<miragebot>
mirage/master 30fee16 Hannes Mehnert: move mirage-types.lwt to mirage-types-lwt
<miragebot>
[mirage] yomimono pushed 2 new commits to master: https://git.io/v115i
miragebot has left #mirage [#mirage]
insitu has joined #mirage
rgrinberg has quit [Ping timeout: 250 seconds]
andreas231 has quit [Ping timeout: 258 seconds]
andreas23 has joined #mirage
insitu has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
vramana1 has joined #mirage
vramana has quit [Ping timeout: 268 seconds]
vramana1 is now known as vramana
copy` has joined #mirage
insitu has joined #mirage
insitu has quit [Read error: Connection reset by peer]
brson has joined #mirage
insitu has joined #mirage
fgimenez has joined #mirage
fgimenez has quit [Changing host]
fgimenez has joined #mirage
AltGr has joined #mirage
insitu has quit [Read error: Connection reset by peer]
insitu has joined #mirage
brson has quit [Read error: Connection reset by peer]
brson has joined #mirage
brson has quit [Read error: Connection reset by peer]
brson has joined #mirage
brson has quit [Read error: Connection reset by peer]
brson has joined #mirage
brson has quit [Read error: Connection reset by peer]
brson has joined #mirage
insitu has quit [Read error: Connection reset by peer]
insitu has joined #mirage
brson has quit [Read error: Connection reset by peer]
fgimenez has quit [Ping timeout: 248 seconds]
fgimenez has joined #mirage
fgimenez has joined #mirage
fgimenez has quit [Changing host]
brson has joined #mirage
brson has quit [Quit: leaving]
Bluerise_ is now known as Bluerise
vramana1 has joined #mirage
vramana has quit [Ping timeout: 268 seconds]
vramana1 is now known as vramana
insitu has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
insitu has joined #mirage
insitu has quit [Read error: Connection reset by peer]
<mato>
hannes: you were looking for me?
fgimenez has quit [Ping timeout: 258 seconds]
fgimenez has joined #mirage
fgimenez has joined #mirage
fgimenez has quit [Changing host]
<hannes>
mato: yes. the solo5/bhyve is running impressively stable, much better than the xen stuff (where my blog needed to be restarted every third day)
<mato>
hannes: that's awesome!
<mato>
hannes: I hope to deploy some unikernels over the xmas break, busy with some other work till then
smondet has quit [Ping timeout: 240 seconds]
srenatus[m] has quit [Quit: Client limit exceeded: 5000]
<hannes>
mato: no worries... i hope the accounts work ok..
smondet has joined #mirage
insitu has joined #mirage
rgrinberg has joined #mirage
yomimono has joined #mirage
unpurecamelbot has joined #mirage
<unpurecamelbot>
I'll be logging this meeting…
<yomimono>
good to see you, unpurecamelbot!
betheynyx_ has quit [Ping timeout: 246 seconds]
unpurecamelbot has quit [Remote host closed the connection]
<yomimono>
aw :(
agarwal1975 has joined #mirage
unpurecamelbot has joined #mirage
<unpurecamelbot>
I'll be logging this merry meeting…
<yomimono>
❄
insitu has quit [Read error: Connection reset by peer]
<engil>
I might be able to attend today
<engil>
not feeling to tired for once
<engil>
s/to/too/
amirmc has joined #mirage
* demonimin
is Gabriel, at the ready
insitu has joined #mirage
<engil>
is there anyone who have access to the super top secret hook URL for canopy.mirage.io ?
<engil>
I pushed the last logs two weeks ago
GemmaG has joined #mirage
<engil>
but that somehow failed
<engil>
the server might have more to say
<engil>
or I could check locally...
<engil>
that sounds like a better idea
unpurecamelbot has quit [Remote host closed the connection]
unpurecamelbot has joined #mirage
<unpurecamelbot>
I'll be logging this merry meeting…
<yomimono>
this may not be common knowledge but ocaml-tls and conduit point to forks of mine in mirage-dev
<hannes>
so, would it be solved by opening the polyvar (i.e. make it non-private)?
<yomimono>
the patches which allow those packages to build in that universe are unlikely to be merged into ocaml-tls as stands
<yomimono>
hannes: great question, I have not had time to test this hypothesis
<avsm>
Just so I understand the overall requirement of ocaml-tls, it is that it wants to handle some errors by itself, and pass others through?
<yomimono>
in fact I would like it a lot if someone else could do this, as I've been spending enough time trying to figure this out that other release stuff is getting neglected
<hannes>
avsm: no. it consumes a flow and provides a flow. it wants to add errors, which can be handled by a consumer, to the flow error type
<yomimono>
(I'm adding another item to the agenda as regards API changes but I don't want it to interrupt this discussion)
<hannes>
(i.e. type error = [ F.error | `Tls_failure of Tls.Engine.failure ])
<avsm>
ah, so there is an upstream consumer of TLS which has some abstract FLOW errors ( from the underlying FLOW) and then the additional (recoverable) TLS errors
<avsm>
ok
<hannes>
exactly, some consumers may treat some TLS failures as recoverable
<avsm>
I think the person who understands the issue best wrt private types is Jeremy Yallop, and he's offered to look at a distillation of the problem tomorrow morning to set us on the right path
<avsm>
can we get this into a small self-contained example for him? (In one ml file just illustrating the types)
<avsm>
then I'm happy to attempt to take on the actual patches from you yomimono
<yomimono>
avsm: that's really great to hear, thanks :)
<avsm>
but I think it's worth pausing on the live trees with this change and getting a firm decision from an OCaml typing expert on the best abstraction approach, and yallop fits that bill :)
<amirmc>
Great! Just to clarify, this is the last blocker before we can do the beta. Is that right?
<yomimono>
there's one more API change which is djs55's proposed addition of disconnect (immediate shutdown) to FLOW
<yomimono>
but that is much less major - we've done similar changes at minor releases in Mirage 2
<hannes>
plus the V1_* rename..
<avsm>
That one is thankfully far simpler since many of the implementations already implement disconnect
<avsm>
just before we get sidetracked
<yomimono>
hannes: I see the V1_ rename as part of the release process itself, but yes you're right that it needs done
<yomimono>
semantics
<avsm>
about the Tls errors: hannes, we can go through it in person tomorrow with yallop perhaps as well?
<hannes>
avsm: if time permits
thomasga has joined #mirage
<avsm>
yeah
<hannes>
(this was my attempt at being british, you could read it as "yes, of course" :)
<thomasga>
(I'm late but hi!)
<hannes>
I'm happy to find a solution here, I tried last weekend for >10hours without much success
<avsm>
ok, let's do that then. Do we have a small file illustrating the problem yomimono/hannesm? a non-compiling example with comments saying what we want it to do would be ideal :)
<yomimono>
hannesm: I think you're a better person to assemble this, I don't trust myself to be completely correct on what is important in that interface
<hannes>
not sure whether I've time for this until tomorrow morning..
<avsm>
lets take it tomorrow morning then
<avsm>
need to get the trees compiling again tonight before more changes anyway :)
<yomimono>
yes, I merged a big changeset and then went to bed last night, sorry not sorry :P
<yomimono>
avsm: sounds like a good segue into our next agenda item, CI
<avsm>
It's deployed! It's live! Bugs are being fixed via it!
<avsm>
There was a maddening bug due to an incorrect comparison function that talex5 just fixed for me, so the live one now should trigger off PRs just fine
<avsm>
samoht suggested a 4.02.3 opam install mirage.2.9.1 revdeps test to check upper bounds for example
<avsm>
and mirage-skeleton is another one... we can run tests too
<avsm>
takayuki imada and i have also deployed a bare metal xen machine in packet.net to do performance testing, so he expects to have an update on that over the next few weeks
<hannes>
nice!
<avsm>
once those scripts are hooked into ci.mirage.io, we can extend with solo5 perf tests also
<mato>
can the underlying CI infra run tests which need /dev/kvm? would be useful for solo5/ukvm?
<avsm>
mato: yes -- xen was the only challenge due to the need to edit grub2 configurations, but sorted that yesterday. KVM just works
<hannes>
I also should rewrap my head around the CI stuff and deploy on my FreeBSD host.
<avsm>
ah and I also have a freebsd bare metal machine, and an ARM64, and an ARM32 (currently undeployed), so I could use help with some FreeBSD Jail runes hannes
<avsm>
i'm thinking of making the CI OPAM2 only, since then we can use the command wrappers to invoke docker, jails or whatever sandbox we need
<hannes>
(surprisingly, my blog (using canopy) and other web services run on bhyve+solo5-virtio with 7MB memory (including irmin/git) -- and I don't need to restart canopy every other day (which I needed to do on linux/xen)
<hannes>
did I dream or wasn't there somewhere a more technical intro? ;)
<avsm>
welcome aboard demonimin -- you're building the final link in a long chain there :P
<demonimin>
yes, I need to update it and make it public
<mato>
yomimono: Just to confirm - what amirmc asked - the Resulty errors, djs55's disconnect change and V1 renaming are all that remains for the Beta?
<demonimin>
I've started prototyping a bit, which means I'll update the design slightly
talex5 has joined #mirage
<hannes>
(no design is by any means ever finished, glad to hear that you're working on it, demonimin)
<yomimono>
mato: we could tag without disconnect changes. resulty errors (specifically the changes to them needed to get master ocaml-tls building) and V1 renaming are crucial
<thomasga>
I am pretty keen to use the new block storage library :-)
<avsm>
yeah, minor interface tweaks are fine as we head towards the final release, but error changes will permeate everything
<demonimin>
basically I'm focused on an MVP that can run Irmin and provides a somewhat useful kv api
<mato>
yomimono: ack. don't want to interrupt the current discussion, can we come back to this (beta1) before we finish today.
<avsm>
sounds about right for a few months
<yomimono>
mato: sure
<thomasga>
demonimin: talex5 and I might have a few GiG of CI logs to store on that stuff..
<avsm>
demonimin: interestingly there's been a lot of interest in resurrecting a JavaScript backend for Mirage too, due to the ReasonML work that Facebook has been doing
<avsm>
so a pure OCaml implementation of a filesystem might end up being mapped to browser storage as well, as talex5 has done in the past with the Irmin blob layer
<demonimin>
ah, okay
<avsm>
(this is very much MirageOS 4.0 stuff :-)
<mato>
demonimin: your proposal looks nice. have you considered how hard it would be to allow concurrent readers/writers at the block level? i.e. share a single persistent store between more than 1 (uni)kernel?
<thomasga>
yup, if if could have anything else first, that would be great
<hannes>
I'd appreciate first a working block device for xen+solo5 :)
<demonimin>
it would be difficult, because garbage collection assumes a single writer
<thomasga>
mato: my guess: hard
insitu has quit [Read error: Connection reset by peer]
<thomasga>
but we can have higher-level lock mechanism
<demonimin>
I'd provide a distributed kv store at a higher-level, using either Irmin or an etcd design
<mato>
even allowing just multiple readers?
<mato>
the reason i ask is that at least multiple readers would make it easy to inspect the store from e.g. the host the unikernel is running on
<demonimin>
I've removed snapshots from the design because that makes garbage collection much easier, so even that would be hard
<demonimin>
but you could request a pause in garbage collection maybe
<thomasga>
mato: do you care about outdated data?
<avsm>
the "memory model" for reads in the presence of any writes is going to be fairly subtle...
<mato>
thomasga: as long as what i get is some kind of consistent snapshot which is not too far out of date that might be enough.
* avsm
desperately wants a single host filesystem first...
<thomasga>
I guess we could have a higher-level cache for concurrent reads if we don't care about consistency too much
<yomimono>
avsm: +1
<demonimin>
so do I, minimum useful thing first
<djs55>
A single reader single writer thing that just worked would be great
<mato>
anyway, i have not thought through this much, so it's just a "what if" question at this stage
<thomasga>
me too, single reader/single writer would already be very very useful
<mato>
agree, let's do the minimal thing first
<demonimin>
I'll consider making gc user-triggered so that another unikernel can inspect, but that's it
<avsm>
yeah explicit GC works
<hannes>
I actually make snapshots etc. of virtual block devices in the host system using ZFS... a simple FS would be sufficient for me
<hannes>
(but then, I'm a spoiled kid having ZFS and zvols)
<mato>
hannes: sure, but for that to work the FS needs to be able to read any snapshot in a consistent fashion
<avsm>
demonimin: a FUSE read-only layer might help too
agarwal1975 has quit [Quit: agarwal1975]
<hannes>
mato: ack
<mato>
hannes: i don't know if demonimin's design allows for that. if yes, then great
<mato>
hannes: (I use much the same thing for VM backups, create an LVM snapshot of the XFS-formatted vm disks and dump that)
<demonimin>
avsm: decent idea
<demonimin>
though remember it's a kv store, not a generic filesystem. Fuse would be focused on inspection.
<hannes>
mato: interesting question (for demonimin and his design)
<avsm>
Yeah, hence read-only. No getting caught in the pseudo-POSIX mire
<demonimin>
oh yes, I had missed that
insitu has joined #mirage
<avsm>
Alright, sounds like there's a lot of interest -- take the discussion to the devel list for a wider audience? :-)
<demonimin>
sure! thanks all for the interest
seangrove has joined #mirage
<yomimono>
thanks demonimin! :D
mort___ has joined #mirage
<yomimono>
next thing: results of the call survey! GemmaG?
<GemmaG>
Yes! Please see the gist I've started (very rough!)
<GemmaG>
Some great feedback, and interesting insights into community thoughts on this call and the ecosystem as a whole
<yomimono>
the link to the raw survey results just punts me to a page that says the survey is over - do you intend to make the raw results visible?
<GemmaG>
I'd like to create some actionable suggestions from this that we can look into after the release :)
<avsm>
That's well useful, thanks GemmaG!
<avsm>
I note suggestions like the use of MeetBot could address much of the concurrency confusion
<GemmaG>
Ah yes - I just closed it and didn't realise that - the results were anonymous so we can make them public if that would be helpful
<yomimono>
I think we should only do that if the survey told participants that their feedback would be made public
<avsm>
Agreed.
<yomimono>
I definitely put information in there that would uniquely identify me
<hannes>
avsm: I have put in this suggestion after I noticed that debian relies on it a lot. needs someone to either rewrite or set it up
<avsm>
For this one, I think GemmaG's summary has loads of actionable information to improve the state of the calls
<avsm>
...after beta is cut
<GemmaG>
Ok - they can stay private and I will generalise
<GemmaG>
Thanks all :)
<avsm>
hannes: yeah!
agarwal1975 has joined #mirage
<yomimono>
GemmaG - thanks for running this and for the excellent summary you've already provided :)
<avsm>
+1
<GemmaG>
thanks!
<amirmc>
+1
<avsm>
(and to engil for his canopy maintenance to get these logs up! he is currently debugging a parsing error :)
<yomimono>
is there anything else on the subject of the survey?
<yomimono>
if not, mato requested that we come back to the subject of beta1
<avsm>
only to ask about the hackathon
<yomimono>
hackathon status: will be rad
<avsm>
which is an unashamedly irrelevant thing to the survey, but I had to make a connection
<hannes>
I suspect there is the question about governance of MirageOS -- which we should address after the release (i.e. how are changes done, how are PRs merged, etc.)
<amirmc>
+1
<avsm>
hannes: yeah -- at least we have this beta cycle to look back on to determine who was actually doing what, and then we can smooth over any repo access issues and general policies based on the experience
<mato>
+1 (governance should be formalised)
<hannes>
I should post to the list that 2-7 march 2017, >10 people already signed up (I haven't sent out any mail, sorry, will do when time permits). 275 EUR, held in marocco, marrakesh
<avsm>
hannes: superb
<hannes>
what I'd also want to achieve is proper documentation similar to the FreeBSD handbook for MirageOS (maintainence guide)
<hannes>
I'd point governance to e.g. https://tails.boum.org/contribute/merge_policy/ (they seem to do a good job with feature proposals, both discussion and preservation of the advantages/disadvantages)
<mato>
hannes: /me would love it if Mirage were maintenance-free :-)
<avsm>
back to the immediate topic at hand of beta1
<mato>
ok
<mato>
First, I wanted to check if "before everyone heads off for xmas breaks" is still realistic?
<hannes>
mato: since software is never finished, I don't believe we can achieve this... there'll always be updates ;)
<avsm>
yomimono: it looks like the sequence is: 1) get trees building after mirage-types-lwt change (the CI is churning on this right now); 2) determine error interface 3) defer Flow.disconnect post beta?
<yomimono>
yes and (2) is a huge unknown since it's already taken approximately eight times longer than originally anticipated
<amirmc>
mato: Another way of asking is "who's around to deal with things?"
<thomasga>
and 2.5 rename V1
<mato>
Second, I've seen the flurry of opam-metadata-upper-bounds PRs, will these changes be somehow automatically integrated back into the upstream trees, or do I need to do this manually for the Solo5 packages?
<thomasga>
yomino: I volonteer to help for stabilizing the repos
<yomimono>
mato: I plan to do these automatically but haven't built the tools yet
<thomasga>
(and to learn how to spell english better)
<hannes>
mato: I guess magic partially appeared and -console, -net (i.e. those I touched last night) are already >= 3.0.0)
<avsm>
mato: I'd encourage "automatically" since that'll be a key part of the post-Mirage3 contribution workflow
<yomimono>
this is something I plan on doing while not bashing my head against errors anymore
<avsm>
everything we automate now will be something that lowers the bar to contributions from newcomers post-release
<thomasga>
yomimono: I also volunteer to help to ease the release on any blocking stuff, so feel free to throw things at me
<mato>
Right, so in terms of the Solo5 packages for release all that remains is some changelogs need to be written and a new release needs to be tagged
<thomasga>
(e.g. the error stuff scares me a bit, but I can try to help :p)
<avsm>
i can confirm that throwing stuff at thomasga really helps with release stress, yomimono
<yomimono>
:P
<thomasga>
(as long as it's not tomatos)
<hannes>
eggs?
<yomimono>
cat toys
<mato>
The changelogs can probably just say "Release for Mirage 3.0 beta1" or does anyone really want more detail than that for the solo5 packages? hannes? djwillia?
<thomasga>
yea, or just code :p
<thomasga>
(or CI logs)
<avsm>
mato: djwillia: yeah starting the tagging process will remove the number of dev packages we have
<yomimono>
mato: possibly there are other changes that have been merged in master for solo5 packages that should bementioned
<yomimono>
mato: but for the mirage3 api conforming stuff, I think that's sufficient
<hannes>
mato: for solo5 it is not much of an issue IMHO, for mirage we should have extensive changelog, similar to what OCaml has
<thomasga>
hannes: do you want that for all packages? or just for the mirage signatures + tool updates?
<djwillia>
mato: yeah i agree the changelog for solo5 should be just "release..."
<yomimono>
it would be amazing to have something like the wiki gasche put together for the 4.04 ocaml release
<thomasga>
anyway, it's a lot of work to get all right and it will take time
<hannes>
thomasga: for all packages which have a release history, esp. important for mirage since there are lots of breaking changes, and we'll be in business to move old code to new code.
<yomimono>
but I intend to write something higher-level than the CHANGES.md in mirage/mirage for the mirage.io blog, which others can help to iterate on
<thomasga>
hannes: ok so we need tooling for gathering all CHANGES into the same place
<mato>
hannes: rightm i think we're in agreement for the solo5 components -- they've never been officially released yet (I don't count the initial versions in OPAM as a "release")
<mato>
hannes: so the versions for mirage 3 can just say "release for mirage 3"
<thomasga>
yea, that would be great. Although, to be honnest, I don't think we will break many existing programs :p
<avsm>
thomasga: I believe that "odig changes" might do a lot of the work for us now
<thomasga>
mato: yes, makes sense to me too
<avsm>
ok, so amirmc GemmaG and I are meeting tomorrow to go through the release checklist, so we'll add "changelog" to the pile
<hannes>
thomasga: gasche's thing is awesome, and I hope we have the resources to put that together for mirage[-types/types-lwt/runtime], in addition to blog posts (which are highly appreciated)
<avsm>
hannes: thomasga: a convenient way to update the changelog is to port existing code and just note what we did
<thomasga>
well, I don't have any unikernel, so not breaking change for me :p
<hannes>
avsm: I went for mirage+functoria several times through the git log
<yomimono>
look under your seat, thomasga
<yomimono>
you get a unikernel!
<hannes>
thomasga: oh, mirage-seal is out of order? ;P
<avsm>
hannes: yeah i meant the annotated changelog
<GemmaG>
I'm also pulling together a range of blog posts/articles from OCL on related Mirage projects
<hannes>
thomasga: there's likely breakage due to mirage-types-lwt ocamlfind package introduced by myself 15 hours ago in your irmin/git..
<avsm>
I've started penning some Docker ones on vpnkit datakit, just notes at the moment
<yomimono>
mato: anything else related to beta1?
<thomasga>
V1 -> Mirage_types
<mato>
yomimono: i think that's all from me
<hannes>
thomasga: or V1 -> Mirage ?
<thomasga>
(and ok, maybe I have a few unikernels lurking around)
<yomimono>
Mirage_types is long :(
<thomasga>
hannes: let's keep the names consistent
<mato>
yomimono: i'd appreciate a heads up on when you intend to start the tagging process, once you think we're ready for it
<thomasga>
`mirage-types` is the opam package already
<yomimono>
mato: copy that.
<avsm>
why not just Mirage?
<yomimono>
Mirage is already the library for the frontend stuff
<thomasga>
because it's in the `mirage-types` package
<yomimono>
default_network etc
<hannes>
I'm all for just Mirage (and Mirage_LWT)
<avsm>
oh yeah, for the configuration
<yomimono>
OK, that's all the agenda stuff, we can keep discussing names though
<mato>
do we no longer have a need for the V1 in the name?
<yomimono>
nope
<avsm>
the frontend stuff is easier to change (mainly mirage-skeleton) than forcing all our other libraries to type Mirage_types
<thomasga>
I find it too long too, but I really like consistent names too
<avsm>
Rresult uses Rresult.R
<avsm>
Mirage.M
brson has joined #mirage
<avsm>
its fairly opaque though
<hannes>
(I'll give my name vote to thomasga)
<thomasga>
I'll vote for me
<thomasga>
anyway, I not fully convinced yet, I just don't want to have to remember 10 different names
<avsm>
I'll give my name to thomasga, unless he chooses to call it some weird French module name
<yomimono>
mirthulhu
<amirmc>
It'll be named after an animal.
<thomasga>
(e.g. in Mirage2 we had to install `mirage-types-lwt`, use the `mirage-types.lwt` library and open `V1_LWT`)
<avsm>
sounds like the end of the call though! should we release unpureocamlbot from his burden?
<amirmc>
+1
<mato>
+1
<yomimono>
+1
<thomasga>
let's call it egarim then :p
<thomasga>
+1 too
<avsm>
thanks everyone! and yomimono for MCing expertly
<avsm>
unpurecamelbot: commit done
<unpurecamelbot>
done
<mato>
Le_Mirage :-)
<engil>
unpurecamelbot: bye
unpurecamelbot has quit [Quit: unpurecamelbot]
talex5 has quit [Quit: Leaving]
GemmaG has left #mirage [#mirage]
amirmc has quit [Quit: Leaving.]
<mato>
thanks all, gotta run
<yomimono>
thanks folks :)
<avsm>
laters!
<avsm>
thomasga: Espejismo ?
<yomimono>
V1 and V1_LWT aren't generally things you refer to a lot, you either open them or mention them in a functor definition and then that's it
<yomimono>
clarity > brevity I guess
<yomimono>
really I just refuse to do this more than once
<avsm>
i dream of the day that V1_LWT will be the identity type for our multicore effect release of OCaml
<thomasga>
yea
<hannes>
MIRAGE_CORE_TYPES
<thomasga>
`open M`
<hannes>
M and M_LWT would also work IMHO
<thomasga>
anway I'll sync with yomimono offline about that
<yomimono>
it sounds like you have all the votes thomasga :)
<thomasga>
mouahahahahaha
noddy has quit [Ping timeout: 265 seconds]
<thomasga>
it's time to leave then :p
thomasga has quit [Quit: Leaving.]
insitu has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
fgimenez has quit []
andreas23 has quit [Quit: Leaving.]
djwillia has quit [Ping timeout: 260 seconds]
noddy2OOO has joined #mirage
avsm has quit [Quit: Page closed]
insitu has joined #mirage
agarwal1975 has quit [Quit: agarwal1975]
insitu has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
noddy2OOO has quit [Ping timeout: 265 seconds]
agarwal1975 has joined #mirage
mort___ has quit [Quit: Leaving.]
brson has quit [Quit: leaving]
insitu has joined #mirage
vramana1 has joined #mirage
brson has joined #mirage
vramana has quit [Ping timeout: 268 seconds]
vramana1 is now known as vramana
insitu has quit [Read error: Connection reset by peer]
insitu has joined #mirage
AltGr has left #mirage [#mirage]
insitu has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
mort___ has joined #mirage
noddy2OOO has joined #mirage
yomimono has quit [Ping timeout: 250 seconds]
yomimono has joined #mirage
agarwal1975 has quit [Quit: agarwal1975]
yomimono has quit [Ping timeout: 250 seconds]
mort___ has quit [Quit: Leaving.]
noddy2OOO has quit [Ping timeout: 245 seconds]
yomimono has joined #mirage
smondet has quit [Ping timeout: 250 seconds]
miragebot has joined #mirage
<miragebot>
mirage/master c83e455 Hannes Mehnert: Merge pull request #736 from hannesm/fixed-arp...
miragebot has left #mirage [#mirage]
<miragebot>
mirage/master fd4c874 Hannes Mehnert: compilation fixed in arp master f276a55
<miragebot>
[mirage] hannesm pushed 2 new commits to master: https://git.io/v1yIz