Re: does something still depend on poppler?
Hi Pedro, On 07.11.2013 20:04, Pedro Giffuni wrote: Hello; I just noticed on FreeBSD port we have a dependency on poppler-glib. Opengrok reports it is detected in configure but it doesn't seem to be used elsewhere. The poppler license is cat-x so it was probably removed before graduation. Is it still useful at all? OpenGrok only gives trunk/main/configure.in and there is something like --with-system-poppler. I have not found a reaction on that flag, but I am no configure expert, so someone knowing that better (hdu?) should have a look... Regards, Pedro. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: does something still depend on poppler?
Hi Pedro, hi Armin, On 08.11.2013 10:06, Armin Le Grand wrote: On 07.11.2013 20:04, Pedro Giffuni wrote: I just noticed on FreeBSD port we have a dependency on poppler-glib. Opengrok reports it is detected in configure but it doesn't seem to be used elsewhere. The poppler license is cat-x so it was probably removed before graduation. Is it still useful at all? OpenGrok only gives trunk/main/configure.in and there is something like --with-system-poppler. I have not found a reaction on that flag, but I am no configure expert, so someone knowing that better (hdu?) should have a look... Looking through the history the --with-system-poppler and --enable-pdf-import configure options seem to be remainders of the XPDF removal in the IP-Clearance phase that was done before our first release. https://issues.apache.org/ooo/show_bug.cgi?id=118592 has more details on that removal. The developers that worked on XPDF removal (Andre and Jürgen) know probably better whether these options are still needed? Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Number of spreadsheets limitation
but MS Excel manages much more than that (I still don't know the limit, but we have here a file with 336 spreadsheets, which cannot be opened in OO 4.0.1 without loss). https://issues.apache.org/ooo/show_bug.cgi?id=35901 - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
the Seamonkey has left the building
As discussed in the thread AOO Security Features without Mozilla I removed the dependency on the ancient Seamonkey-1.1 binaries and use the NSS libraries (Network Security Services) instead. This major rework has been integrated into trunk now. If you are working on trunk you'll notice that the moz module and the configure switch named --disable-mozilla is gone. This switch was sometimes used to build Apache OpenOffice without security services. If you want to continue building without security services please use the --disable-nss-module instead. Whether such an insecure AOO build is something to aim for is dubious though, especially since the biggest hurdles to enable this functionality have been removed which were: - building the Seamonkey-1.1 using special old compiler versions - providing zip-archives of such prebuilt Seamonkey-1.1 binaries are no longer needed. Good riddance. If you are working on Windows then you'll notice that the --with-mozilla-build option is still there as NSS being part of the Mozilla project needs the Mozilla build environment. If you object to install the Mozilla build environment then you couldn't build the moz+nss modules on Windows then and cannot build nss on Windows now. Please use the --disable-nss-module or the --disable-category-B switches if providing the Mozilla build environment for NSS is out of the question. As shown in the earlier thread on this topic the address books provided via the old Seamonkey binaries were quite bit-rotten and often didn't work on modern systems. There is a good chance that their successors will be ready for AOO 4.1 and solve most current problems. Volunteers who'd like to dive right into AOO's SDBC subsytem and write drivers for Mork, LDAP or MAB address book formats are welcome. Especially power users of the older implementations who suffered their shortcomings may find this chance interesting. With the Seamonkey-1.1 compatibility requirement removed it was now also possible to do an overdue update of the security critical NSS libraries to their latest released version. Thanks to Pedro for his initial patch on the platform-independent part of the library update. Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: the Seamonkey has left the building
Hi Herbert, On 08.11.2013 13:18, Herbert Duerr wrote: As discussed in the thread AOO Security Features without Mozilla I removed the dependency on the ancient Seamonkey-1.1 binaries and use the NSS libraries (Network Security Services) instead. This major rework has been integrated into trunk now. If you are working on trunk you'll notice that the moz module and the configure switch named --disable-mozilla is gone. This switch was sometimes used to build Apache OpenOffice without security services. If you want to continue building without security services please use the --disable-nss-module instead. Whether such an insecure AOO build is something to aim for is dubious though, especially since the biggest hurdles to enable this functionality have been removed which were: - building the Seamonkey-1.1 using special old compiler versions - providing zip-archives of such prebuilt Seamonkey-1.1 binaries are no longer needed. Good riddance. Yippie! Congrats! If you are working on Windows then you'll notice that the --with-mozilla-build option is still there as NSS being part of the Mozilla project needs the Mozilla build environment. If you object to install the Mozilla build environment then you couldn't build the moz+nss modules on Windows then and cannot build nss on Windows now. Please use the --disable-nss-module or the --disable-category-B switches if providing the Mozilla build environment for NSS is out of the question. Is there a way to get around this...? Maybe nss can be 'replaced' somehow...? As shown in the earlier thread on this topic the address books provided via the old Seamonkey binaries were quite bit-rotten and often didn't work on modern systems. There is a good chance that their successors will be ready for AOO 4.1 and solve most current problems. Volunteers who'd like to dive right into AOO's SDBC subsytem and write drivers for Mork, LDAP or MAB address book formats are welcome. Especially power users of the older implementations who suffered their shortcomings may find this chance interesting. With the Seamonkey-1.1 compatibility requirement removed it was now also possible to do an overdue update of the security critical NSS libraries to their latest released version. Thanks to Pedro for his initial patch on the platform-independent part of the library update. Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: the Seamonkey has left the building
On 11/8/13 1:18 PM, Herbert Duerr wrote: As discussed in the thread AOO Security Features without Mozilla I removed the dependency on the ancient Seamonkey-1.1 binaries and use the NSS libraries (Network Security Services) instead. This major rework has been integrated into trunk now. If you are working on trunk you'll notice that the moz module and the configure switch named --disable-mozilla is gone. This switch was sometimes used to build Apache OpenOffice without security services. If you want to continue building without security services please use the --disable-nss-module instead. Whether such an insecure AOO build is something to aim for is dubious though, especially since the biggest hurdles to enable this functionality have been removed which were: - building the Seamonkey-1.1 using special old compiler versions - providing zip-archives of such prebuilt Seamonkey-1.1 binaries are no longer needed. Good riddance. If you are working on Windows then you'll notice that the --with-mozilla-build option is still there as NSS being part of the Mozilla project needs the Mozilla build environment. If you object to install the Mozilla build environment then you couldn't build the moz+nss modules on Windows then and cannot build nss on Windows now. Please use the --disable-nss-module or the --disable-category-B switches if providing the Mozilla build environment for NSS is out of the question. As shown in the earlier thread on this topic the address books provided via the old Seamonkey binaries were quite bit-rotten and often didn't work on modern systems. There is a good chance that their successors will be ready for AOO 4.1 and solve most current problems. Volunteers who'd like to dive right into AOO's SDBC subsytem and write drivers for Mork, LDAP or MAB address book formats are welcome. Especially power users of the older implementations who suffered their shortcomings may find this chance interesting. With the Seamonkey-1.1 compatibility requirement removed it was now also possible to do an overdue update of the security critical NSS libraries to their latest released version. Thanks to Pedro for his initial patch on the platform-independent part of the library update. thanks Herbert for the update, this are good news ... A further good step would be to get rid of nss and use openssl instead and use the system certificate stores on the different platforms. If I understand it correct that is the main advantage of nss, it has it's own certificate store. But anyway very good news and a further step in the right direction. Maybe some other volunteers are interested or already have knowledge how to use the system cert store and can help ... Juergen - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: the Seamonkey has left the building
On 08.11.2013 13:39, Armin Le Grand wrote: On 08.11.2013 13:18, Herbert Duerr wrote: [...] If you are working on Windows then you'll notice that the --with-mozilla-build option is still there as NSS being part of the Mozilla project needs the Mozilla build environment. If you object to install the Mozilla build environment then you couldn't build the moz+nss modules on Windows then and cannot build nss on Windows now. Please use the --disable-nss-module or the --disable-category-B switches if providing the Mozilla build environment for NSS is out of the question. Is there a way to get around this...? Maybe nss can be 'replaced' somehow...? There are several libraries that could be alternatives, please see [1] for an overview. Evaluating the viability of them for replacing the individual aspects of NSS that are used in AOO could be an interesting task for volunteers. [1] http://en.wikipedia.org/wiki/Comparison_of_TLS_implementations Regarding the requirement of having the mozilla build environment for building NSS on Windows: I don't think NSS needs much of that tooling. They require this MingW based environment like we depend on our Cygwin based environment. NSS could certainly be rewritten to use cygwin too. But is it worth the trouble? Downloading MozBuildSetup [2] and running it is not much of an effort and it has the great benefit that we can then consume the source releases of NSS almost directly. The alternative of rewriting NSS for our cygwin environment would be much more intrusive than what is recommended for a category-B licensed library. [2] http://ftp.mozilla.org/pub/mozilla.org/mozilla/libraries/win32 Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: the Seamonkey has left the building
On 8 November 2013 14:09, Herbert Duerr h...@apache.org wrote: On 08.11.2013 13:39, Armin Le Grand wrote: On 08.11.2013 13:18, Herbert Duerr wrote: [...] If you are working on Windows then you'll notice that the --with-mozilla-build option is still there as NSS being part of the Mozilla project needs the Mozilla build environment. If you object to install the Mozilla build environment then you couldn't build the moz+nss modules on Windows then and cannot build nss on Windows now. Please use the --disable-nss-module or the --disable-category-B switches if providing the Mozilla build environment for NSS is out of the question. Is there a way to get around this...? Maybe nss can be 'replaced' somehow...? There are several libraries that could be alternatives, please see [1] for an overview. Evaluating the viability of them for replacing the individual aspects of NSS that are used in AOO could be an interesting task for volunteers. [1] http://en.wikipedia.org/wiki/Comparison_of_TLS_implementations Regarding the requirement of having the mozilla build environment for building NSS on Windows: I don't think NSS needs much of that tooling. They require this MingW based environment like we depend on our Cygwin based environment. NSS could certainly be rewritten to use cygwin too. But is it worth the trouble? Downloading MozBuildSetup [2] and running it is not much of an effort and it has the great benefit that we can then consume the source releases of NSS almost directly. The alternative of rewriting NSS for our cygwin environment would be much more intrusive than what is recommended for a category-B licensed library. Especially considering we have ongoing efforts to remove cygwin, and use visual studio directly. rgds jan I. [2] http://ftp.mozilla.org/pub/mozilla.org/mozilla/libraries/win32 Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [Accessibility] IA2 Integration proposal
On Fri, Nov 8, 2013 at 2:42 AM, Steve Yin steve.yin@gmail.com wrote: Hi all, The main development work for IA2 feature is finished on the branch ia2. Although there are some bugs in the current revision, I propose to merge the branch to the trunk for involving more volunteers. Hi Steve, This is excellent news. It sounds like you've made great progress in this big task. I'll start on a blog post to describe the work, based on your information. We can use the blog post to let users know that this capability is coming in AOO 4.1 and maybe to call for more volunteers to help test. A question for you: Is there a possibility of these changes introducing new defects in other areas of the product? If so it would be good to get your opinion on what areas we should re-test to find any defects earlier. For example, I assume parsing of documents is not effect by these changes. But should we look for visible changes to dialogs? If there are new bugs, what is your best guess for where they would show up? Regards, -Rob -- Best Regards, Steve Yin - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: JIRA instead of Bugzilla?
On 8 November 2013 00:43, Kay Schenk kay.sch...@gmail.com wrote: On Thu, Nov 7, 2013 at 2:28 PM, Rob Weir robw...@apache.org wrote: On Tue, Oct 22, 2013 at 11:14 AM, janI j...@apache.org wrote: On 22 October 2013 16:41, Oliver-Rainer Wittmann orwittm...@googlemail.comwrote: Hi, On 22.10.2013 10:04, Rainer Bielefeld wrote: Hi, it's really daunting that nobody cares! I care, but only as a user of our Bugzilla instance being frustrated when I need Bugzilla in the morning (European time zone). It seems that we need to involve ASF Infra as I do not believe that this scheduled outage every day is controlled by us. Just checked, there are no outstanding issues with aoo-bz, except its very slow because it has not yet had the db moved. The scheduled outage is unknown, but could be the backup which runs very early morning (europe time). rgds jan I. Ps. once again it was suggested that we move to jira. By whom? AFAIK, JIRA requires more resources than Bugzilla. So for argument's sake, and speaking purely hypothetically, what are the pros and cons of moving to JIRA? It is worth at least discussing whether this would be something worth looking into. ==Con== 1. Assume migration of new bugs would be imperfect. But maybe not so bad. We have many attachments, comments, etc., but the comments are all plain text, not rich text. 2. New tool to learn for volunteers. But many of us know JIRA also. 3. Would require some time to migrate, from Infra and from BZ admins 4. ??? The handling of attachments is poor comnpared with Bugzilla (which is very straightforward). There does not seem to be a way to add comments at the same time as an attachment. Marking an issue as a duplicate requires a separate operation to link to the duplicate issue. AFAIK importing issues requires quite a long down-time. This would presumably affect both Bugzilla and JIRA, as Bugzilla would need to be be read-only for the duration. It may be quicker if JIRA is set up as a separate instance. ==Pro== 1. Performance/stability? I assume that is why Infra was suggesting this? AFAIK, JIRA needs more resources and is less stable than Bugzilla. Make sure this information is checked with Infra before it is relied on. 2. Agile features that help with release planning It is easier to find issues that relate to a particular version. 3. Anything else ??? UI looks nicer, but has been known to change without warning between releases. Regards, -Rob - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org This is neither a pro nor a con, just a comment. We make use of saved searches and can make them public -- I did a quick look at the ref for Jira and I can't tell how Jira's mechanisms work in this fashion. I have used both also, but did not do anything very sophisticated with Jira in the past. -- - MzK “Unless someone like you cares a whole awful lot, Nothing is going to get better. It's not.” -- Dr. Seuss, The Lorax - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: the Seamonkey has left the building
Thats great news. Thanks for doing the effort. :-) Marcus Am 11/08/2013 01:18 PM, schrieb Herbert Duerr: As discussed in the thread AOO Security Features without Mozilla I removed the dependency on the ancient Seamonkey-1.1 binaries and use the NSS libraries (Network Security Services) instead. This major rework has been integrated into trunk now. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
[WWW]Certificate errors for forums
Some people get certificate errors on the forums https://forum.openoffice.org/en/forum/viewtopic.php?f=50t=65462 I can see this too every now and then, but not on the browser: reading the ES forum rss feeds Akregator sometimes shows, apparently at random times, a certificate error. Regards, Ricardo
Unowinreg.dll in build guide
The build guide doesn't mention it. https://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO . I tried to add the following information, but got a 502 error: |- valign=top | unowinreg.dll | [http://tools.openoffice.org/unowinreg_prebuild/680/unowinreg.dllpre-built unowinreg.dll] (see note) note: Not for windows. Required on all non-windows platforms. Download with: cd $SRC/main wget -O external/unowinreg/unowinreg.dll http://tools.openoffice.org/unowinreg_prebuild/680/unowinreg.dll -- Marcin Tustin
Failure with system NSS
Hello; I tried the new --with-system-nss configure option but it failed in the libxmlsec module: checking for libxslt libraries = 1.0.20... no checking for openssl libraries = 0.9.6... no checking for nspr libraries = 4.0... no checking for nss libraries = 3.2... no checking for gnutls libraries = 0.8.1... no checking for mscrypto libraries... none checking for crypto library... configure: error: At least one crypto library should exist for xmlsec1 yes checking whether byte ordering is bigendian... dmake: Error code 1, while making './unxfbsdx.pro/misc/build/so_configured_so_xmlsec1' On FreeBSD, the system NSS is here: % ls /usr/local/lib/nss libcrmf.alibnssckbi.solibnssutil3.so.1 libssl3.so libfreebl3.solibnssckbi.so.1 libsmime3.so libssl3.so.1 libfreebl3.so.1 libnssdbm3.solibsmime3.so.1 libnss3.so libnssdbm3.so.1 libsoftokn3.so libnss3.so.1 libnssutil3.so libsoftokn3.so.1 But it appears that nspr is not found either: % ls /usr/local/lib/libnspr* /usr/local/lib/libnspr4.a/usr/local/lib/libnspr4.so.1 /usr/local/lib/libnspr4.so While here, I suspect that if libxmlsec could find openssl, it would seriously help progress in the direction of not depending on nss. Finally, both openssl and libxmlsec could get an update. libxmlsec is probably not easy to update, but for openssl I uploaded a newer version to apache-extras. JIC someone is looking for a good excuse to contribute ;). Pedro. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org