Rene,
Rene Engelhard wrote:
So, what are they saying that they do not update the older versions? Are
they backporting the fixes, or is Debian doing that?
There are not. There wasn't really firefox security updates except new
firefox releases with other stuff. Same with the "normal" Mozilla.
Does Mozilla describe somehow, how distros are supposed to bundle its
applications and how they are supporting the distros or something
similar? This obviously should include the handling of security patches etc.
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
You also ship getopt and readdir.
Which reminds me I need to finish my patch to hack that out and make
Linux builds not use it.
expressed in a formally correct way.
Yes, but then you still could have updated mozilla in-tree. it's still
1.7.5 there. Also the handling of issue
http://qa.openoffice.org/issues/show_bug.cgi?id=66338 was bad.
You are not shipping our version of Mozilla, so I would say, this is
more or less our problem only.
By the way, I think it would have been nice, to separate 3rd party stuff
into their own packages (going to add this to my notes).
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 ...
No, you only can (assuming you take the binaries) when you got a new
release. (Or a new milestone, rc, whatever, where the first is not really
recommended for a stable release and the rc, well, it might, but..)
I do not understand this, could you elaborate?
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.
Oh? You do e.g. Linux SPARC builds/porting? Where? Last I know only
Jim Watson does. You surely own sparcs at Sun so hardware cannot be the issue?
Analog with Linux/powerpc.
I was talking about contributing. The work does not necessarily need to
be done by us.
In my opinion, this all is only a question of scalability. Things need
to be done where they belong. Installation sets etc. IMHO belong to the
project, they may very well be contributed by others, so. I would love
to be able to put mozilla.org, x.org, openoffice.org, gnome.org etc.
into my sources.list and to dynamically and _directly_ update my Linux.
(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?
http://qa.openoffice.org/issues/show_bug.cgi?id=21678
This was some reading, I think I understand the issue and expect Martin
to fix it for 2.0.4.
http://qa.openoffice.org/issues/show_bug.cgi?id=37034
So, obviously the Dev.Guide is non-free. I wouldn't say that OOo is
non-free because of this. In this sense, Debian can obviously
redistribute the OOo SDK without the Dev.Guide only.
- - using non-free libraries like gpc
(thankfully now avoidable by --disable-gpc and using basegfxs stuff)
This is indeed ugly. Could basegfxs replace gpc completely?
- - questionable licenses for the hyphs (need to remove all but de and hu)
- - rhino/rhino.patch (quite obvious, told mh, nothing happened yet)
Need to take a look ...
- - jurt/doc
This is ridiculous, somebody should just remove it!
For those issues I didn't file an issue because it woldn't have brought
anything (see the jars issue).
But we nevertheless need to remove this stuff from Debians source and
binaries.
We may want to discuss these things further on OOoCon2006. May be
together with other distributions.
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 ...
See above.
Or take http://qa.openoffice.org/issues/show_bug.cgi?id=49590 (which is
still not fixed even with michaels patch, and so it's disabled
This seems to be a distro issue only, so I am not sure why the patch did
not make it yet.
completely in Debian...). Or that LFS issue above which had a tiny
change (which changed ABI, though, I am aware, so I didn't force it into
my packages myself, although I think it wouldn't have mattered, we use
an other stlport than you anyway -
http://packages.debian.org/libstlport4.6)
If I understand correctly, LFS is at least not incompatible UNO wise. I
do not know yet if it has any influence on the base line, but if it has
not, there should be no problem to just enable it. It seems even to be a
very local change (SAL).
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.
No, the point is that this was a comparison not that I expected you to do
it...
But in case we need those big changes independently of you we need them.
In any case, for those issues above I *did* raise the stuff early. And
as we see the jars issue is *years* old and the DevelopersGuide one
is WONTFIX.
The issues listed by you are not big issues in code terms. Some of them
seem to tickle fundamental questions (the license stuff), others seem to
be simple (so I do not know why pachtes have not been integrated yet).
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?
Pushing it upstream is nice and is done, but it might be that we need the
fix now anyway for further testing of the debs, fixing a
release-critical bug, preparing for the release, help the users
suffering from the ug *now* etc.
As said, the real code issues still seem to origin from your changes.
The license stuff is more ugly, but should be solvable one or the other
way also.
Some things even can't be gotten upstream. Like FHS support. If you have a good
idea how it's possible to add it without breaking your stuff (or mine if you
change something) please tell me. Not that fully FHS'izing OOo does work
OOos standard builds are AFAIK fully FHS compliant. The problem is, that
you change OOo to match your distribution and to become a bundled product.
currently....
Or for bugfixes which can't be done because the OOo build env doesn't support
conditionalizing them... (Java has no #ifdefs for example), and some
So, go and fix it and send in the patches.
distributions (not me) don't ship db4.2 anymore so they need to maintain own
patches to use db4.3/4.4 which can't go upstream..
At least the numbering (minor update only) implies compatibility, so
what are the patches for?
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?
Let's look at my last Debian upload:
* new upstream release candidate (2.0.3rc6).
- adds menu shortcut hint for "Tabelle" in German (closes: #364333)
- drop-down boxes in KDE for RTL languages fixed (closes: #286246)
* ooo-build:
- update
+ now falls back to english help when no local one is there
(closes: #345152)
If I had the RTL fixes before I would have applied them already. Same with
the help one.
This is a bad example, though because we still have enough time
to the release and so I could just have waited for 2.0.3rc6.
But something like that might happen. Also for bugs in the "normal" OOo.
Of course, there's some things caused by "my adaption", like
http://qa.openoffice.org/issues/show_bug.cgi?id=55065 for example,
have yet to try whether the patch fixes it, didn't yet have time to do that)
A release candidate accepted by the OOo community as "stable" should be
good enough for Debian as well as for any other distribution. Debian
related issues might be fixed or not, depending on severity and good
will. It is unfortunately not (yet;-) possible to release a bug free
version.
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,
Yes, afaik.
that Debian can _not_ be LSB compliant (this does not necessarily mean
to be something bad).
Right... But it can (and does) try to get as LSB-compliant as possible.
The installer stuff is a fundamental part of LSB. If you do not support
it, you can not claim to be LSB compliant, which may or may not become a
problem for Debian in the future, depending on the success of LSB.
From an ISV perspective (OOo and certainly also StarOffice are Linux
ISVs), LSB is really the light at the end of the tunnel.
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.
It already *was*. I can build them, though, but I don't have a system where
a "normal" OOo builds (newer binutils and stlport doesn't build anymore)
(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.
yes, but there's only one Debian and you could have looked. In any case, I
raised my voice hours after I saw that on the CVS list so there would be a
chance to revert that (the wasn't something bad about openofficeorg-*
instead of openoffice.org-*).
But I agree it's only unfortunate...
IIRC, LSB states that some namespaces are project dedicated. I would
have expected, that this would hold true for package names as well. We
try to follow LSB already. So, this does not need to mean anything for
non-LSB distros.
Which were the others?
As you mentioned, we are relying on or supporting Mozilla, expat, ICU,
expat did change compatibity? (you don't use libexpat anyway, you use
the old libxmltok/libxmlparse)
ICU didn't either, except that there's new versions with new SONAMEs..
and you use a patched version of it.
libxml, curl, evolution, stlport, gcc_s, ssl, and more, and would love
libxml is quite stable.
Same with curl.
evolution?
libssl isn't used at all..
[ see http://qa.openoffice.org/issues/show_bug.cgi?id=31053 btw... ]
stlport might be an issue yes, but it works fine with libstlport4.6
(not yet with 5.0, but that has an other SONAME anyway)
libgcc_s is a problem, though, right.
But *you* can do a build (static if you want) with those libs if needed,
but asking the distributors not to do so is bogus.
The point here is just, when moving out the 3rd party stuff, we need to
ensure that our builds still run on the targeted platforms. And we only
provide _one_ build for all x86 Linux, we are just balancing the
differences of the distros. If you have a patch removing 3rd party stuff
from the Linux builds, while preserving compatibility with the major
Linux distros, I am pretty sure that it is very welcome (and do not
break windows please).
Regards,
Rene
Looking forward to having some discussions with you on OOoCon2006
Kay
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
