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
<ol> Uh-oh… Please disregard my arguments about Delirium Pub.
<ol> > no official FOSDEM beer event
<davidlt[m]> I wouldn't be surprised if all folks still go there.
<davidlt[m]> > We are now in a hard ABI freeze in preparation for the upcoming glibc 2.37... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/ca6fd4f6e37d1b1c60d1ed5a5d859778240d2bae>)
<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.
<davidlt[m]> I am getting a bit confused ingesting all this information right now. For example, I get impression that Fedora strictly prohibits replacing system packages: https://docs.fedoraproject.org/en-US/fesco/Third_Party_Repository_Policy/#_duplicates_and_replacements
<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]> > ffmpeg-5.1.2-3.fc37.x86_64 : Digital VCR and streaming server... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/ccd01b85429c5b61f75da601d0e843da01fcf528>)
<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]> Ah, it was Conan Kudo again: https://github.com/rpm-software-management/rpm/pull/1035
<davidlt[m]> It was for zen1
<davidlt[m]> The problem here is that detection stuff will grow.
<davidlt[m]> and again Conan Kudo pointed to https://github.com/dmach/libarch
<neil> yeah i can see this detection thing becoming very.. interesting
<neil> and complicated
<davidlt[m]> neil: so your interest is to target specific uarch?
<neil> well, was to target specifically x86-v3+ compiler flags for some (or all) packages
<davidlt[m]> I would be interested in something beyond arch variants, like targeting "haswell" (i.e. uarch) directly.
<davidlt[m]> I think it was to be some packages to begin width due to resources.
<davidlt[m]> glibc-hwcaps don't work on uarch. There are legacy HWCAP thing, but I they want to remove it IIRC.
<neil> i'd looked into that at some point I think
<davidlt[m]> glibc-hwcaps replaces legacy HWCAP, but the problem is that glibc-hwcaps directories are only for the shared libraries.
<davidlt[m]> I should not be thinking about this in the evening otherwise I will continue this in the dreams.
<neil> lol
<neil> go think of more fun things before bed :)
<neil> TY for the links and info. lots to digest
<neil> (and ty to Eighth_Doctor, as well !)
<davidlt[m]> Too much, I feel I need Google Docs to keep track of all this thing.
<davidlt[m]> Basically vendor wants -mach=my_magic_uarch
<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