InBetweenNames
Portageq depreciated, causes warnings while building anything
See https://github.com/gentoo/portage/commit/ab538e7750fb85d57a3eb9d9b440848c1f2c074a
Used in https://github.com/InBetweenNames/gentooLTO/blob/a24c46a21cf51e3465d8f349a2b90b95a6c397af/sys-config/ltoize/files/bashrc.d/41-lto-patch.sh#L21
It will be fatal in the next portage release https://github.com/gentoo/portage/commit/76a7c3c61f6e3779452b6b3675c32bda02c8c88c
Yeah, I got my system broken today after a regular upgrade. Portage was upgraded to 3.0.54 and doesn't work anymore!
Yeah, I got my system broken today after a regular upgrade. Portage was upgraded to 3.0.54 and doesn't work anymore!
I had to emerge -c this package, modify the ebuild1 to get a hardcoded /var/db/repos path instead of portageq, then emerge again, after removing /etc/portage/bashrc.d and bashrc.
This feels wrong, and is a temporary solution, at best.
I think I'm gonna try to work around this next week or in a few, as right now I am unable to.
1 Currently mine doesn't have a lot of changes but I wouldn't recommend using it on production systems.
GentooLTO is practically dead, either stop using it and manage over rides manually or fork GentooLTO to fix uses of portageq in the portage hooks.
To actually fix ltoize would either find some non banned way to find out repository paths (I doubt it) or change the way patches are available in the repo.
With the second options I think you could a package package which contains the patches and could be installed into a proper location. It just means you would have to start making releases so that it gets updated for people in addition to just syncing the repo.
Just spit balling with the later.
https://projects.gentoo.org/pms/8/pms.html#x1-157000B
I'm personally not invested in GentooLTO as I stopped using it a long time ago and instead having managing package.env and /e/p/patches for all the problem packages.
If someone were to fork it Id advocate removing the haphazard filter-flag removal. Some packages actually need it and its breaking stuff for no reason (binutils rebuilds when LTO version changes).
I just edited the /etc/portage/bashrc.d/41-lto-patch.sh and replaced the $(portageq get_repo_path ${PORTAGE_CONFIGROOT} lto-overlay) with an actual path to the repository. This file is a symlink that points inside the repository itself, so the change would be overwritten on the next sync, but because gentooLTO is dead, and no updates are happening, this is not a problem.
I'm personally not invested in GentooLTO as I stopped using it a long time ago and instead having managing package.env and /e/p/patches for all the problem packages.
Could you somehow share your collection of package.env settings and patches?
https://github.com/InBetweenNames/gentooLTO/issues/883#issuecomment-1779837803
The only thing I currently have disabled lto on is for per, ghc and zig. ghc I know it real as I saw it get failing symbols in the new version but perf and zig require re-evalution as it has been a while since I added those.
Looking now I currently don't have any patch for lto (last valid thing must have been x264 for memory). I've been mostly just going through the gauntlet with stricter llvm-17 so that takes most of my package.env while I get through patching it at my own pace.
So I have quite minimal configs.
My CFLAGS are -O3 -march=znver2 -pipe -flto=auto -fuse-linker-plugin so I dont touch ipa-pta which might less friendlier UX.
Welp, I have -march=znver3 -O3 -fdevirtualize-at-ltrans -fipa-pta -fno-semantic-interposition -flto=16 -fuse-linker-plugin -fvect-cost-model=cheap -pipe
I just edited the
/etc/portage/bashrc.d/41-lto-patch.sh
I actually did the same: just hard-coded the path. I feel it's a dirty and ugly hack but nevertheless my portage works again. It's a pity that the project is dying, however I understand that it takes a lot of time and efforts to keep up with all the changes while the app devs are sometimes not very cooperative with LTO demands. Well, so be it...
I just edited the /etc/portage/bashrc.d/41-lto-patch.sh and replaced the $(portageq get_repo_path ${PORTAGE_CONFIGROOT} lto-overlay) with an actual path to the repository. This file is a symlink that points inside the repository itself, so the change would be overwritten on the next sync, but because gentooLTO is dead, and no updates are happening, this is not a problem.
What path did it return? Can you post the change?
What path did it return? Can you post the change?
Path to the lto-overlay repository. In my case it's /var/lib/portage/repos/lto-overlay/, but you probably have something different. Something in the /var/db/portage directory probably.
What path did it return?
Check with
$> portageq get_repo_path / lto-overlay
/var/db/repos/lto-overlay in my case.
So the line in my case would be
local lto_overlay_dir="/var/db/repos/lto-overlay"
Have fun!
Another workaround is to change portageq to the absolute path /usr/bin/portageq.
This overlay has been dropped from the gentoo overlays. Which is expected, I guess.
You can also replace the offending line with this:
local lto_overlay_dir="$("$(command -pv portageq)" get_repo_path ${PORTAGE_CONFIGROOT} lto-overlay)"
Which is a bit more generic than using the absolute path
You can also replace the offending line with this:
local lto_overlay_dir="$("$(command -pv portageq)" get_repo_path ${PORTAGE_CONFIGROOT} lto-overlay)"
portageq seems to be removed soon. Then it would stop working again...
You can also replace the offending line with this:
local lto_overlay_dir="$("$(command -pv portageq)" get_repo_path ${PORTAGE_CONFIGROOT} lto-overlay)"
This seems like a temporary workaround, still hacking on with portageq.
You can also replace the offending line with this:
local lto_overlay_dir="$("$(command -pv portageq)" get_repo_path ${PORTAGE_CONFIGROOT} lto-overlay)"portageq seems to be removed soon. Then it would stop working again...
Where are you getting that portageq itself is deprecated? It's not, only using it within ebuild scope.
You can also replace the offending line with this:
local lto_overlay_dir="$("$(command -pv portageq)" get_repo_path ${PORTAGE_CONFIGROOT} lto-overlay)"portageq seems to be removed soon. Then it would stop working again...
Where are you getting that
portageqitself is deprecated? It's not, only using it within ebuild scope.
These are used in ebuild hooks so they are in ebuild scope.
You can also replace the offending line with this:
local lto_overlay_dir="$("$(command -pv portageq)" get_repo_path ${PORTAGE_CONFIGROOT} lto-overlay)"portageq seems to be removed soon. Then it would stop working again...
Where are you getting that
portageqitself is deprecated? It's not, only using it within ebuild scope.These are used in ebuild hooks so they are in ebuild scope.
It's only banned within ebuild scope because it's temporarily overridden via PATH to use a different executable which behaves differently. As long as you take care to call the real one outside the sandbox, it should continue to work just fine.
No, it's banned because you shouldn't call portageq in ebuilds, as PMS clearly says. The suggested workaround is a hacky workaround indeed and still not permitted. Even if it "works".
portageq will remain as a command outside of the ebuild environment.
I just edited the
/etc/portage/bashrc.d/41-lto-patch.shI actually did the same: just hard-coded the path. I feel it's a dirty and ugly hack but nevertheless my portage works again. It's a pity that the project is dying, however I understand that it takes a lot of time and efforts to keep up with all the changes while the app devs are sometimes not very cooperative with LTO demands. Well, so be it...
It's not really relevant nowadays anyway, given for some time now, we've tried to handle this in ::gentoo. See e.g. https://wiki.gentoo.org/wiki/Project:Toolchain/LTO.
It's not really relevant nowadays anyway, given for some time now, we've tried to handle this in ::gentoo. See e.g. https://wiki.gentoo.org/wiki/Project:Toolchain/LTO.
gentooLTO, despite its name, is not only about LTO, so it's still relevant.
The other flags it adds shouldn't really be passed unconditionally at all.
Not sure where I've said anything that indicates you can't decide. But going against even GCC's advice on things like -fipa-pta is not wise, nor is it wise to pass flags which change runtime behaviour like -fno-semantic-interposition unconditionally.
Well, that's for users to decide.
It's also for users to decide whether they want their system to work properly :). Just because you can use various dubious optimizations doesn't mean you should or that you'll get any support for it.
It's also for users to decide whether they want their system to work properly
My system works properly.
Just because you can use various dubious optimizations doesn't mean you should
But I want to.
or that you'll get any support for it.
I don't ask anybody for support.