I also added the missing supplements in gstreamer-plugins-bad-codecs, so that too should now get automagically installed. lø., jan. 29 2022 at kl. 12.56 +0100 +0100 skrev Bjørn Lie følgende:

lø., jan. 29 2022 at kl. 12.50 +0100 +0100 skrev Manfred Hollstein følgende:

...

Hi Bjørn,

On Sat, 29 Jan 2022, 12:16:40 +0100, Bjørn Lie wrote:

...

Greetings all

Letting you all know that we have removed the packages gstreamer-plugins-bad and gstreamer-plugins-ugly (and their sub-packages) for Tumbleweed. Leap stays as it has been in the past.

In the future only the plugins not available in main oss from these 2 will be packaged and shipped (gstreamer-plugins-libav will continue to exist for now).

This means that user will encounter that zypper expect/wants you to do a vendor change for a lot of gstreamer packages if you currently have them installed from the packman repo. This is expected and you should go ahead with the vendor change.

Thanks for providing this change! I just did the upgrade and found some obstacles which others might see, too:

$ zypper dup --allow-vendor-change ...

This resulted in several messages about file conflicts. Reason is that the gstreamer-plugins-bad-orig-addon and gstreamer-plugins-ugly-orig-addon packages remained installed, but they should go away - perhaps there is an Obsoletes: missing in the new packages. Also gstreamer-plugins-bad-codecs did not get automatically installed while gstreamer-plugins-ugly-codecs did.

So the proper sequence might be the following to work around the small issues:

$ rpm -e gstreamer-plugins-bad-orig-addon gstreamer-plugins-ugly-orig-addon $ zypper dup --allow-vendor-change $ zypper in gstreamer-plugins-bad-codecs

...

Once done, you should be left with only 2 (or 4 if you have gst-*32-bits installed aswell). Those will be:

gstreamer-plugins-bad-codecs gstreamer-plugins-ugly-codecs

(and depending on 32-bit or not)

gstreamer-plugins-bad-codecs-32bit gstreamer-plugins-ugly-codecs-32bit

/Bjørn

HTH, cheers.

l8er manfred

Provides: gstreamer-plugins-ugly-orig-addon = %{version} Obsoletes: gstreamer-plugins-ugly-orig-addon < %{version} Provides: gstreamer-plugins-bad-orig-addon = %{version} Obsoletes: gstreamer-plugins-bad-orig-addon < %{version}

Provides/Obsoletes is in place, but I should have used

Obsoletes: gstreamer-plugins-bad-orig-addon Obsoletes: gstreamer-plugins-ugly-orig-addon

without the version check ...

/Bjørn

lø., jan. 29 2022 at kl. 07.16 -0500 -0500 skrev Neal Gompa følgende:

It didn't work because you didn't use "%{version}-%{release}". Without that, it won't correctly obsolete older builds where the version is the same.

Basically, never use "%{version}" for this case, always use "%{version}-%{release}".

Noted for future ref, for now I went with the versionless Obsolete all past, present and future versions of orig-addon, granted that might come back and bite me in the behind should we ever want to reintroduce orig-addons for bad/ugly. /Bjørn

Hello, Am Samstag, 29. Januar 2022, 13:16:43 CET schrieb Neal Gompa:

On Sat, Jan 29, 2022 at 6:57 AM Bjørn Lie wrote: [...]

...

Provides: gstreamer-plugins-ugly-orig-addon = %{version} Obsoletes: gstreamer-plugins-ugly-orig-addon < %{version} Provides: gstreamer-plugins-bad-orig-addon = %{version} Obsoletes: gstreamer-plugins-bad-orig-addon < %{version}

Provides/Obsoletes is in place, but I should have used

Obsoletes: gstreamer-plugins-bad-orig-addon Obsoletes: gstreamer-plugins-ugly-orig-addon

without the version check ...

As you noted in a later mail, an unversioned Obsoletes: will bite you if you ever want to re-introduce that package. So please don't use unversioned Obsoletes:

It didn't work because you didn't use "%{version}-%{release}". Without that, it won't correctly obsolete older builds where the version is the same.

Basically, never use "%{version}" for this case, always use "%{version}-%{release}".

While I agree that including the release makes sense (if the version stays the same), I don't like the idea of using variables when it comes to Obsoletes. Obsoletes is one of the rare cases where hardcoded version numbers make sense, in this case (assuming the last version from Packman was 1.18.5-1.1) Obsoletes: gstreamer-plugins-ugly-orig-addon < 1.18.5-2.1 Obsoletes: gstreamer-plugins-bad-orig-addon < 1.18.5.2.1 The difference to using %{version}-%{release} is that the hardcoded variant will still only obsolete < 1.18.5-2.1 when we have gstreamer- plugins 2.42 one day. If you use variables, it will then obsolete < 2.42, which is much broader than initially intended, and probably not really what you want. Yes, I know that our packaging guidelines recommend to use variables even for Obsoletes. I hereby propose to change the guidelines to use hardcoded version numbers for Obsoletes. Regards, Christian Boltz -- Du versuchst, einen Braunkohlebagger im Fahrradständer abzustellen. [Ratti in suse-linux zur Frage, wie man Mails mit >=100 MB senden kann]

to., feb. 3 2022 at kl. 20.55 +0100 +0100 skrev Michal Suchánek følgende:

Sounds like the libopenh264 needs some fix to be usable both 32bit and 64bit at the same time.

Thanks

Michal

Right - missing baselibs.conf in openh264 And now we are REALLY way of what should be discussed here on the factory list ;-) Please lets move this to packman if in need of more discussion. /Bjørn

ti., mars 1 2022 at kl. 15.04 +0100 +0100 skrev Dominik Heidler følgende:

Hi,

I'm the maintainer of the opi tool that is in the oss repo and can help installing codecs from packman using "opi codecs" command.

I implemented the changes for tw in this PR for opi: https://github.com/openSUSE/opi/pull/92

Could someone have a look if this makes sense?

Also will this change affect the release after 15.4?

Regards, Dominik

Yes that looks fine. Installing both gstreamer-bad/ugly-codecs AND gstreamer-libav is a bit of a "overkill" but fine, will not hurt anything. Personally I do not have gst-libav installed, but I suppose for the casual enduser this will give the least headache. One could also question the install of pipewire-aptx, as not everyone will have pipewire installed I suppose, but that is up to you. "Current setup" will be the default for future releases yes, at least that is the plan as of now. /Bjørn