Re: Non-responsive maintainer: joost

[Mattia Verga]

Il 03/02/2018 14:12, Richard Shaw ha scritto:
Well I could not find any activity for 2018 so we're well past 3 weeks 
at this point. I have filed a ticket here:


https://pagure.io/fesco/issue/1838

But I don't want to maintain the packages, I can barely keep up with 
the ones I already have on here and RPM Fusion.



It seems that fpc has been upgraded to 3.0.4 by Joost on Friday and he 
addressed some of the bugs opened. Still, he doesn't made any 
communication attempts here or on bugzilla...
Moreover, now we have Lazarus broken on Rawhide because it needs to be 
rebuilt after the fpc upgrade. (and possibly upgraded to 1.8.0).


It would be nice if someone else can, at least, co-maintain these two 
packages (I don't think to be able to).


Mattia
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Clean up your spec files

[Neal Gompa]

On Fri, Feb 9, 2018 at 4:08 AM, Panu Matilainen  wrote:
> On 02/08/2018 04:53 PM, Neal Gompa wrote:
>>
>> On Thu, Feb 8, 2018 at 9:49 AM, Brett Lentz  wrote:
>>>
>>> On 08/02/18 14:09 +0100, Miroslav Suchý wrote:



 * rm -rf $RPM_BUILD_ROOT

>>>
>>> rpmdev-newspec still inserts this. It may be worthwhile to file a bug to
>>> get
>>> it to stop.
>>>
>>
>> The only reason I haven't dropped it yet is because SLE 11 still is
>> supported, and it requires it.
>
>
> Does it, really? IIRC Suse started doing this long long before we did - we
> basically copied it from them:
>
> %__spec_install_pre %{___build_pre}\
> [ "$RPM_BUILD_ROOT" != "/" ] && rm -rf "${RPM_BUILD_ROOT}"\
> mkdir -p `dirname "$RPM_BUILD_ROOT"`\
> mkdir "$RPM_BUILD_ROOT"\
> %{nil}
>
>
>>
>> I could see into adding some magic into removing it when newer rpm is
>> detected, but I'm not sure it's worth it for a single line.
>
>
> That single line is not just entirely harmless junk, it inserts an
> insecurity into the picture which the above _install_pre snippet fixes, and
> adding sections that might not even be needed can have other unwanted
> side-effects, witness https://bugzilla.redhat.com/show_bug.cgi?id=1542743
> where a package actually fails to build because there's a bogus/redundant
> %install section containing that one line.
>
> So please, remove it. If SLE 11 really requires it then handle it that old
> dog specially. It is worth it.
>

Alright, I'll double check and remove it accordingly.

-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: OpenImageIO GCC 8 build problem?

[Richard Shaw]

On Sat, Feb 10, 2018 at 12:38 PM, Jakub Jelinek  wrote:

>
> I'll do another GCC build tonight, might take a day or so to make it into
> the buildroots if all goes well.


I'm still waiting on the armv7hl build but the rest have completed so
thanks!

Richard
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: RANT: Packaging is changing too fast and is not well documented

[Ralf Corsepius]

On 02/11/2018 08:40 AM, Kevin Kofler wrote:

Richard Shaw wrote:

$ fedpkg request-branch 
Could not execute request_branch: The "token" value must be set under the
"fedpkg.pagure" section in your "fedpkg" user configuration


WTF?! So, instead of going to a web interface and making the change (old,
now discontinued, pkgdb), we now have to:
1. go to the web interface
2. read the token there
3. locate a config file
4. edit the config file with a text editor
5. manually insert the token from step 2 there
6. use a CLI to make the change
and that is an improvement, HOW?


Been there, struggled with this and feeling really p***ed by it ;)

This pagureio stuff is a massive usability and a functional regression.

Ralf
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Proposed Fedora packaging guideline: More Go packaging

[nicolas . mailhot]

De: "Jan Chaloupka" 

Hi Jan

Apologies for the delayed answer, I was beating the PR into shape to address 
review comments.

> Let's keep moving forward, 
> improving the infrastructure for other folks and pushing new ideas and 
> improvements into practical solutions.

Let's move forward, I'm sick on sitting on a private spec stash and I see 
people trying to package stuff already in my list with the old guidelines.


On 12/17/2017 08:11 AM, nicolas.mailhot wrote:

>> It builds on the hard work of the Go SIG and reuses the rpm automation 
>> ofhttps://fedoraproject.org/wiki/PackagingDrafts/Go  when it exists, and 
>> produces compatible packages.

> Can you describe what you mean by "compatible packages"?

That mostly means the resulting packages can use "old-style" packages and 
"old-style" packages can use "new-style" packages. The effective result is 
similar enough there is no need for a rupture. Now, as I wrote before 
"old-style" packages will often be too old or not rigorous enough to be useful 
to "new-style" packages.

> I mentioned a list of things that you did not answer fully. Most important to 
> me:
> - your macros do not generate build-time dependencies, which I see as 
> one of the drawbacks.

Generating BuildRequires dynamically needs changes in rpm tooling (mostly mock, 
I think). So it can not be done today if I'm not wrong. If you have a tool that 
outputs BuildRequires outside rpm, you can still use it. That's not an absolute 
showstopper as the go compiler is pretty explicit on what's missing, so 
BuildRequires are easily added during the first %build or %check run (though 
that's tedious and annoying).

> Do you plan to ignore them?

Generating BuildRequires would be quite easy if rpm tooling provided an entry 
point at the end of %prep. So, that's a mid-term objective and requires sending 
an RFE mock-side first.

Requires generation is automatic and complete, so a Go -devel package will pull 
in all it needs without manual intervention (except for version constrains, 
that needs some maturing go dep side first)

> - support for more subpackages. You describe how to specify which files 
> go to which packages 
> (https://fedoraproject.org/wiki/More_Go_packaging#Separate_code_packages) 
> but you don't say how list of provided packages and a list of 
> dependencies are generated for the subpackages.

It is fully automated and transparent, rpm does not care why you split your Go 
code, it will compute provides and requires for every directory installed and 
owned under %{gopath}/src/%{goipath}, and attribute the result to the 
(sub)package owning the the directory. So just choosing what to install in each 
%goinstall invocation is sufficient to compute the corresponding 
requires/provides and attach them to the correct subpackage. If you don't want 
your package to pull a particular dep, just don't install the code that calls 
it.

> - reproducible evaluation of macros. Either for running automatic 
> analysis over spec files or for debugging purposes. I would like the 
> macros to be built in top of binaries I can run separately.

That would be quite difficult to do as most macros depend on rpm variables and 
other context defined during the build run, and can themselves alter rpm state 
dynamically via variable setting and other calls. rpm is not a dumb archive 
format it includes all kinds of package building facilities that the macros 
take advantage of, it ships with an embedded lua engine, and so on.

For "simple" macros that only read a specific variable set, and only perform 
"simple" actions (or set a specific set of variables) you could certainly 
rewrite them as separate scripts or binaries (for example the naming code is 
pretty trivial to rewrite in any language, and takes only one input and one 
output). But the more extensive the integration with rpm is, the more rpm glue 
you'd need to interface the result, and in some cases the glue is likely to be 
a significant part of the existing code. Also, you'd lose quite a lot of 
flexibility, and complexify your build root requirements.

I'm not saying it can not be done, or it is not worthwhile to do, but it's a 
lot of analysis and rewriting work and I'm not sure it's worth it (I'm 
certainly not interested to do it myself).

Note that autodeps are already effectively separate scripts, you just need to 
pass them a few arguments and pipe them Go code directory names to see them 
working. It may feel weird but that's how the autodep rpm API is defined. Other 
ecosystems packaged as rpms sometimes use separate binaries there, sometimes 
with light shell gluing. You have my blessing to rewrite them in Go if you want 
to.


>> - automated package naming derived from the native identifier (import path). 
>> No more packages names without any relation with current upstream naming.

> Can you provide a list of package names that diverge from this convention?

For example, all the golang/x/foo stuff, which is a pity as it is 

Re: Proposed Fedora packaging guideline: More Go packaging

[nicolas . mailhot]

De: "nicolas mailhot" 
À: "Jan Chaloupka" 
>> I mentioned a list of things that you did not answer fully. Most important 
>> to me:
>> - your macros do not generate build-time dependencies, which I see as 
>> one of the drawbacks.

> Generating BuildRequires dynamically needs changes in rpm tooling (mostly 
> mock, I think). So it can not be done today if I'm not wrong. If you have a 
> tool that outputs BuildRequires outside rpm, you can still use it. That's not 
> an
> absolute showstopper as the go compiler is pretty explicit on what's missing, 
> so BuildRequires are easily added during the first %build or %check run 
> (though that's tedious and annoying).

>> Do you plan to ignore them?

>Generating BuildRequires would be quite easy if rpm tooling provided an entry 
>point at the end of %prep. So, that's a mid-term objective and requires 
>sending an RFE mock-side first.

And that part is done:

https://github.com/rpm-software-management/mock/issues/160

Feel free to complete/correct/support the request so it has a change to be 
taken into account and we can start working on integrated Go BuildRequires

Regards

-- 
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

HEADS UP: yaml-cpp 0.6.0 coming to rawhide

[Richard Shaw]

I may wait a few days for all the build problems with gcc 8 and there are
still several packages that haven't been properly rebuilt against boost
1.66, but I plan to build yaml-cpp 0.6.0 and rebuild its dependencies in
the near future:

$ repoquery --repoid=rawhide --source --whatrequires
"libyaml-cpp.so.0.5()(64bit)"
Last metadata expiration check: 0:01:30 ago on Sun 11 Feb 2018 01:21:13 PM
CST.
OpenColorIO-1.1.0-1.fc28.src.rpm
calamares-3.1.8-6.fc28.src.rpm
facter-3.9.3-1.fc28.src.rpm
fawkes-1.0.1-13.fc28.src.rpm
librime-1.2-19.fc28.src.rpm
mongodb-3.6.2-1.fc28.src.rpm
pdns-4.1.0-2.fc28.src.rpm

Thanks,
Richard
FAS: hobbes1069
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: KDE print dialog does not see CUPS settings

[Kevin Kofler]

Kevin Kofler wrote:
> Thankfully, as Rex Dieter points out, this is finally being addressed in
> Qt 5.11 (see https://wiki.qt.io/New_Features_in_Qt_5.11 and
> https://bugreports.qt.io/browse/QTBUG-54464). Unfortunately, that release
> is still a few months away from now. (Qt upstream currently expects to
> release Qt 5.11.0 on May 31.) I would actually argue that we should
> backport this to our packages sooner, backports from OpenSUSE are linked
> in QTBUG-54464. But I am not a maintainer of qt5-qtbase, so it is not my
> decision to make.

I have built qt5-qtbase with these backported patches in a Copr:
https://copr.fedorainfracloud.org/coprs/kkofler/qt5-qtbase-print-dialog-advanced/

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Clean up your spec files

[Miroslav Suchý]

Dne 8.2.2018 v 16:03 Kamil Dudka napsal(a):
> There might be valid reasons for the old stuff appearing in _some_ spec files
> beyond your knowledge, for example specfile maintained by upstream, usable not
> only by Fedora.

AFAIK all mentioned parts are not needed in Fedora and all supported RHELs. I 
would be really surprised if any
distribution requires it.

> they are pretty much harmless.

Technically it is harmless.

But a lot of newbies and 3rd party developers take Fedora packages as example 
for *their* packages. And they copy those
bits over and over...

Miroslav
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: KDE print dialog does not see CUPS settings

[Garry T. Williams]

On Sunday, February 11, 2018 7:39:33 PM EST Kevin Kofler wrote:
> I have built qt5-qtbase with these backported patches in a Copr:
> https://copr.fedorainfracloud.org/coprs/kkofler/qt5-qtbase-print-dialog-advanced/

Thank you, Kevin.

That was an annoying bug so *big* thanks -- it works just fine.

-- 
Garry T. Williams


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1544216] New: perl-Encode-2.96 is available

[bugzilla]

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

Bug ID: 1544216
   Summary: perl-Encode-2.96 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Encode
  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



Latest upstream release: 2.96
Current version/release in rawhide: 2.95-1.fc28
URL: http://search.cpan.org/dist/Encode/

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

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

[Bug 1542721] Please provide a package for EPEL7

[bugzilla]

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



--- Comment #6 from Ralf Corsepius  ---
(In reply to Emmanuel Seyman from comment #5)
> (In reply to Ralf Corsepius from comment #3)
> >
> > I don't know you and have never heard about you before.
> 
> If it makes you feel better, I'll be happy to co-maintain the EPEL branch
> with Robert-André. 

That's not my point. My actual point is I do not want Fedora to be furtherly
run 
down by noobs. Something which I feel is self-explanatory in case people
requesting EPEL packages: They are unmaintainable, by definition.

> > That said, feel free to take the EPEL branch, but I am not interested in
> > having you as co-maintainer for Fedora.
> 
> Per-branch ACLs no longer exist.
Read what I wrote above - Incompetent noobs everywhere in Fedora.

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

[Bug 1543181] Please provide a package for EPEL7

[bugzilla]

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



--- Comment #1 from Emmanuel Seyman  ---
I've requested an epel7 branch for this package.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1525990] [RFE] please provide in EPEL

[bugzilla]

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



--- Comment #2 from Emmanuel Seyman  ---
I've requested an epel7 branch for this package.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1542731] Please provide a package for EPEL7

[bugzilla]

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



--- Comment #1 from Emmanuel Seyman  ---
I've requested an epel7 branch for this package.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1542721] Please provide a package for EPEL7

[bugzilla]

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

Emmanuel Seyman  changed:

   What|Removed |Added

 CC||emman...@seyman.fr



--- Comment #5 from Emmanuel Seyman  ---
(In reply to Ralf Corsepius from comment #3)
>
> I don't know you and have never heard about you before.

If it makes you feel better, I'll be happy to co-maintain the EPEL branch with
Robert-André. 

> That said, feel free to take the EPEL branch, but I am not interested in
> having you as co-maintainer for Fedora.

Per-branch ACLs no longer exist.
https://fedoraproject.org/wiki/Infrastructure/WhatHappenedToPkgdb#How_do_I_give_a_user_commit_access_to_a_dist-git_repo.3F

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

[Bug 1544283] New: perl-Mojolicious-7.65 is available

[bugzilla]

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

Bug ID: 1544283
   Summary: perl-Mojolicious-7.65 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Mojolicious
  Keywords: FutureFeature, Triaged
  Assignee: emman...@seyman.fr
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: emman...@seyman.fr,
perl-devel@lists.fedoraproject.org,
robinlee.s...@gmail.com, yan...@declera.com



Latest upstream release: 7.65
Current version/release in rawhide: 7.64-1.fc28
URL: http://mojolicio.us/

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

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

[Bug 1544287] New: perl-System-Info-0.057 is available

[bugzilla]

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

Bug ID: 1544287
   Summary: perl-System-Info-0.057 is available
   Product: Fedora
   Version: rawhide
 Component: perl-System-Info
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: jples...@redhat.com,
perl-devel@lists.fedoraproject.org



Latest upstream release: 0.057
Current version/release in rawhide: 0.056-1.fc28
URL: http://search.cpan.org/dist/System-Info/

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

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

[Bug 1544285] New: perl-RDF-RDFa-Generator-0.200 is available

[bugzilla]

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

Bug ID: 1544285
   Summary: perl-RDF-RDFa-Generator-0.200 is available
   Product: Fedora
   Version: rawhide
 Component: perl-RDF-RDFa-Generator
  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



Latest upstream release: 0.200
Current version/release in rawhide: 0.192-2.fc28
URL: http://search.cpan.org/dist/RDF-RDFa-Generator/

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

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

[Bug 1544276] New: perl-DBD-Pg-3.7.1 is available

[bugzilla]

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

Bug ID: 1544276
   Summary: perl-DBD-Pg-3.7.1 is available
   Product: Fedora
   Version: rawhide
 Component: perl-DBD-Pg
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: al...@redhat.com, caillon+fedoraproj...@gmail.com,
dev...@gunduz.org, john.j5l...@gmail.com,
jples...@redhat.com, ka...@ucw.cz,
mbar...@fastmail.com,
perl-devel@lists.fedoraproject.org,
prais...@redhat.com, rhug...@redhat.com,
rstr...@redhat.com, sandm...@redhat.com



Latest upstream release: 3.7.1
Current version/release in rawhide: 3.7.0-1.fc28
URL: http://search.cpan.org/dist/DBD-Pg/

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

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

[Bug 1544277] New: perl-Dist-Zilla-6.011 is available

[bugzilla]

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

Bug ID: 1544277
   Summary: perl-Dist-Zilla-6.011 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Dist-Zilla
  Keywords: FutureFeature, Triaged
  Assignee: psab...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: iarn...@gmail.com, perl-devel@lists.fedoraproject.org,
psab...@redhat.com



Latest upstream release: 6.011
Current version/release in rawhide: 6.010-2.fc27
URL: http://search.cpan.org/dist/Dist-Zilla/

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

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

[Bug 1544277] perl-Dist-Zilla-6.011 is available

[bugzilla]

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



--- Comment #1 from Fedora Update System  ---
perl-Dist-Zilla-6.011-1.fc27 has been submitted as an update to Fedora 27.
https://bodhi.fedoraproject.org/updates/FEDORA-2018-98972967f7

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

[Bug 1544277] perl-Dist-Zilla-6.011 is available

[bugzilla]

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



--- Comment #2 from Fedora Update System  ---
perl-Dist-Zilla-6.011-1.fc26 has been submitted as an update to Fedora 26.
https://bodhi.fedoraproject.org/updates/FEDORA-2018-a370736690

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