ABI change announce svt-vp9

[Vascom]

ABI changed in svt-vp9 0.1.1 release.
All changes 
https://taskotron.fedoraproject.org/artifacts/all/6720382c-ebf1-11e9-904f-52540077ca13/tests.yml/svt-vp9-0.1.1-1.fc32.log
___
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: Modularity and the system-upgrade path

[Daniel Mach]

On 10/7/19 8:55 PM, Simo Sorce wrote:

I have to ask,
given containers are so popular and can deal with any dependency
without conflicting with system installed binaries, should we really
continue with this very complicated modular design ?


There are only few people who fully understand how modularity works 
today (contyk who designed modulemd, jmracek and me who implemented the 
DNF part and few others). I agree that the modular design should be 
simplified. If we don't lower the bar, the complexity might prevent from 
wider adoption.


As a former release engineer, I'm personally unhappy about lack of 
upgrade paths between module contexts and I believe that fixing this 
part of modularity design could lead to desired simplification. 
Unfortunately based on discussion I had with contyk yesterday, I don't 
believe it's achievable without making *huge* changes in the modularity 
design and the build infrastructure/process.




Shouldn't we go back to have default packages and then defer to
"containers" for applications (and their dependencies) that need to
deviate from system defaults for any reason ?


I don't think containers can replace modularity. They need to coexist. 
If we want to create containers built on top of a distribution (no 
randomly picked bits from the internet, reproducible builds, security, 
...), we need a way to distribute multiple versions of the software 
(module streams) and they frequently need to be built against each other 
 (module contexts).





Simo.

On Fri, 2019-10-04 at 10:57 -0400, Stephen Gallagher wrote:

Right now, there are two conflicting requirements in Fedora Modularity
that we need to resolve.

1. Once a user has selected a stream, updates should follow that
stream and not introduce incompatiblities. Selected streams should not
be changed without direct action from the user.
2. So far as possible, Modularity should be invisible to those who
don't specifically need it. This means being able to set default
streams so that `yum install package` works for module-provided
content.

Where this becomes an issue is at system-upgrade time (moving from
Fedora 30->31 or continuously tracking Rawhide). Because of
requirement 1, we cannot automatically move users between streams, but
in the case of release upgrades we often want to move to a new default
for the distribution.


The Modularity WG has generally agreed that we want and need to
support behavior of the following use-cases:


Use Case 1:

On Fedora 30, user Alice runs

yum install Foo

The package "Foo" is provided by a module "foo" with a default stream
"v1.0". Because it's available in a default stream, the package is
installed and the module stream "foo:v1.0" is implicitly enabled for
the system.



Fedora 31 is released. On Fedora 31, the module "foo" has a new
default stream "v1.1". When upgrading from Fedora 30 to Fedora 31,
Alice expects the package Foo she installed to be upgraded to version
1.1, because that's what would have happened if it was provided as a
package from the non-modular repositories.



Use Case 2:

On Fedora 30, user Bob runs

yum enable foo:v1.0

In this case, the "v1.0" stream of the "foo" module has a dependency
on the "v2.4" stream of the "bar" module. So when enabling "foo:v1.0",
the system also implicitly enables "bar:v2.4".



Fedora 31 is released. On Fedora 31, the module stream "foo:v1.0" now
depends on "bar:v2.5" instead of "bar:v2.4". The user, caring only
about "foo:v1.0" would expect the upgrade to complete, adjusting the
dependencies as needed.


At Flock and other discussions, we've generally come up with a
solution, but it's not yet recorded anywhere. I'm sending it out for
wider input, but this is more or less the solution we intend to run
with, barring someone finding a severe flaw.

Proposed Solution:

What happens today is that once the stream is set, it is fixed and
unchangeable except by user decision. Through discussions with UX
folks, we've more or less come to the decision that the correct
behavior is as follows:

* The user's "intention" should be recorded at the time of module
enablement. Currently, module streams can exist in four states:
"available, enabled, disabled, default". We propose that there should
be two additional states (names TBD) representing implicit enablement.
The state "enabled" would be reserved for any stream that at some
point was enabled by name. For example, a user who runs `yum install
freeipa:DL1` is making a conscious choice to install the DL1 stream of
freeipa. A user who runs `yum install freeipa-client` is instead
saying "give me whatever freeipa-client is the default".

* The state `dep_enabled` would be set whenever a stream becomes
enabled because some other module stream depended on it. This state
must be entered only if the previous state was `default` or
`available`. (We don't want `enabled` or `disabled` streams being able
to transition to this state.)

* The state `default_enabled` would be set whenever a stream becomes

Re: koji web interface is very slow

[Dominik 'Rathann' Mierzejewski]

On Friday, 11 October 2019 at 04:36, Orion Poplawski wrote:
> On 10/10/19 4:57 PM, Orion Poplawski wrote:
> > On 10/10/19 9:23 AM, Kevin Fenzi wrote:
[...]
> > > Pretty please can you all indicate approximately when (UTC) you were
> > > seeing the slowness? I suspect it may be the nightly database dump job,
> > > but I can't tell without knowing when you saw the slowness...
[...]
> > Thanks, it is much better now.  I feel like I've hit periods of slowness
> > over several days recently so I will definitely note times if I run into
> > it again.
> 
> Definitely slower again:
> Fri Oct 11 02:20:53 UTC 2019

Fri 11 Oct 09:11:01 UTC 2019
It takes 30s to show a build status page, e.g.
https://koji.fedoraproject.org/koji/taskinfo?taskID=38215205

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

Re: Defining the future of the packager workflow in Fedora

[Stephen John Smoogen]

On Thu, 10 Oct 2019 at 20:33, Kevin Kofler  wrote:
>
> Matthew Miller wrote:
> > On Thu, Oct 10, 2019 at 12:28:37AM +0200, Kevin Kofler wrote:
> >> The problem does not only happen if the module is a non-leaf at module
> >> level, but there can also be conflicts at package level, if the modules
> >> bundle non-leaf packages that then conflict between the 2 modules.
> >
> > Yes. I'm less worried about that because I think containerization is the
> > right answer for most of these cases. I realize that reasonable people can
> > disagree with me on this, but it's definitely the general trend on
> > servers, devices, and desktops.
>
> And I think you are absolutely wrong, for the reasons I have already stated
> in:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/LODBTWKZAKR2XPW2AAVVGFKYQH24FLKF/
>
> I shall also point out that there is no difference between module-level
> conflicts and package-level conflicts there: both can be "solved" by
> containerizing the conflicting modules. But this is a very heavy workaround
> for a conflict that is really the distribution's job to avoid. (I would even
> argue that this is even the whole purpose of a distribution, as opposed to
> just downloading random software directly from random sources.)

In agreement with Kevin more than I would expect. [I don't like the
absolute wrong part, but the lower paragraph is where I find
agreement] I truly believe containers are just micro-distributions and
they have exactly the  same social problems that a distribution are
meant to deal with.  it is just that they are so new and wow that most
people just think we can have infinite resources and hopes on it..
just like we did when you had thousands of linux distributions and
dozens new ones every day.




-- 
Stephen J Smoogen.
___
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: Modularity and the system-upgrade path

[Robbie Harwood]

Chris Murphy  writes:

> On Fri, Oct 11, 2019 at 6:57 AM Simo Sorce  wrote:
>> On Fri, 2019-10-11 at 09:56 +0200, Daniel Mach wrote:
>>> On 10/7/19 8:55 PM, Simo Sorce wrote:
 I have to ask, given containers are so popular and can deal with
 any dependency without conflicting with system installed binaries,
 should we really continue with this very complicated modular design
 ?
>>>
>>> There are only few people who fully understand how modularity works
>>> today (contyk who designed modulemd, jmracek and me who implemented
>>> the DNF part and few others). I agree that the modular design should
>>> be simplified. If we don't lower the bar, the complexity might
>>> prevent from wider adoption.
>>
>> Yes, at the moment it is a too complex system.
>
> Do you gain something out of that complexity that's worth it? Or is
> that an open question? And is it a design requirement?
>
>>> As a former release engineer, I'm personally unhappy about lack of
>>> upgrade paths between module contexts and I believe that fixing this
>>> part of modularity design could lead to desired simplification.
>>> Unfortunately based on discussion I had with contyk yesterday, I
>>> don't believe it's achievable without making *huge* changes in the
>>> modularity design and the build infrastructure/process.
>>
>> Well, the way I see it, if it is not usable we shouldn't inflict it
>> on users unless there is a clear and overwhelming technical advantage
>> in doing it. So far it eludes me what advantage modularity gives that
>> is so important.
>
> As a contrarian, I'd be suspicious if there's complete agreement on
> any new thing. Do you disagree with the stated advantages of
> modularity? Or do you not understand the advantages of modularity? Do
> you think modularity is a solution in search of a problem? i.e. you
> don't even agree or understand the stated problem modularity is
> intended to solve, even before the questions of whether modularity
> adequately addresses the problem(s)?

I believe the point most of us are struggling with is: there's no
definition of what advantages of modularity are.  There may or may not
be some idea of what the advantages could be, which is a different
thing.  This makes it really hard to argue whether it is or isn't
succeeding when there isn't a criteria for success.

Lack of such information places it firmly in the class of "solution in
search of a problem".

Thanks,
--Robbie


signature.asc
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: Modularity and the system-upgrade path

[Alexander Scheel]

- Original Message -
> From: "Neal Gompa" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Friday, October 11, 2019 2:36:58 PM
> Subject: Re: Modularity and the system-upgrade path
> 
> On Fri, Oct 11, 2019 at 8:50 AM Stephen Gallagher 
> wrote:
> >
> >
> >
> > On Thu, Oct 10, 2019 at 10:41 AM Lukas Ruzicka  wrote:
> >>
> >> Seeing the reaction of the Modularity WG ... I do not understand how it is
> >> possible that such important decisions are taken by 4 people without any
> >> Fedora wide discussions like this. And yet, it seems a little bit that
> >> even opinions on this list will not fall on fertile grounds.
> >
> >
> >
> > To be clear, I am reading every single reply to this thread very carefully.
> > We *will* be taking all of this feedback into consideration, but please
> > understand that we're also trying to balance things. As Neal noted
> > upthread, we do have a responsibility to our downstream to make sure that
> > we do not break the ability to manage default streams. This becomes much
> > more difficult if we cannot have them in Fedora, because the testing of
> > them is lost. Additionally, no one on the WG disagrees with you that the
> > current state of things is undesirable. I take a moderate amount of
> > offense to the repeated insinuations that the solutions we are building
> > are "hacks". Yes, there's a proposal to work around the upgrade issue to
> > F31 that is absolutely a one-off hack to buy time. But our plans for how
> > upgrades should work long-term as well as how defaults need to behave in
> > the distro are being considered very carefully. We are trying to avoid
> > breakage and to make the process simpler, but we are also shoring up the
> > bridge while crossing it.
> >
> 
> Two years into this, I am currently not confident that modularity will
> be adapted to support community distributions well, especially
> fast-paced ones like Fedora. My fears about it encouraging Fedora to
> slow down has also seemingly borne fruit, too. Java is proof positive
> of this.
> 
> Since the implosion of Fedora Java in the regular distribution and its
> move to modules, the traditional effort to move to newer Java versions
> has basically disappeared. Java 11 LTS was released last year, and to
> this day our default Java is still Java 8 (which is EOL!). Clearly,
> we're developing a new antipattern that we need to nip in the bud
> sooner rather than later.

Not going to argue that we're well behind here, but to my knowledge,
the Stewardship SIG maintains just about everything you'd find in a
useless modular repo (e.g., packages that are outside of the default
module stream's limited API) as an ursine package. We try not to
duplicate too much of what's provided in the default module streams.
So the claim that Java has imploded in the regular distribution are
a little bit of a stretch.

Then again, I don't use eclipse and most of my projects use CMake, not
maven so I don't miss either of those major projects. I'm mostly talking
about the vast swatches of Java libraries... :)

> 
> My disappointment in this became even greater when openSUSE beat us to
> switching to Java 11. Their packaging is derived from ours! They've
> demodularized Java for openSUSE and then did the work to move
> everything forward. Meanwhile, we've now failed at our "first" and
> "features" pillars because the incentive is now *gone*.

The Stewardship SIG does its best to update packages, but doesn't
have the resources to fully switch to JDK 11 ourselves. That's really
up to the Java SIG. Also, there's really nothing to do to demodularize
a package. Just choose a branch and build it as an ursine package...
___
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: koji web interface is very slow

[Orion Poplawski]

On 10/11/19 12:20 PM, Kevin Fenzi wrote:
> So to update this thread some: 
> 
> * Load is fine/responsiveness is fine as long as we aren't doing a
> database dump.
> * When we do, things slow down and load goes way up. 
> 
> We did find one very odd/bad thing on the virthost the server is on (one
> drive in the raid is showing active in multipath and possibly getting
> copies of all i/o sent to it? unclear exactly, but it's wrong and needs
> fixing). 
> 
> So, we stopped the backup and we are going to wait until 21UTC 
> (after 5pm EDT). At that point we will try and clean up that multipath
> issue and see if that helps things. If not we will try and tune the
> vm/database more until we have it responsive all the time. 
> We hope we can do these changes with minimal to no downtime, but there
> may be some. 
> 
> I've filed https://pagure.io/fedora-infrastructure/issue/8292 on this
> issue, folks are welcome to follow along there. 
> 
> Sorry about all this, I was just hoping to make things faster and sadly,
> did not. 
> 

Thanks for working on this, your help is greatly appreciated.


-- 
Orion Poplawski
Manager of NWRA Technical Systems  720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301 https://www.nwra.com/



smime.p7s
Description: S/MIME Cryptographic 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

[Test-Announce] 2019-10-14 @ 16:00 UTC - Fedora 31 Blocker Review Meeting

[Adam Williamson]

# F31 Blocker Review meeting
# Date: 2019-10-14
# Time: 16:00 UTC
# Location: #fedora-blocker-review on irc.freenode.net

Hi folks! We have 6 proposed Final blockers and 11 proposed Final freeze
exception to review, so let's have a Fedora 31 blocker review meeting
on Monday!

If you have time today, you can take a look at the proposed or
accepted blockers before the meeting -  the full lists can be found
here: https://qa.fedoraproject.org/blockerbugs/ .

We'll be evaluating these bugs to see if they violate any of the 
Release Criteria and warrant the blocking of a release if they're not 
fixed. Information on the release criteria for F31 can be found on the 
wiki [0].

For more information about the Blocker and Freeze exception process, 
check out these links:
 - https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process
 - https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process

And for those of you who are curious how a Blocker Review Meeting 
works - or how it's supposed to go and you want to run one - check out 
the SOP on the wiki:
 - https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting

Have a good weekend and see you on Monday!

[0] https://fedoraproject.org/wiki/Fedora_Release_Criteria
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test-annou...@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: Modularity and the system-upgrade path

[Stephen John Smoogen]

On Fri, 11 Oct 2019 at 14:29, Chris Murphy  wrote:
>

> > My main gripe is the current situation where users are thrown under the
> > bus and then we give them a business card and say: read these
> > instruction to figure out how to save yourself.
> > I think this is unacceptable.
>
> Ordinary every day user or do you mean packagers being thrown under
> the bus. And really then, is there a difference because neither the
> mortal user or immortal packager should be thrown under the bus, when
> we get right down to it. That's certainly not a design tolerance. Too
> much trust in dnf has been built up for that to happen. It's natural
> and necessary any possibility of that be resisted.
>
> And I don't actually know any of the parameters under discussion. I
> don't even understand RPM let alone modularity. Every time I approach
> packaging I find too many barriers to entry, or at least something
> else that seems more interesting. I'm quite content with dnf and
> packagers doing the work. Is there a shrinking packager problem?
>

There has been a shrinking packager problem for years due to multiple problems
1. A lot of packagers were doing this as volunteer time, and that is a
limited resource. You get sick, you get tired, you have a work
deadline, etc and then you find yourself 2-3 releases behind and not
feeling like looking at 200 bugzilla's.
2. A lot of packages needed more development work than a packager
could pursue. If I packaged up xtank because i loved the game, and was
able to fix a couple of things.. that is ok. However when it turns out
that it needs a lot of forward port work because Fedora moved to
X11R20 and the maintainers want to stick to Xorg for a bit longer..
you just let the bugzilla's pile up hoping it will sort itself.
3. For years there was a cross distro 'arms' race of 'our distro needs
as many packages as possible or no one will use it'. So you ended up
with some set of packages being pulled in which people were 'sort' of
interested in versus invested in.
4. Packaging is like making cheese, there are 2000 different ways to
do so and it is hard to know which ones are good. Trying to come up
with consensus at times or getting people to follow the consensus ends
up with tyres burning in the streets.
5. Getting reviews takes time and energy from reviewers. When you have
100 packages you absorbed from 4 different packagers.. you have little
time to look at someone else's and mentor them. So instead you have a
backlog of package reviews and probably people who are no longer
interested tied to it.
6. Package upstreams are a lot faster and change greatly. There are a
lot of software which will completely add a dozen new dependencies and
the packager has to rip out the embedded versions or find the versions
which work. Of course those versions rarely work with everything else
and you end up with conflicts between things. That is tiring and
people age out.

As packagers left for some reason or another, other packagers would
find that meant something they needed was going away and would take
that package. And like a death of a thousand papercuts, that meant
that those packagers also started to find their time eaten up so they
might have less time to mentor others. Then some of those people
burned out and you ended up with even more 'well I will take your 100
packages' added onto people.

Just to be clear, this isn't a problem with only Fedora. Debian,
OpenSuSE, etc are all facing the same problems as volunteers
interested in working on distributions are not a 'growing' percentage.
It also doesn't mean that it is the end of the world. It does mean we
have to be more clear about our limits and stick to them. Trying to
package up a lot (or all ) of software does not make sense for
multiple reasons. However the primary one is that most software was
never written to be integrated into an Operating System. It was
written as a universe of its own, and the developers dont' see it as
their job or vision to be tied to an OS. We can force all kind of
things to try to make it but each one takes time and energy from
people who are volunteering that effort and could be doing something
else.


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



-- 
Stephen J Smoogen.
___
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: 

Re: Modularity and the system-upgrade path

[Chris Murphy]

On Fri, Oct 11, 2019 at 6:57 AM Simo Sorce  wrote:
>
> On Fri, 2019-10-11 at 09:56 +0200, Daniel Mach wrote:
> > On 10/7/19 8:55 PM, Simo Sorce wrote:
> > > I have to ask,
> > > given containers are so popular and can deal with any dependency
> > > without conflicting with system installed binaries, should we really
> > > continue with this very complicated modular design ?
> >
> > There are only few people who fully understand how modularity works
> > today (contyk who designed modulemd, jmracek and me who implemented the
> > DNF part and few others). I agree that the modular design should be
> > simplified. If we don't lower the bar, the complexity might prevent from
> > wider adoption.
>
> Yes, at the moment it is a too complex system.

Do you gain something out of that complexity that's worth it? Or is
that an open question? And is it a design requirement?

>
> > As a former release engineer, I'm personally unhappy about lack of
> > upgrade paths between module contexts and I believe that fixing this
> > part of modularity design could lead to desired simplification.
> > Unfortunately based on discussion I had with contyk yesterday, I don't
> > believe it's achievable without making *huge* changes in the modularity
> > design and the build infrastructure/process.
>
> Well, the way I see it, if it is not usable we shouldn't inflict it on
> users unless there is a clear and overwhelming technical advantage in
> doing it. So far it eludes me what advantage modularity gives that is
> so important.

As a contrarian, I'd be suspicious if there's complete agreement on
any new thing. Do you disagree with the stated advantages of
modularity? Or do you not understand the advantages of modularity? Do
you think modularity is a solution in search of a problem? i.e. you
don't even agree or understand the stated problem modularity is
intended to solve, even before the questions of whether modularity
adequately addresses the problem(s)?



>
> > > Shouldn't we go back to have default packages and then defer to
> > > "containers" for applications (and their dependencies) that need to
> > > deviate from system defaults for any reason ?
> >
> > I don't think containers can replace modularity. They need to coexist.
> > If we want to create containers built on top of a distribution (no
> > randomly picked bits from the internet, reproducible builds, security,
> > ...), we need a way to distribute multiple versions of the software
> > (module streams) and they frequently need to be built against each other
> >   (module contexts).
>
> If modules were just an infrastructure artifact used to build
> containers (or spins, or any other useful delivery mechanism) I
> wouldn't be concerned, as then the people exposed to their complexity
> would be people that know what they are doing and can decide to buy in
> or not into the modules ecosystem.

I rather like the idea of them in flatpaks, where any problems are
limited to a particular flatpak, and can't affect the local system.

> My main gripe is the current situation where users are thrown under the
> bus and then we give them a business card and say: read these
> instruction to figure out how to save yourself.
> I think this is unacceptable.

Ordinary every day user or do you mean packagers being thrown under
the bus. And really then, is there a difference because neither the
mortal user or immortal packager should be thrown under the bus, when
we get right down to it. That's certainly not a design tolerance. Too
much trust in dnf has been built up for that to happen. It's natural
and necessary any possibility of that be resisted.

And I don't actually know any of the parameters under discussion. I
don't even understand RPM let alone modularity. Every time I approach
packaging I find too many barriers to entry, or at least something
else that seems more interesting. I'm quite content with dnf and
packagers doing the work. Is there a shrinking packager problem?

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

Way to visualize where Fedora contributors are around the world?

[Richard Shaw]

Just a random thought I had but I actually have no idea which
contributors/packagers are closest to me here in Mississippi, USA.

That got me thinking it would be pretty neat if a map could be
automagically creating showing where everyone is. Wouldn't need exact
addresses for privacy reasons but something that gets you close like a zip
code (or equivalent).

Thoughts?

Thanks,
Richard
___
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: Modularity and the system-upgrade path

[Adam Williamson]

On Fri, 2019-10-11 at 14:42 -0400, Robbie Harwood wrote:
> 
> I believe the point most of us are struggling with is: there's no
> definition of what advantages of modularity are.  There may or may not
> be some idea of what the advantages could be, which is a different
> thing.  This makes it really hard to argue whether it is or isn't
> succeeding when there isn't a criteria for success.

Well, there's various places that provide a fairly 'official'
definition of what the advantages are supposed to be. E.g. the
Modularity docs site has a FAQ section where this is the first
question: "Exactly what problem are you trying to solve?"

https://docs.fedoraproject.org/en-US/modularity/faq/

"Deploying software has many solutions, but what gets deployed often
plays out as a fight between developers and operators. Developers want
the latest (or at least later) features. Operators want software in
packages, certified, with a known period of support. Fedora Modularity
provides multiple versions of packages in a Linux distribution with the
qualities expected from a Linux distribution: transparently built and
delivered, actively maintained, and easy to install — making both
happy."

The "Modules for Everyone" Change also had a "Benefit to Fedora"
section, as it was required to:

https://fedoraproject.org/wiki/Changes/ModulesForEveryone#Benefit_to_Fedora

"Fedora users will have access to a wider range of software choices
than they had previously. Fedora Packagers will be able to use modules
and module defaults to build each stream once and have it available for
any supported Fedora release they wish. They will no longer need to
duplicate that work for both the modular and non-modular repositories."

The 'Fedora Modularization' objective also defines a goal:

https://fedoraproject.org/wiki/Objectives/Fedora_Modularization_%E2%80%94_The_Release#Goal

"Modularity will transform the all-in-one Fedora OS into an operating
system plus a module repository, which will contain a wide selection of
software easily maintained by packagers. This iteration of the
Objective focuses on the second part — providing a wide selection
software in various versions — while laying the groundwork for the
first."

I think those texts taken together give a reasonable account of what
modularity is *supposed* to be doing for us, so we can at least attempt
to then ask and answer the question "is it actually achieving these
things"?
-- 
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: Way to visualize where Fedora contributors are around the world?

[Richard Shaw]

On Fri, Oct 11, 2019 at 1:51 PM Neal Gompa  wrote:

> On Fri, Oct 11, 2019 at 2:48 PM Richard Shaw  wrote:
> >
> > Just a random thought I had but I actually have no idea which
> contributors/packagers are closest to me here in Mississippi, USA.
> >
> > That got me thinking it would be pretty neat if a map could be
> automagically creating showing where everyone is. Wouldn't need exact
> addresses for privacy reasons but something that gets you close like a zip
> code (or equivalent).
> >
> > Thoughts?
> >
>
> That'd be neat! Funnily enough, until a few years ago, I also lived in
> Mississippi. :)
>

Hah... That's funny. I'm in the extreme NW corner and work in Memphis, TN.

Thanks,
Richard
___
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: Way to visualize where Fedora contributors are around the world?

[Orion Poplawski]

On 10/11/19 12:47 PM, Richard Shaw wrote:
> Just a random thought I had but I actually have no idea which
> contributors/packagers are closest to me here in Mississippi, USA.
> 
> That got me thinking it would be pretty neat if a map could be automagically
> creating showing where everyone is. Wouldn't need exact addresses for privacy
> reasons but something that gets you close like a zip code (or equivalent). 
> 
> Thoughts?

FWIW - Fedora Account allows you to enter your Lat/Lon coordinates.  This
isn't displayed in the view though.  But presumably a map could be built with
that.  I do like the idea.


-- 
Orion Poplawski
Manager of NWRA Technical Systems  720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301 https://www.nwra.com/



smime.p7s
Description: S/MIME Cryptographic 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

CPE Weekly: 2019-10-11

[Aoife Moloney]

Hi everyone,

Welcome to the CPE team weekly project update mail!


Background: The Community Platform Engineering group is the Red Hat team
combining IT and release engineering from Fedora and CentOS. Our goal is to
keep core servers and services running and maintained, build releases, and
other strategic tasks that need more dedicated time than volunteers can
give.

For better communication, we will be giving weekly reports to the CentOS
and Fedora communities about the general tasks and work being done.



Fedora:

Rawhide Gating:  


   -

   5.0 pre-release is ue in staging by hopefully the end of this week
   -

   New Koji has been deployed in production
   -

  https://pagure.io/fedora-infrastructure/issue/8244
  -

   Requests for side-tags via fedpkg seems to work
   -

  https://pagure.io/fedora-infrastructure/issue/8280
  -

   Createrepo for side tag in koji is now 45-seconds for a side-tag - this
   is lower than before, so making progress!
   -

  https://pagure.io/fedora-infrastructure/issue/8245
  -

   Fedora Messaging:
   -

  Ci-resultsdb-listener is waiting on ci.centos.org to be
  finished/deployed.
  -

  Fedora-messaging code has been merged
  -

  New release will support new message from the CI system


repoSpanner 


   -

   Increased push performance by 51%!


CentOS:


   -

The team is working with CERN about koji upgrade process for
   cbs.centos.org
   -

   CentOS CI
   -

  JMS messaging  plugin now in testing
  -

 Ack of messages is still missing but the fix is in progress
 -

 Both publishing & consuming are working
 -

   Mirrorlist code change for CentOS 8
   -

   Investigating a phpbb upgrade for www.centos.org/forums and
   fr.centos.org/forums hosts




Application Handover to Community


   -

   Elections: Blocked by this issue - PostgreSQL database is missing in
   application catalogue https://pagure.io/fedora-infrastructure/issue/8253
   -

   Badges: Thread has been started to get a decision with new maintainers
   -

   Packagedb-cli: Retired.
   -

   Pastebin: Ongoing conversations with future maintainer, expecting an
   update in the next week
   -

   Elections: Move to CommuniShift underway but blocked by this issue
   before complete
   -

   https://pagure.io/fedora-infrastructure/issue/8253
  -

   Fedocal:  Possible maintainer found & the team are/will engage to
   finalize
   -

  https://pagure.io/fedora-infrastructure/issue/8274
  -

  Deadline for commitment to maintain is still 15th October
  -

   Nuancier: Maintainer(s!) are identified and the team are engaging in a
   conversation :)
   -

  There is also a conversation happening
  

  in Fedora infra channel about changes in Nuancier.
  -

   Documentation for onboarding contributors to Community OpenShift still
   ongoing with a good mail thread on Fedora Devel



Misc highlights from various parts of the ecosystem:


   -

   FPDC: No Update
   -

   CI Initiative: Disg-git test of CentOS infra conversation happening here
   https://pagure.io/fedora-infrastructure/issue/8279
   
   -

   Bug in Koji plugin was resolved so sending signing messages has resumed.

https://pagure.io/fedora-infrastructure/issue/8158

   -

   cpe/infra-docs repo is being removed from pagure and we are now going to
   use infra-docs-pagure instead. Working with an active contributor in the
   repo to make sure there are no problems.
   -

   Final freeze started on Tuesday 8th October




As always, comments and feedback are more than welcome and we hope you are
finding these updates informative!


Have a great weekend!
Aoife

-- 

Aoife Moloney

Feature Driver

Community Platform Engineering Team

Red Hat EMEA 

Communications House

Cork Road

Waterford



-- 

Aoife Moloney

Feature Driver

Community Platform Engineering Team

Red Hat EMEA 

Communications House

Cork Road

Waterford

___
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: Modularity and the system-upgrade path

[Neal Gompa]

On Fri, Oct 11, 2019 at 8:50 AM Stephen Gallagher  wrote:
>
>
>
> On Thu, Oct 10, 2019 at 10:41 AM Lukas Ruzicka  wrote:
>>
>> Seeing the reaction of the Modularity WG ... I do not understand how it is 
>> possible that such important decisions are taken by 4 people without any 
>> Fedora wide discussions like this. And yet, it seems a little bit that even 
>> opinions on this list will not fall on fertile grounds.
>
>
>
> To be clear, I am reading every single reply to this thread very carefully. 
> We *will* be taking all of this feedback into consideration, but please 
> understand that we're also trying to balance things. As Neal noted upthread, 
> we do have a responsibility to our downstream to make sure that we do not 
> break the ability to manage default streams. This becomes much more difficult 
> if we cannot have them in Fedora, because the testing of them is lost. 
> Additionally, no one on the WG disagrees with you that the current state of 
> things is undesirable. I take a moderate amount of offense to the repeated 
> insinuations that the solutions we are building are "hacks". Yes, there's a 
> proposal to work around the upgrade issue to F31 that is absolutely a one-off 
> hack to buy time. But our plans for how upgrades should work long-term as 
> well as how defaults need to behave in the distro are being considered very 
> carefully. We are trying to avoid breakage and to make the process simpler, 
> but we are also shoring up the bridge while crossing it.
>

Two years into this, I am currently not confident that modularity will
be adapted to support community distributions well, especially
fast-paced ones like Fedora. My fears about it encouraging Fedora to
slow down has also seemingly borne fruit, too. Java is proof positive
of this.

Since the implosion of Fedora Java in the regular distribution and its
move to modules, the traditional effort to move to newer Java versions
has basically disappeared. Java 11 LTS was released last year, and to
this day our default Java is still Java 8 (which is EOL!). Clearly,
we're developing a new antipattern that we need to nip in the bud
sooner rather than later.

My disappointment in this became even greater when openSUSE beat us to
switching to Java 11. Their packaging is derived from ours! They've
demodularized Java for openSUSE and then did the work to move
everything forward. Meanwhile, we've now failed at our "first" and
"features" pillars because the incentive is now *gone*.

> We are absolutely considering the option of disallowing default streams in 
> Fedora, but we *really* don't want to rush into that. For one thing, we do 
> have a number of packages that have moved to modules-only that would have to 
> convert back. For some projects, this is probably just an annoyance, but for 
> others this may be a major impediment. In particular, one of the advantages 
> of Modularity is the ability to have buildroot-only packages that are 
> different from the base operating system (and don't end up delivered as 
> artifacts from the module). There are likely modules out there that rely on 
> this behavior because their build requires a newer or older version of some 
> package than the non-modular buildroot provides. This is not the sole problem 
> to address if we go the "no defaults" route, just the first that came to 
> mind. It's unclear to me right now if forcing everyone back to the old 
> behavior is less effort than fixing the remaining Modularity issues. And 
> since we need to fix them for RHEL as well anyway, it's worth considering 
> carefully if the added work is worthwhile.
>

The buildroot-only packages thing should have been banned in Fedora.
In my view, this feature is very much an anti-community feature,
because it heavily discourages shared maintainership and permits even
more orphanings than should be allowed. The more we do this, the less
value the distribution itself actually provides.

For example, it's pretty painful to package Rust software because you
cannot rely on the existence of Rust components in the distribution.
Everything *must* get built and integrated for each package. This not
only defeats one of the major virtuous outcomes of Fedora
participating in ecosystems (maintainers helping upstreams keep their
software fresh and secure), but also makes it functionally impossible
to distribute the workload of maintaining Rust packages in the same
way we have for Python, C/C++, and Perl.

> I'm wary of assuming that this thread represents the whole of Fedoran 
> opinions, however. As we all know, it's generally the set of people who are 
> upset that speak up the loudest. I'm not discounting your concerns (far from 
> it!), but if we only base development decisions on "make sure no one is upset 
> about it", we'd never accomplish anything new at all. This is why when I've 
> been sending out these emails to discuss ideas, I've been trying to carefully 
> describe both the use-cases and the technical limitations (both 

Re: Way to visualize where Fedora contributors are around the world?

[Alessio]

On Fri, Oct 11, 2019, 8:48 PM Richard Shaw  wrote:

>
> That got me thinking it would be pretty neat if a map could be
> automagically creating showing where everyone is. Wouldn't need exact
> addresses for privacy reasons but something that gets you close like a zip
> code (or equivalent).
>
> Thoughts?
>

Maybe you could play with this tool and adapt it to your needs:
https://pagure.io/fedora-commops/geofp

Ciao
A.
___
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: Defining the future of the packager workflow in Fedora

[Randy Barlow]

On Sat, 2019-10-05 at 02:38 +0200, Kevin Kofler wrote:
> No. Resolving conflicts implies that you need to do an actual merge,
> NOT a 
> fast forward. Fast-forwarding means that I am shipping the SAME
> commit on 
> all branches, so the changelog must be identical (unless I play games
> with 
> %if in the changelog, which is not going to happen).

The same commit is in all branches, there's just also a merge commit.
Subsequent commits that don't conflict do fast-forward.

> In addition, resolving conflicts is extra work compared to a
> conflict-free 
> merge or ideally a fast-forward.

It's less work than the mental overhead of working in a spec file with
%if statements.


signature.asc
Description: This is a digitally signed message part
___
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: koji web interface is very slow

[Kevin Fenzi]

On Fri, Oct 11, 2019 at 09:22:11AM -0400, Stephen John Smoogen wrote:
> On Fri, 11 Oct 2019 at 09:19, Peter Robinson  wrote:
> >
> > On Fri, Oct 11, 2019 at 10:13 AM Dominik 'Rathann' Mierzejewski
> >  wrote:
> > >
> > > On Friday, 11 October 2019 at 04:36, Orion Poplawski wrote:
> > > > On 10/10/19 4:57 PM, Orion Poplawski wrote:
> > > > > On 10/10/19 9:23 AM, Kevin Fenzi wrote:
> > > [...]
> > > > > > Pretty please can you all indicate approximately when (UTC) you were
> > > > > > seeing the slowness? I suspect it may be the nightly database dump 
> > > > > > job,
> > > > > > but I can't tell without knowing when you saw the slowness...
> > > [...]
> > > > > Thanks, it is much better now.  I feel like I've hit periods of 
> > > > > slowness
> > > > > over several days recently so I will definitely note times if I run 
> > > > > into
> > > > > it again.
> > > >
> > > > Definitely slower again:
> > > > Fri Oct 11 02:20:53 UTC 2019
> > >
> > > Fri 11 Oct 09:11:01 UTC 2019
> > > It takes 30s to show a build status page, e.g.
> > > https://koji.fedoraproject.org/koji/taskinfo?taskID=38215205
> >
> > Builds/cli is slow on Fri 11th, 13:17 UTC.
> 
> The fixes we tried seems to have put the load average of koji up to
> 150 while several mbs builds are going. I am going to put our status
> as yellow and see if we can tune this down.

So to update this thread some: 

* Load is fine/responsiveness is fine as long as we aren't doing a
database dump.
* When we do, things slow down and load goes way up. 

We did find one very odd/bad thing on the virthost the server is on (one
drive in the raid is showing active in multipath and possibly getting
copies of all i/o sent to it? unclear exactly, but it's wrong and needs
fixing). 

So, we stopped the backup and we are going to wait until 21UTC 
(after 5pm EDT). At that point we will try and clean up that multipath
issue and see if that helps things. If not we will try and tune the
vm/database more until we have it responsive all the time. 
We hope we can do these changes with minimal to no downtime, but there
may be some. 

I've filed https://pagure.io/fedora-infrastructure/issue/8292 on this
issue, folks are welcome to follow along there. 

Sorry about all this, I was just hoping to make things faster and sadly,
did not. 

kevin


signature.asc
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: Way to visualize where Fedora contributors are around the world?

[Neal Gompa]

On Fri, Oct 11, 2019 at 2:48 PM Richard Shaw  wrote:
>
> Just a random thought I had but I actually have no idea which 
> contributors/packagers are closest to me here in Mississippi, USA.
>
> That got me thinking it would be pretty neat if a map could be automagically 
> creating showing where everyone is. Wouldn't need exact addresses for privacy 
> reasons but something that gets you close like a zip code (or equivalent).
>
> Thoughts?
>

That'd be neat! Funnily enough, until a few years ago, I also lived in
Mississippi. :)



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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

coreos-assembler v0.6.0

[Colin Walters]

As part of creating Fedora CoreOS (and derivatives like Red Hat Enterprise 
Linux CoreOS), we are making some fairly fundamental changes to how the 
operating system works - while OSTree isn't new to Fedora, Ignition is - and 
more broadly than that, using Ignition implies something much more similar to 
the Container Linux experience where installation is via "dd to disk".

We created https://github.com/coreos/coreos-assembler as a new, opinionated 
tool designed to bind together Ignition, rpm-ostree, while carrying forward a 
lot of the Container Linux tooling from the https://github.com/coreos/mantle/ 
project around uploading to IaaS clouds, running tests (kola) etc.

https://github.com/coreos/coreos-assembler/releases/tag/v0.6.0
is the 0.6.0 release.

coreos-assembler comes as a container image (ready to run via "rootless" podman 
for example), not an RPM.   We may try to add it to the Fedora container 
buildsystem at some point, but the reason I'd like to occasionally highlight 
releases here is because part of the intention is that coreos-assembler should 
be an easy onramp for people and projects that want a "custom" Fedora CoreOS 
style system.

For example, I'd like for in the future for Fedora Silverblue and Fedora IoT to 
be *derivatives* of Fedora CoreOS.

And today, RHEL CoreOS (part of OpenShift 4) is created via coreos-assembler, 
although it's RHEL content obviously.

There are obviously a *ton* of "build systems" out there - but I think so far 
coreos-assembler has been working well as a way to make "CoreOS style systems"; 
for anyone who is interested in that (or wants to contribute to Fedora CoreOS), 
please take a look!
___
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

[Test-Announce] Proposal to CANCEL: 2019-10-14 Fedora QA Meeting

[Adam Williamson]

Hi folks! I'm proposing we cancel the QA meeting for Monday. Once again
I don't think there's anything urgent right now (the Xen criterion
probably isn't urgent again as it looks like we have a fix for the bug
there) and we're focused on F31 release testing right now. There will
be a blocker review meeting.

If you're aware of anything important we have to discuss this week,
please do reply to this mail and we can go ahead and run the meeting.

Thanks!
-- 
adamw
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test-annou...@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: Way to visualize where Fedora contributors are around the world?

[Neal Gompa]

On Fri, Oct 11, 2019 at 3:02 PM Richard Shaw  wrote:
>
> On Fri, Oct 11, 2019 at 1:51 PM Neal Gompa  wrote:
>>
>> On Fri, Oct 11, 2019 at 2:48 PM Richard Shaw  wrote:
>> >
>> > Just a random thought I had but I actually have no idea which 
>> > contributors/packagers are closest to me here in Mississippi, USA.
>> >
>> > That got me thinking it would be pretty neat if a map could be 
>> > automagically creating showing where everyone is. Wouldn't need exact 
>> > addresses for privacy reasons but something that gets you close like a zip 
>> > code (or equivalent).
>> >
>> > Thoughts?
>> >
>>
>> That'd be neat! Funnily enough, until a few years ago, I also lived in
>> Mississippi. :)
>
>
> Hah... That's funny. I'm in the extreme NW corner and work in Memphis, TN.
>

I lived in Starkville until four years ago, and before that Clinton.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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 Final blocker status email #5

[Ben Cotton]

Next week is the Go/No-Go meeting. Wouldn't it be great if this was
the last blocker status email?

Action summary


Accepted blockers
-
1. mutter — can't turn zoom off once enabled — POST
ACTION: upstream to merge fixes

2. distribution — Cannot upgrade to Fedora 31: package
exa-0.9.0-2.module_f31+5365+04413d87.x86_64 requires
libgit2.so.28()(64bit), but none of the providers can be installed —
NEW
ACTION: dnf team to look at adding output message

3. fedora-release — Need finalized fedora-release for F31 — MODIFIED
ACTION: QA to verify update FEDORA-2019-1be4cf1f58

4. fedora-repos — updates-testing is still enabled — MODIFIED
ACTION: QA to verify update FEDORA-2019-1be4cf1f58

5. gnome-control-center — gnome-control-c[6995]: segfault at 38 ip
5593cc8dda7e — ON_QA
ACTION: QA to verify update FEDORA-2019-eaf25b8182
NEEDINFO: lruzi...@redhat.com

6. sddm — Cannot start Fedora-KDE-Live (F31) in basic graphics mode on
BIOS machine — NEW
ACTION: upstream to diagnose and fix issue

7. blivet-gui — bios boot partition can't be created at the disk
beginning, if a partition already exists in the middle of the disk —
POST
ACTION: upstream to merge PR #131

8. uboot-tools — uboot-tools-2019.10 is available — ON_QA
ACTION: QA to verify update FEDORA-2019-d9b994c6bc

Proposed blockers
-

1. dnf — dnf-yum in F30 is now higher versioned than F31+ yum's
"Obsoletes" (affects upgrades) — NEW
ACTION: dnf maintainers to correct the Obsoletes line in the dnf-yum pacakge

2. dnf-plugins-extras — dnf system-upgrade reboot fails due to
depresolv difference with download — POST
ACTION: upstream to merge pull request

3. grub2 — Newer kernels do not boot and have invalid grub.cfg entries
(on Xen DomU guests) — ON_QA
ACTION: QA to verify FEDORA-2019-ad706bc4b9

4. libdnf — dnfdragora complains that dnf is locked by another process
after updates — NEW
ACTION: upstream to diagnose and resolve issue

5. mutter — Drag and Drop between applications is broken on Wayland — POST
ACTION: upstream to merge ...merge request

6. gnome-software — "Installed" tab contains core system applications
and allows uninstalling them — MODIFIED
ACTION: QA to verify update FEDORA-2019-9424d60d3d


Bug-by-bug detail
=

Accepted blockers
-
1. mutter — https://bugzilla.redhat.com/show_bug.cgi?id=1749433 — POST
can't turn zoom off once enabled

Zoom remains enabled, even after logging out and logging back in.
Merge requests upstream may fix this.
Upstream merge requests:
https://gitlab.gnome.org/GNOME/mutter/merge_requests/832
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/754

2. distribution — https://bugzilla.redhat.com/show_bug.cgi?id=1747408 — NEW
Cannot upgrade to Fedora 31: package
exa-0.9.0-2.module_f31+5365+04413d87.x86_64 requires
libgit2.so.28()(64bit), but none of the providers can be installed

Accepted as a blocker by FESCo, even though it does not affect default
package sets. DNF team is looking at adding an output message that
would address FESCo's short-term concerns. sgallagh has proposed a
longer-term solution.

3. fedora-release —
https://bugzilla.redhat.com/show_bug.cgi?id=1760474 — MODIFIED
Need finalized fedora-release for F31

FEDORA-2019-1be4cf1f58 has been submitted as an update to Fedora 31.

4. fedora-repos — https://bugzilla.redhat.com/show_bug.cgi?id=1760415 — MODIFIED
updates-testing is still enabled

FEDORA-2019-1be4cf1f58 has been submitted as an update to Fedora 31.

5. gnome-control-center —
https://bugzilla.redhat.com/show_bug.cgi?id=1756553 — ON_QA
gnome-control-c[6995]: segfault at 38 ip 5593cc8dda7e

`gnome-control-center` segfaults when trying to select a display at
Settings>Devices>Displays. Update FEDORA-2019-eaf25b8182 includes the
upstream fix backported.

6. sddm — https://bugzilla.redhat.com/show_bug.cgi?id=1728240 — NEW
Cannot start Fedora-KDE-Live (F31) in basic graphics mode on BIOS machine

This issue only seems to affect BIOS machines when using basic
graphics mode. This appears to be related to an issue encountered in
F30 (RHBZ #1683197).
Upstream issue: https://github.com/sddm/sddm/issues/1204

7. blivet-gui — https://bugzilla.redhat.com/show_bug.cgi?id=1755813 — POST
bios boot partition can't be created at the disk beginning, if a
partition already exists in the middle of the disk

blivet tries to place the BIOS boot partition after existing partiions
in certain configurations, which means the boot partition ends up
misplaced. Upstream PR fixes this issue:
https://github.com/storaged-project/blivet-gui/pull/131 (and RHBZ
#1756288 as a bonus)

8. uboot-tools — https://bugzilla.redhat.com/show_bug.cgi?id=1759358 — ON_QA
uboot-tools-2019.10 is available

The latest release of uboot-tools enables booting for several devices,
included IoT reference devices. Update FEDORA-2019-d9b994c6bc provides
the new verison.

Proposed blockers
-

1. dnf — https://bugzilla.redhat.com/show_bug.cgi?id=1760937 — 

Re: Defining the future of the packager workflow in Fedora

[Adam Williamson]

On Fri, 2019-10-11 at 17:10 -0400, Randy Barlow wrote:
> On Sat, 2019-10-05 at 02:38 +0200, Kevin Kofler wrote:
> > No. Resolving conflicts implies that you need to do an actual merge,
> > NOT a 
> > fast forward. Fast-forwarding means that I am shipping the SAME
> > commit on 
> > all branches, so the changelog must be identical (unless I play games
> > with 
> > %if in the changelog, which is not going to happen).
> 
> The same commit is in all branches, there's just also a merge commit.
> Subsequent commits that don't conflict do fast-forward.
> 
> > In addition, resolving conflicts is extra work compared to a
> > conflict-free 
> > merge or ideally a fast-forward.
> 
> It's less work than the mental overhead of working in a spec file with
> %if statements.

That seems like a personal call, really. I very much like being able to
keep branches in sync without merge commits as it means I can do stuff
like:

for i in el6 epel7 f29 f30 f31 master; do fedpkg switch-branch $i; git
pull; git merge master; fedpkg push; fedpkg build --nowait; done

and I don't find it particularly onerous to deal with sensible
conditionals. It all depends a lot on what you prefer as an individual
and exactly how much difference there needs to be between branches.
-- 
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: Modularity and the system-upgrade path

[Zbigniew Jędrzejewski-Szmek]

On Mon, Oct 07, 2019 at 04:34:21PM -0400, Matthew Miller wrote:
> On Mon, Oct 07, 2019 at 08:13:17PM +0200, Fabio Valentini wrote:
> > To quote you from the other ongoing thread: "The default stream for a
> > package shouldn't be updated in disruptive ways in shipped releases"
> > If that's the case, then what *is* the benefit of abandoning the
> > non-modular version of packages, if default streams need to basically
> > be maintained separately for different branches anyway? 樂
> 
> To me, most packages would benefit from having two streams: fast and slow.
> That's the essential problem I want solved anyway. (Maybe with CentOS
> Streams: fast, slow, very slow.)
> 
> The "slow" version would be updated on a careful cadence with big updates
> aligned with release boundaries. The fast version would be rolling latest.
> And for applications, you can pick which you want.

IIUC, Modules make this particular problem worse:
Let's consider this: a new version of ook came out a month ago, got
released in F31, and it seems nice and stable and fully backwards compatible.
The maintainer decides it's time to push it out to stable releases.

- non-modular: git checkout f30 && git merge f31 && fedpkg build && fedpkg 
update
   (OK, consider this pseudo-code)

- modular: the "stable" stream gets updated, and now F29 users get an update
  just before the release is to be retired. This is at best a waste of
  compilation cycles and download bits, and increases chances of breakage
  in a release that is supposed to have a minimum of disruptions.

The obvious solution is to *not* update in F29, which means that as Fabio 
wrote, 
> default streams need to basically be maintained separately for different 
> branches

Zbyszek
___
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: libdav1d SONAME bump

[Nicolas Chauvet]

Le ven. 11 oct. 2019 à 16:33, Xavier Bachelot  a écrit :
>
> Le 11/10/2019 à 16:10, Robert-André Mauchin a écrit :
> > Hello,
> >
> > Dav1d 0.5.0 was published today and brings a SONAME bump from libdav1d.so.
> > 2.0.0 to libdav1d.so.3.0.0.
> > I will be updating it next week on F31/32, consumers of these libraries
> > (ffmpeg, xine-lib, vlc) will need to rebuild their packages.
> >
>
> This is too late for F31, we're past beta.
> thttps://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#beta-to-pre-release.
>
> Are there any other consumers than RPM Fusion packages ?
> If not, shall we make an exception ? I'm neither +1 nor -1 on this, I
> don't even know if xine-lib would rebuild.
> Leigh, Nicolas, what do you think ?

This kind of situation is very difficult to deal with when in a fedora
freeze period. For me it's impossible to update on the fedora side.
Also I haven't any feedback on what will break or not, so this really
has to be f32 only material unfortunately (or upstream has to learn
not to break ABI).

One workaround to have Dav1d in f31 would be to have a snapshot, so we
could use the new ABI before freeze. (at least).

On a side note, we already provides docker images of ffmpeg, so if one
wants newer components based on rawhide it's a matter to pull the
images.
See also https://hub.docker.com/r/rpmfusion/ffmpeg

-- 
-

Nicolas (kwizart)
___
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: Let's revisit the FTBFS policy

[Miro Hrončok]

On 14. 08. 19 14:23, Miro Hrončok wrote:

Hello.

Recently, a couple hundred packages were retired from rawhide (Fedora 31 at that 
time) based on the Fedora Failed to Build From Source Policy [1]. From various 
reactions over several threads it seems this policy is not ideal. This is an 
attempt to collect feedback and make the policy better serve Fedora's needs.


Fedora has a policy for a long time that can be simplified as:

  1. Mass rebuild for Fedora N happens by releng
  2. Packages that fail to build get open bugzillas by releng
  3. Packages with NEW bugizllas are orphaned after 8 weeks with weekly 
reminders by releng
  4. A week before Fedora N+1 branching any packages which still have open 
Fedora N FTBFS bug are retired by releng


However, 3 or 4 haven't happened since Fedora ~26, because the automation was 
not working any more for various reasons I don't understand.


The policy was then updated by FESCo to allow anybody to step up and do 3. 
manually.
However it needs 2 e-mails to devel directed at the package owners and that may 
be understood as a personal attack by some.

So nobody ever did that but me (twice) IIRC (and I got my share of shame for 
that).

Currently, the FTBFS retirement is problematic due to various things:

1) Bugzilla spam: Maintainers are spammed weekly by releng, some of them find 
that annoying and simply switch the bug to ASSIGNED to make it stop.


The problem is, how do we both keep notifying the maintainers that action is 
needed and not spam them with stuff that will make them filter all Fedora 
e-mails to /dev/null.


2) Retirement out of the blue. When releng executes 4., packagers that stopped 
the bugzilla spam by setting the bug to ASSIGNED are suddenly surprised the 
package was retired. OTOH arguably they made a deliberate action to stop the 
notifications. However, most importantly, any dependent packages were not 
notified at all, which is **not fair**.


This state is broken mostly because there is no automatic orphaning of packages 
that have NEW bugzillas and there is no orphaning at all for packages where the 
bugzillas are ASSIGNED for months. For the second bit, everything indicates that 
packagers are aware of the problem and will fix the bug in time before 4., but 
they don't and things blow up.


3) Questionable importance of the FTBFS bug.

Repeatedly, it has been stated by some, the FTBFS bug is not important and we 
should not retire packages at all based on the fact that they "simply" fail to 
build. I personally don't agree with this for various reasons, but I can imagine 
a situation, where it is reasonable to say so and delay the problem. Obvious 
argument is: Better to have 1 package nonbuildable than have 100 packages 
nonisntallable. So we need a way to opt-out from the retirement, however simply 
setting the bugzilla to ASSIGNED is not it, because we will end up with packages 
last built 6 years ago (and I believe this is not what we want).



I'm starting this thread to collect the ideas about how to make this better.
If you see more problems, share them. I promise I'll do my best to make the 
policy work better for both Fedora and the people who make Fedora.


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


Policy changes proposed at:

https://pagure.io/fesco/fesco-docs/pull-request/18
https://pagure.io/fesco/issue/2244

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

how to list all module repos in Fedora?

[Zbigniew Jędrzejewski-Szmek]

Hi,

https://src.fedoraproject.org/modules/ returns 404, and
https://src.fedoraproject.org/browse/projects/ seems to list rpms/
(though there's 622 pages of output, so I'm not sure).

Is there a way to browse through module repos?

Zbyszek
___
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-20191011.n.0 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 5/153 (x86_64), 1/2 (arm)

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

ID: 467475  Test: x86_64 Server-dvd-iso server_remote_logging_server
URL: https://openqa.fedoraproject.org/tests/467475
ID: 467476  Test: x86_64 Server-dvd-iso server_remote_logging_client
URL: https://openqa.fedoraproject.org/tests/467476
ID: 467507  Test: x86_64 KDE-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/467507

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

ID: 467453  Test: x86_64 Server-dvd-iso modularity_tests
URL: https://openqa.fedoraproject.org/tests/467453
ID: 467511  Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/467511
ID: 467515  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/467515

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

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

ID: 467492  Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/467492
ID: 467542  Test: x86_64 universal upgrade_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/467542
ID: 467543  Test: x86_64 universal upgrade_server_64bit
URL: https://openqa.fedoraproject.org/tests/467543
ID: 467562  Test: x86_64 universal upgrade_minimal_64bit
URL: https://openqa.fedoraproject.org/tests/467562
ID: 467563  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/467563
ID: 467564  Test: x86_64 universal upgrade_kde_64bit
URL: https://openqa.fedoraproject.org/tests/467564
ID: 467565  Test: x86_64 universal upgrade_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/467565
ID: 467601  Test: x86_64 universal upgrade_realmd_client
URL: https://openqa.fedoraproject.org/tests/467601

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

ID: 467571  Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/467571

Passed openQA tests: 139/153 (x86_64)

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

ID: 467595  Test: x86_64 universal install_european_language
URL: https://openqa.fedoraproject.org/tests/467595

Skipped non-gating openQA tests: 1 of 155

Installed system changes in test x86_64 Workstation-live-iso 
install_default_upload: 
1 services(s) added since previous compose: bolt.service
System load changed from 0.27 to 0.38
Previous test data: https://openqa.fedoraproject.org/tests/466539#downloads
Current test data: https://openqa.fedoraproject.org/tests/467484#downloads

Installed system changes in test x86_64 Workstation-live-iso 
install_default@uefi: 
Used mem changed from 857 MiB to 972 MiB
1 services(s) added since previous compose: bolt.service
Previous test data: https://openqa.fedoraproject.org/tests/466541#downloads
Current test data: https://openqa.fedoraproject.org/tests/467486#downloads

Installed system changes in test x86_64 KDE-live-iso install_default_upload: 
System load changed from 0.47 to 1.52
Average CPU usage changed from 2.98571429 to 74.42857143
Previous test data: https://openqa.fedoraproject.org/tests/466554#downloads
Current test data: https://openqa.fedoraproject.org/tests/467499#downloads

Installed system changes in test x86_64 KDE-live-iso install_default@uefi: 
1 services(s) removed since previous compose: pcscd.service
System load changed from 1.92 to 1.20
Average CPU usage changed from 86.85238095 to 32.06190476
Previous test data: https://openqa.fedoraproject.org/tests/466556#downloads
Current test data: https://openqa.fedoraproject.org/tests/467501#downloads

Installed system changes in test x86_64 Silverblue-dvd_ostree-iso 
install_default_upload: 
Used mem changed from 691 MiB to 805 MiB
Used Swap grew from 0 to 5 MiB
1 services(s) added since previous compose: bolt.service
System load changed from 0.11 to 0.49
Average CPU usage changed from 2.10476190 to 15.01428571
Previous test data: https://openqa.fedoraproject.org/tests/466572#downloads
Current test data: https://openqa.fedoraproject.org/tests/467517#downloads

Installed system changes in test x86_64 Silverblue-dvd_ostree-iso 
install_default@uefi: 
Used mem changed from 691 MiB to 837 MiB
Used Swap grew from 0 to 8 MiB
1 services(s) added since previous compose: bolt.service
Previous test data: https://openqa.fedoraproject.org/tests/466574#downloads
Current test data: https://openqa.fedoraproject.org/tests/467519#downloads

Installed system changes in test x86_64 universal install_package_set_kde: 
Used mem changed from 957 MiB to 768 MiB
1 services(s) removed since previous compose: pcscd.service
Previous test data: 

Non-responsive maintainer: jamielinux

[Robbie Harwood]

Hello,

In accordance with Fedora's non-responsive maintainer policy, I'm
sending this message in attempt to contact Jamie Nguyen (jamielinux).

Required non-responsive maintainer bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1760898

Open unaddressed bugs (219 in total):
https://bugzilla.redhat.com/buglist.cgi?bug_status=__open__=Fedora=jamielinux_to1=1=substring_id=10563336=Fedora_format=advanced

In this list are no less than fifteen CVEs dating back as far as 2016,
and twenty-four FTBFS bugs starting in 2018.

I'm specifically looking for resolution to the same problem mentioned in
awjb's non-responsive call with rxvt-unicode, for which jamielinux is a
co-maintainer.  (The issue in question is tracked in
https://bugzilla.redhat.com/show_bug.cgi?id=1741278 and
https://bugzilla.redhat.com/show_bug.cgi?id=1430935 and
https://bugzilla.redhat.com/show_bug.cgi?id=949921 ).

Thanks,
--Robbie


signature.asc
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: how to list all module repos in Fedora?

[Alexander Scheel]

If you go to any modular repo:
https://src.fedoraproject.org/modules/eclipse

And click on "modules" in the path at the top, it takes you to:

https://src.fedoraproject.org/projects/modules/%2A

Which lists them all.

- Original Message -
> From: "Zbigniew Jędrzejewski-Szmek" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Friday, October 11, 2019 1:45:00 PM
> Subject: how to list all module repos in Fedora?
> 
> Hi,
> 
> https://src.fedoraproject.org/modules/ returns 404, and
> https://src.fedoraproject.org/browse/projects/ seems to list rpms/
> (though there's 622 pages of output, so I'm not sure).
> 
> Is there a way to browse through module repos?
> 
> Zbyszek
> ___
> 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: module package exclusion behavior on EL8

[Stephen John Smoogen]

On Thu, 10 Oct 2019 at 19:28, Orion Poplawski  wrote:
>
> I continue to run into strange (at least to me) issues with modules on
> EL8.  RHEL8 ships a 'rhn-tools' module that ships only the "koan"
> package from the cobbler srpm [1].  When this module is enabled, I
> cannot install cobbler from my copr - dnf reports that 'cobbler' is
> excluded.
>
> Can someone fill me in more on this.? Is this expected?  I don't see
> anything in the module file (assuming I have the right module file) that
> specifically calls out cobbler for exclusion (such as a filter entry) -
> so is it just automatically creating an exclusion for all unshipped
> packages?
>

This is by design. I believe it is set up in the modules.yaml file in
the repository but it may also be helped/done with some rpm headers.

I think it is meant to protect you from say a perl-foo-1.2.3 which was
built for perl-5.24 when you have perl-5.26. It may also allow the
module owner to say 'yes I know you could install cobbler-N but I
don't want to support that if you are using my thing'. Basically a
side point of 'yes I built a cobbler to make this thing, but I odn't
want to ship a cobbler.. if they want it they can make their own
module with it.'

I leave it as an exercise to the reader when someone doesn't realize
this, builds the kernel, glibc, bash, etc for their module but doesn't
want to ship that.. and puts it in the filter


-- 
Stephen J Smoogen.
___
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 32 Self-Contained Change proposal: Free Pascal Compiler 3.2.0

[Jason L Tibbitts III]

> "AI" == Artur Iwicki  writes:

AI> I imagine the reason is that this allows us to add new
AI> architectures to FPC and do some trial-and-error builds of FPC
AI> without affecting dependent packages - if FPC itself used
AI> %{fpc_arches}, then adding new architectures to FPC would require
AI> updating fpc-rpm-macros, and that would make all dependent packages
AI> fail to build, since the new-arch builds would fail with "Package
AI> not found: fpc" until we got FPC available on those.

fpc could simply use something like:

ExclusiveArch: %{fpc_arches} aarch64

to trial a new architecture without having to update fpc-rpm-macros.

 - J<
___
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: libdav1d SONAME bump

[Xavier Bachelot]

Le 11/10/2019 à 16:10, Robert-André Mauchin a écrit :

Hello,

Dav1d 0.5.0 was published today and brings a SONAME bump from libdav1d.so.
2.0.0 to libdav1d.so.3.0.0.
I will be updating it next week on F31/32, consumers of these libraries
(ffmpeg, xine-lib, vlc) will need to rebuild their packages.



This is too late for F31, we're past beta.
https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#beta-to-pre-release.

Are there any other consumers than RPM Fusion packages ?
If not, shall we make an exception ? I'm neither +1 nor -1 on this, I 
don't even know if xine-lib would rebuild.

Leigh, Nicolas, what do you think ?

Regards,
Xavier
___
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: Question regarding systemd service unit cleanup

[Ravindra Kumar via devel]

> systemctl daemon-reload?

Thanks Dridi. I had forgotten to mention that I had tried daemon-reload and 
that did not help.

> Isn't this handled automatically by the %systemd scriptlets?

%systemd_post macro is a no-op for upgrade case - 
https://github.com/systemd/systemd/blob/master/src/core/macros.systemd.in#L46 
($1 would be "2" for upgrade in "post" scriptlet - 
https://docs.fedoraproject.org/en-US/packaging-guidelines/Scriptlets/).

- Ravindra
___
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: Way to visualize where Fedora contributors are around the world?

[Kevin Fenzi]

On Fri, Oct 11, 2019 at 02:59:19PM -0600, Orion Poplawski wrote:
> On 10/11/19 12:47 PM, Richard Shaw wrote:
> > Just a random thought I had but I actually have no idea which
> > contributors/packagers are closest to me here in Mississippi, USA.
> > 
> > That got me thinking it would be pretty neat if a map could be automagically
> > creating showing where everyone is. Wouldn't need exact addresses for 
> > privacy
> > reasons but something that gets you close like a zip code (or equivalent). 
> > 
> > Thoughts?
> 
> FWIW - Fedora Account allows you to enter your Lat/Lon coordinates.  This
> isn't displayed in the view though.  But presumably a map could be built with
> that.  I do like the idea.

The ambassadors did this a while back: 

https://fedoraproject.org/wiki/Fedora_ambassadors_map

I'm not sure it's updating, but it was working for a while there. 

kevin


signature.asc
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

Fedora rawhide compose report: 20191011.n.1 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20191010.n.0
NEW: Fedora-Rawhide-20191011.n.1

= SUMMARY =
Added images:0
Dropped images:  2
Added packages:  9
Dropped packages:63
Upgraded packages:   245
Downgraded packages: 0

Size of added packages:  15.61 MiB
Size of dropped packages:1.42 GiB
Size of upgraded packages:   4.52 GiB
Size of downgraded packages: 0 B

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

= ADDED IMAGES =

= DROPPED IMAGES =
Image: Workstation raw-xz aarch64
Path: 
Workstation/aarch64/images/Fedora-Workstation-Rawhide-20191010.n.0.aarch64.raw.xz
Image: Workstation raw-xz armhfp
Path: 
Workstation/armhfp/images/Fedora-Workstation-armhfp-Rawhide-20191010.n.0-sda.raw.xz

= ADDED PACKAGES =
Package: fasttext-0.9.1-1.fc32
Summary: Efficient learning of word representations and sentence classification
RPMs:fasttext fasttext-devel fasttext-libs
Size:1.34 MiB

Package: la-capitaine-cursor-theme-3-5.fc32
Summary: X-cursor theme inspired by macOS and based on KDE Breeze
RPMs:la-capitaine-cursor-theme
Size:17.92 KiB

Package: libresample-0.1.3-32.fc32
Summary: A real-time library for audio sampling rate conversion
RPMs:libresample libresample-devel
Size:337.10 KiB

Package: phoc-0.1.0-2.fc32
Summary: Display compositor designed for phones
RPMs:phoc
Size:399.84 KiB

Package: python-pynetdicom-1.4.1-1.fc32
Summary: A Python implementation of the DICOM networking protocol
RPMs:python-pynetdicom-doc python3-pynetdicom
Size:6.55 MiB

Package: qm-dsp-1.7.1-10.fc32
Summary: Library for DSP and Music Informatics purposes
RPMs:qm-dsp-devel
Size:1.11 MiB

Package: sentencepiece-0.1.83-1.fc32
Summary: An unsupervised text tokenizer for Neural Network-based text generation
RPMs:python3-sentencepiece sentencepiece-devel sentencepiece-libs 
sentencepiece-tools
Size:5.28 MiB

Package: standard-test-roles-4.4-1.module_f32+6795+7cc43ca8
Summary: Standard Test Interface Ansible roles
RPMs:standard-test-roles standard-test-roles-inventory-docker 
standard-test-roles-inventory-qemu
Size:72.92 KiB

Package: tolua++-1.0.93-27.fc32
Summary: A tool to integrate C/C++ code with Lua
RPMs:tolua++ tolua++-devel
Size:536.84 KiB


= DROPPED PACKAGES =
Package: aether-connector-okhttp-0.17.6-2.module_f32+6520+2b0184c9
Summary: OkHttp Aether Connector
RPMs:aether-connector-okhttp aether-connector-okhttp-javadoc
Size:113.82 KiB

Package: amavisd-new-2.12.0-2.fc32
Summary: Email filter with virus scanner and spamassassin support
RPMs:amavisd-new amavisd-new-doc amavisd-new-snmp
Size:834.59 KiB

Package: docker-client-java-8.11.7-4.module_f32+6520+2b0184c9
Summary: Docker Client
RPMs:docker-client-java
Size:605.47 KiB

Package: eclipse-1:4.13-2.module_f32+6520+2b0184c9
Summary: An open, extensible IDE
RPMs:eclipse-equinox-osgi eclipse-jdt eclipse-p2-discovery eclipse-pde 
eclipse-platform eclipse-swt
Size:644.75 MiB

Package: eclipse-abrt-0.0.3-9.module_f32+6520+2b0184c9
Summary: Eclipse ABRT plugin
RPMs:eclipse-abrt
Size:32.96 KiB

Package: eclipse-cdt-2:9.9.0-1.module_f32+6520+2b0184c9
Summary: Eclipse C/C++ Development Tools (CDT) plugin
RPMs:eclipse-cdt eclipse-cdt-arduino eclipse-cdt-docker eclipse-cdt-llvm 
eclipse-cdt-native eclipse-cdt-qt eclipse-cdt-sdk
Size:570.93 MiB

Package: eclipse-dtp-1.14.105-1.module_f32+6520+2b0184c9
Summary: Eclipse Data Tools Platform
RPMs:eclipse-dtp
Size:12.67 MiB

Package: eclipse-ecf-3.14.5-3.module_f32+6520+2b0184c9
Summary: Eclipse Communication Framework (ECF) Eclipse plug-in
RPMs:eclipse-ecf-core eclipse-ecf-runtime eclipse-ecf-sdk
Size:4.50 MiB

Package: eclipse-egit-5.5.0-1.module_f32+6520+2b0184c9
Summary: Eclipse Git Integration
RPMs:eclipse-egit eclipse-egit-mylyn
Size:9.41 MiB

Package: eclipse-egit-github-5.5.0-1.module_f32+6520+2b0184c9
Summary: Eclipse EGit Mylyn GitHub Connector
RPMs:eclipse-egit-github
Size:696.18 KiB

Package: eclipse-epp-logging-2.0.8-2.module_f32+6520+2b0184c9
Summary: Eclipse Error Reporting tool
RPMs:eclipse-epp-logging
Size:512.00 KiB

Package: eclipse-gef-3.11.0-11.module_f32+6520+2b0184c9
Summary: Graphical Editing Framework (GEF) Eclipse plug-in
RPMs:eclipse-gef eclipse-gef-sdk
Size:7.20 MiB

Package: eclipse-jgit-5.5.0-1.module_f32+6520+2b0184c9
Summary: Eclipse JGit
RPMs:eclipse-jgit
Size:32.76 KiB

Package: eclipse-launchbar-1:2.4.0-1.module_f32+6520+2b0184c9
Summary: Eclipse Launchbar plug-in
RPMs:eclipse-launchbar
Size:236.79 KiB

Package: eclipse-linuxtools-7.4.0-2.module_f32+6520+2b0184c9
Summary: Linux specific Eclipse plugins
RPMs:eclipse-linuxtools eclipse-linuxtools-changelog 
eclipse-linuxtools-docker eclipse-linuxtools-gcov eclipse-linuxtools-gprof 
eclipse-linuxtools-javadocs eclipse-linuxtools-libhover 
eclipse-linuxtools-manpage eclipse-linuxtools-perf 
eclipse

Re: Defining the future of the packager workflow in Fedora

[Randy Barlow]

On Fri, 2019-10-11 at 14:34 -0700, Adam Williamson wrote:
> That seems like a personal call, really. I very much like being able
> to
> keep branches in sync without merge commits as it means I can do
> stuff
> like:
> 
> for i in el6 epel7 f29 f30 f31 master; do fedpkg switch-branch $i;
> git
> pull; git merge master; fedpkg push; fedpkg build --nowait; done
> 
> and I don't find it particularly onerous to deal with sensible
> conditionals. It all depends a lot on what you prefer as an
> individual
> and exactly how much difference there needs to be between branches.

Why have branches at all if you are going to have the file be the same
in all branches? You can build for any release off of master - Koji
will still record the commit hash and everything, so nothing bad
happens if you do that. It seems like unnecessary effort to bother with
all the merges (even if they are clean) when you could just have a
master branch if you are set on having a spec file with if statements.

I think I would mind the if statements less if I could use indentation
in the spec file to make it visually easier to discern which code is
part of which if block. Or am I wrong — can you do that?

I personally like using git here - it makes my spec files shorter and
cleaner, and I don't find it hard to resolve the conflicts. As said
elsewhere, there are ideas for how to reduce the very common conflicts
(changelog/version/release) and if we did that I think it'd be even
easier.

Anyways, I think it's fine to do it the way you want (or the way the
group wants if you maintain a package with other folks), but I would
suggest to those who prefer the if statements, why not consider just
using master? It'll save a little effort.


signature.asc
Description: This is a digitally signed message part
___
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: Defining the future of the packager workflow in Fedora

[Randy Barlow]

On Thu, 2019-10-03 at 19:02 +, Zbigniew Jędrzejewski-Szmek wrote:
> > As pointed out elsewhere, we would have fewer conflicts if we could
> > get
> > the version, release, and changelog out of the spec file, and then
> > I
> > think maintaining different spec in different release branches
> > would be
> > easier than it is today.
> 
> Small correction: not the version. Just the release and changelog.

I included version because of jcline's proposal to use git tags to
discern the version and release. Though I bet you could have some
conflicts due to version too (though less common). For example, say you
have these versions:

F29: libfoo-1.2.1-1
F30: libfoo-1.3.0-1

Then upstream does a 1.3.1 with an OMG security fix, and for whatever
reason you don't choose to backport the fix but instead just update F29
to 1.3.1 (you read the changelog, nothing is backwards incompatible,
and backporting the fix is non-trivial, for example). This could lead
to a conflict, but not hard to resolve of course.


signature.asc
Description: This is a digitally signed message part
___
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-Rawhide-20191011.n.1 compose check report

[Fedora compose checker]

No missing expected images.

Compose FAILS proposed Rawhide gating check!
3 of 45 required tests failed, 2 results missing
openQA tests matching unsatisfied gating requirements shown with **GATING** 
below
Unsatisfied gating requirements that could not be mapped to openQA tests:
FAILED: compose.cloud.all
MISSING: fedora.Workstation-boot-iso.x86_64.64bit - compose.install_default
MISSING: fedora.Workstation-boot-iso.x86_64.uefi - compose.install_default

Failed openQA tests: 5/143 (x86_64), 1/2 (arm)

New failures (same test not failed in Fedora-Rawhide-20191010.n.0):

ID: 467984  Test: x86_64 KDE-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/467984
ID: 468011  Test: x86_64 universal install_delete_pata@uefi **GATING**
URL: https://openqa.fedoraproject.org/tests/468011
ID: 468061  Test: x86_64 universal install_arabic_language
URL: https://openqa.fedoraproject.org/tests/468061

Old failures (same test failed in Fedora-Rawhide-20191010.n.0):

ID: 467927  Test: x86_64 Server-dvd-iso modularity_tests
URL: https://openqa.fedoraproject.org/tests/467927
ID: 467968  Test: x86_64 Workstation-live-iso desktop_browser **GATING**
URL: https://openqa.fedoraproject.org/tests/467968
ID: 467989  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/467989

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

New soft failures (same test not soft failed in Fedora-Rawhide-20191010.n.0):

ID: 467921  Test: x86_64 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/467921
ID: 467922  Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/467922
ID: 467956  Test: x86_64 Everything-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/467956
ID: 467957  Test: x86_64 Everything-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/467957
ID: 468002  Test: x86_64 universal install_kickstart_firewall_disabled
URL: https://openqa.fedoraproject.org/tests/468002
ID: 468003  Test: x86_64 universal install_kickstart_firewall_configured
URL: https://openqa.fedoraproject.org/tests/468003
ID: 468009  Test: x86_64 universal install_mirrorlist_graphical
URL: https://openqa.fedoraproject.org/tests/468009
ID: 468048  Test: x86_64 universal install_kickstart_user_creation
URL: https://openqa.fedoraproject.org/tests/468048
ID: 468062  Test: x86_64 universal install_kickstart_nfs
URL: https://openqa.fedoraproject.org/tests/468062

Old soft failures (same test soft failed in Fedora-Rawhide-20191010.n.0):

ID: 467966  Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/467966
ID: 468028  Test: x86_64 universal upgrade_kde_64bit
URL: https://openqa.fedoraproject.org/tests/468028
ID: 468033  Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/468033
ID: 468035  Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/468035
ID: 468053  Test: x86_64 universal install_kickstart_hdd
URL: https://openqa.fedoraproject.org/tests/468053

Passed openQA tests: 124/143 (x86_64)

New passes (same test not passed in Fedora-Rawhide-20191010.n.0):

ID: 467923  Test: x86_64 Server-dvd-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/467923
ID: 467925  Test: x86_64 Server-dvd-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/467925
ID: 467936  Test: x86_64 Server-dvd-iso install_repository_hd_variation
URL: https://openqa.fedoraproject.org/tests/467936
ID: 467938  Test: x86_64 Server-dvd-iso server_realmd_join_kickstart
URL: https://openqa.fedoraproject.org/tests/467938
ID: 467946  Test: x86_64 Server-dvd-iso install_repository_nfs_variation
URL: https://openqa.fedoraproject.org/tests/467946
ID: 467951  Test: x86_64 Server-dvd-iso install_updates_nfs
URL: https://openqa.fedoraproject.org/tests/467951
ID: 467954  Test: x86_64 Server-dvd-iso install_repository_nfs_graphical
URL: https://openqa.fedoraproject.org/tests/467954
ID: 467955  Test: x86_64 Server-dvd-iso install_repository_nfsiso_variation
URL: https://openqa.fedoraproject.org/tests/467955
ID: 467991  Test: x86_64 universal install_sata@uefi
URL: https://openqa.fedoraproject.org/tests/467991
ID: 467992  Test: x86_64 universal install_multi
URL: https://openqa.fedoraproject.org/tests/467992
ID: 467993  Test: x86_64 universal install_multi@uefi
URL: https://openqa.fedoraproject.org/tests/467993
ID: 467994  Test: x86_64 universal install_simple_encrypted
URL: https://openqa.fedoraproject.org/tests/467994
ID: 467995  Test: x86_64 universal install_simple_free_space
URL: https://openqa.fedoraproject.org/tests/467995
ID: 467996  Test: x86_64 universal install_multi_empty
URL: 

Re: libdav1d SONAME bump

[Leigh Scott]

> Hello,
> 
> Dav1d 0.5.0 was published today and brings a SONAME bump from libdav1d.so.
> 2.0.0 to libdav1d.so.3.0.0.
> I will be updating it next week on F31/32, consumers of these libraries 
> (ffmpeg, xine-lib, vlc) will need to rebuild their packages.
> 
> Best regards,
> 
> Robert-André

I'm -1 for the F31 update, I have enough pending tasks without this.
Do we really need  a new version just before F31 release, what are the gains?, 
if it's just a higher version can't it be F32 only?
___
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: koji web interface is very slow

[Kevin Fenzi]

On Fri, Oct 11, 2019 at 03:02:20PM -0600, Orion Poplawski wrote:
> On 10/11/19 12:20 PM, Kevin Fenzi wrote:
> > So to update this thread some: 
> > 
> > * Load is fine/responsiveness is fine as long as we aren't doing a
> > database dump.
> > * When we do, things slow down and load goes way up. 
> > 
> > We did find one very odd/bad thing on the virthost the server is on (one
> > drive in the raid is showing active in multipath and possibly getting
> > copies of all i/o sent to it? unclear exactly, but it's wrong and needs
> > fixing). 
> > 
> > So, we stopped the backup and we are going to wait until 21UTC 
> > (after 5pm EDT). At that point we will try and clean up that multipath
> > issue and see if that helps things. If not we will try and tune the
> > vm/database more until we have it responsive all the time. 
> > We hope we can do these changes with minimal to no downtime, but there
> > may be some. 
> > 
> > I've filed https://pagure.io/fedora-infrastructure/issue/8292 on this
> > issue, folks are welcome to follow along there. 
> > 
> > Sorry about all this, I was just hoping to make things faster and sadly,
> > did not. 
> > 
> 
> Thanks for working on this, your help is greatly appreciated.

No problem... koji is something we really want working smoothly. 

It's too early to tell, but I am running a backup now and while the load
is going up a bit, things are still responsive. 

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

Re: Fedora 32 Self-Contained Change proposal: Free Pascal Compiler 3.2.0

[Artur Iwicki]

Yes, dependent packages should use %{fpc_arches}. FPC itself doesn't do that.

I imagine the reason is that this allows us to add new architectures to FPC and 
do some trial-and-error builds of FPC without affecting dependent packages - if 
FPC itself used %{fpc_arches}, then adding new architectures to FPC would 
require updating fpc-rpm-macros, and that would make all dependent packages 
fail to build, since the new-arch builds would fail with "Package not found: 
fpc" until we got FPC available on those.
___
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

Unretiring the tolua++ package

[Hans de Goede]

Hi All,

Per the 
https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers#Claiming_Ownership_of_a_Retired_Package
procedure here is a mail to let people know I have filed a request to
unretire tolua++:  https://pagure.io/releng/issue/8895

tolua++ was retired as part of the recent semi-automated retiring of packages
which FTBFS, but I just found out that we still have several libraries depending
on it and then a bunch of packages depending on these libraries. So currently we
have a bunch of broken deps in the F31 repo.

Therefore I have requested to become the owner of the tolua++ package and to
unretire tolua++, I will take care of the FTBFS issue.

Note the depending packages were not listed in the orphan reports to the devel 
list,
likely due to this dnf bug: https://bugzilla.redhat.com/show_bug.cgi?id=1760772

Regards,

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

Unretiring the tolua++ package

[Hans de Goede]

Hi All,

Per the 
https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers#Claiming_Ownership_of_a_Retired_Package
procedure here is a mail to let people know I have filed a request to
unretire tolua++:  https://pagure.io/releng/issue/8895

tolua++ was retired as part of the recent semi-automated retiring of packages
which FTBFS, but I just found out that we still have several libraries depending
on it and then a bunch of packages depending on these libraries. So currently we
have a bunch of broken deps in the F31 repo.

Therefore I have requested to become the owner of the tolua++ package and to
unretire tolua++, I will take care of the FTBFS issue.

Note the depending packages were not listed in the orphan reports to the devel 
list,
likely due to this dnf bug: https://bugzilla.redhat.com/show_bug.cgi?id=1760772

Regards,

Hans
___
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 32 Self-Contained Change proposal: Free Pascal Compiler 3.2.0

[Mattia Verga via devel]

Il 11/10/19 11:39, Artur Iwicki ha scritto:
> Yes, dependent packages should use %{fpc_arches}. FPC itself doesn't do that.
>
Ah, I misunderstood the phrase `Add AArch64 and ppc64le to the 
`ExclusiveArch:` tag in the package spec.`.

I thought you were saying to add those ExclusiveArch to all packages 
which requires fpc, sorry.

Mattia

___
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: koji web interface is very slow

[Peter Robinson]

On Fri, Oct 11, 2019 at 10:13 AM Dominik 'Rathann' Mierzejewski
 wrote:
>
> On Friday, 11 October 2019 at 04:36, Orion Poplawski wrote:
> > On 10/10/19 4:57 PM, Orion Poplawski wrote:
> > > On 10/10/19 9:23 AM, Kevin Fenzi wrote:
> [...]
> > > > Pretty please can you all indicate approximately when (UTC) you were
> > > > seeing the slowness? I suspect it may be the nightly database dump job,
> > > > but I can't tell without knowing when you saw the slowness...
> [...]
> > > Thanks, it is much better now.  I feel like I've hit periods of slowness
> > > over several days recently so I will definitely note times if I run into
> > > it again.
> >
> > Definitely slower again:
> > Fri Oct 11 02:20:53 UTC 2019
>
> Fri 11 Oct 09:11:01 UTC 2019
> It takes 30s to show a build status page, e.g.
> https://koji.fedoraproject.org/koji/taskinfo?taskID=38215205

Builds/cli is slow on Fri 11th, 13:17 UTC.

P
___
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 32 Self-Contained Change proposal: Free Pascal Compiler 3.2.0

[Zbigniew Jędrzejewski-Szmek]

On Thu, Oct 10, 2019 at 10:35:23AM -0400, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/Free_Pascal_Compiler_3.2.0
> 
> == Summary ==
> Update the Free Pascal Compiler used within Fedora to version 3.2.0,
> once it is published, and enable building (previously unsupported)
> AArch64 and ppc64le packages using the compiler.

New arch support, \o/.

Zbyszek
___
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: Modularity and the system-upgrade path

[Stephen Gallagher]

On Thu, Oct 10, 2019 at 10:41 AM Lukas Ruzicka  wrote:

> Seeing the reaction of the Modularity WG ... I do not understand how it is
> possible that such important decisions are taken by 4 people without any
> Fedora wide discussions like this. And yet, it seems a little bit that even
> opinions on this list will not fall on fertile grounds.
>


To be clear, I am reading every single reply to this thread very carefully.
We *will* be taking all of this feedback into consideration, but please
understand that we're also trying to balance things. As Neal noted
upthread, we do have a responsibility to our downstream to make sure that
we do not break the ability to manage default streams. This becomes much
more difficult if we cannot have them in Fedora, because the testing of
them is lost. Additionally, no one on the WG disagrees with you that the
current state of things is undesirable. I take a moderate amount of offense
to the repeated insinuations that the solutions we are building are
"hacks". Yes, there's a proposal to work around the upgrade issue to F31
that is absolutely a one-off hack to buy time. But our plans for how
upgrades should work long-term as well as how defaults need to behave in
the distro are being considered very carefully. We are trying to avoid
breakage and to make the process simpler, but we are also shoring up the
bridge while crossing it.

We are absolutely considering the option of disallowing default streams in
Fedora, but we *really* don't want to rush into that. For one thing, we do
have a number of packages that have moved to modules-only that would have
to convert back. For some projects, this is probably just an annoyance, but
for others this may be a major impediment. In particular, one of the
advantages of Modularity is the ability to have buildroot-only packages
that are different from the base operating system (and don't end up
delivered as artifacts from the module). There are likely modules out there
that rely on this behavior because their build requires a newer or older
version of some package than the non-modular buildroot provides. This is
not the sole problem to address if we go the "no defaults" route, just the
first that came to mind. It's unclear to me right now if forcing everyone
back to the old behavior is less effort than fixing the remaining
Modularity issues. And since we need to fix them for RHEL as well anyway,
it's worth considering carefully if the added work is worthwhile.

I'm wary of assuming that this thread represents the whole of Fedoran
opinions, however. As we all know, it's generally the set of people who are
upset that speak up the loudest. I'm not discounting your concerns (far
from it!), but if we only base development decisions on "make sure no one
is upset about it", we'd never accomplish anything new at all. This is why
when I've been sending out these emails to discuss ideas, I've been trying
to carefully describe both the use-cases and the technical limitations
(both intrinsic to the design and those that are the result of imperfect
implementation) each time. It's somewhat disheartening to hear responses
that largely boil down to "If you can't get it perfectly right, stop
trying!".
___
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: koji web interface is very slow

[Stephen John Smoogen]

On Fri, 11 Oct 2019 at 09:19, Peter Robinson  wrote:
>
> On Fri, Oct 11, 2019 at 10:13 AM Dominik 'Rathann' Mierzejewski
>  wrote:
> >
> > On Friday, 11 October 2019 at 04:36, Orion Poplawski wrote:
> > > On 10/10/19 4:57 PM, Orion Poplawski wrote:
> > > > On 10/10/19 9:23 AM, Kevin Fenzi wrote:
> > [...]
> > > > > Pretty please can you all indicate approximately when (UTC) you were
> > > > > seeing the slowness? I suspect it may be the nightly database dump 
> > > > > job,
> > > > > but I can't tell without knowing when you saw the slowness...
> > [...]
> > > > Thanks, it is much better now.  I feel like I've hit periods of slowness
> > > > over several days recently so I will definitely note times if I run into
> > > > it again.
> > >
> > > Definitely slower again:
> > > Fri Oct 11 02:20:53 UTC 2019
> >
> > Fri 11 Oct 09:11:01 UTC 2019
> > It takes 30s to show a build status page, e.g.
> > https://koji.fedoraproject.org/koji/taskinfo?taskID=38215205
>
> Builds/cli is slow on Fri 11th, 13:17 UTC.

The fixes we tried seems to have put the load average of koji up to
150 while several mbs builds are going. I am going to put our status
as yellow and see if we can tune this down.


-- 
Stephen J Smoogen.
___
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: Unretiring the tolua++ package

[Hans de Goede]

Hi,

On 10/11/19 1:20 PM, Miro Hrončok wrote:

On 11. 10. 19 12:11, Hans de Goede wrote:

Hi All,

Per the 
https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers#Claiming_Ownership_of_a_Retired_Package
procedure here is a mail to let people know I have filed a request to
unretire tolua++:  https://pagure.io/releng/issue/8895

tolua++ was retired as part of the recent semi-automated retiring of packages
which FTBFS, but I just found out that we still have several libraries depending
on it and then a bunch of packages depending on these libraries. So currently we
have a bunch of broken deps in the F31 repo.

Therefore I have requested to become the owner of the tolua++ package and to
unretire tolua++, I will take care of the FTBFS issue.

Note the depending packages were not listed in the orphan reports to the devel 
list,
likely due to this dnf bug: https://bugzilla.redhat.com/show_bug.cgi?id=1760772



No dependent packages were listed in the orphan reports because the packages 
were not orphaned.

See:

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


Ah I see, I've added a comment to the releng issue.

Regards,

Hans
___
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: module package exclusion behavior on EL8

[Miroslav Suchý]

Dne 11. 10. 19 v 1:27 Orion Poplawski napsal(a):
I continue to run into strange (at least to me) issues with modules on EL8.  RHEL8 ships a 'rhn-tools' module that ships 
only the "koan" package from the cobbler srpm [1].  When this module is enabled, I cannot install cobbler from my copr - 
dnf reports that 'cobbler' is excluded.


Can someone fill me in more on this.? Is this expected?  I don't see anything in the module file (assuming I have the 
right module file) that specifically calls out cobbler for exclusion (such as a filter entry) - so is it just 
automatically creating an exclusion for all unshipped packages?


There is very little feedback from dnf - the cobbler package simply disappears:


When package with name FOO exists in a module, then package FOO from normal 
repos is masked. This is by design.
I learn it the hard way when we have been asked to implement module_hotfixes in 
Copr. See
https://bugzilla.redhat.com/show_bug.cgi?id=1758470
https://dnf.readthedocs.io/en/latest/modularity.html#package-filtering

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

Re: Heads-up: openQA scheduling outage over last 2 days

[Zbigniew Jędrzejewski-Szmek]

On Wed, Oct 09, 2019 at 08:21:37AM -0700, Adam Williamson wrote:
> Hey folks! Just to let folks know that the openQA job scheduling robot
> (for the production instance) had a bad day and needed to go lie down
> for a bit, so it didn't schedule any tests for any new composes or
> critpath updates that appeared from about Oct 07 17:08:42 UTC until
> about Oct 09 15:00:00 (about 20 minutes ago). Thanks to Christian
> Heimes for alerting me to this. I just gave it a mug of tea and a
> headache pill and some sympathetic conversation and it's back in top
> form and scheduling tests again; it's scheduled all the things it
> missed and the test system is catching up with the backlog, so results
> will start appearing for updates and composes that were missed soon.
> Sorry for any inconvenience.
Adam,

it's good to hear that the robot is in such good hands!
I wish it quick recovery and all the best for the upcoming
busy week.

Zbyszek
___
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: s390x: glibc32 and gcc

[Jerry James]

On Fri, Oct 11, 2019 at 5:08 AM Florian Weimer  wrote:
> And did not bump soname at the same time?  I suspected as much once I
> stared at the problem some more.

Yes, that's exactly right.

> Oh, if mpfr and mpc had bumped soname at the same time, the
> BuildRequires: change would not have been necessary.  But if these
> libraries are not coordinated in this way, then you are right, something
> like this has to be done (given that it's not possible to load mpfr
> twice at different versions, due to lack of symbol versioning).

Right.  That part is done now.  The gcc build has completed.  I just
need to build gawk, because it is in the default build root (and maybe
gdb, because of gdb-minimal; not sure on that one), and then we can
throw away the mpfr3 and libmpc-mpfr3 packages while everything else
rebuilds.

> We need to verify that we can still build a working bootloader on s390x,
> but that can wait until next week.

Sorry for not cluing you in sooner.  I sent email to the maintainers
of all the packages I need to rebuild, but that didn't include you.
I'll let you know as soon as these builds are tagged into Rawhide.
-- 
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

libdav1d SONAME bump

[Robert-André Mauchin]

Hello,

Dav1d 0.5.0 was published today and brings a SONAME bump from libdav1d.so.
2.0.0 to libdav1d.so.3.0.0.
I will be updating it next week on F31/32, consumers of these libraries 
(ffmpeg, xine-lib, vlc) will need to rebuild their packages.

Best regards,

Robert-André

___
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 32 Self-Contained Change proposal: Free Pascal Compiler 3.2.0

[Artur Iwicki]

FPC 3.2.0 hasn't been released yet - this Change Proposal is a bit of a early 
heads-up. The FPC website says it should be out before the end of the year. 
Once it's released, after updating rawhide, a COPR repo can be prepared.
___
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: s390x: glibc32 and gcc

[Florian Weimer]

* Jerry James:

> On Thu, Oct 10, 2019 at 12:39 AM Florian Weimer  wrote:
>> Sorry, I wasn't aware that you were trying to rebuild gcc this week.  I
>> spoke to Jakub about the glibc32 change, and he had no objections.
>>
>> It's not clear how you are handling the transition.  Why do you need to
>> change GCC build requirements?  Did anyone request this?
>>
>> I would have expected a run-time-only compat-mpfr library with the old
>> soname, so that GCC keeps working until it is rebuilt.
>
> It's a little trickier than you might expect, because of libmpc, which
> is also linked with mpfr.

And did not bump soname at the same time?  I suspected as much once I
stared at the problem some more.

> I don't understand your question about changing GCC build
> requirements.  They're changing *back* now, to what they were before
> the transition began; i.e., mpfr-devel and libmpc-devel.

Oh, if mpfr and mpc had bumped soname at the same time, the
BuildRequires: change would not have been necessary.  But if these
libraries are not coordinated in this way, then you are right, something
like this has to be done (given that it's not possible to load mpfr
twice at different versions, due to lack of symbol versioning).

> Thanks for responding so quickly.  I appreciate you fixing the gcc
> build and getting it restarted.  I expect it will finish while I am
> sleeping tonight, so I'll get the rest of the builds launched first
> thing in the morning tomorrow.  Given that we still have to get
> through the flint-Singular-polymake-sagemath sequence of builds, they
> probably won't finish until Sunday night, or possibly even Monday
> morning.  I appreciate everybody's patience with this process.

We need to verify that we can still build a working bootloader on s390x,
but that can wait until next week.

Thanks,
Florian
___
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: Unretiring the tolua++ package

[Miro Hrončok]

On 11. 10. 19 12:11, Hans de Goede wrote:

Hi All,

Per the 
https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers#Claiming_Ownership_of_a_Retired_Package 


procedure here is a mail to let people know I have filed a request to
unretire tolua++:  https://pagure.io/releng/issue/8895

tolua++ was retired as part of the recent semi-automated retiring of packages
which FTBFS, but I just found out that we still have several libraries depending
on it and then a bunch of packages depending on these libraries. So currently we
have a bunch of broken deps in the F31 repo.

Therefore I have requested to become the owner of the tolua++ package and to
unretire tolua++, I will take care of the FTBFS issue.

Note the depending packages were not listed in the orphan reports to the devel 
list,

likely due to this dnf bug: https://bugzilla.redhat.com/show_bug.cgi?id=1760772



No dependent packages were listed in the orphan reports because the packages 
were not orphaned.


See:

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

And:

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/NKFYAWL4GWYR37C6XA63JMNBZYEM6BI3/

--
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: Modularity and the system-upgrade path

[Simo Sorce]

On Fri, 2019-10-11 at 09:56 +0200, Daniel Mach wrote:
> On 10/7/19 8:55 PM, Simo Sorce wrote:
> > I have to ask,
> > given containers are so popular and can deal with any dependency
> > without conflicting with system installed binaries, should we really
> > continue with this very complicated modular design ?
> 
> There are only few people who fully understand how modularity works 
> today (contyk who designed modulemd, jmracek and me who implemented the 
> DNF part and few others). I agree that the modular design should be 
> simplified. If we don't lower the bar, the complexity might prevent from 
> wider adoption.

Yes, at the moment it is a too complex system.

> As a former release engineer, I'm personally unhappy about lack of 
> upgrade paths between module contexts and I believe that fixing this 
> part of modularity design could lead to desired simplification. 
> Unfortunately based on discussion I had with contyk yesterday, I don't 
> believe it's achievable without making *huge* changes in the modularity 
> design and the build infrastructure/process.

Well, the way I see it, if it is not usable we shouldn't inflict it on
users unless there is a clear and overwhelming technical advantage in
doing it. So far it eludes me what advantage modularity gives that is
so important.

> > Shouldn't we go back to have default packages and then defer to
> > "containers" for applications (and their dependencies) that need to
> > deviate from system defaults for any reason ?
> 
> I don't think containers can replace modularity. They need to coexist. 
> If we want to create containers built on top of a distribution (no 
> randomly picked bits from the internet, reproducible builds, security, 
> ...), we need a way to distribute multiple versions of the software 
> (module streams) and they frequently need to be built against each other 
>   (module contexts).

If modules were just an infrastructure artifact used to build
containers (or spins, or any other useful delivery mechanism) I
wouldn't be concerned, as then the people exposed to their complexity
would be people that know what they are doing and can decide to buy in
or not into the modules ecosystem.

My main gripe is the current situation where users are thrown under the
bus and then we give them a business card and say: read these
instruction to figure out how to save yourself.
I think this is unacceptable.

Simo.


> 
> > Simo.
> > 
> > On Fri, 2019-10-04 at 10:57 -0400, Stephen Gallagher wrote:
> > > Right now, there are two conflicting requirements in Fedora Modularity
> > > that we need to resolve.
> > > 
> > > 1. Once a user has selected a stream, updates should follow that
> > > stream and not introduce incompatiblities. Selected streams should not
> > > be changed without direct action from the user.
> > > 2. So far as possible, Modularity should be invisible to those who
> > > don't specifically need it. This means being able to set default
> > > streams so that `yum install package` works for module-provided
> > > content.
> > > 
> > > Where this becomes an issue is at system-upgrade time (moving from
> > > Fedora 30->31 or continuously tracking Rawhide). Because of
> > > requirement 1, we cannot automatically move users between streams, but
> > > in the case of release upgrades we often want to move to a new default
> > > for the distribution.
> > > 
> > > 
> > > The Modularity WG has generally agreed that we want and need to
> > > support behavior of the following use-cases:
> > > 
> > > 
> > > Use Case 1:
> > > 
> > > On Fedora 30, user Alice runs
> > > 
> > > yum install Foo
> > > 
> > > The package "Foo" is provided by a module "foo" with a default stream
> > > "v1.0". Because it's available in a default stream, the package is
> > > installed and the module stream "foo:v1.0" is implicitly enabled for
> > > the system.
> > > 
> > > 
> > > 
> > > Fedora 31 is released. On Fedora 31, the module "foo" has a new
> > > default stream "v1.1". When upgrading from Fedora 30 to Fedora 31,
> > > Alice expects the package Foo she installed to be upgraded to version
> > > 1.1, because that's what would have happened if it was provided as a
> > > package from the non-modular repositories.
> > > 
> > > 
> > > 
> > > Use Case 2:
> > > 
> > > On Fedora 30, user Bob runs
> > > 
> > > yum enable foo:v1.0
> > > 
> > > In this case, the "v1.0" stream of the "foo" module has a dependency
> > > on the "v2.4" stream of the "bar" module. So when enabling "foo:v1.0",
> > > the system also implicitly enables "bar:v2.4".
> > > 
> > > 
> > > 
> > > Fedora 31 is released. On Fedora 31, the module stream "foo:v1.0" now
> > > depends on "bar:v2.5" instead of "bar:v2.4". The user, caring only
> > > about "foo:v1.0" would expect the upgrade to complete, adjusting the
> > > dependencies as needed.
> > > 
> > > 
> > > At Flock and other discussions, we've generally come up with a
> > > solution, but it's not yet recorded anywhere. I'm sending it out for
> > > wider input, 

Fedora 31 compose report: 20191011.n.0 changes

[Fedora Branched Report]

OLD: Fedora-31-20191010.n.0
NEW: Fedora-31-20191011.n.0

= SUMMARY =
Added images:0
Dropped images:  0
Added packages:  2
Dropped packages:1
Upgraded packages:   50
Downgraded packages: 0

Size of added packages:  7.63 MiB
Size of dropped packages:834.47 KiB
Size of upgraded packages:   633.17 MiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   310.19 KiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =

= DROPPED IMAGES =

= ADDED PACKAGES =
Package: ara-0.16.1-2.fc30
Summary: ARA Records Ansible playbook runs
RPMs:ara ara-common ara-doc python3-ara python3-ara-tests
Size:6.85 MiB

Package: libresample-0.1.3-29.fc29
Summary: A real-time library for audio sampling rate conversion
RPMs:libresample libresample-devel
Size:794.39 KiB


= DROPPED PACKAGES =
Package: amavisd-new-2.12.0-2.fc31
Summary: Email filter with virus scanner and spamassassin support
RPMs:amavisd-new amavisd-new-doc amavisd-new-snmp
Size:834.47 KiB


= UPGRADED PACKAGES =
Package:  accerciser-3.34.1-1.fc31
Old package:  accerciser-3.34.0-1.fc31
Summary:  Interactive Python accessibility explorer for the GNOME desktop
RPMs: accerciser
Size: 2.52 MiB
Size change:  1.91 KiB
Changelog:
  * Mon Oct 07 2019 Kalev Lember  - 3.34.1-1
  - Update to 3.34.1


Package:  almanah-0.12.0-1.fc31
Old package:  almanah-0.11.1-26.fc31
Summary:  Application for keeping an encrypted diary
RPMs: almanah
Size: 1.29 MiB
Size change:  -80.28 KiB
Changelog:
  * Mon Oct 07 2019 Kalev Lember  - 0.12.0-1
  - Update to 0.12.0
  - Switch to the meson build system
  - Remove obsolete GConf schemas scriptlet
  - Update source URLs
  - Use license macro for COPYING


Package:  at-spi2-atk-2.34.1-1.fc31
Old package:  at-spi2-atk-2.34.0-1.fc31
Summary:  A GTK+ module that bridges ATK to D-Bus at-spi
RPMs: at-spi2-atk at-spi2-atk-devel
Size: 590.52 KiB
Size change:  -281 B
Changelog:
  * Mon Oct 07 2019 Kalev Lember  - 2.34.1-1
  - Update to 2.34.1


Package:  eog-3.34.1-1.fc31
Old package:  eog-3.34.0-2.fc31
Summary:  Eye of GNOME image viewer
RPMs: eog eog-devel eog-tests
Size: 19.19 MiB
Size change:  18.37 KiB
Changelog:
  * Mon Oct 07 2019 Kalev Lember  - 3.34.1-1
  - Update to 3.34.1


Package:  epiphany-1:3.34.1-1.fc31
Old package:  epiphany-1:3.34.0-1.fc31
Summary:  Web browser for GNOME
RPMs: epiphany epiphany-runtime
Size: 23.65 MiB
Size change:  14.54 KiB
Changelog:
  * Mon Oct 07 2019 Kalev Lember  - 1:3.34.1-1
  - Update to 3.34.1


Package:  evince-3.34.1-1.fc31
Old package:  evince-3.34.0-1.fc31
Summary:  Document viewer
RPMs: evince evince-devel evince-djvu evince-dvi evince-libs 
evince-nautilus
Size: 11.34 MiB
Size change:  4.72 KiB
Changelog:
  * Mon Oct 07 2019 Kalev Lember  - 3.34.1-1
  - Update to 3.34.1


Package:  evolution-3.34.1-1.fc31
Old package:  evolution-3.34.0-1.fc31
Summary:  Mail and calendar client for GNOME
RPMs: evolution evolution-bogofilter evolution-devel 
evolution-devel-docs evolution-help evolution-langpacks evolution-pst 
evolution-spamassassin
Size: 28.31 MiB
Size change:  -27.00 KiB
Changelog:
  * Mon Oct 07 2019 Milan Crha  - 3.34.1-1
  - Update to 3.34.1


Package:  evolution-data-server-3.34.1-1.fc31
Old package:  evolution-data-server-3.34.0-1.fc31
Summary:  Backend data server for Evolution
RPMs: evolution-data-server evolution-data-server-devel 
evolution-data-server-doc evolution-data-server-langpacks 
evolution-data-server-perl evolution-data-server-tests
Size: 22.36 MiB
Size change:  -9.52 KiB
Changelog:
  * Mon Oct 07 2019 Milan Crha  - 3.34.1-1
  - Update to 3.34.1


Package:  evolution-ews-3.34.1-1.fc31
Old package:  evolution-ews-3.34.0-1.fc31
Summary:  Evolution extension for Exchange Web Services
RPMs: evolution-ews evolution-ews-langpacks
Size: 2.22 MiB
Size change:  2.32 KiB
Changelog:
  * Mon Oct 07 2019 Milan Crha  - 3.34.1-1
  - Update to 3.34.1


Package:  evolution-mapi-3.34.1-1.fc31
Old package:  evolution-mapi-3.34.0-1.fc31
Summary:  Evolution extension for MS Exchange 2007 servers
RPMs: evolution-mapi evolution-mapi-langpacks
Size: 1.64 MiB
Size change:  -929 B
Changelog:
  * Mon Oct 07 2019 Milan Crha  - 3.34.1-1
  - Update to 3.34.1


Package:  four-in-a-row-3.34.1-1.fc31
Old package:  four-in-a-row-3.34.0-1.fc31
Summary:  GNOME Four-in-a-row game
RPMs: four-in-a-row
Size: 2.62 MiB
Size change:  268 B
Changelog:
  * Mon Oct 07 2019 Kalev Lember  - 3.34.1-1
  - Update to 3.34.1


Package:  fwupd-1.2.11-2.fc31
Old package:  fwupd-1.2.11-1.fc31
Summary:  Firmware update daemon
RPMs: fwupd fwupd-devel fwupd-tests
Size: 12.82 MiB
Size change:  1.29 KiB
Changelog:
  * Tue Oct 08 2019 Richard Hughes

Re: Modularity and the system-upgrade path

[Lukas Ruzicka]

I don't think containers can replace modularity. They need to coexist.
> If we want to create containers built on top of a distribution (no
> randomly picked bits from the internet, reproducible builds, security,
> ...), we need a way to distribute multiple versions of the software
> (module streams) and they frequently need to be built against each other
>   (module contexts).
>
>
Once I was told, that the purpose of modularity is to enable people to
create containers with
any software version they long for.

This totally has made sense to me, because containers usually only serve a
specific purpose, so
it is easier to pick up correct software versions and limit their
combinations, for example for a LAMP container
or something like that, and it is not so crucial that some other
application might not be fully compatible with that,
because I could create another container with the other application.

System-wide? That is another story, because here we need 100% compatibility
for everything, because we
never can think of combinations of applications and use cases, that
Workstation users long for.

With modularity, we could make Fedora a great distro for developers. But I
would like to see Fedora being the
distro for everyone, and not just developers. Therefore, we need to be as
versatile as possible.
I also have a slogan:

WHATEVER YOU HAVE EXPECTED FROM AN OS ... YOU FIND IT WITH FEDORA.

Let's do it perfect.




>
> >
> > Simo.
> >
> > On Fri, 2019-10-04 at 10:57 -0400, Stephen Gallagher wrote:
> >> Right now, there are two conflicting requirements in Fedora Modularity
> >> that we need to resolve.
> >>
> >> 1. Once a user has selected a stream, updates should follow that
> >> stream and not introduce incompatiblities. Selected streams should not
> >> be changed without direct action from the user.
> >> 2. So far as possible, Modularity should be invisible to those who
> >> don't specifically need it. This means being able to set default
> >> streams so that `yum install package` works for module-provided
> >> content.
> >>
> >> Where this becomes an issue is at system-upgrade time (moving from
> >> Fedora 30->31 or continuously tracking Rawhide). Because of
> >> requirement 1, we cannot automatically move users between streams, but
> >> in the case of release upgrades we often want to move to a new default
> >> for the distribution.
> >>
> >>
> >> The Modularity WG has generally agreed that we want and need to
> >> support behavior of the following use-cases:
> >>
> >>
> >> Use Case 1:
> >>
> >> On Fedora 30, user Alice runs
> >>
> >> yum install Foo
> >>
> >> The package "Foo" is provided by a module "foo" with a default stream
> >> "v1.0". Because it's available in a default stream, the package is
> >> installed and the module stream "foo:v1.0" is implicitly enabled for
> >> the system.
> >>
> >>
> >>
> >> Fedora 31 is released. On Fedora 31, the module "foo" has a new
> >> default stream "v1.1". When upgrading from Fedora 30 to Fedora 31,
> >> Alice expects the package Foo she installed to be upgraded to version
> >> 1.1, because that's what would have happened if it was provided as a
> >> package from the non-modular repositories.
> >>
> >>
> >>
> >> Use Case 2:
> >>
> >> On Fedora 30, user Bob runs
> >>
> >> yum enable foo:v1.0
> >>
> >> In this case, the "v1.0" stream of the "foo" module has a dependency
> >> on the "v2.4" stream of the "bar" module. So when enabling "foo:v1.0",
> >> the system also implicitly enables "bar:v2.4".
> >>
> >>
> >>
> >> Fedora 31 is released. On Fedora 31, the module stream "foo:v1.0" now
> >> depends on "bar:v2.5" instead of "bar:v2.4". The user, caring only
> >> about "foo:v1.0" would expect the upgrade to complete, adjusting the
> >> dependencies as needed.
> >>
> >>
> >> At Flock and other discussions, we've generally come up with a
> >> solution, but it's not yet recorded anywhere. I'm sending it out for
> >> wider input, but this is more or less the solution we intend to run
> >> with, barring someone finding a severe flaw.
> >>
> >> Proposed Solution:
> >>
> >> What happens today is that once the stream is set, it is fixed and
> >> unchangeable except by user decision. Through discussions with UX
> >> folks, we've more or less come to the decision that the correct
> >> behavior is as follows:
> >>
> >> * The user's "intention" should be recorded at the time of module
> >> enablement. Currently, module streams can exist in four states:
> >> "available, enabled, disabled, default". We propose that there should
> >> be two additional states (names TBD) representing implicit enablement.
> >> The state "enabled" would be reserved for any stream that at some
> >> point was enabled by name. For example, a user who runs `yum install
> >> freeipa:DL1` is making a conscious choice to install the DL1 stream of
> >> freeipa. A user who runs `yum install freeipa-client` is instead
> >> saying "give me whatever freeipa-client is the default".
> >>
> >> * The state 

[Bug 1758719] Plans for EPEL8

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|NEW |MODIFIED



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

-- 
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 1756029] [RFE] perl-LWP-UserAgent-Determined build for epel8

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|NEW |MODIFIED



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

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

pghmcfc pushed to perl-Test2-Plugin-NoWarnings (epel8). "We provide Test2::Event::Warning so we don't need to build-require it"

[notifications]

Notification time stamped 2019-10-11 18:09:59 UTC

From 97acaba71a36ff87d3536c514e622caecbf3d17d Mon Sep 17 00:00:00 2001
From: Paul Howarth 
Date: Oct 27 2016 10:57:15 +
Subject: We provide Test2::Event::Warning so we don't need to build-require it


---

diff --git a/perl-Test2-Plugin-NoWarnings.spec 
b/perl-Test2-Plugin-NoWarnings.spec
index 299d21a..f10d13f 100644
--- a/perl-Test2-Plugin-NoWarnings.spec
+++ b/perl-Test2-Plugin-NoWarnings.spec
@@ -1,6 +1,6 @@
 Name:  perl-Test2-Plugin-NoWarnings
 Version:   0.04
-Release:   1%{?dist}
+Release:   2%{?dist}
 Summary:   Fail if tests warn
 License:   Artistic 2.0
 URL:   http://search.cpan.org/dist/Test2-Plugin-NoWarnings/
@@ -18,7 +18,6 @@ BuildRequires:perl(parent)
 BuildRequires: perl(strict)
 BuildRequires: perl(Test2::API)
 BuildRequires: perl(Test2::Event)
-BuildRequires: perl(Test2::Event::Warning)
 BuildRequires: perl(Test2::Util::HashBase)
 BuildRequires: perl(warnings)
 # Test Suite
@@ -63,6 +62,9 @@ make test
 %{_mandir}/man3/Test2::Plugin::NoWarnings.3*
 
 %changelog
+* Thu Oct 27 2016 Paul Howarth  - 0.04-2
+- We provide Test2::Event::Warning so we don't need to build-require it
+
 * Mon Oct 24 2016 Paul Howarth  - 0.04-1
 - Update to 0.04
   - Load Test2::Event::Warning in the plugin instead of relying on Test2 to do



https://src.fedoraproject.org/rpms/perl-Test2-Plugin-NoWarnings/c/97acaba71a36ff87d3536c514e622caecbf3d17d?branch=epel8
___
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

pghmcfc pushed to perl-Test2-Plugin-NoWarnings (epel8). "Update to 0.04 (..more)"

[notifications]

Notification time stamped 2019-10-11 18:09:59 UTC

From 0758fd7c03096d870405dac0b551e723a1fcbbfb Mon Sep 17 00:00:00 2001
From: Paul Howarth 
Date: Oct 24 2016 08:51:13 +
Subject: Update to 0.04


- New upstream release 0.04
  - Load Test2::Event::Warning in the plugin instead of relying on Test2 to do
it for us; this should avoid the bug fixed in the previous version and
eliminates the need for the INIT block, which caused its own problems

---

diff --git a/perl-Test2-Plugin-NoWarnings.spec 
b/perl-Test2-Plugin-NoWarnings.spec
index 2ebefcb..299d21a 100644
--- a/perl-Test2-Plugin-NoWarnings.spec
+++ b/perl-Test2-Plugin-NoWarnings.spec
@@ -1,5 +1,5 @@
 Name:  perl-Test2-Plugin-NoWarnings
-Version:   0.03
+Version:   0.04
 Release:   1%{?dist}
 Summary:   Fail if tests warn
 License:   Artistic 2.0
@@ -18,6 +18,7 @@ BuildRequires:perl(parent)
 BuildRequires: perl(strict)
 BuildRequires: perl(Test2::API)
 BuildRequires: perl(Test2::Event)
+BuildRequires: perl(Test2::Event::Warning)
 BuildRequires: perl(Test2::Util::HashBase)
 BuildRequires: perl(warnings)
 # Test Suite
@@ -62,6 +63,12 @@ make test
 %{_mandir}/man3/Test2::Plugin::NoWarnings.3*
 
 %changelog
+* Mon Oct 24 2016 Paul Howarth  - 0.04-1
+- Update to 0.04
+  - Load Test2::Event::Warning in the plugin instead of relying on Test2 to do
+it for us; this should avoid the bug fixed in the previous version and
+eliminates the need for the INIT block, which caused its own problems
+
 * Tue Oct 18 2016 Paul Howarth  - 0.03-1
 - Update to 0.03
   - Add the $SIG{__WARN__} hook in an INIT block; we really don't want to
diff --git a/sources b/sources
index d536ba9..c31253b 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-e3f286c4cb9806a6eb083de902a1998b  Test2-Plugin-NoWarnings-0.03.tar.gz
+e26bb1795ee9a0d382063977026cf795  Test2-Plugin-NoWarnings-0.04.tar.gz



https://src.fedoraproject.org/rpms/perl-Test2-Plugin-NoWarnings/c/0758fd7c03096d870405dac0b551e723a1fcbbfb?branch=epel8
___
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 1760944] New: perl-Math-BigInt-1.999817 is available

[bugzilla]

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

Bug ID: 1760944
   Summary: perl-Math-BigInt-1.999817 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Math-BigInt
  Keywords: FutureFeature, Triaged
  Assignee: ppi...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 1.999817
Current version/release in rawhide: 1.9998.16-439.fc31
URL: http://search.cpan.org/dist/Math-BigInt/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy


More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring


Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.


Based on the information from anitya:
https://release-monitoring.org/project/7954/

-- 
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 1760943] New: perl-Math-BigInt-FastCalc-0.5009 is available

[bugzilla]

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

Bug ID: 1760943
   Summary: perl-Math-BigInt-FastCalc-0.5009 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Math-BigInt-FastCalc
  Keywords: FutureFeature, Triaged
  Assignee: ppi...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 0.5009
Current version/release in rawhide: 0.500.800-439.fc31
URL: http://search.cpan.org/dist/Math-BigInt-FastCalc/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy


More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring


Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.


Based on the information from anitya:
https://release-monitoring.org/project/12782/

-- 
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 1760942] New: perl-Math-BigInt-GMP-1.6007 is available

[bugzilla]

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

Bug ID: 1760942
   Summary: perl-Math-BigInt-GMP-1.6007 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Math-BigInt-GMP
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: jples...@redhat.com, p...@city-fan.org,
perl-devel@lists.fedoraproject.org, st...@silug.org
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 1.6007
Current version/release in rawhide: 1.6006-4.fc31
URL: http://search.cpan.org/dist/Math-BigInt-GMP/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy


More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring


Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.


Based on the information from anitya:
https://release-monitoring.org/project/7529/

-- 
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 1756029] [RFE] perl-LWP-UserAgent-Determined build for epel8

[bugzilla]

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



--- Comment #1 from Andrew Bauer  ---
Huh, don't know how I missed this. 

Epel8 branch has been requested:
https://pagure.io/releng/fedora-scm-requests/issue/18180

I'll build it as soon as this goes through.

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

pghmcfc pushed to perl-Test2-Plugin-NoWarnings (epel8). "Perl 5.30 rebuild"

[notifications]

Notification time stamped 2019-10-11 18:09:59 UTC

From 74997f22e5320541c22b4f624a4a3eb7228551ca Mon Sep 17 00:00:00 2001
From: Jitka Plesnikova 
Date: Oct 11 2019 18:09:09 +
Subject: Perl 5.30 rebuild


---

diff --git a/perl-Test2-Plugin-NoWarnings.spec 
b/perl-Test2-Plugin-NoWarnings.spec
index a44860f..e61327d 100644
--- a/perl-Test2-Plugin-NoWarnings.spec
+++ b/perl-Test2-Plugin-NoWarnings.spec
@@ -1,6 +1,6 @@
 Name:  perl-Test2-Plugin-NoWarnings
 Version:   0.07
-Release:   1%{?dist}
+Release:   2%{?dist}
 Summary:   Fail if tests warn
 License:   Artistic 2.0
 URL:   https://metacpan.org/release/Test2-Plugin-NoWarnings
@@ -64,6 +64,9 @@ make test
 %{_mandir}/man3/Test2::Plugin::NoWarnings.3*
 
 %changelog
+* Fri May 31 2019 Jitka Plesnikova  - 0.07-2
+- Perl 5.30 rebuild
+
 * Mon Apr 22 2019 Paul Howarth  - 0.07-1
 - Update to 0.07
   - Reverted back to using the Warning event type, since the bug in the Test2



https://src.fedoraproject.org/rpms/perl-Test2-Plugin-NoWarnings/c/74997f22e5320541c22b4f624a4a3eb7228551ca?branch=epel8
___
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

pghmcfc pushed to perl-Test2-Plugin-NoWarnings (epel8). "Merge remote-tracking branch 'origin/f28' into epel8"

[notifications]

Notification time stamped 2019-10-11 18:09:59 UTC

From 147648083fe38430881ca93bbf8bd3250c2c4b7c Mon Sep 17 00:00:00 2001
From: Paul Howarth 
Date: Oct 11 2019 18:08:49 +
Subject: Merge remote-tracking branch 'origin/f28' into epel8


---

diff --git a/.gitignore b/.gitignore
index e69de29..1650141 100644
--- a/.gitignore
+++ b/.gitignore
@@ -0,0 +1 @@
+/Test2-Plugin-NoWarnings-[0-9.]*.tar.gz
diff --git a/perl-Test2-Plugin-NoWarnings.spec 
b/perl-Test2-Plugin-NoWarnings.spec
new file mode 100644
index 000..e7699bb
--- /dev/null
+++ b/perl-Test2-Plugin-NoWarnings.spec
@@ -0,0 +1,117 @@
+Name:  perl-Test2-Plugin-NoWarnings
+Version:   0.06
+Release:   3%{?dist}
+Summary:   Fail if tests warn
+License:   Artistic 2.0
+URL:   http://search.cpan.org/dist/Test2-Plugin-NoWarnings/
+Source0:   
http://search.cpan.org/CPAN/authors/id/D/DR/DROLSKY/Test2-Plugin-NoWarnings-%{version}.tar.gz
+BuildArch: noarch
+# Build
+BuildRequires: coreutils
+BuildRequires: make
+BuildRequires: perl-interpreter
+BuildRequires: perl-generators
+BuildRequires: perl(ExtUtils::MakeMaker) > 6.75
+# Module Runtime
+BuildRequires: perl(Carp)
+BuildRequires: perl(parent)
+BuildRequires: perl(strict)
+BuildRequires: perl(Test2::API)
+BuildRequires: perl(Test2::Event)
+BuildRequires: perl(Test2::Util::HashBase)
+BuildRequires: perl(warnings)
+# Test Suite
+BuildRequires: perl(File::Spec)
+BuildRequires: perl(IPC::Run3)
+BuildRequires: perl(Test2::Bundle::Extended)
+BuildRequires: perl(Test2::Require::Module)
+BuildRequires: perl(Test::More) >= 0.96
+# Optional Tests
+BuildRequires: perl(CPAN::Meta) >= 2.120900
+BuildRequires: perl(CPAN::Meta::Prereqs)
+# Dependencies
+Requires:  perl(:MODULE_COMPAT_%(eval "`perl -V:version`"; echo $version))
+
+%description
+Loading this plugin causes your tests to fail if there are any warnings while
+they run. Each warning generates a new failing test and the warning content is
+outputted via diag.
+
+This module uses $SIG{__WARN__}, so if the code you're testing sets this, then
+this module will stop working.
+
+%prep
+%setup -q -n Test2-Plugin-NoWarnings-%{version}
+
+%build
+perl Makefile.PL INSTALLDIRS=vendor NO_PERLLOCAL=1 NO_PACKLIST=1
+make %{?_smp_mflags}
+
+%install
+make install DESTDIR=%{buildroot}
+%{_fixperms} -c %{buildroot}
+
+%check
+make test
+
+%files
+%license LICENSE
+%doc Changes README.md
+%{perl_vendorlib}/Test2/
+%{_mandir}/man3/Test2::Event::Warning.3*
+%{_mandir}/man3/Test2::Plugin::NoWarnings.3*
+
+%changelog
+* Fri Feb 09 2018 Fedora Release Engineering  - 
0.06-3
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild
+
+* Thu Jul 27 2017 Fedora Release Engineering  - 
0.06-2
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_27_Mass_Rebuild
+
+* Mon Jun 19 2017 Paul Howarth  - 0.06-1
+- Update to 0.06
+  - Warnings inside a subtest were not emitted as TAP events, breaking the TAP
+and making for great confusion: this is because of a bug in the core TAP
+formatter (https://github.com/Test-More/test-more/issues/776); warnings
+are now emitted as Ok events instead of Warning events
+
+* Mon Jun 05 2017 Jitka Plesnikova  - 0.05-3
+- Perl 5.26 rebuild
+
+* Sat Feb 11 2017 Fedora Release Engineering  - 
0.05-2
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_26_Mass_Rebuild
+
+* Tue Nov  8 2016 Paul Howarth  - 0.05-1
+- Update to 0.05
+  - Skip compile.t on Windows; this test uses IPC::Run3, which doesn't seem to
+work well on that platform (CPAN RT#118443)
+
+* Thu Oct 27 2016 Paul Howarth  - 0.04-2
+- We provide Test2::Event::Warning so we don't need to build-require it
+
+* Mon Oct 24 2016 Paul Howarth  - 0.04-1
+- Update to 0.04
+  - Load Test2::Event::Warning in the plugin instead of relying on Test2 to do
+it for us; this should avoid the bug fixed in the previous version and
+eliminates the need for the INIT block, which caused its own problems
+
+* Tue Oct 18 2016 Paul Howarth  - 0.03-1
+- Update to 0.03
+  - Add the $SIG{__WARN__} hook in an INIT block; we really don't want to
+trigger this because of a compile-time warning, and because of a bug in
+Test::Builder, this can actually cause the warning to be lost entirely
+(https://github.com/Test-More/test-more/issues/729)
+  - The Test2::Event::Warning event now returns true for increments_count,
+which means that the test failure caused by a warning will not be output
+as a TAP test line; previously this was just seen as a diag line, which
+could be quite confusing
+(https://github.com/Test-More/test-more/issues/728)
+
+* Mon Sep 19 2016 Paul Howarth  - 0.02-3
+- Drop unused BR: findutils (#1377228)
+
+* Mon Sep 19 2016 Paul Howarth  - 0.02-2
+- Sanitize for Fedora submission
+
+* Sun Sep 18 2016 Paul Howarth  - 0.02-1
+- Initial RPM version
diff --git a/sources b/sources
index e69de29..863c17f 100644
--- a/sources
+++ b/sources
@@ -0,0 +1 @@
+SHA512 (Test2-Plugin-NoWarnings-0.06.tar.gz) = 

pghmcfc pushed to perl-Test2-Plugin-NoWarnings (epel8). "Perl 5.26 rebuild"

[notifications]

Notification time stamped 2019-10-11 18:09:59 UTC

From 22eea02aab9a0f1d8db5e3627b0be2face9edf2b Mon Sep 17 00:00:00 2001
From: Jitka Plesnikova 
Date: Jun 05 2017 19:59:09 +
Subject: Perl 5.26 rebuild


---

diff --git a/perl-Test2-Plugin-NoWarnings.spec 
b/perl-Test2-Plugin-NoWarnings.spec
index 7f7bbb2..2a846a7 100644
--- a/perl-Test2-Plugin-NoWarnings.spec
+++ b/perl-Test2-Plugin-NoWarnings.spec
@@ -1,6 +1,6 @@
 Name:  perl-Test2-Plugin-NoWarnings
 Version:   0.05
-Release:   2%{?dist}
+Release:   3%{?dist}
 Summary:   Fail if tests warn
 License:   Artistic 2.0
 URL:   http://search.cpan.org/dist/Test2-Plugin-NoWarnings/
@@ -62,6 +62,9 @@ make test
 %{_mandir}/man3/Test2::Plugin::NoWarnings.3*
 
 %changelog
+* Mon Jun 05 2017 Jitka Plesnikova  - 0.05-3
+- Perl 5.26 rebuild
+
 * Sat Feb 11 2017 Fedora Release Engineering  - 
0.05-2
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_26_Mass_Rebuild
 



https://src.fedoraproject.org/rpms/perl-Test2-Plugin-NoWarnings/c/22eea02aab9a0f1d8db5e3627b0be2face9edf2b?branch=epel8
___
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

pghmcfc pushed to perl-Test2-Plugin-NoWarnings (epel8). "Update to 0.05 (..more)"

[notifications]

Notification time stamped 2019-10-11 18:09:59 UTC

From 614d507095a4690ec845dcb3eed31c51c8f040c8 Mon Sep 17 00:00:00 2001
From: Paul Howarth 
Date: Nov 08 2016 09:35:39 +
Subject: Update to 0.05


- New upstream release 0.05
  - Skip compile.t on Windows; this test uses IPC::Run3, which doesn't seem to
work well on that platform (CPAN RT#118443)

---

diff --git a/perl-Test2-Plugin-NoWarnings.spec 
b/perl-Test2-Plugin-NoWarnings.spec
index f10d13f..2e0d808 100644
--- a/perl-Test2-Plugin-NoWarnings.spec
+++ b/perl-Test2-Plugin-NoWarnings.spec
@@ -1,6 +1,6 @@
 Name:  perl-Test2-Plugin-NoWarnings
-Version:   0.04
-Release:   2%{?dist}
+Version:   0.05
+Release:   1%{?dist}
 Summary:   Fail if tests warn
 License:   Artistic 2.0
 URL:   http://search.cpan.org/dist/Test2-Plugin-NoWarnings/
@@ -62,6 +62,11 @@ make test
 %{_mandir}/man3/Test2::Plugin::NoWarnings.3*
 
 %changelog
+* Tue Nov  8 2016 Paul Howarth  - 0.05-1
+- Update to 0.05
+  - Skip compile.t on Windows; this test uses IPC::Run3, which doesn't seem to
+work well on that platform (CPAN RT#118443)
+
 * Thu Oct 27 2016 Paul Howarth  - 0.04-2
 - We provide Test2::Event::Warning so we don't need to build-require it
 
diff --git a/sources b/sources
index c31253b..ddd52af 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-e26bb1795ee9a0d382063977026cf795  Test2-Plugin-NoWarnings-0.04.tar.gz
+e3914fbf60baba3af083dc4d8adab802  Test2-Plugin-NoWarnings-0.05.tar.gz



https://src.fedoraproject.org/rpms/perl-Test2-Plugin-NoWarnings/c/614d507095a4690ec845dcb3eed31c51c8f040c8?branch=epel8
___
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

pghmcfc pushed to perl-Test2-Plugin-NoWarnings (epel8). "Initial import (perl-Test2-Plugin-NoWarnings-0.02-3) (..more)"

[notifications]

Notification time stamped 2019-10-11 18:09:59 UTC

From de8e111344105006d0653f93a6884d5a8f8da332 Mon Sep 17 00:00:00 2001
From: Paul Howarth 
Date: Sep 19 2016 13:16:18 +
Subject: Initial import (perl-Test2-Plugin-NoWarnings-0.02-3)


Loading this plugin causes your tests to fail if there are any warnings while
they run. Each warning generates a new failing test and the warning content is
outputted via diag.

This module uses $SIG{__WARN__}, so if the code you're testing sets this, then
this module will stop working.

---

diff --git a/.gitignore b/.gitignore
index e69de29..1650141 100644
--- a/.gitignore
+++ b/.gitignore
@@ -0,0 +1 @@
+/Test2-Plugin-NoWarnings-[0-9.]*.tar.gz
diff --git a/perl-Test2-Plugin-NoWarnings.spec 
b/perl-Test2-Plugin-NoWarnings.spec
new file mode 100644
index 000..bbdb88a
--- /dev/null
+++ b/perl-Test2-Plugin-NoWarnings.spec
@@ -0,0 +1,70 @@
+Name:  perl-Test2-Plugin-NoWarnings
+Version:   0.02
+Release:   3%{?dist}
+Summary:   Fail if tests warn
+License:   Artistic 2.0
+URL:   http://search.cpan.org/dist/Test2-Plugin-NoWarnings/
+Source0:   
http://search.cpan.org/CPAN/authors/id/D/DR/DROLSKY/Test2-Plugin-NoWarnings-%{version}.tar.gz
+BuildArch: noarch
+# Build
+BuildRequires: coreutils
+BuildRequires: make
+BuildRequires: perl
+BuildRequires: perl-generators
+BuildRequires: perl(ExtUtils::MakeMaker) > 6.75
+# Module Runtime
+BuildRequires: perl(Carp)
+BuildRequires: perl(parent)
+BuildRequires: perl(strict)
+BuildRequires: perl(Test2::API)
+BuildRequires: perl(Test2::Event)
+BuildRequires: perl(Test2::Util::HashBase)
+BuildRequires: perl(warnings)
+# Test Suite
+BuildRequires: perl(File::Spec)
+BuildRequires: perl(Test2::Bundle::Extended)
+BuildRequires: perl(Test::More) >= 0.96
+# Optional Tests
+BuildRequires: perl(CPAN::Meta) >= 2.120900
+BuildRequires: perl(CPAN::Meta::Prereqs)
+# Dependencies
+Requires:  perl(:MODULE_COMPAT_%(eval "`perl -V:version`"; echo $version))
+
+%description
+Loading this plugin causes your tests to fail if there are any warnings while
+they run. Each warning generates a new failing test and the warning content is
+outputted via diag.
+
+This module uses $SIG{__WARN__}, so if the code you're testing sets this, then
+this module will stop working.
+
+%prep
+%setup -q -n Test2-Plugin-NoWarnings-%{version}
+
+%build
+perl Makefile.PL INSTALLDIRS=vendor NO_PERLLOCAL=1 NO_PACKLIST=1
+make %{?_smp_mflags}
+
+%install
+make install DESTDIR=%{buildroot}
+%{_fixperms} %{buildroot}
+
+%check
+make test
+
+%files
+%license LICENSE
+%doc Changes README.md
+%{perl_vendorlib}/Test2/
+%{_mandir}/man3/Test2::Event::Warning.3*
+%{_mandir}/man3/Test2::Plugin::NoWarnings.3*
+
+%changelog
+* Mon Sep 19 2016 Paul Howarth  - 0.02-3
+- Drop unused BR: findutils (#1377228)
+
+* Mon Sep 19 2016 Paul Howarth  - 0.02-2
+- Sanitize for Fedora submission
+
+* Sun Sep 18 2016 Paul Howarth  - 0.02-1
+- Initial RPM version
diff --git a/sources b/sources
index e69de29..0f84cad 100644
--- a/sources
+++ b/sources
@@ -0,0 +1 @@
+61d01547afd86bf8e6ba6140ed340cd8  Test2-Plugin-NoWarnings-0.02.tar.gz



https://src.fedoraproject.org/rpms/perl-Test2-Plugin-NoWarnings/c/de8e111344105006d0653f93a6884d5a8f8da332?branch=epel8
___
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

pghmcfc pushed to perl-Test2-Plugin-NoWarnings (epel8). "cpan.org addresses moved to MetaCPAN "

[notifications]

Notification time stamped 2019-10-11 18:09:59 UTC

From 4a17e7ee409a3f11693c01d082f2cd0ed9d3baf1 Mon Sep 17 00:00:00 2001
From: Petr Písař 
Date: Oct 11 2019 18:09:09 +
Subject: cpan.org addresses moved to MetaCPAN 



---

diff --git a/perl-Test2-Plugin-NoWarnings.spec 
b/perl-Test2-Plugin-NoWarnings.spec
index e7699bb..024e6cc 100644
--- a/perl-Test2-Plugin-NoWarnings.spec
+++ b/perl-Test2-Plugin-NoWarnings.spec
@@ -3,8 +3,8 @@ Version:0.06
 Release:   3%{?dist}
 Summary:   Fail if tests warn
 License:   Artistic 2.0
-URL:   http://search.cpan.org/dist/Test2-Plugin-NoWarnings/
-Source0:   
http://search.cpan.org/CPAN/authors/id/D/DR/DROLSKY/Test2-Plugin-NoWarnings-%{version}.tar.gz
+URL:   https://metacpan.org/release/Test2-Plugin-NoWarnings
+Source0:   
https://cpan.metacpan.org/authors/id/D/DR/DROLSKY/Test2-Plugin-NoWarnings-%{version}.tar.gz
 BuildArch: noarch
 # Build
 BuildRequires: coreutils



https://src.fedoraproject.org/rpms/perl-Test2-Plugin-NoWarnings/c/4a17e7ee409a3f11693c01d082f2cd0ed9d3baf1?branch=epel8
___
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

pghmcfc pushed to perl-Test2-Plugin-NoWarnings (epel8). "- Rebuilt for https://fedoraproject.org/wiki/Fedora_26_Mass_Rebuild"

[notifications]

Notification time stamped 2019-10-11 18:09:59 UTC

From d87ebfa3218d3dfa18c6e46dc2f9fbb363f5e7a2 Mon Sep 17 00:00:00 2001
From: Fedora Release Engineering 
Date: Feb 11 2017 05:40:17 +
Subject: - Rebuilt for https://fedoraproject.org/wiki/Fedora_26_Mass_Rebuild


---

diff --git a/perl-Test2-Plugin-NoWarnings.spec 
b/perl-Test2-Plugin-NoWarnings.spec
index 2e0d808..7f7bbb2 100644
--- a/perl-Test2-Plugin-NoWarnings.spec
+++ b/perl-Test2-Plugin-NoWarnings.spec
@@ -1,6 +1,6 @@
 Name:  perl-Test2-Plugin-NoWarnings
 Version:   0.05
-Release:   1%{?dist}
+Release:   2%{?dist}
 Summary:   Fail if tests warn
 License:   Artistic 2.0
 URL:   http://search.cpan.org/dist/Test2-Plugin-NoWarnings/
@@ -62,6 +62,9 @@ make test
 %{_mandir}/man3/Test2::Plugin::NoWarnings.3*
 
 %changelog
+* Sat Feb 11 2017 Fedora Release Engineering  - 
0.05-2
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_26_Mass_Rebuild
+
 * Tue Nov  8 2016 Paul Howarth  - 0.05-1
 - Update to 0.05
   - Skip compile.t on Windows; this test uses IPC::Run3, which doesn't seem to



https://src.fedoraproject.org/rpms/perl-Test2-Plugin-NoWarnings/c/d87ebfa3218d3dfa18c6e46dc2f9fbb363f5e7a2?branch=epel8
___
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

pghmcfc pushed to perl-Test2-Plugin-NoWarnings (epel8). "perl dependency renamed to perl-interpreter "

[notifications]

Notification time stamped 2019-10-11 18:09:59 UTC

From 35811b744a24adb1db2d3d6310ed953d74ec0c18 Mon Sep 17 00:00:00 2001
From: Petr Písař 
Date: Jul 12 2017 12:28:40 +
Subject: perl dependency renamed to perl-interpreter 



---

diff --git a/perl-Test2-Plugin-NoWarnings.spec 
b/perl-Test2-Plugin-NoWarnings.spec
index 49914bf..45a4e47 100644
--- a/perl-Test2-Plugin-NoWarnings.spec
+++ b/perl-Test2-Plugin-NoWarnings.spec
@@ -9,7 +9,7 @@ BuildArch:  noarch
 # Build
 BuildRequires: coreutils
 BuildRequires: make
-BuildRequires: perl
+BuildRequires: perl-interpreter
 BuildRequires: perl-generators
 BuildRequires: perl(ExtUtils::MakeMaker) > 6.75
 # Module Runtime



https://src.fedoraproject.org/rpms/perl-Test2-Plugin-NoWarnings/c/35811b744a24adb1db2d3d6310ed953d74ec0c18?branch=epel8
___
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

pghmcfc pushed to perl-Test2-Plugin-NoWarnings (epel8). "- Rebuilt for https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild (..more)"

[notifications]

Notification time stamped 2019-10-11 18:09:59 UTC

From e4867736025164a981bcaab53619d2f1c076feb5 Mon Sep 17 00:00:00 2001
From: Fedora Release Engineering 
Date: Feb 09 2018 01:40:11 +
Subject: - Rebuilt for https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild


Signed-off-by: Fedora Release Engineering 

---

diff --git a/perl-Test2-Plugin-NoWarnings.spec 
b/perl-Test2-Plugin-NoWarnings.spec
index d039432..e7699bb 100644
--- a/perl-Test2-Plugin-NoWarnings.spec
+++ b/perl-Test2-Plugin-NoWarnings.spec
@@ -1,6 +1,6 @@
 Name:  perl-Test2-Plugin-NoWarnings
 Version:   0.06
-Release:   2%{?dist}
+Release:   3%{?dist}
 Summary:   Fail if tests warn
 License:   Artistic 2.0
 URL:   http://search.cpan.org/dist/Test2-Plugin-NoWarnings/
@@ -62,6 +62,9 @@ make test
 %{_mandir}/man3/Test2::Plugin::NoWarnings.3*
 
 %changelog
+* Fri Feb 09 2018 Fedora Release Engineering  - 
0.06-3
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild
+
 * Thu Jul 27 2017 Fedora Release Engineering  - 
0.06-2
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_27_Mass_Rebuild
 



https://src.fedoraproject.org/rpms/perl-Test2-Plugin-NoWarnings/c/e4867736025164a981bcaab53619d2f1c076feb5?branch=epel8
___
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

pghmcfc pushed to perl-Test2-Plugin-NoWarnings (epel8). "Update to 0.06 (..more)"

[notifications]

Notification time stamped 2019-10-11 18:09:59 UTC

From d53f4dcf0c902ebdf9a8b72f4d447ea3b065dcfc Mon Sep 17 00:00:00 2001
From: Paul Howarth 
Date: Jun 19 2017 08:36:36 +
Subject: Update to 0.06


- New upstream release 0.06
  - Warnings inside a subtest were not emitted as TAP events, breaking the TAP
and making for great confusion: this is because of a bug in the core TAP
formatter (https://github.com/Test-More/test-more/issues/776); warnings
are now emitted as Ok events instead of Warning events

---

diff --git a/perl-Test2-Plugin-NoWarnings.spec 
b/perl-Test2-Plugin-NoWarnings.spec
index 2a846a7..49914bf 100644
--- a/perl-Test2-Plugin-NoWarnings.spec
+++ b/perl-Test2-Plugin-NoWarnings.spec
@@ -1,6 +1,6 @@
 Name:  perl-Test2-Plugin-NoWarnings
-Version:   0.05
-Release:   3%{?dist}
+Version:   0.06
+Release:   1%{?dist}
 Summary:   Fail if tests warn
 License:   Artistic 2.0
 URL:   http://search.cpan.org/dist/Test2-Plugin-NoWarnings/
@@ -62,6 +62,13 @@ make test
 %{_mandir}/man3/Test2::Plugin::NoWarnings.3*
 
 %changelog
+* Mon Jun 19 2017 Paul Howarth  - 0.06-1
+- Update to 0.06
+  - Warnings inside a subtest were not emitted as TAP events, breaking the TAP
+and making for great confusion: this is because of a bug in the core TAP
+formatter (https://github.com/Test-More/test-more/issues/776); warnings
+are now emitted as Ok events instead of Warning events
+
 * Mon Jun 05 2017 Jitka Plesnikova  - 0.05-3
 - Perl 5.26 rebuild
 
diff --git a/sources b/sources
index ddd52af..863c17f 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-e3914fbf60baba3af083dc4d8adab802  Test2-Plugin-NoWarnings-0.05.tar.gz
+SHA512 (Test2-Plugin-NoWarnings-0.06.tar.gz) = 
aed9a3769085028adffd0aa7cbbe2d7d8b89b5f4768e47ae4155dcc1f4aa8fd47319ae7c87ddbc1ed08ca99e1d703eebb74977e88696ea4dcc1104a53332ade2



https://src.fedoraproject.org/rpms/perl-Test2-Plugin-NoWarnings/c/d53f4dcf0c902ebdf9a8b72f4d447ea3b065dcfc?branch=epel8
___
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

pghmcfc pushed to perl-Test2-Plugin-NoWarnings (epel8). "- Rebuilt for https://fedoraproject.org/wiki/Fedora_31_Mass_Rebuild (..more)"

[notifications]

Notification time stamped 2019-10-11 18:09:59 UTC

From 17eb18c1c04113c57dc04a547fef6993ab80e3a3 Mon Sep 17 00:00:00 2001
From: Fedora Release Engineering 
Date: Oct 11 2019 18:09:09 +
Subject: - Rebuilt for https://fedoraproject.org/wiki/Fedora_31_Mass_Rebuild


Signed-off-by: Fedora Release Engineering 

---

diff --git a/perl-Test2-Plugin-NoWarnings.spec 
b/perl-Test2-Plugin-NoWarnings.spec
index e61327d..357e2ed 100644
--- a/perl-Test2-Plugin-NoWarnings.spec
+++ b/perl-Test2-Plugin-NoWarnings.spec
@@ -1,6 +1,6 @@
 Name:  perl-Test2-Plugin-NoWarnings
 Version:   0.07
-Release:   2%{?dist}
+Release:   3%{?dist}
 Summary:   Fail if tests warn
 License:   Artistic 2.0
 URL:   https://metacpan.org/release/Test2-Plugin-NoWarnings
@@ -64,6 +64,9 @@ make test
 %{_mandir}/man3/Test2::Plugin::NoWarnings.3*
 
 %changelog
+* Fri Jul 26 2019 Fedora Release Engineering  - 
0.07-3
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_31_Mass_Rebuild
+
 * Fri May 31 2019 Jitka Plesnikova  - 0.07-2
 - Perl 5.30 rebuild
 



https://src.fedoraproject.org/rpms/perl-Test2-Plugin-NoWarnings/c/17eb18c1c04113c57dc04a547fef6993ab80e3a3?branch=epel8
___
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

pghmcfc pushed to perl-Test2-Plugin-NoWarnings (epel8). "- Rebuilt for https://fedoraproject.org/wiki/Fedora_27_Mass_Rebuild"

[notifications]

Notification time stamped 2019-10-11 18:09:59 UTC

From 0e07951d3578f513d9e7c63e3e94f397cfa86e02 Mon Sep 17 00:00:00 2001
From: Fedora Release Engineering 
Date: Jul 27 2017 06:38:49 +
Subject: - Rebuilt for https://fedoraproject.org/wiki/Fedora_27_Mass_Rebuild


---

diff --git a/perl-Test2-Plugin-NoWarnings.spec 
b/perl-Test2-Plugin-NoWarnings.spec
index 45a4e47..d039432 100644
--- a/perl-Test2-Plugin-NoWarnings.spec
+++ b/perl-Test2-Plugin-NoWarnings.spec
@@ -1,6 +1,6 @@
 Name:  perl-Test2-Plugin-NoWarnings
 Version:   0.06
-Release:   1%{?dist}
+Release:   2%{?dist}
 Summary:   Fail if tests warn
 License:   Artistic 2.0
 URL:   http://search.cpan.org/dist/Test2-Plugin-NoWarnings/
@@ -62,6 +62,9 @@ make test
 %{_mandir}/man3/Test2::Plugin::NoWarnings.3*
 
 %changelog
+* Thu Jul 27 2017 Fedora Release Engineering  - 
0.06-2
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_27_Mass_Rebuild
+
 * Mon Jun 19 2017 Paul Howarth  - 0.06-1
 - Update to 0.06
   - Warnings inside a subtest were not emitted as TAP events, breaking the TAP



https://src.fedoraproject.org/rpms/perl-Test2-Plugin-NoWarnings/c/0e07951d3578f513d9e7c63e3e94f397cfa86e02?branch=epel8
___
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

limb pushed to perl-Test2-Plugin-NoWarnings (epel8). ""Adding package.cfg file""

[notifications]

Notification time stamped 2019-10-11 18:01:14 UTC

From 0f18f4043d0bfe9838c4e8bc26a35d6c7ec3f053 Mon Sep 17 00:00:00 2001
From: Gwyn Ciesla 
Date: Oct 11 2019 18:01:07 +
Subject: "Adding package.cfg file"


---

diff --git a/package.cfg b/package.cfg
new file mode 100644
index 000..66ea79d
--- /dev/null
+++ b/package.cfg
@@ -0,0 +1,2 @@
+[koji]
+targets = epel8 epel8-playground
\ No newline at end of file



https://src.fedoraproject.org/rpms/perl-Test2-Plugin-NoWarnings/c/0f18f4043d0bfe9838c4e8bc26a35d6c7ec3f053?branch=epel8
___
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

pghmcfc pushed to perl-Test2-Plugin-NoWarnings (epel8). "Update to 0.03 (..more)"

[notifications]

Notification time stamped 2019-10-11 18:09:59 UTC

From 6ceee59fb92b2634b5e9a072f86956ca43f61c3b Mon Sep 17 00:00:00 2001
From: Paul Howarth 
Date: Oct 18 2016 12:48:06 +
Subject: Update to 0.03


- New upstream release 0.03
  - Add the $SIG{__WARN__} hook in an INIT block; we really don't want to
trigger this because of a compile-time warning, and because of a bug in
Test::Builder, this can actually cause the warning to be lost entirely
(https://github.com/Test-More/test-more/issues/729)
  - The Test2::Event::Warning event now returns true for increments_count,
which means that the test failure caused by a warning will not be output
as a TAP test line; previously this was just seen as a diag line, which
could be quite confusing
(https://github.com/Test-More/test-more/issues/728)

---

diff --git a/perl-Test2-Plugin-NoWarnings.spec 
b/perl-Test2-Plugin-NoWarnings.spec
index bbdb88a..2ebefcb 100644
--- a/perl-Test2-Plugin-NoWarnings.spec
+++ b/perl-Test2-Plugin-NoWarnings.spec
@@ -1,6 +1,6 @@
 Name:  perl-Test2-Plugin-NoWarnings
-Version:   0.02
-Release:   3%{?dist}
+Version:   0.03
+Release:   1%{?dist}
 Summary:   Fail if tests warn
 License:   Artistic 2.0
 URL:   http://search.cpan.org/dist/Test2-Plugin-NoWarnings/
@@ -22,7 +22,9 @@ BuildRequires:perl(Test2::Util::HashBase)
 BuildRequires: perl(warnings)
 # Test Suite
 BuildRequires: perl(File::Spec)
+BuildRequires: perl(IPC::Run3)
 BuildRequires: perl(Test2::Bundle::Extended)
+BuildRequires: perl(Test2::Require::Module)
 BuildRequires: perl(Test::More) >= 0.96
 # Optional Tests
 BuildRequires: perl(CPAN::Meta) >= 2.120900
@@ -47,7 +49,7 @@ make %{?_smp_mflags}
 
 %install
 make install DESTDIR=%{buildroot}
-%{_fixperms} %{buildroot}
+%{_fixperms} -c %{buildroot}
 
 %check
 make test
@@ -60,6 +62,18 @@ make test
 %{_mandir}/man3/Test2::Plugin::NoWarnings.3*
 
 %changelog
+* Tue Oct 18 2016 Paul Howarth  - 0.03-1
+- Update to 0.03
+  - Add the $SIG{__WARN__} hook in an INIT block; we really don't want to
+trigger this because of a compile-time warning, and because of a bug in
+Test::Builder, this can actually cause the warning to be lost entirely
+(https://github.com/Test-More/test-more/issues/729)
+  - The Test2::Event::Warning event now returns true for increments_count,
+which means that the test failure caused by a warning will not be output
+as a TAP test line; previously this was just seen as a diag line, which
+could be quite confusing
+(https://github.com/Test-More/test-more/issues/728)
+
 * Mon Sep 19 2016 Paul Howarth  - 0.02-3
 - Drop unused BR: findutils (#1377228)
 
diff --git a/sources b/sources
index 0f84cad..d536ba9 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-61d01547afd86bf8e6ba6140ed340cd8  Test2-Plugin-NoWarnings-0.02.tar.gz
+e3f286c4cb9806a6eb083de902a1998b  Test2-Plugin-NoWarnings-0.03.tar.gz



https://src.fedoraproject.org/rpms/perl-Test2-Plugin-NoWarnings/c/6ceee59fb92b2634b5e9a072f86956ca43f61c3b?branch=epel8
___
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 1760112] [RFE] EPEL8 branch of perl-Test-Number-Delta

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED



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

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

pghmcfc pushed to perl-Test2-Plugin-NoWarnings (epel8). "Update to 0.08 (..more)"

[notifications]

Notification time stamped 2019-10-11 18:09:59 UTC

From 092205a65c9da7cbddadcec8393eadab2154dfb3 Mon Sep 17 00:00:00 2001
From: Paul Howarth 
Date: Oct 11 2019 18:09:09 +
Subject: Update to 0.08


- New upstream release 0.08
  - Use IPC::Run3 instead of Capture::Tiny for all tests, which fixes an issue
with the 'tap-bug-in-test2.t' on Windows (CPAN RT#129294)

---

diff --git a/perl-Test2-Plugin-NoWarnings.spec 
b/perl-Test2-Plugin-NoWarnings.spec
index 357e2ed..3ed0860 100644
--- a/perl-Test2-Plugin-NoWarnings.spec
+++ b/perl-Test2-Plugin-NoWarnings.spec
@@ -1,6 +1,6 @@
 Name:  perl-Test2-Plugin-NoWarnings
-Version:   0.07
-Release:   3%{?dist}
+Version:   0.08
+Release:   1%{?dist}
 Summary:   Fail if tests warn
 License:   Artistic 2.0
 URL:   https://metacpan.org/release/Test2-Plugin-NoWarnings
@@ -22,7 +22,6 @@ BuildRequires:perl(Test2::Event)
 BuildRequires: perl(Test2::Util::HashBase)
 BuildRequires: perl(warnings)
 # Test Suite
-BuildRequires: perl(Capture::Tiny)
 BuildRequires: perl(File::Spec)
 BuildRequires: perl(IPC::Run3)
 BuildRequires: perl(Test2::Require::Module)
@@ -64,6 +63,11 @@ make test
 %{_mandir}/man3/Test2::Plugin::NoWarnings.3*
 
 %changelog
+* Fri Oct 11 2019 Paul Howarth  - 0.08-1
+- Update to 0.08
+  - Use IPC::Run3 instead of Capture::Tiny for all tests, which fixes an issue
+with the 'tap-bug-in-test2.t' on Windows (CPAN RT#129294)
+
 * Fri Jul 26 2019 Fedora Release Engineering  - 
0.07-3
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_31_Mass_Rebuild
 
diff --git a/sources b/sources
index b791cb9..b0697fe 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-SHA512 (Test2-Plugin-NoWarnings-0.07.tar.gz) = 
fe9f9c9ca7372177655979a222688753b8c3b0affdcf19866ebe758b19e0c6082128687051588869a0fd41170d244ee0876d64306604a9a19bcd92d1ef3db748
+SHA512 (Test2-Plugin-NoWarnings-0.08.tar.gz) = 
cf641f77b8466bbaf9d9fc166526853f64c9c66e4b1c415af521e81df76760aa3bde0634827d19c9e760c2b763c86e3923af0df83a4e2ddb4c28b8ebbc64eb63



https://src.fedoraproject.org/rpms/perl-Test2-Plugin-NoWarnings/c/092205a65c9da7cbddadcec8393eadab2154dfb3?branch=epel8
___
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

pghmcfc pushed to perl-Test2-Plugin-NoWarnings (epel8). "- Rebuilt for https://fedoraproject.org/wiki/Fedora_29_Mass_Rebuild (..more)"

[notifications]

Notification time stamped 2019-10-11 18:09:59 UTC

From b7ab4b4f06337cfc4f61e0a8b21b47ca3d19c320 Mon Sep 17 00:00:00 2001
From: Fedora Release Engineering 
Date: Oct 11 2019 18:09:09 +
Subject: - Rebuilt for https://fedoraproject.org/wiki/Fedora_29_Mass_Rebuild


Signed-off-by: Fedora Release Engineering 

---

diff --git a/perl-Test2-Plugin-NoWarnings.spec 
b/perl-Test2-Plugin-NoWarnings.spec
index bb11c87..70e8d4f 100644
--- a/perl-Test2-Plugin-NoWarnings.spec
+++ b/perl-Test2-Plugin-NoWarnings.spec
@@ -1,6 +1,6 @@
 Name:  perl-Test2-Plugin-NoWarnings
 Version:   0.06
-Release:   4%{?dist}
+Release:   5%{?dist}
 Summary:   Fail if tests warn
 License:   Artistic 2.0
 URL:   https://metacpan.org/release/Test2-Plugin-NoWarnings
@@ -62,6 +62,9 @@ make test
 %{_mandir}/man3/Test2::Plugin::NoWarnings.3*
 
 %changelog
+* Fri Jul 13 2018 Fedora Release Engineering  - 
0.06-5
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_29_Mass_Rebuild
+
 * Thu Jun 28 2018 Jitka Plesnikova  - 0.06-4
 - Perl 5.28 rebuild
 



https://src.fedoraproject.org/rpms/perl-Test2-Plugin-NoWarnings/c/b7ab4b4f06337cfc4f61e0a8b21b47ca3d19c320?branch=epel8
___
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

pghmcfc pushed to perl-Test2-Plugin-NoWarnings (epel8). "- Rebuilt for https://fedoraproject.org/wiki/Fedora_30_Mass_Rebuild (..more)"

[notifications]

Notification time stamped 2019-10-11 18:09:59 UTC

From f1ee14fafbd072a2b514d223ce90524fa853656d Mon Sep 17 00:00:00 2001
From: Fedora Release Engineering 
Date: Oct 11 2019 18:09:09 +
Subject: - Rebuilt for https://fedoraproject.org/wiki/Fedora_30_Mass_Rebuild


Signed-off-by: Fedora Release Engineering 

---

diff --git a/perl-Test2-Plugin-NoWarnings.spec 
b/perl-Test2-Plugin-NoWarnings.spec
index 70e8d4f..1321514 100644
--- a/perl-Test2-Plugin-NoWarnings.spec
+++ b/perl-Test2-Plugin-NoWarnings.spec
@@ -1,6 +1,6 @@
 Name:  perl-Test2-Plugin-NoWarnings
 Version:   0.06
-Release:   5%{?dist}
+Release:   6%{?dist}
 Summary:   Fail if tests warn
 License:   Artistic 2.0
 URL:   https://metacpan.org/release/Test2-Plugin-NoWarnings
@@ -62,6 +62,9 @@ make test
 %{_mandir}/man3/Test2::Plugin::NoWarnings.3*
 
 %changelog
+* Sat Feb 02 2019 Fedora Release Engineering  - 
0.06-6
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_30_Mass_Rebuild
+
 * Fri Jul 13 2018 Fedora Release Engineering  - 
0.06-5
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_29_Mass_Rebuild
 



https://src.fedoraproject.org/rpms/perl-Test2-Plugin-NoWarnings/c/f1ee14fafbd072a2b514d223ce90524fa853656d?branch=epel8
___
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

pghmcfc pushed to perl-Test2-Plugin-NoWarnings (epel8). "Update to 0.07 (..more)"

[notifications]

Notification time stamped 2019-10-11 18:09:59 UTC

From 78c378b33714bba4883041b193ffbc4582765358 Mon Sep 17 00:00:00 2001
From: Paul Howarth 
Date: Oct 11 2019 18:09:09 +
Subject: Update to 0.07


- New upstream release 0.07
  - Reverted back to using the Warning event type, since the bug in the Test2
core that caused this to be a problem has since been fixed
  - Replaced use of Test2::Bundle::Extended with Test2::V0
- Package new document CODE_OF_CONDUCT.md
- Modernize spec using %{make_build} and %{make_install}

---

diff --git a/perl-Test2-Plugin-NoWarnings.rpmlintrc 
b/perl-Test2-Plugin-NoWarnings.rpmlintrc
new file mode 100644
index 000..15c4609
--- /dev/null
+++ b/perl-Test2-Plugin-NoWarnings.rpmlintrc
@@ -0,0 +1,3 @@
+from Config import *
+
+addFilter("spelling-error %description -l en_US diag -> ")
diff --git a/perl-Test2-Plugin-NoWarnings.spec 
b/perl-Test2-Plugin-NoWarnings.spec
index 1321514..a44860f 100644
--- a/perl-Test2-Plugin-NoWarnings.spec
+++ b/perl-Test2-Plugin-NoWarnings.spec
@@ -1,6 +1,6 @@
 Name:  perl-Test2-Plugin-NoWarnings
-Version:   0.06
-Release:   6%{?dist}
+Version:   0.07
+Release:   1%{?dist}
 Summary:   Fail if tests warn
 License:   Artistic 2.0
 URL:   https://metacpan.org/release/Test2-Plugin-NoWarnings
@@ -9,22 +9,24 @@ BuildArch:noarch
 # Build
 BuildRequires: coreutils
 BuildRequires: make
-BuildRequires: perl-interpreter
 BuildRequires: perl-generators
+BuildRequires: perl-interpreter
 BuildRequires: perl(ExtUtils::MakeMaker) > 6.75
 # Module Runtime
 BuildRequires: perl(Carp)
 BuildRequires: perl(parent)
 BuildRequires: perl(strict)
+BuildRequires: perl(Test2) >= 1.302096
 BuildRequires: perl(Test2::API)
 BuildRequires: perl(Test2::Event)
 BuildRequires: perl(Test2::Util::HashBase)
 BuildRequires: perl(warnings)
 # Test Suite
+BuildRequires: perl(Capture::Tiny)
 BuildRequires: perl(File::Spec)
 BuildRequires: perl(IPC::Run3)
-BuildRequires: perl(Test2::Bundle::Extended)
 BuildRequires: perl(Test2::Require::Module)
+BuildRequires: perl(Test2::V0)
 BuildRequires: perl(Test::More) >= 0.96
 # Optional Tests
 BuildRequires: perl(CPAN::Meta) >= 2.120900
@@ -45,10 +47,10 @@ this module will stop working.
 
 %build
 perl Makefile.PL INSTALLDIRS=vendor NO_PERLLOCAL=1 NO_PACKLIST=1
-make %{?_smp_mflags}
+%{make_build}
 
 %install
-make install DESTDIR=%{buildroot}
+%{make_install}
 %{_fixperms} -c %{buildroot}
 
 %check
@@ -56,12 +58,20 @@ make test
 
 %files
 %license LICENSE
-%doc Changes README.md
+%doc Changes CODE_OF_CONDUCT.md README.md
 %{perl_vendorlib}/Test2/
 %{_mandir}/man3/Test2::Event::Warning.3*
 %{_mandir}/man3/Test2::Plugin::NoWarnings.3*
 
 %changelog
+* Mon Apr 22 2019 Paul Howarth  - 0.07-1
+- Update to 0.07
+  - Reverted back to using the Warning event type, since the bug in the Test2
+core that caused this to be a problem has since been fixed
+  - Replaced use of Test2::Bundle::Extended with Test2::V0
+- Package new document CODE_OF_CONDUCT.md
+- Modernize spec using %%{make_build} and %%{make_install}
+
 * Sat Feb 02 2019 Fedora Release Engineering  - 
0.06-6
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_30_Mass_Rebuild
 
diff --git a/sources b/sources
index 863c17f..b791cb9 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-SHA512 (Test2-Plugin-NoWarnings-0.06.tar.gz) = 
aed9a3769085028adffd0aa7cbbe2d7d8b89b5f4768e47ae4155dcc1f4aa8fd47319ae7c87ddbc1ed08ca99e1d703eebb74977e88696ea4dcc1104a53332ade2
+SHA512 (Test2-Plugin-NoWarnings-0.07.tar.gz) = 
fe9f9c9ca7372177655979a222688753b8c3b0affdcf19866ebe758b19e0c6082128687051588869a0fd41170d244ee0876d64306604a9a19bcd92d1ef3db748



https://src.fedoraproject.org/rpms/perl-Test2-Plugin-NoWarnings/c/78c378b33714bba4883041b193ffbc4582765358?branch=epel8
___
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

pghmcfc pushed to perl-Test2-Plugin-NoWarnings (epel8). "Perl 5.28 rebuild"

[notifications]

Notification time stamped 2019-10-11 18:09:59 UTC

From 7d4c0fd90330a704bad74446cbe8a6b5852312c0 Mon Sep 17 00:00:00 2001
From: Jitka Plesnikova 
Date: Oct 11 2019 18:09:09 +
Subject: Perl 5.28 rebuild


---

diff --git a/perl-Test2-Plugin-NoWarnings.spec 
b/perl-Test2-Plugin-NoWarnings.spec
index 024e6cc..bb11c87 100644
--- a/perl-Test2-Plugin-NoWarnings.spec
+++ b/perl-Test2-Plugin-NoWarnings.spec
@@ -1,6 +1,6 @@
 Name:  perl-Test2-Plugin-NoWarnings
 Version:   0.06
-Release:   3%{?dist}
+Release:   4%{?dist}
 Summary:   Fail if tests warn
 License:   Artistic 2.0
 URL:   https://metacpan.org/release/Test2-Plugin-NoWarnings
@@ -62,6 +62,9 @@ make test
 %{_mandir}/man3/Test2::Plugin::NoWarnings.3*
 
 %changelog
+* Thu Jun 28 2018 Jitka Plesnikova  - 0.06-4
+- Perl 5.28 rebuild
+
 * Fri Feb 09 2018 Fedora Release Engineering  - 
0.06-3
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild
 



https://src.fedoraproject.org/rpms/perl-Test2-Plugin-NoWarnings/c/7d4c0fd90330a704bad74446cbe8a6b5852312c0?branch=epel8
___
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

pghmcfc pushed to perl-Test2-Plugin-NoWarnings (master). "Update to 0.08 (..more)"

[notifications]

Notification time stamped 2019-10-11 17:58:43 UTC

From f7660e89060a174b00d0ab30e9be566794a228e5 Mon Sep 17 00:00:00 2001
From: Paul Howarth 
Date: Oct 11 2019 17:57:35 +
Subject: Update to 0.08


- New upstream release 0.08
  - Use IPC::Run3 instead of Capture::Tiny for all tests, which fixes an issue
with the 'tap-bug-in-test2.t' on Windows (CPAN RT#129294)

---

diff --git a/perl-Test2-Plugin-NoWarnings.spec 
b/perl-Test2-Plugin-NoWarnings.spec
index 357e2ed..3ed0860 100644
--- a/perl-Test2-Plugin-NoWarnings.spec
+++ b/perl-Test2-Plugin-NoWarnings.spec
@@ -1,6 +1,6 @@
 Name:  perl-Test2-Plugin-NoWarnings
-Version:   0.07
-Release:   3%{?dist}
+Version:   0.08
+Release:   1%{?dist}
 Summary:   Fail if tests warn
 License:   Artistic 2.0
 URL:   https://metacpan.org/release/Test2-Plugin-NoWarnings
@@ -22,7 +22,6 @@ BuildRequires:perl(Test2::Event)
 BuildRequires: perl(Test2::Util::HashBase)
 BuildRequires: perl(warnings)
 # Test Suite
-BuildRequires: perl(Capture::Tiny)
 BuildRequires: perl(File::Spec)
 BuildRequires: perl(IPC::Run3)
 BuildRequires: perl(Test2::Require::Module)
@@ -64,6 +63,11 @@ make test
 %{_mandir}/man3/Test2::Plugin::NoWarnings.3*
 
 %changelog
+* Fri Oct 11 2019 Paul Howarth  - 0.08-1
+- Update to 0.08
+  - Use IPC::Run3 instead of Capture::Tiny for all tests, which fixes an issue
+with the 'tap-bug-in-test2.t' on Windows (CPAN RT#129294)
+
 * Fri Jul 26 2019 Fedora Release Engineering  - 
0.07-3
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_31_Mass_Rebuild
 
diff --git a/sources b/sources
index b791cb9..b0697fe 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-SHA512 (Test2-Plugin-NoWarnings-0.07.tar.gz) = 
fe9f9c9ca7372177655979a222688753b8c3b0affdcf19866ebe758b19e0c6082128687051588869a0fd41170d244ee0876d64306604a9a19bcd92d1ef3db748
+SHA512 (Test2-Plugin-NoWarnings-0.08.tar.gz) = 
cf641f77b8466bbaf9d9fc166526853f64c9c66e4b1c415af521e81df76760aa3bde0634827d19c9e760c2b763c86e3923af0df83a4e2ddb4c28b8ebbc64eb63



https://src.fedoraproject.org/rpms/perl-Test2-Plugin-NoWarnings/c/f7660e89060a174b00d0ab30e9be566794a228e5?branch=master
___
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 1760112] [RFE] EPEL8 branch of perl-Test-Number-Delta

[bugzilla]

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

Paul Howarth  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||p...@city-fan.org
   Assignee|tcall...@redhat.com |p...@city-fan.org



--- Comment #1 from Paul Howarth  ---
https://pagure.io/releng/fedora-scm-requests/issue/18170
https://pagure.io/releng/fedora-scm-requests/issue/18171

-- 
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 1758719] Plans for EPEL8

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #2 from Fedora Update System  ---
perl-Class-Std-0.013-12.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-0f2db9e23b

-- 
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 1760111] [RFE] EPEL8 branch of perl-Params-Coerce

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #3 from Fedora Update System  ---
perl-Params-Coerce-0.14-30.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-51257bec98

-- 
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 1760112] [RFE] EPEL8 branch of perl-Test-Number-Delta

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #3 from Fedora Update System  ---
perl-Test-Number-Delta-1.06-15.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-534d7d74d0

-- 
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 1756029] [RFE] perl-LWP-UserAgent-Determined build for epel8

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #3 from Fedora Update System  ---
perl-LWP-UserAgent-Determined-1.07-7.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-0540deaeb2

-- 
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 1756027] [RFE] perl-PerlIO-gzip build for epel8

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version||perl-PerlIO-gzip-0.20-10.el
   ||8
 Resolution|--- |ERRATA
Last Closed||2019-10-12 01:50:16



--- Comment #4 from Fedora Update System  ---
perl-PerlIO-gzip-0.20-10.el8 has been pushed to the Fedora EPEL 8 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 1752411] perl-Date-Holidays-DE-2.03 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Date-Holidays-DE-2.03- |perl-Date-Holidays-DE-2.03-
   |1.fc32  |1.fc32
   |perl-Date-Holidays-DE-2.03- |perl-Date-Holidays-DE-2.03-
   |1.fc30  |1.fc30
   ||perl-Date-Holidays-DE-2.03-
   ||1.fc29



--- Comment #16 from Fedora Update System  ---
perl-Date-Holidays-DE-2.03-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

[389-devel] 389 DS nightly 2019-10-12 - 95% PASS

[vashirov]

https://fedorapeople.org/groups/389ds/ci/nightly/2019/10/12/report-389-ds-base-1.4.2.2-20191011gitc95f6cf.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

[Bug 1755810] [RFE] EPEL8 branch of perl-DateTime-Format-SQLite

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version||perl-DateTime-Format-SQLite
   ||-0.11-28.el8
 Resolution|--- |ERRATA
Last Closed||2019-10-12 01:50:13



--- Comment #6 from Fedora Update System  ---
perl-DateTime-Format-SQLite-0.11-28.el8 has been pushed to the Fedora EPEL 8
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