Anyone able to provide a Mac OS X build of GNC with the DBI backends?
Hi all, I have recently migrated all my gnc data to a MySQL database on my server. The main reason behind this is I have an embedded device which I want to be access (read-only) the transaction data. Originally I began with SQLite3 which turned out has locking issues over the network so I migrated to MySQL which seems to work well. My primary PC is my linux machine for which I built GNC from source with the MySQL backend. However, I also have two Macbooks running Snow Leopard and Mountain Lion respectively, neither of which have development toolchains installed. As these have small SSDs I am not really wanting to install the whole xcode suite if not needed. I wonder if one of the maintainers of the mac port might be able to (please) build a .dmg with the MySQL backend compiled in (either 2.4 or 2.6 is fine) and post it on the home page? Many thanks in advance, Marcus Prebble Sweden ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Building gnucash 2.6.0 python bindings on Debian
On Thursday 16 January 2014 11:39:23 Bas ten Berge wrote:
Hi,
Since I'm posting to the list; there's a warning message when I
import
gnucash:
--
process:1075): GLib-WARNING **: GError
set over the top of a previous GError or uninitialized memory.
This indicates a bug in someone's code. You must ensure an error is
NULL before it's set.
The overwriting error message was: No such file or directory
--
Is there something I can do about this?
Getting rid of GLib-WARNING message appeared to be really simple. The
python-bindings - or a part thereof - were looking for the GNUCash
environment file, which was not installed. I guess it gets installed
when the gui is installed. I created a file named
/usr/local/etc/gnucash/environment containing only this:
---
[Variables] LANG=nl_NL LANGUAGE={LANG}
---
Thanks again, Bas
Ah. That would make sense. But the environment file normally sets up more
variables than only
LANG and LANGUAGE. Some of these may be relevant also for a properly
functioning gnucash.
I'm thinking in particular about the GUILE_LOAD_PATH and optionally
PYTHON_PATH. You may
have set these yourself manually already.
In any case for me it would make more sense to move the code to install the
environment file
to app_utils.
Please file this as an enhancement request in bugzilla so it won't get lost.
Thanks,
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 16/01/2014 15:38, Geert Janssens wrote: On Thursday 16 January 2014 15:06:55 Gary Bilkus wrote: On 16/01/2014 13:26, Geert Janssens wrote: Gary, While looking at your changes I noticed you changed two lines in the vbs script. One is that you added my repository/branch in a comment. That's ok and makes it easier for others to start. The second is to install msys-patch. Is there a reason you do this in the vbs script and not in install-impl.sh ? Geert Hi Geert. The reason I added in msys-patch to my version of your script is so that the instructions I posted on the wiki would work, since they tell you to run your vbs script and then run patch against the 2.6 repo with my patchfile, and that doesn't work if you don't yet have patch installed. Of course, as and when there's a git repo with the patches already incorporated, that step is no longer needed and nor is patch. But it doesn't do much harm to leave it around, and would make it easier for people who have to play catch-up the next time a downstream dependency gets broken. Gary Hi Gary, That makes sense. The reason I'm very cautious about adding stuff in the bootstrap script is that mingw-get is fairly fragile. The bootstrap script unconditionally installs the most recent version of the various packages, but in the install.sh script we force specific versions. If at some point the most recent version is more recent than what we explicitly set this will probably cause mingw-get to error out. That may or may not be bad but at least pretty confusing to new users. We may fix this by installing very specific versions in the bootstrap script already instead of the latest available. Although that approach risks that these versions will at some point get out of sync with the versions defined in defaults.sh. But IMO that is less of an issue. If this happens the installation script will update the packages to the proper versions without errors the first time it runs. I'll admit this is close to nitpicking. There are bigger issues to solve right now, but I mention it because now I noticed it. I will probably forget later on. Geert I completely understand the thinking. That said, I think patch is probably a pretty safe program to just download, given its longevity and stability at this point, compared to things like say the c compiler! ___ 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 16/01/2014 13:23, Geert Janssens wrote: On Thursday 16 January 2014 12:14:49 Gary Bilkus wrote: So just to make sure I understand exactly what you need. 1. I should get the gnucash.git repository from git://github.com:gjanssens/gnucash.git 2. I should git branch -t mingw origin/mingw-rebasing and check out that branch 3. I should appy my patches to that branch - ignoring any which are already there 4. I should run git diff to get a series of patches against the branch in the repository 5. I should split the resulting diff into different files relating to the different fixes 6. I should post the result somewhere and tell you where it is Gary Gary, That's close. But git's workflow is slightly different: 1 and 2 are correct 3. Apply your patches and ignore those that are already there is also correct. Then before committing anything it's worth considering which changes logically belong together and check these changes in in separate commits. 'git add -i' will be tremendously helpful for this part (adding changes into the index interactively). 4. Each time you have added a coherent set of changes to the index file, you can create a (local) commit using 'git commit'. You may want to use clear commit messages in this step as they will eventually end up in the master repository. You can look at my commits for examples but they're only that not hard rules. I suggest though that you explicitly add an author line in your commit message. Since we're still linked to the svn repo, git's author information gets lost for non-committers when we commit to the master repository. This line is in the form: Author: name email 5. When there are no more changes to commit, you can run 'git format-patch' to generate a series of patch files like so: git format-patch origin/mingw-rebasing That should generate the patch files in the current working directory. 6. The normal way to make these patches available to me is to create an enhancement request in bugzilla and attach the patches there. But in this case I'm equally fine if you post them to the list or tell me where you stored them on your own server or whatever. Geert 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. Gary ___ 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 Jan 17, 2014, at 5:57 AM, Gary Bilkus m...@gary.bilkus.com wrote: On 16/01/2014 13:23, Geert Janssens wrote: On Thursday 16 January 2014 12:14:49 Gary Bilkus wrote: So just to make sure I understand exactly what you need. 1. I should get the gnucash.git repository from git://github.com:gjanssens/gnucash.git 2. I should git branch -t mingw origin/mingw-rebasing and check out that branch 3. I should appy my patches to that branch - ignoring any which are already there 4. I should run git diff to get a series of patches against the branch in the repository 5. I should split the resulting diff into different files relating to the different fixes 6. I should post the result somewhere and tell you where it is Gary Gary, That's close. But git's workflow is slightly different: 1 and 2 are correct 3. Apply your patches and ignore those that are already there is also correct. Then before committing anything it's worth considering which changes logically belong together and check these changes in in separate commits. 'git add -i' will be tremendously helpful for this part (adding changes into the index interactively). 4. Each time you have added a coherent set of changes to the index file, you can create a (local) commit using 'git commit'. You may want to use clear commit messages in this step as they will eventually end up in the master repository. You can look at my commits for examples but they're only that not hard rules. I suggest though that you explicitly add an author line in your commit message. Since we're still linked to the svn repo, git's author information gets lost for non-committers when we commit to the master repository. This line is in the form: Author: name email 5. When there are no more changes to commit, you can run 'git format-patch' to generate a series of patch files like so: git format-patch origin/mingw-rebasing That should generate the patch files in the current working directory. 6. The normal way to make these patches available to me is to create an enhancement request in bugzilla and attach the patches there. But in this case I'm equally fine if you post them to the list or tell me where you stored them on your own server or whatever. Geert 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. Regards, John Ralls ___ 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 Jan 17, 2014, at 7:30 AM, John Ralls jra...@ceridwen.us wrote: On Jan 17, 2014, at 5:57 AM, Gary Bilkus m...@gary.bilkus.com wrote: On 16/01/2014 13:23, Geert Janssens wrote: On Thursday 16 January 2014 12:14:49 Gary Bilkus wrote: So just to make sure I understand exactly what you need. 1. I should get the gnucash.git repository from git://github.com:gjanssens/gnucash.git 2. I should git branch -t mingw origin/mingw-rebasing and check out that branch 3. I should appy my patches to that branch - ignoring any which are already there 4. I should run git diff to get a series of patches against the branch in the repository 5. I should split the resulting diff into different files relating to the different fixes 6. I should post the result somewhere and tell you where it is Gary Gary, That's close. But git's workflow is slightly different: 1 and 2 are correct 3. Apply your patches and ignore those that are already there is also correct. Then before committing anything it's worth considering which changes logically belong together and check these changes in in separate commits. 'git add -i' will be tremendously helpful for this part (adding changes into the index interactively). 4. Each time you have added a coherent set of changes to the index file, you can create a (local) commit using 'git commit'. You may want to use clear commit messages in this step as they will eventually end up in the master repository. You can look at my commits for examples but they're only that not hard rules. I suggest though that you explicitly add an author line in your commit message. Since we're still linked to the svn repo, git's author information gets lost for non-committers when we commit to the master repository. This line is in the form: Author: name email 5. When there are no more changes to commit, you can run 'git format-patch' to generate a series of patch files like so: git format-patch origin/mingw-rebasing That should generate the patch files in the current working directory. 6. The normal way to make these patches available to me is to create an enhancement request in bugzilla and attach the patches there. But in this case I'm equally fine if you post them to the list or tell me where you stored them on your own server or whatever. Geert 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. I'll add that this finesses The reason I added in msys-patch to my version of your script is so that the instructions I posted on the wiki would work, since they tell you to run your vbs script and then run patch against the 2.6 repo with my patchfile, and that doesn't work if you don't yet have patch installed. Of course, as and when there's a git repo with the patches already incorporated, that step is no longer needed and nor is patch. But it doesn't do much harm to leave it around, and would make it easier for people who have to play catch-up the next time a downstream dependency gets broken. because there's instantly a published git repository with the patches incorporated! Regards, John Ralls ___ 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 Jan 16, 2014, at 7:53 AM, Geert Janssens janssens-ge...@telenet.be wrote: On Thursday 16 January 2014 07:49:53 John Ralls wrote: On Jan 16, 2014, at 5:23 AM, Geert Janssens janssens-ge...@telenet.be wrote: 3. Apply your patches and ignore those that are already there is also correct. Then before committing anything it's worth considering which changes logically belong together and check these changes in in separate commits. 'git add -i' will be tremendously helpful for this part (adding changes into the index interactively). Pardon me for barging in. I just want to add that a git GUI makes it much less painful to pull diffs apart into commits compared to `git add -i`. TortoiseGit (http://code.google.com/p/tortoisegit/) works well on M$Windows. Regards, John Ralls Interesting. I never used a gui for this yet. Which one do you use on your mac ? I'd been using GitX [1], but it's pretty buggy and crash-prone, so I've lately switched to Atlassian Stash [2], which is free as in beer instead Free, but it hasn't yet crashed on me. On Linux I use gitx and giggle, both of which are in all of the package managers. Regards, John Ralls [1] http://gitx.org/ [2] https://www.atlassian.com/software/stash/overview ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Anyone able to provide a Mac OS X build of GNC with the DBI backends?
On Jan 16, 2014, at 1:25 PM, Marcus Prebble m.preb...@gmail.com wrote: Hi all, I have recently migrated all my gnc data to a MySQL database on my server. The main reason behind this is I have an embedded device which I want to be access (read-only) the transaction data. Originally I began with SQLite3 which turned out has locking issues over the network so I migrated to MySQL which seems to work well. My primary PC is my linux machine for which I built GNC from source with the MySQL backend. However, I also have two Macbooks running Snow Leopard and Mountain Lion respectively, neither of which have development toolchains installed. As these have small SSDs I am not really wanting to install the whole xcode suite if not needed. I wonder if one of the maintainers of the mac port might be able to (please) build a .dmg with the MySQL backend compiled in (either 2.4 or 2.6 is fine) and post it on the home page? That's Mac *maintainer*. There's only one. Sorry, no I won't. USB disks are cheap, get one and install Xcode there. Use your Snow Leopard machine, because if you build GnuCash on the Mountain Lion machine it won't work on Snow Leopard. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Windows Stack Traces
Somebody on the wxWidgets User list just mentioned https://code.google.com/p/jrfonseca/wiki/DrMingw, which includes an exception handling library that we could add to the Win32 builds. If it works as advertised, it would mean that Windows stack traces would be as easy as Mac ones. That would be a Good Thing. Anyone know of a similar package for Linux? Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Anyone able to provide a Mac OS X build of GNC with the DBI backends?
John Ralls jra...@ceridwen.us writes: On Jan 16, 2014, at 1:25 PM, Marcus Prebble m.preb...@gmail.com wrote: Hi all, I have recently migrated all my gnc data to a MySQL database on my server. The main reason behind this is I have an embedded device which I want to be access (read-only) the transaction data. Originally I began with SQLite3 which turned out has locking issues over the network so I migrated to MySQL which seems to work well. My primary PC is my linux machine for which I built GNC from source with the MySQL backend. However, I also have two Macbooks running Snow Leopard and Mountain Lion respectively, neither of which have development toolchains installed. As these have small SSDs I am not really wanting to install the whole xcode suite if not needed. I wonder if one of the maintainers of the mac port might be able to (please) build a .dmg with the MySQL backend compiled in (either 2.4 or 2.6 is fine) and post it on the home page? That's Mac *maintainer*. There's only one. Sorry, no I won't. USB disks are cheap, get one and install Xcode there. Use your Snow Leopard machine, because if you build GnuCash on the Mountain Lion machine it won't work on Snow Leopard. Also, GnuCash *IS* built with DBI support. You just need to supply the DBI MySQL Backend Driver (DBD). Regards, John Ralls -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH warl...@mit.eduPGP key available ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
doxygen config needs and update for F20
Hi, I've set up the new code server to build the docs, and it has the following output. I suspect we'll need to update the config, whch I will happily get to eventually unless someone else get to it first. -derek **Unmatched Entries** CMDOUT (Warning: Tag `SYMBOL_CACHE_SIZE' at line 278 of file doxygen.cfg has become obsolete.) CMDOUT (To avoid this warning please remove this line from your configuration file or upgrade it using doxygen -u) CMDOUT (Warning: Tag `SHOW_DIRECTORIES' at line 462 of file doxygen.cfg has become obsolete.) CMDOUT (To avoid this warning please remove this line from your configuration file or upgrade it using doxygen -u) CMDOUT (Warning: Tag `HTML_ALIGN_MEMBERS' at line 788 of file doxygen.cfg has become obsolete.) CMDOUT (To avoid this warning please remove this line from your configuration file or upgrade it using doxygen -u) CMDOUT (Warning: doxygen no longer ships with the FreeSans font.) CMDOUT (You may want to clear or change DOT_FONTNAME.) CMDOUT (Otherwise you run the risk that the wrong font is being used for dot generated graphs.) -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH warl...@mit.eduPGP key available ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Windows Stack Traces
John Ralls jra...@ceridwen.us writes: Somebody on the wxWidgets User list just mentioned https://code.google.com/p/jrfonseca/wiki/DrMingw, which includes an exception handling library that we could add to the Win32 builds. If it works as advertised, it would mean that Windows stack traces would be as easy as Mac ones. That would be a Good Thing. That sounds pretty cool! Anyone know of a similar package for Linux? The main issue is that on Linux most GnuCash doesn't ship with enough debug info to get a good crash dump. But I'm sure there are some tools available as some systems can send crash dumps automagically. Regards, John Ralls -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH warl...@mit.eduPGP key available ___ 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 Jan 17, 2014, at 7:39 AM, John Ralls jra...@ceridwen.us wrote: On Jan 16, 2014, at 7:53 AM, Geert Janssens janssens-ge...@telenet.be wrote: On Thursday 16 January 2014 07:49:53 John Ralls wrote: On Jan 16, 2014, at 5:23 AM, Geert Janssens janssens-ge...@telenet.be wrote: 3. Apply your patches and ignore those that are already there is also correct. Then before committing anything it's worth considering which changes logically belong together and check these changes in in separate commits. 'git add -i' will be tremendously helpful for this part (adding changes into the index interactively). Pardon me for barging in. I just want to add that a git GUI makes it much less painful to pull diffs apart into commits compared to `git add -i`. TortoiseGit (http://code.google.com/p/tortoisegit/) works well on M$Windows. Regards, John Ralls Interesting. I never used a gui for this yet. Which one do you use on your mac ? I'd been using GitX [1], but it's pretty buggy and crash-prone, so I've lately switched to Atlassian Stash [2], which is free as in beer instead Free, but it hasn't yet crashed on me. Oops, that’s wrong. It’s Atlassian SourceTree: http://www.sourcetreeapp.com/ Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
What (python) package on Fedora 19/20 to install to be able to import the _testcapi module to pass 'make check'
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 ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
