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
dev-util/radare2: verbump to 5.5.4 #23184
Conversation
Pull Request assignmentSubmitter: @stkw0 dev-util/radare2: @stkw0, @gentoo/proxy-maint Linked bugsBugs linked: 790284, 807061, 815046 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 |
Pull request CI reportReport generated at: 2021-12-05 00:22 UTC There are existing issues already. Please look into the report to make sure none of them affect the packages in question: |
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.
* QA Notice: Symbolic link /usr/lib64/radare2/last points to /usr/lib64/radare2/5.5.0 which does not exist.
Huh?
# file /usr/lib64/radare2/last
/usr/lib64/radare2/last: broken symbolic link to 5.5.0
* VDB: detected possibly incorrect RDEPEND (dev-util/radare2-5.5.0)
* dev-libs/libzip | dev-libs/libzip:=
tbh I don't know why radare2 creates /usr/lib64/radare2 folder when it doesn't put anything there, but at least with the current ebuild I don't see that symlink issue. |
Pull request CI reportReport generated at: 2021-12-22 15:02 UTC There are existing issues already. Please look into the report to make sure none of them affect the packages in question: |
Doesn't seem like the test phase is working properly?
I'm not sure how much radare2 and rizin have diverged at this point, but some prefix mangling inside tests might be necessary, you might be able to adapt some patches from dev-util/rizin. Note that I've also disabled tests in Rizin due to ambiguous licensing on the binaries they distribute, so would probably be necessary to do that here too. |
If we recompile those binaries then it won't be a problem right? Although I guess we will have to search all different licenses of all the sources and add those to LICENSE |
Correct, and there's so many that I've not done this yet |
thanks. For now I will just do as you and disable tests, when I do the work of searching for the difference licenses and so I will enable it again. |
Pull request CI reportReport generated at: 2022-01-03 17:17 UTC There are existing issues already. Please look into the report to make sure none of them affect the packages in question: |
# Copyright 1999-2022 Gentoo Authors | ||
# Distributed under the terms of the GNU General Public License v2 | ||
|
||
EAPI=7 |
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.
EAPI=8?
IUSE="ssl" | ||
|
||
# Need to audit licenses of the binaries used for testing | ||
RESTRICT="test" |
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.
Are you able to get tests working locally? This situation is obviously not ideal, but ensuring tests work for at least yourself would be great.
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.
Well, kind of, it works if I first emerge emerge radare2 and then I execute the tests. I don't know if it's possible to do an src_install before src_test is executed so all needed libs and binaries and in the correct paths, changing the path to include all stuff seems very ugly.
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 don't know if it's possible to do an src_install before src_test is executed so all needed libs and binaries and in the correct paths, changing the path to include all stuff seems very ugly.
Yes, you can use the "${BUILD_DIR}" most likely for that. It's somewhat commonly used, the python eclasses even has built-in helpers for that.
Other than these minor nits, lgtm |
Closes: https://bugs.gentoo.org/815046 Bug: https://bugs.gentoo.org/790284 Bug: https://bugs.gentoo.org/807061 Package-Manager: Portage-3.0.28, Repoman-3.0.3 Signed-off-by: David Roman <davidroman96@gmail.com>
Pull request CI reportReport generated at: 2022-01-05 02:32 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-01-05 02:47 UTC There are existing issues already. Please look into the report to make sure none of them affect the packages in question: |
Closes: https://bugs.gentoo.org/815046
Bug: https://bugs.gentoo.org/790284
Bug: https://bugs.gentoo.org/807061
Package-Manager: Portage-3.0.28, Repoman-3.0.3
Signed-off-by: David Roman davidroman96@gmail.com