Portageq depreciated, causes warnings while building anything

[Phoenix591]

See gentoo/portage@ab538e7

Used in

gentooLTO/sys-config/ltoize/files/bashrc.d/41-lto-patch.sh

Line 21 in a24c46a

local lto_overlay_dir="$(portageq get_repo_path ${PORTAGE_CONFIGROOT} lto-overlay)"

[parona-source]

It will be fatal in the next portage release gentoo/portage@76a7c3c

[kanyck]

Yeah, I got my system broken today after a regular upgrade. Portage was upgraded to 3.0.54 and doesn't work anymore!

[antonellocaroli]

how to solve this problem?

[kir68k]

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 ebuild¹ 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.

¹ Currently mine doesn't have a lot of changes but I wouldn't recommend using it on production systems.

[parona-source]

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).

[eternal-sorrow]

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.

[eternal-sorrow]

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?

[parona-source]

#883 (comment)

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.

[eternal-sorrow]

Welp, I have -march=znver3 -O3 -fdevirtualize-at-ltrans -fipa-pta -fno-semantic-interposition -flto=16 -fuse-linker-plugin -fvect-cost-model=cheap -pipe

[kanyck]

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...

[antonellocaroli]

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?

[eternal-sorrow]

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.

[kanyck]

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!

[matoro]

Another workaround is to change portageq to the absolute path /usr/bin/portageq.

[jonasstein]

Please close https://bugs.gentoo.org/916287, when fixed