FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor


 
 
LinkBack Thread Tools
 
Old 08-17-2010, 01:22 PM
Ulf Winkelvos
 
Default ?

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
 
Old 08-18-2010, 03:15 AM
Evangelos Foutras
 
Default ?

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.
 
Old 08-18-2010, 03:28 AM
Evangelos Foutras
 
Default ?

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.
 
Old 08-18-2010, 09:17 PM
Vi0L0
 
Default ?

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
 
Old 08-18-2010, 10:15 PM
Vi0L0
 
Default ?

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
 
Old 09-09-2010, 08:14 PM
Gaetan Bisson
 
Default ?

Hi all,

I'd like to add truetype fonts that provide Chinese/Japanese/Korean
glyphs to [extra].

Besides TTF files, the packages would include a configuration file for
/etc/fonts/conf.avail/ which would be linked to from /etc/fonts/conf.d/
by the install script, so that the font is automatically used for glyphs
not provided by "higher-priority" fonts such as ttf-dejavu.

For instance, I've adapted the AUR package ttf-sazanami which provides a
nice font supporting Japanese characters:

http://arch.vesath.org/ttf-sazanami-20040629-4.src.tar.xz

Any comment or reason why I shouldn't do this is welcome!

Best.

--
Gaetan
 
Old 09-17-2010, 12:44 PM
Christopher Brannon
 
Default ?

* It won't build with Python 2.7.
* It only supports i686.
* Nothing depends on it.
* Apparently, pypy is now preferred.

Any objections?

-- Chris
 
Old 09-17-2010, 12:59 PM
Evangelos Foutras
 
Default ?

On Fri, Sep 17, 2010 at 3:44 PM, Christopher Brannon
<cmbrannon79@gmail.com> wrote:
> * It won't build with Python 2.7.
> * It only supports i686.
> * Nothing depends on it.
> * Apparently, pypy is now preferred.
>
> Any objections?
>
> -- Chris

No objection, let's move it.
 
Old 09-17-2010, 07:37 PM
Thorsten Tpper
 
Default ?

On Fri, 17 Sep 2010 15:59:51 +0300
Evangelos Foutras <foutrelis@gmail.com> wrote:
> On Fri, Sep 17, 2010 at 3:44 PM, Christopher Brannon
> <cmbrannon79@gmail.com> wrote:
> > * It won't build with Python 2.7.
> > * It only supports i686.
> > * Nothing depends on it.
> > * Apparently, pypy is now preferred.
> >
> > Any objections?
> >
> > -- Chris
>
> No objection, let's move it.

I agree, move it.

--
Jabber: atsutane@freethoughts.de Blog: http://atsutane.freethoughts.de/
Key: 295AFBF4 FP: 39F8 80E5 0E49 A4D1 1341 E8F9 39E4 F17F 295A FBF4
 
Old 09-18-2010, 01:21 PM
Christopher Brannon
 
Default ?

Thorsten Tpper <atsutane@freethoughts.de> writes:

> On Fri, 17 Sep 2010 15:59:51 +0300
> Evangelos Foutras <foutrelis@gmail.com> wrote:
>> On Fri, Sep 17, 2010 at 3:44 PM, Christopher Brannon
>> <cmbrannon79@gmail.com> wrote:
>> > * It won't build with Python 2.7.
>> > * It only supports i686.
>> > * Nothing depends on it.
>> > * Apparently, pypy is now preferred.
>> >
>> > Any objections?
>> >
>> > -- Chris
>>
>> No objection, let's move it.
>
> I agree, move it.

Ok, I moved it.

-- Chris
 

Thread Tools




All times are GMT. The time now is 06:01 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org