2018-06-28 GnuCash IRC logs

00:05:40 <chris> I got tricked by API... I was developing a pricedb conversion detector, using gnc_pricedb_has_prices to check if pricing exists between commodity and currency...... it turns out that if direct price does not exist, gnc:exchange-by-pricedb-nearest can improvise and seek another intermediate currency to perform the conversion :-o
00:16:46 *** boldstripe has quit IRC
00:22:32 *** oozer has quit IRC
00:24:35 *** fell has quit IRC
00:38:27 *** kael has quit IRC
00:41:35 *** Mechtilde has joined #gnucash
01:18:40 *** harshitaneja has joined #gnucash
01:27:00 *** Mechtilde has quit IRC
01:29:23 <arahael> Probably a fair decision if there is no arbitrage possible.
02:53:16 *** gjanssens has joined #gnucash
02:53:17 *** ChanServ sets mode: +o gjanssens
02:53:32 <gjanssens> .
03:16:05 *** Mechtilde has joined #gnucash
03:22:37 *** fekepp has joined #gnucash
03:26:59 *** gour has joined #gnucash
03:37:37 *** bertbob has quit IRC
03:44:47 *** bertbob has joined #gnucash
03:47:56 *** bertbob has quit IRC
03:49:56 *** fabior has joined #gnucash
04:02:31 *** bertbob has joined #gnucash
04:04:10 *** fabior has quit IRC
04:08:10 *** pilotauto has quit IRC
04:10:51 *** fabior has joined #gnucash
04:27:25 <darix> /crap
05:00:07 *** chris has quit IRC
05:22:35 *** Mechtilde has quit IRC
05:39:08 *** bastianilso has joined #gnucash
05:48:50 *** ncv has joined #gnucash
05:52:53 *** chris has joined #gnucash
06:17:20 *** bastianilso has quit IRC
06:18:06 *** jotrago has quit IRC
06:19:04 *** jotrago has joined #gnucash
06:22:07 *** jotrago has quit IRC
06:45:32 *** bastianilso has joined #gnucash
06:49:41 *** Jimraehl1 has joined #gnucash
06:50:29 *** Jimraehl1 has left #gnucash
07:16:58 *** chris has quit IRC
07:18:06 *** chris has joined #gnucash
07:19:12 <chris> gjanssens please feel free to revert 4c55141d963452a2381a5bd5b3d4fe31bde2cd2c to fix 796696... i thought i was doing a public service with this commit
07:22:05 <gjanssens> chris: You have determined that commit as the cause ?
07:22:29 <gjanssens> What about the suggestions you make in the bug report ?
07:22:31 <chris> yeps. the old definition of make-empty-list was very permissive, allowing negative numbers and fractions...
07:22:47 <gjanssens> Ok, I'll revert
07:23:03 <chris> whereas the built-in elegant (make-list n elt) allows 'correct' positive integers
07:23:32 *** harshitaneja has quit IRC
07:23:33 <gjanssens> Done
07:23:39 *** gjanssens is now known as gjanssens_afk
07:30:19 <darix> I am a bit confused about the aqhbci-tool getaccsepa. how often do I need to do that? - is it once and it should be stored in the account information or once everytime I try to do a sepa transaction?
07:37:31 *** jotrago has joined #gnucash
07:39:25 *** oozer has joined #gnucash
07:47:11 <chf> darix, out of Gnucash you can make credit transfers only, and call a graphical configuration menu for your accounts which normally works, that needs to be done once per account.
07:50:31 <chf> For everyday work, you simply open the action dialogue for SEPA transfers. Be aware that Gbucash always uses the default transfer type, if this is set to mass transfers, it will make "cumulative" transfers consistibg of one part, or fail if the bank's account type doesn't allow those cumulative transfers, so set the default type to "single" in Aqbanking.
08:22:14 <darix> chf: how? and where?
08:22:43 <darix> chf: every time I try the "actions" -> "online" -> "sepa transaction" it asks me again to run aqhbci-tool
08:23:51 *** harshitaneja has joined #gnucash
08:32:22 *** storyjesse has joined #gnucash
08:32:46 *** boldstripe has joined #gnucash
08:43:32 <chf> Menu "tools", top entry: configuration.
08:44:53 <darix> chf: ok
08:55:13 *** warlord has joined #gnucash
09:29:19 *** fekepp has quit IRC
09:53:13 *** Mechtilde has joined #gnucash
09:54:48 *** fabior has joined #gnucash
10:10:15 *** jotrago has quit IRC
10:19:09 *** fell has joined #gnucash
10:19:10 *** gncbot sets mode: +o fell
10:20:33 *** badger92 has joined #gnucash
10:22:35 *** kael has joined #gnucash
10:38:42 *** ArtGravity has joined #gnucash
10:43:20 *** User__ has joined #gnucash
10:44:58 *** storyjesse has quit IRC
11:01:19 *** jotrago has joined #gnucash
11:01:59 *** RASSRQ has joined #gnucash
11:04:16 *** jotrago has quit IRC
11:04:23 *** Mechtilde has quit IRC
11:04:56 *** jotrago has joined #gnucash
11:41:25 *** boldstripe has quit IRC
11:42:20 *** boldstripe has joined #gnucash
12:06:33 *** bastianilso has quit IRC
12:17:45 *** Mechtilde has joined #gnucash
12:35:37 *** boldstripe has quit IRC
12:36:33 *** boldstripe has joined #gnucash
12:38:12 *** RASSRQ has quit IRC
13:06:47 *** fabior has quit IRC
13:08:26 *** boldstripe has quit IRC
13:11:36 *** gjanssens_afk has quit IRC
13:37:47 <jralls> warlord: I'd like to make an announcement to gnucash-announce, users, and devel (which fell should echo to gnucash-de; not sure what we should do about the other languages) and on the website main page with the cut-over date and time for BZ. When do you plan to do it?
13:42:44 <warlord> Funny -- I'm syncing right now..
13:43:18 <warlord> I had a user error, tho, which I'm trying to correct.
13:44:43 <warlord> jralls: Are there any additional issues with the data? I think I've fixed all known issues.
13:45:11 <warlord> Of course, once we officially cut over, there can be no more drop/re-import fixes. All fixes will need to be live.
13:45:57 <jralls> None as far as I know and we're pretty much down to the wire: Unless Gnome has pushed the date out (and I haven't seen any announcements) bz.gnome goes no-new-bugs on Sunday.
13:47:21 <warlord> What I don't know is the process to "close" the bugs on GnomeBZ and point to our BZ instance.
13:48:23 <warlord> And we wondered what would happen if someone changed their email address... Well, what happens is that I get an error during my fetch process.. So I have to find out what bugs they're on and then forcibly refetch them.
13:48:28 <jralls> Yeah, I was thinking about that since we discussed it on Tuesday. The easy way is simply to query all open Gnucash bugs and do a bulk update on them using the list UI.
13:49:07 <jralls> But it would be nice to put a forward link on each one. That will require require a script.
13:49:15 <warlord> But don't we want a new comment with the URL to the new bug?
13:50:45 <jralls> Without the script we can say "Go to https://bugs.gnucash.org and enter the bug number in the box."
13:52:02 <warlord> jralls: true..
13:56:58 <jralls> So someone changed their email address while you had a fetch in progress?
13:58:46 <warlord> No, someone changed their email address since my last fetch. (actually, 2 someones)
13:59:27 <jralls> So you're doing update fetches instead of dump-and-replace ones?
14:00:48 <warlord> I download the list of bugs and their last-modified dates. If exists(bug) && bug->{last_modified} == last_modified then I don't re-download it.
14:01:14 <warlord> An email address change does not cause the bug to be modified.
14:01:55 <jralls> Right, because email addresses are in the user table. What error do you get?
14:02:25 <warlord> Something like this:
14:02:28 <warlord> Trying to download 5083 users
14:02:28 <warlord> {
14:02:28 <warlord> "result" : null,
14:02:28 <warlord> "error" : {
14:02:28 <warlord> "message" : "There is no user named 'd-bugzilla@moens.cc'. Either you mis-typed the name or that user has not yet registered for a GNOME Bugzilla account.",
14:02:29 <warlord> "code" : 51
14:02:31 <warlord> },
14:02:33 <warlord> "id" : "https://bugzilla.gnome.org/"
14:02:35 <warlord> }
14:07:48 <jralls> I don't understand. Why would you get that when querying for bugs? Aside from that, wouldn't it be simpler to just change the user table with an update query and the new email?
14:11:40 <warlord> jralls: I'm not -- I'm querying for users.
14:12:42 <warlord> The point is that in GnomeBZ the user changed, but the bug didn't. I had a cached version of the bug with the older email address. So when my fetch script tried to download the list of users, Gnome errored out saying it didn't exist.
14:13:02 <warlord> (I cache the bug data -- but user data I re-fetch every time)
14:14:49 <warlord> Anyways, I've got a current fetch completed.
14:15:15 <warlord> We just need to ensure that no changed get made in GnomeBZ after I do my "final" import.
14:17:28 *** User__ has quit IRC
14:18:55 <jralls> I don't think we can ensure that. We can turn off accepting new bugs beforehand and we can close all of the bugs on gnome immediately after and include in the closing note that discussion should continue at bugs.gnucash.org and any further changes on bugzilla.gnome.org will be ignored.
14:20:27 <jralls> So I think we just need to pick a date and time.
14:20:44 <warlord> jralls: I think that's probably a safe thing to do. Timing wise I think we would need to turn off accepting new bugs quickly after I do a fetch (and then we can close/tag the bugs then, too)
14:20:59 <warlord> Okay.
14:22:06 <warlord> When do you want to do it with me?
14:22:28 <jralls> We can shut off new bugs right before you start the fetch. Unfortunately we can't prevent new comments/attachments during the fetch, so we may lose a couple.
14:26:38 <jralls> Tomorrow or Saturday afternoon works best for me. What about you?
14:26:50 <warlord> jralls: It would be better to turn it off right after, otherwise the import will start with no new bugs allowed until we turn it back on.
14:26:59 <warlord> tomorrow is probably better for me.
14:28:10 <jralls> No, if we allow new bugs during the conversion then we risk losing them. Users can stand to wait an hour or two while we do the conversion.
14:29:59 <jralls> How about 13:00 my time, 16:00 your time, 20:00 UTC tomorrow?
14:30:19 <warlord> That works for me.
14:30:45 <warlord> And honestly, the window of failure is minutes if we time it right (turning off bugs after the fetch).
14:31:05 <warlord> We can have the change queued up and I can tell you "go" when it's ready.
14:31:06 *** frakturfreak has joined #gnucash
14:31:30 <jralls> But why risk it at all?
14:31:34 <warlord> It doesn't have to wait for the import to happen, just the fetch --- and indeed only the first stage of the fetch.
14:32:12 <warlord> Fair enough -- the alternative is that after the import we need to go through and turn bugs back on.
14:33:16 *** RASSRQ has joined #gnucash
14:33:48 <jralls> Huh? Are we talking about the same thing? The final fetch means no using gnomebz any more at all. New bugs doesn't get turned back on there ever.
14:35:07 <warlord> If we turn off bugs before the fetch, the product data in the fetch will have the "no bugs" flag. Which means after import into GncBZ we will need to manually them back on (at GncBZ)
14:35:35 *** Mechtilde has quit IRC
14:35:48 <warlord> ... which may not be a bad thing, considering I need to manually fix the code to enable new bugs.
14:36:00 <jralls> Exactly.
14:37:34 <jralls> The no bugs flag isn't a per-bug setting, it's a product setting.
14:37:38 <warlord> So okay, you've convinced me.
14:37:53 <warlord> Yes, I know. product -> {is_active} ---- I believe.
14:38:59 <warlord> Okay, so we turn off new bugs.. Perform fetch... Once fetch is done we go through and close all bugs with forward-pointer to bugs.gnucash.org. Simultaneous to that I drop the db and import the data.. then fix the code.. and then we can turn on new bugs.
14:39:01 <jralls> Like the user email: The actual column in the bugs table is userid, and the email is in login_name. The export/import uses login name but that's not what's in the database.
14:39:25 <warlord> Right.
14:39:41 <warlord> Which is why I needed to re-fetch those two bugs from users who changed their email address.
14:40:26 <jralls> Sounds like a plan. One more piece of the puzzle: Is there time to write a script to put a custom forwarding link on each bug?
14:41:29 <warlord> jralls: That's a good question; I don't know what such a script would look like.
14:43:15 <warlord> I've honestly never tried writing a script to update GnomeBZ. And for GncBZ I'm literally using the BZ::Migrate migrate.pl script.
14:46:46 <jralls> It would loop over a list of all open GnuCash bugs and use update RPC call on each to close it with a comment containing the link. A similar script would run on the already closed bugs and just add a migration comment with link; that one could use either the update or comment call.
14:47:39 <jralls> Not terribly different from your current fetch script, I'd think.
14:49:06 <warlord> jralls: Except my script doesn't login, and it only using GET queries.
14:49:23 <warlord> I can send you my script if you want it. I was never able to get POST to work.
14:49:49 <warlord> Alternate would be to use PyBZ and write a python script to interface to BZ...
14:50:01 <warlord> (which is not what I've done -- my script is all in Perl0
14:52:05 <jralls> There's also https://metacpan.org/pod/release/BMC/WWW-Bugzilla-1.5/WWW/Bugzilla.pm.
14:54:18 <warlord> jralls: I don't recall if I looked at that or not.
14:55:36 <jralls> It might be most useful as a source of code to borrow.
14:58:14 <warlord> Could be.
14:58:22 <warlord> Let me forward you my script.
14:58:43 <warlord> (or try to -- last time I tried I had a problem getting through my no-exe mail filters)
14:58:56 <warlord> ... unless I commit it to a repo!
14:59:11 <jralls> Or use gist.
14:59:20 <jralls> Or pastebin, or...
15:01:36 *** frakturfreak has quit IRC
15:01:46 <warlord> Hmm. pastebin.ca returning 503
15:03:39 *** frakturfreak has joined #gnucash
15:11:04 <jralls> You could also wrap it in a tarball to get it past your mail filter.
15:15:33 <warlord> Nope, the mail filter is "smart" and pulls apart tar and zip files.
15:17:57 <warlord> I could upload it to the Wiki?
15:20:36 *** ncv has quit IRC
15:21:01 <jralls> Good grief. Anywhere that can server a URL will work, I guess, including the wiki.
15:21:13 <jralls> s/server/serve/
15:25:43 *** ncv has joined #gnucash
15:31:02 *** boldstripe has joined #gnucash
15:35:22 *** ncv_ has joined #gnucash
15:35:30 *** ncv has quit IRC
15:36:19 <jralls> warlord: There's no more dumping of users so they can go ahead and reset their passwords in bugs.gnucash.org, right?
15:37:39 *** ncv_ has quit IRC
15:37:50 *** ncv_ has joined #gnucash
15:40:33 *** boldstripe has quit IRC
15:41:25 *** boldstripe has joined #gnucash
15:54:40 <warlord> jralls: nope. users will get dumped.
15:54:46 <warlord> the whole database gets dumped.
15:55:05 <warlord> So they will need to reset their passwords after the final import tomorrow.
15:55:10 <jralls> OK.
16:10:27 <fell> jralls: how about using a template BugURL or similar?
16:12:00 <jralls> fell: Could do, though I've already changed almost all of the pointers. The two remaining are on Eclipse and git-bz. I guess a template would work for those.
16:14:42 <warlord> jralls: okay, scripts are up in the wiki.
16:14:50 <warlord> Linked from the BZ Admin page
16:15:45 <jralls> warlord: Yeah, found it already. I suppose you used lwp::agent when you were trying to get http put to work.
16:16:00 <warlord> jralls: I dont recall. Probably.
16:16:12 <warlord> But it wouldn't work from CURL command-line either.
16:16:22 <jralls> Ah.
16:21:21 <jralls> But there must be a way, see https://wiki.gnucash.org/wiki/Git-bz... hmm, that was written back in 2013.
16:21:38 <warlord> It might work with the XML-RPC but not JSON RPC
16:22:00 <jralls> That's a thought.
16:23:30 *** ArtGravity has quit IRC
16:23:36 <warlord> But I had pretty much already committed to JSON at that point and didn't want to have to recode everything.
16:23:52 <warlord> What does the WWW-Bugzilla module use?
16:24:49 <warlord> (I havent looked at it)
16:28:41 <jralls> Neither, it uses WWW::Mechanize, which converts fields and values into a PUT URL. Not really surprising that the XML and JSON RPCs would be output-only.
16:29:23 *** User__ has joined #gnucash
16:32:05 <warlord> jralls: Doesn't PUT still require some content?
16:32:29 <warlord> It's still surprising to me that POST doesn't work.
16:32:49 <jralls> I don't think so, I think that POST.
16:32:59 <jralls> s/that/that's/
16:33:12 <jralls> IIRC PUT has everything in the URL.
16:33:20 <warlord> Hmm. Ok.
16:33:49 <jralls> It's been awhile (a *long* while) since I've written naked CGI, though.
16:33:50 <warlord> I haven't looked at the HTTP spec in a while. I thought PUT could either have params in the URL or also take data.
16:34:02 <warlord> Ditto.
16:34:10 <warlord> (well, beyond GETs)
16:35:12 <jralls> Anyway, if www::bugzilla still works that's the shortest path to getting a working updater script.
16:35:21 <jralls> I'm installing it now.
16:35:39 <warlord> ok
16:36:07 <jralls> Or maybe python-bz would be, I haven't done any serious perl in some time either.
16:38:21 <jralls> Especially since www::bugzilla failed its self-tests.
16:38:52 <warlord> Hmm. I just did a dnf install perl-WWW-Bugzilla
16:39:41 <jralls> Oddly, dnf doesn't work on a Mac. ;)
16:39:49 <warlord> Funny that ;)
16:40:24 <warlord> But the API does look like it would be pretty easy to write a script to do what we want)
16:40:41 <jralls> I could switch to a Fedora VM... but I'll have a look at python-bugzilla. Unlike WWW::Bugzilla it's actively maintained with the last push 2 days ago.
16:41:09 <jralls> It uses XMLRPC.
16:41:39 <warlord> Okay..
16:41:51 <jralls> Heh, and it's maintained by Red Hat.
16:42:06 *** frakturfreak has quit IRC
16:42:52 <warlord> Of course it is. I just don't know python.
16:42:53 *** ArtGravity has joined #gnucash
16:51:44 *** gour has quit IRC
16:52:11 <warlord> I wonder how hard it would be to use the WWW-Bugzilla interface?
16:52:27 <warlord> ... I could test it against bugs.gnucash for now ;)
16:53:39 <jralls> Only one way to find out! ;)
16:54:23 <warlord> Indeed.
16:55:29 *** boldstripe has quit IRC
17:04:27 *** User__ has quit IRC
17:05:10 <warlord> Hmm. Simple search script is not working against GncBZ :(
17:05:58 *** RASSRQ has quit IRC
17:09:21 <warlord> jralls: gotta run for a bit. Feel free to test your script against bugs.gnucash.. Although I don't think I have the XML or JSON RPCs enables.
17:10:07 <jralls> That might make it hard to test. ;) I can use an old bz.gnome bug to play with.
17:20:21 <warlord> jralls: Does it require XML or JSON RPC?
17:20:34 <jralls> XML
17:21:10 <jralls> But don't worry about it, it's better to test against bz.gnome since that's what I want to do ultimately.
17:22:00 *** ncv has joined #gnucash
17:22:06 *** ncv_ has quit IRC
17:23:16 <warlord> jralls: Sure, but do you really want to be updating old bugs of ours?
17:23:25 <warlord> Those updated will get put into the migration..
17:24:17 <jralls> warlord: Hmm, well, that would mess up the last changed date.
17:24:54 <warlord> Yes. which is why I think you should test against our BZ.
17:25:03 <warlord> I just installed XML and JSON RPC interfaces..
17:27:05 <warlord> I verified that my json RPC works.
17:27:37 <warlord> Although dunno about XML RPC.
17:27:39 <jralls> OK, I'll start by pointing at bugs.gnucash.
17:28:16 <warlord> Great. Now I really gotta run. Should be back in an hour or so.
17:28:37 <jralls> OK, CU
17:30:31 <warlord> XML RPC works, too. Following first suggestion on http://blog.likewise.org/2013/09/using-curl-to-access-bugzillas-xml-rpc-api/ and running against bugs.gnucash returned '5.0.3' in there. So XML RPC works too..
17:30:56 <warlord> Okay, now I'm off.
17:35:43 *** boldstripe has joined #gnucash
17:42:32 <jralls> warlord: Got python-bugzilla installed and tested its update example on https://bugs.gnucash.org/show_bug.cgi?id=793593, test satisfactory.
17:43:16 *** ArtGravity has quit IRC
17:57:07 *** drryan has joined #gnucash
17:59:03 <drryan> Just starting with GNUCash. I am self-employed with an S-Corp for business. Should Business and Personal be separate FILES. so totally separate instances of the program?
18:00:05 *** kael has quit IRC
18:30:53 <jralls> warlord: Script complete, tested on bugs.gnucsh.org, e.g. https://bugs.gnucash.org/show_bug.cgi?id=327279. https://gist.github.com/jralls/c25aaf55cfa0ac86ffd995787fe53650.
18:32:45 <jralls> drryan: Yes, you should have separate files for any legal corporation or trust. The only time where you might consider combining business and personal would be if you report the business on sched C.
18:36:07 <warlord> jralls: Great. What about closing the bug?
18:36:15 <warlord> jralls: IMHO the process should be:
18:36:20 <warlord> 1) Download the full list of bugs.
18:36:26 <warlord> 2) Iterate over the full list:
18:36:40 <warlord> 2a) If the bug is already closed/resolved, then just add the new comment
18:36:52 <warlord> 2b) If the bug is NOT closed/resolved then add the new comment and then close it.
18:37:03 <warlord> (I'm sure you already figured this out)
18:37:52 <jralls> Did you look at the gist?
18:38:06 <warlord> Not yet.
18:38:26 <jralls> It does just what you said.
18:40:20 <warlord> jralls: so it does.
18:40:41 <jralls> For the test I limited the query to component="Import - QSF", that being the one with the least bugs. All of them were already closed so I inverted the condition to test both creating the comment and changing the status.
18:40:58 <warlord> perfect.
18:41:27 <warlord> I think we're all set for tomorrow.
18:41:42 <warlord> (you're welcome to upload this to the Wiki, too, for future reference)
18:42:15 <jralls> Almost. I need to put an announcement on www.gnucash.org and some more work on the wiki Bugzilla page.
18:43:12 <warlord> jralls: ok
18:46:01 <jralls> Python-bugzilla is, as you can see, really easy to work with. I can see using it for some git-bz integration work going forward, like post-commit hooks that update bugs. And since we have our own BZ instance we might be able to go the other way as well, like converting BZ patches to PRs.
18:47:13 <drryan> thank you jralls will do
18:49:55 <warlord> jralls: Yeah, I can see about installing it on code if we want to have git hooks.
18:51:38 <warlord> jralls: should be as easy as dnf install python3-bugzilla
18:52:11 <jralls> Should be. Prolly better to use dnf than pip in this case.
18:52:17 <warlord> Yeah.
18:52:43 <warlord> Unfortunately the script will be sending out thousands of emails with all the updates.
18:53:06 *** pilotauto has joined #gnucash
18:54:44 <warlord> (I wonder if there's a way to temporarily turn off emails)
18:55:12 <jralls> It's true. Most of the Gnomers should be used to it, the migration to gitlab did the same.
18:55:43 <jralls> I don't think so, otherwise they would have done it for their own migration.
18:56:07 <warlord> OK
18:56:18 <warlord> We should also warn our users..
18:56:22 <warlord> BIAB
19:00:11 <darix> chf: i did the "get sepa info" from the aqbanking wizard. opening the sepa transaction dialog again gets me the "please run aqhbci-tool" dialog :(
19:04:43 *** RASSRQ has joined #gnucash
19:11:19 <chf> Has it been stored? If you open the wizard again, is the SEPA account number still there, or has it gone?
19:11:56 <chf> darix, that might also be a bug, so tell us your version of Gnucash and operating system.
19:12:53 <chf> Have you tried to enter the SEPA information manually?
19:13:13 <darix> chf: opensuse tumbleweed latest aqbanking. tried gnucash 3.1 and 3.2
19:14:01 <chf> I don't know anything special about those.
19:14:31 <darix> chf: the swift bic field should be filled I assume?
19:14:35 <chf> Is the Aqbanking configuration writeable?
19:15:21 <chf> This field normally doesn't matter. Most banks will derive that from the account number.
19:15:36 <darix> chf: ~/.aqbanking all files are owned by my user and all files have the u=rwX permissions
19:16:04 <darix> ah
19:16:08 <darix> the iban field on top is set yes
19:16:28 <darix> i checked all the single checkboxes now
19:16:58 <darix> i get asked again.
19:18:57 <chf> That should be sufficient. While the SWIFT number must not contradict the IBAN, that would only matter after sending a transaction (might get rejected, or silently corrected, because the IBAN has checksum fields.)
19:21:05 <chf> What you see seems to be not normal.
19:23:14 <darix> chf: ok just tested with "wiso" and it claims "no online capabable accounts returned"
19:23:23 <darix> when trying to set up with the chipcard
19:23:34 <darix> what is weird
19:23:48 <darix> because I can get transactions from the bank with it just fine in gnucash
19:24:24 <chf> Wiso? You're from Germany then? Let's discuss that in german, if so.
19:26:32 <darix> yes
19:27:10 <darix> sent you a query
19:36:35 *** oozer has quit IRC
20:01:09 *** fell_laptop has joined #gnucash
20:03:04 *** fell has quit IRC
20:04:29 *** drryan has left #gnucash
20:07:07 *** chris has quit IRC
20:08:10 *** fell_laptop is now known as fell
20:08:19 *** gncbot sets mode: +o fell
20:09:47 <fell> jralls: perhaps we should drop the first gnucash from gnucash-core-maint@gnucash.bugs ...
20:11:07 <jralls> fell: And the maint afterwards. I thought I'd do that tomorrow after the migration. I also noticed today that a couple of them aren't getting migrated.
20:12:34 <jralls> hmm, Google+ isn't letting me post to it. I thought that CMarchi had given me privs...
20:13:13 <fell> At least he wrote it
20:14:45 <fell> I have almost no expirience witg G+
20:15:17 <fell> https://wiki.gnucash.org/wiki/index.php?title=Bugzilla&curid=1289&diff=14165&oldid=14031 ist the text to translate?
20:15:17 <jralls> Right, but it didn't pick up the 3.1 announcement, remember, and you asked him about it? Well, it needs 3.2 and the BZ announcement too.
20:16:08 <jralls> You can use that or my email to gnucash-announce, gnucash-user, and gnucash-devel.
20:21:26 <fell> Cristians wrote us at 23.05.18 21:01
20:21:43 <jralls> I found the way in.
20:29:59 <fell> You can now use {{BugURL‏‎}} and later adjust Template:BugURL in the wiki.
20:30:59 <jralls> Thanks.
21:10:11 <fell> When switching, we should remove the product=GnuCash from most links as we have also Documentation, Packaging & Website now.
21:39:47 *** boldstripe has quit IRC
22:02:34 <fell> jralls: searching only for 3.x bugs might produce more duplicate bug reports.
22:50:10 *** boldstripe has joined #gnucash