GCstar forums - libgtk2-perl (and thus gcstar) removed in Debian Testing

I contacted some months ago the GCstar debian package maintainer on Launchpad to make sure that it would be based on the latest version of GCstar on Gitlab after the initial SVN repo closed. I'd didn't received any answer at that time. So currently the GCstar on Debian is outdated and it may become worse when GTK2 is removed!

Migrating to GTK3 may be tricky : GCstar is a multi-OS application running on Linux, Windows and MacOS. We thus have to make sure that the move can be done on all platforms and check that the Perl bindings are available and usable. I can check on Windows and some Linux distribution but not on MacOS.

In the meantime, I hope that the libgtk2-perl package will be available from unofficial or legacy repository so it can be declared as a dependency for GCstar.

Anybody wanting to help can fork the Git repo and create a new branch to propose evolutions of the source code.

Thanks for investigating this issue!

I'd rather let you work alone on the gtk3 branch and merge it without review by default. We will only merge it to the main branch if we're sure it's cross-platform or if it's a condition to be officially supported again in major Linux distribs.

Before that, you may do merge requests that fixes things in the current version and are not directly related to the GTK3 migration.

Great, thanks! I have been a bit distracted learning all about containers to run the existing version in Docker for the time being, but I will have some time to contribute on the GTK3 port again probably sometime next week. I guess to divide workload, I may as well start on the Preferences dialogue and we'll see how things go.

Oh, sorry. I wasn't clear on my configuration. I'm leaning a bit ahead and running on the Testing repo (what will become Bullseye), so I see the issue before most people. On the plus side, it gives us time to fix it ahead of time! The Buster packages are no longer compatible in my case.

Looking into Snap or Flatpak was also an option, but there are no packages presently and I didn't want to dig too deeply into learning them... yet. I did want to learn about containers for a while, so it was an excuse. Not the intended use case, but it works for me

Sure. I went for simplicity of setup rather than minimal disk usage, so I based it on the Debian (stretch) base image. Because I had two apps to package (gmusicbrowser is in the same boat), I made a common image with libgtk2-perl included (plus deps).

Dockerfile for that (I named the image perl-gtk2:latest)

FROM debian:stretch
RUN apt-get update && apt-get install -y libgtk2-perl

For the actual gcstar docker, I created a local user. To keep integration seemless, I made the user (and uid) match my external user.

Here's the gcstar dockerfile:

FROM perl-gtk2:latest
ENV LOCALUSER=zerker
ENV LOCALUID=1001
RUN useradd $LOCALUSER -m -u $LOCALUID && \
    mkdir /home/$LOCALUSER/.config
RUN apt-get update && apt-get install -y gcstar
USER $LOCALUSER
CMD /usr/bin/gcstar

Then, I create a shell script to launch it properly for my setup, mapping enough stuff for X11 to work, and so I could access my collections and gcstar config:

docker container run \
    -v $HOME/Collections:$HOME/Collections \
    -v $HOME/.config/gcstar:$HOME/.config/gcstar \
    -v $HOME/.Xauthority:$HOME/.Xauthority \
    -v /tmp/.X11-unix:/tmp/.X11-unix \
    -e DISPLAY \
    --net=host \
    --rm \
    gcstar

This is pared down from a guide I found online, but that made some iffy decisions... like manually editing passwd and putting the user in the sudoers file. Plus it had some holes, which were mentioned in the comments section but never fixed in the blog.
   
There's also the x11docker project, but that seemed too complicated for what I wanted. Complete security isolation wasn't a goal for me.

Last edited by zerker (2019-11-08 22:14:02)

Bonsoir kerenoc.
Pourquoi vouloir modifier .Xauthority ? Le truc risque de poser un problème .

Je pense que le problème de menu vient de là .

Je ne suis un spécialiste mais je connais assez bien les systèmes GNU/LInux et X11 est obsolète.
La dernière version est la 7.7

That's exactly it. X11 is still very much in use for GTK2 applications, even with XWayland on Wayland systems. It's really only read access that is needed for Xauthority, so I probably could have locked down the bind mount security a bit more than that. There's also a way to use xhost and xauth to explicitly allow certain connections, but I didn't want to do too much digging for this particular container.

Also, 7.7 is the last combined release of X11. Since then, they've been updating the individual components as separate releases. For example, for xorg-server itself, version 1.20 was released in May, 2018 while the most recent point release 1.20.5 was released in May this year.

Last edited by zerker (2019-11-10 13:04:03)

Bonjour,
Je suis sous Debian Buster/unstable et c'est le passage de PERL 5.28 en 5.30 qui me demande la désinstallation de la dernière version test de GCStar.
N'y-a-t'il pas un endroit où indiquer l'utilisation d'une version supérieure de PERL dans GStar, si possible ?
Merci à tous

I used PAR Packer to create an executable that could embed Perl and  some necessary dependencies, to be launched in the "bin" directory of GCstar from the Gitlab Test branch, after setting the execution permission.

I tested it on a fresh Debian 10.1 but not on sid/testing.

Last edited by kerenoc (2020-06-13 10:34:11)

I choose gcstar.exe to avoid colliding with the Perl script : one can rename it a.out if it seems less strange .

Thanks for the modification : it's now merged in the GTK3.

There seems to be some limits to the use of EPIC for GCstar as you noticed. It may come from the fact that some processing is launched asynchronously using timers?

To debug, I sometime find it useful to launch the app with
% perl -w -d gcstar

That seems to produce the maximum level of debugging information, including the call stack for some exceptions.

In my environment, some collections open correctly while others produce an error in the XML backend, a part that shouldn't be impacted by the GTK3 migration!

I'm currently trying to make the image list mode work.

Wow, thanks so much. Sorry I haven't been more help; I was a bit discouraged by my previous stumbling block and started working on other projects instead.

Now with a more functional base, I will hopefully be able to poke at it a bit more to help out again.