openoffice really needs to lose some weight!
I think openoffice.org-i18n needs to be broken up or a script included to remove unwanted languages.
On Fri, January 28, 2005 12:01 pm, Joshua Andrews said:
openoffice really needs to lose some weight!
I think openoffice.org-i18n needs to be broken up or a script included to remove unwanted languages.
Already planned. Someone more informed may answer, but I think FC4 is the target for delivering openoffice as you suggest.
Sean
On Fri, 2005-01-28 at 12:02 -0500, Sean wrote:
On Fri, January 28, 2005 12:01 pm, Joshua Andrews said:
openoffice really needs to lose some weight!
I think openoffice.org-i18n needs to be broken up or a script included to remove unwanted languages.
Already planned. Someone more informed may answer, but I think FC4 is the target for delivering openoffice as you suggest.
100% Correct.
Dan
On Fri, 2005-01-28 at 12:10 -0500, Dan Williams wrote:
On Fri, 2005-01-28 at 12:02 -0500, Sean wrote:
On Fri, January 28, 2005 12:01 pm, Joshua Andrews said:
openoffice really needs to lose some weight!
I think openoffice.org-i18n needs to be broken up or a script included to remove unwanted languages.
Already planned. Someone more informed may answer, but I think FC4 is the target for delivering openoffice as you suggest.
100% Correct.
But are you planning to just remove the unwanted languages, or are you intending to separate the languages out into different RPMs.
I'd prefer the second to the first. Updating OOo (which has happened a number of times over FC2 and FC3 is a PITA given the size of the files and having to download the entire language set for one or two languages doesn't really seem like a huge step forward.
Rodd
On Fri, 2005-01-28 at 09:01 -0800, Joshua Andrews wrote:
openoffice really needs to lose some weight!
I think openoffice.org-i18n needs to be broken up or a script included to remove unwanted languages.
The language-specific files in the i18n RPM _are_ tagged with their respective language (using %lang specfile directive) so you can theoretically set some RPM macro and only install what you really want.
Dan
Hi,
I think openoffice.org-i18n needs to be broken up or a script included to remove unwanted languages.
The language-specific files in the i18n RPM _are_ tagged with their respective language (using %lang specfile directive) so you can theoretically set some RPM macro and only install what you really want.
Which is nice.
Any chance of OOo 2 (beta) being brought into testing. It really is fantastic!
TTFN
Paul
On Fri, 2005-01-28 at 18:40 +0000, Paul wrote:
Hi,
I think openoffice.org-i18n needs to be broken up or a script included to remove unwanted languages.
The language-specific files in the i18n RPM _are_ tagged with their respective language (using %lang specfile directive) so you can theoretically set some RPM macro and only install what you really want.
Which is nice.
Any chance of OOo 2 (beta) being brought into testing. It really is fantastic!
More than likely, but remember that the OOo 2.0 ship date is currently "April/May", and the freeze for FC4 is May 2nd at this time. Red Hat has been burned in the past by shipping non-final software with a release (even though it had been worked on/tested for a while beforehand), so its unlikely that a non-final OOo 2.0 would make it into FC4. We'll have to see. IF 2.0 were pushed to Rawhide, and IF 2.0 didn't make final before the freeze for FC4, then it would probably get pulled before FC4 went live and the package reverted to 1.1.4. Its all kind of "wait and see" at this point.
Dan
On Fri, 28 Jan 2005, Dan Williams wrote:
FC4. We'll have to see. IF 2.0 were pushed to Rawhide, and IF 2.0 didn't make final before the freeze for FC4, then it would probably get pulled before FC4 went live and the package reverted to 1.1.4. Its all kind of "wait and see" at this point.
Why not make both available? After all, fedora includes both gcc3.x and gcc4, although gcc4 definitely has issues.
-Dan
On Fri, 28 Jan 2005 11:32:25 -0800 (PST), Dan Hollis goemon@anime.net wrote:
Why not make both available? After all, fedora includes both gcc3.x and gcc4, although gcc4 definitely has issues.
how big are the gcc3.x and gcc4.x package sets? how big are the openoffice.org packages? Considering the size of openoffice I think it would be irresponsible to choose to ship multiple versions of it in Core considering the need to be respectful of overall bloat.
There is also a question of confusing the target audience. Requiring the target audience of a compiler to know the difference between gcc3 and gcc4 is a small burden.
Requiring the target audience of oo.org or other end-user application to understand the difference between the 2 versions of the same application being offered in Core would in my estimation be a much larger burden on the target group and cause significant confusion.
I don't think its really worth providing multiple versions of the same 'large' end-user application at all. Either oo.org 2.0 ships with fc4 or it doesn't.. it will clearly be in fc5. In the meantime the maintainer should make the appropriate choice and pick one version of the application to ship in fc4 based on the experience with the codebase and the expected maintainership burden for fc4 updates. Damned if you do... damned if you don't.
-jef
On Fri, 2005-01-28 at 14:53 -0500, Jeff Spaleta wrote:
On Fri, 28 Jan 2005 11:32:25 -0800 (PST), Dan Hollis goemon@anime.net wrote:
Why not make both available? After all, fedora includes both gcc3.x and gcc4, although gcc4 definitely has issues.
how big are the gcc3.x and gcc4.x package sets? how big are the openoffice.org packages? Considering the size of openoffice I think it would be irresponsible to choose to ship multiple versions of it in Core considering the need to be respectful of overall bloat.
There is also a question of confusing the target audience. Requiring the target audience of a compiler to know the difference between gcc3 and gcc4 is a small burden.
Requiring the target audience of oo.org or other end-user application to understand the difference between the 2 versions of the same application being offered in Core would in my estimation be a much larger burden on the target group and cause significant confusion.
I don't think its really worth providing multiple versions of the same 'large' end-user application at all. Either oo.org 2.0 ships with fc4 or it doesn't.. it will clearly be in fc5. In the meantime the maintainer should make the appropriate choice and pick one version of the application to ship in fc4 based on the experience with the codebase and the expected maintainership burden for fc4 updates. Damned if you do... damned if you don't.
Since the current timelines are such that there may be a minimal amount of time between the release of FC4 final and OO.org 2.0 final, would it be reasonable to consider making OO.org 2.0 available as an update to FC4 when ready?
Or is that such a significant update, that it would be against FC philosophy to include it as an update and only make it available with a new FC release?
I am just raising the possibility that with roughly 6 months between FC releases, it means that folks would need to wait almost until the end of the year to take advantage of significant new functionality in OO.org.
I agree though, that both version should not be included. It's just way too big.
Marc
On Fri, 28 Jan 2005, Jeff Spaleta wrote:
On Fri, 28 Jan 2005 11:32:25 -0800 (PST), Dan Hollis goemon@anime.net wrote:
Why not make both available? After all, fedora includes both gcc3.x and gcc4, although gcc4 definitely has issues.
how big are the gcc3.x and gcc4.x package sets? how big are the openoffice.org packages? Considering the size of openoffice I think it would be irresponsible to choose to ship multiple versions of it in Core considering the need to be respectful of overall bloat.
any reason it can't be made available on extras?
if not, then the question would be -- does it get released later as a yum update to completely replace openoffice1, or does it wait till FC5?
-Dan
On Fri, 2005-01-28 at 12:11 -0800, Dan Hollis wrote:
On Fri, 28 Jan 2005, Jeff Spaleta wrote:
On Fri, 28 Jan 2005 11:32:25 -0800 (PST), Dan Hollis goemon@anime.net wrote:
Why not make both available? After all, fedora includes both gcc3.x and gcc4, although gcc4 definitely has issues.
how big are the gcc3.x and gcc4.x package sets? how big are the openoffice.org packages? Considering the size of openoffice I think it would be irresponsible to choose to ship multiple versions of it in Core considering the need to be respectful of overall bloat.
any reason it can't be made available on extras?
if not, then the question would be -- does it get released later as a yum update to completely replace openoffice1, or does it wait till FC5?
b/c it is not an extra.
it would be an alternative.
-sv
On Sat, 29 Jan 2005, Alexandre Strube wrote:
Em Sex, 2005-01-28 às 12:11 -0800, Dan Hollis escreveu:
any reason it can't be made available on extras?
no, please not double versions - openoffice 2 is already being shipped as rpm openoffice guys. why don't way for a final release?
So it's either do a major upgrade (oo1.1.2 -> 2.0) in the middle of FC4, or put it off till FC5...
Or delay FC4 till oo2.0 is released...
Did I miss one?
-Dan
On Sat, Jan 29, 2005 at 03:44:32AM -0800, Dan Hollis wrote:
So it's either do a major upgrade (oo1.1.2 -> 2.0) in the middle of FC4, or put it off till FC5... Or delay FC4 till oo2.0 is released... Did I miss one?
How about openoffice.org-1.1.2 and openoffice.org2-2.0, both in FC4? :)
On Sat, 2005-01-29 at 10:52 -0500, Matthew Miller wrote:
On Sat, Jan 29, 2005 at 03:44:32AM -0800, Dan Hollis wrote:
So it's either do a major upgrade (oo1.1.2 -> 2.0) in the middle of FC4, or put it off till FC5... Or delay FC4 till oo2.0 is released... Did I miss one?
How about openoffice.org-1.1.2 and openoffice.org2-2.0, both in FC4? :)
that one sucks; you need to parallel install (or "everything" installs go wonky) and that is not an easy thing for big packages like OOo. Far better to spend the time that would take on getting 2.0 out faster ;)
On Sat, Jan 29, 2005 at 05:08:21PM +0100, Arjan van de Ven wrote:
How about openoffice.org-1.1.2 and openoffice.org2-2.0, both in FC4? :)
that one sucks; you need to parallel install (or "everything" installs go wonky) and that is not an easy thing for big packages like OOo. Far better to spend the time that would take on getting 2.0 out faster ;)
Yeah, just bringing it up for completeness. :)
On Sat, 2005-01-29 at 10:52 -0500, Matthew Miller wrote:
On Sat, Jan 29, 2005 at 03:44:32AM -0800, Dan Hollis wrote:
So it's either do a major upgrade (oo1.1.2 -> 2.0) in the middle of FC4, or put it off till FC5... Or delay FC4 till oo2.0 is released... Did I miss one?
How about openoffice.org-1.1.2 and openoffice.org2-2.0, both in FC4? :)
We have a goal of trying to keep fc4 UNDER 5 CDS and limited to 1 DVD.
having both is gonna suck.
-sv
On Sat, 2005-01-29 at 03:44 -0800, Dan Hollis wrote:
Or delay FC4 till oo2.0 is released...
OO2 is hugely important to some subset of the Fedora-using population, the type involved in office or admin work rather than devel or code. If the time difference is not too large (in my eyes, anything over 30 days) I would definitely suggest that we delay FC4 to wait for OO2.
Alternately, we could include the OO2-beta9999 last-one-before-final and then update to the final 2.0 when available. But please, please, please let's have OO2 in FC4. The office users of FC4 everywhere will bless you!
Cheers,
Alexandre Strube wrote:
Em Sex, 2005-01-28 às 12:11 -0800, Dan Hollis escreveu:
any reason it can't be made available on extras?
no, please not double versions - openoffice 2 is already being shipped as rpm openoffice guys. why don't way for a final release?
I read briefly that openoffice 2 comes with base, I believe. Has anyone tried out this feature? Is this a usable, uncomplicated database or is it pretty intensive to setup.
I'm more for shipping any version of openoffice that can enhance the usability. I also thing that Fedora would do well including a worthy database with an easy to use frontend.
I take it that Openoffice rpms are available from the openoffice.org site. If from some other sire, where are the rpms available?
Jim
Hi,
I read briefly that openoffice 2 comes with base, I believe. Has anyone tried out this feature? Is this a usable, uncomplicated database or is it pretty intensive to setup.
It's pretty easy to set up and use.
I take it that Openoffice rpms are available from the openoffice.org site. If from some other sire, where are the rpms available?
The RPMs on the OOo website are for SuSE and Redhat. They work fine under rawhide.
TTFN
Paul
Paul wrote:
Hi,
I read briefly that openoffice 2 comes with base, I believe. Has anyone tried out this feature? Is this a usable, uncomplicated database or is it pretty intensive to setup.
It's pretty easy to set up and use.
I take it that Openoffice rpms are available from the openoffice.org site. If from some other sire, where are the rpms available?
The RPMs on the OOo website are for SuSE and Redhat. They work fine under rawhide.
TTFN
Paul
The packages work pretty much on FC3. I did get surprised by Base, which is my interest primarily in OO v2.
I get this error:
OpenOffice.org requires a Java Runtime Environment (JRE). Please install a JRE and restart OpenOffice.org
Anyway, I never installed JRE before. If Base will be included with OO2 in Fedora, if it arrives. Would provisions be made for overcoming this requirement, or is Base probably out of the picture?
Jim
Hi,
I get this error:
OpenOffice.org requires a Java Runtime Environment (JRE). Please install a JRE and restart OpenOffice.org
Anyway, I never installed JRE before. If Base will be included with OO2 in Fedora, if it arrives. Would provisions be made for overcoming this requirement, or is Base probably out of the picture?
I remember reading one of the RH chaps had been converting it over to use gcj rather than JRE and some bits weren't playing ball. As soon as it is working with gcj it will be happy.
TTFN
Paul
Paul wrote:
Hi,
I get this error:
OpenOffice.org requires a Java Runtime Environment (JRE). Please install a JRE and restart OpenOffice.org
Anyway, I never installed JRE before. If Base will be included with OO2 in Fedora, if it arrives. Would provisions be made for overcoming this requirement, or is Base probably out of the picture?
I remember reading one of the RH chaps had been converting it over to use gcj rather than JRE and some bits weren't playing ball. As soon as it is working with gcj it will be happy.
TTFN
Paul
Are there any test packages from fedora that might somewhat work (at least load enough to test out the program?
Anyway, good luck to the developer trying to overcome the JRE limitations.
Commenting on OO 2 in general, this should be the goal, final release or not. I like the seperate rpms for different components, rather than one huge openoffice.org rpm. I have no idea as to which rpm contains base though. :-)
Jim
openofficeorg-calc-1.9.74-1.i586.rpm openofficeorg-core-1.9.74-1.i586.rpm openofficeorg-draw-1.9.74-1.i586.rpm openofficeorg-gnome-integration-1.9.74-1.i586.rpm openofficeorg-graphicfilter-1.9.74-1.i586.rpm openofficeorg-impress-1.9.74-1.i586.rpm openofficeorg-javafilter-1.9.74-1.i586.rpm openofficeorg-math-1.9.74-1.i586.rpm openofficeorg-redhat-menus-1.9.74-1.noarch.rpm openofficeorg-spellcheck-1.9.74-1.i586.rpm openofficeorg-testtool-1.9.74-1.i586.rpm openofficeorg-writer-1.9.74-1.i586.rpm openofficeorg-xsltfilter-1.9.74-1.i586.rpm
On Sun, 2005-01-30 at 22:48 -0500, Jim Cornette wrote:
I have no idea as to which rpm contains base though.
I've only installed the following and I've got base installed.
openofficeorg-redhat-menus-1.9.71.1-1 openofficeorg-core-1.9.71.1-1 openofficeorg-xsltfilter-1.9.71.1-1 openofficeorg-writer-1.9.71.1-1 openofficeorg-graphicfilter-1.9.71.1-1
I'd be confident that it's not -redhat-menus, -xsltfiter or - graphicfilter, so that only leaves -writer and -core. A quick look through -writer (using less) doesn't show anything database looking, so I quess it's still part of -core.
Rodd
On Sun, 2005-01-30 at 10:40 +0000, Paul wrote:
Anyway, I never installed JRE before. If Base will be included with
OO2
in Fedora, if it arrives. Would provisions be made for overcoming
this
requirement, or is Base probably out of the picture?
Base uses hsqldb, an embedded Java-based database engine. It requires some form of a JRE on your system
I remember reading one of the RH chaps had been converting it over to use gcj rather than JRE and some bits weren't playing ball. As soon as it is working with gcj it will be happy.
That was to get it to build, not to run IMHO
Colin Charles wrote:
On Sun, 2005-01-30 at 10:40 +0000, Paul wrote:
Anyway, I never installed JRE before. If Base will be included with
OO2
in Fedora, if it arrives. Would provisions be made for overcoming
this
requirement, or is Base probably out of the picture?
Base uses hsqldb, an embedded Java-based database engine. It requires some form of a JRE on your system
I hope this hurdle regarding some form of a database engine for the linux system is worked out. If needing JRE in some form is required, I am not against that requirement. To get a usable, easy to configure and manage simple database for Linux is the real goal. An acceptable alternative for the wintel world would also help with cross-platform development and usage.
I remember reading one of the RH chaps had been converting it over to use gcj rather than JRE and some bits weren't playing ball. As soon as it is working with gcj it will be happy.
That was to get it to build, not to run IMHO
After trying to get base to do anything substantial with either a build on the wintel platform or on the linux platform, I figure that there is really a lot of development needed to get this program running in an acceptable way. I'd love to see it working to an acceptable level. I have simple file databases originally created in 1997 with msaccess 2.0 (now at 2000) that I'd like to move away from msaccess and get working with base.
Base on wintel does get to where you can create forms, but intermingles the form within every application on your desktop.
With the linux (fc test) version, I was only able to successfully create tables and to open dbase tables that were exported from access.mdb tables into dbase tables. The form wizards did not and working with adding items to new forms was pretty much a "what toolbar or menu choice lets me add an item to a form, relate the form to a record source or whatever."
It is great for some database frontend functionality is being added to the program. I would like to see it included or some other simple database into core or extras, if not this time, FC5.
Jim
On Sun, 2005-01-30 at 13:13 +0100, Kyrre Ness Sjobak wrote:
any reason it can't be made available on extras?
Agreed. Release it to extras if it can't make core. Call it openoffice.org.2-version or something, and make sure it conflicts openoffice.org (to make sure paralell installs are possible).
Um, why do you want them to conflict if you also want them to be parallel installable? Those two things sound mutually exclusive to me. Aside from that, I think it's already been discussed in this thread that making two versions of a package as huge and complex as OOo parallel installable is more effort than its worth. Better to pick one of 1) ship an almost-final beta and issue an update to 2.0 when it's released, 2) ship 1.1.x and resign ourselves to that being the version eternally paired with FC4, 3) delay the release of FC4 in the hopes that OOo 2.0 will be shipped so as to not cause a significant delay. Personally, I'm somewhat partial to delay FC4, but only if the delay is, as some one else has suggested, less than 30 days.
On Mon, 2005-01-31 at 15:52 -0500, Paul Iadonisi wrote:
Better to pick one of 1) ship an almost-final beta and issue an update to 2.0 when it's released, 2) ship 1.1.x and resign ourselves to that being the version eternally paired with FC4, 3) delay the release of FC4 in the hopes that OOo 2.0 will be shipped so as to not cause a significant delay. Personally, I'm somewhat partial to delay FC4, but only if the delay is, as some one else has suggested, less than 30 days.
I know I've already said this (in fact, I was the one who suggested <30 days as a good decision point for delaying FC4), but:
1. If <30 days, delay FC4. 2. If not, then ship the almost-final beta with FC4 and update to final when it's ready.
Please...
Cheers,
tir, 01.02.2005 kl. 17.52 skrev Rodolfo J. Paiz:
On Mon, 2005-01-31 at 15:52 -0500, Paul Iadonisi wrote:
Better to pick one of 1) ship an almost-final beta and issue an update to 2.0 when it's released, 2) ship 1.1.x and resign ourselves to that being the version eternally paired with FC4, 3) delay the release of FC4 in the hopes that OOo 2.0 will be shipped so as to not cause a significant delay. Personally, I'm somewhat partial to delay FC4, but only if the delay is, as some one else has suggested, less than 30 days.
I know I've already said this (in fact, I was the one who suggested <30 days as a good decision point for delaying FC4), but:
- If <30 days, delay FC4.
- If not, then ship the almost-final beta with FC4 and update to
final when it's ready.
Please...
Or provide "openoffice2.org-2.0.i386.rpm" that conflicts openoffice.org in extras?
On Thu, 03 Feb 2005 17:24:36 +0100, Kyrre Ness Sjobak kyrre@solution-forge.net wrote:
Or provide "openoffice2.org-2.0.i386.rpm" that conflicts openoffice.org in extras?
sorry... under the current definition of extras as a continuation of Core.. thats probably not an acceptible proposal.
-jef
On Jan 28, 2005, Dan Williams dcbw@redhat.com wrote:
IF 2.0 were pushed to Rawhide, and IF 2.0 didn't make final before the freeze for FC4, then it would probably get pulled before FC4 went live and the package reverted to 1.1.4.
Wouldn't it be better to have it in rawhide, ship whatever nearly-there 2.0ish release at the freeze date, with an update to be released as soon as it goes final? Upgrading form 1.1.4 to 2.0 within a release might be a bit too much...
On Fri, 2005-01-28 at 18:10 -0200, Alexandre Oliva wrote:
IF 2.0 were pushed to Rawhide, and IF 2.0 didn't make final before the freeze for FC4, then it would probably get pulled before FC4 went live and the package reverted to 1.1.4.
Wouldn't it be better to have it in rawhide, ship whatever nearly-there 2.0ish release at the freeze date, with an update to be released as soon as it goes final? Upgrading form 1.1.4 to 2.0 within a release might be a bit too much...
I like this option. As someone who installs the beta of OOo-2.x I would much prefer to see OOo-2.x in FC4 (because it's better) than OOo.1-x.
As I see it, given that FC is a download only distro, I'm all for the occasional inclusion of pre-release software. If you want totally solid, you shouldn't be using FC (IMHO).
Rodd
On Sun, 30 Jan 2005 22:15:16 +1100, Rodd Clarkson rodd@clarkson.id.au wrote:
As I see it, given that FC is a download only distro,
??????
several 3rd party vendors SELL mediasets for FC... http://fedora.redhat.com/download/vendors.html
-jef
Rodd Clarkson wrote:
As I see it, given that FC is a download only distro, I'm all for the occasional inclusion of pre-release software. If you want totally solid, you shouldn't be using FC (IMHO).
"Totally solid" is somewhat subjective.... In general, I disagree with shipping software with FC if the software has *known* problems.
I think a lot of people use FC as an alternative to MS products *because* FC is pretty reliable for non-critical work. If you really want/need better stability, use one of pay-for-it distributions (RHEE etc).
Channels are already in place to distribute bleeding-edge versions of software (rawhide?), but that should not be the *default*.
Personally, I like the *leading-edge* of FC with frequent package updates, and a short release cycle... maybe as my skills improve etc, I'll start getting updates from rawhide and playing more dangerously... but don't start imposing those higher risks on FC in general. Let people decide to increase risk on their own.
Bottom line: there's already a working process for distributing pre-release software to the FC community, that's rawhide. Don't start distributing pre-release software with the final-release iso images.
Don Russell
On Sun, 2005-01-30 at 11:03 -0800, Don Russell wrote:
Rodd Clarkson wrote:
As I see it, given that FC is a download only distro, I'm all for the occasional inclusion of pre-release software. If you want totally solid, you shouldn't be using FC (IMHO).
"Totally solid" is somewhat subjective.... In general, I disagree with shipping software with FC if the software has *known* problems.
<snip>
Bottom line: there's already a working process for distributing pre-release software to the FC community, that's rawhide. Don't start distributing pre-release software with the final-release iso images.
So firefox-0.10.1-1.0PR1.20 shouldn't have been included with FC3? What about thunderbird-0.8.0-9?
I'm not saying that FC should be just including ANY pre-release software, but it has include some well tested pre-release software and I for one applaud the inclusion of firefox and thunderbird in FC3 (instead of having to wait for FC4).
Why can't OOo-2.x pre-release be included (given significant testing) and then updated to 2.0 final after FC4 is released. It's not like this hasn't been done before.
Rodd
Rodd Clarkson wrote:
So firefox-0.10.1-1.0PR1.20 shouldn't have been included with FC3? What about thunderbird-0.8.0-9?
I guess it depends on what we mean by "pre-release"... Is anything 0.x "pre-release"? From what I've read here OOo-2.x pre-release isn't quite ready for the masses. Personally, I'd rather have a less feature-rich but stable product, than a feature-rich product that crashes, hangs or whatever else inconveniences me.
I'm not saying that FC should be just including ANY pre-release software, but it has include some well tested pre-release software and I for one applaud the inclusion of firefox and thunderbird in FC3 (instead of having to wait for FC4).
I agree with that... I use FireFox and Thunderbird... and even bugzilla'd one or two things... Thunderbird 1.0 has some annoyances... but nothing I've found that's caused me any real grief. :-)
Why can't OOo-2.x pre-release be included (given significant testing) and then updated to 2.0 final after FC4 is released. It's not like this hasn't been done before.
I'd have to ask what "significant testing" means.... :-)
Given the short release cycle of FC, I don't see the problem of deferring a program package to the next release, or making it available via up2date. If people really need to run code that close to the bleeding edge, they're free to do so via rawhide.
Is it really a matter of choosing between FC4 and FC5? If omitted from FC4, why can't it made available via up2date at some time prior to FC5?
(up2date is one of pet peeves but it is A LOT better than it used to be)
Don
On Sun, 2005-01-30 at 20:24 -0800, Don Russell wrote:
Rodd Clarkson wrote:
So firefox-0.10.1-1.0PR1.20 shouldn't have been included with FC3? What about thunderbird-0.8.0-9?
I guess it depends on what we mean by "pre-release"... Is anything 0.x "pre-release"? From what I've read here OOo-2.x pre-release isn't quite ready for the masses. Personally, I'd rather have a less feature-rich but stable product, than a feature-rich product that crashes, hangs or whatever else inconveniences me.
That PR in the firefox file name means pre-release.
While OOo-2.x hasn't achieved pre-release yet, I've been very happy using it. Much better than OOo-1.x
<snip>
Why can't OOo-2.x pre-release be included (given significant testing) and then updated to 2.0 final after FC4 is released. It's not like this hasn't been done before.
I'd have to ask what "significant testing" means.... :-)
Significant testing means putting OOo-2.x into rawhide so people can (and will) bang on it with whatever they use to bang things. ;-] Without it's inclusion it rawhide it's going to be really hard to know whether it's up to snuff, but given that it's due for final release around the same time as FC4 it should be pretty good.
People using FC3 already know what OOo-1.1.x is like, so this would be a good way to get them to compare the two.
Given the short release cycle of FC, I don't see the problem of deferring a program package to the next release, or making it available via up2date. If people really need to run code that close to the bleeding edge, they're free to do so via rawhide.
OOo-2.x isn't that close to the bleeding edge. Remember, like Firefox was to be ready around the same time as FC3, OOo is slated for final release around the same time as FC4. That's hardly bleeding edge. Thunderbird wasn't even close to release when FC3 was released.
Is it really a matter of choosing between FC4 and FC5? If omitted from FC4, why can't it made available via up2date at some time prior to FC5?
As I understand it, Redhat is loath to update software that isn't binary compatible during a release. So usually anything with a different major number is held back until the next release. The difference between OOo-1.1.x and OOo-2.x are big enough that I wouldn't think RH would want to upgrade to 2.x mid release.
Consider that there was some concern about going from gimp-2.0.x to gimp-2.2.x even though they were supposed to be binary compatible, and while it did happen, it doesn't happen often.
(up2date is one of pet peeves but it is A LOT better than it used to be)
I wouldn't know. I used to struggle with it until Alan Cox said it was a piece of crap (my paraphrasing) and that it should be dumped from FC. Given how nice yum is getting I couldn't agree more. ;-]
Rodd
Rodd Clarkson wrote:
Significant testing means putting OOo-2.x into rawhide so people can (and will) bang on it with whatever they use to bang things. ;-] Without it's inclusion it rawhide it's going to be really hard to know whether it's up to snuff, but given that it's due for final release around the same time as FC4 it should be pretty good.
OK... I have no objection to putting it into rawhide...
Is it really a matter of choosing between FC4 and FC5? If omitted from FC4, why can't it made available via up2date at some time prior to FC5?
As I understand it, Redhat is loath to update software that isn't binary compatible during a release. So usually anything with a different major number is held back until the next release. The difference between OOo-1.1.x and OOo-2.x are big enough that I wouldn't think RH would want to upgrade to 2.x mid release.
Consider that there was some concern about going from gimp-2.0.x to gimp-2.2.x even though they were supposed to be binary compatible, and while it did happen, it doesn't happen often.
OK.. you convinced me.... :-)
(up2date is one of pet peeves but it is A LOT better than it used to be)
I wouldn't know. I used to struggle with it until Alan Cox said it was a piece of crap (my paraphrasing) and that it should be dumped from FC. Given how nice yum is getting I couldn't agree more. ;-]
I've heard that too.... One of these days I'll "take the plunge" and learn how to use yum... in the mean time, I'm configuring sendmail, procmail, apache, ftp.... yum is on my to-do list :-)
Don
On Sun, 2005-01-30 at 21:18 -0800, Don Russell wrote:
Rodd Clarkson wrote:
Significant testing means putting OOo-2.x into rawhide so people can (and will) bang on it with whatever they use to bang things. ;-] Without it's inclusion it rawhide it's going to be really hard to know whether it's up to snuff, but given that it's due for final release around the same time as FC4 it should be pretty good.
OK... I have no objection to putting it into rawhide...
On the OpenOffice.org2 topic - I'd like 2.0 for FC4 - A little status update, Java became a build-time requirement to create the help-documentation for 2.0, and lots of extra components are in java, so rather than continue to find workarounds by disabling java bits, I expended my time building it with gcj, which is now possible and upstreamed for essential bits. Similiarly hauling around a seperate copy of mozilla, python et al within OOo didn't seem too appealing, http://people.redhat.com/caolanm/progress/progress.png - I'll make some basic x86 rawhide rpms available from http://people.redhat.com/caolanm/openoffice.org2 tomorrow, and sometime during the week ppc arch and the seperate language packs, if its not totally cocked up then perhaps we can think about rawhide :-)
C.
On Mon, 2005-01-31 at 09:32 +0000, Caolan McNamara wrote:
- I'll make some basic x86 rawhide rpms available from
OpenOffice.org 1.9.73 i386 rpms for rawhide available from... http://people.redhat.com/caolanm/openoffice.org2/i386/ for interested parties. Use at your own risk, etc etc.
C.
Hi,
OpenOffice.org 1.9.73 i386 rpms for rawhide available from... http://people.redhat.com/caolanm/openoffice.org2/i386/ for interested parties. Use at your own risk, etc etc.
Brilliant.
Do these need installing as ihv or Uhv?
TTFN
Paul
On Tue, 2005-02-01 at 21:29 +0000, Caolan McNamara wrote:
OpenOffice.org 1.9.73 i386 rpms for rawhide available from... http://people.redhat.com/caolanm/openoffice.org2/i386/ for interested parties. Use at your own risk, etc etc.
Whoops. Needs menu icons.
Also, all oo*2 commands start Writer, and when exiting, a message similar to the following shows up:
/usr/lib/openoffice.org1.9.73/program/soffice: line 235: 8598 \ Segmentation fault "$sd_prog/$sd_binary" "$@"
On Tue, 2005-02-01 at 18:18 -0500, Ignacio Vazquez-Abrams wrote:
On Tue, 2005-02-01 at 21:29 +0000, Caolan McNamara wrote: /usr/lib/openoffice.org1.9.73/program/soffice: line 235: 8598 \ Segmentation fault "$sd_prog/$sd_binary" "$@"
Yeah, I've figured that one out, it's a pretty cool bug. http://www.openoffice.org/issues/show_bug.cgi?id=41904
C.
Caolan McNamara wrote:
On Mon, 2005-01-31 at 09:32 +0000, Caolan McNamara wrote:
- I'll make some basic x86 rawhide rpms available from
OpenOffice.org 1.9.73 i386 rpms for rawhide available from... http://people.redhat.com/caolanm/openoffice.org2/i386/ for interested parties. Use at your own risk, etc etc.
C.
Thanks! Base comes up and is what my interest was related to. I tried the wintel version earlier today and it had issues.
For those wanting the launcher to the the programs. This attached is a gnome desktop launcher attached. Crude but open new for choices.
Jim
On Tue, 01 Feb 2005 19:01:12 -0500, Jim Cornette fct-cornette@insight.rr.com wrote:
Caolan McNamara wrote:
On Mon, 2005-01-31 at 09:32 +0000, Caolan McNamara wrote:
- I'll make some basic x86 rawhide rpms available from
OpenOffice.org 1.9.73 i386 rpms for rawhide available from... http://people.redhat.com/caolanm/openoffice.org2/i386/ for interested parties. Use at your own risk, etc etc.
C.
Thanks! Base comes up and is what my interest was related to. I tried the wintel version earlier today and it had issues.
For those wanting the launcher to the the programs. This attached is a gnome desktop launcher attached. Crude but open new for choices.
Those rpm(s) works fine on FC3 as well. The same Segmentation Fault on exit, as have reported earlier above the lines.
Thanks, Jim, but I've already edit menu by hand. Why gnome-gegel? Rather /ooo_gulls.png?
SAITO Toshiyuki
SAITO Toshiyuki wrote:
On Tue, 01 Feb 2005 19:01:12 -0500, Jim Cornette fct-cornette@insight.rr.com wrote:
Caolan McNamara wrote:
On Mon, 2005-01-31 at 09:32 +0000, Caolan McNamara wrote:
- I'll make some basic x86 rawhide rpms available from
OpenOffice.org 1.9.73 i386 rpms for rawhide available from... http://people.redhat.com/caolanm/openoffice.org2/i386/ for interested parties. Use at your own risk, etc etc.
C.
Thanks! Base comes up and is what my interest was related to. I tried the wintel version earlier today and it had issues.
For those wanting the launcher to the the programs. This attached is a gnome desktop launcher attached. Crude but open new for choices.
Those rpm(s) works fine on FC3 as well. The same Segmentation Fault on exit, as have reported earlier above the lines.
Thanks, Jim, but I've already edit menu by hand. Why gnome-gegel? Rather /ooo_gulls.png?
SAITO Toshiyuki
It was the first interesting icon that I changed upon. I was more interested in uniqueness than hunting down the icon. Also, I have the rpms from openoffice that sport the gull. The two seperate versions co-exist without interfering, /opt instead of the Fedora location.
One thing that I noted on Base when creating a new database, it defaults to initialize. It should not register the db beforehand. The tables cannot be created in this mode. After passing that hurdle, I created a table without trouble.
Jim
Testing OpenOffice.org 1.9.75 i386 rpms for rawhide available from...
http://people.redhat.com/caolanm/openoffice.org2/i386/
C.
On Wednesday 09 February 2005 16:15, Caolan McNamara wrote:
Testing OpenOffice.org 1.9.75 i386 rpms for rawhide available from...
Can you please provide the src.rpm of these test packs ?
I will atempt to build it on sparc/aurora too, but i want pack in fedorish' style. Actualy OOo2 run/build on sparc, but i want pack it in a nice *.sparc.rpm form.
Thanks in advance, ~cristian
Same thing but x86_64 for me :D
On Wed, 9 Feb 2005 16:52:27 +0200, Balint Cristian rezso@rdsor.ro wrote:
On Wednesday 09 February 2005 16:15, Caolan McNamara wrote:
Testing OpenOffice.org 1.9.75 i386 rpms for rawhide available from...
Can you please provide the src.rpm of these test packs ?
I will atempt to build it on sparc/aurora too, but i want pack in fedorish' style.
Actualy OOo2 run/build on sparc, but i want pack it in a nice *.sparc.rpm form.
Thanks in advance, ~cristian
-- fedora-test-list mailing list fedora-test-list@redhat.com To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-test-list
On Wednesday 09 February 2005 17:06, Justin Conover wrote:
Same thing but x86_64 for me :D
stop, read this first:
http://blog.janik.cz/archives/2005-01-23T11_34_01.html
64bit is not yet fully implemented in OO1/2, but can give a try/help to test debug it.
I think Dan Williams @RH know better this issue status, probably he is working on.
But, indeed a ppc build can be exist too of caolan src.rpm :) I would love it too on my ibook :)
On Wed, 9 Feb 2005 16:52:27 +0200, Balint Cristian rezso@rdsor.ro wrote:
On Wednesday 09 February 2005 16:15, Caolan McNamara wrote:
Testing OpenOffice.org 1.9.75 i386 rpms for rawhide available from...
Can you please provide the src.rpm of these test packs ?
I will atempt to build it on sparc/aurora too, but i want pack in fedorish' style.
Actualy OOo2 run/build on sparc, but i want pack it in a nice *.sparc.rpm form.
Thanks in advance, ~cristian
-- fedora-test-list mailing list fedora-test-list@redhat.com To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-test-list
On Wed, 2005-02-09 at 16:52 +0200, Balint Cristian wrote:
On Wednesday 09 February 2005 16:15, Caolan McNamara wrote:
Testing OpenOffice.org 1.9.75 i386 rpms for rawhide available from...
Can you please provide the src.rpm of these test packs ?
ok, http://people.redhat.com/caolanm/openoffice.org2/SRPMS/
note
a), its not going to fly for 64bit as that's a work in progress and the 64bit patches are not in that rpm, and probably won't be until the 64bit port does a bit more than crash on startup :-P b), ppc was not built in this test run because it failed in my last build 8 hours in due to some bizarre ppc/gcj/uno thing whose root cause escapes me. I'm not sure if I included the quick fix in the ppc patch in the src.rpm yet, but if not then its to #if 0 out the avmedia JAR entry in the scp2/source/ooo/files_library.scp, otherwise the src.rpm should be ok for ppc.
I'll hopefully get the language packs for seperate rpms for diverse languages working for the next test and then we can walk around and kick its wheels a bit. FWIW 1.9.78 is penciled in as the OOo2.0 beta.
Some interesting things about what we have to date is that gcc's -fvisibility=hidden stuff is in use for a lot of modules now which should give some good startup-speedups, in addition to many other tweaks and movement of huge chunks of code about the place so it should materalize on screen faster than 1.1.X (well, in theory). Moving to -Os rather than -O1 from ./configure (in-house Hamburg StarOffice defaults to -Os without flaw apparently) is still pending
C.
On Friday 28 January 2005 12:11, Dan Williams wrote:
On Fri, 2005-01-28 at 09:01 -0800, Joshua Andrews wrote:
openoffice really needs to lose some weight!
I think openoffice.org-i18n needs to be broken up or a script included to remove unwanted languages.
The language-specific files in the i18n RPM _are_ tagged with their respective language (using %lang specfile directive) so you can theoretically set some RPM macro and only install what you really want.
It would be nice if this "language selection" capability was also in anaconda.