Re: [dev] AutoUpdate of Office via web
Hi ! KAMI wrote: Will Ingo provide such configure switch? Until that how can enable it in the right way? I do not think a configure switch for enabling online update is on anyones task list yet. Also I have to admit making this feature easily re-usable by others wasn't one of the primary design goals, mostly because other OOo vendors did already have their own update channel. So unless you come up with a patch yourself to introduce a configure switch for enabling online update (which I would happily review), the easiest way for you is probably to go with the patch you already have. Regards, Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] AutoUpdate of Office via web
KAMI wrote: Oliver Braun írta: Are you referring to http://wiki.services.openoffice.org/wiki/Update_Notification_Protocol ? It potentially needs some update itself, but I can't check at the moment as the wiki is currently offline. Can you update the information in the wiki? Done. Do we have a working method to make difference between deb and rpm packages under Linux. I can not se this information in the update protocol. Or we do not want to provide online update for OOo under Linux? The UpdateURL in the versionrc file must be different for deb rpm builds. Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] AutoUpdate of Office via web
Hi ! KAMI wrote: How can I unable Online Update functionality during build? I have patch for it, but I think this is not the ideal solution. I assume you mean enable, right ? As there currently is no configure switch for this, a patch is the only way to do so. Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] AutoUpdate of Office via web
KAMI wrote: I would like to use auto update functionality of openoffice.org. I have created this page: http://ooop.sourceforge.net/update/ooop.php It somehow does not working well. I found this documentation, but I can not see what information need for OOo for the update. Also I saw there is a way to OOo downloads the updates (and not redirected in a new browser window) How does it works? Are you referring to http://wiki.services.openoffice.org/wiki/Update_Notification_Protocol ? It potentially needs some update itself, but I can't check at the moment as the wiki is currently offline. Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Where our products install to
Hi Stephan, Stephan Bergmann wrote: The planned new (OOo 3.0) structures are as follows: On Unix (Linux, Solaris): - The URE product still by default will install to /opt/openoffice.org/ure (but only the /opt prefix is relocatable). - The OOo product by default will install its three layers into -- /opt/openoffice.org/ure -- /opt/openoffice.org/basis3.0 -- /opt/openoffice.org3.0 (where only the /opt prefix is relocatable). - The StarOffice product, for example, by default will install its three layers into -- /opt/openoffice.org/ure -- /opt/openoffice.org/basis3.0 -- /opt/staroffice9 (where only the /opt prefix is relocatable). Is there a good reason to keep the minor (3.0) in the path names and thus to continue to lose (super-)user deployed dictionaries and UNO extensions when upgrading from e.g. 3.0 to 3.1 ? Regards, Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Mac Aqua Build on a Quad G5 under Leopard
Try using the version of Ant that comes with Xcode (/Developer/Java/Ant IIRC). Oliver Russell McGaha wrote: Already done via fink; no joy. Since '/System/Library/Frameworks/JavaVM' doesn't exist; I wondering if it doesn't have to do with how 10.5 handles Java. Russell On Dec 13, 2007, at 8:03 PM, Azreal Yang wrote: hello,i think is a problem about your ant version,you should download a ant that version is =1.6.0 hope it helps. 2007/12/14, Russell McGaha [EMAIL PROTECTED]: Trying to follow the Aqua build instructions on a Quad G5 running 10.5.1, I get the following error in the build.sh script [actually, I think it is in the ./configure script RUN by build.sh] : checking for ant... /sw/bin/ant checking whether ant is = 1.6.0... ./configure: line 25055: test: not /System/Library/Frameworks/JavaVM: integer expression expected configure: error: no, you need at least ant = 1.6.0 anyone know if a cure is possible?? Russell - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- 你咋知道我姓杨呢？ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] How to repackage a OOo build?
Hi Carlos, if you configure the OOo build with --with-package-format=installed, it won't create any rpms, but create the directory structure as it will appear on disk when the rpms got installed. You then can package the result in any way you like. Oliver Carlos López wrote: Dear OOo developers, I've decided to write to you because I need advice from pleople having a deep knowledge about OpenOffice. I've tried to get all the information I need on my own, but unfortunately I haven't been able to do it alone. Recentely, I've posted my problem in the OpenOffice forum and, after waiting for someone to give some advice, I've been told to ask you directly. Besides, I think there is no point to paste the problem here again, so please refer to the next link for details at: http://www.oooforum.org/forum/viewtopic.phtml?p=249962#249962 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] rtl::Reference vs. [com::sun::star::]uno::References
Kay Ramme - Sun Germany - Hamburg wrote: Some of the reasons for the namespace problems we are facing are IMHO simply non optimal placings, e.g. com::sun::uno::Reference would have belonged into cppu (cppu::Reference or may be simply uno::Reference. As probably most people agree with, the whole com::sun::star namespace became obsolete when open sourcing StarOffice and should have been renamed to OOo (or similar), and I am sure there are more aspects one currently would like to see being reflected in the namespaces, but ... we want to stay API and ABI compatible, more or less rendering these thoughts useless ;-) What about new interfaces / services ? Would it be feasible to create uno:: aliases for com::sun::star::uno:: and com::sun::star::lang and start using org::openoffice namespace for new interface/service definitions ? Or even better, move the basic types to ::uno and make aliases for those in the old namespace(s) ?! Other aliases (e.g. for beans etc.) might need to get added over time, but at least we could start the transition. Just my 2 cents, Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] m220 is unstable on Fedora 7
Joe Smith wrote: Starts OK; registration finishes, but using the app (almost any action) for more than a few seconds triggers a crash with a recovery dialog. Please tell me if there's something else I can try. Try disabling online update check (Tools - Options - OpenOffice.org - Online Update). Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Re: m220 is unstable on Fedora 7
Joe Smith wrote: Joe Smith wrote: Oliver Braun wrote: ... Try disabling online update check (Tools - Options - OpenOffice.org - Online Update). Yep, that's consistently where it poops out: ... Seems stable now--thanks! Will be fixed in m221. Thanks for confirming. Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] A: CWS'es with red tinderbox status need justification
Hi *, the OOo release status meeting from 2007/05/15 has accepted a proposal for a new nomination policy affecting child workspaces with a red tinderbox status reported in EIS: Child workspaces with a red tinderbox status need a valid justification when promoted to ready for QA state, otherwise the CWS will be rejected from QA. The justification is expected to be given from one of the developers involved (usually the CWS owner) and should explain why it is o.k. to nominate or integrate the particular child workspace in the current state nonetheless. Some guidance on what needs to be done when one of your CWS'es is affected (including a list of known false positives) can be found at http://wiki.services.openoffice.org/wiki/RedTinderboxStatusInEIS. More info on Tinderbox/EIS integration can be found on http://wiki.services.openoffice.org/wiki/TinderboxAndEISStatus. Regards, Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Windows: Help needed
Hi Stephan,
please find my comments inline:
Stephan Bergmann wrote:
[..]
- Executables and shared libraries in OOo-wo-URE find shared libraries
in URE they depend on via an RPATH (recorded in those executables and
shared libraries) that includes the link to the URE.
I don't understand what you need the symbolic link for:
exported interfaces usually reside at a fixed location (be it below /usr for
bundled or /opt for unbundled packages).
For manual overrides (e.g. for debugging), use LD_LIBARRAY_PATH, which was
invented for that purpose (I consider it a bug that we still use it in our start
script).
Even if you want to keep the URE reference relative, you still do not need the
symbolic link.
- The deployment variables URE_BIN_DIR (used in all other places in the
code where things in URE need to be accessed) and URE_BOOTSTRAP
(pointing at a fundamentalrc in OOo-wo-URE that contains essential
deployment variables to adapt the URE to the needs of OOo) are set in
the shell scripts soffice and unopkg (which should cover, via
indirections, most if not all of the executables that constitute the
interface of OOo, see
http://www.openoffice.org/servlets/ReadMsg?list=devmsgNo=19840).
If the runtime linker was able to find libuno_sal.so, we already know
URE_BIN_DIR, don't we ? Why do we have to double that information in the shell
scripts ?
Please give some examples what entries will be in URE_BOOTSTRAP and why they
can't be in let's say sofficerc.
However, I have problems imagining how I can do something similar on
Windows:
- An installed URE already announces its location in the Windows
registry at HKEY_CLASSES_ROOT\Software\OpenOffice.org\URE. But, even if
all the code that needs to know this value can read it (e.g., we
introduce additional syntax so that the URE_BIN_DIR deployment variable
can be set to something like
${registry:HKEY_CLASSES_ROOT/Software/OpenOffice.org/URE:Path}), one
ugly problem would remain: It would not be easy at all to install two
different pairs of URE and OOo-wo-URE on the same machine (which is of
utmost importance at least for developers, and somewhat easily solved in
the Unix scenario above---all you have to do is adjust the one symbolic
link per installed URE/OOo-wo-URE pair).
As stated above, one does not necessary need symbolic links to address the debug
problem on Unix.
The canonical way to achieve this on Windows I believe is to extend the PATH
variable by default (or install into the system32 directory) and copy debug
versions aside the executable where they will be preferred.
Regards,
Oliver
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Windows: Help needed
Caolan McNamara wrote: I dropped LD_LIBRARY_PATH in the startup script for a bit, because we have rpath ORIGIN we don't need it in OOo itself. But the snag I ran into is that with the current layout at least we do need it so that third party uno components spawned by OOo which are deployed into /uno_packages/ can link against the /path/to/ooo/program libraries :-( If spawned in process, I would expect those libraries to already be mapped into memory. And for out-of-process components we could adapt the launcher to set LD_LIBRARY_PATH appropriately. Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Re: Proxy setting in Inet.xcu has no effect
Matthias B. wrote: On 3/23/07, Oliver Braun [EMAIL PROTECTED] wrote: If you don't need a proxy for the servers you need to access, wouldn't adding those (via API) to the No proxy for list (ooInetNoProxy) solve your problem as well ? Does this allow wildcards? The problem is that I don't have an exhaustive list of all servers in the internal network (and this is a moving target). Yes, wildcards can be used here. Regards, Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Re: Sharing packages across products
Kay Ramme - Sun Germany - Hamburg wrote: For admins actually making use of relocations regulary, it is quite likely that (s)he initially ends up with e.g. /usr/local/program etc. when trying to relocate to /usr/local. which obviously is unfortunate, so we are going to try to fix this :-) Is there already an issue for that? If there is, I didn't came across it yet. Which probably means my example should not be the primary motivation to change the prefix/basedir. But sharing packages across products may be ;-). Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] Re: Proxy setting in Inet.xcu has no effect
Hi, Matthias B. schrieb: A frequent problem for us is that the proxy is misconfigured which causes our custom component (which loads templates from a web server via loadComponentFromUrl) to fail. Since we don't need access to the outside world for OOo, we want to disable the proxy completely. It turns out that editing the Inet.xcu to turn off the proxy is ineffective under Windows, too. Isn't this a bug? Aren't the config files in share/registry/... supposed to be consulted by OOo? They are consulted, but the desktop layer takes precedence. This leaves us no choice but to have our component disable the proxy via UNO API, which of course prevents use of a proxy completely, even in environments where the proxy is properly configured. If you don't need a proxy for the servers you need to access, wouldn't adding those (via API) to the No proxy for list (ooInetNoProxy) solve your problem as well ? - Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Installset Phenomena
Hi *, Rene Engelhard wrote: - Why is ./program/unopkg_gui (a trivial shell script to execute unopkg gui) part of (various different) desktop integrations (e.g., -mandrivia-menus-, -redhat-menus-, -suse-menus-) and not just once and for all put into the same package as ./program/unopkg itself (-core02-)? Yeah, makes no sense. This is a bug: the desktop integration packages must not contain direct references to program to keep the later relocatable - please file an issue for this. If this is also the case for 2.2, I would even consider this a stopper. - What are the ./share/xdg/*.desktop files (from various packages) used for? The desktop integration packages contain just symbolic links to those files (with the indirection of the dynamically created /etc/openoffice.org2.2 link). This is necessary to make a menu entry disappear if the user removes one of the applications. Regards, Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] [Fwd: [installation-dev] Updating to OOo 2.1 language packs]
Forwarding this to a broader audience since I did not get any replies yet. Please reply on [EMAIL PROTECTED] Thanks, Oliver Original Message Subject:[installation-dev] Updating to OOo 2.1 language packs Date: Wed, 25 Oct 2006 13:04:11 +0200 From: Oliver Braun [EMAIL PROTECTED] Reply-To: dev@installation.openoffice.org To: dev@installation.openoffice.org Hi *, with the move to the new numbering schema also the default installation directory changes from OpenOffice.org 2.0 to OpenOffice.org 2.1 resp. from openoffice.org2.0 to openoffice.org2.1. Assuming that users might have language packs installed in their OOs 2.0.x, the result when updating will be platform dependant: * on Windows, the installer will detect the existing 2.0.4 and propose OpenOffice.org 2.0 as destination directory instead = language packs still there, but potentially incompatible (might even lead to crashes). * on Unix, the default directory openoffice.org2.1 will be used, resulting in a naked OOo 2.1 with the language packs still present in openoffice.org2.0. Shouldn't we issue a warning on Windows and install to OpenOffice.org 2.1 by default as on Unix ? Users willing to take the risk might still choose the OpenOffice.org 2.0 manually. - Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] OOo Digital Signatures
Hi Malte, Malte Timmermann wrote: On other platforms there is no global key store, that's the reason why we have chosen to rely on a Mozilla profile. what about GNOME keyring, Apple KeyChain, .. ? I think this assumption is no longer valid. - Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] valgrind work
Caolan McNamara wrote: I see that there appears to be some valgrind work underway, at least in reporting valgrind warnings. Can I suggest that accessibility be enabled for these valgrind tests. I highly suspect there are a gadzillion valgrind-findable bugs exposed with enabling a11y :-( +1 Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Packaging process
Hi Rene, Rene Engelhard wrote: Kay Ramme - Sun Germany - Hamburg wrote: (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... I still don't see the problem here: who - beside package maintainers - would want to install _released_ vanilla OOo beside debian OOo on a single system ? How many users actually complained about this ? For milestone builds, ooo-dev is used for package names. And I thought we worked out a way to avoid incompatible mixtures of the two package sources. What I agree with being unfortunate is that we started with openofficeorg initially. We somehow expected the '.' to cause problems, but the ure package proved the opposite. Regards, Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Connecting to a Named Pipe on Linux
Stephan Bergmann wrote: Erdmann, Torsten wrote: Hi there, i tried to connect to ooo with a named pipe on a linux system: I started OpenOffice on a Linux System. It listens to a named Pipe. Now i tried with java to connect to this pipe. It only functions, if the java application, has been started as the same systemuser as OpenOffice has been started. Every other user (also root), can't establish a connection to this pipe. Is there a solution for this, or are there any permission problems on my System. The problem is that the pipe name FOOBAR at the uno-URL level uno;pipe,name=FOOBAR;urp is mapped to a Unix file name like /tmp/OSL_PIPE_uid_FOOBAR that includes the uid. That way, pipes for two different users cannot interfere (unlike sockets), but two different users cannot talk to one another, either. A somewhat broken design, I would say. FWIW: on the system (OSL) level, this happens only if the pipe is passed a security handle when created. Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
