[EPEL-devel] Fedora EPEL 7 updates-testing report
The following Fedora EPEL 7 Security updates need testing: Age URL 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-4821639cb4 chromium-112.0.5615.49-1.el7 3 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-fca191b57e libyang-2.0.164-2.el7 The following builds have been pushed to Fedora EPEL 7 updates-testing argparse-manpage-4.1-1.el7 calceph-3.5.2-1.el7 coturn-4.6.2-1.el7 python-calcephpy-3.5.2-1.el7 Details about builds: argparse-manpage-4.1-1.el7 (FEDORA-EPEL-2023-967e948200) Build manual page from Python ArgumentParser object Update Information: - new `--include` feature, inspired by `help2man --include` - allow overriding build date with SOURCE_DATE_EPOCH environment variable - the AUTHORS section was changed to more standard AUTHOR ChangeLog: * Sat Apr 15 2023 Pavel Raiskup - 4.1-1 - new `--include` feature, inspired by `help2man --include` - allow overriding build date with SOURCE_DATE_EPOCH environment variable - the AUTHORS section was changed to more standard AUTHOR * Wed Jan 18 2023 Fedora Release Engineering - 4-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_38_Mass_Rebuild calceph-3.5.2-1.el7 (FEDORA-EPEL-2023-4ef592fb68) Astronomical library to access planetary ephemeris files Update Information: Update to 3.5.2 ChangeLog: * Sat Apr 15 2023 Mattia Verga - 3.5.2-1 - Update to 3.5.2 (fedora#2185865) * Wed Jan 18 2023 Fedora Release Engineering - 3.5.1-3 - Rebuilt for https://fedoraproject.org/wiki/Fedora_38_Mass_Rebuild * Wed Jul 20 2022 Fedora Release Engineering - 3.5.1-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_37_Mass_Rebuild coturn-4.6.2-1.el7 (FEDORA-EPEL-2023-6381774820) TURN/STUN & ICE Server Update Information: # Coturn 4.6.2 - Fix MSVC CI build - Prometheus: make sure microhttpd starts using epoll if supported - Fix typo in `mainrelay.c` - Remove unused include that breaks OpenBSD - Delete `LICENSE.OpenSSL` - use santisied psql string - Use the actual redis connection string to connect, not the sanitized one - Implement non-blocking recvfrom on Windows - Add contributing guidelines - Move and split documentation files - Use inline functions for errno checks - Add STUN request/response/error prometheus counters - Add configuration option for TLS 1.3 ciphersuites - Fix wrong usage of C-style in place generated array - bugfix: fix broken type label of `turn_total_allocations` gauge - Add explicit `SIGTERM` and `SIGINT` handlers - Set string bytes to null to prevent random origin - Regenerate manual pages from `README` files - Fix inverted logic in TLS configuration options - Reduce code duplication when printing userdb - Fix memory corruption on socket close - Cleanup logs on turnserver start - Optional build info compiled into turnserver binary - Fix duplicate prometheus metric report - Add sessioncount to prometheus metrics - Update openssl API use to non- deprecated version - Log `threadId` to logs to aid in multi-threaded debugging - Use khash 0.2.8 - Reflect new native Windows build support in documentation - Check and fix format string for `turn_log_func_default` - Properly calculate size for `sm_allocated` - Do not discard qualifiers in `free()` - Simplify defines for macOS platform - WINDOWS: unsigned long should not be used to store pointers - Reduce usage of `TURN_NO_HIREDIS` macros - Update to fix duplicate stdout log output - Use c11 standard - Reduce usage of `TURN_NO_PROMETHEUS` - Remove unnecessary declaration from header file - Support Windows MSVC - Fix resource leaks - Backlog fifo - Change rpm systemd service type from notify to exec - Add missing comma - Fix off-by-one when terminating gcm_nonce - Use `%zu` format specifier for `size_t` - Fix variable argument handling - Cleanup openssl initialization - fuzzing support - created `netengine.c` `get_relay_server` utility method to reduce code duplication - fix bug in calls to `ssl_read` and `ssl_send` where extra verbose flag goes missing - ignore raw UDP if `no_udp` is enabled - Sanitize DB connection string before printing to log - Better detect SCTP protocol - Redis memleaks and socketleaks - Fix issue 51563 in oss-fuzz - Fix
[Bug 2170647] Please branch and build perl-Net-Telnet for EPEL 9
https://bugzilla.redhat.com/show_bug.cgi?id=2170647 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #4 from Fedora Update System --- FEDORA-EPEL-2023-591d95728d has been pushed to the Fedora EPEL 9 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-591d95728d See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2170647 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org 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/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Test upgrades from F37 to F38 - it will take you just a minute
Hi Zbyszek, On Thu, Feb 23, 2023 at 1:55 PM Zbigniew Jędrzejewski-Szmek < zbys...@in.waw.pl> wrote: > On Wed, Feb 22, 2023 at 09:34:14AM -0700, Nathanael D. Noblet wrote: > > On Wed, 2023-02-22 at 10:30 +0100, Miroslav Suchý wrote: > > > dnf --releasever=38 --setopt=module_platform_id=platform:f38 \ > > > --enablerepo=updates-testing \ > > > $(rpm -q fedora-repos-modular >/dev/null && echo -- > > > enablerepo=updates-testing-modular) \ > > > --assumeno distro-sync > > > > I got > > > > Error: > > Problem: package msv-xsdlib-1:2013.6.1-19.fc33.noarch requires > > mvn(relaxngDatatype:relaxngDatatype), but none of the providers can be > > installed > > - jaxb-relaxng-datatype-2.3.5-7.fc37.noarch does not belong to a > > distupgrade repository > > Once msv-xsdlib is removed, jaxb-relaxng-datatype should update. > > > - problem with installed package msv-xsdlib-1:2013.6.1-19.fc33.noarch > > (try to add '--skip-broken' to skip uninstallable packages) > > I'll add this one to fedora-obsolete-packages. > > It looks like you've only added the main package msv [0]. However, that package doesn't exist as a binary rpm, the srpm only produces msv-* subpackages [1]. And obsoleting the main package won't obsolete the subpackages, so this conflict is not fixed yet. I'm not sure if any of the other msv-* subpackages should also be obsoleted or just msv-xsdlib. > > I don't know why those are installed (I don't recognize the packages > > and they aren't dependencies of anything I know I need) and just > > removed them and everything was good after that. > > Zbyszek > [0] https://src.fedoraproject.org/rpms/fedora-obsolete-packages/c/84990c998a074df88521ee48160fce1fd8d5cc9d?branch=rawhide [1] https://koji.fedoraproject.org/koji/buildinfo?buildID=1558554 -- Elliott ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: subarchitectures and RISC-V, was Re: F39 proposal: RPM 4.19 (System-Wide Change proposal)
On Sat, Apr 15, 2023 at 08:38:47AM -0600, Jeff Law wrote: > > > On 4/15/23 00:10, David Abdurachmanov wrote: > > > > > > We have to support SCBs as-is. We even have 64-core OoO (and even > > dual-socket 128-core) systems coming that are still RVA20 (what I call > > "a large scale SBC trying to be a server"). > I think elsewhere you suggested treating the profile as the subarch for RPM. > That may be a viable way to handle the SBC space. > > I still worry about supporting multiple profiles and would like to see a > clear path to deprecating profiles that are out of date. The amount of pain > I've seen in both the x86 and aarch worlds WRT baselines is something I'm > keen to avoid repeating. Yeah, completely agreed. From an infrastructure standpoint, I would love to get riscv in fedora as a primary arch, but I don't think it's practical at all to bring in 3 or 4 or whatever subarches. There's just no hardware that could actually keep up with mainline fedora currently and the duplication of effort building 23,000 packages over N slightly different subarches is not very tenable. The rpm subarches might be a useful path, but then determining what you build for multiple of them and how needs to be addressed. I think we can point people to arm history and try and get them to not repeat it (although perhaps it's too late for a lot of it). > > > > But Fedora RISCV as-is is not how future Fedora RISCV should be. The > > future is RVA23 (or beyond) and standard compliance. There will be > > significant performance differences between profiles for some time. > > Especially RVA20 -> RVA23. RVA20 (or RVA64GC) is just way too small > > with lack of modern ISA. We have had a toy for ~10 years now, and now > > we are moving toward high-performance servers, even HPC, Android (see > > latest Google announcements), etc. That's not driven by RVA20. That's > > RVA23 (and beyond) + vendor extensions. Completely agree. > > Yes! Blocked by lack of "hw probe" interface. There will be "hw probe" > > syscall for RISCV, in v6.4 and v6.5 kernel (I hope). We don't have > > cpuid instruction, HWCAP is way too small for all the extensions > > available. > I'm sure folks will get this sorted out. My only concern with the syscall > was to make sure the glibc folks were on board with using that to drive > ifunc selection. It's a fairly different approach than has been taken in > the past and I want to make sure it's not DOA for glibc. > > Once the kernel & glibc teams reach API agreement I think we'll be able to > make a reasonable query about the system properties in multiple contexts, > including the installer, rpm, etc. That would be great. > > Note that toolchains don't accept RISCV Profiles yet, but that has > > been under discussion for quite some time already. I would assume > > starting GCC 14 timeframe all of that should work. > It'll get sorted out. We've got some bigger fish to fry WRT landing V > support (if you've managed to avoid that mess, consider yourself lucky). > > Lots of stuff is backed up behind getting gcc-13 out the door so that gcc-14 > development can open up. Not sure where profiles will fall into the > priority list, it's hard to see past the V effort right now. Yep. And a lot of it is things that just need to mature and hardware that needs to exist and code and... ;) But hopefully we will get there. kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: subarchitectures and RISC-V, was Re: F39 proposal: RPM 4.19 (System-Wide Change proposal)
On 4/15/23 00:25, David Abdurachmanov wrote: On Sat, Apr 15, 2023 at 7:08 AM Jeff Law wrote: On 4/14/23 20:14, Neal Gompa wrote: We should not screw up with RISC-V in Fedora like RHEL did with ARM. Yes, I'm saying RHEL's ARM strategy was a mistake, and still is, to some degree. We see aspects of this being walked back now as the ecosystem didn't go the way RHEL ARM folks hoped, and breaking further into that ecosystem requires reversing some of those choices. We should learn from that for Fedora RISC-V. Well, the RHEL direction was essentially mandated by the markets vendors were chasing. Plain and simple. You may say RHEL's ARM strategy was a mistake, but I'd disagree strongly. Fedora != CentOS Stream or/and RHEL. I am *well* aware. I wouldn't have brought RHEL into the discussion at all if Neal hadn't ;-) I am gonna repeat myself. I doubt there will be a need to support anything below RVA23 in CentOS Stream. That of course would mean that existing (or near future, yet to be announced) SBCs wouldn't be able to run it. Agreed. It's hard to see a case where anyone that wants Centos on RVA20. RVA23 is a much more realistic target. That's already happened. Stratification was inevitable given the RISC-V model. The only questions in my mind are viability in the server space and whether or not that could one day lead to offerings between server class and the SBC systems. Brings high-performance (and yet cheap) SBCs that it's fully compliant is too expensive today (i.e. you would lose money doing it [personal opinion]). It's going to happen, it's most likely coming from the Chinese market [personal opinion]. You're probably right on all those points. I could say that Ubuntu is the dominating distribution for RISCV SBCs. Canonical engineering resources and willingness to support pretty much every SBC (but with vendor kernel or/and firmware) is really hard to compete with. If you want to get the best out-of-the-box experience on your RISCV SBCs definitely Ubuntu is #1 suggestion, but that wasn't the case for many years. Ubuntu came to RISCV land very late (I would say somewhat recently), but now should be dominating (no way to confirm). Nice work by the Ubuntu community and Canonical engineers. They truly want to support every piece of hardware available out there. Agreed. And one can certainly question the sanity and business model of supporting all those SBCs. But if you look beyond the SBC space, Ubuntu has positioned themselves well to be the distro of choice for aspiring server platforms. One might even look at the SBC engagement as really just positioning themselves for the future (speculation on my part). Ubuntu may have come late, but they're engaged at a level that the Fedora community isn't even close to matching. Jeff ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: subarchitectures and RISC-V, was Re: F39 proposal: RPM 4.19 (System-Wide Change proposal)
On 4/15/23 00:10, David Abdurachmanov wrote: We have to support SCBs as-is. We even have 64-core OoO (and even dual-socket 128-core) systems coming that are still RVA20 (what I call "a large scale SBC trying to be a server"). I think elsewhere you suggested treating the profile as the subarch for RPM. That may be a viable way to handle the SBC space. I still worry about supporting multiple profiles and would like to see a clear path to deprecating profiles that are out of date. The amount of pain I've seen in both the x86 and aarch worlds WRT baselines is something I'm keen to avoid repeating. But Fedora RISCV as-is is not how future Fedora RISCV should be. The future is RVA23 (or beyond) and standard compliance. There will be significant performance differences between profiles for some time. Especially RVA20 -> RVA23. RVA20 (or RVA64GC) is just way too small with lack of modern ISA. We have had a toy for ~10 years now, and now we are moving toward high-performance servers, even HPC, Android (see latest Google announcements), etc. That's not driven by RVA20. That's RVA23 (and beyond) + vendor extensions. Yes! Blocked by lack of "hw probe" interface. There will be "hw probe" syscall for RISCV, in v6.4 and v6.5 kernel (I hope). We don't have cpuid instruction, HWCAP is way too small for all the extensions available. I'm sure folks will get this sorted out. My only concern with the syscall was to make sure the glibc folks were on board with using that to drive ifunc selection. It's a fairly different approach than has been taken in the past and I want to make sure it's not DOA for glibc. Once the kernel & glibc teams reach API agreement I think we'll be able to make a reasonable query about the system properties in multiple contexts, including the installer, rpm, etc. Note that toolchains don't accept RISCV Profiles yet, but that has been under discussion for quite some time already. I would assume starting GCC 14 timeframe all of that should work. It'll get sorted out. We've got some bigger fish to fry WRT landing V support (if you've managed to avoid that mess, consider yourself lucky). Lots of stuff is backed up behind getting gcc-13 out the door so that gcc-14 development can open up. Not sure where profiles will fall into the priority list, it's hard to see past the V effort right now. jeff ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: subarchitectures and RISC-V, was Re: F39 proposal: RPM 4.19 (System-Wide Change proposal)
Once upon a time, David Abdurachmanov said: > I would love to avoid supporting SBCs, especially as some of them are > really not suitable for feature rich Linux distributions. For me, my only interest in the foreseeable future for RISC-V would be SBCs, as an alternative to ARM (e.g. Raspberry Pi). It's not a matter of "afford" so much as there are hobbyist hardware projects and such that fit the SBC form rather than desktop/server form, and x86 has proved too expensive for that market (and failed just about every time it is tried). -- Chris Adams ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Fedora rawhide compose report: 20230415.n.0 changes
OLD: Fedora-Rawhide-20230414.n.0 NEW: Fedora-Rawhide-20230415.n.0 = SUMMARY = Added images:1 Dropped images: 0 Added packages: 2 Dropped packages:1 Upgraded packages: 150 Downgraded packages: 0 Size of added packages: 9.20 MiB Size of dropped packages:2.04 MiB Size of upgraded packages: 4.98 GiB Size of downgraded packages: 0 B Size change of upgraded packages: -62.43 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: Kinoite dvd-ostree ppc64le Path: Kinoite/ppc64le/iso/Fedora-Kinoite-ostree-ppc64le-Rawhide-20230415.n.0.iso = DROPPED IMAGES = = ADDED PACKAGES = Package: atomes-1.1.11-8.fc39 Summary: An atomistic toolbox RPMs:atomes Size:9.18 MiB Package: rust-gst-plugin-version-helper-0.7.5-1.fc39 Summary: Build.rs helper function for GStreamer plugin metadata RPMs:rust-gst-plugin-version-helper+default-devel rust-gst-plugin-version-helper-devel Size:19.31 KiB = DROPPED PACKAGES = Package: fontawesome5-fonts-5.15.4-4.fc38 Summary: Support files for the FontAwesome 5 fonts RPMs:fontawesome5-brands-fonts fontawesome5-fonts fontawesome5-fonts-all fontawesome5-fonts-web fontawesome5-free-fonts Size:2.04 MiB = UPGRADED PACKAGES = Package: NetworkManager-sstp-1:1.3.1-3.fc39 Old package: NetworkManager-sstp-1:1.3.1-2.fc38 Summary: NetworkManager VPN plugin for SSTP RPMs: NetworkManager-sstp NetworkManager-sstp-gnome Size: 959.69 KiB Size change: -31.54 KiB Changelog: * Fri Apr 14 2023 Florian Weimer - 1:1.3.1-3 - Port to C99 Package: amanda-3.5.3-2.fc39 Old package: amanda-3.5.3-1.fc39 Summary: A network-capable tape backup solution RPMs: amanda amanda-client amanda-libs amanda-server Size: 8.43 MiB Size change: -2.31 KiB Changelog: * Fri Apr 14 2023 Florian Weimer - 3.5.3-2 - Port configure script to C99 Package: ansible-collection-ansible-posix-1.5.2-1.fc39 Old package: ansible-collection-ansible-posix-1.5.1-1.fc38 Summary: Ansible Collection targeting POSIX and POSIX-ish platforms RPMs: ansible-collection-ansible-posix Size: 119.60 KiB Size change: 3.19 KiB Changelog: * Fri Apr 14 2023 Maxwell G - 1.5.2-1 - Update to 1.5.2. Fixes rhbz#2185694. Package: awscli-1.27.114-1.fc39 Old package: awscli-1.27.113-1.fc39 Summary: Universal Command Line Environment for AWS RPMs: awscli Size: 3.31 MiB Size change: 17.22 KiB Changelog: * Fri Apr 14 2023 Gwyn Ciesla - 1.27.114-1 - 1.27.114 Package: clang-16.0.1-1.fc39 Old package: clang-16.0.0-1.fc39 Summary: A C language family front-end for LLVM RPMs: clang clang-analyzer clang-devel clang-libs clang-resource-filesystem clang-tools-extra clang-tools-extra-devel git-clang-format python3-clang Size: 235.18 MiB Size change: -166.72 KiB Changelog: * Thu Mar 23 2023 Tulio Magno Quites Machado Filho - 16.0.0-2 - Remove unnecessary patch and macro * Wed Apr 12 2023 Timm B??der - 16.0.0-3 - Use correct source for clang.macros file * Wed Apr 12 2023 Tulio Magno Quites Machado Filho - 16.0.1-1 - Update to LLVM 16.0.1 Package: classified-ads-0.16-1.fc39 Old package: classified-ads-0.15-3.fc38 Summary: Classified ads is distributed, server-less messaging system RPMs: classified-ads Size: 4.46 MiB Size change: 45.96 KiB Changelog: * Sun Mar 12 2023 Antti J??rvinen - 0.16-1 - New upstream release 0.16. Protocol connectivity fixes and translations. Package: clazy-1.11-7.fc39 Old package: clazy-1.11-6.fc39 Summary: Qt oriented code checker based on clang framework RPMs: clazy Size: 2.50 MiB Size change: 431 B Changelog: * Thu Apr 13 2023 Jan Grulich - 1.11-7 - Rebuild against fixed clang Package: compiler-rt-16.0.1-1.fc39 Old package: compiler-rt-16.0.0-1.fc39 Summary: LLVM "compiler-rt" runtime libraries RPMs: compiler-rt Size: 8.26 MiB Size change: 1.09 KiB Changelog: * Thu Apr 13 2023 Tulio Magno Quites Machado Filho - 16.0.1-1 - Update to LLVM 16.0.1 Package: cpp-httplib-0.12.2-2.fc39 Old package: cpp-httplib-0.12.0-3.fc39 Summary: A C++11 single-file header-only cross platform HTTP/HTTPS library RPMs: cpp-httplib-devel Size: 322.25 KiB Size change: 9.70 KiB Changelog: * Fri Apr 14 2023 Petr Menk - 0.12.2-1 - Update to 0.12.2 (#2177353) * Fri Apr 14 2023 Petr Menk - 0.12.2-2 - Require cmake-filesystem. Package: cups-pk-helper-0.2.7-3.fc39 Old package: cups-pk-helper-0.2.7-2.fc38 Summary: A helper that makes system-config-printer use PolicyKit RPMs: cups-pk-helper Size: 373.18 KiB Size change: -2.43 KiB Changelog: * Tue Apr 04 2023 Yaakov Selkowitz - 0.2.7-3 - Update dependencies Package: diskimage-builder-3.26.0-1.fc39 Old package: diskimage-builder-3.2
[Bug 2170647] Please branch and build perl-Net-Telnet for EPEL 9
https://bugzilla.redhat.com/show_bug.cgi?id=2170647 Fedora Update System changed: What|Removed |Added Status|NEW |MODIFIED --- Comment #3 from Fedora Update System --- FEDORA-EPEL-2023-591d95728d has been submitted as an update to Fedora EPEL 9. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-591d95728d -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2170647 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org 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/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: octave 8.1 update coming to rawhide
Is there a chance to have Octave 8.1 at F38? вс, 9 апр. 2023 г. в 18:49, Orion Poplawski : > > On 4/8/23 17:27, Orion Poplawski wrote: > > On 4/5/23 20:22, Orion Poplawski wrote: > >> I will be updating octave to 8.1 this weekend. This involves a soname > >> bump and I will be rebuilding all deps. > > Builds are complete and update submitted: > > https://bodhi.fedoraproject.org/updates/FEDORA-2023-56669c4da2 > > -- > Orion Poplawski > he/him/his - surely the least important thing about me > IT Systems Manager 720-772-5637 > NWRA, Boulder/CoRA Office FAX: 303-415-9702 > 3380 Mitchell Lane or...@nwra.com > Boulder, CO 80301 https://www.nwra.com/ > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > 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/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: subarchitectures and RISC-V, was Re: F39 proposal: RPM 4.19 (System-Wide Change proposal)
On Sat, Apr 15, 2023 at 7:08 AM Jeff Law wrote: > > > > On 4/14/23 20:14, Neal Gompa wrote: > > >> > > > > We should not screw up with RISC-V in Fedora like RHEL did with ARM. > > Yes, I'm saying RHEL's ARM strategy was a mistake, and still is, to > > some degree. We see aspects of this being walked back now as the > > ecosystem didn't go the way RHEL ARM folks hoped, and breaking further > > into that ecosystem requires reversing some of those choices. We > > should learn from that for Fedora RISC-V. > Well, the RHEL direction was essentially mandated by the markets vendors > were chasing. Plain and simple. You may say RHEL's ARM strategy was a > mistake, but I'd disagree strongly. Fedora != CentOS Stream or/and RHEL. Well, I have different opinions on what CentOS and RHEL should be/support in AArch64 days. CentOS Stream or/and RHEL is a different story, and shouldn't impact Fedora in exactly the same way. I am gonna repeat myself. I doubt there will be a need to support anything below RVA23 in CentOS Stream. That of course would mean that existing (or near future, yet to be announced) SBCs wouldn't be able to run it. > > > > > Like ARM, RISC-V risks (pun intended!) total stratification between > > low/mid range SBCs and unobtanium servers. Given the current path of the > > groups working in RISC-V, this is certain to happen. Thus, if Fedora > > RISC-V cannot run well on RISC-V SBCs, then we effectively have no > > useful RISC-V port, since nobody can use it. > That's already happened. Stratification was inevitable given the RISC-V > model. The only questions in my mind are viability in the server space > and whether or not that could one day lead to offerings between server > class and the SBC systems. Brings high-performance (and yet cheap) SBCs that it's fully compliant is too expensive today (i.e. you would lose money doing it [personal opinion]). It's going to happen, it's most likely coming from the Chinese market [personal opinion]. > > > > > > We already have similar problems with POWER (ppc64le) and Z (s390x), > > but the former was built in an era when there were computers of > > reasonable performance across all price points. The latter is > > basically funded by IBM development and nobody can really do anything > > with it. > The era where POWER was a viable platform outside the server space has > been gone for a long time. x86 just killed the market and it's not > clear there's space for anyone else in that market. Apple may prove me > wrong in that space, but the investment they've made is enormous. > > > > > > For the first time in a long time, Fedora has the opportunity to have > > a first-mover advantage and become the default platform for hobbyist, > > professional, and high-end systems of an architecture. Let's not > > squander it on myopic views of datacenter class hardware that don't > > exist yet leveraging specifications that nobody is implementing in > > currently available hardware. > First mover advantage is already lost to Ubuntu. Sad but true in my > mind. Fedora has zero presence in the spaces that matter. The first distributions to support RISCV were Debian and Fedora. I even would say we worked together while building things out, or hunting firmware/silicon bugs. I am still on the Debian IRC channel, and some Debian folks are still on Fedora IRC channel. I could say that Ubuntu is the dominating distribution for RISCV SBCs. Canonical engineering resources and willingness to support pretty much every SBC (but with vendor kernel or/and firmware) is really hard to compete with. If you want to get the best out-of-the-box experience on your RISCV SBCs definitely Ubuntu is #1 suggestion, but that wasn't the case for many years. Ubuntu came to RISCV land very late (I would say somewhat recently), but now should be dominating (no way to confirm). Nice work by the Ubuntu community and Canonical engineers. They truly want to support every piece of hardware available out there. Cheers, david > > > > > > Insofar as subarches go, let's just define them in RPM like we have > > for 32-bit x86 and more recently 64-bit x86. If we know what kind of > > ISA profiles are out there, we should just incorporate them into RPM > > and set up the compatibility detection logic for them to work. > The current and future crop of SBCs just aren't going to have the oomph > to be a viable platform in my mind. I can take a 10+ year old xeon run > qemu on top of it and get dramatically better risc-v performance than > the SBCs out there > > Creating subarch around something like rv20, go ahead. But it's going > to be worse than the armv7 situation was. > > jeff > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines:
Re: subarchitectures and RISC-V, was Re: F39 proposal: RPM 4.19 (System-Wide Change proposal)
On Sat, Apr 15, 2023 at 5:30 AM Neal Gompa wrote: > > On Fri, Apr 14, 2023 at 10:01 PM Jeff Law wrote: > > > > > > > > On 4/12/23 10:08, przemek klosowski via devel wrote: > > >> > > >> That may rule out certain processors, but it ultimately provides a > > >> higher performing baseline architecture for systems that are > > >> (hopefully) going to be good performing parts rather than embedded > > >> focused parts. > > > > > > Yes, good point, but there's already a number of profiles even though > > > they are barely out of the gate: > > > > > > https://github.com/riscv/riscv-profiles/blob/main/profiles.adoc > > I know. While I'm not involved in setting the profiles, I do get > > briefed on them reasonably often. > > > > > > > > I of course agree with you that it makes sense to focus support on a > > > small number of existing platforms with good reputation and performance > > > (for instance both VisionFive and Pine64 are based on StarFive JH7110 > > > SoC). > > Those are not particularly interesting in my mind for a distro target. > > If it can't run a performant system I'd put on my desk or in my rack, > > then it's an embedded target in my mind (yes, I'm over-generalizing). > > There's a place for those, but I don't think that should be Fedora's > > focus for RISC-V. > > > > Full disclosure. I work for Ventana and have a long history with Red > > Hat and Fedora. My vision for Fedora going back before it was actually > > launched as for a desktop/developer focused distribution similar to RHL, > > but free -- and as a feeder distribution into what was then known as > > Advanced Server, now RHEL. > > > > We should not screw up with RISC-V in Fedora like RHEL did with ARM. > Yes, I'm saying RHEL's ARM strategy was a mistake, and still is, to > some degree. We see aspects of this being walked back now as the > ecosystem didn't go the way RHEL ARM folks hoped, and breaking further > into that ecosystem requires reversing some of those choices. We > should learn from that for Fedora RISC-V. > > Like ARM, RISC-V risks (pun intended!) total stratification between > low/mid range SBCs and unobtanium servers. Given the current path of the > groups working in RISC-V, this is certain to happen. Thus, if Fedora > RISC-V cannot run well on RISC-V SBCs, then we effectively have no > useful RISC-V port, since nobody can use it. We are making the same (or similar) mistakes with RISCV as ARM. A long time ago I assumed this would not be the case. After working on this for years now, I think, this is something you cannot avoid. It's just "growing pains". A proper transition from pre-standards/compliance mess will take years too (probably less than a decade). We have to support SCBs as-is. We even have 64-core OoO (and even dual-socket 128-core) systems coming that are still RVA20 (what I call "a large scale SBC trying to be a server"). But Fedora RISCV as-is is not how future Fedora RISCV should be. The future is RVA23 (or beyond) and standard compliance. There will be significant performance differences between profiles for some time. Especially RVA20 -> RVA23. RVA20 (or RVA64GC) is just way too small with lack of modern ISA. We have had a toy for ~10 years now, and now we are moving toward high-performance servers, even HPC, Android (see latest Google announcements), etc. That's not driven by RVA20. That's RVA23 (and beyond) + vendor extensions. > > We already have similar problems with POWER (ppc64le) and Z (s390x), > but the former was built in an era when there were computers of > reasonable performance across all price points. The latter is > basically funded by IBM development and nobody can really do anything > with it. > > For the first time in a long time, Fedora has the opportunity to have > a first-mover advantage and become the default platform for hobbyist, > professional, and high-end systems of an architecture. Let's not > squander it on myopic views of datacenter class hardware that don't > exist yet leveraging specifications that nobody is implementing in > currently available hardware. SiFive P670 and XuanTie C908 (Alibaba T-HEAD) are already RVA22 compatible. It's typically years before IP announcement and actual physical product in your hands. But again, RVA22 is minor (it's just a stop-gap, snaphot), and true interest is RVA23 (and beyond). RVA20/RV64GC is to stay here for years to come. We should continue to support that, but we shouldn't be blocked by that and only support it. We need to hop on the RVI Profiles train model. > > Insofar as subarches go, let's just define them in RPM like we have > for 32-bit x86 and more recently 64-bit x86. If we know what kind of > ISA profiles are out there, we should just incorporate them into RPM > and set up the compatibility detection logic for them to work. Yes! Blocked by lack of "hw probe" interface. There will be "hw probe" syscall for RISCV, in v6.4 and v6.5 kernel (I hope). We don't have cpuid instruction, HWCAP is way too small for all the
