Re: [MirageOS-devel] Random thought for an OPAM feature

2015-06-04 Thread Thomas Gazagnaire
> One of the problems with doing a Mirage release is the sheer number of > often-interdependent packages that need releasing at once, and the > lack of a way to do so atomically. The inevitable breakage seems to > cause considerable pain if you're unlucky enough to be doing something > else at the

Re: [MirageOS-devel] cubie2 arm image loses mac

2015-06-04 Thread Nick Betteridge
> Try running > > xe sr-list > This is what I got: sudo xe sr-list uuid ( RO): a0ceb329-83cb-d074-50d9-53846aa40ff7 name-label ( RW): XenServer Tools name-description ( RW): XenServer Tools ISOs host ( RO): cubieboard2 type ( RO): i

Re: [MirageOS-devel] cubie2 arm image loses mac

2015-06-04 Thread Dave Scott
> On 4 Jun 2015, at 18:00, Nick Betteridge wrote: > > Excellent, they both compile, but I'm getting an error with the upload: > > ./dns.xe > Uploading VDI containing unikernel > result = [ version="1.0"?>StatusSuccessValueOpaqueRef:da16d417-e6d1-c55f-1957-5f2e169d44ff] > result = [ version="1.0

Re: [MirageOS-devel] cubie2 arm image loses mac

2015-06-04 Thread Nick Betteridge
Excellent, they both compile, but I'm getting an error with the upload: ./dns.xe Uploading VDI containing unikernel result = [StatusSuccessValueOpaqueRef:da16d417-e6d1-c55f-1957-5f2e169d44ff] result = [StatusSuccessValueOpaqueRef:02d446ef-7760-6096-09cd-909e82b9d706] result = [StatusSuccessValueOp

Re: [MirageOS-devel] cubie2 arm image loses mac

2015-06-04 Thread Dave Scott
> On 4 Jun 2015, at 17:16, Nick Betteridge wrote: > > > > Try > > > > opam pin add mbr-format git://github.com/djs55/ocaml-mbr#release.0.3 > > opam pin add xe-unikernel-upload > > git://github.com/djs55/xe-unikernel-upload#new-mirage-interfaces > > > > I have built these but not tested them.

Re: [MirageOS-devel] cubie2 arm image loses mac

2015-06-04 Thread Nick Betteridge
> Try > > opam pin add mbr-format git://github.com/djs55/ocaml-mbr#release.0.3 > opam pin add xe-unikernel-upload > git://github.com/djs55/xe-unikernel-upload#new-mirage-interfaces > > I have built these but not tested them. Let me know if they work for you and > I’ll try to release them into

Re: [MirageOS-devel] cubie2 arm image loses mac

2015-06-04 Thread Dave Scott
> On 4 Jun 2015, at 09:49, Nick Betteridge wrote: > > Beaten to it by Dave. > > While we're taking about api on cubie, trying to install xe-unikernel-upload > wants me to downgrade an awful lot of packages. I really don't want to > downgrade from mirage 2.5 to 2.1 - whats the best way of tack

Re: [MirageOS-devel] Random thought for an OPAM feature

2015-06-04 Thread Thomas Gazagnaire
> > I think the main source of trouble is that some repositories are not > packaged and thus it is not obvious which are their dependencies: > - - mirage-skeleton/mirage-www: should it work with > mirage-as-released-in-opam? or the development repo mirage-dev? or > master from various packages? >

Re: [MirageOS-devel] Random thought for an OPAM feature

2015-06-04 Thread Hannes Mehnert
-BEGIN PGP SIGNED MESSAGE- Hash: SHA384 Hi, On 06/04/2015 08:49, Thomas Gazagnaire wrote: > Libraries in mirage-dev are in flux and people using it should > expect breakage -- reporting these breakages on the list or on > GitHub is *very* useful to converge to a stable state. Once > stabi

Re: [MirageOS-devel] Random thought for an OPAM feature

2015-06-04 Thread Daniel Bünzli
Le jeudi, 4 juin 2015 à 11:34, Richard Mortier a écrit : > I think what I'm really saying is: a lightweight way to request a > consistent set of packages without needing to setup a dev opam repo. I think this is tracked by https://github.com/ocaml/opam/issues/1734 Daniel __

Re: [MirageOS-devel] Random thought for an OPAM feature

2015-06-04 Thread Richard Mortier
On 4 June 2015 at 08:49, Thomas Gazagnaire wrote: >> A thought occurred that one way for users to deal with this relatively >> straightforwardly might be to add the ability for opam to pin packages >> based on a datetime. We might then announce that a release was >> in-progress, and anyone who car

Re: [MirageOS-devel] cubie2 arm image loses mac

2015-06-04 Thread Nick Betteridge
Beaten to it by Dave. While we're taking about api on cubie, trying to install xe-unikernel-upload wants me to downgrade an awful lot of packages. I really don't want to downgrade from mirage 2.5 to 2.1 - whats the best way of tackling this? Cheers Date: Thu, 4 Jun 2015 09:40:20 +0100 Subject:

Re: [MirageOS-devel] cubie2 arm image loses mac

2015-06-04 Thread Nick Betteridge
Thanks for the input, I normally set up the board with a static ip address so that I can find it easily - I'll ask on the xapi list. ___ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://list

Re: [MirageOS-devel] cubie2 arm image loses mac

2015-06-04 Thread David Scott
On Thu, Jun 4, 2015 at 9:31 AM, Thomas Leonard wrote: > On 4 June 2015 at 09:22, Nick Betteridge > wrote: > > Each time I fire up a '2 and leave it on overnight and then try and ssh > into > > the board the following morning, I get a no route to host. Doing an arp > on > > my machine will list t

Re: [MirageOS-devel] cubie2 arm image loses mac

2015-06-04 Thread Thomas Leonard
On 4 June 2015 at 09:22, Nick Betteridge wrote: > Each time I fire up a '2 and leave it on overnight and then try and ssh into > the board the following morning, I get a no route to host. Doing an arp on > my machine will list the ip address but default to a 0:0:0:0:0:0 mac > address. Incidentally

[MirageOS-devel] cubie2 arm image loses mac

2015-06-04 Thread Nick Betteridge
Each time I fire up a '2 and leave it on overnight and then try and ssh into the board the following morning, I get a no route to host. Doing an arp on my machine will list the ip address but default to a 0:0:0:0:0:0 mac address. Incidentally, all of the running unikernels on the board are still

Re: [MirageOS-devel] Random thought for an OPAM feature

2015-06-04 Thread Thomas Gazagnaire
> A thought occurred that one way for users to deal with this relatively > straightforwardly might be to add the ability for opam to pin packages > based on a datetime. We might then announce that a release was > in-progress, and anyone who cared could pin all packages to some > "safe" time before