[dev] configure: error: Failed to find some (perl) modules
Erc Bachard wrote: I'd suggest you to install libarchive-zip-perl ( at least that's what apt-cache search answered me ) I did try to run apt-get install libarchive-zip-perl but then I got an error telling me: E: Package libarchive-zip-perl has no installation candidate I think the error relates to the repositories available in /etc/apt/sources.list but I have very little clue on what to change there Thank you lbrtchx // __ E: Package libarchive-zip-perl has no installation candidate ~ r...@knoppix:/media/hdb2/inst/sw/OO/source/OOO310_m19# apt-get install libarchive-zip-perl Reading package lists... Done Building dependency tree... Done Package libarchive-zip-perl is not available, but is referred to by another package. This may mean that the package is missing, has been obsoleted, or is only available from another source E: Package libarchive-zip-perl has no installation candidate ~ it seems to relate to thre number of repositories available in /etc/apt/sources.list ~ r...@knoppix:/media/hdb2/inst/sw/OO/source/OOO310_m19# cat /etc/apt/sources.list # /etc/apt/sources.list for Knoppix # If you want to do a full upgrade, you should first # upgrade the Packages from Debian/unstable (KDE Co.) # before doing a (dist-)upgrade for Debian/testing. # # See sources.list(5) for more information, especialy # Remember that you can only use http, ftp or file URIs # CDROMs are managed through the apt-cdrom tool. # Security updates for stable deb http://security.debian.org stable/updates main contrib non-free deb http://security.debian.org testing/updates main contrib non-free # Stable deb http://ftp.de.debian.org/pub/debian stable main contrib non-free # the non-US branch doesn't exist anymore since sarge. -KK # deb http://ftp.de.debian.org/pub/debian-non-US stable/non-US main contrib non-free # Stable Sources deb-src http://ftp.de.debian.org/pub/debian stable main contrib non-free # deb-src http://ftp.de.debian.org/pub/debian-non-US stable/non-US main contrib non-free # Testing deb http://ftp.de.debian.org/pub/debian testing main contrib non-free # deb http://ftp.de.debian.org/pub/debian-non-US testing/non-US main contrib non-free # Testing Sources deb-src http://ftp.de.debian.org/pub/debian testing main contrib non-free # deb-src http://ftp.de.debian.org/pub/debian-non-US testing/non-US main contrib non-free # Unstable deb http://ftp.de.debian.org/debian unstable main contrib non-free # deb http://ftp.de.debian.org/debian-non-US unstable/non-US main contrib non-free # Unstable Sources deb-src http://ftp.de.debian.org/debian unstable main contrib non-free # deb-src http://ftp.de.debian.org/debian-non-US unstable/non-US main contrib non-free # Experimental deb http://ftp.de.debian.org/debian experimental main contrib non-free # Experimental Sources #deb-src http://ftp.de.debian.org/debian ../project/experimental main contrib non-free # ndiswrapper source (disappeared, only source.tar available) # deb http://ndiswrapper.sourceforge.net/debian ./ # KDE 3.5 (not in sarge) # deb http://pkg-kde.alioth.debian.org/kde-3.5.0/ ./ # deb-src http://pkg-kde.alioth.debian.org/kde-3.5.0/ ./ # deb http://pkg-kde.alioth.debian.org/kde-3.4.1/ ./ # deb-src http://pkg-kde.alioth.debian.org/kde-3.4.1/ ./ # Wine deb http://wine.sourceforge.net/apt/ binary/ # deb-src http://wine.sourceforge.net/apt/ source/ # Unichrome graphics driver # deb http://www.physik.fu-berlin.de/~glaweh/debian/ unichrome/ # deb-src http://www.physik.fu-berlin.de/~glaweh/debian/ unichrome/ # NX stuff # deb http://www.kalyxo.org/debian/ experimental main # deb http://www.kalyxo.org/debian/ unstable main # ndiswrapper # deb http://rigtorp.se/debian unstable/ # deb-src http://rigtorp.se/debian unstable/ # Blades Repository (pppoeconf co) # deb http://people.debian.org/~blade/testing ./ # deb-src http://people.debian.org/~blade/testing ./ # deb cdrom:[Debian GNU/Linux 2.2 r3 _Potato_ - Official i386 Binary-1 (20010427)]/ unstable contrib main non-US/contrib non-US/main # Knoppix special packages resource at LinuxTag HQ # deb http://developer.linuxtag.net/knoppix ./ # deb-src http://developer.linuxtag.net/knoppix ./ # deb http://snapshot.debian.net/archive pool gcc # deb-src http://snapshot.debian.net/archive pool gcc # From the Kanotix archives # deb http://kanotix.com/files/debian/ ./ # deb-src http://kanotix.com/files/debian/ ./ # NX Server # deb http://debian.tu-bs.de/project/kanotix/unstable/ sid nx # deb-src http://debian.tu-bs.de/project/kanotix/unstable/ sid nx # NX Client (binary-only, non-free) # deb http://kanotix.com/files/debian/ sid main contrib non-free # Packages from ubuntu. CAUTION, they don't mix well with Debian # deb http://de.archive.ubuntu.com/ubuntu hoary main universe multiverse # deb-src http://de.archive.ubuntu.com/ubuntu hoary main universe multiverse # Unofficial packages, like JAVA # deb ftp://ftp.debian-unofficial.org/debian/ stable main contrib non-free restricted # deb-src
Re: [dev] OpenOffice Calc in the Financial Markets.
On 11/15/09 17:28, Cassio Neri wrote: What are the issues with OOo Calc and what could be done? Please, forgive me if I'm wrong, but I think: 1. Currently, there is no way to recalculate all changed formulas in current sheet. Although the documentation says that F9 does so, in fact, it doesn't. I've recently reported this bug http://qa.openoffice.org/issues/show_bug.cgi?id=105743 I'm working on this issue and I going to submit a patch. With this patch F9 recalculates all changed formulas in current sheet. This is in accordance with OOo documentation. However it's in opposition with my own suggestion in the bug report (that is, to use Shift+F9 as in Excel). I've changed my mind because I found many places (in the web and in OOo help) stating this behavior for F9. I'll come back to this issue below. I'm not sure if it's good to change the existing behavior of F9 this way. In fact we have a request to include external references in F9 (see issue 29370), so maybe adding a new shortcut for current-sheet-only would be better. 2. As far as I know, there are no volatile functions in OpenOffice add-ins. Of course, the OOo API allows add-in functions to return volatile results. This is much more powerful than what we need and consequently more complex to implement. All we need is to tell OOo that some formulas must always be considered out of date even if they don't seem to be. Recall that in Excel, Shift+F9 recalculates all changed formulas in the current sheet. Since for the add-ins that I'm considering all functions are volatile, it implies that Shift+F9 recalculates all (add-in) formulas in current sheet. Therefore, we can avoid any change in the OOo API while keeping the same user's felling provided that Shift+F9 recalculates all cells in the current sheet. I hope I can make a patch for that. We have the open issue 69903 for this. It's not a matter of a simple patch, because we need a way for an add-in to signal that a function should always be recalculated. Having considered issues 1 and 2 above, in a more general way, we have issue number 3: 3. The majority of users work with automatic calculation turned on. For this reason, I guess, OOo is not very well tested when automatic calculation is turned off. I already found and reported another bug in this set up. http://qa.openoffice.org/issues/show_bug.cgi?id=106135 Yes, thanks for reporting it. 4. Sometimes, we want to recalculate just one cell which calls an add-in function. In Excel it's enough to double click on the cell to start it's edition and then press Enter without modifying anything. I don't really know if Excel recalculates anyway or only because the add-in function is volatile. OOo realizes that we haven't change anything it doesn't recalculate. That's not a big issue. A simple workaround is to make a fake change (e.g. one can press LeftArrow before pressing Enter). Unfortunately, it doesn't work when the result is an array. That's a big issue. I would like to report a bug but I can't give a simple way to reproduce it. The problem is that I have to provide the complete code for an add-in. The is not a simple task: The simplest add-in I can think of requires 4 files (one C++, one IDL and two XML) and complicated instructions on how to build it. For an array formula, you have to select the array, edit the formula, move the text cursor, then press Shift-Ctrl-Enter to input an array formula again. Yes, it's a bit cumbersome. Maybe we also need an explicit way to recalculate single formulas, or formulas in a selection. Niklas - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] configure: error: Failed to find some (perl) modules
On Sat, 14 Nov 2009 19:17:40 -0500 Albretch Mueller lbrt...@gmail.com wrote: I am trying to run config like that (from within a script) but I an stumbling on some missing perl modules: [...] checking for perl... /usr/bin/perl checking the Perl version... checked (perl 5) checking for required Perl modules... Can't locate Archive/Zip.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.8.8 /usr/local/share/perl/5.8.8 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.8 /usr/share/perl/5.8 /usr/local/lib/site_perl .) at -e line 1. BEGIN failed--compilation aborted at -e line 1. configure: error: Failed to find some modules I thought --enable-verbosity was going to give me more information but there are a lot of packages here: http://packages.debian.org/stable/perl/ which ones do I need to install in order to configure OO? in general, see: http://wiki.services.openoffice.org/wiki/Category:Distribution-Specific_Build_Instructions for the package names of the prerequisities on different distros. Best Regards, Bjoern -- === Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht Muenchen: HRB 161028 Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Wolf Frenkel Vorsitzender des Aufsichtsrates: Martin Haering === - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] Build System and visibility
Hi List, again some stuff from the Build Environment Effort(1). While figuring out the way we build libraries with the OpenOffice.org build system it became apparent that we seem to have way to many redundant ways to set the visibility of functions. From the top of my head: - map files - explicitly setting a compiler flag in the make file - XX_DLL_EXPORT/XX_DLL_IMPORT/XX_DLL_PRIVATE and friends However, using the XX_DLL_PRIVATE and friends should be enough for everyone, right? So, it should be possible to simplify the build by only using XX_DLL_PRIVATE and friends, or does anybody see a use case that is not covered by it? If so, I would like to hear it ... ;-) Best Regards, Bjoern (1) http://wiki.services.openoffice.org/wiki/Build_Environment_Effort -- === Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht Muenchen: HRB 161028 Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Wolf Frenkel Vorsitzender des Aufsichtsrates: Martin Haering === - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Getting rid of implicit dependencies on default_images
On Friday 13 November 2009, bjoern michaelsen - Sun Microsystems - Hamburg Germany wrote: Hi List, While working on the Build Environment Effort(1), we stumbled over the implicit dependency of all modules generating resource files on default_images. The resource compiler digs into the default_images directory for the files specified in the *.src/*.hrc files. However, since there is no need for rsc to actually read the file contents when generating *.res files, the dependency is much heavier than needed. After all, everything rsc needs to know is _if_ there is a file with a given name, but not its contents. To get rid of this dependency, we are considering to simply generate a file containing the dirstate of default_images (for example the output of find default_images) and put that in the solver. rsc would use the contents of that file, and would not try to search default_images directly. This would: - reduce dependencies - for example allow to build sw without having a complete default_images around - ease further efforts like split build/better support for full deps Opinions? Interesting idea. The only question is how to generate the list of images. It can't be generated during build because it will not remove the cyclic build dependency. So, you would need to generate it offline which is a bit error prone. Another possibility would be to hack rsc to generate a list of used images and deliver these lists into the solver. The module default_images might be built as a last module and it might check all those delivered lists and throw an error/warning when am image was used but it is not available. -- Best Regards, Petr Mladek software developer - SUSE LINUX, s. r. o.e-mail: pmla...@suse.cz Lihovarská 1060/12 tel: +420 284 028 952 190 00 Prague 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] OpenOffice Calc in the Financial Markets.
Hi Juergen and Niklas. Yes, I would love to see OpenOffice in the financial markets. However, as always, the problem is the inertia: people are not very keen to change. Unfortunately, the company I work for is a very big one and I don't have any influence in those types of decision. I can only just advertise OpenOffice to my colleagues (which I do). Thanks for the information on the NetBeans plugin. I will consider this possibility. I wasn't very clear in my explanation. Let me try again: I'm not sure if it's good to change the existing behavior of F9 this way. In fact we have a request to include external references in F9 (see issue 29370), so maybe adding a new shortcut for current-sheet-only would be better. That was my first thought (I don't have any personal preference for F9). However, as I said in my bug report (issue #105743) the OOo help states (more than once) that F9 recalculates all changed formulas in the CURRENT sheet. Moreover, this is also said in a few places in the website, e.g., 1) http://wiki.services.openoffice.org/wiki/Documentation/OOo3_User_Guides/Calc_Guide/Function_key_shortcuts 2) http://documentation.openoffice.org/manuals/oooauthors2/0313CG-KeyboardShortcuts.pdf and, I guess, in some printed books as well. Therefore, the patch I've submitted changes the code to conciliate it with the documentation in eletronic and hard-copy format. Regarding issue 29370, as far as I understand, it's related more on how each cell is recalculated (method ScFormulaCell::Interpret) than whether it's in the current sheet or not. 2. As far as I know, there are no volatile functions in OpenOffice add-ins. Of course, the OOo API allows add-in functions to return volatile results. This is much more powerful than what we need and consequently more complex to implement. All we need is to tell OOo that some formulas must always be considered out of date even if they don't seem to be. Recall that in Excel, Shift+F9 recalculates all changed formulas in the current sheet. Since for the add-ins that I'm considering all functions are volatile, it implies that Shift+F9 recalculates all (add-in) formulas in current sheet. Therefore, we can avoid any change in the OOo API while keeping the same user's felling provided that Shift+F9 recalculates all cells in the current sheet. I hope I can make a patch for that. We have the open issue 69903 for this. It's not a matter of a simple patch, because we need a way for an add-in to signal that a function should always be recalculated. Yes, I came across this issue before but I couldn't find it again. It was exactly this that I had in mind when I said there are no volatile functions in OpenOffice add-ins. I do understand that this is a complicated matter that, probably, implies a change in the UNO API. However, this is not the intention of the patch I'm talking about. What I have in mind is implement a short-cut, say Shift+F9, to recalculate ALL cells in the CURRENT sheet (regardless if the formula contains add-in or built-in functions). The patch would implement a method to do more or less what ScDocumen::CalcAll does but eliminating the loop which goes though all sheets. It would rather do the job only in the current sheet. For an array formula, you have to select the array, edit the formula, move the text cursor, then press Shift-Ctrl-Enter to input an array formula again. Yes, it's a bit cumbersome. Maybe we also need an explicit way to recalculate single formulas, or formulas in a selection. What I meant here was that this exact instructions don't work. I haven't filled a issue for that one because for me it's difficult to reproduce the bug without the help of an add-in (possibly, it only happens with add-in functions). I do have implemented an add-in which shows the problem but, as I said, it would be hard to submit the add-in code and all the complementary files need to produce a .oxt file. Anyway, what happens when I follow your instructions is that the add-in function is not called and the whole array is filled with blanks. The only way to make the right result appears is pressing either F9 (after a change) or Shift+Ctrl+F9. To finish... All I'm saying happens when automatic calculation is turned off. Best regards, Cassio. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Getting rid of implicit dependencies on default_images
Petr Mladek wrote: On Friday 13 November 2009, bjoern michaelsen - Sun Microsystems - Hamburg Germany wrote: Hi List, While working on the Build Environment Effort(1), we stumbled over the implicit dependency of all modules generating resource files on default_images. The resource compiler digs into the default_images directory for the files specified in the *.src/*.hrc files. However, since there is no need for rsc to actually read the file contents when generating *.res files, the dependency is much heavier than needed. After all, everything rsc needs to know is _if_ there is a file with a given name, but not its contents. To get rid of this dependency, we are considering to simply generate a file containing the dirstate of default_images (for example the output of find default_images) and put that in the solver. rsc would use the contents of that file, and would not try to search default_images directly. This would: - reduce dependencies - for example allow to build sw without having a complete default_images around - ease further efforts like split build/better support for full deps Opinions? Interesting idea. The only question is how to generate the list of images. It can't be generated during build because it will not remove the cyclic build dependency. So, you would need to generate it offline which is a bit error prone. There is no cyclic dependency, only a small unesthetic ;-) workflow: we have the images repository whose dev package contains the directory listings. In our build environment it means that the solver will contain them. All resource files with image lists will include this listing. This happens while building the common, gui, framework etc. packages. In the final package, where global office stuff is built will create images.zip. The only dirty treatment is that images zip can't be built from a dev package, it requires the presence of two repositories (build and images) in the final package build. I think this is bearable. It's definitely better as today where even the rsc circumvents solver or dev packages while building resource containing images lists. Another possibility would be to hack rsc to generate a list of used images and deliver these lists into the solver. The module default_images might be built as a last module and it might check all those delivered lists and throw an error/warning when am image was used but it is not available. Yes, that would be less dirty. The only argument against that is missing images are detected late, not while the packages containing the image lists are built. We need to find out if that will be accepted. IMHO it would also be a good solution. Regards, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to nospamfor...@gmx.de. I use it for the OOo lists and only rarely read other mails sent to it. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
