Personal introduction // Interested in adopting orphans

[Paul Pfeister via devel]

Hi all!

I've probably met a few of you on Matrix already. I've been lurking on irc,
but that side is fairly quiet nowadays. (irc is still my go to outside of
Fedora)

For those of you who I haven't spoken to yet...
I work primarily in the security and infrastructure space, with some
systems and software background sprinkled in as well. I've recently joined
Sherlock <https://github.com/sherlock-project/sherlock> (upstream) as a
maintainer, and have put in a good bit of work reworking things after a
nearly-stale year for the project.

After packaging Sherlock for PyPI and DockerHub, I eventually found my way
over to my personal distro of choice. Figured I may as well package for the
system I use most. Opened a couple Bugzilla requests for review (namely
sherlock-project <https://bugzilla.redhat.com/show_bug.cgi?id=2280116> and
python-exrex <https://bugzilla.redhat.com/show_bug.cgi?id=2280062>) and a
pagure request for sponsorship (python-exrex
<https://pagure.io/packager-sponsors/issue/658>) after getting quite a bit
of helpful feedback from current packagers.

Last Thursday, an inactive packagers list was sent out on devel with a list
of now-orphaned packages. Among these are python-git-changelog
<https://src.fedoraproject.org/rpms/python-git-changelog> and
python-pyzabbix <https://src.fedoraproject.org/rpms/python-pyzabbix>. Both
of these packages are currently still orphaned, and I have an interest in
adopting either or both packages.

python-git-changelog's only maintainer was (seemingly) pushed inactive.
python-pyzabbix's co-maintainer is an existing packager, but after speaking
with Orion, he is not interested in adopting as the main admin due to time
constraints, and he has opened the door for me to do so myself.

>From what you all have seen, is there anything that I may need to consider
for these packages before adoption, that I may not have already? Horror
stories or words of caution?
I'm unable to *officially* claim these packages as I'm not yet in the
packagers group, but I plan to do so as soon as I have some sort of
sponsorship (help there is appreciated, of course!).

Glad to meet y'all!

Paul Pfeister
FAS <https://accounts.fedoraproject.org/user/ppfeister/> // GitHub
<https://github.com/ppfeister/> (more active recently)
p...@pfeister.dev
--
___
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: rich deps result in packages being uninstalled from buildroot

[Paul Howarth]

On Fri, 17 May 2024 13:32:24 +
Zbigniew Jędrzejewski-Szmek  wrote:
> > Oh, this is embarrasing. I added two patches but they didn't get
> > applied because %setup not %autosetup. :(
> > I'll push a fixed build in a moment. Sorry for breaking the builds.
> >  
> 
> perl-Finance-Quote-1.6200-1.fc41:
> https://koji.fedoraproject.org/koji/taskinfo?taskID=117804013

Thanks.
--
___
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: rich deps result in packages being uninstalled from buildroot

[Paul Howarth]

On Thu, 16 May 2024 10:52:29 +
Zbigniew Jędrzejewski-Szmek  wrote:

> On Thu, May 16, 2024 at 11:09:01AM +0200, Fabio Valentini wrote:
> > This looks like you're putting the resolver between a rock and a
> > hard place. :thinking:
> > I don't think I've ever seen packages being *removed* when
> > installing BuildRequires on top of the minimal buildroot ...
> > 
> > Would it be possible to adapt the packages so that add-determinism
> > and add-determinism-nopython are parallel-installable, and have the
> > macro fall back to the add-determinism-nopython executable if the
> > add-determinism executable is not available?
> > That way BuildRequires are additive and wouldn't force package
> > removal from the buildroot, and the rich dependency could be
> > simpler - i.e. `Requires: (add-determinism if python3-libs)`,
> > without Suggests or else branch.  
> 
> Yeah, I think this is the most reasonable approach.
> I'll push a build that does this shortly.
> 
> (I tried to test this locally with mock, with the additional packages
> in a local repo. When I install everything in one go, things work as
> expected. Why I try to check the original issue, and install packages
> piecemeal, mock downgrades packages to fall back to the koji version
> without dependencies, instead of installing the additional deps. In
> koji, it'll only have one version of the package available, so
> hopefully it'll pick addition instead of removals.)

Not sure how this is supposed to work: add-determinism-nopython seems
to install %{_bindir}/add-determinism.nopython but the macro only seems 
to look for %{_bindir}/add-determinism, resulting in this when only
add-determinism-nopython is installed:

(https://koji.fedoraproject.org/koji/taskinfo?taskID=117791675)

+ /usr/bin/add-determinism --brp -j48 
/builddir/build/BUILDROOT/perl-Finance-Quote-1.6200-1.fc41.noarch
/var/tmp/rpm-tmp.hdLEuR: line 89: /usr/bin/add-determinism: No such file or 
directory
error: Bad exit status from /var/tmp/rpm-tmp.hdLEuR (%install)

The intent seems to be that the minimal version checks for existence of
the full version and re-execs it if found. So it seems to me that the
minimal version should be installed as %{_bindir}/add-determinism and
the full version should be called %{_bindir}/add-determinism.withpython
or something. Or maybe just tweak the rpm macro to define
%__brp_add_determinism as %{_bindir}/add-determinism.nopython.

Regards, Paul.
--
___
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

[rpms/perl-Compress-Raw-Lzma] PR #2: Rebuild against xz 5.6.1

[Paul Howarth]

pghmcfc merged a pull-request against the project: `perl-Compress-Raw-Lzma` 
that you are following.

Merged pull-request:

``
Rebuild against xz 5.6.1
``

https://src.fedoraproject.org/rpms/perl-Compress-Raw-Lzma/pull-request/2
--
___
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: google-re2 pacakge update and facebook vs google python bindings ?

[Paul Wouters]

On Mon, 4 Mar 2024, Fabio Valentini wrote:


Since this update was stuck and obviously broken, with no response
from Paul in over a week (either here or on the bodhi update), I've
used my provenpackager rights to revert the commits in dist-git and
unpush the stuck update (it failed gating tests, so it never made it
to rawhide repos). This should prevent the broken update from
accidentally getting pushed to Rawhide again, and it gives an
opportunity to re-do the conversion to rpmautospec correctly (i.e.
"rpmautospec convert" to preserve the old changelog) if that is
desirable.


Thanks and sorry for dropping the ball. Last week there were issues
getting the sidetag and this week it got lost in IETF deadline work.

I'll try to pick this up ASAP via the sidetag.

Paul
--
___
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: google-re2 pacakge update and facebook vs google python bindings ?

[Paul Wouters]

On Wed, 7 Feb 2024, Ben Beasley wrote:


Subject: Re: google-re2 pacakge update and facebook vs google python bindings


I haven't heard back from any of the maintainers.

I've created a PR to upgrade re2-2022-06-01 to re2-2024-02-01 as the
first step towards getting python-google-re2 working.

https://src.fedoraproject.org/rpms/re2/pull-request/6

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

google-re2 pacakge update and facebook vs google python bindings ?

[Paul Wouters]

Hi,

At $dayjob we are running into issues with re2 and python bindings.

Fedora has a fairly old version of re2 with so.9 while upstream is at
so.11. Is there a reason for this? If it is just time, I'd like to
help bumping the package in rawhide.

Originally, facebook creating python bindings for this, which are
packaged in python-fb-re2, but this package is no longer updated
as google're2 now has native python bindings (I think the fb one
was pulled in and maintained and so the fb one is abandoned upsteam)

I'd like to see:

- google-re2 updated to version 2024-02-04
- python3-google-re2 python bindings shipped, providing the fb-re2 package.
- python2-fb-re2 retired

Currently, the google-re2 python bindings do not compile against
the older google-re2 we ship (but that might be a fairly trivial
fix, that would need to be done for the branches anyway)


Added package maintainers to the CC: for additional input.


Again, happy to help if time/effort is the only thing holding
this back. If there are other reasons for this, I'd very much
like to know more. I know there were soname issues in the past.

Packages that would be affected by the soname bump:

loaty
dnsdist
frr
grpc
libarrow
mtxclient
onnxruntime
perl-re-engine-RE2
python3-fb-re2
python3-grpcio
python3-onnxruntime
qt5-qtwebengine
syslog-ng
syslog-ng-opentelemetry

Thanks,

Paul
--
___
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: Figure out what killed an app (rhbz#2253099)

[Paul Grosu]

I think your options are two:

1) Write a plugin for the oom service to capture the state (and log it)
before it kills the process.  Here's the source code to learn more about
that:

https://github.com/facebookincubator/oomd/

2) Or you can completely disable it:

https://www.cjjackson.dev/posts/what-is-systemd-oomd-how-to-disable-it/

The man pages which other folks referred to is here (in case you want to
tweak with configuring it):

https://man7.org/linux/man-pages/man8/systemd-oomd.service.8.html

Hope it helps,
~p

On Wed, Jan 31, 2024 at 1:04 PM Michael Catanzaro 
wrote:

> On Wed, Jan 31 2024 at 06:53:25 PM +01:00:00, Milan Crha
>  wrote:
> > Evo itself doesn't use any seccomp or such, these things can be used
> > by
> > the WebKitGTK. A quick grep revealed:
> >
> >
> https://github.com/WebKit/WebKit/blob/main/Source/WebKit/UIProcess/Launcher/glib/ProcessLauncherGLib.cpp#L258
> >
> > but that code does not seem to be called at this time (or my debug
> > code
> > was wrong, it's possible).
>
> That code is for terminating child processes. It's certainly not
> supposed to terminate itself.
>
> --
> ___
> 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: Troubleshooting MD RAID assembly not working after upgrade to F39

[Paul Howarth]

On Wed, 27 Dec 2023 15:05:29 +0100
Sandro  wrote:

> I could you use some help with ${SUBJECT}. I posted the details in 
> discussion [1], but have yet to receive a response. I thought maybe 
> folks on the list may have an idea.
> 
> I'm kinda lost as to where this is going wrong. Feel free to reply 
> either on discussion or here. I'd appreciate any help I can get.

This may be completely unrelated but I had a similar experience when
installing F39 on one of my machines with OS on SSD and data on
spinning rust with MDRAID volumes.

I'm in the habit of just specifying my two SSDs as devices to use in
the installer and then configuring everything else (mostly using
ansible) post-install. When I booted the new F39 (server) installation
and tried to set up the LVM arrays, most of them couldn't be found.
This turned out to be because the file /etc/lvm/devices/system.devices
was present, and contained only the devices I had specified in the
installer. This seemed to be new behaviour in Fedora 39.

This fix for this was to do this:
# vgimportdevices -a
# vgchange -ay

I was then able to access my MDRAID volumes.

Hopefully this can help somebody.

Regards, Paul.
--
___
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: DNF5: Checking signatures of packages installed out of a repository?

[Paul Howarth]

On Tue, 31 Oct 2023 12:48:31 -0400
Christopher  wrote:
> I'm actually a bit concerned about this thread, because I assumed DNF4
> and DNF5 would check signatures by default today, and that it would
> only skip if `--nogpgcheck` was passed as an option. If it sometimes
> skips the GPG check without that flag, that seems like a serious
> security bug to me. I would expect the same level of signature
> verification for both `dnf install mypackage` and `wget mypackage.rpm
> && dnf localinstall mypackage.rpm`.
> 
> After all, there is no documented flag to force a GPG signature check,
> only the flag to omit the check (`--nogpgcheck`). So, users really
> have to rely on the default behavior of always checking GPG signatures
> if they want DNF to check them. If DNF is not doing that, that's
> really bad, because there's no way for users to force it to check
> them.

Maybe not using dnf, but you can check it using rpm directly:

$ wget mypackage.rpm
$ rpm --checksig mypackage.rpm

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

Orphaned perl-Fennec

[Paul Howarth]

I've just orphaned perl-Fennec, which has been deprecated upstream
since 2018 (in favor of perl-Test2-Suite).

According to fedrq, nothing in Fedora depends on it:
$ fedrq whatrequires-src -X -F source perl-Fennec
(nothing)

This was actually triggered by a test suite failure for the package in
koji that started a couple of weeks ago but I cannot reproduce locally
in mock. Given its state both upstream and in Fedora, I don't think
it's worth expending debugging cycles on this.

Regards, Paul.
___
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

[rpms/perl-List-MoreUtils-XS] PR #1: Disable extra test in RHEL builds

[Paul Howarth]

pghmcfc closed without merging a pull-request against the project: 
`perl-List-MoreUtils-XS` that you
are following.

Closed pull-request:

``
Disable extra test in RHEL builds
``

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

[rpms/perl-Module-Signature] PR #1: Remove obsolete dependency to perl-Digest-SHA1

[Paul Howarth]

pghmcfc merged a pull-request against the project: `perl-Module-Signature` that 
you are following.

Merged pull-request:

``
Remove obsolete dependency to perl-Digest-SHA1
``

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

[rpms/perl-Crypt-IDEA] PR #1: Update license field to new BSD-Systemics SPDX license id

[Paul Howarth]

pghmcfc merged a pull-request against the project: `perl-Crypt-IDEA` that you 
are following.

Merged pull-request:

``
Update license field to new BSD-Systemics SPDX license id
``

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

[rpms/perl-Crypt-DES] PR #2: Update license field to new BSD-Systemics SPDX license i

[Paul Howarth]

pghmcfc merged a pull-request against the project: `perl-Crypt-DES` that you 
are following.

Merged pull-request:

``
Update license field to new BSD-Systemics SPDX license i
``

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

[rpms/perl-CPAN-Meta-Check] PR #1: Update test requirements

[Paul Howarth]

pghmcfc commented on the pull-request: `Update test requirements` that you are 
following:
``
Do you need a new build for this in Rawhide, or is fixing it in git sufficient?
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-CPAN-Meta-Check/pull-request/1
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[rpms/perl-CPAN-Meta-Check] PR #1: Update test requirements

[Paul Howarth]

pghmcfc merged a pull-request against the project: `perl-CPAN-Meta-Check` that 
you are following.

Merged pull-request:

``
Update test requirements
``

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

proposal to orphan tcpcrypt

[Paul Wouters]

Hi,

After talking to the debian maintainer of tcpcrypt, we both decided the
best thing is to remove tcpcrypt from the distributions.

- The protocol at the IETF seems have stalled for many years
- The main proponent and implementer sadly passed away years ago
- The website tcpcrypt.org has died a while ago
- The package interferes badly with firewalling tools

If anyone is really objecting, please let me know and be prepared to
become the maintainer in that case.

Paul
___
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: Several questionable packages installed on fresh system

[Paul Howarth]

On Thu, 13 Jul 2023 14:10:37 +0200
Vít Ondruch  wrote:

> Dne 10. 07. 23 v 10:38 Vít Ondruch napsal(a):
> > Hi,
> >
> >
> > libtomcrypt
> >  
> 
> So this is the dependency chain:
> 
> libtomcrypt <= python3-crypto <= python3-beaker <= python3-mako

I raised https://bugzilla.redhat.com/show_bug.cgi?id=2224405 to get the
Recommends: for python3-crypto dropped from python-beaker.

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

Re: fedora-review workarounds for dnf5

[Paul Howarth]

On Tue, 18 Jul 2023 15:27:01 +0200
Fabio Valentini  wrote:

> On Tue, Jul 18, 2023, 15:22 Maxwell G  wrote:
> 
> > On Tue Jul 18, 2023 at 12:38 +0200, Jakub Kadlcik wrote:  
> > > Hello Jerry,
> > > I proposed a workaround a few days ago
> > > https://pagure.io/FedoraReview/pull-request/485
> > >
> > > but your patch looks like a proper fix. I'll try it and merge to
> > > the fedora-review codebase.
> > >
> > > Does anybody know what was the purpose of --resolve and if it
> > > will be no problem when we remove it?  
> >
> > --requires --resolve resolves the entire dependency tree of a
> > package. --requires just prints the direct dependencies that are
> > specified in the RPM metadata.
> > I don't know what this code is used for,
> > but I don't think simply removing --resolve is the right solution.
> >  
> 
> Is it though? I assume you're thinking of "--recursive". As far as I
> know, "--requires --resolve" force resolution of virtual provides
> instead. I don't think removing "--resolve" is the correct solution
> for this case.
> 
> For example, the check if a package depends on something that's
> deprecated (i.e. "Provides: deprecated ()") would need to resolve and
> check the actual package dependencies, not only virtual provides.

I have a script that uses --requires, --resolve and --recursive all at
the same time:

...
dnf repoquery \
--quiet \
--releasever=$RELEASE_VER \
$EXTRA_REPO_SPEC \
--disablerepo=\* \
--enablerepo=$LOCAL_SOURCE_REPO \
--enablerepo=$LOCAL_BINARY_REPO \
--enablerepo=$BASE_BINARY_REPO \
--arch=${BINARY_ARCHLIST},noarch,src \
--forcearch=$FORCE_ARCH \
--qf '  %{name}' \
--requires --resolve --recursive $BUILD_GROUP 
$LOCAL_PACKAGE_LIST
...
I use it to work out all of the dependencies (build and run time) for
all of the packages in a local repo so that I can mirror them locally.

Regards, Paul.
___
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: rawhide build errors on i686

[Paul Howarth]

On Sun, 2 Jul 2023 18:02:20 +0200
Matthias Runge  wrote:

> On 02/07/2023 17:51, Matthias Runge wrote:
> > Hi there
> > 
> > in one of my recent builds, I came across this error on i686 [1].
> > 
> > Transaction test succeeded.
> > Running transaction
> > warning: /etc/hosts created as /etc/hosts.rpmnew
> > 
> > Error unpacking rpm package shadow-utils-2:4.13-7.fc39.i686
> > error: unpacking of archive failed on file
> > /usr/bin/newgidmap;64a19767: cpio: cap_set_file failed - Value too
> > large for defined data type error: shadow-utils-2:4.13-7.fc39.i686:
> > install failed
> > 
> > 
> > I do believe this failure has nothing to do with my package build
> > (some golang package). Who could debug this further, or is the
> > issue already known?  
> 
> The issue seems to be transient, [2] just passed, I found a related 
> thread on the infrastructure list[3].
> 
> 
> Matthias
> 
> > 
> > Matthias
> > 
> > [1] 
> > https://kojipkgs.fedoraproject.org//work/tasks/7079/102847079/mock_output.log
> >  
> [2] https://koji.fedoraproject.org/koji/taskinfo?taskID=102847771
> [3] 
> https://lists.fedoraproject.org/archives/list/infrastruct...@lists.fedoraproject.org/thread/HX7RPWZGULSWEHVQ4GBCZQNIZUCNLA7A/

Whatever this is, it's intermittent and it's still happening. I'm
getting koschei reports about failed builds with this symptom every
day, and yesterday I had a "real" build fail in that way too:

https://koji.fedoraproject.org/koji/taskinfo?taskID=102913997

I resubmitted the build and it worked:

https://koji.fedoraproject.org/koji/taskinfo?taskID=102915640

Regards, Paul.
___
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

[rpms/perl-HTML-Scrubber] PR #1: Update Source0 URL due to upstream maintainer change

[Paul Howarth]

pghmcfc commented on the pull-request: `Update Source0 URL due to upstream 
maintainer change` that you are following:
``
I tend to use the author-independent version for the modules I package myself, 
which helps in the case where a module is maintained by multiple people and the 
maintainer that does the releases switches back and forth.

Let's see what spot thinks anyway.
``

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

[rpms/perl-HTML-Scrubber] PR #1: Update Source0 URL due to upstream maintainer change

[Paul Howarth]

pghmcfc commented on the pull-request: `Update Source0 URL due to upstream 
maintainer change` that you are following:
``
A better URL would prpbably be 
https://cpan.metacpan.org/modules/by-module/HTML/HTML-Scrubber-%{version}.tar.gz
 since that does not change when there's a change of maintainer.
``

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

[rpms/perl-List-MoreUtils-XS] PR #1: Disable extra test in RHEL builds

[Paul Howarth]

pghmcfc commented on the pull-request: `Disable extra test in RHEL builds` that 
you are following:
``
I didn't merge the PR but did something similar based on the usual pattern for 
such things in our perl modules.
``

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

Re: Trying to strip a library automatically

[Paul Grosu]

Hi Orion,

Glad objdump helped -- the second approach I meant to write objcopy, which
actually strips the symbols.

Regarding how the symbols might show up in the library automatically,
here's how it might happen.  When I took a look at one of the build.log
files from koji at the following link:

https://kojipkgs.fedoraproject.org//packages/Lmod/8.7.25/2.fc38/data/logs/x86_64/build.log

I see your CFLAGS variable contains the -g flag, which forces debug symbols
to be included.  For example, for the tcl2lua it has it as part of the
build (which contains the -g flag):

make[1]: Entering directory '/builddir/build/BUILD/Lmod-8.7.25/pkgs/tcl2lua'
gcc -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches
-pipe -Wall -Werror=format-security
-Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64  -mtune=generic
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection
-fno-omit-frame-pointer -mno-omit-leaf-frame-pointer  -DLUA_COMPAT_MODULE
-fPIC -I/usr/include -I/usr/include/   -c -o tcl2lua.o tcl2lua.c

The way this seems to happen could be as follows:

1) I took a look at the source code from here:

https://kojipkgs.fedoraproject.org//packages/Lmod/8.7.25/2.fc38/src/Lmod-8.7.25-2.fc38.src.rpm

When I looked at the Makefile for tcl2lua under Lmod-8.7.25/pkgs/tcl2lua,
it inherits it from a previous file:

override CFLAGS   := $(CFLAGS) -DLUA_COMPAT_MODULE -fPIC $(LUA_INC)
$(TCL_INCLUDE)

2) When I traverse the inheritance, it seems to come from the configure
script Lmod-8.7.25/configure:

I see a bunch of CFLAGS="-g there.

If I then look at the build.log it seems to be run at the beginning of the
build:

+ ./configure --build=x86_64-redhat-linux-gnu
--host=x86_64-redhat-linux-gnu --program-prefix=
--disable-dependency-tracking --prefix=/usr --exec-prefix=/usr
--bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc
--datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64
--libexecdir=/usr/libexec --localstatedir=/var --runstatedir=/run
--sharedstatedir=/var/lib --mandir=/usr/share/man --infodir=/usr/share/info
--prefix=/usr/share PS=/usr/bin/ps
configure: WARNING: unrecognized options: --disable-dependency-tracking

I then looked at the Lmod.spec file, and I see this, which confirms it:

%build
%if 0%{?rhel} && 0%{?rhel} <= 6
%configure --prefix=%{_datadir} PS=/bin/ps
%else
%configure --prefix=%{_datadir} PS=/usr/bin/ps
%endif
%make_build

So debug symbols seem to get triggered through the configure script.

Hope it helps,
Paul

On Fri, Jun 2, 2023 at 7:42 PM Orion Poplawski  wrote:

> On 6/1/23 23:00, Paul Grosu wrote:
> > Hi Orion,
> >
> > There are two ways to remove the debugging symbols:
> >
> > 1) strip --strip-debug your_library.so
> >
> > 2) objcopy --strip-debug your_library.so
> >
> > Below is an example of both approaches:
> >
> > 1) Method using strip:
> >
> > paul$ objdump --syms libfoo.so | grep debug
> >  ld  .debug_aranges 
> >   .debug_aranges
> >  ld  .debug_info
> >   .debug_info
> >  ld  .debug_abbrev  
> >   .debug_abbrev
> >  ld  .debug_line
> >   .debug_line
> > 0000 l    d  .debug_str 
> >   .debug_str
> > paul$ strip --strip-debug libfoo.so
> > paul$ objdump --syms libfoo.so | grep debug
> > paul$
> >
> > 2) Method using objdump:
> >
> > paul$ objdump --syms libfoo.so | grep debug
> >  ld  .debug_aranges 
> >   .debug_aranges
> >  ld  .debug_info
> >   .debug_info
> > 0000 ld  .debug_abbrev  0000
> >   .debug_abbrev
> > 0000 ld  .debug_line
> >   .debug_line
> > 0000 ld  .debug_str 
> >   .debug_str
> > paul$ objcopy --strip-debug libfoo.so
> > paul$ objdump --syms libfoo.so | grep debug
> > paul$
> >
> > Are there other symbols you are looking to strip?
> >
> > Hope it helps,
> > Paul
>
> So I'm afraid my subject isn't the best - I'm really wondering why the
> library isn't being stripped automatically and debug info collected by
> RPM as I would expect.
>
> But your answer pointed me towards using objdump --syms to verify that
> the debug info has been removed, not the output of "file".  Thanks!
>
> >
> > On Fri, Jun 2, 2023 at 12:11 AM Orion Poplawski  > <mailto:or...@nwra.com>> wrote:
> >
&

Re: Trying to strip a library

[Paul Grosu]

Hi Orion,

There are two ways to remove the debugging symbols:

1) strip --strip-debug your_library.so

2) objcopy --strip-debug your_library.so

Below is an example of both approaches:

1) Method using strip:

paul$ objdump --syms libfoo.so | grep debug
 ld  .debug_aranges 
 .debug_aranges
 ld  .debug_info
 .debug_info
 ld  .debug_abbrev  
 .debug_abbrev
 ld  .debug_line
 .debug_line
 ld  .debug_str 
 .debug_str
paul$ strip --strip-debug libfoo.so
paul$ objdump --syms libfoo.so | grep debug
paul$

2) Method using objdump:

paul$ objdump --syms libfoo.so | grep debug
 ld  .debug_aranges 
 .debug_aranges
 ld  .debug_info
 .debug_info
 ld  .debug_abbrev  
 .debug_abbrev
 ld  .debug_line
 .debug_line
 ld  .debug_str 
 .debug_str
paul$ objcopy --strip-debug libfoo.so
paul$ objdump --syms libfoo.so | grep debug
paul$

Are there other symbols you are looking to strip?

Hope it helps,
Paul

On Fri, Jun 2, 2023 at 12:11 AM Orion Poplawski  wrote:

> I'm trying to resolve this packaging issue with Lmod:
>
> https://artifacts.dev.testing-farm.io/4d7bee41-8d21-42fb-8c57-e5ffbf58119f/
>
> debuginfo
> BAD /usr/share/lmod/8.7.25/lib/tcl2lua.so in Lmod-8.7.25-2.fc38 on i686
> contains debugging symbols
>
> I've dealt with a couple of issues here:
>
> https://src.fedoraproject.org/rpms/Lmod/pull-request/2
>
> but despite all of my attempts the library does not appear to get stripped.
>
> In fact:
>
> ]$ strip -g
>
> /home/orion/BUILDROOT/Lmod-8.7.25-3.fc39.x86_64/usr/lib64/lmod/tcl2lua.so.1.0.1
>
> $ file
>
> /home/orion/BUILDROOT/Lmod-8.7.25-3.fc39.x86_64/usr/lib64/lmod/tcl2lua.so.1.0.1
> /home/orion/BUILDROOT/Lmod-8.7.25-3.fc39.x86_64/usr/lib64/lmod/tcl2lua.so.1.0.1:
>
> ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically
> linked, BuildID[sha1]=aa1ea44979190d0cf530d350f8151ffafeab0f36, not
> stripped
>
> ?
>
>
> --
> Orion Poplawski
> he/him/his  - surely the least important thing about me
> IT Systems Manager 720-772-5637
> NWRA, Boulder/CoRA Office FAX: 303-415-9702
> 3380 Mitchell Lane   or...@nwra.com
> Boulder, CO 80301 https://www.nwra.com/
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[rpms/perl-Crypt-CBC] PR #1: Update license to SPDX format

[Paul Howarth]

pghmcfc merged a pull-request against the project: `perl-Crypt-CBC` that you 
are following.

Merged pull-request:

``
Update license to SPDX format
``

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

[rpms/perl-Crypt-DES] PR #1: Fix C99 compatibility issue

[Paul Howarth]

pghmcfc merged a pull-request against the project: `perl-Crypt-DES` that you 
are following.

Merged pull-request:

``
Fix C99 compatibility issue
``

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

[rpms/perl-Devel-LexAlias] PR #1: Update license to SPDX format

[Paul Howarth]

pghmcfc merged a pull-request against the project: `perl-Devel-LexAlias` that 
you are following.

Merged pull-request:

``
Update license to SPDX format
``

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

[rpms/perl-Convert-BinHex] PR #1: Update license to SPDX format

[Paul Howarth]

pghmcfc commented on the pull-request: `Update license to SPDX format` that you 
are following:
``
@mspacek, I just kicked off a build. I'm happy to add you to the package if you 
want.
``

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

[rpms/perl-Convert-BinHex] PR #1: Update license to SPDX format

[Paul Howarth]

pghmcfc merged a pull-request against the project: `perl-Convert-BinHex` that 
you are following.

Merged pull-request:

``
Update license to SPDX format
``

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

[rpms/perl-B-Hooks-EndOfScope] PR #1: Update license to SPDX format

[Paul Howarth]

pghmcfc merged a pull-request against the project: `perl-B-Hooks-EndOfScope` 
that you are following.

Merged pull-request:

``
Update license to SPDX format
``

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

[rpms/perl-Data-Dump] PR #1: Update license to SPDX format

[Paul Howarth]

pghmcfc merged a pull-request against the project: `perl-Data-Dump` that you 
are following.

Merged pull-request:

``
Update license to SPDX format
``

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

Re: Bodhi_enabled ? Re: F38 Change complete (100% complete) deadline today

[Paul Howarth]

On Sat, 25 Feb 2023 10:41:37 -0800
Kevin Fenzi  wrote:

> On Fri, Feb 24, 2023 at 06:00:08AM +, Sérgio Basto wrote:
> > On Tue, 2023-02-21 at 16:40 -0500, Ben Cotton wrote:  
> > > As of today, F38 Changes should be 100% complete. Change owners
> > > can indicate this by setting the Bugzilla tracker to the ON_QA
> > > state. F38 enters beta freeze today. Any updates that need to
> > > land in the beta release will require an approved freeze
> > > exception or beta blocker.
> > > 
> > > The current beta target is the early target date of 14 March.
> > > 
> > > More schedule details are available at
> > > https://fedorapeople.org/groups/schedule/f-38/f-38-key-tasks.html
> > >  
> > 
> > 
> > ok, we also have "Bodhi updates-testing activation point" 
> > 
> > I just notice many fc38 packages in bodhi -> "create new update"
> > that weren't sent to updates-testing.   
> 
> yeah, any updates after that need to be submitted by the
> maintainer(s). 
> 
> Perhaps we could make it more clear that auto-created updates are
> turned off at that point as well?

There was a point at which the update was automatically created but not
automatically submitted to testing.

I think this is an example:

https://bodhi.fedoraproject.org/updates/FEDORA-2023-1653514c86

The update was created automatically but I noticed it hadn't been
submitted for testing the following day and had to do it myself.

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

Re: Inactive packager check for F38

[Paul Wouters]

On Wed, 15 Feb 2023, Ben Cotton wrote:


For the curious, here are the stats from today's run:

### Found 2129 users in the packager group. ###
### Found 914 users with no activity in pagure/src.fp.org over the
last year. ###
### Found 845 users which also show no activity in Bodhi over the last year. ###


How many packages depend _only_ on people from this list? Eg are likely
to be unmaintained ?

Paul
___
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: OpenSSL update

[Paul Wouters]

On Thu, 9 Feb 2023, Dmitry Belyavskiy wrote:


I've just pushed updates of OpenSSL to the 3.0.8 version to f36/37.
I will also push to f38 and rawhide later today.


Why is f36/f37 the playground for f38/rawhide? Shouldn't this be done
in the reverse order?


In fact all the updates landed simultaneously.


Ahh okay, no worries then :)

Thanks for the updates!

Paul
___
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: OpenSSL update

[Paul Wouters]

On Thu, 9 Feb 2023, Dmitry Belyavskiy wrote:


I've just pushed updates of OpenSSL to the 3.0.8 version to f36/37.
I will also push to f38 and rawhide later today.


Why is f36/f37 the playground for f38/rawhide? Shouldn't this be done
in the reverse order?


This is a security release, it fixes 8 MODERATE CVEs
(https://www.openssl.org/news/secadv/20230207.txt)

I kindly ask you to test the version so it could be rolled up earlier.


I really would hope that testing happens in rawhide before it is pushed
into f36/f37 :(

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

Issue with hardened build

[Paul Howarth]

Hi all,

I recently received a bug report
(https://bugzilla.redhat.com/show_bug.cgi?id=2166454) about
proftpd not being able to load a dynamic module (mod_rewrite) that
provides some optional functionality. This module is not used by
default and has to be enabled manually. The ticket was raised for
EPEL-9 but I can reproduce the issue on my Fedora 37 machine.

I raised the issue upstream
(https://github.com/proftpd/proftpd/issues/1590) and after some
experimentation, it appears that turning off hardened build (by
undefining _hardened_build) results in a build that can load the module.
I can also add -fstack-protector-strong back into optflags without it
breaking. Various other of proftpd's optional modules work OK
regardless of the hardened build state.

The hardened build has been enabled in proftpd for a long time so I
don't know if it's recently stopped working or nobody ever used
mod_rewrite with the packaged builds.

Any ideas why this should be happening? I'd really rather not disable
the hardened build for a complex internet-facing server like proftpd.

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

[EPEL-devel] Re: [SPF:fail] A coordinated plan for ansible-collection updates in EPEL?

[Paul Howarth]

On Mon, 30 Jan 2023 21:13:11 -0700
Orion Poplawski  wrote:

> So, I'm wondering if we should have some kind of (at least 
> semi-)coordinated plan for updating ansible collections in EPEL?
> 
> My initial thought is we would sort of piggy back on to what the 
> "ansible" community collection bundles on top of the ansible-core 
> package provided by RedHat.  So, currently in EL8.7 we have:
> 
> ansible-core-2.13.3
> 
> and EPEL ships:
> 
> ansible-6.3.0 - which corresponds to the ansible community package
> that ships with ansible-2.13.3.
> 
> Then we would endeavor to ship the individual package collection 
> versions that are contained in that package, .e.g: (taken from the 
> MANIFEST.json files):
> 
> ansible.posix 1.4.0
> ansible.utils 2.6.1
> chocolatey.chocolatey 1.3.0
> community.docker 2.7.1
> community.general 5.5.0
> community.libvirt 1.2.0
> community.mysql 3.4.0
> community.rabbitmq 1.2.2
> containers.podman 1.9.4
> netbox.netbox 3.7.1

Sounds like a reasonable plan to me.

> For reference, currently in epel we have:
...
> ansible-collection-community-libvirt.noarch 1.1.0-3.el8
> epel 

I updated ansible-collection-community-libvirt to 1.2.0:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-98b1fc46a5

> I don't really have a particular agenda here, just trying to solicit 
> people's thoughts.  Personally I like minimal installs so I have been 
> only using ansible-core + collections on the systems I maintain and 
> would like to continue to see them be usable together.

I too just use ansible-core + collections on the systems I maintain.

Regards, Paul.
___
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: Can we retire glib, gtk+, bubblemon, manedit and xconvers ?

[Paul Howarth]

On Wed, 21 Dec 2022 14:47:38 +
Sérgio Basto  wrote:

> Hi,
> 
> Dependencies on glib1 and gtk1 are only bubblemon manedit xconvers  ,
> I propose retire it on F38, it's one less burden  that we have . 

As I've always said when this has come up before, I'll be happy to
retire glib1 and gtk+1 when they no longer have dependent packages in
Fedora. Have you tried raising bugs on these dependents to see if their
maintainers are willing to retire them?

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

Re: Inactive packagers to be removed after the F37 release

[Paul Howarth]

On Tue, 29 Nov 2022 10:27:56 +
Paul Howarth  wrote:

> On Mon, 28 Nov 2022 18:20:20 +
> Mattia Verga via devel  wrote:
> 
> > Il 28/11/22 18:36, Nick Bebout ha scritto:
> >   
> > > I've removed a lot of ACLs. See attached log file.
> > 
> > Thanks Nick.
> > 
> > From your output I made a list of the orphaned packages which I
> > think it's a bit more readable:
> >   
> ...
> > - rpms/perl-App-PFT
> > - rpms/perl-Clipboard
> > - rpms/perl-Crypt-Rijndael  
> 
> I took perl-Crypt-Rijndael

And then I noticed that existing co-maintainer xavierb had been
defacto-maintaining it since 2020 so I gave it to him.

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

Re: Inactive packagers to be removed after the F37 release

[Paul Howarth]

On Mon, 28 Nov 2022 18:20:20 +
Mattia Verga via devel  wrote:

> Il 28/11/22 18:36, Nick Bebout ha scritto:
> 
> > I've removed a lot of ACLs. See attached log file.  
> 
> Thanks Nick.
> 
> From your output I made a list of the orphaned packages which I think
> it's a bit more readable:
> 
...
> - rpms/perl-App-PFT
> - rpms/perl-Clipboard
> - rpms/perl-Crypt-Rijndael

I took perl-Crypt-Rijndael

Regards, Paul.
___
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: miniz-3.0.0 brings a SONAME bump

[Paul Howarth]

On Tue, 1 Nov 2022 11:40:45 +0100
Petr Pisar  wrote:

> Hello,
> 
> just a notification that miniz-3.0.0 will bump libminiz.so.0.2 SONAME
> in Fedora 38. As far as I know there is no other package depending on
> it.

It's used at least by perl-Sereal-{De,En}coder:

$ rpm -qp --requires perl-Sereal-Decoder-5.001-1.fc38.x86_64.rpm
libc.so.6()(64bit)
libc.so.6(GLIBC_2.2.5)(64bit)
libc.so.6(GLIBC_2.3.4)(64bit)
libc.so.6(GLIBC_2.4)(64bit)
libcsnappy.so()(64bit)
libminiz.so.0.2()(64bit)
libperl.so.5.36()(64bit)
libzstd.so.1()(64bit)
perl(:MODULE_COMPAT_5.36.0)
perl(:VERSION) >= 5.8.0
perl(Carp)
perl(Exporter)
perl(XSLoader)
perl(constant)
perl(strict)
perl(warnings)
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(PayloadIsZstd) <= 5.4.18-1
rtld(GNU_HASH)
$ rpm -qp --requires perl-Sereal-Encoder-5.001-1.fc38.x86_64.rpm
libc.so.6()(64bit)
libc.so.6(GLIBC_2.14)(64bit)
libc.so.6(GLIBC_2.2.5)(64bit)
libc.so.6(GLIBC_2.3.4)(64bit)
libc.so.6(GLIBC_2.4)(64bit)
libcsnappy.so()(64bit)
libminiz.so.0.2()(64bit)
libperl.so.5.36()(64bit)
libzstd.so.1()(64bit)
perl(:MODULE_COMPAT_5.36.0)
perl(:VERSION) >= 5.8.0
perl(Carp)
perl(Exporter)
perl(XSLoader)
perl(constant)
perl(strict)
perl(warnings)
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(PayloadIsZstd) <= 5.4.18-1
rtld(GNU_HASH)

Paul.
___
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: DNF5 Blockers

[Paul Frields]

On Tue, Oct 11, 2022 at 7:13 AM Zbigniew Jędrzejewski-Szmek <
zbys...@in.waw.pl> wrote:

> On Tue, Oct 11, 2022 at 11:48:14AM +0200, Fabio Valentini wrote:
> > On Mon, Oct 10, 2022 at 9:15 AM Jaroslav Mracek 
> wrote:
> > >
> > > Please can you be more specific which kind of functionality is
> required for particular command? Why is it important to know what user case
> you want to resolve it? Commands has multiple options and some of them
> could be unused. Specially repoquery has tons of options. Knowing critical
> usercase will help us a lot to not only provide the same option but to
> improve DNF5 behavior in comparison to DNF4.
> > >
> > > I recommend to create for each user case or command an issue -
> https://github.com/rpm-software-management/dnf5/issues. Please provide as
> much as possible information to understand the user case to be able to set
> a proper priority.
> >
> > Determining the scope of such big Changes is usually done by the
> > person who proposes the change ...
> > I think it's safe to assume that most commands / options are used by
> > at least some people / tools / scripts, so dropping features is going
> > to be painful, and should be avoided, if possible.
>
> Yes. And looking at this from the other angle: if you ask people what
> features they need, the answer will be "yes" ;) Essentially, pretty
> much every feature ever created has *some* user, and often people will
> only remember about a feature when it turns out that it is missing in
> the new implementation. Also, other things being equal, people prefer
> that the interface is unchanged. This just makes life easier for them.
>

I agree with you Zbyszek. OTOH "identical interface" doesn't seem like a
fair requirement. (I don't believe you were suggesting it was.)

Thus, if we're switching to an entirely new system where
> reimplementing every feature and interface of the old system is not
> possible, people proposing the change need to figure out what *can* be
> implemented, and weigh the efforts required against how needed the
> feature really is,


This sounds reasonable -- describe what will be provided at a minimum.


> propose alternatives for things which are too hard
> or too costly to reimplement,


This sounds reasonable if all we're asking is to provide suggestions or
alternatives for a few things that are more prominent changes. Not
alternatives for every possible function. That would divert too much energy
from more useful work.


> and in the end make some judgement calls.
>

Are you suggesting the DNF team can make these calls? That sounds like a
collegial level of trust and seems okay, if so. But it seems at odds with
the original request, so it should be clear who's accountable for making
what calls.

-- 
Paul
___
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: When is a file dependency appropriate?

[Paul Howarth]

On Thu, 6 Oct 2022 14:38:38 +0200
> This is good point. I have already forget the details. So if there
> was embedded just the right amount of information in the main data,
> we would not need the full list (and lazy loading). Currently, the
> data contains e.g. /usr/bin/*, which is useful for installing
> `/usr/bin/foo`. But we know that in the repository, there is RPM with
> `Requires: /some/strange/path`. Therefore during creating the
> repository metadata, we could look for RPM providing this path and
> include it into the main metadata. This would blow the metadata a
> bit, but it would allow to not care about the full file list at all.
> Of course that would mean `dnf install /some/random/path` won't work
> universally, but 1) I don't think this is widely used for random
> stuff 2) it is easy to detect and download the full file list instead
> if needed.
> 
> Should I open request against createrepo_c?

Fixing it in the repo metadata would only work if the dependency and
its provider are in the same repository. So for instance if there was a
dependency on /some/random/path in the main Fedora repo and the package
containing that file was updated, the createrepo run for the updates
repository wouldn't know about the dependency and wouldn't add the
provide. That's before even considering third-party repos.

Paul.
___
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

Orphaning packages

[Paul Frields]

Hi, I've orphaned the following packages for lack of time:

nautilus-search-tool
pinpoint

They are available for someone to pick up if desired.

I'm asking co-maintainers about some other packages I own, and if I get no
response, there may be some more to follow (a few minor drupal7 and PHP
modules, odfpy, and pioneers). Let me know if any appeal to you:
https://src.fedoraproject.org/user/pfrields/projects

-- 
Paul
___
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: Donate 1 minute of your time to test upgrades from F36 to F37

[Paul Wouters]

On Mon, 12 Sep 2022, Miroslav Suchý wrote:


Do you want to make Fedora 37 better? Please spend 1 minute of your time and 
try to run:



In case you hit dependency issues, please report it against the appropriate 
package.


Seemed fine. I saw two issues related to python azure packages but since
I maintain some that might be self inflected. will double check though
on a stock install.

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

Re: rpm with sequoia pgp

[Paul Wouters]

On Fri, 2 Sep 2022, Neal H. Walfield wrote:


Note: Sequoia currently uses Nettle on Fedora, but there is ongoing
work to port it to Sequoia to OpenSSL:


I think this should be considered a blocker for changing gpg backends.


 
https://github.com/rpm-software-management/rpm/issues/2041#issuecomment-1219175000

Note2: There are lots of reasons to use Sequoia, but one user-visible
reason is improved usability.  When a user imports a certificate,
Sequoia lints it and displays potential issues, or reasons why it
can't be imported:

 
https://github.com/rpm-software-management/rpm/issues/1974#issuecomment-1081779174

 $ rpm --import peter-expired-backsig.pgp
 Certificate 251C20A67D942D45:
   Policy rejects subkey CB4F47D30C8C9CE1: Expired on 2020-05-08T05:11:51Z
   Certificate does not have any usable signing keys

Whereas before rpm would just say:

 error: peter-expired-backsig.pgp: key 1 import failed.


That seems like a fairly minor point to change backends and crypto
library for and could be something that can be fixed in the current
backend as well?

Of course if upstream rpm is moving, I think fedora should do so as well
to keep in line with upstream, but to me that really does imply not
using nettle but using openssl.

Paul
___
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: percona-xtrabackup bundling the kitchen sink in static libs

[Paul Wouters]

On Tue, 23 Aug 2022, Otto Liljalaakso wrote:

The relevant policy is Bundled software policy [1]. Unlike in the past, a 
package does not need a FESCo exception to bundle dependencies. However, the 
requirements of that policy are not being met here: The reason for bundling 
should be recorded in the specfile, and Provides: bundled(x) = 1.2.3 should 
be included.


[1]: https://docs.fedoraproject.org/en-US/fesco/Bundled_Software_policy/


Thanks for the link. Sadly, the justification would be "because upstream
hardcoded this an errors on any other version", which in itself is
pretty weak. And since it includes boost, which can't easilly be
upgraded between fedora releases, all the older stuff lingers forever.

If the maintainer is not responding, you should invoke the Non-responsive 
maintainer policy [2]. This package has CVE bugs open [3], so most probably 
it should eith be retired, or somebody should start caring for it.


Miro started the non-responsive maintainer process and woke up the
maintainer, but they themselves are also thinking it might be better
to kick it out of fedora.

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

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

percona-xtrabackup bundling the kitchen sink in static libs

[Paul Wouters]

Hi,

I looked at fixing percona-xtrabackup and noticed it is staticly linking
to a bunch of libraries. These .a files are then removed in %install so
they are not shipped. It bundles a bunch of this stuff from its extra/ dir:

duktape  googletest  icu  libcbor  libedit  libevent  libfido2  libkmip  lz4  
protobuf  rapidjson  robin-hood-hashing  zlib  zstd

On top of that, it pins boost to a specific (older!) version and bundles boost
seperate via dist-git / sources :(

I've just fixed it up in the same bad way, making it link to the old
openssl just to get it past F35FailsToInstall for rhbz#1989019. It is
going through rawhide and the branches now. But I think perhaps this
package should be removed from rawhide.

This package clearly breaks a lot of packaging rules, so I was
wondering if there was ever any exception of some kind given to this
package? I will definitely look at $dayjob migrating away from this,
eg see if myhoard or mariabackup can be used instead.

Any feedback would be appreciated, as it seems the maintainer is MIA.

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

[rpms/perl-Net-Server] PR #1: Add support for IPv6

[Paul Howarth]

pghmcfc merged a pull-request against the project: `perl-Net-Server` that you 
are following.

Merged pull-request:

``
Add support for IPv6
``

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

[rpms/perl-Net-Server] PR #1: Add support for IPv6

[Paul Howarth]

pghmcfc commented on the pull-request: `Add support for IPv6` that you are 
following:
``
Looks OK but I would include a reference to the bugzilla ticket, as was done 
when the equivalent fix was made in the main branch 
(https://src.fedoraproject.org/rpms/perl-Net-Server/c/db820eb).
``

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

dnf makecache memory usage increase

[Paul Wouters]

Looks like dnf makecache is uses a lot more memory, causing issues on
smaller systems/containers.

F34:

Metadata cache created.
1.51user 0.15system 0:12.01elapsed 13%CPU (0avgtext+0avgdata 162440maxresident)k
144inputs+56outputs (0major+46906minor)pagefaults 0swaps


F35:

Metadata cache created.
29.28user 2.15system 0:49.94elapsed 62%CPU (0avgtext+0avgdata 
841704maxresident)k
184160inputs+497320outputs (181major+425900minor)pagefaults 0swaps

Is this a known issue?

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

Re: Bugzilla: You can't ask Lennart Poettering because that account is disabled.

[Paul Wouters]

On Fri, 8 Jul 2022, Kevin Kofler via devel wrote:


But upstream is now under a hostile corporation's control? Can we trust the
most privileged userspace program when it is effectively controlled by a
hostile corporation?


Yes we can, by reading and evaluating the code like we always do. If it
starts to deviate from our needs and requirements, we can change things.

If Fedora was too depending on one person, this change would be good as
in that case we should have diversified these things already before and
now we would be forced to do so if that is problem.

Lennart might not be the easiest person to work with, and I have had
my personal disagreements with him, but he has never been a malicious
person and I don't expect him to suddenly become one.

I wish him luck on his new adventures.

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

Re: VirtualBox and HOST kernel-5.17.12 weirdness

[Paul Black via devel]

On Sat, 4 Jun 2022 at 05:17, Ian Laurie  wrote:

> Is anyone else seeing crashes and other strange events in VirtualBox
> 6.1.34 (from RPMFusion) with Linux guests when the Linux host is running
> Fedora 36 with kernel-5.17.12?
>


I do and on two different machines (one a Lubuntu guest and the other with
CentOS 7). 5.17.11 works fine on both.

I tried 6.1.35 which has fixes for 5.18 -
https://www.virtualbox.org/ticket/20914 - but that was no different.

With 6.1.97, the problem seems harder to trigger but not impossible.

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

Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)

[Paul Howarth]

On Tue, 10 May 2022 19:36:22 +0200
Florian Weimer  wrote:
> * Vitaly Zaitsev via devel:
> 
> > On 10/05/2022 15:29, Ben Cotton wrote:  
> >> This is initial step to move JDKs to be more like other JDKs, to
> >> build proper transferable images, and to lower certification
> >> burden of each binary.  
> >
> > Strongly -1. Bundled versions are always outdated and may be even
> > vulnerable.  
> 
> And upstream only incorporates security fixes once per quarter, so the
> recent zlib bug (CVE-2018-25032) would have to be reintroduced, or a
> downstream-only patched for it applied.  There was some confusion
> whether this bug only happened with Z_FIXED, but there's been another
> reproducer now.  Given the lack of public discussion (following
> upstream policy), it's not clear whether this has been taken into
> account.

In this case upstream might actually get there first because this CVE
is not yet fixed in Fedora
(https://bugzilla.redhat.com/show_bug.cgi?id=2068066). Of course, this
is unusual.

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

Re: Orphaned packages looking for new maintainers

[Paul Howarth]

I took mcrcon. Co-maintainers welcome.

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

[EPEL-devel] Re: EPEL7 packages still in epel-testing

[Paul Howarth]

On Wed, 20 Apr 2022 14:48:47 -0700
Troy Dawson  wrote:
>  gnucash-2.6.21-1.el72018-04-15 (1466)

Should be safe to unpush this one because gnucash-2.6.21-4.el7 should
be in epel7 stable for 2 years:

https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-aa8e8965dc

Paul.
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

perl-Config-General-2.65 license change

[Paul Howarth]

perl-Config-General-2.65 in Fedora 37 changed its license from (GPL+ or
Artistic) to Artistic 2.0.

http://rt.cpan.org/Ticket/Display.html?id=132893

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

Re: Proposal to retire perl-Crypt-RSA and its dependency chain

[Paul Howarth]

On Wed, 23 Mar 2022 11:31:48 +
Paul Howarth  wrote:

> Now that we have (or will have shortly) fully CryptX-based versions of
> perl-Net-SSH-Perl in F-36, F-37 and all EPELs, it looks to me that
> there are no remaining dependents of perl-Crypt-RSA in Fedora (other
> than the Suggests: for it in perl-Net-SSH-Perl, but I can get rid of
> that in due course).
> 
> I'm seriously considering retiring the following group of packages,
> which are only currently used by perl-Crypt-RSA as far as I can tell:
> 
> perl-Crypt-RSA
> perl-Crypt-Primes
> perl-Crypt-Random
> perl-Math-Pari
> libpari23
> 
> The last release of Crypt-RSA was in 2009. Dana Jacobsen created an
> alternative implementation
> (https://metacpan.org/dist/Alt-Crypt-RSA-BigInt) that avoided the need
> for Math::Pari, which would be a big win itself, but that doesn't look
> to have gained any traction.
> 
> I introduced all of these packages (except libpari23) to Fedora back
> in 2005 when I needed them as dependencies of perl-Net-SSH-Perl. The
> libpari package followed in 2012 because perl-Math-Pari doesn't tend
> to keep up with contemporary pari releases, and is quite painful to
> package anyway. The perl-Net-SSH-Perl package no longer needs the
> other ones, and neither do I.
> 
> Does anyone see any issues with retiring these packages in Fedora?

Great, no comments received so I'm going to go ahead with the
retirement of these packages in Rawhide.

Paul.
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: dist-git force push

[Paul Howarth]

On Fri, 1 Apr 2022 18:22:47 +0200
Hans de Goede  wrote:
> On 4/1/22 18:09, Ondrej Mosnacek wrote:
> >> Context switches for maintainers are expensive!  And while I don't
> >> personally think the "oops fixup" commits are a problem, a "PR
> >> with CI" workflow doesn't get rid of them by any means.  
> > 
> > Why not this then:
> > 
> > - fedpkg commit -sc && fedpkg scratch-build --srpm && fedpkg push &&
> > fedpkg build  
> 
> If people are going to use this, please make it one of:
> 
> 1. If you have plenty of bandwidth + enough CPU + RAM:
> 
> fedpkg mockbuild && fedpkg commit -sc && fedpkg push && fedpkg build
> 
> 2. Or if you don't:
> 
> fedpkg commit -sc && fedpkg scratch-build --arches=x86_64 --srpm &&
> fedpkg push && fedpkg build

Unfortunately fedpkg scratch-build --srpm doesn't catch the case where
the maintainer forgot to do "fedpkg new-sources" for a new upstream
release. Been there, done that...

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

Re: Please use side tags for backwards-incompatible bumps of major packages, not buildroot overrides

[Paul Howarth]

On Wed, 23 Mar 2022 10:41:52 -0700
Kevin Fenzi  wrote:

> I wonder... should we stop allowing buildroot overrides?
> 
> Or at the very least add a admon to adding a new one in bodhi,
> explaining that you should probibly use a side tag, etc?

They're still very useful when bringing up new EPEL releases. When you
have things like the perl stack with lots of interdependencies I think
side tags would be quite unwieldy. They got lots of use (not just by
me!) when bringing up EPEL-8 and EPEL-9 in particular.

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

Proposal to retire perl-Crypt-RSA and its dependency chain

[Paul Howarth]

Now that we have (or will have shortly) fully CryptX-based versions of
perl-Net-SSH-Perl in F-36, F-37 and all EPELs, it looks to me that
there are no remaining dependents of perl-Crypt-RSA in Fedora (other
than the Suggests: for it in perl-Net-SSH-Perl, but I can get rid of
that in due course).

I'm seriously considering retiring the following group of packages,
which are only currently used by perl-Crypt-RSA as far as I can tell:

perl-Crypt-RSA
perl-Crypt-Primes
perl-Crypt-Random
perl-Math-Pari
libpari23

The last release of Crypt-RSA was in 2009. Dana Jacobsen created an
alternative implementation
(https://metacpan.org/dist/Alt-Crypt-RSA-BigInt) that avoided the need
for Math::Pari, which would be a big win itself, but that doesn't look
to have gained any traction.

I introduced all of these packages (except libpari23) to Fedora back in
2005 when I needed them as dependencies of perl-Net-SSH-Perl. The
libpari package followed in 2012 because perl-Math-Pari doesn't tend to
keep up with contemporary pari releases, and is quite painful to
package anyway. The perl-Net-SSH-Perl package no longer needs the other
ones, and neither do I.

Does anyone see any issues with retiring these packages in Fedora?

Regards, Paul.
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Please use side tags for backwards-incompatible bumps of major packages, not buildroot overrides

[Paul Howarth]

On Tue, 22 Mar 2022 11:48:57 -0700
Adam Williamson  wrote:

> I found quite a big mess today, caused by an attempt to bump perl to
> 5.34.1 in Fedora 36:
> 
> https://bodhi.fedoraproject.org/updates/FEDORA-2022-cea638ebd4
> 
> Because some packages depend on the exact perl interpreter version,
> the maintainer made a buildroot override for perl:
> 
> https://bodhi.fedoraproject.org/overrides/perl-5.34.1-486.fc36
> 
> and rebuilt them. Okay.
> 
> The problem with this is, we have lots of perl modules. People build
> them all the time. And buildroot overrides apply to *everything*.
> 
> So, while the buildroot override has been valid, multiple *other* perl
> modules have been unwittingly built against it:
> 
> perl-Scalar-List-Utils:
> https://koji.fedoraproject.org/koji/buildinfo?buildID=1936732
> perl-Parallel-Pipes:
> https://koji.fedoraproject.org/koji/buildinfo?buildID=1937527
> perl-PPIx-Regexp:
> https://koji.fedoraproject.org/koji/buildinfo?buildID=1937522
> perl-Crypt-SSLeay:
> https://koji.fedoraproject.org/koji/buildinfo?buildID=1937521
> perl-Crypt-OpenSSL-PKCS10:
> https://koji.fedoraproject.org/koji/buildinfo?buildID=1937471
> 
> ...and those are just the ones I found so far. Because they were built
> against 5.34.1, all of those builds require
> "perl(:MODULE_COMPAT_5.34.1)" , which means they require perl-5.34.1
> from updates-testing. They cannot be installed with perl-5.34.0 from
> stable. But the maintainers likely had no idea about this - buildroot
> overrides are not at all discoverable, there is zero indication your
> package is building against one when you build it - and have created
> separate updates for those packages:
> 
> https://bodhi.fedoraproject.org/updates/FEDORA-2022-cb1170abf2
> https://bodhi.fedoraproject.org/updates/FEDORA-2022-d83d0ba901
> https://bodhi.fedoraproject.org/updates/FEDORA-2022-fac98e635f
> https://bodhi.fedoraproject.org/updates/FEDORA-2022-c2203f1964
> https://bodhi.fedoraproject.org/updates/FEDORA-2022-0990e3309e
> 
> Users testing those updates will likely not notice the problem,
> because they'll have *all* of updates-testing enabled when they
> update, and perl-5.34.1 will be pulled in. But if any of those
> updates is pushed stable before the perl update is pushed stable, it
> will fail to install for anyone who does not have updates-testing
> enabled.
> 
> This is quite a mess. I'm going to try and clean it up, but it'll be a
> bit ugly (there are a couple of ways I can do it, but both will
> involve doing bumps-and-rebuilds of the affected packages with no
> changes).
> 
> I've been worried about this sort of thing happening for a while due
> to the undesirable properties of buildroot overrides. This is the
> biggest real-world case I've seen, but it could certainly happen
> again. It might even have happened without anyone noticing exactly
> what was going on (just mysterious dependency issues that magically
> went away after a bit).
> 
> So: now we have convenient self-service side tags, *please use them*.
> Especially for something as major as a bump of perl that changes
> dependencies of packages built against it like this. Side tags avoid
> this mess entirely. Using the mechanism to produce an update from a
> side tag also makes it easier to make sure all the right packages are
> in the update and they don't get incorrectly submitted as separate
> updates.
> 
> Thanks folks!

OK, so this is largely my fault. Whilst I didn't do the initial perl
5.34.1 build and update, I did set up the buildroot override and the
builds of the two packages (perl-PAR-Packer and polymake) that have
hard dependencies on the specific perl version they were built against.
Unfortunately the polymake build took over 24 hours on armv7hl but
after that I could have and should have expired the buildroot override
to prevent the follow-up issues affecting other perl-related builds.
The issue was already known about and it was already planned to do the
forthcoming update for f35 to perl 5.34.1 in a side tag
(https://bugzilla.redhat.com/show_bug.cgi?id=2064808#c5).

In mitigation, my thinking was that since the f36 beta freeze is still
ongoing, the perl update and its hard dependencies would almost
certainly have been pushed to stable at the same time anyway. In
addition, since those updates were created prior to the ones for
the other modules that were incidentally built against 5.34.1, perl
itself would have been stable before the later updates arrived. So in
practice there probably wouldn't have been any mysterious dependency
issues in this particular case. And whilst I could have added the
delayed polymake build to the perl+perl-PAR-Packer update, I chose not
to so as not to reset the timer on the perl+perl-PAR-Packer update,
which would have se

Re: Orphaned packages looking for new maintainers

[Paul DeStefano]

Greetings.  I just joined devel, following directions I found on how to become 
maintainer of an orphaned package. I'm interested in helping resurrect 
'remind', last packaged for F29.  I've been using it, ran into a problem, 
needed a newer version, and realized the package was old.  I've built an RPM 
with rpmbuild, but I haven't submitted it for review because I haven't read how 
to do that, yet.  I'll pursue that as time permits in the near future; I'm not 
requesting any help. I'm writing here just because I think I'm supposed to, 
although maybe 'remind' is too old be even considered orphaned?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Package downgrades on upgrade from F35 to F36 + categorized list

[Paul Howarth]

On Fri, 18 Mar 2022 14:32:13 +0100
Fabio Valentini  wrote:
> "Forgotten" F36 updates:
> 
> 
...
> 
> - perl-Net-DNS-0:1.33-1.fc35 > perl-Net-DNS-0:1.32-3.fc36
> Version 1.33 was built on F34, F35, F37 / Rawhide, but not F36.

Fixed:
https://bodhi.fedoraproject.org/updates/FEDORA-2022-837520f9a1

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

[rpms/perl-PAR-Packer] PR #2: Rebuild for Perl 5.34.1

[Paul Howarth]

pghmcfc merged a pull-request against the project: `perl-PAR-Packer` that you 
are following.

Merged pull-request:

``
Rebuild for Perl 5.34.1
``

https://src.fedoraproject.org/rpms/perl-PAR-Packer/pull-request/2
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Curl-minimal as default (System-Wide Change proposal)

[Paul Howarth]

On Tue, 22 Feb 2022 12:00:06 -0500
Ben Cotton  wrote:

> https://fedoraproject.org/wiki/Changes/CurlMinimal_as_Default
> 
> == Summary ==
> `libcurl-minimal` and `curl-minimal` will be installed by default
> instead of `libcurl` and `curl`.
> The "minimal" variants provide only a subset of protocols (HTTP,
> HTTPS, FTP). The full versions can be explicitly requested as
> `libcurl-full` and `curl-full`.

Upstream's thoughts:
https://daniel.haxx.se/blog/2022/03/16/fedora-and-curl-minimal/

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

Re: F37 Change: Curl-minimal as default (System-Wide Change proposal)

[Paul Howarth]

On Thu, 10 Mar 2022 12:26:54 +0100
Vitaly Zaitsev via devel  wrote:

> On 10/03/2022 11:55, Alex wrote:
> > May I suggest to leave at least the telnet protocol in curl-minimal
> > for debugging purposes.  
> 
> Telnet is an extremely vulnerable protocol. It must be disable.
> 
> If you need it, you can always install libcurl-full.

I wonder, do you have the "telnet" program installed on your machine(s)?

I'd be surprised if anyone using curl's telnet *client* support wasn't
aware that it was sending plain text over the network, possibly
including any credentials that were being used. A telnet client is,
however, a very useful debugging tool for various other network
protocols, not just the telnet protocol itself. That is, I believe,
what Alex was advocating for, since the curl tool's presence is
well-nigh universal and hence always available for debugging some
network issues.

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

Re: Let's retire original glib and gtk+ (new report)

[Paul Howarth]

On Mon, 07 Mar 2022 10:29:02 -0600
Michael Catanzaro  wrote:

> On Mon, Mar 7 2022 at 04:17:09 PM +, Sérgio Basto 
>  wrote:
> > Hi,
> > In resume glib still required for 20 packages  [1],
> > apart of the sweet memories that some package bring to us , any of
> > these packages is needed ? or haven't replacement ?  
> 
> The maintainer is unwilling to retire them.
> 
> I think we should ask FESCo to force them to be retired. It's
> confusing to have ancient versions of the packages in the distro, and
> they will stick around forever if not.

I'm not unwilling to retire them, I just want their users to be retired
first so I don't leave a bunch of broken dependencies behind.

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

[rpms/perl-Net-DNS] PR #2: Remove obsolete dependency to Net::DNS::SEC and package tests

[Paul Wouters]

pwouters merged a pull-request against the project: `perl-Net-DNS` that you are 
following.

Merged pull-request:

``
Remove obsolete dependency to Net::DNS::SEC and package tests
``

https://src.fedoraproject.org/rpms/perl-Net-DNS/pull-request/2
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Orphaning some packages (w3c-markup-validator fallout)

[Paul Howarth]

Hi Nathanael,

On Mon, 31 Jan 2022 09:28:27 -0700
"Nathanael D. Noblet"  wrote:
>   I recently gave ownership of w3c-markup-validator to Sérgio Basto
> which reminded me that there are a handful of perl packages that I
> probably created/took a hand in as part of that. I haven't touched
> them in as long as w3c-markup-validator so probably should also
> orphan them as well. There are also some other packages like dspam
> that were great at the time and I used to use them but they don't get
> much if any development anymore and I don't run mail servers anymore.
> 
> The are as follows:
> 
> dspam

This one is already orphaned but you are the sole co-maintainer.

> html401-dtds

This one is yours with dcantrell as co-maintainer. Maybe ask him if he
wants it?

> perl-Config-General

You can give that one to me (FAS: pghmcfc) as I have other things that
depend on it.

> perl-HTML-Encoding

Just yours.

> perl-HTML-Tidy

Owned by eseyman and several others. I have emailed them separately.

> perl-Mail-Mbox-MessageParser

I am already the main admin for this.

> perl-Mail-MboxParser

This is owned by jplesnik.

> perl-SGML-Parser-OpenSP

Just yours.

> php-pecl-cairo

This one is yours with remi as co-maintainer. Maybe ask him if he
wants it?

> wkhtmltopdf

This is owned by mtasaka.

For the packages that have other people as main admins, you can just
remove yourself from the package. For the others, you could orphan them
or maybe reach out to any co-maintainers first.

Please assign perl-Config-General to me.

Cheers, Paul.
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Orphaning some packages (w3c-markup-validator fallout)

[Paul Howarth]

Hi Nathanael,

On Mon, 31 Jan 2022 09:28:27 -0700
"Nathanael D. Noblet"  wrote:
>   I recently gave ownership of w3c-markup-validator to Sérgio Basto
> which reminded me that there are a handful of perl packages that I
> probably created/took a hand in as part of that. I haven't touched
> them in as long as w3c-markup-validator so probably should also
> orphan them as well. There are also some other packages like dspam
> that were great at the time and I used to use them but they don't get
> much if any development anymore and I don't run mail servers anymore.
> 
> The are as follows:
> 
> dspam

This one is already orphaned but you are the sole co-maintainer.

> html401-dtds

This one is yours with dcantrell as co-maintainer. Maybe ask him if he
wants it?

> perl-Config-General

You can give that one to me (FAS: pghmcfc) as I have other things that
depend on it.

> perl-HTML-Encoding

Just yours.

> perl-HTML-Tidy

Owned by eseyman and several others. I have emailed them separately.

> perl-Mail-Mbox-MessageParser

I am already the main admin for this.

> perl-Mail-MboxParser

This is owned by jplesnik.

> perl-SGML-Parser-OpenSP

Just yours.

> php-pecl-cairo

This one is yours with remi as co-maintainer. Maybe ask him if he
wants it?

> wkhtmltopdf

This is owned by mtasaka.

For the packages that have other people as main admins, you can just
remove yourself from the package. For the others, you could orphan them
or maybe reach out to any co-maintainers first.

Please assign perl-Config-General to me.

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

[rpms/perl-DateTime-Format-Strptime] PR #1: Update to 1.79

[Paul Howarth]

pghmcfc merged a pull-request against the project: 
`perl-DateTime-Format-Strptime` that you are following.

Merged pull-request:

``
Update to 1.79
``

https://src.fedoraproject.org/rpms/perl-DateTime-Format-Strptime/pull-request/1
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[rpms/perl-Text-SpellChecker] PR #1: Update hunspell directory path

[Paul Howarth]

pghmcfc merged a pull-request against the project: `perl-Text-SpellChecker` 
that you are following.

Merged pull-request:

``
Update hunspell directory path
``

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

Intent to retire w3c-markup-validator, perl-HTML-Tidy, tidyp

[Paul Howarth]

Hello all,

I'm the Fedora maintainer of the perl-HTML-Tidy package and its
underlying library, tidyp.

The upstream maintainer of these packages has now stopped work on
tidyp, and has archived the upstream repository in a read-only state:
https://github.com/petdance/tidyp

He has also stopped work on HTML-Tidy, and is working on HTML-Tidy5
instead.

Since I no longer use this software myself, I'm intending to stop
maintaining it in Fedora. The only package I can find in Fedora that
depends on perl-HTML-Tidy is w3c-markup-validator; I have contacted
Nathanael, the maintainer of w3c-markup-validator, and since he no
longer uses that package, it would seem like the best thing to do would
be to retire all three packages.

If any other packager has an interest in any of these packages, let us
know and we can transfer ownership of them over to you. Otherwise,
they'll be retired at the start of February, before Fedora 36 is
branched.

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

Re: Orphaned packages looking for new maintainers

[Paul Howarth]

I took perl-Test-Fixme.

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

Re: Undoing my screw-up with python-async-timeout

[Paul Wouters]

On Wed, 19 Jan 2022, Miro Hrončok wrote:

It seems the update received negative karma in Fedora 35 -- when that 
happened, you should have immediately disabled autopush to Fedora 34. (I am 
not saying this to rub your nose in it, but rather as an advice for 
future-you and for others as well.)


Yes indeed. I'll pay more attention to that from now on as well.

No, I don't think we need to carry the epoch to F35 and rawhide. Distro 
upgrades happens with distro-sync.


That's what I thought...


 I am looking for some guidance to ensure I don't break things even more
 and I apologise for the extra work that I have and am causing everyone.


My guidance: Open a Pull Request with the revert+epoch and share the link 
here.


Done: https://src.fedoraproject.org/rpms/python-async-timeout/pull-request/2

Thanks,

Paul
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

[EPEL-devel] Re: The incredibly shrinking RHEL

[Paul Howarth]

On Fri, 14 Jan 2022 07:02:23 -0500
Josh Boyer  wrote:
> 2) Moving content to CRB in RHEL is not a silver bullet solution in
> many scenarios.  If it's strictly for build dependencies, CRB works
> well.  If an EPEL package has a runtime requires on CRB content, that
> is less desirable.  RHEL CodeReady Linux Builder (CRB) content is
> unsupported, not enabled by default, and not intended to be used at
> runtime in production.  EPEL itself is clearly in the same unsupported
> category, but requiring another unsupported repo at runtime may lead
> to unintentional surprises for many users.

The EPEL documentation specifically says to enable CRB/PowerTools if
you're using EPEL:

https://docs.fedoraproject.org/en-US/epel/#how_can_i_use_these_extra_packages

NOTE for RHEL 8 users with certificate subscriptions: EPEL packages
assume that the 'codeready-builder' repository is enabled. You can
do this with:

subscription-manager repos --enable
"codeready-builder-for-rhel-8-$(arch)-rpms"

NOTE for CentOS 8 and CentOS Stream 8 users: EPEL packages assume
that the 'powertools' repository is enabled. You can do this with:

dnf config-manager --set-enabled powertools


Whilst that is for EL-8 I don't see why it would be different for EL-9.
In particular, for interpreted languages like perl there are a large
number of runtime dependencies from EPEL packages to packages in CRB.

Paul.
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: How to reach the certbot SIG?

[Paul Howarth]

Hi,

On Thu, 25 Nov 2021 09:21:27 +0100
spike  wrote:

> Hi everyone,
> 
> I've been trying to contact Fedora's certbot SIG for a while now.
> Back then I wanted to help fix some issues with python-dns-lexicon
> (which are resolved upstream now and an update has trickled down to
> Fedora 35 with the latest release) but currently I'm trying to find
> somebody who's willing to review
> https://bugzilla.redhat.com/show_bug.cgi?id=2019398
> 
> I've tried to subscribe to the corresponding mailing list at
> https://lists.fedoraproject.org/admin/lists/certbot-sig.lists.fedoraproject.org/.
> The subscription needs to be approved however, so postorious tells me
> that "You have a subscription request pending. If you don't hear back
> soon, please contact the list owners." I sent an email to the
> provided address certbot-sig-ow...@lists.fedoraproject.org about 6
> months ago but didn't hear back. So next I went to #fedora-admin to
> ask if maybe my subscription request and/or email didn't come
> through. I was told to contact nb directly since he seems to be the
> owner of said list. I tried to reach him through IRC and sent him a
> mail to the address provided in the fedora user database.
> Unfortunately I didn't hear back.

I'd suggest contacting Felix Schwarz , who
seems to do most of the work on the certbot packages.

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

Re: Self Introduction: Roman Inflianskas

[Paul Wouters]

On Tue, 26 Oct 2021, Roman Inflianskas via devel wrote:


Subject: Self Introduction: Roman Inflianskas

Dear Fedora Community,My name is Roman Inflianskas.I work at aiven.io (DBaaS 
based on Open-Source technologies) as a Python
Backend Developer, and my motivation for becoming a Fedora maintainer is to 
package software that is used by Aiven so that my
effort had more impact. I contributed to SaltStack, KDE, Taskwarrior, aiogram, 
Vim plugins, LaTeX/LyX style of Russian standard
for research work; packaged some software for openSUSE for myself, etc. My 
personal website is http://roman.inflianskas.ru. In
spare time I like to walk in a beautiful Central Park of Helsinki.I've prepared 
`python-cs` and `python-requests-exoscale-auth`
on my PC. Here is the first ticket: 
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2017419The person, who 
recommended
people in our company to become Fedora maintainers is Paul Wouters. I'm 
grateful to him for this.Best Regards,
Roman


Welcome Roman! I'm happy to see more Aiven people join our Fedora efforts :)

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

Migrate python3-language-server upstream to the version maintained by the community

[Mairo Paul Rufus]

Currently python3-language-server upstream is 
https://github.com/palantir/python-language-server which is currently 
unmaintained, this is a proposal to move that to 
https://github.com/python-lsp/python-lsp-server which is a community-maintained 
fork.
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

[rpms/perl-Algorithm-C3] PR #1: Package tests

[Paul Howarth]

pghmcfc merged a pull-request against the project: `perl-Algorithm-C3` that you 
are following.

Merged pull-request:

``
Package tests
``

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

Re: F35 Change: Remove SHA-1 from Sqlite (Self-Contained Change proposal)

[Paul Wouters]

On Mon, 12 Jul 2021, Simo Sorce wrote:


SQLite is a general-purpose tool.  Not every use of SHA-1 is
cryptographically relevant.  Most uses in the context of SQLite probably
aren't, so the removal just annoys users for no good reason.


Note that this is a Sqlite decision, from RHEL engineering we only
requested the removal in digital signatures and where integrity
protection is required for security.
Also note that we do not require full removal, just that SHA-1 is not
used unless users intentionally change configuration.


How does this affect users of NSS who have created "default" databases,
eg using certutil -N ?  Do these use SHA1? If so, can they be migrated
to SHA2?  Automatically ?

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

[rpms/perl-Socket6] PR #2: Remove support of gethostbyname2

[Paul Howarth]

pghmcfc merged a pull-request against the project: `perl-Socket6` that you are 
following.

Merged pull-request:

``
Remove support of gethostbyname2
``

https://src.fedoraproject.org/rpms/perl-Socket6/pull-request/2
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F35 Change: Disable SHA1 In OpenDNSSec (Self-Contained Change proposal)

[Paul Wouters]

On Mon, 28 Jun 2021, Ben Cotton wrote:


https://fedoraproject.org/wiki/Change/DisableSHA1InOpenDNSSec



== Detailed Description ==

OpenDNSSec changed the default behavior to not include SHA1 DS by
default, and added the -sha1 knob as an immediately-deprecated
compatibility knob in version 2.1.0 (2017-2): "OPENDNSSEC-552: By
default ‘ods-enforcer key export –ds’ included the SHA1 version of the
DS. SHA1 use is discouraged in favour of SHA256. To get the SHA1 DS
use the –sha1 flag. This flag is immediately deprecated and will be
removed from future versions of OpenDNSSEC." (see ChangeLog:
https://www.opendnssec.org/archive/releases/ ).

The proposal is to disable the -sha1 knob in Fedora. I will also open
an issue upstream to remove all the sha1-related code.


This change makes me a bit nervous, and I'm the author of RFC 8624 that
recommennds not using SHA-1 for DS/CDS records anymore.

https://datatracker.ietf.org/doc/html/rfc8624#section-3.3


Supporting statement
[https://www.icann.org/en/blogs/details/its-time-to-move-away-from-using-sha-1-in-the-dns-24-1-2020-en
[from ICANN] (2020-1-24): "Now is the time for administrators of zones
at all levels of the DNS to stop using SHA-1 and change to algorithms
using stronger hashes."


While this is true, the order of where things need to change are:

1 Discourage, but not block, the use of SHA-1. Eg remove it from the default 
set.
2 Ensure the migration of SHA-1 based records to SHA-256 is taking place
3 remove support for SHA-1

This plan assumes we are in phase3. I would say we are in phase2.

Remember, any domain that depends on SHA-1 is going to be more secure
than being marked as insecure because SHA-1 is rejected. This is somewhat
different from like SHA-1 support for authentication where the rejection
of a weaker algorithm forces the use of a stronger algorithm.

The DNSSEC fallback when an algorithm is not supported is to go insecure,
not insist on a more secure SHA-2 that is not there. With DNSSEC,
there is not client-server exchange like with TLS or IPsec. There is
a producer on one end, and a consumer on the other end. The two do not
negotiate crypto parameters.


== Benefit to Fedora ==
* This change makes sure OpenDNSSec in Fedora follows ICANN's
guidelines and does not propose SHA1 DS. This is is needed given the
[https://sha-mbles.github.io/ latest attacks against SHA-1]. More
in-depth articles are available
[https://www.dns.cam.ac.uk/news/2020-01-09-sha-mbles.html there] and
[https://mailarchive.ietf.org/arch/msg/dnsop/hA4Ur9qxRJIUo13Pjpmrm_va7cs/


I know that a few people believe that shambles can in theory be abused
with DNSSEC, but a lot of people also believe the constrains of DNS
RRsets make this impossible. But even _if_ it is possible, it would
only affect multiple domains that share the same private key that made
the SHA-1 signature. And then we are talking about RRSIG records and
not, as in this proposal, the DS/CDS RDATA content.


Patch the enforcer so that bsha1 is not honored anymore:


I don't think fedora should move faster than upstream opendnssec. I
believe the people at the IETF and the software developers of the DNS
software are more aware of where we are in the migration path than
individual Fedora developers.


== Upgrade/compatibility impact ==
Zones with SHA-1 signatures can be migrated to SHA-256 by re-signing the zone.


The RRSIG signature is not related to the DS signature. Zone resigning
is something completely different from the DS/CDS records. Those records
are signed by the parent zone, and use whatever algorithm the parent
zone uses, which the child zone cannot dictate.


This change might break (very old) clients that only recognize SHA-1
but these should already be broken (on the Internet at least) because
the root zone is signed with SHA-256 only.


The root zone has no DS record, so this statement does not make sense.
The RRSIG signature algorithm is unrelated to the DS/CDS record RRdata
that contains a hash of the child's public key, where the hash is created
with SHA-1 or SHA-2.


== User Experience ==

OpenDNSSec in Fedora can currently be used to sign zones with SHA1.
With this change, this will no longer be possible. The migration from
SHA1 is underway anyway.


So there are two things that really need to be clarified for this
proposal. Is it talking about DS/CDS signature algorithm as per IANA
registry http://www.iana.org/assignments/ds-rr-types, or are we talking
about DNSKEY signature algorithm, that is responsble for signing all
the zone data, that uses a hash algorithm or SHA-1 or better. Based on
the description, I am a bit worried that it is not entirely clear what
the proposed change actually is.

Please feel free to reach out to me directly to talk about this feature
request.

Paul
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Cod

[rpms/perl-Path-Tiny] PR #1: Remove runtime depencendy for Digest::MD5

[Paul Howarth]

pghmcfc merged a pull-request against the project: `perl-Path-Tiny` that you 
are following.

Merged pull-request:

``
Remove runtime depencendy for Digest::MD5
``

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

Re: Offering strongswan for (co)maintaining

[Paul Wouters]

On Wed, 31 Mar 2021, Petr Menšík wrote:


strongswan and NetworkManager-strongswan packages were passed to me from
previous maintainer. I admit I have little experience with them and do
not run any service based on them. Because IPSsec is quite complex
technology, I am looking for help with its maintenance. I was always
using OpenVPN based solutions myself, so I guess I am not the best
person as main admin. I would like to transfer main admin to anyone
doing a good job, not not immediately. That is why I haven't orphaned it
already.

I would like to keep commit access for a while, but I would share at
least commit access with anyone willing to improve those packages.
Especially someone using they (almost) everyday would be ideal maintainer.


I have been maintaining strongswan for the last couple of years now. I use
it regularly at upstream libreswan to run interop testing. I am actively
maintaing strongswan for this. I am also an admin on this package. Pavel
is also an admin but he has not worked on the package in many years.

But orphaning seems a bit dramatic when there is an active maintainer ?  :)

As for NetworkManager-strongswan, I am not an actie user of this, but I
could just pick it up for the community. I see it is two versions
behind, so I'll go and update it. For some reason, src.fp.org does not
want to show me this package, so I cannot see who else has admin/commit
rights (or request admin/commit for it)

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

python-invoke orphaned

[Paul Howarth]

Hi,

I have orphaned python-invoke, whose test suite requires
pytest-relaxed, which requires pytest < 5 and fails to build with
Python 3.10.

I believe this only impacts python-jsonmodels; not sure how big an
impact it is.

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

Re: Let's retire original glib and gtk+

[Paul Howarth]

On Tue, 25 May 2021 17:00:31 -0500
Michael Catanzaro  wrote:

> On Sat, May 22 2021 at 09:23:23 AM +1000, Bob Hepple 
>  wrote:
> > I have no idea how significant this might be, but perhaps this
> > should be discussed more publicly.  
> 
> Use containers? Ship your own glib as a static lib? I'm impressed you 
> have software that still needs it tbh.
> 
> Anyway, there have been no other objections, and there's been no 
> comment from the package owner, so I wonder if any provenpackagers 
> would be willing to do the glib package retirement?

I'm the package owner and I'm prepared to retire glib/gtk+ once there
are no further dependencies on them in Fedora.

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

[rpms/perl-IO-Socket-INET6] PR #1: Patch for bad code in test

[Paul Howarth]

pghmcfc merged a pull-request against the project: `perl-IO-Socket-INET6` that 
you are following.

Merged pull-request:

``
Patch for bad code in test
``

https://src.fedoraproject.org/rpms/perl-IO-Socket-INET6/pull-request/1
___
perl-devel mailing list -- perl-de...@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-de...@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Bacula 11.0.2-3 for Fedora 33?

[Paul Howarth]

On Sun, 25 Apr 2021 11:17:49 -0400
"Steven A. Falco"  wrote:

> This morning "dnf update" brought in bacula 11.0.2-3.  Previously I
> had been on 9.6.7-1.
> 
> Apparently, the new bacula wants a different database version.  I
> have version 16, but it wants 1022.

I was surprised by this myself yesterday.

> I looked at the files in /usr/share/doc/bacula-director/updatedb but
> there doesn't seem to be anything to update the db from 16 to 1022.
> 
> For now, I've rolled back to 9.6.7-1 and blocked further dnf updates
> of bacula.
> 
> Are there any additional instructions on how to update the bacula
> database?

Normally I would use /usr/libexec/bacula/update_mysql_tables but I
found in this case that it didn't work because it was trying to drop an
index from a table that didn't already exist (the index, not the
table).

I did manage to complete the update by opening up a mysql session and
manually running the commands in the update script for upgrades from
version 16, which is several incremental upgrades to get to 1022. I
ignored the errors relating to commands for dropping indexes that
weren't there.

Beware that if you have a substantial "File" database that this process
will take quite a long time and require a little more free disk space
than taken by the existing bacula database, on top of the original
database.

My backups ran apparently successfully last night on the new version.
This morning I tested a restore that pulled in 14,637 files that came
from a mix of full and differential backups on the old version and the
latest incremental on the latest version. That worked OK.

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

Re: Retiring from Perl maintenance

[Paul Howarth]

Hi Petr,

On Fri, 9 Apr 2021 18:04:34 +0200
Petr Pisar  wrote:

> V Tue, Apr 06, 2021 at 12:21:46PM +0200, Petr Pisar napsal(a):
> > I found a different role in Red Hat which is incompatible with
> > maintaining hundreds of packages. As a result, I will reassign my
> > packages with a Red Hat's interrest to Michal Spacek (mspacek) who
> > replaces me at Red Hat.
> 
> I've just given 88 packages and 259 admin roles to mspacek. I wish
> him happy days with their maintenance.
> 
> > The rest of my packages will be orphaned and available for anyone
> > to take.
> > 
> The rest counts for 526 packages. Those are Fedora Perl packages I'm
> the owner. The list is attached for your reference.
> 
> I will retain them for some time to see how large work load they will
> generate.  According to a sample probe, an average year of my last
> commit to them is 2016.  If the workload will be larger than
> negligable, I will orphan them and post a list on Fedora devel
> mailing list.
> 
> Nevertheless, if you are interested to any of them, don't hesitate
> and contact me and I will reassign them to you.

I'm happy to take the following:

perl-Function-Parameters
perl-Math-Random-MT-Auto
perl-Object-InsideOut
perl-Perl-Critic-Deprecated
perl-Perl-Critic-Lax
perl-Perl-Critic-Pulp
perl-PPIx-QuoteLike
perl-Sereal
perl-Sereal-Decoder
perl-Sereal-Encoder
perl-Test-UseAllModules

Good luck in your new role!

Cheers, Paul.
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Pytest 4 in Fedora, let's get rid of it please

[Paul Howarth]

On Tue, 2 Mar 2021 09:10:32 -0800
Kevin Fenzi  wrote:

> On Tue, Mar 02, 2021 at 04:40:54PM +0000, Paul Howarth wrote:
> > Hi all,
> > 
> > On Tue, 2 Mar 2021 16:06:40 +0100
> > Miro Hrončok  wrote:
> >   
> > > Given the lack of communication from the paramiko/invoke
> > > maintainers, I've just orphaned python-pytest4. If nobody picks
> > > it up, I plan to continue maintaining it in Fedora 33 and 34.  
> > 
> > The paramiko/invoke maintainers would be me. Sorry for not
> > responding but was very busy with work and I kept kicking it down
> > the road.
> > 
> > My interest in paramiko comes from use with ansible, which I am an
> > active user of. I picked up paramiko when it got orphaned.  
> ...snip...
> 
> So, I am sure you are aware, but just to note, ansible can use
> paramiko (and indeed thats default for el6, but nothing newer with
> ControlPersist in ssh) but largely doesn't need it anymore. 
> 
> As ansible maintainer I would be ok dropping it from ansible, but if
> you are going to keep it around, ansible can keep Requiring it in
> case some usecase needs it. :)

Good to know, thanks. I've dropped the invoke and pytest-relaxed
dependencies from paramiko now so there's no reason why it shouldn't
stay around.

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

Re: Pytest 4 in Fedora, let's get rid of it please

[Paul Howarth]

Hi all,

On Tue, 2 Mar 2021 16:06:40 +0100
Miro Hrončok  wrote:

> Given the lack of communication from the paramiko/invoke maintainers,
> I've just orphaned python-pytest4. If nobody picks it up, I plan to
> continue maintaining it in Fedora 33 and 34.

The paramiko/invoke maintainers would be me. Sorry for not responding
but was very busy with work and I kept kicking it down the road.

My interest in paramiko comes from use with ansible, which I am an
active user of. I picked up paramiko when it got orphaned.

My interest in invoke is due to it being an optional dependency of
paramiko. I picked up invoke when it got orphaned. Its test suite does
not work with any remotely modern version of pytest and that doesn't
look like being fixed any time soon.

Further down that dependency chain are python-spec, python-fluidity-sm
and python-should_dsl, which I look after as they're test dependencies
of invoke, though they're pretty much dead upstream it would seem.

The easiest thing for me to do would be to drop the dependency on
invoke from paramiko. I would no longer have an interest in invoke or
its test dependencies, and I'd actually be glad to be rid of them
personally. It might still be a problem for python-jsonmodels though: I
don't know how hard the dependency on invoke there is.

Then there is the problem of what to do with pytest-relaxed but I'd
happily take a patch to paramiko to get rid of it.

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

Re: systemd-resolved fallback DNS servers: usability vs. GDPR

[Paul Wouters]

On Wed, 24 Feb 2021, Colin Walters wrote:


It's trickier than that because local caching nameservers can provide real 
benefits in various server scenarios, and also the IoT/edge case (as usual) 
blurs the traditional datacenter/mobile boundary.  (IoT can be servers with 
WiFi)

We ended up enabling resolved in FCOS, although it took a bit because it broke 
OpenShift, see:
https://github.com/openshift/okd-machine-os/pull/15
https://github.com/openshift/machine-config-operator/pull/2377
https://github.com/openshift/okd-machine-os/pull/47
etc.


It's hard to read through those. It's a big nest of issues, fixes and
reverts on adding/removing systemd-resolved. I couldn't figure out
the DNS setup based on these reports.


(It's really complex for OpenShift because we have a split between the host DNS 
and pod DNS which is served by CoreDNS, yet some cases span those, plus some 
on-premise installs differ from cloud/Iaas in this)


I'm confused here too, since AFAIK NM does not support tying queries for
certain domains to certain nameservers, and I was told that NM
configures DNS, not systemd-resolved, so how is that done in this case
then? For VPN, to support split-DNS you ran a full resolver like
unbound that has this support, and does not get configured through NM.

I guess I can't say more unless someone can point me to some
documentation on the DNS deployment details there. However, this
all changes nothing that different systems want to use different
DNS solutions, and making systemd-resolved part of the init package
so it is mandatory to install is not appropriate.

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

Re: systemd-resolved fallback DNS servers: usability vs. GDPR

[Paul Wouters]

On Tue, 23 Feb 2021, Lennart Poettering wrote:


And yeah, call me a hypocrite, but if I have the choice between having
no Internet at all or using some public DNS servers for DNS, and
leaking a tiny bit of information to those DNS server providers then I
am definitely preferring to have Internet, thank you very much.


In practise, this is not often the case. Almost always, the network will
provide working DNS via DHCP. If not, then the network is severely
broken and hacking up a DNS workaround is likely to fail anyway. Like,
you can't get past hotspot/captive portal.

Newly installed and booted server/cloud images should _really_ use the
DHCP obtained DNS servers. It is very likely their correct functioning
depends on local DNS zones and local resources pointed to by DNS not
available when bypassing the local DNS for public DNS services. It is
also likely that those networks even restrict DNS to only allow their
own DNS servers to be used for security and compliance reasons, and
using public DNS would be a violation of network policy.

The scenario of roaming laptops/phones is completely different from
this. Which is why I have argued for a long time now that
systemd-resolved should not be installed by default on servers or
containers. It adds complexity without any real gain in these
deployments and makes DNS issues harder to troubleshoot.


One could even go further: the privacy level using those public DNS
servers might actually be higher than using the DHCP-provided ones in
many cases, simple because we can use DoT on the former (admittedly
not yet the default in resolved though, but hopefully soon), but
almost never can on the latter, and what's worse the latter are
usually provided by crappy edge networks like Internet Cafés and such
where the fact we send stuff unencrypted is just awful.


I agree with this, but the caveat here is that the solution should take
into account isolating the hotspot/signon network from the OS, and not
mix that into your caches when you later bring up more private/trustworthy
DNS servers. But as I said, I'm fine with the default of
systemd-resolved here, although I would strongly prefer to be able to
not install or remove the package for advanced users like me with
specific DNS and DNSSEC requirements that cannot have systemd-resolved
interfering with the system.


Now, Fedora made its choice here, and I'll accept that, but I still
think it's a bad one, that trades a misunderstood concept of privacy
against a major step forward in userfriendliness. i.e. I am not sure
it's a good choice to limit Fedora's userspace needlessly to people
who can fix their DNS configuration. It's a pretty tiny elite group of
people to be in after all...


It seems to have a price of network administrators having their DNS
broken in a string of different ways resulting in filed bugs at
systemd upstream that takes years to get addressed. It can be argued
that this price is too high for the feature of helping nontechnical
laptop users that stumbled into a broken network.

Meanwhile, applications like firefox are absorbing DNS anyway, adding
another layer in the fight over who gets to configure and process DNS:
DHCP, systemd-resolved, NetworkManager, Gnome, or applications.


(Oh, and I don't appreciate those people at all, who claim that
"resolved sends all DNS lookups" to Google because it's a lie, we
never did that, we only did that in case no better DNS configuration
was available, i.e. as *last* *resort*, one step before giving up
entirely).


This seems contradicting? The last resort method only sends all DNS
queries to google as a last resort? It still means that in 100% of
the cases that the last resort is activated, it sends all traffic to
google? Furthermore, since it hides that this is happening, once
the network is broken, it never gets fixed, and thus leads to the
fallback always kicking in.

If anything, these recurring discussions, and long turnover of
systemd-resolverd bugs show that systemd-resolved should be a choice
and not being pushed as mandatory. And I am fine with saying that for
Workstation or Desktop installs, we lean to the side of userfriendly
and give them systemd-resolved. But it has no place as a default
binary or service on servers, containers or cloud images launched
within actively managed networks.

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

Re: [dns-sig] Re: split-DNS, resolvconf on Fedora

[Paul Wouters]

On Mon, 22 Feb 2021, Petr Menšík wrote:


Wouldn't it be much simpler, if I could just dnf remove systemd-resolved
in case I don't want it?


In the past I also mentioned this. The overwhelming majority of installs
do not gain any benefit from te systemd-resolved service. Most servers,
containers and even workstations are installed and given DNS
configurations via DHCP, manager by a network administrator.

systemd-resolved addresses a problem with finding printers and resolving
a .box domain for router reconfiguration. And it provides partial
solutions for split-DNS views when VPN's are deployed on laptops.

There is no technical reason why this is not in its own package. There
has been some focussing on reducing minimal installs, and this is a
prime candidate for that. I'm fine with the workstation or desktop
installs bringing this package in by default. But I see only potential
harm from installing it on servers, containers and most virtual machines.

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

Unretiring perl-Crypt-PBKDF2

[Paul Howarth]

The perl-Crypt-PBKDF2 package was retired about a year ago due to
having been orphaned for 6+ weeks. I'm unretiring it because it's a
dependency for updating perl-Crypt-CBC.

Review request:
https://bugzilla.redhat.com/show_bug.cgi?id=1928111

Releng ticket:
https://pagure.io/releng/issue/10016

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

perl-Test-File license change

[Paul Howarth]

perl-Test-File-1.44.4-1.fc34 changed license from perl (GPL+ or
Artistic) to Artistic 2.0.

Paul.
___
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