[Bug 1744861] New: ack-3.1.0 is available
by bugzilla＠redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=1744861
Bug ID: 1744861
Summary: ack-3.1.0 is available
Product: Fedora
Version: rawhide
Status: NEW
Component: ack
Keywords: FutureFeature, Triaged
Assignee: robinlee.sysu(a)gmail.com
Reporter: upstream-release-monitoring(a)fedoraproject.org
QA Contact: extras-qa(a)fedoraproject.org
CC: perl-devel(a)lists.fedoraproject.org,
robinlee.sysu(a)gmail.com
Target Milestone: ---
Classification: Fedora
Latest upstream release: 3.1.0
Current version/release in rawhide: 3.0.3-1.fc32
URL: http://search.cpan.org/dist/ack/
Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy
More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring
Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.
Based on the information from anitya:
https://release-monitoring.org/project/15/
--
You are receiving this mail because:
You are on the CC list for the bug.
4 years, 9 months
Perl modules in EPEL 8
by Petr Pisar
As promised in <https://bugzilla.redhat.com/show_bug.cgi?id=1744676> and on
#fedora-perl FreeNode channel, here are some information about packaging Perl
code in for EPEL 8.
EPEL 8.0 release was announced
<https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproj...>.
We can start packaging Perl packages that do not exist in any RHEL repository.
RHEL 8 has three repositories: BaseOS, AppStream, CodeReady Builder. While the
first two are usually enabled, the third one is not enabled by default. So
don't forget to search all of them before requesting an epel8 branch.
RHEL 8 introduced modules. This is the user-facing part of Modularity you can
know from Fedora <https://docs.fedoraproject.org/en-US/modularity/>. In
RHEL-8.0, there is one perl module with two streams:
perl:5.26 [d]
perl:5.24
perl:5.26 is default and that means that by default the Perl visible to YUM
is Perl 5.26.
There are few other Modularity modules that provide RPM packages that
package some Perl modules from CPAN. This is the complete list:
perl-App-cpanminus:1.7044 [d]
perl-DBD-MySQL:4.046 [d]
perl-DBD-Pg:3.7 [d]
perl-DBD-SQLite:1.58 [d]
perl-DBI:1.641 [d]
perl-FCGI:0.78 [d]
perl-YAML:1.24 [d]
Each of those modules have only one stream (i.e. one version of the software).
Modularity allows you to select a different stream and that makes available a different
set of packages. See
<https://developers.redhat.com/blog/2019/05/16/modular-perl-in-red-hat-ent...>
for a tutorial how to work with streams in YUM.
But there are plenty of other Perl packages in RHEL 8. These packages have not
been modularized and thus they exist out of the modules and thus they are
built and compatible only with the default perl stream, perl:5.26. Example is
perl-libwww-perl.
When it comes to adding packages or modules into EPEL, the situation is like
this:
If you add a normal non-modular package into EPEL, it will be built for Perl
5.26. Koji knows what streams are default and packages of those streams are
added into Koji build root. Therefore Koji knows only perl-5.26.3 package,
installs it when build-requiring perl-interpreter and your resulting packages
will run-require perl(:MODULE_COMPAT_5.26.3). If you are fine with it just go
and get packaging.
If you want to add a new package into EPEL and build it as a module in order
to support all Perls, you are out of luck. For now. EPEL 8 does not yet
support building Modularity modules. The announcement promised this will be
fixed around RHEL-8.1 release. Theoretical procedure is following: You will
request creating a new repository in "modules" name space, you will request
creating a new branch in that repository, you will import a modulemd file
(something like a spec file, but this is for modules) into the the branch. If
your modulemd refers to a new package, you will request creating
a repository for the new package in "rpms" namespace. If you need
a special branch for the package sources, you will request for the new branch.
Then make sure your modulemd file build- and run-require "perl:[]" (the empty
list in the brackets denotes all available streams of perl module). Then build
the module using "fedpkg module-build". As a result, you will have two module
builds (one for 5.24 and one for 5.26). Then you pass the builds to Bodhi to
get them into EPEL repozitory. If you want to have the module content
available by default (i.e. without a user enabling a specific stream of your
module), you need to file a pull-request to a special rel-eng repository at
pagure.io (<https://pagure.io/releng/fedora-module-defaults> for Fedora) to
make the stream default.
If you want to add a new stream of an existing module into EPEL, the procedure
is the same, except you will probably won't be allowed to make the new stream
default.
If you want to make an existing non-modular RHEL package compatible for other
Perls, you basically need to add a new module that will contain the package
whose sources you copy from CentOS and then you build the module. The issue is
that you will also get a build for Perl 5.26. This does not matter until you
try to make your stream a default one. That would shadow the RHEL package for
everybody and that probably won't be allowed.
(If you noticed I wrote "probably", it's because I'm not sure about how the
rules for "not replacing RHEL content" will look like in case of modules.
I raised some question on EPEL list
<https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproj...>.)
Maybe you don't need to make the stream default. However, that has the drawback
that people won't be able to do "yum install perl-Foo". They will have to do
"yum module enable perl-Foo:bar" first.
An obvious fix would be to disable building for Perl 5.26 by changing the
modular dependency to "perl:[-5.26]". But if you do that YUM will complain
that your module is incompatible with perl:5.26 (becuase it's default). All
people will see that terrible warning until DNF changes behavior
<https://bugzilla.redhat.com/show_bug.cgi?id=1717117>.
Disabling building for a stream would also hinder all other modules built on top
of your module. They would also be automatically stripped from the Perl 5.26
support. Imaging you want to package a completely new module to be of course
available for the default Perl, but you cannot because some intermediary
dependency is not available for that perl stream. This itself could be worked
around by specifing a tree of modular dependendices
<https://github.com/fedora-modularity/libmodulemd/blob/master/spec.v2.yaml...>
where one subtree would be with perl:5.26 but without the offending module.
But in my opinion that would become non-maintainable at large scale (at depth
of a dependency tree).
However, I believe there is a solution. It's a some sort of a hack that
Red Hat already used when creating perl:5.26 stream. If you explored that
stream thoroughly, you could notice the stream is empty. All it's packages are
non-modular. This is technically in line with Modularity specification. We can
use something similar. But this time not on the stream level, but on a context
level. (Context is a word from modularity and it denotes a module stream built
on a specific set of modules. E.g. perl-DBI:1.641 stream is only one, yet it
exists in two contexts. One is built for perl:5.24, another one for perl:5.26.
YUM automatically chooses the right context, so it's usually not presented to
the users. An exceptition is "yum module info perl-DBI" command.)
My vision for modularizing packages that exist as non-modular in RHEL:
Create a new module a stream. Let the modulemd depend on all perl stream,
including 5.26. Copy the package sources from CentOS, but modify the spec file
in a way that if the package is being built with Perl 5.26, do not produce any
binary package. Otherwise behave as usual. This will built your module for all
Perls, but the 5.26 context will have no packages. Then put the module stream
into YUM repozitory and make it default. If a user uses the default perl:5.26,
installing the package will take it from RHEL. If a user has enabled
perl:5.24, YUM will take the package from EPEL. That's because modular
packages are preferred over non-modular packages.
This only issue is that rpmbuild cannot build a package that produces no
binary packages. A bandage fix is produce a dummy specially named binary
package in case of Perl 5.26 and let modulemd to filter out the binary
package. modulemd can exclude built binary packages from the resulting module
build. And if the resulting binary package does not exist (in case of perl:5.24),
it does not cause any error.
Here is a pseudo code:
perl-Foo.spec:
Name: Foo
%package -n dummy
%if 0%(perl -e 'print $^V =~ m/^v5\.26\./')
%file -n dummy
%else
%file
%{perl_vendorlib}/...
%endif
perl-Foo.yaml:
data:
filter:
rpms:
- dummy
components:
rpms:
- perl-Foo
I'm sorry for the lengthy and boring e-mail. Once EPEL enables building
modules, I'll test my ideas and write here whether it's doable.
-- Petr
4 years, 9 months
[Bug 1741078] New: Upgrade perl-BSON to 1.12.1
by bugzilla＠redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=1741078
Bug ID: 1741078
Summary: Upgrade perl-BSON to 1.12.1
Product: Fedora
Version: rawhide
Status: NEW
Component: perl-BSON
Assignee: ppisar(a)redhat.com
Reporter: jplesnik(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: perl-devel(a)lists.fedoraproject.org, ppisar(a)redhat.com
Target Milestone: ---
Classification: Fedora
Latest Fedora delivers 1.12.0 version. Upstream released 1.12.1. When you have
free time, please upgrade it.
--
You are receiving this mail because:
You are on the CC list for the bug.
4 years, 9 months
[Bug 1385002] Upgrade perl-Pod-PseudoPod-LaTeX to 1.20190729
by bugzilla＠redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=1385002
Fedora Update System <updates(a)fedoraproject.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ON_QA |CLOSED
Fixed In Version| |perl-Pod-PseudoPod-LaTeX-1.
| |20190729-1.fc30
Resolution|--- |ERRATA
Last Closed| |2019-08-24 01:03:09
--- Comment #6 from Fedora Update System <updates(a)fedoraproject.org> ---
perl-Pod-PseudoPod-LaTeX-1.20190729-1.fc30 has been pushed to the Fedora 30
stable repository. If problems still persist, please make note of it in this
bug report.
--
You are receiving this mail because:
You are on the CC list for the bug.
4 years, 9 months
[Bug 1744686] New: [RFE] EPEL8 branch of perl-Role-Tiny
by bugzilla＠redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=1744686
Bug ID: 1744686
Summary: [RFE] EPEL8 branch of perl-Role-Tiny
Product: Fedora EPEL
Version: epel8
Hardware: All
OS: Linux
Status: NEW
Component: perl-Role-Tiny
Assignee: paul(a)city-fan.org
Reporter: riehecky(a)fnal.gov
QA Contact: extras-qa(a)fedoraproject.org
CC: ddick(a)cpan.org, emmanuel(a)seyman.fr, iarnell(a)gmail.com,
paul(a)city-fan.org, perl-devel(a)lists.fedoraproject.org
Target Milestone: ---
Classification: Fedora
Description of problem:
It would be helpful if this module was packaged for EPEL8
Version-Release number of selected component (if applicable):
How reproducible:
Steps to Reproduce:
1.
2.
3.
Actual results:
Expected results:
Additional info:
There are two AppStream modules for perl in RHEL8 right now. I'm not sure what
the EPEL plan is for multi-perl....
--
You are receiving this mail because:
You are on the CC list for the bug.
4 years, 9 months
[Bug 1744566] New: perl-YAML-LibYAML-0.80 is available
by bugzilla＠redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=1744566
Bug ID: 1744566
Summary: perl-YAML-LibYAML-0.80 is available
Product: Fedora
Version: rawhide
Status: NEW
Component: perl-YAML-LibYAML
Keywords: FutureFeature, Triaged
Assignee: jplesnik(a)redhat.com
Reporter: upstream-release-monitoring(a)fedoraproject.org
QA Contact: extras-qa(a)fedoraproject.org
CC: jplesnik(a)redhat.com, mmaslano(a)redhat.com,
paul(a)city-fan.org, perl-devel(a)lists.fedoraproject.org,
tremble(a)tremble.org.uk
Target Milestone: ---
Classification: Fedora
Latest upstream release: 0.80
Current version/release in rawhide: 0.79-2.fc31
URL: http://search.cpan.org/dist/YAML-LibYAML/
Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy
More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring
Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.
Based on the information from anitya:
https://release-monitoring.org/project/3548/
--
You are receiving this mail because:
You are on the CC list for the bug.
4 years, 9 months
[Bug 1740547] New: Upgrade perl-Locale-SubCountry to 2.06
by bugzilla＠redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=1740547
Bug ID: 1740547
Summary: Upgrade perl-Locale-SubCountry to 2.06
Product: Fedora
Version: rawhide
Status: NEW
Component: perl-Locale-SubCountry
Assignee: ppisar(a)redhat.com
Reporter: jplesnik(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: jplesnik(a)redhat.com,
perl-devel(a)lists.fedoraproject.org, ppisar(a)redhat.com
Target Milestone: ---
Classification: Fedora
Latest Fedora delivers 2.05 version. Upstream released 2.06. When you have free
time, please upgrade it.
--
You are receiving this mail because:
You are on the CC list for the bug.
4 years, 9 months