2019-01-15 GnuCash IRC logs

00:39:16 *** boldstripe has quit IRC
00:56:19 *** storyjesse has quit IRC
01:56:19 *** fell has quit IRC
01:57:37 *** fell has joined #gnucash
02:20:56 *** bertbob has quit IRC
02:23:22 *** bertbob has joined #gnucash
02:24:49 *** kapil___ has joined #gnucash
02:36:07 *** bertbob has quit IRC
02:40:03 *** gour has joined #gnucash
02:46:39 *** bertbob has joined #gnucash
02:57:57 <Wilsona> Ok! Thanks to all. I'm going to think about it....
03:03:58 *** fabior has joined #gnucash
03:09:10 *** gjanssens has joined #gnucash
03:09:10 *** ChanServ sets mode: +o gjanssens
03:09:17 <gjanssens> ,
03:09:17 <gncbot> gjanssens: Sent 10 hours and 2 minutes ago: <jralls> I had to re-tag and re-spin the docs release this time. There was a problem with the new build system that I didn't catch in time. The docs tag is 3.4a, not 3.4-1.
03:12:39 *** Laurentius has joined #gnucash
03:13:51 <gjanssens> jralls: that's ok. The automated build should be able to deal with this.
03:15:07 <gjanssens> It is a problem however that the docs tag is 3.4a while the README file on sourceforge and the tar ball are labeled 3.4-1
03:15:42 <gjanssens> That means it's not possible to map a git tag to a tarball in an automated way
03:16:17 <gjanssens> I try to do that for release builds and to extract the sha256 from the README file
03:17:36 <gjanssens> Oh and with "The automated build should be able to deal with this." I mean it should eventually. It doesn't right now.
03:28:25 *** Aussie_matt has quit IRC
04:45:00 *** fabior has quit IRC
05:04:02 *** User_ has joined #gnucash
05:17:09 *** nimish has joined #gnucash
05:36:59 *** nimish has quit IRC
05:37:28 *** nimish has joined #gnucash
06:17:41 *** nimish has quit IRC
06:19:26 *** kapil___ has quit IRC
06:35:48 *** nimish has joined #gnucash
06:38:58 *** nimish has quit IRC
06:48:06 *** Jimraehl1 has joined #gnucash
06:48:28 *** Jimraehl1 has left #gnucash
06:56:07 *** User_ has quit IRC
07:23:10 *** monkeyjuice has joined #gnucash
08:11:02 *** oozer has joined #gnucash
08:14:30 *** gncbot sets mode: +o fell
08:30:23 *** fabior has joined #gnucash
08:31:07 <warlord> jralls, let me know if code needs something more to support the russian build.
08:31:28 <warlord> Also note that new languages need manual intervention in the docs build.
08:33:45 *** KevinDB has quit IRC
08:37:08 *** KevinDB has joined #gnucash
08:39:00 *** boldstripe has joined #gnucash
08:40:30 *** boldstripe has quit IRC
08:43:50 *** nimish has joined #gnucash
08:45:05 *** oozer has quit IRC
08:46:31 *** nimish has quit IRC
08:49:09 *** nimish has joined #gnucash
09:01:38 *** nimish has quit IRC
09:03:47 *** nimish has joined #gnucash
09:05:34 *** nimish has quit IRC
09:06:03 *** nimish has joined #gnucash
09:17:09 <chris> wish to ping gjanssens in case he has any comments regarding the new-style html-chart api. the basic html-chart may change but only marginally in response to upgrading reports. commits will be clean, so, once html-chart is finalised, it will be mergeable cleanly, and the converted charts *will* be upgradable individually
09:27:57 <gjanssens> chris: will the old style api be around still (albeit marked deprecated) ?
09:28:09 <chris> of course
09:28:18 <gjanssens> Then I'm fine with it :)
09:28:21 <chris> \o/
09:28:37 <gjanssens> I think you have thought this through deeply enough
09:28:58 <gjanssens> Of course I do expect full test coverage :D
09:29:03 <chris> :-o
09:29:16 <chris> for html-chart yes, for converted reports maybe
09:29:55 <gjanssens> That's ok I suppose
09:30:14 <gjanssens> I primarily care about tests for areas that undergo heavy changes
09:30:55 <gjanssens> Well, to be complete I'd love tests for all, but things that haven't changed are less likely to break so we should prioritize given our limited time
09:31:26 <chris> another way to view tests is to illustrate real-world usage of API
09:33:54 <gjanssens> True and that's a useful alternative view. For me unit tests help reduce undefined behaviour. So both are valuable
09:38:13 *** oozer has joined #gnucash
09:52:52 <gjanssens> warlord: well it looks like your nightly is smart enough to detect changes. The build log shows no rebuild was performed as every required bit was cached.
09:54:02 <warlord> I suspect that's only happening because I didn't change the branch :)
09:54:04 <gjanssens> It does generate the build log so those will accumulate. We could plan to make subdirectories for those per branch and per month to make it more browsable over time
09:54:41 <warlord> I suspect if I tried to build both master and maint then it WOULD have tried to rebuild.
09:54:45 <warlord> (maybe I'm wrong)
09:55:55 *** nimish has quit IRC
09:56:24 *** nimish has joined #gnucash
09:56:31 <warlord> gjanssens, do you know offhand when 3.5 is "due"? I'm considering Sunday, Feb 3 for code upgrade
09:56:55 <gjanssens> It should be in March only (3 month release cadence)
09:57:10 <warlord> okay.
09:57:21 <gjanssens> Yup: March 31st according to https://wiki.gnucash.org/wiki/Release_Schedule
09:57:33 <warlord> I'll email out my maintenance proposal to get feedback.
10:04:38 *** gour1 has joined #gnucash
10:06:02 *** gour has quit IRC
10:06:16 *** nimish has quit IRC
10:06:45 *** nimish has joined #gnucash
10:11:45 <gjanssens> warlord: re the rebuilds it shouldn't when switching branches
10:12:13 <warlord> Right, but it *seemed* to do so yesterday when I was playing with -r 3.4
10:12:18 <gjanssens> It's actually my script itself that checks whether a build already exists or not and that will skip further building steps
10:12:35 <warlord> How does it test?
10:12:51 <gjanssens> It checks for commit hashes
10:13:30 <gjanssens> That is it well recreate the build reference based on commit hash in docs and gnucash and will then check if that reference already exists in the flatpak repo
10:13:52 <gjanssens> For example:
10:13:54 <gjanssens> Checking for existing build of revision maint-C3.4-22-g3ab5a2be5-D3.4a-1-ga4b9c01
10:13:56 <gjanssens> Nothing to do: build already in repo
10:14:26 <gjanssens> The "build revision" is constructed by the "git describe" results on the two source repos
10:14:38 <gjanssens> That should uniquely indentify each commit in those repos
10:15:06 <gjanssens> So only if either branch changes, a build will be triggered
10:15:26 <gjanssens> Perhaps you removed the flatpak repo in between builds ?
10:17:55 <warlord> Nope, although it is possible I didn't have the host set yet.
10:20:45 <warlord> gjanssens, do I need to set up a cron script for the build_logs? Or should we make that part of the build_package.sh?
10:21:12 <gjanssens> Do you mean making the proper subdirectories ?
10:21:29 <warlord> Yes, and moving older files in
10:22:01 <gjanssens> I would like to add creating the proper subdirectories in build_package.sh
10:22:11 <warlord> Also, looks like mailman3 wont be in F29, only in F30. :(
10:22:19 <warlord> okay, then I wont worry about it :)
10:22:33 <gjanssens> But moving the older files in would be a one-shot for you to clean up the current situation
10:23:08 <warlord> Ah, I can do that once the directories are set up.
10:26:37 *** nimish has quit IRC
10:27:21 *** nimish has joined #gnucash
10:28:20 *** monkeyjuice has quit IRC
10:47:46 *** jerryq has quit IRC
10:57:12 *** nimish has quit IRC
10:57:43 *** nimish has joined #gnucash
11:08:10 *** User_ has joined #gnucash
11:10:54 <warlord> gjanssens, is it a known bug in 3.3 that entering a new transaction during a reconcile will reset the reconcile window to the top?
11:11:44 <gjanssens> warlord: no idea
11:13:59 <warlord> Okay, then I will file a bug report for that. Also, I noticed that using right-arrow in the register doesn't take me to the end of the highlighted area like it did in 2.6.x
11:14:14 *** User_ has quit IRC
11:14:55 <warlord> For example, I have transactions with description "Foo" and "Foo Bar". I used to be able to type "F" and it would autofill "Foo" and highlight it.. Then I could right arrow to get to the end and hit space for it to autofill "Foo Bar"
11:15:04 <warlord> That doesn't work in 3.3 anymore, either.
11:27:35 *** nimish has quit IRC
11:28:26 *** nimish has joined #gnucash
11:31:05 <gjanssens> I know jralls has worked on this keyboard navigation for 3.4 so perhaps it's fixed now.
11:33:08 *** nimish has quit IRC
11:35:03 <warlord> Okay, I can wait until RH pushes the fix into F29 (assuming they will push it)
11:36:20 <warlord> And hey, look, there it is! Let me upgrade..
11:38:35 *** jerryq has joined #gnucash
11:43:44 *** oozer has quit IRC
11:53:34 *** tienne has joined #gnucash
11:54:14 <warlord> Okay, I can confirm that the keyboard nav issue is fixed in 3.4
11:54:23 <warlord> I'll have to check reconciling...
12:03:27 <gjanssens> warlord: I have a few changes ready wrt to the subdirectory creation in the flatpak repo.
12:04:03 <gjanssens> The build logs will be stored in subdirectories like this: <branch>/<year-month>/<logfile>
12:04:27 <gjanssens> There are also "manifest" files (flatpak build recipes) for each successful build
12:04:39 <gjanssens> I'm inclined to make similar subdirectories to be consistent
12:05:19 <gjanssens> But as there will be fewer, I wonder whether it's worth to also make year-month subdirectories, or perhaps year-only ?
12:05:50 <gjanssens> Or even not at all, and only branch-based
12:06:03 <gjanssens> That's how the flatpak ref files are currently stored.
12:06:20 <gjanssens> Hmm, the latter is probably the best compromise (only branch-based)
12:06:49 <gjanssens> Too many subdirectories would also be confusing.
12:07:10 <gjanssens> For log files it kind of makes sense as there's really one logfile per branch every night
12:07:22 <gjanssens> So they are heavily date based
12:07:44 <gjanssens> The other artefacts depend more on commit activity
12:07:56 <warlord> Do you really want year-month and not year/month? It does mean there may be over 300 files in a directory at the end of the year.
12:09:58 <gjanssens> Eh no, it would mean there will be 12 subdirectories per branch at the end of the year with each subdirectory having at most 31 files
12:10:39 <gjanssens> I assume we will from time to time we will clean up older logs/manifests/flatpakrefs as we do on the windows build
12:11:44 <warlord> okay.
12:12:52 <gjanssens> These changes have been pushed
12:13:11 <warlord> I guess if we're going to manually clean out the year-month subdirs after a while, it wont grow too much. You're right, these are not necessarily permanent logs (like IRC logs), so we wont have decades of top-level storage.
12:13:26 <warlord> Do you want me to fire a build or just wait for tonight?
12:13:34 <gjanssens> If later it turns out this scheme doesn't work well, we can adjust as needed
12:13:41 <warlord> I guess there's no harm in firing a build.
12:14:14 <gjanssens> No, only one additional log file :)
12:14:33 <jralls> warlord: I'll push my changes for the russian fix in a few minutes. I added the fonts I picked to the repo so it's self-contained like Japanese.
12:14:34 <gjanssens> It won't create the (new) subdirectories for the manifest files though
12:14:39 <gjanssens> That would require a real build
12:14:52 <gjanssens> On the other hand you may now also enable master builds
12:15:20 <warlord> jralls, okay.
12:15:27 <gjanssens> Their log files won't cause additional noise any more on the maint builds
12:15:57 <gjanssens> jralls: did we merge maint into master already since the 3.4 release ?
12:16:18 <warlord> Let me know if you want nightly master builds too?
12:17:16 <gjanssens> I think we should wait for the maint merge
12:17:34 <warlord> okay
12:17:43 <gjanssens> master as it currently is will create non-working flatpaks due to the appdata change I fixed yesterday
12:17:50 <warlord> ok
12:18:00 <jralls> gjanssens: I should have after the release but github says that I didn't.
12:19:17 <warlord> gjanssens, what should I do about the broken 3.4-tag build logs?
12:20:22 *** Laurentius has quit IRC
12:20:26 <warlord> gjanssens, for manifests it looks like there is duplicated data, or something ... not sure what to do about that.
12:22:18 <gjanssens> warlord: you can remove the 3.4-tag build logs.
12:22:32 <warlord> I just rm'd the flatpak-repo/manifests/org.* --- it was duplicated in manifests/maint/
12:22:38 <warlord> Okay, gjanssens -- will do.
12:22:59 <gjanssens> and what do you mean with "duplicated data" ?
12:23:13 <gjanssens> Oh, sorry missed your last line
12:23:25 <warlord> There were two copies of the manifest json
12:23:44 <warlord> one in manifests/ and one in manifests/maint/ I removed the former, keeping the latter.
12:23:52 <gjanssens> So it appears I unconditionally upload manifest and flatpakref
12:24:28 <gjanssens> I should look into avoiding that
12:25:17 <jralls> warlord: docs changes pushed. If you have time maybe you could kick off a nightly build to make sure everything works.
12:25:28 <warlord> gjanssens, yeah.. possibly
12:26:06 <jralls> warlord, gjanssens: Should I merge maint into master now, or will that mess you guys up?
12:26:07 <warlord> jralls, fired...
12:26:21 <warlord> Wont mess me up. gjanssens ?
12:26:46 <warlord> jralls, oh, is it a known bug (in 3.3) that the reconcile window loses its place and refreshes to the top if I add a new transaction?
12:27:25 <jralls> Not that I recall, give me a sec to look...
12:30:14 <warlord> I saw it in 3.3; just upgraded to 3.4 but don't have another reconcile to do to test it.
12:31:06 <gjanssens> jralls: no you can do the merge as you see fit
12:32:07 <jralls> warlord: I don't see any open bugs on that. You can always test and not save the book.
12:33:25 <jralls> warlord: On the other hand the reconcile window--and all of the others--seems to have been made modal somewhere between 3.3 and 3.4, so it's not presently possible to enter a transaction with the reconcile window open.
12:35:05 <gjanssens> warlord: actually the script should *not* upload a manifest or flatpakref if no new build is started
12:35:24 <gjanssens> But it appears the test for existing builds is flaky
12:36:03 <gjanssens> The most recent build log suggests my test didn't detect a pre-existing build, but the subsequent flatpak-build does
12:37:11 <gjanssens> Can you capture the output of "flatpak repo $fp_repo --branches" into a file (replace $fp_repo with whatever you have set it to or 'repo' if you didn't explicitly set it) and mail that to me ?
12:37:38 <gjanssens> Be careful to capture with > or >>, so all whitespace is preserved exactly
12:37:53 <gjanssens> That should be called from the build directory by the way
12:40:36 <jralls> warlord: Found a problem in docs, just pushed a fix.
12:45:53 <gjanssens> warlord: alternatively you could remove the 'q' from 'grep -qP' in build_package.sh line 106 to check if grep issues a warning there
12:46:47 <gjanssens> And yet another test there would be to replace '\t' with 'http://en.wikipedia.org/wiki/Special:Search?go=Go&search=:space:' in grep's test expression
12:47:12 <gjanssens> Hmm, irc ate my braces
12:47:20 <gjanssens> or brackets
12:47:32 <gjanssens> Don't know how to pass those in irc
12:47:51 <gjanssens> it should be [=open bracket, ]=closing bracket
12:48:28 <gjanssens> <open-bracket><open-bracket>:space:<closing-bracket><closing-bracket>
12:48:33 <gjanssens> whew
12:50:37 <gjanssens> jralls: what to do with the docs git tag? We have 3.4a in git but 3.4-1 on sf
12:51:03 <gjanssens> I don't think there's a way a script can reliably map the first to the second
12:51:52 <gjanssens> I know packagers prefer to reserve the -x notation to indicate their patch levels
12:52:12 <gjanssens> On the other hand adding letters is a bit ugly also.
12:52:28 <jralls> How about add another tag, 3.4-1, for now and make a note in the Document_Release_Process to use that scheme for retags and second releases.
12:52:50 <gjanssens> Should be reinstate .x as third level ? Only using it to fix release issues
12:52:58 <gjanssens> s/be/we/
12:53:27 <gjanssens> So if a release failed or requires a fix that's not packaging related we could create a 3.4.1
12:53:48 <jralls> And use it only on tags but not in CMakeLists.txt/configure.ac?
12:53:57 <gjanssens> Yes
12:54:14 <gjanssens> Or would the be too confusing ?
12:54:21 <gjanssens> *that*
12:54:35 <gjanssens> My fingers refuse to follow my brain today...
12:55:32 <jralls> I hate it when that happens. I seem to be doing it alot with bug numbers lately.
12:58:11 *** oozer has joined #gnucash
13:00:05 <gjanssens> Thinking more of it if we won't update CMakeLists.txt/configure.ac, it would be better to use a symbol other than '.' to indicate a retag.
13:00:15 <jralls> It might be confusing. People are kind of trained to see x.y.z as a proper version number. I guess we could go the other way and call the tarball 3.4a.
13:00:32 <gjanssens> Yes, that's probably better
13:01:40 <jralls> OK, I'll make that change now.
13:04:48 <jralls> And, done.
13:07:32 <gjanssens> Ok, thanks
13:10:26 *** fabior has quit IRC
13:12:18 <jralls> warlord: The docs build probably failed, I missed changing a line in guide/ru/Makefile.am when I reconfigured from testing mode. That's fixed and pushed now.
13:14:32 <jralls> warlord, gjanssens, fell: One more thing on docs and fonts: I didn't provide configure options for the extended fonts the way I did for the Japanese ones. Now I want to remove the options for the Japanese ones and the search of /usr/share/fonts as well as being an unnecessary complication.
13:15:01 <jralls> Can you think of any reason not to?
13:15:59 <warlord> sorry, stepped away for lunch -- catching up now...
13:16:09 *** User_ has joined #gnucash
13:16:41 <fell> I wonder, if we could not have a default font, which has almost all uft chars.
13:17:12 <warlord> gjanssens, the test may have failed because of the change of location..
13:19:14 <jralls> fell: That would be nice, but I couldn't find one; the FreeType ones were the closest I found but they didn't provide all of the Japanese glyphs.
13:19:45 <warlord> jralls, The docs actually did not fail, but it's possible that I'm not building ru ... let me check.
13:20:18 <jralls> warlord: `make pdf` from the root dir should build everything.
13:21:28 <warlord> Oh, I take it back, I was doing ru already
13:22:17 <warlord> Anyways, I didn't get a build failure, but if it was a broken font then the build wouldn't fail.
13:22:45 *** gnomey has quit IRC
13:22:47 <warlord> gjanssens, let me re-run the flatpak build and see if it updates the manitest again
13:22:49 <warlord> manifest
13:22:50 *** gnomey has joined #gnucash
13:24:54 <warlord> Hmm, looks like there was a change to the repo which caused a new FP to get built... Bad test, I guess. I'll wait a minute and try again.
13:26:18 <warlord> Nope, it is definitely overwriting the flatpakref and manifest file
13:27:01 <jralls> warlord: The Russian PDF on code, dated today at 12:27, still has missing glyphs.
13:27:29 <warlord> jralls, do you need me to re-run the build again?
13:28:28 <jralls> I need you to look at the build log to see why it didn't work.
13:30:18 *** gjanssens is now known as gjanssens_afk
13:32:11 <warlord> just re-running make pdf didn't do anything. And of course the script itself hides the build-log.
13:32:48 <jralls> rm guide/ru/gnucash-guide.pdf then re-run make pdf.
13:32:53 *** nimish has joined #gnucash
13:33:42 <jralls> Does the script autogen and configure?
13:33:46 <warlord> yes.
13:33:58 <warlord> it does a git clean, autogen, configure, make...
13:34:15 <warlord> I removed the >/dev/null 2>&1 from the make pdf line and I'm capturing the output.
13:35:32 <warlord> Oops, that apparently didn't work right.
13:36:24 <warlord> aha!!!
13:36:46 *** User_ has quit IRC
13:40:19 <warlord> янв 15, 2019 1:35:51 PM org.apache.fop.apps.FopConfParser configure
13:40:19 <warlord> INFO: Default page-height set to: 297mm
13:40:19 <warlord> янв 15, 2019 1:35:51 PM org.apache.fop.apps.FopConfParser configure
13:40:19 <warlord> INFO: Default page-width set to: 210mm
13:40:19 <warlord> янв 15, 2019 1:35:52 PM org.apache.fop.fonts.LazyFont load
13:40:21 <warlord> SEVERE: Failed to read font metrics file null
13:40:23 <warlord> java.io.IOException: The Fontbox jar was not found in the classpath. This is required for OTF CFF ssupport.
13:40:31 <warlord> [and then a large set of stack trace]
13:41:01 <warlord> don't know why this didn't kill the build
13:42:06 <jralls> Me either. What version of FOP is that?
13:43:03 <warlord> fop-2.0-3.fc24.noarch
13:50:37 <jralls> Hmm, https://bugzilla.redhat.com/show_bug.cgi?id=1413340.
13:50:43 *** oozer has quit IRC
13:53:43 <jralls> warlord: Edit /usr/bin/fop and add "fontbox" to the set-classpath directive at line 28.
14:01:35 <jralls> warlord: BTW, I replicated your issue with the reconcile listbox scrolling back to the top when one adds a new transaction.
14:05:54 *** frakturfreak has joined #gnucash
14:10:35 *** nimish has quit IRC
14:12:41 <fell> 重大: Exception
14:12:42 <fell> java.io.FileNotFoundException: fop.xconf (Datei oder Verzeichnis nicht gefunden)
14:15:01 <jralls> fell: Is that with db7d785?
14:15:39 <fell> yes
14:20:08 <jralls> That's odd. Can you scroll back enough to see the configure output? There should be two lines near the end, guide/ja/fop.xconf and guide/ru/fop.xconf.
14:22:41 <warlord> jralls, that fixes the backtraces and it's building something...
14:23:03 <jralls> fingers crossed...
14:24:11 <warlord> jralls, okay, can you check now? I just copied the new one into place.
14:26:37 <warlord> Looks like some Cyrillic to me..
14:26:57 <jralls> I'm looking at https://code.gnucash.org/docs/ru/gnucash-guide.pdf
14:27:24 <jralls> And I see #### instead of cyrillic. The html has never been a problem.
14:27:52 <fell> in config.status are the creating guide/{ja|ru}/fop.xconf lines
14:28:42 <warlord> jralls, flush your cache? I just tried it and I see cyrillic.
14:29:25 <warlord> What's the file size you're seeing?
14:29:44 <warlord> Should be 9920895
14:29:53 <jralls> warlord: Flushing the cache did it. All good now.
14:30:29 <warlord> Yay.
14:30:53 <warlord> I presume you saw my maint email re Feb 3?
14:33:19 <jralls> Leaving fell's build. fell, I suppose you've already made sure the fop.xconf files are present. Is there anything that might explain why fop couldn't find it?
14:34:50 <jralls> warlord: Yes, and your discussion with gjanssens earlier. I don't have any issues with Feb 3. BTW, there's https://wiki.gnucash.org/wiki/Release_Schedule to see when the next release will be.
14:38:12 <warlord> Yeah, I know, but figured he'd know off the top of his head instead of me looking for the page where the schedule is ;)
14:38:17 * warlord is lazy
14:38:19 <fell> jralls: after a fresh configure, they are there. It seems, I dragged it accidently.
14:38:50 <jralls> fell: And building OK?
14:46:21 <fell> No, but I suspect eclipse: FileNotFoundException: /home/frank/git/gnucash-docs/build/home/frank...
14:49:52 *** guiloma has joined #gnucash
14:51:40 <jralls> I can't help much with that.
14:59:25 *** kael has joined #gnucash
15:03:25 <warlord> I'm just wondering why this fop error didn't throw a build exception that stopped my build scripts?
15:21:03 *** PEA has joined #gnucash
15:22:53 *** calvinct has joined #gnucash
15:24:52 *** oozer has joined #gnucash
15:26:14 <fell> doing everything in a terminal, I end now in the Fontbox error although I have FOP Version 2.1
15:27:09 <fell> luc14n0, it seems, https://bugzilla.redhat.com/show_bug.cgi?id=1413340 still exists in opensuse.
15:37:42 <fell> Yes, after adding Fontbox to BASE_JARS, it works.
15:45:30 *** PEA has quit IRC
15:45:35 *** PEA has joined #gnucash
15:48:50 *** gjanssens_afk is now known as gjanssens
15:49:10 <gjanssens> warlord: wrt to the flatpak build, did you try my other suggestions ?
15:50:10 <gjanssens> flatpak repo --branches > somewhere
15:50:15 <gjanssens> e-mail the result
15:50:17 <gjanssens> and
15:50:38 <gjanssens> remove '-q' from the grep line at 106
15:51:28 <gjanssens> or remove '-P' from grep and replace '\t' with <open-bracket><open-bracket>:space:<closing-bracket><closing-bracket>
15:51:58 <gjanssens> It's either another flatpak too old issue or a grep incompatibility
15:53:49 <warlord> gjanssens, bash-4.3$ flatpak repo --branches > /tmp/flatpak.txt
15:53:49 <warlord> Usage:
15:53:49 <warlord> flatpak repo [OPTION...] LOCATION - Repository maintenance
15:53:57 <warlord> error: LOCATION must be specified
15:54:31 <gjanssens> right make that $ flatpak repo repo --branches > /tmp/flatpak.txt
15:54:32 <warlord> Also... can I run the grep by hand to test it?
15:54:53 <gjanssens> assuming you are using the default for fp_repo
15:55:08 <gjanssens> you can run the grep command by hand by removing -q
15:55:09 <warlord> custom.sh only has gpg_ and home settings
15:55:26 <gjanssens> Ok, the default name for the local repository directory is "repo"
15:55:34 <gjanssens> so my adjusted command should work
15:57:55 <warlord> Yeah, I got output..
15:58:43 <warlord> in your inbox.
15:59:48 <gjanssens> Ok, so your version of flatpak uses spaces as separators while mine uses tabs :(
16:01:11 <gjanssens> can you change the grep part to 'grep -q "/$fp_branch<open-bracket><open-bracket>:space:<closing-bracket><closing-bracket>"'
16:01:39 <gjanssens> so remove the 'P' option and replace '\t' with :space: in double square brackets
16:02:09 <gjanssens> irc eats the double brackets, so I can't type them here
16:02:23 <warlord> Trying by hand does not seem to work
16:02:37 <gjanssens> trying what by hand ?
16:02:57 <warlord> bash-4.3$ cat /tmp/flatpak.txt | grep -q "/maint[[:space:]]"
16:02:58 <warlord> bash-4.3$ echo $?
16:02:58 <warlord> 1
16:02:58 <warlord> bash-4.3$ cat /tmp/flatpak.txt | grep -q "/3.4[[:space:]]"
16:02:58 <warlord> bash-4.3$ echo $?
16:02:58 <warlord> 1
16:03:58 <gjanssens> Eh, indeed. That should have the build ref in there
16:04:37 <gjanssens> Not the branch or release
16:04:43 <gjanssens> C3.4-22-g3ab5a2b-D3.4a-5-gdb7d785
16:04:48 <gjanssens> Try that instead
16:06:56 <warlord> Hmm.. Still failing?
16:06:57 <warlord> bash-4.3$ cat /tmp/flatpak.txt | grep -q "/C3.4-22-g3ab5a2b-D3.4a-5-gdb7d785[[:space:]]"
16:06:57 <warlord> bash-4.3$ echo $?
16:06:58 <warlord> 1
16:06:58 <warlord> bash-4.3$ cat /tmp/flatpak.txt | grep -qP "/C3.4-22-g3ab5a2b-D3.4a-5-gdb7d785\t"
16:06:58 <warlord> bash-4.3$ echo $?
16:06:59 <warlord> 1
16:08:48 <gjanssens> Sorry my mistake. It should be the full thing, so /maint-C3.4-22-g3ab5a2b-D3.4a-5-gdb7d785<space-stuff>
16:09:40 <warlord> Aha! Now it's working...
16:09:41 <warlord> bash-4.3$ cat /tmp/flatpak.txt | grep -qP "/maint-C3.4-22-g3ab5a2b-D3.4a-5-gdb7d785\t"
16:09:41 <warlord> bash-4.3$ echo $?
16:09:41 <warlord> 1
16:09:41 <warlord> bash-4.3$ cat /tmp/flatpak.txt | grep -q "/maint-C3.4-22-g3ab5a2b-D3.4a-5-gdb7d785[[:space:]]"
16:09:41 <warlord> bash-4.3$ echo $?
16:09:45 <warlord> 0
16:09:53 <gjanssens> Yes, that's it :)
16:10:00 <gjanssens> I'll push a commit
16:10:24 <warlord> Well, should we somehow test flatpak? Otherwise this will break again in 3 weeks when I upgrade the system.
16:12:38 <gjanssens> I have tested with tabs on my system as well. The same grep command works in both cases
16:12:57 <gjanssens> :space: stands for all types of whitespace
16:13:06 <gjanssens> Pushed
16:13:23 *** Laurentius has joined #gnucash
16:16:25 *** PEA has quit IRC
16:16:30 *** PEA has joined #gnucash
16:16:31 <gjanssens> warlord: can you retest the full build_package.sh run once more ?
16:16:33 *** Laurentius has quit IRC
16:17:49 <warlord> gjanssens, ah, perfect. Let me test. stdby
16:18:16 <warlord> Well that was FAST
16:18:28 <warlord> Checking for existing build of revision maint-C3.4-22-g3ab5a2b-D3.4a-5-gdb7d785
16:18:29 <warlord> Nothing to do: build already in repo
16:18:29 <warlord> Uploading log file 'build-maint-2019-01-15-16-17-58.log'
16:18:35 <warlord> Still get a log even though nothing was done.
16:19:04 <gjanssens> Yes, I know, but it shouldn't be replacing manifest and flatpakrefs any more
16:19:39 <gjanssens> I think it's good to have a trace of build runs even if nothing was done (it may fail very early as well)
16:19:57 <gjanssens> But it should not update manifests or flatpakrefs if nothing was done.
16:20:29 <warlord> it didn't
16:20:35 <warlord> YAY
16:20:51 *** kael1 has joined #gnucash
16:20:56 *** kael has quit IRC
16:20:56 *** kael1 is now known as kael
16:21:05 <gjanssens> You can now also enable master builds. jralls has merged maint
16:23:54 <gjanssens> And then we're done until I fix the release builds (which will be sometime later)
16:26:15 <warlord> Enabled. Master will be built starting tonight.
16:26:52 <warlord> Now we just need to figure the tag-builds process. Maybe a "build_tags.sh" script in the flatpak repo I can call?
16:27:10 <warlord> .... maybe based on the windows version?
16:27:37 <gjanssens> Nah, I think I will just tweak the build_package.sh script. I have an idea how to do it.
16:27:50 <gjanssens> Then you can simply add a "build_package.sh -r release"
16:28:11 <gjanssens> And it will try to build from the most recent tags
16:28:25 <gjanssens> But that will be for the WE or next week
16:31:23 <warlord> Hmm, okay. I suppose that works too.. a "special" branch tag.
16:32:59 <gjanssens> Yes
16:33:35 <warlord> If you feel that's less work than another script that finds the tags and then calls build_package, --- okay.
16:33:43 *** kael has quit IRC
16:35:06 <gjanssens> It would use the same detection logic to check wether the build was already done
16:35:30 <gjanssens> I like the idea of one test for all yes
16:35:52 <gjanssens> And it won't require that much code in addition
16:43:34 <warlord> I was more thinking a script that finds all (useful) tags and then just calls the builder script which does its magic. On the other hand, we probably don't want a build log for every tag every night -- only new tags, or tags that changed references.
16:45:28 *** PEA has quit IRC
16:45:35 *** PEA has joined #gnucash
16:48:00 <gjanssens> Yeah, the "all useful" tags approach is what we use on the Windows build currently.
16:48:40 <gjanssens> I could prevent build log uploads for runs that don't result in a new build
16:51:22 <warlord> Again, up to you -- you're doing the work.
16:51:31 <gjanssens> True
16:51:45 <warlord> I'm just a proponent of the unixy "make many small programs which each do one thing well" approach.
16:52:20 <gjanssens> Heh, and then we started working on gnucash :)
16:52:36 <gjanssens> It's only missing a kitchen sink to be complete :p
16:53:33 <jralls> I suppose this will all be sorted for the 3.5 release. IIUC flatpaks are supposed to be installed from a repo rather than downloaded, so should the release announcements point to the flatpak repo on code?
16:54:25 <gjanssens> Yeah it will be sorted by then.
16:54:55 <gjanssens> As for installation, there are two ways: either from a repo or by downloading a flatpakref file
16:55:19 <gjanssens> The latter is a single click solution pointing flatpak at a repo and specific branch to install
16:55:31 *** boldstripe has joined #gnucash
16:55:34 <gjanssens> (note flatpak uses the term "branch" more like we would think of a "commit")
16:55:51 <gjanssens> Both the repo and the flatpakrefs are publicly available
16:56:24 <gjanssens> As for the build script I wrote, my original intention was to mimic the Windows builds as close as possible
16:56:49 <gjanssens> But due to the repo nature of flatpak that aproach didn't map very well
16:57:35 <gjanssens> That triggered me to reconsider the nightly builds and in fact I think I'm almost at the opposite position now: I'm inclined to redo the windows build on the flatpak approach instead
16:57:42 <gjanssens> Not with a repo of course
16:58:18 <gjanssens> But the overall build script concept
16:58:41 <warlord> gjanssens, hey, it's not as kitchen-sinky as emacs!
16:58:44 <gjanssens> The flatpak specific parts then need to be replaced with windows specific build parts
16:59:11 <gjanssens> But that's from the top of my head and theoretical.
16:59:37 <gjanssens> I may eventually get to actually doing an experiment, but I'm in no hurry.
16:59:49 <gjanssens> The Windows build works, no need to touch it.
17:00:08 <warlord> Isn't it flatpak that does the dependency checking?
17:02:04 <gjanssens> Sort of. I'm interacting with flatpak to check the dependencies.
17:02:19 <gjanssens> And indeed that part would need an equivalent on Windows.
17:02:27 *** kael has joined #gnucash
17:04:55 <jralls> How big is the flatpakref? It sounds like that would be the thing to put in SF and the Github release note. We'll need to add a link from www.gnucash.org as well.
17:05:46 <gjanssens> It's just a small text file. Have a look here for examples: https://code.gnucash.org/builds/flatpak/maint/
17:06:11 *** Aussie_matt has joined #gnucash
17:06:11 <warlord> they are tiny
17:06:56 <warlord> 1753 bytes currently.
17:07:10 <jralls> Perfect.
17:07:24 <gjanssens> When downloading this file on a recent linux system with flatpak support enabled, it will offer to install the package straight away
17:07:57 *** gour1 has quit IRC
17:08:54 <jralls> Nice. We'll need a wiki page about flatpak leading off with that.
17:10:07 <gjanssens> Indeed. I'll put it on my TODO
17:11:57 <gjanssens> And now time for bed :)
17:12:04 <gjanssens> Glad we got this far already
17:12:12 <gjanssens> TTYL
17:15:40 *** guiloma has quit IRC
17:16:25 *** gjanssens has quit IRC
17:17:01 <warlord> Hopefully flatpak wont get lots of usage until I can move back to my main network!
17:17:38 *** PEA1 has joined #gnucash
17:17:50 *** PEA has quit IRC
17:19:02 <warlord> Gotta run myself..
17:20:06 *** calvinct has quit IRC
17:45:21 *** boldstripe has quit IRC
17:50:29 *** PEA has joined #gnucash
17:52:38 *** PEA1 has quit IRC
17:55:46 *** zangisharp has joined #gnucash
17:59:54 *** zangisharp has quit IRC
18:15:23 *** jerryq has quit IRC
18:19:29 *** PEA has quit IRC
18:19:30 *** PEA has joined #gnucash
18:35:36 *** frakturfreak has quit IRC
18:36:40 *** frakturfreak has joined #gnucash
18:51:32 *** PEA has quit IRC
18:51:33 *** PEA1 has joined #gnucash
18:57:14 *** Wilsona has quit IRC
19:04:21 *** jonp has joined #gnucash
19:04:22 *** jonp` has quit IRC
19:13:33 *** badger93 has joined #gnucash
19:13:52 *** CDB-Away_ has joined #gnucash
19:13:52 *** warlord has quit IRC
19:13:55 *** warlord has joined #gnucash
19:14:30 *** CDB-Away has quit IRC
19:15:14 *** badger92 has quit IRC
19:15:14 *** badger93 is now known as badger92
19:18:19 *** jerryq has joined #gnucash
19:23:27 *** PEA1 has quit IRC
19:23:29 *** PEA has joined #gnucash
19:55:38 *** PEA has quit IRC
19:55:41 *** PEA has joined #gnucash
20:30:43 *** PEA has quit IRC
20:30:45 *** PEA has joined #gnucash
20:30:51 *** tienne has quit IRC
20:31:00 *** kael has quit IRC
20:35:28 *** storyjesse has joined #gnucash
20:52:31 *** oozer has quit IRC
21:03:25 *** PEA has quit IRC
21:03:27 *** PEA has joined #gnucash
21:03:43 *** storyjesse has quit IRC
21:20:50 *** nimish has joined #gnucash
21:27:33 *** nimish has quit IRC
21:29:58 *** nimish has joined #gnucash
21:33:00 *** PEA has quit IRC
21:33:02 *** PEA has joined #gnucash
21:38:06 *** PEA1 has joined #gnucash
21:38:24 *** PEA has quit IRC
21:44:50 *** nimish has quit IRC
21:45:17 *** nimish has joined #gnucash
22:07:18 *** PEA1 has quit IRC
22:32:28 *** Robert847 has joined #gnucash
22:39:25 <Robert847> Hello, I have just noticed that in at least one bank account where I regularly use the OFX import wizard, sometimes the memos are not imported when the rest of the transaction is imported. This is usually release 2.6.17 in Ubuntu 16.04. This seems to have been intermittent. The most recent spate started last November and a few memos do get through.
22:41:02 *** luc14n0 has quit IRC
22:41:34 <Robert847> This FI does not use carriage returns that Windows Notepad or LibreOffice recognizes.recognizes
22:44:36 <Robert847> I don't seem to have an editor handy that can show non-printable characters. I will need to research that angle in more detail. The fact that some memos do come through has me really puzzled
22:51:30 *** nimish has quit IRC
23:01:35 <Robert847> If it makes any difference, I normally download and store the OFX files on a local NAS before importing into GnuCash
23:02:49 <Robert847> Also, I have not needed to delete them so I can go back and look at them for the last several years
23:05:49 *** WebManOfFesto has joined #gnucash
23:06:06 <Robert847> I found Notepad++. I am reading the release notes and finding there have been some issues in recent releases, So I hve not decided which release to download or whether I should look for a didderent editor.
23:06:56 <Robert847> I should look at my spelling before I hit enter
23:08:49 *** WebManOfFesto has quit IRC
23:11:45 <Robert847> OFX files from a credit union do have carriage returns that WordPad recognizes and those memos seem to be imported consistently.
23:13:45 <Robert847> LibreOffice also recognizes them and shows paraagraph marks in the credit union files
23:17:09 <Robert847> When I get to the bottom of this, I will want to figure out how to import the missing memos without affecting all the other data in that account.
23:27:03 *** WebManOfFesto has joined #gnucash