Agenda for Env-and-Stacks WG meeting (2015-09-10)

[Honza Horak]

WG meeting will be at 12:00 UTC (9:00 EST, 14:00 Brno, 8:00 Boston, 
21:00 Tokyo, 22:00 Brisbane) in #fedora-meeting-2 on Freenode.


= Topics =

* Developer portal -- whatever is needed for finalizing

* RepoFunnel and the Software Component Pipeline -- any feedback

https://lists.fedoraproject.org/pipermail/env-and-stacks/2015-August/000902.html

* User level package management -- looking for AI

https://lists.fedoraproject.org/pipermail/env-and-stacks/2015-August/000884.html

Note: Deliberately omitting Langdon's agenda proposed few weeks back, 
since I don't expect Langdon today (but we can operatively add this in 
case he comes):

https://lists.fedoraproject.org/pipermail/env-and-stacks/2015-August/000887.html

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

Re: [EPEL-devel] Dealing with cyclic dependencies

[Bryan Chan]

Dan Horák  wrote on 2015-09-08 01:56:54 PM:

> Often those packages contain a "bootstrap" macro that can be set to 1
> for an initial build with limited dependencies and to 0 for production
> build. And for building for EPEL there should be a older build (source
> rpm) available (because it had to bootstrapped also for regular EPEL),
> so first rebuild this, and then the latest, or next or whatever is
> necessary. The changelog in the spec files and/or history in dist-git
> will show the details about the versions.
>
> Do you have a list of those problematic builds?

Hi Dan, thanks for the suggestion. My team mate has found a similar
bootstrap macro in the ghc packages and is trying it out now.

I asked the person who did the original runs back in June but he doesn't
remember where the circular dependencies came from. He thought it might
be some Python- or Perl-related dependencies in a %test section of a
package but he isn't sure. We will watch out for the issue and report
if we see it again.

Thanks, Bryan
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: Orphaned packages available for new point of contact

[Matěj Cepl]

On 2015-09-09, 19:37 GMT, Kevin Fenzi wrote:
> pytz
> python-dateutil

I see these two as too important to let them fall, so I am 
taking them. However, I would really really like to have some 
co-maintainers, because I don’t feel like I really understand 
the matter.

Orion?

Best,

Matěj

-- 
http://www.ceplovi.cz/matej/, Jabber: mc...@ceplovi.cz
GPG Finger: 89EF 4BC6 288A BF43 1BAB  25C3 E09F EF25 D964 84AC
 
My point was simply that such tax proposals [for Pigovian taxes
compensating for the transaction costs] are the stuff that dreams
are made of. In my youth it was said, that what was too silly to
be said may be sung. In modern economics it may be put into
mathematics.
-- Ronald Coase
   Notes on the Problem of Social Cost

-- 
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: Orphaned packages available for new point of contact

[Mathieu Bridon]

On Thu, 2015-09-10 at 11:16 +0200, Matěj Cepl wrote:
> On 2015-09-09, 19:37 GMT, Kevin Fenzi wrote:
> > pytz
> > python-dateutil
> 
> I see these two as too important to let them fall, so I am 
> taking them. However, I would really really like to have some 
> co-maintainers, because I don’t feel like I really understand 
> the matter.

Give acls to the python-sig group?


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

Re: macros.python2 requires update in F21+

[Robert Kuska]

- Original Message -
> From: "Haïkel" 
> To: "Fedora Python SIG" 
> Cc: "Alan Pevec" , python-ow...@fedoraproject.org
> Sent: Thursday, September 10, 2015 10:16:43 AM
> Subject: Re: macros.python2 requires update in F21+
> 
> Hi,
> 
> Nobody answered, should I assume that everyone is ok with me pushing
> Orion's patches in F21 and F22?
> 
> Regards,
> H.
> 
> 2015-09-08 12:26 UTC+02:00, Haïkel :
> > Hi,
> >
> > Recently, we had a lot of issues with openstack packages due to python
> > newer guidelines.
> > To fix upgrade path for python2 modules, you had to obsolete previous
> > python-xxx module.
> > Orion committed a fix in rawhide in the macro %python_provides that
> > fixes that issue.
> >
> > http://pkgs.fedoraproject.org/cgit/python.git/commit/?id=7fdb9bedcda48894b7ba85e34ca5722b28b69076
> > http://pkgs.fedoraproject.org/cgit/python.git/commit/?id=cb9dd734593c52b84f0b9b6f19f352001c1d50d3
> >
> > Could we backport these in F21/22/23 ?
> > It's rather critical, as we have less experienced packagers pushing
> > updates without checking
> > the upgrade path or provides/obsoletes. Having a reliable
> > %python_macros as in rawhide makes it more
> > robust and will avoid breaking users dependencies
> >
> > I prefer that python maintainers do the update as it's a critical
> > package, but I don't mind doing it in their stead
> > if you approve this (if necessary)
> >
> >
> > Regards,
> > H.
> >
> 
Hi Haikel,

sorry for no response.

LGTM (as a co-maintainer)

--
Robert Kuska
{rkuska}
___
python-devel mailing list
python-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/python-devel

[Bug 1228015] perl-Test-AutoBuild-1.2.4-15.fc23 FTBFS on ARM: cannot open /builddir/build/BUILD/Test-AutoBuild-1.2.4/t/build-home/head/a: No such file or directory at t/110-Repository-Darcs.t line 139

[bugzilla]

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

Fedora Admin XMLRPC Client  changed:

   What|Removed |Added

   Assignee|berra...@redhat.com |extras-orphan@fedoraproject
   ||.org



--- Comment #2 from Fedora Admin XMLRPC Client  
---
This package has changed ownership in the Fedora Package Database.  Reassigning
to the new owner of this component.

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

berrange retired perl-Test-AutoBuild in f23

[notifications]

berrange retired perl-Test-AutoBuild in f23
https://admin.fedoraproject.org/pkgdb/package/perl-Test-AutoBuild/
--
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 1239784] perl-Test-AutoBuild: FTBFS in rawhide

[bugzilla]

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

Fedora Admin XMLRPC Client  changed:

   What|Removed |Added

   Assignee|berra...@redhat.com |extras-orphan@fedoraproject
   ||.org



--- Comment #5 from Fedora Admin XMLRPC Client  
---
This package has changed ownership in the Fedora Package Database.  Reassigning
to the new owner of this component.

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

berrange pushed to perl-Test-AutoBuild (f23). "No longer actively maintained upstream. Better modern alternatives exist, such as Jenkins"

[notifications]

From d7e5e372826770b1ee4309bfa1d40d4bc2058148 Mon Sep 17 00:00:00 2001
From: "Daniel P. Berrange" 
Date: Thu, 10 Sep 2015 10:50:49 +0100
Subject: No longer actively maintained upstream. Better modern alternatives
 exist, such as Jenkins


diff --git a/.gitignore b/.gitignore
deleted file mode 100644
index 21c4753..000
--- a/.gitignore
+++ /dev/null
@@ -1,4 +0,0 @@
-.build*
-noarch
-perl-Test-AutoBuild-*.rpm
-Test-AutoBuild-*.tar.gz
diff --git a/Test-AutoBuild-1.2.4-yaml.patch b/Test-AutoBuild-1.2.4-yaml.patch
deleted file mode 100644
index e2a6858..000
--- a/Test-AutoBuild-1.2.4-yaml.patch
+++ /dev/null
@@ -1,22 +0,0 @@
-diff -rup Test-AutoBuild-1.2.4.orig/t/008-meta.t 
Test-AutoBuild-1.2.4.new/t/008-meta.t
 Test-AutoBuild-1.2.4.orig/t/008-meta.t 2011-09-01 21:49:57.0 
+0100
-+++ Test-AutoBuild-1.2.4.new/t/008-meta.t  2012-03-09 13:07:55.949281028 
+
-@@ -2,14 +2,14 @@
- 
- use Test::More tests => 1;
- SKIP: {
--  eval "use Test::YAML::Meta::Version; use YAML::Syck qw(LoadFile)";
--  skip "Test::YAML::Meta::Version and YAML::Syck required for testing 
META.yml", 1 if $@;
-+  eval "use Test::CPAN::Meta::YAML::Version; use YAML::Syck qw(LoadFile)";
-+  skip "Test::CPAN::Meta::YAML::Version and YAML::Syck required for testing 
META.yml", 1 if $@;
- 
- my %data = (
-   yaml => LoadFile("META.yml"),
- );
- 
--my $spec = Test::YAML::Meta::Version->new(%data);
-+my $spec = Test::CPAN::Meta::YAML::Version->new(%data);
- 
- ok (!$spec->parse());
- 
-Only in Test-AutoBuild-1.2.4.new/t: 008-meta.t~
diff --git a/dead.package b/dead.package
new file mode 100644
index 000..f02c646
--- /dev/null
+++ b/dead.package
@@ -0,0 +1 @@
+No longer actively maintained upstream. Better modern alternatives exist, such 
as Jenkins
diff --git a/perl-Test-AutoBuild.spec b/perl-Test-AutoBuild.spec
deleted file mode 100644
index 0038d58..000
--- a/perl-Test-AutoBuild.spec
+++ /dev/null
@@ -1,729 +0,0 @@
-# Automatically generated by perl-Test-AutoBuild.spec.PL
-
-%bcond_without  fedora
-%define appname Test-AutoBuild
-%define with_selinux 0
-
-# Everything on by default
-%define with_bzr 1
-%define with_cvs 1
-%define with_darcs 1
-%define with_git 1
-%define with_mercurial 1
-%define with_monotone 0
-%define with_perforce 1
-%define with_svk 0
-%define with_svn 1
-%define with_tla 1
-
-# Not available in any Fedora release
-%if %{?fedora}
-%define with_perforce 0
-%endif
-
-# Not available since F15 onwards
-%if %{?fedora} >= 14
-%define with_tla 0
-%endif
-
-# Darcs won't work on arches which lack GHC
-%ifnarch %{?ghc_arches_with_ghci}
-%define with_darcs 0
-%endif
-
-# Avoid empty debug file
-%define debug_package %{nil}
-
-Summary: Framework for performing continuous, unattended, automated software 
builds
-Name: perl-%{appname}
-Version: 1.2.4
-Release: 17%{?dist}%{?extra_release}
-License: GPLv2+
-Group: Development/Tools
-Url: http://autobuild.org/
-Source: 
http://www.cpan.org/authors/id/D/DA/DANBERR/%{appname}-%{version}.tar.gz
-Patch1: %{appname}-%{version}-yaml.patch
-BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
-# Technically this is a noarch package, but due to lack of ghc
-# on some architecutures we need to use arch specific conditionals
-# to kill off the darcs sub-RPM.
-#BuildArchitectures: noarch
-
-Requires: perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo $version))
-
-BuildRequires: perl(BSD::Resource) >= 1.15
-BuildRequires: perl(Config::Record) >= 1.1.0
-BuildRequires: perl(Log::Log4perl)
-BuildRequires: perl(Template)
-BuildRequires: perl(IO::Scalar)
-BuildRequires: perl(Date::Manip)
-BuildRequires: perl(File::ReadBackwards)
-BuildRequires: perl(Class::MethodMaker)
-BuildRequires: perl(XML::Simple)
-BuildRequires: perl(Test::More)
-BuildRequires: perl(Test::Pod)
-BuildRequires: perl(Test::Pod::Coverage)
-BuildRequires: perl(YAML::Syck)
-BuildRequires: perl(Test::CPAN::Meta::YAML::Version)
-BuildRequires: perl(ExtUtils::MakeMaker)
-%if %{with_bzr}
-BuildRequires: bzr >= 0.91
-%endif
-%if %{with_cvs}
-BuildRequires: cvs >= 1.11
-%endif
-%if %{with_darcs}
-BuildRequires: darcs >= 1.0.0
-%endif
-%if %{with_git}
-BuildRequires: git >= 1.5.0.0
-%endif
-%if %{with_mercurial}
-BuildRequires: mercurial >= 0.7
-%endif
-%if %{with_monotone}
-BuildRequires: monotone >= 0.37
-%endif
-%if %{with_svk}
-BuildRequires: perl-SVK >= 1.0
-%endif
-%if %{with_svn}
-BuildRequires: subversion >= 1.0.0
-%endif
-%if %{with_tla}
-BuildRequires: tla >= 1.1.0
-%endif
-%if %{with_selinux}
-BuildRequires: selinux-policy-devel
-%endif
-
-# For Test::AutoBuild::Stage::ISOBuilder
-Requires: /usr/bin/mkisofs
-# For Test::AutoBuild::Stage::CreateRepo
-Requires: /usr/bin/createrepo
-# For Test::AutoBuild::Stage::Apt
-Requires: /usr/bin/genbasedir
-# For Test::AutoBuild::Publisher::XSLTransform
-Requires: /usr/bin/xsltproc
-# For Test::AutoBuild::Stage::RSyncStatus
-Requires: /usr/bin/rsync
-
-# Automatic RPM perl deps script misses this
-Requires: 

berrange pushed to perl-Test-AutoBuild (master). "No longer actively maintained upstream. Better modern alternatives exist, such as Jenkins"

[notifications]

From dd2d78c457637b593a7e11ec8dc6b3823141ca27 Mon Sep 17 00:00:00 2001
From: "Daniel P. Berrange" 
Date: Thu, 10 Sep 2015 11:02:15 +0100
Subject: No longer actively maintained upstream. Better modern alternatives
 exist, such as Jenkins


diff --git a/.gitignore b/.gitignore
deleted file mode 100644
index 21c4753..000
--- a/.gitignore
+++ /dev/null
@@ -1,4 +0,0 @@
-.build*
-noarch
-perl-Test-AutoBuild-*.rpm
-Test-AutoBuild-*.tar.gz
diff --git a/Test-AutoBuild-1.2.4-yaml.patch b/Test-AutoBuild-1.2.4-yaml.patch
deleted file mode 100644
index e2a6858..000
--- a/Test-AutoBuild-1.2.4-yaml.patch
+++ /dev/null
@@ -1,22 +0,0 @@
-diff -rup Test-AutoBuild-1.2.4.orig/t/008-meta.t 
Test-AutoBuild-1.2.4.new/t/008-meta.t
 Test-AutoBuild-1.2.4.orig/t/008-meta.t 2011-09-01 21:49:57.0 
+0100
-+++ Test-AutoBuild-1.2.4.new/t/008-meta.t  2012-03-09 13:07:55.949281028 
+
-@@ -2,14 +2,14 @@
- 
- use Test::More tests => 1;
- SKIP: {
--  eval "use Test::YAML::Meta::Version; use YAML::Syck qw(LoadFile)";
--  skip "Test::YAML::Meta::Version and YAML::Syck required for testing 
META.yml", 1 if $@;
-+  eval "use Test::CPAN::Meta::YAML::Version; use YAML::Syck qw(LoadFile)";
-+  skip "Test::CPAN::Meta::YAML::Version and YAML::Syck required for testing 
META.yml", 1 if $@;
- 
- my %data = (
-   yaml => LoadFile("META.yml"),
- );
- 
--my $spec = Test::YAML::Meta::Version->new(%data);
-+my $spec = Test::CPAN::Meta::YAML::Version->new(%data);
- 
- ok (!$spec->parse());
- 
-Only in Test-AutoBuild-1.2.4.new/t: 008-meta.t~
diff --git a/dead.package b/dead.package
new file mode 100644
index 000..f02c646
--- /dev/null
+++ b/dead.package
@@ -0,0 +1 @@
+No longer actively maintained upstream. Better modern alternatives exist, such 
as Jenkins
diff --git a/perl-Test-AutoBuild.spec b/perl-Test-AutoBuild.spec
deleted file mode 100644
index 0038d58..000
--- a/perl-Test-AutoBuild.spec
+++ /dev/null
@@ -1,729 +0,0 @@
-# Automatically generated by perl-Test-AutoBuild.spec.PL
-
-%bcond_without  fedora
-%define appname Test-AutoBuild
-%define with_selinux 0
-
-# Everything on by default
-%define with_bzr 1
-%define with_cvs 1
-%define with_darcs 1
-%define with_git 1
-%define with_mercurial 1
-%define with_monotone 0
-%define with_perforce 1
-%define with_svk 0
-%define with_svn 1
-%define with_tla 1
-
-# Not available in any Fedora release
-%if %{?fedora}
-%define with_perforce 0
-%endif
-
-# Not available since F15 onwards
-%if %{?fedora} >= 14
-%define with_tla 0
-%endif
-
-# Darcs won't work on arches which lack GHC
-%ifnarch %{?ghc_arches_with_ghci}
-%define with_darcs 0
-%endif
-
-# Avoid empty debug file
-%define debug_package %{nil}
-
-Summary: Framework for performing continuous, unattended, automated software 
builds
-Name: perl-%{appname}
-Version: 1.2.4
-Release: 17%{?dist}%{?extra_release}
-License: GPLv2+
-Group: Development/Tools
-Url: http://autobuild.org/
-Source: 
http://www.cpan.org/authors/id/D/DA/DANBERR/%{appname}-%{version}.tar.gz
-Patch1: %{appname}-%{version}-yaml.patch
-BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
-# Technically this is a noarch package, but due to lack of ghc
-# on some architecutures we need to use arch specific conditionals
-# to kill off the darcs sub-RPM.
-#BuildArchitectures: noarch
-
-Requires: perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo $version))
-
-BuildRequires: perl(BSD::Resource) >= 1.15
-BuildRequires: perl(Config::Record) >= 1.1.0
-BuildRequires: perl(Log::Log4perl)
-BuildRequires: perl(Template)
-BuildRequires: perl(IO::Scalar)
-BuildRequires: perl(Date::Manip)
-BuildRequires: perl(File::ReadBackwards)
-BuildRequires: perl(Class::MethodMaker)
-BuildRequires: perl(XML::Simple)
-BuildRequires: perl(Test::More)
-BuildRequires: perl(Test::Pod)
-BuildRequires: perl(Test::Pod::Coverage)
-BuildRequires: perl(YAML::Syck)
-BuildRequires: perl(Test::CPAN::Meta::YAML::Version)
-BuildRequires: perl(ExtUtils::MakeMaker)
-%if %{with_bzr}
-BuildRequires: bzr >= 0.91
-%endif
-%if %{with_cvs}
-BuildRequires: cvs >= 1.11
-%endif
-%if %{with_darcs}
-BuildRequires: darcs >= 1.0.0
-%endif
-%if %{with_git}
-BuildRequires: git >= 1.5.0.0
-%endif
-%if %{with_mercurial}
-BuildRequires: mercurial >= 0.7
-%endif
-%if %{with_monotone}
-BuildRequires: monotone >= 0.37
-%endif
-%if %{with_svk}
-BuildRequires: perl-SVK >= 1.0
-%endif
-%if %{with_svn}
-BuildRequires: subversion >= 1.0.0
-%endif
-%if %{with_tla}
-BuildRequires: tla >= 1.1.0
-%endif
-%if %{with_selinux}
-BuildRequires: selinux-policy-devel
-%endif
-
-# For Test::AutoBuild::Stage::ISOBuilder
-Requires: /usr/bin/mkisofs
-# For Test::AutoBuild::Stage::CreateRepo
-Requires: /usr/bin/createrepo
-# For Test::AutoBuild::Stage::Apt
-Requires: /usr/bin/genbasedir
-# For Test::AutoBuild::Publisher::XSLTransform
-Requires: /usr/bin/xsltproc
-# For Test::AutoBuild::Stage::RSyncStatus
-Requires: /usr/bin/rsync
-
-# Automatic RPM perl deps script misses this
-Requires: 

berrange retired perl-Test-AutoBuild in master

[notifications]

berrange retired perl-Test-AutoBuild in master
https://admin.fedoraproject.org/pkgdb/package/perl-Test-AutoBuild/
--
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

berrange set the monitor flag of perl-Test-AutoBuild to False

[notifications]

berrange set the monitor flag of perl-Test-AutoBuild to False

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

berrange set the monitor flag of perl-Test-AutoBuild to True

[notifications]

berrange set the monitor flag of perl-Test-AutoBuild to True

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

DNF 1.1.1 and DNF-PLUGINS-CORE 0.1.11 Released

[Honza Šilhan]

Good News everyone,

after another 3 weeks, new versions of DNF and DNF-PLUGINS-CORE have been 
released. DNF 1.1.1
brings mark command [1] feature while DNF-PLUGINS-CORE adds 4 new filters from 
"dnf list" command
and extending functionality of `--arch` and `--tree` switches. Additionally 
around 15 bugs have
been fixed.

For more detailed information about the releases see DNF [2] and DNF plugins 
release notes [3].


Cheers,
Honza


[0] 
http://dnf.baseurl.org/2015/09/09/dnf-1-1-1-and-dnf-plugins-core-0-1-11-released/
[1] http://dnf.readthedocs.org/en/latest/command_ref.html#mark-command
[2] http://dnf.readthedocs.org/en/latest/release_notes.html#release-notes
[3] 
http://dnf-plugins-core.readthedocs.org/en/latest/release_notes.html#release-notes
-- 
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: [EPEL-devel] Dealing with cyclic dependencies

[Bryan Chan]

Stephen John Smoogen  wrote on 2015-09-08 04:48:09 PM:

> Normally you use 1-2 side repos where you put your packages.
>
> Repo 1: All the package for s390 f17 (for example)
> Repo 2: All the packages as they are built by your rebuild script.
>
> As the packages in repo 1 are usually lesser EVR than the f18/f19 you
> are wanting to rebuild you can usually meet the minimum for a circular
> dependency. If you want to really get fancy you can remove packages
> from Repo1 as they are rebuilt in Repo2 and then have a Repo3 which is
> the rebuild of the rebuilds.

We used RHEL 7.1 as our read-only "repo 1". Using a Fedora repo might
have helped us avoid some dependency issues... I hadn't thought of that.

Thanks for the suggestions.

Bryan
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-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-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

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

rawhide report: 20150910 changes

[Fedora Rawhide Report]

Compose started at Thu Sep 10 05:15:03 UTC 2015
Broken deps for i386
--
[IQmol]
IQmol-2.3.0-9.fc24.i686 requires libboost_serialization.so.1.58.0
IQmol-2.3.0-9.fc24.i686 requires libboost_iostreams.so.1.58.0
[ScientificPython]
ScientificPython-2.8-20.fc22.i686 requires libmpi.so.1
[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)
[aqsis]
aqsis-1.8.2-20.fc24.i686 requires libboost_thread.so.1.58.0
aqsis-1.8.2-20.fc24.i686 requires libboost_system.so.1.58.0
aqsis-1.8.2-20.fc24.i686 requires libboost_regex.so.1.58.0
aqsis-1.8.2-20.fc24.i686 requires libboost_program_options.so.1.58.0
aqsis-1.8.2-20.fc24.i686 requires libboost_filesystem.so.1.58.0
aqsis-core-1.8.2-20.fc24.i686 requires libboost_wave.so.1.58.0
aqsis-core-1.8.2-20.fc24.i686 requires libboost_thread.so.1.58.0
aqsis-core-1.8.2-20.fc24.i686 requires libboost_system.so.1.58.0
aqsis-core-1.8.2-20.fc24.i686 requires libboost_regex.so.1.58.0
aqsis-core-1.8.2-20.fc24.i686 requires libboost_iostreams.so.1.58.0
aqsis-core-1.8.2-20.fc24.i686 requires libboost_filesystem.so.1.58.0
aqsis-libs-1.8.2-20.fc24.i686 requires libboost_thread.so.1.58.0
aqsis-libs-1.8.2-20.fc24.i686 requires libboost_system.so.1.58.0
aqsis-libs-1.8.2-20.fc24.i686 requires libboost_regex.so.1.58.0
aqsis-libs-1.8.2-20.fc24.i686 requires libboost_iostreams.so.1.58.0
aqsis-libs-1.8.2-20.fc24.i686 requires libboost_filesystem.so.1.58.0
[aws]
aws-tools-2015-2.fc23.i686 requires libaws_ssl.so
[bro]
bro-2.3.2-6.fc23.i686 requires libjemalloc.so.1
[compat-qpid-cpp]
compat-qpid-tools-0.24-26.fc24.noarch requires python-qpid >= 0:0.8
[condor-low-latency]
condor-low-latency-1.2-2.fc23.6.noarch requires python-qpid
[dpm-contrib-admintools]
dpm-contrib-admintools-0.2.1-6.fc23.i686 requires MySQL-python(x86-32)
[ghc-hakyll]
ghc-hakyll-4.5.4.0-3.fc23.i686 requires libHSxml-1.3.13-ghc7.8.4.so
ghc-hakyll-4.5.4.0-3.fc23.i686 requires 
ghc(pandoc-1.13.2-54186dabcc89e90f1b8b1cafd8e569fe)
ghc-hakyll-devel-4.5.4.0-3.fc23.i686 requires 
ghc-devel(pandoc-1.13.2-54186dabcc89e90f1b8b1cafd8e569fe)
[gnash]
1:gnash-0.8.10-19.fc24.i686 requires libboost_thread.so.1.58.0
1:gnash-0.8.10-19.fc24.i686 requires libboost_system.so.1.58.0
1:gnash-0.8.10-19.fc24.i686 requires libboost_serialization.so.1.58.0
1:gnash-0.8.10-19.fc24.i686 requires libboost_program_options.so.1.58.0
1:gnash-0.8.10-19.fc24.i686 requires libboost_iostreams.so.1.58.0
1:gnash-0.8.10-19.fc24.i686 requires libboost_date_time.so.1.58.0
1:gnash-cygnal-0.8.10-19.fc24.i686 requires libboost_thread.so.1.58.0
1:gnash-cygnal-0.8.10-19.fc24.i686 requires libboost_system.so.1.58.0
1:gnash-cygnal-0.8.10-19.fc24.i686 requires 
libboost_serialization.so.1.58.0
1:gnash-cygnal-0.8.10-19.fc24.i686 requires 
libboost_program_options.so.1.58.0
1:gnash-cygnal-0.8.10-19.fc24.i686 requires libboost_iostreams.so.1.58.0
1:gnash-cygnal-0.8.10-19.fc24.i686 requires libboost_date_time.so.1.58.0
1:gnash-extension-dejagnu-0.8.10-19.fc24.i686 requires 
libboost_thread.so.1.58.0
1:gnash-extension-dejagnu-0.8.10-19.fc24.i686 requires 
libboost_system.so.1.58.0
1:gnash-extension-dejagnu-0.8.10-19.fc24.i686 requires 
libboost_program_options.so.1.58.0
1:gnash-extension-dejagnu-0.8.10-19.fc24.i686 requires 
libboost_iostreams.so.1.58.0
1:gnash-extension-fileio-0.8.10-19.fc24.i686 requires 
libboost_thread.so.1.58.0
1:gnash-extension-fileio-0.8.10-19.fc24.i686 requires 
libboost_system.so.1.58.0
1:gnash-extension-fileio-0.8.10-19.fc24.i686 requires 
libboost_program_options.so.1.58.0
1:gnash-extension-fileio-0.8.10-19.fc24.i686 requires 
libboost_iostreams.so.1.58.0
1:gnash-extension-lirc-0.8.10-19.fc24.i686 requires 
libboost_thread.so.1.58.0
1:gnash-extension-lirc-0.8.10-19.fc24.i686 requires 
libboost_system.so.1.58.0
1:gnash-extension-lirc-0.8.10-19.fc24.i686 requires 
libboost_program_options.so.1.58.0
1:gnash-extension-lirc-0.8.10-19.fc24.i686 requires 
libboost_iostreams.so.1.58.0
1:gnash-extension-mysql-0.8.10-19.fc24.i686 requires 
libboost_thread.so.1.58.0
1:gnash-extension-mysql-0.8.10-19.fc24.i686 requires 
libboost_system.so.1.58.0
1:gnash-extension-mysql-0.8.10-19.fc24.i686 requires 
libboost_program_options.so.1.58.0
1:gnash-extension-mysql-0.8.10-19.fc24.i686 requires 
libboost_iostreams.so.1.58.0
1:gnash-klash-0.8.10-19.fc24.i686 requires libboost_system.so.1.58.0
1:gnash-klash-0.8.10-19.fc24.i686 requires 

F-23 Branched report: 20150910 changes

[Fedora Branched Report]

Compose started at Thu Sep 10 07:15:03 UTC 2015
Broken deps for armhfp
--
[ScientificPython]
ScientificPython-2.8-20.fc22.armv7hl requires libmpi.so.1
[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
[cego]
cego-2.20.21-3.fc23.armv7hl requires liblfcbase.so.1
[dpm-contrib-admintools]
dpm-contrib-admintools-0.2.1-6.fc23.armv7hl requires 
MySQL-python(armv7hl-32)
[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
[licq]
licq-1.8.2-9.fc23.armv7hl requires libboost_regex.so.1.57.0
[mariadb-galera]
1:mariadb-galera-server-10.0.17-5.fc23.armv7hl requires galera >= 
0:25.3.3
[moon-buggy]
moon-buggy-1.0.51-14.fc23.armv7hl requires libesd.so.0
[netbeans-platform]
1:netbeans-platform-harness-7.0.1-11.fc22.armv7hl requires cobertura >= 
0:1.9.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 npm(requestretry) < 
0:1.3
nodejs-grunt-saucelabs-8.6.1-2.fc23.noarch requires npm(requestretry) 
>= 0:1.2.2
nodejs-grunt-saucelabs-8.6.1-2.fc23.noarch requires npm(lodash) >= 
0:3.7.0
nodejs-grunt-saucelabs-8.6.1-2.fc23.noarch requires npm(colors) >= 
0:1.0.0
[nodejs-proxy-agent]
nodejs-proxy-agent-1.1.0-1.fc22.noarch requires npm(socks-proxy-agent) 
< 0:1
[nodejs-socks-proxy-agent]
nodejs-socks-proxy-agent-1.0.0-2.fc23.noarch requires npm(socks-client) 
< 0:2
nodejs-socks-proxy-agent-1.0.0-2.fc23.noarch requires npm(socks-client) 
>= 0:1.1.2
nodejs-socks-proxy-agent-1.0.0-2.fc23.noarch requires npm(extend) < 0:2
[oat]
oat-appraiser-1.6.0-16.fc22.armv7hl requires tomcat-servlet-3.0-api
oat-client-1.6.0-16.fc22.armv7hl requires tomcat-servlet-3.0-api
[oozie]
oozie-4.0.1-5.fc22.noarch requires mvn(org.apache.pig:pig)
oozie-4.0.1-5.fc22.noarch requires mvn(org.apache.hive:hive-serde)
oozie-4.0.1-5.fc22.noarch requires mvn(org.apache.hive:hive-metastore)
oozie-4.0.1-5.fc22.noarch requires 

Re: Orphaned packages available for new point of contact

[Richard Shaw]

Already took nec2c, I've been maintaining it for over a year anyway.

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

limb changed perl-sig's 'watchbugzilla' permission on perl-HTTP-Headers-Fast (f23) to 'Approved'

[notifications]

limb changed perl-sig's 'watchbugzilla' permission on perl-HTTP-Headers-Fast 
(f23) to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-HTTP-Headers-Fast/
--
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

limb changed perl-sig's 'watchbugzilla' permission on perl-HTTP-Headers-Fast (f21) to 'Approved'

[notifications]

limb changed perl-sig's 'watchbugzilla' permission on perl-HTTP-Headers-Fast 
(f21) to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-HTTP-Headers-Fast/
--
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

limb changed perl-sig's 'watchcommits' permission on perl-HTTP-Headers-Fast (master) to 'Approved'

[notifications]

limb changed perl-sig's 'watchcommits' permission on perl-HTTP-Headers-Fast 
(master) to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-HTTP-Headers-Fast/
--
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

limb changed perl-sig's 'watchcommits' permission on perl-HTTP-Headers-Fast (f21) to 'Approved'

[notifications]

limb changed perl-sig's 'watchcommits' permission on perl-HTTP-Headers-Fast 
(f21) to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-HTTP-Headers-Fast/
--
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

limb changed perl-sig's 'watchcommits' permission on perl-HTTP-Headers-Fast (f22) to 'Approved'

[notifications]

limb changed perl-sig's 'watchcommits' permission on perl-HTTP-Headers-Fast 
(f22) to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-HTTP-Headers-Fast/
--
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

limb changed perl-sig's 'watchbugzilla' permission on perl-HTTP-Headers-Fast (f22) to 'Approved'

[notifications]

limb changed perl-sig's 'watchbugzilla' permission on perl-HTTP-Headers-Fast 
(f22) to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-HTTP-Headers-Fast/
--
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

limb changed perl-sig's 'watchcommits' permission on perl-HTTP-Headers-Fast (f23) to 'Approved'

[notifications]

limb changed perl-sig's 'watchcommits' permission on perl-HTTP-Headers-Fast 
(f23) to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-HTTP-Headers-Fast/
--
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

limb changed perl-sig's 'watchbugzilla' permission on perl-HTTP-Headers-Fast (master) to 'Approved'

[notifications]

limb changed perl-sig's 'watchbugzilla' permission on perl-HTTP-Headers-Fast 
(master) to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-HTTP-Headers-Fast/
--
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 1259403] perl-Inline-C-0.76-1.fc24 FTBFS: tests fail with recent perl-ExtUtils-MakeMaker

[bugzilla]

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

Petr Šabata  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
 Resolution|--- |NOTABUG
Last Closed||2015-09-10 09:42:46



--- Comment #1 from Petr Šabata  ---
Fixed with the EU::MM 7.08 update.

-- 
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: Schedule for Thursday's FPC Meeting (2015-09-10 16:00 UTC)

[Mat Booth]

On 9 September 2015 at 19:21, James Antill  wrote:

>  Following is the list of topics that will be discussed in the FPC
> meeting Thursday at 2015-09-10 16:00 UTC in #fedora-meeting-1 on
> irc.freenode.net.
>
>  Local time information (via. rktime):
>
> 2015-09-10 09:00 Thu US/Pacific PDT
> 2015-09-10 12:00 Thu US/Eastern EDT
> 2015-09-10 16:00 Thu UTC <-
> 2015-09-10 17:00 Thu Europe/London  BST
> 2015-09-10 18:00 Thu Europe/Paris  CEST
> 2015-09-10 18:00 Thu Europe/Berlin CEST
> 2015-09-10 21:30 Thu Asia/Calcutta  IST
> --new day--
> 2015-09-11 00:00 Fri Asia/Singapore SGT
> 2015-09-11 00:00 Fri Asia/Hong_Kong HKT
> 2015-09-11 01:00 Fri Asia/Tokyo JST
> 2015-09-11 02:00 Fri Australia/Brisbane EST
>
>
>  Links to all tickets below can be found at:
>
> https://fedorahosted.org/fpc/report/13
>
> = New business =
>
> #topic #566 RPM file triggers
> .fpc 566
> https://fedorahosted.org/fpc/ticket/566
>
> #topic #567 Packaging Python 3 applications and modules for EPEL 7+
> .fpc 567
> https://fedorahosted.org/fpc/ticket/567
>
> = Open Floor =
>
>  For more complete details, please visit each individual ticket.  The
> report of the agenda items can be found at:
>
> https://fedorahosted.org/fpc/report/13
>
>  If you would like to add something to this agenda, you can reply to
> this e-mail, file a new ticket at https://fedorahosted.org/fpc,
> e-mail me directly, or bring it up at the end of the meeting, during
> the open floor topic. Note that added topics may be deferred until
> the following meeting.
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct



Apologies, I am not able to make it to today's meeting.


-- 
Mat Booth
http://fedoraproject.org/get-fedora
-- 
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: Orphaned packages available for new point of contact

[Matěj Cepl]

On 2015-09-10, 09:24 GMT, Mathieu Bridon wrote:
> On Thu, 2015-09-10 at 11:16 +0200, Matěj Cepl wrote:
>> On 2015-09-09, 19:37 GMT, Kevin Fenzi wrote:
>> > pytz
>> > python-dateutil
>> 
>> I see these two as too important to let them fall, so I am 
>> taking them. However, I would really really like to have some 
>> co-maintainers, because I don’t feel like I really understand 
>> the matter.
>
> Give acls to the python-sig group?

How would I do it?

Matěj

-- 
http://www.ceplovi.cz/matej/, Jabber: mc...@ceplovi.cz
GPG Finger: 89EF 4BC6 288A BF43 1BAB  25C3 E09F EF25 D964 84AC
 
If in desperation, read the documentation!
-- Brian D. Ripley, on R-help list

-- 
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 1261901] New: perl-Dist-Zilla-Plugin-ReadmeFromPod-0.33 is available

[bugzilla]

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

Bug ID: 1261901
   Summary: perl-Dist-Zilla-Plugin-ReadmeFromPod-0.33 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Dist-Zilla-Plugin-ReadmeFromPod
  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.33
Current version/release in rawhide: 0.32-3.fc23
URL: http://search.cpan.org/dist/Dist-Zilla-Plugin-ReadmeFromPod/

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 1261901] perl-Dist-Zilla-Plugin-ReadmeFromPod-0.33 is available

[bugzilla]

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



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

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

stderr:
sha256sum: /var/tmp/thn-Mon4g1/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

Minutes from Env-and-Stacks WG meeting (2015-09-10)

[Honza Horak]

==
#fedora-meeting-2: Env and Stacks (2015-09-10)
==


Meeting started by hhorak at 12:01:04 UTC. The full logs are available
at
http://meetbot.fedoraproject.org/fedora-meeting-2/2015-09-10/env-and-stacks.2015-09-10-12.01.log.html
.



Meeting summary
---
* Developer portal -- whatever is needed for finalizing  (hhorak,
  12:04:47)
  * ttomecek is still waiting to get some stuff merged to
Fedora-Dockerfiles  (hhorak, 12:09:30)
  * LINK: http://developer.fedorainfracloud.org/   (hhorak, 12:10:11)
  * LINK: https://fedorahosted.org/fedora-infrastructure/ticket/4876
(hhorak, 12:10:19)
  * work still to be done: packaging ruby packages (about 20)  (hhorak,
12:11:29)
  * content that is still missing to be able to deploy the developer
portal: docker, devassistant, python, a basic guide for openshift
(hhorak, 12:22:43)
  * IDEA: to have linking to some categories on fedora ask matching the
topic on Developer portal, like python, ruby, vagrant.. for example
link from Python content could point to ask with python tag
(hhorak, 12:24:14)
  * developer portal should have some link at getfedora.org  (hhorak,
12:32:58)

* RepoFunnel and the Software Component Pipeline -- any feedback
  (hhorak, 12:33:39)
  * LINK:

https://fedoraproject.org/wiki/Env_and_Stacks/Projects/SoftwareComponentPipeline
(vpavlin, 12:36:12)
  * LINK: https://github.com/ncoghlan/repofunnel   (ncoghlan, 12:36:25)
  * LINK:

https://fedoraproject.org/wiki/Env_and_Stacks/Projects/SoftwareComponentPipeline
(vpavlin, 12:36:32)
  * ACTION: everybody look more closely to the SoftwareComponentPipeline
proposal and let's provide feedback/additional questions on ML
(hhorak, 12:38:45)

* User level package management -- looking for AI  (hhorak, 12:39:37)
  * LINK:

https://lists.fedoraproject.org/pipermail/env-and-stacks/2015-August/000884.html
(hhorak, 12:41:17)
  * the perspective on that changed recently, ncoghlan more focusing on
*enabling* it better; trusting devs building *on* Fedora to make up
their own minds about whether or not to consume upstream package
repos directly  (hhorak, 12:45:46)
  * for *distro* components, focus on automating the upstream -> SRPM
pipeline and removing any manual steps ; for *custom* apps running
*on* Fedora/RHEL/CentOS, provide the tools, provide repo hosting
support in Pulp, but don't try to inject ourselves into the package
review process  (hhorak, 12:48:03)
  * LINK:
https://fedoraproject.org/wiki/User:Mizdebsk/FedoraMavenRepository
(hhorak, 12:53:35)

* Open floor?  (hhorak, 13:04:18)

Meeting ended at 13:11:10 UTC.




Action Items

* everybody look more closely to the SoftwareComponentPipeline proposal
  and let's provide feedback/additional questions on ML




Action Items, by person
---
* **UNASSIGNED**
  * everybody look more closely to the SoftwareComponentPipeline
proposal and let's provide feedback/additional questions on ML




People Present (lines said)
---
* hhorak (56)
* ncoghlan (29)
* vpavlin (21)
* asamalik (16)
* jstribny (15)
* phracek (9)
* ttomecek (6)
* zodbot (4)
* jkaluza (4)
* bkabrda (0)
* juhp (0)
* walters (0)




Generated by `MeetBot`_ 0.1.4

.. _`MeetBot`: http://wiki.debian.org/MeetBot

--
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: Orphaned packages available for new point of contact

[Thomas Spura]

Matěj Cepl  schrieb am Do., 10. Sep. 2015 um 12:56 Uhr:

> On 2015-09-10, 09:24 GMT, Mathieu Bridon wrote:
> > On Thu, 2015-09-10 at 11:16 +0200, Matěj Cepl wrote:
> >> On 2015-09-09, 19:37 GMT, Kevin Fenzi wrote:
> >> > pytz
> >> > python-dateutil
> >>
> >> I see these two as too important to let them fall, so I am
> >> taking them. However, I would really really like to have some
> >> co-maintainers, because I don’t feel like I really understand
> >> the matter.
> >
> > Give acls to the python-sig group?
>
> How would I do that? Is there an user named python-sig?
>

There is group::python-sig [1-2].

Best,
   Thomas

[1] https://admin.fedoraproject.org/pkgdb/packager/group::python-sig/
[2] https://fedoraproject.org/wiki/SIGs/Python#Python_SIG_FAS_group
-- 
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: Orphaned packages available for new point of contact

[Matěj Cepl]

On 2015-09-10, 09:24 GMT, Mathieu Bridon wrote:
> On Thu, 2015-09-10 at 11:16 +0200, Matěj Cepl wrote:
>> On 2015-09-09, 19:37 GMT, Kevin Fenzi wrote:
>> > pytz
>> > python-dateutil
>> 
>> I see these two as too important to let them fall, so I am 
>> taking them. However, I would really really like to have some 
>> co-maintainers, because I don’t feel like I really understand 
>> the matter.
>
> Give acls to the python-sig group?

How would I do that? Is there an user named python-sig?

Matěj

-- 
http://www.ceplovi.cz/matej/, Jabber: mc...@ceplovi.cz
GPG Finger: 89EF 4BC6 288A BF43 1BAB  25C3 E09F EF25 D964 84AC
 
If in desperation, read the documentation!
-- Brian D. Ripley, on R-help list

-- 
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: Orphaned packages available for new point of contact

[Abdel G . Martínez L .]

I will take care of python-xlib and python-couchdb.

On Wednesday, September 9, 2015, Kevin Fenzi  wrote:

> Greetings.
>
> Due to FESCo ticket: https://fedorahosted.org/fesco/ticket/1474
>
> * #1474 Non-responsive maintainer - Jef Spaleta  (jwb, 18:10:08)
>   * LINK: https://fedorahosted.org/fesco/ticket/1474   (jwb, 18:10:09)
>   * AGREED: Orphan jspaleta's packages (+7, 0, -0)  (jwb, 18:12:25)
>   * ACTION: nirik will orphan and mail devel list  (jwb, 18:12:50)
>
> I have orphaned packages that formerly had a point of contact of
> jspaleta.
>
> Please free free to take on point of contact for any that you wish to
> help maintain:
>
> g3data branch: f21
> g3data branch: f22
> g3data branch: f23
> g3data branch: master
> gourmet branch: f21
> gourmet branch: f22
> gourmet branch: f23
> gourmet branch: master
> ScientificPython branch: f21
> ScientificPython branch: f22
> ScientificPython branch: f23
> ScientificPython branch: master
> python-couchdb branch: f21
> python-couchdb branch: f22
> python-couchdb branch: f23
> python-couchdb branch: master
> safekeep branch: el5
> safekeep branch: el6
> safekeep branch: f21
> safekeep branch: f22
> safekeep branch: f23
> safekeep branch: master
> python-xlib branch: f21
> python-xlib branch: f22
> python-xlib branch: f23
> python-xlib branch: master
> pyscript branch: f21
> pyscript branch: f22
> pyscript branch: f23
> pyscript branch: master
> nec2c branch: f21
> nec2c branch: f22
> nec2c branch: f23
> nec2c branch: master
> scipy branch: el5
> scipy branch: f21
> scipy branch: f22
> scipy branch: f23
> scipy branch: master
> istanbul branch: f21
> istanbul branch: f22
> istanbul branch: f23
> istanbul branch: master
> python-matplotlib branch: el5
> python-matplotlib branch: f21
> python-matplotlib branch: f22
> python-matplotlib branch: f23
> python-matplotlib branch: master
> python-basemap-data branch: el5
> python-basemap-data branch: el6
> python-basemap-data branch: epel7
> python-basemap-data branch: f21
> python-basemap-data branch: f22
> python-basemap-data branch: f23
> python-basemap-data branch: master
> pytz branch: f21
> pytz branch: f22
> pytz branch: f23
> pytz branch: master
> telescope-server branch: f21
> telescope-server branch: f22
> telescope-server branch: f23
> telescope-server branch: master
> revelation branch: f21
> revelation branch: f22
> revelation branch: f23
> revelation branch: master
> python-basemap branch: el5
> python-basemap branch: el6
> python-basemap branch: epel7
> python-basemap branch: f21
> python-basemap branch: f22
> python-basemap branch: f23
> python-basemap branch: master
> gpodder branch: f21
> gpodder branch: f22
> gpodder branch: f23
> gpodder branch: master
> g3data branch: f21
> g3data branch: f22
> g3data branch: f23
> g3data branch: master
> gourmet branch: f21
> gourmet branch: f22
> gourmet branch: f23
> gourmet branch: master
> ScientificPython branch: f21
> ScientificPython branch: f22
> ScientificPython branch: f23
> ScientificPython branch: master
> python-dateutil branch: f21
> python-dateutil branch: f22
> python-dateutil branch: f23
> python-dateutil branch: master
> python-couchdb branch: f21
> python-couchdb branch: f22
> python-couchdb branch: f23
> python-couchdb branch: master
> safekeep branch: el5
> safekeep branch: el6
> safekeep branch: f21
> safekeep branch: f22
> safekeep branch: f23
> safekeep branch: master
> python-xlib branch: f21
> python-xlib branch: f22
> python-xlib branch: f23
> python-xlib branch: master
> pyscript branch: f21
> pyscript branch: f22
> pyscript branch: f23
> pyscript branch: master
> nec2c branch: f21
> nec2c branch: f22
> nec2c branch: f23
> nec2c branch: master
> scipy branch: el5
> scipy branch: f21
> scipy branch: f22
> scipy branch: f23
> scipy branch: master
> istanbul branch: f21
> istanbul branch: f22
> istanbul branch: f23
> istanbul branch: master
> python-matplotlib branch: el5
> python-matplotlib branch: f21
> python-matplotlib branch: f22
> python-matplotlib branch: f23
> python-matplotlib branch: master
> python-basemap-data branch: el5
> python-basemap-data branch: el6
> python-basemap-data branch: epel7
> python-basemap-data branch: f21
> python-basemap-data branch: f22
> python-basemap-data branch: f23
> python-basemap-data branch: master
> pytz branch: f21
> pytz branch: f22
> pytz branch: f23
> pytz branch: master
> telescope-server branch: f21
> telescope-server branch: f22
> telescope-server branch: f23
> telescope-server branch: master
> revelation branch: f21
> revelation branch: f22
> revelation branch: f23
> revelation branch: master
> python-basemap branch: el5
> python-basemap branch: el6
> python-basemap branch: epel7
> python-basemap branch: f21
> python-basemap branch: f22
> python-basemap branch: f23
> python-basemap branch: master
> gpodder branch: f21
> gpodder branch: f22
> gpodder branch: f23
> gpodder branch: master
>
>

-- 
*Abdel G. Martínez L.*
-- 
devel mailing list
devel@lists.fedoraproject.org

Re: Orphaned packages available for new point of contact

[Christopher Meng]

Should be time to drop istanbul, since it's no longer developed.

-- 

Yours sincerely,
Christopher Meng

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

limb changed psabata's 'commit' permission on perl-HTTP-Headers-Fast (master) to 'Approved'

[notifications]

limb changed psabata's 'commit' permission on perl-HTTP-Headers-Fast (master) 
to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-HTTP-Headers-Fast/
--
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

limb changed psabata's 'watchbugzilla' permission on perl-HTTP-Headers-Fast (master) to 'Approved'

[notifications]

limb changed psabata's 'watchbugzilla' permission on perl-HTTP-Headers-Fast 
(master) to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-HTTP-Headers-Fast/
--
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

/var/log/dnf.log

[Reindl Harald]

what in the world is that garbage instead a clear and simple log as 
/var/log/yum.log just listing installed, removed and updated packages?


frankly it's impossible to write worksheets as admin what happened in 
the last few weeks with such needless verbose logging


Sep 10 15:26:08 INFO Gesamtgröße: 412 k
Sep 10 15:26:08 INFO Pakete werden heruntergeladen:
Sep 10 15:26:08 INFO Transaktionsüberprüfung wird ausgeführt
Sep 10 15:26:08 INFO Transaktionsprüfung war erfolgreich.
Sep 10 15:26:08 INFO Transaktion wird getestet
Sep 10 15:26:08 INFO Transaktionstest war erfolgreich.
Sep 10 15:26:08 DDEBUG timer: transaction test: 2 ms
Sep 10 15:26:08 INFO Transaktion wird ausgeführt
Sep 10 15:26:08 DDEBUG RPM transaction start.
Sep 10 15:26:08 DDEBUG RPM transaction over.
Sep 10 15:26:08 DDEBUG timer: verify transaction: 189 ms
Sep 10 15:26:08 DDEBUG timer: transaction: 396 ms
Sep 10 15:26:08 INFO
Aktualisiert:
  php-pecl-geoip.x86_64 10:1.1.0-1.fc22.20150910.rh 

  php-pecl-imagick.x86_64 10:3.1.2-1.fc22.20150910.rh 

  php-pecl-mailparse.x86_64 10:2.1.6-1.fc22.20150910.rh 

  php-pecl-mysqlnd_qc.x86_64 10:1.2.0-1.fc22.20150910.rh 

  php-pecl-ssh2.x86_64 10:0.12-1.fc22.20150910.rh 

  php-pecl-uploadprogress.x86_64 10:1.0.3.1-1.fc22.20150910.rh 

  php-pecl-xdebug.x86_64 10:2.3.3-1.fc22.20150910.rh 



Sep 10 15:26:08 INFO Komplett!
Sep 10 15:26:08 DDEBUG Cleaning up.
Sep 10 15:26:34 INFO --- logging initialized ---
Sep 10 15:26:34 DDEBUG timer: config: 7 ms
Sep 10 15:26:34 DEBUG cachedir: /var/cache/dnf
Sep 10 15:26:34 DEBUG DNF version: 1.1.1
Sep 10 15:26:34 DDEBUG Command: dnf --nogpgcheck -y update 
/home/builduser/rpmbuild/RPMS/x86_64/apr-1.5.2-3.fc22.20150910.rh.x86_64.rpm 
/home/builduser/rpmbuild/RPMS/x86_64/apr-devel-1.5.2-3.fc22.20150910.rh.x86_64.rpm 
/home/builduser/rpmbuild/RPMS/x86_64/apr-util-1.5.4-5.fc22.20150910.rh.x86_64.rpm 
/home/builduser/rpmbuild/RPMS/x86_64/apr-util-devel-1.5.4-5.fc22.20150910.rh.x86_64.rpm 
/home/builduser/rpmbuild/RPMS/x86_64/apr-util-mysql-1.5.4-5.fc22.20150910.rh.x86_64.rpm 
/home/builduser/rpmbuild/RPMS/x86_64/apr-util-nss-1.5.4-5.fc22.20150910.rh.x86_64.rpm 
/home/builduser/rpmbuild/RPMS/x86_64/apr-util-openssl-1.5.4-5.fc22.20150910.rh.x86_64.rpm 
/home/builduser/rpmbuild/RPMS/x86_64/arp-scan-1.8.4-1.fc22.20150910.rh.x86_64.rpm 
/home/builduser/rpmbuild/RPMS/x86_64/GeoIP-1.6.5-2.fc22.20150910.rh.x86_64.rpm 
/home/builduser/rpmbuild/RPMS/x86_64/GeoIP-devel-1.6.5-2.fc22.20150910.rh.x86_64.rpm 
/home/builduser/rpmbuild/RPMS/x86_64/gmime-2.6.20-6.fc22.20150910.rh.x86_64.rpm 
/home/builduser/rpmbuild/RPMS/x86_64/gmime-devel-2.6.20-6.fc22.20150910.rh.x86_64.rpm 
/home/builduser/rpmbuild/RPMS/x86_64/httpd-2.4.16-2.fc22.20150910.rh.x86_64.rpm 
/home/builduser/rpmbuild/RPMS/x86_64/httpd-devel-2.4.16-2.fc22.20150910.rh.x86_64.rpm 
/home/builduser/rpmbuild/RPMS/x86_64/httpd-tools-2.4.16-2.fc22.20150910.rh.x86_64.rpm 
/home/builduser/rpmbuild/RPMS/x86_64/lame-3.99.5-5.fc22.20150910.rh.x86_64.rpm 
/home/builduser/rpmbuild/RPMS/x86_64/lame-devel-3.99.5-5.fc22.20150910.rh.x86_64.rpm 
/home/builduser/rpmbuild/RPMS/x86_64/lame-libs-3.99.5-5.fc22.20150910.rh.x86_64.rpm 
/home/builduser/rpmbuild/RPMS/x86_64/libevent-2.0.22-6.fc22.20150910.rh.x86_64.rpm 
/home/builduser/rpmbuild/RPMS/x86_64/libevent-devel-2.0.22-6.fc22.20150910.rh.x86_64.rpm 
/home/builduser/rpmbuild/RPMS/x86_64/libnss-mysql-1.5-23.fc22.20150910.rh.x86_64.rpm 
/home/builduser/rpmbuild/RPMS/x86_64/libzdb-3.1-2.fc22.20150910.rh.x86_64.rpm 
/home/builduser/rpmbuild/RPMS/x86_64/libzdb-devel-3.1-2.fc22.20150910.rh.x86_64.rpm 
/home/builduser/rpmbuild/RPMS/x86_64/lzo-2.08-3.fc22.20150910.rh.x86_64.rpm 
/home/builduser/rpmbuild/RPMS/x86_64/lzo-devel-2.08-3.fc22.20150910.rh.x86_64.rpm 
/home/builduser/rpmbuild/RPMS/x86_64/lzo-minilzo-2.08-3.fc22.20150910.rh.x86_64.rpm 
/home/builduser/rpmbuild/RPMS/x86_64/mariadb-10.0.21-1.fc22.20150910.rh.x86_64.rpm 
/home/builduser/rpmbuild/RPMS/x86_64/mariadb-devel-10.0.21-1.fc22.20150910.rh.x86_64.rpm 
/home/builduser/rpmbuild/RPMS/x86_64/mariadb-libs-10.0.21-1.fc22.20150910.rh.x86_64.rpm 
/home/builduser/rpmbuild/RPMS/x86_64/mariadb-manpages-10.0.21-1.fc22.20150910.rh.x86_64.rpm 
/home/builduser/rpmbuild/RPMS/x86_64/mariadb-server-10.0.21-1.fc22.20150910.rh.x86_64.rpm 
/home/builduser/rpmbuild/RPMS/x86_64/mariadb-test-10.0.21-1.fc22.20150910.rh.x86_64.rpm 
/home/builduser/rpmbuild/RPMS/x86_64/minizip-1.2.8-7.fc22.20150910.rh.x86_64.rpm 
/home/builduser/rpmbuild/RPMS/x86_64/minizip-devel-1.2.8-7.fc22.20150910.rh.x86_64.rpm 
/home/builduser/rpmbuild/RPMS/x86_64/mod_actions-2.4.16-2.fc22.20150910.rh.x86_64.rpm 
/home/builduser/rpmbuild/RPMS/x86_64/mod_asis-2.4.16-2.fc22.20150910.rh.x86_64.rpm 
/home/builduser/rpmbuild/RPMS/x86_64/mod_auth_form-2.4.16-2.fc22.20150910.rh.x86_64.rpm 
/home/builduser/rpmbuild/RPMS/x86_64/mod_authn_anon-2.4.16-2.fc22.20150910.rh.x86_64.rpm 
/home/builduser/rpmbuild/RPMS/x86_64/mod_authn_dbd-2.4.16-2.fc22.20150910.rh.x86_64.rpm 

Proposal to reduce anti-bundling requirements

[Stephen Gallagher]

I assume that subject line got your attention.

I know this is a long-standing debate and that this thread is likely
to turn into an incomprehensible flamewar filled with the same tired
arguments, but I'm going to make a proposal and then attempt to
respond to many of those known arguments up-front (in the hopes that
we can try to keep the conversation on-track). Please keep the
conversation on devel@lists.fedoraproject.org . I CCed packaging@ to
make them aware of this discussion.



Right now, we have a policy that essentially forbids source code from
being bundled into a package. In technical terms, this means
essentially that the packaging policies mandate that any code that
appears more than once in the repository must be turned into a shared
library and dynamically linked into any package that requires it. Any
package that wants an exception to this must petition the Fedora
Packaging Committee and get an explicit exemption from this policy.
This process is heavyweight and sometimes inconsistent in how the
decision is made.

I would like to propose that the no-bundled-libraries policy be
amended  as follows: "Any package that has an existing mechanism to
link against a shared system library and functions correctly when
doing so must link against that library and not bundle it internally.
Any package whose upstream releases cannot link against a shared
system library (or are incompatible with the version in Fedora) may
bundle that library (without requiring a special exemption) but MUST
add Provides: bundled() =  in the spec file for each
known bundled library.(This will allow us to track down the bundling
when we need to). Package maintainers should continue attempt to
engage upstream to support linking against shared system libraries
wherever possible, due to the advantages it provides the package
maintainer."



The reason for this proposal is relatively simple: we know the
advantages to unbundling, particularly with security and resource-
usage. However, the world's developer community largely *does not
care*. We fought the good fight, we tried to bring people around to
seeing our reasoning and we failed.


The point of software is to provide a service to an end-user. Users
don't run software because it has good packaging policies, they run
software because it meets a need that they have. If they can't get
that software from Fedora, they *will* get it from another source (or
use a different OS that doesn't get in their way). I'll take a moment
to remind people that two of Fedora's Four Foundations are "Features"
and "First". We want Fedora to be the most feature-complete
distribution available and we want to get there before anyone else
does. I would say that holding to our no-bundling policy actively
defeats our efforts on that score.



Let me describe some of the advantages to bundling and to unbundling
(as noted so we can hopefully skip some of the hotter parts of the
flamewar). As I noted above, anything that is capable of unbundling
should remain unbundled for its advantages. But things that are not
currently capable (or can't be due to forwards/backwards compatibility
issues, etc.) really shouldn't be forced to attempt it.


== Advantages to using shared libraries ==
 * Security/Bugs - When a bug or security vulnerability is located in
a library, it needs to be patched in only a single package in order to
fix all applications using that library.
 * Resources - A shared library only needs to be loaded into memory
once, reducing the memory requirements of the system.

== Advantages to bundling ==
 * Guarantees that the application is running with the same set of
code that upstream tested. (Fewer Fedora-specific bugs means less
burden on the maintainer)
 * Simplifies packaging of updates. (Fedora maintainer does not need
to keep tabs on unbundling patches to keep in sync for new versions)
 * Increases the available pool of software that can be packaged
substantially (many modern languages such as Ruby and Go are
realistically only functional with allowable bundling)
 * Did I mention the reduction in maintainer burden yet?




Thank you for reading this far. I know that this is a topic that
people get highly passionate about, so please do your best to restrain
your responses to reasoned statments and avoid the temptation to get
angry. I'll summon up a third of our Four Foundations here: remember
that Fedora is built on "Friends" too. This should be a discussion and
not an argument.

signature.asc
Description: This is a digitally signed message part
-- 
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: [Fedora-packaging] Proposal to reduce anti-bundling requirements

[Jon Ciesla]

On Thu, Sep 10, 2015 at 8:53 AM, Stephen Gallagher 
wrote:

> I assume that subject line got your attention.
>
> Most definitely. :)

So it's basically the same but without FPC as a gatekeeper?  Do you have
any proposals for enforcement?  A periodic query of Provides (bundled-foo)
and a BZ requesting a review?  Sometime projects enable unbundling over
time.

-- 
http://cecinestpasunefromage.wordpress.com/

in your fear, seek only peace
in your fear, seek only love

-d. bowie
-- 
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: Proposal to reduce anti-bundling requirements

[Stephen Gallagher]

On Thu, 2015-09-10 at 16:42 +0200, Florian Weimer wrote:
> On 09/10/2015 03:53 PM, Stephen Gallagher wrote:
> 
> > I would like to propose that the no-bundled-libraries policy be
> > amended  as follows: "Any package that has an existing mechanism to
> > link against a shared system library and functions correctly when
> > doing so must link against that library and not bundle it
> > internally.
> > Any package whose upstream releases cannot link against a shared
> > system library (or are incompatible with the version in Fedora) may
> > bundle that library (without requiring a special exemption) but
> > MUST
> > add Provides: bundled() =  in the spec file for
> > each
> > known bundled library.(This will allow us to track down the
> > bundling
> > when we need to). Package maintainers should continue attempt to
> > engage upstream to support linking against shared system libraries
> > wherever possible, due to the advantages it provides the package
> > maintainer."
> 
> Is  the name of the SRPM which provides the system version
> of
> the library?

Exact implementation TBD. I didn't want to get too far into the
technical details. Assume it to be a generally agreed-upon format.


> 
> How do you propose to resolve symbol conflicts if both the system
> library and the bundled library are loaded into the same process? 
>  The
> current ELF linking scheme lacks good support for bundling libraries
> whose exported symbols have not been mangled in some way.
> 

I expect such cases to be rare and dealt with on an as-needed basis.
Generally, projects either bundle or don't. The fuzzy area might be
with plugins, I guess.

signature.asc
Description: This is a digitally signed message part
-- 
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: /var/log/dnf.log

[Brandon Vincent]

On Thu, Sep 10, 2015 at 6:31 AM, Reindl Harald  wrote:
> what in the world is that garbage instead a clear and simple log as
> /var/log/yum.log just listing installed, removed and updated packages?
>
> frankly it's impossible to write worksheets as admin what happened in the
> last few weeks with such needless verbose logging

It might be advantageous to look at the "debuglevel" option in dnf.conf.

Haven't tried messing with it.

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

ppisar pushed to perl-HTTP-Headers-Fast (master). "Import"

[notifications]

From d63af3ac6b6f1237fb5a8ea58b5764d68371413b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= 
Date: Thu, 10 Sep 2015 17:08:24 +0200
Subject: Import


diff --git a/.gitignore b/.gitignore
index e69de29..29a6643 100644
--- a/.gitignore
+++ b/.gitignore
@@ -0,0 +1 @@
+/HTTP-Headers-Fast-0.19.tar.gz
diff --git a/perl-HTTP-Headers-Fast.spec b/perl-HTTP-Headers-Fast.spec
new file mode 100644
index 000..89e05d2
--- /dev/null
+++ b/perl-HTTP-Headers-Fast.spec
@@ -0,0 +1,64 @@
+Name:   perl-HTTP-Headers-Fast
+Version:0.19
+Release:1%{?dist}
+Summary:Faster implementation of HTTP::Headers
+License:GPL+ or Artistic
+Group:  Development/Libraries
+URL:http://search.cpan.org/dist/HTTP-Headers-Fast/
+Source0:
http://www.cpan.org/authors/id/T/TO/TOKUHIROM/HTTP-Headers-Fast-%{version}.tar.gz
+BuildArch:  noarch
+BuildRequires:  perl
+BuildRequires:  perl(File::Basename)
+BuildRequires:  perl(File::Copy)
+BuildRequires:  perl(File::Spec)
+BuildRequires:  perl(Module::Build) >= 0.38
+BuildRequires:  perl(strict)
+BuildRequires:  perl(utf8)
+BuildRequires:  perl(warnings)
+# Run-time:
+BuildRequires:  perl(Carp)
+BuildRequires:  perl(HTTP::Date)
+BuildRequires:  perl(MIME::Base64)
+BuildRequires:  perl(Storable)
+# Tests
+BuildRequires:  perl(Test)
+BuildRequires:  perl(Test::More) >= 0.98
+BuildRequires:  perl(Test::Requires)
+BuildRequires:  perl(URI)
+# Optional tests:
+BuildRequires:  perl(HTTP::Headers) >= 5.822
+Requires:   perl(:MODULE_COMPAT_%(eval "`perl -V:version`"; echo $version))
+Requires:   perl(HTTP::Date)
+Requires:   perl(MIME::Base64)
+Requires:   perl(Storable)
+
+%description
+HTTP::Headers::Fast is a perl class for parsing/writing HTTP headers.
+
+%prep
+%setup -q -n HTTP-Headers-Fast-%{version}
+
+%build
+perl Build.PL installdirs=vendor
+./Build
+
+%install
+./Build install destdir=$RPM_BUILD_ROOT create_packlist=0
+%{_fixperms} $RPM_BUILD_ROOT/*
+
+%check
+./Build test
+
+%files
+%doc Changes README.md
+%license LICENSE
+%{perl_vendorlib}/*
+%{_mandir}/man3/*
+
+%changelog
+* Wed Sep 09 2015 Petr Pisar  - 0.19-1
+- Packaging correction (bug #1230227)
+- 0.19 bump
+
+* Mon Jun 08 2015 Ralf Corsépius  - 0.17-1
+- Initial package.
diff --git a/sources b/sources
index e69de29..0c30ad3 100644
--- a/sources
+++ b/sources
@@ -0,0 +1 @@
+c9493ff2fe0e1b9009d9add281a94be4  HTTP-Headers-Fast-0.19.tar.gz
-- 
cgit v0.10.2



http://pkgs.fedoraproject.org/cgit/perl-HTTP-Headers-Fast.git/commit/?h=master=d63af3ac6b6f1237fb5a8ea58b5764d68371413b
--
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: /var/log/dnf.log

[Jonathan Wakely]

On 10/09/15 08:06 -0700, Brandon Vincent wrote:

On Thu, Sep 10, 2015 at 6:31 AM, Reindl Harald  wrote:

what in the world is that garbage instead a clear and simple log as
/var/log/yum.log just listing installed, removed and updated packages?

frankly it's impossible to write worksheets as admin what happened in the
last few weeks with such needless verbose logging


It might be advantageous to look at the "debuglevel" option in dnf.conf.

Haven't tried messing with it.


Doesn't that affect logging to stdout, rather than to dnf.log?

--
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: [Fedora-packaging] Proposal to reduce anti-bundling requirements

[Stephen Gallagher]

On Thu, 2015-09-10 at 09:03 -0500, Jon Ciesla wrote:
> 
> 
> On Thu, Sep 10, 2015 at 8:53 AM, Stephen Gallagher  om> wrote:
> > I assume that subject line got your attention.
> > 
> Most definitely. :)
> 
> So it's basically the same but without FPC as a gatekeeper?  Do you
> have any proposals for enforcement?  A periodic query of Provides
> (bundled-foo) and a BZ requesting a review?  Sometime projects
> enable unbundling over time.
> 


I don't know that enforcement is strictly necessary. Maintainers that
care will self-enforce. Maintainers that don't care won't be aided by
this.

"Enforcement" implies adding more heavy process, which is part of the
problem this is trying to avoid.

signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[Test-Announce] Fedora 23 Beta Freeze

[Dennis Gilmore]

Hi all,

Tuesday was an important day on the Fedora 23 schedule[1], with two
significant cut-offs.

Tuesday was the Beta freeze[2]. This means that only packages which
fix accepted blocker or freeze exception bugs[3][4] will be marked as
'stable' and included in the Beta composes. Other builds will remain
in updates-testing until the Beta release is approved, at which point
the Beta freeze is lifted and packages can move to 'stable' as usual
until the Final freeze.

Finally, Tuesday was the '100% code complete deadline' Change 
Checkpoint[8],
meaning that Fedora 23 Changes must now be ' New accepted changes must 
be code

complete, meaning all the code required to enable to the new change is
finished. The level of code completeness is reflected as tracker bug 
state

ON_QA. The change does not have to be fully tested by this deadline'.

Regards

Dennis

[1] https://fedoraproject.org/wiki/Releases/23/Schedule
[2] https://fedoraproject.org/wiki/Milestone_freezes
[5] https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process
[6] https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process
[8] https://fedoraproject.org/wiki/Changes/Policy
___
test-announce mailing list
test-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/test-announce
--
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: Proposal to reduce anti-bundling requirements

[Peter Robinson]

>> > I would like to propose that the no-bundled-libraries policy be
>> > amended  as follows: "Any package that has an existing mechanism to
>> > link against a shared system library and functions correctly when
>> > doing so must link against that library and not bundle it
>> > internally.
>> > Any package whose upstream releases cannot link against a shared
>> > system library (or are incompatible with the version in Fedora) may
>> > bundle that library (without requiring a special exemption) but
>> > MUST
>> > add Provides: bundled() =  in the spec file for
>> > each
>> > known bundled library.(This will allow us to track down the
>> > bundling
>> > when we need to). Package maintainers should continue attempt to
>> > engage upstream to support linking against shared system libraries
>> > wherever possible, due to the advantages it provides the package
>> > maintainer."
>>
>> Is  the name of the SRPM which provides the system version
>> of
>> the library?
>
> Exact implementation TBD. I didn't want to get too far into the
> technical details. Assume it to be a generally agreed-upon format.
>
>
>>
>> How do you propose to resolve symbol conflicts if both the system
>> library and the bundled library are loaded into the same process?
>>  The
>> current ELF linking scheme lacks good support for bundling libraries
>> whose exported symbols have not been mangled in some way.
>>
>
> I expect such cases to be rare and dealt with on an as-needed basis.
> Generally, projects either bundle or don't. The fuzzy area might be
> with plugins, I guess.

It doesn't matter how rare they are, it'll only take a single bundled
library handled incorrectly to completely screw a running OS. I don't
think this is something that can just be swept under the carpet, it
needs to be addressed as a core part of the proposal and currently is
not.

Peter
-- 
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: /var/log/dnf.log

[Jonathan Wakely]

On 10/09/15 15:31 +0200, Reindl Harald wrote:
what in the world is that garbage instead a clear and simple log as 
/var/log/yum.log just listing installed, removed and updated packages?


Yes, it's unhelpful nonsense. There doesn't seem to be a replacement
for yum.log :-(


--
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: macros.python2 requires update in F21+

[Jason L Tibbitts III]

> "H" == Haïkel   writes:

H> Hi, Nobody answered, should I assume that everyone is ok with me
H> pushing Orion's patches in F21 and F22?

I'm for whatever works, but I should ask if there's any possibility of
getting these macros out of the main python package and into something
separate that we can update easily.  At least until we're done tweaking
things for the most part.  Some FPC folks are working on additional
macroization to handle the unfortunate EPEL multiple version situation
without having to make a mess of existing packages.

 - J<
___
python-devel mailing list
python-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/python-devel

Re: Proposal to reduce anti-bundling requirements

[Stephen Gallagher]

On Thu, 2015-09-10 at 16:04 +0100, Peter Robinson wrote:
> > > > I would like to propose that the no-bundled-libraries policy be
> > > > amended  as follows: "Any package that has an existing
> > > > mechanism to
> > > > link against a shared system library and functions correctly
> > > > when
> > > > doing so must link against that library and not bundle it
> > > > internally.
> > > > Any package whose upstream releases cannot link against a
> > > > shared
> > > > system library (or are incompatible with the version in
> > > > Fedora) may
> > > > bundle that library (without requiring a special exemption) but
> > > > MUST
> > > > add Provides: bundled() =  in the spec file
> > > > for
> > > > each
> > > > known bundled library.(This will allow us to track down the
> > > > bundling
> > > > when we need to). Package maintainers should continue attempt
> > > > to
> > > > engage upstream to support linking against shared system
> > > > libraries
> > > > wherever possible, due to the advantages it provides the
> > > > package
> > > > maintainer."
> > > 
> > > Is  the name of the SRPM which provides the system
> > > version
> > > of
> > > the library?
> > 
> > Exact implementation TBD. I didn't want to get too far into the
> > technical details. Assume it to be a generally agreed-upon format.
> > 
> > 
> > > 
> > > How do you propose to resolve symbol conflicts if both the system
> > > library and the bundled library are loaded into the same process?
> > >  The
> > > current ELF linking scheme lacks good support for bundling
> > > libraries
> > > whose exported symbols have not been mangled in some way.
> > > 
> > 
> > I expect such cases to be rare and dealt with on an as-needed
> > basis.
> > Generally, projects either bundle or don't. The fuzzy area might be
> > with plugins, I guess.
> 
> It doesn't matter how rare they are, it'll only take a single bundled
> library handled incorrectly to completely screw a running OS. I don't
> think this is something that can just be swept under the carpet, it
> needs to be addressed as a core part of the proposal and currently is
> not.
> 


I think that's overstating the problem, Peter. Users are running
hundreds of applications with bundled libraries today and are not
obviously encountering this potential problem, which leads me to
believe it's very uncommon and therefore not worth blocking progress
on. Yes, it would be useful to have a plan in place for how to deal
with it when it does happen. No, I don't think the plan has to be
perfect before it can move forward.



signature.asc
Description: This is a digitally signed message part
-- 
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: [EPEL-devel] Dealing with cyclic dependencies

[Dan Horák]

On Thu, 10 Sep 2015 03:00:17 -0400
"Bryan Chan"  wrote:

> 
> Dan Horák  wrote on 2015-09-08 01:56:54 PM:
> 
> > Often those packages contain a "bootstrap" macro that can be set to
> > 1 for an initial build with limited dependencies and to 0 for
> > production build. And for building for EPEL there should be a older
> > build (source rpm) available (because it had to bootstrapped also
> > for regular EPEL), so first rebuild this, and then the latest, or
> > next or whatever is necessary. The changelog in the spec files
> > and/or history in dist-git will show the details about the versions.
> >
> > Do you have a list of those problematic builds?
> 
> Hi Dan, thanks for the suggestion. My team mate has found a similar
> bootstrap macro in the ghc packages and is trying it out now.

for ghc specifically I would recommend to contact Jens Petersen (juhp
on #fedora-devel IRC) directly, he is the ghc maintainer in Fedora and
knows best all the weirdness in ghc packaging.

> I asked the person who did the original runs back in June but he
> doesn't remember where the circular dependencies came from. He
> thought it might be some Python- or Perl-related dependencies in a %
> test section of a package but he isn't sure. We will watch out for
> the issue and report if we see it again.

yeah, tests in perl-* are possible candidate, let us know and I guess we
can help


Dan
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

ppisar pushed to perl-HTTP-Headers-Fast (f23). "Import"

[notifications]

From d63af3ac6b6f1237fb5a8ea58b5764d68371413b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= 
Date: Thu, 10 Sep 2015 17:08:24 +0200
Subject: Import


diff --git a/.gitignore b/.gitignore
index e69de29..29a6643 100644
--- a/.gitignore
+++ b/.gitignore
@@ -0,0 +1 @@
+/HTTP-Headers-Fast-0.19.tar.gz
diff --git a/perl-HTTP-Headers-Fast.spec b/perl-HTTP-Headers-Fast.spec
new file mode 100644
index 000..89e05d2
--- /dev/null
+++ b/perl-HTTP-Headers-Fast.spec
@@ -0,0 +1,64 @@
+Name:   perl-HTTP-Headers-Fast
+Version:0.19
+Release:1%{?dist}
+Summary:Faster implementation of HTTP::Headers
+License:GPL+ or Artistic
+Group:  Development/Libraries
+URL:http://search.cpan.org/dist/HTTP-Headers-Fast/
+Source0:
http://www.cpan.org/authors/id/T/TO/TOKUHIROM/HTTP-Headers-Fast-%{version}.tar.gz
+BuildArch:  noarch
+BuildRequires:  perl
+BuildRequires:  perl(File::Basename)
+BuildRequires:  perl(File::Copy)
+BuildRequires:  perl(File::Spec)
+BuildRequires:  perl(Module::Build) >= 0.38
+BuildRequires:  perl(strict)
+BuildRequires:  perl(utf8)
+BuildRequires:  perl(warnings)
+# Run-time:
+BuildRequires:  perl(Carp)
+BuildRequires:  perl(HTTP::Date)
+BuildRequires:  perl(MIME::Base64)
+BuildRequires:  perl(Storable)
+# Tests
+BuildRequires:  perl(Test)
+BuildRequires:  perl(Test::More) >= 0.98
+BuildRequires:  perl(Test::Requires)
+BuildRequires:  perl(URI)
+# Optional tests:
+BuildRequires:  perl(HTTP::Headers) >= 5.822
+Requires:   perl(:MODULE_COMPAT_%(eval "`perl -V:version`"; echo $version))
+Requires:   perl(HTTP::Date)
+Requires:   perl(MIME::Base64)
+Requires:   perl(Storable)
+
+%description
+HTTP::Headers::Fast is a perl class for parsing/writing HTTP headers.
+
+%prep
+%setup -q -n HTTP-Headers-Fast-%{version}
+
+%build
+perl Build.PL installdirs=vendor
+./Build
+
+%install
+./Build install destdir=$RPM_BUILD_ROOT create_packlist=0
+%{_fixperms} $RPM_BUILD_ROOT/*
+
+%check
+./Build test
+
+%files
+%doc Changes README.md
+%license LICENSE
+%{perl_vendorlib}/*
+%{_mandir}/man3/*
+
+%changelog
+* Wed Sep 09 2015 Petr Pisar  - 0.19-1
+- Packaging correction (bug #1230227)
+- 0.19 bump
+
+* Mon Jun 08 2015 Ralf Corsépius  - 0.17-1
+- Initial package.
diff --git a/sources b/sources
index e69de29..0c30ad3 100644
--- a/sources
+++ b/sources
@@ -0,0 +1 @@
+c9493ff2fe0e1b9009d9add281a94be4  HTTP-Headers-Fast-0.19.tar.gz
-- 
cgit v0.10.2



http://pkgs.fedoraproject.org/cgit/perl-HTTP-Headers-Fast.git/commit/?h=f23=d63af3ac6b6f1237fb5a8ea58b5764d68371413b
--
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

ppisar pushed to perl-HTTP-Headers-Fast (f22). "Import"

[notifications]

From d63af3ac6b6f1237fb5a8ea58b5764d68371413b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= 
Date: Thu, 10 Sep 2015 17:08:24 +0200
Subject: Import


diff --git a/.gitignore b/.gitignore
index e69de29..29a6643 100644
--- a/.gitignore
+++ b/.gitignore
@@ -0,0 +1 @@
+/HTTP-Headers-Fast-0.19.tar.gz
diff --git a/perl-HTTP-Headers-Fast.spec b/perl-HTTP-Headers-Fast.spec
new file mode 100644
index 000..89e05d2
--- /dev/null
+++ b/perl-HTTP-Headers-Fast.spec
@@ -0,0 +1,64 @@
+Name:   perl-HTTP-Headers-Fast
+Version:0.19
+Release:1%{?dist}
+Summary:Faster implementation of HTTP::Headers
+License:GPL+ or Artistic
+Group:  Development/Libraries
+URL:http://search.cpan.org/dist/HTTP-Headers-Fast/
+Source0:
http://www.cpan.org/authors/id/T/TO/TOKUHIROM/HTTP-Headers-Fast-%{version}.tar.gz
+BuildArch:  noarch
+BuildRequires:  perl
+BuildRequires:  perl(File::Basename)
+BuildRequires:  perl(File::Copy)
+BuildRequires:  perl(File::Spec)
+BuildRequires:  perl(Module::Build) >= 0.38
+BuildRequires:  perl(strict)
+BuildRequires:  perl(utf8)
+BuildRequires:  perl(warnings)
+# Run-time:
+BuildRequires:  perl(Carp)
+BuildRequires:  perl(HTTP::Date)
+BuildRequires:  perl(MIME::Base64)
+BuildRequires:  perl(Storable)
+# Tests
+BuildRequires:  perl(Test)
+BuildRequires:  perl(Test::More) >= 0.98
+BuildRequires:  perl(Test::Requires)
+BuildRequires:  perl(URI)
+# Optional tests:
+BuildRequires:  perl(HTTP::Headers) >= 5.822
+Requires:   perl(:MODULE_COMPAT_%(eval "`perl -V:version`"; echo $version))
+Requires:   perl(HTTP::Date)
+Requires:   perl(MIME::Base64)
+Requires:   perl(Storable)
+
+%description
+HTTP::Headers::Fast is a perl class for parsing/writing HTTP headers.
+
+%prep
+%setup -q -n HTTP-Headers-Fast-%{version}
+
+%build
+perl Build.PL installdirs=vendor
+./Build
+
+%install
+./Build install destdir=$RPM_BUILD_ROOT create_packlist=0
+%{_fixperms} $RPM_BUILD_ROOT/*
+
+%check
+./Build test
+
+%files
+%doc Changes README.md
+%license LICENSE
+%{perl_vendorlib}/*
+%{_mandir}/man3/*
+
+%changelog
+* Wed Sep 09 2015 Petr Pisar  - 0.19-1
+- Packaging correction (bug #1230227)
+- 0.19 bump
+
+* Mon Jun 08 2015 Ralf Corsépius  - 0.17-1
+- Initial package.
diff --git a/sources b/sources
index e69de29..0c30ad3 100644
--- a/sources
+++ b/sources
@@ -0,0 +1 @@
+c9493ff2fe0e1b9009d9add281a94be4  HTTP-Headers-Fast-0.19.tar.gz
-- 
cgit v0.10.2



http://pkgs.fedoraproject.org/cgit/perl-HTTP-Headers-Fast.git/commit/?h=f22=d63af3ac6b6f1237fb5a8ea58b5764d68371413b
--
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: /var/log/dnf.log

[Reindl Harald]

Am 10.09.2015 um 17:38 schrieb David Sommerseth:

On 10/09/15 15:31, Reindl Harald wrote:

what in the world is that garbage instead a clear and simple log as
/var/log/yum.log just listing installed, removed and updated packages?

frankly it's impossible to write worksheets as admin what happened in
the last few weeks with such needless verbose logging


Did you take a look at /var/log/dnf.rpm.log?


no, because i did not assume it's existence

one example of a not well thought change

yum -> dnf
yum.log -> dnf.log

that would be logical (given that it's still not understandable change 
the name) but that new log should be called "dnf.debug.log" and frankly 
*not* exist in a enduser *default* install






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: Proposal to reduce anti-bundling requirements

[Ralf Corsepius]

On 09/10/2015 03:53 PM, Stephen Gallagher wrote:

I assume that subject line got your attention.



The reason for this proposal is relatively simple: we know the
advantages to unbundling, particularly with security and resource-
usage. However, the world's developer community largely *does not
care*. We fought the good fight, we tried to bring people around to
seeing our reasoning and we failed.


My view: It's an ongoing struggle and fight against upstream 
incompetence, carelessness, sloppiness and low-quality crap software. 
It's a fight we should not give up to, because it would cause damage the 
quality of Fedora.


In that sense, I feel you are undermining and torpedoing Fedora.

Ralf



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

man-db-2.7.3-2.fc24 with file triggers in rawhide

[Nikola Forró]

Hello,

I've pushed man-db with file triggers and crontab dependency dropped to
rawhide. Removing cron job means that there will be no periodic cache
update for user-configured manpaths. There has already been discussion
about this: https://lists.fedoraproject.org/pipermail/devel/2014-Octobe
r/thread.html#203357

I think the subpackage suggestion makes more sense now. Main package
with file triggers fully functional and without dependency on crontabs
or systemd, and subpackage providing only the periodic cache update
functionality for those who need it.

What do you think about it?

Regards,
Nikola
-- 
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: Proposal to reduce anti-bundling requirements

[Josh Boyer]

On Thu, Sep 10, 2015 at 10:24 AM, Ralf Corsepius  wrote:
> On 09/10/2015 04:08 PM, Josh Boyer wrote:
>>
>> On Thu, Sep 10, 2015 at 9:53 AM, Stephen Gallagher 
>> wrote:
>
>
>> Is the intention of your proposal to also allow Chromium into the main
>> Fedora repos?  I honestly can't tell where it draws the line.
>
>
> We have a long list of bundling exceptions in Fedora. I do not see much
> reasons why Chromium (or parts of it) could not be on this list.

I will be honest and say that I am very confused in your response
here.  The bundling Chromium does is much more extensive than
darktable, yet you believe Chromium can get an exception while denying
darktable?  That doesn't make sense to me.

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: [Fedora-packaging] Proposal to reduce anti-bundling requirements

[Paul W. Frields]

On Thu, Sep 10, 2015 at 04:18:00PM +0200, Ralf Corsepius wrote:
> On 09/10/2015 04:06 PM, Stephen Gallagher wrote:
> >On Thu, 2015-09-10 at 09:03 -0500, Jon Ciesla wrote:
> >>
> >>
> >>On Thu, Sep 10, 2015 at 8:53 AM, Stephen Gallagher  >>om> wrote:
> >>>I assume that subject line got your attention.
> >>>
> >>Most definitely. :)
> >>
> >>So it's basically the same but without FPC as a gatekeeper?  Do you
> >>have any proposals for enforcement?  A periodic query of Provides
> >>(bundled-foo) and a BZ requesting a review?  Sometime projects
> >>enable unbundling over time.
> >>
> >
> >
> >I don't know that enforcement is strictly necessary. Maintainers that
> >care will self-enforce. Maintainers that don't care won't be aided by
> >this.
> 
> Are you talking about upstream maintainers of fedora maintainers?

I took this to mean Fedora maintainers, not upstream, but on second
read it seems equally true in both cases.

> The cause of the majority of cases of bundling is upstream maintainers who
> violently refuse to comprehend the evilness of bundling and who use bundling
> because "it's so convenient" to them.

Use of terms like "violent" and "evil" belies an attitude toward
upstream developers that I don't believe helps either upstream or
Fedora.

> >"Enforcement" implies adding more heavy process, which is part of the
> >problem this is trying to avoid.
> You don't seem to be aware about the fact FPC already tries to enforce
> unbundling. Yes, this is a heavy and time-consuming process, esp. on
> occasions upstream's behave stubborn and refuse to listen.

I doubt OP is unaware of this.

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

Re: Proposal to reduce anti-bundling requirements

[Florian Weimer]

On 09/10/2015 03:53 PM, Stephen Gallagher wrote:

> I would like to propose that the no-bundled-libraries policy be
> amended  as follows: "Any package that has an existing mechanism to
> link against a shared system library and functions correctly when
> doing so must link against that library and not bundle it internally.
> Any package whose upstream releases cannot link against a shared
> system library (or are incompatible with the version in Fedora) may
> bundle that library (without requiring a special exemption) but MUST
> add Provides: bundled() =  in the spec file for each
> known bundled library.(This will allow us to track down the bundling
> when we need to). Package maintainers should continue attempt to
> engage upstream to support linking against shared system libraries
> wherever possible, due to the advantages it provides the package
> maintainer."

Is  the name of the SRPM which provides the system version of
the library?

How do you propose to resolve symbol conflicts if both the system
library and the bundled library are loaded into the same process?  The
current ELF linking scheme lacks good support for bundling libraries
whose exported symbols have not been mangled in some way.

-- 
Florian Weimer / Red Hat Product Security
-- 
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: Proposal to reduce anti-bundling requirements

[Andrew Haley]

On 09/10/2015 03:06 PM, Ralf Corsepius wrote:
> My view: It's an ongoing struggle and fight against upstream 
> incompetence, carelessness, sloppiness and low-quality crap software. 
> It's a fight we should not give up to, because it would cause damage the 
> quality of Fedora.
> 
> In that sense, I feel you are undermining and torpedoing Fedora.

Yeah.  In that sense we have a responsibility for raising the bar,
showing how a real OS should be done, with fewer of the kludges and
shortcuts which plague lesser offerings.  We can do better, we have
the skills, we know it's the right thing to do, so we should.

Andrew.
-- 
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: Proposal to reduce anti-bundling requirements

[Daniel P. Berrange]

On Thu, Sep 10, 2015 at 11:25:00AM -0400, Stephen Gallagher wrote:
> On Thu, 2015-09-10 at 16:04 +0100, Peter Robinson wrote:
> > > > > I would like to propose that the no-bundled-libraries policy be
> > > > > amended  as follows: "Any package that has an existing
> > > > > mechanism to
> > > > > link against a shared system library and functions correctly
> > > > > when
> > > > > doing so must link against that library and not bundle it
> > > > > internally.
> > > > > Any package whose upstream releases cannot link against a
> > > > > shared
> > > > > system library (or are incompatible with the version in
> > > > > Fedora) may
> > > > > bundle that library (without requiring a special exemption) but
> > > > > MUST
> > > > > add Provides: bundled() =  in the spec file
> > > > > for
> > > > > each
> > > > > known bundled library.(This will allow us to track down the
> > > > > bundling
> > > > > when we need to). Package maintainers should continue attempt
> > > > > to
> > > > > engage upstream to support linking against shared system
> > > > > libraries
> > > > > wherever possible, due to the advantages it provides the
> > > > > package
> > > > > maintainer."
> > > > 
> > > > Is  the name of the SRPM which provides the system
> > > > version
> > > > of
> > > > the library?
> > > 
> > > Exact implementation TBD. I didn't want to get too far into the
> > > technical details. Assume it to be a generally agreed-upon format.
> > > 
> > > 
> > > > 
> > > > How do you propose to resolve symbol conflicts if both the system
> > > > library and the bundled library are loaded into the same process?
> > > >  The
> > > > current ELF linking scheme lacks good support for bundling
> > > > libraries
> > > > whose exported symbols have not been mangled in some way.
> > > > 
> > > 
> > > I expect such cases to be rare and dealt with on an as-needed
> > > basis.
> > > Generally, projects either bundle or don't. The fuzzy area might be
> > > with plugins, I guess.
> > 
> > It doesn't matter how rare they are, it'll only take a single bundled
> > library handled incorrectly to completely screw a running OS. I don't
> > think this is something that can just be swept under the carpet, it
> > needs to be addressed as a core part of the proposal and currently is
> > not.
> > 
> 
> 
> I think that's overstating the problem, Peter. Users are running
> hundreds of applications with bundled libraries today and are not
> obviously encountering this potential problem, which leads me to
> believe it's very uncommon and therefore not worth blocking progress
> on. Yes, it would be useful to have a plan in place for how to deal
> with it when it does happen. No, I don't think the plan has to be
> perfect before it can move forward.

Even if the problems did occur, the user is going to see it whether
they get the app from Fedora or from a 3rd party repo. I concur that
avoiding bundling is the most desirable scenario for apps in Fedora
but if that can't be achieved, a pragmatic approach benefits the users.
Chucking darktable out of Fedora due to bundling, isn't going to change
what users run. They will still run the exact same RPMs as they would
get from Fedora, but we'll have forced them to search out and enable
a copr / 3rd party repo. This hasn't helped users of darktable in any
way, just put an extra stumbling block in their way which will make
them less happy with the Fedora experiance overall :-(

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|
-- 
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: [Fedora-packaging] Proposal to reduce anti-bundling requirements

[Adam Williamson]

On Thu, 2015-09-10 at 09:03 -0500, Jon Ciesla wrote:
> On Thu, Sep 10, 2015 at 8:53 AM, Stephen Gallagher  om>
> wrote:
> 
> > I assume that subject line got your attention.
> > 
> > Most definitely. :)
> 
> So it's basically the same but without FPC as a gatekeeper?  Do you
> have
> any proposals for enforcement?  A periodic query of Provides
> (bundled-foo)
> and a BZ requesting a review?  Sometime projects enable unbundling
> over
> time.

Do we have any kind of consistent 'enforcement' of the *current*
policy?
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net


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

Re: Proposal to reduce anti-bundling requirements

[Josh Boyer]

On Thu, Sep 10, 2015 at 9:53 AM, Stephen Gallagher  wrote:
> I assume that subject line got your attention.
>
> I know this is a long-standing debate and that this thread is likely
> to turn into an incomprehensible flamewar filled with the same tired
> arguments, but I'm going to make a proposal and then attempt to
> respond to many of those known arguments up-front (in the hopes that
> we can try to keep the conversation on-track). Please keep the
> conversation on devel@lists.fedoraproject.org . I CCed packaging@ to
> make them aware of this discussion.
>
>
>
> Right now, we have a policy that essentially forbids source code from
> being bundled into a package. In technical terms, this means
> essentially that the packaging policies mandate that any code that
> appears more than once in the repository must be turned into a shared
> library and dynamically linked into any package that requires it. Any
> package that wants an exception to this must petition the Fedora
> Packaging Committee and get an explicit exemption from this policy.
> This process is heavyweight and sometimes inconsistent in how the
> decision is made.
>
> I would like to propose that the no-bundled-libraries policy be
> amended  as follows: "Any package that has an existing mechanism to
> link against a shared system library and functions correctly when
> doing so must link against that library and not bundle it internally.
> Any package whose upstream releases cannot link against a shared
> system library (or are incompatible with the version in Fedora) may
> bundle that library (without requiring a special exemption) but MUST
> add Provides: bundled() =  in the spec file for each
> known bundled library.(This will allow us to track down the bundling
> when we need to). Package maintainers should continue attempt to
> engage upstream to support linking against shared system libraries
> wherever possible, due to the advantages it provides the package
> maintainer."

This seeks to amend the proposal for bundling within a SRPM itself.
It doesn't address the broader scope of delivering applications
outside of RPM, such as Docker containers or xdg-apps.  Those also
tend to bundle, but the bundling is done within the container.  In the
case of xdg-apps, they'll need to "bundle" anything that isn't
provided by the xdg-runtime.

Do you want to address the broader issue, or do you foresee that the
current Packaging guidelines simply won't apply to containerized apps
because they are too RPM specific?

> The reason for this proposal is relatively simple: we know the
> advantages to unbundling, particularly with security and resource-
> usage. However, the world's developer community largely *does not
> care*. We fought the good fight, we tried to bring people around to
> seeing our reasoning and we failed.
>
>
> The point of software is to provide a service to an end-user. Users
> don't run software because it has good packaging policies, they run
> software because it meets a need that they have. If they can't get
> that software from Fedora, they *will* get it from another source (or
> use a different OS that doesn't get in their way). I'll take a moment
> to remind people that two of Fedora's Four Foundations are "Features"
> and "First". We want Fedora to be the most feature-complete
> distribution available and we want to get there before anyone else
> does. I would say that holding to our no-bundling policy actively
> defeats our efforts on that score.

Is the intention of your proposal to also allow Chromium into the main
Fedora repos?  I honestly can't tell where it draws the line.

> Let me describe some of the advantages to bundling and to unbundling
> (as noted so we can hopefully skip some of the hotter parts of the
> flamewar). As I noted above, anything that is capable of unbundling
> should remain unbundled for its advantages. But things that are not
> currently capable (or can't be due to forwards/backwards compatibility
> issues, etc.) really shouldn't be forced to attempt it.
>
>
> == Advantages to using shared libraries ==
>  * Security/Bugs - When a bug or security vulnerability is located in
> a library, it needs to be patched in only a single package in order to
> fix all applications using that library.

I think it's worth expanding on this a bit.  Right now, the Security
team files bugs against the main instance of a library/package.  The
proposal seems to help mark bundled copies, but it will still require
more time for them to file bugs against packages that bundle.

>  * Resources - A shared library only needs to be loaded into memory
> once, reducing the memory requirements of the system.
>
> == Advantages to bundling ==
>  * Guarantees that the application is running with the same set of
> code that upstream tested. (Fewer Fedora-specific bugs means less
> burden on the maintainer)
>  * Simplifies packaging of updates. (Fedora maintainer does not need
> to keep tabs on unbundling patches to 

Re: [Fedora-packaging] Proposal to reduce anti-bundling requirements

[Ralf Corsepius]

On 09/10/2015 04:06 PM, Stephen Gallagher wrote:

On Thu, 2015-09-10 at 09:03 -0500, Jon Ciesla wrote:



On Thu, Sep 10, 2015 at 8:53 AM, Stephen Gallagher  wrote:

I assume that subject line got your attention.


Most definitely. :)

So it's basically the same but without FPC as a gatekeeper?  Do you
have any proposals for enforcement?  A periodic query of Provides
(bundled-foo) and a BZ requesting a review?  Sometime projects
enable unbundling over time.




I don't know that enforcement is strictly necessary. Maintainers that
care will self-enforce. Maintainers that don't care won't be aided by
this.


Are you talking about upstream maintainers of fedora maintainers?

The cause of the majority of cases of bundling is upstream maintainers 
who violently refuse to comprehend the evilness of bundling and who use 
bundling because "it's so convenient" to them.



"Enforcement" implies adding more heavy process, which is part of the
problem this is trying to avoid.
You don't seem to be aware about the fact FPC already tries to enforce 
unbundling. Yes, this is a heavy and time-consuming process, esp. on 
occasions upstream's behave stubborn and refuse to listen.


Ralf

--
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: Proposal to reduce anti-bundling requirements

[Stephen Gallagher]

On Thu, 2015-09-10 at 10:08 -0400, Josh Boyer wrote:
> On Thu, Sep 10, 2015 at 9:53 AM, Stephen Gallagher  om> wrote:
> > I assume that subject line got your attention.
> > 
> > I know this is a long-standing debate and that this thread is
> > likely
> > to turn into an incomprehensible flamewar filled with the same
> > tired
> > arguments, but I'm going to make a proposal and then attempt to
> > respond to many of those known arguments up-front (in the hopes
> > that
> > we can try to keep the conversation on-track). Please keep the
> > conversation on devel@lists.fedoraproject.org . I CCed packaging@
> > to
> > make them aware of this discussion.
> > 
> > 
> > 
> > Right now, we have a policy that essentially forbids source code
> > from
> > being bundled into a package. In technical terms, this means
> > essentially that the packaging policies mandate that any code that
> > appears more than once in the repository must be turned into a
> > shared
> > library and dynamically linked into any package that requires it.
> > Any
> > package that wants an exception to this must petition the Fedora
> > Packaging Committee and get an explicit exemption from this policy.
> > This process is heavyweight and sometimes inconsistent in how the
> > decision is made.
> > 
> > I would like to propose that the no-bundled-libraries policy be
> > amended  as follows: "Any package that has an existing mechanism to
> > link against a shared system library and functions correctly when
> > doing so must link against that library and not bundle it
> > internally.
> > Any package whose upstream releases cannot link against a shared
> > system library (or are incompatible with the version in Fedora) may
> > bundle that library (without requiring a special exemption) but
> > MUST
> > add Provides: bundled() =  in the spec file for
> > each
> > known bundled library.(This will allow us to track down the
> > bundling
> > when we need to). Package maintainers should continue attempt to
> > engage upstream to support linking against shared system libraries
> > wherever possible, due to the advantages it provides the package
> > maintainer."
> 
> This seeks to amend the proposal for bundling within a SRPM itself.
> It doesn't address the broader scope of delivering applications
> outside of RPM, such as Docker containers or xdg-apps.  Those also
> tend to bundle, but the bundling is done within the container.  In
> the
> case of xdg-apps, they'll need to "bundle" anything that isn't
> provided by the xdg-runtime.
> 
> Do you want to address the broader issue, or do you foresee that the
> current Packaging guidelines simply won't apply to containerized apps
> because they are too RPM specific?
> 

This proposal was specifically about RPM/SRPM bundling. I think the
broader issue may be impacted by any decision we make here (if we
allow RPM bundling then by definition bundling has precedent). I'd
prefer to keep the container/xdg/etc. discussion out of this thread
for fear of making the conversation too broad.


> > The reason for this proposal is relatively simple: we know the
> > advantages to unbundling, particularly with security and resource-
> > usage. However, the world's developer community largely *does not
> > care*. We fought the good fight, we tried to bring people around to
> > seeing our reasoning and we failed.
> > 
> > 
> > The point of software is to provide a service to an end-user. Users
> > don't run software because it has good packaging policies, they run
> > software because it meets a need that they have. If they can't get
> > that software from Fedora, they *will* get it from another source
> > (or
> > use a different OS that doesn't get in their way). I'll take a
> > moment
> > to remind people that two of Fedora's Four Foundations are
> > "Features"
> > and "First". We want Fedora to be the most feature-complete
> > distribution available and we want to get there before anyone else
> > does. I would say that holding to our no-bundling policy actively
> > defeats our efforts on that score.
> 
> Is the intention of your proposal to also allow Chromium into the
> main
> Fedora repos?  I honestly can't tell where it draws the line.
> 

I can't remember the specific issues around Chromium, so I don't
necessarily want to say yea or nay there. I *thought* I remembered
Chromium had issues beyond simple bundling though. If not, then I see
no problems with including it if this proposal passes.


> > Let me describe some of the advantages to bundling and to
> > unbundling
> > (as noted so we can hopefully skip some of the hotter parts of the
> > flamewar). As I noted above, anything that is capable of unbundling
> > should remain unbundled for its advantages. But things that are not
> > currently capable (or can't be due to forwards/backwards
> > compatibility
> > issues, etc.) really shouldn't be forced to attempt it.
> > 
> > 
> > == Advantages to using shared libraries ==
> >  * Security/Bugs - When 

Re: Proposal to reduce anti-bundling requirements

[Ralf Corsepius]

On 09/10/2015 04:08 PM, Josh Boyer wrote:

On Thu, Sep 10, 2015 at 9:53 AM, Stephen Gallagher  wrote:



Is the intention of your proposal to also allow Chromium into the main
Fedora repos?  I honestly can't tell where it draws the line.


We have a long list of bundling exceptions in Fedora. I do not see much 
reasons why Chromium (or parts of it) could not be on this list.


Ralf

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

ppisar uploaded HTTP-Headers-Fast-0.19.tar.gz for perl-HTTP-Headers-Fast

[notifications]

c9493ff2fe0e1b9009d9add281a94be4  HTTP-Headers-Fast-0.19.tar.gz

http://pkgs.fedoraproject.org/lookaside/pkgs/perl-HTTP-Headers-Fast/HTTP-Headers-Fast-0.19.tar.gz/md5/c9493ff2fe0e1b9009d9add281a94be4/HTTP-Headers-Fast-0.19.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: /var/log/dnf.log

[Brandon Vincent]

On Thu, Sep 10, 2015 at 8:25 AM, Jonathan Wakely  wrote:
> Doesn't that affect logging to stdout, rather than to dnf.log?

I was under the impression it did both.

Brandon Vincent
-- 
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: Proposal to reduce anti-bundling requirements

[Pádraig Brady]

On 10/09/15 14:53, Stephen Gallagher wrote:
> I assume that subject line got your attention.

> The reason for this proposal is relatively simple: we know the
> advantages to unbundling, particularly with security and resource-
> usage. However, the world's developer community largely *does not
> care*. We fought the good fight, we tried to bring people around to
> seeing our reasoning and we failed.

I'm not sure it follows that we compromise the advantages
of existing packaging processes.  How about we strive to
maintain clean separated packages, but where this is not practical
use container tech to provide the bundles?  That may involve
tighter integration of container registry with the app installer.

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

Fedora Rawhide 20150910 compose check report

[Fedora compose checker]

Missing expected images:

Kde Live i386
Workstation Live i386
Cloud base Disk i386
Cloud base Disk x86_64
Kde Live x86_64
Cloud atomic Disk x86_64
Kde Disk armhfp
Workstation Live x86_64

Images in this compose but not Rawhide 20150909:

Xfce Live x86_64
Xfce Live i386
Robotics Live i386
Xfce Disk armhfp
Robotics Live x86_64

No images in Rawhide 20150909 but not this.

Failed openQA tests: 38 of 38

ID: 1910Test: i386 generic_boot default_install
ID: 1909Test: x86_64 generic_boot default_install
ID: 1908Test: i386 universal server_no_swap
ID: 1907Test: i386 universal server_lvmthin
ID: 1906Test: i386 universal server_ext3
ID: 1905Test: i386 universal server_btrfs
ID: 1904Test: i386 universal server_kickstart_hdd
ID: 1903Test: i386 universal server_software_raid
ID: 1902Test: i386 universal server_multi_empty
ID: 1901Test: i386 universal server_simple_free_space
ID: 1900Test: i386 universal server_simple_encrypted
ID: 1899Test: i386 universal server_delete_partial
ID: 1898Test: i386 universal server_repository_http_variation
ID: 1897Test: i386 universal server_repository_http_graphical
ID: 1896Test: i386 universal server_mirrorlist_graphical
ID: 1895Test: i386 universal server_delete_pata
ID: 1894Test: i386 universal server_kickstart_user_creation
ID: 1893Test: i386 universal server_scsi_updates_img
ID: 1892Test: i386 universal server_sata_multi
ID: 1891Test: i386 universal package_set_minimal
ID: 1890Test: x86_64 universal server_no_swap
ID: 1889Test: x86_64 universal server_lvmthin
ID: 1888Test: x86_64 universal server_ext3
ID: 1887Test: x86_64 universal server_btrfs
ID: 1886Test: x86_64 universal server_kickstart_hdd
ID: 1885Test: x86_64 universal server_software_raid
ID: 1884Test: x86_64 universal server_multi_empty
ID: 1883Test: x86_64 universal server_simple_free_space
ID: 1882Test: x86_64 universal server_simple_encrypted
ID: 1881Test: x86_64 universal server_delete_partial
ID: 1880Test: x86_64 universal server_repository_http_variation
ID: 1879Test: x86_64 universal server_repository_http_graphical
ID: 1878Test: x86_64 universal server_mirrorlist_graphical
ID: 1877Test: x86_64 universal server_delete_pata
ID: 1876Test: x86_64 universal server_kickstart_user_creation
ID: 1875Test: x86_64 universal server_scsi_updates_img
ID: 1874Test: x86_64 universal server_sata_multi
ID: 1873Test: x86_64 universal package_set_minimal
-- 
Mail generated by check-compose:
https://git.fedorahosted.org/cgit/fedora-qa.git/tree/check-compose
-- 
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: Proposal to reduce anti-bundling requirements

[Florian Weimer]

On 09/10/2015 04:51 PM, Stephen Gallagher wrote:

>> How do you propose to resolve symbol conflicts if both the system
>> library and the bundled library are loaded into the same process? 
>>  The
>> current ELF linking scheme lacks good support for bundling libraries
>> whose exported symbols have not been mangled in some way.
>>
> 
> I expect such cases to be rare and dealt with on an as-needed basis.
> Generally, projects either bundle or don't. The fuzzy area might be
> with plugins, I guess.

Not just plugins, anything that happens to compile the bundled library
into a DSO (either by itself, or as part of a larger sub-component) will
likely leak colliding symbols, unless special care is taken not to.

If we expect more bundling, then we need an alternative to the current
ELF linking model, IMHO.

-- 
Florian Weimer / Red Hat Product Security
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

ppisar pushed to perl-HTTP-Headers-Fast (f21). "Import"

[notifications]

From d63af3ac6b6f1237fb5a8ea58b5764d68371413b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= 
Date: Thu, 10 Sep 2015 17:08:24 +0200
Subject: Import


diff --git a/.gitignore b/.gitignore
index e69de29..29a6643 100644
--- a/.gitignore
+++ b/.gitignore
@@ -0,0 +1 @@
+/HTTP-Headers-Fast-0.19.tar.gz
diff --git a/perl-HTTP-Headers-Fast.spec b/perl-HTTP-Headers-Fast.spec
new file mode 100644
index 000..89e05d2
--- /dev/null
+++ b/perl-HTTP-Headers-Fast.spec
@@ -0,0 +1,64 @@
+Name:   perl-HTTP-Headers-Fast
+Version:0.19
+Release:1%{?dist}
+Summary:Faster implementation of HTTP::Headers
+License:GPL+ or Artistic
+Group:  Development/Libraries
+URL:http://search.cpan.org/dist/HTTP-Headers-Fast/
+Source0:
http://www.cpan.org/authors/id/T/TO/TOKUHIROM/HTTP-Headers-Fast-%{version}.tar.gz
+BuildArch:  noarch
+BuildRequires:  perl
+BuildRequires:  perl(File::Basename)
+BuildRequires:  perl(File::Copy)
+BuildRequires:  perl(File::Spec)
+BuildRequires:  perl(Module::Build) >= 0.38
+BuildRequires:  perl(strict)
+BuildRequires:  perl(utf8)
+BuildRequires:  perl(warnings)
+# Run-time:
+BuildRequires:  perl(Carp)
+BuildRequires:  perl(HTTP::Date)
+BuildRequires:  perl(MIME::Base64)
+BuildRequires:  perl(Storable)
+# Tests
+BuildRequires:  perl(Test)
+BuildRequires:  perl(Test::More) >= 0.98
+BuildRequires:  perl(Test::Requires)
+BuildRequires:  perl(URI)
+# Optional tests:
+BuildRequires:  perl(HTTP::Headers) >= 5.822
+Requires:   perl(:MODULE_COMPAT_%(eval "`perl -V:version`"; echo $version))
+Requires:   perl(HTTP::Date)
+Requires:   perl(MIME::Base64)
+Requires:   perl(Storable)
+
+%description
+HTTP::Headers::Fast is a perl class for parsing/writing HTTP headers.
+
+%prep
+%setup -q -n HTTP-Headers-Fast-%{version}
+
+%build
+perl Build.PL installdirs=vendor
+./Build
+
+%install
+./Build install destdir=$RPM_BUILD_ROOT create_packlist=0
+%{_fixperms} $RPM_BUILD_ROOT/*
+
+%check
+./Build test
+
+%files
+%doc Changes README.md
+%license LICENSE
+%{perl_vendorlib}/*
+%{_mandir}/man3/*
+
+%changelog
+* Wed Sep 09 2015 Petr Pisar  - 0.19-1
+- Packaging correction (bug #1230227)
+- 0.19 bump
+
+* Mon Jun 08 2015 Ralf Corsépius  - 0.17-1
+- Initial package.
diff --git a/sources b/sources
index e69de29..0c30ad3 100644
--- a/sources
+++ b/sources
@@ -0,0 +1 @@
+c9493ff2fe0e1b9009d9add281a94be4  HTTP-Headers-Fast-0.19.tar.gz
-- 
cgit v0.10.2



http://pkgs.fedoraproject.org/cgit/perl-HTTP-Headers-Fast.git/commit/?h=f21=d63af3ac6b6f1237fb5a8ea58b5764d68371413b
--
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: /var/log/dnf.log

[David Sommerseth]

On 10/09/15 15:31, Reindl Harald wrote:
> what in the world is that garbage instead a clear and simple log as
> /var/log/yum.log just listing installed, removed and updated packages?
> 
> frankly it's impossible to write worksheets as admin what happened in
> the last few weeks with such needless verbose logging

Did you take a look at /var/log/dnf.rpm.log?


--
kind regards,

David Sommerseth

-- 
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: Proposal to reduce anti-bundling requirements

[Adam Williamson]

On Thu, 2015-09-10 at 09:53 -0400, Stephen Gallagher wrote:
> I assume that subject line got your attention.
> 
> I know this is a long-standing debate and that this thread is likely
> to turn into an incomprehensible flamewar filled with the same tired
> arguments, but I'm going to make a proposal and then attempt to
> respond to many of those known arguments up-front (in the hopes that
> we can try to keep the conversation on-track). Please keep the
> conversation on devel@lists.fedoraproject.org . I CCed packaging@ to
> make them aware of this discussion.
> 
> 
> 
> Right now, we have a policy that essentially forbids source code from
> being bundled into a package. In technical terms, this means
> essentially that the packaging policies mandate that any code that
> appears more than once in the repository must be turned into a shared
> library and dynamically linked into any package that requires it. Any
> package that wants an exception to this must petition the Fedora
> Packaging Committee and get an explicit exemption from this policy.
> This process is heavyweight and sometimes inconsistent in how the
> decision is made.

I'm in no way a fan of the current wording of our policies here - it's
extremely vague and, as you say, subject to various interpretations.
It's also known (though perhaps not by all?) that we are nowhere
*close* to actually meeting the policy as written, most obviously in
the area of webapps: I think every webapp in the distro still bundles
Javascript. There is/was an effort to try and unbundle JS; the current
state of play seems to be nicely encapsulated in
https://fedoraproject.org/wiki/Changes/jQuery , which is an F23 change
to unbundle a *single javascript library*, which appears to be stalled
or at least behind (viz the cheerful "Coming Early July!" messages). I
know of (and in at least one case am the maintainer of) various other
packages which have code that's clearly 'bundled', under a strict
reading of the existing guidelines.

Writing a new policy is something that should be done very carefully,
though.

To me there is a clear ecosystem angle on this. What's appropriate for
the core ecosystem of stuff written in non-bundly languages (C,
Python, Perl...) is not necessarily appropriate for Web 2.0-ish things
written in bundly languages (PHP (oh god PHP), Go...)

To me this naturally ties in with the Fedora.next and 'rings' changes.
I'd suggest that a good direction to look in would be different
policies for different 'rings' (or however we wind up conceiving of
different areas of the distribution). I've argued before that it's
difficult to clearly delineate rings/layers of the distribution, but
it seems we are going to be trying to do so in some way, and so long
as that's going to happen, it seems natural to attach any change of
the bundling policy to that effort.

I'd also suggest that we might still want to forbid bundling of *some*
things in layers where it's otherwise permitted. Your policy, for
instance, would allow us to package something which bundles glibc, if
it does not have "an existing mechanism to link against a shared
system [copy]". Do we really want to allow bundling of the things
which *do* play by The Old Rules - the core infrastructure stuff which
is still, by and large, developed according to those conventions?
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net


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

Re: /var/log/dnf.log

[Reindl Harald]

Am 10.09.2015 um 18:58 schrieb drago01:

On Thu, Sep 10, 2015 at 5:46 PM, Reindl Harald  wrote:


Am 10.09.2015 um 17:38 schrieb David Sommerseth:


On 10/09/15 15:31, Reindl Harald wrote:


what in the world is that garbage instead a clear and simple log as
/var/log/yum.log just listing installed, removed and updated packages?

frankly it's impossible to write worksheets as admin what happened in
the last few weeks with such needless verbose logging


Did you take a look at /var/log/dnf.rpm.log?


no, because i did not assume it's existence


 /var/log/dnf

-> found


really?

* cat /var/log/yum.log
* hmm, ok that's only from before the distupgrade
* replace "yum" with "dnf"
* oh my god

changes for the sake of the change are bad - period
__

2.4 MB logs just for a simple upgrade and some local rebuilds?

no idea why developers believe all their debug stuff is relevant for 
users these days, my rsyslog.conf has more "stop" lines that anything 
else


[root@testserver:~]$ ls /var/log/ | grep dnf
-rw-r-  1 rootroot2,4M 2015-09-10 15:49 dnf.librepo.log
-rw-r--r--  1 rootroot592K 2015-09-10 15:49 dnf.log
-rw-r--r--  1 rootroot 32K 2015-09-10 15:49 dnf.rpm.log
__

who the hell needs "/var/log/dnf.librepo.log" as long he is not a active 
dnf developer?


lr_handle_prepare_mirrorlist: Mirrorlist parsed
lr_handle_prepare_internal_mirrorlist: Finalizing internal mirrorlist
lr_handle_prepare_internal_mirrorlist: Finalizing mirrors reported via 
LRI_MIRRORS

lr_handle_perform: Downloading/Locating yum repo
lr_yum_use_local: Locating repo..
lr_yum_use_local_load_base: Found local mirrorlist: 
/var/cache/dnf/rpmfusion-nonfree-81e81e278b15607f/mirrorlist

lr_yum_use_local_load_base: Parsing repomd.xml
lr_yum_use_local_load_base: Repomd revision: 1438758464
lr_yum_use_local: Repository was successfully located
lr_yum_check_checksum_of_md_record: Checking checksum of 
/var/cache/dnf/rpmfusion-nonfree-81e81e278b15607f/repodata/b7756f980305b821834ed56075fdc083b1e535b1993d4aeab1b9b5f5fbc3c3a5-filelists.xml.gz 
(expected: 
b7756f980305b821834ed56075fdc083b1e535b1993d4aeab1b9b5f5fbc3c3a5 [sha256])
lr_checksum_fd_compare: Using checksum cached in xattr: 
[user.Zif.MdChecksum[1441890494]] 
b7756f980305b821834ed56075fdc083b1e535b1993d4aeab1b9b5f5fbc3c3a5

lr_yum_check_checksum_of_md_record: Checksum check - Passed
lr_yum_check_checksum_of_md_record: Checking checksum of 
/var/cache/dnf/rpmfusion-nonfree-81e81e278b15607f/repodata/98e5e02ec48ba9cc45306a620f68ea6fcd919486302cf3a1475cfb8bc7f4f80e-primary.xml.gz 
(expected: 
98e5e02ec48ba9cc45306a620f68ea6fcd919486302cf3a1475cfb8bc7f4f80e [sha256])
lr_checksum_fd_compare: Using checksum cached in xattr: 
[user.Zif.MdChecksum[1441890494]] 
98e5e02ec48ba9cc45306a620f68ea6fcd919486302cf3a1475cfb8bc7f4f80e

lr_yum_check_checksum_of_md_record: Checksum check - Passed
lr_handle_perform: Restoring an old SIGINT handler



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: Proposal to reduce anti-bundling requirements

[Florian Weimer]

On 09/10/2015 05:40 PM, Daniel P. Berrange wrote:

> Even if the problems did occur, the user is going to see it whether
> they get the app from Fedora or from a 3rd party repo.

Not necessarily.  Even more bundling (everything except glibc) tends to
fix it.

-- 
Florian Weimer / Red Hat Product Security
-- 
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: file triggers for updating fontconfig cache in rawhide

[Matthew Miller]

On Mon, Sep 07, 2015 at 02:13:28PM +0900, Akira TAGOH wrote:
> I've added the file triggers for fonts in rawhide to update the cache
> and dropped the call of fc-cache in %post/un from fontpackages. we may
> need to rebuild all of font packages eventually  though, please let me
> know if you see any issues about it.

I just discovered that trying to install the Noto font family in
Software will reliably kill a (relatively powerful) system. This will
fix that, right?


-- 
Matthew Miller

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: [Fedora-packaging] Proposal to reduce anti-bundling requirements

[Stephen Gallagher]

On Thu, 2015-09-10 at 11:02 -0500, Jason L Tibbitts III wrote:

> > > > > > "SG" == Stephen Gallagher  writes:
> SG> If they can't get that software from Fedora, they *will* get it
> from
> SG> another source (or use a different OS that doesn't get in their
> SG> way).
> 
> Exactly.  Let's ship binary drivers.
> 
> I know that's something of a straw man, but my point is that we must
> have some principles, and must work with upstreams to attempt to get
> them to at least understand those principles.  And we shouldn't give
> up
> on that just because someone wants some program which is easily
> provided
> by a copr anyway.
> 


Binary drivers are a different problem. We don't ship those because
there are *legal* concerns preventing it. We've got plenty of stuff in
COPRs right now that are not in Fedora proper *solely* because of
bundling policies and not because of any hard-line external reason.

signature.asc
Description: This is a digitally signed message part
-- 
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: [Fedora-packaging] Proposal to reduce anti-bundling requirements

[Jon Ciesla]

On Thu, Sep 10, 2015 at 10:44 AM, Adam Williamson <
adamw...@fedoraproject.org> wrote:

> On Thu, 2015-09-10 at 09:03 -0500, Jon Ciesla wrote:
> > On Thu, Sep 10, 2015 at 8:53 AM, Stephen Gallagher  > om>
> > wrote:
> >
> > > I assume that subject line got your attention.
> > >
> > > Most definitely. :)
> >
> > So it's basically the same but without FPC as a gatekeeper?  Do you
> > have
> > any proposals for enforcement?  A periodic query of Provides
> > (bundled-foo)
> > and a BZ requesting a review?  Sometime projects enable unbundling
> > over
> > time.
>
> Do we have any kind of consistent 'enforcement' of the *current*
>

Not really.  People find things and file BZs to get them fixed, but there's
really no pressure.


> policy?
> --
> Adam Williamson
> Fedora QA Community Monkey
> IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
> http://www.happyassassin.net
>
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct




-- 
http://cecinestpasunefromage.wordpress.com/

in your fear, seek only peace
in your fear, seek only love

-d. bowie
-- 
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: [Fedora-packaging] Proposal to reduce anti-bundling requirements

[Jason L Tibbitts III]

> "SG" == Stephen Gallagher  writes:

SG> Right now, we have a policy that essentially forbids source code
SG> from being bundled into a package.

Technically we only care if that bundled code is actually compiled in.

SG> In technical terms, this means essentially that the packaging
SG> policies mandate that any code that appears more than once in the
SG> repository must be turned into a shared library and dynamically
SG> linked into any package that requires it.

We're happy with static libraries as well, though of course dynamic libs
are preferable because then you really only need to fix issues in one
place.

SG> Any package that wants an exception to this must petition the Fedora
SG> Packaging Committee and get an explicit exemption from this policy.
SG> This process is heavyweight and sometimes inconsistent in how the
SG> decision is made.

We try to be consistent, but the committee does change over time as do
the opinions of the committee members.  If you have examples of what you
believe to be inconsistencies, please feel to raise them.  I'm guessing
that most of the complaints would stem from FPC allowing Firefox but not
whatever other program.

SG> I would like to propose that the no-bundled-libraries policy be
SG> amended as follows: "Any package that has an existing mechanism to
SG> link against a shared system library and functions correctly when
SG> doing so must link against that library and not bundle it
SG> internally.  Any package whose upstream releases cannot link against
SG> a shared system library (or are incompatible with the version in
SG> Fedora) may bundle that library (without requiring a special
SG> exemption) but MUST add Provides: bundled() =  in
SG> the spec file for each known bundled library.

Which is same as the current policy, minus anyone actually caring
whether this really happens.

I would not object to a weakening of the rules (and in fact I've pushed
a weakening of the rules before, leading to the current situation being
less strict than it was previously).  I would object rather strenuously
to just not bothering.

SG> The reason for this proposal is relatively simple: we know the
SG> advantages to unbundling, particularly with security and resource-
SG> usage. However, the world's developer community largely *does not
SG> care*. We fought the good fight, we tried to bring people around to
SG> seeing our reasoning and we failed.

We haven't really failed, though.  Good work has come of this, and if we
resist these bad habits then more good work can come of it, even to the
upstreams which currently resist.

SG> The point of software is to provide a service to an end-user. Users
SG> don't run software because it has good packaging policies, they run
SG> software because it meets a need that they have.

One could make the same argument for open source in general.

SG> If they can't get that software from Fedora, they *will* get it from
SG> another source (or use a different OS that doesn't get in their
SG> way).

Exactly.  Let's ship binary drivers.

I know that's something of a straw man, but my point is that we must
have some principles, and must work with upstreams to attempt to get
them to at least understand those principles.  And we shouldn't give up
on that just because someone wants some program which is easily provided
by a copr anyway.

 - J<
-- 
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: /var/log/dnf.log

[David Sommerseth]

On 10/09/15 17:46, Reindl Harald wrote:
> 
> Am 10.09.2015 um 17:38 schrieb David Sommerseth:
>> On 10/09/15 15:31, Reindl Harald wrote:
>>> what in the world is that garbage instead a clear and simple log as
>>> /var/log/yum.log just listing installed, removed and updated packages?
>>>
>>> frankly it's impossible to write worksheets as admin what happened in
>>> the last few weeks with such needless verbose logging
>>
>> Did you take a look at /var/log/dnf.rpm.log?
> 
> no, because i did not assume it's existence

Presumptions never reveals the truth.  Honestly, it took me 5 seconds to
figure out this.  This rant takes me minutes.

> one example of a not well thought change

That's an opinion - without much food for thought.

> yum -> dnf
> yum.log -> dnf.log
> 
> that would be logical (given that it's still not understandable change
> the name) but that new log should be called "dnf.debug.log" and frankly
> *not* exist in a enduser *default* install

That is how you would solve it.  Just bite the bitter apple, that not
everybody thinks in the same ways as you do.  For me looking for
/var/log/dnf* actually made the dnf.rpm.log file the obvious place to
look for where rpm operations was involved.  But hey, that's me!

Life usually moves forward and things evolve - embrace it!
Disgruntlement mostly makes just you unhappy.


--
kind regards,

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