[Bug 2123834] perl-Log-Log4perl-1.56 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2123834 Jitka Plesnikova changed: What|Removed |Added Status|ASSIGNED|MODIFIED Fixed In Version||perl-Log-Log4perl-1.56-1.fc ||38 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2123834 ___ 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
[rpms/perl-Log-Log4perl] PR #1: Tests
jplesnik merged a pull-request against the project: `perl-Log-Log4perl` that you are following. Merged pull-request: `` Tests `` https://src.fedoraproject.org/rpms/perl-Log-Log4perl/pull-request/1 ___ 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 2124241] perl-PAR-Packer-1.056 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2124241 Jitka Plesnikova changed: What|Removed |Added Status|NEW |ASSIGNED Doc Type|--- |If docs needed, set a value CC|anon.am...@gmail.com, | |jples...@redhat.com,| |mmasl...@redhat.com | -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2124241 ___ 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 2124001] perl-Proc-Fork-0.808 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2124001 Jitka Plesnikova changed: What|Removed |Added Fixed In Version||perl-Proc-Fork-0.808-1.fc38 Status|ASSIGNED|CLOSED Resolution|--- |RAWHIDE Last Closed||2022-09-06 05:21:25 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2124001 ___ 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
[rpms/perl-Log-Log4perl] PR #1: Tests
jplesnik opened a new pull-request against the project: `perl-Log-Log4perl` that you are following: `` Tests `` To reply, visit the link below https://src.fedoraproject.org/rpms/perl-Log-Log4perl/pull-request/1 ___ 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: hardened malloc is big and slow
On Wed, Aug 31, 2022 at 05:59:42PM +0200, Pablo Mendez Hernandez wrote: > Adding Daniel for awareness. Why was the heavyweight rather than lightweight configuration used? Why compare with all the expensive optional security features enabled? Even the lightweight configuration has 2 of the optional security features enabled: slab canaries and full zero-on-free. Both of those should be disabled to measure the baseline performance. Using the heavyweight configuration means having large slab allocation quarantines and not just zero-on-free but checking that data is still zeroed on allocation (which more than doubles the cost), slot randomization and multiple other features. It just doesn't make sense to turn security up to 11 with optional features and then present that as if it's the performance offered. I'm here to provide clarifications about my project and to counter incorrect beliefs about it. I don't think it makes much sense for Fedora to use it as a default allocator but the claims being made about memory usage and performance are very wrong. I already responded and provided both concise and detailed explanations. I don't know what these nonsense measurements completely disregarding all that are meant to demonstrate. It's a huge hassle for me to respond here because I have no interest in this list and don't want to be subscribed to it. I didn't propose that Fedora uses it and don't think it makes sense for Fedora. At the same time I already explained that glibc malloc is ALSO a very bad choice in detail. Linux distributions not willing to sacrifice much for security would be better served by using jemalloc with small chunk sizes on 64 bit operating systems. ASLR is too low entropy on 32 bit to afford the sacrifice of a few bits for chunk alignment though. It can be configured with extra sanity checks enabled and with certain very non-essential features disabled to provide a better balance of security vs. performance. The defaults are optimized for long running server processes. It's very configurable, including by individual applications. hardened_malloc builds both a lightweight and heavyweight library itself. The lightweight library still has the optional slab allocation canary and full zero-on-free features enabled. Both those should be disabled to truly measure the baseline cost. None of those optional features is provided by glibc malloc. None of them is needed to get the benefits of hardened_malloc's 100% out-of-line metadata, 100% invalid free detection, entirely separate never reused address space regions for all allocator metadata and each slab allocation size class (which covers up to 128k by default), virtual memory quarantines + random guards for large allocations, etc. etc. The optional security features are optional because they're expensive. That's the point of building both a sample lightweight and heavyweight configuration by default. Lightweight configuration is essentially the recommended configuration if you aren't willing to make more significant sacrifices for security. It's not the highest performance configuration it offers, just a reasonable compromise. Slab allocation canaries slightly increase memory usage. Slab allocation quarantines (disabled in lightweight configuration, which is built by default) greatly increase memory usage, especially with the default configuration. The whole point of quarantines is that they delay reuse of the memory and since these are slab allocations within slabs the memory gets held onto. If you wanted to do measure the baseline performance, then you'd do as I suggested and measure with all the optional features disabled (disable at least those 2 features included in optional) and compare that to both glibc malloc and glibc malloc with tcache disabled. I explained previously that hardened_malloc could provide an array-based thread cache as an opt-in feature, but currently it isn't done because it inherently reduces security. No more 100% reliable detection of all invalid frees and a lot more security properties lost. Also hardly makes sense to have optional features like quarantines and slot randomization underneath unless the thread caches are doing the same thing. As I said previously, if you compare hardened_malloc with optional features disabled to glibc malloc with tcache disabled, it performs as well and has much lower fragmentation and lower metadata overhead. If you stick a small array-based thread cache onto hardened_malloc, then it can perform as well as glibc with much larger freelist-based thread caches since it has a different approach to scaling with jemalloc-style arenas. ___ 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:
Re: hardened malloc is big and slow
On Wed, Aug 31, 2022 at 10:19:51AM -0700, John Reiser wrote: > > Bottom line opinion: hardened_malloc ... costs too much. > > Attempting to be constructive: Psychologically, I might be willing to pay > a "security tax" of something like 17%, partly on the basis of similarity > to the VAT rate (Value Added Tax) in some parts of the developed world. The comparison is being done incorrectly. Since hardened_malloc builds both a lightweight and heavyweight library by default, and since I already explained this and that the lightweight library still has optional security features enabled, it doesn't seem to have been done in good faith. My previous posts where I provided both concise and detailed information explaining differences and the approach were ignored. Why is that? As I said previously, hardened_malloc has a baseline very hardened allocator design. It also has entirely optional, expensive security features layered on top of that. I explained in detail that some of those features have a memory cost. Slab allocation canaries have a small memory cost and slab allocation quarantines have a very large memory cost especially with the default configuration. Those expensive optional features each have an added performance cost too. Measuring with 100% of the expensive optional features enabled and trying to portray the performance of the allocator solely based on that is simply incredibly misleading and disregards all of my previous posts in the thread. hardened_malloc builds both a lightweight and heavyweight library by default. The lightweight library still has 2 of the optional security features enabled. None of the optional security features is provided by glibc malloc and if you want to compare the baseline performance then none of those should be enabled for a baseline comparison. Take the light configuration, disable slab allocation canaries and full zero-on-free, and there you go. I also previously explained that hardened_malloc does not include a thread cache for security reasons inherent to the concept of a thread cache. An array-based thread cache with out-of-line metadata would still hurt security, but would be a more suitable approach than a free list compromising the otherwise complete lack of inline metadata. Compare hardened_malloc with the optional security features disabled to glibc malloc and also to glibc malloc with tcache disabled. It's easy enough to stick a thread cache onto hardened_malloc and if there was demand for that I could implement it in half an hour. At the moment, the current users of hardened_malloc don't want to make the sacrifice of losing 100% reliable detection of invalid frees along with the many other benefits lost by doing that. ___ 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: Thunderbird 102 pushed to F36 stable
As I did those updates.. well explained, thx. But this then seems to be a more general problem of how we want to support a switch an application from one ESR/LTS release if it is EOL to the next. not terribly differently than others -- with an abundance of end-user education and caution? tbird version update -- across ESLs or not -- breaking one's install, or eating one's mailstore, is not _automatically_ a universal fact for tbird, it's more often an issue specific to one's system; not uncommmonly, your config &/or your addons. for other ppl, the upgrade's been working fine in production for awhile now with upstream releases, with early fedora tbird builds, and now the fedora release pkgs. for me, the lack of a long-overdue v102 update was 'costing' much more than not ... on F36, thunderbird packages are still available in two major versions dnf list --showduplicates thunderbird Last metadata expiration check: 0:01:09 ago on Sat 03 Sep 2022 07:36:45 AM EDT. Available Packages thunderbird.x86_6491.7.0-1.fc36 fedora thunderbird.x86_64 102.2.1-1.fc36 updates older version's still easily installed, dnf install thunderbird-91.7.0-1.fc36.x86_64 historical versions are still available, and quite easily installed & functional, from https://www.thunderbird.net/en-US/thunderbird/releases/ ESL or not, how exactly was thunderbird 102 'pushed' to ppl's systems? did they enable autoupdates? or, click to allow the update? if tbird's a critical update for 'you', you do have backups of your tbird configs & mailstores? keep up to date with thunderbird version progress/news/chengelogs/notes? remembered that addons are not tbird or fedora issues, and checked current/future compatibility of your addons, as well as whether they're well maintained? communicated issues/bugs/etc to the respective projects? and have waited to update until after checking/verifying that it works for you? and, in case none of that was done, since firefox/tbird major-version update issues _are_ historically well-known (if unfortunate), you froze version upgrades of tbird on your system https://dnf-plugins-core.readthedocs.io/en/latest/versionlock.html to make sure that you're never surprised by an update you don't want/expect? my $0.02. ___ 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: Users with commit rights in src.fp.o but no more in packager group
On Mon, Sep 05, 2022 at 12:13:26PM +0200, Miro Hrončok wrote: > On 05. 09. 22 11:07, Vít Ondruch wrote: > > > > Apart from that, I don't think that the pseudo-users or group ownership > > would work. I saw a good amount of people giving the packages to some > > groups or pseudo-users, but in turn, that meant there is nobody who > > would care about such package. > > +100 While that can surely happen, it can and does also happen when someone is 'main admin' of a package. :) You can't make someone care. I think the best thing we can do is match up the people who care with the packages they care about. Using main admin as a indicator of who cares for the package doesn't seem right to me. You can definitely have cases of packages where multiple people work on it, or cases where just one person does, but they aren't the main admin. Anyhow, the only real reason we need main admin is that bugzilla needs 1 specific user to assign bugs to. Perhaps we could consider this when/if we ever move off bugzilla. 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: Conditional Patch line
On Mon, 2022-09-05 at 15:00 -0500, Maxwell G via devel wrote:
> On Monday, September 5, 2022 Richard W.M. Jones wrote:
> > I have a downstream patch[0] which -- I don't really understand why
> > --
> > breaks riscv64 builds but is necessary for primary Fedora arches.
> > Is
> > it correct to do:
> >
> > %ifnarch riscv64
> > Patch123: downstream.patch
> > %endif
> >
> > given that the package uses %autosetup and therefore doesn't have
> > explicit %patch lines.
> >
> > I think this means that if I build the SRPM on riscv64 then the
> > downstream patch wouldn't be included, meaning that SRPM would then
> > fail to build on other arches. In this particular case that
> > doesn't
> > matter, but it feels wrong. Is there a recommended way to do this
> > (apart from fixing the patch)?
>
> Yes, conditionalizing Source or Patch lines is a bad idea. This exact
> case is
> explicitly forbidden by the guidelines[1]. There is also a guidelines
> PR to
> forbid any type of Source/Patch conditionaliztion[2].
because src.rpm will be different if build in one specific arch and
src.rpm should have the same results built in any arch
> [1]: https://docs.fedoraproject.org/en-US/packaging-guidelines/
> #_no_arch_specific_sources_or_patches
>
> [2]: https://pagure.io/packaging-committee/pull-request/1163
>
> If you don't want to add %patchX for every Patch, you can use regular
> `%setup
> -q` together with %autopatch, which allows more granular control than
> `%autosetup`.
>
> From /usr/lib/rpm/macros:
>
> ```
> # Apply patches using %autosetup configured SCM.
> # Typically used with no arguments to apply all patches in the order
> # introduced in the spec, but alternatively can be used to apply
> indvidual
> # patches in arbitrary order by passing them as arguments.
> # -vVerbose
> # -p Prefix strip (ie patch -p argument)
> # -m Apply patches with number >= min only (if no
> arguments)
> # -M Apply patches with number <= max only (if no
> arguments)
> %autopatch(vp:m:M:) %{lua:
> ```
maybe this works:
%autosetup -M122 -m124
%ifnarch riscv64
%patch123 -p1
%endif
--
Sérgio M. B.
___
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: Conditional Patch line
On 5/9/22 16:42, Richard W.M. Jones wrote: I have a downstream patch[0] which -- I don't really understand why -- breaks riscv64 builds but is necessary for primary Fedora arches. Is it correct to do: %ifnarch riscv64 Patch123: downstream.patch %endif When I have to do things like that (often temporarily), I do something like this %ifnarch riscv64 Patch123: downstream.patch %else Source23: downstream.patch %endif given that the package uses %autosetup and therefore doesn't have explicit %patch lines. I think this means that if I build the SRPM on riscv64 then the downstream patch wouldn't be included, meaning that SRPM would then fail to build on other arches. In this particular case that doesn't matter, but it feels wrong. Is there a recommended way to do this (apart from fixing the patch)? Rich. [0] https://pagure.io/fedora-ocaml/c/41d5e2db7a4667560d6aedda11a3c6a80c8f1b83?branch=fedora-37-4.14.0 Pablo. ___ 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: [EPEL-devel] EPEL: packaging multiple versions and compat packages
On Monday, September 5, 2022 Mark E. Fuller wrote: > Can someone point me to a good resource on how (if permitted) I can make > appropriate compat(?) packages to allow for two major versions of the > same package to be available? > Is this allowed for EPEL? You can package compat packages as long as they don't conflict with anything in RHEL. EPEL packages may conflict with other EPEL packages, however. -- Maxwell G (@gotmax23) Pronouns: He/Him/His 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
[EPEL-devel] Re: EPEL: packaging multiple versions and compat packages
On Monday, September 5, 2022 Mark E. Fuller wrote: > Can someone point me to a good resource on how (if permitted) I can make > appropriate compat(?) packages to allow for two major versions of the > same package to be available? > Is this allowed for EPEL? You can package compat packages as long as they don't conflict with anything in RHEL. EPEL packages may conflict with other EPEL packages, however. -- Maxwell G (@gotmax23) Pronouns: He/Him/His signature.asc Description: This is a digitally signed message part. ___ 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: Inactive packagers to be removed after the F37 release
On Monday, September 5, 2022 Peter Robinson wrote: > it would probably be easier to join and become a packager by > packaging a random leaf package no one would use, then as a packager > pick up an random orphaned package that's in the core distro and then > just compromise the distro that way TBH. They wouldn't even need to pick up a core package. "Supplements: kernel" would get them far enough... -- Maxwell G (@gotmax23) Pronouns: He/Him/His 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
Re: Conditional Patch line
On Monday, September 5, 2022 Richard W.M. Jones wrote:
> I have a downstream patch[0] which -- I don't really understand why --
> breaks riscv64 builds but is necessary for primary Fedora arches. Is
> it correct to do:
>
> %ifnarch riscv64
> Patch123: downstream.patch
> %endif
>
> given that the package uses %autosetup and therefore doesn't have
> explicit %patch lines.
>
> I think this means that if I build the SRPM on riscv64 then the
> downstream patch wouldn't be included, meaning that SRPM would then
> fail to build on other arches. In this particular case that doesn't
> matter, but it feels wrong. Is there a recommended way to do this
> (apart from fixing the patch)?
Yes, conditionalizing Source or Patch lines is a bad idea. This exact case is
explicitly forbidden by the guidelines[1]. There is also a guidelines PR to
forbid any type of Source/Patch conditionaliztion[2].
[1]: https://docs.fedoraproject.org/en-US/packaging-guidelines/
#_no_arch_specific_sources_or_patches
[2]: https://pagure.io/packaging-committee/pull-request/1163
If you don't want to add %patchX for every Patch, you can use regular `%setup
-q` together with %autopatch, which allows more granular control than
`%autosetup`.
>From /usr/lib/rpm/macros:
```
# Apply patches using %autosetup configured SCM.
# Typically used with no arguments to apply all patches in the order
# introduced in the spec, but alternatively can be used to apply indvidual
# patches in arbitrary order by passing them as arguments.
# -vVerbose
# -p Prefix strip (ie patch -p argument)
# -m Apply patches with number >= min only (if no arguments)
# -M Apply patches with number <= max only (if no arguments)
%autopatch(vp:m:M:) %{lua:
```
--
Maxwell G (@gotmax23)
Pronouns: He/Him/His
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
Re: Conditional Patch line
On Mon, Sep 05, 2022 at 09:56:58PM +0200, Dominik 'Rathann' Mierzejewski wrote: > On Monday, 05 September 2022 at 21:42, Richard W.M. Jones wrote: > > I have a downstream patch[0] which -- I don't really understand why -- > > breaks riscv64 builds but is necessary for primary Fedora arches. Is > > it correct to do: > > > > %ifnarch riscv64 > > Patch123: downstream.patch > > %endif > > > > given that the package uses %autosetup and therefore doesn't have > > explicit %patch lines. > > > > I think this means that if I build the SRPM on riscv64 then the > > downstream patch wouldn't be included, meaning that SRPM would then > > fail to build on other arches. In this particular case that doesn't > > matter, but it feels wrong. Is there a recommended way to do this > > (apart from fixing the patch)? > > Change %autosetup to plain %setup and apply the patch conditionally > instead of conditionally including it in the SRPM. There are 26 patches so that's a bit of a PITA. Is there not an easier way? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v ___ 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: Conditional Patch line
On Monday, 05 September 2022 at 21:42, Richard W.M. Jones wrote: > I have a downstream patch[0] which -- I don't really understand why -- > breaks riscv64 builds but is necessary for primary Fedora arches. Is > it correct to do: > > %ifnarch riscv64 > Patch123: downstream.patch > %endif > > given that the package uses %autosetup and therefore doesn't have > explicit %patch lines. > > I think this means that if I build the SRPM on riscv64 then the > downstream patch wouldn't be included, meaning that SRPM would then > fail to build on other arches. In this particular case that doesn't > matter, but it feels wrong. Is there a recommended way to do this > (apart from fixing the patch)? Change %autosetup to plain %setup and apply the patch conditionally instead of conditionally including it in the SRPM. Regards, Dominik -- Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected 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
Conditional Patch line
I have a downstream patch[0] which -- I don't really understand why -- breaks riscv64 builds but is necessary for primary Fedora arches. Is it correct to do: %ifnarch riscv64 Patch123: downstream.patch %endif given that the package uses %autosetup and therefore doesn't have explicit %patch lines. I think this means that if I build the SRPM on riscv64 then the downstream patch wouldn't be included, meaning that SRPM would then fail to build on other arches. In this particular case that doesn't matter, but it feels wrong. Is there a recommended way to do this (apart from fixing the patch)? Rich. [0] https://pagure.io/fedora-ocaml/c/41d5e2db7a4667560d6aedda11a3c6a80c8f1b83?branch=fedora-37-4.14.0 -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org ___ 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] EPEL: packaging multiple versions and compat packages
Hi all, Can someone point me to a good resource on how (if permitted) I can make appropriate compat(?) packages to allow for two major versions of the same package to be available? Is this allowed for EPEL? Thanks -- Mark E. Fuller, Ph.D. ful...@fedoraproject.org ful...@mefuller.dev @fuller:fedora.im @fuller:one.ems.host https://www.stossrohr.net PGP Fingerprint: 73F1 A30C BDF4 DB4B C75F FD0F D599 E76C FFCA BF60 ___ 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: packaging multiple versions and compat packages
Hi all, Can someone point me to a good resource on how (if permitted) I can make appropriate compat(?) packages to allow for two major versions of the same package to be available? Is this allowed for EPEL? Thanks -- Mark E. Fuller, Ph.D. ful...@fedoraproject.org ful...@mefuller.dev @fuller:fedora.im @fuller:one.ems.host https://www.stossrohr.net PGP Fingerprint: 73F1 A30C BDF4 DB4B C75F FD0F D599 E76C FFCA BF60 ___ 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 swap: a port compiler plugin for Rebar3
Hello All! This spec is actually quite simple - it does all the heavy lifting with generic Erlang macros, builds cleanly, so it won't take you long https://bugzilla.redhat.com/show_bug.cgi?id=2123175 I am willing to review something which got stuck in your queue for a while. -- With best regards, Peter Lemenkov. ___ 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: Help needed with Python fc36 build failing
On Mon, Sep 5, 2022 at 2:01 PM Sandro wrote: > Thank you, Miro, for the explanation and the pull request. I remember > switching away from setup.cfg after being told that pyproject.toml is > the way forward. I must have missed the fact that this required a newer > minimum version of setuptools. pyproject does not work well, and is not backwards compatible. This is particularly a problem for EPEL ports from Fedora. Personally, I'd like to see it fixed for EPEL before relying on it for anything in Fedora. ___ 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: Help needed with Python fc36 build failing
On 05-09-2022 19:17, Miro Hrončok wrote: On 05. 09. 22 19:00, Sandro wrote: I see the following errors in the build log of a fc36 build [1]: ValueError: Globs did not match any module: pymunin Going up it looks like the name of the package is not expanded and falls back to UNKNOWN: Successfully built UNKNOWN However, the builds for fc37 and rawhide did succeed. I also tried a local mock build for x86_64, but the result is the same. I fail to grasp what's going on here. [1] https://download.copr.fedorainfracloud.org/results/gui1ty/PyMunin3/fedora-36-armhfp/04809614-python-PyMunin3/ Looking at the project https://pypi.org/project/PyMunin3/3.0.1/#files They include metadata for setuptools in pyproject.toml only (PEP 621): https://github.com/penguinpee/PyMunin3/blob/v3.0.1/pyproject.toml#L5 This has only been supported since setuptools 61.0.0: https://setuptools.pypa.io/en/latest/history.html#v61-0-0 https://peps.python.org/pep-0621/ On Fedora 36, setuptools is 59.6 and it does not read/understand the information from pyproject.toml. Unfortunately, when no name or version is present, setuptools does the UNKNOWN==0.0.0 thing: https://github.com/pypa/setuptools/issues/2329 My guess is that when PyMunin3 started to use this feature: https://github.com/penguinpee/PyMunin3/commit/3993dcaa5366da9d771575e8735dd5a7a2c13894 They should have changed the minimal required setuptools version in: https://github.com/penguinpee/PyMunin3/blob/v3.0.1/pyproject.toml#L2 In fact: https://github.com/penguinpee/PyMunin3/pull/3 To package PyMunin3 on Fedora 36, you might need to revert 3993dcaa5366 via a patch or somebody would need to backport this feature to setuptools 59. That might be non-trivial. Due to a significant amount of other braking changes, updating setuptools in Fedora 36 to 61 is not very likely. Thank you, Miro, for the explanation and the pull request. I remember switching away from setup.cfg after being told that pyproject.toml is the way forward. I must have missed the fact that this required a newer minimum version of setuptools. Since this package has yet to make its way into Fedora, I don't mind if it's not available for F36. It will trickle down (or is it up?) from F37. -- Sandro ___ 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
StrongCryptoSettings3 Setting Test Day
Hey All, We have a bunch of test days coming up, we are currently running StrongCryptoSettings3 test day. I will be keeping this open for community members to come and test. It's fairly simple, just run the commands you find in[0] and your output should correspond to [1] This is an *unconventional* test day which means, two things 1. You must try out any exotic VPN, git work flow, chat apps and see if they work 2. Anything which will use OpenSSL will be affected and any corner case should be possibly tested! The first set of quick command execution will be easy. The test day matrix will be open for the time being and it will be great to have this tested! [0] https://fedoraproject.org/wiki/Test_Day:2022-09-05_StrongCryptoSettings3#How_to_test? [1] https://pagure.io/fedora-qa/issue/707#comment-813926 -- //sumantro Fedora QE TRIED AND PERSONALLY TESTED, ERGO TRUSTED ___ 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: Sympy 1.11 (review swaps)
On Wed, Aug 31, 2022 at 1:37 PM Jerry James wrote: > They're all done, except for this one: > > python-furo: https://bugzilla.redhat.com/show_bug.cgi?id=2121594 > > It's a bit complicated, due to needing a pile of JavaScript at build > time. Who would like to swap reviews? Give me a complicated one. :-) I am still looking for a reviewer for python-furo. Who needs a review? I'll swap you. -- Jerry James http://www.jamezone.org/ ___ 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: Help needed with Python fc36 build failing
On 05. 09. 22 19:17, Miro Hrončok wrote: My guess is that when PyMunin3 started to use this feature: https://github.com/penguinpee/PyMunin3/commit/3993dcaa5366da9d771575e8735dd5a7a2c13894 They should have changed the minimal required setuptools version in: https://github.com/penguinpee/PyMunin3/blob/v3.0.1/pyproject.toml#L2 In fact: https://github.com/penguinpee/PyMunin3/pull/3 To package PyMunin3 on Fedora 36, you might need to revert 3993dcaa5366 via a patch or somebody would need to backport this feature to setuptools 59. That might be non-trivial. Due to a significant amount of other braking changes, updating setuptools in Fedora 36 to 61 is not very likely. Apologies, I now realized that @penguinpee is you. In that case, you might consider not using this feature until Fedora 36 goes EOL. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ 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: Help needed with Python fc36 build failing
On 05. 09. 22 19:00, Sandro wrote: I see the following errors in the build log of a fc36 build [1]: ValueError: Globs did not match any module: pymunin Going up it looks like the name of the package is not expanded and falls back to UNKNOWN: Successfully built UNKNOWN However, the builds for fc37 and rawhide did succeed. I also tried a local mock build for x86_64, but the result is the same. I fail to grasp what's going on here. [1] https://download.copr.fedorainfracloud.org/results/gui1ty/PyMunin3/fedora-36-armhfp/04809614-python-PyMunin3/ Looking at the project https://pypi.org/project/PyMunin3/3.0.1/#files They include metadata for setuptools in pyproject.toml only (PEP 621): https://github.com/penguinpee/PyMunin3/blob/v3.0.1/pyproject.toml#L5 This has only been supported since setuptools 61.0.0: https://setuptools.pypa.io/en/latest/history.html#v61-0-0 https://peps.python.org/pep-0621/ On Fedora 36, setuptools is 59.6 and it does not read/understand the information from pyproject.toml. Unfortunately, when no name or version is present, setuptools does the UNKNOWN==0.0.0 thing: https://github.com/pypa/setuptools/issues/2329 My guess is that when PyMunin3 started to use this feature: https://github.com/penguinpee/PyMunin3/commit/3993dcaa5366da9d771575e8735dd5a7a2c13894 They should have changed the minimal required setuptools version in: https://github.com/penguinpee/PyMunin3/blob/v3.0.1/pyproject.toml#L2 In fact: https://github.com/penguinpee/PyMunin3/pull/3 To package PyMunin3 on Fedora 36, you might need to revert 3993dcaa5366 via a patch or somebody would need to backport this feature to setuptools 59. That might be non-trivial. Due to a significant amount of other braking changes, updating setuptools in Fedora 36 to 61 is not very likely. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ 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
Help needed with Python fc36 build failing
I see the following errors in the build log of a fc36 build [1]: ValueError: Globs did not match any module: pymunin Going up it looks like the name of the package is not expanded and falls back to UNKNOWN: Successfully built UNKNOWN However, the builds for fc37 and rawhide did succeed. I also tried a local mock build for x86_64, but the result is the same. I fail to grasp what's going on here. [1] https://download.copr.fedorainfracloud.org/results/gui1ty/PyMunin3/fedora-36-armhfp/04809614-python-PyMunin3/ -- Sandro ___ 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: Inactive packagers to be removed after the F37 release
On Sun, Sep 4, 2022 at 5:30 PM Michael Catanzaro wrote: > And anybody who isn't willing . ... or able (they are not free, and there may be other restrictions regarding crypto capable device export/import that can require a bit of hoop jumping due to sourcing site shrinkage, all of which does raise bars a bit higher) > ... to buy a security key wouldn't be able to contribute to Fedora > at all. True, and we (as a community) need to understand and support all that wish to contribute, even if they do not have those means. But it is also true that the intent with passkey includes being able to use your (sufficiently modern) mobile device or computer as a source rather than just a physical key(*) (and while I have not tried it (so have no idea how complete/capable it is) I recall there is a golang implementation using your computers TPM2 chip that can be a fido2 authenticator "key" on Linux). While we clearly are not *there* yet, we are getting closer every year where almost everyone has a usable authenticator available to them nearly all the time (typically carried around in their back pocket, or with the user's face staring at the screen). (*) At the recent RSA conference I saw a live demo from a person with devices running iOS, Android, macOS and Windows (no Linux) which could transparently exchange credentials created via FIDO2/passkey technology (even the presenter was a bit surprised there was only a minor "demo effect" glitch since it was partially pre-GA code, but work it did). ___ 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: Manually queue Koschei build?
On Mon, Sep 5, 2022 at 6:00 PM Richard Shaw wrote: > > I was able to fix my EPEL 7 package and performed a successful build: > https://koji.fedoraproject.org/koji/buildinfo?buildID=2058266 > > So I forced a Koschei build to clear the error, but it still built the > PREVIOUS SRPM: > https://koschei.fedoraproject.org/build/13643482 IIUC, koschei takes the latest SRPM from the *buildroot*. So if you didn't file a buildroot override for the successful build, it cannot see it until it is pushed to stable. 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: Inactive packagers to be removed after the F37 release
On 05/09/2022 17:58, Alexander Bokovoy wrote: They are using tokens from Aladdin, Feitian, and Rutoken, compatible with FIDO2 U2F/WebAuthn. These products are certified and allowed for use in Russia. AFAIK, Aladdin and Rutoken requires their own proprietary drivers for GNU/Linux. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ 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: Orphaned packages looking for new maintainers
I've taken a few more (a few for the neuro-sig): > Depending on: mcpanel (1), status change: 2022-08-30 (0 weeks ago) > eegview (maintained by: aekoroglu, ankursinha, neuro-sig) > eegview-0.0-15.fc37.src requires mcpanel-devel = 0.0-15.fc37 > eegview-0.0-15.fc37.x86_64 requires libmcpanel.so.0()(64bit) Taken for neuro-sig, co-maintainers welcome > Depending on: python-aiofiles (5), status change: 2022-08-30 (0 weeks ago) > > > python-matrix-nio (maintained by: ankursinha) > python-matrix-nio-0.19.0-6.fc38.src requires > python3dist(aiofiles) = 0.7 > python3-matrix-nio-0.19.0-6.fc38.noarch requires > python3.11dist(aiofiles) = 0.7 Taken for myself, co-maintainers welcome. > Depending on: python-piexif (3), status change: 2022-08-30 (0 weeks ago) > > vimiv-qt (maintained by: ankursinha) > vimiv-qt-0.8.0-7.fc37.x86_64 requires python3-piexif = > 1.1.3-14.fc37 Taken for myself, co-maintainers welcome. > Depending on: python-rply (4), status change: 2022-08-30 (0 weeks ago) > python-rnc2rng (maintained by: iztokf) > python-rnc2rng-2.6.6-3.fc37.src requires python3dist(rply) = > 0.7.8 > python3-rnc2rng-2.6.6-3.fc37.noarch requires > python3.11dist(rply) = 0.7.8 > > python-citeproc-py (maintained by: ankursinha, ignatenkobrain, > neuro-sig) > python-citeproc-py-0.6.0-5.fc37.src requires > python3dist(rnc2rng) = 2.6.6 > > python-duecredit (maintained by: ankursinha, neuro-sig) > python-duecredit-0.9.1-5.fc37.src requires > python3dist(citeproc-py) = 0.6 > python3-duecredit-0.9.1-5.fc37.noarch requires > python3.11dist(citeproc-py) > = 0.6, python3dist(citeproc-py) = 0.6 > > python-pybids (maintained by: ankursinha, neuro-sig) > python-pybids-0.13.1-5.fc37.src requires python3dist(duecredit) > = 0.9.1 Taken for neuro-sig, co-maintainers welcome > Depending on: rtfilter (2), status change: 2022-08-30 (0 weeks ago) > mcpanel (maintained by: orphan) > mcpanel-0.0-15.fc37.i686 requires librtfilter.so.1 > mcpanel-0.0-15.fc37.src requires rtfilter-devel = 1.1-16.fc37 > mcpanel-0.0-15.fc37.x86_64 requires librtfilter.so.1()(64bit) > > eegview (maintained by: aekoroglu, ankursinha, neuro-sig) > eegview-0.0-15.fc37.src requires mcpanel-devel = 0.0-15.fc37 > eegview-0.0-15.fc37.x86_64 requires libmcpanel.so.0()(64bit) Taken for neuro-sig, co-maintainers welcome -- 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: Inactive packagers to be removed after the F37 release
On ma, 05 syys 2022, Vitaly Zaitsev via devel wrote: On 05/09/2022 17:05, Alexander Bokovoy wrote: The site blocks access from outside of Russia. Yes, you need RU proxy to read the original documents. But you can use your favorite search engine to find "FSB notification" articles in English. Example: http://www.mintest-russia.com/news/russia-importing-encrypted-products-fsb-notification-for-encryption-or-notification-for-encrypted-pr/ There are solutions by Russian companies which use WebAuthn and were certified by Russian state (FSTEK). For example, Avanpost Web SSO and Avanpost FAM were certified in 2021. They are using tokens from Aladdin, Feitian, and Rutoken, compatible with FIDO2 U2F/WebAuthn. These products are certified and allowed for use in Russia. I happen to know as they support FreeIPA integration officially. The issue right now is not a non-certified usage but a basic unavailability of these tokens inside the country. However, this is a completely different store. Avanpost's press-releases (in Russian): https://avanpost.ru/news/928/ https://avanpost.ru/news/944/, and https://avanpost.ru/news/973/ -- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland ___ 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: Orphaned packages looking for new maintainers
On Mon, 2022-09-05 at 16:16 +0200, Fabio Valentini wrote: > On Mon, Sep 5, 2022 at 4:09 PM Miro Hrončok > wrote: > > > > On 05. 09. 22 14:07, Sérgio Basto wrote: > > > > > > fortune-mod says "Orphaned for: Orphaned by releng" , which user > > > was > > > considered unresponsive ? > > > Where I can find the tickets of unresponsive maintainer ? > > > > $ koji list-history --package=fortune-mod TIL > > ... > > Mon Sep 5 07:11:28 2022 package owner changed for fortune-mod in > > f38 by bodhi > > owner.name: sheltren -> orphan > > Mon Sep 5 12:08:51 2022 package owner changed for fortune-mod in > > f37 by bodhi > > owner.name: sheltren -> orphan > > Mon Sep 5 15:02:35 2022 package owner changed for fortune-mod in > > f36 by bodhi > > owner.name: sheltren -> orphan > > > > > > There was no non-responsive maintainer process for sheltren. > > Searching for sheltren in the releng ticket tracker yields nothing. > > > > Note that even the maintainer can orphan the package with the > > reason set to > > "Orphaned for: Orphaned by releng", there is no guard protecting > > against that. > > The package was orphaned by releng because the primary maintainer was > no longer in the "packager" group: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/WR4ZROGR3J7OEZ7IP2XTKT37LRMBCTM3/ > Thank you, I took the fortune-mod -- Sérgio M. B. ___ 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: Inactive packagers to be removed after the F37 release
On 05/09/2022 17:05, Alexander Bokovoy wrote: The site blocks access from outside of Russia. Yes, you need RU proxy to read the original documents. But you can use your favorite search engine to find "FSB notification" articles in English. Example: http://www.mintest-russia.com/news/russia-importing-encrypted-products-fsb-notification-for-encryption-or-notification-for-encrypted-pr/ -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ 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: Inactive packagers to be removed after the F37 release
On ma, 05 syys 2022, Vitaly Zaitsev via devel wrote: On 05/09/2022 14:58, Dominik 'Rathann' Mierzejewski wrote: Do you have any references to articles of law or other regulations? Sorry, but this sounds so absurd I can't just take your word for it. Sure (in Russian, use Google Translate): - http://clsz.fsb.ru/clsz/in-out.htm - http://clsz.fsb.ru/clsz/notif.htm The site blocks access from outside of Russia. -- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland ___ 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 2124296] Please branch and build perl-File-BaseDir in epel9
https://bugzilla.redhat.com/show_bug.cgi?id=2124296 Johannes Kreuzer changed: What|Removed |Added Status|NEW |CLOSED Resolution|--- |NOTABUG Last Closed||2022-09-05 14:55:52 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2124296 ___ 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: Inactive packagers to be removed after the F37 release
On 05/09/2022 14:58, Dominik 'Rathann' Mierzejewski wrote: Do you have any references to articles of law or other regulations? Sorry, but this sounds so absurd I can't just take your word for it. Sure (in Russian, use Google Translate): - http://clsz.fsb.ru/clsz/in-out.htm - http://clsz.fsb.ru/clsz/notif.htm -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ 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 2124296] New: Please branch and build perl-File-BaseDir in epel9
https://bugzilla.redhat.com/show_bug.cgi?id=2124296 Bug ID: 2124296 Summary: Please branch and build perl-File-BaseDir in epel9 Product: Fedora EPEL Version: epel9 Status: NEW Component: perl-File-BaseDir Severity: medium Assignee: or...@nwra.com Reporter: johan...@kreuzer-bb.de QA Contact: extras...@fedoraproject.org CC: jples...@redhat.com, mmasl...@redhat.com, mspa...@redhat.com, or...@nwra.com, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Please branch and build perl-File-BaseDir in epel9. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2124296 ___ 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: Orphaned packages looking for new maintainers
On Mon, Sep 5, 2022 at 4:09 PM Miro Hrončok wrote: > > On 05. 09. 22 14:07, Sérgio Basto wrote: > > > > fortune-mod says "Orphaned for: Orphaned by releng" , which user was > > considered unresponsive ? > > Where I can find the tickets of unresponsive maintainer ? > > $ koji list-history --package=fortune-mod > ... > Mon Sep 5 07:11:28 2022 package owner changed for fortune-mod in f38 by bodhi > owner.name: sheltren -> orphan > Mon Sep 5 12:08:51 2022 package owner changed for fortune-mod in f37 by bodhi > owner.name: sheltren -> orphan > Mon Sep 5 15:02:35 2022 package owner changed for fortune-mod in f36 by bodhi > owner.name: sheltren -> orphan > > > There was no non-responsive maintainer process for sheltren. > Searching for sheltren in the releng ticket tracker yields nothing. > > Note that even the maintainer can orphan the package with the reason set to > "Orphaned for: Orphaned by releng", there is no guard protecting against that. The package was orphaned by releng because the primary maintainer was no longer in the "packager" group: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/WR4ZROGR3J7OEZ7IP2XTKT37LRMBCTM3/ 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: Orphaned packages looking for new maintainers
On 05. 09. 22 14:07, Sérgio Basto wrote: fortune-mod says "Orphaned for: Orphaned by releng" , which user was considered unresponsive ? Where I can find the tickets of unresponsive maintainer ? $ koji list-history --package=fortune-mod ... Mon Sep 5 07:11:28 2022 package owner changed for fortune-mod in f38 by bodhi owner.name: sheltren -> orphan Mon Sep 5 12:08:51 2022 package owner changed for fortune-mod in f37 by bodhi owner.name: sheltren -> orphan Mon Sep 5 15:02:35 2022 package owner changed for fortune-mod in f36 by bodhi owner.name: sheltren -> orphan There was no non-responsive maintainer process for sheltren. Searching for sheltren in the releng ticket tracker yields nothing. Note that even the maintainer can orphan the package with the reason set to "Orphaned for: Orphaned by releng", there is no guard protecting against that. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ 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] Re: EPEL2RHEL - New Wording? - New Workflow?
On Mon, 2022-09-05 at 11:33 +0200, Dominik 'Rathann' Mierzejewski wrote: > It would be really nice if the wording of the bug could contain some > kind of a "thank you" note to the EPEL maintainers of the package in > question. Not everyone will understand this process as "great, I > don't > have to maintain package X anymore, Red Hat will be doing that for me > from now on". Some folks may take it as "Oh no! Red Hat is taking > away > my toy! Why?!" Ideally, there should still be a way for EPEL > maintainer(s) to continue contributing to the RHEL package. This is a great idea. Maybe we could have a link to a doc that explains what's going on in more details and how to contribute to the package once it's in RHEL ? Cheers Davide ___ 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 2124002] perl-YAML-LibYAML-0.84 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2124002 --- Comment #3 from Fedora Update System --- FEDORA-2022-6f0397b5b9 has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2022-6f0397b5b9 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2124002 ___ 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 2123834] perl-Log-Log4perl-1.56 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2123834 Jitka Plesnikova changed: What|Removed |Added CC|jose.p.oliveira.oss@gmail.c | |om, jples...@redhat.com,| |ka...@ucw.cz, | |mspa...@redhat.com, | |st...@silug.org | Doc Type|--- |If docs needed, set a value Status|NEW |ASSIGNED -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2123834 ___ 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: Thunderbird 102 pushed to F36 stable
Hi, As I did those updates.. On Friday, 2022-09-02 17:49:57 +, Mattia Verga via devel wrote: > Here we go again: thunderbird 102 update was submitted to F36. Actually we already had 102.2.0 a week before on 2022-08-23 with https://bodhi.fedoraproject.org/updates/FEDORA-2022-ddee3eb27c for f35 https://bodhi.fedoraproject.org/updates/FEDORA-2022-33dd0f2f3e for f36 after Jan did the rebase to 102.1.0 that was not pushed. We maybe could had gone with 91.13.0 instead of 102.2.0, backing out the rebase for one update, but that was the last 91.x release and newer security fixes will not be released for it, specifically that high-impact CVE-2022-3033 information leak fixed with 102.2.1 is not adressed there. > This new version was known to bring incompatible changes to several > addons, I wasn't aware of that, I'm "only" doing the security updates, and the update to 102.2.0 didn't bring any such up. The releasenotes don't indicate such either: https://www.thunderbird.net/en-US/thunderbird/102.0/releasenotes/ https://www.thunderbird.net/en-US/thunderbird/102.1.0/releasenotes/ https://www.thunderbird.net/en-US/thunderbird/102.2.0/releasenotes/ Furthermore the 102.2.0 release isn't marked as "not as an upgrade from Thunderbird version 91 or earlier" anymore, which 102.0 and 102.1.0 were. > yet it has been submitted to a stable Fedora release with > autopush enable and just a karma threshold of 2. It took less than 5 > hours from the time the update was submitted to the time the update was > pushed to stable. I chose karma +2 because the past has shown that it rarely gets more votes in f36 and in f35 even less and thought that security updates shouldn't linger around more than necessary. > Package maintainers should put more attention when pushing critical > updates like this and avoid that the update being immediately pushed to > stable. Now, holding off only the 102.2.1 push with https://bodhi.fedoraproject.org/updates/FEDORA-2022-4fcde117f2 for f35 doesn't make sense with 102.2.0 already being in. If for Thunderbird a rebase really would need a FESCo exception then that seems to be a new handling for Thunderbird as also in the past there were rebases from for example 78.11.0 to 91.1.0 in stable f33/f34 (I wasn't involved with) when 78.x was discontinued. But this then seems to be a more general problem of how we want to support a switch an application from one ESR/LTS release if it is EOL to the next. Eike -- GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918 630B 6A6C D5B7 6563 2D3A 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
[Bug 2124002] perl-YAML-LibYAML-0.84 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2124002 Fedora Update System changed: What|Removed |Added Fixed In Version||perl-YAML-LibYAML-0.84-1.fc ||38 Resolution|--- |ERRATA Status|MODIFIED|CLOSED Last Closed||2022-09-05 13:02:07 --- Comment #2 from Fedora Update System --- FEDORA-2022-5974208c01 has been pushed to the Fedora 38 stable repository. If problem still persists, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2124002 ___ 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: rpm with sequoia pgp
Hi Dan, On Mon, 05 Sep 2022 14:18:05 +0200, Dan Čermák wrote: > "Neal H. Walfield" writes: > As Sequoia is written in Rust, what is your RISCV story? Fedora is (at > least that's my impression) a quite popular choice for RISCV boards, so > rpm working on RISCV would be crucial for us staying relevant. This is a valid concern, and one that I'm also worried about. According to this web page: https://fedoraproject.org/wiki/Architectures/RISC-V Fedora wants to support the RV64GC architecture, which I think corresponds to riscv64gc-unknown-linux-gnu. The Rust project indicates that riscv64gc-unknown-linux-gnu is a Tier 2 architecture: https://doc.rust-lang.org/nightly/rustc/platform-support.html FWIW, Fedora also supports armv7hl (armv7-unknown-linux-gnueabihf) and s390x-unknown-linux-gnu, which are also Tier 2 Rust architectures, but which have Rust packages: https://koji.fedoraproject.org/koji/buildinfo?buildID=1939157 So, I guess the bad news is that RISCV is not Tier 1, but the good news is that Tier 2 is already pretty good. Relatedly, I hear that Linux will start using Rust. I suspect that as that happens, a lot more resources will be invested in making sure Rust has good support on all of the platforms that Linux supports. Finally, rpm 4.18 will support both the internal OpenPGP parser and the Sequoia-based parser. So, if the Sequoia-based parser proves inadequate for some platforms (e.g., it doesn't compile or the test suite fails), Fedora can still fallback to the internal parser on that platforms. Note, though, that the internal OpenPGP parser is slated to be removed in 4.19: https://github.com/rpm-software-management/rpm/issues/1935 Neal ___ 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: Inactive packagers to be removed after the F37 release
On Monday, 05 September 2022 at 12:40, Vitaly Zaitsev via devel wrote: > On 05/09/2022 10:13, Dominik 'Rathann' Mierzejewski wrote: > > Wait, what? Which countries are 2FA token illegal in? > > Russia, China and all countries from the US export banlist. Do you have any references to articles of law or other regulations? Sorry, but this sounds so absurd I can't just take your word for it. Especially since for example Google's Titan Security Keys are made by a Chinese company Feitian[1][2]. [1] https://www.cnbc.com/2018/08/30/google-titan-made-by-chinese-company-feitian.html [2] https://www.zdnet.com/article/google-launches-titan-security-keys-but-recommends-keys-from-chinese-firm-with-military-links-in/ Regards, Dominik -- Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected 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
Re: rpm with sequoia pgp
On Mon, Sep 5, 2022 at 2:18 PM Dan Čermák wrote: > > Hi Neal, > > "Neal H. Walfield" writes: > > > Hi all, > > > > rpm 4.18 is on the horizon and includes a new OpenPGP backend based on > > Sequoia PGP. > > > > https://rpm.org/wiki/Releases/4.18.0 > > https://sequoia-pgp.org/ > > > > Thanks to Fabio Valentini (decathorpe) for packaging not only > > rpm-sequoia, but all of the Sequoia packages for Fedora. > > > > > > https://copr.fedorainfracloud.org/coprs/decathorpe/sequoia-test-builds/package/rust-rpm-sequoia/ > > As Sequoia is written in Rust, what is your RISCV story? Fedora is (at > least that's my impression) a quite popular choice for RISCV boards, so > rpm working on RISCV would be crucial for us staying relevant. I don't think architecture support is a problem. This might have been an issue when Rust was relatively new, but the list of supported targets is pretty big now: https://doc.rust-lang.org/nightly/rustc/platform-support.html For example, RISC-V (riscv64gc-unknown-linux-gnu) is supported by the Rust toolchain at the same level (Tier 2) as three other architectures we have (armv7hl / armv7-unknown-linux-gnueabihf, ppc64le / powerpc64le-unknown-linux-gnu, s390x / s390x-unknown-linux-gnu). Only x86 (x86_64-unknown-linux-gnu / i686-unknown-linux-gnu) and aarch64 (aarch64-unknown-linux-gnu) have better support (Tier 1). 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
[Bug 2124002] perl-YAML-LibYAML-0.84 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2124002 Fedora Update System changed: What|Removed |Added Status|ASSIGNED|MODIFIED --- Comment #1 from Fedora Update System --- FEDORA-2022-5974208c01 has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2022-5974208c01 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2124002 ___ 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: rpm with sequoia pgp
On Mon, 05 Sep 2022 10:12:23 +0200, Alexander Sosedkin wrote: > Mind the > https://docs.fedoraproject.org/en-US/packaging-guidelines/CryptoPolicies > > Will we need to introduce a configuration mechanism to limit algorithm > selection in Sequoia PGP? Or just wait untl it switches to OpenSSL? Good question. Sequoia has a flexible mechanism to describe its cryptographic policy: https://docs.sequoia-pgp.org/sequoia_openpgp/policy/struct.StandardPolicy.html There isn't yet a way to configure it using a configuration file, but that is doable. Here's the issue, fwiw: https://gitlab.com/sequoia-pgp/sequoia/-/issues/857 One potential issue is that OpenPGP fingerprints are computed using SHA-1. In practice this is not a security problem as fingerprints don't need collision resistance, just second pre-image resistance, which SHA-1 still has. The upcoming version of the OpenPGP specification specifies SHA2 256-based fingerprints https://datatracker.ietf.org/doc/html/draft-ietf-openpgp-crypto-refresh-06#section-5.5.4 But we won't be able to switch immediately: users would have to create new certificates, and old certificates would have to fall out of use. Neal ___ 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
perl-BSSolv license corrected
I corrected a license declaration in perl-BSSolv package from "GPL or Artistic" to "GPL-1.0-or-later OR Artistic-1.0-Perl". -- Petr 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
[Bug 2124002] perl-YAML-LibYAML-0.84 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2124002 Paul Howarth changed: What|Removed |Added Doc Type|--- |If docs needed, set a value Assignee|jples...@redhat.com |p...@city-fan.org Status|NEW |ASSIGNED -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2124002 ___ 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
Fedora 37 compose report: 20220905.n.0 changes
OLD: Fedora-37-20220904.n.0 NEW: Fedora-37-20220905.n.0 = SUMMARY = Added images:0 Dropped images: 0 Added packages: 0 Dropped packages:0 Upgraded packages: 0 Downgraded packages: 0 Size of added packages: 0 B Size of dropped packages:0 B Size of upgraded packages: 0 B Size of downgraded packages: 0 B Size change of upgraded packages: 0 B Size change of downgraded packages: 0 B = ADDED IMAGES = = DROPPED IMAGES = = ADDED PACKAGES = = DROPPED PACKAGES = = UPGRADED PACKAGES = = DOWNGRADED PACKAGES = ___ 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: rpm with sequoia pgp
Hi Neal, "Neal H. Walfield" writes: > Hi all, > > rpm 4.18 is on the horizon and includes a new OpenPGP backend based on > Sequoia PGP. > > https://rpm.org/wiki/Releases/4.18.0 > https://sequoia-pgp.org/ > > Thanks to Fabio Valentini (decathorpe) for packaging not only > rpm-sequoia, but all of the Sequoia packages for Fedora. > > > https://copr.fedorainfracloud.org/coprs/decathorpe/sequoia-test-builds/package/rust-rpm-sequoia/ As Sequoia is written in Rust, what is your RISCV story? Fedora is (at least that's my impression) a quite popular choice for RISCV boards, so rpm working on RISCV would be crucial for us staying relevant. Cheers, Dan ___ 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: Inactive packagers to be removed after the F37 release
Hi Mattia, We seem to be having the same conversation but with opposite interpretations :) I'll try to clarify my comments below. On Mon, Sep 5, 2022 at 9:25 AM Mattia Verga via devel < devel@lists.fedoraproject.org> wrote: > Il 05/09/22 08:59, Brian (bex) Exelbierd ha scritto: > > > > On Sat, Sep 3, 2022 at 9:24 PM Adam Williamson > wrote: > >> On Thu, 2022-08-18 at 17:28 -0400, Ben Cotton wrote: >> > Hello everyone! >> > >> > I just completed the first run of FESCo's newly approved Inactive >> > Packager Policy[1]. Packagers that have been identified as inactive >> > have a ticket in the find-inactive-packagers repo[2]. One week after >> > the F37 final release, packagers who remain inactive will be removed >> > from the packager group. (Note that pagure.io is one of the systems >> > checked for activity, so commenting on your ticket that you're still >> > around will prevent you from showing up in the second round.) >> >> So, I have a probably-controversial idea for a follow-up on this. >> > > I'll add one more idea/loophole to consider closing. I am a member of the > packager group but no longer maintain any packages. I am active enough in > other ways to not be noticed by this policy. I don't think that is right. > > I'm sorry for that. The script currently searches for user activity in > src.fp.o, pagure.io, Bodhi, Bugzilla and Fedora mailing lists. Can you > tell me where you're active, so, maybe, I can add that place in the search > pattern? > I am in the packager group. I have no packages. I have activity in BZ, Fedora mailing lists, etc. However, I believe the script should flag me for removal from the packager group because I do not have commit rights to any package and am not a proven packager. regards, bex I have submitted a ticket to voluntarily give up my packager rights under > this policy. However, we should probably verify that a packager actually > has at least one package or is a proven packager as a part of this policy. > I realize that it is very hard to know how long someone has not had any > packages, so this could result in a request to validate to a person who is > temporarily without a package during the period when the script is run, > however I think this is a reasonable edge case to resolve manually. > > regards, > > bex > > I don't agree with that. If a user haven't got any commit right to any > package, they don't need to be in the packager group, that's exactly the > scope of this policy. Maybe they left years ago, their commit rights were > removed, but they never have been removed from packagers. > > Mattia > ___ > 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 > -- Don't rush to reply to this email. Enjoy work/life balance. I read email once a day and am in the CE(S)T timezone. If you have an urgent email, ping me, and consider other mediums for urgent messages in the future. Brian "bex" Exelbierd (he/him/his) Business Strategist for Communities and Developers Red Hat Enterprise Linux @bexelbie | http://www.winglemeyer.org bexel...@redhat.com ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Orphaned packages looking for new maintainers
fortune-mod says "Orphaned for: Orphaned by releng" , which user was considered unresponsive ? Where I can find the tickets of unresponsive maintainer ? Thank you On Mon, 2022-09-05 at 12:36 +0200, Miro Hrončok wrote: > The following packages are orphaned and will be retired when they > are orphaned for six weeks, unless someone adopts them. If you know > for sure > that the package should be retired, please do so now with a proper > reason: > https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life > > Note: If you received this mail directly you (co)maintain one of the > affected > packages or a package that depends on one. Please adopt the affected > package or > retire your depending package to avoid broken dependencies, otherwise > your > package will fail to install and/or build when the affected package > gets retired. > > Request package ownership via the *Take* button in he left column on > https://src.fedoraproject.org/rpms/ > > Full report available at: > https://churchyard.fedorapeople.org/orphans-2022-09-05.txt > grep it for your FAS username and follow the dependency chain. > > For human readable dependency chains, > see https://packager-dashboard.fedoraproject.org/ > For all orphaned packages, > see https://packager-dashboard.fedoraproject.org/orphan > > Package (co)maintainers > Status Change > = > === > abduco dfateyev, orphan 0 > weeks ago > bumpversion jdornak, orphan 0 > weeks ago > clinfo orphan 0 > weeks ago > colm jtaylor, lorbus, orphan 0 > weeks ago > ell orphan 0 > weeks ago > espresso-ab avigne, orphan 0 > weeks ago > fortune-mod epel-packagers-sig, orphan, 0 > weeks ago > sergiomb, shlomif > geteltorito orphan 0 > weeks ago > gimp-focusblur-plugin orphan 0 > weeks ago > git-archive-all orphan 0 > weeks ago > git-fame fale, ignatenkobrain, orphan 0 > weeks ago > git-lab-porcelain orphan 3 > weeks ago > gmqcc orphan 0 > weeks ago > hct avigne, orphan 0 > weeks ago > httrack cicku, fale, orphan 0 > weeks ago > ipsilon orphan, puiterwijk, simo 2 > weeks ago > kelbt orphan 0 > weeks ago > libmaxminddb jtaylor, mruprich, orphan 0 > weeks ago > libtoml orphan 0 > weeks ago > libtvdb orphan 1 > weeks ago > mcpanel orphan 0 > weeks ago > metapixel orphan 1 > weeks ago > mirrorlist-server adrian, orphan, rust-sig 0 > weeks ago > monobristol orphan 0 > weeks ago > mozilla-https-everywhere orphan, rathann 1 > weeks ago > novacom-client orphan 2 > weeks ago > novacom-server orphan 2 > weeks ago > nsca-ng orphan 0 > weeks ago > origin go-sig, orphan, tdawson 0 > weeks ago > parzip orphan 0 > weeks ago > perl-BSSolv ngompa, orphan 0 > weeks ago > perl-Parse-Debian-Packages orphan 0 > weeks ago > php-psr-http-client orphan 0 > weeks ago > pidgin-save-conv-order orphan 1 > weeks ago > python-aiofiles orphan 0 > weeks ago > python-aioodbc orphan 0 > weeks ago > python-aiorpcx jonny, orphan 0 > weeks ago > python-argopt orphan 0 > weeks ago > python-arpy bochecha, orphan, python-sig 0 > weeks ago > python-august orphan 2 > weeks ago > python-bitstruct orphan 2 > weeks ago > python-calligrabot merlinm, orphan
jwm license change
jwm-2.4.2 in Fedora-rawhide changed its license from GPLv2 to MIT -- Ali Erdinc Koroglu Linux OS Systems Engineering - Intel Finland Oy Registered Address: PL 281, 00181 Helsinki Business Identity Code: 0357606 - 4 Domiciled in Helsinki This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. ___ 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 2124241] New: perl-PAR-Packer-1.056 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2124241 Bug ID: 2124241 Summary: perl-PAR-Packer-1.056 is available Product: Fedora Version: rawhide Status: NEW Component: perl-PAR-Packer Keywords: FutureFeature, Triaged Assignee: jples...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: anon.am...@gmail.com, jples...@redhat.com, mmasl...@redhat.com, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Releases retrieved: 1.056 Upstream release that is considered latest: 1.056 Current version/release in rawhide: 1.055-2.fc37 URL: http://search.cpan.org/dist/PAR-Packer/ 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://fedoraproject.org/wiki/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/3189/ To change the monitoring settings for the project, please visit: https://src.fedoraproject.org/rpms/perl-PAR-Packer -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2124241 ___ 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 2123496] perl-Verilog-Perl-3.480 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2123496 --- Comment #1 from Fedora Update System --- FEDORA-2022-a693cec74a has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2022-a693cec74a -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2123496 ___ 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: Adding Package to side-tag
On Sun, 2022-09-04 at 17:18 -0700, Kevin Fenzi wrote: > On Sat, Sep 03, 2022 at 08:32:47PM +1000, Frank Crawford wrote: > > > > The document I used > > was https://docs.fedoraproject.org/en-US/package- > > maintainers/Package_Update_Guide/#multiple_packages > > > > It was the only place I could find that really talked about side- > > tags, > > and wait-repo looks only mentioned in passing. Once you know it is > > needed it is more obvious, but not if you haven't used them much > > before. > > Well, it does say: > > "The latter is important if any builds depend on previous ones in the > side tag. > Use koji wait-repo --build to ensure that > the respective > build is available in the build root for subsequent builds. " > > But if you can see a way to be more clear there, perhaps you could > put > in a PR? I'll see what I can do, but the issue is more about understanding what is happening in the background than just the wording. Now seeing it fail it is obvious that each side-tag has its own repo, and this is waiting for it to be created, but prior to sitting back and thinking what has to go on the term "wait-repo" is just an extra step. What seems to be really missing is some details of what is happening in the background rather than a list of commands that are important. As I said earlier, there seems to be very little documentation anywhere, on what a side-tag actually is, or what it does. Naively, I assumed just added an extra tag, and that is all. > kevin Regards Frank ___ 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: Inactive packagers to be removed after the F37 release
> > However, last this was discussed, the Fedora AAA system(s) > > did not (yet?) support the full fido2/webauthn/passkey > > functionality, so at this time such full integration is just a > > dream(*). > > You don't have to be a provenpackager to be able to do serious damage; > you just need to maintain one package that's installed by a > sufficiently-interesting quantity of Fedora users. In the long run, we > should be moving to require WebAuthn for all Fedora > authentication-related purposes, since it's unphishable. Last year I > entered my GitHub password into a phishing page that was proxying the > real GitHub... if the evil page had gone to just slightly more effort, > it could have easily intercepted a simple TOTP/HOTP challenge. This is > not possible with WebAuthn, which I would say actually is pretty much > equivalent to a security magic bullet. > > That said, I say this keenly aware that WebKitGTK doesn't support > WebAuthn yet, and I would be interacting with Fedora packaging a lot > less if I couldn't use my normal web browser. And anybody who isn't > willing to buy a security key wouldn't be able to contribute to Fedora > at all. But webauthn and 2FA only stops someone else from compromising my account, it would probably be easier to join and become a packager by packaging a random leaf package no one would use, then as a packager pick up an random orphaned package that's in the core distro and then just compromise the distro that way TBH. 2FA won't stop that as they can just setup an actual 2FA token for their packaging account. ___ 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: Orphaned packages looking for new maintainers
> tasksh orphan 0 weeks ago Taken tasksh over to begin with. Co-maintainers welcome. -- 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: rpm with sequoia pgp
Hi Paul, Thanks for your comments. On Fri, 02 Sep 2022 20:21:21 +0200, Paul Wouters wrote: > On Fri, 2 Sep 2022, Neal H. Walfield wrote: > > > Note: Sequoia currently uses Nettle on Fedora, but there is ongoing > > work to port it to Sequoia to OpenSSL: > > I think this should be considered a blocker for changing gpg backends. That's a decision for Fedora. I have no strong preference. (For what it's worth, rpm doesn't use gpg. rpm has an internal OpenPGP backend, which was developed in house.) > > > > https://github.com/rpm-software-management/rpm/issues/2041#issuecomment-1219175000 > > > > Note2: There are lots of reasons to use Sequoia, but one user-visible > > reason is improved usability. When a user imports a certificate, > > Sequoia lints it and displays potential issues, or reasons why it > > can't be imported: > > > > > > https://github.com/rpm-software-management/rpm/issues/1974#issuecomment-1081779174 > > > > $ rpm --import peter-expired-backsig.pgp > > Certificate 251C20A67D942D45: > >Policy rejects subkey CB4F47D30C8C9CE1: Expired on 2020-05-08T05:11:51Z > >Certificate does not have any usable signing keys > > > > Whereas before rpm would just say: > > > > error: peter-expired-backsig.pgp: key 1 import failed. > > That seems like a fairly minor point to change backends and crypto > library for and could be something that can be fixed in the current > backend as well? I spent some time looking at and trying to improve rpm's OpenPGP implementation. It's quite hairy. See, for example, this issue: https://github.com/rpm-software-management/rpm/issues/2004 Even Panu (rpm's maintainer) does not have great confidence in the OpenPGP parser's robustness: I think the only safe assumption is to assume it a bug in rpm's parser. Shock horror :laughing: https://github.com/rpm-software-management/rpm/issues/2004#issuecomment-1096286416 If you want to have a look at the code, here's a good place to start: https://github.com/rpm-software-management/rpm/blob/d703160/rpmio/rpmpgp_internal.c#L965 I suspect that this hairiness is because the internal OpenPGP parser started as a minimal implementation to handle data generated by GnuPG when it was written about 20 years ago. Panu writes: https://github.com/rpm-software-management/rpm/pull/1813#discussion_r790681223 the rpm implementation strives to do the bare minimum to get by https://github.com/rpm-software-management/rpm/issues/1978#issuecomment-1080606598 The current "API" is ad-hoc stuff added over the course of 20 years, by people with not much OpenPGP experience. I'm sure it shows. And, over time it has grown in complexity to accommodate new requirements, like support for RFC 4880, and subkeys. Whatever the case, Panu doesn't want to invest more time into it: https://github.com/rpm-software-management/rpm/issues/1935 There's something seriously wrong when a significant percent of package manager development discussions is about OpenPGP specification and its interpretation in the RPM context. This is negatively impacting development of RPM "core business", to the point that this has to stop. There's exactly one way to stop it, and that's getting rid of the internal parser, one way or the other. Targeted for RPM 4.19 in 2023, and this also means that no major developments to the existing parser should be done, from here on it's strictly in critical fixes only -mode. Those are reasons against the internal OpenPGP implementation. But, I also want to briefly say why I (a co-founder of the Sequoia project), think that Sequoia is a good choice. In Sequoia we've spent a lot of time trying to get the little details right. In particular, we invested a lot of effort in certificate canonicalization, which is essential to making sure OpenPGP certificates are interpreted in a sane way. There is a nice write up of why this is hard by the author of PGPainless: https://blog.jabberhead.tk/2021/04/03/why-signature-verification-in-openpgp-is-hard/ When I first thought about signature verification in OpenPGP I thought “well, it cannot be that hard, right?”. In the end all you got to do is check if a signature was made by the given key and if that signature checks out (is cryptographically correct). Oh boy, was I wrong. (For the haters: yes, OpenPGP is complicated, but I suspect this type of complexity will be present in some form of another is all PKIs that support expirations, revocations, etc.) It's due to this infrastructure that Sequoia is so often able to return informative error messages that go to the root cause of the problem. While developing Sequoia, we didn't just rely on our interpretation of the RFC. We also looked at what other implementations were doing and tried to push the whole ecosystem forward. This is demonstrated through Justus' work on the OpenPGP interoperability test suite: https://tests.sequoia-pgp.org/ Please share any
Re: Inactive packagers to be removed after the F37 release
On 05/09/2022 10:33, Tommy Nguyen wrote: I cannot think of any reason why 2FA would be illegal in any country when TOTP is based on HMAC and by default uses SHA-1. In some countries (eg. Russia, China) all cryptographic devices must be certified by local government security service. Further if I may offer my unsolicited opinion, I am strongly in favor in requiring 2FA. Who will pay for these devices? Red Hat? Gnome Foundation? Most maintainers won't be happy to spend $50 on a hobby project. There's been too many supply chain incidents (see npm, github, any corporate data breach, et al.) that I think Fedora would benefit from mandating 2FA. For 15 years, there hasn't been a single incident with Fedora. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ 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: Inactive packagers to be removed after the F37 release
On 05/09/2022 10:13, Dominik 'Rathann' Mierzejewski wrote: Wait, what? Which countries are 2FA token illegal in? Russia, China and all countries from the US export banlist. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ 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
Orphaned packages looking for new maintainers
The following packages are orphaned and will be retired when they are orphaned for six weeks, unless someone adopts them. If you know for sure that the package should be retired, please do so now with a proper reason: https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life Note: If you received this mail directly you (co)maintain one of the affected packages or a package that depends on one. Please adopt the affected package or retire your depending package to avoid broken dependencies, otherwise your package will fail to install and/or build when the affected package gets retired. Request package ownership via the *Take* button in he left column on https://src.fedoraproject.org/rpms/ Full report available at: https://churchyard.fedorapeople.org/orphans-2022-09-05.txt grep it for your FAS username and follow the dependency chain. For human readable dependency chains, see https://packager-dashboard.fedoraproject.org/ For all orphaned packages, see https://packager-dashboard.fedoraproject.org/orphan Package (co)maintainersStatus Change abduco dfateyev, orphan0 weeks ago bumpversionjdornak, orphan 0 weeks ago clinfo orphan 0 weeks ago colm jtaylor, lorbus, orphan 0 weeks ago ellorphan 0 weeks ago espresso-abavigne, orphan 0 weeks ago fortune-modepel-packagers-sig, orphan, 0 weeks ago sergiomb, shlomif geteltoritoorphan 0 weeks ago gimp-focusblur-plugin orphan 0 weeks ago git-archive-allorphan 0 weeks ago git-fame fale, ignatenkobrain, orphan0 weeks ago git-lab-porcelain orphan 3 weeks ago gmqcc orphan 0 weeks ago hctavigne, orphan 0 weeks ago httrackcicku, fale, orphan 0 weeks ago ipsilonorphan, puiterwijk, simo2 weeks ago kelbt orphan 0 weeks ago libmaxminddb jtaylor, mruprich, orphan 0 weeks ago libtomlorphan 0 weeks ago libtvdborphan 1 weeks ago mcpanelorphan 0 weeks ago metapixel orphan 1 weeks ago mirrorlist-server adrian, orphan, rust-sig0 weeks ago monobristolorphan 0 weeks ago mozilla-https-everywhere orphan, rathann 1 weeks ago novacom-client orphan 2 weeks ago novacom-server orphan 2 weeks ago nsca-ngorphan 0 weeks ago origin go-sig, orphan, tdawson 0 weeks ago parzip orphan 0 weeks ago perl-BSSolvngompa, orphan 0 weeks ago perl-Parse-Debian-Packages orphan 0 weeks ago php-psr-http-clientorphan 0 weeks ago pidgin-save-conv-order orphan 1 weeks ago python-aiofilesorphan 0 weeks ago python-aioodbc orphan 0 weeks ago python-aiorpcx jonny, orphan 0 weeks ago python-argopt orphan 0 weeks ago python-arpybochecha, orphan, python-sig0 weeks ago python-august orphan 2 weeks ago python-bitstruct orphan 2 weeks ago python-calligrabot merlinm, orphan 2 weeks ago python-colanderinfra-sig, lmacken, orphan, ralph 0 weeks ago python-coreapi orphan 0 weeks ago python-coreschema orphan 0 weeks ago python-cu2qu orphan 2 weeks ago python-daemonize orphan 0 weeks ago python-devtoolsorphan
Re: Users with commit rights in src.fp.o but no more in packager group
On 05. 09. 22 11:07, Vít Ondruch wrote: Apart from that, I don't think that the pseudo-users or group ownership would work. I saw a good amount of people giving the packages to some groups or pseudo-users, but in turn, that meant there is nobody who would care about such package. +100 -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ 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 2124001] perl-Proc-Fork-0.808 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2124001 Jitka Plesnikova changed: What|Removed |Added Status|NEW |ASSIGNED CC|jples...@redhat.com | Doc Type|--- |If docs needed, set a value -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2124001 ___ 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 2123496] perl-Verilog-Perl-3.480 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2123496 Jitka Plesnikova changed: What|Removed |Added Fixed In Version||perl-Verilog-Perl-3.480-1.f ||c38 Status|ASSIGNED|MODIFIED -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2123496 ___ 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: Inactive packagers to be removed after the F37 release
On Mon, Sep 05, 2022 at 08:33:40AM +, Tommy Nguyen wrote: > On Mon, 2022-09-05 at 10:13 +0200, Dominik 'Rathann' Mierzejewski > wrote: > > Wait, what? Which countries are 2FA token illegal in? > > > > Regards, > > Dominik > > I cannot think of any reason why 2FA would be illegal in any country > when TOTP is based on HMAC and by default uses SHA-1. > > Further if I may offer my unsolicited opinion, I am strongly in favor > in requiring 2FA. And if doing it across the board is inconvenient, at > least for "important" packages/roles. > > There's been too many supply chain incidents (see npm, github, any > corporate data breach, et al.) that I think Fedora would benefit from > mandating 2FA. Those who've been around a long time will remember that we've discovered compromises of a Fedora maintainer's account in the past: https://lwn.net/Articles/424484/ Out of an abundance of caution / paranoia, we even later went as far as to force a mass password change and new SSH key creation across all our maintainers: https://lists.fedoraproject.org/pipermail/devel-announce/2011-October/000840.html We got lucky back in 2011 that the impact was not too bad, but luck runs out eventually, so 2fa for maintainers has clear benefits in reducing risk to Fedora and its consumers. With regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| ___ 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] Re: EPEL2RHEL - New Wording? - New Workflow?
On Friday, 02 September 2022 at 18:25, Kevin Fenzi wrote: > On Thu, Sep 01, 2022 at 12:12:07PM -0500, Maxwell G via epel-devel wrote: > > On Wednesday, August 31, 2022 Troy Dawson wrote: > > > EPEL2RHEL is part of the RHEL 8 and 9 new package workflow. When a RHEL > > > maintainer wants to add a package to RHEL 8 or 9 they start a "new package > > > workflow". There are several automations that happen when they start that > > > workflow. One of them is checking if the package is already in epel. If > > > it is, it creates a bugzilla against that package, and links that bug > > > against the EPEL2RHEL tracker. [1] > > > Remember, this check currently happens at the beginning of the new package > > > workflow. Before a package has been branched, built, or put into testing > > > repos. > > > > I think this whole process should be automated. File bugs that say "Heads > > up: > > your package will be automatically retired after the release of RHEL X.X" > > and > > provide some explanation. This will have multiple benefits: > > > > 1. Saying "you'll have to do something in six months, but it'll be bad if > > you > > do it now" is quite difficult to follow. > > > > 2. We can send out one announcement to epel-announce about which packages > > are > > going to be retired and when that'll happen, instead of retiring packages > > in a > > piecemeal manner. > > > > 3. The maintainers won't have to remember to do it. > > > > 4. If we find out that a package is buildroot only, then we'll close the > > bug > > and exclude it from the automatic retiring. > > I really like this approach... :) It would be really nice if the wording of the bug could contain some kind of a "thank you" note to the EPEL maintainers of the package in question. Not everyone will understand this process as "great, I don't have to maintain package X anymore, Red Hat will be doing that for me from now on". Some folks may take it as "Oh no! Red Hat is taking away my toy! Why?!" Ideally, there should still be a way for EPEL maintainer(s) to continue contributing to the RHEL package. Regards, Dominik -- Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan ___ 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] Fedora EPEL 8 updates-testing report
The following Fedora EPEL 8 Security updates need testing: Age URL 47 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-89ad385971 chromium-103.0.5060.114-1.el8 2 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-83ed996f1e rubygem-rack-2.2.4-1.el8 0 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-ebbc78f3cb libapreq2-2.17-1.el8 The following builds have been pushed to Fedora EPEL 8 updates-testing mold-1.4.2-1.el8 mup-7.0-1.el8 Details about builds: mold-1.4.2-1.el8 (FEDORA-EPEL-2022-a941d2abcf) A Modern Linker Update Information: Bump version to 1.4.2 ChangeLog: * Sun Sep 4 2022 Christoph Erhardt - 1.4.2-1 - Bump version to 1.4.2 - Refresh patch mup-7.0-1.el8 (FEDORA-EPEL-2022-8a71d776ba) A music notation program that can also generate MIDI files Update Information: Update to 7.0 ChangeLog: * Sun Sep 4 2022 Greg Bailey - 7.0-1 - Update to 7.0 - noteleft string - mensural symbols and centered stems - improved measuration time signature sizing when used with printedtime - expression eval macros - string() function - shapes context * Fri Jul 22 2022 Fedora Release Engineering - 6.7-7 - Rebuilt for https://fedoraproject.org/wiki/Fedora_37_Mass_Rebuild * Thu Jan 20 2022 Fedora Release Engineering - 6.7-6 - Rebuilt for https://fedoraproject.org/wiki/Fedora_36_Mass_Rebuild * Thu Jul 22 2021 Fedora Release Engineering - 6.7-5 - Rebuilt for https://fedoraproject.org/wiki/Fedora_35_Mass_Rebuild * Tue Jan 26 2021 Fedora Release Engineering - 6.7-4 - Rebuilt for https://fedoraproject.org/wiki/Fedora_34_Mass_Rebuild * Tue Jul 28 2020 Fedora Release Engineering - 6.7-3 - Rebuilt for https://fedoraproject.org/wiki/Fedora_33_Mass_Rebuild * Wed Jan 29 2020 Fedora Release Engineering - 6.7-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild ___ 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] Fedora EPEL 7 updates-testing report
The following Fedora EPEL 7 Security updates need testing: Age URL 0 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-b86f845eb8 libapreq2-2.17-1.el7 The following builds have been pushed to Fedora EPEL 7 updates-testing mup-7.0-1.el7 Details about builds: mup-7.0-1.el7 (FEDORA-EPEL-2022-0cb0fe56f9) A music notation program that can also generate MIDI files Update Information: Update to 7.0 ChangeLog: * Sun Sep 4 2022 Greg Bailey - 7.0-1 - Update to 7.0 - noteleft string - mensural symbols and centered stems - improved measuration time signature sizing when used with printedtime - expression eval macros - string() function - shapes context * Fri Jul 22 2022 Fedora Release Engineering - 6.7-7 - Rebuilt for https://fedoraproject.org/wiki/Fedora_37_Mass_Rebuild * Thu Jan 20 2022 Fedora Release Engineering - 6.7-6 - Rebuilt for https://fedoraproject.org/wiki/Fedora_36_Mass_Rebuild * Thu Jul 22 2021 Fedora Release Engineering - 6.7-5 - Rebuilt for https://fedoraproject.org/wiki/Fedora_35_Mass_Rebuild * Tue Jan 26 2021 Fedora Release Engineering - 6.7-4 - Rebuilt for https://fedoraproject.org/wiki/Fedora_34_Mass_Rebuild * Tue Jul 28 2020 Fedora Release Engineering - 6.7-3 - Rebuilt for https://fedoraproject.org/wiki/Fedora_33_Mass_Rebuild * Wed Jan 29 2020 Fedora Release Engineering - 6.7-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild ___ 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] Fedora EPEL 9 updates-testing report
The following builds have been pushed to Fedora EPEL 9 updates-testing mold-1.4.2-1.el9 mup-7.0-1.el9 Details about builds: mold-1.4.2-1.el9 (FEDORA-EPEL-2022-1dd1cd73e4) A Modern Linker Update Information: Bump version to 1.4.2 ChangeLog: * Sun Sep 4 2022 Christoph Erhardt - 1.4.2-1 - Bump version to 1.4.2 - Refresh patch mup-7.0-1.el9 (FEDORA-EPEL-2022-526c3fb1aa) A music notation program that can also generate MIDI files Update Information: Update to 7.0 ChangeLog: * Sun Sep 4 2022 Greg Bailey - 7.0-1 - Update to 7.0 - noteleft string - mensural symbols and centered stems - improved measuration time signature sizing when used with printedtime - expression eval macros - string() function - shapes context ___ 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 2102581] Add perl-SQL-Abstract to EPEL9
https://bugzilla.redhat.com/show_bug.cgi?id=2102581 Fedora Update System changed: What|Removed |Added Status|ASSIGNED|MODIFIED --- Comment #5 from Fedora Update System --- FEDORA-EPEL-2022-670c12c809 has been submitted as an update to Fedora EPEL 9. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-670c12c809 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2102581 ___ 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: Users with commit rights in src.fp.o but no more in packager group
Dne 03. 09. 22 v 22:28 Kevin Fenzi napsal(a): On Sat, Sep 03, 2022 at 02:01:59PM +, Mattia Verga via devel wrote: Il 26/08/22 07:17, David Tardon ha scritto: Hi, On Thu, 2022-08-25 at 11:04 +0300, Alexander Bokovoy wrote: On to, 25 elo 2022, Miro Hrončok wrote: We use the python-maint pseudo-account to be the default Bugzilla assignee for Pythons, e.g. https://src.fedoraproject.org/rpms/python3.11 Note that it does *not* require the account to be listed in maintainers or to have commit rights. Same for ipa-maint account. Same for systemd-maint and dracut-maint. D. So... wouldn't be better to have a consistent way across all packages to deal with these cases? Sure, but Fedora has been around for many years, accross a bunch of differnt applications and these things have never been completly set. :( What's better, a pseudo-user to be the main-admin of a package, or a real user to be the main-admin and just add the pseudo-user as the default assignee of bugs? What is the difference between pseudo-users and groups? The group membership management is certainly PITA, because group members cannot e.g. remove the group from retired packages: https://pagure.io/releng/issue/10954 Apart from that, I don't think that the pseudo-users or group ownership would work. I saw a good amount of people giving the packages to some groups or pseudo-users, but in turn, that meant there is nobody who would care about such package. Vít We discussed this back when we switched from pkgdb to pagure-dist-git some. One thought at the time was that we make every package use a pseutouser for main-admin, but there's downsides to that too. On the plus side it would allow us to get rid of 'main admin'. Who owns the credentials of those pseudo-users? Also, Fedora Accounts user pages links to non-existent wiki pages... it would be nice to have a description about them (if there's a consensus of continue listing them as main-admin). Many of them the group using them has the credentials, or no one at all. I'm not sure it's possible to get them all sorted, but I agree at least a wiki page with info on them would be good to have at the very least. kevin ___ 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 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
Re: rpm with sequoia pgp
On Mon, Sep 5, 2022 at 10:55 AM Fabio Valentini wrote: > > On Mon, Sep 5, 2022 at 10:12 AM Alexander Sosedkin > wrote: > > > > Quoting Neal H. Walfield (2022-09-02 16:31:18) > > > rpm 4.18 is on the horizon and includes a new OpenPGP backend based on > > > Sequoia PGP. > > > > > > https://rpm.org/wiki/Releases/4.18.0 > > > https://sequoia-pgp.org/ > > > > > > Thanks to Fabio Valentini (decathorpe) for packaging not only > > > rpm-sequoia, but all of the Sequoia packages for Fedora. > > > > > > > > > https://copr.fedorainfracloud.org/coprs/decathorpe/sequoia-test-builds/package/rust-rpm-sequoia/ > > > > > > > > > With this note, I'd firstly like to make the Fedora community more > > > aware of this project. (I don't think it has been mentioned here > > > yet.) > > > > > > Second, although the internal OpenPGP backend is still the default > > > backend, it will be removed in rpm 4.19: > > > > > > https://github.com/rpm-software-management/rpm/issues/1935 > > > > > > It is probably best to start the transition as soon as possible to > > > work out any kinks. > > > > > > In that vein, I'd like to offer my help. Making this type of change > > > needs to be done carefully. Perhaps these are questions or concerns. > > > I'd like to hear them and respond to them. There is also technical > > > work that needs to be done. I'm more of a developer than a packager, > > > but if Fedora decides to use the Sequoia backend, I'd like to offer my > > > help in any way I can. > > > > > > > > > > > > Note: Sequoia currently uses Nettle on Fedora, but there is ongoing > > > work to port it to Sequoia to OpenSSL: > > > > > > > > > https://github.com/rpm-software-management/rpm/issues/2041#issuecomment-1219175000 > > > > Mind the > > https://docs.fedoraproject.org/en-US/packaging-guidelines/CryptoPolicies > > > > Will we need to introduce a configuration mechanism to limit algorithm > > selection in Sequoia PGP? Or just wait untl it switches to OpenSSL? > > Isn't this handled at the level of the crypto library? That's my question, really: does it need extra configuration generated or will it just attempt a low-level library operation and fail gracefully when it finds the operations blocked? > OpenPGP uses nettle for cryptography purposes, shouldn't *that* follow > system crypto policy, just as OpenSSL does? > For example, I don't see anything related to crypto policies in the > gnupg2 package, either. Unfortunately, nettle and gnupg2 don't follow crypto-policies (yet?). It's only beginning to expand beyond networking protocols (TLS/SSH/KRB...). ___ 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: rpm with sequoia pgp
On Mon, Sep 5, 2022 at 10:12 AM Alexander Sosedkin wrote: > > Quoting Neal H. Walfield (2022-09-02 16:31:18) > > rpm 4.18 is on the horizon and includes a new OpenPGP backend based on > > Sequoia PGP. > > > > https://rpm.org/wiki/Releases/4.18.0 > > https://sequoia-pgp.org/ > > > > Thanks to Fabio Valentini (decathorpe) for packaging not only > > rpm-sequoia, but all of the Sequoia packages for Fedora. > > > > > > https://copr.fedorainfracloud.org/coprs/decathorpe/sequoia-test-builds/package/rust-rpm-sequoia/ > > > > > > With this note, I'd firstly like to make the Fedora community more > > aware of this project. (I don't think it has been mentioned here > > yet.) > > > > Second, although the internal OpenPGP backend is still the default > > backend, it will be removed in rpm 4.19: > > > > https://github.com/rpm-software-management/rpm/issues/1935 > > > > It is probably best to start the transition as soon as possible to > > work out any kinks. > > > > In that vein, I'd like to offer my help. Making this type of change > > needs to be done carefully. Perhaps these are questions or concerns. > > I'd like to hear them and respond to them. There is also technical > > work that needs to be done. I'm more of a developer than a packager, > > but if Fedora decides to use the Sequoia backend, I'd like to offer my > > help in any way I can. > > > > > > > > Note: Sequoia currently uses Nettle on Fedora, but there is ongoing > > work to port it to Sequoia to OpenSSL: > > > > > > https://github.com/rpm-software-management/rpm/issues/2041#issuecomment-1219175000 > > Mind the > https://docs.fedoraproject.org/en-US/packaging-guidelines/CryptoPolicies > > Will we need to introduce a configuration mechanism to limit algorithm > selection in Sequoia PGP? Or just wait untl it switches to OpenSSL? Isn't this handled at the level of the crypto library? OpenPGP uses nettle for cryptography purposes, shouldn't *that* follow system crypto policy, just as OpenSSL does? For example, I don't see anything related to crypto policies in the gnupg2 package, either. 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: Inactive packagers to be removed after the F37 release
On Mon, 2022-09-05 at 10:13 +0200, Dominik 'Rathann' Mierzejewski wrote: > Wait, what? Which countries are 2FA token illegal in? > > Regards, > Dominik I cannot think of any reason why 2FA would be illegal in any country when TOTP is based on HMAC and by default uses SHA-1. Further if I may offer my unsolicited opinion, I am strongly in favor in requiring 2FA. And if doing it across the board is inconvenient, at least for "important" packages/roles. There's been too many supply chain incidents (see npm, github, any corporate data breach, et al.) that I think Fedora would benefit from mandating 2FA. ___ 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: Inactive packagers to be removed after the F37 release
On Monday, 05 September 2022 at 09:16, Vitaly Zaitsev via devel wrote: > On 04/09/2022 19:30, Michael Catanzaro wrote: > > And anybody who isn't willing to buy a security key wouldn't be able to > > contribute to Fedora at all. > > So, you want to ban all contributors from countries where such tokens are > prohibited, am I right? Strongly -1. Wait, what? Which countries are 2FA token illegal in? Regards, Dominik -- Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected 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
Re: rpm with sequoia pgp
Quoting Neal H. Walfield (2022-09-02 16:31:18) > rpm 4.18 is on the horizon and includes a new OpenPGP backend based on > Sequoia PGP. > > https://rpm.org/wiki/Releases/4.18.0 > https://sequoia-pgp.org/ > > Thanks to Fabio Valentini (decathorpe) for packaging not only > rpm-sequoia, but all of the Sequoia packages for Fedora. > > > https://copr.fedorainfracloud.org/coprs/decathorpe/sequoia-test-builds/package/rust-rpm-sequoia/ > > > With this note, I'd firstly like to make the Fedora community more > aware of this project. (I don't think it has been mentioned here > yet.) > > Second, although the internal OpenPGP backend is still the default > backend, it will be removed in rpm 4.19: > > https://github.com/rpm-software-management/rpm/issues/1935 > > It is probably best to start the transition as soon as possible to > work out any kinks. > > In that vein, I'd like to offer my help. Making this type of change > needs to be done carefully. Perhaps these are questions or concerns. > I'd like to hear them and respond to them. There is also technical > work that needs to be done. I'm more of a developer than a packager, > but if Fedora decides to use the Sequoia backend, I'd like to offer my > help in any way I can. > > > > Note: Sequoia currently uses Nettle on Fedora, but there is ongoing > work to port it to Sequoia to OpenSSL: > > > https://github.com/rpm-software-management/rpm/issues/2041#issuecomment-1219175000 Mind the https://docs.fedoraproject.org/en-US/packaging-guidelines/CryptoPolicies Will we need to introduce a configuration mechanism to limit algorithm selection in Sequoia PGP? Or just wait untl it switches to OpenSSL? > ... ___ 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 2102597] Add perl-DBIx-Class to EPEL 9
https://bugzilla.redhat.com/show_bug.cgi?id=2102597 Fedora Update System changed: What|Removed |Added Status|ASSIGNED|MODIFIED --- Comment #2 from Fedora Update System --- FEDORA-EPEL-2022-670c12c809 has been submitted as an update to Fedora EPEL 9. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-670c12c809 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2102597 ___ 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
Review request: python-qt6
Hi I've put up python-qt6 for review: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2124098 Happy to review in exchange. Thanks Sandro ___ 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 2123496] perl-Verilog-Perl-3.480 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2123496 Jitka Plesnikova changed: What|Removed |Added CC|chitl...@gmail.com, | |jples...@redhat.com | Doc Type|--- |If docs needed, set a value Status|NEW |ASSIGNED -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2123496 ___ 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
Heads-up: OpenSSL sync with RHEL
Dear colleagues, I'm going to push the updated version of OpenSSL to rawhide. This version incorporates FIPS-related changes from RHEL 9. A major change that may affect your applications in FIPS mode is limiting the RSA encryption. There are also minor tweaks limiting explicit curves support in a similar way as it is done in RHEL. -- Dmitry Belyavskiy ___ 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: Inactive packagers to be removed after the F37 release
Il 05/09/22 08:55, Douglas Kosovic ha scritto: > On Sun, Sep 4, 2022 at 1:38 PM Mattia Verga wrote: >> If anyone wants to have a look to what packages **may** be orphaned >> when those users are removed from the packager group, I've set up a >> script and uploaded the results here [1]. >> >> Do not be too scared by those results: there's still plenty of time for >> those users to show up and declare their willingness to maintain their >> status. If you, however, see a package you care listed with an asterisk >> (look at the bottom of the list), take notice that these are the >> packages that will surely be orphaned, because the current >> maintainer has asked to be removed from the packager group. >> Maybe you can start asking them to transfer the package to you. >> >> I plan to post an updated list before the end of the month and at >> mid October (or maybe Ben will do, if he prefer). >> >> [1] https://mattia.fedorapeople.org/inactive-packagers/affected_packages.txt > Regarding the following package from that list : > - NetworkManager-l2tp (owned by ivanromanov) > > I've been maintaining the package (and upstream source) since 2016, but I'm > not the 'owner" or "main admin", just a member/admin. > > What's the best way to become owner of the NetworkManager-l2tp package? > > > > Thanks, > Doug > Since we're still unsure if ivanromanov is reachable or not, I'd say: - open a BZ ticket on that package, asking ivanromanov to become the main-admin - wait and see if the package will be orphaned in case the main-admin is removed by this policy, then you can take it over I don't think it's wortwhile to open a unresponsive maintainer ticket at this point. Mattia ___ 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: Inactive packagers to be removed after the F37 release
Il 05/09/22 08:59, Brian (bex) Exelbierd ha scritto: > On Sat, Sep 3, 2022 at 9:24 PM Adam Williamson > wrote: > >> On Thu, 2022-08-18 at 17:28 -0400, Ben Cotton wrote: >>> Hello everyone! >>> >>> I just completed the first run of FESCo's newly approved Inactive >>> Packager Policy[1]. Packagers that have been identified as inactive >>> have a ticket in the find-inactive-packagers repo[2]. One week after >>> the F37 final release, packagers who remain inactive will be removed >>> from the packager group. (Note that pagure.io is one of the systems >>> checked for activity, so commenting on your ticket that you're still >>> around will prevent you from showing up in the second round.) >> >> So, I have a probably-controversial idea for a follow-up on this. > > I'll add one more idea/loophole to consider closing. I am a member of the > packager group but no longer maintain any packages. I am active enough in > other ways to not be noticed by this policy. I don't think that is right. I'm sorry for that. The script currently searches for user activity in src.fp.o, pagure.io, Bodhi, Bugzilla and Fedora mailing lists. Can you tell me where you're active, so, maybe, I can add that place in the search pattern? > I have submitted a ticket to voluntarily give up my packager rights under > this policy. However, we should probably verify that a packager actually has > at least one package or is a proven packager as a part of this policy. I > realize that it is very hard to know how long someone has not had any > packages, so this could result in a request to validate to a person who is > temporarily without a package during the period when the script is run, > however I think this is a reasonable edge case to resolve manually. > > regards, > > bex I don't agree with that. If a user haven't got any commit right to any package, they don't need to be in the packager group, that's exactly the scope of this policy. Maybe they left years ago, their commit rights were removed, but they never have been removed from packagers. Mattia___ 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: Inactive packagers to be removed after the F37 release
On 04/09/2022 19:30, Michael Catanzaro wrote: And anybody who isn't willing to buy a security key wouldn't be able to contribute to Fedora at all. So, you want to ban all contributors from countries where such tokens are prohibited, am I right? Strongly -1. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ 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: Inactive packagers to be removed after the F37 release
On Sat, Sep 3, 2022 at 9:24 PM Adam Williamson wrote: > On Thu, 2022-08-18 at 17:28 -0400, Ben Cotton wrote: > > Hello everyone! > > > > I just completed the first run of FESCo's newly approved Inactive > > Packager Policy[1]. Packagers that have been identified as inactive > > have a ticket in the find-inactive-packagers repo[2]. One week after > > the F37 final release, packagers who remain inactive will be removed > > from the packager group. (Note that pagure.io is one of the systems > > checked for activity, so commenting on your ticket that you're still > > around will prevent you from showing up in the second round.) > > So, I have a probably-controversial idea for a follow-up on this. > I'll add one more idea/loophole to consider closing. I am a member of the packager group but no longer maintain any packages. I am active enough in other ways to not be noticed by this policy. I don't think that is right. I have submitted a ticket to voluntarily give up my packager rights under this policy. However, we should probably verify that a packager actually has at least one package or is a proven packager as a part of this policy. I realize that it is very hard to know how long someone has not had any packages, so this could result in a request to validate to a person who is temporarily without a package during the period when the script is run, however I think this is a reasonable edge case to resolve manually. regards, bex -- Don't rush to reply to this email. Enjoy work/life balance. I read email once a day and am in the CE(S)T timezone. If you have an urgent email, ping me, and consider other mediums for urgent messages in the future. Brian "bex" Exelbierd (he/him/his) Business Strategist for Communities and Developers Red Hat Enterprise Linux @bexelbie | http://www.winglemeyer.org bexel...@redhat.com ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
RE: Inactive packagers to be removed after the F37 release
On Sun, Sep 4, 2022 at 1:38 PM Mattia Verga wrote: > If anyone wants to have a look to what packages **may** be orphaned > when those users are removed from the packager group, I've set up a > script and uploaded the results here [1]. > > Do not be too scared by those results: there's still plenty of time for > those users to show up and declare their willingness to maintain their > status. If you, however, see a package you care listed with an asterisk > (look at the bottom of the list), take notice that these are the > packages that will surely be orphaned, because the current > maintainer has asked to be removed from the packager group. > Maybe you can start asking them to transfer the package to you. > > I plan to post an updated list before the end of the month and at > mid October (or maybe Ben will do, if he prefer). > > [1] https://mattia.fedorapeople.org/inactive-packagers/affected_packages.txt Regarding the following package from that list : - NetworkManager-l2tp (owned by ivanromanov) I've been maintaining the package (and upstream source) since 2016, but I'm not the 'owner" or "main admin", just a member/admin. What's the best way to become owner of the NetworkManager-l2tp package? Thanks, Doug ___ 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 2123967] perl-Sereal-5.001 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2123967 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #2 from Fedora Update System --- FEDORA-2022-820d29ea37 has been pushed to the Fedora 37 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2022-820d29ea37` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-820d29ea37 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2123967 ___ 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 2123968] perl-Sereal-Encoder-5.001 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2123968 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #2 from Fedora Update System --- FEDORA-2022-820d29ea37 has been pushed to the Fedora 37 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2022-820d29ea37` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-820d29ea37 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2123968 ___ 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 2123969] perl-Sereal-Decoder-5.001 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2123969 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #2 from Fedora Update System --- FEDORA-2022-820d29ea37 has been pushed to the Fedora 37 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2022-820d29ea37` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-820d29ea37 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2123969 ___ 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
