https://bugzilla.redhat.com/show_bug.cgi?id=2318425 --- Comment #27 from Jakub Čajka <jcajka@xxxxxxxxx> --- (In reply to Tom.Rix from comment #26) > (In reply to Jakub Čajka from comment #25) > > Package seems to be exclude arched, although it AFAIK should build fine and > > with basic functions(BLAS/CPU backend) present on all architectures. If > > there are any serious reasons could you please open tracking issues per > > architecture support guidelines > > https://docs.fedoraproject.org/en-US/packaging-guidelines/ > > #_architecture_support after this bug concludes. > > > > I'm looking at it atm and it seems as rather small changes to spec should > > enable all of it(conditional dependency on rocm, proper archstring in file > > paths etc.) > > I do not have any other the arch hw so i have now way to test or support it. > If you want to provide a patch for an arch you want, please send a pr. > package has been added to the go-sig (iirc), so anyone in it should be able > to enhance this package as needed. That is the reason for the policy :) and should have been caught in the review. When you file the tracking issue we are able to notice the issues and we will help you or just keep it as record why the package is missing on the respective arch. If you are not sure you can reach out to fedora-devel. Here I don't see any reason why this should depart from the Go packaging, target all goarchs. More broadly speaking there are development machines that all Fedora packagers do have access to(it is not only koji or COPR) or we can arrange access to more specific HW. I have opened PR with all the changes in pagure/dist-git. To note it seems that upstream is reducing CPU centered functionality of the package(stripping blas support, various archful optimizations), but basic CPU support still remains. I have noticed one more issue that got missed by review, manual stripping of binaries. That goes against the spirit of debuginfo policy(https://docs.fedoraproject.org/en-US/packaging-guidelines/Debuginfo/). If you need minimized binaries do the striping(if not done by debuginfo generation) in the container, image build when you use the package. If that is the case you could consider breaking up this package in to sub packages per the runner type, if you need to squeeze out every bit of size out of it. Assuming that the ollama server can tolerate missing runners. And last nitpick, offer. Ollama seems to be effectively daemon and could use a systemd integration/unit file. If you think it would be useful I can work on one. -- You are receiving this mail because: You are always notified about changes to this product and component You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2318425 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-spam&short_desc=Report%20of%20Bug%202318425%23c27 -- _______________________________________________ package-review mailing list -- package-review@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to package-review-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/package-review@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
