| --- bpepple has changed the topic to: FESCo meeting -- Meeting rules at http://www.fedoraproject.org/wiki/Development/Schedule/MeetingGuidelines -- Init process | ||
| bpepple | FESCo meeting ping -- bpepple, caillon, c4chris, dgilmore, dwmw2, f13, jeremy, jwb, notting, spot, nirik, tibbs, warren | |
|---|---|---|
| * tibbs here | ||
| nirik is here. | ||
| notting is here | ||
| bpepple | Hi everybody; who's around? | |
| * c4chris is here | ||
| spot swims to the surface | ||
| * bpepple waits another minute or so to see who else shows up. | ||
| bpepple | hmm, I only see 6 FESCo members. | |
| * c4chris too :) | ||
| spot calls f13 to see whats up | ||
| bpepple | jwb mentioned that he had a work meeting, and would probably be late. | |
| caillon | i'm only marginally here | |
| spot | f13 will be here shortly | |
| bpepple | ok, 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 | ||
| bpepple | Did anyone one have any objects to the 2 proposals from the FPC? | |
| * bpepple didn't. | ||
| notting | seems fine to me | |
| * nirik thinks its fine | ||
| c4chris | fine with me | |
| f13 | here, sorry, phone was on silent | |
| bpepple | f13: 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 | ||
| bpepple | Is warren around? | |
| f13 | Huh, bummer | |
| I can talk about what this involves though. | ||
| bpepple | f13: shoot. | |
| f13 | With 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 | ||
| f13 | In 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. | ||
| dwmw2 | what does libflashsupport do? Trap /dev/dsp opens and do evil stuff? | |
| f13 | So 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. | ||
| drago01 | dwmw2: flash dlopens it if present to do audio playback | |
| f13 | or C) we add the file deps, but we demote libflashsupport to an optional package | |
| dwmw2 | it seems reasonable for nspluginwrapper.i386 to require libflashsupport.i386, given that flash is mostly what it gets used for? | |
| nirik | what happens if we nuke the libflashsupport.x86_64 rpm? | |
| (since it's useless otherwise, right?) | ||
| f13 | nirik: libflashsupport.i386 may not be available in x86_64 repos | |
| drago01 | nirik: no its not | |
| nirik: err yes correct | ||
| nirik: nspluginwrapper is not useless | ||
| nirik | right, thats not what I wanted to nuke. | |
| notting | f13: i don't think libflahssupport.i386 is conditional on the presence of .x86_64 in the repo | |
| f13 | nirik: 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? | ||
| nirik | I 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. | |
| f13 | notting: 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. | ||
| skvidal | hold on | |
| notting | so, libflashsupport is a dlopened() module that changes the audio output routines | |
| skvidal | I want to make sure | |
| nirik | yeah, the flash-plugin has very generic requires. | |
| skvidal | we've got a fair bit of the tail wagging the dog here | |
| drago01 | its not a fedora package its a kind of "should work on all rpm distros package" | |
| skvidal | we're going to add a bunch of pkgs to our default install just to make adobe's flash work? | |
| f13 | skvidal: yes, we're bending over backwards for Adobe here. | |
| bpepple | skvidal: yup. | |
| notting | w/o flash plugin source, it's impossible to tell why they need it | |
| skvidal | f13: I think we're bending over forward and letting closed source demands ream us in the ass | |
| f13 | My 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. | ||
| notting | f13: if they have to manually select it, couldn't they just have to manually select the i386 version? | |
| * nirik nods at notting. | ||
| f13 | notting: praps. | |
| * c4chris nods at notting too | ||
| nirik | or if the x86_64 one is gone, and the i386 one is in the repo, they wouldn't have to specifiy arch, right? | |
| skvidal | has anyone asked adobe at all? | |
| f13 | skvidal: warren claims to have. | |
| skvidal | or are we just assuming they won't change/fix their pkg? | |
| * jeremy is here now | ||
| f13 | skvidal: 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. | ||
| skvidal | f13: sounds very reasonable to me | |
| f13 | but he thinks it will require changes in RHEL+SuSE+whomeverelse it will be tough to get approved. | |
| (I think tough shit, make it happen) | ||
| notting | f13: do we actually have a statement from them as to what they are using for sound natively, and why that has issues with PA? | |
| f13 | regardless, 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... | ||
| f13 | ok, 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 | ||
| c4chris | what nirik said | |
| * stickster reads back.... | ||
| bpepple | f13: you get an ETA yet? | |
| tibbs | This is basically an issue of balancing distro purity against ease of use for the users. | |
| f13 | I 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. | |
| f13 | bpepple: sadly, no. | |
| tibbs | It would help to have stats on just how many packages this pulls in, and to characterize the difficulty for users who will encounter this. | |
| dwmw2 | it makes some sense for the nspluginwrapper-plugin library to require the i386 nsplugin-wrapper binary. And for the nsplugin-wrapper binary to require libflashsupport. | |
| f13 | tibbs: 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 | ||
| dwmw2 | ah, point | |
| f13 | I'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 | ||
| tibbs | Does this all come down to balancing some unknown number of i386 packages in the default install versus one "yum install" command? | |
| f13 | anyway, 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 | ||
| bpepple | f13: agreed, how about we move on, and code back to it near the end of the meeting. | |
| s/code/come/ | ||
| f13 | if 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 | |
| drago01 | f13: adobe reader ... java was never wrappable anyway (and still isn't) | |
| bpepple | f13: are we still in holding pattern for the release date, or do we need to discuss it? | |
| jeremy | f13: x86_64 isn't cd sized anyway. even without 32bit bits | |
| f13 | jeremy: nod. | |
| stickster | f13: 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. | |
| f13 | bpepple: I think we're still in a holding pattern, keeping a very watchfull eye on the X stuff, and anaconda upgrades | |
| f13 | stickster: understood, which is why I want a decision today, so that we can get those notes written today | |
| bpepple | f13: 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 | ||
| poelcat | just 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 | ||
| poelcat | we 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 | ||
| bpepple | poelcat: 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. | ||
| poelcat | oops... xulrunner is done | |
| * c4chris says drop | ||
| poelcat | so really just two X features and tetex | |
| f13 | just got a reply from danpb, trying to drag him in here | |
| poelcat | all of which I *think* are done, but just need final updates | |
| mclasen | xserver15 is not done insofar as there is not a 1.5 release yet... | |
| poelcat | mclasen: fair enough... what should the feature page say then? | |
| mclasen | we could rename the feature xserver1.4.99.3 and put it at 100% | |
| poelcat | lol | |
| mclasen | but 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 | ||
| bpepple | f13: ok, so we'll drop the virtstorage feature. | |
| f13 | mclasen: 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 ? | |
| mclasen | ask ajax, I don't know | |
| c4chris | pre-release should do | |
| bpepple | c4chris: agreed. | |
| mclasen | he's put a link to a tentative schedule for 1.5 on the feature page, I believe | |
| * dgilmore is here now | ||
| f13 | honestly, 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 | ||
| bpepple | looks like 1.5 is supposed to hit on april 25th according to his e-mail. | |
| poelcat | f13: thanks... can you just put it on the feature page? | |
| f13 | sure, that'll happen. | |
| poelcat | how about this one: http://fedoraproject.org/wiki/Features/OneSecondX | |
| ? | ||
| c4chris | afaik it's inbedded in the X 1.5 ? | |
| poelcat | f13: can you cover it too? | |
| * warren reading backlog | ||
| poelcat | which leave us with only one left: http://fedoraproject.org/wiki/Releases/FeatureTexLive | |
| f13 | poelcat: sure. | |
| dgilmore | whats the last 5% | |
| it seesm like its all in | ||
| f13 | heh, seems there is a little bit of doubt from the X side that we'll actually release in 2 weeks. | |
| poelcat | dgilmore: can't tell | |
| bpepple | maybe in the next feature release cycle we can add a section about what still needs to be done to get to 100%. | |
| dgilmore | bpepple: that would be useful i think | |
| c4chris | bpepple: yup | |
| f13 | bpepple: good call | |
| dgilmore | AFAIKT it seesm like texlive is done | |
| mclasen | the last 5% is changing the percentage to 100% | |
| bpepple | mclasen: ;) | |
| f13 | yeah, I vote we make an executive call and call this one "done" | |
| bugs left can be fixed later. | ||
| bpepple | f13: +1 | |
| c4chris | done +1 | |
| dgilmore | +1 | |
| tibbs | +1 | |
| warren | reading 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. | |
| f13 | warren: we need to get a decision made today | |
| warren | As for me not being here, that's my fault. I screwed up. | |
| poelcat | re: tetex got it... that's all from me | |
| f13 | for release notes purposes. | |
| bpepple | warren: we're going to get back to discussing flahs after we finish up with features. | |
| f13 | bpepple: looks like we're ready for that | |
| notting | bpepple: well, was there PK and swfdec to review? | |
| bpepple | notting: yeah, we should those. | |
| notting | i guess i brought this up, so... | |
| warren | ok | |
| dgilmore | notting: whats the status? | |
| notting | we added PackageKit and swfdec as default for the beta, with the idea that we'd review them | |
| dgilmore | PAckageKit i dont think is quite ready | |
| notting | the two test plans are at: http://fedoraproject.org/wiki/QA/TestResults/Fedora9PackageKit/Rawhide | |
| notting | and https://fedoraproject.org/wiki/QA/TestResults/Fedora9Swfdec/Rawhide | |
| not sure if anyone has run through the PK tests yet | ||
| so, PK first? | ||
| f13 | I'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 | |
| f13 | while 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 | |
| bpepple | f13: agreed. It's got some rough spots, but overall I haven't had any real problems. | |
| f13 | it'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 (: | ||
| hughsie | f13: ahh, thanks for the ping! | |
| hughsie | PackageKit 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 | ||
| EvilBob | s/would/should | |
| hughsie | theres 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 | |
| f13 | hughsie: is that in RH bugzilla, or fdo? | |
| +1 | ||
| c4chris | +1 | |
| hughsie | RH | |
| dgilmore | -1 | |
| f13 | hughsie: what's the number then ? "PKFBlocker" isn't registering as a vlaid alias | |
| bpepple | dgilmore: Is there anything in particular that you don't like about PK? | |
| hughsie | f13: sorry PKF9Blocker iirc | |
| mclasen | the blocker name is actually F9PKBlocker | |
| dgilmore | bpepple: ive not done extensive testing of PK. but ive found that it seems to error out alot | |
| hughsie | f13: F9PKBlocker sorry | |
| f13 | 3rd time is the charm. | |
| hughsie | dgilmore: have you filed bugs? | |
| dgilmore | bpepple: and it seems to do a poor job of letting me know what its doing | |
| f13 | dgilmore: 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) | |
| dgilmore | hughsie: not yet | |
| bpepple | dgilmore: ok, was just wondering. Thanks for the input. | |
| hughsie | dgilmore: then i know of no problems :-) | |
| dgilmore | f13: its not been clear to me | |
| f13 | anyway, bpepple is that enough votes? | |
| bpepple | I count six '+1', and one '-1'. | |
| f13 | jeremy: ? | |
| bpepple | spot, caillon, dwmw2, jeremy: ? | |
| dgilmore | bpepple: i count 5 +1 and 1 -1 | |
| bpepple | dgilmore: did you get nirik's? | |
| spot | +1 | |
| f13 | dgilmore: you missed bpepple 's initial +1 | |
| * jwb finally shows up | ||
| f13 | dgilmore: or nirik's late +1 | |
| dgilmore | bpepple: no | |
| dwmw2 | sorry, was away briefly | |
| dgilmore | f13: i missed nirik's | |
| jwb | which feature are we on? | |
| f13 | jwb: dwmw2: looking for go/nogo on PK by default in F9 | |
| dgilmore | jwb: PackageKit | |
| bpepple | jwb: packagekit | |
| caillon | bpepple, PK = PackageKit. leave it on. | |
| jwb | i probably shouldn't vote here | |
| f13 | which, 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. | |
| bpepple | ok, that makes it seven '+1', and one '-1'. It's going to be installed by default. | |
| dgilmore | f13: pirut needs to be Obsoleted by PK | |
| dwmw2 | +0 | |
| hircus | f13: on a clean install, pirut is not installed anymore, right? | |
| jwb | i was never able to turn it off, so i just yum removed it | |
| dwmw2 | no opinion here | |
| bpepple | hircus: I believe so. | |
| notting | f13: on an upgrade, will they actually get PK? | |
| f13 | hircus: clean installs no | |
| notting: yes, if they have system-config-printers | ||
| notting: due to system-install-packages which is now PK | ||
| notting | f13: just take the applet out of pirut | |
| erm, the autostart desktop | ||
| dgilmore | notting: it got on my system sduring updates at some point | |
| f13 | jwb: can you file a bug about not being able to turn it off? | |
| dgilmore | pirut is needed by (installed) system-config-kickstart-2.7.15-2.fc9.noarch | |
| f13 | jwb: we'll want hughsie and co to fix it. | |
| hircus | have we gotten through to the x86_64 + flash item yet? | |
| notting | no | |
| hughsie | f13: why do we need the xtra applet? | |
| jwb | f13, eventually | |
| bpepple | hircus: no, after we talk about swfdec. | |
| dgilmore | hughsie: both at one is confusing and annoying | |
| f13 | hughsie: we don't, but some felt the original plan was that one could remove PK and fall back to pirut if they chose. | |
| hughsie | dgilmore: can't you remove pup? | |
| jwb | fwiw, i removed all of them | |
| :) | ||
| f13 | if 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 | ||
| warren | can't the PK applet detect and remove pup from the session? | |
| and vice-versa | ||
| f13 | hughsie: upon upgrades,s omething would have to forcefully remove pup | |
| hughsie | f13: yup, i would say have gnome-pakagekit obsolete pup | |
| f13 | proposal: figure out upgrades and pup on fedora-devel-list our in #fedora-devel, move on. | |
| jwb | yeah | |
| mclasen | warren: that way lies madness | |
| bpepple | moving on.... | |
| notting | ok, the next one is swfdec | |
| dgilmore | we need to make sure that system-config-kickstart works still | |
| --- bpepple has changed the topic to: Swfdec | ||
| notting | https://fedoraproject.org/wiki/QA/TestResults/Fedora9Swfdec/Rawhide | |
| warren | mclasen: just be thankful I didn't suggest running the applet using alternatives =) | |
| f13 | dgilmore: yes, that should just need pirut and not pup. | |
| notting | at the moment, you need a scratch build of it, otherwise it's flaming death all over | |
| even still, (IMO), it's not good | ||
| dgilmore | f13: well we should split pirut into pirut and pup | |
| f13 | dgilmore: moving on... | |
| jwb | notting, wow | |
| that's very red | ||
| f13 | notting: is hte question enabled by default, included but optional, or not included at all? | |
| s/is/are/ | ||
| dgilmore | jwb: flash is the spawn of satan so its expected | |
| bpepple | f13: I believe by default. | |
| notting | no reason to nuke it from the tree. it's a question of default or no | |
| dgilmore | notting: enabled by default -1 | |
| jwb | what's the alternative default? nothing? | |
| notting | jwb: yes | |
| hircus | question: if both swfdec and Adobe's flash-plugin are installed, which one would get used? | |
| dgilmore | jwb: yes | |
| notting | jwb: which means -> firefox's plugin finder -> adobe flash | |
| bpepple | hircus: swfdec. | |
| hircus | eek. then it probably should not be on by default | |
| jwb | notting, rock and hard place, eh? | |
| nirik | enabled by default -1 here too... perhaps f10 if it's better? ;) | |
| f13 | ok, enabled by default -1 | |
| * bpepple will abstain. | ||
| f13 | nirik: where "better" involves the use of non-free plugins? | |
| warren | -1 | |
| nirik | no idea, but thats 6 whole months from now. ;) | |
| notting | well, functional swfdec will always require non-free codecs. but right now, it's not that great even with them, IMO | |
| f13 | nirik: i'd rather make the decision at the feature freeze, not the day or 3 after the final freeze (: | |
| nirik | indeed. | |
| warren | Even if the proprietary codecs made it 100% working, are we really better off morally? Both options are proprietary. | |
| dwmw2 | swfdec not gnash? | |
| bpepple | warren: I'd say it's better than pointer our users to a 100% proprietary option. | |
| s/pointer/pointing/ | ||
| notting | dwmw2: if someone wants to duplicate the test matrix against gnash... | |
| warren | bpepple: not to mention the poor user experience aspect. | |
| notting | dwmw2: swfdec has gst-install-missing-plugin support, though. don't think gnash does | |
| dwmw2 | I just thought gnash was better these days, that's all. If swfdec is, I'll switch :) | |
| bpepple | notting: yeah, gnash doesn't. | |
| * nirik needs real flash for his credit union website of all things. *shudder* | ||
| dwmw2 | scary | |
| notting | nirik: can't you go ADA on them? | |
| dwmw2 | I'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 | |
| f13 | anyway, time issues, can we get a complete vote? | |
| dgilmore | nirik: my credit union makes me have the java plugin installed to login | |
| nirik: even though they use jsp pages and not java applets | ||
| f13 | dwmw2: 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 | ||
| jwb | VOTE PLEASE | |
| dgilmore | it seesm that they have some dumb people | |
| dwmw2 | f13: or in libflashsupport? :) | |
| c4chris | -1 | |
| jwb | -1 | |
| dwmw2 | but that just makes that whole thing scarier :) | |
| +0 | ||
| f13 | -1 | |
| dgilmore | i count 8 -1 | |
| one 0 | ||
| bpepple | ok, swfdec isn't installed by default. | |
| f13 | bpepple: remind me to make sure it stays on the DVD/splitCD media | |
| notting | thx 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 | ||
| f13 | Date point. | |
| warren | here 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. | ||
| jwb | pastebin! | |
| f13 | default 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 | ||
| f13 | post-install 'yum install libflashsupport.i386 nspluginwrapper.i386' drags in 51 packges (all i386), for 22 megs download size | |
| warren | Any disputing of these points? | |
| * bpepple hasn't even had time to read them. | ||
| notting | warren: is the native alsa support in flash identical to the alsa ifdefs of libflashsupport? | |
| nirik | well, 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. | |
| warren | notting: I could ask. | |
| notting | warren: that could make it more obvious wtf it fails with PA | |
| warren | notting: do we install the necessary i386 stuff to do 32bit ALSA thunking by default? | |
| dwmw2 | hopefully by the time they get round to a 64-bit build, they'll have solved this without the need for libflashsupprt | |
| hircus | warren: as of F9 beta, it looks like no 32-bit libraries are installed by default | |
| * nirik nods at dwmw2 | ||
| warren | nirik: I can't answer that question due to NDA. hint hint. | |
| notting | warren: oh geez. they dlopen libasound? WHACK. | |
| f13 | warren: aside from libflashsupport, there is no i386 packages in the default x86_64 install | |
| * f13 spotted something /very/ curious with nspluginwrapper though | ||
| hircus | f13: weird, libflashsupport.i386 is not in my default install | |
| warren | f13: well, I removed the cross-arch dep a few days ago, so there should be none now either. | |
| hircus | nor nsplugwrapper.i386 | |
| f13 | hircus: 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 | ||
| hircus | f13: ah ok. this is a side-effect of yum being arch-strict then | |
| warren | f13: I subsequently did think of a better way to do cross-arch deps without pulling in filelists. | |
| f13: really? I didn't do that. | ||
| f13 | in case the data point was missed above, adding libflashsupport.i386 and nspluginwrapper.i386 introduces 51 (inclusive) i386 packages. | |
| * dwmw2 blinks | ||
| dwmw2 | that's a lot of packages | |
| warren | f13: many of which are already on the livecd but not regular install | |
| dwmw2 | mostly individual libXfoo? | |
| c4chris | yea, me is still at default == -1 | |
| f13 | warren: i386 ones? | |
| warren | Add 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. | ||
| f13 | warren: what is i386 on the Live CD right now? | |
| warren | f13: yes. | |
| hm | ||
| f13 | wow, 47 packages come from nspluginwrapper | |
| warren | f13: 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. | ||
| warren | nirik: what was your idea? | |
| f13 | warren: oh god, scim. | |
| notting | write yum-plugin-flash :P | |
| hircus | Flash is presumably the only reason one'd need nspluginwrapper.i386? is the OpenJDK plugin working on all sites? | |
| nirik | nirik would prefer: libflashsupport optional, and only i386 version is in x86_64 repos... | |
| hircus: no, but java doesn't work with nspluginwrapper anyhow. | ||
| warren | we do need it in the repos or it wont be installable at all | |
| f13 | warren: need what in the repo? | |
| warren | f13: libflashsupport and nspluginwrapper i386 | |
| hircus | nspluginwrapper.i386 not installable if x86_64 not in repo? | |
| oh | ||
| f13 | warren: yeah, I don't think anybody is suggesting we remove it from the repo (or DVD) all together | |
| notting | skvidal: say, how hard would a plugin that adds nspluginwrapper & libflashsupport iff someone adds a 'flash-plugin' package be? | |
| f13 | I mean, really, we could make a special comps group for this (EEK translations) and make it checkable from the first software screen | |
| skvidal | notting: not very - a bit odd, but not hard | |
| nirik | I 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? | |
| warren | Key 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. | ||
| notting | nirik: that won't pull in nspluginwrapper,though | |
| warren | nirik: we still have the lack of nspluginwrapper.i386 problem | |
| hircus | how about a package that contains scripts needed to install proprietary things | |
| f13 | warren: make libflashsupport require it (: | |
| dgilmore | warren: i think we should not take steps to make it easier for propietory software | |
| hircus | so install-flash -> download Adobe's repo file and yum install the required things | |
| warren | dgilmore: you mean like codeina? | |
| dgilmore | hircus: how about no | |
| warren: yes | ||
| hircus | or that. just document things | |
| f13 | warren: the term "developers" in B is incorrect. It's not just developers whom don't want to be bothered with unnecessary i386 packages. | |
| warren | dgilmore: then we should remove the plugin finder from firefox too. | |
| dgilmore | warren: ive been vocal that with codenia we lose | |
| f13 | warren: if we could, we probably would. | |
| but then e'd have to call it !firefox | ||
| warren | f13: ok, same argument s/developers // | |
| notting | well, it's (technically) a regression from F-8. do we care? | |
| warren | I do. | |
| dgilmore | notting: i dont think we care | |
| notting | skvidal: you know, i may have written this once already | |
| warren | is jeremy around? He had an opinion. | |
| f13 | notting: I don't, as I think we can make it obvious at install time to get "flash support" | |
| skvidal | notting: yes, I think so | |
| warren | OH 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 | ||
| warren | 1) arch-specific stuff in comps | |
| warren | 2) arch-specific livecd kickstart files | |
| 3) multilib policy exclusions whitelist | ||
| notting | hm | |
| warren | jeremy thinks we should use cross-arch dependencies | |
| dgilmore | warren: thats just wrong | |
| warren | dgilmore: which part? | |
| dgilmore | "cross-arch dependencies" | |
| warren | dgilmore: why? | |
| notting | having 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 | |
| c4chris | default: no tickable box in anaconda: ok | |
| dgilmore | warren: because it means those that want clean arch systems cant | |
| c4chris | could have a tickable box for swfdec in anaconda too, in that case... | |
| dgilmore | notting: indeed we should not help people get adobe flash period | |
| warren | If 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. | |
| f13 | notting: true. We could term it "support for 32bit firefox plugins" (: | |
| f13 | Danger! hyperbole ahead! | |
| mclasen | warren: how about firmware in the kernel ? | |
| notting | mclasen: oooh, why i oughta..... | |
| warren | mclasen: that isn't pointing, that's inclusion. =) | |
| Why is nobody answering the above question? (repasting) | ||
| mclasen | warren: so you want to avoid being a hypocrite by playing language games | |
| warren | Key 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. | ||
| dgilmore | warren: i say we support B | |
| hircus | so 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 | |
| warren | dgilmore: are they more prevalent than group A? | |
| f13 | warren: they're more useful to us than Group A | |
| spot | i've been really quiet throughout all of this, but adobe could fix this with a single line in their rpm. | |
| dgilmore | warren: Adobe can seriously go fall off a cliff for all I care about flash | |
| warren: i honestly dont care if they are | ||
| notting | skvidal: hrm, can't find it | |
| warren | spot: that is a logical misconception | |
| hircus | we can do (A) and (B) together if we blacklist libflashsupport.x86_64 | |
| spot | warren: its not. its a fact. | |
| warren | hircus: no, that doesn't solve nspluginwrapper.i386 problem | |
| c4chris | for me, A == bend over and let Adobe have it..., so I'm for B | |
| spot | warren: one file Requires will fix this. | |
| hircus | warren: ah yes, nspluginwrapper | |
| warren | spot: Requires what? | |
| skvidal | notting: I can write a plugin for this, if you'd like | |
| hircus | is there a comps category for 32-bit libraries? | |
| notting | Requires: PAIN | |
| warren | skvidal: that does what? | |
| skvidal | notting: but I reserve the right to name it yum-cracked-out-shit | |
| f13 | warren: they could require nspluginwrapper.i386, or whatever file that provides on i386 arches | |
| skvidal | or yum-adobe-needs-to-fix-their-goddamned-deps | |
| f13 | hircus: not any more. | |
| dgilmore | skvidal: i think it should be yum-im-smiking-some-nasty-shit | |
| skvidal: i think it should be yum-im-smoking-some-nasty-shit | ||
| skvidal | dgilmore: I dunno what you're smiking | |
| notting | hm | |
| warren | f13: adobe wont do it because most distros don't do nspluginwrapper or pulseaudio by default. | |
| skvidal | but you keep your second-hand-smike away from me ;) | |
| dgilmore | warren: thats adobes problem not ours | |
| f13 | warren: don't care about default. Do they /have/ a nspluginwrapper | |
| warren | we are being completely unrealistic to insist that they add dependencies just for us. | |
| spot | %if 0%{fedora} | |
| f13 | and that. | |
| notting | Proposal: 'ExclusiveArch: i386' libflashsupport. Do not install by default, document the need to install libflashsupport/nspluginwrapper if you want adobe flash | |
| hircus | and RHEL | |
| drago01 | skvidal: did you want to kill me for this kind of hack? | |
| spot | Requires: %{_libdir}/libflashsupport.so | |
| warren | spot: they don't build distro specific RPMS | |
| drago01 | *didn't | |
| nirik | notting: +1 | |
| spot | %endif | |
| dgilmore | warren: 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 | |
| skvidal | drago01: yes, of course | |
| c4chris | notting: +1 | |
| spot | notting: +1 | |
| warren | dgilmore: there is no reason to be disrespectful. | |
| skvidal | drago01: which is why I'd do it but only in an extremely angry way :) | |
| f13 | notting: +1 (and we can even have libflashsupport require nspluginwrapper, so one package to install) | |
| bpepple | notting: +1 | |
| drago01 | skvidal: ;) | |
| hircus | speaking of 32-bit libraries, any idea if we can put pulseaudio-utils.i386 and pulseaudio-esound-compat.i386 into the x86_64 tree? | |
| warren | f13: I don't want to force people to use nspluginwrapper and vice versa. | |
| dgilmore | warren: your being disrespectful of the whole community | |
| c4chris | k, me needs to go take care of kids... Later folks | |
| warren | dgilmore: that is a matter of opinion. | |
| bpepple | later, c4chris | |
| dgilmore | notting: +1 | |
| warren | hircus: why? | |
| f13 | warren: 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. | |
| warren | hircus: bring this up on the list? this is a new topic | |
| hircus | needed for the other annoying 32-bit app, Real Player | |
| warren | f13: hey, I suggested removing the plugin finder and codeina | |
| spot | people still use Real Player? | |
| hircus | warren: OK. it's already on bugzilla, but I don't remember a discussion on it yet | |
| skvidal | spot: for porn | |
| hircus | oh, and Crossover Wine too | |
| f13 | warren: no, you tried to use them as hyperbole | |
| hircus | skvidal: haha. that and BBC | |
| f13 | spot: I think I have a ram file buffering somewhere from 1998 | |
| skvidal | hircus: same thing | |
| dgilmore | hircus: care factor of Real is 0 | |
| skvidal | hey, I know - let's include helixplayer! | |
| wait, wait, no | ||
| f13 | hircus: Can we discuss that in #fedora-devel after this meeting? | |
| warren | f13: that is a great way to dismiss a valid argument without discussing its merits. | |
| hircus | sure | |
| bpepple | ok, I counted seven '+1' to notting's proposal, | |
| warren | OK, so the only change we're making is simply make sure they're on the DVD? | |
| f13 | warren: 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 | ||
| warren | f13: 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++ | ||
| notting | hm. does it buy anything to have them on the dvd? it's not like we have adobe flash on the dvd | |
| f13 | warren: and begging stickster to push them through for you. | |
| nirik | the f8 notes don't need much change: http://docs.fedoraproject.org/release-notes/f8/en_US/sn-Desktop.html#sn-Enabling-Flash-Plugin | |
| warren | f13: push what? | |
| f13: excuse me, I did what? | ||
| spot | ladies. | |
| f13 | notting: they can select them at install time, so that once they start browsing and install the plugin, it'll "just work" | |
| spot | please take it outside. | |
| warren | f13: there must be some big misunderstanding here. | |
| f13 | warren: 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. | |
| warren | f13: I didn't talk to stickster about anything related to flash. | |
| f13 | warren: 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 | ||
| warren | Oh, OK, I misunderstood, I thought you were accusing me of something. | |
| f13 | no, just outlining what work needs to be done. | |
| bpepple | ok, is there anything else regarding x86_64 flash, or can we start to wrap up? | |
| notting | we have 15 minutes before we have to clear the meeting room for infrastructure :) | |
| warren | Why does it seem that people are taking this far too personally? | |
| drago01 | bpepple: i386 pa libs in the x86_64 repo | |
| bpepple | drago01: let's take that to the mailing lists. | |
| drago01 | was "broken" for f8 since the beginning | |
| ok, fair enough | ||
| --- bpepple has changed the topic to: FESCo meeting -- Free discussion around Fedora | ||
| warren | My 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. | |
| spot | f13: i'm making progress on mono | |
| tibbs | We've made some progress in getting the F9-targeted merge reviews down. | |
| spot | f13: hopefully, we won't have to block anything | |
| tibbs | We're just below 50% closed right now. | |
| notting | do 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" | ||
| warren | f13: we making sure the i386 pulse components are in the x86_64 repo as well? (not default install) | |
| f13 | warren: we aren't yet. Had needed to speak with lennart about it, but that was an unconclusive discussion | |
| and frankly I forgot about it | ||
| warren | do 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? | ||
| drago01 | warren: blocker bug? | |
| f13 | warren: not sure what you're asking. | |
| warren: pungi errs on the side of 'every possible arch' when composing | ||
| warren | oh | |
| ok | ||
| f13 | but for pulse stuff, we have tomake it show up in the x86_^4 repo to begin with, and tha'ts mash | |
| bpepple | ok, if there's nothing else I'm going to wrap the meeting....... | |
| * bpepple will end the meeting in 60 | ||
| hircus | sent 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!