[E-devel] e5: Call for VM

[Bertrand Jacquin <beber@me...>]

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

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

Thanks,

-- 
Beber

Re: [E-devel] e5: Call for VM

[Tom Hacohen <tom.hacohen@sa...>]

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
>
> 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.
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.

--
Tom.

Re: [E-devel] e5: Call for VM

[David Seikel <onefang@gm...>]

On Wed, 30 Jan 2013 13:01:20 +0000 Tom Hacohen
<tom.hacohen@...> 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.

Re: [E-devel] e5: Call for VM

[Bertrand Jacquin <beber@me...>]

On 2013-01-30 21:57, David Seikel wrote:
> On Wed, 30 Jan 2013 13:01:20 +0000 Tom Hacohen
> <tom.hacohen@...> 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?

No, I just forget them. Yes, you need ARM, mips, mipsel, ppc, ppc64, 
sparc ...

>> 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.

Don't they apply a specific licensing for developers ?

> While on the subject, we got suitable licenses for the Windows vms?

We don't currently have.

>> 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.

Well, that's not an immediate request. It's a long term build farm 
design.

> 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.

Also, we can easily do LVM snapshot the VM so we can rewind if 
everything is br0ken.

> 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.

Builbot use a daemon on the slave host, master send order to the slave 
to build that revision for that build chain. There is no use of SSH, all 
transfers and orders are passed via a clear channel on a specific TCP 
port.

-- 
Beber

Re: [E-devel] e5: Call for VM

[Bertrand Jacquin <beber@me...>]

> > While on the subject, we got suitable licenses for the Windows vms?
> 
> We don't currently have.

But we have a valid one for ICC. They provide licence for open source
projects.

-- 
Beber

Re: [E-devel] e5: Call for VM

[David Seikel <onefang@gm...>]

On Thu, 31 Jan 2013 10:32:47 +0100 Bertrand Jacquin
<beber@...> wrote:

> On 2013-01-30 21:57, David Seikel wrote:
> > On Wed, 30 Jan 2013 13:01:20 +0000 Tom Hacohen
> > <tom.hacohen@...> 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?
> 
> No, I just forget them. Yes, you need ARM, mips, mipsel, ppc, ppc64, 
> sparc ...
> 
> >> 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.
> 
> Don't they apply a specific licensing for developers ?

Not that I know of.  I'll add it to me TODO to check on that, since I
want to have a MAC OSX VM image myself for open source development.

> > While on the subject, we got suitable licenses for the Windows vms?
> 
> We don't currently have.
> 
> >> 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.
> 
> Well, that's not an immediate request. It's a long term build farm 
> design.
> 
> > 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.
> 
> Also, we can easily do LVM snapshot the VM so we can rewind if 
> everything is br0ken.
> 
> > 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.
> 
> Builbot use a daemon on the slave host, master send order to the
> slave to build that revision for that build chain. There is no use of
> SSH, all transfers and orders are passed via a clear channel on a
> specific TCP port.

That's cool then.  B-)

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.

Re: [E-devel] e5: Call for VM

[Leif Middelschulte <leif.middelschulte@gm...>]

Am Mittwoch, 30. Januar 2013 um 12:32 schrieb Bertrand Jacquin:
> 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
While it's not directly efl development focused, it would be nice to have a vm to compile/package (GBS/OBS) native (efl based) Tizen apps for the Tizen developer device.

--

Leif
> 
> 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
> 
> Thanks,
> 
> -- 
> Beber
> 
> ------------------------------------------------------------------------------
> 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@... (mailto:enlightenment-devel@...)
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> 
> 

Re: [E-devel] e5: Call for VM

[Bertrand Jacquin <beber@me...>]

>> - ?? Other, and maybe more declination on previous list
>
> While it's not directly efl development focused, it would be nice to
> have a vm to compile/package (GBS/OBS) native (efl based) Tizen apps
> for the Tizen developer device.

What is needed for this ?

-- 
Beber

Re: [E-devel] e5: Call for VM

[Leif Middelschulte <leif.middelschulte@gm...>]

Am Freitag, 1. Februar 2013 um 14:21 schrieb Bertrand Jacquin:
> > > - ?? Other, and maybe more declination on previous list
> > 
> > 
> > While it's not directly efl development focused, it would be nice to
> > have a vm to compile/package (GBS/OBS) native (efl based) Tizen apps
> > for the Tizen developer device.
> > 
> 
> 
> What is needed for this ?
Either you setup a vm with cross compiling stuff, etc. yourself _or_ you use one of these appliances:
http://susestudio.com/a/e0uuBG/obs-obs-server-opensuse-12-1-devel or http://susestudio.com/a/e0uuBG/obs-light-obs-client-stable
Unfortunately I haven't tested them myself locally yet :-/
As far as I read, the 'light' edition is actually intended to run locally (read: on dev machines) though.

--
Leif
> 
> -- 
> Beber
> 
> ------------------------------------------------------------------------------
> 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@... (mailto:enlightenment-devel@...)
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> 
> 

Re: [E-devel] e5: Call for VM

[Tom Hacohen <tom@st...>]

Hey guys,

This is really future stuff, we didn't even get the basics running yet.

--
Tom.


On Fri, Feb 1, 2013 at 5:16 PM, Leif Middelschulte <
leif.middelschulte@...> wrote:

> Am Freitag, 1. Februar 2013 um 14:21 schrieb Bertrand Jacquin:
> > > > - ?? Other, and maybe more declination on previous list
> > >
> > >
> > > While it's not directly efl development focused, it would be nice to
> > > have a vm to compile/package (GBS/OBS) native (efl based) Tizen apps
> > > for the Tizen developer device.
> > >
> >
> >
> > What is needed for this ?
> Either you setup a vm with cross compiling stuff, etc. yourself _or_ you
> use one of these appliances:
> http://susestudio.com/a/e0uuBG/obs-obs-server-opensuse-12-1-devel or
> http://susestudio.com/a/e0uuBG/obs-light-obs-client-stable
> Unfortunately I haven't tested them myself locally yet :-/
> As far as I read, the 'light' edition is actually intended to run locally
> (read: on dev machines) though.
>
> --
> Leif
> >
> > --
> > Beber
> >
> >
> ------------------------------------------------------------------------------
> > 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@... (mailto:
> enlightenment-devel@...)
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> >
> >
>
>
>
> ------------------------------------------------------------------------------
> 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@...
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>



-- 
Tom.

Re: [E-devel] e5: Call for VM

[Carsten Haitzler (The Rasterman) <raster@ra...>]

On Wed, 30 Jan 2013 12:32:23 +0100 Bertrand Jacquin <beber@...> said:

while this would be nice... we don't even have our "home turf" vm's all set up
yet.

1. we need to drop lvm. qcow+file images. it just makes migrating vms elsehwere
a lot harder if you put them on lvm requiring extra levels of special setup to
use them.
2. nfs homedirs are a no-go. homedirs must/should be local to the vm fs image.
making them nfs makes them non-portable. the whole POINT of using qemu/kvm in
the first place is, that if we get overloaded, or if e5 goes down, or whatever
we can TRIVALLY just move any vm over to osuosl's vm cluster system and
re-point dns and presto... it works. this is WHY we want a SIMPLE setup. not
complex. SIMPLE.
3. firewall needs to go - NAT is enough. firewall just wastes peoples time
debugging services. in all the years e1/e2 have been up we have nver needed or
uses a fw. if someone "breaks in" and then can "get data out"... WHO CARES...
we arent hiding secret data! this is not a paranoid corporate system. if they
broke in and start modifying our git repos and then people download src with
trojans in it.. thats bad.. but a fw wont stop that... and tbh... we havent had
this problem before (i know there is a 1st time), and if we do. thats WHY we
have vm filesystem images and qcoq deltas/backups we can just pull out of cold
storage. with qcow we can keep fs DELTAS offline "at home" trivially by just
scping a qcow snapshot (or series) and simply upload any compromised one and
restart from there. enough devs have home storage to keep enough of these
images copied and safe in case this happens.

:)

> 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
> 
> 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
> 
> Thanks,
> 
> -- 
> Beber


-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster@...

Re: [E-devel] e5: Call for VM

[Stefan Schmidt <s.schmidt@sa...>]

Hello.

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

Who is actually going to setup, run and maintain all this VMs?

My personal plans would cover this parts:
o Linux 32 and 64 bit
o Cross compile for ARM
o gcc and clang builds
o Cross builds for Windows with mingw if it turns out to be easy enough

So my needs for VMs are down to 2 or 3.

regards
Stefan Schmidt

Re: [E-devel] e5: Call for VM

[Bertrand Jacquin <beber@me...>]

D'ar lun 04 a viz C'hwevrer 2013 e 16 eur 02, « Stefan Schmidt » he deus skrivet :
> Hello.
> 
> 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
> 
> Who is actually going to setup, run and maintain all this VMs?

I can handled gentoo one, and if needed other linux distro. I'm not
really used to others so I can try but it's not a definitive position :)

> My personal plans would cover this parts:
> o Linux 32 and 64 bit
> o Cross compile for ARM
> o gcc and clang builds
> o Cross builds for Windows with mingw if it turns out to be easy enough
> 
> So my needs for VMs are down to 2 or 3.
> 
> regards
> Stefan Schmidt
> 
> ------------------------------------------------------------------------------
> 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@...
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

-- 
Beber

Re: [E-devel] e5: Call for VM

[Bertrand Jacquin <beber@me...>]

Hi,

D'ar lun 04 a viz C'hwevrer 2013 e 07 eur 29, « Carsten Haitzler » he deus skrivet :
> On Wed, 30 Jan 2013 12:32:23 +0100 Bertrand Jacquin <beber@...> said:
> 
> while this would be nice... we don't even have our "home turf" vm's all set up
> yet.
> 
> 1. we need to drop lvm. qcow+file images. it just makes migrating vms elsehwere
> a lot harder if you put them on lvm requiring extra levels of special setup to
> use them.

I do agree that qcow can be more easy, but here is the trick. We have
two cases : VM migration, VM duplication for tests purpose.

** VM duplication :

Using libvirt to migrate need one of Fibre Channel, NFS, GFS or
iSCSI between the two hosts. We don't have it. I asked to OSUOSL what is
their internal process so maybe we can use it in the future.

For the moment there is nothing, so here is the process :

 = Using LVM :

  pv /dev/vg-data/e5-template1-sys | ssh osuosl dd of=/somewhere/e5-t1-sys.img
	<repeat for each disk>

 = Using qcow :

	scp /somewhere/e5-template1-sys.img osuosl:/somewhere
	<repeat for each disk>

So here it's the same and not so much complicated for one way or one
other.

** Dump to test purpose

That's already what we did with Tom and Dan needed a fresh VM :

  pv /dev/vg-data/e5-template1-sys | xz -f | dd of=/root/e5-template1-sys.img.xz

In all case, the source file is just different, so it's not higly more
complicated, it's the same.

Using FS over FS in not really efficace, plus, you need to care of the
multiple sync that append on the VM FS, on the host FS, on the host
RAID, on the host disks. Using LVM, there is one less layer.

Also, all resize feature etc are still available.

I do think performance is a criteria as we can observe on e2 for now. We
should avoid to reproduce a such situation at the very begenning to not
be surprise in some times.

Also, yes we have a lot of RAM and CPU on e5, that's really fine. But
I/O are absolutely not better with a lot of RAM or CPU.

> 2. nfs homedirs are a no-go. homedirs must/should be local to the vm fs image.
> making them nfs makes them non-portable. the whole POINT of using qemu/kvm in
> the first place is, that if we get overloaded, or if e5 goes down, or whatever
> we can TRIVALLY just move any vm over to osuosl's vm cluster system and
> re-point dns and presto... it works. this is WHY we want a SIMPLE setup. not
> complex. SIMPLE.

Yep ! NFS is here to speed up thing for now, it's temporary and will not
stay. Never wanted to.

> 3. firewall needs to go - NAT is enough.

NAT is not firewalling, hope we agree on this.

> firewall just wastes peoples time
> debugging services.

We should not have to debug anything when thing are up, when we deploy
new since I agree, it's normal. And this does not happend so often.

> in all the years e1/e2 have been up we have nver needed or
> uses a fw.

And for 4 years, MySQL has been opened to whole internet. This just
prevent mistakes.

> if someone "breaks in" and then can "get data out"... WHO CARES...
> we arent hiding secret data! this is not a paranoid corporate system.

I can be really more paranoid than that ;)

> if they
> broke in and start modifying our git repos and then people download src with
> trojans in it.. thats bad.. but a fw wont stop that... and tbh... we havent had
> this problem before (i know there is a 1st time), and if we do. thats WHY we
> have vm filesystem images and qcoq deltas/backups

I also do FS backup with delta on my own.

> we can just pull out of cold
> storage. with qcow we can keep fs DELTAS offline "at home" trivially by just
> scping a qcow snapshot (or series) and simply upload any compromised one and
> restart from there. enough devs have home storage to keep enough of these
> images copied and safe in case this happens.

> :)
> 
> > 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
> > 
> > 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
> > 
> > Thanks,
> > 
> > -- 
> > Beber
> 
> 
> -- 
> ------------- Codito, ergo sum - "I code, therefore I am" --------------
> The Rasterman (Carsten Haitzler)    raster@...
> 

-- 
Beber

Re: [E-devel] e5: Call for VM

[Carsten Haitzler (The Rasterman) <raster@ra...>]

On Wed, 6 Feb 2013 20:19:56 +0100 Bertrand Jacquin <beber@...> said:

> Hi,
> 
> D'ar lun 04 a viz C'hwevrer 2013 e 07 eur 29, « Carsten Haitzler » he deus
> skrivet :
> > On Wed, 30 Jan 2013 12:32:23 +0100 Bertrand Jacquin <beber@...>
> > said:
> > 
> > while this would be nice... we don't even have our "home turf" vm's all set
> > up yet.
> > 
> > 1. we need to drop lvm. qcow+file images. it just makes migrating vms
> > elsehwere a lot harder if you put them on lvm requiring extra levels of
> > special setup to use them.
> 
> I do agree that qcow can be more easy, but here is the trick. We have
> two cases : VM migration, VM duplication for tests purpose.
> 
> ** VM duplication :
> 
> Using libvirt to migrate need one of Fibre Channel, NFS, GFS or
> iSCSI between the two hosts. We don't have it. I asked to OSUOSL what is
> their internal process so maybe we can use it in the future.

eh? i literally have just copied a qemu disk image from machine a to machine
b... and brought up qemu on it and it works out-of-the-box, zero changes,
migrating etc. it was "scp" and presto. thats why "nfs" for homedirs i think is
bad - it's not self-contained in the image file - you have to transprot your
entire setup across which is complex and not self-contained. that's why i think
lvm just complicates things too. with simple disk files we can easily do delta
snapshot files to transport "current state relative to a baseline" and have
the baseline backed up and stored too. u can just bring it up with qemu cmdline
by hand. dont HAVE to use libvirt. it's trivial to do. you can use libvirt too.

qemu-img create -f qcow2 -b base.img delta.img

personally i'm perfectly happy with shutting down the kvm/qemu image once per
day and doing the above to gen a new daily delta img and backing that up (eg
scp it home - i can do this trivially - i have the bandwidth and space. we can
also do it via scping over to e3/e4 too etc.). osuosl plan on bringing up a big
nfs storage system sometime for backups and data and we can use that too when
it appears. :)

and yes - i know qemu can do LIVE snapshots without shutdown.

http://wiki.qemu.org/Features/Snapshots

also possible. :)

> For the moment there is nothing, so here is the process :
> 
>  = Using LVM :
> 
>   pv /dev/vg-data/e5-template1-sys | ssh osuosl dd of=/somewhere/e5-t1-sys.img
> 	<repeat for each disk>
> 
>  = Using qcow :
> 
> 	scp /somewhere/e5-template1-sys.img osuosl:/somewhere
> 	<repeat for each disk>
> 
> So here it's the same and not so much complicated for one way or one
> other.

the files are more obvious. if we need bigger base images it's a simple
re-generate of img file. lvm is more involved to expand image sizes. :)

> ** Dump to test purpose
> 
> That's already what we did with Tom and Dan needed a fresh VM :
> 
>   pv /dev/vg-data/e5-template1-sys | xz -f | dd
> of=/root/e5-template1-sys.img.xz
> 
> In all case, the source file is just different, so it's not higly more
> complicated, it's the same.
> 
> Using FS over FS in not really efficace, plus, you need to care of the
> multiple sync that append on the VM FS, on the host FS, on the host
> RAID, on the host disks. Using LVM, there is one less layer.

this isnt a "mission critical" system. we will have backups. if we loose half a
day of stuff because of a disk failure.. so be it.. we lose it. go back to last
snapshot/backup. with git we have a massively distributed backup/copy of all
the src which is the most important thing we have, so we are good imho.

> Also, all resize feature etc are still available.
> 
> I do think performance is a criteria as we can observe on e2 for now. We
> should avoid to reproduce a such situation at the very begenning to not
> be surprise in some times.

i am sitting here with a totally unoptimized ubuntu 12.04 image in qemu. i
actually don't NOTICE a slowdown compared the to the 12.04 host when it comes
to I/O. in fact... its FASTER than the host - by a wide margin, when it comes
to boot for example. once cached it boots in about 7 seconds all the way to a
gui (e17+xorg+etc. with all the ubuntu overhead behind it too). the host takes
something like 20-30sec to boot... you currently say that it takes about 5 sec
to boot your gentoo vm's.. thats without e17+xorg+the rest ubuntu slaps on top.
this is a simple core i7 desktop with only 3.5gb of available ram (32bit and
your regular spinning hdd... i see no issues here.

what we need to avoid is things like mysql that hammer the disk with syncs. svn
+apache are a lethal combination easily consuming 2gb of ram when someone
checks out our svn tree via http. and trac in general just loves to consume
cycles. remember e2 is a 6+ year old machine, with a raid controller on the
blink, 2g of ram and a fairly old cpu... e5 is beefy on a bad day. 48g of ram
is one really nice disk cache.

> Also, yes we have a lot of RAM and CPU on e5, that's really fine. But
> I/O are absolutely not better with a lot of RAM or CPU.

that's why i'd rather not FORCE it to be I/O - let it go to ram. this is not
"mission critical". if we "lose a transaction" - too bad. someone's bug report
disappears. for git - this is not a problem as its a distributed system with
every client having backups. the person who did the push has the data - we
didn't lose it. we can push it again in this rare event. we can actually
minimize this simply by running fsync on the host every now and again to ensure
syncs to real media - but dont force this per transaction.

i understand your point of view. it's one of "this is a mission critical system
and we must not lose anything ever".  but we can afford that - thus we can make
different trade-offs. ease of administration. obviousness. ease of migration of
vm's, ease of setting up new things ad-hoc when needed and simplicity in
general are worth more imho. the experience of 6+ years of e.org tell me to
"keep it simple". what happens when you get run over by a bus? we don't have
full-time admins following your every setup and reading manuals. they look at
it once and then use it. in 3 years something happens to you (the bus, or you
get bored of e, or are just on a long holiday for 2 months?) and someone else
needs to "fix things"... if what they find is incredibly complex, tied together
deeply and they haven't spent day in and out adminning the box, they can't
figure out what to do and eventually just ad-hoc make a mess trying to get
things back up at all. you may be back after your holiday only to find things
are now messed up, or we spend longer "down" than needed etc. SIMPLICITY trumps
performance here. GIT solves the most important side of data integrity by its
very nature. the rest is "nice to have, but not critical". if we have to roll
back 1/2 a day or a day of data... we'll live just fine, unless this is
happening every few days.. and then we have a major serious problem.

> > 2. nfs homedirs are a no-go. homedirs must/should be local to the vm fs
> > image. making them nfs makes them non-portable. the whole POINT of using
> > qemu/kvm in the first place is, that if we get overloaded, or if e5 goes
> > down, or whatever we can TRIVALLY just move any vm over to osuosl's vm
> > cluster system and re-point dns and presto... it works. this is WHY we want
> > a SIMPLE setup. not complex. SIMPLE.
> 
> Yep ! NFS is here to speed up thing for now, it's temporary and will not
> stay. Never wanted to.

cool! :) again as above - speed.. don't care. :) the qemu -fsdev/virtfs option
is more "sane" imho if we want to have arbitrary expansion space outside the fs
image - this means we can have base fs img + delta + dir of "extra
files" (tar/rsync that dir as needed)

> > 3. firewall needs to go - NAT is enough.
> 
> NAT is not firewalling, hope we agree on this.

i know.. but it provides protection in that "you can't get in through the nat
unless something explicitly forwards a port". getting in is a reality we will
have to live with unless we want to ask for an IP for every VM... and that's
asking a lot of osu to go vie us so many IP's.

> > firewall just wastes peoples time
> > debugging services.
> 
> We should not have to debug anything when thing are up, when we deploy
> new since I agree, it's normal. And this does not happend so often.

ask daniel. he already spent hours figuring out a problem that was the fw
blocking OUTGOING traffic. we JUST need a NAT. we all know the NAT will provide
incoming connections unless we explicitly route them. we "expect" outgoing
connections to "just work" (tm) with nothing in the way.

> > in all the years e1/e2 have been up we have nver needed or
> > uses a fw.
> 
> And for 4 years, MySQL has been opened to whole internet. This just
> prevent mistakes.

we're behind a nat... that already does all the work we need. the host system
(e5) has nothing running anyway, so doesn't matter.

> > if someone "breaks in" and then can "get data out"... WHO CARES...
> > we arent hiding secret data! this is not a paranoid corporate system.
> 
> I can be really more paranoid than that ;)

:) sure. just saying - that we don't need to go this far. :)

> > if they
> > broke in and start modifying our git repos and then people download src with
> > trojans in it.. thats bad.. but a fw wont stop that... and tbh... we havent
> > had this problem before (i know there is a 1st time), and if we do. thats
> > WHY we have vm filesystem images and qcoq deltas/backups
> 
> I also do FS backup with delta on my own.

:)

> > we can just pull out of cold
> > storage. with qcow we can keep fs DELTAS offline "at home" trivially by just
> > scping a qcow snapshot (or series) and simply upload any compromised one and
> > restart from there. enough devs have home storage to keep enough of these
> > images copied and safe in case this happens.
> 
> > :)
> > 
> > > 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
> > > 
> > > 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
> > > 
> > > Thanks,
> > > 
> > > -- 
> > > Beber
> > 
> > 
> > -- 
> > ------------- Codito, ergo sum - "I code, therefore I am" --------------
> > The Rasterman (Carsten Haitzler)    raster@...
> > 
> 
> -- 
> Beber


-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster@...

Re: [E-devel] e5: Call for VM

[ravenlock <ravenlock@ra...>]

On 1/30/13 5:32 AM, 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

What is the plan for licensing the above?

> 
>  (maybe more declination are needed ?)
> 
>  - Mac OS X Snow Leopard
>  - Mac OS X Lion
>  - Mac OS X Mountain Lion

This is easy and do'able if you have the Mac hardware and Parallels.
Refurbed Mac Minis are like $500, you can stuff 16GB in them and a 1TB
disk.  Works perfectly well.  Once upon a time there were E-funds being
held.  We might tap into those?

> 
>  - FreeBSD 8
>  - FreeBSD 9

I'd be happy to pitch in on the FreeBSD front if no one else has jumped
on it.

> 
>  - NetBSD 4.0 (still supported)
>  - NetBSD 6.0 (still supported)
>  - NetBSD 6.0
> 
>  - OpenBSD 5.2

-ravenlock

Re: [E-devel] e5: Call for VM

[Carsten Haitzler (The Rasterman) <raster@ra...>]

On Thu, 07 Feb 2013 09:35:07 -0600 ravenlock <ravenlock@...> said:

> On 1/30/13 5:32 AM, 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
> 
> What is the plan for licensing the above?

someone needs to actually pay for a proper license/copy. there is no way i will
allow us to use pirated copies of any software on our infra. if we ask people
to respect our licenses, be they bsd, gpl or anything else, then we will
respect theirs, regardless if they are open or not.

> >  (maybe more declination are needed ?)
> > 
> >  - Mac OS X Snow Leopard
> >  - Mac OS X Lion
> >  - Mac OS X Mountain Lion
> 
> This is easy and do'able if you have the Mac hardware and Parallels.
> Refurbed Mac Minis are like $500, you can stuff 16GB in them and a 1TB
> disk.  Works perfectly well.  Once upon a time there were E-funds being
> held.  We might tap into those?

he's asking for vm's, not hardware. we can't do squat diddly with a mac mini.
our server is in a rack in a server room/colo in oregon. :) i know - osx
expressly forbids being used on anything other than apple hardware (vm's
included).

> > 
> >  - FreeBSD 8
> >  - FreeBSD 9
> 
> I'd be happy to pitch in on the FreeBSD front if no one else has jumped
> on it.

a qemu vm disk image would be what is good here. the file and any other qemu
cmdline info needed to bring it up (specific device emulation).

something installed with network running and preferably everything up to and
including x running and working within the vm, sshd running and working with a
root password made available for admins.

basically this vm has to run on the server and be brought up and down as needed
and able to be sshd into and configured when/if needed. it will be used for
running builds on, generating any binaries if/when we want, as well as running
test suites. that means it needs all the dependencies on there and the ability
to add more dependencies when/if needed. :)

> > 
> >  - NetBSD 4.0 (still supported)
> >  - NetBSD 6.0 (still supported)
> >  - NetBSD 6.0
> > 
> >  - OpenBSD 5.2
> 
> -ravenlock
> 
> 


-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster@...

Re: [E-devel] e5: Call for VM

[ravenlock <ravenlock@ra...>]

On 2/7/13 8:35 PM, Carsten Haitzler (The Rasterman) wrote:
> On Thu, 07 Feb 2013 09:35:07 -0600 ravenlock <ravenlock@...> said:
> 
>> On 1/30/13 5:32 AM, 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
>>
>> What is the plan for licensing the above?
> 
> someone needs to actually pay for a proper license/copy. there is no way i will
> allow us to use pirated copies of any software on our infra. if we ask people
> to respect our licenses, be they bsd, gpl or anything else, then we will
> respect theirs, regardless if they are open or not.

I didn't propose pirating anything.  Didn't know if we were hoping for
people to purchase and donate copies, send in old decommissioned
personal copies, if we were using E-funds or whatnot.

> 
>>>  (maybe more declination are needed ?)
>>>
>>>  - Mac OS X Snow Leopard
>>>  - Mac OS X Lion
>>>  - Mac OS X Mountain Lion
>>
>> This is easy and do'able if you have the Mac hardware and Parallels.
>> Refurbed Mac Minis are like $500, you can stuff 16GB in them and a 1TB
>> disk.  Works perfectly well.  Once upon a time there were E-funds being
>> held.  We might tap into those?
> 
> he's asking for vm's, not hardware. we can't do squat diddly with a mac mini.

If you desire osx, you'll be duct taping that Mac Mini to your rack
mounted colo.  ;)

> our server is in a rack in a server room/colo in oregon. :) i know - osx
> expressly forbids being used on anything other than apple hardware (vm's
> included).
> 
>>>
>>>  - FreeBSD 8
>>>  - FreeBSD 9
>>
>> I'd be happy to pitch in on the FreeBSD front if no one else has jumped
>> on it.
> 
> a qemu vm disk image would be what is good here. the file and any other qemu
> cmdline info needed to bring it up (specific device emulation).
> 
> something installed with network running and preferably everything up to and
> including x running and working within the vm, sshd running and working with a
> root password made available for admins.
> 
> basically this vm has to run on the server and be brought up and down as needed
> and able to be sshd into and configured when/if needed. it will be used for
> running builds on, generating any binaries if/when we want, as well as running
> test suites. that means it needs all the dependencies on there and the ability
> to add more dependencies when/if needed. :)

Is there a time frame in which this is desired?

> 
>>>
>>>  - NetBSD 4.0 (still supported)
>>>  - NetBSD 6.0 (still supported)
>>>  - NetBSD 6.0
>>>
>>>  - OpenBSD 5.2
>>
>> -ravenlock
>>
>>
> 
> 

Re: [E-devel] e5: Call for VM

[David Seikel <onefang@gm...>]

On Thu, 07 Feb 2013 21:45:23 -0600 ravenlock <ravenlock@...>
wrote:

> On 2/7/13 8:35 PM, Carsten Haitzler (The Rasterman) wrote:
> > On Thu, 07 Feb 2013 09:35:07 -0600 ravenlock
> > <ravenlock@...> said:
> > 
> >> On 1/30/13 5:32 AM, 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
> >>
> >> What is the plan for licensing the above?
> > 
> > someone needs to actually pay for a proper license/copy. there is
> > no way i will allow us to use pirated copies of any software on our
> > infra. if we ask people to respect our licenses, be they bsd, gpl
> > or anything else, then we will respect theirs, regardless if they
> > are open or not.
> 
> I didn't propose pirating anything.  Didn't know if we were hoping for
> people to purchase and donate copies, send in old decommissioned
> personal copies, if we were using E-funds or whatnot.
> 
> > 
> >>>  (maybe more declination are needed ?)
> >>>
> >>>  - Mac OS X Snow Leopard
> >>>  - Mac OS X Lion
> >>>  - Mac OS X Mountain Lion
> >>
> >> This is easy and do'able if you have the Mac hardware and
> >> Parallels. Refurbed Mac Minis are like $500, you can stuff 16GB in
> >> them and a 1TB disk.  Works perfectly well.  Once upon a time
> >> there were E-funds being held.  We might tap into those?

Mac Mini's are just so damn cheap, even though a second hand one cost
as much as my entire PC was when I bought it new.

> > he's asking for vm's, not hardware. we can't do squat diddly with a
> > mac mini.
> 
> If you desire osx, you'll be duct taping that Mac Mini to your rack
> mounted colo.  ;)
> 
> > our server is in a rack in a server room/colo in oregon. :) i know
> > - osx expressly forbids being used on anything other than apple
> > hardware (vm's included).

I mentioned that all before.  Apple is really shooting themselves in
the foot being this hard on open source developers.  But the Mac users
come bitching to us about "why don't you support Mac???".  Telling them
it's all Apple's fault and I can't justify buying a Mac apparently
really gets under their skin, coz Macs are the perfect computer, why
would you not want one?

I do have a Mac Mini on my to buy list, but it's waaay down the bottom,
for when I have that sort of cash just laying around doing nothing.  I
looked at them in the store a couple of days ago, not as mini as I
thought they would be.  I'm gonna have trouble finding SPACE for the
damn thing.

So to all the whining Mac users - if Apple did not make it so fucking
hard to support them, then I'd be supporting them already.  Bitch to
Apple, it's not our fault.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.

Re: [E-devel] e5: Call for VM

[Carsten Haitzler (The Rasterman) <raster@ra...>]

On Thu, 07 Feb 2013 21:45:23 -0600 ravenlock <ravenlock@...> said:

> On 2/7/13 8:35 PM, Carsten Haitzler (The Rasterman) wrote:
> > On Thu, 07 Feb 2013 09:35:07 -0600 ravenlock <ravenlock@...> said:
> > 
> >> On 1/30/13 5:32 AM, 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
> >>
> >> What is the plan for licensing the above?
> > 
> > someone needs to actually pay for a proper license/copy. there is no way i
> > will allow us to use pirated copies of any software on our infra. if we ask
> > people to respect our licenses, be they bsd, gpl or anything else, then we
> > will respect theirs, regardless if they are open or not.
> 
> I didn't propose pirating anything.  Didn't know if we were hoping for
> people to purchase and donate copies, send in old decommissioned
> personal copies, if we were using E-funds or whatnot.

sure - i'm just making it clear, that any such vm's must be installed "above
board" with legitimate licenses for the vm os's :)

> >>>  (maybe more declination are needed ?)
> >>>
> >>>  - Mac OS X Snow Leopard
> >>>  - Mac OS X Lion
> >>>  - Mac OS X Mountain Lion
> >>
> >> This is easy and do'able if you have the Mac hardware and Parallels.
> >> Refurbed Mac Minis are like $500, you can stuff 16GB in them and a 1TB
> >> disk.  Works perfectly well.  Once upon a time there were E-funds being
> >> held.  We might tap into those?
> > 
> > he's asking for vm's, not hardware. we can't do squat diddly with a mac
> > mini.
> 
> If you desire osx, you'll be duct taping that Mac Mini to your rack
> mounted colo.  ;)

which means its not going to happen. osx support in our buildbot/cluster is not
an option until apple changes their licensing policies. so upstream support ==
"whatever devs manage to do at home on their own machines if they have osx
boxen".

> > our server is in a rack in a server room/colo in oregon. :) i know - osx
> > expressly forbids being used on anything other than apple hardware (vm's
> > included).
> > 
> >>>
> >>>  - FreeBSD 8
> >>>  - FreeBSD 9
> >>
> >> I'd be happy to pitch in on the FreeBSD front if no one else has jumped
> >> on it.
> > 
> > a qemu vm disk image would be what is good here. the file and any other qemu
> > cmdline info needed to bring it up (specific device emulation).
> > 
> > something installed with network running and preferably everything up to and
> > including x running and working within the vm, sshd running and working
> > with a root password made available for admins.
> > 
> > basically this vm has to run on the server and be brought up and down as
> > needed and able to be sshd into and configured when/if needed. it will be
> > used for running builds on, generating any binaries if/when we want, as
> > well as running test suites. that means it needs all the dependencies on
> > there and the ability to add more dependencies when/if needed. :)
> 
> Is there a time frame in which this is desired?

whenever you have time. no rush. :)

> > 
> >>>
> >>>  - NetBSD 4.0 (still supported)
> >>>  - NetBSD 6.0 (still supported)
> >>>  - NetBSD 6.0
> >>>
> >>>  - OpenBSD 5.2
> >>
> >> -ravenlock
> >>
> >>
> > 
> > 
> 
> 


-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster@...

Re: [E-devel] e5: Call for VM

[Stefan Schmidt <s.schmidt@sa...>]

Hello.

On 08/02/13 04:29, Carsten Haitzler (The Rasterman) wrote:
> On Thu, 07 Feb 2013 21:45:23 -0600 ravenlock <ravenlock@...>
> said:
>
>> On 2/7/13 8:35 PM, Carsten Haitzler (The Rasterman) wrote:
>>> On Thu, 07 Feb 2013 09:35:07 -0600 ravenlock <ravenlock@...>
> said:
>>>
>>>> On 1/30/13 5:32 AM, 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
>>>>
>>>> What is the plan for licensing the above?
>>>
>>> someone needs to actually pay for a proper license/copy. there is no
> way i
>>> will allow us to use pirated copies of any software on our infra. if
> we ask
>>> people to respect our licenses, be they bsd, gpl or anything else,
> then we
>>> will respect theirs, regardless if they are open or not.
>>
>> I didn't propose pirating anything.  Didn't know if we were hoping for
>> people to purchase and donate copies, send in old decommissioned
>> personal copies, if we were using E-funds or whatnot.
>
> sure - i'm just making it clear, that any such vm's must be installed
> "above
> board" with legitimate licenses for the vm os's :)

This is kinda mood as nobody seems to actually want to setup and 
maintain these. I certainly will not touch windows for efl builds. And 
some point I would be willing to look into automated mingw64 build 
though, cross-compiled from Linux.

I don't rule that somebody at some day may want to do this. But so far 
nobody showed up so we can happily ignore this.

>>>>>   (maybe more declination are needed ?)
>>>>>
>>>>>   - Mac OS X Snow Leopard
>>>>>   - Mac OS X Lion
>>>>>   - Mac OS X Mountain Lion
>>>>
>>>> This is easy and do'able if you have the Mac hardware and Parallels.
>>>> Refurbed Mac Minis are like $500, you can stuff 16GB in them and a
> 1TB
>>>> disk.  Works perfectly well.  Once upon a time there were E-funds
> being
>>>> held.  We might tap into those?
>>>
>>> he's asking for vm's, not hardware. we can't do squat diddly with a
> mac
>>> mini.
>>
>> If you desire osx, you'll be duct taping that Mac Mini to your rack
>> mounted colo.  ;)
>
> which means its not going to happen. osx support in our buildbot/cluster
> is not
> an option until apple changes their licensing policies. so upstream
> support ==
> "whatever devs manage to do at home on their own machines if they have osx
> boxen".

My personal opinion is that we should just ignore this as well. They 
don't want people to devel something else then iOS apps. So why should 
we help them with our time?

A general idea we had was some way of having jenkins slaves that only 
report to the master. Leaving out the scary parts of a server 
controlling the PC in your home for doing the builds. I guess MacOSX 
would not care but I find it scary. :) Anyway, something like this is 
way down on my list. Way down.

regards
Stefan Schmidt

Re: [E-devel] e5: Call for VM

[Leif Middelschulte <leif.middelschulte@gm...>]

Am Freitag, 8. Februar 2013 um 09:45 schrieb Stefan Schmidt:
> Hello.
> 
> On 08/02/13 04:29, Carsten Haitzler (The Rasterman) wrote:
> > On Thu, 07 Feb 2013 21:45:23 -0600 ravenlock <ravenlock@... (mailto:ravenlock@...)>
> > said:
> > 
> > > On 2/7/13 8:35 PM, Carsten Haitzler (The Rasterman) wrote:
> > > > On Thu, 07 Feb 2013 09:35:07 -0600 ravenlock <ravenlock@... (mailto:ravenlock@...)>
> > > 
> > > 
> > 
> > said:
> > > > 
> > > > > On 1/30/13 5:32 AM, 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
> > > > > > 
> > > > > 
> > > > > 
> > > > > What is the plan for licensing the above?
> > > > 
> > > > someone needs to actually pay for a proper license/copy. there is no
> > way i
> > > > will allow us to use pirated copies of any software on our infra. if
> > > 
> > 
> > we ask
> > > > people to respect our licenses, be they bsd, gpl or anything else,
> > > 
> > 
> > then we
> > > > will respect theirs, regardless if they are open or not.
> > > 
> > > 
> > > I didn't propose pirating anything. Didn't know if we were hoping for
> > > people to purchase and donate copies, send in old decommissioned
> > > personal copies, if we were using E-funds or whatnot.
> > > 
> > 
> > 
> > sure - i'm just making it clear, that any such vm's must be installed
> > "above
> > board" with legitimate licenses for the vm os's :)
> > 
> 
> 
> This is kinda mood as nobody seems to actually want to setup and 
> maintain these. I certainly will not touch windows for efl builds. And 
> some point I would be willing to look into automated mingw64 build 
> though, cross-compiled from Linux.
> 
> I don't rule that somebody at some day may want to do this. But so far 
> nobody showed up so we can happily ignore this.
> 
> > > > > > (maybe more declination are needed ?)
> > > > > > 
> > > > > > - Mac OS X Snow Leopard
> > > > > > - Mac OS X Lion
> > > > > > - Mac OS X Mountain Lion
> > > > > > 
> > > > > 
> > > > > 
> > > > > This is easy and do'able if you have the Mac hardware and Parallels.
> > > > > Refurbed Mac Minis are like $500, you can stuff 16GB in them and a
> > > > > 
> > > > 
> > > 
> > 
> > 1TB
> > > > > disk. Works perfectly well. Once upon a time there were E-funds
> > > > 
> > > 
> > 
> > being
> > > > > held. We might tap into those?
> > > > 
> > > > 
> > > > he's asking for vm's, not hardware. we can't do squat diddly with a
> > mac
> > > > mini.
> > > 
> > > 
> > > If you desire osx, you'll be duct taping that Mac Mini to your rack
> > > mounted colo. ;)
> > > 
> > 
> > 
> > which means its not going to happen. osx support in our buildbot/cluster
> > is not
> > an option until apple changes their licensing policies. so upstream
> > support ==
> > "whatever devs manage to do at home on their own machines if they have osx
> > boxen".
> > 
> 
> 
> My personal opinion is that we should just ignore this as well. They 
> don't want people to devel something else then iOS apps. So why should 
> we help them with our time?
> 
> 

I think that it's legal to run Mac OS Server in a virtual machine. But I'm not 100% sure about this. Maybe this information is outdated. 
> 
> A general idea we had was some way of having jenkins slaves that only 
> report to the master. Leaving out the scary parts of a server 
> controlling the PC in your home for doing the builds. I guess MacOSX 
> would not care but I find it scary. :) Anyway, something like this is 
> way down on my list. Way down.
> 
> 

Sounds even better. 

--
Leif
> 
> regards
> Stefan Schmidt
> 
> 
> ------------------------------------------------------------------------------
> Free Next-Gen Firewall Hardware Offer
> Buy your Sophos next-gen firewall before the end March 2013 
> and get the hardware for free! Learn more.
> http://p.sf.net/sfu/sophos-d2d-feb
> _______________________________________________
> enlightenment-devel mailing list
> enlightenment-devel@... (mailto:enlightenment-devel@...)
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> 
> 

Re: [E-devel] e5: Call for VM

[Tom Hacohen <tom.hacohen@sa...>]

On 08/02/13 15:20, Leif Middelschulte wrote:
> Am Freitag, 8. Februar 2013 um 09:45 schrieb Stefan Schmidt:
>> Hello.
>>
>> On 08/02/13 04:29, Carsten Haitzler (The Rasterman) wrote:
>>> On Thu, 07 Feb 2013 21:45:23 -0600 ravenlock <ravenlock@... (mailto:ravenlock@...)>
>>> said:
>>>
>>>> On 2/7/13 8:35 PM, Carsten Haitzler (The Rasterman) wrote:
>>>>> On Thu, 07 Feb 2013 09:35:07 -0600 ravenlock <ravenlock@... (mailto:ravenlock@...)>
>>>>
>>>>
>>>
>>> said:
>>>>>
>>>>>> On 1/30/13 5:32 AM, 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
>>>>>>>
>>>>>>
>>>>>>
>>>>>> What is the plan for licensing the above?
>>>>>
>>>>> someone needs to actually pay for a proper license/copy. there is no
>>> way i
>>>>> will allow us to use pirated copies of any software on our infra. if
>>>>
>>>
>>> we ask
>>>>> people to respect our licenses, be they bsd, gpl or anything else,
>>>>
>>>
>>> then we
>>>>> will respect theirs, regardless if they are open or not.
>>>>
>>>>
>>>> I didn't propose pirating anything. Didn't know if we were hoping for
>>>> people to purchase and donate copies, send in old decommissioned
>>>> personal copies, if we were using E-funds or whatnot.
>>>>
>>>
>>>
>>> sure - i'm just making it clear, that any such vm's must be installed
>>> "above
>>> board" with legitimate licenses for the vm os's :)
>>>
>>
>>
>> This is kinda mood as nobody seems to actually want to setup and
>> maintain these. I certainly will not touch windows for efl builds. And
>> some point I would be willing to look into automated mingw64 build
>> though, cross-compiled from Linux.
>>
>> I don't rule that somebody at some day may want to do this. But so far
>> nobody showed up so we can happily ignore this.
>>
>>>>>>> (maybe more declination are needed ?)
>>>>>>>
>>>>>>> - Mac OS X Snow Leopard
>>>>>>> - Mac OS X Lion
>>>>>>> - Mac OS X Mountain Lion
>>>>>>>
>>>>>>
>>>>>>
>>>>>> This is easy and do'able if you have the Mac hardware and Parallels.
>>>>>> Refurbed Mac Minis are like $500, you can stuff 16GB in them and a
>>>>>>
>>>>>
>>>>
>>>
>>> 1TB
>>>>>> disk. Works perfectly well. Once upon a time there were E-funds
>>>>>
>>>>
>>>
>>> being
>>>>>> held. We might tap into those?
>>>>>
>>>>>
>>>>> he's asking for vm's, not hardware. we can't do squat diddly with a
>>> mac
>>>>> mini.
>>>>
>>>>
>>>> If you desire osx, you'll be duct taping that Mac Mini to your rack
>>>> mounted colo. ;)
>>>>
>>>
>>>
>>> which means its not going to happen. osx support in our buildbot/cluster
>>> is not
>>> an option until apple changes their licensing policies. so upstream
>>> support ==
>>> "whatever devs manage to do at home on their own machines if they have osx
>>> boxen".
>>>
>>
>>
>> My personal opinion is that we should just ignore this as well. They
>> don't want people to devel something else then iOS apps. So why should
>> we help them with our time?
>>
>>
>
> I think that it's legal to run Mac OS Server in a virtual machine. But I'm not 100% sure about this. Maybe this information is outdated.
>>
>> A general idea we had was some way of having jenkins slaves that only
>> report to the master. Leaving out the scary parts of a server
>> controlling the PC in your home for doing the builds. I guess MacOSX
>> would not care but I find it scary. :) Anyway, something like this is
>> way down on my list. Way down.
>>
>>
>
> Sounds even better.
>
> --
> Leif
>>
>> regards
>> Stefan Schmidt
>>
>>

Someone mentioned something about being allowed to run mac on a vm for 
open source software development. I'm not sure it's true though.

But as Stefan said, we were already thinking about having a way for 
"people" to report build status. So we'll be able to have crazy setups, 
like Mac OS, PS3 and etc.

--
Tom.

Re: [E-devel] e5: Call for VM

[ravenlock <ravenlock@ra...>]

On 2/8/13 9:29 AM, Tom Hacohen wrote:
> On 08/02/13 15:20, Leif Middelschulte wrote:
>> Am Freitag, 8. Februar 2013 um 09:45 schrieb Stefan Schmidt:
>>> Hello.
>>>
>>> On 08/02/13 04:29, Carsten Haitzler (The Rasterman) wrote:
>>>> On Thu, 07 Feb 2013 21:45:23 -0600 ravenlock <ravenlock@... (mailto:ravenlock@...)>
>>>> said:
>>>>
>>>>> On 2/7/13 8:35 PM, Carsten Haitzler (The Rasterman) wrote:
>>>>>> On Thu, 07 Feb 2013 09:35:07 -0600 ravenlock <ravenlock@... (mailto:ravenlock@...)>
>>>>>
>>>>>
>>>>
>>>> said:
>>>>>>
>>>>>>> On 1/30/13 5:32 AM, 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
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> What is the plan for licensing the above?
>>>>>>
>>>>>> someone needs to actually pay for a proper license/copy. there is no
>>>> way i
>>>>>> will allow us to use pirated copies of any software on our infra. if
>>>>>
>>>>
>>>> we ask
>>>>>> people to respect our licenses, be they bsd, gpl or anything else,
>>>>>
>>>>
>>>> then we
>>>>>> will respect theirs, regardless if they are open or not.
>>>>>
>>>>>
>>>>> I didn't propose pirating anything. Didn't know if we were hoping for
>>>>> people to purchase and donate copies, send in old decommissioned
>>>>> personal copies, if we were using E-funds or whatnot.
>>>>>
>>>>
>>>>
>>>> sure - i'm just making it clear, that any such vm's must be installed
>>>> "above
>>>> board" with legitimate licenses for the vm os's :)
>>>>
>>>
>>>
>>> This is kinda mood as nobody seems to actually want to setup and
>>> maintain these. I certainly will not touch windows for efl builds. And
>>> some point I would be willing to look into automated mingw64 build
>>> though, cross-compiled from Linux.
>>>
>>> I don't rule that somebody at some day may want to do this. But so far
>>> nobody showed up so we can happily ignore this.
>>>
>>>>>>>> (maybe more declination are needed ?)
>>>>>>>>
>>>>>>>> - Mac OS X Snow Leopard
>>>>>>>> - Mac OS X Lion
>>>>>>>> - Mac OS X Mountain Lion
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> This is easy and do'able if you have the Mac hardware and Parallels.
>>>>>>> Refurbed Mac Minis are like $500, you can stuff 16GB in them and a
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>> 1TB
>>>>>>> disk. Works perfectly well. Once upon a time there were E-funds
>>>>>>
>>>>>
>>>>
>>>> being
>>>>>>> held. We might tap into those?
>>>>>>
>>>>>>
>>>>>> he's asking for vm's, not hardware. we can't do squat diddly with a
>>>> mac
>>>>>> mini.
>>>>>
>>>>>
>>>>> If you desire osx, you'll be duct taping that Mac Mini to your rack
>>>>> mounted colo. ;)
>>>>>
>>>>
>>>>
>>>> which means its not going to happen. osx support in our buildbot/cluster
>>>> is not
>>>> an option until apple changes their licensing policies. so upstream
>>>> support ==
>>>> "whatever devs manage to do at home on their own machines if they have osx
>>>> boxen".
>>>>
>>>
>>>
>>> My personal opinion is that we should just ignore this as well. They
>>> don't want people to devel something else then iOS apps. So why should
>>> we help them with our time?
>>>
>>>
>>
>> I think that it's legal to run Mac OS Server in a virtual machine. But I'm not 100% sure about this. Maybe this information is outdated.
>>>
>>> A general idea we had was some way of having jenkins slaves that only
>>> report to the master. Leaving out the scary parts of a server
>>> controlling the PC in your home for doing the builds. I guess MacOSX
>>> would not care but I find it scary. :) Anyway, something like this is
>>> way down on my list. Way down.
>>>
>>>
>>
>> Sounds even better.
>>
>> --
>> Leif
>>>
>>> regards
>>> Stefan Schmidt
>>>
>>>
> 
> Someone mentioned something about being allowed to run mac on a vm for 
> open source software development. I'm not sure it's true though.

Per OSX Eula:
(iii) to install, use and run up to two (2) additional copies or
instances of the Apple Software within virtual operating system
environments on each Mac Computer you own or control that is already
running the Apple Software, for purposes of: (a) software development;
(b) testing during software development; (c) using OS X Server; or (d)
personal, non-commercial use.

<myInterpretation>
Must own "Mac Computer" already legally running "Apple Software" (i.e.
osx) with virtualization software on it... then you may install an osx vm.
</myInterpretation>

> 
> But as Stefan said, we were already thinking about having a way for 
> "people" to report build status. So we'll be able to have crazy setups, 
> like Mac OS, PS3 and etc.
> 
> --
> Tom.
> 
> 
> ------------------------------------------------------------------------------
> Free Next-Gen Firewall Hardware Offer
> Buy your Sophos next-gen firewall before the end March 2013 
> and get the hardware for free! Learn more.
> http://p.sf.net/sfu/sophos-d2d-feb
> _______________________________________________
> enlightenment-devel mailing list
> enlightenment-devel@...
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> 
> 

Re: [E-devel] e5: Call for VM

[Carsten Haitzler (The Rasterman) <raster@ra...>]

On Fri, 08 Feb 2013 12:12:44 -0600 ravenlock <ravenlock@...> said:

> On 2/8/13 9:29 AM, Tom Hacohen wrote:
> > On 08/02/13 15:20, Leif Middelschulte wrote:
> >> Am Freitag, 8. Februar 2013 um 09:45 schrieb Stefan Schmidt:
> >>> Hello.
> >>>
> >>> On 08/02/13 04:29, Carsten Haitzler (The Rasterman) wrote:
> >>>> On Thu, 07 Feb 2013 21:45:23 -0600 ravenlock <ravenlock@...
> >>>> (mailto:ravenlock@...)> said:
> >>>>
> >>>>> On 2/7/13 8:35 PM, Carsten Haitzler (The Rasterman) wrote:
> >>>>>> On Thu, 07 Feb 2013 09:35:07 -0600 ravenlock <ravenlock@...
> >>>>>> (mailto:ravenlock@...)>
> >>>>>
> >>>>>
> >>>>
> >>>> said:
> >>>>>>
> >>>>>>> On 1/30/13 5:32 AM, 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
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> What is the plan for licensing the above?
> >>>>>>
> >>>>>> someone needs to actually pay for a proper license/copy. there is no
> >>>> way i
> >>>>>> will allow us to use pirated copies of any software on our infra. if
> >>>>>
> >>>>
> >>>> we ask
> >>>>>> people to respect our licenses, be they bsd, gpl or anything else,
> >>>>>
> >>>>
> >>>> then we
> >>>>>> will respect theirs, regardless if they are open or not.
> >>>>>
> >>>>>
> >>>>> I didn't propose pirating anything. Didn't know if we were hoping for
> >>>>> people to purchase and donate copies, send in old decommissioned
> >>>>> personal copies, if we were using E-funds or whatnot.
> >>>>>
> >>>>
> >>>>
> >>>> sure - i'm just making it clear, that any such vm's must be installed
> >>>> "above
> >>>> board" with legitimate licenses for the vm os's :)
> >>>>
> >>>
> >>>
> >>> This is kinda mood as nobody seems to actually want to setup and
> >>> maintain these. I certainly will not touch windows for efl builds. And
> >>> some point I would be willing to look into automated mingw64 build
> >>> though, cross-compiled from Linux.
> >>>
> >>> I don't rule that somebody at some day may want to do this. But so far
> >>> nobody showed up so we can happily ignore this.
> >>>
> >>>>>>>> (maybe more declination are needed ?)
> >>>>>>>>
> >>>>>>>> - Mac OS X Snow Leopard
> >>>>>>>> - Mac OS X Lion
> >>>>>>>> - Mac OS X Mountain Lion
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> This is easy and do'able if you have the Mac hardware and Parallels.
> >>>>>>> Refurbed Mac Minis are like $500, you can stuff 16GB in them and a
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>> 1TB
> >>>>>>> disk. Works perfectly well. Once upon a time there were E-funds
> >>>>>>
> >>>>>
> >>>>
> >>>> being
> >>>>>>> held. We might tap into those?
> >>>>>>
> >>>>>>
> >>>>>> he's asking for vm's, not hardware. we can't do squat diddly with a
> >>>> mac
> >>>>>> mini.
> >>>>>
> >>>>>
> >>>>> If you desire osx, you'll be duct taping that Mac Mini to your rack
> >>>>> mounted colo. ;)
> >>>>>
> >>>>
> >>>>
> >>>> which means its not going to happen. osx support in our buildbot/cluster
> >>>> is not
> >>>> an option until apple changes their licensing policies. so upstream
> >>>> support ==
> >>>> "whatever devs manage to do at home on their own machines if they have
> >>>> osx boxen".
> >>>>
> >>>
> >>>
> >>> My personal opinion is that we should just ignore this as well. They
> >>> don't want people to devel something else then iOS apps. So why should
> >>> we help them with our time?
> >>>
> >>>
> >>
> >> I think that it's legal to run Mac OS Server in a virtual machine. But I'm
> >> not 100% sure about this. Maybe this information is outdated.
> >>>
> >>> A general idea we had was some way of having jenkins slaves that only
> >>> report to the master. Leaving out the scary parts of a server
> >>> controlling the PC in your home for doing the builds. I guess MacOSX
> >>> would not care but I find it scary. :) Anyway, something like this is
> >>> way down on my list. Way down.
> >>>
> >>>
> >>
> >> Sounds even better.
> >>
> >> --
> >> Leif
> >>>
> >>> regards
> >>> Stefan Schmidt
> >>>
> >>>
> > 
> > Someone mentioned something about being allowed to run mac on a vm for 
> > open source software development. I'm not sure it's true though.
> 
> Per OSX Eula:
> (iii) to install, use and run up to two (2) additional copies or
> instances of the Apple Software within virtual operating system
> environments on each Mac Computer you own or control that is already
> running the Apple Software, for purposes of: (a) software development;
> (b) testing during software development; (c) using OS X Server; or (d)
> personal, non-commercial use.
> 
> <myInterpretation>
> Must own "Mac Computer" already legally running "Apple Software" (i.e.
> osx) with virtualization software on it... then you may install an osx vm.
> </myInterpretation>

which means "not us"... so apple can go away until it changes its policies.

> > But as Stefan said, we were already thinking about having a way for 
> > "people" to report build status. So we'll be able to have crazy setups, 
> > like Mac OS, PS3 and etc.
> > 
> > --
> > Tom.
> > 
> > 
> > ------------------------------------------------------------------------------
> > Free Next-Gen Firewall Hardware Offer
> > Buy your Sophos next-gen firewall before the end March 2013 
> > and get the hardware for free! Learn more.
> > http://p.sf.net/sfu/sophos-d2d-feb
> > _______________________________________________
> > enlightenment-devel mailing list
> > enlightenment-devel@...
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> > 
> > 
> 
> 


-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster@...