Re: Potential kTLS issue with TLS-PSK, GnuTLS + Rawhide - how to debug it?
Hello Simon, Thanks for looking into it! Simon Farnsworth writes: > On Friday, 25 November 2022 13:57:26 GMT Richard W.M. Jones wrote: >> Turns out this is fixed in upstream gnutls (not the version in >> Rawhide). The commit which fixes it is: >> >> commit 67843b3a8e28e4c74296caea2d1019065c87afb3 >> Author: Frantisek Krenzelok >> Date: Mon Sep 5 13:05:17 2022 +0200 >> >> KTLS: fallback to default >> >> If an error occurs during setting of keys either initial or key update >> then fallback to default mode of operation (disable ktls) and let the >> user know >> >> Signed-off-by: Frantisek Krenzelok >> >> lib/handshake.c| 7 ++- >> lib/tls13/key_update.c | 23 +++ >> 2 files changed, 25 insertions(+), 5 deletions(-) >> >> With full debugging you can see the message caused by this commit: >> >> nbdkit: null[1]: debug: gnutls: 4: HSK[0x7fc9e00010a0]: TLS 1.3 set read key >> with cipher suite: GNUTLS_CHACHA20_POLY1305_SHA256 > nbdkit: null[1]: debug: >> gnutls: 13: BUF[HSK]: Emptied buffer >> nbdkit: null[1]: debug: gnutls: 13: BUF[HSK]: Emptied buffer >> nbdkit: null[1]: debug: gnutls: 5: REC[0x7fc9e00010a0]: Start of epoch >> cleanup > nbdkit: null[1]: debug: gnutls: 5: REC[0x7fc9e00010a0]: Epoch #0 >> freed nbdkit: null[1]: debug: gnutls: 5: REC[0x7fc9e00010a0]: Epoch #1 >> freed nbdkit: null[1]: debug: gnutls: 5: REC[0x7fc9e00010a0]: End of epoch >> cleanup nbdkit: null[1]: debug: gnutls: 1: disabling KTLS: failed to set >> keys >> Is this because kTLS doesn't support PSK? >> > kTLS doesn't do key management, so it doesn't know the difference between PSK > and X.509 (it gets the symmetric keys from userspace after the key exchange > is > done). > > However, looking at https://gitlab.com/gnutls/gnutls/-/blob/master/lib/system/ > ktls.c, GnuTLS only supports using kTLS with GNUTLS_CIPHER_AES_128_GCM and > GNUTLS_CIPHER_AES_256_GCM cipher suites, while your debugging output shows > that this connection is using GNUTLS_CHACHA20_POLY1305_SHA256. Yes, that is the case. With gnutls-cli: $ gnutls-cli -d1 -p 5556 localhost --pskusername psk_identity --pskkey "..." --priority NORMAL:-KX-ALL:+ECDHE-PSK |<1>| disabling KTLS: failed to set keys If you disable CHACHA20-POLY1305, it works without that message: $ gnutls-cli -d1 -p 5556 localhost --pskusername psk_identity --pskkey "..." --priority NORMAL:-CHACHA20-POLY1305:-KX-ALL:+ECDHE-PSK I've filed an issue so those ciphersuites are eventually supported: https://gitlab.com/gnutls/gnutls/-/issues/1434 Regards, -- Daiki Ueno ___ 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: Should the policy documents better reflect real package maintenance practice?
I'd like to suggest specific updates (I'd feel more like I was contributing to a productive conversation and less like I'm merely complaining), but I'm a little unclear FESCo's point of view. I'll do my best. Given the discussion so far, I feel like Fedora effectively allows at least leaf nodes to update without significant oversight, and I wonder if it would be useful to reflect that distinction more fully in the philosophy statement. I am unclear on the general sentiment toward updates of packages that are not leaf nodes, and I tend to think that it's valuable to maintain minor-version stability (feature stability) on those packages even if leaf nodes are expected to maintain only major-version stability (compatible-interface stability). If that's an acceptable point of view, perhaps replace the fourth sentence of the first paragraph with: Updates to shared dependencies should aim to only fix bugs, and not introduce features. Updates to "leaf" nodes may introduce new features, but only when those features would not be disruptive to the user or developer experience. It might also be helpful to express a preference for either stability or updates when the upstream vendor is actively supporting two stable releases of a leaf node. In the third paragraph, the phrase "ABI changes in general are very strongly discouraged" could be prefixed with "Any" or "Incompatible" in order to further clarify whether Fedora releases are supposed to maintain Major-version or Minor-version stability in dependency packages. The Exceptions section says "If your package does not fit in one of the classes below..." is confusing, but probably only because the exceptions list is disorganized. It starts with specific packages that have exceptions (the kernel, KDE, and other packages), and then "Security fixes" -- which looks like a class of packages with an exception, except that it requires a FESCo ticket as packages without an exception do (and then lists the kernel, again), and finishes with two classes of packages with an exception to the policy. Here, I'd suggest some minor reorganization: classes of packages that have exceptions generally, and then specific packages with exceptions. Security fixes seems like it belongs at the end, possibly noting that security fixes do not have an exception from the stable release policy, but approval of rebase updates is fast-tracked. Or, if they do have an exception because of the nature of the update, then generally reword all of this. Possibly to note that a ticket is required in order to organize rebuilding any related packages that require it, if packagers are not required to wait for FESCo approval. (And, remove the duplicate reference to the policy exception for the kernel) The first Example describes a Firefox security update and indicates that it would be allowed, but does not describe filing the FESCo ticket that the "Security Updates" section states as a requirement. These two things should be made consistent. Maybe use a different package as an example, since I think this is intended to illustrate something that would require a Major version rebase in order to fix a security problem, and which doesn't have an exception. As a final suggestion, while I hate making the policy any longer, perhaps the policy could start with an extremely brief "TL; DR", along the lines of: "Leaf" nodes MUST be Major-version stable. Everything else MUST be Minor-version stable. Any more significant rebase MUST have a standing exception from FESCo, or request a one-time exception from FESCo. If such a short summary is possible, then maybe the current bugzilla remainders to "check the policy" before pushing an update can be improved. While I expect that the majority of Fedora's maintainers understand Semantic Versions and interface stability well, it might be helpful for new packages (and occasionally for users) to add a footnote or sidebar somewhere to provide background on why a stable interface is desirable, and to provide definitions that help clarify what level of stability is desirable for dependencies and for leaf nodes. Definitions and rationale: In order to understand why a stable interface policy is desirable, it is necessary to understand the basics of Semantic Versioning. In the Semantic Versioning system (https://semver.org/), the Major, Minor, and Patch version numbers represent different types of changes as they increment. When only the Patch level increments, users should expect no interface changes, only backwards-compatible bug fixes. When the Minor level increments, users should expect that new features or interfaces may have been added, but all of the interfaces from prior versions with the same Major version are still present and compatible. When the Major version increases, then users should expect that interfaces may had been removed or changed in incompatible
Re: Should the policy documents better reflect real package maintenance practice?
As a practical example, if Fedora prefers stability for application packages over early updates, I'd like to use Thunderbird as an example because the upstream vendor supports two releases concurrently for a predictable period of ~ 12 weeks. In practice, maintaining that package might look like this: Thunderbird update policy: Thunderbird releases follow the Mozilla ESR calendar [1] relatively closely. Each stable release series is supported for a little over a year, and each release lifecycle overlaps with the subsequent release for at least 12 weeks to allow users a transition period that provides time to test and adapt to breaking API changes. For Fedora releases, Thunderbird should rebase to a new stable release in Rawhide as early as possible, while stable Fedora releases should remain on the old stable series for as long as possible. Firefox ESR releases occur every four weeks (five in some cases), on Tuesday, and Thunderbird will release shortly thereafter. The release cadence makes package maintenance fairly predictable. Roughly every four weeks, the newest release [2] should be built in Rawhide, and in any branched but not yet final Fedora release. If that release is a new release series, a self-contained change announcement should be added to the upcoming Fedora release proposals, possibly referring to the changes documented in the webextension API guide [3]. If there was also a release from the previous release series, that release should also be built in each active Fedora release. However, if there was no release from a prior release series, then the newest release should also be built in each active Fedora release. 1: https://wiki.mozilla.org/Release_Management/Calendar 2: https://www.thunderbird.net/en-US/thunderbird/releases/ 3: https://webextension-api.thunderbird.net/en/latest/index.html ___ 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: Should the policy documents better reflect real package maintenance practice?
On Fri, Nov 25, 2022 at 12:20:10AM +, Gary Buhrmaster wrote: > On Thu, Nov 24, 2022 at 1:40 PM Miroslav Suchý wrote: > > > I have to make confession. I am breaking this guidelines too. With > > releasing of new version of Mock and fedora-license-data. The problem for > > me is that the list of these exception is not available and not maintained. > > I inherited Mock from Clark and later gave it to Pavel and I am now merely > > co-maintainer. So I really do not know if Mock has had the exception. And > > because no one enforce it I even did not apply for the exception for > > fedora-license-data and I use common sense, becase it does not have sense > > to have old data in stable branches. > > Unfortunately, this discussion runs into a multidimensional > matrix of considerations, and different people may make > different choices at each checkbox. ...snip... Absoletely. There's a ton of variables that go into the decision, but I think it's important for there to be some general guidance to err on the side of not changing the user experence in stable releases if you can. 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: [HEADS UP] Rebuild of wxGTK wxGLCanvas-using packages
On Sun, 27 Nov 2022, Mamoru TASAKA wrote: Scott Talbert wrote on 2022/11/24 2:23: Hi all, In order to fix some incompatibilities with wxWidgets wxGLCanvas (which is currently built with OpenGL EGL support) and several package users which are expecting OpenGL GLX support, I need to rebuild wxWidgets with a different configuration option. Unfortunately, this results in an ABI change, so all packages that link with libwx_gtk3u_gl-3.2.so.0 need to be rebuilt. Unfortunately #2, this also needs to be done in F37. I've opened two side tags to do the rebuilds for F37 and F38. F37: f37-build-side-60200 F38: f38-build-side-60198 The following packages need to be rebuilt in the above side tags (note, I've already taken care of python-wxpython4 and CubicSDR, which are also affected): 0ad OpenSceneGraph erlang hugin kicad mrpt panoglview visualboyadvance-m wxmacmolplt If the maintainers of those packages could rebuild their packages in both of the above side tags, it would be creatly appreciated. After a week, I'll flag down a provenpackager to assist with the rest. Thanks, Scott All the requested packages have been successfully rebuilt: https://koji.fedoraproject.org/koji/builds?inherited=0=60198=-build_id=1 https://koji.fedoraproject.org/koji/builds?inherited=0=60200=-build_id=1 Thanks a lot, Mamoru! :) I've created updates to merge these side tags: https://bodhi.fedoraproject.org/updates/FEDORA-2022-6be9e24d9c https://bodhi.fedoraproject.org/updates/FEDORA-2022-efd6af3ba0 Thanks, Scott___ 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: Direct to stable updates
On Sat, Nov 26, 2022 at 05:27:30PM -, Mattia Verga via devel wrote: > @kevin I've announced on Bodhi matrix channel that I was planning to draft > the new release, but since I received no response I've pushed out Bodhi 7.0.0. > > I have followed the SOP at [1] and bodhi-* RPMs are now available in both > f37-infra-stg and f36-infra-stg. Tests run smoothly in F37, so I think it's > ok to move bodhi-backend on it. > > Can you take care of running the playbooks on staging so that we can start > testing the new version? Yep. I will do so sometime in the coming week. Will have more of an idea when tomorrow. 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: "rescue" boot entry files are not updated on OS upgrades
If I'm not mistaken, this issue hasn't been resolved... Since the rescue kernel depends to some extent on the kernel modules in the root volume, would the right solution be: - in preuninstall, determine whether the rescue kernel matches the version being removed, and if so, remove it, and then: - determine whether the version being removed matches the running kernel, and if not, then build a rescue kernel for the running kernel version Protecting the running kernel is optional, so it's possible that the running kernel will be the one removed, and in that case I *think* that the system will end up building a rescue kernel for the version whose installation triggered the removal of a kernel package. That rescue kernel might not work, but neither would the version whose modules were just removed, so the system probably isn't worse off. (And systems with the normal behavior of protecticong the running kernel should be safe from this.) Then the remaining problem is that an awful lot of Fedora systems have already removed the kernel-modules corresponding to (and supporting) their rescue kernel, and this approach would leave them in their current broken state. On Tue, Mar 1, 2022 at 2:56 PM Chris Murphy wrote: > > On Tue, Mar 1, 2022 at 3:24 PM Justin Forbes wrote: > > > I am surprised that the rescue kernel would give an indefinite hang or > > even just a dracut prompt within a release. > > The latter case is trivially reproducible on UEFI, with the failure > being that mounting /boot/efi comes *after* switchroot. After > switchroot the vfat module in the initramfs is not available, and the > rootfs lacks matching /usr/lib/modules, therefore it's also not > available. And thus mount fails and thus dracut shell. > > A possible simple work around is having the installer add "nofail" > mount option to /boot/efi which raises the potential problem that it > fails to mount for $REASON, and thus silently isn't getting bootloader > updates. I guess that's better than always getting a dracut prompt? > > Also more reliable would be if the rescue boot entry uses > systemd.whateverisolate=multiuser.target to make sure (a) consistency > no matter the existence of /usr/lib/modules (b) we don't get hung up > somehow loading the graphical environment possibly needing things in > /usr/lib/modules that aren't available. > > -- > Chris Murphy > ___ > 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 on the list, report it: > https://pagure.io/fedora-infrastructure ___ 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
wlroots 0.16 update announcement
Greetings, Sometime within the next week, I'll be updating wlroots in rawhide to 0.16.0[1] and sway to the latest release candidate. As usual, the update contains API/ABI breaking changes and soname will be bumped to libwlroots.so.11. wlroots0.15 compatibility package will be introduced in the same side-tag. No breakages are expected and no action is required from the maintainers of dependent packages. I'll send another notice with a side-tag id to unblock the updates that already require 0.16 (currently only labwc) when it's ready. *** I'm also planning to update wlroots in f37 once 0.16.1 is available. There are a plenty of bug fixes and some important security features (ext-session-lock-v1) that, I believe, should not require waiting another 6 months for f38. Sway will likely not be included in the initial f37 update, but may follow later when it gets sufficient testing. [1]: https://gitlab.freedesktop.org/wlroots/wlroots/-/releases/0.16.0 -- Best regards, Aleksei Bavshin OpenPGP_signature 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
Fedora rawhide compose report: 20221127.n.0 changes
OLD: Fedora-Rawhide-20221126.n.0 NEW: Fedora-Rawhide-20221127.n.0 = SUMMARY = Added images:1 Dropped images: 2 Added packages: 0 Dropped packages:0 Upgraded packages: 55 Downgraded packages: 0 Size of added packages: 0 B Size of dropped packages:0 B Size of upgraded packages: 1.74 GiB Size of downgraded packages: 0 B Size change of upgraded packages: 222.71 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: Server_KVM qcow2 ppc64le Path: Server/ppc64le/images/Fedora-Server-KVM-Rawhide-20221127.n.0.ppc64le.qcow2 = DROPPED IMAGES = Image: Container_Base docker s390x Path: Container/s390x/images/Fedora-Container-Base-Rawhide-20221126.n.0.s390x.tar.xz Image: Container_Base docker ppc64le Path: Container/ppc64le/images/Fedora-Container-Base-Rawhide-20221126.n.0.ppc64le.tar.xz = ADDED PACKAGES = = DROPPED PACKAGES = = UPGRADED PACKAGES = Package: Maelstrom-3.0.6-44.fc38 Old package: Maelstrom-3.0.6-44.fc37 Summary: A space combat game RPMs: Maelstrom Size: 3.02 MiB Size change: 1.46 KiB Changelog: * Sat Nov 26 2022 Florian Weimer - 3.0.6-44 - Fixes for building in strict(er) C99 mode (#2148634) Package: alpine-2.26-3.fc38 Old package: alpine-2.26-2.fc37 Summary: powerful, easy to use console email client RPMs: alpine Size: 9.87 MiB Size change: 76.52 KiB Changelog: * Sat Nov 26 2022 Florian Weimer - 2.26-3 - Port configure script to C99 (#2148656) Package: alsa-ucm-asahi-1-5.fc38 Old package: alsa-ucm-asahi-1-3.fc38 Summary: ALSA Use Case Manager configuration (and topologies) for Apple silicon devices RPMs: alsa-ucm-asahi Size: 16.53 KiB Size change: -49 B Package: archlinux-keyring-20221123-1.fc38 Old package: archlinux-keyring-20221110-1.fc38 Summary: GPG keys used by Arch distribution to sign packages RPMs: archlinux-keyring Size: 1.12 MiB Size change: 516 B Changelog: * Sat Nov 26 2022 Frantisek Sumsal 20221123-1 - Version 20221123 (#2145118) Package: asahi-scripts-20221122-1.fc38 Old package: asahi-scripts-20221027-7.fc38 Summary: Miscellaneous admin scripts for Asahi Linux RPMs: asahi-fwextract asahi-scripts dracut-asahi linux-firmware-vendor update-m1n1 Size: 54.21 KiB Size change: 601 B Changelog: * Sat Nov 26 2022 Davide Cavalca 20221122-1 - Update to 20221122; Fixes: RHBZ#2145036 Package: bitcoin-core-24.0-1.fc38 Old package: bitcoin-core-23.0-2.fc37 Summary: Peer to Peer Cryptographic Currency RPMs: bitcoin-core-desktop bitcoin-core-devel bitcoin-core-libs bitcoin-core-server bitcoin-core-utils Size: 62.93 MiB Size change: 3.03 MiB Changelog: * Mon Nov 21 2022 Simone Caronni - 24.0-1 - Update to 24.0. Package: bzflag-2.4.26-1.fc38 Old package: bzflag-2.4.22-5.fc37 Summary: 3D multi-player tank battle game RPMs: bzflag bzflag-maps-sample Size: 43.33 MiB Size change: 8.32 KiB Changelog: * Sat Nov 26 2022 Jeff Makey 2.4.26-1 - version 2.4.26 Package: coin-or-Bcps-0.94.5-9.fc38 Old package: coin-or-Bcps-0.94.5-8.fc37 Summary: Part of the COIN High Performance Parallel Search Framework RPMs: coin-or-Bcps coin-or-Bcps-devel coin-or-Bcps-doc Size: 3.41 MiB Size change: -88.43 KiB Changelog: * Sat Nov 26 2022 Florian Weimer - 0.94.5-9 - Port configure scripts to C99 Package: copr-cli-1.104-1.fc38 Old package: copr-cli-1.103-1.fc38 Summary: Command line interface for COPR RPMs: copr-cli Size: 93.04 KiB Size change: -584 B Changelog: * Sat Nov 26 2022 Jakub Kadlcik 1.104-1 - move to GitHub home page - add parameter for custom method repos Package: copr-dist-git-0.58-1.fc38 Old package: copr-dist-git-0.57-1.fc38 Summary: Copr services for Dist Git server RPMs: copr-dist-git Size: 62.75 KiB Size change: 5.04 KiB Changelog: * Sat Nov 26 2022 Jakub Kadlcik 0.58-1 - require redis.service to be started - move to GitHub home page - fair processing of task from multiple sandboxes - use dispatcher and background workers Package: copr-frontend-1.192-1.fc38 Old package: copr-frontend-1.191-1.fc38 Summary: Frontend for Copr RPMs: copr-frontend copr-frontend-devel copr-frontend-fedora Size: 1.96 MiB Size change: 7.89 KiB Changelog: * Sat Nov 26 2022 Jakub Kadlcik 1.192-1 - allow arbitrary creation of :pr: directories - custom repositories with custom webhook - move to GitHub home page - use shlex.quote instead of pipes.quote - add route for a new distgit dispatcher - expand repos for custom SRPM - process external repos for custom build - support LDAP groups for Kerberos users - add version to the bitbucket webhook tag name - loosen the rules of package matching in webhook tags - add optional argument pkg_name
[EPEL-devel] Fedora EPEL 7 updates-testing report
The following Fedora EPEL 7 Security updates need testing: Age URL 3 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-10049c7b14 libbsd-0.11.7-1.el7 The following builds have been pushed to Fedora EPEL 7 updates-testing clustershell-1.9-3.el7 Details about builds: clustershell-1.9-3.el7 (FEDORA-EPEL-2022-aff1301acf) Python framework for efficient cluster administration Update Information: Update to upstream release 1.9 ChangeLog: * Sun Nov 27 2022 Stephane Thiell 1.9-3 - remove suse macros * Sun Nov 27 2022 Stephane Thiell 1.9-2 - python2 macro cleanup * Sat Nov 26 2022 Stephane Thiell 1.9-1 - update to 1.9 ___ 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
corsepiu pushed to rpms/perl-WWW-Form-UrlEncoded (rawhide). "Convert licence to SPDX."
Notification time stamped 2022-11-28 07:02:08 UTC
From 004db77010204604d15d6fe8e992391ccb1d9220 Mon Sep 17 00:00:00 2001
From: Ralf Corsépius
Date: Nov 28 2022 07:01:48 +
Subject: Convert licence to SPDX.
---
diff --git a/perl-WWW-Form-UrlEncoded.spec b/perl-WWW-Form-UrlEncoded.spec
index 715870f..1b708fc 100644
--- a/perl-WWW-Form-UrlEncoded.spec
+++ b/perl-WWW-Form-UrlEncoded.spec
@@ -1,8 +1,8 @@
Name: perl-WWW-Form-UrlEncoded
Version:0.26
-Release:11%{?dist}
+Release:12%{?dist}
Summary:Parser and builder for application/x-www-form-urlencoded
-License:GPL+ or Artistic
+License:GPL-1.0-or-later OR Artistic-1.0-Perl
URL:https://metacpan.org/release/WWW-Form-UrlEncoded
Source0:
https://cpan.metacpan.org/authors/id/K/KA/KAZEBURO/WWW-Form-UrlEncoded-%{version}.tar.gz
@@ -56,6 +56,9 @@ BREAK_BACKWARD_COMPAT=1 ./Build test
%{_mandir}/man3/*
%changelog
+* Mon Nov 28 2022 Ralf Corsépius - 0.26-12
+- Convert licence to SPDX.
+
* Fri Jul 22 2022 Fedora Release Engineering -
0.26-11
- Rebuilt for https://fedoraproject.org/wiki/Fedora_37_Mass_Rebuild
https://src.fedoraproject.org/rpms/perl-WWW-Form-UrlEncoded/c/004db77010204604d15d6fe8e992391ccb1d9220?branch=rawhide
___
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
corsepiu pushed to rpms/perl-Validation-Class (rawhide). "Convert license to SPDX."
Notification time stamped 2022-11-28 07:06:29 UTC
From b57e0b9e0b2a7af20c48d85c11d740763de41a91 Mon Sep 17 00:00:00 2001
From: Ralf Corsépius
Date: Nov 28 2022 07:06:18 +
Subject: Convert license to SPDX.
---
diff --git a/perl-Validation-Class.spec b/perl-Validation-Class.spec
index 2a63107..53dd78c 100644
--- a/perl-Validation-Class.spec
+++ b/perl-Validation-Class.spec
@@ -1,8 +1,8 @@
Name: perl-Validation-Class
Version:7.900058
-Release:2%{?dist}
+Release:3%{?dist}
Summary:Powerful Data Validation Framework
-License:GPL+ or Artistic
+License:GPL-1.0-or-later OR Artistic-1.0-Perl
URL:https://metacpan.org/release/Validation-Class
Source0:
https://cpan.metacpan.org/authors/id/C/CK/CKRAS/Validation-Class-%{version}.tar.gz
BuildArch: noarch
@@ -69,6 +69,9 @@ complete set of pre-defined validations and filters referred
to as
%{_mandir}/man3/*
%changelog
+* Mon Nov 28 2022 Ralf Corsépius - 7.900058-3
+- Convert license to SPDX.
+
* Fri Jul 22 2022 Fedora Release Engineering -
7.900058-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_37_Mass_Rebuild
https://src.fedoraproject.org/rpms/perl-Validation-Class/c/b57e0b9e0b2a7af20c48d85c11d740763de41a91?branch=rawhide
___
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
[EPEL-devel] Fedora EPEL 8 updates-testing report
The following Fedora EPEL 8 Security updates need testing: Age URL 3 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-08012668ea libbsd-0.11.7-1.el8 3 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-da88fe53cf advancecomp-2.4-1.el8 2 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-15988b1700 qpress-20220819-3.el8 The following builds have been pushed to Fedora EPEL 8 updates-testing bitcoin-core-24.0-1.el8 clustershell-1.9-1.el8 Details about builds: bitcoin-core-24.0-1.el8 (FEDORA-EPEL-2022-6582b3f093) Peer to Peer Cryptographic Currency Update Information: Update to 24.0. ChangeLog: * Mon Nov 21 2022 Simone Caronni - 24.0-1 - Update to 24.0. * Wed Jul 20 2022 Fedora Release Engineering - Rebuilt for https://fedoraproject.org/wiki/Fedora_37_Mass_Rebuild References: [ 1 ] Bug #2148273 - bitcoin-core-24.0 is available https://bugzilla.redhat.com/show_bug.cgi?id=2148273 clustershell-1.9-1.el8 (FEDORA-EPEL-2022-4f454888a6) Python framework for efficient cluster administration Update Information: Update to upstream release 1.9 ChangeLog: * Sun Nov 27 2022 Stephane Thiell 1.9-1 - update to 1.9 - removed python2 and suse macros ___ 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
[EPEL-devel] Re: EPEL 7 retirement of findbugs-bcel
On Sun, 27 Nov 2022 at 14:32, Richard Fearn wrote: > Hi all, > > In July 2021 I retired the FindBugs packages from Fedora: > > Thanks for announcing the retirement and giving a good example for how people should do so in the future. -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ 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
[Bug 2148748] New: perl-Term-ReadLine-Gnu-1.45 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2148748 Bug ID: 2148748 Summary: perl-Term-ReadLine-Gnu-1.45 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Term-ReadLine-Gnu Keywords: FutureFeature, Triaged Assignee: emman...@seyman.fr Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: c...@fea.st, emman...@seyman.fr, lkund...@v3.sk, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Releases retrieved: 1.45 Upstream release that is considered latest: 1.45 Current version/release in rawhide: 1.44-1.fc38 URL: https://metacpan.org/dist/Term-ReadLine-Gnu/ 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/7548/ To change the monitoring settings for the project, please visit: https://src.fedoraproject.org/rpms/perl-Term-ReadLine-Gnu -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2148748 ___ 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
[Bug 2148767] New: perl-Compress-LZF: Avoid implicit function declarations for C99 compatibility
https://bugzilla.redhat.com/show_bug.cgi?id=2148767 Bug ID: 2148767 Summary: perl-Compress-LZF: Avoid implicit function declarations for C99 compatibility Product: Fedora Version: rawhide Status: ASSIGNED Component: perl-Compress-LZF Assignee: fwei...@redhat.com Reporter: fwei...@redhat.com QA Contact: extras...@fedoraproject.org CC: p...@city-fan.org, perl-devel@lists.fedoraproject.org Blocks: 2141798 (PortingToModernCNoUpstream) Target Milestone: --- Classification: Fedora Created attachment 1927874 --> https://bugzilla.redhat.com/attachment.cgi?id=1927874=edit perl-Compress-LZF-c99.patch The XS module sources do not include . This results in a compile error with strict(er) C99 compilers. There's no obvious way to report bugs to upstream, so I'm filing this bug for public reference. Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=2141798 [Bug 2141798] Porting Fedora to modern C: Bugs without (referenceable) upstream -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2148767 ___ 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
[Bug 2148767] perl-Compress-LZF: Avoid implicit function declarations for C99 compatibility
https://bugzilla.redhat.com/show_bug.cgi?id=2148767 Florian Weimer changed: What|Removed |Added Resolution|--- |RAWHIDE Status|ASSIGNED|CLOSED Fixed In Version||perl-Compress-LZF-3.8-24.fc ||38 Last Closed||2022-11-27 20:28:12 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2148767 ___ 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
[Bug 2148773] New: perl-Prima-1.67 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2148773 Bug ID: 2148773 Summary: perl-Prima-1.67 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Prima Keywords: FutureFeature, Triaged Assignee: ppi...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: lkund...@v3.sk, perl-devel@lists.fedoraproject.org, ppi...@redhat.com Target Milestone: --- Classification: Fedora Releases retrieved: 1.67 Upstream release that is considered latest: 1.67 Current version/release in rawhide: 1.66-2.fc38 URL: http://search.cpan.org/dist/Prima/ 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/3289/ To change the monitoring settings for the project, please visit: https://src.fedoraproject.org/rpms/perl-Prima -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2148773 ___ 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
[EPEL-devel] Re: Fedora EPEL 9 request Compiz
Hi John, On Sun Nov 27, 2022 at 08:51 +, john tatt via epel-devel wrote: > Hi everyoneI'll like to have Compiz / Emerald available on RHEL/Rocky aso > > is there a chance for this to happen ? > Thank you Please follow the standard EPEL Package Request[1] procedure and let us know if you have any questions. [1]: https://docs.fedoraproject.org/en-US/epel/epel-package-request/ -- Best, Maxwell G (@gotmax23) Pronouns: He/Him/His ___ 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
corsepiu pushed to rpms/perl-namespace-sweep (rawhide). "Modernize spec. (..more)"
Notification time stamped 2022-11-28 07:51:40 UTC
From aed7e101acb9261360aada0ae7a22af4fb57c935 Mon Sep 17 00:00:00 2001
From: Ralf Corsépius
Date: Nov 28 2022 07:51:31 +
Subject: Modernize spec.
Convert license to SPDX.
---
diff --git a/perl-namespace-sweep.spec b/perl-namespace-sweep.spec
index 2586465..b32be59 100644
--- a/perl-namespace-sweep.spec
+++ b/perl-namespace-sweep.spec
@@ -1,13 +1,12 @@
Name: perl-namespace-sweep
Version:0.006
-Release:18%{?dist}
+Release:19%{?dist}
Summary:Sweep up imported subs in your classes
-License:GPL+ or Artistic
+License:GPL-1.0-or-later OR Artistic-1.0-Perl
URL:https://metacpan.org/release/namespace-sweep
Source0:
https://cpan.metacpan.org/authors/id/F/FR/FRIEDO/namespace-sweep-%{version}.tar.gz
BuildArch: noarch
-BuildRequires: make
BuildRequires: %{__perl}
BuildRequires: %{__make}
@@ -46,16 +45,16 @@ will still be able to use the imported functions without
any problems.
%setup -q -n namespace-sweep-%{version}
%build
-%{__perl} Makefile.PL INSTALLDIRS=vendor NO_PACKLIST=1
-%{__make} %{?_smp_mflags}
+%{__perl} Makefile.PL INSTALLDIRS=vendor NO_PACKLIST=1 NO_PERLLOCAL=1
+%{make_build}
%install
-%{__make} pure_install DESTDIR=$RPM_BUILD_ROOT
+%{make_install}
%{_fixperms} $RPM_BUILD_ROOT/*
%check
-make test
+%{__make} test
%files
%doc README
@@ -64,6 +63,10 @@ make test
%{_mandir}/man3/*
%changelog
+* Mon Nov 28 2022 Ralf Corsépius - 0.006-19
+- Modernize spec.
+- Convert license to SPDX.
+
* Fri Jul 22 2022 Fedora Release Engineering -
0.006-18
- Rebuilt for https://fedoraproject.org/wiki/Fedora_37_Mass_Rebuild
https://src.fedoraproject.org/rpms/perl-namespace-sweep/c/aed7e101acb9261360aada0ae7a22af4fb57c935?branch=rawhide
___
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
[EPEL-devel] Re: Fedora EPEL 9 request Compiz
Hi everyoneI'll like to have Compiz / Emerald available on RHEL/Rocky aso is there a chance for this to happen ? Thank you ___ 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
[EPEL-devel] EPEL 7 retirement of findbugs-bcel
Hi all, In July 2021 I retired the FindBugs packages from Fedora: https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/YI723NBFFXAOQSRMYIEFAD6CYGX7S6MM/ This included the findbugs-bcel package, which was an old snapshot of Apache Commons BCEL packaged for use by FindBugs. findbugs-bcel is still present in EPEL 7, but has just had a CVE bug filed against it: https://bugzilla.redhat.com/show_bug.cgi?id=2142726 Rather than attempt to address this vulnerability, and since FindBugs was never packaged for EPEL 7, I intend to retire findbugs-bcel from EPEL 7. As per the EPEL Package Retirement guidelines (https://docs.fedoraproject.org/en-US/epel/epel-policy-retirement/), I'm sending this email to announce my proposal to retire it. According to repoquery, no other packages depend on findbugs-bcel. Regards, Richard -- Richard Fearn richardfe...@gmail.com ___ 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
