eseyman uploaded Catalyst-Plugin-Email-0.09.tar.gz for perl-Catalyst-Plugin-Email

[notifications]

1d62cc854056ac72df16da3139f23ffd  Catalyst-Plugin-Email-0.09.tar.gz

http://pkgs.fedoraproject.org/lookaside/pkgs/perl-Catalyst-Plugin-Email/Catalyst-Plugin-Email-0.09.tar.gz/md5/1d62cc854056ac72df16da3139f23ffd/Catalyst-Plugin-Email-0.09.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

eseyman uploaded Catalyst-View-TT-0.43.tar.gz for perl-Catalyst-View-TT

[notifications]

7e3cfc28416bc5be8b2e6a7bd625e05a  Catalyst-View-TT-0.43.tar.gz

http://pkgs.fedoraproject.org/lookaside/pkgs/perl-Catalyst-View-TT/Catalyst-View-TT-0.43.tar.gz/md5/7e3cfc28416bc5be8b2e6a7bd625e05a/Catalyst-View-TT-0.43.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: noarch vs. all, x86_64 vs. amd64, kernel vs. linux and PAE

[Roberto Ragusa]

On 08/14/2015 02:38 PM, Wei-Lun Chao wrote:
 Hi,
 
 Is there already any discussion about:
 rename arch name noarch to all
 rename arch name x86_64 to amd64
 rename package name kernel-PAE to kernel
 and even rename package name kernel to linux

IMHO

kernel-PAE - kernel is reasonable, if the nonPAE is suppressed

x86_64 - amd64 is a good idea, as the architecture was created
by AMD; dropping an underscore is nice too

-- 
   Roberto Ragusamail at robertoragusa.it
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

eseyman pushed to perl-Catalyst-View-TT (master). Update to 0.43

[notifications]

From 3cb9771a51fa682b78bf7e20449a48d823b718ac Mon Sep 17 00:00:00 2001
From: Emmanuel Seyman emman...@seyman.fr
Date: Sun, 16 Aug 2015 10:47:05 +0200
Subject: Update to 0.43


diff --git a/.gitignore b/.gitignore
index 4f30a84..883e20c 100644
--- a/.gitignore
+++ b/.gitignore
@@ -6,3 +6,4 @@ Catalyst-View-TT-0.34.tar.gz
 /Catalyst-View-TT-0.40.tar.gz
 /Catalyst-View-TT-0.41.tar.gz
 /Catalyst-View-TT-0.42.tar.gz
+/Catalyst-View-TT-0.43.tar.gz
diff --git a/perl-Catalyst-View-TT.spec b/perl-Catalyst-View-TT.spec
index 7241435..f77ca86 100644
--- a/perl-Catalyst-View-TT.spec
+++ b/perl-Catalyst-View-TT.spec
@@ -1,10 +1,10 @@
 Name:   perl-Catalyst-View-TT
 Summary:Template Toolkit View Class
-Version:0.42
-Release:3%{?dist}
+Version:0.43
+Release:1%{?dist}
 License:GPL+ or Artistic
 
-Source0:
http://search.cpan.org/CPAN/authors/id/J/JJ/JJNAPIORK/Catalyst-View-TT-%{version}.tar.gz
+Source0:
http://search.cpan.org/CPAN/authors/id/E/ET/ETHER/Catalyst-View-TT-%{version}.tar.gz
 URL:http://search.cpan.org/dist/Catalyst-View-TT/
 Requires:   perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo 
$version))
 BuildArch:  noarch
@@ -12,7 +12,7 @@ BuildArch:  noarch
 BuildRequires:  perl(Catalyst) = 5.7
 BuildRequires:  perl(Class::Accessor)
 BuildRequires:  perl(CPAN)
-BuildRequires:  perl(ExtUtils::MakeMaker) = 6.59
+BuildRequires:  perl(ExtUtils::MakeMaker) = 6.76
 BuildRequires:  perl(MRO::Compat)
 BuildRequires:  perl(Path::Class)
 BuildRequires:  perl(Template)
@@ -36,14 +36,11 @@ find . -type f -exec chmod -x -c {} +
 sed -i 's/\r//' t/lib/TestApp/Template/Any.pm
 
 %build
-%{__perl} Makefile.PL INSTALLDIRS=vendor
+%{__perl} Makefile.PL INSTALLDIRS=vendor NO_PACKLIST=1
 make %{?_smp_mflags}
 
 %install
 make pure_install DESTDIR=%{buildroot}
-
-find %{buildroot} -type f -name .packlist -exec rm -f {} +
-
 %{_fixperms} %{buildroot}/*
 
 %check
@@ -55,6 +52,10 @@ make test
 %{_mandir}/man3/Catalyst*
 
 %changelog
+* Sun Aug 16 2015 Emmanuel Seyman emman...@seyman.fr - 0.43-1
+- Update to 0.43
+- Do not generate the .packlist file
+
 * Thu Jun 18 2015 Fedora Release Engineering rel-...@lists.fedoraproject.org 
- 0.42-3
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_23_Mass_Rebuild
 
diff --git a/sources b/sources
index 8dfbc9f..2013c52 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-d154807302fb9ac5ff1e5aa473c084e6  Catalyst-View-TT-0.42.tar.gz
+7e3cfc28416bc5be8b2e6a7bd625e05a  Catalyst-View-TT-0.43.tar.gz
-- 
cgit v0.10.2



http://pkgs.fedoraproject.org/cgit/perl-Catalyst-View-TT.git/commit/?h=masterid=3cb9771a51fa682b78bf7e20449a48d823b718ac
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Broken dependencies: perl-Method-Signatures

[buildsys]

perl-Method-Signatures has broken dependencies in the rawhide tree:
On x86_64:
perl-Method-Signatures-20141021-1.fc22.noarch requires 
perl(:MODULE_COMPAT_5.20.1)
On i386:
perl-Method-Signatures-20141021-1.fc22.noarch requires 
perl(:MODULE_COMPAT_5.20.1)
On armhfp:
perl-Method-Signatures-20141021-1.fc22.noarch requires 
perl(:MODULE_COMPAT_5.20.1)
Please resolve this as soon as possible.


--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Broken dependencies: perl-Test-AutoBuild

[buildsys]

perl-Test-AutoBuild has broken dependencies in the rawhide tree:
On x86_64:
perl-Test-AutoBuild-1.2.4-15.fc22.x86_64 requires 
perl(:MODULE_COMPAT_5.20.0)
On i386:
perl-Test-AutoBuild-1.2.4-15.fc22.i686 requires 
perl(:MODULE_COMPAT_5.20.0)
On armhfp:
perl-Test-AutoBuild-1.2.4-15.fc22.armv7hl requires 
perl(:MODULE_COMPAT_5.20.0)
Please resolve this as soon as possible.


--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Broken dependencies: perl-Devel-BeginLift

[buildsys]

perl-Devel-BeginLift has broken dependencies in the rawhide tree:
On x86_64:
perl-Devel-BeginLift-0.001003-9.fc22.x86_64 requires 
perl(:MODULE_COMPAT_5.20.0)
perl-Devel-BeginLift-0.001003-9.fc22.x86_64 requires 
libperl.so.5.20()(64bit)
On i386:
perl-Devel-BeginLift-0.001003-9.fc22.i686 requires 
perl(:MODULE_COMPAT_5.20.0)
perl-Devel-BeginLift-0.001003-9.fc22.i686 requires libperl.so.5.20
On armhfp:
perl-Devel-BeginLift-0.001003-9.fc22.armv7hl requires 
perl(:MODULE_COMPAT_5.20.0)
perl-Devel-BeginLift-0.001003-9.fc22.armv7hl requires libperl.so.5.20
Please resolve this as soon as possible.


--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Broken dependencies: perl-Data-Alias

[buildsys]

perl-Data-Alias has broken dependencies in the rawhide tree:
On x86_64:
perl-Data-Alias-1.18-4.fc22.x86_64 requires perl(:MODULE_COMPAT_5.20.0)
perl-Data-Alias-1.18-4.fc22.x86_64 requires libperl.so.5.20()(64bit)
On i386:
perl-Data-Alias-1.18-4.fc22.i686 requires perl(:MODULE_COMPAT_5.20.0)
perl-Data-Alias-1.18-4.fc22.i686 requires libperl.so.5.20
On armhfp:
perl-Data-Alias-1.18-4.fc22.armv7hl requires perl(:MODULE_COMPAT_5.20.0)
perl-Data-Alias-1.18-4.fc22.armv7hl requires libperl.so.5.20
Please resolve this as soon as possible.


--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Broken dependencies: perl-CGI-Application-Structured-Tools

[buildsys]

perl-CGI-Application-Structured-Tools has broken dependencies in the rawhide 
tree:
On x86_64:
perl-CGI-Application-Structured-Tools-0.015-7.fc22.noarch requires 
perl(:MODULE_COMPAT_5.20.0)
On i386:
perl-CGI-Application-Structured-Tools-0.015-7.fc22.noarch requires 
perl(:MODULE_COMPAT_5.20.0)
On armhfp:
perl-CGI-Application-Structured-Tools-0.015-7.fc22.noarch requires 
perl(:MODULE_COMPAT_5.20.0)
Please resolve this as soon as possible.


--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Broken dependencies: perl-POE-API-Peek

[buildsys]

perl-POE-API-Peek has broken dependencies in the rawhide tree:
On x86_64:
1:perl-POE-API-Peek-2.20-8.fc22.noarch requires 
perl(:MODULE_COMPAT_5.20.0)
On i386:
1:perl-POE-API-Peek-2.20-8.fc22.noarch requires 
perl(:MODULE_COMPAT_5.20.0)
On armhfp:
1:perl-POE-API-Peek-2.20-8.fc22.noarch requires 
perl(:MODULE_COMPAT_5.20.0)
Please resolve this as soon as possible.


--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Broken dependencies: perl-Data-Dump-Streamer

[buildsys]

perl-Data-Dump-Streamer has broken dependencies in the rawhide tree:
On x86_64:
perl-Data-Dump-Streamer-2.38-3.fc22.x86_64 requires 
perl(:MODULE_COMPAT_5.20.0)
perl-Data-Dump-Streamer-2.38-3.fc22.x86_64 requires 
libperl.so.5.20()(64bit)
On i386:
perl-Data-Dump-Streamer-2.38-3.fc22.i686 requires 
perl(:MODULE_COMPAT_5.20.0)
perl-Data-Dump-Streamer-2.38-3.fc22.i686 requires libperl.so.5.20
On armhfp:
perl-Data-Dump-Streamer-2.38-3.fc22.armv7hl requires 
perl(:MODULE_COMPAT_5.20.0)
perl-Data-Dump-Streamer-2.38-3.fc22.armv7hl requires libperl.so.5.20
Please resolve this as soon as possible.


--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Broken dependencies: perl-Test-Vars

[buildsys]

perl-Test-Vars has broken dependencies in the rawhide tree:
On x86_64:
perl-Test-Vars-0.005-6.fc22.noarch requires perl(:MODULE_COMPAT_5.20.0)
On i386:
perl-Test-Vars-0.005-6.fc22.noarch requires perl(:MODULE_COMPAT_5.20.0)
On armhfp:
perl-Test-Vars-0.005-6.fc22.noarch requires perl(:MODULE_COMPAT_5.20.0)
Please resolve this as soon as possible.


--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Broken dependencies: polymake

[buildsys]

polymake has broken dependencies in the rawhide tree:
On x86_64:
polymake-2.13-22.git20141013.fc23.x86_64 requires 
perl(:MODULE_COMPAT_5.20.2)
polymake-2.13-22.git20141013.fc23.x86_64 requires perl = 4:5.20.2
polymake-2.13-22.git20141013.fc23.x86_64 requires 
libperl.so.5.20()(64bit)
On i386:
polymake-2.13-22.git20141013.fc23.i686 requires 
perl(:MODULE_COMPAT_5.20.2)
polymake-2.13-22.git20141013.fc23.i686 requires perl = 4:5.20.2
polymake-2.13-22.git20141013.fc23.i686 requires libperl.so.5.20
On armhfp:
polymake-2.13-22.git20141013.fc23.armv7hl requires 
perl(:MODULE_COMPAT_5.20.2)
polymake-2.13-22.git20141013.fc23.armv7hl requires perl = 4:5.20.2
polymake-2.13-22.git20141013.fc23.armv7hl requires libperl.so.5.20
Please resolve this as soon as possible.


--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Broken dependencies: perl-Devel-FindRef

[buildsys]

perl-Devel-FindRef has broken dependencies in the rawhide tree:
On x86_64:
perl-Devel-FindRef-1.44-3.fc22.x86_64 requires 
perl(:MODULE_COMPAT_5.20.0)
perl-Devel-FindRef-1.44-3.fc22.x86_64 requires libperl.so.5.20()(64bit)
On i386:
perl-Devel-FindRef-1.44-3.fc22.i686 requires perl(:MODULE_COMPAT_5.20.0)
perl-Devel-FindRef-1.44-3.fc22.i686 requires libperl.so.5.20
On armhfp:
perl-Devel-FindRef-1.44-3.fc22.armv7hl requires 
perl(:MODULE_COMPAT_5.20.0)
perl-Devel-FindRef-1.44-3.fc22.armv7hl requires libperl.so.5.20
Please resolve this as soon as possible.


--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Broken dependencies: perl-B-Hooks-OP-Check-EntersubForCV

[buildsys]

perl-B-Hooks-OP-Check-EntersubForCV has broken dependencies in the rawhide tree:
On x86_64:
perl-B-Hooks-OP-Check-EntersubForCV-0.09-10.fc22.x86_64 requires 
perl(:MODULE_COMPAT_5.20.0)
perl-B-Hooks-OP-Check-EntersubForCV-0.09-10.fc22.x86_64 requires 
libperl.so.5.20()(64bit)
On i386:
perl-B-Hooks-OP-Check-EntersubForCV-0.09-10.fc22.i686 requires 
perl(:MODULE_COMPAT_5.20.0)
perl-B-Hooks-OP-Check-EntersubForCV-0.09-10.fc22.i686 requires 
libperl.so.5.20
On armhfp:
perl-B-Hooks-OP-Check-EntersubForCV-0.09-10.fc22.armv7hl requires 
perl(:MODULE_COMPAT_5.20.0)
perl-B-Hooks-OP-Check-EntersubForCV-0.09-10.fc22.armv7hl requires 
libperl.so.5.20
Please resolve this as soon as possible.


--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: noarch vs. all, x86_64 vs. amd64, kernel vs. linux and PAE

[Reindl Harald]

Am 16.08.2015 um 10:55 schrieb Reindl Harald:



Am 16.08.2015 um 10:47 schrieb Roberto Ragusa:

On 08/14/2015 02:38 PM, Wei-Lun Chao wrote:

Hi,

Is there already any discussion about:
rename arch name noarch to all
rename arch name x86_64 to amd64
rename package name kernel-PAE to kernel
and even rename package name kernel to linux


IMHO

kernel-PAE - kernel is reasonable, if the nonPAE is suppressed


yes


x86_64 - amd64 is a good idea, as the architecture was created
by AMD; dropping an underscore is nice too


no the architecture was created by Intel

AMD added the 64bit capabilities in a compatible way other than Intel
itself tried with Itanium which was not able to run i686 instructions
and later Intel was forced to license the AMD extensions

so no, it is a terrible idea rename x86_64 to AMD64 because it suggests
that's not for Intel CPUs and it's proven that people think that when
read only AMD


https://en.wikipedia.org/wiki/X86-64

https://en.wikipedia.org/wiki/X86-64#AMD64
https://en.wikipedia.org/wiki/X86-64#Intel_64

so we support only AMD64?
really?
written on x64_64 Fedora on a Intel(R) Core(TM) i7-3770 CPU @ 3.40GH




signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

eseyman uploaded Mojolicious-6.15.tar.gz for perl-Mojolicious

[notifications]

a427279f4b9628e4fed3270355a30148  Mojolicious-6.15.tar.gz

http://pkgs.fedoraproject.org/lookaside/pkgs/perl-Mojolicious/Mojolicious-6.15.tar.gz/md5/a427279f4b9628e4fed3270355a30148/Mojolicious-6.15.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

eseyman uploaded Mouse-v2.4.5.tar.gz for perl-Mouse

[notifications]

2183f5bc16c7d37df5cf1dacf8ef88a1  Mouse-v2.4.5.tar.gz

http://pkgs.fedoraproject.org/lookaside/pkgs/perl-Mouse/Mouse-v2.4.5.tar.gz/md5/2183f5bc16c7d37df5cf1dacf8ef88a1/Mouse-v2.4.5.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

eseyman pushed to perl-Catalyst-Plugin-Email (master). Update to 0.09 and clean up spec file

[notifications]

From ee9c096d84a0a480a78b0a96248dae2fab63a647 Mon Sep 17 00:00:00 2001
From: Emmanuel Seyman emman...@seyman.fr
Date: Sun, 16 Aug 2015 10:20:08 +0200
Subject: Update to 0.09 and clean up spec file


diff --git a/.gitignore b/.gitignore
index 8757a08..b8fa8e5 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1,2 @@
 Catalyst-Plugin-Email-0.08.tar.gz
+/Catalyst-Plugin-Email-0.09.tar.gz
diff --git a/perl-Catalyst-Plugin-Email.spec b/perl-Catalyst-Plugin-Email.spec
index b158472..d9cb1d6 100644
--- a/perl-Catalyst-Plugin-Email.spec
+++ b/perl-Catalyst-Plugin-Email.spec
@@ -1,22 +1,24 @@
 Name:   perl-Catalyst-Plugin-Email
-Version:0.08
-Release:16%{?dist}
+Version:0.09
+Release:1%{?dist}
 Summary:Send emails with Catalyst
 License:GPL+ or Artistic
-Group:  Development/Libraries
+
 URL:http://search.cpan.org/dist/Catalyst-Plugin-Email/
-Source0:
http://www.cpan.org/authors/id/M/MR/MRAMBERG/Catalyst-Plugin-Email-%{version}.tar.gz
-BuildRoot:  %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
+Source0:
http://www.cpan.org/authors/id/E/ET/ETHER/Catalyst-Plugin-Email-%{version}.tar.gz
+
 BuildArch:  noarch
 BuildRequires:  perl(Catalyst) = 2.99
 BuildRequires:  perl(Email::MIME)
 BuildRequires:  perl(Email::MIME::Creator)
 BuildRequires:  perl(Email::Send)
 BuildRequires:  perl(Email::Simple::Creator)
-BuildRequires:  perl(ExtUtils::MakeMaker)
+BuildRequires:  perl(ExtUtils::MakeMaker) = 6.76
 BuildRequires:  perl(Test::More)
 Requires:   perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo 
$version))
 
+%{?perl_default_filter}
+
 %description
 Send emails with Catalyst and Email::Send and Email::MIME::Creator.
 
@@ -24,32 +26,26 @@ Send emails with Catalyst and Email::Send and 
Email::MIME::Creator.
 %setup -q -n Catalyst-Plugin-Email-%{version}
 
 %build
-%{__perl} Makefile.PL INSTALLDIRS=vendor
+%{__perl} Makefile.PL INSTALLDIRS=vendor NO_PACKLIST=1
 make %{?_smp_mflags}
 
 %install
-rm -rf $RPM_BUILD_ROOT
-
-make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT
-
-find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
-find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2/dev/null \;
-
+make pure_install DESTDIR=$RPM_BUILD_ROOT
 %{_fixperms} $RPM_BUILD_ROOT/*
 
 %check
 make test
 
-%clean
-rm -rf $RPM_BUILD_ROOT
-
 %files
-%defattr(-,root,root,-)
 %doc Changes README
-%{perl_vendorlib}/*
-%{_mandir}/man3/*
+%{perl_vendorlib}/Catalyst*
+%{_mandir}/man3/Catalyst*
 
 %changelog
+* Sun Aug 16 2015 Emmanuel Seyman emman...@seyman.fr - 0.09-1
+- Update to 0.09
+- Clean up spec file
+
 * Thu Jun 18 2015 Fedora Release Engineering rel-...@lists.fedoraproject.org 
- 0.08-16
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_23_Mass_Rebuild
 
diff --git a/sources b/sources
index 2078bcf..0c9ae60 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-173e2b91b21e55da9671220734869c6d  Catalyst-Plugin-Email-0.08.tar.gz
+1d62cc854056ac72df16da3139f23ffd  Catalyst-Plugin-Email-0.09.tar.gz
-- 
cgit v0.10.2



http://pkgs.fedoraproject.org/cgit/perl-Catalyst-Plugin-Email.git/commit/?h=masterid=ee9c096d84a0a480a78b0a96248dae2fab63a647
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: noarch vs. all, x86_64 vs. amd64, kernel vs. linux and PAE

[Reindl Harald]

Am 16.08.2015 um 10:47 schrieb Roberto Ragusa:

On 08/14/2015 02:38 PM, Wei-Lun Chao wrote:

Hi,

Is there already any discussion about:
rename arch name noarch to all
rename arch name x86_64 to amd64
rename package name kernel-PAE to kernel
and even rename package name kernel to linux


IMHO

kernel-PAE - kernel is reasonable, if the nonPAE is suppressed


yes


x86_64 - amd64 is a good idea, as the architecture was created
by AMD; dropping an underscore is nice too


no the architecture was created by Intel

AMD added the 64bit capabilities in a compatible way other than Intel 
itself tried with Itanium which was not able to run i686 instructions 
and later Intel was forced to license the AMD extensions


so no, it is a terrible idea rename x86_64 to AMD64 because it suggests 
that's not for Intel CPUs and it's proven that people think that when 
read only AMD


NOTHING above is reasonable but just a make changes for the sake of a 
change or having solution, seeking problem now




signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[Bug 1253992] New: perl-Math-PlanePath-120 is available

[bugzilla]

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

Bug ID: 1253992
   Summary: perl-Math-PlanePath-120 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Math-PlanePath
  Keywords: FutureFeature, Triaged
  Assignee: mhron...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: mhron...@redhat.com,
perl-devel@lists.fedoraproject.org



Latest upstream release: 120
Current version/release in rawhide: 119-1.fc23
URL: http://search.cpan.org/dist/Math-PlanePath/

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
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[Bug 1253995] New: perl-MooseX-Types-DateTime-MoreCoercions-0.15 is available

[bugzilla]

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

Bug ID: 1253995
   Summary: perl-MooseX-Types-DateTime-MoreCoercions-0.15 is
available
   Product: Fedora
   Version: rawhide
 Component: perl-MooseX-Types-DateTime-MoreCoercions
  Keywords: FutureFeature, Triaged
  Assignee: ppi...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com,
psab...@redhat.com



Latest upstream release: 0.15
Current version/release in rawhide: 0.14-4.fc23
URL: http://search.cpan.org/dist/MooseX-Types-DateTime-MoreCoercions/

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
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[Bug 1253995] perl-MooseX-Types-DateTime-MoreCoercions-0.15 is available

[bugzilla]

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



--- Comment #1 from Upstream Release Monitoring 
upstream-release-monitor...@fedoraproject.org ---
Failed to kick off scratch build.

cmd:  sha256sum /var/tmp/thn-sSMaU9/100.0%
return code:  1
stdout:

stderr:
sha256sum: /var/tmp/thn-sSMaU9/100.0%: No such file or directory

-- 
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
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[Bug 1253992] perl-Math-PlanePath-120 is available

[bugzilla]

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



--- Comment #1 from Upstream Release Monitoring 
upstream-release-monitor...@fedoraproject.org ---
Failed to kick off scratch build.

cmd:  sha256sum /var/tmp/thn-unmG9E/100.0%
return code:  1
stdout:

stderr:
sha256sum: /var/tmp/thn-unmG9E/100.0%: No such file or directory

-- 
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
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

eseyman pushed to perl-Mouse (master). Update to 2.4.5 (dropping upstreamed patches as we go)

[notifications]

From d303d24c58a23778542b40520f53efc0d7d3ff3d Mon Sep 17 00:00:00 2001
From: Emmanuel Seyman emman...@seyman.fr
Date: Sun, 16 Aug 2015 11:40:10 +0200
Subject: Update to 2.4.5 (dropping upstreamed patches as we go)


diff --git a/.gitignore b/.gitignore
index f05b087..30ebe7c 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1,2 @@
 /Mouse-[0-9.]*.tar.gz
+/Mouse-v2.4.5.tar.gz
diff --git a/Mouse-2.4.2-Fix-test-code.patch b/Mouse-2.4.2-Fix-test-code.patch
deleted file mode 100644
index 142aedb..000
--- a/Mouse-2.4.2-Fix-test-code.patch
+++ /dev/null
@@ -1,39 +0,0 @@
-From 43bd48014c89331cc0dadad78190890199469e81 Mon Sep 17 00:00:00 2001
-From: Syohei YOSHIDA syo...@gmail.com
-Date: Wed, 24 Jun 2015 18:02:57 +0900
-Subject: [PATCH 2/2] Fix test code
-MIME-Version: 1.0
-Content-Type: text/plain; charset=UTF-8
-Content-Transfer-Encoding: 8bit
-
-In original code, mismatching plan error is occurred.
-
-Signed-off-by: Petr Písař ppi...@redhat.com

- t/900_mouse_bugs/017_issue29.t | 9 ++---
- 1 file changed, 6 insertions(+), 3 deletions(-)
-
-diff --git a/t/900_mouse_bugs/017_issue29.t b/t/900_mouse_bugs/017_issue29.t
-index 14c2900..bc93767 100644
 a/t/900_mouse_bugs/017_issue29.t
-+++ b/t/900_mouse_bugs/017_issue29.t
-@@ -3,10 +3,13 @@
- package main;
- use strict;
- use warnings;
--use Test::More skip_all = 'See https://github.com/gfx/p5-Mouse/issues/29';
--
--use Test::Requires qw(threads); # XXX: ithreads is discuraged!
-+use constant HAS_THREADS = eval{ require threads  require threads::shared 
};
-+use Test::More;
- 
-+use if !HAS_THREADS, 'Test::More',
-+(skip_all = This is a test for threads ($@));
-+use if $Test::More::VERSION = 2.00, 'Test::More',
-+(skip_all = Test::Builder2 has bugs about threads);
- 
- {
- package Foo;
--- 
-2.1.0
-
diff --git a/Mouse-2.4.2-Fix-thread-issue-for-Perl-5.22.0-or-higher.patch 
b/Mouse-2.4.2-Fix-thread-issue-for-Perl-5.22.0-or-higher.patch
deleted file mode 100644
index f178e73..000
--- a/Mouse-2.4.2-Fix-thread-issue-for-Perl-5.22.0-or-higher.patch
+++ /dev/null
@@ -1,195 +0,0 @@
-From 40f345f8b69a863069b25c5f3aac22d8f677eb03 Mon Sep 17 00:00:00 2001
-From: Syohei YOSHIDA syo...@gmail.com
-Date: Wed, 24 Jun 2015 17:34:02 +0900
-Subject: [PATCH 1/2] Fix thread issue for Perl 5.22.0 or higher
-MIME-Version: 1.0
-Content-Type: text/plain; charset=UTF-8
-Content-Transfer-Encoding: 8bit
-
-Signed-off-by: Petr Písař ppi...@redhat.com

- mouse.h|  8 
- xs-src/MouseAccessor.xs| 20 
- xs-src/MouseTypeConstraints.xs | 17 +++--
- 3 files changed, 31 insertions(+), 14 deletions(-)
-
-diff --git a/mouse.h b/mouse.h
-index b0c53ef..48792a2 100644
 a/mouse.h
-+++ b/mouse.h
-@@ -106,6 +106,14 @@ SV* mouse_av_at_safe(pTHX_ AV* const mi, I32 const ix);
- #define MOUSE_mg_slot(mg)   MOUSE_mg_obj(mg)
- #define MOUSE_mg_xa(mg)((AV*)MOUSE_mg_ptr(mg))
- 
-+static inline MAGIC *MOUSE_get_magic(CV *cv, MGVTBL *vtbl)
-+{
-+#ifndef MULTIPLICITY
-+return (MAGIC*)(CvXSUBANY(cv).any_ptr);
-+#else
-+return mg_findext((SV*)cv, PERL_MAGIC_ext, vtbl);
-+#endif
-+}
- 
- /* mouse_instance.xs stuff */
- SV*  mouse_instance_create (pTHX_ HV* const stash);
-diff --git a/xs-src/MouseAccessor.xs b/xs-src/MouseAccessor.xs
-index daf9cf1..11eb630 100644
 a/xs-src/MouseAccessor.xs
-+++ b/xs-src/MouseAccessor.xs
-@@ -122,7 +122,9 @@ mouse_accessor_generate(pTHX_ SV* const attr, XSUBADDR_t 
const accessor_impl){
-  * although we use MAGIC for gc, we also store mg to
-  * CvXSUBANY for efficiency (gfx)
-  */
-+#ifndef MULTIPLICITY
- CvXSUBANY(xsub).any_ptr = (void*)mg;
-+#endif
- 
- return xsub;
- }
-@@ -262,7 +264,7 @@ XS(XS_Mouse_accessor)
- {
- dVAR; dXSARGS;
- dMOUSE_self;
--MAGIC* const mg = (MAGIC*)XSANY.any_ptr;
-+MAGIC* const mg = MOUSE_get_magic(cv, mouse_accessor_vtbl);
- 
- SP -= items; /* PPCODE */
- PUTBACK;
-@@ -285,7 +287,7 @@ XS(XS_Mouse_reader)
- {
- dVAR; dXSARGS;
- dMOUSE_self;
--MAGIC* const mg = (MAGIC*)XSANY.any_ptr;
-+MAGIC* const mg = MOUSE_get_magic(cv, mouse_accessor_vtbl);
- 
- if (items != 1) {
- mouse_throw_error(MOUSE_mg_attribute(mg), NULL,
-@@ -303,7 +305,7 @@ XS(XS_Mouse_writer)
- {
- dVAR; dXSARGS;
- dMOUSE_self;
--MAGIC* const mg = (MAGIC*)XSANY.any_ptr;
-+MAGIC* const mg = MOUSE_get_magic(cv, mouse_accessor_vtbl);
- 
- if (items != 2) {
- mouse_throw_error(MOUSE_mg_attribute(mg), NULL,
-@@ -351,7 +353,9 @@ mouse_simple_accessor_generate(pTHX_
-  * although we use MAGIC for gc, we also store mg to CvXSUBANY
-  * for efficiency (gfx)
-  */
-+#ifndef MULTIPLICITY
- CvXSUBANY(xsub).any_ptr = (void*)mg;
-+#endif
- 
- return xsub;
- }
-@@ -360,7 +364,7 @@ XS(XS_Mouse_simple_reader)
- {
- dVAR; dXSARGS;
- dMOUSE_self;
--MAGIC* const mg = (MAGIC*)XSANY.any_ptr;
-+MAGIC* const mg = MOUSE_get_magic(cv, mouse_accessor_vtbl);
- 

Re: Same comand names in /usr/bin and /usr/sbin

[Lennart Poettering]

On Fri, 14.08.15 17:58, Matthew Miller (mat...@fedoraproject.org) wrote:

 On Fri, Aug 14, 2015 at 07:24:16PM +0200, Lennart Poettering wrote:
  Given that sbin is in $PATH for unprivileged users too the seperation
  is really pointless, since it's now only the $PATH order which makes
  this not explode.
 
 Yeah; I have a halfhearted wish to rationalize what goes in sbin and
 what goes in bin. One approach would be to make sbin be commands that
 wouldn't normally be even in privileged users' $PATH — daemons and so
 on that should be launched by init. (Having crond in my path is just
 polluting the namespace.) But all of that is a lot of churn for
 something that's... not usually a problem.

Also, that ship has sailed a long time ago, when we added sbin to very
user's $PATH, not just root's...

There's the general problem that things which were initially intended
to be run only by root often are opened up later for unprivileged
clients, and if that happens you'd have to move the file from bin/ to
sbin/, but that breaks API, since the paths of many binaries are kinda
assumed to be API by many scripts. That then resulted in people
placing compat symlinks, so that /usr/sbin/tracepath for example
became a symlink to /usr/bin/tracepath so that both paths are
available.

In general: encoding privilige policy into the API through binary
paths is a really bad idea, as policy shouldn't be considered strict
API (or to be more precise: it should be allowed to open up policy --
while of course not necessarily to close it down later on), but paths
are.

Hence: we should say goodbye to the concept of separate bin/sbin, we
kinda did already by adding both to $PATH for all users, but we should
work on making this go away in the FS hierachy too, and replace sbin
by a symlink.

Lennart

-- 
Lennart Poettering, Red Hat
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

pghmcfc pushed to perl-Devel-PartialDump (f23). Update to 0.18 (..more)

[notifications]

From 192b67ddd3ee9de7b06615d2bcef2aa9d94ee9f8 Mon Sep 17 00:00:00 2001
From: Paul Howarth p...@city-fan.org
Date: Sun, 16 Aug 2015 13:20:07 +0100
Subject: Update to 0.18

- New upstream release 0.18
  - Update some distribution tooling
- Switch to ExtUtils::MakeMaker flow

diff --git a/perl-Devel-PartialDump.spec b/perl-Devel-PartialDump.spec
index 4fe6c77..0aa4dea 100644
--- a/perl-Devel-PartialDump.spec
+++ b/perl-Devel-PartialDump.spec
@@ -1,19 +1,21 @@
 Name:   perl-Devel-PartialDump
-Version:0.17
-Release:3%{?dist}
+Version:0.18
+Release:1%{?dist}
 Summary:Partial dumping of data structures, optimized for argument 
printing
 License:GPL+ or Artistic
 URL:http://search.cpan.org/dist/Devel-PartialDump/
 Source0:
http://www.cpan.org/authors/id/E/ET/ETHER/Devel-PartialDump-%{version}.tar.gz
 BuildArch:  noarch
 # Module Build
+BuildRequires:  coreutils
+BuildRequires:  findutils
+BuildRequires:  make
 BuildRequires:  perl
-BuildRequires:  perl(Module::Build::Tiny) = 0.030
+BuildRequires:  perl(ExtUtils::MakeMaker)
 # Module Runtime
 BuildRequires:  perl(Carp)
-BuildRequires:  perl(Carp::Heavy)
 BuildRequires:  perl(Class::Tiny)
-BuildRequires:  perl(namespace::clean) = 0.20
+BuildRequires:  perl(namespace::clean) = 0.19
 BuildRequires:  perl(overload)
 BuildRequires:  perl(Scalar::Util)
 BuildRequires:  perl(strict)
@@ -23,14 +25,12 @@ BuildRequires:  perl(warnings)
 BuildRequires:  perl(CPAN::Meta)
 BuildRequires:  perl(CPAN::Meta::Requirements)
 BuildRequires:  perl(ExtUtils::MakeMaker)
-BuildRequires:  perl(File::Spec::Functions)
-BuildRequires:  perl(List::Util)
+BuildRequires:  perl(File::Spec)
 BuildRequires:  perl(ok)
 BuildRequires:  perl(Test::More) = 0.94
 BuildRequires:  perl(Test::Warn)
 # Runtime
 Requires:   perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
-Requires:   perl(Carp::Heavy)
 Requires:   perl(overload)
 
 # Filter bogus provide of perl(DB)
@@ -43,22 +43,30 @@ This module is a data dumper optimized for logging of 
arbitrary parameters.
 %setup -q -n Devel-PartialDump-%{version}
 
 %build
-perl Build.PL --installdirs=vendor
-./Build
+perl Makefile.PL INSTALLDIRS=vendor
+make %{?_smp_mflags}
 
 %install
-./Build install --destdir=%{buildroot} --create_packlist=0
+rm -rf %{buildroot}
+make pure_install DESTDIR=%{buildroot}
+find %{buildroot} -type f -name .packlist -exec rm -f {} ';'
+%{_fixperms} %{buildroot}
 
 %check
-./Build test
+make test
 
 %files
 %license LICENSE
-%doc Changes CONTRIBUTING README.md
+%doc Changes CONTRIBUTING README
 %{perl_vendorlib}/Devel/
 %{_mandir}/man3/Devel::PartialDump.3*
 
 %changelog
+* Sun Aug 16 2015 Paul Howarth p...@city-fan.org - 0.18-1
+- Update to 0.18
+  - Update some distribution tooling
+- Switch to ExtUtils::MakeMaker flow
+
 * Thu Jun 18 2015 Fedora Release Engineering rel-...@lists.fedoraproject.org 
- 0.17-3
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_23_Mass_Rebuild
 
diff --git a/sources b/sources
index 474c739..76c07b3 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-c076e685aa184dede1454b3bea3430fa  Devel-PartialDump-0.17.tar.gz
+eb6045e1ae8860f21631fe046125fd98  Devel-PartialDump-0.18.tar.gz
-- 
cgit v0.10.2



http://pkgs.fedoraproject.org/cgit/perl-Devel-PartialDump.git/commit/?h=f23id=192b67ddd3ee9de7b06615d2bcef2aa9d94ee9f8
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[Bug 1253987] perl-Devel-PartialDump-0.18 is available

[bugzilla]

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

Paul Howarth p...@city-fan.org changed:

   What|Removed |Added

   Assignee|psab...@redhat.com  |p...@city-fan.org



-- 
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
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

rawhide report: 20150816 changes

[Fedora Rawhide Report]

Compose started at Sun Aug 16 05:15:03 UTC 2015
Broken deps for i386
--
[IQmol]
IQmol-2.3.0-6.fc23.i686 requires libboost_serialization.so.1.57.0
IQmol-2.3.0-6.fc23.i686 requires libboost_iostreams.so.1.57.0
[ScientificPython]
ScientificPython-2.8-20.fc22.i686 requires libmpi.so.1
[adobe-source-libraries]
adobe-source-libraries-1.0.43-24.fc22.i686 requires 
libboost_thread.so.1.57.0
adobe-source-libraries-1.0.43-24.fc22.i686 requires 
libboost_system.so.1.57.0
adobe-source-libraries-1.0.43-24.fc22.i686 requires 
libboost_signals.so.1.57.0
[apache-scout]
apache-scout-1.2.6-11.fc21.noarch requires mvn(org.apache.juddi:uddi-ws)
apache-scout-1.2.6-11.fc21.noarch requires 
mvn(org.apache.juddi:juddi-client)
[aws]
aws-tools-2015-2.fc23.i686 requires libaws_ssl.so
[cp2k]
cp2k-mpich-2.6.0-4.fc23.i686 requires libscalapack.so.2
cp2k-mpich-2.6.0-4.fc23.i686 requires libmpifort.so.12
cp2k-mpich-2.6.0-4.fc23.i686 requires libmpiblacs.so.2
cp2k-mpich-2.6.0-4.fc23.i686 requires libmpi.so.12
cp2k-mpich-2.6.0-4.fc23.i686 requires libelpa.so.3
cp2k-openmpi-2.6.0-4.fc23.i686 requires libscalapack.so.2
cp2k-openmpi-2.6.0-4.fc23.i686 requires libmpiblacs.so.2
cp2k-openmpi-2.6.0-4.fc23.i686 requires libmpi_usempif08.so.0
cp2k-openmpi-2.6.0-4.fc23.i686 requires libmpi_usempi_ignore_tkr.so.0
cp2k-openmpi-2.6.0-4.fc23.i686 requires libmpi_mpifh.so.2
cp2k-openmpi-2.6.0-4.fc23.i686 requires libmpi.so.1
cp2k-openmpi-2.6.0-4.fc23.i686 requires libelpa.so.3
[darcs]
darcs-2.8.5-3.fc23.i686 requires libHStar-0.4.0.1-ghc7.8.4.so
darcs-2.8.5-3.fc23.i686 requires 
ghc(tar-0.4.0.1-88996a8f4fefe5700b5394aaa2fa845d)
ghc-darcs-2.8.5-3.fc23.i686 requires libHStar-0.4.0.1-ghc7.8.4.so
ghc-darcs-2.8.5-3.fc23.i686 requires 
ghc(tar-0.4.0.1-88996a8f4fefe5700b5394aaa2fa845d)
ghc-darcs-devel-2.8.5-3.fc23.i686 requires 
ghc-devel(tar-0.4.0.1-88996a8f4fefe5700b5394aaa2fa845d)
[dpm-contrib-admintools]
dpm-contrib-admintools-0.2.1-6.fc23.i686 requires MySQL-python(x86-32)
[elasticsearch]
elasticsearch-1.7.1-1.fc24.noarch requires lucene4-sandbox
[elektra]
elektra-0.8.12-2.fc24.i686 requires libelektratools-full.so
elektra-0.8.12-2.fc24.i686 requires libelektra-full.so.4
[ghc-citeproc-hs]
ghc-citeproc-hs-0.3.9-6.fc23.i686 requires libHSxml-1.3.13-ghc7.8.4.so
ghc-citeproc-hs-0.3.9-6.fc23.i686 requires 
ghc(xml-1.3.13-62bfe61c33b8015ab0b36aed75278ed2)
ghc-citeproc-hs-devel-0.3.9-6.fc23.i686 requires 
ghc-devel(xml-1.3.13-62bfe61c33b8015ab0b36aed75278ed2)
[ghc-hakyll]
ghc-hakyll-4.5.4.0-3.fc23.i686 requires libHSxml-1.3.13-ghc7.8.4.so
[ghc-scotty]
ghc-scotty-0.9.0-3.fc23.i686 requires 
libHSstringsearch-0.3.6.5-ghc7.8.4.so
[ghc-texmath]
ghc-texmath-0.8.0.1-3.fc23.i686 requires libHSxml-1.3.13-ghc7.8.4.so
ghc-texmath-0.8.0.1-3.fc23.i686 requires 
ghc(xml-1.3.13-62bfe61c33b8015ab0b36aed75278ed2)
ghc-texmath-devel-0.8.0.1-3.fc23.i686 requires 
ghc-devel(xml-1.3.13-62bfe61c33b8015ab0b36aed75278ed2)
[ghc-wai-extra]
ghc-wai-extra-3.0.4.5-2.fc23.i686 requires 
libHSstringsearch-0.3.6.5-ghc7.8.4.so
ghc-wai-extra-3.0.4.5-2.fc23.i686 requires 
ghc(stringsearch-0.3.6.5-7f7d1930cd1bcb2865db7caec97dd82d)
ghc-wai-extra-devel-3.0.4.5-2.fc23.i686 requires 
ghc-devel(stringsearch-0.3.6.5-7f7d1930cd1bcb2865db7caec97dd82d)
[gnatcoll]
gnatcoll-2014-4.fc23.i686 requires libgtkada-3.8.so.2
[gnome-python2]
gnome-python2-bonobo-2.28.1-16.fc23.i686 requires pyorbit(x86-32) = 
0:2.0.1
[golang-github-influxdb-influxdb]
golang-github-influxdb-influxdb-devel-0.8.5-0.2.git9485e99.fc23.noarch 
requires golang(github.com/rakyll/statik)
[gtksourceview-sharp]
gtksourceview-sharp-2.0.12-24.fc23.i686 requires gtksourceview
[hadoop]
hadoop-common-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey:jersey-servlet)
hadoop-common-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey:jersey-server)
hadoop-common-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey:jersey-json)
hadoop-common-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey:jersey-core)
hadoop-hdfs-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey:jersey-server)
hadoop-hdfs-2.4.1-8.fc22.noarch requires mvn(com.sun.jersey:jersey-core)
hadoop-mapreduce-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey:jersey-server)
hadoop-mapreduce-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey.contribs:jersey-guice)
hadoop-tests-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey:jersey-servlet)
hadoop-tests-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey:jersey-server)
hadoop-tests-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey:jersey-json)

F-23 Branched report: 20150816 changes

[Fedora Branched Report]

Compose started at Sun Aug 16 07:15:02 UTC 2015
Broken deps for armhfp
--
[apache-scout]
apache-scout-1.2.6-11.fc21.noarch requires mvn(org.apache.juddi:uddi-ws)
apache-scout-1.2.6-11.fc21.noarch requires 
mvn(org.apache.juddi:juddi-client)
[aws]
aws-tools-2015-2.fc23.armv7hl requires libaws_ssl.so
[cduce]
cduce-0.6.0-13.fc23.armv7hl requires ocaml(Curl) = 
0:c9482fe21d30ad4b5f1ca281b3da3d99
[dpm-contrib-admintools]
dpm-contrib-admintools-0.2.1-6.fc23.armv7hl requires 
MySQL-python(armv7hl-32)
[dpm-dsi]
dpm-dsi-1.9.5-6.fc23.armv7hl requires 
globus-gridftp-server-progs(armv7hl-32) = 0:8.0
[gammaray]
gammaray-qt5-2.2.1-10.fc23.armv7hl requires qt5-qtbase(armv7hl-32) = 
0:5.4.2
[gnome-python2]
gnome-python2-bonobo-2.28.1-16.fc23.armv7hl requires 
pyorbit(armv7hl-32) = 0:2.0.1
[gnome-shell-extension-pomodoro]
gnome-shell-extension-pomodoro-0.11.0-0.3.gitc7ad79d3.fc23.armv7hl 
requires libgnome-desktop-3.so.10
[gtksourceview-sharp]
gtksourceview-sharp-2.0.12-24.fc23.armv7hl requires gtksourceview
[hadoop]
hadoop-common-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey:jersey-servlet)
hadoop-common-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey:jersey-server)
hadoop-common-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey:jersey-json)
hadoop-common-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey:jersey-core)
hadoop-hdfs-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey:jersey-server)
hadoop-hdfs-2.4.1-8.fc22.noarch requires mvn(com.sun.jersey:jersey-core)
hadoop-mapreduce-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey:jersey-server)
hadoop-mapreduce-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey.contribs:jersey-guice)
hadoop-tests-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey:jersey-servlet)
hadoop-tests-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey:jersey-server)
hadoop-tests-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey:jersey-json)
hadoop-tests-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey:jersey-core)
hadoop-tests-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey:jersey-client)
hadoop-tests-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey.contribs:jersey-guice)
hadoop-yarn-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey:jersey-server)
hadoop-yarn-2.4.1-8.fc22.noarch requires mvn(com.sun.jersey:jersey-json)
hadoop-yarn-2.4.1-8.fc22.noarch requires mvn(com.sun.jersey:jersey-core)
hadoop-yarn-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey:jersey-client)
hadoop-yarn-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey.contribs:jersey-guice)
[hawaii-shell]
hawaii-shell-0.3.0-3.fc22.armv7hl requires 
libqtaccountsservice-qt5.so.0.1.2
[hbase]
hbase-0.98.3-4.fc22.noarch requires mvn(com.sun.jersey:jersey-server)
hbase-0.98.3-4.fc22.noarch requires mvn(com.sun.jersey:jersey-json)
hbase-0.98.3-4.fc22.noarch requires mvn(com.sun.jersey:jersey-core)
hbase-tests-0.98.3-4.fc22.noarch requires 
mvn(com.sun.jersey:jersey-server)
hbase-tests-0.98.3-4.fc22.noarch requires 
mvn(com.sun.jersey:jersey-json)
hbase-tests-0.98.3-4.fc22.noarch requires 
mvn(com.sun.jersey:jersey-core)
[klavaro]
klavaro-3.01-0.pre1.1.fc23.1.armv7hl requires libgtkdataboks.so.0
[mariadb-galera]
1:mariadb-galera-server-10.0.17-5.fc23.armv7hl requires galera = 
0:25.3.3
[mesos]
mesos-0.22.0-SNAPSHOT.1.c513126.fc22.1.armv7hl requires libprotobuf.so.8
python-mesos-0.22.0-SNAPSHOT.1.c513126.fc22.1.armv7hl requires 
libprotobuf.so.8
[moon-buggy]
moon-buggy-1.0.51-14.fc23.armv7hl requires libesd.so.0
[ncbi-blast+]
ncbi-blast+-2.2.31-1.fc23.armv7hl requires libxformat.so
ncbi-blast+-2.2.31-1.fc23.armv7hl requires libxcleanup.so
ncbi-blast+-2.2.31-1.fc23.armv7hl requires libvalid.so
ncbi-blast+-2.2.31-1.fc23.armv7hl requires libpubmed.so
ncbi-blast+-2.2.31-1.fc23.armv7hl requires libmlacli.so
ncbi-blast+-2.2.31-1.fc23.armv7hl requires libmla.so
ncbi-blast+-2.2.31-1.fc23.armv7hl requires libmedlars.so
ncbi-blast+-2.2.31-1.fc23.armv7hl requires libgbseq.so
[netbeans-platform]
1:netbeans-platform-harness-7.0.1-11.fc22.armv7hl requires cobertura = 
0:1.9.3
[nodejs-got]
nodejs-got-3.3.0-1.fc23.noarch requires npm(object-assign)  0:3
[nodejs-grunt-contrib-copy]
nodejs-grunt-contrib-copy-0.8.0-2.fc23.noarch requires 
npm(file-sync-cmp)  0:0.2
nodejs-grunt-contrib-copy-0.8.0-2.fc23.noarch requires 
npm(file-sync-cmp) = 0:0.1.0
nodejs-grunt-contrib-copy-0.8.0-2.fc23.noarch requires npm(chalk) = 
0:0.5.1
[nodejs-grunt-saucelabs]
nodejs-grunt-saucelabs-8.6.1-2.fc23.noarch requires npm(sauce-tunnel) 
= 0:2.2.3
nodejs-grunt-saucelabs-8.6.1-2.fc23.noarch requires 

pghmcfc pushed to perl-Devel-PartialDump (perl-Devel-PartialDump-0.18-1.fc23). Update to 0.18 (..more)

[notifications]

From 192b67ddd3ee9de7b06615d2bcef2aa9d94ee9f8 Mon Sep 17 00:00:00 2001
From: Paul Howarth p...@city-fan.org
Date: Sun, 16 Aug 2015 13:20:07 +0100
Subject: Update to 0.18

- New upstream release 0.18
  - Update some distribution tooling
- Switch to ExtUtils::MakeMaker flow

diff --git a/perl-Devel-PartialDump.spec b/perl-Devel-PartialDump.spec
index 4fe6c77..0aa4dea 100644
--- a/perl-Devel-PartialDump.spec
+++ b/perl-Devel-PartialDump.spec
@@ -1,19 +1,21 @@
 Name:   perl-Devel-PartialDump
-Version:0.17
-Release:3%{?dist}
+Version:0.18
+Release:1%{?dist}
 Summary:Partial dumping of data structures, optimized for argument 
printing
 License:GPL+ or Artistic
 URL:http://search.cpan.org/dist/Devel-PartialDump/
 Source0:
http://www.cpan.org/authors/id/E/ET/ETHER/Devel-PartialDump-%{version}.tar.gz
 BuildArch:  noarch
 # Module Build
+BuildRequires:  coreutils
+BuildRequires:  findutils
+BuildRequires:  make
 BuildRequires:  perl
-BuildRequires:  perl(Module::Build::Tiny) = 0.030
+BuildRequires:  perl(ExtUtils::MakeMaker)
 # Module Runtime
 BuildRequires:  perl(Carp)
-BuildRequires:  perl(Carp::Heavy)
 BuildRequires:  perl(Class::Tiny)
-BuildRequires:  perl(namespace::clean) = 0.20
+BuildRequires:  perl(namespace::clean) = 0.19
 BuildRequires:  perl(overload)
 BuildRequires:  perl(Scalar::Util)
 BuildRequires:  perl(strict)
@@ -23,14 +25,12 @@ BuildRequires:  perl(warnings)
 BuildRequires:  perl(CPAN::Meta)
 BuildRequires:  perl(CPAN::Meta::Requirements)
 BuildRequires:  perl(ExtUtils::MakeMaker)
-BuildRequires:  perl(File::Spec::Functions)
-BuildRequires:  perl(List::Util)
+BuildRequires:  perl(File::Spec)
 BuildRequires:  perl(ok)
 BuildRequires:  perl(Test::More) = 0.94
 BuildRequires:  perl(Test::Warn)
 # Runtime
 Requires:   perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
-Requires:   perl(Carp::Heavy)
 Requires:   perl(overload)
 
 # Filter bogus provide of perl(DB)
@@ -43,22 +43,30 @@ This module is a data dumper optimized for logging of 
arbitrary parameters.
 %setup -q -n Devel-PartialDump-%{version}
 
 %build
-perl Build.PL --installdirs=vendor
-./Build
+perl Makefile.PL INSTALLDIRS=vendor
+make %{?_smp_mflags}
 
 %install
-./Build install --destdir=%{buildroot} --create_packlist=0
+rm -rf %{buildroot}
+make pure_install DESTDIR=%{buildroot}
+find %{buildroot} -type f -name .packlist -exec rm -f {} ';'
+%{_fixperms} %{buildroot}
 
 %check
-./Build test
+make test
 
 %files
 %license LICENSE
-%doc Changes CONTRIBUTING README.md
+%doc Changes CONTRIBUTING README
 %{perl_vendorlib}/Devel/
 %{_mandir}/man3/Devel::PartialDump.3*
 
 %changelog
+* Sun Aug 16 2015 Paul Howarth p...@city-fan.org - 0.18-1
+- Update to 0.18
+  - Update some distribution tooling
+- Switch to ExtUtils::MakeMaker flow
+
 * Thu Jun 18 2015 Fedora Release Engineering rel-...@lists.fedoraproject.org 
- 0.17-3
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_23_Mass_Rebuild
 
diff --git a/sources b/sources
index 474c739..76c07b3 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-c076e685aa184dede1454b3bea3430fa  Devel-PartialDump-0.17.tar.gz
+eb6045e1ae8860f21631fe046125fd98  Devel-PartialDump-0.18.tar.gz
-- 
cgit v0.10.2



http://pkgs.fedoraproject.org/cgit/perl-Devel-PartialDump.git/commit/?h=perl-Devel-PartialDump-0.18-1.fc23id=192b67ddd3ee9de7b06615d2bcef2aa9d94ee9f8
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[Bug 1253987] perl-Devel-PartialDump-0.18 is available

[bugzilla]

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



--- Comment #1 from Fedora Update System upda...@fedoraproject.org ---
perl-Devel-PartialDump-0.18-1.fc23 has been submitted as an update for Fedora
23.
https://admin.fedoraproject.org/updates/perl-Devel-PartialDump-0.18-1.fc23

-- 
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
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

pghmcfc pushed to perl-Devel-PartialDump (perl-Devel-PartialDump-0.18-1.fc24). Update to 0.18 (..more)

[notifications]

This commit already existed in another branch.

http://pkgs.fedoraproject.org/cgit/perl-Devel-PartialDump.git/commit/?h=perl-Devel-PartialDump-0.18-1.fc24id=192b67ddd3ee9de7b06615d2bcef2aa9d94ee9f8
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: noarch vs. all, x86_64 vs. amd64, kernel vs. linux and PAE

[Felix Miata]

Roberto Ragusa composed on 2015-08-16 10:47 (UTC+0200):

 dropping an underscore is nice too

That would be wonderful. Underscore is an contortive nuisance trying to touch
type top row with one pinkie while shifting with other pinkie, not to mention
even to see it when font is small or contrast low.
-- 
The wise are known for their understanding, and pleasant
words are persuasive. Proverbs 16:21 (New Living Translation)

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Broken dependencies: perl-Task-Catalyst

[buildsys]

perl-Task-Catalyst has broken dependencies in the F-23 tree:
On x86_64:
perl-Task-Catalyst-4.02-8.fc22.noarch requires 
perl(:MODULE_COMPAT_5.20.0)
On i386:
perl-Task-Catalyst-4.02-8.fc22.noarch requires 
perl(:MODULE_COMPAT_5.20.0)
On armhfp:
perl-Task-Catalyst-4.02-8.fc22.noarch requires 
perl(:MODULE_COMPAT_5.20.0)
Please resolve this as soon as possible.


--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Broken dependencies: perl-Carp-REPL

[buildsys]

perl-Carp-REPL has broken dependencies in the F-23 tree:
On x86_64:
perl-Carp-REPL-0.18-1.fc23.noarch requires perl(:MODULE_COMPAT_5.20.2)
On i386:
perl-Carp-REPL-0.18-1.fc23.noarch requires perl(:MODULE_COMPAT_5.20.2)
On armhfp:
perl-Carp-REPL-0.18-1.fc23.noarch requires perl(:MODULE_COMPAT_5.20.2)
Please resolve this as soon as possible.


--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Broken dependencies: perl-CatalystX-REPL

[buildsys]

perl-CatalystX-REPL has broken dependencies in the F-23 tree:
On x86_64:
perl-CatalystX-REPL-0.04-10.fc22.noarch requires 
perl(:MODULE_COMPAT_5.20.0)
On i386:
perl-CatalystX-REPL-0.04-10.fc22.noarch requires 
perl(:MODULE_COMPAT_5.20.0)
On armhfp:
perl-CatalystX-REPL-0.04-10.fc22.noarch requires 
perl(:MODULE_COMPAT_5.20.0)
Please resolve this as soon as possible.


--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Broken dependencies: perl-B-Hooks-OP-Check-EntersubForCV

[buildsys]

perl-B-Hooks-OP-Check-EntersubForCV has broken dependencies in the F-23 tree:
On x86_64:
perl-B-Hooks-OP-Check-EntersubForCV-0.09-10.fc22.x86_64 requires 
perl(:MODULE_COMPAT_5.20.0)
perl-B-Hooks-OP-Check-EntersubForCV-0.09-10.fc22.x86_64 requires 
libperl.so.5.20()(64bit)
On i386:
perl-B-Hooks-OP-Check-EntersubForCV-0.09-10.fc22.i686 requires 
perl(:MODULE_COMPAT_5.20.0)
perl-B-Hooks-OP-Check-EntersubForCV-0.09-10.fc22.i686 requires 
libperl.so.5.20
On armhfp:
perl-B-Hooks-OP-Check-EntersubForCV-0.09-10.fc22.armv7hl requires 
perl(:MODULE_COMPAT_5.20.0)
perl-B-Hooks-OP-Check-EntersubForCV-0.09-10.fc22.armv7hl requires 
libperl.so.5.20
Please resolve this as soon as possible.


--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Broken dependencies: perl-Test-AutoBuild

[buildsys]

perl-Test-AutoBuild has broken dependencies in the F-23 tree:
On x86_64:
perl-Test-AutoBuild-1.2.4-15.fc22.x86_64 requires 
perl(:MODULE_COMPAT_5.20.0)
On i386:
perl-Test-AutoBuild-1.2.4-15.fc22.i686 requires 
perl(:MODULE_COMPAT_5.20.0)
On armhfp:
perl-Test-AutoBuild-1.2.4-15.fc22.armv7hl requires 
perl(:MODULE_COMPAT_5.20.0)
Please resolve this as soon as possible.


--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Broken dependencies: perl-MongoDB

[buildsys]

perl-MongoDB has broken dependencies in the F-23 tree:
On x86_64:
perl-MongoDB-0.702.2-5.fc22.x86_64 requires perl(:MODULE_COMPAT_5.20.0)
perl-MongoDB-0.702.2-5.fc22.x86_64 requires libperl.so.5.20()(64bit)
On i386:
perl-MongoDB-0.702.2-5.fc22.i686 requires perl(:MODULE_COMPAT_5.20.0)
perl-MongoDB-0.702.2-5.fc22.i686 requires libperl.so.5.20
On armhfp:
perl-MongoDB-0.702.2-5.fc22.armv7hl requires perl(:MODULE_COMPAT_5.20.0)
perl-MongoDB-0.702.2-5.fc22.armv7hl requires libperl.so.5.20
Please resolve this as soon as possible.


--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Broken dependencies: perl-Method-Signatures

[buildsys]

perl-Method-Signatures has broken dependencies in the F-23 tree:
On x86_64:
perl-Method-Signatures-20141021-1.fc22.noarch requires 
perl(:MODULE_COMPAT_5.20.1)
On i386:
perl-Method-Signatures-20141021-1.fc22.noarch requires 
perl(:MODULE_COMPAT_5.20.1)
On armhfp:
perl-Method-Signatures-20141021-1.fc22.noarch requires 
perl(:MODULE_COMPAT_5.20.1)
Please resolve this as soon as possible.


--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Broken dependencies: perl-Data-Dump-Streamer

[buildsys]

perl-Data-Dump-Streamer has broken dependencies in the F-23 tree:
On x86_64:
perl-Data-Dump-Streamer-2.38-3.fc22.x86_64 requires 
perl(:MODULE_COMPAT_5.20.0)
perl-Data-Dump-Streamer-2.38-3.fc22.x86_64 requires 
libperl.so.5.20()(64bit)
On i386:
perl-Data-Dump-Streamer-2.38-3.fc22.i686 requires 
perl(:MODULE_COMPAT_5.20.0)
perl-Data-Dump-Streamer-2.38-3.fc22.i686 requires libperl.so.5.20
On armhfp:
perl-Data-Dump-Streamer-2.38-3.fc22.armv7hl requires 
perl(:MODULE_COMPAT_5.20.0)
perl-Data-Dump-Streamer-2.38-3.fc22.armv7hl requires libperl.so.5.20
Please resolve this as soon as possible.


--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Broken dependencies: perl-Devel-BeginLift

[buildsys]

perl-Devel-BeginLift has broken dependencies in the F-23 tree:
On x86_64:
perl-Devel-BeginLift-0.001003-9.fc22.x86_64 requires 
perl(:MODULE_COMPAT_5.20.0)
perl-Devel-BeginLift-0.001003-9.fc22.x86_64 requires 
libperl.so.5.20()(64bit)
On i386:
perl-Devel-BeginLift-0.001003-9.fc22.i686 requires 
perl(:MODULE_COMPAT_5.20.0)
perl-Devel-BeginLift-0.001003-9.fc22.i686 requires libperl.so.5.20
On armhfp:
perl-Devel-BeginLift-0.001003-9.fc22.armv7hl requires 
perl(:MODULE_COMPAT_5.20.0)
perl-Devel-BeginLift-0.001003-9.fc22.armv7hl requires libperl.so.5.20
Please resolve this as soon as possible.


--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Broken dependencies: perl-Test-Vars

[buildsys]

perl-Test-Vars has broken dependencies in the F-23 tree:
On x86_64:
perl-Test-Vars-0.005-6.fc22.noarch requires perl(:MODULE_COMPAT_5.20.0)
On i386:
perl-Test-Vars-0.005-6.fc22.noarch requires perl(:MODULE_COMPAT_5.20.0)
On armhfp:
perl-Test-Vars-0.005-6.fc22.noarch requires perl(:MODULE_COMPAT_5.20.0)
Please resolve this as soon as possible.


--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Broken dependencies: perl-Data-Alias

[buildsys]

perl-Data-Alias has broken dependencies in the F-23 tree:
On x86_64:
perl-Data-Alias-1.18-4.fc22.x86_64 requires perl(:MODULE_COMPAT_5.20.0)
perl-Data-Alias-1.18-4.fc22.x86_64 requires libperl.so.5.20()(64bit)
On i386:
perl-Data-Alias-1.18-4.fc22.i686 requires perl(:MODULE_COMPAT_5.20.0)
perl-Data-Alias-1.18-4.fc22.i686 requires libperl.so.5.20
On armhfp:
perl-Data-Alias-1.18-4.fc22.armv7hl requires perl(:MODULE_COMPAT_5.20.0)
perl-Data-Alias-1.18-4.fc22.armv7hl requires libperl.so.5.20
Please resolve this as soon as possible.


--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Broken dependencies: perl-POE-API-Peek

[buildsys]

perl-POE-API-Peek has broken dependencies in the F-23 tree:
On x86_64:
1:perl-POE-API-Peek-2.20-8.fc22.noarch requires 
perl(:MODULE_COMPAT_5.20.0)
On i386:
1:perl-POE-API-Peek-2.20-8.fc22.noarch requires 
perl(:MODULE_COMPAT_5.20.0)
On armhfp:
1:perl-POE-API-Peek-2.20-8.fc22.noarch requires 
perl(:MODULE_COMPAT_5.20.0)
Please resolve this as soon as possible.


--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Broken dependencies: polymake

[buildsys]

polymake has broken dependencies in the F-23 tree:
On x86_64:
polymake-2.13-22.git20141013.fc23.x86_64 requires 
perl(:MODULE_COMPAT_5.20.2)
polymake-2.13-22.git20141013.fc23.x86_64 requires perl = 4:5.20.2
polymake-2.13-22.git20141013.fc23.x86_64 requires 
libperl.so.5.20()(64bit)
On i386:
polymake-2.13-22.git20141013.fc23.i686 requires 
perl(:MODULE_COMPAT_5.20.2)
polymake-2.13-22.git20141013.fc23.i686 requires perl = 4:5.20.2
polymake-2.13-22.git20141013.fc23.i686 requires libperl.so.5.20
On armhfp:
polymake-2.13-22.git20141013.fc23.armv7hl requires 
perl(:MODULE_COMPAT_5.20.2)
polymake-2.13-22.git20141013.fc23.armv7hl requires perl = 4:5.20.2
polymake-2.13-22.git20141013.fc23.armv7hl requires libperl.so.5.20
Please resolve this as soon as possible.


--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Broken dependencies: perl-Devel-FindRef

[buildsys]

perl-Devel-FindRef has broken dependencies in the F-23 tree:
On x86_64:
perl-Devel-FindRef-1.44-3.fc22.x86_64 requires 
perl(:MODULE_COMPAT_5.20.0)
perl-Devel-FindRef-1.44-3.fc22.x86_64 requires libperl.so.5.20()(64bit)
On i386:
perl-Devel-FindRef-1.44-3.fc22.i686 requires perl(:MODULE_COMPAT_5.20.0)
perl-Devel-FindRef-1.44-3.fc22.i686 requires libperl.so.5.20
On armhfp:
perl-Devel-FindRef-1.44-3.fc22.armv7hl requires 
perl(:MODULE_COMPAT_5.20.0)
perl-Devel-FindRef-1.44-3.fc22.armv7hl requires libperl.so.5.20
Please resolve this as soon as possible.


--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Broken dependencies: perl-CGI-Application-Structured-Tools

[buildsys]

perl-CGI-Application-Structured-Tools has broken dependencies in the F-23 tree:
On x86_64:
perl-CGI-Application-Structured-Tools-0.015-7.fc22.noarch requires 
perl(:MODULE_COMPAT_5.20.0)
On i386:
perl-CGI-Application-Structured-Tools-0.015-7.fc22.noarch requires 
perl(:MODULE_COMPAT_5.20.0)
On armhfp:
perl-CGI-Application-Structured-Tools-0.015-7.fc22.noarch requires 
perl(:MODULE_COMPAT_5.20.0)
Please resolve this as soon as possible.


--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[Bug 1253988] New: perl-Devel-REPL-1.003027 is available

[bugzilla]

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

Bug ID: 1253988
   Summary: perl-Devel-REPL-1.003027 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Devel-REPL
  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: 1.003027
Current version/release in rawhide: 1.003026-3.fc23
URL: http://search.cpan.org/dist/Devel-REPL/

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
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[Bug 1253987] New: perl-Devel-PartialDump-0.18 is available

[bugzilla]

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

Bug ID: 1253987
   Summary: perl-Devel-PartialDump-0.18 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Devel-PartialDump
  Keywords: FutureFeature, Triaged
  Assignee: psab...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: iarn...@gmail.com, p...@city-fan.org,
perl-devel@lists.fedoraproject.org, psab...@redhat.com



Latest upstream release: 0.18
Current version/release in rawhide: 0.17-3.fc23
URL: http://search.cpan.org/dist/Devel-PartialDump/

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
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[Bug 1253989] New: perl-Dist-Zilla-Plugin-Test-Compile-2.054 is available

[bugzilla]

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

Bug ID: 1253989
   Summary: perl-Dist-Zilla-Plugin-Test-Compile-2.054 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Dist-Zilla-Plugin-Test-Compile
  Keywords: FutureFeature, Triaged
  Assignee: psab...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: jples...@redhat.com,
perl-devel@lists.fedoraproject.org, ppi...@redhat.com,
psab...@redhat.com



Latest upstream release: 2.054
Current version/release in rawhide: 2.053-3.fc23
URL: http://search.cpan.org/dist/Dist-Zilla-Plugin-Test-Compile/

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
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

pghmcfc uploaded Devel-PartialDump-0.18.tar.gz for perl-Devel-PartialDump

[notifications]

eb6045e1ae8860f21631fe046125fd98  Devel-PartialDump-0.18.tar.gz

http://pkgs.fedoraproject.org/lookaside/pkgs/perl-Devel-PartialDump/Devel-PartialDump-0.18.tar.gz/md5/eb6045e1ae8860f21631fe046125fd98/Devel-PartialDump-0.18.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

pghmcfc pushed to perl-Devel-PartialDump (master). Update to 0.18 (..more)

[notifications]

From 192b67ddd3ee9de7b06615d2bcef2aa9d94ee9f8 Mon Sep 17 00:00:00 2001
From: Paul Howarth p...@city-fan.org
Date: Sun, 16 Aug 2015 13:20:07 +0100
Subject: Update to 0.18

- New upstream release 0.18
  - Update some distribution tooling
- Switch to ExtUtils::MakeMaker flow

diff --git a/perl-Devel-PartialDump.spec b/perl-Devel-PartialDump.spec
index 4fe6c77..0aa4dea 100644
--- a/perl-Devel-PartialDump.spec
+++ b/perl-Devel-PartialDump.spec
@@ -1,19 +1,21 @@
 Name:   perl-Devel-PartialDump
-Version:0.17
-Release:3%{?dist}
+Version:0.18
+Release:1%{?dist}
 Summary:Partial dumping of data structures, optimized for argument 
printing
 License:GPL+ or Artistic
 URL:http://search.cpan.org/dist/Devel-PartialDump/
 Source0:
http://www.cpan.org/authors/id/E/ET/ETHER/Devel-PartialDump-%{version}.tar.gz
 BuildArch:  noarch
 # Module Build
+BuildRequires:  coreutils
+BuildRequires:  findutils
+BuildRequires:  make
 BuildRequires:  perl
-BuildRequires:  perl(Module::Build::Tiny) = 0.030
+BuildRequires:  perl(ExtUtils::MakeMaker)
 # Module Runtime
 BuildRequires:  perl(Carp)
-BuildRequires:  perl(Carp::Heavy)
 BuildRequires:  perl(Class::Tiny)
-BuildRequires:  perl(namespace::clean) = 0.20
+BuildRequires:  perl(namespace::clean) = 0.19
 BuildRequires:  perl(overload)
 BuildRequires:  perl(Scalar::Util)
 BuildRequires:  perl(strict)
@@ -23,14 +25,12 @@ BuildRequires:  perl(warnings)
 BuildRequires:  perl(CPAN::Meta)
 BuildRequires:  perl(CPAN::Meta::Requirements)
 BuildRequires:  perl(ExtUtils::MakeMaker)
-BuildRequires:  perl(File::Spec::Functions)
-BuildRequires:  perl(List::Util)
+BuildRequires:  perl(File::Spec)
 BuildRequires:  perl(ok)
 BuildRequires:  perl(Test::More) = 0.94
 BuildRequires:  perl(Test::Warn)
 # Runtime
 Requires:   perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
-Requires:   perl(Carp::Heavy)
 Requires:   perl(overload)
 
 # Filter bogus provide of perl(DB)
@@ -43,22 +43,30 @@ This module is a data dumper optimized for logging of 
arbitrary parameters.
 %setup -q -n Devel-PartialDump-%{version}
 
 %build
-perl Build.PL --installdirs=vendor
-./Build
+perl Makefile.PL INSTALLDIRS=vendor
+make %{?_smp_mflags}
 
 %install
-./Build install --destdir=%{buildroot} --create_packlist=0
+rm -rf %{buildroot}
+make pure_install DESTDIR=%{buildroot}
+find %{buildroot} -type f -name .packlist -exec rm -f {} ';'
+%{_fixperms} %{buildroot}
 
 %check
-./Build test
+make test
 
 %files
 %license LICENSE
-%doc Changes CONTRIBUTING README.md
+%doc Changes CONTRIBUTING README
 %{perl_vendorlib}/Devel/
 %{_mandir}/man3/Devel::PartialDump.3*
 
 %changelog
+* Sun Aug 16 2015 Paul Howarth p...@city-fan.org - 0.18-1
+- Update to 0.18
+  - Update some distribution tooling
+- Switch to ExtUtils::MakeMaker flow
+
 * Thu Jun 18 2015 Fedora Release Engineering rel-...@lists.fedoraproject.org 
- 0.17-3
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_23_Mass_Rebuild
 
diff --git a/sources b/sources
index 474c739..76c07b3 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-c076e685aa184dede1454b3bea3430fa  Devel-PartialDump-0.17.tar.gz
+eb6045e1ae8860f21631fe046125fd98  Devel-PartialDump-0.18.tar.gz
-- 
cgit v0.10.2



http://pkgs.fedoraproject.org/cgit/perl-Devel-PartialDump.git/commit/?h=masterid=192b67ddd3ee9de7b06615d2bcef2aa9d94ee9f8
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: noarch vs. all, x86_64 vs. amd64, kernel vs. linux and PAE

[Josh Boyer]

On Aug 16, 2015 12:50 PM, Reindl Harald h.rei...@thelounge.net wrote:



 Am 16.08.2015 um 18:14 schrieb Roberto Ragusa:

 On 08/16/2015 10:55 AM, Reindl Harald wrote:


 no the architecture was created by Intel

 AMD added the 64bit capabilities in a compatible way other than Intel
itself tried with Itanium which was not able to run i686 instructions and
later Intel was forced to license the AMD extensions


 Well, saying that the architecture was created by Intel is an evident
 rewrite the history exercise.


 no, the main architecture is still Intel
 AMD extended it and Intel adopted the extenisons

 but *the point* is that calling it AMD64 is *plain wrong* because
AMD/Inetl *and others* are using *the same* architecture and using a AMD64
suffix would imply that binary is for AMD CPU's only which is wrong


 You immediately contradict in the second sentence, where you describe
the IA64 fiasco,
 and the adoption of AMD64 by Intel.
 Or maybe you think that licensing the AMD extensions is equivalent to
the architecture
 was created by Intel?

 Let's recap how it really went:

 - Intel designed a new incompatible arch (IA64), it was useless at
emulating the i386
 and was a substantial market failure
 - AMD designed the AMD64, as an extension if IA32
 - Linux was running on AMD64 immediately at day 0, as AMD had been
giving around simulators
 for chips not created yet
 - Microsoft, who had already ported Windows to IA64, created an AMD64
version too
 - Intel tried to avoid the humiliating acceptance that their rivals did
a better job
 than them, by going to extend the ia32 in a different way
 - Microsoft told Intel I already did a port for you, you do not dare
asking me another
 - Intel released the EM64T architecture
 - Linus wrote a furious email saying that he had spent time studying the
EM64T manuals
 only to finally realize that it could all have been replaced with just
the sentence
 it's AMD64 (differences are only found in little details)

 Nowadays some use AMD64 and some x86_64, with Intel preferring the
second for obvious reasons.


 i know the history well, long enough in the business


 Having said that, the cost of change has got probably too high, so we
will keep
 the current mix of AMD64 (used by BSD, Windows, Solaris, Java, Debian)
 and x86_64 (used by Linux, Fedora, SuSE, gcc)


 it's not a point of costs
 it's simply plain wrong

 and just because Debian is here wrong as well as calling the httpd
package apache don't make it right

OK you can stop this thread now.  We aren't going to change in any case and
it doesn't matter which of you is correct here.

If you really must argue further please do it off list.

josh
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[Bug 1241821] Please update to = 1.300011 to let bugzilla 5.0 run.

[bugzilla]

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



--- Comment #5 from Emmanuel Seyman emman...@seyman.fr ---
(In reply to Emmanuel Seyman from comment #3)

 I'll keep this bug updated with my actions.

JFTR, perl-Email-Send requires perl-Moo and a number of other things. These
were unmaintained when RHEL-7 was released. I suspect using the versions in
Rawhide is going to fail horribly so this is going to be more complicated than
I thought.

-- 
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
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

eseyman pushed to perl-IO-Async (master). Update to 0.68, disabling a new test as we go

[notifications]

From 7cf56edc8632697982f743f32e1cac50aa4c0289 Mon Sep 17 00:00:00 2001
From: Emmanuel Seyman emman...@seyman.fr
Date: Sun, 16 Aug 2015 16:21:45 +0200
Subject: Update to 0.68, disabling a new test as we go


diff --git a/.gitignore b/.gitignore
index 8e9baa1..f77f48c 100644
--- a/.gitignore
+++ b/.gitignore
@@ -10,3 +10,4 @@ IO-Async-0.28.tar.gz
 /IO-Async-0.65.tar.gz
 /IO-Async-0.66.tar.gz
 /IO-Async-0.67.tar.gz
+/IO-Async-0.68.tar.gz
diff --git a/IO-Async-0.68-disable-resolver-test.patch 
b/IO-Async-0.68-disable-resolver-test.patch
new file mode 100644
index 000..aef9843
--- /dev/null
+++ b/IO-Async-0.68-disable-resolver-test.patch
@@ -0,0 +1,31 @@
+diff -up ./t/50resolver.t.orig ./t/50resolver.t
+--- ./t/50resolver.t.orig  2015-08-16 15:48:07.665077176 +0200
 ./t/50resolver.t   2015-08-16 15:52:21.625568678 +0200
+@@ -302,27 +302,6 @@ my ( $localhost_err, @localhost_addrs )
+is_deeply( \@got, \@lo_addrs, '$resolver-getaddrinfo resolved addresses 
synchronously' );
+ }
+ 
+-# Now something I hope doesn't exist - we put it in a known-missing TLD
+-my $missinghost = TbK4jM2M0OS.lm57DWIyu4i;
+-
+-# Some CPAN testing machines seem to have wildcard DNS servers that reply to
+-# any request. We'd better check for them
+-
+-SKIP: {
+-skip Resolver has an answer for $missinghost, 1 if gethostbyname( 
$missinghost );
+-
+-my $future = wait_for_future $resolver-getaddrinfo(
+-   host = $missinghost,
+-   service  = 80,
+-   socktype = SOCK_STREAM,
+-);
+-
+-ok( $future-failure, '$future failed for missing host' );
+-is( ( $future-failure )[1], resolve, '-failure [1] gives resolve' );
+-is( ( $future-failure )[2], getaddrinfo, '-failure [2] gives 
getaddrinfo' );
+-is( ( $future-failure )[3], Socket::EAI_NONAME, '-failure [3] gives 
EAI_NONAME' );
+-}
+-
+ my $testaddr = pack_sockaddr_in( 80, INADDR_LOOPBACK );
+ my ( $testerr, $testhost, $testserv ) = getnameinfo( $testaddr );
+ 
diff --git a/perl-IO-Async.spec b/perl-IO-Async.spec
index e9e5753..8c2fa82 100644
--- a/perl-IO-Async.spec
+++ b/perl-IO-Async.spec
@@ -1,11 +1,12 @@
 Name:   perl-IO-Async
-Version:0.67
-Release:4%{?dist}
+Version:0.68
+Release:1%{?dist}
 Summary:A collection of modules that implement asynchronous filehandle 
IO
 
 License:GPL+ or Artistic
 URL:http://search.cpan.org/dist/IO-Async/
 Source0:
http://search.cpan.org/CPAN/authors/id/P/PE/PEVANS/IO-Async-%{version}.tar.gz
+Patch0: IO-Async-0.68-disable-resolver-test.patch
 
 BuildArch:  noarch
 BuildRequires:  make
@@ -64,6 +65,7 @@ A collection of modules that implement asynchronous 
filehandle IO
 
 %prep
 %setup -q -n IO-Async-%{version}
+%patch0
 
 
 %build
@@ -86,6 +88,10 @@ make test
 
 
 %changelog
+* Sun Aug 16 2015 Emmanuel Seyman emman...@seyman.fr - 0.68-1
+- Update to 0.68
+- Disable resolution test for a missing host
+
 * Tue Aug 11 2015 Petr Šabata con...@redhat.com - 0.67-4
 - Prevent FTBFS by correcting the build time dependency list
 
diff --git a/sources b/sources
index fdb143d..0ddf4b5 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-ce6f002ba0bc0e1ec3a58100d0e28823  IO-Async-0.67.tar.gz
+4d5177c823d17cecb6c4f9588ac80d9d  IO-Async-0.68.tar.gz
-- 
cgit v0.10.2



http://pkgs.fedoraproject.org/cgit/perl-IO-Async.git/commit/?h=masterid=7cf56edc8632697982f743f32e1cac50aa4c0289
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[Bug 1238168] FTBFS: Failed during 'make check': 13netlink-message-attrs.t and 20io-socket-netlink-generic.t

[bugzilla]

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

Emmanuel Seyman emman...@seyman.fr changed:

   What|Removed |Added

External Bug ID||CPAN 71112



-- 
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
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: noarch vs. all, x86_64 vs. amd64, kernel vs. linux and PAE

[Reindl Harald]

Am 16.08.2015 um 18:14 schrieb Roberto Ragusa:

On 08/16/2015 10:55 AM, Reindl Harald wrote:


no the architecture was created by Intel

AMD added the 64bit capabilities in a compatible way other than Intel itself 
tried with Itanium which was not able to run i686 instructions and later Intel 
was forced to license the AMD extensions


Well, saying that the architecture was created by Intel is an evident
rewrite the history exercise.


no, the main architecture is still Intel
AMD extended it and Intel adopted the extenisons

but *the point* is that calling it AMD64 is *plain wrong* because 
AMD/Inetl *and others* are using *the same* architecture and using a 
AMD64 suffix would imply that binary is for AMD CPU's only which is wrong



You immediately contradict in the second sentence, where you describe the IA64 
fiasco,
and the adoption of AMD64 by Intel.
Or maybe you think that licensing the AMD extensions is equivalent to the 
architecture
was created by Intel?

Let's recap how it really went:

- Intel designed a new incompatible arch (IA64), it was useless at emulating 
the i386
and was a substantial market failure
- AMD designed the AMD64, as an extension if IA32
- Linux was running on AMD64 immediately at day 0, as AMD had been giving 
around simulators
for chips not created yet
- Microsoft, who had already ported Windows to IA64, created an AMD64 version 
too
- Intel tried to avoid the humiliating acceptance that their rivals did a 
better job
than them, by going to extend the ia32 in a different way
- Microsoft told Intel I already did a port for you, you do not dare asking me 
another
- Intel released the EM64T architecture
- Linus wrote a furious email saying that he had spent time studying the EM64T 
manuals
only to finally realize that it could all have been replaced with just the 
sentence
it's AMD64 (differences are only found in little details)

Nowadays some use AMD64 and some x86_64, with Intel preferring the second 
for obvious reasons.


i know the history well, long enough in the business


Having said that, the cost of change has got probably too high, so we will keep
the current mix of AMD64 (used by BSD, Windows, Solaris, Java, Debian)
and x86_64 (used by Linux, Fedora, SuSE, gcc)


it's not a point of costs
it's simply plain wrong

and just because Debian is here wrong as well as calling the httpd 
package apache don't make it right





signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Sponsors - who does (not) work on FE-NEEDSPONSOR tickets

[Kevin Fenzi]

On Sat, 15 Aug 2015 10:02:05 -0400
Haïkel hgue...@fedoraproject.org wrote:

...snip...

 Using Bugzilla rather than FAS is not a bad idea, as some people
 abuse their sponsor status by blindly adding people into the packager
 group without any supervision. Using FAS as the information source
 would just hide this hideous behaviour.

Well, sponsors are allowed to sponsor people, it's not abuse. 

If they don't properly mentor those packagers after that it's another
matter, but thats much harder to tell from any kind of automated
report. 

kevin


pgpcdPNYJTUVI.pgp
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Same comand names in /usr/bin and /usr/sbin

[Matthew Miller]

On Sun, Aug 16, 2015 at 02:03:38PM +0200, Lennart Poettering wrote:
 In general: encoding privilige policy into the API through binary
 paths is a really bad idea, as policy shouldn't be considered strict
 API (or to be more precise: it should be allowed to open up policy --
 while of course not necessarily to close it down later on), but paths
 are.

Yeah, that's why I was suggesting using it instead for things that
really have no business being in anyone's path, root or not, rather
than have it relate to privileges at all. But, again, only
halfheartedly.


-- 
Matthew Miller
mat...@fedoraproject.org
Fedora Project Leader
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Same comand names in /usr/bin and /usr/sbin

[Nico Kadel-Garcia]

On Sun, Aug 16, 2015 at 8:03 AM, Lennart Poettering
mzerq...@0pointer.de wrote:
 On Fri, 14.08.15 17:58, Matthew Miller (mat...@fedoraproject.org) wrote:

 On Fri, Aug 14, 2015 at 07:24:16PM +0200, Lennart Poettering wrote:
  Given that sbin is in $PATH for unprivileged users too the seperation
  is really pointless, since it's now only the $PATH order which makes
  this not explode.

 Yeah; I have a halfhearted wish to rationalize what goes in sbin and
 what goes in bin. One approach would be to make sbin be commands that
 wouldn't normally be even in privileged users' $PATH — daemons and so
 on that should be launched by init. (Having crond in my path is just
 polluting the namespace.) But all of that is a lot of churn for
 something that's... not usually a problem.

 Also, that ship has sailed a long time ago, when we added sbin to very
 user's $PATH, not just root's...

 There's the general problem that things which were initially intended
 to be run only by root often are opened up later for unprivileged
 clients, and if that happens you'd have to move the file from bin/ to
 sbin/, but that breaks API, since the paths of many binaries are kinda
 assumed to be API by many scripts. That then resulted in people
 placing compat symlinks, so that /usr/sbin/tracepath for example
 became a symlink to /usr/bin/tracepath so that both paths are
 available.

This is not such a problem if the files are identical. For mock,
authconfig, and others trhat I personally mentioned, they are
distinct binaries. I'd prefer to see that be discarded. If one is a
binary that sommons the other with parameters, *rename* the target.

 In general: encoding privilige policy into the API through binary
 paths is a really bad idea, as policy shouldn't be considered strict
 API (or to be more precise: it should be allowed to open up policy --
 while of course not necessarily to close it down later on), but paths
 are.

 Hence: we should say goodbye to the concept of separate bin/sbin, we
 kinda did already by adding both to $PATH for all users, but we should
 work on making this go away in the FS hierachy too, and replace sbin
 by a symlink.

 Lennart

Oh, my. I'm afraid I'm going to have to backfilll some history for
reletavily new Linux developers.

that unless you study some history, you won't understand this stuff.
The original UNIX bootstrap tools lived in /etc, namely the dump
and restore tools and very little else. Later, as Linux was created,
the / partition contained /bin and /sbin, barely enough tools to
run limited scripting and a other tools to be able to do the basic OS
or restoration bootstrapping, tools that wouldn't fit in the old
/etc hardcoded and limited disk space anymore.

/usr was deployed later in the bootstrapping processes, and included
far more site specific components.
It included more than the most basic and universal bootstrapping
toolkits. Both in /sbin on /, and with /usr/sbin on /usr those
tools were segregated because they were dangerous* for ordinary users
to play with, and potentially to confuse themselves and screw up the
machine. The tools were still available, but they required specific
selection to use.

It's a basic violation of the ordinary segregation between /bin as
ordinary user tools and /sbin as sysadmin tools to start mixing
them, and much more confusing to have the same program name in both.
And it's frankly easy to avoid. mock, for example, should rename
/.sbin/mock to something else to avoid command line confusion.

All that made clear, I'm going to get a bit persoal. I hope I can keep
it clear an dpolite enough.

Leonart,  I'm afraid that it's very difficult to trust your opinion on
anything involving ordinary filesystem layout.  Your work with systemd
makes it clear that you wish to discard much, if not all, of the
existing configuration layout and File System Hierarchy to put it all
under systemd and /run. This includes the sytemd re-arrangement of
longstanding network configurations such as /etc/resolv.conf to a
symlink to /run, the re-allocation of /meda to an ill-defined
/run/media/username,

I'm not saying these desires are not understandable, or evil. But it's
very clear that you have other practices and goals in mind than a
great deal of the existing Linux and UNIX community. And your
suggested policies are often aimed at those broader goals, not aimed
at solving the particular individual problem. Your comments above are
one such example. *No one else* suggested discarding /sbin. Doing so
will break decades of stable open source and free software.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: systemd bugs again and again

[Josh Boyer]

On Aug 16, 2015 1:01 PM, Nico Kadel-Garcia nka...@gmail.com wrote:

 Yes, Lennart is a dick. Everyone who has to work with sytemd has seen
this.

Personal attacks are not acceptable on this list.  Don't do it again.

josh
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Sponsors - who does (not) work on FE-NEEDSPONSOR tickets

[Haïkel]

2015-08-16 10:33 GMT-04:00 Kevin Fenzi ke...@scrye.com:
 On Sat, 15 Aug 2015 10:02:05 -0400
 Haïkel hgue...@fedoraproject.org wrote:

 ...snip...

 Using Bugzilla rather than FAS is not a bad idea, as some people
 abuse their sponsor status by blindly adding people into the packager
 group without any supervision. Using FAS as the information source
 would just hide this hideous behaviour.

 Well, sponsors are allowed to sponsor people, it's not abuse.

 If they don't properly mentor those packagers after that it's another
 matter, but thats much harder to tell from any kind of automated
 report.

 kevin


+2
Automated reports has little value by themselves, there are a lot of things
that can't be measured like the amount of time spent on explaining/teaching
packaging or guidelines on irc/mail.

About the problem I was mentioning, I did some investigation and even
contacted the sponsors and mentees.
But naming people on a public list would just pour oil over fire.

Rather than shaming the inactive sponsors that do no harm, we should
rather fix the lack of mentoring of our new packagers.
Some people forget that you don't need to be a sponsor to mentor new packager.

Regards,
H.

 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: noarch vs. all, x86_64 vs. amd64, kernel vs. linux and PAE

[Roberto Ragusa]

On 08/16/2015 10:55 AM, Reindl Harald wrote:
 
 no the architecture was created by Intel
 
 AMD added the 64bit capabilities in a compatible way other than Intel itself 
 tried with Itanium which was not able to run i686 instructions and later 
 Intel was forced to license the AMD extensions

Well, saying that the architecture was created by Intel is an evident
rewrite the history exercise.

You immediately contradict in the second sentence, where you describe the IA64 
fiasco,
and the adoption of AMD64 by Intel.
Or maybe you think that licensing the AMD extensions is equivalent to the 
architecture
was created by Intel?

Let's recap how it really went:

- Intel designed a new incompatible arch (IA64), it was useless at emulating 
the i386
and was a substantial market failure
- AMD designed the AMD64, as an extension if IA32
- Linux was running on AMD64 immediately at day 0, as AMD had been giving 
around simulators
for chips not created yet
- Microsoft, who had already ported Windows to IA64, created an AMD64 version 
too
- Intel tried to avoid the humiliating acceptance that their rivals did a 
better job
than them, by going to extend the ia32 in a different way
- Microsoft told Intel I already did a port for you, you do not dare asking me 
another
- Intel released the EM64T architecture
- Linus wrote a furious email saying that he had spent time studying the EM64T 
manuals
only to finally realize that it could all have been replaced with just the 
sentence
it's AMD64 (differences are only found in little details)

Nowadays some use AMD64 and some x86_64, with Intel preferring the second 
for obvious reasons.

Having said that, the cost of change has got probably too high, so we will keep
the current mix of AMD64 (used by BSD, Windows, Solaris, Java, Debian)
and x86_64 (used by Linux, Fedora, SuSE, gcc).

Regards.

-- 
   Roberto Ragusamail at robertoragusa.it
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Same comand names in /usr/bin and /usr/sbin

[drago01]

On Sun, Aug 16, 2015 at 6:32 PM, Matthew Miller
mat...@fedoraproject.org wrote:
 On Sun, Aug 16, 2015 at 02:03:38PM +0200, Lennart Poettering wrote:
 In general: encoding privilige policy into the API through binary
 paths is a really bad idea, as policy shouldn't be considered strict
 API (or to be more precise: it should be allowed to open up policy --
 while of course not necessarily to close it down later on), but paths
 are.

 Yeah, that's why I was suggesting using it instead for things that
 really have no business being in anyone's path, root or not, rather
 than have it relate to privileges at all. But, again, only
 halfheartedly.

That's what libexec is for? Or you mean use it instead of libexec?
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Same comand names in /usr/bin and /usr/sbin

[Lennart Poettering]

On Sun, 16.08.15 12:57, Nico Kadel-Garcia (nka...@gmail.com) wrote:

  In general: encoding privilige policy into the API through binary
  paths is a really bad idea, as policy shouldn't be considered strict
  API (or to be more precise: it should be allowed to open up policy --
  while of course not necessarily to close it down later on), but paths
  are.
 
  Hence: we should say goodbye to the concept of separate bin/sbin, we
  kinda did already by adding both to $PATH for all users, but we should
  work on making this go away in the FS hierachy too, and replace sbin
  by a symlink.
 
 Oh, my. I'm afraid I'm going to have to backfilll some history for
 reletavily new Linux developers.
 
 that unless you study some history, you won't understand this stuff.
 The original UNIX bootstrap tools lived in /etc, namely the dump
 and restore tools and very little else. Later, as Linux was created,
 the / partition contained /bin and /sbin, barely enough tools to
 run limited scripting and a other tools to be able to do the basic OS
 or restoration bootstrapping, tools that wouldn't fit in the old
 /etc hardcoded and limited disk space anymore.

Not really, /sbin was actually introduced originally to contain
statically linked binaries. That's what s was supposed to mean,
initially. Linux then later redefined that to mean system.

 /usr was deployed later in the bootstrapping processes, and included
 far more site specific components.
 It included more than the most basic and universal bootstrapping
 toolkits. Both in /sbin on /, and with /usr/sbin on /usr those
 tools were segregated because they were dangerous* for ordinary users
 to play with, and potentially to confuse themselves and screw up the
 machine. The tools were still available, but they required specific
 selection to use.

Not really, this isn't about dangerous. This is about privileges
on Linux (i.e. root-only, see FHS). UNIX had a concept of user
priviliges since a long time...

 It's a basic violation of the ordinary segregation between /bin as
 ordinary user tools and /sbin as sysadmin tools to start mixing
 them, and much more confusing to have the same program name in both.
 And it's frankly easy to avoid. mock, for example, should rename
 /.sbin/mock to something else to avoid command line confusion.

Hmm, so you are introducing a new /.sbin now? What's the point of
that?  Just use /usr/lib/package for private files that are not
supposed to be called by anything else directly, and you are good.

The difference between you and me is that I wan't to clean up the FHS
by simplifying it, and enable new uses while doing so, while you just
want to randomly introduce new directories without actually enabling
anything new...

 All that made clear, I'm going to get a bit persoal. I hope I can keep
 it clear an dpolite enough.
 
 Lennart,  I'm afraid that it's very difficult to trust your opinion on
 anything involving ordinary filesystem layout.  Your work with systemd
 makes it clear that you wish to discard much, if not all, of the
 existing configuration layout and File System Hierarchy to put it all
 under systemd and /run.

Hmm? I don't really follow what you are saying. Persistent admin
configuration belongs under /etc, and not under systemd or /run or
whatever you are saying.

 This includes the sytemd re-arrangement of
 longstanding network configurations such as /etc/resolv.conf to a
 symlink to /run, 

I think you are misunderstanding something there. All I am proposing
is that network management software does not make runtime changes to
/etc each time you connect or disconnect to a WLAN. Because /etc is
admin territory, should be considered static and persistent, and
should hence not be manipulated constantly by system software without
explicit request of the admin, during runtime. Or in other words: 
an admin should be able to mount /etc read-only, and the system
should still be able to work (though of course not be able to change
configuration), but I should still be able to connect to WLANs...

Moreover, with everything we proposed there we always said that
/etc/resolv.conf as real file trumps /etc/resolv.conf as
symlink... The symlink is only added if nothing else was in place
there yet.

 the re-allocation of /meda to an ill-defined
 /run/media/username,

I was not really involved in that change (that's udisks). Although I
think it makes a lot of sense, as it fixes security problems with
regards to name clashes of labels between different users.

 Your comments above are one such example. *No one else* suggested
 discarding /sbin. Doing so will break decades of stable open source
 and free software.

Au contraire. How would that break decades of stable open source and
free software? Sure consolehelper needs to be fixed first, but other
than that? Suddenly all binaries are available in both paths. That
means pretty much all scripts that hardcode one or the other path
(maybe because ported over from another distro which sticks some

Re: systemd bugs again and again

[Nico Kadel-Garcia]

Yes, Lennart is a dick. Everyone who has to work with sytemd has seen this.

But please, Don't give him excuses to pretend justification for
ignoring your complaints by coming off growsy in the mailing list.

On Thu, Aug 13, 2015 at 8:50 PM, Reindl Harald h.rei...@thelounge.net wrote:
 is systemd now orphaned in Fedora or why is there no single comment over 3
 months from a maintainer and a upstream available fix is also ignored for a
 week without any comment
 https://bugzilla.redhat.com/show_bug.cgi?id=1226509#c5

 Am 04.07.2015 um 11:08 schrieb Reindl Harald:

 i am tired of ignored bugs in core components like
 https://bugzilla.redhat.com/show_bug.cgi?id=1226509

 how to reproduce?

 just use RuntimeDirectory and ExecStartPost in a systemd-unit and
 stop the service every hour on each machine for backups, you will have a
 few failed starts each day

 Jul  4 03:18:54 backup-arrakis systemd: Failed at step RUNTIME_DIRECTORY
 spawning /usr/libexec/mysqld-wait-ready: File exists
 Jul  4 03:18:54 backup-arrakis systemd: Failed to start MariaDB Database.
 Jul  4 03:18:54 backup-arrakis systemd: Unit mysqld.service entered
 failed state.
 Jul  4 03:18:54 backup-arrakis systemd: mysqld.service failed.
 Jul  4 08:17:54 backup-arrakis systemd: Failed at step RUNTIME_DIRECTORY
 spawning /usr/libexec/mysqld: File exists
 Jul  4 08:17:54 backup-arrakis systemd: Failed to start MariaDB Database.
 Jul  4 08:17:54 backup-arrakis systemd: Unit mysqld.service entered
 failed state.
 Jul  4 08:17:54 backup-arrakis systemd: mysqld.service failed



 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Same comand names in /usr/bin and /usr/sbin

[Reindl Harald]

Am 16.08.2015 um 18:57 schrieb Nico Kadel-Garcia:

It's a basic violation of the ordinary segregation between /bin as
ordinary user tools and /sbin as sysadmin tools to start mixing
them, and much more confusing to have the same program name in both.
And it's frankly easy to avoid. mock, for example, should rename
/.sbin/mock to something else to avoid command line confusion


nonsense

./sbin/ is nowehre in the FHS
./sbin/ is not below/usr
./sbin is not protected ReadOnlyDirectories=/usr

/usr/lib/appname and /usr/libexec exists



signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Same comand names in /usr/bin and /usr/sbin

[Nico Kadel-Garcia]

On Sun, Aug 16, 2015 at 2:31 PM, Reindl Harald h.rei...@thelounge.net wrote:

 Am 16.08.2015 um 18:57 schrieb Nico Kadel-Garcia:

 It's a basic violation of the ordinary segregation between /bin as
 ordinary user tools and /sbin as sysadmin tools to start mixing
 them, and much more confusing to have the same program name in both.
 And it's frankly easy to avoid. mock, for example, should rename
 /.sbin/mock to something else to avoid command line confusion


 nonsense

 ./sbin/ is nowehre in the FHS
 ./sbin/ is not below/usr
 ./sbin is not protected ReadOnlyDirectories=/usr

 /usr/lib/appname and /usr/libexec exists

/sbin isn't a separate filesystem, it is a subdirectory of /, and
it's explicitly mentioned at
http://www.pathname.com/fhs/2.2/fhs-3.14.html as requiring copies or
symlinks to certain specific, long-stable program names. Let me quote
that document:

 3.14.1 Purpose

 Utilities used for system administration (and other root-only commands) are 
 stored in /sbin, /usr/sbin, and /usr/local/sbin. /sbin contains binaries 
 essential for booting, restoring, recovering, and/or repairing the system in 
 addition to the binaries in /bin.[footnote 15]
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[Bug 1254031] New: perl-Pod-Markdown-3.000 is available

[bugzilla]

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

Bug ID: 1254031
   Summary: perl-Pod-Markdown-3.000 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Pod-Markdown
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: jples...@redhat.com, mmasl...@redhat.com,
perl-devel@lists.fedoraproject.org



Latest upstream release: 3.000
Current version/release in rawhide: 2.002-4.fc23
URL: http://search.cpan.org/dist/Pod-Markdown/

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
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: systemd bugs again and again

[Nico Kadel-Garcia]

On Sun, Aug 16, 2015 at 1:09 PM, Josh Boyer jwbo...@fedoraproject.org wrote:
 On Aug 16, 2015 1:01 PM, Nico Kadel-Garcia nka...@gmail.com wrote:

 Yes, Lennart is a [rude word removed]

 Personal attacks are not acceptable on this list.  Don't do it again.

Sorry, that was meant to be a personal message to the author of the
previous message, and it was still out of line even as a private
message. I apologize.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Same comand names in /usr/bin and /usr/sbin

[Reindl Harald]

Am 17.08.2015 um 00:24 schrieb Nico Kadel-Garcia:

On Sun, Aug 16, 2015 at 2:31 PM, Reindl Harald h.rei...@thelounge.net wrote:


Am 16.08.2015 um 18:57 schrieb Nico Kadel-Garcia:


It's a basic violation of the ordinary segregation between /bin as
ordinary user tools and /sbin as sysadmin tools to start mixing
them, and much more confusing to have the same program name in both.
And it's frankly easy to avoid. mock, for example, should rename
/.sbin/mock to something else to avoid command line confusion


nonsense

./sbin/ is nowehre in the FHS
./sbin/ is not below/usr
./sbin is not protected ReadOnlyDirectories=/usr

/usr/lib/appname and /usr/libexec exists


/sbin isn't a separate filesystem, it is a subdirectory of /, and
it's explicitly mentioned at
http://www.pathname.com/fhs/2.2/fhs-3.14.html as requiring copies or
symlinks to certain specific, long-stable program names. Let me quote
that document:


3.14.1 Purpose

Utilities used for system administration (and other root-only commands) are 
stored in /sbin, /usr/sbin, and /usr/local/sbin. /sbin contains binaries 
essential for booting, restoring, recovering, and/or repairing the system in 
addition to the binaries in /bin.[footnote 15]


* these days are gone
* they where gone long before usrMove because in reality the
  purpose of /sbin did *not* work for many years
* UsrMove happened
* ReadOnlyDirectories=/usr is one of the UsrMove benefits
* your ./sbin is mentioned nowhere in the FHS
* FHS is outdated
* the rescue system these days is in the dracutrd
* you would damage all benefits of UsrMove for no gain
* hidden directories are bad

while i often have hard critics for systemd upstream it's never just for 
the purpose of trolling and personal attacking - think about that




signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Same comand names in /usr/bin and /usr/sbin

[Nico Kadel-Garcia]

On Sun, Aug 16, 2015 at 6:24 PM, Nico Kadel-Garcia nka...@gmail.com wrote:
 On Sun, Aug 16, 2015 at 2:31 PM, Reindl Harald h.rei...@thelounge.net wrote:

 Am 16.08.2015 um 18:57 schrieb Nico Kadel-Garcia:

 It's a basic violation of the ordinary segregation between /bin as
 ordinary user tools and /sbin as sysadmin tools to start mixing
 them, and much more confusing to have the same program name in both.
 And it's frankly easy to avoid. mock, for example, should rename
 /.sbin/mock to something else to avoid command line confusion


 nonsense

 ./sbin/ is nowehre in the FHS
 ./sbin/ is not below/usr
 ./sbin is not protected ReadOnlyDirectories=/usr

 /usr/lib/appname and /usr/libexec exists

 /sbin isn't a separate filesystem, it is a subdirectory of /, and
 it's explicitly mentioned at
 http://www.pathname.com/fhs/2.2/fhs-3.14.html as requiring copies or
 symlinks to certain specific, long-stable program names. Let me quote
 that document:

Ahhh, I am sorry, I may have contributed to the confusion by mistyping
/sbin as /.sbin. I'm on a new email interface, and am having some
difficulty with overwriting as opposed to my preferred default
insertion for editing. But that was my own fault.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Same comand names in /usr/bin and /usr/sbin

[Reindl Harald]

Am 17.08.2015 um 01:22 schrieb Nico Kadel-Garcia:

On Sun, Aug 16, 2015 at 6:24 PM, Nico Kadel-Garcia nka...@gmail.com wrote:

On Sun, Aug 16, 2015 at 2:31 PM, Reindl Harald h.rei...@thelounge.net wrote:


Am 16.08.2015 um 18:57 schrieb Nico Kadel-Garcia:


It's a basic violation of the ordinary segregation between /bin as
ordinary user tools and /sbin as sysadmin tools to start mixing
them, and much more confusing to have the same program name in both.
And it's frankly easy to avoid. mock, for example, should rename
/.sbin/mock to something else to avoid command line confusion


nonsense

./sbin/ is nowehre in the FHS
./sbin/ is not below/usr
./sbin is not protected ReadOnlyDirectories=/usr

/usr/lib/appname and /usr/libexec exists


/sbin isn't a separate filesystem, it is a subdirectory of /, and
it's explicitly mentioned at
http://www.pathname.com/fhs/2.2/fhs-3.14.html as requiring copies or
symlinks to certain specific, long-stable program names. Let me quote
that document:


Ahhh, I am sorry, I may have contributed to the confusion by mistyping
/sbin as /.sbin. I'm on a new email interface, and am having some
difficulty with overwriting as opposed to my preferred default
insertion for editing. But that was my own fault


the same nonsense

/sbin is the same as /usr/sbin for a long time now



signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Metadata signing for rawhide

[Nico Kadel-Garcia]

On Thu, Aug 6, 2015 at 11:30 AM, Dennis Gilmore den...@ausil.us wrote:
 On Thursday, August 06, 2015 08:29:50 AM Rex Dieter wrote:
 Nico Kadel-Garcia wrote:
  What makes you think a site that is poisoning or abusing the metadata
  would not simply run createrepo and generate entirely new metadat

 But then it wouldn't match the metalink timestamps or checksums, that Dennis
 mentioned either.  Or am I missing something?

 Exactly. it would only bite a user that had switched from the metalink urls
 shipped by default to something else.

 Dennis

Or had their metalinks repointed for them for them by someone else.
I'm glad that default Fedora yum and dnf configurations now use HTTPS
by default, but it's a computational burden and an awkward requirement
for internal mirrors or locally modified repositories . I've certainly
built precisely such locally modified repositories, precisely to leave
out bulky Fedora packages with a great deal of churn and to provide a
locked internal release version with packages replaced.

Avoiding HTTPS, and thus being vulnerable to DNS redirection of
man-in-the-middle proxy manipulation or poisoned repositories, is an
increasing risk. And non-HTTPS  access is particularly common for
Fedora mirrors.

http://mirrors.kernel.org/fedora/, anyone?
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[Bug 1254028] New: perl-constant-tiny-1.02 is available

[bugzilla]

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

Bug ID: 1254028
   Summary: perl-constant-tiny-1.02 is available
   Product: Fedora
   Version: rawhide
 Component: perl-constant-tiny
  Keywords: FutureFeature, Triaged
  Assignee: ppi...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com



Latest upstream release: 1.02
Current version/release in rawhide: 1.01-8.fc23
URL: http://search.cpan.org/dist/constant-tiny/

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
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[Bug 1254028] perl-constant-tiny-1.02 is available

[bugzilla]

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



--- Comment #1 from Upstream Release Monitoring 
upstream-release-monitor...@fedoraproject.org ---
Failed to kick off scratch build.

cmd:  sha256sum /var/tmp/thn-4M1Koc/100.0%
return code:  1
stdout:

stderr:
sha256sum: /var/tmp/thn-4M1Koc/100.0%: No such file or directory

-- 
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
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[Bug 1254031] perl-Pod-Markdown-3.000 is available

[bugzilla]

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



--- Comment #1 from Upstream Release Monitoring 
upstream-release-monitor...@fedoraproject.org ---
Failed to kick off scratch build.

cmd:  sha256sum /var/tmp/thn-Di2pKO/100.0%
return code:  1
stdout:

stderr:
sha256sum: /var/tmp/thn-Di2pKO/100.0%: No such file or directory

-- 
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
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: Same comand names in /usr/bin and /usr/sbin

[Neal Gompa]

On Sun, Aug 16, 2015 at 7:25 PM, Reindl Harald h.rei...@thelounge.net
wrote:


 Am 17.08.2015 um 01:22 schrieb Nico Kadel-Garcia:

 On Sun, Aug 16, 2015 at 6:24 PM, Nico Kadel-Garcia nka...@gmail.com
 wrote:

 On Sun, Aug 16, 2015 at 2:31 PM, Reindl Harald h.rei...@thelounge.net
 wrote:


 Am 16.08.2015 um 18:57 schrieb Nico Kadel-Garcia:


 It's a basic violation of the ordinary segregation between /bin as
 ordinary user tools and /sbin as sysadmin tools to start mixing
 them, and much more confusing to have the same program name in both.
 And it's frankly easy to avoid. mock, for example, should rename
 /.sbin/mock to something else to avoid command line confusion


 nonsense

 ./sbin/ is nowehre in the FHS
 ./sbin/ is not below/usr
 ./sbin is not protected ReadOnlyDirectories=/usr

 /usr/lib/appname and /usr/libexec exists


 /sbin isn't a separate filesystem, it is a subdirectory of /, and
 it's explicitly mentioned at
 http://www.pathname.com/fhs/2.2/fhs-3.14.html as requiring copies or
 symlinks to certain specific, long-stable program names. Let me quote
 that document:


 Ahhh, I am sorry, I may have contributed to the confusion by mistyping
 /sbin as /.sbin. I'm on a new email interface, and am having some
 difficulty with overwriting as opposed to my preferred default
 insertion for editing. But that was my own fault


 the same nonsense

 /sbin is the same as /usr/sbin for a long time now


 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct


​Quoting in FHS 3.0
http://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html (which is
really the one we should be looking at):​

*The following commands, or symbolic links to commands*... (Sect 3.16.2)
[...]
*The following files, or symbolic links to files*... (Sect 3.16.3)

(From FHS chapter 3.16 /sbin: System binaries
http://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s16.html)

Thus, it sounds like FHS is okay with the idea of */sbin* being symlinked
to some other directory. Ultimately, FHS doesn't appear to mandate that the
folder and its contents must physically exist there, only that they are
present to enable *booting, restoring, recovering, and/or repairing the
system* (Sect 3.16.1).

The split between */sbin* and */bin* was largely for providing a logical
division of core administrative functions and the rest of the stuff
installed. Frankly, I don't see how that matters so much anymore. FHS
doesn't even recommend walling off access to */sbin*, either.


-- 
真実はいつも一つ！/ Always, there's only one truth!
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Metadata signing for rawhide

[Pierre-Yves Chibon]

On Sun, Aug 16, 2015 at 07:40:21PM -0400, Nico Kadel-Garcia wrote:
 On Thu, Aug 6, 2015 at 11:30 AM, Dennis Gilmore den...@ausil.us wrote:
  On Thursday, August 06, 2015 08:29:50 AM Rex Dieter wrote:
  Nico Kadel-Garcia wrote:
   What makes you think a site that is poisoning or abusing the metadata
   would not simply run createrepo and generate entirely new metadat
 
  But then it wouldn't match the metalink timestamps or checksums, that 
  Dennis
  mentioned either.  Or am I missing something?
 
  Exactly. it would only bite a user that had switched from the metalink urls
  shipped by default to something else.
 
 Or had their metalinks repointed for them for them by someone else.
 I'm glad that default Fedora yum and dnf configurations now use HTTPS
 by default

I am unsure I understand what you mean, I read this as yum and dnf query mirrors
via https, but that's not true, it queries the metalink via https because we
expose them in our proxies via https, but downloading the packages are done via
http or https or ftp depending on what the mirror offers.


Pierre
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F23: Copr build failure: glibc

[Sérgio Basto]

Hi, redirecting to copr-devel 

On Qua, 2015-07-29 at 09:18 -0400, Stephen Gallagher wrote:
 On Wed, 2015-07-29 at 15:15 +0200, Rajeesh K V wrote:
  Hello,
  
  Copr fails to build for F23 (i686, x86_64) due to error:
  
  Error: Package glibc-2.21.90-21.fc23.x86_64.rpm is not signed
  
  For instance see the build log
  https://copr-be.cloud.fedoraproject.org/results/rajeeshknambiar/kf5-k
  de-apps/fedora-23-x86_64/plasma-volume-control-5.3.90-1.fc22/root.log
  
  
 
 
 Known issue, should be fixed later today when Bodhi is activated for
 Fedora 23.

I still have those failures in fedora-23-ppc64le [1] and
fedora-rawhide-ppc64le buildroots .

Should we open bug reports in bugzilla , product Copr [3] ?  

[1]
https://copr-be.cloud.fedoraproject.org/results/sergiomb/patchutils_with_diffview/fedora-23-ppc64le/00109173-patchutils/root.log
DEBUG util.py:377:  Error: Package tar-1.28-6.fc23.ppc64le.rpm is not
signed

[2]
https://copr-be.cloud.fedoraproject.org/results/sergiomb/patchutils_with_diffview/fedora-rawhide-ppc64le/00109173-patchutils/root.log
DEBUG util.py:377:  Error: nothing provides libsemanage.so.1()(64bit)
needed by shadow-utils-2:4.2.1-2.fc23.ppc64le.
DEBUG util.py:377:  nothing provides libsemanage.so.1()(64bit) needed by 
shadow-utils-2:4.2.1-2.fc23.ppc64le
DEBUG util.py:488:  Child return code was: 1

[3]
https://bugzilla.redhat.com/enter_bug.cgi?product=Copr

Thanks,
-- 
Sérgio M. B.

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Same comand names in /usr/bin and /usr/sbin

[Gary Gatling]

On Sun, Aug 16, 2015 at 2:52 PM, Eric Griffith egriffit...@gmail.com
wrote:

 Didn't Arch move /usr/sbin to just be a symlink to /usr/bin?


Looks like they did.

[gsgatlin@arch64 ~]$ ls -al  /usr/sbin
lrwxrwxrwx 1 root root 3 Feb 15 16:57 /usr/sbin - bin
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Same comand names in /usr/bin and /usr/sbin

[Matthew Miller]

On Sun, Aug 16, 2015 at 06:35:28PM +0200, drago01 wrote:
  Yeah, that's why I was suggesting using it instead for things that
  really have no business being in anyone's path, root or not, rather
  than have it relate to privileges at all. But, again, only
  halfheartedly.
 That's what libexec is for? Or you mean use it instead of libexec?

Maybe libexec would be appropriate. Especially if we would go ahead
and make sbin a link to bin. Anything which shouldn't be run but is
instead in a systemd service file could move.

-- 
Matthew Miller
mat...@fedoraproject.org
Fedora Project Leader
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Same comand names in /usr/bin and /usr/sbin

[Reindl Harald]

Am 16.08.2015 um 20:52 schrieb Eric Griffith:

  *No one else* suggested discarding /sbin. Doing so
  will break decades of stable open source and free software.

Didn't Arch move /usr/sbin to just be a symlink to /usr/bin?


maybe

but even if not, it don't matter and would not break *anything* because 
after that *both* paths would be valid, independent from which unix-like 
OS you start a script with a hardcoded path


and it would avoid the topic to ever happen again

now that we survived UsrMove (even if there are still broken packages 
like glibc providing only /sbin/ldconfig and breaking deps when packages 
using /usr/sbin/ldconfig - and the same for perl) that change would only 
make things really clear




signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Same comand names in /usr/bin and /usr/sbin

[Eric Griffith]

 *No one else* suggested discarding /sbin. Doing so
 will break decades of stable open source and free software.

Didn't Arch move /usr/sbin to just be a symlink to /usr/bin?
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Same comand names in /usr/bin and /usr/sbin

[Eric Griffith]

On Aug 16, 2015 2:59 PM, Reindl Harald h.rei...@thelounge.net wrote:


 Am 16.08.2015 um 20:52 schrieb Eric Griffith:

   *No one else* suggested discarding /sbin. Doing so
   will break decades of stable open source and free software.

 Didn't Arch move /usr/sbin to just be a symlink to /usr/bin?


 maybe

 but even if not, it don't matter and would not break *anything* because
after that *both* paths would be valid, independent from which unix-like OS
you start a script with a hardcoded path

 and it would avoid the topic to ever happen again

 now that we survived UsrMove (even if there are still broken packages
like glibc providing only /sbin/ldconfig and breaking deps when packages
using /usr/sbin/ldconfig - and the same for perl) that change would only
make things really clear


I knew that it -shouldnt- break anything, though I'm sure that some obscure
app has some weird functionality that relys on a sbin/bin split, I was just
pointing out that any major breakage should've already been caught and
handled by at least one fairly major distribution
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

vanoudt uploaded HTTP-OAI-4.03.tar.gz for perl-HTTP-OAI

[notifications]

7331d421de6187e56b6621fbb3b94879  HTTP-OAI-4.03.tar.gz

http://pkgs.fedoraproject.org/lookaside/pkgs/perl-HTTP-OAI/HTTP-OAI-4.03.tar.gz/md5/7331d421de6187e56b6621fbb3b94879/HTTP-OAI-4.03.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

vanoudt uploaded Authen-CAS-Client-0.07.tar.gz for perl-Authen-CAS-Client

[notifications]

81220965ac20ab4e07d53b4d749e33db  Authen-CAS-Client-0.07.tar.gz

http://pkgs.fedoraproject.org/lookaside/pkgs/perl-Authen-CAS-Client/Authen-CAS-Client-0.07.tar.gz/md5/81220965ac20ab4e07d53b4d749e33db/Authen-CAS-Client-0.07.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel