jplesnik pushed to perl-Config-Model-Itself (master). "2.002 bump"

[notifications]

From 40a16d9aca32e22cea3fa4c0ad420ad2d5078b6d Mon Sep 17 00:00:00 2001
From: Jitka Plesnikova 
Date: Thu, 21 Jan 2016 13:10:11 +0100
Subject: 2.002 bump

---
 .gitignore|  1 +
 perl-Config-Model-Itself.spec | 26 +-
 sources   |  2 +-
 3 files changed, 23 insertions(+), 6 deletions(-)

diff --git a/.gitignore b/.gitignore
index 6ba0dc6..cb929fc 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1,2 @@
 /Config-Model-Itself-1.245.tar.gz
+/Config-Model-Itself-2.002.tar.gz
diff --git a/perl-Config-Model-Itself.spec b/perl-Config-Model-Itself.spec
index 7f09b3a..75ac883 100644
--- a/perl-Config-Model-Itself.spec
+++ b/perl-Config-Model-Itself.spec
@@ -1,5 +1,5 @@
 Name:   perl-Config-Model-Itself
-Version:1.245
+Version:2.002
 Release:1%{?dist}
 Summary:Model editor for Config::Model
 License:LGPLv2+
@@ -7,10 +7,14 @@ Group:  Development/Libraries
 URL:http://search.cpan.org/dist/Config-Model-Itself/
 Source0:
http://www.cpan.org/authors/id/D/DD/DDUMONT/Config-Model-Itself-%{version}.tar.gz
 BuildArch:  noarch
+BuildRequires:  coreutils
 BuildRequires:  perl
+BuildRequires:  perl(App::Cmd::Tester)
+BuildRequires:  perl(App::Cme) >= 1.002
+BuildRequires:  perl(App::Cme::Common)
 BuildRequires:  perl(base)
 BuildRequires:  perl(Carp)
-BuildRequires:  perl(Config::Model) >= 2.064
+BuildRequires:  perl(Config::Model) >= 2.075
 BuildRequires:  perl(Config::Model::TkUI) >= 1.210
 BuildRequires:  perl(Config::Model::Value)
 BuildRequires:  perl(Data::Compare)
@@ -27,6 +31,7 @@ BuildRequires:  perl(lib)
 BuildRequires:  perl(Log::Log4perl) >= 1.11
 BuildRequires:  perl(Module::Build)
 BuildRequires:  perl(Mouse)
+BuildRequires:  perl(Mouse::Util::TypeConstraints)
 BuildRequires:  perl(Path::Tiny)
 BuildRequires:  perl(Pod::POM)
 BuildRequires:  perl(Pod::Usage)
@@ -39,12 +44,16 @@ BuildRequires:  perl(Tk)
 BuildRequires:  perl(vars)
 BuildRequires:  perl(warnings)
 BuildRequires:  perl(YAML::Tiny)
-Requires:   perl(Config::Model::TkUI) >= 1.210
+BuildRequires:  sed
 Requires:   perl(:MODULE_COMPAT_%(eval "`perl -V:version`"; echo $version))
+Requires:   perl(App::Cme) >= 1.002
+Requires:   perl(Config::Model::TkUI) >= 1.210
 
 %global __requires_exclude 
%{?__requires_exclude:%__requires_exclude|}^perl\\(Config::Model\\)\s*$
+%global __requires_exclude %__requires_exclude|^perl\\(Config::Model\\) >= 
2.064\s*$
 %global __requires_exclude 
%__requires_exclude|^perl\\(Config::Model::TkUI\\)\s*$
 %global __requires_exclude %__requires_exclude|^perl\\(Log::Log4perl\\)\s*$
+%global __requires_exclude %__requires_exclude|^perl\\(App::Cme\\)\s*$
 
 %description
 Config::Itself module and its model files provide a model of Config:Model
@@ -62,18 +71,25 @@ perl Build.PL installdirs=vendor
 ./Build install destdir=$RPM_BUILD_ROOT create_packlist=0
 %{_fixperms} $RPM_BUILD_ROOT/*
 
+# Install bash_completion script
+install -D -m 0644 contrib/bash_completion.cme_meta 
%{buildroot}%{_sysconfdir}/bash_completion.d/cme_meta
+
 %check
 ./Build test
 
 %files
 %license LICENSE
-%doc Changes config-model-edit data README
+%doc Changes data README.md
 %{perl_vendorlib}/*
 %{_bindir}/config-model-edit
-%{_mandir}/man3/*
 %{_mandir}/man1/*
+%{_mandir}/man3/*
+%{_sysconfdir}/bash_completion.d
 
 %changelog
+* Fri Jan 15 2016 Jitka Plesnikova  - 2.002-1
+- 2.002 bump
+
 * Mon Jul 20 2015 Jitka Plesnikova  - 1.245-1
 - 1.245 bump
 - Modernize spec
diff --git a/sources b/sources
index 2b09efe..7e3c83a 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-0b48cf3b596b49681094424b212e8363  Config-Model-Itself-1.245.tar.gz
+7ff844e759979a81feef30c6f3b7f356  Config-Model-Itself-2.002.tar.gz
-- 
cgit v0.11.2



http://pkgs.fedoraproject.org/cgit/perl-Config-Model-Itself.git/commit/?h=master=40a16d9aca32e22cea3fa4c0ad420ad2d5078b6d
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

[Bug 1290794] Upgrade perl-Config-Model-Itself to 2.002

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |CLOSED
 CC||jples...@redhat.com
   Fixed In Version||perl-Config-Model-Itself-2.
   ||002-1.fc24
 Resolution|--- |RAWHIDE
Last Closed||2016-01-21 07:16:11



-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

jplesnik pushed to perl-XML-XPath (master). "1.25 bump"

[notifications]

From 58542d01a21689d1a828f8bb84806b69fc9236c9 Mon Sep 17 00:00:00 2001
From: Jitka Plesnikova 
Date: Thu, 21 Jan 2016 13:30:53 +0100
Subject: 1.25 bump

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

diff --git a/.gitignore b/.gitignore
index c0f1a26..4921476 100644
--- a/.gitignore
+++ b/.gitignore
@@ -4,3 +4,4 @@ XML-XPath-1.13.tar.gz
 /XML-XPath-1.21.tar.gz
 /XML-XPath-1.22.tar.gz
 /XML-XPath-1.24.tar.gz
+/XML-XPath-1.25.tar.gz
diff --git a/perl-XML-XPath.spec b/perl-XML-XPath.spec
index 53592e2..c851bff 100644
--- a/perl-XML-XPath.spec
+++ b/perl-XML-XPath.spec
@@ -1,5 +1,5 @@
 Name:   perl-XML-XPath
-Version:1.24
+Version:1.25
 Release:1%{?dist}
 Summary:XPath parser and evaluator for Perl
 License:Artistic 2.0
@@ -68,6 +68,9 @@ make test
 %{_mandir}/man3/*.3*
 
 %changelog
+* Thu Jan 21 2016 Jitka Plesnikova  - 1.25-1
+- 1.25 bump
+
 * Wed Jan 20 2016 Jitka Plesnikova  - 1.24-1
 - 1.24 bump
 
diff --git a/sources b/sources
index 9c848b0..a335d86 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-5eea1e03f4a548b427d9a8cdd13c98be  XML-XPath-1.24.tar.gz
+a586abd19e91d38df4d17ff940777dc3  XML-XPath-1.25.tar.gz
-- 
cgit v0.11.2



http://pkgs.fedoraproject.org/cgit/perl-XML-XPath.git/commit/?h=master=58542d01a21689d1a828f8bb84806b69fc9236c9
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

[Bug 1300658] Please provide a package for EPEL7

[bugzilla]

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



--- Comment #1 from Robin Lee  ---
I may not have time to get it done recently. Would you like to take this
package?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

Re: Python naming guidelines clarification

[Jan Včelák]

Thank you, Robert. It makes perfect sense. I'll fix my packages.

Cheers,

Jan

On Thu, Jan 21, 2016 at 2:12 PM, Robert Kuska  wrote:
>
>
> - Original Message -
>> From: "Jan Včelák" 
>> To: "Development discussions related to Fedora" 
>> 
>> Sent: Thursday, January 21, 2016 12:40:47 PM
>> Subject: Re: Python naming guidelines clarification
>>
>> On Wed, Jan 20, 2016 at 11:54 PM, Zbigniew Jędrzejewski-Szmek wrote:
>> > Yes, the guidelines apply to the source rpm name too. Those
>> > srpms should be called python-*, because they contain python libries.
>>
>> OK. Thank you.
>>
>> And what is the best current practice if the library contains some
>> utilities. Should the utilities land in the python{2,3}-name package?
>> Should it land in both?
>>
>> To give you an example, the ripe.atlas.sagan ships a utility
>> parse_abuf. I'm currently removing it from the package as the upstream
>> is going to deprecate it with the next release. But theoretically,
>> should the utility be included in python2-ripe-atlas-sagan as
>> parse_abuf2 and in python3-ripe-atlas-sagan as parse_abuf? Or would it
>> be better for instance to create a package ripe-atlas-sagan which will
>> contain just the Python 3 version of the utility?
>>
>
> As I suggested in my email before, package just one version running on
> Python3 (if supported) when utility provides same functionality whether run
> with Python3 or Python2.
>
> There are special cases when you have to provide bin files for both major
> versions of python, good example is python-pip (python3-pip installs python3
> modules, python2-pip installs python2 modules).
>
> Here are conventions for naming executables and some mentions about
> Python2/Python3 executables conflicts:
> https://fedoraproject.org/wiki/Packaging:Python#Naming
>
> I believe that your confusion (you are not alone) is caused by misleading
> example specfile in python packaging guidelines and lack of verbosity
> about such cases, I already tried to argue about changing it
> https://fedorahosted.org/fpc/ticket/558#comment:6
>
>
>
> Lets assume python project named `example` which ships executable `example`:
>
> 1. `example` is pure application, supports Python3 -
> I package it as `example` with executable `example` running on Python3, all
> backend libraries will be also packaged under `example` rpm as they are not 
> meant
> to be used as libraries in other projects
>
> 2. `example` is application and it also ships libraries which may be used in
> other projects -
> I package it as `example` which will ship executable `example` running on 
> Python3,
> I will build it for both Python2 and Python3 and package its libraries under
> python2-example and python3-example, (hence `example` will require 
> `python3-example`)
>
> 3. `example` is application with different behaviour for both major python 
> versions -
> I package `example` as `python-example` with `python2-example` and 
> `python3-example`
> subpackages carrying both backends libraries and executables, unversioned 
> executable
> `example` will be packaged under `python2-example` (hence running on python2).
>
> I hope it makes sense :)
>
>> Jan
>> --
>> devel mailing list
>> devel@lists.fedoraproject.org
>> http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
>
>
> --
> Robert Kuska
> {rkuska}
> --
> devel mailing list
> devel@lists.fedoraproject.org
> http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Should 'dnf install gtk3-devel.i686' work?

[Reindl Harald]

Am 21.01.2016 um 14:34 schrieb Yanko Kaneti:

On Thu, 2016-01-21 at 09:38 +, Richard W.M. Jones wrote:

On Thu, Jan 21, 2016 at 11:10:22AM +0200, Yanko Kaneti wrote:

On Wed, 2016-01-20 at 15:50 +, Richard W.M. Jones wrote:

If you're on freshly installed Fedora 23 (x86-64), then

   dnf install gtk3-devel.x86_64
..

Is this a bug or is it not expected this would work or I am doing
it
wrong?


IMO trying to get this (i686 development environment on x86_64
native
install) to work reliably and chasing down all the corner cases is
futile, leads to confusion instead of improving the developer
experience in any significant way compared to using mock and should
be
declared unsupported.


The logical consequence of this is we would get rid of multilib
entirely.


Not really. Runtime multilib is quite valuable feature, as any user of
closed source blobs (Steam!!) could attest.


the same for wine and windows games

(not that i personally have any i686 package installed)



signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

[Bug 1300658] New: Please provide a package for EPEL7

[bugzilla]

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

Bug ID: 1300658
   Summary: Please provide a package for EPEL7
   Product: Fedora EPEL
   Version: el6
 Component: perl-Net-ARP
  Assignee: robinlee.s...@gmail.com
  Reporter: ru...@rubenkerkhof.com
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org,
robinlee.s...@gmail.com



Hi,

I just noticed that perl-Net-ARP doesn't have a package in EPEL7.
perl-Net-ARP is a requirement for mysql-mmm. Could you please build for EPEL7?

Thanks!

Ruben

-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

Re: Should 'dnf install gtk3-devel.i686' work?

[Richard W.M. Jones]

On Thu, Jan 21, 2016 at 07:41:23AM -0600, Rex Dieter wrote:
> Rex Dieter wrote:
> 
> > Michael Schwendt wrote:
> > 
> >> On Wed, 20 Jan 2016 17:32:52 +0100, Ralf Corsepius wrote:
> >> 
> >>> IMO, this is supposed to work => Bug
> >>> 
> >>> The big question would be: Where?
> >> 
> >> It cannot work as long as gtk3-devel relies on pkgconfig(foo)
> >> dependencies instead of arch-specific explicit Requires.
> > 
> > Sounds like one way forward to fix this is to make pkgconfig dependencies
> > arch'd
> 
> Hrm, thinking on it more, I don't think that can ever work for this purpose.  
> There's no way to know that
> Requires: foo
> in a bar.pc pkgconfig file refers to an arch'd foo or not (foo could 
> possibly be noarch).

Right - that is precisely the problem with my current patch:

https://bugzilla.redhat.com/show_bug.cgi?id=1300432#c2

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Should 'dnf install gtk3-devel.i686' work?

[Richard W.M. Jones]

On Thu, Jan 21, 2016 at 03:34:34PM +0200, Yanko Kaneti wrote:
> On Thu, 2016-01-21 at 09:38 +, Richard W.M. Jones wrote:
> > On Thu, Jan 21, 2016 at 11:10:22AM +0200, Yanko Kaneti wrote:
> > > On Wed, 2016-01-20 at 15:50 +, Richard W.M. Jones wrote:
> > > > If you're on freshly installed Fedora 23 (x86-64), then
> > > > 
> > > >   dnf install gtk3-devel.x86_64
> > > > ..
> > > > 
> > > > Is this a bug or is it not expected this would work or I am doing
> > > > it
> > > > wrong?
> > > 
> > > IMO trying to get this (i686 development environment on x86_64
> > > native
> > > install) to work reliably and chasing down all the corner cases is
> > > futile, leads to confusion instead of improving the developer
> > > experience in any significant way compared to using mock and should
> > > be
> > > declared unsupported.
> > 
> > The logical consequence of this is we would get rid of multilib
> > entirely.
> 
> Not really. Runtime multilib is quite valuable feature, as any user of
> closed source blobs (Steam!!) could attest.

Hmmm.  Do we care about closed source blobs?

Actually I really want 'dnf install gtk3-devel.i686' to work, because
the alternatives (mock, virtualization) are not very good solutions
because they are difficult to automate.

I'm trying to build a 32 bit virt-p2v binary.  virt-p2v is free
software.  Building a 32 bit binary is a useful thing to do since the
binary is meant to be copied to ancient (pre-2004) physical hardware
in order to virtualize what's running on that hardware.

In the context of Koji or users doing `./configure && make' you can't
really fire up a chroot or VM to do part of the build.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

[EPEL-devel] Re: The %license property is now supported in EPEL6

[Peter Lemenkov]

Hello All!

2016-01-20 22:03 GMT+01:00 Jason L Tibbitts III :
> Just a note that it EPEL6 no longer requires you to include the
> definition of %license property; you can use it freely in your %files
> list as you would in EPEL7 or Fedora.  It simply maps to %doc as it
> would if you had included the magic line noise manually.  This works for
> me in koji; if it doesn't work in your local mock instance, it's
> possible that the mirrors still need to catch up with the change to
> comps.

Great news! Thanks everyone involved!

-- 
With best regards, Peter Lemenkov.
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

[Bug 1300671] New: perl-CPAN-Perl-Releases-2.56 is available

[bugzilla]

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

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



Latest upstream release: 2.56
Current version/release in rawhide: 2.54-1.fc24
URL: http://search.cpan.org/dist/CPAN-Perl-Releases/

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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

Re: Should 'dnf install gtk3-devel.i686' work?

[Rex Dieter]

Rex Dieter wrote:

> Michael Schwendt wrote:
> 
>> On Wed, 20 Jan 2016 17:32:52 +0100, Ralf Corsepius wrote:
>> 
>>> IMO, this is supposed to work => Bug
>>> 
>>> The big question would be: Where?
>> 
>> It cannot work as long as gtk3-devel relies on pkgconfig(foo)
>> dependencies instead of arch-specific explicit Requires.
> 
> Sounds like one way forward to fix this is to make pkgconfig dependencies
> arch'd

Hrm, thinking on it more, I don't think that can ever work for this purpose.  
There's no way to know that
Requires: foo
in a bar.pc pkgconfig file refers to an arch'd foo or not (foo could 
possibly be noarch).

-- Rex

--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

[Bug 1300488] perl-XML-XPath-1.25 is available

[bugzilla]

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



--- Comment #3 from Upstream Release Monitoring 
 ---
jplesnik's perl-XML-XPath-1.25-1.fc24 completed
http://koji.fedoraproject.org/koji/buildinfo?buildID=712831

-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

[Bug 1300488] perl-XML-XPath-1.25 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-XML-XPath-1.25-1.fc24
 Resolution|--- |RAWHIDE
Last Closed||2016-01-21 07:55:27



-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

Re: Should 'dnf install gtk3-devel.i686' work?

[Petr Pisar]

On 2016-01-21, Rex Dieter  wrote:
> Rex Dieter wrote:
>> Sounds like one way forward to fix this is to make pkgconfig dependencies
>> arch'd
>
> Hrm, thinking on it more, I don't think that can ever work for this purpose.  
> There's no way to know that
> Requires: foo
> in a bar.pc pkgconfig file refers to an arch'd foo or not (foo could 
> possibly be noarch).
>
With rich dependencies we could hack it by depending on pkgconfig(foo)
or pkgconfig(foo)%{?_isa}.

-- Petr
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Updating hdf5 to 1.8.16 in rawhide today

[Orion Poplawski]

On 01/14/2016 04:25 PM, Orion Poplawski wrote:

On 11/20/2015 02:39 PM, Orion Poplawski wrote:

I'll be updating hdf5 to 1.8.16 in rawhide in the next few days.  This
includes a soname bump for the C++ wrapper libs, but as usual I'll be
rebuilding all deps due to run-time version checking by the library.



Well, the arm build is hanging in a test, so this didn't happen today.  I'll
try to reproduce the test failure to see what's up...


Switching mpich to the nemesis channel on all platforms has cleared this 
up.  hdf5 build has started now and should be done in about 4 hours. 
Then I'll start the rest of the rebuilds.



--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA DivisionFAX: 303-415-9702
3380 Mitchell Lane  or...@cora.nwra.com
Boulder, CO 80301  http://www.cora.nwra.com
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

rawhide report: 20160121 changes

[Fedora Rawhide Report]

Compose started at Thu Jan 21 05:15:03 UTC 2016
Broken deps for i386
--
[IQmol]
IQmol-2.3.0-9.fc24.i686 requires libboost_serialization.so.1.58.0
IQmol-2.3.0-9.fc24.i686 requires libboost_iostreams.so.1.58.0
IQmol-2.3.0-9.fc24.i686 requires libOpenMeshCore.so.3.2
[alliance]
alliance-5.0-40.20090901snap.fc22.i686 requires libXm.so.2
[asterisk]
asterisk-calendar-13.3.2-1.fc23.2.i686 requires libical.so.1
[avogadro]
avogadro-libs-1.1.1-15.fc24.i686 requires libGLEW.so.1.10
[banshee]
banshee-2.6.2-12.fc23.i686 requires mono(taglib-sharp) = 0:2.0.3.7
[banshee-community-extensions]
banshee-community-extensions-2.4.0-11.fc23.i686 requires 
mono(taglib-sharp) = 0:2.0.3.7
[couchdb]
couchdb-1.6.1-7.fc24.i686 requires erlang(erl_nif_version) = 0:2.7
couchdb-1.6.1-7.fc24.i686 requires erlang(erl_drv_version) = 0:3.1
[diskimage-builder]
diskimage-builder-1.8.0-1.fc24.noarch requires /usr/local/bin/dib-python
[eclipse-jbosstools]
eclipse-jbosstools-as-4.2.2-1.fc22.noarch requires 
osgi(org.eclipse.tm.terminal)
[ejabberd]
ejabberd-14.07-6.fc22.i686 requires erlang(erl_nif_version) = 0:2.7
ejabberd-14.07-6.fc22.i686 requires erlang(erl_drv_version) = 0:3.1
[erlang-basho_metrics]
erlang-basho_metrics-1.0.0-15.fc23.i686 requires 
erlang(erl_nif_version) = 0:2.7
[erlang-bitcask]
erlang-bitcask-1.6.3-6.fc22.i686 requires erlang(erl_nif_version) = 
0:2.7
[erlang-ebloom]
erlang-ebloom-2.0.0-2.fc23.i686 requires erlang(erl_nif_version) = 0:2.7
[erlang-eleveldb]
erlang-eleveldb-1.3.2-7.fc22.i686 requires erlang(erl_nif_version) = 
0:2.7
[erlang-emmap]
erlang-emmap-0-0.12.git05ae1bb.fc23.i686 requires 
erlang(erl_nif_version) = 0:2.7
[erlang-esasl]
erlang-esasl-0.1-18.20120116git665cc80.fc23.i686 requires 
erlang(erl_drv_version) = 0:3.1
[erlang-js]
erlang-js-1.3.0-1.fc22.i686 requires erlang(erl_drv_version) = 0:3.1
[erlang-skerl]
erlang-skerl-1.1.0-11.fc23.i686 requires erlang(erl_nif_version) = 0:2.7
[erlang-snappy]
erlang-snappy-1.0.3-0.11.git80db168.fc23.i686 requires 
erlang(erl_nif_version) = 0:2.7
[fawkes]
fawkes-core-0.5.0-26.fc24.i686 requires libmicrohttpd.so.10
fawkes-plugin-player-0.5.0-26.fc24.i686 requires libgeos-3.4.2.so
fawkes-plugin-xmlrpc-0.5.0-26.fc24.i686 requires libmicrohttpd.so.10
[gcc-python-plugin]
gcc-python2-debug-plugin-0.14-8.fc24.i686 requires gcc = 0:5.3.1-2.fc24
gcc-python2-plugin-0.14-8.fc24.i686 requires gcc = 0:5.3.1-2.fc24
gcc-python3-debug-plugin-0.14-8.fc24.i686 requires gcc = 0:5.3.1-2.fc24
gcc-python3-plugin-0.14-8.fc24.i686 requires gcc = 0:5.3.1-2.fc24
[gnash]
1:gnash-0.8.10-19.fc24.i686 requires libboost_thread.so.1.58.0
1:gnash-0.8.10-19.fc24.i686 requires libboost_system.so.1.58.0
1:gnash-0.8.10-19.fc24.i686 requires libboost_serialization.so.1.58.0
1:gnash-0.8.10-19.fc24.i686 requires libboost_program_options.so.1.58.0
1:gnash-0.8.10-19.fc24.i686 requires libboost_iostreams.so.1.58.0
1:gnash-0.8.10-19.fc24.i686 requires libboost_date_time.so.1.58.0
1:gnash-cygnal-0.8.10-19.fc24.i686 requires libboost_thread.so.1.58.0
1:gnash-cygnal-0.8.10-19.fc24.i686 requires libboost_system.so.1.58.0
1:gnash-cygnal-0.8.10-19.fc24.i686 requires 
libboost_serialization.so.1.58.0
1:gnash-cygnal-0.8.10-19.fc24.i686 requires 
libboost_program_options.so.1.58.0
1:gnash-cygnal-0.8.10-19.fc24.i686 requires libboost_iostreams.so.1.58.0
1:gnash-cygnal-0.8.10-19.fc24.i686 requires libboost_date_time.so.1.58.0
1:gnash-extension-dejagnu-0.8.10-19.fc24.i686 requires 
libboost_thread.so.1.58.0
1:gnash-extension-dejagnu-0.8.10-19.fc24.i686 requires 
libboost_system.so.1.58.0
1:gnash-extension-dejagnu-0.8.10-19.fc24.i686 requires 
libboost_program_options.so.1.58.0
1:gnash-extension-dejagnu-0.8.10-19.fc24.i686 requires 
libboost_iostreams.so.1.58.0
1:gnash-extension-fileio-0.8.10-19.fc24.i686 requires 
libboost_thread.so.1.58.0
1:gnash-extension-fileio-0.8.10-19.fc24.i686 requires 
libboost_system.so.1.58.0
1:gnash-extension-fileio-0.8.10-19.fc24.i686 requires 
libboost_program_options.so.1.58.0
1:gnash-extension-fileio-0.8.10-19.fc24.i686 requires 
libboost_iostreams.so.1.58.0
1:gnash-extension-lirc-0.8.10-19.fc24.i686 requires 
libboost_thread.so.1.58.0
1:gnash-extension-lirc-0.8.10-19.fc24.i686 requires 
libboost_system.so.1.58.0
1:gnash-extension-lirc-0.8.10-19.fc24.i686 requires 
libboost_program_options.so.1.58.0
1:gnash-extension-lirc-0.8.10-19.fc24.i686 requires 
libboost_iostreams.so.1.58.0
1:gnash-extension-mysql-0.8.10-19.fc24.i686 requires 
libboost_thread.so.1.58.0

Re: Python naming guidelines clarification

[Robert Kuska]

- Original Message -
> From: "Jan Včelák" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Thursday, January 21, 2016 12:40:47 PM
> Subject: Re: Python naming guidelines clarification
> 
> On Wed, Jan 20, 2016 at 11:54 PM, Zbigniew Jędrzejewski-Szmek wrote:
> > Yes, the guidelines apply to the source rpm name too. Those
> > srpms should be called python-*, because they contain python libries.
> 
> OK. Thank you.
> 
> And what is the best current practice if the library contains some
> utilities. Should the utilities land in the python{2,3}-name package?
> Should it land in both?
> 
> To give you an example, the ripe.atlas.sagan ships a utility
> parse_abuf. I'm currently removing it from the package as the upstream
> is going to deprecate it with the next release. But theoretically,
> should the utility be included in python2-ripe-atlas-sagan as
> parse_abuf2 and in python3-ripe-atlas-sagan as parse_abuf? Or would it
> be better for instance to create a package ripe-atlas-sagan which will
> contain just the Python 3 version of the utility?
> 

As I suggested in my email before, package just one version running on
Python3 (if supported) when utility provides same functionality whether run
with Python3 or Python2.

There are special cases when you have to provide bin files for both major
versions of python, good example is python-pip (python3-pip installs python3 
modules, python2-pip installs python2 modules).

Here are conventions for naming executables and some mentions about 
Python2/Python3 executables conflicts:
https://fedoraproject.org/wiki/Packaging:Python#Naming

I believe that your confusion (you are not alone) is caused by misleading
example specfile in python packaging guidelines and lack of verbosity
about such cases, I already tried to argue about changing it 
https://fedorahosted.org/fpc/ticket/558#comment:6



Lets assume python project named `example` which ships executable `example`:

1. `example` is pure application, supports Python3 -
I package it as `example` with executable `example` running on Python3, all
backend libraries will be also packaged under `example` rpm as they are not 
meant
to be used as libraries in other projects

2. `example` is application and it also ships libraries which may be used in
other projects -
I package it as `example` which will ship executable `example` running on 
Python3, 
I will build it for both Python2 and Python3 and package its libraries under
python2-example and python3-example, (hence `example` will require 
`python3-example`)

3. `example` is application with different behaviour for both major python 
versions -
I package `example` as `python-example` with `python2-example` and 
`python3-example`
subpackages carrying both backends libraries and executables, unversioned 
executable
`example` will be packaged under `python2-example` (hence running on python2).

I hope it makes sense :)

> Jan
> --
> devel mailing list
> devel@lists.fedoraproject.org
> http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org


--
Robert Kuska
{rkuska}
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: The %license property is now supported in EPEL6

[Dennis Gilmore]

On Thursday, January 21, 2016 11:48:22 AM Petr Pisar wrote:
> On 2016-01-20, Jason L Tibbitts III  wrote:
> > Just a note that it EPEL6 no longer requires you to include the
> > definition of %license property; you can use it freely in your %files
> > list as you would in EPEL7 or Fedora.  It simply maps to %doc as it
> > would if you had included the magic line noise manually.  This works for
> > me in koji; if it doesn't work in your local mock instance, it's
> > possible that the mirrors still need to catch up with the change to
> > comps.
> 
> How's that implemented? Does the code come from RHEL? Or does EPEL
> modify some RHEL package? Or does it modify comps group? Or does it
> modify default mock configuration for EPEL?

epel-rpm-macros was added to the buildroot and buildsys-build group in comps 
which defines the macros

Dennis
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Should 'dnf install gtk3-devel.i686' work?

[Yanko Kaneti]

On Thu, 2016-01-21 at 09:38 +, Richard W.M. Jones wrote:
> On Thu, Jan 21, 2016 at 11:10:22AM +0200, Yanko Kaneti wrote:
> > On Wed, 2016-01-20 at 15:50 +, Richard W.M. Jones wrote:
> > > If you're on freshly installed Fedora 23 (x86-64), then
> > > 
> > >   dnf install gtk3-devel.x86_64
> > > ..
> > > 
> > > Is this a bug or is it not expected this would work or I am doing
> > > it
> > > wrong?
> > 
> > IMO trying to get this (i686 development environment on x86_64
> > native
> > install) to work reliably and chasing down all the corner cases is
> > futile, leads to confusion instead of improving the developer
> > experience in any significant way compared to using mock and should
> > be
> > declared unsupported.
> 
> The logical consequence of this is we would get rid of multilib
> entirely.

Not really. Runtime multilib is quite valuable feature, as any user of
closed source blobs (Steam!!) could attest.

- Yanko
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Python naming guidelines clarification

[Jan Včelák]

On Wed, Jan 20, 2016 at 11:54 PM, Zbigniew Jędrzejewski-Szmek wrote:
> Yes, the guidelines apply to the source rpm name too. Those
> srpms should be called python-*, because they contain python libries.

OK. Thank you.

And what is the best current practice if the library contains some
utilities. Should the utilities land in the python{2,3}-name package?
Should it land in both?

To give you an example, the ripe.atlas.sagan ships a utility
parse_abuf. I'm currently removing it from the package as the upstream
is going to deprecate it with the next release. But theoretically,
should the utility be included in python2-ripe-atlas-sagan as
parse_abuf2 and in python3-ripe-atlas-sagan as parse_abuf? Or would it
be better for instance to create a package ripe-atlas-sagan which will
contain just the Python 3 version of the utility?

Jan
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

[Bug 1300671] perl-CPAN-Perl-Releases-2.56 is available

[bugzilla]

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

Petr Šabata  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
   Fixed In Version||perl-CPAN-Perl-Releases-2.5
   ||6-1.fc24
 Resolution|--- |RAWHIDE
Last Closed||2016-01-21 09:01:28



-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

[Bug 1216112] CVE-2015-3451 perl-XML-LibXML: "expand_entities" option was not preserved under some circumstances

[bugzilla]

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

Ján Rusnačko  changed:

   What|Removed |Added

 CC||jrusn...@redhat.com
 Whiteboard|impact=low,public=20150423, |impact=low,public=20150423,
   |reported=20150423,source=re |reported=20150423,source=re
   |searcher,cvss2=2.6/AV:N/AC: |searcher,cvss2=2.6/AV:N/AC:
   |H/Au:N/C:P/I:N/A:N,fedora-a |H/Au:N/C:P/I:N/A:N,fedora-a
   |ll/perl-XML-LibXML=affected |ll/perl-XML-LibXML=affected
   |,rhel-5/perl-XML-LibXML=won |,rhel-5/perl-XML-LibXML=won
   |tfix,rhel-6/perl-XML-LibXML |tfix,rhel-6/perl-XML-LibXML
   |=wontfix,rhel-7/perl-XML-Li |=wontfix,rhel-7/perl-XML-Li
   |bXML=wontfix|bXML=wontfix,cwe=CWE-611



-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

jplesnik uploaded XML-XPath-1.25.tar.gz for perl-XML-XPath

[notifications]

a586abd19e91d38df4d17ff940777dc3  XML-XPath-1.25.tar.gz

http://pkgs.fedoraproject.org/lookaside/pkgs/perl-XML-XPath/XML-XPath-1.25.tar.gz/md5/a586abd19e91d38df4d17ff940777dc3/XML-XPath-1.25.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

Re: Should 'dnf install gtk3-devel.i686' work?

[Rex Dieter]

Michael Schwendt wrote:

> On Wed, 20 Jan 2016 17:32:52 +0100, Ralf Corsepius wrote:
> 
>> IMO, this is supposed to work => Bug
>> 
>> The big question would be: Where?
> 
> It cannot work as long as gtk3-devel relies on pkgconfig(foo) dependencies
> instead of arch-specific explicit Requires.

Sounds like one way forward to fix this is to make pkgconfig dependencies 
arch'd

-- Rex
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

psabata pushed to perl-CPAN-Perl-Releases (master). "2.56 bump, updated for v5.23.7"

[notifications]

From d7d1972f36f6e83c4d6d2cbe3b68389291b74f26 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20=C5=A0abata?= 
Date: Thu, 21 Jan 2016 15:00:08 +0100
Subject: 2.56 bump, updated for v5.23.7

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

diff --git a/.gitignore b/.gitignore
index c3c0690..fcc00c9 100644
--- a/.gitignore
+++ b/.gitignore
@@ -36,3 +36,4 @@
 /CPAN-Perl-Releases-2.50.tar.gz
 /CPAN-Perl-Releases-2.52.tar.gz
 /CPAN-Perl-Releases-2.54.tar.gz
+/CPAN-Perl-Releases-2.56.tar.gz
diff --git a/perl-CPAN-Perl-Releases.spec b/perl-CPAN-Perl-Releases.spec
index b95f85c..6ba1ca9 100644
--- a/perl-CPAN-Perl-Releases.spec
+++ b/perl-CPAN-Perl-Releases.spec
@@ -1,5 +1,5 @@
 Name:   perl-CPAN-Perl-Releases
-Version:2.54
+Version:2.56
 Release:1%{?dist}
 Summary:Mapping Perl releases on CPAN to the location of the tarballs
 License:GPL+ or Artistic
@@ -52,6 +52,9 @@ make test
 %{_mandir}/man3/*
 
 %changelog
+* Thu Jan 21 2016 Petr Šabata  - 2.56-1
+- 2.56 bump, updated for v5.23.7
+
 * Tue Dec 22 2015 Petr Šabata  - 2.54-1
 - 2.54 bump, updated for v5.23.6
 
diff --git a/sources b/sources
index d1200d8..6dc668f 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-24842e8cb10d3c177d08eb17df53856d  CPAN-Perl-Releases-2.54.tar.gz
+a6148133929e7dda340b7d2835f0dac0  CPAN-Perl-Releases-2.56.tar.gz
-- 
cgit v0.11.2



http://pkgs.fedoraproject.org/cgit/perl-CPAN-Perl-Releases.git/commit/?h=master=d7d1972f36f6e83c4d6d2cbe3b68389291b74f26
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

psabata uploaded CPAN-Perl-Releases-2.56.tar.gz for perl-CPAN-Perl-Releases

[notifications]

a6148133929e7dda340b7d2835f0dac0  CPAN-Perl-Releases-2.56.tar.gz

http://pkgs.fedoraproject.org/lookaside/pkgs/perl-CPAN-Perl-Releases/CPAN-Perl-Releases-2.56.tar.gz/md5/a6148133929e7dda340b7d2835f0dac0/CPAN-Perl-Releases-2.56.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

Re: Python naming guidelines clarification

[Jan Včelák]

On Thu, Jan 21, 2016 at 9:09 AM, Robert Kuska wrote:
> I don't see an use case for python2 subpackage, or am I missing something?

This is a good catch. I'll verify this with upstream. But most
probably, you are right. Thank you.

Jan
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: The %license property is now supported in EPEL6

[Petr Pisar]

On 2016-01-20, Jason L Tibbitts III  wrote:
> Just a note that it EPEL6 no longer requires you to include the
> definition of %license property; you can use it freely in your %files
> list as you would in EPEL7 or Fedora.  It simply maps to %doc as it
> would if you had included the magic line noise manually.  This works for
> me in koji; if it doesn't work in your local mock instance, it's
> possible that the mirrors still need to catch up with the change to
> comps.
>
How's that implemented? Does the code come from RHEL? Or does EPEL
modify some RHEL package? Or does it modify comps group? Or does it
modify default mock configuration for EPEL?

-- Petr
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Should 'dnf install gtk3-devel.i686' work?

[Richard W.M. Jones]

On Thu, Jan 21, 2016 at 04:10:00AM +0100, Ralf Corsepius wrote:
> On 01/20/2016 08:23 PM, Richard W.M. Jones wrote:
> >
> >I have filed a bug (against gtk3 for now) about this issue:
> >
> >   https://bugzilla.redhat.com/show_bug.cgi?id=1300432
> 
> I still don't know the cause of this issue, I don't think this is
> gtk3's fault (alone). It's possible to generate similar breakdowns
> for many packages (My gut feeling is, this culprit is dnf).
> 
> Example:
> # dnf install usbguard-devel.i686

I don't know about this package, but for gtk3-devel.i686 I also
tried yum-deprecated with the same results.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

ppisar pushed to perl-Test-Run-CmdLine (f23). "0.0131 bump"

[notifications]

From 9980daf9dcf01ef4ca483efbb22e8162d56b4918 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= 
Date: Thu, 21 Jan 2016 09:53:52 +0100
Subject: 0.0131 bump

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

diff --git a/.gitignore b/.gitignore
index 9f5184e..bd54fab 100644
--- a/.gitignore
+++ b/.gitignore
@@ -2,3 +2,4 @@
 /Test-Run-CmdLine-0.0127.tar.gz
 /Test-Run-CmdLine-0.0128.tar.gz
 /Test-Run-CmdLine-0.0130.tar.gz
+/Test-Run-CmdLine-0.0131.tar.gz
diff --git a/perl-Test-Run-CmdLine.spec b/perl-Test-Run-CmdLine.spec
index 1c5c363..ae06413 100644
--- a/perl-Test-Run-CmdLine.spec
+++ b/perl-Test-Run-CmdLine.spec
@@ -1,5 +1,5 @@
 Name:   perl-Test-Run-CmdLine
-Version:0.0130
+Version:0.0131
 Release:1%{?dist}
 Summary:Run TAP tests from command line using the Test::Run module
 # lib and other code:   MIT
@@ -110,6 +110,9 @@ perl Build.PL installdirs=vendor
 %doc examples
 
 %changelog
+* Thu Jan 21 2016 Petr Pisar  - 0.0131-1
+- 0.0131 bump
+
 * Wed Jan 06 2016 Petr Pisar  - 0.0130-1
 - 0.0130 bump
 
diff --git a/sources b/sources
index dcfc1ca..b73f6bc 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-6f982ffc43181059b75b2fe36d642027  Test-Run-CmdLine-0.0130.tar.gz
+858e6485a6d67cfcb472c82c55e3ea87  Test-Run-CmdLine-0.0131.tar.gz
-- 
cgit v0.11.2



http://pkgs.fedoraproject.org/cgit/perl-Test-Run-CmdLine.git/commit/?h=f23=9980daf9dcf01ef4ca483efbb22e8162d56b4918
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

[Bug 1209911] CVE-2015-3406 perl-Module-Signature: unsigned files interpreted as signed in some circumstances

[bugzilla]

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

Ján Rusnačko  changed:

   What|Removed |Added

 CC||jrusn...@redhat.com
 Whiteboard|impact=moderate,public=2015 |impact=moderate,public=2015
   |0405,reported=20150408,sour |0405,reported=20150408,sour
   |ce=oss-security,cvss2=5.1/A |ce=oss-security,cvss2=5.1/A
   |V:N/AC:H/Au:N/C:P/I:P/A:P,f |V:N/AC:H/Au:N/C:P/I:P/A:P,f
   |edora-all/perl-Module-Signa |edora-all/perl-Module-Signa
   |ture=affected,epel-all/perl |ture=affected,epel-all/perl
   |-Module-Signature=affected, |-Module-Signature=affected,
   |rhel-7/perl-Module-Signatur |rhel-7/perl-Module-Signatur
   |e=wontfix   |e=wontfix,cwe=CWE-347



-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

[Bug 1300602] New: Upgrade perl-Lucy to 0.4.3

[bugzilla]

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

Bug ID: 1300602
   Summary: Upgrade perl-Lucy to 0.4.3
   Product: Fedora
   Version: rawhide
 Component: perl-Lucy
  Keywords: FutureFeature
  Assignee: lkund...@v3.sk
  Reporter: ppi...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: lkund...@v3.sk, perl-devel@lists.fedoraproject.org



Latest Fedora delivers 0.4.2 version. Upstream released 0.4.3. When you have
free time, please uprade it.

Also please enable release monitoring to receive notifications about new
releases.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

[Bug 1300484] perl-Test-Run-CmdLine-0.0131 is available

[bugzilla]

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



--- Comment #5 from Fedora Update System  ---
perl-Test-Run-CmdLine-0.0131-1.fc23 has been submitted as an update to Fedora
23. https://bodhi.fedoraproject.org/updates/FEDORA-2016-7eef79c754

-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

[Bug 1300484] perl-Test-Run-CmdLine-0.0131 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-Test-Run-CmdLine-0.013
   ||1-1.fc24



--- Comment #3 from Petr Pisar  ---
Corrects tests. Suitable for F>23.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

Re: Should 'dnf install gtk3-devel.i686' work?

[Richard W.M. Jones]

On Thu, Jan 21, 2016 at 09:39:38AM +0100, Ralf Corsepius wrote:
> On 01/21/2016 09:27 AM, Richard W.M. Jones wrote:
> >I also
> >tried yum-deprecated with the same results.
>
> I also tried - same result. I guess, investigating this any further
> will require pre-dnf Fedora.

The earliest Fedora I have easy access to in my cloud builder is
Fedora 18.  That was the version which introduced dnf, but I don't
think it was yet the default -- at least 'yum' works in that version
and there is no 'yum-deprecated' command.

I tested it now and the same problem exists with yum in Fedora 18.

Fedora 18 was worse actually because there is a file conflict between
a file in gtk3-devel.{i686,x86_64}, so you have to uninstall
gtk3-devel.x86_64 to do the test.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Should 'dnf install gtk3-devel.i686' work?

[Yanko Kaneti]

On Wed, 2016-01-20 at 15:50 +, Richard W.M. Jones wrote:
> If you're on freshly installed Fedora 23 (x86-64), then
> 
>   dnf install gtk3-devel.x86_64
> ..
> 
> Is this a bug or is it not expected this would work or I am doing it
> wrong?

IMO trying to get this (i686 development environment on x86_64 native
install) to work reliably and chasing down all the corner cases is
futile, leads to confusion instead of improving the developer
experience in any significant way compared to using mock and should be
declared unsupported.

- Yanko
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

ppisar pushed to perl-Module-CoreList (master). "5.20160120 bump"

[notifications]

From c3db40daa1e6a76b7873d061fe878e29823109ba Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= 
Date: Thu, 21 Jan 2016 10:34:24 +0100
Subject: 5.20160120 bump

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

diff --git a/.gitignore b/.gitignore
index 22f08d9..d583061 100644
--- a/.gitignore
+++ b/.gitignore
@@ -19,3 +19,4 @@ Module-CoreList-2.13.tar.gz
 /Module-CoreList-5.20151120.tar.gz
 /Module-CoreList-5.20151213.tar.gz
 /Module-CoreList-5.20151220.tar.gz
+/Module-CoreList-5.20160120.tar.gz
diff --git a/perl-Module-CoreList.spec b/perl-Module-CoreList.spec
index 31ab264..cb2a547 100644
--- a/perl-Module-CoreList.spec
+++ b/perl-Module-CoreList.spec
@@ -1,7 +1,7 @@
 Name:   perl-Module-CoreList
 # Epoch to compete with perl.spec
 Epoch:  1
-Version:5.20151220
+Version:5.20160120
 Release:1%{?dist}
 Summary:What modules are shipped with versions of perl
 License:GPL+ or Artistic
@@ -83,6 +83,9 @@ make test
 %{_mandir}/man1/corelist.*
 
 %changelog
+* Thu Jan 21 2016 Petr Pisar  - 1:5.20160120-1
+- 5.20160120 bump
+
 * Tue Dec 22 2015 Jitka Plesnikova  - 1:5.20151220-1
 - 5.20151220 bump
 
diff --git a/sources b/sources
index 856210b..eda78c0 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-76f6b1584082123ade91d0189477ae5e  Module-CoreList-5.20151220.tar.gz
+227e8d3524b3c6543edbeb372625cdec  Module-CoreList-5.20160120.tar.gz
-- 
cgit v0.11.2



http://pkgs.fedoraproject.org/cgit/perl-Module-CoreList.git/commit/?h=master=c3db40daa1e6a76b7873d061fe878e29823109ba
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

ppisar pushed to perl-Module-CoreList (f23). "5.20160120 bump"

[notifications]

From f5da200cabd9a8cf0291e7701c758961df9c2fe5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= 
Date: Thu, 21 Jan 2016 10:34:24 +0100
Subject: 5.20160120 bump

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

diff --git a/.gitignore b/.gitignore
index 22f08d9..d583061 100644
--- a/.gitignore
+++ b/.gitignore
@@ -19,3 +19,4 @@ Module-CoreList-2.13.tar.gz
 /Module-CoreList-5.20151120.tar.gz
 /Module-CoreList-5.20151213.tar.gz
 /Module-CoreList-5.20151220.tar.gz
+/Module-CoreList-5.20160120.tar.gz
diff --git a/perl-Module-CoreList.spec b/perl-Module-CoreList.spec
index 31ab264..cb2a547 100644
--- a/perl-Module-CoreList.spec
+++ b/perl-Module-CoreList.spec
@@ -1,7 +1,7 @@
 Name:   perl-Module-CoreList
 # Epoch to compete with perl.spec
 Epoch:  1
-Version:5.20151220
+Version:5.20160120
 Release:1%{?dist}
 Summary:What modules are shipped with versions of perl
 License:GPL+ or Artistic
@@ -83,6 +83,9 @@ make test
 %{_mandir}/man1/corelist.*
 
 %changelog
+* Thu Jan 21 2016 Petr Pisar  - 1:5.20160120-1
+- 5.20160120 bump
+
 * Tue Dec 22 2015 Jitka Plesnikova  - 1:5.20151220-1
 - 5.20151220 bump
 
diff --git a/sources b/sources
index 856210b..eda78c0 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-76f6b1584082123ade91d0189477ae5e  Module-CoreList-5.20151220.tar.gz
+227e8d3524b3c6543edbeb372625cdec  Module-CoreList-5.20160120.tar.gz
-- 
cgit v0.11.2



http://pkgs.fedoraproject.org/cgit/perl-Module-CoreList.git/commit/?h=f23=f5da200cabd9a8cf0291e7701c758961df9c2fe5
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

Re: The %license property is now supported in EPEL6

[Jan Chaloupka]

Great!!! Thanks for the good news

On 01/20/2016 10:09 PM, Jason L Tibbitts III wrote:

Just a note that it EPEL6 no longer requires you to include the
definition of %license property; you can use it freely in your %files
list as you would in EPEL7 or Fedora.  It simply maps to %doc as it
would if you had included the magic line noise manually.  This works for
me in koji; if it doesn't work in your local mock instance, it's
possible that the mirrors still need to catch up with the change to
comps.

You'll still need that line noise (for now, at least) in EPEL5.  Next
I'll be looking into whether or not it's actually possible.

  - J<
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

jplesnik uploaded Config-Model-Itself-2.002.tar.gz for perl-Config-Model-Itself

[notifications]

7ff844e759979a81feef30c6f3b7f356  Config-Model-Itself-2.002.tar.gz

http://pkgs.fedoraproject.org/lookaside/pkgs/perl-Config-Model-Itself/Config-Model-Itself-2.002.tar.gz/md5/7ff844e759979a81feef30c6f3b7f356/Config-Model-Itself-2.002.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

Re: Should 'dnf install gtk3-devel.i686' work?

[Ian Malone]

On 21 January 2016 at 09:10, Yanko Kaneti  wrote:
> On Wed, 2016-01-20 at 15:50 +, Richard W.M. Jones wrote:
>> If you're on freshly installed Fedora 23 (x86-64), then
>>
>>   dnf install gtk3-devel.x86_64
>> ..
>>
>> Is this a bug or is it not expected this would work or I am doing it
>> wrong?
>
> IMO trying to get this (i686 development environment on x86_64 native
> install) to work reliably and chasing down all the corner cases is
> futile, leads to confusion instead of improving the developer
> experience in any significant way compared to using mock and should be
> declared unsupported.
>

That would be extremely disappointing.

-- 
imalone
http://ibmalone.blogspot.co.uk
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Should 'dnf install gtk3-devel.i686' work?

[Richard W.M. Jones]

On Thu, Jan 21, 2016 at 11:10:22AM +0200, Yanko Kaneti wrote:
> On Wed, 2016-01-20 at 15:50 +, Richard W.M. Jones wrote:
> > If you're on freshly installed Fedora 23 (x86-64), then
> > 
> >   dnf install gtk3-devel.x86_64
> > ..
> > 
> > Is this a bug or is it not expected this would work or I am doing it
> > wrong?
> 
> IMO trying to get this (i686 development environment on x86_64 native
> install) to work reliably and chasing down all the corner cases is
> futile, leads to confusion instead of improving the developer
> experience in any significant way compared to using mock and should be
> declared unsupported.

The logical consequence of this is we would get rid of multilib
entirely.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

[Bug 1209917] CVE-2015-3408 perl-Module-Signature: arbitrary code execution when verifying module signatures

[bugzilla]

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

Ján Rusnačko  changed:

   What|Removed |Added

 CC||jrusn...@redhat.com
 Whiteboard|impact=moderate,public=2015 |impact=moderate,public=2015
   |0405,reported=20150408,sour |0405,reported=20150408,sour
   |ce=oss-security,cvss2=5.1/A |ce=oss-security,cvss2=5.1/A
   |V:N/AC:H/Au:N/C:P/I:P/A:P,f |V:N/AC:H/Au:N/C:P/I:P/A:P,f
   |edora-all/perl-Module-Signa |edora-all/perl-Module-Signa
   |ture=affected,epel-all/perl |ture=affected,epel-all/perl
   |-Module-Signature=affected, |-Module-Signature=affected,
   |rhel-7/perl-Module-Signatur |rhel-7/perl-Module-Signatur
   |e=wontfix   |e=wontfix,cwe=CWE-77



-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

Re: Should 'dnf install gtk3-devel.i686' work?

[Ralf Corsepius]

On 01/20/2016 05:59 PM, Michael Schwendt wrote:

On Wed, 20 Jan 2016 17:32:52 +0100, Ralf Corsepius wrote:


IMO, this is supposed to work => Bug

The big question would be: Where?


It cannot work as long as gtk3-devel relies on pkgconfig(foo) dependencies
instead of arch-specific explicit Requires.


AFAIU,the problem behind this is, in case of multilibs, there are 
several providers providing non-arched rpm tags:


Example:

# rpm -q -provides -p libXt-devel-1.1.5-2.fc23.i686.rpm
libXt-devel = 1.1.5-2.fc23
libXt-devel(x86-32) = 1.1.5-2.fc23
pkgconfig(xt) = 1.1.5

# rpm -q -provides -p libXt-devel-1.1.5-2.fc23.x86_64.rpm
libXt-devel = 1.1.5-2.fc23
libXt-devel(x86-64) = 1.1.5-2.fc23
pkgconfig(xt) = 1.1.5


Apparently, dnf doesn't resolve such deps correctly, but seem to try to 
resolve such deps either by a "first match" or "primary arch" strategy 
and doesn't take a depchains an "inherited arch" into account:


# dnf remove libICE-devel libSM-devel libX11-devel libXt-devel

# dnf install libXt-devel.i686
...
Installing:
 libICE-devel  x86_64  1.0.9-3.fc23   fedora   54 k
 libSM-devel   x86_64  1.2.2-3.fc23   fedora   17 k
 libX11i6861.6.3-2.fc23   fedora  616 k
 libX11-devel  x86_64  1.6.3-2.fc23   fedora  984 k
 libXt i6861.1.5-2.fc23   fedora  174 k
 libXt-devel   i6861.1.5-2.fc23   fedora  450 k

[note: libICE-devel.i686, libSM-devel.i686 are missing]

Seems to me as if history is repeating - IIRC, we've had this issue in 
early stage of yum, as well ;)


Ralf



--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Should 'dnf install gtk3-devel.i686' work?

[Ralf Corsepius]

On 01/21/2016 09:27 AM, Richard W.M. Jones wrote:

On Thu, Jan 21, 2016 at 04:10:00AM +0100, Ralf Corsepius wrote:

On 01/20/2016 08:23 PM, Richard W.M. Jones wrote:


I have filed a bug (against gtk3 for now) about this issue:

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


I still don't know the cause of this issue, I don't think this is
gtk3's fault (alone). It's possible to generate similar breakdowns
for many packages (My gut feeling is, this culprit is dnf).

Example:
# dnf install usbguard-devel.i686


I don't know about this package, but for gtk3-devel.i686
No prob. This was just a random package with fewer deps than gtk3, I 
picked up for testing.



I also
tried yum-deprecated with the same results.
I also tried - same result. I guess, investigating this any further will 
require pre-dnf Fedora.


Ralf
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

ppisar uploaded Test-Run-CmdLine-0.0131.tar.gz for perl-Test-Run-CmdLine

[notifications]

858e6485a6d67cfcb472c82c55e3ea87  Test-Run-CmdLine-0.0131.tar.gz

http://pkgs.fedoraproject.org/lookaside/pkgs/perl-Test-Run-CmdLine/Test-Run-CmdLine-0.0131.tar.gz/md5/858e6485a6d67cfcb472c82c55e3ea87/Test-Run-CmdLine-0.0131.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

ppisar uploaded Module-CoreList-5.20160120.tar.gz for perl-Module-CoreList

[notifications]

227e8d3524b3c6543edbeb372625cdec  Module-CoreList-5.20160120.tar.gz

http://pkgs.fedoraproject.org/lookaside/pkgs/perl-Module-CoreList/Module-CoreList-5.20160120.tar.gz/md5/227e8d3524b3c6543edbeb372625cdec/Module-CoreList-5.20160120.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

[Bug 1300484] perl-Test-Run-CmdLine-0.0131 is available

[bugzilla]

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



--- Comment #4 from Upstream Release Monitoring 
 ---
ppisar's perl-Test-Run-CmdLine-0.0131-1.fc24 completed
http://koji.fedoraproject.org/koji/buildinfo?buildID=712791

-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

ppisar pushed to perl-Test-Run-CmdLine (master). "0.0131 bump"

[notifications]

From 9980daf9dcf01ef4ca483efbb22e8162d56b4918 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= 
Date: Thu, 21 Jan 2016 09:53:52 +0100
Subject: 0.0131 bump

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

diff --git a/.gitignore b/.gitignore
index 9f5184e..bd54fab 100644
--- a/.gitignore
+++ b/.gitignore
@@ -2,3 +2,4 @@
 /Test-Run-CmdLine-0.0127.tar.gz
 /Test-Run-CmdLine-0.0128.tar.gz
 /Test-Run-CmdLine-0.0130.tar.gz
+/Test-Run-CmdLine-0.0131.tar.gz
diff --git a/perl-Test-Run-CmdLine.spec b/perl-Test-Run-CmdLine.spec
index 1c5c363..ae06413 100644
--- a/perl-Test-Run-CmdLine.spec
+++ b/perl-Test-Run-CmdLine.spec
@@ -1,5 +1,5 @@
 Name:   perl-Test-Run-CmdLine
-Version:0.0130
+Version:0.0131
 Release:1%{?dist}
 Summary:Run TAP tests from command line using the Test::Run module
 # lib and other code:   MIT
@@ -110,6 +110,9 @@ perl Build.PL installdirs=vendor
 %doc examples
 
 %changelog
+* Thu Jan 21 2016 Petr Pisar  - 0.0131-1
+- 0.0131 bump
+
 * Wed Jan 06 2016 Petr Pisar  - 0.0130-1
 - 0.0130 bump
 
diff --git a/sources b/sources
index dcfc1ca..b73f6bc 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-6f982ffc43181059b75b2fe36d642027  Test-Run-CmdLine-0.0130.tar.gz
+858e6485a6d67cfcb472c82c55e3ea87  Test-Run-CmdLine-0.0131.tar.gz
-- 
cgit v0.11.2



http://pkgs.fedoraproject.org/cgit/perl-Test-Run-CmdLine.git/commit/?h=master=9980daf9dcf01ef4ca483efbb22e8162d56b4918
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

ppisar pushed to perl-Module-CoreList (f22). "5.20160120 bump"

[notifications]

From c36bb2d5d25e5b898d4521c8a64a6cc74ae8ea6f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= 
Date: Thu, 21 Jan 2016 10:34:24 +0100
Subject: 5.20160120 bump

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

diff --git a/.gitignore b/.gitignore
index 22f08d9..d583061 100644
--- a/.gitignore
+++ b/.gitignore
@@ -19,3 +19,4 @@ Module-CoreList-2.13.tar.gz
 /Module-CoreList-5.20151120.tar.gz
 /Module-CoreList-5.20151213.tar.gz
 /Module-CoreList-5.20151220.tar.gz
+/Module-CoreList-5.20160120.tar.gz
diff --git a/perl-Module-CoreList.spec b/perl-Module-CoreList.spec
index ff19c1c..028246c 100644
--- a/perl-Module-CoreList.spec
+++ b/perl-Module-CoreList.spec
@@ -1,7 +1,7 @@
 Name:   perl-Module-CoreList
 # Epoch to compete with perl.spec
 Epoch:  1
-Version:5.20151220
+Version:5.20160120
 Release:1%{?dist}
 Summary:What modules are shipped with versions of perl
 License:GPL+ or Artistic
@@ -83,6 +83,9 @@ make test
 %{_mandir}/man1/corelist.*
 
 %changelog
+* Thu Jan 21 2016 Petr Pisar  - 1:5.20160120-1
+- 5.20160120 bump
+
 * Tue Dec 22 2015 Jitka Plesnikova  - 1:5.20151220-1
 - 5.20151220 bump
 
diff --git a/sources b/sources
index 856210b..eda78c0 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-76f6b1584082123ade91d0189477ae5e  Module-CoreList-5.20151220.tar.gz
+227e8d3524b3c6543edbeb372625cdec  Module-CoreList-5.20160120.tar.gz
-- 
cgit v0.11.2



http://pkgs.fedoraproject.org/cgit/perl-Module-CoreList.git/commit/?h=f22=c36bb2d5d25e5b898d4521c8a64a6cc74ae8ea6f
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

Re: Should 'dnf install gtk3-devel.i686' work?

[Ian Malone]

On 21 January 2016 at 14:25, Dennis Gilmore  wrote:

>
> However I  really think we need to sit down and rethink multilib. I would like
> to start by changing the multilib method to runtime. So you only get runtime
> libraries and nothing to build 32 bit apps on 64 bit. For 32 bit building you
> should just use mock, docker, systemd-nspawn or something else. It would mean
> we need to make and ship a i386 docker base image if we say use docker.
>
> We have dropped most multilib support already. Today s390x has multilib with
> s390 and x86_64 multilib with i386.we dropped 32 bit ppc support entirely, we
> are working to drop s390 which will leave x86_64 standing all alone. Given
> changes in technologies since x86_64 first became a thing I think we sit back
> and reevaluate the idea of multilib. Maybe there is better ways to achieve
> what we want today

Successfully build and run 20+ year old programs without having to
completely rewrite them would be one of the things I want today. In
fact it's one of the things I was doing earlier this week.

-- 
imalone
http://ibmalone.blogspot.co.uk
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

[Test-Announce] Fedora 24 Rawhide 20160121 nightly compose nominated for testing

[adamwill]

Announcing the creation of a new nightly release validation test event
for Fedora 24 Rawhide 20160121. Please help run some tests for this
nightly compose if you have time. For more information on nightly
release validation testing, see:
https://fedoraproject.org/wiki/QA:Release_validation_test_plan

Notable package version changes:
pungi - 20160115: 4.0.3-1, 20160121: 4.0.4-1

Test coverage information for the current release can be seen at:
https://www.happyassassin.net/testcase_stats/24

You can see all results, find testing instructions and image download
locations, and enter results on the Summary page:

https://fedoraproject.org/wiki/Test_Results:Fedora_24_Rawhide_20160121_Summary

The individual test result pages are:

https://fedoraproject.org/wiki/Test_Results:Fedora_24_Rawhide_20160121_Installation
https://fedoraproject.org/wiki/Test_Results:Fedora_24_Rawhide_20160121_Base
https://fedoraproject.org/wiki/Test_Results:Fedora_24_Rawhide_20160121_Server
https://fedoraproject.org/wiki/Test_Results:Fedora_24_Rawhide_20160121_Cloud
https://fedoraproject.org/wiki/Test_Results:Fedora_24_Rawhide_20160121_Desktop
https://fedoraproject.org/wiki/Test_Results:Fedora_24_Rawhide_20160121_Security_Lab
https://fedoraproject.org/wiki/Template:Fedora_24_Rawhide_20160121_Download

Thank you for testing!
-- 
Mail generated by relval: https://www.happyassassin.net/wikitcms/
On behalf of: adamwill
___
test-announce mailing list
test-annou...@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/test-annou...@lists.fedoraproject.org
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Should 'dnf install gtk3-devel.i686' work?

[Jonathan Wakely]

On 21/01/16 10:15 -0500, Josh Boyer wrote:

On Thu, Jan 21, 2016 at 10:10 AM, Ian Malone  wrote:

Successfully build and run 20+ year old programs without having to
completely rewrite them would be one of the things I want today. In
fact it's one of the things I was doing earlier this week.


Is there a reason that would not work in mock?


A developer who wants to build a 32-bit program on x86_64 might not
be in the mock group. Their system administrator might not want to
give them access to the mock group, given that it's effectively root,
but might be happy to install foobar-devel.i686 for them.

"gcc -m32" is simpler than using a chroot or container.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Python naming guidelines clarification

[Zbigniew Jędrzejewski-Szmek]

On Thu, Jan 21, 2016 at 02:36:00PM +0100, Jan Včelák wrote:
> On Thu, Jan 21, 2016 at 2:12 PM, Robert Kuska  wrote:
> >> And what is the best current practice if the library contains some
> >> utilities. Should the utilities land in the python{2,3}-name package?
> >> Should it land in both?
> >>
> >> To give you an example, the ripe.atlas.sagan ships a utility
> >> parse_abuf. I'm currently removing it from the package as the upstream
> >> is going to deprecate it with the next release. But theoretically,
> >> should the utility be included in python2-ripe-atlas-sagan as
> >> parse_abuf2 and in python3-ripe-atlas-sagan as parse_abuf? Or would it
> >> be better for instance to create a package ripe-atlas-sagan which will
> >> contain just the Python 3 version of the utility?
> >
> > As I suggested in my email before, package just one version running on
> > Python3 (if supported) when utility provides same functionality whether run
> > with Python3 or Python2.
> >
> > There are special cases when you have to provide bin files for both major
> > versions of python, good example is python-pip (python3-pip installs python3
> > modules, python2-pip installs python2 modules).
> >
> > Here are conventions for naming executables and some mentions about
> > Python2/Python3 executables conflicts:
> > https://fedoraproject.org/wiki/Packaging:Python#Naming
> >
> > I believe that your confusion (you are not alone) is caused by misleading
> > example specfile in python packaging guidelines and lack of verbosity
> > about such cases, I already tried to argue about changing it
> > https://fedorahosted.org/fpc/ticket/558#comment:6
> >
> > Lets assume python project named `example` which ships executable `example`:
> >
> > 1. `example` is pure application, supports Python3 -
> > I package it as `example` with executable `example` running on Python3, all
> > backend libraries will be also packaged under `example` rpm as they are not 
> > meant
> > to be used as libraries in other projects
> >
> > 2. `example` is application and it also ships libraries which may be used in
> > other projects -
> > I package it as `example` which will ship executable `example` running on 
> > Python3,
> > I will build it for both Python2 and Python3 and package its libraries under
> > python2-example and python3-example, (hence `example` will require 
> > `python3-example`)
> >
> > 3. `example` is application with different behaviour for both major python 
> > versions -
> > I package `example` as `python-example` with `python2-example` and 
> > `python3-example`
> > subpackages carrying both backends libraries and executables, unversioned 
> > executable
> > `example` will be packaged under `python2-example` (hence running on 
> > python2).

Yes, this is a very nice description. It would be great this become
part of the guidelines, because this is an issue that comes up quite
often. Current guidelines talk about case 3. prominently, but it
actually quite rare, and most packages are either case 1. or 2.

> > - Original Message -
> >> From: "Jan Včelák" 
> >> To: "Development discussions related to Fedora" 
> >> 
> >> Sent: Thursday, January 21, 2016 12:40:47 PM
> >> Subject: Re: Python naming guidelines clarification
> >>
> >> On Wed, Jan 20, 2016 at 11:54 PM, Zbigniew Jędrzejewski-Szmek wrote:
> >> > Yes, the guidelines apply to the source rpm name too. Those
> >> > srpms should be called python-*, because they contain python libries.

Here I assumed that your package is case 2. It looks like this
from the description. If those modules can be used externally,
than case 2. applies, if they cannot, then case 1. applies.

Zbyszek
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Should 'dnf install gtk3-devel.i686' work?

[Dennis Gilmore]

On Wednesday, January 20, 2016 03:50:03 PM Richard W.M. Jones wrote:
> If you're on freshly installed Fedora 23 (x86-64), then
> 
>   dnf install gtk3-devel.x86_64
> 
> gets you everything you need to compile a simple Gtk3 application[1].
> 
> However on the same host if you do:
> 
>   dnf install gtk3-devel.i686
> 
> then there's a lot missing before you can compile a 32 bit Gtk3
> application[2].  I had to install the following dependencies (found by
> tedious trial-and-error) before I could compile it:
> 
>   dnf -y install
> {pango,pixman,zlib,libpng,expat,mesa-libEGL,libX11,libdrm,libxcb,libXau,lib
> Xdamage,libXfixes,libXxf86vm,libXext,mesa-libGL,libXrender,harfbuzz,graphite
> 2,gdk-pixbuf2,atk,cairo-gobject,libXinerama,libXi,libXrandr,libXcursor,libXc
> omposite,wayland,libwayland-client,libxkbcommon,libwayland-cursor,mesa-libwa
> yland-egl,libepoxy,at-spi2-atk,at-spi2-core,dbus,glib2,glibc}-devel.i686
> 
> Is this a bug or is it not expected this would work or I am doing it wrong?

I am not really sure that people have tested this use case in years. It would 
be interesting to see if yum-deprecated gave you working results. If so then I 
would say it is a dnf bug.

However I  really think we need to sit down and rethink multilib. I would like 
to start by changing the multilib method to runtime. So you only get runtime 
libraries and nothing to build 32 bit apps on 64 bit. For 32 bit building you 
should just use mock, docker, systemd-nspawn or something else. It would mean 
we need to make and ship a i386 docker base image if we say use docker.

We have dropped most multilib support already. Today s390x has multilib with 
s390 and x86_64 multilib with i386.we dropped 32 bit ppc support entirely, we 
are working to drop s390 which will leave x86_64 standing all alone. Given 
changes in technologies since x86_64 first became a thing I think we sit back 
and reevaluate the idea of multilib. Maybe there is better ways to achieve 
what we want today

Dennis
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Should 'dnf install gtk3-devel.i686' work?

[Josh Boyer]

On Thu, Jan 21, 2016 at 10:37 AM, Jonathan Wakely
 wrote:
> On 21/01/16 10:15 -0500, Josh Boyer wrote:
>>
>> On Thu, Jan 21, 2016 at 10:10 AM, Ian Malone  wrote:
>>>
>>> Successfully build and run 20+ year old programs without having to
>>> completely rewrite them would be one of the things I want today. In
>>> fact it's one of the things I was doing earlier this week.
>>
>>
>> Is there a reason that would not work in mock?
>
>
> A developer who wants to build a 32-bit program on x86_64 might not
> be in the mock group. Their system administrator might not want to
> give them access to the mock group, given that it's effectively root,
> but might be happy to install foobar-devel.i686 for them.

True, but that is policy beyond the scope of Fedora, not technical
reasons for it to not be possible.  Also, perhaps such users can use
local KVM guests to build on, etc.  We cannot account for all such
policy decisions various sysadmins make.

> "gcc -m32" is simpler than using a chroot or container.

You're arguing convenience.  I'm not saying that is wrong, but it is
not an answer to the question I asked really.

josh
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

pghmcfc pushed to perl-Perl-Critic (el5). "Clean up and fix FTBFS (..more)"

[notifications]

From 812867b92394e230f1a77d41c41a9cb6f4bff035 Mon Sep 17 00:00:00 2001
From: Paul Howarth 
Date: Thu, 21 Jan 2016 14:39:17 +
Subject: Clean up and fix FTBFS

- Don't rely on the behavior of all() when the list is empty (CPAN RT#63816)
- Fix expected failure count for multiple glob test in
  BuiltinFunctions::RequireGlobFunction, changed with later version of PPI
  (CPAN RT#30139)
- Fix license tag
- Fix source URL to point to MetaCPAN, where it can still be found
- Classify buildreqs by usage
- Run tests with LANG=en_US so spell check works properly
- Drop %defattr, redundant since rpm 4.4
- Don't use macros for commands
- Make %files list more explicit
- Use %{_fixperms} macro rather than our own chmod incantation
---
 .gitignore  |   2 +-
 Perl-Critic-1.05-678628c8.patch |  39 +
 Perl-Critic-1.05-rt30139.patch  |  11 
 perl-Perl-Critic.spec   | 122 
 4 files changed, 137 insertions(+), 37 deletions(-)
 create mode 100644 Perl-Critic-1.05-678628c8.patch
 create mode 100644 Perl-Critic-1.05-rt30139.patch

diff --git a/.gitignore b/.gitignore
index 6d2ff70..567c985 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1 @@
-Perl-Critic-1.05.tar.gz
+/Perl-Critic-[0-9.]*.tar.gz
diff --git a/Perl-Critic-1.05-678628c8.patch b/Perl-Critic-1.05-678628c8.patch
new file mode 100644
index 000..6b8b78c
--- /dev/null
+++ b/Perl-Critic-1.05-678628c8.patch
@@ -0,0 +1,39 @@
+From 678628c8eb4614c45d644f33b6cadf2e9c410e69 Mon Sep 17 00:00:00 2001
+From: Tom Wyant 
+Date: Sat, 11 Dec 2010 08:19:59 +
+Subject: [PATCH] RT #63816: installation fails when using lastest version of
+ List::MoreUtils
+
+The proximate problem is that the behavior of all() when the list is
+empty has changed. Previous behavior (as of List::MoreUtils 0.26,
+anyway) was that all() with an empty list returned false. With
+List::MoreUtils it returns true. But the code relies on the old
+behavior.
+
+Unfortunately, what's really needed is first a review of the
+List::MoreUtils functions used by Perl::Critic, then protection of all
+affected functions. Or maybe just protect them all, to be truly
+paranoid.
+---
+--- lib/Perl/Critic/Policy/TestingAndDebugging/ProhibitNoStrict.pm
 lib/Perl/Critic/Policy/TestingAndDebugging/ProhibitNoStrict.pm
+@@ -61,7 +61,7 @@ sub violates {
+ return if !$stmnt;
+ my @words = split m{ [^a-z]+ }mx, $stmnt;
+ @words = grep { $_ !~ m{ qw|no|strict }mx } @words;
+-return if all { exists $self->{_allow}->{$_} } @words;
++return if @words && all { exists $self->{_allow}->{$_} } @words;
+ 
+ #If we get here, then it must be a violation
+ return $self->violation( $desc, $expl, $elem );
+--- lib/Perl/Critic/Policy/TestingAndDebugging/ProhibitNoWarnings.pm
 lib/Perl/Critic/Policy/TestingAndDebugging/ProhibitNoWarnings.pm
+@@ -61,7 +61,7 @@ sub violates {
+ return if !$stmnt;
+ my @words = split m{ [^a-z]+ }mx, $stmnt;
+ @words = grep { $_ !~ m{ qw|no|warnings }mx } @words;
+-return if all { exists $self->{_allow}->{$_} } @words;
++return if @words && all { exists $self->{_allow}->{$_} } @words;
+ 
+ #If we get here, then it must be a violation
+ return $self->violation( $desc, $expl, $elem );
diff --git a/Perl-Critic-1.05-rt30139.patch b/Perl-Critic-1.05-rt30139.patch
new file mode 100644
index 000..677373e
--- /dev/null
+++ b/Perl-Critic-1.05-rt30139.patch
@@ -0,0 +1,11 @@
+--- t/BuiltinFunctions/RequireGlobFunction.run
 t/BuiltinFunctions/RequireGlobFunction.run
+@@ -17,7 +17,7 @@ foreach my $file (<*.pl>) {
+ #-
+ 
+ ## name Multiple globs via <...>
+-## failures 1
++## failures 2
+ ## cut
+ 
+ @files = (<*.pl>, <*.pm>);
diff --git a/perl-Perl-Critic.spec b/perl-Perl-Critic.spec
index 56e9610..082526c 100644
--- a/perl-Perl-Critic.spec
+++ b/perl-Perl-Critic.spec
@@ -1,37 +1,75 @@
 Name:   perl-Perl-Critic
 Version:1.05
-Release:1%{?dist}
+Release:2%{?dist}
 Summary:Critique Perl source code for best-practices
-
 Group:  Development/Libraries
-License:GPL or Artistic
+License:GPL+ or Artistic
 URL:http://search.cpan.org/dist/Perl-Critic/
-Source0:
http://www.cpan.org/authors/id/T/TH/THALJEF/perlcritic/Perl-Critic-%{version}.tar.gz
-BuildRoot:  %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
-
+Source0:
https://cpan.metacpan.org/authors/id/T/TH/THALJEF/perlcritic/Perl-Critic-%{version}.tar.gz
+Patch0: Perl-Critic-1.05-678628c8.patch
+Patch1: Perl-Critic-1.05-rt30139.patch
+BuildRoot:  %{_tmppath}/%{name}-%{version}-%{release}-root-%(id -nu)
 BuildArch:  noarch
+# Module Build
+BuildRequires:  coreutils
+BuildRequires:  perl
 BuildRequires:  perl(Module::Build)
+# Module Runtime
 BuildRequires:  perl(B::Keywords) >= 1.05

pghmcfc pushed to perl-Perl-Critic (perl-Perl-Critic-1.05-2.el5). "Clean up and fix FTBFS (..more)"

[notifications]

From 812867b92394e230f1a77d41c41a9cb6f4bff035 Mon Sep 17 00:00:00 2001
From: Paul Howarth 
Date: Thu, 21 Jan 2016 14:39:17 +
Subject: Clean up and fix FTBFS

- Don't rely on the behavior of all() when the list is empty (CPAN RT#63816)
- Fix expected failure count for multiple glob test in
  BuiltinFunctions::RequireGlobFunction, changed with later version of PPI
  (CPAN RT#30139)
- Fix license tag
- Fix source URL to point to MetaCPAN, where it can still be found
- Classify buildreqs by usage
- Run tests with LANG=en_US so spell check works properly
- Drop %defattr, redundant since rpm 4.4
- Don't use macros for commands
- Make %files list more explicit
- Use %{_fixperms} macro rather than our own chmod incantation
---
 .gitignore  |   2 +-
 Perl-Critic-1.05-678628c8.patch |  39 +
 Perl-Critic-1.05-rt30139.patch  |  11 
 perl-Perl-Critic.spec   | 122 
 4 files changed, 137 insertions(+), 37 deletions(-)
 create mode 100644 Perl-Critic-1.05-678628c8.patch
 create mode 100644 Perl-Critic-1.05-rt30139.patch

diff --git a/.gitignore b/.gitignore
index 6d2ff70..567c985 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1 @@
-Perl-Critic-1.05.tar.gz
+/Perl-Critic-[0-9.]*.tar.gz
diff --git a/Perl-Critic-1.05-678628c8.patch b/Perl-Critic-1.05-678628c8.patch
new file mode 100644
index 000..6b8b78c
--- /dev/null
+++ b/Perl-Critic-1.05-678628c8.patch
@@ -0,0 +1,39 @@
+From 678628c8eb4614c45d644f33b6cadf2e9c410e69 Mon Sep 17 00:00:00 2001
+From: Tom Wyant 
+Date: Sat, 11 Dec 2010 08:19:59 +
+Subject: [PATCH] RT #63816: installation fails when using lastest version of
+ List::MoreUtils
+
+The proximate problem is that the behavior of all() when the list is
+empty has changed. Previous behavior (as of List::MoreUtils 0.26,
+anyway) was that all() with an empty list returned false. With
+List::MoreUtils it returns true. But the code relies on the old
+behavior.
+
+Unfortunately, what's really needed is first a review of the
+List::MoreUtils functions used by Perl::Critic, then protection of all
+affected functions. Or maybe just protect them all, to be truly
+paranoid.
+---
+--- lib/Perl/Critic/Policy/TestingAndDebugging/ProhibitNoStrict.pm
 lib/Perl/Critic/Policy/TestingAndDebugging/ProhibitNoStrict.pm
+@@ -61,7 +61,7 @@ sub violates {
+ return if !$stmnt;
+ my @words = split m{ [^a-z]+ }mx, $stmnt;
+ @words = grep { $_ !~ m{ qw|no|strict }mx } @words;
+-return if all { exists $self->{_allow}->{$_} } @words;
++return if @words && all { exists $self->{_allow}->{$_} } @words;
+ 
+ #If we get here, then it must be a violation
+ return $self->violation( $desc, $expl, $elem );
+--- lib/Perl/Critic/Policy/TestingAndDebugging/ProhibitNoWarnings.pm
 lib/Perl/Critic/Policy/TestingAndDebugging/ProhibitNoWarnings.pm
+@@ -61,7 +61,7 @@ sub violates {
+ return if !$stmnt;
+ my @words = split m{ [^a-z]+ }mx, $stmnt;
+ @words = grep { $_ !~ m{ qw|no|warnings }mx } @words;
+-return if all { exists $self->{_allow}->{$_} } @words;
++return if @words && all { exists $self->{_allow}->{$_} } @words;
+ 
+ #If we get here, then it must be a violation
+ return $self->violation( $desc, $expl, $elem );
diff --git a/Perl-Critic-1.05-rt30139.patch b/Perl-Critic-1.05-rt30139.patch
new file mode 100644
index 000..677373e
--- /dev/null
+++ b/Perl-Critic-1.05-rt30139.patch
@@ -0,0 +1,11 @@
+--- t/BuiltinFunctions/RequireGlobFunction.run
 t/BuiltinFunctions/RequireGlobFunction.run
+@@ -17,7 +17,7 @@ foreach my $file (<*.pl>) {
+ #-
+ 
+ ## name Multiple globs via <...>
+-## failures 1
++## failures 2
+ ## cut
+ 
+ @files = (<*.pl>, <*.pm>);
diff --git a/perl-Perl-Critic.spec b/perl-Perl-Critic.spec
index 56e9610..082526c 100644
--- a/perl-Perl-Critic.spec
+++ b/perl-Perl-Critic.spec
@@ -1,37 +1,75 @@
 Name:   perl-Perl-Critic
 Version:1.05
-Release:1%{?dist}
+Release:2%{?dist}
 Summary:Critique Perl source code for best-practices
-
 Group:  Development/Libraries
-License:GPL or Artistic
+License:GPL+ or Artistic
 URL:http://search.cpan.org/dist/Perl-Critic/
-Source0:
http://www.cpan.org/authors/id/T/TH/THALJEF/perlcritic/Perl-Critic-%{version}.tar.gz
-BuildRoot:  %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
-
+Source0:
https://cpan.metacpan.org/authors/id/T/TH/THALJEF/perlcritic/Perl-Critic-%{version}.tar.gz
+Patch0: Perl-Critic-1.05-678628c8.patch
+Patch1: Perl-Critic-1.05-rt30139.patch
+BuildRoot:  %{_tmppath}/%{name}-%{version}-%{release}-root-%(id -nu)
 BuildArch:  noarch
+# Module Build
+BuildRequires:  coreutils
+BuildRequires:  perl
 BuildRequires:  perl(Module::Build)
+# Module Runtime
 BuildRequires:  perl(B::Keywords) >= 1.05

Re: Updating hdf5 to 1.8.16 in rawhide today

[Jonathan Wakely]

On 21/01/16 06:52 -0700, Orion Poplawski wrote:

On 01/14/2016 04:25 PM, Orion Poplawski wrote:

On 11/20/2015 02:39 PM, Orion Poplawski wrote:

I'll be updating hdf5 to 1.8.16 in rawhide in the next few days.  This
includes a soname bump for the C++ wrapper libs, but as usual I'll be
rebuilding all deps due to run-time version checking by the library.



Well, the arm build is hanging in a test, so this didn't happen today.  I'll
try to reproduce the test failure to see what's up...


Switching mpich to the nemesis channel on all platforms has cleared 
this up.  hdf5 build has started now and should be done in about 4 
hours. Then I'll start the rest of the rebuilds.


Could the following be rebuilt in the f24-boost side tag, so they use
the new Boost?

Field3D
OpenImageIO
engrid
gdal
mrpt
paraview
vigra
vtk
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Should 'dnf install gtk3-devel.i686' work?

[Josh Boyer]

On Thu, Jan 21, 2016 at 10:10 AM, Ian Malone  wrote:
> On 21 January 2016 at 14:25, Dennis Gilmore  wrote:
>
>>
>> However I  really think we need to sit down and rethink multilib. I would 
>> like
>> to start by changing the multilib method to runtime. So you only get runtime
>> libraries and nothing to build 32 bit apps on 64 bit. For 32 bit building you
>> should just use mock, docker, systemd-nspawn or something else. It would mean
>> we need to make and ship a i386 docker base image if we say use docker.
>>
>> We have dropped most multilib support already. Today s390x has multilib with
>> s390 and x86_64 multilib with i386.we dropped 32 bit ppc support entirely, we
>> are working to drop s390 which will leave x86_64 standing all alone. Given
>> changes in technologies since x86_64 first became a thing I think we sit back
>> and reevaluate the idea of multilib. Maybe there is better ways to achieve
>> what we want today
>
> Successfully build and run 20+ year old programs without having to
> completely rewrite them would be one of the things I want today. In
> fact it's one of the things I was doing earlier this week.

Is there a reason that would not work in mock?

josh
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

[EPEL-devel] Re: EPEL5 mass rebuild (2016-01-20, 179 failures)

[Paul Howarth]

On 21/01/16 00:49, Jason L Tibbitts III wrote:
...

Failures in %check: 12
ccache-2.4-21.el5.src.rpm (adev)
heimdal-1.6.0-0.9.20140621gita5adc06.el5.src.rpm (ktdreyer)
libresample-0.1.3-7.el5.src.rpm (jcollie)
perl-Calendar-Simple-1.17-2.el5.src.rpm (laxathom)
perl-Email-Abstract-2.132-4.el5.2.src.rpm (spot)


This is failing due to a missing dependency perl(User::Identity) in 
perl-Mail-Box.



perl-Gearman-Client-Async-0.94-3.el5.src.rpm (psabata)
perl-PDL-2.4.3-5.el5.src.rpm (mmaslano, rnorwood, jplesnik)
perl-Perl-Critic-1.05-1.el5.src.rpm (rmyers, pghmcfc)


I have patched this (1 fix for code, 1 for test suite) and pushed an 
update. It had been broken by changes in the List::MoreUtils module.


Paul.
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

Re: Should 'dnf install gtk3-devel.i686' work?

[Jan Kratochvil]

On Thu, 21 Jan 2016 16:37:01 +0100, Jonathan Wakely wrote:
> A developer who wants to build a 32-bit program on x86_64 might not
> be in the mock group. Their system administrator might not want to

Aren't the multiuser systems a history now with VPSes or even just containers
cheaper than a hamburger?  Moreover for anyone with any special requirements.


Jan
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Should 'dnf install gtk3-devel.i686' work?

[Jonathan Wakely]

On 21/01/16 16:49 +0100, Jan Kratochvil wrote:

On Thu, 21 Jan 2016 16:37:01 +0100, Jonathan Wakely wrote:

A developer who wants to build a 32-bit program on x86_64 might not
be in the mock group. Their system administrator might not want to


Aren't the multiuser systems a history now with VPSes or even just containers
cheaper than a hamburger?  Moreover for anyone with any special requirements.


They weren't history two years ago at my last job, but that's two
years ago so maybe they are now.

In many large firms in slow-moving industries two years is not very
long, but they wouldn't be developing on Fedora anyway.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Should 'dnf install gtk3-devel.i686' work?

[Sérgio Basto]

On Qui, 2016-01-21 at 08:25 -0600, Dennis Gilmore wrote:
> 
> I am not really sure that people have tested this use case in years.
> It would 
> be interesting to see if yum-deprecated gave you working results. If
> so then I 
> would say it is a dnf bug.

Is not a dnf bug 

Somehow 
dnf repoquery --provides  gtk3-devel.x86_64 
(or rpm -q --provides gtk3-devel.x86_64 ) 
and 
dnf repoquery --provides  gtk3-devel.i686

should provides different pkgconfig(s), instead the same, for example: 
pkgconfig(gail-3.0) = 3.18.2 

if gtk3-devel.x86_64 and gtk3-devel.i686 provides the same pkgconfig ,
is not possible for dnf or yum choose the correct package. 


-- 
Sérgio M. B.

--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Fedora Rawhide 20160121 compose check report

[Fedora compose checker]

Missing expected images:

Kde disk raw armhfp
Kde live i386
Kde live x86_64

No images in this compose but not Rawhide 20160120

No images in Rawhide 20160120 but not this.

Failed openQA tests: 53 of 63

ID: 3570Test: x86_64 universal server_mirrorlist_graphical
URL: https://openqa.fedoraproject.org/tests/3570
ID: 3569Test: x86_64 universal server_repository_http_graphical
URL: https://openqa.fedoraproject.org/tests/3569
ID: 3568Test: x86_64 universal server_repository_http_variation
URL: https://openqa.fedoraproject.org/tests/3568
ID: 3546Test: x86_64 universal server_sata_multi
URL: https://openqa.fedoraproject.org/tests/3546
ID: 3545Test: x86_64 universal server_scsi_updates_img
URL: https://openqa.fedoraproject.org/tests/3545
ID: 3543Test: x86_64 universal server_delete_pata@uefi
URL: https://openqa.fedoraproject.org/tests/3543
ID: 3542Test: x86_64 universal server_delete_pata
URL: https://openqa.fedoraproject.org/tests/3542
ID: 3598Test: i386 generic_boot default_install
URL: https://openqa.fedoraproject.org/tests/3598
ID: 3594Test: x86_64 generic_boot default_install@uefi
URL: https://openqa.fedoraproject.org/tests/3594
ID: 3593Test: x86_64 generic_boot default_install
URL: https://openqa.fedoraproject.org/tests/3593
ID: 3547Test: x86_64 universal server_sata_multi@uefi
URL: https://openqa.fedoraproject.org/tests/3547
ID: 3601Test: x86_64 workstation_live default_install@uefi
URL: https://openqa.fedoraproject.org/tests/3601
ID: 3600Test: x86_64 workstation_live default_install
URL: https://openqa.fedoraproject.org/tests/3600
ID: 3599Test: i386 workstation_live default_install
URL: https://openqa.fedoraproject.org/tests/3599
ID: 3586Test: i386 universal server_repository_http_graphical
URL: https://openqa.fedoraproject.org/tests/3586
ID: 3587Test: i386 universal server_scsi_updates_img
URL: https://openqa.fedoraproject.org/tests/3587
ID: 3550Test: x86_64 universal server_multi_empty
URL: https://openqa.fedoraproject.org/tests/3550
ID: 3549Test: x86_64 universal server_simple_free_space
URL: https://openqa.fedoraproject.org/tests/3549
ID: 3548Test: x86_64 universal server_simple_encrypted
URL: https://openqa.fedoraproject.org/tests/3548
ID: 3567Test: x86_64 universal package_set_minimal
URL: https://openqa.fedoraproject.org/tests/3567
ID: 3552Test: x86_64 universal server_delete_partial
URL: https://openqa.fedoraproject.org/tests/3552
ID: 3551Test: x86_64 universal server_software_raid
URL: https://openqa.fedoraproject.org/tests/3551
ID: 3559Test: x86_64 universal server_simple_encrypted@uefi
URL: https://openqa.fedoraproject.org/tests/3559
ID: 3562Test: x86_64 universal server_software_raid@uefi
URL: https://openqa.fedoraproject.org/tests/3562
ID: 3561Test: x86_64 universal server_multi_empty@uefi
URL: https://openqa.fedoraproject.org/tests/3561
ID: 3560Test: x86_64 universal server_simple_free_space@uefi
URL: https://openqa.fedoraproject.org/tests/3560
ID: 3563Test: x86_64 universal server_delete_partial@uefi
URL: https://openqa.fedoraproject.org/tests/3563
ID: 3588Test: i386 universal server_simple_encrypted
URL: https://openqa.fedoraproject.org/tests/3588
ID: 3585Test: i386 universal package_set_minimal
URL: https://openqa.fedoraproject.org/tests/3585
ID: 3589Test: i386 universal server_software_raid
URL: https://openqa.fedoraproject.org/tests/3589
ID: 3555Test: x86_64 universal server_xfs
URL: https://openqa.fedoraproject.org/tests/3555
ID: 3554Test: x86_64 universal server_ext3
URL: https://openqa.fedoraproject.org/tests/3554
ID: 3553Test: x86_64 universal server_btrfs
URL: https://openqa.fedoraproject.org/tests/3553
ID: 3575Test: x86_64 universal upgrade_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/3575
ID: 3556Test: x86_64 universal server_lvmthin
URL: https://openqa.fedoraproject.org/tests/3556
ID: 3581Test: x86_64 universal european_language_install
URL: https://openqa.fedoraproject.org/tests/3581
ID: 3580Test: x86_64 universal server_shrink_ntfs
URL: https://openqa.fedoraproject.org/tests/3580
ID: 3579Test: x86_64 universal server_shrink_ext4
URL: https://openqa.fedoraproject.org/tests/3579
ID: 3578Test: x86_64 universal server_updates_img_local
URL: https://openqa.fedoraproject.org/tests/3578
ID: 3582Test: i386 universal upgrade_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/3582
ID: 3564Test: x86_64 universal server_btrfs@uefi
URL: https://openqa.fedoraproject.org/tests/3564
ID: 3565Test: x86_64 universal server_ext3@uefi
URL: https://openqa.fedoraproject.org/tests/3565
ID: 3566Test: x86_64 universal server_xfs@uefi
URL: https://openqa.fedoraproject.org/tests/3566
ID: 3592Test: i386 universal server_lvmthin
URL: 

Re: How to test appdata for a package?

[Richard Shaw]

Coming back around to this...

I have made sure that gnome-software wasn't already running, did
appstream-util validate (no relaxed and fixed all output), and I still
can't get it to show up in gnome-software after installing the resultant
RPM...

Any other ideas? I would really like a method to visually review the
results prior to building official packages.

Thanks,
Richard
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Should 'dnf install gtk3-devel.i686' work?

[Richard W.M. Jones]

On Thu, Jan 21, 2016 at 04:36:33PM +, Sérgio Basto wrote:
> On Qui, 2016-01-21 at 08:25 -0600, Dennis Gilmore wrote:
> > 
> > I am not really sure that people have tested this use case in years.
> > It would 
> > be interesting to see if yum-deprecated gave you working results. If
> > so then I 
> > would say it is a dnf bug.
> 
> Is not a dnf bug 
> 
> Somehow 
> dnf repoquery --provides  gtk3-devel.x86_64 
> (or rpm -q --provides gtk3-devel.x86_64 ) 
> and 
> dnf repoquery --provides  gtk3-devel.i686
> 
> should provides different pkgconfig(s), instead the same, for example: 
> pkgconfig(gail-3.0) = 3.18.2 
> 
> if gtk3-devel.x86_64 and gtk3-devel.i686 provides the same pkgconfig ,
> is not possible for dnf or yum choose the correct package. 

Correct - I've shown elsewhere in the thread that this bug exists in
yum, at least as far back as yum from Fedora 18.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Should 'dnf install gtk3-devel.i686' work?

[Jonathan Wakely]

On 21/01/16 10:52 -0500, Josh Boyer wrote:

On Thu, Jan 21, 2016 at 10:37 AM, Jonathan Wakely
 wrote:

On 21/01/16 10:15 -0500, Josh Boyer wrote:


On Thu, Jan 21, 2016 at 10:10 AM, Ian Malone  wrote:


Successfully build and run 20+ year old programs without having to
completely rewrite them would be one of the things I want today. In
fact it's one of the things I was doing earlier this week.



Is there a reason that would not work in mock?



A developer who wants to build a 32-bit program on x86_64 might not
be in the mock group. Their system administrator might not want to
give them access to the mock group, given that it's effectively root,
but might be happy to install foobar-devel.i686 for them.


True, but that is policy beyond the scope of Fedora, not technical
reasons for it to not be possible.  Also, perhaps such users can use
local KVM guests to build on, etc.  We cannot account for all such
policy decisions various sysadmins make.


But if Fedora stops shipping 32-bit -devel packages that doesn't let
the admins choose the policy, they *must* tell their users to use mock
or containers.


"gcc -m32" is simpler than using a chroot or container.


You're arguing convenience.  I'm not saying that is wrong, but it is
not an answer to the question I asked really.


True, but it's an answer to "Is there a reason *a developer using
Fedora* would *choose to* not work in mock"  :-)

Removing multilib -devel packages dictates a particular way of working
on developers, which I find a bit surprising.

I hope at least the glibc-devel.i686 package would remain, or I would
find it more difficult to use Fedora for my upstream GCC development
(which *does* support multilib, and will continue to do so whatever
Fedora does).
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Should 'dnf install gtk3-devel.i686' work?

[Matthew Miller]

On Thu, Jan 21, 2016 at 04:49:21PM +0100, Jan Kratochvil wrote:
> Aren't the multiuser systems a history now with VPSes or even just
> containers cheaper than a hamburger? Moreover for anyone with any
> special requirements.

No. They are incredibly common in schools and in high performance
computing.

-- 
Matthew Miller

Fedora Project Leader
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: bodhi - new update obsoleted an older update that had been submitted for stable

[Paul W. Frields]

On Wed, Jan 20, 2016 at 08:22:29PM -0500, Josh Boyer wrote:
> On Wed, Jan 20, 2016 at 7:38 PM, Luke Macken  wrote:
> > On Wed, Jan 20, 2016 at 07:17:10AM -0500, Josh Boyer wrote:
> >> On Wed, Jan 20, 2016 at 5:55 AM, Richard Fearn  
> >> wrote:
> >> > Hi,
> >> >
> >> >> https://github.com/fedora-infra/bodhi/issues/763
> >> >
> >> > You beat me to it :) Thanks for doing that!
> >> >
> >> > And Luke seems to have fixed the problem already. Thanks Luke!
> >>
> >> He fixed the code, but it isn't merged yet nor is it deployed in
> >> Fedora Infrastructure from what I can tell.
> >
> > The fix is now in production.
> >
> > Sorry about the annoying regression, folks. Bodhi previously would avoid
> > obsoleting updates that had an open request, even if it hasn't gotten
> > pulled into a push yet. A recent improvement to this logic allows for
> > updates with a testing request to get obsoleted if a newer update gets
> > submitted before it gets "locked" into a push. The bug that snuck in
> > allowed this to happen to unlocked updates with a stable request too.
> 
> Thanks for the explanation and the quick fix, Luke.

+1, thanks Luke!

-- 
Paul W. Frieldshttp://paul.frields.org/
  gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233  5906 ACDB C937 BD11 3717
  http://redhat.com/   -  -  -  -   http://pfrields.fedorapeople.org/
The open source story continues to grow: http://opensource.com
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Updating hdf5 to 1.8.16 in rawhide today

[Orion Poplawski]

On 01/21/2016 08:07 AM, Jonathan Wakely wrote:
> On 21/01/16 06:52 -0700, Orion Poplawski wrote:
>> On 01/14/2016 04:25 PM, Orion Poplawski wrote:
>>> On 11/20/2015 02:39 PM, Orion Poplawski wrote:
 I'll be updating hdf5 to 1.8.16 in rawhide in the next few days.  This
 includes a soname bump for the C++ wrapper libs, but as usual I'll be
 rebuilding all deps due to run-time version checking by the library.

>>>
>>> Well, the arm build is hanging in a test, so this didn't happen today.  I'll
>>> try to reproduce the test failure to see what's up...
>>
>> Switching mpich to the nemesis channel on all platforms has cleared this
>> up.  hdf5 build has started now and should be done in about 4 hours. Then
>> I'll start the rest of the rebuilds.
> 
> Could the following be rebuilt in the f24-boost side tag, so they use
> the new Boost?
> 
> Field3D
> OpenImageIO
> engrid
> gdal
> mrpt
> paraview
> vigra
> vtk

Will do


-- 
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301   http://www.nwra.com
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fedora Rawhide 20160121 compose check report

[Adam Williamson]

On Thu, 2016-01-21 at 16:36 +, Fedora compose checker wrote:
> Missing expected images:
> 
> Kde disk raw armhfp
> Kde live i386
> Kde live x86_64
> 
> No images in this compose but not Rawhide 20160120
> 
> No images in Rawhide 20160120 but not this.
> 
> Failed openQA tests: 53 of 63

Sigh - bring in the usual suspects: cantarell and gtk3 changed in
today's compose. As usual, I'll re-do the needles and re-launch the
tests.
-- 
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
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

[389-devel] Jenkins build is back to normal : 389-ds-base #860

[jenkins]

See 
--
389-devel mailing list
389-devel@%(host_name)s
http://lists.fedoraproject.org/admin/lists/389-devel@lists.fedoraproject.org

[389-devel] Build failed in Jenkins: 389-ds-base #859

[jenkins]

See 

Changes:

[Noriko Hosoi] Ticket #48144 - Add /usr/sbin/status-dirsrv script to get the 
status of

[Noriko Hosoi] Ticket #48144 - Add /usr/sbin/status-dirsrv script to get the 
status of

--
Started by an SCM change
Building remotely on F22 (Fedora22 fedora Fedora fedora22) in workspace 

Wiping out workspace first.
Cloning the remote Git repository
Cloning repository git://git.fedorahosted.org/git/389/ds.git
 > git init  # 
 > timeout=10
Fetching upstream changes from git://git.fedorahosted.org/git/389/ds.git
 > git --version # timeout=10
 > git -c core.askpass=true fetch --tags --progress 
 > git://git.fedorahosted.org/git/389/ds.git +refs/heads/*:refs/remotes/origin/*
 > git config remote.origin.url git://git.fedorahosted.org/git/389/ds.git # 
 > timeout=10
 > git config --add remote.origin.fetch +refs/heads/*:refs/remotes/origin/* # 
 > timeout=10
 > git config remote.origin.url git://git.fedorahosted.org/git/389/ds.git # 
 > timeout=10
Fetching upstream changes from git://git.fedorahosted.org/git/389/ds.git
 > git -c core.askpass=true fetch --tags --progress 
 > git://git.fedorahosted.org/git/389/ds.git +refs/heads/*:refs/remotes/origin/*
 > git rev-parse origin/master^{commit} # timeout=10
Checking out Revision 68659b64ce8ecb12a62d0984ed026e6dd3fc73ec (origin/master)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 68659b64ce8ecb12a62d0984ed026e6dd3fc73ec
 > git rev-list 5e689f8d61eff1c4f5173592c8310aeae11cc164 # timeout=10
[389-ds-base] $ /bin/sh -e /tmp/hudson4253224827408594362.sh

Running configure...
CFLAGS= -Wall CXXFLAGS= -Wall ./configure --with-tmpfiles-d=/etc/tmpfiles.d 
--with-openldap --enable-autobind --enable-gcc-security --with-selinux 
--with-systemdsystemunitdir=/lib/systemd/system 
--with-systemdsystemconfdir=/etc/systemd/system --enable-debug
Build log is 
http://jenkins.fedorainfracloud.org/job/389-ds-base/ws/build.859.txt

Running make...
Build log is 
http://jenkins.fedorainfracloud.org/job/389-ds-base/ws/build.859.txt
Build http://jenkins.fedorainfracloud.org/job/389-ds-base/859/ failed
Last 100 lines of build log:

mv -f ldap/servers/slapd/.deps/ns_slapd-detach.Tpo 
ldap/servers/slapd/.deps/ns_slapd-detach.Po
gcc -DHAVE_CONFIG_H -I.  -g3 -DDEBUG -DMCC_DEBUG -Wall -Wp,-D_FORITY_SOURCE=2 
-fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 
-grecord-gcc-switches -Werror=format-security 
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1   -DBUILD_NUM=\"2016.021.186\" 
-DVENDOR="\"389 Project\"" -DBRAND="\"389\"" -DCAPBRAND="\"389\"" 
-UPACKAGE_VERSION -UPACKAGE_TARNAME -UPACKAGE_STRING -UPACKAGE_BUGREPORT 
-I./ldap/include -I./ldap/servers/slapd -I./include -I.  
-DLOCALSTATEDIR="\"/opt/dirsrv/var\"" -DSYSCONFDIR="\"/opt/dirsrv/etc\"" 
-DLIBDIR="\"/opt/dirsrv/lib\"" -DBINDIR="\"/opt/dirsrv/bin\"" 
-DDATADIR="\"/opt/dirsrv/share\"" 
-DDOCDIR="\"/opt/dirsrv/share/doc/389-ds-base\"" 
-DSBINDIR="\"/opt/dirsrv/sbin\"" 
-DPLUGINDIR="\"/opt/dirsrv/lib/dirsrv/plugins\"" 
-DTEMPLATEDIR="\"/opt/dirsrv/share/dirsrv/data\""  -I/usr/include/sasl 
-I/usr/include  -I/usr/include/nss3 -I/usr/include/nspr4 -I/usr/include/nspr4  
-I/usr/include-Wall -MT ldap/servers/slapd/ns_slapd-extendop.o -MD -MP -MF 
ldap/servers/slapd/.deps/ns_slapd-extendop.Tpo -c -o 
ldap/servers/slapd/ns_slapd-extendop.o `test -f 'ldap/servers/slapd/extendop.c' 
|| echo './'`ldap/servers/slapd/extendop.c
mv -f ldap/servers/slapd/.deps/ns_slapd-extendop.Tpo 
ldap/servers/slapd/.deps/ns_slapd-extendop.Po
gcc -DHAVE_CONFIG_H -I.  -g3 -DDEBUG -DMCC_DEBUG -Wall -Wp,-D_FORITY_SOURCE=2 
-fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 
-grecord-gcc-switches -Werror=format-security 
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1   -DBUILD_NUM=\"2016.021.186\" 
-DVENDOR="\"389 Project\"" -DBRAND="\"389\"" -DCAPBRAND="\"389\"" 
-UPACKAGE_VERSION -UPACKAGE_TARNAME -UPACKAGE_STRING -UPACKAGE_BUGREPORT 
-I./ldap/include -I./ldap/servers/slapd -I./include -I.  
-DLOCALSTATEDIR="\"/opt/dirsrv/var\"" -DSYSCONFDIR="\"/opt/dirsrv/etc\"" 
-DLIBDIR="\"/opt/dirsrv/lib\"" -DBINDIR="\"/opt/dirsrv/bin\"" 
-DDATADIR="\"/opt/dirsrv/share\"" 
-DDOCDIR="\"/opt/dirsrv/share/doc/389-ds-base\"" 
-DSBINDIR="\"/opt/dirsrv/sbin\"" 
-DPLUGINDIR="\"/opt/dirsrv/lib/dirsrv/plugins\"" 
-DTEMPLATEDIR="\"/opt/dirsrv/share/dirsrv/data\""  -I/usr/include/sasl 
-I/usr/include  -I/usr/include/nss3 -I/usr/include/nspr4 -I/usr/include/nspr4  
-I/usr/include-Wall -MT ldap/servers/slapd/ns_slapd-fedse.o -MD -MP -MF 
ldap/servers/slapd/.deps/ns_slapd-fedse.Tpo -c -o 
ldap/servers/slapd/ns_slapd-fedse.o `test -f 'ldap/servers/slapd/fedse.c' || 
echo './'`ldap/servers/slapd/fedse.c
mv -f ldap/servers/slapd/.deps/ns_slapd-fedse.Tpo 

Re: Should 'dnf install gtk3-devel.i686' work?

[Matthew Miller]

On Thu, Jan 21, 2016 at 11:37:36AM -0500, Matthew Miller wrote:
> > Aren't the multiuser systems a history now with VPSes or even just
> > containers cheaper than a hamburger? Moreover for anyone with any
> > special requirements.
> No. They are incredibly common in schools and in high performance
> computing.

And, you might say "But, really, Fedora for that?" -- well, yes. It's
reasonably common to provide a Fedora system as a login node because of
access to the wider amount of pre-packaged software and newer versions
of stuff.

-- 
Matthew Miller

Fedora Project Leader
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Embedding javascript in binary

[Christopher]

On Thu, Jan 21, 2016 at 2:03 PM Sander Hoentjen  wrote:

> On 01/21/2016 12:29 AM, Christopher wrote:
> > On Wed, Jan 20, 2016 at 12:34 PM Sander Hoentjen  > > wrote:
> > [snip]
> >
> > > https://fedoraproject.org/wiki/Packaging:JavaScript
> > Yeah I read that, but is says "Please note that this section
> > really only
> > applies to JavaScript libraries intended for use on the web." so I am
> > not sure that applies to my case.
> >
> >
> > It also doesn't thoroughly cover these use cases:
> >
> > 1. how to handle customized embedded forks of a JavaScript library in
> > upstream,
> >
> > 2. how to deal with JavaScript resources which upstream Java packages
> > embed in their WARs (should the maintainer have to rewrite significant
> > portions of upstream code to make these resources available from
> > another location in the filesystem?),
> >
> > 3. applications which require the same shared JavaScript resources but
> > with slightly different flags set in the source (to control style, or
> > behavior),
> >
> > 4. how to package a single upstream project which many projects use
> > which contains a combination of images, styles, JavaScript, and other
> > resources, in a well-known hierarchical structure (like Bootstrap)
> So do you have any ideas regarding these issues?
> Would it be ok for my case if upstream provides both minified and src js?
> How could I check if the minified one is indeed gotten from the src js?
> Or do I always have to re-minify js?
> Is included jquery okay or do I have to use the jquery that is already
> packaged?
>
>
Unfortunately, no. I don't have answers for how to deal with these cases.
However, I do think that minification should always be done as part of the
build, and any upstream minified source should not be used at all, as it's
not free and open source software.

As for jQuery, js-jquery and the older js-jquery1 are already packaged in
Fedora. Hopefully you can figure out how to make your package use those
instead of embed its own.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Gnome keyring security in Fedora

[Christopher]

I've been thinking about Gnome keyring a lot lately, and I have concerns
about security, and I don't know if this is a Gnome keyring problem, or a
problem affecting Fedora specifically.

In short, it doesn't look like Gnome keyring has the ability to notify a
user interactively when a password is read from an unlocked keyring (or to
dynamically unlock it with a master passphrase upon request). Is this
correct? If so, it puts it behind NSS features that Firefox and other apps
use to store passwords and other credentials. However, if it's just
something specific which isn't packaged for Fedora, or isn't installed by
default, that would be very good to know.

In the past, seahorse-plugins provided a gpg-agent with a tool for
configuring cache preferences. It looks like seahorse-plugins is no longer
packaged for Fedora, and gpg2 integrates with seahorse/gnome keyring
differently (I don't know how). At least for GPG passphrases, this provided
some UI to notify the user upon programmatic access to the cached
credentials, and provided an notification icon whenever the cache was
non-empty. It also provided a customizable timer for the cache.

Although they didn't help for non-GPG credentials, these features of
seahorse-plugins provided important (essential, I would say) security for a
GPG credential cache (and, I would argue, essential for any private
credential store). However, these appear to have been lost in Fedora,
making Fedora less secure. Does anybody know about this? Do these features
have replacements which I'm not aware of? If so, why aren't they installed
in Fedora by default?

Is this downgrade in security a Fedora problem, or is it a Gnome problem,
or a seahorse problem? Are there alternatives? NSS seems to be getting some
of this right, but doesn't have good integration with Gnome/Seahorse/GPG.

Thoughts?

--
Christopher
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

F24 Self Contained Change: Atomic Developer Mode

[Jan Kurik]

= Proposed Self Contained Change: Atomic Developer Mode =
https://fedoraproject.org/wiki/Changes/Atomic_Developer_Mode

Change owner(s):
* Jonathan Lebon < jlebon AT redhat DOT com>

Add a "Developer Mode" boot menu entry in the Atomic image to allow
users to boot without setting up cloud-init.

== Detailed Description ==
The high-level goal of Atomic Developer Mode is to make the Fedora
Atomic Host image more accessible by providing a new GRUB 2 menu item
labeled e.g. "Fedora 24 (Twenty Four) Developer Mode". This mode is an
attempt to provide a painless experience for folks who want to try out
Atomic but (1) do not want to bother setting up a cloud-init
datasource, or (2) do not know anything about cloud-init, or even (3)
do not have much experience with Linux overall. They just want to try
out e.g. /usr/bin/atomic, /usr/bin/docker, or play with the Cockpit
console.

Since the functionality is completely integrated into the image, there
are no requirements on the host system, other than its ability to boot
VMs. When booted in Developer Mode, the following happens:

* cloud-init uses a local built-in datasource
* a new root password is generated
* the root user is automatically logged in on tty1
* the cockpit/ws image is downloaded and started
* a tmux session is started on tty1 to provide all the relevant
information (root password, IP address, Cockpit console address)

More information and discussion can be found on the Cloud SIG mailing list


== Scope ==
Proposal owners:
* Create an atomic-devmode package to hold the helper files needed for
this feature -- DONE
* Add the atomic-devmode package to the Fedora repos
* Submit the necessary changes to repos related with tree and image creation:
  1. Submit a patch to fedora-atomic to have the atomic-devmode
package part of the default tree compose
  2. Submit a patch to spin-kickstarts to have the boot menu item
added in the kickstart %post
* Work with projectatomic.io maintainers to properly present Atomic
Developer Mode (including updating the Quick Start Guide)

Other developers: N/A (not a System Wide Change)

Release engineering: N/A (not a System Wide Change)

Policies and guidelines: N/A (not a System Wide Change)

Trademark approval: N/A (not needed for this Change)
-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

F24 Self Contained Change: Atomic Developer Mode

[Jan Kurik]

= Proposed Self Contained Change: Atomic Developer Mode =
https://fedoraproject.org/wiki/Changes/Atomic_Developer_Mode

Change owner(s):
* Jonathan Lebon < jlebon AT redhat DOT com>

Add a "Developer Mode" boot menu entry in the Atomic image to allow
users to boot without setting up cloud-init.

== Detailed Description ==
The high-level goal of Atomic Developer Mode is to make the Fedora
Atomic Host image more accessible by providing a new GRUB 2 menu item
labeled e.g. "Fedora 24 (Twenty Four) Developer Mode". This mode is an
attempt to provide a painless experience for folks who want to try out
Atomic but (1) do not want to bother setting up a cloud-init
datasource, or (2) do not know anything about cloud-init, or even (3)
do not have much experience with Linux overall. They just want to try
out e.g. /usr/bin/atomic, /usr/bin/docker, or play with the Cockpit
console.

Since the functionality is completely integrated into the image, there
are no requirements on the host system, other than its ability to boot
VMs. When booted in Developer Mode, the following happens:

* cloud-init uses a local built-in datasource
* a new root password is generated
* the root user is automatically logged in on tty1
* the cockpit/ws image is downloaded and started
* a tmux session is started on tty1 to provide all the relevant
information (root password, IP address, Cockpit console address)

More information and discussion can be found on the Cloud SIG mailing list


== Scope ==
Proposal owners:
* Create an atomic-devmode package to hold the helper files needed for
this feature -- DONE
* Add the atomic-devmode package to the Fedora repos
* Submit the necessary changes to repos related with tree and image creation:
  1. Submit a patch to fedora-atomic to have the atomic-devmode
package part of the default tree compose
  2. Submit a patch to spin-kickstarts to have the boot menu item
added in the kickstart %post
* Work with projectatomic.io maintainers to properly present Atomic
Developer Mode (including updating the Quick Start Guide)

Other developers: N/A (not a System Wide Change)

Release engineering: N/A (not a System Wide Change)

Policies and guidelines: N/A (not a System Wide Change)

Trademark approval: N/A (not needed for this Change)
-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel-announce mailing list
devel-announce@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel-announce@lists.fedoraproject.org

[Bug 1300870] New: fusioninventory-agent-2.3.18-rc1 is available

[bugzilla]

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

Bug ID: 1300870
   Summary: fusioninventory-agent-2.3.18-rc1 is available
   Product: Fedora
   Version: rawhide
 Component: fusioninventory-agent
  Keywords: FutureFeature, Triaged
  Assignee: maria...@tuxette.fr
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: maria...@tuxette.fr,
perl-devel@lists.fedoraproject.org



Latest upstream release: 2.3.18-rc1
Current version/release in rawhide: 2.3.17-1.fc24
URL: http://www.fusioninventory.org/

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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

[EPEL-devel] EPEL-ANNOUNCE python-psutil-2.2.1 in epel7

[Ralph Bean]

Hello all,

python-psutil-2.2.1 has been in epel7-testing for over a month now,
and I intend to push it to stable in the coming weeks.  It is needed
for the letsencrypt tools.

There are a few small incompatibilities, but none of the dependencies
that we found in EPEL7 itself would be affected.  Of course, there
could be software not in EPEL7 that uses this package.. but that's why
we're taking our time before pushing this update to stable.

Please test the bodhi update when you can, so we can make way for
letsencrypt[1].

-Ralph

[1] https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-eead4a588c


signature.asc
Description: PGP signature
___
epel-announce mailing list
epel-annou...@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-annou...@lists.fedoraproject.org
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

Re: Updating hdf5 to 1.8.16 in rawhide today

[Orion Poplawski]

On 01/21/2016 06:52 AM, Orion Poplawski wrote:
> On 01/14/2016 04:25 PM, Orion Poplawski wrote:
>> On 11/20/2015 02:39 PM, Orion Poplawski wrote:
>>> I'll be updating hdf5 to 1.8.16 in rawhide in the next few days.  This
>>> includes a soname bump for the C++ wrapper libs, but as usual I'll be
>>> rebuilding all deps due to run-time version checking by the library.
>>>
>>
>> Well, the arm build is hanging in a test, so this didn't happen today.  I'll
>> try to reproduce the test failure to see what's up...
> 
> Switching mpich to the nemesis channel on all platforms has cleared this up. 
> hdf5 build has started now and should be done in about 4 hours. Then I'll
> start the rest of the rebuilds.
> 
> 

netcdf is giving me fits so I'm going to be able to complete the netcdf
dependent builds today.  The rest of the hdf5 only dependent stuff should be
done now or soon.

-- 
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301   http://www.nwra.com
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

[Bug 1300870] fusioninventory-agent-2.3.18-rc1 is available

[bugzilla]

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



--- Comment #1 from Upstream Release Monitoring 
 ---
Failed to kick off scratch build.

cmd:  spectool -g /var/tmp/thn-2H951h/fusioninventory-agent.spec
return code:  22
stdout:
Getting
https://github.com/fusioninventory/fusioninventory-agent/archive/2.3.18.tar.gz
to ./2.3.18.tar.gz

stderr:
  % Total% Received % Xferd  Average Speed   TimeTime Time  Current
 Dload  Upload   Total   SpentLeft  Speed

  0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 0
100   1450   1450 0382  0 --:--:-- --:--:-- --:--:--   383

  0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 0
  0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 0
curl: (22) The requested URL returned error: 404 Not Found

-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

[EPEL-devel] Re: EPEL5 mass rebuild (2016-01-20, 179 failures)

[Jason L Tibbitts III]

> "DC" == Dan Callaghan  writes:

DC> All of these broken dependencies onto python-setuptools-devel seemed
DC> a little strange to me so I dug into it.

Thanks for doing this.  I thought it was a bit odd but figured it was
better to actually get the report out there rather than try and figure
out why everything was breaking.

DC> So it seems like we will just need to update all those broken EPEL5
DC> packages to require python-setuptools instead of
DC> python-setuptools-devel. Hopefully there are no interfaces (or
DC> fixes) in the newer 0.6c9 version which EPEL packages were relying
DC> on...

Well, we can't really make the situation worse, can we?  The alternative
is simply to remove them, I guess.

Anyway, any provenpackagers up for fixing these?  I could script it, I
guess, but I should give folks a chance to fix things up on their own.

 - J<
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

Re: Should 'dnf install gtk3-devel.i686' work?

[Jan Kratochvil]

On Thu, 21 Jan 2016 23:24:13 +0100, Ian Malone wrote:
> and shifting data in and out is more awkward than working directly on it.

Mock has bind_mount* plugin for that.


Jan
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

nss_myhostname as default in Fedora

[Orion Poplawski]

See https://bugzilla.redhat.com/show_bug.cgi?id=1284323 as well

For a while (from 197-1 until 228-5), systemd added "myhostname" to the end of
the hosts line in /etc/nsswitch.conf in %post via sed.  This has been removed
as it is error prone, and the above request filed to add it by default to
/etc/nsswitch.conf in glibc.  The glibc maintainer would like to see
discussion of this on the devel list, hence this email.

My interest in this stems from build issues with mpich using programs.  This
may have been triggered by a combination of the above change as well as
changes in mpich, I'm not sure.  In any case, mpich uses gethostbyname() on
the hostname of the machine it is running on in order to configure itself
properly, and fails if it cannot do this.  So the mpich tests run by netcdf
are currently failing on the builders, and has since Nov 27 when systemd
dropped adding myhostname took place.

So:

- Is the change to nsswitch.conf in glibc (back to behavior that was the
default for quite a while) desired?

- If not, is there some other way we can get the koji builders' mock
configuration to be setup so they can at least resolve their own hostname?

Thanks.

PS - There is some other discussion around "mymachines" which seems much more
problematic.  I'd like to just focus on myhostname for now.  The glibc
maintainer has indicated that he wants to wait for mymachines to be resolved,
but it's almost two months now and I don't see that being resolved soon.

-- 
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301   http://www.nwra.com
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Should 'dnf install gtk3-devel.i686' work?

[Richard W.M. Jones]

On Thu, Jan 21, 2016 at 12:53:45PM -0700, Orion Poplawski wrote:
> On 01/21/2016 10:32 AM, Richard W.M. Jones wrote:
> > On Thu, Jan 21, 2016 at 04:36:33PM +, Sérgio Basto wrote:
> >> On Qui, 2016-01-21 at 08:25 -0600, Dennis Gilmore wrote:
> >>>
> >>> I am not really sure that people have tested this use case in years.
> >>> It would 
> >>> be interesting to see if yum-deprecated gave you working results. If
> >>> so then I 
> >>> would say it is a dnf bug.
> >>
> >> Is not a dnf bug 
> >>
> >> Somehow 
> >> dnf repoquery --provides  gtk3-devel.x86_64 
> >> (or rpm -q --provides gtk3-devel.x86_64 ) 
> >> and 
> >> dnf repoquery --provides  gtk3-devel.i686
> >>
> >> should provides different pkgconfig(s), instead the same, for example: 
> >> pkgconfig(gail-3.0) = 3.18.2 
> >>
> >> if gtk3-devel.x86_64 and gtk3-devel.i686 provides the same pkgconfig ,
> >> is not possible for dnf or yum choose the correct package. 
> > 
> > Correct - I've shown elsewhere in the thread that this bug exists in
> > yum, at least as far back as yum from Fedora 18.
> > 
> > Rich.
> > 
> 
> It's not a bug.  The requires is satisfied.

Yup, I didn't mean to indicate the bug was in dnf (or yum).  They are
obviously behaving correctly, and as you say the requires of the
packages themselves are wrong.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

[EPEL-devel] Re: EPEL5 mass rebuild (2016-01-20, 179 failures)

[Dan Callaghan]

Excerpts from Jason L Tibbitts III's message of 2016-01-20 18:49 -06:00:
> Failures due to missing dependencies: 122
> arprec-2.2.18-1.el5.src.rpm [qd-devel] (besser82)
> babel-0.9.5-2.el5.src.rpm [python26-distribute] (jcollie, fschwarz)
> Cython-0.14.1-3.el5.src.rpm [python26-distribute] (stevetraylen)
> dinotrace-9.4c-1.el5.src.rpm [emacs-verilog-mode] (chitlesh)
> disktype-9-5.el5.src.rpm [libewf-devel] (richardfearn, kwizart)
> euca2ools-2.1.3-1.el5.src.rpm [python26-setuptools] (gholms)
> gdal-1.4.2-4.el5.src.rpm [xerces-c-devel] (devrim, pali, volter)
> grin-1.1.1-3.el5.src.rpm [python-setuptools-devel] (hubbitus)
> mnemosyne-1.2.1-1.el5.src.rpm [python-setuptools-devel] (rathann)
> [...]

All of these broken dependencies onto python-setuptools-devel seemed 
a little strange to me so I dug into it.

In December 2013 python-setuptools was retired from EPEL5 because it 
moved into RHEL. But EPEL5 had 0.6c9-5.el5 whereas RHEL imported 
0.6c5-2.el5. I never even noticed this, my RHEL5 VM (which apparently is 
older than 2013) still has the EPEL package because its version is 
higher.

The other irritating difference between the packages is that the RHEL 
package didn't retain the (admittedly pointless) split into a -devel 
subpackage containing easy_install, everything is in the main 
python-setuptools package instead:

dcallagh@erlenmeyer ~ $ rpm -q python-setuptools python-setuptools-devel
python-setuptools-0.6c9-5.el5
python-setuptools-devel-0.6c9-5.el5
dcallagh@erlenmeyer ~ $ rpm -ql python-setuptools-devel
/usr/bin/easy_install
/usr/bin/easy_install-2.4
/usr/lib/python2.4/site-packages/easy_install.py
/usr/lib/python2.4/site-packages/easy_install.pyc
/usr/lib/python2.4/site-packages/easy_install.pyo
/usr/share/doc/python-setuptools-devel-0.6c9
/usr/share/doc/python-setuptools-devel-0.6c9/EasyInstall.txt
/usr/share/doc/python-setuptools-devel-0.6c9/README.txt
/usr/share/doc/python-setuptools-devel-0.6c9/api_tests.txt
/usr/share/doc/python-setuptools-devel-0.6c9/psfl.txt
/usr/share/doc/python-setuptools-devel-0.6c9/zpl.txt
dcallagh@erlenmeyer ~ $ rpm -ql python-setuptools
/usr/lib/python2.4/site-packages/pkg_resources.py
/usr/lib/python2.4/site-packages/pkg_resources.pyc
/usr/lib/python2.4/site-packages/pkg_resources.pyo
/usr/lib/python2.4/site-packages/setuptools
[...]
dcallagh@erlenmeyer ~ $ sudo repoquery python-setuptools
python-setuptools-0:0.6c5-2.el5.noarch
dcallagh@erlenmeyer ~ $ sudo repoquery -l python-setuptools
/usr/bin/easy_install
/usr/bin/easy_install-2.4
/usr/lib/python2.4/site-packages/easy_install.py
/usr/lib/python2.4/site-packages/easy_install.pyc
/usr/lib/python2.4/site-packages/easy_install.pyo
/usr/lib/python2.4/site-packages/pkg_resources.py
/usr/lib/python2.4/site-packages/pkg_resources.pyc
/usr/lib/python2.4/site-packages/pkg_resources.pyo
/usr/lib/python2.4/site-packages/setuptools
[...]

So it seems like we will just need to update all those broken EPEL5 packages to
require python-setuptools instead of python-setuptools-devel. Hopefully there
are no interfaces (or fixes) in the newer 0.6c9 version which EPEL packages
were relying on...

I will update any packages I have commit access to (which is just 
TurboGears I think).

-- 
Dan Callaghan 
Senior Software Engineer, Products & Technologies Operations
Red Hat, Inc.


signature.asc
Description: PGP signature
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

Re: Should 'dnf install gtk3-devel.i686' work?

[Ian Malone]

On 21 January 2016 at 15:15, Josh Boyer  wrote:
> On Thu, Jan 21, 2016 at 10:10 AM, Ian Malone  wrote:
>> On 21 January 2016 at 14:25, Dennis Gilmore  wrote:
>>
>>>
>>> However I  really think we need to sit down and rethink multilib. I would 
>>> like
>>> to start by changing the multilib method to runtime. So you only get runtime
>>> libraries and nothing to build 32 bit apps on 64 bit. For 32 bit building 
>>> you
>>> should just use mock, docker, systemd-nspawn or something else. It would 
>>> mean
>>> we need to make and ship a i386 docker base image if we say use docker.
>>>
>>> We have dropped most multilib support already. Today s390x has multilib with
>>> s390 and x86_64 multilib with i386.we dropped 32 bit ppc support entirely, 
>>> we
>>> are working to drop s390 which will leave x86_64 standing all alone. Given
>>> changes in technologies since x86_64 first became a thing I think we sit 
>>> back
>>> and reevaluate the idea of multilib. Maybe there is better ways to achieve
>>> what we want today
>>
>> Successfully build and run 20+ year old programs without having to
>> completely rewrite them would be one of the things I want today. In
>> fact it's one of the things I was doing earlier this week.
>
> Is there a reason that would not work in mock?
>

It would, it would require installing the entire development system in
mock though, and shifting data in and out is more awkward than working
directly on it. Additionally, notice the:

>>> Given
>>> changes in technologies since x86_64 first became a thing I think we sit 
>>> back
>>> and reevaluate the idea of multilib. Maybe there is better ways to achieve
>>> what we want today"

Since RHEL/CentOS 7 already does not exist in a native 32bit version I
do wonder what would actually be running in a hypothetical
mock/container/VM to build and run 32 bit systems down the road if
multilib went away.

-- 
imalone
http://ibmalone.blogspot.co.uk
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

[EPEL-devel] EPEL-ANNOUNCE Re: python-psutil-2.2.1 in epel7

[Itamar]

On 01/21/2016 07:41 PM, Ralph Bean wrote:
> Hello all,
>
> python-psutil-2.2.1 has been in epel7-testing for over a month now,
> and I intend to push it to stable in the coming weeks.  It is needed
> for the letsencrypt tools.
>
> There are a few small incompatibilities, but none of the dependencies
> that we found in EPEL7 itself would be affected.  Of course, there
> could be software not in EPEL7 that uses this package.. but that's why
> we're taking our time before pushing this update to stable.
>
> Please test the bodhi update when you can, so we can make way for
> letsencrypt[1].
>
> -Ralph
>
> [1] https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-eead4a588c
thank you, its on the way to stable.
___
epel-announce mailing list
epel-annou...@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-annou...@lists.fedoraproject.org
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

Temporary Disposable Client Image Process

[Tim Flink]

As far as I know, the plan for handling the disposable client images
for the immediate future is to build and distribute them manually until
the real system is in place.

To that end, I figure that it'll work best to just put the compressed
images somewhere that's easy to access. I'm planning to just put them
here for now:

https://tflink.fedorapeople.org/taskotron/taskotron-cloud/images/

I'd recommend against anyone else relying on a single image too heavily
right now - this is very unlikely to be the final place we put images
if it ends up making sense to make them easily grab-able.

Tim


pgp4y3utIzNB5.pgp
Description: OpenPGP digital signature
___
qa-devel mailing list
qa-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/qa-devel@lists.fedoraproject.org

Re: Schedule for Friday's FESCo Meeting (2016-01-22)

[Josh Boyer]

On Thu, Jan 21, 2016 at 7:46 PM, Kalev Lember  wrote:
> Following is the list of topics that will be discussed in the FESCo
> meeting Friday at 17:00UTC in #fedora-meeting on irc.freenode.net.
>
> To convert UTC to your local time, take a look at
>   http://fedoraproject.org/wiki/UTCHowto
>
> or run:
>   date -d '2016-01-22 17:00 UTC'
>
>
> Links to all tickets below can be found at:
> https://fedorahosted.org/fesco/report/9
>
> = Followups =
>
> #topic #1478 F24 Self Contained Changes
> .fesco 1478
> https://fedorahosted.org/fesco/ticket/1478
>
> #topic #1519 reevaluate Fedora 24 schedule
> .fesco 1519
> https://fedorahosted.org/fesco/ticket/1519
>
> = New business =
>
> #topic #1518 Software packaged in Fedora should not be allowed to implement 
> DRM schemes that cannot be disabled
> .fesco 1518
> https://fedorahosted.org/fesco/ticket/1518
>
> #topic #1525 F24 System Wide Change: Suds Jurko Fork
> .fesco 1525
> https://fedorahosted.org/fesco/ticket/1525
>
> #topic #1527 rabbitvcs package maintainer not responding
> .fesco 1527
> https://fedorahosted.org/fesco/ticket/1527
>
> #topic #1528 orphan packages owned by helloworld1
> .fesco 1528
> https://fedorahosted.org/fesco/ticket/1528
>
> #topic #1529 package poco: maintener not responsive bugid 917362
> .fesco 1529
> https://fedorahosted.org/fesco/ticket/1529
>
> #topic #1532 F24 System Wide Change: NewRpmDBFormat
> .fesco 1532
> https://fedorahosted.org/fesco/ticket/1532
>
> #topic #1533 F24 System Wide Change: Golang 1.6
> .fesco 1533
> https://fedorahosted.org/fesco/ticket/1533
>
> #topic #1534 Approve skip-release upgrading as an officially supported 
> upgrade method
> .fesco 1534
> https://fedorahosted.org/fesco/ticket/1534
>
> #topic #1535 quassel maintainer (tuxbrewr) not responding
> .fesco 1535
> https://fedorahosted.org/fesco/ticket/1535
>
> #topic #1536 initscript exception for initscripts package
> .fesco 1536
> https://fedorahosted.org/fesco/ticket/1536

I'm skeptical we're going to get through all of this.  I'd recommend
trying to work the non-responsive maintainer tickets outside the
meeting.  They aren't urgent.

josh
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: The %license property is now supported in EPEL6

[Adam Williamson]

On Wed, 2016-01-20 at 15:09 -0600, Jason L Tibbitts III wrote:
> Just a note that it EPEL6 no longer requires you to include the
> definition of %license property; you can use it freely in your %files
> list as you would in EPEL7 or Fedora.  It simply maps to %doc as it
> would if you had included the magic line noise manually.  This works for
> me in koji; if it doesn't work in your local mock instance, it's
> possible that the mirrors still need to catch up with the change to
> comps.
> 
> You'll still need that line noise (for now, at least) in EPEL5.  Next
> I'll be looking into whether or not it's actually possible.

Awesome!

Does anyone feel like tackling %autosetup? :)
-- 
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
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Schedule for Friday's FESCo Meeting (2016-01-22)

[Kalev Lember]

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

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

or run:
  date -d '2016-01-22 17:00 UTC'


Links to all tickets below can be found at: 
https://fedorahosted.org/fesco/report/9

= Followups =

#topic #1478 F24 Self Contained Changes
.fesco 1478
https://fedorahosted.org/fesco/ticket/1478

#topic #1519 reevaluate Fedora 24 schedule
.fesco 1519
https://fedorahosted.org/fesco/ticket/1519

= New business =

#topic #1518 Software packaged in Fedora should not be allowed to implement DRM 
schemes that cannot be disabled
.fesco 1518
https://fedorahosted.org/fesco/ticket/1518

#topic #1525 F24 System Wide Change: Suds Jurko Fork
.fesco 1525
https://fedorahosted.org/fesco/ticket/1525

#topic #1527 rabbitvcs package maintainer not responding
.fesco 1527
https://fedorahosted.org/fesco/ticket/1527

#topic #1528 orphan packages owned by helloworld1
.fesco 1528
https://fedorahosted.org/fesco/ticket/1528

#topic #1529 package poco: maintener not responsive bugid 917362
.fesco 1529
https://fedorahosted.org/fesco/ticket/1529

#topic #1532 F24 System Wide Change: NewRpmDBFormat
.fesco 1532
https://fedorahosted.org/fesco/ticket/1532

#topic #1533 F24 System Wide Change: Golang 1.6
.fesco 1533
https://fedorahosted.org/fesco/ticket/1533

#topic #1534 Approve skip-release upgrading as an officially supported upgrade 
method
.fesco 1534
https://fedorahosted.org/fesco/ticket/1534

#topic #1535 quassel maintainer (tuxbrewr) not responding
.fesco 1535
https://fedorahosted.org/fesco/ticket/1535

#topic #1536 initscript exception for initscripts package
.fesco 1536
https://fedorahosted.org/fesco/ticket/1536

= Open Floor = 

For more complete details, please visit each individual ticket.  The
report of the agenda items can be found at
https://fedorahosted.org/fesco/report/9

If you would like to add something to this agenda, you can reply to
this e-mail, file a new ticket at https://fedorahosted.org/fesco,
e-mail me directly, or bring it up at the end of the meeting, during
the open floor topic. Note that added topics may be deferred until
the following meeting.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

[389-devel] Please review, 47977 Implement sd_notify mechanism

[William Brown]

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


https://fedorahosted.org/389/attachment/ticket/47977/0001-Ticket-47944-
Implement-sd_notify-for-systemd.patch

-- 
Sincerely,

William Brown
Software Engineer
Red Hat, Brisbane



signature.asc
Description: This is a digitally signed message part
--
389-devel mailing list
389-devel@%(host_name)s
http://lists.fedoraproject.org/admin/lists/389-devel@lists.fedoraproject.org

[EPEL-devel] Necessity of some old RPM constructs in EL5

[Jason L Tibbitts III]

I'm now working on some magic macros for EPEL5.  Currently (on my
machine, at least) you can use %license and don't need BuildRoot:.  I'm
curious about some other boilerplate constructs, though.

%defattr in %files:
I've been told that even EPEL5 doesn't need this, but still it
persists.  Can someone verify that it really is not required?  Why do
people keep putting it in if so?

Cleaning %buildroot in %install::
Why is is so essential that the buildroot be cleaned as the first line
of %install?  I think I can make this happen magically but I'm not sure
why it's needed at all.

%clean
What actually goes wrong if %clean isn't there?  If it's just some cruft
that might be left over after a successful build, then is it really an
issue if it's not present?

 - J<
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

Re: How to test appdata for a package?

[Zbigniew Jędrzejewski-Szmek]

On Thu, Jan 21, 2016 at 11:26:18AM -0600, Richard Shaw wrote:
> Coming back around to this...
> 
> I have made sure that gnome-software wasn't already running, did
> appstream-util validate (no relaxed and fixed all output), and I still
> can't get it to show up in gnome-software after installing the resultant
> RPM...
> 
> Any other ideas? I would really like a method to visually review the
> results prior to building official packages.

Yeah, it would be really nice to be able to do:
gnome-software foobar.appdata.xml.
Apart from obvious convenience, this would have the additional advantage
of not requiring root privileges.

Zbyszek
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: How to test appdata for a package?

[Richard Shaw]

On Thu, Jan 21, 2016 at 6:44 PM, Zbigniew Jędrzejewski-Szmek <
zbys...@in.waw.pl> wrote:

> On Thu, Jan 21, 2016 at 11:26:18AM -0600, Richard Shaw wrote:
> > Coming back around to this...
> >
> > I have made sure that gnome-software wasn't already running, did
> > appstream-util validate (no relaxed and fixed all output), and I still
> > can't get it to show up in gnome-software after installing the resultant
> > RPM...
> >
> > Any other ideas? I would really like a method to visually review the
> > results prior to building official packages.
>
> Yeah, it would be really nice to be able to do:
> gnome-software foobar.appdata.xml.
> Apart from obvious convenience, this would have the additional advantage
> of not requiring root privileges.


Interestingly enough, while all searches failed, listing the installed
packages and scrolling down to it worked. Strange.

Thanks,
Richard
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: nss_myhostname as default in Fedora

[Michael Catanzaro]

On Thu, 2016-01-21 at 15:18 -0700, Orion Poplawski wrote:
> See https://bugzilla.redhat.com/show_bug.cgi?id=1284323 as well
> 
> For a while (from 197-1 until 228-5), systemd added "myhostname" to
> the end of
> the hosts line in /etc/nsswitch.conf in %post via sed.  This has been
> removed
> as it is error prone, and the above request filed to add it by
> default to
> /etc/nsswitch.conf in glibc.  The glibc maintainer would like to see
> discussion of this on the devel list, hence this email.

I don't care how it gets there, but I very much hope it gets there
somehow. mpich is not the only program that will be broken without
nss_myhostname.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org