[18.26]MIG2[19.0]

[marcos-mendez]

@OnGle and @JedMeister

I just finished reviewing, Have to fix TKLBAM still tought

Hope it helps (maybe a little gohorse style with AI but compiled and worked in IPv6

Now i can keep working on the apps

Thanks guys!

popsolutions/common@a5cf6d4#r180163665

[OnGle]

Awesome stuff!, TKLBAM has been a pretty big thorn in the side for the py3 update. We have a temporary work around, in the form of an embedded pypy runtime until we finalize a proper py3 update. Love to checkout the progress you made.

Off the top of my head the biggest issue was the way it handled strings & byte objects. Because python2 treats strings as byte strings by default, there's no enforced encoding. Which means unfortunately any embedded strings in anything that get's read/written by tklbam2 doesn't have a well defined path into python3 which now handles strings and byte-strings as distinct objects.

[l-arnold]

Not fully related to TKLBAM 19, but being TKLBAM 18 implemented perhaps it is, I am mentioning here that I did some work over the last month and made a "tklbam-rescue" script which I have run off a few Turnkey imaged, VirtualBox servers, and effectively pulls specified tklbam backups off of the hub and stores them, unencrypted onto a local cifs mount server. From there the backups can still be called by TKLBam (assuming the mnt is accessible) for running a restore.

I have done this primarily to reduce some Hub Storage costs, but also to have more practical explore capability for what is in the old data sets, which has been quite practical here and there.