[aur-general] Shall I move mplayer-vaapi to [community]?
Hi guys, I've been using mplayer-vaapi [1] with my Radeon HD 4200 IGP for a couple of months now and I think it's a very useful package. Recently, its maintainer in the AUR dropped it because he switched to libvdpau. So, I've been thinking of adopting it and moving it to [community]. I haven't done anything yet, as I'm a bit unsure of whether I should go forward with the move. On one hand, a binary package for mplayer-vaapi is included in the unofficial, but well maintained, catalyst repo [2], but on the other hand it still is a useful package and it only has an additional dependency on libva (available in [extra]) compared to the straight mplayer package; it'd be nice to have it in [community]. On an semi-related note, I was also thinking of moving xvba-video to [community] as well, but it depends on the catalyst package which has a very complicated PKGBUILD (i.e. manual installation of every file). Therefore, I don't have any plans to mess with that for now. :P Thoughts? :> ---- [1] http://aur.archlinux.org/packages.php?ID=35321 [2] http://wiki.archlinux.org/index.php/ATI_Catalyst#Catalyst.27s_repositories
On 08/17/2010 05:14 AM, Evangelos Foutras wrote:
Hi guys,
I've been using mplayer-vaapi [1] with my Radeon HD 4200 IGP for a couple of months now and I think it's a very useful package. Recently, its maintainer in the AUR dropped it because he switched to libvdpau. So, I've been thinking of adopting it and moving it to [community].
I haven't done anything yet, as I'm a bit unsure of whether I should go forward with the move. On one hand, a binary package for mplayer-vaapi is included in the unofficial, but well maintained, catalyst repo [2], but on the other hand it still is a useful package and it only has an additional dependency on libva (available in [extra]) compared to the straight mplayer package; it'd be nice to have it in [community].
Thomas would be very happy to have this in our repos. :) I don't have any particular issues with it but this open a road in which we allowed patched applications in our repos. This patch wasn't accepted upstream by mplayer devs yet.
On an semi-related note, I was also thinking of moving xvba-video to [community] as well, but it depends on the catalyst package which has a very complicated PKGBUILD (i.e. manual installation of every file). Therefore, I don't have any plans to mess with that for now. :P
Did catalyst resolved the issues that we had with it some time ago? If yes catalyst should be repacked properly if you want it in repos, like nvidia is. -- Ionuț
Am Dienstag, den 17.08.2010, 08:23 +0200 schrieb Ionuț Bîru <ibiru@archlinux.org>:
On 08/17/2010 05:14 AM, Evangelos Foutras wrote:
Hi guys,
I've been using mplayer-vaapi [1] with my Radeon HD 4200 IGP for a couple of months now and I think it's a very useful package. Recently, its maintainer in the AUR dropped it because he switched to libvdpau. So, I've been thinking of adopting it and moving it to [community].
I haven't done anything yet, as I'm a bit unsure of whether I should go forward with the move. On one hand, a binary package for mplayer-vaapi is included in the unofficial, but well maintained, catalyst repo [2], but on the other hand it still is a useful package and it only has an additional dependency on libva (available in [extra]) compared to the straight mplayer package; it'd be nice to have it in [community].
Thomas would be very happy to have this in our repos. :) I don't have any particular issues with it but this open a road in which we allowed patched applications in our repos.
This patch wasn't accepted upstream by mplayer devs yet.
Last time i checked there weren't even any recent discussion on the mailing-list. There was some discussion between Gwenole (libva-sds dev) and the mplayer dev team last year... So far libva(sds-patched) is supported by ffmpeg, but the output related things are not in mplayer. Would be an interesting thing to know, if there still is hope for the rest of Gwenole's patches to be accepeted. If you, Evangelos, decide to move this to community, you should however leave the lazy road i took with this package! :) I.e. apply the sds patches to arch's current mplayer source snapshot, instead of simply building the full sds-patched mplayer source. I ran into dependency troubles several times and had to hack around that, or wait until some deps were updated. I think, as Ionuț stated, this is rather "political thing" to discuss, but the package itself. The package has always worked pretty good for me, except for minor issues with subtitle-rendering and there have not been many complaints in the comments, that I remember. Regards, Ulf
On 17/08/10 16:22, Ulf Winkelvos wrote:
If you, Evangelos, decide to move this to community, you should however leave the lazy road i took with this package! :) I.e. apply the sds patches to arch's current mplayer source snapshot, instead of simply building the full sds-patched mplayer source. I ran into dependency troubles several times and had to hack around that, or wait until some deps were updated.
Thanks for the tip. I uploaded a package based on the mplayer package from [extra]. Basically, I just added the SDS patches to it. Seems to be working well. :)
On 17/08/10 09:23, Ionuț Bîru wrote:
On 08/17/2010 05:14 AM, Evangelos Foutras wrote:
Hi guys,
I've been using mplayer-vaapi [1] with my Radeon HD 4200 IGP for a couple of months now and I think it's a very useful package. Recently, its maintainer in the AUR dropped it because he switched to libvdpau. So, I've been thinking of adopting it and moving it to [community].
I haven't done anything yet, as I'm a bit unsure of whether I should go forward with the move. On one hand, a binary package for mplayer-vaapi is included in the unofficial, but well maintained, catalyst repo [2], but on the other hand it still is a useful package and it only has an additional dependency on libva (available in [extra]) compared to the straight mplayer package; it'd be nice to have it in [community].
Thomas would be very happy to have this in our repos. :) I don't have any particular issues with it but this open a road in which we allowed patched applications in our repos.
I see your point, but it's an important feature for the people that want it (me included) and the package footprint is around 8-9 MiB, so I believe it's worth having in our repos! :> Hopefully, in the future these patches will be included in the main mplayer source code and this package will be made redundant. For the moment, I have gone ahead and uploaded mplayer-vaapi to [community], based on your mplayer PKGBUILD. :)
This patch wasn't accepted upstream by mplayer devs yet.
On an semi-related note, I was also thinking of moving xvba-video to [community] as well, but it depends on the catalyst package which has a very complicated PKGBUILD (i.e. manual installation of every file). Therefore, I don't have any plans to mess with that for now. :P
Did catalyst resolved the issues that we had with it some time ago? If yes catalyst should be repacked properly if you want it in repos, like nvidia is.
I'm not exactly sure what the situation with the Catalyst driver is. I'm using a package for it from the [catalyst] repo, and it's working pretty well. However, the PKGBUILD in the AUR looks pretty scary. :P I might have a look at it at some point, as I wouldn't mind maintaining it if I was able to figure it out.
On Wednesday 18 August 2010, at 05:28:02, Evangelos Foutras <foutrelis@gmail.com> wrote:
I'm not exactly sure what the situation with the Catalyst driver is. I'm using a package for it from the [catalyst] repo, and it's working pretty well. However, the PKGBUILD in the AUR looks pretty scary. :P
I might have a look at it at some point, as I wouldn't mind maintaining it if I was able to figure it out.
Well it could look kinda scary, but it's very usefull especially when you are using more than one, stock kernel. Plus i believe that idea of 'automatic recompilation of fglrx module when kernel upadate' is very good, and yes - i know it's bypassing arch way - so it's optionall. Also MrElendig said that this new catalyst package could be not safe - ie. when building of fglrx module fails, so [catalyst] repo is providing package called catalyst-module- only (with module for stock kernel) so users with compilation problems could use it. Actually i can provide you nvidia-like catalyst and catalyst-utils pkgbuilds in minutes, but like i said catalyst isn't ready for landing in official repo. You would have to remove it very quickly, because arch can't wait with kernel/xserver updates for months just because of one, poor supported, blob. -- Greetz Vi0L0 gpg: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x561FEC2AFFC7E56E
On Tuesday 17 August 2010, at 08:23:17, Ionuț Bîru <ibiru@archlinux.org> wrote:
Did catalyst resolved the issues that we had with it some time ago? If yes catalyst should be repacked properly if you want it in repos, like nvidia is.
No, catalyst is still away from good support of upstream kernel/xorg-server. For xserver 1.7 support we had to wait for nearly 5 months! Plus we have to wait 2 months for them to put my 1 line patch which serve kernel 2.6.34 support, 1 line! Sure it's now supporting xserver 1.8 and kernels up to 2.6.36-rc1 but it's bad idea to put it to official repo just because of that. Catalyst actually support just few distros, and that distros are generally far from upstream. I was actually crossing all my fingers for xserver 1.9 (which has new abi) in ubuntu 10.10. But it was worth it... <sigh> so we don't need to wait for new xserver support for 5 months, just 2... Anyhow my point is that catalyst atm isn't ready to land in official repo, it's far far away from Arch Way, and i think that catalyst should show at least one year of good support before we could put it to official repo again. -- Greetz Vi0L0 gpg: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x561FEC2AFFC7E56E
participants (4)
-
Evangelos Foutras
-
Ionuț Bîru
-
Ulf Winkelvos
-
Vi0L0