dunst CI: Add AppImage

This PR introduces the generation of an AppImage.

The produced appimage uses the static appimage runtime and bundles all the libraries and its own ld-musl.so, so it should work on any linux system from the last 15 years.

Also I'm creating some dummy icon and .desktop entry, it would be nice if dunst gets its official .desktop and icon.

~~Also while the AppImage that I produce from the last stable build works perfectly, I just tested the one produced here which is a git build and it does have some issues finding the icons? and also the notification window is bigger for some reason, not sure if this is a known issue or an issue that would only affect the appimage for recent builds?~~ UPDATE: Fixed

Nov 02 '24 15:11 Samueru-sama

Also while the AppImage that I produce from the last stable build works perfectly, I just tested the one produced here which is a git build and it does have some issues finding the icons? and also the notification window is bigger for some reason, not sure if this is a known issue or an issue that would only affect the appimage for recent builds?

Just quickly installed the dunst -git aur package to check, and yes I have the same issue with it, which I means I found a bug that I likely need to report if hasn't been already lol

Nov 02 '24 15:11 Samueru-sama

This PR introduces the generation of an AppImage.

Some context here

The produced appimage uses the static appimage runtime and bundles all the libraries and its own ld-musl.so, so it should work on any linux system from the last 15 years.

Also I'm creating some dummy icon and .desktop entry, it would be nice if dunst gets its official .desktop and icon.

Also while the AppImage that I produce from the last stable build works perfectly, I just tested the one produced here which is a git build and it does have some issues finding the icons? and also the notification window is bigger for some reason, not sure if this is a known issue or an issue that would only affect the appimage for recent builds?

The here link gives me a 404. Could you describe which issues are you getting with the new dunst? I assume only in the master branch?

Nov 02 '24 19:11 bynect

This PR introduces the generation of an AppImage. Some context here The produced appimage uses the static appimage runtime and bundles all the libraries and its own ld-musl.so, so it should work on any linux system from the last 15 years. Also I'm creating some dummy icon and .desktop entry, it would be nice if dunst gets its official .desktop and icon.

Also while the AppImage that I produce from the last stable build works perfectly, I just tested the one produced here which is a git build and it does have some issues finding the icons? and also the notification window is bigger for some reason, not sure if this is a known issue or an issue that would only affect the appimage for recent builds?

The here link gives me a 404. Could you describe which issues are you getting with the new dunst? I assume only in the master branch?

https://github.com/Samueru-sama/dunst/actions/runs/11643737551

scroll to the end and download the appimage.

And about the issue I ran into, I will open an issue in detail for it with screenshots and all of that later.

UPDATE:

Context for others, the issue was resolved here.

Nov 02 '24 19:11 Samueru-sama

@bebehei Are you sure I have bashism in the AppRun? The script passes all checks in shellcheck and I use dash as my /bin/sh.

Nov 10 '24 14:11 Samueru-sama

@Samueru-sama Yes, $() is now in default POSIX. But still I think "$@" is a bashism, because it copies ARGV exactly as the list from ARGV without doing word splitting etc but also not being converted to a concatenated string.

Nov 10 '24 14:11 bebehei

Ok, about "$@", even the POSIX section is totally contradictory:

When the expansion occurs within double-quotes, the behavior is unspecified unless one of the following is true:

Field splitting as described in Field Splitting would be performed if the expansion were not within double-quotes (regardless of whether field splitting would have any effect; for example, if IFS is null).

(text bold by me) To me, this makes no sense.

After all, let's just assume, this is no bashism.

Nov 10 '24 15:11 bebehei

:warning: Please install the 'codecov app svg image' to ensure uploads and comments are reliably processed by Codecov.

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 65.16%. Comparing base (9d3c91a) to head (c4c6305). Report is 7 commits behind head on master.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #1391      +/-   ##
==========================================
+ Coverage   65.11%   65.16%   +0.04%     
==========================================
  Files          50       50              
  Lines        8649     8649              
  Branches     1021     1021              
==========================================
+ Hits         5632     5636       +4     
+ Misses       3017     3013       -4

Flag	Coverage Δ
unittests	`65.16% <ø> (+0.04%)`	:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

Nov 10 '24 15:11 codecov-commenter

Fixed the AppRun because the new one wasn't working like it should. it is a bit confusing how it works so here is an explanation.

The AppImage runtime sets a few env variables, one of those is the env variable ARGV0 which is just $0, so if you rename or symlink the appimage to be dunstctl for example, you can use that to launch dunstctl or other binaries.

So I transfer that to a new variable called BIN and I unset ARGV0, the reason behind this is because ARGV0 is also used by zsh and can cause issues with zsh users, see here

So the first case statement checks if BIN matches dunst, dunstify or dunstctl and launches them, since dunstctl is a script and not an elf it has to be launched in a different matter without using the dynamic linker.

Then if none of this matches, there is a fallback to check the first argument if it matches dunst, dunstify or dunstctl again, if so we shift and continue as normal.

And if none of this happens the instructions are given and the appimage defaults to running dunst.

Nov 10 '24 15:11 Samueru-sama

Hello, I tried it and it seems to work well. I have only two notes:

Should this be run everytime or on releases?
Currently the name of the appimage is a generic 1.11.0-non-git. Maybe putting the precise commit for non releases is better?

Dec 03 '24 09:12 bynect

* Should this be run everytime or on releases?

Why not both?

* Currently the name of the appimage is a generic 1.11.0-non-git. Maybe putting the precise commit for non releases is better?

Not sure what to do in this case though, the 1.11.0-non-git is reported by dunst itself.

Dec 03 '24 19:12 Samueru-sama

Why not both?

sure enough 🤣

Not sure what to do in this case though, the 1.11.0-non-git is reported by dunst itself

The non git name is given as a fallback. the preferred version is obtained with git describe --tags which gives both the tag and a short coimmit hash.

You are getting the non-git version because apparently the container does not get a git folder.

Dec 03 '24 21:12 bynect

The non git name is given as a fallback. the preferred version is obtained with git describe --tags which gives both the tag and a short coimmit hash.

You are getting the non-git version because apparently the container does not get a git folder.

What should I do here? The version ends up being the VERSION variable, I think github sets a variable that has the commit tag and I guess I can assign VERSION to that.

Dec 03 '24 21:12 Samueru-sama

The non git name is given as a fallback. the preferred version is obtained with git describe --tags which gives both the tag and a short coimmit hash. You are getting the non-git version because apparently the container does not get a git folder.

What should I do here? The version ends up being the VERSION variable, I think github sets a variable that has the commit tag and I guess I can assign VERSION to that.

the fact is that just by changing the VERSION variable the actual version backed in dunst is not affected.

The correct way would be to have access to the git repository from the github action. but I am not expert on actions so I don't know how to do that.

Maybe you can adapt something from our workflow?

    steps:
      - uses: actions/checkout@v4
        with:
          # Clone the whole history including tags.
          fetch-depth: 0    # <<<<<

      - name: setup $HOME for git
        run: echo "HOME=${RUNNER_TEMP}" >> ${GITHUB_ENV}

      - name: configure safe directory for git
        run: git config --global --add safe.directory ${GITHUB_WORKSPACE}

      - name: build
        run: make -j all dunstify test/test

Dec 03 '24 22:12 bynect

@Samueru-sama do you think you can wrap this up when you have the time?

Apr 28 '25 21:04 bynect

@Samueru-sama do you think you can wrap this up when you have the time?

Sure but I'm not sure how to fix the VERSION issue

Apr 29 '25 03:04 Samueru-sama

@Samueru-sama do you think you can wrap this up when you have the time?

Sure but I'm not sure how to fix the VERSION issue

Is cloning the git repo in the workflow not working?

Apr 29 '25 07:04 bynect

@Samueru-sama do you think you can wrap this up when you have the time?

Sure but I'm not sure how to fix the VERSION issue

Is cloning the git repo in the workflow not working?

That sounds crazy, but if it fixes the issue then sure thing I can try that xd.

With that said it will take a while since I have a backlog on other projects, I also need to backport some "fixes" from the dunst-appimage repo like how I discovered that dunst dlopens the libnotify.so of the host and doesn't link to it directly, and what is crazy is that the dunst built with musl is able to dlopen the libnotify.so of the host even if it links againts glibc and this worked without issue somehow 🤯

Apr 30 '25 03:04 Samueru-sama

That sounds crazy, but if it fixes the issue then sure thing I can try that xd.

we already do it in the coverage workflow. it shouldnt be too bad https://github.com/dunst-project/dunst/blob/d0f8976162b46b97293317f36cec4f74fafc649c/.github/workflows/main.yml#L79

anyway don't feel pressured, do it when you can

Apr 30 '25 07:04 bynect