CI failure - floating point calculation assertions

[jnqnfe]

I'm aware that with the latest automated monthly CI run the instance using the nightly compiler is now failing, as I can reproduce locally with the nightly compiler.

The following tests are failing:

• src/time/microseconds.rs - time::microseconds::MicroSeconds::div_f32 (line 595)
• src/time/microseconds.rs - time::microseconds::MicroSeconds::from_secs_f32 (line 257)
• src/time/microseconds.rs - time::microseconds::MicroSeconds::from_secs_f64 (line 218)
• src/time/microseconds.rs - time::microseconds::MicroSeconds::mul_f32 (line 508)

The error output is as follows:

---- src/time/microseconds.rs - time::microseconds::MicroSeconds::div_f32 (line 595) stdout ----
Test executable failed (exit code 101).

stderr:
thread 'main' panicked at 'assertion failed: `(left == right)`
  left: `MicroSeconds(859872558)`,
 right: `MicroSeconds(859872559)`', src/time/microseconds.rs:7:1
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace


---- src/time/microseconds.rs - time::microseconds::MicroSeconds::from_secs_f32 (line 257) stdout ----
Test executable failed (exit code 101).

stderr:
thread 'main' panicked at 'assertion failed: `(left == right)`
  left: `MicroSeconds(2299999)`,
 right: `MicroSeconds(2300000)`', src/time/microseconds.rs:6:1
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace


---- src/time/microseconds.rs - time::microseconds::MicroSeconds::from_secs_f64 (line 218) stdout ----
Test executable failed (exit code 101).

stderr:
thread 'main' panicked at 'assertion failed: `(left == right)`
  left: `MicroSeconds(2299999)`,
 right: `MicroSeconds(2300000)`', src/time/microseconds.rs:6:1
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace


---- src/time/microseconds.rs - time::microseconds::MicroSeconds::mul_f32 (line 508) stdout ----
Test executable failed (exit code 101).

stderr:
thread 'main' panicked at 'assertion failed: `(left == right)`
  left: `MicroSeconds(8478000000)`,
 right: `MicroSeconds(8478000152)`', src/time/microseconds.rs:8:1
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

I'll head now to the Rust compiler issue list to file an issue report...

[werdahias]

I also have that bug when trying to package the latest libpulse-binding for debian. If I run the test they fail because of ~1 ms time differences. Would you consider lowering the precision for those tests ?

[werdahias]

Reading up on the linked issue:
Maybe implement it like that:

use float_eq::float_eq;


float_eq!(comparing ms here);

I don't know enough rust to write a suitable patch tbh.

[jnqnfe]

Hi, I've now published a new version which should fix this.

I've explained things in the bug report (edit: I meant the commit log), but to update the report - essentially, rust v1.60 included a minor breaking change to the way float-point calculations were done in certain stdlib functions, and this got tweaked again in version 1.63.

At the time I first noticed this, with failures from a 1.60 nightly, it was suggested that I should make use of float_eq to perform comparisons for the test, but I wasn't entirely comfortable with that and ended up just leaving it for some time, for which I apologise.

Since we've moved on several stable versions now, I felt that it was best to simply adjust the tests according to the values expected from rust stdlib v1.63+. Thus flipping the situation such that cargo test now succeeds for rust versions 1.63 and newer, but fails for older versions, rather than the opposite.

I noticed that rustc in debian is at 1.63, so this should pose no issue to these crates making their way into Debian, which would be awesome btw! :D

If there happens to be any users of an older rust version for whom this is a problem, we can revisit the float_eq thing, and similarly we can reconsider it if such a situation with rust's stdlib ever occurs again (I'm still not entirely comfortable with making use of float_eq here and would rather not implement use of it just to future proof against a hypothetical further breaking of tests at some point in the future that may never occur).

[jnqnfe]

On Mon, 2023-01-09 at 07:19 -0800, werdahias wrote: thanks, works for me. I just have to work around the two test trying to access the .config/pulse folder since the build runs in a chroot: failures: src/mainloop/standard.rs - mainloop::standard (line 56) src/mainloop/threaded.rs - mainloop::threaded (line 231)

No problem. Btw I accidentally initially replied with the wrong account, a much older one (that I really should delete) that's linked to a private email address that I just use for personal stuff (separate from dev work). That's why you would have gotten two copies from separate accounts (me correcting my mistake). The 'jnqnfe' gmail address is the correct one to reach me about dev work. I just wanted to ask that you please keep the private address private. I mean I'm not bothered that you sent a reply to it, I'd just prefer people to not know of it so please don't do anything that would reveal it to others. Thanks. :) About the chroot issue you face. I'm not sure where you're at with it, so I'll just add some comments that may be helpful... If I remember correctly the two tests you point to are the only two tests that actually go through a process of establishing a proper connection to PA, to somewhat simulate what an actual application might do. I feel confident that the problem will lie not with the binding's code but instead with the chroot environment. FWIW I actually ran into a problem getting these tests to pass in the CI environment last night after upgrading CI to run on Ubuntu 22.04 from 20.04. I don't know precisely why, but I found that switching from starting PA with `pulseaudio -D --start` to `systemctl --user start pulseaudio` fixed the problem in that case. I don't know if this has any relevance. Searching for general 'pulseaudio chroot' issues, google turns up a whole bunch of results. For instance this: netblue30/firejail#3484 I notice in this other discussion they specifically mention the pulse config folder: termux/termux-packages#12289 This entry in the PA FAQ may be helpful: https://www.freedesktop.org/wiki/Software/PulseAudio/FAQ/#howdoiplaysoundsfrommychroottomyhostspulseaudiodaemon This other entry about getting an access error might also be helpful: https://www.freedesktop.org/wiki/Software/PulseAudio/FAQ/#igetthiserrormessage:accessdenied  . This may have some relevance to the problem I mentioned running into in the CI environment, since the error I was getting there (`PAErr(- 1)`) corresponds to an access error. I hope this proves helpful. Good luck. :)

[werdahias]

thanks for all the helpful hints :) I just decided to skip those two tests as getting them to run would have been too much effort and skipped them. libpulse-binding is just awaiting upload :)

[jnqnfe]

Okay, cool. :)

…

On Mon, 2023-01-09 at 14:25 -0800, werdahias wrote: thanks for all the helpful hints :) I just decided to skip those two tests as getting them to run would have been too much effort and skipped them. libpulse-binding is just awaiting upload :) — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you modified the open/close state.Message ID: <jnqnfe/pulse-binding- ***@***.***>