Rust 1.70 required to build gtk-rs

[faern]

Thank you for providing such a helpful container definition! I noticed that some dependencies of gtk-rs now requires a newer version of Rust than included in this image:

error: package `graphene-sys v0.18.5 (https://github.com/gtk-rs/gtk-rs-core?branch=0.18#42b9caf9)` cannot be built because it requires rustc 1.70 or newer, while the currently active rustc version is 1.69.0

A simple rustup update fails with errors consistently in the container. However, I was able to work around the issue by doing this:

$ rustup uninstall stable
$ rustup install stable
$ rustup target add x86_64-pc-windows-gnu

Nothing is really broken here. Just a request for a newly built image (hopefully with #29 at the same time). And a workaround for people in the meantime.

[MGlolenstine]

Thank you for the detailed report! I'll take a look after work and see how much I can update.

I've had some issues with nightly GTK, and I hope the one referenced would work without issues.

[faern]

Thank you for the quick response. Yes, I also had issues building the image from scratch with newer GTK versions. Not sure what went wrong. But I retreated to GTK 4.8 for now.

[MGlolenstine]

GTK 4.10 should be working fine. That's one of the actions we have in CI for image building, which passed months ago.

I'll have to update versions to newer ones.

[MGlolenstine]

Firstly, I apologise for the late response; something came up.

I have managed to update the 4.6, 4.8 and 4.10 images on the Docker Hub, hopefully to the latest rust, but I haven't been able to get 4.12.4 running as of yet.

[faern]

I'm happy to hear that these new images are available! :sparkles: Nothing to apologize for. It's all free open source work :)

Do you know approximately what is blocking a 4.12 build?

I have not downloaded or verified your new images yet. But I trust they work, so I will close this issue.

[MGlolenstine]

I am not sure what is blocking the newest build, but I think it has something to do with the outdated dependencies that are getting imported with Fedora.

I'm planning on testing how a Nix->Docker container works for this, as we could get faster builds with smaller container images.

I tried updating Fedora in the past and there's one open issue relating to Fedora, but truth be told, I only used it because it had the best-written tutorial and GTK people seem to support it the best.

I'm not promising anything but to test it. I hope I can make it work, as it would make versioning easier and we could also add local builds to projects without having to run Docker.

[MGlolenstine]

After few hours of trial-and-error yesterday (#29), I've found out that the blocking dependency right now is AppStream. And the issue isn't with GTK4 itself, but Adwaita build.

Fedora, even the version 40, only provides 1.0.1 of AppStream, but the >=1.0.2 is needed for a successful build of Adwaita. That is currently an issue with all 1.4.x versions of Adwaita, so I guess I'll wait until 1.0.2 drops to update the Adwaita in the latest version of GTK4.

[faern]

That's weird! Fedora 40 is not even stable yet, and usually have very up to date packages. Does this container need so new versions of adwaita then? Can it not run an older version if the newest is too bleeding edge?

[MGlolenstine]

The container itself doesn't need the new versions of dependencies, it's Adwaita that does. The container works fine for other versions of GTK and Adwaita versions that are lower than 1.4.x.

I think they build their dependencies from scratch, which I wasn't able to achieve and felt like it was too much effort for a bleeding edge Adwaita.

I'll wait until the new version of AppStream is released and will then try bumping Adwaita to 1.4.x in another Pull Request.

EDIT: I still have to try and build these versions of GTK and Adwaita with Nix to see if it's possible to create smaller containers that we could use. NixOS also has a PR for nixpkgs for the AppStream 1.0.2, so that might help.