<davidlt[m]>
kernel v6.4.2 has landed, but nothing interesting.
<davidlt[m]>
and nothing interesting in the queue too.
<davidlt[m]>
I see Fedora cooked kernel-6.4.2-200.fc38 yesterday. It might be a time for me to rebase kernel-ark stuff.
<davidlt[m]>
It's not in Bodhi yet. It's a bit too early to have 6.4 in the stable channel.
<davidlt[m]>
DesignWare GPIO driver (from SiFive) got merged into OpenSBI today. I might pull this in today.
<davidlt[m]>
alexsaezm: do you know how to figure out why golang fails to build a package when there are no error messages?
<davidlt[m]>
A number of packages fail after something like: cp $WORK/b185/_pkg_.a /home/riscv/.cache/go-build/91/91c617a82161de60b3b0379247e49c552d8ce5722b0139beda0a871f6e2441ff-d # internal
<davidlt[m]>
Google suggests multiple different ideas, which is basically random stuff.
<alexsaezm>
in aarch64 for example, there's a conditional at the very top that skips that (I removed I think recently)
<alexsaezm>
maybe is that?
<davidlt[m]>
alexsaezm: could you point to the commit what you did?
<alexsaezm>
yeah
<alexsaezm>
let me check
<davidlt[m]>
It's early morning here, and my eyes don't want to work :)
<alexsaezm>
same here, I still need my first coffee :D
<alexsaezm>
so it's still unmerged because I changed in the 1.21 pull request but you can see the change here:
<davidlt[m]>
Actually we do have ignore_tests set, but we are running %check.
<davidlt[m]>
Ah, that's for golang (my head really not working)
<davidlt[m]>
Also does GO_TEST_TIMEOUT_SCALE work with %gocheck?
<alexsaezm>
yeah, but it's a little bit weird how ti works AFAIK
<davidlt[m]>
Let's try it. I just timed out on one package.
<alexsaezm>
I'm trying to recall what was going on a where I saw it. I recall having the same issue and it was due to a chunk of code that failed but got buried behind the normal compilation and the last thing was a cp where in reality the error happened way before. I think what I did was to compile the package in the very specific version manually and that's where I saw the message but I'm trying to find if I wrote something about it because I
<alexsaezm>
think I did.
<davidlt[m]>
it will probably fail.
<davidlt[m]>
I see /tmp/go-build3029956582/b001/go-jose.v2.test -test.paniconexit0 -test.timeout=10m0s running.
<davidlt[m]>
panic: test timed out after 10m0s
<davidlt[m]>
TestOpaqueKeyRoundtripJWE (8m3s)
<davidlt[m]>
running tests:
<davidlt[m]>
Are there any others ways to tell %gocheck to increase timeout?
<alexsaezm>
yeah, so the best way to increase the timeout is instead of using scale (because I think I saw a bug in that section of the compiler and I know for a fact that some of the timeouts are hardcoded) is to run -timeout 50m
<alexsaezm>
for example go test -timeout 50m
<davidlt[m]>
There is nothing in the package source code that would set the timeout value.
<alexsaezm>
btw
<alexsaezm>
I found my notes
<davidlt[m]>
SCALE did nothing, still failed as the original.
<alexsaezm>
so the same thing happened on Delve few months ago
<alexsaezm>
and I sent this message to a coworker:
<alexsaezm>
after removing a lot of flags, the real error appeared. In the current latest release of delve (1.20.1) the go-dap version is 0.6.0 but Fedora contains 0.7.0. That creates a small issue in this line: https://github.com/go-delve/delve/blob/8e48ad75747fbc3d5faa07cb4f2ca8de85f25c29/service/dap/server.go#L1414 0.7.0 needs dap.Source to be &dap.Source. For some reason that was hidden behind the macros and now it compiles perfectly fine.
<alexsaezm>
```
<alexsaezm>
(well I have a failing test due to a path issue but that's another story)```
<alexsaezm>
* and I sent this message to a coworker:
<alexsaezm>
(well I have a failing test due to a path issue but that's another story)
<alexsaezm>
after removing a lot of flags, the real error appeared. In the current latest release of delve (1.20.1) the go-dap version is 0.6.0 but Fedora contains 0.7.0. That creates a small issue in this line: https://github.com/go-delve/delve/blob/8e48ad75747fbc3d5faa07cb4f2ca8de85f25c29/service/dap/server.go#L1414 0.7.0 needs dap.Source to be &dap.Source. For some reason that was hidden behind the macros and now it compiles perfectly fine.
<alexsaezm>
````
<alexsaezm>
s/```//
<alexsaezm>
So basically, due to the macros some issue in a library might be happening
<alexsaezm>
it took me several days to see that (I even thought it was the cp the one that failed)
<davidlt[m]>
I had the same idea, but I could config cp failing :)
<davidlt[m]>
So that still doesn't explain how to figure out by package X is failing.
<davidlt[m]>
What flags should I remove and where?
<alexsaezm>
let me see if I was smart enough to write about it
<alexsaezm>
Looks like what I did was to copy over the expansion of gobuild macro (so basically removing the macro all together and write go build
<alexsaezm>
because I recall trying to override the macro in the specfile with the __pre something macro but that was hard and didn't solve anything
<alexsaezm>
so basically... removing the macro, and running go build
<alexsaezm>
I know, what a solution :P
<davidlt[m]>
Could you provide example for golang-github-distribution-3 ?
<davidlt[m]>
This one is blocking tons of stuff.
<alexsaezm>
sure, the specfile on the src.fedoraproject?
<davidlt[m]>
Yeah, default ones.
<alexsaezm>
sure
<davidlt[m]>
We have very little changes in Go land for riscv64 (apart the main spec).
<rwmjones>
fyi the kernel build failed, but apparently right at the end
<rwmjones>
real541m10.763s
<rwmjones>
user1936m13.337s
<rwmjones>
sys142m21.666s
<rwmjones>
creating the hmac file
<rwmjones>
it's very unclear what the actual error is
<davidlt[m]>
rwmjones: that never happened before IIRC, so this is something new.
<davidlt[m]>
This is vs ~850 minutes.
<davidlt[m]>
Or ~9 hours vs ~14+ hours.
<rwmjones>
reproducible ...
<rwmjones>
rjones@vf2:~$ cd /home/rjones/rpmbuild/BUILDROOT/kernel-6.3.11-200.0.riscv64.fc38.riscv64/boot
<alexsaezm>
I tried locally and it still builds ✌️
<davidlt[m]>
rwmjones: we don't run debuginfod servers, but the thing works (tested in mock a couple days ago)
<davidlt[m]>
alexsaezm: I am finishing jose-2 and then spinning your spec.
<davidlt[m]>
alexsaezm: for the jose, I had to do: `%global gotestflags %{gotestflags} -timeout 30m`
<davidlt[m]>
ops, actually did 60 minutes for the final spec, as I didn't want to try too many times.
<alexsaezm>
great yeah, I have 50m in some Go tests 'cause aarch64 fails with the 10m lol. Please ping me if I look AFK, I'm fighting (and I'm not gonna win) with PPC64LE.
<davidlt[m]>
alexsaezm: this should be documentated in packaging guidelines of what to do if default timeouts are good.
<alexsaezm>
right
* alexsaezm
should improve the docs :'D
<davidlt[m]>
The thing that we love to postpone (forever) :)
<alexsaezm>
not sure where nor how should I do that
<davidlt[m]>
golang-github-distribution-3 is cooking locally.
<davidlt[m]>
Not sure how long we need to wait for it to fail.
<alexsaezm>
till the end of the time :D
<conchuod>
davidlt[m]: Did I tell you that Starfive sent us their PCI driver v2 off-list? Need to test it and get back to them, it's the same base IP as us, so might not take too long to upstream.
<davidlt[m]>
conchuod: yes you did. it would be nice to have it land for the next kernel.
<davidlt[m]>
As I am now considering adding VF2 into the build farm :) NVMe is must-have.
<conchuod>
I dunno if it will be "next kernel" material, but certainly I'd expect it to be faster than a new driver.
<davidlt[m]>
But from the log it's unclear if that has any affect.
<alexsaezm>
for some reason, I think when using the macro or when doing the for loop, not sure which one, it continues even if it failed and then it later fail completely
<alexsaezm>
I'm trying one thing...
<davidlt[m]>
I don't see this message on aarch64 and x86_64
<alexsaezm>
I think it might be skipping it on riscv
<alexsaezm>
I see some +build flags on the file
* alexsaezm
needs a riscv machine in his desk
<davidlt[m]>
rwmjones: ^^^ that's something for you 😄
<alexsaezm>
some of the files compile in linux in general as a target but others are arch dependent
<alexsaezm>
so I think this is where the problem starts. the code is arch dependent (not sure if it needs to be)
<alexsaezm>
and the macros don't make the experience better
<rwmjones>
so it's a hardware or kernel-specific bug related to the VF2
<conchuod>
"rg jh7110_hash_wait_key_done", you running downstream stuff?
<rwmjones>
it's the dodgy starfive kernel which has lots of out of tree patches, so who knows what's going on
<conchuod>
👍
<davidlt[m]>
dtometzki: mock will not work with systemd-nspawn containers. shadow-utils fails to install: error: unpacking of archive failed on file /usr/bin/newgidmap;64a7e9bc: cpio: cap_set_file failed - Operation not supported
<davidlt[m]>
* dtometzki: mock will not work with systemd-nspawn containers. `shadow-utils fails to install: error: unpacking of archive failed on file /usr/bin/newgidmap;64a7e9bc: cpio: cap\_set\_file failed - Operation not supported`
<davidlt[m]>
I will try to configure it to use old-style chroot.
<alexsaezm>
davidlt[m]: wait.. is this a component? it costs 4 euros... :-/
<davidlt[m]>
alexsaezm: Select the right option ;)
<davidlt[m]>
It's €203.68 for 16GB RAM model.
<alexsaezm>
Oh!
<alexsaezm>
now I see it
<davidlt[m]>
€12.29 for case, fan.
<alexsaezm>
I needed to scroll down :-/
<davidlt[m]>
€6.83 for POE module.
<alexsaezm>
now I see the full price
<alexsaezm>
I was going to buy 10 lol
<alexsaezm>
does it worth it as a first device for a noob? :D
<davidlt[m]>
alexsaezm: just remember that this basically has no upstream support apart UART :)
<davidlt[m]>
VF2 would be a better pick if you care about SW.
<davidlt[m]>
For development TH1520 is probably better (TBD), faster and more memory, but it will be long months before you get a proper upstream support.
<davidlt[m]>
Not to mention it lacks any high speed IO. The best you can do is NVMe over USB :)
<davidlt[m]>
dtometzki: failed with old style chroot too, same shadow-utils.
<davidlt[m]>
Basically I need root and a more space on /
<alexsaezm>
davidlt[m]: as long as I can have a headless fedora with ssh for playing with go... that's all I care
<dtometzki__>
davidlt[m]: I have no more space it is HW limit sorry
<dtometzki__>
<alexsaezm> "wait.. is this a component? it..." <- But Aliexpress dont deliver to germany :-(
<javierm>
alexsaezm: you could find it fairly cheap even in europe and has good mainline support
<davidlt[m]>
My advice is go buy VF2 and at some point consider TH1520 if there is sufficient benefits.
<javierm>
alexsaezm: if will be supported for the official riscv fedora port that's another question, because that SoC doesn't follow the latest riscv specs
<davidlt[m]>
Well, T-HEAD is not really compliant to riscv too.
<javierm>
davidlt[m]: yeah mean for the ERRATA_THEAD in the kernel ?
<dtometzki__>
> <@davidlt:matrix.org> Basically I need root and a more space on /
<dtometzki__>
* You will find more space under /mnt/data
<davidlt[m]>
So T-HEAD have a custom PTE. Basically they took "reserved" and used it, which is now also used by a standard riscv extension. I don't recall if they actually match.
<davidlt[m]>
There is also unratified vector support.
<davidlt[m]>
There is also something strange with the way they identify implementation.
<davidlt[m]>
conchuod: would know more as he is involved on the kernel side.
<javierm>
davidlt[m]: yeah, that's the ERRATA_THEAD_PBMT I think
<davidlt[m]>
Oh yeah, I remember it now.
<javierm>
davidlt[m]: but since everything is up in the air anyways, we don't really know what would be the supported or not by distros so I suggested alexsaezm that one because at least would be a cheap e-waste :)
jcajka has joined #fedora-riscv
<rwmjones>
TH1520 is a decent chip?
<conchuod>
It's spec non compliant, but it's prob the best chip we have in riscv land?
<conchuod>
> There is also something strange with the way they identify implementation.
<conchuod>
We use the m*id CSRs to enable errata, they leave them blank on all their cores, so it'll probably fall over soon.
<conchuod>
If that's what you mean.
<rwmjones>
yeah
<rwmjones>
well, I ordered one anyhow
<rwmjones>
could be e-waste, who knows ...
<conchuod>
I cba buying one, got enough boards, but if they give me one for w/e reason it'd be my main board once there's ethernet support I guess.
<conchuod>
I don't think it'll be e-waste, but I doubt there'll be vendor involvement in driver support etc.
<davidlt[m]>
I pinged them again to send you one, but I got no reply 😔
<conchuod>
Fewer boards is less work for me ;)
<davidlt[m]>
The more you have boards, the easier my life is ;)
esv_ has joined #fedora-riscv
esv_ has quit [Ping timeout: 240 seconds]
tg has joined #fedora-riscv
<davidlt[m]>
I circled back to Golang stuff again.
<davidlt[m]>
Conan Kudo or nirik could you point me to whatever information exist on how Fedora container images are cooked (KS files, or other templates, tools, ansible configs, code, etc.)?
esv_ has joined #fedora-riscv
esv_ has quit [Read error: Connection reset by peer]
esv_ has joined #fedora-riscv
jcajka has quit [Quit: Leaving]
esv_ has quit [Read error: Connection reset by peer]
esv_ has joined #fedora-riscv
<davidlt[m]>
alexsaezm: got a bit of a strange error:
<sorear>
is there a clear timeline or sequence of events for when riscv64 fedora is going to start having a hard dependency on things that are in RVA23 or the eventual server SoC spec but aren't in RVA20?