from:"Andreas Cadhalpun"

On 22.11.2016 10:55, Sebastian Dröge wrote:
> On Mon, 2016-11-21 at 23:46 +0100, Andreas Cadhalpun wrote:
>> I will take care of ffmpeg myself and I assume you will take care of
>> gst-plugins-bad1.0.
> 
> Yeah, will do in the next days! Some other things to handle first

That's fine. I'll also wait with fixing ffmpeg for the next upstream
bugfix release that is expected soon.

I've now filed bugs #845361 - #845366 about the other packages.
(vlc got already fixed before I had the chance to file a bug.)

Best regards,
Andreas

Bug#845362: libquicktime: removal of libschroedinger

Package: src:libquicktime
Version: 2:1.2.4-8
Severity: serious
Tags: patch
Control: block 845037 by -1

Dear Maintainer,

libschroedinger contains various possibly security relevant bugs and is
no longer maintained upstream. Therefore it has been decided to remove
it from Debian. (see bug #845037)

Before it can be removed, all reverse dependencies have to stop using it.

Attached is a patch dropping the build-dependency on libschroedinger-dev,
which is sufficient to achieve this.

Best regards,
Andreas
--- a/debian/control
+++ b/debian/control
@@ -25,7 +25,6 @@ Build-Depends:
  libpng-dev,
  libpopt-dev,
  libraw1394-dev [linux-any],
- libschroedinger-dev,
  libsdl1.2-dev,
  libswscale-dev (>= 6:10~),
  libvorbis-dev,

Bug#845364: lives: removal of libschroedinger

Package: src:lives
Version: 2.8.0-1
Severity: serious
Tags: patch
Control: block 845037 by -1

Dear Maintainer,

libschroedinger contains various possibly security relevant bugs and is
no longer maintained upstream. Therefore it has been decided to remove
it from Debian. (see bug #845037)

Before it can be removed, all reverse dependencies have to stop using it.

Attached is a patch dropping the build-dependency on libschroedinger-dev,
which is sufficient to achieve this.

Best regards,
Andreas
--- a/debian/control
+++ b/debian/control
@@ -30,7 +30,6 @@ Build-Depends:
  libogg-dev,
  libpulse-dev,
  libraw1394-dev [linux-any],
- libschroedinger-dev,
  libsdl1.2-dev,
  libswscale-dev,
  libtheora-dev,

Bug#845366: ocaml-schroedinger: removal of libschroedinger

Package: src:ocaml-schroedinger
Version: 0.1.0-3
Severity: serious
Control: block 845037 by -1

Dear Maintainer,

libschroedinger contains various possibly security relevant bugs and is
no longer maintained upstream. Therefore it has been decided to remove
it from Debian. (see bug #845037)

Before it can be removed, all reverse dependencies have to stop using it.

Since this package is not useful without libschroedinger, the plan is
to remove it along with that library. This is just an advance notice.

Best regards,
Andreas

Bug#845365: mplayer: removal of libschroedinger

Package: src:mplayer
Version: 2:1.3.0-4
Severity: serious
Tags: patch
Control: block 845037 by -1

Dear Maintainer,

libschroedinger contains various possibly security relevant bugs and is
no longer maintained upstream. Therefore it has been decided to remove
it from Debian. (see bug #845037)

Before it can be removed, all reverse dependencies have to stop using it.

Attached is a patch dropping the build-dependency on libschroedinger-dev,
which is sufficient to achieve this.

libschroedinger was disabled already anyway due to:
Checking for libschroedinger ... no (ffmpeg (static) is required by 
libschroedinger, sorry)

Best regards,
Andreas
--- a/debian/control
+++ b/debian/control
@@ -57,7 +57,6 @@ Build-Depends:
  libpostproc-dev (>= 7:3.0~),
  libpulse-dev,
  librtmp-dev,
- libschroedinger-dev,
  libsdl1.2-dev,
  libsmbclient-dev [!hurd-any],
  libspeex-dev,

Bug#845363: liquidsoap: removal of libschroedinger

Package: src:liquidsoap
Version: 1.1.1-7.1
Severity: serious
Tags: patch
Control: block 845037 by -1

Dear Maintainer,

libschroedinger contains various possibly security relevant bugs and is
no longer maintained upstream. Therefore it has been decided to remove
it from Debian. (see bug #845037)

Before it can be removed, all reverse dependencies have to stop using it.

Attached is a patch dropping the build-dependency on
libschroedinger-ocaml-dev and the liquidsoap-plugin-schroedinger package,
which is sufficient to achieve this.

Best regards,
Andreas
--- a/debian/control
+++ b/debian/control
@@ -42,7 +42,6 @@ Build-Depends:
  libportaudio-ocaml-dev (>= 0.2.0),
  libpulse-ocaml-dev (>= 0.1.2),
  libsamplerate-ocaml-dev (>= 0.1.2),
- libschroedinger-ocaml-dev (>= 0.1.0-3),
  libsdl-ocaml-dev,
  libshine-ocaml-dev,
  libsoundtouch-ocaml-dev (>= 0.1.7),
@@ -142,7 +141,6 @@ Depends:
  liquidsoap-plugin-portaudio,
  liquidsoap-plugin-pulseaudio,
  liquidsoap-plugin-samplerate,
- liquidsoap-plugin-schroedinger,
  liquidsoap-plugin-sdl,
  liquidsoap-plugin-shine,
  liquidsoap-plugin-soundtouch,
@@ -497,7 +495,7 @@ Description: audio streaming language -- Ogg plugin
  .
  This package provides support for Ogg stream decoding and encoding in
  Liquidsoap. This plugin is only useful when used with one of vorbis,
- speex, flac, theora or schroedinger plugin.
+ speex, flac or theora plugin.
 
 Package: liquidsoap-plugin-opus
 Architecture: any
@@ -587,24 +585,6 @@ Description: audio streaming language -- Samplerate plugin
  This package provides support for audio samplerate conversion using
  libsamplerate in Liquidsoap.
 
-Package: liquidsoap-plugin-schroedinger
-Architecture: any
-Depends:
- liquidsoap (= ${binary:Version}),
- ${misc:Depends},
- ${ocaml:Depends},
- ${shlibs:Depends}
-Description: audio streaming language -- Schroedinger plugin
- Liquidsoap is a powerful tool for building complex audio streaming systems,
- typically targeting internet radios (e.g. icecast streams).
- .
- It consists of a simple script language, in which you can create, combine and
- transform audio sources. Its design makes liquidsoap flexible and easily
- extensible.
- .
- This package provides support ogg/dirac video decoding and encoding using
- libschroedinger in Liquidsoap.
-
 Package: liquidsoap-plugin-sdl
 Architecture: any
 Depends:
--- a/debian/liquidsoap-plugin-schroedinger.install
+++ /dev/null
@@ -1 +0,0 @@
-usr/lib/liquidsoap/*/plugins/schroedinger.cm*
--- a/debian/rules
+++ b/debian/rules
@@ -9,7 +9,7 @@ DEB_PYTHON2_MODULE_PACKAGES := liguidsoap
 DEFAULT_FONT := /usr/share/fonts/truetype/ttf-liberation/LiberationSans-Regular.ttf
 
 DEB_CONFIGURE_EXTRA_FLAGS := \
-  --enable-ogg-dynamic-plugin --enable-schroedinger-dynamic-plugin --enable-flac-dynamic-plugin \
+  --enable-ogg-dynamic-plugin --enable-flac-dynamic-plugin \
   --enable-speex-dynamic-plugin --enable-vorbis-dynamic-plugin --enable-theora-dynamic-plugin \
   --enable-sdl-dynamic-plugin --enable-gavl-dynamic-plugin --enable-mad-dynamic-plugin \
   --enable-faad-dynamic-plugin --enable-xmlplaylist-dynamic-plugin --enable-lastfm-dynamic-plugin \
@@ -41,7 +41,7 @@ else
 -Nliquidsoap-plugin-ladspa -Nliquidsoap-plugin-lastfm -Nliquidsoap-plugin-mad \
 -Nliquidsoap-plugin-ogg -Nliquidsoap-plugin-oss -Nliquidsoap-plugin-portaudio \
 -Nliquidsoap-plugin-pulseaudio -Nliquidsoap-plugin-samplerate \
--Nliquidsoap-plugin-schroedinger -Nliquidsoap-plugin-soundtouch -Nliquidsoap-plugin-speex \
+-Nliquidsoap-plugin-soundtouch -Nliquidsoap-plugin-speex \
 -Nliquidsoap-plugin-taglib -Nliquidsoap-plugin-theora -Nliquidsoap-plugin-voaacenc \
 -Nliquidsoap-plugin-vorbis -Nliquidsoap-plugin-xmlplaylist -Nliquidsoap-plugin-lame \
 -Nliquidsoap-plugin-dssi -Nliquidsoap-plugin-lo -Nliquidsoap-plugin-camlimages \

Bug#845361: gmerlin-avdecoder: removal of libschroedinger

Package: src:gmerlin-avdecoder
Version: 1.2.0~dfsg-7
Severity: serious
Tags: patch
Control: block 845037 by -1

Dear Maintainer,

libschroedinger contains various possibly security relevant bugs and is
no longer maintained upstream. Therefore it has been decided to remove
it from Debian. (see bug #845037)

Before it can be removed, all reverse dependencies have to stop using it.

Attached is a patch dropping the build-dependency on libschroedinger-dev,
which is sufficient to achieve this.

Best regards,
Andreas
--- a/debian/control
+++ b/debian/control
@@ -36,7 +36,6 @@ Build-Depends:
  libmpeg2-4-dev,
  libpng-dev,
  libpostproc-dev,
- libschroedinger-dev,
  libsmbclient-dev,
  libspeex-dev,
  libswscale-dev,

Bug#845037: libschroedinger-1.0-0: is this package fit for stretch?

2016-11-21 Thread Andreas Cadhalpun

Hi Sebastian,

On 21.11.2016 08:22, Sebastian Dröge wrote:
> On Sun, 2016-11-20 at 11:57 +0100, Moritz Muehlenhoff wrote:
> 
>>> Thus I think stretch would be better of without this library.
>>>
>>> As replacement, ffmpeg has a decent dirac decoder and also a
>>> vc2 encoder, which is the intra-only subset of dirac that
>>> got standardized by the SMPTE.
>>
>> Andreas, thanks for filing this bug. Fully agreed from my side.
> 
> I tend to agree here.

OK, then it's agreed to remove libschroedinger.

> Note however that VC2 is only a subset of Dirac,
> so we'll definitely lose some (probably unimportant) functionality
> here.

That's true, but I also think that the functionality going to be lost
is rather unimportant.

> Current reverse dependencies are
>  ffmpeg
>  gmerlin-avdecoder
>  gst-plugins-bad1.0
>  libquicktime
>  liquidsoap
>  lives
>  ocaml-schroedinger
>  vlc

There is also mplayer, which has a build-dependency on libschroedinger-dev,
however no run-time dependency due to:
Checking for libschroedinger ... no (ffmpeg (static) is required by 
libschroedinger, sorry)

> Except for the ocaml bindings, this should all be a matter of simply
> disabling the functionality.

Yes. The ocaml bindings have a very low popcon (14), so I think it's
OK to just remove them together with libschroedinger.

I will take care of ffmpeg myself and I assume you will take care of
gst-plugins-bad1.0.
I intend to file bugs for the other packages and block this bug by
them.

Best regards,
Andreas

Bug#845037: libschroedinger-1.0-0: is this package fit for stretch?

2016-11-19 Thread Andreas Cadhalpun

Package: libschroedinger-1.0-0
Version: 1.0.11-2.1
Severity: serious
X-Debbugs-Cc: Debian Security Team 

Dear Maintainer,

libschroedinger contains various possibly security relevant bugs
(see #787957 for the tip of the iceberg).

Furthermore it is no longer maintained upstream:
 * last release from 2012
 * homepage vanished

Thus I think stretch would be better of without this library.

As replacement, ffmpeg has a decent dirac decoder and also a
vc2 encoder, which is the intra-only subset of dirac that
got standardized by the SMPTE.

Best regards,
Andreas


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

Kernel: Linux 4.8.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages libschroedinger-1.0-0 depends on:
ii  libc6  2.24-5
ii  libgcc11:6.2.0-13
ii  liborc-0.4-0   1:0.4.26-2
ii  libstdc++6 6.2.0-13
ii  multiarch-support  2.24-5

libschroedinger-1.0-0 recommends no packages.

libschroedinger-1.0-0 suggests no packages.

-- no debconf information

Bug#841977: libomxil-bellagio0: binaries shipped in shared library package

2016-10-24 Thread Andreas Cadhalpun

Package: libomxil-bellagio0
Version: 0.9.3-3
Severity: serious
Justification: Debian Policy section 8.2

Dear Maintainer,

libomxil-bellagio0 includes binaries and manual pages:
 * /usr/bin/omxregister-bellagio
 * /usr/bin/omxregister-bellagio-0
 * /usr/share/man/man1/omxregister-bellagio.1.gz
 * /usr/share/man/man1/omxregister-bellagio-0.1.gz

These filenames are not versioned. After a soname bump, the new
library package will thus conflict with libomxil-bellagio0.
Such behavior is forbidden by Debian Policy section 8.2:
"If your package contains files whose names do not change with each
change in the library shared object version, you must not put them
in the shared library package. Otherwise, several versions of the
shared library cannot be installed at the same time without filename
clashes, making upgrades and transitions unnecessarily difficult."

Also libomxil-bellagio0 runs omxregister-bellagio upon installation,
which means it is not installable on a foreign architecture.

Best regards,
Andreas

Bug#831591: ffmpeg: kodi crash

2016-10-13 Thread Andreas Cadhalpun

Control: reopen -1
Control: reassign -1 kodi 16.1+dfsg1-2
Control: severity -1 important

Hi,

The relevant backtrace from the kodi_crashlog is:

Thread 1 (Thread 0x7f1b6bffe700 (LWP 16893)):
#0  0x7f1ba92991c8 in __GI_raise (sig=sig@entry=6) at 
../sysdeps/unix/sysv/linux/raise.c:54
#1  0x7f1ba929a64a in __GI_abort () at abort.c:89
#2  0x7f1ba92d4f4a in __libc_message (do_abort=do_abort@entry=2, 
fmt=fmt@entry=0x7f1ba93cdb30 "*** Error in `%s': %s: 0x%s ***\n") at 
../sysdeps/posix/libc_fatal.c:175
#3  0x7f1ba92da6b6 in malloc_printerr (action=3, str=0x7f1ba93ca909 
"free(): invalid pointer", ptr=, ar_ptr=) at 
malloc.c:5004
#4  0x7f1ba92dae9e in _int_free (av=0x7f1ba9601b20 , 
p=, have_lock=0) at malloc.c:3865
#5  0x7f1baa6d4a9d in av_buffer_unref () from 
/usr/lib/x86_64-linux-gnu/libavutil.so.55
#6  0x7f1baa6e15d2 in av_frame_unref () from 
/usr/lib/x86_64-linux-gnu/libavutil.so.55
#7  0x7f1bab93cf10 in avcodec_decode_video2 () from 
/usr/lib/x86_64-linux-gnu/libavcodec.so.57
#8  0x0090b26c in CDVDDemuxFFmpeg::ParsePacket(AVPacket*) ()
#9  0x0090d0c2 in CDVDDemuxFFmpeg::Read() ()
#10 0x01079b53 in CDVDPlayer::ReadPacket(DemuxPacket*&, CDemuxStream*&) 
()
#11 0x0107ecd7 in CDVDPlayer::Process() ()
#12 0x012103ff in CThread::Action() ()
#13 0x012106bf in CThread::staticThread(void*) ()
#14 0x7f1bb23e5464 in start_thread (arg=0x7f1b6bffe700) at 
pthread_create.c:333
#15 0x7f1ba934d30d in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Looking at the ParsePacket function reveals [1]:
AVFrame picture;
memset(, 0, sizeof(AVFrame));
picture.pts = picture.pkt_dts = picture.pkt_pts = 
picture.best_effort_timestamp = AV_NOPTS_VALUE;
picture.pkt_pos = -1;
picture.key_frame = 1;
picture.format = -1;

This is using non-public ABI, e.g. the size of AVFrame, while the documentation
explicitly says "sizeof(AVFrame) is not a part of the public ABI" [2].
What's worse is that it doesn't use av_frame_alloc as required [3]:
"AVFrame must be allocated using av_frame_alloc()."

The whole block quoted above should be replaced with:
AVFrame *picture = av_frame_alloc().

Then the following code should use picture instead of :
avcodec_decode_video2(st->codec, picture, _picture, pkt);

And at the end it can be freed (instead of using av_frame_unref) with:
av_frame_free();

In the experimental kodi branch there is another occurrence of this bug
in xbmc/cores/VideoPlayer/VideoRenderers/HwDecRender/MMALRenderer.cpp.

Best regards,
Andreas


1: 
https://anonscm.debian.org/cgit/pkg-multimedia/kodi.git/tree/xbmc/cores/dvdplayer/DVDDemuxers/DVDDemuxFFmpeg.cpp?id=8d5cf423001aa4e7f850c20b158b2811e637e607#n1665
2: 
https://anonscm.debian.org/cgit/pkg-multimedia/ffmpeg.git/tree/libavutil/frame.h?id=87b93f4e3ee2b6253ab9f5a166860a1ff18877d5#n174
3: 
https://anonscm.debian.org/cgit/pkg-multimedia/ffmpeg.git/tree/libavutil/frame.h?id=87b93f4e3ee2b6253ab9f5a166860a1ff18877d5#n154

Bug#840434: marked as pending

2016-10-11 Thread Andreas Cadhalpun

tag 840434 pending
thanks

Hello,

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

http://git.debian.org/?p=pkg-multimedia/ffmpeg.git;a=commitdiff;h=87b93f4

---
commit 87b93f4e3ee2b6253ab9f5a166860a1ff18877d5
Author: Andreas Cadhalpun <andreas.cadhal...@googlemail.com>
Date:   Tue Oct 11 21:18:00 2016 +0200

finalize changelog

diff --git a/debian/changelog b/debian/changelog
index 1209a73..88975bb 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,12 +1,28 @@
-ffmpeg (7:3.1.4-1) UNRELEASED; urgency=medium
+ffmpeg (7:3.1.4-1) unstable; urgency=medium
 
   [ Ondřej Nový ]
   * Disable librtmp support, because the built-in RTMP support is better.
 
   [ Andreas Cadhalpun ]
   * Import new upstream bugfix release 3.1.4.
-
- -- Andreas Cadhalpun <andreas.cadhal...@googlemail.com>  Tue, 11 Oct 2016 
20:45:44 +0200
+ - Fixes CVE-2016-7122, CVE-2016-7450, CVE-2016-7502, CVE-2016-7555,
+   CVE-2016-7562, CVE-2016-7785 and CVE-2016-7905. (Closes: #840434)
+  * Fix typos.
+  * Replace libopencv-dev build-dependency with libopencv-imgproc-dev.
+  * Improve build-time optimization for libavfilter-extra.
+  * Mention sofalizer in libavfilter-extra6 description.
+  * Remove redundant nocheck test.
+  * Add libopenjpegenc-recreate-image-data-buffer.patch to fix autopkg
+test crashes.
+  * Let the encdec test print the command before executing it.
+  * Update encdec*_list.txt.
+  * Re-enable the libopenjpeg decoder.
+  * Enable libzmq on hurd, as it is now available there.
+  * Use 'set -e' to abort build on configure failure.
+  * Only set CC/CXX if they differ from the default.
+  * Set configure options for cross-building.
+
+ -- Andreas Cadhalpun <andreas.cadhal...@googlemail.com>  Tue, 11 Oct 2016 
21:17:10 +0200
 
 ffmpeg (7:3.1.3-2) unstable; urgency=medium

Bug#813858: gcc-5: [mips] regression: miscompilation caused by -fexpensive-optimizations

2016-02-12 Thread Andreas Cadhalpun

Control: forwarded -1 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69714
Control: tags -1 patch

Hi Aurelien,

On 08.02.2016 23:59, Aurelien Jarno wrote:
> On 2016-02-06 02:38, Andreas Cadhalpun wrote:
>> This works correctly with gcc-5 5.3.1-6, so it is a regression in 5.3.1-7.
> 
> In my case I am able to reproduce the issue with both version 5.3.1-6
> and 5.3.1-7, as well as 5.3.1-8.

This is very strange, as ffmpeg 7:2.8.5-1 built successfully with gcc-5 5.3.1-6
on the mips buildd.

> That said I don't think that GCC is broken here, instead the source code is 
> wrong.

I beg to differ.

>> static uint32_t av_bswap32(uint32_t x)
>> {
>> return x) << 8 & 0xff00) | ((x) >> 8 & 0x00ff)) << 16 | x) >> 
>> 16) << 8 & 0xff00) | (((x) >> 16) >> 8 & 0x00ff)));
>> }
> 
> Note that this doesn't really produce optimized code.  has a
> better code which calls __builtin_bswap32 on a (not that) recent GCC.

ffmpeg has it's own optimized versions for more common architectures.

>> return av_bswap32(*((uint32_t *) ([2])));
> 
> This is dereferencing a type-punned pointer, as reported by using -Wall.
> This means that GCC can now assume that the value to fetch in preamble is
> 32-bit aligned, and that's why it generates code to bswap the aligned
> 32-bit code starting at position 4 instead of the one starting at position
> 2.
> 
> Note that this undefined behavior can be reproduced on amd64 by using
> the -fsanitize=undefined option (ubsan):
> 
> | test.c:32:12: runtime error: load of misaligned address 0xffdf50da for type 
> 'uint32_t', which requires 4 byte alignment
> | 0xffdf50da: note: pointer points here
> |  04 08  21 10 f0 2d 00 00 00 00  48 d1 df ff 60 c1 75 f7  eb 15 74 f7 d4 99 
> 04 08  00 00 00 00 c0 84
> | 
> |   ^ 

These warnings are a red herring, as they are only an artifact from reducing
the testcase. They don't happen with the ffmpeg code and avoiding them in
the testcase, e.g. with the following diff, doesn't fix the problem:
--- a/test.c
+++ b/test.c
@@ -16,6 +16,8 @@
 void *a;
 } AVPacket;
 
+union unaligned_32 { uint32_t l; } __attribute__((packed)) 
__attribute__((may_alias));
+
 static uint32_t av_bswap32(uint32_t x)
 {
 return x) << 8 & 0xff00) | ((x) >> 8 & 0x00ff)) << 16 | x) >> 16) 
<< 8 & 0xff00) | (((x) >> 16) >> 8 & 0x00ff)));
@@ -29,5 +31,5 @@
 preamble[i] = s->pb->buf_ptr[0];
 s->pb->buf_ptr += 1;
 }
-return av_bswap32(*((uint32_t *) ([2])));
+return av_bswap32(((const union unaligned_32 *) ([2]))->l);
 }

On the other hand, gcc-5 5.3.1-7 also regressed on hppa, causing different test 
failures
of ffmpeg. I've reported this to debian-hppa, where it was analyzed and 
forwarded
upstream. The patch [1] fixing that also fixes the regression on mips.

Best regards,
Andreas


1: https://gcc.gnu.org/bugzilla/attachment.cgi?id=37655=diff

Bug#813858: gcc-5: [mips] regression: miscompilation caused by -fexpensive-optimizations

2016-02-06 Thread Andreas Cadhalpun

Control: affects -1 tokyocabinet

Hi Tobias,

On 06.02.2016 15:37, Tobias Frost wrote:
> I also see something like this for tokyocabinet, see #813880 for an
> analysis... 
> 
> I see those failures on powerpc, ppc64 and s390x, but not on mips.

Well, 1.4.48-5 and 1.4.48-6 also failed to build on mips [1].

> So this might be indeed a differnt bug as well, but I guess related to
> optimization.
> 
> After seeing this bug, I tried -fno-expensive-optimizations on
> partch.d.o -- and this fixes also the regression I was experiencing.

I tried making the argument of av_bswap32 in my test case volatile and
that also fixed the problem. So it seems to me that these really are
the same bug. Thus I've added this to the bug metadata.

Best regards,
Andreas

1: 
https://buildd.debian.org/status/fetch.php?pkg=tokyocabinet=mips=1.4.48-6=1454770843

Bug#813858: gcc-5: [mips] regression: miscompilation caused by -fexpensive-optimizations

2016-02-05 Thread Andreas Cadhalpun

Package: gcc-5
Version: 5.3.1-7
Severity: serious
Justification: causes ffmpeg to FTBFS
Control: affects -1 ffmpeg
X-Debbugs-Cc: debian-m...@lists.debian.org

Dear Maintainer,

ffmpeg 7:2.8.6-1 failed to build on mips due to test failures.

I investigated the problem and it turns out to be caused by a compiler bug
that can be avoided by using '-fno-expensive-optimizations'.
(Somehow this feels like Déjà vu... #800318)

Attached is a reduced test case:
$ ls
Makefile  main.c  test.c
$  make
cc -fPIC -g -O2 -fno-expensive-optimizations -c -o working.o test.c
cc -shared -o libworking.so working.o
cc -fPIC -g -o working main.c -L. -lworking
cc -fPIC -g -O2 -c -o broken.o test.c
cc -shared -o libbroken.so broken.o
cc -fPIC -g -o broken main.c -L. -lbroken
LD_LIBRARY_PATH=. ./working || true
chunk_size: 11760
working
LD_LIBRARY_PATH=. ./broken || true
chunk_size: 0
broken

This works correctly with gcc-5 5.3.1-6, so it is a regression in 5.3.1-7.
The difference between broken.o compiled by 5.3.1-6 and 5.3.1-7 is shown
by diffoscope as:
├── objdump --line-numbers --disassemble --section=.text {}
│ @@ -17,23 +17,23 @@
│18:24420001addiu   v0,v0,1
│1c:24630001addiu   v1,v1,1
│20:aca2000csw  v0,12(a1)
│  ./test.c:28 (discriminator 3)
│24:1446fffbbne v0,a2,14 
│28:a064sb  a0,-1(v1)
│  ./test.c:32
│ -  2c:8ba4000alwl a0,10(sp)
│ -  30:97a2000clhu v0,12(sp)
│ -  34:9ba4000dlwr a0,13(sp)
│ -  38:7c0210a0wsbhv0,v0
│ +  2c:8ba3000alwl v1,10(sp)
│ +  30:97a4000clhu a0,12(sp)
│ +  34:9ba3000dlwr v1,13(sp)
│ +  38:7c0420a0wsbha0,a0
│  ./test.c:33
│3c:27bd0010addiu   sp,sp,16
│  ./test.c:32
│ -  40:00021c00sll v1,v0,0x10
│ -  44:00041202srl v0,a0,0x8
│ -  48:00042602srl a0,a0,0x18
│ -  4c:3042ff00andiv0,v0,0xff00
│ -  50:00621025or  v0,v1,v0
│ +  40:3084andia0,a0,0x
│ +  44:00031200sll v0,v1,0x8
│ +  48:7c633a00ext v1,v1,0x8,0x8
│ +  4c:00431825or  v1,v0,v1
│ +  50:00031400sll v0,v1,0x10
│  ./test.c:33
│54:03e8jr  ra
│58:00441025or  v0,v0,a0
│5c:nop
├── readelf --wide --decompress --string-dump=.comment {}
│ @@ -1,4 +1,4 @@
│  
│  String dump of section '.comment':
│ -  [ 1]  GCC: (Debian 5.3.1-6) 5.3.1 20160114
│ +  [ 1]  GCC: (Debian 5.3.1-7) 5.3.1 20160121
│  
╵

I hope that helps to fix this bug soon.

Best regards,
Andreas


-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: mips

Kernel: Linux 4.3.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages gcc-5 depends on:
ii  binutils  2.26-3
ii  cpp-5 5.3.1-7
ii  gcc-5-base5.3.1-7
ii  libc6 2.21-7
ii  libcc1-0  5.3.1-7
ii  libgcc-5-dev  5.3.1-7
ii  libgcc1   1:5.3.1-7
ii  libgmp10  2:6.1.0+dfsg-2
ii  libisl15  0.16.1-1
ii  libmpc3   1.0.3-1
ii  libmpfr4  3.1.3-2
ii  libstdc++65.3.1-7
ii  zlib1g1:1.2.8.dfsg-2+b1

Versions of packages gcc-5 recommends:
ii  libc6-dev  2.21-7

Versions of packages gcc-5 suggests:
pn  gcc-5-doc 
pn  gcc-5-locales 
pn  gcc-5-multilib
pn  libasan2-dbg  
pn  libatomic1-dbg
pn  libcilkrts5-dbg   
pn  libgcc1-dbg   
pn  libgomp1-dbg  
pn  libitm1-dbg   
pn  liblsan0-dbg  
pn  libmpx0-dbg   
pn  libquadmath0-dbg  
pn  libtsan0-dbg  
pn  libubsan0-dbg 

-- no debconf information
#include 
#include 

typedef struct AVIOContext {
uint8_t a[4];
uint8_t *buffer;
int32_t buffer_size;
uint8_t *buf_ptr;
} AVIOContext;

typedef struct AVFormatContext {
uint8_t a[15];
AVIOContext* pb;
} AVFormatContext;

typedef struct AVPacket {
void *a;
} AVPacket;

int roq_read_packet(AVFormatContext *s, AVPacket *pkt);

int main()
{
AVPacket pkt = { 0 };
AVFormatContext s = { 0 };
AVIOContext pb = { 0 };
uint8_t buffer[32768] = { 0x84, 0x10, 0xff, 0xff, 0xff, 0xff, 0x1e, 0x00,
  0x21, 0x10, 0xf0, 0x2d, 0x00, 0x00, 0x00, 0x00,
  0 };

pb.buffer = buffer;
pb.buffer_size = 32768;
pb.buf_ptr = [8];
s.pb = 

int chunk_size = roq_read_packet(, );
printf("chunk_size: %u\n", chunk_size);
if (chunk_size == 0x2df0) {
printf("working\n");
return 0;
}
else {
printf("broken\n");
return 1;
}
}
CFLAGS +=

Bug#811519: vlc: avio plugin leaks file content

2016-01-19 Thread Andreas Cadhalpun

Control: tags -1 = moreinfo
Control: severity -1 important

Hi,

On 19.01.2016 17:27, Sebastian Ramacher wrote:
> On 2016-01-19 18:11:01, Rémi Denis-Courmont wrote:
>> With a carefully crafted URL, the VLC avio plugin can be made to leak
>> content of local files to remote parties.
>> The root cause is the same as CVE-2016-1897.
>>
>> See also:
>>
>> https://mailman.videolan.org/pipermail/vlc-devel/2016-January/105718.html
> 
> There is nothing to be done in the vlc package. Reassigning to ffmpeg. It 
> needs
> to be built with --disable-protocol=concat.

How is CVE-2016-1897 not fully fixed?

Rémi, please share details about any remaining vulnerability with
.

Best regards,
Andreas

Bug#741935: Bug#803800: avbin: FTBFS with FFmpeg 2.9

2016-01-11 Thread Andreas Cadhalpun

Hi Jon,

On 11.01.2016 11:24, Jonathan Peirce wrote:
> Thanks for the note Andreas. I think for the psychopy package we now
> have sufficient alternatives that we can live without avbin.

Thanks for the confirmation. I requested the removal of avbin now
in bug #810706 [1].

Best regards,
Andreas


1: https://bugs.debian.org/810706

Bug#741935: Bug#803800: avbin: FTBFS with FFmpeg 2.9

2016-01-07 Thread Andreas Cadhalpun

Hi,

the next version of FFmpeg is planned to be released this month
(and it might be called 3.0 instead of 2.9).

As this package is currently broken (#750577), not in testing
due to #741935, and still orphaned, I think it should be removed
from sid.

Therefore I'll request it's removal soon, unless someone fixes
the outstanding issues of this package.

Best regards,
Andreas

Bug#807973: chromium-browser: 1 GB of sourceless binaries in the source package

2015-12-14 Thread Andreas Cadhalpun

Source: chromium-browser
Version: 47.0.2526.80-1
Severity: serious
Justification: policy §2.1

Dear Maintainer,

in this version, the source package includes about 1 GB of binaries
in the native_client/toolchain subdirectory.
Apparently no sources for them are included, only references in:
native_client/toolchain_build/toolchain_build.py

The DFSG #2 requires source code to be present. Since these binaries
are hopefully not used during build, please strip them from the tarball.

Best regards,
Andreas

Bug#807578: /usr/bin/afl-clang-fast: strict dependency on clang version not declared

2015-12-10 Thread Andreas Cadhalpun

Package: afl-clang
Version: 1.95b-2
Severity: serious
Justification: makes the program unusable
File: /usr/bin/afl-clang-fast

Dear Maintainer,

The current version of afl-clang-fast in testing doesn't work at all:
$ echo "int main(){return 0;}" | afl-clang-fast -x c -
afl-clang-fast 1.95b by 
afl-llvm-pass 1.95b by 
/usr/lib/llvm-3.5/bin/clang: symbol lookup error: 
/usr/lib/afl/afl-llvm-pass.so: undefined symbol: 
_ZN4llvm16MetadataTracking5trackEPvRNS_8MetadataENS_12PointerUnionIPNS_15MetadataAsValueEPS2_EE
clang: error: unable to execute command: No such file or directory
clang: error: clang frontend command failed due to signal (use -v to see 
invocation)
Debian clang version 3.5.2-3 (tags/RELEASE_352/final) (based on LLVM 3.5.2)
Target: x86_64-pc-linux-gnu
Thread model: posix
clang: note: diagnostic msg: PLEASE submit a bug report to 
http://bugs.debian.org/ and include the crash backtrace, preprocessed source, 
and associated run script.
clang: note: diagnostic msg: Error generating preprocessed source(s) - ignoring 
input from stdin.
clang: note: diagnostic msg: Error generating preprocessed source(s) - no 
preprocessable inputs.

The reason is that clang in testing is still version 3.5, while it is
already 3.6 in sid, so afl-clang got built with 3.6.
Previous versions (up to 1.94b-1+b1) used to declare this dependency like:
clang (<< 1:3.7), clang (>= 1:3.6)

However, the current version (1.95b-2) only depends on unversioned 'clang',
which is not enough.

Since debian/changelog does not mention this change, I assume that it was
not intended.

Also, please keep using a public git repository for your packaging, so
that one can more easily check which change broke something.

Best regards,
Andreas


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

Kernel: Linux 4.3.0-trunk-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages afl-clang depends on:
ii  afl 1.95b-2
ii  clang   1:3.5-26
ii  libc6   2.19-22
ii  libgcc1 1:5.2.1-23
ii  libstdc++6  5.2.1-23

afl-clang recommends no packages.

afl-clang suggests no packages.

Bug#804852: Bug#800509: LLVM default to 3.6 transition ?

2015-11-22 Thread Andreas Cadhalpun

Dear release team,

afl-clang is also involved in this transition, as it depends on:
clang (<< 1:3.6), clang (>= 1:3.5)

Hence it is currently uninstallable in sid, which was reported as #804852.

After a no-change-rebuild in current sid, these dependencies change to:
clang (<< 1:3.7), clang (>= 1:3.6)

So please schedule a binNMU for afl to make it installable again.

Best regards,
Andreas

Bug#805169: cmus-plugin-ffmpeg: not linked with libavresample

2015-11-15 Thread Andreas Cadhalpun

Package: cmus-plugin-ffmpeg
Version: 2.5.0-7+b2
Tags: sid stretch patch
Severity: grave
Justification: makes the package unusable

Dear Maintainer,

the libav10.patch makes use of libavresample, but doesn't make sure
the plugin is actually linked with that library.

Thus cmus can't dlopen this plugin:
$ cmus --plugins | grep -A 3 ffmpeg
There is no output, while there should be:
$ cmus --plugins | grep -A 3 ffmpeg
  ffmpeg:
Priority: 30
File Types: ac3 aif aifc aiff ape au mka shn tta wma aac fla flac m4a m4b 
mp+ mp2 mp3 mp4 mpc mpp ogg wav wv
MIME Types:

It used to work, because Libav's libavcodec links with libavresample,
but FFmpeg's libavcodec doesn't.

The following patch fixes this bug:
---8<---
--- cmus-2.5.0.orig/configure
+++ cmus-2.5.0/configure
@@ -347,7 +347,7 @@ check_aac()
 check_ffmpeg()
 {
HAVE_FFMPEG_AVCODEC_H=y
-   pkg_config FFMPEG "libavformat" || return $?
+   pkg_config FFMPEG "libavformat libavresample" || return $?
if check_header "libavcodec/avcodec.h" $FFMPEG_CFLAGS
then
HAVE_FFMPEG_AVCODEC_H=n
--->8---

However, it might be better to just import the new upstream version,
which uses libswresample instead of libavresample.

Best regards,
Andreas


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

Kernel: Linux 4.3.0-trunk-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages cmus-plugin-ffmpeg depends on:
ii  libavformat-ffmpeg56  7:2.8.1-1+b1
ii  libc6 2.19-22

cmus-plugin-ffmpeg recommends no packages.

Versions of packages cmus-plugin-ffmpeg suggests:
ii  cmus  2.5.0-7+b2

-- no debconf information

Bug#804222: harvid: FTBFS: *** No rule to make target '../libharvid/libharvid.a', needed by 'harvid'. Stop.

2015-11-06 Thread Andreas Cadhalpun

Control: tags -1 patch

Hi Chris,

On 06.11.2015 12:37, Chris Lamb wrote:
> harvid fails to build from source in unstable/amd64:
> 
>   [..]
> 
>   cc -c -o timecode.o -g -O2 -fstack-protector-strong -Wformat
>   -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2`pkg-config
>   --cflags libavcodec libavformat libavutil libswscale` timecode.c
>   export PKG_CONFIG_PATH=;\
>   cc -c -o vinfo.o -g -O2 -fstack-protector-strong -Wformat
>   -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2`pkg-config
>   --cflags libavcodec libavformat libavutil libswscale` vinfo.c
>   make[3]: *** No rule to make target '../libharvid/libharvid.a', needed
>   by 'harvid'.  Stop.

The problem is that upstream's Makefile is not compatible with parallel
building. Attached patch fixes this.

Best regards,
Andreas

Description: Fix parallel build
 libharvid is required to build the harvid binary in the src directory.
 Declaring this dependency is only possible, when changing the $(SUBDIRS)
 target from double-colon to single-colon, since double-colon implies
 independence.
 But then it has to be marked .PHONY as well, or nothing will be built.

Author: Andreas Cadhalpun <andreas.cadhal...@googlemail.com>
Last-Update: <2015-11-06>

--- harvid-0.8.0.orig/Makefile
+++ harvid-0.8.0/Makefile
@@ -3,7 +3,9 @@ SUBDIRS = libharvid src doc
 
 default: all
 
-$(SUBDIRS)::
+src: libharvid
+
+$(SUBDIRS):
 	$(MAKE) -C $@ $(MAKECMDGOALS)
 
 all clean man install uninstall install-bin install-man uninstall-bin uninstall-man install-lib uninstall-lib: $(SUBDIRS)
@@ -11,4 +13,4 @@ all clean man install uninstall install-bin install-man uninstall-bin uninstall-
 dist:
 	git archive --format=tar --prefix=harvid-$(VERSION)/ HEAD | gzip -9 > harvid-$(VERSION).tar.gz
 
-.PHONY: clean all subdirs install uninstall dist install-bin install-man uninstall-bin uninstall-man install-lib uninstall-lib
+.PHONY: clean all subdirs install uninstall dist install-bin install-man uninstall-bin uninstall-man install-lib uninstall-lib $(SUBDIRS)

Bug#803700: mrpt: FTBFS: 7 FAILED TESTS

2015-11-03 Thread Andreas Cadhalpun

Control: tags -1 fixed-upstream

Hi Jose Luis,

On 03.11.2015 10:34, Jose Luis Blanco wrote:
> For the records: This was caused by the use of the latest alpha
> version of Eigen 3.3, as explained in this bug report:
> http://eigen.tuxfamily.org/bz/show_bug.cgi?id=1066#c3
> 
> It is already fixed upstream in MRPT. We will release a new version
> soon to close this bug.

That's good news, tagging the bug accordingly.

Best regards,
Andreas

Bug#803701: ovito: FTBFS: missing BD libcgal-qt5-dev

2015-11-01 Thread Andreas Cadhalpun

Source: ovito
Version: 2.3.3+dfsg1-1
Severity: serious
Tags: Patch

Dear Maintainer,

ovito currently fails to build due to a missing build-dependency on 
libcgal-qt5-dev:

CMake Error at /usr/lib/x86_64-linux-gnu/cmake/CGAL/CGALExports.cmake:83 
(message):
  The imported target "CGAL::CGAL_Qt5" references the file

 "/usr/lib/x86_64-linux-gnu/libCGAL_Qt5.so.11.0.1"

  but this file does not exist.  Possible reasons include:

  * The file was deleted, renamed, or moved to another location.

  * An install or uninstall procedure did not complete successfully.

  * The installation package was faulty and contained

 "/usr/lib/x86_64-linux-gnu/cmake/CGAL/CGALExports.cmake"

  but not all the files it references.

The trivial patch is:
--- a/debian/control
+++ b/debian/control
@@ -15,7 +15,7 @@ Build-Depends: cmake,
libboost-iostreams-dev,
libboost-python-dev,
libbotan1.10-dev,
-   libcgal-dev [!armel],
+   libcgal-qt5-dev [!armel],
libglu1-mesa-dev [armel armhf],
libgl1-mesa-dev [armel armhf],
libgsl0-dev,

A full build log is available from the reproducibility rebuild [1].

Best regards,
Andreas


1: https://reproducible.debian.net/rb-pkg/unstable/amd64/ovito.html

Bug#803700: mrpt: FTBFS: 7 FAILED TESTS

2015-11-01 Thread Andreas Cadhalpun

Source: mrpt
Version: 1.3.0-1.1
Severity: serious

Dear Maintainer,

mrpt currently fails to build due to test failures:

[==] 139 tests from 24 test cases ran. (8760 ms total)
[  PASSED  ] 132 tests.
[  FAILED  ] 7 tests, listed below:
[  FAILED  ] Pose3DQuatPDFGaussTests.CompositionJacobian
[  FAILED  ] Pose3DQuatPDFGaussTests.Composition
[  FAILED  ] Pose3DQuatPDFGaussTests.InverseComposition
[  FAILED  ] Pose3DQuatPDFGaussTests.ChangeCoordsRef
[  FAILED  ] Pose3DPDFGaussTests.CompositionJacobian
[  FAILED  ] Pose3DPDFGaussTests.AllOperators
[  FAILED  ] Pose3DPDFGaussTests.ChangeCoordsRef

 7 FAILED TESTS

A full build log is available from the reproducibility rebuild [1].

Best regards,
Andreas


1: https://reproducible.debian.net/rb-pkg/unstable/amd64/mrpt.html

Bug#803461: [Pkg-clamav-devel] Bug#803461: clamav: FTBFS with LLVM 3.6

2015-11-01 Thread Andreas Cadhalpun

Control: tags -1 pending

On 30.10.2015 11:42, Andreas Beckmann wrote:
> Clamav in experimental FTBFS with LLVM 3.6:
> 
> configure: Using external LLVM
> checking for supported LLVM version... no (3.6.2)
> configure: error: LLVM < 3.6 required, but "3.6.2"(362) found
> configure: error: Failed to configure LLVM, and LLVM was explicitly requested

This has already been fixed in git.

Best regards,
Andreas

Bug#800318: gcc-5: [mips,mipsel] regression: miscompilation caused by -fexpensive-optimizations

2015-09-29 Thread Andreas Cadhalpun

On 29.09.2015 22:54, Aurelien Jarno wrote:
> On 2015-09-29 19:41, Andreas Cadhalpun wrote:
>> Great. Can you estimate when that upload will happen?
>> (I'm trying to decide whether or not to workaround it in the meantime.)
> 
> This is handled by Matthias Klose, so it's a bit difficult to say, but I
> guess before the end of the week. Note that version 5.2.1-18 might
> appear as it has been uploaded today, but it was stuck in NEW for a few
> days.

OK.

>>> I'll also try to better understand the issue so that I can report the
>>> bug upstream.
> 
> On this aspect, I believe the problem might be PR66424 [1], at least the
> fix for this bug fixes the testcase you provided. I am currently cleanly
> building gcc with it and tomorrow morning I'll build ffmpeg with this
> gcc to fully confirm. In the meantime Matthias asked upstream to
> backport it to the stable gcc 5 branch, which has already been done a
> few hours ago.

Cool. If it fixes the testcase I'm quite confident that it fixes
ffmpeg's test failures as well.

Best regards,
Andreas

Bug#800318: gcc-5: [mips,mipsel] regression: miscompilation caused by -fexpensive-optimizations

2015-09-29 Thread Andreas Cadhalpun

Hi,

On 28.09.2015 21:52, Aurelien Jarno wrote:
> On 2015-09-28 18:17, Andreas Cadhalpun wrote:
>> Attached is a testcase for mips, but it works fine for mipsel.
>>
>> One more peculiarity I noticed is that adding 'c->A = 1;' to
>> an unused code path inverts the behavior: It works with
>> -fexpensive-optimizations, but fails with -fno-expensive-optimizations.
> 
> Big thanks for working on that. I have done some tests with it and
> -mtune=mips32r2 is the culprit not -march=mips32r2. This is kind of
> unexpected, but at least it is consistent with the mipsel issue. This
> means the optimization happens when scheduling the instructions. This
> also means we have an easy workaround without lowering the ISA. I'll
> commit that so that's in the next gcc upload.

Great. Can you estimate when that upload will happen?
(I'm trying to decide whether or not to workaround it in the meantime.)

> I'll also try to better understand the issue so that I can report the
> bug upstream.

Thanks.

Best regards,
Andreas

Bug#800318: gcc-5: [mips,mipsel] regression: miscompilation caused by -fexpensive-optimizations

2015-09-28 Thread Andreas Cadhalpun

Hi Aurelien,

On 28.09.2015 14:48, Aurelien Jarno wrote:
> On 2015-09-27 23:43, Andreas Cadhalpun wrote:
>> A slightly larger test case for mips is compiling ffmpeg...
> 
> It what I did to test if the failure is due to the above changes.
> ffmpeg builds fine with gcc version 5.2.1-17 and -march=mips2
> -mtune=mips32 (instead of the new default -march=mips32r2), and passes
> the testsuite. I'll see if I can isolate a smaller testcase so that we
> can understand the problem.

Attached is a testcase for mips, but it works fine for mipsel.

One more peculiarity I noticed is that adding 'c->A = 1;' to
an unused code path inverts the behavior: It works with
-fexpensive-optimizations, but fails with -fno-expensive-optimizations.

Best regards,
Andreas

#include 
#include 

typedef struct Context {
int64_t out;
int64_t A;
int64_t B;
int C;
} Context;

void init_tables(Context *c, int *table, int brightness, int contrast, int saturation);

int main()
{
Context c = { 0 };
int table[3] = {104597, 132201, 25675};
init_tables(, table, 0, 65536, 65536);

fprintf(stderr, "TEST: 0x%"PRIX64"\n", c.out);
if (c.out == 0x12a15) {
printf("working\n");
return 0;
}
printf("broken\n");
return 1;
}
CFLAGS += -fPIC -O2
LDFLAGS += -shared

all: working broken
LD_LIBRARY_PATH=. ./working || true
LD_LIBRARY_PATH=. ./broken || true

working.o:
$(CC) $(CFLAGS) -fno-expensive-optimizations -c -o working.o test.c

broken.o:
$(CC) $(CFLAGS) -c -o broken.o test.c

libworking.so: working.o
$(CC) $(LDFLAGS) -o libworking.so working.o

libbroken.so: broken.o
$(CC) $(LDFLAGS) -o libbroken.so broken.o

working: libworking.so
$(CC) -o working main.c -L. -lworking

broken: libbroken.so
$(CC) -o broken main.c -L. -lbroken

clean:
rm -f working.o libworking.so working broken.o libbroken.so broken
#include 

typedef struct Context {
int64_t out;
int64_t A;
int64_t B;
int C;
} Context;

static uint8_t clip_uint8_c(int a)
{
if (a&(~0xFF)) return (-a)>>31;
else return a;
}
static void fill_table(uint8_t* table[256 + 2*256], const int elemsize,
   const int64_t inc, void *y_tab)
{
int i;
uint8_t *y_table = y_tab;
y_table -= elemsize * (inc >> 9);
for (i = 0; i < 256 + 2*256; i++) {
int64_t cb = clip_uint8_c(i-256)*inc;
table[i] = y_table + elemsize * (cb >> 16);
}
}
static void fill_gv_table(int table[256 + 2*256], const int elemsize, const int64_t inc)
{
int i;
int off = -(inc >> 9);
for (i = 0; i < 256 + 2*256; i++) {
int64_t cb = clip_uint8_c(i-256)*inc;
table[i] = elemsize * (off + (cb >> 16));
}
}
static uint16_t roundToInt16(int64_t f)
{
int r = (f + (1 << 15)) >> 16;
if (r < -0x7FFF)
return 0x8000;
else if (r > 0x7FFF)
return 0x7FFF;
else
return r;
}

uint8_t yuvTable[1024];
int table_gV[256 + 2*256];
uint8_t *table_rV[256 + 2*256];
uint8_t *table_gU[256 + 2*256];
uint8_t *table_bU[256 + 2*256];
int64_t loc1;
int64_t loc2;
int64_t loc3;
int loc4;

__attribute__((cold)) void init_tables(Context *c, int *table, int brightness, int contrast, int saturation)
{
int i;
const int bpp = c->C;
const int yoffs = brightness ? 384 : 326;
int64_t crv = table[0];
int64_t cbu = table[1];
int64_t cgu = -table[0];
int64_t cgv = -table[2];
int64_t cy = 1 << 16;
int64_t TEST = 1 << 16;
int64_t oy = 0;
int64_t yb = 0;
if (!brightness) {
cy = (cy * 255) / 219;
TEST = (TEST * 255) / 219;
oy = 16 << 16;
} else {
crv = (crv * 224) / 255;
cbu = (cbu * 224) / 255;
cgu = (cgu * 224) / 255;
cgv = (cgv * 224) / 255;
}
cy = (cy * contrast) >> 16;
//c->out = TEST;
TEST = (TEST * contrast) >> 16;
c->out = TEST;

crv = (crv * contrast * saturation) >> 32;
cbu = (cbu * contrast * saturation) >> 32;
cgu = (cgu * contrast * saturation) >> 32;
cgv = (cgv * contrast * saturation) >> 32;
oy -= 256 * brightness;
c->A = 1;
c->B = roundToInt16(cy * 8192) + roundToInt16(crv * 8192);
loc1 = roundToInt16(cgv * 8192);
loc2 = roundToInt16(cgu * 8192);
loc3 = roundToInt16(oy * 8);
loc4 = roundToInt16(cy << 13) + roundToInt16(oy) + roundToInt16(crv << 13) 
   + roundToInt16(cgv << 13) + roundToInt16(cgu << 13) + roundToInt16(cbu << 13);
crv = ((crv << 16) + 0x8000) / ((cy) > (1) ? (cy) : (1));
cbu = ((cbu << 16) + 0x8000) / ((cy) > (1) ? (cy) : (1));
cgu = ((cgu << 16) + 0x8000) / ((cy) > (1) ? (cy) : (1));
cgv = ((cgv << 16) + 0x8000) / ((cy) > (1) ? (cy) :

Bug#800318: gcc-5: [mips,mipsel] regression: miscompilation caused by -fexpensive-optimizations

2015-09-27 Thread Andreas Cadhalpun

Package: gcc-5
Version: 5.2.1-17
Severity: serious
Justification: causes ffmpeg to FTBFS
Control: affects -1 ffmpeg
X-Debbugs-Cc: Aurelien Jarno , debian-m...@lists.debian.org


Dear Maintainer,

ffmpeg 7:2.8-1 failed to build on mips/mipsel due to test failures.

I investigated the problem and it turns out to be caused by a compiler bug
that can be avoided by using '-fno-expensive-optimizations'.

Attached is a reduced test case:
$ ls
Makefile  main.c  test.c
$ make
cc -fPIC -O2 -fno-expensive-optimizations -c -o working.o test.c
cc -shared -o libworking.so working.o
cc -o working main.c -L. -lworking
cc -fPIC -O2 -c -o broken.o test.c
cc -shared -o libbroken.so broken.o
cc -o broken main.c -L. -lbroken
LD_LIBRARY_PATH=. ./working || true
TEST: 0x12A15
working
LD_LIBRARY_PATH=. ./broken || true
TEST: 0x1
broken

This works correctly with gcc-5 5.2.1-16, so it is a regression in 5.2.1-17.
The changelog reveals:
  [ Aurelien Jarno ]
  * Use --with-mips-plt on mips*.
  * Build for R2 ISA on mips, mips64 and mips64el.
  * Optimize for R2 ISA on mipsel.
  * Only apply mips-fix-loongson2f-nop on mipsel.

I assume one of these changes is responsible for this regression.

Best regards,
Andreas


-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: mipsel (mips)

Kernel: Linux 4.2.0-trunk-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages gcc-5 depends on:
ii  binutils  2.25.1-3
ii  cpp-5 5.2.1-17
ii  gcc-5-base5.2.1-17
ii  libc6 2.19-22
ii  libcc1-0  5.2.1-17
ii  libgcc-5-dev  5.2.1-17
ii  libgcc1   1:5.2.1-17
ii  libgmp10  2:6.0.0+dfsg-7
ii  libisl13  0.14-2
ii  libmpc3   1.0.3-1
ii  libmpfr4  3.1.3-1
ii  libstdc++65.2.1-17
ii  zlib1g1:1.2.8.dfsg-2+b1

Versions of packages gcc-5 recommends:
ii  libc6-dev  2.19-22

Versions of packages gcc-5 suggests:
pn  gcc-5-doc
pn  gcc-5-locales
pn  gcc-5-multilib   
pn  libasan2-dbg 
pn  libatomic1-dbg   
pn  libcilkrts5-dbg  
pn  libgcc1-dbg  
pn  libgomp1-dbg 
pn  libitm1-dbg  
pn  liblsan0-dbg 
pn  libmpx0-dbg  
pn  libquadmath-dbg  
pn  libtsan0-dbg 
pn  libubsan0-dbg

-- no debconf information
#include 
#include 

typedef struct Context {
int64_t out;
int64_t A;
int64_t B;
int64_t C;
int D;
} Context;

void init_tables(Context *c, int *table, int brightness, int contrast, int saturation);

int main()
{
int64_t out = 0;
Context c = { 0 };
int table[3] = {104597, 132201, 25675};
init_tables(, table, 0, 65536, 65536);

fprintf(stderr, "TEST: 0x%"PRIX64"\n", c.out);
if (c.out == 0x12A15) {
printf("working\n");
return 0;
}
printf("broken\n");
return 1;
}
CFLAGS += -fPIC -O2
LDFLAGS += -shared

all: working broken
LD_LIBRARY_PATH=. ./working || true
LD_LIBRARY_PATH=. ./broken || true

working.o:
$(CC) $(CFLAGS) -fno-expensive-optimizations -c -o working.o test.c

broken.o:
$(CC) $(CFLAGS) -c -o broken.o test.c

libworking.so: working.o
$(CC) $(LDFLAGS) -o libworking.so working.o

libbroken.so: broken.o
$(CC) $(LDFLAGS) -o libbroken.so broken.o

working: libworking.so
$(CC) -o working main.c -L. -lworking

broken: libbroken.so
$(CC) -o broken main.c -L. -lbroken

clean:
rm -f working.o libworking.so working broken.o libbroken.so broken
#include 

typedef struct Context {
int64_t out;
int64_t A;
int64_t B;
int64_t C;
int D;
} Context;

static uint8_t clip_uint8_c(int a)
{
if (a&(~0xFF)) return (-a)>>31;
else return a;
}
static void fill_table(uint8_t* table[256 + 2*256], const int elemsize,
   const int64_t inc, void *y_tab)
{
int i;
uint8_t *y_table = y_tab;
y_table -= elemsize * (inc >> 9);
for (i = 0; i < 256 + 2*256; i++) {
int64_t cb = clip_uint8_c(i-256)*inc;
table[i] = y_table + elemsize * (cb >> 16);
}
}
static void fill_gv_table(int table[256 + 2*256], const int elemsize, const int64_t inc)
{
int i;
int off = -(inc >> 9);
for (i = 0; i < 256 + 2*256; i++) {
int64_t cb = clip_uint8_c(i-256)*inc;
table[i] = elemsize * (off + (cb >> 16));
}
}
static uint16_t roundToInt16(int64_t f)
{
int r = (f + (1 << 15)) >> 16;
if (r < -0x7FFF)
return 0x8000;
else if (r > 0x7FFF)
return 0x7FFF;
else
return r;
}

uint8_t yuvTable[1024];
int table_gV[256 + 2*256];
uint8_t *table_rV[256 + 2*256];
uint8_t *table_gU[256 + 2*256];
uint8_t *table_bU[256 + 2*256];

__attribute__((cold)) void init_tables(Context *c, int *table, int brightness, int contrast, int saturation)
{
int i, dst, base, rbase;
const int bpp = c->D;
const int yoffs = brightness ? 384 : 326;

Bug#800318: gcc-5: [mips,mipsel] regression: miscompilation caused by -fexpensive-optimizations

2015-09-27 Thread Andreas Cadhalpun

Hi Aurelien,

On 27.09.2015 23:10, Aurelien Jarno wrote:
> On 2015-09-27 20:37, Andreas Cadhalpun wrote:
> Thanks for the detailed testcase. I have been able to reproduce the
> issue on mipsel, but not on mips.

Indeed, this test case only works on mipsel.
However, the same tests of ffmpeg's testsuite fail on mips, just with different
checksums. So it likely has the same cause.

>> This works correctly with gcc-5 5.2.1-16, so it is a regression in 5.2.1-17.
>> The changelog reveals:
>>   [ Aurelien Jarno ]
>>   * Use --with-mips-plt on mips*.
>>   * Build for R2 ISA on mips, mips64 and mips64el.
>>   * Optimize for R2 ISA on mipsel.
>>   * Only apply mips-fix-loongson2f-nop on mipsel.
>>
>> I assume one of these changes is responsible for this regression.
> 
> Indeed. At least on mipsel the issue is due to the use of
> -mtune=mips32r2 by default. I guess the best is to change it back to
> -mtune=mips32 until we better understand the issue.

OK.

> Does someone have time to look at the issue more in details? The
> generated code is quite different between -mtune=mips32 and
> -mtune=mips32r2 (not in terms of instructions, but in terms of
> sequencing).
> 
> As for mips, given I am not able to reproduce the issue, my guess is
> that it's due to the switch to -march=mips32r2, but I currently have
> no way to make sure.

A slightly larger test case for mips is compiling ffmpeg...

Best regards,
Andreas

Bug#785916: landell: Please update to GStreamer 1.x

2015-08-21 Thread Andreas Cadhalpun

Hi Sebastian,

On 21.08.2015 08:44, Sebastian Dröge wrote:
 On Fr, 2015-08-21 at 00:11 +0200, Andreas Cadhalpun wrote:
 I'm also going to request the removal of gstreamer0.10-ffmpeg,
 since it is the last reverse-dependency of src:libpostproc
 and I want to request it's removal.
 I hope you don't mind.
 
 Please go ahead, I didn't request removal of that one yet because I
 wanted to have all GStreamer 0.10 packages go away together but it
 doesn't really matter. Thanks!

It's gone now.

 I think gstreamer-hplugins can also be removed, because landell
 is it's only reverse-dependency.
 But I have no immediate interest in it's removal, so I leave
 that to someone else.
 
 Please request removal of that one while you're at it, there's no point
 in keeping that if landell is removed.

OK, I just requested it's removal. (#796419)

Best regards,
Andreas

Bug#795718: Don't include libav in stretch

2015-08-19 Thread Andreas Cadhalpun

Hi Moritz,

On 19.08.2015 15:53, Moritz Mühlenhoff wrote:
 On Tue, Aug 18, 2015 at 08:08:01PM +0200, Andreas Cadhalpun wrote:
 On 16.08.2015 14:27, Moritz Muehlenhoff wrote:
 It was decided to switch to ffmpeg for stretch and it's now in
 testing.

 Please remove libav from testing (or rather from unstable unless
 someone wants to continue to maintain it in unstable/experimental
 only)

 It has been planned to remove the libav source package from unstable,
 once the transition to ffmpeg is fully finished.
 Unfortunately this transition is currently blocked by two packages:
  * freerdp needs a new upstream version, but the maintainers are
unresponsive. (#788557)
  * vtk6 still has old binaries using Libav in testing, because
the uncoordinated vtk6.1 - vtk6.2 transition broke some
of its reverese dependencies. (#793621)
 
 Ok, thanks. Let's wait until these are sorted out.

I've now sent a minimal patch for freerdp to #788557.
Maybe you feel like NMUing?
I'm tempted to just ignore the vtk6 transition and request the
removal of libav once freerdp is fixed, since there is no progress
with that transition. And after all, it was not coordinated.

Best regards,
Andreas

Bug#788557: freerdp: FTBFS: list sub-command REMOVE_DUPLICATES requires list to be present

2015-08-19 Thread Andreas Cadhalpun

Control: tag -1 patch

Hi,

On 16.07.2015 20:23, Andreas Cadhalpun wrote:
 On 12.06.2015 19:15, Andreas Cadhalpun wrote:
 freerdp currently fails to build in sid/stretch with the following error:
 CMake Error at channels/client/CMakeLists.txt:33 (list):
   list sub-command REMOVE_DUPLICATES requires list to be present.
 
 This is fixed-upstream as part of commit [1].
 However, there are more issues, but current git HEAD compiles fine.
[...]
 1: 
 https://github.com/FreeRDP/FreeRDP/commit/1b663ceffe51008af7ae9749e5b7999b2f7d6698?diff=unified

Attached is a patch for the debian package backporting this commit
and additionally fixing winpr/libwinpr/CMakeLists.txt in a similar way.

This is now the last package not yet rebuilt for the ffmpeg-libav
transition [2], so please upload the fix as soon as possible.

Best regards,
Andreas


2: https://release.debian.org/transitions/html/ffmpeg-libav.html
diff --git a/debian/patches/0004_build-cmake-3.1-compatibility.patch b/debian/patches/0004_build-cmake-3.1-compatibility.patch
new file mode 100644
index 000..71df3ec
--- /dev/null
+++ b/debian/patches/0004_build-cmake-3.1-compatibility.patch
@@ -0,0 +1,78 @@
+From 1b663ceffe51008af7ae9749e5b7999b2f7d6698 Mon Sep 17 00:00:00 2001
+From: Bernhard Miklautz bernhard.mikla...@shacknet.at
+Date: Fri, 12 Dec 2014 18:26:45 +0100
+Subject: [PATCH] build: cmake 3.1 compatibility
+
+* fix problem with REMOVE_DUPLICATES on undefined lists
+* since 3.1 file(GLOB FILEPATHS RELATIVE .. returns single / instead of // as
+  previously - necessary adoptions for regex and matches done. Should
+	work with all cmake versions.
+
+Tested with 3.1.0-rc3
+
+Origin: upstream, https://github.com/FreeRDP/FreeRDP/commit/1b663ceffe51008af7ae9749e5b7999b2f7d6698?diff=unified
+
+diff --git a/channels/CMakeLists.txt b/channels/CMakeLists.txt
+index d9e8402..006e50f 100644
+--- a/channels/CMakeLists.txt
 b/channels/CMakeLists.txt
+@@ -202,8 +202,8 @@ set(FILENAME ChannelOptions.cmake)
+ file(GLOB FILEPATHS RELATIVE ${CMAKE_CURRENT_SOURCE_DIR} */${FILENAME})
+ 
+ foreach(FILEPATH ${FILEPATHS})
+-	if(${FILEPATH} MATCHES ^([^/]*)//${FILENAME})
+-		string(REGEX REPLACE ^([^/]*)//${FILENAME} \\1 DIR ${FILEPATH})
++	if(${FILEPATH} MATCHES ^([^/]*)/+${FILENAME})
++		string(REGEX REPLACE ^([^/]*)/+${FILENAME} \\1 DIR ${FILEPATH})
+ 		set(CHANNEL_OPTION)
+ 		include(${FILEPATH})
+ 		if(${CHANNEL_OPTION})
+diff --git a/channels/client/CMakeLists.txt b/channels/client/CMakeLists.txt
+index fc42466..a78cdeb 100644
+--- a/channels/client/CMakeLists.txt
 b/channels/client/CMakeLists.txt
+@@ -30,7 +30,9 @@ set(${MODULE_PREFIX}_SRCS
+ 	${CMAKE_CURRENT_SOURCE_DIR}/channels.c
+ 	${CMAKE_CURRENT_SOURCE_DIR}/channels.h)
+ 
++if(CHANNEL_STATIC_CLIENT_ENTRIES)
+ list(REMOVE_DUPLICATES CHANNEL_STATIC_CLIENT_ENTRIES)
++endif()
+ 
+ foreach(STATIC_ENTRY ${CHANNEL_STATIC_CLIENT_ENTRIES})
+ 	foreach(STATIC_MODULE ${CHANNEL_STATIC_CLIENT_MODULES})
+diff --git a/third-party/CMakeLists.txt b/third-party/CMakeLists.txt
+index 09b1fd4..610f35e 100644
+--- a/third-party/CMakeLists.txt
 b/third-party/CMakeLists.txt
+@@ -22,11 +22,11 @@
+ file(GLOB all_valid_subdirs RELATIVE ${CMAKE_CURRENT_SOURCE_DIR} */CMakeLists.txt)
+ 
+ foreach(dir ${all_valid_subdirs})
+-	if(${dir} MATCHES ^([^/]*)//CMakeLists.txt)
+-		string(REGEX REPLACE ^([^/]*)//CMakeLists.txt \\1 dir_trimmed ${dir})
++	if(${dir} MATCHES ^([^/]*)/+CMakeLists.txt)
++		string(REGEX REPLACE ^([^/]*)/+CMakeLists.txt \\1 dir_trimmed ${dir})
+ 		message(STATUS Adding third-party component ${dir_trimmed})
+ 		add_subdirectory(${dir_trimmed})
+ 	endif()
+ endforeach(dir)
+ 
+-set(THIRD_PARTY_INCLUDES ${THIRD_PARTY_INCLUDES} PARENT_SCOPE)
+\ No newline at end of file
++set(THIRD_PARTY_INCLUDES ${THIRD_PARTY_INCLUDES} PARENT_SCOPE)
+diff --git a/winpr/libwinpr/CMakeLists.txt b/winpr/libwinpr/CMakeLists.txt
+index fdb2bda..7e1603b 100644
+--- a/winpr/libwinpr/CMakeLists.txt
 b/winpr/libwinpr/CMakeLists.txt
+@@ -32,8 +32,8 @@ set(FILENAME ModuleOptions.cmake)
+ file(GLOB FILEPATHS RELATIVE ${CMAKE_CURRENT_SOURCE_DIR} */${FILENAME})
+ 
+ foreach(FILEPATH ${FILEPATHS})
+-	if(${FILEPATH} MATCHES ^([^/]*)//${FILENAME})
+-		string(REGEX REPLACE ^([^/]*)//${FILENAME} \\1 ${MODULE_PREFIX}_SUBMODULE ${FILEPATH})
++	if(${FILEPATH} MATCHES ^([^/]*)/+${FILENAME})
++		string(REGEX REPLACE ^([^/]*)/+${FILENAME} \\1 ${MODULE_PREFIX}_SUBMODULE ${FILEPATH})
+ 		set(${MODULE_PREFIX}_SUBMODULES ${${MODULE_PREFIX}_SUBMODULES} ${${MODULE_PREFIX}_SUBMODULE})
+ 	endif()
+ endforeach(FILEPATH)
diff --git a/debian/patches/series b/debian/patches/series
index c6fa6bb..40d6e0a 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -10,3 +10,4 @@
 0001_fix-cmdline-parser.patch
 0002_handle-old-style-cmdline-options.patch
 0003_copy-data-when-adding-glyph-to-cache.patch
+0004_build-cmake-3.1-compatibility.patch

Bug#795718: Don't include libav in stretch

2015-08-18 Thread Andreas Cadhalpun

Hi Moritz,

On 16.08.2015 14:27, Moritz Muehlenhoff wrote:
 It was decided to switch to ffmpeg for stretch and it's now in
 testing.
 
 Please remove libav from testing (or rather from unstable unless
 someone wants to continue to maintain it in unstable/experimental
 only)

It has been planned to remove the libav source package from unstable,
once the transition to ffmpeg is fully finished.
Unfortunately this transition is currently blocked by two packages:
 * freerdp needs a new upstream version, but the maintainers are
   unresponsive. (#788557)
 * vtk6 still has old binaries using Libav in testing, because
   the uncoordinated vtk6.1 - vtk6.2 transition broke some
   of its reverese dependencies. (#793621)

Help with any of these would be much appreciated.

If you just want to file a removal bug: I think the libpostproc
source package can go already. ;)

Best regards,
Andreas

Bug#794817: Should mplayer2 be removed from unstable?

2015-08-13 Thread Andreas Cadhalpun

On 07.08.2015 03:19, Sebastian Ramacher wrote:
 On 2015-08-06 23:05:58, Andreas Cadhalpun wrote:
 Unless someone objects, I'll reassign this bug to ftp.debian.org for
 removal soon.
 
 Before doing so, please file bugs against packages (Build-)Depending on
 mplayer2 to switch back to mplayer:
 
 Checking reverse dependencies...
 # Broken Depends:
 jajuk: jajuk
 kphotoalbum: kphotoalbum
 
 # Broken Build-Depends:
 jajuk: mplayer2

I've filed #795418 for jajuk and #795419 for kphotoalbum and made them block
this bug.

Best regards,
Andreas

Bug#794817: Should mplayer2 be removed from unstable?

2015-08-06 Thread Andreas Cadhalpun

Package: mplayer2
Severity: serious

I think mplayer2 should be removed because:
 * It is dead upstream (even the homepage is gone).
 * mplayer is back in Debian, which can replace mplayer2.

Unless someone objects, I'll reassign this bug to ftp.debian.org for
removal soon.

Best regards,
Andreas


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#793557: clamtk in testing

2015-07-26 Thread Andreas Cadhalpun

Control: severity -1 important
Control: tags -1 = unreproducible moreinfo

Hi Carlos,

On 25.07.2015 04:10, Carlos Kosloff wrote:
 * Specs
 
 Using KDE desktop, on a Toshiba laptop with amd64 architecture.

Much more useful would be the information collected by reportbug:
$ reportbug --template clamtk

 * What caused the problem
 
 After a dist-upgrade on 2015/07/24 clamtk does not launch.

What packages were upgraded?
Can you post the relevant parts of /var/log/dpkg.log from that upgrade?

 * Steps taken to resolve the problem
 
 Reinstalled.
 Rebooted computer.
 Attempted to launch from CLI.
 As user:
 command clamtk reports illegal instruction.

This works fine here, thus I'm downgrading the severity.
clamtk is just a perl program, so any illegal instruction error is probably
caused by perl.

What instructions does your CPU support?
Please provide the output of:
$ cat /proc/cpuinfo

A backtrace of the crash would most certainly be helpful as well.
Please provide the output of the following command (after installing gdb):
$ gdb --batch -ex r -ex 'bt full' -ex q --args perl /usr/bin/clamtk

 As root:
 No protocol specified
 Gtk-WARNING **: cannot open display: :0 at 
 /usr/lib/x86_64-linux-gnu/perl5/5.20/Gtk2.pm line 126.

I don't think running clamtk as root is a good idea.

Best regards,
Andreas


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#792992: gazebo: FTBFS with Bullet 2.83.5

Control: tags -1 fixed-upstream patch

Hi,

On 20.07.2015 13:45, Markus Koschany wrote:
 gazebo fails to build from source with the latest version of Bullet,
 2.83.5. Please update your package.

This is fixed upstream [1][2]. Attached is a patch for the debian package.

 I am sorry for the short notice of this bug report because I became
 only recently aware of gazebo being a new reverse dependency of
 Bullet. The upload to unstable happened in May but the package passed
 the NEW queue only yesterday.

Preparing library transitions in experimental avoids such problems.

Best regards,
Andreas


1: 
https://bitbucket.org/osrf/gazebo/commits/53bd6fdb10e57d8a70353dd02a48e2ff8a8c7f4b
2: 
https://bitbucket.org/osrf/gazebo/commits/893065d361d16cd39dfe25716408e36543272e24

--- /dev/null
+++ b/debian/patches/0010-backport-bullet-fix.patch
@@ -0,0 +1,114 @@
+Description: Use btHingeAccumulatedAngleConstraint if bullet 2.83 or greater is available
+Author: Steve Peters scpet...@osrfoundation.org
+Origin: https://bitbucket.org/osrf/gazebo/commits/53bd6fdb10e57d8a70353dd02a48e2ff8a8c7f4b
+
+diff --git a/cmake/SearchForStuff.cmake b/cmake/SearchForStuff.cmake
+--- a/cmake/SearchForStuff.cmake
 b/cmake/SearchForStuff.cmake
+@@ -379,6 +379,10 @@
+ add_definitions( -DLIBBULLET_VERSION=0.0 )
+ BUILD_WARNING (Bullet  2.82 not found, for bullet physics engine option, please install libbullet2.82-dev.)
+   endif()
++  
++  if (BULLET_VERSION VERSION_GREATER 2.82)
++add_definitions( -DLIBBULLET_VERSION_GT_282 )
++  endif()
+ 
+ else (PKG_CONFIG_FOUND)
+   set (BUILD_GAZEBO OFF CACHE INTERNAL Build Gazebo FORCE)
+diff --git a/gazebo/physics/bullet/BulletHingeJoint.cc b/gazebo/physics/bullet/BulletHingeJoint.cc
+--- a/gazebo/physics/bullet/BulletHingeJoint.cc
 b/gazebo/physics/bullet/BulletHingeJoint.cc
+@@ -104,7 +104,11 @@
+   // If both links exist, then create a joint between the two links.
+   if (bulletChildLink  bulletParentLink)
+   {
++#ifdef LIBBULLET_VERSION_GT_282
++this-bulletHinge = new btHingeAccumulatedAngleConstraint(
++#else
+ this-bulletHinge = new btHingeConstraint(
++#endif
+ *(bulletChildLink-GetBulletLink()),
+ *(bulletParentLink-GetBulletLink()),
+ BulletTypes::ConvertVector3(pivotChild),
+@@ -116,7 +120,11 @@
+   // and the world.
+   else if (bulletChildLink)
+   {
++#ifdef LIBBULLET_VERSION_GT_282
++this-bulletHinge = new btHingeAccumulatedAngleConstraint(
++#else
+ this-bulletHinge = new btHingeConstraint(
++#endif
+ *(bulletChildLink-GetBulletLink()),
+ BulletTypes::ConvertVector3(pivotChild),
+ BulletTypes::ConvertVector3(axisChild));
+@@ -125,7 +133,11 @@
+   // and the world.
+   else if (bulletParentLink)
+   {
++#ifdef LIBBULLET_VERSION_GT_282
++this-bulletHinge = new btHingeAccumulatedAngleConstraint(
++#else
+ this-bulletHinge = new btHingeConstraint(
++#endif
+ *(bulletParentLink-GetBulletLink()),
+ BulletTypes::ConvertVector3(pivotParent),
+ BulletTypes::ConvertVector3(axisParent));
+@@ -209,7 +221,18 @@
+ {
+   math::Angle result;
+   if (this-bulletHinge)
+-result = this-bulletHinge-getHingeAngle() - this-angleOffset;
++  {
++#ifdef LIBBULLET_VERSION_GT_282
++btHingeAccumulatedAngleConstraint* hinge =
++  static_castbtHingeAccumulatedAngleConstraint*(this-bulletHinge);
++if (hinge)
++  result = hinge-getAccumulatedHingeAngle();
++else
++#else
++  result = this-bulletHinge-getHingeAngle();
++#endif
++result -= this-angleOffset;
++  }
+   return result;
+ }
+ 
+diff --git a/test/integration/joint_revolute.cc b/test/integration/joint_revolute.cc
+--- a/test/integration/joint_revolute.cc
 b/test/integration/joint_revolute.cc
+@@ -16,6 +16,7 @@
+ */
+ 
+ #include ServerFixture.hh
++#include gazebo/gazebo_config.h
+ #include gazebo/physics/physics.hh
+ #include SimplePendulumIntegrator.hh
+ #include helper_physics_generator.hh
+@@ -99,12 +100,15 @@
+ 
+ void JointTestRevolute::WrapAngle(const std::string _physicsEngine)
+ {
+-  /// \TODO: bullet hinge angles are wrapped (#1074)
++#ifndef LIBBULLET_VERSION_GT_282
++  /// bullet hinge angles are wrapped for 2.82 and less
+   if (_physicsEngine == bullet)
+   {
+-gzerr  Aborting test for bullet, see issues #1074.\n;
++gzerr  Aborting test for bullet, angle wrapping requires bullet 2.83
++   std::endl;
+ return;
+   }
++#endif
+ 
+   // Load an empty world
+   Load(worlds/empty.world, true, _physicsEngine);
+@@ -127,6 +131,7 @@
+ ASSERT_TRUE(joint != NULL);
+ 
+ // set velocity to 2 pi rad/s and step forward 1.5 seconds.
++// angle should reach 3 pi rad.
+ double vel = 2*M_PI;
+ unsigned int stepSize = 50;
+ unsigned int stepCount = 30;
--- /dev/null
+++ b/debian/patches/0011-backport-bullet-fix2.patch
@@ -0,0 +1,37 @@
+Description: Fix build when compiled against bullet 2.83
+Author: Steve Peters

Bug#793085: ffmpeg: removal of ffmpeg makes files disappear from libav-tools

Control: tags -1 pending
Control: severity -1 important

Hi,

On 21.07.2015 13:58, Reinhard Tartler wrote:
 On Tue, Jul 21, 2015, 4:51 AM Andreas Beckmann a...@debian.org 
 mailto:a...@debian.org wrote:
 This is a serious bug violating policy 7.6, see
 
 https://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces
 and also see the footnote that describes this incorrect behavior
 https://www.debian.org/doc/debian-policy/footnotes.html#f53

Policy 7.6.1 says:
Normally, Breaks should be used in conjunction with Replaces.

So that's not a 'must' and thus not a release critical bug.

 Well, that was actually the purpose, the idea is to replace qt-faststart from
 libav-tools, and the problem is rather transitional until libav-tools is 
 uninstalled.
 I guess the bug is that we don't ensure that this actually takes place.
 I've therefore made two commits in git:
 
 - one that tightens the Breaks relationship as suggested

That one fixes this bug, so I'm setting the pending tag.

 - one that renames libav-tools-links to libav-tools in src:ffmpeg.

That's fine for me if you prefer it that way.
I just pushed a commit renaming d/libav-tools-links.links to 
d/libav-tools.links,
so that the links don't get lost.

 This should ensure a comprehensive transition.
 
 Feedback on these two commits are welcome. In particular, I saw a comment 
 suggesting
 to transition command-line interface separately from the library interfaces.
 While this may make the transition slightly smaller, the benefits don't 
 outweigh
 the confusion here, and would rather suggest to transition them both at the 
 same
 time with the 2nd commit mentioned above.

The library transition is already happening, so changing that now is fine.

Best regards,
Andreas


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#792992: gazebo: FTBFS with Bullet 2.83.5

Hi Markus,

On 21.07.2015 17:50, Markus Koschany wrote:
 Am 21.07.2015 um 17:38 schrieb Andreas Cadhalpun:
 On 20.07.2015 13:45, Markus Koschany wrote:
 gazebo fails to build from source with the latest version of Bullet,
 2.83.5. Please update your package.

 This is fixed upstream [1][2]. Attached is a patch for the debian package.
 
 Great. Thanks.

:-)

 I am sorry for the short notice of this bug report because I became
 only recently aware of gazebo being a new reverse dependency of
 Bullet. The upload to unstable happened in May but the package passed
 the NEW queue only yesterday.

 Preparing library transitions in experimental avoids such problems.
 
 Yup, but since Gazebo has never been in testing, this issue simply fell
 through the cracks and shouldn't cause any delay for the transition at all.

I see. I was just rather surprised to see gazebo failing during the
libav - ffmpeg transition, while it worked fine in my rebuild test a few
days ago.

Best regards,
Andreas


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#793131: avbin: FTBFS: fatal error: avformat.h: No such file or directory

Package: avbin
Version: 7-4
Tags: patch
Severity: serious
Justification: fails to build from source (but built successfully in the past)
Tags: sid stretch

Dear maintainer,

the libav - ffmpeg transition is ongoing and the headers are now installed
in the multi-arch locations. Thus compiling with '-I/usr/include/libavformat'
doesn't work around the wrong include paths anymore.

Attached patch changes them to the full paths.

I'm sorry for not noticing this earlier (my build chroot was unclean...).

Best regards,
Andreas
--- a/debian/patches/libav.patch
+++ b/debian/patches/libav.patch
@@ -4,17 +4,11 @@ Last-Update: 2014-03-17
 
 --- avbin-7.orig/src/avbin.c
 +++ avbin-7/src/avbin.c
-@@ -25,9 +25,11 @@
- #include avbin.h
- 
- /* ffmpeg */
--#include libavformat/avformat.h
--#include libavcodec/avcodec.h
--#include libavutil/avutil.h
-+#include avformat.h
-+#include avcodec.h
-+#include avutil.h
-+#include swscale.h
+@@ -28,6 +28,8 @@
+ #include libavformat/avformat.h
+ #include libavcodec/avcodec.h
+ #include libavutil/avutil.h
++#include libswscale/swscale.h
 +#include libavutil/dict.h
  
  struct _AVbinFile {

Bug#793089: dvbcut: FTBFS against ffmpeg

Control: tags -1 patch

Hi,

Sorry for not noticing this earlier (my build chroot was unclean...).

On 21.07.2015 11:05, Sebastian Ramacher wrote:
 dvbcut failed to build on the buildds for the libav-ffmpeg transition:
 | g++ -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wall 
 -DPACKAGE_NAME=\\ -DPACKAGE_TARNAME=\\ -DPACKAGE_VERSION=\\ 
 -DPACKAGE_STRING=\\ -DPACKAGE_BUGREPORT=\\ -DPACKAGE_URL=\\ 
 -DHAVE_LIB_SWSCALE=1 -DHAVE_LIB_MAD=1 -DHAVE_LIB_A52=1 -DHAVE_LIB_AO=1 
 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 
 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 
 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_AO_AO_H=1 -DHAVE_MAD_H=1 
 -DHAVE_STDINT_H=1 -DHAVE_A52DEC_A52_H=1 -DHAVE_STDLIB_H=1 -DHAVE_UNISTD_H=1 
 -DHAVE_SYS_PARAM_H=1 -DHAVE_GETPAGESIZE=1 -DHAVE_MMAP=1 
 -D__STDC_LIMIT_MACROS=1 -D__STDC_CONSTANT_MACROS=1 -D_FILE_OFFSET_BITS=64 
 -D_FORTIFY_SOURCE=2 -I/usr/include -I/usr/include/ffmpeg -I/include 
 -DQT_SHARED -DQT3_SUPPORT -DQT_SHARED -I/usr/include/qt4 
 -I/usr/include/qt4/Qt3Support -I/usr/include/qt4 -I/usr/include/qt4/QtNetwork 
 -I/usr/include/qt4 -I/usr/include/qt4/QtSql -I/usr/include/qt4 
 -I/usr/include/qt4/QtGui 
 -
I/usr/include/qt4 -I/usr/include/qt4/QtXml -I/usr/include/qt4 
-I/usr/include/qt4/QtCore  -I. -D_FORTIFY_SOURCE=2 -I/usr/include 
-I/usr/include/ffmpeg -I/include -DQT_SHARED -DQT3_SUPPORT -DQT_SHARED 
-I/usr/include/qt4 -I/usr/include/qt4/Qt3Support -I/usr/include/qt4 
-I/usr/include/qt4/QtNetwork -I/usr/include/qt4 -I/usr/include/qt4/QtSql 
-I/usr/include/qt4 -I/usr/include/qt4/QtGui -I/usr/include/qt4 
-I/usr/include/qt4/QtXml -I/usr/include/qt4 -I/usr/include/qt4/QtCore  -I.  -c 
-o differenceimageprovider.o differenceimageprovider.cpp
 | In file included from differenceimageprovider.cpp:24:0:
 | avframe.h:28:21: fatal error: swscale.h: No such file or directory
 |  #include swscale.h
 |  ^
 | compilation terminated.

This is caused by the headers now being installed in the multi-arch locations.
Attached is a patch fixing this by using the full libswscale/swscale.h path.

Best regards,
Andreas
--- /dev/null
+++ b/debian/patches/fix_ffmpeg_includes.patch
@@ -0,0 +1,62 @@
+Description: Use full include path for FFmpeg libraries
+
+Author: Andreas Cadhalpun andreas.cadhal...@googlemail.com
+Last-Update: 2015-07-21
+
+--- dvbcut-0.5.4+svn178.orig/src/avframe.h
 dvbcut-0.5.4+svn178/src/avframe.h
+@@ -25,7 +25,7 @@ extern C {
+ #include libavcodec/avcodec.h
+ #include libavutil/mem.h
+ #ifdef HAVE_LIB_SWSCALE
+-#include swscale.h
++#include libswscale/swscale.h
+ #endif
+ }
+ 
+--- dvbcut-0.5.4+svn178.orig/src/lavfmuxer.cpp
 dvbcut-0.5.4+svn178/src/lavfmuxer.cpp
+@@ -19,8 +19,8 @@
+ /* $Id$ */
+ 
+ extern C {
+-#include avformat.h
+-#include avcodec.h
++#include libavformat/avformat.h
++#include libavcodec/avcodec.h
+ }
+ #include cstring
+ #include utility
+--- dvbcut-0.5.4+svn178.orig/src/lavfmuxer.h
 dvbcut-0.5.4+svn178/src/lavfmuxer.h
+@@ -22,7 +22,7 @@
+ #define _DVBCUT_LAVFMUXER_H
+ 
+ extern C {
+-#include avformat.h
++#include libavformat/avformat.h
+ }
+ 
+ #include mpgfile.h
+--- dvbcut-0.5.4+svn178.orig/src/main.cpp
 dvbcut-0.5.4+svn178/src/main.cpp
+@@ -33,7 +33,7 @@
+ 
+ #include qapplication.h
+ extern C {
+-#include avformat.h
++#include libavformat/avformat.h
+ }
+ #include qimage.h
+ #include qsettings.h
+--- dvbcut-0.5.4+svn178.orig/src/streamdata.h
 dvbcut-0.5.4+svn178/src/streamdata.h
+@@ -24,7 +24,7 @@
+ #include string
+ #include list
+ extern C {
+-#include avformat.h
++#include libavformat/avformat.h
+ }
+ 
+ #include port.h
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -8,3 +8,4 @@ bug753347_initialize-pkt-variable-in-mpgfile__recodevideo-to-avoid-crash.patch
 715843_do-not-access-argv-beyond-last-item.patch
 753369_mplayer2-uses-different-indices-for-audio-streams.patch
 avoid-PATH_MAX-macro.patch
+fix_ffmpeg_includes.patch

Bug#793015: taoframework: FTBFS, needs update of hardcoded sonames

2015-07-20 Thread Andreas Cadhalpun

Source: taoframework
Version: 2.1.svn20090801-10
Tags: patch
Severity: serious
Justification: fails to build from source

Dear maintainer,

the ffmpeg-libav transition [1] is ongoing and thus the hardcoded sonames
in taoframework need to be updated.
Please apply attached patch doing that.

Best regards,
Andreas

1: https://release.debian.org/transitions/html/ffmpeg-libav.html
--- a/debian/patches/200_libavcodec_update.diff
+++ b/debian/patches/200_libavcodec_update.diff
@@ -7,7 +7,7 @@ Index: taoframework/src/Tao.FFmpeg/Tao.FFmpeg.dll.config
  dllmap dll=avcodec-51.dll os=windows target=avcodec-51.dll /
  dllmap dll=avcodec-51.dll os=osx target=libavcodec.so.51 /
 -dllmap dll=avcodec-51.dll os=!windows,osx target=libavcodec.so.51 /
-+dllmap dll=avcodec-51.dll os=!windows,osx target=libavcodec.so.56 /
++dllmap dll=avcodec-51.dll os=!windows,osx target=libavcodec-ffmpeg.so.56 /
  
  dllmap dll=avformat-52.dll os=windows target=avformat-52.dll /
  dllmap dll=avformat-52.dll os=osx target=libavformat.so.52 /
--- a/debian/patches/200_libavformat_update
+++ b/debian/patches/200_libavformat_update
@@ -7,7 +7,7 @@ Index: taoframework/src/Tao.FFmpeg/Tao.FFmpeg.dll.config
  dllmap dll=avformat-52.dll os=windows target=avformat-52.dll /
  dllmap dll=avformat-52.dll os=osx target=libavformat.so.52 /
 -dllmap dll=avformat-52.dll os=!windows,osx target=libavformat.so.52 /
-+dllmap dll=avformat-52.dll os=!windows,osx target=libavformat.so.56 /
++dllmap dll=avformat-52.dll os=!windows,osx target=libavformat-ffmpeg.so.56 /
  
  dllmap dll=avutil-49.dll os=windows target=avutil-49.dll /
  dllmap dll=avutil-49.dll os=osx target=libavutil.so.49 /
--- a/debian/patches/200_libavutil_update.diff
+++ b/debian/patches/200_libavutil_update.diff
@@ -10,7 +10,7 @@ Index: taoframework/src/Tao.FFmpeg/Tao.FFmpeg.dll.config
  dllmap dll=avutil-49.dll os=windows target=avutil-49.dll /
  dllmap dll=avutil-49.dll os=osx target=libavutil.so.49 /
 -dllmap dll=avutil-49.dll os=!windows,osx target=libavutil.so.49 /
-+dllmap dll=avutil-49.dll os=!windows,osx target=libavutil.so.54 /
++dllmap dll=avutil-49.dll os=!windows,osx target=libavutil-ffmpeg.so.54 /
  
  dllmap dll=swscale-0.dll os=windows target=swscale-0.dll /
  dllmap dll=swscale-0.dll os=osx target=libswscale.so.0 /
--- a/debian/patches/200_libswscale_update
+++ b/debian/patches/200_libswscale_update
@@ -7,5 +7,5 @@ Index: taoframework/src/Tao.FFmpeg/Tao.FFmpeg.dll.config
  dllmap dll=swscale-0.dll os=windows target=swscale-0.dll /
  dllmap dll=swscale-0.dll os=osx target=libswscale.so.0 /
 -dllmap dll=swscale-0.dll os=!windows,osx target=libswscale.so.0 /
-+dllmap dll=swscale-0.dll os=!windows,osx target=libswscale.so.3 /
++dllmap dll=swscale-0.dll os=!windows,osx target=libswscale-ffmpeg.so.3 /
  /configuration

Bug#788557: freerdp: FTBFS: list sub-command REMOVE_DUPLICATES requires list to be present

2015-07-16 Thread Andreas Cadhalpun

Control: tag -1 fixed-upstream

Hi,

On 12.06.2015 19:15, Andreas Cadhalpun wrote:
 freerdp currently fails to build in sid/stretch with the following error:
 CMake Error at channels/client/CMakeLists.txt:33 (list):
   list sub-command REMOVE_DUPLICATES requires list to be present.

This is fixed-upstream as part of commit [1].
However, there are more issues, but current git HEAD compiles fine.
(It just runs into a test failure...)

Best regards,
Andreas

1: 
https://github.com/FreeRDP/FreeRDP/commit/1b663ceffe51008af7ae9749e5b7999b2f7d6698?diff=unified


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#792493: xmms2: FTBFS: uses obsolete ruby Config::CONFIG

2015-07-15 Thread Andreas Cadhalpun

Source: xmms2
Version: 0.8+dfsg-12
Tags: patch
Severity: serious
Justification: fails to build from source

Dear Maintainer,

xmms2 fails to build in sid currently [1]:
Checking for program ruby : 
/usr/bin/ruby2.2 
ruby  : 1.8.0 
command ['/usr/bin/ruby2.2', '-rrbconfig', '-e', puts 
Config::CONFIG['archdir']] returned 1
debian/rules:39: recipe for target 'override_dh_auto_configure' failed

Attached patch fixes this by using RbConfig instead of the obsolete Config.

Best regards,
Andreas


1: https://reproducible.debian.net/rb-pkg/unstable/amd64/xmms2.html
--- /dev/null
+++ b/debian/patches/ruby2.2-RbConfig.patch
@@ -0,0 +1,16 @@
+Description: Use RbConfig instead of Config
+
+Author: Andreas Cadhalpun andreas.cadhal...@googlemail.com
+Last-Update: 2015-07-15
+
+--- a/waflib/Tools/ruby.py
 b/waflib/Tools/ruby.py
+@@ -45,7 +45,7 @@ def check_ruby_ext_devel(self):
+ 	def read_out(cmd):
+ 		return Utils.to_list(self.cmd_and_log([self.env.RUBY,'-rrbconfig','-e',cmd]))
+ 	def read_config(key):
+-		return read_out('puts Config::CONFIG[%r]'%key)
++		return read_out('puts RbConfig::CONFIG[%r]'%key)
+ 	ruby=self.env['RUBY']
+ 	archdir=read_config('archdir')
+ 	cpppath=archdir
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -14,3 +14,4 @@ fix-libmodplug-include.patch
 samba-with-pkg-cfg.patch
 ruby2-multiarch.patch
 libav10.patch
+ruby2.2-RbConfig.patch

Bug#788559: [Help] Cmake detection problem (Was: Bug#788559: vxl: FTBFS: fatal error: libc.h: No such file or directory)

2015-07-15 Thread Andreas Cadhalpun

Control: tag -1 patch

Eureka!

On 25.06.2015 11:27, Andreas Tille wrote:
 I've checked this issue and i boils down to the fact that the header
 file in question is included only conditional.  Unfortunately this
 condition is not properly set.  Cmake is supposed to detect an existing
 libc.h header file in dcmtk:
 
 $ grep -R HAVE_LIBC_H | grep CHECK_INCLUDE_FILE
 v3p/dcmtk/CMakeLists.txt:CHECK_INCLUDE_FILE( libc.hDCMTK_HAVE_LIBC_H )
 
 But this does not seem to work properly.  Any idea what might went
 wrong here?

The problem is not limited to DCMTK_HAVE_LIBC_H:
  # The configuration has changed, so reset the stored variables to
  # force them to be recomputed
  #
  FOREACH( var
DCMTK_DCM_DICT_DEFAULT_PATH
[...]
DCMTK_HAVE_LIBC_H
[...]
HAVE_DCMTK_SIZEOF_LONG )  # Created indirectly by CHECK_TYPE_SIZE
SET( ${var} ${var} )  #  -- This is the problem!
  ENDFOREACH( var )

It tries to reset the variables, but it sets their value to their name.
Apparently this worked (accidentally?) with previous cmake versions, but
doesn't work anymore.
Instead I think it should just unset the variables.
A patch doing that (and thus fixing the FTBFS) is attached.

Best regards,
Andreas

--- a/debian/patches/series
+++ b/debian/patches/series
@@ -18,3 +18,4 @@ opencl_kfreebsd.patch
 shared-lib-without-dependency-information.patch
 #compflags.patch
 libav10.patch
+unset-cmake-variables.patch
--- /dev/null
+++ b/debian/patches/unset-cmake-variables.patch
@@ -0,0 +1,19 @@
+Description: Unset Cmake variables on configuration change
+ Previously they have been set to arbitrary values, but that confuses
+ recent versions of cmake.
+
+Author: Andreas Cadhalpun andreas.cadhal...@googlemail.com
+Bug-Debian: https://bugs.debian.org/788559
+Last-Update: 2015-07-15
+
+--- a/v3p/dcmtk/CMakeLists.txt
 b/v3p/dcmtk/CMakeLists.txt
+@@ -113,7 +113,7 @@ ELSE( ${DCMTK_CONFIG_SERIAL_CURRENT} MAT
+ DCMTK_SIZEOF_LONG
+ DCMTK_CMAKE_COMPILER_IS_GNUCXX_2XX
+ HAVE_DCMTK_SIZEOF_LONG )  # Created indirectly by CHECK_TYPE_SIZE
+-SET( ${var} ${var} )
++UNSET( ${var} )
+   ENDFOREACH( var )
+ 
+   # Record that we've done the new config.

Bug#788557: freerdp: FTBFS: list sub-command REMOVE_DUPLICATES requires list to be present

2015-06-12 Thread Andreas Cadhalpun

Source: freerdp
Version: 1.1.0~git20140921.1.440916e+dfsg1-4
Severity: serious
Justification: fails to build from source

Dear Maintainer,

freerdp currently fails to build in sid/stretch with the following error:
CMake Error at channels/client/CMakeLists.txt:33 (list):
  list sub-command REMOVE_DUPLICATES requires list to be present.

A full build log can be obtained from the reproducibility rebuild [1].

Best regards
Andreas


1: 
https://reproducible.debian.net/rbuild/unstable/amd64/freerdp_1.1.0~git20140921.1.440916e+dfsg1-4.rbuild.log


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#788559: vxl: FTBFS: fatal error: libc.h: No such file or directory

2015-06-12 Thread Andreas Cadhalpun

Source: vxl
Version: 1.17.0.dfsg-1
Severity: serious
Justification: fails to build from source

Dear Maintainer,

vxl currently fails to build in sid/stretch with the following error:
[  0%] Building CXX object vcl/CMakeFiles/vcl.dir/vcl_cassert.o
In file included from 
/tmp/buildd/vxl-1.17.0.dfsg/v3p/dcmtk/ofstd/include/ofcond.h:32:0,
 from 
/tmp/buildd/vxl-1.17.0.dfsg/v3p/dcmtk/ofstd/libsrc/ofcond.cxx:27:
/tmp/buildd/vxl-1.17.0.dfsg/v3p/dcmtk/ofstd/include/ofstring.h:57:18: fatal 
error: libc.h: No such file or directory
 #include libc.h
  ^
compilation terminated.

Best regards,
Andreas


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#785203: clamav-freshclam: ERROR: Can't create temporary directory

2015-05-13 Thread Andreas Cadhalpun

Control: forcemerge 777219 -1

Hi Rob,

On 13.05.2015 14:56, Rob Mason wrote:
 This error appears against 'freshclam', but I believe its related to
 clamav-base.
 
 Following a dist-upgrade of clamav, the /var/lib/clamav directory
 ownership is reset to 'clamav'. This behaviour is incorrect if clamav
 has been configured to run under a different UID such as 'defang'.
 
 My scenario:
 
 In /etc/clamd.conf, 'User' and 'LocalSocketGroup' are set to 'defang'.
  'AllowSupplementaryGroups' is set to 'false'

This is OK.

 In /etc/freshclam.conf, 'DatabaseOwner' is set to 'defang'

This should not be necessary.

 Following an 'apt-get dist-upgrade' the output of
 '/var/log/clamav/freshclam.log' shows:
 
 Wed May 13 13:14:42 2015 - Update process terminated
 Wed May 13 13:14:46 2015 - --
 Wed May 13 13:14:46 2015 - freshclam daemon 0.98.7 (OS: linux-gnu, ARCH: 
 x86_64, CPU: x86_64)
 Wed May 13 13:14:46 2015 - ERROR: Can't create temporary directory 
 /var/lib/clamav/clamav-9cf028fe3f1d39c22fb44fa7e4f18bdf.tmp
 Wed May 13 13:14:46 2015 - Hint: The database directory must be writable for 
 UID 112 or GID 114
 Wed May 13 13:14:46 2015 - --
 
 Workaround is to manually change ownership back to the actual
 DatabaseOwner following a dist-upgrade.

The short answer is that a DatabaseOwner different than clamav
is not supported by the Debian package, because it requires to
manually chown /var/lib/clamav, which should not be done.

This has already been discussed in bug #777219 [1], so I'm
merging it with this bug.

If you think there is a convincing reason to support changing
DatabaseOwner, please let us know and we can unarchive/reopen
bug #777219.

Best regards,
Andreas


1: https://bugs.debian.org/777219


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#783720: clamav-daemon does not honour Local* with systemd

2015-05-01 Thread Andreas Cadhalpun

Hi Sebastian,

On 01.05.2015 23:11, Sebastian Andrzej Siewior wrote:
 On 2015-04-29 23:03:49 [+0200], Andreas Cadhalpun wrote:
 The options
LocalSocket /var/run/clamav/clamd.ctl.change
LocalSocketGroup nobody
LocalSocketMode 600
 
 same options
 
 I just pushed a fix for this.
 It seems to work as intended, but additional testing would be nice. ;)
 
 now I see in /etc/systemd/system/clamav-daemon.socket.d/extend.conf:
 [Socket]
 ListenStream=
 SocketUser=clamav
 ListenStream=/var/run/clamav/clamd.ctl.change
 SocketGroup=nobody
 SocketMode=600

That's exactly what should be there.

 and ls gives me:
 ls -lah /var/run/clamav/
 total 0
 drwxr-xr-x  2 clamav clamav  80 May  1 22:59 .
 drwxr-xr-x 16 root   root   560 May  1 21:28 ..
 srw-rw-rw-  1 clamav clamav   0 May  1 21:28 clamd.ctl
 srw---  1 root   root 0 May  1 22:59 clamd.ctl.change
 
 which means the user  group is wrong.

That's caused by the socket not being stopped before changing.
Running 'systemctl stop clamav-daemon.socket' followed by
'systemctl start clamav-daemon.socket' makes it work.

I just pushed a commit disabling the clamav-daemon.socket in prerm.
This makes above work without manual intervention and also avoids
the stale socket file.

 The debian/clamav-daemon.postinst.in file adds ListenStream twice, so
 the first (empty) one may leave. After that change I still don't see
 systemd setting the permissions properly. Any ideas?

The first, empty ListenStream is intended: It tells systemd to ignore
the one provided by the main socket unit in /lib/systemd/system.
Otherwise it would open two sockets.

 However while testing this, I noticed another issue:
 The clamav-daemon.socket is not stopped during 'dpkg-reconfigure 
 clamav-daemon'.
 Thus after changing the name of the socket, a stale socket file is left 
 behind.
 I'm not sure if that's really a problem worth fixing though. Thoughts?
 
 Leaving stale sockets isn't nice I guess. But it won't happen often I
 guess. stop - change socket file - start would fix it and a reload
 due to new options would be done anyway. Would that be a way to fix it?

That's how it's fixed now. ;)

Best regards,
Andreas


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#783838: blender: FTBFS in Jessie

2015-04-30 Thread Andreas Cadhalpun

Hi Matteo,

On 30.04.2015 19:45, Matteo F. Vescovi wrote:
 I was about uploading it today in the afternoon, but the python3.4 issue (now 
 fixed) prevented that.
 
 I'll hopefully upload it tomorrow.

Thanks!

Best regards,
Andreas


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#783842: paraview: FTBFS: no matching function for call to 'min(unsigned int, int)'

2015-04-30 Thread Andreas Cadhalpun

Source: paraview
Version: 4.1.0+dfsg+1
Severity: serious

Dear maintainer,

paraview currently fails to build with the following error:

/tmp/buildd/paraview-4.1.0+dfsg+1/VTK/Rendering/FreeType/vtkFreeTypeTools.cxx: 
In member function 'bool vtkFreeTypeTools::CalculateBoundingBox(const T, 
vtkFreeTypeTools::MetaData)':
/tmp/buildd/paraview-4.1.0+dfsg+1/VTK/Rendering/FreeType/vtkFreeTypeTools.cxx:1190:51:
 error: no matching function for call to 'min(unsigned int, int)'
   metaData.descent);
   ^
/tmp/buildd/paraview-4.1.0+dfsg+1/VTK/Rendering/FreeType/vtkFreeTypeTools.cxx:1190:51:
 note: candidates are:
In file included from /usr/include/c++/4.9/bits/char_traits.h:39:0,
 from /usr/include/c++/4.9/ios:40,
 from /usr/include/c++/4.9/ostream:38,
 from /usr/include/c++/4.9/iostream:39,
 from 
/tmp/buildd/paraview-4.1.0+dfsg+1/VTK/Common/Core/vtkIOStream.h:33,
 from 
/tmp/buildd/paraview-4.1.0+dfsg+1/VTK/Common/Core/vtkSystemIncludes.h:36,
 from 
/tmp/buildd/paraview-4.1.0+dfsg+1/obj-x86_64-linux-gnu/VTK/Common/Core/vtkAtomicInt.h:38,
 from 
/tmp/buildd/paraview-4.1.0+dfsg+1/VTK/Common/Core/vtkObjectBase.h:44,
 from 
/tmp/buildd/paraview-4.1.0+dfsg+1/VTK/Common/Core/vtkObject.h:42,
 from 
/tmp/buildd/paraview-4.1.0+dfsg+1/VTK/Rendering/FreeType/vtkFreeTypeTools.h:27,
 from 
/tmp/buildd/paraview-4.1.0+dfsg+1/VTK/Rendering/FreeType/vtkFreeTypeTools.cxx:16:
/usr/include/c++/4.9/bits/stl_algobase.h:194:5: note: templateclass _Tp const 
_Tp std::min(const _Tp, const _Tp)
 min(const _Tp __a, const _Tp __b)
 ^
/usr/include/c++/4.9/bits/stl_algobase.h:194:5: note:   template argument 
deduction/substitution failed:
/tmp/buildd/paraview-4.1.0+dfsg+1/VTK/Rendering/FreeType/vtkFreeTypeTools.cxx:1190:51:
 note:   deduced conflicting types for parameter 'const _Tp' ('unsigned int' 
and 'int')
   metaData.descent);
   ^
In file included from /usr/include/c++/4.9/bits/char_traits.h:39:0,
 from /usr/include/c++/4.9/ios:40,
 from /usr/include/c++/4.9/ostream:38,
 from /usr/include/c++/4.9/iostream:39,
 from 
/tmp/buildd/paraview-4.1.0+dfsg+1/VTK/Common/Core/vtkIOStream.h:33,
 from 
/tmp/buildd/paraview-4.1.0+dfsg+1/VTK/Common/Core/vtkSystemIncludes.h:36,
 from 
/tmp/buildd/paraview-4.1.0+dfsg+1/obj-x86_64-linux-gnu/VTK/Common/Core/vtkAtomicInt.h:38,
 from 
/tmp/buildd/paraview-4.1.0+dfsg+1/VTK/Common/Core/vtkObjectBase.h:44,
 from 
/tmp/buildd/paraview-4.1.0+dfsg+1/VTK/Common/Core/vtkObject.h:42,
 from 
/tmp/buildd/paraview-4.1.0+dfsg+1/VTK/Rendering/FreeType/vtkFreeTypeTools.h:27,
 from 
/tmp/buildd/paraview-4.1.0+dfsg+1/VTK/Rendering/FreeType/vtkFreeTypeTools.cxx:16:
/usr/include/c++/4.9/bits/stl_algobase.h:240:5: note: templateclass _Tp, class 
_Compare const _Tp std::min(const _Tp, const _Tp, _Compare)
 min(const _Tp __a, const _Tp __b, _Compare __comp)
 ^
/usr/include/c++/4.9/bits/stl_algobase.h:240:5: note:   template argument 
deduction/substitution failed:
/tmp/buildd/paraview-4.1.0+dfsg+1/VTK/Rendering/FreeType/vtkFreeTypeTools.cxx:1190:51:
 note:   deduced conflicting types for parameter 'const _Tp' ('unsigned int' 
and 'int')
   metaData.descent);
   ^

A full build log can be obtained from the reproducibility rebuild [1].

Best regards,
Andreas

1: 
https://reproducible.debian.net/rbuild/unstable/amd64/paraview_4.1.0+dfsg+1-1.rbuild.log


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#763148: Prevent migration to jessie

On 29.04.2015 12:28, Emilio Pozuelo Monfort wrote:
 On 29/04/15 10:41, Bálint Réczey wrote:
 2015-04-29 9:44 GMT+02:00 Emilio Pozuelo Monfort po...@debian.org:
 On 27/04/15 00:30, Andreas Cadhalpun wrote:
 On 27.04.2015 00:01, Emilio Pozuelo Monfort wrote:
 On 26/04/15 19:06, Andreas Cadhalpun wrote:
 Dear release team,

 as you undoubtedly know: jessie has been released! \o/

 Thus this bug is now obsolete and I'm closing it.

 Please remove the testing migration block of ffmpeg.

 I don't think you understand the problem.

 Having both ffmpeg and libav in the same release is the problem.

 But having mysql-5.5 and mariadb-10.0 in jessie is apparently no
 problem, despite previous claims. What's the difference?

It would really be nice to get an answer for this question.

 So at this moment, that block hint is not going to be removed.

 When will it be removed, if not now?

 Previously Moritz Mühlenhoff wrote [1]:
 After the jessie release a decision between libav and ffmpeg will need
 to be made. It certainly possible to have them co-exist for a year or
 so, but the decision needs to be made before the jessie+1 freeze.

 How do you think this should go forward?

 You could ask the TC to decide between the two. As it happened with #717076 
 for
 example.

The TC is only a last resort, used when the normal processes fail.
It would be much better if they would work.
Therefore I'm planning to discuss a possible transition from
Libav to FFmpeg with the maintainers of the reverse dependencies,
before asking the TC for a resolution.
However this will take time and I don't see any reason to block
ffmpeg from testing during this time.
It could be removed again before stretch is released, should that
prove necessary.

 There is no need to ask TC (yet), it is blocked by Julien:
 https://release.debian.org/britney/hints/jcristau

 Dear Julien,

 Could you please lift the unblock now since Jessie has been released
 and we generally don't ban packages from entering testing based on
 duplicate functionality?
 
 Sigh. This has been said multiple times, but I'll explain it again.
 
 We do block stuff based on security concerns.
 
 Since there are concerns on shipping both libav and ffmpeg,

Just for your information: I'm currently in the process of finding and
fixing FFmpeg's remaining potentially security relevant bugs by systematically
fuzzing its demuxers/decoders with afl [1].
Once that's done (hopefully in the not too far future) security concerns
regarding FFmpeg should become more or less void.

And anyway, as far as I know, the only security support for testing comes
through unstable. So it's not like having FFmpeg in testing would increase
the workload of the security team.

 we won't allow
 ffmpeg unless it is chosen to be the default and there is a clear transition
 plan, so that we can switch from one to the other. Only then will the block 
 hint
 be removed.
 
 Hope that is clear.

Let me take your example of libjpeg-turbo: It has been in testing, when
the TC bug #717076 [2] was filed and during the year the decision was debated 
there,
except for a short time, were it was removed due to concrete unfixed security
issues [3].

It is not clear to me, why a similar treatment should not be possible for 
ffmpeg.

Best regards,
Andreas


1: https://tracker.debian.org/pkg/afl
   BTW: Thanks to Jakub Wilk for packaging afl!
2: https://bugs.debian.org/717076
3: https://bugs.debian.org/729873


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#783720: clamav-daemon does not honour Local* with systemd

Hi Sebastian,

On 29.04.2015 14:56, Sebastian Andrzej Siewior wrote:
 The options
   LocalSocket /var/run/clamav/clamd.ctl.change
   LocalSocketGroup nobody
   LocalSocketMode 600
 
 in clamd.conf are not considered when used via systemd. It seems that 
   /lib/systemd/system/clamav-daemon.socket
 has those options hardcoded. Not sure if this should be updated by
 debconf or the clamd.conf should win over the service file but the way
 it is now the options are silently ignored which means a regression from
 Wheezy.

This should be handled just as the TCPSocket option via extending the
socket unit with /etc/systemd/system/clamav/extend.conf.
(I should have noticed this, when implementing the TCPSocket extending.)
I'll work on implementing that shortly.

 Feel free to correct the severity level but it mill break all setups
 where a different group and socket path is used.

We handled the TCPSocket issue as serious, so I'll leave the severity
for now.

Best regards,
Andreas


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#763148: Prevent migration to jessie

Hi Jonathan,

thanks for answering my question.

On 29.04.2015 16:52, Jonathan Wiltshire wrote:
 mysql-5.5 and mariadb-10.0 in Jessie is not exactly no problem.
 There were extensive discussions before the freeze about which of
 the *four* forks of MySQL would ship in Jessie.

 Bear in mind that MySQL and Maria were both already in testing at
 this point.

When I asked Moritz about MySQL and MariaDB [1] in February 2014,
MariaDB 5.5 had been in testing for just two months, while
MariaDB 10.0 went to testing only in November 2014.

 The security team understandably want to support only
 one fork. The maintainers could not agree which it should be.

This is exactl
I don't think that's a fair criterion. FFmpeg would be in testing,
if it wasn't blocked.
Now the justification for the block is that it's not in testing.
That's kind of circular.

 andy how it was with FFmpeg/Libav before the freeze.

 We eventually arranged to ship two of those four forks in Jessie
 with a view to having only one in Stretch,  easing the transition
 for users if it ends up being Maria. That aim has not changed.
 Jessie was a compromise situation.

I would have appreciated if there had been such a compromise solution
for FFmpeg/Libav as well.

 This isn't a good direct comparison with ffmpeg/libav since we do
 not have the situation of them both in testing at the moment,

I don't think that's a fair criterion. FFmpeg would be in testing,
if it wasn't blocked.
Now the justification for the block is that it's not in testing.
That's kind of circular.

 and
 I believe that should remain the case until one or the other
 becomes the obvious candidate. We do not want to end up with
 dependencies on both in testing that need to be untangled later.

That's understandable. But on the other hand, not having FFmpeg
in testing means more work elsewhere and less testing for it.

Best regards,
Andreas

1: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=729203#420


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#763148: Prevent migration to jessie

Hi Moritz,

On 29.04.2015 20:22, Moritz Mühlenhoff wrote:
 Andreas Cadhalpun wrote:
 
 But having mysql-5.5 and mariadb-10.0 in jessie is apparently no
 problem, despite previous claims. What's the difference?
 
 To properly migrate over a daemon they need to co-exist for a stable
 release, while a lib does not. Stretch will only have one of them.

That makes sense, thanks for explaining.

 How do you think this should go forward?
 
 When someone made a strawpoll amongst the multimedia maintainers
 last year it boiled down to libav for jessie, since it's now to late.
 You should revisit that decision now that the release cycle has started.
 (Beside pkg-multimedia-maintainers, this certainly also includes
 maintainers like Balint which maintain relevant multimedia apps outside of
 pkg-multimedia-maintainers.)
 
 If no convinging/clear majority can be reached, let the CTTE decide.

That was my plan.

 Having both for a year along each other will only waste people's time. Now
 at the beginning of the release cycle is the time to make a decision,
 not by dragging things into a year as of today. Picking one of the two
 won't be any simpler in 12 months.

I just fear that the decision making process will take long, especially
if the TC has to get involved. (The libjpeg-turbo TC decision took 1 year.)

Having ffmpeg in testing during this time would be nice, e.g. so that people
using testing can easily compare them.

Was that not what you meant with [1]:
It certainly possible to have them co-exist for a year or so

Best regards,
Andreas

1: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=763148#134


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#763148: Prevent migration to jessie

Hi Julien,

On 29.04.2015 20:40, Julien Cristau wrote:
 On Wed, Apr 29, 2015 at 20:33:07 +0200, Andreas Cadhalpun wrote:
 
 Having ffmpeg in testing during this time would be nice, e.g. so that people
 using testing can easily compare them.

 Not really.  It's a library, users don't get to compare, they get to use
 whichever one is chosen by the application they're using.

It's not only a library, but also a set of command-line tools (the ffmpeg
binary package).

With these command-line tools one can check the libraries. (That's how
a large part of the upstream test-suite works.)

For example, one can verify that bugs in Libav don't exist in FFmpeg,
e.g. #783616 [1].

Best regards,
Andreas

1: https://bugs.debian.org/783616


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#763148: Prevent migration to jessie

On 29.04.2015 20:47, Moritz Mühlenhoff wrote:
 On Wed, Apr 29, 2015 at 08:33:07PM +0200, Andreas Cadhalpun wrote:
 Having both for a year along each other will only waste people's time. Now
 at the beginning of the release cycle is the time to make a decision,
 not by dragging things into a year as of today. Picking one of the two
 won't be any simpler in 12 months.

 I just fear that the decision making process will take long, especially
 if the TC has to get involved. (The libjpeg-turbo TC decision took 1 year.)

 Having ffmpeg in testing during this time would be nice, e.g. so that people
 using testing can easily compare them.

 Was that not what you meant with [1]:
 It certainly possible to have them co-exist for a year or so
 
 Honestly at this point I don't believe we'll need a year to sort out whether
 it'll be libav or ffmpeg.
 
 I'll refrain from mentioning my personal preference for now, but IMO
 one of the two is preferable in almost all aspects, so picking the lib for
 stretch shouldn't take that long.

OK, then I'll try start that discussion on pkg-multimedia soon.
But I'll have to take care of something else first.

Best regards,
Andreas


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#763148: Prevent migration to jessie

Hi Alessio,

On 29.04.2015 15:27, Alessio Treglia wrote:
 On Wed, Apr 29, 2015 at 12:47 PM, Andreas Cadhalpun
 andreas.cadhal...@googlemail.com wrote:
 Therefore I'm planning to discuss a possible transition from
 Libav to FFmpeg with the maintainers of the reverse dependencies,
 before asking the TC for a resolution.
 
 What if one or more maintainers do not agree with you to make his
 packages break away from libav?

As I tried to imply above: If no decision between having both,
only FFmpeg, or only Libav can be reached with normal means,
we have to ask the TC.

 What result are you aiming to achieve?

I'd like to see stretch released with FFmpeg. So either FFmpeg replaces
Libav or the Security Team gets convinced that having both is acceptable.

 Splitting multimedia packages up in two groups, each one depending on
 a different implementation of the same interfaces?

This is a possible outcome, if both are allowed in stretch.

 And on the basis of what?

If both are there, any maintainer can make his own decision, probably
based on upstream preference.

 I feel that we'd better *first* decide on which one between ffmpeg and
 libav we want to keep, and drop the alternative.

I feel that it's not necessary, but possible, to make a Debian-wide
decision between FFmpeg and Libav.

Best regards,
Andreas


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#763148: Prevent migration to jessie

Hi Alessandro,

On 29.04.2015 16:08, Alessandro Ghedini wrote:
 The decision has to be taken *now*, not in one year.

We should start discussing, sure, but I would be surprised if a decision
could be reached in a time frame short enough to qualify as 'now'.

 Last year, just before the freeze, we (the multimedia team) sort of held a 
 vote
 to decide this, but it went in favour of libav. IIRC the reason people voted 
 in
 favour of libav was that we were too close to the freeze to do anything.
 
 Now would be the time to start that discussion again. So, instead of wasting
 energies arguing against the migration block, I suggest you be the one to
 restart that discussion, given that you are the maintainer of ffmpeg.

As I already wrote [1], I plan to start such a discussion. However I thought 
that
meanwhile FFmpeg would be allowed into testing, as this seemed what Moritz
suggested: Have both in testing for a year, while discussing further actions.
Therefore I did not expect that this would be controversial.

Best regards,
Andreas


1: https://bugs.debian.org/763148#188


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#783720: clamav-daemon does not honour Local* with systemd

Control: tags -1 pending

Hi Sebastian,

On 29.04.2015 21:09, Andreas Cadhalpun wrote:
 On 29.04.2015 14:56, Sebastian Andrzej Siewior wrote:
 The options
  LocalSocket /var/run/clamav/clamd.ctl.change
  LocalSocketGroup nobody
  LocalSocketMode 600

 in clamd.conf are not considered when used via systemd. It seems that 
  /lib/systemd/system/clamav-daemon.socket
 has those options hardcoded. Not sure if this should be updated by
 debconf or the clamd.conf should win over the service file but the way
 it is now the options are silently ignored which means a regression from
 Wheezy.
 
 This should be handled just as the TCPSocket option via extending the
 socket unit with /etc/systemd/system/clamav/extend.conf.
 (I should have noticed this, when implementing the TCPSocket extending.)
 I'll work on implementing that shortly.

I just pushed a fix for this.
It seems to work as intended, but additional testing would be nice. ;)

I've also run this through piuparts, which didn't complain.

However while testing this, I noticed another issue:
The clamav-daemon.socket is not stopped during 'dpkg-reconfigure clamav-daemon'.
Thus after changing the name of the socket, a stale socket file is left behind.
I'm not sure if that's really a problem worth fixing though. Thoughts?

Best regards,
Andreas


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#763148: Prevent migration to jessie

Hi Alessandro,

On 29.04.2015 14:58, Alessandro Ghedini wrote:
 On mer, apr 29, 2015 at 02:29:43 +0200, Bálint Réczey wrote:
 Since there are concerns on shipping both libav and ffmpeg, we won't allow
 ffmpeg unless it is chosen to be the default and there is a clear transition
 plan, so that we can switch from one to the other. Only then will the block 
 hint
 be removed.
 There are no technical reasons for not having both in testing an I see
 this the only fair solution. There are no name- nor symbol collision
 between the packages. They co-exist perfectly on my systems, too.
 
 There is at least one reason that I can think of. Assuming the decision to 
 keep
 either libav or ffmpeg (not both) stands,

Great to hear that this is only an assumption and no definitive statement!

 if ffmpeg is allowed to migrate and
 other packages start depending on it,

Packages already depend on FFmpeg, simply because they don't work with Libav:
pencil2d, vokoscreen, kodi (in NEW [1]), chromium (using embedded copy),
mplayer (ITP: #763826 [2])

 and if before the stretch release ffmpeg
 is deemed not release ready (e.g. if libav is chosen), then more work will be
 required to untangle the dependencies and have ffmpeg removed from testing.

If a preliminary decision is made in e.g. one years time, maintainers would have
plenty of time to adapt.

And if FFmpeg is not allowed into testing, this will mean more work for those
wanting/needing to use it, like e.g. adding patches to not fail completely,
when using Libav.
If the final decision would be to only allow FFmpeg, not having had it in
testing would also mean, well, less testing, of itself and possibly 
reverse-dependencies
using it instead of Libav. (Currently most don't provide versions compiled
against both. Thanks for doing this with mpv, by the way.)
It would also be difficult to get testing for a fix of #763632 [3], as long
as FFmpeg is not in testing.

So there is work involved both ways.

Best regards,
Andreas

1: https://ftp-master.debian.org/new/kodi_14.2+dfsg1-1.html
2: https://bugs.debian.org/763826
3: https://bugs.debian.org/763632


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#763148: Prevent migration to jessie

2015-04-26 Thread Andreas Cadhalpun

On 27.04.2015 00:01, Emilio Pozuelo Monfort wrote:
 On 26/04/15 19:06, Andreas Cadhalpun wrote:
 Dear release team,

 as you undoubtedly know: jessie has been released! \o/

 Thus this bug is now obsolete and I'm closing it.

 Please remove the testing migration block of ffmpeg.
 
 I don't think you understand the problem.
 
 Having both ffmpeg and libav in the same release is the problem.

But having mysql-5.5 and mariadb-10.0 in jessie is apparently no
problem, despite previous claims. What's the difference?

 So at this moment, that block hint is not going to be removed.

When will it be removed, if not now?

Previously Moritz Mühlenhoff wrote [1]:
After the jessie release a decision between libav and ffmpeg will need
to be made. It certainly possible to have them co-exist for a year or
so, but the decision needs to be made before the jessie+1 freeze.

How do you think this should go forward?

Best regards,
Andreas

1: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=763148#134


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#781265: gnome-power-manager: gnome-power-statistics segfaults always under certain case

2015-03-27 Thread Andreas Cadhalpun

Control: reassign -1 upower
Control: forcemerge 774546 -1

Hi Mohammed,

On 27.03.2015 01:45, Mohammed Sadik P. K. wrote:
 On 3/27/15, Andreas Cadhalpun andreas.cadhal...@googlemail.com wrote:
 This looks like a duplicate of #774546 [1].
 Can you install libupower-glib3 0.99.2-2 from experimental and report
 if that fixed this problem?
 
 Yes, It does fix the bug. Please close the bug.

Thanks for confirming. I'm merging it with the other bug.

Best regards,
Andreas


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#781265: gnome-power-manager: gnome-power-statistics segfaults always under certain case

2015-03-26 Thread Andreas Cadhalpun

Hi Mohammed,

On 26.03.2015 17:55, Mohammed Sadik P. K. wrote:
* What led up to the situation?
 
  Opened `gnome-power-statistics' (via GNOME Terminal emulator),
  switched between the Tabs, and it segfaults on certain cases.
[...]
 ii  libupower-glib3  0.99.1-3.1

This looks like a duplicate of #774546 [1].
Can you install libupower-glib3 0.99.2-2 from experimental and report
if that fixed this problem?

Best regards,
Andreas

1: https://bugs.debian.org/774546


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#779798: openjfx: FTBFS error: conflicting declaration 'typedef int32_t UChar32'

2015-03-04 Thread Andreas Cadhalpun


Source: openjfx
Version: 8u20-b26-3
Severity: serious
Justification: fails to build from source

Dear Maintainer,

openjfx fails to build on sid/amd64:
In file included from /usr/include/x86_64-linux-gnu/unicode/utypes.h:36:0,
 from /usr/include/x86_64-linux-gnu/unicode/ucnv_err.h:86,
 from /usr/include/x86_64-linux-gnu/unicode/ucnv.h:50,
 from /usr/include/libxml2/libxml/encoding.h:31,
 from /usr/include/libxml2/libxml/parser.h:810,
 from 
../../../../src/main/native/Source/WebCore/xml/XSLStyleSheet.h:32,
 from 
../../../../src/main/native/Source/WebCore/xml/XSLTProcessor.h:29,
 from generated/JSXSLTProcessor.h:27,
 from generated/JSDOMWindow.cpp:614:
/usr/include/x86_64-linux-gnu/unicode/umachine.h:298:17: error: conflicting 
declaration 'typedef int32_t UChar32'
 typedef int32_t UChar32;
 ^
In file included from 
../../../../src/main/native/Source/WTF/wtf/unicode/Unicode.h:36:0,
 from 
../../../../src/main/native/Source/WTF/wtf/text/ASCIIFastPath.h:31,
 from 
../../../../src/main/native/Source/WTF/wtf/text/WTFString.h:28,
 from ../../../../src/main/native/Source/WTF/wtf/DateMath.h:54,
 from 
../../../../src/main/native/Source/WebCore/webcorejava_pch.h:57:
../../../../src/main/native/Source/WTF/wtf/unicode/java/UnicodeJava.h:24:18: 
note: previous declaration as 'typedef uint32_t UChar32'
 typedef uint32_t UChar32;
  ^

This can also be seen in the reproducibility rebuild [1].

Best regards,
Andreas

1: https://reproducible.debian.net/rb-pkg/sid/amd64/openjfx.html


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#779802: vtk6: FTBFS: error: no matching function for call to 'min(unsigned int, int)'

2015-03-04 Thread Andreas Cadhalpun


Source: vtk6
Version: 6.1.0+dfsg2-5
Tags: sid
Severity: serious
Justification: fails to build from source

Dear Maintainer,

vtk6 fails to build on sid/amd64, but it works on jessie/amd64 (hence the sid 
tag).

The errors are:

/tmp/buildd/vtk6-6.1.0+dfsg2/Rendering/FreeType/vtkFreeTypeTools.cxx: In member 
function 'bool vtkFreeTypeTools::CalculateBoundingBox(const T, 
vtkFreeTypeTools::MetaData)':
/tmp/buildd/vtk6-6.1.0+dfsg2/Rendering/FreeType/vtkFreeTypeTools.cxx:1190:51: error: no 
matching function for call to 'min(unsigned int, int)'
   metaData.descent);
   ^
/tmp/buildd/vtk6-6.1.0+dfsg2/Rendering/FreeType/vtkFreeTypeTools.cxx:1190:51: 
note: candidates are:
In file included from /usr/include/c++/4.9/bits/char_traits.h:39:0,
 from /usr/include/c++/4.9/ios:40,
 from /usr/include/c++/4.9/ostream:38,
 from /usr/include/c++/4.9/iostream:39,
 from /tmp/buildd/vtk6-6.1.0+dfsg2/Common/Core/vtkIOStream.h:33,
 from 
/tmp/buildd/vtk6-6.1.0+dfsg2/Common/Core/vtkSystemIncludes.h:36,
 from 
/tmp/buildd/vtk6-6.1.0+dfsg2/debian/build/Common/Core/vtkAtomicInt.h:38,
 from 
/tmp/buildd/vtk6-6.1.0+dfsg2/Common/Core/vtkObjectBase.h:44,
 from /tmp/buildd/vtk6-6.1.0+dfsg2/Common/Core/vtkObject.h:42,
 from 
/tmp/buildd/vtk6-6.1.0+dfsg2/Rendering/FreeType/vtkFreeTypeTools.h:27,
 from 
/tmp/buildd/vtk6-6.1.0+dfsg2/Rendering/FreeType/vtkFreeTypeTools.cxx:16:
/usr/include/c++/4.9/bits/stl_algobase.h:194:5: note: templateclass _Tp const _Tp 
std::min(const _Tp, const _Tp)
 min(const _Tp __a, const _Tp __b)
 ^
/usr/include/c++/4.9/bits/stl_algobase.h:194:5: note:   template argument 
deduction/substitution failed:
/tmp/buildd/vtk6-6.1.0+dfsg2/Rendering/FreeType/vtkFreeTypeTools.cxx:1190:51: 
note:   deduced conflicting types for parameter 'const _Tp' ('unsigned int' and 
'int')
   metaData.descent);
   ^
In file included from /usr/include/c++/4.9/bits/char_traits.h:39:0,
 from /usr/include/c++/4.9/ios:40,
 from /usr/include/c++/4.9/ostream:38,
 from /usr/include/c++/4.9/iostream:39,
 from /tmp/buildd/vtk6-6.1.0+dfsg2/Common/Core/vtkIOStream.h:33,
 from 
/tmp/buildd/vtk6-6.1.0+dfsg2/Common/Core/vtkSystemIncludes.h:36,
 from 
/tmp/buildd/vtk6-6.1.0+dfsg2/debian/build/Common/Core/vtkAtomicInt.h:38,
 from 
/tmp/buildd/vtk6-6.1.0+dfsg2/Common/Core/vtkObjectBase.h:44,
 from /tmp/buildd/vtk6-6.1.0+dfsg2/Common/Core/vtkObject.h:42,
 from 
/tmp/buildd/vtk6-6.1.0+dfsg2/Rendering/FreeType/vtkFreeTypeTools.h:27,
 from 
/tmp/buildd/vtk6-6.1.0+dfsg2/Rendering/FreeType/vtkFreeTypeTools.cxx:16:
/usr/include/c++/4.9/bits/stl_algobase.h:240:5: note: templateclass _Tp, class _Compare 
const _Tp std::min(const _Tp, const _Tp, _Compare)
 min(const _Tp __a, const _Tp __b, _Compare __comp)
 ^
/usr/include/c++/4.9/bits/stl_algobase.h:240:5: note:   template argument 
deduction/substitution failed:
/tmp/buildd/vtk6-6.1.0+dfsg2/Rendering/FreeType/vtkFreeTypeTools.cxx:1190:51: 
note:   deduced conflicting types for parameter 'const _Tp' ('unsigned int' and 
'int')
   metaData.descent);
   ^
/tmp/buildd/vtk6-6.1.0+dfsg2/Rendering/FreeType/vtkFreeTypeTools.cxx: In member 
function 'void vtkFreeTypeTools::GetLineMetrics(T, T, vtkFreeTypeTools::MetaData, 
int, int*)':
/tmp/buildd/vtk6-6.1.0+dfsg2/Rendering/FreeType/vtkFreeTypeTools.cxx:1954:77: error: no 
matching function for call to 'max(int, unsigned int)'
   bbox[1] = std::max(bbox[1], pen[0] + bitmapGlyph-left + bitmap-width);
 ^
/tmp/buildd/vtk6-6.1.0+dfsg2/Rendering/FreeType/vtkFreeTypeTools.cxx:1954:77: 
note: candidates are:
In file included from /usr/include/c++/4.9/bits/char_traits.h:39:0,
 from /usr/include/c++/4.9/ios:40,
 from /usr/include/c++/4.9/ostream:38,
 from /usr/include/c++/4.9/iostream:39,
 from /tmp/buildd/vtk6-6.1.0+dfsg2/Common/Core/vtkIOStream.h:33,
 from 
/tmp/buildd/vtk6-6.1.0+dfsg2/Common/Core/vtkSystemIncludes.h:36,
 from 
/tmp/buildd/vtk6-6.1.0+dfsg2/debian/build/Common/Core/vtkAtomicInt.h:38,
 from 
/tmp/buildd/vtk6-6.1.0+dfsg2/Common/Core/vtkObjectBase.h:44,
 from /tmp/buildd/vtk6-6.1.0+dfsg2/Common/Core/vtkObject.h:42,
 from 
/tmp/buildd/vtk6-6.1.0+dfsg2/Rendering/FreeType/vtkFreeTypeTools.h:27,
 from

Bug#779664: ffmpeg: needs Breaks+Replaces: libav-tools ( 6:9~)

2015-03-03 Thread Andreas Cadhalpun


Control: tags -1 pending

Hi Andreas,

On 03.03.2015 20:46, Andreas Beckmann wrote:

during a test with piuparts I noticed your package fails to co-install
with libav-tools from wheezy.


Thanks for all your testing with piuparts. :)


Since there is no ffmpeg package in jessie, adding these Breaks+Replaces
would ease some upgrade paths from wheezy as well as possible backporting.


Indeed.


In libav (6:9~beta1-1) the compatibility links for ff* tools were removed.


I just added the Breaks+Replaces in git [1].

Best regards,
Andreas

1: 
https://anonscm.debian.org/cgit/collab-maint/ffmpeg.git/commit/?id=705a1ffdfcccf83f1892353951378d9e9526804e



--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#775400: [Pkg-clamav-devel] Bug#775400: clamav-freshclam: freshclam cant download virus definitions

2015-01-15 Thread Andreas Cadhalpun


Control: severity -1 important

Hi,

On 15.01.2015 22:31, Sebastian Andrzej Siewior wrote:

On Thu, Jan 15, 2015 at 10:13:27AM +0100, Ulrich Schmidt wrote:

Package: clamav-freshclam
Version: 0.98.5+dfsg-3
Severity: grave
Tags: newcomer

Why newcommer?


Good question. This tag is supposed to be added to bugs that can be 
fixed by newcomers. (By chance this might even be true here.)



Justification: renders package unusable

Not unter normal circumstances. Atleast I hope so :)


Indeed, it works for most, so I'm reducing the severity.


I did a fresh Jessie install yesterday and installed clamav-daemon+clamav-
freshclam, clamav+clamav-freshclam, deinstalled those packages, reinstalled,
removed, deleted clamav subfolders many many times, to find something i did
wromg.


I am under the impression that atleast 2 should work on Jessie. But I will try
to re-test.


I can reproduce the second problem, but not the first.


Finally i found 2 things that stops freshclam working:

1) /etc/clamav/freshclam.conf has a bad HTTPProxyServer line so freshclam cant
connect.
   I commented out the HTTPProxyServer line and freshclam was able to connect.


How did that line get in there? Did you enter something or did it get there on
its own?


The clamav-freshclam package doesn't add a HTTPProxyServer line by default.
Can you elaborate what exactly you did to get this bad line there?


2) folder /var/lib/clamav was root:root and freshclam cant create files in this
folder.
   I did a chown clamav:clamav /var/lib/clamav and clamav and freshclam starts
running fine. (At least it seems so :) ).

If I recall correctly then clamav-base should do this chown in its postinst.
It is also the one that adds the clamav user to /etc/passwd and so on… This
should have happen since otherwise chown clamav:clamav would not work.


I can reproduce this in a minimal jessie chroot with:
# apt install clamav-base
# apt remove clamav-base
# apt install clamav-base

This can be worked around with:
# apt purge clamav-base
# apt install clamav-base

The problem is that clamav-base.postinst calls chown only on fresh 
installations. This should be easy to fix by moving the chown calls out 
of the 'if [ -z $2 ]'.



-- debconf information:
   clamav-freshclam/http_proxy: �

this looks strange. But it is not your doing, right?


It seems the debconf setting is corrupted, which is really strange.

Best regards,
Andreas


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#773041: Bug#773318: clamav dies/hangs

2014-12-23 Thread Andreas Cadhalpun


Hi,

On 22.12.2014 22:52, Sebastian Andrzej Siewior wrote:

On 2014-12-22 02:52:02 [+0100], Marc Dequènes (duck) wrote:

I can upload this simple fix quickly, nevertheless i did not have time to
proofread it. Any comment?


I plan to add the following patch to clamav. I added a small comment
why we have the busy loop there. So far it looks like a good idea. The
only problem is that we need off_t beeing 64bit (LFS) or it won't work
on 32bit. No problem on Debian side…


I think there is a better way than changing the type of frame_end to off_t.
It is possible to avoid the overflow by reordering the code:

--- libmspack-0.4.orig/mspack/qtmd.c
+++ libmspack-0.4/mspack/qtmd.c
@@ -296,10 +296,12 @@ int qtmd_decompress(struct qtmd_stream *

 /* decode more, up to the number of bytes needed, the frame boundary,
  * or the window boundary, whichever comes first */
-frame_end = window_posn + (out_bytes - (qtm-o_end - qtm-o_ptr));
-if ((window_posn + frame_todo)  frame_end) {
+if (frame_todo  (out_bytes - (qtm-o_end - qtm-o_ptr))) {
   frame_end = window_posn + frame_todo;
 }
+else {
+  frame_end = window_posn + (out_bytes - (qtm-o_end - qtm-o_ptr));
+}
 if (frame_end  qtm-window_size) {
   frame_end = qtm-window_size;
 }

This works, because frame_todo is at most QTM_FRAME_SIZE = 32768.

Merry Christmas,
Andreas


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#773041: Bug#773318: clamav dies/hangs

2014-12-23 Thread Andreas Cadhalpun


Control: found 773318 0.98.5+dfsg-0+deb7u1
Control: notfound 773318 0.98.5+dfsg-3
# 0.98.5+dfsg-3 uses the system libmspack
# see bug #773041 for progress there

Hi Sebastian,

On 23.12.2014 21:44, Sebastian Andrzej Siewior wrote:

Even better, I like it. The patch at the end of the email is what I
pushed into the wheezy branch for clamav [0]. So after an upload for
stable, we have Wheezy fixed.


Yes, thanks.


I have no idea how to close this bug for
unstable since it has to be fixed in a different package. Probably
manually with a comment…


I'm marking the unstable version as not affected, because we have #773041
to track the progress for libmspack. So the upload of the fixed wheezy
version will close this bug.


Side question: In case someone has unattended-upgrades running, how does
he get clamd restarted after a libmspack update?


I think needrestart can do that.

Best regards,
Andreas


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#773318: clamav dies/hangs

2014-12-20 Thread Andreas Cadhalpun


Hi James,

On 19.12.2014 23:07, James Cloos wrote:

AC == Andreas Cadhalpun andreas.cadhal...@googlemail.com writes:


AC You mean it crashed?
AC Please provide excerpts of /var/log/clamav/clamav.log and
AC /var/log/syslog from around the time of the crashes.

Yes, the clamd process quit, so the milter process was rejecting all
incoming mail with a 4xx try again reply.

In each case the last thing logged to clamav.log before I restarted
clamd was just a

 Reading databases from /var/lib/clamav

line.

So it looks like it died during a reload, since:

 Database correctly reloaded

did not get logged.


Indeed. It seems like one of the unofficial signature databases caused 
clamd to crash during reload. It would be great, if you could determine 
which one that was, so that the problem can be reproduced.



AC If you can reproduce the crashes, please install clamav-dbg and use
AC gdb to provide a backtrace of the crashes.

I removed the clamav-milter call to keep mail flowing; I'll turn it back
on on one of them this weekend.


Thanks.

Best regards,
Andreas


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#773318: clamav dies/hangs

2014-12-20 Thread Andreas Cadhalpun


Control: tags 773041 security
Control: severity 773041 grave
Justification: causes remote denial of service

Hi James,

On 19.12.2014 23:12, James Cloos wrote:

Even w/ the milter not called, one of the MXs has one clamd thread
consuming 100% cpu right now.  gdb says:

#0  0x7fd0b4791ed0 in ?? () from /usr/lib/x86_64-linux-gnu/libmspack.so.0
#1  0x7fd0b47863ea in ?? () from /usr/lib/x86_64-linux-gnu/libmspack.so.0
#2  0x7fd0b55c1e26 in cli_scanmscab (ctx=0x7fd096dfb6b0, sfx_offset=256) at 
libmspack.c:384
#3  0x7fd0b5597aa0 in magic_scandesc (ctx=0x7fd096dfb6b0, type=CL_TYPE_ANY)
 at scanners.c:2703
#4  0x7fd0b5598059 in cli_base_scandesc (desc=12, ctx=0x7fd096dfb6b0, 
type=CL_TYPE_ANY)
 at scanners.c:3051
#5  0x7fd0b559bf33 in fileblobScan (fb=0x7fd088003910) at blob.c:641
#6  0x7fd0b559c01d in fileblobScanAndDestroy (fb=fb@entry=0x7fd088003910) 
at blob.c:399
#7  0x7fd0b55a08db in do_multipart (mainMessage=0x0, messages=optimized 
out,
 i=optimized out, rc=0x7fd096dfa35c, mctx=0x7fd096dfa420, 
messageIn=optimized out,
 tptr=0x7fd096dfa360, recursion_level=0) at mbox.c:3712
#8  0x7fd0b55a0019 in parseEmailBody (messageIn=0x7fd095df4000,
 messageIn@entry=0x7fd088004940, textIn=0x100, textIn@entry=0x0, 
mctx=0x7fd0880047b1,
 recursion_level=32512, recursion_level@entry=0) at mbox.c:1533
#9  0x7fd0b55a1232 in cli_parse_mbox (
 dir=dir@entry=0x7fd088000e50 
/tmp/clamav-4b94ddbad0a132b5af6d2f6db3a76e40.tmp,
 ctx=ctx@entry=0x7fd096dfb6b0) at mbox.c:508
#10 0x7fd0b55a1b1a in cli_mbox (
 dir=dir@entry=0x7fd088000e50 
/tmp/clamav-4b94ddbad0a132b5af6d2f6db3a76e40.tmp,
 ctx=ctx@entry=0x7fd096dfb6b0) at mbox.c:309
#11 0x7fd0b5579218 in cli_scanmail (ctx=0x7fd096dfb6b0) at scanners.c:1702


Thanks for the backtrace!

As it shows that clamd hangs in libmspack, I think this is bug #773041 
[1]. A possible fix is mentioned in [2]. We'll have to include it in the 
libmspack copy embedded in clamav, which is used in wheezy.


Best regards,
Andreas


1: https://bugs.debian.org/773041
2: https://bugs.debian.org/773041#8


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#773318: clamav dies/hangs

2014-12-16 Thread Andreas Cadhalpun


Package: clamav-daemon
Version: 0.98.5+dfsg-3
Severity: grave
Justification: renders package unusable
Control: submitter -1 James Cloos cl...@jhcloos.com
X-Debbugs-CC: James Cloos cl...@jhcloos.com

Forwarding the bug reported on the mailing list:
https://lists.alioth.debian.org/pipermail/pkg-clamav-devel/2014-December/004884.html

On 16.12.2014 15:59, James Cloos wrote:

Package: clamav-daemon
Version: 0.98.5+dfsg-3
Severity: grave
Justification: renders package unusable

Starting Thursday night clamd died each night.

After removing the clamav-unofficial-sigs cron job, last night clamd
got stuck using all cpu.  (800% on the 8-node box.)

Either way that blocks all incoming mail.

It is possible that this morning's bug was triggered by the logrotate
cron job, given /etc/logrotate.d/clamav-daemon

-- Package-specific info:
--- configuration ---
Checking configuration files in /etc/clamav

Config file: clamd.conf
---
LogFile = /var/log/clamav/clamav.log
StatsHostID = auto
StatsEnabled disabled
StatsPEDisabled = yes
StatsTimeout = 10
LogFileUnlock disabled
LogFileMaxSize = 4294967295
LogTime = yes
LogClean disabled
LogSyslog disabled
LogFacility = LOG_LOCAL6
LogVerbose disabled
LogRotate = yes
ExtendedDetectionInfo = yes
PidFile = /var/run/clamav/clamd.pid
TemporaryDirectory disabled
DatabaseDirectory = /var/lib/clamav
OfficialDatabaseOnly disabled
LocalSocket = /var/run/clamav/clamd.ctl
LocalSocketGroup = clamav
LocalSocketMode = 666
FixStaleSocket = yes
TCPSocket disabled
TCPAddr disabled
MaxConnectionQueueLength = 15
StreamMaxLength = 26214400
StreamMinPort = 1024
StreamMaxPort = 2048
MaxThreads = 12
ReadTimeout = 180
CommandReadTimeout = 5
SendBufTimeout = 200
MaxQueue = 100
IdleTimeout = 30
ExcludePath disabled
MaxDirectoryRecursion = 15
FollowDirectorySymlinks disabled
FollowFileSymlinks disabled
CrossFilesystems = yes
SelfCheck = 3600
DisableCache disabled
VirusEvent disabled
ExitOnOOM disabled
AllowAllMatchScan = yes
Foreground disabled
Debug disabled
LeaveTemporaryFiles disabled
User = clamav
AllowSupplementaryGroups disabled
Bytecode = yes
BytecodeSecurity = TrustSigned
BytecodeTimeout = 6
BytecodeUnsigned disabled
BytecodeMode = Auto
DetectPUA disabled
ExcludePUA disabled
IncludePUA disabled
AlgorithmicDetection = yes
ScanPE = yes
ScanELF = yes
DetectBrokenExecutables disabled
ScanMail = yes
ScanPartialMessages disabled
PhishingSignatures = yes
PhishingScanURLs = yes
PhishingAlwaysBlockCloak disabled
PhishingAlwaysBlockSSLMismatch disabled
PartitionIntersection disabled
HeuristicScanPrecedence disabled
StructuredDataDetection disabled
StructuredMinCreditCardCount = 3
StructuredMinSSNCount = 3
StructuredSSNFormatNormal = yes
StructuredSSNFormatStripped disabled
ScanHTML = yes
ScanOLE2 = yes
OLE2BlockMacros disabled
ScanPDF = yes
ScanSWF = yes
ScanArchive = yes
ArchiveBlockEncrypted disabled
ForceToDisk disabled
MaxScanSize = 104857600
MaxFileSize = 26214400
MaxRecursion = 10
MaxFiles = 1
MaxEmbeddedPE = 10485760
MaxHTMLNormalize = 10485760
MaxHTMLNoTags = 2097152
MaxScriptNormalize = 5242880
MaxZipTypeRcg = 1048576
MaxPartitions = 50
MaxIconsPE = 100
ScanOnAccess disabled
OnAccessIncludePath disabled
OnAccessExcludePath disabled
OnAccessExcludeUID disabled
OnAccessMaxFileSize = 5242880
DevACOnly disabled
DevACDepth disabled
DevPerformance disabled
DevLiblog disabled
DisableCertCheck disabled

Config file: freshclam.conf
---
StatsHostID disabled
StatsEnabled disabled
StatsTimeout disabled
LogFileMaxSize = 4294967295
LogTime = yes
LogSyslog disabled
LogFacility = LOG_LOCAL6
LogVerbose disabled
LogRotate = yes
PidFile = /var/run/clamav/freshclam.pid
DatabaseDirectory = /var/lib/clamav
Foreground disabled
Debug disabled
AllowSupplementaryGroups disabled
UpdateLogFile = /var/log/clamav/freshclam.log
DatabaseOwner = clamav
Checks = 24
DNSDatabaseInfo = current.cvd.clamav.net
DatabaseMirror = db.local.clamav.net, database.clamav.net
PrivateMirror = 10
MaxAttempts = 5
ScriptedUpdates = yes
TestDatabases = yes
CompressLocalDatabase disabled
ExtraDatabase disabled
DatabaseCustomURL disabled
HTTPProxyServer disabled
HTTPProxyPort disabled
HTTPProxyUsername disabled
HTTPProxyPassword disabled
HTTPUserAgent disabled
NotifyClamd = /etc/clamav/clamd.conf
OnUpdateExecute disabled
OnErrorExecute disabled
OnOutdatedExecute disabled
LocalIPAddress disabled
ConnectTimeout = 30
ReceiveTimeout = 30
SubmitDetectionStats disabled
DetectionStatsCountry disabled
DetectionStatsHostID disabled
SafeBrowsing disabled
Bytecode = yes

Config file: clamav-milter.conf
---
LogFile = /var/log/clamav/clamav-milter.log
LogFileUnlock disabled
LogFileMaxSize = 2097152
LogTime = yes
LogSyslog disabled
LogFacility = LOG_LOCAL6
LogVerbose = yes
LogRotate = yes
PidFile = /var/run/clamav/clamav-milter.pid
TemporaryDirectory = /tmp
FixStaleSocket = yes
MaxThreads = 10
ReadTimeout = 120
Foreground disabled
User = clamav
AllowSupplementaryGroups = yes
MaxFileSize =

Bug#773318: clamav dies/hangs

2014-12-16 Thread Andreas Cadhalpun


Control: tags -1 moreinfo

Hi James,

On 16.12.2014 21:55, Andreas Cadhalpun wrote:

On 16.12.2014 15:59, James Cloos wrote:

Package: clamav-daemon
Version: 0.98.5+dfsg-3
Severity: grave
Justification: renders package unusable

Starting Thursday night clamd died each night.


You mean it crashed?
Please provide excerpts of /var/log/clamav/clamav.log and 
/var/log/syslog from around the time of the crashes.


If you can reproduce the crashes, please install clamav-dbg and use gdb 
to provide a backtrace of the crashes.



After removing the clamav-unofficial-sigs cron job, last night clamd
got stuck using all cpu.  (800% on the 8-node box.)


Again, please provide the logs mentioned above.


Either way that blocks all incoming mail.
It is possible that this morning's bug was triggered by the logrotate
cron job, given /etc/logrotate.d/clamav-daemon


On 16.12.2014 17:44, James Cloos wrote:
 It turns out that clamd threads start looping, maxing out cpu, very
 soon after a restart.  Sometimes using up all ram, other times just
 preventing the milter from connecting to clamd.

 Which leaves the package unusable.

Please set 'Debug true' in /etc/clamav/clamd.conf, restart clamav-daemon 
and provide debug logs, when the issue happens again.


Best regards,
Andreas


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#771911: [Pkg-clamav-devel] Bug#771911: clamav-daemon: doesn't listen on TCP socket under systemd

2014-12-03 Thread Andreas Cadhalpun


Hi Scott,

On 03.12.2014 22:38, Scott Kitterman wrote:

On Wednesday, December 03, 2014 10:05:56 PM Andreas Cadhalpun wrote:

@team members: Do you agree that we should treat this as an RC bug and
upload the fix immediately to unstable?


Yes.  I just bumped the priority to serious.  I don't think anything else
that's in queue merits RC status though.  Let's just fix this and leave the
rest for 0.98.6 whenever it comes out.


OK. The necessary commits are [1] for the creation of the extending unit 
file and [2] to accept AF_INET6 sockets, which systemd uses in the 
'TCPAddr any' configuration.


Should I create a branch containing only these fixes?

Best regards,
Andreas

1: 
https://anonscm.debian.org/cgit/pkg-clamav/clamav.git/commit/?id=6feefb84aa516190e47611f86d35ee0218295e48
2: 
https://anonscm.debian.org/cgit/pkg-clamav/clamav.git/commit/?id=4bef97af4b95dde6541cf30d2d2fa1a285a6324d



--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#771911: clamav-daemon: doesn't listen on TCP socket under systemd

2014-12-03 Thread Andreas Cadhalpun


Hi Scott,

On 03.12.2014 23:12, Scott Kitterman wrote:

On Wednesday, December 03, 2014 11:08:42 PM Andreas Cadhalpun wrote:

Should I create a branch containing only these fixes?


Yes.  I think that would be best.


I just pushed the bug771911 branch [1].

Best regards,
Andreas

1: https://anonscm.debian.org/cgit/pkg-clamav/clamav.git/log/?h=bug771911


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#771454: libflite1: minimal version in symbols file too old

2014-11-29 Thread Andreas Cadhalpun


Package: libflite1
Version: 1.4-release-11
Severity: serious

Dear Maintainer,

the symbols file of libflite1 sets the minimal version for all symbols 
to 1.4-release. But apparently this is not correct:

If libflite1 1.4-release-8 is installed, ffmpeg does not work:

$ ffmpeg
ffmpeg: symbol lookup error: 
/usr/lib/x86_64-linux-gnu/libflite_cmu_us_slt.so.1: undefined symbol: 
usenglish_init


Installing libflite1 1.4-release-9 (or newer) fixes this.
Probably the fix for #746383 included in 1.4-release-9 is responsible 
for this.


I think the best way forward is to increase the minimal versions of all 
symbols to 1.4-release-9~ and rebuilt all reverse dependencies against a 
fixed version.


Best regards,
Andreas

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

Kernel: Linux 3.17.0-trunk-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set 
to C)

Shell: /bin/sh linked to /bin/dash

Versions of packages libflite1 depends on:
ii  libasound2 1.0.28-1
ii  libc6  2.19-13
ii  multiarch-support  2.19-13

libflite1 recommends no packages.

Versions of packages libflite1 suggests:
pn  alsa-base  none

-- no debconf information


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#769384: [Pkg-clamav-devel] Bug#769384: Bug#769384: ERROR: This tool requires libclamav with functionality level 79 or higher (current f-level: 77)

2014-11-13 Thread Andreas Cadhalpun


Hi,

On 13.11.2014 13:55, Scott Kitterman wrote:

On Thursday, November 13, 2014 13:25:34 Sebastian Andrzej Siewior wrote:

We have depends on libclamav6 based on library functions / ABI. Now the
ABI remains unchanged but stops working. This was neither tested nor
expected.


The problem is that the API changed (subtly): CL_FLEVEL got increased.


I guess the simplest thing to do is to depend the whole clamav package
on the built version instead of versioned symbols like we now.
This check comes from check_flevel() and it is not exported so havp 
friends won't care about his.
Any comments?


The exported function is not check_flevel, but rather cl_retflevel, 
which just returns CL_FLEVEL.



I don't have a better idea.  We need to do something and that's the only
approach I can think of that avoids having to manually set a minimum version.


I think this is the wrong workaround.
The correct fix is to bump the minimal version requirement of 
cl_retflevel to 0.98.5~rc1, which is the upstream version in which 
CL_FLEVEL changed the last time.


We'll have to do that in the future every time CL_FLEVEL is increased.

It is important to note that c-icap-modules also uses cl_retflevel, even 
though it doesn't use CL_FLEVEL directly. Thus it can't have a runtime 
test failing with older libclamav.


Best regards,
Andreas


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#769384: [Pkg-clamav-devel] Bug#769384: Bug#769384: ERROR: This tool requires libclamav with functionality level 79 or higher (current f-level: 77)

2014-11-13 Thread Andreas Cadhalpun


Hi,

On 13.11.2014 22:37, Andreas Cadhalpun wrote:

The correct fix is to bump the minimal version requirement of
cl_retflevel to 0.98.5~rc1, which is the upstream version in which
CL_FLEVEL changed the last time.


I have now reverted Sebastian's workaround and added this fix.
Now the packages clamav, clamav-daemon and clamav-freshclam depend on:
libclamav6 (= 0.98.5~rc1)

Best regards,
Andreas


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#767353: clamav: ERROR: Can't save PID to file /var/run/clamav/freshclam.pid: No such file or directory

2014-10-30 Thread Andreas Cadhalpun


Control: severity -1 normal

Hi Santiago,

On 30.10.2014 13:23, Santiago Vila wrote:

The subject says it all.  This may affect the ability of sysvinit to
start or stop the process (but I may be wrong), hence the serious severity.


Clamav-freshclam works fine under sysvinit and thus I'm reducing the 
severity of this bug.


In fact, this error message only appears when the init system is systemd 
and it is totally harmless in that case.


If you want to get rid of this message, you can remove the PidFile line 
from /etc/clamav/freshclam.conf.
However, be warned that if you do this, clamav-freshclam won't start 
anymore with sysvinit as PID 1.


Best regards,
Andreas


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#764253: system-config-printer: Creates millions of ppd symlinks

2014-10-22 Thread Andreas Cadhalpun


Hi OdyX,

On 22.10.2014 11:24, Didier 'OdyX' Raboud wrote:

Le mardi, 21 octobre 2014, 20.09:08 Andreas Cadhalpun a écrit :

Thus I think there are two bugs here:
   * cups should not create files with wrong permissions in
/etc/cups/ppd


Upstream seems to think differently; see http://cups.org/str.php?L4500
and https://bugzilla.redhat.com/show_bug.cgi?id=1150917#c6

I'm therefore planning to add the patch proposed in STR: #4500 to make
sure symlinks are only returned when they are readable, this should help
right?


Yes, this helps a lot, thanks!
Now cups copies the ppd file to /tmp instead of creating a symlink.

(By the way, the cups test suite hangs in pbuilder, printing endless 
lines of:

Waiting for scheduler to become ready...)


* scp-dbus-service should not start an infinite loop
creating millions of symlinks in /tmp just because the permissions in
/etc/cups/ppd are wrong


This should definitively be fixed in system-config-printer anyway.


Indeed this should be fixed, because starting an infinite loop is a 
rather bad failure mode.


Best regards,
Andreas


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#764253: system-config-printer: Creates millions of ppd symlinks

2014-10-22 Thread Andreas Cadhalpun

Hi Till,

On 22.10.2014 18:14, Till Kamppeter wrote:

I have forwarded this report to Tim Waugh from Red Hat, original author
of system-config-printer and he has answered me the following:

[...]

Thanks for forwarding this upstream.

For the two bugs you mentioned there are fixes now:

Thus I think there are two bugs here:
* cups should not create files with wrong permissions in /etc/cups/ppd

CUPS STR #4500: https://cups.org/str.php?L4500

Yes, this fixes the cups side of the problem.

* scp-dbus-service should not start an infinite loop creating millions
of symlinks in /tmp just because the permissions in /etc/cups/ppd
are wrong

https://git.fedorahosted.org/cgit/system-config-printer.git/commit/?h=1.4.xid=9a81dd1de3afaf30eec92045429029103823b577

I can confirm that this prevents the infinite loop.
The temporary files are still left behind in /tmp upon failure, but as
long as that are not millions, it doesn't matter.

The only strange thing is that scp-dbus-service gets triggered by simply
printing. So can you please try what Tim suggests:

--
Run scp-dbus-service --debug before printing, and see which D-Bus call
it receives. Or watch dbus-monitor --session.
--

and post your results here? Thanks.

There is a DBus call explicitly starting this service:
method call sender=:1.37 - dest=org.freedesktop.DBus serial=4
path=/org/freedesktop/DBus; interface=org.freedesktop.DBus;
member=StartServiceByName

string org.fedoraproject.Config.Printing

This is caused by the scp applet:
/usr/share/system-config-printer/applet.py

If this applet is not running, scp-dbus-service is not started upon
printing.

Best regards,
Andreas

--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#764588: ffmpeg: fails to build from source in sid

2014-10-09 Thread Andreas Cadhalpun


Control: reassign -1 pbuilder
Control: forcemerge 700591 -1
Control: affects 700591 ffmpeg

Hi Holger,

On 09.10.2014 12:57, Holger Levsen wrote:

ffmpeg fails to build from source in sid in pbuilder as per attached log.


It works fine in sid (and jessie), but ...


make[1]: Leaving directory '/tmp/buildd/ffmpeg-2.4.1'
debian/rules override_dh_auto_build-arch
make[1]: Entering directory '/tmp/buildd/ffmpeg-2.4.1'
sem_open: Function not implemented


... you use the pbuilder from stable, which doesn't work correctly, see 
bug #700591 [1].


Adding the following to your pbuilderrc should work around the problem:
BINDMOUNTS=$BINDMOUNTS /run/shm

Best regards,
Andreas

1: https://bugs.debian.org/700591


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#764548: chromium: fails to build due to missing libgnome-keyring-dev build-dependency

2014-10-08 Thread Andreas Cadhalpun


Source: chromium-browser
Version: 37.0.2062.120-4
Severity: serious
Justification: fails to build from source

Dear Maintainer,

chromium failed to build on amd64 [1]:
Package gnome-keyring-1 was not found in the pkg-config search path.
Perhaps you should add the directory containing `gnome-keyring-1.pc'
to the PKG_CONFIG_PATH environment variable
No package 'gnome-keyring-1' found

This is due to a missing build-dependency on libgnome-keyring-dev.

Even with that installed the binary package misses a dependency on 
libgnome-keyring0, because 'linux_link_gnome_keyring=1' is not added to 
the defines.


Additionally h264 support got disabled, because 'proprietary_codecs=1' 
is not used anymore.


Attached patch fixes these issues, please consider applying it.

Best regards,
Andreas

PS: Please keep the git repository up to date. (Currently the last known 
upload there is 37.0.2062.120-2.) This would help with figuring out what 
changelog entries like 'Merge changes from the experimental branch' mean.

E.g. what happened with the disable/google-api-warning.patch?

1: 
https://buildd.debian.org/status/fetch.php?pkg=chromium-browserarch=amd64ver=37.0.2062.120-4stamp=1412576129
diff --git a/debian/control b/debian/control
index 488ad96..e647d86 100644
--- a/debian/control
+++ b/debian/control
@@ -81,6 +81,7 @@ Build-Depends:
  libgcrypt11-dev | libgcrypt20-dev,
  fonts-ipafont-gothic,
  fonts-ipafont-mincho,
+ libgnome-keyring-dev,
 Built-Using:
  libjs-jquery,
  libjs-jquery-flot,
diff --git a/debian/rules b/debian/rules
index b0e5a15..797ee58 100755
--- a/debian/rules
+++ b/debian/rules
@@ -40,6 +40,8 @@ defines+=enable_hidpi=1 \
  linux_link_libpci=1 \
  linux_link_gsettings=1 \
  linux_link_libspeechd=1 \
+ linux_link_gnome_keyring=1 \
+ proprietary_codecs=1 \
 
 # system libraries to use
 defines+=use_system_re2=1 \

Bug#763148: Prevent migration to jessie


Hi,

On 05.10.2014 03:26, Michael Gilbert wrote:

On Fri, Oct 3, 2014 at 1:44 PM, Andreas Cadhalpun wrote:

But I don't think that the mere possibility of such problems is a sufficient
reason to disregard Debian policy, which clearly states that embedded code
copies should not be used.
This is especially the case, if it prevents the properly packaged library
and the command line tools from being part of the stable release.


That may be worth considering post-jessie, but an unavoidable issue
right now is that ffmpeg arrived too late to make it into this release
cycle.


Sorry, I don't understand what you're saying here:
The whole discussion we are having currently is about letting FFmpeg 
migrate to jessie!


So this is no 'unavoidable issue'.

But as you seem to be willing to consider this in principle, I think now 
the time has come for the release team to make an official decision:


Is FFmpeg allowed to migrate to testing, so that chromium can use it?

Or is chromium allowed to continue to use it's embedded copy?

Best regards,
Andreas


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#763148: Prevent migration to jessie


Hi,

On 05.10.2014 21:27, Cyril Brulebois wrote:

Andreas Cadhalpun andreas.cadhal...@googlemail.com (2014-10-05):

The whole discussion we are having currently is about letting FFmpeg
migrate to jessie!

So this is no 'unavoidable issue'.

But as you seem to be willing to consider this in principle, I think
now the time has come for the release team to make an official
decision:

Is FFmpeg allowed to migrate to testing, so that chromium can use it?

Or is chromium allowed to continue to use it's embedded copy?


I'm not sure why one would think the decision still needs to be made.


That's because the last message from a release team member in this bug 
said [1]:

'However (and please note that I'm not a member of the security team
and just speak for myself here as always when not otherwise marked) if
it would be possible to replace the internal code copy in chromium
by a reference to ffmpeg (but it's not possible with libav), that will
probably lead to a re-evalutation. (That doesn't necessarily mean
sucess guranteed, but it looks to me as it will not make things
worse.)'

It is possible to replace the internal code copy in chromium
by a reference to ffmpeg [2], so I thought this would lead to a 
re-evaluation.


Best regards,
Andreas


1: https://bugs.debian.org/763148#27
2: https://bugs.debian.org/763632


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#763148: Prevent migration to jessie


Hi,

On 05.10.2014 22:38, Cyril Brulebois wrote:

Andreas Cadhalpun andreas.cadhal...@googlemail.com (2014-10-05):

On 05.10.2014 21:27, Cyril Brulebois wrote:

I'm not sure why one would think the decision still needs to be made.


That's because the last message from a release team member in this
bug said [1].



1: https://bugs.debian.org/763148#27


What I wrote applies to both Andreas.


When and how was this decision made, if apparently not even all release 
team members were aware of that?


Best regards,
Andreas


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#763148: Prevent migration to jessie


Hi Raphael,

On 05.10.2014 23:01, Raphael Geissert wrote:

I refrained myself from making this comment on the previous debian-devel
thread, but now I consider it necessary to be said: given your apparent lack
of understanding of the situation and way of communicating it only makes me
wonder on the ability to work with you as the maintainer of such a security-
sensitive package that ffmpeg is. I truly hope you understand the
implications of such an impediment.


I always tried to understand the arguments of others and explain my 
point of view extensively.


I'm sorry if this wasn't how it looked to you.

Best regards,
Andreas


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#763148: Prevent migration to jessie