Update linux-raw-sys to 0.3.8

[heiher]

This PR aims to fix a compile issue for LoongArch by updating linux-raw-sys.

error[E0433]: failed to resolve: use of undeclared crate or module `general`
  --> /home/hev/.cargo/registry/src/index.crates.io-6f17d22bba15001f/linux-raw-sys-0.1.3/src/lib.rs:67:20
   |
67 | impl PartialEq for general::__kernel_timespec {
   |                    ^^^^^^^ use of undeclared crate or module `general`

error[E0433]: failed to resolve: use of undeclared crate or module `general`
  --> /home/hev/.cargo/registry/src/index.crates.io-6f17d22bba15001f/linux-raw-sys-0.1.3/src/lib.rs:79:13
   |
79 | impl Eq for general::__kernel_timespec {}
   |             ^^^^^^^ use of undeclared crate or module `general`

  cargo update -p is-terminal -p io-lifetimes

    Updating crates.io index
    Updating errno v0.2.8 -> v0.3.1
    Updating hermit-abi v0.2.6 -> v0.3.1
    Updating io-lifetimes v1.0.1 -> v1.0.10
    Updating is-terminal v0.4.0 -> v0.4.7
    Updating libc v0.2.137 -> v0.2.144
    Updating linux-raw-sys v0.1.3 -> v0.3.8
    Updating rustix v0.36.3 -> v0.37.19
    Updating windows-sys v0.42.0 -> v0.48.0
      Adding windows-targets v0.48.0
    Updating windows_aarch64_gnullvm v0.42.0 -> v0.48.0
    Updating windows_aarch64_msvc v0.42.0 -> v0.48.0
    Updating windows_i686_gnu v0.42.0 -> v0.48.0
    Updating windows_i686_msvc v0.42.0 -> v0.48.0
    Updating windows_x86_64_gnu v0.42.0 -> v0.48.0
    Updating windows_x86_64_gnullvm v0.42.0 -> v0.48.0
    Updating windows_x86_64_msvc v0.42.0 -> v0.48.0

[epage]

If our version requirements are compatible with LoongArch but local development of env_logger isn't due to an older lock file, does it matter?

[heiher]

This issue was discovered during our automated building of packages from the crates.io source. It appears that even if env_logger's dependencies are not updated, it does not affect a project's ability to lock onto compatible version. However, it would be preferable if env_logger could compile successfully as well.

[epage]

However, it would be preferable if env_logger could compile successfully as well.

Why?

[heiher]

Thanks for your response. I believe that by doing so, we can avoid encountering this issue again in future automation testing. If you find this unacceptable, please ignore my request.

[epage]

In my case, this changes a direct dependency and I try to have the lock file and manfiest in-sync with each other for direct dependencies and I try to avoid bumping direct dependencies unless there is a needed feature or a new version out.

In light of that, I think I'll close this.