-
Notifications
You must be signed in to change notification settings - Fork 7
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
EAPI=8 support #32
Comments
Does anyone know how to properly set up a cross compiling environment? Do I just extract a CBUILD stage3 somewhere and point BROOT to it? |
You cannot do this with paludis (yet, until somebody implements it in a proper way).
In the bad old days, This issue report is about |
You might want to reread the question again. ;) I know it is not implemented, but the |
Ah, in that case, yes, I think that should do the trick. It's just that In other news, I've started implementing EAPI 8 stuff, privately for now. Will update the original post accordingly by ticking off items that are done. I'm lazy on test cases, though, so any work publishing will probably be slow, since new features are useless without proper test cases. More to come. |
Did you base your work on the current master from exherbo? There are some fixes in there that would be nice to have. Especially in regards to cmake and python. |
Yep. I've always rebased the EAPI 7 stuff against exherbo's master for my personal use for the past few years. Same thing now, especially in order to fix the python 3.9 breakage. I'd like to uplift this repo, too. But I'm not quite done yet. :) |
Take a look at my fork, I've just rebased against exherbo's master for fun. Don't expect EAPI 8 changes just yet, I haven't put them in there yet. That was the uplifting I've been talking about. Hopefully I didn't mess it up somewhere. |
I've pushed my changes to the feature/eapi8 branch, but do not try to use any of this until it's fully done. I've also added a warning to However, for those curious, take a look. |
@Ionic |
As an update on this issue, my current branch (see above) now contains a feature-complete EAPI=8 implementation (with the usual caveat on It's missing a lot of test cases for the new features, though, so it's not prime-time or merge ready. I'm confident enough to use it on my own system and update my packages with it, but will have to add test cases for each new feature to make sure that it really works correctly. At the very least, I know that the already existing tests don't fail, so I haven't introduced regressions / EAPI=7 and lower ebuilds should continue to work as they always have. |
I've installed your branch (without Python support) is my system & managed to update quite a lot of EAPI8 packages in automatic fashion. Almost everything went fine. Your work is impressive & definitely useful. |
We really need EAPI=8 support badly, but I need to add test cases for the new things I implemented. I'll keep working on that. I'm pretty sure that everything on my branch should work correctly, but making sure that it does doesn't hurt. I've only seen a few issues with specific ebuilds, some of which are general ones going down to EAPI=0 (for instance #40). Others, like |
(As usual, please let me know if there's something on the Gentoo side that you need, be it fixed ebuilds, or something else.) |
Not immediately, I really have to look it up first. :) The dolphin ebuild utilizes a somewhat global variable in Then, there was |
The test cases should now be more or less complete and under Tests ERepository7:
ERepository8:
depend_idepend (missing execute permissions on |
Thank you very much! I'll cherry-pick some of your changes and apply them to my A few observations:
Again, thank you, I'll get working on hooking that up. |
The switch to C++17 isn't really necessary per se, but I'd really prefer refactoring
The reason the environments differ is because I commented out variable definitions that are never used in the C++ tests.
edit: talked to heirecka in #paludis on LibraIRC, he didn't see a particular reason not to raise it, so I will a c++-version detection and add an old implementation as well. |
Don't add old implementations, I'm already doing that and fixing what I can find. If they switch to requiring C++17, we can just apply your changes. |
That seems to be fine. PMS defines banned commands as this:
It doesn't say that the commands must not be defined. Providing a wrapper which aborts the build process, which is what we do, is absolutely aligned with the spec. |
Do you want me to change the tests? |
No, don't worry. I'm currently doing that, fixing tests that are wonky and improving them. I'll just need a few more days to get it all done. :) |
@Ionic there are 3 more commits in https://github.com/negril/paludis/commits/wip/feature/tests after the one you cherry picked from. Some of the cleanups in there you haven't done yet. And the restriction tests actually work now. |
Oh, right, I just pushed my changes yesterday in a hurry. Didn't even test them yet. I'll get the other changes, too... and actually test them. Note that the restriction label override test shouldn't have worked, so there's something wonky with it. The first label in there is "file+", which shouldn't be a recognized one... and actually cause the test to fail. |
I think that I have applied all your changes now, with a few exceptions:
I'll try to rework the override labels tests again tomorrow, since something is definitely wonky if they succeed when they shouldn't. Additionally, this stuff is so complicated that we actually want to also make sure that the whole testing matrix works and we're missing a few cases. After that's done, I'll actually try to build all of this stuff and see how it goes. |
In |
Thanks for the explanation, but that's not what I meant. Your current code has a typo where one of the files is prefixed with At least in theory. Practically, I guess that the distfile was just discarded since Edit: besides the failure due to the typo, it should have failed anyway, since the non-prefixed distfile I'll debug this and find out what's wrong. My initial suspicion is that this happens due to distfile caching in distdir. |
Okay, with the modified test suite, I'm seeing the following failures:
I'll continue working on this soon. |
I had implemented From the PMS:
Hence BASH_COMPAT is the minimum bash version required and the reason I used ver_test for the test case. If you want to check if the option is set correctly we would have to test |
I've fixed a few things, mostly in the EAPI=7 range, but not everything yet. Thanks for the Other than that, I added The Tomorrow I'd like to work on some low-hanging fruits like the |
@Ionic don't put to much work into fixing the selector test fails. They work fine ( minus the still matching empty sets ) with the reworked test environment. |
The issue with the selectors test has merely been Most of the new selectors tests I've written now work correctly, but we certainly have an issue, since I never implemented the new "empty OR/XOR group" behavior that is now required with EAPI=8, so these failures are totally sane and helping us out a lot. I've been fixing a lot of issues in the past few days (also for EAPI=8, although I haven't force-pushed this branch yet, since I've had to rebase often anyway due to the EAPI=7 changes), most implemented things now work correctly. I'm still debugging the Other than that, your test cases have been immensely helpful, especially for EAPI=7. I didn't even realize that there are things we haven't implemented correctly or at all yet. |
The Other than that, the good news is that all The following
Thus, the only failing tests are due to unimplemented functionality, and, especially, only in |
I've since implemented (for EAPI=7+):
Afterwards, I noticed that we don't have proper That alone isn't a big deal, since Paludis has proper support for this internally, but incremental profile variables are, so far, not exported back to the ebuild environment. Instead, Additionally, the code that cleans up the environment with a fixed list of variables that are supposed to be unset, which should be extended by While I can easily refactor this to clean up variables in More to come. |
Luckily, my analysis wasn't quite right. While there are a few variables which are not correctly exported, most of them seem to be, namely However, other variables (which I've looked up first), are missing from this special handling, namely Implementing
|
I've implemented the empty group changes. I'll upload them tomorrow. The cross build changes aren't that hard, but we need to decide how we want to configure that. AFAIK portage just uses just BROOT and decides from that. But I think we might be able to solve it via installed repositories. e: exherbo has a cross branch we might look at that as well. |
Changes are at Ionic#1. |
While testing I ran into the realisation that we wrongly assume that the top node of a dependency is a all-of group. We'll need a new root element and implement it everywhere. I'll report back when I'm done. |
Thanks a lot for that! I'll look into it at a later time.
Isn't that okay? I mean, the root being an all-of group is fine, since setups such as I got a bit side-tracked by something I read in PMS, namely:
A setup such as === parent ===
ARCH="cheese"
USERLAND="GNU"
LINGUAS="enabled_en enabled_en_GB enabled_en_GB@UTF-8"
WEIRDVAR="water ski"
OTHERVAR="banana ray"
USE_EXPAND="LINGUAS USERLAND WEIRDVAR"
USE_EXPAND_UNPREFIXED="ARCH"
USE_EXPAND_IMPLICIT="USERLAND ARCH"
USE_EXPAND_VALUES_USERLAND="GNU"
IUSE_IMPLICIT="build" === child ===
USE_EXPAND_UNPREFIXED='OTHERVAR'
USE_EXPAND='-WEIRDVAR'
WEIRDVAR='sand storm'
OTHERVAR='death' leads to some interesting setup in declare -x USE_EXPAND="LINGUAS USERLAND"
declare -x USE_EXPAND_HIDDEN=""
declare -x USE_EXPAND_IMPLICIT="USERLAND ARCH"
declare -x USE_EXPAND_UNPREFIXED="OTHERVAR"
declare -x USE_EXPAND_VALUES_ARCH="cheese otherarch"
declare -x USE_EXPAND_VALUES_USERLAND="GNU"
declare -x USE_EXPAND="LINGUAS USERLAND"
declare -x IUSE_IMPLICIT="build"
declare -x USE_EXPAND_IMPLICIT="USERLAND ARCH"
declare -x USE_EXPAND_UNPREFIXED="OTHERVAR"
declare -x IUSE_EFFECTIVE="build cheese otherarch userland_GNU"
declare -x ARCH="cheese"
declare -x WEIRDVAR="sand storm"
declare -x OTHERVAR="death" This seems to be wrong for multiple reasons. First, since Secondly, I may misunderstand PMS again, but
which, to me, means, that any variables that are part of I'll check how portage behaves to have a baseline comparison. Edit: portage does this:
That seems to be in line with the PMS specification (at least when it comes to reducing the content of variables), so, meh, paludis really does not seem to calculate this correctly. Which is quite surprising, given that Ciaran wrote the PMS section. But, even though that's more in line with PMS, modyfing child_profile by adding
Here, So either I misunderstood something or both PMs behave weirdly. I'll probably ask for help at a later time, but also likely won't be able to continue working on it this before the start of March. |
Initially I misread the truth table for The assumption that it's an all-of group is still weird to me because we treat it differently at least in the By now I've fixed the empty group changes and pushed them have a look at that please because I might have went overboard with the test case. :) In other news, we need to have a look at the resolver. For me removing |
There's no guarantee that ${DISTDIR} only contains the distfiles for this package (it could be the system's whole cache, for example -- like in Paludis). Bug: MageSlayer/paludis-gentoo-patches#32 (comment) Thanks-to: Ionen Wolkens <[email protected]> Signed-off-by: Sam James <[email protected]>
Linking the While it isn't prime-time-ready yet, it includes most features and will be "stable" (as in: no rebases, not bug free or feature complete) going forward, unlike the |
Every few years, paludis breaks.
This is one of those times.
EAPI 8 has been released and is getting used now, which means that paludis will just silently ignore those ebuilds.
As usual, mgorny released an ultimate guide to EAPI 8.
The changes look mostly managable, although the
IDEPEND
feature needs invasive work similar to theBDEPEND
feature (and even that one was never properly implemented to take cross compiling into account, rather merged with normal dependencies).Checklist:
--datarootdir
automatically passed byeconf
--disable-static
automatically passed byeconf
doconfd
not influenced byinsopts
doenvd
not influenced byinsopts
doheader
not influenced byinsopts
doinitd
not influenced byexeopts
dosym -r
for relative symlinksfetch+
notation inSRC_URI
to override fetch restrictionmirror+
notation inSRC_URI
to override mirror restrictionhasq
bannedhasv
banneduseq
bannedIDEPEND
as host-based-only post-install-time dependency variable, mimicking whatBDEPEND
is forDEPEND
- can probably be merged intoRDEPEND
PATCHES
does not allow options any longerPROPERTIES
is append by default instead of overwriteRESTRICT
is append by default instead of overwritetest_network
as newPROPERTIES
value for network support during the test phaseunpack
dropped support for7-zip
,LHA
andRAR
formatsupdates
filenames need no longer follow thenQ-yyyy
schemeusev
accepts optional second parameter to override output valuepkg_*
phases set working directory to an empty (but existing) directoryThe text was updated successfully, but these errors were encountered: