Re: [MirageOS-devel] cubieboard2/truck users and opam 1.2

[Anil Madhavapeddy <anil@xxxxxxxxxx>]

On 3 Nov 2014, at 09:12, Thomas Leonard <talex5@xxxxxxxxx> wrote:
> 
> On 3 November 2014 00:02, Anil Madhavapeddy <anil@xxxxxxxxxx> wrote:
>> That should work, but it's always better to grab the binary compiled on the
>> target distro if at all possible.  The PPA remote will also give you all the
>> other binaries (like opam-admin) which aren't essential for basic usage, but
>> will get pretty confusing if you try to use an older opam-admin in the
>> future.
> 
> By the way, it would be slightly more convenient for 0install too if
> these were sub-commands ("opam installer" vs "opam-installer"), since
> "0install add" has the user provide the top-level command name. This
> is for security reasons, so that packages can't add commands to the
> user's PATH without an explicit request from the user.

Doesn't git have problems with 0install as well then?  The extension
mechanism is the same -- multiple binaries with <base>-<extension> that
are looked up by the <base> command in the path.

Munging all the commands into the mainline binary will eventually break
something that can't be linked, such as the opam-installext shell script.

> 
> I'll try to get the OPAM 0install binaries updated to 1.2 from
> 1.2-beta4 soon too.

Great!

-anil

> 
>> -anil
>> 
>> 
>> On 2 Nov 2014, at 23:56, Luke Dunstan <lukedunstan81@xxxxxxxxx> wrote:
>> 
>> A week ago I started using this binary:
>> https://github.com/ocaml/opam/releases/download/1.2.0/opam-1.2.0-armv7l-Linux
>> 
>> I just renamed it to "opam" and put it in a directory that is earlier in
>> PATH than /usr/bin. It seems to work fine, but is there any reason why this
>> might cause problems?
>> 
>> Luke
>> 
>> 
>> On 3 November 2014 06:50, Anil Madhavapeddy <anil@xxxxxxxxxx> wrote:
>>> 
>>> 
>>> On 2 Nov 2014, at 22:46, David Scott <scott.dj@xxxxxxxxx> wrote:
>>> 
>>> 
>>> 
>>> On Sun, Nov 2, 2014 at 8:57 PM, Anil Madhavapeddy <anil@xxxxxxxxxx> wrote:
>>>> 
>>>> For Cubieboard2 users, the Launchpad OPAM builds do end up with armhf
>>>> images, but you can't use the PPA commands since the distribution template
>>>> of our Cubie image is 'Linaro' instead of 'Ubuntu' (not sure why we can't
>>>> just switch to a pure Ubuntu or Debian image).
>>>> 
>>>> Anyway, these four simple commands will get you OPAM 1.2.0 without having
>>>> to do a source compilation, as root:
>>>> 
>>>> echo "deb http://ppa.launchpad.net/avsm/ocaml41+opam12/ubuntu trusty
>>>> main"  > /etc/apt/sources.list.d/ppa-opam.list
>>>> apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 5B2D0C5561707B09
>>>> apt-get update
>>>> apt-get upgrade
>>> 
>>> 
>>> This worked nicely for me. I was able to (from memory, hope I've not
>>> typo'ed it)
>>> 
>>> opam init
>>> eval `opam config env`
>>> opam remote add mirage-dev git://github.com/mirage/mirage-dev
>>> opam install mirage
>>> git clone git://github.com/mirage/mirage-skeleton
>>> cd mirage-skeleton
>>> MODE=xen make configure
>>> MODE=xen make build
>>> 
>>> and all the examples built ok.
>>> 
>>> 
>>> Coincidentally, the same as
>>> https://github.com/mirage/is-mirage-broken/blob/master/scripts/build_mirage
>>> !
>>> 
>>> -anil
>>> 
>>> 
>>> _______________________________________________
>>> MirageOS-devel mailing list
>>> MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
>>> http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel
>>> 
>> 
>> 
>> 
>> _______________________________________________
>> MirageOS-devel mailing list
>> MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
>> http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel
>> 
> 
> 
> 
> -- 
> Dr Thomas Leonard        http://0install.net/
> GPG: 9242 9807 C985 3C07 44A6  8B9A AE07 8280 59A5 3CC1
> GPG: DA98 25AE CAD0 8975 7CDA  BD8E 0713 3F96 CA74 D8BA


_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel