Backport fixes to earlier releases?

[rtzoeller]

The upcoming 0.26 release will fix several bugs -- as previous releases included or will include breaking changes, it may not be possible for all clients to trivially uptake these bug fixes by upgrading to the latest version of nix. Additionally, 0.26 will bump the MSRV, making it difficult for clients stuck on an older rust to adopt these fixes.

@asomers should we backport any of the fixes to patch earlier releases?

---

Here's a draft list of changes to backport to each version:

0.25

• Workaround XNU bug in getifaddrs netmasks #1788
• 7109eb9d2e953f40ee0bbf79e8d427e8dd059930 - fix microsecond calculation for TimeSpec #1801
• 4d38456cab60843d212a62af7066ceac7bc6011e - Handle unacceptable name gracefully in {User,Group}::from_name #1815
• 9b232dd5815c9f78d13e061a407468a6fad53142 - fix bugs on android armv7, because pw.pw_passwd.is_null() #1824
• fa62534a238c86334d41bc1da68267388cda9b36 - Fix using SockaddrStorage to store Unix domain addresses on Linux #1871 (at least the fix, and possibly the new APIs)
• 006fc6f7975b3a6b64329847b780622aab392109 - Update use of libc::timespec to prepare for future libc version #1886

0.24

• Workaround XNU bug in getifaddrs netmasks #1788
• 7109eb9d2e953f40ee0bbf79e8d427e8dd059930 - fix microsecond calculation for TimeSpec #1801
• 4d38456cab60843d212a62af7066ceac7bc6011e - Handle unacceptable name gracefully in {User,Group}::from_name #1815
• 9b232dd5815c9f78d13e061a407468a6fad53142 - fix bugs on android armv7, because pw.pw_passwd.is_null() #1824
  • Pick 8cfc530b8881e2edba4df54d0334a6b81cd598c6 first to avoid conflict.
• fa62534a238c86334d41bc1da68267388cda9b36 - Fix using SockaddrStorage to store Unix domain addresses on Linux #1871 (at least the fix, and possibly the new APIs)
• 006fc6f7975b3a6b64329847b780622aab392109 - Update use of libc::timespec to prepare for future libc version #1886
  • Needs manual resolution.
  • Do we want to include b3e4d59bd7ad8a816b2ebe5f4564d8b62bbba4f5?

0.23

• ad7e3c719ce43e0210e71763109c42383ee5aa33 - InetAddr::from_std should set sin_len/sin6_len on the BSDs #1642
• 7109eb9d2e953f40ee0bbf79e8d427e8dd059930 - fix microsecond calculation for TimeSpec #1801
• 4d38456cab60843d212a62af7066ceac7bc6011e - Handle unacceptable name gracefully in {User,Group}::from_name #1815
• 9b232dd5815c9f78d13e061a407468a6fad53142 - fix bugs on android armv7, because pw.pw_passwd.is_null() #1824
  • Pick 8cfc530b8881e2edba4df54d0334a6b81cd598c6 first to avoid conflict.
• 006fc6f7975b3a6b64329847b780622aab392109 - Update use of libc::timespec to prepare for future libc version #1886
  • Needs manual resolution.
  • Do we want to include b3e4d59bd7ad8a816b2ebe5f4564d8b62bbba4f5?

0.22

• ad7e3c719ce43e0210e71763109c42383ee5aa33 - InetAddr::from_std should set sin_len/sin6_len on the BSDs #1642
• 7109eb9d2e953f40ee0bbf79e8d427e8dd059930 - fix microsecond calculation for TimeSpec #1801
• 4d38456cab60843d212a62af7066ceac7bc6011e - Handle unacceptable name gracefully in {User,Group}::from_name #1815
• 9b232dd5815c9f78d13e061a407468a6fad53142 - fix bugs on android armv7, because pw.pw_passwd.is_null() #1824
  • Pick 8cfc530b8881e2edba4df54d0334a6b81cd598c6 first to avoid conflict, but this commit requires manual resolution due to 3f6151ebbe11c6c20735f6390be69461628f9857.
• 006fc6f7975b3a6b64329847b780622aab392109 - Update use of libc::timespec to prepare for future libc version #1886
  • This may largely be a no-op, since we lack most of the conflicting functions entirely this far back.

[rtzoeller]

Some but not all of these bugs would also apply to 0.23, which I believe is also still fairly heavily used per the download statistics on https://crates.io/crates/nix. We could also backport and release a new patch for this branch, if desired.

[asomers]

You're right. And even 0.22 has 10k downloads per day. We should probably backport.

[rtzoeller]

I'm happy to handle the actual cherry-picking and release processes; I think it can all wait until we have 0.26 released though.

If we're applying fixes across 0.22 <-> 0.25, it'd be helpful to have a list of changes we want to cherry-pick into each version. There might be some fixes from 0.23 <-> 0.25 that we want to cherry-pick back to 0.22, for example.

I've updated the original issue to provide a space for this list.

[rtzoeller]

@asomers should we backport #1642 to 0.23 and 0.22? We deprecated InetAddr::from_std in 0.24, which was ironically the first release containing #1642.

Not sure how we feel about applying fixes to since-deprecated APIs, but it seems easy enough to include if we're already fixing things.

[asomers]

If it's easy, sure. But I don't want to expend too much energy maintaining old releases.

[wesleywiser]

I'm working on upgrading the version of musl used by the Rust *-linux-musl targets to musl 1.2. We unfortunately will have to make some breaking changes to the libc crate as part of that effort. I've done a crater run of the proposed changes which revealed a number of crates that no longer build because of compilation errors in various versions of the nix crate as a result of those libc changes:

Version	Number of downstream crates broken
nix-0.22.3	32
nix-0.23.1	52
nix-0.24.2	111
nix-0.25.0	87

If you're going to be releasing updates to any of those versions, it would be awesome if you could include #1886! I would be happy to help with that and provide patches and testing for whatever versions you choose.

[asomers]

@rtzoeller I think I'll have some free time tonight or tomorrow evening to work on releases. I'll start with 0.26.0 and work my way backwards.

[rtzoeller]

@asomers if you can get 0.26.0 published (not sure if there are any other PRs we want to pull in), I'm happy to handle the backporting if you'd prefer. Not sure how much manual fixing of cherry-picks will be required.

[rtzoeller]

@wesleywiser if I'm understanding correctly, #1886 lets us support both musl 1.1 now and 1.2 in the future? In that case, I agree we should cherry-pick it back to those releases if possible. I'll add it to the list, but please thumbs up/down this comment to ack my understanding.

[rtzoeller]

@asomers I tried cherry-picking the commits and have added my notes to the issue body; very few conflicts and almost all could be solved by picking an additional commit.

#1886 is the only painful one, just because we've added so much to src/sys/time.rs recently.

I expect there will be a healthy amount of clippy cleanup needed after cherry picking, unless we want to suppress things.

[rtzoeller]

@asomers I have drafts up for patches of 0.25, 0.24, and 0.23. I will get to 0.22 after we get a resolution on how to backport #1886. I see no reason to hold up 0.26.0 for that though.

[rtzoeller]

@rtzoeller need to backport #1821 as well.

[rtzoeller]

@asomers can you look over #1887 and #1889? These should reflect the 0.25 and 0.24 patches - I plan on publishing these as soon as I get your go-ahead (i.e. not waiting for the 0.23 and 0.22 patches to be ready first).

I'm planning on closing the draft PRs and pushing directly to the branches, as it appears we have done in the past.

0.23 (#1892) is having some issues with the Redox build. We will also need to decide how to handle the mqueue changes from https://github.com/nix-rust/nix/pull/1639/files, as clippy is unhappy but the original fix was a breaking change not suitable for a patch release.

0.22 (#1901).... I am not sure what to do with. #1821 is nontrivial to backport due to #1524, which first landed in 0.23.0. We also were not running clippy at this point, and the build is failing for what appear to be infrastructure issues.

[asomers]

#1887 and #1889 look good to me. I may be able to take a look at the other two this weekend, if I have time. Satisfying Clippy is always the hardest part about making patch releases.

[rtzoeller]

#1892 should be ready for review; I'm not sure why the mqueue changes didn't come up, but I won't complain. Just needed to use a newer redox compiler and backport one redox fix.

[rtzoeller]

0.23, 0.24, and 0.25 are patched. 0.22 still remains, but I'm contemplating if our time is better spent updating crates which are still depending on that old of a version, rather than patching.

For example: watchexec/command-group#8

[asomers]

Closing this issue. We never did publish another version of 0.22, and the world hasn't complained.