[GNC-dev] Make of 3.3-181

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

[GNC-dev] Make of 3.3-181

Stephen M. Butler
I just did a git pull and then build of of the maint branch.  Saw this
slide past during the make step.

[ 92%] Generating
../../../../lib/gnucash/scm/ccache/2.0/gnucash/report/locale-specific/de_DE.go

(process:16634): gnc.module-WARNING **: 13:49:35.430: Could not locate
module gnucash/tax/de_DE interface v.0
wrote
`/home/steve/Projects/GnuCash/maint-build/lib/gnucash/scm/ccache/2.0/gnucash/report/locale-specific/de_DE.go'

Not sure if this was in earlier builds of it was just introduced.

--Steve

--
Stephen M Butler, PMP, PSM
[hidden email]
[hidden email]
253-350-0166
-------------------------------------------
GnuPG Fingerprint:  8A25 9726 D439 758D D846 E5D4 282A 5477 0385 81D8

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: [GNC-dev] Make of 3.3-181

c.holtermann
For me it is
* 02:10:26  WARN <gnc.module> Could not locate module gnucash/tax/us
interface v.0
wrote
`/home/christoph/oldhome_moved/Computer/src/gnucash/gnucash-git-fork-c.holtermann/lib64/gnucash/scm/ccache/2.2/gnucash/report/locale-specific/us.go'

I'm in germany and no compile issues with the de_DE things.

Christoph Holtermann

Am 2018-12-23 22:55, schrieb Stephen M. Butler:

> I just did a git pull and then build of of the maint branch.  Saw this
> slide past during the make step.
>
> [ 92%] Generating
> ../../../../lib/gnucash/scm/ccache/2.0/gnucash/report/locale-specific/de_DE.go
>
> (process:16634): gnc.module-WARNING **: 13:49:35.430: Could not locate
> module gnucash/tax/de_DE interface v.0
> wrote
> `/home/steve/Projects/GnuCash/maint-build/lib/gnucash/scm/ccache/2.0/gnucash/report/locale-specific/de_DE.go'
>
> Not sure if this was in earlier builds of it was just introduced.
>
> --Steve
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: [GNC-dev] Make of 3.3-181

Frank H. Ellenberger-3
I would suspect

either the change of locale-specific-tax from an option to the default
behaviour in configure was not completely ported to cmake

or it was not applied if the locale was C.

Frank

Am 24.12.18 um 02:12 schrieb [hidden email]:

> For me it is
> * 02:10:26  WARN <gnc.module> Could not locate module gnucash/tax/us
> interface v.0
> wrote
> `/home/christoph/oldhome_moved/Computer/src/gnucash/gnucash-git-fork-c.holtermann/lib64/gnucash/scm/ccache/2.2/gnucash/report/locale-specific/us.go'
>
>
> I'm in germany and no compile issues with the de_DE things.
>
> Christoph Holtermann
>
> Am 2018-12-23 22:55, schrieb Stephen M. Butler:
>> I just did a git pull and then build of of the maint branch.  Saw this
>> slide past during the make step.
>>
>> [ 92%] Generating
>> ../../../../lib/gnucash/scm/ccache/2.0/gnucash/report/locale-specific/de_DE.go
>>
>>
>> (process:16634): gnc.module-WARNING **: 13:49:35.430: Could not locate
>> module gnucash/tax/de_DE interface v.0
>> wrote
>> `/home/steve/Projects/GnuCash/maint-build/lib/gnucash/scm/ccache/2.0/gnucash/report/locale-specific/de_DE.go'
>>
>>
>> Not sure if this was in earlier builds of it was just introduced.
>>
>> --Steve
> _______________________________________________
> gnucash-devel mailing list
> [hidden email]
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: [GNC-dev] Make of 3.3-181

Geert Janssens-4
Op maandag 24 december 2018 02:33:39 CET schreef Frank H. Ellenberger:
> I would suspect
>
> either the change of locale-specific-tax from an option to the default
> behaviour in configure was not completely ported to cmake
>
> or it was not applied if the locale was C.
>
> Frank

As far as I remember this has always been the case. The German Tax reports are
only added if gnucash is built in an environment configured to the German
locale. In all other cases it is skipped, and instead a US tax report is
built. A part of the build system detects this and issues a warning.

This is a historical configuration wart that needs fixing at some point.
Country or jurisdiction specific decisions should not be made at compile time,
but at run time and even then probably only under user control.

So the build system and code should change in such a way that both reports get
built and included unconditionally and that the user at run time decides which
report to run. In the current implementation though only one of these reports
can exist at any given time IIRC.

Geert


_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: [GNC-dev] Make of 3.3-181

John Ralls-2


> On Dec 24, 2018, at 1:35 AM, Geert Janssens <[hidden email]> wrote:
>
> Op maandag 24 december 2018 02:33:39 CET schreef Frank H. Ellenberger:
>> I would suspect
>>
>> either the change of locale-specific-tax from an option to the default
>> behaviour in configure was not completely ported to cmake
>>
>> or it was not applied if the locale was C.
>>
>> Frank
>
> As far as I remember this has always been the case. The German Tax reports are
> only added if gnucash is built in an environment configured to the German
> locale. In all other cases it is skipped, and instead a US tax report is
> built. A part of the build system detects this and issues a warning.
>
> This is a historical configuration wart that needs fixing at some point.
> Country or jurisdiction specific decisions should not be made at compile time,
> but at run time and even then probably only under user control.
>
> So the build system and code should change in such a way that both reports get
> built and included unconditionally and that the user at run time decides which
> report to run. In the current implementation though only one of these reports
> can exist at any given time IIRC.

Agreed in principle, but in this case ISTM it would make more sense to just remove them.

de_DE.scm hasn’t been substantively maintained since it was first committed in 2005. taxtxf-de_DE.scm was last updated in 2011. The US versions get annual updates. Add to that that few if any users even have access to them because they require that the user build from source in the de_DE locale.

Regards,
John Ralls

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: [GNC-dev] Make of 3.3-181

Frank H. Ellenberger-3


Am 24.12.18 um 18:30 schrieb John Ralls:
> Agreed in principle, but in this case ISTM it would make more sense to just remove them.

Then all books based on SKR04 will crash. That was the reason, it became
default.

> de_DE.scm hasn’t been substantively maintained since it was first committed in 2005. taxtxf-de_DE.scm was last updated in 2011. The US versions get annual updates. Add to that that few if any users even have access to them because they require that the user build from source in the de_DE locale.

The implemented part is for the monthly VAT declaration and the VAT rate
does not change so often.

> Regards,
> John Ralls

Merry Christmas
Frank

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: [GNC-dev] Make of 3.3-181

Stephen M. Butler
In reply to this post by Geert Janssens-4
On 12/24/18 1:35 AM, Geert Janssens wrote:

> Op maandag 24 december 2018 02:33:39 CET schreef Frank H. Ellenberger:
>> I would suspect
>>
>> either the change of locale-specific-tax from an option to the default
>> behaviour in configure was not completely ported to cmake
>>
>> or it was not applied if the locale was C.
>>
>> Frank
> As far as I remember this has always been the case. The German Tax reports are
> only added if gnucash is built in an environment configured to the German
> locale. In all other cases it is skipped, and instead a US tax report is
> built. A part of the build system detects this and issues a warning.
>
> This is a historical configuration wart that needs fixing at some point.
> Country or jurisdiction specific decisions should not be made at compile time,
> but at run time and even then probably only under user control.
>
> So the build system and code should change in such a way that both reports get
> built and included unconditionally and that the user at run time decides which
> report to run. In the current implementation though only one of these reports
> can exist at any given time IIRC.
>
> Geert


If I read this correctly, then it's a non-issue and just an
informational line.  I'll crawl back into my dugout now!  :-)

--
Stephen M Butler, PMP, PSM
[hidden email]
[hidden email]
253-350-0166
-------------------------------------------
GnuPG Fingerprint:  8A25 9726 D439 758D D846 E5D4 282A 5477 0385 81D8

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: [GNC-dev] Make of 3.3-181

John Ralls-2
In reply to this post by Frank H. Ellenberger-3


> On Dec 24, 2018, at 9:44 AM, Frank H. Ellenberger <[hidden email]> wrote:
>
>
>
> Am 24.12.18 um 18:30 schrieb John Ralls:
>> Agreed in principle, but in this case ISTM it would make more sense to just remove them.
>
> Then all books based on SKR04 will crash. That was the reason, it became
> default.

Well, we have another long-standing action item to separate the account templates from the current locale selection. We'd need to bring txfde_DE.scm along with that.
>
>> de_DE.scm hasn’t been substantively maintained since it was first committed in 2005. taxtxf-de_DE.scm was last updated in 2011. The US versions get annual updates. Add to that that few if any users even have access to them because they require that the user build from source in the de_DE locale.
>
> The implemented part is for the monthly VAT declaration and the VAT rate
> does not change so often.

Since the TXF report is for exporting one's income tax information to US Income Tax software like Turbotax this seems a mis-application.

Regards,
John Ralls

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: [GNC-dev] Make of 3.3-181

Frank H. Ellenberger-3


Am 24.12.18 um 22:10 schrieb John Ralls:

>
>
>> On Dec 24, 2018, at 9:44 AM, Frank H. Ellenberger <[hidden email]> wrote:
>>
>>
>>
>> Am 24.12.18 um 18:30 schrieb John Ralls:
>>> Agreed in principle, but in this case ISTM it would make more sense to just remove them.
>>
>> Then all books based on SKR04 will crash. That was the reason, it became
>> default.
>
> Well, we have another long-standing action item to separate the account templates from the current locale selection. We'd need to bring txfde_DE.scm along with that.

Right, and like the account templates all locales should be build.

>>> de_DE.scm hasn’t been substantively maintained since it was first committed in 2005. taxtxf-de_DE.scm was last updated in 2011. The US versions get annual updates. Add to that that few if any users even have access to them because they require that the user build from source in the de_DE locale.
>>
>> The implemented part is for the monthly VAT declaration and the VAT rate
>> does not change so often.
>
> Since the TXF report is for exporting one's income tax information to US Income Tax software like Turbotax this seems a mis-application.

Why? The german government prefers from private and requires from
business users to use its interface ElStEr. Both groups have to file at
the end of the year the income statement, most business users also the
VAT statement, special branches also other taxes. Like Taxbird for the
US there are third party tools for DE. The difference might be the
monthly predeclaration and payment of VAT. But because this is the most
annoying part, it was implemented first.

> Regards,
> John Ralls

Regards
Frank

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: [GNC-dev] Make of 3.3-181

Christopher Lam
There is still a strong argument to clean up these reports...

They are generally messy, lots of duplicate code, impose new
translatable strings; they use localised C API such as
xaccAccountGetTaxUSCode (even taxtxf-de_DE.scm calls it), are poorly tested.

I have not touched any of them significantly because they are both an
eyesore.

Yet, to move the whole code base forward means maintaining these reports
forever.

Perhaps it would be useful to canvas the users and ask how much use they
actually get?

C


_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: [GNC-dev] Make of 3.3-181

John Ralls-2
In reply to this post by Frank H. Ellenberger-3


> On Dec 24, 2018, at 3:23 PM, Frank H. Ellenberger <[hidden email]> wrote:
>
>
>
> Am 24.12.18 um 22:10 schrieb John Ralls:
>>
>>
>>> On Dec 24, 2018, at 9:44 AM, Frank H. Ellenberger <[hidden email]> wrote:
>>>
>>>
>>>
>>> Am 24.12.18 um 18:30 schrieb John Ralls:
>>>> Agreed in principle, but in this case ISTM it would make more sense to just remove them.
>>>
>>> Then all books based on SKR04 will crash. That was the reason, it became
>>> default.
>>
>> Well, we have another long-standing action item to separate the account templates from the current locale selection. We'd need to bring txfde_DE.scm along with that.
>
> Right, and like the account templates all locales should be build.
>
>>>> de_DE.scm hasn’t been substantively maintained since it was first committed in 2005. taxtxf-de_DE.scm was last updated in 2011. The US versions get annual updates. Add to that that few if any users even have access to them because they require that the user build from source in the de_DE locale.
>>>
>>> The implemented part is for the monthly VAT declaration and the VAT rate
>>> does not change so often.
>>
>> Since the TXF report is for exporting one's income tax information to US Income Tax software like Turbotax this seems a mis-application.
>
> Why? The german government prefers from private and requires from
> business users to use its interface ElStEr. Both groups have to file at
> the end of the year the income statement, most business users also the
> VAT statement, special branches also other taxes. Like Taxbird for the
> US there are third party tools for DE. The difference might be the
> monthly predeclaration and payment of VAT. But because this is the most
> annoying part, it was implemented first.

So begin with TXF is for personal tax return software, not for business returns.

(Taxbird for the US (https://www.taxbird.com/ <https://www.taxbird.com/>) is completely unrelated to the German one (http://www.taxbird.de/ <http://www.taxbird.de/>) and doesn’t have anything to do with TXF import. Software that uses TXF includes Intuit’s TurboTax (https://turbotax.intuit.com/ <https://turbotax.intuit.com/>) and H&R Block’s Tax Software (https://www.hrblock.com/tax-software/ <https://www.hrblock.com/tax-software/>).)

So the German tax extraction module and corresponding report shouldn’t be called “txf”. If the format they export is called ElStEr then that’s what they should be called. They also shouldn’t be in tax/us and locale-specific/us.

For completeness in case someone decides to take on cleaning this up, there are two more puzzle pieces: gnc_ui_account_get_tax_info_string in libgnucash/app-utils/gnc-ui-utils.c and gnucash/gnome/dialog-tax-info.c.

It turns out that everything gets built regardless of locale. de-DE.go, txf-de_DE.go, and the rest are all in my build directory using the C locale. Not that that matters, they’re pure Scheme and guile would build them on the fly if it needed to.

What’s different between Cmake and autotools is that under autotools we used recursive build to ensure that dependencies (in this case libgnucash/tax/us) were built before what depends on them (gnucash/report/locale-specific/us). Cmake doesn’t work that way, it has a single build and needs to be told explicitly about dependencies so that it can correctly order the build. That dependency information is missing from gnucash/report/locale-specific/us/CMakeLists.txt, creating the opportunity for the warning that Steve noticed.

It’s not a real problem, just noise: It’s just byte-compiling, not linking, so there’s no real need for the gnucash/tax/de_DE module at build time and it does get built and installed before the tests run.

Regards,
John Ralls
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

[GNC-dev] GnuCash Maint - general problem to enter year for 30.12. + 31.12. ?

Carsten Rinke
Hi,

today after building from the maint branch I noticed following behaviour:

Enter a new transaction with a date 31.12.2018 and press enter:
31.12.2019 is displayed.

Try to edit and set it back to 2018 by "ctrl -" and press enter:
31.12.2019 is displayed.

Try to set it to 30.12.2019 by using "-": 30.12.2020 is displayed.

Once that you change to 29.12. the year can be set normally again.


I went back and built again from the 3.4 release snapshot:

Here the issue is not reproducable.


Does anyone else see this, too?


Kind regards,
Carsten

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: [GNC-dev] GnuCash Maint - general problem to enter year for 30.12. + 31.12. ?

John Ralls-2


> On Jan 27, 2019, at 5:20 AM, Carsten Rinke <[hidden email]> wrote:
>
> Hi,
>
> today after building from the maint branch I noticed following behaviour:
>
> Enter a new transaction with a date 31.12.2018 and press enter: 31.12.2019 is displayed.
>
> Try to edit and set it back to 2018 by "ctrl -" and press enter: 31.12.2019 is displayed.
>
> Try to set it to 30.12.2019 by using "-": 30.12.2020 is displayed.
>
> Once that you change to 29.12. the year can be set normally again.
>
>
> I went back and built again from the 3.4 release snapshot:
>
> Here the issue is not reproducable.
>
>
> Does anyone else see this, too?

Carsten,

Yes, Mike Alexander noticed it and filed https://bugs.gnucash.org/show_bug.cgi?id=797067 yesterday. I think there's a good chance it's the same ICU bug as the one in the "Test Failure" thread but I haven't yet had a chance to test it.

Regards,
John Ralls

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel