Reopening this as it was proven to affect multiple users and, now that
we ship an asahi-btsync service, for those users it leaves the service
in a permanent failing state.
So the bug is not specifically with asahi-btsync, but rather generically with
reading that variable from NVRAM. We could even reassign it to
librust-apple-nvram-dev since that's where the reading happens, but let's not
rush things (also, the variable specifically is a bluetooth variable). Does
Hi all,
ok this is the actual state for me (as NoisyCoil already found out:
macbook pro m1pro 14'')
asahi btsync:
thread 'main' panicked at src/main.rs:53:17:
called `Result::unwrap()` on an `Err` value: VariableNotFound
note: run with `RUST_BACKTRACE=1` environment variable to display a
bac
Hi all,
ok this is the actual state for me (as NoisyCoil already found out:
macbook pro m1pro 14'')
asahi btsync:
thread 'main' panicked at src/main.rs:53:17:
called `Result::unwrap()` on an `Err` value: VariableNotFound
note: run with `RUST_BACKTRACE=1` environment variable to display a
bac
Package: asahi-btsync
Followup-For: Bug #1071216
X-Debbugs-Cc: noisyc...@tutanota.com, cybae...@web.de
Hi all,
The reported bug seems to point to a missing variable in NVRAM, which is a bit
weird. I cannot reproduce it on my machine (M1 Mac Mini).
cy8aer, do you confirm the bug is still there an
On Thu, 16 May 2024 12:10:04 +0200 Thomas Renard wrote:>
Package: asahi-btsync
> Version: 0.2.0-1+b1
> Severity: normal
>
> Dear Maintainer,
>
> calling of asahi-btsync panics.
>
> - call asahi-btsync
Let's read some Rust:
fn real_main() -> Result<()> {
let matches = clap::command!()
Package: asahi-btsync
Version: 0.2.0-1+b1
Severity: normal
Dear Maintainer,
calling of asahi-btsync panics.
- call asahi-btsync
expect:
this should show the help page (because it needs parameters)
actual:
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value:
VariableNotFou
7 matches
Mail list logo
