2020-02-06 GnuCash IRC logs
00:04:36 *** timetravellers has joined #gnucash
00:04:36 *** ChanServ sets mode: +v timetravellers
00:59:12 *** Mechtilde has joined #gnucash
00:59:34 *** warlord has quit IRC
01:02:02 *** Gerd has joined #gnucash
01:02:49 *** Mechtilde has quit IRC
01:03:15 *** Mechtilde has joined #gnucash
01:20:45 *** Gerd has quit IRC
01:29:31 *** chf has joined #gnucash
01:44:07 *** sbluhm has joined #gnucash
01:55:54 *** hussam has joined #gnucash
01:55:54 *** ChanServ sets mode: +v hussam
01:56:33 *** fell has joined #gnucash
01:56:34 *** ChanServ sets mode: +o fell
01:57:51 *** Mechtilde has quit IRC
01:58:28 *** fell_laptop has quit IRC
02:00:12 *** TownsendHardware has quit IRC
02:01:05 *** TownsendHardware has joined #gnucash
02:01:24 *** sbluhm has quit IRC
02:06:37 *** chf has quit IRC
02:06:46 *** sbluhm has joined #gnucash
02:10:12 *** sbluhm has quit IRC
02:10:44 *** sbluhm has joined #gnucash
02:31:47 *** Aussie_matt has quit IRC
02:33:08 *** bertbob has quit IRC
02:35:18 *** bertbob has joined #gnucash
02:35:18 *** ChanServ sets mode: +v bertbob
02:37:56 *** timetravellers has quit IRC
03:03:46 *** sbluhm has quit IRC
03:18:25 *** sbluhm has joined #gnucash
03:18:25 *** ChanServ sets mode: +v sbluhm
03:18:55 *** sbluhm has quit IRC
03:28:34 *** sbluhm has joined #gnucash
03:28:34 *** ChanServ sets mode: +v sbluhm
03:30:14 *** gjanssens has joined #gnucash
03:30:14 *** ChanServ sets mode: +o gjanssens
03:51:18 *** KevinDB has quit IRC
03:52:43 *** KevinDB has joined #gnucash
03:52:43 *** ChanServ sets mode: +v KevinDB
03:57:36 *** sbluhm has quit IRC
04:10:18 *** sbluhm has joined #gnucash
04:46:18 *** sbluhm has quit IRC
05:03:49 *** sbluhm has joined #gnucash
05:16:57 *** Mechtilde has joined #gnucash
05:23:29 <gjanssens> .
05:28:34 *** sbluhm has quit IRC
05:37:51 *** Mechtilde has quit IRC
05:45:23 *** User__ has joined #gnucash
05:45:41 *** sbluhm has joined #gnucash
06:00:00 *** User__ has quit IRC
06:02:29 *** chf has joined #gnucash
06:12:00 *** Jimraehl1 has joined #gnucash
06:14:19 *** fell has quit IRC
06:16:23 *** omnireq_ has quit IRC
06:16:34 *** omnireq_ has joined #gnucash
06:17:28 *** storyjesse has quit IRC
06:37:36 *** Mechtilde has joined #gnucash
06:51:05 *** warlord has joined #gnucash
06:51:05 *** gncbot sets mode: +o warlord
06:55:20 <chris> gjanssens: your patch is fine too. I think #643 can be merged in. budgets-current and budgets-unreversed both behave correctly.
06:55:57 <warlord> .
06:58:23 *** omnireq_ has quit IRC
06:58:34 *** omnireq_ has joined #gnucash
07:02:24 *** hussam has quit IRC
07:03:39 *** immae has quit IRC
07:06:35 <gjanssens> chris: go for it
07:14:58 *** immae has joined #gnucash
07:15:11 *** fady has joined #gnucash
07:18:30 *** fady has quit IRC
07:34:39 *** fell has joined #gnucash
07:34:39 *** ChanServ sets mode: +o fell
07:39:53 *** omnireq_ has quit IRC
07:40:21 *** omnireq_ has joined #gnucash
07:42:49 <chris> maint->master merge is tricky again
08:33:48 *** hussam has joined #gnucash
08:33:48 *** ChanServ sets mode: +v hussam
08:34:40 *** hussam has quit IRC
08:35:22 *** hussam has joined #gnucash
08:35:22 *** ChanServ sets mode: +v hussam
08:57:49 *** Mechtilde has quit IRC
09:02:23 *** omnireq_ has quit IRC
09:03:10 *** omnireq_ has joined #gnucash
09:09:18 *** Gerd has joined #gnucash
09:16:03 *** MatrixTravelerbot[m] has quit IRC
09:16:18 *** luwum[m] has quit IRC
09:16:18 *** habicht[m] has quit IRC
09:16:18 *** ElonSatoshi[m] has quit IRC
09:16:55 *** sunyibo[m] has quit IRC
09:16:55 *** peter-butler[m] has quit IRC
09:16:55 *** Couto[m] has quit IRC
09:16:55 *** mmkodali[m] has quit IRC
09:25:06 *** Couto[m] has joined #gnucash
09:44:53 *** omnireq_ has quit IRC
09:45:08 *** omnireq_ has joined #gnucash
10:01:31 <chris> https://www.fool.com/the-blueprint/gnucash-review/
10:01:35 <chris> https://opensource.com/article/20/2/gnucash
10:04:59 <warlord> chris, COOL! Thanks for sharing!
10:07:36 <warlord> Which reminds me, I forgot to update the news section that the maintenance is complete.
10:17:24 *** Gerd has quit IRC
10:22:49 *** Mechtilde has joined #gnucash
10:29:00 *** Mechtilde has quit IRC
10:36:10 *** omnireq_ has quit IRC
10:50:56 *** Agfarmer18 has joined #gnucash
10:52:54 <gnomey> i launch gnucash and immediately there is a "*" next to the file name. I did not change anything, and all my scheduled txns are set to notify me. Yet I received no notification.
10:53:24 <gnomey> so I hit control-S control-q to save and exit, and I relaunch
10:53:37 <gnomey> immediately the "*" is again next to the filename
10:54:07 <gnomey> happens every time now
10:54:25 <warlord> gnomey, what version of gnucash?
10:54:29 <warlord> And what platform?
10:55:34 <gnomey> it's the latest debian stretch version. Checking..
10:55:50 <gnomey> 2.6.15
10:58:18 <gnomey> i should also mention that i accidentally mistyped a stock when adding a new stock. There is no way to correct this in the GUI. I had to open the XML in emacs and remove the record of the mistyped stock.
11:00:12 <gnomey> I've even done a "save as.." and then started using the new datafile, thinking that perhaps "save as.." would do a top-to-bottom rewrite of the data. That did not help
11:02:40 <warlord> Where did you mistype it? Why not edit it in the security editor?
11:02:50 <gnomey> i had this problem for years (where the "*" would show a change every launch w/out showing what changed). It was then finally fixed for like a year or so.. not sure how it was fixed. now it's back
11:02:55 <warlord> As for 2.6.15 --- Umm, that is WAY out of date, like YEARS old. 3.8 is current stable.
11:03:24 <gnomey> oh shit.. i didn't know about the security editor
11:03:29 <gnomey> thanks for that tip!
11:03:33 <warlord> Yeah, there was an issue about that.. It was fixed a long time ago. No clue when or which version, but you're not even running the latest 2.6 release!
11:06:26 <gnomey> man, it'll be annoying to see the false change indicator.. perhaps for a year to come, but it wouldn't be worth it to take steps like doing a backports upgrade just for the chance of fixing it
11:06:32 <gnomey> i'll just have to live with it
11:08:36 <warlord> sorry
11:09:33 *** kael has joined #gnucash
11:09:33 *** ChanServ sets mode: +v kael
11:13:09 <gnomey> so i'm in the security editor, and it will not let me remove the bad security saying the "commodity is being used". Yet it's not, because I removed the transaction.
11:13:28 <gjanssens> chris: maint->master merge has been pushed for your convenience :)
11:13:46 *** omnireq has joined #gnucash
11:13:46 *** ChanServ sets mode: +v omnireq
11:13:57 <gjanssens> gnomey: is it still in the price editor, or an account denominated in that security ?
11:16:09 <gnomey> gjanssens: i actually have a duplicate of the same security, and one of the securities has an account for it. I tried deleting the /other/ one (the one w/out an account) and it refused. I suppose the software may be mixing them up because they have the same ticker.
11:16:27 <gnomey> but I'll delete the one account as well, since there are no transactions. That will probably solve it
11:16:48 *** Agfarmer18 has quit IRC
11:17:16 <gnomey> i'll delete the account linked to the security, then I'll delete both securities and start over
11:18:04 <gnomey> ah, i can see i had an account for both.. sorry for the confusion
11:18:56 <gnomey> gjanssens: thanks for the tip.. that fixed it
11:19:18 <gjanssens> you're welcome
11:20:10 <gnomey> the reason for the mess was that the same stock had two different tickers, and my broker uses the two tickers interchangably
11:20:51 <gnomey> so it caused me to create two records for the same security
11:20:56 <warlord> Weird
11:21:23 <gnomey> i've never seen this on the US markets, but the European stock markets have this annoying characteristic
11:22:08 <gnomey> so a few of my stock accounts are named "symbol1 aka symbol2" so i can keep it straight
11:23:03 <gnomey> i also do that when there's a corporate action where one stock becomes owned by another, and happens in all markets
11:24:20 <gnomey> so when oracle bought Sun, I had something like "ORCL aka JAVA aka SUNM"
11:25:51 *** ArtGravity has joined #gnucash
11:25:51 *** ChanServ sets mode: +v ArtGravity
11:26:20 *** kael has quit IRC
11:26:20 *** kael1 has joined #gnucash
11:26:20 *** ChanServ sets mode: +v kael1
11:28:49 *** kael1 is now known as kael
11:32:44 *** Couto[m] has quit IRC
11:36:11 *** fell has quit IRC
11:39:20 <jralls> gnomey, not only are you using an obsolete release of GnuCash, you're running an obsolete release of Debian.
11:41:39 <gnomey> jralls: yeah, i do need to get my shit together and dist-upgrade. I've seen dist-upgrade hose a whole system so I'll have to set aside a day where i doubly backup everything and pull the trigger, and reserve time for disaster recovery
11:42:22 <jralls> OK. FWIW I upgraded my server to buster with no hiccups at all.
11:42:39 <gnomey> but i think it's wrong to say stretch is "obsolete". It's not the latest, but AFAIK Stretch is still officially supported
11:42:45 <gnomey> glad to hear it
11:43:11 <jralls> Stretch is "oldstable" so it's still getting some security updates but nothing else.
11:43:30 *** kael has quit IRC
11:44:48 <gnomey> i seem to always be using some obscure package or driver, so even when dist-upgrade is not a disaster i still tend to lose a couple apps or some capability
11:45:24 <gnomey> and gnucash/ledger is one of those problems
11:46:20 <gnomey> ledger discontinued the ability to read gnucash data files, so I'm using a very old version of ledger that has been hacked to work with libs (which may not even be current either)
11:46:44 <gnomey> so i'm a bit afraid of losing ledger
11:47:51 <gnomey> i have custom scripts that use ledger to get data out of gnucash to generate LaTeX-formatted tax reports and invoices
11:47:57 *** guak has joined #gnucash
11:48:24 <gnomey> so it's a quite fragile situation
11:50:11 <warlord> I've been upgrading some of my servers recently..
11:50:14 *** waeking has quit IRC
11:50:22 *** ArtGravity has quit IRC
11:50:51 <warlord> Upgraded my SIP server from F25 -> F31; currently working on upgrading my DHCP server from F25 -> F31
11:51:13 <warlord> (this has been annoying since the system goes offline for about on hour for each dist-update!
12:00:29 *** ArtGravity has joined #gnucash
12:00:29 *** ChanServ sets mode: +v ArtGravity
12:20:01 *** gimpnet-irc[m] has joined #gnucash
12:20:02 *** habicht[m] has joined #gnucash
12:20:04 *** JulianHofer[m] has joined #gnucash
12:20:06 *** luwum[m] has joined #gnucash
12:20:08 *** mmkodali[m] has joined #gnucash
12:20:10 *** peter-butler[m] has joined #gnucash
12:20:10 *** MatrixTravelerbot[m] has joined #gnucash
12:20:12 *** sunyibo[m] has joined #gnucash
12:20:15 *** ElonSatoshi[m] has joined #gnucash
12:23:05 <gnomey> here's an example of a security that has many ticker symbols: https://contract.ibkr.info/v3.10/index.php?action=Conid%20Info&wlId=IB&conid=11988279&lang=en&ib_entity=
12:23:42 <gnomey> there is a different symbol for every exchange
12:24:38 <gnomey> yet the ISIN is the same for all of them.
12:28:00 <gnomey> in principle the "symbol/abbreviation" field should accept a list of symbols, perhaps comma-separated, and the "type:" field should also be a list
12:28:12 <gnomey> (in the security editor)
12:48:59 <gnomey> would be useful if users could add a new security by simply entering ISIN, and have all the fields pre-filled by a query of contract.ibkr.info
12:51:25 <jralls> gnomey, Eww. It's part of the international stock-quoting system that a stock that trades on multiple exchanges gets a different symbol for each exchange. Presumably when you place an order with your broker they're shopping around for the best deal (and unless there's an EU regulation that makes them a fiduciary, that's the best deal form *them*, not for you) and then reporting the actual symbol they traded on your behalf.
12:52:17 *** fell has joined #gnucash
12:52:17 *** ChanServ sets mode: +o fell
12:52:31 <gjanssens> jralls: to come back to the gettext issue
12:52:33 <jralls> It's way beyond GnuCash's remit to keep track of that for you as that's more of a trading function than it is an accounting function.
12:52:45 <jralls> gjanssens, OK.
12:54:50 <gjanssens> In order to generate a complete gnucash.pot file, we need gettext 0.20 as that's the first version that can extract the Developer_Name string from the appdata file.
12:55:11 <gjanssens> We obviously don't need that appdata file on MacOS or Windows
12:55:17 <jralls> gnomey, so I suggest that you pick one symbol and use that in GnuCash. GnuCash's internal use of symbols is only to retrieve quotes via F::Q and for accounting purposes you really need do that only on one exchange.
12:55:51 <gjanssens> However in theory someone may want to contribute to the translations on those platforms and generate their own gnucash.pot file.
12:56:06 <jralls> gjanssens, right. Nor do most users who are building GnuCash for personal use, regardless of OS.
12:56:07 <gnomey> jralls: i don't see how you can avoid the intermingling. If I place an order for 5000 shares, the broker often fills some shares on one exchange and the rest on another. And even when a single trade fills an order, the paperwork uses different symbols. E.g. dividends may be reported under one symbol, and the trade reported for another symbol
12:57:07 <gjanssens> The point is, we do want only one version of the gnucash.pot file to ever be generated.
12:57:31 <gnomey> the only way to keep my head straight is to show all symbols in GC. (e.g. sym1-aka-sym2)
12:57:41 <gjanssens> fell recently generated his own which was missing a translatable string because he used an older version of gettext;
12:57:46 <gjanssens> We should avoid that
12:58:14 <gjanssens> Which is why I suggested that potfile generation should be disabled unless gettext 0.20 or more recent is found.
12:58:15 <jralls> gjanssens, OK, I see that point. So we require at least gettext-0.20 or disable the gnucash.pot target.
12:58:34 <jralls> Heh, we're on the same wavelength then.
12:58:42 <gjanssens> :)
12:59:34 <gjanssens> We can make appdata file generation optional indeed. Though I'd like to get some feedback from real packagers about that before I do.
13:01:40 <jralls> Do the distros actually use the appdata file?
13:02:09 <gjanssens> Yes. It's required to appear in the gnome software tool
13:02:14 *** Agfarmer18 has joined #gnucash
13:02:15 <gjanssens> As for flathub
13:03:27 <gjanssens> (I mean and it's required to appear on flathub)
13:04:01 <jralls> The Gnome Software Tool is effing useless. Most Debian users use Synaptic because it actually works. IIRC RedHat (should we start calling it IBM?) has their own tool that replaces the Gnome one.
13:04:45 <gjanssens> Fedora uses it as does Ubuntu...
13:05:01 <jralls> Flathub is another matter, and if that's the significant use case then the file belongs on gnucash-on-flatpak just like Info.plist belongs in gnucash-on-osx.
13:05:03 <gjanssens> And I just checked Plasma's Discover tool also uses the appdata information
13:05:59 <jralls> OK, so gnucash.appdata has general applicability and we should include it in all Linux builds.
13:06:11 <gjanssens> I think so
13:06:25 <gjanssens> It can be ignored on the other platforms.
13:06:53 <gjanssens> I'll just make it so that it always is generated on linux.
13:07:11 <gjanssens> If it can, it will use translations, if not it will be untranslated.
13:07:31 <jralls> But that's skew to gnucash.pot generation. We need it for tarballs because TP insists. We need translators to be able to generate it at will.
13:07:44 <gjanssens> Of course.
13:08:13 <gjanssens> the presence of a target for gnucash.pot file generation will still depend on the version of gettext
13:08:37 <jralls> What about runtime gettext? If the installed gettext is < 0.20 will it notice that it needs to retrieve a msgstr from gnucash.appdata?
13:09:15 <gjanssens> Can you clarify what you mean ?
13:11:35 <jralls> gettext is a two-part program. One part goes through the sources and extracts msgids from sources and compiles them into foo.pot. The other part gets linked into the running program and converts msgids to msgstrs, the latter in the user's language.
13:12:28 <gjanssens> Oh that.
13:12:37 <gjanssens> It's slightly different for appdata files.
13:13:01 <gjanssens> The extraction is the same.
13:13:36 <gjanssens> However when generating the final appdata file, the translated strings will be mixed into the final appdata file.
13:14:10 <gjanssens> That file with all translations is distributed.
13:14:35 <gjanssens> I don't know if consumers of that appdata file then use gettext to find the correct string in the file.
13:14:56 <gjanssens> I guess it's rather an xml specific localization library that does so.
13:15:03 <jralls> Probably not, that would be unnecessarily heavy.
13:15:49 <gjanssens> So at runtime it boils down to; if the appdata file has translations in the requested language it will be used
13:15:59 <jralls> I meant gettext would be unnecessarily heavy.
13:16:12 <gjanssens> If the build time gettext fails to add those, they simply won't be available at runtime.
13:16:20 <gjanssens> (got that :)
13:18:04 <gjanssens> By the way, a week or two ago I set out to update gettext on mingw64 to 0.20.
13:18:08 <jralls> So at build-time we have a requirement for gettext-0.20 if we're making gnucash.pot or gnucash.appdata. Our CMake options should reflect that rather than specifying gettext version.
13:18:39 <gjanssens> That turned out to be harder than I had hoped
13:19:48 <gjanssens> Hm, you mean we should have options "WITH_GNUCASH_POT" and "WITH_GNUCASH_APPDATA"
13:20:00 <jralls> Yes.
13:20:06 <gjanssens> Which are then overridden to Off if gettext is not recent enough ?
13:21:16 <gjanssens> The former On by default, the latter On by default if not on Windows or MacOS
13:21:19 <jralls> Yes again. Though maybe ENABLE or BUILD instead of WITH. WITH implies to me to use an optional library.
13:21:33 <gjanssens> Better wording indeed.
13:21:54 <jralls> Actually I'd disable both by default on Win and MacOS.
13:22:29 <jralls> But require both for dist and distcheck.
13:22:50 <gjanssens> Disable generating the build rule or disable *building* them by default ?
13:22:54 <gjanssens> There's a difference
13:24:22 <jralls> BUILD_GNUCASH_POT=OFF BUILD_GNUCASH_APPDATA=OFF by default. Those that need them can override in the cmake invocation, and dist will fail because it needs to build a correct gnucash.pot.
13:25:24 <jralls> If they're both off then the gettext requirement is 0.18.1 because that's the first that provides the runtime macros for translating scheme msgids.
13:25:44 <jralls> If either is on then it's obviously 0.20.
13:26:35 <jralls> Eh, runtime macro is kind of nonsensical. The macros that enable translation at runtime.
13:27:15 <jralls> gnomey, I haven't forgotten about you. Do you import trading transactions or are you working from paper?
13:28:22 <jralls> gjanssens, do you remember offhand if gnucash.appdata is included in the tarball, or is it gnucash.appdata.in?
13:30:29 <gjanssens> gnucash.appdata.xml.in.in
13:31:08 <gjanssens> Which is the file even before version information is inserted (which comes from gnc-version.h or git)
13:32:03 <jralls> Is that the right thing to do? Could we make it so that gettext-0.20 isn't needed for tarball builds?
13:32:37 <gjanssens> I don't think we can
13:32:48 <jralls> For right-thing-to-do, shouldn't the version information be inserted as part of building the dist?
13:33:06 <gjanssens> It is, in gnc-version.h
13:33:43 <gjanssens> That's the central location of all version information used everywhere version information is needed.
13:34:15 <gjanssens> You could indeed consider spreading this information around during dist generation
13:34:34 <gjanssens> However I prefer not to duplicate data.
13:34:55 <gjanssens> But as for eliminating the need for gettext-0.20 in tarballs
13:35:19 <gjanssens> That would imply you want to prevent making pot files from tarballs as well
13:35:48 <jralls> That's right, it's not needed. dist generates a pot file.
13:36:08 <gjanssens> And prevent making a translatable versions of the appdata file from the tarball
13:36:22 <jralls> Benno would throw the mother of all hissy fits if it didn't.
13:36:52 <gjanssens> Well, my point of view is quite opposite
13:37:06 *** Mechtilde has joined #gnucash
13:37:19 <gjanssens> I'm doing what I can to at some point eliminate the need of a separate tarball distribution
13:37:27 <jralls> OK, but your point of view would get us kicked out of the TP.
13:37:35 <gjanssens> :)
13:37:56 <gjanssens> No, our dist tarballs would be a tar archive of our git repository at a given tag
13:38:25 <gjanssens> No more confusion between the result of git archive and our dist tarballs.
13:38:32 <gjanssens> We're not there obviously
13:38:53 <gjanssens> I am just hesitant in doing things that would drive us farther away from that
13:39:00 <jralls> And you're willing to dump half of our active translations to get there?
13:39:40 <jralls> I'm serious about the TP dropping support if our dist tarballs don't have a gnucash.pot.
13:40:03 <gjanssens> Imposing restrictions on what can be built from tarballs vs from git gets us further away from that
13:40:19 <gjanssens> Re gnucash.pot dist tarballs, I didn't realize.
13:40:51 <gjanssens> *in* dist tarballs
13:41:40 <gjanssens> Though that's just one more change to our current development system.
13:42:22 <gjanssens> We can add gnucash.pot back in the sources, and ensure we update it right before tagging a release.
13:42:53 <gjanssens> All in all, I don't intend to solve that particular future scenario tonight
13:42:54 <jralls> Regardless, I don't think that what I'm suggesting precludes building gnucash.pot from a tarball, though doing so would require gettext-0.20. It's just not necessary. If we could do the same for gnucash.appdata then distro packagers would be able to build their packages from tarballs without having to have gettext-0.20.
13:43:56 <jralls> I don't want build targets in git. It means that a build dirties the repo and breaks automated builds.
13:44:54 <gjanssens> Why can't we just use the same rules: on linux try enable both for the dist tarball build, but if the gettext version is too old, disable them
13:45:27 <gjanssens> Emit a useful message indicating why it was disabled.
13:46:25 <gjanssens> You can build an untranslated appdata file even with an older gettext version (that is, gettext is not used then)
13:46:26 <jralls> Why would we want to allow building a dist tarball with an incomplete gnucash.pot?
13:46:52 <gjanssens> No,no, I mean when building *from* a dist tarball
13:47:03 <jralls> OTOH BUILD_GNUCASH_APPDATA would be a no-op for dist so that doesn't matter.
13:47:20 <gjanssens> Obviously generating the dist tarball is a no-go if there's no way to generate a complete pot file
13:47:20 <jralls> Otherwise, yes, same rules.
13:48:16 <gjanssens> So perhaps I misread your "Could we make it so that gettext-0.20 isn't needed for tarball builds?"
13:49:32 <gjanssens> Oh, and I remember why I chose to capture all version information in one single file (gnc-version.h)
13:49:58 <gjanssens> With that there's only one single place where I have to special case between git builds vs tarball builds
13:50:18 <jralls> Maybe. What I had hoped for was that we could process gnucash.appdata enough so that a tarball build would work without needing gettext-0.20. That would preclude any whining from distro packagers.
13:50:48 <gjanssens> If we want to insert the version information in the various files where it's used, I'd have to special case each time any of these files is used.
13:51:51 <gjanssens> that's what I think you can't do unless you include the fully processed appdata file.
13:52:10 <gjanssens> That then prevents distro packagers from adding their own build id into that file.
13:52:21 <gjanssens> We release 3.8
13:52:41 <gjanssens> A packager will package it as 3.8-5 if they had to apply downstream patches
13:53:21 <gjanssens> I actually don't worry too much about that.
13:53:47 <gjanssens> Packagers that care about recent gnucash updates typically also target recent distros
13:54:36 <gjanssens> We didn't have translations for older distros anyway, so there's no loss on those distros.
13:54:37 <jralls> Not all, think of the folks doing the backports to Ubuntu 16 & 18.
13:55:04 <gjanssens> As I said, those didn't have a translated appdata file to begin with
13:55:41 <gjanssens> I do think we should keep the option to generate an untranslated appdata file on those platforms.
13:56:17 <gjanssens> Do you know offhand what versions of gettext ar on those distros BTW ?
13:56:29 <jralls> So the option would be TRANSLATE_GNUCASH_APPDATA instead of BUILD_GNUCASH_APPDATA?
13:57:26 <gjanssens> I think so indeed
13:57:59 <jralls> Not offhand, but repology says 0.19.18.1 for 18.04-20.04 and 0.19.7 for 16.04.
13:57:59 <gjanssens> Though if you want to skip building that file on MacOS and Windows, that would be in addition to BUILD_GNUCASH_APPDATA
13:58:35 <gjanssens> So both can actually translate all but the Developer Name string in appdata.
13:58:51 <gjanssens> That requires 0.19.6
13:59:20 <gjanssens> Note there's also the gnucash.desktop file which is in the same boat but supported since gettext 0.19
14:00:30 <jralls> I'm not concerned about the building, I'm concerned about erroring out on dependencies, i.e. gettext-0.20, unnecessarily.
14:00:50 <gjanssens> Ok. That can easily be avoided.
14:01:02 <gjanssens> So TRANSLATE_GNUCASH_APPDATA it will be
14:01:18 <fell> Glade2 msgctxt and Glade3 were implemented in 0.18.3,
14:01:28 <fell> GSettings and Desktop entries are implemented in 0.19
14:01:39 <fell> Scheme format strings got a fix in 0.19.4
14:01:49 <fell> AppData support: gettext-0.19.6
14:01:58 <jralls> fell, do we translate anything in GSettings?
14:02:04 <fell> All
14:02:44 <gjanssens> I'll also see if I can differentiate between the user explicitly requests BUILD_GNUCASH_POTFILE or when it's enabled/disabled by cmake tests.
14:03:11 <fell> The list of ourr requirements are hidden in https://wiki.gnucash.org/wiki/Translation#Our_Build_Process
14:03:12 <gjanssens> If the user requests it while gettext is too old, I'd want to error out, otherwise only warn.
14:03:39 <gjanssens> But that's just a bonus :)
14:03:54 <gjanssens> I'll start with just implementing a warning
14:04:41 <gjanssens> jralls: do you want to disable appata translation if only the Developer Name string can't be translated ? Or or you fine with just a warning ?
14:05:14 <gjanssens> gettext 0.19.6 and more recent will happily process that file, just not treat Developer Name as a translatable string
14:07:14 <gjanssens> BBL...
14:08:38 <gjanssens> Hmm, master is currently failing on Ubuntu, due to my temporary increased version requirement.
14:08:39 <jralls> gjanssens, Considering that gettext 0.20 doesn't seem to have much distro penetration yet ISTM it had better be a warning.
14:08:47 <gjanssens> Ok
14:09:09 <jralls> Yup, like I said even Ubuntu 20.04 won't have gettext 0.20
14:09:14 <gjanssens> I had increased the version to 0.20 while performing the last maint->master merge
14:09:41 <gjanssens> It was a complex merge and I didn't want to fix the gettext stuff in-merge
14:09:52 <gjanssens> I'll lower it again for now.
14:10:23 <jralls> Debian unstable doesn't have it either. Looks like it will be a while before we can require it.
14:10:42 <jralls> And I'll have to switch to Fedora for doing the dists.
14:11:02 <gjanssens> :(
14:11:12 <gjanssens> Fix pushed
14:11:17 <gjanssens> BBL for real now...
14:11:24 <jralls> TTYL
14:12:17 *** calvinct has joined #gnucash
14:14:15 *** ArtGravity has quit IRC
14:28:26 *** sbluhm has quit IRC
14:31:31 *** frakturfreak has joined #gnucash
14:37:07 *** timetravellers has joined #gnucash
14:37:07 *** ChanServ sets mode: +v timetravellers
14:46:28 *** sbluhm has joined #gnucash
14:46:28 *** ChanServ sets mode: +v sbluhm
14:50:29 *** timetravellers has quit IRC
14:54:21 <gnomey> jralls: i manually enter securities buys/sells and dividends. It is labor intensive and I was thinking about parsing the PDF statements, but last time I looked at that the import capability of gnucash fell short
14:55:32 <jralls> gnomey, well if you update to buster it has 3.x and a much more capable CSV import capability.
14:55:45 <fell> gnomey: You could convert pdfs with pdftotext.
14:56:56 <gnomey> jralls: glad to hear it. i just recall that QIF and OFX was too limited to be useful.
14:57:49 <gnomey> fell: indeed I would use pdftotext, perhaps parse that and import into sqlite, then do a query to generate CSV
14:58:26 <jralls> The SQLite part seems like an extra step.
14:58:48 <jralls> If you can parse to a SQL insert query you can parse to a line of CSV.
15:00:13 <gnomey> well sqlite has a simple command for CSV import/export, so a db table could be structured to mirror the csv attributes
15:00:27 <gnomey> it just depends on what kind of mess comes out of the PDF
15:01:22 <gnomey> different parts of the same record are likely scattered. E.g. the ISIN won't be right next to the trade data
15:01:30 <jralls> Right, but the bit that goes between the parens in INSERT INTO foo VALUES=(x, y, z)... is already CSV.
15:03:18 <gnomey> when i scrape websites, i often find it useful to parse into sqlite all attributes that are easily available, perhaps out of order, and then query for parts needed.
15:04:16 <gnomey> the sql middle step can also make some conversions easy, like date formats
15:04:53 <jralls> But you can do the same with data structures of your preferred scripting language.
15:12:15 <gnomey> the "*" no longer appears on launch. It seems removing unused securities using the security editor fixed that issue
15:15:42 <jralls> Huh, I wouldn't have expected that.
15:21:45 *** Gerd has joined #gnucash
15:42:38 *** jervin has joined #gnucash
16:11:18 *** fell_laptop has joined #gnucash
16:11:19 *** fell has quit IRC
16:11:19 *** ChanServ sets mode: +o fell_laptop
16:12:13 *** fell_laptop is now known as fell
16:16:13 *** gjanssens has quit IRC
16:23:02 *** KevinDB has quit IRC
16:24:26 *** KevinDB has joined #gnucash
16:24:26 *** ChanServ sets mode: +v KevinDB
16:29:27 *** Mechtilde has quit IRC
16:29:55 *** calvinct has quit IRC
16:54:14 *** Aussie_matt has joined #gnucash
16:56:02 *** Robert8471 has joined #gnucash
16:56:13 *** Robert8471 has left #gnucash
16:58:06 *** Robert847 has joined #gnucash
16:58:06 *** ChanServ sets mode: +v Robert847
16:58:10 *** Robert847 has left #gnucash
16:59:25 *** User__ has joined #gnucash
17:02:51 *** Robert847 has joined #gnucash
17:02:51 *** ChanServ sets mode: +v Robert847
17:02:55 *** Robert847 has left #gnucash
17:04:53 *** frakturfreak has quit IRC
17:15:55 *** KevinDB has quit IRC
17:17:11 *** KevinDB has joined #gnucash
17:17:11 *** ChanServ sets mode: +v KevinDB
17:32:06 *** Gerd has quit IRC
17:34:52 *** ArtGravity has joined #gnucash
17:34:52 *** ChanServ sets mode: +v ArtGravity
17:54:31 *** User__ has quit IRC
17:57:24 *** immae has quit IRC
17:59:13 *** sbluhm has quit IRC
17:59:59 *** immae has joined #gnucash
19:10:17 *** omnireq has quit IRC
19:36:53 *** Agfarmer18 has quit IRC
19:41:58 *** oozer has joined #gnucash
20:24:39 *** omnireq has joined #gnucash
21:01:34 *** guak has quit IRC
21:17:57 *** oozer has quit IRC
22:03:37 *** ArtGravity has quit IRC
22:32:26 *** yo has joined #gnucash
22:32:44 <yo> Hi! Anyone uses mint and gnucash?
23:13:04 *** fell has quit IRC
23:18:57 *** yo has quit IRC
23:33:45 *** fell has joined #gnucash
23:33:45 *** ChanServ sets mode: +o fell
23:42:10 *** fell has quit IRC
23:43:04 *** fell has joined #gnucash
23:43:04 *** ChanServ sets mode: +o fell
23:45:15 *** Gerd has joined #gnucash
23:46:36 *** fell has quit IRC
23:46:58 *** fell has joined #gnucash
23:46:58 *** ChanServ sets mode: +o fell
23:48:04 *** fell has quit IRC
23:53:47 *** fell has joined #gnucash
23:53:47 *** ChanServ sets mode: +o fell