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#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#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#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#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#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#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#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#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#963301: 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#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#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#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
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#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#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#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#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#852594: buzztrax: Update udevadm path
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. Sebastian signature.asc Description: This is a digitally signed message part
Bug#865423: gst-rtsp-server1.0: testsuite emits large amounts of multicast traffic
On Wed, 2017-06-21 at 11:47 +0100, James Cowgill wrote: > > Hi, > > While running the testsuite, the "gst/rtspserver" test emits about 200k > UDP packets into the local network. They are all sent to a multicast > address which will be forwarded to the router for the current subnet and > then probably dropped (since no-one else should be in the chosen > multicast group). This violates Policy 4.9 which states "For packages in > the main archive, no required targets may attempt network access." > > On a related note, this does seem to be the cause of losing all the mips > buildds at AQL recently. The multicast traffic seems to trip the > protection mechanisms at AQL and so the router disables the Debian rack > to "protect" the rest of the network. There was a firewall rule to > prevent this, but there was a typo in it so it didn't work this time. > > It is likely this package will be blacklisted on mips* until this bug is > fixed. Can you think of any alternative other than disabling the testsuite? I'm ok with disabling it if there's nothing else we can do, and feel free to also just upload a NMU for that :) Sebastian signature.asc Description: This is a digitally signed message part
Bug#853723: tracker-extract gets killed by seccomp when gstreamer tries to regenerate cache (dup2 related)
On Tue, 2017-01-31 at 16:04 +0200, Sebastian Dröge wrote: > On Tue, 31 Jan 2017 11:33:34 +0100 Laurent Bigonville rg > > wrote: > > Package: tracker-extract > > Version: 1.10.4-1 > > Severity: serious > > > > Hi, > > > > tracker-extract gets killed by seccomp when gstreamer tries to > > regenerate cache. > > > > According to Simon, one of the solution would be to set the > > GST_REGISTRY_UPDATE=no environment variable. > > Or you could set GST_REGISTRY to a filename in a path that is > readable/writeable by tracker-extract. > > Your suggestion has the advantage that there is only a single > registry, > and tracker-extract never generates a new one. Mine has the advantage > that tracker-extract would always have the latest information in the > registry (e.g. if plugins were added/removed, tracker would otherwise > use the old information... and possibly fail to load things that it > thinks that are there). Oh I misread, the problem is the forking plus file descriptor passing. In that case you could also set GST_REGISTRY_FORK=no, which would let it do the registry update in-process (which has the disadvantage that broken plugins that crash upon loading can't be blacklisted and the whole process just dies). signature.asc Description: This is a digitally signed message part
Bug#853723: tracker-extract gets killed by seccomp when gstreamer tries to regenerate cache (dup2 related)
On Tue, 31 Jan 2017 11:33:34 +0100 Laurent Bigonville wrote: > Package: tracker-extract > Version: 1.10.4-1 > Severity: serious > > Hi, > > tracker-extract gets killed by seccomp when gstreamer tries to > regenerate cache. > > According to Simon, one of the solution would be to set the > GST_REGISTRY_UPDATE=no environment variable. Or you could set GST_REGISTRY to a filename in a path that is readable/writeable by tracker-extract. Your suggestion has the advantage that there is only a single registry, and tracker-extract never generates a new one. Mine has the advantage that tracker-extract would always have the latest information in the registry (e.g. if plugins were added/removed, tracker would otherwise use the old information... and possibly fail to load things that it thinks that are there). signature.asc Description: This is a digitally signed message part
Bug#850266: Missing headers in -dev package
Package: libsrtp2-dev Severity: serious Version: 2.0.0-1 Hi, it seems like the headers in the crypto subdirectory should also be included, at least partially. Without this, constants like SRTP_AES_128_ICM SRTP_NULL_CIPHER and others are missing and they seem to be needed for usage of the API. Also various functions from the srtp_priv.h header that was available in < 2.0 seem to be needed, at least the software I'm looking at is using them. For example srtp_get_stream(), for which there seems to be no alternative. Best regards, Sebastian signature.asc Description: This is a digitally signed message part
Bug#845037: libschroedinger-1.0-0: is this package fit for stretch?
On Mon, 2016-11-21 at 23:46 +0100, Andreas Cadhalpun wrote: > Hi Sebastian, > > On 21.11.2016 08:22, Sebastian Dröge wrote: > > On Sun, 2016-11-20 at 11:57 +0100, Moritz Muehlenhoff wrote: > > > > > > Thus I think stretch would be better of without this library. > > > > > > > > As replacement, ffmpeg has a decent dirac decoder and also a > > > > vc2 encoder, which is the intra-only subset of dirac that > > > > got standardized by the SMPTE. > > > > > > Andreas, thanks for filing this bug. Fully agreed from my side. > > > > I tend to agree here. > > OK, then it's agreed to remove libschroedinger. > > > Note however that VC2 is only a subset of Dirac, > > so we'll definitely lose some (probably unimportant) functionality > > here. > > That's true, but I also think that the functionality going to be lost > is rather unimportant. Ack > Yes. The ocaml bindings have a very low popcon (14), so I think it's > OK to just remove them together with libschroedinger. > > I will take care of ffmpeg myself and I assume you will take care of > gst-plugins-bad1.0. Yeah, will do in the next days! Some other things to handle first signature.asc Description: This is a digitally signed message part
Bug#845037: libschroedinger-1.0-0: is this package fit for stretch?
On Sun, 2016-11-20 at 11:57 +0100, Moritz Muehlenhoff wrote: > > Thus I think stretch would be better of without this library. > > > > As replacement, ffmpeg has a decent dirac decoder and also a > > vc2 encoder, which is the intra-only subset of dirac that > > got standardized by the SMPTE. > > Andreas, thanks for filing this bug. Fully agreed from my side. I tend to agree here. Note however that VC2 is only a subset of Dirac, so we'll definitely lose some (probably unimportant) functionality here. Current reverse dependencies are ffmpeg gmerlin-avdecoder gst-plugins-bad1.0 libquicktime liquidsoap lives ocaml-schroedinger vlc Except for the ocaml bindings, this should all be a matter of simply disabling the functionality. signature.asc Description: This is a digitally signed message part
Bug#843908: API/ABI change without corresponding soname change
Package: zeromq3 Version: 4.2.0-1 Severity: grave Hi, the symbol zpoller_ignore_interrupts was removed in 4.2.0 (as also mentioned in the release notes), and replaced by zpoller_set_nonstop. Unfortunately this didn't go together with a change of the soname, thus breaking all existing packages that currently link against zmq and use that symbol. According to the release notes there are also more symbols that were removed / replaced by something else, or even worse, signatures of functions changed while keeping the old function name. See https://github.com/zeromq/czmq/releases Sebastian signature.asc Description: This is a digitally signed message part
Bug#831909: gstreamer coredumps when playing wavs since the libavcodec upgrade
On Fri, 22 Jul 2016 13:27:09 +0300 Faidon Liambotis wrote: > I still don't exactly understand how H.264/VA-API are related when playing > just a .wav file, though... They are not, it's just that the initialization of this GStreamer plugin (the ffmpeg/libav one) is going through all the codecs that are provided and remembers what is available. > #0 0x76fc01c8 in __GI_raise (sig=sig@entry=6) > at ../sysdeps/unix/sysv/linux/raise.c:54 > #1 0x76fc164a in __GI_abort () at abort.c:89 > #2 0x7fffeda6260b in init_context_defaults (s=s@entry=0x70095720, > codec=codec@entry=0x7fffee3a8900 ) > at src/libavcodec/options.c:142 All the hardware based ffmpeg codecs should be disabled in gst-libav though. It of course still shouldn't crash like this, which seems like a problem in ffmpeg, but I'll fix gst-libav to ignore them all now. signature.asc Description: This is a digitally signed message part
Bug#831909: gstreamer coredumps when playing wavs since the libavcodec upgrade
On Wed, 20 Jul 2016 22:06:05 +0300 Faidon Liambotis wrote: > Stack trace of thread 4122: > #0 0x7fa47ae7f1c8 raise (libc.so.6) > #1 0x7fa47ae8064a abort (libc.so.6) > #2 0x7fa4719b8f5b n/a (libavcodec.so.57) > #3 0x7fa4719b9026 avcodec_alloc_context3 >(libavcodec.so.57) > #4 0x7fa473360540 n/a (libgstlibav.so) > #5 0x7fa473356e53 n/a (libgstlibav.so) > #6 0x7fa47b74b22d g_type_class_ref (libgobject-2.0.so.0) > #7 0x7fa47b9c8da4 gst_element_register >(libgstreamer-1.0.so.0) > #8 0x7fa4733575b3 n/a (libgstlibav.so) > #9 0x7fa473349e20 n/a (libgstlibav.so) > #10 0x7fa47b9ea537 n/a (libgstreamer-1.0.so.0) > #11 0x7fa47b9ec425 n/a (libgstreamer-1.0.so.0) > #12 0x7fa47b9ed12c gst_plugin_load_by_name >(libgstreamer-1.0.so.0) > #13 0x7fa47b9eda8d gst_plugin_feature_load >(libgstreamer-1.0.so.0) > #14 0x7fa47ba137e3 gst_type_find_factory_call_function >(libgstreamer-1.0.so.0) > #15 0x7fa479c48421 gst_type_find_helper_for_data >(libgstbase-1.0.so.0) > #16 0x7fa479c485a4 gst_type_find_helper_for_buffer >(libgstbase-1.0.so.0) > #17 0x7fa4799f446a n/a (libgstwavparse.so) > #18 0x7fa4799f4b47 n/a (libgstwavparse.so) > #19 0x7fa4799fabb1 n/a (libgstwavparse.so) > #20 0x7fa47ba0ee71 n/a (libgstreamer-1.0.so.0) > #21 0x7fa47b47b55e n/a (libglib-2.0.so.0) > #22 0x7fa47b47abc5 n/a (libglib-2.0.so.0) > #23 0x7fa47b1f4464 start_thread (libpthread.so.0) Thanks for the report. Can you install debug symbols for libavcodec57 and get another backtrace? Also what's the assertion you see on the terminal that causes the abort()? Do you have the same problem with gstreamer1.0-libav from experimental (version 1.9.1-1)? I can't reproduce this here with either 1.8.2-1 or 1.9.1-1 unfortunately. signature.asc Description: This is a digitally signed message part
Bug#825150: pitivi: hard dependency is unmet -- gstgtk
On Fr, 2016-05-27 at 01:39 +0200, Martin Hanson wrote: > > > > You have gstreamer1.0-plugins-bad from Debian Multimedia installed. > > Try > > with the official Debian packages instead, they contain the > > GStreamer > > GTK integration. > I am running with a clean and new Jessie installation, no multimedia > repos and I get the exact same error. > > I tried installing and running pitivi on another box that runs Debian > Stretch, same exact error, also no multimedia repo. What happens if you run "gst-inspect-1.0 gtksink"? gst-inspect-1.0 is in gstreamer1.0-tools Do you have /usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstgtksink.so? signature.asc Description: This is a digitally signed message part
Bug#825150: pitivi: hard dependency is unmet -- gstgtk
On Di, 2016-05-24 at 14:07 +0800, Nick Coleman wrote: > Package: pitivi > Version: 0.95-1+b1 > Severity: grave > Justification: renders package unusable > > Pitivi crashes on start with an unmet hard dependency, making the > package unusable. The error message is: > > - gstgtk not found on the system > [...] > ii gstreamer1.0-plugins-bad [gstreamer1.0-videosink] 1:1.8.1-dmo1 You have gstreamer1.0-plugins-bad from Debian Multimedia installed. Try with the official Debian packages instead, they contain the GStreamer GTK integration. signature.asc Description: This is a digitally signed message part
Bug#816587: shared-mime-info: FTBFS: LaTeX Error: File `ulem.sty' not found.
reassign 816587 docbook-utils reassign 817026 docbook-utils reassign 817027 docbook-utils forcemerge 816587 817026 817027 thanks On Do, 2016-03-03 at 10:45 +0200, Sebastian Dröge wrote: > On Do, 2016-03-03 at 08:36 +, Chris Lamb wrote: > > > > Source: shared-mime-info > > Version: 1.5-2 > > Severity: serious > > Justification: fails to build from source > > User: reproducible-bui...@lists.alioth.debian.org > > Usertags: ftbfs > > X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org > > > > Dear Maintainer, > > > > shared-mime-info fails to build from source in unstable/amd64: > Yes, for whatever reason texlive-generic-recommended is not > automatically pulled in anymore. Should check first if this was > intentional. docbook-utils' docbook2pdf needs ulem.sty from texlive-generic- recommended. At some point something in the texlive dependencies changed so it's not automatically pulled in anymore. Means that either that texlive change has to be reverted, or docbook- tools has to depend on texlive-generic-recommended. signature.asc Description: This is a digitally signed message part
Bug#816587: shared-mime-info: FTBFS: LaTeX Error: File `ulem.sty' not found.
On Do, 2016-03-03 at 08:36 +, Chris Lamb wrote: > Source: shared-mime-info > Version: 1.5-2 > Severity: serious > Justification: fails to build from source > User: reproducible-bui...@lists.alioth.debian.org > Usertags: ftbfs > X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org > > Dear Maintainer, > > shared-mime-info fails to build from source in unstable/amd64: Yes, for whatever reason texlive-generic-recommended is not automatically pulled in anymore. Should check first if this was intentional. signature.asc Description: This is a digitally signed message part
Bug#785924: [Freewx-maint] Bug#785924: wxwidgets3.0: Please update to GStreamer 1.x
On Mo, 2016-02-22 at 00:49 +1300, Olly Betts wrote: > > Sebastian Dröge wrote: > > How can I test the wxwidgets GStreamer integration? > You need to test via an application which uses it - something which > depends on the wx or wxpython media package. I think I've used > whyteboard for this before. > Thanks for looking at this. Ok, it all seems to work. I've uploaded this to DELAYED/1, just let me know if you want to do the upload yourself instead :) signature.asc Description: This is a digitally signed message part
Bug#785924: wxwidgets3.0: Please update to GStreamer 1.x
On So, 2016-02-21 at 12:29 +0200, Sebastian Dröge wrote: > On So, 2016-02-21 at 11:09 +0200, Sebastian Dröge wrote: > > On Di, 2015-11-10 at 20:28 +, Olly Betts wrote: > > > > > > I'll try to find time to test it. Also happy for someone else to > > > test > > > the amended patch and NMU if it works, but please keep me in the > > > loop to > > > avoid duplicating effort. > > > > > > (If someone does NMU, you could usefully drop `--enable-sdl` in > > > debian/rules to close #802770 - there's no corresponding BD so > > > this > > > doesn't affect the built result in a clean chroot). > > > > I'm looking into this now btw, will provide an updated patch some > > time later today or so. How can I test the wxwidgets GStreamer > > integration? > > Please see attached. This builds but I don't know how to test it. I also provided that patch upstream with some further information, but their bug tracker requires moderation of comments so it probably takes a while until it shows up there. signature.asc Description: This is a digitally signed message part
Bug#785924: wxwidgets3.0: Please update to GStreamer 1.x
On So, 2016-02-21 at 11:09 +0200, Sebastian Dröge wrote:
> On Di, 2015-11-10 at 20:28 +, Olly Betts wrote:
> >
> > I'll try to find time to test it. Also happy for someone else to
> > test
> > the amended patch and NMU if it works, but please keep me in the
> > loop to
> > avoid duplicating effort.
> >
> > (If someone does NMU, you could usefully drop `--enable-sdl` in
> > debian/rules to close #802770 - there's no corresponding BD so this
> > doesn't affect the built result in a clean chroot).
>
> I'm looking into this now btw, will provide an updated patch some time
> later today or so. How can I test the wxwidgets GStreamer integration?
Please see attached. This builds but I don't know how to test it.diff -Nru wxwidgets3.0-3.0.2+dfsg/debian/changelog wxwidgets3.0-3.0.2+dfsg/debian/changelog
--- wxwidgets3.0-3.0.2+dfsg/debian/changelog 2015-08-03 13:55:58.0 +0300
+++ wxwidgets3.0-3.0.2+dfsg/debian/changelog 2016-02-21 12:26:54.0 +0200
@@ -1,3 +1,16 @@
+wxwidgets3.0 (3.0.2+dfsg-1.3) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * debian/control.in,
+debian/rules,
+debian/patches/gst1.0.patch:
++ Port to GStreamer 1.x (Closes: #785924), patch based on the one from
+ http://trac.wxwidgets.org/ticket/14976 with a lot of changes.
+ * debian/control.in:
++ Remove obsolete build-depends on ESD and GConf.
+
+ -- Sebastian Dröge Sun, 21 Feb 2016 11:21:28 +0200
+
wxwidgets3.0 (3.0.2+dfsg-1.2) unstable; urgency=medium
* Non maintainer upload.
diff -Nru wxwidgets3.0-3.0.2+dfsg/debian/control wxwidgets3.0-3.0.2+dfsg/debian/control
--- wxwidgets3.0-3.0.2+dfsg/debian/control 2015-07-30 14:59:26.0 +0300
+++ wxwidgets3.0-3.0.2+dfsg/debian/control 2016-02-21 12:15:52.0 +0200
@@ -5,10 +5,10 @@
Build-Depends: debhelper (>= 9), gettext, libgtk2.0-dev,
g++ (>= 4:5.2),
zlib1g-dev, libjpeg-dev, libpng-dev, libtiff5-dev, libsm-dev,
- libgl1-mesa-dev | libgl-dev, libglu1-mesa-dev | libglu-dev, libesd0-dev,
- autotools-dev, libexpat1-dev, dpkg-dev (>= 1.16.1~),
- libxt-dev, libgstreamer-plugins-base0.10-dev, libgconf2-dev, libwebkitgtk-dev,
- libnotify-dev
+ libgl1-mesa-dev | libgl-dev, libglu1-mesa-dev | libglu-dev,
+ autotools-dev, autoconf, libexpat1-dev, dpkg-dev (>= 1.16.1~), libxt-dev,
+ libgstreamer1.0-dev, libgstreamer-plugins-base1.0-dev,
+ libwebkitgtk-dev, libnotify-dev
Maintainer: wxWidgets Maintainers
Uploaders: Olly Betts
Standards-Version: 3.9.6
@@ -129,7 +129,10 @@
Package: libwxgtk-media3.0-0v5
Architecture: any
Pre-Depends: ${misc:Pre-Depends}
-Depends: ${shlibs:Depends}, ${misc:Depends}
+Depends: ${shlibs:Depends}, ${misc:Depends},
+ gstreamer1.0-plugins-base,
+ gstreamer1.0-plugins-good,
+ gstreamer1.0-x
Multi-Arch: same
Breaks: libwxgtk-media3.0-0
Replaces: libwxgtk-media3.0-0
diff -Nru wxwidgets3.0-3.0.2+dfsg/debian/control.in wxwidgets3.0-3.0.2+dfsg/debian/control.in
--- wxwidgets3.0-3.0.2+dfsg/debian/control.in 2015-07-30 14:59:22.0 +0300
+++ wxwidgets3.0-3.0.2+dfsg/debian/control.in 2016-02-21 12:15:50.0 +0200
@@ -5,10 +5,10 @@
Build-Depends: debhelper (>= 9), gettext, libgtk2.0-dev,
g++ (>= 4:5.2),
zlib1g-dev, libjpeg-dev, libpng-dev, libtiff5-dev, libsm-dev,
- libgl1-mesa-dev | libgl-dev, libglu1-mesa-dev | libglu-dev, libesd0-dev,
- autotools-dev, libexpat1-dev, dpkg-dev (>= 1.16.1~),
- libxt-dev, libgstreamer-plugins-base0.10-dev, libgconf2-dev, libwebkitgtk-dev,
- libnotify-dev
+ libgl1-mesa-dev | libgl-dev, libglu1-mesa-dev | libglu-dev,
+ autotools-dev, autoconf, libexpat1-dev, dpkg-dev (>= 1.16.1~), libxt-dev,
+ libgstreamer1.0-dev, libgstreamer-plugins-base1.0-dev,
+ libwebkitgtk-dev, libnotify-dev
Maintainer: wxWidgets Maintainers
Uploaders: Olly Betts
Standards-Version: 3.9.6
@@ -129,7 +129,10 @@
Package: libwxgtk-media=SOV
Architecture: any
Pre-Depends: ${misc:Pre-Depends}
-Depends: ${shlibs:Depends}, ${misc:Depends}
+Depends: ${shlibs:Depends}, ${misc:Depends},
+ gstreamer1.0-plugins-base,
+ gstreamer1.0-plugins-good,
+ gstreamer1.0-x
Multi-Arch: same
Breaks: libwxgtk-media3.0-0
Replaces: libwxgtk-media3.0-0
diff -Nru wxwidgets3.0-3.0.2+dfsg/debian/patches/gst1.0.patch wxwidgets3.0-3.0.2+dfsg/debian/patches/gst1.0.patch
--- wxwidgets3.0-3.0.2+dfsg/debian/patches/gst1.0.patch 1970-01-01 02:00:00.0 +0200
+++ wxwidgets3.0-3.0.2+dfsg/debian/patches/gst1.0.patch 2016-02-21 11:48:12.0 +0200
@@ -0,0 +1,886 @@
+Index: wxwidgets3.0-3.0.2+dfsg/configure.in
+===
+--- wxwidgets3.0-3.0.2+dfsg.orig/configure.in
wxwidgets3.0-3.0.2+dfsg/configure.in
+@@ -7543,43 +7543,22 @@ if test "$wxUSE_MEDIACTRL" = "yes" -o "$
+ wxUSE_GSTREAMER="no"
+
+ dnl ---
+-
Bug#785924: wxwidgets3.0: Please update to GStreamer 1.x
On Di, 2015-11-10 at 20:28 +, Olly Betts wrote: > > I'll try to find time to test it. Also happy for someone else to test > the amended patch and NMU if it works, but please keep me in the loop to > avoid duplicating effort. > > (If someone does NMU, you could usefully drop `--enable-sdl` in > debian/rules to close #802770 - there's no corresponding BD so this > doesn't affect the built result in a clean chroot). I'm looking into this now btw, will provide an updated patch some time later today or so. How can I test the wxwidgets GStreamer integration? signature.asc Description: This is a digitally signed message part
Bug#788708: Bug#799632: iceweasel: SIGSEGV when playing videos via gstreamer
On So, 2015-12-06 at 12:17 +0100, Soeren D. Schulze wrote: > Am 06.12.2015 um 08:50 schrieb Sebastian Dröge: > > > Hello, > > > > > > it is not fixed, alas. The following SIGSEGV backtrace is with > > > gstreamer1.0-plugins-bad 1.6.1-1+b1 and iceweasel 38.4.0esr- > > > 1. Such > > > crashes are rarer, but they do occur: > > > > Hi, > > > > this is a different bug than the stack corruption related to the > > faad > > plugin though. It looks like broken error handling in iceweasel: > > https://github.com/mozilla/gecko-dev/blob/GECKO3840esr_2015102720_R > > ELBRANCH/dom/media/gstreamer/GStreamerReader.cpp#L1464 > > > > This line here should check if mapping actually succeeds. > > Apparently it > > doesn't (for whatever reason which might be another bug), as in the > > next stack frame all field in frame are 0. > > Right after sending the last message, I could reproduce the crash > without frames #0--#2, so the crash looks very similar to the one > that I reported initially (see below). > [...] That's the same crash :) How can you reproduce this? It never happened to me so far. Do you also get that with a newer version of iceweasel? signature.asc Description: This is a digitally signed message part
Bug#788708: Bug#799632: iceweasel: SIGSEGV when playing videos via gstreamer
On Sa, 2015-12-05 at 16:28 +0100, Soeren D. Schulze wrote: > Am 12.11.2015 um 15:02 schrieb Sebastian Dröge: > > On Do, 2015-11-12 at 14:41 +0100, Soeren D. Schulze wrote: > > > Hello, > > > > > > the problem does not seem to occur any more with > > > gstreamer1.0-plugins-bad 1.6.1-1+b1 and iceweasel 38.4.0esr-1. > > > > > > Do you have any specific packages for me to test? > > > > Just a normal jessie installation without installing things from > > other sources, including sid :) It is definitely fixed since gst- > > plugins-bad 1.5.X, it's just not clear if the actual bug also > > exists in jessie or not (and if it doesn't, the fix will also have > > no effect for people who mix their packages with ones from other > > sources). > > Hello, > > it is not fixed, alas. The following SIGSEGV backtrace is with > gstreamer1.0-plugins-bad 1.6.1-1+b1 and iceweasel 38.4.0esr-1. Such > crashes are rarer, but they do occur: Hi, this is a different bug than the stack corruption related to the faad plugin though. It looks like broken error handling in iceweasel: https://github.com/mozilla/gecko-dev/blob/GECKO3840esr_2015102720_RELBRANCH/dom/media/gstreamer/GStreamerReader.cpp#L1464 This line here should check if mapping actually succeeds. Apparently it doesn't (for whatever reason which might be another bug), as in the next stack frame all field in frame are 0. Do you have, by any chance, gstreamer1.0-vaapi installed? signature.asc Description: This is a digitally signed message part
Bug#788708: Bug#799632: iceweasel: SIGSEGV when playing videos via gstreamer
On Sa, 2015-11-21 at 17:06 +0100, Agustin Martin wrote: > 2015-11-14 15:25 GMT+01:00 Soeren D. Schulze >: > > I am not sure about those SIGPIPEs. They occured to me, too, but I > > could > > just press 'c' in gdb and continue using iceweasel until the > > SIGSEGV. On > > the other hand, they are apparently gone now in stretch. > > > > Could you press 'c' next time it happens, and wait for a SIGSEGV to > > occur? > > Hi, > > This time a SIGSEV did occur, please find attached backtrace Hi, this is a completely different crash than the one related to faad that was fixed in sid. Do you have a way to reproduce the crash you're observing here? signature.asc Description: This is a digitally signed message part
Bug#788708: Bug#799632: iceweasel: SIGSEGV when playing videos via gstreamer
On Do, 2015-11-12 at 15:35 +0100, Soeren D. Schulze wrote: > Am 12.11.2015 um 15:02 schrieb Sebastian Dröge: > > On Do, 2015-11-12 at 14:41 +0100, Soeren D. Schulze wrote: > > > Hello, > > > > > > the problem does not seem to occur any more with > > > gstreamer1.0-plugins-bad 1.6.1-1+b1 and iceweasel 38.4.0esr-1. > > > > > > Do you have any specific packages for me to test? > > > > Just a normal jessie installation without installing things from > > other > > sources, including sid :) It is definitely fixed since gst-plugins- > > bad > > 1.5.X, it's just not clear if the actual bug also exists in jessie > > or > > not (and if it doesn't, the fix will also have no effect for people > > who > > mix their packages with ones from other sources). > > I believe so. I have had symptomatically similar crashes on two > different jessie systems, but I had not installed debugging symbols, > and it's hard to reproduce those crashes at command. It should crash always more or less immediately when you visit a website with AAC audio. Vimeo for example :) > If there is code in jessie that causes stack corruption, it should be > fixed in any case in my opinion, regardless whether it causes crashes > or not. Is it clear whether the stack corruption implies a security > threat? The relevant upstream bug is https://bugzilla.gnome.org/show_bug.cgi?id=748571 The problem here is that the configure check for the faad version went wrong based on the specific compiler version. It's fairly trivial, if the release team agrees that we should get that into jessie I can do that in any case. It shouldn't have any negative side effects. signature.asc Description: This is a digitally signed message part
Bug#788708: Bug#799632: iceweasel: SIGSEGV when playing videos via gstreamer
On Do, 2015-11-12 at 14:41 +0100, Soeren D. Schulze wrote: > Hello, > > the problem does not seem to occur any more with > gstreamer1.0-plugins-bad 1.6.1-1+b1 and iceweasel 38.4.0esr-1. > > Do you have any specific packages for me to test? Just a normal jessie installation without installing things from other sources, including sid :) It is definitely fixed since gst-plugins-bad 1.5.X, it's just not clear if the actual bug also exists in jessie or not (and if it doesn't, the fix will also have no effect for people who mix their packages with ones from other sources). signature.asc Description: This is a digitally signed message part
Bug#788708: Bug#799632: iceweasel: SIGSEGV when playing videos via gstreamer
On Di, 2015-11-10 at 20:31 +0100, Agustin Martin wrote:
> On Mon, Sep 21, 2015 at 03:55:16AM +0200, Soeren D. Schulze wrote:
> > Package: iceweasel
> > Version: 38.2.1esr-1~deb8u1
> > Severity: important
> >
> > Approximately once every 10 hours of use, I experience a crash of
> > Iceweasel.
> > It seems to be correlated with playing videos via gstreamer with
> > the
> > libav/ffmpeg backend, but I have not yet found any reliable way to
> > reproduce
> > it.
> >
> > I have observed similar crashes like this on other Debian systems
> > with
> > earlier versions of Iceweasel, but I cannot tell if it is the same
> > bug
> > because I did not have a debugger running.
> >
> > Please see the full backtrace below. At a first glance, the
> > problem seems
> > to be in the GST_VIDEO_FRAME_COMP_DATA macro which ultimately calls
> > GST_VIDEO_FORMAT_INFO_DATA (defined in the gstreamer headers),
> > which in turn
> > dereferences frame->info->finfo. According to #1 in the backtrace,
> > finfo is
> > NULL, so I think this is what causes the crash.
> ...
>
> > {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype
> > = 0}}}
> > not_first_call =
> > pagesize_m1 =
> > sp =
> > freesize =
> > __PRETTY_FUNCTION__ = "start_thread"
> > #16 0x7707c06d in clone () at
> > ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
> > No locals.
> > (gdb)
>
> This seems to be similar to the backtrace reported in
> https://bugs.debian.org/797227, caused by the same problem
> as https://bugs.debian.org/788708 (cc'ed).
>
> Is this problem still hapenning with gstreamer1.0-plugins-bad 1.4.5-3
> or higher?
If someone can confirm that, I'll prepare a gst-plugins-bad1.0 update
for jessie with that patch. Just let me know :)
signature.asc
Description: This is a digitally signed message part
Bug#788708: iceweasel: GStreamer causes segmentation fault
On Mo, 2015-11-09 at 18:45 +0100, Agustin Martin wrote: > Hi, gstreamer plugins maintainers > > I have unarchived this bug report to add more info on it. Not yet > reopened it for jessie because I am not fully sure that is is the one > to blame. > > I am having some problems in jessie similar to those reported in > this > bug report, although they are not yet as reproducible. > > Using iceweasel=38.4.0esr-1~deb8u1 and > gstreamer1.0-plugins-bad+libgstreamer-plugins-bad1.0-0=1.4.4- > 2.1+b1 I have been finding some problems about iceweasel sudden > closure. I have build a personal gstreamer1.0-plugins-bad=1.4.4- > 2.1.0.0+amd1 package including the patch that fixed this problem and > it seemed to disappear. The reason why I am not yet reopening this > bug report for jessie is that after reverting to current jessie > versions (1.4.4-2.1(+b1)) I am not reproducing it, so I cannot > discard that there is something else involved. That seems weird. Do you happen to have a backtrace of one of these crashes still, ideally with debug symbols? > Adding this info here in case anyone else is finding this problem in > jessie. If so, a jessie point upload may be be useful. If jessie is indeed affected by this issue, we should backport the fix. Would be good to know :) signature.asc Description: This is a digitally signed message part
Bug#785924: wxwidgets3.0: Please update to GStreamer 1.x
On Sa, 2015-10-31 at 20:39 +, Olly Betts wrote: > On Sat, Oct 31, 2015 at 02:16:28PM +0100, Moritz Muehlenhoff wrote: > > On Thu, May 21, 2015 at 02:31:29PM +0300, Sebastian Dröge wrote: > > > Hi Olly, > > > > > > On Do, 2015-05-21 at 01:24 +0100, Olly Betts wrote: > > > > > > > But there's an upstream ticket about switching to gstreamer 1.0 > > > > with a > > > > recently added patch. I'd appreciate a quick review from > > > > someone who > > > > has more idea about gstreamer's API than I do if you have a few > > > > minutes > > > > (it's not a huge patch): > > > > > > > > http://trac.wxwidgets.org/attachment/ticket/14976/gst1.0.patch > > > > > > > > I can tell the configure part needs improving, at least to make > > > > it > > > > upstream-able, which makes me wonder about its general quality. > > > > > > wxGStreamerMediaBackend::QueryVideoSizeFromPad() probably leaks > > > the caps > > > now, you need to unref() them after usage. > > > > > > !gst_structure_has_name (gst_message_get_structure(message), > > > "prepare-window-handle")) > > > should be using > > > gst_is_video_overlay_prepare_window_handle_message() > > > > > > Otherwise seems ok if that is really enough to make things work. > > > Not > > > sure if more changes are needed elsewhere. > > > > what's the status? wxwidgets is now one of the two remaining > > packages > > blocking the removal of gstreamer 0.10 from stretch. > > Status is stalled, essentially. > > I gather from what slomo said that the current patch isn't suitable > for applying. The first remark is a minor memory leak, the second is just cleanup (and usage of the correct API) but at this time has no functional difference (but might in the future). The leak you can fix by adding a simple gst_caps_unref() for the caps in that function. Does the patch work otherwise? If so, just get it in after adding that one line mentioned above :) signature.asc Description: This is a digitally signed message part
Bug#785926: Bug#731122: Initial patch for GStreamer 1.0 / farstream 0.2 support
On Fr, 2015-10-16 at 10:05 +0300, Sebastian Dröge wrote: > On Sun, 4 Oct 2015 22:51:55 +0200 Bernhard Schmidt wrote: > > > > I can't do that, as > > > > - my DD application is still in progress > > - I certainly don't want to NMU a multi-binary package with a library > > and five-digit popcon count as first action > > > > However, if someone wants to, I have uploaded 2.10.11-1.1 to mentors > > > > http://mentors.debian.net/package/pidgin > > I'll take a look at this later today, thanks for preparing this! I > assume, considering what you wrote above, that you don't want to be > listed in the changelog at the bottom line then? Going to upload that in a bit now. But I noticed that Fedora has lots of other patches that would probably be useful to have for proper interoperability with other software, and various fixes: http://pkgs.fedoraproject.org/cgit/pidgin.git/tree/ Might make sense for Ari to merge at least some of these, they're all upstream but it doesn't look like there will be a new release anytime soon. signature.asc Description: This is a digitally signed message part
Bug#785926: Bug#731122: Initial patch for GStreamer 1.0 / farstream 0.2 support
On Sun, 4 Oct 2015 22:51:55 +0200 Bernhard Schmidt wrote: > > I can't do that, as > > - my DD application is still in progress > - I certainly don't want to NMU a multi-binary package with a library > and five-digit popcon count as first action > > However, if someone wants to, I have uploaded 2.10.11-1.1 to mentors > > http://mentors.debian.net/package/pidgin I'll take a look at this later today, thanks for preparing this! I assume, considering what you wrote above, that you don't want to be listed in the changelog at the bottom line then? > Additional notes: > - I have run-tested it, but I don't use multimedia I guess that's already better than having the package removed completely :) > - the NMU includes a change from Ari only found in the git-repo ... not > sure whether this should be included in the NMU The pulseaudio change makes sense > - the package has a lintian error, I'm not exactly sure whether this can > be uploaded at all without overriding it Things with lintian errors can be uploaded, also I assume this was there before already anyway? signature.asc Description: This is a digitally signed message part
Bug#800660: gnome-keyring: crashes iceweasel when logging into a password-protected website
On Fri, 02 Oct 2015 10:20:49 +0200 =?utf-8?q?Rapha=C3=ABl_Hertzog?= wrote: > Since I upgraded to gnome-keyring 3.18, I'm no longer able to login into > password-protected website with iceweasel. It just gets stuck and I have > to kill it. > > In the logs I see this: > > oct. 02 10:04:42 x230-buxy gnome-keyring-daemon[2195]: asked to register item > /org/freedesktop/secrets/collection/login/23, but it's already registered > oct. 02 10:05:06 x230-buxy gnome-session[2199]: ** (gnome-shell:2354): > CRITICAL **: remove_mnemonics: assertion 'label != NULL' failed > oct. 02 10:05:06 x230-buxy gnome-keyring-daemon[2195]: could not register > secret unlock prompt on session bus: Un objet est déjà exporté pour > l'interface « org.freedesktop.Secret.Prompt » en « > /org/freedesktop/secrets/prompt/p6 » > oct. 02 10:05:06 x230-buxy gnome-keyring-daemon[2195]: GLib-GIO: > g_dbus_interface_skeleton_unexport: assertion 'interface_->priv->connections > != NULL' failed Same here, without customized startup scripts and happens with dbus -user-session and without. signature.asc Description: This is a digitally signed message part
Bug#799677: pitivi: Incorrect depends, build-depends, and other issues
On Mon, 21 Sep 201509:27:23 -0400 Scott Kitterman wrote: > To start with, pitivi only builds against a single python3 version (the > default), not all versions, so it should build-dep on python3-dev vice > python3-all-dev. The python3-all-dev build-dep makes it appear on the list > of candidate packages for the python3.5 transition [1], which is should not. Thanks, will fix with next upload > That is, however, probably the most minor thing I noticed once I started > looking. > > In the depends, it should be python3:Depends vice python:Depends. Since the > python files are shipped in a private library location, you will have to > specify the location to dh_python3 (see man dh_python3, private dirs. > > The generated python3 depends should currently look like: > > python3 (<< 3.5), python3 (>= 3.4~) > > The manual python3 depends should be removed. I was not able to figure out > how to make this work, but I suspect it has to do with a linking issue in the > build. Ack > If you look at the i386 build log [2], it contains: > > dpkg-shlibdeps: warning: > debian/pitivi/usr/lib/i386-linux-gnu/pitivi/python/pitivi/timeline/renderer.so > contains an unresolvable reference to symbol PyList_GetItem: it's probably a > plugin > dpkg-shlibdeps: warning: 8 other similar warnings have been skipped (use -v > to see them all) > > PyList_GetItem is provided by python3.4, so this is not a plugin, it's a > missing link. My understanding is that you don't link Python modules against libpython, because the interpreter is already statically linked against libpython itself. > I suspect that between fixing that and the private dirs issue for dh_python3, > the depends issue should end up sorted. > > Finally, if you look at the file list for the binary (the same i386 build log > [2] provides a convenient place to look), there are multiple __pycache__ > directories in the binary that should not be there. Those should be generated > on the target system. Thanks! signature.asc Description: This is a digitally signed message part
Bug#799689: gst-python1.0: Missing python3 interpreter depends for python3-gst-1.0
On Mo, 2015-09-21 at 10:43 -0400, Scott Kitterman wrote: > The package uses python:Depends instead of python3:Depends for > python3-gst-1.0, so it does not end up with correct dependencies. > Fixing this gives a correct result. Please see the attached patch > which fixes this as well as cleaning up some obsolete provides while > I was at it. Thanks, I'll upload this together with the 1.6.0 release end of this week. Unless this is blocking you right now and needs to be resolved ASAP :) signature.asc Description: This is a digitally signed message part
Bug#785840: gcompris: Please update to GStreamer 1.x
On So, 2015-09-20 at 21:57 +0200, Yann Dirson wrote: > On Sun, Sep 20, 2015 at 08:36:06PM +0200, Sebastian Dröge wrote: > > On So, 2015-09-20 at 19:17 +0200, Sebastian Dröge wrote: > > > On So, 2015-09-20 at 15:33 +0200, Sebastian Dröge wrote: > > > > Hi again, > > > > > > > > I shortly looked at the code in git in gstreamer.c. Not a > > > > single > > > > change other than the build system and package dependencies > > > > should > > > > be > > > > necessary here. > > > > > > FWIW, I'll send you a patch soonish. Seem to have something > > > almost > > > working now. > > > > Patch attached, please upload or should I do an NMU? Whatever you > > prefer :) > > You seem pretty ready to upload, feel free :) > And thanks for your contribution ! It's on its way, while take a while with my slow internet connection Thanks for your fast response :) > > Untested except for compilation! > > Well, it should not be much more than just checking if you have sound > on startup :) Works. Is gcompris-qt still using GStreamer, or are they just going via QtMultimedia then (which for Debian would still be GStreamer)? signature.asc Description: This is a digitally signed message part
Bug#785840: gcompris: Please update to GStreamer 1.x
On So, 2015-09-20 at 19:17 +0200, Sebastian Dröge wrote:
> On So, 2015-09-20 at 15:33 +0200, Sebastian Dröge wrote:
> > Hi again,
> >
> > I shortly looked at the code in git in gstreamer.c. Not a single
> > change other than the build system and package dependencies should
> > be
> > necessary here.
>
> FWIW, I'll send you a patch soonish. Seem to have something almost
> working now.
Patch attached, please upload or should I do an NMU? Whatever you
prefer :)
Untested except for compilation!diff -Nru gcompris-15.02/debian/changelog gcompris-15.02/debian/changelog
--- gcompris-15.02/debian/changelog 2015-05-05 22:57:06.0 +0200
+++ gcompris-15.02/debian/changelog 2015-09-20 19:51:19.0 +0200
@@ -1,3 +1,10 @@
+gcompris (15.02-1.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Update to GStreamer 1.0 (Closes: #785840).
+
+ -- Sebastian Dröge Sun, 20 Sep 2015 19:09:08 +0200
+
gcompris (15.02-1) unstable; urgency=medium
* New upstream release.
diff -Nru gcompris-15.02/debian/control gcompris-15.02/debian/control
--- gcompris-15.02/debian/control 2014-12-30 18:30:43.0 +0100
+++ gcompris-15.02/debian/control 2015-09-20 20:18:51.0 +0200
@@ -3,14 +3,14 @@
Priority: optional
Maintainer: Yann Dirson
Homepage: http://gcompris.net/
-Build-Depends: debhelper (>= 9), autotools-dev, dh-buildinfo, dpkg-dev (>= 1.13.19), libxml2-dev, python-dev, python-gtk2-dev, libxml-parser-perl, libxrandr-dev, libxxf86vm-dev, libsqlite3-dev, libgtk2.0-dev (>= 2.4.0), libgstreamer0.10-dev, intltool, librsvg2-dev, python-cairo-dev
+Build-Depends: debhelper (>= 9), dh-autoreconf, autoconf, automake, libtool, autotools-dev, gnome-common, dh-buildinfo, dpkg-dev (>= 1.13.19), libxml2-dev, python-dev, python-gtk2-dev, libxml-parser-perl, libxrandr-dev, libxxf86vm-dev, libsqlite3-dev, libgtk2.0-dev (>= 2.4.0), libgstreamer1.0-dev, intltool, librsvg2-dev, python-cairo-dev
Standards-Version: 3.9.3
Vcs-git: git://anonscm.debian.org/collab-maint/gcompris.git
Vcs-browser: http://anonscm.debian.org/gitweb/?p=collab-maint/gcompris.git;a=summary
Package: gcompris
Architecture: any
-Depends: gcompris-data (= ${source:Version}), ${shlibs:Depends}, ${python:Depends}, python-pysqlite2, python-gtk2, gstreamer0.10-alsa | gstreamer0.10-audiosink, gstreamer0.10-plugins-base, gstreamer0.10-plugins-good, librsvg2-common (>= 2.18), python-cairo, ${misc:Depends}
+Depends: gcompris-data (= ${source:Version}), ${shlibs:Depends}, ${python:Depends}, python-pysqlite2, python-gtk2, gstreamer1.0-alsa | gstreamer1.0-audiosink, gstreamer1.0-plugins-base, gstreamer1.0-plugins-good, librsvg2-common (>= 2.18), python-cairo, ${misc:Depends}
Suggests: gnucap, tuxpaint
Replaces: gcompris-data (<< 8.4.1)
Description: Educational games for small children
diff -Nru gcompris-15.02/debian/patches/01_gstreamer-1.0.patch gcompris-15.02/debian/patches/01_gstreamer-1.0.patch
--- gcompris-15.02/debian/patches/01_gstreamer-1.0.patch 1970-01-01 01:00:00.0 +0100
+++ gcompris-15.02/debian/patches/01_gstreamer-1.0.patch 2015-09-20 20:28:27.0 +0200
@@ -0,0 +1,11 @@
+--- gcompris-15.02.orig/configure.ac
gcompris-15.02/configure.ac
+@@ -389,7 +389,7 @@ if test x$with_sdlmixer = xyes; then
+ AUDIO_LIBS="$AUDIO_LIBS -lSDL_mixer"
+ else
+ dnl Default is gstreamer
+- PKG_CHECK_MODULES(AUDIO, gstreamer-0.10,, AC_MSG_ERROR([*** GSTREAMER not found!]))
++ PKG_CHECK_MODULES(AUDIO, gstreamer-1.0 gmodule-no-export-2.0,, AC_MSG_ERROR([*** GSTREAMER not found!]))
+ AC_DEFINE([USE_GSTREAMER], 1,[gstreamer is enabled])
+ fi
+ AC_SUBST(AUDIO_CFLAGS)
diff -Nru gcompris-15.02/debian/patches/series gcompris-15.02/debian/patches/series
--- gcompris-15.02/debian/patches/series 2014-12-30 18:12:20.0 +0100
+++ gcompris-15.02/debian/patches/series 2015-09-20 19:10:46.0 +0200
@@ -0,0 +1 @@
+01_gstreamer-1.0.patch
diff -Nru gcompris-15.02/debian/rules gcompris-15.02/debian/rules
--- gcompris-15.02/debian/rules 2014-09-06 12:32:52.0 +0200
+++ gcompris-15.02/debian/rules 2015-09-20 19:09:31.0 +0200
@@ -10,7 +10,7 @@
#export DH_VERBOSE=1
%:
- dh $@ --with autotools_dev --with python2
+ dh $@ --with autoreconf,autotools_dev --with python2
SOUNDLANGS=$(shell grep '^Package: gcompris-sound-' debian/control | cut -d- -f3)
signature.asc
Description: This is a digitally signed message part
Bug#785840: gcompris: Please update to GStreamer 1.x
On So, 2015-09-20 at 15:33 +0200, Sebastian Dröge wrote: > Hi again, > > I shortly looked at the code in git in gstreamer.c. Not a single > change other than the build system and package dependencies should be > necessary here. FWIW, I'll send you a patch soonish. Seem to have something almost working now. signature.asc Description: This is a digitally signed message part
Bug#785840: gcompris: Please update to GStreamer 1.x
Hi again, I shortly looked at the code in git in gstreamer.c. Not a single change other than the build system and package dependencies should be necessary here.
Bug#785840: gcompris: Please update to GStreamer 1.x
Hi, I forwarded this upstream a while ago without any response. Is gcompris still actively developed? https://bugzilla.gnome.org/show_bug.cgi?id=747949 Basically, replace the 0.10 build dependencies with 1.0. Then make things compile and work again. See this small porting guide here http://cgit.freedesktop.org/gstreamer/gstreamer/tree/docs/random/porting-to-1.0.txt If you have any further questions please ask :) If you can point me to the code that uses gstreamer, I can also take a short look.
Bug#799174: Should not be part of next release
Package: liboil Severity: serious Tags: sid stretch liboil should not be part of the next release and should be removed, see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=792121 for the reasoning. Only one package is holding it back right now. signature.asc Description: This is a digitally signed message part
Bug#793628: Please remove unused build-dependency on liboil0.3-dev
On Sat, 25 Jul 2015 21:31:38 +0300 Sebastian =?ISO-8859-1?Q?Dr=F6ge?= wrote: > Package: psimedia > Severity: important > > Hi, > > please remove the build-dependency on liboil0.3-dev. It's apparently > not needed anymore as there is no binary dependency on the > corresponding library package, and liboil is planned to be removed as > soon as possible. > > If you still need something like liboil, it is superseded by orc since > a few years. Making this bug RC-critical now as we really shouldn't ship liboil in the next release and psimedia is the only package preventing it from being removed. Please upload a new version as soon as possible. signature.asc Description: This is a digitally signed message part
Bug#797227: segfault - gst_memory_unmap, libgstreamer
On Mi, 2015-09-02 at 17:32 +0900, Changwoo Ryu wrote: > Yes, I just have tested the patch on faad plugin at the GNOME > bugzilla 748571. And it fixes the problem. Thanks for testing, question is if I should upload a new package with the fix to unstable or we just wait until 1.6.0 is released... which should happen in the next week or two. signature.asc Description: This is a digitally signed message part
Bug#797227: segfault - gst_memory_unmap, libgstreamer
On Di, 2015-09-01 at 11:28 +0300, Sebastian Dröge wrote: > On Di, 2015-09-01 at 10:25 +0200, Vincent Lefevre wrote: > > On 2015-09-01 11:07:28 +0300, Sebastian Dröge wrote: > > > The gcc 5 transition might've broken something related to > > > iceweasel, > > > which is written in C++ and depends a lot on C++ libraries. Which > > > > > > then > > > might result in the invalid memory accesses mentioned above. > > > > > > But GStreamer and dependencies in use here are plain C, so are > > > unaffected by that transition. Same for GTK. > > > > No, GStreamer is linked against libpcre: > > GLib is linked against pcre, yes. But nothing there is actually using > it, and even if it was you would see something blowing up with regex > handling instead :) > > > > I think there are problems somewhere in iceweasel in the way it > > > is > > > using GTK, which is independent of the gcc 5 transition. And > > > which > > > might or might not be the reason for the crash. > > > > I would tend to say that the effects of these GTK problems are only > > local. If they yield more global memory corruption due to specific > > remote contents (e.g. a video), then this is an important security > > issue. > > Who knows? It's poking at memory that was freed already and things > like that, which could cause random crashes at a later time. The crash is most likely this bug here: https://bugzilla.gnome.org/show_bug.cgi?id=748571 That would also explain why it doesn't crash with 1.5.90. signature.asc Description: This is a digitally signed message part
Bug#797227: segfault - gst_memory_unmap, libgstreamer
On Di, 2015-09-01 at 10:25 +0200, Vincent Lefevre wrote: > On 2015-09-01 11:07:28 +0300, Sebastian Dröge wrote: > > The gcc 5 transition might've broken something related to > > iceweasel, > > which is written in C++ and depends a lot on C++ libraries. Which > > then > > might result in the invalid memory accesses mentioned above. > > > > But GStreamer and dependencies in use here are plain C, so are > > unaffected by that transition. Same for GTK. > > No, GStreamer is linked against libpcre: GLib is linked against pcre, yes. But nothing there is actually using it, and even if it was you would see something blowing up with regex handling instead :) > > I think there are problems somewhere in iceweasel in the way it is > > using GTK, which is independent of the gcc 5 transition. And which > > might or might not be the reason for the crash. > > I would tend to say that the effects of these GTK problems are only > local. If they yield more global memory corruption due to specific > remote contents (e.g. a video), then this is an important security > issue. Who knows? It's poking at memory that was freed already and things like that, which could cause random crashes at a later time. signature.asc Description: This is a digitally signed message part
Bug#797227: segfault - gst_memory_unmap, libgstreamer
Hi, On Mo, 2015-08-31 at 18:05 +0100, jnqnfe wrote: > > > Interesting... that doesn't make any sense unless something > > corrupted the stack :) Can you also run in valgrind with --track > > -origins=yes and provide the log? > > Sure. Just fyi, because loading iceweasel after a crash results in a > state where it asks whether or not to try to restore my tabs, I > reverted back to gst v1.5.90, allowing me to get a clean restore then > shutdown of iceweasel, then I installed the older version again and > ran valgrind. I am not actually familiar with valgrind at all > currently, if this is loading iceweasel in a VM environment, is it > actually loading my iceweasel profile? If not, then is there any use > to this? It is running the application like it would be running without valgrind, so it should use your profile. But it runs in some kind of VM to catch invalid memory accesses and things like that, so will be very slow. With this log it doesn't look like you got iceweasel to crash. Was it just not possible to crash it? I also forgot to mention that you should set G_SLICE=always-malloc in the environment before running valgrind. So basically you would do G_SLICE=always-malloc valgrind --track-origins=yes iceweasel and then go to the vimeo website where stuff was crashing and try to make it crash :) What is interesting in your log so far is that there are lots of invalid memory accesses around GTK. I'm not surprised at all if there are random crashes with all that code poking at random memory areas it shouldn't :) These invalid memory accesses seem to be iceweasel's fault, either in the JavaScript engine or elsewhere. > Do you think there is anything in the fact that we have gst-base > libraries @ version 1.4.5-2 (built 110 days ago!) interacting with > gst -bad libraries @ version 1.4.5-2+b2 (built 3 days ago) in this > troublesome stack trace. We're going through a major transition to > GCC5 right now (as I'm sure you know very well), which involves ABI > breakages. Could there perhaps be a ABI breakage issue between these > two libraries, considering one has been recently rebuilt, but not the > other?? The gcc 5 transition might've broken something related to iceweasel, which is written in C++ and depends a lot on C++ libraries. Which then might result in the invalid memory accesses mentioned above. But GStreamer and dependencies in use here are plain C, so are unaffected by that transition. Same for GTK. I think there are problems somewhere in iceweasel in the way it is using GTK, which is independent of the gcc 5 transition. And which might or might not be the reason for the crash. signature.asc Description: This is a digitally signed message part
Bug#797227: segfault - gst_memory_unmap, libgstreamer
Hi, On Mo, 2015-08-31 at 16:41 +0100, jnqnfe wrote: > On Mon, 2015-08-31 at 17:36 +0300, Sebastian Dröge wrote: > > On Mo, 2015-08-31 at 15:29 +0100, jnqnfe wrote: > > > > > > > Can someone who is still able to reproduce this with 1.5.90 > > > > from > > > > experimental also install debug symbols for libc6, libglib2.0 > > > > -0, > > > > all the GStreamer packages and then > > > > a) run with valgrind --track-origins=yes > > > > b) get a new backtrace with gdb? > > > > > > > > Thanks! > > > > > > I do not believe anyone has reported being able to reproduce the > > > issue with 1.5.90 packages. > > > > > > Do you want me to revert to the troublesome packages and get a > > > more > > > complete bt for you? > > > > That would be great, yes. Thanks :) > > Ok, pasted below! (full bt further down) > > #0 0x7fff97f50ff0 in gst_memory_unmap (mem=0x7fff, > info=info@entry=0x7fff87867980) at gstmemory.c:339 > #1 0x7fff97f26f76 in gst_buffer_unmap (buffer=, > info=0x7fff87867980) at gstbuffer.c:1622 > #2 0x7fff85442294 in gst_faad_set_format (dec=0x7fffc3399aa0 > [GstFaad], caps=) at gstfaad.c:326 > [...] Interesting... that doesn't make any sense unless something corrupted the stack :) Can you also run in valgrind with --track-origins=yes and provide the log? signature.asc Description: This is a digitally signed message part
Bug#797227: segfault - gst_memory_unmap, libgstreamer
On Mo, 2015-08-31 at 15:29 +0100, jnqnfe wrote: > > > Can someone who is still able to reproduce this with 1.5.90 from > > experimental also install debug symbols for libc6, libglib2.0-0, > > all the GStreamer packages and then > > a) run with valgrind --track-origins=yes > > b) get a new backtrace with gdb? > > > > Thanks! > > I do not believe anyone has reported being able to reproduce the > issue with 1.5.90 packages. > > Do you want me to revert to the troublesome packages and get a more > complete bt for you? That would be great, yes. Thanks :) signature.asc Description: This is a digitally signed message part
Bug#797227: segfault - gst_memory_unmap, libgstreamer
Hi, On Sun, 30 Aug 2015 00:04:02 +0100 jnqnfe wrote: > Upgrading to gstreamer1.0-plugins-bad from experimental as someone > suggested resulted in the following package changes: > > The following NEW packages will be installed: > [...] > Iceweasel indeed no longer crashes now. Running in gdb I instead get > a SIGPIPE failure. Can you get a backtrace of that SIGPIPE? And without running in gdb, everything works fine for you now? The vimeo link, https://vimeo.com/55640554, pasted in this bug report earlier here does not cause any crashes or anything for me, it just works fine. Can someone who is still able to reproduce this with 1.5.90 from experimental also install debug symbols for libc6, libglib2.0-0, all the GStreamer packages and then a) run with valgrind --track-origins=yes b) get a new backtrace with gdb? Thanks! signature.asc Description: This is a digitally signed message part
Bug#785916: landell: Please update to GStreamer 1.x
On Fr, 2015-08-21 at 00:11 +0200, Andreas Cadhalpun wrote: > > If you need any help with porting or have further questions, please > > feel free to also contact me privately. > > I'm also going to request the removal of gstreamer0.10-ffmpeg, > since it is the last reverse-dependency of src:libpostproc > and I want to request it's removal. > I hope you don't mind. Please go ahead, I didn't request removal of that one yet because I wanted to have all GStreamer 0.10 packages go away together but it doesn't really matter. Thanks! > I think gstreamer-hplugins can also be removed, because landell > is it's only reverse-dependency. > But I have no immediate interest in it's removal, so I leave > that to someone else. Please request removal of that one while you're at it, there's no point in keeping that if landell is removed. signature.asc Description: This is a digitally signed message part
Bug#767423: tracker-extract SIGSEGV
Hi, can you get a backtrace of the crash with the following packages installed? libglib2.0-0-dbg libgstreamer1.0-0-dbg gstreamer1.0-plugins-base-dbg gstreamer1.0-plugins-good-dbg gstreamer1.0-plugins-bad-dbg gstreamer1.0 -plugins-ugly-dbg gstreamer1.0-libav-dbg Also please check if the problem still exists with the GStreamer packages from experimental. The backtrace you provided is not really that helpful, but it could be a problem that is fixed since a while already related to liba52 (and not libav). Thanks! signature.asc Description: This is a digitally signed message part
Bug#788601: pitivi: segfaults on start, 100% of the time
On Mo, 2015-06-22 at 10:28 +0200, Open BSD wrote: > I'm not sure how to do that, i run jessie with verion 0.93-4.2 and > there's no newer version in jessie backports? > > I did download the universal bundle (0.94) from the pitivi website > but that includes all the dependencies and i think, as such, runs > fine. I guess that means 0.94 in whatever variant ever is not affected, and it's only something wrong in jessie. But probably also not for everybody, otherwise there would've been more complaints before. So we have to find the reason why it happens for you but not for others. I should set up a jessie install some time in the next days. signature.asc Description: This is a digitally signed message part
Bug#788601: pitivi: segfaults on start, 100% of the time
On Thu, 18 Jun 2015 12:45:00 +0200 Open BSD < gulpenergladia...@gmail.com> wrote: > this might be the same thing as in #732813 but i haven't tried it with > another version. Hi, not too useful backtrace of the crash unfortunately but that looks like a problem somewhere between python-gi, GDK/GTK and X11. And also something looks very wrong with the Clutter bindings here. Doesn't look to me like a Pitivi problem. Can you still reproduce this with version 0.94 though? signature.asc Description: This is a digitally signed message part
Bug#788601: pitivi: segfaults on start, 100% of the time
Hi, On Fr, 2015-06-12 at 23:11 -0500, John Goerzen wrote: > Package: pitivi > Version: 0.93-4.2 > Severity: grave > Justification: renders package unusable > > It just doesn't even start: > > > (pitivi:26977): Clutter-WARNING **: clutter_x11_set_use_argb_visual() > can only be used before calling clutter_init() > > (pitivi:26977): Clutter-WARNING **: clutter_x11_set_display() can > only > be used before calling clutter_init() > > (pitivi:26977): Clutter-WARNING **: > clutter_x11_disable_event_retrieval() can only be used before calling > clutter_init() > > (pitivi:26977): Clutter-WARNING **: clutter_disable_accessibility() > can > only be called before initializing Clutter. > Missing soft dependency: > - pycanberra not found on the system > -> enables sound notifications when rendering is complete > Missing soft dependency: > - GnomeDesktop not found on the system > -> file thumbnails provided by GNOME's thumbnailers > Segmentation fault Can you run pitivi in gdb and get a backtrace, ideally after installing the relevant debug packages for whatever appears in the backtrace? Thanks! signature.asc Description: This is a digitally signed message part
Bug#777024: gst segfault
On Fr, 2015-02-13 at 15:14 -0500, Michael Gilbert wrote: > control: tag -1 pending > > Hi, > > I've uploaded an nmu fixing this issue to delayed/2. Please let me > know if I should delay longer. thanks for the NMU! signature.asc Description: This is a digitally signed message part
Bug#769941: libgstreamer-plugins-base1.0-0: Iceweasel crashes with "gst_app_src_set_size: assertion 'GST_IS_APP_SRC (appsrc)' failed"
On Mi, 2014-12-17 at 09:35 +0100, webmbackslash wrote: > Hi, i have this bug too. > Attached is the valgrind output and it ended for me loading iceweasel > for a few moments and showing "killed". > This is the command i used: > valgrind --track-origins=yes --trace-children=yes --leak-check=full > iceweasel Hi, thanks for the valgrind log, but I can see nothing there from the actual crash. It's just a few memory leaks and processes exiting normally. For the actual bug here, I suspect some reference counting problem somewhere inside iceweasel but hard to locate it like this. Especially as this crash never happened to me so far signature.asc Description: This is a digitally signed message part
Bug#769941: libgstreamer-plugins-base1.0-0: Iceweasel crashes with "gst_app_src_set_size: assertion 'GST_IS_APP_SRC (appsrc)' failed"
On Di, 2014-11-18 at 11:37 +, George B. wrote: > On 18/11/14 09:22, Sebastian Dröge wrote: > > I assume it first started to appear when > > upgrading from 1.4.3 to 1.4.4 yesterday? > > I noticed it with GMail yesterday, but I haven't used that for a long time (I > usually connect via Icedove). > > I did note a crash at some point last week on some other random website - > that time I just ignored it, but it is possible it was related. > > > Can you always reproduce it > > when logging in on GMail? Which version of iceweasel are you using? > > It does not crash for me unfortunately. > > I can always reproduce it, providing I have media.gstreamer.enabled = true in > about:config. If set to false false - no crash. > > Iceweasel version is 33.1 (from experimental) > > > If you can always reproduce it, could you run iceweasel in valgrind > > (don't forget to install valgrind-dbg)? Set G_SLICE=always-malloc in the > > environment and run valgrind with --track-origins=yes and > > --trace-children=yes > > Unfortunately valgrind never gets to fully load the login page (exits with > "Killed"). I used: > > valgrind --track-origins=yes --trace-children=yes --error-limit=no iceweasel > -safe-mode > > I attach the STDERR log, but I'm not sure how useful that will be since there > is no mention of gstreamer there. Not very useful :) But thanks! Can you check if the crash goes away if you downgrade some of the GStreamer packages to 1.4.3, and if so which one makes the difference? signature.asc Description: This is a digitally signed message part
Bug#769941: libgstreamer-plugins-base1.0-0: Iceweasel crashes with "gst_app_src_set_size: assertion 'GST_IS_APP_SRC (appsrc)' failed"
On Mo, 2014-11-17 at 19:13 +, George B. wrote: > Package: libgstreamer-plugins-base1.0-0 > Version: 1.4.4-2 > Severity: critical > Justification: breaks unrelated software > > Hello, > > Iceweasel has started crashing when I try and login into Google Mail. > Looking at the backtrace it appears to be caused by libgstreamer, so > filing a bug against this package (AFAIK this particular package is > where those functions came from). > > Apologies if this was supposed to filed against a different package - > feel free to re-assign in that case. > [...] Hi, thanks for reporting this. I assume it first started to appear when upgrading from 1.4.3 to 1.4.4 yesterday? Can you always reproduce it when logging in on GMail? Which version of iceweasel are you using? It does not crash for me unfortunately. If you can always reproduce it, could you run iceweasel in valgrind (don't forget to install valgrind-dbg)? Set G_SLICE=always-malloc in the environment and run valgrind with --track-origins=yes and --trace-children=yes This looks like either stack corruption somewhere, or something in iceweasel released objects that it is still going to use. I'm not aware of any change from 1.4.3 to 1.4.4 that could be related to this unfortunately. signature.asc Description: This is a digitally signed message part
Bug#761019: gstreamer1.0 nmu
On So, 2014-11-02 at 12:03 +0100, Laurent Bigonville wrote: > Le Sun, 02 Nov 2014 11:35:21 +0100, > Sebastian Dröge a écrit : > > > On So, 2014-11-02 at 10:41 +0100, Laurent Bigonville wrote: > > > On Sun, 2 Nov 2014 00:52:23 -0400 Michael Gilbert > > > wrote: > > > Hello, > > > > > > > Hi, I've uploaded an nmu fixing this issue. Please see attached. > > > > > > Well this is certainly a solution, not the solution IMHO. > > > > > > The dependencies are usually calculated by dh_girepository and it's > > > not happening here some some reasons. debian/rules is mangling the > > > shlibs file, I guess this is the reason. > > > > Yeah, I was looking into this a bit and couldn't find the reason for > > dh_girepository not picking it up... but also didn't want to do this > > workaround solution as there seems to be an underlying problem > > somewhere. > > > > As we're near a release I guess this workaround is fine, but we should > > keep this bug open nonetheless. > > > > Same bug is in gst-plugins-base1.0 btw. Feel free to NMU that one the > > same way too, but also keep that bug open. > > The reason seems to be the dummy shlibs.local. dh_girepository is > called twice, the 1st time (explicitly from the debian/rules) before > the this dummy shlibs.local is created and a 2nd time (cdbs is doing > that) after the shlibs.local has been created. Only the result from > the 2nd call is used. > > So my question is why is this dummy shlibs.local file created during the > build? We could either remove this completely or move the call to > dh_girepository to the end of the common-binary-predeb-arch target > (after the "rm"). Just tried with both solution and they all seems to > work. I have no idea :) It was probably a workaround for something many years ago and IIRC this was already there before I took over the packages. It should be safe to remove if the results are the same. Will upload new packages of gstreamer1.0 and gst-plugins-base1.0 tomorrow unless someone else wants to do it before Thanks! signature.asc Description: This is a digitally signed message part
Bug#761019: gstreamer1.0 nmu
On So, 2014-11-02 at 10:41 +0100, Laurent Bigonville wrote: > On Sun, 2 Nov 2014 00:52:23 -0400 Michael Gilbert > wrote: > Hello, > > > Hi, I've uploaded an nmu fixing this issue. Please see attached. > > Well this is certainly a solution, not the solution IMHO. > > The dependencies are usually calculated by dh_girepository and it's not > happening here some some reasons. debian/rules is mangling the shlibs > file, I guess this is the reason. Yeah, I was looking into this a bit and couldn't find the reason for dh_girepository not picking it up... but also didn't want to do this workaround solution as there seems to be an underlying problem somewhere. As we're near a release I guess this workaround is fine, but we should keep this bug open nonetheless. Same bug is in gst-plugins-base1.0 btw. Feel free to NMU that one the same way too, but also keep that bug open. signature.asc Description: This is a digitally signed message part
Bug#764133: librtmp-dev misses dependency on libgnutls-dev and zlib1g-dev
On So, 2014-10-05 at 20:29 +0300, Sebastian Dröge wrote:
> Package: librtmp-dev
> Version: 2.4+20131018.git79459a2-4
> Severity: serious
>
> Hi,
>
> librtmp-dev should have a dependency on libgnutls-dev and zlib1g-dev
> according to the pkg-config file:
> [...]
> Requires.private: gnutls,hogweed,nettle
> Libs: -L${libdir} -lrtmp -lz -lgmp
> [...]
>
> Without this packages build-depending on librtmp-dev will fail to link
> unless they also (indirectly) build-depend on the other packages
> already.
Actually libgnutls28-dev as libgnutls-dev is removed and replaced by
that.
signature.asc
Description: This is a digitally signed message part
Bug#764133: librtmp-dev misses dependency on libgnutls-dev and zlib1g-dev
Package: librtmp-dev
Version: 2.4+20131018.git79459a2-4
Severity: serious
Hi,
librtmp-dev should have a dependency on libgnutls-dev and zlib1g-dev
according to the pkg-config file:
[...]
Requires.private: gnutls,hogweed,nettle
Libs: -L${libdir} -lrtmp -lz -lgmp
[...]
Without this packages build-depending on librtmp-dev will fail to link
unless they also (indirectly) build-depend on the other packages
already.
signature.asc
Description: This is a digitally signed message part
Bug#764100: gst-plugins-bad1.0: build-depends on libgnutls-dev
On So, 2014-10-05 at 14:57 +0200, Andreas Metzler wrote: > Package: gst-plugins-bad1.0 > Version: 1.4.3-1 > Severity: serious > Tags: patch > Justification: fails to build from source (but built successfully in the past) > User: ametz...@debian.org > Usertags: gnutls3 > > gst-plugins-bad1.0 build-depends on libgnutls-dev which is > - scheduled for removal > - and (somehow related) uninstallable. > > The b-d therefore makes the package FTBFS (uninstallable b-d). Please > update it to libgnutls28-dev instead. Hi, actually gst-plugins-bad1.0 does not depend on gnutls anymore and just uses nettle directly for crypto stuff. I'll upload a new version without the build-dependency soonish. signature.asc Description: This is a digitally signed message part
Bug#763433: Color format emulation breaks GStreamer's V4L2 support since 1.4.0
Package: libv4l-0 Version: 1.4.0-1 Severity: serious Hi, since version 1.4.0 the color format emulation in libv4l breaks GStreamer's v4l2 support. See this bug report for more details: https://bugzilla.gnome.org/show_bug.cgi?id=737521 In specific, this commit breaks it: http://git.linuxtv.org/cgit.cgi/v4l-utils.git/commit/?id=10213c975afdfcc90aa7de39e66c40cd7e8a57f7 This was also reported to the LinuxTV mailing list apparently. Older versions for libv4l were not affected AFAIK. signature.asc Description: This is a digitally signed message part
Bug#732680: insanity is no longer maintained upstream
Package: gst-qa-system Severity: serious Hi, please get the insanity/gst-qa-system package removed from Debian. It is no longer maintained upstream since years and there never was a release. This was mostly an experiment if such an approach can lead to useful results or not, and it failed. This should've never been in Debian at all. Best regards, Sebastian signature.asc Description: This is a digitally signed message part
