Re: [packman] 32 bit baselibs needed by winegstreamer still not published

2017-02-07 Diskussionsfäden Olaf Hering 
On Mon, Jan 30, Olaf Hering wrote:

> It seems the bug was that publishing is disabled for Leap/i586, which
> appearently also covers all the -32bit packages in Leap/x86_64. Now
> publishing is enabled for Leap/i586, hopefully that was the missing
> knob. It may take some time until the packages appear on the mirrors.

All gstreamer-32bit packages are available now, the missing dependencies
are resolved.

Olaf


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

Re: [packman] [PM] pcsx2 1.4.0+git20161227.1208-1.1 (openSUSE_Leap 42.2/x86_64)

2017-02-07 Diskussionsfäden Olaf Hering 
On Tue, Jan 10, Guo Yunhe wrote:

> Maybe the Git version is not stable enough for daily use yet. Could you 
> package stable release as pcsx2 and unstable release pcsx2-beta?

There is now a pcsx2-32bit.rpm for Leap, please check if it works.

Olaf


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

Re: [packman] dependencies of packman subpackages from same build

2017-02-07 Diskussionsfäden Pascal Bleser 
It is indeed annoying because you end up with a setup that doesn't
play closed formats properly as it should be, with ffmpeg/libav
packages from different repositories. It also affects mplayer.

Until zypper implements that behavior (which sounds like a very good
idea to me), which won't be available until the next Leap to most
users anyhow, the best approach is probably to do hard requires with
version+release.

What we used to do in the past is to add a "pm" suffix in the release tag, e.g.
ffmpeg-1.2.3-23.pm

Might not be a bad idea to revive that for a few critical packages
(ffmpeg/libav definitely comes to mind) as it would make sure that we
would conflict release numbers with whatever is built in oss or in
multimedia:libs

Another approach would be a pattern or an empty package
("packman-ffmpeg") that just pulls everything of libav*/ffmpeg in with
hard requires -- that might sound crude but in the end, it is what
everyone wants if they add the Packman repos and want to install the
ffmpeg that's in there.

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

Re: [packman] dependencies of packman subpackages from same build

2017-02-07 Diskussionsfäden Olaf Hering 
On Tue, Feb 07, Daniel Pecka wrote:

> We were discussing this with olaf few weeks ago and I've suggested to
> ensure that proper libs from proper vendor are satisfied if you explicitely
> set your deps to be `= %version-%release' (eg they will require lib
> packages that have same version-release string) ..

Jan Engelhardt suggested that libzypp should make sure that each
subpackage comes from the same src.rpm. Its unclear if such info is in
the repo metadata. Making the change there would cover all cases.
I did not follow up on this with the zypp maintainers at
zypp-de...@opensuse.org.

My suggestion was to tweak the few affected packages (ffmpeg, gstreamer)
to make sure each subpkg comes from the same build.

> Current workaround in suse is, that ppl rely on the fact, that packman his

'zypper dup --from packman' is not a workaround.
It is the correct way to handle overlapping packages, not just for the
packman repository.

> SUSEhelp on freenode knows this factoid:
>  ``zypper dup --from packman'' is wrong. It will forcefully
> update _all_ packages that you have already in your system with theirs
> packman instances (if they exist), just imagine ...

Whoever put that there is overreacting.
Please get this removed, it is wrong. Especially with 42.2 and
Tumbleweed, they have very few overlapping packages.

Olaf


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

[packman] dependencies of packman subpackages from same build

2017-02-07 Diskussionsfäden Daniel Pecka 
Hello,

I've been solving in #suse in past weeks with several ppl same problem:
They had installed some package(s) from packman but its deps (usually
subpackages from same build) were from repo-oss .. Good example is ffmpeg,
which shall looks after the successful installation:

# rpm -qa --queryformat "%-48{sourcerpm}\t%-44{name}\t%{vendor}\n" | perl
-ne 'next if ! m/^ffmpeg-3/; print'
ffmpeg-3.2-6.5.src.rpm
libavfilter6
http://packman.links2linux.de
ffmpeg-3.2-6.5.src.rpm
libavutil55
http://packman.links2linux.de
ffmpeg-3.2-6.5.src.rpm
libavdevice57
http://packman.links2linux.de
ffmpeg-3.2-6.5.src.rpm
libswresample2
http://packman.links2linux.de
ffmpeg-3.2-6.5.src.rpm
libavresample3
http://packman.links2linux.de
ffmpeg-3.2-6.5.src.rpm
libpostproc54
http://packman.links2linux.de
ffmpeg-3.2-6.5.src.rpm
ffmpeg
http://packman.links2linux.de
ffmpeg-3.2-6.5.src.rpm
libavformat57
http://packman.links2linux.de
ffmpeg-3.2-6.5.src.rpm
libavcodec57
http://packman.links2linux.de
ffmpeg-3.2-6.5.src.rpm
libswscale4
http://packman.links2linux.de

eg all subpackages from ffmpeg family should be from same build in order
they work properly and they don't generate artifacts ... He had ofc a dirty
mix of ffmpeg and related libs to be from repo-oss and packman and it
didn't work properly ...

We were discussing this with olaf few weeks ago and I've suggested to
ensure that proper libs from proper vendor are satisfied if you explicitely
set your deps to be `= %version-%release' (eg they will require lib
packages that have same version-release string) ..

Current workaround in suse is, that ppl rely on the fact, that packman his
higher versions than suse repos and that dup --from packman is commonly
used, but my apologize, generic dup --from packman just because to fix a
libs for foo (ffmpeg or few other codecs) is something abhorrent ...

SUSEhelp on freenode knows this factoid:
 ``zypper dup --from packman'' is wrong. It will forcefully
update _all_ packages that you have already in your system with theirs
packman instances (if they exist), just imagine ...

and I'm fully agreeing with him ... If you don't have enough skills to fix
things manually you're somewhat forced to do this molestatory step ..
Please let's think about some deps related policy for packman.

regards, daniel



S Pozdravem / Best Regards
---

Daniel Pecka - dpe...@opensuse.org
SCSA, SCNA, RHCE, CLP
___
Packman mailing list
Packman@links2linux.de
http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman

Re: [packman] The great deletion

2017-02-07 Diskussionsfäden Olaf Hering 
On Tue, Feb 07, Luigi Baldoni wrote:

> weren't 13.x repos supposed to be removed by now?

13.x was removed, its still available on the mirrors.
Its time to add a 42.3 target at some point.

Olaf


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

[packman] The great deletion

2017-02-07 Diskussionsfäden Luigi Baldoni 
@Olaf
weren't 13.x repos supposed to be removed by now?
Or perhaps the plan has been scuttled?

Regards

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

Re: [packman] Handbrake - Latest version?

2017-02-07 Diskussionsfäden Olaf Hering 
On Tue, Feb 07, Pascal Bleser wrote:

> Then the better solution would be to make a static build of libbluray
> into Handbrake, but not sure that is going to work without some heavy
> patching

Well, until then the latest and greatest is only available in
Tumbleweed. There is nothing wrong with that.
Perhaps handbrake links to a special libbluray via rpath.


Olaf


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

Re: [packman] Handbrake - Latest version?

2017-02-07 Diskussionsfäden Pascal Bleser 
2017-02-07 11:00 GMT+01:00 Olaf Hering :
> On Thu, Feb 02, Pascal Bleser wrote:
[...]
> Is libbluray ABI compatible with the version that was released with Leap?
> Both share the same SONAME, but given the history of libbluray failures
> its very likely that binaries not built against the new version will
> misbehave.

Sorry Olaf, I misunderstood, you mean the other way around

True.. that might happen indeed...

Then the better solution would be to make a static build of libbluray
into Handbrake, but not sure that is going to work without some heavy
patching

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

Re: [packman] Handbrake - Latest version?

2017-02-07 Diskussionsfäden Pascal Bleser 
2017-02-07 11:00 GMT+01:00 Olaf Hering :
> On Thu, Feb 02, Pascal Bleser wrote:
>
>> Having a look at it, but I'm currently stuck because they require a
>> patched libbluray so I have to submit the changes there first.
>
> Is libbluray ABI compatible with the version that was released with Leap?
> Both share the same SONAME, but given the history of libbluray failures
> its very likely that binaries not built against the new version will
> misbehave.

The patch adds six bytes in a struct to expose the "clip_id" which is
then used by Handbrake and hence, one will definitely need to use the
latest libbluray from multimedia:libs or from Essentials at Packman
(which is just a _link to multimedia:libs/libbluray)

Unfortunately, I'm not sure how to enforce that in the package...
Could add a Provides: libbluray+clip_id that is then Required in Handbrake
Or bump up the version artificially even though it's not an upstream
version and Require that explicitly in Handbrake (Requires: libbluray*
>= ...)
Both are ugly..

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

Re: [packman] Handbrake - Latest version?

2017-02-07 Diskussionsfäden Olaf Hering 
On Thu, Feb 02, Pascal Bleser wrote:

> Having a look at it, but I'm currently stuck because they require a
> patched libbluray so I have to submit the changes there first.

Is libbluray ABI compatible with the version that was released with Leap?
Both share the same SONAME, but given the history of libbluray failures
its very likely that binaries not built against the new version will
misbehave.

Olaf


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