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 jcris...@debian.org 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 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
Re: libvpx transition
On May 17, 2015 1:21:29 PM EEST, Julien Cristau jcris...@debian.org 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. 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
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
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#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 sl...@coaxion.net + + * configure.ac: + releasing 1.4.4 + +2014-11-06 12:31:17 +0100 Sebastian Dröge sebast...@centricular.com + + * po/eo.po: + po: Update translations + === release 1.4.3 === -2014-09-24 Sebastian Dröge sl...@coaxion.net +2014-09-24 12:48:29 +0300 Sebastian Dröge sebast...@centricular.com + * 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 sebast...@centricular.com + + * 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
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 sl...@coaxion.net + + * configure.ac: + releasing 1.4.4 + === release 1.4.3 === -2014-09-24 Sebastian Dröge sl...@coaxion.net +2014-09-24 12:50:34 +0300 Sebastian Dröge sebast...@centricular.com + * 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é aconchi...@gmail.com 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 list less imposing. # This message is too long to be a string in the A/UX 3.1 sh. cat _ACEOF
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: 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=tagusers=debian-rele...@lists.debian.orgdata=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=tagusers=debian-rele...@lists.debian.orgdata=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: 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
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
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 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]
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
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
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 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 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
