2018-05-21 GnuCash IRC logs

00:11:22 *** bertbob has quit IRC
00:22:55 *** marusich has joined #gnucash
00:23:35 *** bertbob has joined #gnucash
00:26:49 *** bertbob has quit IRC
00:42:34 *** bertbob has joined #gnucash
01:17:18 *** marusich has quit IRC
01:18:18 *** Cuare has quit IRC
01:22:32 *** fell has quit IRC
01:23:19 *** fell has joined #gnucash
01:33:02 *** Mechtilde has joined #gnucash
01:35:56 *** gour has joined #gnucash
01:37:58 *** Mechtilde has quit IRC
01:41:30 *** Mechtilde has joined #gnucash
01:48:56 *** badger92 has quit IRC
01:51:55 *** badger92 has joined #gnucash
01:56:49 <omnireq> Jralls: Thanks! I continued building and it broke over something with gmock but I got it sorted out and installed. Be well.
01:57:38 *** frakturfreak has quit IRC
01:57:59 *** harshitaneja has joined #gnucash
02:13:05 *** frakturfreak has joined #gnucash
02:17:40 *** mikee_ has joined #gnucash
02:17:58 *** mikee has quit IRC
02:30:05 *** badger92 has quit IRC
02:31:28 *** badger92 has joined #gnucash
02:31:40 *** mikee_ is now known as mikee
02:31:59 <mikee> @op
02:31:59 <gncbot> mikee: Error: You don't have the #gnucash,op capability. If you think that you should have this capability, be sure that you are identified before trying again. The 'whoami' command can tell you if you're identified.
02:32:45 <mikee> @op
02:32:45 *** gncbot sets mode: +o mikee
02:37:05 *** eagles0513876 has joined #gnucash
02:39:05 *** eagles0513875 has quit IRC
02:39:05 *** eagles0513876 is now known as eagles0513875
02:48:14 *** fabior has joined #gnucash
03:10:28 *** chf has quit IRC
03:11:52 *** Mechtilde has quit IRC
03:15:16 *** chf has joined #gnucash
03:28:34 *** Mechtilde has joined #gnucash
03:28:45 *** ArtGravity has quit IRC
03:51:38 *** ArtGravity has joined #gnucash
04:13:22 *** badger92 has quit IRC
04:18:28 *** fabior has quit IRC
04:21:34 *** badger92 has joined #gnucash
04:37:35 *** fabior has joined #gnucash
04:41:25 *** ncv has joined #gnucash
05:06:11 *** gjanssens has joined #gnucash
05:06:11 *** ChanServ sets mode: +o gjanssens
05:06:20 <gjanssens> .
05:06:20 <gncbot> gjanssens: Sent 1 day, 19 hours, and 11 minutes ago: <chris> thank you for looking into this for me. at least I know I'm not seeing things. I've tried various combinations of (gnc-numeric-create) instead of numbers directly, still no dice. Ah well.
05:06:21 <gncbot> gjanssens: Sent 1 day, 18 hours, and 32 minutes ago: <chris> - further experiments - 100% discount does successfully nullify gncEntry invoice amount, and 200% discount also works.
05:06:22 <gncbot> gjanssens: Sent 1 day, 3 hours, and 35 minutes ago: <chris> all's good now thanks
05:44:35 *** pilotauto has quit IRC
06:17:13 *** User has joined #gnucash
06:28:59 *** User has quit IRC
06:58:57 *** fabior has quit IRC
07:22:54 *** boldstripe has joined #gnucash
07:39:00 <warlord> .
07:45:51 *** omnireq has quit IRC
07:47:52 *** omnireq has joined #gnucash
07:52:08 <warlord> jralls: Interesting -- the import automatically created the "missing" status/resolution fields. So now we have a "mix" of the BZ and Gnome fields.
07:52:25 <warlord> Strangely there is an empty, "non-deletable" value.
07:53:07 *** harshitaneja has quit IRC
07:57:21 *** harshitaneja has joined #gnucash
08:03:08 *** harshitaneja has quit IRC
08:12:21 *** harshitaneja has joined #gnucash
08:20:52 *** User has joined #gnucash
08:43:44 <warlord> Oh, it's a default setting; you don't *have* to insert a resolution. Okay.
08:44:04 <warlord> I've reloaded the database, changing NOTGNOME -> NOTGNUCASH
08:44:13 <warlord> I should probably also remove IN_PROGRESS
08:57:14 <warlord> .. and done (programatically)
09:07:03 *** fabior has joined #gnucash
09:33:27 *** ncv_ has joined #gnucash
09:34:39 *** ncv has quit IRC
10:06:54 <warlord> @tell jralls I have updated the wiki with the current "status" -- your description of the status/resolution changes was incorrect. I've updated it to reflect the current state and I've added a bug status workflow matrix (which is a copy of the existing state of the system). We can play with the matrix on the wiki and then make BZ reflect that.
10:06:54 <gncbot> warlord: The operation succeeded.
10:09:22 <warlord> gjanssens: If you have input into the bug status workflow I'm all ears. C.f. https://wiki.gnucash.org/wiki/Bugzilla_Administration
10:18:22 *** Festour has joined #gnucash
10:19:17 <Festour> Hello! Is there a way to add to transaction a image file?
10:26:04 <warlord> Festour: Yes, select the transaction, right-click, add file
10:51:37 *** storyjesse has quit IRC
10:56:08 *** User has quit IRC
11:29:15 *** fell_laptop has joined #gnucash
11:39:30 *** oozer has joined #gnucash
11:45:43 <jralls> .
11:45:43 <gncbot> jralls: Sent 1 hour and 38 minutes ago: <warlord> I have updated the wiki with the current status -- your description of the status/resolution changes was incorrect. I've updated it to reflect the current state and I've added a bug status workflow matrix (which is a copy of the existing state of the system). We can play with the matrix on the wiki and then make BZ reflect that.
11:45:51 *** fabior has quit IRC
11:48:23 <jralls> gjanssens: Do we need to do anything about GDPR?
11:50:09 <jralls> warlord: Hmm, my description came from the 5.0 docs. I wonder what else is wrong in them.
11:50:33 <warlord> jralls: dunno, but I did a "clean install" and looked at what was in the database.
11:51:32 <jralls> No matter though: I like RESOLVED better than FIXED anyway.
11:53:03 <jralls> But let's turn off "unconfirmed" as we have in bz.gnome. It's a per-project setting.
11:53:04 <warlord> *nods*
11:53:57 <warlord> Okay -- I don't know if I can do that programatically.
11:54:22 <jralls> I don't think you need to. As I said, it's a per-project setting.
11:55:16 <jralls> So we just uncheck the box on the project admin page. c.f. https://bugzilla.gnome.org/editproducts.cgi?action=edit&product=GnuCash.
11:55:50 <warlord> What I meant was, I don't know if I can edit the 'enable UNCONFIRMED' status during the import. Ideally I'd like to do that.
11:57:06 <warlord> Ah, I can. $product->{has_unconfirmed} = 0 (or false.. need to figure out how to set that
11:57:11 <jralls> Since it's unset on bz.gnome I'd think it would import as well, but it may not be exposed by rpc.
11:57:52 <warlord> Hmm. It does. It even says has_unconfirmed: false in the json.
11:58:08 <warlord> Maybe I need to change that for import
12:00:13 <warlord> Aha. Yes. Need to change "false" to "0"
12:00:50 <jralls> Heh. A bug in the import code.
12:02:26 <warlord> Acutally, I take it back. It's not a "false" string. it's the json value "false" (no quotes). I need to figure out how that's imported.
12:03:51 <jralls> I wouldn't worry too much about it. It just takes a click on the admin page later to turn it off.
12:04:56 <warlord> Weird. It IS read in as 0.
12:05:19 <warlord> Well, I am worried about it, because if it's doing the wrong thing here with a boolean, it could be doing the wrong thing elsewhere, too.
12:05:41 <jralls> That is a bigger concern, yes.
12:06:18 <warlord> The import *should* create that project with has_unconfirmed:false -- but it's being set to true.
12:06:21 <jralls> Are you sure that it's doing the wrong thing? ATM I think you're the only one who can see the project admin page.
12:06:42 <warlord> Yes. The check-box is checked.
12:06:56 *** harshitaneja has quit IRC
12:07:05 <jralls> Mmm, crossed. Can you capture the insert query?
12:07:32 *** harshitaneja has joined #gnucash
12:09:57 <warlord> GRR... Documentation is wrong. It's "allows_unconfirmed", not "has_unconfirmed:
12:10:04 <jralls> FALSE, false, and 0 should work correctly according to the MySQL docs. (are you using MySQL or pgsql?)
12:10:24 <gjanssens> jralls: at first reflection I don't think we have to do something with regards to the GDPR
12:10:39 <gjanssens> But I'll think it through a bit more and come back on that.
12:10:45 <gjanssens> I have to leave now
12:10:53 <jralls> gjanssens: Ok, good. A lot of websites and bloggers are in a lather over here. Bye.
12:11:15 *** gjanssens is now known as gjanssens_afk
12:11:28 <warlord> jralls: it's a json -> perl question, not mysql.
12:11:49 *** harshitaneja has quit IRC
12:11:59 <warlord> I think the issue might come up in terms of deleting email archives.
12:12:24 <Festour> warlord: thanks you
12:13:49 <jralls> warlord: GDPR might apply to importing email addresses into bz.gnucash. We have no permission from anyone to do that.
12:14:21 <warlord> Festour: you're welcome
12:14:40 <jralls> It also might apply to logging IP addresses here.
12:16:56 <jralls> warlord: BTW, csoriano posted to gnome-desktop-devel this morning that the shutdown date for bz.gnome is 1 July.
12:17:11 <warlord> Okay. So we have another month to "get it right"
12:17:55 <warlord> running another import -- hopefully I fixed the UNCONFIRMED flag. And if so, I'll edit the wiki.
12:18:28 *** ncv__ has joined #gnucash
12:19:50 *** ncv_ has quit IRC
12:20:36 <jralls> OK. I don't think we want CONFIRMED either.
12:21:07 <warlord> W00t. That fixed that.
12:21:34 <jralls> Anyway, the wiki should reflect how we want the workflow to be, not necessarily what we can get the import to do.
12:21:37 <warlord> Damn you bogus documentation
12:21:53 <warlord> I agree
12:22:02 <warlord> The workflow itself will need to be hand-created.
12:22:04 <jralls> Uh... rocks and glass houses...
12:22:18 <warlord> But I'd like to automate as much as possible during the import.
12:22:27 <jralls> Roger that.
12:22:47 *** Grav has joined #gnucash
12:23:08 <warlord> The real issue is that the JSON API != the Perl API. So I have to back-translate everything
12:23:43 <warlord> I'm using the JSON API to pull data, but then I'm passing it into the PERL API -- and the hash members have been translated, so I need to reverse-engineer the translation and convert them back.
12:26:58 <warlord> Okay, wiki updated.
12:35:01 <warlord> jralls: And yes, looks like I can remove CONFIRMED safely.. Do we want to do that?
12:36:52 <jralls> Yes, let's. It's equivalent to NEW in the Gnome workflow.
12:40:01 *** fabior has joined #gnucash
12:43:05 <jralls> I've updated the wiki to reflect removing CONFIRMED and added some Xs to the workflow to reflect what we've been using on Gnome.
12:55:37 *** gour_ has joined #gnucash
12:57:58 *** gour has quit IRC
13:04:19 <warlord> okay.
13:04:47 *** kael has joined #gnucash
13:07:07 <warlord> Interestingly, I *think* I can programatically set the work flow as well.
13:09:58 *** omnireq has quit IRC
13:10:22 <jralls> OK. Does it make sense to or should we go with what we've got?
13:21:38 <warlord> Well, every time I dump the DB it needs to be reset -- so I'd like to make the migration script set it up if I can.
13:25:18 <jralls> At some point we have to declare victory and get the system set up. How close do you think you are to getting all of the date you can get?
13:29:16 <warlord> I'm GETTING all the data from Gnome.. It's a question of converting it all the way we want and getting the instance set up the way we want..
13:29:39 *** oozer has quit IRC
13:29:42 <warlord> Some stuff is easy to adjust later. Other stuff is better done during the import (IMHO)
13:30:24 *** bertbob has quit IRC
13:31:58 <jralls> OK, what's left in the second list?
13:32:13 <jralls> i.e. stuff that's better fixed during import?
13:33:33 <warlord> Well, right now I'm dropping a bunch of status data
13:34:05 <warlord> That all needs to be fixed (e.g. attachments.gnome_attachment_status)
13:34:29 <warlord> .. or the cf_gnome_{version,target} fields
13:35:35 <jralls> I suppose that those are gnome custom fields that stock bz doesn't know what to do with.
13:38:56 <warlord> Yes.
13:39:04 <warlord> We probably don't care about the cf_gnome_*
13:39:13 <warlord> But we probably DO want the attachment status field
13:39:53 <warlord> ... alas, does NOT look like I can reset the workflow easily by code. So we'll just have to rebuild the matrix by hand every time I reset the DB.
13:41:22 <jralls> You could write a query to stuff the table(s) outside of perl.
13:42:05 <jralls> MySQL's backup utility will do most of the work...
13:43:17 <jralls> We absolutely don't care about the Gnome versions and targets, that's useful only for core Gnome desktop apps. Even Gtk and Glib don't use them AFAICT.
13:44:31 <warlord> Indeed, I had to do that for the duplicates table.
13:44:56 <warlord> I could do that for the workflow table, too, following the code in editworkflow.cgi
13:47:44 <warlord> But honestly, I think it might be easier to just do it by hand.
13:48:01 <jralls> OK.
13:49:48 *** Mechtilde has quit IRC
13:51:17 *** frakturfreak has quit IRC
13:52:28 <warlord> Let me try something quickly.. (of course, by "quickly" it measn ~5 minute to run an import)
13:55:44 <warlord> Their code has to worry about adding extra entries into the DB. I know what the status is so I can be careful to only add the rows I need.
13:58:41 *** frakturfreak has joined #gnucash
14:07:34 <warlord> Damn. Something I did broke the import. Now I have to figure out what change did it.
14:08:08 <warlord> WEIRD. It appears to have been the allow_unconfirmed change.
14:08:35 <warlord> I think the issue is that we HAD allowed unconfirmed, so there are some history messages that use it.
14:09:38 <warlord> Let me check for sure..
14:13:59 <warlord> Yep. Not sure why I thought that was working before? *sigh* Not too hard to reset the flag afterwards, but annoying.
14:16:04 <jralls> Huh. That's a weird constraint.
14:18:06 *** fabior has quit IRC
14:21:19 *** bertbob has joined #gnucash
14:21:49 *** gour_ is now known as gour
14:21:52 *** Mechtilde has joined #gnucash
14:23:55 *** frakturfreak has quit IRC
14:24:32 <warlord> Yeah. The error is:
14:24:39 <warlord> Starting to create Bug 58566
14:24:39 <warlord> Can't call method "name" on an undefined value at Bugzilla/Bug.pm line 1484.
14:24:55 <warlord> This error is trying to call name() on a status.
14:26:22 <warlord> LIne 1484 is the first of these lines:
14:26:24 <warlord> $new_status = ($valid_statuses[0]->name ne 'UNCONFIRMED') ?
14:26:24 <warlord> $valid_statuses[0] : $valid_statuses[1];
14:29:46 *** frakturfreak has joined #gnucash
14:29:51 <jralls> So setting "allow_unconfirmed=false" sets $valid_statuses[0] to undef?
14:30:09 <jralls> That seems like a bug.
14:33:12 <jralls> It sounds like "importing" is more like "replaying the log", which is interesting. Does that imply that exporting was effectively creating a series of transactions to play back? That might explain why it took so long.
14:33:53 <jralls> Anyway, you may be able to work around it by deferring setting allows_unconfirmed until after the bugs are loaded.
14:35:51 <warlord> Not directly..
14:36:57 <warlord> It is sort of like that, but not quite. The import IS done as a "single transaction", but it's made up of tons of sub-transactions.
14:38:22 <warlord> Exporting is literally a script that goes: 1) tell me all the bugs associated with gnucash 2) foreach bug, pull down the bug data, bug comments, bug history, and bug attachments. 3) Save all this data into json files. 4) extract all users from the bug fields 5) once all bugs have been downloaded, ask bugzilla for all the user info. Save that to json.
14:38:44 <warlord> Then the importer is "read all the json files, massage the data into a format required, and feel it all into Bugzilla::Migrate"
14:38:56 *** frakturfreak has quit IRC
14:40:02 <warlord> I think I figured out the problem. When UNCONFIRMED was turned off, there was no valid initial state for a bug. So when the bug is created it has no valid initial state. Boom.
14:40:52 <warlord> So I changed the code to modify the workflow earlier (before_insert)
14:41:30 <warlord> This seems to have fixed the problem. My dry-run worked, so I'm doing it for real now and we'll see how it goes.
14:41:59 <warlord> Yep. That fixed it.
14:42:40 <warlord> Here's a question for you: what order do you want for the status (and resolution) field options?
14:43:36 *** frakturfreak has joined #gnucash
14:47:40 <warlord> Okay, that worked. New statuses are inserted and default work flow is created. yay.
14:47:47 <warlord> So still need to deal with the additional fields.
14:48:02 <warlord> Wish there were a way to determine how they are configured on gnome-bz
14:49:21 *** fell_laptop has quit IRC
14:52:04 *** fell_laptop has joined #gnucash
14:55:43 <jralls> You mean in the dropdown? Let's make them like they are in Gnome to begin with: NEW, ASSIGNED, NEEDINFO, RESOLVED, VERIFIED and FIXED, WONTFIX, DUPLICATE, NOTABUG, NOTGNUCASH, INVALID, INCOMPLETE, OBSOLETE.
14:59:44 <jralls> ovitters is logged into #gnome ATM. If anyone knows how the additional fields are set up it's him. What are the fields besides attachments.gnome_attachment_status?
14:59:57 <warlord> Hmm. The gnome_attachment_status is a Gnome-BZ-specific extension.
15:00:08 <warlord> If we want to continue with it, we probably need to re-implement that.
15:02:29 <warlord> I've got the list as New, Assigned, Needinfo, ReOpened, Resolved, Verified (which is your order, but with Reopened in there too)
15:04:14 <warlord> For the resolution flags.. you left out WORKSFORME. I can certainly easily order the new flags in there -- changing the existing ones is a tiny bit more work.
15:05:34 *** oozer has joined #gnucash
15:05:46 <jralls> WORKSFORME isn't used by Gnome.
15:08:46 <jralls> And when the status is RESOLVED or VERIFIED the available statuses are REOPENED, RESOLVED, VERIFIED in that order. REOPENED isn't available when the bug is already open.
15:09:06 <warlord> Oh, okay. I suppose I can delete that, then.
15:09:59 <warlord> That should be the case now; REOPENED is only available from RESOLVED and VERIFIED
15:13:40 <jralls> OK. Gotta reset my pword to check...
15:15:32 <warlord> Yeah, sorry. And you'll have to reset it again shortly once I reorder the resolutions.
15:16:30 <warlord> Is it okay if the order is: [none], FIXED, INVALID, WONTFIX, DUPLICATE, NOTABUG, NOTGNUCASH, INCOMPLETE, OBSOLETE ?
15:17:11 <warlord> The [none], FIXED, INVALID, WONTFIX, DUPLICATE order is pre-set. I can change the order if you want, it's just a little more work.
15:18:26 <jralls> Interesting: Changing a bug from VERIFIED to REOPENED makes it NEW.
15:19:31 <jralls> And yeah, I don't think that the resolution order is that critical.
15:20:21 <warlord> Okay, so I'll just insert them the way I said above and leave it.
15:21:14 <warlord> WEIRD.. Why would it change from REOPENED to NEW?
15:21:27 *** Mechtilde has quit IRC
15:21:36 <jralls> What's actually showing up right now is INCOMPLETE, NOTABUG, NOTGNUCASH, OBSOLETE, FIXED, INVALID, WONTFIX, DUPLICATE, WORKSFORME.
15:21:43 *** Mechtilde has joined #gnucash
15:21:49 <warlord> Yeah, I didn't re-run with the new order.
15:21:59 <warlord> It'll take effect next time I rerun the import.
15:22:31 <warlord> Hmm, LOOKS like you changed it to REOPENED.
15:22:38 <warlord> Oh, also, can you try creating a new bug?
15:23:24 <warlord> It says "Status = Reopened" to me? Where is it saying "new"?
15:24:39 <jralls> Interesting. It was saying NEW on the bug page after I changed it, but when I went back to the list and refreshed it the status was REOP and when I went back to the bug it now says REOPENED.
15:24:56 <warlord> Hmmm...
15:27:27 <warlord> Oh.. hahaha. New Bug failed, but that's probably because of one of my migration hacks!
15:28:19 <jralls> Wow, you typed that faster than I got internal server error page.
15:28:19 *** fabior has joined #gnucash
15:28:44 *** fell_laptop has quit IRC
15:28:52 *** Mechtilde has quit IRC
15:28:57 <jralls> Or did it fail while I was actually creating the bug report?
15:31:26 <warlord> I already tried to create a new bug..
15:31:33 <warlord> So I saw the error.
15:33:06 *** fell_laptop has joined #gnucash
15:33:19 <warlord> I'm tracking it down..
15:35:43 <warlord> Okay, bug-creation works. But I just turned if off again
15:37:24 <warlord> I had missed another spot where I needed to remove code I had inserted for the migration
15:41:39 <warlord> Time to flush again and retry.. ;)
15:43:43 *** Mechtilde has joined #gnucash
15:49:20 <warlord> jralls: I'll email the list of fields that I'm currently ignoring. It'll be easier than typing them all here.
15:49:37 <jralls> ;-)
15:56:55 *** Mechtilde has quit IRC
16:06:38 *** gncbot sets mode: +o fell_laptop
16:08:28 <fell_laptop> About https://code.gnucash.org/logs/2018/05/21.html#T14:08:08: Yes, it was in use in older instances of gnome bz.
16:12:22 <warlord> jralls: okay, email sent. Hopefully it's clear. I'm getting a bit bleary0eyed
16:13:25 <warlord> fell_laptop: Thanks. But that wasn't quite the issue here, luckily. Yes, there are some UNCONFIRMED entries in the history, and that's okay.
16:16:41 <jralls> fell_laptop: Do you know anything about GDPR and how or whether it might apply to us?
16:18:24 <fell_laptop> jralls: I do not remember to read about it before todays chat log. Is it some abbreviation?
16:19:05 <jralls> Yes, it's the EU's General Data Privacy Regulation that goes into effect on the 25th.
16:20:25 <fell_laptop> Different languages, different abbreviations ;-)
16:20:37 <jralls> Natch.
16:24:02 <fell_laptop> DSGVO in german
16:27:00 <mikee> I asked about it int the user mailing list 10 Apr 2018.
16:27:04 <jralls> warlord: Can you make me an admin on bz.gnucash so that I can look at setup stuff?
16:27:25 <mikee> GDPR that is.
16:30:03 <jralls> mikee: You did indeed, but in the context of the data users store in GnuCash. Because of commentary that's been showing up over here on genealogy blogs I've gotten concerned about the data in Derek's servers like the email archives, IRC logs, and now bugzilla.
16:31:28 <warlord> jralls: Done. You are now an admin (at least until I blow away the config)
16:31:59 <jralls> warlord: Thanks. I'm still getting an internal server error when I try to create a bug.
16:32:17 <warlord> jralls: Please let me know if you make any config changes so I can make sure to persist them.
16:32:27 <warlord> Yes, bug creation is turned off in the code.
16:32:37 <warlord> Do you need to be able to create new bugs right now?
16:32:53 <mikee> jralls: Good point, I was just considereing what users would be storing within GnuCash,
16:32:57 <jralls> No, I was just testing because I thought you'd said you'd fixed it.
16:34:05 <jralls> And I'm not planning to make any persistable changes. I'm trying to figure out the variables, but I need to see into the nooks and crannies to do it.
16:34:09 <warlord> I did, but then I unfixed it. The migration/import requires some code changes -- and those code changes break bug creation. I THOUGHT I had done enough to turn it back on, but I had missed a place. Now I know where it all is, so I can easily go back again. But for now, it's off so I can migrate easily.
16:34:31 <warlord> Okay. Some of it may not be visible from the UI.
16:34:49 <warlord> I can send you my "Fetch" script that pulls from GnomeBZ?
16:34:58 <warlord> Or I can send you the json of specific bugs?
16:35:43 <jralls> ISTR you'd found a URL for looking a flags on bz.gnome. Do you remember what it is?
16:36:12 <jralls> The fetch script might be useful. That way I can get a sample of the json.
16:42:30 <warlord> jralls: sent
16:48:05 <fell_laptop> About GDPR@gnucash.org: We might Add a sentence on each account creation page: "Info according EU GDPR: To provide this service we will store your email address..."
16:49:05 <fell_laptop> Perhaps we should discuss it on -devel to catch more aspects.
16:51:52 *** fabior has quit IRC
16:55:51 <fell_laptop> BTW it is nothing completly new. End of the 1970ies we discussed the first german data protection law. Not much later EU uniffied most aspects from the different national laws and now incorporates the technical progress.
16:59:33 <jralls> fell_laptop: The new regulation apparently goes much further: Disclosure including documented opt-in permission, transfer rights, removal rights, and very heavy fines for not complying.
17:01:07 <jralls> warlord: Not received. Where did you send it?
17:05:48 *** gjanssens_afk has quit IRC
17:08:40 *** gour has quit IRC
17:14:39 <warlord> jralls: "John Ralls" <jralls@ceridwen.us>
17:15:29 <warlord> Oh, and this is why you didn't get it:
17:15:32 <warlord> May 21 16:42:26 mail2 postfix/smtp[21592]: 1E804E2049: to=<jralls@ceridwen.us>, relay=127.0.0.1[127.0.0.1]:10024, delay=0.2, delays=0.08/0.01/0/0.11, dsn=2.7.1, status=sent (250 2.7.1 Ok, discarded, id=20433-08 - BANNED: P=p003,L=1,M=multipart/mixed | P=p002,L=1/2,M=application/x-perl,T=exe,N=BugzillaFetch.pl)
17:15:53 <warlord> My anti-virus blocked it!!
17:16:14 <jralls> That's what you get for having anti-virus!
17:16:23 <warlord> LOL
17:16:25 <warlord> Yeah.
17:16:27 <warlord> Silly me!
17:20:51 <warlord> Of course it's blocking it as a gzip or a zip file!
17:25:43 <warlord> jralls: I just put it on my web server and sent you the link.
17:25:46 <warlord> *grumble*
17:26:01 <jralls> Oh, I was going to suggest tar.gz.
17:27:33 <warlord> In the end I feel the scripts should go into a source repo.
17:27:41 <warlord> Gotta run for a bit.
17:37:15 <fell_laptop> fines are limited to max (20 Mio. EUR; 4% of yearly worldwide sales)
17:51:55 <jralls> fell_laptop: I don't think warlord would consider €20M "limited", and I don't know what a court would set as his "sales". Remember there's no GnuCash Inc. (or AG) protecting him. It's his server and he's legally liable.
17:52:45 <jralls> Never mind the cost of hiring lawyers to defend himself.
18:00:34 *** boldstripe has quit IRC
18:22:45 *** ncv__ has quit IRC
18:38:22 *** pilotauto has joined #gnucash
18:42:02 *** Festour has quit IRC
19:13:49 *** kael has quit IRC
19:34:26 *** fell_laptop has quit IRC
20:09:52 *** Grav has quit IRC
22:17:29 *** tonysoar has joined #gnucash
22:22:53 *** ArtGravity has quit IRC
22:25:03 *** tonysoar has quit IRC
22:34:37 *** User has joined #gnucash
22:37:47 *** oozer has quit IRC
22:56:39 *** storyjesse has joined #gnucash
22:59:34 *** boldstripe has joined #gnucash
23:47:07 *** User has quit IRC