TryExec prevents session launching

[HashBangAU]

I've found that the bambam session isn't offered to me on the Pop!OS login screen if the file in /etc/X11/sessions/ contains the TryExec= line.

Perhaps it's failing because the file is a script with a shebang rather than a real executable, or maybe it's unable to run that check for some reason?

Background:

• I've just discovered bambam after looking in the app store for something my kid can mess around with. It's a cool project, thanks! I might try swapping in some assets from pictures of family members etc.
• The package manager gave me a real old version, so I had to manually download and run the commands to set it up with the magic `--in-dedicated-session' flag.
• It didn't work straight away, but I'd been messing around with the .desktop files already, so I tried stripping it back to just the minimum, and it worked! By adding and removing stuff, I realised it was the TryExec.
• I'm happy to push a PR to just remove those lines, if that's an acceptable solution. If you want to keep TryExec, maybe you could check for the presence of python? That'd be a real binary executable file.

[porridge]

Thanks for the report! I'm glad you like bambam. My kids are already too old to use it 😉

This TryExec issue is puzzling. There is nothing in the specification that says the specified file must be an ELF binary 🤔

It says:

If the file is not present or if it is not executable, the entry may be ignored

Are you sure the specified file was present and executable for all users?

[HashBangAU]

I appreciate your quick reply. You're asking the right question with "...executable for all users?".

If I move the install out of my home directory to /opt/bambam/, it works fine with the TryExec left in, I guess because the presence of the file is checked before auth, even though the real launching is done after.

The docs saying "executable file on disk" must be just talking about the permissions bits, not the file type.

It was bit easier to extract the tar and run those setup commands as myself in my owned directory structure, and it almost worked that way, but it's better off being a multi-user install with a bit of sudo and adjustment. It might be worth a note in Manual Installation section of the README?

[porridge]

It would be great if you could suggest a change in a PR 🙏🏻

[HashBangAU]

I've opened #190

I was playing around on Pop!OS 22.04 originally, but today I went to set it up on an old laptop that I don't mind my daughter drooling on, and unsuccessfully tried Pop!OS 24.04 (Wayland based) before switching to Debian 13 with LXQt to make sure I got a nice up-to-date X11 environment.

Maybe I should try the versions from the apt repo again, instead of manual install. Ubuntu Jellyfish repo still only had 1.1.2 for me, but newer Ubuntu versions and Debian Trixie should have 1.2.1 or 1.4.1 with the --in-dedicated-session stuff?

Edit: sudo apt install bambam on Debian trixie just works straight away, getting the /usr/share/xsessions/bambam-session.desktop path right and everything.

[porridge]

niedz., 25 sty 2026, 13:22 użytkownik HashBangAU ***@***.***> napisał:

*HashBangAU* left a comment (porridge/bambam#189) <#189 (comment)> I've opened #190 <#190>

Thanks!

I was playing around on Pop!OS 22.04 originally, but today I went to set it up on an old laptop that I don't mind my daughter drooling on, and unsuccessfully tried Pop!OS 24.04 (Wayland based)

Interesting, what happens under Wayland?

newer Ubuntu versions and Debian Trixie should have 1.2.1 or 1.4.1 with the --in-dedicated-session stuff?

https://packages.debian.org/bambam and https://packages.ubuntu.com/bambam will tell you which suite has which version.

[HashBangAU]

Sorry, my mistake, I'm learning as I go and apparently getting a fair bit wrong.

I upgraded to Pop!OS 24.04 on the Mini-PC (not the laptop), did the automatic install with sudo apt install bambam, and it works fine. Maybe there was an issue with the hybrid GPU setup in the laptop, or I just got the path for the desktop file wrong or messed up something else in the manual install.

I've force pushed to my PR branch, retracting statements about Wayland.

Out of interest, when you submit source for the debian/ubuntu repositories, how does it decide where to install BamBam to, and where to put that bambam-session.desktop file? I can't see any scripts for that in the github files, unless it's in the Makefile somewhere.

[porridge]

Sorry, my mistake, I'm learning as I go and apparently getting a fair bit wrong.

I upgraded to Pop!OS 24.04 on the Mini-PC (not the laptop), did the automatic install with sudo apt install bambam, and it works fine. Maybe there was an issue with the hybrid GPU setup in the laptop, or I just got the path for the desktop file wrong or messed up something else in the manual install.

Interesting. Out of curiosity I installed PopOS 24.04 on a VM, and put the bambam-session.desktop file in /usr/share/wayland-sessions. It appeared under the cogwheel icon in the login prompt, and bambam starts, but does not seem to accept any input, neither from keyboard or from the mouse, so I'm stuck at its "welcome" screen. And after switching to another VT and back, it disappears. 🤷🏻

When you upgraded, are you sure you're using a wayland-based session and not an X-based one? 🤔

I've force pushed to my PR branch, retracting statements about Wayland.

Out of interest, when you submit source for the debian/ubuntu repositories, how does it decide where to install BamBam to, and where to put that bambam-session.desktop file? I can't see any scripts for that in the github files, unless it's in the Makefile somewhere.

It's in the debian branch: https://github.com/porridge/bambam/blob/debian/debian/install

[HashBangAU]

The package install process puts the desktop file in "/usr/share/xsessions/bambam-session.desktop", which appears to work correctly for me. Maybe putting it in "/usr/share/wayland-sessions/" changes how it gets launched?

I believe PopOS uses Wayland primarily, and COSMIC has its file in "wayland-sessions", but maybe X11 is still available? Or there's XWayland in there as a compatibility layer?

I'd need to read some more to really know what's happening.

I upgraded to 24.04 by doing a clean install, so there couldn't have been any remnants of 22.04 hanging around from pre-COSMIC.

[porridge]

Yeah, I'm not sure either. But I know putting bambam-session.desktop in /etc/X11/sessions has no effect for me (no bambam session menu item on login screen) on freshly installed PopOS 24.04. But installing it in /usr/share/xsessions/ works OK. So I guess the /etc/X11/sessions directory might be a Debian-specific thing, in which case it would be better to at least mention the other directory in the README.

…

Message ID: ***@***.***>

[porridge]

Out of curiosity I installed PopOS 24.04 on a VM, and put the bambam-session.desktop file in /usr/share/wayland-sessions. It appeared under the cogwheel icon in the login prompt, and bambam starts, but does not seem to accept any input, neither from keyboard or from the mouse, so I'm stuck at its "welcome" screen. And after switching to another VT and back, it disappears. 🤷🏻

After some googling and much trial and error I was able to make it work natively on wyaland (without xwayland in the way) by installing the cage package and changing the Exec line to something like Exec=/usr/bin/cage -ds -- env SDL_VIDEODRIVER=wayland /usr/games/bambam --in-dedicated-session

This works both on Debian 13 and in PopOS 24.04.

But the experience is suboptimal: specifically, while sounds play straight away after pressing a key, the pictures only appear with a lag of two keypresses, or once the mouse is moved. No idea whether this is due to bambam code doing something silly, or SDL/pygame not really being wayland-ready yet.