Re: [packman] Stable Packman for Leap

2016-06-20 Diskussionsfäden Olaf Hering
On Mon, Jun 20, Tomáš Chvátal wrote:

> We need to do this properly.

How would your proposal look like in practice? There are packages which
act as "overlay" and there are additional packages. vlc, ffmpeg and
gstreamer-(bad|ugly) are overlay, things like kodi are addon. Many of
the packages are enabled for a subset of the available repositories.

Where are the package sources supposed to live? This affects how the
binaries are delivered to the mirrors. Right now there are 4 projects
(Essentials|Extra|Games|Multimedia)/ delivered as individual
install repos, and there is the toplevel catch-all repo which covers all
of the above.

If the existing layout is supposed to be supported then one way to
handle it are _aggregates for each package, which fetches the binaries
from another repo. If the existing layout should disappear we are free
to redefine the layout as needed.

And now that I look at the  mirror layout I notice the directory names
are flipped, compared to OBS and IBS: in packman its / while
in OBS its /. So maybe there is a chance to adjust the
publisher to fetch binaries for /suse/openSUSE_Tumbleweed/Essentials
from Essentials-TW/openSUSE_Tumbleweed instead of
Essentials/openSUSE_Tumbleweed. As a result each dist would get its own
project. If we go that route each pkg would start from scratch, and its
CI_CNT and B_CNT will be reset and as a result it will look like a
downgrade for most packages. Is there a way preserve CI_CNT/B_CNT?


Olaf

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

Re: [packman] qmmp missing libmad/libacc plugins on SLE 12

2016-06-20 Diskussionsfäden Olaf Hering
On Fri, Jun 17, Frank Steiner wrote:

> Is there any special reason why these two plugins were dropped?
> If it just happened accidentally, could you re-add them please?

Perhaps this was by accident. The SLE12 binaries are from October
because meanwhile the pkg requires Qt 5.4. SLE12 ships with 5.3. There
is a Qt 5.5 in the Update channel, but no binaries are available in OBS.
As a result a few packages do not build with SLE12SP1, including qmmp.

There is nothing PMBS can do to fix it. The obvious fix is to release
the Qt 5.5 binaries from the Update channel also to
openSUSE.org:SUSE:SLE-12-SP1:Update.

Or wait until SP2 is released, then PMBS will start to build againts it.


Olaf

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


Re: [packman] Packman for Tumbleweed

2016-06-20 Diskussionsfäden Dave Plater
On 6/20/16, Olaf Hering  wrote:
> On Mon, Jun 20, Dave Plater wrote:
>
>> So we can safely delete the other gstreamer packages or are there
>> packages that will get broken as a result?
>
> A few packages which are linked in but have no BUILD_ORIG or other knobs
> can be excluded from openSUSE_Tumbleweed. Looks like all _linked
> gstreamer packages (except -bad and -ugly), chromaprint and very few
> others are affected. I have done that already for 42.2.
>
> Some packages have now a hard requirement for ffmpeg3. I think today one
> can live without MPlayer and xine-lib. There are likely elegant ways to
> let such packages pick the available ffmpeg variant.
>
> Olaf
>
I can't live without xine, it's my primary video player, there's a
project still going on at mercurial but no release has happened for
years. It's also the only gui that emulates a dvd player properly for
preview in DVDStyler. MPlayer is for mswindows it never worked for me.
If there's a problem with xine ui or libs I'll have a look.
Dave

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


Re: [packman] Packman for Tumbleweed

2016-06-20 Diskussionsfäden Olaf Hering
On Mon, Jun 20, Dave Plater wrote:

> So we can safely delete the other gstreamer packages or are there
> packages that will get broken as a result?

A few packages which are linked in but have no BUILD_ORIG or other knobs
can be excluded from openSUSE_Tumbleweed. Looks like all _linked
gstreamer packages (except -bad and -ugly), chromaprint and very few
others are affected. I have done that already for 42.2.

Some packages have now a hard requirement for ffmpeg3. I think today one
can live without MPlayer and xine-lib. There are likely elegant ways to
let such packages pick the available ffmpeg variant.

Olaf

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


Re: [packman] Stable Packman for Leap

2016-06-20 Diskussionsfäden Olaf Hering
On Mon, Jun 20, Tomáš Chvátal wrote:

> Ok guys this is again half-assed solution with package suffixes and others.

This is for the current way of publishing packages.

> We need to do this properly.

I'm actually ok with reorganizing the whole project layout. Since the
resulting layout is not automatically published this needs some thought.

Olaf

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

Re: [packman] Stable Packman for Leap

2016-06-20 Diskussionsfäden Tomáš Chvátal
Ok guys this is again half-assed solution with package suffixes and others.

We need to do this properly.

1) Have packman-essentials-Factory project
 * builds against factory only
 * links only factory packages
 * links only factory deps
2) Have packman-essentials-Product project
 * Builds only against openSUSE-version they are for
 * links only packages from this product
 * links only product dependencies
 * If something is missing it inherits the dependency from the product+1,
if missing then product+2...
3) Use sr# approach for packages not in OBS to first go to packman-factory
and when verified go to the "stable" products, alternatively use
maintenance model (but that uses more resources).

Last time people were against this because it IS more complex than one big
heap of everything in one repo. But it is the only solution that makes this
rock-solid and actually safe for use on stable environments and edgy for
Tumbleweed.

For the PMBS the resources load with the above should be lower due to
lesser need for rebuilds.

Tom


2016-06-20 14:16 GMT+02:00 Dave Plater :

> On 6/20/16, Frederic Crozat  wrote:
> > 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
> > ___
> I thought it might need more servers for a separate stable repository
> but if it doesn't then it's two birds with one stone.
> Dave
>
> ___
> Packman mailing list
> Packman@links2linux.de
> http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
>
___
Packman mailing list
Packman@links2linux.de
http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman


Re: [packman] Stable Packman for Leap

2016-06-20 Diskussionsfäden Dave Plater
On 6/20/16, Frederic Crozat  wrote:
> 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
> ___
I thought it might need more servers for a separate stable repository
but if it doesn't then it's two birds with one stone.
Dave

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


Re: [packman] Packman for Tumbleweed

2016-06-20 Diskussionsfäden Richard Brown
On 20 June 2016 at 12:02, Olaf Hering  wrote:
> On Mon, Jun 20, Richard Brown wrote:
>
>> Packman's current model for Tumbleweed, building against
>> multimedia:libs and not Tumbleweed, means that Packman users get
>> packages of the NEXT version of ffmpeg, gstreamer, etc, BEFORE it is
>> ready for Tumbleweed
>
> Regarding gstreamer, I wonder what kind of testing is done. Can it do
> anything useful in the variant from OBS? Looking at the spec files, only
> -bad and -ugly rely on packman.

openQA is fully capable of loading a video, going to a specific frame
and confirming it renders properly, and listening to audio and
ensuring the output from the sound card spectrographically matches a
reference audience sample.

So in short, we test if it works, not whether it's got a pretty spec file.

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


Re: [packman] Packman for Tumbleweed

2016-06-20 Diskussionsfäden Dave Plater
On 6/20/16, Olaf Hering  wrote:
> On Mon, Jun 20, Richard Brown wrote:
>
>> Packman's current model for Tumbleweed, building against
>> multimedia:libs and not Tumbleweed, means that Packman users get
>> packages of the NEXT version of ffmpeg, gstreamer, etc, BEFORE it is
>> ready for Tumbleweed
We maintain packman in multimedia especially multimedia:libs, it takes
too long for a package to filter through into Factory and even longer
into Tumbleweed for us to do our job properly. I restored
multimedia:libs/ffmpeg to 2.8 at the ire of the maintainers that first
submitted it because of the builds that it might have broken in
Packman. This is why there is an ffmpeg-2.8 package in Packman, to
wait until upstream catches up, which they will do.
>From an installation point of view ffmpeg library abi versions exist
happily with each other on any system.
Olaf has worked hard on ensuring that there are no system breakages
due to the ffmpeg abi change. When all of the packages in OBS build
against ffmpeg3 .
Users don't use openSUSE's ffmpeg, it's crippled. It's main purpose in
OBS is for packages to build against it and for a few packages that
don't rely on it's libavcodec.
There is nothing wrong with Tumbleweed having ffmpeg-2.8, users of
ffmpeg have all updated to 3 from Packman anyway.
See below for gstreamer.
>
> Regarding gstreamer, I wonder what kind of testing is done. Can it do
> anything useful in the variant from OBS? Looking at the spec files, only
> -bad and -ugly rely on packman.
>
>> This causes disruption, pain, heartache, and I've now lost track of
>> the amount of times it's broken GNOME applications that used
>> gstreamer.
>
> That would have been valueable information actually, especially for this
> thread.
>
> Olaf
>
So we can safely delete the other gstreamer packages or are there
packages that will get broken as a result?
Dave

___
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 Carlos E. R.
On 2016-06-20 08:28, Dave Plater wrote:

> 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.

As a plain user of packman since many years, I have to say thank you for
this. I'm happy to be using ffmpeg version 3 something in my old
openSUSE 13.11. Works very well.

-- 
Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 "Bottle" at Telcontar)



signature.asc
Description: OpenPGP digital signature
___
Packman mailing list
Packman@links2linux.de
http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman

Re: [packman] Packman for Tumbleweed

2016-06-20 Diskussionsfäden Olaf Hering
On Mon, Jun 20, Richard Brown wrote:

> Packman's current model for Tumbleweed, building against
> multimedia:libs and not Tumbleweed, means that Packman users get
> packages of the NEXT version of ffmpeg, gstreamer, etc, BEFORE it is
> ready for Tumbleweed

Regarding gstreamer, I wonder what kind of testing is done. Can it do
anything useful in the variant from OBS? Looking at the spec files, only
-bad and -ugly rely on packman.

> This causes disruption, pain, heartache, and I've now lost track of
> the amount of times it's broken GNOME applications that used
> gstreamer.

That would have been valueable information actually, especially for this
thread.

Olaf

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


Re: [packman] Stable Packman for Leap

2016-06-20 Diskussionsfäden Olaf Hering
On Mon, Jun 20, Frederic Crozat wrote:

> Le lun. 20 juin 2016 à 10:07, Dave Plater  a écrit :
> 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.

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

I have now created a 42.2_ffmpeg pkg, and I disabled many pkgs which
just link to OBS and exist in 42.2 and which link to ffmpeg.

Lets see how that works in practice.

Olaf

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


[packman] Packman for Tumbleweed

2016-06-20 Diskussionsfäden Richard Brown
On 20 June 2016 at 10:03, Dave Plater  wrote:
> This thread has the wrong subject.
> I think this is a proposal for a new Packman model.
> Rolling release Packman and stable Packman,

While I support this idea, I still think packman needs to stop rolling
faster than Tumbleweed

Therefore for rolling packman, I still recommend it should be built
against Tumbleweed, and not an untested devel project.

So while the discussions about Leap go on in the other thread, this
new thread is to discuss the situation specific to Tumbleweed

Tumbleweed is a tested rolling distribution. While it can change
anything at any time, it only changes stuff once they are tested and
integrated.

Packman's current model for Tumbleweed, building against
multimedia:libs and not Tumbleweed, means that Packman users get
packages of the NEXT version of ffmpeg, gstreamer, etc, BEFORE it is
ready for Tumbleweed

This causes disruption, pain, heartache, and I've now lost track of
the amount of times it's broken GNOME applications that used
gstreamer.

Packman is effectively treating it's users like guineapigs for the
unreleased packages in multimedia:libs. I'd rather Packman be a
reliable source of packages that can be trusted.

Please build Packman for Tumbleweed using linked packages from Tumbleweed.
Also, Bjorn's advice about =direct is still good ;)

- Richard

___
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] [PM] mythtv-0_27 0.27.3-5.2 (openSUSE 13.2/x86_64)

2016-06-20 Diskussionsfäden Aliaksei Padvalski
The package is ready but there is a bug:
https://code.mythtv.org/trac/ticket/12735#no2

20.06.2016, 09:37, "process" :
> Dear packman team,
>
> you are doing a great job on your services, thank you.
>
> In April, the mythtv team finally released their new version of mythtv,
> starting to deal with the web interface aside other things. I am just curious,
> if someone of your team is working on building the new packages or I should
> give at a try at OBS myself.
>
> Thank you again for all your efforts,
>
> regards
> process.
>
> ___
> Packman mailing list
> Packman@links2linux.de
> http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman

___
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 Dave Plater
This thread has the wrong subject.
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.
Meanwhile we do the best we can to make Packman as stable as possible.
Regards
Dave Plater

___
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  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 Olaf Hering
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.


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?

Olaf

___
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 but this is still
> to be qualified, I never dup Packman, I just looked a