[rpms/perl-Compress-Raw-Lzma] PR #2: Rebuild against xz 5.6.1
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: Troubleshooting MD RAID assembly not working after upgrade to F39
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?
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
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
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
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
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
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
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
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
Re: Several questionable packages installed on fresh system
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
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
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
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
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
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
[rpms/perl-Crypt-CBC] PR #1: Update license to SPDX format
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
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
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
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
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
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
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
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
Issue with hardened build
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?
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 ?
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
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
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
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: When is a file dependency appropriate?
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
[rpms/perl-Net-Server] PR #1: Add support for IPv6
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
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
Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
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
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
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
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
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
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
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
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
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 set it back by 2 days and potentially resulted in other modules being pushed to stable before the underlying perl update. Anyway, won't happen again. Regards, Paul. ___ devel mailing
Re: Package downgrades on upgrade from F35 to F36 + categorized list
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
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)
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)
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)
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
Re: Orphaning some packages (w3c-markup-validator fallout)
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)
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
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
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
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
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
[EPEL-devel] Re: The incredibly shrinking RHEL
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?
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
[rpms/perl-Algorithm-C3] PR #1: Package tests
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
[rpms/perl-Socket6] PR #2: Remove support of gethostbyname2
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
[rpms/perl-Path-Tiny] PR #1: Remove runtime depencendy for Digest::MD5
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
python-invoke orphaned
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+
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
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?
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
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
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
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
Unretiring perl-Crypt-PBKDF2
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
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
Re: Build needed - Dovecot CVE-2020-24386 has gone public
On Wed, 6 Jan 2021 12:11:43 +0100 Marius Schwarz wrote: > we need an urgent build of 2.3.13 as the CVE-2020-24386 got public. > > I saw in Koji that the first build failed on the 4th Jan for F32 and > F33. > > Can someone pls help and invest this, as it's a critical security > issue. The test suite fails on some architectures. I sent a PR upstream that fixes i386 builds for me: https://github.com/dovecot/core/pull/149 (note: I'm not the dovecot maintainer, and nobody has commented on my PR). 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
Orphaned trac-accountmanager-plugin and trac-spamfilter-plugin
Hi all, neither trac-accountmanager-plugin nor trac-spamfilter-plugin work with the development (1.5.x) build of trac currently in Fedora 33 and Rawhide. This may change at some point but as I can't use them with trac on my Fedora 33 server, I've decided to abandon my own use of trac. Hence I have orphaned the plugins. Good luck to anyone that wants to take them over. 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
Re: EPEL8 Branch Request: perl-Data-GUID
On Thu, 8 Oct 2020 15:30:43 +0200 Pierre-Yves Chibon wrote: > On Thu, Oct 08, 2020 at 03:27:22PM +0200, Pierre-Yves Chibon wrote: > > On Thu, Oct 08, 2020 at 03:22:46PM +0200, Emmanuel Seyman wrote: > > > > > > Hello, all. > > > > > > Ralf Corsepius has requested that someone give Paul Howarth and > > > Jitka Plesnikova collaborator rights in bug #1870755 . Their FAS > > > usernames are pghmcfc and jplesnik respectively. > > > > > > Is there someone on the list who can do this? > > > > I can, on it. > > Done Now I need someone to create the epel8 branch because collaborators can't request their own branches. https://pagure.io/releng/fedora-scm-requests/issue/29566 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
[EPEL-devel] Re: Continuing playground discussion
On Fri, 4 Sep 2020 07:18:31 -0700 Troy Dawson wrote: > Step 4 - Untag all the things that are "older" in playground > -- currently that is a releng process. There is no way for a > maintainer to retire their package from playground. > -- This needs to happen some time (3 months?) after step 2 is > finished. A time that we can see that people have manually built > their package in playground, versus the automatic builds. So that the > "older" packages are obvious. Isn't it likely that builds with the same NEVR (apart from the disttag) in playground as in EPEL-8 proper are automatic builds rather than manual ones? That would certainly reflect my own usage, where almost all of my packages would be the same, but my manual build of proftpd is different. 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
Re: Galera FTBFS in f33, but same build passes in f32
On Thu, 27 Aug 2020 14:21:03 +0200 Lukas Javorsky wrote: > Hi folks, > > I've run into the compilation problem in the Galera package > This problem occurs only on f33 and higher tho. > > Here is build performed on Fedora 32: > https://koji.fedoraproject.org/koji/taskinfo?taskID=50232504 > > And here is the same build, but on Fedora 33: > https://koji.fedoraproject.org/koji/taskinfo?taskID=50232498 > > Does anyone know what could cause this? > It looks like something that changed in *cc1plus* or *scons *is > causing this, so if you had similar issue, please let me know. > > Thanks for any help. > Lukas Looks like you might be hitting https://bugzilla.redhat.com/show_bug.cgi?id=1850198 (changed api for fail_if and fail_unless in check), the workaround for which now introduces warnings, and they are turned to errors by the use of "-Werror". 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
Re: Strange build failures in rawhide buildroot (cont'd) - glibc 2.33 dev snapshot?
On Sat, 15 Aug 2020 16:28:47 +0200 Fabio Valentini wrote: > - autoreconf fails because %build needs a newer shell (protobuf): > > /usr/bin/autoconf: This script requires a shell more modern than all > /usr/bin/autoconf: the shells that I found on your system. > /usr/bin/autoconf: Please tell bug-autoc...@gnu.org about your system, > /usr/bin/autoconf: including any error possibly output before this > /usr/bin/autoconf: message. Then install a modern shell, or manually > run /usr/bin/autoconf: the script under such a shell if you do have > one. autoreconf: /usr/bin/autoconf failed with exit status: 1 > > - shell not executing stuff in backticks `command foo` but returns > empty string (tonto): > `build-classpath foo` # this doesn't work? > > > I'm getting the sinking feeling that RPM scriptlets are broken? Do > they get run in the wrong shell? sh instead of bash maybe? > > I'm grasping at straws here, but all those build failures are starting > to be really disruptive to the work that I'm actually trying to do ... I had an issue with a configure script wanting a more modern shell. I tried running mock with --isolation-simple and it stopped complaining. Maybe that would help you too? 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
Re: Proposal to Add: Log In/Out Blocker Criteria
On Tue, 4 Aug 2020 10:55:30 +0200 Christopher Engelhard wrote: > On 04.08.20 10:47, Miro Hrončok wrote: > > I would even go further and remove the "with multiple user accounts" > > condition. Even on a singe user system, I'd like to be able to log > > out and back in again. > > +1 on that. If you remove the "with multiple user accounts" then being able to log in and out on a single-user system would satisfy the requirement even if the multi-user bug was present, which wouldn't be very helpful. 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
Orphaning perl-perl5i
I've just orphaned perl-perl5i (https://src.fedoraproject.org/rpms/perl-perl5i). I can't see any dependencies in Fedora so it shouldn't cause any issues if it gets retired. The package is FTBFS since Perl was updated to 5.32 and perl-Devel-Declare was updated to a version compatible with 5.32: https://github.com/evalEmpire/perl5i/issues/307 The perl5i module uses Devel::Declare to implement function and method signatures (https://metacpan.org/pod/perl5i#Subroutine-and-Method-Signatures), in a similar fashion to the Function::Parameters module (https://metacpan.org/pod/Function::Parameters), so it shouldn't be *too* hard to fix but upstream has been inactive for a few years now. 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
[rpms/perl-Compress-Raw-Lzma] PR #1: Use make macros
pghmcfc commented on the pull-request: `Use make macros` that you are following:
``
I did a bigger change that used %{make_install} too.
``
To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-Compress-Raw-Lzma/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
[rpms/perl-Compress-Raw-Lzma] PR #1: Use make macros
pghmcfc closed without merging a pull-request against the project: `perl-Compress-Raw-Lzma` that you are following. Closed pull-request: `` Use make macros `` https://src.fedoraproject.org/rpms/perl-Compress-Raw-Lzma/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
[EPEL-devel] Re: Modules again
On Tue, 19 May 2020 19:00:25 +0100 Paul Howarth wrote: > On Tue, 19 May 2020 09:21:46 -0700 > Kevin Fenzi wrote: > > > On Tue, May 19, 2020 at 11:48:04AM -0400, Stephen John Smoogen > > wrote: > > > On Tue, 19 May 2020 at 11:05, Paul Howarth > > > wrote: > > > > On Tue, 19 May 2020 09:07:30 -0400 > > > > Stephen John Smoogen wrote: > > > > > > > > > On Tue, 19 May 2020 at 06:05, Paul Howarth > > > > > wrote: > > > > > > > > Yes, I'm using vanilla configs straight from mock-core-configs > > > > for this, and that has epel-8-x86_64.cfg, which pulls in > > > > centos-8.tpl, which has the PowerTools repo defined and not > > > > disabled. > > > > > > > > (I generally use my own configs and don't touch the original > > > > ones, so I know that if I try the original ones from upstream > > > > then they should work as intended) > > > > > > > > Note that the error message doesn't say it can't find > > > > Judy-devel, it says that it (and Judy) is/are excluded. I don't > > > > know why that is. > > > > > > > > > > > Ohhh sorry. I missed the obvious. I am going to guess from past > > > problems, the system is trying to pull in mariadb which filters it > > > out and mariadb-devel which has it in. So when it sees the filters > > > it says 'nope can't do this sorry'. I wish there was a 'no I know > > > it might break my system do it anyway!' flag but I don't see one > > > looking through /usr/share/doc/mock/site-defaults.cfg . This was > > > one of the reasons for grobisplitter being used. > > > > You should be able to set: > > > > module_hotfixes = True > > > > in your dnf/yum/mock config. > > > > From the dnf man page: > > > > "Set this to True to disable module RPM filtering and make all RPMs > > from the repository available. The default is False. This allows > > user to create a repository with cherry-picked hotfixes that are > > included in a package set on a modular system." > > Ah, setting that option for the PowerTools repo allows the build to > work. Now if only there was a way to do that from the command line so > I didn't have to touch the mock config. And now in CentOS 8.2 Judy-devel is missing from the PowerTools repo and so it doesn't work again. Ho hum. 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
Re: use of 'date' in rpm .spec %define concats add'l str chars?
On Fri, 3 Jul 2020 11:09:47 -0700
PGNet Dev wrote:
> on F32,
>
> date +FORMAT,
> date +%Y%m%d_%H%M%S
>
> returns
> 20200703_105351
>
>
>
> as expected.
>
> in an rpm .spec, if I define
>
> %define _build_timestamp %( date +%Y%m%d_%H%M%S )
>
> and _use_ %{_build_timestamp) _anywhere_ else in the spec, at exec of
> any of rpmbuild/mock build/@COPR etc, it appears as
>
> '20200703_105351OURCE'
>
> ?
>
> Simply changing the define to
>
> %define _build_timestamp %( date +%Y%m%d_%H%M%S | head -c 15 )
>
> 'fixes' the problem, and use of %{_build_timestamp) correctly returns
>
> '20200703_105351'
>
>
>
> Is this a bug in rpmbuild or date? Or a problem in my usage?
Remember that '%' introduces a macro expansion, so if that's not what
you want, you should escape the '%' as '%%':
%define _build_timestamp %( date +%%Y%%m%%d_%%H%%M%%S )
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
[EPEL-devel] Re: Modules again
On Wed, 20 May 2020 08:10:42 +0200 Petr Pisar wrote: > On Tue, May 19, 2020 at 04:05:02PM +0100, Paul Howarth wrote: > > On Tue, 19 May 2020 09:07:30 -0400 > > Stephen John Smoogen wrote: > > > > > On Tue, 19 May 2020 at 06:05, Paul Howarth > > > wrote: > > > > On Mon, 18 May 2020 22:29:54 -0600 > > > > Orion Poplawski wrote: > > > > > > > > > On 5/17/20 6:34 AM, Paul Howarth wrote: > > > > > > I'm trying to do a local build of gtkwave for EPEL-8. > > > > > > > > > > > > A koji scratch build somehow works: > > > > > > http://koji.fedoraproject.org/koji/taskinfo?taskID=44609837 > > > > > > > > > > > > But a local build does not: > > > > > > > > > > > > $ mock -r epel-8-x86_64 gtkwave-3.3.104-2.fc31.src.rpm > > > > > > ... > > > > > > Error: > > > > > > Problem: conflicting requests > > > > > >- package > > > > > > Judy-devel-1.0.5-18.module_el8.1.0+217+4d875839.i686 is > > > > > > excluded > > > > > >- package > > > > > > Judy-devel-1.0.5-18.module_el8.1.0+217+4d875839.x86_64 is > > > > > > excluded > > > > > > > > > > > > Adding a repo with a local build of Judy doesn't help; that > > > > > > gets excluded too. > > > > > > > > > > > > Any clues? > > > > > > > > > > > > Paul. > > > > > > > > > > Judy-devel appears to be part of the mariadb-devel module. > > > > > Locally I can do: > > > > > > > > > > dnf module enable mariadb-devel > > > > > dnf install Judy-devel > > > > > > > > > > This was discovered with: > > > > > > > > > > dnf module provides Judy-devel > > > > > > > > > > on RHEL 8.2, though that does not appear to work on CentOS > > > > > 8.1. > > > > > > > > > > For mock, this seems to work: > > > > > > > > > > mock -r epel-8-x86_64 --config-opts > > > > > module_enable=mariadb-devel --config-opts module_enable= > > > > > gtkwave-3.3.104-2.el8.src.rpm > > > > > > > > I tried that and it didn't make any difference for me (building > > > > on F-31). Maybe I need to wait for CentOS 8.2? > > > > > > > > > > > Hmm do you have the Powertools enabled in that Mock? I see > > > Judy-devel in the CentOS-8.1 tree in Powertools. > > > > Yes, I'm using vanilla configs straight from mock-core-configs for > > this, and that has epel-8-x86_64.cfg, which pulls in centos-8.tpl, > > which has the PowerTools repo defined and not disabled. > > > > (I generally use my own configs and don't touch the original ones, > > so I know that if I try the original ones from upstream then they > > should work as intended) > > > > Note that the error message doesn't say it can't find Judy-devel, it > > says that it (and Judy) is/are excluded. I don't know why that is. > > > The message means that the Judy-devel package exists in a repository, > but is not available for an installation, because a module it belongs > to is not active (i.e. not enabled nor default). The correct > procedure is enable the module it belongs to. > > "dnf module provides Judy-devel" command returns mariadb-devel:10.3 > module. After enabling that module you get another error message that > Judy package is excluded. That's because Judy package belongs to > mariadb:10.3 module. You also need to enable that module. Then it > works. It also works in mock: > > $ mock -r epel-8-x86_64 --config-opts module_enable=mariadb-devel > --config-opts module_enable=mariadb install Judy-devel [...] > INFO: installing package(s): Judy-devel > No matches found for the following disable plugin patterns: local, > spacewalk CentOS-8 - Base >539 kB/s | 2.2 MB > 00:04 CentOS-8 - AppStream >1.3 MB/s | 7.0 MB > 00:05 CentOS-8 - PowerTools >442 kB/s | 2.0 MB > 00:04 CentOS-8 - Extras >5.7 kB/s | 5.9 kB > 00:01 epel >5.2 kB/s | 4.7 kB > 00:00 Dependencies resolved. >
Re: i3wm for EPEL8
On Tue, 19 May 2020 10:47:57 -0400 Eric Mesa wrote: > I noticed that the i3 window manager wasn't available in EPEL8. Before > trying to go through the process of becoming a package maintainer I > decided to try and run it via copr to see how much modification was > needed. For EPEL8 (as opposed to 7) I was able to take the current > spec file and, after creating an EPEL8 copr repo for xcb-util-xrm ( > https://copr.fedorainfracloud.org/coprs/djotaku/xcb-util-xrm/), it > would build. But it wouldn't install for it needed some perl > packages. So I set about building those. You can see how far I got in > ( https://copr.fedorainfracloud.org/coprs/djotaku/i3wm/packages/), > but each one had one or more dependencies. So I was rapidly along a > path towards having to recreate nearly all of Perl for EPEL8. (Only a > slight exaggeration). Unfortunately, for those, I couldn't just bum > the spec file because they each had a patch that needed to be > applied. So I had to download the repo from pagure, use spectool and > mock to create the srpm and then load that into copr. Quite tedious. Interesting what you say about the perl modules because perl-common-sense, perl-JSON-XS and perl-Types-Serialiser are available in the EL-8 Code Ready Builder / PowerTools repo, which is a dependency of EPEL-8: https://fedoraproject.org/wiki/EPEL#How_can_I_use_these_extra_packages.3F Is that repo not enabled in your EPEL-8 configuration? 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
[EPEL-devel] Re: Modules again
On Tue, 19 May 2020 09:21:46 -0700 Kevin Fenzi wrote: > On Tue, May 19, 2020 at 11:48:04AM -0400, Stephen John Smoogen wrote: > > On Tue, 19 May 2020 at 11:05, Paul Howarth > > wrote: > > > On Tue, 19 May 2020 09:07:30 -0400 > > > Stephen John Smoogen wrote: > > > > > > > On Tue, 19 May 2020 at 06:05, Paul Howarth > > > > wrote: > > > > > > Yes, I'm using vanilla configs straight from mock-core-configs for > > > this, and that has epel-8-x86_64.cfg, which pulls in centos-8.tpl, > > > which has the PowerTools repo defined and not disabled. > > > > > > (I generally use my own configs and don't touch the original > > > ones, so I know that if I try the original ones from upstream > > > then they should work as intended) > > > > > > Note that the error message doesn't say it can't find Judy-devel, > > > it says that it (and Judy) is/are excluded. I don't know why that > > > is. > > > > > > > > Ohhh sorry. I missed the obvious. I am going to guess from past > > problems, the system is trying to pull in mariadb which filters it > > out and mariadb-devel which has it in. So when it sees the filters > > it says 'nope can't do this sorry'. I wish there was a 'no I know > > it might break my system do it anyway!' flag but I don't see one > > looking through /usr/share/doc/mock/site-defaults.cfg . This was > > one of the reasons for grobisplitter being used. > > You should be able to set: > > module_hotfixes = True > > in your dnf/yum/mock config. > > From the dnf man page: > > "Set this to True to disable module RPM filtering and make all RPMs > from the repository available. The default is False. This allows > user to create a repository with cherry-picked hotfixes that are > included in a package set on a modular system." Ah, setting that option for the PowerTools repo allows the build to work. Now if only there was a way to do that from the command line so I didn't have to touch the mock config. Thanks! 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
[EPEL-devel] Re: Modules again
On Tue, 19 May 2020 09:07:30 -0400 Stephen John Smoogen wrote: > On Tue, 19 May 2020 at 06:05, Paul Howarth wrote: > > > On Mon, 18 May 2020 22:29:54 -0600 > > Orion Poplawski wrote: > > > > > On 5/17/20 6:34 AM, Paul Howarth wrote: > > > > I'm trying to do a local build of gtkwave for EPEL-8. > > > > > > > > A koji scratch build somehow works: > > > > http://koji.fedoraproject.org/koji/taskinfo?taskID=44609837 > > > > > > > > But a local build does not: > > > > > > > > $ mock -r epel-8-x86_64 gtkwave-3.3.104-2.fc31.src.rpm > > > > ... > > > > Error: > > > > Problem: conflicting requests > > > >- package > > > > Judy-devel-1.0.5-18.module_el8.1.0+217+4d875839.i686 is excluded > > > >- package > > > > Judy-devel-1.0.5-18.module_el8.1.0+217+4d875839.x86_64 is > > > > excluded > > > > > > > > Adding a repo with a local build of Judy doesn't help; that gets > > > > excluded too. > > > > > > > > Any clues? > > > > > > > > Paul. > > > > > > Judy-devel appears to be part of the mariadb-devel module. > > > Locally I can do: > > > > > > dnf module enable mariadb-devel > > > dnf install Judy-devel > > > > > > This was discovered with: > > > > > > dnf module provides Judy-devel > > > > > > on RHEL 8.2, though that does not appear to work on CentOS 8.1. > > > > > > For mock, this seems to work: > > > > > > mock -r epel-8-x86_64 --config-opts module_enable=mariadb-devel > > > --config-opts module_enable= gtkwave-3.3.104-2.el8.src.rpm > > > > I tried that and it didn't make any difference for me (building on > > F-31). Maybe I need to wait for CentOS 8.2? > > > > > Hmm do you have the Powertools enabled in that Mock? I see Judy-devel > in the CentOS-8.1 tree in Powertools. Yes, I'm using vanilla configs straight from mock-core-configs for this, and that has epel-8-x86_64.cfg, which pulls in centos-8.tpl, which has the PowerTools repo defined and not disabled. (I generally use my own configs and don't touch the original ones, so I know that if I try the original ones from upstream then they should work as intended) Note that the error message doesn't say it can't find Judy-devel, it says that it (and Judy) is/are excluded. I don't know why that is. 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
[EPEL-devel] Re: Modules again
On Mon, 18 May 2020 22:29:54 -0600 Orion Poplawski wrote: > On 5/17/20 6:34 AM, Paul Howarth wrote: > > I'm trying to do a local build of gtkwave for EPEL-8. > > > > A koji scratch build somehow works: > > http://koji.fedoraproject.org/koji/taskinfo?taskID=44609837 > > > > But a local build does not: > > > > $ mock -r epel-8-x86_64 gtkwave-3.3.104-2.fc31.src.rpm > > ... > > Error: > > Problem: conflicting requests > >- package Judy-devel-1.0.5-18.module_el8.1.0+217+4d875839.i686 is > > excluded > >- package Judy-devel-1.0.5-18.module_el8.1.0+217+4d875839.x86_64 > > is excluded > > > > Adding a repo with a local build of Judy doesn't help; that gets > > excluded too. > > > > Any clues? > > > > Paul. > > Judy-devel appears to be part of the mariadb-devel module. Locally I > can do: > > dnf module enable mariadb-devel > dnf install Judy-devel > > This was discovered with: > > dnf module provides Judy-devel > > on RHEL 8.2, though that does not appear to work on CentOS 8.1. > > For mock, this seems to work: > > mock -r epel-8-x86_64 --config-opts module_enable=mariadb-devel > --config-opts module_enable= gtkwave-3.3.104-2.el8.src.rpm I tried that and it didn't make any difference for me (building on F-31). Maybe I need to wait for CentOS 8.2? > koji does some magic to essentially auto-enable some modules that I > don't believe mock has. It writes its own mock configs, that I know. After that, I'm in the dark... Thanks for trying. 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
[EPEL-devel] Modules again
I'm trying to do a local build of gtkwave for EPEL-8. A koji scratch build somehow works: http://koji.fedoraproject.org/koji/taskinfo?taskID=44609837 But a local build does not: $ mock -r epel-8-x86_64 gtkwave-3.3.104-2.fc31.src.rpm ... Error: Problem: conflicting requests - package Judy-devel-1.0.5-18.module_el8.1.0+217+4d875839.i686 is excluded - package Judy-devel-1.0.5-18.module_el8.1.0+217+4d875839.x86_64 is excluded Adding a repo with a local build of Judy doesn't help; that gets excluded too. Any clues? 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
Re: moreutils newly in PowerTools repo in centos-8
On Sat, 16 May 2020 20:23:35 +0200 clime wrote: > I am co-maintaining an epel-7 package (dist-git) and I wanted to add > it to epel-8 too. But right now, it wouldn't install because one of > the dependencies (moreutils) is newly in PowerTools repo > (https://bugzilla.redhat.com/show_bug.cgi?id=1833810). > > I assume that basically means I cannot depend on such package from an > epel-8 package or at least I will solve it like this by removing the > dependency. Something like this is a bit surprising, however. I didn't > know a repo like that existed. You can safely depend on things in the PowerTools repo as it's expected that EPEL-8 users will also use that repository: https://fedoraproject.org/wiki/EPEL#How_can_I_use_these_extra_packages.3F Looking at the BZ ticket, it seems you discovered that yourself. 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
[EPEL-devel] Re: Handling packages retired in epel but not yet available in CentOS?
On Thu, 14 May 2020 12:31:40 -0700 Michel Alexandre Salim wrote: > We're working on validating CentOS 8 for some desktop use cases at > work, and noticed that after working fine on a machine that's > installed several months ago, it's now failing on a freshly-installed > machine. > > Turns out that we need libzstd, which on the previous machine was > sourced from the EPEL repo, but the epel8 package got retired 3 > months ago because the package is now in RHEL's BaseOS: > > https://src.fedoraproject.org/rpms/zstd/history/dead.package?identifier=epel8 > > The package is only in BaseOS in 8.2 though, and CentOS 8.2 is not > out -- the only repo that has it now is 8-stream: > > https://mirrors.edge.kernel.org/centos/8-stream/BaseOS/x86_64/os/Packages/ > > 8.1.1911 does not have the package: > https://mirrors.edge.kernel.org/centos/8.1.1911/BaseOS/x86_64/os/Packages/ > > Also, the version in BaseOS (if 8-stream is up to date) is 1.4.2, > which is older than the last version in EPEL (1.4.4). > > Is anyone else in the same situation, and how do you work around it? > Since EPEL is a sort of "rolling release" does it make sense to just > track 8-stream if you're using it, or are people resorting to hosting > these key packages in internal repos? That's what I'm doing. I got the sources from CentOS git (https://git.centos.org/rpms/zstd/tree/c8), built it myself and hosted it in a temporary local repo until CentOS 8.2 is out. 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
[rpms/perl-B-Hooks-OP-Check] PR #1: Spec file cleanups: Use_make_build and make_install macros, use NO_PACKLIST=1
pghmcfc merged a pull-request against the project: `perl-B-Hooks-OP-Check` that you are following. Merged pull-request: `` Spec file cleanups: Use_make_build and make_install macros, use NO_PACKLIST=1 `` https://src.fedoraproject.org/rpms/perl-B-Hooks-OP-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
[rpms/perl-B-Hooks-OP-Check] PR #1: Spec file cleanups: Use_make_build and make_install macros, use NO_PACKLIST=1
pghmcfc commented on the pull-request: `Spec file cleanups: Use_make_build and make_install macros, use NO_PACKLIST=1` that you are following: `` Hi Tom, the Perl Tips URL is missing an "r" at the end: ``` <<< https://fedoraproject.org/wiki/Perl/Tips#ExtUtils::MakeMake >>> https://fedoraproject.org/wiki/Perl/Tips#ExtUtils::MakeMaker ``` Could you fix that before submitting your next batch of PRs? `` To reply, visit the link below https://src.fedoraproject.org/rpms/perl-B-Hooks-OP-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
Re: python2-dns without DNSSEC support in rawhide
Hi Lumir, On Wed, 29 Apr 2020 07:35:43 +0200 Lumir Balhar wrote: > Hello. > > I'd like to switch python-dns crypto backend from pycryptodomex and > ecdsa to python-cryptography. Upstream already did the same in master > branch: https://github.com/rthalley/dnspython/pull/449 > > But, because python2-cryptography is not available in Fedora anymore, > this change will disable DNSSEC functionality in python2-dns. There > are only two packages depending on python2-dns: mailman and > trac-spamfilter-plugin. I did a check and rebuild of both of them and > it seems that they both work with the new version and there is no > usage of DNSSEC in their codebases. COPR: > https://copr.fedorainfracloud.org/coprs/lbalhar/dns/ > > PR: https://src.fedoraproject.org/rpms/python-dns/pull-request/5 > > If you think we should not merge the PR, let us know rather sooner > than later. No objections from me (trac-spamfilter-plugin maintainer); it uses python-dns for IP blacklist lookups and I wouldn't be surprised if mailman did the same. On the other hand, maybe the crypto backend could be changed for Python 3 and not for the Python 2 version? I would hope that the Python 2 version wouldn't need to be maintained for too much longer anyway. 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
Re: Creation of a perl-packagers-sig group
On Mon, 20 Apr 2020 00:23:03 +0200 Emmanuel Seyman wrote: > * Emmanuel Seyman [12/03/2020 21:03] : > > > > https://pagure.io/fedora-infrastructure/issue/8743 > > Okay, this was done a few weeks ago (sorry for the lag, the world's > been kind of crazy, these last few weeks). > > Does anybody want to be an admin of the group (I'ld rather not be > alone to do this)? Who wants to be a member of the group? I'll be a member. 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
Re: Unretire gjots2 (gtk heirarchical note jotter)
On Tue, 14 Apr 2020 16:51:04 +0200 Alexander Ploumistos wrote: > On Tue, Apr 14, 2020 at 4:40 PM Petr Pisar wrote: > > > > On Tue, Apr 14, 2020 at 04:27:06PM +0200, Alexander Ploumistos > > wrote: > > > The FSF address should be the most straightforward to fix. > > > > > Straightforward, but impossible for a pacakger. Because it's a part > > of the license declaration, only an author can change it, as the > > license reads: > > > > [...]keep intact all the > > notices that refer to this License [...] > > > > That's the reason why I consider this rpmlint warning quite > > unhelpful. > > Do you mean the author of the software or the license? I've seen that > debated over and over again and my understanding is that packagers are > not supposed to patch the file, but upstream developers (which is the > case here) should correct that error. Our wiki links to a version of > GPL 2 with the correct address: > https://fedoraproject.org/wiki/Common_Rpmlint_issues#incorrect-fsf-address I view the rpmlint warning as a hint to try to get upstream to fix the license text. In the case of unresponsive upstreams, we just have to live with 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
[EPEL-devel] Re: Input Requested: revising policy for stalled EPEL requests
On Fri, 10 Apr 2020 15:17:25 -0700 Troy Dawson wrote: > On Fri, Apr 3, 2020 at 3:21 PM Troy Dawson wrote: > > > > EPEL Issue #101 [1] has pointed out that our current policy for > > stalled EPEL requests is fairly in-efficient and can cause some long > > delays. > > > > What do people think the process should be? > > > > Here is an example: > > * A packager opens a bugzilla requesting a package be added to EPEL. > > They also express that they are willing to help maintain / > > co-maintain that package in EPEL. > > * A period of time goes by with no response > > * They re-say that they are willing to maintain / co-maintain the > > package in EPEL > > * Another period of time goes by with no response > > * They file a rel-eng ticket, that points to the bugzilla, > > requesting appropriate privileges to be able to branch and build > > that package in EPELX > > * That happens. > > * They then request branch, and build the package in EPELX following > > normal ways. > > > > This is just an example, but it's what I picture in my head. > > Troy > > > > [1] - https://pagure.io/epel/issue/101 > > This is the proposed policy. If people could look through it for any > problems, it would be appreciated. > > **Stalled EPEL Requests** > There are times that an EPEL / Fedora package maintainer isn't > responding to an EPEL package request. If a different packager would > like to build and maintain that package in EPEL, these are the steps > they take. > > * A packager opens a bugzilla requesting a package be added to EPEL. > They also express that they are willing to help maintain / co-maintain > that package in EPEL-X. > > * A week goes by with no response > > * They re-say that they are willing to maintain / co-maintain the > package in EPEL > ** This is just incase the initial message was missed. > > * A week goes by with no response > > * They file a rel-eng ticket, that points to the bugzilla, requesting > appropriate privileges to be able to branch and build that package in > EPEL-X > ** Currently that privilege is "admin" > ** This part of the policy will adjust as various features get > implemented in pagure and dist-git > > * The privileges are given > * They then request a branch, and build the package in EPEL-X > following normal steps. I think there's also a good case for the requester to be made the bugzilla contact for EPEL for that package, though it would be complicated if there was an existing EPEL branch, which would presumably have been made (and been maintained) by someone else. 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
Re: Detecting when building under mock?
On Tue, 7 Apr 2020 11:43:26 -0400 (EDT) Scott Talbert wrote: > Is there a recommended way for detecting when a package is being > built under mock? I have a package where some tests fail due to > various things not being present in a mock container, e.g, /dev/log > doesn't exist. I can just disable these tests downstream, but > upstream might take a change if I can wrap them in a "if !mock" > condition. Why not test for the presence of /dev/log before running such tests? 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
[rpms/perl-Socket6] PR #1: Spec file cleanups: Use make_build and make_install macros, use NO_PACKLIST=1
pghmcfc commented on the pull-request: `Spec file cleanups: Use make_build and make_install macros, use NO_PACKLIST=1` that you are following: `` I merged this locally and fixed the typo in the ExtUtils::MakeMaker reference. It's now pushed and built in Fedora. `` To reply, visit the link below https://src.fedoraproject.org/rpms/perl-Socket6/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
[rpms/perl-Socket6] PR #1: Spec file cleanups: Use make_build and make_install macros, use NO_PACKLIST=1
pghmcfc closed without merging a pull-request against the project: `perl-Socket6` that you are following. Closed pull-request: `` Spec file cleanups: Use make_build and make_install macros, use NO_PACKLIST=1 `` https://src.fedoraproject.org/rpms/perl-Socket6/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
[rpms/perl-String-CRC32] PR #1: Spec file cleanups: Use make_build and make_install macros, use NO_PACKLIST=1
pghmcfc closed without merging a pull-request against the project: `perl-String-CRC32` that you are following. Closed pull-request: `` Spec file cleanups: Use make_build and make_install macros, use NO_PACKLIST=1 `` https://src.fedoraproject.org/rpms/perl-String-CRC32/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
[rpms/perl-String-CRC32] PR #1: Spec file cleanups: Use make_build and make_install macros, use NO_PACKLIST=1
pghmcfc commented on the pull-request: `Spec file cleanups: Use make_build and make_install macros, use NO_PACKLIST=1` that you are following: `` I merged this locally and fixed the typo in the ExtUtils::MakeMaker reference. It's now pushed and built in Fedora. `` To reply, visit the link below https://src.fedoraproject.org/rpms/perl-String-CRC32/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
[rpms/perl-Unix-Syslog] PR #1: Spec file cleanups: Use make_build, make_install macros, and use NO_PACKLIST=1
pghmcfc closed without merging a pull-request against the project: `perl-Unix-Syslog` that you are following. Closed pull-request: `` Spec file cleanups: Use make_build, make_install macros, and use NO_PACKLIST=1 `` https://src.fedoraproject.org/rpms/perl-Unix-Syslog/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
[rpms/perl-Unix-Syslog] PR #1: Spec file cleanups: Use make_build, make_install macros, and use NO_PACKLIST=1
pghmcfc commented on the pull-request: `Spec file cleanups: Use make_build, make_install macros, and use NO_PACKLIST=1` that you are following: `` I merged this locally and fixed the typo in the ExtUtils::MakeMaker reference. It's now pushed and built in Fedora. `` To reply, visit the link below https://src.fedoraproject.org/rpms/perl-Unix-Syslog/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
