[EPEL-devel] Fedora EPEL 8 updates-testing report
The following Fedora EPEL 8 Security updates need testing: Age URL 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-99cf4e74b7 putty-0.81-1.el8 The following builds have been pushed to Fedora EPEL 8 updates-testing openssl3-3.2.1-1.1.el8 stow-2.4.0-1.el8 Details about builds: openssl3-3.2.1-1.1.el8 (FEDORA-EPEL-2024-b002585dd2) Utilities from the general purpose cryptography library with TLS implementation Update Information: Merge in changes from c9s' openssl to pick up various CVE fixes and other bugfixes ChangeLog: * Mon Apr 22 2024 Michel Lind - 3.2.1-1.1 - Merge c9s openssl changes to pick up CVE fixes * Wed Apr 3 2024 Dmitry Belyavskiy - 1:3.2.1-1 - Rebasing OpenSSL to 3.2.1 Resolves: RHEL-26271 * Wed Feb 21 2024 Dmitry Belyavskiy - 1:3.0.7-27 - Use certified FIPS module instead of freshly built one in Red Hat distribution Related: RHEL-23474 * Tue Nov 21 2023 Dmitry Belyavskiy - 1:3.0.7-26 - Avoid implicit function declaration when building openssl Related: RHEL-1780 - In FIPS mode, prevent any other operations when rsa_keygen_pairwise_test fails Resolves: RHEL-17104 - Add a directory for OpenSSL providers configuration Resolves: RHEL-17193 - Eliminate memory leak in OpenSSL when setting elliptic curves on SSL context Resolves: RHEL-19515 - POLY1305 MAC implementation corrupts vector registers on PowerPC (CVE-2023-6129) Resolves: RHEL-21151 - Excessive time spent checking invalid RSA public keys (CVE-2023-6237) Resolves: RHEL-21654 - SSL ECDHE Kex fails when pkcs11 engine is set in config file Resolves: RHEL-20249 - Denial of service via null dereference in PKCS#12 Resolves: RHEL-22486 - Use certified FIPS module instead of freshly built one in Red Hat distribution Resolves: RHEL-23474 * Mon Oct 16 2023 Dmitry Belyavskiy - 1:3.0.7-25 - Provide relevant diagnostics when FIPS checksum is corrupted Resolves: RHEL-5317 - Don't limit using SHA1 in KDFs in non-FIPS mode. Resolves: RHEL-5295 - Provide empty evp_properties section in main OpenSSL configuration file Resolves: RHEL-11439 - Avoid implicit function declaration when building openssl Resolves: RHEL-1780 - Forbid explicit curves when created via EVP_PKEY_fromdata Resolves: RHEL-5304 - AES-SIV cipher implementation contains a bug that causes it to ignore empty associated data entries (CVE-2023-2975) Resolves: RHEL-5302 - Excessive time spent checking DH keys and parameters (CVE-2023-3446) Resolves: RHEL-5306 - Excessive time spent checking DH q parameter value (CVE-2023-3817) Resolves: RHEL-5308 - Fix incorrect cipher key and IV length processing (CVE-2023-5363) Resolves: RHEL-13251 - Switch explicit FIPS indicator for RSA-OAEP to approved following clarification with CMVP Resolves: RHEL-14083 - Backport the check required by SP800-56Br2 6.4.1.2.1 (3.c) Resolves: RHEL-14083 - Add missing ECDH Public Key Check in FIPS mode Resolves: RHEL-15990 - Excessive time spent in DH check/generation with large Q parameter value (CVE-2023-5678) Resolves: RHEL-15954 * Wed Jul 12 2023 Dmitry Belyavskiy - 1:3.0.7-24 - Make FIPS module configuration more crypto-policies friendly Related: rhbz#2216256 * Tue Jul 11 2023 Dmitry Belyavskiy - 1:3.0.7-23 - Add a workaround for lack of EMS in FIPS mode Resolves: rhbz#2216256 * Thu Jul 6 2023 Sahana Prasad - 1:3.0.7-22 - Remove unsupported curves from nist_curves. Resolves: rhbz#2069336 * Mon Jun 26 2023 Sahana Prasad - 1:3.0.7-21 - Remove the listing of brainpool curves in FIPS mode. Related: rhbz#2188180 * Tue May 30 2023 Dmitry Belyavskiy - 1:3.0.7-20 - Fix possible DoS translating ASN.1 object identifiers Resolves: CVE-2023-2650 - Release the DRBG in global default libctx early Resolves: rhbz#2211340 * Mon May 22 2023 Clemens Lang - 1:3.0.7-19 - Re-enable DHX keys in FIPS mode, disable FIPS 186-4 parameter validation and generation in FIPS mode Resolves: rhbz#2169757 * Thu May 18 2023 Dmitry Belyavskiy - 1:3.0.7-18 - Use OAEP padding and aes-128-cbc by default in cms command in FIPS mode Resolves: rhbz#2160797 * Tue May 9 2023 Dmitry Belyavskiy - 1:3.0.7-17 - Enforce using EMS in FIPS mode - better alerts Related: rhbz#2157951 * Tue May 2 2023 Sahana Prasad - 1:3.0.7-16 - Upload new upstream sources without manually hobbling them. - Remove the hobbling script as it is redundant. It is now allowed to ship the sources of patented EC curves, however it is still made unavailable to use by compiling with the 'no-ec2m' Configure option. The additional forbidden curves such as P-160, P-192, wap-tls curves are manually removed by updating 0011-Remove-EC-curves.patch. - Enable Brainpool curves. - Apply the changes to ec_curve.c and ectest.c as a new
[EPEL-devel] Re: Anyone want to maintain openssl3 for epel8?
On 4/22/24 17:03, Michel Lind wrote: I created this (tracking c9s' openssl package) since there were plans to start depending on openssl v3 in systemd back in 2022, but looks like that has not happened yet - and CentOS Hyperscale SIG is no longer updating our systemd package for c8s. The maintenance involved is mainly rebasing changes from c9s, though someone who actually have a need for this would be better able to verify that the builds are actually working. If there's no taker in two weeks, per https://docs.fedoraproject.org/en-US/epel/epel-policy-retirement/ I'll retire the package. As a parting gift, this update closes most of the open bugs. There are two CVEs from 2024 that I can't confirm are fixed in the c9s package so I left them in NEW https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-b002585dd2 Best regards, -- _o) Michel Lind _( ) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 OpenPGP_0x8B229D2F7CCC04F2.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature -- ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Fedora RISC-V port needs to put shared objects into /usr/lib64/lp64d
> > Just for your information, here's how Gentoo is doing things to stay > compatible > with as many variants as possible: > PS. Stage files are here: https://www.gentoo.org/downloads/#riscv (rv32-ilp32 is still building, rv32 musl is waiting until the worst musl-1.2.5 issues are ironed out...) -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, comrel, toolchain, base-system, perl, libreoffice) https://wiki.gentoo.org/wiki/User:Dilfridge signature.asc Description: This is a digitally signed message part. -- ___ 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
Review swaps
Hi all, I have 3 packages awaiting reviews. I'm happy to exchange. First is a new IBus input method (code includes bits of C and Python): ibus-array: https://bugzilla.redhat.com/show_bug.cgi?id=2275556 The other two are trivial rust packages that I need for upcoming libchewing release: rust-xflags-macrios: https://bugzilla.redhat.com/show_bug.cgi?id=2276537 rust-xflags: https://bugzilla.redhat.com/show_bug.cgi?id=2276539 Cheers, Kan-ru -- ___ 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: Fedora RISC-V port needs to put shared objects into /usr/lib64/lp64d
Hi, I'm handling the RISC-V libdirs in Gentoo. > There are multiple PRs and patches floating around that make RISC-V use > the /usr/lib64 directory, like other 64-bit ports. However, RISC-V > recommends to use /usr/lib64/lp64d for the Fedora ABI variant, and > various upstream projects follow that. From memory I think as per spec both variants are valid. For more than one ABI, only the latter makes sense of course. (It gets more complicated for 32bit, because there it's /usr/lib versus /usr/lib32/ilp32d ...) Just for your information, here's how Gentoo is doing things to stay compatible with as many variants as possible: 1) Non-multilib setups, 64bit /usr/lib64 2) Non-multilib setups, 32bit: /usr/lib 3) Multilib setups (example with primary ABI lp64d): * The *primary* ABI is using the non-multilib path, to keep binary compatibility /usr/lib64 * All *other* ABI use the multilib, two-level paths: /usr/lib64/lp64 /usr/lib32/ilp32d /usr/lib32/ilp32 * The two-level path of the *primary* ABI is a symlink to the non-multilib path. /usr/lib64/lp64d => /usr/lib64 (or equivalent, /usr/lib64/lp64d => . ) Installing the primary ABI into a two-level libdir is something we tried in the past, but it lead to some pain. There are too many build systems out there that assume that $(get_libdir) has one path level only, and then use expressions like (particularly stupid invented example) CONFIG_FILE=/usr/$(get_libdir)/../../etc/myconfig.conf which leads to chaos once $(get_libdir) outputs "lib64/lp64d" ... Cheers, Andreas (on vacation, expect >24h response times) > I think we should follow upstream, so that it's possible to use Fedora > to do upstream development without patching the sources, or elaborate > Fedora-specific configure invocations. The other reasons is to > future-proof the Fedora port against the arrival of an alternative ABI > that is not fully backwards-compatible (the same reason why the official > RISC-V documentation requires use of these paths). -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, comrel, toolchain, base-system, perl, libreoffice) https://wiki.gentoo.org/wiki/User:Dilfridge signature.asc Description: This is a digitally signed message part. -- ___ 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
[Bug 2276541] New: perl-JSON-Path-1.0.5 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2276541 Bug ID: 2276541 Summary: perl-JSON-Path-1.0.5 is available Product: Fedora Version: rawhide Status: NEW Component: perl-JSON-Path Keywords: FutureFeature, Triaged Assignee: emman...@seyman.fr Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: emman...@seyman.fr, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Releases retrieved: 1.0.5 Upstream release that is considered latest: 1.0.5 Current version/release in rawhide: 1.0.4-3.fc40 URL: https://metacpan.org/release/JSON-Path/ Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://docs.fedoraproject.org/en-US/package-maintainers/Upstream_Release_Monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from Anitya: https://release-monitoring.org/project/15651/ To change the monitoring settings for the project, please visit: https://src.fedoraproject.org/rpms/perl-JSON-Path -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2276541 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202276541%23c0 -- ___ 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: [Heads-up] More spring cleaning: orphaning bamf
On 4/22/24 16:32, Fabio Valentini wrote: On Mon, Apr 22, 2024 at 11:12 PM Michel Lind wrote: Dear all, I've been maintaining bamf for... quite some time, and don't actually have a need for it anymore. It's pretty much in maintenance mode upstream as well. I've built the last stable version in Rawhide to close https://bugzilla.redhat.com/show_bug.cgi?id=2055853 but will probably not build for stable releases, I'll let the new maintainer(s) handle that. Right now it looks like only plank actually uses it; its maintainer is cc:ed $ fedrq whatrequires bamf bamf-daemon-0.5.5-8.fc40.x86_64 bamf-devel-0.5.5-8.fc40.i686 bamf-devel-0.5.5-8.fc40.x86_64 plank-libs-0.11.89-15.20210202.git013d051.fc40.i686 plank-libs-0.11.89-15.20210202.git013d051.fc40.x86_64 So if you use plank, or otherwise have a need for this, feel free to take this over. The story with plank is a bit weird ... The last release was in 2019, and elementary OS forked it some years later, because upstream development was pretty much dead. At that point, I was a (co-)maintainer of the plank package, and switched the package to build from the elementary fork, because it had fixes and support for some new stuff. However, elementary has been developing their own dock from scratch (with eyes on eventual Wayland support), and the plank project on launchpad actually looks more active again :| So maybe the package should be switched back to the original upstream when / if the new elementary Dock is ready (it's not yet) ... Nice. The plank in our dist-git is from... uh, 2021. So it's probably overdue for an update. -- _o) Michel Lind _( ) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 OpenPGP_0x8B229D2F7CCC04F2.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital 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
[EPEL-devel] Anyone want to maintain openssl3 for epel8?
I created this (tracking c9s' openssl package) since there were plans to start depending on openssl v3 in systemd back in 2022, but looks like that has not happened yet - and CentOS Hyperscale SIG is no longer updating our systemd package for c8s. The maintenance involved is mainly rebasing changes from c9s, though someone who actually have a need for this would be better able to verify that the builds are actually working. If there's no taker in two weeks, per https://docs.fedoraproject.org/en-US/epel/epel-policy-retirement/ I'll retire the package. Best regards, -- _o) Michel Lind _( ) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 OpenPGP_0x8B229D2F7CCC04F2.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature -- ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: RC 1.14 fails in VirtualBox, has problems in UTM
> On 19 Apr 2024, at 16:57, Adam Williamson wrote: > > On VMWare it plays but is distorted, > don't know why. Maybe a known issue with vmware, I have been told. Something to do with needing to reclock the audio stream. Barry -- ___ 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: [Heads-up] More spring cleaning: orphaning bamf
On Mon, Apr 22, 2024 at 11:12 PM Michel Lind wrote: > > Dear all, > > I've been maintaining bamf for... quite some time, and don't actually have a > need for it anymore. > > It's pretty much in maintenance mode upstream as well. > > I've built the last stable version in Rawhide to close > https://bugzilla.redhat.com/show_bug.cgi?id=2055853 > > but will probably not build for stable releases, I'll let the new > maintainer(s) > handle that. > > Right now it looks like only plank actually uses it; its maintainer is cc:ed > > $ fedrq whatrequires bamf > bamf-daemon-0.5.5-8.fc40.x86_64 > bamf-devel-0.5.5-8.fc40.i686 > bamf-devel-0.5.5-8.fc40.x86_64 > plank-libs-0.11.89-15.20210202.git013d051.fc40.i686 > plank-libs-0.11.89-15.20210202.git013d051.fc40.x86_64 > > So if you use plank, or otherwise have a need for this, feel free to take > this over. The story with plank is a bit weird ... The last release was in 2019, and elementary OS forked it some years later, because upstream development was pretty much dead. At that point, I was a (co-)maintainer of the plank package, and switched the package to build from the elementary fork, because it had fixes and support for some new stuff. However, elementary has been developing their own dock from scratch (with eyes on eventual Wayland support), and the plank project on launchpad actually looks more active again :| So maybe the package should be switched back to the original upstream when / if the new elementary Dock is ready (it's not yet) ... Fabio -- ___ 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: [Heads-up] More spring cleaning: orphaning bamf
On 4/22/24 16:12, Michel Lind wrote: Dear all, I've been maintaining bamf for... quite some time, and don't actually have a need for it anymore. It's pretty much in maintenance mode upstream as well. I've built the last stable version in Rawhide to close https://bugzilla.redhat.com/show_bug.cgi?id=2055853 but will probably not build for stable releases, I'll let the new maintainer(s) handle that. Right now it looks like only plank actually uses it; its maintainer is cc:ed That should have been plank-maintainers, sorry -- _o) Michel Lind _( ) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 OpenPGP_0x8B229D2F7CCC04F2.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital 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
[Heads-up] More spring cleaning: orphaning bamf
Dear all, I've been maintaining bamf for... quite some time, and don't actually have a need for it anymore. It's pretty much in maintenance mode upstream as well. I've built the last stable version in Rawhide to close https://bugzilla.redhat.com/show_bug.cgi?id=2055853 but will probably not build for stable releases, I'll let the new maintainer(s) handle that. Right now it looks like only plank actually uses it; its maintainer is cc:ed $ fedrq whatrequires bamf bamf-daemon-0.5.5-8.fc40.x86_64 bamf-devel-0.5.5-8.fc40.i686 bamf-devel-0.5.5-8.fc40.x86_64 plank-libs-0.11.89-15.20210202.git013d051.fc40.i686 plank-libs-0.11.89-15.20210202.git013d051.fc40.x86_64 So if you use plank, or otherwise have a need for this, feel free to take this over. Best regards, -- _o) Michel Lind _( ) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 OpenPGP_0x8B229D2F7CCC04F2.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital 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: Self Introduction: Łukasz W.
On Mon, Apr 22, 2024 at 10:43 PM Fabio Valentini wrote: > > On Mon, Apr 22, 2024 at 9:16 PM Łukasz Wojniłowicz > wrote: > > > > You're welcome. rust-appdirs got in and I believe is waiting to be > > available in the repositories. > > No, it's waiting for *you* to actually import the package. :) > Just getting the package review ticket approved does nothing on its own. Sorry, I just saw that you imported and built the package for Rawhide. Congratulations for getting your first package into Fedora then! :) Fabio -- ___ 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: Self Introduction: Łukasz W.
On Mon, Apr 22, 2024 at 9:16 PM Łukasz Wojniłowicz wrote: > > You're welcome. rust-appdirs got in and I believe is waiting to be > available in the repositories. No, it's waiting for *you* to actually import the package. :) Just getting the package review ticket approved does nothing on its own. > Meanwhile, I try to get another dependencies in at: > https://bugzilla.redhat.com/show_bug.cgi?id=2276462 > https://bugzilla.redhat.com/show_bug.cgi?id=2276290 I will try to get to those soon, but I can't promise when I will have the time to do so. Fabio -- ___ 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
Simpler first tutorial package for Package Maintainer Docs
Hello everybody, I wrote a pull request for Package Maintainer Docs about adding a simpler tutorial package than GNU Hello [1]. Since it is a larger change and I have not received any reviews yet, I would like to announce this work here, in hope of getting some feedback, before just merging the change. Since I have already described the work in the pull request description, I will just copy it here below. Feel free to respond on the list or in pull request comments. [1]: https://pagure.io/fedora-docs/package-maintainer-docs/pull-request/153 > Add simpler Banner package to packaging tutorial > > Packaging tutorial's approach of packaging GNU Hello has suffered from > certain complexities in GNU Hello package. The package is quite old and > uses some tooling from the GNU project that are not very widely used > any more, such as Texinfo. Also, the package is old and thus suffers > from e.g. having a file that is not UTF-8 encoded. To avoid immediately > exposing tutorial readers to these quirks, make GNU Hello part 2 of the > tutorial and add a simpler package, Banner, as part 1. This way the > reader can reach a complete specfile, compliant with Fedora guidelines, > quicker, and still get a feeling for resolving packaging quirks in the > second part. > > In the future, basing the first tutorial on real packages should > probably be switched to hosting dedicated "test project", which avoid > any quirks and can be packaged to Fedora requirements using only > Fedora's set of RPM macros. Such package should also avoid GNU > Autotools and be based on CMake or Meson, which are simpler to > understand and more widespread today. -- ___ 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
matio soname bump
matio 1.5.27 is coming to rawhide. I'm building it in side tag 41-build-side-88211. I'll rebuild kst, LapPlt, openmeed, and vips there, and then merge. -- Gwyn Ciesla she/her/hers in your fear, seek only peace in your fear, seek only love -d. bowie Sent with Proton Mail secure email. signature.asc Description: OpenPGP digital 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: Self Introduction: Łukasz W.
Hi Dominik, On Mon, 22 Apr 2024 19:31:50 +0200 Dominik 'Rathann' Mierzejewski wrote: > Hello, Łukasz. > > On Sunday, 21 April 2024 at 20:37, Łukasz Wojniłowicz wrote: > > Hi all, > > > > @decathorpe reviewed my first package positively at > > https://bugzilla.redhat.com/show_bug.cgi?id=2271100 > > and now I'm looking for somebody to sponsor me. My official request > > for sponsorship is at > > https://pagure.io/packager-sponsors/issue/640. > > I've sponsored you. Thanks again :) > > I would like to package aw-server-rust and eventually other > > components from ActivityWatch. Fedora is missing several dozens of > > dependencies for aw-server-rust and I would like to follow up on > > them as well. > > Great! Thanks for your contribution. You're welcome. rust-appdirs got in and I believe is waiting to be available in the repositories. Meanwhile, I try to get another dependencies in at: https://bugzilla.redhat.com/show_bug.cgi?id=2276462 https://bugzilla.redhat.com/show_bug.cgi?id=2276290 > > If that's of any use, I already maintain nvidia-340xx-kmod at > > RPMFusion and provide ungoogled-chromium at my own COPR. > > That is certainly useful for users of older nVidia GPUs. Thanks! Me included :) > > I look forward to hearing from you soon. > > Welcome to Fedora! Thank you for welcoming me and for your fast response. Regards, Łukasz -- ___ 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: Self Introduction: Łukasz W.
On Sun, Apr 21, 2024 at 08:37:12PM +0200, Łukasz Wojniłowicz wrote: > Hi all, > > @decathorpe reviewed my first package positively at > https://bugzilla.redhat.com/show_bug.cgi?id=2271100 > and now I'm looking for somebody to sponsor me. My official request for > sponsorship is at https://pagure.io/packager-sponsors/issue/640. > > I would like to package aw-server-rust and eventually other components > from ActivityWatch. Fedora is missing several dozens of dependencies > for aw-server-rust and I would like to follow up on them as well. > > If that's of any use, I already maintain nvidia-340xx-kmod at RPMFusion > and provide ungoogled-chromium at my own COPR. > > I look forward to hearing from you soon. Welcome to Fedora. Zbyszek -- ___ 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: [HEADS-UP] openexr so name bump heading Rawhide and f40
I tried to so synfig and gstreamer1-plugins-bad-free, and they need some of the others rebuilt first: https://kojipkgs.fedoraproject.org//work/tasks/2955/116742955/root.log https://kojipkgs.fedoraproject.org//work/tasks/3027/116743027/root.log -- Gwyn Ciesla she/her/hers in your fear, seek only peace in your fear, seek only love -d. bowie Sent with Proton Mail secure email. On Monday, April 22nd, 2024 at 7:14 AM, Josef Řídký wrote: > Hi folks, > > this is in advance notice about the upcoming rebase of the openexr package in > Fedora Rawhide and f40. > > List of dependent package should be following (please, correct me if I > haven't found all): > CTL > ImageMagick > OpenColorIO > OpenEXR_Viewers > OpenImageIO > OpenSceneGraph-OpenEXR > blender > cinelerra-gg > darktable > freeimage > gdal > gegl04 > gimp > gmic > gstreamer1-plugins-bad-free > hugin > kf5-kimageformats > kio-extras > krita > libjxl > olive > opencv > pfstools > povray > synfig > synfigstudio > vigra > vips > > I would like to ask responsible maintainers (or kind proven packager) to > rebuild their packages for Rawhide and f40 with following side-tags: > > F40 -> f40-build-side-88171 > Rawhide -> f41-build-side-88169 > > > Best regards > > Josef Ridky > Senior Software Engineer > Core Services Team > Red Hat Czech, s.r.o. signature.asc Description: OpenPGP digital 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: Self Introduction: Łukasz W.
Hello, Łukasz. On Sunday, 21 April 2024 at 20:37, Łukasz Wojniłowicz wrote: > Hi all, > > @decathorpe reviewed my first package positively at > https://bugzilla.redhat.com/show_bug.cgi?id=2271100 > and now I'm looking for somebody to sponsor me. My official request for > sponsorship is at https://pagure.io/packager-sponsors/issue/640. I've sponsored you. > I would like to package aw-server-rust and eventually other components > from ActivityWatch. Fedora is missing several dozens of dependencies > for aw-server-rust and I would like to follow up on them as well. Great! Thanks for your contribution. > If that's of any use, I already maintain nvidia-340xx-kmod at RPMFusion > and provide ungoogled-chromium at my own COPR. That is certainly useful for users of older nVidia GPUs. Thanks! > I look forward to hearing from you soon. Welcome to Fedora! Regards, Dominik -- Fedora https://fedoraproject.org Deep in the human unconscious is a pervasive need for a logical universe that makes sense. But the real universe is always one step beyond logic. -- from "The Sayings of Muad'Dib" by the Princess Irulan -- ___ 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
Heads up: orphaned bti (bash twitter id*ocy)
Dear all, I just orphaned https://src.fedoraproject.org/rpms/bti - a command-line Twitter client. I no longer use Twitter anymore, this package has basically not needed any attention (it rebuilds fine) but I'm not sure if it works anymore post-takeover. It does have an open issue asking for a port to pcre2, but upstream has not committed anything in 7 years. There is a PR from 2021 that addressed the pcre2 issue, if anyone wants to pick this up: https://github.com/gregkh/bti/pull/54 Best regards, -- _o) Michel Lind _( ) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 OpenPGP_0x8B229D2F7CCC04F2.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital 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: [HEADS-UP] openexr so name bump heading Rawhide and f40
Well good news, the F40 rebuild is not needed. It looks like there was an issue with proper bug report reference. Sorry for the disturbance about that in F40. But the Rawhide rebuild is still in place so please use f41-build-side-88169 for rebuild of dependent packages. Best regards Josef Ridky Senior Software Engineer Core Services Team Red Hat Czech, s.r.o. On Mon, Apr 22, 2024 at 6:11 PM Josef Řídký wrote: > Hi Ben, > > thanks for the notice. I'll fill the FESCO ticket right away and wait for > their decision. So let's call F40 only (not Rawhide) side tags builds on > hold till the decision is made. > > Best regards > > Josef Ridky > Senior Software Engineer > Core Services Team > Red Hat Czech, s.r.o. > > > On Mon, Apr 22, 2024 at 5:04 PM Ben Beasley > wrote: > >> Is there a specific reason that an ABI-breaking update in required in the >> stable F40 release? And would you consider asking FESCo for approval as >> required by the Updates Policy? >> >> https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#stable-releases >> >> Note that if this update happens in F40 now, it will have very messy >> interactions with other updates in other side tags, e.g. >> https://bodhi.fedoraproject.org/updates/FEDORA-2024-45862e3ed9 for >> blender. Even if this update is truly required in F40, I would advocate for >> delaying it by at least one week. >> >> Thanks, >> >> Ben Beasley (FAS music) >> On 4/22/24 8:14 AM, Josef Řídký wrote: >> >> Hi folks, >> >> this is in advance notice about the upcoming rebase of the openexr >> package in Fedora Rawhide and f40. >> >> List of dependent package should be following (please, correct me if I >> haven't found all): >> CTL >> ImageMagick >> OpenColorIO >> OpenEXR_Viewers >> OpenImageIO >> OpenSceneGraph-OpenEXR >> blender >> cinelerra-gg >> darktable >> freeimage >> gdal >> gegl04 >> gimp >> gmic >> gstreamer1-plugins-bad-free >> hugin >> kf5-kimageformats >> kio-extras >> krita >> libjxl >> olive >> opencv >> pfstools >> povray >> synfig >> synfigstudio >> vigra >> vips >> >> I would like to ask responsible maintainers (or kind proven packager) to >> rebuild their packages for Rawhide and f40 with following side-tags: >> >> F40 -> f40-build-side-88171 >> Rawhide -> f41-build-side-88169 >> >> Best regards >> >> Josef Ridky >> Senior Software Engineer >> Core Services Team >> Red Hat Czech, s.r.o. >> >> -- >> ___ >> 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 >> > -- ___ 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: [HEADS-UP] openexr so name bump heading Rawhide and f40
Hi Ben, thanks for the notice. I'll fill the FESCO ticket right away and wait for their decision. So let's call F40 only (not Rawhide) side tags builds on hold till the decision is made. Best regards Josef Ridky Senior Software Engineer Core Services Team Red Hat Czech, s.r.o. On Mon, Apr 22, 2024 at 5:04 PM Ben Beasley wrote: > Is there a specific reason that an ABI-breaking update in required in the > stable F40 release? And would you consider asking FESCo for approval as > required by the Updates Policy? > > https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#stable-releases > > Note that if this update happens in F40 now, it will have very messy > interactions with other updates in other side tags, e.g. > https://bodhi.fedoraproject.org/updates/FEDORA-2024-45862e3ed9 for > blender. Even if this update is truly required in F40, I would advocate for > delaying it by at least one week. > > Thanks, > > Ben Beasley (FAS music) > On 4/22/24 8:14 AM, Josef Řídký wrote: > > Hi folks, > > this is in advance notice about the upcoming rebase of the openexr package > in Fedora Rawhide and f40. > > List of dependent package should be following (please, correct me if I > haven't found all): > CTL > ImageMagick > OpenColorIO > OpenEXR_Viewers > OpenImageIO > OpenSceneGraph-OpenEXR > blender > cinelerra-gg > darktable > freeimage > gdal > gegl04 > gimp > gmic > gstreamer1-plugins-bad-free > hugin > kf5-kimageformats > kio-extras > krita > libjxl > olive > opencv > pfstools > povray > synfig > synfigstudio > vigra > vips > > I would like to ask responsible maintainers (or kind proven packager) to > rebuild their packages for Rawhide and f40 with following side-tags: > > F40 -> f40-build-side-88171 > Rawhide -> f41-build-side-88169 > > Best regards > > Josef Ridky > Senior Software Engineer > Core Services Team > Red Hat Czech, s.r.o. > > -- > ___ > 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 > -- ___ 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: Rust Stack Spring Cleaning - 2024 Edition
On Mon, Apr 22, 2024 at 5:13 PM Peter Robinson wrote: > > I am aware of a few of the above I'm listed against that my deps no > longer requre (eg passwd) but I hadn't got around to working out what > else depended on them to retire without possibly breaking something > else, overall happy for them to be retired as part of the mass > retirement if there's no other deps. Whoops, sorry about that - I constructed the "packages per maintainer" list manually, apparently I was too tired to check that everybody included in the table is also included in the per-maintainer lists :( > There's also some that are deps on things still in progress like > rust-rustls-pki-types (rhbz 2272351 has dep details), not sure how to > tag those so I don't have to do more work to repackage them. Thanks for checking! FYI, rustls-pki-types is no longer a leaf package since I updated rustls / reqwest to newer versions. Fabio -- ___ 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: Rust Stack Spring Cleaning - 2024 Edition
On Thu, 11 Apr 2024 at 14:26, Fabio Valentini wrote: > > Hello Rust packagers, > > I'm continuously working on reducing unnecessary accumulation of cruft > in the Rust package stack in Fedora, and I have been keeping track of > unused library packages for almost three years now. > > Some of these packages have been unused leaves for over two years! > > I will again start being more proactive with orphaning / retiring > affected packages where I am the primary maintainer, starting > incrementally from the packages which have been unused for the longest > time - unless I know of a reason to keep a specific package, for > example: > > - something that depends on the package is still going through package review > - the package was updated to a "breaking" release and a compat package > was created, and now the "main" package is not depended on while the > compat package is in use > > If you know of a reason why a leaf package where I am the primary > maintainer should not be retired, please let me know, and I will > exclude it from the list. > > For packages where I am *not* the primary maintainer, I need help: > > - Is this package still required for something that I don't know > about, or can it be dropped? > - Was it added as a dependency for something else, but packaging this > "something else" was abandoned? > - Was it needed at the time, but is the library no longer needed now? > > Keeping unused packages around only makes maintenance of the Rust > stack more difficult due to the more "dense" dependency graph that > needs to be considered when pushing "breaking" changes. Over the past > year or so, the number of Rust packages in Fedora has grown by almost > 50% from about 2200 to over 3000, which is making this issue worse. > > Full report included below (view in monospace font for correct formatting). > > Thank you for your help, > Fabio > > +--++---+--+ > | Package | Leaf since | Leaf days | Maintainer > | > +--++---+--+ > | rust-curve25519-dalek| 2021-11-18 | 875 | dcavalca > | > | rust-gstreamer-editing-services | 2021-11-18 | 875 | atim > | > | rust-gstreamer-player| 2021-11-18 | 875 | atim > | > | rust-rand_jitter | 2021-11-18 | 875 | jistone > | > | rust-rand_os | 2021-11-18 | 875 | jistone > | > | rust-tower-test | 2021-11-18 | 875 | decathorpe > | > | rust-tower-util | 2021-11-18 | 875 | decathorpe > | > | rust-partial-io | 2022-02-06 | 795 | decathorpe > | > | rust-minimad | 2022-02-18 | 783 | dcavalca > | > | rust-libhandy| 2022-02-20 | 781 | decathorpe > | > | rust-tiger | 2022-02-20 | 781 | decathorpe > | > | rust-rand_hc | 2022-02-21 | 780 | jistone > | > | rust-benfred-read-process-memory | 2022-02-27 | 774 | dcavalca > | > | rust-custom_error| 2022-02-27 | 774 | dcavalca > | > | rust-madvr_parse | 2022-02-27 | 774 | dcavalca > | > | rust-os-release | 2022-02-27 | 774 | dcavalca > | > | rust-strict | 2022-02-27 | 774 | dcavalca > | > | rust-subprocess | 2022-02-27 | 774 | dcavalca > | > | rust-libxml | 2022-04-07 | 735 | decathorpe > | > | rust-snake_case | 2022-04-25 | 717 | decathorpe > | > | rust-openat-ext | 2022-04-28 | 714 | walters > | > | rust-log-mdc | 2022-05-05 | 707 | decathorpe > | > | rust-cargo-manifest | 2022-05-06 | 706 | laiot > | > | rust-digest_auth | 2022-05-06 | 706 | laiot > | > | rust-binascii| 2022-05-10 | 702 | saluki > | > | rust-inlinable_string| 2022-05-10 | 702 | decathorpe > | > | rust-ubyte | 2022-05-10 | 702 | decathorpe > | > | rust-email-encoding | 2022-05-17 | 695 | saluki > | > | rust-tabular | 2022-05-23 | 689 | jbtrystram > | > | rust-async-mutex | 2022-06-01 | 680 | decathorpe > | > | rust-awc | 2022-06-01 | 680 | decathorpe > | > | rust-infer | 2022-06-15 | 666 | decathorpe > | > | rust-escape_string | 2022-07-08 | 643 | dcavalca > | > | rust-actix
Re: [HEADS-UP] openexr so name bump heading Rawhide and f40
Is there a specific reason that an ABI-breaking update in required in the stable F40 release? And would you consider asking FESCo for approval as required by the Updates Policy? https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#stable-releases Note that if this update happens in F40 now, it will have very messy interactions with other updates in other side tags, e.g. https://bodhi.fedoraproject.org/updates/FEDORA-2024-45862e3ed9 for blender. Even if this update is truly required in F40, I would advocate for delaying it by at least one week. Thanks, Ben Beasley (FAS music) On 4/22/24 8:14 AM, Josef Řídký wrote: Hi folks, this is in advance notice about the upcoming rebase of the openexr package in Fedora Rawhide and f40. List of dependent package should be following (please, correct me if I haven't found all): CTL ImageMagick OpenColorIO OpenEXR_Viewers OpenImageIO OpenSceneGraph-OpenEXR blender cinelerra-gg darktable freeimage gdal gegl04 gimp gmic gstreamer1-plugins-bad-free hugin kf5-kimageformats kio-extras krita libjxl olive opencv pfstools povray synfig synfigstudio vigra vips I would like to ask responsible maintainers (or kind proven packager) to rebuild their packages for Rawhide and f40 with following side-tags: F40 -> f40-build-side-88171 Rawhide -> f41-build-side-88169 Best regards Josef Ridky Senior Software Engineer Core Services Team Red Hat Czech, s.r.o. -- ___ devel mailing list --devel@lists.fedoraproject.org To unsubscribe send an email todevel-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
libarrow (Apache Arrow) SONAME bump in rawhide
Coming soon. Updating to Arrow 16.0.0 -- Kaleb -- ___ 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: 20240422.n.0 changes
OLD: Fedora-Rawhide-20240421.n.0 NEW: Fedora-Rawhide-20240422.n.0 = SUMMARY = Added images:2 Dropped images: 1 Added packages: 1 Dropped packages:2 Upgraded packages: 57 Downgraded packages: 0 Size of added packages: 31.15 MiB Size of dropped packages:358.13 KiB Size of upgraded packages: 1.01 GiB Size of downgraded packages: 0 B Size change of upgraded packages: 33.84 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: Server_KVM qcow2 ppc64le Path: Server/ppc64le/images/Fedora-Server-KVM-Rawhide-20240422.n.0.ppc64le.qcow2 Image: Sericea ociarchive aarch64 Path: Sericea/aarch64/images/Fedora-Sericea-Rawhide.20240422.n.0.ociarchive = DROPPED IMAGES = Image: LXQt live aarch64 Path: Spins/aarch64/iso/Fedora-LXQt-Live-aarch64-Rawhide-20240421.n.0.iso = ADDED PACKAGES = Package: dnf-repo-0.5.6-1.fc41 Summary: DNF wrapper tool to control repos RPMs:dnf-repo Size:31.15 MiB = DROPPED PACKAGES = Package: golang-github-alecthomas-template-0-0.16.20200126gitfb15b89.fc38 Summary: Fork of go's text/template adding newline elision RPMs:golang-github-alecthomas-template-devel Size:63.67 KiB Package: mkosi14-14-4.fc40 Summary: Create bespoke OS images RPMs:mkosi14 Size:294.46 KiB = UPGRADED PACKAGES = Package: DevIL-1.7.8-47.fc41 Old package: DevIL-1.7.8-43.fc40 Summary: A cross-platform image library RPMs: DevIL DevIL-ILUT DevIL-ILUT-devel DevIL-devel Size: 1.77 MiB Size change: 7.03 KiB Changelog: * Thu Jan 18 2024 Fedora Release Engineering - 1.7.8-44 - Rebuilt for https://fedoraproject.org/wiki/Fedora_40_Mass_Rebuild * Fri Jan 19 2024 Fedora Release Engineering - 1.7.8-45 - Rebuilt for https://fedoraproject.org/wiki/Fedora_40_Mass_Rebuild * Mon Jan 22 2024 Fedora Release Engineering - 1.7.8-46 - Rebuilt for https://fedoraproject.org/wiki/Fedora_40_Mass_Rebuild * Sun Apr 21 2024 Hans de Goede - 1.7.8-47 - Fix FTBFS - Resolves: rhbz#2260957 Package: OpenImageIO-2.5.7.0-3.fc41 Old package: OpenImageIO-2.5.7.0-2.fc41 Summary: Library for reading and writing images RPMs: OpenImageIO OpenImageIO-devel OpenImageIO-iv OpenImageIO-utils python3-openimageio Size: 18.11 MiB Size change: 14.37 KiB Changelog: * Sun Apr 21 2024 Benjamin A. Beasley - 2.5.7.0-3 - Rebuild for OpenVDB 11 without backward-compatible ABI Package: PyGreSQL-6.0.1-1.fc41 Old package: PyGreSQL-6.0-1.fc40 Summary: Python client library for PostgreSQL RPMs: python3-pygresql Size: 691.81 KiB Size change: 368 B Changelog: * Sun Apr 21 2024 Ondrej Sloup - 6.0.1-1 - Rebase to the latest upstream version (rhbz#2276157) Package: blender-1:4.1.1-3.fc41 Old package: blender-1:4.1.1-1.fc41 Summary: 3D modeling, animation, rendering and post-production RPMs: blender blender-rpm-macros Size: 242.73 MiB Size change: 146.71 KiB Changelog: * Sun Apr 21 2024 Benjamin A. Beasley - 1:4.1.1-2 - More carefully account for Python dependencies - Add missing runtime/install-time dependencies - Add weak dependencies used by included add-ons * Sun Apr 21 2024 Benjamin A. Beasley - 1:4.1.1-3 - Fix blank blender.1 man page Package: blosc2-2.14.4-1.fc41 Old package: blosc2-2.14.0-1.fc41 Summary: High performance compressor optimized for binary data RPMs: blosc2 blosc2-devel Size: 1.28 MiB Size change: 3.88 KiB Changelog: * Sun Apr 21 2024 Packit - 2.14.4-1 - Update to 2.14.4 upstream release - Resolves: rhbz#2273551 - SO version is changed to '3' Package: bottles-1:51.11-6.fc41 Old package: bottles-1:51.11-3.fc41 Summary: Run Windows in a Bottle RPMs: bottles Size: 630.92 KiB Size change: -106 B Changelog: * Sun Apr 21 2024 Sandro - 1:51.11-4 - Generate Python requirements - Fix RHBZ#2276256 Package: cinnamon-6.0.4-6.fc41 Old package: cinnamon-6.0.4-5.fc41 Summary: Window management and application launching for GNOME RPMs: cinnamon cinnamon-calendar-server Size: 9.24 MiB Size change: -31.02 KiB Changelog: * Sun Apr 21 2024 Leigh Scott - 6.0.4-6 - Add patch to remove old goa desktop file Package: fping-5.2-1.fc41 Old package: fping-5.1^20221021git8dc0b7f-1.fc40 Summary: Scriptable, parallelized ping-like utility RPMs: fping Size: 161.60 KiB Size change: 8.94 KiB Changelog: * Fri Nov 10 2023 Charles R. Anderson - 5.1^20231102gita3f4c57-1 - update to latest git snapshot to see if it fixes fping -n with systemd-resolved * Fri Jan 19 2024 Fedora Release Engineering - 5.1^20231102gita3f4c57-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_40_Mass_Rebuild * Wed Jan 24 2024 Fedora Release Engineering - 5.1^20231102gita3f4c57-3 - Rebuilt for https://fedoraproject.org/wiki/Fedora_40_Mass_Rebuild * Mon Jan 29 2024 Fedora
No FESCo Meeting this Monday (2024-04-22)
There is nothing on the agenda, so the meeting is cancelled. I'll chair the next meeting. = Discussed and Voted in the Ticket = #3197 Request for Updates Policy Exception: ruff https://pagure.io/fesco/issue/3197 APPROVED (+4, 0, 0) #3195 Change: Pytest 8 https://pagure.io/fesco/issue/3195 APPROVED (+4, 0, 0) #3194 Change: Versioned Kubernetes Packages https://pagure.io/fesco/issue/3194 APPROVED (+3, 0, 0) #3193 Change: Openssl Deprecate Engine https://pagure.io/fesco/issue/3193 APPROVED (+3, 0, 0) #3190 Change: Enable Consistent Device Naming in Cloud Images https://pagure.io/fesco/issue/3190 APPROVED (+4, 0, 0) #3189 Change: Change Compose Settings https://pagure.io/fesco/issue/3189 APPROVED (+8, 0, 0) #3188 Change: RPM 4.20 https://pagure.io/fesco/issue/3188 APPROVED (+7, 0, 0) -- ___ 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
[HEADS-UP] openexr so name bump heading Rawhide and f40
Hi folks, this is in advance notice about the upcoming rebase of the openexr package in Fedora Rawhide and f40. List of dependent package should be following (please, correct me if I haven't found all): CTL ImageMagick OpenColorIO OpenEXR_Viewers OpenImageIO OpenSceneGraph-OpenEXR blender cinelerra-gg darktable freeimage gdal gegl04 gimp gmic gstreamer1-plugins-bad-free hugin kf5-kimageformats kio-extras krita libjxl olive opencv pfstools povray synfig synfigstudio vigra vips I would like to ask responsible maintainers (or kind proven packager) to rebuild their packages for Rawhide and f40 with following side-tags: F40 -> f40-build-side-88171 Rawhide -> f41-build-side-88169 Best regards Josef Ridky Senior Software Engineer Core Services Team Red Hat Czech, s.r.o. -- ___ 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: Fedora RISC-V port needs to put shared objects into /usr/lib64/lp64d
On Mon, Apr 22, 2024 at 12:07:38PM +0200, Florian Weimer wrote: > * Daniel P. Berrangé: > > > On Fri, Apr 19, 2024 at 02:21:57PM +0200, Florian Weimer wrote: > >> There are multiple PRs and patches floating around that make RISC-V use > >> the /usr/lib64 directory, like other 64-bit ports. However, RISC-V > >> recommends to use /usr/lib64/lp64d for the Fedora ABI variant, and > >> various upstream projects follow that. > >> > >> I think we should follow upstream, so that it's possible to use Fedora > >> to do upstream development without patching the sources, or elaborate > >> Fedora-specific configure invocations. > > > > I'm not convinced that using /usr/lib64/lp64d would lead to > > *less* patching. > > > > Apps targetting Fedora are long used to having to adapt from > > using /usr/lib to /usr/lib64. > > But that's largely baked into the upstream defaults by now (unlike the > Debian multi-arch paths). > > > Introducing the use of /usr/lib64/lp64d instead, just for RiscV, feels > > likely to break expectations resulting in apps which build fine on all > > Fedora arches except for RiscV > > I don't want us to have RPM spec file hacks just to get RISC-V to > install in the correct locations. The symbolic link evidently does not > cover all cases. What cases aren't covered by the symlink? We have a full, working Fedora/RISC-V distro using it at the moment. Rich. > Whatever we do, it should be upstream. Maybe convince RISC-V to adopt > /usr/lib64. Or have the RISC-V folks implement automated detection of > path layout in autotools, Meson etc., so that out of the box, both paths > work. > > Thanks, > Florian > -- > ___ > 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 -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top -- ___ 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: Fedora RISC-V port needs to put shared objects into /usr/lib64/lp64d
* David Abdurachmanov: > We most likely will not have ABIs installed in parallel, but we might > change ABI. Currently Linux distributions target "RV64GC", but we > don't really want that for the future RISC-V. I keep telling folks > that "RV64GC" is already "a legacy" (10+ years old), but that's the > major target for the next few years. We are scheduled to see some > RVA22 SBCs this year. > > RV64GC -> RVA20 -> RVA22 -> RVA23 -> RVA24. > > That's how things evolved. RVA23 most likely will be ratified soonish. > RVA24 is most likely the next major RISC-V Profile from RVI point of > view (TBD). Server specifications are based on RVA23 (and will be > updated to RVA24 [most likely]). This defines baseline ISA, optional > extensions, etc. Is there really an ABI change, though? That would only happen if the set of callee-saved registers grows, to include vector registers. Adding new registers has compatibility problems on its own. Fedora might want to switch to an ISA baseline that is incompatible with all currently available CPUs, but that's not necessarily an ABI break as such. Thanks, Florian -- ___ 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: Fedora RISC-V port needs to put shared objects into /usr/lib64/lp64d
* Andrea Bolognani: > On Fri, Apr 19, 2024 at 02:21:57PM +0200, Florian Weimer wrote: >> There are multiple PRs and patches floating around that make RISC-V use >> the /usr/lib64 directory, like other 64-bit ports. However, RISC-V >> recommends to use /usr/lib64/lp64d for the Fedora ABI variant, and >> various upstream projects follow that. >> >> I think we should follow upstream, so that it's possible to use Fedora >> to do upstream development without patching the sources, or elaborate >> Fedora-specific configure invocations. The other reasons is to >> future-proof the Fedora port against the arrival of an alternative ABI >> that is not fully backwards-compatible (the same reason why the official >> RISC-V documentation requires use of these paths). > > I just checked in a Debian riscv64 chroot and they don't seem to > follow this recommendation: > > # cat /etc/ld.so.conf.d/riscv64-linux-gnu.conf > /usr/local/lib/riscv64-linux-gnu > /lib/riscv64-linux-gnu > /usr/lib/riscv64-linux-gnu > > This matches what Debian does on all architectures, that is, install > libraries under fully arch-qualified paths. If Debian doesn't stray > from its usual practices for RISC-V, I'm not convinced that Fedora > needs to either. Debian is really not a good example here because they have not upstreamed their path layout. I really don't think it's a good idea to clutter dozens of spec files with changes for what's arguably just a toy architecture today, with plenty of CPU-incompatible changes still coming. Thanks, Florian -- ___ 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: Fedora RISC-V port needs to put shared objects into /usr/lib64/lp64d
* Daniel P. Berrangé: > On Fri, Apr 19, 2024 at 02:21:57PM +0200, Florian Weimer wrote: >> There are multiple PRs and patches floating around that make RISC-V use >> the /usr/lib64 directory, like other 64-bit ports. However, RISC-V >> recommends to use /usr/lib64/lp64d for the Fedora ABI variant, and >> various upstream projects follow that. >> >> I think we should follow upstream, so that it's possible to use Fedora >> to do upstream development without patching the sources, or elaborate >> Fedora-specific configure invocations. > > I'm not convinced that using /usr/lib64/lp64d would lead to > *less* patching. > > Apps targetting Fedora are long used to having to adapt from > using /usr/lib to /usr/lib64. But that's largely baked into the upstream defaults by now (unlike the Debian multi-arch paths). > Introducing the use of /usr/lib64/lp64d instead, just for RiscV, feels > likely to break expectations resulting in apps which build fine on all > Fedora arches except for RiscV I don't want us to have RPM spec file hacks just to get RISC-V to install in the correct locations. The symbolic link evidently does not cover all cases. Whatever we do, it should be upstream. Maybe convince RISC-V to adopt /usr/lib64. Or have the RISC-V folks implement automated detection of path layout in autotools, Meson etc., so that out of the box, both paths work. Thanks, Florian -- ___ 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
Next Open NeuroFedora Meeting: Monday, 22 April 2024 (today) at 13:00 UTC
Hello everyone, Please join us at the next Open NeuroFedora team meeting on Monday, 22 April at 13:00 UTC. The meeting is a public meeting, and open for everyone to attend. You can join us over on Matrix in the Fedora Meeting channel: https://matrix.to/#/#meeting:fedoraproject.org You can use this link to see the local time for the meeting: https://www.timeanddate.com/worldclock/fixedtime.html?msg=Open+NeuroFedora+Meeting=20240422T13=1440=1 or you can use this command in a terminal: $ date -d 'Monday, April 22, 2024 13:00 UTC' The meeting will be chaired by @ankursinha. The agenda for the meeting is: - New introductions and roll call. - Tasks from last meeting: https://meetbot.fedoraproject.org/latest/neurofedora - Open Pagure tickets: https://pagure.io/neuro-sig/NeuroFedora/issues?status=Open=S%3A+Next+meeting - Package health check: https://packager-dashboard.fedoraproject.org/dashboard?groups=neuro-sig - Open package reviews check: https://bugzilla.redhat.com/show_bug.cgi?id=fedora-neuro - CompNeuro lab compose status check for F40: https://koji.fedoraproject.org/koji/packageinfo?packageID=30691 - Neuroscience query of the week - Next meeting day, and chair. - Open floor. We hope to see you there! The meeting announcement is also posted on the NeuroFedora blog here: https://neuroblog.fedoraproject.org/2024/04/22/next-open-neurofedora-meeting-22-april-1300-utc.html You can learn more about NeuroFedora here: https://neuro.fedoraproject.org Cheers, -- Thanks, Regards, Ankur Sinha "FranciscoD" (He / Him / His) | https://fedoraproject.org/wiki/User:Ankursinha Time zone: Europe/London 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: Orphaning my packages: elvish, git-delta & dependencies
Thanks, I opened a re-review request of elvish to follow package renaming process [1]. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2276356 [1] https://docs.fedoraproject.org/en-US/package-maintainers/Package_Renaming_Process/ -- ___ 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: Orphaning my packages: elvish, git-delta & dependencies
Hau idatzi du Felix Wang (topa...@outlook.com) erabiltzaileak (2024 api. 22(a), al. (03:57)): > > I'd like to take elvish package, Current package golang-github-elves-elvish should be replaced by a new one[1], set correct Obsoletes tag and retired. The name and goipath are not correct anymore.a > and I filed a review request of golang-pkg-nimblebun-lsp, which it is a > dependency of elvish. > I would be grateful If you can take the review, or I can do the review swap > if am familiar the knowledge with it. > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2276326 Approved. [1] https://download.copr.fedorainfracloud.org/results/mikelo2/elvish/fedora-rawhide-x86_64/07333485-elvish/elvish.spec plus the Obsoletes should be OK for the review. -- ___ 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
