Cannot build under Ubuntu

[janrothkegel]

Hi all,

I followed the build instructions. I am unsure about the version constraint on gtk and libadwaita. Both of them are only available as older versions in the repository and also the GTK website is not very helpful. I receive the following error:

~/Downloads/repos/Pinta$ dotnet run --project Pinta

(process:491668): Gtk-WARNING **: 20:44:00.816: Theme directory emotes@2x/22 of theme WhiteSur-light has no size field

(pinta:491668): Gtk-WARNING **: 20:44:01.286: Theme directory emotes@2x/22 of theme WhiteSur-light has no size field

(pinta:491668): Gtk-WARNING **: 20:44:02.711: AdwGizmo 0x61310c76a250 (tabboxchild) reported min width -6, but sizes must be >= 0

(pinta:491668): Gtk-WARNING **: 20:44:02.760: AdwGizmo 0x61310c76a250 (tabboxchild) reported min width -6, but sizes must be >= 0

(pinta:491668): Gtk-WARNING **: 20:44:02.784: AdwGizmo 0x61310c76a250 (tabboxchild) reported min width -6, but sizes must be >= 0
Unhandled exception. System.TypeInitializationException: The type initializer for 'Pinta.Gui.Widgets.PintaCanvas' threw an exception.
---> System.EntryPointNotFoundException: Unable to find an entry point named 'gdk_memory_texture_builder_get_type' in shared library 'Gdk'.
at Gdk.Internal.MemoryTextureBuilder.GetGType()
at Gdk.MemoryTextureBuilder.GetGType()
at Gdk.Internal.MemoryTextureBuilderHandle.For[T](ConstructArgument[] constructArguments)
at Gdk.MemoryTextureBuilder..ctor(ConstructArgument[] constructArguments)
at Pinta.Gui.Widgets.PintaCanvas.CreateTextureFromSurface(ImageSurface surface, Texture updateTexture, Region updateRegion) in /home/janrothkegel/Downloads/repos/Pinta/Pinta.Gui.Widgets/Widgets/Canvas/PintaCanvas.cs:line 150
at Pinta.Gui.Widgets.PintaCanvas.CreateTransparentPatternTexture() in /home/janrothkegel/Downloads/repos/Pinta/Pinta.Gui.Widgets/Widgets/Canvas/PintaCanvas.cs:line 164
at Pinta.Gui.Widgets.PintaCanvas..cctor() in /home/janrothkegel/Downloads/repos/Pinta/Pinta.Gui.Widgets/Widgets/Canvas/PintaCanvas.cs:line 43
--- End of inner exception stack trace ---
at Pinta.Gui.Widgets.PintaCanvas.DrawTransparentBackground(Snapshot snapshot, Rect canvasViewBounds) in /home/janrothkegel/Downloads/repos/Pinta/Pinta.Gui.Widgets/Widgets/Canvas/PintaCanvas.cs:line 174
at Pinta.Gui.Widgets.PintaCanvas.UpdateCanvas() in /home/janrothkegel/Downloads/repos/Pinta/Pinta.Gui.Widgets/Widgets/Canvas/PintaCanvas.cs:line 124
at Pinta.Gui.Widgets.PintaCanvas.b__11_0() in /home/janrothkegel/Downloads/repos/Pinta/Pinta.Gui.Widgets/Widgets/Canvas/PintaCanvas.cs:line 105
at GLib.Internal.SourceFuncNotifiedHandler.<.ctor>b__4_0(IntPtr userData)

Could anybody please assist?

Thanks
Jan

[badcel]

The class MemoryTextureBuilder is available since GTK 4.16.

So you probably need an environment which provides this dependency to be able to run the code.

I think there are flatpak and snap packages available.

[JGCarroll]

Fedora would be a fantastic distribution for building Pinta on, but it wouldn't build on Fedora 41, which is only a single version behind their current stable.

Ultimately Ubuntu has the same 6 months schedule as Fedora does if we're happy to ignore LTS concerns. But as far as LTS' go, RHEL 10 was released 2 months ago, and can't build Pinta either, for being Gnome 46 whereas Pinta is expecting Gnome 48.

I think GTK is just in an awkward position in the ecosystem and it's why Gnome invests into Flatpak so heavily amongst their own apps, if KDE were in the dominant position, it'd be the same story for them too (hence why KDE also invests heavily into Flatpaks and Snaps for their apps).

[MikePryadko]

there are flatpak and snap packages available

But all that we need it's DEB-package :)
P.S. why ppa-repository is veeeeery outdated? Ubuntu is most popular Linux Distro and apt is most popular packaging tool! Why are Pinta's devs promoting flatpack&snap?!

[JGCarroll]

Flatpak and Snap can provide GTK4 backports to Ubuntu 16.04; an Apt package of 3.1 cannot be built for Ubuntu 24.04 even if it were a PPA without extreme hackery. Similarly Mono/C# work the same way, but GTK is the bigger of the two problems.

In the context of this discussion, Debian 13 has just released with GTK 4.18, meaning 3.1 will now build on Debian 13, but not Ubuntu 24.04. This might be the case for a few months, but if e.g., Pinta starts using Glycin directly in GTK 4.20 - then it will stop immediately building on Debian 13 and it wouldn't be until 2027 the next version of Pinta would work for Debian, in version 14, via Apt. And that's assuming the minimum GTK version isn't updated yet again.

I sympathise that people would rather a .deb exists and just works, but the stability policy in Ubuntu that's mirrored in Debian is that software does not get updated. A PPA can break this by forcing packages onto the system that don't have to follow upstream policy, but the technical work involved in making that .deb would be packaging the entirety of GTK and C# (Debian doesn't have .NET and people would use the PPA regardless of them being explicitly intended for Ubuntu) for 12 years of distributions across 2 architectures, or alternatively, one flatpak/snap, and someone has to be willing to commit to maintain that for a period of years.

It's exactly the same technical problem that makes an .AppImage equivilently difficult, you can't rely on GTK4 from the host, so you'd have to package it specifically. The packaging work is significantly more for GTK than Pinta.

[MikePryadko]

@JGCarroll looks like we need to write a new one painting app 😁 on C or Rust (or maybe Java)

[JGCarroll]

.NET Maui, obviously ;)
Maybe Avalonia
For legal reasons, this is half a joke.

[Skif-off]

I tried a slightly different approach in my Xubuntu 24.04.
I backported the following packages:

cairo-1.18.4
gtk4-4.18.6
harfbuzz-10.2.0
libadwaita-1-1.7.0 (with small fix)
libpng1.6-1.6.47
pango1.0-1.56.3
wayland-1.23.1
wayland-protocols-1.41

and compiled Pinta with these packages. (Pinta and libraries/packages were built in a virtual machine with sbuild.)
I extracted the libraries from the DEB files, copied the necessary .NET 8 files and use the following script:

#!/bin/sh

#export GTK_THEME=Adwaita
#export GTK_THEME=Greybird-dark

DIR=`dirname "$0"`

#export DOTNET_ROOT=$DIR/lib/dotnet

export XDG_DATA_DIRS="$DIR/share:$XDG_DATA_DIRS"
#export GSETTINGS_SCHEMA_DIR="$DIR/share/glib-2.0/schemas:$GSETTINGS_SCHEMA_DIR"
export LD_LIBRARY_PATH="$DIR/lib/x86_64-linux-gnu:$LD_LIBRARY_PATH"
#export PATH="$DIR/bin:$PATH"

exec $DIR/lib/dotnet/dotnet $DIR/lib/pinta/Pinta.dll "$@"

P.S. I don't like Snap and Flatpak.

[MikePryadko]

Hi! Don't you try to build in Docker? As I know it's a good way: for example, FreeCAD comes with ready dockerfiles for that purpose 🙃 and it works excellent 😎

P.S. I don't like Snap and Flatpak too))

[Skif-off]

Hi @MikePryadko!
I have never used Docker :) I use sbuild, which allows me to avoid cluttering the system with dev packages (especially if packages mighty conflict), and I don't see the point in learning an additional tool, because sbuild helps in this case too.

[janrothkegel]

From a very high-level point of view: Couldn't we just run the build and some desktop in a docker container using VS Code remote extension? Of course, for testing one would need to access the desktop via RDP or similar. But could this give a more robust and standardized build process for developers? (Probably encouraging more people to contribute...)

[srd8580]

@janrothkegel , I am in the exact same boat as you, I would like to contribute as well, but I am on Linux Mint 22.2, which is based on Ubuntu 24.04. I have a Windows 11 VirtualBox I could use, but that's always a bit of a pain. What did you end up doing to get a dev environment running? Thanks.

[JGCarroll]

You could do this for the development side yes, the newest Ubuntu (non LTS) release, both Fedora releases, Debian 13, Arch, etc - would all build Pinta in a Docker/VM environment. If you hooked it up with a GUI, you'd be fine.

The difficulty is in the distribution after the fact which becomes problematic, but for development alone, Docker/VM's would be a valid approach, I'd recommend giving Debian 13 or Fedora a go, with a minor preference for Fedora in this case since I'm told it already has C# in its distribution repos, which will slightly simplify things for you.

[janrothkegel]

I tried the fedora-xfce variant of webtop. After adding some packages I was able to build and run in Docker. However, I was not able to make it work with VS Code as VS Code always complains about not being able to install .NET 8. In fact was already in place, I have just the silkies version of VS Code. Maybe it works when trying it natively. Unfortunately, my holidays are over now but maybe I will be able to play a little bit around anyway.

[janrothkegel]

Good news 🙂 I was able to attach from VS Code in the host to a Fedora container with a desktop. Now I can develop on the host (of course everything is actually running in the container) and when I start debugging, Pinta pops up in the remote desktop. I will now need some time to create a solution that automatically does all the stuff when launching VS Code.

@JGCarroll Do you believe it makes sense to integrate this kind of solution into the Pinta repository? Or will it be better if I create a dedicated repository and add Pinta as a submodule? The latter might be more flexible when it comes to running on different desktops and migrating as soon as webtop drops new images...

[JGCarroll]

More a @cameronwhite question to be honest but I think exposure plays parts in things getting used and being for developers if it could easily sit in the main repository, it's probably worth doing that.

[janrothkegel]

@srd8580 Maybe you can try my fork. Unfortunately, it is not working automated as these dev containers do create containers in containers that will not run the actual Fedora system from the Dockerfile. Here are the instructions for now:

1. (Make sure to have Docker installed and in the right user group etc. when on Linux)
2. Clone https://github.com/janrothkegel/Pinta.git
3. Open folder in VS Code
4. It should already ask you for automatic installation of extensions, but if not so: Manually install C#, C# DevKit, Container Tools, Dev Containers
5. First real step is to (1) right-click docker-compose.yml in .devcontainer and then (2) "Compose up" (this will take incredibly long when doing it for the first time)

6. Now, (1) click the "Containers" extension, (2) right-click the dev container and (3) attach to it. The server will then install in the container.

7. In the new VS Code window you will need to open /config/Pinta/.
8. VS Code will hopefully ask you to install some extensions. If not so: Install C# and C# DevKit manually.
9. (Give it some time to discover the projects; see indicator in the status bar)
10. Go to (1) "Run and Debug" and (2) hit the play button.

11. See the application popping up in http://localhost:3000/ or (if your browser restricts HTTP) https://localhost:3000/

Never use the "Reopen folder in Dev container" option or similar.

Some of the steps become redundant or faster when doing it again.

Please let me know whether it is working.

[srd8580]

@janrothkegel , this is good stuff! Looks like you've done some great work on this! I will give all of this a shot when I get some time (most often that's weekends :)).

[srd8580]

@janrothkegel 's instructions were beautiful and worked like a charm! Debugging and running in the browser in about 5 minutes. I had docker installed already, but not docker-compose. Well done!

[janrothkegel]

@JGCarroll @cameronwhite Will I just create a branch on my repo and then send a pull request or how do things work for Pinta?

[JGCarroll]

Send the PR and Cameron will have a look - there's no real rules beyond trying to keep things elegant (minimal patches for the scope, running dotnet format, etc).

There's contribution guidelines here but they're very generic really.

Having looked briefly at your branch, it'd be neat if you could clarify this line

FROM lscr.io/linuxserver/webtop:fedora-xfce

from the perspective of, who is lscr.io, is this image likely to be available for long term use, etc.

Otherwise I'd have wondered if e.g., Github Codespaces might also be a valid approach to this as I believe it's meant to solve similar problems, but I'm unsure if there's GUI support or perhaps a way to expose a GUI from the Codespaces VM.

Otherwise it looks fine but maybe the README.md could be updated to refer to it and encourage people to use it. Popularity might rise and fall overtime considering e.g., Ubuntu 26.04 should build Pinta fine but perhaps by 2027 we're back in this same position. Ultimately if it helps get contributors and people are happy to use it, I don't see any real reasons to not include it personally.

[janrothkegel]

@JGCarroll @cameronwhite It is true that I should probably register my own derived image in DockerHub in order to persist the status (I think I mentioned this earlier as well). I don't think that Codespace is the right place, but I like the approach of keeping things separated until I or someone else comes up with a fully integrated 1-click dev container solution. That's why I created https://github.com/janrothkegel/pinta-virtual-dev-environment and a pull request #1833, which simply references this project for those who have problems building in their host OS. Please have a look.

[ryan-de-boer]

I had the same ubuntu error, but I switched to "openSUSE-Tumbleweed" distro in WSL and it all worked fine. So if you can use another distro then that is an option. But of course wouldn't it be nice if it worked in any distro including ubuntu.
A bit more info in: #2032
Sorry for resurrecting this thread, but I like readers to have all the known options. I actually initially wanted to use Fedora but WSL doesn't support that distro - so I guess WSL has its limitations too.

[JGCarroll]

Ubuntu 26.04 would be out next month, I'm unsure when WSL2 would be eligible to recieve it, but that should be able to build Pinta.

FWIW Fedora does appear for me:

PS C:\Users\james> wsl --list --online
The following is a list of valid distributions that can be installed.
Install using 'wsl.exe --install <Distro>'.

NAME                            FRIENDLY NAME
Ubuntu                          Ubuntu
Ubuntu-24.04                    Ubuntu 24.04 LTS
openSUSE-Tumbleweed             openSUSE Tumbleweed
openSUSE-Leap-16.0              openSUSE Leap 16.0
SUSE-Linux-Enterprise-15-SP7    SUSE Linux Enterprise 15 SP7
SUSE-Linux-Enterprise-16.0      SUSE Linux Enterprise 16.0
kali-linux                      Kali Linux Rolling
Debian                          Debian GNU/Linux
AlmaLinux-8                     AlmaLinux OS 8
AlmaLinux-9                     AlmaLinux OS 9
AlmaLinux-Kitten-10             AlmaLinux OS Kitten 10
AlmaLinux-10                    AlmaLinux OS 10
archlinux                       Arch Linux
FedoraLinux-43                  Fedora Linux 43
FedoraLinux-42                  Fedora Linux 42
eLxr                            eLxr 12.12.0.0 GNU/Linux
Ubuntu-20.04                    Ubuntu 20.04 LTS
Ubuntu-22.04                    Ubuntu 22.04 LTS
OracleLinux_7_9                 Oracle Linux 7.9
OracleLinux_8_10                Oracle Linux 8.10
OracleLinux_9_5                 Oracle Linux 9.5
openSUSE-Leap-15.6              openSUSE Leap 15.6
SUSE-Linux-Enterprise-15-SP6    SUSE Linux Enterprise 15 SP6

Maybe try giving wsl.exe --update a go? Or might be that there isn't a "Fedora" generic name like there is for Ubuntu, looks like it's FedoraLinux-43 specifically above.

You've also Debian which I think Debian 13 has the right GTK to build Pinta too whilst being closer to Ubuntu, you'd have to get DotNET from the Microsoft Debian repository though as it isn't part of the base repo like in Ubuntu.

[ryan-de-boer]

Nice, yeah I noticed on another computer I had a different list of distros. Thanks for that. Nice to see Fedora and Arch Linux there.
I wrote up a guide on getting it working in Tumbleweed here:
#2040
It was pretty easy to do. The hardest part was getting saving eg png files working, I think I have the steps required but I did so many things I could have missed something.

[ryan-de-boer]

I got it working easy on Ubuntu 25.10. I put instructions here:
#2077
Or you can wait till 26.04, should be simple on that too.