@Trizek-WMF, sure - there is nothing particularly specific to chapters here. I have retitled the task accordingly.

Thanks a lot, @bd808! I've already upgraded my tool to the python3.5 image.

This is especially confusing given that python3 --version returns 3.5.3 when logging in to tool forge and becomeing the tool user.

Um, @intracer, do we know where the source recordings are? Is there still a chance to find them? It would be nice to archive them in some way, and maybe they can still be useful despite we didn't create the final video anyway.

Thank you. Updated the wiki accordingly.

Thank you, @bd808, for the clarification and explanation, and to @jcrespo for providing all the nitty-gritty details and more workarounds.

In T198508#4452398, @jcrespo wrote:

Do you mean specifically the indexes on utf8mb4 will fail under these conditions, until mariadb >= 10.2.2 is deployed? Or something else?

No, 10.2 will fail, too, because bad client configuration is being used. Both newer versions of MySQL and MariaDB use utf8mb4 as a default, and so will do toolsdb. Change the database default as I suggest at T198508#4447768 as a fix -this is not an infrastructure bug.

You said

10.0.34 version of MySQL in which limitations are imposed on index columns

But in reality is bad support from the python-social developers, it works if they decided to support properly utf8mb4 + innodb_large_prefix, which is now the default on newer versions.

or it will fail everywhere by default (I just adjusted 10.0 to the newer version default). :-(

In T198508#4447698, @jcrespo wrote:

Your problem is not mariadb (10.0 is fully supported) your problem is trying to use utf8mb4- while mediawiki developers used to support utf8 (3-byte utf) they decided to support only binary for new installation. See: T194125

In other words- upgrading the server, while it is certainly going to happen soon, it will only make the problem worse, not better :-)

In T190274#4073781, @Chicocvenancio wrote:

I share @zhuyifei1999's frustration here. Adding a system package is possible, but will add to image build time and size, and this is something that should not be needed.

That being said, Django is a popular enough framework that I do think it should be supported "as recommended" or as close to that as possible. If no one strongly objects I will send a patch by tomorrow and build the new images once/if that is approved.

I have added a note to the documentation about these issues. But I hope they can be fixed (by upgrading mariadb) so that no workarounds are needed.

I have added a note to the documentation about this limitation. The django oauth tool tutorial probably needs updating, although it focuses on sqlite.

Another possible workaround is to use utf8 instead of utf8mb4, however that means partial Unicode support.

I must say that for a newcomer to tool forge it's very confusing to discover that django's default database driver can't be installed while following the documentation where django is even given as an example. If mysqlclient-dev can't be made available, please update the wiki page with a clear notice of how to get django running in these conditions.

Great. It seems unlikely I'll be able to come, however:( Who's coming?

Any possible dates negotiated?

Good, thanks.

@ViraMotorko_WMUA, please confirm you're on board (or let me know if you're not).

Maybe something like dash.wmflabs.org at least?

Звичайно у нас є можливість переносу конфігурації сервера — вона ж не зашифрована якась. Але для цього потрібен певний «перехідний час», коли обидва сервери працюватимуть паралельно (скажімо, тиждень), і сервіси один за одним переноситимуться з одного на инший з поступовим перемиканням доменів на новий.

This could have been expressed in a comment. I refuse to accept this as a task assigned to me, but I accept this as your opinion and I agree with most of it.

We were discussing plans to change our VPS provider, is it going to happen and when? If so, it would make sense for me to start replicating our current services on the new VPS under puppet.

Is it likely to have this implemented by September?

So this needs to be updated with a step-by-step guide on creating a task.

Probably we also need to create groups like WMUA board and WMUA staff.

Updated (I assumed this is obvious from parent task)

Possible additional volunteers: @Antanana, @Pavlo1, ...

In T146332#2787068, @Ragesoss wrote:

In T146332#2781007, @dungodung wrote:

https://dash.wikimedia.org/ would work for me :)

+1

I agree - currently the *requirement* to have the password raises the threshold of joining the course (one more piece of information needs to be copy-pasted or remembered). It should be optional.

@Ragesoss, thank you, good to know. So this leaves us with a relatively small subset of users who we can hopefully ask to login on Meta once.

Thank you, @Ragesoss, for looking into this so urgently. I still can not add the user though - they haven't got a meta account either. I think that a full solution would be to change the requirement from a specific wiki to any wiki that is connected to SUL. And I wonder which one - Engilsh Wikipedia or Meta - is more likely to be the wiki that a teacher at a university will have an account on?

Just created a test account on a non-English Wikipedia. Then I tried adding that account as a Facilitator and it failed. Bust as soon as I visited English Wikipedia and logged in there with the test account, I could add it as a Facilitator. So it seems to depend on the account existence specifically on English Wikipedia.

This is probably the same bug: I can not add a Facilitator to a course I have created. It returns an error: Sorry, Kunst is not an existing user. But the user definitely exists: https://tools.wmflabs.org/guc/?user=Kunst

Something like this?

• space name: something like WMUA Tech Nonpublic
• group lead: @intracer
• users: @Yury_Bulka, @Ahonc