Hi,

Am Mittwoch, 28. Juni 2006 10:52 schrieb Kay Ramme - Sun Germany - Hamburg:
> Rene Engelhard wrote:
> > 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.

We are going to ship no version of Mozilla...

> > 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
we also not allowed to ship non-free stuff. And it doesn't do users good to omit
that Guide...

> > - - 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...

> > - - 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..

> > 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.

> > 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...

> > 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.

> 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..

> > 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

> > 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)

> 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.

> 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
compatibility for AGES. Just an example. Any current Linux distri uses 
libcurl.so.3.
More examples?

Regards,

Rene
-- 
René Engelhard -- Debian GNU/Linux Developer -- Debian OOo Maintainer-Team
http://www.debian.org | http://people.debian.org/~rene/ | [EMAIL PROTECTED]
http://openoffice.debian.net | debian-openoffice@lists.debian.org
GPG: 248AEB73 | Fingerprint: 41FA F208 28D4 7CA5 19BB 7AD9 F859 90B0 248A EB73

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to