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 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
