open-vm-tools not available for ARM

[eaf]

Hi,

For some reason this is AMD64-only right now.

I tried pulling open-vm-tools from github, built it, and it appears to work fine, at least as far as copy/paste between host and VM is concerned.

Is there a reason why this package is AMD64-only? Can it perhaps be extended to ARM64 as well? Or can I do something just in my install to get it force-installed in order to avoid doing the manual download and build during future upgrades?

Thanks!

[hdcg]

Hi eaf,

most of the time ARM is left out, because it has not been tested.
You can add your arch locally via /etc/portage/package.accept_keywords.
In your case case adding a file containing

Code: Select all

app-emulation/open-vm-tools ~ARM64

to the above directory, should allow portage to install it on ARM64 arch (please add the arch of your choice or simply **).
If needed, you can restrict accept_keywords to suitable versions. E.g.

Code: Select all

<app-emulation/open-vm-tools-9999 ~ARM64

Best Regards,
Holger

[flysideways]

I've been running an ~arm64 keyworded Gentoo install as a guest in Fusion on a Apple Silicon MacBook for about 8 months and forgot this was missing.

pakages.gentoo.org doesn't show it in any form other than amd64 and x86.

That means it is nowhere in the tree, correct? That means, for the Gentoo way, I need to create an overlay and an ebuild, right?

[Hu]

No, that is not the correct interpretation. It is in the tree, but it is keyworded stable for amd64 and x86 only. It has no keywords for other architectures, so it is neither declared broken (-ARCH), declared testing (~ARCH), nor declared stable (ARCH). No one has made any conclusive statement in the ebuild, positive or negative, about non-Intel architectures.

You only need an override via /etc/portage/package.accept_keywords, as hdcg referenced. However, since there is no keyword for non-Intel platforms, accepting ~arm64 will not work (and accepting ~ARM64 is meaningless, since no such architecture exists). I think the functional choices here would be:

Code: Select all

app-emulation/open-vm-tools **

or

Code: Select all

app-emulation/open-vm-tools amd64

The latter is a bit weird, but has the perk that it would not accept amd64-unstable versions (of which there are currently none).

[flysideways]

Thanks @Hu. That is interesting, always eager to learn.

When I try that, I unfortunately have a dependency I'm not sure how to deal with.

Code: Select all

~ # emerge -vp app-emulation/open-vm-tools

These are the packages that would be merged, in order:

Calculating dependencies... done!
Dependency resolution took 0.49 s (backtrack: 0/20).


emerge: there are no ebuilds to satisfy "x11-libs/libdrm[video_cards_vmware]".
(dependency required by "app-emulation/open-vm-tools-12.2.5::gentoo[resolutionkms]" [ebuild])
(dependency required by "app-emulation/open-vm-tools" [argument])

x11-libs/libdrm is installed and vmware has been in make.conf VIDEO_CARDS since I first built this install.

Code: Select all

emerge -vp x11-libs/libdrm 

These are the packages that would be merged, in order:

Calculating dependencies... done!
Dependency resolution took 0.69 s (backtrack: 0/20).

[ebuild   R    ] x11-libs/libdrm-2.4.120::gentoo  USE="udev -test -tools -valgrind" VIDEO_CARDS="-amdgpu -exynos -freedreno (-intel) -nouveau (-omap) -radeon -tegra -vc4 -vivante (-vmware)" 0 KiB

[Hu]

x11-libs/libdrm is installed and vmware has been in make.conf VIDEO_CARDS since I first built this install.

Code: Select all

emerge -vp x11-libs/libdrm 

These are the packages that would be merged, in order:

Calculating dependencies... done!
Dependency resolution took 0.69 s (backtrack: 0/20).

[ebuild   R    ] x11-libs/libdrm-2.4.120::gentoo  USE="udev -test -tools -valgrind" VIDEO_CARDS="-amdgpu -exynos -freedreno (-intel) -nouveau (-omap) -radeon -tegra -vc4 -vivante (-vmware)" 0 KiB

That output says VIDEO_CARDS=vmware is masked for this package. It may be masked for all packages on this architecture or just for this one package. Regardless, the mask overrides your request to enable it, so you end up with it disabled, and having it disabled is not acceptable to app-emulation/open-vm-tools[resolutionkms]. Disable USE=resolutionkms on app-emulation/open-vm-tools or override the mask on x11-libs/libdrm[video_cards_vmware]. As always when overriding a mask, consider that the mask may have been put there to block a known broken configuration, so overriding it may only lead you to a different error - at compile time, or possibly as a nasty bug at run time. In this specific case, it looks like the base profile masks video_cards_vmware, then the Intel-based profiles negate that mask. As a non-Intel profile, yours does not negate it, so the mask from base prevails. The mask message states # not needed on non-x86, non-amd64 systems, so overriding it is probably safe. However, as I was not the one to write the mask and have never discussed it with the person who did, this is pure speculation on my part.

[eaf]

Thanks for all the suggestions here.

I had to use '**' for open-vm-tools because with ~amd64 alone it still wouldn't install, libdnet also required some alterations:

Code: Select all

dev-libs/libdnet ~arm64
app-emulation/open-vm-tools **

Then I too ran into VIDEO_CARDS=vmware issues around libdrm, but overrode that and finally installed the tools via:

Code: Select all

# emerge --nodeps -av open-vm-tools

Oh, and there was a compile error due to failure to include vmwgfx_drm.h. I saw the same even with building open-vm-tools manually, straight from github. Had to add a /usr/include/vmwgfx_drm.h with a single "#include <drm/vmwgfx_drm.h>"

[Hu]

I had to use '**' for open-vm-tools because with ~amd64 alone it still wouldn't install,

With what error did it fail? Note I suggested amd64, not ~amd64, because there are currently no unstable keyword ebuilds of that package.

libdnet also required some alterations:

Code: Select all

dev-libs/libdnet ~arm64

You could rely on the implicit-ARCH behavior here:

Code: Select all

dev-libs/libdnet

Then I too ran into VIDEO_CARDS=vmware issues around libdrm, but overrode that

How did you override this?

and finally installed the tools via:

Code: Select all

# emerge --nodeps -av open-vm-tools

This is almost always wrong. Why did you use --nodeps here?

Oh, and there was a compile error due to failure to include vmwgfx_drm.h. I saw the same even with building open-vm-tools manually, straight from github. Had to add a /usr/include/vmwgfx_drm.h with a single "#include <drm/vmwgfx_drm.h>"

This also looks incorrect to me. You probably need to add the result of pkg-config CFLAGS for the package that provides that header, which would then add /usr/include/drm to the search path.

[eaf]

If I use ~arm64 instead of **, I get this:

Code: Select all

!!! All ebuilds that could satisfy "open-vm-tools" have been masked.
!!! One of the following masked packages is required to complete your request:
- app-emulation/open-vm-tools-12.2.5::gentoo (masked by: missing keyword)
- app-emulation/open-vm-tools-12.2.0::gentoo (masked by: missing keyword)

And --nodeps was added to avoid dealing with VIDEO_CARDS:

Code: Select all

!!! All ebuilds that could satisfy "x11-libs/libdrm[video_cards_vmware]" have been masked.
!!! One of the following masked packages is required to complete your request:
- x11-libs/libdrm-9999::gentoo (masked by: missing keyword)
- x11-libs/libdrm-2.4.120::gentoo (masked by: ~arm64 keyword)

[flysideways]

override the mask on x11-libs/libdrm[video_cards_vmware]

I tried everything that came to mind, and what I think I found in wiki.gentoo.org, with no success.

I have been using this vm in Fusion for eight months with no real complaint. I'm not very interested in being able to share with other vm's or the host.

My only interest with open-vm-tools would be the vmwgfx module so I get the native resolution of my laptop. The resolution I am using is quite good, just not as good as a vm that has vmwgfx and the native resolution.

It will be a while before I can get back to this.

[Hu]

If I use ~arm64 instead of **, I get this:

Code: Select all

!!! All ebuilds that could satisfy "open-vm-tools" have been masked.
!!! One of the following masked packages is required to complete your request:
- app-emulation/open-vm-tools-12.2.5::gentoo (masked by: missing keyword)
- app-emulation/open-vm-tools-12.2.0::gentoo (masked by: missing keyword)

That is consistent with what I said above. No package is keyworded as ~arm64, so accepting that keyword does not help.

And --nodeps was added to avoid dealing with VIDEO_CARDS:

Code: Select all

!!! All ebuilds that could satisfy "x11-libs/libdrm[video_cards_vmware]" have been masked.
!!! One of the following masked packages is required to complete your request:
- x11-libs/libdrm-9999::gentoo (masked by: missing keyword)
- x11-libs/libdrm-2.4.120::gentoo (masked by: ~arm64 keyword)

It looks like this could have been handled by accepting the ~arm64 keyword. More importantly, when next you try to update @world, you will likely be forced to address the dependency.

override the mask on x11-libs/libdrm[video_cards_vmware]

I tried everything that came to mind, and what I think I found in wiki.gentoo.org, with no success.

That suggests that whatever you could think of was incorrect. If you need help solving this, please show us what you did. I would expect that negating the mask via /etc/portage/profile should suffice.

[flysideways]

That suggests that whatever you could think of was incorrect.

You are correct.

Anyhow, I ended up fixing the libdrm issue by adding

Code: Select all

-video_cards_vmware

to the /var/db/repos/gentoo/profiles/arch/arm64/use.mask file for now. I expect it to get overwritten.

And, I have also separately used ** and amd64, as a look see. I have settled on ** for now.

After successfully emerging this mess I am left with this warning.

Code: Select all

* Messages for package app-emulation/open-vm-tools-12.2.5:

 *   CONFIG_VMWARE_BALLOON:      is not set when it should be.
 *   CONFIG_VMWARE_PVSCSI:       is not set when it should be.
 *   CONFIG_X86_IOPL_IOPERM:     is not set when it should be.
 * Please check to make sure these options are set correctly.
 * Failure to do so may cause unexpected problems.

I will look into those later.

And, I still cannot select my native resolution from the click and drool Gnome menu. It is not shown. I'll keep with it a bit longer. It's an adventure, right?

[flysideways]

Code: Select all

me@build ~ $ neofetch 
         -/oyddmdhs+:.                me@build 
     -odNMMMMMMMMNNmhy+-`             -------- 
   -yNMMMMMMMMMMMNNNmmdhy+-           OS: Gentoo Linux aarch64 
 `omMMMMMMMMMMMMNmdmmmmddhhy/`        Host: VMware20,1 1 
 omMMMMMMMMMMMNhhyyyohmdddhhhdo`      Kernel: 6.7.4-gentoo-dist 
.ydMMMMMMMMMMdhs++so/smdddhhhhdm+`    Uptime: 47 secs 
 oyhdmNMMMMMMMNdyooydmddddhhhhyhNd.   Packages: 948 (emerge) 
  :oyhhdNNMMMMMMMNNNmmdddhhhhhyymMh   Shell: bash 5.2.26 
    .:+sydNMMMMMNNNmmmdddhhhhhhmMmy   Resolution: 3456x2160 
       /mMMMMMMNNNmmmdddhhhhhmMNhs:   DE: GNOME 45.2 
    `oNMMMMMMMNNNmmmddddhhdmMNhs+`    WM: Mutter 
  `sNMMMMMMMMNNNmmmdddddmNMmhs/.      WM Theme: Adwaita 
 /NMMMMMMMMNNNNmmmdddmNMNdso:`        Theme: Adwaita [GTK2/3] 
+MMMMMMMNNNNNmmmmdmNMNdso/-           Icons: Adwaita [GTK2/3] 
yMMNNNNNNNmmmmmNNMmhs+/-`             Terminal: gnome-terminal 
/hMMNNNNNNNNMNdhs++/-`                CPU: Apple - (8) 
`/ohdmmddhys+++/:.`                   GPU: 00:0f.0 VMware Device 0406 
  `-//////:--.                        Memory: 975MiB / 39092MiB 

                                                              
                                                              

It helped after I found the service name for open-vm-tools is vmware-tools.

Code: Select all

rc-service vmware-tools -v start
rc-update add vmware-tools default

[flysideways]

I have moved the

Code: Select all

-video_cards_vmware

declaration to a newly created /etc/portage/profile/use.mask file so it survives updates.

I will continue to use open-vm-tools on this ~arm64 install until I find a reason not to. I am liking the 3456x2160 native resolution.

Thanks for the help @Hu

[NeddySeagoon]

Some keyword bugs are in order here.

That will get the changes into the ::gentoo repo.

[flysideways]

https://bugs.gentoo.org/924544

[flysideways]

In my original post in the above bug, I included the part of dmesg showing vmwgfx, the vmware driver for video.

Code: Select all

dmesg | grep vmwgfx
[    2.388683] vmwgfx 0000:00:0f.0: [drm] Register MMIO at 0x0x000000003d000000 size is 4096 kiB
[    2.388688] vmwgfx 0000:00:0f.0: [drm] VRAM at 0x0000000070000000 size is 131072 kiB
[    2.388695] vmwgfx 0000:00:0f.0: [drm] Running on SVGA version 3.
[    2.388698] vmwgfx 0000:00:0f.0: [drm] Capabilities: cursor, cursor bypass, alpha cursor, 3D, pitchlock, irq mask, traces, command buffers, command buffers 2, gbobject, dx, hp cmd queue, no bb restriction, cap2 register, 
[    2.388700] vmwgfx 0000:00:0f.0: [drm] Capabilities2: grow otable, intra surface copy, dx2, gb memsize 2, screendma reg, otable ptdepth2, non ms to ms stretchblt, cursor mob, mshint, cb max size 4mb, dx3, frame type, trace full fb, extra regs, lo staging, 
[    2.388701] vmwgfx 0000:00:0f.0: [drm] DMA map mode: Caching DMA mappings.
[    2.388745] vmwgfx 0000:00:0f.0: [drm] Legacy memory limits: VRAM = 4096 kB, FIFO = 256 kB, surface = 524288 kB
[    2.388746] vmwgfx 0000:00:0f.0: [drm] MOB limits: max mob size = 1048576 kB, max mob pages = 2097152
[    2.388747] vmwgfx 0000:00:0f.0: [drm] Maximum display memory size is 262144 kiB
[    2.423454] vmwgfx 0000:00:0f.0: [drm] No GMR memory available. Graphics memory resources are very limited.
[    2.423560] vmwgfx 0000:00:0f.0: [drm] Screen Target display unit initialized
[    2.425047] vmwgfx 0000:00:0f.0: [drm] Using command buffers with DMA pool.
[    2.426044] vmwgfx 0000:00:0f.0: [drm] Available shader model: SM_5_1X.
[    2.448219] [drm] Initialized vmwgfx 2.20.0 20211206 for 0000:00:0f.0 on minor 0
[    2.451529] vmwgfx 0000:00:0f.0: [drm] fb0: vmwgfxdrmfb frame buffer device

The response from NATTkA bot was;

Code: Select all

Sanity check failed:

> app-emulation/open-vm-tools-12.2.5
>   depend ~arm64 stable profile default/linux/arm64/17.0 (12 total)
>     x11-libs/libdrm[video_cards_vmware]
>   depend ~arm64 dev profile default/linux/arm64/17.0/hardened/selinux (1 total)
>     x11-libs/libdrm[video_cards_vmware]
>   rdepend ~arm64 stable profile default/linux/arm64/17.0 (12 total)
>     x11-libs/libdrm[video_cards_vmware]
>   rdepend ~arm64 dev profile default/linux/arm64/17.0/hardened/selinux (1 total)
>     x11-libs/libdrm[video_cards_vmware]

From what I can understand from reading about NATTkA, is that it just sees the -video_cards_vmware mask on libdrm and reports that without any critical analysis.

Being a maintainer is beyond my current skill set. I will continue to use these packages until something seems broken.

Do I also need to create a bug report for the libdrm mask?

[Hu]

The automation assumes /etc/portage/profile is missing/empty, since no one but you will have that. Therefore, if your proposed changes are wrong when that directory is empty, then they are not acceptable to merge as-is to the Portage tree. You need to get that flag unmasked for ARM profile users. A bug report seems like the most likely way to make that happen.

[NeddySeagoon]

flysideways,

Looking at the profiles in ::gentoo for how video_cards_vmware is managed.

Code: Select all

/var/db/repos/gentoo/profiles $ grep -R video_cards_vmware ./
./arch/amd64/use.mask:-video_cards_vmware
./arch/riscv/use.mask:video_cards_vmware
./arch/base/use.mask:video_cards_vmware
./arch/x86/use.mask:-video_cards_vmware
./prefix/darwin/macos/arch/x64/use.mask:-video_cards_vmware

You need an entry like that for arm64.

It would be ./arch/arm64/use.mask -video_cards_vmware

Its two commits in one PR, if you want to make it easy for maintainers :)
The first commit fixes the profile, the second adds the ~arm64 keyword.
With a PR, the CI will check that the repo is healthy if the PR were to be applied.

Your bug has been assigned

Assignee: bug-wranglers@gentoo.org → maintainer-needed@gentoo.org

[flysideways]

OK.

I have spent some more time with this.

As per an earlier post of mine

Anyhow, I ended up fixing the libdrm issue by adding

Code: Select all

-video_cards_vmware	

to the /var/db/repos/gentoo/profiles/arch/arm64/use.mask file for now. I expect it to get overwritten.

which looks like

Code: Select all

snip 
... 
# Unmask ARM-only video-cards
-video_cards_exynos
-video_cards_freedreno
-video_cards_lima
-video_cards_nouveau
-video_cards_panfrost
-video_cards_tegra
-video_cards_v3d
-video_cards_vc4
-video_cards_amdgpu
-video_cards_radeon
-video_cards_radeonsi
-video_cards_vmware

...

yields

Code: Select all

$ grep -R video_cards_vmware ./
./prefix/darwin/macos/arch/x64/use.mask:-video_cards_vmware
./arch/arm64/use.mask:-video_cards_vmware
./arch/base/use.mask:video_cards_vmware
./arch/riscv/use.mask:video_cards_vmware
./arch/x86/use.mask:-video_cards_vmware
./arch/amd64/use.mask:-video_cards_vmware

This also requires an /etc/portage/package.accept_keywords/ entry for both open-vm-tools and xf86-video-vmware. I used the earlier proposed ** solution. Rebuilding @world added

Code: Select all

>=media-libs/mesa-24.0.3 xa

to /etc/portage/package.use/zz-autounmask

Additionally, in the VMWare Fusion settings for the VM, the Accelerate 3D Graphics check box needs to be checked in order to select adequate video memory. Otherwise it only allocates 256M of video memory, which is not adequate.

@Neddy, I don't understand this

Its two commits in one PR, if you want to make it easy for maintainers
The first commit fixes the profile, the second adds the ~arm64 keyword.

The emerged versions of open-vm-tools (12.2.5) and xf86-video-vmware (13.4.0) are the same as the stable amd64 and x86.

[flysideways]

I am not sure how to best update the bug so it is actionable.

Clarifying that

Code: Select all

-video_cards_vmware

was added to the

Code: Select all

# Unmask ARM-only video-cards

section of /var/db/repos/gentoo/profiles/arch/arm64/use.mask is perhaps obvious.

I do not know how to express what it is that I have done by adding ** to a package_accept_keywords file for both open-vm-tools and xf86-video-vmware.

Finally, how do I run that which produces the sanity check?

[Hu]

I do not know how to express what it is that I have done by adding ** to a package_accept_keywords file for both open-vm-tools and xf86-video-vmware.

For this step, you change the KEYWORDS= line in those ebuilds so that nobody needs to accept **. I suggest changing it to add ~arm64 in both of those ebuilds, to reflect that it is still in testing, but is at least possible to use.

[NeddySeagoon]

flysideways,

As Hu says add the testing keyword to packages you have tested.
That's not enough to make it work for others.

With that change to need to change
/var/db/repos/gentoo/profiles/arch/arm64/use.mask too, just as you did.

Then it works for everyone once its in the ::gentoo repo.

As you say, you change will be overwritten. You can make the change locally in /etc/portage/profile/use.mask
That won't be changed by emerge --sync.
That file will not exist until you create it.

[flysideways]

I have followed the wiki guides https://wiki.gentoo.org/wiki/Eselect/Repository and https://wiki.gentoo.org/wiki/Creating_a ... repository on two different virtual machines. My local repositories are named local. The outcome seems promising, but not yet satisfactory.

On one I added ~arm64 to app-emulation-open-vm-tools and x11-drivers/xf86-video-vmware (it is needed by open-vm-tools). On the other, to get pysolfc, I added ~arm64 to games-board/pysolfc and dev-tcltk/tktable (it is needed by pysolfc).

On the open-vm-tools modded vm, open-vm-tools fails and xf86-video-vmware completes. On the pysolfc modded vm, pysolfc completes and tktable fails.

Both of the failures are, "no such file or directory", when they get to the first patch in the ebuild. I've searched and looked about a bit, but am not finding anything conclusive.

Both of the failing packages complete successfully when built with the package.accept.keywords method. It is when I try to build them with ~arm64 added to the ebuild that I get the failures.

I'll look a bit more, and if still unsuccessful, will paste the parts.

edit to add: They look like this

Code: Select all

* Package:    app-emulation/open-vm-tools-12.2.5:0
 * Repository: local
 * USE:        X arm64 deploypkg dnet elibc_glibc fuse icu kernel_linux pam resolutionkms ssl vgauth
 * FEATURES:   network-sandbox preserve-libs sandbox userpriv usersandbox
 * Determining the location of the kernel source code
 * Found kernel source directory:
 *     /usr/src/linux
 * Found sources for kernel version:
 *     6.7.10-gentoo-dist
 * Checking for suitable kernel configuration options ...
 *   CONFIG_VMWARE_BALLOON:      is not set when it should be.
 *   CONFIG_VMWARE_PVSCSI:       is not set when it should be.
 *   CONFIG_X86_IOPL_IOPERM:     is not set when it should be.
 [ !! ]
 * Please check to make sure these options are set correctly.
 * Failure to do so may cause unexpected problems.
>>> Unpacking source...
>>> Unpacking open-vm-tools-12.2.5-21855600.tar.gz to /var/tmp/portage/app-emulation/open-vm-tools-12.2.5/work
>>> Source unpacked in /var/tmp/portage/app-emulation/open-vm-tools-12.2.5/work
>>> Preparing source in /var/tmp/portage/app-emulation/open-vm-tools-12.2.5/work/open-vm-tools-12.2.5-21855600 ...
 * Applying 10.1.0-Werror.patch ...
/var/tmp/portage/app-emulation/open-vm-tools-12.2.5/temp/environment: line 1258: /var/tmp/portage/app-emulation/open-vm-tools-12.2.5/files/10.1.0-Werror.patch: No such file or directory
/var/tmp/portage/app-emulation/open-vm-tools-12.2.5/temp/environment: line 1261: /var/tmp/portage/app-emulation/open-vm-tools-12.2.5/files/10.1.0-Werror.patch: No such file or directory
 [ !! ]
 * ERROR: app-emulation/open-vm-tools-12.2.5::local failed (prepare phase):
 *   patch -p1 -p2 failed with /var/tmp/portage/app-emulation/open-vm-tools-12.2.5/files/10.1.0-Werror.patch
 * 
 * Call stack:
 *               ebuild.sh, line  136:  Called src_prepare
 *             environment, line 2805:  Called eapply '-p2' '/var/tmp/portage/app-emulation/open-vm-tools-12.2.5/files/10.1.0-Werror.patch' '/var/tmp/portage/app-emulation/open-vm-tools-12.2.5/files/11.3.5-icu.patch'
 *             environment, line 1326:  Called _eapply_patch '/var/tmp/portage/app-emulation/open-vm-tools-12.2.5/files/10.1.0-Werror.patch'
 *             environment, line 1264:  Called __helpers_die 'patch -p1 -p2 failed with /var/tmp/portage/app-emulation/open-vm-tools-12.2.5/files/10.1.0-Werror.patch'
 *   isolated-functions.sh, line  112:  Called die
 * The specific snippet of code:
 *              die "$@"
 * 
 * If you need support, post the output of `emerge --info '=app-emulation/open-vm-tools-12.2.5::local'`,
 * the complete build log and the output of `emerge -pqv '=app-emulation/open-vm-tools-12.2.5::local'`.
 * The complete build log is located at '/var/tmp/portage/app-emulation/open-vm-tools-12.2.5/temp/build.log'.
 * The ebuild environment file is located at '/var/tmp/portage/app-emulation/open-vm-tools-12.2.5/temp/environment'.
 * Working directory: '/var/tmp/portage/app-emulation/open-vm-tools-12.2.5/work/open-vm-tools-12.2.5-21855600'
 * S: '/var/tmp/portage/app-emulation/open-vm-tools-12.2.5/work/open-vm-tools-12.2.5-21855600'

and

Code: Select all

* Package:    dev-tcltk/tktable-2.10.8:0
 * Repository: local
 * USE:        arm64 elibc_glibc kernel_linux
 * FEATURES:   network-sandbox preserve-libs sandbox userpriv usersandbox
>>> Unpacking source...
>>> Unpacking tktable-2.10.8.tar.gz to /var/tmp/portage/dev-tcltk/tktable-2.10.8/work
>>> Source unpacked in /var/tmp/portage/dev-tcltk/tktable-2.10.8/work
>>> Preparing source in /var/tmp/portage/dev-tcltk/tktable-2.10.8/work/tktable-2.10.8 ...
 * Applying tktable-2.10-parallelMake.patch ...
/var/tmp/portage/dev-tcltk/tktable-2.10.8/temp/environment: line 290: /var/tmp/portage/dev-tcltk/tktable-2.10.8/files/tktable-2.10-parallelMake.patch: No such file or directory
/var/tmp/portage/dev-tcltk/tktable-2.10.8/temp/environment: line 293: /var/tmp/portage/dev-tcltk/tktable-2.10.8/files/tktable-2.10-parallelMake.patch: No such file or directory
 [ !! ]
 * ERROR: dev-tcltk/tktable-2.10.8::local failed (prepare phase):
 *   patch -p1  failed with /var/tmp/portage/dev-tcltk/tktable-2.10.8/files/tktable-2.10-parallelMake.patch
 * 
 * Call stack:
 *               ebuild.sh, line 136:  Called src_prepare
 *             environment, line 469:  Called default
 *      phase-functions.sh, line 872:  Called default_src_prepare
 *      phase-functions.sh, line 948:  Called __eapi8_src_prepare
 *             environment, line 271:  Called eapply '--' '/var/tmp/portage/dev-tcltk/tktable-2.10.8/files/tktable-2.10-parallelMake.patch' '/var/tmp/portage/dev-tcltk/tktable-2.10.8/files/tktable-2.10.8-clang6.patch'
 *             environment, line 358:  Called _eapply_patch '/var/tmp/portage/dev-tcltk/tktable-2.10.8/files/tktable-2.10-parallelMake.patch'
 *             environment, line 296:  Called __helpers_die 'patch -p1  failed with /var/tmp/portage/dev-tcltk/tktable-2.10.8/files/tktable-2.10-parallelMake.patch'
 *   isolated-functions.sh, line 112:  Called die
 * The specific snippet of code:
 *              die "$@"
 * 
 * If you need support, post the output of `emerge --info '=dev-tcltk/tktable-2.10.8::local'`,
 * the complete build log and the output of `emerge -pqv '=dev-tcltk/tktable-2.10.8::local'`.
 * The complete build log is located at '/var/tmp/portage/dev-tcltk/tktable-2.10.8/temp/build.log'.
 * The ebuild environment file is located at '/var/tmp/portage/dev-tcltk/tktable-2.10.8/temp/environment'.
 * Working directory: '/var/tmp/portage/dev-tcltk/tktable-2.10.8/work/tktable-2.10.8'
 * S: '/var/tmp/portage/dev-tcltk/tktable-2.10.8/work/tktable-2.10.8'

[flysideways]

The ones that complete don't have any patches. I need permissions somewhere that are wrong?