Bug#1019047: O: gst123 -- GStreamer based command line media player

[Sebastian Dröge]

Package: wnpp
Severity: normal
Control: affects -1 src:gst123

I intend to orphan the gst123 package.

The package description is:
 The program gst123 is designed to be a more flexible command line player in
 the spirit of ogg123 and mpg123, based on GStreamer. It plays all file formats
 supported by GStreamer, so if you have audio/video collections which contain
 different file formats, like flac, ogg and mp3, you can use gst123 to play all
 your audio/video files.

Bug#1019046: O: buzztrax -- Modular music composer

[Sebastian Dröge]

Package: wnpp
Severity: normal
Control: affects -1 src:buzztrax

I intend to orphan the buzztrax package.

The package description is:
 Buzztrax aims to be a music studio that allows one to compose songs using
 only a computer with a soundcard. If you’ve used tracker programs like
 FastTracker, Impulse Tracker, or the original AMIGA SoundTracker, that will
 give you an idea of how one can sequence music in Buzztrax. The Buzztrax
 editor uses a similar concept, where a song consists of a sequence with
 tracks and in each track one uses patterns with events (musical notes and
 control changes). In contrast to other Tracker programs, tracks are not
 simply sample players: a user can make a song using an arrangement of virtual
 audio plugins that are linked together to create different effects. Each of
 these machines can be controlled realtime or via patterns in the sequencer.

Bug#1018070: O: pitivi -- non-linear audio/video editor using GStreamer

[Sebastian Dröge]

Package: wnpp
Severity: normal
Control: affects -1 src:pitivi

I intend to orphan the pitivi package.

The package description is:
 GStreamer is a streaming media framework, based on graphs of filters
 which operate on media data.  Applications using this library can do
 anything from real-time sound processing to playing videos, and just
 about anything else media-related.  Its plugin-based architecture means
 that new data types or processing capabilities can be added simply by
 installing new plug-ins.
 .
 PiTiVi allows users to easily edit audio/video projects based on the
 GStreamer framework.  PiTIVi provides several ways of creating and
 modifying a timeline.  Ranging from a simple synopsis view (a-la
 iMovie) to the full-blown editing view (aka Complex View) which puts
 you in complete control of your editing.

Bug#1018069: O: game-music-emu -- Playback library for video game music files - development files

[Sebastian Dröge]

Package: wnpp
Severity: normal
Control: affects -1 src:game-music-emu

I intend to orphan the game-music-emu package.

The package description is:
 game-music-emu is a collection of video game music file emulators that
 support the following formats and systems:
  * AYZX Spectrum/Amstrad CPC
  * GBS   Nintendo Game Boy
  * GYM   Sega Genesis/Mega Drive
  * HES   NEC TurboGrafx-16/PC Engine
  * KSS   MSX Home Computer/other Z80 systems (doesn't support FM sound)
  * NSF/NSFE  Nintendo NES/Famicom (with VRC 6, Namco 106, and FME-7 sound)
  * SAP   Atari systems using POKEY sound chip
  * SPC   Super Nintendo/Super Famicom
  * VGM/VGZ   Sega Master System/Mark III, Sega Genesis/Mega Drive,BBC Micro
 .
 This package contains the header files, static libraries
 and symbolic links that developers using libgme will need.

Bug#1017905: Ships autogenerated files that can't be renegerated with the code in Debian main

[Sebastian Dröge]

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

[Sebastian Dröge]

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

[Sebastian Dröge]

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

[Sebastian Dröge]

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

[Sebastian Dröge]

Source: gudev-sharp-3.0
Version: 3.0.0-1
Severity: serious
Tags: upstream

See the discussion on the Debian Rust maintainers list for background:
https://alioth-lists.debian.net/pipermail/pkg-rust-maintainers/2022-August/022857.html

While that discussion is about Rust packages that were rejected, the same
situation also applies to gtk-sharp2 unfortunately. For more details how to 
solve
this in a way that makes ftp-masters happy, please refer to them.


Affected file is gudev/gudev-api.raw. This file was autogenerated from
specific versions of the underlying C libraries and it's not clear which
versions were used.

Debian ships these C libraries but certainly in different versions so it's not
possible to regenerate these files with what is available in Debian.

It will be necessary to either include the source code of the C libraries in
the exact version, or regenerate the files at build time with whatever is
available in Debian.

The latter will probably generate different bindings, potentially even with
different API, so is probably not a useful solution.


-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (700, 'unstable'), (500, 'unstable-debug'), (100, 
'experimental'), (1, 'experimental-debug')
merged-usr: no
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.18.0-4-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#1017898: Ships autogenerated files that can't be renegerated with the code in Debian main

[Sebastian Dröge]

Source: appindicator3-sharp
Version: 12.10.0+git20151221-5.1
Severity: serious
Tags: upstream

See the discussion on the Debian Rust maintainers list for background:
https://alioth-lists.debian.net/pipermail/pkg-rust-maintainers/2022-August/022857.html

While that discussion is about Rust packages that were rejected, the same
situation also applies to appindicator3-sharp unfortunately. For more details 
how to solve
this in a way that makes ftp-masters happy, please refer to them.


Affected file is sources/appindicator3-sharp-api.raw. This file were
autogenerated from specific versions of the underlying C libraries and it's
not clear which versions were used.

Debian ships these C libraries but certainly in different versions so it's not
possible to regenerate these files with what is available in Debian.

It will be necessary to either include the source code of the C libraries in
the exact version, or regenerate the files at build time with whatever is
available in Debian.

The latter will probably generate different bindings, potentially even with
different API, so is probably not a useful solution.


-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (700, 'unstable'), (500, 'unstable-debug'), (100, 
'experimental'), (1, 'experimental-debug')
merged-usr: no
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.18.0-4-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#1017900: Ships autogenerated files that can't be renegerated with the code in Debian main

[Sebastian Dröge]

Source: gudev-sharp-1.0
Version: 0.1-4.1
Severity: serious
Tags: upstream


See the discussion on the Debian Rust maintainers list for background:
https://alioth-lists.debian.net/pipermail/pkg-rust-maintainers/2022-August/022857.html

While that discussion is about Rust packages that were rejected, the same
situation also applies to gtk-sharp2 unfortunately. For more details how to 
solve
this in a way that makes ftp-masters happy, please refer to them.


Affected file is gudec/gudev-api.raw. This file were autogenerated from
specific versions of the underlying C libraries and it's not clear which
versions were used.

Debian ships these C libraries but certainly in different versions so it's not
possible to regenerate these files with what is available in Debian.

It will be necessary to either include the source code of the C libraries in
the exact version, or regenerate the files at build time with whatever is
available in Debian.

The latter will probably generate different bindings, potentially even with
different API, so is probably not a useful solution.


-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (700, 'unstable'), (500, 'unstable-debug'), (100, 
'experimental'), (1, 'experimental-debug')
merged-usr: no
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.18.0-4-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#1017897: Ships autogenerated files that can't be renegerated with the code in Debian main

[Sebastian Dröge]

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

[Sebastian Dröge]

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  

Bug#1017895: Ships copies of libraries that are packaged in Debian

[Sebastian Dröge]

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

[Sebastian Dröge]

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

[Sebastian Dröge]

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

[Sebastian Dröge]

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

[Sebastian Dröge]

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

[Sebastian Dröge]

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

[Sebastian Dröge]

On Thu, 27 Jan 2022 18:31:37 +0100 Francois Gouget  wrote:
> > 
> gstreamer1.0-plugins-bad is part of the main archive area. However in
> Debian Testing's version 1.18.5-1+b4 it depends on
> libgstreamer-gl1.0-0 which is now in the contrib archive area.
> 
> This is a violation of section 2.2.1 of the Policy which states that:
> 
>    None of the packages in the main archive area require software
>    outside of that area to function.
> 
> So to fix this one of the following should be done:
> * Demote this dependency to a 'Suggest', assuming the package is still
>   usable without it.
> * Remove the dependency entirely with the same caveat.
> * Or libgstreamer-gl1.0-0 should be moved back to the main archive area.

libgstreamer-gl1.0-0 does not seem to be in contrib unless I'm missing 
something.

Why do you think it is in contrib?


signature.asc
Description: This is a digitally signed message part

Bug#987299: unblock: gstreamer1.0/1.18.4-1

[Sebastian Dröge]

On Thu, 2021-04-22 at 14:17 +0200, Ivo De Decker wrote:
> tags -1 confirmed moreinfo
> 
> On Thu, Apr 22, 2021 at 02:09:20PM +0200, Moritz Mühlenhoff wrote:
> > Am Wed, Apr 21, 2021 at 09:31:12AM +0300 schrieb Sebastian Dröge:
> > > In addition to various more minor bugs, this release also fixes
> > > CVE-2021-3497
> > > and CVE-2021-3498 as well as other potentially security-relevant
> > > issues that
> > > didn't get their own CVE.
> > 
> > JFTR, there was an earlier discussion about CVE-2021-3497/CVE-2021-
> > 3498 with
> > Sebastian and given the way gstreamer release branches are handled
> > we
> > suggested to ask for an unblock of 1.18.4 (it's fundamentally quite
> > similar
> > to ffmpeg or vlc where we're also following release branches).
> 
> OK, thanks for the clarification.
> 
> You can go ahead with the uploads of these packages, and remove the
> moreinfo tag from this bug once they are ready to migrate.

Thanks, I'll upload the new versions this evening.

> Please note that it seems there was a fix for #984579 in the upload
> to unstable that isn't included in the upload to experimental. I
> assume this will be fixed in the next upload as well.

Yes, that's already included in my local version.


signature.asc
Description: This is a digitally signed message part

Bug#987299: unblock: gstreamer1.0/1.18.4-1

[Sebastian Dröge]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package gstreamer1.0

GStreamer 1.18.4 is a bugfix release on top of 1.18.3, which is currently in
testing/unstable. 1.18.4 is currently waiting in experimental until the
unblock request is accepted.

This does not affect only the gstreamer1.0 source package but also:
  - gst-plugins-base1.0
  - gst-plugins-good1.0
  - gst-plugins-bad1.0
  - gst-plugins-ugly1.0
  - gst-libav1.0
  - gst-rtsp-server-1.0
  - gstreamer-editing-services1.0
  - gstreamer-vaapi

and in theory gst-python1.0 and gst-plugins-bad1.0-contrib but those only got
a new release without any other changes than the version number. It might make
sense to get these two updated too to avoid user confusion caused by version
numbers being out of sync.


You can find a summary of the changes in the upstream release notes:
https://gstreamer.freedesktop.org/releases/1.18/#1.18.4

While there are quite a few changes, they are all targeted fixes for bugs that
were found, and the fixes were manually cherry-picked from the current
development branch and considered low-risk.

Each change is built upstream on many different platforms, the unit tests get
run as well as the whole integration testsuite.

At the bottom of the release notes you can find a link to the list of all
merge requests that were merged for this release.

In addition to various more minor bugs, this release also fixes CVE-2021-3497
and CVE-2021-3498 as well as other potentially security-relevant issues that
didn't get their own CVE.

Ubuntu 21.04 and Fedora 34 are also going to release with 1.18.4.


Thanks for your consideration!


unblock gstreamer1.0/1.18.4-1

Bug#985358: pitivi: A/V out of sync in rendered videos

[Sebastian Dröge]

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

[Sebastian Dröge]

On Tue, 2021-03-16 at 11:16 -0300, Antonio Terceiro wrote:

Dear Maintainer,

The version of pitivi in bullseye is affected by the bug listed above:
rendered videos have A/V out of sync by a few seconds, while they sound
just find in the preview.

I'm attaching the upstream patch that fixed the issue, already
backported to the current Debian package. I rebuilt pitivi locally with
this patch, and confirmed that it does fix the issue.

Yeah I'm aware of this and various other issues in the version
currently in Debian, and which are fixed in the latest releases.

Due to Debian release freeze policies the latest release is not
uploaded yet and I don't know how useful it is to just patch some of
the issues.

In the end what we'd really want is the latest release.


signature.asc
Description: This is a digitally signed message part

Bug#981203: gstreamer1.0: annotate Build-Depends

[Sebastian Dröge]

On Wed, 27 Jan 2021 17:15:06 +0100 Helmut Grohne  wrote:

> gstreamer1.0 participates in dependency loops relevant to architecture
> bootstrap. Rather than work on such a difficult problem, I looked into
> easily droppable dependencies. It turns out that the libgmp-dev and
> libgsl-dev dependencies are optional and unnecessary when building
> without tests as happens when passing nocheck via DEB_BUILD_OPTIONS. As
> such, these dependencies can be annotated . Please consider
> applying the attached patch.

Thanks, I've applied this to git and it will be part of the next
upload:

https://salsa.debian.org/gstreamer-team/gstreamer1.0/-/commit/daf98ff1fcfed98562e70af14888bf477eaa3fdb

Let me know if this becomes urgent at some point and I'll upload it
directly.


signature.asc
Description: This is a digitally signed message part

Bug#980439: nmu: gst-plugins-bad1.0_1.18.3-1

[Sebastian Dröge]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu

nmu gst-plugins-bad1.0_1.18.3-1 . ANY . unstable . -m "Rebuild against srt 
1.4.2-1.1 with the changed library package name"

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (700, 'unstable'), (500, 'unstable-debug'), (100, 
'experimental'), (1, 'experimental-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-1-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#971754: ABI breakage from 1.4.1 to 1.4.2

[Sebastian Dröge]

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

[Sebastian Dröge]

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

[Sebastian Dröge]

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

[Sebastian Dröge]

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

[Sebastian Dröge]

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

[Sebastian Dröge]

On Mon, 28 Dec 2020 18:40:38 +0100 Paul Gevers  wrote:
> 
> If you believe your package is unable to migrate to testing due to
> issues beyond your control, don't hesitate to contact the Release Team.
> In this case, I think it may be wise to upload to
> testing-proposed-updates and ask for an unblock. Otherwise your two bug
> fix releases may not make it to bullseye.


Hi Paul,

This is solely blocked on srt currently, and the maintainer will have
to figure out a solution there for the ABI breakage.

I could upload a version of gst-plugins-bad1.0 without the SRT plugin
for the time being so it can migrate in the meantime.

If I do that and srt gets fixed before the bullseye release, will I be
able to upload a new gst-plugins-bad1.0 version that re-enables the SRT
plugin and have it migrated?


Thanks,
Sebastian

Bug#978643: Please build with fdk-aac support

[Sebastian Dröge]

On Tue, 29 Dec 2020 18:23:34 +0100 Andreas Metzler  wrote:
> On 2020-12-29 Laurent Bigonville  wrote:
> [...]
> > The problem is that they are using elements that requires fdk-aac and
> > faac and these are currently packaged as non-free in debian.
> [...]
> > What would be the plan to have fdkaac and faac elements enabled? We
> > would have to add a new package that would go in contrib I guess? Would
> > that be acceptable?
> > 
> afaict we would need to add a new *source* package in contrib since a
> source package in main (gst-plugins-bad1.0) cannot build-depend on
> packages outside main.

Yes that would need a new source package. I'd be happy to have that as
part of the packages on https://salsa.debian.org/gstreamer-team and
take care of updating that together with new GStreamer releases if
someone (Laurent?) wants to prepare an initial package.

It's a bit suboptimal that pulseaudio requires fdk. I wonder if this
can also be made to work with the ffmpeg AAC encoder or if that doesn't
support LATM/LOAS yet.


FWIW, pulseaudio will need these changes here:
  https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1793

They're not merged upstream yet and won't be before 1.19 so would have
to be included as a patch for now.

Bug#971754: ABI breakage from 1.4.1 to 1.4.2

[Sebastian Dröge]

Source: srt
Version: 1.4.2-1
Severity: serious
Tags: upstream

1.4.2 broke ABI by adding some fields to the CBytePerfMon structure.
See https://github.com/Haivision/srt/issues/1592 for details.

There were also other ABI breakages in previous versions that are not
reflected by the binary package name of the library.

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (700, 'unstable'), (500, 'unstable-debug'), (100, 
'experimental'), (1, 'experimental-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.8.0-2-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#971741: pitivi should depend on libgstreamer-plugins-bad1.0-dev

[Sebastian Dröge]

On Tue, 2020-10-06 at 10:58 +0200, Richard B. Kreckel wrote:
> 
> Pitivi reports "Could not import 'GstTranscoder'. Make sure you have it 
> available." and exits immediately unless package 
> gir1.2-gst-plugins-bad-1.0 is isntalled.

Thanks, I'll include this in the next upload soonish. There are a few
other things to fix too.

Bug#965007: pitivi: ships a copy of gstreamer libraries

[Sebastian Dröge]

On Wed, 2020-09-23 at 09:36 +0200, Gianfranco Costamagna wrote:
> 
> Hello, I found that pitivi was using the gst-transcoder only if not found on 
> the system,
> and upstream commit "51ae6533ee26ffd47e453eb5f5ad8cd46f57d15e" worked in 
> fixing that.
> 
> I prepared a version on Debomatic with that change, and it stopped installing 
> the binary/pkgconfig/libraries.
> 
> http://debomatic-amd64.debian.net/distribution#unstable/pitivi/0.999-3/buildlog
> 
> 
> I would like to upload to sid, but unfortunately gst-plugins-bad1.0 conflicts 
> with pitivi << 0., so it won't fix the uninstallability...
> 
> Sebastian, how do you feel about relaxing that one?
> 
> I'm attaching a diff here (I'll change also VCS fields, and fix some lintian 
> sandess here and there)

Thanks for the diff. Upstream is planning to do a release any day now,
so I'd prefer waiting for that instead but if you have any other
changes to the packaging I'd be happy to integrate them :)

You can also send them as MR to
  https://salsa.debian.org/gstreamer-team/pitivi

Bug#893813: closed by Debian FTP Masters (reply to Sebastian Dröge ) (Bug#893813: fixed in gst-plugins-bad1.0 1.18.0-1)

[Sebastian Dröge]

On Tue, 2020-09-08 at 13:03 +, Thorsten Glaser wrote:
> Debian Bug Tracking System dixit:
> 
> >This is an automatic notification regarding your Bug report
> >which was filed against the src:gst-plugins-bad1.0 package:
> >
> >#893813: gst-plugins-bad1.0: FTBFS on x32: wrongly uses amd64 assembly
> 
> This unfortunately doesn’t seem to be complete, 1.18.0-1 FTBFS with:
> 
> 
> […]
> dh_install -pgstreamer1.0-plugins-bad 
> debian/tmp/usr/lib/x86_64-linux-gnux32/gstreamer-1.0/libgstresindvd.so
> mkdir -p /<>/fake-home
> HOME=/<>/fake-home \
> LD_LIBRARY_PATH=debian/libgstreamer-plugins-bad1.0-0/usr/lib/x86_64-linux-gnux32:debian/libgstreamer-opencv1.0-0/usr/lib/x86_64-linux-gnux32:/usr/lib/x86_64-linux-gnux32/libfakeroot:/usr/lib64/libfakeroot:/usr/lib32/libfakeroot
>  \
> dh_gstscancodecs
> 
> ERROR: Caught a segmentation fault while loading plugin file:
> debian/gstreamer1.0-plugins-bad/usr/lib/x86_64-linux-gnux32/gstreamer-1.0/libgstsrtp.so

That's a different problem though. I saw that one before on another
platform (Raspberry Pi IIRC). There it was something broken
in libsrtp2-1.

You can probably confirm that by running

  gst-inspect-1.0 
debian/gstreamer1.0-plugins-bad/usr/lib/x86_64-linux-gnux32/gstreamer-1.0/libgstsrtp.so

in gdb on that machine and getting a backtrace of the crash.

Bug#880401: gstreamer1.0-plugins-bad: Enabling experimental-agc of the webrtcdsp element makes it fail with "Illegal instruction" on ARM

[Sebastian Dröge]

reassign 880401 webrtc-audio-processing
thanks

On Tue, 31 Oct 2017 10:36:29 +0200 Martin Laakso <16...@notsharingmy.info> 
wrote:

> The title says it all. This bug is not present in the amd64 binaries.
> 
> It's probably worth mentioning that the CPU is a Broadcom BCM2835, in case 
> this is CPU-specific.
> 
> The same happened with GStreamer 1.10.4, which is why I tried upgrading to 
> the testing version.

There's no custom assembly or otherwise problematic code in the
GStreamer plugin, all the heavy lifting is done by webrtc-audio-
processing.

Reassigning there.

Bug#881398: gstreamer1.0-x: Unable to play anything with Parole, Totem, etc.

[Sebastian Dröge]

On Sat, 11 Nov 2017 11:09:20 +0100 jEsuSdA  wrote:
> 
> I've just reinstall my PC and it was unable to play anything with Parole WITH
> ANY USER BUT ROOT.

Is this still a problem? If so, can you provide some more information
about how it fails?

A GStreamer debug log would also be useful to have. You can get one by
setting GST_DEBUG=6 before running the application, and redirecting
stderr to a file.

Bug#870373: gstreamer1.0-plugins-base: "Could not decode stream" while trying to play Ogg Vorbis file

[Sebastian Dröge]

On Tue, 01 Aug 2017 15:29:13 +0200 Jonathan Ballet  wrote:
> 
> None of my music players using GStreamer are able to play Ogg Vorbis
> music files since a couple of months.

Is this still a problem? If so, can you provide such an Ogg Vorbis file?

It fails to read the file in question here, but all of mine are working fine.

Bug#890472: Status for Vulkan development tools?

[Sebastian Dröge]

On Mon, 13 Jul 2020 09:57:25 -0600 John Zupin  wrote:
> 
> Brett is no longer with LunarG and I'll be making updates to his ITP bug 
> submissions about the status of these packages.
> 
> The current status for the shaderc package is that it has been out for 
> 1+ years now and is hosted by LunarG.
> 
> I am LunarG's curator for these packages, please check 
> https://vulkan.lunarg.com/sdk/home under the "ubuntu packages" tab for 
> more information about our repository.

Would you consider maintaining them in Debian? That way people don't
have to get them from some random other place but directly from their
main package repository, and it would also appear in Ubuntu.

shaderc is at this point required for GTK4's and GStreamer's Vulkan
support, so not having it in the package repository is starting to
become a problem.

Bug#965007: pitivi: ships a copy of gstreamer libraries

[Sebastian Dröge]

On Mon, 2020-08-17 at 09:10 -0300, Antonio Terceiro wrote:
> 
> This file is already present in pitivi on stable, and
> gstreamer1.0-plugins-bad-apps is only present in experimental.  testing
> and unstable are unaffected by this, or testing would be unaffected if
> this hadn't caused pitivi to be removed.
> 
> I'm reassigning to gstreamer1.0-plugins-bad-apps.

It's a bug in pitivi. It should've never shipped these files outside
its private library directory.

It will be fixed once there's a new pitivi release, which I'm waiting
for currently. Please reassign this back to pitivi, thanks.


signature.asc
Description: This is a digitally signed message part

Bug#963307: gstreamer1.0: FTBFS:

[Sebastian Dröge]

On Sun, 21 Jun 2020 21:53:15 +0200 Lucas Nussbaum  wrote:
> 
> 
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
> [...]


Thanks for reporting. This happens because GNU make was updated to 4.3,
which includes backwards incompatible changes. Updating to that was
probably a bad idea before making sure most things work with the new
version...


The package in experimental has this fixed by getting rid of the
autotools/make-based build system and switching to meson.

GStreamer 1.18.0 should make it in time for bullseye so I'm not going
to bother fixing this separately.

Bug#959879: python-jedi: New upstream release 0.17.0

[Sebastian Dröge]

Source: python-jedi
Severity: wishlist

Dear Maintainer,

There's a new upstream release, 0.17.0, that is required for the vim
coc-python plugin. It does not work with earlier versions so it would be great
if the package in Debian could be updated.

Thanks!

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (700, 'unstable'), (500, 'unstable-debug'), (100, 
'experimental'), (1, 'experimental-debug')
Architecture: amd64 (x86_64)

Kernel: Linux 5.5.0-2-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#956002: pitivi: Python SyntaxWarning in package setup - bad identity comparisons against literals

[Sebastian Dröge]

On Sun, 2020-04-05 at 17:36 -0400, Phil Miller wrote:
> Package: pitivi
> Version: 0.999-2
> Severity: normal
> 
> running python rtupdate hooks for python3.8...
> [snip other packages with the same warning]
> /usr/lib/x86_64-linux-gnu/pitivi/python/pitivi/application.py:328:
> SyntaxWarning: "is" with a literal. Did you mean "=="?
>   elif status is "UNSUPPORTED":
> /usr/lib/x86_64-linux-
> gnu/pitivi/python/pitivi/timeline/previewers.py:869: SyntaxWarning:
> "is" with a literal. Did you mean "=="?
>   if self._image_size[0] is 0:

Thanks for reporting. This is already fixed since quite a while
upstream, and many other things too. We'll get the fix together with
the next release in the hopefully not too distant future.


signature.asc
Description: This is a digitally signed message part

Bug#954799: ITA fatsort -- utility for sorting FAT directory structures

[Sebastian Dröge]

On Mon, 2020-03-23 at 17:27 +0100, Jordi Sayol wrote:
> 
> The current maintainer of the fatsort package has given me permission
> to adopt it, so I'll do it if there isn't any inconvenience.

Thanks for taking it over, please just go ahead :)


signature.asc
Description: This is a digitally signed message part

Bug#946329: valgrind-mpi FTBFS

[Sebastian Dröge]

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 

Bug#942614: valgrind: debuginfo section duplicates a section in the main ELF file

[Sebastian Dröge]

On Sat, 19 Oct 2019 03:36:12 +0200 Simon Richter  wrote:
> Package: valgrind
> Version: 1:3.15.0-1.1
> Severity: normal
> Tags: upstream
> 
> Hi,
> 
> this is probably the same as Ubuntu bug #1848211.

I can confirm that the

  0001-Don-t-look-for-debug-alt-file-in-debug-image-if-it-i.patch 

patch from the Ubuntu package fixes this. Not only does the warning
disappear but also callstacks provided by valgrind are actually useful
again.

Note that valgrind-mpi doesn't build at all on current sid, but that's
a separate issue.


signature.asc
Description: This is a digitally signed message part

Bug#942314: RFP: gst-plugins-rs -- GStreamer plugins written in Rust

[Sebastian Dröge]

Package: wnpp
Severity: wishlist

* Package name: gst-plugins-rs
  Version : 0.5.0
  Upstream Author : Sebastian Dröge 
* URL : https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs
* License : LGPL, MIT/Apache-2.0
  Programming Lang: Rust
  Description : GStreamer plugins written in Rust

The GStreamer project is starting to write various extension plugins in the
Rust programming language. There are a few useful ones now at this point and
it would be good to start packaging them.

I personally don't have the time for maintaining this also in Debian in
addition to all the other GStreamer packages (help welcome!) but would be
happy to assist anybody who wants to start packaging gst-plugins-rs.

The package should probably be maintained as part of the Debian Rust team:
https://wiki.debian.org/Teams/RustPackaging
See there also for the Rust-specific packaging policy.

It will be required to also package various dependencies as part of this.

Bug#929185: default soundfonts

[Sebastian Dröge]

On Wed, 2019-09-04 at 13:07 +0200, Fabian Greffrath wrote:
> Hi slomo,
> 
> could you please consider this patch for the next gst-plugins-bad1.0
> upload?

Thanks, I've added it to git for now. There will be an 1.16.1 release
in the near future, the patch will be part of that


signature.asc
Description: This is a digitally signed message part

Bug#914250: gstreamer1.0-plugins-good: cheese is not able to capture from usb webcam

[Sebastian Dröge]

forwarded 914250 
https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/issues/644
thanks

On Tue, 20 Nov 2018 23:14:56 +0100 =?UTF-8?Q?Bernhard_=c3=9cbelacker?= 
 wrote:

> a webcam that was working previously in stretch does not with current testing.
> 
> I tracked it down to the gstreamer1.0-plugins-good package,
> was working until 1.12.4-1+b1, failes since 1.14.0-4.

Thanks, I've forwarded this upstream:
  https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/issues/644


signature.asc
Description: This is a digitally signed message part

Bug#914549: Segmentation fault for some videos (assertion 'GST_MINI_OBJECT_IS_LOCKABLE (object)' failed)

[Sebastian Dröge]

On Sat, 24 Nov 2018 19:39:11 +0100 antistress  wrote:
> Package: gstreamer1.0-plugins-base
> Version: 1.14.4-dmo1

You're using a non-official version of GStreamer. Can you reproduce
this also with the packages from Debian?


signature.asc
Description: This is a digitally signed message part

Bug#914697: libgstreamer1.0-0: Certain GTK and GNOME applications fai to start or load

[Sebastian Dröge]

On Mon, 26 Nov 2018 13:14:56 +0100 Adrian Immanuel Kiess  
wrote:
>
> The error these applications spit out is:
> 
> (gst-plugin-scanner:12086): GLib-GObject-WARNING **: 13:00:20.092: cannot
> register existing type 'GstAggregator'

This sounds like you have incompatible versions of GStreamer installed.

What's the output of

  dpkg -l *gst*

and

  ldd /usr/lib/*/gstreamer-1.0/libgstcompositor.so

?

Thanks!


signature.asc
Description: This is a digitally signed message part

Bug#927739: FTBFS: undefined reference to `yylex'

[Sebastian Dröge]

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'

[Sebastian Dröge]

Source: libkate
Version: 0.4.1-9
Severity: serious

Hi,

Something seems to have changed with flex, which causes the package to now
fail to build:

/bin/bash ../libtool  --tag=CC  --silent --mode=link gcc -Wall -W
-I/usr/include/libpng16 -g -O2 
-fdebug-prefix-map=/home/slomo/tmp/foo/libkate-0.4.1=. -fstack-protector-strong 
-Wformat -Werror=format-security  -Wl,-z,relro -Wl,-z,now -o kateenc 
kateenc-kateenc.o kateenc-kate_lexer.o kateenc-kate_parser.o kateenc-kpng.o 
../lib/liboggkate.la ../lib/libkate.la -logg -lpng16 -lz -lfl 
/usr/bin/ld: 
/usr/lib/gcc/x86_64-linux-gnu/8/../../../x86_64-linux-gnu/libfl.so: undefined 
reference to `yylex'
collect2: error: ld returned 1 exit status


Thanks!

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (700, 'unstable'), (500, 'unstable-debug'), (100, 
'experimental'), (1, 'experimental-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-4-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#914861: gstreamer1.0: Please convert from cdbs to dh

[Sebastian Dröge]

On Tue, 27 Nov 2018 22:36:46 -0500 Jeremy Bicha  wrote:
> Source: gstreamer1.0
> Version: 1.14.4-1
> X-Debbugs-CC: sl...@debain.org
> 
> Sebastian, the gstreamer packages are some of the last prominent
> "desktop" packages I use that use cdbs. I think they would benefit
> from a conversion to use the "simple dh" rules instead.
> 
> Here are some benefits I anticipate:
> - dh has built-in support for meson. I guess there's nothing stopping
> cdbs packages from using meson, but I haven't seen any do it.
> - dh has built-in support for multiarch. Obvlously, cdbs packages can
> do multiarch too but it's just a bit easier in dh.
> - dh_auto_test runs build tests by default.
> - dh is now much more commonly used than cdbs which makes the rules
> file more accessible to more Debian contributors.
> - in my opinion, dh is easier to work with in general.
> 
> I would like to help you convert these packages, but I didn't want to
> start on the work unless you were open to the idea.

I think that's a great idea. I'm currently updating in the debian-
experimental branch for 1.15.1 and if you could start working on that
afterwards that would be wonderful.

I already had that on my list since a while but never got to it.


Thanks a lot and sorry for the late reply!


signature.asc
Description: This is a digitally signed message part

Bug#904266: gir1.2-gstreamer-1.0: Install the typelibs into a multi-arch directory

[Sebastian Dröge]

On Wed, 2018-08-08 at 12:37 +, Hugh McMaster wrote:
> Hi Sebastian,
> 
> On Monday, 30 July 2018 16:32:27 +1000, Sebastian Dröge wrote:
> > Are gobject-introspection and all the bindings actually looking in
> > that
> > directory too?
> 
> The typelibs for gobject-introspection are now installed in 
> /usr/lib//gobject-introspection/giscanner.

Thanks, I'll take a look at that together with the next upload unless
you'd like to provide a patch for this already.

Same thing for the other related bug, the proposed solution seems fine.


signature.asc
Description: This is a digitally signed message part

Bug#823307: libgstreamer1.0-dev is not Multi-Arch compatible

[Sebastian Dröge]

On Wed, 2018-08-08 at 12:30 +, Hugh McMaster wrote:
> On Monday, 30 July 2018 016:33:39 +1000, Sebastian Dröge wrote:
> > Which files are conflicting between the x86 and x86-64 version of the
> > package?
> 
> There is only file conflict: in the binary gst-codec-info-1.0.
> 
> As this is a compiled binary, it is not so easy to fix. But I need to look
> at the sources to understand if it has an architecture-indepenent
> interface and/or output.

It's not unfortunately, it needs to be able to load .so files for that
target build architecture during the build of packages.

How is this solved in other such cases?


signature.asc
Description: This is a digitally signed message part

Bug#904266: gir1.2-gstreamer-1.0: Install the typelibs into a multi-arch directory

[Sebastian Dröge]

On Sun, 22 Jul 2018 13:23:33 + Hugh McMaster  
wrote:
> Package: gir1.2-gstreamer-1.0
> Version: 1.14.1-1
> Severity: normal
> Tags: patch
> 
> Dear Maintainer,
> 
> The package gir1.2-gstreamer-1.0 is not currently multi-arch compatible,
> as the typelibs are installed in /usr/lib/girepository-1.0.
> 
> To make the package multi-arch compatible, the typelibs need to be
> installed in /usr/lib/*/girepository-1.0.
> 
> The attached patch makes this change and marks the package Multi-Arch: same.

Are gobject-introspection and all the bindings actually looking in that
directory too?

signature.asc
Description: This is a digitally signed message part

Bug#823307: libgstreamer1.0-dev is not Multi-Arch compatible

[Sebastian Dröge]

On Tue, 03 May 2016 10:46:12 +0200 Francois Gouget  wrote:
> Package: libgstreamer1.0-dev
> Version: 1.8.0-2
> Severity: normal
> 
> Dear Maintainer,
> 
> The libgstreamer1.0-dev package is not multi-arch aware so that the amd64 
> version
> conflicts with the i386 one which makes it impossible to install both. As a 
> result
> several libigstxxx.so symbolic links are missing making development 
> impossible without
> manually hacking the filesystem.
> 
> This particularly hurts Wine development as it is important to be able to 
> compile both
> the 32 and 64 bit versions.
> 
> Note that this bug is still present in 1.8.1-1.

Which files are conflicting between the x86 and x86-64 version of the
package?

signature.asc
Description: This is a digitally signed message part

Bug#894076: Can't include GL and GLES headers simultaneously on non-64 bit architectures

[Sebastian Dröge]

On Thu, 2018-03-29 at 12:45 +0300, Sebastian Dröge wrote:
> On Thu, 2018-03-29 at 10:54 +0200, Julien Cristau wrote:
> > 
> > I expect we'll get a fix from upstream when that happens.
> 
> What would you suggest for the time being? This sounds like it's
> going to take a while.
> 
> The simplest workaround on my side would probably be to just not
> build the Qt/QML GStreamer plugin on ARM until this is fixed.

Ok, as there is no progress here I'll simply remove the Qt/QML plugin
on ARM for the time being.

signature.asc
Description: This is a digitally signed message part

Bug#894387: gst-plugins-bad1.0: Corebird can't playvideos anymore

[Sebastian Dröge]

On Thu, 2018-03-29 at 19:24 +0200, Philip Rinn wrote:
> 
> > So we'll have to get that solved somehow
> 
> Is there another solution than adding a dependency on gstreamer1.0-
> gtk3 in corebird? (Besides adding it to gstreamer1.0-plugins-good
> which you obviously don't want).

GStreamer has a mechanism to tell you about missing plugins and ask the
user to install it. On Debian this is handled via
/etc/alternatives/gstreamer-codec-install , which usually then points
to packagekit and would ask the user to install the gstreamer1.0-gtk3
package then.

But as corebird apparently does not use that API in the current
version, that's also not a very useful solution.


I don't see a solution that a) requires no changes to corebird, b)
doesn't let gstreamer1.0-plugins-good (or -bad) pull in GTK as a
dependency and defeat the purpose of splitting it off into its own
package.

We should really just somehow get the new package into testing fast,
which is currently blocked on mesa.

signature.asc
Description: This is a digitally signed message part

Bug#894387: gst-plugins-bad1.0: Corebird can't playvideos anymore

[Sebastian Dröge]

reassign 894387 gst-plugins-good1.0
thanks

On Thu, 2018-03-29 at 18:28 +0200, Philip Rinn wrote:
> Source: gst-plugins-bad1.0
> Version: 1.14.0-1
> Severity: normal
> 
> Hi,
> 
> since gst-plugins-bad1.0 1.14.0-1 entered testing today corebird
> can't play videos anymore.
> 
> The error is:
> 
> "Could not create gtksink. Need gst-plugins-bad >= 1.6"

You need to depend on gstreamer1.0-gtk now, which provides the GTK
plugin. It was moved to its own package because people complained that
gstreamer1.0-plugins-bad pulls in too many dependency (and it would be
in gstreamer1.0-plugins-good otherwise now anyway with 1.14).

Unfortunately, that package is not in testing yet because of a bug in
mesa, which seems blocked by bureaucracy now.
See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=894076

So we'll have to get that solved somehow

signature.asc
Description: This is a digitally signed message part

Bug#894076: Can't include GL and GLES headers simultaneously on non-64 bit architectures

[Sebastian Dröge]

On Thu, 2018-03-29 at 10:54 +0200, Julien Cristau wrote:
> 
> I expect we'll get a fix from upstream when that happens.

What would you suggest for the time being? This sounds like it's going
to take a while.

The simplest workaround on my side would probably be to just not build
the Qt/QML GStreamer plugin on ARM until this is fixed.

signature.asc
Description: This is a digitally signed message part

Bug#894076: Can't include GL and GLES headers simultaneously on non-64 bit architectures

[Sebastian Dröge]

On Mon, 2018-03-26 at 20:37 +0300, Sebastian Dröge wrote:
> On Mon, 2018-03-26 at 19:03 +0200, Julien Cristau wrote:
> > Control: severity -1 normal
> > Control: tag -1 upstream
> > 
> > On 03/26/2018 10:01 AM, Sebastian Dröge wrote:
> > > Package: mesa
> > > Version: 17.3.7-1
> > > Severity: serious
> > > Forwarded: https://bugs.freedesktop.org/show_bug.cgi?id=105328
> > > 
> > 
> > I don't think that's a serious bug.
> 
> Well, it's preventing gst-plugins-good1.0 from building currently and
> all workarounds would mean a loss in functionality (no GL support on
> arm).
> 
> It also currently causes no GLES support to be available on 32 bit
> platforms in gst-plugins-base1.0.

Is there any progress on this? I could provide a patch if that helps
with anything and if you would be open to apply that before upstream
went through all the Khronos bureaucracy

signature.asc
Description: This is a digitally signed message part

Bug#894149: buzztrax FTBFS with gstreamer 1.14

[Sebastian Dröge]

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

[Sebastian Dröge]

On Mon, 2018-03-26 at 19:03 +0200, Julien Cristau wrote:
> Control: severity -1 normal
> Control: tag -1 upstream
> 
> On 03/26/2018 10:01 AM, Sebastian Dröge wrote:
> > Package: mesa
> > Version: 17.3.7-1
> > Severity: serious
> > Forwarded: https://bugs.freedesktop.org/show_bug.cgi?id=105328
> > 
> 
> I don't think that's a serious bug.

Well, it's preventing gst-plugins-good1.0 from building currently and
all workarounds would mean a loss in functionality (no GL support on
arm).

It also currently causes no GLES support to be available on 32 bit
platforms in gst-plugins-base1.0.

signature.asc
Description: This is a digitally signed message part

Bug#894076: Can't include GL and GLES headers simultaneously on non-64 bit architectures

[Sebastian Dröge]

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=armel=1.14.0-1=1521580828=0

This causes

a) gst-plugins-base1.0 to only build with support for GL and not both
GL and GLES on the affected architectures,

b) causes gst-plugins-good1.0 to fail to build because Qt is including
the GLES headers, while GStreamer includes only the GL headers because
of the above

Currently gst-plugins-good1.0 fails to build on armel/armhf and can't
migrate to testing because of this bug. As a workaround I could force
gst-plugins-good to only build with GLES support on armel/armhf but
that's just that, a workaround.


This was reported upstream here
  https://bugs.freedesktop.org/show_bug.cgi?id=105328
and upstream agrees that this is a bug, and it seems easy enough to fix
by guarding the type definitions with the preprocessor to not redefine
them if they were already defined.


Thanks!

signature.asc
Description: This is a digitally signed message part

Bug#893813: gst-plugins-bad1.0: FTBFS on x32: wrongly uses amd64 assembly

[Sebastian Dröge]

forwarded 893813 
thanks

On Thu, 2018-03-22 at 19:05 +0100, Thorsten Glaser wrote:
> [...]
> 
> Please report that upstream.

Thanks, done: https://bugzilla.gnome.org/show_bug.cgi?id=794605

Feel free to NMU for this change, but I expect there to be more similar
problems elsewhere.

signature.asc
Description: This is a digitally signed message part

Bug#892128: libgstreamer-gl1.0-0: Missing recommends on gstreamer1.0-gl

[Sebastian Dröge]

On Mon, 2018-03-05 at 16:26 -0500, Jeremy Bicha wrote:
> Package: libgstreamer-gl1.0-0
> Version: 1.13.90-1
> 
> I think libgstreamer-gl1.0-0 is missing a Recommends on gstreamer1.0-gl.
> 
> I noticed this while figuring out an issue with the dependencies for 
> webkit2gtk.
> 
> https://bugs.webkit.org/183336

Thanks, next upload will fix that. I've already included a fix in GIT.

You probably want to let webkit depend on gstreamer1.0-gl though, AFAIU
it requires those elements now for proper accelerated video playback.

signature.asc
Description: This is a digitally signed message part

Bug#862024: Status of this bug?

[Sebastian Dröge]

On Sat, 2018-01-20 at 10:19 +0200, Sebastian Dröge wrote:
> On Fri, 2018-01-19 at 13:26 -0800, Josh Triplett wrote:
> > I'd love to see this fixed as well, and a gstreamer1.0-plugins-
> > opencv 
> > or
> > similar introduced.
> > 
> > Would it help to have a patch?
> 
> Yes, please go ahead :) Thanks! I had no time yet to do this
> properly.
> 
> Note that there's also an OpenCV library in GStreamer, so multiple
> binary packages would be needed here.

I've implemented something like this in GIT for gst-plugins-bad. Will
finish and upload it hopefully during this weekend, or early next week
otherwise.

signature.asc
Description: This is a digitally signed message part

Bug#888501: gstreamer1.0-vaapi: Latests versions does not work at all

[Sebastian Dröge]

reassign 888501 libva
thanks

On Fri, 26 Jan 2018 10:40:36 -0200 Junior Polegato 
 wrote:

> libva info: VA-API version 0.40.0
> libva info: va_getDriverName() returns 0
> libva info: Trying to open /usr/lib/i386-linux-gnu/dri/i965_drv_video.so
> libva error: /usr/lib/i386-linux-gnu/dri/i965_drv_video.so has no function
> __vaDriverInit_0_32
> libva info: va_openDriver() returns -1

Hi,

this looks like a version mismatch between your Intel driver and
libva, nothing related to gstreamer-vaapi.

Reassigning to libva for the time being.


Best regards,
Sebastian

signature.asc
Description: This is a digitally signed message part

Bug#889020: New upstream version 0.11

[Sebastian Dröge]

Package: gtimelog
Severity: wishlist

Hi,

there's a new upstream version, 0.11, available now. It features a much
more polished UI and useful features that previously required external
applications.

Would be great to have the package updated in Debian.


Sebastian

signature.asc
Description: This is a digitally signed message part

Bug#888326: gst-libav1.0: FTBFS with FFmpeg 3.5

[Sebastian Dröge]

forwarded 888326 https://bugzilla.gnome.org/show_bug.cgi?id=792900
thanks

On Wed, 24 Jan 2018 22:26:50 + jcowg...@debian.org wrote:

> Your package FTBFS with the upcoming version 3.5 of FFmpeg. In FFmpeg 3.5,
> there are a number of API changes which will cause many packages to FTBFS.
> For this reason I have uploaded an early development snapshot to experimental
> before the 3.5 release in an attempt to fix some of these a bit quicker.
> While 3.5 has not been finalized and the ABI is not stable yet, there should
> not be any significant API breakages before the release.
> 
> [...]

Thanks, I've forwarded this upstream:
https://bugzilla.gnome.org/show_bug.cgi?id=792900

signature.asc
Description: This is a digitally signed message part

Bug#849090: Port to Python 3 and python3-gst-1.0

[Sebastian Dröge]

On Thu, 22 Dec 2016 17:52:00 +0200 Sebastian Dröge <sl...@debian.org> wrote:

> your package currently depends on python-gst-1.0. Upstream is planning
> to drop Python 2.x support in the near future, leaving only Python 3
> support.
> 
> Please update your package to Python 3 to make this as painless as
> possible later. Thanks!

Just an update here, this will likely happen in the next 2-3 months
with the next upstream release. Your package will become uninstallable
at that point unless it is ported to Python 3.

signature.asc
Description: This is a digitally signed message part

Bug#849086: Port to Python 3 and python3-gst-1.0

[Sebastian Dröge]

On Thu, 22 Dec 2016 17:51:41 +0200 Sebastian Dröge <sl...@debian.org> wrote:

> your package currently depends on python-gst-1.0. Upstream is planning
> to drop Python 2.x support in the near future, leaving only Python 3
> support.
> 
> Please update your package to Python 3 to make this as painless as
> possible later. Thanks!


Just an update here, this will likely happen in the next 2-3 months
with the next upstream release. Your package will become uninstallable
at that point unless it is ported to Python 3.

signature.asc
Description: This is a digitally signed message part

Bug#849089: Port to Python 3 and python3-gst-1.0

[Sebastian Dröge]

On Thu, 22 Dec 2016 17:51:55 +0200 Sebastian Dröge <sl...@debian.org> wrote:

> your package currently depends on python-gst-1.0. Upstream is planning
> to drop Python 2.x support in the near future, leaving only Python 3
> support.
> 
> Please update your package to Python 3 to make this as painless as
> possible later. Thanks!

Just an update here, this will likely happen in the next 2-3 months
with the next upstream release. Your package will become uninstallable
at that point unless it is ported to Python 3.

signature.asc
Description: This is a digitally signed message part

Bug#849088: Port to Python 3 and python3-gst-1.0

[Sebastian Dröge]

On Thu, 22 Dec 2016 17:51:52 +0200 Sebastian Dröge <sl...@coaxion.net> wrote:

> your package currently depends on python-gst-1.0. Upstream is planning
> to drop Python 2.x support in the near future, leaving only Python 3
> support.
> 
> Please update your package to Python 3 to make this as painless as
> possible later. Thanks!

Just an update here, this will likely happen in the next 2-3 months
with the next upstream release. Your package will become uninstallable
at that point unless it is ported to Python 3.

signature.asc
Description: This is a digitally signed message part

Bug#849084: Port to Python 3 and python3-gst-1.0

[Sebastian Dröge]

On Thu, 22 Dec 2016 17:51:10 +0200 Sebastian Dröge <sl...@debian.org> wrote:

> your package currently depends on python-gst-1.0. Upstream is planning
> to drop Python 2.x support in the near future, leaving only Python 3
> support.
> 
> Please update your package to Python 3 to make this as painless as
> possible later. Thanks!

Just an update here, this will likely happen in the next 2-3 months
with the next upstream release. Your package will become uninstallable
at that point unless it is ported to Python 3.

signature.asc
Description: This is a digitally signed message part

Bug#849087: Port to Python 3 and python3-gst-1.0

[Sebastian Dröge]

On Thu, 22 Dec 2016 17:51:48 +0200 Sebastian Dröge <sl...@debian.org> wrote:

> your package currently depends on python-gst-1.0. Upstream is planning
> to drop Python 2.x support in the near future, leaving only Python 3
> support.
> 
> Please update your package to Python 3 to make this as painless as
> possible later. Thanks!

Just an update here, this will likely happen in the next 2-3 months
with the next upstream release. Your package will become uninstallable
at that point unless it is ported to Python 3.

signature.asc
Description: This is a digitally signed message part

Bug#849091: Port to Python 3 and python3-gst-1.0

[Sebastian Dröge]

On Thu, 22 Dec 2016 17:52:09 +0200 Sebastian Dröge <sl...@debian.org> wrote:

> your package currently depends on python-gst-1.0. Upstream is planning
> to drop Python 2.x support in the near future, leaving only Python 3
> support.
> 
> Please update your package to Python 3 to make this as painless as
> possible later. Thanks!

Just an update here, this will likely happen in the next 2-3 months
with the next upstream release. Your package will become uninstallable
at that point unless it is ported to Python 3.

signature.asc
Description: This is a digitally signed message part

Bug#849092: Port to Python 3 and python3-gst-1.0

[Sebastian Dröge]

On Thu, 22 Dec 2016 17:52:13 +0200 Sebastian Dröge <sl...@debian.org> wrote:

> your package currently depends on python-gst-1.0. Upstream is planning
> to drop Python 2.x support in the near future, leaving only Python 3
> support.
> 
> Please update your package to Python 3 to make this as painless as
> possible later. Thanks!

Just an update here, this will likely happen in the next 2-3 months
with the next upstream release. Your package will become uninstallable
at that point unless it is ported to Python 3.

signature.asc
Description: This is a digitally signed message part

Bug#888245: Port to Python 3 and python3-gst-1.0

[Sebastian Dröge]

Package: photofilmstrip
Severity: normal
User: sl...@debian.org
Usertags: python-gst-1.0-removal

Hi,

your package currently depends on python-gst-1.0. Upstream is planning
to drop Python 2.x support in the near future (next 2-3 months!),
leaving only Python 3 support.

Please update your package to Python 3 to make this as painless as
possible. Thanks!


Sebastian

signature.asc
Description: This is a digitally signed message part

Bug#862024: Status of this bug?

[Sebastian Dröge]

On Fri, 2018-01-19 at 13:26 -0800, Josh Triplett wrote:
> I'd love to see this fixed as well, and a gstreamer1.0-plugins-opencv 
> or
> similar introduced.
> 
> Would it help to have a patch?

Yes, please go ahead :) Thanks! I had no time yet to do this properly.

Note that there's also an OpenCV library in GStreamer, so multiple
binary packages would be needed here.

signature.asc
Description: This is a digitally signed message part

Bug#863663: Letter to Santa

[Sebastian Dröge]

On Wed, 2017-12-20 at 23:57 +0100, Francesco Poli wrote:
> 
> ;-)
> 
> Seriously: is there any progress (not documented on the bugzilla
> bug)? Please let me know.

The mailing list is no bug tracker and mails like this are not going to
motivate anybody, and at least in my case got rid of any motivation at
all to look at it.

Check the Bugzilla ticket for progress, it also contains some outline
of how it could be fixed if someone wants to spend their time on it.

> P.S.: Please keep the Debian bug address in Cc. Thanks!

The Debian bug has the Bugzilla bug set as "forwarded-to", so will get
updated automatically. Nothing to be done here.


signature.asc
Description: This is a digitally signed message part

Bug#883849: libwebkit2gtk-4.0-37 uninstallable because gst-plugins-bad1.0 is now at 1.12.4

[Sebastian Dröge]

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 <pochu@deb
> > 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

[Sebastian Dröge]

On Fri, 8 Dec 2017 11:17:22 +0100 Emilio Pozuelo Monfort  
wrote:
> On 08/12/17 11:04, Paul Gevers wrote:
> > Package: libwebkit2gtk-4.0-37
> > Version: 2.18.3-1
> > Severity: grave
> > Justification: renders package unusable
> > 
> > While trying to build a new version of liferea in unstable, I noticed that
> > libwebkit2gtk-4.0-37 is uninstallable due to a newer version of
> > gst-plugins-bad1.0.
> > 
> > libwebkit2gtk-4.0-37 Depends libgstreamer-plugins-bad1.0-0 (<< 1.12.4)
> 
> Just a small transition, fixed with:
> 
> emilio@tatooine:~$ wb nmu gnome-dvb-daemon gstreamer-vaapi webkit2gtk . ANY .
> unstable . -m 'Rebuild against gst-plugins-bad1.0 1.12.4.'

Please make sure to rebuild against 1.12.4-2. Then we won't have the
same problem again for 1.12.5, but only once 1.13/1.14 is there.

signature.asc
Description: This is a digitally signed message part

Bug#883691: game-music-emu: AddressSanitizer: negative-size-param: (size=-8), size=-8 passed to memcpy in Mem_File_Reader::read_avail

[Sebastian Dröge]

Hi Salvatore,

On Wed, 2017-12-06 at 20:32 +0100, Salvatore Bonaccorso wrote:
> 
> Thank you. 
> 
> MITRE has assigned CVE-2017-17446 for this issue.
> 
> I do not think we need a DSA for this issue, but could be fixed via a
> point release.

Upstream did a new release with a fix for this very crash, and also
added some more checks for preventing similar bugs to the code. I'm
uploading that to unstable now.

This release only really contains the fix, nothing else, and if that's
all fine with you it could also go into the next stable point release.

signature.asc
Description: This is a digitally signed message part

Bug#883691: game-music-emu: AddressSanitizer: negative-size-param: (size=-8), size=-8 passed to memcpy in Mem_File_Reader::read_avail

[Sebastian Dröge]

forwarded 883691 
https://bitbucket.org/mpyne/game-music-emu/issues/14/addresssanitizer-negative-size-param-size
thanks


Hi Salvatore,

On Wed, 2017-12-06 at 17:50 +0100, Salvatore Bonaccorso wrote:
> [...]
> 
> So the issue seem located in game-music-emu, Sebastian can you have a
> look?

I've forwarded this upstream now, thanks for reporting!

See: 
https://bitbucket.org/mpyne/game-music-emu/issues/14/addresssanitizer-negative-size-param-size

The crash can also be reproduced by running "ffplay" on the file.

signature.asc
Description: This is a digitally signed message part

Bug#879673: ffmpeg 3.4 API compat layer not 100% backwards compatible

[Sebastian Dröge]

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

[Sebastian Dröge]

Package: ffmpeg
Version: 7:3.4-1
Severity: serious

Hi,

ffmpeg 3.4 comes with a new decoding API (among other things), and
provides a compatibility layer around that for the old API.
Unfortunately this compatibility layer is apparently not 100% backwards
compatible or buggy. It breaks at least h264 decoding with gst-
libav1.0, but then probably also breaks other packages.

gst-libav upstream bug can be found here:
https://bugzilla.gnome.org/show_bug.cgi?id=789193

We'll try to port over to the new API but it looks like some effort,
and even independent of that the compatibility layer should either be
fixed or the soname of the libraries has to be updated.


Best regards,
Sebastian

signature.asc
Description: This is a digitally signed message part

Bug#862024: gstreamer1.0-plugins-bad: Dependency on libopencv-contrib3.2 pulls over 236MB.

[Sebastian Dröge]

On Fri, 2017-10-20 at 22:16 +0200, Michael Biebl wrote:
> On Thu, 19 Oct 2017 22:35:33 -0300 Daniel Serpell
>  wrote:
> > Package: gstreamer1.0-plugins-bad
> > Version: 1.12.3-2
> > Followup-For: Bug #862024
> > 
> > Hi!
> > 
> > Biggest culprit are the new opencv packages, there libopencv-contrib3.2
> > pulls libvtk (150MB) and other big packages, about 236MB in total.
> > 
> > Next in the list is libopencv-calib3d3.2, at 60MB,
> > libopencv-objdetect3.2 at 58MB, libopencv-imgcodecs3.2 at 57MB.
> > 
> > So, simply splitting /usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstopencv.so
> > out in another package will reduce the size of dependencies to the
> > previous level.
> 
> Sebastian what do you think about splitting out less common used plugins
> with heavy dependencies into a separate binary package like
> gstreamer1.0-plugins-bad-extra?
> 
> The first plugin moved to this -extra package would be libgstopencv.so
> and we could move more plugins as we see fit (that's why I think using a
> rather generic name like -extra would be preferrable).
> 
> The main gstreamer1.0-plugins-bad package would have a suggests:
> gstreamer1.0-plugins-bad-extra

I'm fine with the idea, the main problem is that whatever I decide for
"extra" plugins, for someone it will be a important one :)

Moving opencv to its own binary package was on my list already, its
dependency chain is just too huge and most people don't need it.


So let's go with an "extra" package instead, I'll spend some time
thinking about what else would make sense to have moved. DirectFB
probably.

> A middle ground would be to investigate why  gstreamer1.0-plugins-bad
> needs libopencv-contrib3.2 with opencv and if this could be avoided.
> [...]

Yes, we use some of the contrib stuff unfortunately.

signature.asc
Description: This is a digitally signed message part

Bug#878747: gst-plugins-bad1.0 FTBFS with libopenjp2-7-dev 2.3

[Sebastian Dröge]

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
> te=sid
> 
> ...
> 
> In file included from gstopenjpegdec.h:29:0,
>  from gstopenjpegdec.c:27:
> gstopenjpeg.h:42:12: fatal error: openjpeg-2.2/openjpeg.h: No such
> file or directory
>  #  include 
> ^
> compilation terminated.

There's a patch for this upstream, I'll get it included in the package
in the next days and then upload a fixed version. Thanks!

signature.asc
Description: This is a digitally signed message part

Bug#863525: game-music-emu: library for interfacing with SPC

[Sebastian Dröge]

On Sun, 2017-09-24 at 23:06 -0400, Michael Gilbert wrote:
> Hi,
> 
> I would like to apply the patch attached to the original message.
> I'll plan to do an upload to delayed/10 in a few days.  If you have
> any feedback, please let me know.

Check with upstream why it is not included in gme. As long as it is
separate, it would be better to also have it packaged separately.

Also check with upstream if this is maintained at all and guaranteed to
be available for future releases. Just patching in some random code
found elsewhere that even adds API is usually not a good idea.

signature.asc
Description: This is a digitally signed message part

Bug#876338: nmu: gstreamer-vaapi_1.12.3-1

[Sebastian Dröge]

On Thu, 2017-09-21 at 11:00 +0200, Emilio Pozuelo Monfort wrote:
> Hi Sebastian!
> 
> On 21/09/17 09:57, Sebastian Dröge wrote:
> > Package: release.debian.org
> > Severity: normal
> > User: release.debian@packages.debian.org
> > Usertags: binnmu
> > 
> > nmu gstreamer-vaapi_1.12.3-1 . ANY . unstable . -m "Rebuild against
> > gstreamer1.0-plugins-bad 1.12.3"
> 
> This was already handled in #876227 (which also took care of the other
> dependencies).
> 
> As you mentioned on the webkit bug, it'd be nice to only require this for 
> minor
> (and not micro) releases.

Yeah, next upload to gst-plugins-bad will do that :) The micro
requirement was a leftover from 0.10 times

signature.asc
Description: This is a digitally signed message part

Bug#876340: nmu: gstreamer-vaapi_1.12.3-1

[Sebastian Dröge]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu

nmu gstreamer-vaapi_1.12.3-1 . ANY . unstable . -m "Rebuild against 
gstreamer1.0-plugins-bad"


See bug #868429 for context. Thanks!

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (700, 'unstable'), (500, 'unstable-debug'), (100, 
'experimental'), (1, 'experimental-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.11.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#876339: nmu: gstreamer-vaapi_1.12.3-1

[Sebastian Dröge]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu

nmu gstreamer-vaapi_1.12.3-1 . ANY . unstable . -m "Rebuild against 
gstreamer1.0-plugins-bad 1.12.3"


See bug #868429 for context. Thanks!

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (700, 'unstable'), (500, 'unstable-debug'), (100, 
'experimental'), (1, 'experimental-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.11.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#876338: nmu: gstreamer-vaapi_1.12.3-1

[Sebastian Dröge]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu

nmu gstreamer-vaapi_1.12.3-1 . ANY . unstable . -m "Rebuild against 
gstreamer1.0-plugins-bad 1.12.3"


See bug #868429 for context. Thanks!

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (700, 'unstable'), (500, 'unstable-debug'), (100, 
'experimental'), (1, 'experimental-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.11.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#876257: libwebkit2gtk-4.0-37: blocks upgrade path for libgstreamer-plugins-bad1.0-0 1.12.3

[Sebastian Dröge]

Hi Alberto,

On Wed, 2017-09-20 at 11:19 +0200, Alberto Garcia wrote:
> On Wed, Sep 20, 2017 at 10:53:07AM +0200, Antonio Ospite wrote:
> > it looks like libwebkit2gtk-4.0-37 is blocking the upgrade path
> > for libgstreamer-plugins-bad1.0-0 1.12.3, looking at the package
> > dependencies I spotted these constraints:
> > 
> > libgstreamer-plugins-bad1.0-0 (>= 1.12.2), libgstreamer-plugins-bad1.0-0 
> > (<< 1.12.3)
> > 
> > which explain the issue.
> > 
> > However I am not sure about why both constraints are there.
> 
> That's gst-plugins-bad:
> 
> DEB_DH_MAKESHLIBS_ARGS_libgstreamer-plugins-bad$(gst_deb_abi) += -V 
> "libgstreamer-plugins-bad$(gst_deb_abi) (>= $(gst_version)), 
> libgstreamer-plugins-bad$(gst_deb_abi) (<< $(gst_version_next))"
> 
> From its changelog:
> 
>   + Split the libraries into their own package and add a -dev package.
> The API of the library is not guaranteed to be stable and as such
> the shlibs of the library package are very strict and will require
> dependant libraries to get a rebuild after every new upstream version.
> 
> I understand that its rdeps need to be rebuilt each time there's a new
> upstream version, or how is that supposed to work? Sebastian?

That's correct. The API and ABI of the libraries in gst-plugins-bad is
not stable and can change every release.

However only every new minor release, not micro release.
So >= 1.12 < 1.13 would be sufficient here and probably would solve
most of the headaches.

Feel free to send me a patch or NMU directly for that, otherwise I'll
get it done with the next upload.

signature.asc
Description: This is a digitally signed message part

Bug#852594: buzztrax: Update udevadm path

[Sebastian Dröge]

On Wed, 2017-09-13 at 15:15 +0200, Michael Biebl wrote:
> Control: tags -1 fixed-upstream
> On Tue, 12 Sep 2017 11:49:40 +0300 Sebastian =?ISO-8859-1?Q?Dr=F6ge?=
>  wrote:
> > severity 852594 minor
> > thanks
> > 
> > Hi,
> > 
> > as this only affects a source code comment and not actual code, I'm
> > downgrading the severity to minor. This is in no way serious.
> 
> Indeed. Thanks for your explanation.
> I did not check each bug report individually before raising the severity
> so I missed Stefan's comment. Sorry for that.

Sure, not a problem at all :)

signature.asc
Description: This is a digitally signed message part