pagurus has quit [Read error: Connection reset by peer]
pagurus has joined #mirage
andreas23 has quit [Quit: Leaving.]
Haudegen has joined #mirage
andreas23 has joined #mirage
argent_smith has joined #mirage
mort___ has joined #mirage
mort___ has quit [Quit: Leaving.]
mort___ has joined #mirage
mort___ has quit [Quit: Leaving.]
lobo has quit [Ping timeout: 245 seconds]
lobo has joined #mirage
Haudegen has quit [Remote host closed the connection]
mort___ has joined #mirage
mort___ has quit [Quit: Leaving.]
mort___ has joined #mirage
Haudegen has joined #mirage
mort___ has quit [Quit: Leaving.]
mort___ has joined #mirage
mort___ has quit [Quit: Leaving.]
mort___ has joined #mirage
mort___ has quit [Quit: Leaving.]
<lobo>
hannes: just parsed the meeting e-mail again. you wrote 16:00 utc in the e-mail and 16 bst is in the topic. but 16:00 bst would be 16:00 utc+1
<reynir>
It's usually at 17:00 in CEST/CET, lobo
<lobo>
reynir: mhh, maybe i'm just confused. i'll go and get another 0xc0ffee :)
<reynir>
I mean the meeting are usually at 17:00 :)
<lobo>
right :D
<reynir>
I'll be handing out vegetables by then :/
wildsebastian has joined #mirage
argent_smith has quit [Quit: Leaving.]
andreas23 has quit [Quit: Leaving.]
mcclurmc has joined #mirage
mcclurmc has quit [Client Quit]
<hannes>
lobo: i'm bad with timezoes.. i usually specify times in berlin time, and if i say sth else, i mean "the time in london atm"... so, 16:00 BST or 15:00 UTC is what i meant
<lobo>
hannes: np, that's what i've thought. just didn't want to write a mail to cause confusion on the ml :)
yomimono has joined #mirage
<mato>
yomimono: hey ho
<yomimono>
mato: hello!
<hannes>
hello
<mato>
hannes: you should update the channel topic :-)
<kensan>
We have been running https://muen.sk on Muen/Solo5 since last December and we really only restarted it to renew certificates :)
<hannes>
credits where credit's due
<mato>
kensan: good stuff! you should brag more about that :)
* mato
figured out ChanServ has a TOPICSWAP command that does exactly what was wanted
* hannes
has another 5 days to deploy+debug his let's encrypt stuff (that's when my blog LE cert expires)
<kensan>
hannes: Well compared to what everybody else did I am not sure to deserve such a "high level" mention ;)
<kensan>
mato: That is what I am doing now :)
<mato>
Sure you do, after all you did most of the work on the Muen port!
<kensan>
We have a tagline on the site with some links to Solo5 and MirageOS "This page is served by a MirageOS/Solo5 TLS unikernel running on Muen"
<hannes>
to move on in the agenda, there will be another retreat in marrakesh, from october 3rd -10th. registration is open, see http://retreat.mirage.io for details
<mato>
yes, we should start reaching out to some of the wider community folks we wanted to invite
<mato>
such as gianluca and wei chen
<mato>
also no idea if dan & ricarkol can make it again, but it would be nice
<hannes>
mato: yes! I think it would be good for solo5 people to gather there, maybe I/we should announce it on the solo5 list as well
<mato>
feel free to do that
<mato>
kensan: any chance you'll join us again in october?
<kensan>
mato: I will try to make it work. Not sure if for the whole retreat.
<kensan>
mato: Also reet may be coming as well.
<hannes>
kensan: \o/
<kensan>
He is the second half of the Muen/codelabs team ;)
<mato>
hooray
<kensan>
s/second/other/
<mato>
hannes: is there anyone else you think i should remind/approach separately?
<mato>
hannes: i can try and ping justincormack_, though i suspect his schedule is probably full already
<hannes>
mato: i guess nikhil ap and adam steen would be good to invite there as well.. yes, justin as well
<mato>
ok, i'll start making a list and sending out some emails.
<mato>
by the way, from what dan told me some time ago, i believe nikhil is in the process of applying for/sorting out an internship at ibm
<yomimono>
mato: awesome, thanks for doing that :D
<hannes>
that's good to hear! I found his fork+code on github
<mato>
dunno. yomimono: how's the xen backend re-work going?
<yomimono>
educational, therefore slow :P
<mato>
that's fine. i believe you decided to re-work atop unikraft rather than mini-os, how's that turned out?
<yomimono>
well, I wanted to see how much more work it would be to do that
<yomimono>
and it took a lot of work to find that out
<yomimono>
it turns out that a large piece (grant table support) was also being rewritten by someone else while I was looking at it
<yomimono>
some patches for that just landed on the unikraft mailing list a couple of days ago, so I'd like to check those out
<yomimono>
I have now two sort-of-working independent things: a port of the opam minios-xen package to the current upstream mini-os (distinct from unikraft)
<mato>
ah, nice. btw does unikraft have ARM support?
<yomimono>
and the build machinery for porting the build to unikraft + ocaml-freestanding (but not working builds)
<yomimono>
mato: yes
<yomimono>
for arm32
<mato>
yup
<mato>
by the first thing, you mean a new minios-xen package based on upstream mini-os?
<yomimono>
mato: yep
<yomimono>
it allllllllllmost works
<mato>
but without the corresponding ocaml-freestanding glue, right?
<yomimono>
mato: correct
<mato>
so essentially the existing backend code + new mini-os
<yomimono>
that's enough (I think - I haven't confirmed this and there are some build system things to work out) to get us PVH support
<yomimono>
mato: correct
<mato>
right, so that may be a feasible interim step, though tbh I really wanted most of the old xen backend code to die :-)
<yomimono>
yes, me too!
<mato>
(the mess that is in mirage-xen that is)
<yomimono>
I would really like not to have that sitting around to maintain anymore
<mato>
anyway, that all sounds like progress, so good news :-)
<yomimono>
yes, although I wanted to ask you some questions about ocaml-freestanding
<mato>
please do
<hannes>
sounds like good progress imho :D
<yomimono>
would it be possible to project several ocaml packages for each backend, like ocaml-freestanding-virtio, etc, so that they'd be coinstallable?
<yomimono>
I didn't immediately see a reason not to do this when hacking around in there
<mato>
hmm
<yomimono>
(sorry, should've said "project several ocaml packages, one for each target" or something like that)
<mato>
maybe, i'm not sure. every time i started thinking about that problem (and conversely the existence of solo5-kernel-* which are NOT coinstallable), i got stuck.
<mato>
how would coinstallability help you?
<hannes>
ocaml-freestanding installs a .pc file -- now having N ocaml-freestanding would require to duplicate/take N mirage-solo5 packages as well, no? because otherwise who'd know which pc file to use?
<yomimono>
I've wanted it more in day-to-day mirage'ing because I like to test stuff for multiple backends, but in this case it's actually that the dependency on the underlying target isn't explicit
<mato>
I use multiple switches for that. Or just deal with the remove/install/recompile.
<yomimono>
mato: yeah, I use multiple switches for this as well, but it means more software installs and updates, kind of a bummer
<yomimono>
none of it is impossible to work around
<mato>
Even today e.g. Xen, Solo5 and UNIX are not coinstallable, right?
<yomimono>
they are
<mato>
Not for the whole stack? I thought there was still a mirage-no-xen or something that parts of the stack ended up installing
<mato>
Or has that been fixed?
<yomimono>
that's true for parts of the stack that involve entropy/crypto IIRC?
<mato>
Anyway, I still think (pending inspiration) that "effort of fixing this" > "effort to work around it"
<yomimono>
but I think if you've had mirage-xen you can still build for unix without it being horrible
<mato>
Yes, it was crypto that I was thinking of.
<yomimono>
hannes: to your point about N mirage-solo5 packages, I think that's correct
<yomimono>
so I'm happy to put this in the "not impossible but irritatingly fiddly with current tools" bucket
<mato>
ack. is there anything else you wanted to ask re ocaml-freestanding?
<yomimono>
that's it
<yomimono>
thanks :)
<hannes>
the mirage-no-xen / mirage-no-solo5 are hacks to specify the dependencies of nocrypto, as: either there's a mirage-solo5 AND as well a gmp-freestanding AND as well a zarith-freestanding __OR__ no mirage-solo5 at all (similar for xen)
<mato>
yeah, if OPAM had e.g. virtual packages as in Debian then we wouldn't need those hacks (where N real packages can "Provide" a virtual one)
<mato>
some of those hacks, anyway
<hannes>
that is true. i'm not entirely sure whether virtual / provides is part of opam2 (i think not)
<mato>
I think some of this can also be further improved if we go down replacing pkg-config with OPAM 2 per-package variables, but that then leaves us with the problem of supporting OPAM 1...
mort___ has joined #mirage
<hannes>
I'd suggest to get rid of opam1 once opam2 is released, and mirage could do so by simply not supporting it..
<yomimono>
no opposition here!
<mato>
well, not *immediately+ after opam 2 is released, but at some not too distant point, that might be a way to go
<hannes>
not immediately, but "whenever someone gets around to rewrite parts of mirage", and opam2 is released, I'd be happy to just drop support
<hannes>
maybe too many ifs in there... any other topics for today? :)
mort___1 has joined #mirage
mort___ has quit [Ping timeout: 245 seconds]
<hannes>
doesn't look like, thanks for attending! let's meet again in 2 weeks! :)
<mato>
looks like that's it
<mato>
yup
<yomimono>
\o/ thanks for getting these going again, hannes!
<mato>
+1
Haudegen has quit [Remote host closed the connection]