Minutes: http://meetbot.fedoraproject.org/fedora-meeting/2009-08-14/fedora-meeting.2009-08-14-17.01.html Minutes (text): http://meetbot.fedoraproject.org/fedora-meeting/2009-08-14/fedora-meeting.2009-08-14-17.01.txt Log: http://meetbot.fedoraproject.org/fedora-meeting/2009-08-14/fedora-meeting.2009-08-14-17.01.log.html -- 17:01:23 <jds2001> #startmeeting FESCo meeting 2009/08/14 17:01:25 <jds2001> #chair dgilmore jwb notting nirik sharkcz jds2001 j-rod skvidal Kevin_Kofler 17:01:41 * nirik is here. 17:01:43 <jds2001> so notting and skvidal are unhere 17:02:04 <Kevin_Kofler> Present. 17:02:44 * dgilmore is here 17:03:02 * j-rod here 17:03:27 <jds2001> cool 17:03:42 <jds2001> #topic apcuspd static linking 17:03:47 <jds2001> .fesco 235 17:04:16 <Kevin_Kofler> Can't the libs go to /lib instead? 17:04:26 <Kevin_Kofler> Static linking sounds like a bad solution to me. 17:04:44 <j-rod> please to be not the linking of static 17:04:46 <jds2001> how many are there? 17:04:47 <Kevin_Kofler> But there clearly is a problem there, stuff in / must not require libs from /usr. 17:04:57 <nirik> .bugzilla bug 346271 17:04:59 <bugbot> Bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=346271 low, low, ---, notting, ASSIGNED, halt initscript does not properly handle apcupsd shutdowns 17:05:28 <nirik> it's other packages /usr/lib/ libs that it's linked to... 17:05:45 <nirik> snmp and sensors 17:05:53 <Kevin_Kofler> Those need to be moved to /lib. 17:06:09 <jds2001> well my rootfs is typically like 1GB 17:06:10 <Kevin_Kofler> Statically linking strikes me as the wrong solution to a real problem. 17:06:19 <dgilmore> i thought we had already agreed that we dont support /usr of a seperate filesystem 17:06:39 <jds2001> so if we move everything in the world to /lib, then I've got a problem. 17:07:01 <nirik> dgilmore: yeah, I wonder how many people aside from jds2001 do seperate /usr anymore. 17:07:23 * jds2001 doesnt think i'm unique :) 17:07:36 <nirik> the guide suggests against it. 17:07:37 <dgilmore> jds2001: but you are 17:07:39 <nirik> http://docs.fedoraproject.org/install-guide/f11/en-US/html/s2-diskpartrecommend-x86.html#sn-partitioning-advice 17:07:48 * jds2001 can point to several thousand systems at $DAYJOB that have a separate /usr 17:07:49 <nirik> "Do not place /usr on a separate partition" 17:08:08 <nirik> jds2001: is that seperate /usr on local disk? or via net? 17:08:15 <jds2001> local disk 17:08:17 <dgilmore> im pretty sure last release we said that /usr on a seperate filesystem was not supported 17:08:38 <nirik> then in this case I don't think it matters. This is only a problem if we shut down net and can't use /usr/lib/ 17:08:39 <jds2001> and they're RHEL/Solaris, but the point remains. 17:09:03 <jds2001> I think remote /usr isn't supported. 17:09:05 <nirik> so this case is not 'seperate /usr' but 'seperate /usr on network' 17:09:11 <nirik> (unless I am reading this wrong) 17:09:29 <jds2001> pretty much how i read it too. 17:09:42 <dgilmore> nirik: which is really not supported 17:10:01 <nirik> humm... or is it... does it umount other fses before it runs that? 17:11:17 * nirik re-reads the patch and halt script. 17:12:22 <nirik> no, it's all non root mounts I think... 17:12:23 <Kevin_Kofler> How much of the static libs gets linked in if we do the static linking? If it doesn't actually save space, then it's a no-brainer to -1 it and tell them to just move the stuff to /lib instead if they want to support this usecase. 17:13:07 <dgilmore> its a seperate /usr 17:13:18 <nirik> yeah, I don't know how far it goes adding those 2 packages and their deps to /lib 17:13:26 <Kevin_Kofler> One advantage of moving to /lib is that it costs essentially nothing for those who don't have separate /usr unlike static linking. 17:13:53 <Kevin_Kofler> So for the vast majority of people, if the problem is to be solved, moving to /lib is the best solution. 17:13:57 <dgilmore> the answer here i believe is dont have a seperate /usr 17:14:49 <dgilmore> it doesnt make sense like it used to anymore 17:14:55 <Kevin_Kofler> Why can't we just move the libs to /lib? For all those without a separate /usr, it won't change a thing. 17:15:13 <dgilmore> Kevin_Kofler: where do we stop? 17:15:25 <Kevin_Kofler> For those few folks with a separate /usr, it'll solve their problem, and if their / is not big enough, they'll just have to fix it. 17:15:50 <Kevin_Kofler> dgilmore: Good question. Maybe we should drop /usr entirely like HURD or make it an alias for / like MSYS? ;-) 17:15:51 <nirik> if it's just 2 packages for this I'd be ok with moving them to /lib... but if it pulls in a bunch of stuff we should just say no. 17:16:21 <nirik> in any case I don't think we should static link unless there is a more compelling reason. 17:16:27 <jds2001> yeah, I'm wondering how much stuff it drags in 17:16:39 <jds2001> static linking is bad, mmmkkaayyy :) 17:16:42 <dgilmore> Do not place /usr on a separate partition If /usr is on a separate partition from /, the boot process becomes much more complex, and in some situations (like installations on iSCSI drives), might not work at all. 17:16:48 <dgilmore> from the install guide 17:17:11 <jds2001> how does it become more complex? 17:17:24 <jds2001> the /usr gets mounted in rc.sysinit 17:17:28 <Kevin_Kofler> Can we vote on not allowing the static linking exception first of all? 17:17:33 <Kevin_Kofler> I think we all agree on that part. 17:17:39 <dgilmore> we likely have other things people consider critical to propper functionality that live in /usr 17:17:42 <jds2001> sure, -1 17:17:58 <Kevin_Kofler> -1 to the exception here too. 17:18:00 <dgilmore> static linking -1 17:18:09 <nirik> -1 here as well. 17:18:15 <jds2001> dgilmore: i didnt say your system would be very functional except for enough to perhaps get a shell. 17:18:15 <nirik> notting was +1 in the ticket 17:18:21 <dgilmore> diabling having a seperate /usr in anacond +1 17:18:40 <dgilmore> diabling having a seperate /usr in anaconda +1 17:18:45 <jds2001> dgilmore: that'll fly over like a lead balloon :) 17:18:52 <Kevin_Kofler> We need one more -1 to the exception to throw it out. 17:18:55 <j-rod> -1, die static linking, die 17:19:38 <jds2001> #agreed apcupsd cannot be statically linked. 17:19:49 <jds2001> is there more on this?] 17:20:12 * jds2001 moves on 17:20:21 <jds2001> #topic FPC Items 17:20:26 <jds2001> .fesco 241 17:20:29 <jds2001> MPI? 17:20:42 <jds2001> There was something on the page that was confusing to me, let me find it. 17:21:24 <jds2001> ahh - Each MPI build of shared libraries SHOULD have a separate -libs subpackage for the libraries (e.g. foo-mpich2-libs). As in the case of MPI compilers, NO library configuration (in /etc/ld.so.conf.d) MUST be made. 17:21:25 <nirik> +1 here for MPI. It makes sense to me... 17:21:59 <jds2001> that seems to be as "library configuration in /etc/ld.so.conf.d MUST NOT be made" 17:22:15 <jds2001> or am I reading it wrong? 17:22:55 <Kevin_Kofler> Those guidelines are really vomit-inducing, why can't we just pick one default MPI implementation and one default compiler? (g77 needs to die!) :-/ 17:23:04 <jds2001> +1 with that minor cleanup 17:23:15 <dgilmore> +1 for MPI 17:23:23 <jds2001> Kevin_Kofler: because different MPI compilers work better with different workloads 17:23:24 <j-rod> +1 mpi 17:23:32 <j-rod> and different interconnects 17:23:35 <jds2001> notting was +1 17:23:54 <j-rod> er, different mpi implementations, not compilers, work better with different interconnects 17:24:11 <jds2001> #agreed MPI guidelines are accepted 17:24:16 <jds2001> Environment modules? 17:24:22 <jds2001> Pretty cool, +1 17:24:23 <Kevin_Kofler> "Also, people doing high performance computing may want to use more efficient compilers than the default one in Fedora (gcc)" -> So we're doing this to support proprietary compilers? :-/ 17:24:49 <nirik> +1 on env modules. I hope they get used now in more places that they should be... 17:24:56 <j-rod> +1 for env modules 17:25:18 <nirik> Kevin_Kofler: we are doing this to allow MPI/cluster people to pick their MPI implementation(s) 17:25:26 <j-rod> and compilers 17:26:49 <jds2001> anyhow, we need two more for env modules 17:27:58 <j-rod> jds2001: I read notting's comment to mean "+1 to every one of these items on the FPC list" 17:28:07 <jds2001> yep, me too 17:28:15 <j-rod> so we only need one more. :) 17:28:21 <jds2001> true :) 17:28:48 <jds2001> and skvidal said he'd make comments but didn't, that slakcer! 17:28:49 <Kevin_Kofler> +1 to environment modules, they aren't any more scary than the stuff qt3 and friends stuff into /etc/profile.d systemwide. 17:29:07 <jds2001> in fact significantly less scary, imo :) 17:29:16 <jds2001> anyhow 17:29:31 <jds2001> #agreed environemnt modules guideline is accepted 17:29:49 <jds2001> correcting the ant sample spec? 17:29:49 <nirik> Kevin_Kofler: I wonder if qt couldn't use them too? :) 17:29:58 <j-rod> +1 for version 1 of the java ant tweak, trivial fixup 17:30:10 <jds2001> um, we're voting on version 2 17:30:17 <Kevin_Kofler> nirik: Quite possible, we'll have to look into it. 17:30:20 <j-rod> uh, what? 17:30:23 <jds2001> that's what FPC put forward. 17:30:36 <dgilmore> +1 for the ant change 17:30:38 <jds2001> the second option, with the two find commands, 17:30:40 <j-rod> "I propose the command to read either 'find \(...' or 'find; find;' 17:30:40 <jds2001> +1 17:30:45 <nirik> +1 as well here... fix it up. 17:30:49 <Kevin_Kofler> IMHO the one line solution is better... 17:30:57 <Kevin_Kofler> But any is better than the non-working command. :-) 17:31:07 <Kevin_Kofler> So +1. 17:31:18 <j-rod> jds2001: wait, where is one or the other of those put forward over the other? 17:31:29 <jds2001> j-rod: in the ticket 17:31:45 <j-rod> oh. the '(option 2)' at the end. 17:31:50 <j-rod> missed that, sorry 17:31:53 <jds2001> Correct ant sample spec : https://fedoraproject.org/wiki/PackagingDrafts/JavaAntSampleSpec (option 2) 17:32:06 <j-rod> meh. I like the one-liner better, but whatever. working is better than not. 17:32:24 <Kevin_Kofler> j-rod: Me too. 17:32:35 <Kevin_Kofler> I don't see why we should be running 2 commands when one will do, it's slower. 17:32:42 <Kevin_Kofler> It has to traverse the file system twice. 17:32:48 <jds2001> abadger1999: you around? 17:32:52 <jds2001> why did 17:33:01 <abadger1999> Yep. What's up? 17:33:04 <jds2001> FPC choose option 2 over option 1 for the ant spec? 17:33:09 <j-rod> well, not really that much slower, the second find will be pretty snappy, since everything's going to be cached in memory 17:33:12 <dgilmore> to me it was that you could use either of the wo new ways 17:33:15 <rdieter> jds2001: I think the motivation was that it was easier to parse, read 17:33:26 <jds2001> makes sense. 17:34:44 <jds2001> #agreed Java ant sample spec correction is accepted 17:34:51 <jds2001> notting was +1, and I counted 4 :) 17:35:02 <jds2001> R Guidelines? 17:35:23 <j-rod> +1, looks sane 17:35:24 <nirik> +1 to R guidelines here. 17:35:31 <jds2001> +1 17:36:12 <Kevin_Kofler> +1 17:36:40 <jds2001> #agreed R Guidelines update is approved 17:36:49 <dgilmore> +1 to R 17:36:59 <jds2001> Droping the scrollkeeper scriptlets? 17:37:01 <j-rod> +1, kill scrollkeeper with fire 17:37:08 <jds2001> +1 17:37:17 <jds2001> j-rod: still needed in EPEL :( 17:37:23 <jds2001> but oh well 17:37:24 <dgilmore> +1 to scrollkeper, we should clean up 17:37:25 <Kevin_Kofler> +1 17:37:30 * j-rod cares not about epel... :) 17:37:36 <j-rod> oh, wait, I mean... 17:37:38 <j-rod> :) 17:37:39 <Kevin_Kofler> jds2001: They should be moved to the EPEL guidelines as mentioned in the proposal. 17:37:45 * dgilmore slaps j-rod with a tv tunder card 17:37:49 <jds2001> Kevin_Kofler: yeah 17:38:09 <nirik> +1 here. 17:38:27 <jds2001> #agreed scrollkeeper scriptlets guideline is dropped 17:38:37 <jds2001> Numpy and pygtk2? 17:38:43 <j-rod> dgilmore: ouch. those things can be quite sharp... 17:38:53 <j-rod> +1 to the numpy change 17:39:02 <Kevin_Kofler> +1 17:39:19 <nirik> +1 here I guess... it seems weird for a guideline, but I guess that will get the most people aware of the issue. 17:39:19 <dgilmore> +1 to numpy 17:39:22 <jds2001> +1 I guess. What if someone forgets? 17:39:33 <dgilmore> nirik: it does seem odd 17:39:40 <dgilmore> but it makse sense space wise 17:39:45 <jds2001> yeah 17:39:48 <j-rod> they'll figure it out when a bug gets filed because something doesn't work 17:39:53 <Kevin_Kofler> The alternative is to force NumPy in for any and all systems with PyGtk on them. 17:40:05 <jds2001> yeah, and that aint cool 17:40:12 <j-rod> but that would sorta defeat the purpose of the change 17:40:15 <jds2001> that's why I was +1 :) 17:40:48 <jds2001> #agreed PyGTK and NumPy guideline is approved 17:41:15 <abadger1999> ajax is filing a bug upstream against pygtk. This is to get people aware of the workaround until that's fixed. 17:41:15 <jds2001> #topic libvdpau inclusion 17:41:41 <dgilmore> jds2001: whats the ticket number? 17:41:43 <j-rod> +1 for including it 17:41:50 <j-rod> #238 17:41:51 <jds2001> .fesco 238 17:41:53 <jds2001> sorry 17:42:30 <Kevin_Kofler> Sigh, an API for binary drivers only. :-/ 17:42:41 <jds2001> :/ 17:42:47 <adamw> can non-fesco members speak in the meeting? (testing) 17:42:54 <Kevin_Kofler> (Nvidia and S3 so far) 17:42:54 <j-rod> well, for now, its only binary drivers... 17:42:54 <nirik> adamw: sure. 17:42:57 <jds2001> sure thing 17:42:58 <Kevin_Kofler> No Free implementations. 17:43:12 <jds2001> we've declined other things on this basis. 17:43:24 <kwizart> ! 17:43:29 <adamw> if it contributes to the discussion at all, i have packages for vaapi stuff that i've been building for poulsbo drivers. 17:43:35 <adamw> libva and a vaapi-enabled mplayer. 17:43:36 <dgilmore> j-rod: any change of it being adopted by open drivers? 17:44:00 <Kevin_Kofler> I'd argue it's also a GPL violation to use this stuff in GPL apps. 17:44:02 <j-rod> dgilmore: I think vaapi is more likely to be adopted by open drivers than vdpau, but I couldn't say for sure 17:44:04 <drago01> keithp was thinking about an implementation in the intel driver dunno what happened to that 17:44:06 <dgilmore> adamw: but that could all be in rpmfusion 17:44:11 <Kevin_Kofler> -1 to including it until/unless Free drivers support it. 17:44:13 <adamw> that's related by the looks of the fesco ticket, and kind of in the same situation; i think only poulsbo chipsets (which use a binary driver) can actually use it 17:44:13 <j-rod> vdpau apparently supports a LOT more functionality than vaapi though 17:44:28 <j-rod> and vdpau can serve as a backend ot vaapi, if so desired 17:44:30 <adamw> although there's possible a vaapi implemention for intel, not entirely sure. 17:44:47 <jds2001> kwizart: just talk :) 17:45:27 <j-rod> we do have libXNVCtrl already in fedora... 17:45:28 <kwizart> we shoudn't discuss either or not we (as fedora) should support libvdpau (or libvaapi) 17:45:29 <kwizart> here 17:45:41 <jds2001> kwizart: why not? 17:45:42 <Kevin_Kofler> Plus, doesn't libvdpau only help with patent-encumbered codecs anyway? 17:45:54 <kwizart> libvdpau require a proprietaty backend 17:45:57 <nirik> there's another similar case already in fedora isn't there with MPD? 17:45:58 <j-rod> that's worse than vdpau, since its nVidia binary driver specific, this is at least an open spec 17:45:59 <Kevin_Kofler> http://en.wikipedia.org/wiki/VDPAU only talks about "MPEG-1, MPEG-2, MPEG-4 AVC (H.264), VC-1, and WMV3/WMV9 encoded videos". 17:46:05 <jds2001> yeah, to me this seems as rpmfusion fodder 17:46:06 <kwizart> we are discussing to include an opensource wrapper 17:46:17 <Kevin_Kofler> None of that stuff can be used in Fedora anyway. 17:46:24 <adamw> Kevin_Kofler: that's accurate according to the nvidia docs, yeah. even mpeg? 17:46:33 <kwizart> which will allow vdpauinfo and qvdautest to enter 17:46:35 <Kevin_Kofler> I don't see what the point of shipping VDPAU in Fedora is. 17:46:37 <kwizart> that's all, 17:46:57 <Kevin_Kofler> There are no Free backends, all the users are patent-encumbered. 17:46:58 <jds2001> kwizart: why couldnt this go in rpmfusion? 17:47:12 * jds2001 not saying it's not useful, just not appropriate for Fedora 17:47:15 <Kevin_Kofler> IMHO this should go to RPM Fusion and it will be RPM Fusion's job to debate in which section it goes. 17:47:21 <kwizart> Kevin_Kofler, vdpauinfo will be usefull in fedora, it will say no vdpau backend is here 17:47:23 <kwizart> that's all 17:47:33 <Kevin_Kofler> How useful is that? 17:47:37 <j-rod> I guess it wouldn't hurt to put it into a 3rd-party repo until such time as there's a video driver actually in fedora that can use it 17:47:39 <drago01> Kevin_Kofler: we ship libXNVCtrl .. which also does not have free implementations 17:47:39 <Kevin_Kofler> IMHO it's completely useless. 17:48:04 <Kevin_Kofler> It's just an info tool and it says we have nothing, about as useless as Hello World. 17:48:07 <j-rod> but we do have this prior precedent 17:48:10 <kwizart> what end-users do after if they install a vdpau backend isn't our choose 17:48:18 <Kevin_Kofler> drago01: That just means that stuff should go away as well. 17:48:28 <jds2001> drago01: that was a mistake. 17:48:37 <jds2001> i dunno how that got in 17:48:38 <rdieter> Kevin_Kofler: what about apps/libs that have (optional) support for vdpau? 17:48:40 <drago01> Kevin_Kofler: would break apps that use it 17:48:43 <nirik> should all the mpd frontends go away too? 17:48:46 <kwizart> i meant we shoudn't have any word to say if said backend is installed on a end-users system 17:49:11 <rdieter> I guess they could use dlopen hacks, but eww... 17:49:18 * jds2001 steps awuy for a few minutes 17:49:25 <kwizart> rdieter, they do use dlopen 17:49:30 <Kevin_Kofler> rdieter: They should just be built without it. 17:49:33 <drago01> there are no suchs apps 17:49:56 <kwizart> Kevin_Kofler, what should be built without it? 17:49:57 <rdieter> kwizart: ok 17:49:58 <Kevin_Kofler> But anyway, there are no apps using VDPAU in Fedora as it is only useful to accelerate patent-encumbered codecs. 17:49:59 <j-rod> what about xine? 17:50:00 <drago01> most (all) of them are in rpmfusion due to patent reasons 17:50:09 <Kevin_Kofler> drago01: Right. 17:50:14 <drago01> j-rod: ah missed that one 17:50:16 <j-rod> I'm not all that familiar w/how xine is built... 17:50:28 <j-rod> could vdpau support be built for it outside of the fedora package? 17:50:34 <Kevin_Kofler> I guess xine-lib-extras-freeworld is all that would benefit from vdpau. 17:50:40 <kwizart> Kevin_Kofler, you are geting it the wrong way... as I said already fedora cannot support vdpau 17:50:57 <Kevin_Kofler> So I stand by my -1, I don't see what the point of shipping libvdpau in Fedora is. 17:51:02 <j-rod> or would keeping libvdpau out effectively mean rpmfusion would have to have a replacement xine to support vdpau? 17:51:08 <drago01> kwizart: sure it can, add an implementation to $ossdriver 17:51:09 <kwizart> thought the vdpau_wrapper is in a accurate place in fedora IMHO 17:51:17 <Kevin_Kofler> j-rod: xine-lib is modular. 17:51:25 <Kevin_Kofler> We already have xine-lib-extras-freeworld in RPM Fusion. 17:51:42 <j-rod> that's mostly codecs though, no? 17:51:54 <Kevin_Kofler> Isn't vdpau used by those codecs in the first place? 17:52:03 <j-rod> I'm saying I don't know if decoder backend support would need to be built into the main binary 17:52:05 <kwizart> one could have a patentless implementation of ffmpeg, 17:52:26 <kwizart> it could be allowed to enter in fedora 17:52:28 <j-rod> yes, vdpau handles those codecs 17:52:29 <adamw> does anyone actually _know_ how xine-vdpau builds or are we guessing? 17:52:38 <Kevin_Kofler> I think we don't know. 17:52:41 * nirik leans toward not allowing it now, but once some free driver supports it, bring it in then. 17:52:41 <drago01> adamw: the later 17:52:44 <Kevin_Kofler> I'm one of the xine-lib maintainers, I can check. 17:52:47 <j-rod> but nVidia has paid the codec royalties 17:52:49 <kwizart> but the question that vdpau codec is patented remains 17:52:51 <Kevin_Kofler> How about we defer the decision until we checked the facts? 17:53:03 <j-rod> so if you can simply pump bitstreams into the gpu, there's no software doing any decoding 17:53:09 <j-rod> (maybe) 17:53:10 <nirik> thats fine with me... if someone steps up to do that. ;) 17:53:19 <kwizart> then if it could be used to decoding it can also be used to transcode 17:53:23 <adamw> for me, can you guys state whether or not the same decision will apply to libva? 17:53:33 <drago01> j-rod: well afaik nvidia does this only for h264 and on some gpus for VC1 17:53:42 <Kevin_Kofler> I can look at xine-lib. 17:53:50 <j-rod> drago01: ? it can do mpeg2 just fine as well 17:53:56 <drago01> j-rod: everything else is done on cpu and offload parts to the gpu 17:54:27 <j-rod> pretty sure mpeg2 is handled entirely by the gpu too 17:54:28 * jds2001 is back 17:54:43 <kwizart> yes vc1 h264 mpeg-2 and mpeg-1 17:54:47 <adamw> oh, actually there's some vaapi support for intel now. i guess that makes it a different case. 17:54:47 <drago01> j-rod: yeah might be my point was vc1 17:54:49 <kwizart> nothing more 17:55:17 <Kevin_Kofler> AFAIK, the codecs don't support building pure hardware versions. 17:55:24 <kwizart> (thought a dirac backend could be in the work) 17:55:30 <Kevin_Kofler> So you can't use vdpau to bypass the patent issues. 17:56:06 <j-rod> adamw: well, it makes a difference for vaapi libs... not sure it helps libvdpau's case... 17:56:13 <kwizart> I haven't verified that ^^ 17:56:21 <kwizart> but that's an interesting question 17:56:35 <drago01> http://us.download.nvidia.com/XFree86/Linux-x86_64/185.18.10/README/appendix-h.html 17:56:46 <drago01> some codecs have "complete acceleration" 17:56:53 <drago01> so this should mean "done in hw" 17:56:54 <adamw> j-rod: yeah, i'm personally most concerned about vaapi as that's what i've built the package for =) i guess i'll bring it up later 17:57:25 <drago01> adamw: there is no reason why we have to choose one .. we could just package both 17:57:33 <j-rod> adamw: I think vaapi libs are probably a no-brainer to let in, since open implementations are in the works 17:57:36 <adamw> no, i wasn't suggesting a choice, that wouldn't make sense 17:57:40 <Kevin_Kofler> drago01: But the implementations in MPlayer etc. will build the patent-encumbered software version too. 17:57:43 <adamw> i just wanted to follow this debate as it affected vaapi 17:58:24 <jds2001> i dont see a problem if there are open implementations in the works 17:58:26 <drago01> Kevin_Kofler: yeah but we can have hw only players in fedora once we have driver support 17:58:29 <jds2001> wiht vaapi 17:58:47 <adamw> ok, thanks then guys, i'll go back to lurking...will submit a libva package soon then probably 17:58:47 <Kevin_Kofler> drago01: But all this is moot as long as there are only binary drivers. 17:59:21 <Kevin_Kofler> So, do we vote or are we going to debate this forever? 17:59:35 <jds2001> voting would be good :) 17:59:40 <jds2001> -1 18:00:01 <Kevin_Kofler> -1, until/unless Free Software drivers support it 18:00:02 <nirik> -1 for now, bring in once some free drivers use this. 18:01:00 <dgilmore> -1 for now one there is something concrete that can use it we can reevaluate 18:01:25 * nirik doesn't know what this might mean for MPD clients and/or libXNVCtrl perhaps we should revisit those at some point. 18:01:25 <drago01> http://people.freedesktop.org/~ymanton/g3dvl_uoft.ppt "open implemetation in the works" 18:02:21 <Kevin_Kofler> One more -1? 18:02:40 * nirik tries to look at the nasty ppt file. 18:02:44 <j-rod> ooh, ooh, see drago01's link... :) 18:02:48 <j-rod> +1 here still. 18:03:42 <drago01> nirik: oo opens it just fine ... but putting a ppt on freedesktop.org is odd 18:03:56 <Kevin_Kofler> drago01: We can revisit when that happened. 18:03:57 <nirik> drago01: do you know how far away that is? or what the current status is. 18:04:10 <nirik> yes, I know, just took a while for ooimpress to start up here. ;) 18:04:24 <drago01> nirik: not really darktama might now more 18:04:31 <drago01> *know 18:05:07 <jds2001> so are we getting one more -1, or are we going to sit here all day? :D 18:05:27 <nirik> well, if there is something soon, I would switch to +1... can you find out more and we can revisit? 18:05:30 <drago01> can we add a general rule on when suchs apps/libs are allowed and when not? 18:05:44 <drago01> having fesco decide on case by case basis seems wrong 18:06:07 <jds2001> sure, my view is that "crutch for propietary apps/drivers/things == bad" 18:06:14 <Kevin_Kofler> Same here... 18:06:37 <drago01> define things 18:06:42 <jwb> jds2001, that's pretty nebulous 18:06:45 <nirik> well, would one of you write up a policy/gather comments and we can discuss it next time? 18:06:59 <jds2001> jwb: it is nebulous 18:07:06 <jwb> jds2001, one could consider a compat-openssl package a "crutch" for proprietary apps 18:07:11 <nirik> note this case, the MPD case and libXNVCtrl and how they would be handled with the new policy? 18:07:17 <Kevin_Kofler> jwb: That's why we don't have one. :-) 18:07:25 <Kevin_Kofler> I have to leave now, so FYI, I'm also -1 on 236, bypassing review makes no sense, they should just use one SRPM for all languages. 18:07:39 <jds2001> Kevin_Kofler: im in agreement there 18:07:41 * rdieter checked xine-lib, vdpau support isn't in upstream xine, there's is a xine-vdpau fork though 18:07:55 <nirik> thats bad for updates volume, but feel free to disagree. ;) 18:08:13 <jds2001> nirik: why? 18:08:29 <jds2001> nirik: oh, nvm 18:08:41 * jds2001 not thinking 18:08:42 * jwb sighs 18:08:45 <nirik> one srpm -> 42 subpackages? This would mean anytime anything gets updated anywhere in any of them all 42 push out as updates. 18:08:52 <jds2001> nirik: yeah 18:08:58 <jwb> since Kevin left, s/compat-openssl/compat-libstdc++ 18:09:01 <nirik> so, back to the current topic? we didn't reach a decision? 18:09:02 <dgilmore> nirik: there are a few ways to splitit 18:09:03 <jds2001> that's why i said i wasnt thinking :) 18:09:06 <drago01> deltarpms should handle that 18:09:19 <drago01> make it require yum-presto ;) 18:09:26 * jwb stares at drago01 18:09:33 <nirik> we defer this until next week? we defer it until someone writes up a policy we use? we just move on? 18:09:47 <dgilmore> nirik: i think we need to defer till we have more info on the status of novouea support 18:09:49 <jds2001> yeah, we'll defer until someone comes up with a policy 18:10:06 <nirik> drago01: can you update the ticket with more info if you get a chance to find out? 18:10:30 <drago01> nirik: yes will try to get infos about the intel situation too 18:10:38 <nirik> thanks. 18:10:38 <jds2001> #agreed decision is deferred until a generic policy is presented, taking into account current instances of similar items. 18:10:40 <j-rod> I was going to suggest that since I filed the ticket, perhaps I should go hunt down more info, but I'm happy to let drago01 do it. :) 18:11:05 <jds2001> #topic publican localization packages bypassing review 18:11:08 <jds2001> .fesco 236 18:11:09 <drago01> j-rod: fell free to do it I can add info if I find something else 18:11:19 <dgilmore> -1 to bypassing review 18:11:25 <dgilmore> - 18:11:38 <jds2001> -1 to bypassing review, -1 to single srpm for all languages. 18:11:40 <j-rod> drago01: how 'bout we both plan on adding stuff, and hopefully at least one of us does? :) 18:11:54 <dgilmore> there are lots of ways this could be split 18:11:57 <drago01> j-rod: works for me 18:11:58 <nirik> -1 to bypassing review here too. 18:12:00 <dgilmore> one srpm per language 18:12:11 <nirik> I think one srpm per lang is good. 18:12:14 <dgilmore> one srpm per langage/guide combo 18:12:22 <jds2001> dgilmore: i think that's the way publican spits it out 18:12:23 <dgilmore> or one per guide 18:12:26 <jds2001> one per language 18:12:35 <nirik> I think that FPC will need to be consulted about the guidelines on lang in summary/description tho 18:12:36 <dgilmore> jds2001: they need to not use publican to create spec files 18:12:43 <jds2001> Sparks: you around by chance? 18:12:57 <j-rod> -1 for skipping review. these would be relatively easy reviews, since they're simply translations, no? 18:12:58 <nirik> one srpm per guide is bad, IMHO 18:13:10 <dgilmore> nirik: it needs to be in english, and can have a translation in it 18:13:13 <j-rod> initial package gets reviewed heavily, translations don't need to be scrutinized as much 18:13:21 <nirik> dgilmore: ok, so they need to fix it to make them that way. 18:13:43 <dgilmore> nirik: they need to stop trying to use publican to creat spec files 18:13:51 <dgilmore> nirik: it does a horrible job 18:13:54 <nirik> why? 18:14:03 <dgilmore> the package that was approved using it should not have been approved 18:14:05 <jds2001> could it be improved? 18:14:05 <nirik> I thought it did at first, but has been heavily fixed up 18:15:01 <dgilmore> jds2001: it doesnt do alot of things it should, and it doesnt work in cvs so changes made by releng for rebuilds, others for some other reason will get thrown away 18:15:22 <dgilmore> they cant bypass the normal procedures because they think its too hard 18:15:24 <nirik> dgilmore: are they using it for updates too? I thought it was just initial build? 18:15:46 <dgilmore> nirik: AFAIK its everytime they update the package 18:15:55 <jds2001> yeah, using it for updates is bad 18:16:27 <jds2001> it may take more time to do it right, but not *that* much more time i wouldnt think 18:16:34 <nirik> yeah, thats not good. I would say it would be ok to use for initial review/import, but after that use the regular tools. 18:16:36 <dgilmore> i can see that a translater will update a bunch of guides at once so a per lang spec is ok i think 18:17:04 <nirik> yep. I don't think everyone wants an update when there was a minor change to the Esperanto version. 18:17:07 <dgilmore> nirik: and thats not what they want, they want to use publican to do everythig for them 18:17:39 <jds2001> if they want to code it to play nice, fine. 18:17:51 * nirik misunderstood. Oh well, in any case we shouldn't let these bypass review... 18:17:51 <dgilmore> the security guide doesnt meet the packaging guidelines 18:17:53 <jds2001> but what you described is not "playing nice" 18:19:03 * dgilmore needs to leave in 2 minutes 18:19:11 <jds2001> anyhow, -1 to bypassing review 18:19:17 <jds2001> bad i already said that 18:20:23 <jds2001> #agreed translated publican guides may not bypass review 18:20:30 <jds2001> anything else? 18:21:37 <jds2001> guess not 18:21:41 <jds2001> #endmeeting -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
