Re: What (python) package on Fedora 19/20 to install to be able to import the _testcapi module to pass 'make check'
On Friday 17 January 2014 18:43:20 Alex Aycinena wrote: Geert, I see you were asking this question on IRC back in Nov, I'm getting the same test failures you reported then on my Fedora 19. Did you ever resolve it? Thanks, Alex Hi Alex, Yes I eventually got past this - didn't I report this on IRC as well ? Anyway, on Fedora you need to install the python-test package. I have also created a bugreport[1] against gnucash for this. It should check for the presence of the _testcapi if python bindings are enabled. Geert [1] https://bugzilla.gnome.org/show_bug.cgi?id=712301 ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Building on Windows from scratch - guile problem SOLVED
On Friday 17 January 2014 07:30:00 John Ralls wrote: OK Geert, I think I have what you want at http://www.greenwheel.com/publicFiles/rebase-patches.zip Let me know if this works for you. Not being a git expert, it's possible I've not quite done the right thing, but I think this should be OK. As another option, perhaps the most git-ish (sorry) of all, would be for Gary to get a (free) Github account, fork Geert's repo, make his branch, push that back to *his* repo, and then from Github send Geert a pull request. I know I've argued against allowing this in the past, but I'm coming around to the idea that we need to make it easier for folks to offer patches. Heh, I didn't want to propose this exactly because of your opposition in the past. But I have been thinking of leveraging github's pull requests as well. I see for example that swig is using this approach rather succesfully. I can imagine that a project the size of a linux kernel needs some stricter rules to keep organized. But GnuCash is pretty small in comparison. Reminds me we still have to discuss our future branching strategy, but that's for another thread. Back to the patches at hand: Gary, I tried to download the zip file you made available, but I get a permission error on that website. Can you check that ? Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Building on Windows from scratch - guile problem SOLVED
On 18/01/2014 09:53, Geert Janssens wrote: On Friday 17 January 2014 07:30:00 John Ralls wrote: OK Geert, I think I have what you want at http://www.greenwheel.com/publicFiles/rebase-patches.zip Let me know if this works for you. Not being a git expert, it's possible I've not quite done the right thing, but I think this should be OK. As another option, perhaps the most git-ish (sorry) of all, would be for Gary to get a (free) Github account, fork Geert's repo, make his branch, push that back to *his* repo, and then from Github send Geert a pull request. I know I've argued against allowing this in the past, but I'm coming around to the idea that we need to make it easier for folks to offer patches. Heh, I didn't want to propose this exactly because of your opposition in the past. But I have been thinking of leveraging github's pull requests as well. I see for example that swig is using this approach rather succesfully. I can imagine that a project the size of a linux kernel needs some stricter rules to keep organized. But GnuCash is pretty small in comparison. Reminds me we still have to discuss our future branching strategy, but that's for another thread. Back to the patches at hand: Gary, I tried to download the zip file you made available, but I get a permission error on that website. Can you check that ? Geert Sorry Geert, forgot to add read perms to the file. Should be OK now. Gary ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: What (python) package on Fedora 19/20 to install to be able to import the _testcapi module to pass 'make check'
Thanks Geert. Alex On Sat, Jan 18, 2014 at 1:46 AM, Geert Janssens janssens-ge...@telenet.bewrote: On Friday 17 January 2014 18:43:20 Alex Aycinena wrote: Geert, I see you were asking this question on IRC back in Nov, I'm getting the same test failures you reported then on my Fedora 19. Did you ever resolve it? Thanks, Alex Hi Alex, Yes I eventually got past this - didn't I report this on IRC as well ? Anyway, on Fedora you need to install the python-test package. I have also created a bugreport[1] against gnucash for this. It should check for the presence of the _testcapi if python bindings are enabled. Geert [1] https://bugzilla.gnome.org/show_bug.cgi?id=712301 ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: r23705 - gnucash/trunk/src - Bug 605991 Help button on New and Edit Job dialogs brings up wrong help page. With this patch I linked almost all business features to corresponding help pages. For fe
On Saturday 18 January 2014 13:47:53 Cristian Marchi wrote: Author: cmarchi Date: 2014-01-18 13:47:52 -0500 (Sat, 18 Jan 2014) New Revision: 23705 Trac: http://svn.gnucash.org/trac/changeset/23705 Modified: gnucash/trunk/src/business/business-gnome/dialog-customer.c gnucash/trunk/src/business/business-gnome/dialog-employee.c gnucash/trunk/src/business/business-gnome/dialog-invoice.c gnucash/trunk/src/business/business-gnome/dialog-job.c gnucash/trunk/src/business/business-gnome/dialog-order.c gnucash/trunk/src/business/business-gnome/dialog-vendor.c gnucash/trunk/src/gnome-utils/gnc-ui.h gnucash/trunk/src/plugins/bi_import/dialog-bi-import-gui.c gnucash/trunk/src/plugins/customer_import/dialog-customer-import-gui. c Log: Bug 605991 Help button on New and Edit Job dialogs brings up wrong help page. With this patch I linked almost all business features to corresponding help pages. For features not yet documented, the button will open the initial chapter of the business section. ___ gnucash-patches mailing list gnucash-patc...@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-patches Ah, that's a great improvement. Thanks ! Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Translation policy
Am Dienstag, 14. Januar 2014, 13:42:13 schrieb John Ralls: I've updated http://wiki.gnucash.org/wiki/Translation_Status accordingly. Also, as 2.6.0 is out the door, we are not in string freeze anymore. Just commit whatever you think you'd like to do. (Yes, I know this has some drawbacks as well, but a formal string freeze on the branch for the releases really only makes sense if we have two branches, so that the string-breaking patch can always go into the unstable branch. As we don't have a separate unstable branch at this point in time, all patches can go into trunk.) No, all patches can not go into trunk/master. Bug fixes only until we branch 2.6. If you have some new feature that you just can’t wait to get started on, by all means get started, but do it in a branch in your own repository. I was talking about translations. With respect to translations and user message changes, indeed all patches can go into trunk/master. The question of new feature development is a different matter, though. Regards, Christian You can merge it into master after we branch 2.6. There are lots of bugs to work on, so work on them and commit the fixes to trunk. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: base-typemaps.i and budgets
Am Donnerstag, 16. Januar 2014, 15:52:49 schrieb David Osguthorpe: This appears to be a problem in the swig out typemap in base-typemaps.i for GList type structures. This typemap is defined differently for python versus scheme - here Im specifically dealing with the Python version. ... The problem found returning budgets is that this matches any arbitrary GList whose type is not defined in the previous else if components of the if structure, hence a list of budgets is returned as a list of gnc_monetary type. I think this is an error of the swig description. To me it sounds someone added the mapping for the GListgnc_monetary (C++ notation) for whatever reason, and that person didn't notice that this mapping ends up as a catch-all for other functions that contain a GList in their definition. Question is why is this routine defined for various specific types eg CommodityList *, SplitList *, AccountList *, LotList *, PriceList *, EntryList * where it seems to me the elements must always be of a specific type. I *thought* this is the desparate attempt to map the programmer's knowledge that a specific GList contains only commodity pointers into the correctly typed python container. This lack of templated container types is one of the bigger bummers of our core API. Instead, every container is a GList* and if we're lucky, it contains the type we are expecting :-) Also, returning a void type for untested element types would seem to me to be better than returning a wrong type for a generic GList (it may be possible to re-map the swig void type in python later). Absolutely. If we don't know anything, we can only return a void type. However, in almost all usages of GList throughout gnucash the actual value type is known and hopefully at least mentioned in that function's documentation (a GList containing xy). In C/glib, unfortunately that's about all that is possible. Regards, Christian ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: r23706 - gnucash/trunk/src/register/ledger-core - Bug 721791 - Segmentation fault when correcting invalid date
Am Samstag, 18. Januar 2014, 16:50:22 schrieb John Ralls: Author: jralls Date: 2014-01-18 16:50:21 -0500 (Sat, 18 Jan 2014) New Revision: 23706 Trac: http://svn.gnucash.org/trac/changeset/23706 Modified: gnucash/trunk/src/register/ledger-core/split-register-model.c Log: Bug 721791 - Segmentation fault when correcting invalid date And greatly simplify gnc_split_register_get_date_help by just getting a GDate and running g_date_strftime on it instead of messing around with Timespecs and g_localtime_r (twice!) and all of that just to make a stupid string. Thanks for fixing the bug! Note that the functions for using the GDate are still relatively new in gnucash. That's why in most cases they are not (yet) being used, even though they are more suitable and less error-prone and better altogether :-) Regards, Christian ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: r23706 - gnucash/trunk/src/register/ledger-core - Bug 721791 - Segmentation fault when correcting invalid date
On Jan 18, 2014, at 2:47 PM, Christian Stimming christ...@cstimming.de wrote: Am Samstag, 18. Januar 2014, 16:50:22 schrieb John Ralls: Author: jralls Date: 2014-01-18 16:50:21 -0500 (Sat, 18 Jan 2014) New Revision: 23706 Trac: http://svn.gnucash.org/trac/changeset/23706 Modified: gnucash/trunk/src/register/ledger-core/split-register-model.c Log: Bug 721791 - Segmentation fault when correcting invalid date And greatly simplify gnc_split_register_get_date_help by just getting a GDate and running g_date_strftime on it instead of messing around with Timespecs and g_localtime_r (twice!) and all of that just to make a stupid string. Thanks for fixing the bug! Note that the functions for using the GDate are still relatively new in gnucash. That's why in most cases they are not (yet) being used, even though they are more suitable and less error-prone and better altogether :-) And one of the GLib dependencies that we're getting rid of. ;-) No worries, though: Boost::gregorian [1] has more-or-less the same functionality with I hope less work. Regards, John Ralls [1] http://www.boost.org/doc/libs/1_55_0/doc/html/date_time/gregorian.html#date_time.gregorian.date_class ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
configure has difficulty finding libgoffice
I downloaded the source for gnucash about an hour ago. I'm running ./configure and this is the end of the output - showing problem: .. .. checking for gdk-pixbuf-2.0... yes checking GDK_PIXBUF_CFLAGS... -pthread -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libpng15 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include checking GDK_PIXBUF_LIBS... -lgdk_pixbuf-2.0 -lgobject-2.0 -lglib-2.0 checking for libgoffice-0.8 = 0.7.0... no configure: error: Cannot find libgoffice.= 0.7.0 [user1@hoho6 gnucash-2.6.0]$ If I search for libgoffice, it looks like I have both libgoffice-0.8 and libgoffice-0.10 [user1@hoho6 gnucash-2.6.0]$ ls -l /usr/lib64/libgoffice* lrwxrwxrwx. 1 root root 25 Jan 19 00:33 /usr/lib64/libgoffice-0.10.so - libgoffice-0.10.so.10.0.9 lrwxrwxrwx. 1 root root 25 Jan 19 00:33 /usr/lib64/libgoffice-0.10.so.10 - libgoffice-0.10.so.10.0.9 -rwxr-xr-x. 1 root root 1692040 Jan 1 11:15 /usr/lib64/libgoffice-0.10.so.10.0.9 lrwxrwxrwx. 1 root root 24 Jul 5 2013 /usr/lib64/libgoffice-0.8.so.8 - libgoffice-0.8.so.8.0.17 -rwxr-xr-x. 1 root root 1376096 Feb 14 2013 /usr/lib64/libgoffice-0.8.so.8.0.17 [user1@hoho6 gnucash-2.6.0]$ My system is Fedora19 I have gnucash 2.4, which is the latest available through the yum install gnucash distribution. I was hoping to be able to use the latest and greatest 2.6 series. Bob G ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: configure has difficulty finding libgoffice
--On January 19, 2014 1:21:50 AM -0600 Bob Gustafson bob...@rcn.com wrote: I downloaded the source for gnucash about an hour ago. I'm running ./configure and this is the end of the output - showing problem: What does pkg-config --modversion libgoffice-0.8 print? You may need to set PKG_CONFIG_PATH or possibly PKG_CONFIG in your environment before running config. Mike ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
