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