fix(x11/cinnamon): use desktopappinfo from giounix not gio

[sabamdarif]

close #26742

[robertkirkman]

@sabamdarif If you cherry-pick this PR, does it work as an alternative solution?

• Prepare for GLib 2.86.0 typelib break linuxmint/cinnamon#13091

[robertkirkman]

Another X11 GUI affected by an extremely similar problem is awesome. I am planning to fix it here:

• bump(x11/awesome): 2025.05.17 #26693

[sabamdarif]

@sabamdarif If you cherry-pick this PR, does it work as an alternative solution?

* [Prepare for GLib 2.86.0 typelib break linuxmint/cinnamon#13091](https://github.com/linuxmint/cinnamon/pull/13091)

i will try

[sabamdarif]

yes @robertkirkman it did work, i understand now that is the real issue thanks

[robertkirkman]

very good, and should it be called "from" or "form"? I thought it should be "from"

[sabamdarif]

o yes wait

[sabamdarif]

very good, and should it be called "from" or "form"? I thought it should be "from"

from

[robertkirkman]

In order to pass the CI it will need to have TERMUX_PKG_REVISION increased by 1 in the build.sh

[TomJo2000]

That should have already been caught by the linter.

termux-packages/scripts/lint-packages.sh

Lines 124 to 142 in b982d53

	# Check the latest commit that modified `$package`
	# It must either:
	# - Modify TERMUX_PKG_REVISION
	# - Modify TERMUX_PKG_VERSION
	# - Or specify one of the CI skip tags
	check_version_change() {
	local base_commit commit_diff package="$1"
	base_commit="$(git merge-base 'master@{upstream}' 'HEAD')"
	commit_diff="$(git log --patch "${base_commit}.." -- "$package")"
	# If the diff is empty there's no commit modifying that package on this branch, which is a PASS.
	[[ -z "$commit_diff" ]] && return
	grep -q \
	-e '^+TERMUX_PKG_REVISION=' \
	-e '^+TERMUX_PKG_VERSION=' \
	-e '\[no version check\]' <<< "$commit_diff" \
	|| return 1
	}

Why wasn't it...

[sabamdarif]

In order to pass the CI it will need to have TERMUX_PKG_REVISION increased by 1 in the build.sh

oh yes i forgot about that

[robertkirkman]

@TomJo2000 I don't fully understand how the linter works, but just looking at the part you highlighted, where does the {upstream} keyword "come from" there and how does the linter know what "upstream" is in that context?

~/code/termux-packages $ cat scripts/lint-packages.sh | grep upstream
        base_commit="$(git merge-base 'master@{upstream}' 'HEAD')"
~/code/termux-packages $

[TomJo2000]

@TomJo2000 I don't fully understand how the linter works, but just looking at the part you highlighted, where does the {upstream} keyword "come from" there and how does the linter know what "upstream" is in that context?

That's some git-rev syntax¹.

Footnotes

1. https://man.archlinux.org/man/git-rev-parse.1#SPECIFYING_REVISIONS:~:text=%5B%3Cbranchname%3E%5D%40%7Bupstream%7D%2C%20e.g.%20master%40%7Bupstream%7D%2C%20%40%7Bu%7D ↩

[robertkirkman]

@TomJo2000 ok that's great but it doesn't work on my computer (a Termux right now) when I try to test it. How is it meant to work in CI, do I have it set up wrong? Also, can this condition detect a problem if build.sh of the package is not edited (only .patch files edited) in the PR?

[TomJo2000]

It's supposed to make a diff of the entire branch using git log --patch "${base_commit}.." -- "$package" to look for changes to the package.

$package is $1 of check_version_change...
Which is $package_script, the iterator variable over $@ of linter_main...
And linter_main gets called build.sh locations for all packages that are being linted.
So it should actually be looking at the package directory instead, good catch.

[robertkirkman]

If you can see my screenshot, do you see as well how my Test.log is empty? it seems like it shouldn't be so that is why i focused on that part first, do you know why that could be? I am concerned a similar problem could be happening in CI.

[TomJo2000]

If you can see my screenshot, do you see as well how my Test.log is empty? it seems like it shouldn't be so that is why i focused on that part first, do you know why that could be? I am concerned a similar problem could be happening in CI.

I'm guessing there's no branch.<name>.merge set up for the branch.
Can you check the branch entry for that branch in the .git/config of the repo?

[robertkirkman]

~/code/termux-packages $ cat .git/config
[core]
        repositoryformatversion = 0
        filemode = true
        bare = false
        logallrefupdates = true
[remote "origin"]
        url = https://github.com/sabamdarif/termux-packages
        fetch = +refs/heads/*:refs/remotes/origin/*
[branch "fix-26742"]
        remote = origin
        merge = refs/heads/fix-26742
~/code/termux-packages $

Maybe the CI doesn't have the correct information configured in git at this point either, but I don't know for sure.

[TomJo2000]

I'll throw a cat of the .git/config in there for debugging.

[robertkirkman]

very good, and should it be called "from" or "form"? I thought it should be "from"

from

could you edit the commit to change that?

[sabamdarif]

could you edit the commit to change that?

ok

[robertkirkman]

To me it looks like when you try to change that, it doesn't change anything, maybe the way you are trying to change it isn't working?

[sabamdarif]

i added it in both of this palaces, where did you mean ?

[sabamdarif]

i use git commit --amend

[robertkirkman]

Oh, when I asked you did you mean "form" or "from" I meant, about this "form":

did you mean this to be "form" or "from"?

[sabamdarif]

oh my bad i understand it wrong , wait

[robertkirkman]

Ok wonderful, now it's ready! I will merge it in 24 hours and I guess I will also merge my similar glib 2.86 compatibility PR for awesome in 24 hours.