Bug#1019047: O: gst123 -- GStreamer based command line media player
Package: wnpp Severity: normal Control: affects -1 src:gst123 I intend to orphan the gst123 package. The package description is: The program gst123 is designed to be a more flexible command line player in the spirit of ogg123 and mpg123, based on GStreamer. It plays all file formats supported by GStreamer, so if you have audio/video collections which contain different file formats, like flac, ogg and mp3, you can use gst123 to play all your audio/video files.
Bug#1019046: O: buzztrax -- Modular music composer
Package: wnpp Severity: normal Control: affects -1 src:buzztrax I intend to orphan the buzztrax package. The package description is: Buzztrax aims to be a music studio that allows one to compose songs using only a computer with a soundcard. If you’ve used tracker programs like FastTracker, Impulse Tracker, or the original AMIGA SoundTracker, that will give you an idea of how one can sequence music in Buzztrax. The Buzztrax editor uses a similar concept, where a song consists of a sequence with tracks and in each track one uses patterns with events (musical notes and control changes). In contrast to other Tracker programs, tracks are not simply sample players: a user can make a song using an arrangement of virtual audio plugins that are linked together to create different effects. Each of these machines can be controlled realtime or via patterns in the sequencer.
Bug#1018070: O: pitivi -- non-linear audio/video editor using GStreamer
Package: wnpp Severity: normal Control: affects -1 src:pitivi I intend to orphan the pitivi package. The package description is: GStreamer is a streaming media framework, based on graphs of filters which operate on media data. Applications using this library can do anything from real-time sound processing to playing videos, and just about anything else media-related. Its plugin-based architecture means that new data types or processing capabilities can be added simply by installing new plug-ins. . PiTiVi allows users to easily edit audio/video projects based on the GStreamer framework. PiTIVi provides several ways of creating and modifying a timeline. Ranging from a simple synopsis view (a-la iMovie) to the full-blown editing view (aka Complex View) which puts you in complete control of your editing.
Bug#1018069: O: game-music-emu -- Playback library for video game music files - development files
Package: wnpp Severity: normal Control: affects -1 src:game-music-emu I intend to orphan the game-music-emu package. The package description is: game-music-emu is a collection of video game music file emulators that support the following formats and systems: * AYZX Spectrum/Amstrad CPC * GBS Nintendo Game Boy * GYM Sega Genesis/Mega Drive * HES NEC TurboGrafx-16/PC Engine * KSS MSX Home Computer/other Z80 systems (doesn't support FM sound) * NSF/NSFE Nintendo NES/Famicom (with VRC 6, Namco 106, and FME-7 sound) * SAP Atari systems using POKEY sound chip * SPC Super Nintendo/Super Famicom * VGM/VGZ Sega Master System/Mark III, Sega Genesis/Mega Drive,BBC Micro . This package contains the header files, static libraries and symbolic links that developers using libgme will need.
Bug#1017905: Ships autogenerated files that can't be renegerated with the code in Debian main
Source: rust-glib-sys Version: 0.14.0-1 Severity: serious See the discussion on the Debian Rust maintainers list for background: https://alioth-lists.debian.net/pipermail/pkg-rust-maintainers/2022-August/022857.html For more details how to solve this in a way that makes ftp-masters happy, please refer to them. This doesn't affect only rust-glib-sys but basically every library crate package that depends on it, i.e. - rust-atk and rust-atk-sys - rust-gdk and rust-gdk-sys - rust-gdk4 and rust-gdk4-sys - rust-gdk-pixbuf and rust-gdk-pixbuf-sys - rust-gdk4-wayland and rust-gdk4-wayland-sys - rust-gdk4-x11 and rust-gdk4-x11-sys - rust-gdkx11 and rust-gdkx11-sys - rust-gio and rust-gio-sys - rust-glib and rust-glib-sys - rust-gobject-sys - rust-graphene-rs and rust-graphene-sys - rust-gsk4 and rust-gsk4-sys - rust-gstreamer and rust-gstreamer-sys - rust-gstreamer-* and rust-gstreamer-*-sys - rust-gtk and rust-gtk-sys - rust-gtk4 and rust-gtk4-sys - rust-libhandy and rust-libhandy-sys - rust-pango and rust-pango-sys - rust-pangocairo and rust-pangocairo-sys I'm not going to file bugs for all these packages as they're all maintained by the Rust team and they all have to be solved in the same way. -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (700, 'unstable'), (500, 'unstable-debug'), (100, 'experimental'), (1, 'experimental-debug') merged-usr: no Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.18.0-4-amd64 (SMP w/8 CPU threads; PREEMPT) 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#1017904: Ships autogenerated files that can't be renegerated with the code in Debian main
Source: webkit2-sharp Version: 2.10.9+git20160917-1.1 Severity: serious Tags: upstream See the discussion on the Debian Rust maintainers list for background: https://alioth-lists.debian.net/pipermail/pkg-rust-maintainers/2022-August/022857.html While that discussion is about Rust packages that were rejected, the same situation also applies to gtk-sharp unfortunately. For more details how to solve this in a way that makes ftp-masters happy, please refer to them. Affected file is sources/webkit2-sharp-api.raw. This file was autogenerated from specific versions of the underlying C libraries and it's not clear which versions were used. Debian ships these C libraries but certainly in different versions so it's not possible to regenerate these files with what is available in Debian. It will be necessary to either include the source code of the C libraries in the exact version, or regenerate the files at build time with whatever is available in Debian. The latter will probably generate different bindings, potentially even with different API, so is probably not a useful solution. -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (700, 'unstable'), (500, 'unstable-debug'), (100, 'experimental'), (1, 'experimental-debug') merged-usr: no Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.18.0-4-amd64 (SMP w/8 CPU threads; PREEMPT) 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#1017903: Ships autogenerated files that can't be renegerated with the code in Debian main
Source: soup-sharp Version: 2.42.2+git20151219-3.1 Severity: serious Tags: upstream See the discussion on the Debian Rust maintainers list for background: https://alioth-lists.debian.net/pipermail/pkg-rust-maintainers/2022-August/022857.html While that discussion is about Rust packages that were rejected, the same situation also applies to gtk-sharp unfortunately. For more details how to solve this in a way that makes ftp-masters happy, please refer to them. Affected file is soup/soup-sharp-api.raw. This file was autogenerated from specific versions of the underlying C libraries and it's not clear which versions were used. Debian ships these C libraries but certainly in different versions so it's not possible to regenerate these files with what is available in Debian. It will be necessary to either include the source code of the C libraries in the exact version, or regenerate the files at build time with whatever is available in Debian. The latter will probably generate different bindings, potentially even with different API, so is probably not a useful solution. -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (700, 'unstable'), (500, 'unstable-debug'), (100, 'experimental'), (1, 'experimental-debug') merged-usr: no Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.18.0-4-amd64 (SMP w/8 CPU threads; PREEMPT) 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#1017902: Ships autogenerated files that can't be renegerated with the code in Debian main
Source: poppler-sharp Version: 0.0.3-4.1 Severity: serious Tags: upstream See the discussion on the Debian Rust maintainers list for background: https://alioth-lists.debian.net/pipermail/pkg-rust-maintainers/2022-August/022857.html While that discussion is about Rust packages that were rejected, the same situation also applies to gtk-sharp2 unfortunately. For more details how to solve this in a way that makes ftp-masters happy, please refer to them. Affected file is poppler/poppler-api.raw. This file was autogenerated from specific versions of the underlying C libraries and it's not clear which versions were used. Debian ships these C libraries but certainly in different versions so it's not possible to regenerate these files with what is available in Debian. It will be necessary to either include the source code of the C libraries in the exact version, or regenerate the files at build time with whatever is available in Debian. The latter will probably generate different bindings, potentially even with different API, so is probably not a useful solution. -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (700, 'unstable'), (500, 'unstable-debug'), (100, 'experimental'), (1, 'experimental-debug') merged-usr: no Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.18.0-4-amd64 (SMP w/8 CPU threads; PREEMPT) 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#1017901: Ships autogenerated files that can't be renegerated with the code in Debian main
Source: gudev-sharp-3.0 Version: 3.0.0-1 Severity: serious Tags: upstream See the discussion on the Debian Rust maintainers list for background: https://alioth-lists.debian.net/pipermail/pkg-rust-maintainers/2022-August/022857.html While that discussion is about Rust packages that were rejected, the same situation also applies to gtk-sharp2 unfortunately. For more details how to solve this in a way that makes ftp-masters happy, please refer to them. Affected file is gudev/gudev-api.raw. This file was autogenerated from specific versions of the underlying C libraries and it's not clear which versions were used. Debian ships these C libraries but certainly in different versions so it's not possible to regenerate these files with what is available in Debian. It will be necessary to either include the source code of the C libraries in the exact version, or regenerate the files at build time with whatever is available in Debian. The latter will probably generate different bindings, potentially even with different API, so is probably not a useful solution. -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (700, 'unstable'), (500, 'unstable-debug'), (100, 'experimental'), (1, 'experimental-debug') merged-usr: no Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.18.0-4-amd64 (SMP w/8 CPU threads; PREEMPT) 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#1017898: Ships autogenerated files that can't be renegerated with the code in Debian main
Source: appindicator3-sharp Version: 12.10.0+git20151221-5.1 Severity: serious Tags: upstream See the discussion on the Debian Rust maintainers list for background: https://alioth-lists.debian.net/pipermail/pkg-rust-maintainers/2022-August/022857.html While that discussion is about Rust packages that were rejected, the same situation also applies to appindicator3-sharp unfortunately. For more details how to solve this in a way that makes ftp-masters happy, please refer to them. Affected file is sources/appindicator3-sharp-api.raw. This file were autogenerated from specific versions of the underlying C libraries and it's not clear which versions were used. Debian ships these C libraries but certainly in different versions so it's not possible to regenerate these files with what is available in Debian. It will be necessary to either include the source code of the C libraries in the exact version, or regenerate the files at build time with whatever is available in Debian. The latter will probably generate different bindings, potentially even with different API, so is probably not a useful solution. -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (700, 'unstable'), (500, 'unstable-debug'), (100, 'experimental'), (1, 'experimental-debug') merged-usr: no Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.18.0-4-amd64 (SMP w/8 CPU threads; PREEMPT) 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#1017900: Ships autogenerated files that can't be renegerated with the code in Debian main
Source: gudev-sharp-1.0 Version: 0.1-4.1 Severity: serious Tags: upstream See the discussion on the Debian Rust maintainers list for background: https://alioth-lists.debian.net/pipermail/pkg-rust-maintainers/2022-August/022857.html While that discussion is about Rust packages that were rejected, the same situation also applies to gtk-sharp2 unfortunately. For more details how to solve this in a way that makes ftp-masters happy, please refer to them. Affected file is gudec/gudev-api.raw. This file were autogenerated from specific versions of the underlying C libraries and it's not clear which versions were used. Debian ships these C libraries but certainly in different versions so it's not possible to regenerate these files with what is available in Debian. It will be necessary to either include the source code of the C libraries in the exact version, or regenerate the files at build time with whatever is available in Debian. The latter will probably generate different bindings, potentially even with different API, so is probably not a useful solution. -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (700, 'unstable'), (500, 'unstable-debug'), (100, 'experimental'), (1, 'experimental-debug') merged-usr: no Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.18.0-4-amd64 (SMP w/8 CPU threads; PREEMPT) 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#1017897: Ships autogenerated files that can't be renegerated with the code in Debian main
Source: gtk-sharp3 Version: 2.99.3-4 Severity: serious Tags: upstream See the discussion on the Debian Rust maintainers list for background: https://alioth-lists.debian.net/pipermail/pkg-rust-maintainers/2022-August/022857.html While that discussion is about Rust packages that were rejected, the same situation also applies to gtk-sharp3 unfortunately. For more details how to solve this in a way that makes ftp-masters happy, please refer to them. Affected files are atk/atk-api.raw, gtk/gtk-api.raw and the other */*-api.raw files. These files were autogenerated from specific versions of the underlying C libraries and it's not clear which versions were used. Debian ships these C libraries but certainly in different versions so it's not possible to regenerate these files with what is available in Debian. It will be necessary to either include the source code of the C libraries in the exact version, or regenerate the files at build time with whatever is available in Debian. The latter will probably generate different bindings, potentially even with different API, so is probably not a useful solution. -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (700, 'unstable'), (500, 'unstable-debug'), (100, 'experimental'), (1, 'experimental-debug') merged-usr: no Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.18.0-4-amd64 (SMP w/8 CPU threads; PREEMPT) 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#1017896: Ships copies of libraries that are packaged in Debian
Package: firefox-esr Version: 102.1.0esr-2 Severity: serious Hi, The firefox source package currently ships various libraries that are packaged in Debian, but at build time the local copies are used instead. The package build process should use the versions packaged in Debian. Examples of these are basically everything in the third_party directory, specifically the ones I'm aware of and why I'm reporting this here are the ones in third_party/rust. - third_party/rust/semver corresponds to the rust-semver package in Debian. - third_party/rust/time corresponds to the rust-time package in Debian. - third_party/rust/nom corresponds to the rust-nom package in Debian. These are just examples, basically everything in the directory is affected. In addition all the libraries that currently are not packaged in Debian should ideally be packaged in Debian instead of using some arbitrary version that is bundled with firefox. Note that various of these libraries had CVEs in the past, e.g. CVE-2022-24713 for third_party/rust/regex, so having various copies of them in different source packages is clearly not ideal. -- Package-specific info: -- Extensions information Name: DoH Roll-Out Location: /usr/lib/firefox-esr/browser/features/doh-roll...@mozilla.org.xpi Package: firefox-esr Status: enabled Name: English (GB) Language Pack locale Location: /usr/lib/firefox-esr/browser/extensions/langpack-en...@firefox-esr.mozilla.org.xpi Package: firefox-esr-l10n-en-gb Status: enabled Name: Firefox Screenshots Location: /usr/lib/firefox-esr/browser/features/screensh...@mozilla.org.xpi Package: firefox-esr Status: enabled Name: Form Autofill Location: /usr/lib/firefox-esr/browser/features/formautof...@mozilla.org.xpi Package: firefox-esr Status: enabled Name: HTTPS Everywhere Location: /usr/share/webext/https-everywhere Package: webext-https-everywhere Status: enabled Name: Picture-In-Picture Location: /usr/lib/firefox-esr/browser/features/pictureinpict...@mozilla.org.xpi Package: firefox-esr Status: enabled Name: uBlock Origin Location: /usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/ublo...@raymondhill.net Package: webext-ublock-origin-firefox Status: enabled Name: Web Compatibility Interventions Location: /usr/lib/firefox-esr/browser/features/webcom...@mozilla.org.xpi Package: firefox-esr Status: enabled Name: WebCompat Reporter Location: /usr/lib/firefox-esr/browser/features/webcompat-repor...@mozilla.org.xpi Package: firefox-esr Status: user-disabled -- Addons package information ii firefox-esr 102.1.0esr-2 amd64Mozilla Firefox web browser - Extended Support Release (ESR) ii firefox-esr-l10n-en-gb 102.1.0esr-2 all English (United Kingdom) language package for Firefox ESR ii webext-https-everywhere 2022.5.11-1 all Extension to force the use of HTTPS on many sites ii webext-ublock-origin-firefox 1.42.0+dfsg-1 all lightweight and efficient ads, malware, trackers blocker (Firefox) -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (700, 'unstable'), (500, 'unstable-debug'), (100, 'experimental'), (1, 'experimental-debug') merged-usr: no Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.18.0-4-amd64 (SMP w/8 CPU threads; PREEMPT) 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 Versions of packages firefox-esr depends on: ii debianutils 5.7-0.3 ii fontconfig 2.13.1-4.4 ii libasound2 1.2.7.2-1 ii libatk1.0-0 2.38.0-1 ii libc62.34-4 ii libcairo-gobject21.16.0-6 ii libcairo21.16.0-6 ii libdbus-1-3 1.14.0-2 ii libdbus-glib-1-2 0.112-2 ii libevent-2.1-7 2.1.12-stable-5+b1 ii libffi8 3.4.2-4 ii libfontconfig1 2.13.1-4.4 ii libfreetype6 2.12.1+dfsg-3 ii libgcc-s112.1.0-8 ii libgdk-pixbuf-2.0-0 2.42.9+dfsg-1 ii libglib2.0-0 2.72.3-1+b1 ii libgtk-3-0 3.24.34-1 ii libnspr4 2:4.34-1 ii libnss3 2:3.81-2 ii libpango-1.0-0 1.50.9+ds-1 ii libstdc++6 12.1.0-8 ii libvpx7 1.12.0-1 ii libx11-6 2:1.8.1-2 ii libx11-xcb1 2:1.8.1-2 ii libxcb-shm0 1.15-1 ii libxcb1 1.15-1 ii libxcomposite1 1:0.4.5-1 ii libxdamage1 1:1.1.5-2 ii libxext6 2:1.3.4-1 ii libxfixes3 1:6.0.0-1 ii libxrandr2 2:1.5.2-2+b1 ii libxtst6 2:1.2.3-1.1 ii procps 2:3.3.17-7+b1 ii zlib1g 1:1.2.11.dfsg-4.1 Versions of packages firefox-esr recommends: ii libavcodec57 7:3.4.3-1 ii libavcodec58 7:4.4.2-1+b3 ii libavcodec59 7:5.1-2+b1 Versions of packages firefox-esr suggests: ii fonts-lmodern 2.005-1 pn fon
Bug#1017895: Ships copies of libraries that are packaged in Debian
Package: firefox Version: 103.0.2-2 Severity: serious Hi, The firefox source package currently ships various libraries that are packaged in Debian, but at build time the local copies are used instead. The package build process should use the versions packaged in Debian. Examples of these are basically everything in the third_party directory, specifically the ones I'm aware of and why I'm reporting this here are the ones in third_party/rust. - third_party/rust/semver corresponds to the rust-semver package in Debian. - third_party/rust/time corresponds to the rust-time package in Debian. - third_party/rust/time-0.1.44 corresponds to the rust-time-0.1 package in Debian. - third_party/rust/nom corresponds to the rust-nom package in Debian. - third_party/rust/nom-6.1.2 corresponds to the rust-nom package in Debian too but currently no nom-6 version is packaged. These are just examples, basically everything in the directory is affected. In addition all the libraries that currently are not packaged in Debian should ideally be packaged in Debian instead of using some arbitrary version that is bundled with firefox. Note that various of these libraries had CVEs in the past, e.g. CVE-2022-24713 for third_party/rust/regex, so having various copies of them in different source packages is clearly not ideal. -- Package-specific info: -- Extensions information Name: Add-ons Search Detection Location: /usr/lib/firefox/browser/omni.ja Package: firefox Status: enabled Name: Amazon.com Location: /usr/lib/firefox/browser/omni.ja Package: firefox Status: enabled Name: Bing Location: /usr/lib/firefox/browser/omni.ja Package: firefox Status: enabled Name: Dark theme Location: /usr/lib/firefox/browser/omni.ja Package: firefox Status: user-disabled Name: DoH Roll-Out Location: /usr/lib/firefox/browser/features/doh-roll...@mozilla.org.xpi Package: firefox Status: enabled Name: DuckDuckGo Location: /usr/lib/firefox/browser/omni.ja Package: firefox Status: enabled Name: eBay Location: /usr/lib/firefox/browser/omni.ja Package: firefox Status: enabled Name: Firefox Alpenglow theme Location: /usr/lib/firefox/browser/omni.ja Package: firefox Status: user-disabled Name: Firefox Multi-Account Containers Location: ${PROFILE_EXTENSIONS}/@testpilot-containers.xpi Status: enabled Name: Firefox Screenshots Location: /usr/lib/firefox/browser/features/screensh...@mozilla.org.xpi Package: firefox Status: enabled Name: Form Autofill Location: /usr/lib/firefox/browser/features/formautof...@mozilla.org.xpi Package: firefox Status: enabled Name: GNOME Shell integration Location: ${PROFILE_EXTENSIONS}/chrome-gnome-sh...@gnome.org.xpi Status: enabled Name: Google Location: /usr/lib/firefox/browser/omni.ja Package: firefox Status: enabled Name: HTTPS Everywhere Location: ${PROFILE_EXTENSIONS}/https-everywhere-...@eff.org.xpi Status: enabled Name: Light theme Location: /usr/lib/firefox/browser/omni.ja Package: firefox Status: enabled Name: No Flash Location: ${PROFILE_EXTENSIONS}/jid1-cplltty501t...@jetpack.xpi Status: app-disabled Name: Picture-In-Picture Location: /usr/lib/firefox/browser/features/pictureinpict...@mozilla.org.xpi Package: firefox Status: enabled Name: Privacy Badger Location: ${PROFILE_EXTENSIONS}/jid1-mnnxcxisbpnsxq-...@jetpack.xpi Status: user-disabled Name: System theme — auto theme Location: /usr/lib/firefox/omni.ja Package: firefox Status: user-disabled Name: uBlock Origin Location: ${PROFILE_EXTENSIONS}/ublo...@raymondhill.net.xpi Status: enabled Name: Video DownloadHelper Location: ${PROFILE_EXTENSIONS}/{b9db16a4-6edc-47ec-a1f4-b86292ed211d}.xpi Status: enabled Name: Web Compatibility Interventions Location: /usr/lib/firefox/browser/features/webcom...@mozilla.org.xpi Package: firefox Status: enabled Name: WebCompat Reporter Location: /usr/lib/firefox/browser/features/webcompat-repor...@mozilla.org.xpi Package: firefox Status: user-disabled Name: Wikipedia (en) Location: /usr/lib/firefox/browser/omni.ja Package: firefox Status: enabled Name: Yomichan Location: ${PROFILE_EXTENSIONS}/a...@foosoft.net.xpi Status: enabled -- Addons package information ii firefox103.0.2-2amd64Mozilla Firefox web browser -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (700, 'unstable'), (500, 'unstable-debug'), (100, 'experimental'), (1, 'experimental-debug') merged-usr: no Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.18.0-4-amd64 (SMP w/8 CPU threads; PREEMPT) 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 Versions of packages firefox depends on: ii debianutils 5.7-0.3 ii fontconfig 2.13.1-4.4 ii libasound2 1.2.7.2-1 ii libatk1.0-0 2.38.0-1 ii libc62.34-4 ii libcairo-gobject21.16.0-6 ii libcairo21.16.0-6
Bug#1017893: Ships autogenerated files that can't be renegerated with the code in Debian main
Source: gtk-sharp2 Version: 2.12.40-3 Severity: serious Tags: upstream See the discussion on the Debian Rust maintainers list for background: https://alioth-lists.debian.net/pipermail/pkg-rust-maintainers/2022-August/022857.html While that discussion is about Rust packages that were rejected, the same situation also applies to gtk-sharp2 unfortunately. For more details how to solve this in a way that makes ftp-masters happy, please refer to them. Affected files are atk/atk-api.raw, gtk/gtk-api.raw and the other */*-api.raw files. These files were autogenerated from specific versions of the underlying C libraries and it's not clear which versions were used. Debian ships these C libraries but certainly in different versions so it's not possible to regenerate these files with what is available in Debian. It will be necessary to either include the source code of the C libraries in the exact version, or regenerate the files at build time with whatever is available in Debian. The latter will probably generate different bindings, potentially even with different API, so is probably not a useful solution. -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (700, 'unstable'), (500, 'unstable-debug'), (100, 'experimental'), (1, 'experimental-debug') merged-usr: no Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.18.0-4-amd64 (SMP w/8 CPU threads; PREEMPT) 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#1017892: Ships copies of libraries that are in Debian and autogenerated files that can't be renegerated with the code in Debian main
Source: librsvg Version: 2.54.4+dfsg-1 Severity: serious Tags: upstream Hi, See the discussion on the Debian Rust maintainers list for background: https://alioth-lists.debian.net/pipermail/pkg-rust-maintainers/2022-August/022857.html For more details how to solve this in a way that makes ftp-masters happy, please refer to them. The vendor subdirectory in the librsvg source package contains copies of various Rust libraries in specific versions. Some of them are packaged in Debian (i.e. the version from Debian should be used), others contain autogenerated files for which the original source is not in Debian. Examples for this are - vendor/semver corresponds to the rust-semver package in Debian. Here version 1.0.10 is included while Debian currently only has version 1.0.4. Both versions should be API compatible so that's not necessarily a problem for switching to the Debian version. - vendor/memchr corresponds to the rust-memchr package in Debian. Currently these two have the same version. - vendor/png corresponds to the rust-png package in Debian. Here version 0.17.5 is included while Debian currently only has version 0.16.8. Both versions are not API compatible. - vendor/glib-sys corresponds to the rust-glib-sys package in Debian. Here version 0.15.10 is included while Debian currently only has version 0.14.0. Both versions are not API compatible at all. In addition the src/lib.rs in that subdirectory has exactly the same problem mentioned in the above discussion. It is autogenerated from GLib-2.0.gir by the gir tool, and GLib-2.0.gir is autogenerated from the GLib (glib2.0 source package) source code. Either the original source in the exact version used here and everything to generate the files has to be shipped with the source package, or the files have to be regenerated at build time with whatever is available in Debian. See the above discussion for more details. These are not all files affected. You'll have to check the whole content of the vendor subdirectory on every release and ideally make sure each of these are packaged in Debian in the correct version. -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (700, 'unstable'), (500, 'unstable-debug'), (100, 'experimental'), (1, 'experimental-debug') merged-usr: no Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.18.0-4-amd64 (SMP w/8 CPU threads; PREEMPT) 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#1017891: Ships autogenerated files that can't be renegerated with the code in Debian main
Source: vala Version: 0.56.2-1 Severity: serious Tags: upstream Hi, See the discussion on the Debian Rust maintainers list for background: https://alioth-lists.debian.net/pipermail/pkg-rust-maintainers/2022-August/022857.html While that discussion is about Rust packages that were rejected, the same situation also applies to Vala unfortunately. For more details how to solve this in a way that makes ftp-masters happy, please refer to them. The whole vapi subdirectory of the source package currently contains autogenerated files for which the original source is not available in Debian. Some examples for this are - gstreamer-audio-1.0.vapi: This was generated from the gir file of the corresponding library. While the library does exist in Debian and also the gir file (libgstreamer-plugins-base1.0-dev), the same version does not exist and regenerating it from the version in Debian will introduce changes due to being older. As of 0.56.2 the file was generated from an unspecified git snapshot after the last GStreamer release, see https://gitlab.gnome.org/GNOME/vala/-/commit/6d80e07996834ace2a8d0f994913bc9cc623ec9b - gnet-2.0.vapi: The corresponding library does not even exist in Debian. This is not a full list. You'll have to check one by one for all of these autogenerated files and provide the original source in the correct version, or ideally regenerate the files based on the source code in Debian on every build. >From my understanding, regenerating the files with whatever version is available in Debian at build time is not an option if you don't want to lose upstream support for any vapi-related bugs. These files are also included in binary packages. -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (700, 'unstable'), (500, 'unstable-debug'), (100, 'experimental'), (1, 'experimental-debug') merged-usr: no Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.18.0-4-amd64 (SMP w/8 CPU threads; PREEMPT) 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#1017890: Ships autogenerated files that can't be renegerated with the code in Debian main
Package: gobject-introspection Version: 1.72.0-1+b1 Severity: serious Tags: upstream Hi, See the discussion on the Debian Rust maintainers list for background: https://alioth-lists.debian.net/pipermail/pkg-rust-maintainers/2022-August/022857.html While that discussion is about Rust packages that were rejected, the same situation also applies to gobject-introspection unfortunately. For more details how to solve this in a way that makes ftp-masters happy, please refer to them. gobject-introspection ships gir/glib-2.0.c, gir/gio-2.0.c, gir/gmodule-2.0.c and gir/gobject-2.0.c. These files are autogenerated from a specific version of the GLib source code via the misc/update-glib-annotations.py script. The version that was used in 1.72.0 happens to be GLib 2.72.0 which is not in the archive anymore if you check https://deb.debian.org/debian/pool/main/g/glib2.0/ In this case there are probably no differences if you regenerate the files from glib 2.72.3 but in other releases the situation is a bit more complicated, and various gobject-introspection releases shipped with generated files from some random git snapshot of glib. Ideally these files would be regenerated during each build with whatever version is currently available in Debian, however this might be discouraged by upstream as it's not clear anymore then what the exact files are that are being used in a specific Debian release compared to the upstream release. Alternatively the original source, i.e. glib in the exact version used for the files, could be included in the source package. Note that these files are used to generate the GLib-2.0.gir, Gio-2.0.gir, GModule-2.0.gir and GObject-2.0.gir files that are also shipped in the binary packages. -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (700, 'unstable'), (500, 'unstable-debug'), (100, 'experimental'), (1, 'experimental-debug') merged-usr: no Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.18.0-4-amd64 (SMP w/8 CPU threads; PREEMPT) 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 Versions of packages gobject-introspection depends on: ii build-essential 12.9 ii libc6 2.34-4 ii libdpkg-perl1.21.9 ii libffi8 3.4.2-4 ii libgirepository-1.0-1 [libgirepository-1.0-1-with-libffi8] 1.72.0-1+b1 ii libglib2.0-02.72.3-1+b1 ii python3 3.10.6-1 ii python3-distutils 3.10.6-1 ii python3-mako1.1.3+ds1-3 ii python3-markdown3.4.1-1 gobject-introspection recommends no packages. gobject-introspection suggests no packages. -- no debconf information
Bug#1005120: wpewebkit: Fails to build with gstreamer 1.20
On Tue, 2022-02-08 at 18:10 +0100, Alberto Garcia wrote: > On Mon, Feb 07, 2022 at 10:53:56AM -0500, Jeremy Bicha wrote: > > wpewebkit fails to build from source, apparently because of the recent > > gstreamer 1.20 uploads. > > > > -- Checking for module 'gstreamer-codecparsers-1.0 >= 1.14.0' > > -- No package 'gstreamer-codecparsers-1.0' found > > > > That .pc file is provided by libgstreamer-plugins-bad1.0-dev so > > maybe you just need to Build-Depend on that. > > As far as I'm aware gstreamer-codecparsers-1.0 is not needed in the > default build, the problem that I'm seeing here is this one: > > CMake Error at Source/cmake/GStreamerChecks.cmake:50 (message): > GStreamerGL is needed for USE_GSTREAMER_GL. > > GStreamerGL is however installed. The reason why this fails is this > one: > > # pkg-config --cflags gstreamer-gl-1.0 > Package gudev-1.0 was not found in the pkg-config search path. > Perhaps you should add the directory containing `gudev-1.0.pc' > > So I understand that libgstreamer-plugins-base1.0-dev would need to > depend on libgudev-1.0-dev, right Sebastian? Indeed, needs a libgudev-1.0-dev (>= 147) [linux-any] . I've added gbm and all the other new ones but apparently missed that one. I'll upload a new version later or tomorrow morning. signature.asc Description: This is a digitally signed message part
Bug#1004438: reportbug: gstreamer1.0-plugins-bad 1.18.5-1+b4 has an invalid dependency on a contrib package
On Thu, 27 Jan 2022 18:31:37 +0100 Francois Gouget wrote: > > > gstreamer1.0-plugins-bad is part of the main archive area. However in > Debian Testing's version 1.18.5-1+b4 it depends on > libgstreamer-gl1.0-0 which is now in the contrib archive area. > > This is a violation of section 2.2.1 of the Policy which states that: > > None of the packages in the main archive area require software > outside of that area to function. > > So to fix this one of the following should be done: > * Demote this dependency to a 'Suggest', assuming the package is still > usable without it. > * Remove the dependency entirely with the same caveat. > * Or libgstreamer-gl1.0-0 should be moved back to the main archive area. libgstreamer-gl1.0-0 does not seem to be in contrib unless I'm missing something. Why do you think it is in contrib? signature.asc Description: This is a digitally signed message part
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#985358: pitivi: A/V out of sync in rendered videos
On Tue, 2021-03-16 at 13:39 -0300, Antonio Terceiro wrote: As a user, I don't even know about all the stuff that could be better; pitivi worked ok for me as an amateur video editor. It just failed at the end of the process, rendering the video. So from my PoV, the version in bullseye is fine once this is fixed. Of course the latest and greatest if always better, but that's incompatible with a stable release. We just have to cut it at some point. While that's true, in this case I'm mostly concerned about all the bugfixes that happened in the meantime. In any case, would you be interested in helping maintaining this package? I don't have much time for that these days. signature.asc Description: This is a digitally signed message part
Bug#985358: pitivi: A/V out of sync in rendered videos
On Tue, 2021-03-16 at 11:16 -0300, Antonio Terceiro wrote: Dear Maintainer, The version of pitivi in bullseye is affected by the bug listed above: rendered videos have A/V out of sync by a few seconds, while they sound just find in the preview. I'm attaching the upstream patch that fixed the issue, already backported to the current Debian package. I rebuilt pitivi locally with this patch, and confirmed that it does fix the issue. Yeah I'm aware of this and various other issues in the version currently in Debian, and which are fixed in the latest releases. Due to Debian release freeze policies the latest release is not uploaded yet and I don't know how useful it is to just patch some of the issues. In the end what we'd really want is the latest release. signature.asc Description: This is a digitally signed message part
Bug#981203: gstreamer1.0: annotate Build-Depends
On Wed, 27 Jan 2021 17:15:06 +0100 Helmut Grohne wrote: > gstreamer1.0 participates in dependency loops relevant to architecture > bootstrap. Rather than work on such a difficult problem, I looked into > easily droppable dependencies. It turns out that the libgmp-dev and > libgsl-dev dependencies are optional and unnecessary when building > without tests as happens when passing nocheck via DEB_BUILD_OPTIONS. As > such, these dependencies can be annotated . Please consider > applying the attached patch. Thanks, I've applied this to git and it will be part of the next upload: https://salsa.debian.org/gstreamer-team/gstreamer1.0/-/commit/daf98ff1fcfed98562e70af14888bf477eaa3fdb Let me know if this becomes urgent at some point and I'll upload it directly. signature.asc Description: This is a digitally signed message part
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#971754: ABI breakage from 1.4.1 to 1.4.2
On Sat, 2021-01-16 at 14:05 +0100, Paul Gevers wrote: > > I was expecting a new upstream release to be incorporated, but I > understand upstream didn't release anything new yet. For whatever > it's worth, your MR doesn't look too weird. Thanks, I've uploaded it to delayed/1 in case someone disagrees. Otherwise it'll be on the NEW queue tomorrow for the new binary packages, and once it's done there a binNMU for gst-plugins-bad1.0 can happen and everything can migrate to testing. signature.asc Description: This is a digitally signed message part
Bug#971754: ABI breakage from 1.4.1 to 1.4.2
Hi Paul, On Fri, 2021-01-15 at 22:37 +0100, Paul Gevers wrote: > > Can you do this please? srt is orphaned, your package depend on it, > could you please help us get us out of this situation? (if this > happens soon, we'll accept the transition to fix this). I've created a MR in salsa for this change: https://salsa.debian.org/debian/libsrt/-/merge_requests/2 If that looks acceptable and correct to you then I'll upload it. signature.asc Description: This is a digitally signed message part
Bug#971754: ABI breakage from 1.4.1 to 1.4.2
On Fri, 2021-01-15 at 22:37 +0100, Paul Gevers wrote: > Hi Sebastian, > > On Thu, 14 Jan 2021 11:39:24 +0200 Sebastian =?ISO-8859-1?Q?Dr=F6ge?= > wrote: > > Upstream fixed this now by making the soversion 1.4 and from now on > > guaranteeing that patch versions (1.4.0 -> 1.4.X) do not break ABI. > > > > It would make sense to backport that fix and then rename the > > library package accordingly to libsrt1.4. > > > > For gst-plugins-bad1.0 only a binNMU would be needed once this is > > all > > sorted out here. > > Can you do this please? srt is orphaned, your package depend on it, > could you please help us get us out of this situation? (if this > happens soon, we'll accept the transition to fix this). I'll try to have some time for that this weekend. signature.asc Description: This is a digitally signed message part
Bug#971754: ABI breakage from 1.4.1 to 1.4.2
On Wed, 13 Jan 2021 17:42:27 +0100 Andreas Beckmann wrote: > Control: tag -1 patch > > Hi, > > On Thu, 7 Jan 2021 20:52:39 +0100 Paul Gevers wrote: > > On Tue, 06 Oct 2020 16:38:49 +0300 =?utf-8?q?Sebastian_Dr=C3=B6ge?= > > wrote: > > > 1.4.2 broke ABI by adding some fields to the CBytePerfMon structure. > > > See https://github.com/Haivision/srt/issues/1592 for details. > > > > Any progress on this? The freeze for bullseye is around the corner, and > > this bug is already impacting other packages that fail to migrate to > > testing due to srt not migrating. > > given the freeze timing and uncertain date for an upstream fix, I'd > suggest the attached patch: > * bump SOVERSION from 1 to 1.4.2 (that won't conflict with whatever > upstream chooses to solve this in the upcoming 1.4.3 release, be it > SOVERSION 1.4 or 1.4.3) > * rename the packages accordingly > > That will require a late transition involving only 1 package: > gst-plugins-bad1.0 Upstream fixed this now by making the soversion 1.4 and from now on guaranteeing that patch versions (1.4.0 -> 1.4.X) do not break ABI. It would make sense to backport that fix and then rename the library package accordingly to libsrt1.4. For gst-plugins-bad1.0 only a binNMU would be needed once this is all sorted out here. signature.asc Description: This is a digitally signed message part
Bug#978564: src:gst-plugins-bad1.0: fails to migrate to testing for too long: dependency is not migrating
On Tue, 5 Jan 2021 19:09:04 +0100 Paul Gevers wrote: > > > This is solely blocked on srt currently, and the maintainer will have > > to figure out a solution there for the ABI breakage. > > Ack. Although, you *could* help them find a solution. RC bugs in key > packages are a shared responsibility in my opinion. I looked through the users of the library and none of them currently rely on the broken ABI and it doesn't look like upstream cares about ABI stability much so I see 3 options here * migrate the current version to testing and consider it a non-bug and hope it never happens again * the above plus also updating the package so dependencies would always depend on >= upstream_version && < next_upstream_version * don't include the package in Debian because upstream doesn't care about ABI stability That seems like something for the maintainer to figure out IMHO but they didn't even respond to #971754 yet. > > I could upload a version of gst-plugins-bad1.0 without the SRT plugin > > for the time being so it can migrate in the meantime. > > I suggested to upload the current version to tpu. I'll unblock it if no > further changes to what is currently in unstable and if it happens > within a week or two. Doing so now, thanks. There's going to be another GStreamer bugfix release beginning of next week, which I'll be uploading after this has migrated to then. signature.asc Description: This is a digitally signed message part
Bug#978564: src:gst-plugins-bad1.0: fails to migrate to testing for too long: dependency is not migrating
On Mon, 28 Dec 2020 18:40:38 +0100 Paul Gevers wrote: > > If you believe your package is unable to migrate to testing due to > issues beyond your control, don't hesitate to contact the Release Team. > In this case, I think it may be wise to upload to > testing-proposed-updates and ask for an unblock. Otherwise your two bug > fix releases may not make it to bullseye. Hi Paul, This is solely blocked on srt currently, and the maintainer will have to figure out a solution there for the ABI breakage. I could upload a version of gst-plugins-bad1.0 without the SRT plugin for the time being so it can migrate in the meantime. If I do that and srt gets fixed before the bullseye release, will I be able to upload a new gst-plugins-bad1.0 version that re-enables the SRT plugin and have it migrated? Thanks, Sebastian
Bug#978643: Please build with fdk-aac support
On Tue, 29 Dec 2020 18:23:34 +0100 Andreas Metzler wrote: > On 2020-12-29 Laurent Bigonville wrote: > [...] > > The problem is that they are using elements that requires fdk-aac and > > faac and these are currently packaged as non-free in debian. > [...] > > What would be the plan to have fdkaac and faac elements enabled? We > > would have to add a new package that would go in contrib I guess? Would > > that be acceptable? > > > afaict we would need to add a new *source* package in contrib since a > source package in main (gst-plugins-bad1.0) cannot build-depend on > packages outside main. Yes that would need a new source package. I'd be happy to have that as part of the packages on https://salsa.debian.org/gstreamer-team and take care of updating that together with new GStreamer releases if someone (Laurent?) wants to prepare an initial package. It's a bit suboptimal that pulseaudio requires fdk. I wonder if this can also be made to work with the ffmpeg AAC encoder or if that doesn't support LATM/LOAS yet. FWIW, pulseaudio will need these changes here: https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1793 They're not merged upstream yet and won't be before 1.19 so would have to be included as a patch for now.
Bug#971754: ABI breakage from 1.4.1 to 1.4.2
Source: srt Version: 1.4.2-1 Severity: serious Tags: upstream 1.4.2 broke ABI by adding some fields to the CBytePerfMon structure. See https://github.com/Haivision/srt/issues/1592 for details. There were also other ABI breakages in previous versions that are not reflected by the binary package name of the library. -- 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.8.0-2-amd64 (SMP w/8 CPU threads) Kernel taint flags: 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#971741: pitivi should depend on libgstreamer-plugins-bad1.0-dev
On Tue, 2020-10-06 at 10:58 +0200, Richard B. Kreckel wrote: > > Pitivi reports "Could not import 'GstTranscoder'. Make sure you have it > available." and exits immediately unless package > gir1.2-gst-plugins-bad-1.0 is isntalled. Thanks, I'll include this in the next upload soonish. There are a few other things to fix too.
Bug#965007: pitivi: ships a copy of gstreamer libraries
On Wed, 2020-09-23 at 09:36 +0200, Gianfranco Costamagna wrote: > > Hello, I found that pitivi was using the gst-transcoder only if not found on > the system, > and upstream commit "51ae6533ee26ffd47e453eb5f5ad8cd46f57d15e" worked in > fixing that. > > I prepared a version on Debomatic with that change, and it stopped installing > the binary/pkgconfig/libraries. > > http://debomatic-amd64.debian.net/distribution#unstable/pitivi/0.999-3/buildlog > > > I would like to upload to sid, but unfortunately gst-plugins-bad1.0 conflicts > with pitivi << 0., so it won't fix the uninstallability... > > Sebastian, how do you feel about relaxing that one? > > I'm attaching a diff here (I'll change also VCS fields, and fix some lintian > sandess here and there) Thanks for the diff. Upstream is planning to do a release any day now, so I'd prefer waiting for that instead but if you have any other changes to the packaging I'd be happy to integrate them :) You can also send them as MR to https://salsa.debian.org/gstreamer-team/pitivi
Bug#893813: closed by Debian FTP Masters (reply to Sebastian Dröge ) (Bug#893813: fixed in gst-plugins-bad1.0 1.18.0-1)
On Tue, 2020-09-08 at 13:03 +, Thorsten Glaser wrote: > Debian Bug Tracking System dixit: > > >This is an automatic notification regarding your Bug report > >which was filed against the src:gst-plugins-bad1.0 package: > > > >#893813: gst-plugins-bad1.0: FTBFS on x32: wrongly uses amd64 assembly > > This unfortunately doesn’t seem to be complete, 1.18.0-1 FTBFS with: > > > […] > dh_install -pgstreamer1.0-plugins-bad > debian/tmp/usr/lib/x86_64-linux-gnux32/gstreamer-1.0/libgstresindvd.so > mkdir -p /<>/fake-home > HOME=/<>/fake-home \ > LD_LIBRARY_PATH=debian/libgstreamer-plugins-bad1.0-0/usr/lib/x86_64-linux-gnux32:debian/libgstreamer-opencv1.0-0/usr/lib/x86_64-linux-gnux32:/usr/lib/x86_64-linux-gnux32/libfakeroot:/usr/lib64/libfakeroot:/usr/lib32/libfakeroot > \ > dh_gstscancodecs > > ERROR: Caught a segmentation fault while loading plugin file: > debian/gstreamer1.0-plugins-bad/usr/lib/x86_64-linux-gnux32/gstreamer-1.0/libgstsrtp.so That's a different problem though. I saw that one before on another platform (Raspberry Pi IIRC). There it was something broken in libsrtp2-1. You can probably confirm that by running gst-inspect-1.0 debian/gstreamer1.0-plugins-bad/usr/lib/x86_64-linux-gnux32/gstreamer-1.0/libgstsrtp.so in gdb on that machine and getting a backtrace of the crash.
Bug#880401: gstreamer1.0-plugins-bad: Enabling experimental-agc of the webrtcdsp element makes it fail with "Illegal instruction" on ARM
reassign 880401 webrtc-audio-processing thanks On Tue, 31 Oct 2017 10:36:29 +0200 Martin Laakso <16...@notsharingmy.info> wrote: > The title says it all. This bug is not present in the amd64 binaries. > > It's probably worth mentioning that the CPU is a Broadcom BCM2835, in case > this is CPU-specific. > > The same happened with GStreamer 1.10.4, which is why I tried upgrading to > the testing version. There's no custom assembly or otherwise problematic code in the GStreamer plugin, all the heavy lifting is done by webrtc-audio- processing. Reassigning there.
Bug#881398: gstreamer1.0-x: Unable to play anything with Parole, Totem, etc.
On Sat, 11 Nov 2017 11:09:20 +0100 jEsuSdA wrote: > > I've just reinstall my PC and it was unable to play anything with Parole WITH > ANY USER BUT ROOT. Is this still a problem? If so, can you provide some more information about how it fails? A GStreamer debug log would also be useful to have. You can get one by setting GST_DEBUG=6 before running the application, and redirecting stderr to a file.
Bug#870373: gstreamer1.0-plugins-base: "Could not decode stream" while trying to play Ogg Vorbis file
On Tue, 01 Aug 2017 15:29:13 +0200 Jonathan Ballet wrote: > > None of my music players using GStreamer are able to play Ogg Vorbis > music files since a couple of months. Is this still a problem? If so, can you provide such an Ogg Vorbis file? It fails to read the file in question here, but all of mine are working fine.
Bug#890472: Status for Vulkan development tools?
On Mon, 13 Jul 2020 09:57:25 -0600 John Zupin wrote: > > Brett is no longer with LunarG and I'll be making updates to his ITP bug > submissions about the status of these packages. > > The current status for the shaderc package is that it has been out for > 1+ years now and is hosted by LunarG. > > I am LunarG's curator for these packages, please check > https://vulkan.lunarg.com/sdk/home under the "ubuntu packages" tab for > more information about our repository. Would you consider maintaining them in Debian? That way people don't have to get them from some random other place but directly from their main package repository, and it would also appear in Ubuntu. shaderc is at this point required for GTK4's and GStreamer's Vulkan support, so not having it in the package repository is starting to become a problem.
Bug#965007: pitivi: ships a copy of gstreamer libraries
On Mon, 2020-08-17 at 09:10 -0300, Antonio Terceiro wrote: > > This file is already present in pitivi on stable, and > gstreamer1.0-plugins-bad-apps is only present in experimental. testing > and unstable are unaffected by this, or testing would be unaffected if > this hadn't caused pitivi to be removed. > > I'm reassigning to gstreamer1.0-plugins-bad-apps. It's a bug in pitivi. It should've never shipped these files outside its private library directory. It will be fixed once there's a new pitivi release, which I'm waiting for currently. Please reassign this back to pitivi, thanks. signature.asc Description: This is a digitally signed message part
Bug#963307: gstreamer1.0: FTBFS:
On Sun, 21 Jun 2020 21:53:15 +0200 Lucas Nussbaum wrote: > > > During a rebuild of all packages in sid, your package failed to build > on amd64. > [...] Thanks for reporting. This happens because GNU make was updated to 4.3, which includes backwards incompatible changes. Updating to that was probably a bad idea before making sure most things work with the new version... The package in experimental has this fixed by getting rid of the autotools/make-based build system and switching to meson. GStreamer 1.18.0 should make it in time for bullseye so I'm not going to bother fixing this separately.
Bug#959879: python-jedi: New upstream release 0.17.0
Source: python-jedi Severity: wishlist Dear Maintainer, There's a new upstream release, 0.17.0, that is required for the vim coc-python plugin. It does not work with earlier versions so it would be great if the package in Debian could be updated. Thanks! -- 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) Kernel: Linux 5.5.0-2-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#956002: pitivi: Python SyntaxWarning in package setup - bad identity comparisons against literals
On Sun, 2020-04-05 at 17:36 -0400, Phil Miller wrote: > Package: pitivi > Version: 0.999-2 > Severity: normal > > running python rtupdate hooks for python3.8... > [snip other packages with the same warning] > /usr/lib/x86_64-linux-gnu/pitivi/python/pitivi/application.py:328: > SyntaxWarning: "is" with a literal. Did you mean "=="? > elif status is "UNSUPPORTED": > /usr/lib/x86_64-linux- > gnu/pitivi/python/pitivi/timeline/previewers.py:869: SyntaxWarning: > "is" with a literal. Did you mean "=="? > if self._image_size[0] is 0: Thanks for reporting. This is already fixed since quite a while upstream, and many other things too. We'll get the fix together with the next release in the hopefully not too distant future. signature.asc Description: This is a digitally signed message part
Bug#954799: ITA fatsort -- utility for sorting FAT directory structures
On Mon, 2020-03-23 at 17:27 +0100, Jordi Sayol wrote: > > The current maintainer of the fatsort package has given me permission > to adopt it, so I'll do it if there isn't any inconvenience. Thanks for taking it over, please just go ahead :) signature.asc Description: This is a digitally signed message part
Bug#946329: valgrind-mpi FTBFS
Package: valgrind Version: 1:3.15.0-1 Severity: serious valgrind currently fails to build from source. The Ubuntu patch to drop MPI 1 support (drop-MPI-1-support.patch) probably fixes this. In file included from libmpiwrap.c:116: libmpiwrap.c: In function 'showTy': /usr/lib/x86_64-linux-gnu/openmpi/include/mpi.h:322:57: error: expected expression before '_Static_assert' 322 | #define THIS_SYMBOL_WAS_REMOVED_IN_MPI30(func, newfunc) _Static_assert(0, #func " was removed in MPI-3.0. Use " #newfunc " instead.") | ^~ /usr/lib/x86_64-linux-gnu/openmpi/include/mpi.h:1112:24: note: in expansion of macro 'THIS_SYMBOL_WAS_REMOVED_IN_MPI30' 1112 | #define MPI_UB THIS_SYMBOL_WAS_REMOVED_IN_MPI30(MPI_UB, MPI_Type_create_resized); |^~~~ libmpiwrap.c:281:19: note: in expansion of macro 'MPI_UB' 281 |else if (ty == MPI_UB) fprintf(f,"UB"); | ^~ /usr/lib/x86_64-linux-gnu/openmpi/include/mpi.h:322:57: error: expected expression before '_Static_assert' 322 | #define THIS_SYMBOL_WAS_REMOVED_IN_MPI30(func, newfunc) _Static_assert(0, #func " was removed in MPI-3.0. Use " #newfunc " instead.") | ^~ /usr/lib/x86_64-linux-gnu/openmpi/include/mpi.h:1113:24: note: in expansion of macro 'THIS_SYMBOL_WAS_REMOVED_IN_MPI30' 1113 | #define MPI_LB THIS_SYMBOL_WAS_REMOVED_IN_MPI30(MPI_LB, MPI_Type_create_resized); |^~~~ libmpiwrap.c:282:19: note: in expansion of macro 'MPI_LB' 282 |else if (ty == MPI_LB) fprintf(f,"LB"); | ^~ libmpiwrap.c: In function 'showCombiner': /usr/lib/x86_64-linux-gnu/openmpi/include/mpi.h:322:57: error: expected expression before '_Static_assert' 322 | #define THIS_SYMBOL_WAS_REMOVED_IN_MPI30(func, newfunc) _Static_assert(0, #func " was removed in MPI-3.0. Use " #newfunc " instead.") | ^~ /usr/lib/x86_64-linux-gnu/openmpi/include/mpi.h:743:46: note: in expansion of macro 'THIS_SYMBOL_WAS_REMOVED_IN_MPI30' 743 | #define MPI_COMBINER_HVECTOR_INTEGER THIS_SYMBOL_WAS_REMOVED_IN_MPI30(MPI_COMBINER_HVECTOR_INTEGER, MPI_COMBINER_HVECTOR); | ^~~~ libmpiwrap.c:354:12: note: in expansion of macro 'MPI_COMBINER_HVECTOR_INTEGER' 354 | case MPI_COMBINER_HVECTOR_INTEGER: fprintf(f, "HVECTOR_INTEGER"); break; |^~~~ /usr/lib/x86_64-linux-gnu/openmpi/include/mpi.h:322:57: error: expected expression before '_Static_assert' 322 | #define THIS_SYMBOL_WAS_REMOVED_IN_MPI30(func, newfunc) _Static_assert(0, #func " was removed in MPI-3.0. Use " #newfunc " instead.") | ^~ /usr/lib/x86_64-linux-gnu/openmpi/include/mpi.h:743:46: note: in expansion of macro 'THIS_SYMBOL_WAS_REMOVED_IN_MPI30' 743 | #define MPI_COMBINER_HVECTOR_INTEGER THIS_SYMBOL_WAS_REMOVED_IN_MPI30(MPI_COMBINER_HVECTOR_INTEGER, MPI_COMBINER_HVECTOR); | ^~~~ libmpiwrap.c:354:12: note: in expansion of macro 'MPI_COMBINER_HVECTOR_INTEGER' 354 | case MPI_COMBINER_HVECTOR_INTEGER: fprintf(f, "HVECTOR_INTEGER"); break; |^~~~ libmpiwrap.c:354:40: error: expected expression before ':' token 354 | case MPI_COMBINER_HVECTOR_INTEGER: fprintf(f, "HVECTOR_INTEGER"); break; |^ In file included from libmpiwrap.c:116: /usr/lib/x86_64-linux-gnu/openmpi/include/mpi.h:322:57: error: expected expression before '_Static_assert' 322 | #define THIS_SYMBOL_WAS_REMOVED_IN_MPI30(func, newfunc) _Static_assert(0, #func " was removed in MPI-3.0. Use " #newfunc " instead.") | ^~ /usr/lib/x86_64-linux-gnu/openmpi/include/mpi.h:744:47: note: in expansion of macro 'THIS_SYMBOL_WAS_REMOVED_IN_MPI30' 744 | #define MPI_COMBINER_HINDEXED_INTEGER THIS_SYMBOL_WAS_REMOVED_IN_MPI30(MPI_COMBINER_HINDEXED_INTEGER, MPI_COMBINER_HINDEXED); | ^~~~ libmpiwrap.c:359:12: note: in expansion of macro 'MPI_COMBINER_HINDEXED_INTEGER' 359 | case MPI_COMBINER_HINDEXED_INTEGER: fprintf(f, "HINDEXED_INTEGER"); break; |^ /usr/lib/x86_64-linux-gnu/openmpi/include/mpi.h:322:57: error: expected expression before '_Static_assert' 322 | #define THIS_SYMBOL_WAS_REMOVED_IN_MPI30(func, newfunc) _Static_assert(0, #func " was removed in M
Bug#942614: valgrind: debuginfo section duplicates a section in the main ELF file
On Sat, 19 Oct 2019 03:36:12 +0200 Simon Richter wrote: > Package: valgrind > Version: 1:3.15.0-1.1 > Severity: normal > Tags: upstream > > Hi, > > this is probably the same as Ubuntu bug #1848211. I can confirm that the 0001-Don-t-look-for-debug-alt-file-in-debug-image-if-it-i.patch patch from the Ubuntu package fixes this. Not only does the warning disappear but also callstacks provided by valgrind are actually useful again. Note that valgrind-mpi doesn't build at all on current sid, but that's a separate issue. signature.asc Description: This is a digitally signed message part
Bug#942314: RFP: gst-plugins-rs -- GStreamer plugins written in Rust
Package: wnpp Severity: wishlist * Package name: gst-plugins-rs Version : 0.5.0 Upstream Author : Sebastian Dröge * URL : https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs * License : LGPL, MIT/Apache-2.0 Programming Lang: Rust Description : GStreamer plugins written in Rust The GStreamer project is starting to write various extension plugins in the Rust programming language. There are a few useful ones now at this point and it would be good to start packaging them. I personally don't have the time for maintaining this also in Debian in addition to all the other GStreamer packages (help welcome!) but would be happy to assist anybody who wants to start packaging gst-plugins-rs. The package should probably be maintained as part of the Debian Rust team: https://wiki.debian.org/Teams/RustPackaging See there also for the Rust-specific packaging policy. It will be required to also package various dependencies as part of this.
Bug#929185: default soundfonts
On Wed, 2019-09-04 at 13:07 +0200, Fabian Greffrath wrote: > Hi slomo, > > could you please consider this patch for the next gst-plugins-bad1.0 > upload? Thanks, I've added it to git for now. There will be an 1.16.1 release in the near future, the patch will be part of that signature.asc Description: This is a digitally signed message part
Bug#914250: gstreamer1.0-plugins-good: cheese is not able to capture from usb webcam
forwarded 914250 https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/issues/644 thanks On Tue, 20 Nov 2018 23:14:56 +0100 =?UTF-8?Q?Bernhard_=c3=9cbelacker?= wrote: > a webcam that was working previously in stretch does not with current testing. > > I tracked it down to the gstreamer1.0-plugins-good package, > was working until 1.12.4-1+b1, failes since 1.14.0-4. Thanks, I've forwarded this upstream: https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/issues/644 signature.asc Description: This is a digitally signed message part
Bug#914549: Segmentation fault for some videos (assertion 'GST_MINI_OBJECT_IS_LOCKABLE (object)' failed)
On Sat, 24 Nov 2018 19:39:11 +0100 antistress wrote: > Package: gstreamer1.0-plugins-base > Version: 1.14.4-dmo1 You're using a non-official version of GStreamer. Can you reproduce this also with the packages from Debian? signature.asc Description: This is a digitally signed message part
Bug#914697: libgstreamer1.0-0: Certain GTK and GNOME applications fai to start or load
On Mon, 26 Nov 2018 13:14:56 +0100 Adrian Immanuel Kiess wrote: > > The error these applications spit out is: > > (gst-plugin-scanner:12086): GLib-GObject-WARNING **: 13:00:20.092: cannot > register existing type 'GstAggregator' This sounds like you have incompatible versions of GStreamer installed. What's the output of dpkg -l *gst* and ldd /usr/lib/*/gstreamer-1.0/libgstcompositor.so ? Thanks! signature.asc Description: This is a digitally signed message part
Bug#927739: FTBFS: undefined reference to `yylex'
On Mon, 2019-04-22 at 14:22 +0200, Santiago Vila wrote: > > I can build libkate in my autobuilders. > > I also triggered a rebuild in reproducible-builds and it worked: > > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/libkate.html > > Can you reproduce the failure in another system? > Does the failure happen always, or it happens randomly? I did some more testing. It happens only if libfl-dev is installed, which was on my system but is not part of the build dependencies. So this should either become part of Build-Conflicts or has to be fixed, but it's less bad than I thought :) To solve it, one can link with libfl.a instead of libfl.so apparently. signature.asc Description: This is a digitally signed message part
Bug#927739: FTBFS: undefined reference to `yylex'
Source: libkate Version: 0.4.1-9 Severity: serious Hi, Something seems to have changed with flex, which causes the package to now fail to build: /bin/bash ../libtool --tag=CC --silent --mode=link gcc -Wall -W -I/usr/include/libpng16 -g -O2 -fdebug-prefix-map=/home/slomo/tmp/foo/libkate-0.4.1=. -fstack-protector-strong -Wformat -Werror=format-security -Wl,-z,relro -Wl,-z,now -o kateenc kateenc-kateenc.o kateenc-kate_lexer.o kateenc-kate_parser.o kateenc-kpng.o ../lib/liboggkate.la ../lib/libkate.la -logg -lpng16 -lz -lfl /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/8/../../../x86_64-linux-gnu/libfl.so: undefined reference to `yylex' collect2: error: ld returned 1 exit status 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.19.0-4-amd64 (SMP w/8 CPU cores) 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 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#914861: gstreamer1.0: Please convert from cdbs to dh
On Tue, 27 Nov 2018 22:36:46 -0500 Jeremy Bicha wrote: > Source: gstreamer1.0 > Version: 1.14.4-1 > X-Debbugs-CC: sl...@debain.org > > Sebastian, the gstreamer packages are some of the last prominent > "desktop" packages I use that use cdbs. I think they would benefit > from a conversion to use the "simple dh" rules instead. > > Here are some benefits I anticipate: > - dh has built-in support for meson. I guess there's nothing stopping > cdbs packages from using meson, but I haven't seen any do it. > - dh has built-in support for multiarch. Obvlously, cdbs packages can > do multiarch too but it's just a bit easier in dh. > - dh_auto_test runs build tests by default. > - dh is now much more commonly used than cdbs which makes the rules > file more accessible to more Debian contributors. > - in my opinion, dh is easier to work with in general. > > I would like to help you convert these packages, but I didn't want to > start on the work unless you were open to the idea. I think that's a great idea. I'm currently updating in the debian- experimental branch for 1.15.1 and if you could start working on that afterwards that would be wonderful. I already had that on my list since a while but never got to it. Thanks a lot and sorry for the late reply! signature.asc Description: This is a digitally signed message part
Bug#904266: gir1.2-gstreamer-1.0: Install the typelibs into a multi-arch directory
On Wed, 2018-08-08 at 12:37 +, Hugh McMaster wrote: > Hi Sebastian, > > On Monday, 30 July 2018 16:32:27 +1000, Sebastian Dröge wrote: > > Are gobject-introspection and all the bindings actually looking in > > that > > directory too? > > The typelibs for gobject-introspection are now installed in > /usr/lib//gobject-introspection/giscanner. Thanks, I'll take a look at that together with the next upload unless you'd like to provide a patch for this already. Same thing for the other related bug, the proposed solution seems fine. signature.asc Description: This is a digitally signed message part
Bug#823307: libgstreamer1.0-dev is not Multi-Arch compatible
On Wed, 2018-08-08 at 12:30 +, Hugh McMaster wrote: > On Monday, 30 July 2018 016:33:39 +1000, Sebastian Dröge wrote: > > Which files are conflicting between the x86 and x86-64 version of the > > package? > > There is only file conflict: in the binary gst-codec-info-1.0. > > As this is a compiled binary, it is not so easy to fix. But I need to look > at the sources to understand if it has an architecture-indepenent > interface and/or output. It's not unfortunately, it needs to be able to load .so files for that target build architecture during the build of packages. How is this solved in other such cases? signature.asc Description: This is a digitally signed message part
Bug#904266: gir1.2-gstreamer-1.0: Install the typelibs into a multi-arch directory
On Sun, 22 Jul 2018 13:23:33 + Hugh McMaster wrote: > Package: gir1.2-gstreamer-1.0 > Version: 1.14.1-1 > Severity: normal > Tags: patch > > Dear Maintainer, > > The package gir1.2-gstreamer-1.0 is not currently multi-arch compatible, > as the typelibs are installed in /usr/lib/girepository-1.0. > > To make the package multi-arch compatible, the typelibs need to be > installed in /usr/lib/*/girepository-1.0. > > The attached patch makes this change and marks the package Multi-Arch: same. Are gobject-introspection and all the bindings actually looking in that directory too? signature.asc Description: This is a digitally signed message part
Bug#823307: libgstreamer1.0-dev is not Multi-Arch compatible
On Tue, 03 May 2016 10:46:12 +0200 Francois Gouget wrote: > Package: libgstreamer1.0-dev > Version: 1.8.0-2 > Severity: normal > > Dear Maintainer, > > The libgstreamer1.0-dev package is not multi-arch aware so that the amd64 > version > conflicts with the i386 one which makes it impossible to install both. As a > result > several libigstxxx.so symbolic links are missing making development > impossible without > manually hacking the filesystem. > > This particularly hurts Wine development as it is important to be able to > compile both > the 32 and 64 bit versions. > > Note that this bug is still present in 1.8.1-1. Which files are conflicting between the x86 and x86-64 version of the package? signature.asc Description: This is a digitally signed message part
Bug#894076: Can't include GL and GLES headers simultaneously on non-64 bit architectures
On Thu, 2018-03-29 at 12:45 +0300, Sebastian Dröge wrote: > On Thu, 2018-03-29 at 10:54 +0200, Julien Cristau wrote: > > > > I expect we'll get a fix from upstream when that happens. > > What would you suggest for the time being? This sounds like it's > going to take a while. > > The simplest workaround on my side would probably be to just not > build the Qt/QML GStreamer plugin on ARM until this is fixed. Ok, as there is no progress here I'll simply remove the Qt/QML plugin on ARM for the time being. signature.asc Description: This is a digitally signed message part
Bug#894387: gst-plugins-bad1.0: Corebird can't playvideos anymore
On Thu, 2018-03-29 at 19:24 +0200, Philip Rinn wrote: > > > So we'll have to get that solved somehow > > Is there another solution than adding a dependency on gstreamer1.0- > gtk3 in corebird? (Besides adding it to gstreamer1.0-plugins-good > which you obviously don't want). GStreamer has a mechanism to tell you about missing plugins and ask the user to install it. On Debian this is handled via /etc/alternatives/gstreamer-codec-install , which usually then points to packagekit and would ask the user to install the gstreamer1.0-gtk3 package then. But as corebird apparently does not use that API in the current version, that's also not a very useful solution. I don't see a solution that a) requires no changes to corebird, b) doesn't let gstreamer1.0-plugins-good (or -bad) pull in GTK as a dependency and defeat the purpose of splitting it off into its own package. We should really just somehow get the new package into testing fast, which is currently blocked on mesa. signature.asc Description: This is a digitally signed message part
Bug#894387: gst-plugins-bad1.0: Corebird can't playvideos anymore
reassign 894387 gst-plugins-good1.0 thanks On Thu, 2018-03-29 at 18:28 +0200, Philip Rinn wrote: > Source: gst-plugins-bad1.0 > Version: 1.14.0-1 > Severity: normal > > Hi, > > since gst-plugins-bad1.0 1.14.0-1 entered testing today corebird > can't play videos anymore. > > The error is: > > "Could not create gtksink. Need gst-plugins-bad >= 1.6" You need to depend on gstreamer1.0-gtk now, which provides the GTK plugin. It was moved to its own package because people complained that gstreamer1.0-plugins-bad pulls in too many dependency (and it would be in gstreamer1.0-plugins-good otherwise now anyway with 1.14). Unfortunately, that package is not in testing yet because of a bug in mesa, which seems blocked by bureaucracy now. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=894076 So we'll have to get that solved somehow signature.asc Description: This is a digitally signed message part
Bug#894076: Can't include GL and GLES headers simultaneously on non-64 bit architectures
On Thu, 2018-03-29 at 10:54 +0200, Julien Cristau wrote: > > I expect we'll get a fix from upstream when that happens. What would you suggest for the time being? This sounds like it's going to take a while. The simplest workaround on my side would probably be to just not build the Qt/QML GStreamer plugin on ARM until this is fixed. signature.asc Description: This is a digitally signed message part
Bug#894076: Can't include GL and GLES headers simultaneously on non-64 bit architectures
On Mon, 2018-03-26 at 20:37 +0300, Sebastian Dröge wrote: > On Mon, 2018-03-26 at 19:03 +0200, Julien Cristau wrote: > > Control: severity -1 normal > > Control: tag -1 upstream > > > > On 03/26/2018 10:01 AM, Sebastian Dröge wrote: > > > Package: mesa > > > Version: 17.3.7-1 > > > Severity: serious > > > Forwarded: https://bugs.freedesktop.org/show_bug.cgi?id=105328 > > > > > > > I don't think that's a serious bug. > > Well, it's preventing gst-plugins-good1.0 from building currently and > all workarounds would mean a loss in functionality (no GL support on > arm). > > It also currently causes no GLES support to be available on 32 bit > platforms in gst-plugins-base1.0. Is there any progress on this? I could provide a patch if that helps with anything and if you would be open to apply that before upstream went through all the Khronos bureaucracy signature.asc Description: This is a digitally signed message part
Bug#894149: buzztrax FTBFS with gstreamer 1.14
On Wed, 2018-03-28 at 10:08 +0300, Juhani Numminen wrote: > Control: tags -1 fixed-upstream > > On Mon, 26 Mar 2018 22:31:51 +0300 Adrian Bunk > wrote: > > Source: buzztrax > > Version: 0.10.2-4 > > ... > > src/gst/dec/bt-dec.c:956:14: error: expected '=', ',', ';', 'asm' > > or '__attribute__' before '-' token > > buzztrax - dec, > > ^ > > It seems that these commits might be useful: > > https://github.com/Buzztrax/buzztrax/commit/a89abcf > https://github.com/Buzztrax/buzztrax/commit/f34f72e > https://github.com/Buzztrax/buzztrax/commit/d56c60a Yes but I'm also checking with upstream if they can make a release with those commits and any other meaningful fixes since the last release instead. If not, I'll upload a version with those patches. signature.asc Description: This is a digitally signed message part
Bug#894076: Can't include GL and GLES headers simultaneously on non-64 bit architectures
On Mon, 2018-03-26 at 19:03 +0200, Julien Cristau wrote: > Control: severity -1 normal > Control: tag -1 upstream > > On 03/26/2018 10:01 AM, Sebastian Dröge wrote: > > Package: mesa > > Version: 17.3.7-1 > > Severity: serious > > Forwarded: https://bugs.freedesktop.org/show_bug.cgi?id=105328 > > > > I don't think that's a serious bug. Well, it's preventing gst-plugins-good1.0 from building currently and all workarounds would mean a loss in functionality (no GL support on arm). It also currently causes no GLES support to be available on 32 bit platforms in gst-plugins-base1.0. signature.asc Description: This is a digitally signed message part
Bug#894076: Can't include GL and GLES headers simultaneously on non-64 bit architectures
Package: mesa Version: 17.3.7-1 Severity: serious Forwarded: https://bugs.freedesktop.org/show_bug.cgi?id=105328 Hi, Currently it's impossible to include the GL and GLES headers simultaneously on non-64 bit architectures, see e.g. https://buildd.debian.org/status/fetch.php?pkg=gst-plugins-good1.0&arch=armel&ver=1.14.0-1&stamp=1521580828&raw=0 This causes a) gst-plugins-base1.0 to only build with support for GL and not both GL and GLES on the affected architectures, b) causes gst-plugins-good1.0 to fail to build because Qt is including the GLES headers, while GStreamer includes only the GL headers because of the above Currently gst-plugins-good1.0 fails to build on armel/armhf and can't migrate to testing because of this bug. As a workaround I could force gst-plugins-good to only build with GLES support on armel/armhf but that's just that, a workaround. This was reported upstream here https://bugs.freedesktop.org/show_bug.cgi?id=105328 and upstream agrees that this is a bug, and it seems easy enough to fix by guarding the type definitions with the preprocessor to not redefine them if they were already defined. Thanks! signature.asc Description: This is a digitally signed message part
Bug#893813: gst-plugins-bad1.0: FTBFS on x32: wrongly uses amd64 assembly
forwarded 893813 thanks On Thu, 2018-03-22 at 19:05 +0100, Thorsten Glaser wrote: > [...] > > Please report that upstream. Thanks, done: https://bugzilla.gnome.org/show_bug.cgi?id=794605 Feel free to NMU for this change, but I expect there to be more similar problems elsewhere. signature.asc Description: This is a digitally signed message part
Bug#892128: libgstreamer-gl1.0-0: Missing recommends on gstreamer1.0-gl
On Mon, 2018-03-05 at 16:26 -0500, Jeremy Bicha wrote: > Package: libgstreamer-gl1.0-0 > Version: 1.13.90-1 > > I think libgstreamer-gl1.0-0 is missing a Recommends on gstreamer1.0-gl. > > I noticed this while figuring out an issue with the dependencies for > webkit2gtk. > > https://bugs.webkit.org/183336 Thanks, next upload will fix that. I've already included a fix in GIT. You probably want to let webkit depend on gstreamer1.0-gl though, AFAIU it requires those elements now for proper accelerated video playback. signature.asc Description: This is a digitally signed message part
Bug#862024: Status of this bug?
On Sat, 2018-01-20 at 10:19 +0200, Sebastian Dröge wrote: > On Fri, 2018-01-19 at 13:26 -0800, Josh Triplett wrote: > > I'd love to see this fixed as well, and a gstreamer1.0-plugins- > > opencv > > or > > similar introduced. > > > > Would it help to have a patch? > > Yes, please go ahead :) Thanks! I had no time yet to do this > properly. > > Note that there's also an OpenCV library in GStreamer, so multiple > binary packages would be needed here. I've implemented something like this in GIT for gst-plugins-bad. Will finish and upload it hopefully during this weekend, or early next week otherwise. signature.asc Description: This is a digitally signed message part
Bug#888501: gstreamer1.0-vaapi: Latests versions does not work at all
reassign 888501 libva thanks On Fri, 26 Jan 2018 10:40:36 -0200 Junior Polegato wrote: > libva info: VA-API version 0.40.0 > libva info: va_getDriverName() returns 0 > libva info: Trying to open /usr/lib/i386-linux-gnu/dri/i965_drv_video.so > libva error: /usr/lib/i386-linux-gnu/dri/i965_drv_video.so has no function > __vaDriverInit_0_32 > libva info: va_openDriver() returns -1 Hi, this looks like a version mismatch between your Intel driver and libva, nothing related to gstreamer-vaapi. Reassigning to libva for the time being. Best regards, Sebastian signature.asc Description: This is a digitally signed message part
Bug#889020: New upstream version 0.11
Package: gtimelog Severity: wishlist Hi, there's a new upstream version, 0.11, available now. It features a much more polished UI and useful features that previously required external applications. Would be great to have the package updated in Debian. Sebastian signature.asc Description: This is a digitally signed message part
Bug#888326: gst-libav1.0: FTBFS with FFmpeg 3.5
forwarded 888326 https://bugzilla.gnome.org/show_bug.cgi?id=792900 thanks On Wed, 24 Jan 2018 22:26:50 + jcowg...@debian.org wrote: > Your package FTBFS with the upcoming version 3.5 of FFmpeg. In FFmpeg 3.5, > there are a number of API changes which will cause many packages to FTBFS. > For this reason I have uploaded an early development snapshot to experimental > before the 3.5 release in an attempt to fix some of these a bit quicker. > While 3.5 has not been finalized and the ABI is not stable yet, there should > not be any significant API breakages before the release. > > [...] Thanks, I've forwarded this upstream: https://bugzilla.gnome.org/show_bug.cgi?id=792900 signature.asc Description: This is a digitally signed message part
Bug#849090: Port to Python 3 and python3-gst-1.0
On Thu, 22 Dec 2016 17:52:00 +0200 Sebastian Dröge wrote: > your package currently depends on python-gst-1.0. Upstream is planning > to drop Python 2.x support in the near future, leaving only Python 3 > support. > > Please update your package to Python 3 to make this as painless as > possible later. Thanks! Just an update here, this will likely happen in the next 2-3 months with the next upstream release. Your package will become uninstallable at that point unless it is ported to Python 3. signature.asc Description: This is a digitally signed message part
Bug#849086: Port to Python 3 and python3-gst-1.0
On Thu, 22 Dec 2016 17:51:41 +0200 Sebastian Dröge wrote: > your package currently depends on python-gst-1.0. Upstream is planning > to drop Python 2.x support in the near future, leaving only Python 3 > support. > > Please update your package to Python 3 to make this as painless as > possible later. Thanks! Just an update here, this will likely happen in the next 2-3 months with the next upstream release. Your package will become uninstallable at that point unless it is ported to Python 3. signature.asc Description: This is a digitally signed message part
Bug#849089: Port to Python 3 and python3-gst-1.0
On Thu, 22 Dec 2016 17:51:55 +0200 Sebastian Dröge wrote: > your package currently depends on python-gst-1.0. Upstream is planning > to drop Python 2.x support in the near future, leaving only Python 3 > support. > > Please update your package to Python 3 to make this as painless as > possible later. Thanks! Just an update here, this will likely happen in the next 2-3 months with the next upstream release. Your package will become uninstallable at that point unless it is ported to Python 3. signature.asc Description: This is a digitally signed message part
Bug#849088: Port to Python 3 and python3-gst-1.0
On Thu, 22 Dec 2016 17:51:52 +0200 Sebastian Dröge wrote: > your package currently depends on python-gst-1.0. Upstream is planning > to drop Python 2.x support in the near future, leaving only Python 3 > support. > > Please update your package to Python 3 to make this as painless as > possible later. Thanks! Just an update here, this will likely happen in the next 2-3 months with the next upstream release. Your package will become uninstallable at that point unless it is ported to Python 3. signature.asc Description: This is a digitally signed message part
Bug#849087: Port to Python 3 and python3-gst-1.0
On Thu, 22 Dec 2016 17:51:48 +0200 Sebastian Dröge wrote: > your package currently depends on python-gst-1.0. Upstream is planning > to drop Python 2.x support in the near future, leaving only Python 3 > support. > > Please update your package to Python 3 to make this as painless as > possible later. Thanks! Just an update here, this will likely happen in the next 2-3 months with the next upstream release. Your package will become uninstallable at that point unless it is ported to Python 3. signature.asc Description: This is a digitally signed message part
Bug#849084: Port to Python 3 and python3-gst-1.0
On Thu, 22 Dec 2016 17:51:10 +0200 Sebastian Dröge wrote: > your package currently depends on python-gst-1.0. Upstream is planning > to drop Python 2.x support in the near future, leaving only Python 3 > support. > > Please update your package to Python 3 to make this as painless as > possible later. Thanks! Just an update here, this will likely happen in the next 2-3 months with the next upstream release. Your package will become uninstallable at that point unless it is ported to Python 3. signature.asc Description: This is a digitally signed message part
Bug#849092: Port to Python 3 and python3-gst-1.0
On Thu, 22 Dec 2016 17:52:13 +0200 Sebastian Dröge wrote: > your package currently depends on python-gst-1.0. Upstream is planning > to drop Python 2.x support in the near future, leaving only Python 3 > support. > > Please update your package to Python 3 to make this as painless as > possible later. Thanks! Just an update here, this will likely happen in the next 2-3 months with the next upstream release. Your package will become uninstallable at that point unless it is ported to Python 3. signature.asc Description: This is a digitally signed message part
Bug#849091: Port to Python 3 and python3-gst-1.0
On Thu, 22 Dec 2016 17:52:09 +0200 Sebastian Dröge wrote: > your package currently depends on python-gst-1.0. Upstream is planning > to drop Python 2.x support in the near future, leaving only Python 3 > support. > > Please update your package to Python 3 to make this as painless as > possible later. Thanks! Just an update here, this will likely happen in the next 2-3 months with the next upstream release. Your package will become uninstallable at that point unless it is ported to Python 3. signature.asc Description: This is a digitally signed message part
Bug#888245: Port to Python 3 and python3-gst-1.0
Package: photofilmstrip Severity: normal User: sl...@debian.org Usertags: python-gst-1.0-removal Hi, your package currently depends on python-gst-1.0. Upstream is planning to drop Python 2.x support in the near future (next 2-3 months!), leaving only Python 3 support. Please update your package to Python 3 to make this as painless as possible. Thanks! Sebastian signature.asc Description: This is a digitally signed message part
Bug#862024: Status of this bug?
On Fri, 2018-01-19 at 13:26 -0800, Josh Triplett wrote: > I'd love to see this fixed as well, and a gstreamer1.0-plugins-opencv > or > similar introduced. > > Would it help to have a patch? Yes, please go ahead :) Thanks! I had no time yet to do this properly. Note that there's also an OpenCV library in GStreamer, so multiple binary packages would be needed here. signature.asc Description: This is a digitally signed message part
Bug#863663: Letter to Santa
On Wed, 2017-12-20 at 23:57 +0100, Francesco Poli wrote: > > ;-) > > Seriously: is there any progress (not documented on the bugzilla > bug)? Please let me know. The mailing list is no bug tracker and mails like this are not going to motivate anybody, and at least in my case got rid of any motivation at all to look at it. Check the Bugzilla ticket for progress, it also contains some outline of how it could be fixed if someone wants to spend their time on it. > P.S.: Please keep the Debian bug address in Cc. Thanks! The Debian bug has the Bugzilla bug set as "forwarded-to", so will get updated automatically. Nothing to be done here. signature.asc Description: This is a digitally signed message part
Bug#883849: libwebkit2gtk-4.0-37 uninstallable because gst-plugins-bad1.0 is now at 1.12.4
On Fri, 2017-12-08 at 15:59 +0100, Emilio Pozuelo Monfort wrote: > On 08/12/17 15:44, Sebastian Dröge wrote: > > On Fri, 8 Dec 2017 11:17:22 +0100 Emilio Pozuelo Monfort > ian.org> wrote: > > > On 08/12/17 11:04, Paul Gevers wrote: > > > > Package: libwebkit2gtk-4.0-37 > > > > Version: 2.18.3-1 > > > > Severity: grave > > > > Justification: renders package unusable > > > > > > > > While trying to build a new version of liferea in unstable, I > > > > noticed that > > > > libwebkit2gtk-4.0-37 is uninstallable due to a newer version of > > > > gst-plugins-bad1.0. > > > > > > > > libwebkit2gtk-4.0-37 Depends libgstreamer-plugins-bad1.0-0 (<< > > > > 1.12.4) > > > > > > Just a small transition, fixed with: > > > > > > emilio@tatooine:~$ wb nmu gnome-dvb-daemon gstreamer-vaapi > > > webkit2gtk . ANY . > > > unstable . -m 'Rebuild against gst-plugins-bad1.0 1.12.4.' > > > > Please make sure to rebuild against 1.12.4-2. Then we won't have > > the > > same problem again for 1.12.5, but only once 1.13/1.14 is there. > > That's hard when there's no 1.12.4-2 in the archive yet and I already > scheduled those binNMUs earlier today :P That's disappointing, why don't you have a time-machine? :) Oh well, next time then! signature.asc Description: This is a digitally signed message part
Bug#883849: libwebkit2gtk-4.0-37 uninstallable because gst-plugins-bad1.0 is now at 1.12.4
On Fri, 8 Dec 2017 11:17:22 +0100 Emilio Pozuelo Monfort wrote: > On 08/12/17 11:04, Paul Gevers wrote: > > Package: libwebkit2gtk-4.0-37 > > Version: 2.18.3-1 > > Severity: grave > > Justification: renders package unusable > > > > While trying to build a new version of liferea in unstable, I noticed that > > libwebkit2gtk-4.0-37 is uninstallable due to a newer version of > > gst-plugins-bad1.0. > > > > libwebkit2gtk-4.0-37 Depends libgstreamer-plugins-bad1.0-0 (<< 1.12.4) > > Just a small transition, fixed with: > > emilio@tatooine:~$ wb nmu gnome-dvb-daemon gstreamer-vaapi webkit2gtk . ANY . > unstable . -m 'Rebuild against gst-plugins-bad1.0 1.12.4.' Please make sure to rebuild against 1.12.4-2. Then we won't have the same problem again for 1.12.5, but only once 1.13/1.14 is there. signature.asc Description: This is a digitally signed message part
Bug#883691: game-music-emu: AddressSanitizer: negative-size-param: (size=-8), size=-8 passed to memcpy in Mem_File_Reader::read_avail
Hi Salvatore, On Wed, 2017-12-06 at 20:32 +0100, Salvatore Bonaccorso wrote: > > Thank you. > > MITRE has assigned CVE-2017-17446 for this issue. > > I do not think we need a DSA for this issue, but could be fixed via a > point release. Upstream did a new release with a fix for this very crash, and also added some more checks for preventing similar bugs to the code. I'm uploading that to unstable now. This release only really contains the fix, nothing else, and if that's all fine with you it could also go into the next stable point release. signature.asc Description: This is a digitally signed message part
Bug#883691: game-music-emu: AddressSanitizer: negative-size-param: (size=-8), size=-8 passed to memcpy in Mem_File_Reader::read_avail
forwarded 883691 https://bitbucket.org/mpyne/game-music-emu/issues/14/addresssanitizer-negative-size-param-size thanks Hi Salvatore, On Wed, 2017-12-06 at 17:50 +0100, Salvatore Bonaccorso wrote: > [...] > > So the issue seem located in game-music-emu, Sebastian can you have a > look? I've forwarded this upstream now, thanks for reporting! See: https://bitbucket.org/mpyne/game-music-emu/issues/14/addresssanitizer-negative-size-param-size The crash can also be reproduced by running "ffplay" on the file. signature.asc Description: This is a digitally signed message part
Bug#879673: ffmpeg 3.4 API compat layer not 100% backwards compatible
On Tue, 2017-10-24 at 13:44 +0100, James Cowgill wrote: > > gst-libav upstream bug can be found here: > > https://bugzilla.gnome.org/show_bug.cgi?id=789193 > > OK, hopefully upstream ffmpeg can help fixing this bug, since I'm not > sure what I can do about it. It seems like it also introduces severe performance regressions as zerocopy decoding is not possible anymore with the compatibility layer. > > We'll try to port over to the new API but it looks like some > > effort, > > and even independent of that the compatibility layer should either > > be > > fixed or the soname of the libraries has to be updated. > > Updating SONAMEs doesn't help when there's an API break and the > behavior of existing functions has changed. It's simply the right thing to do if you break the API/ABI. That's why the soname exists to begin with :) Also it makes sure that all software is actually ready for the new version as it requires rebuilding/relinking to the new name, and generally makes it far more explicit that there was breakage and stuff has to be updated. All that of course only if the ffmpeg people don't consider this a bug in the compatibility layer but instead an intentional breakage. signature.asc Description: This is a digitally signed message part
Bug#879673: ffmpeg 3.4 API compat layer not 100% backwards compatible
Package: ffmpeg Version: 7:3.4-1 Severity: serious Hi, ffmpeg 3.4 comes with a new decoding API (among other things), and provides a compatibility layer around that for the old API. Unfortunately this compatibility layer is apparently not 100% backwards compatible or buggy. It breaks at least h264 decoding with gst- libav1.0, but then probably also breaks other packages. gst-libav upstream bug can be found here: https://bugzilla.gnome.org/show_bug.cgi?id=789193 We'll try to port over to the new API but it looks like some effort, and even independent of that the compatibility layer should either be fixed or the soname of the libraries has to be updated. Best regards, Sebastian signature.asc Description: This is a digitally signed message part
Bug#862024: gstreamer1.0-plugins-bad: Dependency on libopencv-contrib3.2 pulls over 236MB.
On Fri, 2017-10-20 at 22:16 +0200, Michael Biebl wrote: > On Thu, 19 Oct 2017 22:35:33 -0300 Daniel Serpell > wrote: > > Package: gstreamer1.0-plugins-bad > > Version: 1.12.3-2 > > Followup-For: Bug #862024 > > > > Hi! > > > > Biggest culprit are the new opencv packages, there libopencv-contrib3.2 > > pulls libvtk (150MB) and other big packages, about 236MB in total. > > > > Next in the list is libopencv-calib3d3.2, at 60MB, > > libopencv-objdetect3.2 at 58MB, libopencv-imgcodecs3.2 at 57MB. > > > > So, simply splitting /usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstopencv.so > > out in another package will reduce the size of dependencies to the > > previous level. > > Sebastian what do you think about splitting out less common used plugins > with heavy dependencies into a separate binary package like > gstreamer1.0-plugins-bad-extra? > > The first plugin moved to this -extra package would be libgstopencv.so > and we could move more plugins as we see fit (that's why I think using a > rather generic name like -extra would be preferrable). > > The main gstreamer1.0-plugins-bad package would have a suggests: > gstreamer1.0-plugins-bad-extra I'm fine with the idea, the main problem is that whatever I decide for "extra" plugins, for someone it will be a important one :) Moving opencv to its own binary package was on my list already, its dependency chain is just too huge and most people don't need it. So let's go with an "extra" package instead, I'll spend some time thinking about what else would make sense to have moved. DirectFB probably. > A middle ground would be to investigate why gstreamer1.0-plugins-bad > needs libopencv-contrib3.2 with opencv and if this could be avoided. > [...] Yes, we use some of the contrib stuff unfortunately. signature.asc Description: This is a digitally signed message part
Bug#878747: gst-plugins-bad1.0 FTBFS with libopenjp2-7-dev 2.3
On Mon, 2017-10-16 at 15:50 +0300, Adrian Bunk wrote: > Source: gst-plugins-bad1.0 > Version: 1.12.2-1 > Severity: serious > > https://buildd.debian.org/status/package.php?p=gst-plugins-bad1.0&sui > te=sid > > ... > > In file included from gstopenjpegdec.h:29:0, > from gstopenjpegdec.c:27: > gstopenjpeg.h:42:12: fatal error: openjpeg-2.2/openjpeg.h: No such > file or directory > # include > ^ > compilation terminated. There's a patch for this upstream, I'll get it included in the package in the next days and then upload a fixed version. Thanks! signature.asc Description: This is a digitally signed message part
Bug#863525: game-music-emu: library for interfacing with SPC
On Sun, 2017-09-24 at 23:06 -0400, Michael Gilbert wrote: > Hi, > > I would like to apply the patch attached to the original message. > I'll plan to do an upload to delayed/10 in a few days. If you have > any feedback, please let me know. Check with upstream why it is not included in gme. As long as it is separate, it would be better to also have it packaged separately. Also check with upstream if this is maintained at all and guaranteed to be available for future releases. Just patching in some random code found elsewhere that even adds API is usually not a good idea. signature.asc Description: This is a digitally signed message part
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#876257: libwebkit2gtk-4.0-37: blocks upgrade path for libgstreamer-plugins-bad1.0-0 1.12.3
Hi Alberto, On Wed, 2017-09-20 at 11:19 +0200, Alberto Garcia wrote: > On Wed, Sep 20, 2017 at 10:53:07AM +0200, Antonio Ospite wrote: > > it looks like libwebkit2gtk-4.0-37 is blocking the upgrade path > > for libgstreamer-plugins-bad1.0-0 1.12.3, looking at the package > > dependencies I spotted these constraints: > > > > libgstreamer-plugins-bad1.0-0 (>= 1.12.2), libgstreamer-plugins-bad1.0-0 > > (<< 1.12.3) > > > > which explain the issue. > > > > However I am not sure about why both constraints are there. > > That's gst-plugins-bad: > > DEB_DH_MAKESHLIBS_ARGS_libgstreamer-plugins-bad$(gst_deb_abi) += -V > "libgstreamer-plugins-bad$(gst_deb_abi) (>= $(gst_version)), > libgstreamer-plugins-bad$(gst_deb_abi) (<< $(gst_version_next))" > > From its changelog: > > + Split the libraries into their own package and add a -dev package. > The API of the library is not guaranteed to be stable and as such > the shlibs of the library package are very strict and will require > dependant libraries to get a rebuild after every new upstream version. > > I understand that its rdeps need to be rebuilt each time there's a new > upstream version, or how is that supposed to work? Sebastian? That's correct. The API and ABI of the libraries in gst-plugins-bad is not stable and can change every release. However only every new minor release, not micro release. So >= 1.12 < 1.13 would be sufficient here and probably would solve most of the headaches. Feel free to send me a patch or NMU directly for that, otherwise I'll get it done with the next upload. signature.asc Description: This is a digitally signed message part
Bug#852594: buzztrax: Update udevadm path
On Wed, 2017-09-13 at 15:15 +0200, Michael Biebl wrote: > Control: tags -1 fixed-upstream > On Tue, 12 Sep 2017 11:49:40 +0300 Sebastian =?ISO-8859-1?Q?Dr=F6ge?= > wrote: > > severity 852594 minor > > thanks > > > > Hi, > > > > as this only affects a source code comment and not actual code, I'm > > downgrading the severity to minor. This is in no way serious. > > Indeed. Thanks for your explanation. > I did not check each bug report individually before raising the severity > so I missed Stefan's comment. Sorry for that. Sure, not a problem at all :) signature.asc Description: This is a digitally signed message part