The package games-emulation/jgrf depends on media-libs/libepoxy[egl]. The latter, in its latest iteration, forces egl to be on, and removes the USE flag. Thus, the games-emulation/jgrf ebuilds need to be altered to accommodate this. Proposed patches to fix the two ebuilds currently in the tree will be added as attachments in following posts.
Created attachment 891857 [details, diff] Update jgrf-9999 to work with libepoxy USE flag removal
Created attachment 891858 [details, diff] Update jgrf-1.0.2-r1 to work with libepoxy USE flag removal
(In reply to Travis Snoozy from comment #0) > The package games-emulation/jgrf depends on media-libs/libepoxy[egl]. The > latter, in its latest iteration, forces egl to be on, and removes the USE > flag. Thus, the games-emulation/jgrf ebuilds need to be altered to > accommodate this. > > Proposed patches to fix the two ebuilds currently in the tree will be added > as attachments in following posts. hi I made the same mistake as you for Bug 930404 in fact just replace || ( media-libs/libepoxy[egl] >=media-libs/libepoxy-1.5.10-r3 ) by media-libs/libepoxy[egl(+)] see https://devmanual.gentoo.org/eclass-reference/ebuild/ Atom USE defaults Beginning with EAPI 4, USE dependencies may specify default assumptions about values for flags that may or may not be missing from the IUSE of the matched package. Such defaults are specified by immediately following a flag with either (+) or (-). Use (+) to behave as if a missing flag is present and enabled, or (-) to behave as if it is present and disabled
I fixed this in PR https://github.com/gentoo/gentoo/pull/35976. However Gentoo is currently blocking me from maintaining my ebuilds so no idea when it will be merged. Last time I asked about my open PRs in IRC I was accused of "guilt tripping" the Gentoo devs...
(In reply to orbea from comment #4) > I fixed this in PR https://github.com/gentoo/gentoo/pull/35976. > > However Gentoo is currently blocking me from maintaining my ebuilds so no > idea when it will be merged. Last time I asked about my open PRs in IRC I > was accused of "guilt tripping" the Gentoo devs... Nobody is blocking you from maintaining your ebuilds. I said that we can't promise to merge *new* packages and that it's guilt tripping to say we should merge new packages because upstream put effort into Gentoo.
I would prefer if you didn't try to gaslight me. From #gentoo-proxy-maint: 2024-04-09 06:47:10 orbea can someone please help out with reviewing my PRs? They are starting to add up, one has been open since January... https://github.com/gentoo/gentoo/pulls/orbea 2024-04-09 06:50:15 @sam_ the january one is a new package 2024-04-09 06:50:25 @sam_ new packages are basically done as favours unless something really needs it 2024-04-09 06:50:34 @sam_ they're not prioritised or considered in the queue at all 2024-04-09 06:50:39 @sam_ see the text in https://github.com/gentoo/gentoo/pull/35028#issuecomment-1912481407 2024-04-09 06:56:02 orbea upstream was very accomodating in order to get it into Gentoo.... 2024-04-09 06:56:51 @sam_ do you see how that's just guilt tripping a bit though? 2024-04-09 06:56:54 @sam_ like i never agreed to add it 2024-04-09 06:56:58 @sam_ i'm not even saying i won't 2024-04-09 06:57:01 negril then put it into ::guru? 2024-04-09 06:57:33 orbea guilt tripping.....that is a really rude way to put it The basic fact remains is that my self-maintained PRs remain blocked regardless if they are for new packages or not. This is extremely demotivating, discouraging and depressing. How long am I supposed to wait until I can maintain my ebuilds? You once accused me being abusive when I asked you to help merge some PRs, but if I am to be bluntly honest you are the one that is being abusive.
That log feels consistent with what I said above, I don't see how there's any gaslighting. I don't remember calling you abusive, I do remember saying I was overwhelmed and you were pinging a lot. Anyway, if you feel that way, I don't think any sort of relationship is salvageable unfortunately.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=b5d0712964b8c620087638ae5c9b7b24e998e4da commit b5d0712964b8c620087638ae5c9b7b24e998e4da Author: orbea <orbea@riseup.net> AuthorDate: 2024-04-27 21:26:07 +0000 Commit: Joonas Niilola <juippis@gentoo.org> CommitDate: 2024-04-29 08:45:18 +0000 games-emulation/jgrf: fix media-libs/libepoxy depend Closes: https://bugs.gentoo.org/930792 Signed-off-by: orbea <orbea@riseup.net> Signed-off-by: Joonas Niilola <juippis@gentoo.org> games-emulation/jgrf/jgrf-1.0.2-r1.ebuild | 2 +- games-emulation/jgrf/jgrf-9999.ebuild | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)
It is gaslighting because the core problem that is not at all limited to me is that its impossible to effectively maintain ebuilds or fix issues for projects like slibtool when every new set of changes takes weeks to months to be accepted usually only after complaining several times. Yet I am supposed to think that maintainers are not being essentially blocked? This includes new ebuilds like RMG where merging it is NOT a favor to me, but a favor to any Gentoo user who wants to emulate the Nintendo 64 on Gentoo. Even if it was a favor to me is that undeserved after 100s of commits to the Gentoo infrastructure and fixing countless bugs in Gentoo and upstream projects that Gentoo uses? By all means if there are technical reasons I am all ears, but implying I need to be deserving of favors is not such and an incredibly inconsiderate of the amount of the time I am starting to believe was wasted on Gentoo. I am thankful to juippis for merging the JGEMU PR, but what I am supposed to do about my other PRs? > I don't remember calling you abusive, I do remember saying I was overwhelmed and you were pinging a lot. 2023-09-17 05:23:29 @orbea sam_: cant you just add me as the eudev maintainer to avoid it being removed? I really don't appreciate how you guys are removing non-systemd code one piece at a time...if I have to maintain a eudev overlay Im not going to have time for slibtool anymore... 2023-09-17 05:23:55 @orbea and i dont have energy to argue with a bunch of assholes on the ML 2023-09-17 17:41:48 @sam_ calling people assholes isn't helpful 2023-09-17 17:41:51 @sam_ "you guys" 2023-09-17 17:42:01 @sam_ eudev already is systemd code, it's just rotten, and adding a bunch of stubs isn't useful 2023-09-17 17:42:10 @sam_ i'm not interested in receiving even more abuse 2023-09-17 17:42:14 <-- sam_ (~sam@000228b9.user.oftc.net) has left #slibtool 2023-09-17 18:16:55 @orbea how rude... In retrospect I could of better expressed my frustration with some very bad faith arguments on the ML by a few individuals (Not by you) where most were not even directed at me. That said I have a good friend who still can't use systemd udev because it bricks their arm systems with no errors and I am still banned on the systemd github project because years ago I dared to talk back to Poettering about a CVE issue he deemed not a bug. (We were both wrong, it was a bug in a dependency of systemd)
(In reply to orbea from comment #9) > It is gaslighting because the core problem that is not at all limited to me > is that its impossible to effectively maintain ebuilds or fix issues for > projects like slibtool when every new set of changes takes weeks to months > to be accepted usually only after complaining several times. Yet I am > supposed to think that maintainers are not being essentially blocked? > I don't know how to respond to this bit. I don't really think proxy-maint is in a healthy state, I think we need way more people doing reviews, and I think we could do better at reviewing too to avoid too many round-trips. > This includes new ebuilds like RMG where merging it is NOT a favor to me, > but a favor to any Gentoo user who wants to emulate the Nintendo 64 on > Gentoo. No, but it's about how it's more work for proxy-maint, which includes me, it's also frustrating for users if they can get something better maintained from an overlay too. > Even if it was a favor to me is that undeserved after 100s of > commits to the Gentoo infrastructure and fixing countless bugs in Gentoo and > upstream projects that Gentoo uses? By all means if there are technical > reasons I am all ears, but implying I need to be deserving of favors is not > such and an incredibly inconsiderate of the amount of the time I am starting > to believe was wasted on Gentoo. We have rules on adding new packages, and I've tended to be lenient in applying them to you. So, when faced with the choice of "do I spend time merging current package PRs (inc. orbea's)" vs "adding more packages -> even more current package PRs to review", I preferred the former in this case. > > I am thankful to juippis for merging the JGEMU PR, but what I am supposed to > do about my other PRs? > > > I don't remember calling you abusive, I do remember saying I was overwhelmed and you were pinging a lot. > > 2023-09-17 05:23:29 @orbea sam_: cant you just add me as the eudev > maintainer to avoid it being removed? I really don't appreciate how you guys > are removing non-systemd code one piece at a time...if I have to maintain a > eudev overlay Im not going to have time for slibtool anymore... > 2023-09-17 05:23:55 @orbea and i dont have energy to argue with a bunch > of assholes on the ML > 2023-09-17 17:41:48 @sam_ calling people assholes isn't helpful > 2023-09-17 17:41:51 @sam_ "you guys" > 2023-09-17 17:42:01 @sam_ eudev already is systemd code, it's just > rotten, and adding a bunch of stubs isn't useful > 2023-09-17 17:42:10 @sam_ i'm not interested in receiving even more > abuse > 2023-09-17 17:42:14 <-- sam_ (~sam@000228b9.user.oftc.net) has left > #slibtool > 2023-09-17 18:16:55 @orbea how rude... > That's not calling you abusive, that's saying I felt your remark was over the line because I was being accused of "removing non-systemd code one piece at a time". But yes, I was a bit frustrated, and I could've used better phrasing :(
(In reply to Sam James from comment #10) > > No, but it's about how it's more work for proxy-maint, which includes me, > it's also frustrating for users if they can get something better maintained > from an overlay too. > + frustrating for you / any other proxied maints who then have to wait longer if we're already not coping with the current load...
