Relink warnings
When I build Gnucash from svn trunk, I always get relink warnings during make install. Why are these happening exactly ? And can they be avoided ? They make my change-build-install-test cycle dog slow. Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
String freeze
Is trunk in string freeze already ? I am about to commit a patch that adds 3 new translatable strings. Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: String freeze
Zitat von Geert Janssens janssens-ge...@telenet.be: Is trunk in string freeze already ? I am about to commit a patch that adds 3 new translatable strings. No, trunk is (still) not yet in string freeze. There have been approx. 20 changed or new strings between 2.3.7 and 2.3.8, mostly because the time interval turned out so large. So just go ahead and add further strings, if they improve the program (which I guess they do). Regards. Christian ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: String freeze
On Wednesday 9 December 2009, Christian Stimming wrote: No, trunk is (still) not yet in string freeze. There have been approx. 20 changed or new strings between 2.3.7 and 2.3.8, mostly because the time interval turned out so large. So just go ahead and add further strings, if they improve the program (which I guess they do). Regards. Christian On Wednesday 9 December 2009, Phil Longstaff wrote: No, it is not in string freeze, though I think the next release (2.3.9) should include a freeze. Go ahead. Phil Ok, thanks guys. I have just committed a patch that adds tooltips to the payment dialog. Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Payment dialog proposal
On Tuesday 8 December 2009, Derek Atkins wrote: But a tooltip is good too. The Invoice/Bill to assign this payment to. Note that is field is optional. If you leave it blank, GnuCash will automatically assign the payment to the first unpaid invoice/bill for this customer/vendor. Can't you make the tooltip dependent on the underlying type? The labels change, why not the tooltip too based on the underlying one? I just committed a patch that adds tooltips that use the proper terms for each type. I chose to add tooltips for the owner, invoice and amount widgets, with invoice and amount having some additional information that shows the invoice selection is optional. Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: String freeze
No, it is not in string freeze, though I think the next release (2.3.9) should include a freeze. Go ahead. Phil From: Geert Janssens janssens-ge...@telenet.be To: gnucash-devel@gnucash.org Sent: Wed, December 9, 2009 9:50:41 AM Subject: String freeze Is trunk in string freeze already ? I am about to commit a patch that adds 3 new translatable strings. Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Bugzilla access
I was browsing through the GnuCash bugs and wanted to modify some bugs (mark bug 583155 as a duplicate of bug 430187 and update version of bug 430187), but I can't. Can I be allowed to make such changes, or should I just ask on the list ? If I can be allowed, are there some rules or guidelines to follow on processing bugs ? Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Bugzilla access
Zitat von Geert Janssens janssens-ge...@telenet.be: I was browsing through the GnuCash bugs and wanted to modify some bugs (mark bug 583155 as a duplicate of bug 430187 and update version of bug 430187), but I can't. Right, your e-mail address is not in the list of names who are marked as Developers of Gnucash in bugzilla (approx. 20 gnucash right now). Can I be allowed to make such changes, or should I just ask on the list ? Which e-mail address do you use inside bugzilla? I tried to find your account there before but I couldn't. Just tell me the name and I'll add you to the developer list. If I can be allowed, are there some rules or guidelines to follow on processing bugs ? No (other than the common bugzilla recommendations), just go ahead. Regards, Christian ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Bugzilla access
On Wednesday 9 December 2009, Christian Stimming wrote: Zitat von Geert Janssens janssens-ge...@telenet.be: I was browsing through the GnuCash bugs and wanted to modify some bugs (mark bug 583155 as a duplicate of bug 430187 and update version of bug 430187), but I can't. Right, your e-mail address is not in the list of names who are marked as Developers of Gnucash in bugzilla (approx. 20 gnucash right now). Can I be allowed to make such changes, or should I just ask on the list ? Which e-mail address do you use inside bugzilla? I tried to find your account there before but I couldn't. Just tell me the name and I'll add you to the developer list. Sorry, I meant to add that I was using a different email address in bugzilla. It's i...@kobaltwit.be If I can be allowed, are there some rules or guidelines to follow on processing bugs ? No (other than the common bugzilla recommendations), just go ahead. Ok, thanks, I will use common sense where possible and ask if in doubt ;) Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Bugzilla access
I see 'janssensjo...@telenet.be', but not 'janssens-ge...@telenet.be'. What is your bugzilla account name and/or e-mail? Phil From: Geert Janssens janssens-ge...@telenet.be To: gnucash-devel@gnucash.org Sent: Wed, December 9, 2009 10:51:16 AM Subject: Bugzilla access I was browsing through the GnuCash bugs and wanted to modify some bugs (mark bug 583155 as a duplicate of bug 430187 and update version of bug 430187), but I can't. Can I be allowed to make such changes, or should I just ask on the list ? If I can be allowed, are there some rules or guidelines to follow on processing bugs ? Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
MacOSX builds of 2.3.X
I guess this is mostly for John Ralls who seems to be providing the 2.2.9 native MacOSX builds. I just recently clued in that I am not doing anything to synchronize with you so that a native macosx build of 2.3.X could be uploaded to sourceforge along with the win32 build so that we would provide tarballs, win32 setup.exe and mac .dmg at the same time. This assumes, of course, that mac 2.3.X builds are possible :) How do you want to coordinate? Shall I just send you an e-mail? Do you have a daily svn build so that if 2.3.X is tagged, you can easily produce a .dmg? Phil ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Bugzilla access
OK - try now. From: Geert Janssens janssens-ge...@telenet.be To: Christian Stimming stimm...@tuhh.de Cc: gnucash-devel@gnucash.org Sent: Wed, December 9, 2009 11:27:23 AM Subject: Re: Bugzilla access On Wednesday 9 December 2009, Christian Stimming wrote: Zitat von Geert Janssens janssens-ge...@telenet.be: I was browsing through the GnuCash bugs and wanted to modify some bugs (mark bug 583155 as a duplicate of bug 430187 and update version of bug 430187), but I can't. Right, your e-mail address is not in the list of names who are marked as Developers of Gnucash in bugzilla (approx. 20 gnucash right now). Can I be allowed to make such changes, or should I just ask on the list ? Which e-mail address do you use inside bugzilla? I tried to find your account there before but I couldn't. Just tell me the name and I'll add you to the developer list. Sorry, I meant to add that I was using a different email address in bugzilla. It's i...@kobaltwit.be If I can be allowed, are there some rules or guidelines to follow on processing bugs ? No (other than the common bugzilla recommendations), just go ahead. Ok, thanks, I will use common sense where possible and ask if in doubt ;) Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Undocumented? Close book
Hi, Parker Jones zoubi...@hotmail.com writes: Thanks David, that does help a lot.Especially the tip about reports. I can see a problem with my usage because my partner also uses the same accounts. She might occasionally make changes without realising that zeroing transactions need updating and I might not notice her changes, thus leaving the books out of sync. I suppose I'll have to re-close books regularly to be safe. For the record, I never close the books. I don't see a reason to. All the reports are designed to handle periods, so really the only thing that closing the books gives you is the ability to look at the account balances in the Chart of Accounts to see this period's balance. But if you use the reports for that info then you don't need to ever close the books. -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: Bugzilla access
Indeed it works, thanks. Geert On Wednesday 9 December 2009, Phil Longstaff wrote: OK - try now. From: Geert Janssens janssens-ge...@telenet.be To: Christian Stimming stimm...@tuhh.de Cc: gnucash-devel@gnucash.org Sent: Wed, December 9, 2009 11:27:23 AM Subject: Re: Bugzilla access On Wednesday 9 December 2009, Christian Stimming wrote: Zitat von Geert Janssens janssens-ge...@telenet.be: I was browsing through the GnuCash bugs and wanted to modify some bugs (mark bug 583155 as a duplicate of bug 430187 and update version of bug 430187), but I can't. Right, your e-mail address is not in the list of names who are marked as Developers of Gnucash in bugzilla (approx. 20 gnucash right now). Can I be allowed to make such changes, or should I just ask on the list ? Which e-mail address do you use inside bugzilla? I tried to find your account there before but I couldn't. Just tell me the name and I'll add you to the developer list. Sorry, I meant to add that I was using a different email address in bugzilla. It's i...@kobaltwit.be If I can be allowed, are there some rules or guidelines to follow on processing bugs ? No (other than the common bugzilla recommendations), just go ahead. Ok, thanks, I will use common sense where possible and ask if in doubt ;) Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: PERLINC in gnc-fq-*
John Ralls jra...@ceridwen.us writes:
A user complained in gnucash-users that gnc-fq-check failed on him
because of the line use lib
/System/Library/Perl/5.8.8/darwin-thread-multi-2level. The directory
gets inserted at build time from running PERLINCL=`$PERL -MConfig -e
'print $Config{archlibexp}'` in configure.
What's the point of that? That directory is already in @INC on the
build machine, but if the user doesn't have the exact same version of
perl installed, it will raise an exception because the directory won't
exist.
My GUESS is that there was a worry that it wouldn't be in @INC on the
target machine, but I don't know if that makes any sense.
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: Relink warnings
Geert Janssens janssens-ge...@telenet.be writes: When I build Gnucash from svn trunk, I always get relink warnings during make install. Why are these happening exactly ? And can they be avoided ? They make my change-build-install-test cycle dog slow. Libtool. I don't know if there's any way to avoid them. I see them on many libtool-based applications. Geert -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: r18476 - htdocs/trunk/news - Fix unstable version warning
Phil, I see you have pushed a new news item. You already found there is now a warning block in it. I had made some additional changes to the news pages, like adding links to the proper download locations and some general tidying to the titles. I see now that I didn't communicate these changes properly. Sorry about that. The result is that these changes are not picked up in your new news item. I propose to take the news item for 2.3.7 as a template for future (development) news pages. It would be nice if the 2.3.8 item had the other layout and content updates I did to the previous items. I can do that if you like, or you can do it yourself. I think apart for the version numbers, the only varying part of the news item is the Changes between 2.3.x and 2.3.y include section. Specifically for the version number, it's easiest to do a search and replace. There are some in the links at the bottom of the news item as well. Geert On Wednesday 9 December 2009, Phil Longstaff wrote: Author: plongstaff Date: 2009-12-09 13:09:25 -0500 (Wed, 09 Dec 2009) New Revision: 18476 Trac: http://svn.gnucash.org/trac/changeset/18476 Modified: htdocs/trunk/news/091208-2.3.8.news Log: Fix unstable version warning ___ gnucash-patches mailing list gnucash-patc...@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-patches ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: r18476 - htdocs/trunk/news - Fix unstable version warning
Also, when you update a release (stable or development), the new version number should be inserted in externals/global_params.php. This ensures that the front page and downloads page continue to list the latest versions. For an unstable release, only the downloads page is affected by this, for a stable release, both pages are affected. Geert On Wednesday 9 December 2009, Phil Longstaff wrote: Author: plongstaff Date: 2009-12-09 13:09:25 -0500 (Wed, 09 Dec 2009) New Revision: 18476 Trac: http://svn.gnucash.org/trac/changeset/18476 Modified: htdocs/trunk/news/091208-2.3.8.news Log: Fix unstable version warning ___ gnucash-patches mailing list gnucash-patc...@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-patches ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Version field in Bugzilla
There's a version field in bugzilla that can be used to set a GnuCash version. When reporting bugs, I have always set this to the version that has the problem. But now I also start closing bugs, I wonder if I have to change this field when closing a bug. Should it be set to the version in which the problem was fixed ? Or keep it on the version in which the problem was reported ? Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: r18476 - htdocs/trunk/news - Fix unstable version warning
I didn't 'svn update' until after I'd copied 2.3.7 to 2.3.8 as a template, so I didn't know about the new stuff. It wasn't until I had first committed the 2.3.8 news item and then went to see how it looked on gnucash.org that I noticed some of the new stuff. I copied the warning block, but nothing else. A new template would be great. Even better would be working out a good process for updating the changed item section. For this, I looked at the revision log from http://svn.gnucash.org/trac/log/gnucash/trunk, but it cuts off the comments. Phil From: Geert Janssens janssens-ge...@telenet.be To: gnucash-devel@gnucash.org Sent: Wed, December 9, 2009 1:35:42 PM Subject: Re: r18476 - htdocs/trunk/news - Fix unstable version warning Phil, I see you have pushed a new news item. You already found there is now a warning block in it. I had made some additional changes to the news pages, like adding links to the proper download locations and some general tidying to the titles. I see now that I didn't communicate these changes properly. Sorry about that. The result is that these changes are not picked up in your new news item. I propose to take the news item for 2.3.7 as a template for future (development) news pages. It would be nice if the 2.3.8 item had the other layout and content updates I did to the previous items. I can do that if you like, or you can do it yourself. I think apart for the version numbers, the only varying part of the news item is the Changes between 2.3.x and 2.3.y include section. Specifically for the version number, it's easiest to do a search and replace. There are some in the links at the bottom of the news item as well. Geert On Wednesday 9 December 2009, Phil Longstaff wrote: Author: plongstaff Date: 2009-12-09 13:09:25 -0500 (Wed, 09 Dec 2009) New Revision: 18476 Trac: http://svn.gnucash.org/trac/changeset/18476 Modified: htdocs/trunk/news/091208-2.3.8.news Log: Fix unstable version warning ___ gnucash-patches mailing list gnucash-patc...@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-patches ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Gnucash 2.3.8 released
GnuCash 2.3.8 released The GnuCash development team proudly announces GnuCash 2.3.8, the ninth of several unstable 2.3.x releases of the GnuCash Free Accounting Software which will eventually lead to the stable version 2.4.0. With this new release series, GnuCash can use an SQL database using SQLite3, MySQL or PostgreSQL. It runs on GNU/Linux, *BSD, Solaris, Microsoft Windows and Mac OSX. This release is intended for developers and testers who want to help tracking down all those bugs that are still in there. WARNING WARNING WARNING - Make sure you make backups of any files used in testing versions of GnuCash in the 2.3.x series. Although the developers go to great lengths to ensure that no data will be lost we cannot guarantee that your data will not be affected if for some reason GnuCash crashes in testing these releases. NOTE: This is an *UNSTABLE* version of Gnucash. The latest stable version is 2.2.9. PLEASE TEST TEST AND TEST SOME MORE any and all features important to you. Then post any bugs you find to bugzilla Major changes in the 2.3.x release include; * In addition to the XML backend, Gnucash can now use a SQLite3, MySQL or PostgreSQL database to store the data. This is a new implementation using libdbi. It supports all features including the business features. In order to build with this, add --enable-dbi to the configure command. In addition to the libdbi-dev package for your distribution, you will also need the appropriate DBD (libdbi driver) package for sqlite3, mysql or postgresql. * In addition to the current GtkHTML HTML engine used to display reports and graphs, Gnucash can use WebKit. WebKit is the engine used by Google Chrome on Windows and Safari on Apple. In order to build with this, add --enable-webkit to the configure command. You will need an appropriate webkit-dev package. On win32, you will need to download the webkit-1.1.5-win32.zip file from the source repository and put it into the downloads directory of your gnucash build area. * Updated to AqBanking 3 on Win32. Changes between 2.3.7 and 2.3.8 include: * Disable it_IT help in the win32 binary * Recreate index after updating table * Temporarily disable currency trading accounts so that 'make check' will pass * Fix test-resolve-file-path - results have changed * Fix compilation problem in test * Add src/gnome-utils/gnc-tree-model-account-drag.c to po/POTFILES.in * Set debug level for gnc.backend.dbi automatically to DEBUG. * Fix memory leak: Let the pixbuf renderer for goffice plots be unreferenced * Add libguile CFLAGS and LIBADD to libqof build * Fix too-new gtk_dialog_get_content_area function of r18413: Patch by J. … * Transaction post date also needs to allow NULL values. * Temporary workaround for crash at startup after r18429. * Decrease verbosity of aqbanking plugin: Debug output only if preference … * In the Save As dialog, set XML as default, not sqlite3. * Fix compile error on current ubuntu by clashing symbol declarations in … * When creating an account selector and a commodity list if provider, just … * Remove forgotten printf in r18402 which shouldn't have been committed to … * Fix amount sign of imported bank transfers (e.g. from DTAUS … * Fix GCC pointer strictness compiler errors/warnings and remove duplicate … * Fix compile error related to uninitialized value. Patch by Matt Lavin … * Introduce disambiguation prefix for Deposit action to distinguish it … * Make one register function more const correct to avoid compiler warnings … * Fix typo: scm_catch_body_t - scm_t_catch_body * gnc-module doesn't need to compile/link with guile * Add new option in register Tab order includes Transfer field. Patch by Colin Law * Partly fix broken data file backward compatibility with SX recurrence * Win32: Allow m4 1.4.11 and 1.4.13 as well as 1.4.7. * Win32: Assert there is only one aqbanking plugin directory * Win32: Minor version update of aqbanking. * Bug #603186: Fix crash with txf.scm on win32 Patch by J. Alex … * Bug #537476: Fix currency trading account preference lookup Patch by Mike … * Fix the bug described in comment 19 of bug 537476, balance sheet wrong … * Bug #310567: Disable newly introduced shift txn forward feature again … * Fix bug 600486 - Unable to open sqllite file on Win7 64 bit Unposted … * Fix Bug 591573 - File|Save As with xml option and no file name … * Fix bug 602603 - State file cannot be saved with MySQL because of colon … * Bug #570895: Allow reporting for single budget periods in
Re: Undocumented? Close book
The nice thing with GnuCash / XML is that it works on a single file (book) just like say Open Office. So, save backups, for instance just before running (or testing) Close Book. Then it is easy to go back if the function did something strange. Remember: close book is used for handling accounting periods (relevant for business accounting, primarily at year's end). Google gave: http://svn.gnucash.org/docs/HEAD/bookperiods.html Wikipedia: To close the books for the month, we will adjust expenses and revenue to zero by appropriately crediting and debiting the income summary and then closing the income summary to retained earnings (part of equity). http://en.wikipedia.org/wiki/Double-entry_bookkeeping_system Birger On on., 2009-12-09 at 12:30 -0500, Derek Atkins wrote: Hi, Parker Jones zoubi...@hotmail.com writes: Thanks David, that does help a lot.Especially the tip about reports. I can see a problem with my usage because my partner also uses the same accounts. She might occasionally make changes without realising that zeroing transactions need updating and I might not notice her changes, thus leaving the books out of sync. I suppose I'll have to re-close books regularly to be safe. For the record, I never close the books. I don't see a reason to. All the reports are designed to handle periods, so really the only thing that closing the books gives you is the ability to look at the account balances in the Chart of Accounts to see this period's balance. But if you use the reports for that info then you don't need to ever close the books. -derek ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Version field in Bugzilla
I normally set the 'target milestone' to the version which will contain the fix. Recently, all bugs prior to 2.0 were either closed or moved. For actual bugs, I like to see the original version. If a bug is reported in version X and stable version Y has a fix, the bug will be reported against X and someone who scans the list and knows that version Y contains a fix can recognize that fact. For enhancements, however, is it useful to know what version the request was reported against? Personally, I don't think so. If someone wants a new feature in version X, and stable version Y still doesn't have that feature, I don't think the added info that it was requested against version X is of any use. I would prefer to see enhancements changed (regardless of how they are reported) to be against SVN. I've started using the bugzilla 'browse' (https://bugzilla.gnome.org/browse.cgi?product=GnuCash). If I want to fix some old bugs, this tells me where to start (2.0.5). Phil From: Geert Janssens janssens-ge...@telenet.be To: gnucash-devel@gnucash.org Sent: Wed, December 9, 2009 1:43:38 PM Subject: Version field in Bugzilla There's a version field in bugzilla that can be used to set a GnuCash version. When reporting bugs, I have always set this to the version that has the problem. But now I also start closing bugs, I wonder if I have to change this field when closing a bug. Should it be set to the version in which the problem was fixed ? Or keep it on the version in which the problem was reported ? Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Version field in Bugzilla
Am Mittwoch, 9. Dezember 2009 schrieb Phil Longstaff: I normally set the 'target milestone' to the version which will contain the fix. I agree. The Version field is being used for the version where the bug was spotted and reported. The Target Milestone shows the version when the solution will appear publicly. If one closes a bug, we shouldn't modify the Version field because it still contains information that we might not have in any of the other fields, as sometimes the bug might have disappeared in the current version already (which means we will probably close it as DUPLICATE or OBSOLETE). Recently, all bugs prior to 2.0 were either closed or moved. For actual bugs, I like to see the original version. Yes, same here. For enhancements, however, is it useful to know what version the request was reported against? Personally, I don't think so. Yes, usually it is not necessary to know the reporter's version anymore. In that case it should be set to SVN as long as SVN doesn't have this feature. However, there might be exceptions to this rule, in which case we should leave the Version field to the reporter's version. I've started using the bugzilla 'browse' https://bugzilla.gnome.org/browse.cgi?product=GnuCash Yes, this is also my start page into bugzilla. I use it almost daily to at least quickly review the new bugs (right column, second line from top). Regards, Christian ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Patches: Documentation, account.glade, gnc-ui-util
Dear Alex, thanks a lot for your patches. Am Dienstag, 8. Dezember 2009 schrieb J. Alex Aycinena: -doc-patchfile updates the documentation to reflect the recently applied tax enhancements Applied. -gnc-ui-util-acct-glade-patchfile has some small corrections to account.glade and gnc-ui-util.c also related to the tax enhancements Applied. The changed in account.glade are a bit difficult - your glade editor has changed the complete file and one cannot see the actual change easily. This is caused by the 2.x and 3.x version of the glade editor, and all gnucash files are still created by (and thus, backwards compatible with) version 2.x. I just noticed I don't have any glade 2.x available on Ubuntu 9.10, though... Hence, I first converted the file to glade-3, then compared with your patched file, which gave me the single changed line (git makes this rather easy). @developers: Should we convert all glade files to glade-3 sometime soon? Otherwise we will run into this issue every time someone wants to edit the glade files with the currently recommended and available tools... Regards, Christian PS: You don't need to send mail to gnucash-patches; gnucash-devel is sufficient and the recommended place to submit patches. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Gnucash 2.3.8 released
Am Mittwoch, 9. Dezember 2009 schrieb Phil Longstaff: GnuCash 2.3.8 released The GnuCash development team proudly announces GnuCash 2.3.8, the ninth of several unstable 2.3.x releases of the GnuCash Free Accounting Software Thanks a lot, Phil, for preparing the new release! It is a good step forward to have a new release, now that we have had quite a number of changes. Thank you very much for going through all the release work for us. Way to go :-) Christian which will eventually lead to the stable version 2.4.0. With this new release series, GnuCash can use an SQL database using SQLite3, MySQL or PostgreSQL. It runs on GNU/Linux, *BSD, Solaris, Microsoft Windows and Mac OSX. This release is intended for developers and testers who want to help tracking down all those bugs that are still in there. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Documentation en français
Dear Isabelle, unfortunately this is an English-language mailing list and my French is not helping me much. I understood you explained you are a teacher in some kind of school, but I couldn't understand the main part of your message. Either you try again on the French-speaking mailing list https://lists.gnucash.org/mailman/listinfo/gnucash-fr but it is frequented rather low, or you would need to ask again in English here. Thank you very much! Best Regards, Christian Stimming Am Mittwoch, 2. Dezember 2009 schrieb Isabelle Néron: Bonjour, Je suis enseignante en Ecole de commerce et management. Mes élèves sont destinés à de la finance d'entreprise, de la gestion de patrimoine, voire l'expertise comptable ; et je suis consultante sur les mêmes domaines, notamment en PME depuis 18 ans. Recherchant un logiciel utilisable en local (pour des raisons de sécurité, je ne veux pas utiliser des mises à disposition sur des sites comme Mon Officeo, même si le coté nomade et l'accès de n'importe quel poste peut paraître attrayant), j'ai trouvé le vôtre grâce à un message sur un forum. Tout ce que j'ai pu lire en français m'a beaucoup attiré, je pense que votre outil est particulièrement bien pensé, d'autant qu'il peut manifestement répondre aux besoins d'une PME, contrairement aux programmes de gestion de trésorerie spécifiques, beaucoup trop lourds et compliqués à paramétrer (je parle d'expérience). Mais j'ai tout de même un souci avec la documentation en anglais, car je dois intervenir dès le début de la semaine prochaine sur ce sujet, et le temps va me manquer, car je ne lis pas à la même vitesse en anglais qu'en français ! S'il existe une version, même allégée, de la documentation en français, je suis preneuse !!!. Merci de me répondre au plus vite, je compte sur vous. Au plaisir de vous lire, ou vous parler ? Cordialement Isabelle NERON 09 50 22 66 98 06 09 16 56 41 ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Version field in Bugzilla
Phil, Christian, Thanks for elaborating on this. The link to Bugzilla's browse feature was very nice too. I have taken the liberty to add this info in the wiki as well (see http://wiki.gnucash.org/wiki/QA/BugzillaAdministration). No doubt I won't be the last one to wonder about this. This will allow us to point future new developers to a wiki. Geert On Wednesday 9 December 2009, Christian Stimming wrote: Am Mittwoch, 9. Dezember 2009 schrieb Phil Longstaff: I normally set the 'target milestone' to the version which will contain the fix. I agree. The Version field is being used for the version where the bug was spotted and reported. The Target Milestone shows the version when the solution will appear publicly. If one closes a bug, we shouldn't modify the Version field because it still contains information that we might not have in any of the other fields, as sometimes the bug might have disappeared in the current version already (which means we will probably close it as DUPLICATE or OBSOLETE). Recently, all bugs prior to 2.0 were either closed or moved. For actual bugs, I like to see the original version. Yes, same here. For enhancements, however, is it useful to know what version the request was reported against? Personally, I don't think so. Yes, usually it is not necessary to know the reporter's version anymore. In that case it should be set to SVN as long as SVN doesn't have this feature. However, there might be exceptions to this rule, in which case we should leave the Version field to the reporter's version. I've started using the bugzilla 'browse' https://bugzilla.gnome.org/browse.cgi?product=GnuCash Yes, this is also my start page into bugzilla. I use it almost daily to at least quickly review the new bugs (right column, second line from top). Regards, Christian ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: r18476 - htdocs/trunk/news - Fix unstable version warning
On Wednesday 9 December 2009, Phil Longstaff wrote: I didn't 'svn update' until after I'd copied 2.3.7 to 2.3.8 as a template, so I didn't know about the new stuff. It wasn't until I had first committed the 2.3.8 news item and then went to see how it looked on gnucash.org that I noticed some of the new stuff. I copied the warning block, but nothing else. A new template would be great. Even better would be working out a good process for updating the changed item section. For this, I looked at the revision log from http://svn.gnucash.org/trac/log/gnucash/trunk, but it cuts off the comments. What do you mean with it cuts off the comments ? Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: r18476 - htdocs/trunk/news - Fix unstable version warning
On Wednesday 9 December 2009, Phil Longstaff wrote: On Wed, 2009-12-09 at 23:34 +0100, Geert Janssens wrote: On Wednesday 9 December 2009, Phil Longstaff wrote: I didn't 'svn update' until after I'd copied 2.3.7 to 2.3.8 as a template, so I didn't know about the new stuff. It wasn't until I had first committed the 2.3.8 news item and then went to see how it looked on gnucash.org that I noticed some of the new stuff. I copied the warning block, but nothing else. A new template would be great. Even better would be working out a good process for updating the changed item section. For this, I looked at the revision log from http://svn.gnucash.org/trac/log/gnucash/trunk, but it cuts off the comments. What do you mean with it cuts off the comments ? Here's the log message from the most recent commit: Small UI string corrections related to the recent tax enhancements. Patch … The ... is what I mean. Ok, now I see. It didn't cross my mind you were looking to a website in your browser. I was looking at svn log at the command line, which also uses a URL :) You can check Show full log messages and click update. This gives you a view with full log messages, but the layout is slightly changed as well. Maybe this helps ? If not, I think I should be able to whip up a script that extracts the right information and massage it into the proper format. Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: r18476 - htdocs/trunk/news - Fix unstable version warning
On Wed, 2009-12-09 at 23:34 +0100, Geert Janssens wrote: On Wednesday 9 December 2009, Phil Longstaff wrote: I didn't 'svn update' until after I'd copied 2.3.7 to 2.3.8 as a template, so I didn't know about the new stuff. It wasn't until I had first committed the 2.3.8 news item and then went to see how it looked on gnucash.org that I noticed some of the new stuff. I copied the warning block, but nothing else. A new template would be great. Even better would be working out a good process for updating the changed item section. For this, I looked at the revision log from http://svn.gnucash.org/trac/log/gnucash/trunk, but it cuts off the comments. What do you mean with it cuts off the comments ? Here's the log message from the most recent commit: Small UI string corrections related to the recent tax enhancements. Patch … The ... is what I mean. Phil ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Patches: Documentation, account.glade, gnc-ui-util
Christian, 2009/12/9 Christian Stimming stimm...@tuhh.de: Dear Alex, thanks a lot for your patches. @developers: Should we convert all glade files to glade-3 sometime soon? Otherwise we will run into this issue every time someone wants to edit the glade files with the currently recommended and available tools... Regards, Christian PS: You don't need to send mail to gnucash-patches; gnucash-devel is sufficient and the recommended place to submit patches. Thanks, Alex ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Relink warnings
On Wed, 2009-12-09 at 12:49 -0500, Derek Atkins wrote: Geert Janssens janssens-ge...@telenet.be writes: When I build Gnucash from svn trunk, I always get relink warnings during make install. Why are these happening exactly ? And can they be avoided ? They make my change-build-install-test cycle dog slow. Libtool. I don't know if there's any way to avoid them. I see them on many libtool-based applications. I googled and found this: http://www.mail-archive.com/bug-libt...@gnu.org/msg00838.html Seems a few years old. Don't know why it hasn't been merged into libtool. Phil ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Problem with account tree/model change with dragging (r18426)
I think some problems were introduced with this change. I created a report and tried to modify the set of accounts used for this report. The following showed up in /tmp/gnucash.trace: * 20:14:20 CRIT Gtk gtk_tree_model_sort_convert_iter_to_child_iter: assertion `GTK_IS_TREE_MODEL_SORT (tree_model_sort)' failed * 20:14:20 CRIT Gtk gtk_tree_model_sort_get_model: assertion `GTK_IS_TREE_MODEL_SORT (tree_model)' failed * 20:14:20 CRIT Gtk gtk_tree_model_filter_convert_iter_to_child_iter: assertion `GTK_IS_TREE_MODEL_FILTER (filter)' failed * 20:14:20 CRIT gnc.gui gnc_tree_view_account_filter_by_view_info: assertion `GNC_IS_ACCOUNT(acct)' failed * 20:14:20 CRIT Gtk gtk_tree_model_sort_convert_iter_to_child_iter: assertion `GTK_IS_TREE_MODEL_SORT (tree_model_sort)' failed * 20:14:20 CRIT Gtk gtk_tree_model_sort_get_model: assertion `GTK_IS_TREE_MODEL_SORT (tree_model)' failed * 20:14:20 CRIT Gtk gtk_tree_model_filter_convert_iter_to_child_iter: assertion `GTK_IS_TREE_MODEL_FILTER (filter)' failed * 20:14:20 CRIT gnc.gui gnc_tree_view_account_filter_by_view_info: assertion `GNC_IS_ACCOUNT(acct)' failed More info: I set a breakpoint down in the logging code, and it stopped on: Breakpoint 3, log4glib_handler (log_domain=0x806c7c GLib-GObject, log_level=G_LOG_LEVEL_WARNING, message=0xa878208 invalid cast from `GncTreeModelAccountDrag' to `GtkTreeModelSort', user_data=0x8052c30) at qoflog.c:112 which may provide some clue to the problem. Phil ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: MacOSX builds of 2.3.X
On Dec 9, 2009, at 8:24 AM, Phil Longstaff wrote: I guess this is mostly for John Ralls who seems to be providing the 2.2.9 native MacOSX builds. I just recently clued in that I am not doing anything to synchronize with you so that a native macosx build of 2.3.X could be uploaded to sourceforge along with the win32 build so that we would provide tarballs, win32 setup.exe and mac .dmg at the same time. This assumes, of course, that mac 2.3.X builds are possible :) How do you want to coordinate? Shall I just send you an e-mail? Do you have a daily svn build so that if 2.3.X is tagged, you can easily produce a .dmg? I've actually got a 2.3.8 build built and ready to bundle for installation. I'm holding off to get the PERLINC issue sorted out. You told the list that you'd tagged 2.3.8 but didn't say when you were planning to upload the tarballs and make an announcement. If you add that information and give a few days lead time, I should be able to build the tagged revision and bundle it up to meet the release date. I don't do nightly builds, never mind nightly bundles. Derek wanted to set that up on a VM somewhere, but we got distracted by other things and never got it going. I suppose it would be a good idea for me to set it up locally so if something breaks I'll see it without having to spend a lot of time bisecting to find the problem. (A nightly build wouldn't necessarily line up with a tagged release, so it's just a QA check, not something that would save time for bundling a release.) Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: MacOSX builds of 2.3.X
On Wed, 2009-12-09 at 17:59 -0800, John Ralls wrote: On Dec 9, 2009, at 8:24 AM, Phil Longstaff wrote: I guess this is mostly for John Ralls who seems to be providing the 2.2.9 native MacOSX builds. I just recently clued in that I am not doing anything to synchronize with you so that a native macosx build of 2.3.X could be uploaded to sourceforge along with the win32 build so that we would provide tarballs, win32 setup.exe and mac .dmg at the same time. This assumes, of course, that mac 2.3.X builds are possible :) How do you want to coordinate? Shall I just send you an e-mail? Do you have a daily svn build so that if 2.3.X is tagged, you can easily produce a .dmg? I've actually got a 2.3.8 build built and ready to bundle for installation. I'm holding off to get the PERLINC issue sorted out. You told the list that you'd tagged 2.3.8 but didn't say when you were planning to upload the tarballs and make an announcement. If you add that information and give a few days lead time, I should be able to build the tagged revision and bundle it up to meet the release date. I don't do nightly builds, never mind nightly bundles. Derek wanted to set that up on a VM somewhere, but we got distracted by other things and never got it going. I suppose it would be a good idea for me to set it up locally so if something breaks I'll see it without having to spend a lot of time bisecting to find the problem. (A nightly build wouldn't necessarily line up with a tagged release, so it's just a QA check, not something that would save time for bundling a release.) Unfortunately, there are a few steps between tagging the build and doing the upload. If I tag on day 0, I can also create the tarballs on the same day. However, I need to wait until day 1 before the win32 build is complete (assuming it does complete). I then try to download it and install it to make sure it installs and starts OK. Then, I can upload everything to sourceforge (I just figured out how to make that work reliably). If the win32 build doesn't work, it needs to be fixed, and I then need to untag and retag the build. According to Derek, if the untag and retag are on different days, the tag build will kick itself off again. Otherwise, it needs to be manually kicked. Once the 2 tarballs and win32 setup.exe are on sourceforge, I update the news for the gnucash website and then send out the release notes. If our 3 most-supported platforms are linux, win32 and mac, then I suggest that for 2.3.9, I won't announce the release until the 2 tarballs, win32 setup.exe and mac build are available on sourceforge. Phil ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: MacOSX builds of 2.3.X
On Dec 9, 2009, at 6:18 PM, Phil Longstaff wrote: On Wed, 2009-12-09 at 17:59 -0800, John Ralls wrote: On Dec 9, 2009, at 8:24 AM, Phil Longstaff wrote: I guess this is mostly for John Ralls who seems to be providing the 2.2.9 native MacOSX builds. I just recently clued in that I am not doing anything to synchronize with you so that a native macosx build of 2.3.X could be uploaded to sourceforge along with the win32 build so that we would provide tarballs, win32 setup.exe and mac .dmg at the same time. This assumes, of course, that mac 2.3.X builds are possible :) How do you want to coordinate? Shall I just send you an e-mail? Do you have a daily svn build so that if 2.3.X is tagged, you can easily produce a .dmg? I've actually got a 2.3.8 build built and ready to bundle for installation. I'm holding off to get the PERLINC issue sorted out. You told the list that you'd tagged 2.3.8 but didn't say when you were planning to upload the tarballs and make an announcement. If you add that information and give a few days lead time, I should be able to build the tagged revision and bundle it up to meet the release date. I don't do nightly builds, never mind nightly bundles. Derek wanted to set that up on a VM somewhere, but we got distracted by other things and never got it going. I suppose it would be a good idea for me to set it up locally so if something breaks I'll see it without having to spend a lot of time bisecting to find the problem. (A nightly build wouldn't necessarily line up with a tagged release, so it's just a QA check, not something that would save time for bundling a release.) Unfortunately, there are a few steps between tagging the build and doing the upload. If I tag on day 0, I can also create the tarballs on the same day. However, I need to wait until day 1 before the win32 build is complete (assuming it does complete). I then try to download it and install it to make sure it installs and starts OK. Then, I can upload everything to sourceforge (I just figured out how to make that work reliably). If the win32 build doesn't work, it needs to be fixed, and I then need to untag and retag the build. According to Derek, if the untag and retag are on different days, the tag build will kick itself off again. Otherwise, it needs to be manually kicked. Once the 2 tarballs and win32 setup.exe are on sourceforge, I update the news for the gnucash website and then send out the release notes. If our 3 most-supported platforms are linux, win32 and mac, then I suggest that for 2.3.9, I won't announce the release until the 2 tarballs, win32 setup.exe and mac build are available on sourceforge. Right. But I can start on the OSX bundle as soon as you tag SVN, so if, when you tag you post here I've just tagged 2.3.9 for release, and barring problems I'll announce the release in 3 days, then most likely I can have the dmg up on sourceforge by the time you announce -- and if there's an issue, we can use those 3 days to discuss it. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
