Rene,
Rene Engelhard wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Kay Ramme - Sun Germany - Hamburg wrote:
[...]
What I wanted to say with the introduction was that I tried to be polite
but as there was things you mentioned which are no-no for distributions
and you offended all Debian users I needed to make clear I try that but
I did _not_ offend any Debian user, I am only asking questions and
making suggestions and express my opinion. For example, what is wrong
about asking why distros always compile everything by their own? It may
be naive but in _no_ terms offensive!
I cannot gurantee it. I wrote that mail in one go.
So, I suggest that you reread your mails before pushing the send button.
I do not have any tolerance for lazy mails (while I do not say that your
mails were lazy so).
[...]
purposes. Some are for desktop users, some are for generic servers, some
are for specialized purposes like firewalls, application servers or
clustering. Some try to imitate Windows or Mac OS X, some try to get
away from other OSes as much as they can. A lot of changes are made to
give personality to the distributions.
That does not necessarily mean, that they need to patch or change
anything in the provided products, does it? At least OOo provides
extensive configurability to actually change everything, without needing
to alter a single line of code.
Of course that does. There's bugs in OOo. Bugs need to be fixed.
Distributions and OOo have different release schedules. Or: You have
Release schedules shouldn't be the problem, I would expect Debian to
always ship the latest stable version.
We can't always. Release schedules is release schedules.
For example, we freeze in October, new OOo will come September.
I am not sure we will have enough time to get it into the distri.
(Building, testing in real-world, all library dependencies must be met
etc, various revisions, approval cycles, etc)
So, if you think that you do not have enough time to import the latest
OOo or that it does not match your quality guide lines, I suggest to
either go with the old one, or to officially raise your voice and to
express your concerns. I am pretty sure Martin is listening and would
escalate any issue as needed and appropriate.
Or take stable: 1.1.3 is in stable (1.1.4 was released already, yes, I
maybe could have gotten that in, but 1.1.3 needed updates first and then
it was too late. 1.1.5 was released *after* the sarge release)
So, 1.1.3 seems to be reasonable than.
some additions you *need* for whatever reasons.
And you don't build some of the optional stuff.
You have various UNFIXED security things open (Mozilla to name the most
prominent one).
Isn't Mozilla providing binaries of products with latest security patches?
No. Not for old versions. Just new versions. And the OOo tree still
So, what are they saying that they do not update the older versions? Are
they backporting the fixes, or is Debian doing that?
contains mozilla 1.7.5 which you build against (NB: I don't know how
your build env looks like) and ship.
As already said elsewhere, the problem is, that we did not find a way,
to reliable express dependencies against 3rd party stuff, except for the
real core stuff, as libc and friends. And AFAIK even these are not
expressed in a formally correct way.
In any case, it is a no-no for a Linux distri to ship binaries you just
got.
For what reason?
Because you can't do source fixes? You can't produce reliable binaries?
You certainly can, every binary release of OOo is (nearly:-) bitwise
reproduceable and tagged accordingly in CVS. And I would be surprised,
if our binaries would be less stable than yours ...
You can't provide packages for other archs (like we also do ppc and
sparc, for 1.1.x there also was s390)
You may want to look at this from the other side. Builds for other archs
may very well just be contributions to OpenOffice.org. OpenOffice.org
would than obviously provide these contributions. There is no need to
rebuild anything, even if you want to support other archs.
And not everything is configurable...
So you patch what is not configurable?
And what we need for other stuff, too.
We also of course patch the configs for our default-configs.
We also patch features in if that's sensible or if those features are
planned to go upstream some time (KDE stuff, Lockdown, Calc Solver etc)
What about providing patches to configure the needed things at run- or
deployment-time?
after all, OOo claims to be free software, so changing it is allowed
It certainly is, and, if I understand correctly (so, please correct me
if I am wrong), you are basically maintaining a fork!
(claims to becausse there's stuff which is *not* free in the tree since
loong which outstanding issues for them...)
You may want to give me a hint?
Yeah, I know, but you implied wanting every distri getting the rpms from
OOo and building their rpms/debs out of that.
No, you misunderstood me. My opinion is, that the easiest way would be,
to just take the binaries build by us, but you are certainly free to do
what ever you want ...
Are you only submitting bugs or fixes as well?
When I can fix them I submit fixes as well.
But they also didn't get applied.... See for example
http://qa.openoffice.org/issues/show_bug.cgi?id=26865 which had an easy
fix (ABI change, though, anyway) so it's not a that good example but
it was possible to fix with some coordination for a major release like
2.0.
I take a look at it ....
I mostly commit fixes myself now when I have some...
Sounds good :-)
When I can not there's problems.. But for important functionality bugs
or licensing bugs there's still no fix. Issue numbers on request...
Just give me some ids, I try to comment ...
Ah, suuuure. And then you have another schedule than a distri which
wants to release. And at some time needs to set the baseline what will
be there and at some time only allow minor fixes only. Would you accept
hughe updates at RC phase of OOo? I don't think so.
It is unlikely that we would accept huge changes late in a release. But,
there shouldn't be the need for them anyway, otherwise you raised your
voice too late.
What if you need to fix bugs *before* a new version of OOo comes out
upstream?
I would expect that you just do it like everybody else, stumble over a
problem, find a fix and push it upstream. Or did I misunderstood you?
I do. but OOo release can take longer than we need the fix. Sometimes we
need it immediately for testing and for the next release
I have the impressions, that these fixes are related to your adaption of
OOo. Do you have some examples?
I will cowardly let the Debian guys answer this ;-).
Yes, Debianists, please comment ...
I'll do.
That's complete bullshit.
OK, another comment like this, and you may talk to anybody else ...
Well, it's a attack against any person using Debian.
No, it is not. Please see above.
Debian (and it's derivatives) is a distribution like everyone else -
dpkg/deb even was there *before* rpm afaik. Even if not, Debian should be
Does that mean anything?
natively supported, not though alien'ized packages which can have
arbritrary amounts
iof bugs through conversion.
It seems that you are somehow personally offended ...
Right. Telling Debian people they just should use rpm is broken. There's
OK, that may be right, did Debian voice that at LSB? This also means,
that Debian can _not_ be LSB compliant (this does not necessarily mean
to be something bad).
deb and it's the superiour format... And even if it wasn't deb is the
It _is_ the superiour format.
format for Debian so providing debs is the right thing to do.
Anybody is free to contribute these.
There *is* support for Debian in your build system, but you don't enable
it...
(Or you at least don't publish the resulting files for deb support)
As I said, there were plans to provide .debs. But, isn't that
were. There isn't debs.
Martin H. may comment on the plans ...
(Not to mention you renamed the packages so that they are not parallel
installable anymore with the official debs, but that's another matter)
This is unfortunate. But, we can not really know and check all distros
package names.
libfreetype6 is an exception, it a long time was buggy iin this respect,
but bugs appear everywhere, even in OOo.
freetype was just one of many problems ...
Which were the others?
As you mentioned, we are relying on or supporting Mozilla, expat, ICU,
libxml, curl, evolution, stlport, gcc_s, ssl, and more, and would love
to find a way not needing to build and to ship these anymore.
Regards,
Rene
Kay
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
