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