Conversation
tuler
force-pushed
the
feature/emulator-0.20.0
branch
3 times, most recently
from
2ca1fd0 to
98b3299
Compare
tuler
force-pushed
the
feature/emulator-0.20.0
branch
2 times, most recently
from
de9d847 to
a85c99d
Compare
tuler
force-pushed
the
feature/emulator-0.20.0
branch
from
a85c99d to
a365670
Compare
| end | ||
|
|
||
| depends_on "cartesi-machine-emulator" | ||
| depends_on "cartesi-machine-guest-tools" |
There was a problem hiding this comment.
I would name it cartesi-machine-guest-tools-rootfs-image because it is not really guest tools.
There was a problem hiding this comment.
What if we decide that the formula should install more things from the machine-guest-tools, like put the riscv64 guest tools somewhere so developers can use it in builds.
There was a problem hiding this comment.
The name cartesi-machine-guest-tools is reserved for the package that installs guest-tools inside riscv64 guests (see cartesi/linux-packages#1), so the naming here is conflicting, because cartesi-machine-guest-tools is exactly the name used in Debian/Ubuntu/Alpine riscv64 to install libcmt, etc.
like put the riscv64 guest tools somewhere so developers can use it in builds.
Then that would be something like cartesi-machine-guest-tools-images, or cartesi-machine-guest-tools-packages or whatever depending on what it provides.
There was a problem hiding this comment.
The main initial issue was actually the package version, which cannon go backwards.
I don't mind much about the package name, as long as it makes sense.
We could even have a single package named cartesi-machine-images that includes the linux image and the rootfs image, but then what version number we use.
There was a problem hiding this comment.
Way back when, when we discussed what to name these packages, we had decided on
cartesi-machine-emulator: the emulator binaries etc
cartesi-machine-rootfs-image: roofs.ext2
cartesi-machine-linux-image: linux.bin
cartesi-machine: meta package that installs all three
cartesi-machine-guest-tools should really only be the source for the guest package that is installed inside rootfs.ext2. It only produces a rootfs.ext2 so it can test stuff in CI, right? The fact we are using the rootfs.ext2 for other purposes is a historical mistake. We should really be getting the rootfs.ext2 from a different repo, the cartesi-machine-rootfs-image repo. Indeed, there is a tag there that we could use, currently at v0.20.0-test1 that I wanted to promote to "real life".
There was a problem hiding this comment.
I understand better the issue now. The 0.20.0-test1 is a rootfs package produced with manually signed packages produced by @edubart
There was a problem hiding this comment.
Please use the same way Diego did on MacPorts at https://github.com/cartesi/macports-ports/blob/main/ports/emulators/cartesi-machine-rootfs-image/Portfile
That is, use cartesi-machine-rootfs-image with version 0.17.2 pointing to rootfs-tools.ext2 from machine-guest-tools.
This is also the same way currently on linux-packages PR cartesi/linux-packages#1
There was a problem hiding this comment.
I can’t do the same way he did, because brew does not allow to go to version 0.17.2.
There was a problem hiding this comment.
Can’t we all go back to how it was and release a proper machine-rootfs-image repo?
There was a problem hiding this comment.
@edubart I already upgraded it to simply create the rootfs.ext2 from a Dockerfile. But we need to fix the guest tools package signature situation.
3 participants
cartesi-machineandcartesi-machine-stored-hashwrapper scripts to use absolute Lua bin path installed bylua@5.4, as it is now a keg-only dependency and as such not installed in the global bin folder.Test plan