date:20161201

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



--- Comment #6 from Fedora Update System  ---
perl-DBD-MySQL-4.039-2.fc24 has been pushed to the Fedora 24 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-2016-302f840ecf

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

Re: failure of f24 to f25 upgrade: SOLVED

On Fri, 2016-12-02 at 03:05 +0200, Alexander Ploumistos wrote:
> I think you might be missing Google's key:
> https://www.google.com/linuxrepositories/
> 
> 
> 
> 
Thanks, got it.

Regards,
Les H___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[389-devel] Re: Build failed in Jenkins: 389-DS-NIGHTLY #149

2016-12-01 Thread William Brown

On Thu, 2016-12-01 at 09:16 +1000, William Brown wrote:
> > CRITICAL:stress_tests:DeleteUsers: failed to delete 
> > (uid=person3,dc=example,dc=com) error: Can'\''t contact LDAP server
> > CRITICAL:stress_tests:DeleteUsers: failed to delete 
> > (uid=employee4,dc=example,dc=com) error: Can'\''t contact LDAP server
> > CRITICAL:stress_tests:DeleteUsers: failed to delete 
> > (uid=entry4,dc=example,dc=com) error: Can'\''t contact LDAP server
> > Exception in thread Thread-37:
> > Traceback (most recent call last):
> >   File "/usr/lib64/python2.7/threading.py", line 804, in __bootstrap_inner
> > self.run()
> >   File 
> > "
> >  line 92, in run
> > assert False
> > AssertionError: assert False
> > 
> 
> 
> I will also be investigating this error today. 
> 

https://fedorahosted.org/389/ticket/48894



-- 
Sincerely,

William Brown
Software Engineer
Red Hat, Brisbane


signature.asc
Description: This is a digitally signed message part
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org

[Bug 1178357] mojomojo-1.11 is available

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

Filipe Rosset  changed:

   What|Removed |Added

 Status|NEW |CLOSED
 CC||rosset.fil...@gmail.com
 Resolution|--- |WONTFIX
Last Closed||2016-12-01 21:44:28



--- Comment #1 from Filipe Rosset  ---
Package retired

http://pkgs.fedoraproject.org/cgit/rpms/mojomojo.git/commit/?id=86e615e13819264771b6c706d8cc4ff2c2a92712

-- 
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 1400755] perl-Pod-Simple-3.35 is available

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



--- Comment #1 from Upstream Release Monitoring 
 ---
Patching or scratch build for perl-Pod-Simple-3.32 failed.

-- 
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 1400755] perl-Pod-Simple-3.35 is available

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



--- Comment #3 from Upstream Release Monitoring 
 ---
Patches were not touched. All were applied properly

-- 
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 1400755] perl-Pod-Simple-3.35 is available

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



--- Comment #2 from Upstream Release Monitoring 
 ---
Created attachment 1227123
  --> https://bugzilla.redhat.com/attachment.cgi?id=1227123=edit
Rebase-helper rebase-helper-debug.log log file.
See for details and report the eventual error to rebase-helper
https://github.com/phracek/rebase-helper/issues.

-- 
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 1400755] New: perl-Pod-Simple-3.35 is available

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

Bug ID: 1400755
   Summary: perl-Pod-Simple-3.35 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Pod-Simple
  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,
st...@silug.org



Latest upstream release: 3.35
Current version/release in rawhide: 3.32-365.fc25
URL: http://search.cpan.org/dist/Pod-Simple/

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

-- 
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 1400750] New: perl-Test-Strict-0.38 is available

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

Bug ID: 1400750
   Summary: perl-Test-Strict-0.38 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Test-Strict
  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.38
Current version/release in rawhide: 0.37-1.fc25
URL: http://search.cpan.org/dist/Test-Strict/

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

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

Re: failure of f24 to f25 upgrade: SOLVED

2016-12-01 Thread stan

On Thu, 01 Dec 2016 16:43:13 -0800
Howard Howell  wrote:

> warning: /var/cache/dnf/google-earth-17f28a61f303b7a2/packages/google-
> earth-stable-6.0.3.2197-0.x86_64.rpm: Header V4 DSA/SHA1 Signature,
> key ID 7fac5991: NOKEY
> The downloaded packages were saved in cache until the next successful
> transaction.
> You can remove cached packages by executing 'dnf clean packages'.
> Error: Public key for google-earth-stable-6.0.3.2197-0.x86_64.rpm is
> not installed
> 
> Still some work to do.  Is there any thing specific you believe I
> should say in the bugzilla post?

You shouldn't open a bugzilla against Fedora, since Fedora doesn't
sponsor the google-earth repository.  If you open a ticket at
google-earth, you should just quote the errors above in the ticket.

But you could just follow the advice that Max Pyziur wrote:

> Once the upgrade completed, and everything seemed to be functioning
> correctly, I then did a
> dnf install  package that I
> downloaded from the Google Earth page.

That is, he disabled the repository and installed from a downloaded
package instead.  It doesn't fix the issue of the keys, it bypasses it.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: failure of f24 to f25 upgrade: SOLVED

2016-12-01 Thread Alexander Ploumistos

I think you might be missing Google's key:
https://www.google.com/linuxrepositories/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

2016-12-01 Thread updates

The following Fedora EPEL 5 Security updates need testing:
 Age  URL
 753  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2014-3849   
sblim-sfcb-1.3.8-2.el5
 396  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-edbea40516   
mcollective-2.8.4-1.el5
 368  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-582c8075e6   
thttpd-2.25b-24.el5
  12  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-6cd7f05048   
drupal7-7.52-1.el5
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-e172bd9393   
phpMyAdmin4-4.0.10.18-1.el5
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-d99f990696   
php-php-gettext-1.0.12-1.el5
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-88041bbead   
php53-php-gettext-1.0.12-1.el5


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

R-qtl-1.40.8-1.el5
dpm-dsi-1.9.10-3.el5
iftop-1.0-0.12.pre4.el5
libmad-0.15.1b-19.el5

Details about builds:



 R-qtl-1.40.8-1.el5 (FEDORA-EPEL-2016-995e3fd86e)
 Tools for analyzing QTL experiments

Update Information:

Version 1.40, 2016-10-31  Major changes:  - cim() now halts with an error for
cross type "4way". The method has not been implemented for 4-way crosses, and
the results are not meaningful.  Minor changes:  - Small change to the way
Bayesian credible intervals are calculated by bayesint(), concerning the
treatment of widths of intervals between positions.  - Fix bug in
switchAlleles() so that it works with cross type "bcsft" (and will give an
appropriate error message for unsupported cross types).  - sim.cross gives a
warning if model is specified but not used (this is the case for RILs, where
we've not implemented the simulation of QTL effects)  - plot.pxg (aka plotPXG)
passes ... to plot(), so now you can control the y-axis limits via ylim.  -
Fixed a problem with column names of output of scantwopermhk.




 dpm-dsi-1.9.10-3.el5 (FEDORA-EPEL-2016-5e513bab91)
 Disk Pool Manager (DPM) plugin for the Globus GridFTP server

Update Information:

* updated dmlite dep




 iftop-1.0-0.12.pre4.el5 (FEDORA-EPEL-2016-c130571340)
 Command line tool that displays bandwidth usage on an interface

Update Information:

- Added patch to fix broken MAC address output (#1063298, #1165349)

References:

  [ 1 ] Bug #1165349 - Odd behavior when displaying MAC address
https://bugzilla.redhat.com/show_bug.cgi?id=1165349




 libmad-0.15.1b-19.el5 (FEDORA-EPEL-2016-8372ec0566)
 MPEG audio decoder library

Update Information:

Initial import from elsewhere. rhbz#1396139

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

Re: failure of f24 to f25 upgrade: SOLVED

On Thu, 2016-12-01 at 14:52 -0800, Adam Williamson wrote:
> On Thu, 2016-12-01 at 17:03 -0500, Przemek Klosowski wrote:
> > This got me thinking if there's a common root cause that could be 
> > checked automatically? I didn't quite understand what exactly
> > happened 
> > in the affected packages to cause it.
> 
> No, they're usually all different little awkward packaging corner
> cases.
> 
> For instance, one common one in the F24 -> F25 upgrade involved the
> rpm
> python subpackages. These were called rpm-python and rpm-python3 in
> F24, but in F25 they were renamed to python2-rpm and python3-rpm . Of
> course, the F25 packages got lines like:
> 
> Obsoletes: rpm-python < %{version}-%{release}
> Provides: rpm-python = %{version}-%{release}
> 
> Obsoletes: rpm-python3 < %{version}-%{release}
> Provides: rpm-python3 = %{version}-%{release}
> 
> Unfortunately, the F24 stable 'rpm' package actually got *ahead* of
> the
> F25 stable rpm package for a while. So when you tried to run the
> upgrade, the obsoletion didn't kick in - because the F24 package
> *wasn't* "< %{version}-%{release}". But dnf couldn't keep the old
> rpm-
> python(3) package(s) around because then some other dependency chain
> wasn't satisfied (I forget the details). So it simply had no way to
> resolve the problem without removing everything that required rpm-
> python or rpm-python3 ...
> 
> But that's just one possible case, there have been many others.
> Packaging is hard. You can usually figure it out, if you dig into a
> bit; it *does* help to file bugs so the issues can be solved for
> others.
The rpm -e did in fact fix the issue.  The completeness solution posted
by John (I think that was who posted it) was a good idea.  However as
was pointed out, the package for Google-earth still has some issues.  I
need it to continue the development of the friends program, so I re-
installed it using dnf, and got the following error:
# dnf install google-earth
Last metadata expiration check: 0:46:41 ago on Thu Dec  1 15:46:43
2016.
Dependencies resolved.
===
=
 Package  ArchVersion   Repository 
Size
===
=
Installing:
 google-earth-stable  x86_64  6.0.3.2197-0  google-
earth   30 M

Transaction Summary
===
=
Install  1 Package

Total download size: 30 M
Installed size: 92 M
Is this ok [y/N]: y
Downloading Packages:
google-earth-stable-6.0.3.2197-0.x86_64.rpm 356 kB/s |  30
MB 01:27
-
---
Total   356 kB/s |  30
MB 01:27 
warning: /var/cache/dnf/google-earth-17f28a61f303b7a2/packages/google-
earth-stable-6.0.3.2197-0.x86_64.rpm: Header V4 DSA/SHA1 Signature, key
ID 7fac5991: NOKEY
The downloaded packages were saved in cache until the next successful
transaction.
You can remove cached packages by executing 'dnf clean packages'.
Error: Public key for google-earth-stable-6.0.3.2197-0.x86_64.rpm is
not installed

Still some work to do.  Is there any thing specific you believe I
should say in the bugzilla post?

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

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

2016-12-01 Thread updates

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
 634  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-1087   
dokuwiki-0-0.24.20140929c.el7
 396  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-dac7ed832f   
mcollective-2.8.4-1.el7
 114  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-23fa04bf1c   
redis-3.2.3-1.el7
  98  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-e8f4ff76b3   
chicken-4.11.0-3.el7
  41  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-ee3cc4d1b6   
compat-guile18-1.8.8-14.el7
  12  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-103c5b0f17   
drupal7-7.52-1.el7
  12  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-c7640e3ff5   
teeworlds-0.6.4-2.el7
   9  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-05f68ac70b   
p7zip-16.02-2.el7
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-a0a16db403   
dpkg-1.17.27-1.el7
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-0e9b9b02bb   
phpMyAdmin-4.4.15.9-1.el7
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-89c47c50a3   
mingw-gdk-pixbuf-2.30.8-2.el7 mingw-qt5-qtimageformats-5.6.0-2.el7 
mingw-jasper-1.900.28-1.el7
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-bd288eeb9f   
php-php-gettext-1.0.12-1.el7
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-7059e6dc35   
roundcubemail-1.1.7-1.el7


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

R-qtl-1.40.8-1.el7
deja-dup-34.3-1.el7
distribution-gpg-keys-1.9-1.el7
dmlite-0.8.4-1.el7
iftop-1.0-0.12.pre4.el7
keepassx2-2.0.3-2.el7
libmad-0.15.1b-19.el7
mirmon-2.11-1.el7
php-punic-1.6.4-1.el7
python-cccolutils-1.4-1.el7
python-pypandoc-1.3.3-2.el7
python-rpmfluff-0.5.2-1.el7
shorewall-5.0.14.1-1.el7
yamllint-1.6.0-1.el7

Details about builds:



 R-qtl-1.40.8-1.el7 (FEDORA-EPEL-2016-5f8b1e694b)
 Tools for analyzing QTL experiments

Update Information:

Version 1.40, 2016-10-31  Major changes:  - cim() now halts with an error for
cross type "4way". The method has not been implemented for 4-way crosses, and
the results are not meaningful.  Minor changes:  - Small change to the way
Bayesian credible intervals are calculated by bayesint(), concerning the
treatment of widths of intervals between positions.  - Fix bug in
switchAlleles() so that it works with cross type "bcsft" (and will give an
appropriate error message for unsupported cross types).  - sim.cross gives a
warning if model is specified but not used (this is the case for RILs, where
we've not implemented the simulation of QTL effects)  - plot.pxg (aka plotPXG)
passes ... to plot(), so now you can control the y-axis limits via ylim.  -
Fixed a problem with column names of output of scantwopermhk.




 deja-dup-34.3-1.el7 (FEDORA-EPEL-2016-c65d42a188)
 Simple backup tool and frontend for duplicity

Update Information:

https://launchpad.net/deja-dup/+announcement/14368

References:

  [ 1 ] Bug #1400115 - deja-dup-34.3 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1400115




 distribution-gpg-keys-1.9-1.el7 (FEDORA-EPEL-2016-b0b510f15b)
 GPG keys of various Linux distributions

Update Information:

- add new Copr' keys - add Fedora 26 keys - add more CentOS 7 keys (aarch64,
debug, SIGs, testing)




 dmlite-0.8.4-1.el7 (FEDORA-EPEL-2016-5bbe5ebbed)
 Lcgdm grid data management and storage framework

Update Information:

*  new upstrem release    * new upstream release    * new upstream
release    * bug fixes    * new upstream release

References:

  [ 1 ] Bug #1384305 - dnf upgrade produces error msgs
https://bugzilla.redhat.com/show_bug.cgi?id=1384305




 iftop-1.0-0.12.pre4.el7

[Bug 1400735] New: perl-Locale-Codes-3.42 is available

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

Bug ID: 1400735
   Summary: perl-Locale-Codes-3.42 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Locale-Codes
  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: 3.42
Current version/release in rawhide: 3.41-1.fc26
URL: http://search.cpan.org/dist/Locale-Codes/

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

-- 
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 1393364] perl-Inline-Python-0.52 is available

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



--- Comment #6 from Upstream Release Monitoring 
 ---
Created attachment 1227088
  --> https://bugzilla.redhat.com/attachment.cgi?id=1227088=edit
Rebase-helper rebase-helper-debug.log log file.
See for details and report the eventual error to rebase-helper
https://github.com/phracek/rebase-helper/issues.

-- 
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 1393364] perl-Inline-Python-0.52 is available

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



--- Comment #7 from Upstream Release Monitoring 
 ---
Patches were not touched. All were applied properly

-- 
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 1395138] stompclt-1.5 is available

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|stompclt-1.5-1.fc25 |stompclt-1.5-1.fc25
   |stompclt-1.5-1.el6  |stompclt-1.5-1.el6
   |stompclt-1.5-1.el7  |stompclt-1.5-1.el7
   ||stompclt-1.5-1.el5



--- Comment #12 from Fedora Update System  ---
stompclt-1.5-1.el5 has been pushed to the Fedora EPEL 5 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

[Bug 1393364] perl-Inline-Python-0.52 is available

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



--- Comment #5 from Upstream Release Monitoring 
 ---
Patching or scratch build for perl-Inline-Python-0.50 failed.

-- 
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 1393364] perl-Inline-Python-0.52 is available

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

Upstream Release Monitoring  
changed:

   What|Removed |Added

Summary|perl-Inline-Python-0.51 is  |perl-Inline-Python-0.52 is
   |available   |available



--- Comment #4 from Upstream Release Monitoring 
 ---
Latest upstream release: 0.52
Current version/release in rawhide: 0.50-1.fc26
URL: http://search.cpan.org/dist/Inline-Python/

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

-- 
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 1400728] New: perl-Date-Manip-6.57 is available

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

Bug ID: 1400728
   Summary: perl-Date-Manip-6.57 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Date-Manip
  Keywords: FutureFeature, Triaged
  Assignee: jpazdzi...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: jpazdzi...@redhat.com,
perl-devel@lists.fedoraproject.org



Latest upstream release: 6.57
Current version/release in rawhide: 6.56-1.fc26
URL: http://search.cpan.org/dist/Date-Manip/

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

-- 
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 1395591] CVE-2016-1249 perl-DBD-MySQL: Out-of-bounds read when using server-side prepared statement support

https://bugzilla.redhat.com/show_bug.cgi?id=1395591
Bug 1395591 depends on bug 1395592, which changed state.

Bug 1395592 Summary: CVE-2016-1249 perl-DBD-MySQL: Out-of-bounds read when 
using server-side prepared statement support [fedora-all]
https://bugzilla.redhat.com/show_bug.cgi?id=1395592

   What|Removed |Added

 Status|CLOSED  |ON_QA
 Resolution|ERRATA  |---



-- 
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 1399581] CVE-2016-1251 perl-DBD-MySQL: Use after free when using prepared statements [fedora-all]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #5 from Fedora Update System  ---
perl-DBD-MySQL-4.033-4.fc23 has been pushed to the Fedora 23 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-2016-bf6c3ea62c

-- 
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 1395592] CVE-2016-1249 perl-DBD-MySQL: Out-of-bounds read when using server-side prepared statement support [ fedora-all]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|CLOSED  |ON_QA
 Resolution|ERRATA  |---
   Keywords||Reopened



--- Comment #12 from Fedora Update System  ---
perl-DBD-MySQL-4.033-4.fc23 has been pushed to the Fedora 23 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-2016-bf6c3ea62c

-- 
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 1398478] perl-Perl-Critic-Pulp-91 is available

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #14 from Fedora Update System  ---
perl-Perl-Critic-Pulp-92-1.fc23 has been pushed to the Fedora 23 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-2016-177bbd6ad1

-- 
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 1400224] perl-Perl-Critic-Pulp-92 is available

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #5 from Fedora Update System  ---
perl-Perl-Critic-Pulp-92-1.fc23 has been pushed to the Fedora 23 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-2016-177bbd6ad1

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

spot pushed to perl-Config-IniFiles (master). "2.94"

From 6c32cd5a45785158792d9c0b20d5cda2b13a17e6 Mon Sep 17 00:00:00 2001
From: Tom Callaway 
Date: Thu, 1 Dec 2016 13:49:21 -0500
Subject: 2.94

---
 .gitignore| 1 +
 perl-Config-IniFiles.spec | 5 -
 sources   | 2 +-
 3 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/.gitignore b/.gitignore
index 6d099da..7596cd4 100644
--- a/.gitignore
+++ b/.gitignore
@@ -14,3 +14,4 @@ Config-IniFiles-2.58.tar.gz
 /Config-IniFiles-2.91.tar.gz
 /Config-IniFiles-2.92.tar.gz
 /Config-IniFiles-2.93.tar.gz
+/Config-IniFiles-2.94.tar.gz
diff --git a/perl-Config-IniFiles.spec b/perl-Config-IniFiles.spec
index 815890c..c98a453 100644
--- a/perl-Config-IniFiles.spec
+++ b/perl-Config-IniFiles.spec
@@ -1,5 +1,5 @@
 Name:   perl-Config-IniFiles
-Version:2.93
+Version:2.94
 Release:1%{?dist}
 Summary:A module for reading .ini-style configuration files
 Group:  Development/Libraries
@@ -84,6 +84,9 @@ perl Build.PL installdirs=vendor
 %{_mandir}/man3/*.3pm*
 
 %changelog
+* Thu Dec  1 2016 Tom Callaway  - 2.94-1
+- update to 2.94
+
 * Mon Jul 25 2016 Tom Callaway  - 2.93-1
 - update to 2.93
 
diff --git a/sources b/sources
index 3f47f31..f82d52e 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-f02b3639ed12c08022d537bc0356725c  Config-IniFiles-2.93.tar.gz
+0828508c1c7663760c8a1bd6d1b2ff94  Config-IniFiles-2.94.tar.gz
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl-Config-IniFiles.git/commit/?h=master=6c32cd5a45785158792d9c0b20d5cda2b13a17e6
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

spot uploaded Config-IniFiles-2.94.tar.gz for perl-Config-IniFiles

0828508c1c7663760c8a1bd6d1b2ff94  Config-IniFiles-2.94.tar.gz

http://pkgs.fedoraproject.org/lookaside/pkgs/perl-Config-IniFiles/Config-IniFiles-2.94.tar.gz/md5/0828508c1c7663760c8a1bd6d1b2ff94/Config-IniFiles-2.94.tar.gz
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: failure of f24 to f25 upgrade

On Thu, 2016-12-01 at 17:03 -0500, Przemek Klosowski wrote:
> This got me thinking if there's a common root cause that could be 
> checked automatically? I didn't quite understand what exactly happened 
> in the affected packages to cause it.

No, they're usually all different little awkward packaging corner
cases.

For instance, one common one in the F24 -> F25 upgrade involved the rpm
python subpackages. These were called rpm-python and rpm-python3 in
F24, but in F25 they were renamed to python2-rpm and python3-rpm . Of
course, the F25 packages got lines like:

Obsoletes: rpm-python < %{version}-%{release}
Provides: rpm-python = %{version}-%{release}

Obsoletes: rpm-python3 < %{version}-%{release}
Provides: rpm-python3 = %{version}-%{release}

Unfortunately, the F24 stable 'rpm' package actually got *ahead* of the
F25 stable rpm package for a while. So when you tried to run the
upgrade, the obsoletion didn't kick in - because the F24 package
*wasn't* "< %{version}-%{release}". But dnf couldn't keep the old rpm-
python(3) package(s) around because then some other dependency chain
wasn't satisfied (I forget the details). So it simply had no way to
resolve the problem without removing everything that required rpm-
python or rpm-python3 ...

But that's just one possible case, there have been many others.
Packaging is hard. You can usually figure it out, if you dig into a
bit; it *does* help to file bugs so the issues can be solved for
others.
-- 
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

Re: Rawhide aarch64: gcc bus error

2016-12-01 Thread Justin Forbes

On Thu, Dec 1, 2016 at 4:37 PM, Justin Forbes  wrote:
> On Wed, Nov 30, 2016 at 10:45 PM, Orion Poplawski  wrote:
>> On 11/30/2016 04:20 PM, Richard W.M. Jones wrote:
>>>
>>> On Wed, Nov 30, 2016 at 10:08:55PM +, Richard W.M. Jones wrote:

 On Wed, Nov 30, 2016 at 02:07:13PM -0700, Jerry James wrote:
>
> I'm trying to build python-cvxopt, but gcc is failing on aarch64 with
> a bus error:
>
> http://koji.fedoraproject.org/koji/taskinfo?taskID=16684863


 As a data point, the build succeeds on F25/aarch64 with:

   glibc-2.24-3.fc25.aarch64
   gcc-6.2.1-2.fc25.aarch64

 I'll spin up a Rawhide VM later to see if I can reproduce this with
 the suspect glibc etc (don't want to risk upgrading glibc on my main
 machine :-)
>>>
>>>
>>> On Rawhide (updated partially from F25), the compile works OK with:
>>>
>>> glibc-2.24-3.fc25.aarch64
>>> gcc-6.2.1-2.fc26.aarch64
>>>
>>> and it still *works* if I upgrade glibc to:
>>>
>>> glibc-2.24.90-19.fc26.aarch64
>>>
>>> (leaving all other non-glibc-related packages unchanged).
>>>
>>> But it *fails* in exactly the way you describe if I upgrade glibc to:
>>>
>>> glibc-2.24.90-20.fc26.aarch64
>>>
>>> So it looks fairly conclusively like it's something to do with the
>>> latest glibc, and you need to be looking at the differences between
>>> the -19 and -20 packages.
>>
>>
>> Thanks.  I've untaged it.
>>
>
> Seems like it is not actually untagged. My kernel build failed again
> today and it is still using -20.
>

Ignore me, I was looking at the wrong logs it seems. That was
yesterday's build. Today's works.

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

Re: Rawhide aarch64: gcc bus error

2016-12-01 Thread Justin Forbes

On Wed, Nov 30, 2016 at 10:45 PM, Orion Poplawski  wrote:
> On 11/30/2016 04:20 PM, Richard W.M. Jones wrote:
>>
>> On Wed, Nov 30, 2016 at 10:08:55PM +, Richard W.M. Jones wrote:
>>>
>>> On Wed, Nov 30, 2016 at 02:07:13PM -0700, Jerry James wrote:

 I'm trying to build python-cvxopt, but gcc is failing on aarch64 with
 a bus error:

 http://koji.fedoraproject.org/koji/taskinfo?taskID=16684863
>>>
>>>
>>> As a data point, the build succeeds on F25/aarch64 with:
>>>
>>>   glibc-2.24-3.fc25.aarch64
>>>   gcc-6.2.1-2.fc25.aarch64
>>>
>>> I'll spin up a Rawhide VM later to see if I can reproduce this with
>>> the suspect glibc etc (don't want to risk upgrading glibc on my main
>>> machine :-)
>>
>>
>> On Rawhide (updated partially from F25), the compile works OK with:
>>
>> glibc-2.24-3.fc25.aarch64
>> gcc-6.2.1-2.fc26.aarch64
>>
>> and it still *works* if I upgrade glibc to:
>>
>> glibc-2.24.90-19.fc26.aarch64
>>
>> (leaving all other non-glibc-related packages unchanged).
>>
>> But it *fails* in exactly the way you describe if I upgrade glibc to:
>>
>> glibc-2.24.90-20.fc26.aarch64
>>
>> So it looks fairly conclusively like it's something to do with the
>> latest glibc, and you need to be looking at the differences between
>> the -19 and -20 packages.
>
>
> Thanks.  I've untaged it.
>

Seems like it is not actually untagged. My kernel build failed again
today and it is still using -20.

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

Re: failure of f24 to f25 upgrade

2016-12-01 Thread stan

On Thu, 1 Dec 2016 17:03:30 -0500
Przemek Klosowski  wrote:

> On 12/01/2016 04:39 PM, Howard Howell wrote:
> > It looks like probably Dominik's suggestion of the -e cleared the
> > program.  So somehow, rpm -e packagename seemed to be the magic
> > bullet. I will start overwith the update to make sure all the
> > packages downloaded, and let you know if success happens.  
> FWIW, I had several file conflicts resulting from standard F24
> packages that blocked the upgrade to F25.
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1396848
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1396849
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1396319
> 
> that requireddnf erase . Sometimes these
> erasures had a slightly worrying amount of dependencies (a dozen, not
> hundreds, though), and in each case they reinstalled smoothly after
> the OS upgrade. Two of those have been promptly fixed by the
> packagers, and apparently are no longer an isssue.
> 
> This got me thinking if there's a common root cause that could be 
> checked automatically? I didn't quite understand what exactly
> happened in the affected packages to cause it.
> 

Usually this is because of library version conflicts.  The F24 package
was compiled with an earlier library, but your upgrade is going to
replace that library with a new version, and there is no F25 package
(yet) that uses the new library version.  =><=

I think this is due to the freeze, as packages accumulate in updates
and updates testing during the freeze before release.  That's why they
updated so smoothly after the upgrade.

There was a discussion on this list recently about this very issue, and
my take away from that discussion was that this is a consequence of the
release process itself, and would be non-trivial to fix.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1396860] perl-Module-CoreList-5.20161120 is available

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Module-CoreList-5.2016 |perl-Module-CoreList-5.2016
   |1120-1.fc26 |1120-1.fc26
   |perl-Module-CoreList-5.2016 |perl-Module-CoreList-5.2016
   |1120-1.fc25 |1120-1.fc25
   |perl-Module-CoreList-5.2016 |perl-Module-CoreList-5.2016
   |1120-1.fc24 |1120-1.fc24
   ||perl-Module-CoreList-5.2016
   ||1120-1.fc23



--- Comment #10 from Fedora Update System  ---
perl-Module-CoreList-5.20161120-1.fc23 has been pushed to the Fedora 23 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

Re: failure of f24 to f25 upgrade

2016-12-01 Thread Przemek Klosowski


On 12/01/2016 04:39 PM, Howard Howell wrote:

It looks like probably Dominik's suggestion of the -e cleared the
program.  So somehow, rpm -e packagename seemed to be the magic bullet.
  I will start overwith the update to make sure all the packages
downloaded, and let you know if success happens.
FWIW, I had several file conflicts resulting from standard F24 packages 
that blocked the upgrade to F25.


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

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

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

that requireddnf erase . Sometimes these erasures 
had a slightly worrying amount of dependencies (a dozen, not hundreds, 
though), and in each case they reinstalled smoothly after the OS 
upgrade. Two of those have been promptly fixed by the packagers, and 
apparently are no longer an isssue.


This got me thinking if there's a common root cause that could be 
checked automatically? I didn't quite understand what exactly happened 
in the affected packages to cause it.


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

Re: failure of f24 to f25 upgrade

2016-12-01 Thread John Florian

On Thu, 2016-12-01 at 13:32 -0800, Howard Howell wrote:
On Thu, 2016-12-01 at 21:25 +, John Florian wrote:
On Thu, 2016-12-01 at 12:55 -0800, Adam Williamson wrote:

On Thu, 2016-12-01 at 12:35 -0800, Josh Stone wrote:



Perhaps dnf thinks google-earth is now the authority on %{_bindir} ?
So removing it is tearing the rug out from under all those others?



Well, I don't think so, as I'd expect that to rip out much *more*
stuff. I think it must be something a bit more odd than /usr/bin . The
'filesystem' package provides /usr/bin too, and that ought to be
installed.


That's a good point.  What does `rpm -V filesystem` show?

___



Nothing!# rpm -V filesystem
#

I think you're in good shape then.  It sounds like the `rpm -e` did what was 
needed and you're now back to a more normal Fedora.  I suspect your upgrade 
will go smoothly now.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: failure of f24 to f25 upgrade

On Thu, 2016-12-01 at 14:32 -0700, stan wrote:
> On Thu, 01 Dec 2016 11:32:33 -0800
> Howard Howell  wrote:
> 
> > 
> > Hi, everyone,
> > I have been trying to upgrade my system from f24 to f25 using
> > the cli in the terminal.
> > 
> >   814  dnf system-upgrade download --releasever=25
> >   815  dnf system-upgrade download --releasever=25 --allowerasing
> >   816  dnf system-upgrade download --releasever=25 --allowerasing
> > --
> > nogpgcheck
> > 
> >   all run from superuser.
> > 
> >   error: 
> > Running transaction check
> > Transaction check succeeded.
> > Running transaction test
> > The downloaded packages were saved in cache until the next
> > successful
> > transaction.
> > You can remove cached packages by executing 'dnf clean packages'.
> > Error: Transaction check error:
> >   file /usr/bin from install of
> > google-earth-stable-6.0.3.2197-0.x86_64 conflicts with file from
> > package filesystem-3.2-37.fc24.x86_64 # dnf --system-upgrade reboot
> > will not run due to same error.
> 
> This is a well known error in the spec file for the google earth
> file.
> It tries to own /usr/bin, which it can't own, and so fails.
> 
> Here's a web reference to it.
> http://forums.fedoraforum.org/showthread.php?t=302767
> and here
> https://ask.fedoraproject.org/en/question/85979/transaction-check-err
> or-during-google-earth-install/
> 
> A long time ago I installed google earth, and used a work around on
> the
> spec file.  I don't remember it now, but it worked with the rebuilt
> rpm
> file.
> 
> The way to fix this so you can upgrade is by removing only google
> earth using rpm directly, instead of through dnf.
> 
> rpm --erase --nodeps --test [google-earth-stable?]
> 
> This will test the command without doing anything.  When it does what
> you want, remove the --test option.
> 
> After the upgrade, you can look for ways to re-install google earth.
Thanks, Rich, Dominik, Adam, Josh and John.  It appears that both
versions are now gone.

It looks like probably Dominik's suggestion of the -e cleared the
program.  So somehow, rpm -e packagename seemed to be the magic bullet.
 I will start overwith the update to make sure all the packages
downloaded, and let you know if success happens.

Thank you all for your support.

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

Re: failure of f24 to f25 upgrade

On Thu, 2016-12-01 at 21:25 +, John Florian wrote:
> 
> On Thu, 2016-12-01 at 12:55 -0800, Adam Williamson wrote:
> 
> > On Thu, 2016-12-01 at 12:35 -0800, Josh Stone wrote:
> > > 
> > > > > > Perhaps dnf thinks google-earth is now the authority on
%{_bindir} ?
> > > > > > So removing it is tearing the rug out from under all those
others?
> > 
> > Well, I don't think so, as I'd expect that to rip out much *more*
> > > > stuff. I think it must be something a bit more odd than /usr/bin .
The
> > 'filesystem' package provides /usr/bin too, and that ought to be
> > installed.
> > 
> 
> 
> 
> 
> That's a good point.  What does `rpm -V filesystem` show?
> 
> 
> 
> ___
> 
Nothing!# rpm -V filesystem
# 

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

Re: failure of f24 to f25 upgrade

2016-12-01 Thread stan

On Thu, 01 Dec 2016 11:32:33 -0800
Howard Howell  wrote:

> Hi, everyone,
>   I have been trying to upgrade my system from f24 to f25 using
> the cli in the terminal.
> 
>   814  dnf system-upgrade download --releasever=25
>   815  dnf system-upgrade download --releasever=25 --allowerasing
>   816  dnf system-upgrade download --releasever=25 --allowerasing --
> nogpgcheck
> 
>   all run from superuser.
> 
>   error: 
> Running transaction check
> Transaction check succeeded.
> Running transaction test
> The downloaded packages were saved in cache until the next successful
> transaction.
> You can remove cached packages by executing 'dnf clean packages'.
> Error: Transaction check error:
>   file /usr/bin from install of
> google-earth-stable-6.0.3.2197-0.x86_64 conflicts with file from
> package filesystem-3.2-37.fc24.x86_64 # dnf --system-upgrade reboot
> will not run due to same error.

This is a well known error in the spec file for the google earth file.
It tries to own /usr/bin, which it can't own, and so fails.

Here's a web reference to it.
http://forums.fedoraforum.org/showthread.php?t=302767
and here
https://ask.fedoraproject.org/en/question/85979/transaction-check-error-during-google-earth-install/

A long time ago I installed google earth, and used a work around on the
spec file.  I don't remember it now, but it worked with the rebuilt rpm
file.

The way to fix this so you can upgrade is by removing only google
earth using rpm directly, instead of through dnf.

rpm --erase --nodeps --test [google-earth-stable?]

This will test the command without doing anything.  When it does what
you want, remove the --test option.

After the upgrade, you can look for ways to re-install google earth.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: failure of f24 to f25 upgrade

On Thu, 2016-12-01 at 13:21 -0800, Josh Stone wrote:
> On 12/01/2016 12:40 PM, Howard Howell wrote:
> > 
> > -Original Message-
> > From: Josh Stone 
> > To: hlhow...@pacbell.net, Development discussions related to Fedora
> >  > v...@lists.fedoraproject.org>, Adam Williamson  > ct.o
> > rg>
> > Subject: Re: failure of f24 to f25 upgrade
> > Date: Thu, 1 Dec 2016 12:37:04 -0800
> > 
> > On 12/01/2016 12:26 PM, Howard Howell wrote:
> > > 
> > > 
> > > Now it gets really weird...
> > > # rpm -q --provides google-earth
> > > package google-earth is not installed
> > 
> > Should be google-earth-stable, no?
> > *
> > 
> > Different results:
> > rpm -q --provides google-earth-stable
> > google-earth = 7.1.7.2606
> > google-earth-stable = 7.1.7.2606-0
> > google-earth-stable(x86-64) = 7.1.7.2606-0
> 
> There's also something weird that this is 7.1...
> but your original mail quoted problems with 6.0.
> 
New stuff, however the commands are affecting the system, when I now go
to /opt/google/earth, the directory is now empty.

and google earth is no longer in the list of applications.

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

Re: failure of f24 to f25 upgrade

2016-12-01 Thread John Florian

On Thu, 2016-12-01 at 12:55 -0800, Adam Williamson wrote:

On Thu, 2016-12-01 at 12:35 -0800, Josh Stone wrote:



Perhaps dnf thinks google-earth is now the authority on %{_bindir} ?
So removing it is tearing the rug out from under all those others?



Well, I don't think so, as I'd expect that to rip out much *more*
stuff. I think it must be something a bit more odd than /usr/bin . The
'filesystem' package provides /usr/bin too, and that ought to be
installed.


That's a good point.  What does `rpm -V filesystem` show?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: failure of f24 to f25 upgrade

2016-12-01 Thread Josh Stone

On 12/01/2016 12:40 PM, Howard Howell wrote:
> -Original Message-
> From: Josh Stone 
> To: hlhow...@pacbell.net, Development discussions related to Fedora  v...@lists.fedoraproject.org>, Adam Williamson  rg>
> Subject: Re: failure of f24 to f25 upgrade
> Date: Thu, 1 Dec 2016 12:37:04 -0800
> 
> On 12/01/2016 12:26 PM, Howard Howell wrote:
>>
>> Now it gets really weird...
>> # rpm -q --provides google-earth
>> package google-earth is not installed
> 
> Should be google-earth-stable, no?
> *
> 
> Different results:
> rpm -q --provides google-earth-stable
> google-earth = 7.1.7.2606
> google-earth-stable = 7.1.7.2606-0
> google-earth-stable(x86-64) = 7.1.7.2606-0

There's also something weird that this is 7.1...
but your original mail quoted problems with 6.0.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F24 GStreamer zero day

2016-12-01 Thread Ahmad Samir

On 30 November 2016 at 23:19, Ahmad Samir  wrote:
> On 29 November 2016 at 16:24, Richard W.M. Jones  wrote:
>> On Wed, Nov 23, 2016 at 09:39:03AM +0100, Florian Weimer wrote:
>>> On 11/23/2016 02:15 AM, Sérgio Basto wrote:
>>> >On Ter, 2016-11-22 at 18:57 -0600, Michael Catanzaro wrote:
>>> >>Hi,
>>> >>
>>> >>Is anybody working on fixing [1]?
>>> >>
>>> >>The exploit is a little impractical in that it only works if you have
>>> >>not updated any F24 base packages except GStreamer, but we should
>>> >>still
>>> >>fix it. I don't see any GStreamer updates in bodhi yet.
>>> >
>>> >for gstreamer
>>> >https://bugzilla.redhat.com/show_bug.cgi?id=1395128
>>> >https://bugzilla.redhat.com/show_bug.cgi?id=1395768
>>> >https://bugzilla.redhat.com/show_bug.cgi?id=1397064
>>> >
>>> >for gstreamer1
>>> >https://bugzilla.redhat.com/show_bug.cgi?id=1397065
>>> >https://bugzilla.redhat.com/show_bug.cgi?id=1395769
>>> >
>>> >but no commits in scm yet
>>>
>>> What about the larger picture?  Can tracker be made optional again
>>> for the GNOME desktop?
>>
>> I have this in my .bashrc:
>>
>> # Kill with fire.
>> killall -9 -r tracker-.* >& /dev/null
>>
>> Seems to be the only way to permanently disable it that I have found
>> (I'm not using GNOME).
>>
>> Rich.
>
> On F25 (not sure about older releases), on can mask the tracker
> systemd user service(s):
> # cd /etc/systemd/user/
> # for i in $(rpm -ql tracker | grep systemd.*.service); do ln -s
> /dev/null $(basename $i); done
>
> the tracker processes won't get started the next time you log in.
>

This doesn't work if one uses startx to log in instead of logging in
via a graphical display manager; in that case this seems to work:
$ mkdir -p ~/.local/share/dbus-1/services
$ cd ~/.local/share/dbus-1/services
$ cp /usr/share/dbus-1/services/*Tracker* .
$ perl -p -i -e 's!Exec=.*!Exec=/bin/false!' *Tracker*

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

Re: failure of f24 to f25 upgrade

On Thu, 2016-12-01 at 21:54 +0100, Dominik 'Rathann' Mierzejewski
wrote:
> On Thursday, 01 December 2016 at 21:40, Howard Howell wrote:
> > 
> > -Original Message-
> > From: Josh Stone 
> > To: hlhow...@pacbell.net, Development discussions related to Fedora
> >  > v...@lists.fedoraproject.org>, Adam Williamson  > ct.o
> > rg>
> > Subject: Re: failure of f24 to f25 upgrade
> > Date: Thu, 1 Dec 2016 12:37:04 -0800
> > 
> > > 
> > > On 12/01/2016 12:26 PM, Howard Howell wrote:
> > > > 
> > > > 
> > > > Now it gets really weird...
> > > > # rpm -q --provides google-earth
> > > > package google-earth is not installed
> > > 
> > > Should be google-earth-stable, no?
> > > *
> > 
> > Different results:
> > rpm -q --provides google-earth-stable
> > google-earth = 7.1.7.2606
> > google-earth-stable = 7.1.7.2606-0
> > google-earth-stable(x86-64) = 7.1.7.2606-0
> > 
> > But not the one with the issue???
> 
> Yes, because dnf complains about issues with the updated
> google-earth-stable package, not the current one. 
> 
> Try `rpm -e google-earth-stable'.
> 
> Regards,
> Dominik
> 
> PS. Your quoting is bad (no indentation, so it misattributes quotes)
> and this is really not a topic for the developers list.
As you can see, I did change the quoting preferences.  I didn't notice
that it had changed.  I have vision issues, and touch issues, so
occasionally I change things I do not intend to. 
Thanks for bringing it to my attention.
Regards,
Les H
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: failure of f24 to f25 upgrade

-Original Message-
From: Dominik 'Rathann' Mierzejewski 
Reply-to: Development discussions related to Fedora

To: devel@lists.fedoraproject.org
Subject: Re: failure of f24 to f25 upgrade
Date: Thu, 1 Dec 2016 21:54:13 +0100

On Thursday, 01 December 2016 at 21:40, Howard Howell wrote:
> 
> -Original Message-
> From: Josh Stone 
> To: hlhow...@pacbell.net, Development discussions related to Fedora
>  v...@lists.fedoraproject.org>, Adam Williamson  .o
> rg>
> Subject: Re: failure of f24 to f25 upgrade
> Date: Thu, 1 Dec 2016 12:37:04 -0800
> 
> > 
> > On 12/01/2016 12:26 PM, Howard Howell wrote:
> > > 
> > > 
> > > Now it gets really weird...
> > > # rpm -q --provides google-earth
> > > package google-earth is not installed
> > 
> > Should be google-earth-stable, no?
> > *
> 
> Different results:
> rpm -q --provides google-earth-stable
> google-earth = 7.1.7.2606
> google-earth-stable = 7.1.7.2606-0
> google-earth-stable(x86-64) = 7.1.7.2606-0
> 
> But not the one with the issue???

Yes, because dnf complains about issues with the updated
google-earth-stable package, not the current one. 

Try `rpm -e google-earth-stable'.

Regards,
Dominik

PS. Your quoting is bad (no indentation, so it misattributes quotes)
and this is really not a topic for the developers list.

# rpm -e google-earth-stable
[root@school log]# 

Well, I tried the users list, no reply.  I did google, bugzilla, and
checked as many search terms as I could.  Upgrades via dnf are
relatively new, and since it was not on bugzilla, I thought before I
submitted one I should have sufficient supporting information on what
exactly is the bug.  A non conforming package is going to happen on the
cutting edge, so this is something that bears investigation by the
developers, I would think.

Also if investigation proves that I caused it then providing people
with information to avoid the issue would be good, wouldn't it?
 However installing a non supported package should not prevent an
upgrade, should it?

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

Re: failure of f24 to f25 upgrade

-Original Message-
From: Adam Williamson 
To: hlhow...@pacbell.net, Josh Stone , Development
discussions related to Fedora 
Subject: Re: failure of f24 to f25 upgrade
Date: Thu, 01 Dec 2016 12:54:44 -0800

On Thu, 2016-12-01 at 12:40 -0800, Howard Howell wrote:
> 
> -Original Message-
> From: Josh Stone 
> To: hlhow...@pacbell.net, Development discussions related to Fedora
>  v...@lists.fedoraproject.org>, Adam Williamson  .o
> rg>
> Subject: Re: failure of f24 to f25 upgrade
> Date: Thu, 1 Dec 2016 12:37:04 -0800
> 
> On 12/01/2016 12:26 PM, Howard Howell wrote:
> > 
> > 
> > Now it gets really weird...
> > # rpm -q --provides google-earth
> > package google-earth is not installed
> 
> Should be google-earth-stable, no?
> *
> 
> Different results:
> rpm -q --provides google-earth-stable
> google-earth = 7.1.7.2606
> google-earth-stable = 7.1.7.2606-0
> google-earth-stable(x86-64) = 7.1.7.2606-0
> 
> But not the one with the issue???

It's a file, I just wanted to see the package provides. Can we also
get:

rpm -ql google-earth-stable ?
***
# rpm -ql google-earth-stable
/etc/cron.daily
/etc/cron.daily/google-earth
/opt/google/earth/free
/opt/google/earth/free/ImporterGlobalSettings.ini
/opt/google/earth/free/ImporterUISettings.ini
/opt/google/earth/free/PCOptimizations.ini
/opt/google/earth/free/drivers.ini
/opt/google/earth/free/google-earth
/opt/google/earth/free/google-earth.desktop
/opt/google/earth/free/googleearth
/opt/google/earth/free/googleearth-bin
/opt/google/earth/free/gpl.txt
/opt/google/earth/free/gpsbabel
/opt/google/earth/free/kh20
/opt/google/earth/free/lang
/opt/google/earth/free/lang/ar.qm
/opt/google/earth/free/lang/bg.qm
/opt/google/earth/free/lang/ca.qm
/opt/google/earth/free/lang/cs.qm
/opt/google/earth/free/lang/da.qm
/opt/google/earth/free/lang/de.qm
/opt/google/earth/free/lang/el.qm
/opt/google/earth/free/lang/en.qm
/opt/google/earth/free/lang/es-419.qm
/opt/google/earth/free/lang/es.qm
/opt/google/earth/free/lang/fa.qm
/opt/google/earth/free/lang/fi.qm
/opt/google/earth/free/lang/fil.qm
/opt/google/earth/free/lang/fr.qm
/opt/google/earth/free/lang/he.qm
/opt/google/earth/free/lang/hi.qm
/opt/google/earth/free/lang/hr.qm
/opt/google/earth/free/lang/hu.qm
/opt/google/earth/free/lang/id.qm
/opt/google/earth/free/lang/it.qm
/opt/google/earth/free/lang/ja.qm
/opt/google/earth/free/lang/ko.qm
/opt/google/earth/free/lang/lt.qm
/opt/google/earth/free/lang/lv.qm
/opt/google/earth/free/lang/nl.qm
/opt/google/earth/free/lang/no.qm
/opt/google/earth/free/lang/pl.qm
/opt/google/earth/free/lang/pt-PT.qm
/opt/google/earth/free/lang/pt.qm
/opt/google/earth/free/lang/ro.qm
/opt/google/earth/free/lang/ru.qm
/opt/google/earth/free/lang/sk.qm
/opt/google/earth/free/lang/sl.qm
/opt/google/earth/free/lang/sr.qm
/opt/google/earth/free/lang/sv.qm
/opt/google/earth/free/lang/th.qm
/opt/google/earth/free/lang/tr.qm
/opt/google/earth/free/lang/uk.qm
/opt/google/earth/free/lang/vi.qm
/opt/google/earth/free/lang/zh-Hans.qm
/opt/google/earth/free/lang/zh-Hant-HK.qm
/opt/google/earth/free/lang/zh-Hant.qm
/opt/google/earth/free/libIGAttrs.so
/opt/google/earth/free/libIGCore.so
/opt/google/earth/free/libIGExportCommon.so
/opt/google/earth/free/libIGGfx.so
/opt/google/earth/free/libIGMath.so
/opt/google/earth/free/libIGOpt.so
/opt/google/earth/free/libIGSg.so
/opt/google/earth/free/libIGUtils.so
/opt/google/earth/free/libLeap.so
/opt/google/earth/free/libQtCore.so.4
/opt/google/earth/free/libQtGui.so.4
/opt/google/earth/free/libQtNetwork.so.4
/opt/google/earth/free/libQtWebKit.so.4
/opt/google/earth/free/libaction.so
/opt/google/earth/free/libalchemyext.so
/opt/google/earth/free/libapiloader.so
/opt/google/earth/free/libauth.so
/opt/google/earth/free/libbase.so
/opt/google/earth/free/libbasicingest.so
/opt/google/earth/free/libcollada.so
/opt/google/earth/free/libcommon.so
/opt/google/earth/free/libcommon_gui.so
/opt/google/earth/free/libcommon_platform.so
/opt/google/earth/free/libcommon_webbrowser.so
/opt/google/earth/free/libcomponentframework.so
/opt/google/earth/free/libevll.so
/opt/google/earth/free/libexpat.so.1
/opt/google/earth/free/libfilmstrip.so
/opt/google/earth/free/libflightsim.so
/opt/google/earth/free/libfreebl3.so
/opt/google/earth/free/libfusioncommon.so
/opt/google/earth/free/libgdal.so.1
/opt/google/earth/free/libgdata.so
/opt/google/earth/free/libge_cache.so
/opt/google/earth/free/libge_chrome_net.so
/opt/google/earth/free/libge_net.so
/opt/google/earth/free/libgeobase.so
/opt/google/earth/free/libgeobaseutils.so
/opt/google/earth/free/libglobalnew.so
/opt/google/earth/free/libgoogleapi.so
/opt/google/earth/free/libgoogleearth_free.so
/opt/google/earth/free/libgooglesearch.so
/opt/google/earth/free/libgps.so
/opt/google/earth/free/libicudata.so.50
/opt/google/earth/free/libicuuc.so.50

Re: failure of f24 to f25 upgrade

2016-12-01 Thread Rich Mattes

On Thu, Dec 1, 2016 at 3:55 PM, Adam Williamson
 wrote:
> On Thu, 2016-12-01 at 12:35 -0800, Josh Stone wrote:
>>
>> Perhaps dnf thinks google-earth is now the authority on %{_bindir} ?
>> So removing it is tearing the rug out from under all those others?
>
> Well, I don't think so, as I'd expect that to rip out much *more*
> stuff. I think it must be something a bit more odd than /usr/bin . The
> 'filesystem' package provides /usr/bin too, and that ought to be
> installed.


Perhaps it's a side effect of DNF's "clean_requirements_on_remove" feature[1]?

Rich

[1] http://dnf.readthedocs.io/en/latest/conf_ref.html#main-options
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: failure of f24 to f25 upgrade

On Thu, 2016-12-01 at 12:35 -0800, Josh Stone wrote:
> 
> Perhaps dnf thinks google-earth is now the authority on %{_bindir} ?
> So removing it is tearing the rug out from under all those others?

Well, I don't think so, as I'd expect that to rip out much *more*
stuff. I think it must be something a bit more odd than /usr/bin . The
'filesystem' package provides /usr/bin too, and that ought to be
installed.
-- 
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

Re: failure of f24 to f25 upgrade

On Thu, 2016-12-01 at 12:40 -0800, Howard Howell wrote:
> -Original Message-
> From: Josh Stone 
> To: hlhow...@pacbell.net, Development discussions related to Fedora  v...@lists.fedoraproject.org>, Adam Williamson  rg>
> Subject: Re: failure of f24 to f25 upgrade
> Date: Thu, 1 Dec 2016 12:37:04 -0800
> 
> On 12/01/2016 12:26 PM, Howard Howell wrote:
> > 
> > Now it gets really weird...
> > # rpm -q --provides google-earth
> > package google-earth is not installed
> 
> Should be google-earth-stable, no?
> *
> 
> Different results:
> rpm -q --provides google-earth-stable
> google-earth = 7.1.7.2606
> google-earth-stable = 7.1.7.2606-0
> google-earth-stable(x86-64) = 7.1.7.2606-0
> 
> But not the one with the issue???

It's a file, I just wanted to see the package provides. Can we also get:

rpm -ql google-earth-stable ?
-- 
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

Re: failure of f24 to f25 upgrade

2016-12-01 Thread Dominik 'Rathann' Mierzejewski

On Thursday, 01 December 2016 at 21:40, Howard Howell wrote:
> -Original Message-
> From: Josh Stone 
> To: hlhow...@pacbell.net, Development discussions related to Fedora  v...@lists.fedoraproject.org>, Adam Williamson  rg>
> Subject: Re: failure of f24 to f25 upgrade
> Date: Thu, 1 Dec 2016 12:37:04 -0800
> 
>> On 12/01/2016 12:26 PM, Howard Howell wrote:
>> > 
>> > Now it gets really weird...
>> > # rpm -q --provides google-earth
>> > package google-earth is not installed
>> 
>> Should be google-earth-stable, no?
>> *
> 
> Different results:
> rpm -q --provides google-earth-stable
> google-earth = 7.1.7.2606
> google-earth-stable = 7.1.7.2606-0
> google-earth-stable(x86-64) = 7.1.7.2606-0
> 
> But not the one with the issue???

Yes, because dnf complains about issues with the updated
google-earth-stable package, not the current one. 

Try `rpm -e google-earth-stable'.

Regards,
Dominik

PS. Your quoting is bad (no indentation, so it misattributes quotes)
and this is really not a topic for the developers list.
-- 
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: failure of f24 to f25 upgrade

-Original Message-
From: Josh Stone 
To: hlhow...@pacbell.net, Development discussions related to Fedora , Adam Williamson 
Subject: Re: failure of f24 to f25 upgrade
Date: Thu, 1 Dec 2016 12:37:04 -0800

On 12/01/2016 12:26 PM, Howard Howell wrote:
> 
> Now it gets really weird...
> # rpm -q --provides google-earth
> package google-earth is not installed

Should be google-earth-stable, no?
*

Different results:
rpm -q --provides google-earth-stable
google-earth = 7.1.7.2606
google-earth-stable = 7.1.7.2606-0
google-earth-stable(x86-64) = 7.1.7.2606-0

But not the one with the issue???
Regards,
Les H
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: failure of f24 to f25 upgrade

2016-12-01 Thread Josh Stone

On 12/01/2016 12:26 PM, Howard Howell wrote:
> Now it gets really weird...
> # rpm -q --provides google-earth
> package google-earth is not installed

Should be google-earth-stable, no?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: failure of f24 to f25 upgrade

2016-12-01 Thread Josh Stone

On 12/01/2016 12:22 PM, Adam Williamson wrote:
> On Thu, 2016-12-01 at 12:15 -0800, Howard Howell wrote:
>> -Original Message-
>> From: Adam Williamson 
>> To: hlhow...@pacbell.net, Development discussions related to Fedora > v...@lists.fedoraproject.org>
>> Subject: Re: failure of f24 to f25 upgrade
>> Date: Thu, 01 Dec 2016 12:11:29 -0800
>>
>> On Thu, 2016-12-01 at 12:05 -0800, Howard Howell wrote:
>>>
>>>
>>> Since the dnf erase command doesn't work, or tries to remove over
>>> 211M
>>> of files, do you mean just to remove the directory tree for the
>>> offending package using the rm command?
>>
>> Sorry, I missed that part. I use 'dnf remove', but I don't know if
>> there's any difference between that and 'dnf erase'. But when you say
>> '211M of files', that could just be Google Earth itself; it's a pretty
>> big app. What exactly is the output from 'dnf remove google-earth'?
>>
>> Dependencies resolved.
>> ===
>> =
>>  Package  Arch   VersionRepository 
>> Size
>> ===
>> =
>>
>> Transaction Summary
>> ===
>> =
>> Remove  61 Packages
> 
> Wow, yeah. There is something weird going on there. It looks a lot like
> the google-earth stuff is providing some kind of core stuff which
> should usually come from a Fedora package, so that package isn't
> installed. But I dunno how you got in that state in the *first* place.
> What does `rpm -q --provides google-earth` show?
> 

Perhaps dnf thinks google-earth is now the authority on %{_bindir} ?
So removing it is tearing the rug out from under all those others?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: failure of f24 to f25 upgrade

-Original Message-
From: Adam Williamson 
To: hlhow...@pacbell.net, Development discussions related to Fedora 
Subject: Re: failure of f24 to f25 upgrade
Date: Thu, 01 Dec 2016 12:22:31 -0800

On Thu, 2016-12-01 at 12:15 -0800, Howard Howell wrote:
> 
> -Original Message-
> From: Adam Williamson 
> To: hlhow...@pacbell.net, Development discussions related to Fedora
>  v...@lists.fedoraproject.org>
> Subject: Re: failure of f24 to f25 upgrade
> Date: Thu, 01 Dec 2016 12:11:29 -0800
> 
> On Thu, 2016-12-01 at 12:05 -0800, Howard Howell wrote:
> > 
> > 
> > 
> > Since the dnf erase command doesn't work, or tries to remove over
> > 211M
> > of files, do you mean just to remove the directory tree for the
> > offending package using the rm command?
> 
> Sorry, I missed that part. I use 'dnf remove', but I don't know if
> there's any difference between that and 'dnf erase'. But when you say
> '211M of files', that could just be Google Earth itself; it's a
> pretty
> big app. What exactly is the output from 'dnf remove google-earth'?
> 
> Dependencies resolved.
> =
> ==
> =
>  Package  Arch   VersionRepositor
> y 
> Size
> =
> ==
> =
> 
> Transaction Summary
> =
> ==
> =
> Remove  61 Packages

Wow, yeah. There is something weird going on there. It looks a lot like
the google-earth stuff is providing some kind of core stuff which
should usually come from a Fedora package, so that package isn't
installed. But I dunno how you got in that state in the *first* place.
What does `rpm -q --provides google-earth` show?

sorry for the second reply... but, google earth still works.  I don't
remember when exactly I installed it, or from where.  I was deep into a
bit of friends code he is using on robotics, which uses the google
earth api for its mapping.  I get one track minded when chasing
software, and that package is 4 or 5 languages, deep directory stuff,
lots of indirect and text parsing in the web interface, so my mind was
in a different space when it asked for google earth. I normally load
such things just using dnf install, but I seem to remember that I
couldn't find google earth with dns (probably typos or text inversion),
so I may have downloaded it from google.  Speed kills!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: failure of f24 to f25 upgrade

-Original Message-
From: Adam Williamson 
To: hlhow...@pacbell.net, Development discussions related to Fedora 
Subject: Re: failure of f24 to f25 upgrade
Date: Thu, 01 Dec 2016 12:22:31 -0800

On Thu, 2016-12-01 at 12:15 -0800, Howard Howell wrote:
> 
> -Original Message-
> From: Adam Williamson 
> To: hlhow...@pacbell.net, Development discussions related to Fedora
>  v...@lists.fedoraproject.org>
> Subject: Re: failure of f24 to f25 upgrade
> Date: Thu, 01 Dec 2016 12:11:29 -0800
> 
> On Thu, 2016-12-01 at 12:05 -0800, Howard Howell wrote:
> > 
> > 
> > 
> > Since the dnf erase command doesn't work, or tries to remove over
> > 211M
> > of files, do you mean just to remove the directory tree for the
> > offending package using the rm command?
> 
> Sorry, I missed that part. I use 'dnf remove', but I don't know if
> there's any difference between that and 'dnf erase'. But when you say
> '211M of files', that could just be Google Earth itself; it's a
> pretty
> big app. What exactly is the output from 'dnf remove google-earth'?
> 
> Dependencies resolved.
> =
> ==
> =
>  Package  Arch   VersionRepositor
> y 
> Size
> =
> ==
> =
> 
> Transaction Summary
> =
> ==
> =
> Remove  61 Packages

Wow, yeah. There is something weird going on there. It looks a lot like
the google-earth stuff is providing some kind of core stuff which
should usually come from a Fedora package, so that package isn't
installed. But I dunno how you got in that state in the *first* place.
What does `rpm -q --provides google-earth` show?

Now it gets really weird...
# rpm -q --provides google-earth
package google-earth is not installed
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: failure of f24 to f25 upgrade

On Thu, 2016-12-01 at 12:15 -0800, Howard Howell wrote:
> -Original Message-
> From: Adam Williamson 
> To: hlhow...@pacbell.net, Development discussions related to Fedora  v...@lists.fedoraproject.org>
> Subject: Re: failure of f24 to f25 upgrade
> Date: Thu, 01 Dec 2016 12:11:29 -0800
> 
> On Thu, 2016-12-01 at 12:05 -0800, Howard Howell wrote:
> > 
> > 
> > Since the dnf erase command doesn't work, or tries to remove over
> > 211M
> > of files, do you mean just to remove the directory tree for the
> > offending package using the rm command?
> 
> Sorry, I missed that part. I use 'dnf remove', but I don't know if
> there's any difference between that and 'dnf erase'. But when you say
> '211M of files', that could just be Google Earth itself; it's a pretty
> big app. What exactly is the output from 'dnf remove google-earth'?
> 
> Dependencies resolved.
> ===
> =
>  Package  Arch   VersionRepository 
> Size
> ===
> =
> 
> Transaction Summary
> ===
> =
> Remove  61 Packages

Wow, yeah. There is something weird going on there. It looks a lot like
the google-earth stuff is providing some kind of core stuff which
should usually come from a Fedora package, so that package isn't
installed. But I dunno how you got in that state in the *first* place.
What does `rpm -q --provides google-earth` show?
-- 
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

Re: failure of f24 to f25 upgrade

-Original Message-
From: Adam Williamson 
To: hlhow...@pacbell.net, Development discussions related to Fedora 
Subject: Re: failure of f24 to f25 upgrade
Date: Thu, 01 Dec 2016 12:11:29 -0800

On Thu, 2016-12-01 at 12:05 -0800, Howard Howell wrote:
> 
> 
> Since the dnf erase command doesn't work, or tries to remove over
> 211M
> of files, do you mean just to remove the directory tree for the
> offending package using the rm command?

Sorry, I missed that part. I use 'dnf remove', but I don't know if
there's any difference between that and 'dnf erase'. But when you say
'211M of files', that could just be Google Earth itself; it's a pretty
big app. What exactly is the output from 'dnf remove google-earth'?

Dependencies resolved.
===
=
 Package  Arch   VersionRepository 
Size
===
=
Removing:
 esmtpx86_64 1.2-
4.fc24 @updates   97 k
 google-earth-stable  x86_64 7.1.7.2606-
0   @@commandline 189 M
 liblockfile  x86_64 1.09-
4.fc24@fedora44 k
 libpng12 x86_64 1.2.56-
2.fc24  @fedora   442 k
 mailxx86_64 12.5-
19.fc24   @fedora   479 k
 ncurses-compat-libs  x86_64 6.0-
6.20160709.fc24@updates  946 k
 patchx86_64 2.7.5-
3.fc24   @fedora   231 k
 perl-Algorithm-Diff  noarch 1.1903-
4.fc24  @fedora   108 k
 perl-Archive-Tar noarch 2.06-
2.fc24@updates  149 k
 perl-Archive-Zip noarch 1.58-
1.fc24@updates  252 k
 perl-B-Lint  noarch 1.20-
6.fc24@fedora30 k
 perl-CGI noarch 4.28-
2.fc24@fedora   533 k
 perl-CPANnoarch 2.11-
349.fc24  @fedora   1.7 M
 perl-Class-ISA   noarch 0.36-
1017.fc24 @fedora13 k
 perl-Compress-Bzip2  x86_64 2.25-
1.fc24@updates  142 k
 perl-Data-Sectionnoarch 0.26-
6.fc24@fedora40 k
 perl-Devel-Size  x86_64 0.80-
4.fc24@fedora78 k
 perl-Env noarch 1.04-
347.fc24  @fedora26 k
 perl-ExtUtils-CBuilder   noarch 1:0.280224-
2.fc24  @fedora96 k
 perl-ExtUtils-MM-Utils   noarch 7.10-
5.fc24@updates  3.1 k
 perl-File-CheckTree  noarch 4.42-
296.fc24  @fedora28 k
 perl-IO-Zlib noarch 1:1.10-
364.fc24@updates   19 k
 perl-IPC-Cmd noarch 1:0.96-
1.fc24  @updates   83 k
 perl-IPC-System-Simple   noarch 1.25-
8.fc24@fedora69 k
 perl-Locale-Codesnoarch 3.40-
1.fc24@updates  2.2 M
 perl-Locale-Maketext noarch 1.26-
349.fc24  @updates  166 k
 perl-Locale-Maketext-Simple  noarch 1:0.21-
364.fc24@updates   14 k
 perl-MRO-Compat  noarch 0.12-
10.fc24   @fedora26 k
 perl-Module-Buildnoarch 2:0.42.18-
1.fc24   @fedora   654 k
 perl-Module-CoreList noarch 1:5.20161020-
1.fc24@updates  719 k
 perl-Module-Load-Conditional noarch 0.68-
1.fc24@updates   29 k
 perl-Module-Metadata noarch 1.27-
4.fc24@fedora61 k
 perl-Net-Pingnoarch 2.43-
364.fc24  @updates   67 k
 perl-Params-Checknoarch 1:0.38-
347.fc24@fedora28 k
 perl-Perl-OSType noarch 1.009-
2.fc24   @fedora33 k
 perl-Pod-Checker noarch 4:1.71-
6.fc24  @fedora45 k
 perl-Pod-Htmlnoarch 1.22-
364.fc24  @updates   36 k
 perl-Pod-LaTeX   noarch 0.61-
297.fc24  @fedora84 k
 perl-Pod-Parser  noarch 1.63-
348.fc24  @fedora   263 k
 perl-Pod-Plainer noarch 1.04-
2.fc24@fedora   5.1 k
 perl-Software-Licensenoarch 0.103012-
1.fc24@fedora   417 k
 perl-Sys-Syslog  x86_64 0.35-
1.fc24@updates   95 k
 perl-Test-Simple noarch 1.001014-
347.fc24  @fedora   448 k
 perl-Text-Diff   noarch 1.44-
1.fc24@fedora83 k
 perl-Text-Glob   noarch 0.09-
15.fc24   @fedora   7.8 k
 perl-Text-Soundexx86_64 3.05-
2.fc24@fedora47 k
 perl-Text-Template   noarch 1.46-
4.fc24@fedora   122 k
 perl-autodie noarch 2.29-
2.fc24@fedora   211 k
 perl-inc-latest  noarch 2:0.500-
4.fc24 @fedora35 k

Re: failure of f24 to f25 upgrade

On Thu, 2016-12-01 at 12:05 -0800, Howard Howell wrote:
> 
> Since the dnf erase command doesn't work, or tries to remove over 211M
> of files, do you mean just to remove the directory tree for the
> offending package using the rm command?

Sorry, I missed that part. I use 'dnf remove', but I don't know if
there's any difference between that and 'dnf erase'. But when you say
'211M of files', that could just be Google Earth itself; it's a pretty
big app. What exactly is the output from 'dnf remove google-earth'?
-- 
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

Re: failure of f24 to f25 upgrade

-Original Message-
From: Adam Williamson 
To: hlhow...@pacbell.net, Development discussions related to Fedora 
Subject: Re: failure of f24 to f25 upgrade
Date: Thu, 01 Dec 2016 11:41:23 -0800

On Thu, 2016-12-01 at 11:32 -0800, Howard Howell wrote:
> 
> Hi, everyone,
>   I have been trying to upgrade my system from f24 to f25 using
> the cli in the terminal.
> 
>   814  dnf system-upgrade download --releasever=25
>   815  dnf system-upgrade download --releasever=25 --allowerasing
>   816  dnf system-upgrade download --releasever=25 --allowerasing --
> nogpgcheck
> 
>   all run from superuser.
> 
>   error: 
> Running transaction check
> Transaction check succeeded.
> Running transaction test
> The downloaded packages were saved in cache until the next successful
> transaction.
> You can remove cached packages by executing 'dnf clean packages'.
> Error: Transaction check error:
>   file /usr/bin from install of google-earth-stable-6.0.3.2197-
> 0.x86_64 
> conflicts with file from package filesystem-3.2-37.fc24.x86_64
>   # dnf --system-upgrade reboot
> will not run due to same error.
> 
> I have obtained the google key and installed it using pgp install,
> but
> no change.  Here are some of the other things I have tried:
>     dnf distrosync
>     dnf help
>     dnf upgrade google_Earth
>     dnf upgrade google-earth
>     dnf system-upgrade --nogpgcheck reboot
>     dnf erase googleearth
> 
> The erase google earth I have tried also with the full name
>     dnf erase google-earth-stable-6.0.3.2197-0.x86_64
>     No match for argument: google-earth-stable-6.0.3.2197-0.x86_64
>     Error: No packages marked for removal.
> 
> Given that I cannot erase the offending package, I tried:
>     dnf system-upgrade reboot --allowerasing
>     Error: system is not ready for upgrade
> 
> Yet again with nogpgcheck
>   dnf system-upgrade reboot --nogpgcheck
>   Error: system is not ready for upgrade
> 
> A straight reboot will bring the system back to f24.  But no upgrade.
> 
> A bugzilla check was no less frustrating with no help for the issue.
> 
> Any ideas out there?

Well, that Google Earth package is clearly bad. There's no reason it
should own /usr/bin . It looks like the problem is that it sets a
different mode on it than the `filesystem` package does, which dnf/rpm
will see as a conflict: two packages can contain the same file or
directory without conflict only so long as the file or directory is
identical and has identical properties in both. If they diverge at all,
it becomes a package conflict.

The obvious thing you can do for now is simply remove the google-earth
package; after that the upgrade should work fine. You can then look at
ways to reinstall Google Earth on the upgraded system.

Since the dnf erase command doesn't work, or tries to remove over 211M
of files, do you mean just to remove the directory tree for the
offending package using the rm command?

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

Re: failure of f24 to f25 upgrade

On Thu, 2016-12-01 at 11:32 -0800, Howard Howell wrote:
> Hi, everyone,
>   I have been trying to upgrade my system from f24 to f25 using
> the cli in the terminal.
> 
>   814  dnf system-upgrade download --releasever=25
>   815  dnf system-upgrade download --releasever=25 --allowerasing
>   816  dnf system-upgrade download --releasever=25 --allowerasing --
> nogpgcheck
> 
>   all run from superuser.
> 
>   error: 
> Running transaction check
> Transaction check succeeded.
> Running transaction test
> The downloaded packages were saved in cache until the next successful
> transaction.
> You can remove cached packages by executing 'dnf clean packages'.
> Error: Transaction check error:
>   file /usr/bin from install of google-earth-stable-6.0.3.2197-0.x86_64 
> conflicts with file from package filesystem-3.2-37.fc24.x86_64
>   # dnf --system-upgrade reboot
> will not run due to same error.
> 
> I have obtained the google key and installed it using pgp install, but
> no change.  Here are some of the other things I have tried:
>     dnf distrosync
>     dnf help
>     dnf upgrade google_Earth
>     dnf upgrade google-earth
>     dnf system-upgrade --nogpgcheck reboot
>     dnf erase googleearth
> 
> The erase google earth I have tried also with the full name
>     dnf erase google-earth-stable-6.0.3.2197-0.x86_64
>     No match for argument: google-earth-stable-6.0.3.2197-0.x86_64
>     Error: No packages marked for removal.
> 
> Given that I cannot erase the offending package, I tried:
>     dnf system-upgrade reboot --allowerasing
>     Error: system is not ready for upgrade
> 
> Yet again with nogpgcheck
>   dnf system-upgrade reboot --nogpgcheck
>   Error: system is not ready for upgrade
> 
> A straight reboot will bring the system back to f24.  But no upgrade.
> 
> A bugzilla check was no less frustrating with no help for the issue.
> 
> Any ideas out there?

Well, that Google Earth package is clearly bad. There's no reason it
should own /usr/bin . It looks like the problem is that it sets a
different mode on it than the `filesystem` package does, which dnf/rpm
will see as a conflict: two packages can contain the same file or
directory without conflict only so long as the file or directory is
identical and has identical properties in both. If they diverge at all,
it becomes a package conflict.

The obvious thing you can do for now is simply remove the google-earth
package; after that the upgrade should work fine. You can then look at
ways to reinstall Google Earth on the upgraded system.
-- 
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

ppisar uploaded Clownfish-CFC-0.6.0.5.tar.gz for perl-Clownfish-CFC

bbce2160894b0f29b79f351e29452f02  Clownfish-CFC-0.6.0.5.tar.gz

http://pkgs.fedoraproject.org/lookaside/pkgs/perl-Clownfish-CFC/Clownfish-CFC-0.6.0.5.tar.gz/md5/bbce2160894b0f29b79f351e29452f02/Clownfish-CFC-0.6.0.5.tar.gz
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

ppisar pushed to perl-Clownfish-CFC (master). "0.6.0.5 bump"

From 70c6407e1bba55df1fb0e0f361348fc2607ad195 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= 
Date: Thu, 1 Dec 2016 18:01:06 +0100
Subject: 0.6.0.5 bump

---
 .gitignore  | 1 +
 perl-Clownfish-CFC.spec | 5 -
 sources | 2 +-
 3 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/.gitignore b/.gitignore
index dd80030..2ddbcfd 100644
--- a/.gitignore
+++ b/.gitignore
@@ -5,3 +5,4 @@
 /Clownfish-CFC-0.5.1.tar.gz
 /Clownfish-CFC-0.6.0.tar.gz
 /Clownfish-CFC-0.6.0.4.tar.gz
+/Clownfish-CFC-0.6.0.5.tar.gz
diff --git a/perl-Clownfish-CFC.spec b/perl-Clownfish-CFC.spec
index af4a6c9..78efb2c 100644
--- a/perl-Clownfish-CFC.spec
+++ b/perl-Clownfish-CFC.spec
@@ -1,5 +1,5 @@
 Name:   perl-Clownfish-CFC
-Version:0.6.0.4
+Version:0.6.0.5
 Release:1%{?dist}
 Summary:Compiler for Apache Clownfish
 # other files:  ASL 2.0
@@ -107,6 +107,9 @@ find $RPM_BUILD_ROOT -type f -name '*.bs' -size 0 -delete
 %{_mandir}/man3/*
 
 %changelog
+* Thu Dec 01 2016 Petr Pisar  - 0.6.0.5-1
+- 0.6.0.5 bump
+
 * Mon Oct 10 2016 Petr Pisar  - 0.6.0.4-1
 - 0.6.0.4 bump
 
diff --git a/sources b/sources
index f2d32c2..ebf7ba7 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-4bc443558fc3a62d6c47b7ea0ea531af  Clownfish-CFC-0.6.0.4.tar.gz
+bbce2160894b0f29b79f351e29452f02  Clownfish-CFC-0.6.0.5.tar.gz
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl-Clownfish-CFC.git/commit/?h=master=70c6407e1bba55df1fb0e0f361348fc2607ad195
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

failure of f24 to f25 upgrade

Hi, everyone,
I have been trying to upgrade my system from f24 to f25 using
the cli in the terminal.

  814  dnf system-upgrade download --releasever=25
  815  dnf system-upgrade download --releasever=25 --allowerasing
  816  dnf system-upgrade download --releasever=25 --allowerasing --
nogpgcheck

  all run from superuser.

  error: 
Running transaction check
Transaction check succeeded.
Running transaction test
The downloaded packages were saved in cache until the next successful
transaction.
You can remove cached packages by executing 'dnf clean packages'.
Error: Transaction check error:
  file /usr/bin from install of google-earth-stable-6.0.3.2197-0.x86_64 
conflicts with file from package filesystem-3.2-37.fc24.x86_64
  # dnf --system-upgrade reboot
will not run due to same error.

I have obtained the google key and installed it using pgp install, but
no change.  Here are some of the other things I have tried:
    dnf distrosync
    dnf help
    dnf upgrade google_Earth
    dnf upgrade google-earth
    dnf system-upgrade --nogpgcheck reboot
    dnf erase googleearth

The erase google earth I have tried also with the full name
    dnf erase google-earth-stable-6.0.3.2197-0.x86_64
    No match for argument: google-earth-stable-6.0.3.2197-0.x86_64
    Error: No packages marked for removal.

Given that I cannot erase the offending package, I tried:
    dnf system-upgrade reboot --allowerasing
    Error: system is not ready for upgrade

Yet again with nogpgcheck
dnf system-upgrade reboot --nogpgcheck
Error: system is not ready for upgrade

A straight reboot will bring the system back to f24.  But no upgrade.

A bugzilla check was no less frustrating with no help for the issue.

Any ideas out there?

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

[Bug 1400119] perl-Config-IniFiles-2.94 is available

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

Tom "spot" Callaway  changed:

   What|Removed |Added

 Status|NEW |CLOSED
 Resolution|--- |RAWHIDE
Last Closed||2016-12-01 13:58:18



-- 
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 1400119] perl-Config-IniFiles-2.94 is available

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



--- Comment #4 from Upstream Release Monitoring 
 ---
spot's perl-Config-IniFiles-2.94-1.fc26 completed
http://koji.fedoraproject.org/koji/buildinfo?buildID=821806

-- 
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 1396854] perl-CPAN-Perl-Releases-3.00 is available

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-CPAN-Perl-Releases-3.0 |perl-CPAN-Perl-Releases-3.0
   |0-1.fc26|0-1.fc26
   |perl-CPAN-Perl-Releases-3.0 |perl-CPAN-Perl-Releases-3.0
   |0-1.fc25|0-1.fc25
   ||perl-CPAN-Perl-Releases-3.0
   ||0-1.fc24



--- Comment #6 from Fedora Update System  ---
perl-CPAN-Perl-Releases-3.00-1.fc24 has been pushed to the Fedora 24 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

[Bug 1397379] perl-Test-PostgreSQL-1.21 is available

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Test-PostgreSQL-1.21-1 |perl-Test-PostgreSQL-1.21-1
   |.fc26   |.fc26
   |perl-Test-PostgreSQL-1.21-1 |perl-Test-PostgreSQL-1.21-1
   |.fc25   |.fc25
   ||perl-Test-PostgreSQL-1.21-1
   ||.fc24



--- Comment #10 from Fedora Update System  ---
perl-Test-PostgreSQL-1.21-1.fc24 has been pushed to the Fedora 24 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

[Bug 1396684] perl-Locale-Codes-3.41 is available

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Locale-Codes-3.41-1.fc |perl-Locale-Codes-3.41-1.fc
   |26  |26
   |perl-Locale-Codes-3.41-1.fc |perl-Locale-Codes-3.41-1.fc
   |25  |25
   ||perl-Locale-Codes-3.41-1.fc
   ||24



--- Comment #7 from Fedora Update System  ---
perl-Locale-Codes-3.41-1.fc24 has been pushed to the Fedora 24 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

[Bug 1396860] perl-Module-CoreList-5.20161120 is available

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Module-CoreList-5.2016 |perl-Module-CoreList-5.2016
   |1120-1.fc26 |1120-1.fc26
   |perl-Module-CoreList-5.2016 |perl-Module-CoreList-5.2016
   |1120-1.fc25 |1120-1.fc25
   ||perl-Module-CoreList-5.2016
   ||1120-1.fc24



--- Comment #9 from Fedora Update System  ---
perl-Module-CoreList-5.20161120-1.fc24 has been pushed to the Fedora 24 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

f25+: vala 0.34.x+ bug causing .vapi file generation for ALL CURRENT PACKAGE BUILDS to be possibly faulty

2016-12-01 Thread Fabio Valentini

I has come to my attention that - since the update to vala from the
0.34.x series has made it into the fedora 25(+) repositories - every
package that generates .vapi files during build might have done so
incorrectly, because of the following bug, which is present in vala
releases up to 0.34.3 (also including 0.35.1), but has been fixed in
git:

Functions that have a return type of a fixed-size array were not
treated correctly - they instead are wrongly indicated to return the
base type of the respective array (the array qualifier "[]" is
missing).

I reported this bug at
https://bugzilla.redhat.com/show_bug.cgi?id=1398738 a week ago, but it
has not received any attention so far. I have notified Rico
Tzschichholz directly and he has fixed this bug in the meantime (0.34
branch: 
https://git.gnome.org/browse/vala/commit/?h=0.34=7e76f75e42e7ac45c896e81e97955c8b2089d7e9
and in master), but it is not yet part of a stable vala release.

As far as I can tell, every affected package that has been rebuilt
since the faulty vala releases have made it into the f25 / f25 repos
might contain errors because of this bug, and every affected package
that is rebuilt now might introduce a new faulty package into fedora
repositories.

I don't know how frequent fixed-size-array return types are in
functions overall, but at least one package in the stable fedora
repositories has been affected by this bug:
NetworkManager(-glib-devel), where libnm-util.vapi contains (at least
one) such error - which results in build failures for packages using
the affected APIs.

Once a fix for the bug is available in fedora (I guess a patch to the
latest vala release containing the fix linked above, since - so far -
no new release has been tagged upstream), packages that generate .vapi
files will have to be rebuilt to pick up the fix and to correct any
errors that crept in while a faulty vala version was in the
repositories.

I find it somehow curious that nobody else has picked this error up
before, but it might still take some time to affect more package
builds since this is a one-removed problem ...

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

[Bug 1400359] perl-Clownfish-CFC-0.6.0.5 is available

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
   Fixed In Version||perl-Clownfish-CFC-0.6.0.5-
   ||1.fc26
 Resolution|--- |RAWHIDE
Last Closed||2016-12-01 12:16:13



--- Comment #1 from Petr Pisar  ---
A bug-fix release suitable for Fedora ≥ 26.

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

Re: Release validation NG: planning thoughts

On Thu, 2016-12-01 at 14:25 +0100, Josef Skladanka wrote:
> On Wed, Nov 30, 2016 at 6:29 PM, Adam Williamson  > wrote:
> > On Wed, 2016-11-30 at 18:20 +0100, Josef Skladanka wrote:
> > > I would try not to go the third way, because that is really prone to
> > 
> > erros
> > > IMO, and I'm not sure that "per context" is always right. So for me, the
> > > "TCMS" part of the data, should be:
> > > 1) testcases (with required fields/types of the fields in the "result
> > > response"
> > > 2) testplans - which testcases, possibly organized into groups. Maybe
> > 
> > even
> > > dependencies + saying "I need testcase X to pass, Y can be pass or warn,
> > 
> > Z
> > > can be whatever when A passes, for the testplan to pass"
> > > 
> > > But this is fairly complex thing, to be honest, and it would be the first
> > > and only useable TCMS in the world (from my point of view).
> > 
> > I have rather different opinions, actually...but I'm not working on
> > this right now and I'd rather have something concrete to discuss than
> > just opinions :)
> > 
> > We should obviously set goals properly, before diving into implementation
> 
> details :) I'm interested in what you have in mind, since I've been
> thinking about this particular kind of thing for the last few years, and it
> really depends on what you expect of the system.

Well, the biggest point where I differ is that I think your 'third way'
is kind of unavoidable. For all kinds of reasons.

We re-use test cases between package update testing, Test Days, and
release validation testing, for instance; some tests are more or less
unique to some specific process, but certainly not all of them. The
desired test environments may be significantly different in these
different cases.

We also have secondary arch teams using release validation processes
similar to the primary arch process: they use many of the same test
cases, but the desired test environments are of course not the same.

Of course, in a non-wiki based system you could plausibly argue that a
test case could be stored along with *all* of its possible
environments, and then the configuration for a specific test event
could include the information as to which environments are relevant
and/or required for that test event. But at that point I think you're
rather splitting hairs...

In my original vision of 'relval NG' the test environment wouldn't
actually exist at all, BTW. I was hoping we could simply list test
cases, and the user could choose the image they were testing, and the
image would serve as the 'test environment'. But on second thought
that's unsustainable as there are things like BIOS vs. UEFI where we
may want to run the same test on the same image and consider it a
different result. The only way we could stick to my original vision
there would be to present 'same test, different environment' as another
row in the UI, kinda like we do for 'two-dimensional test tables' in
Wikitcms; it's not actually horrible UI, but I don't think we'd want to
pretend in the backend that these were two completely different. I
mean, we could. Ultimately a 'test case' is going to be a database row
with a URL and a numeric ID. We don't *have* to say the URL key is
unique. ;)

There are really all kinds of ways you can structure it, but I think
fundamentally they'd all boil down to the same inherent level of
complexity; some of them might be demonstrably worse than others
(like...sticking them all in wikicode and parsing wiki table syntax to
figure out when you have different 'test instances' for the same test
case! that sounds like a *really bad* way to do it!)

Er. I'm rambling, aren't I? One reason I actually tend to prefer just
sitting down and writing something to trying to plan it all out
comprehensively is that when I just sit here and try to think out
planning questions I get very long-winded and fuzzy and chase off down
all possible paths. Just writing a damn thing is usually quite quick
and crystallizes a lot of the questions wonderfully...
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
qa-devel mailing list -- qa-devel@lists.fedoraproject.org
To unsubscribe send an email to qa-devel-le...@lists.fedoraproject.org

Re: clarification of package naming guidelines

2016-12-01 Thread Gerald B. Cox

On Thu, Dec 1, 2016 at 8:39 AM, Mattia Verga 
wrote:

>
> So, in my opinion, you did it right naming your package "superlu_dist".
> For sure, you MUST not use uppercase letters.

I believe there is a bit of leeway for the packager here.  You SHOULD not
use uppercase; it isn't an edict - it's a guideline.  That said,
I agree that lowercase is far preferable.  We all know what a PITA it is to
try to figure out package names in the repository.  That is why
the guidelines state you SHOULD use lowercase and hyphens instead of
underscores.  Turning the attention to the underscore, I would in this
instance change it to a hyphen:  so the package would be named
"superlu-dist".  Why, because that is what most people are going to use and
what how the vast majority of packages are named.

Bottom line, it's your decision as the packager (within the parameters
stated in the guideline - which mean if you really wanted you could just
keep the name SuperLU_DIST - but there are reasons explained in the
packaging guidelines why that isn't a good idea.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: clarification of package naming guidelines

2016-12-01 Thread Mattia Verga


Il 01/12/2016 13:35, Dave Love ha scritto:

Could someone clarify the rules on package naming
?

Background:  I've packaged something its author calls SuperLU_DIST using
the rpm name superlu_dist.  I interpreted that as consistent with those
guidelines as well as allowing it to be searched for, and without the
inconvenience of mixed case.  Others opinions are that it should be
changed to superlu-dist or SuperLUDIST, which would mean you couldn't
search the repository for the proper name of the software, like the
existing SuperLUMT v. SuperLU_MT.  (I think that case-insensitive search
is appropriate, but again others don't.)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

From the Packaging Naming Guidelines:
" General Naming
Package names should be in lower case and use dashes in preference to 
underscores"


In the next chapter is said:
" Separators
When naming packages for Fedora, the maintainer must use the dash '-' as 
the delimiter for name parts. The maintainer must NOT use an underscore 
'_', a plus '+', or a period '.' as a delimiter.

...
There are a few exceptions to the no underscore '_' rule.
...
packages where the upstream name naturally contains an underscore are 
excluded from this."


So, in my opinion, you did it right naming your package "superlu_dist". 
For sure, you MUST not use uppercase letters.


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

Re: Bodhi problems?

2016-12-01 Thread Kevin Fenzi

On Thu, 1 Dec 2016 10:49:28 +0100
Juan Orti Alcaine  wrote:

> I can't push to stable a couple of updates. Is there any known problem
> with Bodhi?
> 
> https://bodhi.fedoraproject.org/updates/FEDORA-2016-fa485c1c95
> https://bodhi.fedoraproject.org/updates/FEDORA-2016-eae6ba26e4

There were some problems eariler this morning. 

Everything should be back to normal now however. 

kevin


pgp4Cq9tOA2_n.pgp
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F25 GNOME Shell notification locked up hard for some time

2016-12-01 Thread Michael Schwendt

On Wed, 30 Nov 2016 00:52:10 +0100, Michael Schwendt wrote:

> So, I will reinstall first, and if it's still reproducible afterwards,
> I will be available for some time to answer questions in a bug report.

In a fresh install F25 I cannot experience the same issue so far.
I had come from a very late beta and updated to F25 stable updates.
There have been a few orphan package updates during that time, however,
which have been deleted in bodhi, so I could not find out anything about
them other than replacing them with distro-sync.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: static linking a library

2016-12-01 Thread Neal Gompa

On Thu, Dec 1, 2016 at 10:44 AM, Neal Becker  wrote:
> Mercurial upstream is asking about a compression library zstd.
>
> Specifically:
> https://www.mercurial-scm.org/pipermail/mercurial-packaging/2016-November/000178.html
>
> I believe the proposed solution here:
> https://www.mercurial-scm.org/pipermail/mercurial-packaging/2016-December/000182.html
>
> which is to statically link the library to the mercurial executable would
> also raise issues?  A special exception to the statically linked binary
> would be required?

Per our guidelines[1], just add a bundled(zstd) Provides that
indicates what version of the library is vendored in. And as soon as
reasonably possible, unbundle it.

That's all you need to do. I would also suggest leaving a comment in
the spec above the bundled() Provides to the discussion so that the
rationale is known and documented.

[1]: 
https://fedoraproject.org/wiki/Bundled_Libraries#Treatment_of_Bundled_Libraries


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

[Bug 1398750] The biber and texlive-biblatex versions in F25 are incompatible.

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version||biber-2.6-1.fc25
 Resolution|--- |ERRATA
Last Closed||2016-12-01 10:56:48



--- Comment #7 from Fedora Update System  ---
biber-2.6-1.fc25 has been pushed to the Fedora 25 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

[Bug 1397128] Upgrade perl-Config-Model to 2.094

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-Config-Model-2.094-1.f |perl-Config-Model-2.094-1.f
   |c26 |c26
   ||perl-Config-Model-2.094-1.f
   ||c25
 Resolution|--- |ERRATA
Last Closed||2016-12-01 10:56:21



--- Comment #3 from Fedora Update System  ---
perl-Config-Model-2.094-1.fc25 has been pushed to the Fedora 25 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

[Bug 1397379] perl-Test-PostgreSQL-1.21 is available

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-Test-PostgreSQL-1.21-1 |perl-Test-PostgreSQL-1.21-1
   |.fc26   |.fc26
   ||perl-Test-PostgreSQL-1.21-1
   ||.fc25
 Resolution|--- |ERRATA
Last Closed||2016-12-01 10:56:15



--- Comment #9 from Fedora Update System  ---
perl-Test-PostgreSQL-1.21-1.fc25 has been pushed to the Fedora 25 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

[Bug 1396684] perl-Locale-Codes-3.41 is available

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-Locale-Codes-3.41-1.fc |perl-Locale-Codes-3.41-1.fc
   |26  |26
   ||perl-Locale-Codes-3.41-1.fc
   ||25
 Resolution|--- |ERRATA
Last Closed||2016-12-01 10:56:02



--- Comment #6 from Fedora Update System  ---
perl-Locale-Codes-3.41-1.fc25 has been pushed to the Fedora 25 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

[Bug 1394475] perlbrew-0.77 is available

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perlbrew-0.77-1.fc26|perlbrew-0.77-1.fc26
   ||perlbrew-0.78-1.fc25
 Resolution|--- |ERRATA
Last Closed||2016-12-01 10:55:58



--- Comment #5 from Fedora Update System  ---
perlbrew-0.78-1.fc25 has been pushed to the Fedora 25 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

[Bug 1396854] perl-CPAN-Perl-Releases-3.00 is available

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-CPAN-Perl-Releases-3.0 |perl-CPAN-Perl-Releases-3.0
   |0-1.fc26|0-1.fc26
   ||perl-CPAN-Perl-Releases-3.0
   ||0-1.fc25
 Resolution|--- |ERRATA
Last Closed||2016-12-01 10:56:05



--- Comment #5 from Fedora Update System  ---
perl-CPAN-Perl-Releases-3.00-1.fc25 has been pushed to the Fedora 25 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

[Bug 1396853] perlbrew-0.78 is available

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perlbrew-0.78-1.fc26|perlbrew-0.78-1.fc26
   ||perlbrew-0.78-1.fc25
 Resolution|--- |ERRATA
Last Closed||2016-12-01 10:55:54



--- Comment #3 from Fedora Update System  ---
perlbrew-0.78-1.fc25 has been pushed to the Fedora 25 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

static linking a library

2016-12-01 Thread Neal Becker

Mercurial upstream is asking about a compression library zstd.

Specifically:
https://www.mercurial-scm.org/pipermail/mercurial-packaging/2016-November/000178.html

I believe the proposed solution here:
https://www.mercurial-scm.org/pipermail/mercurial-packaging/2016-December/000182.html

which is to statically link the library to the mercurial executable would 
also raise issues?  A special exception to the statically linked binary 
would be required?

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

[Bug 1395138] stompclt-1.5 is available

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|stompclt-1.5-1.fc25 |stompclt-1.5-1.fc25
   |stompclt-1.5-1.el6  |stompclt-1.5-1.el6
   ||stompclt-1.5-1.el7



--- Comment #11 from Fedora Update System  ---
stompclt-1.5-1.el7 has been pushed to the Fedora EPEL 7 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

[Bug 1395138] stompclt-1.5 is available

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|stompclt-1.5-1.fc25 |stompclt-1.5-1.fc25
   ||stompclt-1.5-1.el6



--- Comment #10 from Fedora Update System  ---
stompclt-1.5-1.el6 has been pushed to the Fedora EPEL 6 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

Re: [RFC] RPM's Python dependency generator

2016-12-01 Thread Petr Viktorin

On 12/01/2016 02:42 PM, Neal Gompa wrote:

On Thu, Dec 1, 2016 at 8:36 AM, Igor Gnatenko wrote:

On Wed, Nov 30, 2016 at 2:53 PM, Tomas Orsava wrote:

On 11/30/2016 02:44 PM, Neal Gompa wrote:

On Wed, Nov 30, 2016 at 8:41 AM, Tomas Orsava wrote:

I don't think the depgen should be enabled by default, at least not in
the
foreseeable future. IIRC it's not that well implemented—e.g. I believe it
doesn't read requirements.txt for example (but I might be wrong).
There will be a lot of cases where the generated requirements are
incomplete, or contain unnecessary entries, etc. I think it should remain
an
opt-in.

According to various Python people, we're not actually supposed to
read requirements.txt. That file is explicitly designed for people to
individualized deployments. The proper place to get this information
is from the egg-info/dist-info data, which is what we read. The fact
that some people abuse requirements.txt and have it read in by their
setup.py is beside the point. Whatever the setup.py (thus
pip/easy_install/etc.) says it needs, the generator will dutifully
report.

The fact remains in too many cases it will need to be manually adjusted, it
won't be foolproof.
Therefore I argue it would be better for it to be an opt-in so that new
packagers don't immediately have to jump in into debugging a depgen they
have no clue how really works.

We'll see how it will go. we have depgen for pkgconfig, libraries,
etc. for many years and people don't go and debug it immediately, but
for many of packages it will help a lot. Anyhow, we'll see after
couple of releases.

Neal suggested to have:
%__python_requires
%{_rpmconfigdir}/%{?pythondistdeps_enable:pythondistdeps.py}%{!?pythondistdeps_enable:pythondeps.sh}
--requires
in python.attr inside RPM.

I tested it and it just works once I specify `%global
pythondistdeps_enable 1` in spec. Can you help me to get this
included? With RPM part it's clear how to get this, but updating
guidelines and other stuff...

This will also drastically simplify the work of tools like pyp2rpm,
since instead of having to do crazy processing of module names, it can
just use the appropriate pypi provides/requires. If the macro template
enables the requires generator, it won't even need to specify requires
at all, as they'll be generated from the wheel data anyway.

+1, ideally that'll leave us with only one automatic dependency generator.

Problems with upstreams getting setup.py wrong should be treated as
upstream bugs and treated accordingly: reported as pull requests, or, as
the last resort, by a Fedora-specific patch to setup.py.

CCing Michal from the pyp2rpm project, so that everyone knows he's aware
of the discussion here.

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

Re: [RFC] RPM's Python dependency generator

2016-12-01 Thread Tomas Orsava


On 12/01/2016 02:36 PM, Igor Gnatenko wrote:

We'll see how it will go. we have depgen for pkgconfig, libraries,
etc. for many years and people don't go and debug it immediately, but
for many of packages it will help a lot. Anyhow, we'll see after
couple of releases.


Yeah, absolutely. When it's battle-tested and solid, it will make 
packaging that much easier.



Neal suggested to have:
%__python_requires
%{_rpmconfigdir}/%{?pythondistdeps_enable:pythondistdeps.py}%{!?pythondistdeps_enable:pythondeps.sh}
--requires
in python.attr inside RPM.


Oh that's clever, I was wondering how things like that are done!


I tested it and it just works once I specify `%global
pythondistdeps_enable 1` in spec. Can you help me to get this
included? With RPM part it's clear how to get this, but updating
guidelines and other stuff...


AFAIK the best way to get the guidelines updated is to create an 
accompanying Fedora Change. [0]
I sadly don't have free cycles to take that on, as I'm currently 
involved in 2 upcoming Fedora Changes, nevertheless I will gladly 
provide any help and guidance you might need!


[0] https://fedoraproject.org/wiki/Changes/Policy
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org

Re: [RFC] RPM's Python dependency generator

2016-12-01 Thread Neal Gompa

On Thu, Dec 1, 2016 at 8:36 AM, Igor Gnatenko  wrote:
> On Wed, Nov 30, 2016 at 2:53 PM, Tomas Orsava  wrote:
>> On 11/30/2016 02:44 PM, Neal Gompa wrote:
>>>
>>> On Wed, Nov 30, 2016 at 8:41 AM, Tomas Orsava  wrote:

 I don't think the depgen should be enabled by default, at least not in
 the
 foreseeable future. IIRC it's not that well implemented—e.g. I believe it
 doesn't read requirements.txt for example (but I might be wrong).
 There will be a lot of cases where the generated requirements are
 incomplete, or contain unnecessary entries, etc. I think it should remain
 an
 opt-in.

>>> According to various Python people, we're not actually supposed to
>>> read requirements.txt. That file is explicitly designed for people to
>>> individualized deployments. The proper place to get this information
>>> is from the egg-info/dist-info data, which is what we read. The fact
>>> that some people abuse requirements.txt and have it read in by their
>>> setup.py is beside the point. Whatever the setup.py (thus
>>> pip/easy_install/etc.) says it needs, the generator will dutifully
>>> report.
>>
>>
>> The fact remains in too many cases it will need to be manually adjusted, it
>> won't be foolproof.
>> Therefore I argue it would be better for it to be an opt-in so that new
>> packagers don't immediately have to jump in into debugging a depgen they
>> have no clue how really works.
> We'll see how it will go. we have depgen for pkgconfig, libraries,
> etc. for many years and people don't go and debug it immediately, but
> for many of packages it will help a lot. Anyhow, we'll see after
> couple of releases.
>
> Neal suggested to have:
> %__python_requires
> %{_rpmconfigdir}/%{?pythondistdeps_enable:pythondistdeps.py}%{!?pythondistdeps_enable:pythondeps.sh}
> --requires
> in python.attr inside RPM.
>
> I tested it and it just works once I specify `%global
> pythondistdeps_enable 1` in spec. Can you help me to get this
> included? With RPM part it's clear how to get this, but updating
> guidelines and other stuff...

This will also drastically simplify the work of tools like pyp2rpm,
since instead of having to do crazy processing of module names, it can
just use the appropriate pypi provides/requires. If the macro template
enables the requires generator, it won't even need to specify requires
at all, as they'll be generated from the wheel data anyway.


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

Re: Creating an new update is failing

2016-12-01 Thread Michael Catanzaro

On Thu, 2016-12-01 at 07:23 +0100, Ralf Corsepius wrote:
> This problem seems gone, but now I am seeing another one:

Also, the search form seems broken again. I'm positive it was working
just a couple days ago. I see errors in the WebKit web inspector:

[Error] Refused to connect to wss://hub.fedoraproject.org:9939 because
it does not appear in the connect-src directive of the Content Security
Policy.
[Error] SecurityError (DOM Exception 18): The operation is insecure.
(anonymous function) (live.js:27)
WebSocketSetup (live.js:27)
(anonymous function) (live.js:2)
c (jquery-1.10.2.min.js:4:26042)
fireWith (jquery-1.10.2.min.js:4:26842)
ready (jquery-1.10.2.min.js:4:3317)
q (jquery-1.10.2.min.js:4:723)
[Error] Failed to load resource: the server responded with a status of
404 (Not Found) (bootstrap.css.map, line 0)

I have to guess the URL to get to the page for my update. :(

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

Re: Release validation NG: planning thoughts

2016-12-01 Thread Josef Skladanka

On Wed, Nov 30, 2016 at 6:29 PM, Adam Williamson  wrote:

> On Wed, 2016-11-30 at 18:20 +0100, Josef Skladanka wrote:
> > I would try not to go the third way, because that is really prone to
> erros
> > IMO, and I'm not sure that "per context" is always right. So for me, the
> > "TCMS" part of the data, should be:
> > 1) testcases (with required fields/types of the fields in the "result
> > response"
> > 2) testplans - which testcases, possibly organized into groups. Maybe
> even
> > dependencies + saying "I need testcase X to pass, Y can be pass or warn,
> Z
> > can be whatever when A passes, for the testplan to pass"
> >
> > But this is fairly complex thing, to be honest, and it would be the first
> > and only useable TCMS in the world (from my point of view).
>
> I have rather different opinions, actually...but I'm not working on
> this right now and I'd rather have something concrete to discuss than
> just opinions :)
>
> We should obviously set goals properly, before diving into implementation
details :) I'm interested in what you have in mind, since I've been
thinking about this particular kind of thing for the last few years, and it
really depends on what you expect of the system.
___
qa-devel mailing list -- qa-de...@lists.fedoraproject.org
To unsubscribe send an email to qa-devel-le...@lists.fedoraproject.org

msuchy uploaded perl-Satcon-2.6.1.tar.gz for perl-Satcon

2552385284eea0a8922a27e625914a3e  perl-Satcon-2.6.1.tar.gz

http://pkgs.fedoraproject.org/lookaside/pkgs/perl-Satcon/perl-Satcon-2.6.1.tar.gz/md5/2552385284eea0a8922a27e625914a3e/perl-Satcon-2.6.1.tar.gz
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: Base Runtime prototype build and numerous FTBFS issues

2016-12-01 Thread Stephen Gallagher

On 12/01/2016 06:06 AM, Igor Gnatenko wrote:
> On Wed, Nov 30, 2016 at 4:36 PM, Petr Šabata  wrote:
>> (Since this is a common question: No, the final Base Runtime module,
>> or the Generational Core stack it is part of, won't be self-hosting and
>> we won't be shipping the entire set we're currently working with under
>> that name.)
>>
...
>> And the modulemd input for this build is here:
>> http://pkgs.stg.fedoraproject.org/cgit/modules/base-runtime.git/tree/base-runtime.yaml?id=d2485512c7916304e73fabc5db422798eb2be1d5
> Wondering why rubygem*, jboss*, nodejs* and gstreamer* are there...

As noted in the quote above, this is part of the bootstrapping set. In order to
get off the ground, we need to be able to build modules in the module
infrastructure. This means we need to be able to build the tools that build the
packages in the modules (and in turn, the tools to build those tools and so on).
The 2943 SRPMs in this first pass comprises the full, recursive set of packages
necessary to self-host the Base Runtime set of 162 SRPMs.

Given the relatively small number of failures, it's not really worth the effort
(right now) to try to figure out why certain packages are getting pulled in.
Yes, this set is far larger than we would prefer, but since this is a
bootstrapping effort that will hopefully not need to happen again, there's no
strong reason to dig deeply into it except to satisfy curiosity.

signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Creating an new update is failing

2016-12-01 Thread Steve Dickson



On 12/01/2016 07:19 AM, Jiri Vanek wrote:
> On 12/01/2016 10:55 AM, Jiri Vanek wrote:
>> On 11/30/2016 07:10 PM, Patrick  マルタインアンドレアス  Uiterwijk wrote:
>>> Hi,
>>>
 Hello,

 I'm trying to create a new update and
 I'm getting this error:

 Builds : Unable to create update. Parent instance is not bound to a 
 Session; lazy load
 operation of attribute 'release' cannot proceed

 The build looks fine:
 http://koji.fedoraproject.org/koji/buildinfo?buildID=821471

 Any ideas what the problem is?
>>>
>>> I'm very sorry for the problems here, they should now be fixed.
>>>

>>
>> Still not better :(
> 
> Working now.
+1... thanks!

steved.

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

[Bug 1398478] perl-Perl-Critic-Pulp-91 is available

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



--- Comment #13 from Fedora Update System  ---
perl-Perl-Critic-Pulp-92-1.fc23 has been submitted as an update to Fedora 23.
https://bodhi.fedoraproject.org/updates/FEDORA-2016-177bbd6ad1

-- 
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 1400224] perl-Perl-Critic-Pulp-92 is available

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



--- Comment #4 from Fedora Update System  ---
perl-Perl-Critic-Pulp-92-1.fc23 has been submitted as an update to Fedora 23.
https://bodhi.fedoraproject.org/updates/FEDORA-2016-177bbd6ad1

-- 
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 1398478] perl-Perl-Critic-Pulp-91 is available

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



--- Comment #12 from Fedora Update System  ---
perl-Perl-Critic-Pulp-92-1.fc24 has been submitted as an update to Fedora 24.
https://bodhi.fedoraproject.org/updates/FEDORA-2016-6e6fc07729

-- 
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 1400224] perl-Perl-Critic-Pulp-92 is available

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



--- Comment #3 from Fedora Update System  ---
perl-Perl-Critic-Pulp-92-1.fc24 has been submitted as an update to Fedora 24.
https://bodhi.fedoraproject.org/updates/FEDORA-2016-6e6fc07729

-- 
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 1398478] perl-Perl-Critic-Pulp-91 is available

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



--- Comment #11 from Fedora Update System  ---
perl-Perl-Critic-Pulp-92-1.fc25 has been submitted as an update to Fedora 25.
https://bodhi.fedoraproject.org/updates/FEDORA-2016-aba5e8d95b

-- 
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 1400224] perl-Perl-Critic-Pulp-92 is available