| View previous topic :: View next topic |
| Author |
Message |
eaf
n00b
Joined: 27 Apr 2018
Posts: 11
|
 Posted: Wed Jan 31, 2024 12:11 am Post subject: open-vm-tools not available for ARM |
 |
|
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! |
|
| Back to top |
|
 |
hdcg
Tux's lil' helper
Joined: 07 Apr 2013
Posts: 120
|
| Posted: Wed Jan 31, 2024 5:12 am Post subject: |
|
|
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: | | 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: | | <app-emulation/open-vm-tools-9999 ~ARM64 |
Best Regards,
Holger |
|
| Back to top |
|
|
flysideways
Guru
Joined: 29 Jan 2005
Posts: 498
|
| Posted: Wed Jan 31, 2024 3:51 pm Post subject: |
|
|
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? |
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 22853
|
| Posted: Wed Jan 31, 2024 5:14 pm Post subject: |
|
|
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: | | app-emulation/open-vm-tools ** |
or | Code: | | 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). |
|
| Back to top |
|
|
flysideways
Guru
Joined: 29 Jan 2005
Posts: 498
|
| Posted: Thu Feb 01, 2024 5:27 am Post subject: |
|
|
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: | ~ # 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: | 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 |
|
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 22853
|
| Posted: Thu Feb 01, 2024 4:03 pm Post subject: |
|
|
| flysideways wrote: | x11-libs/libdrm is installed and vmware has been in make.conf VIDEO_CARDS since I first built this install. | Code: | 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. |
|
| Back to top |
|
|
eaf
n00b
Joined: 27 Apr 2018
Posts: 11
|
| Posted: Thu Feb 01, 2024 10:00 pm Post subject: |
|
|
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: | 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: | # 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>" |
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 22853
|
| Posted: Fri Feb 02, 2024 12:04 am Post subject: |
|
|
| eaf wrote: | | 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. | eaf wrote: | libdnet also required some alterations:
| Code: | | dev-libs/libdnet ~arm64 |
|
You could rely on the implicit-ARCH behavior here: | /etc/portage/package.accept_keywords: | | dev-libs/libdnet |
| eaf wrote: | | Then I too ran into VIDEO_CARDS=vmware issues around libdrm, but overrode that |
How did you override this? | eaf wrote: | and finally installed the tools via: | Code: | | # emerge --nodeps -av open-vm-tools |
|
This is almost always wrong. Why did you use --nodeps here? | eaf wrote: | | 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. |
|
| Back to top |
|
|
eaf
n00b
Joined: 27 Apr 2018
Posts: 11
|
| Posted: Fri Feb 02, 2024 11:35 pm Post subject: |
|
|
If I use ~arm64 instead of **, I get this:
| Code: | !!! 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: | !!! 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) |
|
|
| Back to top |
|
|
flysideways
Guru
Joined: 29 Jan 2005
Posts: 498
|
| Posted: Sat Feb 03, 2024 5:54 pm Post subject: |
|
|
| Quote: | | 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. |
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 22853
|
| Posted: Sat Feb 03, 2024 7:21 pm Post subject: |
|
|
| eaf wrote: | If I use ~arm64 instead of **, I get this:
| Code: | !!! 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. | eaf wrote: | And --nodeps was added to avoid dealing with VIDEO_CARDS: | Code: | !!! 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. | flysideways wrote: | | Hu wrote: | | 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. |
|
| Back to top |
|
|
flysideways
Guru
Joined: 29 Jan 2005
Posts: 498
|
| Posted: Fri Feb 09, 2024 7:08 pm Post subject: |
|
|
| Quote: | | That suggests that whatever you could think of was incorrect. |
You are correct. 
Anyhow, I ended up fixing the libdrm issue by adding
| Code: | | -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: | * 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?
Last edited by flysideways on Sun Feb 11, 2024 6:10 pm; edited 1 time in total |
|
| Back to top |
|
|
flysideways
Guru
Joined: 29 Jan 2005
Posts: 498
|
| Posted: Sat Feb 10, 2024 3:33 pm Post subject: |
|
|
| Code: | 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: | rc-service vmware-tools -v start
rc-update add vmware-tools default |
|
|
| Back to top |
|
|
flysideways
Guru
Joined: 29 Jan 2005
Posts: 498
|
| Posted: Sun Feb 11, 2024 6:08 pm Post subject: |
|
|
I have moved the | Code: | | -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 |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54638
Location: 56N 3W
|
| Posted: Sun Feb 11, 2024 6:13 pm Post subject: |
|
|
Some keyword bugs are in order here.
That will get the changes into the ::gentoo repo.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
flysideways
Guru
Joined: 29 Jan 2005
Posts: 498
|
|
| Back to top |
|
|
flysideways
Guru
Joined: 29 Jan 2005
Posts: 498
|
| Posted: Sun Feb 18, 2024 12:32 pm Post subject: |
|
|
In my original post in the above bug, I included the part of dmesg showing vmwgfx, the vmware driver for video.
| Code: | 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: | 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? |
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 22853
|
| Posted: Sun Feb 18, 2024 4:03 pm Post subject: |
|
|
| 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. |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54638
Location: 56N 3W
|
| Posted: Sun Feb 18, 2024 8:33 pm Post subject: |
|
|
flysideways,
Looking at the profiles in ::gentoo for how video_cards_vmware is managed.
| Code: | /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 | Quote: | | Assignee: bug-wranglers@gentoo.org → maintainer-needed@gentoo.org |
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
flysideways
Guru
Joined: 29 Jan 2005
Posts: 498
|
| Posted: Sun Mar 17, 2024 10:53 am Post subject: |
|
|
OK.
I have spent some more time with this.
As per an earlier post of mine | Quote: |
Anyhow, I ended up fixing the libdrm issue by adding
| Code: |
-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: | 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: | $ 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: | | >=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 | Quote: | 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.
Last edited by flysideways on Sun Mar 17, 2024 11:27 am; edited 2 times in total |
|
| Back to top |
|
|
flysideways
Guru
Joined: 29 Jan 2005
Posts: 498
|
| Posted: Sun Mar 17, 2024 11:01 am Post subject: |
|
|
I am not sure how to best update the bug so it is actionable.
Clarifying that | Code: | | -video_cards_vmware |
was added to the | Code: | | # 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? |
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 22853
|
| Posted: Sun Mar 17, 2024 2:28 pm Post subject: |
|
|
| flysideways wrote: | | 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. |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54638
Location: 56N 3W
|
| Posted: Sun Mar 17, 2024 3:06 pm Post subject: |
|
|
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.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
flysideways
Guru
Joined: 29 Jan 2005
Posts: 498
|
| Posted: Mon Mar 18, 2024 1:04 am Post subject: |
|
|
I have followed the wiki guides https://wiki.gentoo.org/wiki/Eselect/Repository and https://wiki.gentoo.org/wiki/Creating_an_ebuild_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: | * 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: | * 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' |
|
|
| Back to top |
|
|
flysideways
Guru
Joined: 29 Jan 2005
Posts: 498
|
| Posted: Mon Mar 18, 2024 1:14 am Post subject: |
|
|
| The ones that complete don't have any patches. I need permissions somewhere that are wrong? |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Gentoo on ARM
