<div dir="ltr"><div>Hi, all!</div><div><br></div><div>I will be missing on tomorrow's meeting, but I would still like to share what I did in these two-three weeks. There are a few points marked with **NEEDS DISCUSSION**. I would really like to hear your opinion on these points.</div><div><br></div><div>1) Upgraded the AppImage runtime to the new version<br><br>   * The upgrade **broke** Krita AppImage to run on systems with AppImageLauncher <br>      installed. See bug <a href="https://bugs.kde.org/show_bug.cgi?id=503204">https://bugs.kde.org/show_bug.cgi?id=503204</a><br><br>   * The workaround for the issue is to upgrade AppImageLauncher to the "alpha"<br>     version. But, as far as I can tell, it might be impossible on **some** systems<br>     which install it using a package manager (e.g. Arch Linux).<br>     <br>   * The new runtime is currently activated in **both** the active branches,<br>     master and krita/5.2, so both branches are affected.<br>     <br>   * **NEEDS DISCUSSION:** We need to decide what to do, whether to revert <br>     this change or poke the AppImage developers about this issue or <br>     try to fix ourselves.<br>     <br>2) Made a testing branch with Ubuntu 22.04 base image for AppImage.<br><br>   Ubuntu 20.04 is reaching its EOL next month, so we should update our AppImage<br>   packages. The MR with the prebuilt packages is here:<br>   <br>   <a href="https://invent.kde.org/graphics/krita/-/merge_requests/2388">https://invent.kde.org/graphics/krita/-/merge_requests/2388</a><br>   <br>   I need people with different distributions to test the packages built in the<br>   pipeline from this MR. If it runs fine on all the knows systems, then I can <br>   start the deploying process (it is not trivial, since we should also switch<br>   the Android and Qt6 images/packages).<br>   <br>   Basically, I need a greenlight to start deploying the upgrade :)<br>   <br>3) Upgraded FFMPEG to version 7<br><br>   * **NEEDS DISCUSSION:**  It now supports AV1 encoder, perhaps we </div><div>     should add that to our GUI? Theoretically, it should be patent-free.<br>     <br>   * It now also supports hardware optimizations for Intel CPU/GPU using<br>     the QSV encoders. Personally, I didn't manage to make it work on <br>     my system. Perhaps someone could test it?<br>     <br>   * The QSV encoders are not available in the GUI, one should activate<br>     them manually by providing custom command-line in the encoder's <br>     settings page.<br>     <br>4) Been working on implementing unittests for the Metadata Deduplication MR.<br>   While writing the unittest I found a lot of issues still present with the<br>   metadata being duplicated. I think I fixed most of them, though the patch<br>   still needs to be cleaned up a little bit. I will do that after the <br>   vacation. MR: <a href="https://invent.kde.org/graphics/krita/-/merge_requests/2368">https://invent.kde.org/graphics/krita/-/merge_requests/2368</a><br>   <br>5) **NEEDS DISCUSSION:** I think my changes to the database schema in the<br>   metadata MR unintentionally activated `PRAGMA foreign_keys = ON` option,<br>   which opened a can of worms:<br>   <br>   * it seems like Krita uses foreign_key features of SQLite in the DB schema,<br>     but Krita **has never activated** actual runtime checks for this. It means<br>     that tables do declare the foreign key dependencies, but they are never<br>     verified on the runtime.<br>     <br>   * I wonder what should we do about that?<br>   <br>   * My idea/proposal:<br>   <br>     * enable foreign key checks on **development** (and nightly?) builds,<br>       do that developers should track down all the issues<br>     <br>     * disable foreign key checks on **release** builds and pray it works<br>       as before :)<br><br clear="all"></div><br><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">Dmitry Kazakov</div></div>