10:45 a.m.
Hello List!
I'm sure that at least the maintainers of mplayer and ffmpeg have
considered adding this. I have adjusted the SPEC files locally on my
machine to test VDPAU. Now I wanted to know if it would be possible to
include VDPAU support in packages in RPMFusion?
One main issue I'd see is that VDPAU support would make the packages
that support it nonfree wether or not they are basically free, since
they would have a BuildRequirement on xorg-x11-drv-nvidia-devel.
What are your opinions?
Greetings,
Felix
11:52 a.m.
Felix Kaechele wrote:
Now I wanted to know if it would be possible to
include VDPAU support in packages in RPMFusion?
One main issue I'd see is that VDPAU support would make the packages
that support it nonfree wether or not they are basically free, since
they would have a BuildRequirement on xorg-x11-drv-nvidia-devel.
That's not possible, we need ffmpeg in RPM Fusion free (most of RPM Fusion
free depends on it!), it can't BR stuff from nonfree.
Kevin Kofler
12:23 p.m.
Kevin Kofler wrote:
Felix Kaechele wrote:
> Now I wanted to know if it would be possible to
> include VDPAU support in packages in RPMFusion?
> One main issue I'd see is that VDPAU support would make the packages
> that support it nonfree wether or not they are basically free, since
> they would have a BuildRequirement on xorg-x11-drv-nvidia-devel.
That's not possible, we need ffmpeg in RPM Fusion free (most of RPM Fusion
free depends on it!), it can't BR stuff from nonfree.
... but you could use non-free to replace packages from free ...
It's essentially the same as to replace packages from Fedora with
RPMFusion packages, only that it would be RPMFusion replacing itselves ;)
12:46 p.m.
On Wed, Mar 4, 2009 at 1:23 PM, Ralf Corsepius <rc040203(a)freenet.de> wrote:
... but you could use non-free to replace packages from free ...
It's essentially the same as to replace packages from Fedora with RPMFusion
packages, only that it would be RPMFusion replacing itselves ;)
It is RPM Fusion policy NOT to replace packages from Fedora.
Bye,
Andrea.
12:58 p.m.
2009/3/4 Andrea Musuruane <musuruan(a)gmail.com>:
On Wed, Mar 4, 2009 at 1:23 PM, Ralf Corsepius
<rc040203(a)freenet.de> wrote:
> ... but you could use non-free to replace packages from free ...
>
> It's essentially the same as to replace packages from Fedora with RPMFusion
> packages, only that it would be RPMFusion replacing itselves ;)
It is RPM Fusion policy NOT to replace packages from Fedora.
We do not replace package, we replace library using the system dynamic linker.
In the general case:
What leaded to replacement library versus non-replacement package:
1/ It is always possible to have both packages installed.
2/ It is eventually possible to support a switch for which system wide
library to use
3/ if needed, the switch can be implemented from a given apps using
it's own LD_LIBRARY_PATH.
4/ etc
Nicolas (kwizart)
2:05 p.m.
Nicolas Chauvet wrote:
2009/3/4 Andrea Musuruane <musuruan(a)gmail.com>:
> On Wed, Mar 4, 2009 at 1:23 PM, Ralf Corsepius <rc040203(a)freenet.de> wrote:
>> ... but you could use non-free to replace packages from free ...
>>
>> It's essentially the same as to replace packages from Fedora with RPMFusion
>> packages, only that it would be RPMFusion replacing itselves ;)
> It is RPM Fusion policy NOT to replace packages from Fedora.
>
We do not replace package, we replace library using the system dynamic linker.
The result is essentially the same:
- Non deterministic system behavior
- Potential NEVR and file conflicts and "NEVR races".
Ralf
2:31 p.m.
2009/3/4 Ralf Corsepius <rc040203(a)freenet.de>:
Nicolas Chauvet wrote:
>
> 2009/3/4 Andrea Musuruane <musuruan(a)gmail.com>:
>>
>> On Wed, Mar 4, 2009 at 1:23 PM, Ralf Corsepius <rc040203(a)freenet.de>
>> wrote:
>>>
>>> ... but you could use non-free to replace packages from free ...
>>>
>>> It's essentially the same as to replace packages from Fedora with
>>> RPMFusion
>>> packages, only that it would be RPMFusion replacing itselves ;)
>>
>> It is RPM Fusion policy NOT to replace packages from Fedora.
>>
> We do not replace package, we replace library using the system dynamic
> linker.
The result is essentially the same:
I was trying to say it was not, and tried to
say why, but it was snaped....
- Non deterministic system behavior
Can you elaborate a little
bit ?
Remember that wxsvg-freeworld have been rejected because the
with_ffmpeg broke the ABI with ffmpeg_less version provided in fedora.
- Potential NEVR and file conflicts and "NEVR races".
Possible.... Do you have cases studies ? (expect the usual mesa-libGL
than shouldn't be hardcoded).
Nicolas (kwizart)
2:53 p.m.
Nicolas Chauvet wrote:
2009/3/4 Ralf Corsepius <rc040203(a)freenet.de>:
> Nicolas Chauvet wrote:
>> 2009/3/4 Andrea Musuruane <musuruan(a)gmail.com>:
>>> On Wed, Mar 4, 2009 at 1:23 PM, Ralf Corsepius <rc040203(a)freenet.de>
>>> wrote:
>>>> ... but you could use non-free to replace packages from free ...
>>>>
>>>> It's essentially the same as to replace packages from Fedora with
>>>> RPMFusion
>>>> packages, only that it would be RPMFusion replacing itselves ;)
>>> It is RPM Fusion policy NOT to replace packages from Fedora.
>>>
>> We do not replace package, we replace library using the system dynamic
>> linker.
> The result is essentially the same:
I was trying to say it was not, and tried to say why, but it was snaped....
> - Non deterministic system behavior
Can you elaborate a little bit ?
Quite simple: Your *.so's suffer from different bugs than the version in
Fedora, your *.so's provide different features than the packages in
Fedora => Different application behavior, function-wise and bugs-wise.
Whether you only replace the libs or even the applications doesn't
matter much.
The only real difference is, when only replacing the *.so's you don't
have to care about consistency wrt. applications (installation paths,
number of applications etc.).
Remember that wxsvg-freeworld have been rejected because the
with_ffmpeg broke the ABI with ffmpeg_less version provided in fedora.
Do I
understand correctly? RPMFusion has decided not provide the ffmpeg
enabled wxsvg?
What shall I think of this?
> - Potential NEVR and file conflicts and "NEVR races".
Possible.... Do you have cases studies ?
The kmods vs. akmod vs. kernel issues are
such a case.
Ralf
5:16 p.m.
2009/3/4 Ralf Corsepius <rc040203(a)freenet.de>:
...
>> - Non deterministic system behavior
>
> Can you elaborate a little bit ?
Quite simple: Your *.so's suffer from different bugs than the version in
Fedora, your *.so's provide different features than the packages in Fedora
=> Different application behavior, function-wise and bugs-wise.
Whether you only replace the libs or even the applications doesn't matter
much.
The only real difference is, when only replacing the *.so's you don't have
to care about consistency wrt. applications (installation paths, number of
applications etc.).
> Remember that wxsvg-freeworld have been rejected because the
> with_ffmpeg broke the ABI with ffmpeg_less version provided in fedora.
Do I understand correctly? RPMFusion has decided not provide the ffmpeg
enabled wxsvg?
That was the contrary actually, the ffmpeg_less version was cleaned
out from fedora to avoid replacement package problem.
According to wxsvg upstream, no project was using the ffmpeg_less
version. so rpmfusion provides the only wxsvg.
What shall I think of this?
I'm not one to tell others what
to think or not. I'm just saying that
replacement library should be avoided most, indeed.
But it shouldn't be necessary to move the whole Gnome Desktop
Environment to rpmfusion to have it full featured once it settles on
freetype-freeworld and etc.
If bugs are reported to the freetype component instead of
freetype-freeworld, that's an education issue, and that's not related
to any technical capabilities.
Now I'm kind of new to the specifics sub-pixel problem, Does the
patches were merged in freetype/cario/ upstream actually ?
Will the package work along with the version in rawhide ?
>> - Potential NEVR and file conflicts and "NEVR
races".
>
> Possible.... Do you have cases studies ?
The kmods vs. akmod vs. kernel issues are such a case.
Indeed, but the kmod/akmod/kernel problems are enought different than
the -freeworld replacement mechanism that it prevent serious
comparison IMO.
Nicolas (kwizart)
2:15 a.m.
Nicolas Chauvet wrote:
I'm not one to tell others what to think or not. I'm just
saying that
replacement library should be avoided most, indeed.
But it shouldn't be necessary to move the whole Gnome Desktop
Environment to rpmfusion to have it full featured once it settles on
freetype-freeworld and etc.
Freetype is used by a lot more than just GNOME.
If bugs are reported to the freetype component instead of
freetype-freeworld, that's an education issue, and that's not related
to any technical capabilities.
I have watchbugzilla on freetype, I'll notice if people incorrectly report
things against it and triage it. So far I haven't seen a single
freetype-freeworld bug filed against freetype.
Now I'm kind of new to the specifics sub-pixel problem, Does the
patches were merged in freetype/cario/ upstream actually ?
The freetype patches are upstream, but disabled by default (so there's one
small non-upstream patch which enables them in the build-time
configuration). The cairo patches are not upstream (AFAIK upstream rejected
them for patent reasons) and we don't have a cairo-freeworld yet.
Will the package work along with the version in rawhide ?
There's a freetype-freeworld in Rawhide which should match the Rawhide
freetype. But normally API/ABI compatibility is not an issue with freetype
anyway.
Kevin Kofler
2:25 a.m.
Ralf Corsepius wrote:
- Potential NEVR and file conflicts and "NEVR races".
NEVR conflicts are not an issue with freetype vs. freetype-freeworld because
there's no versioned requires. The plugin-type -freeworld packages (e.g.
xine-lib-extras-freeworld) actually cause more NEVR issues than the ones
which override the system library entirely (still, plugins are preferred to
overrides where possible, it's a much cleaner solution).
I haven't seen a single file conflict between freetype and
freetype-freeworld. The freetype-freeworld package omits and has always
omitted everything provided by the main freetype package. The only files it
contains are the ones listed below:
/etc/fonts/conf.d/99-DejaVu-autohinter-only.conf
/etc/ld.so.conf.d/freetype-freeworld-i386.conf
/usr/lib/freetype-freeworld
/usr/lib/freetype-freeworld/libfreetype.so.6
/usr/lib/freetype-freeworld/libfreetype.so.6.3.16
/usr/share/doc/freetype-freeworld-2.3.5
/usr/share/doc/freetype-freeworld-2.3.5/ChangeLog
/usr/share/doc/freetype-freeworld-2.3.5/FTL.TXT
/usr/share/doc/freetype-freeworld-2.3.5/GPL.TXT
/usr/share/doc/freetype-freeworld-2.3.5/LICENSE.TXT
/usr/share/doc/freetype-freeworld-2.3.5/README
none of which are likely to ever be provided by freetype. (FWIW,
99-DejaVu-autohinter-only.conf may disappear at some point. DejaVu upstream
says the bytecode interpreter should be used if possible, but their hinting
changes the weight of the font, so it looks very different, and they also
still don't have hinting for all characters, so you'll get a mix of the
hinted and autohinter looks. So whatever the default is, there will always
be complaints about it.)
As for NEVR races, they're fairly irrelevant as ABI and API compatibility is
normally not an issue for freetype. And I update freetype-freeworld
whenever freetype is changed in a way which affects freetype-freeworld as
well, so the updates will hit within hours of each other, you won't miss
anything by using the freeworld package.
That said, if you need or want neither subpixel rendering nor the bytecode
interpreter, then there's no reason to install freetype-freeworld.
Kevin Kofler
2:14 p.m.
On 04.03.2009 13:23, Ralf Corsepius wrote:
Kevin Kofler wrote:
> Felix Kaechele wrote:
>> Now I wanted to know if it would be possible to
>> include VDPAU support in packages in RPMFusion?
>> One main issue I'd see is that VDPAU support would make the packages
>> that support it nonfree wether or not they are basically free, since
>> they would have a BuildRequirement on xorg-x11-drv-nvidia-devel.
> That's not possible, we need ffmpeg in RPM Fusion free (most of RPM Fusion
> free depends on it!), it can't BR stuff from nonfree.
... but you could use non-free to replace packages from free ...
It's essentially the same as to replace packages from Fedora with
RPMFusion packages, only that it would be RPMFusion replacing itselves ;)
We normally don't do the latter for good reasons. But I'd say it's not
fully ideal, nevertheless an acceptable (and IMHO the best) compromise
if we allow packages from the RPM Fusion nonfree repo to replace
packages from the free repo, *as long* as the maintainers are the same
in both trees.
Or does anyone have a better idea? ld.so.conf-tricks and different
package names IMHO are to confusing for users.
Just my 2 cent of course.
CU
knurd
11:53 a.m.
2009/3/4 Felix Kaechele <felix(a)fetzig.org>:
Hello List!
I'm sure that at least the maintainers of mplayer and ffmpeg have considered
adding this. I have adjusted the SPEC files locally on my machine to test
VDPAU. Now I wanted to know if it would be possible to include VDPAU support
in packages in RPMFusion?
One main issue I'd see is that VDPAU support would make the packages that
support it nonfree wether or not they are basically free, since they would
have a BuildRequirement on xorg-x11-drv-nvidia-devel.
What are your opinions?
Of course, if it was the case, then we couldn't
redistribute anything
compiled with vdpau.
Actually, the library use the same mechanism as XvMC, with an open
source library wrapper exposing the public API.
Then that wrapper will open any vendor vdpau provider library, either
it is open or closed source. In the current situation, the wrapper is
provided as a binary form within the nvidia driver, but can be
packaged from the opensource version also. (cannot remember the url)
It could be possible to have the opensource version packaged in
fedora. But given the problem it will give (API version missmatch,
stability), I wouldn't recommand to do so at this time. Then, one
should notice that dispite the vdpau API is open, there is no
opensource implementation of it yet. (so it could be prevented in
fedora, for that weird reason).
Nicolas (kwizart)
Greetings,
Felix
2:19 a.m.
Nicolas Chauvet wrote:
2009/3/4 Felix Kaechele <felix(a)fetzig.org>:
> Hello List!
>
> I'm sure that at least the maintainers of mplayer and ffmpeg have considered
> adding this. I have adjusted the SPEC files locally on my machine to test
> VDPAU. Now I wanted to know if it would be possible to include VDPAU support
> in packages in RPMFusion?
> One main issue I'd see is that VDPAU support would make the packages that
> support it nonfree wether or not they are basically free, since they would
> have a BuildRequirement on xorg-x11-drv-nvidia-devel.
>
> What are your opinions?
Of course, if it was the case, then we couldn't redistribute anything
compiled with vdpau.
Actually, the library use the same mechanism as XvMC, with an open
source library wrapper exposing the public API.
Then that wrapper will open any vendor vdpau provider library, either
it is open or closed source. In the current situation, the wrapper is
provided as a binary form within the nvidia driver, but can be
packaged from the opensource version also. (cannot remember the url)
It could be possible to have the opensource version packaged in
fedora. But given the problem it will give (API version missmatch,
stability), I wouldn't recommand to do so at this time. Then, one
should notice that dispite the vdpau API is open, there is no
opensource implementation of it yet. (so it could be prevented in
fedora, for that weird reason).
Hm. I guess I should probably pay attention here myself... VDPAU support
is one of the hot ticket items in the next version of MythTV that a good
sized portion of the userbase *is* going to want. To date, I haven't
even tried building packages w/the support enabled, but I'd not even
considered that it'd require build deps that aren't in the free repo.
I'd certainly like some way to do it though, without having to move
MythTV to the non-free repo.
--jarod
3:48 p.m.
Hi there again!
I actually see a chance to have VDPAU support in the free branch. I
looked into the needed header files vdpau.h and vdpau_x11.h and those
individual files are licensed under the MIT license.
So if that is really the only thing that is required to build against
VDPAU we could have a vdpau-headers package in free to build the VDPAU
support.
If I find the time I'll further look into that.
Felix
7:41 p.m.
2009/3/18 Felix Kaechele <felix(a)fetzig.org>:
Hi there again!
I actually see a chance to have VDPAU support in the free branch. I looked
It is
aimed to go into the free branch
into the needed header files vdpau.h and vdpau_x11.h and those
individual
files are licensed under the MIT license.
So if that is really the only thing that is required to build against VDPAU
we could have a vdpau-headers package in free to build the VDPAU support.
If I find the time I'll further look into that.
I'm sorry but the license
question has never been the problem, as
libvdpau It will behave like libXvMC wrapper library.
Players are expected to link to the open source (MIT) wrapper library
which last will dlopen the appropriate backend library.
Now someone can tell a problem is to have a free implementation of the
vdpau backend library; same as it exist in the XvMC case. So libvdpau
wrapper can be allowed into Fedora. But even then, it will rely on
patented codec (mpeg-2 h264 vc-1) via the the ffmpeg library.
Nevertheless dirac support "may" be in the work and could be added.
Actually a more important problem is that libvdpau still evolve and
might be incompatible with the nvidia binary backend bundled with one
or the other version of a given driver.
So for now it seems better to push for package maintainer of
compatible players to provide an accurate build conditional from the
spec file, so the mplayer can be rebuilt with libdvpau support.
Nicolas (kwizart)
rpmfusion bugreport:
http://bugzilla.rpmfusion.org/show_bug.cgi?id=449
fedora bugreport:
https://bugzilla.redhat.com/show_bug.cgi?id=490988
5515
days inactive
5529
days old
rpmfusion-developers@lists.rpmfusion.org
15 comments
7 participants
participants (7)
-
Andrea Musuruane -
Felix Kaechele -
Jarod Wilson -
Kevin Kofler -
Nicolas Chauvet -
Ralf Corsepius -
Thorsten Leemhuis