dgilmore changed the topic of #fedora-riscv to: Fedora on RISC-V https://fedoraproject.org/wiki/Architectures/RISC-V || Logs: https://libera.irclog.whitequark.org/fedora-riscv || Alt Arch discussions are welcome in #fedora-alt-arches
zsun has joined #fedora-riscv
jednorozec has quit [Read error: Connection reset by peer]
jednorozec has joined #fedora-riscv
zsun has quit [Quit: Leaving.]
davidlt has joined #fedora-riscv
<davidlt> rwmjones_, seems your GHC change is OK
<davidlt> there is a new GHC build in upstream Fedora
* davidlt goes to check compiler hashes
<davidlt> let's build it
<davidlt> I wonder if I have enough GHC land rebuilt to actually build GHC
<davidlt> eh, font scaling after firefox update is terrible (?)
<davidlt> heh, someone is modding RTX 2080 Ti memory, 11GB -> 22GB
<davidlt> oh, someone modded 2080 Ti to 44GB too (last year)
<davidlt> that's not something Nvidia would like
<davidlt> to my surprised GHC is compiling (it will take some time)
<davidlt> a day IIRC
<rwmjones_> davidlt: ghc hashes don't change
<davidlt> just packages?
<davidlt> anyways it's cooking
<rwmjones_> afaik nothing changes; I rebuilt ghc with that patch yesterday and installed it and I didn't have to rebuild anything else
<davidlt> OK, anyways I will pause GHC package rebuilding before this new GHC lands
<davidlt> just in case
<rwmjones_> about packages,
<rwmjones_> fftw builds fine without modifications (on vf2)
<rwmjones_> gdl still has some failed tests, I'll do a PR for that soon
<rwmjones_> still have to look at flexiblas and gd
<rwmjones_> so if there are more packages after those, put them here and I can look at them after
<davidlt> I will make a new list maybe today (it's holidays here)
<davidlt> wxGTK, request to list failing tests on riscv64 (will require testing locally): http://fedora.riscv.rocks:3000/rpms/wxGTK/commits/branch/main-riscv64
<davidlt> texlive-base, needs disabling luajit bits (just don't upstream bootstrap flag): http://fedora.riscv.rocks:3000/rpms/texlive-base/commit/f6aa90f4c04c6e7abdf2486450b508dd70ad9c52
<davidlt> another task would be add support for riscv64 in llvmlite
<davidlt> This failed, and I never looked again at it.
<davidlt> last build is here (incl. logs): http://fedora.riscv.rocks/koji/taskinfo?taskID=1592263
<davidlt> scipy, check diff between spec (multiple commits): http://fedora.riscv.rocks:3000/rpms/scipy/src/branch/main-riscv64
<davidlt> it's basically the list of PYTEST_ADDOPTS (i.e. ignored failing tests)
<davidlt> if you want some more interesting work, investigate why mold tests are failing in Fedora for riscv64
<davidlt> some packages use mold already, samba is one of them
<davidlt> technically not a problem with Pioneer, but lets do this for now
<davidlt> redhat-lsb, add riscv64 support (you will need to recheck/resest this one): http://fedora.riscv.rocks:3000/rpms/redhat-lsb/commit/620fd4e8fd30f7d5857ba6590f66d17ec4d3855f
<davidlt> I haven't touched it since F29 or so
<rwmjones_> wasn't redhat-lsb deprecated?
<rwmjones_> Subject: [fesco] Issue #3089: retiring redhat-lsb in Fedora
<rwmjones_> sorry, happy holidays too!
<rwmjones_> I'll look at the list above while you're away
<davidlt> I am not "away", just not glued to the screen the whole day :)
<davidlt> redhat-lsb is still in (incl. F41): https://src.fedoraproject.org/rpms/redhat-lsb
<davidlt> There is even a new build in testing for F39.
<davidlt> Anyways if my laptop disconnects from IRC I still check channel logs at whitequark.org/
<davidlt> otherwise Matrix is always on ;)
davidlt has quit [Ping timeout: 255 seconds]
<rwmjones_> fuwei: ^^^ note I'm pulling changes into Fedora now, if you have any changes you want me to help pull in too, then please let me know
<rwmjones_> texlive is insane ...
zsun has joined #fedora-riscv
davidlt has joined #fedora-riscv
<davidlt> rwmjones_, why? :)
<davidlt> the massive amount of PRMs? ;)
<davidlt> It's just something like ~6000 of them
<rwmjones_> davidlt: the number of source files for one :-)
<rwmjones_> $ grep ^Source *.spec | wc -l
<rwmjones_> 426
<rwmjones_> I suppose it's one way to avoid separate packaging
<davidlt> ah, sorry texlive-base is not that big
<davidlt> base is just minimal set
<rwmjones_> good that they're doing it, but irrelevant for me as I've never connected a display to my vf2
<rwmjones_> I'm very pleased it is handling 5 parallel builds at the moment well
<davidlt> that's a lot for that small board
<davidlt> I raised maxjobs on Pioneer to 32 for fun, but that will have to wait for GHC to finish
<davidlt> It was probably a mistake to send GHC to Pioneer instead of Unmatched
<davidlt> Unmatched is faster writing out RPMs
<davidlt> I think it was 17 hours vs 23 hours on Pioneer
<rwmjones_> does the pioneer have an NVMe drive?
<davidlt> Actually no difference, I will be sleeping anyways :)
<rwmjones_> while the nvme drive on the vf2 is quite slow, it's better than not having an nvme drive
<davidlt> Oh, yes. I removed the Chinese one and replaced with the same NVMes I use on Unmatched.
<davidlt> I get impression that running 16 dnf install via mock is quite slow
<davidlt> I also noticed that only one of them was running at a time (I think)
<davidlt> I wasn't spending too much attention on it for now
<davidlt> Maybe I was dreaming, or something :)
<davidlt> Anyways almost all the builds related to GHC are done on Pioneer because I want to play with it, test it, etc.
<davidlt> There was an interesting discussion on #riscv yesterday about pulseaudio and vectorized glibc functions on memory mapped devices
<davidlt> apparently things like memcpy, and in general that memory is tricky to use. You need to careful how you access/touch it.
<rwmjones_> yeah I remember long ago (on 68030) having problems with using C for accessing memory mapped devices
<rwmjones_> like my C compiler would decide to split or combine 16 and 32 bit loads and stores
<rwmjones_> and the hardware would be very unhappy about it
<rwmjones_> you really need to use some kind of direct primitives with memory mapped devices
<rwmjones_> well I read the first third of that thread and it doesn't surpise me at all that memcpy doesn't work on memory mapped I/O devices
<rwmjones_> davidlt: comment on https://src.fedoraproject.org/rpms/snapshot/pull-request/3 that is worth considering ..
davidlt has quit [Ping timeout: 255 seconds]
davidlt has joined #fedora-riscv
<davidlt> rwmjones_, commented
<davidlt> rwmjones_, up to you, both approaches work for me, but it also depends on meson macro maintainer(s).
<davidlt> rwmjones_, if you go with global macro change then also do that for %ctest too
jcajka has joined #fedora-riscv
<davidlt> I currently don't recall how it's done for ctest, but there are packages with that
<davidlt> I think it's --timeout
<davidlt> default is 60 or something
<davidlt> rwmjones_,
<davidlt> this is not a correct change (lacks ifarch), but gives an idea
<davidlt> now I recall that default is 1500
<davidlt> (for ctest timeout)
<davidlt> thus 6000 is 4x
<davidlt> yeah, let's do global
<davidlt> for meson and cmake
<rwmjones_> davidlt: do you have an idea roughly how many packages are affected by timeouts (like order of magnitude)?
<rwmjones_> if it's just a handful I wouldn't bother with the global macro
<davidlt> see my comments on snapshot
<rwmjones_> yup I see
<davidlt> our dist-git overlay currently is <300 packages, with smallest delta we ever had ~1500 packages
<davidlt> ~1000 of packages in general don't build in Fedora
<davidlt> So up to <2000 packages lets say (worst case scenario)
<rwmjones_> let me have a look at the global macro and get back .. got another meeting now
<davidlt> there are definitely more packages failing because of tests timing out, I have seen those, but I never fixed them
aurel32 has quit [Ping timeout: 256 seconds]
aurel32 has joined #fedora-riscv
davidlt has quit [Ping timeout: 264 seconds]
cyberpear has joined #fedora-riscv
zsun has quit [Quit: Leaving.]
davidlt has joined #fedora-riscv
<davidlt> rwmjones_, is there a way to respin the tests for https://bodhi.fedoraproject.org/updates/FEDORA-2024-86f122ac31 ?
<davidlt> There is no log for "baseos-qe.koji-build.scratch-build.validation"
<davidlt> and "a few seconds ago" is wrong
cyberpear has quit [Quit: Connection closed for inactivity]
<rwmjones_> looking
<rwmjones_> did that test actually run?
<rwmjones_> TBH I always ignore bodhi tests
<davidlt> yeah, but I think this is blocking binutils from landing (?)
<rwmjones_> I clicked "trigger new test run"
<rwmjones_> no idea what that will do
kalev has joined #fedora-riscv
<rwmjones_> ghc patch went upstream
<davidlt> the build is ongoing
<davidlt> actually it's packaging step, which takes long on pioneer
davidlt has quit [Ping timeout: 252 seconds]
jcajka has quit [Remote host closed the connection]
iooi has joined #fedora-riscv