[389-devel] 389 DS nightly 2019-08-24 - 96% PASS

[vashirov]

https://fedorapeople.org/groups/389ds/ci/nightly/2019/08/24/report-389-ds-base-1.4.1.6-20190823gitaf4631f.fc30.x86_64.html
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org

Request to add new groups to comps.xml

[Danny Lee]

Hello devel,

The NeuroFedora SIG is working to create a Comp-Neuro Fedora Labs 
 live image/installer.  We would also 
like group our packages into an easier-to-install format for our target 
audience, which may include researchers who are new to Fedora.


To this end we would like to respectfully request the addition of two 
new groups in Comps.XML 
. 



The first group would be "neuro-simulators" which would include several 
simulation packages as mandatory installs and a dozen or so python 
packages as default installs.


The second group would be "comp-neuro-tools" and would include many of 
the packages found on the Neuro-SIG group's page on src.fp.o 
 as well as the software 
being packaged on the NeuroFedora pagure 
.


More information on the Comp-Neuro Lab image and NeuroFedora in general:

 *

   comps group discussion:https://pagure.io/neuro-sig/NeuroFedora/issue/198

 *

   NeuroFedora team:https://pagure.io/group/neuro-sig

 *

   NeuroFedora documentation:https://neuro.fedoraproject.org
   

 *

   NeuroFedora blog:https://neuroblog.fedoraproject.org
   

 *

   NeuroFedora packages:https://src.fedoraproject.org/group/neuro-sig

 *

   The logo/stickers etc for NeuroFedora were created by the Fedora
   design team and reside
   here:https://pagure.io/neuro-sig/NeuroFedora/blob/master/f/Artwork

 *

   We've already presented NeuroFedora to the neuroscience community at
   this year's annual conference,
   CNS*2019:https://www.cnsorg.org/cns-2019-quick. Our poster is
   
here:https://pagure.io/neuro-sig/2019-NeuroFedora-poster-CNS/blob/master/f/2019-CNS-NeuroFedora.pdf

--
Danny Lee  I have been impressed with the urgency of 
doing. Knowing is not enough; we must apply. Being willing is not 
enough; we must do. ~ Leonardo da Vinci


___
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

[Bug 1741078] Upgrade perl-BSON to 1.12.1

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-BSON-1.12.1-1.fc31 |perl-BSON-1.12.1-1.fc31
   |perl-BSON-1.12.1-1.fc30 |perl-BSON-1.12.1-1.fc30
   ||perl-BSON-1.12.1-1.fc29



--- Comment #7 from Fedora Update System  ---
perl-BSON-1.12.1-1.fc29 has been pushed to the Fedora 29 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.
___
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

[Bug 1744710] [RFE] EPEL8 branch of perl-HTTP-Headers-Fast

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #5 from Fedora Update System  ---
perl-HTTP-Headers-Fast-0.22-3.el8 has been pushed to the Fedora EPEL 8 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-07cb841e5f

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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

[Bug 1744681] [RFE] EPEL8 branch of perl-Net-IP

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #2 from Fedora Update System  ---
perl-Net-IP-1.26-20.el8 has been pushed to the Fedora EPEL 8 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-e5ad6f9682

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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] Fedora EPEL 8 updates-testing report

[updates]

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

clamav-0.101.4-1.el8
libunwind-1.3.1-3.el8
perl-CPAN-Changes-0.42-13.el8
perl-Expect-1.35-10.el8
perl-HTTP-Headers-Fast-0.22-3.el8
perl-Mixin-Linewise-0.108-15.el8
perl-Net-IP-1.26-20.el8
python-ecdsa-0.13.2-3.el8

Details about builds:



 clamav-0.101.4-1.el8 (FEDORA-EPEL-2019-fabd190d13)
 End-user tools for the Clam Antivirus scanner

Update Information:

ClamAV 0.101.4 is a security patch release that addresses the following issues.
-An out of bounds write was possible within ClamAV's NSIS bzip2 library when
attempting decompression in cases where the number of selectors exceeded the max
limit set by the library (CVE-2019-12900). The issue has been resolved by
respecting that limit.  Thanks to Martin Simmons for reporting the issue
here.  - The zip bomb vulnerability mitigated in 0.101.3 has been assigned
the CVE identifier CVE-2019-12625. Unfortunately, a workaround for the zip-bomb
mitigation was immediately identified. To remediate the zip-bomb scan time
issue, a scan time limit has been introduced in 0.101.4. This limit now resolves
ClamAV's vulnerability to CVE-2019-12625.  The default scan time limit is 2
minutes (12 milliseconds).  To customize the time limit: - use the
clamscan  --max-scantime option - use the clamd  MaxScanTime config option
Libclamav users may customize the time limit using the cl_engine_set_num
function. For example:  C cl_engine_set_num(engine,
CL_ENGINE_MAX_SCANTIME, time_limit_milliseconds)  Thanks to David Fifield
for reviewing the zip-bomb mitigation in 0.101.3 and reporting the issue.




 libunwind-1.3.1-3.el8 (FEDORA-EPEL-2019-c25ebc1512)
 An unwinding library

Update Information:

Libunwind provides a C ABI to determine the call-chain of a program.

References:

  [ 1 ] Bug #1743588 - Please build for epel8
https://bugzilla.redhat.com/show_bug.cgi?id=1743588




 perl-CPAN-Changes-0.42-13.el8 (FEDORA-EPEL-2019-0a41d88896)
 Read and write Changes files

Update Information:

This is the first EPEL-8 package of perl-CPAN-Changes.




 perl-Expect-1.35-10.el8 (FEDORA-EPEL-2019-6fc04a83e8)
 Expect for Perl

Update Information:

This is the first EPEL-8 build of perl-Expect.

References:

  [ 1 ] Bug #1744512 - Request to build perl-Expect for EPEL 8
https://bugzilla.redhat.com/show_bug.cgi?id=1744512




 perl-HTTP-Headers-Fast-0.22-3.el8 (FEDORA-EPEL-2019-07cb841e5f)
 Faster implementation of HTTP::Headers

Update Information:

HTTP::Headers::Fast is a perl class for parsing/writing HTTP headers.

References:

  [ 1 ] Bug #1744710 - [RFE] EPEL8 branch of perl-HTTP-Headers-Fast
https://bugzilla.redhat.com/show_bug.cgi?id=1744710




 perl-Mixin-Linewise-0.108-15.el8 (FEDORA-EPEL-2019-62e6d002f2)
 Write your linewise code for handles; this does the rest

Update Information:

First EPEL-8 build of perl-Mixin-Linewise.




 perl-Net-IP-1.26-20.el8 (FEDORA-EPEL-2019-e5ad6f9682)
 Perl module for manipulation of IPv4 and IPv6 addresses

Update Information:

This is the first EPEL-8 build of 

[Bug 1744512] Request to build perl-Expect for EPEL 8

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #2 from Fedora Update System  ---
perl-Expect-1.35-10.el8 has been pushed to the Fedora EPEL 8 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-6fc04a83e8

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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] Fedora EPEL 7 updates-testing report

[updates]

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
 374  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-3c9292b62d   
condor-8.6.11-1.el7
 149  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-d2c1368294   
cinnamon-3.6.7-5.el7
 115  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-c499781e80   
python-gnupg-0.4.4-1.el7
 113  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-bc0182548b   
bubblewrap-0.3.3-2.el7
  50  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-12067fc897   
dosbox-0.74.3-2.el7
  12  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-26e64681f6   
hostapd-2.9-1.el7
   8  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-6e2a2d877a   
nfdump-1.6.18-1.el7
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-1a711333e8   
nghttp2-1.31.1-2.el7
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-e1ddf9b607   
sleuthkit-4.6.7-1.el7


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

clamav-0.101.4-1.el7
python3-chardet-3.0.4-1.el7

Details about builds:



 clamav-0.101.4-1.el7 (FEDORA-EPEL-2019-ae72f875d9)
 End-user tools for the Clam Antivirus scanner

Update Information:

ClamAV 0.101.4 is a security patch release that addresses the following issues.
-An out of bounds write was possible within ClamAV's NSIS bzip2 library when
attempting decompression in cases where the number of selectors exceeded the max
limit set by the library (CVE-2019-12900). The issue has been resolved by
respecting that limit.  Thanks to Martin Simmons for reporting the issue
here.  - The zip bomb vulnerability mitigated in 0.101.3 has been assigned
the CVE identifier CVE-2019-12625. Unfortunately, a workaround for the zip-bomb
mitigation was immediately identified. To remediate the zip-bomb scan time
issue, a scan time limit has been introduced in 0.101.4. This limit now resolves
ClamAV's vulnerability to CVE-2019-12625.  The default scan time limit is 2
minutes (12 milliseconds).  To customize the time limit: - use the
clamscan  --max-scantime option - use the clamd  MaxScanTime config option
Libclamav users may customize the time limit using the cl_engine_set_num
function. For example:  C cl_engine_set_num(engine,
CL_ENGINE_MAX_SCANTIME, time_limit_milliseconds)  Thanks to David Fifield
for reviewing the zip-bomb mitigation in 0.101.3 and reporting the issue.

ChangeLog:

* Thu Aug 22 2019 Orion Poplawski  - 0.101.4-1
- Update to 0.101.4

References:

  [ 1 ] Bug #1744273 - clamav-0.101.4 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1744273




 python3-chardet-3.0.4-1.el7 (FEDORA-EPEL-2019-25334ee372)
 Character encoding auto-detection in Python

Update Information:

Update to 3.0.4

ChangeLog:

* Thu Aug 22 2019 Orion Poplawski  - 3.0.4-1
- Update to 3.0.4


___
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

[Bug 1385002] Upgrade perl-Pod-PseudoPod-LaTeX to 1.20190729

[bugzilla]

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

Fedora Update System  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  ---
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.
___
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

[Bug 1741078] Upgrade perl-BSON to 1.12.1

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-BSON-1.12.1-1.fc31 |perl-BSON-1.12.1-1.fc31
   ||perl-BSON-1.12.1-1.fc30
 Resolution|--- |ERRATA
Last Closed||2019-08-24 01:02:46



--- Comment #6 from Fedora Update System  ---
perl-BSON-1.12.1-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.
___
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: "ERROR: Could not find useradd in chroot" in COPR rawhide builds

[Marcin Zajaczkowski]

Thanks guys for your replies. It built successfully with 
"use_bootstrap_container experimental" disabled.

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

Unretire qd

[Jerry James]

Per the "Claiming Ownership of a Retired Package" checklist, I am
announcing that I wish to unretire the qd package:

https://pagure.io/releng/issue/8673

It appears to have been one of the packages that was retired recently
due to FTBFS.  I maintain the libfplll package, which depends on qd.
-- 
Jerry James
http://www.jamezone.org/
___
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

[Bug 1744710] [RFE] EPEL8 branch of perl-HTTP-Headers-Fast

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED



--- Comment #4 from Fedora Update System  ---
FEDORA-EPEL-2019-07cb841e5f has been submitted as an update to Fedora EPEL 8.
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-07cb841e5f

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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

[Bug 1744710] [RFE] EPEL8 branch of perl-HTTP-Headers-Fast

[bugzilla]

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



--- Comment #3 from Orion Poplawski  ---
Thanks!

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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: Modularity Policy Discussion for EPEL 8.1

[Kevin Fenzi]

On 8/23/19 10:56 AM, Stephen Gallagher wrote:
> As you know, we delayed support of Modularity in EPEL (called
> Application Streams in RHEL) until 8.1 while we worked out some
> remaining issues. Some of those issues were technical, but we have a
> few others that will come down to policy. In particular, EPEL has to
> deal with something Fedora does not: the possibility that it could
> come into conflict with streams from the official Red Hat Application
> Streams.
> 
> I'm going to try to enumerate in this email some of the cases I can
> think of that might need attention, as well as providing my
> recommendations for what policy we should set in EPEL.
> 
> Case 1: EPEL ships a module "foo" with stream "baz" (aka "foo:baz").
> This is an alternative stream to RHEL AppStream, which ships
> "foo:bar". In a new minor release, RHEL AppStream starts also shipping
> "foo:baz".
> 
> Case 2: EPEL ships a module "foo:baz". RHEL AppStream does not ship
> the module"foo" at all. In a new minor release, RHEL AppStream starts
> also shipping "foo:baz".
> 
> Case 3: EPEL ships a module "foo:baz". RHEL AppStream does not ship
> the module "foo" at all. In a new minor release, RHEL AppStream starts
> also shipping "foo:bar".
> 
> Case 4: EPEL ships a module "foo:baz". AppStream ships the module
> "foo" and has "foo:bar" declared as the default stream.
> 
> Case 5: EPEL ships a module "foo:baz". AppStream ships the module
> "foo" and has no default stream specified for the "foo" module.
> 
> Case 6: EPEL ships a module "foo:baz" that wants to set the default
> profile of the "baz" stream to "client". AppStream does not ship the
> module "foo".
> 
> Case 7: EPEL ships a module "foo:baz" that wants to set the default
> profile of the "baz" stream to "client". AppStream ships the module
> "foo" and has a default profile set for the "bar" stream.
> 
> 
> 
> So lets's break these down. The first three cases are all very
> similar. They address the situation where we have both RHEL and EPEL
> attempting to own the same name within a namespace (module). My
> recommendation here is that we require EPEL module streams to be
> prefixed with "epel-". Then, even if RHEL AppStream starts shipping a
> stream of the same name, there will be no namespace collision. There
> is another benefit as well: it will be easy to tell at a glance
> whether a particular stream is from RHEL AppStream (and therefore
> supported by Red Hat) or if it comes from EPEL, with only volunteer
> community support.
> 
> The cases involving default module streams are a bit more complicated.
> Making a module stream a "default stream" effectively means that its
> contents are treated like the non-modular EPEL 8 contents, except that
> installing one of them means that the stream becomes enabled. We need
> to figure out, however, whether we should allow EPEL to set default
> streams at all. The major issue is that if RHEL later starts shipping
> this module and wants to set a default stream, we now have a conflict
> to resolve. From a technological standpoint, it can be done: Red Hat
> will need to ship the defaults object metadata with a `data.version`
> value higher than the one shipped in EPEL. Yum will then prefer that
> version over the one in EPEL. A slight risk occurs here if EPEL ships
> an update to the defaults data that bumps the version higher again,
> but that's really no different than today when someone pushes a
> package build to EPEL that ends up in RHEL with a lower version at a
> point release.
> 
> Things get dicier when we add in the concept of the default profiles,
> though. The design of the module defaults metadata did not entirely
> take the split repo ownership into account (my fault). So we
> essentially have a single YAML document in the metadata that
> identifies the default stream and the default profiles for each stream
> in the module. Now, there's some leeway here: I did consider the
> updates[-testing] use-case, so in the event that two repos both
> contain defaults for a module, they can be merged[1] in many cases. If
> they have the same `data.version` value, so long as the provided
> profiles do not conflict, they will just be merged together. If they
> have differing `data.version` values, the higher one will win.
> 
> 
> So, I see the following options for how to handle default streams in RHEL 8
> 
> Option 1: We disallow assigning default streams at all within EPEL 8.
> This will protect us against a future change where RHEL wants to set a
> default. Additionally, it means that all EPEL modules are explicitly
> opt-in and so we don't ever surprise anyone.
> 
> Option 2: We allow making EPEL streams the default stream if RHEL does
> not currently provide a default stream. We set strict policy regarding
> what a default stream may contain (such as "must not replace any
> package provided by RHEL 8"). If RHEL later decides to set a default
> for this stream, the RHEL release engineering must ensure that the
> `data.version` 

[Bug 1744676] [RFE] EPEL8 branch of perl-BSD-Resource

[bugzilla]

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



--- Comment #6 from Pat Riehecky  ---
In my ideal world, I'd love to be able to say "this package builds for these
modules" and have some back end tooling that builds the package for all the
various streams.

For example, this package perl-BSD-Resource could build for all the perl
streams.  This would let the package owner pick what streams they care about
but maintain only the one source this is not possible today.

I'll reach out to Smoogen.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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: Laptop powerdown when early boot incl. bootloader phase stuck (Was: Bug 1742953 - No Screensaver/Powerdown after Inactivity at LUKS Password Prompt)

[John Harris]

On Friday, August 23, 2019 12:34:50 PM MST Chris Murphy wrote:
> GRUB verifies the signature of the kernel before it is booted, in the
> Secure Boot enabled case.

Correct, but that's one architecture, but failing to load an image is a fatal 
error.

> a. Press any key before the timeout and it won't shutdown
> b. Power back on, and don't walk away, so you can press any key before
> the timeout, and it won't shut down

There is currently no functionality in GRUB for a timeout upon a fatal error. 
If there was, how exactly would that be useful? You'd get back to your system, 
and it's just shut down for some random reason. You power it back on, 
expecting to get back to work, and suddenly there's the same error that could 
have just been waiting for you right there on the screen.

Regardless, if implemented, that works when it's your only system. What do you 
do when you're a sysadmin managing a few hundred workstations? Just wait for 
users to complain about individual systems?

> The only way you're going to troubleshoot bootloader problems is
> having the equivalent of physical access.

Right, that or IPMI or KVM, but I don't know what that would have to do with 
implementing a timeout in GRUB.

-- 
John M. Harris, Jr. 
Splentity
https://splentity.com/

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Schedule for Mondays's FESCo Meeting (2019-08-26)

[Justin Forbes]

Following is the list of topics that will be discussed in the
FESCo meeting Monday at 15:00UTC in #fedora-meeting-1 on
irc.freenode.net.

To convert UTC to your local time, take a look at
  http://fedoraproject.org/wiki/UTCHowto

or run:
  date -d '2019-08-26 15:00 UTC'


Links to all issues to be discussed can be found at:
https://pagure.io/fesco/report/meeting_agenda

= Discussed and Voted in the Ticket =
qt5-qtwebengine : exception to continue using python2 to build
https://pagure.io/fesco/issue/2208
This is APPROVED (+4,0,-0)

= Open Floor =

We have no issues tagged for the meeting. I will open the
meeting for Open Floor if we have quorum.

For more complete details, please visit each individual
issue.  The report of the agenda items can be found at
https://pagure.io/fesco/report/meeting_agenda

If you would like to add something to this agenda, you can
reply to this e-mail, file a new issue at
https://pagure.io/fesco, e-mail me directly, or bring it
up at the end of the meeting, during the open floor topic. Note
that added topics may be deferred until the following meeting.
___
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: Laptop powerdown when early boot incl. bootloader phase stuck (Was: Bug 1742953 - No Screensaver/Powerdown after Inactivity at LUKS Password Prompt)

[Chris Murphy]

On Fri, Aug 23, 2019 at 12:59 PM John Harris  wrote:
>
> GRUB does not have the ability to halt the system on all architectures, but it
> does on most. That said, there are some things to consider:
>
> If GRUB was able to load the kernel and initrd/initramfs image, even if it's
> corrupt, it will execute that. At this point, GRUB is no longer running.

GRUB verifies the signature of the kernel before it is booted, in the
Secure Boot enabled case.

>
> Do we really want to have no indication that something went wrong, and just
> poweroff the system, upon a failed boot? How is that a good idea for any
> system, servers, workstations or laptops?

a. Press any key before the timeout and it won't shutdown
b. Power back on, and don't walk away, so you can press any key before
the timeout, and it won't shut down

The only way you're going to troubleshoot bootloader problems is
having the equivalent of physical access.

-- 
Chris Murphy
___
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: Error with fedpkg update

[Kevin Fenzi]

On 8/23/19 11:10 AM, Adam Williamson wrote:
> 
> It won't appear in Bodhi at all, but it will get the koji tag 'f31' and
> so appear in Fedora 31 composes.
> 
> This is how Rawhide and Branched-pre-Bodhi-enablement *always* worked -
> it just feels a bit odd now because we have the gating stuff enabled
> for Rawhide, but it wasn't set up for the short time between Branch
> point and Bodhi enablement for the branch; so right now Rawhide is
> working the 'new' way with auto-created Bodhi updates, but F31 is
> working the 'old' way with no Bodhi at all.

NOTE: for next branching I think the idea is to enable gating for it as
well as rawhide. This will be less confusing for everyone and make more
sense... we just weren't ready for it this time.

kevin




signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Laptop powerdown when early boot incl. bootloader phase stuck (Was: Bug 1742953 - No Screensaver/Powerdown after Inactivity at LUKS Password Prompt)

[John Harris]

On Friday, August 23, 2019 11:06:18 AM MST Chris Murphy wrote:
> On Fri, Aug 23, 2019 at 5:48 AM Jan Pokorný  wrote:
> 
> 
> > One such other situation is having the bootloader (grub2) failed and
> > hence be stuck in 'press a key to continue' or just staying in the
> > selection menu without any timeout ticking for whatever reason.
> 
> 
> There is signature verification of all the bootloader binaries, and
> the kernel, in the UEFI Secure Boot case. I'm not sure what kind of
> signature checking could be enabled in the case of UEFI Secure Boot
> disable and BIOS and other firmware types. First, there'd need to be
> some way to identify an error, then what can be done (try another
> kernel, OK what if that fails?) to mitigate it.
> 
> Since Fedora 30, the grub.cfg is no longer modified by grubby, it's a
> static configuration file. So at least in the normal case, it's
> created correctly from the outset and other than bit rot it should
> always be present and correct forever. What if any of that changes?
> I'm not sure what the fallback behavior is, it's possibly worth
> exploring. The Fedora GRUB BLS module does have some sanity testing of
> the BLS snippet in it, but I'm not sure how robust it is and if
> there's a fallback other than trying another menu entry, which means
> trying another kernel. At the point which it's exhausted all menu
> entries and kernels, then what? Does GRUB in the pre-boot environment
> on all archs have the capacity to power off the system? I'm not sure.
> It's an interesting question.

GRUB does not have the ability to halt the system on all architectures, but it 
does on most. That said, there are some things to consider:

If GRUB was able to load the kernel and initrd/initramfs image, even if it's 
corrupt, it will execute that. At this point, GRUB is no longer running.

Do we really want to have no indication that something went wrong, and just 
poweroff the system, upon a failed boot? How is that a good idea for any 
system, servers, workstations or laptops?

-- 
John M. Harris, Jr. 
Splentity
https://splentity.com/

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[389-devel] please review: PR 50563 - Improve idl_new_fetch error messages

[Mark Reynolds]

https://pagure.io/389-ds-base/pull-request/50563

--

389 Directory Server Development Team
___
389-devel mailing list -- 389-de...@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-de...@lists.fedoraproject.org

Re: Error with fedpkg update

[Fabio Valentini]

On Fri, Aug 23, 2019 at 7:58 PM Gerald B. Cox  wrote:
>
>
>
> On Fri, Aug 23, 2019 at 1:49 PM Adam Williamson  
> wrote:
>>
>>
>> >
>> > bodhi is not yet enabled for fedora 31.
>> >
>> > According to the schedule, that's supposed to happen on 2019-08-29:
>> > https://fedoraproject.org/wiki/Releases/31/Schedule
>>
>> And just to be clear - that means you don't *need* to create an update.
>> Your build just gets tagged into f31 automatically.
>>
>
> I'm a bit confused.  The master build went to F32 (rawhide).  So I then built 
> for F31, F30 and F29.  Now F32 build is showing a status of "Stable" in 
> bodhi, F29 and F30 are showing "testing".  So you're saying that 
> automagically F31 will appear in bodhi as "stable"?

No, F31 builds won't show up in bodhi at all. They go directly to
"stable" in koji. Updates only show up for F32 because of rawhide
gating, which automatically submits packages through bodhi for
testing. However, that's not yet implemented / enabled for branched
releases.

Still, bodhi *will* be activated for branched / F31 next week, and
then you will have to manually submit bodhi updates for F31 - as
usual.

TL;DR: The procedure for branched has not changed at all. It's just
that rawhide gating and rawhide / F32 updates automagically showing up
in bodhi probably makes things confusing.

Fabio

> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
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: Error with fedpkg update

[Adam Williamson]

On Fri, 2019-08-23 at 14:54 -0300, Gerald B. Cox wrote:
> On Fri, Aug 23, 2019 at 1:49 PM Adam Williamson 
> wrote:
> 
> > > bodhi is not yet enabled for fedora 31.
> > > 
> > > According to the schedule, that's supposed to happen on 2019-08-29:
> > > https://fedoraproject.org/wiki/Releases/31/Schedule
> > 
> > And just to be clear - that means you don't *need* to create an update.
> > Your build just gets tagged into f31 automatically.
> > 
> > 
> I'm a bit confused.  The master build went to F32 (rawhide).  So I then
> built for F31, F30 and F29.  Now F32 build is showing a status of "Stable"
> in bodhi, F29 and F30 are showing "testing".  So you're saying that
> automagically F31 will appear in bodhi as "stable"?

It won't appear in Bodhi at all, but it will get the koji tag 'f31' and
so appear in Fedora 31 composes.

This is how Rawhide and Branched-pre-Bodhi-enablement *always* worked -
it just feels a bit odd now because we have the gating stuff enabled
for Rawhide, but it wasn't set up for the short time between Branch
point and Bodhi enablement for the branch; so right now Rawhide is
working the 'new' way with auto-created Bodhi updates, but F31 is
working the 'old' way with no Bodhi at all.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
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: Laptop powerdown when early boot incl. bootloader phase stuck (Was: Bug 1742953 - No Screensaver/Powerdown after Inactivity at LUKS Password Prompt)

[Chris Murphy]

On Fri, Aug 23, 2019 at 5:48 AM Jan Pokorný  wrote:

> One such other situation is having the bootloader (grub2) failed and
> hence be stuck in 'press a key to continue' or just staying in the
> selection menu without any timeout ticking for whatever reason.

There is signature verification of all the bootloader binaries, and
the kernel, in the UEFI Secure Boot case. I'm not sure what kind of
signature checking could be enabled in the case of UEFI Secure Boot
disable and BIOS and other firmware types. First, there'd need to be
some way to identify an error, then what can be done (try another
kernel, OK what if that fails?) to mitigate it.

Since Fedora 30, the grub.cfg is no longer modified by grubby, it's a
static configuration file. So at least in the normal case, it's
created correctly from the outset and other than bit rot it should
always be present and correct forever. What if any of that changes?
I'm not sure what the fallback behavior is, it's possibly worth
exploring. The Fedora GRUB BLS module does have some sanity testing of
the BLS snippet in it, but I'm not sure how robust it is and if
there's a fallback other than trying another menu entry, which means
trying another kernel. At the point which it's exhausted all menu
entries and kernels, then what? Does GRUB in the pre-boot environment
on all archs have the capacity to power off the system? I'm not sure.
It's an interesting question.


-- 
Chris Murphy
___
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] Modularity Policy Discussion for EPEL 8.1

[Stephen Gallagher]

As you know, we delayed support of Modularity in EPEL (called
Application Streams in RHEL) until 8.1 while we worked out some
remaining issues. Some of those issues were technical, but we have a
few others that will come down to policy. In particular, EPEL has to
deal with something Fedora does not: the possibility that it could
come into conflict with streams from the official Red Hat Application
Streams.

I'm going to try to enumerate in this email some of the cases I can
think of that might need attention, as well as providing my
recommendations for what policy we should set in EPEL.

Case 1: EPEL ships a module "foo" with stream "baz" (aka "foo:baz").
This is an alternative stream to RHEL AppStream, which ships
"foo:bar". In a new minor release, RHEL AppStream starts also shipping
"foo:baz".

Case 2: EPEL ships a module "foo:baz". RHEL AppStream does not ship
the module"foo" at all. In a new minor release, RHEL AppStream starts
also shipping "foo:baz".

Case 3: EPEL ships a module "foo:baz". RHEL AppStream does not ship
the module "foo" at all. In a new minor release, RHEL AppStream starts
also shipping "foo:bar".

Case 4: EPEL ships a module "foo:baz". AppStream ships the module
"foo" and has "foo:bar" declared as the default stream.

Case 5: EPEL ships a module "foo:baz". AppStream ships the module
"foo" and has no default stream specified for the "foo" module.

Case 6: EPEL ships a module "foo:baz" that wants to set the default
profile of the "baz" stream to "client". AppStream does not ship the
module "foo".

Case 7: EPEL ships a module "foo:baz" that wants to set the default
profile of the "baz" stream to "client". AppStream ships the module
"foo" and has a default profile set for the "bar" stream.



So lets's break these down. The first three cases are all very
similar. They address the situation where we have both RHEL and EPEL
attempting to own the same name within a namespace (module). My
recommendation here is that we require EPEL module streams to be
prefixed with "epel-". Then, even if RHEL AppStream starts shipping a
stream of the same name, there will be no namespace collision. There
is another benefit as well: it will be easy to tell at a glance
whether a particular stream is from RHEL AppStream (and therefore
supported by Red Hat) or if it comes from EPEL, with only volunteer
community support.

The cases involving default module streams are a bit more complicated.
Making a module stream a "default stream" effectively means that its
contents are treated like the non-modular EPEL 8 contents, except that
installing one of them means that the stream becomes enabled. We need
to figure out, however, whether we should allow EPEL to set default
streams at all. The major issue is that if RHEL later starts shipping
this module and wants to set a default stream, we now have a conflict
to resolve. From a technological standpoint, it can be done: Red Hat
will need to ship the defaults object metadata with a `data.version`
value higher than the one shipped in EPEL. Yum will then prefer that
version over the one in EPEL. A slight risk occurs here if EPEL ships
an update to the defaults data that bumps the version higher again,
but that's really no different than today when someone pushes a
package build to EPEL that ends up in RHEL with a lower version at a
point release.

Things get dicier when we add in the concept of the default profiles,
though. The design of the module defaults metadata did not entirely
take the split repo ownership into account (my fault). So we
essentially have a single YAML document in the metadata that
identifies the default stream and the default profiles for each stream
in the module. Now, there's some leeway here: I did consider the
updates[-testing] use-case, so in the event that two repos both
contain defaults for a module, they can be merged[1] in many cases. If
they have the same `data.version` value, so long as the provided
profiles do not conflict, they will just be merged together. If they
have differing `data.version` values, the higher one will win.


So, I see the following options for how to handle default streams in RHEL 8

Option 1: We disallow assigning default streams at all within EPEL 8.
This will protect us against a future change where RHEL wants to set a
default. Additionally, it means that all EPEL modules are explicitly
opt-in and so we don't ever surprise anyone.

Option 2: We allow making EPEL streams the default stream if RHEL does
not currently provide a default stream. We set strict policy regarding
what a default stream may contain (such as "must not replace any
package provided by RHEL 8"). If RHEL later decides to set a default
for this stream, the RHEL release engineering must ensure that the
`data.version` value is higher than what EPEL 8 carries.

I'm somewhat more in favor of Option 1 here, mostly because it
minimizes the chance of conflicts and ensures the opt-in nature of
EPEL. But I'm willing to hear counter-arguments.



For default 

Re: Error with fedpkg update

[Gerald B. Cox]

On Fri, Aug 23, 2019 at 1:49 PM Adam Williamson 
wrote:

>
> >
> > bodhi is not yet enabled for fedora 31.
> >
> > According to the schedule, that's supposed to happen on 2019-08-29:
> > https://fedoraproject.org/wiki/Releases/31/Schedule
>
> And just to be clear - that means you don't *need* to create an update.
> Your build just gets tagged into f31 automatically.
>
>
I'm a bit confused.  The master build went to F32 (rawhide).  So I then
built for F31, F30 and F29.  Now F32 build is showing a status of "Stable"
in bodhi, F29 and F30 are showing "testing".  So you're saying that
automagically F31 will appear in bodhi as "stable"?
___
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

[Bug 1744710] [RFE] EPEL8 branch of perl-HTTP-Headers-Fast

[bugzilla]

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

Paul Howarth  changed:

   What|Removed |Added

 CC||p...@city-fan.org



--- Comment #2 from Paul Howarth  ---
(In reply to Orion Poplawski from comment #1)
> No matching package to install: 'perl(Module::Build::Tiny) >= 0.035'
> 
> which in turn needs:
> 
> No matching package to install: 'perl(ExtUtils::Config) >= 0.003'
> No matching package to install: 'perl(ExtUtils::Helpers) >= 0.020'
> No matching package to install: 'perl(ExtUtils::InstallPaths) >= 0.002'

All included in
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-c156deeb84

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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: Error with fedpkg update

[Adam Williamson]

On Fri, 2019-08-23 at 16:20 +0200, Fabio Valentini wrote:
> On Fri, Aug 23, 2019 at 4:18 PM Gerald B. Cox  wrote:
> > I've been trying to submit an update to testing for several days now and it 
> > keeps failing
> > with the following message:
> > 
> > Could not execute update: Could not generate update request: Cannot find 
> > release associated with build: copyq-3.9.1-1.fc31, tags: ['f31']
> > A copy of the filled in template is saved as bodhi.template.last
> > 
> > The fedpkg build was successful, and I see it in koj.
> > 
> > Does anyone have an idea to what the problem is?
> 
> bodhi is not yet enabled for fedora 31.
> 
> According to the schedule, that's supposed to happen on 2019-08-29:
> https://fedoraproject.org/wiki/Releases/31/Schedule

And just to be clear - that means you don't *need* to create an update.
Your build just gets tagged into f31 automatically.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
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: [HEADS UP] Fedora 32 Python 3.8 rebuilds have started in a side tag

[Miro Hrončok]

On 23. 08. 19 17:15, Vít Ondruch wrote:


Dne 23. 08. 19 v 17:05 Kaleb Keithley napsal(a):



On Wed, Aug 21, 2019 at 1:23 PM Miro Hrončok > wrote:


On 15. 08. 19 0:18, Miro Hrončok wrote:
> Hello, in order to deliver Python 3.8, we are running a coordinated
rebuild in a
> side tag.
>

The side tag was merged. Build in regular rawhide now. Thanks.


/me wonders why my `dnf update`  on my f32/rawhide box isn't updating to 
python-3.8. Should it be?



I guess there was no Rawhide compose yet, which would contain the changes. I 
would not be surprised if the merge broke the compose.


We are monitoring it to firefight any such breakage, but the current breakage is 
not relevant to 3.8.


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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: Laptop powerdown when early boot incl. bootloader phase stuck (Was: Bug 1742953 - No Screensaver/Powerdown after Inactivity at LUKS Password Prompt)

[John Harris]

On Friday, August 23, 2019 4:46:53 AM MST Jan Pokorný wrote:
> On 20/08/19 20:59 -0600, Chris Murphy wrote:
> > There is no good reason for the current behavior, in particular on a
> > laptop. And it's fail danger, not fail safe. The very simple work
> > around for the computer shutting off in 3 minutes of inactivity and
> > you don't like that? Power it back on and enter your passphrase.
> > Shockingly easy and obvious. Unless of course you're stuck somewhere
> > and in fact want to use your laptop as a heating pad.
> 
> Just that the particular corner case is not perceived in isolation,
> there are other early-boot-stuck situations that would make sense
> to deal with in the same fashion even if the sources are completely
> different (predictability is more important from user's POV, IMHO).
> 
> One such other situation is having the bootloader (grub2) failed and
> hence be stuck in 'press a key to continue' or just staying in the
> selection menu without any timeout ticking for whatever reason.
> That's directly comparable to the LUKS prompt without any attention
> for a prolonged time.
> 
> With grub2, situation is actually worse, since without having any
> means to control CPU throttling (which is already present by the
> time one is to enter LUKS password), laptop will indeed become
> said "heating pad" after a bit (one could for instance enter the
> grub prompt if it's deemed a feature for some).

To clarify on this a bit, GRUB will only stat "in the selection menu without 
any timeout for whatever reason" if it is either not configured to 
automatically select an entry after a timeout, or a key is pressed before the 
timeout, meaning GRUB expects you to choose a different boot option.

As for "stuck in 'press a key to continue'", if it didn't do this, you would 
have no way of knowing what the error is to recover your system.

-- 
John M. Harris, Jr. 
Splentity
https://splentity.com/

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: fedora-gpg-keys not updated yet again

[Kevin Fenzi]

On 8/23/19 4:12 AM, Dusty Mabe wrote:
> 
> 
> On 8/22/19 12:58 PM, Kevin Fenzi wrote:
>> On 8/21/19 9:27 AM, Dusty Mabe wrote:
>>>
>>>
>>> On 8/19/19 6:59 AM, Pavel Raiskup wrote:
 On Monday, August 19, 2019 10:50:52 AM CEST Zbigniew Jędrzejewski-Szmek 
 wrote:
> Can we *please* send out the FN+1 and FN+2 keys a month before branching,
> to *all* releases of Fedora, so we can avoid this pointless scramble?

 What about to have F33 keys right now, when the fresh F31 branch is out?

>>>
>>> +1. Go ahead and make the f33 keys when we branch for f31. 
>>
>> I don't see how this helps any. I agree we should push out the f33 keys
>> before next branching, but why now?
>>
> 
> For me it solves any "timing" issues. We often get into a state where we're
> trying to upgrade to something that is signed with a key we don't have yet.

Yes, but it would also be solved by pushing the F33 key out a few weeks
or a month or so before branching next time right?

kevin



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: f32/rawhide, nothing provides module(platform:f31)

[Kevin Fenzi]

On 8/23/19 8:07 AM, Kaleb Keithley wrote:
> `dnf update` on my f32/rawhide machine is giving me:
> 
> Problem 1: conflicting requests
>   - nothing provides module(platform:f31) needed by module
> bat:latest:3120190714171319:22d7e2a5-0.x86_64
>  Problem 2: conflicting requests
>   - nothing provides module(platform:f31) needed by module
> exa:latest:3120190721165838:22d7e2a5-0.x86_64
>  Problem 3: conflicting requests
>   - nothing provides module(platform:f31) needed by module
> libgit2:0.28:3120190714114509:f636be4b-0.x86_64
>  Problem 4: conflicting requests
>   - nothing provides module(platform:f31) needed by module
> silver:rolling:3120190728135623:22d7e2a5-0.x86_64
> 
> What do I need to do for this?

There's nothing you can do, releng needs to rebuild modules:

https://pagure.io/releng/issue/8664

kevin



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: [HEADS UP] Fedora 32 Python 3.8 rebuilds have started in a side tag

[Peter Robinson]

On Fri, Aug 23, 2019 at 4:07 PM Kaleb Keithley  wrote:
>
>
>
> On Wed, Aug 21, 2019 at 1:23 PM Miro Hrončok  wrote:
>>
>> On 15. 08. 19 0:18, Miro Hrončok wrote:
>> > Hello, in order to deliver Python 3.8, we are running a coordinated 
>> > rebuild in a
>> > side tag.
>> >
>>
>> The side tag was merged. Build in regular rawhide now. Thanks.
>
>
> /me wonders why my `dnf update`  on my f32/rawhide box isn't updating to 
> python-3.8. Should it be?
>
> Both rawhide-modular and rawhide repos are enabled.

There's not been a successful compose with the content. There was some
interaction problems with anaconda in there. Once that's succeeded you
should see it shortly there after, keep an eye out in the Rawhide
Reports which have the updates.
___
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: Code Ready Builder

[Stephen John Smoogen]

On Fri, 23 Aug 2019 at 11:03, Paul Howarth  wrote:
>
> The EL-8 non-default repo Code Ready Builder is primarily targeted at
> developers, but it looks to me like it's going to be a required repo
> for a lot of EPEL-8 users, particularly those using interpreted
> languages.
>
> As an example, today I built perl-Expect for EPEL-8
> (https://bugzilla.redhat.com/show_bug.cgi?id=1744512). This has a
> dependency on perl-IO-Tty, which is in Code Ready Builder. The
> dependency isn't just a build-time dependency though, it's a run-time
> one too. So it seems to me that the Code Ready Builder repo will be
> required for lots of EPEL-8 users, just like the optional repo used to
> be for earlier EL versions.
>

Yeah. I think this is going to be one of those hard things we are
going to run into with a lot of Appstream missing packages. Most of
the time it can be done without it and then BOOM nope you need 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



-- 
Stephen J Smoogen.
___
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: [Help needed] Packaging sassc ruby gem for jekyll 4.0.0

[Vít Ondruch]

Pavel Valena did some work on sassc:

https://copr.fedorainfracloud.org/coprs/pvalena/rubygems/package/rubygem-sassc/


Vít


Dne 23. 08. 19 v 16:53 Fabio Valentini napsal(a):
> Hi everybody,
>
> With the recent, major new release of Jekyll (4.0.0) and its SASS
> converter (2.0.0), it migrated from the deprecated, plain ruby "sass"
> gem to "sassc", which is a wrapper around the libsass C++ library.
> I've never had to deal with this scenario for my other ruby packages,
> and I just can't get it to work, even when using the bundled version
> of libsass (which, by the way, is newer than what's available in
> fedora ...).
>
> Can anybody give me some pointers how to properly do this? The
> packaging guidelines for this scenario are kind of vague, and I just
> can't get my .spec file to do "the right thing" (TM) here.
>
> A WIP .spec file (generated with gem2rpm, and with fixes for the
> issues I know how to solve already applied on top) is here:
> https://github.com/decathorpe/rpmbuild-staging/blob/master/SPECS/rubygem-sassc.spec
>
> Thanks,
> Fabio
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
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: [HEADS UP] Fedora 32 Python 3.8 rebuilds have started in a side tag

[Fabio Valentini]

On Fri, Aug 23, 2019, 17:07 Kaleb Keithley  wrote:

>
>
> On Wed, Aug 21, 2019 at 1:23 PM Miro Hrončok  wrote:
>
>> On 15. 08. 19 0:18, Miro Hrončok wrote:
>> > Hello, in order to deliver Python 3.8, we are running a coordinated
>> rebuild in a
>> > side tag.
>> >
>>
>> The side tag was merged. Build in regular rawhide now. Thanks.
>>
>
> /me wonders why my `dnf update`  on my f32/rawhide box isn't updating to
> python-3.8. Should it be?
>
> Both rawhide-modular and rawhide repos are enabled.
>

I think there has not yet been a successful rawhide compose since the side
tag with python 3.8 was merged in koji.

Fabio


> Thanks,
>
> --
>
> Kaleb
> ___
> 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
>
___
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: [HEADS UP] Fedora 32 Python 3.8 rebuilds have started in a side tag

[Vít Ondruch]

Dne 23. 08. 19 v 17:05 Kaleb Keithley napsal(a):
>
>
> On Wed, Aug 21, 2019 at 1:23 PM Miro Hrončok  > wrote:
>
> On 15. 08. 19 0:18, Miro Hrončok wrote:
> > Hello, in order to deliver Python 3.8, we are running a
> coordinated rebuild in a
> > side tag.
> >
>
> The side tag was merged. Build in regular rawhide now. Thanks.
>
>
> /me wonders why my `dnf update`  on my f32/rawhide box isn't updating
> to python-3.8. Should it be?


I guess there was no Rawhide compose yet, which would contain the
changes. I would not be surprised if the merge broke the compose.


Vít


>
> Both rawhide-modular and rawhide repos are enabled.
>
> Thanks,
>
> --
>
> Kaleb
>
> ___
> 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
___
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

f32/rawhide, nothing provides module(platform:f31)

[Kaleb Keithley]

`dnf update` on my f32/rawhide machine is giving me:

Problem 1: conflicting requests
  - nothing provides module(platform:f31) needed by module
bat:latest:3120190714171319:22d7e2a5-0.x86_64
 Problem 2: conflicting requests
  - nothing provides module(platform:f31) needed by module
exa:latest:3120190721165838:22d7e2a5-0.x86_64
 Problem 3: conflicting requests
  - nothing provides module(platform:f31) needed by module
libgit2:0.28:3120190714114509:f636be4b-0.x86_64
 Problem 4: conflicting requests
  - nothing provides module(platform:f31) needed by module
silver:rolling:3120190728135623:22d7e2a5-0.x86_64

What do I need to do for this?

Thanks,

--

Kaleb
___
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: [HEADS UP] Fedora 32 Python 3.8 rebuilds have started in a side tag

[Kaleb Keithley]

On Wed, Aug 21, 2019 at 1:23 PM Miro Hrončok  wrote:

> On 15. 08. 19 0:18, Miro Hrončok wrote:
> > Hello, in order to deliver Python 3.8, we are running a coordinated
> rebuild in a
> > side tag.
> >
>
> The side tag was merged. Build in regular rawhide now. Thanks.
>

/me wonders why my `dnf update`  on my f32/rawhide box isn't updating to
python-3.8. Should it be?

Both rawhide-modular and rawhide repos are enabled.

Thanks,

--

Kaleb
___
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] Code Ready Builder

[Paul Howarth]

The EL-8 non-default repo Code Ready Builder is primarily targeted at
developers, but it looks to me like it's going to be a required repo
for a lot of EPEL-8 users, particularly those using interpreted
languages.

As an example, today I built perl-Expect for EPEL-8
(https://bugzilla.redhat.com/show_bug.cgi?id=1744512). This has a
dependency on perl-IO-Tty, which is in Code Ready Builder. The
dependency isn't just a build-time dependency though, it's a run-time
one too. So it seems to me that the Code Ready Builder repo will be
required for lots of EPEL-8 users, just like the optional repo used to
be for earlier EL versions.

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

[Help needed] Packaging sassc ruby gem for jekyll 4.0.0

[Fabio Valentini]

Hi everybody,

With the recent, major new release of Jekyll (4.0.0) and its SASS
converter (2.0.0), it migrated from the deprecated, plain ruby "sass"
gem to "sassc", which is a wrapper around the libsass C++ library.
I've never had to deal with this scenario for my other ruby packages,
and I just can't get it to work, even when using the bundled version
of libsass (which, by the way, is newer than what's available in
fedora ...).

Can anybody give me some pointers how to properly do this? The
packaging guidelines for this scenario are kind of vague, and I just
can't get my .spec file to do "the right thing" (TM) here.

A WIP .spec file (generated with gem2rpm, and with fixes for the
issues I know how to solve already applied on top) is here:
https://github.com/decathorpe/rpmbuild-staging/blob/master/SPECS/rubygem-sassc.spec

Thanks,
Fabio
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: "ERROR: Could not find useradd in chroot" in COPR rawhide builds

[Miroslav Suchý]

Dne 22. 08. 19 v 17:54 Miro Hrončok napsal(a):
> On 22. 08. 19 17:37, Marcin Zajaczkowski wrote:
>> Hi. Probably I missed some announcement, but my doublecmd builds have 
>> started to fail a few days ago in rawhide with:
>>> Complete!
>>> Finish(bootstrap): dnf install
>>> ERROR: Exception(/tmp/tmp5fbduv2b/doublecmd-gtk.spec) 
>>> Config(1015329-fedora-rawhide-x86_64) 0 minutes 57 seconds
>>> INFO: Results and/or logs in: /var/lib/copr-rpmbuild/results
>>> INFO: Cleaning up build root ('cleanup_on_failure=True')
>>> Start: clean chroot
>>> INFO: unmounting tmpfs.
>>> Finish: clean chroot
>>> ERROR: Could not find useradd in chroot, maybe the install failed?
>>
>> https://copr-be.cloud.fedoraproject.org/results/vondruch/doublecmd/fedora-rawhide-x86_64/01015329-doublecmd-gtk/builder-live.log.gz
>>
>> https://copr.fedorainfracloud.org/coprs/vondruch/doublecmd/
> 
> 
> This might be caused by https://bugzilla.redhat.com/show_bug.cgi?id=1740421

Nope. It seems that minimalization of Fedora reached another level and DNF no 
longer requires shadow-utils.
Should be fixed by 
https://github.com/rpm-software-management/mock/commit/8f8863d6a9189d8b3771198272e2017e02cf0f02

-- 
Miroslav Suchy, RHCA
Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys
___
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

[Bug 1744681] [RFE] EPEL8 branch of perl-Net-IP

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|NEW |MODIFIED



--- Comment #1 from Fedora Update System  ---
FEDORA-EPEL-2019-e5ad6f9682 has been submitted as an update to Fedora EPEL 8.
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-e5ad6f9682

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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: Rules for shadowing RHEL packages with EPEL modules

[Stephen Gallagher]

On Fri, Aug 23, 2019 at 9:43 AM Petr Pisar  wrote:

> On Fri, Aug 23, 2019 at 08:26:32AM -0400, Stephen John Smoogen wrote:
> > On Fri, 23 Aug 2019 at 06:52, Petr Pisar  wrote:
> > > Case: RHEL delivers a non-modular P package. There is no S stream of
> > > a M module. Can I add a new M module with a new S stream that will
> contain
> > > a modular P package? I guess it will be allowed. Can I make the stream
> > > default? I guess that won't be allowed.
> > >
> >
> > I would agree with your assessment.
> >
> Thank you for the prompt response. I have yet another peculiar corner case
> of
> this one, that I is actually very prominent for me:
>
> We have plenty of Perl packages in RHEL. Most of them are not modularized,
> thus they are compatible only with Perl 5.26, a default perl:5.26 stream.
> I feel there will be a demand for providing their modularized variants in
> EPEL
> so that users can use them even with non-default perl.
>
> All that can be implemented by adding a new module. This is not a problem.
> The
> problem is that the module will an second-class citizen compating to a
> module
> with net new package due to missing the default stream. The reasong for
> banning the default is that the EPEL modular package would mask the
> non-modular RHEL package.
>
> Let's I have a theoretcal way how to build that module so thet a context
> for
> perl:5.26 will be an empty, no RPM package. Then making the stream default
> would not violate the no-replacement rule.
>
> If a user used perl:5.26, yum would install the non-modular package from
> RHEL
> because there won't by any modular package masking it. If a user enabled
> a different perl stream, yum would install the modular package from EPEL.
>
> Would you accept this solution?
>

 I just spent a few minutes trying to figure out if this is technically
possible. I think it *might* be, but the more I think about it, the less I
like it. I think we should approach EPEL with the principle of least
surprise. I don't think any admin should ever get an EPEL package *by
accident*. If they used `yum enable perl:5.24`, I don't think that should
implicitly mean that they start getting EPEL packages. If they want to use
EPEL content, they should have to enable an EPEL stream on purpose.
___
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: Error with fedpkg update

[Fabio Valentini]

On Fri, Aug 23, 2019 at 4:18 PM Gerald B. Cox  wrote:
>
> I've been trying to submit an update to testing for several days now and it 
> keeps failing
> with the following message:
>
> Could not execute update: Could not generate update request: Cannot find 
> release associated with build: copyq-3.9.1-1.fc31, tags: ['f31']
> A copy of the filled in template is saved as bodhi.template.last
>
> The fedpkg build was successful, and I see it in koj.
>
> Does anyone have an idea to what the problem is?

bodhi is not yet enabled for fedora 31.

According to the schedule, that's supposed to happen on 2019-08-29:
https://fedoraproject.org/wiki/Releases/31/Schedule

Fabio

> Thanks!
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
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: Rules for shadowing RHEL packages with EPEL modules

[Stephen Gallagher]

On Fri, Aug 23, 2019 at 6:52 AM Petr Pisar  wrote:

> If I read the EPEL 8 annoucement correctly, it's still not possible to
> build
> modules in EPEL. Nevertheless I'd like to know how the rules about "not
> replacing RHEL content" will apply to modules. Here are my question:
>
> Case: RHEL delivers an M module with a default S1 stream. There is no S2
> stream. Can I add a new S2 stream into EPEL? I guess this will be allowed.
> If
> later RHEL introduces S2 stream, I guess EPEL will remove the S2 module.
>
>
As Smooge says downstream, I think EPEL will need to namespace its streams
so it's always clear if you are running an EPEL or RHEL version of a
stream. I also don't think we necessarily need to drop the EPEL version;
since two streams of the same module cannot be enabled at the same time,
there shouldn't be any harm in retaining the EPEL one if there is cause to
do so. (For example, maybe the EPEL version includes experimental features
where the RHEL one has them disabled).


> Case: RHEL delivers an M module with no default stream, there is no S
> stream.
> Can I add a new S stream into EPEL and make it default? I'm not sure this
> will
> be allowed. There is a risk of creating conflicts between streams
> transitively
> required by another default streams. (Remember the libgit2 module conflict
> .)
>
>
I think the only safe approach for EPEL is to disallow the setting of
default streams. This will avoid the possibility of conflicts.



> Case: RHEL delivers a non-modular P package. There is no S stream of
> a M module. Can I add a new M module with a new S stream that will contain
> a modular P package? I guess it will be allowed. Can I make the stream
> default? I guess that won't be allowed.
>


As I said above, I think we probably don't want EPEL to ever ship a default
stream. They should always be supplemental. As for shipping a non-default
stream that carries P: yes, that will work. And it's one of the major
advantages that EPEL gains in RHEL 8: it's finally possible for us to ship
updated versions of RHEL software where required, as long as it is a
conscious user decision. (We need to make it clear that if they enable this
stream, they're not going to be supported for it by Red Hat if it breaks
something else on their system).



>
> Case: RHEL delivers a P package. Can I build a modular P package when
> building
> a new module stream in EPEL only for the purpose of building the module
> and then filter out the P package from the module (i.e. a build-only module
> component) so that the P package does not get into EPEL repository? I guess
> this will be allowed.
>
>
Yes, absolutely. If a package is only needed at build-time, this is an
ideal way to deal with it. We're also going to be improving MBS to make
this simpler: see https://pagure.io/fm-orchestrator/issue/1307 (implementation
of
https://github.com/fedora-modularity/libmodulemd/blob/master/spec.v2.yaml#L282
 )



> Could EPEL product owner (or whoever makes and assert the rules) clarify?
> I need to know that to choose the easiest and yet conforming strategy for
> adding new modules into EPEL, especially when dealing with RHEL packages
> unavailable for some module contexts.
>

I hope this helps.
___
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

Error with fedpkg update

[Gerald B. Cox]

I've been trying to submit an update to testing for several days now and it
keeps failing
with the following message:

Could not execute update: Could not generate update request: Cannot find
release associated with build: copyq-3.9.1-1.fc31, tags: ['f31']
A copy of the filled in template is saved as bodhi.template.last

The fedpkg build was successful, and I see it in koj.

Does anyone have an idea to what the problem is?

Thanks!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora-31-20190823.n.0 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 16/152 (x86_64), 1/2 (arm)

New failures (same test not failed in Fedora-31-20190822.n.0):

ID: 434660  Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/434660
ID: 434663  Test: x86_64 Workstation-live-iso desktop_background
URL: https://openqa.fedoraproject.org/tests/434663
ID: 434670  Test: x86_64 KDE-live-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/434670
ID: 434674  Test: x86_64 KDE-live-iso base_update_cli
URL: https://openqa.fedoraproject.org/tests/434674
ID: 434681  Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/434681
ID: 434686  Test: x86_64 Silverblue-dvd_ostree-iso release_identification
URL: https://openqa.fedoraproject.org/tests/434686
ID: 434694  Test: x86_64 Silverblue-dvd_ostree-iso desktop_background
URL: https://openqa.fedoraproject.org/tests/434694
ID: 434765  Test: x86_64 universal install_pxeboot@uefi
URL: https://openqa.fedoraproject.org/tests/434765

Old failures (same test failed in Fedora-31-20190822.n.0):

ID: 434648  Test: x86_64 Server-dvd-iso modularity_tests
URL: https://openqa.fedoraproject.org/tests/434648
ID: 434668  Test: x86_64 KDE-live-iso release_identification
URL: https://openqa.fedoraproject.org/tests/434668
ID: 434679  Test: x86_64 KDE-live-iso desktop_background
URL: https://openqa.fedoraproject.org/tests/434679
ID: 434683  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/434683
ID: 434712  Test: x86_64 universal install_software_raid
URL: https://openqa.fedoraproject.org/tests/434712
ID: 434718  Test: x86_64 universal install_no_swap
URL: https://openqa.fedoraproject.org/tests/434718
ID: 434737  Test: x86_64 universal install_software_raid@uefi
URL: https://openqa.fedoraproject.org/tests/434737
ID: 434742  Test: x86_64 universal install_no_swap@uefi
URL: https://openqa.fedoraproject.org/tests/434742
ID: 434766  Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/434766

Soft failed openQA tests: 2/152 (x86_64)
(Tests completed, but using a workaround for a known bug)

Old soft failures (same test soft failed in Fedora-31-20190822.n.0):

ID: 434749  Test: x86_64 universal upgrade_kde_64bit
URL: https://openqa.fedoraproject.org/tests/434749
ID: 434750  Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/434750

Passed openQA tests: 133/152 (x86_64)

New passes (same test not passed in Fedora-31-20190822.n.0):

ID: 434652  Test: x86_64 Workstation-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/434652
ID: 434653  Test: x86_64 Workstation-live-iso release_identification
URL: https://openqa.fedoraproject.org/tests/434653
ID: 434654  Test: x86_64 Workstation-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/434654
ID: 434655  Test: x86_64 Workstation-live-iso base_selinux
URL: https://openqa.fedoraproject.org/tests/434655
ID: 434656  Test: x86_64 Workstation-live-iso base_services_start
URL: https://openqa.fedoraproject.org/tests/434656
ID: 434657  Test: x86_64 Workstation-live-iso base_service_manipulation
URL: https://openqa.fedoraproject.org/tests/434657
ID: 434658  Test: x86_64 Workstation-live-iso base_update_cli
URL: https://openqa.fedoraproject.org/tests/434658
ID: 434659  Test: x86_64 Workstation-live-iso base_system_logging
URL: https://openqa.fedoraproject.org/tests/434659
ID: 434661  Test: x86_64 Workstation-live-iso desktop_terminal
URL: https://openqa.fedoraproject.org/tests/434661
ID: 434662  Test: x86_64 Workstation-live-iso desktop_browser
URL: https://openqa.fedoraproject.org/tests/434662
ID: 434666  Test: x86_64 Workstation-live-iso 
desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/434666
ID: 434676  Test: x86_64 KDE-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/434676
ID: 434685  Test: x86_64 Silverblue-dvd_ostree-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/434685
ID: 434687  Test: x86_64 Silverblue-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/434687
ID: 434688  Test: x86_64 Silverblue-dvd_ostree-iso base_selinux
URL: https://openqa.fedoraproject.org/tests/434688
ID: 434689  Test: x86_64 Silverblue-dvd_ostree-iso base_services_start
URL: https://openqa.fedoraproject.org/tests/434689
ID: 434690  Test: x86_64 Silverblue-dvd_ostree-iso base_service_manipulation
URL: https://openqa.fedoraproject.org/tests/434690
ID: 434691  Test: x86_64 Silverblue-dvd_ostree-iso base_system_logging
URL: https://openqa.fedoraproject.org/tests/434691
ID: 434692  Test: x86_64 Silverblue-dvd_ostree-iso desktop_terminal
URL: 

[Bug 1744512] Request to build perl-Expect for EPEL 8

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED



--- Comment #1 from Fedora Update System  ---
FEDORA-EPEL-2019-6fc04a83e8 has been submitted as an update to Fedora EPEL 8.
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-6fc04a83e8

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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

[Bug 1744512] Request to build perl-Expect for EPEL 8

[bugzilla]

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

Paul Howarth  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|trem...@tremble.org.uk  |p...@city-fan.org



-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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: Rules for shadowing RHEL packages with EPEL modules

[Chris Adams]

Once upon a time, Stephen John Smoogen  said:
> Honestly I don't understand the solution (and probably the problem)
> enough to answer. My understanding of modules is about the same as a
> layman's knowledge of quantum mechanics. I know it exists, I know it
> does a lot of things, and I know it is full of conundrums which make
> no sense to what I normally want to do.

THIS!

I've been hearing about modules for a while in Fedora, and now in RHEL 8,
but I don't really have the faintest idea what they are, how I'll have
to deal with them (both as an admin and as a packager), etc.

Once CentOS 8 is out and I have some time, I'll work on getting my one
useful EPEL package built for it, but hopefully that won't involve
modules.  I only have a couple of packages between Fedora and EPEL, and
they so rarely need updates that every time I do anything, I have to go
fumble through the steps required (trying to follow online
documentation, which I usually screw up, like I think I checked my
source tarball into git like a moron).

-- 
Chris Adams 
___
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: Rules for shadowing RHEL packages with EPEL modules

[Stephen John Smoogen]

On Fri, 23 Aug 2019 at 09:43, Petr Pisar  wrote:
>
> On Fri, Aug 23, 2019 at 08:26:32AM -0400, Stephen John Smoogen wrote:
> > On Fri, 23 Aug 2019 at 06:52, Petr Pisar  wrote:
> > > Case: RHEL delivers a non-modular P package. There is no S stream of
> > > a M module. Can I add a new M module with a new S stream that will contain
> > > a modular P package? I guess it will be allowed. Can I make the stream
> > > default? I guess that won't be allowed.
> > >
> >
> > I would agree with your assessment.
> >
> Thank you for the prompt response. I have yet another peculiar corner case of
> this one, that I is actually very prominent for me:
>
> We have plenty of Perl packages in RHEL. Most of them are not modularized,
> thus they are compatible only with Perl 5.26, a default perl:5.26 stream.
> I feel there will be a demand for providing their modularized variants in EPEL
> so that users can use them even with non-default perl.
>
> All that can be implemented by adding a new module. This is not a problem. The
> problem is that the module will an second-class citizen compating to a module
> with net new package due to missing the default stream. The reasong for
> banning the default is that the EPEL modular package would mask the
> non-modular RHEL package.
>
> Let's I have a theoretcal way how to build that module so thet a context for
> perl:5.26 will be an empty, no RPM package. Then making the stream default
> would not violate the no-replacement rule.
>
> If a user used perl:5.26, yum would install the non-modular package from RHEL
> because there won't by any modular package masking it. If a user enabled
> a different perl stream, yum would install the modular package from EPEL.
>
> Would you accept this solution?
>

Honestly I don't understand the solution (and probably the problem)
enough to answer. My understanding of modules is about the same as a
layman's knowledge of quantum mechanics. I know it exists, I know it
does a lot of things, and I know it is full of conundrums which make
no sense to what I normally want to do.

My general rule is going to be "Does this require too much thinking of
a system administrator to fix or figure out at 2am when they have
worked 4 12 hour days already?" If it does, I don't think it needs to
be in EPEL and should have its own solution and community of people
who understand it to run. If it doesn't, then it can probably work in
EPEL but needs to be written in a way that 2am sysadmin can grok.


-- 
Stephen J Smoogen.
___
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: Rules for shadowing RHEL packages with EPEL modules

[Petr Pisar]

On Fri, Aug 23, 2019 at 08:26:32AM -0400, Stephen John Smoogen wrote:
> On Fri, 23 Aug 2019 at 06:52, Petr Pisar  wrote:
> > Case: RHEL delivers a non-modular P package. There is no S stream of
> > a M module. Can I add a new M module with a new S stream that will contain
> > a modular P package? I guess it will be allowed. Can I make the stream
> > default? I guess that won't be allowed.
> >
> 
> I would agree with your assessment.
> 
Thank you for the prompt response. I have yet another peculiar corner case of
this one, that I is actually very prominent for me:

We have plenty of Perl packages in RHEL. Most of them are not modularized,
thus they are compatible only with Perl 5.26, a default perl:5.26 stream.
I feel there will be a demand for providing their modularized variants in EPEL
so that users can use them even with non-default perl.

All that can be implemented by adding a new module. This is not a problem. The
problem is that the module will an second-class citizen compating to a module
with net new package due to missing the default stream. The reasong for
banning the default is that the EPEL modular package would mask the
non-modular RHEL package.

Let's I have a theoretcal way how to build that module so thet a context for
perl:5.26 will be an empty, no RPM package. Then making the stream default
would not violate the no-replacement rule.

If a user used perl:5.26, yum would install the non-modular package from RHEL
because there won't by any modular package masking it. If a user enabled 
a different perl stream, yum would install the modular package from EPEL.

Would you accept this solution?

-- Petr


signature.asc
Description: PGP signature
___
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

Fedora 31 compose report: 20190823.n.0 changes

[Fedora Branched Report]

OLD: Fedora-31-20190822.n.0
NEW: Fedora-31-20190823.n.0

= SUMMARY =
Added images:3
Dropped images:  0
Added packages:  3
Dropped packages:3
Upgraded packages:   75
Downgraded packages: 0

Size of added packages:  158.44 MiB
Size of dropped packages:1.89 MiB
Size of upgraded packages:   2.42 GiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   -36.04 MiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =
Image: Server raw-xz aarch64
Path: Server/aarch64/images/Fedora-Server-31-20190823.n.0.aarch64.raw.xz
Image: Workstation raw-xz armhfp
Path: 
Workstation/armhfp/images/Fedora-Workstation-armhfp-31-20190823.n.0-sda.raw.xz
Image: Server raw-xz armhfp
Path: Server/armhfp/images/Fedora-Server-armhfp-31-20190823.n.0-sda.raw.xz

= DROPPED IMAGES =

= ADDED PACKAGES =
Package: celestia-1.6.1-29.fc29
Summary: OpenGL real-time visual space simulation
RPMs:celestia
Size:149.01 MiB

Package: gstreamer-plugins-base-0.10.36-18.fc27
Summary: GStreamer streaming media framework base plug-ins
RPMs:gstreamer-plugins-base gstreamer-plugins-base-devel 
gstreamer-plugins-base-devel-docs gstreamer-plugins-base-tools
Size:9.42 MiB

Package: nodejs-monocle-1.1.51-12.fc29
Summary: A tool for watching directories for file changes
RPMs:nodejs-monocle
Size:12.77 KiB


= DROPPED PACKAGES =
Package: freshmaker-0.0.4-8.fc30
Summary: Freshmaker is a service scheduling rebuilds of artifacts as new 
content becomes available.
RPMs:freshmaker
Size:147.82 KiB

Package: perl-GStreamer-0.20-16.fc31
Summary: Perl bindings to version 0.10.x of the GStreamer framework
RPMs:perl-GStreamer
Size:1.56 MiB

Package: perl-GStreamer-Interfaces-0.06-23.fc31
Summary: Perl interface to the GStreamer Interfaces library
RPMs:perl-GStreamer-Interfaces
Size:196.04 KiB


= UPGRADED PACKAGES =
Package:  GitPython-3.0.2-1.fc31
Old package:  GitPython-2.1.11-4.fc31
Summary:  Python Git Library
RPMs: python3-GitPython
Size: 536.81 KiB
Size change:  5.05 KiB
Changelog:
  * Fri Aug 16 2019 Miro Hron??ok  - 2.1.11-5
  - Rebuilt for Python 3.8

  * Thu Aug 22 2019 Kevin Fenzi  - 3.0.2-1
  - Update to 3.0.2. Fixes bug #1742158


Package:  R-units-0.6.4-1.fc31
Old package:  R-units-0.6.3-3.fc31
Summary:  Measurement Units for R Vectors
RPMs: R-units
Size: 4.60 MiB
Size change:  25.01 KiB
Changelog:
  * Thu Aug 22 2019 I??aki ??car  - 0.6.4-1
  - Update to 0.6-4


Package:  aime-8.20190821-1.fc31
Old package:  aime-8.20190626-2.fc31
Summary:  An application embeddable programming language interpreter
RPMs: aime aime-devel
Size: 3.84 MiB
Size change:  8.48 KiB
Changelog:
  * Thu Aug 22 2019 Filipe Rosset  - 8.20190821-1
  - Updated to 8.20190821 fixes rhbz#1744389


Package:  avahi-0.7-20.fc31
Old package:  avahi-0.7-18.fc30
Summary:  Local network service discovery
RPMs: avahi avahi-autoipd avahi-compat-howl avahi-compat-howl-devel 
avahi-compat-libdns_sd avahi-compat-libdns_sd-devel avahi-devel avahi-dnsconfd 
avahi-glib avahi-glib-devel avahi-gobject avahi-gobject-devel avahi-libs 
avahi-qt3 avahi-qt3-devel avahi-qt4 avahi-qt4-devel avahi-sharp avahi-tools 
avahi-ui avahi-ui-devel avahi-ui-gtk3 avahi-ui-sharp avahi-ui-sharp-devel 
avahi-ui-tools python2-avahi python3-avahi
Size: 4.96 MiB
Size change:  175.51 KiB
Changelog:
  * Fri Feb 22 2019 Michal Seklet??r  - 0.7-19
  - add support for advertising services on the local machine only (i.e. on 
loopback)

  * Wed Jul 24 2019 Fedora Release Engineering  - 
0.7-20
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_31_Mass_Rebuild


Package:  blueberry-1.2.9-1.fc31
Old package:  blueberry-1.2.6-2.fc31
Summary:  Bluetooth configuration tool
RPMs: blueberry cinnamon-applet-blueberry
Size: 1.22 MiB
Size change:  6.89 KiB
Changelog:
  * Thu Aug 22 2019 Kevin Fenzi  - 1.2.8-1
  - Update to 1.2.8. Fixes bug #1742148

  * Thu Aug 22 2019 Mukundan Ragavan  - 1.2.9-1
  - Update to 1.2.9


Package:  cacti-1.2.5-4.fc31
Old package:  cacti-1.2.5-3.fc31
Summary:  An rrd based graphing tool
RPMs: cacti
Size: 18.76 MiB
Size change:  101 B
Changelog:
  * Thu Aug 22 2019 Morten Stevens  - 1.2.5-4
  - Don't require php-imap


Package:  cekit-3.4.0-1.fc31
Old package:  cekit-3.3.1-2.fc31
Summary:  Container image creation tool
RPMs: cekit cekit-bash-completion cekit-zsh-completion
Size: 128.67 KiB
Size change:  3.40 KiB
Changelog:
  * Mon Aug 19 2019 Miro Hron??ok  - 3.3.1-3
  - Rebuilt for Python 3.8

  * Thu Aug 22 2019 Marek Goldmann  - 3.4.0-1
  - Release 3.4.0


Package:  charliecloud-0.9.10-12.fc31
Old package:  charliecloud-0.9.10-10.fc31
Summary:  Lightweight user-defined software stacks for high-performance 
computing
RPMs: charliecloud charliecloud-doc
Size: 754.70 KiB
Size change:  -1.57

Perl modules in EPEL 8

[Petr Pisar]

As promised in  and on
#fedora-perl FreeNode channel, here are some information about packaging Perl
code in for EPEL 8.

EPEL 8.0 release was announced
.
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 . 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

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 ( 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
.)

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 

[EPEL-devel] Re: Rules for shadowing RHEL packages with EPEL modules

[Stephen John Smoogen]

The following answers are just my opinions and not policy.

On Fri, 23 Aug 2019 at 06:52, Petr Pisar  wrote:
>
> If I read the EPEL 8 annoucement correctly, it's still not possible to build
> modules in EPEL. Nevertheless I'd like to know how the rules about "not
> replacing RHEL content" will apply to modules. Here are my question:
>
> Case: RHEL delivers an M module with a default S1 stream. There is no S2
> stream. Can I add a new S2 stream into EPEL? I guess this will be allowed. If
> later RHEL introduces S2 stream, I guess EPEL will remove the S2 module.
>

Personally I think all EPEL streams should say they are they from EPEL
so S2-EPEL. Consider it a Stream tag :).

> Case: RHEL delivers an M module with no default stream, there is no S stream.
> Can I add a new S stream into EPEL and make it default? I'm not sure this will
> be allowed. There is a risk of creating conflicts between streams transitively
> required by another default streams. (Remember the libgit2 module conflict
> .)
>

I would be against that. However I am not sure how we would police
that.. [because there is no one to do that kind of work.]


> Case: RHEL delivers a non-modular P package. There is no S stream of
> a M module. Can I add a new M module with a new S stream that will contain
> a modular P package? I guess it will be allowed. Can I make the stream
> default? I guess that won't be allowed.
>

I would agree with your assessment.


> Case: RHEL delivers a P package. Can I build a modular P package when building
> a new module stream in EPEL only for the purpose of building the module
> and then filter out the P package from the module (i.e. a build-only module
> component) so that the P package does not get into EPEL repository? I guess
> this will be allowed.
>

It will have to be allowed because it is going to be the only way we
can build a lot of packages which may never show up in Code Ready
Builder.

> Could EPEL product owner (or whoever makes and assert the rules) clarify?

There is no product. There is no product owner. The EPEL Steering
Committee helps craft rules but in the end they will come from the
community.


> I need to know that to choose the easiest and yet conforming strategy for
> adding new modules into EPEL, especially when dealing with RHEL packages
> unavailable for some module contexts.
>
> -- Petr
> ___
> 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



-- 
Stephen J Smoogen.
___
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: 'showme' RPM dependency visualizer (was: Minimization Objective report)

[Adam Samalik]

Yeah, that's a good point. I might rename the repo as well. Thanks for the
suggestion!

On Fri, Aug 23, 2019 at 1:15 PM Dusty Mabe  wrote:

>
>
> On 8/23/19 6:35 AM, Dominik 'Rathann' Mierzejewski wrote:
> > Hi, Adam.
> >
> > On Wednesday, 21 August 2019 at 15:41, Adam Samalik wrote:
> > [...]
> >> == Toolbox ==
> >>
> >> The 'showme' tool [3] for visualising and inspecting RPM dependencies
> >> now supports weak dependencies and a package list output.
> >
> > I didn't have a chance to tell you this at Flock, but could you rename
> > the binary to something like rpm-showme? Plain showme is very generic
> > and unsuitable for such a specific tool.
> >
>
> I agree. It also means people are less likely to "discover" the tool and
> must be told about it or otherwise find it through indirect searches.
>
> Dusty
> ___
> 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
>


-- 

Adam Šamalík
---
Senior Software Engineer
Red Hat
___
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

Laptop powerdown when early boot incl. bootloader phase stuck (Was: Bug 1742953 - No Screensaver/Powerdown after Inactivity at LUKS Password Prompt)

[Jan Pokorný]

On 20/08/19 20:59 -0600, Chris Murphy wrote:
> There is no good reason for the current behavior, in particular on a
> laptop. And it's fail danger, not fail safe. The very simple work
> around for the computer shutting off in 3 minutes of inactivity and
> you don't like that? Power it back on and enter your passphrase.
> Shockingly easy and obvious. Unless of course you're stuck somewhere
> and in fact want to use your laptop as a heating pad.

Just that the particular corner case is not perceived in isolation,
there are other early-boot-stuck situations that would make sense
to deal with in the same fashion even if the sources are completely
different (predictability is more important from user's POV, IMHO).

One such other situation is having the bootloader (grub2) failed and
hence be stuck in 'press a key to continue' or just staying in the
selection menu without any timeout ticking for whatever reason.
That's directly comparable to the LUKS prompt without any attention
for a prolonged time.

With grub2, situation is actually worse, since without having any
means to control CPU throttling (which is already present by the
time one is to enter LUKS password), laptop will indeed become
said "heating pad" after a bit (one could for instance enter the
grub prompt if it's deemed a feature for some).

-- 
Poki


pgpfidGgFp6BI.pgp
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: i686 hw builders running out of ram in cpio?

[Panu Matilainen]

On 7/19/19 8:29 AM, John Reiser wrote:

Anyone else seeing this?  It seems to only happen on physical i686
machines, not vm's, but that's based on only three builds so far.

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

BUILDSTDERR: create archive failed: cpio: write failed - Cannot 
allocate memory


Very similar to  https://bugzilla.redhat.com/show_bug.cgi?id=1729382


This should be fixed as of rpm >= 4.15.0-0.beta.4, apologies for the 
long delay in addressing it.


- Panu -
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Help update Hugo

[Dusty Mabe]

On 8/22/19 12:46 AM, Robert-André Mauchin wrote:
> Hello,
> 
> Feel free to help review these packages needed to update Hugo:
> 

Thanks for the effort here Robert-André. I might be able to help
with a few of these since I use Hugo. Will let you know next week.

Dusty 
___
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: 'showme' RPM dependency visualizer (was: Minimization Objective report)

[Dusty Mabe]

On 8/23/19 6:35 AM, Dominik 'Rathann' Mierzejewski wrote:
> Hi, Adam.
> 
> On Wednesday, 21 August 2019 at 15:41, Adam Samalik wrote:
> [...]
>> == Toolbox ==
>>
>> The 'showme' tool [3] for visualising and inspecting RPM dependencies
>> now supports weak dependencies and a package list output.
> 
> I didn't have a chance to tell you this at Flock, but could you rename
> the binary to something like rpm-showme? Plain showme is very generic
> and unsuitable for such a specific tool.
> 

I agree. It also means people are less likely to "discover" the tool and
must be told about it or otherwise find it through indirect searches.

Dusty 
___
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: fedora-gpg-keys not updated yet again

[Dusty Mabe]

On 8/22/19 12:58 PM, Kevin Fenzi wrote:
> On 8/21/19 9:27 AM, Dusty Mabe wrote:
>>
>>
>> On 8/19/19 6:59 AM, Pavel Raiskup wrote:
>>> On Monday, August 19, 2019 10:50:52 AM CEST Zbigniew Jędrzejewski-Szmek 
>>> wrote:
 Can we *please* send out the FN+1 and FN+2 keys a month before branching,
 to *all* releases of Fedora, so we can avoid this pointless scramble?
>>>
>>> What about to have F33 keys right now, when the fresh F31 branch is out?
>>>
>>
>> +1. Go ahead and make the f33 keys when we branch for f31. 
> 
> I don't see how this helps any. I agree we should push out the f33 keys
> before next branching, but why now?
> 

For me it solves any "timing" issues. We often get into a state where we're
trying to upgrade to something that is signed with a key we don't have yet.

With ostree we hit this every time we branch. Here is where a user hit it this
time: 
https://discussion.fedoraproject.org/t/unable-to-update-gpg-signatures-found-but-none-are-in-trusted-keyring/2703/3?u=dustymabe

There could be other problems that won't be solved but if we get the key out
now for the next release we'll at least solve any races and problems like this.

Dusty 
___
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: Lines disordered in mock's build.log

[Panu Matilainen]

On 7/1/19 3:54 PM, Miro Hrončok wrote:

Hello,

I've noticed that last couple of weeks, I see disordered lines in mock's 
build.log. This happens constantly in local mock, copr and Koji. Example:



[...]
See the "error: Bad exit status from /var/tmp/rpm-tmp.yUtVju (%check)" 
part in the middle of %check output.


Has something changed? Or is it an rpm 4.15 thing?


It was indeed a regression introduced in 4.15, and should be now fixed 
as of rpm >= 4.15.0-0.beta.3


The fix is upstream already but test-driving it in rawhide for a few 
days prior to rc1 release (next week), please report any new anomalies 
ASAP if you encounter them.


- Panu -
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[EPEL-devel] Rules for shadowing RHEL packages with EPEL modules

[Petr Pisar]

If I read the EPEL 8 annoucement correctly, it's still not possible to build
modules in EPEL. Nevertheless I'd like to know how the rules about "not
replacing RHEL content" will apply to modules. Here are my question:

Case: RHEL delivers an M module with a default S1 stream. There is no S2
stream. Can I add a new S2 stream into EPEL? I guess this will be allowed. If
later RHEL introduces S2 stream, I guess EPEL will remove the S2 module.

Case: RHEL delivers an M module with no default stream, there is no S stream.
Can I add a new S stream into EPEL and make it default? I'm not sure this will
be allowed. There is a risk of creating conflicts between streams transitively
required by another default streams. (Remember the libgit2 module conflict
.)

Case: RHEL delivers a non-modular P package. There is no S stream of
a M module. Can I add a new M module with a new S stream that will contain
a modular P package? I guess it will be allowed. Can I make the stream
default? I guess that won't be allowed.

Case: RHEL delivers a P package. Can I build a modular P package when building 
a new module stream in EPEL only for the purpose of building the module
and then filter out the P package from the module (i.e. a build-only module
component) so that the P package does not get into EPEL repository? I guess
this will be allowed.

Could EPEL product owner (or whoever makes and assert the rules) clarify?
I need to know that to choose the easiest and yet conforming strategy for
adding new modules into EPEL, especially when dealing with RHEL packages
unavailable for some module contexts.

-- Petr


signature.asc
Description: PGP signature
___
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

'showme' RPM dependency visualizer (was: Minimization Objective report)

[Dominik 'Rathann' Mierzejewski]

Hi, Adam.

On Wednesday, 21 August 2019 at 15:41, Adam Samalik wrote:
[...]
> == Toolbox ==
> 
> The 'showme' tool [3] for visualising and inspecting RPM dependencies
> now supports weak dependencies and a package list output.

I didn't have a chance to tell you this at Flock, but could you rename
the binary to something like rpm-showme? Plain showme is very generic
and unsuitable for such a specific tool.

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
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

[Bug 1744676] [RFE] EPEL8 branch of perl-BSD-Resource

[bugzilla]

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



--- Comment #5 from Petr Pisar  ---
(In reply to Jan Pazdziora from comment #4)
> If I get EPEL 8 branch created today and just build the module,

Here you mean a Perl module as non-modular RPM package.

> will it build (correctly) against the default module (5.26)

And here you mean a Modularity module.

> and at least users of the default perl will be happy?

Yes. That works. If you do not want to wait for EPEL supporting building
modules, do that (i.e. build a normal RPM package).

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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

[Bug 1735227] fusioninventory-agent: FTBFS in Fedora rawhide/f31: File not found: /builddir/build/BUILDROOT/fusioninventory-agent-2.5.1-3.fc31.arm/etc/fusioninventory/proxy-server-plugin.cfg

[bugzilla]

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



--- Comment #8 from Petr Pisar  ---
(In reply to Petr Pisar from comment #7)
> You also need to build it for Fedora 32.

You don't. This an old build before branching F31.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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

[Bug 1735227] fusioninventory-agent: FTBFS in Fedora rawhide/f31: File not found: /builddir/build/BUILDROOT/fusioninventory-agent-2.5.1-3.fc31.arm/etc/fusioninventory/proxy-server-plugin.cfg

[bugzilla]

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



--- Comment #7 from Petr Pisar  ---
You also need to build it for Fedora 32.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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

[Bug 1744676] [RFE] EPEL8 branch of perl-BSD-Resource

[bugzilla]

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



--- Comment #4 from Jan Pazdziora  ---
I'm not sure I understand the situation correctly. If I get EPEL 8 branch
created today and just build the module, will it build (correctly) against the
default module (5.26) and at least users of the default perl will be happy? Or
will even this approach fail without the module support in EPEL? Or will it
work but make things harder in the future when the module support gets to EPEL
and we will want to do the rebuilds for the other modules?

I guess perl-devel is the reasonable venue.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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

[Bug 1735227] fusioninventory-agent: FTBFS in Fedora rawhide/f31: File not found: /builddir/build/BUILDROOT/fusioninventory-agent-2.5.1-3.fc31.arm/etc/fusioninventory/proxy-server-plugin.cfg

[bugzilla]

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

maria...@tuxette.fr  changed:

   What|Removed |Added

 Status|NEW |CLOSED
 Resolution|--- |RAWHIDE
Last Closed||2019-08-23 09:02:39



--- Comment #6 from maria...@tuxette.fr  ---
Solved by https://bodhi.fedoraproject.org/updates/FEDORA-2019-0d81816e61

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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

[Bug 1744686] [RFE] EPEL8 branch of perl-Role-Tiny

[bugzilla]

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

Paul Howarth  changed:

   What|Removed |Added

 Status|NEW |CLOSED
 Resolution|--- |NOTABUG
Last Closed||2019-08-23 08:57:44



--- Comment #1 from Paul Howarth  ---
The perl-Role-Tiny package is in the codeready-builder-for-rhel-8 channel and
therefore cannot be built in EPEL-8 as it would replace a rhel-8 package.

The EPEL plan for perl is mentioned here:
https://lists.fedoraproject.org/archives/list/epel-de...@lists.fedoraproject.org/thread/HXFHAPXPG2FX4NHP2WDNE3J3JXE53LML/

Currently there is no non-default module/AppStream support in EPEL-8 so
everything is built in a monolithic repo against default module streams. This
means that any perl packages get built against the perl 5.26 stream and not the
perl-5.24 stream. Somewhere down the line that may change but I doubt it'll
happen any time soon.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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

[Bug 1744676] [RFE] EPEL8 branch of perl-BSD-Resource

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

  Flags|needinfo?(ppi...@redhat.com |
   |)   |



--- Comment #3 from Petr Pisar  ---
The only information I have is
.
My interpretation is that it's not possible to build Modularity modules in EPEL
8.

And there is yet another issue: There are a few Perl packages modularized in
RHEL. I'm sure people will want EPEL to provide their modularized rebuilds, so
that users can switch to a different perl and still enjoy all the other Perl
packages. A straightforward implementation is copying sources from CentOS to
EPEL, wrapping them with a module and building the module in EPEL 8 while
letting a stream expansion to build it for all perls. The downside is that the
modular package would mask RHEL package. That was forbidden in EPEL 7 and I
believe the same rule will apply to EPEL 8. There are few ways how to deal with
it but none of them is simple. We need to clarify it with EPEL project owner
and choose a right strategy in Perl/EPEL sig. I'd like to elaborate about it
more in some list. Do you prefer Fedora's perl-devel or EPEL's epel-devel? I'd
rather use perl-devel for discussing the strategy.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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: fedora-gpg-keys not updated yet again

[Kamil Paral]

On Fri, Aug 23, 2019 at 10:39 AM Vít Ondruch  wrote:

>
> Dne 22. 08. 19 v 18:57 Kevin Fenzi napsal(a):
>
> On 8/21/19 3:24 AM, Vít Ondruch wrote:
>
>
> That is not completely true. The only possible way is to update the
> `fedora-gpg-keys` first without anything else and that was the reason
> for [1]. But since [1] did not landed in Fedora prior the branch, there
> is no way to update Rawhide and keep everything Rawhide and at the same
> time keep checking signatures all the time.
>
> But you could upgrade to the f31 version and then to rawhide.
>
> IOW prior branch, I had installed fedora-repos-31-0.2 together with
> fedora-gpg-keys-31-0.2. As long as there was no F31 compose, there was
> available fedora-repos-32-0.2 together with fedora-gpg-keys-32-0.2 (or
> 0.1, it does not really matter), but those were not possible to install,
> because they are signed by F32 GPG key, which is not available on my
> system yet. The fedora-repos-31-0.5 is the first post branch package
> signed with the key on my system. This allows me to install
> fedora-gpg-keys-31-0.5 but at the same time it changes the configuration
> of /etc/yum.repos.d/fedora{,-rawhide}.repo making the system F31 instead
> of Rawhide. And this is wrong.
>
> Wrong how? What do you want there?
>
>
> My system is Rawhide and should stay Rawhide. I don't want to stay on F31
> by mistake. I don't ever wan't to install anything from stable branch.
>
>
> Most/many people want to folow the
> branch, so thats what we have always done there.
>
>
> Some people want, but I doubt it is majority. It makes no sense to
> suddenly switch from Rawhide to F31. Rawhide should be always Rawhide and
> switching to stable branch should be conscious decision.
>
>
> In any event, hopefully soon we will have rawhide named rawhide and not
> 31 or 32 and with that you can indicate what you want to do much more
> clearly.
>
>
> Looking forward to this.
>

External testing is very welcome:
https://pagure.io/releng/issue/7445
https://copr.fedorainfracloud.org/coprs/kparal/rawhide-releasever/

This will also have the effect that Rawhide installation will always stay
Rawhide, and you'll need to explicitly switch to Branched, if you want to
do so.
___
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: fedora-gpg-keys not updated yet again

[Vít Ondruch]

Dne 22. 08. 19 v 18:57 Kevin Fenzi napsal(a):
> On 8/21/19 3:24 AM, Vít Ondruch wrote:
>
>> That is not completely true. The only possible way is to update the
>> `fedora-gpg-keys` first without anything else and that was the reason
>> for [1]. But since [1] did not landed in Fedora prior the branch, there
>> is no way to update Rawhide and keep everything Rawhide and at the same
>> time keep checking signatures all the time.
> But you could upgrade to the f31 version and then to rawhide.
>> IOW prior branch, I had installed fedora-repos-31-0.2 together with
>> fedora-gpg-keys-31-0.2. As long as there was no F31 compose, there was
>> available fedora-repos-32-0.2 together with fedora-gpg-keys-32-0.2 (or
>> 0.1, it does not really matter), but those were not possible to install,
>> because they are signed by F32 GPG key, which is not available on my
>> system yet. The fedora-repos-31-0.5 is the first post branch package
>> signed with the key on my system. This allows me to install
>> fedora-gpg-keys-31-0.5 but at the same time it changes the configuration
>> of /etc/yum.repos.d/fedora{,-rawhide}.repo making the system F31 instead
>> of Rawhide. And this is wrong.
> Wrong how? What do you want there?


My system is Rawhide and should stay Rawhide. I don't want to stay on
F31 by mistake. I don't ever wan't to install anything from stable branch.


> Most/many people want to folow the
> branch, so thats what we have always done there.


Some people want, but I doubt it is majority. It makes no sense to
suddenly switch from Rawhide to F31. Rawhide should be always Rawhide
and switching to stable branch should be conscious decision.


>
> In any event, hopefully soon we will have rawhide named rawhide and not
> 31 or 32 and with that you can indicate what you want to do much more
> clearly.


Looking forward to this.


>
>> But it should be better next time, because [1] finally landed. It allows
>> to update fedora-gpg-keys without updating fedora-repos. That means it
>> should be possible to get the new Rawhide keys and then keep updating
>> from Rawhide repository.
> You can still update both and just change the repo configs the way you
> want as well.


I could do a lot of things, but ideally I should do nothing else then
"dnf update", because I am using Rawhide.


Vít


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


signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1744676] [RFE] EPEL8 branch of perl-BSD-Resource

[bugzilla]

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

Jan Pazdziora  changed:

   What|Removed |Added

  Flags||needinfo?(ppi...@redhat.com
   ||)



--- Comment #2 from Jan Pazdziora  ---
Petr, do I read it right that any building of Perl modules in EPEL 8 is
effectively on hold until the module support comes to EPEL? I've had requests
for other modules, so would like to make sure I'm spreading the correct
message.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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

[Bug 1744676] [RFE] EPEL8 branch of perl-BSD-Resource

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 CC||ppi...@redhat.com



--- Comment #1 from Petr Pisar  ---
EPEL does not support modules. Module support in EPEL is planned later (a
tentative deadline was articulated as "EPEL-8.1").

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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