| Summary: | emerge can see binpkgs with -pK flag, but not with -K alone | ||
|---|---|---|---|
| Product: | Portage Development | Reporter: | Ivan Occam <ivan.occam> |
| Component: | Binary packages support | Assignee: | Portage team <dev-portage> |
| Status: | UNCONFIRMED --- | ||
| Severity: | normal | CC: | mgorny, syu.os |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | AMD64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 930802 | ||
| Attachments: |
log of attempt to emerge binpkgs, with and without --pretend and --debug options
local emerge.info server emerge --info output of emerge -pK output of emerge -dpK output of emerge -K output of emerge -Kd |
||
Could you give those as sep. attachments or within a tarfile please? ... and emerge --info (In reply to Sam James from comment #2) > ... and emerge --info Will do! Created attachment 881052 [details]
local emerge.info
Created attachment 881053 [details]
server emerge --info
emerge --info on the server which built and hosts the binpkgs
Created attachment 881054 [details]
output of emerge -pK
Created attachment 881055 [details]
output of emerge -dpK
Created attachment 881057 [details]
output of emerge -K
Other than this, emerge just provides a message stating the binpkgs cannot be found.
Created attachment 881058 [details]
output of emerge -Kd
emerge's only other message is it cannot find the binary package
I can confirm this behaviour persists despite mounting the nfs4 share via /etc/fstab at boot, and on three different client computers. Huh, it really does give up super early. zac? Very puzzling. The --pretend option seems like it should only make a difference if FEATURES=binpkg-request-signature is enabled. Is there any difference if you use -k instead of -K? With -k, emerge wants to compile all the target packages from source, and will proceed to compilation. I'm looking for some more ideas but in the meantime: I wonder if you could try bisect it roughly if you try say, portage-3.0.10 - does that work? You can try it from a source checkout with https://wiki.gentoo.org/wiki/Project:Portage#Testing_Portage. You have to pick a newer version though if using gpkg. When I tried doing a source checkout with versions 0.20 and 0.31, I had the same result. And after modifying my PYTHONPATH and PATH as described in the wiki page, my standard emerge install of 3.0.59 couldn't see the binpkgs, even with the --pretend flag. More significantly, while testing, I noticed that the issue might have to do wit h sudo ... if I do 'sudo emerge -pvK PACKAGE', it cannot see the binpkgs. But if I run the same command without sudo I see the bins as expected. Hope that helps. Something to do with the UID? Oh, and yes, I did use gpkg, for the record. (In reply to Ivan Occam from comment #15) > More significantly, while testing, I noticed that the issue might have to do > wit h sudo ... if I do 'sudo emerge -pvK PACKAGE', it cannot see the > binpkgs. But if I run the same command without sudo I see the bins as > expected. This sounds like it could be related to something like root_squash in your nfs exports. As it is, /var/cache/binpkgs typically needs to be both readable and writable by root. I got it to work using export options of (rw,no_subtree_check,root_squash), and directory permissions on the server of 775 for /var/cache/binpkgs. However, the wiki specifically states to use read-only options at https://wiki.gentoo.org/wiki/Binary_package_guide#NFS_exported Is the wiki incorrect? It would be trivial for me to correct that. |
Created attachment 881051 [details] log of attempt to emerge binpkgs, with and without --pretend and --debug options While attempting to install binpkgs hosted on a nfs4 share mounted at /var/cache/binpkgs, emerge is able to see the binary packages when the '--pretend' option is used, but not when actual install is attempted. When attempting a proper install, it fails with an message that 'there are no binary packages to satisfy "PACKAGE".'