Hi, Could you please branch and build perl-Type-Tiny for EPEL 9 ? Regards, Xavier
Will you be able to branch and build perl-Type-Tiny in epel9? I would be happy to be a co-maintainer if you do not wish to build it on epel9.
What do you expect me to do? You know, I do not use RHEL nor do I support RHEL, because I consider EPEL to be harmful to Fedora. Please provide me with precise and detailed instructions, what you expect me to do. Fedora's "wanna-be docs" doesn't carry this information.
Thanks for the response Ralf. I'm just following the process at the moment: https://docs.fedoraproject.org/en-US/epel/epel-package-request/#fedora_packagers Normally I'd expect you to ignore the EPEL request or, as you have done here, state that you don't support EPEL, which would then lead us to https://docs.fedoraproject.org/en-US/epel/epel-policy/#stalled_epel_requests in which a releng ticket could be raised and an epel packager (who raised the releng ticket) would: (a) be assigned commit access to the package, which would enable them to request the epel branch (this used to be able to be done by a provenpackager, but not any more), and (b) the EPEL bugzilla contact would be assigned to that person so you'd never be bothered with EPEL requests for that package again. I think that the EPEL bugzilla contact assignment is worth going through the additional steps for, rather than just assigning somebody commit access yourself, which would leave you as the EPEL bugzilla contact. There is a process for doing that separately as well but that would be more hassle for you. So, in summary, I'd suggest that for the EPEL package requests you've received, the best thing for you to do would be to note in the ticket that you don't do EPEL and add a link to https://docs.fedoraproject.org/en-US/epel/epel-policy/#stalled_epel_requests such that the reporter can go through the rest of the process themselves (assuming that they are packagers themselves, which is almost always the case at the moment).
I've add ppisar as "collaborator" for epel* and made him primary bugzilla contact through this nonhelpful GUI on https://src.fedoraproject.org/rpms/perl-Types-Path-Tiny
Apparently this freaking GUI doesn't set/reset the default-assignee in bugzilla :(
Also depends on the following packages which don't have a bug filed yet: perl-Class-ISA perl-Devel-Hide perl-Devel-Refcount perl-Function-Parameters perl-MooseX-Getopt perl-MooseX-Types perl-MooseX-Types-Common perl-MouseX-Types perl-Return-Type perl-Sub-Exporter-Lexical perl-Type-Tie perl-Validation-Class There is a circular dependency on perl-Types-Path-Tiny (RHBZ#2033633) and several others.
(In reply to Xavier Bachelot from comment #6) > There is a circular dependency on perl-Types-Path-Tiny (RHBZ#2033633) and > several others. You probably need to apply the %{perl_bootstrap} magic. I.e. 1st build with %{perl_bootstrap} enabled, then a 2nd time with %{perl_bootstrap} disabled.
(In reply to Xavier Bachelot from comment #6) > Also depends on the following packages which don't have a bug filed yet: > perl-Class-ISA > perl-Devel-Hide > perl-Devel-Refcount > perl-Function-Parameters > perl-MooseX-Getopt > perl-MooseX-Types > perl-MooseX-Types-Common > perl-MouseX-Types > perl-Return-Type > perl-Sub-Exporter-Lexical > perl-Type-Tie > perl-Validation-Class > > There is a circular dependency on perl-Types-Path-Tiny (RHBZ#2033633) and > several others. I've a plan and build order for everything needed to get to perl-Type-Tiny including the bootstrapping. I've done them all locally but didn't want to get too far ahead in the dependency chain with the tickets yet. Moose and Mouse need to be done first too.
I don't see where the dependency on Devel::Refcount comes from. Test::Refcount used to use it, but not since version 0.07.
(In reply to Paul Howarth from comment #9) > I don't see where the dependency on Devel::Refcount comes from. The testsuite uses it: Type-Tiny-1.012004/Makefile.PL: Devel::Refcount Type-Tiny-1.012004/t/20-unit/Type-Registry/refcount.t:use Test::Requires 'Devel::Refcount'; Type-Tiny-1.012004/t/20-unit/Type-Registry/refcount.t:use Devel::Refcount 'refcount'; Type-Tiny-1.012004/t/20-unit/Type-Tiny/refcount.t:use Test::Requires 'Devel::Refcount'; Type-Tiny-1.012004/t/20-unit/Type-Tiny/refcount.t:use Devel::Refcount 'refcount'; If you remove BR: perl(Devel::Refcount) from the *.spec, the testsuite complains about it: t/20-unit/Type-Tiny/refcount.t ............................ skipped: Test requires module 'Devel::Refcount' but it's not found
Ah, I see. I remember going through the optional test modules a while back to see which ones were available in Fedora but that must have been when Test::Refcount still pulled in Devel::Refcount so I didn't notice it.
https://pagure.io/releng/fedora-scm-requests/issue/41051 Note that this request will result in an initial bootstrap build; it will still be some time before a "real" build is ready to be issued as an update. Critical path is: libtomcrypt (Bug 2029477) -> perl-CryptX (Bug 2029477) -> perl-Crypt-CBC (Bug 2037669) -> perl-Crypt-Blowfish (Bug 2037672) -> perl-Data-Serializer -> perl-Log-Trace -> perl-Test-Assertions -> perl-Hash-Flatten -> perl-Validation-Class -> perl-Type-Tiny
(In reply to Paul Howarth from comment #12) > https://pagure.io/releng/fedora-scm-requests/issue/41051 > > Note that this request will result in an initial bootstrap build; it will > still be some time before a "real" build is ready to be issued as an update. I've changed my mind about this. The bootstrap build is done and added as a buildroot override. However, I'm still going to issue an update with it so as to make it easier for everyone to get on with their own packages. Having a build in the stable epel9 repo will help with people's local testing. The final post-bootstrap build of perl-Type-Tiny won't have any different contents than the bootstrap build, just more tests having been run during the build. My local testing indicates that the additional tests will all pass.
FEDORA-EPEL-2022-7b3a04be87 has been submitted as an update to Fedora EPEL 9. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-7b3a04be87
FEDORA-EPEL-2022-7b3a04be87 has been pushed to the Fedora EPEL 9 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-7b3a04be87 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-EPEL-2022-7b3a04be87 has been pushed to the Fedora EPEL 9 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-EPEL-2022-844601896b has been submitted as an update to Fedora EPEL 9. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-844601896b
FEDORA-EPEL-2022-844601896b has been pushed to the Fedora EPEL 9 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-844601896b See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-EPEL-2022-844601896b has been pushed to the Fedora EPEL 9 stable repository. If problem still persists, please make note of it in this bug report.