Re: [packman] obs-studio and obs-v4l2sink broken after last update

2020-09-11 Diskussionsfäden Frederic Crozat
v4l2sink is currently unmaintained upstream (there is already bug
report on github for the plugin location) but a fork is being
integrated in OBS for new major version, so the problem will be gone).

Le ven. 11 sept. 2020 à 10:42, Olaf Hering  a écrit :
>
> Am Fri, 11 Sep 2020 10:28:06 +0200
> schrieb Frederic Crozat :
>
> > The changes for libexec should have probably been restricted to
>
> Unlikely. It is upstreams fault, they should have used the proper variables 
> in their cmake files...
>
> Did anyone already open an upstream bug to get this sorted out?
>
> Olaf



-- 
Frederic Crozat

___
Packman mailing list
Packman@links2linux.de
http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman

Re: [packman] obs-studio and obs-v4l2sink broken after last update

2020-09-11 Diskussionsfäden Frederic Crozat
Le ven. 11 sept. 2020 à 10:18, McCullen, Will  a écrit :
>
> Forgive me. I am on Opensuse 15.2, obs-studio 25.0.8-pm152.3.1, and
> obs-v4l2sink 0.1.0-pm152.3.1

The changes for libexec should have probably been restricted to
Factory build and not 15.2 builds for OBS and v4l2sink..

>
> On Thu, Sep 10, 2020 at 8:24 AM McCullen, Will  wrote:
>
> > I was wondering if you were aware that the last obs-studio update broke
> > the functionality of obs-v4l2sink. That kind of busts the whole video
> > conferencing solution.
> > Could you please let me know if that is something on your end, or was
> > there a change that requires a modification on my end?
> > Thank you so much.
> >
> > --
> > Will McCullen
> > IT Center for Excellence, Adv. Program Manager
> > Pima Community College
> > (520) 206-
> >
>
>
> --
> Will McCullen
> IT Center for Excellence, Adv. Program Manager
> Pima Community College
> (520) 206-
> ___
> Packman mailing list
> Packman@links2linux.de
> http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman



-- 
Frederic Crozat

___
Packman mailing list
Packman@links2linux.de
http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman

[packman] Stable Packman for Leap

2016-06-20 Diskussionsfäden Frederic Crozat
Le lun. 20 juin 2016 à 10:07, Dave Plater  a écrit :

> This thread has the wrong subject.
>

Not anymore ;)

I think this is a proposal for a new Packman model.
> Rolling release Packman and stable Packman, because ATM it is
> impossible to have both but maybe Richard can help to get this done.
>

I don't see why Packman project needs Richard help on getting this done ?

This is purely a project setup issue (and in the long term, it will eat
less build ressources from Packman Build Service..)
-- 

-- 
Frédéric Crozat
___
Packman mailing list
Packman@links2linux.de
http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman


Re: [packman] rebuilding gstreamer every day?

2016-06-20 Diskussionsfäden Frederic Crozat
Le lun. 20 juin 2016 à 09:45, Olaf Hering <o...@aepfle.de> a écrit :

> On Mon, Jun 20, Frederic Crozat wrote:
>
> > You seem to forget the entire mess it created for Packman users when
> ffmpeg
> > 3 became the "default" ffmpeg in Packman.
>
> What mess was that? Likely just the build breakage caused by the API
> change.
>

Just look at the archive of this ml about codec missing, for instance..

You seem to forget a majority of Leap users don't want (and sometime don't
know) how to fiddle with regression in packages. Not everybody is like you
or me (or people subscribed to this ml ;)

I think we should try to _link 42.2_{gstreamer,ffmpeg,whatever} to
> openSUSE.org:openSUSE:Leap:42.2:Update and see how it goes.
> Or should there be no gstreamer pkg at all for 42.2 because
> openSUSE:Leap:42.2 already links to ffmpeg?
>

linking to 42.2:Update would be indeed a good start, and using ffmpeg from
42.2:Update and enabling patented codecs from this project and publishing
the additional gstreamer packages from 42.2:Update (if any, I didn't check
source code) would probably be enough for Leap users. No need to have
everything up to date.

(PS: I switched to list only, no need to cc everybody involved since
everybody is subscribed).
-- 

-- 
Frédéric Crozat
___
Packman mailing list
Packman@links2linux.de
http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman


Re: [packman] rebuilding gstreamer every day?

2016-06-20 Diskussionsfäden Frederic Crozat
Le lun. 20 juin 2016 à 08:29, Dave Plater  a écrit :

> On 6/19/16, Richard Brown  wrote:
> > On 19 June 2016 at 16:41, Dave Plater  wrote:
> >>> The pkg in multimedia:libs is about one hundred, thousand, million
> >>> times more at risk of being broken than the pkg in Factory
> >>
> >> Not if it's well maintained
> >
> > There is _NO SUCH THING_ as a well maintained Devel Project.
> >
> > https://en.opensuse.org/openSUSE:Factory_development_model
> >
> > They EXIST to be where things are put together, broken and ultimately
> > fixed before being submitted to Factory for testing into Tumbleweed
> >
> > A Devel Project which doesn't break from time to time is not doing
> > it's job properly.
> Firstly, I've been a multimedia and other single  packages, package
> maintainer in openSUSE since 2009 and fixed many bugs. I think that my
> opinion is qualified. Breakages used to occur in Factory and now they
> are picked up in Tumbleweed and they are fixed in a branch of the
> devel project. Upstream releases packages that have been tested across
> the entire Linux spectrum of distributions. If I pick up a breakage I
> first look if it has been fixed upstream in git or whatever revision
> control system is used and apply a patch.
>

And yet, using a devel project as a basis for packages for Leap is wrong
(to TW, maybe less, but this is debatable). It forces users to
switch the entire gstreamer stack to Packman, including major version
upgrade of this stack for no good reason other than "this is the version
which is in devel project".

zypper dup is NOT something which should be advocated to Leap users.

>>>
> >>> Because it's a devel project, where packages are MEANT to be broken
> >>> from time to time, meanwhile we KNOW the ffmpeg packages in Factory
> >>> work as they get tested in openQA as part of the VLC testing.
> >>>
> >>> I've said it before and I'll say it again Packman building against
> >>> multimedia:libs has always been silly
> >>
> >> Once Packman packages weren't linked and that resulted in many
> >> problems with incompatible libraries and out of sync maintenance.
> >
> > I have no problem with linking, but link to the right thing for petes
> sake
> >
> > ffmpeg in Packman is linked to openSUSE.org:multimedia:libs
> >
> > This means it is version 3.0.2
> >
> > In Tumbleweed ffmpeg is 2.8.6
> >
> > In Leap ffmpeg is 2.8.6
> >
> > In Leap 42.2 ffmpeg is 2.8.6
> >
> > End result: Any Packman user is now forced to upgrade ffmpeg and
> > potentially ffmpeg related packages, including many multimedia
> > applications, to the versions in packman to a version of ffmpeg which
> > is UNTESTED and NOT SUPPORTED by the openSUSE Project (yet)
> ffmpeg is well tested upstream, I use the latest version on Leap and I
> use ffmpeg frequently.
> I have the ffmpeg libraries from both ffmpeg ABI 3 and 2 on my system,
> this is what the shared library policy is all about and the ffmpeg
> developers stick to the policy, ffmpeg libraries and gstreamer
> libraries are the keystone of linux multimedia.
>

You seem to forget the entire mess it created for Packman users when ffmpeg
3 became the "default" ffmpeg in Packman.

>
> > In short, this is dangerous, wrong, stupid and downright idiotic.. and
> > I'm being polite and holding back what i really think about it.
> >
> > At the very LEAST ffmpeg in Packman should be linked to
> Factory/Tumbleweed
>
> No, Packman users want the latest packages, Packman is the Tumbleweed
> of multimedia but it doesn't have automatic tests like Tumbleweed
> because it isn't an installation media it is a repository for packages
> that cannot be in the openSUSE distribution.
>

No, this is wrong.

A majority of packman users just want codecs and software which is not
available directly from openSUSE. This is mostly true for Leap users, maybe
a bit less
for TW users. Leap users values stability vs latest version of everything.

Pushing latest gstreamer stack or ffmpeg to Leap users through Packman is
simply wrong.

>
> > Packman for Leap should be linked to the version in Leap, so that
> > users do not have to suffer needless risk upgrading their packages.
> >
> >> Packman is a safe way for users to get the newest packages, especially
> >> Leap users because it rarely gets new packages. It's a pity somebody
> >> doesn't donate some extra server power to Packman to speed up the
> >> build cycle. Maintaining the Packman packages in multimedia apps and
> >> libs has taken away the old volatility that used to come from Packman.
> >> It's a far better option to enabling multiple obs repositories for Leap.
> >
> > No, Packman is not a safe way and this thread is sadly yet another
> > example of packman maintainers ignoring sound advice from seasoned
> > packagers who know what they're talking about.
>
> I actually don't agree with the zypper dup -r Packman model and would
> rather see a Requires: package-version-release model 

Re: [packman] xmms for SLE 12

2015-07-30 Diskussionsfäden Frederic Crozat
gtk1 is dead, as well as libxml1 and arts.

You should switch to something else than xmms.



-- 
Frederic Crozat

___
Packman mailing list
Packman@links2linux.de
http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman