Fig regression of peach-dyndns-updater #63
No reviewers
Labels
No Label
bug
documentation
duplicate
enhancement
help wanted
invalid
maintenance
peach-lib
peach-network
peach-oled
peach-stats
peach-web
question
refactor
wontfix
No Milestone
No project
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: PeachCloud/peach-workspace#63
Loading…
Reference in New Issue
No description provided.
Delete Branch "fix-regression"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
This PR fixes a regression of peach-dyndns-updater. I still don't totally understand the cause of the regression (maybe upgrade of rust?), so I've just changed to use nsupdate in a slightly different way which is working now (writing the arguments to a file, and then calling nsupdate passing the path to the file as an argument, instead of instantiating a child process and passing the arguments by writing to stdin for the child).
I've also
I've tested on the pi that this is working.
@notplants
Nice, that sounds like a good approach to me.
Great PR! Very happy to have this in working order :) Now we'll have two ways of testing inter-peach replication (DYN DNS & Tor hidden service).
I added a couple commits:
config_manager
function callscargo fmt
to tidy-up a couple small formatting issues.unwrap()
withResult<bool, PeachError>
+?
for the function which checks if the dyn dns domain is new?
operator for the function call inpeach-web
unwrap()
bit me when experimenting withrouille
andmaud
(server crash when visiting the DNS settings page) - figured I'd take care of it while my memory was fresh@notplants
Ah, this turned into a nightmare. I noticed there was a conflict for
Cargo.toml
for your PR and then realised that the branch you had forked from to createfix_regression
was not up to date withmain
. Ironically, thefix_regression
PR would have introduced multiple regressions.I think I have merged all the outstanding changes: PR #60, PR #61, & PR #62.
I also discovered an issue with compilation at the workspace-level. Because the
miniserde_support
feature flag is enabled forpeach-lib
in one crate and theserde_support
flag is enabled in another crate,cargo
fails with errors like this:error[E0119]: conflicting implementations of trait
miniserde::Serializefor type
stats::MemStat``This is annoying. Here's a small SO post about it:
https://stackoverflow.com/questions/64200237/multiple-versions-of-local-dependency-in-cargo-workspace-with-different-features
I'll figure out a solution later.
Note: I did not delete the branch, just in case we have to revert the merge.
@glyph with your original fixing commits, thanks,
... I was less familiar with those things in the spring when I was working on this and glad to feel more comfortable now
don't totally understand the merge conflict issue you ran into, but sounds like a mess and glad you got it sorted
@notplants
It happens to me sometimes when I work on a branch without merging latest changes from
main
(so my branch then ends up being behind in some ways). I think in this case the particular changes you didn't have on your branch were from the PR which updated the crypto inpeach-lib
(when we switched to using thesha3
crate). So then there was a conflict in theCargo.toml
ofpeach-lib
.I figured I'd just go ahead and make the commits rather than asking you to make changes. That also makes it easier for you to get straight to work on other tasks whenever you start your day :)
I think I understand, that something about the Cargo.toml from the old branch + what I added, cauased a conflict, so it couldn't just straight-forward merge in the commits it was still missing.
and cool yes I have no problem at all with less polishing commits to do :)