Rene,
Rene Engelhard wrote:
We are going to ship no version of Mozilla...
No Mozilla at all? Neither Firefox nor Thunderbird etc.? Or are you
talking about the suite only?
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.
That's what we do now but it still means repackaging the source since
What needs to be done to simplify this process?
- - 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?
I didn't see bad effects, but didn't dig deep into it. Even if there were issues
I wouldn't be able to use gpc...
It seems, that already have had a good experience with basegfx. Did you
provide patches for removing gpc?
- - 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!
Maybe, but it's there..
This files do not even get delivered. So, please just create a CWS and
remove them.
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.
No, it's not. It's an issue for any serious admin.
You don't want to have any user set the link youself, you want to add it
globally and be done with it. That's the same case here, I could package it
but let the users enable the plugin but that IMHO is bad.
So, this is an OOo issue independent of any distros needs. Obviously it
has not been regarded yet to be severe enough to get fixed. This has
nothing to do with our discussion.
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).
well, it changes ABI...
SAL is supposed to encapsulate all system dependent file operations, the
comment in the issue states, that all necessary types are already 64
bit. Turning on LFS for SAL is, as far as I understand, not changing
SALs ABI, as non system implemented function is passed through. So, I
have to admit, that I do not which ABI you are talking about.
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.
No, I didn't change the plugin in any way (well, we do with michaels patch now,
which doesn't work reliably either)
It simply doesn't work if you eant to enable it globally.
So, you mean that from your point of view this issue is release
critical, while the rest of OOo does not think so?
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.
For you. Not for distris.
The FHS does *not* allow /opt for distris. /opt is for third-party add-ons.
Like for you.
distris have to use /usr/lib, /usr/share, /etc, /var etc.
(which I currently do using some symlinks, hacks, etc, and teh config still
isn't in /etc
and the arch-indep stuff still is in /usr/libn/openoffice/share..
AFAIK, /opt is for unbundled software, while the other directories are
for bundled stuff. You may very well create a OOoForDebian and release
it as unbundled software. And this is exactly the point I wanted to
make, why do you want to release it as bundled?
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.
Uh, you don't understand me. There's no conditionalizing possible because Java
has no
#ifedf like thing
#ifdefs are often the wrong approach anyway. Find a patch which
generalizes the code. Also, it would be nice to concretely see the
problem you want to fix.
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?
API changes in db. They change API between minor releases which is also normal
for other
stuff. Or change db on-disk format (which thankfully isn't the cas ehere for
OOos needs)
Does that mean, that they did change the API incompatible in a MINOR? If
it did not change incompatible, than there is no problem anyway.
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.
Yes, but still then you might release a new one *after* a deadline of the
distri.
And you as a disti have to be have th epossibility to backport fixes like the
ones
above if needed. Buildability from sources is a principle in the Linux
distributions.
This is simple, do _not_ rely on release candidates and schedules of
other projects, they may slip. Take the stable product instead.
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
LOL. And Linux distri uses zlib. It is completely compatible and hasn't changes
So, I do not know what is funny about this.
compatibility for AGES. Just an example. Any current Linux distri uses
libcurl.so.3.
More examples?
Did you provide a patch for this? Is it compatible with OOo supported
distros? Than there shouldn't be any problem to integrate it.
Regards,
Rene
Kay
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
