Bug#987299: unblock: gstreamer1.0/1.18.4-1
On Thu, 2021-04-22 at 14:17 +0200, Ivo De Decker wrote: > tags -1 confirmed moreinfo > > On Thu, Apr 22, 2021 at 02:09:20PM +0200, Moritz Mühlenhoff wrote: > > Am Wed, Apr 21, 2021 at 09:31:12AM +0300 schrieb Sebastian Dröge: > > > In addition to various more minor bugs, this release also fixes > > > CVE-2021-3497 > > > and CVE-2021-3498 as well as other potentially security-relevant > > > issues that > > > didn't get their own CVE. > > > > JFTR, there was an earlier discussion about CVE-2021-3497/CVE-2021- > > 3498 with > > Sebastian and given the way gstreamer release branches are handled > > we > > suggested to ask for an unblock of 1.18.4 (it's fundamentally quite > > similar > > to ffmpeg or vlc where we're also following release branches). > > OK, thanks for the clarification. > > You can go ahead with the uploads of these packages, and remove the > moreinfo tag from this bug once they are ready to migrate. Thanks, I'll upload the new versions this evening. > Please note that it seems there was a fix for #984579 in the upload > to unstable that isn't included in the upload to experimental. I > assume this will be fixed in the next upload as well. Yes, that's already included in my local version. signature.asc Description: This is a digitally signed message part
Bug#987299: unblock: gstreamer1.0/1.18.4-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package gstreamer1.0 GStreamer 1.18.4 is a bugfix release on top of 1.18.3, which is currently in testing/unstable. 1.18.4 is currently waiting in experimental until the unblock request is accepted. This does not affect only the gstreamer1.0 source package but also: - gst-plugins-base1.0 - gst-plugins-good1.0 - gst-plugins-bad1.0 - gst-plugins-ugly1.0 - gst-libav1.0 - gst-rtsp-server-1.0 - gstreamer-editing-services1.0 - gstreamer-vaapi and in theory gst-python1.0 and gst-plugins-bad1.0-contrib but those only got a new release without any other changes than the version number. It might make sense to get these two updated too to avoid user confusion caused by version numbers being out of sync. You can find a summary of the changes in the upstream release notes: https://gstreamer.freedesktop.org/releases/1.18/#1.18.4 While there are quite a few changes, they are all targeted fixes for bugs that were found, and the fixes were manually cherry-picked from the current development branch and considered low-risk. Each change is built upstream on many different platforms, the unit tests get run as well as the whole integration testsuite. At the bottom of the release notes you can find a link to the list of all merge requests that were merged for this release. In addition to various more minor bugs, this release also fixes CVE-2021-3497 and CVE-2021-3498 as well as other potentially security-relevant issues that didn't get their own CVE. Ubuntu 21.04 and Fedora 34 are also going to release with 1.18.4. Thanks for your consideration! unblock gstreamer1.0/1.18.4-1
Bug#980439: nmu: gst-plugins-bad1.0_1.18.3-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu nmu gst-plugins-bad1.0_1.18.3-1 . ANY . unstable . -m "Rebuild against srt 1.4.2-1.1 with the changed library package name" -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (700, 'unstable'), (500, 'unstable-debug'), (100, 'experimental'), (1, 'experimental-debug') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-1-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#876338: nmu: gstreamer-vaapi_1.12.3-1
On Thu, 2017-09-21 at 11:00 +0200, Emilio Pozuelo Monfort wrote: > Hi Sebastian! > > On 21/09/17 09:57, Sebastian Dröge wrote: > > Package: release.debian.org > > Severity: normal > > User: release.debian@packages.debian.org > > Usertags: binnmu > > > > nmu gstreamer-vaapi_1.12.3-1 . ANY . unstable . -m "Rebuild against > > gstreamer1.0-plugins-bad 1.12.3" > > This was already handled in #876227 (which also took care of the other > dependencies). > > As you mentioned on the webkit bug, it'd be nice to only require this for > minor > (and not micro) releases. Yeah, next upload to gst-plugins-bad will do that :) The micro requirement was a leftover from 0.10 times signature.asc Description: This is a digitally signed message part
Bug#876340: nmu: gstreamer-vaapi_1.12.3-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu nmu gstreamer-vaapi_1.12.3-1 . ANY . unstable . -m "Rebuild against gstreamer1.0-plugins-bad" See bug #868429 for context. Thanks! -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (700, 'unstable'), (500, 'unstable-debug'), (100, 'experimental'), (1, 'experimental-debug') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.11.0-2-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#876339: nmu: gstreamer-vaapi_1.12.3-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu nmu gstreamer-vaapi_1.12.3-1 . ANY . unstable . -m "Rebuild against gstreamer1.0-plugins-bad 1.12.3" See bug #868429 for context. Thanks! -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (700, 'unstable'), (500, 'unstable-debug'), (100, 'experimental'), (1, 'experimental-debug') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.11.0-2-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#876338: nmu: gstreamer-vaapi_1.12.3-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu nmu gstreamer-vaapi_1.12.3-1 . ANY . unstable . -m "Rebuild against gstreamer1.0-plugins-bad 1.12.3" See bug #868429 for context. Thanks! -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (700, 'unstable'), (500, 'unstable-debug'), (100, 'experimental'), (1, 'experimental-debug') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.11.0-2-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#868646: nmu: gstreamer-vaapi_1.12.2-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu Hi, gstreamer-vaapi depends on the exact upstream version of libgstreamer-plugins-bad1.0-0 it was built against. Because this, a binNMU is needed to update the generated dependencies to the latest version. Thanks! nmu gstreamer-vaapi_1.12.2-1 . ANY . unstable . -m "Rebuild against GStreamer 1.12.2 to fix dependencies (Closes: #868429)" -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (700, 'unstable'), (100, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.11.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#868645: nmu: gstreamer-vaapi_1.12.2-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu Hi, gstreamer-vaapi depends on the exact upstream version of libgstreamer-plugins-bad1.0-0 it was built against. Because this, a binNMU is needed to update the generated dependencies to the latest version. Thanks! nmu gstreamer-vaapi_1.12.2-1 . ANY . unstable . -m "Rebuild against GStreamer 1.12.2 to fix dependencies (Closes: #868429)" -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (700, 'unstable'), (100, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.11.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Re: libvpx transition
On So, 2015-05-17 at 14:14 +0300, Sebastian Dröge wrote: > > On May 17, 2015 1:21:29 PM EEST, Julien Cristau wrote: > >On Sun, May 17, 2015 at 12:41:17 +0300, Sebastian Dröge wrote: > > > >> gst-plugins-bad0.10 is uploaded but for some obscure reason landed on > >> the NEW queue because it believed that gstreamer0.10-plugins-bad-doc > >is > >> a new binary package (it is not). > > > >Well... > > > >gstreamer0.10-plugins-bad-doc | 0.10.19-2 | oldoldstable > >| all > >gstreamer0.10-plugins-bad-doc | 0.10.23-7.1+deb7u1 | oldstable > >| all > >gstreamer0.10-plugins-bad-doc | 0.10.23-7.1+deb7u2 | > >oldstable-proposed-updates | all > >gstreamer0.10-plugins-bad-doc | 0.10.23-8 | new > >| all > > > >Certainly looks new to unstable. > > Interesting, indeed. This would mean that one of the nmus was probably > built without arch all packages or something like that. > > I'll check tonight, weird. So, FYI... 0.10.23-7.4 was a "source all" upload, but contained no binary packages at all. Not even the doc package. -7.3 was "source all amd64" and contained all binary packages, including the doc package. signature.asc Description: This is a digitally signed message part
Re: libvpx transition
On May 17, 2015 1:21:29 PM EEST, Julien Cristau wrote: >On Sun, May 17, 2015 at 12:41:17 +0300, Sebastian Dröge wrote: > >> gst-plugins-bad0.10 is uploaded but for some obscure reason landed on >> the NEW queue because it believed that gstreamer0.10-plugins-bad-doc >is >> a new binary package (it is not). > >Well... > >gstreamer0.10-plugins-bad-doc | 0.10.19-2 | oldoldstable >| all >gstreamer0.10-plugins-bad-doc | 0.10.23-7.1+deb7u1 | oldstable >| all >gstreamer0.10-plugins-bad-doc | 0.10.23-7.1+deb7u2 | >oldstable-proposed-updates | all >gstreamer0.10-plugins-bad-doc | 0.10.23-8 | new >| all > >Certainly looks new to unstable. Interesting, indeed. This would mean that one of the nmus was probably built without arch all packages or something like that. I'll check tonight, weird. Thanks -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/a3f063bf-ec0a-46c2-b25b-86426a9aa...@coaxion.net
Re: libvpx transition
On Sa, 2015-05-16 at 08:59 +0200, Emilio Pozuelo Monfort wrote: > On 15/05/15 16:52, Emilio Pozuelo Monfort wrote: > > On 15/05/15 16:30, Sebastian Dröge wrote: > >> Hi Emilio, > >> > >> I indeed forgot that, sorry! > >> > >> On Fr, 2015-05-15 at 16:21 +0200, Emilio Pozuelo Monfort wrote: > >>> Hi Sebastian, > >>> > >>> There's an uncoordinated transition for libvpx in unstable. I suppose you > >>> didn't > >>> remember the soname had changed when re-uploading to unstable now that > >>> the > >>> freeze is over. It affects a few of packages and I do wonder whether the > >>> rdeps > >>> will build just fine or not. I saw this[1] and shows that a few symbols > >>> were > >>> removed, but I don't know if that affects our rdeps. > >> > >> All recent rdeps should build fine against the new version of the > >> library. The removed symbols shouldn't be used by anything (at least I'm > >> not aware of any user), the bigger problem is that some compatibility > >> #defines disappeared from the headers. > >> > >> But I expect everything recent to build just fine. The only thing that > >> probably doesn't is gst-plugins-bad0.10, but that one should really just > >> die and disappear from the archive. > >> > >>> Can you check if the rdeps are fine, so we can schedule binNMUs if > >>> appropriate? > >> > >> Please schedule binNMUs for everything except gst-plugins-bad0.10, that > >> will have to be patched a little. If any of the binNMUs fails for > >> whatever reason, patching the packages should be a matter of sed (I'll > >> check then). > > > > Great, I have scheduled the binNMUs. Let's see how things go. > > So: > > libgd2 and icedove fail to build because of libvpx. I've filed bugs for both. > iceweasel failed to build for seemingly unrelated reasons (and with old > libvpx). > gst-plugins-bad0.10 needs an upload. gst-plugins-bad0.10 is uploaded but for some obscure reason landed on the NEW queue because it believed that gstreamer0.10-plugins-bad-doc is a new binary package (it is not). signature.asc Description: This is a digitally signed message part
Bug#785198: transition: GStreamer 0.10 removal
On Sa, 2015-05-16 at 09:31 +0200, Emilio Pozuelo Monfort wrote: > Hi Sebastian, > > On 13/05/15 13:09, Sebastian Dröge wrote: > > Package: release.debian.org > > Severity: normal > > User: release.debian@packages.debian.org > > Usertags: transition > > > > Hi, > > > > see rationale in this mailing list thread: > > https://lists.debian.org/debian-devel/2015/05/msg00335.html > > > > It was suggested in that thread to also set up a transition tracker for > > this. The main package involved here would be libgstreamer0.10-0, which > > should go away and has libgstreamer1.0-0 as replacement already. > > > > The qt-gstreamer transition (#760003) already clears part of the > > remaining GStreamer 0.10 dependencies. Additionally there are further > > GStreamer 0.10 bindings: > > > > python-gst0.10 is replaced by python-gst1.0 / python3-gst1.0 > > > > libgstreamer0.9-cil is replaced by libgstreamer1.0-cil > > (which is not yet uploaded, upstream release exists) > > > > libgstreamermm-0.10-2 would be replaced by libgstreamermm-1.0-XXX > > (which is also not yet uploaded, upstream release exists) > > > > libgstreamer-perl, haskell-gstreamer > > I'm not aware what the plans there are, the latter also has nothing > > depending on it. > > I don't want to have hundreds of RC bugs just for this. You can file bugs at > say > important severity though, and when the list of rdeps gets down significantly, > they can be raised to serious. Also sending a dd-list to debian-devel can be > useful. I'll send a follow-up with dd-list to debian-devel later. As nobody did any porting of any of these packages over the last 3 years, I doubt that any porting will happen just because I file non-RC bugs for them :) But if you prefer that, I'm going to just file bugs with important severity. Not sure if I should also orphan the GStreamer 0.10 packages on the next uploads, might be the most sensible thing to do though. signature.asc Description: This is a digitally signed message part
Re: libvpx transition
On Sa, 2015-05-16 at 08:59 +0200, Emilio Pozuelo Monfort wrote: > On 15/05/15 16:52, Emilio Pozuelo Monfort wrote: > > On 15/05/15 16:30, Sebastian Dröge wrote: > >> Hi Emilio, > >> > >> I indeed forgot that, sorry! > >> > >> On Fr, 2015-05-15 at 16:21 +0200, Emilio Pozuelo Monfort wrote: > >>> Hi Sebastian, > >>> > >>> There's an uncoordinated transition for libvpx in unstable. I suppose you > >>> didn't > >>> remember the soname had changed when re-uploading to unstable now that > >>> the > >>> freeze is over. It affects a few of packages and I do wonder whether the > >>> rdeps > >>> will build just fine or not. I saw this[1] and shows that a few symbols > >>> were > >>> removed, but I don't know if that affects our rdeps. > >> > >> All recent rdeps should build fine against the new version of the > >> library. The removed symbols shouldn't be used by anything (at least I'm > >> not aware of any user), the bigger problem is that some compatibility > >> #defines disappeared from the headers. > >> > >> But I expect everything recent to build just fine. The only thing that > >> probably doesn't is gst-plugins-bad0.10, but that one should really just > >> die and disappear from the archive. > >> > >>> Can you check if the rdeps are fine, so we can schedule binNMUs if > >>> appropriate? > >> > >> Please schedule binNMUs for everything except gst-plugins-bad0.10, that > >> will have to be patched a little. If any of the binNMUs fails for > >> whatever reason, patching the packages should be a matter of sed (I'll > >> check then). > > > > Great, I have scheduled the binNMUs. Let's see how things go. > > So: > > libgd2 and icedove fail to build because of libvpx. I've filed bugs for both. Those just require a simple sed patch :) It's VPX_PLANE_* and VPX_IMG_FMT_* now instead of the unprefixed versions. > iceweasel failed to build for seemingly unrelated reasons (and with old > libvpx). > gst-plugins-bad0.10 needs an upload. Same for gst-plugins-bad0.10, for which I'll upload a fixed version tonight. Thanks! signature.asc Description: This is a digitally signed message part
Re: libvpx transition
Hi Emilio, I indeed forgot that, sorry! On Fr, 2015-05-15 at 16:21 +0200, Emilio Pozuelo Monfort wrote: > Hi Sebastian, > > There's an uncoordinated transition for libvpx in unstable. I suppose you > didn't > remember the soname had changed when re-uploading to unstable now that the > freeze is over. It affects a few of packages and I do wonder whether the rdeps > will build just fine or not. I saw this[1] and shows that a few symbols were > removed, but I don't know if that affects our rdeps. All recent rdeps should build fine against the new version of the library. The removed symbols shouldn't be used by anything (at least I'm not aware of any user), the bigger problem is that some compatibility #defines disappeared from the headers. But I expect everything recent to build just fine. The only thing that probably doesn't is gst-plugins-bad0.10, but that one should really just die and disappear from the archive. > Can you check if the rdeps are fine, so we can schedule binNMUs if > appropriate? Please schedule binNMUs for everything except gst-plugins-bad0.10, that will have to be patched a little. If any of the binNMUs fails for whatever reason, patching the packages should be a matter of sed (I'll check then). Thanks! Sebastian signature.asc Description: This is a digitally signed message part
Bug#785198: transition: GStreamer 0.10 removal
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hi, see rationale in this mailing list thread: https://lists.debian.org/debian-devel/2015/05/msg00335.html It was suggested in that thread to also set up a transition tracker for this. The main package involved here would be libgstreamer0.10-0, which should go away and has libgstreamer1.0-0 as replacement already. The qt-gstreamer transition (#760003) already clears part of the remaining GStreamer 0.10 dependencies. Additionally there are further GStreamer 0.10 bindings: python-gst0.10 is replaced by python-gst1.0 / python3-gst1.0 libgstreamer0.9-cil is replaced by libgstreamer1.0-cil (which is not yet uploaded, upstream release exists) libgstreamermm-0.10-2 would be replaced by libgstreamermm-1.0-XXX (which is also not yet uploaded, upstream release exists) libgstreamer-perl, haskell-gstreamer I'm not aware what the plans there are, the latter also has nothing depending on it. Sebastian signature.asc Description: This is a digitally signed message part
Bug#769085: (pre-approval for) unblock: gst-libav1.0/1.4.4-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Hi, I'd like to upload gst-libav1.0 1.4.4-1 to unstable. This is currently in experimental as I wanted it to get out there ASAP without blocking any testing migration if this unblock request is not accepted. 1.4.4 is a bugfix release compared to 1.4.3 and only contains non-risky fixes that were backported from GStreamer's GIT master branch. Attached you can find a diff of 1.4.3-1 to 1.4.4-1. Thanks for your consideration! diff --git a/ChangeLog b/ChangeLog index 055e0e8..d645ee2 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,9 +1,21 @@ +=== release 1.4.4 === + +2014-11-06 Sebastian Dröge + + * configure.ac: + releasing 1.4.4 + === release 1.4.3 === -2014-09-24 Sebastian Dröge +2014-09-24 12:50:34 +0300 Sebastian Dröge + * ChangeLog: + * NEWS: + * RELEASE: * configure.ac: - releasing 1.4.3 + * docs/plugins/inspect/plugin-libav.xml: + * gst-libav.doap: + Release 1.4.3 2014-09-22 14:00:07 -0700 Aleix Conchillo Flaqué diff --git a/Makefile.in b/Makefile.in index 3aebc2c..63e110c 100644 --- a/Makefile.in +++ b/Makefile.in @@ -95,8 +95,8 @@ DIST_COMMON = $(top_srcdir)/common/win32.mak \ ChangeLog $(srcdir)/Makefile.in $(srcdir)/Makefile.am \ $(top_srcdir)/configure $(am__configure_deps) \ $(srcdir)/config.h.in $(srcdir)/gst-libav.spec.in COPYING \ - COPYING.LIB TODO compile config.guess config.sub depcomp \ - install-sh missing ltmain.sh + COPYING.LIB TODO compile config.guess config.sub install-sh \ + missing ltmain.sh subdir = . ACLOCAL_M4 = $(top_srcdir)/aclocal.m4 am__aclocal_m4_deps = $(top_srcdir)/common/m4/as-ac-expand.m4 \ diff --git a/NEWS b/NEWS index 6319890..b0d6beb 100644 --- a/NEWS +++ b/NEWS @@ -1,2 +1,2 @@ -This is GStreamer Libav Plugins 1.4.3 +This is GStreamer Libav Plugins 1.4.4 diff --git a/aclocal.m4 b/aclocal.m4 index 089106a..b76e823 100644 --- a/aclocal.m4 +++ b/aclocal.m4 @@ -103,10 +103,9 @@ _AM_AUTOCONF_VERSION(m4_defn([AC_AUTOCONF_VERSION]))]) # configured tree to be moved without reconfiguration. AC_DEFUN([AM_AUX_DIR_EXPAND], -[dnl Rely on autoconf to set up CDPATH properly. -AC_PREREQ([2.50])dnl -# expand $ac_aux_dir to an absolute path -am_aux_dir=`cd $ac_aux_dir && pwd` +[AC_REQUIRE([AC_CONFIG_AUX_DIR_DEFAULT])dnl +# Expand $ac_aux_dir to an absolute path. +am_aux_dir=`cd "$ac_aux_dir" && pwd` ]) # AM_CONDITIONAL-*- Autoconf -*- diff --git a/config.sub b/config.sub index d654d03..bba4efb 100755 --- a/config.sub +++ b/config.sub @@ -2,7 +2,7 @@ # Configuration validation subroutine script. # Copyright 1992-2014 Free Software Foundation, Inc. -timestamp='2014-05-01' +timestamp='2014-09-11' # This file is free software; you can redistribute it and/or modify it # under the terms of the GNU General Public License as published by @@ -302,6 +302,7 @@ case $basic_machine in | pdp10 | pdp11 | pj | pjl \ | powerpc | powerpc64 | powerpc64le | powerpcle \ | pyramid \ + | riscv32 | riscv64 \ | rl78 | rx \ | score \ | sh | sh[1234] | sh[24]a | sh[24]aeb | sh[23]e | sh[34]eb | sheb | shbe | shle | sh[1234]le | sh3ele \ @@ -828,6 +829,10 @@ case $basic_machine in basic_machine=powerpc-unknown os=-morphos ;; + moxiebox) + basic_machine=moxie-unknown + os=-moxiebox + ;; msdos) basic_machine=i386-pc os=-msdos @@ -1373,7 +1378,7 @@ case $os in | -cygwin* | -msys* | -pe* | -psos* | -moss* | -proelf* | -rtems* \ | -mingw32* | -mingw64* | -linux-gnu* | -linux-android* \ | -linux-newlib* | -linux-musl* | -linux-uclibc* \ - | -uxpv* | -beos* | -mpeix* | -udk* \ + | -uxpv* | -beos* | -mpeix* | -udk* | -moxiebox* \ | -interix* | -uwin* | -mks* | -rhapsody* | -darwin* | -opened* \ | -openstep* | -oskit* | -conix* | -pw32* | -nonstopux* \ | -storm-chaos* | -tops10* | -tenex* | -tops20* | -its* \ diff --git a/configure b/configure index ecc8e57..85b78d3 100755 --- a/configure +++ b/configure @@ -1,6 +1,6 @@ #! /bin/sh # Guess values for system-dependent variables and create Makefiles. -# Generated by GNU Autoconf 2.69 for GStreamer libav 1.4.3. +# Generated by GNU Autoconf 2.69 for GStreamer libav 1.4.4. # # Report bugs to <http://bugzilla.gnome.org/enter_bug.cgi?product=GStreamer>. # @@ -591,8 +591,8 @@ MAKEFLAGS= # Identity of this package. PACKAGE_NAME='GStreamer libav' PACKAGE_TARNAME='gst-libav' -PACKAGE_VERSION='1.4.3' -PACKAGE_STRING='GStreamer libav 1.4.3' +PACKAGE_VERSION='1.4.4' +PACKAGE_STRING='GStreamer libav 1.4.4' PACKAGE_BUGREPORT='http://bugzilla.gnome.org/enter_bug.cgi?product=GStreamer' PACKAGE_URL='' @@ -1495,7 +1495,7 @@ if test "$ac_init_help" = "long"; then # Omit some internal or obsolete options to make the li
Bug#769081: (pre-approval for) unblock: gst-plugins-ugly1.0/1.4.4-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Hi, I'd like to upload gst-plugins-ugly1.0 1.4.4-1 to unstable. This is currently in experimental as I wanted it to get out there ASAP without blocking any testing migration if this unblock request is not accepted. 1.4.4 is a bugfix release compared to 1.4.3 and only contains non-risky fixes that were backported from GStreamer's GIT master branch. Attached you can find a diff of 1.4.3-1 to 1.4.4-1. Thanks for your consideration! diff --git a/ChangeLog b/ChangeLog index c41667c..e3d76cf 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,9 +1,86 @@ +=== release 1.4.4 === + +2014-11-06 Sebastian Dröge + + * configure.ac: + releasing 1.4.4 + +2014-11-06 12:31:17 +0100 Sebastian Dröge + + * po/eo.po: + po: Update translations + === release 1.4.3 === -2014-09-24 Sebastian Dröge +2014-09-24 12:48:29 +0300 Sebastian Dröge + * ChangeLog: + * NEWS: + * RELEASE: * configure.ac: - releasing 1.4.3 + * docs/plugins/inspect/plugin-a52dec.xml: + * docs/plugins/inspect/plugin-amrnb.xml: + * docs/plugins/inspect/plugin-amrwbdec.xml: + * docs/plugins/inspect/plugin-asf.xml: + * docs/plugins/inspect/plugin-cdio.xml: + * docs/plugins/inspect/plugin-dvdlpcmdec.xml: + * docs/plugins/inspect/plugin-dvdread.xml: + * docs/plugins/inspect/plugin-dvdsub.xml: + * docs/plugins/inspect/plugin-lame.xml: + * docs/plugins/inspect/plugin-mad.xml: + * docs/plugins/inspect/plugin-mpeg2dec.xml: + * docs/plugins/inspect/plugin-realmedia.xml: + * docs/plugins/inspect/plugin-siddec.xml: + * docs/plugins/inspect/plugin-twolame.xml: + * docs/plugins/inspect/plugin-x264.xml: + * docs/plugins/inspect/plugin-xingmux.xml: + * gst-plugins-ugly.doap: + * win32/common/config.h: + Release 1.4.3 + +2014-09-24 11:50:57 +0300 Sebastian Dröge + + * po/af.po: + * po/az.po: + * po/bg.po: + * po/ca.po: + * po/cs.po: + * po/da.po: + * po/de.po: + * po/el.po: + * po/en_GB.po: + * po/eo.po: + * po/es.po: + * po/eu.po: + * po/fi.po: + * po/fr.po: + * po/gl.po: + * po/hr.po: + * po/hu.po: + * po/id.po: + * po/it.po: + * po/ja.po: + * po/lt.po: + * po/lv.po: + * po/ms.po: + * po/mt.po: + * po/nb.po: + * po/nl.po: + * po/or.po: + * po/pl.po: + * po/pt_BR.po: + * po/ro.po: + * po/ru.po: + * po/sk.po: + * po/sl.po: + * po/sq.po: + * po/sr.po: + * po/sv.po: + * po/tr.po: + * po/uk.po: + * po/vi.po: + * po/zh_CN.po: + Update .po files === release 1.4.2 === diff --git a/Makefile.in b/Makefile.in index 955ee09..02c0e31 100644 --- a/Makefile.in +++ b/Makefile.in @@ -97,7 +97,7 @@ DIST_COMMON = $(top_srcdir)/common/win32.mak \ $(top_srcdir)/configure $(am__configure_deps) \ $(srcdir)/config.h.in $(srcdir)/gst-plugins-ugly.spec.in \ ABOUT-NLS COPYING compile config.guess config.rpath config.sub \ - depcomp install-sh missing ltmain.sh + install-sh missing ltmain.sh subdir = . ACLOCAL_M4 = $(top_srcdir)/aclocal.m4 am__aclocal_m4_deps = $(top_srcdir)/common/m4/as-ac-expand.m4 \ diff --git a/NEWS b/NEWS index 1e5248c..81265e3 100644 --- a/NEWS +++ b/NEWS @@ -1,2 +1,2 @@ -This is GStreamer Ugly Plugins 1.4.3 +This is GStreamer Ugly Plugins 1.4.4 diff --git a/RELEASE b/RELEASE index cda5024..9a27b48 100644 --- a/RELEASE +++ b/RELEASE @@ -1,5 +1,5 @@ -Release notes for GStreamer Ugly Plugins 1.4.3 +Release notes for GStreamer Ugly Plugins 1.4.4 The GStreamer team is pleased to announce a bugfix release of the stable 1.4 release series. The 1.4 release series is adding new features on top @@ -24,6 +24,7 @@ some new features and more intrusive changes that were considered too risky as a bugfix. + "When you have to shoot, shoot. Don't talk." @@ -105,6 +106,5 @@ subscribe to the gstreamer-devel list. Contributors to this release - * Guillaume Desmottes * Sebastian Dröge \ No newline at end of file diff --git a/aclocal.m4 b/aclocal.m4 index bc4f5ff..b1ab167 100644 --- a/aclocal.m4 +++ b/aclocal.m4 @@ -103,10 +103,9 @@ _AM_AUTOCONF_VERSION(m4_defn([AC_AUTOCONF_VERSION]))]) # configured tree to be moved without reconfiguration. AC_DEFUN([AM_AUX_DIR_EXPAND], -[dnl Rely on autoconf to set up CDPATH properly. -AC_PREREQ([2.50])dnl -# expand $ac_aux_dir to an absolute path -am_aux_dir=`cd $ac_aux_dir && pwd` +[AC_REQUIRE([AC_CONFIG_AUX_DIR_DEFAULT])dnl +# Expand $ac_aux_dir to an absolute path. +am_aux_dir=`cd "$ac_aux_dir" && pwd` ]) # AM_CONDITIONAL-*- Autoconf -*- diff --git a/config.sub b/config.sub index d654d03..bba4efb 100755 --- a/config.sub +++ b/config.sub @@ -2,7 +2,7 @@ # Configuration validation subroutine script. # Copyright 1992-2014 Free Software Foundation, Inc. -timestamp='2014-05-01' +timestamp='2014-09-11' # This file is free software; you can redistribute it and/or modify it # under the terms of the GNU General Public License as published by
Re: Accepted orc 0.4.7-1 (source all amd64)
On Mon, 2010-09-13 at 19:50 +0200, Julien Cristau wrote: > Hi Sebastian, > > On Fri, Aug 20, 2010 at 07:17:08 +, Sebastian Dröge wrote: > > > orc (0.4.7-1) unstable; urgency=low > > . > >* New upstream release: > > + debian/rules: > >- Update shlibs version for API additions. > > That's not exactly helpful in the middle of a freeze, since it means > reverse-deps get stuck with a dependency that's not satisfied in > testing. The changes aren't small either, so I'm not looking forward to > reviewing this. So what's your plan for orc in squeeze? Hrm, this should've go to experimental instead of unstable. I'll upload a 1:0.4.6-1 later, which will be the same as previous 0.4.6-1. Sorry signature.asc Description: This is a digitally signed message part
Re: Proxied permission to upload a patched cairo [Was: Bug#502018: Iceweasel rendering problems still exist in Iceweasel 3.5.11 in Sid]
On Mon, 2010-08-16 at 18:54 +0100, Adam D. Barratt wrote: > On Mon, 2010-08-16 at 10:45 +0200, Mike Hommey wrote: > > As I've been asked to convince you to allow a new cairo upload with a > > given patch (see below), here I am ;) > [...] > > On Fri, Aug 13, 2010 at 06:08:07PM +0200, Sebastian Dröge wrote: > > > On Fri, 2010-08-13 at 17:59 +0200, Mike Hommey wrote: > > > > On Fri, Aug 13, 2010 at 05:55:16PM +0200, Sebastian Dröge wrote: > [...] > > > > > Probably but I don't really like the idea of having yet another > > > > > release > > > > > with this workaround for buggy drivers. As long as that workaround is > > > > > in > > > > > cairo nobody will ever fix the buggy drivers... > > > > > > > > > > If nothing happens before squeeze release on the drivers front. (...) > > > > > > > > It hasn't happened since way before lenny released, there is no way this > > > > will happen in the little time remaining before the squeeze release. > > Well, I'm not going to force the maintainers to include the patch if > they don't want to but, yes, I'd accept an upload that incorporated that > patch (preferably without a bunch of unrelated changes that break the > world as well ;-). Well, I asked Mike to ask you because of this patch. It feels dirty to apply this hack again :/ I'll upload a new cairo version with just this patch to unstable soon, thanks. signature.asc Description: This is a digitally signed message part
Please schedule binNMUs for gst-plugins-bad0.10
Hi, please schedule some binNMUs for gst-plugins-bad0.10 against wildmidi >= 0.2.3.2-1. This is the only package affected/depending on wildmidi. Thanks signature.asc Description: This is a digitally signed message part
Re: Decoupling GNOME 2.30 transitions
On Mon, 2010-05-03 at 11:39 +0100, Adam D. Barratt wrote: > On Sun, March 28, 2010 12:54, Josselin Mouette wrote: > > 3 - totem-pl-parser (libtotem-plparser12 â libtotem-plparser17) > > + evince (libevince1 â libevince2) > > As discussed on IRC, please go ahead with these: > > > Sourceful uploads: > > brasero > > evince > > gnome-python-desktop > > totem > > totem-pl-parser Thanks, evince, totem and totem-pl-parser are uploaded to unstable now. Joss, are you doing brasero and gnome-python-desktop? signature.asc Description: This is a digitally signed message part
Re: libmpcdec6 transition
Am Samstag, den 17.10.2009, 11:32 +0200 schrieb Luk Claes: > Sebastian Dröge wrote: > > Hi, > > I'd like to ask if we can continue/finish the libmpcdec6 transition now. > > Relevant bugs can be seen at > > http://bugs.debian.org/cgi-bin/pkgreport.cgi?which=tag&users=debian-rele...@lists.debian.org&data=libmpcdec6-transition > > The faad2 transition should be finished first, it's lasting for a very > long time as people keep uploading packages breaking the transition... > It's very close to succeed now for the third time, I'm at least pushing > part of it in now... Like... now? :) If not, just tell me when it's ok to upload to unstable. signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
libmpcdec6 transition
Hi, I'd like to ask if we can continue/finish the libmpcdec6 transition now. Relevant bugs can be seen at http://bugs.debian.org/cgi-bin/pkgreport.cgi?which=tag&users=debian-rele...@lists.debian.org&data=libmpcdec6-transition Remaining packages are: xine-lib (patch in bug #476374) mpc123 (fixed upstream, see bug #476372) cmus (patch in bug #476382) k3b (patch in bug #476379) libtunepimp (patch in bug #476378) signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Reverting the libmpc 0.1~r435-1 upload
Am Dienstag, den 07.04.2009, 20:27 +0200 schrieb Adeodato Simó: > + Sebastian Dröge (Sat, 21 Mar 2009 09:26:20 +0100): > > Hello, > > > > > I'll take a look at some packages in the next days and send an status > > > > update to those bugs, maybe raising the severity to important now... > > > Sure, important sounds fine to me, thanks. > > > Ok, done... the affected packages are: > > > cmus Bug #476382 > > cynthiune.app Bug #476381 > > gst-plugins-bad0.10 Ported > > k3b Bug #476379 > > libtunepimp Bug #476378 > > moc Ported (FTBFS atm because of other issues) > > mpc123 Bug #476372 > > mpd Bug #476377 > > mplayer Bug #476384 > > qmmp Bug #520596 > > quodlibet Unnecessary dependency, bug #476376 > > vlc Bug #476375 > > xine-lib Bug #476374 > > xine-lib-1.2 Bug #520600 > > xmms2 Bug #476373 > > > Some of them might actually be ported already but they don't > > build their musepack support with the experimental package right > > now. This might be because the header location has changed > > after I've filed those bugs, now it's final though :) > > Well, none of those bugs has been fixed in experimental by now (nor have > a patch), and the one marked as pending (the one that is not quodlibet), > has a comment by the maintainer stating that he intends to disable > musepack support while upstream gets around to fixing the issue. The > picture doesn’t look very promising: > > http://bit.ly/libmpcdec6-transition > > I’m all for getting this transition done without leaving the old API > around, but at the same time I don’t want packages unbuildable in > unstable, with failures that are not straightforward to fix, for a long > period of time. > > As I said in one of my earlier mails, I won’t feel comfortable with > going forward with this transition until all (or most) of the packages > have tested patches. The thing is that for this to happen, we’re going > to need either time, quite a lot of it, or for somebody to step up and > start “driving” the transition, filling the gaps the maintainers may > leave. > > So the question is whether you have the time and inclination to do the > latter yourself, if you want the transition done sooner rather than > later, working with maintainers on a solution for each particular > package (a solution that does not entail, preferably, dropping Musepack > support from the application). For example, Rafael Laboissiere, the > maintainer of libmtp, did exactly this for the recent libmtp7 -> libmtp8 > transition: he filed bugs, provided patches, and did a bunch of NMUs, > which allowed us to do the transition in a timely manner. > > So, do we have a plan, or do we just opt for waiting? I’m Bcc'ing all of > the involved bugs so that maintainers can send an update on the status > of their bug (to the debian-release mailing list and *your* bug, > please). If a fix exists, please send it to the BTS with an appropriate > “patch” tag or, preferably, make an upload to experimental. Ok, we've waited some months now and according to your bug list only 5 packages are missing. xine-lib, xine-lib-1.2 are ported already IIRC, mpc123 was ported upstream already so that makes 2 packages (k3b and libtunepimp). Do you think now is a good time for an upload or shall we really wait until the last package is ported? signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Libass transition
Am Sonntag, den 29.03.2009, 19:41 +0200 schrieb Adeodato Simó: > * Christophe Mutricy [Wed, 25 Mar 2009 23:16:24 +0100]: > > > Hi, > > Hello, Christophe. > > > Can I upload libass 0.9.6 in unstable. It has a SO version with these > > reverse dependency: > > > vlc > > gstreamer0.10-plugins-bad > > You can upload now. Please let me know when it’s in unstable, and I’ll > schedule the necessary Bin-NMUs. I'd like to upload a sourceful upload of gst-plugins-bad... when shall I do it? :) signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Libass transition
Am Mittwoch, den 25.03.2009, 23:16 +0100 schrieb Christophe Mutricy: > Hi, > > Can I upload libass 0.9.6 in unstable. It has a SO version with these > reverse dependency: > > vlc > gstreamer0.10-plugins-bad > > > Hmm, now i 've just read your mail on d-d-a and both package are > affected. So I guess I should wait for the ffmpeg+libraw1394 transition > to happen. Are there API changes or just ABI changes? In case of the former, could you upload it to experimental now already? :) signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Reverting the libmpc 0.1~r435-1 upload
Am Samstag, den 14.03.2009, 18:46 +0100 schrieb Adeodato Simó: > * Sebastian Dröge [Sat, 14 Mar 2009 12:20:11 +0100]: > > > I'll take a look at some packages in the next days and send an status > > update to those bugs, maybe raising the severity to important now... > > Sure, important sounds fine to me, thanks. Ok, done... the affected packages are: cmus Bug #476382 cynthiune.app Bug #476381 gst-plugins-bad0.10 Ported k3b Bug #476379 libtunepimp Bug #476378 moc Ported (FTBFS atm because of other issues) mpc123 Bug #476372 mpd Bug #476377 mplayer Bug #476384 qmmp Bug #520596 quodlibet Unnecessary dependency, bug #476376 vlc Bug #476375 xine-lib Bug #476374 xine-lib-1.2 Bug #520600 xmms2 Bug #476373 Some of them might actually be ported already but they don't build their musepack support with the experimental package right now. This might be because the header location has changed after I've filed those bugs, now it's final though :) Bye signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Reverting the libmpc 0.1~r435-1 upload
Am Mittwoch, den 11.03.2009, 23:15 +0100 schrieb Adeodato Simó: > * Sebastian Dröge [Wed, 11 Mar 2009 06:39:47 +0100]: > > Hello again, > > > Ok, sounds sensible and I'm sorry that this has caused some problems. > > I've filed bugs on all packages that b-d on libmpc-dev about one year > > ago at the time when it was uploaded to unstable and the maintainers > > that talked to me afterwards said that they'll care for this after it's > > uploaded to unstable. > > > Porting to the new API shouldn't be that hard so what would you propose > > how we do this transition? I'll upload the new package with updated > > epoch to experimental later today, maybe this time the maintainers of > > packages that b-d on libmpc-dev also want to port their applications > > before it's in unstable ;) Just tell me when you think it's a good time > > to upload it again to unstable. > > Hm. I think it’d be great if you could mail each of these bugs, saying > that the upload to unstable will happen soon, and that’d it’d be great > if they could look into looking at porting their applications already. > > Ideally, libmpc would be uploaded to unstable one all of these bugs have > a patch confirmed to work (eg. by uploading it to experimental with > properly versioned build-depends). That should give us some reassurance > that we’re not going to have things eternally broken in unstable. > > Providing patches if, of course, one way of ensuring the transition will > happen sooner rather than later. I'll take a look at some packages in the next days and send an status update to those bugs, maybe raising the severity to important now... On another topic, shall I upload another sourcefull upload of gst-plugins-bad0.10 or wait until it has moved to testing after a binNMU against old libmpcdec? signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Reverting the libmpc 0.1~r435-1 upload
Am Dienstag, den 10.03.2009, 17:34 +0100 schrieb Adeodato Simó: > Hello, Sebastian. > > I'm writing you to inform you that I've just made an epoched upload of > the old libmpcdec pacakge to unstable, which means that libmpcdec-dev > will be provided again by libmpcdec, taking over libmpc's. > > The recent upload of libmpc to unstable implied a SONAME bump, but it > was not coordinated with the Release Team. However, this is not the > reason why I've reverted your upload, since there have been already some > other uncoordinated transitions, and I've just incorporated them to the > list of ongoing transitions. > > However, libmpcdec-dev 0.1~r435-1 introduces API changes. At first I > thought that they were only the move of include files from > /usr/include/mpcdec to /usr/include/mpc, which would be pretty trivial > to fix. But that is not the case: there are true API changes that are > going to require porting of the applications, and we simply can't afford > allowing that in unstable at the moment for a library that would tie > itself to several ongoing transitions (ffmpeg, to begin with), and would > block them for who knows how long. > > I'm not sure what your response to this mail will be. Hopefully you'll > understand the above reasons, and when you reply, will be able to talk > about how to do the libmpcdec transition properly, by ensuring all > reverse dependencies have a fix in form of tested patch by the time the > transition starts in unstable. But I must also inform you that uploads > of libmpc to unstable are blocked until the ffmpeg transition completes. Ok, sounds sensible and I'm sorry that this has caused some problems. I've filed bugs on all packages that b-d on libmpc-dev about one year ago at the time when it was uploaded to unstable and the maintainers that talked to me afterwards said that they'll care for this after it's uploaded to unstable. Porting to the new API shouldn't be that hard so what would you propose how we do this transition? I'll upload the new package with updated epoch to experimental later today, maybe this time the maintainers of packages that b-d on libmpc-dev also want to port their applications before it's in unstable ;) Just tell me when you think it's a good time to upload it again to unstable. signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: libmtp7 -> libmtp8 transition
Am Samstag, den 21.02.2009, 21:56 +0100 schrieb Adeodato Simó: > > * banshee > > > I could not build this package in my sid/experimental system because of a > > complex web of dependencies starting with cli-common-dev. However, Ubuntu > > intrepid has version 1.2.1-3ubuntu1 that depends on libmtp8. > > I'm CC'ing the banshee maintainer to see if he thinks that the version > in unstable can be rebuilt against libmtp8 or not, because I'm fearing > the version in experimental is tied to the Mono transition (can you > confirm, Sebastian?) Yes, banshee works fine with libmtp8 but I need to wait until mono 2.0 is in unstable. signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
BinNMUs for all packages that built with libglib2.0-dev (= 2.16.4-1)
Hi, please schedule binNMUs for all packages that built with libglib2.0-dev (= 2.16.4-1) on big endian architectures. This version of GLib had a bug, caused by changed behaviour of AC_C_BIGENDIAN in autoconf 2.62, that resulted in #define G_BYTE_ORDER G_LITTLE_ENDIAN in glibconfig.h. As this macro is used in many public glib macros and also used very often in other software every package that built with 2.16.4 on big endian architectures is now potentially broken. glib2.0 2.16.4-2 will fix this issue. signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Please schedule binNMUs of gstreamer0.10-ffmpeg against new ffmpeg
Am Samstag, den 24.05.2008, 18:53 +0200 schrieb Adeodato Simó: > * Sebastian Dröge [Thu, 22 May 2008 10:01:53 +0200]: > > > Hi, > > please schedule binNMUs of gstreamer0.10-ffmpeg on all architectures > > against ffmpeg-free >= 0.svn20080206-5. The previous version had some > > symbols duplicated between libswscale and libavcodec and this resulted > > in broken linking (the symbols of libswscale were needed but it was > > linked against the libavcodec ones, thus no dependency on libswscale). > > Hello, > > it seems there's been a gstreamer0.10-ffmpeg upload after this mail > (0.10.4-2), which got built against -5 everywhere. *However*, note that > the package still does not depend on libswscale0 (just mentioning in > case there's something wrong with that). > > Please let us know if we should schedule something after all. No, that's all fine now. I've removed the requirement of libswscale in 0.10.4-2 as there was a faster alternative in libavcodec for these concrete use cases. signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Please schedule binNMUs of gstreamer0.10-ffmpeg against new ffmpeg
Hi, please schedule binNMUs of gstreamer0.10-ffmpeg on all architectures against ffmpeg-free >= 0.svn20080206-5. The previous version had some symbols duplicated between libswscale and libavcodec and this resulted in broken linking (the symbols of libswscale were needed but it was linked against the libavcodec ones, thus no dependency on libswscale). This is fixed in the new version and to my knowledge the only package affected by this is gstreamer0.10-ffmpeg. Thanks signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Bug#477331: cairo bug workarounded at d-i
Am Donnerstag, den 08.05.2008, 14:02 -0300 schrieb Otavio Salvador: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hello RM team, > > We've added a workaround at d-i to the cairo's bug #477441 to avoid to > delay the installer release. This issue is really serious from Debian > Installer point of view and we'd like to get it fixed as soon as > possible. > > I've sent a follow-up to the bug (here in CC) asking for the directfb > backend changes to be reverted to the latest working code _but_ to > wait until we release Debian Installer Lenny Beta 2 for the upload. > > With that in mind, I'd like to ask for the cairo unblock. > > I'll keep in touch with cairo maintainer and GNOME team to get it > done. Ok, now that cairo is in testing I'll upload a new cairo on Monday or Tuesday that reverts the broken DirectFB code. Fine with you? signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Bug#477454: bugs is serious, sorry
Am Montag, den 28.04.2008, 13:06 +0200 schrieb Tristan Seligmann: > * Sebastian Dröge <[EMAIL PROTECTED]> [2008-04-25 23:28:18 +0200]: > > > Well, the upstream code is just a bit nicer now: > > http://www.sacredchao.net/quodlibet/changeset/4267 > > Okay, I don't see much point in arguing over this further; is the > upstream change enough to make you (Sebastian) and the release team > happy? If so, I'll roll a new tarball with that change, and upload that > (I'll need someone to sponsor the upload, though.) I can sponsor this upload if you want. But the upstream change is not enough to make me completely happy. I'd prefer if this line contained just a neutral URL instead of an URL that expresses the wish to let me choke on cookies ;) signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
binNMUs for libspeex dropping .la files
Hi, please schedule binNMUs for the following packages as latest libspeex was dropping .la files, making packages depending on the following fail to build: libshout Thanks signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
binNMUs against libupnp3
Hi, please schedule binNMUs for the following packages for the libupnp3 SONAME transition: amule gmyth-upnp wmaloader Thanks signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
binNMUs for libffi transition
Hi, could someone schedule a binNMU for pygobject (against libffi-dev 3.0.4-1). After that has finished please schedulebinNMUs for the packages below on all archs (with dep-wait on the pygobject binNMU and libffi-dev >= 3.0.4-1). deskbar-applet emesene exaile gdesklets gedit gnome-games gnome-orca gnome-python-desktop gnumeric griffith gtk-vnc matplotlib miro museek+ music-applet nicotine notify-python ontv pigment-python pygobject pygtksourceview pyscrabble rhythmbox sonata streamtuner sugar-toolkit tinyerp-client virt-manager vte Thanks signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
binNMUs for libgnomekbd 2.22.0
Hi, please schedule binNMUs for libgnomekbd 2.22.0 soname change. The following packages are affected: gnome-screensaver 2.22.0-1 gnome-applets 2.20.1-3 All others had a sourcefull upload recently which build depends on the new version. Thanks signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: binNMUs for gtk-sharp2 2.10.4-2
Am Mittwoch, den 05.03.2008, 23:49 -0800 schrieb Steve Langasek: > On Tue, Mar 04, 2008 at 11:20:41AM +0100, Sebastian Dröge wrote: > > > Am Dienstag, den 04.03.2008, 00:02 -0800 schrieb Steve Langasek: > > > On Mon, Mar 03, 2008 at 05:15:00AM +0100, Sebastian Dröge wrote: > > > > Hi, > > > > could you please schedule binNMUs for gtk-sharp2 2.10.4-2? The previous > > > > one had a broken clilibs control file, resulting in bugs like #468906 > > > > (builds against new version won't work with old version). > > > > > gnome-sharp2 2.16.1-1 > > > > How do I know by looking at the packages which architectures need binNMUed > > > and which don't? > > > If the packages have dependencies on libglib2.0-cil (>= 2.10.1) or > > libgtk2.0-cil (>= 2.10.1) they need a binNMU. Those dependencies should > > all be >= 2.10.4 > > It looks like gnome-sharp2 depended on (>= 2.10.2), not (>= 2.10.1); does it > still need binNMUed? Yes, I meant 2.10.2, sorry. > And the packages that depend on libglib2.0-cil (>= 2.10.2) have arch: all > packages built from the same source which have the same dependency - do > those packages also need to be rebuilt? If so, these packages need > sourceful uploads, not binNMUs. Ok, then I'll do a sourceful upload instead. Just curious, but why are binNMUs of arch: all packages not possible? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: binNMUs for gtk-sharp2 2.10.4-2
Am Dienstag, den 04.03.2008, 00:02 -0800 schrieb Steve Langasek: > On Mon, Mar 03, 2008 at 05:15:00AM +0100, Sebastian Dröge wrote: > > Hi, > > could you please schedule binNMUs for gtk-sharp2 2.10.4-2? The previous > > one had a broken clilibs control file, resulting in bugs like #468906 > > (builds against new version won't work with old version). > > > gnome-sharp2 2.16.1-1 > > How do I know by looking at the packages which architectures need binNMUed > and which don't? If the packages have dependencies on libglib2.0-cil (>= 2.10.1) or libgtk2.0-cil (>= 2.10.1) they need a binNMU. Those dependencies should all be >= 2.10.4 signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
binNMUs for gtk-sharp2 2.10.4-2
Hi, could you please schedule binNMUs for gtk-sharp2 2.10.4-2? The previous one had a broken clilibs control file, resulting in bugs like #468906 (builds against new version won't work with old version). gnome-sharp2 2.16.1-1 Thanks signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
binNMUs for libxklavier12-dev
Hi, please schedule binNMUs for the following packages because of libxklavier12-dev. This is necessary because the soname of libxklavier changed once more and these packages are depending on the old version (but not build depending on them). gnome-screensaver 2.20.0-2 gnome-applets 2.20.1-2 Thanks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
binNMU for aubio
Hi, please schedule binNMUs for aubio 0.3.2-2 on all archs. This is necessary because libfftw3f previously had /usr/lib/libfftw3f.la but this file was dropped since then. Unfortunately libaubio.la still lists it which makes everything linking against it fail. Thanks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: binNMU for gst0.10-python
Am Montag, den 04.02.2008, 23:32 -0800 schrieb Steve Langasek: > On Wed, Jan 30, 2008 at 04:46:05PM +0100, Sebastian Dröge wrote: > > > please schedule a binNMU for gst0.10-python on all archs against > > libgstreamer0.10-0 (>= 0.10.17) and libgstreamer-plugins-base0.10-0 (>= > > 0.10.17). The old version, 0.10.16, had an accidental ABI breakage. > > Does this mean that version 0.10.17 restores ABI compatibility with 0.10.15 > and earlier? In short: yes. The longer story is, that there was a ABI breakage in 0.10.14 that nobody noticed unfortunately. The last element(s) of two structs disappeared due to a stupid change that only happens when compiling with -DGST_DISABLE_DEPRECATED which was the default until 0.10.16. This broke nothing and since then everything seems to be rebuild. In 0.10.16 upstream started to not build releases with -DGST_DISABLE_DEPRECATED and the structs growed a bit again to the old, intended situation which broke applications. The fix in 0.10.17 is to have this struct fields removed in any case which of course is a ABI breakage compared to 0.10.13 and before... but as nobody ever noticed this seemed to be the correct decision. signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
binNMU for gst0.10-python
Hi, please schedule a binNMU for gst0.10-python on all archs against libgstreamer0.10-0 (>= 0.10.17) and libgstreamer-plugins-base0.10-0 (>= 0.10.17). The old version, 0.10.16, had an accidental ABI breakage. Thanks and bye signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: binNMUs for cli-common 0.5.5
Am Samstag, den 12.01.2008, 00:15 -0800 schrieb Steve Langasek: > On Wed, Jan 09, 2008 at 07:04:59AM +0100, Sebastian Dröge wrote: > > Hi, > > please schedule binNMUs for the following packages for cli-common 0.5.5. > > Because of a bug in older version dh_makeclilibs created broken clilibs > > control files. > > > > monodoc 1.2.6-2 > > Arch: all packages, not binNMUable. Ah, good to know, I'll upload a new version later. > > gmime 2.2.15-1 > > No package by this name in unstable. Sorry, gmime2.2 is the package name. > > taglib-sharp 2.0.2.0-2 > > Already done, according to your other message. > > > banshee 0.13.2+dfsg-1 > > Also appears to be superseded by a new sourceful upload by you? Right, should be 0.13.2+dfsg-2 (binNMU against taglib-sharp 2.0.3.0-1). signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: binNMUs for cli-common 0.5.5
Am Mittwoch, den 09.01.2008, 08:08 +0100 schrieb Sebastian Dröge: > Am Mittwoch, den 09.01.2008, 07:05 +0100 schrieb Sebastian Dröge: > > Hi, > > please schedule binNMUs for the following packages for cli-common 0.5.5. > > Because of a bug in older version dh_makeclilibs created broken clilibs > > control files. > > > > monodoc 1.2.6-2 > > gmime 2.2.15-1 > > taglib-sharp 2.0.2.0-2 > > banshee 0.13.2+dfsg-1 > > Correction: > banshee 0.13.2+dfsg-2 should get a binNMU against the binNMU'd > taglib-sharp... And another update: taglib-sharp is already done because of a new upstream release. Would be nice to get a banshee binNMU against that then, all others are still valid though. signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: binNMUs for cli-common 0.5.5
Am Mittwoch, den 09.01.2008, 07:05 +0100 schrieb Sebastian Dröge: > Hi, > please schedule binNMUs for the following packages for cli-common 0.5.5. > Because of a bug in older version dh_makeclilibs created broken clilibs > control files. > > monodoc 1.2.6-2 > gmime 2.2.15-1 > taglib-sharp 2.0.2.0-2 > banshee 0.13.2+dfsg-1 Correction: banshee 0.13.2+dfsg-2 should get a binNMU against the binNMU'd taglib-sharp... signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
binNMUs for cli-common 0.5.5
Hi, please schedule binNMUs for the following packages for cli-common 0.5.5. Because of a bug in older version dh_makeclilibs created broken clilibs control files. monodoc 1.2.6-2 gmime 2.2.15-1 taglib-sharp 2.0.2.0-2 banshee 0.13.2+dfsg-1 Thanks and bye signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
binNMUs for eel2 2.20.0-2
Hi, please schedule binNMUs for eel2 rdepends on all archs. eel2 changed the soname from version 2.18 to 2.20, the API is essentially the same. Packages involved: gnome-mount link-monitor-applet mail-notification nautilus nautilus-cd-burner nautilus-python nautilus-share Thanks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: binNMUs for glib2.0 2.14.1-2
Am Montag, den 17.09.2007, 20:47 -0700 schrieb Steve Langasek: > Hi Sebastian, > > On Mon, Sep 17, 2007 at 11:42:30PM +0200, Sebastian Dröge wrote: > > Hi, > > please schedule binNMUs for glib2.0 2.14.1-2 on all archs against pcre3 > > 7.3-2 (libpcre3-dev). > > The binNMU is needed because of broken shlibs (required to low version) > > in the previous pcre version and glib uses newer symbols than available > > in the old shlibs version. > > The pcre 7.3-2 changelog says: > >* Increased shlibdeps from 4.5 to 6.0. 6.0 introduced a new function > (pcre_compile2) to the API, so anything using that requires at least > 6.0. (Closes #441345) > > But etch already had pcre 6.7-1, so surely there's no reason to worry about > getting (>= 6.0) in the dependencies for this one library in particular in > unstable? Hm, as glib required pcre 7.2 for building I assumed that there are some new symbols. Might be a wrong assumption, I'll check it later. signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
binNMUs for glib2.0 2.14.1-2
Hi, please schedule binNMUs for glib2.0 2.14.1-2 on all archs against pcre3 7.3-2 (libpcre3-dev). The binNMU is needed because of broken shlibs (required to low version) in the previous pcre version and glib uses newer symbols than available in the old shlibs version. Thanks signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
binNMU requests for nautilus-cd-burner
Hi, please schedule the following binNMUs for the libnautilus-burn3 -> libnautilus-burn4 transition. Please note that banshee was recently uploaded and is currently still in incoming. The previous versions were not binNMU safe. rhythmbox_0.9.6-9, Rebuild against libnautilus-burn4, 1, alpha amd64 arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc gnome-media_2.18.0-2, Rebuild against libnautilus-burn4, 1, alpha amd64 arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc brasero_0.4.4-4, Rebuild against libnautilus-burn4, 1, alpha amd64 arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc banshee_0.12.1+dfsg-3, Rebuild against libnautilus-burn4, 1, amd64 arm i386 ia64 powerpc Thanks and Bye signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
binNMU request for epiphany-browser 2.18
Hi, please schedule the following binNMU for the new epiphany-browser 2.18 in unstable. The path for extensions has changed from /usr/lib/epiphany/2.14 to /usr/lib/epiphany/2.14. Please note that seahorse doesn't depend on epiphany-browser but still provides an epiphany extension. seahorse_1.0.1-2, Rebuild against epiphany-browser 2.18, 1, alpha amd64 arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc Thanks and Bye signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
binNMU requests for libgail17 -> libgail18 transition
Hi, please schedule the following binNMUs: eel2_2.14.3-5, Rebuild against libgail18, 1, alpha amd64 arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc ghex_2.8.2-3, Rebuild against libgail18, 1, alpha amd64 arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc glade_2.12.1-7, Rebuild against libgail18, 1, alpha amd64 arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc gnome-media_2.14.2-5, Rebuild against libgail18, 1, alpha amd64 arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc gnome-mount_0.6-1, Rebuild against libgail18, 1, alpha amd64 arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc gtkhtml3.8_3.12.1-2, Rebuild against libgail18, 1, alpha amd64 arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc libgtkhtml2_2.11.0-3, Rebuild against libgail18, 1, alpha amd64 arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc link-monitor-applet_2.1-1, Rebuild against libgail18, 2, alpha amd64 arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc mail-notification_4.0.dfsg.1-1, Rebuild against libgail18, 1, alpha amd64 arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc music-applet_0.9.2-3, Rebuild against libgail18, 2, alpha amd64 arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc nautilus_2.14.3-11, Rebuild against libgail18, 2, alpha amd64 arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc nautilus-cd-burner_2.14.3-8, Rebuild against libgail18, 2, alpha amd64 arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc nautilus-python_0.4.3-1.1, Rebuild against libgail18, 1, alpha amd64 arm hppa i386ia64 m68k mips mipsel powerpc s390 sparc Thanks and Bye signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [Pkg-mono-group] Please add mono 1.2.3.1 to unstable (and, eventually, etch) rather than experimental
On Di, 2007-03-06 at 12:29 +0100, Wouter Verhelst wrote: > Hi, > > I know this is going to be kinda controversial, but I'd really like to > make a case to either upload mono 1.2.3.1 to unstable (and eventually > have it migrate to etch), or to at least backport the fix for #403495 to > the version in unstable. The fix for that bug is not easy to backport as it's not just one SVN revision but a few with interdependencies. At least IIRC, I looked at it some time ago. I would definitely love to see 1.2.3.1 in etch but I doubt it will be possible as the diff between 1.2.2.1 and 1.2.3.1 is rather large and not easy to review, not all changes are bugfixes but there are also other improvements in different libraries. We (the Mono team) decided that we won't upload 1.2.3.1 (or any other new upstream versions of mono and related software) to unstable unless it's guaranteed by the release team that it will go to etch... otherwise it will cause some unnecessary trobule to get smaller fixes into etch without going through unstable first... Apart from that I don't know about a single regression from 1.2.2.1 to 1.2.3.1 until now, only general improvements. Bye signature.asc Description: This is a digitally signed message part
