On Wed, 30 Jan 2013 13:01:20 +0000 Tom Hacohen <tom.haco...@samsung.com> wrote:
> On 30/01/13 11:32, Bertrand Jacquin wrote: > > Hi, > > > > For e5 buildbot/whatever we will need different OS and architecture > > to test. So if some volunteer are free to build some, we can gladly > > host them. > > > > Needed OS : > > > > - Windows XP x86 > > - Windows XP x86_64 > > - Windows Vista x86_64 > > - Windows 7 x86_64 > > - Windows 8 x86_64 > > > > (maybe more declination are needed ?) > > > > - Mac OS X Snow Leopard > > - Mac OS X Lion > > - Mac OS X Mountain Lion > > > > - FreeBSD 8 > > - FreeBSD 9 > > > > - NetBSD 4.0 (still supported) > > - NetBSD 6.0 (still supported) > > - NetBSD 6.0 > > > > - OpenBSD 5.2 > > > > - ?? Other, and maybe more declination on previous list Various versions of Linux as well, or did you leave them off coz you don't need any help setting them up? > > Here are characteristics : > > > > - More the system is light, faster we can transfer it > > - dd if=/dev/zero of=/device at first > > - Make the image available as a disk gzip/xz format (as main > > content will be unused space defined with zeros previously) > > - Use virtIO for network, disk and console > > - kernel parameters: > > panic=5 clocksource=kvm-clock console=tty0 console=ttyS0,115200 > > - 1 network interface with DHCP > > - syslog everything to host: log.e5 (I can send you a syslog-ng > > conf if necessery) > > - smtp relay: smtp.e5 (I can send you a exim config) > > - minimal install > > - watchdog (wdd prefered http://linux.exosec.net/watchdog/daemon/) > > - necessary packages > > - snmpd > > - acpid > > Some comments: > > You can't run Mac OS in a vm. It's possible, and it used to be legal, but Apple changed their license terms to make that illegal now. Now it's only legal to run Mac OSX on actual Apple branded hardware. Even if you own the Apple hardware, it's still illegal to run Mac OSX on a virtual machine on something else. I think that's a seriously silly mistake by Apple, as it prevents exactly the sort of thing we are trying to do here. Unfunded open source project wanting to be portable to everything, including Mac OSX, gets shot in the back by silly Apple policies so we can't afford to support them. Sooo, thanks to Apple, it's way too hard to support them for portable open source projects. I WANT to produce open source code that runs under Mac OSX as well as Windows and Linux and ..., but I came to the conclusion that Mac OSX users are just gonna have to wait until poor old me has a couple of grand laying around doing nothing before I can afford to support them. Not my fault, Apples fault, but the MAC OSX users scream blue bloody murder that I don't want to support them. It's really hard to justify purchasing expensive hardware just for a few open source projects. I know there's Mac Mini's, but they still cost twice as much as the money I spent on an equivalent development PC. I WANT to support them, Apple tied my hands and I can't. Why do I get the feeling Samsung's not gonna donate Apple hardware to open source EFL development any time soon? No love lost there. lol While on the subject, we got suitable licenses for the Windows vms? > I think it's too soon for this. We haven't really figured out our > whole CI process. Lets have those VMs when all of that is sorted. I agree here, especially with the talk of moving from buildbot to jenkins. Let that settle, as it might change the requirements. A few words of my own from my experience doing similar stuff - A very minimal default install of the OS, followed by a script that can install the rest of the build tools and build dependencies needed, is what I do. That makes things easy to reconstruct each OS later. It should even help when building variants for any specific OS if the script has a bit of flexibility. A lot of people say "just use ssh" for connecting to the systems to automate the builds. Now I don't know what buildbot and jenkins use, so this part might not be needed to say. I think ssh is a mistake under these sorts of circumstances, coz it's too heavy weight when you are running lots of VMs to compile lots of source code, on local virtual machines. They are throw away VMs that can be recreated from scratch, running a local network that is scripted from the local host. They don't NEED end to end encryption and security to slow things down, they NEED all the CPU cycles we can throw at them. Serial terminals are much better for this sort of thing, and even Windows can be scripted via serial terminal. Waaaay less overhead. On the other hand, ssh for us developers to connect from the outside world is still good there, that's the sort of thing ssh is for. For the internal build scripting though, it's just excess overhead that gets in the way. Ssh is just lazy, coz it's used for everything else, better to use the right tool for the job. Seriously, you might think ssh is not THAT much overhead, but when you are looking at dozens of vms, all busy compiling source code as quick as they can, and sending build logs back, then things start to multiply. You really don't want extra overhead then. -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world.
signature.asc
Description: PGP signature
------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan
_______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
