<avsm>
#499 remains under risk "make it possible to specify package version constraints for unikernels"
<avsm>
I've been stuck in a deep hole of build rule rewrites, so not had a chance to look at it yet
<avsm>
how big a disaster is it if it doesnt land for 3.0 yomimono?
<hannes>
I'd claim it to be a blocker since only that allows us to specify the supported versions of the mirage tool (and types) of unikernels... if we don't have that, users will get strange errors trying to compile sth with an older unsupported tool suite
<yomimono>
avsm: there's minimal risk to human life or limb, but I think the number of questions/complaints we get that boil down to version incompatibilities will increase as we get more users
<yomimono>
avsm: it's a common thing that people bounce off of & a really big stumbling block imo
<avsm>
Yeah, it feels like this should be a release blocker
<avsm>
Lets leave it there at the very top of that issue until it gets sorted :)
<avsm>
Most of the effort recently has been on mirage-types
<avsm>
There are a few more things to merge that are all discussed on their relevant tickets well, but is there anything burning there for anyone?
<avsm>
The big change that is quite mechanical is renaming V1 to something else, but that can be done fairly easily in one pass through all the libraries.
<avsm>
I have a large rewrite of mirage-platform to use topkg, and am splitting out the C build rules into a separate mirage-build package
<yomimono>
I want to do that right before we tag the release
<yomimono>
avsm: that's great to hear!
<avsm>
this should make solo5 and xen coinstallable, since their stubs will be built separately
<avsm>
Also, I am eliminating use of -pack in favour of module aliases as I do this, so unikernel binary sizes should reduce.
<hannes>
avsm: great!
<hannes>
well, moving C bindings out of mirage-platform to the subsequent libraries, topkg all the things... should be good!
<mato>
avsm: I've not yet had time to look at your build rule changes for mirage-platform, hopefully we can sit down together when you're in Berlin an go over it?
<avsm>
mato: yes definitely! I'm aiming to do more work on it on the plane; I discovered a bunch of rules I wrote a few years ago in mirage-platform that I can grab unmodified :)
<avsm>
I think mirage-solo5/xen coinstallability should be a release blocker as well, since it makes generating documentation very difficult otherwise
<mato>
Regarding Solo5, all things are mostly on track, my only concern is the stability of virtio drivers which is still not 100% on FreeBSD/bhyve
mort___ has quit [Quit: Leaving.]
<avsm>
docs.mirage.io is going well -- I've been using it day-to-day now! There are currently some build failures, but it's a useful linting tool to make sure mirage-dev is building
<avsm>
mato: great, I'd also like to deploy the infrastructure using solo5 next week. The blocker is just moving https://github.com/mirage/mirage-www/pull/493 into production (4.03 builds)
<avsm>
So, in terms of contributions, one _very useful_ thing to do for anyone wishing to contribute is to start porting libraries in http://docs.mirage.io that do not use topkg to use it
<hannes>
your ci asks me for a password
<avsm>
hannes: hm, must be a revproxy. I'll disable the password shortly...
<amirmc>
I get a certificate invalid error
<avsm>
it's a self-signed certificate
<avsm>
it's only a development deployment atm, it might be easier if i shift it a letsencrypt mirage.io VM instead
<mattg>
avsm: i will see about porting some libs to topkg
<avsm>
Drup: but I'm finding that a general refresh of the packaging is quite useful for many libraries to speed up builds, shift to module aliases instead of pack, and publish per-library docs. The topkg workflow is quite pleasant to work with
<hannes>
avsm: if you've general guidelines how to build C stubs (now that we have xen, unix, solo5) -- I suspect that'd be useful
<avsm>
hannes: thanks!
<avsm>
hannes: yes I will put full docs on it once it works :-) should be next week
<Drup>
avsm: As usual, the second rewrite is always better.
yomimono has joined #mirage
<avsm>
Drup: yeah there's nothing wrong with oasis -- topkg just collapses a few of the layers and is simpler
<avsm>
having an oasis plugin for odig would be very handy indeed
<Drup>
avsm: I won't argue about that here, I already expressed my opinion on other places. I just wanted to point out that doing this could probably be more far-reaching to the wider ocaml ecosystem.
<avsm>
Drup: sure... as I said, an oasis/odig plugin would be welcome
<hannes>
is there a rough target date for the 3.0 release?
<yomimono>
one week ago, then this week... so... uh...
<hannes>
ah 'next wednesday'... well played ;)
<yomimono>
when it's ready
<yomimono>
real soon now
<avsm>
In terms of release schedules, it looks like we'll have to delay the release to get all these interface changes in. A bunch of us will be in Berlin on Saturday, so I'd suggest projecting a realistic date for next week. Can be discussed on the list
<avsm>
We're in good shape in that the mirage-dev trunks make it much easier to bulk test changes now
<avsm>
(as opposed to finding breakages in an released package, having to fork it to mirage-dev, etc etc)