-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi,
Kay Ramme - Sun Germany - Hamburg wrote: > >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). I already did two times. Anyway, sorry. > >>>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? There are not. There wasn't really firefox security updates except new firefox releases with other stuff. Same with the "normal" Mozilla. > >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. > >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..) > >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. > >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! No. A fork is if you fork off a codebase and do own stuff. This is some adaptions and eventually a few features which will get upstream. This is *not* 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? http://qa.openoffice.org/issues/show_bug.cgi?id=21678 http://qa.openoffice.org/issues/show_bug.cgi?id=37034 - - using non-free libraries like gpc (thankfully now avoidable by --disable-gpc and using basegfxs stuff) - - questionable licenses for the hyphs (need to remove all but de and hu) - - rhino/rhino.patch (quite obvious, told mh, nothing happened yet) - - jurt/doc - - netbeans_integration, I am quite sure there's stuff non-free/not LGPL compatible, correct me if not 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. > >>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 .... Thanks, but it mostly was important for 1.1.x (although probably too big) or for 2.0 (best time for an ABI change). I don't think you want to change the ABI now, do you? > >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 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) > >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. > >>>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. 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 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 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.. (You probably will count that as a argument for internal use of libs, but I'll mentioning this anyway) > >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) > >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. > >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... > >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. Regards, Rene -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEoVEl+FmQsCSK63MRAmAyAJ0VD3rDygBCa7M9VyEXc+dFqAl03ACeJf0W x4rWzpMqPjYi+xmp400TLg4= =3PDZ -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
