Re: Failing builds on rawhide

[Jan Synacek]

Peter Robinson  writes:

> On Thu, Nov 12, 2015 at 12:47 PM, Peter Robinson  wrote:
>> On Thu, Nov 12, 2015 at 12:41 PM, Jan Synacek  wrote:
>>> I'm getting this error:
>>>
>>> bash: /usr/bin/rpmbuild: No such file or directory
>>>
>>> http://koji.fedoraproject.org/koji/taskinfo?taskID=11804093
>>
>> I suspect that's due to python 3.5 being tagged in, it should be OK
>> shortly,  I'm keeping an eye on it.
>
> I think we should be good now, I resbumitted your task
>
> http://koji.fedoraproject.org/koji/taskinfo?taskID=11804206

Thank you!
-- 
Jan Synacek
Software Engineer, Red Hat


signature.asc
Description: PGP 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

lcons changed lcons's 'commit' permission on perl-Net-STOMP-Client (epel7) to 'Approved'

[notifications]

lcons changed lcons's 'commit' permission on perl-Net-STOMP-Client (epel7) to 
'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Net-STOMP-Client/
--
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

lcons changed lcons's 'commit' permission on perl-Net-STOMP-Client (master) to 'Approved'

[notifications]

lcons changed lcons's 'commit' permission on perl-Net-STOMP-Client (master) to 
'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Net-STOMP-Client/
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

pghmcfc pushed to perl-DateTime (perl-DateTime-1.21-1.fc24). "Update to 1.21 (..more)"

[notifications]

From 69df12bb3aa096168d011c4d3b7fb20252ae61a2 Mon Sep 17 00:00:00 2001
From: Paul Howarth 
Date: Fri, 13 Nov 2015 10:50:57 +
Subject: Update to 1.21

- New upstream release 1.21
  - Make all tests pass with the current DateTime::Locale
- Explicitly BR: perl-devel, needed for EXTERN.h
---
 perl-DateTime.spec | 27 +++
 sources|  2 +-
 2 files changed, 20 insertions(+), 9 deletions(-)

diff --git a/perl-DateTime.spec b/perl-DateTime.spec
index 1d7733c..3794e00 100644
--- a/perl-DateTime.spec
+++ b/perl-DateTime.spec
@@ -1,20 +1,19 @@
 Name:   perl-DateTime
 Epoch:  2
-Version:1.20
+Version:1.21
 Release:1%{?dist}
 Summary:Date and time object for Perl
-# Even though lib/DateTime.xs says `the same as Perl', it also points to the
-# LICENSE file (Artistic 2.0).  Reading the changelog entry for v0.56 suggests
-# this was simply overlooked when re-licensing.
-# Reported as rt#102546
 License:Artistic 2.0
 Group:  Development/Libraries
 URL:http://search.cpan.org/dist/DateTime/
 Source0:
http://www.cpan.org/authors/id/D/DR/DROLSKY/DateTime-%{version}.tar.gz
+BuildRequires:  coreutils
+BuildRequires:  findutils
+BuildRequires:  gcc
+BuildRequires:  make
 BuildRequires:  perl
-BuildRequires:  perl(Module::Build)
-BuildRequires:  perl(strict)
-BuildRequires:  perl(warnings)
+BuildRequires:  perl-devel
+BuildRequires:  perl(Module::Build) >= 0.28
 # Run-time:
 BuildRequires:  perl(base)
 BuildRequires:  perl(Carp)
@@ -26,9 +25,12 @@ BuildRequires:  perl(overload)
 BuildRequires:  perl(Params::Validate) >= 1.03
 BuildRequires:  perl(POSIX)
 BuildRequires:  perl(Scalar::Util)
+BuildRequires:  perl(strict)
 BuildRequires:  perl(Try::Tiny)
 BuildRequires:  perl(vars)
+BuildRequires:  perl(warnings)
 BuildRequires:  perl(warnings::register)
+# Optional Run-time:
 BuildRequires:  perl(XSLoader)
 # Tests:
 # Cwd not used
@@ -39,6 +41,7 @@ BuildRequires:  perl(Test::More) >= 0.96
 BuildRequires:  perl(Test::Warnings) >= 0.005
 BuildRequires:  perl(utf8)
 # Optional tests:
+BuildRequires:  perl(CPAN::Meta) >= 2.120900
 # circular dependency - perl(DateTime::Format::Strptime) >= 1.2000
 # Pod::Coverage::TrustPod not used
 # Pod::Wordlist not used
@@ -52,10 +55,13 @@ BuildRequires:  perl(Storable)
 # Test::Pod::Coverage 1.08 not used
 # Test::Spelling 0.12 not used
 # Test::Version not used
+BuildRequires:  perl(Test::Warn)
 Requires:   perl(:MODULE_COMPAT_%(eval "`perl -V:version`"; echo $version))
 Requires:   perl(XSLoader)
 
+# Avoid provides from DateTime.so
 %{?perl_default_filter}
+
 # Filter under-specified dependencies
 %global __requires_exclude 
%{?__requires_exclude:%__requires_exclude|}^perl\\((DateTime::Locale|DateTime::TimeZone|Params::Validate)\\)$
 
@@ -94,6 +100,11 @@ find %{buildroot} -type f -name '*.bs' -size 0 -exec rm -f 
{} \;
 %{_mandir}/man3/DateTime::LeapSecond.3*
 
 %changelog
+* Fri Nov 13 2015 Paul Howarth  - 2:1.21-1
+- Update to 1.21
+  - Make all tests pass with the current DateTime::Locale
+- Explicitly BR: perl-devel, needed for EXTERN.h
+
 * Fri Jul 24 2015 Petr Pisar  - 2:1.20-1
 - 1.20 bump
 
diff --git a/sources b/sources
index d97c8d9..73fdf8f 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-9cc3afee0f5cf6fb786aa7e2e32a89bd  DateTime-1.20.tar.gz
+15ba32ede10465fd8a9c26fbbb5f1945  DateTime-1.21.tar.gz
-- 
cgit v0.11.2



http://pkgs.fedoraproject.org/cgit/perl-DateTime.git/commit/?h=perl-DateTime-1.21-1.fc24=69df12bb3aa096168d011c4d3b7fb20252ae61a2
--
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: DNF is completly unable to act with local packages

[Honza Šilhan]

> From: "Honza Šilhan" 
> > From: "Michael Schwendt" 
> > If an _upgrade_ introduces new sub-packages or new dependencies, you
> > need a method that can install those new packages *and* update older
> > installed ones at the same time. Running "rpm -U *.rpm" is like asking
> > RPM to "upgrade the installation to the packages specified by *.rpm",
> > which may involve replacing older installed ones as well as adding new
> > packages to the installation.
> 
> I was suggesting that it would be possible to extend `strict` configuration
> option
> for updates. That means with `dnf update *.rpm --strict=0` you would achieve
> what you
> have said in this paragraph.

I made a mistake. It should be this command line `dnf update *.rpm 
--setopt=strict=0`.

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

psabata pushed to perl-POE-Component-Client-DNS (f22). "Perl 5.22 rebuild"

[notifications]

From ac60ac64851672d2c9c54f4c7f705eb4f69c9458 Mon Sep 17 00:00:00 2001
From: Jitka Plesnikova 
Date: Sat, 6 Jun 2015 13:55:15 +0200
Subject: Perl 5.22 rebuild

---
 perl-POE-Component-Client-DNS.spec | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/perl-POE-Component-Client-DNS.spec 
b/perl-POE-Component-Client-DNS.spec
index 55bfb51..ea4f575 100644
--- a/perl-POE-Component-Client-DNS.spec
+++ b/perl-POE-Component-Client-DNS.spec
@@ -1,6 +1,6 @@
 Name:   perl-POE-Component-Client-DNS
 Version:1.053
-Release:5%{?dist}
+Release:6%{?dist}
 Summary:Non-blocking/concurrent DNS queries using Net::DNS and POE
 License:GPL+ or Artistic
 URL:http://search.cpan.org/dist/POE-Component-Client-DNS
@@ -58,6 +58,9 @@ make test
 %{_mandir}/man3/*.3*
 
 %changelog
+* Sat Jun 06 2015 Jitka Plesnikova  - 1.053-6
+- Perl 5.22 rebuild
+
 * Fri Aug 29 2014 Jitka Plesnikova  - 1.053-5
 - Perl 5.20 rebuild
 
-- 
cgit v0.11.2



http://pkgs.fedoraproject.org/cgit/perl-POE-Component-Client-DNS.git/commit/?h=f22=ac60ac64851672d2c9c54f4c7f705eb4f69c9458
--
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

psabata pushed to perl-POE-Component-Client-DNS (f23). "1.054 bump, Net::DNS 1.03 compatibility release (..more)"

[notifications]

From a5d6cc846b7e2904bb0646a73225b87513ddd20f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20=C5=A0abata?= 
Date: Fri, 13 Nov 2015 12:31:20 +0100
Subject: 1.054 bump, Net::DNS 1.03 compatibility release

- Package the license text
---
 .gitignore |  1 +
 perl-POE-Component-Client-DNS.spec | 35 +--
 sources|  2 +-
 3 files changed, 23 insertions(+), 15 deletions(-)

diff --git a/.gitignore b/.gitignore
index b939c76..5170032 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,2 +1,3 @@
 POE-Component-Client-DNS-1.051.tar.gz
 /POE-Component-Client-DNS-1.053.tar.gz
+/POE-Component-Client-DNS-1.054.tar.gz
diff --git a/perl-POE-Component-Client-DNS.spec 
b/perl-POE-Component-Client-DNS.spec
index 7452c39..7e0ad1d 100644
--- a/perl-POE-Component-Client-DNS.spec
+++ b/perl-POE-Component-Client-DNS.spec
@@ -1,33 +1,36 @@
 Name:   perl-POE-Component-Client-DNS
-Version:1.053
-Release:7%{?dist}
+Version:1.054
+Release:1%{?dist}
 Summary:Non-blocking/concurrent DNS queries using Net::DNS and POE
 License:GPL+ or Artistic
 URL:http://search.cpan.org/dist/POE-Component-Client-DNS
 Source0:
http://search.cpan.org/CPAN/authors/id/R/RC/RCAPUTO/POE-Component-Client-DNS-%{version}.tar.gz
-Requires:   perl(:MODULE_COMPAT_%(eval "$(perl -V:version)"; echo 
$version))
 BuildArch:  noarch
+# Build
+BuildRequires:  coreutils
+BuildRequires:  make
 BuildRequires:  perl
+BuildRequires:  perl(ExtUtils::MakeMaker) >= 6.76
+BuildRequires:  perl(strict)
+BuildRequires:  perl(warnings)
+# Runtime
 BuildRequires:  perl(Carp)
 BuildRequires:  perl(constant)
+BuildRequires:  perl(Net::DNS) >= 0.65
+BuildRequires:  perl(POE) >= 1.294
+BuildRequires:  perl(Socket)
+# Tests only
 BuildRequires:  perl(Data::Dumper)
-BuildRequires:  perl(ExtUtils::MakeMaker)
 %{?_with_network_tests:
 BuildRequires:  perl(lib)
 }
-BuildRequires:  perl(Net::DNS) >= 0.65
-BuildRequires:  perl(POE) >= 1.294
 BuildRequires:  perl(Scalar::Util)
-BuildRequires:  perl(Socket)
-BuildRequires:  perl(strict)
 BuildRequires:  perl(Test::More) >= 0.96
 BuildRequires:  perl(Test::NoWarnings) >= 1.02
-BuildRequires:  perl(warnings)
+Requires:   perl(:MODULE_COMPAT_%(eval "$(perl -V:version)"; echo 
$version))
 Requires:   perl(Net::DNS) >= 0.65
 Requires:   perl(POE) >= 1.294
 
-%{?perl_default_filter}
-
 %description
 POE::Component::Client::DNS provides a facility for non-blocking, concurrent
 DNS requests. Using POE, it allows other tasks to run while waiting for name
@@ -37,12 +40,11 @@ servers to respond.
 %setup -q -n POE-Component-Client-DNS-%{version}
 
 %build
-perl Makefile.PL INSTALLDIRS=vendor
+perl Makefile.PL INSTALLDIRS=vendor NO_PACKLIST=1
 make %{?_smp_mflags}
 
 %install
 make pure_install DESTDIR=%{buildroot}
-find %{buildroot} -type f -name .packlist -exec rm -f {} +
 %{_fixperms} %{buildroot}/*
 # the perldoc/pod documentation is nice, but I really found this much more
 # useful.
@@ -53,11 +55,16 @@ cp t/01_resolve.t example_resolve
 make test
 
 %files
+%license LICENSE
 %doc CHANGES README example_resolve
 %{perl_vendorlib}/*
-%{_mandir}/man3/*.3*
+%{_mandir}/man3/*
 
 %changelog
+* Fri Nov 13 2015 Petr Šabata  - 1.054-1
+- 1.054 bump, Net::DNS 1.03 compatibility release
+- Package the license text
+
 * Thu Jun 18 2015 Fedora Release Engineering  
- 1.053-7
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_23_Mass_Rebuild
 
diff --git a/sources b/sources
index 923aef5..bed6872 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-248fb8056f1b7085beb2d8f300a39e9c  POE-Component-Client-DNS-1.053.tar.gz
+8ce0200ec2fec64ead3bb3face0025a5  POE-Component-Client-DNS-1.054.tar.gz
-- 
cgit v0.11.2



http://pkgs.fedoraproject.org/cgit/perl-POE-Component-Client-DNS.git/commit/?h=f23=a5d6cc846b7e2904bb0646a73225b87513ddd20f
--
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

psabata pushed to perl-POE-Component-Client-DNS (master). "1.054 bump, Net::DNS 1.03 compatibility release (..more)"

[notifications]

From a5d6cc846b7e2904bb0646a73225b87513ddd20f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20=C5=A0abata?= 
Date: Fri, 13 Nov 2015 12:31:20 +0100
Subject: 1.054 bump, Net::DNS 1.03 compatibility release

- Package the license text
---
 .gitignore |  1 +
 perl-POE-Component-Client-DNS.spec | 35 +--
 sources|  2 +-
 3 files changed, 23 insertions(+), 15 deletions(-)

diff --git a/.gitignore b/.gitignore
index b939c76..5170032 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,2 +1,3 @@
 POE-Component-Client-DNS-1.051.tar.gz
 /POE-Component-Client-DNS-1.053.tar.gz
+/POE-Component-Client-DNS-1.054.tar.gz
diff --git a/perl-POE-Component-Client-DNS.spec 
b/perl-POE-Component-Client-DNS.spec
index 7452c39..7e0ad1d 100644
--- a/perl-POE-Component-Client-DNS.spec
+++ b/perl-POE-Component-Client-DNS.spec
@@ -1,33 +1,36 @@
 Name:   perl-POE-Component-Client-DNS
-Version:1.053
-Release:7%{?dist}
+Version:1.054
+Release:1%{?dist}
 Summary:Non-blocking/concurrent DNS queries using Net::DNS and POE
 License:GPL+ or Artistic
 URL:http://search.cpan.org/dist/POE-Component-Client-DNS
 Source0:
http://search.cpan.org/CPAN/authors/id/R/RC/RCAPUTO/POE-Component-Client-DNS-%{version}.tar.gz
-Requires:   perl(:MODULE_COMPAT_%(eval "$(perl -V:version)"; echo 
$version))
 BuildArch:  noarch
+# Build
+BuildRequires:  coreutils
+BuildRequires:  make
 BuildRequires:  perl
+BuildRequires:  perl(ExtUtils::MakeMaker) >= 6.76
+BuildRequires:  perl(strict)
+BuildRequires:  perl(warnings)
+# Runtime
 BuildRequires:  perl(Carp)
 BuildRequires:  perl(constant)
+BuildRequires:  perl(Net::DNS) >= 0.65
+BuildRequires:  perl(POE) >= 1.294
+BuildRequires:  perl(Socket)
+# Tests only
 BuildRequires:  perl(Data::Dumper)
-BuildRequires:  perl(ExtUtils::MakeMaker)
 %{?_with_network_tests:
 BuildRequires:  perl(lib)
 }
-BuildRequires:  perl(Net::DNS) >= 0.65
-BuildRequires:  perl(POE) >= 1.294
 BuildRequires:  perl(Scalar::Util)
-BuildRequires:  perl(Socket)
-BuildRequires:  perl(strict)
 BuildRequires:  perl(Test::More) >= 0.96
 BuildRequires:  perl(Test::NoWarnings) >= 1.02
-BuildRequires:  perl(warnings)
+Requires:   perl(:MODULE_COMPAT_%(eval "$(perl -V:version)"; echo 
$version))
 Requires:   perl(Net::DNS) >= 0.65
 Requires:   perl(POE) >= 1.294
 
-%{?perl_default_filter}
-
 %description
 POE::Component::Client::DNS provides a facility for non-blocking, concurrent
 DNS requests. Using POE, it allows other tasks to run while waiting for name
@@ -37,12 +40,11 @@ servers to respond.
 %setup -q -n POE-Component-Client-DNS-%{version}
 
 %build
-perl Makefile.PL INSTALLDIRS=vendor
+perl Makefile.PL INSTALLDIRS=vendor NO_PACKLIST=1
 make %{?_smp_mflags}
 
 %install
 make pure_install DESTDIR=%{buildroot}
-find %{buildroot} -type f -name .packlist -exec rm -f {} +
 %{_fixperms} %{buildroot}/*
 # the perldoc/pod documentation is nice, but I really found this much more
 # useful.
@@ -53,11 +55,16 @@ cp t/01_resolve.t example_resolve
 make test
 
 %files
+%license LICENSE
 %doc CHANGES README example_resolve
 %{perl_vendorlib}/*
-%{_mandir}/man3/*.3*
+%{_mandir}/man3/*
 
 %changelog
+* Fri Nov 13 2015 Petr Šabata  - 1.054-1
+- 1.054 bump, Net::DNS 1.03 compatibility release
+- Package the license text
+
 * Thu Jun 18 2015 Fedora Release Engineering  
- 1.053-7
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_23_Mass_Rebuild
 
diff --git a/sources b/sources
index 923aef5..bed6872 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-248fb8056f1b7085beb2d8f300a39e9c  POE-Component-Client-DNS-1.053.tar.gz
+8ce0200ec2fec64ead3bb3face0025a5  POE-Component-Client-DNS-1.054.tar.gz
-- 
cgit v0.11.2



http://pkgs.fedoraproject.org/cgit/perl-POE-Component-Client-DNS.git/commit/?h=master=a5d6cc846b7e2904bb0646a73225b87513ddd20f
--
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: Summary/Minutes for today's FESCo meeting (2015-11-11)

[Josh Boyer]

On Nov 13, 2015 12:03 AM, "Scott Schmit"  wrote:
>
> On Wed, Nov 11, 2015 at 01:54:32PM -0500, Adam Jackson wrote:
> > ===
> > #fedora-meeting: FESCO (2015-11-11)
> > ===
>
> The meeting summary isn't showing the resolutions from the meetings
> properly.  Reading the summary...
>
> > Meeting summary
> > ---
> > * #1491 clarifications/improvements for new bundling policy  (ajax,
> >   18:04:48)
> >   * LINK: https://fedorahosted.org/fesco/ticket/1491   (ajax, 18:04:48)
> >
> > * 1478 F24 Self Contained Changes  (ajax, 18:31:31)
> >   * LINK: https://fedorahosted.org/fesco/ticket/1478   (ajax, 18:31:32)
> >
> > * 1496 OpenH264 solution.fesco 1496  (ajax, 18:41:50)
> >   * LINK: https://fedorahosted.org/fesco/ticket/1496   (ajax, 18:41:51)
>
> ...discussion occurred on these topics, but nothing was agreed upon.
>
> According to the below...
>
> > 18:04:48  #topic #1491 clarifications/improvements for new
> > bundling policy
> > 18:28:29  #approved bundled libs must be appropriately filtered
> > from rpm Provides as documented in
> >
https://fedoraproject.org/wiki/Packaging:AutoProvidesAndRequiresFiltering
> > (+6 -0)
>
> > 18:31:31  #topic 1478 F24 Self Contained Changes
> > 18:33:57  #approved Change is approved (+6 -0)
>
> > 18:41:50  #topic 1496 OpenH264 solution.fesco 1496
> > 18:45:44  #approved Proposal is approved (+7 -0)
>
> ...that was not the case.

Wrong zodbot keyword.  It should have been #agreed.  The items were
approved and the tickets updated correctly though.

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: DNF is completly unable to act with local packages

[Reindl Harald]

Am 13.11.2015 um 12:13 schrieb Reindl Harald:



Am 13.11.2015 um 12:09 schrieb Honza Šilhan:

From: "Reindl Harald" 
would not be a topic if DNF would not be completly broken for "dnf
update *.rpm", in F22 it works sometimes while in F23 it is just
unuseable 99.9% of the time


That's an important information, it would be great if you would cooperate
mentioning it in your bug report and attaching the debugdata as was
requested
for each system. DNF versions are the same for F22 and F23 so I guess
that would
be a a different packaging of the local packages - we will know from
the debugdata


just download a random set of sub-packages with stricht versioned
inter-package dependencies from koji, type "dnf update *.rpm" and you
have your debug data


you have *all needed* informations to reproduce long ago

dnf downgrade dhcp\*

https://koji.fedoraproject.org/koji/buildinfo?buildID=695813


[root@srv-rhsoft:/downloads]$ dnf update *.rpm
Last metadata expiration check performed 0:11:21 ago on Fri Nov 13 
12:11:48 2015.

Fehler: package dhcp-common-12:4.3.3-6.fc23.noarch is not installable.
package dhcp-libs-12:4.3.3-6.fc23.x86_64 is not installable.
package dhcp-server-12:4.3.3-6.fc23.x86_64 is not installable
(try to add '--allowerasing' to command line to replace conflicting 
packages)



[root@srv-rhsoft:/downloads]$ ls
insgesamt 1,2M
-rw-r- 1 harry verwaltung 299K 2015-11-13 12:21 
dhcp-client-4.3.3-6.fc23.x86_64.rpm
-rw-r- 1 harry verwaltung 193K 2015-11-13 12:22 
dhcp-common-4.3.3-6.fc23.noarch.rpm
-rw-r- 1 harry verwaltung 137K 2015-11-13 12:21 
dhcp-libs-4.3.3-6.fc23.x86_64.rpm
-rw-r- 1 harry verwaltung 512K 2015-11-13 12:21 
dhcp-server-4.3.3-6.fc23.x86_64.rpm



https://bugzilla.redhat.com/show_bug.cgi?id=1263888#c9

--> Starting dependency resolution
--> Finished dependency resolution
Error: nothing provides dhcp-common = 12:4.3.3-6.fc23 needed by 
dhcp-client-12:4.3.3-6.fc23.x86_64.

package dhcp-common-12:4.3.3-6.fc23.noarch is not installable.
package dhcp-compat-12:4.3.3-6.fc23.x86_64 is not installable.
package dhcp-libs-12:4.3.3-6.fc23.x86_64 is not installable.
package dhcp-relay-12:4.3.3-6.fc23.x86_64 is not installable.
package dhcp-server-12:4.3.3-6.fc23.x86_64 is not installable.
package grep-2.22-1.fc23.x86_64 is not installable.
package nss-3.20.1-1.0.fc23.x86_64 is not installable.
package nss-sysinit-3.20.1-1.0.fc23.x86_64 is not installable.
package nss-tools-3.20.1-1.0.fc23.x86_64 is not installable




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: Building Images for Taskotron Disposable Clients

[Kamil Paral]

> As we get closer to putting disposable clients into production, we need
> a way to have updated images for those clients. I don't think this is
> news to anyone since the topic has come up several times before but now
> there's a bit more urgency :)
> 
> In my mind, we have the following requirements:
>  - Produces qcow2 images that work with testcloud
>  - can be run in an automated way
>  - allows adding/changing/customizing packages contained in image
>  - allows arbitrary repos to be specified
> 
> and the following "nice to have" things:
>  - can build branched and rawhide images
>  - builds images from scratch using only things provided by releng
>  - written in python
>  - builds more than qcow2 for some future-proofing

qemu-img can convert between many image formats, so native support in that tool 
is not that important, I think.

>  - can run well in a VM
> 
> Is there anything that I missed?

The image should be compatible with guestfish, so that we can e.g. copy in some 
files without rebuilding the image from scratch. Might be useful for e.g. 
additional ssh keys (we have cloud-init for that at the moment, but if we had 
some troubles with it or we needed something it doesn't support, this would be 
an alternative way). I'm not fully sure what the requirements are, but I think 
guestfish can work with almost anything, including LVM, so unless the tool 
creates some crazy partition layout, it should work with everything.


> 
> As far as I know, we're looking at two options right now:
> taskotron-vmbuilder and imagefactory. I've put together a list of
> the pros and cons that I know of for both tools. Thoughts on which
> direction to take would be appreciated.
> 
> Tim
> 
> 
> taskotron-vmbuilder [1] is a PoC system kparal built around
> virt-builder [2]. Images are specified in a yaml file and instead of
> building those images from scratch "It takes cleanly prepared, digitally
> signed OS templates and customizes them".
> 
> [1] https://bitbucket.org/fedoraqa/taskotron-vmbuilder
> [2] http://libguestfs.org/virt-builder.1.html
> 
> pros:
>  - already does almost everything we need

To be fair, there have been some issues regarding SELinux, and I'm not sure 
they are sorted yet. The SELinux contexts of files inside the image were not 
set properly and one more reboot with autorelabel was needed. Might be fixed 
now, or not, I haven't tried for a long time. With anaconda, we're not likely 
to hit these kind of issues (we'll hit different ones).

>  - fits all requirements
>  - builds quickly
>  - well supported
> 
> cons:
>  - requires blobs which are out of our control
>* yes, I know who does the work behind virt-builder. My concern
>  isn't with him, it's the general concept that I don't like. This
>  also gets into the fact that we would have pretty much no control
>  over timing of release for the base images.

All the tools required to create that "blob" - or image template (as they call 
it) - are open source and in Fedora, from what I see, so we can host our own. 
virt-builder man page says:
"For serious virt-builder use, you may want to create your own repository of 
templates."

This is how to create the template:
http://libguestfs.org/virt-builder.1.html#create-the-templates
For new stable Fedora releases, we can a single install manually, and use 
virt-sysprep on the image to have it ready. For Rawhide and maybe even for 
Branched, we might want to prepare a fresh new template more often, i.e. 
automate that. This is how libguestfs project does it:
https://github.com/libguestfs/libguestfs/blob/master/builder/website/fedora.sh

So you might see this as a combination of imagefactory and virt-builder-style 
process. The image is installed clean using anaconda once in a time (but very 
rarely), and most of the time just the prepared template is adjusted (updated 
with new packages), because it's much faster.

I'm not saying this is better or worse than alternatives, I just don't think 
this "blob" argument is quite right - we'd probably create and host our own 
templates, not rely on upstream one.


>  - limited support for rawhide and branched releases

There's limited (or no) support for it in the upstream repo, that's correct.

But if we host our own repo, according to the documentation and source code, it 
seems that as long as anaconda can install it, it should be possible to create 
an image for it. Which sounds as the same situation as with imagefactory. (Of 
course with the additional requirement that virt-* tools have to work in 
Rawhide/Branched).


>  - limited support for non-server spins

I'm not really sure what you mean, we can install any package set we want, so 
the only difference would be in the filesystem layout? The upstream templates 
seems to have only @core installed, in our own images we could adjust even that.

>  - output images are large in size

This is interesting. Theoretically I see no reason why official Cloud images 
should be smaller 

psabata pushed to perl-POE-Component-Client-DNS (f22). "- Rebuilt for https://fedoraproject.org/wiki/Fedora_23_Mass_Rebuild"

[notifications]

From dc77212c22a8930c68e2d17091fd31e9e198 Mon Sep 17 00:00:00 2001
From: Dennis Gilmore 
Date: Thu, 18 Jun 2015 05:13:24 +
Subject: - Rebuilt for https://fedoraproject.org/wiki/Fedora_23_Mass_Rebuild

---
 perl-POE-Component-Client-DNS.spec | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/perl-POE-Component-Client-DNS.spec 
b/perl-POE-Component-Client-DNS.spec
index ea4f575..7452c39 100644
--- a/perl-POE-Component-Client-DNS.spec
+++ b/perl-POE-Component-Client-DNS.spec
@@ -1,6 +1,6 @@
 Name:   perl-POE-Component-Client-DNS
 Version:1.053
-Release:6%{?dist}
+Release:7%{?dist}
 Summary:Non-blocking/concurrent DNS queries using Net::DNS and POE
 License:GPL+ or Artistic
 URL:http://search.cpan.org/dist/POE-Component-Client-DNS
@@ -58,6 +58,9 @@ make test
 %{_mandir}/man3/*.3*
 
 %changelog
+* Thu Jun 18 2015 Fedora Release Engineering  
- 1.053-7
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_23_Mass_Rebuild
+
 * Sat Jun 06 2015 Jitka Plesnikova  - 1.053-6
 - Perl 5.22 rebuild
 
-- 
cgit v0.11.2



http://pkgs.fedoraproject.org/cgit/perl-POE-Component-Client-DNS.git/commit/?h=f22=dc77212c22a8930c68e2d17091fd31e9e198
--
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

psabata pushed to perl-POE-Component-Client-DNS (f22). "1.054 bump, Net::DNS 1.03 compatibility release (..more)"

[notifications]

From a5d6cc846b7e2904bb0646a73225b87513ddd20f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20=C5=A0abata?= 
Date: Fri, 13 Nov 2015 12:31:20 +0100
Subject: 1.054 bump, Net::DNS 1.03 compatibility release

- Package the license text
---
 .gitignore |  1 +
 perl-POE-Component-Client-DNS.spec | 35 +--
 sources|  2 +-
 3 files changed, 23 insertions(+), 15 deletions(-)

diff --git a/.gitignore b/.gitignore
index b939c76..5170032 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,2 +1,3 @@
 POE-Component-Client-DNS-1.051.tar.gz
 /POE-Component-Client-DNS-1.053.tar.gz
+/POE-Component-Client-DNS-1.054.tar.gz
diff --git a/perl-POE-Component-Client-DNS.spec 
b/perl-POE-Component-Client-DNS.spec
index 7452c39..7e0ad1d 100644
--- a/perl-POE-Component-Client-DNS.spec
+++ b/perl-POE-Component-Client-DNS.spec
@@ -1,33 +1,36 @@
 Name:   perl-POE-Component-Client-DNS
-Version:1.053
-Release:7%{?dist}
+Version:1.054
+Release:1%{?dist}
 Summary:Non-blocking/concurrent DNS queries using Net::DNS and POE
 License:GPL+ or Artistic
 URL:http://search.cpan.org/dist/POE-Component-Client-DNS
 Source0:
http://search.cpan.org/CPAN/authors/id/R/RC/RCAPUTO/POE-Component-Client-DNS-%{version}.tar.gz
-Requires:   perl(:MODULE_COMPAT_%(eval "$(perl -V:version)"; echo 
$version))
 BuildArch:  noarch
+# Build
+BuildRequires:  coreutils
+BuildRequires:  make
 BuildRequires:  perl
+BuildRequires:  perl(ExtUtils::MakeMaker) >= 6.76
+BuildRequires:  perl(strict)
+BuildRequires:  perl(warnings)
+# Runtime
 BuildRequires:  perl(Carp)
 BuildRequires:  perl(constant)
+BuildRequires:  perl(Net::DNS) >= 0.65
+BuildRequires:  perl(POE) >= 1.294
+BuildRequires:  perl(Socket)
+# Tests only
 BuildRequires:  perl(Data::Dumper)
-BuildRequires:  perl(ExtUtils::MakeMaker)
 %{?_with_network_tests:
 BuildRequires:  perl(lib)
 }
-BuildRequires:  perl(Net::DNS) >= 0.65
-BuildRequires:  perl(POE) >= 1.294
 BuildRequires:  perl(Scalar::Util)
-BuildRequires:  perl(Socket)
-BuildRequires:  perl(strict)
 BuildRequires:  perl(Test::More) >= 0.96
 BuildRequires:  perl(Test::NoWarnings) >= 1.02
-BuildRequires:  perl(warnings)
+Requires:   perl(:MODULE_COMPAT_%(eval "$(perl -V:version)"; echo 
$version))
 Requires:   perl(Net::DNS) >= 0.65
 Requires:   perl(POE) >= 1.294
 
-%{?perl_default_filter}
-
 %description
 POE::Component::Client::DNS provides a facility for non-blocking, concurrent
 DNS requests. Using POE, it allows other tasks to run while waiting for name
@@ -37,12 +40,11 @@ servers to respond.
 %setup -q -n POE-Component-Client-DNS-%{version}
 
 %build
-perl Makefile.PL INSTALLDIRS=vendor
+perl Makefile.PL INSTALLDIRS=vendor NO_PACKLIST=1
 make %{?_smp_mflags}
 
 %install
 make pure_install DESTDIR=%{buildroot}
-find %{buildroot} -type f -name .packlist -exec rm -f {} +
 %{_fixperms} %{buildroot}/*
 # the perldoc/pod documentation is nice, but I really found this much more
 # useful.
@@ -53,11 +55,16 @@ cp t/01_resolve.t example_resolve
 make test
 
 %files
+%license LICENSE
 %doc CHANGES README example_resolve
 %{perl_vendorlib}/*
-%{_mandir}/man3/*.3*
+%{_mandir}/man3/*
 
 %changelog
+* Fri Nov 13 2015 Petr Šabata  - 1.054-1
+- 1.054 bump, Net::DNS 1.03 compatibility release
+- Package the license text
+
 * Thu Jun 18 2015 Fedora Release Engineering  
- 1.053-7
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_23_Mass_Rebuild
 
diff --git a/sources b/sources
index 923aef5..bed6872 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-248fb8056f1b7085beb2d8f300a39e9c  POE-Component-Client-DNS-1.053.tar.gz
+8ce0200ec2fec64ead3bb3face0025a5  POE-Component-Client-DNS-1.054.tar.gz
-- 
cgit v0.11.2



http://pkgs.fedoraproject.org/cgit/perl-POE-Component-Client-DNS.git/commit/?h=f22=a5d6cc846b7e2904bb0646a73225b87513ddd20f
--
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: FedRTC.org SIP and XMPP service - help needed

[Daniel Pocock]

On 13/11/15 00:00, Jared K. Smith wrote:
> 
> On Thu, Nov 12, 2015 at 2:36 PM, Daniel Pocock  > wrote:
> 
> I've been looking at ways to expand on the fedrtc.org
>  service and would
> like to start creating a team around the service just as we did in
> Debian[1].
> 
> 
> 
> Ordinarily I'd probably be the first to encourage this, but having done
> a lot of the work to setup Fedora Talk many years ago, I'm not sure this
> is a good fit for Fedora Infrastructure.  Why?  Because with Fedora
> Talk, we saw that the service wasn't used very much, and while the
> maintenance burden on the Infra team wasn't big, it was still one more
> thing they had to worry about, and something that the didn't feed 100%
> confident in administering.  Do you have any statistics on how much the
> service is being used by Fedora contributors?
> 


I replied to those same queries on the infrastructure mailing list[1]
and I've largely copied the reply.

Some key things to remember when comparing statistics for debian.org and
fedrtc.org:
a) debian.org also has XMPP, this engages more people.  I didn't offer
XMPP on fedrtc.org because it will be inconvenient for people to move
their buddy lists to fedoraproject.org
b) debian.org runs it as an official service, it has been announced in
the newsletter and debian-devel-announce mailing list and other places
over a period of almost 2 years now.

I've also started a separate thread on the infrastructure list with an
alternative hosting solution[2]

Fedora Talk was based on Asterisk.
https://fedoraproject.org/wiki/Infrastructure/Asterisk
Asterisk has lots of great features (voicemail, queues, etc) but it is
mainly for voice, it emphasizes SIP and at the time it was also quite
bad with IPv6, TLS and NAT.  FedRTC.org is based on a SIP proxy, not
Asterisk.  SIP proxies (and XMPP servers) tend to have a much bigger
emphasis on connectivity and they also tend to have less features, so
they are easier to support.  The repro SIP proxy has exceptionally good
TLS and IPv6 support.  Asterisk is not really optimized for federation
but federation is quite easy with a SIP proxy because of the emphasis on
connectivity.

FedRTC.org also has a TURN server, this boosts success for people behind
NAT.

Times have changed too:

- WebRTC is here, millions of users have WebRTC capable browsers.  It is
not just voice, it lets you do voice and video with just a little HTML.
 Have a look at the page source behind fedrtc.org to see what I mean.
The only server-side scripting is the PHP for password creation.

- Google is deprecating their standards-based XMPP.  People wanting to
continue talking to friends who use real XMPP are looking for alternatives.

- Mobile: apps for mobile VoIP, video and messaging are everywhere.
Open source apps like Lumicall (for SIP) and Conversations (for XMPP)
are trivial to install.  I recently submitted a patch to K-9 Mail on
Android so people can reply to any email with a SIP or XMPP call
https://github.com/k9mail/k-9/pull/866
Android devices are, by their nature, optimized for making calls, so
these apps tend to work a lot more intuitively than first generation
desktop softphones.

The service itself is not just for usage by developers, there are two
other purposes it serves:

- it gives people a stable point of reference for testing any softphones
or chat applications packaged in Fedora.

- it it useful for demonstrations.  I demonstrated federated calling
between FedRTC.org and rtc.debian.org in several talks, including the
Debian and Ubuntu Community Conference (DUCC) in Milan earlier this year.

Actual stats: 26 people have tried the service so far.  In Debian, we
have had over 200 people (about 25% of developers).  FedRTC.org has not
been promoted as an official service so I think it is reasonable to
suggest usage will increase if it becomes officially supported and if
XMPP is part of it too.

Interaction with other communities is another big drawcard.  There are
various others doing it: Debian (both SIP and XMPP), GNOME (XMPP) and
FSFE (XMPP).  The Lumicall app allows anybody to create a SIP account
based on their phone number and FedRTC.org users can call Lumicall users
and vice-versa.  Both the SIP and XMPP services have been built for
secure federation.  Some developers already run their own private XMPP
servers and will be happy to talk to people who have a fedoraproject.org
XMPP address.

I understand the concern about this potentially creating extra work for
the infrastructure team.  In Debian, we didn't want the service to
become a burden on the DSA team and so we created a dedicated RTC team
to handle issues specific to the services.
https://wiki.debian.org/Teams/RTC
The DSA team only have to worry about keeping the machines running,
backups, package updates and dumping some data from LDAP into the files
we need.  The RTC team test and propose changes to the configuration
files and 

Re: FedRTC.org SIP and XMPP service - help needed

[Peter Robinson]

On Fri, Nov 13, 2015 at 8:19 AM, Daniel Pocock  wrote:
>
>
> On 13/11/15 00:00, Jared K. Smith wrote:
>>
>> On Thu, Nov 12, 2015 at 2:36 PM, Daniel Pocock > > wrote:
>>
>> I've been looking at ways to expand on the fedrtc.org
>>  service and would
>> like to start creating a team around the service just as we did in
>> Debian[1].
>>
>>
>>
>> Ordinarily I'd probably be the first to encourage this, but having done
>> a lot of the work to setup Fedora Talk many years ago, I'm not sure this
>> is a good fit for Fedora Infrastructure.  Why?  Because with Fedora
>> Talk, we saw that the service wasn't used very much, and while the
>> maintenance burden on the Infra team wasn't big, it was still one more
>> thing they had to worry about, and something that the didn't feed 100%
>> confident in administering.  Do you have any statistics on how much the
>> service is being used by Fedora contributors?
>>
>
>
> I replied to those same queries on the infrastructure mailing list[1]
> and I've largely copied the reply.



> Actual stats: 26 people have tried the service so far.  In Debian, we
> have had over 200 people (about 25% of developers).  FedRTC.org has not
> been promoted as an official service so I think it is reasonable to
> suggest usage will increase if it becomes officially supported and if
> XMPP is part of it too.

Those aren't stats. By "tried" do you mean created an account and
logged a SIP/XMPP client to the service? Or are actively use it?

In both the FedRTC and debian case how many calls are made a
day/month, what is the volume of XMPP etc? In the later case we
already use both IRC and Telegram within the community, I'm not sure
what value yet another text messaging service provides.

What happens if it was possible to delegate a DNS record(s) and
provide FAS integration and have it hosted somewhere else in the short
to medium term to see how popular it is with proper named and "buddy
lists" than can be migrated if it becomes overwhelmingly popular with
proper stats to back it up?


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

stevetraylen changed lcons's 'approveacls' permission on perl-Net-STOMP-Client (master) to 'Approved'

[notifications]

stevetraylen changed lcons's 'approveacls' permission on perl-Net-STOMP-Client 
(master) to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Net-STOMP-Client/
--
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

stevetraylen changed lcons's 'approveacls' permission on perl-Directory-Queue (f23) to 'Approved'

[notifications]

stevetraylen changed lcons's 'approveacls' permission on perl-Directory-Queue 
(f23) to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Directory-Queue/
--
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

stevetraylen changed lcons's 'approveacls' permission on perl-Directory-Queue (f21) to 'Approved'

[notifications]

stevetraylen changed lcons's 'approveacls' permission on perl-Directory-Queue 
(f21) to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Directory-Queue/
--
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

stevetraylen changed lcons's 'approveacls' permission on perl-Directory-Queue (epel7) to 'Approved'

[notifications]

stevetraylen changed lcons's 'approveacls' permission on perl-Directory-Queue 
(epel7) to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Directory-Queue/
--
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

stevetraylen changed lcons's 'approveacls' permission on perl-Directory-Queue (el6) to 'Approved'

[notifications]

stevetraylen changed lcons's 'approveacls' permission on perl-Directory-Queue 
(el6) to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Directory-Queue/
--
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

stevetraylen changed lcons's 'approveacls' permission on perl-Directory-Queue (el5) to 'Approved'

[notifications]

stevetraylen changed lcons's 'approveacls' permission on perl-Directory-Queue 
(el5) to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Directory-Queue/
--
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

stevetraylen changed lcons's 'approveacls' permission on perl-Net-STOMP-Client (el5) to 'Approved'

[notifications]

stevetraylen changed lcons's 'approveacls' permission on perl-Net-STOMP-Client 
(el5) to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Net-STOMP-Client/
--
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

stevetraylen changed lcons's 'approveacls' permission on perl-Net-STOMP-Client (f23) to 'Approved'

[notifications]

stevetraylen changed lcons's 'approveacls' permission on perl-Net-STOMP-Client 
(f23) to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Net-STOMP-Client/
--
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

stevetraylen changed lcons's 'approveacls' permission on perl-Directory-Queue (f22) to 'Approved'

[notifications]

stevetraylen changed lcons's 'approveacls' permission on perl-Directory-Queue 
(f22) to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Directory-Queue/
--
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

stevetraylen changed lcons's 'approveacls' permission on perl-Directory-Queue (master) to 'Approved'

[notifications]

stevetraylen changed lcons's 'approveacls' permission on perl-Directory-Queue 
(master) to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Directory-Queue/
--
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

stevetraylen changed lcons's 'approveacls' permission on perl-Net-STOMP-Client (f22) to 'Approved'

[notifications]

stevetraylen changed lcons's 'approveacls' permission on perl-Net-STOMP-Client 
(f22) to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Net-STOMP-Client/
--
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

stevetraylen changed lcons's 'approveacls' permission on perl-Net-STOMP-Client (f21) to 'Approved'

[notifications]

stevetraylen changed lcons's 'approveacls' permission on perl-Net-STOMP-Client 
(f21) to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Net-STOMP-Client/
--
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

stevetraylen changed lcons's 'approveacls' permission on perl-Net-STOMP-Client (epel7) to 'Approved'

[notifications]

stevetraylen changed lcons's 'approveacls' permission on perl-Net-STOMP-Client 
(epel7) to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Net-STOMP-Client/
--
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 1268513] perl-PDF-Create-1.19 is available

[bugzilla]

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



--- Comment #17 from Upstream Release Monitoring 
 ---
lucilanga's perl-PDF-Create-1.19-1.fc24 completed
http://koji.fedoraproject.org/koji/buildinfo?buildID=699061

-- 
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 1281631] perl-GraphViz-2.19 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-GraphViz-2.19-1.fc24
 Resolution|--- |RAWHIDE
Last Closed||2015-11-13 03:51:09



-- 
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: Retire a package from Fedora i686 (not x86_64)

[Reindl Harald]

Am 12.11.2015 um 21:49 schrieb Przemek Klosowski:

On the other hand, Harald, I have to say that in this case my irony
detector bent the needle. You often voice your displeasure in this forum
that some setup you used for years was broken by new stuff, and yet you say

you CAN NOT HAVE both - leading edge software and legacy support forever


I just see this quoted back at you in the future :)


it's a difference replacing working software with some 
alpha/beta-quality stuff lacking half of the features and waiting years 
to get useable as before or just drop the support for hardware older 
than 10 years for the sake of use capabilities of more recent one




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

stevetraylen changed lcons's 'approveacls' permission on perl-Net-STOMP-Client (f21) to 'Approved'

[notifications]

stevetraylen changed lcons's 'approveacls' permission on perl-Net-STOMP-Client 
(f21) to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Net-STOMP-Client/
--
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

stevetraylen changed lcons's 'approveacls' permission on perl-Net-STOMP-Client (f22) to 'Approved'

[notifications]

stevetraylen changed lcons's 'approveacls' permission on perl-Net-STOMP-Client 
(f22) to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Net-STOMP-Client/
--
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

stevetraylen changed lcons's 'approveacls' permission on perl-Directory-Queue (f22) to 'Approved'

[notifications]

stevetraylen changed lcons's 'approveacls' permission on perl-Directory-Queue 
(f22) to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Directory-Queue/
--
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

stevetraylen changed lcons's 'approveacls' permission on perl-Directory-Queue (f21) to 'Approved'

[notifications]

stevetraylen changed lcons's 'approveacls' permission on perl-Directory-Queue 
(f21) to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Directory-Queue/
--
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

stevetraylen changed lcons's 'approveacls' permission on perl-Net-STOMP-Client (epel7) to 'Approved'

[notifications]

stevetraylen changed lcons's 'approveacls' permission on perl-Net-STOMP-Client 
(epel7) to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Net-STOMP-Client/
--
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

stevetraylen changed lcons's 'approveacls' permission on perl-Directory-Queue (master) to 'Approved'

[notifications]

stevetraylen changed lcons's 'approveacls' permission on perl-Directory-Queue 
(master) to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Directory-Queue/
--
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

stevetraylen changed lcons's 'approveacls' permission on perl-Net-STOMP-Client (el6) to 'Approved'

[notifications]

stevetraylen changed lcons's 'approveacls' permission on perl-Net-STOMP-Client 
(el6) to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Net-STOMP-Client/
--
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

stevetraylen changed lcons's 'approveacls' permission on perl-Net-STOMP-Client (f23) to 'Approved'

[notifications]

stevetraylen changed lcons's 'approveacls' permission on perl-Net-STOMP-Client 
(f23) to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Net-STOMP-Client/
--
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

stevetraylen changed lcons's 'approveacls' permission on perl-Net-STOMP-Client (master) to 'Approved'

[notifications]

stevetraylen changed lcons's 'approveacls' permission on perl-Net-STOMP-Client 
(master) to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Net-STOMP-Client/
--
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

stevetraylen changed lcons's 'approveacls' permission on perl-Net-STOMP-Client (el5) to 'Approved'

[notifications]

stevetraylen changed lcons's 'approveacls' permission on perl-Net-STOMP-Client 
(el5) to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Net-STOMP-Client/
--
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

stevetraylen changed lcons's 'approveacls' permission on perl-Directory-Queue (f23) to 'Approved'

[notifications]

stevetraylen changed lcons's 'approveacls' permission on perl-Directory-Queue 
(f23) to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Directory-Queue/
--
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

stevetraylen changed lcons's 'approveacls' permission on perl-Directory-Queue (epel7) to 'Approved'

[notifications]

stevetraylen changed lcons's 'approveacls' permission on perl-Directory-Queue 
(epel7) to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Directory-Queue/
--
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

stevetraylen changed lcons's 'approveacls' permission on perl-Directory-Queue (el6) to 'Approved'

[notifications]

stevetraylen changed lcons's 'approveacls' permission on perl-Directory-Queue 
(el6) to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Directory-Queue/
--
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

stevetraylen changed lcons's 'approveacls' permission on perl-Directory-Queue (el5) to 'Approved'

[notifications]

stevetraylen changed lcons's 'approveacls' permission on perl-Directory-Queue 
(el5) to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Directory-Queue/
--
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

psabata set the monitor flag of perl-POE-Component-Client-DNS to nobuild

[notifications]

psabata set the monitor flag of perl-POE-Component-Client-DNS to nobuild

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

jplesnik pushed to perl-GraphViz (master). "2.19 bump"

[notifications]

From 336c70f2e285e095bb9d7808abae0f4ced29bec6 Mon Sep 17 00:00:00 2001
From: Jitka Plesnikova 
Date: Fri, 13 Nov 2015 09:35:20 +0100
Subject: 2.19 bump

---
 .gitignore |  1 +
 perl-GraphViz.spec | 14 +++---
 sources|  2 +-
 3 files changed, 13 insertions(+), 4 deletions(-)

diff --git a/.gitignore b/.gitignore
index ae21461..9edd96a 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,3 +1,4 @@
 /GraphViz-2.14.tgz
 /GraphViz-2.16.tgz
 /GraphViz-2.18.tgz
+/GraphViz-2.19.tgz
diff --git a/perl-GraphViz.spec b/perl-GraphViz.spec
index b6c7643..49ab83b 100644
--- a/perl-GraphViz.spec
+++ b/perl-GraphViz.spec
@@ -1,6 +1,6 @@
 Name:   perl-GraphViz
-Version:2.18
-Release:3%{?dist}
+Version:2.19
+Release:1%{?dist}
 Summary:Interface to the GraphViz graphing tool
 License:Artistic 2.0
 Group:  Development/Libraries
@@ -10,6 +10,10 @@ BuildArch:  noarch
 
 BuildRequires:  graphviz-devel
 
+BuildRequires:  coreutils
+BuildRequires:  findutils
+BuildRequires:  make
+BuildRequires:  perl
 BuildRequires:  perl(Carp) >= 1.01
 BuildRequires:  perl(Config)
 BuildRequires:  perl(ExtUtils::MakeMaker)
@@ -29,8 +33,9 @@ BuildRequires:  perl(vars)
 BuildRequires:  perl(warnings)
 BuildRequires:  perl(XML::Twig) >= 3.38
 BuildRequires:  perl(XML::XPath) >= 1.13
+BuildRequires:  sed
 # optional test
-BuildRequires:  perl(Test::Pod) >= 1.45
+BuildRequires:  perl(Test::Pod) >= 1.48
 
 # not autodetected
 Requires:   graphviz
@@ -71,6 +76,9 @@ make test
 %{_mandir}/man3/*
 
 %changelog
+* Fri Nov 13 2015 Jitka Plesnikova  - 2.19-1
+- 2.19 bump
+
 * Thu Jun 18 2015 Fedora Release Engineering  
- 2.18-3
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_23_Mass_Rebuild
 
diff --git a/sources b/sources
index 8be93ea..2f4be81 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-cd507325c0bbfcc168a034abaf60a12b  GraphViz-2.18.tgz
+a394f6a0366e6561af45b4c2d00688df  GraphViz-2.19.tgz
-- 
cgit v0.11.2



http://pkgs.fedoraproject.org/cgit/perl-GraphViz.git/commit/?h=master=336c70f2e285e095bb9d7808abae0f4ced29bec6
--
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

lucilanga pushed to perl-PDF-Create (master). "update to latest upstream release"

[notifications]

From efa92f99802decc312980b7722e5857d9a1ed877 Mon Sep 17 00:00:00 2001
From: Lucian Langa 
Date: Fri, 13 Nov 2015 10:12:52 +0100
Subject: update to latest upstream release

---
 .gitignore   |  1 +
 LICENSE  |  8 
 perl-PDF-Create.spec | 13 -
 sources  |  2 +-
 4 files changed, 10 insertions(+), 14 deletions(-)
 delete mode 100644 LICENSE

diff --git a/.gitignore b/.gitignore
index 7f969e5..e381451 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,2 +1,3 @@
 PDF-Create-1.04.tar.gz
 /PDF-Create-1.10.tar.gz
+/PDF-Create-1.19.tar.gz
diff --git a/LICENSE b/LICENSE
deleted file mode 100644
index ab0cbd2..000
--- a/LICENSE
+++ /dev/null
@@ -1,8 +0,0 @@
-The main package does not specify a license.
-However author states this:
-
-"I had a look and have decided to use the perl license. The next
-release will have
-this set in the META.yml file."
-
-Markus Baertschi
diff --git a/perl-PDF-Create.spec b/perl-PDF-Create.spec
index db3a27b..9ff66ed 100644
--- a/perl-PDF-Create.spec
+++ b/perl-PDF-Create.spec
@@ -1,12 +1,11 @@
 Name:   perl-PDF-Create
-Version:1.10
+Version:1.19
 Release:1%{?dist}
 Summary:Create PDF files
 License:GPL+ or Artistic
 Group:  Development/Libraries
 URL:http://search.cpan.org/dist/PDF-Create/
-Source0:
http://www.cpan.org/authors/id/S/SZ/SZABGAB/PDF-Create-%{version}.tar.gz
-Source1:LICENSE
+Source0:
http://www.cpan.org/authors/id/M/MA/MANWAR/PDF-Create-%{version}.tar.gz
 BuildArch:  noarch
 BuildRequires:  perl(ExtUtils::MakeMaker)
 BuildRequires:  perl(Carp)
@@ -40,7 +39,6 @@ make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT
 
 find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
 find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2>/dev/null \;
-cp -p %{SOURCE1} %{_builddir}/PDF-Create-%{version}/
 
 %{_fixperms} $RPM_BUILD_ROOT/*
 
@@ -48,11 +46,16 @@ cp -p %{SOURCE1} %{_builddir}/PDF-Create-%{version}/
 make test
 
 %files
-%doc CHANGES pdf-logo.svg LICENSE README
+%doc Changes pdf-logo.svg README
 %{perl_vendorlib}/PDF
 %{_mandir}/man3/*.3*
 
 %changelog
+* Fri Nov 13 2015 Lucian Langa  - 1.19-1
+- misc cleanups
+- update source url
+- update to latest upstream
+
 * Sun Jun 21 2015 Lucian Langa  - 1.10-1
 - cleanup spec
 - update source url
diff --git a/sources b/sources
index e97cb90..d3a0cf4 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-83bed42d9603f1027aea180b693d680b  PDF-Create-1.10.tar.gz
+a55a9978adac7dfc878b541fdc22f32f  PDF-Create-1.19.tar.gz
-- 
cgit v0.11.2



http://pkgs.fedoraproject.org/cgit/perl-PDF-Create.git/commit/?h=master=efa92f99802decc312980b7722e5857d9a1ed877
--
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

stevetraylen changed lcons's 'approveacls' permission on perl-Net-STOMP-Client (el6) to 'Approved'

[notifications]

stevetraylen changed lcons's 'approveacls' permission on perl-Net-STOMP-Client 
(el6) to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Net-STOMP-Client/
--
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

Review swaps

[Jerry James]

Here are the next 2 steps on the long slow march to the gap HAP
package for sagemath.  Only a few left to go!  Let me know what I can
review for you in exchange for these reviews.

gap-pkg-smallsemi: https://bugzilla.redhat.com/show_bug.cgi?id=1281664
gap-pkg-semigroups: https://bugzilla.redhat.com/show_bug.cgi?id=1274568

Note that gap-pkg-semigroups BRs gap-pkg-smallsemi.  Thanks!
-- 
Jerry James
http://www.jamezone.org/
-- 
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: Building Images for Taskotron Disposable Clients

[Kamil Paral]

> My vote would be for imagefactory. In my mind, it comes down to the blob
> vs. from-scratch thing, using the same tools that releng does and the
> fact that imagefactory is completely written in python.
> 
> Whether we use the API or not is a different question, though :)

I think both tools are capable of doing what we need and the amount of required 
work will be similar. The blob argument disappears if we create and host our 
own templates. The collaboration factor is important and having some kind of 
API is also a good thing (even though I haven't seen it yet and I don't know 
what we would use it for). I don't think we will patch that too much (if we 
need to submit nontrivial patches, we're likely using a wrong tool, I don't 
think we should be spreading ourselves even thinner than we are now), so the 
implementation language is not a big deal, I think. Hosting and downloading 
might be easier with virt-builder, because it already supports querying remote 
image templates index and downloading selected files.

There is one view angle that we should consider as well, I think, which is the 
task-developer use case. For our production use case, it doesn't really matter 
how fast the compose process it or how large the disk images are. But how are 
the task developers going to use them? If they're going to download them (and 
periodically update them, even several times per week), we want the images as 
small as possible. If they're going to build them locally, we want them built 
fast and with small download sizes (the virt-builder template saves some data 
from downloading, only updates are downloaded; also there's a question whether 
we could cache the downloaded packages somehow with some of these tools). Or 
will we offer both approaches, let them pick what works best for them?

If we intended to mostly build those images on dev's computers, I'd probably 
prefer virt-builder. But my current impression is that local building will be a 
secondary option, and we'll primarily offer pre-created images for download 
(even downloading them automatically). Which makes sense, it's easier for the 
dev, and less error-prone. So in that light (assuming no one has different 
plans in mind), it doesn't really matter which technology we choose to build 
it. Image size is a factor here, though. I don't have any real numbers here, it 
would be very interesting to see the same image (same package set, same 
filesystem size) built by both tools and compare the output size (ideally even 
after running zerofree on them and compressing them). My guess is that they 
should have the same size (what would cause a difference?), but we might be 
surprised. Do we have a volunteer to test this? :)
___
qa-devel mailing list
qa-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/qa-devel

Re: Failing builds on rawhide

[Antonio Trande]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

still problems on rawhide/python3.5?

RPM build errors:
error: Bad exit status from /var/tmp/rpm-tmp.sPV9pz (%build)
Bad exit status from /var/tmp/rpm-tmp.sPV9pz (%build)
Child return code was: 1
EXCEPTION: Command failed. See logs for output.
 # bash --login -c /usr/bin/rpmbuild -bb --target x86_64 --nodeps
/builddir/build/SPECS/libsbml.spec
Traceback (most recent call last):
  File
"/usr/lib/python3.4/site-packages/mockbuild/trace_decorator.py", line
84, in trace
result = func(*args, **kw)
  File "/usr/lib/python3.4/site-packages/mockbuild/util.py", line 520,
in do
raise exception.Error("Command failed. See logs for output.\n #
%s" % (command,), child.returncode)
mockbuild.exception.Error: Command failed. See logs for output.
 # bash --login -c /usr/bin/rpmbuild -bb --target x86_64 --nodeps
/builddir/build/SPECS/libsbml.spec

https://kojipkgs.fedoraproject.org//work/tasks/9975/11819975/build.log

- -- 
Antonio Trande

mailto: sagitter 'at' fedoraproject 'dot' org
http://fedoraos.wordpress.com/
https://fedoraproject.org/wiki/User:Sagitter
GPG Key: 0x565E653C
Check on https://keys.fedoraproject.org/
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJWRfsqAAoJEF5tK7VWXmU8/sMIAL2Vn/sjloJEAX2OEk2krBkM
kKiIUCHPkbbHpyD781l3GZJicFmRwfLyMQkWj7PovTqGCHy6jMqLq/nanzSvB0Me
R9sv0zFs98pVAsNULfjwmYWE1udzgY/L0/nAbBnNgoZMnC7S6Az/s03d2NkqkiP6
2YWDdSEerQaPoMK6aQUGje9I1YEpgmoR52mRdz+SLWi69TuWDC/hP1PrH2hEtEEd
nxjibBxz56ds80WD+RZpr9GF48UmZ30SYYt7oe7lMTB+Poel4rokS/SftOSm4/Ws
HGt+XTB7RauvgEZTm/1lPJ350Sg8uMMDxyOTyKpLsg0mKKRWls53FTV9hGNnUag=
=YBOi
-END PGP 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

[EPEL-devel] Any news on alternative arch support?

[Bryan Chan]

Hello EPEL devs,

I would like to report on what we have been doing with EPEL on s390x.

At the last IRC meeting (September 4), bstinson suggested that I report
bugs for EPEL package build failures on s390x. A couple of us at IBM have
been doing that over the past couple of months, and even provided fixes for
some of the packages. The bugs are listed under this report:

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

We recently uncovered a bug in our scripts that led to false failures, so
we are re-building the packages again to try to get a more accurate success
ratio. Some package groups are not buildable right now (e.g. nodejs-*,
mongodb, etc.), as we are still porting the code upstream for those
projects. There are other build failures that we haven't gotten to yet; we
will continue our investigation, and document our findings in bugzilla.

nirik mentioned he was going to contact the Fedora s390 arch maintainer...
Was there any news on that front?

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

Re: Summary/Minutes for today's FESCo meeting (2015-11-11)

[Matthew Miller]

On Wed, Nov 11, 2015 at 01:54:32PM -0500, Adam Jackson wrote:
> * #1278 establish Fedora Bat-Signal for ultra-critical security updates
>   (ajax, 18:02:25)
>   * LINK: https://fedorahosted.org/fesco/ticket/1278   (ajax, 18:02:31)
>   * Removed from meeting agenda until ticket is updated  (ajax,
> 18:04:24)

FTR, I *did* have a talk with Sparks last week which included this.
I'll continue to follow up.

-- 
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: Python 3.5 for Fedora 23 in COPR

[Abdel G . Martínez L .]

Great work!

2015-11-13 7:52 GMT-05:00 Matej Stuchlik :

> Hey folks,
> a while ago I've created a COPR repo [0] with Python 3.5 for f23,
> I haven't had any bug reports so far, so it should be OK to use.
>
> You can install it with:
>
> $ dnf copr enable -y mstuchli/Python3.5
> $ dnf install -y python35-python3
>
> Then you can use the python3.5 and pip3.5 executables.
>
> Some more information is available at [1].
>
> Enjoy!
>
> [0] https://copr.fedoraproject.org/coprs/mstuchli/Python3.5/
> [1] http://synfo.github.io/2015/11/13/Python-3.5-in-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




-- 
*Abdel G. Martínez L.*
-- 
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: Building Images for Taskotron Disposable Clients

[Tim Flink]

On Fri, 13 Nov 2015 10:02:20 -0500 (EST)
Kamil Paral  wrote:

> > My vote would be for imagefactory. In my mind, it comes down to the
> > blob vs. from-scratch thing, using the same tools that releng does
> > and the fact that imagefactory is completely written in python.
> > 
> > Whether we use the API or not is a different question, though :)
> 
> I think both tools are capable of doing what we need and the amount
> of required work will be similar. The blob argument disappears if we
> create and host our own templates. The collaboration factor is
> important and having some kind of API is also a good thing (even
> though I haven't seen it yet and I don't know what we would use it
> for). I don't think we will patch that too much (if we need to submit
> nontrivial patches, we're likely using a wrong tool, I don't think we
> should be spreading ourselves even thinner than we are now), so the
> implementation language is not a big deal, I think.

Agreed on not spreading ourselves any thinner than we already are. From
my testing of imagefactory's api, it will need a small patch to make it
work for our needs but it's not a big patch, I've just been hoping for
some input upstream before submitting anything.

> Hosting and
> downloading might be easier with virt-builder, because it already
> supports querying remote image templates index and downloading
> selected files.

Unless we're running virt-builder on each virthost, I don't see how
this is relevent.

My thought behind using imagefactory's API was that we could build the
images in one location and each virthost would query that API, looking
for a newer image and downloading the newer image if found.

> There is one view angle that we should consider as well, I think,
> which is the task-developer use case. For our production use case, it
> doesn't really matter how fast the compose process it or how large
> the disk images are. But how are the task developers going to use
> them? If they're going to download them (and periodically update
> them, even several times per week), we want the images as small as
> possible. If they're going to build them locally, we want them built
> fast and with small download sizes (the virt-builder template saves
> some data from downloading, only updates are downloaded; also there's
> a question whether we could cache the downloaded packages somehow
> with some of these tools). Or will we offer both approaches, let them
> pick what works best for them?

I think that the bigger question here is what the process for
non-taskotron-devs will look like. For disposable client execution, are
we going to have them use base cloud images, our custom images or just
discourage disposable client execution?

There aren't so many devs and so far, they're all capable of figuring
out either way. I'm more worried about what'll happen when we start
telling folks to install libtaskotron and "go nuts".

> If we intended to mostly build those images on dev's computers, I'd
> probably prefer virt-builder. But my current impression is that local
> building will be a secondary option, and we'll primarily offer
> pre-created images for download (even downloading them
> automatically). Which makes sense, it's easier for the dev, and less
> error-prone. So in that light (assuming no one has different plans in
> mind), it doesn't really matter which technology we choose to build
> it. Image size is a factor here, though. I don't have any real
> numbers here, it would be very interesting to see the same image
> (same package set, same filesystem size) built by both tools and
> compare the output size (ideally even after running zerofree on them
> and compressing them). My guess is that they should have the same
> size (what would cause a difference?), but we might be surprised. Do
> we have a volunteer to test this? :)

I can give this a try later today - I have both tools installed on a
machine here.

Tim


pgpnn6GiXJsXR.pgp
Description: OpenPGP digital signature
___
qa-devel mailing list
qa-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/qa-devel

Re: Failing builds on rawhide

[Kalev Lember]

On 11/13/2015 04:01 PM, Antonio Trande wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Hi,
> 
> still problems on rawhide/python3.5?
> 
> RPM build errors:
> error: Bad exit status from /var/tmp/rpm-tmp.sPV9pz (%build)
> Bad exit status from /var/tmp/rpm-tmp.sPV9pz (%build)
> Child return code was: 1
> EXCEPTION: Command failed. See logs for output.
>  # bash --login -c /usr/bin/rpmbuild -bb --target x86_64 --nodeps
> /builddir/build/SPECS/libsbml.spec
> Traceback (most recent call last):
>   File
> "/usr/lib/python3.4/site-packages/mockbuild/trace_decorator.py", line
> 84, in trace
> result = func(*args, **kw)
>   File "/usr/lib/python3.4/site-packages/mockbuild/util.py", line 520,
> in do
> raise exception.Error("Command failed. See logs for output.\n #
> %s" % (command,), child.returncode)
> mockbuild.exception.Error: Command failed. See logs for output.
>  # bash --login -c /usr/bin/rpmbuild -bb --target x86_64 --nodeps
> /builddir/build/SPECS/libsbml.spec
> 
> https://kojipkgs.fedoraproject.org//work/tasks/9975/11819975/build.log

The actual error is higher up in the log file. No idea what to make of
it, but maybe it helps you figure out what's going on:

cd /builddir/build/BUILD/libSBML-5.12.0-Source/build/src/bindings/python && 
/usr/bin/python3 
/builddir/build/BUILD/libSBML-5.12.0-Source/src/bindings/python/doc-converter/rewrite_pydoc.py
 -f 
/builddir/build/BUILD/libSBML-5.12.0-Source/build/src/bindings/python/pydoc-doxygen.i
 -o 
/builddir/build/BUILD/libSBML-5.12.0-Source/build/src/bindings/python/pydoc-normal.i
 -i 
/builddir/build/BUILD/libSBML-5.12.0-Source/src/bindings/python/../../../docs/src/common-text
 -g 
/builddir/build/BUILD/libSBML-5.12.0-Source/src/bindings/python/../../../docs/src/common-graphics
Traceback (most recent call last):
  File 
"/builddir/build/BUILD/libSBML-5.12.0-Source/src/bindings/python/doc-converter/rewrite_pydoc.py",
 line 808, in 
main()
  File 
"/builddir/build/BUILD/libSBML-5.12.0-Source/src/bindings/python/doc-converter/rewrite_pydoc.py",
 line 803, in main
graphics_dir, quietly)
  File 
"/builddir/build/BUILD/libSBML-5.12.0-Source/src/bindings/python/doc-converter/rewrite_pydoc.py",
 line 275, in rewrite
return p.sub(lambda match: rewrite_each(match, include_dir, graphics_dir, 
quietly), contents)
  File 
"/builddir/build/BUILD/libSBML-5.12.0-Source/src/bindings/python/doc-converter/rewrite_pydoc.py",
 line 275, in 
return p.sub(lambda match: rewrite_each(match, include_dir, graphics_dir, 
quietly), contents)
  File 
"/builddir/build/BUILD/libSBML-5.12.0-Source/src/bindings/python/doc-converter/rewrite_pydoc.py",
 line 289, in rewrite_each
body = rewrite_one_body(body, include_dir, graphics_dir, quietly)
  File 
"/builddir/build/BUILD/libSBML-5.12.0-Source/src/bindings/python/doc-converter/rewrite_pydoc.py",
 line 317, in rewrite_one_body
body = p.sub(lambda match: rewrite_htmlinclude(match, include_dir, 
quietly), body)
  File 
"/builddir/build/BUILD/libSBML-5.12.0-Source/src/bindings/python/doc-converter/rewrite_pydoc.py",
 line 317, in 
body = p.sub(lambda match: rewrite_htmlinclude(match, include_dir, 
quietly), body)
  File 
"/builddir/build/BUILD/libSBML-5.12.0-Source/src/bindings/python/doc-converter/rewrite_pydoc.py",
 line 599, in rewrite_htmlinclude
parser = RewritePydocHTMLParser(AbstractFormatter(writer))
TypeError: __init__() takes 1 positional argument but 2 were given
src/bindings/python/CMakeFiles/binding_python_swig.dir/build.make:517: recipe 
for target 'src/bindings/python/libsbml_wrap.cpp' failed
make[2]: Leaving directory '/builddir/build/BUILD/libSBML-5.12.0-Source/build'
CMakeFiles/Makefile2:2933: recipe for target 
'src/bindings/python/CMakeFiles/binding_python_swig.dir/all' failed
make[2]: *** [src/bindings/python/libsbml_wrap.cpp] Error 1


-- 
Kalev
-- 
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 1281886] New: selinux causes RT to prevent httpd from starting

[bugzilla]

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

Bug ID: 1281886
   Summary: selinux causes RT to prevent httpd from starting
   Product: Fedora
   Version: 22
 Component: rt
  Assignee: rc040...@freenet.de
  Reporter: ti...@math.uh.edu
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org,
rc040...@freenet.de, ti...@math.uh.edu



This is really just a heads up, and should probably be reassigned to
selinux-policy, but I wanted to run it by you to make sure it's not an RT issue
first.

Basically, httpd updated last night, which means it restarted.  Unfortunately
this failed:

Nov 13 09:57:43 rt2.math.uh.edu httpd[23688]: AH00526: Syntax error on line 29
of /etc/httpd/conf.d/virt-rt.conf:
Nov 13 09:57:43 rt2.math.uh.edu httpd[23688]: Cannot write to
'/var/log/rt/rt.log': Permission denied at
/usr/share/perl5/vendor_perl/Log/Dispatch/File.pm line 107.\n

Line 29 is the Plack setup, which fails; there's nothing actually wrong with
the syntax of the apache configuration file.


use Plack::Handler::Apache2;
Plack::Handler::Apache2->preload("/usr/sbin/rt-server");


And it can't read /var/log/rt.log because of:

time->Fri Nov 13 03:33:30 2015
type=AVC msg=audit(1447407210.438:3285): avc:  denied  { open } for  pid=12191
comm="/usr/sbin/rt-se" path="/var/log/rt/rt.log" dev="dm-1" ino=393970
scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:var_log_t:s0
tclass=file permissive=0

setenforce 0 fixes it, of course, and after that there are no additional AVCs.

My guess is that this broke with a selinux policy update (the last one was
selinux-policy-targeted-3.13.1-128.18.fc22.noarch on October 29th) but nothing
actually failed until httpd restarted last night.

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

[Sandro Mani]

On 13.11.2015 16:09, Jerry James wrote:

Here are the next 2 steps on the long slow march to the gap HAP
package for sagemath.  Only a few left to go!  Let me know what I can
review for you in exchange for these reviews.

gap-pkg-smallsemi: https://bugzilla.redhat.com/show_bug.cgi?id=1281664
gap-pkg-semigroups: https://bugzilla.redhat.com/show_bug.cgi?id=1274568

Note that gap-pkg-semigroups BRs gap-pkg-smallsemi.  Thanks!

Hi

If you're okay with mingw packages, I'd like to have these two reviewed:

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

Both are straight forward.

Sandro

--
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: Building Images for Taskotron Disposable Clients

[Kamil Paral]

> > >  - may not run well in a VM (would need nested virt)
> > 
> > This is the same as in virt-builder, it also needs virt support.
> > Originally I thought it doesn't, but it does. It can still be used
> > without hw virt support (unlike anaconda, that would just be
> > impossible performance-wise), but it's much much much slower and I
> > don't think we would want to go that route (building an image 30
> > minutes instead of 3 minutes).
> 
> It sounds like we're going to need a bare metal solution either way,
> then.

I bet my old socks that we'll end up with nested virt eventually. It's not a 
years-proven technology, but it worked well for me locally, OpenQA is now 
running on it as well inside Fedora Infra, and many projects (not just ours) 
seem to gravitate towards it, because bare metal is just "too much trouble"TM.
___
qa-devel mailing list
qa-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/qa-devel

Re: Review swaps

[Jerry James]

On Fri, Nov 13, 2015 at 8:18 AM, Sandro Mani  wrote:
> If you're okay with mingw packages, I'd like to have these two reviewed:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1265853
> https://bugzilla.redhat.com/show_bug.cgi?id=1265854
>
> Both are straight forward.

Sure, will do.  Thanks, Sandro!
-- 
Jerry James
http://www.jamezone.org/
-- 
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: FedRTC.org SIP and XMPP service - help needed

[Michael Catanzaro]

On Fri, Nov 13, 2015 at 1:20 AM, Peter Robinson  wrote:
> In both the FedRTC and debian case how many calls are made a
> day/month, what is the volume of XMPP etc? In the later case we
> already use both IRC and Telegram within the community, I'm not sure
> what value yet another text messaging service provides.

Well we could use this to replace our IRC meetings. We could finish
meetings much faster over SIP than with IRC. It's kind of primitive
that we don't have a good way to do voice and video calls right now.
At least I've never used Telegram, or seen anyone using it; it doesn't
work with Empathy AFAIK; do we even have a GNOME Telegram client?
-- 
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: FedRTC.org SIP and XMPP service - help needed

[Josh Boyer]

On Fri, Nov 13, 2015 at 1:45 PM, Michael Catanzaro
 wrote:
> On Fri, Nov 13, 2015 at 1:20 AM, Peter Robinson  wrote:
>> In both the FedRTC and debian case how many calls are made a
>> day/month, what is the volume of XMPP etc? In the later case we
>> already use both IRC and Telegram within the community, I'm not sure
>> what value yet another text messaging service provides.
>
> Well we could use this to replace our IRC meetings. We could finish
> meetings much faster over SIP than with IRC. It's kind of primitive
> that we don't have a good way to do voice and video calls right now.

We don't do IRC because of lack of voice or video.  We do IRC because
it scales to whomever wants to participate.  Doing Fedora meetings in
voice or video introduces limitations in the number of concurrent
attendees, both as participants and lurkers.  It also enforces some
amount of order to the meeting itself.  IRC also makes it extremely
easy to provide exact logs of the discussions in addition to the
minutes.

So if we are going to replace that with voice/video, we need to make
sure it scales to a very large number of people, we have someone doing
their best to transcribe things, and we have recording capabilities so
people can replay it if they cannot attend.

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: FedRTC.org SIP and XMPP service - help needed

[Daniel Pocock]

On 13/11/15 19:45, Michael Catanzaro wrote:
> On Fri, Nov 13, 2015 at 1:20 AM, Peter Robinson  wrote:
>> In both the FedRTC and debian case how many calls are made a
>> day/month, what is the volume of XMPP etc? In the later case we
>> already use both IRC and Telegram within the community, I'm not sure
>> what value yet another text messaging service provides.
> 
> Well we could use this to replace our IRC meetings. We could finish
> meetings much faster over SIP than with IRC. It's kind of primitive
> that we don't have a good way to do voice and video calls right now.
> At least I've never used Telegram, or seen anyone using it; it doesn't
> work with Empathy AFAIK; do we even have a GNOME Telegram client?
> 


Telegram is coming to Telepathy/Empathy:

https://akulichalexandr.wordpress.com/2015/03/24/telegram-connection-manager-the-first-release-is-going-on/

https://github.com/TelepathyQt/telepathy-morse

but Telegram is not based on an open server.  The server is proprietary.
 Although they promise that messages are encrypted, they do have
metadata, so they know who you know and when you contacted somebody,
those details alone can be quite valuable for a range of purposes that
are not in the best interests of the user.

XMPP has MUC, a text-based alternative to IRC.  I'm not sure if there is
a compelling reason to change from IRC though.

There are certain situations where voice and video are useful though,
for example, making training presentations, interviewing GSoC students
or demonstrating how well Fedora does multimedia.

Regards,

Daniel
-- 
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 1281294] Upgrade perl-Directory-Queue to 1.9

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #4 from Fedora Update System  ---
perl-Directory-Queue-1.9-1.el6 has been pushed to the Fedora EPEL 6 testing
repository. If problems still persist, please make note of it in this bug
report.
If you want to test the update, you can install it with
$ su -c 'yum --enablerepo=epel-testing update perl-Directory-Queue'
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-8ddd959853

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

python3 rebuild notes: python-testtools

[Jerry James]

I've been looking at some packages that failed the python 3 rebuild
and are sitting underneath some of my packages.  I had hoped to
untangle things, but it's apparent that I'm not going to be able to do
so with the amount of time I have available.  Here are some notes in
case anybody out there in Fedora land has time to take this to
completion.

The basic problem is that python-testtools is involved in multiple
cyclic dependencies.  This works:

1. Build python-extras with tests turned off.
2. Build python-traceback2, with tests turned off like python-extras does
3. Build python-linecache2, with tests turned off like python-extras does
4. Build python-testtools (there is a new version, just released today)
5. Build python-fixtures (there is a newer version, don't know what changed)

The next steps should be the following:
6. Rebuild python-extras with tests turned on
7. Rebuild python-traceback2 with tests turned on
8. Rebuild python-linecache2 with tests turned on

Unfortunately, steps 6-8 are broken, because somebody updated
python-unittest2 from version 0.8.0 to version 1.1.0 yesterday, and
python-traceback2 requires version 0.8.0.  Really requires version
0.8.0.  Try step 6.  The python *2* build fails.  I think
python-unittest2 will have to be rolled back to version 0.8.0, unless
someone wants to figure out how to update python-traceback2.

Anyway, here's hoping somebody has time to finish untangling the
situation.  If not, I'll take it up again when I can find some free
time.  Regards,
-- 
Jerry James
http://www.jamezone.org/
-- 
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: [RFC] DistGit Container Image namespacing for Layered Image Build Service

[Ralph Bean]

On Thu, Nov 12, 2015 at 03:01:49PM -0500, Ray Strode wrote:
> Hi,
> 
> On Tue, Nov 10, 2015 at 1:08 PM, Adam Miller
>  wrote:
> > If we were to go with the former rather than the latter, we would need
> > to find a way to "namespace" container images so they can be
> > determined as different. I've thought about this a lot and I worry
> > about defining a namespace by some alphanumberic sequence because I
> > just know that at some point there will end up being a piece of
> > software in the ecosystem that we want to package as a rpm that will
> > share this pattern and result in problematic filtering. We could
> > accept that risk and simply say "this sequence is a reserved word" or
> > use a special character as the leading character in a DistGit
> > repository name to signify that it is a container.
> 
> git repositories normally use '/' to separate namespaces, so i'd propose
> 
> $ fedpkg clone containers/cockpit
> 
> and maybe add support for
> 
> $ fedpkg clone srpms/cockpit
> 
> at the same time.
> 
> This has the added benefit that cgit will automatically filter docker
> reposistories when you visit, e.g,
> 
> http://pkgs.fedoraproject.org/cgit/containers/

I like this too.  Here are three thoughts:

Perhaps, we use 'dockerfiles' for the prefix instead of 'containers',
because presumably there will be some whole new way to build
containers in 2017, and we'll need to keep our dockerfiles/ repos
separate from our awesomefiles/ repos.

We could also use this opportunity to move the kickstarts (another
input to koji builds) away from https://fedorahosted.org/spin-kickstarts
and over to dist-git as well, with a namespace like 'kickstarts/kde'
and 'kickstarts/lxde'.

The existing rpm content could be moved to a 'specfiles/' namespace
(or maybe 'srpms/'?) but we could further add some apache httpd rules that
respond with a redirect to the 'srpms/' namespace if the requests to
the base namespaceless-namespace level are met with a 404. -- "when in
doubt, default to srpms/".  That might help keep some of our existing
tools working as-is without too much catastrophe.


signature.asc
Description: PGP 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

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

[updates]

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
 249  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-1087   
dokuwiki-0-0.24.20140929c.el7
 145  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-6813   
chicken-4.9.0.1-4.el7
  53  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-8155   
nagios-4.0.8-1.el7
  41  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-925e9374c9   
python-pymongo-3.0.3-1.el7
  17  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-234553a060   
mediawiki123-1.23.11-1.el7
  17  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-ad1b660a4d   
php-ZendFramework-1.12.16-1.el7
  12  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-dac7ed832f   
mcollective-2.8.4-1.el7
  12  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-97e247eb19   
perl-HTML-Scrubber-0.15-1.el7
  10  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-22f9be240b   
qemu-2.0.0-1.el7.6
   8  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-f5273e10c1   
rabbitmq-server-3.3.5-12.el7
   6  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-f75cdd1774   
metis-5.1.0-7.el7
   6  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-4b33ee7c84   
wildmagic5-5.13-12.el7
   6  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-d6eaf22c8d   
MUMPS-5.0.1-4.el7
   6  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-e1379fc854   
owncloud-8.0.9-1.el7
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-693544258f   
telegram-cli-1.3.1-7.20150730git2052f4.el7
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-7b2b7d02df   
quassel-0.11.1-1.el7
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-8a26d71e56   
pdns-3.4.7-1.el7
   2  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-da5a65c143   
zarafa-7.1.14-1.el7
   0  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-c399ccf199   
sundials-2.6.2-11.el7


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

atari++-1.80-1.el7
gnudos-1.8-4.el7
java-dirq-1.6-2.el7
mash-0.6.19-1.el7
p7zip-15.09-2.el7
pam-kwallet-5.4.2-1.el7
perl-Authen-Credential-1.1-1.el7
perl-Directory-Queue-1.9-1.el7
php-myclabs-deep-copy-1.5.0-1.el7
php-phpunit-PHPUnit-4.8.17-1.el7
php-theseer-autoload-1.21.0-1.el7
python-pkgwat-api-0.12-6.el7
python-taskw-1.1.0-3.el7
qmapshack-1.4.0-1.el7
routino-3.0-3.el7
rubygem-rhc-1.38.4-1.el7
sundials-2.6.2-11.el7
torrent-file-editor-0.2.1-1.el7
uwsgi-2.0.11.2-1.el7
yubico-piv-tool-1.1.1-1.el7
zabbix20-2.0.16-1.el7
zabbix22-2.2.11-1.el7

Details about builds:



 atari++-1.80-1.el7 (FEDORA-EPEL-2015-4c2e1c3377)
 Unix based emulator of the Atari eight bit computers

Update Information:

- updated to version 1.80 - http://www.xl-project.com/news.html

References:

  [ 1 ] Bug #1279847 - atari++-1.80 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1279847




 gnudos-1.8-4.el7 (FEDORA-EPEL-2015-784e87ef9d)
 The GnuDOS library for GNU/Linux

Update Information:

More bug fixes!




 java-dirq-1.6-2.el7 (FEDORA-EPEL-2015-56132bc9c4)
 Directory based queue

Update Information:

Updated to latest version from upstream.




 mash-0.6.19-1.el7 (FEDORA-EPEL-2015-4081d155ee)
 Koji buildsystem to yum repository converter

Update Information:

Use Fedora 24 key for Rawhide




 p7zip-15.09-2.el7 (FEDORA-EPEL-2015-a1e22516b0)
 Very high compression ratio file archiver

Update Information:

p7zip-15.09 is available and fix rhbz #917366

References:

  [ 1 ] Bug #917366 - create unowned directory by having a requires on 
p7zip-plugins

[Bug 1281294] Upgrade perl-Directory-Queue to 1.9

[bugzilla]

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



--- Comment #5 from Fedora Update System  ---
perl-Directory-Queue-1.9-1.el7 has been pushed to the Fedora EPEL 7 testing
repository. If problems still persist, please make note of it in this bug
report.
If you want to test the update, you can install it with
$ su -c 'yum --enablerepo=epel-testing update perl-Directory-Queue'
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-1790a8ce7c

-- 
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: [RFC] DistGit Container Image namespacing for Layered Image Build Service

[Brian C. Lane]

On Tue, Nov 10, 2015 at 12:08:25PM -0600, Adam Miller wrote:
> Hello all,
> In the Fedora 24 timeframe the Fedora Release Engineering group is
> aiming to deliver the Layered Image Build Service[0] to allow Fedora
> contributors to build containers images. In the first iteration of
> this we're targeting Docker layered image support. Part of this will
> be to allow Fedora contributors to maintain Dockerfiles much like we
> maintain rpm spec files via DistGit.

So you're talking about one docker file per package, right? Or are these
going to pull from multiple packages and have the docker container be a
different level of object? Or both?

If you're talking about a 1:1 package:docker mapping then the only thing
that makes sense to me is to have them live in the current system next
to the .spec files. Anything else will easily introduce divergence from
the rpm packages.

I also see that 'container packager' and 'rpm packager' are used in the
build service page. I don't think these should be separate roles,
everyone should be a packager. If you have one role working on container
building for a package and another who only does rpm packaging we're
going to, again, end up with things diverging.

Some things I'd suggest (given I don't know the answers to the above
questions):

1. All bits have to come from koji built rpms. No rebuilding of bits
for docker, it just installs existing bits.

2. docker files for packages live in dist-git next to the package spec
file.

3. Any meta-containers collecting using packages are also an rpm
package, following whatever naming convention gets decided on.
fedora-docker-foo would make sense to me.

4. package level docker files are maintained by the same people who maintain
the package.

-- 
Brian C. Lane | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA (PST8PDT)
-- 
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: FedRTC.org SIP and XMPP service - help needed

[Jaroslav Nahorny]

Josh Boyer  writes:

> On Fri, Nov 13, 2015 at 1:45 PM, Michael Catanzaro
>  wrote:
>> On Fri, Nov 13, 2015 at 1:20 AM, Peter Robinson  wrote:
>>> In both the FedRTC and debian case how many calls are made a
>>> day/month, what is the volume of XMPP etc? In the later case we
>>> already use both IRC and Telegram within the community, I'm not sure
>>> what value yet another text messaging service provides.
>>
>> Well we could use this to replace our IRC meetings. We could finish
>> meetings much faster over SIP than with IRC. It's kind of primitive
>> that we don't have a good way to do voice and video calls right now.
>
> We don't do IRC because of lack of voice or video.  We do IRC because
> it scales to whomever wants to participate.

+1

> Doing Fedora meetings in voice or video introduces limitations in the
> number of concurrent attendees, both as participants and lurkers.

And IRC sets much lower bandwidth requirements for users who want to
join. And works better for people with hearing disabilities

> It also enforces some amount of order to the meeting itself.  IRC also
> makes it extremely easy to provide exact logs of the discussions in
> addition to the minutes.

+1

>
> So if we are going to replace that with voice/video, we need to make
> sure it scales to a very large number of people, we have someone doing
> their best to transcribe things, and we have recording capabilities so
> people can replay it if they cannot attend.

+1

To be honest I rarely participate in Fedora IRC meetings. My thoughts
are based on 15+ years of experience with IRC, and alternative instant
communication technologies (XMPP, voice, video).

The biggest advantage of IRC for me is, you can always easily find
interesting pieces of talk by grepping logs. I wouldn't want to watch
hours of videos, to find what I'm looking for.

-- 
jaroslav
-- 
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 1281294] Upgrade perl-Directory-Queue to 1.9

[bugzilla]

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



--- Comment #6 from Fedora Update System  ---
perl-Directory-Queue-1.9-1.el5 has been pushed to the Fedora EPEL 5 testing
repository. If problems still persist, please make note of it in this bug
report.
If you want to test the update, you can install it with
$ su -c 'yum --enablerepo=epel-testing update perl-Directory-Queue'
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-e7c0689950

-- 
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: [RFC] DistGit Container Image namespacing for Layered Image Build Service

[Adam Miller]

On Fri, Nov 13, 2015 at 3:47 PM, Ralph Bean  wrote:
> On Thu, Nov 12, 2015 at 03:01:49PM -0500, Ray Strode wrote:
>> Hi,
>>
>> On Tue, Nov 10, 2015 at 1:08 PM, Adam Miller
>>  wrote:
>> > If we were to go with the former rather than the latter, we would need
>> > to find a way to "namespace" container images so they can be
>> > determined as different. I've thought about this a lot and I worry
>> > about defining a namespace by some alphanumberic sequence because I
>> > just know that at some point there will end up being a piece of
>> > software in the ecosystem that we want to package as a rpm that will
>> > share this pattern and result in problematic filtering. We could
>> > accept that risk and simply say "this sequence is a reserved word" or
>> > use a special character as the leading character in a DistGit
>> > repository name to signify that it is a container.
>>
>> git repositories normally use '/' to separate namespaces, so i'd propose
>>
>> $ fedpkg clone containers/cockpit
>>
>> and maybe add support for
>>
>> $ fedpkg clone srpms/cockpit
>>
>> at the same time.
>>
>> This has the added benefit that cgit will automatically filter docker
>> reposistories when you visit, e.g,
>>
>> http://pkgs.fedoraproject.org/cgit/containers/
>
> I like this too.  Here are three thoughts:
>
> Perhaps, we use 'dockerfiles' for the prefix instead of 'containers',
> because presumably there will be some whole new way to build
> containers in 2017, and we'll need to keep our dockerfiles/ repos
> separate from our awesomefiles/ repos.
>
> We could also use this opportunity to move the kickstarts (another
> input to koji builds) away from https://fedorahosted.org/spin-kickstarts
> and over to dist-git as well, with a namespace like 'kickstarts/kde'
> and 'kickstarts/lxde'.
>
> The existing rpm content could be moved to a 'specfiles/' namespace
> (or maybe 'srpms/'?) but we could further add some apache httpd rules that
> respond with a redirect to the 'srpms/' namespace if the requests to
> the base namespaceless-namespace level are met with a 404. -- "when in
> doubt, default to srpms/".  That might help keep some of our existing
> tools working as-is without too much catastrophe.

+1

I'm a big fan of where this is going.

Maybe we should draft a proposal around this (maybe some notes in
gobby?) and then start a new thread under a new name to generate more
general discussion around this in the context of being able to deliver
many different kinds of artifact for Fedora.Next. My only fear of
continuing this topic thread is that folks who aren't interested in
containers or docker might not be tuned in because of the subject
line.

Thoughts?

-AdamM

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

[Bug 1281978] perl-Math-BigInt-1.999710 is available

[bugzilla]

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



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

list index out of range

-- 
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 1281978] New: perl-Math-BigInt-1.999710 is available

[bugzilla]

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

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



Latest upstream release: 1.999710
Current version/release in rawhide: 1.9997.09-1.fc24
URL: http://search.cpan.org/dist/Math-BigInt/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy

More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring

Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.

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

Re: [RFC] DistGit Container Image namespacing for Layered Image Build Service

[Adam Miller]

On Fri, Nov 13, 2015 at 5:14 PM, Brian C. Lane  wrote:
> On Tue, Nov 10, 2015 at 12:08:25PM -0600, Adam Miller wrote:
>> Hello all,
>> In the Fedora 24 timeframe the Fedora Release Engineering group is
>> aiming to deliver the Layered Image Build Service[0] to allow Fedora
>> contributors to build containers images. In the first iteration of
>> this we're targeting Docker layered image support. Part of this will
>> be to allow Fedora contributors to maintain Dockerfiles much like we
>> maintain rpm spec files via DistGit.
>
> So you're talking about one docker file per package, right? Or are these
> going to pull from multiple packages and have the docker container be a
> different level of object? Or both?

Both, it's mostly at the discretion of the person attempting to
deliver something in a container. Some may be simple "I added httpd on
top of the base Fedora Docker image" and others might be "I put all of
ownCloud into a container so you can just run the whole thing with
this one command"

That being said, I'm not married to the concept. It was just the idea
going into it. If the general consensus among the community is "one
Dockerfile to one package" we could go that route.

>
> If you're talking about a 1:1 package:docker mapping then the only thing
> that makes sense to me is to have them live in the current system next
> to the .spec files. Anything else will easily introduce divergence from
> the rpm packages.

Absolutely, so far there has been the expectation that there will be
divergence because of the more "dynamic" nature of what containers
bring to the table.

>
> I also see that 'container packager' and 'rpm packager' are used in the
> build service page. I don't think these should be separate roles,
> everyone should be a packager. If you have one role working on container
> building for a package and another who only does rpm packaging we're
> going to, again, end up with things diverging.

I believe they will diverge naturally as time goes on. Also, I don' t
think everyone who has rpm packaging expertise is well versed in the
ways of Docker and vice versa.

>
> Some things I'd suggest (given I don't know the answers to the above
> questions):
>
> 1. All bits have to come from koji built rpms. No rebuilding of bits
> for docker, it just installs existing bits.

That is the plan, but configuration can take place inside the context
of the container image build process to allow for single-command
execution.

>
> 2. docker files for packages live in dist-git next to the package spec
> file.

We can, pending the agreement that's all we as a community/project use
Dockerfiles for. The original idea going in to this though is that we
could extend this to provide a more full featured solution for
services that would need more than one package. Even simple things
like httpd modules (mod_wsgi, mod_php, etc) would technically ship
more rpms than they produce in the docker image.

Also in the distant future (out of scope for the original offering),
we'd like to look at delivering multi-container apps via Nulecule[0]
specifications.

>
> 3. Any meta-containers collecting using packages are also an rpm
> package, following whatever naming convention gets decided on.
> fedora-docker-foo would make sense to me.

I'm not sure I follow what you mean here, why would something that
only comes as a Dockerfile also be a rpm?

>
> 4. package level docker files are maintained by the same people who maintain
> the package.
>

This certainly makes sense if we end up going the package:container 1:1 route.

-AdamM

[0] - https://github.com/projectatomic/nulecule

> --
> Brian C. Lane | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA 
> (PST8PDT)
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: wayland in rawhide

[Ray Strode]

hi,

> Here's one on Ironlake, with two monitors plugged in.
>
> https://bugzilla.gnome.org/show_bug.cgi?id=750610
>
> still not fixed, doesn't fall back.
Well, black screens obviously aren't good, and we should clearly fix this.

If we don't get it fixed by closer to release, than maybe it's a good
data point for switching
back to Xorg for fedora 24.  But note:

1) 3 monitor setups are somewhat more rare than one and two monitor
setups, so it's important to fix, but the impact is more limited so
the problem didn't get as much exposure as it would have otherwise.
2) the bug was reported by a developer who has reproducing hardware
and intimate domain knowledge around the functions related to the
failure (you).

I'm sure we can figure this one out after a few minutes poking at it
with the hardware.  If not you, then me, or Rui, or a hand full of
other people.

Regardless of what this bug means for Fedora 24, I don't think it
should affect what we're doing for rawhide.

--Ray
-- 
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 1281640] perl-POE-Component-Client-DNS-1.054 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #4 from Fedora Update System  ---
perl-POE-Component-Client-DNS-1.054-1.fc22 has been pushed to the Fedora 22
testing repository. If problems still persist, please make note of it in this
bug report.
If you want to test the update, you can install it with
$ su -c 'dnf --enablerepo=updates-testing update perl-POE-Component-Client-DNS'
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2015-8ae6243451

-- 
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 1281640] perl-POE-Component-Client-DNS-1.054 is available

[bugzilla]

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



--- Comment #5 from Fedora Update System  ---
perl-POE-Component-Client-DNS-1.054-1.fc23 has been pushed to the Fedora 23
testing repository. If problems still persist, please make note of it in this
bug report.
If you want to test the update, you can install it with
$ su -c 'dnf --enablerepo=updates-testing update perl-POE-Component-Client-DNS'
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2015-009978280d

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

[bugzilla]

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

Bug ID: 1281985
   Summary: perl-Test-Strict-0.33 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Test-Strict
  Keywords: FutureFeature, Triaged
  Assignee: psab...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: mmasl...@redhat.com,
perl-devel@lists.fedoraproject.org, psab...@redhat.com



Latest upstream release: 0.33
Current version/release in rawhide: 0.32-1.fc24
URL: http://search.cpan.org/dist/Test-Strict/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy

More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring

Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.

-- 
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 1281982] perl-WWW-Salesforce-0.25 is available

[bugzilla]

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



--- Comment #1 from Upstream Release Monitoring 
 ---
Created attachment 1093955
  --> https://bugzilla.redhat.com/attachment.cgi?id=1093955=edit
[patch] Update to 0.25 (#1281982)

-- 
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 1281982] New: perl-WWW-Salesforce-0.25 is available

[bugzilla]

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

Bug ID: 1281982
   Summary: perl-WWW-Salesforce-0.25 is available
   Product: Fedora
   Version: rawhide
 Component: perl-WWW-Salesforce
  Keywords: FutureFeature, Triaged
  Assignee: lkund...@v3.sk
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: fi...@andresovi.net, lkund...@v3.sk,
perl-devel@lists.fedoraproject.org, sce...@gmail.com



Latest upstream release: 0.25
Current version/release in rawhide: 0.24-1.fc24
URL: http://search.cpan.org/dist/WWW-Salesforce/

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 1281982] perl-WWW-Salesforce-0.25 is available

[bugzilla]

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



--- Comment #2 from Upstream Release Monitoring 
 ---
Scratch build completed
http://koji.fedoraproject.org/koji/taskinfo?taskID=11826136

-- 
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: Retire a package from Fedora i686 (not x86_64)

[Germano Massullo]

A clear example of the mentioned problems for Darktable 32 bit
http://redmine.darktable.org/issues/10717
-- 
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: copr - hung or out of control build .. ? resolved by itself.

[David Timms]

On 14/11/15 01:18, Miroslav Suchý wrote:
> Dne 13.11.2015 v 13:30 David Timms napsal(a):
>> Hi, I submitted an audacity build f22,23,rawhide. Usually it finishes in
>> 12-20 mins. 22/23 are done, but rawhide's been 80 minutes, so I think
>> something has gone wrong... No logs yet for it.
>>
>> https://copr.fedoraproject.org/coprs/dtimms/audacity-git/build/139224/
> 
> I see it as succeeded, so your problems are likely resolved now :)

Thanks Miroslav, it did finish in 112 mins. That was way longer than
normal, I guess the builders where under heavy load or something. Thanks
anyway.

I'm also none the wiser about the Koji build which failed. Since the
same on COPR eventually finished, I tried Koji again, and succeeded as
expected, so all good.

Dave.
-- 
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] Proposal to CANCEL: 2015-11-16 Fedora QA Meeting

[Adam Williamson]

Hi folks! I'm proposing we cancel Monday's QA meeting. We met the last
few weeks and I think pretty much knocked out all the key discussion
topics. I'm going to be out Monday morning, but if anyone has a topic
for a meeting, please just reply to this mail and anyone can pick up
and run the meeting: just follow
https://fedoraproject.org/wiki/QA:SOP_IRC_meeting_process . Thanks!
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net


___
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

lcons changed lcons's 'commit' permission on perl-Directory-Queue (el6) to 'Approved'

[notifications]

lcons changed lcons's 'commit' permission on perl-Directory-Queue (el6) to 
'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Directory-Queue/
--
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

lcons changed lcons's 'commit' permission on perl-Directory-Queue (f22) to 'Approved'

[notifications]

lcons changed lcons's 'commit' permission on perl-Directory-Queue (f22) to 
'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Directory-Queue/
--
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

lcons changed lcons's 'commit' permission on perl-Directory-Queue (f23) to 'Approved'

[notifications]

lcons changed lcons's 'commit' permission on perl-Directory-Queue (f23) to 
'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Directory-Queue/
--
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

lcons changed lcons's 'commit' permission on perl-Directory-Queue (el5) to 'Approved'

[notifications]

lcons changed lcons's 'commit' permission on perl-Directory-Queue (el5) to 
'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Directory-Queue/
--
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

lcons changed lcons's 'commit' permission on perl-Directory-Queue (epel7) to 'Approved'

[notifications]

lcons changed lcons's 'commit' permission on perl-Directory-Queue (epel7) to 
'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Directory-Queue/
--
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

lcons changed lcons's 'commit' permission on perl-Directory-Queue (f21) to 'Approved'

[notifications]

lcons changed lcons's 'commit' permission on perl-Directory-Queue (f21) to 
'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Directory-Queue/
--
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

lcons changed lcons's 'commit' permission on perl-Directory-Queue (master) to 'Approved'

[notifications]

lcons changed lcons's 'commit' permission on perl-Directory-Queue (master) to 
'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Directory-Queue/
--
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

lcons changed lcons's 'commit' permission on perl-Net-STOMP-Client (el5) to 'Approved'

[notifications]

lcons changed lcons's 'commit' permission on perl-Net-STOMP-Client (el5) to 
'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Net-STOMP-Client/
--
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

lcons changed lcons's 'commit' permission on perl-Net-STOMP-Client (f22) to 'Approved'

[notifications]

lcons changed lcons's 'commit' permission on perl-Net-STOMP-Client (f22) to 
'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Net-STOMP-Client/
--
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: F23: r8169 stopped working

[Jos Vos]

On Fri, Nov 13, 2015 at 08:02:58AM +0100, Jos Vos wrote:

> I did some further tests:
> 
> -  Also the F23 Live image works fine (with 4.2.3 kernel), no issues
>with the Ethernet, I get an immediate connection, flawless...
>And: also suspend/resume works fine there (see below).
> 
> -  F23 installed (with all updates): no Ethernet working and resume
>after suspend doesn't turn on backlight of the laptop (system is
>running fine, I can remotely login via wifi), while resuming with
>backlight works perfectly using the F23 live image.

Update: the suspend issue was solved by *removing* "nomodeset" from
the boot command line in the grub config (I compared the command lines
of the Live image and the installed version).

The Ethernet card started working when I *enabled* secure boot in the
BIOS, but it (in most cases?) stays working when I disable it again.
Confused, as I'm wondering if this can influence the Ethernet driver
or is this just a random coincidence?

-- 
--Jos Vos 
--X/OS Experts in Open Systems BV   |   Phone: +31 20 6938364
--Amsterdam, The Netherlands| Fax: +31 20 6948204
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

lcons changed lcons's 'commit' permission on perl-Net-STOMP-Client (el6) to 'Approved'

[notifications]

lcons changed lcons's 'commit' permission on perl-Net-STOMP-Client (el6) to 
'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Net-STOMP-Client/
--
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

lcons changed lcons's 'commit' permission on perl-Net-STOMP-Client (f23) to 'Approved'

[notifications]

lcons changed lcons's 'commit' permission on perl-Net-STOMP-Client (f23) to 
'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Net-STOMP-Client/
--
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

lcons changed lcons's 'commit' permission on perl-Net-STOMP-Client (f21) to 'Approved'

[notifications]

lcons changed lcons's 'commit' permission on perl-Net-STOMP-Client (f21) to 
'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Net-STOMP-Client/
--
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

lcons set the monitor flag of perl-No-Worries to nobuild

[notifications]

lcons set the monitor flag of perl-No-Worries to nobuild

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