avsm changed the topic of #mirage to: mirage 2 released! party on!
mort___ has quit [Quit: Leaving.]
yegods has quit []
yomimono has joined #mirage
yomimono has quit [Ping timeout: 244 seconds]
yomimono has joined #mirage
yomimono has quit [Client Quit]
<hannes>
problem with the dhcp thingy is that configure gets the right cmdline arguments (and thus evaluates the graph correctly), but build doesn't... solution is upcoming (caching the config arguments in .mirage-args)
brson has joined #mirage
brson has quit [Ping timeout: 265 seconds]
brson has joined #mirage
brson has quit [Read error: Connection reset by peer]
brson has joined #mirage
rgrinberg has joined #mirage
brson_ has joined #mirage
brson has quit [Ping timeout: 250 seconds]
brson_ has quit [Read error: Connection reset by peer]
brson has joined #mirage
copy` has quit [Quit: Connection closed for inactivity]
andreas23 has joined #mirage
andreas231 has quit [Ping timeout: 260 seconds]
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 [Quit: Lost terminal]
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
rgrinberg has quit [Ping timeout: 252 seconds]
jermar has joined #mirage
jermar has quit [Remote host closed the connection]
noddy has quit [Ping timeout: 248 seconds]
noddy has joined #mirage
brson has quit [Quit: leaving]
brson has joined #mirage
insitu has joined #mirage
insitu has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
jermar has joined #mirage
jermar has quit [Ping timeout: 250 seconds]
andreas23 has quit [Quit: Leaving.]
insitu has joined #mirage
AltGr has joined #mirage
andreas23 has joined #mirage
jermar has joined #mirage
<mato>
hannes: Indeed, if I specify the same dhcp args to mirage build as well as mirage configure then dhcp builds fine
brson has quit [Quit: leaving]
fgimenez has joined #mirage
fgimenez has joined #mirage
fgimenez has quit [Changing host]
srenatus[m] has quit [Ping timeout: 258 seconds]
mattg has quit [Ping timeout: 258 seconds]
demonimin has quit [Ping timeout: 258 seconds]
mattg has joined #mirage
demonimin has joined #mirage
haesbaer1 has joined #mirage
mort___ has joined #mirage
haesbaert has quit [Ping timeout: 258 seconds]
tg has quit [Ping timeout: 258 seconds]
tg has joined #mirage
srenatus[m] has joined #mirage
mort___1 has joined #mirage
mort___ has quit [Read error: Connection reset by peer]
fgimenez has quit [Ping timeout: 265 seconds]
fgimenez has joined #mirage
fgimenez has joined #mirage
fgimenez has quit [Changing host]
insitu has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
ptrf has joined #mirage
copy` has joined #mirage
insitu has joined #mirage
insitu has quit [Client Quit]
noddy has quit [Ping timeout: 246 seconds]
mort___ has joined #mirage
mort___1 has quit [Read error: Connection reset by peer]
mort___ has quit [Quit: Leaving.]
mort___ has joined #mirage
mort___ has quit [Quit: Leaving.]
fgimenez has quit [Ping timeout: 240 seconds]
fgimenez has joined #mirage
fgimenez has joined #mirage
fgimenez has quit [Changing host]
insitu has joined #mirage
insitu has quit [Ping timeout: 256 seconds]
insitu has joined #mirage
insitu has quit [Ping timeout: 250 seconds]
noddy has joined #mirage
insitu has joined #mirage
mort___ has joined #mirage
mort___ has quit [Client Quit]
mort___ has joined #mirage
agarwal1975 has joined #mirage
yomimono has joined #mirage
unpurecamelbot has joined #mirage
<unpurecamelbot>
I'll be logging this meeting…
<yomimono>
you're early, friend!
<reynir>
AArch64 :o
mort___ has quit [Quit: Leaving.]
<engil>
always
<engil>
the bot is more active than I am :)
<yomimono>
that's a mark of true software engineering success
<engil>
until they take other society
<engil>
over…
<yomimono>
that's also a mark of true software engineering success
<yomimono>
you know the skynet folks were high-fiving each other right up until robots ate them or whatever happened in that movie
<engil>
haha, and well, a society run by unikernels written in OCaml, what's not to like.
insitu has quit [Ping timeout: 244 seconds]
<hannes>
.oO(lucky me will likely be around during this meeting today)
rgrinberg has joined #mirage
smondet has joined #mirage
noddy has quit [Ping timeout: 260 seconds]
andreas23 has quit [Quit: Leaving.]
<reynir>
\o/
demonimin has quit [Ping timeout: 256 seconds]
demonimin has joined #mirage
djs55 has joined #mirage
amirmc has joined #mirage
<hannes>
mato: I've not used mirage describe... is it sensible to be used without a configuration? or, is there anything apart from help which is sensible to use without running configure first?
<yomimono>
hannes: I don't frequently use mirage describe but it's reasonable to use without configuring since it will look at config.ml itself & tell you about keys
<hannes>
also, lazyness of builds - it looks very much like we would like to have those, but to achieve that we have to reimplement some pieces of make.. basically we should only recompile the config.* if config.ml changed (and if we have that in place, there's not really a need to dump configure's sys.argv onto disk)
avsm has joined #mirage
<avsm>
hello!
<yomimono>
hi avsm!
<amirmc>
(waves)
<avsm>
I have just destroyed 4 VMs with a build-a-thon
<avsm>
so a perfect time for a mirage call :) who else is here? Hi amirmc!
<yomimono>
update: beta not cut yet because errors pr is outstanding
<yomimono>
(in the sense of unresolved, not in the sense of it's super great)
<hannes>
errors, then renames, then cut?
<yomimono>
good god I hope so
<avsm>
errors, then renames, then deploy infra, then cut
<avsm>
self-host before tag, shouldnt take too long if everything builds :)
GemmaG has joined #mirage
<amirmc>
errors, then renames, then deploy infra, then cut, then write some stuff :P (still need to help users transition)
<hannes>
avsm: I don't understand what "self-hosted before tag" means
<avsm>
overall, the build is in good shape. Mainly yomimono and hannes changes have all settled in and docs.mirage.io is uptodate as of this morning
<avsm>
hannes: deploy mirage-www (and hopefully DNS) using the trees that we are announcing as beta
<yomimono>
i'm very excited about hannes's build changes :D
<avsm>
it needs some adaptation to hannes (awesome) build changes
<yomimono>
already loving getting faster nicer behavior without having to remember --no-opam
<hannes>
well well, the rather big changes to mirage + functoria showed some problems with the CLI (at least to me), and @mato is right that we need to review/design the workflow
<hannes>
I'm happy that you are happy, and the changes improve mirage imho. there is now separation between phases, no dependency onto Makefile, and we use opam files for dependency management
<hannes>
(plus I removed code :D)
<mato>
\o/
<avsm>
Yes, so the new scheme that generates an OPAM file is just awesome. I'm going to run past AltGr when I have it running to see if anything can be helped by OPAM2
<amirmc>
yomimono: Could you paste the link for the errors PR? Mainly so it shows up in the logs for this chat.
<hannes>
one item I'm still not sure about is: does anyone _care_ about "-f <configfile>"? if not, my brain could more easily come up with a nice deployment workflow
<avsm>
I haven't tried it in detail yet aside from a smoketest, so I expect it'll take a week or so for people to try it out and report back.
<avsm>
hannes: mirage-www uses that, but could be convinced not to
<hannes>
(removing -f, settle to one unikernel per directory with a config.ml)
<hannes>
avsm: mirage-skeleton Makefile also use it, but trivial to get rid of... the actual question was: is anyone having multiple config files in a single directory
<avsm>
hannes: not me, since i just lift the reason for having multiple config files into a parameter in one config file, usually
<mato>
one directory per unikernel seems reasonable to me. there's plenty of precedent in tooling-land for "one directory per project".
<avsm>
its certainly an ok limmitation for beta, and fix if anyone complains
<yomimono>
I'd suspect the problem would instead be people naming their only config.ml something else, so they can have a Config module
<yomimono>
for something in their application
<yomimono>
that can of course be worked around but is an annoyance
<hannes>
canopy has Canopy_config... so lots of projects prefix with their project name, which is sensible
<amirmc>
We should explicitly poll people we know just to check. e.g. sgrove, ericsson folks, etc.
<hannes>
(and big thanks to mato, and yomimono, as well as others for reviews of my mirage/functoria changes (also drup!))
jermar has left #mirage ["Leaving"]
<avsm>
also thanks to drup for fixing the ocamlgraph exception!
<yomimono>
+1
<avsm>
Soooo, the open issues remaining are either maddeningly tedious or difficult
<avsm>
lets start with tedious... the Block/Kv_ro/fs ones that Mindy has been hammering away at
<avsm>
This completes the move to using Result.t instead of exceptions, but there are a lot of libraries that used the old style
<avsm>
one open question was fat-filesystem, wasnt it yomimono ?
<yomimono>
yes, I have some patches for it but not a complete rebuild
<avsm>
That's quite old code and may not be that useful now. djs55 -- thoughts on this?
<avsm>
should we just disable for beta1 or complete the port?
<mato>
We don't have any other filesystem/persistence solution, do we?
<hannes>
as mentioned in 698 we're not yet done with errors, it fails e.g. for TLS (customizable errors) and being able to handle errors properly (apart from erroring out)
<djs55>
I wouldn't use the code for anything serious — it's good enough to synthesise simple disk images containing kernels, ramdisks etc. But we are lacking an alternative at the moment :(
<avsm>
mato: right now crunch is the only other way to go
<djs55>
ideally there would be some Irmin-on-block or similar
<avsm>
someone might start working on Irmin-on-block soon, but not started yet so wont be ready for release
<hannes>
I'd also appreciate a fat-on-block for things where the complexity of irmin is not needed. KISS
noddy has joined #mirage
<avsm>
so lacking an alternative, and that it'll take time, should we just leave the library marked as broken for beta1, but keep the functoria runes so that it can be fixed through december?
<yomimono>
it's completely nonobvious to mirageos users that fat shouldn't be used for anything serious atm
<mato>
it'd be an interesting project for someone to come up with a persistent key/value store entirely in ocaml (say, something along the lines of LMDB)
<mato>
hannes imo ^^^ is what you actually want
<avsm>
mato: yes, someone may be working on that soon, but not yet confirmed
<djs55>
the problems I know about with the fat implementation are around locking, but the impact of that depends on the use-case. If people expect to be able to send lots of concurrent FS operations at it safely they'll probably be disappointed; if someone just wants to store a few files and retrieve them again it's ok
<djs55>
after I've finished my current qcow work I can take a look at fat-filesystem again
<avsm>
If djs55 cant fix up fat-filesystem i'll put it on my list. yomimono has quite done her time in this part of the stack :P
<hannes>
djs55: \o/
<yomimono>
djs55: I'd appreciate that a lot :D
thomasga has joined #mirage
<avsm>
This does lead to the hard question though: opening up FLOW to be [>`Msg of string]
<djs55>
It's better than nothing
<djs55>
I look forward to irmin on block :)
<avsm>
that's quite a bit of churn again isnt it, including in the network code?
<hannes>
avsm: imho needed for 3.0, as said in 698 (unfortunately I won't have time for this in december)
<yomimono>
yeah, but if it's unusable without it, it's better to do it now
<yomimono>
if it's just FLOW that's actually not too bad
<avsm>
yeah
<avsm>
we've punted a bit by making it Ok `Eof so far
<avsm>
thereby declaring Eof not to be an error :)
<yomimono>
errrr
<yomimono>
that's not quite correct
<yomimono>
It's error closed for writes
<yomimono>
It wasn't intended to be a punt -- when reading, that's really not a problem
<avsm>
oh true, we always want to handle Eof on reads as it's a normal case
<hannes>
yomimono: I suspect in block we'll end up in the same issues (e.g. an encrypted layer getting a block, providing a block)
<yomimono>
if that's not your experience, then yes that's a problem in the design and we should fix it
<thomasga>
(I completely missed the beginning of the meeting but irmin on block sounds great to me)
<yomimono>
hannes: there are already things that get a block, provide a block in that PR -- see mirage-block
<avsm>
The thing not clear to me is why "Error `Closed" and not "Ok `Closed", following the same reasoning as Eof
<yomimono>
because if you tried to write to something and you can't, that's a problem
<avsm>
isnt it as normal to write to a channel closed by the other side?
<yomimono>
if you see eof you know it's closed too
<yomimono>
perhaps I'm being obtuse
<avsm>
on the read end, yes, but if I'm just writing (e.g. a proxy), then the only way to detect the other side has disappeared is if I get a Closed on write
<avsm>
the equivalent of Unix.write returning 0
<avsm>
alright, lets declare this a blocker and continue on the PR? There's consensus that it needs to be addressed before 3.0
<avsm>
the blocker list is currently looking much smaller, which is good :)
ricarkol has joined #mirage
<avsm>
Ok... how's the Solo5 ELF review going mato?
<mato>
avsm: Equivalent of UNIX EPIPE you mean...
<mato>
avsm: That's all done and merged. I'm basically waiting for the network stack key renames to be finalised and merged (#707 and friends), then I can update unikernel-runner and we should be all set to deploy infra using it
<avsm>
awesome!
<djs55>
I guess with protocols like TCP sometimes the write will succeed but the data is never received because the remote has gone away whereas sometimes the write happens after the local end knows the remote has gone away and so it fails locally?
<avsm>
Anyone else got any PRs that haven't been shown attention?
<yomimono>
djs55: yes, I'm thinking about the latter case
<avsm>
djs55 mato: yes that's the scenario I was thinking of. You dont always close the channel yourself
<avsm>
Ok, because people have to dash, rearranging agenda slightly.
<avsm>
GemmaG: you had "ideas for new logo" on the agenda for MirageOS3. exciting!
<hannes>
there's still this topkg'ing of cstruct, tcpip, mirage-platform... any ideas when + who will do that? (+the charrua-client safe_foo which I complained on via PM)
<djs55>
is topkg'ing required for Mirage 3? (sorry for the newbie question)
<avsm>
hannes: i have a topkg of tcpip that needs rebasing. those are not blockers for the beta though
<thomasga>
the logos looks great!
<GemmaG>
It would be good to start a conversation about logo ideas and go from there - this was exploratory for now :)
<amirmc>
GemmaG: which image in particular? Are they different or stages?
<mato>
where's the palm trees? :-)
<yomimono>
hannes: to me? if so I forgot, if not can you explain
<avsm>
+1 to the logo! I like the 3 stages a lot
<hannes>
(marrakesh: ~10 people already signed up (you sign up by writing a mail to me))
<hannes>
yomimono: no, to avsm
<mato>
hannes: is there a date already set for marrakesh hackathon?
<thomasga>
about topkg'ing. I was thinking about creating a custom .carcass stuff for mirage projects, and maybe link that with the mirage too to be able to `mirage init` a new project and get a fresh template
<avsm>
Hang on, could we finish with one thread at a time please?
<hannes>
mato: 2-7 march 2017. i so far only mailed to last years participants. sorry.
<avsm>
Everyone is just interjecting random things so far.
<avsm>
Logos: feedback to GemmaG please
<GemmaG>
Yes please - new ideas also welcome. I'll set up a thread
<avsm>
This is an initial draft, so ideas/feedback to her now, mirageos-devel mail later?
<avsm>
I like the 3 stages incidentally. Could we use those to mark libraries as alpha/beta/stable for Mirage?
<thomasga>
for the logos: we need a black&white version of them too
<avsm>
ok, thanks GemmaG! I think an overhauled look and feel of mirage.io by January is feasible too :-) Something simpler than the current one with the logo seems very do-able
talex5 has joined #mirage
<thomasga>
not sure how the current color scheme will work for that (I guess it could, but need to think about that)
<avsm>
and a favicon as well i guess
<avsm>
something has to replace the current llama that has been on the github org as a placeholder since 2008
<GemmaG>
Sure - I'll work on those and email the list
<thomasga>
yea. And a big wall poster version.
<avsm>
I love that llama
<amirmc>
and the sandcat on the twitter profile
<avsm>
Yes, yomimono's sandcat!
<avsm>
Alright, onto the hackathon then. hannes!
<thomasga>
and tee-shirts!
<avsm>
Did the mail ever go out to mirageos-devel hannes , about the hackathon
<avsm>
i think it only went to last year's attendees
* avsm
is just trying to dig out the email to check, but cant find it
<hannes>
so, it will happen 2-7 march 2017. there are spots available. I'll mail mirageos-devel soon
<avsm>
awesome
<GemmaG>
Yeah - also thinking of tshirts for hackathon - will work on them over next few weeks
<avsm>
for those who cant make it, there will be a cambridge hackathon contingent too
<avsm>
oh, I got a bunch of ODroid C2s that are more powerful for routing, but are arm64
<hannes>
275 EUR per person, you can also arrive on 1st and leave on 8th. you can also just drop by the weekend. spots are limited due to number of beds. I try to diversify people
<hannes>
I don't want to send anybody away (due to limited space or lack of money)
<avsm>
so book early
<avsm>
if anyone wants to organise something in their local area as well, then of course also welcome to -- tshirts can be shipped :-)
<avsm>
ok to pick up the next thread: topkg
<avsm>
it's not greatly documented so far, and we've had some people starting to help with ports
<hannes>
if the demand is higher, I can also try to find more accomodation (but I don't really want to organise events for 50+ people)
<avsm>
thomasga: a skeleton repo would be really useful for mirage
<avsm>
hannes: 50+ would be tough in morocco :P
<thomasga>
avsm: ok, I will see what I can do
GemmaG has left #mirage [#mirage]
<avsm>
generally speaking topkg works well, but there's all the random things we've learnt that need to be written down somewhere. i can help too
<hannes>
(since I need to enjoy the event by sitting in the sun and get sunburned ;)
<avsm>
(e.g. VERSION_NUM in META and not VERSION, that sort of thing)
<avsm>
good news is that the odig format seems to work well, and codoc is making progress
<avsm>
http://docs.mirage.io/odoc/ may become the default soon, just as soon as some css issues are fixed by upstream
<djs55>
I like thomasga's idea of some kind of "mirage init" to create a topkg project template
<avsm>
yeah; agreed.
<avsm>
especially in the new `opam` file generation world we live in
<avsm>
Alright, next on agenda was CI
<avsm>
I'm going to punt massively. I had it working, live, and then destroyed the entire setup 1 hour before this call. I showed it to yomimono though :P
<avsm>
will get it up and running later today i hope
amirmc has quit [Quit: Leaving.]
<yomimono>
it definitely existed
<avsm>
we have machines on ci.mirage.io for this, and the github webhooks etc are working, and code is at https://github.com/avsm/mirage-ci
<yomimono>
I can 100% verify that it was there and had logs and tested stuff and showed colors and knew about PRs
<avsm>
will mail the list when it exists for more than a day
<hannes>
avsm: speaking of which, what does "it" and "working" mean? is it about the opam libraries for now?
<hannes>
or... since we now have opam files for unikernels, do we have a CI which does reverse deps for unikernels? ;)
<avsm>
it runs these phases for now, including revdeps
<avsm>
and so it can easily be extended to do revdeps for opam unikernels
<avsm>
i'm also adding mirage/mirage-specific tests (e.g. run mirage_skeleton)
<avsm>
and revdeps can be configured to be allowed-failures
<avsm>
The CI also resolves all the Git heads into concrete revisions so the script to build it is reproducible
<hannes>
avsm: idea: please use individual unikernels, not mirage-skeleton as a bulk run.
<avsm>
hannes: yes!!
<avsm>
hannes: I'm doing exactly that, just because the Makefile in mirage-skeleton stresses me out with the environment propagation
<hannes>
(thus skeleton becomes 10*4 projects, and we can add the example unikernels from other repos as well)
<avsm>
this is much easier now thanks to opam generation. yay
<hannes>
.oO(looks like opam generation was worth the nights I spent on it)
<avsm>
:-)
<avsm>
Last item on agenda is a headsup about performance testing; it's making progress, there is a forward port of iperf, and I chatted with Imada-san about opening up the code and running it regularly under the CI
<avsm>
hopefully more progress in the next two weeks. we have a bare-metal machine to run them on regularly and reproducibly, and he is working on shell scripting them up to be automated with kvm/xen
<avsm>
mort___ helping with that also
<mort___>
.
<mato>
excellent! looking forward to trying out the perf tests
<hannes>
I'm much slower with my CI setup (FreeBSD) -- so far I achieved a) server with IP, b) install via serial-over-lan a custom FreeBSD, now slowly getting towards a system packages build, later a datakit-based CI on there. plus I've lots of v4+v6 addresses there (and can deploy FreeBSD/solo5) -- https://0bin.link/paste/f23lPTRK#7n-steVDk6aRiUYjqN2HzprpmAhoMts73T4sCIY9+hR
<avsm>
hannes: you have lots of ipv4 addresses??? awesome!
<avsm>
keen to get FreeBSD/solo5 in the live pool
<avsm>
alright, AOB?
<hannes>
avsm: well, I host at a VPN provider, they have IP :)
<avsm>
anything exciting going on with projects? I've got Odroid C2s and am playing with an aarch64 port of Mirage. everything compiles in userspace ELF mode atm :-)
<mato>
Is everyone happy with the workflow changes? Any concerns?
<mort___>
have a cubietruck+ but that should be straightforward and not nearly as exciting
<hannes>
I'll start a new blog with a friend, and for this removed all JS and bootstrap CSS from canopy
<mato>
hannes: what else would you like to change?
<avsm>
mato: I need to use it more but will have an opinion by next week
<hannes>
avsm: simplify for me is equal to removing... but that's me, like to remove code
<hannes>
mato: I'd want more caching and more determinism
<hannes>
mato: such as: mirage configure <params> --> compile config.XXX -> then get mirage build etc. working... also needs a separate distclean and clean.
<thomasga>
I also would like random generated names for my unikernels
<hannes>
atm mirage <subcommand> deletes + recompiles config.XXX every time
<mato>
right, yeah, i saw that
<thomasga>
e.g. `mirage build spitting_llama`
<avsm>
thomasga: that sounds suspiciously unrandom
<hannes>
thomasga: I agree, if we get deterministic random (i.e. mirage configure --dhcp true always leads to spitting_llama)
<thomasga>
or `mirage run beardy_anil`
<avsm>
I think the call has reached its natural conclusion :)
<mato>
:-)
<avsm>
thanks everyone!
<avsm>
unpurecamelbot commit done
<thomasga>
:p
<unpurecamelbot>
done
<yomimono>
thanks for facilitating, avsm :)
<hannes>
certainly the url in an opam file seems to be underspecified!?
<mato>
thanks all. btw i'll be in cambridge next week
<avsm>
mato: yay!
<hannes>
mato: yay. i won't
brson has joined #mirage
talex5 has quit [Quit: Leaving]
<mato>
hannes: url underspecified for what? do you want to use it in the opam generation somehow?
<mato>
right now the generated opam is not used for anything except installing it's dependencies, is that going to change?
<hannes>
mato: somehow I'd like to be able to say "mirage-skeleton, but only console subdir" for change tracking (to update via CI)... but atm only mirage-skeleton.git is possible
<hannes>
mato: I want to use it for CI and reverse dependencies (I guess avsm wants that as well)
<avsm>
yeah
<mato>
so e.g. in terms of CI/CD you want an "opam upgrade" to rebuild your unikernel if it (or it's dependencies) have changed?
<hannes>
mato: if config.ml changes, I'd like to rerun mirage configure with all sensible key combinations leading to a set of opam files.
<hannes>
if a dependency changes (or the unikernel source itself), I'd like to rebuild all those unikernels
<mort___>
i wondered about this a while ago but haven't tried doing it yet — would it be possible (and useful) to try and do a complete local opam install, inside the directory containing the config.ml?
<mort___>
wondering if that would improve replicability
<hannes>
it is doable right now if we just use coarse-grained deps (and adjust the build rule slightly to do a cd <subdir>; mirage build)
<hannes>
mort___: that's some opam 2.0 feature I guess, I think this is orthogonal to what I have in mind (dev machine vs CI)
<mort___>
ah ok
<mort___>
yes perhaps
mort___ has quit [Quit: Leaving.]
yomimono has quit [Quit: Leaving]
<hannes>
mato: oh, thanks for the extensive mailing list thread on workflow. I'll contribute my ideas there.
mort___ has joined #mirage
vramana has joined #mirage
miragebot has joined #mirage
<miragebot>
mirage/master 4ebd6b5 Mindy Preston: rename gateway to ipv4-gateway
<miragebot>
[mirage] yomimono pushed 3 new commits to master: https://git.io/v133X
<miragebot>
mirage/master 6c8a3cc Mindy Preston: rename ipv4 to ipv4_address, ipv4_network to ipv4; remove custom parse/print