<davidlt[m]>
Thankfully I didn't start GCC 13 build. There is already a new commit (not yet submitted for the build).
Guest36 has joined #fedora-riscv
<Guest36>
Hi all! Guys, pls give me a password Fedora's Image (.raw)
<Guest36>
I cant find this
<Guest36>
I have user: Fedora RISCV User, but i haven't password from this OS
<davidlt[m]>
It prints it on the serial console login
<davidlt[m]>
Guest36: it's "fedora_rocks!" (remember to change it, especially if the board is open to wider Internet)
<davidlt[m]>
If you use virt-builder it should/could create custom password (and print it) at disk image creation time.
<davidlt[m]>
Conan Kudo: I was having a walk and thinking about x86_64-v{2,3,4} and RVA{20,22,23}. I might create a mailing list thread to ask for input/discussion. Note, I do not plan to suggest changing the baseline (that would anger folks). I am more interesting how we could make it work for everyone.
<Guest36>
Thank you, Guys! "fedora_rocks!" - was accepted! <3
jcajka has joined #fedora-riscv
fuwei has quit [Ping timeout: 260 seconds]
fuwei has joined #fedora-riscv
Guest36 has quit [Quit: Client closed]
Kevinsadminaccou has quit [Quit: You have been kicked for being idle]
fuwei has quit [Remote host closed the connection]
fuwei has joined #fedora-riscv
<davidlt[m]>
I might hold off a bit, I smell a new GCC build incoming :)
fuwei has quit [Remote host closed the connection]
<kwizart>
Hello, anyone knows the upstream kernel status of jh7100 ? (and alikes ?) I'm not sure which device I have (but it's discontinued IIRC) and I wonder if current fedora riscv kernel have support for the device ?
Kevinsadminaccou has joined #fedora-riscv
<davidlt[m]>
Conan Kudo: I see your name on allow_vendor_change PRs and BZ item. What is the best practice to support vendor repositories especially if it contains RPMs that are replacing system RPMs.
<Eighth_Doctor>
switching off automatic vendor changing is probably a good idea
<Eighth_Doctor>
we need a Change proposal to change DNF's behavior
<davidlt[m]>
does that basically lock install package to a specific repository?
<Eighth_Doctor>
no, it locks whatever packages you install to the "Vendor" tag of that package
<davidlt[m]>
Oh, that's a better description for that flag :)
<davidlt[m]>
Conan Kudo: I am a bit confused on how things work (just spent a hour googling history related to this). So technically I am not allowed to replace system package without FESCo exception?
<Eighth_Doctor>
yup
<Eighth_Doctor>
does your Koji system use the same vendor tag setting as Fedora's?
<davidlt[m]>
For example, what if I want to provide T-HEAD or StarFive (or different vendor) optimized packages which would replace existing packages.
<davidlt[m]>
Yes.
<davidlt[m]>
I am just trying to understand technical, policy and politics on how things should work.
<Eighth_Doctor>
so Fedora RISC-V packages claim "Fedora Project" is the vendor then?
<davidlt[m]>
Yes.
<davidlt[m]>
They always did since 2016 IIRC.
<Eighth_Doctor>
so are you talking about having compile optimized? or configuration optimized?
<Eighth_Doctor>
because the latter is allowed by creating swappable packages already
<davidlt[m]>
Compiled. Different extensions to boost performance.
<Eighth_Doctor>
ah that's going to be fun
<Eighth_Doctor>
because we don't have a policy for that at all right now
<davidlt[m]>
For example bit manip extensions.
<Eighth_Doctor>
and the nature of Koji setups makes this very difficult to do :(
<davidlt[m]>
What is swappable packages? I have not seen such description yet.
<Eighth_Doctor>
generically, they're known as mutually conflicting packages
<davidlt[m]>
I don't expect that in upstream Koji setup. I am ingesting all possible work (past, present, dead, WIP), policies, etc.
<Eighth_Doctor>
if two packages have Provides+Conflicts of the same virtual name, RPM and DNF consider them equivalent providers, but only allow one of them to be installed at a time
<davidlt[m]>
Ah, that's a better term :)
<Eighth_Doctor>
I call them swappable because you use "dnf swap" to switch between them ;)
<davidlt[m]>
That explains it already :)
<davidlt[m]>
Okay, so let's say I want to swap a system package to replace it with a vendor. Well the actual package name would be different of course, maybe glibc-{thead,starfive,sifive,etc.}, but binaries would be direct replacements.
<davidlt[m]>
Same config.
<davidlt[m]>
I was looking at RPMFusion and how Fedora works, it seems they try their best to avoid RPM name conflicts. Packages sometimes match names (e.g. ffmpeg), but produced RPMs do not.
<davidlt[m]>
So technically in my book RPM Fusion is replacing a system package. Well the content is replaced, the actual RPM name is different.
<davidlt[m]>
So is the only rule is not avoid having the same RPM names as the ones provided in Fedora repositories?
<Eighth_Doctor>
well, that's a "special" example
<davidlt[m]>
Looking at 3rd party repo rules:
<davidlt[m]>
> RPM packages in a third-party repository must not replace packages provided by official Fedora repositories, nor break dependencies between those packages.
<Eighth_Doctor>
there's a bit of acrimony over ffmpeg, which has prevented resolving that particular issue
<davidlt[m]>
There are/were more packages like that.
<Eighth_Doctor>
the only other one I'm aware of is mesa-va-drivers-freeworld
<davidlt[m]>
Yeah. Mesa is another good example.
<Eighth_Doctor>
that one is a swappable package
<davidlt[m]>
So here is a thing. Until x86_64-v{2,3,4} and the same issues for RVA{20,22,23} is solved I am thinking about vendor specific repos (most likely not a full distro).
<davidlt[m]>
Different thing. Potentially a stop-gap solution.
<davidlt[m]>
It shouldn't be hard to keep those up to date. I already see that in my head.
<Esmil>
davidlt[m]: don't hesitate to talk to Heinrich about this as well. i'm sure this is an issue all distros will face eventually
<davidlt[m]>
Esmil: I know. All distros have issues here. He mentioned already similar issues.
<Esmil>
Cool
<davidlt[m]>
Esmil: I just don't know if all distros will take a similar approach.
<Eighth_Doctor>
one way to make those overlay packages work is to set a vendor tag to make it so those packages are built to identify differently
<davidlt[m]>
Right now I kinda want full flexibility. (1) optimized binaries for different profiles via glibc-hwcaps (2) full distro recompiled for a profile (preferably using the same RPMS as in (1) and (3) vendor repositories for optimized libraries that could be locked to a vendor.
<Eighth_Doctor>
in preparation for that, we need DNF's defaults to change
<davidlt[m]>
Conan Kudo: yeah, that's fine.
<davidlt[m]>
Conan Kudo: do you plan to be at FOSDEM/DevConf/Flock/something?
<Eighth_Doctor>
FOSDEM yes
<Eighth_Doctor>
the rest, who knows
<Eighth_Doctor>
I'm funding my travel to FOSDEM out of pocket :)
<Eighth_Doctor>
and technically will be unemployed during that time :P
<Eighth_Doctor>
(I'll be gainfully employed afterward)
<davidlt[m]>
Oh, epic. I seems you are also active during Europe time zones ;)
<Eighth_Doctor>
I shouldn't be
<Eighth_Doctor>
I live in the US east coast
<davidlt[m]>
Don't tell me that you are in US and chatting now :)
<Eighth_Doctor>
yup
<Eighth_Doctor>
I literally woke up to you pinging me
<Eighth_Doctor>
CentOS Hyperscale SIG is using the vendor stuff extensively, and we had the CentOS Koji tags for us configured accordingly: https://pagure.io/centos-infra/issue/621
<davidlt[m]>
Do you think it's worth me sending some emails with similar ideas (and probably generating way too many replies) or is worth thinking more about this. Clearly I don't have all the info yet. Your name keeps popping up in my research.
<Eighth_Doctor>
COPR automatically sets a unique vendor per namespace
<Eighth_Doctor>
e.g. ngompa/foo gets "Fedora COPR provided by ngompa" or something like that
<davidlt[m]>
Yeah, so I could to vendor="Fedora VisionFive V2", rebuild some RPMs (e.g. glibc, openssl, gnutls, etc.)
<davidlt[m]>
Create a repo, do dnf swap and set allow_vendor_change=False ?
<Eighth_Doctor>
yes
<davidlt[m]>
(Well, if policy allows)
<Eighth_Doctor>
I strongly suggest you make a F39 Change to switch DNF's default behavior
<Eighth_Doctor>
talk to the DNF team first, but I think they'd be fine with it
<Eighth_Doctor>
they're in #yum:matrix.org
<davidlt[m]>
Also the whole thing doesn't work with distro-sync
<davidlt[m]>
You seem to know a lot of what I am getting more interested it, would be great to get some more knowledge from you about it at FOSDEM :)
<Eighth_Doctor>
I did this stuff for a living :)
<Eighth_Doctor>
nobody likes what I have to say, but I speak with the scars of experience :)
<davidlt[m]>
What I need is to figure out how Fedora as a distro does not get stuck with RVA20/RV64GC, but constantly moves forward without making users angry. Seems that it would work for x86_64-v{2,3,4} stuff too.
<davidlt[m]>
I know that vendors will want to have optimized libraries. That happened with ARMv8 + enterprise stuff, that will happen here too.
<kwizart>
> <Eighth_Doctor> there's a bit of acrimony over ffmpeg, which has prevented resolving that particular issue
<kwizart>
can you elaborate ?
<Eighth_Doctor>
davidlt: I've wanted optimized binaries for a few years now
<Eighth_Doctor>
in OpenMandriva, I helped implement the AMD Ryzen optimized build
<davidlt[m]>
Conan Kudo: I wan to hear more about it too :)
<Eighth_Doctor>
I have scars from this
<Eighth_Doctor>
I wanted to also implement sysroot multiarch, but my PR to actually make this work is stuck in limbo
<davidlt[m]>
"sysroot multi-arch" does not very nice, but hey I probably don't know the details.
<davidlt[m]>
The way I feel is: if I don't find a way to provide optimizations in Fedora/RISCV land vendors might just rebuild distros with their own things. That's not what I want.
<Eighth_Doctor>
it means that all archful binaries go into /usr/target/{bin,lib(64),libexec}
<Eighth_Doctor>
then we have /usr/host -> /usr/target symlink
<davidlt[m]>
Isn't that a bit similar to glibc-hwcaps?
<Eighth_Doctor>
and /usr/{bin,lib(64),libexec} -> /usr/host/{bin,lib(64),libexec}
<Eighth_Doctor>
not quite
<Eighth_Doctor>
what this does is enable installing any arch on your system
<davidlt[m]>
yeah, not quite, but kinda close on a single arch-family.
<Eighth_Doctor>
right
<Eighth_Doctor>
but it also enables trivially supporting emulated arches too
<davidlt[m]>
Except binaries are not incl. in glibc-hwcaps too.
<Eighth_Doctor>
the hwcaps would still install into their target lib64 subdirectory
<davidlt[m]>
Yeah, but it's only wired for shared libraries.
<Eighth_Doctor>
yeah
<Eighth_Doctor>
the idea is that it generalizes multilib to all archful content
<davidlt[m]>
It works out-of-the-box in Fedora, just no packages install there.
<Eighth_Doctor>
and simplifies parallel installation of multiple subarches
<Eighth_Doctor>
because "target" is the platform triple
<Eighth_Doctor>
all subset cases would work properly too: debian-style multiarch, fedora-style multilib, etc.
<davidlt[m]>
I need to run for a bit, but I will be back within an hour.
<davidlt[m]>
I think it would be best to chat in Brussels sometime. Maybe take BoF slot?
<davidlt[m]>
Fedora/RISCV BoF or just sub-arch variant/optimized binaries in general.
<Eighth_Doctor>
maybe
<Eighth_Doctor>
I haven't decided yet how much I'll participate in FOSDEM itself
<Eighth_Doctor>
depends on how much I don't want to feel like I'm in a meatpacking facility
<davidlt[m]>
Outside FOSDEM is fine too. FOSDEM for me is more about meeting folks, not going to the talks.
<davidlt[m]>
There will be videos afterwards.
<davidlt[m]>
Okay, now I truly have to run. Be balk a bit later.
* davidlt[m]
back
<davidlt[m]>
Another 3 commits landed in GCC repo
<davidlt[m]>
Well, instead I am building glibc pre-2.37 for now
jcajka has quit [Quit: Leaving]
<davidlt[m]>
Conan Kudo: one thing that I don't like about vendor lock is that DNF will not warn me if vendor NVR is outdated or not.
<davidlt[m]>
Like I would like to know if vendor is late to deliver that openssl with CVE fixes.
<davidlt[m]>
I would like dnf update to tell me that vendor is falling behind (somehow).
<davidlt[m]>
Probably checking if there is a newer NVR (ignoring vendor lock). If that's a case vendor is falling behind.
<Eighth_Doctor>
that's logistically not possible without some kind of extra service or tracking to add relationships
<Eighth_Doctor>
there's not enough information in the repodata alone to be able to divine that information
<davidlt[m]>
Yeah, and package name must be different.
<davidlt[m]>
If package names would be the same vendor lock True/False would result in a different package.
<davidlt[m]>
Well, it's enough of thinking for today :) I should experiment with this stuff some other day to see what's the experience is like.
dtometzki has quit [Quit: Reconnecting]
dtometzki has joined #fedora-riscv
<neil>
one of my starfive boards came this weekend :)
<davidlt[m]>
neil: nice, enjoy a new toy ;)
<neil>
:D when i find some time lol
<davidlt[m]>
Yeah
<davidlt[m]>
I need to check mine tracking details.
<davidlt[m]>
I think UPS cannot decide when to deliver. It constantly changes :)
<neil>
just read/skimmed the scrollback today about the different optimized packages.. very interesting. i have some personal interest in that too w.r.t. hyperscale for rebuilding some things for (e.g., specific intel targets)
<davidlt[m]>
It is stuck somewhere in Germany for the last 2 days
<davidlt[m]>
neil: yeah, it's a very interesting topic and things are moving (in general) forward, but at different speeds on different distros.
* neil
worries a lot about installer size bloat
<davidlt[m]>
I think for Intel/AMD per-machine (well uarch) is a bit too much, but x86_64-v{2,3,4} variants make life a bit easier.
<davidlt[m]>
Well large companies don't install via ISO :) It's all KS + PXE install anyways from Foreman or something (I guess).
<neil>
hehe but people always like to complain about the ISO anyways... not that the `dvd` has fit on a DVD in some years
<davidlt[m]>
Either it bare metal provisioning or even better, private cloud (or probably container runtime, or mixed these days). [Kubernetes with container + virtualization].
<neil>
absolutely.. things like ostree/coreos make even more sense too as you can just have different trees with the right rpms to use
<neil>
in any case, this sounds really cool. i'd love to try and help!
<davidlt[m]>
Yeah, for a single user with a limited connection it's a problem. It's not a problem for hyperscaler.
<neil>
i'd be mildly concerned if hyperscalers were installing off the internet
<davidlt[m]>
I think we need to figure out all things Conan Kudo did already over the years (what merged, what didn't, what's missing).
<neil>
100%. sounds like he just told us where he's going to be, and when! :P
<davidlt[m]>
Yup
<davidlt[m]>
I think there was a patch for zen4 in RPM.
<davidlt[m]>
x86_64-v{2,3,4} and RVA20/22/23 gives us most of the benefits (or should give).
<davidlt[m]>
Conan Kudo: do you plan to attempt extending RPM with zen1/2/3/4 stuff?
<Eighth_Doctor>
maybe
<Eighth_Doctor>
I'm a little tired of the changing goalposts
<Eighth_Doctor>
and actually I'm probably going to propose OpenMandriva swap from znver1 to x86_64-v3
<Eighth_Doctor>
or even x86_64-v4, since all Ryzen models support AVX512
<neil>
that seems sane. i've started putting together a... _something_ trying to grok this. will share w/ you davidlt[m] when I have it in something more... parseable