Skip to content

Error if unsupported version in toltecctl #576

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

Closed
wants to merge 27 commits into from
Closed

Conversation

Eeems
Copy link
Member

@Eeems Eeems commented Mar 24, 2022

Fix #445

@Eeems Eeems added the packages Add or improve packages of the repository label Mar 24, 2022
@Eeems
Copy link
Member Author

Eeems commented Mar 24, 2022

This is currently untested

@Eeems Eeems requested a review from matteodelabre March 27, 2022 16:51
@Eeems Eeems marked this pull request as ready for review March 27, 2022 16:51
@Eeems
Copy link
Member Author

Eeems commented Mar 27, 2022

Did some spot testing on my rM1 and the code seems sound. I haven't tested by updating to the latest OS though.

@Eeems
Copy link
Member Author

Eeems commented Mar 28, 2022

This will need to be updated when #579 is merged.

@Eeems
Copy link
Member Author

Eeems commented Mar 29, 2022

Just tested and this seems to work properly. The values are for the latest stable as we'll be adding support for it with the other changes on their way into testing.

@matteodelabre
Copy link
Member

Thanks for your work on this, Eeems! Haven’t tested this yet but judging by the diff this looks good.

Only thing is, I’m not sure hardcoding the supported version numbers in the script itself is a viable solution. Consider the following situation: someone upgrades to the latest OS release while Toltec doesn’t yet support it, so toltecctl reenable fails (as it should). But then, what happens? The toltec-bootstrap package would never be updated since reenable is failing, so the supported version numbers in the script would never be updated.

What about instead publishing two files on our website that would contain the latest supported version numbers? The script could pull those files and compare their value against the current /etc/version to decide whether to reenable.

Also, I’m not sure I understand the rationale for running check-version in the toltecctl switch-branch subcommand. Did you mean to add it to another part of the script?

@Eeems
Copy link
Member Author

Eeems commented Apr 2, 2022

Technically they would still be able to install by using --force on the reenable. Fair point though, we should check something to see if the supported version has changed. How do you want to keep track of that?

I've seen some people running switch branch without understanding what it actually does already. We probably should include a version check there still, but only if we have the supported version be per branch. That way we can keep people from switching back to stable on a version that isn't supported in stable yet.

@matteodelabre
Copy link
Member

Technically they would still be able to install by using --force on the reenable. Fair point though, we should check something to see if the supported version has changed. How do you want to keep track of that?

The solution I have in mind is to publish a file on our website containing compatibility information. For example, we could add a file named Compatibility in both /stable and /testing subfolders. The file contents could look something like this:

Max-OS-Version: 2.12.2.573
Max-Build-Timestamp: 20220303120824

The version field would be used for displaying information to the user on the latest supported version, and the timestamp field would be used for comparison with the /etc/version file.

I've seen some people running switch branch without understanding what it actually does already. We probably should include a version check there still, but only if we have the supported version be per branch. That way we can keep people from switching back to stable on a version that isn't supported in stable yet.

Sounds good. Should we also call the check function in the bootstrap script?

@Eeems
Copy link
Member Author

Eeems commented Apr 3, 2022

The solution I have in mind is to publish a file on our website containing compatibility information. For example, we could add a file named Compatibility in both /stable and /testing subfolders. The file contents could look something like this:

Max-OS-Version: 2.12.2.573
Max-Build-Timestamp: 20220303120824

The version field would be used for displaying information to the user on the latest supported version, and the timestamp field would be used for comparison with the /etc/version file.

Seems reasonable. We will have to split this information between rM1 and rM2 somehow. Do you want me to update the PR to handle this?

Sounds good. Should we also call the check function in the bootstrap script?

I think it would be a good idea to do so.

@matteodelabre
Copy link
Member

Added a quick implementation of what we discussed above. Untested for now.

@Eeems
Copy link
Member Author

Eeems commented Jul 6, 2022

Added a quick implementation of what we discussed above. Untested for now.

Did you ever get a chance to test this?

@Eeems
Copy link
Member Author

Eeems commented Jul 31, 2022

@matteodelabre poke

@matteodelabre
Copy link
Member

#616 is a reminder that this needs to be finalized. I probably won’t have enough time for this until the start of next month.

@Eeems
Copy link
Member Author

Eeems commented Sep 26, 2022

@matteodelabre poke

@Eeems
Copy link
Member Author

Eeems commented Sep 2, 2023

#731 we probably should focus on this again soon.

@Eeems
Copy link
Member Author

Eeems commented Sep 2, 2023

Unfortunatly using /etc/version as an always increasing value will no longer work, one of the 3.6 releases has a value from 2018. We can pull the official value from /usr/share/remarkable/update.conf similar to how codexctl does https://github.com/Jayy001/codexctl/blob/7aedd90a7686db014329591767f3ba5eb81cfb29/local/codexctl.py#L100C14-L105

@Eeems Eeems added this to the 3.x support milestone Nov 24, 2023
@Eeems
Copy link
Member Author

Eeems commented Nov 27, 2023

I've updated the logic to handle minimum and maximum versions, this should provide the building blocks required to start generating multiple repos with different OS version ranges. I haven't tested anything yet, but in theory it should work. I also fixed up the version compare logic to use opkg compare-versions as the current logic seemed to always fail when trying to run it.

@Eeems
Copy link
Member Author

Eeems commented Dec 18, 2023

Closing in favour of #759

@Eeems Eeems closed this Dec 18, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
packages Add or improve packages of the repository
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants