date:20221013

On Fri, Oct 14, 2022 at 1:39 AM Kevin Kofler via devel
 wrote:
> ... but this is absolutely absurd.

To (mis) quote Randy Bush: "their application, their rules".
If you don't like them, find another provider.

I hope that RedHat quickly supports passkeys, where
this all becomes moot.

Unless you share your specific password (please do
*NOT* *NOT* do so), there is no way to know for sure
if the password has other issues.

For example, technically, PassWORD! meets most
minimal length and mixed case requirements, but
is clearly not a good password.
___
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

Ridiculous new Red Hat Bugzilla password security requirements

Hi,

today, Red Hat Bugzilla forced me to change my password because apparently a 
password of 9 random alphanumeric+symbol characters (1 symbol, 8 mixed-case 
alphanumeric) is suddenly no longer considered secure enough. This is 
absolutely ridiculous for a bug tracker. It is not like that password is for 
a bank account or for a build system (I believe FAS and thus Koji actually 
has less stringent password security requirements than that!), so how secure 
does the password really have to be?

I have generated a new 20-character random password with "pwgen -s 20 1", 
and that is good enough for Bugzilla (but who knows for how long?), but this 
is absolutely absurd.

Kevin Kofler
___
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: Non-responsive maintainer check for volter

Scott Talbert wrote:
> This is a non-responsive maintainer check for volter (Volker Fröhlich).
> Does anyone know how to contact this user?
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=2134665

Volker basically left Fedora packaging almost a year ago:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/3QANCB2C5PLVBJD4SNQPBZQ7Q5MU2L45/#T4NT6DFNGYXB3WI6GBQOVSPC5NKQZVN6

Does the e-mail address in FAS and Bugzilla (the gmx.at one) no longer work?

I am going to ping him on IRC (volter at Libera Chat) pointing him to this 
thread, but considering the thread linked above, I think we can probably 
fast-track the orphaning.

Kevin Kofler
___
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

Non-responsive maintainer check for mikedep333

This is a non-responsive maintainer check for mikedep333 (Michael 
DePaulo).  Does anyone know how to contact this maintainer?


https://bugzilla.redhat.com/show_bug.cgi?id=2134659
___
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

Non-responsive maintainer check for ivazquez

This is a non-responsive maintainer check for ivazquez (Ignacio 
Vazquez-Abrams).  Does anyone know how to contact this user?


https://bugzilla.redhat.com/show_bug.cgi?id=2134660
___
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

Non-responsive maintainer check for volter

This is a non-responsive maintainer check for volter (Volker Fröhlich). 
Does anyone know how to contact this user?


https://bugzilla.redhat.com/show_bug.cgi?id=2134665___
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

Non-responsive maintainer check for wolfy

This a non-responsive maintainer check for wolfy (manuel wolfshant). 
Does anyone know how to contact this maintainer?


https://bugzilla.redhat.com/show_bug.cgi?id=2134664
___
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: What if we excluded 32bit ARM from Python 3.12

2022-10-13 Thread Sandro


On 13-10-2022 19:22, Neal Gompa wrote:

Would anybody be sad about that?


I'm fine with it. The less ARM in my life, the better.


I feel ya. ;-P

ARM: https://en.wikipedia.org/wiki/Association_of_Radical_Midwives
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-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/python-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Advice needed: Pantheon desktop broken on Fedora 37 (yes, worse than usual)

2022-10-13 Thread Andreas Tunek

Den tors 13 okt. 2022 kl 17:01 skrev Neal Gompa :

> On Thu, Oct 13, 2022 at 10:58 AM Neal Gompa  wrote:
> >
> > On Thu, Oct 13, 2022 at 10:55 AM Michael J Gruber 
> wrote:
> > >
> > > Thanks for all your work!
> > >
> > > Dropping pantheon is not the only fallout of GNOME's schedule around
> our release. (I do understand why we wanted it in.)
> >
> > Pantheon's struggles are more evidence of GNOME's lack of courtesy to
> > the larger ecosystem leveraging their stack. I wish it wasn't like
> > this. :(
> >
>
> To elucidate, libsoup is the straw that broke the camel's back here.
> There have been numerous problems over the years caused by breakages
> in the GNOME stack. The biggest one being Mutter. I'm really sad to
> see Pantheon go, because it's a great desktop environment.
>
> I don't think Mutter promise a stable ABI, so if you want to use Mutter in
> a Linux distro context you have to keep up or work with upstream. That is
> true for a lot of other projects as well.
>
> --
> 真実はいつも一つ！/ Always, there's only one truth!
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Ostree Native Container (Phase 2, stable) (System-Wide Change proposal)

2022-10-13 Thread Ben Cotton

On Thu, Oct 13, 2022 at 3:08 PM Ben Cotton  wrote:
>
> == Contingency Plan ==
> * Contingency mechanism: Continue to ship things the way we ship them today
> * Contingency deadline: Dunno
> * Blocks release? No

I suggest the branch day (2023-02-07) as the contingency deadline here.

-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
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

F38 proposal: Ostree Native Container (Phase 2, stable) (System-Wide Change proposal)

2022-10-13 Thread Ben Cotton

https://fedoraproject.org/wiki/Changes/OstreeNativeContainerStable

This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.


== Summary ==

Continue the work done in
https://fedoraproject.org/wiki/Changes/OstreeNativeContainer but in an
officially stable format, and expanded to cover more OSTree-based
editions.  This goes "all in" on being container-native and
significantly changes the technology and user emphasis.

== Owner ==

* Name: [[User:walters| Colin Walters]], [[User:jmarrero| Joseph
Marrero]], [[User:baude| Brent Baude]]
* Email: walt...@verbum.org, jmarr...@fedoraproject.org, ba...@fedoraproject.org


== Detailed Description ==

* rpm-ostree's functionality to
[https://coreos.github.io/rpm-ostree/container/ boot and upgrade from
Docker/OCI container images] is declared stable
* Rework Fedora editions and spins (CoreOS, IoT, Silverblue, Kinoite,
etc) that use ostree to instead deliver via Docker/OCI container
images
* `rpm-ostree` is reworked to gain strong CLI compatibility with
`yum/dnf` commands (cliwrap)
* The new container native functionality is exposed via `dnf image`
* (TBD: Rebranding of rpm-ostree itself to `dnf-image` or something else)
* Support and documentation for generating derived images
* Support in Anaconda and other tools
* Support for generating bootable images


A top level goal is that users should not need to know or understand
ostree (or rpm-ostree); they only need to know containers and most key
functionality is exposed via the `yum/dnf` frontend with a few
extensions.


=== Backwards compatibility ===

If you're a user of ostree today: no need to worry.  Everything that
works today in ostree and rpm-ostree will continue to work for years
to come (it's shipped in RHEL9). However, it's expected that most
users will find the new model sufficiently compelling to switch fairly
quickly.

=== Stable Bootable OCI ===

More information about this is available in
[https://coreos.github.io/rpm-ostree/container/ the rpm-ostree
documentation].  This Change highlights that this functionality is
planned to be officially stable.

=== Changing to OCI over the wire ===

Today Fedora has an OSTree repository that contains updates for
editions such as Fedora CoreOS and Fedora Silverblue.

These editions instead will become [https://github.com/opencontainers
OCI base images], available at e.g.

* `quay.io/fedora/fedora-coreos:stable`
([https://quay.io/repository/fedora/fedora-coreos this exists today]!)
* `quay.io/fedora/fedora-silverblue:38` (does not exist, but can soon)

An update will be shipped that will cause existing systems tracking
the production ostree branches to be switched to the corresponding
container image.  Concretely for example, a system running
`fedora:fedora/36/x86_64/silverblue` will execute `rpm-ostree rebase
ostree-remote-registry:fedora:quay.io/fedora/fedora-silverblue:36`.

Note that at the current time, Fedora does not sign container images.
This should change (likely to something based on
[cosign](https://github.com/containers/skopeo/pull/1701)), but in the
mean time, the ostree-container flow supports verifying the embedded
ostree-baesd GPG signatures and this will continue to be used.

The Fedora OSTree repository will become read-only and stop receiving updates.

Note that for Fedora CoreOS specifically, there is some outstanding
design discussion around the intersection with Cincinnati:
https://github.com/coreos/fedora-coreos-tracker/issues/1263

 Wire efficiency 

Today the container images generated by rpm-ostree are "chunked" in a
reproducible fashion; for more information on this, see

* https://github.com/ostreedev/ostree-rs-ext/issues/69
* https://coreos.github.io/rpm-ostree/container/

However, longer term (as that first issue notes) we do want to add
[https://github.com/containers/image/pull/902 container deltas].
Doing so will benefit non-host containers too.



=== dnf/yum CLI compatibility ===

rpm-ostree has a feature called
[cliwrap](https://coreos.github.io/rpm-ostree/cliwrap/) today.  A key
motivation here is that in the switch to using containers as the
frontend, the project name "rpm-ostree" (which is very literal) no
longer makes sense.  A further emphasis on "container native" will
strongly encourage writing e.g. a `Dockerfile` like this:



FROM quay.io/fedora/fedora-silverblue:stable
RUN dnf -y install sway && ostree container commit


*Today*, one can spell this as `RUN rpm-ostree install -y sway &&
ostree container commit` - but a toplevel goal here is to allow host
system customization using the same patterns and tools one uses to
build application containers, and to de-emphasize the "ostree backend"
aspect.

To complete this story on the client side, what is today called
"ostree native containers" will be exposed via a new `dnf image`

F38 proposal: Ostree Native Container (Phase 2, stable) (System-Wide Change proposal)

2022-10-13 Thread Ben Cotton

https://fedoraproject.org/wiki/Changes/OstreeNativeContainerStable

This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.


== Summary ==

Continue the work done in
https://fedoraproject.org/wiki/Changes/OstreeNativeContainer but in an
officially stable format, and expanded to cover more OSTree-based
editions.  This goes "all in" on being container-native and
significantly changes the technology and user emphasis.

== Owner ==

* Name: [[User:walters| Colin Walters]], [[User:jmarrero| Joseph
Marrero]], [[User:baude| Brent Baude]]
* Email: walt...@verbum.org, jmarr...@fedoraproject.org, ba...@fedoraproject.org


== Detailed Description ==

* rpm-ostree's functionality to
[https://coreos.github.io/rpm-ostree/container/ boot and upgrade from
Docker/OCI container images] is declared stable
* Rework Fedora editions and spins (CoreOS, IoT, Silverblue, Kinoite,
etc) that use ostree to instead deliver via Docker/OCI container
images
* `rpm-ostree` is reworked to gain strong CLI compatibility with
`yum/dnf` commands (cliwrap)
* The new container native functionality is exposed via `dnf image`
* (TBD: Rebranding of rpm-ostree itself to `dnf-image` or something else)
* Support and documentation for generating derived images
* Support in Anaconda and other tools
* Support for generating bootable images


A top level goal is that users should not need to know or understand
ostree (or rpm-ostree); they only need to know containers and most key
functionality is exposed via the `yum/dnf` frontend with a few
extensions.


=== Backwards compatibility ===

If you're a user of ostree today: no need to worry.  Everything that
works today in ostree and rpm-ostree will continue to work for years
to come (it's shipped in RHEL9). However, it's expected that most
users will find the new model sufficiently compelling to switch fairly
quickly.

=== Stable Bootable OCI ===

More information about this is available in
[https://coreos.github.io/rpm-ostree/container/ the rpm-ostree
documentation].  This Change highlights that this functionality is
planned to be officially stable.

=== Changing to OCI over the wire ===

Today Fedora has an OSTree repository that contains updates for
editions such as Fedora CoreOS and Fedora Silverblue.

These editions instead will become [https://github.com/opencontainers
OCI base images], available at e.g.

* `quay.io/fedora/fedora-coreos:stable`
([https://quay.io/repository/fedora/fedora-coreos this exists today]!)
* `quay.io/fedora/fedora-silverblue:38` (does not exist, but can soon)

An update will be shipped that will cause existing systems tracking
the production ostree branches to be switched to the corresponding
container image.  Concretely for example, a system running
`fedora:fedora/36/x86_64/silverblue` will execute `rpm-ostree rebase
ostree-remote-registry:fedora:quay.io/fedora/fedora-silverblue:36`.

Note that at the current time, Fedora does not sign container images.
This should change (likely to something based on
[cosign](https://github.com/containers/skopeo/pull/1701)), but in the
mean time, the ostree-container flow supports verifying the embedded
ostree-baesd GPG signatures and this will continue to be used.

The Fedora OSTree repository will become read-only and stop receiving updates.

Note that for Fedora CoreOS specifically, there is some outstanding
design discussion around the intersection with Cincinnati:
https://github.com/coreos/fedora-coreos-tracker/issues/1263

 Wire efficiency 

Today the container images generated by rpm-ostree are "chunked" in a
reproducible fashion; for more information on this, see

* https://github.com/ostreedev/ostree-rs-ext/issues/69
* https://coreos.github.io/rpm-ostree/container/

However, longer term (as that first issue notes) we do want to add
[https://github.com/containers/image/pull/902 container deltas].
Doing so will benefit non-host containers too.



=== dnf/yum CLI compatibility ===

rpm-ostree has a feature called
[cliwrap](https://coreos.github.io/rpm-ostree/cliwrap/) today.  A key
motivation here is that in the switch to using containers as the
frontend, the project name "rpm-ostree" (which is very literal) no
longer makes sense.  A further emphasis on "container native" will
strongly encourage writing e.g. a `Dockerfile` like this:



FROM quay.io/fedora/fedora-silverblue:stable
RUN dnf -y install sway && ostree container commit


*Today*, one can spell this as `RUN rpm-ostree install -y sway &&
ostree container commit` - but a toplevel goal here is to allow host
system customization using the same patterns and tools one uses to
build application containers, and to de-emphasize the "ostree backend"
aspect.

To complete this story on the client side, what is today called
"ostree native containers" will be exposed via a new `dnf image`

Re: F38 proposal: RPM Sequoia (System-Wide Change proposal)

2022-10-13 Thread PGNet Dev


Let's Encrypt also supports the dns-01 challenge[1] that doesn't require
any publicly available IPs. Using dns verification is required to obtain a
Let's Encrypt wildcard certificate.


While I tend to prefer using the dns-01 challenge approach
when possible, not all DNS providers have made it easy to
accomplish (the certbot folk have implementations for a
number of the major DNS providers, and one can sometimes
find other 3rd party code for others, but it can still be hard
to setup and use, which means just enough additional
impedance that sometimes people will choose not to use it;
I can't blame them, as sometimes free has a higher cost
than having someone else order the cert from one of
the non-free CAs).


fwiw, IME, one of the lowest-friction  dns-challenge tools I've recommended, 
and see actually getting used by clients, is acme.sh,


https://github.com/acmesh-official/acme.sh#user-content-8-automatic-dns-api-integration

which supports 'most' of the big dns apis,

https://github.com/acmesh-official/acme.sh/wiki/dnsapi

and, when not an option, is fairly trivial to use manually


https://github.com/acmesh-official/acme.sh#user-content-9-use-dns-manual-mode
https://github.com/acmesh-official/acme.sh/wiki/dns-manual-mode

all of this with no cumbersome python, go, webserver, etc deps.  just bash 
shell.
___
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 2132704] Upgrade perl-Image-Info to 1.43

https://bugzilla.redhat.com/show_bug.cgi?id=2132704

Tom "spot" Callaway  changed:

   What|Removed |Added

 Status|NEW |CLOSED
 Resolution|--- |RAWHIDE
Last Closed||2022-10-13 17:51:58



--- Comment #1 from Tom "spot" Callaway  ---
1.43 in rawhide.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2132704
___
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: What if we excluded 32bit ARM from Python 3.12

On Thu, Oct 13, 2022 at 5:08 AM Miro Hrončok  wrote:
>
> Hello Pythonistas,
>
> we are probably going to package python3.12 soon for all Fedora releases.
>
> Unfortunately, building Python for 32bit ARM has been very tedious lately, as
> the Koji build keeps restarting and the build takes 24+ hours to finish.
>
> Considering 32bit ARM is gone from Fedora 37+, I was considering the
> ExcludeArch it from the python3.12 package even on older Fedoras, to make the
> builds easier.
>
> Would anybody be sad about that?
>

I'm fine with it. The less ARM in my life, the better.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-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/python-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: What if we excluded 32bit ARM from Python 3.12

2022-10-13 Thread Sandro


On 13-10-2022 11:07, Miro Hrončok wrote:

Considering 32bit ARM is gone from Fedora 37+, I was considering the
ExcludeArch it from the python3.12 package even on older Fedoras, to make the
builds easier.

Would anybody be sad about that?


Not at all.

While I still have a RPi 3 running on armv7l, it will be upgraded to 
aarch64 eventually and I don't expect anything to break by not having 
Python3.12 available for it.


-- Sandro
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-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/python-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: RPM Sequoia (System-Wide Change proposal)

On Thu, Oct 13, 2022 at 4:57 PM Maxwell G via devel
 wrote:

> Let's Encrypt also supports the dns-01 challenge[1] that doesn't require
> any publicly available IPs. Using dns verification is required to obtain a
> Let's Encrypt wildcard certificate.

While I tend to prefer using the dns-01 challenge approach
when possible, not all DNS providers have made it easy to
accomplish (the certbot folk have implementations for a
number of the major DNS providers, and one can sometimes
find other 3rd party code for others, but it can still be hard
to setup and use, which means just enough additional
impedance that sometimes people will choose not to use it;
I can't blame them, as sometimes free has a higher cost
than having someone else order the cert from one of
the non-free CAs).
___
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: F38 proposal: RPM Sequoia (System-Wide Change proposal)

2022-10-13 Thread Kevin P. Fleming


On 10/13/22 11:28, Demi Marie Obenour wrote:

systemd (yes, systemd)
is considering using Rust, though it has not yet started including it,
and there is already Rust code in Mesa IIRC.


Don't forget the Python 'cryptography' package... also a Rust user. It's 
here to stay, at least for the foreseeable future.


--
Kevin P. Fleming
He/Him/His
Principal Program Manager, RHEL
Red Hat US/Eastern Time Zone
___
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: F38 proposal: RPM Sequoia (System-Wide Change proposal)

2022-10-13 Thread Maxwell G via devel

On Thu Oct 13, 2022 at 17:12 +0200, Kevin Kofler via devel wrote:
> > And using Let's Encrypt for private mirrors is sufficiently painful that I
> > wouldn't recommend it.
>
> Set up a subdomain like vpn.example.com, point it to the public IP, then 
> configure the VPN's internal DNS to resolve vpn.example.com to the VPN-
> internal address instead, the /etc/hosts on the VPN server itself to resolve 
> it to 127.0.0.1, and the mirror server on port 443 (whereas port 80 is 
> reserved for certbot's builtin temporary (and world-readable) webserver with 
> the http-01 challenge) to accept connections only from the VPN and from 
> localhost and to use the Let's Encrypt certificate. Been there, done that 
> (not for a repository mirror though, my employer is small enough for that 
> not to be worthwhile). I assume that this approach should also work for a 
> physical LAN in lieu of the VPN.

Let's Encrypt also supports the dns-01 challenge[1] that doesn't require
any publicly available IPs. Using dns verification is required to obtain a
Let's Encrypt wildcard certificate.

[1]: https://letsencrypt.org/docs/challenge-types/#dns-01-challenge
--
Maxwell G (@gotmax23)
Pronouns: He/Him/His


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 2134212] perl-Finance-Quote-1.5301 is available

https://bugzilla.redhat.com/show_bug.cgi?id=2134212



--- Comment #3 from Gwyn Ciesla  ---
Interesting. Sorry for the confusion. I guess the former, since the latter
might result in needing additional epochs in the future.

I only took ownership of this pacakage to facilitate the Gnucash stack. If
you'd like to take it over, that would be fine with me.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2134212
___
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: F38 proposal: RPM Sequoia (System-Wide Change proposal)

2022-10-13 Thread Demi Marie Obenour

On 10/13/22 04:23, Panu Matilainen wrote:
> On 10/13/22 10:53, Neal Gompa wrote:
>> On Thu, Oct 13, 2022 at 3:29 AM Panu Matilainen  wrote:
>>>
>>> On 10/13/22 07:18, Kevin Kofler via devel wrote:
> For the last 20 years or so, RPM has used a home-grown OpenPGP parser
> for dealing with keys and signatures. That parser is rather infamous
> for its limitations and flaws, and especially in recent years has
> proven a significant burden to RPM development. In order to improve
> security and free developer resources for dealing with RPM's "core
> business" instead, RPM upstream is in the process of deprecating the
> internal parser in favor of [https://sequoia-pgp.org/ Sequoia PGP]
> based solution written in Rust.

 Why are you using a new library written in Rust? Can you not use one of the
 existing mature C implementations of OpenPGP? gpgme maybe?
>>>
>>> Had there been such an option, we would've switched over years ago.
>>> Gpgme is based around calling and communicating with an external gpg
>>> process, which is a setup you do NOT want in the rpm context where
>>> chroots come and go etc. Also, rpm requires access to the "low-level"
>>> digests-in-progress because it calculates multiple things on a single read.
>>>
>>
>> The real problem is that all other OpenPGP implementations died out
>> because of GnuPG. And then GnuPG made the choice to force an
>> inter-process model.
>>
>> At work, I deal with this on Debian systems, which do indeed use GnuPG
>> for this. It creates a lot of problems, especially for building images
>> and dealing with chroots, which is why in the context of RPM PGP
>> upstream, I never pushed to consider it.
>>
>> The most serious problems with PackageKit memory leaks and hangs are
>> actually caused by GnuPG, since DNF uses it for some GPG stuff because
>> there's no API for using RPM's PGP capabilities. There's no fix unless
>> the RPM and DNF teams agree on an API and build it out so that libdnf
>> and librepo no longer need to use GnuPG through gpgme anymore.
>>
>> This is also the underlying reason why Red Hat has resisted
>> implementing signed repository metadata and enforcing it by default.
>> Of course this is a bit of a catch-22 as well, as there's no
>> motivation to find a solution because neither Fedora nor RHEL offer
>> signed repository metadata despite repeated calls for it over the past
>> decade.
>>
>> Now, don't get me wrong: I'm personally extremely unhappy about having
>> to depend on the Sequoia stack for RPM PGP. I have a strong distaste
>> for the Rust community ecosystem these days, and I don't love the idea
>> of having to have LLVM in the core bootstrap chain (hopefully gcc-rs
>> will be in place soon enough!). But we literally don't have any other
>> options. GnuPG/GPGME is out of the question for the reasons Panu and I
>> stated, and NeoPG died several years ago. There are no C/C++ libraries
>> for OpenPGP verification.
> 
> There's RNP (in C++, used by Thunderbird at least), but alas that 
> doesn't expose the digest-in-progress either. So at least in it's 
> current form, it's not an option for rpm. Also, the API appears to have 
> all manner of quirks and gotchas that aren't welcome in a 
> security-critical piece.
> 
> As for bootstrap, there will always (have to) be a way to build rpm 
> without depending on Rust. Even if that meant no signature verification 
> support in such a configuration.

RPM could keep its own internal parser for bootstrap only.  Bootstrap
does not need support for revocation, etc.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)
___
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: F38 proposal: RPM Sequoia (System-Wide Change proposal)

2022-10-13 Thread Demi Marie Obenour

On 10/13/22 11:18, Kevin Kofler via devel wrote:
> Fabio Valentini wrote:
>> Do you have suggestions for improving this situation? I think we're
>> pretty close to doing the best we can with packaging Rust projects,
>> given the current limitations of the language (i.e. the support for
>> building "true shared Rust libraries" is still very limited and
>> unstable; but that might improve in the future).
> 
> Building true shared libraries is pretty much a prerequisite for any sane 
> form of packaging.

I strongly recommend that you bring this up on the rust-lang Zulip
(https://rust-lang.zulipchat.com) and see if you can find people who can
improve this.

>> Additionally, the way the Sequoia GPG backend for RPM is implemented,
>> it's actually shipped as a standard shared library with a C ABI and
>> accompanying C headers (which are binary compatible with the existing
>> in-house GPG backend code in RPM). No Rust code will be statically
>> linked into /usr/bin/rpm.
> 
> That at least makes sense. (Though I assume that that C-style .so still 
> internally depends on a whole bunch of Rust crates that are statically 
> compiled and linked into the .so, does it not?)

It does.

>> I'm sorry to disappoint you, but Rust is here to stay, whether you
>> like it or not.
>> For example, it's been voted the "most loved" and "most wanted"
>> language for a few years in a row in Stack Overflow's surveys:
>> https://survey.stackoverflow.co/2022/#technology-most-loved-dreaded-and-wanted
> 
> And according to the same statistics, the majority of developers runs 
> Windows, yet hopefully you do not propose that Fedora ship Windows…
> 
> We need to ship what we can reasonably ship, not what the (relative) 
> majority of developers in the world (most of whom do not even run Fedora) 
> happens to prefer.

There is now Rust code in the Linux kernel.  It currently is not
needed by any shipping driver, but that is not a matter of *if*,
but of *when*.  The Asahi GPU driver is being written in Rust,
for example, so anyone building Linux for Apple Silicon will need
CONFIG_RUST=y in the not-too-distant future.  systemd (yes, systemd)
is considering using Rust, though it has not yet started including it,
and there is already Rust code in Mesa IIRC.

C and C++ are being moved away from because they have unfixable
security problems.  Memory unsafety, which is predominantly (though
not exclusively) found in C and C++ codebases, accounts for well
over half of all security vulnerabilities.  Google tried to retrofit
memory safety into C++ and failed, and the existing methods for
making C memory-safe either have massive overheads (4x slowdown
for a single-threaded application, worse for multi-threaded, IIRC)
or require a completely unreasonable amount of developer effort for
a volunteer project (formal methods).
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)
___
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: Copr delete-by-default expiration policy still unacceptable

On Thu, Oct 13, 2022 at 3:56 PM Josh Boyer  wrote:
>
> On Thu, Oct 13, 2022 at 11:04 AM Gary Buhrmaster
>  wrote:
> >
> > On Thu, Oct 13, 2022 at 2:25 PM Josh Boyer  
> > wrote:
> >
> > > Would you be willing to pay for that feature?
> >
> > A "freemium" COPR service?
> >
> > I suspect that that would be such a
> > niche service that the cost per user
> > (to pay for the overheads to create
> > and maintain it) would not be
> > acceptable to anyone.
>
> I find that statement to be... ironic.  We're already running a free
> COPR service and paying for the overhead to create and maintain it.

I was talking about adding the "freemium"
paid service, which means being able to
charge users.  Adding in the various payment
processing options (and terminating service
when payment ends) is typically complex.
Real money changes everything.
___
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: Copr delete-by-default expiration policy still unacceptable

2022-10-13 Thread Josh Boyer

On Thu, Oct 13, 2022 at 11:04 AM Gary Buhrmaster
 wrote:
>
> On Thu, Oct 13, 2022 at 2:25 PM Josh Boyer  wrote:
>
> > Would you be willing to pay for that feature?
>
> A "freemium" COPR service?
>
> I suspect that that would be such a
> niche service that the cost per user
> (to pay for the overheads to create
> and maintain it) would not be
> acceptable to anyone.

I find that statement to be... ironic.  We're already running a free
COPR service and paying for the overhead to create and maintain it.

josh
___
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: F38 proposal: RPM Sequoia (System-Wide Change proposal)

On Thu, Oct 13, 2022 at 11:38 AM Demi Marie Obenour
 wrote:
>
> On 10/13/22 08:14, Neal Gompa wrote:
> > On Thu, Oct 13, 2022 at 4:24 AM Panu Matilainen  wrote:
> >>
> >> On 10/13/22 10:53, Neal Gompa wrote:
> >>> On Thu, Oct 13, 2022 at 3:29 AM Panu Matilainen  
> >>> wrote:
> 
>  On 10/13/22 07:18, Kevin Kofler via devel wrote:
> >> For the last 20 years or so, RPM has used a home-grown OpenPGP parser
> >> for dealing with keys and signatures. That parser is rather infamous
> >> for its limitations and flaws, and especially in recent years has
> >> proven a significant burden to RPM development. In order to improve
> >> security and free developer resources for dealing with RPM's "core
> >> business" instead, RPM upstream is in the process of deprecating the
> >> internal parser in favor of [https://sequoia-pgp.org/ Sequoia PGP]
> >> based solution written in Rust.
> >
> > Why are you using a new library written in Rust? Can you not use one of 
> > the
> > existing mature C implementations of OpenPGP? gpgme maybe?
> 
>  Had there been such an option, we would've switched over years ago.
>  Gpgme is based around calling and communicating with an external gpg
>  process, which is a setup you do NOT want in the rpm context where
>  chroots come and go etc. Also, rpm requires access to the "low-level"
>  digests-in-progress because it calculates multiple things on a single 
>  read.
> 
> >>>
> >>> The real problem is that all other OpenPGP implementations died out
> >>> because of GnuPG. And then GnuPG made the choice to force an
> >>> inter-process model.
> >>>
> >>> At work, I deal with this on Debian systems, which do indeed use GnuPG
> >>> for this. It creates a lot of problems, especially for building images
> >>> and dealing with chroots, which is why in the context of RPM PGP
> >>> upstream, I never pushed to consider it.
> >>>
> >>> The most serious problems with PackageKit memory leaks and hangs are
> >>> actually caused by GnuPG, since DNF uses it for some GPG stuff because
> >>> there's no API for using RPM's PGP capabilities. There's no fix unless
> >>> the RPM and DNF teams agree on an API and build it out so that libdnf
> >>> and librepo no longer need to use GnuPG through gpgme anymore.
> >>>
> >>> This is also the underlying reason why Red Hat has resisted
> >>> implementing signed repository metadata and enforcing it by default.
> >>> Of course this is a bit of a catch-22 as well, as there's no
> >>> motivation to find a solution because neither Fedora nor RHEL offer
> >>> signed repository metadata despite repeated calls for it over the past
> >>> decade.
> >>>
> >>> Now, don't get me wrong: I'm personally extremely unhappy about having
> >>> to depend on the Sequoia stack for RPM PGP. I have a strong distaste
> >>> for the Rust community ecosystem these days, and I don't love the idea
> >>> of having to have LLVM in the core bootstrap chain (hopefully gcc-rs
> >>> will be in place soon enough!). But we literally don't have any other
> >>> options. GnuPG/GPGME is out of the question for the reasons Panu and I
> >>> stated, and NeoPG died several years ago. There are no C/C++ libraries
> >>> for OpenPGP verification.
> >>
> >> There's RNP (in C++, used by Thunderbird at least), but alas that
> >> doesn't expose the digest-in-progress either. So at least in it's
> >> current form, it's not an option for rpm. Also, the API appears to have
> >> all manner of quirks and gotchas that aren't welcome in a
> >> security-critical piece.
> >>
> >
> > Huh, I'd forgotten about RNP. It seems it now has an OpenSSL backend
> > and at least the verification API (which is what RPM would use) seems
> > to be getting love lately. Insofar as quirks and gotchas, I'm not a
> > great judge of that at the moment, but I don't think it could be worse
> > than what we have with GnuPG.
> >
> > The missing "digest-in-progress" thing is an issue, I guess. Have we
> > raised the issue with them about it?
> >
> >> As for bootstrap, there will always (have to) be a way to build rpm
> >> without depending on Rust. Even if that meant no signature verification
> >> support in such a configuration.
> >>
> >
> > Eck. What about the x509 based stuff we were talking about last year?
> > All the crypto backends RPM supports now support that stuff out of the
> > box.
> >
> > Embedded x509 signatures (certs) to replace GPG signatures could work
> > as an alternative.
>
> OpenPGP is not great, but X.509 is an absolute disaster in comparison.

But there are more implementations of the latter. I'll take that.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:

Re: F38 proposal: RPM Sequoia (System-Wide Change proposal)

2022-10-13 Thread Demi Marie Obenour

On 10/13/22 08:14, Neal Gompa wrote:
> On Thu, Oct 13, 2022 at 4:24 AM Panu Matilainen  wrote:
>>
>> On 10/13/22 10:53, Neal Gompa wrote:
>>> On Thu, Oct 13, 2022 at 3:29 AM Panu Matilainen  wrote:

 On 10/13/22 07:18, Kevin Kofler via devel wrote:
>> For the last 20 years or so, RPM has used a home-grown OpenPGP parser
>> for dealing with keys and signatures. That parser is rather infamous
>> for its limitations and flaws, and especially in recent years has
>> proven a significant burden to RPM development. In order to improve
>> security and free developer resources for dealing with RPM's "core
>> business" instead, RPM upstream is in the process of deprecating the
>> internal parser in favor of [https://sequoia-pgp.org/ Sequoia PGP]
>> based solution written in Rust.
>
> Why are you using a new library written in Rust? Can you not use one of 
> the
> existing mature C implementations of OpenPGP? gpgme maybe?

 Had there been such an option, we would've switched over years ago.
 Gpgme is based around calling and communicating with an external gpg
 process, which is a setup you do NOT want in the rpm context where
 chroots come and go etc. Also, rpm requires access to the "low-level"
 digests-in-progress because it calculates multiple things on a single read.

>>>
>>> The real problem is that all other OpenPGP implementations died out
>>> because of GnuPG. And then GnuPG made the choice to force an
>>> inter-process model.
>>>
>>> At work, I deal with this on Debian systems, which do indeed use GnuPG
>>> for this. It creates a lot of problems, especially for building images
>>> and dealing with chroots, which is why in the context of RPM PGP
>>> upstream, I never pushed to consider it.
>>>
>>> The most serious problems with PackageKit memory leaks and hangs are
>>> actually caused by GnuPG, since DNF uses it for some GPG stuff because
>>> there's no API for using RPM's PGP capabilities. There's no fix unless
>>> the RPM and DNF teams agree on an API and build it out so that libdnf
>>> and librepo no longer need to use GnuPG through gpgme anymore.
>>>
>>> This is also the underlying reason why Red Hat has resisted
>>> implementing signed repository metadata and enforcing it by default.
>>> Of course this is a bit of a catch-22 as well, as there's no
>>> motivation to find a solution because neither Fedora nor RHEL offer
>>> signed repository metadata despite repeated calls for it over the past
>>> decade.
>>>
>>> Now, don't get me wrong: I'm personally extremely unhappy about having
>>> to depend on the Sequoia stack for RPM PGP. I have a strong distaste
>>> for the Rust community ecosystem these days, and I don't love the idea
>>> of having to have LLVM in the core bootstrap chain (hopefully gcc-rs
>>> will be in place soon enough!). But we literally don't have any other
>>> options. GnuPG/GPGME is out of the question for the reasons Panu and I
>>> stated, and NeoPG died several years ago. There are no C/C++ libraries
>>> for OpenPGP verification.
>>
>> There's RNP (in C++, used by Thunderbird at least), but alas that
>> doesn't expose the digest-in-progress either. So at least in it's
>> current form, it's not an option for rpm. Also, the API appears to have
>> all manner of quirks and gotchas that aren't welcome in a
>> security-critical piece.
>>
> 
> Huh, I'd forgotten about RNP. It seems it now has an OpenSSL backend
> and at least the verification API (which is what RPM would use) seems
> to be getting love lately. Insofar as quirks and gotchas, I'm not a
> great judge of that at the moment, but I don't think it could be worse
> than what we have with GnuPG.
> 
> The missing "digest-in-progress" thing is an issue, I guess. Have we
> raised the issue with them about it?
> 
>> As for bootstrap, there will always (have to) be a way to build rpm
>> without depending on Rust. Even if that meant no signature verification
>> support in such a configuration.
>>
> 
> Eck. What about the x509 based stuff we were talking about last year?
> All the crypto backends RPM supports now support that stuff out of the
> box.
> 
> Embedded x509 signatures (certs) to replace GPG signatures could work
> as an alternative.

OpenPGP is not great, but X.509 is an absolute disaster in comparison.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)
___
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: What if we excluded 32bit ARM from Python 3.12

2022-10-13 Thread Victor Stinner

Which kind of computers and hardware use 32-bit ARM these days?

Raspberry Pi Zero 2 (2021), Raspberry Pi 3 (2018), Raspberry Pi 4
(2019) use 64-bit ARM, whereas older Raspberry Pi 1 (2012), Raspberry
Pi 2 (2015) and Raspberry Pi Zero (2015) use 32-bit ARM.

Victor

On Thu, Oct 13, 2022 at 11:08 AM Miro Hrončok  wrote:
>
> Hello Pythonistas,
>
> we are probably going to package python3.12 soon for all Fedora releases.
>
> Unfortunately, building Python for 32bit ARM has been very tedious lately, as
> the Koji build keeps restarting and the build takes 24+ hours to finish.
>
> Considering 32bit ARM is gone from Fedora 37+, I was considering the
> ExcludeArch it from the python3.12 package even on older Fedoras, to make the
> builds easier.
>
> Would anybody be sad about that?
>
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
> ___
> python-devel mailing list -- python-devel@lists.fedoraproject.org
> To unsubscribe send an email to python-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/python-devel@lists.fedoraproject.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-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/python-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: RPM Sequoia (System-Wide Change proposal)

On Thu, Oct 13, 2022 at 3:13 PM Kevin Kofler via devel
 wrote:
>
> Neal Gompa wrote:
> > I'm not going to get into this too much, but suffice to say, it's not
> > universally accessible as a CA.
>
> I would very much be interested in those details though.

As I recall, the current LE root certificate is not (and in some
cases may not be able to be) installed in all clients.  When
the cross signing cert (from a well known/trusted CA)
expired a year ago a number of clients suddenly found
themselves getting errors.  It is easy to say "install new
root certs", but that is not actually easy to do in all cases.
___
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: Copr delete-by-default expiration policy still unacceptable

2022-10-13 Thread PGNet Dev


Don't get me wrong, the folks who work on Koji and Copr are great, but
even they'll admit that they're woefully underfunded. The compose
tooling, PDC, etc. are also examples of this problem.


Can't agree enough.  Hats off to the COPR folks.
Without it, even it current state, RH/Fed ecosystem is, at least here, a LOT 
less tenable/attractive, if at all.


Even in a world where I would be *able* to pay for it (and there's
plenty of commercial evidence that such a service would be something
people would pay for), I just don't think it would stick.


Here's 1 'mid-sized umbrella' vote.

I'm happy to pay for a COPR service.  Particularly if it were to exist on 
at-least-arm's-length infrastructure, and provides decoupling from RH/IBM's 
corporate legal paranoias and policies.

That could be managed as reasonable subscription fees.

Another option is to get the containerized COPR efforts polished & available.  
Then, any/all could spin them up easily (aka, far easier than now), and deploy locally, 
&/or make available ...
and, charge some reasonable fee for those downloads.

And by reasonable fees, I'm not talking about Enterprise-sized profit-generating-fees, 
but enough given Fedora-project's real needs (devs & infrastructure) to defray, at 
least some of the, operating costs.  And something that a significant majority of 
current contributors -- paid & volunteer alike -- would consider a worthwhile 
bargain for the value received.
___
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: F38 proposal: RPM Sequoia (System-Wide Change proposal)

Fabio Valentini wrote:
> Do you have suggestions for improving this situation? I think we're
> pretty close to doing the best we can with packaging Rust projects,
> given the current limitations of the language (i.e. the support for
> building "true shared Rust libraries" is still very limited and
> unstable; but that might improve in the future).

Building true shared libraries is pretty much a prerequisite for any sane 
form of packaging.

> Additionally, the way the Sequoia GPG backend for RPM is implemented,
> it's actually shipped as a standard shared library with a C ABI and
> accompanying C headers (which are binary compatible with the existing
> in-house GPG backend code in RPM). No Rust code will be statically
> linked into /usr/bin/rpm.

That at least makes sense. (Though I assume that that C-style .so still 
internally depends on a whole bunch of Rust crates that are statically 
compiled and linked into the .so, does it not?)

> I'm sorry to disappoint you, but Rust is here to stay, whether you
> like it or not.
> For example, it's been voted the "most loved" and "most wanted"
> language for a few years in a row in Stack Overflow's surveys:
> https://survey.stackoverflow.co/2022/#technology-most-loved-dreaded-and-wanted

And according to the same statistics, the majority of developers runs 
Windows, yet hopefully you do not propose that Fedora ship Windows…

We need to ship what we can reasonably ship, not what the (relative) 
majority of developers in the world (most of whom do not even run Fedora) 
happens to prefer.

Kevin Kofler
___
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: F38 proposal: RPM Sequoia (System-Wide Change proposal)

Neal Gompa wrote:
> I'm not going to get into this too much, but suffice to say, it's not
> universally accessible as a CA.

I would very much be interested in those details though. I do not see 
anybody being excluded from Let's Encrypt, not even countries under US 
embargo (e.g., over 30 sites in Iran are apparently using it 
successfully).

> And using Let's Encrypt for private mirrors is sufficiently painful that I
> wouldn't recommend it.

Set up a subdomain like vpn.example.com, point it to the public IP, then 
configure the VPN's internal DNS to resolve vpn.example.com to the VPN-
internal address instead, the /etc/hosts on the VPN server itself to resolve 
it to 127.0.0.1, and the mirror server on port 443 (whereas port 80 is 
reserved for certbot's builtin temporary (and world-readable) webserver with 
the http-01 challenge) to accept connections only from the VPN and from 
localhost and to use the Let's Encrypt certificate. Been there, done that 
(not for a repository mirror though, my employer is small enough for that 
not to be worthwhile). I assume that this approach should also work for a 
physical LAN in lieu of the VPN.

> There have been attempts to fix things, but Panu doesn't feel
> qualified to review the changes. That doesn't mean someone else who
> would be willing to do so couldn't. But because of... reasons, as long
> as it's in the RPM codebase, it's unlikely someone else will be
> trusted enough to do those reviews.

I see. So splitting might be worthwhile then. Assuming someone will care 
enough to actually maintain the code.

Kevin Kofler
___
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: Copr delete-by-default expiration policy still unacceptable

On Thu, Oct 13, 2022 at 11:04 AM Gary Buhrmaster
 wrote:
>
> On Thu, Oct 13, 2022 at 2:25 PM Josh Boyer  wrote:
>
> > Would you be willing to pay for that feature?
>
> A "freemium" COPR service?
>
> I suspect that that would be such a
> niche service that the cost per user
> (to pay for the overheads to create
> and maintain it) would not be
> acceptable to anyone.

Considering services like packagecloud.io and others exist and do
manage to make money storing repositories and builds, I think it's
pretty workable for COPR too. It would require some advertising and
such to get it out there, but it'd be workable.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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: Copr delete-by-default expiration policy still unacceptable

On Thu, Oct 13, 2022 at 2:25 PM Josh Boyer  wrote:

> Would you be willing to pay for that feature?

A "freemium" COPR service?

I suspect that that would be such a
niche service that the cost per user
(to pay for the overheads to create
and maintain it) would not be
acceptable to anyone.
___
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: Copr delete-by-default expiration policy still unacceptable

2022-10-13 Thread Mattia Verga via devel

Il 13/10/22 16:48, Kevin Kofler via devel ha scritto:
>
> What makes Copr so interesting is that it is offered at no cost to all
> Fedora contributors. But it has always been treated as an unloved stepchild
> by Red Hat and has never received the kind of resources, e.g., OBS has.

Is there any chance Fedora can put some money for that? Who is
responsible for spending Fedora resources? Looking at the Fedora budget
summaries [0] (latest available is for 2020...) Fedora always closes
years spending only 50% of the available budget... can't we put some
money on technical stuff needed by the platform instead of always rely
on RH?

[0] https://budget.fedoraproject.org/budget/docs/index.html

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Advice needed: Pantheon desktop broken on Fedora 37 (yes, worse than usual)

On Thu, Oct 13, 2022 at 10:58 AM Neal Gompa  wrote:
>
> On Thu, Oct 13, 2022 at 10:55 AM Michael J Gruber  
> wrote:
> >
> > Thanks for all your work!
> >
> > Dropping pantheon is not the only fallout of GNOME's schedule around our 
> > release. (I do understand why we wanted it in.)
>
> Pantheon's struggles are more evidence of GNOME's lack of courtesy to
> the larger ecosystem leveraging their stack. I wish it wasn't like
> this. :(
>

To elucidate, libsoup is the straw that broke the camel's back here.
There have been numerous problems over the years caused by breakages
in the GNOME stack. The biggest one being Mutter. I'm really sad to
see Pantheon go, because it's a great desktop environment.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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: Advice needed: Pantheon desktop broken on Fedora 37 (yes, worse than usual)

On Thu, Oct 13, 2022 at 10:55 AM Michael J Gruber  
wrote:
>
> Thanks for all your work!
>
> Dropping pantheon is not the only fallout of GNOME's schedule around our 
> release. (I do understand why we wanted it in.)

Pantheon's struggles are more evidence of GNOME's lack of courtesy to
the larger ecosystem leveraging their stack. I wish it wasn't like
this. :(



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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: Copr delete-by-default expiration policy still unacceptable

On Thu, Oct 13, 2022 at 10:48 AM Kevin Kofler via devel
 wrote:
>
> Josh Boyer wrote:
> > Would you be willing to pay for that feature?
>
> Probably not, because at that point, it would probably be cheaper to just
> set up a mirror or even a full-fledged build system on a VPS somewhere. Or
> even to use OBS, though I do not know what their retention policies for old
> repositories are (i.e., whether they are any better or even worse).
>
> What makes Copr so interesting is that it is offered at no cost to all
> Fedora contributors. But it has always been treated as an unloved stepchild
> by Red Hat and has never received the kind of resources, e.g., OBS has.
> Though it is still better than what smaller distributions like Arch are able
> to offer, where, e.g., the AUR only allows publishing the source PKGBUILD
> files and no binaries at all.
>

Red Hat has not truly invested in Fedora build infrastructure
software in a long time. It's pretty clear they don't consider it
valuable enough to have a significant team supporting it like SUSE
does for their stuff.

Don't get me wrong, the folks who work on Koji and Copr are great, but
even they'll admit that they're woefully underfunded. The compose
tooling, PDC, etc. are also examples of this problem.

Even in a world where I would be *able* to pay for it (and there's
plenty of commercial evidence that such a service would be something
people would pay for), I just don't think it would stick.

This is also part of the reason why I'm extremely wary about their
desire to hotwire Fedora image builds into the Red Hat hosted image
builder infrastructure. I've seen this story repeat so many times now
that I distrust new efforts from them on this front now, because we
always wind up holding the wet paper bag in the end.

--
真実はいつも一つ！/ Always, there's only one truth!
___
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: Copr delete-by-default expiration policy still unacceptable

2022-10-13 Thread Josh Boyer

On Thu, Oct 13, 2022 at 10:48 AM Kevin Kofler via devel
 wrote:
>
> Josh Boyer wrote:
> > Would you be willing to pay for that feature?
>
> Probably not, because at that point, it would probably be cheaper to just
> set up a mirror or even a full-fledged build system on a VPS somewhere. Or
> even to use OBS, though I do not know what their retention policies for old
> repositories are (i.e., whether they are any better or even worse).

Ok.  Then perhaps you should pursue the mirror idea to solve your
needs.  Putting that into a cloud storage bucket seems like it would
give you what you want.

> What makes Copr so interesting is that it is offered at no cost to all
> Fedora contributors. But it has always been treated as an unloved stepchild
> by Red Hat and has never received the kind of resources, e.g., OBS has.
> Though it is still better than what smaller distributions like Arch are able
> to offer, where, e.g., the AUR only allows publishing the source PKGBUILD
> files and no binaries at all.

Yes, COPR is great.  But "indefinite storage" or "user defined
storage" is not a core tenant of what it is for.  Keeping it free
while iterating on useful features requires limitations elsewhere.

To be clear, I am in no way suggesting COPR should ever move to a
paid-for model.  I'm just highlighting that it's a free service that
has operating costs and budget and it is reasonable to limit that in
some ways.

josh
___
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: Advice needed: Pantheon desktop broken on Fedora 37 (yes, worse than usual)

2022-10-13 Thread Michael J Gruber

Thanks for all your work!

Dropping pantheon is not the only fallout of GNOME's schedule around our 
release. (I do understand why we wanted it in.)
___
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: Copr delete-by-default expiration policy still unacceptable

Josh Boyer wrote:
> Would you be willing to pay for that feature?

Probably not, because at that point, it would probably be cheaper to just 
set up a mirror or even a full-fledged build system on a VPS somewhere. Or 
even to use OBS, though I do not know what their retention policies for old 
repositories are (i.e., whether they are any better or even worse).

What makes Copr so interesting is that it is offered at no cost to all 
Fedora contributors. But it has always been treated as an unloved stepchild 
by Red Hat and has never received the kind of resources, e.g., OBS has. 
Though it is still better than what smaller distributions like Arch are able 
to offer, where, e.g., the AUR only allows publishing the source PKGBUILD 
files and no binaries at all.

Kevin Kofler
___
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: Copr delete-by-default expiration policy still unacceptable

2022-10-13 Thread Michael J Gruber

You do have to admit that this happens only as a result of:

- wanting to support EOLed chroots
- not wanting to support non EOLed chroots (for those projects)
- not receiving notification e-mails
- not logging onto the web UI for more than 75 days

All of this in combination, and knowingly, as you write. I think it's quite a 
lot to ask for a change to cater for that specific combination, rather than 
adjusting your mail filters or habits. COPR is a great free service, repos are 
left rotting all the time for various reasons, and the way the cleanup is done 
supports keeping COPR available for free (to us).
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Heads-up: llhttp 8.0.0 coming to Rawhide

2022-10-13 Thread Ben Beasley

The llhttp package will instead be updated to version 8.1.0, which was 
released after the original announcement. The schedule and other details 
for this update remain unchanged.


Release notes for version 8.1.0: 
https://github.com/nodejs/llhttp/releases/tag/release%2Fv8.1.0


Source diff: https://github.com/nodejs/llhttp/compare/v6.0.10...v8.1.0

On 10/8/22 10:11, Ben Beasley wrote:
In one week (2022-10-15), or slightly later, I plan to update the 
llhttp package in Rawhide from 6.0.10 to 8.0.0. This includes some 
breaking API/ABI changes and a .so version bump. There is one 
dependent package, python-aiohttp, which I will rebuild with llhttp in 
a side tag using my python-packagers-sig membership. I have already 
verified compatibility in COPR.


Release notes for version 7.0.0: 
https://github.com/nodejs/llhttp/releases/tag/release%2Fv7.0.0


Release notes for version 8.0.0: 
https://github.com/nodejs/llhttp/releases/tag/release%2Fv8.0.0


Source diff: https://github.com/nodejs/llhttp/compare/v6.0.10...v8.0.0

Dist-git PR: https://src.fedoraproject.org/rpms/llhttp/pull-request/6

– Ben Beasley (FAS music)


___
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: F38 proposal: RPM Sequoia (System-Wide Change proposal)

On Thu, Oct 13, 2022 at 9:58 AM Kevin Kofler via devel
 wrote:
>
> Neal Gompa wrote:
> > No, because when you do things like mirror repositories (especially
> > for private mirrors), that signature is the only way to verify the
> > integrity. HTTPS is only transport encryption from a particular
> > connection.
>
> HTTPS protects against a MITM on the connection introducing invalid
> repository contents, which I would assume to be the biggest threat here. But
> sure, it by design does not guarantee that the data on the remote end is
> valid to begin with.
>
> > Also, a ton of Fedora mirrors still don't use HTTPS for various reasons.
>
> I would say that those mirrors ought to be kicked out of the mirror list
> immediately.
>
> With Let's Encrypt having been available for years, there is really no
> excuse for not offering HTTPS. Assuming you own a domain name (which I
> assume to already be the case for all mirrors), setting up HTTPS with Let's
> Encrypt does not cost you a dime. Even if you are a commercial entity.
>

I'm not going to get into this too much, but suffice to say, it's not
universally accessible as a CA. And using Let's Encrypt for private
mirrors is sufficiently painful that I wouldn't recommend it.

> > Well, it might still be worthwhile to split out RPM's OpenPGP
> > implementation into its own project and allow people to contribute to
> > it. The worst that can happen is that nothing changes.
>
> If that implementation is really as awfully broken as Panu is saying, I do
> not think that that would be of much use, unfortunately.
>

There have been attempts to fix things, but Panu doesn't feel
qualified to review the changes. That doesn't mean someone else who
would be willing to do so couldn't. But because of... reasons, as long
as it's in the RPM codebase, it's unlikely someone else will be
trusted enough to do those reviews.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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: Copr delete-by-default expiration policy still unacceptable

2022-10-13 Thread Josh Boyer

On Thu, Oct 13, 2022 at 8:41 AM Kevin Kofler via devel
 wrote:
>
> Miroslav Suchý wrote:
> > Dne 13. 10. 22 v 6:12 Kevin Kofler via devel napsal(a):
> >> I am really angry at Copr's expiration policy once again. It looks like I
> >> missed the deadline to renew the expired chroots (I still do not get any
> >> notification mails, they end up eaten in a spam filter somewhere), so
> >> once again a lot of data was deleted forever with no way to recover it.
> > What is your proposal then? The resources are not infinite.
>
> At least allow the opt-out per maintainer.
>
> I would suggest to add the permanent opt-out checkbox, mark it "(BETA)", and
> then evaluate how many maintainers actually check that checkbox and how much
> resource usage is actually caused by it. Then after a year or two, decide
> whether to keep the checkbox or revert to the current status quo. Or drop it
> sooner if you really run out of disk space as quickly as you seem to expect.

Would you be willing to pay for that feature?

josh
___
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: F38 proposal: RPM Sequoia (System-Wide Change proposal)

Neal Gompa wrote:
> No, because when you do things like mirror repositories (especially
> for private mirrors), that signature is the only way to verify the
> integrity. HTTPS is only transport encryption from a particular
> connection.

HTTPS protects against a MITM on the connection introducing invalid 
repository contents, which I would assume to be the biggest threat here. But 
sure, it by design does not guarantee that the data on the remote end is 
valid to begin with.

> Also, a ton of Fedora mirrors still don't use HTTPS for various reasons.

I would say that those mirrors ought to be kicked out of the mirror list 
immediately.

With Let's Encrypt having been available for years, there is really no 
excuse for not offering HTTPS. Assuming you own a domain name (which I 
assume to already be the case for all mirrors), setting up HTTPS with Let's 
Encrypt does not cost you a dime. Even if you are a commercial entity.

> Well, it might still be worthwhile to split out RPM's OpenPGP
> implementation into its own project and allow people to contribute to
> it. The worst that can happen is that nothing changes.

If that implementation is really as awfully broken as Panu is saying, I do 
not think that that would be of much use, unfortunately.

Kevin Kofler
___
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: F38 proposal: RPM Sequoia (System-Wide Change proposal)

2022-10-13 Thread Fabio Valentini

On Thu, Oct 13, 2022 at 3:31 PM Kevin Kofler via devel
 wrote:
>
> The dependency on LLVM is not even the worst issue in my eyes. LLVM is also
> used by other core projects, e.g., mesa, these days.
>
> The worst issue I see with Rust is the way libraries are "packaged", which
> just implies installing source code and recompiling that source code for
> every single application. (And as a result, the output obviously gets
> statically linked into the application, with all the drawbacks of static
> linking.) I consider a language with no usable shared library support to be
> entirely unpackageable and hence entirely useless.

Do you have suggestions for improving this situation? I think we're
pretty close to doing the best we can with packaging Rust projects,
given the current limitations of the language (i.e. the support for
building "true shared Rust libraries" is still very limited and
unstable; but that might improve in the future).

Additionally, the way the Sequoia GPG backend for RPM is implemented,
it's actually shipped as a standard shared library with a C ABI and
accompanying C headers (which are binary compatible with the existing
in-house GPG backend code in RPM). No Rust code will be statically
linked into /usr/bin/rpm.

> And then of course there is the issue that it is yet another language with
> yet another syntax (and an only partially C-like one, so the learning curve
> is unnecessarily high), yet another library ecosystem, etc. C has been the
> de facto lingua franca all this time, now we are back into a tower-of-babel
> scenario with tons of programming languages, which will necessarily bloat
> the core system over time.

I'm sorry to disappoint you, but Rust is here to stay, whether you
like it or not.
For example, it's been voted the "most loved" and "most wanted"
language for a few years in a row in Stack Overflow's surveys:
https://survey.stackoverflow.co/2022/#technology-most-loved-dreaded-and-wanted
So, do you have any actionable / constructive criticism for how we do
Rust packaging in Fedora, or did you just want to post that "I hate
Rust because it's not C"?

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: F38 proposal: RPM Sequoia (System-Wide Change proposal)

On Thu, Oct 13, 2022 at 9:31 AM Kevin Kofler via devel
 wrote:
>
> Neal Gompa wrote:
> > This is also the underlying reason why Red Hat has resisted
> > implementing signed repository metadata and enforcing it by default.
> > Of course this is a bit of a catch-22 as well, as there's no
> > motivation to find a solution because neither Fedora nor RHEL offer
> > signed repository metadata despite repeated calls for it over the past
> > decade.
>
> Is signed repository metadata not basically moot now that pretty much all
> the world has moved on from unencrypted HTTP to secure HTTPS?
>

No, because when you do things like mirror repositories (especially
for private mirrors), that signature is the only way to verify the
integrity. HTTPS is only transport encryption from a particular
connection.

Also, a ton of Fedora mirrors still don't use HTTPS for various reasons.

> > Now, don't get me wrong: I'm personally extremely unhappy about having
> > to depend on the Sequoia stack for RPM PGP. I have a strong distaste
> > for the Rust community ecosystem these days, and I don't love the idea
> > of having to have LLVM in the core bootstrap chain (hopefully gcc-rs
> > will be in place soon enough!).
>
> The dependency on LLVM is not even the worst issue in my eyes. LLVM is also
> used by other core projects, e.g., mesa, these days.
>
> The worst issue I see with Rust is the way libraries are "packaged", which
> just implies installing source code and recompiling that source code for
> every single application. (And as a result, the output obviously gets
> statically linked into the application, with all the drawbacks of static
> linking.) I consider a language with no usable shared library support to be
> entirely unpackageable and hence entirely useless.
>
> And then of course there is the issue that it is yet another language with
> yet another syntax (and an only partially C-like one, so the learning curve
> is unnecessarily high), yet another library ecosystem, etc. C has been the
> de facto lingua franca all this time, now we are back into a tower-of-babel
> scenario with tons of programming languages, which will necessarily bloat
> the core system over time.
>
> > So here we are, in a subpar situation created by bad tools because
> > nobody cares enough about security anyway.
>
> Sounds like a mess indeed.
>

Well, it might still be worthwhile to split out RPM's OpenPGP
implementation into its own project and allow people to contribute to
it. The worst that can happen is that nothing changes.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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: F38 proposal: RPM Sequoia (System-Wide Change proposal)

Neal Gompa wrote:
> This is also the underlying reason why Red Hat has resisted
> implementing signed repository metadata and enforcing it by default.
> Of course this is a bit of a catch-22 as well, as there's no
> motivation to find a solution because neither Fedora nor RHEL offer
> signed repository metadata despite repeated calls for it over the past
> decade.

Is signed repository metadata not basically moot now that pretty much all 
the world has moved on from unencrypted HTTP to secure HTTPS?

> Now, don't get me wrong: I'm personally extremely unhappy about having
> to depend on the Sequoia stack for RPM PGP. I have a strong distaste
> for the Rust community ecosystem these days, and I don't love the idea
> of having to have LLVM in the core bootstrap chain (hopefully gcc-rs
> will be in place soon enough!).

The dependency on LLVM is not even the worst issue in my eyes. LLVM is also 
used by other core projects, e.g., mesa, these days.

The worst issue I see with Rust is the way libraries are "packaged", which 
just implies installing source code and recompiling that source code for 
every single application. (And as a result, the output obviously gets 
statically linked into the application, with all the drawbacks of static 
linking.) I consider a language with no usable shared library support to be 
entirely unpackageable and hence entirely useless.

And then of course there is the issue that it is yet another language with 
yet another syntax (and an only partially C-like one, so the learning curve 
is unnecessarily high), yet another library ecosystem, etc. C has been the 
de facto lingua franca all this time, now we are back into a tower-of-babel 
scenario with tons of programming languages, which will necessarily bloat 
the core system over time.

> So here we are, in a subpar situation created by bad tools because
> nobody cares enough about security anyway.

Sounds like a mess indeed.

Kevin Kofler
___
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: Copr delete-by-default expiration policy still unacceptable

2022-10-13 Thread Stephen Smoogen

On Thu, 13 Oct 2022 at 08:49, Kevin Kofler via devel <
devel@lists.fedoraproject.org> wrote:

> Miroslav Suchý wrote:
> > Dne 13. 10. 22 v 6:12 Kevin Kofler via devel napsal(a):
> >> I am really angry at Copr's expiration policy once again. It looks like
> I
> >> missed the deadline to renew the expired chroots (I still do not get any
> >> notification mails, they end up eaten in a spam filter somewhere), so
> >> once again a lot of data was deleted forever with no way to recover it.
> > What is your proposal then? The resources are not infinite.
>
> At least allow the opt-out per maintainer.
>
> I would suggest to add the permanent opt-out checkbox, mark it "(BETA)",
> and
> then evaluate how many maintainers actually check that checkbox and how
> much
> resource usage is actually caused by it. Then after a year or two, decide
> whether to keep the checkbox or revert to the current status quo. Or drop
> it
> sooner if you really run out of disk space as quickly as you seem to
> expect.
>
>
The problem is that they HAVE been running out of disk space quite
regularly. This is not a new problem as COPR has bounced off of zero
storage over time as various 'newer' hardware is moved over for their
usage. Currently, the storage they are using is an aging disk service which
will go out of warranty in about a year. As far as I know, there is no
budget to buy more disk space for this project. Instead there is a long
list of complaints from the community which usually get aggregated up as
'this is not working, why do we still invest in it?'


-- 
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
___
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 2134433] Please build Net::INET6Glue for EPEL 9

https://bugzilla.redhat.com/show_bug.cgi?id=2134433



--- Comment #2 from Steve Traylen  ---
I was wandering that myself.

I blindly decided that since the module was still in Fedora it was still
needed.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2134433
___
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: Copr delete-by-default expiration policy still unacceptable

Miroslav Suchý wrote:
> Dne 13. 10. 22 v 6:12 Kevin Kofler via devel napsal(a):
>> I am really angry at Copr's expiration policy once again. It looks like I
>> missed the deadline to renew the expired chroots (I still do not get any
>> notification mails, they end up eaten in a spam filter somewhere), so
>> once again a lot of data was deleted forever with no way to recover it.
> What is your proposal then? The resources are not infinite.

At least allow the opt-out per maintainer.

I would suggest to add the permanent opt-out checkbox, mark it "(BETA)", and 
then evaluate how many maintainers actually check that checkbox and how much 
resource usage is actually caused by it. Then after a year or two, decide 
whether to keep the checkbox or revert to the current status quo. Or drop it 
sooner if you really run out of disk space as quickly as you seem to expect.

>> (By the way, I have since entirely deleted 3 deprecated Coprs that do not
>> have builds for newer releases and hence stopped being useful entirely as
>> a result.)
> ??? If you have enabled "Follow Fedora branching" (per-project setting)
> then all your packages are automatically rebuild for new Fedora version
> when it is added to Copr. And your project will be always up2date.

Patched mesa builds based on an ancient Fedora mesa package are not going to 
be of any use on current Fedora releases, which is why I had not enabled 
those autorebuilds for that Copr. I no longer build the nouveau-locking-
patched mesa, and in fact, I believe the issue has finally been fixed 
upstream since, years later.

The other 2 repositories were about providing a stable Wesnoth on a Fedora 
release that shipped with an unstable version, but that stable version is 
now really outdated (there has been at least one new stable release since), 
so I deliberately did not support that Copr on current Fedora.

But now it is also no longer available for those Fedora releases that I did 
intend to support.

> BTW email is not the only one notification we have. If some of yours
> chroot are flagged as EOL you will be shown this banner in WebUI:
> 
> Some of the chroots you maintain are *newly marked EOL*, and will be
> removed in the future. Please review
> https://copr.fedorainfracloud.org/user/repositories/ to hide this warning.

That assumes I actually log into Copr, otherwise I will never see the 
message.

Maybe only start the timer if the maintainer actually logs into Copr and 
sees the banner?

>> PS: At the very least, you could add a checkbox to allow a maintainer to
>> opt out permanently of automatic expiration (it would still be possible
>> to
>
> This is not a solution as it does not comes with solution where we get the
> storage.

I am not convinced that the storage requirements will actually skyrocket as 
quickly as you expect. As I wrote, I would suggest trying it out and 
evaluating what happens.

>> manually click on "Expire now"), as opposed to having to click dozens of
>> buttons (an everincreasing number, since there is not even an "Extend
>> all" button) at least every 180 days (in practice, more often, or you end
>> up missing the deadline). That is a very unfriendly dark pattern.
> 
> We did not put there "Extend all" intentionally. With the intent that you
> have to consider each project separately and think about if you still
> really needed.

That is exactly the definition of a dark pattern.

> BTW: I am curious what is your use-case to keep **dozens** EOL
> repositories (which means F34-) alive?

A handful Coprs * several EOL releases * several architectures = dozens of 
buttons to click.

Kevin Kofler
___
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: Advice needed: Pantheon desktop broken on Fedora 37 (yes, worse than usual)

2022-10-13 Thread Fabio Valentini

On Wed, Aug 24, 2022 at 12:55 AM Miro Hrončok  wrote:
>
> On 23. 08. 22 23:46, Fabio Valentini wrote:
> > even if the advice is: "yes, retire the packages, rather
> > than leave them broken, they can be added back once they have been
> > fixed"
>
> Knowing nothing about Pantheon or GObject C, I do think this is always better
> than noninstallable packages. So if all other efforts fail, I would retire the
> packages before Final Freeze and only introduce them back if ever fixed.
>
> Yes, it may be emotionally a bit painful, but IMHO it gives a clearer message
> to our users if the package is missing rather than utterly broken.

To come back to this issue: I ended up retiring all packages for the
Pantheon desktop and elementary applications from Fedora 37. This
turned out to have been the right move, since Pantheon desktop
components and some apps are still not compatible with libraries from
GNOME 43 (mutter 43 / evolution-data-server 3.45+ / libsoup3 / etc),
and we're already in the Final Freeze now - so getting things fixed in
time for Fedora 37 would have been extremely unlikely.

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 2134433] Please build Net::INET6Glue for EPEL 9

https://bugzilla.redhat.com/show_bug.cgi?id=2134433

Petr Pisar  changed:

   What|Removed |Added

 CC||ppi...@redhat.com
   Doc Type|--- |If docs needed, set a value



--- Comment #1 from Petr Pisar  ---
Is this module really needed? Or just somebody forgot the remove an unused
dependency? As far as I know all the modules Net::INET6Glue patches support
IPv6 natively.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2134433
___
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: What if we excluded 32bit ARM from Python 3.12

2022-10-13 Thread Petr Viktorin

Makes sense. It's a new package. I see nothing wrong with excluding it, 
to see what breaks & who complains.



On 13. 10. 22 11:07, Miro Hrončok wrote:

Hello Pythonistas,

we are probably going to package python3.12 soon for all Fedora releases.

Unfortunately, building Python for 32bit ARM has been very tedious 
lately, as the Koji build keeps restarting and the build takes 24+ hours 
to finish.


Considering 32bit ARM is gone from Fedora 37+, I was considering the 
ExcludeArch it from the python3.12 package even on older Fedoras, to 
make the builds easier.


Would anybody be sad about that?


___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-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/python-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2134433] New: Please build Net::INET6Glue for EPEL 9

https://bugzilla.redhat.com/show_bug.cgi?id=2134433

Bug ID: 2134433
   Summary: Please build Net::INET6Glue for EPEL 9
   Product: Fedora EPEL
   Version: epel9
Status: NEW
 Component: perl-Net-INET6Glue
  Assignee: emman...@seyman.fr
  Reporter: steve.tray...@cern.ch
QA Contact: extras...@fedoraproject.org
CC: emman...@seyman.fr, ktdre...@ktdreyer.com,
perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Hi,

Please could perl-Net-INET6Glue be build for EPEL9

I verified that the current rawhide package both builds and can be installed
within an alma+mock 9 mock build.

perl-Net-INET6Glue-0.604-6.el9.noarch

Steve.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2134433
___
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: F38 proposal: RPM Sequoia (System-Wide Change proposal)

On Thu, Oct 13, 2022 at 4:24 AM Panu Matilainen  wrote:
>
> On 10/13/22 10:53, Neal Gompa wrote:
> > On Thu, Oct 13, 2022 at 3:29 AM Panu Matilainen  wrote:
> >>
> >> On 10/13/22 07:18, Kevin Kofler via devel wrote:
>  For the last 20 years or so, RPM has used a home-grown OpenPGP parser
>  for dealing with keys and signatures. That parser is rather infamous
>  for its limitations and flaws, and especially in recent years has
>  proven a significant burden to RPM development. In order to improve
>  security and free developer resources for dealing with RPM's "core
>  business" instead, RPM upstream is in the process of deprecating the
>  internal parser in favor of [https://sequoia-pgp.org/ Sequoia PGP]
>  based solution written in Rust.
> >>>
> >>> Why are you using a new library written in Rust? Can you not use one of 
> >>> the
> >>> existing mature C implementations of OpenPGP? gpgme maybe?
> >>
> >> Had there been such an option, we would've switched over years ago.
> >> Gpgme is based around calling and communicating with an external gpg
> >> process, which is a setup you do NOT want in the rpm context where
> >> chroots come and go etc. Also, rpm requires access to the "low-level"
> >> digests-in-progress because it calculates multiple things on a single read.
> >>
> >
> > The real problem is that all other OpenPGP implementations died out
> > because of GnuPG. And then GnuPG made the choice to force an
> > inter-process model.
> >
> > At work, I deal with this on Debian systems, which do indeed use GnuPG
> > for this. It creates a lot of problems, especially for building images
> > and dealing with chroots, which is why in the context of RPM PGP
> > upstream, I never pushed to consider it.
> >
> > The most serious problems with PackageKit memory leaks and hangs are
> > actually caused by GnuPG, since DNF uses it for some GPG stuff because
> > there's no API for using RPM's PGP capabilities. There's no fix unless
> > the RPM and DNF teams agree on an API and build it out so that libdnf
> > and librepo no longer need to use GnuPG through gpgme anymore.
> >
> > This is also the underlying reason why Red Hat has resisted
> > implementing signed repository metadata and enforcing it by default.
> > Of course this is a bit of a catch-22 as well, as there's no
> > motivation to find a solution because neither Fedora nor RHEL offer
> > signed repository metadata despite repeated calls for it over the past
> > decade.
> >
> > Now, don't get me wrong: I'm personally extremely unhappy about having
> > to depend on the Sequoia stack for RPM PGP. I have a strong distaste
> > for the Rust community ecosystem these days, and I don't love the idea
> > of having to have LLVM in the core bootstrap chain (hopefully gcc-rs
> > will be in place soon enough!). But we literally don't have any other
> > options. GnuPG/GPGME is out of the question for the reasons Panu and I
> > stated, and NeoPG died several years ago. There are no C/C++ libraries
> > for OpenPGP verification.
>
> There's RNP (in C++, used by Thunderbird at least), but alas that
> doesn't expose the digest-in-progress either. So at least in it's
> current form, it's not an option for rpm. Also, the API appears to have
> all manner of quirks and gotchas that aren't welcome in a
> security-critical piece.
>

Huh, I'd forgotten about RNP. It seems it now has an OpenSSL backend
and at least the verification API (which is what RPM would use) seems
to be getting love lately. Insofar as quirks and gotchas, I'm not a
great judge of that at the moment, but I don't think it could be worse
than what we have with GnuPG.

The missing "digest-in-progress" thing is an issue, I guess. Have we
raised the issue with them about it?

> As for bootstrap, there will always (have to) be a way to build rpm
> without depending on Rust. Even if that meant no signature verification
> support in such a configuration.
>

Eck. What about the x509 based stuff we were talking about last year?
All the crypto backends RPM supports now support that stuff out of the
box.

Embedded x509 signatures (certs) to replace GPG signatures could work
as an alternative.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Fedora 37 compose report: 20221013.n.0 changes

2022-10-13 Thread Fedora Rawhide Report

OLD: Fedora-37-20221012.n.0
NEW: Fedora-37-20221013.n.0

= SUMMARY =
Added images:0
Dropped images:  1
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 =
Image: Kinoite dvd-ostree x86_64
Path: Kinoite/x86_64/iso/Fedora-Kinoite-ostree-x86_64-37-20221012.n.0.iso

= 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

[Bug 2134185] perl-HTML-Parser-3.79 is available

https://bugzilla.redhat.com/show_bug.cgi?id=2134185



--- Comment #2 from Fedora Update System  ---
FEDORA-2022-36fa644cae has been submitted as an update to Fedora 35.
https://bodhi.fedoraproject.org/updates/FEDORA-2022-36fa644cae


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2134185
___
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 2134185] perl-HTML-Parser-3.79 is available

https://bugzilla.redhat.com/show_bug.cgi?id=2134185



--- Comment #1 from Fedora Update System  ---
FEDORA-2022-5cf0dcb7f2 has been submitted as an update to Fedora 37.
https://bodhi.fedoraproject.org/updates/FEDORA-2022-5cf0dcb7f2


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2134185
___
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 2134185] perl-HTML-Parser-3.79 is available

https://bugzilla.redhat.com/show_bug.cgi?id=2134185



--- Comment #3 from Fedora Update System  ---
FEDORA-2022-79189ab269 has been submitted as an update to Fedora 36.
https://bodhi.fedoraproject.org/updates/FEDORA-2022-79189ab269


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2134185
___
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 rawhide compose report: 20221013.n.0 changes

2022-10-13 Thread Fedora Rawhide Report

OLD: Fedora-Rawhide-20221012.n.0
NEW: Fedora-Rawhide-20221013.n.0

= SUMMARY =
Added images:2
Dropped images:  6
Added packages:  5
Dropped packages:23
Upgraded packages:   81
Downgraded packages: 0

Size of added packages:  4.44 MiB
Size of dropped packages:16.67 MiB
Size of upgraded packages:   2.78 GiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   15.23 MiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =
Image: Container_Base docker aarch64
Path: 
Container/aarch64/images/Fedora-Container-Base-Rawhide-20221013.n.0.aarch64.tar.xz
Image: Kinoite dvd-ostree ppc64le
Path: Kinoite/ppc64le/iso/Fedora-Kinoite-ostree-ppc64le-Rawhide-20221013.n.0.iso

= DROPPED IMAGES =
Image: Xfce raw-xz aarch64
Path: Spins/aarch64/images/Fedora-Xfce-Rawhide-20221012.n.0.aarch64.raw.xz
Image: Container_Minimal_Base docker aarch64
Path: 
Container/aarch64/images/Fedora-Container-Minimal-Base-Rawhide-20221012.n.0.aarch64.tar.xz
Image: Silverblue dvd-ostree ppc64le
Path: 
Silverblue/ppc64le/iso/Fedora-Silverblue-ostree-ppc64le-Rawhide-20221012.n.0.iso
Image: KDE raw-xz aarch64
Path: Spins/aarch64/images/Fedora-KDE-Rawhide-20221012.n.0.aarch64.raw.xz
Image: Container_Minimal_Base docker s390x
Path: 
Container/s390x/images/Fedora-Container-Minimal-Base-Rawhide-20221012.n.0.s390x.tar.xz
Image: Container_Base docker ppc64le
Path: 
Container/ppc64le/images/Fedora-Container-Base-Rawhide-20221012.n.0.ppc64le.tar.xz

= ADDED PACKAGES =
Package: python-mistune08-0.8.4-7.fc38
Summary: Markdown parser for Python
RPMs:python3-mistune08
Size:39.36 KiB

Package: python-poetry-plugin-export-1.1.1-2.fc38
Summary: Poetry plugin to export the dependencies to various formats
RPMs:python3-poetry-plugin-export
Size:34.26 KiB

Package: python-sphinx-typlog-theme-0.8.0-1.fc38
Summary: A Sphinx theme sponsored by Typlog
RPMs:python3-sphinx-typlog-theme
Size:32.25 KiB

Package: rust-libsodium-sys-0.2.7-1.fc38
Summary: FFI binding to libsodium
RPMs:rust-libsodium-sys+default-devel 
rust-libsodium-sys+use-pkg-config-devel rust-libsodium-sys-devel
Size:56.56 KiB

Package: vl-gothic-fonts-20220612-2.fc38
Summary: Japanese TrueType font
RPMs:vl-gothic-fonts vl-gothic-fonts-all vl-pgothic-fonts
Size:4.28 MiB


= DROPPED PACKAGES =
Package: gimp-focusblur-plugin-3.2.6-17.fc37
Summary: Simulate an out-of-focus blur
RPMs:gimp-focusblur-plugin
Size:284.30 KiB

Package: gmqcc-0.3.5-24.fc37
Summary: Improved Quake C Compiler
RPMs:gmqcc gmqpak qcvm
Size:449.21 KiB

Package: kelbt-0.16-15.fc37
Summary: Backtracking LR Parsing
RPMs:kelbt
Size:339.09 KiB

Package: perl-Parse-Debian-Packages-0.03-24.fc37
Summary: Parse the data from a Debian Packages.gz
RPMs:perl-Parse-Debian-Packages
Size:14.03 KiB

Package: php-psr-http-client-1.0.1-6.fc37
Summary: Common interface for HTTP clients
RPMs:php-psr-http-client
Size:11.49 KiB

Package: phpdoc-2.9.1-7.fc37
Summary: Documentation generator for PHP
RPMs:phpdoc
Size:1.39 MiB

Package: python-coreapi-2.3.3-9.fc37
Summary: Python client library for Core API
RPMs:python3-coreapi
Size:80.17 KiB

Package: python-coreschema-0.0.4-9.fc37
Summary: Core Schema
RPMs:python3-coreschema
Size:46.47 KiB

Package: python-drf-yasg-1.20.0-7.fc37
Summary: Automated generation of real Swagger/OpenAPI 2.0 schemas from Django 
Rest
RPMs:python3-drf-yasg python3-drf-yasg+validation
Size:909.23 KiB

Package: python-itypes-1.2.0-7.fc37
Summary: Simple immutable types for python
RPMs:python3-itypes
Size:16.42 KiB

Package: python-pacpy-1.0.3.1-16.fc37
Summary: Calculate phase-amplitude coupling in Python
RPMs:python3-pacpy
Size:709.44 KiB

Package: python-phabricator-0.7.0-20.fc37
Summary: Phabricator API Bindings
RPMs:python3-phabricator
Size:46.45 KiB

Package: python-pydenticon-0.3.1-18.fc37
Summary: Library for generating identicons
RPMs:python3-pydenticon
Size:19.12 KiB

Package: python-pytest-capturelog-0.7-27.fc37
Summary: py.test plugin to capture log messages
RPMs:python3-pytest-capturelog
Size:15.96 KiB

Package: python-qrencode-1.2~git.1.b75219e-15.fc37
Summary: Simple wrapper for the C qrencode
RPMs:python3-qrencode
Size:67.78 KiB

Package: rubygem-hiera-eyaml-3.2.0-6.fc37
Summary: Hiera backend for decrypting encrypted yaml properties
RPMs:rubygem-hiera-eyaml rubygem-hiera-eyaml-doc
Size:421.97 KiB

Package: rubygem-optimist-3.0.0-6.fc37
Summary: Commandline option parser for Ruby
RPMs:rubygem-optimist rubygem-optimist-doc
Size:352.57 KiB

Package: scram-0.16.2-15.fc37
Summary: Probabilistic Risk Analysis Tool
RPMs:scram scram-gui
Size:3.92 MiB

Package: scudcloud-1.65-16.fc37
Summary: Non official desktop client for Slack
RPMs:scudcloud
Size:101.02 KiB

Package: sgmanager-2.0.0-13+201801213git+146.861aa67.fc37
Summary: OpenStack Security Groups

[Bug 2134185] perl-HTML-Parser-3.79 is available

https://bugzilla.redhat.com/show_bug.cgi?id=2134185

Jitka Plesnikova  changed:

   What|Removed |Added

   Fixed In Version||perl-HTML-Parser-3.79-1.fc3
   ||8
 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=2134185
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[EPEL-devel] Fedora EPEL 7 updates-testing report

2022-10-13 Thread updates

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
   6  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-f174e47230   
luajit-2.0.5-1.20220913.46e62cd.el7
   6  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-3f600666f9   
python3-mod_wsgi-4.7.1-3.el7
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-e8cd6275b1   
weechat-3.6-2.el7
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-d23756a749   
apptainer-1.1.2-1.el7


The following builds have been pushed to Fedora EPEL 7 updates-testing

dmlite-1.15.2-11.el7
py-radix-0.10.0-1.el7

Details about builds:



 dmlite-1.15.2-11.el7 (FEDORA-EPEL-2022-a3e92546be)
 Lcgdm grid data management and storage framework

Update Information:

Fix issue testing missing spacetokens before DPM2dCache migration Fix minor
configuration issue with DPM to dCache 8.2 migration

ChangeLog:

* Tue Oct 11 2022 Petr Vokac  - 1.15.2-11
- Support for DPM to dCache 8.2 migration
* Thu Jul 21 2022 Fedora Release Engineering  - 
1.15.2-10
- Rebuilt for https://fedoraproject.org/wiki/Fedora_37_Mass_Rebuild
* Fri Jun 24 2022 Jonathan Wakely  - 1.15.2-9
- Remove obsolete boost-python3-devel build dependencies (#2100748)




 py-radix-0.10.0-1.el7 (FEDORA-EPEL-2022-58529dc418)
 Radix tree data structure for Python

Update Information:

- Update to upstream 0.10.0 version - Rename Python 2 (sub)package - Provide
Python 3.6 subpackage

ChangeLog:

* Sun Oct  9 2022 Robert Scheck  0.10.0-1
- Update to 0.10.0
- Rename Python 2 (sub)package and provide Python 3 subpackage


___
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 2124459] Please branch and build perl-Net-OpenSSH in epel9

https://bugzilla.redhat.com/show_bug.cgi?id=2124459

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #4 from Fedora Update System  ---
FEDORA-EPEL-2022-c7d9a171f8 has been pushed to the Fedora EPEL 9 testing
repository.

You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-c7d9a171f8

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=2124459
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[EPEL-devel] Fedora EPEL 9 updates-testing report

2022-10-13 Thread updates

The following Fedora EPEL 9 Security updates need testing:
 Age  URL
   6  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-1c6c522b07   
weechat-3.6-1.el9
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-c5646c5693   
apptainer-1.1.2-1.el9


The following builds have been pushed to Fedora EPEL 9 updates-testing

borgmatic-1.7.3-1.el9
duo_unix-1.12.1-4.el9
koji-1.30.1-1.el9
perl-Net-OpenSSH-0.82-3.el9
python-drgn-0.0.21-1.el9
python-pycdio-2.1.0-9.el9

Details about builds:



 borgmatic-1.7.3-1.el9 (FEDORA-EPEL-2022-64cd98ca6b)
 Simple Python wrapper script for borgbackup

Update Information:

-   [#357](https://projects.torsion.org/borgmatic-
collective/borgmatic/issues/357): Add "break-lock" action for removing any
repository and cache locks leftover from Borg   aborting. -
[#360](https://projects.torsion.org/borgmatic-collective/borgmatic/issues/360):
To prevent Borg hangs, unconditionally delete stale named pipes before dumping
databases. -   [#587](https://projects.torsion.org/borgmatic-
collective/borgmatic/issues/587): When database hooks are enabled, auto-exclude
special files from a "create" action to   prevent Borg from hanging. You can
override/prevent this behavior by explicitly setting the   "read_special"
option to true. -   [#587](https://projects.torsion.org/borgmatic-
collective/borgmatic/issues/587): Warn when ignoring a configured "read_special"
value of false, as true is needed when   database hooks are enabled. -
[#589](https://projects.torsion.org/borgmatic-collective/borgmatic/issues/589):
Update sample systemd service file to allow system "idle" (e.g. a video monitor
turning   off) while borgmatic is running. -
[#590](https://projects.torsion.org/borgmatic-collective/borgmatic/issues/590):
Fix for potential data loss (data not getting backed up) when the
"patterns_from" option   was used with "source_directories" (or the
"~/.borgmatic" path existed, which got injected into   "source_directories"
implicitly). The fix is for borgmatic to convert "source_directories" into
patterns whenever "patterns_from" is used, working around a Borg bug:   [htt
ps://github.com/borgbackup/borg/issues/6994](https://github.com/borgbackup/borg/
issues/6994) -   [#590](https://projects.torsion.org/borgmatic-
collective/borgmatic/issues/590): In "borgmatic create --list" output, display
which files get excluded from the backup due   to patterns or excludes. -
[#591](https://projects.torsion.org/borgmatic-collective/borgmatic/issues/591):
Add support for Borg 2's "--match-archives" flag. This replaces "--glob-
archives", which   borgmatic now treats as an alias for "--match-archives".
But note that the two flags have   slightly different syntax. See the Borg 2
changelog for more information:   [https://borgbackup.readthedocs.io/en/2.0.
0b3/changes.html#version-2-0-0b3-2022-10-
02](https://borgbackup.readthedocs.io/en/2.0.0b3/changes.html#version-2-0-0b3-
2022-10-02) -   Fix for "borgmatic --archive latest" not finding the latest
archive when a verbosity is set.

ChangeLog:

* Wed Oct 12 2022 Felix Kaechele  - 1.7.3-1
- update to 1.7.3

References:

  [ 1 ] Bug #2134188 - borgmatic-1.7.3 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2134188




 duo_unix-1.12.1-4.el9 (FEDORA-EPEL-2022-f4a2800a35)
 Duo two-factor authentication for UNIX systems

Update Information:

Add Recommends for pam_duo to the main package to prevent potential lockout

ChangeLog:

* Wed Oct 12 2022 Davide Cavalca  - 1.12.1-4
- Add Recommends for pam_duo to the main package to prevent potential lockout
  issues (Fixes: RHBZ#2134160)

References:

  [ 1 ] Bug #2134160 - Main package should pull in pam_duo to avoid lockout
https://bugzilla.redhat.com/show_bug.cgi?id=2134160




 koji-1.30.1-1.el9 (FEDORA-EPEL-2022-0e957e3cf8)
 Build system tools

Update Information:

Update to upstream bugfix release 1.30.1.

[Bug 2134185] perl-HTML-Parser-3.79 is available

https://bugzilla.redhat.com/show_bug.cgi?id=2134185

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Doc Type|--- |If docs needed, set a value
 CC|caillon+fedoraproject@gmail |
   |.com, caol...@redhat.com,   |
   |jples...@redhat.com,|
   |ka...@ucw.cz,   |
   |mspa...@redhat.com, |
   |rhug...@redhat.com, |
   |rstr...@redhat.com, |
   |sandm...@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=2134185
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[EPEL-devel] Fedora EPEL 8 updates-testing report

2022-10-13 Thread updates

The following Fedora EPEL 8 Security updates need testing:
 Age  URL
   6  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-56709b917a   
weechat-3.6-1.el8
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-56c3cc55b3   
apptainer-1.1.2-1.el8


The following builds have been pushed to Fedora EPEL 8 updates-testing

dmlite-1.15.2-11.el8
duo_unix-1.12.1-4.el8
koji-1.30.1-1.el8
python-drgn-0.0.21-1.el8

Details about builds:



 dmlite-1.15.2-11.el8 (FEDORA-EPEL-2022-86257ff758)
 Lcgdm grid data management and storage framework

Update Information:

Fix issue testing missing spacetokens before DPM2dCache migration Fix minor
configuration issue with DPM to dCache 8.2 migration

ChangeLog:

* Tue Oct 11 2022 Petr Vokac  - 1.15.2-11
- Support for DPM to dCache 8.2 migration
* Thu Jul 21 2022 Fedora Release Engineering  - 
1.15.2-10
- Rebuilt for https://fedoraproject.org/wiki/Fedora_37_Mass_Rebuild
* Fri Jun 24 2022 Jonathan Wakely  - 1.15.2-9
- Remove obsolete boost-python3-devel build dependencies (#2100748)




 duo_unix-1.12.1-4.el8 (FEDORA-EPEL-2022-07b2763e76)
 Duo two-factor authentication for UNIX systems

Update Information:

Add Recommends for pam_duo to the main package to prevent potential lockout

ChangeLog:

* Wed Oct 12 2022 Davide Cavalca  - 1.12.1-4
- Add Recommends for pam_duo to the main package to prevent potential lockout
  issues (Fixes: RHBZ#2134160)

References:

  [ 1 ] Bug #2134160 - Main package should pull in pam_duo to avoid lockout
https://bugzilla.redhat.com/show_bug.cgi?id=2134160
  [ 2 ] Bug #2134211 - Missing pam_duo.so in duo_unix-1.12.1-3.el8.x86_64
https://bugzilla.redhat.com/show_bug.cgi?id=2134211




 koji-1.30.1-1.el8 (FEDORA-EPEL-2022-f6ffc03f2a)
 Build system tools

Update Information:

Update to upstream bugfix release 1.30.1.

ChangeLog:

* Wed Oct 12 2022 Kevin Fenzi  - 1.30.1-1
- Update to 1.30.1. Fixed rhbz#2133004




 python-drgn-0.0.21-1.el8 (FEDORA-EPEL-2022-5419ea9ce2)
 Programmable debugger

Update Information:

Update to 0.0.21; Fixes: RHBZ#2134210

ChangeLog:

* Wed Oct 12 2022 Davide Cavalca  0.0.21-1
- Update to 0.0.21; Fixes: RHBZ#2134210
* Sat Aug  6 2022 Michel Alexandre Salim  0.0.20-2
- Rebuilt for libkdumpfile.so.10

References:

  [ 1 ] Bug #2134210 - python-drgn-0.0.21 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2134210


___
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: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

2022-10-13 Thread Pierre-Yves Chibon

On Thu, Oct 13, 2022 at 10:36:52AM +0300, Panu Matilainen wrote:
> On 10/12/22 17:47, Stephen Smoogen wrote:
> > 
> > 
> > On Wed, 12 Oct 2022 at 10:32, Kevin P. Fleming  > > wrote:
> > 
> > On 10/12/22 08:59, Stephen Smoogen wrote:
> >  > Maybe call it the Fedora Update Manager 'FUM' ?
> > 
> > Unless we're going to call it RUM when it makes its way into RHEL, that
> > name may not be the best choice :-)
> > 
> > 
> > Well Red Hat shipped the Yellowdog Update Manager for 2 releases so I am
> > sure they can go with FUM or RUM (RPM Update Manager)..
> 
> RPM Update Manager, an easily pronouncable and distro agnostic acronym which
> even makes sense. Now that would be a hard sell...

Depends, once the age question is resolved, buying RUM should be fairly straight
forward :-p


Pierre
___
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: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

2022-10-13 Thread Mattia Verga via devel

So, coming back to the steps needed for this to happen as discussed in the 
FESCo ticket, I think the first one is to decide how users can start testing 
dnf5 on "expendable" machines.

The proposal says that dnf5 can be installed in parallel with dnf. I think this 
doesn't highlight what things will be broken, as tools will still use dnf. 
Also, @zbysek asked in the FESCo ticket what data from the RPM database is 
shared between the two, but didn't receive a reply: say, as a user, I install 
dnf5 in parallel with dnf, will I be able to "dnf install foo" and then "dnf5 
uninstall foo"?

For those two things I wrote above, if in the end dnf5 will be renamed back as 
dnf to be a drop in replacement, wouldn't be better to have dnf5 obsolete dnf 
starting from now? I don't think anyone is going to test it on a production 
machine anyway...

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

What if we excluded 32bit ARM from Python 3.12

2022-10-13 Thread Miro Hrončok


Hello Pythonistas,

we are probably going to package python3.12 soon for all Fedora releases.

Unfortunately, building Python for 32bit ARM has been very tedious lately, as 
the Koji build keeps restarting and the build takes 24+ hours to finish.


Considering 32bit ARM is gone from Fedora 37+, I was considering the 
ExcludeArch it from the python3.12 package even on older Fedoras, to make the 
builds easier.


Would anybody be sad about that?

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-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/python-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: RPM Sequoia (System-Wide Change proposal)

2022-10-13 Thread Panu Matilainen


On 10/13/22 10:53, Neal Gompa wrote:

On Thu, Oct 13, 2022 at 3:29 AM Panu Matilainen  wrote:


On 10/13/22 07:18, Kevin Kofler via devel wrote:

For the last 20 years or so, RPM has used a home-grown OpenPGP parser
for dealing with keys and signatures. That parser is rather infamous
for its limitations and flaws, and especially in recent years has
proven a significant burden to RPM development. In order to improve
security and free developer resources for dealing with RPM's "core
business" instead, RPM upstream is in the process of deprecating the
internal parser in favor of [https://sequoia-pgp.org/ Sequoia PGP]
based solution written in Rust.


Why are you using a new library written in Rust? Can you not use one of the
existing mature C implementations of OpenPGP? gpgme maybe?


Had there been such an option, we would've switched over years ago.
Gpgme is based around calling and communicating with an external gpg
process, which is a setup you do NOT want in the rpm context where
chroots come and go etc. Also, rpm requires access to the "low-level"
digests-in-progress because it calculates multiple things on a single read.



The real problem is that all other OpenPGP implementations died out
because of GnuPG. And then GnuPG made the choice to force an
inter-process model.

At work, I deal with this on Debian systems, which do indeed use GnuPG
for this. It creates a lot of problems, especially for building images
and dealing with chroots, which is why in the context of RPM PGP
upstream, I never pushed to consider it.

The most serious problems with PackageKit memory leaks and hangs are
actually caused by GnuPG, since DNF uses it for some GPG stuff because
there's no API for using RPM's PGP capabilities. There's no fix unless
the RPM and DNF teams agree on an API and build it out so that libdnf
and librepo no longer need to use GnuPG through gpgme anymore.

This is also the underlying reason why Red Hat has resisted
implementing signed repository metadata and enforcing it by default.
Of course this is a bit of a catch-22 as well, as there's no
motivation to find a solution because neither Fedora nor RHEL offer
signed repository metadata despite repeated calls for it over the past
decade.

Now, don't get me wrong: I'm personally extremely unhappy about having
to depend on the Sequoia stack for RPM PGP. I have a strong distaste
for the Rust community ecosystem these days, and I don't love the idea
of having to have LLVM in the core bootstrap chain (hopefully gcc-rs
will be in place soon enough!). But we literally don't have any other
options. GnuPG/GPGME is out of the question for the reasons Panu and I
stated, and NeoPG died several years ago. There are no C/C++ libraries
for OpenPGP verification.


There's RNP (in C++, used by Thunderbird at least), but alas that 
doesn't expose the digest-in-progress either. So at least in it's 
current form, it's not an option for rpm. Also, the API appears to have 
all manner of quirks and gotchas that aren't welcome in a 
security-critical piece.


As for bootstrap, there will always (have to) be a way to build rpm 
without depending on Rust. Even if that meant no signature verification 
support in such a configuration.




If there was *any other choice*, we would have taken it. Even
splitting out RPM's internal OpenPGP code into its own project for
someone to rework and upgrade would be an option if someone actually
wanted to. The reality is that nobody wants to work on that.


Yep. In case there's any doubt, I too would've much, MUCH, VERY MUCH 
preferred a C (or even C++) library but in the ~15 years I've been on 
the lookout, no viable and credible candidates have appeared.
Rpm will remain open to alternative backends, should such a thing 
emerge, but I'm not holding my breath.


- Panu -




So here we are, in a subpar situation created by bad tools because
nobody cares enough about security anyway.








--
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

2022-10-13 Thread Vít Ondruch

Heh, I would really prefer to stay with "dnf", but thx everybody for 
brainstorming the name. I like the proposals ;)



Vít


Dne 12. 10. 22 v 15:59 Stephen Smoogen napsal(a):



On Wed, 12 Oct 2022 at 09:49, Miroslav Suchý  wrote:

Dne 12. 10. 22 v 12:28 Vít Ondruch napsal(a):
> So since I don't think the DNF5 name and especially the package
name was elaborated here and my wish in package review
> to have the package name just `dnf` was completely ignored [1],
I'll ask here.
>
> Why `dnf5` and not `dnf` version 5. If it is not DNF and it
needs different name, then please rather name it `foobar`.
> I think that introducing the version into name is wrong (with
exception of compat packages) and I think that DNF
> should lead by example and not abusing the package name for version.

My opinion is that it should not be packaged as "dnf" until it is
ready to fully replace DNFv4. And that will take some
time. I think it is fine to introduce it now in Fedora as "dnf5"
package. And later rename it to "dnf".


Maybe call it the Fedora Update Manager 'FUM' ?

Miroslav
___
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



--
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard 
battle. -- Ian MacClaren


___
devel mailing list --devel@lists.fedoraproject.org
To unsubscribe send an email todevel-le...@lists.fedoraproject.org
Fedora Code of 
Conduct:https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines
List 
Archives:https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report 
it:https://pagure.io/fedora-infrastructure/new_issue


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: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

2022-10-13 Thread Vít Ondruch



Dne 12. 10. 22 v 15:48 Miroslav Suchý napsal(a):

Dne 12. 10. 22 v 12:28 Vít Ondruch napsal(a):
So since I don't think the DNF5 name and especially the package name 
was elaborated here and my wish in package review to have the package 
name just `dnf` was completely ignored [1], I'll ask here.


Why `dnf5` and not `dnf` version 5. If it is not DNF and it needs 
different name, then please rather name it `foobar`. I think that 
introducing the version into name is wrong (with exception of compat 
packages) and I think that DNF should lead by example and not abusing 
the package name for version.


My opinion is that it should not be packaged as "dnf" until it is 
ready to fully replace DNFv4. And that will take some time. I think it 
is fine to introduce it now in Fedora as "dnf5" package. And later 
rename it to "dnf".



There are following statements in the "Scope" section of current change 
proposal:


* Obsolete dnf package by dnf5

* Modify comps groups to replace dnf or yum by dnf5

This does not suggest that "And later rename it to "dnf"." is the plan.

But if it is the plan, then I'd love to see it documented in the change 
proposal. Of course the rename back to "dnf" should happen prior various 
places and especially documentation gets updated to "dnf5".




Vít




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

[Bug 2134212] perl-Finance-Quote-1.5301 is available

https://bugzilla.redhat.com/show_bug.cgi?id=2134212



--- Comment #2 from Paul Howarth  ---
Hi Gwyn,

I was going to close this WONTFIX because the only change between 1.53 and
1.5301 is the addition of an explicit dependency on LWP::Protocol::https but we
have that in our downstream packaging already.

Moreover, the 1.5301 version number will mean that when 1.54 comes out, we'll
need to either call it 1.5400 for RPM versioning or we'll need to add an epoch.
Which would be your preference?


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2134212
___
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: Copr delete-by-default expiration policy still unacceptable

2022-10-13 Thread Miroslav Suchý

Dne 13. 10. 22 v 6:12 Kevin Kofler via devel napsal(a):

I am really angry at Copr's expiration policy once again. It looks like I
missed the deadline to renew the expired chroots (I still do not get any
notification mails, they end up eaten in a spam filter somewhere), so once
again a lot of data was deleted forever with no way to recover it.

What is your proposal then? The resources are not infinite.

(By the way, I have since entirely deleted 3 deprecated Coprs that do not
have builds for newer releases and hence stopped being useful entirely as a
result.)
??? If you have enabled "Follow Fedora branching" (per-project setting) then all your packages are automatically rebuild
for new Fedora version when it is added to Copr. And your project will be always up2date.

The assumption that users will receive notifications mails and act on them
is still entirely invalid (because e-mail is not a certified delivery
method, mails can get lost at any time), and deleting data is not and will
never be a safe default. The default must be to retain, not to delete.
BTW email is not the only one notification we have. If some of yours chroot are flagged as EOL you will be shown this
banner in WebUI:

Some of the chroots you maintain are *newly marked EOL*, and will be removed in the future. Please review
https://copr.fedorainfracloud.org/user/repositories/ to hide this warning.

PS: At the very least, you could add a checkbox to allow a maintainer to opt
out permanently of automatic expiration (it would still be possible to

This is not a solution as it does not comes with solution where we get the
storage.

manually click on "Expire now"), as opposed to having to click dozens of
buttons (an everincreasing number, since there is not even an "Extend all"
button) at least every 180 days (in practice, more often, or you end up
missing the deadline). That is a very unfriendly dark pattern.

We did not put there "Extend all" intentionally. With the intent that you have to consider each project separately and
think about if you still really needed.

BTW: I am curious what is your use-case to keep **dozens** EOL repositories
(which means F34-) alive?

Miroslav___
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: F38 proposal: RPM Sequoia (System-Wide Change proposal)

On Thu, Oct 13, 2022 at 3:29 AM Panu Matilainen  wrote:
>
> On 10/13/22 07:18, Kevin Kofler via devel wrote:
> >> For the last 20 years or so, RPM has used a home-grown OpenPGP parser
> >> for dealing with keys and signatures. That parser is rather infamous
> >> for its limitations and flaws, and especially in recent years has
> >> proven a significant burden to RPM development. In order to improve
> >> security and free developer resources for dealing with RPM's "core
> >> business" instead, RPM upstream is in the process of deprecating the
> >> internal parser in favor of [https://sequoia-pgp.org/ Sequoia PGP]
> >> based solution written in Rust.
> >
> > Why are you using a new library written in Rust? Can you not use one of the
> > existing mature C implementations of OpenPGP? gpgme maybe?
>
> Had there been such an option, we would've switched over years ago.
> Gpgme is based around calling and communicating with an external gpg
> process, which is a setup you do NOT want in the rpm context where
> chroots come and go etc. Also, rpm requires access to the "low-level"
> digests-in-progress because it calculates multiple things on a single read.
>

The real problem is that all other OpenPGP implementations died out
because of GnuPG. And then GnuPG made the choice to force an
inter-process model.

At work, I deal with this on Debian systems, which do indeed use GnuPG
for this. It creates a lot of problems, especially for building images
and dealing with chroots, which is why in the context of RPM PGP
upstream, I never pushed to consider it.

The most serious problems with PackageKit memory leaks and hangs are
actually caused by GnuPG, since DNF uses it for some GPG stuff because
there's no API for using RPM's PGP capabilities. There's no fix unless
the RPM and DNF teams agree on an API and build it out so that libdnf
and librepo no longer need to use GnuPG through gpgme anymore.

This is also the underlying reason why Red Hat has resisted
implementing signed repository metadata and enforcing it by default.
Of course this is a bit of a catch-22 as well, as there's no
motivation to find a solution because neither Fedora nor RHEL offer
signed repository metadata despite repeated calls for it over the past
decade.

Now, don't get me wrong: I'm personally extremely unhappy about having
to depend on the Sequoia stack for RPM PGP. I have a strong distaste
for the Rust community ecosystem these days, and I don't love the idea
of having to have LLVM in the core bootstrap chain (hopefully gcc-rs
will be in place soon enough!). But we literally don't have any other
options. GnuPG/GPGME is out of the question for the reasons Panu and I
stated, and NeoPG died several years ago. There are no C/C++ libraries
for OpenPGP verification.

If there was *any other choice*, we would have taken it. Even
splitting out RPM's internal OpenPGP code into its own project for
someone to rework and upgrade would be an option if someone actually
wanted to. The reality is that nobody wants to work on that.

So here we are, in a subpar situation created by bad tools because
nobody cares enough about security anyway.

--
真実はいつも一つ！/ Always, there's only one truth!
___
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: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

2022-10-13 Thread Panu Matilainen


On 10/12/22 17:47, Stephen Smoogen wrote:



On Wed, 12 Oct 2022 at 10:32, Kevin P. Fleming > wrote:


On 10/12/22 08:59, Stephen Smoogen wrote:
 > Maybe call it the Fedora Update Manager 'FUM' ?

Unless we're going to call it RUM when it makes its way into RHEL, that
name may not be the best choice :-)


Well Red Hat shipped the Yellowdog Update Manager for 2 releases so I am 
sure they can go with FUM or RUM (RPM Update Manager).. 


RPM Update Manager, an easily pronouncable and distro agnostic acronym 
which even makes sense. Now that would be a hard sell...


- Panu -
___
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: F38 proposal: RPM Sequoia (System-Wide Change proposal)

2022-10-13 Thread Panu Matilainen


On 10/13/22 07:18, Kevin Kofler via devel wrote:

For the last 20 years or so, RPM has used a home-grown OpenPGP parser
for dealing with keys and signatures. That parser is rather infamous
for its limitations and flaws, and especially in recent years has
proven a significant burden to RPM development. In order to improve
security and free developer resources for dealing with RPM's "core
business" instead, RPM upstream is in the process of deprecating the
internal parser in favor of [https://sequoia-pgp.org/ Sequoia PGP]
based solution written in Rust.


Why are you using a new library written in Rust? Can you not use one of the
existing mature C implementations of OpenPGP? gpgme maybe?


Had there been such an option, we would've switched over years ago. 
Gpgme is based around calling and communicating with an external gpg 
process, which is a setup you do NOT want in the rpm context where 
chroots come and go etc. Also, rpm requires access to the "low-level" 
digests-in-progress because it calculates multiple things on a single read.



At this point the change is mostly invisible in normal daily use.


Not really, because it makes some packages uninstallable.


Not uninstallable. You can use --nosignature, or resign such packages 
with something stronger. Which one is the better course depends on the 
situation of course.



- Some old, insecure (MD5/SHA1 based) signatures are rejected (this is
in line with the stronger crypto settings proposed elsewhere for F38)


Such a hardcoded restriction, without a way for the local administrator to
allow the legacy signatures, is not acceptable.


Mind you, I don't exactly agree with this style of explicit disabling 
either (see 
https://lists.rpm.org/pipermail/rpm-maint/2021-October/018344.html and 
onwards). But. I doubt many people realize just how thin the ice is (and 
has always been) with the existing parser. I consider this step a matter 
of survival, and ultimately some legacy content becoming harder to use 
is an acceptable tradeoff for *that*.


I don't know how deep this all is wired inside Sequoia, but I totally 
agree (as you see in the thread linked above) that this should be based 
on the system crypto policy. As explained in the change, nettle (which 
doesn't support the system crypto policies AIUI) should be seen as a 
temporary stepstone in Fedora, with a plan to switch to openssl (which 
does) in the nearish future.


So technically this is a matter of "Sequoia should honor system crypto 
policy", rpm is just a dumb API user here that sometimes get told "nope" 
by the underlying libraries, whether due to crypto policy, FIPS or whatever.


- Panu -
___
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 2134183] Can't install perl on i*86 due to missing dependencies

https://bugzilla.redhat.com/show_bug.cgi?id=2134183

Jitka Plesnikova  changed:

   What|Removed |Added

   Assignee|jples...@redhat.com |p...@city-fan.org
 Resolution|--- |RAWHIDE
  Component|perl|perl-Compress-Raw-Lzma
   Fixed In Version||perl-Compress-Raw-Lzma-2.20
   ||1-4.fc38
 Status|NEW |CLOSED
 CC||jn...@redhat.com,
   ||p...@city-fan.org
Last Closed||2022-10-13 06:49:32



--- Comment #1 from Jitka Plesnikova  ---
xz was updated to 5.2.7. perl-Compress-Raw-Lzma had to be rebuild against the
version.

$ rpm -qpR
https://kojipkgs.fedoraproject.org//packages/perl-Compress-Raw-Lzma/2.201/4.fc38/i686/perl-Compress-Raw-Lzma-2.201-4.fc38.i686.rpm
| grep xz-libs
xz-libs(x86-32) = 5.2.7


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2134183
___
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 2124459] Please branch and build perl-Net-OpenSSH in epel9

https://bugzilla.redhat.com/show_bug.cgi?id=2124459

Fedora Update System  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED



--- Comment #3 from Fedora Update System  ---
FEDORA-EPEL-2022-c7d9a171f8 has been submitted as an update to Fedora EPEL 9.
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-c7d9a171f8


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2124459
___
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 2130626] Please branch and build perl-Pegex in epel9