FESCo-2008-04-10

--- bpepple has changed the topic to: FESCo meeting -- Meeting rules at http://www.fedoraproject.org/wiki/Development/Schedule/MeetingGuidelines -- Init process
bpeppleFESCo meeting ping -- bpepple, caillon, c4chris, dgilmore, dwmw2, f13, jeremy, jwb, notting, spot, nirik, tibbs, warren
* tibbs here
nirik is here.
notting is here
bpeppleHi everybody; who's around?
* c4chris is here
spot swims to the surface
* bpepple waits another minute or so to see who else shows up.
bpepplehmm, I only see 6 FESCo members.
* c4chris too :)
spot calls f13 to see whats up
bpepplejwb mentioned that he had a work meeting, and would probably be late.
cailloni'm only marginally here
spotf13 will be here shortly
bpeppleok, let's gets started then with some hopefully easy stuff.
--- bpepple has changed the topic to: FESCo meeting -- Any objection to this week's report from FPC at https://www.redhat.com/archives/fedora-devel-list/2008-April/msg00802.html
bpeppleDid anyone one have any objects to the 2 proposals from the FPC?
* bpepple didn't.
nottingseems fine to me
* nirik thinks its fine
c4chrisfine with me
f13here, sorry, phone was on silent
bpepplef13: no worries.
ok, I don't hear anyone objection, so I think we can move on.
--- bpepple has changed the topic to: FESCo-Meeting -- libflashsupport & nspluginwrapper on x86_64 - warren
bpeppleIs warren around?
f13Huh, bummer
I can talk about what this involves though.
bpepplef13: shoot.
f13With F9, we've taken a pretty strong 180 on our multilib policy
Previously, if yum was asked to install "foo", and both foo.i386 and foo.x86_64 were available, it would install them both
now, we have system local policy on what to do, and we default to installing only the "best" arch
net result is that a fresh install of Fedora 9 x86_64 would result in 0 i386 packages
... except for libflashsupport/nspluginwrapper
* dwmw2 arrives
f13In order to use adobe flash you need a number of htings.
first, you need nspluginwrapper.i386 in order to wrap the i386 only plugin from adobe
and if you happen to use PulseAudio (like we do in Fedora), you need an additional peice of software called 'libflashsupport'
and you need the i386 version of it to match the i386 adobe plugin
Due to our multilib policy in F8, we just listed both of those packages in comps, and users wound up getting both arches of them (along with both arches of a ton of other stuff)
That same trick doesn't work this time around, and you'd only get the x86_64 versions of them. x86_64 nspluginwrapper is still useful to wrap 64bit plugins and protect your browser space
libflashsupport.x86_64 is utterly useless
and only exists I believe to pave the way for the i386 version to be pulled in on x86_64 composes.
dwmw2what does libflashsupport do? Trap /dev/dsp opens and do evil stuff?
f13So we have a choice to make.
dwmw2: I'm not entirely sure what it does, only that if you use pulse, you must use it to use flash, 'cause flash is doing something really odd, like using oss stuff, not even alsa
alsa native can handle what flash does, pulse can't without this shim
Our choices are, A) add file level requires in the x86_64 libflashsupport so that it drags in the 32 bit one by default, and audio from flash will work once the user has installed the plugin.
whoops
well, B) is don't, and the user would have to explicitly install libflashsupport.i386 in order to get sound.
drago01dwmw2: flash dlopens it if present to do audio playback
f13or C) we add the file deps, but we demote libflashsupport to an optional package
dwmw2it seems reasonable for nspluginwrapper.i386 to require libflashsupport.i386, given that flash is mostly what it gets used for?
nirikwhat happens if we nuke the libflashsupport.x86_64 rpm?
(since it's useless otherwise, right?)
f13nirik: libflashsupport.i386 may not be available in x86_64 repos
drago01nirik: no its not
nirik: err yes correct
nirik: nspluginwrapper is not useless
nirikright, thats not what I wanted to nuke.
nottingf13: i don't think libflahssupport.i386 is conditional on the presence of .x86_64 in the repo
f13nirik: unless some other x86_64 package or multilib i386 package has file or library requires on libflashsupport.i386, it won't show up inx86_64
notting: hrm, which of our algorithms pulls it in?
nirikI would really like to not have a pile of i386 packages on a default x86_64 install. Ideally when someone installs the flash-plugin package it would pull in the needed package, but I guess we can't change their flash package.
f13notting: and would that get fooled by ExclusiveArch i386?
nirik: right, warren claims that it's "impossible" for adobe to add anything to their package that would help this situation.
nirik: it seems they feel it's a problem of our own creation by using PulseAudio
and since they build one rpm and expect it to work for Fedora, RHEL, SuSE, etc... they can't make any changes which would break it on those platforms.
skvidalhold on
nottingso, libflashsupport is a dlopened() module that changes the audio output routines
skvidalI want to make sure
nirikyeah, the flash-plugin has very generic requires.
skvidalwe've got a fair bit of the tail wagging the dog here
drago01its not a fedora package its a kind of "should work on all rpm distros package"
skvidalwe're going to add a bunch of pkgs to our default install just to make adobe's flash work?
f13skvidal: yes, we're bending over backwards for Adobe here.
bpeppleskvidal: yup.
nottingw/o flash plugin source, it's impossible to tell why they need it
skvidalf13: I think we're bending over forward and letting closed source demands ream us in the ass
f13My proposal is to have the file reqs there, so that the i386 package gets dragged in, but make it an 'optional' package, not a defualt one.
that way, the user has sto select libflashsupport in order to get hit with the i386 packages
it's one extra step for flash users, and that's what warren really wants to avoid.
nottingf13: if they have to manually select it, couldn't they just have to manually select the i386 version?
* nirik nods at notting.
f13notting: praps.
* c4chris nods at notting too
nirikor if the x86_64 one is gone, and the i386 one is in the repo, they wouldn't have to specifiy arch, right?
skvidalhas anyone asked adobe at all?
f13skvidal: warren claims to have.
skvidalor are we just assuming they won't change/fix their pkg?
* jeremy is here now
f13skvidal: I also suggested that adobe drop a virtual requirs in their package, that each distro could satisfy with whatever package makes sound go for flash
but he claims it will be impossible for adobe to do this any time soon. /maybe/ in time for F10.
skvidalf13: sounds very reasonable to me
f13but he thinks it will require changes in RHEL+SuSE+whomeverelse it will be tough to get approved.
(I think tough shit, make it happen)
nottingf13: do we actually have a statement from them as to what they are using for sound natively, and why that has issues with PA?
f13regardless, we do need to come up with a decision for F9, and I wasn't comfortable making that decision alone.
notting: I don't off hand, I think lennart has some background there, as does warren.
notting: IIRC they weren't comfortable using an API that wasn't stable, and I don't teven think they consider alsa 'stable'
* nirik would prefer: libflashsupport optional, and only i386 version is in x86_64 repos...
f13ok, warren just texted me, he's driving.  I'm trying ot get an ETA from him so that we can postpone voting, and let him have a say
nirik: I'd be perfectly happy with that, and I'd ensure that the package was available on the DVD
we'd have to get some late release notes written and translated, but I thikn we have the power to do that
c4chriswhat nirik said
* stickster reads back....
bpepplef13: you get an ETA yet?
tibbsThis is basically an issue of balancing distro purity against ease of use for the users.
f13I believe warren's arguments are that the x86_64 users who want flash to work "out of the box" far outweigh the x86_64 users that care about not having .i386 packages on their default install.
f13bpepple: sadly, no.
tibbsIt would help to have stats on just how many packages this pulls in, and to characterize the difficulty for users who will encounter this.
dwmw2it makes some sense for the nspluginwrapper-plugin library to require the i386 nsplugin-wrapper binary. And for the nsplugin-wrapper binary to require libflashsupport.
f13tibbs: I had asked him for this information.
dwmw2: some, but not much, as nspluginwrapper.x86_64 is perfectly useable and quite useful without any i386 stuff
dwmw2: especially since we're going to start getting selinux protection on it
dwmw2ah, point
f13I'm not aware of any significant firefox plugin that is 32bit only too.
other than flash
java /used/ to be a while ago, but that's not hte case anymore
tibbsDoes this all come down to balancing some unknown number of i386 packages in the default install versus one "yum install" command?
f13anyway, I really do think it would be fair to give warren a chance to argue his side of this, before we vote.
tibbs: or one packagekit search -> click to install
tibbs: or one extra click during intial install
oh!
also, there is the matter of the Live CD
bpepplef13: agreed, how about we move on, and code back to it near the end of the meeting.
s/code/come/
f13if we're not short on size, we also have to decide if we're going to put the i386 stuff on the x86_64 live cd
drago01f13: adobe reader ... java was never wrappable anyway (and still isn't)
bpepplef13: are we still in holding pattern for the release date, or do we need to discuss it?
jeremyf13: x86_64 isn't cd sized anyway.  even without 32bit bits
f13jeremy: nod.
sticksterf13: We're running really short on time for release notes if you want them translated and ready for GA. There's a zero-day update possibility but that doesn't make it onto gold spins.
f13bpepple: I think we're still in a holding pattern, keeping a very watchfull eye on the X stuff, and anaconda upgrades
f13stickster: understood, which is why I want a decision today, so that we can get those notes written today
bpepplef13: ok.
should we talk about features now then?
* stickster takes off docs hat and retreats into &
--- bpepple has changed the topic to: FESCo-Meeting -- Features Completion - http://fedoraproject.org/wiki/Releases/9/FeatureList - poelcat
poelcatjust a few left that I need help with
http://fedoraproject.org/wiki/Features/Dashboard
* f13 is inviting hugsie to pop in here for package kit
poelcatwe never offically removed virtstorage, but I can't get a response from anyone and still at 25% done
* poelcat would like a vote to officially drop
bpepplepoelcat: It needs to be dropped.  The owner has had plenty of time to update it.
* f13 pings owner on IRC one more time
nirik says drop.
poelcatoops... xulrunner is done
* c4chris says drop
poelcatso really just two X features and tetex
f13just got a reply from danpb, trying to drag him in here
poelcatall of which I *think* are done, but just need final updates
mclasenxserver15 is not done insofar as there is not a 1.5 release yet...
poelcatmclasen: fair enough... what should the feature page say then?
mclasenwe could rename the feature xserver1.4.99.3 and put it at 100%
poelcatlol
mclasenbut that seems silly
f13<@notting> danpb_ltop: virt-storage feature... what's up?
<@danpb_ltop> notting: the libvirt parts of it are all done
<@danpb_ltop> notting: the virt-maanger bits are punted to F10
<@jkeating> danpb_ltop: what does that mean as far as feature advertisement for F9, just not say anything?
::: alanm!~alanm@vpn-14-150.rdu.redhat.com has quit: Quit: Muuuwwwhahahaaaa!
* poelcat is open to something reasonable... i just don't have a lot to work with when the only response is silence
f13<@danpb_ltop> jkeating: probably easiest to just not say anything
<@jkeating> ok.
<@danpb_ltop> jkeating: becasue most of our target audience won't use libvirt APIs directly
bpepplef13: ok, so we'll drop the virtstorage feature.
f13mclasen: what is the projected release date of 1.5?  Any chance it'll happen before F9, or should we really change the feature to say an Xserver1.5 pre-release ?
mclasenask ajax, I don't know
c4chrispre-release should do
bpepplec4chris: agreed.
mclasenhe's put a link to a tentative schedule for 1.5 on the feature page, I believe
* dgilmore is here now
f13honestly, it's not like we're going to pull the pre-release bits out
but in order to get translations on the feature stuff, we need to know pre, or actual release.
poelcat: I'll commit to getting that information from ajax before the day is over
bpepplelooks like 1.5 is supposed to hit on april 25th according to his e-mail.
poelcatf13: thanks... can you just put it on the feature page?
f13sure, that'll happen.
poelcathow about this one: http://fedoraproject.org/wiki/Features/OneSecondX
?
c4chrisafaik it's inbedded in the X 1.5 ?
poelcatf13: can you cover it too?
* warren reading backlog
poelcatwhich leave us with only one left: http://fedoraproject.org/wiki/Releases/FeatureTexLive
f13poelcat: sure.
dgilmorewhats the last 5%
it seesm like its all in
f13heh, seems there is a little bit of doubt from the X side that we'll actually release in 2 weeks.
poelcatdgilmore: can't tell
bpepplemaybe in the next feature release cycle we can add a section about what still needs to be done to get to 100%.
dgilmorebpepple: that would be useful i think
c4chrisbpepple: yup
f13bpepple: good call
dgilmoreAFAIKT it seesm like texlive is done
mclasenthe last 5% is changing the percentage to 100%
bpepplemclasen: ;)
f13yeah, I vote we make an executive call and call this one "done"
bugs left can be fixed later.
bpepplef13: +1
c4chrisdone +1
dgilmore+1
tibbs+1
warrenreading through the backlog, I can see that a lot of the assumptions and understandings surrounding flash, libflashsupport and nspluginwrapper are actually incorrect.  Given the length of time remaining in the meeting, I might recommend that I post a complete run-down to the list instead.
f13warren: we need to get a decision made today
warrenAs for me not being here, that's my fault.  I screwed up.
poelcatre: tetex got it... that's all from me
f13for release notes purposes.
bpepplewarren: we're going to get back to discussing flahs after we finish up with features.
f13bpepple: looks like we're ready for that
nottingbpepple: well, was there PK and swfdec to review?
bpepplenotting: yeah, we should those.
nottingi guess i brought this up, so...
warrenok
dgilmorenotting: whats the status?
nottingwe added PackageKit and swfdec as default for the beta, with the idea that we'd review them
dgilmorePAckageKit i dont think is quite ready
nottingthe two test plans are at: http://fedoraproject.org/wiki/QA/TestResults/Fedora9PackageKit/Rawhide
nottingand https://fedoraproject.org/wiki/QA/TestResults/Fedora9Swfdec/Rawhide
not sure if anyone has run through the PK tests yet
so, PK first?
f13I've been using PK exclusively for anything I would have done pirut/pup for, and a lot of what I would have done yum cli for
f13while its a bit rough, and not what I'm used to, I don't think it's in terrible shape, even to be our default graphical package management tool
bpepplef13: agreed.  It's got some rough spots, but overall I haven't had any real problems.
f13it's getting active bugfixes, and a lot of attention, which at this moment I can't say the same about the alternative (mostly /because/ effort is being put into PK, and we don't want to duplicate effort)
hughsie: now would be a good time to speak up for yourself (:
hughsief13: ahh, thanks for the ping!
hughsiePackageKit is coming on nicely - i think that bugzilla will be the best source for bugs - but the core stuff is pretty stable now
nothing that would kill your data anyway
EvilBobs/would/should
hughsietheres a PKF(Blocker target for all the bugs that have to be fixed
bpepple+1 to leaving PK installed by default.
warren+1
notting+1
f13hughsie: is that in RH bugzilla, or fdo?
+1
c4chris+1
hughsieRH
dgilmore-1
f13hughsie: what's the number then ?  "PKFBlocker" isn't registering as a vlaid alias
bpeppledgilmore: Is there anything in particular that you don't like about PK?
hughsief13: sorry PKF9Blocker iirc
mclasenthe blocker name is actually F9PKBlocker
dgilmorebpepple: ive not done extensive testing of PK.  but ive found that it seems to error out alot
hughsief13: F9PKBlocker sorry
f133rd time is the charm.
hughsiedgilmore: have you filed bugs?
dgilmorebpepple: and it seems to do a poor job of letting me know what its doing
f13dgilmore: are those errors actual PK errors, or yum errors from repos?
nirik+1 (although I haven't tested it too much here either, but at least it's getting good attention and work)
dgilmorehughsie: not yet
bpeppledgilmore: ok, was just wondering.  Thanks for the input.
hughsiedgilmore: then i know of no problems :-)
dgilmoref13: its not been clear to me
f13anyway, bpepple is that enough votes?
bpeppleI count six '+1', and one '-1'.
f13jeremy: ?
bpepplespot, caillon, dwmw2, jeremy: ?
dgilmorebpepple: i count 5 +1 and 1 -1
bpeppledgilmore: did you get nirik's?
spot+1
f13dgilmore: you missed bpepple 's initial +1
* jwb finally shows up
f13dgilmore: or nirik's late +1
dgilmorebpepple: no
dwmw2sorry, was away briefly
dgilmoref13: i missed nirik's
jwbwhich feature are we on?
f13jwb: dwmw2: looking for go/nogo on PK by default in F9
dgilmorejwb: PackageKit
bpepplejwb: packagekit
caillonbpepple, PK = PackageKit.  leave it on.
jwbi probably shouldn't vote here
f13which, does that mean we'd actually remove pirut?  We're going to have to do something about upgrades or else users will have /both/ PK and pup trying to show them updates.
bpeppleok, that makes it seven '+1', and one '-1'.  It's going to be installed by default.
dgilmoref13: pirut needs to be Obsoleted by PK
dwmw2+0
hircusf13: on a clean install, pirut is not installed anymore, right?
jwbi was never able to turn it off, so i just yum removed it
dwmw2no opinion here
bpepplehircus: I believe so.
nottingf13: on an upgrade, will they actually get PK?
f13hircus: clean installs no
notting: yes, if they have system-config-printers
notting: due to system-install-packages which is now PK
nottingf13: just take the applet out of pirut
erm, the autostart desktop
dgilmorenotting: it got on my system sduring updates at some point
f13jwb: can you file a bug about not being able to turn it off?
dgilmorepirut is needed by (installed) system-config-kickstart-2.7.15-2.fc9.noarch
f13jwb: we'll want hughsie and co to fix it.
hircushave we gotten through to the x86_64 + flash item yet?
nottingno
hughsief13: why do we need the xtra applet?
jwbf13, eventually
bpepplehircus: no, after we talk about swfdec.
dgilmorehughsie: both at one is confusing and annoying
f13hughsie: we don't, but some felt the original plan was that one could remove PK and fall back to pirut if they chose.
hughsiedgilmore: can't you remove pup?
jwbfwiw, i removed all of them
:)
f13if we go with PK by default, which it looks like we do, we'll have to figure /somethin/g out for upgrades.  We can punt that to jeremy, msyefl, and whomever else wants to be involved.
I don't thik we need to take up more fESCo time on it
warrencan't the PK applet detect and remove pup from the session?
and vice-versa
f13hughsie: upon upgrades,s omething would have to forcefully remove pup
hughsief13: yup, i would say have gnome-pakagekit obsolete pup
f13proposal: figure out upgrades and pup on fedora-devel-list our in #fedora-devel, move on.
jwbyeah
mclasenwarren: that way lies madness
bpepplemoving on....
nottingok, the next one is swfdec
dgilmorewe need to make sure that system-config-kickstart works still
--- bpepple has changed the topic to: Swfdec
nottinghttps://fedoraproject.org/wiki/QA/TestResults/Fedora9Swfdec/Rawhide
warrenmclasen: just be thankful I didn't suggest running the applet using alternatives =)
f13dgilmore: yes, that should just need pirut and not pup.
nottingat the moment, you need a scratch build of it, otherwise it's flaming death all over
even still, (IMO), it's not good
dgilmoref13: well we should split pirut into pirut and pup
f13dgilmore: moving on...
jwbnotting, wow
that's very red
f13notting: is hte question enabled by default, included but optional, or not included at all?
s/is/are/
dgilmorejwb: flash is the spawn of satan  so its expected
bpepplef13: I believe by default.
nottingno reason to nuke it from the tree. it's a question of default or no
dgilmorenotting: enabled by default -1
jwbwhat's the alternative default?  nothing?
nottingjwb: yes
hircusquestion: if both swfdec and Adobe's flash-plugin are installed, which one would get used?
dgilmorejwb: yes
nottingjwb: which means -> firefox's plugin finder -> adobe flash
bpepplehircus: swfdec.
hircuseek. then it probably should not be on by default
jwbnotting, rock and hard place, eh?
nirikenabled by default -1 here too... perhaps f10 if it's better? ;)
f13ok, enabled by default -1
* bpepple will abstain.
f13nirik: where "better" involves the use of non-free plugins?
warren-1
nirikno idea, but thats 6 whole months from now. ;)
nottingwell, functional swfdec will always require non-free codecs. but right now, it's not that great even with them, IMO
f13nirik: i'd rather make the decision at the feature freeze, not the day or 3 after the final freeze (:
nirikindeed.
warrenEven if the proprietary codecs made it 100% working, are we really better off morally?  Both options are proprietary.
dwmw2swfdec not gnash?
bpepplewarren: I'd say it's better than pointer our users to a 100% proprietary option.
s/pointer/pointing/
nottingdwmw2: if someone wants to duplicate the test matrix against gnash...
warrenbpepple: not to mention the poor user experience aspect.
nottingdwmw2: swfdec has gst-install-missing-plugin support, though. don't think gnash does
dwmw2I just thought gnash was better these days, that's all. If swfdec is, I'll switch :)
bpepplenotting: yeah, gnash doesn't.
* nirik needs real flash for his credit union website of all things. *shudder*
dwmw2scary
nottingnirik: can't you go ADA on them?
dwmw2I'd prefer to have a free implementation (whichever one it is) installed by default, but make sure the evil one works if users install it
f13anyway, time issues, can we get a complete vote?
dgilmorenirik: my credit union makes me have the java plugin installed to login
nirik: even though they use jsp pages and not java applets
f13dwmw2: at this point, I think that would require an Obsolete in the adobe flash rpm, which they may not do any time soon.
* notting is -1 to installed by default. revisit for f10
jwbVOTE PLEASE
dgilmoreit seesm that they have some dumb people
dwmw2f13: or in libflashsupport? :)
c4chris-1
jwb-1
dwmw2but that just makes that whole thing scarier :)
+0
f13-1
dgilmorei count 8 -1
one 0
bpeppleok, swfdec isn't installed by default.
f13bpepple: remind me to make sure it stays on the DVD/splitCD media
nottingthx to james laska for getting the test plan pages wikified
* bpepple really isn't looking forward to telling upstream a second time.
--- bpepple has changed the topic to: x86_64 flash
f13Date point.
warrenhere comes a big paste
First: Detail Corrections
=========================
* libflashsupport.x86_64 is currently useless, but Adobe did promise a 64bit native plugin one day, and its presence will ensure that sound works when it happens.
* Flash plugin does NOT do OSS, and libflashsupport does NOT do any evil device redirection.
* Flash does native ALSA by default, but for some reason it doesn't work with the pulse ALSA emulated device. Sound does appear to work without libflashsupport.i386 only if pulseaudio has let go of the ALSA device (after a customary few seconds of inactivity). This of course this means that pulse (everything else) stops working while flash has exclusive use of ALSA.
jwbpastebin!
f13default install minus libflashsuport/nspluginwrapper
warren* libflashsupport uses pulseaudio directly via the native pulseaudio interface instead of Flash's internal ALSA.  This is the only way to ensure that sound works smoothly between all desktop apps, and the only way to get any sound from Flash for thin clients.
* jwb sighs
f13post-install 'yum install libflashsupport.i386 nspluginwrapper.i386' drags in 51 packges (all i386), for 22 megs download size
warrenAny disputing of these points?
* bpepple hasn't even had time to read them.
nottingwarren: is the native alsa support in flash identical to the alsa ifdefs of libflashsupport?
nirikwell, if there is no 64 bit flash currently, why ship libflashsupport.x86_64 now? you can always add it back in later once its needed.
warrennotting: I could ask.
nottingwarren: that could make it more obvious wtf it fails with PA
warrennotting: do we install the necessary i386 stuff to do 32bit ALSA thunking by default?
dwmw2hopefully by the time they get round to a 64-bit build, they'll have solved this without the need for libflashsupprt
hircuswarren: as of F9 beta, it looks like no 32-bit libraries are installed by default
* nirik nods at dwmw2
warrennirik: I can't answer that question due to NDA.  hint hint.
nottingwarren: oh geez. they dlopen libasound? WHACK.
f13warren: aside from libflashsupport, there is no i386 packages in the default x86_64 install
* f13 spotted something /very/ curious with nspluginwrapper though
hircusf13: weird, libflashsupport.i386 is not in my default install
warrenf13: well, I removed the cross-arch dep a few days ago, so there should be none now either.
hircusnor nsplugwrapper.i386
f13hircus: the file deps aren't there right now.
warren: well, anaocnda showed "nspluginwrapper.i386" selected by default
warren: I unchecked it to figure out wtf it was showing .i386
hircusf13: ah ok. this is a side-effect of yum being arch-strict then
warrenf13: I subsequently did think of a better way to do cross-arch deps without pulling in filelists.
f13: really? I didn't do that.
f13in case the data point was missed above, adding libflashsupport.i386 and nspluginwrapper.i386 introduces 51 (inclusive) i386 packages.
* dwmw2 blinks
dwmw2that's a lot of packages
warrenf13: many of which are already on the livecd but not regular install
dwmw2mostly individual libXfoo?
c4chrisyea, me is still at default == -1
f13warren: i386 ones?
warrenAdd Dependency from flash-plugin
================================
This sounds good in theory, but this is asking for the impossible for two key reasons:
1) Adobe will not build a different RPM for different distros. All other distros would have to virtual provide whatever is necessary at the same time. How feasible is this?
2) This is technically wrong. Their plugin by default outputs to ALSA which works everywhere already. We're the only ones that can't satisfy this expectation.
f13warren: what is i386 on the Live CD right now?
warrenf13: yes.
hm
f13wow, 47 packages come from nspluginwrapper
warrenf13: scim related i386 packages pull in a lot of X and gtk stack I think
* nirik likes his idea still... but it does mean it doesn't work out of the box.
warrennirik: what was your idea?
f13warren: oh god, scim.
nottingwrite yum-plugin-flash :P
hircusFlash is presumably the only reason one'd need nspluginwrapper.i386? is the OpenJDK plugin working on all sites?
niriknirik would prefer: libflashsupport optional, and only i386 version is in x86_64 repos...
hircus: no, but java doesn't work with nspluginwrapper anyhow.
warrenwe do need it in the repos or it wont be installable at all
f13warren: need what in the repo?
warrenf13: libflashsupport and nspluginwrapper i386
hircusnspluginwrapper.i386 not installable if x86_64 not in repo?
oh
f13warren: yeah, I don't think anybody is suggesting we remove it from the repo (or DVD) all together
nottingskvidal: say, how hard would a plugin that adds nspluginwrapper & libflashsupport iff someone adds a 'flash-plugin' package be?
f13I mean, really, we could make a special comps group for this (EEK translations) and make it checkable from the first software screen
skvidalnotting: not very - a bit odd, but not hard
nirikI don't see the point in libflashsupport.x86_64, and if we remove it then a 'yum install libflashsupport' will always get i386, so less confusion for end users, right?
warrenKey Question: What is more important?  Who is more prevalent?
=============================================================
A) x86_64 end-users avoid confusion with no visible indication of why it isn't working.
B) x86_64 developers who want to be 100% free of i386 packages immediately after an install.
Is it easier to explain to group A or group B what to do? I would think group B is in the extreme minority.
nottingnirik: that won't pull in nspluginwrapper,though
warrennirik: we still have the lack of nspluginwrapper.i386 problem
hircushow about a package that contains scripts needed to install proprietary things
f13warren: make libflashsupport require it (:
dgilmorewarren: i think we should not take steps to make it easier for propietory software
hircusso install-flash -> download Adobe's repo file and yum install the required things
warrendgilmore: you mean like codeina?
dgilmorehircus: how about no
warren: yes
hircusor that. just document things
f13warren: the term "developers" in B is incorrect.  It's not just developers whom don't want to be bothered with unnecessary i386 packages.
warrendgilmore: then we should remove the plugin finder from firefox too.
dgilmorewarren: ive been vocal  that with codenia we lose
f13warren: if we could, we probably would.
but then e'd have to call it !firefox
warrenf13: ok, same argument s/developers //
nottingwell, it's (technically) a regression from F-8. do we care?
warrenI do.
dgilmorenotting: i dont think we care
nottingskvidal: you know, i may have written this once already
warrenis jeremy around?  He had an opinion.
f13notting: I don't, as I think we can make it obvious at install time to get "flash support"
skvidalnotting: yes, I think so
warrenOH btw, there were 3 other workarounds I discussed with Jeremy but they were shot down
* stickster_afk makes little hand-wavy "I'm dreaming back to..." motions
warren1) arch-specific stuff in comps
warren2) arch-specific livecd kickstart files
3) multilib policy exclusions whitelist
nottinghm
warrenjeremy thinks we should use cross-arch dependencies
dgilmorewarren: thats just wrong
warrendgilmore: which part?
dgilmore"cross-arch dependencies"
warrendgilmore: why?
nottinghaving a 'flash support' option that installs helpers for adobe in combination with voting to remove swfdec from default could be seen as a pretty big slap in the face to the swfdec people
c4chrisdefault: no  tickable box in anaconda: ok
dgilmorewarren: because it means those that want clean arch systems cant
c4chriscould have a tickable box for swfdec in anaconda too, in that case...
dgilmorenotting: indeed  we should not help people get adobe flash period
warrenIf we're doing this as a regression from F-8 for the purpose of moral highground, then we should remove codeina and the plugin finder as well or we're being hypocritical.  I'm willing to accept complete removal of proprietary pointers.
f13notting: true.  We could term it "support for 32bit firefox plugins" (:
f13Danger!  hyperbole ahead!
mclasenwarren: how about firmware in the kernel ?
nottingmclasen: oooh, why i oughta.....
warrenmclasen: that isn't pointing, that's inclusion. =)
Why is nobody answering the above question? (repasting)
mclasenwarren: so you want to avoid being a hypocrite by playing language games
warrenKey Question: What is more important?  Who is more prevalent?
=============================================================
A) x86_64 end-users avoid confusion with no visible indication of why it isn't working.
B) x86_64 who want to be 100% free of i386 packages immediately after an install.
Is it easier to explain to group A or group B what to do? I would think group B is in the extreme minority.
dgilmorewarren: i say we support B
hircusso things are either good enough / free enough to be included by default, or excluded completely. does not seem to be a merely linguistic finesse to me
warrendgilmore: are they more prevalent than group A?
f13warren: they're more useful to us than Group A
spoti've been really quiet throughout all of this, but adobe could fix this with a single line in their rpm.
dgilmorewarren: Adobe can seriously go fall off a cliff for all I care about flash
warren: i honestly dont care if they are
nottingskvidal: hrm, can't find it
warrenspot: that is a logical misconception
hircuswe can do (A) and (B) together if we blacklist libflashsupport.x86_64
spotwarren: its not. its a fact.
warrenhircus: no, that doesn't solve nspluginwrapper.i386 problem
c4chrisfor me, A == bend over and let Adobe have it..., so I'm for B
spotwarren: one file Requires will fix this.
hircuswarren: ah yes, nspluginwrapper
warrenspot: Requires what?
skvidalnotting: I can write a plugin for this, if you'd like
hircusis there a comps category for 32-bit libraries?
nottingRequires: PAIN
warrenskvidal: that does what?
skvidalnotting: but I reserve the right to name it yum-cracked-out-shit
f13warren: they could require nspluginwrapper.i386, or whatever file that provides on i386 arches
skvidalor yum-adobe-needs-to-fix-their-goddamned-deps
f13hircus: not any more.
dgilmoreskvidal: i think it should be yum-im-smiking-some-nasty-shit
skvidal: i think it should be yum-im-smoking-some-nasty-shit
skvidaldgilmore: I dunno what you're smiking
nottinghm
warrenf13: adobe wont do it because most distros don't do nspluginwrapper or pulseaudio by default.
skvidalbut you keep your second-hand-smike away from me ;)
dgilmorewarren: thats adobes problem not ours
f13warren: don't care about default.  Do they /have/ a nspluginwrapper
warrenwe are being completely unrealistic to insist that they add dependencies just for us.
spot%if 0%{fedora}
f13and that.
nottingProposal: 'ExclusiveArch: i386' libflashsupport. Do not install by default, document the need to install libflashsupport/nspluginwrapper if you want adobe flash
hircusand RHEL
drago01skvidal: did you want to kill me for this kind of hack?
spotRequires: %{_libdir}/libflashsupport.so
warrenspot: they don't build distro specific RPMS
drago01*didn't
niriknotting: +1
spot%endif
dgilmorewarren: please grab your ankles so that adobe can have its way.    We really should not care about it.  File a bug with adobe and walk away
skvidaldrago01: yes, of course
c4chrisnotting: +1
spotnotting: +1
warrendgilmore: there is no reason to be disrespectful.
skvidaldrago01: which is why I'd do it  but only in an extremely angry way :)
f13notting: +1 (and we can even have libflashsupport require nspluginwrapper, so one package to install)
bpepplenotting: +1
drago01skvidal: ;)
hircusspeaking of 32-bit libraries, any idea if we can put pulseaudio-utils.i386 and pulseaudio-esound-compat.i386 into the x86_64 tree?
warrenf13: I don't want to force people to use nspluginwrapper and vice versa.
dgilmorewarren: your being disrespectful of the whole community
c4chrisk, me needs to go take care of kids...  Later folks
warrendgilmore: that is a matter of opinion.
bpepplelater, c4chris
dgilmorenotting: +1
warrenhircus: why?
f13warren: um, if you're going to force people to use a 3rd party closed source plugin, you might as well give htem a bit of protection.
warrenhircus: bring this up on the list?  this is a new topic
hircusneeded for the other annoying 32-bit app, Real Player
warrenf13: hey, I suggested removing the plugin finder and codeina
spotpeople still use Real Player?
hircuswarren: OK. it's already on bugzilla, but I don't remember a discussion on it yet
skvidalspot: for porn
hircusoh, and Crossover Wine too
f13warren: no, you tried to use them as hyperbole
hircusskvidal: haha. that and BBC
f13spot: I think I have a ram file buffering somewhere from 1998
skvidalhircus: same thing
dgilmorehircus: care factor of Real is 0
skvidalhey, I know - let's include helixplayer!
wait, wait, no
f13hircus: Can we discuss that in #fedora-devel after this meeting?
warrenf13: that is a great way to dismiss a valid argument without discussing its merits.
hircussure
bpeppleok, I counted seven '+1' to notting's proposal,
warrenOK, so the only change we're making is simply make sure they're on the DVD?
f13warren: you /know/ we're not going to throw out codina or plugin finder at this point, so you're obviously trying to use them as an ultimatem to get your way.
warren: and writing release notes, and getting them to translators today
warrenf13: You think think that we're possibly being hypocritical to prefer one proprietary solution over another?
zcat(i see the glowing blog reviews now. no worries about fedora becoming the next ubuntu.)
warren++
nottinghm. does it buy anything to have them on the dvd? it's not like we have adobe flash on the dvd
f13warren: and begging stickster to push them through for you.
nirikthe f8 notes don't need much change: http://docs.fedoraproject.org/release-notes/f8/en_US/sn-Desktop.html#sn-Enabling-Flash-Plugin
warrenf13: push what?
f13: excuse me, I did what?
spotladies.
f13notting: they can select them at install time, so that once they start browsing and install the plugin, it'll "just work"
spotplease take it outside.
warrenf13: there must be some big misunderstanding here.
f13warren: you'll need to write release notes for users who care about adobe flash.  THose release notes will need to be translated, and gone through stickster for fedora-release-notes package.
warrenf13: I didn't talk to stickster about anything related to flash.
f13warren: you do if you want release notes related to flash added to fedora-release-notes
warren: he's still the upstream and package owner for fedora-release-notes
warrenOh, OK, I misunderstood, I thought you were accusing me of something.
f13no, just outlining what work needs to be done.
bpeppleok, is there anything else regarding x86_64 flash, or can we start to wrap up?
nottingwe have 15 minutes before we have to clear the meeting room for infrastructure :)
warrenWhy does it seem that people are taking this far too personally?
drago01bpepple: i386 pa libs in the x86_64 repo
bpeppledrago01: let's take that to the mailing lists.
drago01was "broken" for f8 since the beginning
ok, fair enough
--- bpepple has changed the topic to: FESCo meeting -- Free discussion around Fedora
warrenMy goal is only trying to prevent user confusion and provide a smooth user experience.  I take offense to the connotation that I'm "bending over" to Adobe.  I would prefer that we did not point at any proprietary components at all.
spotf13: i'm making progress on mono
tibbsWe've made some progress in getting the F9-targeted merge reviews down.
spotf13: hopefully, we won't have to block anything
tibbsWe're just below 50% closed right now.
nottingdo we need a block/noblock vote on mono-with-binary-components?
* wolfy would like to see a solution which ensures that fedora users can see youtube clips without being forced to ask around "why does it not work"
warrenf13: we making sure the i386 pulse components are in the x86_64 repo as well?  (not default install)
f13warren: we aren't yet.  Had needed to speak with lennart about it, but that was an unconclusive discussion
and frankly I forgot about it
warrendo we have a list of "remember to do this before release"?
f13: do we need any gross-hacks to ensure i386 in DVD or there is already a "supported" way?
drago01warren: blocker bug?
f13warren: not sure what you're asking.
warren: pungi errs on the side of 'every possible arch' when composing
warrenoh
ok
f13but for pulse stuff, we have tomake it show up in the x86_^4 repo to begin with, and tha'ts mash
bpeppleok, if there's nothing else I'm going to wrap the meeting.......
* bpepple will end the meeting in 60
hircussent to the mailing list
* bpepple will end the meeting in 30
bpepple will end the meeting in 15
bpepple-- MARK -- Meeting End

Generated by irclog2html.py 2.5 by Marius Gedminas - find it at mg.pov.lt!