09:31 <hursand> rwmjones_ Currently rust-sys-info can't pass tests on riscv64, and the problem was caused by cpu_speed() as it doesn't support riscv64 right now. As there's no current standard on riscv64 to determine the cpu speed from /proc/cpuinfo, it's preferred to skip the test_cpu_speed() on riscv64, so should the patch be submitted to upstream or to Fedora

09:31 <hursand> source?

09:31 <hursand> Related issue: https://github.com/FillZpp/sys-info-rs/issues/105

10:01 <rwmjones_> hursand: morning

10:03 <rwmjones_> just trying to compile it here

10:09 <rwmjones_> it doesn't even get to the tests for me, fails with ...

10:09 <rwmjones_> error: 16 files in the working directory contain changes that were not yet committed into git:

10:09 <rwmjones_> ...

10:09 <rwmjones_> to proceed despite this and include the uncommitted changes, pass the `--allow-dirty` flag

10:09 <rwmjones_> /usr/bin/cp: missing file operand

10:09 <rwmjones_> Try '/usr/bin/cp --help' for more information.

10:10 <rwmjones_> do you have local changes that get past this problem?

10:11 <rwmjones_> hursand: about your question, you could change the Fedora spec file to skip the test, and add a link to the upstream issue as a comment

10:11 <rwmjones_> if you CC @rjones @davidlt on the Fedora PR we will take a look

11:06 <davidlt> hursand, in general using /proc/cpuinfo is not that advisable

11:07 <davidlt> So such field in cpuinfo for riscv64 doesn't exist, but you can calculate the actual clock (e.g. lmbench does that IIRC)

11:08 <davidlt> There is a way to get it from sysfs as opp table is defined in DT

11:08 <davidlt> But that's also in some cases are wrong.

11:08 <davidlt> Like choosing 1500MHz on VF2 is actually 1000MHz IIRC (there is a patch to fix that).

11:09 <davidlt> Also there are so many other things where clocks will be changing very rapidly (check on Intel, AMD systems, especially laptops)

11:14 <hursand> davidlt I agree with you, but that's how rust-sys-info originally determines the cpu speed(quite dirty hacks) and I could do nothing with it =L , and also that's why I was trying to add support for riscv64 to this project at first but eventually given up because of the same reason you just mentioned. So I'm going to add a patch to skip the

11:14 <hursand> test_cpu_speed() and want to check if submitting the patch to Fedora source is more appropriate =D

11:15 <davidlt> hursand, replied on GH

11:15 <davidlt> https://github.com/FillZpp/sys-info-rs/issues/105#issuecomment-1962898281

11:15 <davidlt> Basically it's one line change to return Err(Error::UnsupportedSystem)

11:17 <hursand> davidlt Actually cpu_speed() did return Err, and in test_cpu_speed() it tries to unwrap() the returned value and caused the panic

11:17 <davidlt> hursand, so the test is broken because it doesn't handle Err? :)

11:17 <davidlt> That sounds like a broken test

11:18 <davidlt> In that case your change is probably OK, but I still don't like it,

11:18 <davidlt> The test should be written to check for Err and handle it too.

11:19 <davidlt> Instead of adding the same cfg macros as that will become a spaghetti with all the possible options

11:19 <hursand> davidlt Correct, so either we skip the test like how https://salsa.debian.org/rust-team/debcargo-conf/-/merge_requests/295/diffs did, or we modify the test to properly handle the returned Err value

11:19 <hursand> Okay I got what you mean

11:19 <davidlt> I think the current approach is OK, but not ideal. The test should handle all possible return values from the function.

11:20 <davidlt> It shouldn't fail if you receive Err(Error::UnsupportedSystem)

11:20 <davidlt> and then you can just drop the whole cfg macro

11:21 <davidlt> Maybe print a message from the test that it's unsupported on the platform

11:21 <davidlt> Haven't used rust in years, thus I am a bit rusty how things works there these days :)

11:22 <hursand> So if we take this approach, it seems that submitting the patch to upstream would be a better choice? As if there're other new arch emerged, this test can still be passed without modifying the code

11:22 <davidlt> Yes

11:22 <davidlt> There are another two arches that I see coming up

11:23 <davidlt> loongson is pushing hard, and I noticed sw_64 or whatever too slowly showing up

11:23 <hursand> Okay, thanks

11:24 <davidlt> Sw (sw_64) is Sunway IIRC (another MIPS clone from China IIRC).

11:45 <rwmjones_> davidlt: mozjs115 compiles unmodified for me

11:45 <davidlt> rwmjones_, on VF2?

11:45 <rwmjones_> I'm going to look at mozjs102 later, that has some failures

11:45 <rwmjones_> yes on VF2

11:45 <davidlt> OK, I will try later on.

11:46 <davidlt> I installed a new NVMe on Pioneer (again!), and let's see how it will last

11:46 <davidlt> i.e. how long

11:46 <rwmjones_> so it eats NVMe drives ...?

11:46 <rwmjones_> that's a very specifically strange failure

11:47 <davidlt> After 400+ hours of operation I basically get Data Transfer Error from PCIe, then IO errors on NVMe, and then file system goes read-only and it starts eating (and failing) all the builds in Koji

11:47 <davidlt> I reinstalled on a brand new NVMe yesterday and it latest ~4 hours maybe, and it happened again.

11:47 <davidlt> So I unpacked another brand new NVMe (just in case) and trying again

11:48 <davidlt> Either it "broke", or it doesn't like the current load (?)

11:48 <davidlt> I had no significant issues (apart rare random hangs), after now it's annoying

11:49 <davidlt> I am doing just one build right now, webkit2gtk4.0, on it

17:43 <davidlt> rwmjones_, I need NVR with https://src.fedoraproject.org/rpms/rapidjson/commits/rawhide