FESCo meeting summary for 20090904

[Jon Stanley]

Minutes:
http://meetbot.fedoraproject.org/fedora-meeting/2009-09-04/fedora-meeting.2009-09-04-17.01.html
Minutes (text):
http://meetbot.fedoraproject.org/fedora-meeting/2009-09-04/fedora-meeting.2009-09-04-17.01.txt
Log:
http://meetbot.fedoraproject.org/fedora-meeting/2009-09-04/fedora-meeting.2009-09-04-17.01.log.html

--

17:01:37 <jds2001> #startmeeting FESCo meeting 2009-09-04
17:01:37 <zodbot> Meeting started Fri Sep  4 17:01:37 2009 UTC.  The
chair is jds2001. Information about MeetBot at
http://wiki.debian.org/MeetBot.
17:01:37 <zodbot> Useful Commands: #action #agreed #halp #info #idea
#link #topic.
17:01:38 <jds2001> #chair dgilmore jwb notting nirik sharkcz jds2001
j-rod skvidal Kevin_Kofler
17:01:38 <zodbot> Current chairs: Kevin_Kofler dgilmore j-rod jds2001
jwb nirik notting sharkcz skvidal
17:01:42 * skvidal is here
17:01:43 * nirik is here.
17:01:46 * sharkcz is here
17:01:49 <skvidal> woah - and so is jds2001, apparently
17:01:50 <jds2001> change in plans, I'm here :)
17:01:52 <Kevin_Kofler> Present.
17:01:57 * notting is here
17:02:17 <jds2001> alright, let me pull up the agenda :)
17:02:45 <j-rod> Here
17:02:46 <jds2001> notting: the report looks old and stale
17:02:55 <notting> jds2001: nothing else was in the tickets
17:02:55 <jds2001> do we just have those two items?
17:02:59 <jds2001> k
17:03:13 <jds2001> #topic FLP proposal
17:03:16 <jds2001> .fesco 243
17:03:18 <zodbot> jds2001: #243 (New entry of 'Build packages for
which Fedora is upstream for all language translators' review &
correction' for F12 schedule) - FESCo - Trac -
https://fedorahosted.org/fesco/ticket/243
17:03:46 <nirik> so they added a list...
17:03:54 <notting> given that list, i'm +1 for it
17:04:00 <nirik> but do we really want to add this right now for this
cycle? I guess we could.
17:04:22 <jds2001> yeah, that list is sane.
17:04:50 <jds2001> but it adds something starting today
17:05:05 <nirik> well, yesterday...
17:05:09 <jds2001> poelcat: you around?
17:05:19 <notting> realistically,it's 'build packages by beta freeze'
17:05:47 <Kevin_Kofler> The deadline is Sep 15.
17:05:56 <Kevin_Kofler> Who cares about the start date?
17:06:00 <Kevin_Kofler> We can make it today or whatever.
17:06:25 <Kevin_Kofler> I'm +1 to the proposal with the given list.
17:06:40 <nirik> how do indicate to the maintainers of those packages
that they must do a build?
17:07:12 <jds2001> i guess file a bug?
17:07:16 <Kevin_Kofler> But I'm completely -1 to the suggestion of
introducing that kind of requirements for packages which are
translated by upstream teams (or upstream projects which don't do
translations at all).
17:07:29 <jds2001> Kevin_Kofler: me too
17:07:59 * skvidal is cool w/the list too - +1
17:08:05 <jds2001> +1
17:08:16 <sharkcz> +1, the list is OK
17:08:33 * warren has a question for FESCO when it is appropriate.
17:08:33 <j-rod> I'll play balk too, +1
17:08:47 <notting> play balk? we all take a base?
17:08:51 <jds2001> warren: we only have one more item on the agenda :)
17:09:12 <jds2001> which i suspect is a noop, but oh well.....
17:09:32 <nirik> +1 from me too, but we should make sure they know
abotu this... fedora-devel-announce email? or email to all the
maintainers?
17:10:19 <jds2001> yeah, who wants to take that?
17:10:23 <jds2001> the proposal owner?
17:10:27 <jds2001> or one of us?
17:11:02 * dgilmore is here
17:11:44 <jds2001> bueller?
17:12:58 * jds2001 guesses he'll do it just to move on :)
17:13:06 <notting> i think the trans team can do it,as they're
probably in a good position to do it for future releases too
17:13:12 <sharkcz> IMO the proposal owner should create a tracker bug
+ bugs for individual packages
17:13:23 <notting> unless it becomes part of the 'normal' schedule notices
17:13:50 <jds2001> notting: i guess it would be in the future.
17:14:38 <jds2001> ok, lets put a note in the ticket
17:14:52 <jds2001> saying that this needs to be communicated by the trans team.
17:15:03 <jds2001> sound good?
17:15:32 <notting> wfm
17:15:56 <jds2001> #agreed FLP proposal is accepted, will need to be
communicated to package owners by the translation team
17:16:04 <poelcat> jds2001: yes, i'm here
17:16:06 <jds2001> #top libvdpau
17:16:19 <jds2001> poelcat: cool
17:16:31 <poelcat> now that i saw ping :)
17:16:35 <jds2001> poelcat: we just added an item to the F12 schedule :)
17:16:55 <jds2001> poelcat: the translation team wanted all packages
rebuilt for which we are upstream.
17:17:10 <poelcat> cool, i'll add it in
17:17:12 <jds2001> There's a list in https://fedorahosted.org/fesco/ticket/243
17:17:26 <poelcat> how long does that task usually take?
17:17:38 <notting> a day or three
17:17:44 <jds2001> poelcat: the translation team had it proposed to
start yesterday and go to the 15th
17:17:49 <notting> less if all the maintainers are paying attention
17:17:50 <jds2001> for future schedules :)
17:18:04 <jds2001> but yeah, it doesnt take that long
17:18:39 <poelcat> just curious so i can build the logic in the right
way... *who* builds the packages...each maintainer or automatically by
releng?
17:18:58 <jds2001> good question :)
17:19:04 <jds2001> each maintainer I'd say
17:19:36 <poelcat> who is responsible for checking to see that they
all got done?
17:19:45 <notting> it involves pulling new translations from the SCM,
so it has to be maintainers
17:19:57 <Kevin_Kofler> Right, the point is to get current translations.
17:20:01 <Kevin_Kofler> So just rebuilding is pointless.
17:20:12 <Kevin_Kofler> You need to actually fetch the latest translations.
17:20:18 <jds2001> right....brain not fully engaged today :)
17:20:19 <sharkcz> it requires new release and rebuild
17:20:36 <Kevin_Kofler> Right, a new "upstream" release is the right
way to do things.
17:20:55 * poelcat was looking at it from the perspective of "what
team owns this task" or "how we will know it is done"
17:20:55 <Kevin_Kofler> (That's also why this only makes sense for the
packages for which we're upstream.)
17:21:10 <poelcat> but i see it isn't clear cut
17:21:28 <dgilmore> there really is no way to define "packages we are
upstream for"
17:21:51 <Kevin_Kofler> This is about translations.
17:21:54 <drago01> hosted at fedorahosted?
17:21:57 <nirik> really this is 'packages we translate for'
17:22:08 <Kevin_Kofler> So the definition is "packages translated by
our translation team".
17:22:19 <Kevin_Kofler> https://fedorahosted.org/fesco/ticket/243#comment:27
17:23:35 <jds2001> so i think the translation team would be
responsible for tracking progress.
17:25:13 <nirik> how about we ask them if they are willing to handle
it, if not we come up with some other method?
17:25:18 <Kevin_Kofler> jds2001: Yeah, that makes sense.
17:25:36 <Kevin_Kofler> Who will handle it if not them?
17:26:14 <Kevin_Kofler> They want those packages to go out, they
should watch the list.
17:26:30 <notting> given a list of packages, it's scriptable. but
rel-eng has a lot on their plate
17:26:41 <jds2001> notting: even pulling translations from the SCM?
17:26:52 <notting> jds2001: no, i mean just checking that the package
has been rebuilt
17:26:58 <jds2001> oh, yeah
17:27:42 <Kevin_Kofler> Well, that's not sufficient, we also need to
check that the tarball has been updated.
17:27:51 <Kevin_Kofler> Or a patch added for the translations.
17:27:59 <Kevin_Kofler> Just rebuilding won't achieve anything.
17:28:35 <notting> true, but unless l10n comes back, that's not our
problem. can we close on this?
17:28:57 <jds2001> sure
17:29:13 <jds2001> #topic libvdpau inclusion
17:29:21 <jds2001> .fesco 238
17:29:22 <zodbot> jds2001: #238 (Can libvdpau go in Fedora?) - FESCo -
Trac - https://fedorahosted.org/fesco/ticket/238
17:29:25 <jds2001> any progress here?
17:29:35 <j-rod> so drago01 has provided quite a few bits of relevant
info, I think...
17:29:43 <j-rod> (I suck)
17:30:13 <j-rod> plummers is going to include a discussion about
implementing vdpau for nouveau
17:30:29 <j-rod> and we have precedents for other similar stuff being in fedora
17:30:38 <Kevin_Kofler> The problem is, they want to use shaders to
implement the decoding in software.
17:30:41 <j-rod> so I don't really see the reason to keep this out for now
17:30:50 <Kevin_Kofler> Well, software running on the graphics card.
17:30:55 <Kevin_Kofler> But not the actual video unit.
17:31:05 <Kevin_Kofler> Shipping that software might trigger some
patent trouble.
17:31:22 <jds2001> yeah, I'm not opposed to it being in
17:31:40 <drago01> + we have the mail from ajax which makes a lot of
sense imho (remote client)
17:31:50 <j-rod> that too
17:31:55 <jds2001> yeah, that too
17:31:58 <Kevin_Kofler> And shouldn't we wait until Nouveau (or some
other Free driver) actually implements it before allowing it in?
17:32:09 <j-rod> no.
17:32:15 <Kevin_Kofler> Why not?
17:32:16 <j-rod> why not have it already in place?
17:32:21 <j-rod> why?
17:32:33 <Kevin_Kofler> Because it doesn't benefit Fedora at all to ship it now.
17:32:38 <j-rod> yes, it does
17:32:43 <Kevin_Kofler> Plus, what program which we are allowed to
ship (i.e. not patent-encumbered) actually uses this?
17:32:48 <skvidal> Kevin_Kofler: so we only ship stuff which benefits us?
17:33:03 <Kevin_Kofler> AFAIK, other than trivial test programs which
just say whether VDPAU is available or not, nothing we can ship uses
it.
17:33:08 <jds2001> geez, a lot of my packages dont benefit is
17:33:12 <j-rod> it certainly benefits *me* in *my* use of fedora
17:33:12 <jds2001> us
17:33:22 <Kevin_Kofler> So if RPM Fusion needs it for their programs,
why shouldn't it be in RPM Fusion?
17:33:29 <jds2001> is cowsay beneficial?
17:33:30 <kwizart> libvdpau can be used to build vdpauinfo and qvdpautest
17:33:36 <kwizart> in fedora
17:33:51 <notting> in the long term grand scheme of things
17:34:01 <j-rod> and one can run them *on fedora* against a remote
system w/binary bits. (see ajax' email)
17:34:01 <notting> we need a credible video acceleration api, used by programs
17:34:01 <Kevin_Kofler> kwizart: Those are trivial test programs.
17:34:11 <notting> if upstream X devs say VDPAU is the useful API
17:34:16 <Kevin_Kofler> They aren't any more useful than "Hello World".
17:34:29 <dgilmore> notting: im agreeing with you there
17:34:31 <kwizart> indeed, but that's all... the original reason to
have libvdpau in fedora would be to have it out from rpmfusion-free
repository
17:34:32 <notting> i'm willing to consider forward-thinking adoption
in order to get apps in line for when the backends are there
17:34:36 <Kevin_Kofler> Want me to submit a review request for GNU Hello? ^^
17:34:38 <j-rod> getting an api library into the distro certainly
makes it easier to develop something that uses the api
17:34:46 <kwizart> where all sort of patent encumbered package are
17:34:50 <nirik> well, currently we don't have a 'this must be this
usefull to be in fedora' guideline.
17:34:58 <jds2001> Kevin_Kofler: you should have no issue getting that in :)
17:35:04 <drago01> define "usefull"
17:35:07 <nirik> Kevin_Kofler: it's already in.
17:35:08 <jds2001> but i think it already is.
17:35:14 <kwizart> that are illegal in the US whereas libvdpau wrapper
isn't illegal, it's a matter of choice to allow it or not
17:35:39 * XulWork installs cowsay
17:36:04 <notting> kwizart: although i still argue that libvpdau is
very lightly a 'library'
17:36:09 <Kevin_Kofler> <notting> we need a credible video
acceleration api, used by programs
17:36:18 <drago01> Kevin_Kofler:
http://koji.fedoraproject.org/koji/buildinfo?buildID=118305
17:36:25 <Kevin_Kofler> How is an API with only 2 proprietary
implementations (Nvidia and S3) a "credible" API to endorse in Fedora?
17:36:35 <j-rod> its an open api
17:36:45 <ajax> and it's a better one than the alternatives
17:36:49 <j-rod> with work being done on an open implementation
17:36:51 <ajax> libva is a joke
17:36:52 <Kevin_Kofler> We should back VAAPI instead, there's work on
actually getting support for that one into at least the intel driver.
17:36:53 <jds2001> Kevin_Kofler: upstream says it is.
17:37:03 <notting> Kevin_Kofler: there are three video acceleration
apis for linux. everyone agrees XvMC is useless, and it's generally
preferred over VAAPI
17:37:16 <j-rod> what ajax said.
17:37:25 <Kevin_Kofler> In addition, VDPAU can ONLY accelerate
patent-encumbered codecs.
17:37:31 <ajax> Kevin_Kofler: bullshit.
17:37:46 <Kevin_Kofler> Well, nothing uses it for Theora so far, it
may well be possible.
17:37:54 <Kevin_Kofler> But that needs to get implemented.
17:38:03 <Kevin_Kofler> (But it isn't any better for VAAPI.)
17:38:05 <j-rod> VDPAU *also* does things like deinterlacing
17:38:15 <kwizart> Kevin_Kofler, schroedinger have a cuda accelerated
library made with a proprietary cuda (nvidia compiler) if you want to
accelerate dirac
17:38:31 <ajax> seriously, come up with an argument that excludes
vdpau that doesn't exclude pilot-link
17:38:31 <Kevin_Kofler> What does this have to do with VDPAU?
17:38:33 <kwizart> but not all codec can be hardware accelerated
17:38:46 <ajax> or libgpod
17:39:10 <j-rod> can we just vote on this? I'm only hearing one
dissenter, unless the rest of the dissenters are being silent...
17:39:20 <drago01>
http://www.nvnews.net/vbulletin/showthread.php?t=123091 it does more
than just decoding
17:39:24 <kwizart> dirac is the only codec (patent free) that is
designed to be hw accelerated
17:39:32 <nirik> I'm +1 here until/unless we have a more general
guideline that says only things meeting some level of usefullness can
get in. Any such guideline would have to address the packages already
in like this one too.
17:39:34 <j-rod> +1, libvdpau is acceptable for inclusion in fedora
17:39:35 <sharkcz> libvdpau inclusion has +1 from me
17:39:49 <Kevin_Kofler> kwizart: So why do we want to ship
acceleration libraries then?
17:39:54 <jds2001> +1 here too
17:39:55 <Kevin_Kofler> They'll be by definition useless in Fedora.
17:40:11 <Kevin_Kofler> -1 to libvdpau from me.
17:40:18 <notting> +1 from me (i think i was +1 when this was
originally proposed)
17:40:25 <skvidal> +1
17:40:44 <jds2001> #agreed libvdpau is acceptable for inclusion in Fedora
17:40:51 <kwizart> Kevin_Kofler, to allow decoding and eventually to transcode
17:40:57 <Kevin_Kofler> And once again we're helping proprietary drivers. :-/
17:41:00 <jds2001> #topic Open Floor
17:41:06 <jds2001> warren: you had something?
17:41:12 <Kevin_Kofler> kwizart: Nope.
17:41:15 <warren> i'm not sure if i want to ask anymore
17:41:24 <Kevin_Kofler> You need a proprietary driver which we won't
ship for that.
17:41:27 <warren> the spirit has been beaten out of me
17:41:40 <jds2001> Kevin_Kofler: we've moved on
17:41:43 <Kevin_Kofler> Nouveau's implementation will also not be
shippable if it does the patent-encumbered stuff in the driver.
17:41:47 <dgilmore> warren: just ask
17:41:55 <Kevin_Kofler> If not, it will be the app which is not shippable.
17:41:59 <warren> does fesco have any opinion on dracut by default for F-12?
17:42:10 <Kevin_Kofler> The actual video unit is not documented and
will not be supported by Nouveau any time soon.
17:42:27 <warren> (have folks been paying enough attention to form an
educated opinion?)
17:42:28 <drago01> Kevin_Kofler: there is a vdpau mpeg2 gstreamer
plugin ... it should be shippable afaik but IANAL
17:42:32 <dgilmore> warren: i think its fine.  its working well for me
17:42:41 <Kevin_Kofler> drago01: But the driver is not.
17:42:42 <jds2001> warren: Iv'e actually not been paying that much attention
17:42:47 <Kevin_Kofler> So Fedora will not support it out of the box.
17:42:52 <Kevin_Kofler> So we gain nothing by shipping VDPAU.
17:42:52 <jds2001> drago01, Kevin_Kofler: please take this elsewehre
17:42:53 <dgilmore> Kevin_Kofler: please be quiet we have moved on
17:43:02 <nirik> it seems to work, but I am concerned with the source
issue thats being mentioned on the list.
17:43:13 <kwizart> we do not shipping VDPAU that was not the question
that were asked
17:43:16 <dgilmore> warren: what issues are you seeing that you think
we should not use it
17:43:29 <dgilmore> warren: and is there bugs,  or a tracker to point us at/
17:43:32 <warren> nirik: the dracut developers seem amenable to go
back to generating the initrd in kernel %post instead of %build
17:43:34 <warren> which I'm in favor of
17:43:54 <Kevin_Kofler> kwizart: I mean shipping libvdpau, which just
got approved.
17:44:00 <dgilmore> warren: why?
17:44:02 <notting> warren: i'm fine with it technically (there are
bugs, none of which seem insurmountable). i think we likely will need
to move to host-created initramfs in %post for the legal reason
17:44:10 <nirik> I thought one of the advantages of dracut was that
everyone had the initrd. ;(
17:44:14 <warren> dgilmore: there aren't many known bugs, just
jkeating is trying to force it out of F-12 by default
17:44:23 <warren> thus I'm asking if anybody has any objections to it
17:44:29 <drago01> add a dracut source package which contains the sources?
17:44:30 <warren> notting: yeah, I'm totally in favor of that for
technical reasons
17:44:38 <warren> drago01: that isin't the issue
17:44:45 <drago01> it is
17:44:56 <Kevin_Kofler> notting: Huh? What legal reasons?
17:45:01 <nirik> drago01: sources of all the things that it uses?
17:45:33 <notting> Kevin_Kofler: building the initramfs at package
build time from binaries in the build root makes source compliance
messy. see thread.
17:45:36 <drago01> nirik: or a tar archive of the srpms or whatever
17:45:43 <nirik> yuck
17:46:08 <warren> notting: is that the main concern then?
17:46:21 <drago01> I mean wtf ... we have the patches in cvs and the
tarballs are available upstream
17:46:32 <notting> warren: that is *my* concern. i can not speak for others.
17:46:34 <drago01> so if anyone asks for sources we can point him to that
17:46:34 <dgilmore> i have 4 or 5 systems using dracut initrds  and
all of them just work
17:46:48 <jds2001> drago01: but how do you exactly reproduce the buildroot?
17:46:52 <Kevin_Kofler> We ignore that concern for pretty much
everything else, e.g. statically-linked stuff.
17:46:54 <jds2001> drago01: i think that's the problem
17:46:55 <nirik> drago01: 'I would like the source for this
initrd-generic please' 'oh, go look around in cvs lookaside cache and
cvs and you might be able to find them'
17:47:19 * nirik finds that lame
17:47:21 <Kevin_Kofler> And pretty much ALL binaries are statically
linked to libc_nonshared.a.
17:48:22 <drago01> jds2001: how do you do this for random $package
where the srpm is no longer available (ie. some rawhide build)
17:49:29 * nirik suggests folks continue the thread on devel about
this? are we going to solve it here?
17:49:44 <jds2001> drago01: if it ever made it to rawhide it's
retained (aiui, dgilmore could elaborate more)
17:49:47 <warren> well, you seem to have answered my question
17:49:52 <jds2001> the SRPM that is.
17:49:53 <warren> there are no objections to it here
17:50:24 * adamw raises hand - i have an open floor topic if that's okay
17:50:40 <jds2001> drago01: it's only reaped if for example it was in
updates-candidate or updates-testing but never made it further it
could be reaped.
17:50:51 <jds2001> dgilmore: correct me if im wrong, not my area of expertise :)
17:51:23 <jds2001> adamw: what's up?
17:51:39 <adamw> going back to the video acceleration stuff - last
time it was discussed, i asked about libva, and got general approval
that it was fine for fedora
17:51:46 <adamw> so i've opened a review request at
https://bugzilla.redhat.com/show_bug.cgi?id=518546
17:51:47 <dgilmore> jds2001: not correct
17:51:48 <buggbot> Bug 518546: medium, medium, ---, ismael, NEW,
Review Request: libva - VAAPI video playback acceleration
17:52:04 <dgilmore> jds2001: we do garbace collection on koji
17:52:10 <adamw> however, i've just thought about it, and i realized
it includes one working backend, which does MPEG-1/2 acceleration for
intel 965 chips
17:52:24 <adamw> is this problematic from a patent perspective?
apparently we have problems with mpeg
17:52:35 <dgilmore> if we did not clean up packages we would be using
15T+ of disk rather than 8.6T
17:52:51 <notting> adamw: ...what *exactly* is it doing with the stream?
17:52:52 <drago01> adamw: if it is done in hardware itr shouldn't I
would just make the bug block FE-LEGAL
17:53:00 <mether> adamw, isnt that a legal question? FESCo cant answer
that for you
17:53:04 <adamw> if so, who would be sufficiently clueful to take a
look at the code and see if it actually does anything infringing? i
don't know how much happens in the driver and how much is done by the
hardware, i'm not enough of a coder to tell
17:53:10 <adamw> mether: my question is there :)
17:53:40 <adamw> make it block FE-LEGAL is the right way forward?
17:53:45 <Kevin_Kofler> Yes.
17:53:48 <notting> adamw: yeah, FE-LEGAL
17:53:49 <adamw> alrighty, thanks.
17:54:16 <jds2001> mether: btw, I suck and didn't forward out your
provenpackager request in a timely manner.
17:54:23 <kwizart> adamw, usually for XvMC which already implemented
mpeg-2 hw decode, that was requiring  ffmpeg or libmpeg2 codec library
17:54:25 <jds2001> mether: it will be on the agenda next week
17:54:29 <Kevin_Kofler> Then spot is going to try to sort it out, and
he may ask lawyers and/or developers experienced with the area for
expertise.
17:55:04 <notting> adamw: as an example, we ship the mpeg demux gst
plugin in fedora, and file(1) can identify them. so if it's
recognizing the stream and feeding it to the hardware, it might be
fine
17:55:13 <dgilmore> warren: I think its something that needs to be
hashed out. but im personally in favour of the generic initrd. we just
need to make sure we cover all bases
17:55:33 <warren> I personally don't care about %build vs %post
17:55:36 <ajax> we ship plenty of things that can have non-free backends.
17:55:52 <warren> I'm only alarmed that dracut might be pulled from F-12.
17:56:55 <adamw> notting: sure, i understand that there's a continuum
there, which is why i'm asking; i'm not really a coder so i can't look
at the code and actually grok what it's doing. anyway, have asked on
the bug. thanks.
17:57:41 <adamw> ajax: oh sure, i intend to ship libva either way, the
question is just whether i can include the i965 MPEG backend in the
package or not.
17:58:43 <ajax> adamw: i'm going to go with "probably".  we do a
similar thing for s3tc support in opengl. we can hand pre-compressed
textures to the hardware and _it_ can decode them, but we can't ship
anything that implements the compression or expansion in software.
17:59:16 <jds2001> anything else for today?
17:59:23 <ajax> 965 pretty much has a hardware mpeg decoder, so it's
largely the same thing.  parsing the file format and extracting frames
isn't patented; but the compression itself is.
17:59:41 <adamw> ajax: if you could help out with the review that'd be
great :) i suspect you'd be able to read the code, hehe
18:00:03 * j-rod likes hardware video decoders...
18:00:09 <ajax> (the same argument applies to vdpau, btw.  it's just
enabling the hardware decoder.)
18:00:47 <Kevin_Kofler> The problem with VDPAU is that all its
currently available backends are proprietary software.
18:02:26 <kwizart> proprietary backend /patented codec
18:02:34 <ajax> yes, you've mentioned that.  i'm still not sure why
you think that's relevant.
18:02:49 <kwizart> at least work is been done with dirac hw decoding
via nvidia gpu
18:03:01 <kwizart> nvidia gpu are capable to hw decode dirac
18:03:07 <Kevin_Kofler> But we don't ship that in Fedora.
18:03:22 <Kevin_Kofler> (and we can't, because it requires the
proprietary CUDA to build)
18:03:35 <kwizart> either or not we ship isn' the matter
18:03:37 <nirik> we also ship a lot of MPD frontends, but MPD is not
in fedora. ;)
18:03:50 <ajax> so you're saying if i'd implement mpeg decode for 965,
you'd be okay with vdpau.
18:04:00 <drago01> what about stuff like libiphone
18:04:00 <kwizart> the problem is to be legal to ship
18:04:04 <nirik> we ship Oracle perl packages that convert various
oracle things...
18:04:06 <Kevin_Kofler> ajax: Yes. :-)
18:04:07 <ajax> but since i haven't jumped through your hoop yet,
you're not okay with it.
18:04:09 <drago01> we don't ship the iphone os in fedora
18:05:01 <ajax> and you'd prefer to keep it out _until_ someone jumps
through that hoop.
18:05:31 * nirik wonders if we have anything more or can end the meeting now?
18:05:36 <ajax> that seems like a pretty weak distinction.
18:05:42 <jds2001> just what i was thinking
18:05:45 <ajax> anyway, gotta go read libva now.
18:05:57 <Kevin_Kofler> It's the distinction between an API useful for
Free Software and an API useless for it.
18:06:09 <notting> i think we've finishd discussion
18:06:11 <Kevin_Kofler> But whatever, I got outvoted anyway.
18:06:21 <notting> erm, 'finished the agenda'
18:06:33 <drago01> adamw: btw can you provide links that work (the
last one in your review ticket doesn't)
18:06:56 * jds2001 ends the meeting in 30
18:07:00 <adamw> drago01: yeah, i meant to update that, i realized
after five minutes that putting all this stuff in fedorapeople was a
bad idea :) i'll update the link
18:07:05 <kwizart> libvdpau is free software, they have merged a patch
from me: http://cgit.freedesktop.org/~aplattner/libvdpau/commit/?id=50925e6b95aa9eaebd26c35f1f8f6af7acec4814
18:07:26 <jds2001> kwizart: i dont think there's debate about that
18:07:29 <jds2001> anyhow.
18:07:29 <Kevin_Kofler> Free software with non-Free dependencies is
"free, but shackled".
18:07:35 <jds2001> #endmeeting