-
Notifications
You must be signed in to change notification settings - Fork 210
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Prepare for v0.11 release and fix remaining issues #283
Conversation
I just published a |
Docs.rs has no network access, so we can't `cargo install` the binary dependencies. This is not required for doc generation, so we trick our way around that issue by providing a dummy build script just for docs.rs.
In the README.md there is a broken link to the migration guides. |
@asensio-project Thanks! Fixed in 4e2b8d7 |
Looks like the size of the generated first stage code increased on the latest nightly: https://github.com/rust-osdev/bootloader/actions/runs/3511818449/jobs/5882914661 . So we need to reduce the first stage size even more before merging this. As a workaround, we could ship a precompiled version built with a pinned nightly version, but we should try find a proper fix first. |
When I tried to compile with the new version of this crate I have the following error:
Looks like a dependency error. |
Funty 1.2 has been yanked. Cargo ignores yanked versions unless Cargo.lock already mentions them. |
I know. But how can be fixed? |
The dependency on mbrman will need to be updated to 0.5, which uses bitvec 1.0, which in turn uses the non-yanked funty 2.0. |
|
@asensio-project In the meantime, the following workaround can be used:
It must be in the top-level Cargo.toml |
Fixes the build on the latest Rust nightlies, which apparently generate slightly bigger code than older nightlies.
What about adding an option for avoiding the bootloader to don't write into screen until loading the kernel? This way, we don't have to clear screen. |
Since I don't know when the The new |
We could add a |
Looks like there is some kind of test failure on If someone has access to a macOS machine, it would be great if you could try these steps:
|
The test seems successful on my macOS M1 device. If I add Might be a problem solely with the speed of GitHub actions? Log
|
@micfong-z Thanks for testing!
I don't think that speed is the problem. The test runs for almost 20 minutes before it gets canceled by out timeout: This typically happens on a panic. Unfortunately, we don't have serial output of the bootloader panic message, so we don't see it in the logs... |
fyi, I just ran a GitHub Actions on my fork, testing
I would doubt this is a technical glitch from GitHub, but I'm not quite sure about how Actions works, and I just edited on the existing testing yml file. I might have missed some steps to replicate the problem. |
Interesting.. I just restarted the failed CI jobs manually, let's see if the problem is reproducible. |
"All checks have passed" now :D |
I just updated mbrman to 0.5.1 which uses bitvec 1.0.1. Sorry for the long delay |
Thanks a lot!
Well, I guess we can merge then :D. We have a scheduled CI build in place for the |
Prepares the new
v0.11
merged in #232 for publishing.TODO:
Fixes #291
Fixes #286