[Bug 1652477] Upgrade perl-Config-Model to 2.128

2018-11-22 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1652477

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #2 from Fedora Update System  ---
perl-Config-Model-2.128-1.fc29 has been pushed to the Fedora 29 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-2018-391b489bff

-- 
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org


[EPEL-devel] Fedora EPEL 7 updates-testing report

2018-11-22 Thread updates
The following Fedora EPEL 7 Security updates need testing:
 Age  URL
 166  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-3835d39d1a   
unrtf-0.21.9-8.el7
 116  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-f9d6ff695a   
bibutils-6.6-1.el7 ghc-hs-bibutils-6.6.0.0-1.el7 pandoc-citeproc-0.3.0.1-4.el7
 100  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-3c9292b62d   
condor-8.6.11-1.el7
  72  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-3492a96896   
myrepos-1.20180726-1.el7
  22  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-bdb21ebc3f   
drupal7-7.60-2.el7
  15  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-32e0cee0bb   
perl-Mojolicious-7.94-1.el7
  14  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-9051b49e75   
suricata-4.0.6-1.el7
   9  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-fc29932f12   
pdns-4.0.6-2.el7
   8  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-f9270bbaec   
pdns-recursor-4.1.7-1.el7
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-a09ace87bb   
php-PHPMailer-5.2.27-1.el7
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-0e73364530   
python-paramiko-2.1.1-0.9.el7
   2  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-c25e48ded1   
bird-1.6.4-2.el7
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-2206653eb9   
python-django-1.11.13-4.el7 python-django16-1.6.11.7-5.el7
   0  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-3f65916e08   
moodle-3.1.15-1.el7


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

dnsdist-1.3.3-1.el7
php-PsrLog-1.1.0-1.el7

Details about builds:



 dnsdist-1.3.3-1.el7 (FEDORA-EPEL-2018-cf66ab47c5)
 Highly DNS-, DoS- and abuse-aware loadbalancer

Update Information:

Security fix for CVE-2018-14663

ChangeLog:

* Sun Nov 18 2018 Sander Hoentjen  - 1.3.3-1
- Update to 1.3.3
- Fixes CVE-2018-14663

References:

  [ 1 ] Bug #1649053 - CVE-2018-14663 dnsdist: Record smuggling when adding ECS 
or XPF [epel-7]
https://bugzilla.redhat.com/show_bug.cgi?id=1649053




 php-PsrLog-1.1.0-1.el7 (FEDORA-EPEL-2018-499f968765)
 Common interface for logging libraries

Update Information:

**Version 1.1.0**  *Add a new TestLogger, useful for testing purposes; see
Seldaek/monolog#1229 (#57, thanks gmponos) *Test if the context array
accepts closed resources (#54, thanks RGustBardon)

ChangeLog:

* Thu Nov 22 2018 Remi Collet  - 1.1.0-1
- update to 1.1.0


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


[Bug 1648876] Upgrade perl-Pegex to 0.70

2018-11-22 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1648876

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version||perl-Pegex-0.70-1.fc29
 Resolution|--- |ERRATA
Last Closed||2018-11-22 21:29:49



--- Comment #3 from Fedora Update System  ---
perl-Pegex-0.70-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://getfedora.org/code-of-conduct.html
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 2018-11-23 - 90% PASS

2018-11-22 Thread vashirov
https://fedorapeople.org/groups/389ds/ci/nightly/2018/11/23/report-389-ds-base-1.4.0.19-20181123git9d736d6.fc29.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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org


Re: Proposal: Faster composes by eliminating deltarpms and using zchunked rpms instead

2018-11-22 Thread Jonathan Dieter
On Thu, 2018-11-22 at 11:31 -0500, Josh Boyer wrote:
> I'm concerned that this will effectively render EL RPM unable to
> handle any Fedora RPMs at all.  That's both a practical concern, as
> many people develop Fedora using EL and vice versa, and also a broader
> ecosystem concern.  I would very much like for all of our
> distributions to be able to more easily operate together, and this
> effectively forks Fedora off into it's own space yet again.

For what very little it's worth, a zchunked rpm is still a valid zchunk
file, and you would be able to easily extract the payload and the
header from a zchunked rpm on an EL system.  In fact, because we're not
planning to change the rpm header format at all, there could easily be
a tool to convert a zchunked rpm into an xz or gzipped rpm (and vice
versa).  Having said that, there's a huge difference between this and
having EL's RPM actually be able to read Fedora's RPMs.

> Have we really looked at the wider scope of what a format change like
> this would do in the context of some of the larger picture things
> we're working on with lifecycle and cross-distro collaboration
> efforts?  I agree this would be better than delta RPMs when looking at
> that *specific* usecase, but improving that (even with compose time
> benefits) by doing a format change seems to be inflicting a very high
> cost for what is an important but relatively small usecase.

This is a really good point and I don't know know the answer.  As per
Neal's suggestion earlier in the thread, I posted this to the rpm-
ecosystem mailing list.  Michael from SUSE brought up some very valid
concerns about how well zchunk would compare with deltarpm in delta
efficiency, but apart from that, it's been pretty quiet there.

If it's already obvious that the cost for this proposal isn't worth the
gain, I do completely understand.  If we're not sure, I'll do a proof-
of-concept that converts standard rpms into zchunked rpms, so we can
compare sizes and deltas, and hopefully get some data points on speed.

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


Re: Automating package maintainers responsivity check

2018-11-22 Thread Peter Oliver
On Wed, 21 Nov 2018, 17:21 Jonathan Wakely 
> This assumes there is a queue of ready and willing (and competent)
> volunteers to take on packages that get automatically orphaned. Is
> that true? I doubt it. If those people exist, why aren't they already
> offering to co-maintain packages, or responding to some of those open
> bugs?
>

A possible answer to that question could be that no-ones going to volunteer
to do work that they assume someone else already has in hand.

Also, it's hard to volunteer to co-maintain a package which has a
non-responsive maintainer, because there is no one to grant you access.
For simple packages that only require a minor version update, invoking and
following through the non-responsive maintainer process is often more
effort than the outstanding work required on the package.

>
-- 
Peter Oliver
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


>1yo BZ: Could not apply database update "DBXUpdate-2016-08-09-13-16-00.bin"...: Invalid argument

2018-11-22 Thread Richard Shaw
Just installed F29 on a HP 15-g023cl and was checking things out post
install and ran into this failed service I wasn't familiar with.

# systemctl status dbxtool
● dbxtool.service - Secure Boot DBX (blacklist) updater
   Loaded: loaded (/usr/lib/systemd/system/dbxtool.service; enabled; vendor
preset: enabled)
   Active: failed (Result: exit-code) since Thu 2018-11-22 11:21:39 CST;
22min ago
  Process: 784 ExecStart=/usr/bin/dbxtool -a /usr/share/dbxtool/ -q
(code=exited, status=1/FAILURE)
 Main PID: 784 (code=exited, status=1/FAILURE)

Nov 22 11:21:38 localhost.localdomain systemd[1]: Started Secure Boot DBX
(blacklist) updater.
Nov 22 11:21:39 localhost.localdomain dbxtool[784]: Applying 1 updates
Nov 22 11:21:39 localhost.localdomain dbxtool[784]: Applying
"DBXUpdate-2016-08-09-13-16-00.bin" 2010-3-6 19:17:21
Nov 22 11:21:39 localhost.localdomain dbxtool[784]: Could not apply
database update "DBXUpdate-2016-08-09-13-16-00.bin": Invalid argument
Nov 22 11:21:39 localhost.localdomain dbxtool[784]: Cannot Continue.:
Invalid argument
Nov 22 11:21:39 localhost.localdomain systemd[1]: dbxtool.service: Main
process exited, code=exited, status=1/FAILURE
Nov 22 11:21:39 localhost.localdomain systemd[1]: dbxtool.service: Failed
with result 'exit-code'.

I quickly found a few bugs, the oldest one is over a year old and was
initally reported on F27! There seem to be suggested fixes but no
maintainer action in some time.

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

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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Proposal: Faster composes by eliminating deltarpms and using zchunked rpms instead

2018-11-22 Thread Josh Boyer
On Wed, Nov 21, 2018 at 3:37 PM Jonathan Dieter  wrote:
>
> On Wed, 2018-11-21 at 11:31 -0500, Colin Walters wrote:
> > After having introduced a new format (OSTree) into the ecosystem here,
> > as well as working a lot on the Docker/OCI ecosystem, one thing I want
> > to emphasize is:
> >
> > A lot of Red Hat's customers don't connect their systems to the Internet,
> > they want easy offline mirroring.  OSTree supports that, and it's
> > also possible to do with OCI images of course.
> >
> > But, a lot organizations use e.g. https://jfrog.com/artifactory/
> > which today doesn't support OSTree (it does support RPM and Docker/OCI).
> > So any format break for RPM wouldn't be usable until Artifactory gains
> > support for it.  And even after that happened you'd have in some
> > places a large lag time for it to be deployed.
> >
> > In general, any data format break is going to impose a lot higher
> > costs than you might imagine.
>
> Thanks for bringing up these points.  You are undoubtedly correct that
> there's an unknown cost associated with these changes, but hopefully
> the cost will become a little clearer once we have a POC.

I'm concerned that this will effectively render EL RPM unable to
handle any Fedora RPMs at all.  That's both a practical concern, as
many people develop Fedora using EL and vice versa, and also a broader
ecosystem concern.  I would very much like for all of our
distributions to be able to more easily operate together, and this
effectively forks Fedora off into it's own space yet again.

Have we really looked at the wider scope of what a format change like
this would do in the context of some of the larger picture things
we're working on with lifecycle and cross-distro collaboration
efforts?  I agree this would be better than delta RPMs when looking at
that *specific* usecase, but improving that (even with compose time
benefits) by doing a format change seems to be inflicting a very high
cost for what is an important but relatively small usecase.

josh

> > (Also on this topic, I should note that the OSTree data format cleanly
> >  fixes a lot of the issues being discussed here; it has deltas, and also
> >  doesn't make the mistake of checksumming compressed data,
> >  when performing updates only changed files are rewritten, not to mention
> >  a whole transactional update system, etc.)
>
> Yep.  I've experimented with OSTree and love the concepts behind it.  I
> don't think we're quite ready to ditch the classic rpm systems yet,
> though.
>
> Jonathan
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> 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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: prevent accidentally creating branches in dist-git

2018-11-22 Thread Pierre-Yves Chibon
On Wed, Nov 21, 2018 at 10:31:34AM -0500, Neal Gompa wrote:
> On Tue, Nov 20, 2018 at 9:26 AM Dusty Mabe  wrote:
> >
> >
> > I've certainly made the mistake of accidentally creating branches
> > in dist-git and now being stuck with them because we can't delete
> > them. Now that src.fedoraproject.org (dist-git) is backed by a newer
> > version of pagure you can prevent creating new branches by `git push`.
> >
> > For your project in the web UI:
> >
> > - Go to the `Settings` menu
> > - Select `Hooks` from the left hand side
> > - Expand `Prevent creating new branches by git push`
> > - Click the checkbox
> > - Click `Update`
> >
> > I personally think this should be the default for all projects but
> > I don't know if there is a way to easily make that happen when a project
> > gets created.
> >
> > Hope this helps someone!
> 
> This is amazing. Please tell me there's an API call to set this for
> all my projects? Because I just want this for every package I
> maintain, excluding forks (obviously)!

There is no API call to toggle Hooks yet, definitively worth opening a RFE 
though :)


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


404 in git email notifications (Was: pagure pushed to git (master). "Updated pull-request 16f37409e293432fb406e514cd649b66: Move git instaweb to a subpackage")

2018-11-22 Thread Tomasz Kłoczko
Looks like in all email notifications like below URL points to 404.

kloczek
-- 
Tomasz Kłoczko | LinkedIn: *http://lnkd.in/FXPWxH *


On Thu, 22 Nov 2018 at 05:23,  wrote:

> Notification time stamped 2018-11-22 04:23:19 UTC
>
> pagure pushed to git (master).  "Updated pull-request
> 16f37409e293432fb406e514cd649b66: Move git instaweb to a subpackage"
>
> https://src.fedoraproject.org/rpms/git/c/1554ae206fcb088dfbf8f2ba78b7db36dcb3e07f?branch=master
> ___
> scm-commits mailing list -- scm-comm...@lists.fedoraproject.org
> To unsubscribe send an email to scm-commits-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/scm-comm...@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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Proposal: Faster composes by eliminating deltarpms and using zchunked rpms instead

2018-11-22 Thread John Reiser

On 2018-11-16, Jonathan Dieter wrote:

For reference, this is in reply to Paul [Frield]'s email about lifecycle
objectives, specifically focusing on problem statement #1[1].


Have rpm use zchunk as its compression format, removing the need for
deltarpms, and thus reducing compose time.  This will require changes
to both the rpm format and new features in the zchunk format.




[1]:
https://fedoraproject.org/wiki/Objectives/Lifecycle/Problem_statements#Challenge_.231:_Faster.2C_more_scalable_composes



Currently a compose takes a minimum of around 8.5 hours ([1] and others);
the goal is 1 hour.  The goal is particularly relevant during the last
phase of a Fedora release cycle (after code freeze) when each successive
compose contains only a few .rpms that have changed from the previous
compose, and the question-of-the-hour is whether some particular bug
actually was fixed.  In this case deltarpms can be ignored.
The goal also is relevant to a future of CI (Continuous Integration)
that has automated gating of changes depending on successful tests
of the entire compose ("Does it boot and pass the test cases?")
Again, deltarpms can be ignored.

Please display some measurements which support the belief
that using zchunk will reduce compose time dramatically,
whether by eliminating deltarpms or by other effects.

Did you view
https://www.youtube.com/watch?v=kW7oz_zbSD0
"Flock 2018 - Improving Fedora Compose process" (Aug.8, 2018; 55min)
They do present measurements [coarse].  The overwhelming
conclusion is that 8.5 hours is a data flow problem, both
large-grain (moving .rpms and other files across the network)
and small-grain (extracting the desired information from
the header of an .rpm that uses data compression.)

The number one request that I heard in the recorded session
was for faster access to fields in the header of an .rpm
that uses data compression.  This is slow today because the
header+tail are compressed together as if a single logical stream,
and the code retrieves and de-compresses the whole .rpm in order to access
just the header.  However, both xz (liblzma)  and gzip (zlib) accept
a parameter to stop decompressing after generating N bytes of output;
why not use this?  N can be known, or over-estimated, or iteratively
(and incrementally) approximated until it covers the entire header.
To make de-compression of the rpm header even easier,
call xz_compress twice: once with the header, once with the tail.
The concatenation of the compressed outputs is transparent
by default but visible if you look for it, just like zlib.

In effect the "directory" feature of zchunk can be implemented
for the special case of header-vs-tail (using either xz (liblzma)
or gzip (zlib)) without disturbing other clients of .rpms.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Something is broken in low-level components, processes segfault

2018-11-22 Thread Florian Weimer
* Florian Weimer:

> * Igor Gnatenko:
>
>> https://apps.fedoraproject.org/koschei/build/5700914
>>
>>   process didn't exit successfully: `/usr/bin/rustc --crate-name
>> glib_sys src/lib.rs --color never --crate-type lib
>> --emit=dep-info,link -C opt-level=3 -C metadata=20d7ee6da134c60a -C
>> extra-filename=-20d7ee6da134c60a --out-dir
>> /builddir/build/BUILD/glib-sys-0.6.0/target/release/deps -L
>> dependency=/builddir/build/BUILD/glib-sys-0.6.0/target/release/deps
>> --extern 
>> bitflags=/builddir/build/BUILD/glib-sys-0.6.0/target/release/deps/libbitflags-056f832aae1b729d.rlib
>> --extern 
>> libc=/builddir/build/BUILD/glib-sys-0.6.0/target/release/deps/liblibc-626066f325dbf1d3.rlib
>> -Copt-level=3 -Cdebuginfo=2 -Clink-arg=-Wl,-z,relro,-z,now -l
>> glib-2.0` (signal: 11, SIGSEGV: invalid memory reference)
>>
>> There were just libxcrypt/glibc/llvm/annobin updates, so it's hard to
>> guess what exactly is broken.
>
> This is .  I will
> revert the most likely upstream patch that causes this.
>
> Sorry for the inconvenience.

Worked around in glibc-2.28.9000-19.fc30 by reverting the broken patch.
I think I've also found and fixed the actual bug.  A patch is pending
upstream review.

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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Upgraded from F28 x96_64 XFCE Spin to F29 => rough audio - not kernel - hardware?

2018-11-22 Thread Philip Rhoades

Samuel,


On 2018-11-18 03:15, Samuel Sieb wrote:

On 11/17/18 1:33 AM, Philip Rhoades wrote:

On 2018-11-17 19:46, Samuel Sieb wrote:

On 11/17/18 12:17 AM, Philip Rhoades wrote:
My problem is not crackling_or_skipping - it is more just noisy.  
That link is a fix for a PA problem and is not specific to the 
F28->F29 upgrade which has caused the current problem.  I don't want 
to have to re-install PA now - to my way of thinking, that just adds 
a layer of complexity to the problem.


Does booting an F28 kernel fix the audio?  If so, then file a kernel 
bug.


Ah, good thinking - I will boot on the F28 LiveUSB . . and report 
back.


I was actually meaning one of the previous kernel versions from before
the upgrade, but a live USB is a good test as well.



Ah right - I had done an install from scratch with a fresh partitioning 
so a USB LiveOS was what I had to use.


Anyway, I finally got around to booting on a F28 Live USB and the sound 
was just as bad - so it looks like it was not a kernel problem.  Maybe 
there has been a hardware failure in the either the headphones or the 
built-in sound card?  It was time for me to get a new, better set of 
headphones anyway so I will follow up here when they arrive and I can 
test again.


Thanks,

Phil.
--
Philip Rhoades

PO Box 896
Cowra  NSW  2794
Australia
E-mail:  p...@pricom.com.au
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Rawhide buildroot broken by dnf or dnf-plugins-core

2018-11-22 Thread Richard W.M. Jones
On Thu, Nov 22, 2018 at 01:14:18PM +0100, Jaroslav Mracek wrote:
> Thanks for your offer, but builds have been finished. Hope that it solved
> all of issues.

Can confirm it's all working now, thanks.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Rawhide buildroot broken by dnf or dnf-plugins-core

2018-11-22 Thread Jaroslav Mracek
Thanks for your offer, but builds have been finished. Hope that it solved
all of issues.
libdnf-0.22.3-1.fc30

dnf-4.0.9-1.fc30

dnf-plugins-core-4.0.2-1.fc30

dnf-plugins-extras-4.0.0-1.fc30


Jaroslav

On Thu, Nov 22, 2018 at 12:25 PM Richard W.M. Jones 
wrote:

> On Thu, Nov 22, 2018 at 12:21:04PM +0100, Jaroslav Mracek wrote:
> > The update of dnf-plugins-core and dnf-plugins-extras is ready for
> rawhide.
> > But I cannot make fedpkg build due to error:
> > Kerberos authentication fails: unable to obtain a session
> > Could not execute build: Could not login to
> > https://koji.fedoraproject.org/kojihub
> >
> > I will ask a college to do it for me.
>
> I can probably do it.  Is it just those two packages,
> dnf-plugins-{core,extras}?  Do they need to be built in a particular
> order?
>
> Rich.
>
> --
> Richard Jones, Virtualization Group, Red Hat
> http://people.redhat.com/~rjones
> Read my programming and virtualization blog: http://rwmj.wordpress.com
> virt-top is 'top' for virtual machines.  Tiny program with many
> powerful monitoring features, net stats, disk stats, logging, etc.
> http://people.redhat.com/~rjones/virt-top
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> 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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Rawhide buildroot broken by dnf or dnf-plugins-core

2018-11-22 Thread Neal Gompa
On Thu, Nov 22, 2018 at 6:25 AM Richard W.M. Jones  wrote:
>
> On Thu, Nov 22, 2018 at 12:21:04PM +0100, Jaroslav Mracek wrote:
> > The update of dnf-plugins-core and dnf-plugins-extras is ready for rawhide.
> > But I cannot make fedpkg build due to error:
> > Kerberos authentication fails: unable to obtain a session
> > Could not execute build: Could not login to
> > https://koji.fedoraproject.org/kojihub
> >
> > I will ask a college to do it for me.
>
> I can probably do it.  Is it just those two packages,
> dnf-plugins-{core,extras}?  Do they need to be built in a particular
> order?
>

If the buildroot is broken, then you won't be able to do it, since
dnf-plugins-core is required for mock.

But ordinarily, no, they only require DNF, so they can be built in parallel.



-- 
真実はいつも一つ!/ 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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


[Bug 1652560] New: /etc/rt/ RT_SiteConfig.d created without search permission

2018-11-22 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1652560

Bug ID: 1652560
   Summary: /etc/rt/RT_SiteConfig.d created without search
permission
   Product: Fedora
   Version: 29
 Component: rt
  Assignee: rc040...@freenet.de
  Reporter: i...@cs.ox.ac.uk
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org,
rc040...@freenet.de, ti...@math.uh.edu



After installing the rt package:

$ ls -ald /etc/rt/RT_SiteConfig.d
drw-r- 2 apache apache 47 Nov 20 18:06 /etc/rt/RT_SiteConfig.d

We need to manually add 'x' permission before putting config files
in there.  But if rt is upgraded via dnf/rpm then the permissions
get reset and suddenly RT loses its configuration until we figure out
the problem and re-add the permissions.

This seems to be because of the following line in the spec file:

%config(noreplace) %attr(0640,apache,apache) %{_sysconfdir}/%{name}/RT_*

Seen in: 
rt-4.4.2-2.fc28.noarch.rpm
rt-4.4.3-1.fc29.noarch.rpm

-- 
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org


Re: Rawhide buildroot broken by dnf or dnf-plugins-core

2018-11-22 Thread Richard W.M. Jones
On Thu, Nov 22, 2018 at 12:21:04PM +0100, Jaroslav Mracek wrote:
> The update of dnf-plugins-core and dnf-plugins-extras is ready for rawhide.
> But I cannot make fedpkg build due to error:
> Kerberos authentication fails: unable to obtain a session
> Could not execute build: Could not login to
> https://koji.fedoraproject.org/kojihub
> 
> I will ask a college to do it for me.

I can probably do it.  Is it just those two packages,
dnf-plugins-{core,extras}?  Do they need to be built in a particular
order?

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Rawhide buildroot broken by dnf or dnf-plugins-core

2018-11-22 Thread Jaroslav Mracek
The update of dnf-plugins-core and dnf-plugins-extras is ready for rawhide.
But I cannot make fedpkg build due to error:
Kerberos authentication fails: unable to obtain a session
Could not execute build: Could not login to
https://koji.fedoraproject.org/kojihub

I will ask a college to do it for me.

Jaroslav

On Thu, Nov 22, 2018 at 11:57 AM Richard W.M. Jones 
wrote:

>
> DEBUG util.py:439:  Error:
> DEBUG util.py:439:   Problem: package dnf-plugins-core-4.0.0-2.fc30.noarch
> requires python3-dnf-plugins-core = 4.0.0-2.fc30, but none of the providers
> can be installed
> DEBUG util.py:439:- package dnf-4.0.9-1.fc30.noarch conflicts with
> python3-dnf-plugins-core < 4.0.2 provided by
> python3-dnf-plugins-core-4.0.0-2.fc30.noarch
> DEBUG util.py:439:- package supermin-5.1.19-5.fc29.x86_64 requires
> dnf-plugins-core, but none of the providers can be installed
> DEBUG util.py:439:- package supermin-5.1.19-5.fc29.x86_64 requires
> dnf, but none of the providers can be installed
> DEBUG util.py:439:- package libguestfs-1:1.39.11-2.fc30.x86_64
> requires supermin >= 5.1.18, but none of the providers can be installed
> DEBUG util.py:439:- package libguestfs-devel-1:1.39.11-2.fc30.x86_64
> requires libguestfs.so.0()(64bit), but none of the providers can be
> installed
> DEBUG util.py:439:- conflicting requests
> DEBUG util.py:439:  (try to add '--allowerasing' to command line to
> replace conflicting packages or '--skip-broken' to skip uninstallable
> packages)
>
> Rich.
>
> --
> Richard Jones, Virtualization Group, Red Hat
> http://people.redhat.com/~rjones
> Read my programming and virtualization blog: http://rwmj.wordpress.com
> Fedora Windows cross-compiler. Compile Windows programs, test, and
> build Windows installers. Over 100 libraries supported.
> http://fedoraproject.org/wiki/MinGW
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> 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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Proposal: Faster composes by eliminating deltarpms and using zchunked rpms instead

2018-11-22 Thread Roberto Ragusa
On 11/22/2018 05:55 AM, Kevin Kofler wrote:
> 
> The thing is, with a fast network and a slow CPU, deltarpms actually slow 
> you down. No wonder users in such a situation hate them.
> 

Actually, with a fast network and even a FAST CPU, deltarpms actually slow
you down.
There is no CPU where deltarpms is faster than the megabytes/s of a good 
network.

Regards.

-- 
   Roberto Ragusamail at robertoragusa.it
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Rawhide buildroot broken by dnf or dnf-plugins-core

2018-11-22 Thread Richard W.M. Jones

DEBUG util.py:439:  Error: 
DEBUG util.py:439:   Problem: package dnf-plugins-core-4.0.0-2.fc30.noarch 
requires python3-dnf-plugins-core = 4.0.0-2.fc30, but none of the providers can 
be installed
DEBUG util.py:439:- package dnf-4.0.9-1.fc30.noarch conflicts with 
python3-dnf-plugins-core < 4.0.2 provided by 
python3-dnf-plugins-core-4.0.0-2.fc30.noarch
DEBUG util.py:439:- package supermin-5.1.19-5.fc29.x86_64 requires 
dnf-plugins-core, but none of the providers can be installed
DEBUG util.py:439:- package supermin-5.1.19-5.fc29.x86_64 requires dnf, but 
none of the providers can be installed
DEBUG util.py:439:- package libguestfs-1:1.39.11-2.fc30.x86_64 requires 
supermin >= 5.1.18, but none of the providers can be installed
DEBUG util.py:439:- package libguestfs-devel-1:1.39.11-2.fc30.x86_64 
requires libguestfs.so.0()(64bit), but none of the providers can be installed
DEBUG util.py:439:- conflicting requests
DEBUG util.py:439:  (try to add '--allowerasing' to command line to replace 
conflicting packages or '--skip-broken' to skip uninstallable packages)

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


[rpms/perl-Encode-Detect] PR #1: Remove old cruft

2018-11-22 Thread Ondřej Lysoněk

olysonek opened a new pull-request against the project: `perl-Encode-Detect` 
that you are following:
``
Remove old cruft
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-Encode-Detect/pull-request/1
___
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org


Re: prevent accidentally creating branches in dist-git

2018-11-22 Thread Matthias Runge
On Wed, Nov 21, 2018 at 09:34:14AM -0600, Jason L Tibbitts III wrote:
> > "DM" == Dusty Mabe  writes:
> DM> I personally think this should be the default for all projects but I
> DM> don't know if there is a way to easily make that happen when a
> DM> project gets created.

> I'm sure there could be.  But I'd go further and say that we should set
> that on all existing repositories and then let folks opt out if they
> wish.

Yes,

that is a good suggestion. It'd prevent some unexpected things to happen
otherwise.

Best,
Matthias
-- 
Matthias Runge 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Something is broken in low-level components, processes segfault

2018-11-22 Thread Florian Weimer
* Igor Gnatenko:

> https://apps.fedoraproject.org/koschei/build/5700914
>
>   process didn't exit successfully: `/usr/bin/rustc --crate-name
> glib_sys src/lib.rs --color never --crate-type lib
> --emit=dep-info,link -C opt-level=3 -C metadata=20d7ee6da134c60a -C
> extra-filename=-20d7ee6da134c60a --out-dir
> /builddir/build/BUILD/glib-sys-0.6.0/target/release/deps -L
> dependency=/builddir/build/BUILD/glib-sys-0.6.0/target/release/deps
> --extern 
> bitflags=/builddir/build/BUILD/glib-sys-0.6.0/target/release/deps/libbitflags-056f832aae1b729d.rlib
> --extern 
> libc=/builddir/build/BUILD/glib-sys-0.6.0/target/release/deps/liblibc-626066f325dbf1d3.rlib
> -Copt-level=3 -Cdebuginfo=2 -Clink-arg=-Wl,-z,relro,-z,now -l
> glib-2.0` (signal: 11, SIGSEGV: invalid memory reference)
>
> There were just libxcrypt/glibc/llvm/annobin updates, so it's hard to
> guess what exactly is broken.

This is .  I will
revert the most likely upstream patch that causes this.

Sorry for the inconvenience.

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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


upgrade your libtaskotron virtualenv to python3

2018-11-22 Thread Kamil Paral
Hi taskotron developers,

we've recently switched to using python3 by default in libtaskotron and all
taskotron tasks. So if you have your local virtualenv to be used with
libtaskotron, I suggest you re-create it with python3 [1] instead of
python2, because that's how libtaskotron is going to get used from now on.

Cheers,
Kamil

[1]
https://qa.fedoraproject.org/docs/libtaskotron/latest/devguide.html#installing-a-development-environment
___
qa-devel mailing list -- qa-devel@lists.fedoraproject.org
To unsubscribe send an email to qa-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/qa-devel@lists.fedoraproject.org


[Bug 1651944] Upgrade perl-Net-Whois-Raw to 2.99021

2018-11-22 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1651944

Jitka Plesnikova  changed:

   What|Removed |Added

   Assignee|dd...@cpan.org  |jples...@redhat.com



-- 
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org


[Bug 1651944] Upgrade perl-Net-Whois-Raw to 2.99021

2018-11-22 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1651944

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-Net-Whois-Raw-2.99.021
   ||-1.fc30
 Resolution|--- |RAWHIDE
Last Closed||2018-11-22 03:56:51



-- 
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org


[Bug 1652477] Upgrade perl-Config-Model to 2.128

2018-11-22 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1652477



--- Comment #1 from Fedora Update System  ---
perl-Config-Model-2.128-1.fc29 has been submitted as an update to Fedora 29.
https://bodhi.fedoraproject.org/updates/FEDORA-2018-391b489bff

-- 
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org


Re: prevent accidentally creating branches in dist-git

2018-11-22 Thread Dominik 'Rathann' Mierzejewski
On Wednesday, 21 November 2018 at 16:34, Jason L Tibbitts III wrote:
> > "DM" == Dusty Mabe  writes:
> 
> DM> I personally think this should be the default for all projects but I
> DM> don't know if there is a way to easily make that happen when a
> DM> project gets created.
> 
> I'm sure there could be.  But I'd go further and say that we should set
> that on all existing repositories and then let folks opt out if they
> wish.

+1, definitely.

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPMFusion   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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


[Bug 1652477] Upgrade perl-Config-Model to 2.128

2018-11-22 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1652477

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-Config-Model-2.128-1.f
   ||c30



-- 
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org


[Bug 1652477] Upgrade perl-Config-Model to 2.128

2018-11-22 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1652477

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|david.hanneq...@gmail.com   |jples...@redhat.com



-- 
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org


[Bug 1652477] New: Upgrade perl-Config-Model to 2.128

2018-11-22 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1652477

Bug ID: 1652477
   Summary: Upgrade perl-Config-Model to 2.128
   Product: Fedora
   Version: rawhide
 Component: perl-Config-Model
  Assignee: david.hanneq...@gmail.com
  Reporter: jples...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: david.hanneq...@gmail.com,
perl-devel@lists.fedoraproject.org



Latest Fedora delivers 2.127 version. Upstream released 2.128. When you have
free time, please upgrade it.

-- 
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org