09:48 <kishore> if i start to build github.com/mirage/mirage - ocamlfind complains that it can find "mirage-protocols", i assume i have to build them separate.

09:48 <kishore> i poked mirage.io, and github.com/mirage/mirage, i couldn't find instructions on "Building mirage from source"

09:48 <kishore> Where can i find them ?

09:50 <kensan> mato: I have a question regarding the mirage patch for Muen: https://github.com/codelabs-ch/mirage/commit/e3a8d55

09:52 <kensan> mato: Since there are version dependencies on solo5-kernel etc it means that a versioned solo5 release must exist before submitting that change, right?

10:13 <mato> kensan: Yeah, it's tricky and the Solo5 packages are a bit weird. I need to think about it and possibly write an email to the mirage list.

10:15 <mato> kensan: In theory, if users follow the standard instructions of "mirage configure -t muen; make depend" then with the current setup (what you have in your patches) the depend step will just fail if no solo5-kernel-muen package is available. However, there should be a clearer way of expressing those dependencies. Possibly just adding a versioned dependency on the a release of mirage-solo5 with your changes is

10:15 <mato> enough. Not sure.

10:21 <kensan> mato: Ok, thanks for the info.

10:21 <kensan> mato: I am trying to build for solo5-kernel-muen using mirage but somehow "make depend" craps out on me with the rebased patches.

10:22 <kensan> mato: mirage does not seem to see that solo5-kernel-muen is a viable option as a dependency to ocaml-freestanding besides ukvm and virtio.

10:26 <mato> kensan: Yeah, you need to pin ocaml-freestanding with the updated metadata for that to work (the | dependency on solo5-kernel-muen)

10:26 <mato> kensan: So yes, ocaml-freestanding will need a new release.

10:27 <kensan> mato: I have a pin for ocaml-freestanding. Explicitly installing it seemed to have helped.

10:28 <kensan> mato: Ok, I think I get it now. The chain looks like: Solo5 patches-> new solo5 version/release, ocaml-freestanding patches -> new ocaml-freestanding version/release

10:29 <kensan> mato: mirage patches referencing new versions as min for muen.

10:30 <hannes> the problem afaics is that opam packages pinned/pointing to dev repos still have the same version number... and thus while we can express ">0.2.1", the dev-repo won't suffice (but only a new release will)

10:34 <kensan> hannes: Ah, I see.

10:36 <mato> kensan: Yeah, that chain *should* be enough.

10:36 <hannes> so, atm (released) mirage will bail at -t muen, but once we have that released, the muen backend can depend (in mirage.ml) onto solo5-kernel-ukvm >= 0.3 (or whichever versions are good)

10:37 <mato> kensan: Since mirage-solo5 depends on ocaml-freestanging.

10:37 <mato> hannes: no, Muen uses a separate solo5-kernel-muen package

10:37 <hannes> mato: sounds good to me :)

10:38 <mato> hannes: hannes So, once a solo5-kernel-muen package is released to OPAM I can make a new ocaml-freestanding release (adding "| solo5-kernel-muen" to its dependencies) and that should be all that's required. Once a version of mirage with -t muen is released to opam things will just work.

10:39 <mato> hannes: The proliferation of solo5-kernel-xxx packages is not ideal but i see no straightforward fix for that right now.

10:39 <mato> lunch, biab

10:46 <hannes> mato: that sounds good to me... and yes, the exploding solo5-kernel-x is not nice atm.. but we need bits from that (well, compiler+linker flags?) for ocaml-freestanding, don't we?

11:11 <mato> hannes: Yeah. I don't think the exploding kernel packages can be fixed w/o some reconstruction of how the pkg-config flags are passed around.

11:12 <mato> hannes: An unfortunately I don't have enough bandwidth right now to figure out a solution.

11:14 <hannes> mato: i think it is fine for now :)

11:14 <hannes> (I've negative bandwidth and am ear-sick)

11:55 <mato> kensan: So, following the instructions in the Muen PR, is this command still what I want to test a Solo5 unikernel:

11:55 <mato> make SYSTEM=xml/mirage-solo5.xml emulate COMPONENTS="libmutime libdebuglog sm time dbgserver"

11:55 <mato> (adding NO_PROOF=true to that)

12:01 <mato> ...trying test_hello, it's hard to tell whether bochs is just insanely slow or stuck.

12:02 <mato> kensan: ... so, i think i may just merge the PR without actually testing it since it takes too much time :-(

12:02 <mato> and I don't want to block the PR

12:03 <kensan> mato: Have a look at emulate/serial.out

12:03 <kensan> mato: or try tools/scripts/mulog-subject.py 3 emulate/serial.out

12:03 <mato> kensan: ah, that was not obvious, i was looking for something on the console :)

12:03 <kensan> mato: You should see the log output

12:03 <kensan> mato: No the screen will stay as is :)

12:03 <kensan> mato: only serial output.

12:04 <mato> ok, that seems to work

12:04 <kensan> mato: Sorry, was away for lunch.

12:04 <kensan> mato: time, block and ping cannot be tested with Bochs but the others should be fine.

12:05 <kensan> mato: cool!

12:05 <mato> ok, I just wanted to test "something" to see if things work

12:11 <kensan> mato: When I get some time I will look at setting up Docker image for building Muen.

12:12 <mato> kensan: FYI, randomly tried to boot emulate/muen.iso under nested KVM, does not work (not that I expected it to)

12:13 <mato> kensan: Anyhow, bochs will do, now that I know where to find the output.

12:13 <kensan> mato: Ok, thanks for trying.

12:14 <kensan> mato: What Linux kernel version did you try?

12:14 <mato> kensan: 4.11 on a Broadwell NUC (NUC5i7RYB)

12:15 <kensan> mato: Ah right.

12:15 <mato> kensan: With "qemu-system-x86_64 -machine q35 -enable-kvm -cpu host,+invtsc,migratable=no -m 2048 -smp 2 -nographic -cdrom emulate/muen.iso" gets as far as "I/O APIC RTE 01: ..." and then appears to hang.

12:21 <kensan> mato: ok.

12:27 <mato> Argh.

12:27 <mato> kensan: So I thought for a moment that ocaml-freestanding no longer builds on Debian stretch, but it turns out that adding gnat and spark to my $PATH makes bits of the build pick up some ancient wrong gcc provided by gnat.

12:28 <kensan> mato: Yeah, that's a bit unfortunate and confusing...

12:30 <mato> kensan: Apart from using Docker images, a workaround might be to have some Makefile parameters that can be set to point to GNAT and SPARK w/o having to muck with $PATH....?

12:33 <kensan> mato: will have to think about that.

12:34 <mato> kensan: How did it build for you? Do you just set the $PATH for only the shell you're building Muen in?

12:34 <mato> (the PATH with the wrong gcc in it)

12:34 <kensan> mato: I am building Mirage in a different shell.

12:34 <mato> ok, that explains it

12:34 <kensan> mato: I have an file I source for Muen development.

12:35 <mato> ack

13:12 <mato> kensan: Ok, I've rebuilt the various affected OPAM switches, added the pins, however the result of "mirage configure -t muen" in mirage-skeleton/tutorial/hello doesn't build for me. Is that the same for you?

13:12 <mato> (before I go and investigate what's wrong with it...)

13:18 <kensan> mato: let me try again

13:18 <kensan> mato: I just did it for static_website_tls before

13:19 <kensan> mato: It builds for me...

13:20 <kensan> mato: I am on Debian stable

13:20 <kensan> mato: What error do you get?

13:22 <mato> kensan: Does "make depend" work for you?

13:22 <kensan> mato: yes.

13:23 <mato> kensan: Is this with a recently run "opam update"?

13:24 <mato> For me make depend just produces my least favourite opam error "Sorry, no solution found" with no extra information

13:24 <kensan> mato: yes, but let me give it another shot

13:25 <kensan> mato: Yeah, works for me.

13:25 <mato> Ugh

13:26 <kensan> mato: Do you have aspcud installed?

13:26 <mato> yup

13:26 <mato> kensan: With these pins?

13:26 <mato> mirage.3.0.2 git git://github.com/codelabs-ch/mirage#muen

13:26 <mato> ocaml-freestanding.0.2.1 git git://github.com/codelabs-ch/ocaml-freestanding#muen

13:26 <mato> solo5-kernel-muen.~unknown git git://github.com/codelabs-ch/solo5#muen

13:27 <kensan> mato: Ah, I have a few packages to update

13:27 <kensan> mato: I have them pinned locally.

13:27 <kensan> mato: hold on.

13:28 <kensan> mato: I had a local fix

13:28 <kensan> mato: pushed it just now.

13:28 <kensan> mato: To mirage that is.

13:33 <mato> kensan: ok, that helped. the "hello" example now works.

13:33 <mato> (the mirage one that is)

13:34 <mato> kensan: i only see the first message from hello -- there's a 1 second sleep in between them. is that due to time flowing slowly in bochs?

13:35 <kensan> mato: Yeah, execution is quite slow in Bochs due to emulation.

13:36 <mato> kensan: Ok, I think this will do for the purposes of verifying that things work for now.

13:36 <kensan> mato: But do you see the whole log output?

13:36 <mato> kensan: No

13:36 <mato> kensan: Nothing after the first message

13:37 <mato> kensan: https://zerobin.net/?cfa8f3a1937891a7#Jn5lFfq1pF61eRl9ngv5PVYPBC6pEyN3yD75Wu0Hupk=

13:38 <kensan> mato: ah yeah that's because of the timer.

13:43 <mato> kensan: Is that not functional / due to the bochs emulation being slow?

13:44 <kensan> mato: Time passing is very inaccurate

13:44 <kensan> plus emulation is very slow.

13:45 <mato> ok.

13:45 <kensan> mato: Its the same situation as with test_time.

13:46 <mato> kensan: Alright, I think this means we can merge the Muen PR, I'll add some comments to Github about the next steps.

13:47 <kensan> mato: btw, you can filter the log output using tools/scripts/mulog-subject.py 3 emulate/serial.out

13:47 <kensan> mato: This will only show the output from logchannel #3.

13:47 <kensan> mato: Cool! \@/

14:25 <kensan> mato: I opened a PR for ocaml-freestanding.

14:28 <mato> kensan: thanks. I'll probably move that last comment on #190 into a [meta] tracking issue so as not to have it sitting in a "closed" PR.

14:30 <kensan> mato: Ok, thank you.

14:48 <mato> kensan: Done.

14:49 <mato> kensan: Thx for the PR. Will look at it in $TIME.

14:49 <mato> kensan: Random question, since you already use some NUCs for testing Muen, do you think it'd be hard to get it to boot on a 5i7RYH? Asking since I have one of those spare as a bare metal test box.

14:57 <kensan> mato: No, I think it should be fairly straight forward.

14:57 <kensan> mato: for arbitrary values of $fairly ;)

14:57 <mato> :-)

14:58 <kensan> mato: You would need to generate a hardware config. The easiest way to do this is by running the mugenhwcfg tool from a running Linux system.

14:59 <kensan> mato: https://git.codelabs.ch/?p=muen/mugenhwcfg.git

15:03 <kensan> mato: Then copy the generated output.xml file to policy/hardware/intel-nuc-5i7ryh.xml

15:04 <kensan> mato: and add a corresponding platform config which is probably the same as for the 5i5MYHE NUC.

15:05 <kensan> mato: So cp policy/platform/intel-nuc-5i5myhe.xml policy/platform/intel-nuc-5i7ryh.xml

15:05 <kensan> mato: Maybe you have to make minor changes to the generated hardware xml.

15:06 <kensan> mato: If all is there: make HARDWARE=hardware/intel-nuc-5i7ryh.xml SYSTEM=xml/mirage-solo5-net.xml NO_PROOF=true iso

15:10 <lobo> hannes: get well soon. looking forward to some interesting blog posts :-)

15:40 <hannes> lobo: thx, it's already getting a bit better

15:40 <hannes> (and tomorrow off to germany)

15:42 <apache2> I have some build failing because of xen-gnt.unix /43

15:42 <apache2> oops

15:42 <apache2> xen-gnt.unix missing, does anyone know what this is?

15:44 <yomimono> ocaml-gnt got a jbuilder port earlier this week, which might have caused some carnage

15:44 <yomimono> possibly there's now a xen-gnt-unix

15:44 <yomimono> yep

15:45 <yomimono> apache2: can you file an issue on mirage/mirage if these are builds of mirage itself, or `make depend` from a `mirage configure`?

15:54 <apache2> OB[ERROR] The compilation of vchan.2.3.0 failed.

15:55 <apache2> this is the pkg that complains about missing en-gnt.h

15:55 <apache2> xen-gnt.unix sorry

15:58 <yomimono> apache2: yeah, it looks like vchan wasn't ever aware that xen-gnt could be built without unix sublibrary, if I'm inferring correctly from `opam info`

16:02 <apache2> :(

16:05 <yomimono> I need to go AFK for a little bit but I'll have a look at it when I get back - might be quicker to file an issue on ocaml-vchan in case someone else is around to fix

16:07 <apache2> yomimono: thank you!!!

16:07 <hannes> apache2: to get it up and running, you can opam pin xen-gnt 2.2.3 .. and "downgrade" to this known working (before jbuilder split all the packages and broke sth)

16:11 <apache2> thank you!

16:11 <apache2> yeah this jbuilder wild west upgrading thing... :(

16:49 <yomimono> hannes: thanks, I realized two seconds after closing the laptop I should have said that ^_^;

16:58 <hannes> yomimono: nw