You are not logged in.
they see something similar (for a different compilation) and it sounds as it makes a difference if you build on pure i686 hardware or virtualized via linux32 - is that right? (or am I too tired?)
Offline
Looks exactly the same.
Maybe the generated files by gSOAP are simply too big.
True, real hardware has the address space limit of 4gb, a
chroot, container on a 64-bit machine not, it seems.
Tbis means we have to be able to force certain packages to
slaves with specific properties like 32-bit chroot on real 64-bit
hardware like my build slave?
Offline
I'm building in a systemd-container in a linux32-setarch-chroot in a systemd-container on 64bit-hardware - I thought, you might be building on actual 32-bit hardware ...
Offline
No, I'm building on a 64-bit machine using the build-package script directly (which starts the 32-bit setarch-chroot?).
Maybe systemd has lowered the settings for virtual memory for each container?
Offline
But good point. I can try to build on true 32-bit infrastructure..
Offline
I'm not sure, if the build scripts work if executed on 32-bit, but it might be possible.
But for now, I'd say, you can build & upload the package - if you got your key signed and I put it into the keyring.
Offline
The stabilization of the linux package is currently blocked due to virtualbox-modules-arch being blocked by virtualbox being unbuildable.
I pretty much prefer, that you build and upload the virtualbox package now and we care about the key issue later (worst case is that some people get key issues, but the kernel will be recent - which I find more important).
Offline
Now some packages build, but I get:
root@arch32-testing ~]# VBoxHeadless -v on -s test
Oracle VM VirtualBox Headless Interface 5.2.0
(C) 2008-2017 Oracle Corporation
All rights reserved.Segmentation fault (core dumped)
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
Core was generated by `/usr/lib/virtualbox/VBoxHeadless -v on -s test'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0xb3920c12 in ?? () from /usr/lib/virtualbox/components/VBoxVMM.so
[Current thread is 1 (Thread 0xb2bebb40 (LWP 7432))]
(gdb) bt
#0 0xb3920c12 in ?? () from /usr/lib/virtualbox/components/VBoxVMM.so
#1 0xb391869d in CPUMR3Init () from /usr/lib/virtualbox/components/VBoxVMM.so
#2 0xb39c1b93 in ?? () from /usr/lib/virtualbox/components/VBoxVMM.so
#3 0xb39c62be in ?? () from /usr/lib/virtualbox/components/VBoxVMM.so
#4 0xb39c6cd5 in ?? () from /usr/lib/virtualbox/components/VBoxVMM.so
#5 0xb39c54ad in ?? () from /usr/lib/virtualbox/components/VBoxVMM.so
#6 0xb39c5855 in ?? () from /usr/lib/virtualbox/components/VBoxVMM.so
#7 0xb7b4f340 in ?? () from /usr/lib/virtualbox/VBoxRT.so
#8 0xb7bef75a in ?? () from /usr/lib/virtualbox/VBoxRT.so
#9 0xb7ee1e56 in start_thread () from /usr/lib/libpthread.so.0
#10 0xb7ddc3b6 in clone () from /usr/lib/libc.so.6
(gdb) q
and half of the packages in community are still 5.1.x, so they were not built.
Offline
Ah, I see:
2017-11-03 12:28 virtualbox-modules-arch f6445eea62e1f163a064a78e08bf528f81bcdbfb 6be177bd4475778fe0e6f7046bb9210de75ab395 community nlopc43
they are built on other slaves, now that the core virtualbox package is around. Ok. I'll wait.. :-)
Offline
Ah virtualbox-modules-arch breaks now. Ok. I'll have a look.
Offline
Ok. Done and tested.
They are just signed with my sign key, so building in the staging-i686-chroot with SigLevel=Never was necessary.
Offline
There is another important difference. I'm always building as root (changing the makepkg script accordingly).
I'm in a chroot anyway, so the danger is minimal. On the other hand, software should be built as non-root always:
it's bad if people start to assume they have root rights to build software.
So, some nspawn parameters could be relaxed and I simply have more virtual memory to build the package.
Offline