hannes changed the topic of #mirage to: bug cleaning day every first friday in month (14:00 UTC - late, next: 2nd Feb); MirageOS 3 is released, happy hacking!
demonimin has quit [Quit: No Ping reply in 180 seconds.]
demonimin has joined #mirage
maker has quit [Ping timeout: 248 seconds]
maker has joined #mirage
dtornabene has joined #mirage
gentauro has quit [Ping timeout: 240 seconds]
gentauro has joined #mirage
AltGr has joined #mirage
argent_smith has joined #mirage
mort___ has joined #mirage
AltGr has left #mirage [#mirage]
mort___ has quit [Quit: Leaving.]
AltGr has joined #mirage
mort___ has joined #mirage
mort___ has quit [Quit: Leaving.]
mort___ has joined #mirage
mort___ has quit [Quit: Leaving.]
mort___ has joined #mirage
mort___1 has joined #mirage
mort___ has quit [Read error: Connection reset by peer]
<yomimono>
first up on the agenda is a request from lars_kurth from last time : is github.com/mirage/mirage-www/TROVE up to date?
<hannes>
I put in the first point -- lars_kurth was curious whether TROVE is still up to date.
<yomimono>
I had a look at it last week and put in a PR to update it, which I see has been merged, but I almost certainly missed some stuff
<mato>
TROVE is only for xen-related repos or everything?
<yomimono>
everything, solo5 stuff included
<yomimono>
(if it wants to be)
<mato>
sure :)
<hannes>
I've no clue what TROVE is used for, but it looks like we've atm at least 3 ways of tagging MirageOS packages: TROVE (used by xen project), opam tag (used anywhere?), github tags (which were introduced recently)... can we please settle on a single on and use it?
<lars_kurth>
Hi all
<yomimono>
lars is asking because it's included in Xen's metrics about the project, but that's because we're an incubated project, not because of the xen-specific content AFAIU
<yomimono>
(oh, but lars can probably speak for himself! sorry!)
<lars_kurth>
I don't care about the mechanism: I am just trying to find a sensible way to get an up-to-date list of git repos. TROVE is what Anil suggested
<lars_kurth>
But then it got stale sometimes in mid 2017
<mato>
hannes: by "github tags" do you mean the thing presented as "topics"?
<mato>
lars_kurth: right, so as long as you have a script to run that produces some list of repos, you're fine?
<lars_kurth>
mato: correct
<hannes>
mato: yes, https://github.com/topics/mirageos would be my current favorite since every repository can add on their own "mirageos" and everybody can browse it
<mato>
hannes: do we care about repos not on github? (presume no, just asking)
<hannes>
mato: hmm, maybe opam tag is more suitable than ;) you are right we shouldn't move any step towards github lock-in
<mato>
lars_kurth: is the repo list supposed to be somehow "blessed" or is it ok that anyone can add to it?
<Drup>
are opam tags really reliable ?
<Drup>
I remember the tagging to be more or less random, depending on the maintaner
<lars_kurth>
mato: I am just using it to get stats about what is happening in the community. This should be useful for you guys (or someone in your group who cares about community and metrcis).
<lars_kurth>
Whether it needs to blessed or not, is your call
<yomimono>
I suspect that if we were to use opam tags we'd need to have an automated process to produce a list resembling TROVE out of them anyway
<yomimono>
same for github topics
<yomimono>
or no?
<mato>
probably, in either case mirage-www is not the right place for it to be
<mato>
i'm happy to write (and host/run) a script that queries for github tags, optionally adds a static list of repos (to address lock-in) and commits it to a trove-style list somewhere
<yomimono>
excellent, thanks mato :)
<lars_kurth>
That would work for me
<mato>
ok, if there are no objections... then i'll do that
<mato>
once it works we can switch from TROVE
<yomimono>
sounds good! and like perhaps we could move on...
<yomimono>
...to the next item, which I put on the agenda on behalf of kensan without asking :P
<lars_kurth>
mato: thanks. Please CC me when you have it
<yomimono>
Muen SK v0.9 was released with support for MirageOS subjects via solo5 :D
<mato>
lars_kurth: ack
<kensan>
Hi btw! \o
<yomimono>
hi! :D
<yomimono>
congratulations on the release!
<kensan>
I am half attending ;)
<kensan>
thanks! Really psyched that we run our project website through MirageOS on Muen
mort___ has joined #mirage
<lars_kurth>
Another quick thing before I run off: GSoC application submitted. Thanks for your input
<yomimono>
yay! thanks for taking care of that, lars!
djs55 has joined #mirage
<lars_kurth>
Outreachy may be a bit of a problem this year: I have some funds (not sure yet for how many slots), but mentors need to copy their projects into the outreach system and I expect the level of detail needed is higher than what you have now
<lars_kurth>
I am wondering whether it is worthwhile to go through the effort (and we only have until Feb 12th) to do all this
<reynir>
oh hi
<yomimono>
I wasn't sure until today, but I should be able to set aside time for doing that lars_kurth
<yomimono>
I can coordinate with you offline, I have an email from you I should respond to
<lars_kurth>
Let's do that
<yomimono>
great :)
<kensan>
avsm suggested we could write a small blurb about it for the mirage.io blog which points to the article explaining how to run MirageOS unikernels on Muen.
<yomimono>
to pop the stack a bit, there's an article on running mirageos on muen at https://muen.sk/articles.html which is a good read :)
<kensan>
Will try to do that.
<hannes>
kensan: tbh, I'd wait until muen + mirageos are friends out of the box...
<mato>
yeah. my wish is to have this happen by end of Q1
<kensan>
hannes: Yeah, I was wondering if that should be postponed until the pins are not needed anymore.
<kensan>
mato: Cool, then I think its better to wait until its all spiffy ;)
<mato>
ideally ready by marrakesh, then we can polish there and release just after when on real internet :)
<yomimono>
excellent :D
<mato>
kensan: by the way, if you can keep the "running muen in nested kvm" in the back of your mind, that'd be useful...
<mato>
kensan: (now that we have the new ci, but that's a later topic in the agenda)
<kensan>
mato: Yeah, we are revisiting that in regular intervals.
<mato>
kensan: Thanks. I'm happy to run whatever bleeding-edge KVM it might need
<kensan>
mato: We not have Muen travis tests via Docker containers where we build the bochs image
<kensan>
s/not/now/
<kensan>
mato: In principle you could run parts of the Solo5 tests in Bochs and check the log output but I would think that is quite a bit of work just for that...
<mato>
kensan: I'd rather not, it'd be slow, and I don't have the hardware resource for that right nwo
<mato>
kensan: so better to wait until nested VT is sorted
<kensan>
mato: yeah, exactly. I agree.
<yomimono>
so next up --
<yomimono>
a quick reminder that we have another bug cleaning day on friday
<yomimono>
people generally start in the UTC afternoon and coordinate here
<yomimono>
not sure how people's FOSDEM schedules will affect that but I'll at least be able to hang around and generate github noise
<mato>
git push origin delirium :-)
<yomimono>
next next: hannes is looking for coauthors ;)
<hannes>
no.
<hannes>
first "no starch press" is looking for someone for an OCaml book ;p
<hannes>
and the other things are just delayed, sorry.
<hannes>
mato and myself will be at fosdem this weekend, if you're around, chat us up :)
<yomimono>
cool :) got time to tell us about solo5 ci updates, mato?
<mato>
yup
<mato>
so, we can now run end-to-end tests for solo5 using nested virtualization on kvm
<mato>
until now this was only happening on travis using software emulation for qemu for the virtio target
<mato>
This is done for both Linux (Debian 9) and FreeBSD (11.1-RELEASE)
<yomimono>
nice! is there a place where the test results are exposed that we can go see?
<mato>
Notably missing is aarch64. This leads me to prod mort___, since he has a big aarch64 box at the lab which needs a sane OS installed on it :)
<mato>
yomimono: Kind of. The CI uses surf-build as the underlying driver, so it effectively runs only on PRs.
<mato>
yomimono: For each PR you can click on the "all checks passed (failed)", click on "Details" and that leads to a gist with the build log.
<mato>
yomimono: There is no centralised dashboard as such.
<yomimono>
mato: I use the centralized dashboard given to me by cloud CI providers basically never :)
<mato>
I'm sure this could be improved in various ways, but I don't want to invest too much time in it right now. Also, surf-build is a great product, but horrible to run (written in node.js)
<mato>
So it'd be on my list of "things to rewrite in OCaml" :-)
<yomimono>
:D
<yomimono>
mato: next agenda item is also yours so move on whenever you're ready :)
<mato>
ARM64 missing is an issue I'd like to resolve sooner rather than later as otherwise the ARM code will bitrot
<mato>
So feel free to help me prod mort___ :-) and/or give me access to an aarch64 box that runs docker (which is enough for the compile-testing-only variant)
<mato>
Next.
<mato>
Now that we have CI working, time to start breaking things!
<yomimono>
Yay!
<mato>
And unblocking Solo5 development which has been kind of stalled.
<mato>
In order to do that, I need to a) add some constraints to the OPAM repository so that mirage ukvm and virtio targets keep working.
<mato>
b) (possibly) add a "last commit before API breaks" tag to solo5/solo5 so that people using the current master can keep doing so (hannes mainly?)
<hannes>
mato: I'm off using hannesm/solo5.git#clang60 mostly nowadays
<mato>
Now, I'd like to ask the collective hive-mind, if it's sufficient to add constraints only in ocaml/opam-repository, w/o updating version numbers.
<mato>
i.e. only in the official opam.ocaml.org metadata
<hannes>
mato: yes, that is sufficient!
<yomimono>
mato: yes, absolutely
<hannes>
mato: and you can use the mirage-dev repository for staging an opam universe of "needs to be published at the same time"
<hannes>
mato: I'm not sure anymore about it's travis setup, but it should build mirage-skeleton on a daily basis!?
<mato>
Right, and at that point I can start breaking master all over the stack, using "pin --dev" until I have releases ready for a staging opam repository?
<hannes>
(doesn't do any end-to-end tests, apart from executing the unix backend of mirage-skeleton)
<yomimono>
mato: pretty much. you might want to drop a mail to mirageos-devel when you hit the "breaking master all over the stack" point
<mato>
ok, makes sense, so my understand is correct
<hannes>
mato: in mirage-dev you can put as url the git repository (and branch information) in the opam packages there, so no need to manually pin all the things on the computers you want to run tests on
<mato>
great
<mato>
for mirage-skeleton, I plan to set up some end-to-end tests using the new VM-based CI
<yomimono>
EXCELLENT :D
<mato>
not run on every commit, since the poor nuc would melt, but probably once or twice in 24h
<mato>
great, that answers all my questions. i plan to start merging breaking things once back and recovered from fosdem
<hannes>
now I'm looking forward to get rr, gdb, and netmap support by the end of Q1 ;p
<mato>
that _might_ be a bit optimistic :)
<ricarkol>
rr, gdb, hehe. That's me!
<ricarkol>
This is the order in which I was planning to work on things: 1. tests, 2. freebsd gdb, 3. rr. I can push freebsd up if you prefer
<reynir>
What is rr?
<ricarkol>
record-replay
<reynir>
Ah :)
<hannes>
ricarkol: i don't have a concrete need for FreeBSD-gdb, so carry on with your priorities
<ricarkol>
also, those things can be parallelized, so if somebody wants to work on any of those, that would be great
<yomimono>
I think that's a wrap on this catchup. thanks, everyone, for joining!
<mato>
Yes, thanks all!
<ricarkol>
bye everybody, and thanks again to mato for the CI
<lars_kurth>
Thanks
<hannes>
oh, one more thing: please sign up for http://retreat.mirage.io if you haven't yet... i need to finalise numbers soon
<hannes>
and thanks all!
<mato>
ricarkol: Please open an issue to discuss improved tests, I have some ideas ... I didn't know you had the python stuff until you commented elsewhere.
<mato>
yup, thanks all!
talex5 has quit [Quit: Leaving]
* kensan
waves from the distance
TImada_ has quit [Ping timeout: 260 seconds]
<ricarkol>
will do mato. Yeah, the bash tests are awesome if we keep things simple, but every time i touch it i feel like i'm breaking something.
<mato>
thanks
<mato>
yes, bash is unsuitable for that level of complexity
mort___ has quit [Quit: Leaving.]
mato has quit [Quit: WeeChat 2.0.1]
mort___ has joined #mirage
mato has joined #mirage
AltGr has left #mirage [#mirage]
dtornabene has quit [Quit: Leaving]
mort___ has quit [Quit: Leaving.]
olle has quit [Quit: olle]
mort___ has joined #mirage
mort___ has quit [Quit: Leaving.]
mort___ has joined #mirage
jnavila has joined #mirage
mort___ has quit [Quit: Leaving.]
mort___ has joined #mirage
mort___ has quit [Client Quit]
jnavila has quit [Ping timeout: 240 seconds]
jnavila has joined #mirage
jnavila has quit [Ping timeout: 240 seconds]
mort___ has joined #mirage
ricarkol has quit [Quit: Leaving.]
ricarkol has joined #mirage
jnavila has joined #mirage
mort___ has quit [Quit: Leaving.]
mort___ has joined #mirage
mort___ has quit [Quit: Leaving.]
argent_smith has quit [Quit: Leaving.]
ricarkol has quit [Ping timeout: 248 seconds]
ricarkol has joined #mirage
mort___ has joined #mirage
demonimin has quit [Remote host closed the connection]
demonimin has joined #mirage
mort___ has left #mirage [#mirage]
jnavila has quit [Remote host closed the connection]