avsm changed the topic of #mirage to: mirage 2 released! party on!
<hannes> will MacOSX < yosemite be a valuable target for MirageOS3? (I've no clue how old this MacOSX is)
<yomimono> I think yosemite is... 10.8? and they're on 10.12 now?
<yomimono> My guess would be no. Is that the only thing we use the MacOSX target for?
<yomimono> (no, surely not, there's the vmnet stuff too)
<yomimono> the osx names got harder to remember when they stopped being cats
<hannes> no. the `MacOSX is used for > (or >=) yosemite
<hannes> but there's a bunch of code just to find out that the minor version of the whatever will be ok
<hannes> but i wanted to sleep i think
<yomimono> go sleep, it will still be crufty in the morning probably
<yomimono> and if not, that's even better
yomimono has quit [Ping timeout: 258 seconds]
yomimono has joined #mirage
yomimono has quit [Ping timeout: 244 seconds]
rgrinberg has quit [Ping timeout: 260 seconds]
brson has quit [Quit: leaving]
noddy has quit [Ping timeout: 265 seconds]
noddy has joined #mirage
insitu has joined #mirage
insitu has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
insitu has joined #mirage
demonimin has quit [Remote host closed the connection]
andreas23 has joined #mirage
andreas231 has joined #mirage
demonimin has joined #mirage
andreas23 has quit [Ping timeout: 265 seconds]
copy` has quit [Quit: Connection closed for inactivity]
fgimenez has joined #mirage
fgimenez has quit [Changing host]
fgimenez has joined #mirage
AltGr has joined #mirage
fgimenez has quit [Ping timeout: 268 seconds]
fgimenez has joined #mirage
mort___ has joined #mirage
mort___1 has joined #mirage
mort___1 has quit [Client Quit]
mort___ has quit [Ping timeout: 240 seconds]
smkz has quit [Quit: x]
smkz has joined #mirage
jermar has joined #mirage
mort___ has joined #mirage
smkz has quit [Client Quit]
smkz has joined #mirage
noddy has quit [Ping timeout: 256 seconds]
noddy has joined #mirage
demonimin has quit [Remote host closed the connection]
insitu has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
fgimenez has quit [Ping timeout: 245 seconds]
fgimenez has joined #mirage
fgimenez has joined #mirage
fgimenez has quit [Changing host]
insitu has joined #mirage
demonimin has joined #mirage
insitu has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
copy` has joined #mirage
abeaumont has quit [Ping timeout: 252 seconds]
insitu has joined #mirage
insitu has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
fgimenez has quit [Ping timeout: 240 seconds]
fgimenez has joined #mirage
fgimenez has quit [Changing host]
fgimenez has joined #mirage
yomimono has joined #mirage
<mato> yomimono: what time's the mirage irc meeting? 4pm uk?
<yomimono> Yep.
* yomimono checks to make sure she didn't miscopy TZ in the reminder email
<yomimono> ah, failed to mention it at all, nice
* hannes will be in transit at that point in time
<Drup> yomimono: did you ended up using the match_impl version for stack+qubes ?
<Drup> (the github discussion is unclear)
<hannes> but enjoy your meetings ;)
<yomimono> Drup: where? we had discussion about a few different locations
<yomimono> statements meant to reject constructing socket-based tcp/udp on non-unix, or the generic_stackv4 implementation choice logic?
<Drup> generic_stackv4
<yomimono> yes, there's a match_impl in there now
<Drup> hum, eq should probably go back in functoria_key
<yomimono> (your original statement was unambiguous, the others are match_'s
<yomimono> )
<yomimono> ack, could definitely be used other places
<Drup> the code is indeed clearer, the downside is that the dot will not indicate exactly the choice structure depending on keys :(
<yomimono> I think I'm missing something about how to make good use of the dot output
<Drup> You will get a big "choice node" that depends on all the involved key and 4 outputs, not a decision tree
insitu has joined #mirage
<Drup> yomimono: alternatively, the dot output is not the right presentation for your usage. ;) I wouldn't mind having feedback on that part
<yomimono> Drup: yeah, I was just about to ask what kinds of questions you envision the dot output answering
<yomimono> probably "what will I get if I set this key", right?
<Drup> yes, mostly
mort___ has quit [Quit: Leaving.]
<yomimono> which does seem like the sort of thing a user would want to know, but I'm definitely more used to invoking a --help when confused about that sort of thing
mort___ has joined #mirage
<hannes> I'd guess the underlying question is: can we have nice code and nice dot output? what is needed to make this happen (maybe Drup can PR how it should be done?)
<Drup> hannes: this is something I wondered too, and I don't have an answer
<Drup> either you use a if, then functoria know about if, and you get a nice structure, or you use a match, and then you don't
<hannes> certainly nested choices in the dot output aren't too nice, but maybe choice2/3/4/5/6 should then be provided by functoria?
<Drup> I would like to find good encoding for sum types that would make match convenients, but didn't really got time to pursue that
<hannes> !
<hannes> +1
<Drup> (so I settle for this list-based solution with a default case, which is kinda crap, but workish enough)
<Drup> (and If you look at the implementation of match_impl, it's basically a chain of If ...)
<hannes> Drup: do you get one node with n edges for match_impl (of n cases), or n nodes with 2 edges each?
copy` has quit [Quit: Connection closed for inactivity]
<Drup> huum, I don't remember
<Drup> I wanted the former, but did I implemented it ?
<Drup> doh, nothing compiles anymore since mirage and www/skeleton are partially out of sync :(
<yomimono> mirage-skeleton branch mirage-dev or master?
<yomimono> drup: there's also a mirage-dev branch of mirage-www but since that doesn't get built automatically it might really be broken atm :(
<mato> is there a way i can get opam to tell me all known packages that depend on X (reverse depends)?
<yomimono> opam list --depends on X
<yomimono> sorry, --depends-on
<yomimono> ugh, unicorns when I try to look at mirage-www on github :(
<hannes> yomimono: ah, that should build again now that fat has a conflict with wt-2.6 in opam-repo..
<yomimono> hannes: thanks for taking care of that
<yomimono> drup: say more things about your problem; you shouldn't be totally unable to build everything
<hannes> still, mirage-www (on mirage-dev branch) is broken after my console changes... i tried briefly to fix it, but couldn't..
<Drup> it's fine, I'm just extremly mirage-rusty
<hannes> ended up that i thought the whole logging should rather use logs instead of console.log
<Drup> hannes: it will show one node with n outputs
<hannes> and then fell asleep, sorry
<hannes> Drup: that is good!
<Drup> I coaless If nodes
<hannes> ic
<Drup> (can be seen directly in mirage-skeleton/stackv4)
<yomimono> hannes: yes, I think you're right that it should use logs
<yomimono> hannes: then we could perhaps export them to syslog and look at them
<hannes> syslog them to /dev/null
<yomimono> or throw them down the memory hole where no one will ever see them
<yomimono> jinx
<Drup> which ... result in a weird behavior for the new console
<Drup> huum
<hannes> that's what i do with my logs
<yomimono> emerging best practice in these trying times
<Drup> huum, the dot graph for stackv4 has grown significantly bigger and more spagetti with the qubes stuff
copy` has joined #mirage
<hannes> yomimono: I just restarted the last failing mirage-www job at https://travis-ci.org/mirage/mirage-www/jobs/176125723
<yomimono> https://status.github.com/messages says major service outage, so now might not be the time to try to figure out whether our tests pass
<yomimono> (I mean, if they do that's great, but they're probably going to have a lot of transient pull failures)
<hannes> oh wait... there's this new distributed version control system out there which should be tolerant to failures of single entities *runs away*
<yomimono> yes, and it would be lovely to use it that way instead of putting all of our code on one server that then can sometimes fail, and telling all of our testing infrastructure to look there, I agree
* mato is still wanting the "please use local git mirrors of *everything* instead of whatever the remote is" mode for opam
<yomimono> mato: I want this too and I think it may actually already sort of exist -- opam info mirror suggests such a thing
<mato> that plus "here's a manifest of {repo+commit}...", please use these and these only
<mato> yomimono: yeah, but unclear if it'll work with git:// URLs
<hannes> isn't this sth best to-be-solved outside of opam, i.e. a transparent git proxy?
<mato> possibly. except that with the world hell bent on https-is-everywhere, proxies (transparent or not) are becoming somewhat more useless over time
<hannes> afaics fetch (wget) respect HTTP_PROXY env var, and use http instead of https to the proxy.. plus you can inject your own CA since it's after all your computer..
<hannes> but I may be too idealistic here... and the git version pins certainly need some opam support (but I guess you can already pin to a version, similar to a branch)
insitu has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<Drup> yomimono: going back to the previous topic. What do you use describe --dot for (if you do)/what kind of visualisation would like to have ?
<yomimono> Drup: I don't really use it at all unless I'm talking with you and you tell me to look at it :P
<yomimono> Then I usually look at it and say "yes, it appears that I indeed made mirage do something nonsensical" and close it
<Drup> x)
<yomimono> could be useful in noticing that some component is being shared that shouldn't be
<yomimono> hm, annotations when I run it with --eval would be nice, I think
<Drup> annotations ?
<yomimono> reasons for choosing a node
<yomimono> but tbh I'm really bad with visual things and usually prefer to use words when possible
<yomimono> I'm not a good person to ask about things like this
<Drup> I see
<Drup> (I'm the opposite, I do little graph drawing everywhere, hence why I made that dot thing ...)
<yomimono> it would probably be very valuable for me if I were hacking around in the actual graph stuff in functoria
<Drup> yomimono: so what kind of feedback would you like ? describe+config.ml is good enough for you ?
<yomimono> Drup: I've done a lot of hacking in printf debugging, I'm sorry to say, and then running mirage with -v
<yomimono> I don't use describe very often either
<Drup> :(
<yomimono> sorry :(
<Drup> what do you use the printfs for ?
<yomimono> you might get less depressing answers on the mailing list
<yomimono> drup: most recently I was using them to try to figure out how I was getting such confusing results after changing generic_stackvv4
<yomimono> but I think the problem is that I'm hacking on mirage, not using mirage to build some other application, most of the time
<yomimono> so it's not really the use that you intended, I don't think
<Drup> actually, it sort of is
<Drup> maybe a choice log would be useful ?
<Drup> "I reduced this If node because that keys had value plouf" ?
<yomimono> yeah, that's the sort of thing I'd like, I think
<Drup> (--eval was meant to provide that, but I guess it's not detailed enough)
<yomimono> part of it isn't really a deficiency of the tool, but --dot doesn't do the right thing on my system; I have to save a file and then open it with xdot which is annoying
<yomimono> (--dot opens xdot but the graph doesn't display)
<Drup> ah
<Drup> but that's an unreported bug :<
<yomimono> yes, I have consistently forgotten about it two seconds after encountering it every time
<yomimono> best reported in mirage/mirage or mirage/functoria?
<Drup> functoria
<yomimono> but I really think you should ask other people who like opening new windows and looking at pictures more. It will be almost everyone
<Drup> yomimono: does "echo foo.dot | xdot" do something correct ?
<yomimono> do you mean cat?
<Drup> yes
<yomimono> ok, I'll check
<yomimono> nope, blank
<Drup> ah
<Drup> it's supposed to work
seangrove has joined #mirage
insitu has joined #mirage
amirmc has joined #mirage
<Drup> yomimono: do you know which xdot version ?
<yomimono> drup: one that doesn't have --version . Hang on, let me interrogate my package manager
<yomimono> 0.6-2 according to dpkg-query
<yomimono> (debian 8)
<Drup> I have 0.7-2, maybe it's been fixed since
<Drup> hum, doubt it, 0.7 is from april, and it was working before
<Drup> grumph
<yomimono> software :(
<Drup> anyway, functoria should still provide a better interface for not graphical people :3
<Drup> If you have ideas or whatnot (in particular that would replace printf-based tracing), create a bug report
<Drup> it can't really hurt
<yomimono> i'll try to be a bit more conscious of that, yeah
avsm has joined #mirage
unpurecamelbot has joined #mirage
<unpurecamelbot> I'll be logging this meeting…
<avsm> Greetings! Time for the MirageOS meeting, agenda here: https://github.com/mirage/mirage-www/wiki/Call-Agenda
<avsm> Who's around?
<yomimono> hi!
<amirmc> o/
djwillia has joined #mirage
* mato waves
<avsm> a few people travelling and such today, so lets get started
<seangrove> o/
<avsm> First up is the release schedule - yomimono, take it away
<yomimono> i'd hoped to tag a beta yesterday which clearly didn't happen
<yomimono> but I'm still hoping to do that this week
<yomimono> it's silly to do it before we're done making really huge API changes, and there's one big outstanding one: result errors
<yomimono> so I'm trying to get that into close-enough shape to PR and merge first.
<mato> what does "tagging a beta" mean exactly?
<amirmc> Could we summarise the rough outline of the path to 3.0?
<amirmc> and I also have the same question as mato :)
<yomimono> mato: specifying a version (not dev~mirage) for mirage-types then expressing that version constraint for the universe of stuff that's currently in mirage-dev
<yomimono> mato: also plan on renaming V1, V1_LWT before this change
<avsm> So the good news is that once the API churn has stopped, this can happen in the existing mirage-dev; just convert the dev.mirage versions to concrete archivs
<avsm> we do need to set upper bounds early on in opam-repository though
<mato> yomimono: So, in practice, if someone wants to install the beta, what would they do?
Hannes__ has joined #mirage
<mato> yomimono: and, conversely, what happens to fixes in between the beta and 3.0?
<yomimono> mato: similar workflow to how you end up with the mirage3 stuff currently: custom repo, then opam install
talex5 has joined #mirage
<mato> so there'll be a short-lived mirage/mirage-dev#beta or something like that?
<yomimono> mato: depends on the magnitude. I'd imagined a lot of point "releases" for things within mirage-dev
<Hannes__> I guess the ability to specify version constraints in config.ml should also be fixed asap, since otherwise we end up in the same situation as now: we can't express support for a given mirage-types in a unikernel
<yomimono> mato: something like that, yeah.
* mort___ says hi
<avsm> that version constraints issue does seem pressing :-/
* mato is just trying to understand how easy it'll be to point users to trying out the beta
<amirmc> ^^ same
<avsm> A separate remote is a fine way to distribute the beta
<yomimono> hannes__: everyone agrees that it would be nice to have, but nobody has had time to do it
<Hannes__> It seems to be easy if we remove the opam calls from mirage configure and use a make depend instead
gemma_ has joined #mirage
<mato> also, is "tagging a beta" dependent on tagging actual versions of all the unreleased packages in mirage-dev?
<yomimono> mato, amirmc: what's your dream workflow for getting the beta?
<avsm> One uncomfortable point right now is that `mirage configure` can also invoke `opam pin`, if you activate tracing, so its quite side-effectful
<yomimono> mirage configure doesn't do that by itself
<yomimono> avsm: it gives you some help text telling you that you should do it
<mato> yomimono: having a separate remote available for trying out the beta (with instructions) is probably good enough for me
fgimenez has quit [Ping timeout: 268 seconds]
<avsm> yomimono: yeah good point; I just c&p it blindly ;-)
<djwillia> avsm: where's the best place to learn about "tracing"?
<amirmc> yomimono: I think something like `opam install mirage.beta1` would work (I'm totally making that up on the spot btw - no idea if it's sensible).
<mato> amirmc: that would depend on getting all the beta dependencies into upstream opam proper
<Drup> amirmc: better use the mirage-dev repo for that
<djwillia> avsm: thanks
<yomimono> amirmc: would `opam remote add mirage-beta url && opam install mirage.beta1` be significantly worse from your perspective?
<avsm> So the real goal of the first beta is to discover any show stoppers in APIs, not to have a fully reproducible beta1. So to some extent, we could even release with just the mirage-dev instructions without tagging releases
<yomimono> (which is what drup and mato are saying)
<avsm> Although tagging some of the core libraries seems prudent
<amirmc> Asking people to add a remote and remember to remove it later seems complicated. If that's the best way for now, then fine. :)
fgimenez has joined #mirage
fgimenez has joined #mirage
fgimenez has quit [Changing host]
<yomimono> avsm: true, but it would be nice for people to know they have "the beta" rather than some old version, which right now they have no way of knowing
<mato> +1
<yomimono> if we're going to ask people to try things and report errors, I'd rather be able to know that they're not running into stuff we fixed weeks ago :)
djs55 has joined #mirage
<mato> amirmc: we can probably add some magic conflicts to ensure that you're either on the beta remote or not (yomimono?)
<amirmc> If we want people to use mirage-dev, we don't need to mention 'beta1' at all. Just be on mirage-dev for a while.
<avsm> right, that's true, so we want to distinguish: mirage.2.9.1, mirage.3.0.0~beta1, mirage.dev~mirage
<yomimono> we can express versions within mirage-dev
<Hannes__> Calling it beta1 helps!
* yomimono nods
<amirmc> But current issue is that if people are trying to be productive a global remote affects other switches.
<avsm> Bear in mind that we do not want beta1 to survive in the wild very long; there is only a month-long release window.
<avsm> so confining it to the warm confines of mirage-dev would be prudent. It should not hit ocaml/opam-repository
<Drup> amirmc: jump on the opam 2.0 bandwagon ? :D
<Hannes__> after all, there is a schedule?
<mato> Sure, but (what amir said) we don't want the beta to potentially break people's existing working mirage 2 setups, whatever those might be
<amirmc> drup: heh! one thing at a time :P
<Hannes__> amirmc: agreed. We can prove a shell script with pins as well
<Drup> (it was a joke, even if per-switch repositories are really cool)
<amirmc> drup: I know :)
<avsm> The overall planning ticket is https://github.com/mirage/mirage/issues/592
<avsm> amirmc: are you keeping the issue body uptodate with the comments?
<Hannes__> S/prove/provide/
<amirmc> avsm: Is there something missing there?
<avsm> mato: I think we just have to clearly document the limitations of remotes in OPAM 1.2. We can't solve every upstream tooling problem
<avsm> amirmc: I dont know, I havent cross checked all the comments, hence my question :)
<amirmc> avsm: I don't think there's anything to add to that issue. The only thing that isn't clear is what the rough timeline looks like.
<mato> avsm: Ack.
<amirmc> avsm: The checkboxes haven't changed and the announcement activity is the same. Just when things are expected to happen.
<avsm> amirmc: ack, I (literally just now) added another one for the performance harness
<avsm> Alright, so we can get a sensible schedule once we do the last of the API churning merges
<avsm> and get the V1 renaming in
<avsm> but broadly speaking, still aiming for a beta this month with a website update, and a final release in January
<yomimono> unless everyone changes their minds and decides that the current error interface and names are just great and nothing needs to change :P
<avsm> from experience, it takes a significant amount of time to tag and release, so I would account a few days for that
<avsm> and adding upper bounds and so on
<mato> indeed.
<Hannes__> But now we've topkg nearly everywhere :D
<mato> so IIUC the beta1 remote does not depend on tagging or releasing the component packages?
<avsm> mato: it makes sense to tag as many as we can
<avsm> since that's the only vehicle by which we can constraint other packages
<yomimono> mato: in practice, the fewer of them we tag the harder it will be to diagnose problem reports
<yomimono> but it's not a strict requirement
<mato> yomimono: hm. i'm away from tomorrow until the end of the week. so won't have time to tag the solo5 packages until i get back.
<amirmc> I'm happy to review and walkthrough any instructions relating to the beta process. I'd like to get the early adopters using it. Just ping whenever's there's something to look at.
<avsm> amirmc: sounds good!
<yomimono> mato: is there a reason not to just tag current HEAD in a working universe?
<avsm> mato: i have solo5 access right? i can do the tags on HEAD if you are away
<avsm> jinx :)
<Hannes__> I guess an initial upgrade guide would be nice to have for beta testers as well
<mato> avsm: yomimono: what i don't understand is is it just a tag or a full "release", i.e. new opam version number, changelog, etc.
<avsm> i'd be surprised if we tag before Monday though
<avsm> It's a full package release
<avsm> just not uploaded to ocaml/opam-repository yet
<avsm> but instead pushed to mirage/mirage-dev
<amirmc> We'd need to point to the mirage-dev branch of skeleton too. That'll likely be helpful.
thomasga has joined #mirage
<mato> avsm: yomimono: in that case i'd prefer to be around while that's being done.
<avsm> ok, so anything burning on any individual issues yomimono (aside from the opam constraint)
<yomimono> mato: ack.
<avsm> mato: early next week should be fine
<mato> sounds good
<yomimono> avsm: would like to reiterate the opam constraint. I doubt that will involve API changes but it's pretty important and it seems no one has looked at it seriously yet
<avsm> yeah, it does seem very important :-/
<avsm> at least if we hold the beta to mirage-dev, we have December to do it in
<avsm> since its only a real disaster once we have incompatible universes in opam stable
<avsm> ok, onto the next topic...
<avsm> compilers! OCaml 4.04.0 came out, and the package universe is slowly adapting
<avsm> thanks mato for getting ocaml-freestanding working with it, so Solo5/4.04 should be good to test with
Hannes__ has quit [Ping timeout: 260 seconds]
<avsm> if anyone sees any packaging issues, please do raise them so that they get attention
<avsm> most of the ppx universe should work now (ppx_sexp_conv and so on)
<yomimono> xen/4.04 should be working as well, just to be clear
<yomimono> please report problems with that too :)
<avsm> yes sorry -- both xen and solo5. I'm going to shift mirage-www over today hopefully
<yomimono> awesome!
<avsm> we are still doing deployment builds on 4.02, no reason not to move now
<amirmc> Side question, Is 4.04 in homebrew yet?
<avsm> Not yet, it's too early for the update as there's a 4.04.1 coming out with some important bugfixes
<amirmc> ack
* yomimono plays sad trombone
<avsm> opam switch should work of course
<avsm> alright, onto testing then
<avsm> yomimono: tracvis seems healthier now?
<amirmc> Yup, was wondering when my collection of system-aliased switches was due to break :P
agarwal1975 has joined #mirage
<yomimono> avsm: not 100% healthy yet but getting there, thanks to you and hannes
<yomimono> end of message
<avsm> so good news on the CI front -- we do have https://github.com/avsm/mirage-dev working and successfully building revdeps
<avsm> but its not live yet until i get stable machines, which are deploying as we speak on Scaleway
<avsm> the issue is just getting the ton of storage we require
<yomimono> correct link? that's your fork of mirage-dev
<yomimono> awesome!
<avsm> i'll move this to mirage/mirage-ci as soon as we have something live on ci.mirage.io
<avsm> github support pinged me politely asking why i had a repo with 1 million+ branches being pushed to once a second
<yomimono> #1 unicorn generator 2016
<avsm> so i think we might want to set up our own git repos to be good citizens :P
<mato> :-)
<thomasga> (also the CI library is there https://github.com/docker/datakit/tree/master/ci if anyone wants to play with it)
<avsm> and talex5 is giving a talk about it tomorrow in London! https://www.meetup.com/London-Functionals/events/235133158/
<thomasga> the build/test pipeline is defined with https://github.com/docker/datakit/blob/master/ci/src/cI_s.mli
<thomasga> and then all of that get inspected/executed and we have a nice webserver and scheduler and so on
<avsm> the way the CI is built is a nice DSL that lets you compose stages together with applicative plugins
<mato> avsm: wouldn't it be better to host our own git for the huge repos? or is there some reason they been to be on github?
<mato> s/been/need/
<amirmc> It would be good to allocate some time to write a blog post about the CI work. To go out after the release, I mean.
<avsm> mato: yes absolutely, just a matter of getting a stable machine set to do so
<thomasga> I really hope and that talex5's talk is recorded :-)
<yomimono> +1
<avsm> amirmc: yes, gemma_ is coordinating the blog posts
<thomasga> but yes, we need to write some blog post about that
<thomasga> post(s)
<avsm> I'll write about the mirage-ci DSls once its live
<amirmc> +1
<thomasga> I need to describe irmin/datakit relations too
<amirmc> +1
<avsm> there are Opam_build, Docker_build, Docker_run plugins and hannes is working on a FreeBSD_jail one as well
<avsm> more on that next meeting or before in mirageos-devel when its live
<avsm> I've also started resurrecting our old Mirage2 performance harness with mort___ and Takayuki Imada https://github.com/mirage/mirage/issues/685
<avsm> we just met this morning, so more on that as the beta gets tagged. it's of course quite important to be able to measure our release :)
<yomimono> this is cool! I look forward to seeing it develop
<mort___> avsm: have you done anything with mirage-perf yet? current harness is rather tied to xenserver specifically (having just looked at it)…
<avsm> mort___: nope
<avsm> there is a nice looking iperf unikernel in there though
<avsm> and now we have a proper logging library in v3!
<mort___> yes
<mort___> am going to bring that up to latest mirage/functoria at least
<avsm> awesome
<avsm> Alright, onto the hack event!
<avsm> lots of fun stuff got done -- anyone have any queries about any particular project?
<yomimono> I had ?s about mirage-ci which are now very answered :D
<avsm> I'm keen to see the local version of the MirageCI that hannes and thomasga hacked on :-)
<avsm> Also hannes has started organising the next hackathon in Marrakech
<avsm> so quite a few physical events in warm and cold climates in the next months, but not many outside EMEA
<amirmc> hannes: Can you remind us of the dates again? :)
<seangrove> Is the mirage-ci stuff meant to be used by people like me, building stuff using mirage, xor just for the development of mirage itself?
<seangrove> And yay for Marrakech!
<avsm> seangrove: it's actually a bunch of libraries that generates a CLI, so i use it locally with Docker4Mac
<yomimono> I think hannes is away atm but the dates last I heard were the first week in march
<avsm> there's a 'canary' mode that only builds the master branch, so it's quite convenient for local dev too
<avsm> but it's certainly not out of experimental yet, so i'd wait for it to be stable on ci.mirage.io first
<avsm> there are a few other users of it now as well (e.g. internally at Docker for our infrastructure), so stability will only get better
<avsm> I think that's pretty much it for the written-down-agenda this week
<amirmc> FYI, Marrakech is 2-7 March. I may well have a clash :-/
<yomimono> attending for a subset of the dates is OK FWIW
<yomimono> (according to mail from hannes)
<avsm> does anyone remember how to shut the bot down? :-)
<avsm> unpurecamelbot commit done
<unpurecamelbot> done
<avsm> wooop!
<avsm> nothing exploded
<amirmc> On that note. If we're going to continue IRC meetings, then we should consider MeetBot.
<amirmc> Or at least pull in some of the features.
<avsm> looks neat, will take a look. scary darcs
<mato> thanks all and avsm for coordinating! looking forward to the beta and 3.0
<avsm> thanks everyone! let the epic tagging fest begin!
<djwillia> take it easy all, thank you!
<yomimono> thanks folks!
djwillia has quit [Quit: Page closed]
talex5 has quit [Quit: Leaving]
amirmc has quit [Quit: Leaving.]
brson has joined #mirage
fgimenez has quit []
avsm has quit [Quit: Page closed]
jermar has quit [Ping timeout: 258 seconds]
insitu has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
AltGr has left #mirage [#mirage]
gemma_ has quit [Quit: Connection closed for inactivity]
insitu has joined #mirage
yomimono has quit [Ping timeout: 240 seconds]
insitu has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
w10have has joined #mirage
mort___ has quit [Quit: Leaving.]
jermar has joined #mirage
insitu has joined #mirage
w10have has quit [Ping timeout: 260 seconds]
brson has quit [Ping timeout: 260 seconds]
noddy has quit [Ping timeout: 248 seconds]
agarwal1975 has quit [Read error: Connection reset by peer]
mort___ has joined #mirage
agarwal1975 has joined #mirage
yomimono has joined #mirage
insitu has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
brson has joined #mirage
thomasga has quit [Quit: Leaving.]
agarwal1975 has quit [Quit: agarwal1975]
agarwal1975 has joined #mirage
jermar has quit [Remote host closed the connection]
andreas231 has quit [Ping timeout: 250 seconds]
gemma_ has joined #mirage
mort___ has quit [Ping timeout: 256 seconds]
thomasga has joined #mirage
<yomimono> ISTR some handy guide for booting mirageos unikernels on GCE, does anyone know where that lives?
jermar has joined #mirage
mort___ has joined #mirage
thomasga has left #mirage [#mirage]
brson has quit [Quit: leaving]
brson has joined #mirage
mort___ has quit [Quit: Leaving.]
rgrinberg has joined #mirage
noddy has joined #mirage
<engil> unpurecamelbot: bye
unpurecamelbot has quit [Quit: unpurecamelbot]
<yomimono> insomniac camels around here today
agarwal1975 has quit [Quit: agarwal1975]