Since the new maintainer has stepped in to substitute the previous one, I've been having issues even building the package, failing immediately upon the build process attempts to patch the source-code. I do not believe, however, that it would work regardless, since the maintainer has deleted the compile and install phases from the ebuild *entirely*. I wish not to attribute this to misbehavior from the maintainer, but this is extremely inconvenient, since that, for the following reason, this package tries to install the latest 9999 version as per recommendation of the project itself (hyprland), and therefore I'm not particularly inclined to mask this version. Reproducible: Always Steps to Reproduce: 1. doas emerge xdg-desktop-portal-hyprland / updating Actual Results: Errors out in the prepare phase attempting to patch the source Expected Results: The ebuild should've patch and compile and then install the software correctly as it did before.
Created attachment 882149 [details] Information, as per required
I'm confused by what "defaults to 9999" means. It doesn't look keyworded?
Sam probably he is using the latest 9999 because of the recommendation of Hyprland. Guilherme Matos 9999 version are updated most of the time when a new stable release apear so it normal for some times 9999 be broken, also guru ci dosen't test 9999 version to my knowledge (Sam, pls correct me if I wrong). Second pls dont blame people the 9999 ebuild dosen't exist I just created one it can be broken because of upstream change that I don't notice, since I dont update Hyprland evertime it receive a new commit and I dont recommend anyone using 9999, varxy sometimes commit things should be commited will are all humans. Now I notice the problem is a patch that is outdated use 1.3.1 for until a new release of xdg-desktop-portal-hyprland drops (latest release is only 2 weeaks old, 9999 should be used if you have a problem with the stable release).
Yeah, the CI doesn't check it at all (it's checked with `pkgcheck`, but ago doesn't try to build any of it etc (which is fine/expected)). I am not sure what OP refers to wrt compile/install, as it's normal to not need to define src_compile and src_install if the default/exported eclass implementations work. It's very common for live ebuilds to stop working when patches stop applying. It's part of why relying on them is a pain ;)
Ok it broken because of one line change :)
The latest commit hours after the release 1.3.1: https://github.com/hyprwm/xdg-desktop-portal-hyprland/commit/6a5de92769d5b7038134044053f90e7458f6a197
Created attachment 882539 [details, diff] xdg-desktop-portal-hyprland-9999_use_sys_sdbus-c++.patch Sam I don't know if I push this or wait but well this should fix it
Looks good to me!
Ok gonna push it, also test in my machine and is working
fix: https://gitweb.gentoo.org/repo/proj/guru.git/commit/?h=dev&id=0173d5106ad7899cd18b70bd21487b6e375d01e3
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/proj/guru.git/commit/?id=0173d5106ad7899cd18b70bd21487b6e375d01e3 commit 0173d5106ad7899cd18b70bd21487b6e375d01e3 Author: Gonçalo Negrier Duarte <gonegrier.duarte@gmail.com> AuthorDate: 2024-01-18 18:08:10 +0000 Commit: Gonçalo Negrier Duarte <gonegrier.duarte@gmail.com> CommitDate: 2024-01-18 18:10:10 +0000 gui-libs/xdg-desktop-portal-hyprland:fix 9999 stbus-c++ patch * upstream commit: https://github.com/hyprwm/xdg-desktop-portal-hyprland/commit/6a5de92769d5b7038134044053f90e7458f6a197 Closes: https://bugs.gentoo.org/921969 Signed-off-by: Gonçalo Negrier Duarte <gonegrier.duarte@gmail.com> ...op-portal-hyprland-9999_use_sys_sdbus-c++.patch | 32 ++++++++++++++++++++++ .../xdg-desktop-portal-hyprland-9999.ebuild | 2 +- 2 files changed, 33 insertions(+), 1 deletion(-)
Have you thought about just dropping the patch entirely? It's purpose was moot after https://github.com/hyprwm/xdg-desktop-portal-hyprland/commit/f46cff1df2d83b826193665091b843cb7776d20c was added. The less patches in 9999 the better.
Don't remove these patches or the ebuild will be broken for openrc users due to something with elogind as in https://bugs.gentoo.org/917678
It would be useful to include that context in the patches header. So the pc file for sdbus-c++ is broken (or elogind isnt installing its pc file) and should be fixed in sdbus-c++.
(In reply to Alfred Wingate from comment #14) > It would be useful to include that context in the patches header. > > So the pc file for sdbus-c++ is broken (or elogind isnt installing its pc > file) and should be fixed in sdbus-c++. Yes, ALWAYS include: a) what the patch does; b) why it's needed; c) any relevant references like bugs / PRs / ... at the top of the patch.
> Yes, ALWAYS include: > a) what the patch does; > b) why it's needed; > c) any relevant references like bugs / PRs / ... > at the top of the patch. I will do that from now on, sorry!
Thanks! :)
