Is there a reason the firefox.i386 and firefox-devel.i386 packages are in the x86_64 repo for rawhide? They both got pulled into my system when the firefox-devel package was introduced. However, "yum remove firefox.i386" shows that there are no dependencies. I was just wondering if this was deliberate and if they will be around for a while.
Thanks Demond
On Mon, Jul 31, 2006 at 11:04:16AM -0400, Demond wrote:
Is there a reason the firefox.i386 and firefox-devel.i386 packages are in the x86_64 repo for rawhide? They both got pulled into my system when the firefox-devel package was introduced. However, "yum remove firefox.i386" shows that there are no dependencies. I was just wondering if this was deliberate and if they will be around for a while.
It's handy if you have to use the flash plugin....
Le lundi 31 juillet 2006 à 11:11 -0400, Matthew Miller a écrit :
On Mon, Jul 31, 2006 at 11:04:16AM -0400, Demond wrote:
Is there a reason the firefox.i386 and firefox-devel.i386 packages are in the x86_64 repo for rawhide? They both got pulled into my system when the firefox-devel package was introduced. However, "yum remove firefox.i386" shows that there are no dependencies. I was just wondering if this was deliberate and if they will be around for a while.
It's handy if you have to use the flash plugin....
Except x86_64 OO.o will require x86_64 firefox, which will stomp on the i386 one, and kill flash.
Anyone managed to build http://www.gibix.net/dokuwiki/en:projects:nspluginwrapper
yet?
Nicolas Mailhot writes:
Le lundi 31 juillet 2006 à 11:11 -0400, Matthew Miller a écrit :
On Mon, Jul 31, 2006 at 11:04:16AM -0400, Demond wrote:
Is there a reason the firefox.i386 and firefox-devel.i386 packages are in the x86_64 repo for rawhide? They both got pulled into my system when the firefox-devel package was introduced. However, "yum remove firefox.i386" shows that there are no dependencies. I was just wondering if this was deliberate and if they will be around for a while.
It's handy if you have to use the flash plugin....
Except x86_64 OO.o will require x86_64 firefox, which will stomp on the i386 one, and kill flash.
Surely this is a bug in yum. OK, we should get stuff multilibbed so you can install -32 if you really want, but yum always installing both libs is a PITA.
Andrew.
On Mon, 2006-07-31 at 16:28 +0100, Andrew Haley wrote:
Nicolas Mailhot writes:
Le lundi 31 juillet 2006 à 11:11 -0400, Matthew Miller a écrit :
On Mon, Jul 31, 2006 at 11:04:16AM -0400, Demond wrote:
Is there a reason the firefox.i386 and firefox-devel.i386 packages are in the x86_64 repo for rawhide? They both got pulled into my system when the firefox-devel package was introduced. However, "yum remove firefox.i386" shows that there are no dependencies. I was just wondering if this was deliberate and if they will be around for a while.
It's handy if you have to use the flash plugin....
Except x86_64 OO.o will require x86_64 firefox, which will stomp on the i386 one, and kill flash.
Surely this is a bug in yum. OK, we should get stuff multilibbed so you can install -32 if you really want, but yum always installing both libs is a PITA.
There is an "exactarch" directive for yum.conf which almost sounds like it would do the right thing. But it's already defaulted to on and doesn't do what you (and I) would like here.
C.
On Monday 31 July 2006 08:40, Caolan McNamara wrote:
There is an "exactarch" directive for yum.conf which almost sounds like it would do the right thing. But it's already defaulted to on and doesn't do what you (and I) would like here.
exclude *.i386
Le lundi 31 juillet 2006 à 11:52 -0400, Jesse Keating a écrit :
On Monday 31 July 2006 08:40, Caolan McNamara wrote:
There is an "exactarch" directive for yum.conf which almost sounds like it would do the right thing. But it's already defaulted to on and doesn't do what you (and I) would like here.
exclude *.i386
Nah
The problem is x86_64 OO.o wants x86_64 firefox now mozilla's being killed
flash needs i386 x86_64 firefox
multilib will allow i386 and x86_64 firefox to be installed, but the user will only see x86_64 (without flash) because it has /usr/bin priority
On Monday 31 July 2006 11:59, Nicolas Mailhot wrote:
Nah
The problem is x86_64 OO.o wants x86_64 firefox now mozilla's being killed
flash needs i386 x86_64 firefox
multilib will allow i386 and x86_64 firefox to be installed, but the user will only see x86_64 (without flash) because it has /usr/bin priority
I wasn't responding to that problem.
I was responding to the complaint that yum installs both i386 and x86_64 package (if available) by default.
On Mon, Jul 31, 2006 at 05:59:10PM +0200, Nicolas Mailhot wrote:
multilib will allow i386 and x86_64 firefox to be installed, but the user will only see x86_64 (without flash) because it has /usr/bin priority
This is easily changed....
On Monday, 31 July 2006 at 17:22, Nicolas Mailhot wrote:
Le lundi 31 juillet 2006 à 11:11 -0400, Matthew Miller a écrit :
On Mon, Jul 31, 2006 at 11:04:16AM -0400, Demond wrote:
Is there a reason the firefox.i386 and firefox-devel.i386 packages are in the x86_64 repo for rawhide? They both got pulled into my system when the firefox-devel package was introduced. However, "yum remove firefox.i386" shows that there are no dependencies. I was just wondering if this was deliberate and if they will be around for a while.
It's handy if you have to use the flash plugin....
Except x86_64 OO.o will require x86_64 firefox, which will stomp on the i386 one, and kill flash.
How about using gnash-plugin instead? It's already usable.
Regards, R.
Dominik 'Rathann' Mierzejewski wrote:
How about using gnash-plugin instead? It's already usable.
It under review in Fedora Extras. However many of the flash features are not implemented in gnash and some of the flash files are tied to patented codecs and other similar issues.
Rahul
On Mon, 2006-07-31 at 23:39 +0530, Rahul wrote:
It under review in Fedora Extras. However many of the flash features are not implemented in gnash and some of the flash files are tied to patented codecs and other similar issues.
The latter isn't too much of a problem if gnash uses gstreamer appropriately. It doesn't actually have to _include_ the problematic codecs.
On Mon, 2006-07-31 at 17:22 +0200, Nicolas Mailhot wrote:
Anyone managed to build http://www.gibix.net/dokuwiki/en:projects:nspluginwrapper
yet?
I tried. The plugin host thingy just segfaults on startup. Somewhere in library code as far as I could figure out.
Matthew Miller wrote:
On Mon, Jul 31, 2006 at 11:04:16AM -0400, Demond wrote:
Is there a reason the firefox.i386 and firefox-devel.i386 packages are in the x86_64 repo for rawhide? They both got pulled into my system when the firefox-devel package was introduced. However, "yum remove firefox.i386" shows that there are no dependencies. I was just wondering if this was deliberate and if they will be around for a while.
It's handy if you have to use the flash plugin....
Ditto for flash, and it's also handy for the Sun Java plugin. I personally hope firefox.i386 is a permanent addition to the x86_64 repo for FC6. Can someone confirm it is or isn't?
Jay
On Monday 31 July 2006 21:04, Jay Cliburn wrote:
Ditto for flash, and it's also handy for the Sun Java plugin. I personally hope firefox.i386 is a permanent addition to the x86_64 repo for FC6. Can someone confirm it is or isn't?
It may be temporary, it may not be. We've removed mozilla in favor of Firefox for building things against, so firefox grew a -devel sub package. However this is a temporary measure until xulrunner is ready for prime time which will provide the basis of the browsing stuff and a -devel package to build against, so that firefox doesn't need a -devel anymore, and packages can use a much smaller xulrunner to develop against. At that time, firefox may cease to be multilib automatically, however I would entertain requests to force it to be multilib...
On Mon, Jul 31, 2006 at 10:15:12PM -0400, Jesse Keating wrote:
It may be temporary, it may not be. We've removed mozilla in favor of Firefox for building things against, so firefox grew a -devel sub package. However this is a temporary measure until xulrunner is ready for prime time which will provide the basis of the browsing stuff and a -devel package to build against, so that firefox doesn't need a -devel anymore, and packages can use a much smaller xulrunner to develop against. At that time, firefox may cease to be multilib automatically, however I would entertain requests to force it to be multilib...
The argument-which-I-hope-I-will-not-restart applies here too -- Macromedia _ought_ to make an x86_64 version, and they have less incentive to if all the distro vendors make it easier for them to just ship i386 everywhere.
On Mon, 2006-07-31 at 22:34 -0400, Matthew Miller wrote:
The argument-which-I-hope-I-will-not-restart applies here too -- Macromedia _ought_ to make an x86_64 version, and they have less incentive to if all the distro vendors make it easier for them to just ship i386 everywhere.
Basically they don't seem to have a single clue how to write portable software, or use pre-existing libraries: (and they're hiring) http://www.kaourantin.net/2005/08/porting-flash-player-to-alternative.html
Matthew Miller wrote:
On Mon, Jul 31, 2006 at 10:15:12PM -0400, Jesse Keating wrote:
It may be temporary, it may not be. We've removed mozilla in favor of Firefox for building things against, so firefox grew a -devel sub package. However this is a temporary measure until xulrunner is ready for prime time which will provide the basis of the browsing stuff and a -devel package to build against, so that firefox doesn't need a -devel anymore, and packages can use a much smaller xulrunner to develop against. At that time, firefox may cease to be multilib automatically, however I would entertain requests to force it to be multilib...
The argument-which-I-hope-I-will-not-restart applies here too -- Macromedia _ought_ to make an x86_64 version, and they have less incentive to if all the distro vendors make it easier for them to just ship i386 everywhere.
I can totally agree with this. But others will say, and with a reasonably good point is wether the number of people using x86_64 is larger or smaller than the number of people using and requiring flash mandatorily.
There is no right answer for such, only hardcore left and right viewpoints based on personal individual preference and requirements.
If Fedora were to ship _only_ the 32bit version of firefox in x86_64, then I would more or less have a problem with that assuming the x86_64 build were more performant (as it should be) overall.
The web is probably _the_ most important client-side "killer app" right now however, and like it or not, many people rely on flash, java and/or other stuff which is equally proprietary, and can only consider using a product if it provides the functionality needed. Including the i386 version of firefox enables people to optionally use this software they require without forcing it on them, allowing more people to use the OS without having to rebuild things themselves, or hack around the problem. It seems a reasonable compromise between two extreme viewpoints to include 32bit ff to me, and it itself is completely open source.
I also agree however that in theory at least, this provides macromedia with less incentive to provide a 64bit version of flash. Where I contrast though, is that I do not see this as a problem. To provide only the 64bit version of firefox would in theory promote macromedia to provide a 64bit version of a proprietary product, thereby encouraging use of proprietary products even more IMHO, as 32bit OS's are legacy in many ways now, and will be legacy in all ways in the near future. Let's leave proprietary software stuck in 32bit land, and hopefully an open source alternative to flash will come along which happens to be 64bit clean.
Just an alternative viewpoint, also purely based on open source advocacy.
Matthew Miller wrote:
The argument-which-I-hope-I-will-not-restart applies here too -- Macromedia _ought_ to make an x86_64 version, and they have less incentive to if all the distro vendors make it easier for them to just ship i386 everywhere.
If Macromedia Flash doesn't work for you, try gnash and if that doesn't work... at least you have access to the code to perhaps make a difference ;) people should direct their focus on gnash and work on improving it.
Michael
Jesse Keating wrote:
On Monday 31 July 2006 21:04, Jay Cliburn wrote:
Ditto for flash, and it's also handy for the Sun Java plugin. I personally hope firefox.i386 is a permanent addition to the x86_64 repo for FC6. Can someone confirm it is or isn't?
It may be temporary, it may not be. We've removed mozilla in favor of Firefox for building things against, so firefox grew a -devel sub package. However this is a temporary measure until xulrunner is ready for prime time which will provide the basis of the browsing stuff and a -devel package to build against, so that firefox doesn't need a -devel anymore, and packages can use a much smaller xulrunner to develop against. At that time, firefox may cease to be multilib automatically, however I would entertain requests to force it to be multilib...
Thanks for that information.
I'm indifferent to browser make and model, myself; Firefox just seems to be in vogue and I'm accustomed to it now. But the enduring headache for a number of FC x86_64 users is the absence of 64-bit Macromedia Flash and Sun Java plugins -- despite the availability gnash and blackdown and nspluginwrapper -- and fedoraforum is chock full of people trying to figure out how to add i386 repos and install and keep up to date a "foreign" arch package in x86_64. For some AMD64 owners, the decision whether to use FCx.i386 or FCx.x86_64 is swayed to i386 by the simple desire to avoid the wrestling match with 32-bit Firefox and its plugins in a 64-bit Fedora. (A cursory search of the AMD64 forum at fedoraforum will bear out this assertion.)
I wrote a howto at fedoraforum that lays out the steps to get 32-bit Firefox installed with Flash and Sun Java in x86_64, but I'm occasionally astonished at just how badly people can muck it up by not following the instructions to the letter, and sometimes they run into gnarly dependency problems that may or may not be of their own making. Having 32-bit Firefox in the x86_64 repo significantly simplifies the whole process, and would be cheered by many a new Fedora/AMD64 user.
Jay
On Mon, Jul 31, 2006 at 09:48:38PM -0500, Jay Cliburn wrote:
I'm indifferent to browser make and model, myself; Firefox just seems to be in vogue and I'm accustomed to it now. But the enduring headache for a number of FC x86_64 users is the absence of 64-bit Macromedia Flash and Sun Java plugins -- despite the availability gnash and blackdown and nspluginwrapper -- and fedoraforum is chock full of people trying to figure out how to add i386 repos and install and keep up to date a "foreign" arch package in x86_64. For some AMD64 owners, the decision whether to use FCx.i386 or FCx.x86_64 is swayed to i386 by the simple desire to avoid the wrestling match with 32-bit Firefox and its plugins in a 64-bit Fedora. (A cursory search of the AMD64 forum at fedoraforum will bear out this assertion.)
I wrote a howto at fedoraforum that lays out the steps to get 32-bit Firefox installed with Flash and Sun Java in x86_64, but I'm occasionally astonished at just how badly people can muck it up by not following the instructions to the letter, and sometimes they run into gnarly dependency problems that may or may not be of their own making. Having 32-bit Firefox in the x86_64 repo significantly simplifies the whole process, and would be cheered by many a new Fedora/AMD64 user.
Much as it is highly annoying, other distributions such as OpenSuSE have started shipping only the 32-bit Firefox or equivalent on AMD64, and not shipping a 64-bit Firefox at all, for exactly this reason. Idea being work must happen in the background to get 64-bit Java and other plugins to work, but until then, don't dork over your end users. You loose a lot of bully pulpit, but you make for happier users.
On 7/31/06, Matt Domsch Matt_Domsch@dell.com wrote:
You loose a lot of bully pulpit, but you make for happier users.
They are going to learn a very hard lesson. Users are never happy, all you do is shift what users are unhappy about. In fact I generally work under the assumption that the optimal integrated userbase unhappiness is an adiabatic constant which you can not decrease through incremental changes. No matter what incremental decisions you make, the total unhappiness has a lower bound and unless you have concrete evidence to the contrary, you also need to assume you are riding at the lower bound at every iteration of your icremental process.
Certain correlaries immediate follow from these assumptions. One of which is that instead of thinking about how to increase happiness which incremental decisions, the most constructive way to think is how do I best manage a constant level of userbase unhappiness to best meet long term goals. Instead of asking question like.. "will this design decision about this compoent make users happier?" the better question becomes "What compoent do we want users to be unhappiest about?"
-jef"when people answer the question about their glass being half full or half empty, why do they always forget that the glass is half full with air as well?"spaleta
Jef,
It may be bloody hard to lower the unhappiness of users past a limit, but it's *not* hard to have it increase manifold, usually as a result of "they're unhappy anyway, a little more unhappiness won't change anything" attitudes.
Jay Cliburn wrote:
I wrote a howto at fedoraforum that lays out the steps to get 32-bit Firefox installed with Flash and Sun Java in x86_64
As additional data points relating to this topic, there are actually two howtos at fedoraforum that provide instructions for installing firefox.i386 in Fedora x86_64: one howto for FC4 and one for FC5.
FC4: http://forums.fedoraforum.org/forum/showthread.php?t=81591 FC5: http://forums.fedoraforum.org/forum/showthread.php?t=102143
The FC4 howto has been accessed 15,023 times as of this writing, and the FC5 howto has been accessed 9,608 times. Even if just 10% of users accessing those threads were x86_64 users really intent upon installing 32-bit Firefox along with Flash and Sun Java plugins, we're talking about hundreds of end users who'd benefit from having firefox.i386 in the x86_64 repo(s).
If the decision is made to leave ff.i386 in x86_64 permanently, I'd appreciate it if you'd post the decision here when it's made. A lot of folks will be happy to hear the news.
Thanks, Jay
On Mon, 2006-07-31 at 20:04 -0500, Jay Cliburn wrote:
Ditto for flash, and it's also handy for the Sun Java plugin. I personally hope firefox.i386 is a permanent addition to the x86_64 repo for FC6. Can someone confirm it is or isn't?
The blackdown JVM has an x86_64 browser plugin that works just fine for me. I hacked up the jpackage package to get it to build for x86_64:
http://www.haxxed.com/rpms/java-1.4.2-blackdown-1.4.2.03-1jpp.nosrc.rpm
Jay Cliburn wrote:
Matthew Miller wrote:
On Mon, Jul 31, 2006 at 11:04:16AM -0400, Demond wrote:
Is there a reason the firefox.i386 and firefox-devel.i386 packages are in the x86_64 repo for rawhide? They both got pulled into my system when the firefox-devel package was introduced. However, "yum remove firefox.i386" shows that there are no dependencies. I was just wondering if this was deliberate and if they will be around for a while.
It's handy if you have to use the flash plugin....
Ditto for flash, and it's also handy for the Sun Java plugin. I personally hope firefox.i386 is a permanent addition to the x86_64 repo for FC6. Can someone confirm it is or isn't?
Jay
Has a decision been made as to whether firefox.i386 will be left in the x86_64 repos for FC6 final?
On Wednesday 06 September 2006 21:01, Jay Cliburn wrote:
Has a decision been made as to whether firefox.i386 will be left in the x86_64 repos for FC6 final?
So far, xulrunner isn't ready for release, so firefox-devel stays, and thus firefox.i386 stays.
Jesse Keating wrote:
On Wednesday 06 September 2006 21:01, Jay Cliburn wrote:
Has a decision been made as to whether firefox.i386 will be left in the x86_64 repos for FC6 final?
So far, xulrunner isn't ready for release, so firefox-devel stays, and thus firefox.i386 stays.
Elsewhere in this thread you wrote you'd entertain requests to keep it there even after xulrunner is released. What is the formal method for someone like me to make that request?
On Wednesday 06 September 2006 21:23, Jay Cliburn wrote:
Elsewhere in this thread you wrote you'd entertain requests to keep it there even after xulrunner is released. What is the formal method for someone like me to make that request?
There isn't one. I hear your noise though (: We'll save the discussion for when xulrunner shows up.
Jesse Keating wrote:
On Wednesday 06 September 2006 21:23, Jay Cliburn wrote:
Elsewhere in this thread you wrote you'd entertain requests to keep it there even after xulrunner is released. What is the formal method for someone like me to make that request?
There isn't one. I hear your noise though (: We'll save the discussion for when xulrunner shows up.
Even if we decide to keep the i386 firefox (and I think we should), we still have the messy issue of dealing with two launchers. This is very messy from a user friendliness perspective.
- Two browser launchers? - How is xremote supposed to work? You can currently only run one arch of the browser at a time. - It is possible to run both archs with minor changes to the xremote code, but this makes things even more confusing to the user.
Possible solutions... none of which are ideal. - Ship only i386, as that is the only useful arch. - Ship both, but hide the x86_64 launcher from users.
I've seen that Microsoft hasn't found a good solution to this problem when I tried Windows AMD64 beta. Anyone know if they "solved" this in the final release?
Warren Togami wtogami@redhat.com
On Wed, Sep 06, 2006 at 10:43:39PM -0400, Warren Togami wrote:
Possible solutions... none of which are ideal.
- Ship only i386, as that is the only useful arch.
FWIW, this is what openSuSE / SLES did the last time I looked a few months ago.
Warren Togami <wtogami <at> redhat.com> writes:
- Ship only i386, as that is the only useful arch.
The "only useful arch"? Can we please quit assuming everyone needs Flash? I don't even have Flash (or any other proprietary plugin for that matter) installed on this i386 Fedora (I don't have a 64-bit CPU or I'd use x86_64), I don't miss it. Down with Flash ads! Especially those which disable the option to stop the animation or script around it. (That's what I hate about proprietary software, they keep allowing other people to try to decide what I do with my computer.)
- Ship both, but hide the x86_64 launcher from users.
I think even that isn't a great solution.
Kevin Kofler
tor, 07 09 2006 kl. 05:04 +0000, skrev Kevin Kofler:
Warren Togami <wtogami <at> redhat.com> writes:
- Ship only i386, as that is the only useful arch.
The "only useful arch"? Can we please quit assuming everyone needs Flash? I don't even have Flash (or any other proprietary plugin for that matter) installed on this i386 Fedora (I don't have a 64-bit CPU or I'd use x86_64), I don't miss it. Down with Flash ads! Especially those which disable the option to stop the animation or script around it. (That's what I hate about proprietary software, they keep allowing other people to try to decide what I do with my computer.)
Agreed, I happen not to define usefulness in softwares ability to apease proprietary vendors.
- Ship both, but hide the x86_64 launcher from users.
I think even that isn't a great solution.
Instead of this exceedingly stupid solution we could actively push gcjwebplugin, gnash and totem-plugin all of which conform to our freedom standards while providing the services our users need. No need to give up functionality for freedom when we can have both.
- David
On Thursday 07 September 2006 09:18, David Nielsen wrote:
Instead of this exceedingly stupid solution we could actively push gcjwebplugin, gnash and totem-plugin all of which conform to our freedom standards while providing the services our users need. No need to give up functionality for freedom when we can have both.
Unfortunately, gcjwebplugin was pulled from the distro due to security flaws that we will not have time to resolve by the final release. :/
On Thu, Sep 07, 2006 at 09:21:03AM -0400, Jesse Keating wrote:
On Thursday 07 September 2006 09:18, David Nielsen wrote:
Instead of this exceedingly stupid solution we could actively push gcjwebplugin, gnash and totem-plugin all of which conform to our freedom standards while providing the services our users need. No need to give up functionality for freedom when we can have both.
Unfortunately, gcjwebplugin was pulled from the distro due to security flaws that we will not have time to resolve by the final release. :/
AFAIK it weren't known security flaws, but unfinished security audit.
Jakub
tor, 07 09 2006 kl. 09:21 -0400, skrev Jesse Keating:
On Thursday 07 September 2006 09:18, David Nielsen wrote:
Instead of this exceedingly stupid solution we could actively push gcjwebplugin, gnash and totem-plugin all of which conform to our freedom standards while providing the services our users need. No need to give up functionality for freedom when we can have both.
Unfortunately, gcjwebplugin was pulled from the distro due to security flaws that we will not have time to resolve by the final release. :/
I arrogantly assumed, as FC6 is pretty much set in stone, that we were looking forward towards FC7 and beyond.
- David
Well, not quite:
"/usr/lib[64]/gcj-4.1.1/libgcjwebplugin.so"
ist still around. What actually has been removed is the (empty) dummy package "java-1.4.2-gcj-compat-plugin" which created a symbolic link to "/usr/lib/mozilla/plugins". You are still free to create the symlink by hand or an equivalent one to "$HOME/.mozilla/plugins" ..
Unfortunately, gcjwebplugin was pulled from the distro due to security flaws that we will not have time to resolve by the final release. :/
-- Jesse Keating Release Engineer: Fedora
On Thursday 07 September 2006 10:18, Joachim Frieben wrote:
Well, not quite:
"/usr/lib[64]/gcj-4.1.1/libgcjwebplugin.so"
ist still around. What actually has been removed is the (empty) dummy package "java-1.4.2-gcj-compat-plugin" which created a symbolic link to "/usr/lib/mozilla/plugins". You are still free to create the symlink by hand or an equivalent one to "$HOME/.mozilla/plugins" ..
This so file is supposed to be removed as well. We don't have the capacity to keep up with the security fixes needed (so I'm told) so we can't just leave the .so file there, we have to not package it at all.
Hi,
Jesse Keating wrote:
On Thursday 07 September 2006 10:18, Joachim Frieben wrote:
Well, not quite:
"/usr/lib[64]/gcj-4.1.1/libgcjwebplugin.so"
ist still around. What actually has been removed is the (empty) dummy package "java-1.4.2-gcj-compat-plugin" which created a symbolic link to "/usr/lib/mozilla/plugins". You are still free to create the symlink by hand or an equivalent one to "$HOME/.mozilla/plugins" ..
This so file is supposed to be removed as well. We don't have the capacity to keep up with the security fixes needed (so I'm told)
No, that's not the issue. The issue is that we're actively developing GNU Classpath's security infrastructure, but we're not ready to declare it secure yet.
so we can't just leave the .so file there, we have to not package it at all.
I would like to leave the .so file so that adventurous users can install the symlink by hand.
Tom
It would be really, really naughty to do so ... No, seriously: it won't be used at all unless a user has actually tracked it down (!) and deliberately decides to use it at his own risk. I for myself am pleased that I can use it for the 2-3 "Java" applets that I actually need.
This so file is supposed to be removed as well. We don't have the capacity to keep up with the security fixes needed (so I'm told) so we can't just leave the .so file there, we have to not package it at all.
-- Jesse Keating Release Engineer: Fedora
On Thursday 07 September 2006 13:31, Joachim Frieben wrote:
It would be really, really naughty to do so ... No, seriously: it won't be used at all unless a user has actually tracked it down (!) and deliberately decides to use it at his own risk. I for myself am pleased that I can use it for the 2-3 "Java" applets that I actually need.
It will stay. Those responsible for the security of it feel comfortable with the situation.
On 9/7/06, David Nielsen david@lovesunix.net wrote:
Instead of this exceedingly stupid solution we could actively push gcjwebplugin, gnash and totem-plugin all of which conform to our freedom standards while providing the services our users need. No need to give up functionality for freedom when we can have both.
We'll have to wait for FC13 or so (2010) before gnash has legal mp3 support though :(.
n0dalus.
On Thu, Sep 07, 2006 at 11:09:07PM +0930, n0dalus wrote:
On 9/7/06, David Nielsen david@lovesunix.net wrote:
Instead of this exceedingly stupid solution we could actively push gcjwebplugin, gnash and totem-plugin all of which conform to our freedom standards while providing the services our users need. No need to give up functionality for freedom when we can have both.
We'll have to wait for FC13 or so (2010) before gnash has legal mp3 support though :(.
Gnash sound support will certainly be through gstreamer, so it is not related with gnash per se, but with mp3. And if there is a legal gstreamer mp3 backend in the mean time I guess gnash will be able to take advantage of it.
-- Pat
Patrice Dumas (pertusus@free.fr) said:
We'll have to wait for FC13 or so (2010) before gnash has legal mp3 support though :(.
Gnash sound support will certainly be through gstreamer, so it is not related with gnash per se, but with mp3. And if there is a legal gstreamer mp3 backend in the mean time I guess gnash will be able to take advantage of it.
The fluendo plugins may be of help here....
Bill
On Thu, Sep 07, 2006 at 03:18:31PM +0200, David Nielsen wrote:
tor, 07 09 2006 kl. 05:04 +0000, skrev Kevin Kofler:
Warren Togami <wtogami <at> redhat.com> writes:
Instead of this exceedingly stupid solution we could actively push gcjwebplugin, gnash and totem-plugin all of which conform to our freedom standards while providing the services our users need. No need to give up functionality for freedom when we can have both.
Gnash is a very fast moving and promising project, but honestly it doesn't replace the proprietary flash by now. Especially gnash currently shipped in fedora which crashes on almost all flash animations. CVS gnash has allready made good progress, but in my opinion gnash is still unusable for anything else than testing.
-- Pat
tor, 07 09 2006 kl. 15:52 +0200, skrev Patrice Dumas:
On Thu, Sep 07, 2006 at 03:18:31PM +0200, David Nielsen wrote:
tor, 07 09 2006 kl. 05:04 +0000, skrev Kevin Kofler:
Warren Togami <wtogami <at> redhat.com> writes:
Instead of this exceedingly stupid solution we could actively push gcjwebplugin, gnash and totem-plugin all of which conform to our freedom standards while providing the services our users need. No need to give up functionality for freedom when we can have both.
Gnash is a very fast moving and promising project, but honestly it doesn't replace the proprietary flash by now. Especially gnash currently shipped in fedora which crashes on almost all flash animations. CVS gnash has allready made good progress, but in my opinion gnash is still unusable for anything else than testing.
Gnash cvs is very promising and very actively developed. There's also libfad which aims to provide full flash backend using cairo which should be blazing fast. I wouldn't take this defeatist stance towards free software, we've come very far in a short time with these technologies.
As for codec support we have GStreamer which supports pretty much any format under the sun and gnash can take advantage of it.
- David
On Thu, Sep 07, 2006 at 04:16:03PM +0200, David Nielsen wrote:
tor, 07 09 2006 kl. 15:52 +0200, skrev Patrice Dumas:
Gnash cvs is very promising and very actively developed. There's also libfad which aims to provide full flash backend using cairo which should be blazing fast. I wouldn't take this defeatist stance towards free software, we've come very far in a short time with these technologies.
I don't know about libfad, but gnash is based on GameSWF so it isn't such a short time if it is taken into account. I maintain gnash in fedora, I follow and contribute to upstream, and I truely believe that in some time it will be a perfect player, but right now it is not usable for the common web surfing cases. It is not defeatism, but realism.
Anyway I think that free software will always be late when there is a need to implement closed formats, since there is a need to reverse engineer the format. When it isn't patented, in case it is even forbidden to deal with those formats outside of the free world. As long as proprietary formats are used, proprietary apps will certainly be better than free apps for some time.
-- Pat
Warren Togami wrote:
Even if we decide to keep the i386 firefox (and I think we should), we still have the messy issue of dealing with two launchers.
I think most users will solve it by `yum remove firefox.x86_64`. That's what I'll do until gcj, gnash, et al. catch up.
Possible solutions... none of which are ideal.
- Ship only i386, as that is the only useful arch.
This gets my vote. And I agree with your usefulness opinion. I've never (knowingly) needed a 64-bit browser[*].
Prior to reviving this thread last night, I used firefox.x86_64 with gnash-plugin just to see how it'd work. The site I use to determine whether/how flash is working is http://kawasaki.com/product_home.asp . To my dismay, gnash never left the starting blocks, remaining stuck at "loading menu" or similar. I'd file a BZ, but all it'd do is point the developer to yet another web site that doesn't work. If that's the recommended tack, it won't be long before hundreds of similar BZs accumulate.
Jay
[*] It probably wouldn't be much of a stretch to say I've never needed a 64-bit anything, but I've got a 64-bit cpu, so I'm going to run x86_64 as a matter of principle. I suspect many users feel the same. (Although 64-bit was probably faster than i386 would've been when I converted all those VHS-C home movies to DVD.)
On Thu, 2006-09-07 at 09:14 -0500, Jay Cliburn wrote:
This gets my vote. And I agree with your usefulness opinion. I've never (knowingly) needed a 64-bit browser[*].
Running an i386 app under compatibility, especially one with a large library stack like Firefox, adds noticeable startup lag and memory bloat, as an entirely separate i386 version of all the libraries has to be loaded.
Le samedi 09 septembre 2006 à 16:35 -0500, Callum Lerwick a écrit :
On Thu, 2006-09-07 at 09:14 -0500, Jay Cliburn wrote:
This gets my vote. And I agree with your usefulness opinion. I've never (knowingly) needed a 64-bit browser[*].
Running an i386 app under compatibility, especially one with a large library stack like Firefox, adds noticeable startup lag and memory bloat, as an entirely separate i386 version of all the libraries has to be loaded.
My personal preference would be to install both versions under x86_64, with the 64bit version the default one, and a plugin like the 'open page in ie' windows users use to access the 32 bit version.
That is, until major plugins like flahs are available for 32 bit.
On Wed, 2006-09-06 at 22:43 -0400, Warren Togami wrote:
- Two browser launchers?
- How is xremote supposed to work? You can currently only run one arch
of the browser at a time.
- It is possible to run both archs with minor changes to the xremote
code, but this makes things even more confusing to the user.
Possible solutions... none of which are ideal.
- Ship only i386, as that is the only useful arch.
- Ship both, but hide the x86_64 launcher from users.
As long as we're brainstorming: - Ship only the x86_64 launcher. Use mozembed to embed the i386-firefox with the flash plugin to handle flash movies.
-Toshio
On Mon, 2006-07-31 at 11:11 -0400, Matthew Miller wrote:
On Mon, Jul 31, 2006 at 11:04:16AM -0400, Demond wrote:
Is there a reason the firefox.i386 and firefox-devel.i386 packages are in the x86_64 repo for rawhide? They both got pulled into my system when the firefox-devel package was introduced. However, "yum remove firefox.i386" shows that there are no dependencies. I was just wondering if this was deliberate and if they will be around for a while.
It's handy if you have to use the flash plugin....
it also breaks yum though...
(at least it did for me last week)
try installing yum install mozilla-devel
and watch things go bang
On Tuesday 01 August 2006 10:36, Arjan van de Ven wrote:
it also breaks yum though...
(at least it did for me last week)
try installing yum install mozilla-devel
Mozilla should no longer be in the repos. It has been blocked for rawhide / FC6.
On Monday 31 July 2006 11:04, Demond wrote:
Is there a reason the firefox.i386 and firefox-devel.i386 packages are in the x86_64 repo for rawhide? They both got pulled into my system when the firefox-devel package was introduced. However, "yum remove firefox.i386" shows that there are no dependencies. I was just wondering if this was deliberate and if they will be around for a while.
Every package that has a -devel subpackage is considered multilib, thus it is made available and all its deps are made available in multilib platforms. There are very few exceptions, such as the kernel, to this rule.
-
Andrew Haley -
Arjan van de Ven -
Bill Nottingham -
Callum Lerwick -
Caolán McNamara -
David Nielsen -
David Woodhouse -
Demond -
Dominik 'Rathann' Mierzejewski -
Jakub Jelinek -
Jay Cliburn -
Jef Spaleta -
Jesse Keating -
Joachim Frieben -
Kevin Kofler -
Matt Domsch -
Matthew Miller -
Michael J. Knox -
Mike A. Harris -
n0dalus -
Nicolas Mailhot -
Patrice Dumas -
Rahul Sundaram -
Thomas Fitzsimmons -
Toshio Kuratomi -
Warren Togami