Bug#667888: toonloop: FTBFS ("error: 'GstElement* clutter_gst_video_sink_new(ClutterTexture*)' is deprecated (declared at /usr/include/clutter-1.0/clutter-gst/clutter-gst-util.h:48) [-Werror=deprecate

[Adam D. Barratt]

Source: toonloop
Version: 2.1.18-3
Severity: serious
Tags: wheezy sid

Hi,

toonloop FTBFS.  From the amd64 build log:

pipeline.cpp: In constructor 'Pipeline::Pipeline(Application*)':
pipeline.cpp:457:18: error: 'GstElement* 
clutter_gst_video_sink_new(ClutterTexture*)' is deprecated (declared at 
/usr/include/clutter-1.0/clutter-gst/clutter-gst-util.h:48) 
[-Werror=deprecated-declarations]
compilation terminated due to -Wfatal-errors.
cc1plus: all warnings being treated as errors
make[4]: *** [toonloop-pipeline.o] Error 1
make[4]: Leaving directory 
`/build/buildd-toonloop_2.1.18-3+b1-amd64-Q8Fp2o/toonloop-2.1.18/src'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory 
`/build/buildd-toonloop_2.1.18-3+b1-amd64-Q8Fp2o/toonloop-2.1.18/src'
make[2]: *** [all] Error 2
make[2]: Leaving directory 
`/build/buildd-toonloop_2.1.18-3+b1-amd64-Q8Fp2o/toonloop-2.1.18/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory 
`/build/buildd-toonloop_2.1.18-3+b1-amd64-Q8Fp2o/toonloop-2.1.18'
make: *** [debian/stamp-makefile-build] Error 2
dpkg-buildpackage: error: debian/rules build-arch gave error exit status 2

Full logs available via
https://buildd.debian.org/status/package.php?p=toonloop&suite=sid

Regards,

Adam




___
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#667888: toonloop: FTBFS ("error: 'GstElement* clutter_gst_video_sink_new(ClutterTexture*)' is deprecated (declared at /usr/include/clutter-1.0/clutter-gst/clutter-gst-util.h:48) [-Werror=deprecate

[Adam D. Barratt]

On Sat, 2012-04-07 at 12:12 +0200, Jonas Smedegaard wrote:
> On 12-04-07 at 10:39am, Adam D. Barratt wrote:
> > toonloop FTBFS.  From the amd64 build log:
> 
> > cc1plus: all warnings being treated as errors
> 
> Yeah, this has already been reported as bug#666756.  Thanks anyway.

Oops; sorry about that.  Clearly more coffee needed this morning.

Regards,

Adam




___
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.

[Adam D. Barratt]

severity 670338 important
thanks

On Tue, 2012-04-24 at 19:02 +, Cyril Roelandt wrote:
> Package: libquicktime-dev
> Severity: serious
> Tags: patch
> Justification: fails to build from source
> 
> Dear Maintainer,
> 
>* What led up to the situation?
> libquicktime FTBFS on hurd-i386 (cf. 
> http://people.debian.org/~sthibault/graph-top.txt). Building the source from 
> the git repository fails with :

This isn't RC, for two reasons - a) hurd isn't a release architecture;
b) the package has never built there in any case; downgrading.

Regards,

Adam




___
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#683030: unblock: vlc/2.0.3-1

[Adam D. Barratt]

On Sat, 2012-07-28 at 15:54 +0100, Adam D. Barratt wrote:
> Depends: vlc libav (not considered)
> 
> The new libav does not have an unblock request ttbomk and from a quick
> look at the diff I'm not prepared to unblock it without at least some
> discussion (there are changes which don't appear to be mentioned in the
> changelog and some of the changes listed in the changelog don't actually
> appear tohave been made).

Looking again and reading through the associated bug reports, it looks a
bit better than I thought; I really shouldn't have to read through
longish bug report logs to find out why a change has been made to the
packaging, however.

libav maintainers (Cced):

- the changelog for -5 mentions making transitional packages arch:all,
but not a number of removals of "Multi-Arch: foreign" that seem to have
been applied to some packages.

- the changelog also doesn't mention the dropping of the ffmpeg
Provides.

- this change looks slightly odd:

  * Do not run doxygen if it is not installed.

doxygen is in B-D-Indep and only appears to be used when building the
arch:all -doc package.  On that basis, why would it not always be
installed when required?

Regards,

Adam


___
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#683030: unblock: vlc/2.0.3-1

[Adam D. Barratt]

On Sat, 2012-07-28 at 22:32 +0200, Jonas Smedegaard wrote:
> On 12-07-28 at 04:47pm, Adam D. Barratt wrote:
> > - this change looks slightly odd:
> > 
> >   * Do not run doxygen if it is not installed.
> > 
> > doxygen is in B-D-Indep and only appears to be used when building the 
> > arch:all -doc package.  On that basis, why would it not always be 
> > installed when required?
> 
> I did not apply this change but recognize it from Emdebian sprint: 
> Reason is, I believe, to ease bootstrapping new architectures by 
> suppressing build of arch-all packages.

Hmmm, unless I'm reading the rules files incorrectly, purely running the
binary-arch target should already have DTRT without requiring doxygen to
be installed.  Hence the query, as the change appears to be effectively
an unnecessary no-op right now.

Regards,

Adam


___
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#683030: unblock: vlc/2.0.3-1

[Adam D. Barratt]

On 01.08.2012 09:14, Fabian Greffrath wrote:

Am 28.07.2012 17:47, schrieb Adam D. Barratt:

On Sat, 2012-07-28 at 15:54 +0100, Adam D. Barratt wrote:

 Depends: vlc libav (not considered)

The new libav does not have an unblock request ttbomk and from a 
quick
look at the diff I'm not prepared to unblock it without at least 
some
discussion (there are changes which don't appear to be mentioned in 
the
changelog and some of the changes listed in the changelog don't 
actually

appear tohave been made).


So, will libav 6:0.8.3-5 get unblocked or should we request this 
separately?


The libav discussion moved to (the cloned) #683247, where Reinhard said 
he was going to upload -6.  That bug also contains some discussion which 
suggests the previous m-a:foreign changes were incorrect.  In any case, 
let's move the discussion there, please. :-)


Regards,

Adam

___
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: Supercollider in wheezy

[Adam D. Barratt]

On Wed, 2012-08-15 at 18:23 -0400, Felipe Sateler wrote:
> I write to fix the issue of supercollider in wheezy. Current SC in
> testing is upstream version 3.4.5. Current in sid is 3.5.3. The
> version in wheezy has a FTBFS bug (#674386), so we need to get rid of
> that. Options are:
> 
> 1. Upload a fix via tpu.

Apparently this happened.  Whilst the package does look sane, was that
actually acked in advance?

Regards,

Adam


___
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: Supercollider in wheezy

[Adam D. Barratt]

On Sun, 2012-08-19 at 18:05 -0400, Felipe Sateler wrote:
> On Sun, Aug 19, 2012 at 5:56 PM, Adam D. Barratt
>  wrote:
> > On Wed, 2012-08-15 at 18:23 -0400, Felipe Sateler wrote:
> >> I write to fix the issue of supercollider in wheezy. Current SC in
> >> testing is upstream version 3.4.5. Current in sid is 3.5.3. The
> >> version in wheezy has a FTBFS bug (#674386), so we need to get rid of
> >> that. Options are:
> >>
> >> 1. Upload a fix via tpu.
> >
> > Apparently this happened.  Whilst the package does look sane, was that
> > actually acked in advance?
> 
> No. I was under the impression that the ack has to come after the
> upload (because the rt uses the actuall uploaded package for the ack).

We'd likely ack the proposed diff and then unblock after reviewing the
actual uploaded diff.

> The devref even says to wait until the package has built on all archs
> before notifying the RT. I was waiting for that before sending a mail.

Hmmm, we should probably review that, particularly during a freeze.
fwiw, britney won't try and migrate the package until all the
architectures are built anyway; that's "new", as in implemented within
the past couple of years - I suspect the previous behaviour may have
been the reasoning behind the devref suggestion.

> I went for uploading the fixes to tpu because:
> 
> 1. There was a fix available so it makes no sense to not fix the package.
> 2. If 3.5 is going to be allowed to migrate, it should be because it
> makes sense to have 3.5 instead of 3.4, and not because of some
> unrelated bug.

Sounds reasonable.  I've added an "approve" hint (effectively an unblock
for t-p-u); thanks.

Regards,

Adam


___
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: VLC Enable sftp

[Adam D. Barratt]

On Wed, 2012-09-26 at 00:35 +0800, Larry Pinney wrote:
> VideoLAN should have sftp enabled in order to play video on the (my)
> LAN.
> Please include the commit from Benjamin Drung in the upcoming Release.
> 
> 
> http://anonscm.debian.org/gitweb/?p=pkg-multimedia/vlc.git;a=commitdiff;h=ebfad0e

The Release Team can't do anything about a patch that's not in unstable.
CCing the vlc maintainers; please direct further discussion there.
(From a very quick look it sounds featurish and therefore possibly not
appropriate at this point, but if the maintainers wish to include it in
a future upload then that's their decision.)

Thanks,

Adam



___
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: severity of 693799 is important

[Adam D. Barratt]

On Wed, 2012-11-21 at 16:57 +, Debian Bug Tracking System wrote:
> Processing commands for cont...@bugs.debian.org:
> 
> > severity 693799 important
> Bug #693799 [mhwaveedit] mhwaveedit: FTBFS on big endian archs

Why? The package used to build fine on those architectures and there are
now outdated packages in unstable, which clearly makes this a regression
and thus RC unless I'm missing some detail.

Regards,

Adam


___
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: Please binNMU phonon-backend-vlc against the new libvlccore7

[Adam D. Barratt]

On 2013-10-28 6:46, Mateusz Łukasik wrote:

recently vlc source package has been updated and it now builds
libvlccore7  instead of libvlccore5.
It is possible to build phonon-backend-vlc against the new
libvlccore7.  Now phonon-backend-vlc have broken depends on i386 and
amd64. On others  architectures new version is not avaitable now, see
#727831.


phonon-backend-vlc isn't the only package affected; CCing the 
maintainers - what's the plan here?


# Broken Depends:
cytadela/contrib: cytadela [amd64 armel armhf i386 ia64 kfreebsd-amd64 
kfreebsd-i386 mips mipsel powerpc s390x sparc]
freetuxtv: freetuxtv [amd64 armel armhf i386 ia64 kfreebsd-amd64 
kfreebsd-i386 mips mipsel powerpc s390x sparc]
goldencheetah: goldencheetah [amd64 armel armhf i386 ia64 
kfreebsd-amd64 kfreebsd-i386 mips mipsel powerpc s390x sparc]
libplayer: libplayer2 [amd64 armel armhf i386 ia64 kfreebsd-amd64 
kfreebsd-i386 mips mipsel powerpc s390x sparc]
npapi-vlc: browser-plugin-vlc [amd64 armel armhf i386 ia64 
kfreebsd-amd64 kfreebsd-i386 mips mipsel powerpc s390x sparc]
phonon-backend-vlc: phonon-backend-vlc [amd64 armel armhf i386 ia64 
kfreebsd-amd64 kfreebsd-i386 mips mipsel powerpc s390x sparc]


I must admit to not being overjoyed at such changes being made in an 
urgency=high upload, with changelog entries such as


   * New major upstream release. (Closes: #436339, #632965, #642187,
 #698023, #593735, #724734, #665732, #700752, #704941, #708953,
 #712935, #398167, #646200, #679654, #654955, LP: #982953, #301193,
 #986785, #1038303, #1109026, #530797, #667584, #938621, #671031,
 #1080847, #1157384, #1173943)

Unless every single one of those bugs is requesting an upload of the 
new version, that changelog stanza is broken imho; it should refer to 
the actual changes made.


Regards,

Adam

___
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: Please binNMU phonon-backend-vlc against the new libvlccore7

[Adam D. Barratt]

On 2013-10-30 12:08, Rémi Denis-Courmont wrote:


On Wed, 30 Oct 2013 11:38:29 +, "Adam D. Barratt"

 wrote:

[...]
* New major upstream release. (Closes: #436339, #632965, 
#642187,



  #698023, #593735, #724734, #665732, #700752, #704941, #708953,


  #712935, #398167, #646200, #679654, #654955, LP: #982953, 
#301193,


  #986785, #1038303, #1109026, #530797, #667584, #938621, 
#671031,



  #1080847, #1157384, #1173943)





Unless every single one of those bugs is requesting an upload of the
new version,


They do; they are all (fixed-)upstream bugs. And whomever made the 
upload

even *missed* a few bug numbers there.


As a random selection, #593735 is entitled "vlc: don't exclusively 
depend on ttf-freefont". That is a) a packaging change and b) not a 
request for a new upstream version.


Even if that bug were fixed upstream, that is /not/ the same as a 
request for a new upstream version to be uploaded. In this case, the 
changelog would have been better as something along the lines of:


  * New major upstream release:
- don't exclusively depend on ttf-freefont (Closes: #593735)
- change 2 (Closes: #NN)

Regards,

Adam

___
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: Please binNMU phonon-backend-vlc against the new libvlccore7

[Adam D. Barratt]

On 2013-10-30 15:48, Benjamin Drung wrote:

On Mi, 2013-10-30 at 13:08 +0100, Rémi Denis-Courmont wrote:

   Hello,

On Wed, 30 Oct 2013 11:38:29 +, "Adam D. Barratt"
 wrote:
> On 2013-10-28 6:46, Mateusz Łukasik wrote:
>> recently vlc source package has been updated and it now builds
>> libvlccore7  instead of libvlccore5.

[...]

> phonon-backend-vlc isn't the only package affected; CCing the
> maintainers - what's the plan here?

[...]
I concur with upstream. These packages should be fixed to use the 
stable

API from libvlc instead of using libvlccore. Looking at the other
package, they all just depend on libvlc, but not on libvlccore. Just
phonon-backend-vlc requires libvlccore.


Mea culpa, I obviously had a moment and missed that only libvlccore had 
changed SONAME (can I blame jetlag?).


However, it's not just phonon-backend-vlc - goldencheetah depends on 
both libvlc and libvlccore.


Regards,

Adam

___
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#726733: av_register_all() segfaults on s390x in some cases (regression, causes FTBFS)

[Adam D. Barratt]

On Sat, 2013-11-02 at 21:11 -0400, Reinhard Tartler wrote:
> can you perhaps also provide a backtrace? It seems that there are no
> public s390x porter machines where I could get that myself.

adsb@zelenka:~$ schroot --list | grep s390x
chroot:experimental_s390x-dchroot
chroot:jessie_s390x-dchroot
chroot:sid_s390x-dchroot
chroot:wheezy-backports_s390x-dchroot
chroot:wheezy_s390x-dchroot
source:experimental_s390x-dchroot
source:jessie_s390x-dchroot
source:sid_s390x-dchroot
source:wheezy-backports_s390x-dchroot
source:wheezy_s390x-dchroot

Regards,

Adam

___
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#893278: stretch-pu: package showq/0.4.1+git20161215~dfsg0-2+deb9u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sat, 2018-03-17 at 19:33 +0200, Adrian Bunk wrote:
> Fix the program startup.

I'm not sure how much we're actually helping by fixing a package that
was apparently not even trivially tested before upload and had been
entirely broken for nearly a year before anyone even noticed.

Feel free to upload, but it seems like time would be better spent
avoiding us getting to such situations to begin with, rather than
having to spend time on them after the fact.

Regards,

Adam

___
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#893278: stretch-pu: package showq/0.4.1+git20161215~dfsg0-2+deb9u1

[Adam D. Barratt]

Control: tags -1 + pending

On Sat, 2018-03-31 at 22:27 +0100, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Sat, 2018-03-17 at 19:33 +0200, Adrian Bunk wrote:
> > Fix the program startup.
> 
> I'm not sure how much we're actually helping by fixing a package that
> was apparently not even trivially tested before upload and had been
> entirely broken for nearly a year before anyone even noticed.
> 
> Feel free to upload, but it seems like time would be better spent
> avoiding us getting to such situations to begin with, rather than
> having to spend time on them after the fact.
> 

Uploaded and flagged for acceptance.

Regards,

Adam

___
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#792619: transition: ffmpeg

[Adam D. Barratt]

On 2015-07-23 16:41, Adam D. Barratt wrote:

On 2015-07-23 15:49, Andreas Cadhalpun wrote:
By the way, do you know why vtk6 is shown as bad in the transition 
tracker,

even though it built successfully with ffmpeg?


Because building successfully doesn't mean building sanely.

Package: libvtk6.1
Source: vtk6 (6.1.0+dfsg2-6)
Version: 6.1.0+dfsg2-6+b1


Specifically, I got the right reason but the wrong reason for it. :-)

It's still bad because libvtk6.1 is still in sid. And libvtk6.1 is still 
in sid because of the mess that is the vtk6 "transition" (#749395, which 
has been going on for over a year now).


Regards,

Adam

___
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#792619: transition: ffmpeg

[Adam D. Barratt]

On 2015-07-23 15:49, Andreas Cadhalpun wrote:
By the way, do you know why vtk6 is shown as bad in the transition 
tracker,

even though it built successfully with ffmpeg?


Because building successfully doesn't mean building sanely.

Package: libvtk6.1
Source: vtk6 (6.1.0+dfsg2-6)
Version: 6.1.0+dfsg2-6+b1
Installed-Size: 121728
Maintainer: Debian Science Team 


Architecture: amd64
Replaces: libvtk32, libvtk4, libvtk4c2, libvtk4c2a, libvtk5, libvtk5.8, 
libvtk6
Depends: libavcodec56 (>= 6:11~beta1) | libavcodec-extra-56 (>= 
6:11~beta1), libavformat56 (>= 6:11~beta1), libavutil54 (>= 6:11~beta1), 
libc6 (>= 2.15), [...]


Regards,

Adam

___
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#805549: Patch for strech, jessie, wheezy

[Adam D. Barratt]

On 2015-12-15 13:04, Felipe Sateler wrote:

Hi,

Dear release team, I'm copying you to ask if the attached patch would
be OK to upload to stable/oldstable, fixes bug #805549. This error
makes some builds against stk impossible, since there are two headers
missing.

The version in unstable is a different upstream version, so the patch
is not exactly the same (attached is a patch on a patch, currently we
patch the real file, as the previous patch was accepted upstream).


In isolation, the patch looks okay. In order to get approval for actual 
uploads for stable and oldstable, however, please open a p-u bug for 
each, including a full source debdiff for a package built and tested on 
that distribution.


Regards,

Adam

___
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#805549: Patch for strech, jessie, wheezy

[Adam D. Barratt]

On Tue, 2015-12-15 at 13:18 +, Adam D. Barratt wrote:
> On 2015-12-15 13:04, Felipe Sateler wrote:
> > Hi,
> > 
> > Dear release team, I'm copying you to ask if the attached patch would
> > be OK to upload to stable/oldstable, fixes bug #805549. This error
> > makes some builds against stk impossible, since there are two headers
> > missing.
> > 
> > The version in unstable is a different upstream version, so the patch
> > is not exactly the same (attached is a patch on a patch, currently we
> > patch the real file, as the previous patch was accepted upstream).
> 
> In isolation, the patch looks okay. In order to get approval for actual 
> uploads for stable and oldstable, however, please open a p-u bug for 
> each, including a full source debdiff for a package built and tested on 
> that distribution.

I note that there are now #810760 and #810761. For future reference,
"[i]n order to get approval", implied opening the bugs _before_ the
uploads, not afterwards.

Regards,

Adam

___
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: Introducing symbol versioning in FFmpeg

[Adam D. Barratt]

Hi,

Apologies for the delay in getting back to you.

On Sun, 2009-12-13 at 09:27 +0100, Reinhard Tartler wrote: 
> We currently FFmpeg version 0.5 in lenny and squeeze. I noticed
> difficulties when trying to update the distro packages to a recent svn
> checkout, because the SONAME of libavutil has been bumped. In situations
> where the application package was not recompiled (yet), this causes
> libavutil to be loaded twice, once with the old SONAME and once with the
> new SONAME.
> 
> My understanding of the situation is that symbol versioning is the
> recommended answer to this problem. I therefore went ahead and started a
> discussion upstream about that [1]. In that discussion, upstream (more
> or less) agreed on that plan.
> 
> I'm proposing the following changes to the FFmpeg packages in Debian:
> 
>  i.   each and every library of FFmpeg applies the following version tag
>   to each and every symbol: ${LIBNAME}_${SONAME}
> 
>  ii.  upload of FFmpeg 0.5 to unstable with versioned symbols
> 
>  iii. binNMU all applications to pick up the new versioned symbols.
> 
>  iv.  Upload a newer FFmpeg snapshot to experimental with versioned
>   symbols.
> 
> I request assistance from the release team for the following questions:
> 
>  - does the symbol versioning strategy in step i. make sense?

Yes.  As a Debian-specific addition, the libraries should have their
shlibs updated to ensure that binaries built against them will have a
">= version_introducing_symbols" dependency.

> I believe so, as upstream does care for ABI compatibility inside the
> single FFmpeg libraries, but not (yet) about issues caused by transitive
> dependencies. E.g., this would mean the symbols of libavutil49 (in
> squeeze) would get the tag LIBAVUTIL_49, whereas libavutil in
> experimental would get LIBAVUTIL_50.
> 
>  - do I need to rename the binary packages and conflict against the old
>packages as outlined in the last parahraph of the library packaging
>guide, section 3.3 [2]?

This isn't strictly necessary, although not renaming the packages could
lead to the same kind of issues you mentioned above for partial upgrades
(either testing -> testing or stable -> newstable).

If squeeze and lenny will both have the same soname for each of the
libraries involved, this isn't an issue.

> Upstream has concerns that this is absolutely required due to bugs in the
> gnu linker ld, see his posting in [3].

If I understand correctly, upstream's concerns are around the behaviour
of the linker when multiple versions of the ffmpeg libraries are
available on the system, one with and one without symbol versioning?  If
so then I don't believe that would be an issue for Debian as the
installation of the symbol-versioned libraries would replace the earlier
non-versioned libraries.

> - When would be a good time to do this change? I imagine that depending
>on the previous answer, this will cause a larger transition for
>squeeze.

Please go ahead with the uploads introducing symbol versioning.  In
order to ease transition, we'll schedule the required binNMUs once the
package has migrated to testing.

[...] 
> - Currently, FFmpeg exports all sort of internal symbols. With symbol
>versioning, upstream agreed to limit the list of exported symbols.
>I'd like to do so in FFmpeg 0.5 in squeeze as well. Do you agree with
>this?

This would be an ABI breaking change and as such /would/ require a
package name change.  We'd prefer that the symbol versioning change be
made first and then look at the potential impact of the symbol removal.

Regards,

Adam

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

Re: Introducing symbol versioning in FFmpeg

[Adam D. Barratt]

On Tue, 2010-01-26 at 07:57 +0100, Reinhard Tartler wrote:
> On Mo, Dez 21, 2009 at 23:17:42 (CET), Adam D. Barratt wrote:
> 
> > Please go ahead with the uploads introducing symbol versioning.  In
> > order to ease transition, we'll schedule the required binNMUs once the
> > package has migrated to testing.
> 
> While ffmpeg not migrated to testing yet (will most probably do so in 2
> days), it has now been installed on all architectures:
> 
> https://buildd.debian.org/status/package.php?p=ffmpeg&suite=unstable
>
> AFAIUI binNMUs for reverse depends can be scheduled now.

It would be preferable to have the package migrate first to avoid the
(albeit low) possibility of anything that needs to migrate quickly
getting stuck behind it; admittedly a few recent uploads, including a
couple of python2.6 binNMUs, appear to have picked up updated ffmpeg
dependencies already.

In any case, ffmpeg should migrate in tonight's britney run.

> Do you have
> specialized tools for determining a list of packages subject to binNMUs,
> or shall I compile a list for i386?

http://release.debian.org/~adsb/ffmpeg_binNMUs.txt is what I believe to
be the list of packages potentially needing binNMUs.

Excluding those packages which have either had sourceful uploads in the
past day or so (e.g. vtk) or have already scheduled or completed binNMUs
for python2.6 (e.g. picard) would be useful to avoid duplicated work and
builds.

Regards,

Adam

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

Re: Introducing symbol versioning in FFmpeg

[Adam D. Barratt]

On Wed, 2010-01-27 at 07:54 +, Adam D. Barratt wrote:
> http://release.debian.org/~adsb/ffmpeg_binNMUs.txt is what I believe to
> be the list of packages potentially needing binNMUs.
> 
> Excluding those packages which have either had sourceful uploads in the
> past day or so (e.g. vtk) or have already scheduled or completed binNMUs
> for python2.6 (e.g. picard) would be useful to avoid duplicated work and
> builds.

The list has now been updated to remove those packages which have had
rebuilds since the ffmpeg upload or have outstanding python2.6 binNMUs
scheduled for them (and in one case to include a binNMU for one
architecture where the python2.6 binNMU completed shortly before ffmpeg
was available on that architecture).

Regards,

Adam

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

Bug#573131: liblo: FTBFS on mipsel (needs updating for new cdbs)

[Adam D. Barratt]

Package: src:liblo
Version: 0.26~repack-3
Severity: serious

Hi,

liblo failed to build on mipsel:

/usr/bin/fakeroot debian/rules clean
debian/rules:22: /usr/share/cdbs/1/rules/copyright-check.mk: No such file or 
directory
make: *** No rule to make target 
`/usr/share/cdbs/1/rules/copyright-check.mk'.  Stop.
dpkg-buildpackage: error: /usr/bin/fakeroot debian/rules clean gave error 
exit status


Looking at the cdbs changelog, copyright-check.mk appears to have been 
merged in to utils.mk in a recent upload.


Regards,

Adam 





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

Re: Bug#823206: gb: armhf kodi_16.1+dfsg1-1

[Adam D. Barratt]

On Mon, 2016-05-02 at 10:17 +0200, Bálint Réczey wrote:
> Package: release.debian.org
> User: release.debian@packages.debian.org
> Usertags: binnmu
[...]
> Build of kodi failed on buildd, but I have successfully rebuilt it
> on debomatic from the same source:
> http://debomatic-armhf.debian.net/distribution#unstable/kodi/16.1+dfsg1-1/buildlog
> 
> Please trigger a rebuild to have official builds for the package.
> 
>  gb kodi_16.1+dfsg1-1 . armhf

"Usertags: binnmu"

As explained previously:

That's not a binNMU, it's a give-back - hence "gb". Please don't use
binNMU requests for wanna-build actions that aren't binNMUs - other
actions should be directed to $arch@buildd.d.o or
debian-wb-team@lists.d.o, as per
http://lists.debian.org/debian-project/2009/03/msg00096.html

Regards,

Adam


___
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#823206: gb: armhf kodi_16.1+dfsg1-1

[Adam D. Barratt]

On Mon, 2016-05-02 at 12:08 +0100, Adam D. Barratt wrote:
> On Mon, 2016-05-02 at 10:17 +0200, Bálint Réczey wrote:
> > Package: release.debian.org
> > User: release.debian@packages.debian.org
> > Usertags: binnmu
> [...]
> > Build of kodi failed on buildd, but I have successfully rebuilt it
> > on debomatic from the same source:
> > http://debomatic-armhf.debian.net/distribution#unstable/kodi/16.1+dfsg1-1/buildlog
> > 
> > Please trigger a rebuild to have official builds for the package.
> > 
> >  gb kodi_16.1+dfsg1-1 . armhf
> 
> "Usertags: binnmu"
> 
> As explained previously:
> 
> That's not a binNMU, it's a give-back - hence "gb". Please don't use
> binNMU requests for wanna-build actions that aren't binNMUs - other
> actions should be directed to $arch@buildd.d.o or
> debian-wb-team@lists.d.o, as per
> http://lists.debian.org/debian-project/2009/03/msg00096.html

Therefore closing this.

Regards,

Adam


___
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#707307: mediatomb-common: Mediatomb in Wheezy fails to start because there is no libfaac.so.0

[Adam D. Barratt]

Control: tags -1 + moreinfo

On Thu, 2013-05-09 at 00:56 +0200, J G Miller wrote:
> The MediaTomb daemon executable in Wheezy is linked to libfaac
> 
> ldd /usr/bin/mediatomb  | grep libfaac
> libfaac.so.0 => not found

On which architecture? At least neither of the amd64 or i386 binaries
appear to be directly linked to libfaac.

Ah:

> Architecture: armel (armv5tel)

Nope, the armel binary doesn't appear to be either.

Please could you provide the full ldd output, together with "objdump
--private-headers /usr/bin/mediatomb"?

Regards,

Adam

___
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#709752: mplayer: Linked against missing libssl.so.0.9.8

[Adam D. Barratt]

Control: tags -1 + moreinfo

On Sat, 2013-05-25 at 11:25 +0300, Mika Mäenpää wrote:
> It seems that mplayer is linked against obsolete package libssl0.9.8 in amd64 
> architecture.
> 
> When I try to start mplayer, I get the following message:
> 
>   mplayer: error while loading shared libraries: libssl.so.0.9.8: cannot open 
>   shared object file: No such file or directory

mplayer doesn't have an openssl dependency and AFAICS doesn't use the
library. Indeed, no packages in wheezy/amd64 depend on the libssl0.9.8
package.

Please could you run "which mplayer" and "ldd $(which mplayer)" and
provide the result?

Regards,

Adam

___
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#709752: mplayer: Linked against missing libssl.so.0.9.8

[Adam D. Barratt]

On Sat, 2013-05-25 at 13:31 +0300, Mika Mäenpää wrote:
> 2013/5/25 Adam D. Barratt :
> >
> > Please could you run "which mplayer" and "ldd $(which mplayer)" and
> > provide the result?
[...]
> librtmp.so.0 => /home/pulmu/lib/librtmp.so.0 (0x7fd735257000)

This looks like a good candidate. What happens if you move this local
library out of the way?

I've confirmed that the equivalent check on a wheezy install here does
include librtmp.so.0 but does not feature any references to any version
of libssl.

Regards,

Adam

___
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#709752: Processed: Re: Bug#709752: mplayer: Linked against missing libssl.so.0.9.8

[Adam D. Barratt]

Control: notfixed -1 mplayer/2:1.0~rc4.dfsg1+svn34540-1

On Wed, 2013-06-19 at 12:24 +, Debian Bug Tracking System wrote:
> Processing commands for cont...@bugs.debian.org:
> 
> > # fix version tracking
> > fixed 709752 mplayer/2:1.0~rc4.dfsg1+svn34540-1

That's an odd definition of "fix". :-) The bug didn't exist in the
packages, so was correctly closed unversioned; marking it as fixed in
any version is wrong.

What was the problem you were trying to solve? AFAICS, it was correct to
begin with.

Regards,

Adam

___
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#709752: Processed: Re: Bug#709752: mplayer: Linked against missing libssl.so.0.9.8

[Adam D. Barratt]

On Wed, 2013-06-19 at 21:39 +0100, Steven Chamberlain wrote:
> On 19/06/13 21:32, Adam D. Barratt wrote:
> > [...] so was correctly closed unversioned; marking it as fixed in
> > any version is wrong.
> 
> That left it marked as 'found' in some version though.  Is that correct?

In the sense that the bug was reported against that version, yes. It
shouldn't matter either way given the closure though.

> > What was the problem you were trying to solve? AFAICS, it was correct to
> > begin with.
> 
> This is what I was really trying to influence.  But its version tracking
> may be broken:
> 
> http://blends.debian.net/edu/bugs/desktop-gnome.html

fwiw, quoted with permission from #debbugs:

21:48 < adsb> certainly it was my understanding that closed with no
fixed versions rendered found versions irrelevant
21:48 < dondelelcaro> adsb: right, it does
21:48 < dondelelcaro> if it's -done and there's no fixed versions, it's
fixed everywhere
21:49 < adsb> glad I'm not going entirely crazy :)
21:49 < adsb> apparently someone needs to fix blends.d.n's understanding
then
21:49 < dondelelcaro> ah
21:49 < dondelelcaro> wouldn't surprise me if someone got it wrong if
they're not using the actual code in the BTS... it is kind of subtle

Regards,

Adam

___
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#548625:

[Adam D. Barratt]

severity 548625 serious
thanks

On Sun, 2011-02-27 at 11:17 +, Alessio Treglia wrote:
> Hi!
> 
> > Please do ping me if anyone stumbles across this bug untouch for more
> > than a week: Then I got distracted from it :-/
> 
> So... ping! :)

This issue is now causing libshout to FTBFS on arm{el,hf}; raising
severity.

Regards,

Adam




___
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#579464: Fixed upstream

[Adam D. Barratt]

On Wed, April 28, 2010 11:14, Jonas Smedegaard wrote:
> On Wed, Apr 28, 2010 at 12:06:10PM +0200, Adrian Knoth wrote:
>>This got fixed upstream (r3994). We should upgrade to this revision,
>>because it also contains r3993. r3993 is required to compile the jackd2
>>on non-ALSA platforms.
>
> Sounds great.
>
> I am too busy to work on this the next couple of days.

At the risk of being a pain, do you have an ETA as to when a new upload
might be possible?

A fixed j-a-c-k would (hopefully) allow us to finally push the entangled
celt and directfb transitions in to testing.

Regards,

Adam




___
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'")

[Adam D. Barratt]

Package: jack-audio-connection-kit
Version: 1.9.5~dfsg-4
Severity: serious

Hi,

j-a-c-k FTBFS on armel.  From the build log:

../linux/JackAtomic_os.h:73:2: warning: #warning using builtin gcc (version > 
4.1) atomic
../common/JackAPI.cpp: In function 'jack_client_t* jack_client_new(const 
char*)':
../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)'
Waf: Leaving directory 
`/build/buildd-jack-audio-connection-kit_1.9.5~dfsg-4-armel-Sc6IkM/jack-audio-connection-kit-1.9.5~dfsg/build'
Build failed
 -> task failed (err #1): 
{task: cxx JackAPI.cpp -> JackAPI_1.o}
make[1]: Entering directory 
`/build/buildd-jack-audio-connection-kit_1.9.5~dfsg-4-armel-Sc6IkM/jack-audio-connection-kit-1.9.5~dfsg/build'
make: *** [debian/stamp-makefile-build] Error 1
dpkg-buildpackage: error: debian/rules build gave error exit status 2

Full log at 
https://buildd.debian.org/fetch.cgi?pkg=jack-audio-connection-kit&arch=armel&ver=1.9.5%7Edfsg-4&stamp=1272857925&file=log&as=raw

Regards,

Adam



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

Bug#580089: jack-audio-connection-kit: FTBFS on ia64 and alpha

[Adam D. Barratt]

Package: jack-audio-connection-kit
Version: 1.9.5~dfsg-4
Severity: serious

Hi,

j-a-c-k FTBFS on (so far) alpha and ia64; from the build log:

In file included from ../common/JackAtomic.h:24,
 from ../common/JackAtomicState.h:23,
 from ../common/JackGraphManager.h:28,
 from ../common/JackClient.cpp:22:
../linux/JackAtomic_os.h:73:2: warning: #warning using builtin gcc (version > 
4.1) atomic
Waf: Leaving directory 
`/build/buildd-jack-audio-connection-kit_1.9.5~dfsg-4-ia64-morvzb/jack-audio-connection-kit-1.9.5~dfsg/build'
Build failed
 -> task failed (err #1): 
{task: cxx JackAPI.cpp -> JackAPI_1.o}
make[1]: Entering directory 
`/build/buildd-jack-audio-connection-kit_1.9.5~dfsg-4-ia64-morvzb/jack-audio-connection-kit-1.9.5~dfsg/build'
make: *** [debian/stamp-makefile-build] Error 1
dpkg-buildpackage: error: debian/rules build gave error exit status 2

This may have the same root cause as the armel failure, in which case please 
merge them.

Full build logs available via 
https://buildd.debian.org/status/package.php?p=jack-audio-connection-kit

Regards,

Adam



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

Bug#580089: jack-audio-connection-kit: FTBFS on ia64 and alpha

[Adam D. Barratt]

reopen 580089
thanks

On Mon, 2010-05-03 at 17:18 +0200, Adrian Knoth wrote:
> On Mon, May 03, 2010 at 04:03:10PM +0100, Adam D. Barratt wrote:
> > This may have the same root cause as the armel failure, in which case
> > please merge them.
> 
> I don't think so. For the alpha and ia64, I have written a fix:
> 
>http://trac.jackaudio.org/attachment/ticket/171/jackd2-pointersize.patch
> 
> 
> Next upload will hopefully build on these architectures.

Nope :-/  They now fail for different reasons.

alpha:

[ 37/209] cxx: common/JackServerAPI.cpp ->
build/default/common/JackServerAPI_1.o
18:50:24 runner system command -> ['/usr/bin/g++', '-g', '-O2', '-g', '-Wall', 
'-O2', '-O3', '-fPIC', '-DPIC', '-fvisibility=hidden', '-Idefault/linux', 
'-I../linux', '-Idefault/posix', '-I../posix', '-Idefault/common', 
'-I../common', '-Idefault/common/jack', '-I../common/jack', '-Idefault', 
'-I..', '-Idefault/build/default', '-DHAVE_CONFIG_H', '-DSERVER_SIDE', 
'../common/JackServerAPI.cpp', '-c', '-o', 'default/common/JackServerAPI_1.o']
In file included from ../common/JackAtomic.h:24,
 from ../common/JackAtomicState.h:23,
 from ../common/JackGraphManager.h:28,
 from ../common/JackServerAPI.cpp:22:
../linux/JackAtomic_os.h:73:2: warning: #warning using builtin gcc (version > 
4.1) atomic
../common/JackServerAPI.cpp: In function 'jack_client_t* 
jack_client_open_aux(const char*, jack_options_t, jack_status_t*, va_list)':
../common/JackServerAPI.cpp:76: error: could not convert 'ap' to 'bool'

ia64:

19:48:32 runner system command -> ['/usr/bin/gcc', '-g', '-O2', '-g', '-Wall', 
'-O2', '-O3', '-Idefault/linux', '-I../linux', '-Idefault/posix', '-I../posix', 
'-Idefault/dbus', '-I../dbus', '-Idefault', '-I..', '-Idefault/common', 
'-I../common', '-Idefault/common/jack', '-I../common/jack', 
'-I/usr/include/dbus-1.0', '-I/usr/lib/dbus-1.0/include', '../dbus/sigsegv.c', 
'-c', '-o', 'default/dbus/sigsegv_1.o']
../dbus/sigsegv.c: In function 'signal_segv':
../dbus/sigsegv.c:101: error: 'NGREG' undeclared (first use in this function)
../dbus/sigsegv.c:101: error: (Each undeclared identifier is reported only once
../dbus/sigsegv.c:101: error: for each function it appears in.)
../dbus/sigsegv.c:106: error: 'mcontext_t' has no member named 'gregs'

Adam



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

Bug#580618: jack-audio-connection-kit: FTBFS on armel ("error: 'mcontext_t' has no member named 'gregs'")

[Adam D. Barratt]

Package: src:jack-audio-connection-kit
Version: 1.9.5~dfsg-9
Severity: serious

Hi,

Unfortunately, j-a-c-k is still failing to build on armel.  -9 has been
tried three times, two of which resulted in an "illegal instruction"
stopping the build; the other gave:

../dbus/sigsegv.c: In function 'signal_segv':
../dbus/sigsegv.c:107: error: 'mcontext_t' has no member named 'gregs'

The full log is at 
https://buildd.debian.org/fetch.cgi?&pkg=jack-audio-connection-kit&ver=1.9.5%7Edfsg-9&arch=armel&stamp=1273173146&file=log

fwiw, the HPPA build has also been tried several times yet with no
success, but I'm not entirely sure whether those are package or buildd
issues.

Regards,

Adam



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

Bug#580824: jack-audio-connection-kit: FTBFS on hppa (multiple issues)

[Adam D. Barratt]

Package: jack-audio-connection-kit
Version: 1.9.5~dfsg-12
Severity: serious
Tags: patch

Hi,

j-a-c-k FTBFS on hppa.  While some of the issues may be buildd related,
some of them aren't; the good news is that I believe I've fixed them. :-)
(at least, I've successfully built j-a-c-k on the hppa porter box)

There are two issues:

- waf's parallel building and hppa don't mix; I've stolen a patch which
Jakub Wilk provided for xmms2 and applied it to j-a-c-k. It will break if
anything causes the .waf.-* directory to be renamed, but that seems like
another reason not to use waf ;-)

- the "alpha/ia64 segv fix" patch also needs to include hppa in its
growing list of architectures on which not to execute the relevant code;
the patch probably also wants renaming :-)

I've attached a new patch to fix the first; I assume the second is trivial
enough not to need a patch.

I'd appreciate an upload containing these changes so that we can hopefully
finally get j-a-c-k built on all architectures which are relevant for
testing migration.

Regards,

AdamDescription: Disable parallel build on hppa architecture.
Origin: http://code.google.com/p/waf/source/browse/tags/waf-1.5.0/playground/serial.py

--- a/.waf-1.5.0-8e39a4c1c16303c1e8f010bf330305f6/wafadmin/Runner.py
+++ b/.waf-1.5.0-8e39a4c1c16303c1e8f010bf330305f6/wafadmin/Runner.py
@@ -143,3 +143,100 @@ class Parallel(object):
 	self.consumers=[TaskConsumer(self)for i in xrange(self.numjobs)]
 		assert(self.count==0 or self.stop)
 
+class Serial(object):
+
+	def __init__(self, bld, j=1):
+		self.manager = bld.task_manager
+		self.outstanding = []
+
+		# progress bar
+		self.total = self.manager.total()
+		self.processed = 0
+		self.error = 0
+
+		self.switchflag = 1 # postpone
+		
+		self.consumers = None
+
+	# warning, this one is recursive ..
+	def get_next(self):
+		if self.outstanding:
+			t = self.outstanding.pop(0)
+			self.processed += 1
+			return t
+
+		# handle case where only one wscript exist
+		# that only install files
+		if not self.manager.groups:
+			return None
+
+		(_, self.outstanding) = self.manager.get_next_set()
+		if not self.outstanding: return None
+
+		return self.get_next()
+
+	def postpone(self, tsk):
+		self.processed -= 1
+		self.switchflag *= -1
+		# this actually shuffle the list
+		if self.switchflag>0: self.outstanding.insert(0, tsk)
+		else: self.outstanding.append(tsk)
+
+	def start(self):
+		debug('runner: Serial start called')
+		while 1:
+			# get next Task
+			tsk = self.get_next()
+			if tsk is None: break
+
+			if Logs.verbose: debug('runner: retrieving %r' % tsk)
+
+			st = tsk.runnable_status()
+			if st == ASK_LATER:
+debug('runner: postponing %r' % tsk)
+self.postpone(tsk)
+continue
+
+			#continue
+			if st == SKIP_ME:
+tsk.hasrun = SKIPPED
+self.manager.add_finished(tsk)
+continue
+
+			tsk.position = (self.processed, self.total)
+
+			# display the command that we are about to run
+			tsk.generator.bld.printout(tsk.display())
+
+			# run the command
+			if tsk.__class__.stat: ret = tsk.__class__.stat(tsk)
+			else: ret = tsk.run()
+			self.manager.add_finished(tsk)
+
+			# non-zero means something went wrong
+			if ret:
+self.error = 1
+tsk.hasrun = CRASHED
+tsk.err_code = ret
+if Options.options.keep: continue
+else: return -1
+
+			try:
+tsk.post_run()
+			except OSError:
+self.error = 1
+tsk.hasrun = MISSING
+if Options.options.keep: continue
+else: return -1
+			else:
+tsk.hasrun = SUCCESS
+
+		if self.error:
+			return -1
+
+import subprocess
+p = subprocess.Popen(['dpkg', '--print-architecture'], stdout=subprocess.PIPE)
+arch = p.stdout.read().strip()
+p.wait()
+if arch == 'hppa':
+	Parallel = Serial
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers

Bug#580824: jack-audio-connection-kit: FTBFS on hppa (multiple issues)

[Adam D. Barratt]

On Sun, May 9, 2010 01:05, Dmitrijs Ledkovs wrote:
> On 9 May 2010 00:44, Adam D. Barratt  wrote:
>>
>> - waf's parallel building and hppa don't mix; I've stolen a patch which
>> Jakub Wilk provided for xmms2 and applied it to j-a-c-k. It will break
>> if
>> anything causes the .waf.-* directory to be renamed, but that seems like
>> another reason not to use waf ;-)
>>
>
> Running waf with "-j1" flag should stop all paralelism.
>
> e.g.
>
> ./waf configure build -j1
>
> Is this not enough to make waf behave on hppa?

>From what I could see from reading the code, the number of jobs should
automatically default to the number of available CPUs in any case, so
should automatically be 1 at least on the porter box.

However, assuming that adding the following to debian/rules would
implement your suggestion, then sadly no it does not appear to be enough:

waf-configure-options += $(if $(filter hppa,$(DEB_HOST_ARCH)),-j1)

Even with this change, the "./waf configure" call hangs after outputting

Checking for dbus-1 >= 1.0.0 : ok
Checking for dbus-1 flags: ok
Checking for header expat.h  : ok

I killed it after 15 minutes of inactivity; the build output shows that
-j1 was passed to the configure call. If I add the Runner.py patch
instead, it gets past that point with ease (and later fails with the
second error I mentioned, which is trivially fixable by adding "&&
!defined(__hppa__)" to an existing patch).

Regards,

Adam




___
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

[Adam D. Barratt]

On Mon, June 14, 2010 06:49, Reinhard Tartler wrote:
> On Sat, Jun 12, 2010 at 16:57:52 (CEST), Adam D. Barratt wrote:
>
>> On Mon, 2010-05-31 at 18:39 +0200, Reinhard Tartler wrote:
>>> This creates the situation that we actually partially revert the last
>>> transition.  However, we still consider jackd2 as the superior
>>> implementation for squeeze, so we need to introduce a new virtual
>>> package for the libjack0 library. We expect the actual rebuilds to be
>>> rather smooth, since the jackd1 implementation was tested extensively
>>> in
>>> Lenny and Squeeze.
>>>
>>> It appears that 93 source packages will need to be binNMUd as part of
>>> this transition.
[...]
>> Is there a solution which would allow us to perform a gradual rebuild of
>> involved packages without potentially blocking other transitions?
>
> The transition does not need to be finished before some other transition
> starts because we intend to retain the package 'libjack0' as non-virtual
> package so that dependencies on this remain resolvable all the time.
>
> Is this what you've asked for or did I miss something?

What I meant was, could we do something along the lines of:

* upload new j-a-c-k package and whatever other sourceful changes are
required
* get the above built everywhere and migrated to testing asap
* binNMU libjack0's r-deps a few at a time, letting them migrate to
testing as and when they're ready and skipping any that will require
rebuilds for other transitions anyway

This would be much easier to fit in around other transitions than having
to rebuild all of the r-deps before any of them could transition.  From a
quick look, the only potential issue with the j-a-c-k upload itself I can
see is that it build-depends on python; however, as it doesn't produce any
python modules and only appears to have a runtime dependency on the python
package, I'm not sure this actually causes any problems in practice.

Regards,

Adam


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

Bug#589199: cannot install ardour on testing

[Adam D. Barratt]

On Thu, 2010-07-15 at 22:44 -0400, Reinhard Tartler wrote:
> On Thu, Jul 15, 2010 at 14:23:45 (EDT), Marco wrote:
> > The following packages have unmet dependencies:
> >   ardour: Depends: jackd (>= 0.103.0) but it is not going to be installed
> > E: Broken packages
> 
> please share the exact versions of the package and its dependencies you
> are trying to install. I'm especially curious to see your sources.list,
> potentially your /etc/apt/preferences (if non-empty/missing).
> 
> is this stable? the dependency indicates that the package was built
> against a copy of libjack not in testing/unstable.

The ardour packages in both testing and unstable depend on "jackd (>=
0.103.0)".  Although the exact versioning of the dependency isn't
mentioned, I'd suspect this was added in 1:2.0~rc1-0ubuntu1, which was
incorporated in to a package uploaded to Debian in April 2007.

Regards,

Adam



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

Bug#589199: cannot install ardour on testing

[Adam D. Barratt]

On Sun, 2010-07-18 at 17:20 +0200, Reinhard Tartler wrote:
> reassing 589199 libaubio2
> stop
> 
> On Sat, Jul 17, 2010 at 17:11:38 (CEST), Adam D. Barratt wrote:
> 
> > On Thu, 2010-07-15 at 22:44 -0400, Reinhard Tartler wrote:
> >> On Thu, Jul 15, 2010 at 14:23:45 (EDT), Marco wrote:
> >> > The following packages have unmet dependencies:
> >> >   ardour: Depends: jackd (>= 0.103.0) but it is not going to be installed
> >> > E: Broken packages
[...]
> The following packages have unmet dependencies:
>   ardour: Depends: libaubio2 but it is not going to be installed
>   Depends: libjack0 (>= 0.118.0) but it is not going to be installed
> E: Broken packages
[...]
> In order to fix this bug, the package libaubio2 needs to be binNMUed.
> In this basis, I'm reassinging this bug to the package libaubio2
> 
> Adam, can you please schedule a binNMU?

binNMUs for aubio scheduled.

Regards,

Adam



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

Bug#590863: ardour: FTBFS on sparc ("scons: *** [gtk2_ardour/panner2d.o] Error -11")

[Adam D. Barratt]

Package: ardour
Version: 1:2.8.11-1
Severity: serious

Hi,

ardour FTBFS on sparc; from the build log:

g++ -o gtk2_ardour/panner2d.o -c -Woverloaded-virtual -DPROGRAM_NAME=\"Ardour\" 
-D_REENTRANT -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 
-DGTK_NEW_TOOLTIP_API -DPACKAGE=\"gtk2_ardour\" -DLIBSIGC_DISABLE_DEPRECATED 
-DLOCALEDIR=\"/usr/share/locale\" -DVERSIONSTRING=\"2.8.11\" -DHAVE_LV2 -O3 
-fomit-frame-pointer -ffast-math -fstrength-reduce -pipe -g -O2 -g -Wall -O2 
-Wall -DHAVE_LIBLO -DPROGRAM_NAME=\"Ardour\" -D_REENTRANT -D_LARGEFILE_SOURCE 
-D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Ilibs -DENABLE_NLS 
-DPACKAGE=\"gtk2_ardour\" -pthread -pthread -pthread -pthread -pthread -pthread 
-pthread -pthread -pthread -DFFT_ANALYSIS -DFREESOUND -DUSE_RUBBERBAND 
-DHAVE_LV2 -D_REENTRANT -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -Ilibs/pbd 
-I/usr/include/pixman-1 -I/usr/include/gtk-unix-print-2.0 -I/usr/include/cairo 
-I/usr/include/pango-1.0 -Ilibs/ardour -I/usr/include/libart-2.0 
-I/usr/lib/glib-2.0/include -I/usr/lib/giomm-2.4/include 
-I/usr/lib/gtkmm-2.4/include -I/usr/include/cairomm-1.0 -I. 
-I/usr/include/gail-1.0 -Ilibs/rubberband -I/usr/include/glib-2.0 
-I/usr/include/gdkmm-2.4 -I/usr/include/freetype2 -I/usr/include/gio-unix-2.0 
-Igtk2_ardour -I/usr/include/atkmm-1.6 -I/usr/include/atk-1.0 
-I/usr/lib/cairomm-1.0/include -I/usr/include/gtk-2.0 -Ilibs/midi++2 
-I/usr/include/libpng12 -I/usr/include/libgnomecanvasmm-2.6 
-I/usr/include/libgnomecanvas-2.0 -I/usr/lib/glibmm-2.4/include 
-I/usr/include/sigc++-2.0 -I/usr/include/rasqal -I/usr/lib/gtk-2.0/include 
-I/usr/include/libxml2 -Ilibs/gtkmm2ext -I/usr/include/pangomm-1.4 
-I/usr/include/giomm-2.4 -I/usr/lib/libgnomecanvasmm-2.6/include 
-I/usr/lib/pangomm-1.4/include -I/usr/include/glibmm-2.4 
-I/usr/include/gtkmm-2.4 -Ilibs/surfaces/control_protocol 
-I/usr/lib/gdkmm-2.4/include -I/usr/lib/sigc++-2.0/include 
gtk2_ardour/panner2d.cc
scons: *** [gtk2_ardour/panner2d.o] Error -11
scons: building terminated because of errors.
make: *** [debian/stamp-scons-build] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2

Full logs available via 
https://buildd.debian.org/status/package.php?p=ardour&suite=unstable

Regards,

Adam



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

Bug#590948: csound: FTBFS on hppa (build terminated after 300 minutes of inactivity)

[Adam D. Barratt]

Package: csound
Version: 1:5.12.1~dfsg-2
Severity: serious

Hi,

csound FTBFS on hppa when binNMUed for the jackd-defaults transition;
from the most recent build log:

Generating docs for compound XOUT...
Generating docs for compound XOUT_HIGH...
Generating docs for compound XOUT_LOW...
Generating docs for compound XOUT_MAX...
Generating docs for compound XSEG...
make: *** [build-indep-stamp] Terminated
GBuild killed with signal TERM after 300 minutes of inactivity

Full logs available via
https://buildd.debian.org/status/package.php?p=csound&suite=unstable

Regards,

Adam



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

Bug#590976: slv2: FTBFS on hppa (Build killed with signal TERM after 300 minutes of inactivity)

[Adam D. Barratt]

Package: slv2
Version: 0.6.6-4
Severity: serious

Hi,

slv2 FTFBS when binNMUed for the jackd-defaults transition; from the
build log:

[19/25] copy: doc/reference.doxygen.in -> build/default/doc/reference.doxygen
make: *** wait: No child processes.  Stop.
make: *** Waiting for unfinished jobs
make: *** wait: No child processes.  Stop.
make[1]: *** [override_dh_auto_build] Terminated
Build killed with signal TERM after 300 minutes of inactivity

Full logs available via
https://buildd.debian.org/status/package.php?p=slv2

I noticed that the package uses waf to build so the patches applied to
packages such as xiphos may be of interest (see e.g. #582904).

Regards,

Adam 



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

Re: Bug#589689: transition to libjack-jackd2-0 breaks many packages

[Adam D. Barratt]

On Tue, 2010-07-20 at 22:30 +0200, Adrian Knoth wrote:
> It works (on the library level), but the packages need to depend on the
> newly introduced virtual package libjack-0.116 which is provided by
> either libjack0 or libjack-jackd2-0. 
> 
> (to be precise, they'll depend on (libjack-jackd2-0 | libjack-0.116),
> and that's what the binNMUs are for)

On the subject of those binNMUs, they should now all have been
scheduled.

Looking at unstable and ignoring packages which have built successfully
and are simply missing uploads, the remaining packages depending on just
libjack0 are:

- ardour: FTBFS on sparc (#590863)
- csound: FTBFS on hppa (#590948)
- gnuradio: FTBFS everywhere (#573759) and not in testing
- hydrogen: FTBFS on several architectures (#574719)
- lmms: Unbuildable due to dependency on libwine-dev (#590950)
- slv2: FTBFS on hppa (#590976)
- wine-unstable: FTBFS on powerpc; not in testing

Testing is similar but also includes:

- aqualung, moc, qmmp, xine-lib, xmms2: waiting for libmodplug
- freej: waiting for opencv, which started an uncoordinated transition
and FTBFS on hppa
- idjc: 3/10 days old
- mpd: 8/10 days old
- qtractor: 6/10 days old
- seq24: 7/10 days old

Regards,

Adam

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

Re: Bug#589689: transition to libjack-jackd2-0 breaks many packages

[Adam D. Barratt]

On Fri, July 30, 2010 19:02, Felipe Sateler wrote:
> On 30/07/10 13:25, Adam D. Barratt wrote:
>> - ardour: FTBFS on sparc (#590863)
>> - csound: FTBFS on hppa (#590948)
>> - slv2: FTBFS on hppa (#590976)
>
> All these three look like problems with the buildd host/toolchain.
> CSound hangs in a doxygen call that has not been modified since the -1
> upload. Trying to build that same documentation in paer gives me
> segmentation faults in doxygen in different stages almost every time (I
> managed to build it after a few retries).

Of the four tries on the buildds, csound hung in doxygen twice and during
the source build twice, afaics.  That and the fact that it needed several
tries on paer suggest that even if we it managed to build after another
attempt or three, the next binNMU or sourceful upload may well have the
same problem(s).

> The paer sid chroot does not
> have the necessary build deps, so I can't binNMU it myself.

You can, you just need to request that the build-deps be installed.

> slv2 hangs in a file copy operation, apparently.

slv2 appears to have suffered from a known problem with waf's parallel
functionality on hppa.  The new sourceful upload has built fine on hppa.

Regards,

Adam


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

Re: Bug#589689: transition to libjack-jackd2-0 breaks many packages

[Adam D. Barratt]

On Sun, August 1, 2010 12:33, Felipe Sateler wrote:
> Copying this to the appropriate bug...
[...]
> Indeed. How do you suggest working through this? Facts:
>
> 1. The build hangs unpredictably on a doxygen call.
> 2. The doxygen call is in build-indep (so it is not strictly necessary
> for binary only builds, but gets executed anyway).
>
> I can move the doxygen call away from there into binary-indep, but that
> feels like a hack to me.

Does the documentation actually differ across architectures?  If the
doxygen calls are simply for generating the contents of libcsound64-doc
then arranging for them to only occur when the binary-indep packages are
being built sounds like a sane solution; if I'm missing something obvious,
then someone please apply the relevant cluebat. :-)

Regards,

Adam


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

Bug#590948: fixed in csound 1:5.12.1~dfsg-4

[Adam D. Barratt]

reopen 590948
thanks

On Wed, August 4, 2010 16:32, Jonas Smedegaard wrote:
> Source: csound
> Source-Version: 1:5.12.1~dfsg-4
>
> We believe that the bug you reported is fixed in the latest version of
> csound, which is due to be installed in the Debian FTP archive:
[...]
>* Build documentation in -doc specific build target, to avoid
>  supoerfluous rebuilds in arch-only rebuilds. Closes: bug#590948,
>  thanks to Julin Cristau and others.

Unfortunately, this doesn't seem to have worked :-(

>From the most recent hppa build log:

touch debian/stamp-scons-build
doxygen
[...]
Generating namespace index...
make: *** [build-doxygen-stamp] Segmentation fault
dpkg-buildpackage: error: debian/rules build gave error exit status 2
Generating docs for
names
Build finished at 20100805-0429
FAILED [dpkg-buildpackage died]


A quick check of the i386 log also shows the documentation still being
generated.

Regards,

Adam




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

Re: flac_1.2.1-3

[Adam D. Barratt]

Hi,

On Mon, 2010-08-09 at 15:45 +0200, Fabian Greffrath wrote:
> the pkg-multimedia team has just uploaded a revised flac_1.2.1-3 
> package to unstable. This packages contains fixes for two bugs 
> (#579025 and #585518) which unfortunately required an autoreconf of 
> the build system. The autoreconf result is applied by means of a 
> patch, which makes the interdiff quite huge and is the reasons why I 
> haven't attached it to this mail.

#585518 appears to be a wishlist change to support an unofficial port,
which wouldn't qualify for an exception on its own.

I'm ambivalent about #579025.  The bug log indicates that it doesn't
actually affect any packages in the archive, as it only occurs when the
install prefix is not overriden; it could break things for people
compiling local flac-using applications.  By your own determination
though, it's only a "normal" bug.

The log for #579025 also suggests that fixing it would require
rebuilding reverse dependencies; is that the case?

Regards,

Adam

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

Re: Bug#589689: transition to libjack-jackd2-0 breaks many packages

[Adam D. Barratt]

On Tue, 2010-08-31 at 20:59 +0200, Julien Cristau wrote:
> Coming back to the libjack binNMUs:
> 
> On Fri, Jul 30, 2010 at 18:25:15 +0100, Adam D. Barratt wrote:
> 
> > Looking at unstable and ignoring packages which have built successfully
> > and are simply missing uploads, the remaining packages depending on just
> > libjack0 are:
> > 
> > - ardour: FTBFS on sparc (#590863)
> > - csound: FTBFS on hppa (#590948)
> 
> both fixed and in testing.

csound still has an outdated dependency on hppa; the newer package in
unstable FTBFS on sparc.

Regards,

Adam

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

Re: Bug#589689: transition to libjack-jackd2-0 breaks many packages

[Adam D. Barratt]

On Wed, September 1, 2010 09:10, Reinhard Tartler wrote:
> On Tue, Aug 31, 2010 at 21:14:05 (CEST), Adam D. Barratt wrote:
>
>> csound still has an outdated dependency on hppa;
>
> What dependency is that?

libcsound64-5.2 depends on "libjack0 (>= 0.118.0)".

> Where can we look that up?

Predictably, in the testing packages file for hppa :-)
http://ftp.debian.org/debian/dists/testing/main/binary-hppa/Packages.gz ,
for example.

Regards,

Adam


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

Re: Bug#589689: transition to libjack-jackd2-0 breaks many packages

[Adam D. Barratt]

On Wed, September 1, 2010 10:05, Reinhard Tartler wrote:
> On Wed, Sep 01, 2010 at 10:51:31 (CEST), Adam D. Barratt wrote:
>
>> On Wed, September 1, 2010 09:10, Reinhard Tartler wrote:
>>> On Tue, Aug 31, 2010 at 21:14:05 (CEST), Adam D. Barratt wrote:
>>>
>>>> csound still has an outdated dependency on hppa;
>>>
>>> What dependency is that?
>>
>> libcsound64-5.2 depends on "libjack0 (>= 0.118.0)".
>
> Right, could you schedule a binNMU for csound on hppa? that should fix
> it.

Scheduled.

Regards,

Adam


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

Re: Bug#589689: transition to libjack-jackd2-0 breaks many packages

[Adam D. Barratt]

On Wed, 2010-09-01 at 13:10 +0100, Adam D. Barratt wrote:
> On Wed, September 1, 2010 10:05, Reinhard Tartler wrote:
> > On Wed, Sep 01, 2010 at 10:51:31 (CEST), Adam D. Barratt wrote:
> >> libcsound64-5.2 depends on "libjack0 (>= 0.118.0)".
> >
> > Right, could you schedule a binNMU for csound on hppa? that should fix
> > it.
> 
> Scheduled.

and failed, due to doxygen breaking.  The fixed doxygen should migrate
tonight, so I've added a dep-wait.

Regards,

Adam

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

Re: Bug#589689: transition to libjack-jackd2-0 breaks many packages

[Adam D. Barratt]

On Wed, 2010-09-01 at 09:40 -0400, Felipe Sateler wrote: 
> On 01/09/10 04:10, Reinhard Tartler wrote:
> > this package has been tried four times and every time we see a different
> > build error:
> > 
> > #1 (on lebrun):segfault in gcc
> > #2 (on schroeder): segfault in python (i.e. scons, the build system)
> > #3 (on lebrun):segfault in gcc, but in a different compilation unit as 
> > #1
> > #4 (on schroeder): sigill in gcc
[...]
> Please, I'd like to know what to do about this. I have a RC bug on
> csound (#591802) about this build failure and by this point I think this
> is not a bug in csound. Note that I have built the package successfully
> on smetana, and Adrian Knoth also did on a machine of his own. Should I
> upload the package and close the bug?

In the short term, uploading the package built on smetana in order to
allow the package to migrate (possibly with a gentle nudge from britney)
is ok.

Longer term, we still need to work out why the package builds happily on
both porter boxes (having managed to build it successfully myself on
sperger last night) but not on the buildds, so that we can rebuild it in
the future for security builds and stable updates.

Regards,

Adam

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

Re: Bug#589689: transition to libjack-jackd2-0 breaks many packages

[Adam D. Barratt]

On Tue, 2010-08-31 at 20:59 +0200, Julien Cristau wrote:
> Coming back to the libjack binNMUs:
> 
> On Fri, Jul 30, 2010 at 18:25:15 +0100, Adam D. Barratt wrote:
[...]
> > - freej: waiting for opencv, which started an uncoordinated transition
> > and FTBFS on hppa
[..]
> So as far as squeeze is concerned the only missing piece is freej,
> unless I missed something.

opencv, and therefore freej, migrated; closing.

Regards,

Adam


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

Bug#611579: libavformat52: broke ABI without SONAME change

[Adam D. Barratt]

user release.debian@packages.debian.org
usertag 611579 + squeeze-can-defer
tag 611579 + squeeze-ignore
thanks

On Mon, 2011-01-31 at 06:54 +0100, Reinhard Tartler wrote:
> On Sun, Jan 30, 2011 at 23:05:33 (CET), Lionel Elie Mamane wrote:
> 
> > Package: libavformat52
> > Version: 4:0.6.1-2
> > Severity: serious
> > Justification: 8
> >
> > user@host:~ $ gmplayer
> > gmplayer: relocation error: gmplayer: symbol codec_wav_tags, version 
> > LIBAVFORMAT_52 not defined in file libavformat.so.52 with link time 
> > reference
> > user@host:~ $ dpkg -l mplayer-gui
> > ii  mplayer-gui  2:1.0~rc3++final.dfsg1-1 movie player 
> > for Unix-like systems
> 
> mplayer is using internals of libavformat which have been renamed. This
> particular symbol is now called 'ff_codec_wav_tags', but there are also
> other ones. Upgrading to mplayer rc4 will fix this issue.

So far as I can see, this only affects users of the ffmpeg libraries in
experimental currently?  If so, then this isn't a blocker for the
squeeze release; tagging as such.

Regards,

Adam




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

Bug#611791: [SRM] Approval for libmms_0.6-1squeeze1

[Adam D. Barratt]

Hi,

On Mon, 2011-02-07 at 10:52 +0100, Fabian Greffrath wrote:
> please consider the attached diff for libmms in stable. It fixes an 
> alignment issue that makes the whole library rather useless on e.g. ARM.

>From the bug report, it appears that this issue also affects the package
in unstable?  If so, please apply the fix to unstable first, and we can
then look at a stable update assuming no issues arise.

Regards,

Adam




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

Bug#612491: hexter: Uninstallable on kfreebsd-*

[Adam D. Barratt]

Package: hexter
Version: 0.6.2-2
Severity: serious

Hi,

hexter is uninstallable on kfreebsd-* due to its dependency on
dssi-host-jack, which does not exist on those architectures.

Either the dependency should be dropped on kfreebsd-* if that makes
sense or (ideally) dssi should be made to build there.

Regards,

Adam




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

Re: FFmpeg 0.6 transition

[Adam D. Barratt]

[debian-devel dropped from Cc as it didn't seem relevant to the mail]

On Tue, 2011-02-15 at 12:06 +0100, Reinhard Tartler wrote:
> On Di, Feb 15, 2011 at 09:31:33 (CET), Reinhard Tartler wrote:
> 
> > BTW,  where has mehdi's excellent transition tracker gone?
> 
> It is here: http://release.debian.org/transitions/ffmpeg.html
> 
> AFAIUI all packages marked red in the list above need to be rebuilt
> (i.e., binNMUed).

I've scheduled an initial set of packages on most architectures (not
alpha, hppa or mips due to the size of their queues); let's see how that
goes.

For reference, I've explicitly /not/ scheduled cherokee (#612482) or
libavg (#580678).

Regards,

Adam


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

Re: FFmpeg 0.6 transition

[Adam D. Barratt]

On Thu, 2011-02-17 at 22:21 +0100, Benjamin Drung wrote:
> Am Donnerstag, den 17.02.2011, 21:12 + schrieb Adam D. Barratt:
> > I've scheduled an initial set of packages on most architectures (not
> > alpha, hppa or mips due to the size of their queues); let's see how that
> > goes.
[...]
> You don't need to binNMU audacity, because I just uploaded 1.3.12-11.

Thanks for letting us know.  Sadly I started at the top of the
alphabetically sorted list; the audacity binNMUs have already built on
three architectures.

Regards,

Adam


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

Bug#611791: [SRM] Approval for libmms_0.6-1squeeze1

[Adam D. Barratt]

On Mon, February 21, 2011 12:28, Fabian Greffrath wrote:
> this is the patch in question:
> 
>
> Do you want me to add it to the package targetted at s-p-u for
> clarification, or should I apply it in unstable first?

Yes, the fix would need to be applied to unstable first, so we can
discover if any further issues occur.

> How about Hans'
> suggestion to accept libmms 0.6.2 in stable?

Even after excluding build system noise, the difference between the
current stable and unstable packages comes to

 29 files changed, 1094 insertions(+), 1459 deletions(-)

including a bunch of code rearrangement.  That's really too large and
non-specific for a stable update, I'm afraid.

Regards,

Adam




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

Bug#614956: mediatomb: FTBFS due to gcc-4.4 / linker changes

[Adam D. Barratt]

Package: mediatomb
Version: 0.12.0~svn2018-6.1
Severity: serious

Hi,

mediatomb FTBFS in unstable due to what looks like a consequence of the
recent gcc-4.4 linker invocation changes; from the build log:

g++ -I../src -I../tombupnp/ixml/inc -I../tombupnp/threadutil/inc
-I../tombupnp/upnp/inc -I..  -I/usr/include/mysql  -DBIG_JOINS=1 
-fno-strict-aliasing   -DUNIV_LINUX -DUNIV_LINUX -I/usr/include/mozjs
-I/usr/include/taglib   -pthread-Wall -g -O2  -Wl,-z,defs 
-lrt  -lmagic -o mediatomb mediatomb-main.o libmediatomb.a
../tombupnp/build/libtombupnp.a -Wl,-z,defs -lsqlite3
-rdynamic -L/usr/lib/mysql -lmysqlclient_r -L/usr/lib -ltag  -lmozjs
-lmagic  -lexif  -lrt -pthread  -lavformat -lavutil -lffmpegthumbnailer
-lexpat -lcurl -lcurl
/usr/bin/ld: libmediatomb.a(libmediatomb_a-mysql_storage.o): undefined
reference to symbol 'uncompress'
/usr/bin/ld: note: 'uncompress' is defined in DSO /usr/lib64/libz.so.1 so
try adding it to the linker command line
/usr/lib64/libz.so.1: could not read symbols: Invalid operation
collect2: ld returned 1 exit status
make[3]: *** [mediatomb] Error 1

Full logs available via
https://buildd.debian.org/status/package.php?p=mediatomb

Regards,

Adam




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

Bug#614957: openmovieeditor: FTBFS due to gcc-4.4 / linker changes

[Adam D. Barratt]

Package: openmovieeditor
Version: 0.0.20080102-3
Severity: serious

Hi,

openmovieeditor FTBFS in unstable due to what looks like a consequence of
the recent gcc-4.4 linker invocation changes; from the build log:

i486-linux-gnu-g++  -g -O2  -lsamplerate   -lsndfile   -lgavl  
-lquicktime -lpthread -lm -lz -ldl   -lavcodec   -lavformat   -lmpeg3
-lswscale   -ljack -lfltk_images -lfltk_gl -lfltk -o openmovieeditor 
nle.o helper.o Timeline.o VideoTrack.o nle_main.o SwitchBoard.o
WavArtist.o TimelineView.o VideoClip.o VideoViewGL.o FilmStrip.o Ruler.o
Rect.o Prefs.o MoveDragHandler.o TrimDragHandler.o VideoFileQT.o
TrackBase.o AudioTrack.o AudioClip.o AudioFileSnd.o AudioFileQT.o
PortAudioPlaybackCore.o JackPlaybackCore.o Renderer.o Flmm_Scalebar.o
SaveAsDialog.o ImageClip.o strlcpy.o AudioClipArtist.o VideoClipArtist.o
render_helper.o ImageClipArtist.o VideoFileFfmpeg.o VideoFileFactory.o
VideoFileMpeg3.o AudioFileMpeg3.o IdleHandler.o FilmStripFactory.o
AudioFileFfmpeg.o AudioFileFactory.o WaveForm.o TimelineScroll.o
DocManager.o Command.o MoveCommand.o RemoveCommand.o TrimCommand.o
AddCommand.o SplitCommand.o RemoveTrackCommand.o AddTrackCommand.o
DiskCache.o SelectDragHandler.o MoveSelectionCommand.o MediaPanel.o
FolderBrowser.o MediaBrowser.o FileBrowser.o VideoThumbnails.o Resampler.o
CompositeCommand.o RemoveSelectionCommand.o DummyClip.o DummyClipArtist.o
Frei0rFactoryPlugin.o Frei0rEffect.o Frei0rDialog.o FltkEffectMenu.o
Frei0rFactory.o VideoEffectClip.o IPlaybackCore.o PasteSelectionCommand.o
PasteCommand.o SpecialClipsBrowser.o TitleClip.o Fl_Split.o
fl_font_browser.o ColorCurveFactory.o ColorCurveFilter.o CurveEditor2.o
ColorCurveDialog.o ColorGrader2.o AudioVolumeFilter.o
AudioVolumeFilterFactory.o AutomationDragHandler.o FilterClip.o
ThreadedAudioReader.o MainFilterFactory.o FilterAddCommand.o
FilterRemoveCommand.o ScaleCropTiltFilter.o ScaleCropTiltFilterFactory.o
ScaleCropTiltDialog.o ThreadedAudioFile.o VideoWriterQT.o EncodingPreset.o
InkscapeClip.o NodeFilterFactory.o NodeFilter.o NodeFilterDialog.o
Frei0rGraphEditor.o NodeFilterFrei0rFactory.o
NodeFilterFrei0rFactoryPlugin.o SinkNode.o SrcNode.o Frei0rNode.o
Frei0rDoubleSlider.o Frei0rColorButton.o Frei0rBoolButton.o AutoTrack.o
AutoDragHandler.o NodeFilterBezierCurveFactoryPlugin.o BezierCurveNode.o
CurveEditorBezier.o portaudio/libportaudio.a tinyxml/libtinyxml.a
timeline/libtimeline.a ProgressDialog/libProgressDialog.a sl/libsl.a
LoadSaveManager/libLoadSaveManager.a ErrorDialog/libErrorDialog.a
/usr/bin/ld: VideoFileFfmpeg.o: undefined reference to symbol
'av_free@@LIBAVUTIL_50'
/usr/bin/ld: note: 'av_free@@LIBAVUTIL_50' is defined in DSO
/usr/lib/libavutil.so.50 so try adding it to the linker command line
/usr/lib/libavutil.so.50: could not read symbols: Invalid operation
collect2: ld returned 1 exit status
make[4]: *** [openmovieeditor] Error 1

Full logs available via
https://buildd.debian.org/status/package.php?p=openmovieeditor

Regards,

Adam




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

Re: FFmpeg 0.6 transition

[Adam D. Barratt]

On Thu, 2011-02-17 at 21:12 +, Adam D. Barratt wrote:
> [debian-devel dropped from Cc as it didn't seem relevant to the mail]
> 
> On Tue, 2011-02-15 at 12:06 +0100, Reinhard Tartler wrote:
> > It is here: http://release.debian.org/transitions/ffmpeg.html
> > 
> > AFAIUI all packages marked red in the list above need to be rebuilt
> > (i.e., binNMUed).
> 
> I've scheduled an initial set of packages on most architectures (not
> alpha, hppa or mips due to the size of their queues); let's see how that
> goes.
> 
> For reference, I've explicitly /not/ scheduled cherokee (#612482) or
> libavg (#580678).

So, a status update.  We've now scheduled binNMUs for all the reverse
dependencies other than those with pre-existing FTBFS issues; ignoring
packages where we're just waiting for mips, the current issues are:

* amide - FTBFS (no-add-needed, #614725)
[ * blender, dvswitch - waiting for cmake ]
* cherokee - RC-buggy and FTBFS (#612482); looking like a removal
candidate
* elmerfem - FTBFS (no-add-needed, #614952)
* ffmpeg2theora - FTBFS (no-add-needed, #614996)
* freej - FTBFS (#614458)
* gdcm - FTBFS (no-add-needed, #614953)
* kino - FTBFS (no-add-needed, #614954)
* ktoon - FTBFS (#614446)
[ * libavg - FTBFS (#580678); not in testing ]
* libvalhalla - FTBFS due to build-dependency issues (#614989)
* mediatomb - FTBFS (no-add-needed, #614956)
* openmovieeditor - FTBFS (no-add-needed, #614957)
* openscenegraph - FTBFS (#614467)
* qutecom - not getting built on armel due to a dependency chain that
ends up in the rasqal ickiness
* smilutils - FTBFS (no-add-needed, #614958)
* xine-lib - FTBFS due to X changes (#610635)

Regards,

Adam


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

Bug#611791: [SRM] Approval for libmms_0.6-1squeeze1

[Adam D. Barratt]

On Mon, 2011-03-07 at 09:32 +0100, Fabian Greffrath wrote:
> Am 21.02.2011 13:58, schrieb Adam D. Barratt:
> > Yes, the fix would need to be applied to unstable first, so we can
> > discover if any further issues occur.
> 
> libmms 0.6.2-2 has just entered testing without any complaints.

Please go ahead with the stable upload.

Regards,

Adam




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

Bug#624666: vlc: security update breaks mp3 support

[Adam D. Barratt]

Hi,

As this regression was apparently caused by a security update, I've
added the security team to CC.

On Sat, 2011-04-30 at 14:43 +0200, Christoph Goehre wrote:
> After I update from vlc version 0.8.6.h-4+lenny2.3 to 0.8.6.h-4+lenny3,
> I couldn't play any mp3 music file. If I reinstall the old version,
> everything works fine.
> 
> $ vlc -v file.mp3 
> VLC media player 0.8.6h Janus
> [0314] message packetizer warning: message queue overflowed
> [0344] ffmpeg decoder warning: incorrect frame size
>  (mp2@0x8f4b600)
[...]
> For my investigation, the bug must be situated in the mpeg_audio patch
> hunks of CVE-2010-1441.patch.

Regards,

Adam




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