2019-08-14 GnuCash IRC logs

00:13:23 *** bertbob has quit IRC
00:15:09 *** bertbob has joined #gnucash
00:15:10 *** ChanServ sets mode: +v bertbob
01:16:03 *** fell has quit IRC
01:17:22 *** fell has joined #gnucash
01:17:23 *** ChanServ sets mode: +o fell
01:40:20 <fell> phpinfo().html told me: "GetText Support enabled". Should we remove (c) 2005/last modified external/php.* then?
01:40:36 <fell> modified 2010
01:44:23 *** Mechtilde has quit IRC
04:06:47 *** gjanssens has joined #gnucash
04:06:48 *** ChanServ sets mode: +o gjanssens
04:28:53 *** Aussie_matt has quit IRC
04:49:25 *** Mechtilde has joined #gnucash
05:23:38 *** fabior has joined #gnucash
06:29:56 *** Jimraehl1 has joined #gnucash
06:31:58 *** Jimraehl1 has quit IRC
06:37:02 *** GnuCashNewbie has joined #gnucash
06:40:55 *** storyjesse has quit IRC
06:42:27 *** oozer has joined #gnucash
06:48:46 *** Mechtilde has quit IRC
06:55:13 *** Mechtilde has joined #gnucash
07:10:22 *** Mechtilde has quit IRC
07:15:04 *** fabior has quit IRC
07:22:13 *** Mechtilde has joined #gnucash
07:26:18 *** Mechtilde has quit IRC
07:57:08 *** badger92 has joined #gnucash
08:06:48 *** jervin has quit IRC
08:37:20 *** jervin has joined #gnucash
08:45:19 *** jervin has quit IRC
09:31:29 <warlord> .
09:31:46 *** jervin has joined #gnucash
09:51:14 *** Mechtilde has joined #gnucash
09:57:03 *** GnuCashNewbie has quit IRC
10:11:33 *** jervin has quit IRC
10:12:02 *** jervin has joined #gnucash
10:16:27 <gjanssens> warlord: wrt to pruning the flatpak repo, the commands "flatpak remote-ls" and "flatpak remote-delete" can be used
10:16:57 <gjanssens> The flatpak builds are not stored as individual installer packages as on Windows or Macos, but in an ostree based repo
10:17:14 <gjanssens> So it's not possible to simply prune installer packages
10:17:28 <gjanssens> Instead older "branches" can be dropped from the repo.
10:17:52 <gjanssens> I'm having some difficulties right now to use those commands on my local test repo though
10:18:30 <gjanssens> It gives me a pretty odd error about being unable to open a temporary file.
10:19:42 <warlord> Hmm.
10:20:01 <warlord> Well, I'll worry about it some other time. It's only using 24G right now.
10:20:13 <warlord> Although we SHOULD deal with building tag/release builds.
10:22:01 <gjanssens> Yeah, thinking about that bit as well
10:22:09 *** oozer has quit IRC
10:22:20 <gjanssens> I remember now why I didn't implement it yet
10:23:35 <gjanssens> I had done a first implementation starting from the tags found in the git repos
10:24:08 <gjanssens> However that way I wasn't using the official release tarballs and hence the build was using a slightly different source from the other releases
10:24:23 <gjanssens> In theory the end result should be the same, but I prefer to be consistent.
10:25:12 <gjanssens> So the flatpak release builds should obviously also start from the release tarballs (application and documentation)
10:26:00 <gjanssens> flatpak can be configured to fetch those from sf or github. For safety it expects to get an shasum of the tarballs together with the link
10:27:48 <gjanssens> And I don't think I can automate getting those without loosing the actual security it's meant to set in place
10:28:30 <gjanssens> I mean, I can automatically track new tags appearing in gnucash or gnucash-docs and based on those try to download the tarballs from say sf
10:28:53 <gjanssens> I can then even calculate the shasum of those tarballs and use that in the flatpak build recipe
10:29:49 <warlord> does jralls post the sha-sum in the NEWS file?
10:29:53 <gjanssens> But if I recalculate this shasum to please flatpak, I have no guarantee the tarballs are really the ones jralls intended to be used for release (say due to a sf safety breach or whathever)
10:30:07 <gjanssens> He does
10:31:22 <warlord> Then maybe we somehow leverage that? If there is a new tag, then look for a new news file, and then look for the shasum in there?
10:31:25 <warlord> Then pull from SF?
10:32:17 <gjanssens> That is probably doable on condition the tag names can be mapped to a news file
10:33:10 <gjanssens> There may be multiple tags (like 2.6.6 and 2.6.6a)
10:33:48 <warlord> True.
10:33:59 <warlord> And news files have dates, not release tags.
10:36:46 <gjanssens> Indeed
10:37:47 <warlord> I think it's going to have to be someone heuristic.
10:38:08 <gjanssens> If we can formalize the tags vs files and paths, we can probably still manage
10:38:11 *** oozer has joined #gnucash
10:38:39 <gjanssens> For example, sf also carries a README.txt file with sha-sums and tarball names next to those
10:39:15 <warlord> Sure, but if the attack vector is a hacked SF account, then they could change that, too.
10:39:34 <gjanssens> That was one of my thoughts as well
10:39:48 <gjanssens> It will depend on how paranoid we choose to be in the end
10:40:27 <gjanssens> If we want it to be as hack safe as possible I think the only option is to add the release hashes in the gnucash-on-flatpak for each new release
10:40:42 <warlord> Or we can just use the tag from git. The only difference between that and tarball is swig output, no?
10:41:38 <gjanssens> No
10:42:10 <gjanssens> The tarball contains an additional version.h file
10:43:00 <gjanssens> For git builds this is inferred from the git describe command (and incidentally this exact same info is eventually written to the version.h file)
10:43:51 <gjanssens> From 4.x onwards I believe we agreed to make swig a mandatory dependency to bring git and tarball builds as close together as possible
10:45:19 <warlord> Sure, but the version.h file should be the same, too, right? The git tag would be the same. Perhaps a date string would be different.
10:46:20 *** Mechtilde has quit IRC
10:46:28 *** oozer has quit IRC
10:46:32 <gjanssens> I think the dates are indeed the tricky bit
10:47:01 <gjanssens> But what you're advocating is what I was moving away from in the flatpak release builds
10:47:22 <gjanssens> Though that may be a silly thing to do in the end
10:47:32 <warlord> I understand, but the windows build is still doing it.
10:47:46 <warlord> It's not pulling a tarball, it's building from git.
10:47:59 <gjanssens> Even for releases ? I had forgotten about that
10:48:07 <warlord> (it's just being kicked off by jralls instead of waiting for the nightly)
10:48:23 <warlord> I am 99% sure that yes, even for releases, it is building from git.
10:48:34 <warlord> but jralls would need to (re)confirm.
10:48:45 <gjanssens> There there isn't much point in trying to be more correct in flatpak
10:54:31 <chris> thank you gjanssens -- cleaned up branch. works. I presume that gint = int, and setting cached_result and immediately testing it is idiomatic C++ and not overengineering :) will try build windows tomorrow. /*flu*/
11:01:33 <gjanssens> you're welcome
11:01:43 <gjanssens> By the way, which report uses this feature ?
11:02:10 <gjanssens> It's definitely not overengineering :)
11:02:17 <gjanssens> chris: the particular bit about cached_result is that it's defined "static". This means its value will be retained over function calls.
11:02:55 <gjanssens> The very first run the varable isn't set yet and hence it gets initialized to 0
11:03:12 <gjanssens> On subsequent runs it's previous value will be reused
11:03:42 <gjanssens> But there may still be a bug in there so I'd prefer to have an actual report to test this with
11:03:57 *** fabior has joined #gnucash
11:06:49 <chris> only the transaction report, sort by dates, weekly grouping
11:07:55 * chris off now, ill:(
11:08:11 <gjanssens> Tx, get well soon :)
11:14:03 <gjanssens> Hmm, breakpoint on gnc_start_of_week fires only once at application startup... Can't get it to fire again when configuring the transaction report
11:23:35 <gjanssens> Ok a quick test case shows it works as I expected.
11:24:11 <gjanssens> warlord: back to the idea of generating release builds starting from tags in the repo
11:24:33 <gjanssens> Imagine we have a 3.7 tag for application and a 3.7a tag for documentation
11:25:05 <gjanssens> I can perfectly well combine those into one release, but what should be the release's final number become ?
11:25:05 <warlord> Well, yeah, the tags would need to match, I think.
11:25:12 <warlord> 3.7
11:25:32 <gjanssens> And what if that release had already been published ?
11:25:36 <gjanssens> 3.7-1 ?
11:25:46 <warlord> Release should be code-based, not docs based. An updated docs package wouldn't key off a new build.
11:26:08 <warlord> er, wouldn't kick off a new build.
11:26:21 <warlord> So if there were a 3.7 release with a 3.7 docs build..
11:26:26 <warlord> Then there is a docs update to 3.7a..
11:26:32 <gjanssens> What if the docs were broken and fixed in 3.7a ?
11:26:37 <warlord> No new build happens, unless there is a new code tag too.
11:26:45 <gjanssens> We have had this in the past
11:27:21 <gjanssens> Do w e then also have to create a 3.7a code tag pointing at the same commit is 3.7 ?
11:27:23 <warlord> Define "docs were broken"? If it breaks the build, then there would never be a 3.7 release because the build would stop during the docs build portion.
11:27:34 *** guak has joined #gnucash
11:27:39 <warlord> Probably, yes.
11:27:57 <warlord> Because I suspect rebuilding 3.7 would pull in the 3.7 docs build, too.
11:28:05 <warlord> ... which is broken. So it would fail a second time.
11:28:16 <gjanssens> For example figures show garbage in release tag and we didn't see it before tagging.
11:28:40 <gjanssens> That's not obvious while building but a user complains after installing the new release
11:30:41 <gjanssens> Well that's what I wanted to get at with "formalizing the tags/directories"
11:32:52 <gjanssens> If we want to avoid this, we have a few options. The easiest is probably that if we need to re-release for some reason, simply increase the minor on both application and data, marking the previous number as bad
11:33:23 <gjanssens> So in the example above, code would have tage 3.7 and 3.8 on the same commit where docs would have 3.7 and 3.8 on different commits
11:33:51 <gjanssens> That's the easiest to have automated build scripts pick up matching versions on app and docs
11:34:28 <gjanssens> The drawback is mainly that our release schedule needs manual fixes each time we have to do an unplanned re-release
11:36:11 <gjanssens> The other option is to add a letter to the release number, like 3.7a and have the script automatically look for the number with the highest letter (with no letter being less than 'a' and 'a' being less than 'b',...)
11:36:35 <gjanssens> And match those together under release 3.7
11:37:00 <warlord> An unplanned re-release like this would warrant a 3.7.1
11:37:27 <gjanssens> If a previous (bad) 3.7 release was already built, the new one will be 3.7-1
11:37:45 <warlord> I think we need to have a new (code) tag to kick off a new release.
11:37:46 <gjanssens> Ok, replace all letters with an additional .number
11:38:23 <warlord> So yes, it would be tag code with 3.7.1 at the same commit as 3.7; Tag docs with 3.7.1 at the new commit that fixes it. New release is 3.7.1
11:38:40 <gjanssens> Fair enough
11:40:00 <gjanssens> That still leaves the -1, -2 and so one additions for packaging fixes which is what distros use for their patch levels.
11:41:12 <warlord> exactly.
11:41:29 <warlord> 3.7 -> 3.7.1 is for *us*. And then -1, -2, is for packaging.
11:43:32 <gjanssens> I was hoping to use "git describe" on a commit to do some sanity testing on release tags
11:44:06 <gjanssens> Unfortunately in case of having two tags on a single commit it will only work with the most recent tag
11:44:36 <gjanssens> Although that may not a be problem in this case
11:44:49 <gjanssens> We're only interested in the most recent tag anyway
11:45:32 <gjanssens> So with this let's wait for jralls' feedback on tagging.
11:46:59 <gjanssens> Sidenote, it occurs to me the problem of determining which builds to fire off is a problem shared by the different packaging repos we have (gnucash-on-xyz)
11:48:00 <gjanssens> It may be one reason to merge these repos together into one gnucash-packaging repo at some point, hoping that could result in some code sharing.
11:48:48 <gjanssens> Oh well, it's easy to come up with fun "what-if" side projects...
11:51:06 <warlord> gotta run. Back soon.
11:53:35 *** kael has joined #gnucash
11:53:35 *** ChanServ sets mode: +v kael
11:55:19 *** Mechtilde has joined #gnucash
12:10:05 *** kael has quit IRC
12:24:57 *** MarkFirewhal has joined #gnucash
12:44:57 *** kael has joined #gnucash
12:44:57 *** ChanServ sets mode: +v kael
12:50:20 *** ArtGravity has joined #gnucash
12:50:20 *** ChanServ sets mode: +v ArtGravity
13:20:17 *** dizzydeane has joined #gnucash
13:21:42 *** plexigras has joined #gnucash
13:37:36 *** fell has quit IRC
13:52:43 *** kael has quit IRC
13:57:15 *** fabior has quit IRC
14:03:59 *** MarkFirewhal has quit IRC
14:09:42 *** fell has joined #gnucash
14:09:43 *** ChanServ sets mode: +o fell
14:11:14 *** frakturfreak has joined #gnucash
14:24:54 *** kael has joined #gnucash
14:24:54 *** ChanServ sets mode: +v kael
15:02:56 *** MarkFirewhal has joined #gnucash
15:05:34 *** oozer has joined #gnucash
15:06:28 *** gjanssens has quit IRC
15:08:58 *** MarkFirewhal has quit IRC
15:12:29 *** fabior has joined #gnucash
16:15:55 *** MarkFirewhal has joined #gnucash
16:17:36 *** calvinct has joined #gnucash
16:25:07 *** Mechtilde has quit IRC
16:27:08 *** Mechtilde has joined #gnucash
16:29:02 *** fabior has quit IRC
16:29:53 *** plexigras has quit IRC
16:30:09 *** Mechtilde has quit IRC
16:31:32 *** Mechtilde has joined #gnucash
16:40:53 *** calvinct has quit IRC
16:46:22 *** Mechtilde has quit IRC
16:49:59 *** Mechtilde has joined #gnucash
16:52:11 <fell> I am on he.po PR551 now
17:00:10 *** Mechtilde has quit IRC
17:00:48 <fell> Without stock buttons it is almost impossible to test gnucash in foreign languages. :-(
17:01:50 *** frakturfreak has quit IRC
17:11:05 *** Mechtilde has joined #gnucash
17:16:14 *** Mechtilde has quit IRC
17:20:14 *** Mechtilde has joined #gnucash
17:28:36 *** Mechtilde has quit IRC
17:37:14 *** Mechtilde has joined #gnucash
17:38:15 *** jervin has joined #gnucash
17:40:15 *** Mechtilde has quit IRC
17:41:08 *** jervin has quit IRC
17:59:48 *** Mechtilde has joined #gnucash
18:02:49 *** Mechtilde has quit IRC
18:03:56 *** warlord has quit IRC
18:12:51 *** Mechtilde has joined #gnucash
18:15:51 *** Mechtilde has quit IRC
18:22:28 *** kael has quit IRC
18:34:36 *** Aussie_matt has joined #gnucash
18:44:15 *** Mechtilde has joined #gnucash
18:47:17 *** Mechtilde has quit IRC
18:51:06 *** Mechtilde has joined #gnucash
18:54:38 *** jervin has joined #gnucash
18:54:42 *** Mechtilde has quit IRC
18:56:09 *** Mechtilde has joined #gnucash
18:59:09 *** Mechtilde has quit IRC
19:12:18 *** calvinct has joined #gnucash
19:13:41 *** Mechtilde has joined #gnucash
19:13:54 *** jervin has quit IRC
19:15:37 *** calvinct has quit IRC
19:16:42 *** Mechtilde has quit IRC
19:18:48 *** calvinct has joined #gnucash
19:19:06 *** Mechtilde has joined #gnucash
19:22:57 *** Mechtilde has quit IRC
19:27:10 *** calvinct has quit IRC
19:30:07 *** Mechtilde has joined #gnucash
19:33:32 *** Mechtilde has quit IRC
19:34:20 *** Mechtilde has joined #gnucash
19:37:21 *** Mechtilde has quit IRC
19:38:54 *** Mechtilde has joined #gnucash
19:41:55 *** Mechtilde has quit IRC
19:58:41 *** Mechtilde has joined #gnucash
20:01:42 *** Mechtilde has quit IRC
20:10:39 *** Mechtilde has joined #gnucash
20:13:41 *** Mechtilde has quit IRC
20:15:15 *** warlord has joined #gnucash
20:15:15 *** gncbot sets mode: +o warlord
20:20:09 *** Cuare has joined #gnucash
20:20:09 *** ChanServ sets mode: +v Cuare
20:20:58 *** Mechtilde has joined #gnucash
20:24:00 *** Mechtilde has quit IRC
20:31:41 *** Robert847 has joined #gnucash
20:33:23 *** Mechtilde has joined #gnucash
20:36:22 *** Mechtilde has quit IRC
21:07:42 *** Mechtilde has joined #gnucash
21:10:44 *** Mechtilde has quit IRC
21:12:55 *** omnireq has quit IRC
21:22:08 *** omnireq has joined #gnucash
21:22:08 *** ChanServ sets mode: +v omnireq
21:25:57 *** Mechtilde has joined #gnucash
21:27:57 *** guak has quit IRC
21:28:58 *** Mechtilde has quit IRC
21:33:55 *** Mechtilde has joined #gnucash
21:36:57 *** Mechtilde has quit IRC
21:39:54 *** Mechtilde has joined #gnucash
21:42:09 *** oozer has quit IRC
21:42:56 *** Mechtilde has quit IRC
21:45:31 *** omnireq has quit IRC
22:15:55 *** Mechtilde has joined #gnucash
22:19:15 *** Mechtilde has quit IRC
22:20:47 *** Mechtilde has joined #gnucash
22:23:48 *** Mechtilde has quit IRC
22:27:11 *** Mechtilde has joined #gnucash
22:30:13 *** Mechtilde has quit IRC
22:35:37 *** Mechtilde has joined #gnucash
22:38:38 *** Mechtilde has quit IRC
22:48:41 *** Mechtilde has joined #gnucash
22:51:44 *** Mechtilde has quit IRC
23:06:27 *** Mechtilde has joined #gnucash
23:09:29 *** Mechtilde has quit IRC
23:10:21 *** Mechtilde has joined #gnucash
23:13:22 *** Mechtilde has quit IRC
23:20:04 *** Mechtilde has joined #gnucash
23:23:06 *** Mechtilde has quit IRC