Re: [GNC-dev] Building 3.5 package for Disco
On 5/3/19 4:32 PM, John Ralls wrote:
>
> gnucash-design.info is built only if you have make info installed. I wouldn't
> bother, the document is severely obsolete. Just find it in your build
> description and remove it.
>
> Let's get back to gtest. I looked at gnc_gtest_configure() in
> common/cmake_modules/GncAddTest.cmake and was reminded that if cmake finds
> libgtest.a that it will ignore the source directory and use the system
> libgtest.a.
>
> The missing symbols are from libgtest.a, so maybe the linker is getting them
> in the wrong order. Open GncAddTest.cmake in an editor and at line 137 change
>set(GTEST_LIB "${GTEST_SHARED_LIB};${GTEST_MAIN_LIB}" PARENT_SCOPE)
> to
>set(GTEST_LIB "${GTEST_MAIN_LIB};${GTEST_SHARED_LIB}" PARENT_SCOPE)
>
> and see if that fixes the error.
>
> It's been that way for a long time so why it would suddenly matter is
> strange...
>
> Regards,
> John Ralls
First, here are the locations of libgtest.a on my system:
/usr/lib/x86_64-linux-gnu/libgtest.a
/home/steve/Projects/GnuCash/build/common/test-core/libgtest.a
/home/steve/Projects/GnuCash/chrislam/.build/common/test-core/libgtest.a
1. Removed ./debian/gnucash-common.info
2. Made the change noted above on line 137 in
./common/cmake_modules/GncAddTest.cmake
I have a debian package for 3.5 as built in 19.04 (Disco).
sudo apt install ./*3.5*.deb
Reading package lists... Done
Building dependency tree
Reading state information... Done
Note, selecting 'gnucash' instead of './gnucash_3.5_amd64.deb'
Note, selecting 'gnucash-common' instead of './gnucash-common_3.5_all.deb'
Note, selecting 'python3-gnucash' instead of
'./python3-gnucash_3.5_amd64.deb'
gnucash-common is already the newest version (1:3.5).
The following packages were automatically installed and are no longer
required:
libboost-regex1.65.1 libuser1 python-libuser
Use 'sudo apt autoremove' to remove them.
Suggested packages:
libdbd-mysql
Recommended packages:
pythone3-gnucash
The following NEW packages will be installed:
python3-gnucash
The following packages will be upgraded:
gnucash
1 upgraded, 1 newly installed, 0 to remove and 3 not upgraded.
Need to get 0 B/4,229 kB of archives.
After this operation, 1,772 kB of additional disk space will be used.
Do you want to continue? [Y/n] Y
Get:1 /home/steve/Projects/GnuCash/gnucash_3.5_amd64.deb gnucash amd64
1:3.5 [3,958 kB]
Get:2 /home/steve/Projects/GnuCash/python3-gnucash_3.5_amd64.deb
python3-gnucash amd64 1:3.5 [271 kB]
(Reading database ... 227873 files and directories currently installed.)
Preparing to unpack .../GnuCash/gnucash_3.5_amd64.deb ...
Unpacking gnucash (1:3.5) over (1:3.5) ...
Selecting previously unselected package python3-gnucash.
Preparing to unpack .../python3-gnucash_3.5_amd64.deb ...
Unpacking python3-gnucash (1:3.5) ...
Setting up python3-gnucash (1:3.5) ...
Setting up gnucash (1:3.5) ...
Processing triggers for mime-support (3.60ubuntu1) ...
Processing triggers for gnome-menus (3.32.0-1ubuntu1) ...
Processing triggers for man-db (2.8.5-2) ...
Processing triggers for desktop-file-utils (0.23-4ubuntu1) ...
It fired up and worked. Let me push these up to Google Drive and make
them available.
Thanks John. Could not have done this without your help!
--Steve
--
Stephen M Butler, PMP, PSM
stephen.m.butle...@gmail.com
kg...@arrl.net
253-350-0166
---
GnuPG Fingerprint: 8A25 9726 D439 758D D846 E5D4 282A 5477 0385 81D8
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Building 3.5 package for Disco
> On May 3, 2019, at 3:55 PM, Stephen M. Butler wrote:
>
> On 5/3/19 3:07 PM, Stephen M. Butler wrote:
>> On 5/3/19 2:57 PM, John Ralls wrote:
>>> <>
>>> Please copy All of the lines beginning with GTEST from the
>>> CMakeCache.txt in your debian-build controlled build directory. You
>>> can get that easily with
>>> grep ^GTEST path/to/CMakeCache.txt
>>>
>>> CMake doesn't care if there's whitespace between the -D and the variable
>>> name.
>>>
>>> Regars,
>>> John Ralls
>> grep -i gtest CM*.txt
>> GMOCK_INCLUDE_DIR:PATH=/home/steve/Projects/GnuCash/gnucash/.build/__gtest/googlemock/include
>> GMOCK_SRC_DIR:PATH=/home/steve/Projects/GnuCash/gnucash/.build/__gtest/googlemock
>> GTEST_INCLUDE_DIR:PATH=/home/steve/Projects/GnuCash/gnucash/.build/__gtest/googletest/include
>> GTEST_MAIN_LIB:FILEPATH=/usr/lib/x86_64-linux-gnu/libgtest_main.a
>> GTEST_ROOT:UNINITIALIZED=/usr/src/googletest/googletest
>> GTEST_SHARED_LIB:FILEPATH=/usr/lib/x86_64-linux-gnu/libgtest.a> //Found GTest
>> GTEST_FOUND:INTERNAL=YES
>>
>>
>> Part of the build rules copies /usr/src/googletest down to the build folder:
>>
>> mkdir -p .build/__gtest
>> cp -Rv /usr/src/googletest/* .build/__gtest/
>>
>> Perhaps I should point cmake to that location instead?
>>
> I made the change to point to the copy as noted above and hit same
> snag. Then tried to bypass the auto test and ran into this much further
> down the road:
>
>debian/rules override_dh_install
> make[1]: Entering directory '/home/steve/Projects/GnuCash/gnucash'
> rm -f -fv debian/tmp/usr/share/glib-2.0/schemas/gschemas.compiled #
> L:package-contains-compiled-glib-schema
> removed 'debian/tmp/usr/share/glib-2.0/schemas/gschemas.compiled'
> pod2man -s1 --stderr --utf8 debian/tmp/usr/bin/gnc-fq-check
> debian/tmp/gnc-fq-check.1
> find debian/tmp/usr/lib -name \*.la -exec rm -v \{\} \;
> dh_install
> make[1]: Leaving directory '/home/steve/Projects/GnuCash/gnucash'
>dh_installdocs -O--buildsystem=cmake -O--builddirectory=.build
>dh_installchangelogs -O--buildsystem=cmake -O--builddirectory=.build
>dh_installexamples -O--buildsystem=cmake -O--builddirectory=.build
>dh_installman -O--buildsystem=cmake -O--builddirectory=.build
>dh_installinfo -O--buildsystem=cmake -O--builddirectory=.build
> dh_installinfo: Cannot find (any matches for)
> "libgnucash/doc/design/gnucash-design.info" (tried in .)
>
> make: *** [debian/rules:24: binary] Error 2
> dpkg-buildpackage: error: fakeroot debian/rules binary subprocess
> returned exit status 2
>
> --
>
> override_dh_install has these lines:
>
> override_dh_install:
> $(RM) -fv
> debian/tmp/usr/share/glib-2.0/schemas/gschemas.compiled #
> L:package-contains-compiled-glib-schema
> pod2man -s1 --stderr --utf8 debian/tmp/usr/bin/gnc-fq-check
> debian/tmp/gnc-fq-check.1
> find debian/tmp/usr/lib -name \*.la -exec rm -v \{\} \;
> dh_install
>
> --
>
> gnucash.install has these lines:
>
> ## https://bugzilla.gnome.org/show_bug.cgi?id=790840
> usr/lib/*/gnucash/
>
> usr/bin/gnucash
> usr/bin/gnc-fq-check
> usr/bin/gnc-fq-dump
> usr/bin/gnc-fq-helper
> usr/bin/gnc-fq-update
> usr/share/applications/gnucash.desktop
> etc
>
> ---
>
> gnucash-common.install has this:
>
> usr/share/glib-2.0/schemas
> usr/share/gnucash
> usr/share/icons
> usr/share/locale
> usr/include
>
>
> python3-gnucash.install has these:
>
> ## https://bugzilla.gnome.org/show_bug.cgi?id=790550
> usr/lib/python*/dist-packages/gnucash/*.so
> =
>
> not sure which one was being processed.
gnucash-design.info is built only if you have make info installed. I wouldn't
bother, the document is severely obsolete. Just find it in your build
description and remove it.
Let's get back to gtest. I looked at gnc_gtest_configure() in
common/cmake_modules/GncAddTest.cmake and was reminded that if cmake finds
libgtest.a that it will ignore the source directory and use the system
libgtest.a.
The missing symbols are from libgtest.a, so maybe the linker is getting them in
the wrong order. Open GncAddTest.cmake in an editor and at line 137 change
set(GTEST_LIB "${GTEST_SHARED_LIB};${GTEST_MAIN_LIB}" PARENT_SCOPE)
to
set(GTEST_LIB "${GTEST_MAIN_LIB};${GTEST_SHARED_LIB}" PARENT_SCOPE)
and see if that fixes the error.
It's been that way for a long time so why it would suddenly matter is strange...
Regards,
John Ralls
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Building 3.5 package for Disco
On 5/3/19 3:07 PM, Stephen M. Butler wrote:
> On 5/3/19 2:57 PM, John Ralls wrote:
>> <>
>> Please copy All of the lines beginning with GTEST from the
>> CMakeCache.txt in your debian-build controlled build directory. You
>> can get that easily with
>> grep ^GTEST path/to/CMakeCache.txt
>>
>> CMake doesn't care if there's whitespace between the -D and the variable
>> name.
>>
>> Regars,
>> John Ralls
> grep -i gtest CM*.txt
> GMOCK_INCLUDE_DIR:PATH=/home/steve/Projects/GnuCash/gnucash/.build/__gtest/googlemock/include
> GMOCK_SRC_DIR:PATH=/home/steve/Projects/GnuCash/gnucash/.build/__gtest/googlemock
> GTEST_INCLUDE_DIR:PATH=/home/steve/Projects/GnuCash/gnucash/.build/__gtest/googletest/include
> GTEST_MAIN_LIB:FILEPATH=/usr/lib/x86_64-linux-gnu/libgtest_main.a
> GTEST_ROOT:UNINITIALIZED=/usr/src/googletest/googletest
> GTEST_SHARED_LIB:FILEPATH=/usr/lib/x86_64-linux-gnu/libgtest.a //Found GTest
> GTEST_FOUND:INTERNAL=YES
>
>
> Part of the build rules copies /usr/src/googletest down to the build folder:
>
> mkdir -p .build/__gtest
> cp -Rv /usr/src/googletest/* .build/__gtest/
>
> Perhaps I should point cmake to that location instead?
>
I made the change to point to the copy as noted above and hit same
snag. Then tried to bypass the auto test and ran into this much further
down the road:
debian/rules override_dh_install
make[1]: Entering directory '/home/steve/Projects/GnuCash/gnucash'
rm -f -fv debian/tmp/usr/share/glib-2.0/schemas/gschemas.compiled #
L:package-contains-compiled-glib-schema
removed 'debian/tmp/usr/share/glib-2.0/schemas/gschemas.compiled'
pod2man -s1 --stderr --utf8 debian/tmp/usr/bin/gnc-fq-check
debian/tmp/gnc-fq-check.1
find debian/tmp/usr/lib -name \*.la -exec rm -v \{\} \;
dh_install
make[1]: Leaving directory '/home/steve/Projects/GnuCash/gnucash'
dh_installdocs -O--buildsystem=cmake -O--builddirectory=.build
dh_installchangelogs -O--buildsystem=cmake -O--builddirectory=.build
dh_installexamples -O--buildsystem=cmake -O--builddirectory=.build
dh_installman -O--buildsystem=cmake -O--builddirectory=.build
dh_installinfo -O--buildsystem=cmake -O--builddirectory=.build
dh_installinfo: Cannot find (any matches for)
"libgnucash/doc/design/gnucash-design.info" (tried in .)
make: *** [debian/rules:24: binary] Error 2
dpkg-buildpackage: error: fakeroot debian/rules binary subprocess
returned exit status 2
--
override_dh_install has these lines:
override_dh_install:
$(RM) -fv
debian/tmp/usr/share/glib-2.0/schemas/gschemas.compiled #
L:package-contains-compiled-glib-schema
pod2man -s1 --stderr --utf8 debian/tmp/usr/bin/gnc-fq-check
debian/tmp/gnc-fq-check.1
find debian/tmp/usr/lib -name \*.la -exec rm -v \{\} \;
dh_install
--
gnucash.install has these lines:
## https://bugzilla.gnome.org/show_bug.cgi?id=790840
usr/lib/*/gnucash/
usr/bin/gnucash
usr/bin/gnc-fq-check
usr/bin/gnc-fq-dump
usr/bin/gnc-fq-helper
usr/bin/gnc-fq-update
usr/share/applications/gnucash.desktop
etc
---
gnucash-common.install has this:
usr/share/glib-2.0/schemas
usr/share/gnucash
usr/share/icons
usr/share/locale
usr/include
python3-gnucash.install has these:
## https://bugzilla.gnome.org/show_bug.cgi?id=790550
usr/lib/python*/dist-packages/gnucash/*.so
=
not sure which one was being processed.
--
Stephen M Butler, PMP, PSM
stephen.m.butle...@gmail.com
kg...@arrl.net
253-350-0166
---
GnuPG Fingerprint: 8A25 9726 D439 758D D846 E5D4 282A 5477 0385 81D8
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Building 3.5 package for Disco
On 5/3/19 2:57 PM, John Ralls wrote: > On May 3, 2019, at 2:44 PM, Stephen M. Butler wrote: >> On 5/3/19 12:24 PM, John Ralls wrote: >>> On May 3, 2019, at 8:37 AM, Stephen M. Butler wrote: On 5/2/19 10:14 PM, John Ralls wrote: >> On May 2, 2019, at 6:38 PM, Stephen M. Butler wrote: >> >> /usr/bin/ld: >> /usr/lib/gcc/x86_64-linux-gnu/8/../../../x86_64-linux-gnu/libgtest_main.a(gtest_main.cc.o): > It's linking a system file instead of the one that GnuCash should have > built. Is it linking that libgtest_main.a when you do a regular build? > > Regards, > John Ralls > > Yes, it appears to have done that. I see this line in the CMakeCache.txt file in my local build directory from the test yesterday (not the directory where dpkg_buildpackage worked) //Path to a library. GTEST_MAIN_LIB:FILEPATH=/usr/lib/x86_64-linux-gnu/libgtest_main.a I have attached the CMakeCache.txt file if that helps. >>> The CMakeCache.txt shows what looks like a typo: >>> GTEST_ROOT:UNINITIALIZED=/usr/src/googletest/googletesti >>> >>> What does the GTEST section of the debian-build CMakeCache.txt look like? >>> >>> Regards >>> John Ralls >>-DGTEST_ROOT=/usr/src/googletest/googletest \ >>-DGMOCK_ROOT=/usr/src/googletest/googlemock \ >> >> Do I need a space after the -D? > That isn't from CMakeCache.txt. Please copy All of the lines beginning with > GTEST from the CMakeCache.txt in your debian-build controlled build > directory. You can get that easily with > grep ^GTEST path/to/CMakeCache.txt > > CMake doesn't care if there's whitespace between the -D and the variable name. > > Regars, > John Ralls grep -i gtest CM*.txt GMOCK_INCLUDE_DIR:PATH=/home/steve/Projects/GnuCash/gnucash/.build/__gtest/googlemock/include GMOCK_SRC_DIR:PATH=/home/steve/Projects/GnuCash/gnucash/.build/__gtest/googlemock GTEST_INCLUDE_DIR:PATH=/home/steve/Projects/GnuCash/gnucash/.build/__gtest/googletest/include GTEST_MAIN_LIB:FILEPATH=/usr/lib/x86_64-linux-gnu/libgtest_main.a GTEST_ROOT:UNINITIALIZED=/usr/src/googletest/googletest GTEST_SHARED_LIB:FILEPATH=/usr/lib/x86_64-linux-gnu/libgtest.a //Found GTest GTEST_FOUND:INTERNAL=YES Part of the build rules copies /usr/src/googletest down to the build folder: mkdir -p .build/__gtest cp -Rv /usr/src/googletest/* .build/__gtest/ Perhaps I should point cmake to that location instead? -- Stephen M Butler, PMP, PSM stephen.m.butle...@gmail.com kg...@arrl.net 253-350-0166 --- GnuPG Fingerprint: 8A25 9726 D439 758D D846 E5D4 282A 5477 0385 81D8 ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Building 3.5 package for Disco
> On May 3, 2019, at 2:44 PM, Stephen M. Butler wrote: > > On 5/3/19 12:24 PM, John Ralls wrote: >> >>> On May 3, 2019, at 8:37 AM, Stephen M. Butler wrote: >>> >>> On 5/2/19 10:14 PM, John Ralls wrote: > On May 2, 2019, at 6:38 PM, Stephen M. Butler wrote: > > /usr/bin/ld: > /usr/lib/gcc/x86_64-linux-gnu/8/../../../x86_64-linux-gnu/libgtest_main.a(gtest_main.cc.o): It's linking a system file instead of the one that GnuCash should have built. Is it linking that libgtest_main.a when you do a regular build? Regards, John Ralls >>> Yes, it appears to have done that. I see this line in the >>> CMakeCache.txt file in my local build directory from the test yesterday >>> (not the directory where dpkg_buildpackage worked) >>> >>> //Path to a library. >>> GTEST_MAIN_LIB:FILEPATH=/usr/lib/x86_64-linux-gnu/libgtest_main.a >>> >>> >>> I have attached the CMakeCache.txt file if that helps. >> The CMakeCache.txt shows what looks like a typo: >> GTEST_ROOT:UNINITIALIZED=/usr/src/googletest/googletesti >> >> What does the GTEST section of the debian-build CMakeCache.txt look like? >> >> Regards >> John Ralls >> >> >-DGTEST_ROOT=/usr/src/googletest/googletest \ >-DGMOCK_ROOT=/usr/src/googletest/googlemock \ > > > Do I need a space after the -D? That isn't from CMakeCache.txt. Please copy All of the lines beginning with GTEST from the CMakeCache.txt in your debian-build controlled build directory. You can get that easily with grep ^GTEST path/to/CMakeCache.txt CMake doesn't care if there's whitespace between the -D and the variable name. Regars, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Building 3.5 package for Disco
On 5/3/19 12:24 PM, John Ralls wrote: > >> On May 3, 2019, at 8:37 AM, Stephen M. Butler wrote: >> >> On 5/2/19 10:14 PM, John Ralls wrote: On May 2, 2019, at 6:38 PM, Stephen M. Butler wrote: /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/8/../../../x86_64-linux-gnu/libgtest_main.a(gtest_main.cc.o): >>> It's linking a system file instead of the one that GnuCash should have >>> built. Is it linking that libgtest_main.a when you do a regular build? >>> >>> Regards, >>> John Ralls >>> >>> >> Yes, it appears to have done that. I see this line in the >> CMakeCache.txt file in my local build directory from the test yesterday >> (not the directory where dpkg_buildpackage worked) >> >> //Path to a library. >> GTEST_MAIN_LIB:FILEPATH=/usr/lib/x86_64-linux-gnu/libgtest_main.a >> >> >> I have attached the CMakeCache.txt file if that helps. > The CMakeCache.txt shows what looks like a typo: > GTEST_ROOT:UNINITIALIZED=/usr/src/googletest/googletesti > > What does the GTEST section of the debian-build CMakeCache.txt look like? > > Regards > John Ralls > > -DGTEST_ROOT=/usr/src/googletest/googletest \ -DGMOCK_ROOT=/usr/src/googletest/googlemock \ Do I need a space after the -D? -- Stephen M Butler, PMP, PSM stephen.m.butle...@gmail.com kg...@arrl.net 253-350-0166 --- GnuPG Fingerprint: 8A25 9726 D439 758D D846 E5D4 282A 5477 0385 81D8 ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] pressing forward will take you back
Am Fr., 3. Mai 2019 um 18:07 Uhr schrieb Geert Janssens < geert.gnuc...@kobaltwit.be>: > Op vrijdag 3 mei 2019 15:26:54 CEST schreef Frank H. Ellenberger: : > > 5 contains the text and the back button is removed. So it is impossible > to > > go back and adjust settings. > > > You don't have to go back manually. If you click "Forward"/"Next" gnucash > will > perform a number of checks. If one of those checks fails you'll be > redirected > to the preview page automatically. The use of the word "back" in that > sentence > is confusing. > I have incorporated this in the existing text and tried to make also the rest clearer by reordering. https://github.com/Gnucash/gnucash/commit/76936bc646737116e24306c931d46141914aff00 > Another issue: changes on page 3 are overwritten by defaults after > clicking > > back on page 4. > > > That is worth improving. > Right, but I am now out of town over the wekend > Geert > Frank ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
[GNC-dev] GnuCash Wiki Registration restored
Hi, Today it was reported that Wiki new-user registrations were not working. We traced this down to an update to mediawiki without also updating an extension back in February. This presented as an Internal Error whenever someone tried to register for a wiki account. The errant extensions have been updated and the resigration service should now be working. We apologize if you were affected by this outage. -derek -- Derek Atkins 617-623-3745 de...@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Building 3.5 package for Disco
> On May 3, 2019, at 8:37 AM, Stephen M. Butler wrote: > > On 5/2/19 10:14 PM, John Ralls wrote: >> >>> On May 2, 2019, at 6:38 PM, Stephen M. Butler wrote: >>> >>> /usr/bin/ld: >>> /usr/lib/gcc/x86_64-linux-gnu/8/../../../x86_64-linux-gnu/libgtest_main.a(gtest_main.cc.o): >> It's linking a system file instead of the one that GnuCash should have >> built. Is it linking that libgtest_main.a when you do a regular build? >> >> Regards, >> John Ralls >> >> > Yes, it appears to have done that. I see this line in the > CMakeCache.txt file in my local build directory from the test yesterday > (not the directory where dpkg_buildpackage worked) > > //Path to a library. > GTEST_MAIN_LIB:FILEPATH=/usr/lib/x86_64-linux-gnu/libgtest_main.a > > > I have attached the CMakeCache.txt file if that helps. The CMakeCache.txt shows what looks like a typo: GTEST_ROOT:UNINITIALIZED=/usr/src/googletest/googletesti What does the GTEST section of the debian-build CMakeCache.txt look like? Regards John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] pressing forward will take you back
Op vrijdag 3 mei 2019 15:26:54 CEST schreef Frank H. Ellenberger: > Hi David, > > no, itt is a problem with the structure of the assistant: > 1. Intro > 2. Select file > 3. Preview with many settings to choose > 4. Match accounts > 5. Txn Info > 6. Match txns > 7. Summary > > 5 contains the text and the back button is removed. So it is impossible to > go back and adjust settings. > You don't have to go back manually. If you click "Forward"/"Next" gnucash will perform a number of checks. If one of those checks fails you'll be redirected to the preview page automatically. The use of the word "back" in that sentence is confusing. > Another issue: changes on page 3 are overwritten by defaults after clicking > back on page 4. > That is worth improving. Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Building 3.5 package for Disco
On 5/2/19 10:05 PM, John Ralls wrote: > >> On May 2, 2019, at 6:12 PM, Stephen M. Butler wrote: >> >> <> >> == >> >> Do I need to file a bug for any of the above? > Steve, > > Nope, those are all either known- or non-problems. > > Regards, > John Ralls > > Thanks John. Thought that might be the case. -- Stephen M Butler, PMP, PSM stephen.m.butle...@gmail.com kg...@arrl.net 253-350-0166 --- GnuPG Fingerprint: 8A25 9726 D439 758D D846 E5D4 282A 5477 0385 81D8 ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] pressing forward will take you back
Hi David, no, itt is a problem with the structure of the assistant: 1. Intro 2. Select file 3. Preview with many settings to choose 4. Match accounts 5. Txn Info 6. Match txns 7. Summary 5 contains the text and the back button is removed. So it is impossible to go back and adjust settings. Another issue: changes on page 3 are overwritten by defaults after clicking back on page 4. Regards Frank Am Fr., 3. Mai 2019 um 14:21 Uhr schrieb David Carlson < david.carlson@gmail.com>: > Is that a problem with translations? What if you use the word "Continue" > in English? > > On Fri, May 3, 2019 at 6:42 AM Frank H. Ellenberger < > frank.h.ellenber...@gmail.com> wrote: > >> While I replaced the references to the by "Next" replaced "Forward" >> buttons, I stumbled over >> "If there were problems with the import settings, pressing forward will >> take you back to the preview page to try and correct." >> in assistant-csv-trans-import.glade. >> >> From the current structure of the assistant, I thought, I would replace >> "forward" by "back twice", but the back button is disabled in this state, >> which makes it impossible to go back to the configuraion page. >> >> I am also wondering why this page is of type progress. >> Regards >> >> Frank >> ___ >> gnucash-devel mailing list >> gnucash-devel@gnucash.org >> https://lists.gnucash.org/mailman/listinfo/gnucash-devel >> > > > -- > David Carlson > ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] pressing forward will take you back
Is that a problem with translations? What if you use the word "Continue" in English? On Fri, May 3, 2019 at 6:42 AM Frank H. Ellenberger < frank.h.ellenber...@gmail.com> wrote: > While I replaced the references to the by "Next" replaced "Forward" > buttons, I stumbled over > "If there were problems with the import settings, pressing forward will > take you back to the preview page to try and correct." > in assistant-csv-trans-import.glade. > > From the current structure of the assistant, I thought, I would replace > "forward" by "back twice", but the back button is disabled in this state, > which makes it impossible to go back to the configuraion page. > > I am also wondering why this page is of type progress. > Regards > > Frank > ___ > gnucash-devel mailing list > gnucash-devel@gnucash.org > https://lists.gnucash.org/mailman/listinfo/gnucash-devel > -- David Carlson ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] About the "$HOME/.local" installation prefix
Geert, Agree with all the points you and david Carlson made. I had expected and guessed that the GnuCashbuild configured its search directories for resources from the cmake install prefix, but hadn't actually checked it out to be sure. The problem as I see it is recommending a setup for a novice or inexperienced user new to building and installing who may or may not have admin privileges to use that will allow them to install and uninstall fairly easily even when they no longer have the build directory and access to the make uninstall. Even with a little bit of development experience you can usually work it out for yourself. A user who is primarily interested in just using Gnucash and doesn't want to know about the nitty gritty of development per se but wants to be using the most up to date version, on the other hand, will get frustrated if every time he has to update, he has to figure out what went where and how to get rid of it. I'll rework the Wiki page to use a non hidden directory with a gnucash specific subdirectory as an install point in the example rather than $HOME/.local and just add notes to the effect that this directory can be hidden if desired by prefixing it with a dot. Then a simple rm -rf can be used easily. I'll also add some notes about setting up aliases to start it up. That should cover the user new to building from source. Then anyone who wants a more sophisticated setup can roll their own. cheers David Cousens - David Cousens -- Sent from: http://gnucash.1415818.n4.nabble.com/GnuCash-Dev-f1435356.html ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] About the "$HOME/.local" installation prefix
Colin There is no reason why the install directory can't just be an ordinary directory. There is no real reason for it to be hidden. It is what I use if I do do a local install. The only possible advantage is that if you can hide the directory it doesn't clutter the view of files when you won't be looking at program files the majority of the time even though you will be using them David - David Cousens -- Sent from: http://gnucash.1415818.n4.nabble.com/GnuCash-Dev-f1435356.html ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
[GNC-dev] pressing forward will take you back
While I replaced the references to the by "Next" replaced "Forward" buttons, I stumbled over "If there were problems with the import settings, pressing forward will take you back to the preview page to try and correct." in assistant-csv-trans-import.glade. >From the current structure of the assistant, I thought, I would replace "forward" by "back twice", but the back button is disabled in this state, which makes it impossible to go back to the configuraion page. I am also wondering why this page is of type progress. Regards Frank ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] [GNC] UK VAT and "Making Tax Digital"
Hi Christopher, responses inline: On Thursday, 2 May 2019 12:36:06 BST Christopher Lam wrote: > Are you referring to the Multicolumn report with multiple embedded reports? > This one would be very annoying to create CSV export from... each embedded > report exposes its html output only. > That was the report I was thinking of, not surprised that CSV would be hard to generate. > The links I attached earlier (replacing transaction.scm and > income-gst-statement.scm) would enable CSV export, exposing the headers and > the grand-totals. > Correct, that is what I see. but the totals are wrong because the report can't consider the asset purchases. > Meanwhile I'm rather more interested in generating a proper solution :-) > > For UK VAT I'd think the more complex requirements here would warrant a > customised solution based on the existing VAT account structure, rather > than to try shoehorn hacks on the existing report. > Fair enough. I guess the GST report was written with Oz in mind and then generalised a bit. > If you can create a sample datafile based on the CoA as suggested by > New-account wizard, No problem, will take your template file and try to get that sorted over the weekend or early next week. thanks, Maf. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Fwd: [GNC] UK VAT and "Making Tax Digital"
Hi Christopher, thanks, I've just subscribed to -devel I can see no reason for anything other than GBP in a UK VAT return! sensible restriction. Maf. On Thursday, 2 May 2019 16:44:59 BST Christopher Lam wrote: > Maf's reply forwarded to devel. > > I think a sensible restriction to vat-report will be: all amounts *must* be > converted into a report-currency... which will then ensure there's only 1 > currency for grand-total, therefore 1 heading + 1 grand-total = 1 csv row. > > -- Forwarded message - > From: Maf. King > Date: Thu, 2 May 2019 at 13:36 > Subject: Re: [GNC] UK VAT and "Making Tax Digital" > To: Christopher Lam > Cc: gnucash-devel > > > Hi Christopher, > > responses inline: > > On Thursday, 2 May 2019 12:36:06 BST Christopher Lam wrote: > > Are you referring to the Multicolumn report with multiple embedded > > reports? > > > This one would be very annoying to create CSV export from... each embedded > > report exposes its html output only. > > That was the report I was thinking of, not surprised that CSV would be hard > to > generate. > > > The links I attached earlier (replacing transaction.scm and > > income-gst-statement.scm) would enable CSV export, exposing the headers > > and > > > the grand-totals. > > Correct, that is what I see. but the totals are wrong because the report > can't consider the asset purchases. > > > Meanwhile I'm rather more interested in generating a proper solution :-) > > > > For UK VAT I'd think the more complex requirements here would warrant a > > customised solution based on the existing VAT account structure, rather > > than to try shoehorn hacks on the existing report. > > Fair enough. I guess the GST report was written with Oz in mind and then > generalised a bit. > > > If you can create a sample datafile based on the CoA as suggested by > > New-account wizard, > > No problem, will take your template file and try to get that sorted over > the > weekend or early next week. > > thanks, > Maf. -- Maf. King PGP Key fingerprint = 8D68 A91F 733B 2C1F 43B7 2B7C E591 E8E1 0DE7 C542 ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] About the "$HOME/.local" installation prefix
Op vrijdag 3 mei 2019 03:09:43 CEST schreef David Cousens: > Hi John, > > It was because of a number of posts in the forum, not sure whether DEV or > USER around the time I reworked the pages which suggested $HOME/.local for > single user local installations of GnuCash . I think it may also have been > specified the previous Wiki page I started from as well. At the time I could > not find any better suggestions so I left it in place. My own preference > has been to install in /usr/local or /opt system wide for production. If > you use make uninstall from the build directory it seems to uninstall > correctly from $HOME/.local as long as the manifest still exists as the > paths to each file installed are specified > Indeed. That's the mechanism in place to uninstall packages. It has a few flaws though. For this to work 1. the build directory is still around 2. the current state of the build directory still would install files in the same spot and at least the same files as the original install. I have been bitten both ways (one of the conditions didn't apply any more). These flaws are what triggered the creation of package managers. So in general I prefer installing via make install into a unique directory per installed application. That way the above pitfalls don't matter. If something changes such that make uninstall can't clean up, you can simply remove the complete installation directory. > If I do a local temporary install, I personally install in a subdirectory of > my home directory and add the relevant search paths to the front of the > PATH environment variable . You of course have the problem with the order > in PATH as to whether you search $HOME directories before or after system > installed paths if you have multiple copies of different versions. Ideally > in that case you could invoke a startup script which setup the PATH > variable depending on which version you are starting up and where its > resouces are located. I have used /opt and /usr/local for different > versions but the same problem with ordering the search order in PATH > arises. You could also define aliases to deal with this, like alias gnucash-my-build = /home/user/path/to/my/install/bin/gnucash Then "gnucash" would run the system installed gnucash, "gnucash-my-build" would run your own Or, as I would think most users would like to start gnucash from their Destkop environment's menu or application launcher, you can copy the gnucash.desktop file from /share/applications to /home/user/.local/share/ applications. If you then edit the file and change the "Name" value to say "My GnuCash" (and do the same for the Name in your language), you can start "My GnuCash" from your DE's menu or application launcher. You may have to log out and back in for this to work. > > Python installs what it calls site-packages under $HOME/.local which seem to > be user specific but most of the other data I find in the directory is in > $HOME/.local/share which seems to be mainly user specific data for various > packages. > > The Linux File Heirarchy gives no real guidance for the structure of a users > home directory apart from a reference to XDG and GLib conventions ( can't > find any reference): > > https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html > > One stackexchange article suggested duplicating sections of the FHS under > $HOME which seems a bit extreme. I believe that suggestion goes with the concept of having $HOME/bin on the PATH. But the weakness of installing multiple applications in the same install prefix without the safety net of a decent package manager remains. > If I did that I would be inclined to have a > specific directory under $HOME with the /bin, /etc, /lib /share directories > under it. I have an Applications directory for that purpose usually with a > package sub directory under that which contains the above directories. > I'm more in favor of this approach as well. > For the little development work on GnuCash I do I have a separate structure > again under my home directory which has an install subdirectory which I > install to. Same here. > I have often wondered whether I am actually getting to the > correct libraries by setting up the PATH variable (particularly if I forget > to set it up). Then there is unsetting PATH when you want to go back to > production work. You shouldn't worry about setting paths for getting the proper libraries. GnuCash should take care of this itself. It's encoded based on the installation prefix you provide while running cmake. The only reason to add something to the PATH is to allow you to simply type "gnucash" somewhere in a shell and that would then start your local installation. But even that's entirely optional. You could just as well start it by using the full path to the binary, make an alias as described above or move it up your path by adding a softlink from $HOME/bin to your gnucash binary. Both of the latter options
Re: [GNC-dev] About the "$HOME/.local" installation prefix
On Fri, 3 May 2019 at 07:26, David Cousens wrote: > ... > I.e. we recommend using cmake commands as follows for inexperienced or users > who don't have admin privileges rather than simply installing directly under > $HOME/.local which already has a gnucash directory for GnuCash user > preferences. > > cmake -DCMAKE_INSTALL_PREFIX=$HOME/.local/programs/gnucash absolute path to sources> > > If you think this is a better idea (or there is another more general > alternative I can update the Wiki build instructions to reflect this. The > user could then create an alias in the bashrc file to access the executable > and/or add it to their launcher etc. I really don't like the idea of installing under a hidden directory (~/.local). Colin ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] About the "$HOME/.local" installation prefix
John, Geert et al I have not been able to find any references on user directory organization apart from the XDG (https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html). There was one comment in this link (https://itsfoss.com/install-software-from-source-code/) which suggests that software installed in /opt from source expects to find its resources in directories relative to a package parent directory in /opt. and that this is why simlinks are used from/usr/bin or /usr/local/bin to the executable in /opt/ where the application stores its resources relative to /opt/. This seems to be how LibreOffice is installed on Linux Mint for example. I haven't had gnucash installed in /opt for quite a while now (or $HOME/.local) but I remember noticing that the resources for/opt were under a package directory. If the same situation (i.e. the ability to find program resources in a relative directory structure) applies for the installation in a user directory rather than installing directly under $HOME/.local we could recommend installing to a subdirectory of this location specifically for program installations and in turn create a directory under that for gnucash which would contain the executable and its resources. This would then facilitate easy removal of the package from a users home directory by simply deleting the package level directory to simplify things for inexperienced users. The above seems to be the case as I install development builds to an install subdirectory which is a subdirectory of a main directory which contains my gnucash sources and separate build directories for make and ninja etc and I have never detected that starting gnucash from the .../install/bin/gnucash executable has accessed resouces for production builds which I have installed in /usr/local. Can't be definitive about that but it has included changes to gnucash library files which appeared in the executable which wouldn't be the case if it was picking up libraries from the system installation. I guess this was the munge of the file locations that occurs with cmake for /opt and $HOME/.local type installations you referred to in an earlier post compared with installation in a system location. I.e. we recommend using cmake commands as follows for inexperienced or users who don't have admin privileges rather than simply installing directly under $HOME/.local which already has a gnucash directory for GnuCash user preferences. cmake -DCMAKE_INSTALL_PREFIX=$HOME/.local/programs/gnucash If you think this is a better idea (or there is another more general alternative I can update the Wiki build instructions to reflect this. The user could then create an alias in the bashrc file to access the executable and/or add it to their launcher etc. David Cousens - David Cousens -- Sent from: http://gnucash.1415818.n4.nabble.com/GnuCash-Dev-f1435356.html ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
