Bug#888656: flowcanvas: should this package be removed? (superseded by ganv)

Source: flowcanvas Severity: important User: debian...@lists.debian.org Usertags: proposed-removal Control: clone -1 -2 Control: reassign -2 ladish Control: retitle -2 ladish: should this package be removed? flowcanvas depends on numerous obsolete GNOME 2-era libraries (e.g. #885095) and hasn't

Bug#868612: mixxx: diff for NMU version 2.0.0~dfsg-7.1

On Mon, 24 Jul 2017 at 14:04:03 +0200, Mattia Rizzolo wrote: > I've merged your changes and added a tag to the git repository; please > feel free to reschedule it to delayed/0. Thanks, done (assuming I got my dcut syntax right). S ___

Bug#868612: mixxx: diff for NMU version 2.0.0~dfsg-7.1

@@ +mixxx (2.0.0~dfsg-7.1) unstable; urgency=medium + + * Non-maintainer upload. + + [ Sebastian Ramacher ] + * Remove used B-D on libaudiofile-dev + + [ Simon McVittie ] + * Add patch from James Cowgill to fix FTBFS with newer sqlite3 +(Closes: #868612) + + -- Simon McVittie <s...@debian.

Bug#865264: unicap: please build-depend on automake, not obsolete automake1.11

Source: unicap Version: 0.9.12-2 Severity: normal User: debian...@lists.debian.org Usertags: automake1.11 automake1.11-only This package Build-Depends on the obsolete automake1.11 package. Please check whether this package can be built correctly with the recommended automake version, as provided

Bug#865168: jack-audio-connection-kit: please build-depend on automake, not obsolete automake1.11

Source: jack-audio-connection-kit Version: 1:0.125.0-2 Severity: normal User: debian...@lists.debian.org Usertags: automake1.11 automake1.11-only This package Build-Depends on the obsolete automake1.11 package. Please check whether this package can be built correctly with the recommended

Bug#865166: icecast2: please build-depend on automake, not obsolete automake1.11

Source: icecast2 Version: 2.4.2-1 Severity: normal User: debian...@lists.debian.org Usertags: automake1.11 automake1.11-only This package Build-Depends on the obsolete automake1.11 package. Please check whether this package can be built correctly with the recommended automake version, as

Bug#852985: gsequencer: please do not build-depend on oss4-dev on Linux

On Tue, 31 Jan 2017 at 02:56:37 +0100, Joël Krähemann wrote: > The patch looks fine. There should be no problem as passing this > configure flag. I even used gsequencer on linuxfromscratch.org based > system without having OSS4 at all. I'd be happy to sponsor a maintainer upload with this or a

Bug#852984: audacious-plugins: please do not build-depend on oss4-dev on Linux

On Sun, 29 Jan 2017 at 18:30:09 +0100, Sebastian Ramacher wrote: > > On Sat, 28 Jan 2017 at 17:54:43 +, Simon McVittie wrote: > > I have done a non-maintainer upload to DELAYED/7 > > Thank you. Feel free to reschedule it to DELAYED/0. Rescheduled. I'll open an unblock

Bug#852985: gsequencer: please do not build-depend on oss4-dev on Linux

Control: tags 852985 + patch On Sat, 28 Jan 2017 at 17:55:43 +, Simon McVittie wrote: > This package build-depends on oss4-dev, which is built by RC-buggy source > package oss4. I attach a possible patch. I don't know how to test gsequencer, so I am not intending to do a NMU for th

Bug#852984: audacious-plugins: please do not build-depend on oss4-dev on Linux

Control: tags 852984 + patch pending On Sat, 28 Jan 2017 at 17:54:43 +, Simon McVittie wrote: > This package build-depends on oss4-dev, which is built by RC-buggy source > package oss4. I have done a non-maintainer upload to DELAYED/7 to make sure this doesn't result in audacious g

Bug#852985: gsequencer: please do not build-depend on oss4-dev on Linux

Source: gsequencer Version: 0.7.122-1 Severity: serious Justification: release team consensus This package build-depends on oss4-dev, which is built by RC-buggy source package oss4. I discussed this with some release team members and their opinion is that oss4 should only be used on non-Linux

Bug#852984: audacious-plugins: please do not build-depend on oss4-dev on Linux

Source: audacious-plugins Version: 3.7.2-2 Severity: serious Justification: release team consensus This package build-depends on oss4-dev, which is built by RC-buggy source package oss4. I discussed this with some release team members and their opinion is that oss4 should only be used on

Bug#836396: sonic-pi: please replace dbus-launch with something else

Source: sonic-pi Version: 2.10.0~repack-2 Severity: normal Tags: upstream User: d...@packages.debian.org Usertags: dbus-launch dbus-launch-for-infra As described in I'm trying to reduce how much dbus-launch is used in Debian. sonic-pi

Bug#836078: audacious: please switch from dbus-x11 to default-dbus-session-bus | dbus-session-bus

On Tue, 30 Aug 2016 at 20:59:07 -0400, Nicholas D Steeves wrote: > I maintain the Jessie backport for audacious. As far as I can tell, > neither default-dbus-session-bus nor dbus-session-bus are provided for > Jessie, even as a virtual package. Correct. If you want to allow for no-change

Bug#836078: audacious: please switch from dbus-x11 to default-dbus-session-bus | dbus-session-bus

Source: audacious Version: 3.7.2-1 Severity: normal User: d...@packages.debian.org Usertags: dbus-launch default-dbus-session-bus As described in I'm trying to reduce how much dbus-launch is used in Debian. This package currently

Bug#799649: stk: ABI transition needed for libstdc++ v5

Source: stk Version: 4.4.4-5 Severity: serious Justification: ABI break since stable when rebuilt Tags: sid stretch User: debian-...@lists.debian.org Usertags: libstdc++-cxx11 Background[1]: libstdc++6 introduces a new ABI to conform to the C++11 standard, but keeps the old ABI to not break

Bug#797994: synfig: ABI transition needed for libstdc++ v5

Source: synfig Version: 1.0-1 Severity: serious Justification: breaks ABI without a package rename Tags: sid stretch User: debian-...@lists.debian.org Usertags: libstdc++-cxx11 Background[1]: libstdc++6 introduces a new ABI to conform to the C++11 standard, but keeps the old ABI to not break

Re: Bug#791290: sndobj: library transition may be needed when GCC 5 is the default

On Fri, 07 Aug 2015 at 13:22:49 -0300, Felipe Sateler wrote: Sndobj requires a transition. Renamed package has been uploaded to experimental and is in NEW. Since sndobj does not appear to build-depend on any libraries that need a transition, I believe it can be uploaded to unstable any time.

Bug#795813: kodi: FTBFS with g++-5: multiple definitions of argument-parsing stuff

Source: kodi Version: 14.2+dfsg1-2 Severity: serious Justification: fails to build from source (but built successfully in the past) Tags: patch kodi fails to build from source when binNMU'd for the libstdc++ transitions: https://buildd.debian.org/status/package.php?p=kodi There are lots of

Bug#791197: lv2-c++-tools: library transition may be needed when GCC 5 is the default

On Fri, 07 Aug 2015 at 12:49:43 -0300, Felipe Sateler wrote: I don't think a transition is required, but maybe there are libpaq users outside debian? Does someone know? If there isn't a reason to suspect there are library users outside Debian, it seems less disruptive to assume there are not.

Bug#794975: mixxx: will FTBFS with unsatisfiable dependencies due to libstdc++ transition

in, but I assume there is some special reason in this case. The attached patch appears to resolve this. I'm happy to NMU this (with the addition of this bug number) if necessary. Regards, S From a0156952b92336f21642a9cd31c317f933510919 Mon Sep 17 00:00:00 2001 From: Simon McVittie s

Bug#791307: vamp-plugin-sdk: library transition may be needed when GCC 5 is the default

Control: severity 791307 serious Control: retitle 791307 vamp-plugin-sdk: library transition needed for GCC 5 ABI On Fri, 03 Jul 2015 at 13:14:47 +, Matthias Klose wrote: - Decide if the symbols matching __cxx11 or B5cxx11 are part of the library API, and are used by the reverse

Bug#697026: swami: please re-upload built against GLib 2.32

Source: swami Version: 2.0.0+svn389-1 Severity: serious Justification: Bug #694525 Control: block 694525 by -1 src:swami was last built against GLib 2.30, and contains public structs (SwamiLock and derived structs) which embed a GStaticMutex, GStaticRecMutex or GStaticRWLock. On most 32-bit

Bug#697026: swami: please re-upload built against GLib 2.32

A simple rebuild (no source changes) on amd64 results in a swami GUI executable that runs, but I have no idea how to test it, or indeed make it do anything at all. It appears to default to trying to exec jackd (which is only suggested, and that only indirectly) and output via that; with the

Bug#697031: swami: default output mechanism is jackd, which is not depended on

Package: swami Version: 2.0.0+svn389-1 Severity: normal swami appears to default to output via jackd: libswami-Message: Loading plugins from /usr/lib/swami libswami-Message: Loaded 4 plugins Cannot connect to server socket err = No such file or directory Cannot connect to server request channel

Bug#666401: libavutil51: conflict with libavutil-extra-51 is counter-productive

Package: libavutil51 Version: 5:0.8.1-3 Severity: important Judging by its description, libavutil-extra-51 is meant to be a transitional package. However, transitional packages should be installable simultaneously with the package to which you're transitioning, otherwise there's no point: if the

Bug#587110: mixxx: FTBFS: dlgprefmidibindings.cpp:75: undefined reference to `MidiOptionDelegate::MidiOptionDelegate(QObject*)'

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Fri, 25 Jun 2010 at 12:14:04 +0200, Lucas Nussbaum wrote: Source: mixxx Version: 1.7.2-1 Severity: serious Tags: squeeze sid User: debian...@lists.debian.org Usertags: qa-ftbfs-20100624 qa-ftbfs Justification: FTBFS on amd64 Hi, How do

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

On Mon, 03 May 2010 at 18:13:00 +0200, Adrian Knoth wrote: 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 a struct, or a platform-specific-object that exists nowhere else in C, or a piece of cheese,