New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
x11-plugins/gkrellm-leds: update EAPI 6 -> 8 #24729
Conversation
f114b27
to
6bb4871
Compare
Pull Request assignmentSubmitter: @laumann x11-plugins/gkrellm-leds: @gentoo/proxy-maint (maintainer needed) Linked bugsBugs linked: 799176 In order to force reassignment and/or bug reference scan, please append Docs: Code of Conduct ● Copyright policy (expl.) ● Devmanual ● GitHub PRs ● Proxy-maint guide |
|
||
S="${WORKDIR}/${MY_P}" | ||
|
||
PATCHES=( "${FILESDIR}/${P}-r2-ldflags-typo.patch" ) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not entirely sure which variables I should use in reference to the patch. My understanding so far is that one should refrain from ${PF}
, but the PMS lists several others (including ${P}
here) that aren't "consistent".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's "not consistent" in the sense that "it might be different in e.g. pkg_postrm", but I need to check. Today has been quite long and not been really at computer much.
It's safe to use it in PATCHES (but don't use ${PF} for the reasons @ionenwks mentioned in #gentoo-dev earlier; we generally anticipate we can revbump packages en-masse without affecting their installability. Using ${PF} harms that).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Typically:
- Patch will likely keep across versions: ${PN}-0.0.0-name.patch (i.e. long standing issues, or Gentoo specific patches)
- Patch that should be either reviewed or dropped next version: ${P}-name.patch (i.e may be fixed / upstreamed, if not, can change to
${PN}
on bump -- Edit: I tend to prefer to use ${P} at first and change later like that, but depends)
And yeah, ${PF}
is just different given it includes revision making it too volatile over nothing. It shouldn't be thrown around casually and revbumps with no changes preferably shouldn't be able to break things, normally only used for docs dir.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, seems like I was right to change ${PF}
to ${P}
here. I included -r2
in the patch name, because I wanted to reflect that it's been created for that revision. But it should probably also apply to any potential future revisions of this version.
Thanks for the input!
Pull request CI reportReport generated at: 2022-03-23 19:21 UTC There are existing issues already. Please look into the report to make sure none of them affect the packages in question: |
6bb4871
to
ddd5b54
Compare
@thesamesam ping on this one. I pushed some minor edits to the ebuild. |
Pull request CI reportReport generated at: 2022-03-27 21:48 UTC There are existing issues already. Please look into the report to make sure none of them affect the packages in question: |
1e999d7
to
f42bc87
Compare
Pull request CI reportReport generated at: 2022-04-05 07:42 UTC There are existing issues already. Please look into the report to make sure none of them affect the packages in question: |
Pull request CI reportReport generated at: 2022-04-05 07:57 UTC There are existing issues already. Please look into the report to make sure none of them affect the packages in question: |
|
||
## linker flags, we are building a plugin so skip lib prefix and lib versions | ||
-gkleds_la_LDFLAGS = -module -avoid-version @GK_LDFLAGS@ | ||
+gkleds_la_LDFLAGS = -module -avoid-version @GKM_LDFLAGS@ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
in general, in variables you shouldn't reference @VAR@
but $(VAR)
because AC_SUBST
already creates a separate VAR = @VAR@
somewhere in Makefile.in
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, I wanted to go for the smallest change that would fix the problem. Do you want me make this change?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
no, it's just something to be aware of if you're fixing build systems
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Alright, thanks! 😄 I appreciate it.
} | ||
|
||
src_configure() { | ||
PLUGIN_SO=( src/.libs/gkleds$(get_modname) ) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is this really needed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should be the name of the plugin's .so file. The default is ${PN}$(get_modname)
, so I think it's needed, yes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FWIW, referencing .libs/ tends to break with slibtool
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What's the solution to that? Move the file after it's been built?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we actually need to set it at all in configure? Can't we just set it to the right name on install?
Besides the EAPI bump, there's a bug for the referenced bug. The issue seems to be simply a typo in src/Makefile.am resulting in a variable @GK_LDFLAGS@ not being replaced appropriately. Closes: https://bugs.gentoo.org/799176 Signed-off-by: Thomas Bracht Laumann Jespersen <t@laumann.xyz>
f42bc87
to
e9b8c3f
Compare
Pull request CI reportReport generated at: 2022-04-05 19:57 UTC There are existing issues already. Please look into the report to make sure none of them affect the packages in question: |
Besides the EAPI bump, there's a bug for the referenced bug. The issue
seems to be simply a typo in src/Makefile.am resulting in a variable
@GK_LDFLAGS@ not being replaced appropriately.
Closes: https://bugs.gentoo.org/799176
Signed-off-by: Thomas Bracht Laumann Jespersen t@laumann.xyz
TODO
ebuild install
-r1 and -r2 and compare the image folders