-
Notifications
You must be signed in to change notification settings - Fork 17
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update runtime to Gnome 40 #98
Conversation
- change plugin branch - add patched for webkitgtk
|
Started test build 42837 |
|
Build 42837 failed |
|
Freed up some disk space to build locally. Will fix this. |
|
Started test build 42851 |
|
This did build and run locally (x86_64) |
|
Build 42851 successful |
|
the plugins are ready to go too. |
|
@hfiguiere Each time we update the platform, we will have to notify you in advance to prepare an update to the plug-ins too? If so, I'll make some |
|
Anyway this looks obviously right. Let's merge. A bit sad to say goodbye to the ARM platform (with which perfectly good machines are still sold daily) too, though I guess we can't fight the change. About:
Next time, I don't think you should hesitate to use the Flathub CI to test your builds. Just note them "WIP" or something if you wish to make clear it's work-in-progress. I know for a fact that I nearly never build our flatpak locally anymore, and when I do, I temporarily deactivate webkit. I used to build GIMP locally back when I initially created this flatpak, and because of webkit, one single build was taking me nearly a full day (like 6 hours maybe? more?). Seriously when the flatpak build failed in the middle of webkit compilation after 4 hours of completely bogging my computer down, this was depressing. On the other hand, the CI has very efficient build machines as it compiles everything in less than 1.5 hour and your machine is still usable for other work. So next time, don't hesitate. I won't mind and I don't think Flathub admins mind too (it's also what the CI is for, as long as we don't overuse it, which we certainly don't). 🙂 |
|
But I have to wait 1.5hours to check a change... CI is nice, but when fixing stuff.... and reading the log is often painfully slow. Cleaning up space mean purging something in the 250GB of flatpak build caches... As for ARM (32 bits) my only problem is that this mean no flatpak for RaspberryPi as shipped because it still ship with the 32bits OS (with a completely capable 64-bit CPU). |
Doesn't it take longer on your laptop? How long does it take? I actually thought you said so (but now that I look your former messages, it doesn't seem like you said it was longer, just "it takes a while", but not comparatively indeed).
Ah ok if you actually prefer to build locally, no prob then. I know for me, I would not stand anymore having to build the flatpak of GIMP (the dev one without webkit and all would likely be better, but the stable one is a hell). No prob. Was just a proposition in case you were same as me. At each one's prefered workflow! 👍
Not only the issue of 32-bit OS on actual 64-bit hardware. I still have an older RPI (32-bit hardware), not so old at all, and it pains me that everyone would consider it as "trash". This is a really sad world where everything which is a few years old (not the new "fancy new gadget") — though in perfectly working condition — is just thrown away. IMO this is a serious social and ecological issue. And even looking at new models, the RPI zero are still 32-bit hardware and they are still being sold as we speak. It's not even deprecated material, yet it's deprecated through the software. So sad. 😢 By the way, you haven't answered on this one question I had:
|
Given that I use ccache, and it progressively rebuild, if I have to fix a build, after a module failure is fixed it doesn't rebuild again. Unlike on CI. It took me 3 or 4 attempt for webkitgtk, including wrong attempts, but in the end ccache made it faster than retrying CI many times.
tbf I don't think until the RPi4 came that it was even a machine to consider for modern desktop usage, including Gimp.
I wouldn't use a Zero to run gimp. These are really designed for embedded computing. With 512MB, it's becoming tiny. You an still get the last version on arm, it won't disappear.
Sorry. Yes it's better. But two things: if you don't change the extension version in the extension point, they should work: it combine the Gimp API (2) and the Runtime versions (40). Between two Gnome runtimes on the same freedesktop, it should be ok. 42 will likely be based on 21.08 though, which is the biggest leap: new glib, new compiler, etc. |
I use ccache too, it helps but when build time are so horrible as webkit's one, it was still bad. Also flatpak build being purely linear (except for the Maybe things evolved. Also I do have a better laptop now (though my previous laptop was not too bad either). Let's forget my advice anyway! 😛
Indeed. But some people still use these for low end desktop. Sure, I will not advise to make a pro desktop even less to do high end graphics editing (our artist's desktop computer has 32GiB of RAM for instance!). But even though GIMP is targetted at advanced graphics work, it is irrefutable that a lot of people use it mostly to crop and resize cat photos, memes or whatnot. These people still exist, so there is no reason to refuse access to GIMP if that's alright for their usage. 🤷 In the last 7 months for instance, we had nearly 1500 i386 download of GIMP flatpak (old version of course, since the arch has also been discontinued for even longer) and more than 400 downloads of the ARM version. Anyway I'm not complaining. I understand the reasons for discontinuing these platforms. It's fair. Just a bit sad.
Yeah of course. But no bug fix, etc.
Hmmm… our API version has 2 numbers (major.minor). Even though it's forward compatible (a plug-in for GIMP 2.6 for instance should still work in GIMP 2.10, albeit possibly with some warning when some functions were deprecated), we don't guarantee plug-ins for later versions to work on older version (if you used a new API for 2.10, don't expect an older GIMP to run the plug-in). Shouldn't we use the full API version? I'm actually even wondering if this versionning should not have 3 numbers now (i.e. micro as well) since we are now possibly adding new features (API functions included) even in micro releases.
Should we make a strong rule anyway? Just in case? Also do you want push access to this repo to help me maintain the GIMP flatpak? |
It's not bad advice, just that sonetime using CI is not the fastest. Fixing the WebKit build did involve some investigation. I tried a few things before the fix I did, caused by newer glib (and webkit doing stupid things like forward declaring a function that is now a macro by default....) and newer icu (we they unbroke some macros but in the end broke code working around). It would have taken much more time going through CI. (my laptop, despite being 4 year old, is a Core i7 + 16GB RAM and SSD, so it's not super slow)
Here is my post on Flathub discourse: https://discourse.flathub.org/t/revisiting-arm-32-bits-support-answer-no/924
Yes and no. Making it more complicated would make it more painful IMHO. Plugins only appeared in 2.10 for Flatpak. This is not meant to protect the API, but rather to protect runtime ABI issues.
Just let me know it's happening.
I can use it with great responsibility. Anything to help. |
|
Looks like the plugins need to be manually installed as they don't get updated because of the branch. (I will file a flatpak bug) |
Yeah I think I saw this one already. You had linked it somewhere else I was myself discussing this topic, if I recall. 🙂
Awesome. You seem nice to work with and be responsible indeed. That's why I proposed you. 🙂 Anyway the contribution rules are simple: for simple fixes, anything obviously right, without any kind of loss or whatever, just push (with sensible commit message, as you did so far, so that I or others can understand what the change is for). For anything you are not sure of, or when you wish a review yourself, you can continue to make a MR and I'll happily review, then we can discuss things. Same for controversial topics, let's continue discuss them before pushing. Anyway any idea how this works to give you write access though? It doesn't even look like I have any admin role on this repository myself. At least I can't find any administration interface. Do we have to make a request at flathub? I could not find any written process as well. @TingPing @alexlarsson Is there a process if I want to give @hfiguiere contributor rights.
Could you post the link here after you made it? Thanks! |
I think @nedrichards or @barthalion have the power to do. Thanks! |
|
@hfiguiere has been invited. |
|
@TingPing Thanks. |
Closes #84
Closes #85
Keeping as draft for now, I ran out of disk space on the install phase if webkitgtk. Will check it build here and test the build.
Also as noted, plugins will need to be updated.