Add Kolibri 0.16.0b5

[dylanmccall]

#7

[GeorgesStavracas]

I suppose this is a draft because the Kolibri 0.16 release is not stable? LGTM otherwise

[dbnicholson]

I suppose this is a draft because the Kolibri 0.16 release is not stable? LGTM otherwise

I think it's a draft because the app will need some changes to actually work on 0.16.

[dylanmccall]

Yes, this was floating around from endlessm/kolibri-installer-gnome#16. It needs to be tested properly to make sure we haven't regressed anywhere else, and I didn't explain in the earlier PR why 0001-Allow-superuser-to-be-null-in-device-provision-API.patch was removed. I think we probably still need it - it's part of the initial setup process, at least until someone resolves learningequality/kolibri-installer-gnome#87 :)

[dbnicholson]

@dylanmccall Have you tested this out? Since the explore plugin depends on 0.16, this is required. Do you have any idea what things need to be changed?

[dylanmccall]

@dylanmccall Have you tested this out? Since the explore plugin depends on 0.16, this is required. Do you have any idea what things need to be changed?

Yeah, I ended up spending today on this one. Still needs a bit more time. The big thing is we need to either rebase this patch, or fix learningequality/kolibri-installer-gnome#87. Looking at the relevant changes in kolibri/core/device/serializers.py, I figured, actually, might be good to fix that issue. At least here, to start with, since we are certainly in a position to enable automatic login everywhere, regardless of the system configuration.

So I did that. But there appear to be some errors from our additional Kolibri plugins, now, so that needs to be sorted out.

[dbnicholson]

That's a nice improvement. I didn't look that closely at the last commit, but clearly the auto provision file is nice win. My other question about moving to 0.16 is more about desktop-auth-plugin's DesktopUser model vs upstream's app plugin and OSUser model. I think DesktopUser provides some pieces that OSUser, so it may not be possible. However, it would be nice to use OSUser out of the gate rather than a separate custom user model.

[dylanmccall]

I solved one issue, where the frontend was getting stuck on Kolibri's script loading spinner, with this in the log:

[Error] TypeError: fn.toString().match is not a function. (In 'fn.toString().match(functionTypeCheckRE)', 'fn.toString().match' is undefined)
	logError (kolibri.core.default_frontend-0.16.0b5.js:2:1470451)
	globalHandleError (kolibri.core.default_frontend-0.16.0b5.js:2:1470331)
	handleError (kolibri.core.default_frontend-0.16.0b5.js:2:1469797)
	(anonymous function) (kolibri.core.default_frontend-0.16.0b5.js:2:1471475)
	flushCallbacks (kolibri.core.default_frontend-0.16.0b5.js:2:1470642)

I don't really understand what the problem is, except that it is specifically happening with WebKitGtk. Solved by upgrading the runtime to what will (soon - September 20) be GNOME 45. That runtime's version of WebKitGtk works fine here.

[dylanmccall]

There is one last problem, where kolibri-daemon fails to start for the first time with the following error inside Kolibri:

INFO: Copying KOLIBRI_HOME template to '/var/home/dylan/.var/app/org.endlessos.Key.Devel/data/kolibri'
INFO: Enabling plugin kolibri.plugins.app
INFO: Enabling plugin kolibri_app_desktop_xdg_plugin
INFO: Enabling plugin kolibri_desktop_auth_plugin
INFO: Enabling plugin kolibri_explore_plugin
Process KolibriHttpProcess-1:
Traceback (most recent call last):
  File "/usr/lib/python3.11/multiprocessing/process.py", line 314, in _bootstrap
    self.run()
  File "/app/lib/python3.11/site-packages/kolibri_daemon/kolibri_http_process.py", line 54, in run
    init_kolibri()
  File "/app/lib/python3.11/site-packages/kolibri_daemon/kolibri_utils.py", line 52, in init_kolibri
    initialize(**kwargs)
  File "/app/lib/python3.11/site-packages/kolibri/utils/main.py", line 283, in initialize
    _upgrades_before_django_setup(updated, version)
  File "/app/lib/python3.11/site-packages/kolibri/utils/main.py", line 197, in _upgrades_before_django_setup
    autoremove_unavailable_plugins()
  File "/app/lib/python3.11/site-packages/kolibri/plugins/utils/__init__.py", line 416, in autoremove_unavailable_plugins
    raise RuntimeError("Attempted to update plugins when registry is initialized")
RuntimeError: Attempted to update plugins when registry is initialized

It starts fine a second time, because it doesn't try to re-enable the plugins a second time. (If I hack around and force the app to execute that code to enable plugins anyway, we run into the same error in every case).

I'm not sure why things are happening in the wrong order and need to do some spelunking 🤔

---

Update: Spelunking concluded! I don't think we need that registered_plugins.register_plugins bit anymore.

[dbnicholson]

Awesome!

[starnight]

Verified and covered by #49 (comment)