Bug#852216: kodi: FTBFS on mips64el

2017-01-22 Thread Julien Cristau
Source: kodi
Version: 2:17.0~rc3+dfsg1-1
Severity: serious
Justification: fails to build from source (but built successfully in the past)

kodi FTBFS on the mips64el buildd:

> PeripheralCecAdapter.cpp: In member function 'virtual void 
> PERIPHERALS::CPeripheralCecAdapter::Announce(ANNOUNCEMENT::AnnouncementFlag, 
> const char*, const char*, const CVariant&)':
> PeripheralCecAdapter.cpp:169:25: error: 'CEC::libcec_configuration {aka 
> struct CEC::libcec_configuration}' has no member named 'bPowerOnScreensaver'
>  if (m_configuration.bPowerOnScreensaver == 1 && !bIgnoreDeactivate &&
>  ^~~

Full log at
https://buildd.debian.org/status/fetch.php?pkg=kodi=mips64el=2%3A17.0~rc3%2Bdfsg1-1=1484804663=0

Cheers,
Julien

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers


Bug#797204: kodi: FTBFS on armhf (illegal instruction)

2015-08-28 Thread Julien Cristau
Source: kodi
Version: 15.1+dfsg1-2
Severity: serious
Justification: fails to build from source (but built successfully in the past)

Your package no longer builds on the armhf buildds:

 make -C addons/skin.confluence/media
 make[2]: Entering directory 
 '/«BUILDDIR»/kodi-15.1+dfsg1/addons/skin.confluence/media'
 /«BUILDDIR»/kodi-15.1+dfsg1/tools/depends/native/TexturePacker/bin/TexturePacker
  -use_none -input . -output Textures.xbt
 make[2]: *** [Textures.xbt] Illegal instruction
 make[1]: *** [skins] Error 2
 Makefile:13: recipe for target 'Textures.xbt' failed
 make[1]: *** Waiting for unfinished jobs
 make[2]: Leaving directory 
 '/«BUILDDIR»/kodi-15.1+dfsg1/addons/skin.confluence/media'
 Makefile:335: recipe for target 'skins' failed

See full log at
https://buildd.debian.org/status/fetch.php?pkg=kodiarch=armhfver=15.1%2Bdfsg1-2stamp=1440181997

Cheers,
Julien


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian

2014-07-28 Thread Julien Cristau
On Mon, Jul 28, 2014 at 03:39:29 +0200, Andreas Cadhalpun wrote:

 Hi Reinhard,
 
 On 28.07.2014 02:05, Reinhard Tartler wrote:
 On Sun, Jul 27, 2014 at 7:20 PM, Andreas Cadhalpun
 andreas.cadhal...@googlemail.com wrote:
 
   * Does it make sense for me to switch my package?
 The rule of thumb is, if your upstream uses FFmpeg for development
 you probably want to switch to using it, too.
 
 In [1], Moritz from the security team clearly stated that he is more
 than uncomfortable with having more than one copy of libavcodec in
 debian/testing.
 
 I discussed this with Moritz in the ITP bug. Moritz ended this discussion
 [a], and as I wasn't convinced by his arguments, I continued my work. If in
 the end really only one copy is allowed in the next stable release, I think
 it should be FFmpeg.
 
 In consequence this means that any package that builds
 against the ffmpeg packages currently in NEW won't make it into
 testing either. I am therefore surprised about the given answer to the
 question above.
 
 It remains to be seen, what the release team prefers: frustrated users and
 developers or both forks in jessie.
 
The release team is likely to let the people involved in multimedia foo
fight it out among themselves and pick a winner.  We're not going to
ship both and hand that mess over to the security team.

Cheers,
Julien


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: Bug#739079: transition: libav10

2014-05-11 Thread Julien Cristau
On Thu, May  8, 2014 at 20:35:55 -0400, Reinhard Tartler wrote:

 On Tue, May 6, 2014 at 9:39 AM, Bálint Réczey bal...@balintreczey.hu wrote:
 
  When do you plan starting the transition? How about opening it with
  Libav 10.1? ;-)
  I think we are in a pretty good position for startin now.
 
 I agree. Let me upload 10.1 this weekend to unstable to finally start
 this transition.
 
What's the status of the remaining 8 open bugs?  (Mostly interested in
vtk and opencv, since they're the ones with reverse deps, I think.)

Cheers,
Julien


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: Bug#739079: transition: libav10

2014-05-11 Thread Julien Cristau
On Sun, May 11, 2014 at 11:25:49 -0400, Reinhard Tartler wrote:

 for the rest, I'd think that there is a very good chance that the
 respective maintainers are going to fix them before they turn out to
 be actual blockers of the transition. If they do, let's remove them
 temporarily from testing.
 
 I mean, uploading libav10 to unstable will require many additional
 sourceful uploads of package versions that are currently in
 experimental, which will take some time by itself. I'd suggest let's
 start with that.
 
So the fact that it'll require sourceful uploads of lots of packages
with many different maintainers is actually a big part of what makes
this painful for us.  The easiest transitions are the ones where a
rebuild is all that's necessary, and fewer people need to be involved to
upload things at more or less the same time.

Would a timeline like this work for you:
- T: upload libav to unstable
- T+0: upgrade all FTBFS bugs to serious severity, ask maintainers to
  move the updated packages from experimental to sid
- T+1 day (approximately): libav is built on all archs in sid
- T+1 week: libav maintainers (+ anyone else interested) start NMUing
  the remaining packages (without delay)
- T+2 weeks (hopefully): everything is rebuilt and can move to testing
?

For reference last time took 2 months.

Cheers,
Julien


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: Bug#739079: transition: libav10

2014-05-11 Thread Julien Cristau
Control: tag -1 confirmed

On Sun, May 11, 2014 at 12:05:55 -0400, Reinhard Tartler wrote:

 On Sun, May 11, 2014 at 11:50 AM, Julien Cristau jcris...@debian.org wrote:
  Would a timeline like this work for you:
  - T: upload libav to unstable
  - T+0: upgrade all FTBFS bugs to serious severity, ask maintainers to
move the updated packages from experimental to sid
  - T+1 day (approximately): libav is built on all archs in sid
  - T+1 week: libav maintainers (+ anyone else interested) start NMUing
the remaining packages (without delay)
  - T+2 weeks (hopefully): everything is rebuilt and can move to testing
  ?
 
 That would be beautiful. From my side, I would appreciate it very much
 if we could make T==today.
 
  For reference last time took 2 months.
 
 I'll be doing my best to make it happen faster this time.
 
OK, let's go ahead then.

Cheers,
Julien


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#743713: x264: FTBFS on sparc: cc1: error: unrecognized command line option '-fno-aggressive-loop-optimizations'

2014-04-05 Thread Julien Cristau
Source: x264
Version: 2:0.142.2389+git956c8d8-3
Severity: important

See the build log at
https://buildd.debian.org/status/fetch.php?pkg=x264arch=sparcver=2%3A0.142.2389%2Bgit956c8d8-3stamp=1396707861

Looks like that option is not recognized by gcc 4.6.

Cheers,
Julien


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#731061: RM: supercollider-supernova [powerpc sparc] -- NBS; no longer built

2013-12-01 Thread Julien Cristau
Package: ftp.debian.org
Severity: normal

Hi,

from supercollider's changelog (1:3.6.3~repack-4):

  * Do not build/provide supernova on sparc/powerpc (Closes: #728573)

So please remove supercollider-supernova on those archs.

Thanks,
Julien


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: Bug#706798: transition: Libav 9

2013-09-30 Thread Julien Cristau
On Mon, Sep 30, 2013 at 20:26:30 +0200, Sebastian Ramacher wrote:

 dvd-slideshow, dvdwizard, tribler and videotrans still depend on ffmpeg.
 dvd-slideshow would make a good removal candidate. #710411 is open since May 
 and
 has not received a reply from the maintainer.
 
 dvdwizard and videotrans appear on the list of auto-removal candidates. 
 tribler
 has been uploaded recently but still depends on ffmpeg.
 
So, err, dvd-slideshow, dvdwizard and videotrans have the same
Maintainer as libav.  How is this still unfixed?  If these packages are
unmaintained, can the pkg-multimedia team please take care of cleaning
up its cruft?

Cheers,
Julien


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: Bug#699470: crystalhd-dkms: Kernel null pointer BUG in crystalhd_dioq_fetch_wait()

2013-03-01 Thread Julien Cristau
On Fri, Mar  1, 2013 at 21:38:54 +0100, thomas schorpp wrote:

 So no technical reasons to drop the package?
 
Until and unless the driver is in mainline, there's every reason to drop
it.

Cheers,
Julien


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: Bug#699470: crystalhd-dkms: Kernel null pointer BUG in crystalhd_dioq_fetch_wait()

2013-03-01 Thread Julien Cristau
On Fri, Mar  1, 2013 at 12:36:03 -0500, Andres Mejia wrote:

 It looks like the crystalhd drivers are buggy with newer kernel
 releases. I opt for removing the dkms package. I will do this over the
 weekend.
 
Thanks.

Julien


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: Bug#699470: crystalhd-dkms: Kernel null pointer BUG in crystalhd_dioq_fetch_wait()

2013-02-28 Thread Julien Cristau
On Thu, Jan 31, 2013 at 19:25:50 +0100, tom schorpp wrote:

 Package: crystalhd-dkms
 Version: 1:0.0~git20110715.fdd2f19-7
 Severity: critical
 Tags: patch
 Justification: breaks the whole system
 
 Reproducible NULL pointer BUG at 
 crystalhd-0.0~git20110715.fdd2f19/driver/linux/crystalhd_misc.c:515, 
 triggered by adobe flash plugin from dmo repo, ffmpeg, mplayer, bino or 
 other, mostly on heavy ioq usage 
 or after FETCH_TIMEOUT and/or unclosed driver HANDLEs.
 
Does the maintainer or somebody on pkg-multimedia plan on fixing this RC
bug?  If not I'll consider a NMU removing the dkms package from
crystalhd source.

Cheers,
Julien


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: Processed: Re: Bug#687988: blender: Fails to display solid objects with r600/gallium3D

2013-01-29 Thread Julien Cristau
On Tue, Jan 29, 2013 at 09:24:14 +0100, Matteo F. Vescovi wrote:

 Hi!
 
 On Mon, Jan 28, 2013 at 7:46 PM, Julien Cristau jcris...@debian.org wrote:
  When you reassign a bug, please send a mail with the relevant
  information and context to the target package maintainers.  The above is
  just useless.
 
 I thought the history in the bug report was enough to explain the issue.

The difference is the bug report's history is not in my inbox, and if I
have to go read the whole bug log it's never going to happen; if
somebody who already did that (or enough of it to reassign to my
package) can explain their reasoning and summarise the bug in a mail
that gets to me, things become much easier.

Cheers,
Julien

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers


Re: Processed: Re: Bug#687988: blender: Fails to display solid objects with r600/gallium3D

2013-01-28 Thread Julien Cristau
On Mon, Jan 28, 2013 at 10:39:11 +, Debian Bug Tracking System wrote:

 Processing commands for cont...@bugs.debian.org:
 
  reassign 687988 src:mesa 8.0.5-3
 Bug #687988 [blender] blender: Fails to display solid objects with 
 r600/gallium3D
 Bug reassigned from package 'blender' to 'src:mesa'.

When you reassign a bug, please send a mail with the relevant
information and context to the target package maintainers.  The above is
just useless.

Cheers,
Julien


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#685243: vlc: breaks squeeze-wheezy upgrade into very bad state

2013-01-01 Thread Julien Cristau
On Sat, Aug 18, 2012 at 18:20:48 +, Daniel Pocock wrote:

 Package: vlc-nox
 Version: 1.1.3-1squeeze6
 Severity: important
 
 
 My box is amd64, running squeeze
 
 I started an upgrade to wheezy,
 
 apt-get upgrade
 
 was successful.  Then I ran
 
 apt-get dist-upgrade
 
 and it failed here:
 
 Processing triggers for vlc-nox ...
 /usr/lib/vlc/vlc-cache-gen: error while loading shared libraries:
 libvlccore.so.5: cannot open shared object file: No such file or directory
 dpkg: error processing vlc-nox (--unpack):
  subprocess installed post-installation script returned error exit
 status 127
 configured to not write apport reports
   Errors were encountered while
 processing:
  vlc-nox
 E: Sub-process /usr/bin/dpkg returned an error code (1)
 
Please provide the full upgrade log and contents of /var/lib/dpkg/status
before and after the upgrade.

I suspect this is yet another case of dpkg triggering unconfigured
packages (#671711).  Which dpkg maintainers don't plan on fixing, and
recommend working around in other packages.  Except I'm not aware of any
work-around having been suggested.

Cheers,
Julien


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#683247: unblock libav/6:0.8.3-6

2012-08-04 Thread Julien Cristau
On Sat, Aug  4, 2012 at 11:45:40 +0200, Reinhard Tartler wrote:

 On Mon, Jul 30, 2012 at 2:17 PM, Adam D. Barratt
 a...@adam-barratt.org.uk wrote:
  On 30.07.2012 08:08, Reinhard Tartler wrote:
 
  I intend to work on a new upload that incorporates your suggestions
  for clarifying the debian/changelog file this week. If you don't mind,
  I'd leave the doxygen and the Provides: ffmpeg changes as-is.
  Additionally, I intend to change ffmpeg-dbg from Arch: any to arch:
  all for consistency with libav-extra-dbg (both are empty, transitional
   packages).
 
 
  That sounds fine to me; thanks.  Please let us know (and retitle the libav
  unblock bug appropriately) once that's been done.
 
 I'm doing so with this email. Please consider adjusting the time that
 is required for migration.
 
Unblocked.

Cheers,
Julien


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#678997: libavutil51: binnmu broke multiarch co-installability

2012-06-25 Thread Julien Cristau
On Mon, Jun 25, 2012 at 18:38:37 +0200, Reinhard Tartler wrote:

 Debian-release, are you OK with a new upload to fix this?
 
No objection.

 How can we avoid this problem in the future?
 
Fix dpkg/sbuild.

Cheers,
Julien


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#671302: libav: circular dependency between libav and opencv

2012-05-03 Thread Julien Cristau
On Thu, May  3, 2012 at 10:20:57 -0400, Andres Mejia wrote:

 I'm not entirely certain how build circular dependency issues like this are
 resolved. Perhaps we should ask for help from the toolchain package
 maintainers or debian-devel.

What's wrong with just disabling opencv?

Cheers,
Julien


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#670338: libquicktime-dev: FTBFS on hurd.

2012-04-24 Thread Julien Cristau
On Tue, Apr 24, 2012 at 19:02:51 +, Cyril Roelandt wrote:

 Package: libquicktime-dev
 Severity: serious
 Tags: patch
 Justification: fails to build from source
 
Bugs affecting non-release architectures never have a severity bigger
than important.

Cheers,
Julien


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#669988: libavformat53: arch-dependent files in multiarch: same package

2012-04-22 Thread Julien Cristau
Package: libavformat53
Version: 5:0.8.1-4
Severity: important
User: multiarch-de...@lists.alioth.debian.org
Usertags: multiarch

Hi,

libavformat53 is marked as Multi-Arch: same, but contains files in
arch-independent paths with arch-specific contents:

[libavformat53 5:0.8.1-4]
usr/share/doc/libavformat53/formats.txt.gz
  0a16d10e30dbe3abe9eeeaec9c2d4cef kfreebsd-i386 kfreebsd-amd64
  fad5bc1f202b35a5822af28da99b1e4d s390 amd64 i386 powerpc sparc armhf ia64 
mips mipsel

diff between the kfreebsd-amd64 and amd64 files:

@@ -17,6 +17,7 @@
  D  aea MD STUDIO audio
  DE aiffAudio IFF
  DE alawPCM A-law format
+ DE alsaALSA audio output
  DE amr 3GPP AMR file format
  D  anm Deluxe Paint Animation
  D  apc CRYO APC format
@@ -32,7 +33,6 @@
  D  bethsoftvid Bethesda Softworks VID format
  D  bfi Brute Force  Ignorance
  D  binkBink
- D  bktrvideo grab
  D  bmv Discworld II BMV
  D  c93 Interplay C93
  D  caf Apple Core Audio Format
@@ -46,6 +46,7 @@
  D  dsicin  Delphine Software International CIN format
  DE dts raw DTS
  DE dv  DV video format
+ D  dv1394  DV1394 A/V grab
   E dvd MPEG-2 PS format (DVD VOB)
  D  dxa DXA
  D  ea  Electronic Arts Multimedia Format
@@ -55,6 +56,7 @@
  DE f32le   PCM 32 bit floating-point little-endian format
  DE f64be   PCM 64 bit floating-point big-endian format
  DE f64le   PCM 64 bit floating-point little-endian format
+ D  fbdev   Linux framebuffer
  DE ffm FFM (AVserver live feed) format
  DE ffmetadata  FFmpeg metadata in text format
  D  film_cpkSega FILM/CPK format
@@ -83,6 +85,7 @@
  D  jv  Bitmap Brothers JV
  DE latmLOAS/LATM
  D  libcdio  
+ D  libdc1394   dc1394 v.2 A/V grab
  D  lmlm4   lmlm4 raw format
  D  lxf VR native stream format (LXF)
  DE m4v raw MPEG-4 video format
@@ -173,7 +176,6 @@
  D  vc1 raw VC-1
  D  vc1test VC-1 test bitstream format
   E vcd MPEG-1 System format (VCD)
- D  video4linux Video4Linux device grab
  D  video4linux2Video4Linux2 device grab
  D  vmd Sierra VMD format
   E vob MPEG-2 PS format (VOB)

Cheers,
Julien


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#669999: libgpac-dev: arch-dependent files in multiarch: same package

2012-04-22 Thread Julien Cristau
Package: libgpac-dev
Version: 0.4.5+svn4019~dfsg0-2
Severity: important
User: multiarch-de...@lists.alioth.debian.org
Usertags: multiarch

Hi,

libgpac-dev is marked as Multi-Arch: same, but contains files in
arch-independent paths with arch-specific contents:

[libgpac-dev 0.4.5+svn4019~dfsg0-2]
usr/include/gpac/configuration.h

Cheers,
Julien


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#670032: libwxsvg-dev: arch-dependent files in multiarch: same package

2012-04-22 Thread Julien Cristau
Package: libwxsvg-dev
Version: 2:1.1.8~dfsg0-1
Severity: important
User: multiarch-de...@lists.alioth.debian.org
Usertags: multiarch

Hi,

libwxsvg-dev is marked as Multi-Arch: same, but contains files in
arch-independent paths with arch-specific contents:

[libwxsvg-dev 2:1.1.8~dfsg0-1]
usr/share/doc/libwxsvg-dev/examples/test.svg
  31826c9c922faef0272dace46ca79514 ia64 s390x kfreebsd-amd64 amd64
  ba5f2d4df6629c7fed6a12f660406deb s390 i386 powerpc sparc armel armhf mips 
kfreebsd-i386 mipsel

Specifically:
$ diff -u (dpkg --fsys-tarfile 
/srv/ftp-master.debian.org/ftp/pool/main/w/wxsvg/libwxsvg-dev_1.1.8~dfsg0-1_s390.deb
 | tar xOf - ./usr/share/doc/libwxsvg-dev/examples/test.svg ) (dpkg 
--fsys-tarfile 
/srv/ftp-master.debian.org/ftp/pool/main/w/wxsvg/libwxsvg-dev_1.1.8~dfsg0-1_amd64.deb
 | tar xOf - ./usr/share/doc/libwxsvg-dev/examples/test.svg )
--- /dev/fd/63  2012-04-22 13:08:21.822071847 +
+++ /dev/fd/62  2012-04-22 13:08:21.822071847 +
@@ -11,7 +11,7 @@
  rect id=rect2365 height=100 width=200 stroke=red y=10 x=10 
stroke-width=2 fill=blue/
  rect id=rect2367 rx=10 ry=10 height=100 width=200 stroke=red 
y=10 x=220 stroke-width=2 fill=blue/
  line id=line2369 stroke-width=10 y2=100 x2=200 stroke=red y1=20 
x1=20/
- line id=line2371 y2=20 stroke-width=10 x2=200 stroke=red y1=100 
x1=20/
+ line id=line2371 y2=20 x1=20 x2=200 stroke=red y1=100 
stroke-width=10/
  circle id=circle2373 cy=220 cx=110 r=90 
style=stroke:red;fill:#8080FF/
  g id=g2386
   path id=ellipse2375 style=stroke:#f00;fill:#80ff80 d=m430 220c0 
38.64-49.28 70-110 70s-110-31.36-110-70 49.28-70 110-70 110 31.36 110 70z/

Cheers,
Julien


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#667504: libav-tools: bus error on sparc encoding vp8

2012-04-05 Thread Julien Cristau
On Wed, Apr  4, 2012 at 10:04:25 -0400, Jack Hill wrote:

 Package: libav-tools
 Version: 4:0.8.1-1
 Severity: normal
 
 Dear Maintainer,
 
 Using the avconv executable to encode a video with the vp8 codec (via libvpx) 
 fails with a bus error. This happens with both webm and mkv containers.
 The error does not happen if a different codec is chosen (e.g. libtheora).
 
 To reproduce:
 0) get a video encoded in something other than vp8 (I used youtube-dl to get 
 an h.264 encoded video).
 1) try to transcode it with
 avconv -i infile.mp4 outfile.webm
 (avconv automatically chooses libvpx for a .webm file)
 2) observe failure.
 
 I will appily provide more debuggin information if provided with instructions 
 for obtaining.
 
Get debug symbols for avconv and the relevant libraries (at least libav*
and libvpx).  There'll either be a -dbg package in the archive, or you
can rebuild from source with DEB_BUILD_OPTIONS=nostrip set in the build
environment.  Then run avconv in gdb, and get a full backtrace when it
crashes.

See also http://wiki.debian.org/HowToGetABacktrace

Cheers,
Julien


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#660934: vlc: FTBFS on armel

2012-02-22 Thread Julien Cristau
Source: vlc
Version: 2.0.0-1
Severity: serious
Justification: fails to build from source (but built successfully in the past)

vlc FTBFS on the armel buildd, with:
 /bin/bash: line 4: 32312 Segmentation fault  ./vlc-cache-gen ../modules

See the build log at
https://buildd.debian.org/status/fetch.php?pkg=vlcarch=armelver=2.0.0-1stamp=1329552344

Cheers,
Julien


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#660935: vlc: FTBFS on kfreebsd-*

2012-02-22 Thread Julien Cristau
Source: vlc
Version: 2.0.0-1
Severity: serious
Justification: fails to build from source (but built successfully in the past)

vlc FTBFS on the kfreebsd buidds:
 posix/thread.c: In function 'vlc_cond_timedwait':
 posix/thread.c:456:3: error: #error FIXME: breaks vlc_cond_init_daytime()
 make[2]: *** [posix/thread.lo] Error 1

See the build logs linked from
https://buildd.debian.org/status/package.php?p=vlc

Cheers,
Julien


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#660936: vlc: FTBFS on powerpc

2012-02-22 Thread Julien Cristau
Source: vlc
Version: 2.0.0-1
Severity: serious
Justification: fails to build from source (but built successfully in the past)

vlc FTBFS on powerpc with:
 libtool: compile:  gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../.. 
 -DMODULE_NAME=i420_yuy2_altivec -DMODULE_NAME_IS_i420_yuy2_altivec 
 -DMODULE_STRING=\i420_yuy2_altivec\ -D__PLUGIN__ -I../../include 
 -I../../include -g -O2 -Wall -Wextra -Wsign-compare -Wundef -Wpointer-arith 
 -Wbad-function-cast -Wwrite-strings -Wmissing-prototypes 
 -Wvolatile-register-var -Werror-implicit-function-declaration -pipe 
 -fvisibility=hidden -ffast-math -funroll-loops -fomit-frame-pointer -mtune=G4 
 -c ../video_chroma/i420_yuy2.c  -fPIC -DPIC -o 
 .libs/libi420_yuy2_altivec_plugin_la-i420_yuy2.o
 In file included from memcpy.c:39:0:
 /usr/lib/gcc/powerpc-linux-gnu/4.6/include/altivec.h:35:2: error: #error Use 
 the -maltivec flag to enable PowerPC AltiVec support

See the build log at
https://buildd.debian.org/status/fetch.php?pkg=vlcarch=powerpcver=2.0.0-1stamp=1329537251

Cheers,
Julien


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#653887: libavformat53 breaks mplayer

2012-01-01 Thread Julien Cristau
On Sun, Jan  1, 2012 at 08:25:00 +0100, Reinhard Tartler wrote:

 reassign 653887 mplayer 2:1.0~rc4.dfsg1-1
 stop
 
 Happy new year, Brian!
 
 On So, Jan 01, 2012 at 02:37:37 (CET), Brian Paterni wrote:
 
  Package: libavformat53
  Version: 4:0.8~beta1-1
  Severity: serious
  Justification: 5
 
  Dear Maintainer,
 
  libavformat53 in experimental seems to have broken mplayer's ability to
  playback files. After upgrading to 4:0.8~beta1-1, mplayer reports the 
  following
  whenever I attempt to play something:
 
  mplayer: relocation error: mplayer: symbol ff_codec_wav_tags, version
  LIBAVFORMAT_53 not defined in file libavformat.so.53 with link time 
  reference
 
 I really think this is a bug in mplayer. ff_codec_wav_tags is and always
 was an internal symbol, that is no longer exported since this commit:
 
 http://git.libav.org/?p=libav.git;a=commitdiff;h=8d74bf17c6d6280195854f4dadb19ef37d054566
 
 This issue a long-standing wart in mplayer that should really be fixed
 there.
 
It should *also* be fixed in libavformat53 by adding Breaks against
unfixed versions of mplayer.

Cheers,
Julien



___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers


Bug#653887: libavformat53 breaks mplayer

2012-01-01 Thread Julien Cristau
On Sun, Jan  1, 2012 at 08:25:00 +0100, Reinhard Tartler wrote:

 I really think this is a bug in mplayer. ff_codec_wav_tags is and always
 was an internal symbol, that is no longer exported since this commit:
 
 http://git.libav.org/?p=libav.git;a=commitdiff;h=8d74bf17c6d6280195854f4dadb19ef37d054566
 
 This issue a long-standing wart in mplayer that should really be fixed
 there.
 
Honestly, this is kind of a broken position IMO.  The moment one of your
reverse deps uses a symbol, it stops being internal, whatever your
intentions were.

Cheers,
Julien



___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers


Re: Bug#651197: RM: desktopcouch/1.0.8-1

2011-12-06 Thread Julien Cristau
On Tue, Dec  6, 2011 at 17:50:18 +0100, David Paleino wrote:

 Package: release.debian.org
 Severity: normal
 User: release.debian@packages.debian.org
 Usertags: rm
 
 Hello,
 please remove desktopcouch from testing, since it's currently unusable at all
 (see bug #651142, X-Debbugs-CCed). I just raised that bug's severity to grave.
 
 However, it has some rdepends, all coming from the same source package: 
 dmedia.
 I don't know if I'm required to contact dmedia's maintainers before asking
 removal of desktopcouch -- in any case, they are CCed.
 
Removal hint added for both.

Cheers,
Julien

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers


Bug#650363: Once again tries to find driver from wrong place

2011-11-29 Thread Julien Cristau
On Tue, Nov 29, 2011 at 10:10:56 +0200, Juhapekka Tolvanen wrote:

 Package: vainfo
 Version: 1.0.14-1
 Severity: grave
 
 
 juhtolv@juhtolv:/home/juhtolv % vainfo   
 libva: libva version 0.32.0
 libva: va_getDriverName() returns 0
 libva: Trying to open /usr/lib/dri/mga_drv_video.so
 libva: va_openDriver() returns -1
 vaInitialize failed with error code -1 (unknown libva error),exit
 [1]3304 exit 3 vainfo
 juhtolv@juhtolv:/home/juhtolv % ls -la /usr/lib/dri 
 yhteensä 200
 drwxr-xr-x   2 root root   4096 marra 22 04:11 ./
 drwxr-xr-x 384 root root 180224 marra 27 15:39 ../
 -rw-r--r--   1 root root  15672 loka  31 21:56 dummy_drv_video.so
 juhtolv@juhtolv:/home/juhtolv % locate mga_drv   
 /usr/lib/xorg/modules/drivers/mga_drv.so
 juhtolv@juhtolv:/home/juhtolv % ls /usr/lib/xorg/modules/drivers
 mga_drv.so

That's an X driver, nothing to do with va.  Pretty sure there doesn't
even exist a mga va driver.

Cheers,
Julien



___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers


Re: Upcoming Libav 0.7 transition

2011-09-01 Thread Julien Cristau
On Sun, May  1, 2011 at 18:46:27 +0200, Reinhard Tartler wrote:

 Hi,
 
 I'd like to ask for permission to start a new Libav (the new FFmpeg)
 transition in unstable. The current package can be seen in experimental,
 basically all libraries bumped SONAME, so that the new release is
 co-installable with the Libav 0.6 series.
 
Sorry for the delay.  Please feel free to go ahead with this.

Cheers,
Julien

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers


Bug#635724: marked as done (vlc: FTBFS (kfreebsd-i386) Segmentation fault (core dumped) ../bin/vlc-cache-gen .)

2011-08-11 Thread Julien Cristau
On Wed, Aug 10, 2011 at 14:09:21 +0200, Reinhard Tartler wrote:

 Hi,
 
 now with qt4-x11 fixed, I'm very confident that vlc can be built again
 on kfreebsd-i386. Can you therefore please set a dep-wait for vlc on
 qt4-x11 version 4:4.7.3-6? I believe the syntax is:
 
 dw vlc_1.1.11-2 . kfreebsd-i386 . -m 'qt4-x11 (= 4:4.7.3-6)'
 
I didn't see this mail until now, but I gave back vlc on ki earlier
today, and it built.

Cheers,
Julien



___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers


Re: Bug#614726: FFmpeg 0.6 transition

2011-03-03 Thread Julien Cristau
On Wed, Mar  2, 2011 at 12:39:19 +0100, Julien Cristau wrote:

 urgent amide/0.9.2-1.1
 urgent soundtouch/1.5.0-4
 urgent portaudio19/19+svn20101113-3
 urgent pcre3/8.12-3

pcre3 now migrated on its own

 urgent zoneminder/1.24.2-9

will be 10 days old tonight

 urgent audacity/1.3.12-14
 urgent gst-plugins-bad0.10/0.10.19-2.1
 # link ocaml and ffmpeg transitions, not good 
 remove liquidsoap/0.9.2-3 ocaml-soundtouch/0.1.5-1 liq-contrib/08.11-1
 # ftbfs on armel, unmaintained (#598933)
 remove ktoon/0.8.1-4.1

we can keep ktoon as long as we keep libavutil49

 # ftbfs (#615563)
 remove cherokee/1.0.8-5

same

 # ftbfs (#615654)
 remove ihu/0.6.0-2
 # obsolete binary needs decrufting
 force soundtouch/1.5.0-4
 
and one I forgot:
# #612473 - siretart says mplayer-gui is going away anyway
force mplayer/2:1.0~rc4.dfsg1-1

 hint ffmpeg/4:0.6.1-5 soundtouch/1.5.0-4 gst-plugins-bad0.10/0.10.19-2.1
 
Test run result at
http://release.debian.org/~jcristau/britney/update_output.txt

Cheers,
Julien

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: Bug#614726: FFmpeg 0.6 transition

2011-03-02 Thread Julien Cristau
Hi,

the ffmpeg transition got entangled with soundtouch (libsoundtouch1c2 →
libsoundtouch0), vtk (5.4 → 5.6), and now with gdal (through
openscenegraph).  While soundtouch is close to ready, a number of vtk's
reverse deps FTBFS, and afaik gdal has barely started, so I'm looking at
separating these out.

So I'm thinking of temporarily keeping libavutil49 in testing, with
something like this:

diff --git a/britney b/britney
index 3069203..1fc7d33 100755
--- a/britney
+++ b/britney
@@ -137,6 +137,10 @@ pkg_lists () {
   for di_pkg_file in 
$suite_dir/{main,contrib,non-free}/debian-installer/binary-$arch/Packages.gz; do
   test -f $di_pkg_file  zcat $di_pkg_file | dedupe_pkg_list 
$1/$suite/Packages_$arch
   done
+ # XXX ugly hack, close your eyes.
+  if [ -f $FTP_MIRROR/dists/testing/main/binary-$arch/Packages.gz ]; 
then
+  zcat $FTP_MIRROR/dists/testing/main/binary-$arch/Packages.gz | 
grep-dctrl -FPackage libavutil49 -a -X -FSource ffmpeg | sed -e 
's/^Source:.*/Source: ffmpeg0.5/' $1/$suite/Packages_$arch
+  fi
   done
   done
   $FAUXPKG_SCRIPT generate $1/testing $1/unstable

I'm hoping since libavutil has versioned symbols having two versions in
testing for a little while won't be too much of a problem.

A test run with the following set of hints looks like it would work,
once the missing builds for audacity and gst-plugins-bad0.10 are in:

urgent amide/0.9.2-1.1
urgent soundtouch/1.5.0-4
urgent portaudio19/19+svn20101113-3
urgent pcre3/8.12-3
urgent zoneminder/1.24.2-9
urgent audacity/1.3.12-14
urgent gst-plugins-bad0.10/0.10.19-2.1
# link ocaml and ffmpeg transitions, not good 
remove liquidsoap/0.9.2-3 ocaml-soundtouch/0.1.5-1 liq-contrib/08.11-1
# ftbfs on armel, unmaintained (#598933)
remove ktoon/0.8.1-4.1
# ftbfs (#615563)
remove cherokee/1.0.8-5
# ftbfs (#615654)
remove ihu/0.6.0-2
# obsolete binary needs decrufting
force soundtouch/1.5.0-4

hint ffmpeg/4:0.6.1-5 soundtouch/1.5.0-4 gst-plugins-bad0.10/0.10.19-2.1

Thoughts?

Cheers,
Julien

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Bug#615968: slv2-doc: missing replaces/conflicts on libslv2-9

2011-03-01 Thread Julien Cristau
Package: slv2-doc
Version: 0.6.6-8
Severity: serious

When moving files between packages, you need to take care of the upgrade
path...

Cheers,
Julien



___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Bug#615847: libslv2-9: manpages need to be moved to libslv2-dev

2011-02-28 Thread Julien Cristau
Package: libslv2-9
Version: 0.6.6-5
Severity: serious

Hi,

shared library packages should never include non-SONAME-versioned files,
to allow co-installability of different ABIs.  Plus the documentation
for a library makes no sense in the runtime package anyway.

Cheers,
Julien

-- System Information:
Debian Release: 6.0
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'squeeze-updates'), (500, 
'proposed-updates'), (500, 'oldstable'), (500, 'unstable'), (500, 'testing'), 
(101, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages libslv2-9 depends on:
ii  libc6 2.11.2-10  Embedded GNU C Library: Shared lib
ii  libraptor11.4.21-2   Raptor RDF parser and serializer l
ii  librasqal20.9.20-1   Rasqal RDF query library
ii  librdf0   1.0.10-3   Redland Resource Description Frame

libslv2-9 recommends no packages.

Versions of packages libslv2-9 suggests:
pn  slv2-jack none (no description available)

-- no debconf information



___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Bug#615140: libsoundtouch-dev: needs to provide libsoundtouch1-dev

2011-02-25 Thread Julien Cristau
Package: libsoundtouch-dev
Version: 1.5.0-3
Severity: serious
Justification: i said so

Apparently you decided to start a SONAME transition with no coordination
with the release team.  This will clash with the ongoing transition to
ffmpeg 0.6, and delay things by that much.  Please don't do this again.

Now that's out of the way...

You also renamed your -dev package from libsoundtouch1-dev to
libsoundtouch-dev, which means every reverse dependency not only needs
to be rebuilt, but needs sourceful changes.  Unless the API is
completely different from the old version, that's not acceptable.
Please add 'Provides: libsoundtouch1-dev' to libsoundtouch-dev so we can
rebuild reverse dependencies.

Cheers,
Julien



___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Bug#614726: FFmpeg 0.6 transition

2011-02-22 Thread Julien Cristau
Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: transition

On Sun, Feb  6, 2011 at 14:29:33 +0100, Reinhard Tartler wrote:

 Hi,
 
 First of all, congratulations on the release!
 
 FYI: I just accepted mehdis offer from debconf 10 to upload ffmpeg just
 after the squeeze release. I've got a lot of pings and flames that this
 wasn't included in squeeze, we discussed this to death in NYC, and
 therefore just went ahead.
 
Filing as a bug so I can mark blockers.

Cheers,
Julien



___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Bug#613411: More info

2011-02-21 Thread Julien Cristau
On Tue, Feb 15, 2011 at 08:10:52 -0800, Dave Beckett wrote:

 The desc should never be NULL since it's running through a list from raptor,
 and the final one is to get the default parser.  The only way this can
 happen is if raptor wasn't initialised properly, which is my guess here.  I
 suspect ardour is linking to raptor1 and raptor2, and thus crashing.
 
I don't know the impact there, but this may also be a problem with
redland-bindings (librdf-perl, librdf-ruby, php5-librdf, python-librdf),
slv2 (libslv2-9, slv2-jack), soprano (soprano-daemon) in sid, which
depend on both librdf0 and libraptor1.

Cheers,
Julien



___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: [SRM] Approval for libmms_0.6-1squeeze1

2011-02-19 Thread Julien Cristau
On Mon, Feb  7, 2011 at 10:52:43 +0100, Fabian Greffrath wrote:

 +--- libmms.orig/src/bswap.h
  libmms/src/bswap.h
 +@@ -21,23 +21,50 @@
 +  */
 + 
 + 
 +-/* Go cheap now, will rip out glib later. *Sigh* */
 +-#include glib.h
 ++#include stdint.h
 + 
 +-/* NOTE:
 +- * Now, to clear up confusion: LE_XX means from LE to native, XX bits wide
 +- * I know it's not very clear naming (tell me about it, I
 +- * misinterpreted in first version and caused bad nasty bug, *sigh*),
 +- * but that's inherited code, will clean up as things go
 +- * Oh, and one more thing -- they take *pointers*, not actual ints
 +- */
 +-
 +-#define LE_16(val) (GINT16_FROM_LE (*((u_int16_t*)(val
 +-#define BE_16(val) (GINT16_FROM_BE (*((u_int16_t*)(val
 +-#define LE_32(val) (GINT32_FROM_LE (*((u_int32_t*)(val
 +-#define BE_32(val) (GINT32_FROM_BE (*((u_int32_t*)(val
 +-
 +-#define LE_64(val) (GINT64_FROM_LE (*((u_int64_t*)(val
 +-#define BE_64(val) (GINT64_FROM_BE (*((u_int64_t*)(val
 ++#define SWAP_ENDIAN_16(val) \
 ++(val[1] | (val[0]  8))

So this looks weird to me.  That macro looks like it's doing big endian
to native, not swap.  And the SAME_ENDIAN_* macros smell like little
endian to native.  Which means this is broken on BE.  Am I missing
something?

 ++#define SWAP_ENDIAN_32(val) \
 ++(val[3] | (val[2]  8) | (val[1]  16) | (val[0]  24))
 ++#define SWAP_ENDIAN_64(val) \
 ++(val[7] | (val[6]  8) | (val[5]  16) | (val[4]  24) | \
 ++((uint64_t)val[3]  32) | ((uint64_t)val[2]  40) | \
 ++((uint64_t)val[1]  48) | ((uint64_t)val[0]  56))
 ++
 ++#define SAME_ENDIAN_16(val) \
 ++(val[0] | (val[1]  8))
 ++#define SAME_ENDIAN_32(val) \
 ++(val[0] | (val[1]  8) | (val[2]  16) | (val[3]  24))
 ++#define SAME_ENDIAN_64(val) \
 ++(val[0] | (val[1]  8) | (val[2]  16) | (val[3]  24) | \
 ++((uint64_t)val[4]  32) | ((uint64_t)val[5]  40) | \
 ++((uint64_t)val[6]  48) | ((uint64_t)val[7]  56))
 ++

Cheers,
Julien

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Bug#613411: ardour-i686: segfault when starting

2011-02-14 Thread Julien Cristau
cc:ing the redland maintainer.

On Mon, Feb 14, 2011 at 17:35:32 +0100, Adrian Knoth wrote:

 Package: ardour-i686
 Version: 1:2.8.11-4
 Severity: grave
 Justification: renders package unusable
 
 Hi!
 
 When starting ardour, it currently fails with a segfault:
 
 raptor_sequence.c:385: (raptor_sequence_get_at) assertion failed: object
 pointer of type raptor_sequence is NULL.
 raptor_sequence.c:385: (raptor_sequence_get_at) assertion failed: object
 pointer of type raptor_sequence is NULL.
 
 Program received signal SIGSEGV, Segmentation fault.
 0xb65bd932 in librdf_parser_raptor_constructor () from
 /usr/lib/librdf.so.0
 (gdb) bt
 #0  0xb65bd932 in librdf_parser_raptor_constructor () from
 /usr/lib/librdf.so.0
 #1  0xb65bd7ad in librdf_init_parser () from /usr/lib/librdf.so.0
 #2  0xb65aeca5 in librdf_world_open () from /usr/lib/librdf.so.0
 #3  0xb64f239c in slv2_world_new () from /usr/lib/libslv2.so.9
 #4  0xb7f6bb09 in ARDOUR::LV2World::LV2World() () from 
 /usr/lib/ardour2/libardour.so
 #5  0xb7eb0f44 in ARDOUR::PluginManager::PluginManager() () from 
 /usr/lib/ardour2/libardour.so
 #6  0xb7e5be04 in ARDOUR::init(bool, bool) () from 
 /usr/lib/ardour2/libardour.so
 #7  0x0815d512 in ARDOUR_UI::ARDOUR_UI(int*, char***) ()
 #8  0x0838c2bb in main ()
 
 
 Since I maintain the package, I file this bug for reference and
 documentation purpose.
 
 Note: recompiling against current librdf0 (1.0.13-1) fails, so it seems
 there is a larger API change in librdf:
 
 /usr/include/rasqal/rasqal.h:1021: error: 'raptor_log_handler' has not been 
 declared
 
 
 Let's see.
 
 -- System Information:
 Debian Release: wheezy/sid
   APT prefers unstable
   APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
 Architecture: i386 (i686)
 
 Kernel: Linux 2.6.37 (SMP w/2 CPU cores; PREEMPT)
 Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to 
 en_US.UTF-8)
 Shell: /bin/sh linked to /bin/bash
 
 Versions of packages ardour-i686 depends on:
 ii  jackd  5 JACK Audio Connection Kit 
 (default
 ii  libart-2.0-2   2.3.21-1  Library of functions for 2D 
 graphi
 ii  libasound2 1.0.23-2.1shared library for ALSA 
 applicatio
 ii  libatk1.0-01.30.0-1  The ATK accessibility toolkit
 ii  libaubio2  0.3.2-4+b2a library for audio segmentation
 ii  libc6  2.11.2-11 Embedded GNU C Library: Shared 
 lib
 ii  libcairo2  1.10.2-2  The Cairo 2D vector graphics 
 libra
 ii  libcairomm-1.0-1   1.8.4-3   C++ wrappers for Cairo (shared 
 lib
 ii  libcurl3-gnutls7.21.3-1  Multi-protocol file transfer 
 libra
 ii  libfftw3-3 3.2.2-1   library for computing Fast 
 Fourier
 ii  libfontconfig1 2.8.0-2.1 generic font configuration 
 library
 ii  libfreetype6   2.4.2-2.1 FreeType 2 font engine, shared 
 lib
 ii  libgcc11:4.5.0-1 GCC support library
 ii  libglib2.0-0   2.28.0-1  The GLib library of C routines
 ii  libglibmm-2.4-1c2a 2.24.2-1  C++ wrapper for the GLib toolkit 
 (
 ii  libgnomecanvas2-0  2.30.1-1  A powerful object-oriented 
 display
 ii  libgnomecanvasmm-2.6-1 2.26.0-1  C++ wrappers for libgnomecanvas2 
 (
 ii  libgtk2.0-02.20.1-2  The GTK+ graphical user 
 interface 
 ii  libgtkmm-2.4-1c2a  1:2.20.3-1C++ wrappers for GTK+ (shared 
 libr
 ii  libjack-jackd2-0 [libj 1.9.6~dfsg.1-2JACK Audio Connection Kit 
 (librari
 ii  liblo7 0.26~repack-5 Lightweight OSC library
 ii  liblrdf0   0.4.0-3   a library to manipulate RDF 
 files 
 ii  libpango1.0-0  1.28.3-1+squeeze1 Layout and rendering of 
 internatio
 ii  libpangomm-1.4-1   2.26.2-1  C++ Wrapper for pango (shared 
 libr
 ii  libraptor1 1.4.21-2  Raptor RDF parser and serializer 
 l
 ii  librasqal2 0.9.20-1  Rasqal RDF query library
 ii  librdf01.0.13-1  Redland Resource Description 
 Frame
 ii  libsamplerate0 0.1.7-3   Audio sample rate conversion 
 libra
 ii  libsigc++-2.0-0c2a 2.2.4.2-1 type-safe Signal Framework for 
 C++
 ii  libslv2-9  0.6.6-5   A library for simple use of LV2 
 pl
 ii  libsndfile11.0.23-1  Library for reading/writing 
 audio 
 ii  libstdc++6 4.5.0-1   The GNU Standard C++ Library v3
 ii  libusb-0.1-4   2:0.1.12-17   userspace USB programming library
 ii  libvamp-hostsdk3   2.1-1 helper library for Vamp hosts 
 writ
 ii  libvamp-sdk2   2.1-1 helper library for Vamp plugins 
 wr
 ii  libxml22.7.8.dfsg-2  GNOME XML library
 ii  libxslt1.1 1.1.26-6  XSLT 1.0 processing library - 
 runt
 ii  python   

Bug#613292: wsynth-dssi: uninstallable on kfreebsd

2011-02-13 Thread Julien Cristau
Package: wsynth-dssi
Version: 0.1.3-3
Severity: serious

The wsynth-dssi package depends on dssi-host-jack, which is not
available on kfreebsd.

Cheers,
Julien



___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Bug#612438: ffmpeg: libva-dev is linux-only

2011-02-08 Thread Julien Cristau
Package: ffmpeg
Version: 4:0.6.1-4
Severity: serious
Justification: fails to build from source

The build-dependency on libva-dev prevents ffmpeg building on !linux
archs.  Please make it linux-only (or get libva to build on !linux, if
that makes more sense).

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

Cheers,
Julien


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Bug#608680: Only supported for x86 target

2011-01-02 Thread Julien Cristau
On Sun, Jan  2, 2011 at 19:50:16 +0100, Thomas Preud'homme wrote:

 -march=native is only supported for (Intel 386 and AMD x86-64)-like targets. 
 A 
 simple solution would be to just disable this flag. Another option would be 
 to 
 populate CPPFLAGS in debian/rules with -march=native depending on the output 
 of dpkg-architecture and the value of DEB_BUILD_OPTIONS.

-march=native is always ABSOLUTELY WRONG when building debian packages.
Please think about it for 5 seconds.

Cheers,
Julien


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: Freeze exception for csound?

2010-12-26 Thread Julien Cristau
On Sat, Nov 13, 2010 at 21:13:58 -0300, Felipe Sateler wrote:

 Dear release team,
 
 Recently, a bug was reported against csound (#603321), which was
 already fixed in upstream CVS. The bug is severity: normal, although
 one could argue for a higher severity given that it segfaults whenever
 using a certain opcode.
 
This is not migrating to testing because it ftbfs on sparc.
https://buildd.debian.org/build.php?pkg=csoundver=1%3A5.12.1~dfsg-6arch=sparcfile=log

Cheers,
Julien


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: Freeze exception for csound?

2010-12-17 Thread Julien Cristau
On Thu, Dec 16, 2010 at 20:37:40 -0300, Felipe Sateler wrote:

 Uploaded. Thanks!
 
and unblocked.

Cheers,
Julien


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Bug#605507: your mail

2010-12-17 Thread Julien Cristau
On Mon, Dec  6, 2010 at 19:06:59 +0900, d+...@vdr.jp wrote:

 tags 605507 + patch
 thanks
 
 Hi,
 
 Here is third try.
 Would you please try it?
 
 diff -u icecast2-2.3.2/debian/icecast2.init 
 icecast2-2.3.2/debian/icecast2.init
 --- icecast2-2.3.2/debian/icecast2.init   2010-12-06 18:48:19.0 
 +0900
 +++ icecast2-2.3.2/debian/icecast2.init   2010-12-06 18:38:24.0 
 +0900
 @@ -51,7 +51,8 @@
   ;;
stop)
   echo -n Stopping $DESC: 
 - start-stop-daemon --stop --oknodo --quiet --exec $DAEMON
 + # Send TERM after 5 seconds, wait at most 30 seconds.
 + start-stop-daemon --stop --oknodo --retry TERM/5/0/30 --quiet --exec 
 $DAEMON
   echo $NAME.
   ;;
reload|force-reload)
 diff -u icecast2-2.3.2/debian/icecast2.postinst 
 icecast2-2.3.2/debian/icecast2.postinst
 --- icecast2-2.3.2/debian/icecast2.postinst   2010-12-06 18:48:19.0 
 +0900
 +++ icecast2-2.3.2/debian/icecast2.postinst   2010-12-06 18:52:07.0 
 +0900
 @@ -45,6 +45,9 @@
  # Tightened permissions for the config file
  chmod -R ug=rw,o=,ug+X /etc/icecast2/icecast.xml
  
 +# avoid to fail on invoke-rc.d icecast2 start when upgrading see Bug#605507
 +sleep 3
 +

What is this supposed to achieve?

  #DEBHELPER#
  
  exit 0
 
Cheers,
Julien


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: Freeze exception for csound?

2010-12-16 Thread Julien Cristau
On Sat, Nov 13, 2010 at 21:13:58 -0300, Felipe Sateler wrote:

 Dear release team,
 
 Recently, a bug was reported against csound (#603321), which was
 already fixed in upstream CVS. The bug is severity: normal, although
 one could argue for a higher severity given that it segfaults whenever
 using a certain opcode.
 
 Here is the entire patch:
 
 Description: Acquire bus lock at init time
  Otherwise we get segfaults when trying to use it at perf time
 Origin: upstream, commit:1.40
 Bug-Debian: http://bugs.debian.org/603321
 --- a/OOps/bus.c
 +++ b/OOps/bus.c
 @@ -1056,6 +1056,8 @@
  err = csoundGetChannelPtr(csound, (p-fp), (char*) p-iname,
CSOUND_AUDIO_CHANNEL | CSOUND_OUTPUT_CHANNEL);
  if (LIKELY(!err)) {
 +  p-lock = csoundGetChannelLock(csound, (char*) p-iname,
 + CSOUND_AUDIO_CHANNEL | CSOUND_OUTPUT_CHANNEL);
p-h.opadr = (SUBR) chnclear_opcode_perf;
return OK;
  }
 
 
 Would this be acceptable for squeeze? If not, I will not upload to
 leave the window open for a possible RC bug fix via unstable.
 
Yes, that would be fine.  Sorry for the delayed answer.

Cheers,
Julien


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: Please unblock ffmpeg_4:0.5.2-6

2010-10-05 Thread Julien Cristau
On Tue, Oct  5, 2010 at 15:45:41 +0200, Reinhard Tartler wrote:

 
 Hi,
 
 Please unblock ffmpeg_4:0.5.2-6. It fixes CVE-2010-3429.
 
Done.

Cheers,
Julien


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Bug#591881: vlc-nox: package fails to upgrade properly from lenny

2010-08-29 Thread Julien Cristau
On Sun, Aug 29, 2010 at 17:42:15 +0200, Reinhard Tartler wrote:

 Dear release team, please unblock ffmpeg_0.5.2-3 for squeeze.
 
Done.  Thanks for your work.

Cheers,
Julien


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Bug#591881: vlc-nox: package fails to upgrade properly from lenny

2010-08-29 Thread Julien Cristau
On Sun, Aug 29, 2010 at 19:36:58 +0200, Christian Marillat wrote:

 Julien Cristau jcris...@debian.org writes:
 
  On Sun, Aug 29, 2010 at 17:42:15 +0200, Reinhard Tartler wrote:
 
  Dear release team, please unblock ffmpeg_0.5.2-3 for squeeze.
  
  Done.  Thanks for your work.
 
 Maybe the release team need to be aware of bug 592457 not fixed in
 ffmpeg_0.5.2-3 ?
 
I saw that in the changelog, but I don't think it's my responsibility to
override the maintainer here.  If ftpmaster says this needs to be
reverted, then so be it, but I trust this wasn't done behind their
backs.

Cheers,
Julien


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: Bug#583916: Upcoming jack transition

2010-06-06 Thread Julien Cristau
Hi Reinhard,

On Sun, Jun  6, 2010 at 10:43:33 +0200, Reinhard Tartler wrote:

 On So, Jun 06, 2010 at 00:15:54 (CEST), Julien Cristau wrote:
 
  Your proposal talked about introducing a libjack-jackd2-0 and a
  libjack0-0.118+svn3796 package, AIUI.  I don't understand why the
  current libjack0 package can't stay.
 
 Hm. maybe I missed something here. So your idea is to have the original
 'jack1' package have the non-virtual package libjack0, right? The idea
 was to make it easier in future to switch the jack implementation that
 is used to build applications against. But I agree that this is not
 really that important at this point. Moreover, I'm not even sure anymore
 that we would want to do that, but that's future discussion, right.
 
My idea was to have the j-a-c-k (jackd2) package provide the non-virtual
package libjack0, just like today.  I didn't think it was important
which libjack implementation apps build against, and this seemed the
easiest / least disruptive way.

[snip]
  I'm not quite sure about the rest of the plan (switching the j-a-c-k
  package from one implementation to another one, introducing a
  jackd-defaults), it seems overengineered compared to leaving the current
  j-a-c-k package alone, and reintroducing jackd1 and its libjack
  alongside it.  Can you explain why you need all this?
 
 The plan is to have 2 implementations of jackd2 in squeeze: jackd1 and
 jackd2. Both badly need their 'own' implementation of libjack, while
 regular applications don't care if they find libjack0 from jackd1 or
 jackd2 at run time. [1]
 
 For the default install, we want to install jackd2 by default as we
 believe that it provides a superiour user experience. However, we want
 to have all applications built against libjack0 from jackd1. Moreover,

OK as I said above I don't understand this bit...

 upstream has indicated that they want to provide backports for future,
 more featureful jackd1 packages on their website. Therefore I've
 imagined a jack-defaults package that can be overriden in that
 repository. A user would then only have to 'apt-get dist-upgrade' and
 have its jackd2 replaced by the newer jackd1 implementation.
 
'apt-get install jackd1' is not good enough?  If all apps are rebuilt
with the new shlibs, then this should replace jackd2 and its libjack0
with jackd1 and the corresponding lib, AFAICT.

Cheers,
Julien


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: Bug#583916: Upcoming jack transition

2010-06-05 Thread Julien Cristau
On Mon, May 31, 2010 at 18:39:11 +0200, Reinhard Tartler wrote:

 The last transition switched the jack-audio-connection-kit package
 from 'jackd' to 'jackd2'. 'jackd2' is a complete reimplementation of
 jackd in C++ with SMP support. Most importantly however, is an added
 feature that improves interoperability with pulseaudio.  For this
 reason, we decided to make this version the default version for Squeeze.
 
 During testing, however, we discovered that this transition has been and
 still is a bit problematic.  Besides some more or less known bugs in
 'jackd2', it exposes a lot of additional (internal, C++ only) symbols,
 with which we are not comfortable at all.  Moreover, we have been
 approached by upstream(s) with concerns that our current package does
 not make it easy for 3rd parties (may it be upstream or backports.org)
 to provide replacement packages for other jackd implementations.
 
 For this reason, we propose to:
 
  - revert the 'jack-audio-connection-kit' package to the jackd1
implementation
 
  - make this package the provider of libjack-dev, however the actual
daemon will be packaged as 'jackd1' (currently jackd)
 
  - create a shlibs file that makes application packages depend on
'libjack0-0.116 | libjack0-0.118+svn3796 (= 1:0.0116)' (or similar).
This effectively defines a new virtual package 'libjack0-0.116' that
is provided by any jack implementation that claims to be binary 
compatible with the 0.116 release of the original jack
implementation.
 
  - have all packages that are linked against libjack recompiled to pick
up the new shlibs
 
  - introduce the jackd2 implementation as a new source package 'jackd2'.
The binary package name of this jack daemon will be 'jackd2', the
library package will be 'libjack-jackd2-0' and (of course also)
provide 'libjack0-0.116'.
 
  - introduce a new source package 'jackd-defaults' that generates a meta
package 'jackd' which points to the default jack implementation,
which will be jackd2 for Debian.
 
So I have a few questions about this plan:
- if all implementations of libjack are binary-compatible, then why do
  we need to change the package name when changing implementations of
  libjack?
- I understand you want to allow different jackd implementations to
  coexist.  Do we really need 2 implementations of libjack as well?
- related to this, the libjack0.symbols file currently has things like
  'jack_client_kill_thr...@base 1.9.5~dfsg-13' which suggest that it is,
  actually, not completely compatible with other implementations (a
  quick check suggests that nothing out of the jack-audio-connection-kit
  source package uses these additional symbols, but..)
- many packages apparently depend on symbols labelled 0.118.0 or later
  in the symbols file, how does that fly with a 0.116 jackd1?

Overall this looks like a lot of churn, late in the release cycle, for
an end result which seems quite close to the current situation.

Cheers,
Julien


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Bug#580088: jack-audio-connection-kit: FTBFS on armel (cannot convert 'int' to 'va_list')

2010-05-03 Thread Julien Cristau
On Mon, May  3, 2010 at 18:13:00 +0200, Adrian Knoth wrote:

 On Mon, May 03, 2010 at 04:00:14PM +0100, Adam D. Barratt wrote:
 
  ../common/JackAPI.cpp:303: error: cannot convert 'int' to 'va_list'
  for argument '4' to 'jack_client_t* jack_client_open_aux(const char*,
  jack_options_t, jack_status_t*, va_list)'
 
 The code in question:
 
jack_client_open_aux(client_name, (jack_options_t)options, NULL, NULL);
 
 Obviously, arg4 is NULL, so the message means the compiler cannot
 convert 0 to a va_list, which should be (more or less) a pointer. Or at
 least was until some va_list mangling in gcc-4.4.
 
va_list is very much not a pointer.  It's an opaque type, using it as a
pointer is wrong.

Cheers,
Julien


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Bug#579465: jack-audio-connection-kit: FTBFS on kfreebsd-*: error: a c compiler is required

2010-04-30 Thread Julien Cristau
On Tue, Apr 27, 2010 at 23:38:41 +0200, Jonas Smedegaard wrote:

 BTW, we currently set other arch-specific flags based on
 DEB_BUILD_ARCH - I wonder if that should instead be DEB_HOST_ARCH?

That would probably be more correct, yes.

Cheers,
Julien


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Bug#563483: closed by Christophe Mutricy xto...@videolan.org (Bug#563483: fixed in vlc 1.0.4-2)

2010-01-08 Thread Julien Cristau
On Fri, Jan  8, 2010 at 12:59:32 +, Christophe Mutricy wrote:

 2010/1/8 Julien Cristau jcris...@debian.org:
 
  What are you trying to achieve with that?
 
 Files have moved between this 2 packages (and back as I forgot an use case)
 
Then use Replaces, not Conflicts.

Cheers,
Julien



___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers