[Bug 291390] emulators/qemu-user-static: poudriere build fails on both 14-STABLE and 15-STABLE

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D291390

--- Comment #46 from Sulev-Madis Silber <[email protected]=
e> ---
there was once a pissed developer in mailing lists who didn't get why freeb=
sd
isn't like linux and won't allow building base and ports under a normal user
privileges, with newer or older host as builder

i only had to comment, which didn't satisfy him, that probably every freebsd
hardware developer has full lab with all architectures and versions running=
 on
real hardware and won't be scared to run things under root on a very danger=
ous
current. and for this reason things were never changed

maybe he was trolling too since i don't believe actual embedded hardware
manufacturer is single man operation with only one personal laptop. which c=
an
break. nevermind the huge security implications. you really can't break out=
 of
the physical hardware. and you no longer need to book an appointment and br=
ing
punch cards to get some code compiled on country's only good computer locat=
ed
at prominent university lab

well i don't know. i used to run some things on full emulation in qemu armv=
7 vm
on a c2d machine. some operations, or should i say portupgrade portsdb
generations still took just seconds even on that e-waste class hardware. bu=
t it
took 6 hours!!! in vm. compilation mostly worked, with some questionable
errors. but it still was very very very slow. but funnily why was ssh into =
it
so responsible. it ran part ufs on zfs file. part nfs. but speed is such th=
at i
don't think i've seen that on any real hardware, and i regularly have ran o=
ld
stuff

p.s.; still don't know how i made uboot building depend on cups but i'm sti=
ll
sure i didn't see things there. but it's not unusual to see default options
bringing half of xorg into headless server and so on. nevermind the build t=
ools
bring every know scripting language into machine and so on

just recently i opted to run 13.x built armv7 ports on 16.x kernel and world
because it was simpler to work out the kinks there than to get 16.x ports
built. but this is clearly not business production environment, otherwise i
would just run all on own hardware

--=20
You are receiving this mail because:
You are the assignee for the bug.=