corsepiu pushed to perl-HTML-Lint (f24). "Perl 5.24 rebuild"

[notifications]

From 6fd68083561905d5a4434f68b28f4ff633d2b9ac Mon Sep 17 00:00:00 2001
From: Jitka Plesnikova 
Date: Mon, 16 May 2016 05:14:54 +0200
Subject: Perl 5.24 rebuild

---
 perl-HTML-Lint.spec | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/perl-HTML-Lint.spec b/perl-HTML-Lint.spec
index 20b5490..93a6563 100644
--- a/perl-HTML-Lint.spec
+++ b/perl-HTML-Lint.spec
@@ -1,6 +1,6 @@
 Name:   perl-HTML-Lint
 Version:2.22
-Release:6%{?dist}
+Release:7%{?dist}
 Summary:HTML::Lint Perl module
 License:Artistic 2.0
 Group:  Development/Libraries
@@ -53,6 +53,9 @@ make test
 %{_mandir}/man3/*
 
 %changelog
+* Mon May 16 2016 Jitka Plesnikova  - 2.22-7
+- Perl 5.24 rebuild
+
 * Thu Feb 04 2016 Fedora Release Engineering  - 
2.22-6
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_24_Mass_Rebuild
 
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl-HTML-Lint.git/commit/?h=f24=6fd68083561905d5a4434f68b28f4ff633d2b9ac
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

corsepiu pushed to perl-HTML-Lint (f24). "Cleanup merger."

[notifications]

From 55c0e9102ebf112d908ffe947a30a40ff33ea014 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ralf=20Cors=C3=A9pius?= 
Date: Sat, 10 Dec 2016 07:30:15 +0100
Subject: Cleanup merger.

---
 perl-HTML-Lint.spec | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/perl-HTML-Lint.spec b/perl-HTML-Lint.spec
index 22016fb..ac5ed04 100644
--- a/perl-HTML-Lint.spec
+++ b/perl-HTML-Lint.spec
@@ -58,9 +58,6 @@ make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT
 - Update to 2.24.
 - Drop 0001-doc-tag-required-errors-are-now-sorted-by-tag-name.patch.
 
-* Mon May 16 2016 Jitka Plesnikova  - 2.22-7
-- Perl 5.24 rebuild
-
 * Thu Feb 04 2016 Fedora Release Engineering  - 
2.22-6
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_24_Mass_Rebuild
 
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl-HTML-Lint.git/commit/?h=f24=55c0e9102ebf112d908ffe947a30a40ff33ea014
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

corsepiu pushed to perl-HTML-Lint (f24). "Update to 2.24. (..more)"

[notifications]

From c7876ab37d23176a8fa4491ffc1ee00983e9a944 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ralf=20Cors=C3=A9pius?= 
Date: Sat, 10 Dec 2016 06:39:01 +0100
Subject: Update to 2.24.

- Drop 0001-doc-tag-required-errors-are-now-sorted-by-tag-name.patch.
---
 .gitignore |  2 +-
 ...equired-errors-are-now-sorted-by-tag-name.patch | 46 --
 perl-HTML-Lint.spec| 18 +
 sources|  2 +-
 4 files changed, 13 insertions(+), 55 deletions(-)
 delete mode 100644 
0001-doc-tag-required-errors-are-now-sorted-by-tag-name.patch

diff --git a/.gitignore b/.gitignore
index 18ef76d..926547c 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1 @@
-/HTML-Lint-2.22.tar.gz
+/HTML-Lint-2.24.tar.gz
diff --git a/0001-doc-tag-required-errors-are-now-sorted-by-tag-name.patch 
b/0001-doc-tag-required-errors-are-now-sorted-by-tag-name.patch
deleted file mode 100644
index 7f35291..000
--- a/0001-doc-tag-required-errors-are-now-sorted-by-tag-name.patch
+++ /dev/null
@@ -1,46 +0,0 @@
-From 503ad38530d6796fbef6fe74dd20d07b98e4143b Mon Sep 17 00:00:00 2001
-From: Andy Lester 
-Date: Tue, 7 Apr 2015 09:57:09 -0500
-Subject: [PATCH] doc-tag-required errors are now sorted by tag name.
-

- Changes | 9 +
- lib/HTML/Lint/Parser.pm | 2 +-
- 2 files changed, 10 insertions(+), 1 deletion(-)
-
-diff --git a/Changes b/Changes
-index 01f254c..3093c8a 100644
 a/Changes
-+++ b/Changes
-@@ -6,6 +6,15 @@ NOTE: All bugs and requests are now being handled through 
GitHub.
- 
- Please DO NOT send bug reports to http://rt.cpan.org/.
- 
-+NEXT
-+
-+[FIXES]
-+Errors of the type doc-tag-required did not come out in any defined
-+order.  They are now sorted by tag name.  This was discovered
-+because hash randomization caused tests to fail on Perl 5.18 and
-+above. Thanks, Slaven Rezic and Andrew Main.
-+
-+
- 2.22Mon Apr  6 15:47:11 CDT 2015
- [CHANGES THAT COULD BREAK YOUR CODE]
- Previously, html_ok() would not check the entire structure of a web
-diff --git a/lib/HTML/Lint/Parser.pm b/lib/HTML/Lint/Parser.pm
-index aa1e337..5c60915 100644
 a/lib/HTML/Lint/Parser.pm
-+++ b/lib/HTML/Lint/Parser.pm
-@@ -102,7 +102,7 @@ sub _start_document {
- sub _end_document {
- my ($self,$line,$column) = @_;
- 
--for my $tag ( keys %isRequired ) {
-+for my $tag ( sort keys %isRequired ) {
- if ( !$self->{_first_seen}->{$tag} ) {
- $self->gripe( 'doc-tag-required', tag => $tag );
- }
--- 
-2.1.0
-
diff --git a/perl-HTML-Lint.spec b/perl-HTML-Lint.spec
index 3da0912..22016fb 100644
--- a/perl-HTML-Lint.spec
+++ b/perl-HTML-Lint.spec
@@ -1,15 +1,16 @@
 Name:   perl-HTML-Lint
-Version:2.22
-Release:7%{?dist}
+Version:2.24
+Release:1%{?dist}
 Summary:HTML::Lint Perl module
 License:Artistic 2.0
 Group:  Development/Libraries
 URL:http://search.cpan.org/dist/HTML-Lint/
 Source0:
http://www.cpan.org/authors/id/P/PE/PETDANCE/HTML-Lint-%{version}.tar.gz
-# https://github.com/petdance/html-lint/commit/f5115c7
-Patch0: 0001-doc-tag-required-errors-are-now-sorted-by-tag-name.patch
 BuildArch:  noarch
 BuildRequires:  perl-generators
+BuildRequires:  %{__make}
+BuildRequires:  %{__perl}
+
 BuildRequires:  perl(ExtUtils::MakeMaker)
 BuildRequires:  perl(HTML::Parser) >= 3.47
 BuildRequires:  perl(HTML::Tagset) >= 3.03
@@ -34,18 +35,17 @@ legitmacy.
 
 %prep
 %setup -q -n HTML-Lint-%{version}
-%patch0 -p1
 
 %build
 %{__perl} Makefile.PL INSTALLDIRS=vendor NO_PACKLIST=1
-make %{?_smp_mflags}
+%{__make} %{?_smp_mflags}
 
 %install
 make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT
 %{_fixperms} $RPM_BUILD_ROOT/*
 
 %check
-make test
+%{__make} test
 
 %files
 %doc Changes README
@@ -54,6 +54,10 @@ make test
 %{_mandir}/man3/*
 
 %changelog
+* Sat Dec 10 2016 Ralf Corsépius  - 2.24-1
+- Update to 2.24.
+- Drop 0001-doc-tag-required-errors-are-now-sorted-by-tag-name.patch.
+
 * Mon May 16 2016 Jitka Plesnikova  - 2.22-7
 - Perl 5.24 rebuild
 
diff --git a/sources b/sources
index 7435cc5..4646c4f 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-b04ea191d1ffbcfd798097239a0a70ee  HTML-Lint-2.22.tar.gz
+913b13b47d53b3b06c1fcbaff6ca80f2  HTML-Lint-2.24.tar.gz
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl-HTML-Lint.git/commit/?h=f24=c7876ab37d23176a8fa4491ffc1ee00983e9a944
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

corsepiu pushed to perl-HTML-Lint (f24). "Mandatory Perl build-requires added "

[notifications]

From bcdfc5f2538bf43f39065e9077e35fec49948474 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= 
Date: Fri, 24 Jun 2016 09:43:24 +0200
Subject: Mandatory Perl build-requires added
 

---
 perl-HTML-Lint.spec | 1 +
 1 file changed, 1 insertion(+)

diff --git a/perl-HTML-Lint.spec b/perl-HTML-Lint.spec
index 93a6563..3da0912 100644
--- a/perl-HTML-Lint.spec
+++ b/perl-HTML-Lint.spec
@@ -9,6 +9,7 @@ Source0:
http://www.cpan.org/authors/id/P/PE/PETDANCE/HTML-Lint-%{version
 # https://github.com/petdance/html-lint/commit/f5115c7
 Patch0: 0001-doc-tag-required-errors-are-now-sorted-by-tag-name.patch
 BuildArch:  noarch
+BuildRequires:  perl-generators
 BuildRequires:  perl(ExtUtils::MakeMaker)
 BuildRequires:  perl(HTML::Parser) >= 3.47
 BuildRequires:  perl(HTML::Tagset) >= 3.03
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl-HTML-Lint.git/commit/?h=f24=bcdfc5f2538bf43f39065e9077e35fec49948474
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

corsepiu pushed to perl-HTML-Lint (f25). "Update to 2.24. (..more)"

[notifications]

From c7876ab37d23176a8fa4491ffc1ee00983e9a944 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ralf=20Cors=C3=A9pius?= 
Date: Sat, 10 Dec 2016 06:39:01 +0100
Subject: Update to 2.24.

- Drop 0001-doc-tag-required-errors-are-now-sorted-by-tag-name.patch.
---
 .gitignore |  2 +-
 ...equired-errors-are-now-sorted-by-tag-name.patch | 46 --
 perl-HTML-Lint.spec| 18 +
 sources|  2 +-
 4 files changed, 13 insertions(+), 55 deletions(-)
 delete mode 100644 
0001-doc-tag-required-errors-are-now-sorted-by-tag-name.patch

diff --git a/.gitignore b/.gitignore
index 18ef76d..926547c 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1 @@
-/HTML-Lint-2.22.tar.gz
+/HTML-Lint-2.24.tar.gz
diff --git a/0001-doc-tag-required-errors-are-now-sorted-by-tag-name.patch 
b/0001-doc-tag-required-errors-are-now-sorted-by-tag-name.patch
deleted file mode 100644
index 7f35291..000
--- a/0001-doc-tag-required-errors-are-now-sorted-by-tag-name.patch
+++ /dev/null
@@ -1,46 +0,0 @@
-From 503ad38530d6796fbef6fe74dd20d07b98e4143b Mon Sep 17 00:00:00 2001
-From: Andy Lester 
-Date: Tue, 7 Apr 2015 09:57:09 -0500
-Subject: [PATCH] doc-tag-required errors are now sorted by tag name.
-

- Changes | 9 +
- lib/HTML/Lint/Parser.pm | 2 +-
- 2 files changed, 10 insertions(+), 1 deletion(-)
-
-diff --git a/Changes b/Changes
-index 01f254c..3093c8a 100644
 a/Changes
-+++ b/Changes
-@@ -6,6 +6,15 @@ NOTE: All bugs and requests are now being handled through 
GitHub.
- 
- Please DO NOT send bug reports to http://rt.cpan.org/.
- 
-+NEXT
-+
-+[FIXES]
-+Errors of the type doc-tag-required did not come out in any defined
-+order.  They are now sorted by tag name.  This was discovered
-+because hash randomization caused tests to fail on Perl 5.18 and
-+above. Thanks, Slaven Rezic and Andrew Main.
-+
-+
- 2.22Mon Apr  6 15:47:11 CDT 2015
- [CHANGES THAT COULD BREAK YOUR CODE]
- Previously, html_ok() would not check the entire structure of a web
-diff --git a/lib/HTML/Lint/Parser.pm b/lib/HTML/Lint/Parser.pm
-index aa1e337..5c60915 100644
 a/lib/HTML/Lint/Parser.pm
-+++ b/lib/HTML/Lint/Parser.pm
-@@ -102,7 +102,7 @@ sub _start_document {
- sub _end_document {
- my ($self,$line,$column) = @_;
- 
--for my $tag ( keys %isRequired ) {
-+for my $tag ( sort keys %isRequired ) {
- if ( !$self->{_first_seen}->{$tag} ) {
- $self->gripe( 'doc-tag-required', tag => $tag );
- }
--- 
-2.1.0
-
diff --git a/perl-HTML-Lint.spec b/perl-HTML-Lint.spec
index 3da0912..22016fb 100644
--- a/perl-HTML-Lint.spec
+++ b/perl-HTML-Lint.spec
@@ -1,15 +1,16 @@
 Name:   perl-HTML-Lint
-Version:2.22
-Release:7%{?dist}
+Version:2.24
+Release:1%{?dist}
 Summary:HTML::Lint Perl module
 License:Artistic 2.0
 Group:  Development/Libraries
 URL:http://search.cpan.org/dist/HTML-Lint/
 Source0:
http://www.cpan.org/authors/id/P/PE/PETDANCE/HTML-Lint-%{version}.tar.gz
-# https://github.com/petdance/html-lint/commit/f5115c7
-Patch0: 0001-doc-tag-required-errors-are-now-sorted-by-tag-name.patch
 BuildArch:  noarch
 BuildRequires:  perl-generators
+BuildRequires:  %{__make}
+BuildRequires:  %{__perl}
+
 BuildRequires:  perl(ExtUtils::MakeMaker)
 BuildRequires:  perl(HTML::Parser) >= 3.47
 BuildRequires:  perl(HTML::Tagset) >= 3.03
@@ -34,18 +35,17 @@ legitmacy.
 
 %prep
 %setup -q -n HTML-Lint-%{version}
-%patch0 -p1
 
 %build
 %{__perl} Makefile.PL INSTALLDIRS=vendor NO_PACKLIST=1
-make %{?_smp_mflags}
+%{__make} %{?_smp_mflags}
 
 %install
 make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT
 %{_fixperms} $RPM_BUILD_ROOT/*
 
 %check
-make test
+%{__make} test
 
 %files
 %doc Changes README
@@ -54,6 +54,10 @@ make test
 %{_mandir}/man3/*
 
 %changelog
+* Sat Dec 10 2016 Ralf Corsépius  - 2.24-1
+- Update to 2.24.
+- Drop 0001-doc-tag-required-errors-are-now-sorted-by-tag-name.patch.
+
 * Mon May 16 2016 Jitka Plesnikova  - 2.22-7
 - Perl 5.24 rebuild
 
diff --git a/sources b/sources
index 7435cc5..4646c4f 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-b04ea191d1ffbcfd798097239a0a70ee  HTML-Lint-2.22.tar.gz
+913b13b47d53b3b06c1fcbaff6ca80f2  HTML-Lint-2.24.tar.gz
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl-HTML-Lint.git/commit/?h=f25=c7876ab37d23176a8fa4491ffc1ee00983e9a944
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

corsepiu pushed to perl-HTML-Lint (master). "Update to 2.24. (..more)"

[notifications]

From c7876ab37d23176a8fa4491ffc1ee00983e9a944 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ralf=20Cors=C3=A9pius?= 
Date: Sat, 10 Dec 2016 06:39:01 +0100
Subject: Update to 2.24.

- Drop 0001-doc-tag-required-errors-are-now-sorted-by-tag-name.patch.
---
 .gitignore |  2 +-
 ...equired-errors-are-now-sorted-by-tag-name.patch | 46 --
 perl-HTML-Lint.spec| 18 +
 sources|  2 +-
 4 files changed, 13 insertions(+), 55 deletions(-)
 delete mode 100644 
0001-doc-tag-required-errors-are-now-sorted-by-tag-name.patch

diff --git a/.gitignore b/.gitignore
index 18ef76d..926547c 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1 @@
-/HTML-Lint-2.22.tar.gz
+/HTML-Lint-2.24.tar.gz
diff --git a/0001-doc-tag-required-errors-are-now-sorted-by-tag-name.patch 
b/0001-doc-tag-required-errors-are-now-sorted-by-tag-name.patch
deleted file mode 100644
index 7f35291..000
--- a/0001-doc-tag-required-errors-are-now-sorted-by-tag-name.patch
+++ /dev/null
@@ -1,46 +0,0 @@
-From 503ad38530d6796fbef6fe74dd20d07b98e4143b Mon Sep 17 00:00:00 2001
-From: Andy Lester 
-Date: Tue, 7 Apr 2015 09:57:09 -0500
-Subject: [PATCH] doc-tag-required errors are now sorted by tag name.
-

- Changes | 9 +
- lib/HTML/Lint/Parser.pm | 2 +-
- 2 files changed, 10 insertions(+), 1 deletion(-)
-
-diff --git a/Changes b/Changes
-index 01f254c..3093c8a 100644
 a/Changes
-+++ b/Changes
-@@ -6,6 +6,15 @@ NOTE: All bugs and requests are now being handled through 
GitHub.
- 
- Please DO NOT send bug reports to http://rt.cpan.org/.
- 
-+NEXT
-+
-+[FIXES]
-+Errors of the type doc-tag-required did not come out in any defined
-+order.  They are now sorted by tag name.  This was discovered
-+because hash randomization caused tests to fail on Perl 5.18 and
-+above. Thanks, Slaven Rezic and Andrew Main.
-+
-+
- 2.22Mon Apr  6 15:47:11 CDT 2015
- [CHANGES THAT COULD BREAK YOUR CODE]
- Previously, html_ok() would not check the entire structure of a web
-diff --git a/lib/HTML/Lint/Parser.pm b/lib/HTML/Lint/Parser.pm
-index aa1e337..5c60915 100644
 a/lib/HTML/Lint/Parser.pm
-+++ b/lib/HTML/Lint/Parser.pm
-@@ -102,7 +102,7 @@ sub _start_document {
- sub _end_document {
- my ($self,$line,$column) = @_;
- 
--for my $tag ( keys %isRequired ) {
-+for my $tag ( sort keys %isRequired ) {
- if ( !$self->{_first_seen}->{$tag} ) {
- $self->gripe( 'doc-tag-required', tag => $tag );
- }
--- 
-2.1.0
-
diff --git a/perl-HTML-Lint.spec b/perl-HTML-Lint.spec
index 3da0912..22016fb 100644
--- a/perl-HTML-Lint.spec
+++ b/perl-HTML-Lint.spec
@@ -1,15 +1,16 @@
 Name:   perl-HTML-Lint
-Version:2.22
-Release:7%{?dist}
+Version:2.24
+Release:1%{?dist}
 Summary:HTML::Lint Perl module
 License:Artistic 2.0
 Group:  Development/Libraries
 URL:http://search.cpan.org/dist/HTML-Lint/
 Source0:
http://www.cpan.org/authors/id/P/PE/PETDANCE/HTML-Lint-%{version}.tar.gz
-# https://github.com/petdance/html-lint/commit/f5115c7
-Patch0: 0001-doc-tag-required-errors-are-now-sorted-by-tag-name.patch
 BuildArch:  noarch
 BuildRequires:  perl-generators
+BuildRequires:  %{__make}
+BuildRequires:  %{__perl}
+
 BuildRequires:  perl(ExtUtils::MakeMaker)
 BuildRequires:  perl(HTML::Parser) >= 3.47
 BuildRequires:  perl(HTML::Tagset) >= 3.03
@@ -34,18 +35,17 @@ legitmacy.
 
 %prep
 %setup -q -n HTML-Lint-%{version}
-%patch0 -p1
 
 %build
 %{__perl} Makefile.PL INSTALLDIRS=vendor NO_PACKLIST=1
-make %{?_smp_mflags}
+%{__make} %{?_smp_mflags}
 
 %install
 make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT
 %{_fixperms} $RPM_BUILD_ROOT/*
 
 %check
-make test
+%{__make} test
 
 %files
 %doc Changes README
@@ -54,6 +54,10 @@ make test
 %{_mandir}/man3/*
 
 %changelog
+* Sat Dec 10 2016 Ralf Corsépius  - 2.24-1
+- Update to 2.24.
+- Drop 0001-doc-tag-required-errors-are-now-sorted-by-tag-name.patch.
+
 * Mon May 16 2016 Jitka Plesnikova  - 2.22-7
 - Perl 5.24 rebuild
 
diff --git a/sources b/sources
index 7435cc5..4646c4f 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-b04ea191d1ffbcfd798097239a0a70ee  HTML-Lint-2.22.tar.gz
+913b13b47d53b3b06c1fcbaff6ca80f2  HTML-Lint-2.24.tar.gz
-- 
cgit v0.12



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

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

[updates]

The following Fedora EPEL 6 Security updates need testing:
 Age  URL
 520  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-7031   
python-virtualenv-12.0.7-1.el6
 514  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-7168   
rubygem-crack-0.3.2-2.el6
 446  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-8156   
nagios-4.0.8-1.el6
 404  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-e2b4b5b2fb   
mcollective-2.8.4-1.el6
 376  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-35e240edd9   
thttpd-2.25b-24.el6
 106  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-8594ed3a53   
chicken-4.11.0-3.el6
  46  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-cb5398893b   
nodejs-0.10.48-3.el6
  15  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-2dba9625e2   
p7zip-16.02-2.el6
  12  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-4e37be4ce3   
dpkg-1.16.18-2.el6
  10  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-0018ee705f   
phpMyAdmin-4.0.10.18-1.el6
  10  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-63073e2e01   
php-php-gettext-1.0.12-1.el6
   8  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-93771e981d   
tomcat-7.0.73-1.el6
   6  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-8482adf875   
php-simplesamlphp-saml2-2.3.3-1.el6 php-simplesamlphp-saml2_1-1.10.3-1.el6
   6  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-5ddfd80ad5   
lxc-1.0.9-1.el6
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-851b04cffd   
golang-1.7.4-1.el6


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

inxi-2.3.5-1.el6
libabigail-1.0-0.8.rc6.4.el6
pcre2-10.21-10.el6
python-requestbuilder-0.7.1-1.el6
tor-0.2.8.11-1.el6
unuran-1.8.1-1.el6

Details about builds:



 inxi-2.3.5-1.el6 (FEDORA-EPEL-2016-e31192fa70)
 A full featured system information script

Update Information:

Update to 2.3.5.




 libabigail-1.0-0.8.rc6.4.el6 (FEDORA-EPEL-2016-25898c5006)
 Set of ABI analysis tools

Update Information:

Fix upstream bug - Fix aborting when reading .foo symbols from a ppc64 binary
  Fix upstream Bug 20927 - Segfault when abidiff is invoked with $HOME not
set    Fix an issue where some suppressed diff nodes are still visible in
change reports    Update to upstream 1.0.rc6 tarball    Add README

References:

  [ 1 ] Bug #1352547 - Missing pyxdg as Requires in 
libabigail-1.0-0.8.rc5.3.fc24
https://bugzilla.redhat.com/show_bug.cgi?id=1352547
  [ 2 ] Bug #19658 - None
https://bugzilla.redhat.com/show_bug.cgi?id=19658
  [ 3 ] Bug #1331348 - README file is not packaged
https://bugzilla.redhat.com/show_bug.cgi?id=1331348




 pcre2-10.21-10.el6 (FEDORA-EPEL-2016-cf4d89f5bc)
 Perl-compatible regular expression library

Update Information:

This release fixes "pcre2-config --libs-posix" output, a memory leak in
pcre2test tool, a buffer overflow in the library when partial-matching for CR-LF
in an empty buffer and a crash in pcre2test tool when diplaying wide characters.




 python-requestbuilder-0.7.1-1.el6 (FEDORA-EPEL-2016-b53cce97e8)
 Command line-driven HTTP request builder

Update Information:

This update fixes bugs in configuration file handling and commands' help output
formatting.  It also adds a NOTICE logging level.




 tor-0.2.8.11-1.el6 (FEDORA-EPEL-2016-adfd022c6a)
 Anonymizing overlay network for TCP

Update Information:

update to upstream release 0.2.8.10    update to upstream release 0.2.8.10




 unuran-1.8.1-1.el6 (FEDORA-EPEL-2016-369585bc55)
 Universal 

Re: trying to install dictd-server and...

[stevefoley12723]

CORRECTION:

There is a folder labeled "selinux" in /usr/share/doc/dict-server/ 

I seem to remember installing Fedora years and years ago and being driven crazy 
for a week trying to get apache working. I really think having a package named 
"dictd-server" should just install that package. Well, it does install the 
package, but there is no indications of how to add dictionary files so that it 
works as a service when you boot...which leads to hours of research on the web!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

corsepiu uploaded HTML-Lint-2.24.tar.gz for perl-HTML-Lint

[notifications]

913b13b47d53b3b06c1fcbaff6ca80f2  HTML-Lint-2.24.tar.gz

http://pkgs.fedoraproject.org/lookaside/pkgs/perl-HTML-Lint/HTML-Lint-2.24.tar.gz/md5/913b13b47d53b3b06c1fcbaff6ca80f2/HTML-Lint-2.24.tar.gz
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

trying to install dictd-server and...

[stevefoley12723]

Well, I must say, Fedora is not making it easy! I've used Debian for a few 
years and I really expect to install something and have it work.

But...there are selinux issues, I guess. I really don't know about 
selinux...now I'm learning a lot. There is a folder labeled "selinux" in 
/usr/share/doc/selinux but, no instructions on how to install. The INSTALL file 
doesn't mention any of this.

Now, I would suggest a better idea would to have dnf install dictd-server just 
install the thing and then have a few dict files that dnf install could also 
install...that would save me like five or so hours of work!!!

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

trying to install dictd-server and...

[stevefoley12723]

Well, I must say, Fedora is not making it easy! I've used Debian for a few 
years and I really expect to install something and have it work.

But...there are selinux issues, I guess. I really don't know about 
selinux...now I'm learning a lot. There is a folder labeled "selinux" in 
/usr/share/doc/selinux but, no instructions on how to install. The INSTALL file 
doesn't mention any of this.

Now, I would suggest a better idea would to have dnf install dictd-server just 
install the thing and then have a few dict files that dnf install could also 
install...that would save me like five or so hours of work!!!

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

[Bug 1397612] ctstream-25 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|ctstream-25-1.fc26  |ctstream-25-1.fc26
   |ctstream-25-1.fc25  |ctstream-25-1.fc25
   |ctstream-25-1.fc23  |ctstream-25-1.fc23
   |ctstream-25-1.fc24  |ctstream-25-1.fc24
   ||ctstream-25-1.el7



--- Comment #15 from Fedora Update System  ---
ctstream-25-1.el7 has been pushed to the Fedora EPEL 7 stable repository. If
problems still persist, please make note of it in this bug report.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1403038] perl-iCal-Parser-1.21 is available

[bugzilla]

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



--- Comment #7 from Fedora Update System  ---
perl-iCal-Parser-1.21-1.fc24 has been pushed to the Fedora 24 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2016-aaf3ae8ea6

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: GSequencer upstream wants to package for fedora

[Zbigniew Jędrzejewski-Szmek]

On Fri, Dec 09, 2016 at 09:57:07PM +0100, Joël Krähemann wrote:
> Hi all
> 
> Just modified the gsequencer.spec file. Now, it should be more the fedora way.
> 
> https://sourceforge.net/projects/ags/files/fedora/
> 
> Additionally, I uploaded the srpm and rpm packages built.
> 
> * gsequencer
> * gsequencer-devel
> * gsequencer-devel-docs
This should be gsequencer-doc (note no "s").

> * gsequencer-debuginfo

> > On Thu, Dec 08, 2016 at 05:13:24PM +0100, Michael Schwendt wrote:
> >> On Thu, 8 Dec 2016 15:21:21 +0100, Joël Krähemann wrote:
> >>
> >> > My name is Joël Krähemann. I maintain Advanced Gtk+ Sequencer and I'd
> >> > like to provide it in fedora. Linux is my OS of choice since 2001.
> >> > Along the time I have used many distributions like debian, linux from
> >> > scratch, SUSE, fedora and a few others.
> >>
> >> Hello!
> >>
> >> Here find some helpful links about the Fedora Packager and their processes:
> >>
> >> * https://fedoraproject.org/wiki/Join_the_package_collection_maintainers
> >> * https://fedoraproject.org/wiki/Category:Package_Maintainers
> >> * 
> >> https://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group
> >> * https://fedoraproject.org/wiki/Package_Review_Process
> >
> > In particular, you should open a Review request for gsequencer as the next
> > step.

See this last URL. It describes the steps to open a Review request.

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

[Bug 1395461] perl-PDF-Create-1.39 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #18 from Fedora Update System  ---
perl-PDF-Create-1.39-1.fc25 has been pushed to the Fedora 25 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2016-1bb63671b7

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1385016] Upgrade perl-Text-vCard to 3.08

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #2 from Fedora Update System  ---
perl-Text-vCard-3.09-1.fc25 has been pushed to the Fedora 25 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2016-ca6f1ed270

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1387455] perl-AuthCAS-1.7 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #7 from Fedora Update System  ---
perl-AuthCAS-1.7-1.fc25 has been pushed to the Fedora 25 testing repository. If
problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2016-16595c0ba3

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1403038] perl-iCal-Parser-1.21 is available

[bugzilla]

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



--- Comment #6 from Fedora Update System  ---
perl-iCal-Parser-1.21-1.fc25 has been pushed to the Fedora 25 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2016-0cc7e7d71e

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1403038] perl-iCal-Parser-1.21 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #5 from Fedora Update System  ---
perl-iCal-Parser-1.21-1.fc23 has been pushed to the Fedora 23 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2016-93431904d1

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: Some preliminary Fedora 25 stats — and future release scheduling

[Zbigniew Jędrzejewski-Szmek]

On Fri, Dec 09, 2016 at 11:29:29AM -0500, Stephen John Smoogen wrote:
> On 9 December 2016 at 07:58, Pierre-Yves Chibon  wrote:
> 
> >>
> >> No that is a separate data set.
> >
> > The title of the graph might need a little adjustment :)
> 
> Ah thanks. I have fixed the title and added a reverse stacked graph
> 
> https://smooge.fedorapeople.org/fedora-all-stacked-ma.png
> 
> https://smooge.fedorapeople.org/fedora-rev-all-stacked-ma.png

What's with the numbering: fed27, fed28, fed29?

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

[Bug 1297077] RFE: Perl6 for EPEL

[bugzilla]

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



--- Comment #7 from Todd  ---
please go to the latest version, which is 11

Thanks,
-T

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: future of official optical media support in Fedora

[Mike Pinkerton]

On 8 Dec 2016, at 11:22, Dennis Gilmore wrote:

On miércoles, 7 de diciembre de 2016 1:56:32 PM CST Mike Pinkerton  
wrote:


I use the Server netinstall image.  Use cases include loop mounting
the netinstall .iso on boxes with Grub2 -- works on remote boxes
where there is no physical access and can be easier than setting up a
remote PXE solution -- and burning a CD for local boxes without  
Grub2.
There is the pxe iso to use boot.fedoraproject.org that would  
probably better

suit your purposes.


How does that work on a remote box with no physical access, no DHCP  
and no console access?



Does anyone maintain a up-to-date list of the content differences
between the Server and Everything netinstall discs?  Is there any
difference other than in default preferences?  Is there a way to do a
single disc with a choice of "give me Server defaults" or "give me
Everything defaults"?


The server netinst iso uses the server defaults, partitioning and  
filesystem
selection. there is no way to do both with a single disk today. it  
would
require who knows what work, I imagine the work is possible its  
just not an

option today.


Aren't the server defaults just a matter of package selection?

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

Re: GSequencer upstream wants to package for fedora

[Joël Krähemann]

Hi all

For your information

http://koji.fedoraproject.org/koji/taskinfo?taskID=16809691
https://copr.fedorainfracloud.org/coprs/jkraehemann/gsequencer/

Bests,
Joël

On Fri, Dec 9, 2016 at 10:15 PM, Joël Krähemann  wrote:
> Hi Michael
>
> I'm not sure of what packaging mistakes you are talking.
> I just updated the spec file and removed the requires field.
>
> But yes, I'd like to give it for review now.
>
> Bests,
> Joël
>
>
> On Fri, Dec 9, 2016 at 10:04 PM, Michael Schwendt  wrote:
>> On Fri, 9 Dec 2016 21:57:07 +0100, Joël Krähemann wrote:
>>
>>> Hi all
>>>
>>> Just modified the gsequencer.spec file. Now, it should be more the fedora 
>>> way.
>>>
>>> https://sourceforge.net/projects/ags/files/fedora/
>>>
>>> Additionally, I uploaded the srpm and rpm packages built.
>>>
>>> * gsequencer
>>> * gsequencer-devel
>>> * gsequencer-devel-docs
>>> * gsequencer-debuginfo
>>
>> So, do you want to offer it for official package review or not?
>> It still contains a lot of packaging mistakes _not_ specific to Fedora.
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1399581] CVE-2016-1251 perl-DBD-MySQL: Use after free when using prepared statements [fedora-all]

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-DBD-MySQL-4.041-1.fc26 |perl-DBD-MySQL-4.041-1.fc26
   ||perl-DBD-MySQL-4.039-2.fc24
 Resolution|--- |ERRATA
Last Closed||2016-12-09 19:26:26



--- Comment #8 from Fedora Update System  ---
perl-DBD-MySQL-4.039-2.fc24 has been pushed to the Fedora 24 stable repository.
If problems still persist, please make note of it in this bug report.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1399580] CVE-2016-1251 perl-DBD-MySQL: Use after free when using prepared statements

[bugzilla]

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

Bug 1399581 Summary: CVE-2016-1251 perl-DBD-MySQL: Use after free when using 
prepared statements [fedora-all]
https://bugzilla.redhat.com/show_bug.cgi?id=1399581

   What|Removed |Added

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



-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 831716] Bugzilla requires perl-JSON-RPC-CGI for JSON-RPC functionality which checksetup.pl does not warn about

[bugzilla]

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



--- Comment #23 from Fedora Update System  ---
bugzilla-5.0.3-2.fc24 has been pushed to the Fedora 24 stable repository. If
problems still persist, please make note of it in this bug report.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1398309] perl-Test-Prereq-2.002 is available

[bugzilla]

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

Bug 1398690 Summary: Review Request: perl-Module-Extract-Use - Pull out the 
modules a module explicitly uses
https://bugzilla.redhat.com/show_bug.cgi?id=1398690

   What|Removed |Added

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



-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

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

[jenkins]

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

[Bug 1403404] New: perl-Moo-2.003000 is available

[bugzilla]

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

Bug ID: 1403404
   Summary: perl-Moo-2.003000 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Moo
  Keywords: FutureFeature, Triaged
  Assignee: emman...@seyman.fr
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: emman...@seyman.fr, iarn...@gmail.com,
perl-devel@lists.fedoraproject.org



Latest upstream release: 2.003000
Current version/release in rawhide: 2.002005-1.fc26
URL: http://search.cpan.org/dist/Moo/

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

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

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

Based on the information from anitya: 
https://release-monitoring.org/project/3123/

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

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

[jenkins]

See 

Changes:

[Mark Reynolds] Ticket 47662 - Better input argument validation and error 
messages for

--
Started by an SCM change
Building remotely on F23 (fedora Fedora23 Fedora fedora23) in workspace 

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

Running configure...
CFLAGS= -Wall CXXFLAGS= -Wall ./configure --with-tmpfiles-d=/etc/tmpfiles.d 
--with-openldap --enable-autobind --enable-gcc-security --with-selinux 
--with-systemdsystemunitdir=/lib/systemd/system 
--with-systemdsystemconfdir=/etc/systemd/system --enable-debug
Build log is 
https://jenkins.fedorainfracloud.org/job/389-ds-base/ws/build.1142.txt
autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal --force -I m4
autoreconf: configure.ac: tracing
autoreconf: running: libtoolize --copy --force
libtoolize: putting auxiliary files in '.'.
libtoolize: copying file './ltmain.sh'
libtoolize: putting macros in 'm4'.
libtoolize: copying file 'm4/libtool.m4'
libtoolize: copying file 'm4/ltoptions.m4'
libtoolize: copying file 'm4/ltsugar.m4'
libtoolize: copying file 'm4/ltversion.m4'
libtoolize: copying file 'm4/lt~obsolete.m4'
libtoolize: Consider adding 'AC_CONFIG_MACRO_DIRS([m4])' to configure.ac,
libtoolize: and rerunning libtoolize and aclocal.
autoreconf: running: /usr/bin/autoconf --force
autoreconf: running: /usr/bin/autoheader --force
autoreconf: running: automake --add-missing --copy --force-missing
configure.ac:29: installing './compile'
configure.ac:25: installing './config.guess'
configure.ac:25: installing './config.sub'
configure.ac:14: installing './install-sh'
configure.ac:14: installing './missing'
Makefile.am: installing './depcomp'
autoreconf: Leaving directory `.'

Running make...
Build log is 
https://jenkins.fedorainfracloud.org/job/389-ds-base/ws/build.1142.txt

Checking for warnings...
Build https://jenkins.fedorainfracloud.org/job/389-ds-base/1142/ failed
There are build warnings
Warning log is 
https://jenkins.fedorainfracloud.org/job/389-ds-base/ws/build-warns.1142.txt
Last 100 lines of warning log:

ldap/servers/plugins/memberof/memberof.c:3106:8: warning: variable ‘msg’ set 
but not used [-Wunused-but-set-variable]


Build step 'Execute shell' marked build as failure
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

[langdon]

On 12/09/2016 03:26 PM, Matthew Miller wrote:

On Fri, Dec 09, 2016 at 03:19:58PM -0500, langdon wrote:

Langdon is sitting right next to me right now and I'm going to tag him
in for more on Modularity.

[...]

them. We can also decide when a "release" makes sense based on
marketing or other considerations and just "pull the trigger" on
that day. Or we could allow users to decide for themselves by opting
in to a "rolling release" style of deployment.


This all sounds suspiciously like what I said would be the ideal. How
far from that, in the actual world, are we going to be with Modularity
when we get to, say, October 2017?

Well, I think it depends. We need a lot of community help to convert 
things to modules, integrate tests, etc. We also need factory-2 to be 
fully online (or at least mostly). We also are not completely sure how 
small we can make the "gen-core". The folks working on gen-core are 
gonna make it super small, but then modularity is gonna come and add a 
bunch of stuff that we need to make available to applications until we 
have the opportunity to repackage (e.g. if you have a lib and it is 
packaged with a command line tool, even if the lib can be parallel 
installed, the command line tool can't, so we have to re-package). 
Basically, the gen-core will be ~equivalent to a distribution that we 
are shrinking by pulling content into the applications.


So, making the "decision to release" based on marketing will likely be 
possible. The impact of that decision on users being "no biggie" will 
probably take longer. I know that is a little cryptic but the modularity 
project has always been trying to lay the groundwork in a non-disruptive 
way. So you will be able to build modules and have a disconnect from 
gen-core and app lifecycle but the gen-core will probably be big at 
first, not all apps will be modularized, many leaf apps sitting in an 
"everything else" module, etc. Over time (and it is semi-unpredictable 
length), we will get closer and closer to the ideal.


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

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

[Kevin Fenzi]

On Thu, 8 Dec 2016 12:40:49 -0500
Przemek Klosowski  wrote:

> On 12/08/2016 11:10 AM, Matthew Miller wrote:
> > It's my plan to explore different ideas to continue to make Fedora
> > more successful as measured by user and contributor growth,
> > contributor return on effort, and fulfillment of our mission.  
> Your stated goals are quite high level, so I would like to step back
> and ask some broad questions before discussing fairly detailed
> technical choices between your options.
> I do realize that rehashing the 'rolling vs. point release'
> discussion can't be made in abstract, but I always had hard time
> separating technical and psychological, marketing and organizational
> arguments in that debate. I think you as the leadership should be
> thinking it through more clearly than I'm able to.
> 
> Specifically, I think that for someone who already has a working
> Fedora installation, the point releases are a distinction without
> much difference: I think the users want a smoothly running system
> being continuously upgraded. They don't care if sometimes such update
> takes longer and changes are deeper than usual. If all goes well,
> they should always be on a usable system. As a 'reductio ad absurdum'
> exercise, far out in the future, why should anyone be excited by
> arrival of Fedora 139? We're treating the releases as precious pets,
> but they are really doomed to become cattle :)
...snip...

I just want to note here why I don't think rolling releases are great
for everyone: WIth a rolling release you have to roughly consume
changes as maintainers of your release push them to you. With a point
release system you have much more choice when to switch. 

For example, say you are a heavy user of libreoffice and have a
important class using it. You don't want to be forced to upgrade while
you are busy using the application, you would rather wait until you are
in a time of lesser activity and spent the time then to learn the new
version. 

kevin


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

Re: Summary/Minutes from today's FESCo Meeting (2016-12-09)

[Kevin Fenzi]

On Fri, 9 Dec 2016 13:19:13 -0600
Chris Adams  wrote:

> Once upon a time, Josh Boyer  said:
> > On Fri, Dec 9, 2016 at 12:20 PM, Chris Adams 
> > wrote:  
> > > Once upon a time, Adam Miller 
> > > said:  
> > >> Meeting started by maxamillion at 16:00:37 UTC. The full logs are
> > >> available at
> > >> https://meetbot.fedoraproject.org/fedora-meeting/2016-12-09/fesco.2016-12-09-16.00.log.html
> > >>   
> > >
> > > So, this is a minor request...
> > >
> > > I read email in mutt, a terminal-based mail client.  I have it
> > > configured so I can open up URLs in lynx easily.  Recently
> > > though, I can't open the agenda or logs from meetings in lynx.  I
> > > don't know when this happened (I don't try to pull them up all
> > > the time, just when I see something that interests me).
> > >
> > > Any chance this could be addressed?  
> > 
> > Um... that sounds like a bug in mutt and/or lynx?  The URLs that are
> > included are just standard URLs so there's nothing to fix from that
> > aspect.  
> 
> It's the content at the URLs, not the URL itself (sorry if I didn't
> make it clear).  The agenda URL apparently wants me to authenticate
> with OpenID, and the log URL just names the log (content in an IFRAME
> or something maybe?).
> 
> These are the URLs I am testing:
> 
> https://pagure.io/fesco/report/meeting_agenda
> https://meetbot.fedoraproject.org/fedora-meeting/2016-12-09/fesco.2016-12-09-16.00.log.html
> 
> I know web devs love to use HTML5, CSS, and scripting to do all kinds
> of fancy stuff, but a simple list of tickets and a plain text log dump
> shouldn't require anything special.

You likely want: 

https://meetbot-raw.fedoraproject.org/fedora-meeting/2016-12-09/fesco.2016-12-09-16.00.log.txt

for the second of those. It might be good if this was listed when you
go to the other url and don't have "all the scripting" things
available. 

Would you be able to file that request upstream?
( https://github.com/fedora-infra/mote/issues )

kevin


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

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

[drago01]

On Friday, December 9, 2016, Matthew Miller 
wrote:

> On Fri, Dec 09, 2016 at 03:19:58PM -0500, langdon wrote:
> > >Langdon is sitting right next to me right now and I'm going to tag him
> > >in for more on Modularity.
> [...]
> > them. We can also decide when a "release" makes sense based on
> > marketing or other considerations and just "pull the trigger" on
> > that day. Or we could allow users to decide for themselves by opting
> > in to a "rolling release" style of deployment.
>
>
> This all sounds suspiciously like what I said would be the ideal. How
> far from that, in the actual world, are we going to be with Modularity
> when we get to, say, October 2017?
>
> That does not work ... Without install media it might not be possible to
install Fedora on hardware unsupported by the last release kernel for a
long time. So not really "ideal".

> --
> Matthew Miller
> >
> Fedora Project Leader
> ___
> devel mailing list -- devel@lists.fedoraproject.org 
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

[Matthew Miller]

On Fri, Dec 09, 2016 at 10:22:44PM +, Peter Robinson wrote:
> repo data). The full list makes up most of the 40Mb downloaded. The
> dnf developers seem to think that everyone has lots of data/bandwidth
> and don't see the problem with it.

Isn't the problem that the SAT solver used by DNF for dependency
resolution doesn't know in advance if it will be needed or not, and
there isn't an easy way of adding it in midway?

-- 
Matthew Miller

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

Re: Some preliminary Fedora 25 stats — and future release scheduling

[Matthew Miller]

On Fri, Dec 09, 2016 at 04:21:27PM -0500, Stephen John Smoogen wrote:
> >> Ah thanks. I have fixed the title and added a reverse stacked graph
> >> https://smooge.fedorapeople.org/fedora-all-stacked-ma.png
> > What happened in late 2014?
> We dropped SSLv2 and SSLv3 and some TLS algorithms. This dropped a lot
> of clients who were already 'end of lifed' from checking in. [They may
> still be trying but handshake not happening etc.]

This dropped measurement Fedora 12, 13, 14, and 15 by about 95%
overnight. For whatever reason, did not affect F11 and earlier, or
later.

There's no particular reason to expect that F12-F15 do anything but
follow the very slow long tail decline we see in releases before and
after that, and so for reports where I'm showing a pretty overall
picture — or when trying to answer questions like "how many legacy
systems vs. current or recent releases"? I usually use a projected
value.

I don't have an excellent explanation for the drop we saw *this*
summer, except the observation (from another dataset) that it seems to
be mostly a drop in i686 while x86_64 is still growing.

-- 
Matthew Miller

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

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

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-Locale-Codes-3.42-1.fc |perl-Locale-Codes-3.42-1.fc
   |26  |26
   ||perl-Locale-Codes-3.42-1.fc
   ||25
 Resolution|--- |ERRATA
Last Closed||2016-12-09 17:25:49



--- Comment #6 from Fedora Update System  ---
perl-Locale-Codes-3.42-1.fc25 has been pushed to the Fedora 25 stable
repository. If problems still persist, please make note of it in this bug
report.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 831716] Bugzilla requires perl-JSON-RPC-CGI for JSON-RPC functionality which checksetup.pl does not warn about

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
 Resolution|--- |ERRATA
Last Closed|2012-07-20 22:49:34 |2016-12-09 17:25:42



--- Comment #22 from Fedora Update System  ---
bugzilla-5.0.3-3.fc25 has been pushed to the Fedora 25 stable repository. If
problems still persist, please make note of it in this bug report.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

[Peter Robinson]

>>> > problem. The fact that updates default to auto-push after +3 karma is
>>> > entirely plucked out of the air, it's just something someone made up
>>> > one day. We could *certainly* change that. I'd be quite interested in a
>>> > tweak where there's a minimum-time-in-testing value for autopush too,
>>> > which would default to say 2 days. The way that would work is automatic
>>> > push would never happen until the update had actually been in updates-
>>> > testing (not queued for push) for that long. *Manual* push could still
>>> > be done during that time, and the update submitter could make the
>>> > minimum-time-in-testing value larger or smaller (as they can make the
>>> > karma threshold for autopush greater or smaller). 2 days would just be
>>> > the default (and is similarly a number I've just made up; we could make
>>> > it something else).
>>>
>>> What if we combined this time threshold with, also, auto-pushes happen
>>> only on Monday (or whatever)?
>>
>> I wouldn't hate it. On a visceral level I've never bought the 'batched
>> updates' idea at all, but if it only affects autopushes I don't mind
>> tweaking around. It doesn't involve too much work to change, it's easy
>> to change back, and manual pushes are still available.
>
> For whatever reason I've gotten three update notifications in Gnome
> Software this week alone, and I've done the restart and install each
> time. This is Fedora 25. And then 3-4 times at separate occasions I've
> needed to add some command line items and each time dnf does a full
> fedora and updates repo metadata download of around 40MB each time,
> which is what I thought dnf-makecache.timer was supposed to do in the
> background so I'd never see and have to wait for it just to get a 53K
> program installed.

I actively disable the dnf makecache functionality and just run "dnf
--refresh" each time I need to use it as I find the makecache
functionality is just broken and pulls down vast amount of data
repeatedly.

dnf also has an issue where it pulls down all the repo data each tme,
the fullfilelist is generally not needed for pure update/package
install and yum had functionality where it would only pull that down
if and when it was explicitly needed. From memory this is only for
things like repoquery against file lists not in the usual bin
directories (the bin directory file lists are included in the standard
repo data). The full list makes up most of the 40Mb downloaded. The
dnf developers seem to think that everyone has lots of data/bandwidth
and don't see the problem with it.

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

Re: Status of microcode updates

[Peter Robinson]

On Fri, Dec 9, 2016 at 11:10 AM, Florian Weimer  wrote:
> We would like to enable hardware-assisted lock optimizations in glibc on
> multiple architectures.  In general, this feature works only on production
> hardware with current firmware, and not on pre-production machines some
> vendors provide for architecture bringup.

Have you got an overview of the required instructions/generations of
CPU architecture needed for each different architecture by chance?
From there it might be  easier to give details of where all the build
HW is at. In the case of build VMs (x86/aarch64/Power64) does this
need to be emulated by qemu/kvm or is it passed through from the host
CPU?

> Are the Fedora builders using hardware with support contracts, and are
> vendor firmware updates applied occasionally, so that we can rely on what
> the CPU/firmware reports about CPU features?  (Some vendors had to disable
> lock optimizations through firmware updates because the CPU implementation
> was buggy.)
>
> Do we at least apply microcode updates early during Linux boot on the
> builders?

Only for x86, the cpu microcode update utility is only supported on
that architecture. I believe all the other architectures apply any CPU
firmware via the OS firmware/BIOS/what ever it's called on the various
platforms.

> What about default Fedora installations?  Do they come with early boot
> microcode updates?

See the microcode_ctl package.

> If all this is covered on the Fedora side, we probably can just enable lock
> optimizations, and we do not need to implement complicated hardware
> blacklisting.

All builders run Fedora, some are physical hardware, some are VMs
running on a RHEL hypervisor. As I mentioned above what does the
virtual hardware need to support in this regard? Have you got some
upstream docs about it for the various architectures?

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

Re: Status of microcode updates

[Peter Robinson]

On Fri, Dec 9, 2016 at 3:25 PM, Stephen John Smoogen  wrote:
> On 9 December 2016 at 07:41, Josh Boyer  wrote:
>> On Fri, Dec 9, 2016 at 7:30 AM, Florian Weimer  wrote:
>>> On 12/09/2016 01:22 PM, Josh Boyer wrote:
>
>>> We can't predict the future.  But if Fedora builders use commercially
>>> supported hardware (and not pre-production samples from one of Red Hat's
>>> hardware partners), we can benefit from the efforts vendors put into fixing
>>> such issues.  Otherwise, we will have to reverse-engineer and replicate such
>>> workarounds in our own software, which is *very* difficult because vendors
>>> are traditionally very tight-lipped about such issues.
>>
>> I believe all of the builders are commercially supported hardware, or
>> the equivalent of such in case of some of the alternative
>> architectures.  If I remember correctly, on-site support and warranty
>> are two things required to get HW into the Fedora datacenter.  Again,
>> hopefully someone from Infra will confirm.
>>
>
> Builders are a combination of things and depend on the architecture.
> The information I am giving may also not be completely accurate and
> will require someone from Release Engineering to answer.
>
> 1) Virtual machines running in kvm (some Dell hardware, some cisco, some ibm?)
> 2) Dell hardware systems running Fedora 25 for x86_64/i386 builds.
> 3) IBM PPC systems which are sometimes preproduction hardware but
> running virtual images.

The IBM hardware has never, at least in my time, been pre-production
hardware. We've had at times pre-production firmware (for little
endian bootstrap) but it was production hardware it was running on.
The current hardware is production level Power 8 hardware.

> 4) Aarch64 hardware which are either production HP moonshot or
> preproduction Mustang systems

All the builders for rawhide are VMs running on production "B series"
X-gene hardware (HP Moonshot chassis).

> 5) s390 virtual systems
> 6) arm systems from a no longer around manufacturer.

And these will soon (Jan) move to virtual VMs running on the above HP hardware.

> Firmware updates depend on the manufacturer and the hardware. The
> cisco systems get updates very sporadically, the Dell boxes get every
> 6 months and the IBM do not seem to get updates anymore but are under
> hardware contract for replacements and such.
>
>
>
>
> --
> Stephen J Smoogen.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Summary/Minutes from today's FESCo Meeting (2016-12-09)

[Pierre-Yves Chibon]

On Fri, Dec 09, 2016 at 01:19:13PM -0600, Chris Adams wrote:
> Once upon a time, Josh Boyer  said:
> > On Fri, Dec 9, 2016 at 12:20 PM, Chris Adams  wrote:
> > > Once upon a time, Adam Miller  said:
> > >> Meeting started by maxamillion at 16:00:37 UTC. The full logs are
> > >> available at
> > >> https://meetbot.fedoraproject.org/fedora-meeting/2016-12-09/fesco.2016-12-09-16.00.log.html
> > >
> > > So, this is a minor request...
> > >
> > > I read email in mutt, a terminal-based mail client.  I have it
> > > configured so I can open up URLs in lynx easily.  Recently though, I
> > > can't open the agenda or logs from meetings in lynx.  I don't know when
> > > this happened (I don't try to pull them up all the time, just when I see
> > > something that interests me).
> > >
> > > Any chance this could be addressed?
> > 
> > Um... that sounds like a bug in mutt and/or lynx?  The URLs that are
> > included are just standard URLs so there's nothing to fix from that
> > aspect.
> 
> It's the content at the URLs, not the URL itself (sorry if I didn't make
> it clear).  The agenda URL apparently wants me to authenticate with
> OpenID, and the log URL just names the log (content in an IFRAME or
> something maybe?).
> 
> These are the URLs I am testing:
> 
> https://pagure.io/fesco/report/meeting_agenda

It's a one-liner but indeed, oddly enough it is asking for auth while I can't
think of a good reason it should.

Going to fix this, thanks :)


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

Re: Some preliminary Fedora 25 stats — and future release scheduling

[Stephen John Smoogen]

On 9 December 2016 at 16:06, Scott Schmit  wrote:
> On Fri, Dec 09, 2016 at 11:29:29AM -0500, Stephen John Smoogen wrote:
>> Ah thanks. I have fixed the title and added a reverse stacked graph
>>
>> https://smooge.fedorapeople.org/fedora-all-stacked-ma.png
>
> What happened in late 2014?

We dropped SSLv2 and SSLv3 and some TLS algorithms. This dropped a lot
of clients who were already 'end of lifed' from checking in. [They may
still be trying but handshake not happening etc.]



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



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

Re: GSequencer upstream wants to package for fedora

[Joël Krähemann]

Hi Michael

I'm not sure of what packaging mistakes you are talking.
I just updated the spec file and removed the requires field.

But yes, I'd like to give it for review now.

Bests,
Joël


On Fri, Dec 9, 2016 at 10:04 PM, Michael Schwendt  wrote:
> On Fri, 9 Dec 2016 21:57:07 +0100, Joël Krähemann wrote:
>
>> Hi all
>>
>> Just modified the gsequencer.spec file. Now, it should be more the fedora 
>> way.
>>
>> https://sourceforge.net/projects/ags/files/fedora/
>>
>> Additionally, I uploaded the srpm and rpm packages built.
>>
>> * gsequencer
>> * gsequencer-devel
>> * gsequencer-devel-docs
>> * gsequencer-debuginfo
>
> So, do you want to offer it for official package review or not?
> It still contains a lot of packaging mistakes _not_ specific to Fedora.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Some preliminary Fedora 25 stats — and future release scheduling

[Peter Robinson]

On 10 Dec 2016 08:06, "Scott Schmit"  wrote:

On Fri, Dec 09, 2016 at 11:29:29AM -0500, Stephen John Smoogen wrote:
> Ah thanks. I have fixed the title and added a reverse stacked graph
>
> https://smooge.fedorapeople.org/fedora-all-stacked-ma.png

What happened in late 2014?


Fedora 21 which was the first relelase post 1 year Fedora.next initiative
move to 3 editions.

P


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

Re: Some preliminary Fedora 25 stats — and future release scheduling

[Scott Schmit]

On Fri, Dec 09, 2016 at 11:29:29AM -0500, Stephen John Smoogen wrote:
> Ah thanks. I have fixed the title and added a reverse stacked graph
> 
> https://smooge.fedorapeople.org/fedora-all-stacked-ma.png

What happened in late 2014?


smime.p7s
Description: S/MIME cryptographic signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: GSequencer upstream wants to package for fedora

[Michael Schwendt]

On Fri, 9 Dec 2016 21:57:07 +0100, Joël Krähemann wrote:

> Hi all
> 
> Just modified the gsequencer.spec file. Now, it should be more the fedora way.
> 
> https://sourceforge.net/projects/ags/files/fedora/
> 
> Additionally, I uploaded the srpm and rpm packages built.
> 
> * gsequencer
> * gsequencer-devel
> * gsequencer-devel-docs
> * gsequencer-debuginfo

So, do you want to offer it for official package review or not?
It still contains a lot of packaging mistakes _not_ specific to Fedora.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: GSequencer upstream wants to package for fedora

[Joël Krähemann]

Hi all

Just modified the gsequencer.spec file. Now, it should be more the fedora way.

https://sourceforge.net/projects/ags/files/fedora/

Additionally, I uploaded the srpm and rpm packages built.

* gsequencer
* gsequencer-devel
* gsequencer-devel-docs
* gsequencer-debuginfo

Bests,
Joël


On Thu, Dec 8, 2016 at 6:30 PM, Zbigniew Jędrzejewski-Szmek
 wrote:
> On Thu, Dec 08, 2016 at 05:13:24PM +0100, Michael Schwendt wrote:
>> On Thu, 8 Dec 2016 15:21:21 +0100, Joël Krähemann wrote:
>>
>> > My name is Joël Krähemann. I maintain Advanced Gtk+ Sequencer and I'd
>> > like to provide it in fedora. Linux is my OS of choice since 2001.
>> > Along the time I have used many distributions like debian, linux from
>> > scratch, SUSE, fedora and a few others.
>>
>> Hello!
>>
>> Here find some helpful links about the Fedora Packager and their processes:
>>
>> * https://fedoraproject.org/wiki/Join_the_package_collection_maintainers
>> * https://fedoraproject.org/wiki/Category:Package_Maintainers
>> * https://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group
>> * https://fedoraproject.org/wiki/Package_Review_Process
>
> In particular, you should open a Review request for gsequencer as the next
> step.
>
> From a quick view at the spec file:
> Source0 should be a full URL
>
> '-n gsequencer' is a noop, just drop it for readability.
> Similarly, %setup -q -n %{name}-%{version} → %setup -q
> or oven just %autosetup.
>
> In %files:
> %{_libdir}/gsequencer/* → %{_libdir}/gsequencer
> (you need to "own" the directory too).
> Similarly in %{_datadir}, if you run rpmlint I'm pretty sure it'll complain
> about unowned directories.
>
> In general, it's better to put each Requires/BuildRequires item on it's own
> line. Diffs looks better and it's easier to spot mistakes.
>
> No dots at the end of Summary.
>
> Some of the explicit dependencies, e.g. Requires: libags, are most
> likely uneeded — rpm generates dependencies on libraries automatically.
>
> Also, I'm not sure you need so many subpackages: it's not Debian
> where every teeny-tiny library needs a separate subpackage. In particular,
> you can at least merge all the -devel subpackages into one.
>
> But the package looks nice in general. Should not be an issue to get
> it accepted.
>
> Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

[Adam Williamson]

On Fri, 2016-12-09 at 14:31 -0600, Michael Catanzaro wrote:
> On Fri, 2016-12-09 at 12:25 -0800, Adam Williamson wrote:
> > Software will check for new updates at most every 48 hours, so if
> > there
> > happen to *be* new updates every 48 hours and your system is running
> > the whole time, yeah, you can get 3-and-a-bit update notifications
> > per
> > week.
> 
> Not *quite* -- Software does check for updates daily (not 48 hours,
> unless this changed...?) but it notifies the user at most once per
> week, unless there is a security update, in which case it notifies
> immediately.

Oh yeah, sorry, I was forgetting the logic. You're right, it's 24
hours. I just punted the clock 48 hours to be safe (in the test where I
have to work around this behaviour...)
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

[Adam Williamson]

On Fri, 2016-12-09 at 21:29 +0100, Michael Schwendt wrote:
> Of course, the developers of bodhi would need to be convinced of such a
> feature, too, and it could be that there is no big kahuna to do exactly
> that. Oh well.

Well, no, you could just send a patch. Bodhi is a rather nice codebase
and quite easy to work on. I've had several things merged into it.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

[Michael Catanzaro]

On Fri, 2016-12-09 at 12:25 -0800, Adam Williamson wrote:
> Software will check for new updates at most every 48 hours, so if
> there
> happen to *be* new updates every 48 hours and your system is running
> the whole time, yeah, you can get 3-and-a-bit update notifications
> per
> week.

Not *quite* -- Software does check for updates daily (not 48 hours,
unless this changed...?) but it notifies the user at most once per
week, unless there is a security update, in which case it notifies
immediately.

The problem is that we have very minor security updates all the time,
and each one causes Software to present all updates to you. That really
shouldn't happen IMO; only "important" security updates should trigger
this, for some value of "important".

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

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

[Michael Schwendt]

On Fri, 09 Dec 2016 11:00:45 -0800, Adam Williamson wrote:

> > Same applies to your usage scenario. Personal experience is just that:
> > personal experience.  
> 
> Yes, but the burden of proof always lies with those who want to change
> stuff. I've got the easy job here: I just get to say 'look, if you want
> to change everything, provide some concrete evidence:
> 
> a) that there's a problem
> b) that the changes will solve it
> c) that they won't create larger problems than the ones they solve'
> 
> That's always how it works. You have to provide a justification for
> change. No justification is really needed for no-change.

Then you get to keep the pieces. Unfortunate as it may sound, but I don't
see any "burden of proof". I do not "have to provide" anything at all.
I voice my opinion, and you are free to listen _or_ ignore it.
And if you don't listen, you may as well forget about changing bodhi, too,
and enjoy updates that get marked stable by the karma threshold system
even before they have appeared on the relevant world-wide mirrors.

But hey, in another reply you've mentioned the rather old "logical AND"
solution to the problem. Karma threshold AND minimum time spent in repo.
Of course, the developers of bodhi would need to be convinced of such a
feature, too, and it could be that there is no big kahuna to do exactly
that. Oh well.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

[Matthew Miller]

On Fri, Dec 09, 2016 at 03:19:58PM -0500, langdon wrote:
> >Langdon is sitting right next to me right now and I'm going to tag him
> >in for more on Modularity.
[...]
> them. We can also decide when a "release" makes sense based on
> marketing or other considerations and just "pull the trigger" on
> that day. Or we could allow users to decide for themselves by opting
> in to a "rolling release" style of deployment.


This all sounds suspiciously like what I said would be the ideal. How
far from that, in the actual world, are we going to be with Modularity
when we get to, say, October 2017?

-- 
Matthew Miller

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

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

[Adam Williamson]

On Fri, 2016-12-09 at 13:21 -0700, Chris Murphy wrote:
> On Fri, Dec 9, 2016 at 1:12 PM, Adam Williamson
>  wrote:
> > On Fri, 2016-12-09 at 15:05 -0500, Matthew Miller wrote:
> > > On Fri, Dec 09, 2016 at 11:55:26AM -0800, Adam Williamson wrote:
> > > > problem. The fact that updates default to auto-push after +3 karma is
> > > > entirely plucked out of the air, it's just something someone made up
> > > > one day. We could *certainly* change that. I'd be quite interested in a
> > > > tweak where there's a minimum-time-in-testing value for autopush too,
> > > > which would default to say 2 days. The way that would work is automatic
> > > > push would never happen until the update had actually been in updates-
> > > > testing (not queued for push) for that long. *Manual* push could still
> > > > be done during that time, and the update submitter could make the
> > > > minimum-time-in-testing value larger or smaller (as they can make the
> > > > karma threshold for autopush greater or smaller). 2 days would just be
> > > > the default (and is similarly a number I've just made up; we could make
> > > > it something else).
> > > 
> > > What if we combined this time threshold with, also, auto-pushes happen
> > > only on Monday (or whatever)?
> > 
> > I wouldn't hate it. On a visceral level I've never bought the 'batched
> > updates' idea at all, but if it only affects autopushes I don't mind
> > tweaking around. It doesn't involve too much work to change, it's easy
> > to change back, and manual pushes are still available.
> 
> For whatever reason I've gotten three update notifications in Gnome
> Software this week alone, and I've done the restart and install each
> time. This is Fedora 25. And then 3-4 times at separate occasions I've
> needed to add some command line items and each time dnf does a full
> fedora and updates repo metadata download of around 40MB each time,
> which is what I thought dnf-makecache.timer was supposed to do in the
> background so I'd never see and have to wait for it just to get a 53K
> program installed.

GNOME Software doesn't use dnf's caches.

Software will check for new updates at most every 48 hours, so if there
happen to *be* new updates every 48 hours and your system is running
the whole time, yeah, you can get 3-and-a-bit update notifications per
week.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[389-devel] please review: Ticket 47662 - improve cli tool usage validation and errors

[Mark Reynolds]

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

https://fedorahosted.org/389/attachment/ticket/47662/0001-Ticket-47662-Better-input-argument-validation-and-er.patch
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

[Chris Murphy]

On Fri, Dec 9, 2016 at 1:12 PM, Adam Williamson
 wrote:
> On Fri, 2016-12-09 at 15:05 -0500, Matthew Miller wrote:
>> On Fri, Dec 09, 2016 at 11:55:26AM -0800, Adam Williamson wrote:
>> > problem. The fact that updates default to auto-push after +3 karma is
>> > entirely plucked out of the air, it's just something someone made up
>> > one day. We could *certainly* change that. I'd be quite interested in a
>> > tweak where there's a minimum-time-in-testing value for autopush too,
>> > which would default to say 2 days. The way that would work is automatic
>> > push would never happen until the update had actually been in updates-
>> > testing (not queued for push) for that long. *Manual* push could still
>> > be done during that time, and the update submitter could make the
>> > minimum-time-in-testing value larger or smaller (as they can make the
>> > karma threshold for autopush greater or smaller). 2 days would just be
>> > the default (and is similarly a number I've just made up; we could make
>> > it something else).
>>
>> What if we combined this time threshold with, also, auto-pushes happen
>> only on Monday (or whatever)?
>
> I wouldn't hate it. On a visceral level I've never bought the 'batched
> updates' idea at all, but if it only affects autopushes I don't mind
> tweaking around. It doesn't involve too much work to change, it's easy
> to change back, and manual pushes are still available.

For whatever reason I've gotten three update notifications in Gnome
Software this week alone, and I've done the restart and install each
time. This is Fedora 25. And then 3-4 times at separate occasions I've
needed to add some command line items and each time dnf does a full
fedora and updates repo metadata download of around 40MB each time,
which is what I thought dnf-makecache.timer was supposed to do in the
background so I'd never see and have to wait for it just to get a 53K
program installed.

So batching would be vastly preferred to what I've been experiencing
this week even though I agree that the Windows update Tuesdays model
has its own short coming; not least of which is the connotation.

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

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

[langdon]

On 12/09/2016 02:52 PM, Matthew Miller wrote:

On Fri, Dec 09, 2016 at 08:50:06AM -0800, Adam Williamson wrote:

So, *did* you feel that the F25 cycle felt compressed? If we're close
enough to the theoretical-world above that we feel like we can do, say,
four month cycles to stay on track without experiencing (particular)
pain, maybe that's okay.

This seems like an impossible question to answer. Our release cycles
are entirely arbitrary; they're precisely what we say they are. So I'm
not sure how to say whether one "feels compressed", or understand how
"four month cycles" would make us "stay on track". *What* track would
we be staying on?

Roughly Mother's Day / Halloween, and not unpredictably cycling around
the calendar. Entirely arbitrary in general, in the sense that we make
them up is fine. Entirely arbitrary *each time* where we don't know
where they'll be in the future until after the current release is done
is bad for users, Fedora developers, upstream developers, downstreams,
and basically every group I can think of.


you're proposing sounded like a large amount of work for (particularly)
release engineering, but came with no clear justification beyond "I
have an unquantifiable feeling that we can get better press coverage if
we do one release a year", which is extremely thin. At a bare minimum,
any significant release cycle change needs to come with a ground-up and
coherent justification of why *that* is the best way, right now, for
the Fedora project to produce little baby Fedoras.

I'm sorry — I'll blame some of this on what Smooge said, about emailing
ideas from the conference floor. I didn't mean for the release adoption curve
and PR cycles to be the justification — that's just what got me
thinking about it right now.

I'm not sure what the best way is, right now.



It also seems bizarre to be having a 'release' conversation that
doesn't really seem to tie in at all with what's going on with
Modularity and Factory 2.0...since I thought those were the primary
drivers of planned major change to how we deliver Fedora.

Somewhere back in the early part of one of these threads, that *was* in
there — Generational Core on _three month_ cycles following new kernel
releases, userspace modules updated on their own natural cycles, and
big release events annually.

Langdon is sitting right next to me right now and I'm going to tag him
in for more on Modularity.



So, what I hope for with gen-core/modularity is that the decision to 
"release" becomes entirely unrelated to engineering. In other words, at 
any given time there is a fully working/fully tested, up to date 
gen-core and all the applications (or modules) that sit on it. Those 
applications will also, likely, be able to run on multiple gen-cores. As 
result, the processes to produce working artifacts that users can 
install will always be running. Hopefully, with enough CI (read: 
automated testing) that there is little to no human involvement in 
ensure that everything is in "good shape."


If we can get to that point, then we can make "release" and "lifecycle" 
decisions purely based on the desire of "not code" reasons. In other 
words, we can decide how many versions of things are currently available 
based on the effort required to maintain them. We can also decide when a 
"release" makes sense based on marketing or other considerations and 
just "pull the trigger" on that day. Or we could allow users to decide 
for themselves by opting in to a "rolling release" style of deployment.


Right now, we decide on the server-side when a "release" happens for 
lots of reasons. In the modularized world, there is no reason that we 
can't let users decide when they get new versions of things and they may 
even want different rules for different software. Or, as that is likely 
to be pretty confusing (particularly at first) we could have the 
Editions decide their policies/releases and have the client tools 
"enforce" them.


Langdon

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

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

[jenkins]

See 

Changes:

[Mark Reynolds] Ticket 48681 - logconv.pl lists sasl binds with no dn as 
anonymous

--
Started by an SCM change
Building remotely on F23 (fedora Fedora23 Fedora fedora23) in workspace 

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

Running configure...
CFLAGS= -Wall CXXFLAGS= -Wall ./configure --with-tmpfiles-d=/etc/tmpfiles.d 
--with-openldap --enable-autobind --enable-gcc-security --with-selinux 
--with-systemdsystemunitdir=/lib/systemd/system 
--with-systemdsystemconfdir=/etc/systemd/system --enable-debug
Build log is 
https://jenkins.fedorainfracloud.org/job/389-ds-base/ws/build.1141.txt
autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal --force -I m4
autoreconf: configure.ac: tracing
autoreconf: running: libtoolize --copy --force
libtoolize: putting auxiliary files in '.'.
libtoolize: copying file './ltmain.sh'
libtoolize: putting macros in 'm4'.
libtoolize: copying file 'm4/libtool.m4'
libtoolize: copying file 'm4/ltoptions.m4'
libtoolize: copying file 'm4/ltsugar.m4'
libtoolize: copying file 'm4/ltversion.m4'
libtoolize: copying file 'm4/lt~obsolete.m4'
libtoolize: Consider adding 'AC_CONFIG_MACRO_DIRS([m4])' to configure.ac,
libtoolize: and rerunning libtoolize and aclocal.
autoreconf: running: /usr/bin/autoconf --force
autoreconf: running: /usr/bin/autoheader --force
autoreconf: running: automake --add-missing --copy --force-missing
configure.ac:29: installing './compile'
configure.ac:25: installing './config.guess'
configure.ac:25: installing './config.sub'
configure.ac:14: installing './install-sh'
configure.ac:14: installing './missing'
Makefile.am: installing './depcomp'
autoreconf: Leaving directory `.'

Running make...
Build log is 
https://jenkins.fedorainfracloud.org/job/389-ds-base/ws/build.1141.txt

Checking for warnings...
Build https://jenkins.fedorainfracloud.org/job/389-ds-base/1141/ failed
There are build warnings
Warning log is 
https://jenkins.fedorainfracloud.org/job/389-ds-base/ws/build-warns.1141.txt
Last 100 lines of warning log:

ldap/servers/plugins/memberof/memberof.c:3106:8: warning: variable ‘msg’ set 
but not used [-Wunused-but-set-variable]


Build step 'Execute shell' marked build as failure
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

[Adam Williamson]

On Fri, 2016-12-09 at 15:05 -0500, Matthew Miller wrote:
> On Fri, Dec 09, 2016 at 11:55:26AM -0800, Adam Williamson wrote:
> > problem. The fact that updates default to auto-push after +3 karma is
> > entirely plucked out of the air, it's just something someone made up
> > one day. We could *certainly* change that. I'd be quite interested in a
> > tweak where there's a minimum-time-in-testing value for autopush too,
> > which would default to say 2 days. The way that would work is automatic
> > push would never happen until the update had actually been in updates-
> > testing (not queued for push) for that long. *Manual* push could still
> > be done during that time, and the update submitter could make the
> > minimum-time-in-testing value larger or smaller (as they can make the
> > karma threshold for autopush greater or smaller). 2 days would just be
> > the default (and is similarly a number I've just made up; we could make
> > it something else).
> 
> What if we combined this time threshold with, also, auto-pushes happen
> only on Monday (or whatever)?

I wouldn't hate it. On a visceral level I've never bought the 'batched
updates' idea at all, but if it only affects autopushes I don't mind
tweaking around. It doesn't involve too much work to change, it's easy
to change back, and manual pushes are still available.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

[Matthew Miller]

On Fri, Dec 09, 2016 at 11:55:26AM -0800, Adam Williamson wrote:
> problem. The fact that updates default to auto-push after +3 karma is
> entirely plucked out of the air, it's just something someone made up
> one day. We could *certainly* change that. I'd be quite interested in a
> tweak where there's a minimum-time-in-testing value for autopush too,
> which would default to say 2 days. The way that would work is automatic
> push would never happen until the update had actually been in updates-
> testing (not queued for push) for that long. *Manual* push could still
> be done during that time, and the update submitter could make the
> minimum-time-in-testing value larger or smaller (as they can make the
> karma threshold for autopush greater or smaller). 2 days would just be
> the default (and is similarly a number I've just made up; we could make
> it something else).

What if we combined this time threshold with, also, auto-pushes happen
only on Monday (or whatever)?

-- 
Matthew Miller

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

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

[Adam Williamson]

On Fri, 2016-12-09 at 20:46 +0100, Michael Schwendt wrote:
> On Fri, 9 Dec 2016 19:41:28 +0100, Ralf Corsepius wrote:
> 
> > And? What*s the problem? It's part of a packagers job to balance the 
> > tradeoffs and find a viable compromise.
> 
> You don't need to agree. In the reply you've truncated, I've only pointed
> out how I feel about the updates flood. It's my number one reason why I've
> pretty much given up spending karma points in bodhi as all too often an
> update had been pushed before I could vote -1. Rushing out updates
> defeats the purpose of Test Updates, IMO. And nothing is done to make
> the updates-testing repo more sexy.

There are much simpler ways to deal with this, if it's really a
problem. The fact that updates default to auto-push after +3 karma is
entirely plucked out of the air, it's just something someone made up
one day. We could *certainly* change that. I'd be quite interested in a
tweak where there's a minimum-time-in-testing value for autopush too,
which would default to say 2 days. The way that would work is automatic
push would never happen until the update had actually been in updates-
testing (not queued for push) for that long. *Manual* push could still
be done during that time, and the update submitter could make the
minimum-time-in-testing value larger or smaller (as they can make the
karma threshold for autopush greater or smaller). 2 days would just be
the default (and is similarly a number I've just made up; we could make
it something else).
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

[Matthew Miller]

On Fri, Dec 09, 2016 at 08:50:06AM -0800, Adam Williamson wrote:
> > So, *did* you feel that the F25 cycle felt compressed? If we're close
> > enough to the theoretical-world above that we feel like we can do, say,
> > four month cycles to stay on track without experiencing (particular)
> > pain, maybe that's okay.
> This seems like an impossible question to answer. Our release cycles
> are entirely arbitrary; they're precisely what we say they are. So I'm
> not sure how to say whether one "feels compressed", or understand how
> "four month cycles" would make us "stay on track". *What* track would
> we be staying on?

Roughly Mother's Day / Halloween, and not unpredictably cycling around
the calendar. Entirely arbitrary in general, in the sense that we make
them up is fine. Entirely arbitrary *each time* where we don't know
where they'll be in the future until after the current release is done
is bad for users, Fedora developers, upstream developers, downstreams,
and basically every group I can think of.

> you're proposing sounded like a large amount of work for (particularly)
> release engineering, but came with no clear justification beyond "I
> have an unquantifiable feeling that we can get better press coverage if
> we do one release a year", which is extremely thin. At a bare minimum,
> any significant release cycle change needs to come with a ground-up and
> coherent justification of why *that* is the best way, right now, for
> the Fedora project to produce little baby Fedoras.

I'm sorry — I'll blame some of this on what Smooge said, about emailing
ideas from the conference floor. I didn't mean for the release adoption curve
and PR cycles to be the justification — that's just what got me
thinking about it right now.

I'm not sure what the best way is, right now.


> It also seems bizarre to be having a 'release' conversation that
> doesn't really seem to tie in at all with what's going on with
> Modularity and Factory 2.0...since I thought those were the primary
> drivers of planned major change to how we deliver Fedora.

Somewhere back in the early part of one of these threads, that *was* in
there — Generational Core on _three month_ cycles following new kernel
releases, userspace modules updated on their own natural cycles, and
big release events annually.

Langdon is sitting right next to me right now and I'm going to tag him
in for more on Modularity.

-- 
Matthew Miller

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

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

[Michael Schwendt]

On Fri, 9 Dec 2016 19:41:28 +0100, Ralf Corsepius wrote:

> And? What*s the problem? It's part of a packagers job to balance the 
> tradeoffs and find a viable compromise.

You don't need to agree. In the reply you've truncated, I've only pointed
out how I feel about the updates flood. It's my number one reason why I've
pretty much given up spending karma points in bodhi as all too often an
update had been pushed before I could vote -1. Rushing out updates
defeats the purpose of Test Updates, IMO. And nothing is done to make
the updates-testing repo more sexy.

"Viable" is such a vague word.

> Openly said, I feel some people do not comprehend the fundamental 
> differences between RHEL, CentOS and Fedora and between a community 
> project and an enterprise project.

You mean, like EPEL that is flooded with updates, too? ;)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Un-retiring QCad

[Przemek Klosowski]

On 12/06/2016 08:25 AM, Antonio Trande wrote:

This is an un-retiring request for QCad on Fedora
(https://admin.fedoraproject.org/pkgdb/package/rpms/qcad/). Now upstream
provides an open-source community edition version of QCad
Could you comment on the current relationship of QCad to its fork 
LibreCAD, available in Fedora from librecad.org?
I believe librecad was forked for licensing and/or maintenance issues, 
so I am glad to hear that moved forward, but can you give some 
background on where the situation stands now as to the relative merits 
of both projects?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

corsepiu pushed to perl-Devel-StackTrace (f24). "Mandatory Perl build-requires added "

[notifications]

From 8a19f9fd951379ba3746beb68418f3eb3a53f91a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= 
Date: Fri, 24 Jun 2016 10:25:06 +0200
Subject: Mandatory Perl build-requires added
 

---
 perl-Devel-StackTrace.spec | 1 +
 1 file changed, 1 insertion(+)

diff --git a/perl-Devel-StackTrace.spec b/perl-Devel-StackTrace.spec
index 1d17791..64472fe 100644
--- a/perl-Devel-StackTrace.spec
+++ b/perl-Devel-StackTrace.spec
@@ -17,6 +17,7 @@ BuildArch:  noarch
 # Disabled by default
 %bcond_with author_tests
 
+BuildRequires:  perl-generators
 BuildRequires:  perl(base)
 BuildRequires:  perl(bytes)
 BuildRequires:  perl(ExtUtils::MakeMaker)
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl-Devel-StackTrace.git/commit/?h=f24=8a19f9fd951379ba3746beb68418f3eb3a53f91a
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

corsepiu pushed to perl-Devel-StackTrace (f24). "Perl 5.24 rebuild"

[notifications]

From af7803f1e8668aeffe4160536839e12631be66e5 Mon Sep 17 00:00:00 2001
From: Jitka Plesnikova 
Date: Sat, 14 May 2016 13:00:41 +0200
Subject: Perl 5.24 rebuild

---
 perl-Devel-StackTrace.spec | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/perl-Devel-StackTrace.spec b/perl-Devel-StackTrace.spec
index 40617e1..1d17791 100644
--- a/perl-Devel-StackTrace.spec
+++ b/perl-Devel-StackTrace.spec
@@ -2,7 +2,7 @@ Name:   perl-Devel-StackTrace
 Summary:Perl module implementing stack trace and stack trace frame 
objects
 Version:2.01
 Epoch:  1
-Release:1%{?dist}
+Release:2%{?dist}
 License:Artistic 2.0
 Group:  Development/Libraries
 URL:http://search.cpan.org/dist/Devel-StackTrace/
@@ -88,6 +88,9 @@ make test %{?with_release_tests:RELEASE_TESTING=1} 
%{?with_author_tests:AUTHOR_T
 %{_mandir}/man3/*
 
 %changelog
+* Sat May 14 2016 Jitka Plesnikova  - 1:2.01-2
+- Perl 5.24 rebuild
+
 * Fri Mar 04 2016 Ralf Corsépius  - 1:2.01-1
 - Update to 2.01.
 
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl-Devel-StackTrace.git/commit/?h=f24=af7803f1e8668aeffe4160536839e12631be66e5
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

corsepiu pushed to perl-Devel-StackTrace (f24). "Cleanup merger."

[notifications]

From b2d11302e8139db733237e875e02432996bf9f94 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ralf=20Cors=C3=A9pius?= 
Date: Fri, 9 Dec 2016 20:33:38 +0100
Subject: Cleanup merger.

---
 perl-Devel-StackTrace.spec | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/perl-Devel-StackTrace.spec b/perl-Devel-StackTrace.spec
index c93b40a..b588006 100644
--- a/perl-Devel-StackTrace.spec
+++ b/perl-Devel-StackTrace.spec
@@ -105,9 +105,6 @@ make %{?_smp_mflags}
 * Fri Dec 09 2016 Ralf Corsépius  - 1:2.02-1
 - Update to 2.02.
 
-* Sat May 14 2016 Jitka Plesnikova  - 1:2.01-2
-- Perl 5.24 rebuild
-
 * Fri Mar 04 2016 Ralf Corsépius  - 1:2.01-1
 - Update to 2.01.
 
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl-Devel-StackTrace.git/commit/?h=f24=b2d11302e8139db733237e875e02432996bf9f94
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

corsepiu pushed to perl-Devel-StackTrace (f24). "Update to 2.02."

[notifications]

From d69775333bfb89a029a509ea1a6d4dbb55c8ad21 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ralf=20Cors=C3=A9pius?= 
Date: Fri, 9 Dec 2016 18:32:54 +0100
Subject: Update to 2.02.

---
 .gitignore |  2 +-
 perl-Devel-StackTrace.spec | 24 
 sources|  2 +-
 3 files changed, 22 insertions(+), 6 deletions(-)

diff --git a/.gitignore b/.gitignore
index 4c29769..736bd80 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1 @@
-/Devel-StackTrace-2.01.tar.gz
+/Devel-StackTrace-2.02.tar.gz
diff --git a/perl-Devel-StackTrace.spec b/perl-Devel-StackTrace.spec
index 64472fe..c93b40a 100644
--- a/perl-Devel-StackTrace.spec
+++ b/perl-Devel-StackTrace.spec
@@ -1,8 +1,8 @@
 Name:   perl-Devel-StackTrace
 Summary:Perl module implementing stack trace and stack trace frame 
objects
-Version:2.01
+Version:2.02
 Epoch:  1
-Release:2%{?dist}
+Release:1%{?dist}
 License:Artistic 2.0
 Group:  Development/Libraries
 URL:http://search.cpan.org/dist/Devel-StackTrace/
@@ -18,6 +18,9 @@ BuildArch:  noarch
 %bcond_with author_tests
 
 BuildRequires:  perl-generators
+BuildRequires:  %{__perl}
+BuildRequires:  %{__make}
+
 BuildRequires:  perl(base)
 BuildRequires:  perl(bytes)
 BuildRequires:  perl(ExtUtils::MakeMaker)
@@ -56,6 +59,16 @@ BuildRequires:  perl(Test::Pod) > 1.41
 BuildRequires:  perl(Test::Pod::Coverage) >= 1.08
 BuildRequires:  perl(Test::Spelling) >= 0.12
 BuildRequires:  perl(Test::Synopsis)
+# N/A in Fedora BuildRequires:  perl(Code::TidyAll::Plugin::Test::Vars) >= 0.02
+BuildRequires:  perl(Parallel::ForkManager) >= 1.19
+BuildRequires:  perl(Perl::Critic) >= 1.126
+BuildRequires:  perl(Perl::Tidy) >= 20160302
+BuildRequires:  perl(Test::CPAN::Meta::JSON) >= 0.16
+BuildRequires:  perl(Test::Code::TidyAll) >= 0.50
+BuildRequires:  perl(Test::Mojibake)
+BuildRequires:  perl(Test::Portability::Files)
+BuildRequires:  perl(Test::Vars) >= 0.009
+BuildRequires:  perl(Test::Version) >= 2.05
 %endif
 
 %description
@@ -76,11 +89,11 @@ data available from caller() as of Perl 5.6.0.
 make %{?_smp_mflags}
 
 %install
-make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT
+%{__make} pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT
 %{_fixperms} $RPM_BUILD_ROOT/*
 
 %check
-make test %{?with_release_tests:RELEASE_TESTING=1} 
%{?with_author_tests:AUTHOR_TESTING=1}
+%{__make} test %{?with_release_tests:RELEASE_TESTING=1} 
%{?with_author_tests:AUTHOR_TESTING=1}
 
 %files
 %doc Changes
@@ -89,6 +102,9 @@ make test %{?with_release_tests:RELEASE_TESTING=1} 
%{?with_author_tests:AUTHOR_T
 %{_mandir}/man3/*
 
 %changelog
+* Fri Dec 09 2016 Ralf Corsépius  - 1:2.02-1
+- Update to 2.02.
+
 * Sat May 14 2016 Jitka Plesnikova  - 1:2.01-2
 - Perl 5.24 rebuild
 
diff --git a/sources b/sources
index 6f62a9b..ae37cec 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-164a5908bcfb79a8fbbca1a2182416ae  Devel-StackTrace-2.01.tar.gz
+bcc49dc2744d1fae906de0de3df07cca  Devel-StackTrace-2.02.tar.gz
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl-Devel-StackTrace.git/commit/?h=f24=d69775333bfb89a029a509ea1a6d4dbb55c8ad21
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

corsepiu pushed to perl-Devel-StackTrace (f25). "Update to 2.02."

[notifications]

From d69775333bfb89a029a509ea1a6d4dbb55c8ad21 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ralf=20Cors=C3=A9pius?= 
Date: Fri, 9 Dec 2016 18:32:54 +0100
Subject: Update to 2.02.

---
 .gitignore |  2 +-
 perl-Devel-StackTrace.spec | 24 
 sources|  2 +-
 3 files changed, 22 insertions(+), 6 deletions(-)

diff --git a/.gitignore b/.gitignore
index 4c29769..736bd80 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1 @@
-/Devel-StackTrace-2.01.tar.gz
+/Devel-StackTrace-2.02.tar.gz
diff --git a/perl-Devel-StackTrace.spec b/perl-Devel-StackTrace.spec
index 64472fe..c93b40a 100644
--- a/perl-Devel-StackTrace.spec
+++ b/perl-Devel-StackTrace.spec
@@ -1,8 +1,8 @@
 Name:   perl-Devel-StackTrace
 Summary:Perl module implementing stack trace and stack trace frame 
objects
-Version:2.01
+Version:2.02
 Epoch:  1
-Release:2%{?dist}
+Release:1%{?dist}
 License:Artistic 2.0
 Group:  Development/Libraries
 URL:http://search.cpan.org/dist/Devel-StackTrace/
@@ -18,6 +18,9 @@ BuildArch:  noarch
 %bcond_with author_tests
 
 BuildRequires:  perl-generators
+BuildRequires:  %{__perl}
+BuildRequires:  %{__make}
+
 BuildRequires:  perl(base)
 BuildRequires:  perl(bytes)
 BuildRequires:  perl(ExtUtils::MakeMaker)
@@ -56,6 +59,16 @@ BuildRequires:  perl(Test::Pod) > 1.41
 BuildRequires:  perl(Test::Pod::Coverage) >= 1.08
 BuildRequires:  perl(Test::Spelling) >= 0.12
 BuildRequires:  perl(Test::Synopsis)
+# N/A in Fedora BuildRequires:  perl(Code::TidyAll::Plugin::Test::Vars) >= 0.02
+BuildRequires:  perl(Parallel::ForkManager) >= 1.19
+BuildRequires:  perl(Perl::Critic) >= 1.126
+BuildRequires:  perl(Perl::Tidy) >= 20160302
+BuildRequires:  perl(Test::CPAN::Meta::JSON) >= 0.16
+BuildRequires:  perl(Test::Code::TidyAll) >= 0.50
+BuildRequires:  perl(Test::Mojibake)
+BuildRequires:  perl(Test::Portability::Files)
+BuildRequires:  perl(Test::Vars) >= 0.009
+BuildRequires:  perl(Test::Version) >= 2.05
 %endif
 
 %description
@@ -76,11 +89,11 @@ data available from caller() as of Perl 5.6.0.
 make %{?_smp_mflags}
 
 %install
-make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT
+%{__make} pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT
 %{_fixperms} $RPM_BUILD_ROOT/*
 
 %check
-make test %{?with_release_tests:RELEASE_TESTING=1} 
%{?with_author_tests:AUTHOR_TESTING=1}
+%{__make} test %{?with_release_tests:RELEASE_TESTING=1} 
%{?with_author_tests:AUTHOR_TESTING=1}
 
 %files
 %doc Changes
@@ -89,6 +102,9 @@ make test %{?with_release_tests:RELEASE_TESTING=1} 
%{?with_author_tests:AUTHOR_T
 %{_mandir}/man3/*
 
 %changelog
+* Fri Dec 09 2016 Ralf Corsépius  - 1:2.02-1
+- Update to 2.02.
+
 * Sat May 14 2016 Jitka Plesnikova  - 1:2.01-2
 - Perl 5.24 rebuild
 
diff --git a/sources b/sources
index 6f62a9b..ae37cec 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-164a5908bcfb79a8fbbca1a2182416ae  Devel-StackTrace-2.01.tar.gz
+bcc49dc2744d1fae906de0de3df07cca  Devel-StackTrace-2.02.tar.gz
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl-Devel-StackTrace.git/commit/?h=f25=d69775333bfb89a029a509ea1a6d4dbb55c8ad21
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

[Gerald B. Cox]

On Fri, Dec 9, 2016 at 11:00 AM, Adam Williamson  wrote:

> Yes, but the burden of proof always lies with those who want to change
> stuff. I've got the easy job here: I just get to say 'look, if you want
> to change everything, provide some concrete evidence:
>
> a) that there's a problem
> b) that the changes will solve it
> c) that they won't create larger problems than the ones they solve'
>
> That's always how it works. You have to provide a justification for
> change. No justification is really needed for no-change.
>

Yup... absolutely true.  Change for change sake isn't a reason - and
spectral justifications
don't cut it.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Summary/Minutes from today's FESCo Meeting (2016-12-09)

[Chris Adams]

Once upon a time, Josh Boyer  said:
> On Fri, Dec 9, 2016 at 12:20 PM, Chris Adams  wrote:
> > Once upon a time, Adam Miller  said:
> >> Meeting started by maxamillion at 16:00:37 UTC. The full logs are
> >> available at
> >> https://meetbot.fedoraproject.org/fedora-meeting/2016-12-09/fesco.2016-12-09-16.00.log.html
> >
> > So, this is a minor request...
> >
> > I read email in mutt, a terminal-based mail client.  I have it
> > configured so I can open up URLs in lynx easily.  Recently though, I
> > can't open the agenda or logs from meetings in lynx.  I don't know when
> > this happened (I don't try to pull them up all the time, just when I see
> > something that interests me).
> >
> > Any chance this could be addressed?
> 
> Um... that sounds like a bug in mutt and/or lynx?  The URLs that are
> included are just standard URLs so there's nothing to fix from that
> aspect.

It's the content at the URLs, not the URL itself (sorry if I didn't make
it clear).  The agenda URL apparently wants me to authenticate with
OpenID, and the log URL just names the log (content in an IFRAME or
something maybe?).

These are the URLs I am testing:

https://pagure.io/fesco/report/meeting_agenda
https://meetbot.fedoraproject.org/fedora-meeting/2016-12-09/fesco.2016-12-09-16.00.log.html

I know web devs love to use HTML5, CSS, and scripting to do all kinds of
fancy stuff, but a simple list of tickets and a plain text log dump
shouldn't require anything special.
-- 
Chris Adams 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

[Gerald B. Cox]

On Fri, Dec 9, 2016 at 4:51 AM, Michael Schwendt 
wrote:

> And there it is again, the rush to get out updates. Quickly! Quickly!
> What has been released before is not bug-free, and the update are not
> bug-free either, and even if no user has reported a bug, the flow of
> updates will ensure that the user will be affected by a new bug
> eventually.
>
> No one is saying that.  There is a process now to test changes - KDE
utilizes that and
it has been working and your not waiting on an artificially imposed
criteria to get new
releases.


> If as a maintainer you don't release version upgrades quickly, some users
> complain everywhere they are permitted to post. Except for bugzilla. And
> if you make available upgrades quickly, the users will complain if they
> think they are affected by bugs.
>
Upstream release cycles are not aligned with Fedora's dist release schedule
> anyway.
>

True, and holding back a release because of the distributions release
schedule
really doesn't make any sense.  The current system handles it.  KDE has
proved that.

>
> > I think pushing all updates in a big drop will actually make them LESS
> > tested than if they just trickle through one at a time.
>
> The latter is turning all users of the stable "updates" repo into
> testers once those updates are unleashed so quickly. And those brave ones,
> albeit only few, who would be willing to evaluate "Test Updates" for some
> time, don't get any real chance to do so, because updates are rushed out.
>

No, there is a Testing repo.  They aren't pushed to stable until the
maintainer decides they
are ready.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

[Adam Williamson]

On Fri, 2016-12-09 at 19:48 +0100, Michael Schwendt wrote:
> On Fri, 09 Dec 2016 09:40:08 -0800, Adam Williamson wrote:
> 
> > This is just a bunch of entirely unsupported assertions, and thus not
> > worth the time to respond to.
> 
> Same applies to your usage scenario. Personal experience is just that:
> personal experience.

Yes, but the burden of proof always lies with those who want to change
stuff. I've got the easy job here: I just get to say 'look, if you want
to change everything, provide some concrete evidence:

a) that there's a problem
b) that the changes will solve it
c) that they won't create larger problems than the ones they solve'

That's always how it works. You have to provide a justification for
change. No justification is really needed for no-change.

> Great! Then something else is the cause, such as editing bodhi tickets and
> replacing builds or removing them. Whatever. Or else "dnf" would not find
> installed packages with no reference in bodhi. And previous releases of
> a package in the repo still get deleted, breaking history undo.

Well, yes. I don't think it's ever been claimed that 'history undo' is
guaranteed to always work. We've never claimed to keep every build that
at some point landed in updates-testing or updates there forever, so
far as I know.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

[Michael Schwendt]

On Fri, 09 Dec 2016 09:40:08 -0800, Adam Williamson wrote:

> This is just a bunch of entirely unsupported assertions, and thus not
> worth the time to respond to.

Same applies to your usage scenario. Personal experience is just that:
personal experience.

> But I'll just note that it is not possible to delete updates in Bodhi,
> and hasn't been since Bodhi 2 arrived, which was years ago.

Great! Then something else is the cause, such as editing bodhi tickets and
replacing builds or removing them. Whatever. Or else "dnf" would not find
installed packages with no reference in bodhi. And previous releases of
a package in the repo still get deleted, breaking history undo.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

[Ralf Corsepius]

On 12/09/2016 01:51 PM, Michael Schwendt wrote:

On Fri, 09 Dec 2016 06:07:02 +0100, Kevin Kofler wrote:



If as a maintainer you don't release version upgrades quickly, some users
complain everywhere they are permitted to post. Except for bugzilla. And
if you make available upgrades quickly, the users will complain if they
think they are affected by bugs.


And? What*s the problem? It's part of a packagers job to balance the 
tradeoffs and find a viable compromise.



I think pushing all updates in a big drop will actually make them LESS
tested than if they just trickle through one at a time.

Agreed. Swapping one large bowl over users doesn't help anybody.

Openly said, I feel some people do not comprehend the fundamental 
differences between RHEL, CentOS and Fedora and between a community 
project and an enterprise project.


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

Re: Summary/Minutes from today's FESCo Meeting (2016-12-09)

[Stephen John Smoogen]

On 9 December 2016 at 12:35, Josh Boyer  wrote:
> On Fri, Dec 9, 2016 at 12:20 PM, Chris Adams  wrote:
>> Once upon a time, Adam Miller  said:
>>> Meeting started by maxamillion at 16:00:37 UTC. The full logs are
>>> available at
>>> https://meetbot.fedoraproject.org/fedora-meeting/2016-12-09/fesco.2016-12-09-16.00.log.html
>>
>> So, this is a minor request...
>>
>> I read email in mutt, a terminal-based mail client.  I have it
>> configured so I can open up URLs in lynx easily.  Recently though, I
>> can't open the agenda or logs from meetings in lynx.  I don't know when
>> this happened (I don't try to pull them up all the time, just when I see
>> something that interests me).
>>
>> Any chance this could be addressed?
>
> Um... that sounds like a bug in mutt and/or lynx?  The URLs that are
> included are just standard URLs so there's nothing to fix from that
> aspect.


The problems seems to be that the new meetbot m0te does not render  a
page in lynx.

Going to the link just says:

fedora-meeting channel meeting logs - 2016-12-09

   fesco.2016-12-09-16.00.log.html

The same in elinks. It looks like we are relying on some HTML/CSS
magic which makes text browsers useless. Probably effects text2voice
readers for blind readers also.

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



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

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

[Sérgio Basto]

On Qui, 2016-12-08 at 09:17 -0500, Matthew Miller wrote:
> Trying to make this idea a little more concrete. Here's two
> suggestions
> for how it might work. These are strawman ideas -- please provide
> alternates, poke holes, etc. And particularly from a QA and rel-eng
> point of view. Both of these are not taking modularity into account
> in
> any way; it's "how we could do this with our current distro-building
> process".
> 
> 
> Option 1: Big batched update
> 
>   1. Release F26 according to schedule
>  https://fedoraproject.org/wiki/Releases/26/Schedule
> 
>   2. At the beginning of October, stop pushing non-security updates
>  from updates-testing to updates
> 
>   3. Bigger updates (desktop environment refreshes, etc.) allowed
> into
>  updates-testing at this time.
> 
>   4. Mid-October, freeze exceptions for getting into updates-testing
>  even.
> 
>   5. Test all of that together in Some Handwavy Way for serious
>  problems and regressions.
> 
>   6. Once all good, push from updates-testing to updates at end of
>  October or beginning of November.
> 
> 
> Option 2: Branching!
> 
>   1. Release F26 according to schedule.
> 
>   2. July/August: branch F26.1 from F26 (not rawhide)
> 
>   3. Updates to F26 also go into F26.1 (magic happens here?)
> 
>   4. No Alpha, but do "Beta" freeze and validation as normal for
>  release.
> 
>   5. And same for F26.1 final
> 
>   6. And sometime in October/November, release that (but without big
>  press push).
> 
>   7. GNOME Software presents F26.1 as upgrade option
> 
>   8. F26 continues in parallel through December
> 
>   9. In January, update added to F26 which activates the F26.1 repo.
> 
>  10. And also in January updates stop going to F26.


I like the idea of option 2 or any idea that may give us more stable
releases. And I think we should work on this idea since I am not alone
:) 

I wrote something near to that, years ago,  F26.1 final be a new base
i.e. all updates go to the base repo  when F26.1 release . 
I'm thinking also in post-release idea , so maybe, the plan could be
something like : 
F26 GA , one month later F24 EOL and F26.1 at same time and just
another month later F27 branch. This idea avoid duplication of QA work
in stable and devel branch at same time and QA just begin to work on
devel branch one (or two) month(s) later.

Best regards.
> 
> Some of this idea, by the way, is reminiscent of Spot's suggestions
> at
> FUDCon Lawrence in 2013. This is not completely coincidence - I
> always
> liked those ideas!
> 
> 
-- 
Sérgio M. B.

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

Re: a diversion into EPEL [was Re: Two more concrete ideas for what a once-yearly+update schedule would look like]

[Przemek Klosowski]

On 12/09/2016 11:17 AM, Matthew Miller wrote:

For other software, where users would like the
version to match more closely the long lifecycle, maybe there could be
a hand-off from Fedora version to CentOS version.
Yeah, hand-offs would be a great feature for the users. Right now, it's 
tricky to use Fedora in production because of the 18-month support 
cycle; a smooth hand-off would make it much easier to manage Fedora 
installations, and therefore would help adoption. I know I would use 
Fedora more in production if I could rely on hand-off.


It would be a great selling point:
 Fedora offers cutting-edge features now, and transitions 
gently to long term support.


Strangely, this also affects  RedHat commercial products: we've run into 
situations where we deployed paid, supported systems and then something 
happened and they fell off the list, thus losing updates. I thought it'd 
be a nice feature in RedHat to hand off unsupported systems to CentOS. 
Right now, I buy commercial support for the most important systems, 
deploy CentOS for not very important ones that don't need latest 
versions, and use Fedora when I need the most recent features. Hand-offs 
that work across all three(*) would make managing this stuff much easier.


I had a conversation with RedHat, arguing that whatever revenue they 
lost on those systems would be offset by having more systems overall, 
because people like me would be less hesitant to deploy RedHat; 
long-term support considerations would be decoupled from technical issues.




(*) of course only in reasonable configurations: I could only see two 
useful hand-offs: Fedora ->CentOS and RedHat -> CentOS---I can't see how 
it'd make sense to hand-off from e.g. RedHat to Fedora.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

[Adam Williamson]

On Fri, 2016-12-09 at 18:37 +0100, Michael Schwendt wrote:
> On Fri, 09 Dec 2016 08:44:26 -0800, Adam Williamson wrote:
> 
> > On Fri, 2016-12-09 at 13:18 +0100, Michael Schwendt wrote:
> > > The apparently random flow of poorly tested "rushed out" updates  
> > 
> > 
> 
> Nah, not needed at all. Basically, one can update a desktop workstation to
> death, if applying updates too often or not at the right time. Then you
> suffer from updates causing regression, if not searching for an even newer
> update in the updates-testing repo, where pulling out individual packages
> isn't safe. One faces a growing number of issues, systemd waiting for
> timeouts during poweroff/reboot, SELinux errors or warnings, GNOME Shell
> logging you out, applications failing to render or refusing to work,
> Firefox crashing, ABRT collecting unusable crash data daily, DNF being
> unable to perform history undo, because packages are not found in the
> repos anymore. You can find failure reports from users, who haven't
> updated their installation for weeks, then applied 200 or more updates at
> once and afterwards couldn't log in anymore. And if updating to
> updates-testing, there are still packagers, who delete their bodhi pages,
> so eventually you notice that a distro-sync wants to downgrade updates
> that have been deleted "silently" (why? negative karma?  severe
> breakage?).

This is just a bunch of entirely unsupported assertions, and thus not
worth the time to respond to.

But I'll just note that it is not possible to delete updates in Bodhi,
and hasn't been since Bodhi 2 arrived, which was years ago.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

[Michael Schwendt]

On Fri, 09 Dec 2016 08:44:26 -0800, Adam Williamson wrote:

> On Fri, 2016-12-09 at 13:18 +0100, Michael Schwendt wrote:
> > The apparently random flow of poorly tested "rushed out" updates  
> 
> 

Nah, not needed at all. Basically, one can update a desktop workstation to
death, if applying updates too often or not at the right time. Then you
suffer from updates causing regression, if not searching for an even newer
update in the updates-testing repo, where pulling out individual packages
isn't safe. One faces a growing number of issues, systemd waiting for
timeouts during poweroff/reboot, SELinux errors or warnings, GNOME Shell
logging you out, applications failing to render or refusing to work,
Firefox crashing, ABRT collecting unusable crash data daily, DNF being
unable to perform history undo, because packages are not found in the
repos anymore. You can find failure reports from users, who haven't
updated their installation for weeks, then applied 200 or more updates at
once and afterwards couldn't log in anymore. And if updating to
updates-testing, there are still packagers, who delete their bodhi pages,
so eventually you notice that a distro-sync wants to downgrade updates
that have been deleted "silently" (why? negative karma?  severe
breakage?).
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: a diversion into EPEL [was Re: Two more concrete ideas for what a once-yearly+update schedule would look like]

[Josh Boyer]

On Fri, Dec 9, 2016 at 12:14 PM, Igor Gnatenko
 wrote:
> On Dec 9, 2016 5:18 PM, "Matthew Miller"  wrote:
>
> On Fri, Dec 09, 2016 at 11:07:32AM -0500, Colin Walters wrote:
>> > Anyways, in the big picture, while I don't speak for everyone on
>> > the Project Atomic side, I personally point users at CentOS first,
>> > unless I have some reason to think they want Fedora. Something like
>> > 80% of Fedora usage hitting the mirrors was desktop systems, right?
>> > I don't expect that to change personally.
>> Although..except for EPEL.  And how EPEL works should obviously be
>> part of this. Things would feel clearer if EPEL lived in CentOS now
>> perhaps.
>
> Right; in mirror traffic, EPEL is to Fedora Workstation as Workstation
> is to Server. :)
>
> EPEL packages *are* Fedora packages, though — moving the project to
> CentOS isn't completely crazy, but would require a lot more integration
> and cooperation between the projects.
>
> That's something I'd like to see anyway. I think there are a lot of
> opportunities for this with containers and modularity — if you can just
> run Fedora containers on CentOS or RHEL *directly*, why bother
> rebuilding them? For a lot of the software that's in EPEL, that's
> completely sufficient. For other software, where users would like the
> version to match more closely the long lifecycle, maybe there could be
> a hand-off from Fedora version to CentOS version.
>
> Don't know how modularity is related here. It's just about building distro.
> Containers, yeah, but please don't kill Fedora. I don't want to run
> container for each software I use. RHEL and CentOS people can struggle, but
> don't do this with Fedora users.

Please stop with hyperbole.  Nobody is "killing" Fedora.

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

Re: Summary/Minutes from today's FESCo Meeting (2016-12-09)

[Josh Boyer]

On Fri, Dec 9, 2016 at 12:20 PM, Chris Adams  wrote:
> Once upon a time, Adam Miller  said:
>> Meeting started by maxamillion at 16:00:37 UTC. The full logs are
>> available at
>> https://meetbot.fedoraproject.org/fedora-meeting/2016-12-09/fesco.2016-12-09-16.00.log.html
>
> So, this is a minor request...
>
> I read email in mutt, a terminal-based mail client.  I have it
> configured so I can open up URLs in lynx easily.  Recently though, I
> can't open the agenda or logs from meetings in lynx.  I don't know when
> this happened (I don't try to pull them up all the time, just when I see
> something that interests me).
>
> Any chance this could be addressed?

Um... that sounds like a bug in mutt and/or lynx?  The URLs that are
included are just standard URLs so there's nothing to fix from that
aspect.

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

corsepiu pushed to perl-Devel-StackTrace (master). "Update to 2.02."

[notifications]

From d69775333bfb89a029a509ea1a6d4dbb55c8ad21 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ralf=20Cors=C3=A9pius?= 
Date: Fri, 9 Dec 2016 18:32:54 +0100
Subject: Update to 2.02.

---
 .gitignore |  2 +-
 perl-Devel-StackTrace.spec | 24 
 sources|  2 +-
 3 files changed, 22 insertions(+), 6 deletions(-)

diff --git a/.gitignore b/.gitignore
index 4c29769..736bd80 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1 @@
-/Devel-StackTrace-2.01.tar.gz
+/Devel-StackTrace-2.02.tar.gz
diff --git a/perl-Devel-StackTrace.spec b/perl-Devel-StackTrace.spec
index 64472fe..c93b40a 100644
--- a/perl-Devel-StackTrace.spec
+++ b/perl-Devel-StackTrace.spec
@@ -1,8 +1,8 @@
 Name:   perl-Devel-StackTrace
 Summary:Perl module implementing stack trace and stack trace frame 
objects
-Version:2.01
+Version:2.02
 Epoch:  1
-Release:2%{?dist}
+Release:1%{?dist}
 License:Artistic 2.0
 Group:  Development/Libraries
 URL:http://search.cpan.org/dist/Devel-StackTrace/
@@ -18,6 +18,9 @@ BuildArch:  noarch
 %bcond_with author_tests
 
 BuildRequires:  perl-generators
+BuildRequires:  %{__perl}
+BuildRequires:  %{__make}
+
 BuildRequires:  perl(base)
 BuildRequires:  perl(bytes)
 BuildRequires:  perl(ExtUtils::MakeMaker)
@@ -56,6 +59,16 @@ BuildRequires:  perl(Test::Pod) > 1.41
 BuildRequires:  perl(Test::Pod::Coverage) >= 1.08
 BuildRequires:  perl(Test::Spelling) >= 0.12
 BuildRequires:  perl(Test::Synopsis)
+# N/A in Fedora BuildRequires:  perl(Code::TidyAll::Plugin::Test::Vars) >= 0.02
+BuildRequires:  perl(Parallel::ForkManager) >= 1.19
+BuildRequires:  perl(Perl::Critic) >= 1.126
+BuildRequires:  perl(Perl::Tidy) >= 20160302
+BuildRequires:  perl(Test::CPAN::Meta::JSON) >= 0.16
+BuildRequires:  perl(Test::Code::TidyAll) >= 0.50
+BuildRequires:  perl(Test::Mojibake)
+BuildRequires:  perl(Test::Portability::Files)
+BuildRequires:  perl(Test::Vars) >= 0.009
+BuildRequires:  perl(Test::Version) >= 2.05
 %endif
 
 %description
@@ -76,11 +89,11 @@ data available from caller() as of Perl 5.6.0.
 make %{?_smp_mflags}
 
 %install
-make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT
+%{__make} pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT
 %{_fixperms} $RPM_BUILD_ROOT/*
 
 %check
-make test %{?with_release_tests:RELEASE_TESTING=1} 
%{?with_author_tests:AUTHOR_TESTING=1}
+%{__make} test %{?with_release_tests:RELEASE_TESTING=1} 
%{?with_author_tests:AUTHOR_TESTING=1}
 
 %files
 %doc Changes
@@ -89,6 +102,9 @@ make test %{?with_release_tests:RELEASE_TESTING=1} 
%{?with_author_tests:AUTHOR_T
 %{_mandir}/man3/*
 
 %changelog
+* Fri Dec 09 2016 Ralf Corsépius  - 1:2.02-1
+- Update to 2.02.
+
 * Sat May 14 2016 Jitka Plesnikova  - 1:2.01-2
 - Perl 5.24 rebuild
 
diff --git a/sources b/sources
index 6f62a9b..ae37cec 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-164a5908bcfb79a8fbbca1a2182416ae  Devel-StackTrace-2.01.tar.gz
+bcc49dc2744d1fae906de0de3df07cca  Devel-StackTrace-2.02.tar.gz
-- 
cgit v0.12



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

corsepiu uploaded Devel-StackTrace-2.02.tar.gz for perl-Devel-StackTrace

[notifications]

bcc49dc2744d1fae906de0de3df07cca  Devel-StackTrace-2.02.tar.gz

http://pkgs.fedoraproject.org/lookaside/pkgs/perl-Devel-StackTrace/Devel-StackTrace-2.02.tar.gz/md5/bcc49dc2744d1fae906de0de3df07cca/Devel-StackTrace-2.02.tar.gz
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: Summary/Minutes from today's FESCo Meeting (2016-12-09)

[Chris Adams]

Once upon a time, Adam Miller  said:
> Meeting started by maxamillion at 16:00:37 UTC. The full logs are
> available at
> https://meetbot.fedoraproject.org/fedora-meeting/2016-12-09/fesco.2016-12-09-16.00.log.html

So, this is a minor request...

I read email in mutt, a terminal-based mail client.  I have it
configured so I can open up URLs in lynx easily.  Recently though, I
can't open the agenda or logs from meetings in lynx.  I don't know when
this happened (I don't try to pull them up all the time, just when I see
something that interests me).

Any chance this could be addressed?
-- 
Chris Adams 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: a diversion into EPEL [was Re: Two more concrete ideas for what a once-yearly+update schedule would look like]

[Igor Gnatenko]

On Dec 9, 2016 5:18 PM, "Matthew Miller"  wrote:

On Fri, Dec 09, 2016 at 11:07:32AM -0500, Colin Walters wrote:
> > Anyways, in the big picture, while I don't speak for everyone on
> > the Project Atomic side, I personally point users at CentOS first,
> > unless I have some reason to think they want Fedora. Something like
> > 80% of Fedora usage hitting the mirrors was desktop systems, right?
> > I don't expect that to change personally.
> Although..except for EPEL.  And how EPEL works should obviously be
> part of this. Things would feel clearer if EPEL lived in CentOS now
> perhaps.

Right; in mirror traffic, EPEL is to Fedora Workstation as Workstation
is to Server. :)

EPEL packages *are* Fedora packages, though — moving the project to
CentOS isn't completely crazy, but would require a lot more integration
and cooperation between the projects.

That's something I'd like to see anyway. I think there are a lot of
opportunities for this with containers and modularity — if you can just
run Fedora containers on CentOS or RHEL *directly*, why bother
rebuilding them? For a lot of the software that's in EPEL, that's
completely sufficient. For other software, where users would like the
version to match more closely the long lifecycle, maybe there could be
a hand-off from Fedora version to CentOS version.

Don't know how modularity is related here. It's just about building distro.
Containers, yeah, but please don't kill Fedora. I don't want to run
container for each software I use. RHEL and CentOS people can struggle, but
don't do this with Fedora users.




--
Matthew Miller

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

Re: Fedora Rawhide-20161209.n.0 compose check report

[Adam Williamson]

On Fri, 2016-12-09 at 15:43 +, Fedora compose checker wrote:
> Missing expected images:
> 
> Kde live x86_64
> Kde live i386
> 
> Failed openQA tests: 11/90 (x86_64), 5/16 (i386), 1/2 (arm)
> 
> New failures (same test did not fail in Rawhide-20161208.n.0):
> 
> ID: 50861 Test: x86_64 Workstation-boot-iso install_default
> URL: https://openqa.fedoraproject.org/tests/50861
> ID: 50862 Test: x86_64 Workstation-boot-iso install_default@uefi
> URL: https://openqa.fedoraproject.org/tests/50862
> ID: 50864 Test: i386 Workstation-boot-iso install_default
> URL: https://openqa.fedoraproject.org/tests/50864

Dependency issue between libvirt and xen;
http://koji.fedoraproject.org/koji/buildinfo?buildID=823764 fixes it.

> ID: 50873 Test: x86_64 Server-dvd-iso install_default_upload
> URL: https://openqa.fedoraproject.org/tests/50873
> ID: 50889 Test: i386 Server-dvd-iso install_default
> URL: https://openqa.fedoraproject.org/tests/50889
> ID: 50941 Test: x86_64 universal install_kickstart_firewall_configured
> URL: https://openqa.fedoraproject.org/tests/50941

These all timed out. But now I take a closer look, there's actually a
bug here: these aren't just taking too long and timing out, the
installer is actually *hanging* during the install process. They get to
 post-install quite fast, then the spinner stops animating at some
point during post-install and they just sit there at a stuck screen
until the timeout is reached. We don't even get logs, because the
system does seem to be hung: when openQA tries to switch to a tty to
gather logs, it fails.

I'll have to run a few installs manually locally and see if I can
reproduce this.

> ID: 50953 Test: i386 universal upgrade_2_desktop_32bit
> URL: https://openqa.fedoraproject.org/tests/50953

This is another case of a problem that's shown up since upgrading the
openQA boxes to Fedora 25: qemu is crashing with some SPICE errors. I
asked the SPICE folks about these and they say they probably indicate
some kind of guest error, but this never happened when the openQA boxes
were on Fedora 24. I'll file a bug on something.

15:23:50.4842 32146 QEMU: 
15:23:50.4843 32146 QEMU: (process:32151): Spice-WARNING **: 
display-channel.h:295:validate_surface: canvas address is 0x561113e0be10 for 0 
(and is NULL)
15:23:50.4844 32146 QEMU: 
15:23:50.4844 32146 QEMU: 
15:23:50.4844 32146 QEMU: (process:32151): Spice-WARNING **: 
display-channel.h:296:validate_surface: failed on 0
15:23:50.4844 32146 QEMU: 
15:23:50.4844 32146 QEMU: (process:32151): Spice-CRITICAL **: 
display-channel.c:1666:display_channel_update: condition 
`validate_surface(display, surface_id)' failed
15:23:50.5387 32146 waitpid for 32151 returned 0

(that's the qemu process dying right at the start of the test).
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Summary/Minutes from today's FESCo Meeting (2016-12-09)

[Adam Miller]

===
#fedora-meeting: FESCO (2016-12-09)
===


Meeting started by maxamillion at 16:00:37 UTC. The full logs are
available at
https://meetbot.fedoraproject.org/fedora-meeting/2016-12-09/fesco.2016-12-09-16.00.log.html
.



Meeting summary
---
* init process  (maxamillion, 16:00:40)

* #1635 F26 Self Contained Changes (Java Security Policy)  (maxamillion,
  16:10:07)
  * LINK: https://pagure.io/fesco/issue/1635#comment-43494
(maxamillion, 16:10:07)
  * AGREED: Approve F26 Self Contained Change Java Security Policy (+1:
5, -1: 0, +0: 0)  (maxamillion, 16:18:40)

* #1646 No appropriate sudo directory for user scripts  (maxamillion,
  16:18:50)
  * LINK: https://pagure.io/fesco/issue/1646   (maxamillion, 16:18:50)
  * AGREED: Defer decision of Issue #1646 until 2016-12-16
(maxamillion, 16:21:28)

* #1635 F26 Self contained Changes - Zend Framework 3  (maxamillion,
  16:21:35)
  * LINK: https://pagure.io/fesco/issue/1635#comment-45817
(maxamillion, 16:21:35)
  * AGREED: F26 Self Contained Change - Zend Framework 3 (+1: 6, -1: 0,
+0: 0)  (maxamillion, 16:24:53)

* #1652 i686 is not on primary mirror location  (maxamillion, 16:25:21)
  * LINK: https://pagure.io/fesco/issue/1652   (maxamillion, 16:25:21)
  * AGREED: Proposal: FESCo will draft an announcement for the demotion
of i686 to an atlernative architecture and seek Council input before
publishing. Secondly, FESCo will draft an architecture demotion
process. (+1: 5, -1: 0, +0: 0)  (maxamillion, 16:46:39)

* Next week's chair  (maxamillion, 16:48:21)
  * jsmith to chair FESCo Meeting 2016-12-16  (maxamillion, 16:49:26)

* Open Floor  (maxamillion, 16:49:37)
  * Reminder that 5 FESCo seats are open for elections now
https://fedoraproject.org/wiki/Elections  (maxamillion, 16:50:27)
  * AGREED: Cancel FESCo Meetings on 2016-12-23 and 2016-12-30
(maxamillion, 17:00:51)

Meeting ended at 17:02:03 UTC.




Action Items






Action Items, by person
---
* **UNASSIGNED**
  * (none)




People Present (lines said)
---
* maxamillion (88)
* jwb (43)
* Rathann (27)
* jsmith (21)
* zodbot (15)
* sgallagh (13)
* dgilmore (3)
* nirik (0)
* paragan (0)
* kalev (0)




Generated by `MeetBot`_ 0.1.4

.. _`MeetBot`: http://wiki.debian.org/MeetBot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: a diversion into EPEL [was Re: Two more concrete ideas for what a once-yearly+update schedule would look like]

[Stephen John Smoogen]

On 9 December 2016 at 11:42, Nikos Mavrogiannopoulos  wrote:
> On Fri, 2016-12-09 at 11:17 -0500, Matthew Miller wrote:
>> On Fri, Dec 09, 2016 at 11:07:32AM -0500, Colin Walters wrote:
>> > > Anyways, in the big picture, while I don't speak for everyone on
>> > > the Project Atomic side, I personally point users at CentOS
>> > > first,
>> > > unless I have some reason to think they want Fedora. Something
>> > > like
>> > > 80% of Fedora usage hitting the mirrors was desktop systems,
>> > > right?
>> > > I don't expect that to change personally.
>> >
>> > Although..except for EPEL.  And how EPEL works should obviously be
>> > part of this. Things would feel clearer if EPEL lived in CentOS now
>> > perhaps.
>> Right; in mirror traffic, EPEL is to Fedora Workstation as
>> Workstation
>> is to Server. :)
>>
>> EPEL packages *are* Fedora packages, though — moving the project to
>> CentOS isn't completely crazy, but would require a lot more
>> integration and cooperation between the projects.
>
> Right, it would have to be easy for maintainers to contribute in both.
>
>> That's something I'd like to see anyway. I think there are a lot of
>> opportunities for this with containers and modularity — if you can
>> just run Fedora containers on CentOS or RHEL *directly*, why bother
>> rebuilding them?
>
> I agree that can be an option in some cases, however, I can think of a
> few cases which it cannot. (a) running centos7 on a container, without
> epel you cannot have that additional software, (b) kernel features
> which are available in Fedora but not in centos7, may cause the
> software not to work if they don't detect the features on runtime, (c)
> simplicity; not having to go through the path of having to run special
> tools for scanning vulnerabilities in running containers.

There is also the fact that I doubt that containers and modularity are
what EL customers are aware they want anytime soon. The majority of
EPEL users are on RHEL-6 (and that number is still growing as they
move from RHEL-5 to RHEL-6). RHEL-7 is growing but only at a  rate
which shows the conservative nature of most EL sites.

I expect that containers/modularity etc will become something EL users
want after Fedora considers it not only old but is actively looking to
replace it with some new shiney paradigm that will solve the problems
left from containers.


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



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

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

[Adam Williamson]

On Fri, 2016-12-09 at 11:03 -0500, Matthew Miller wrote:
> So, *did* you feel that the F25 cycle felt compressed? If we're close
> enough to the theoretical-world above that we feel like we can do, say,
> four month cycles to stay on track without experiencing (particular)
> pain, maybe that's okay.

This seems like an impossible question to answer. Our release cycles
are entirely arbitrary; they're precisely what we say they are. So I'm
not sure how to say whether one "feels compressed", or understand how
"four month cycles" would make us "stay on track". *What* track would
we be staying on?

When I mentioned shorter cycles, I wasn't suggesting we do all the same
stuff we do now, only in a smaller space of time. That would be awful.
I was honestly thinking more about far more automated and less
significant 'release events'. But really, my larger point is that what
you're proposing sounded like a large amount of work for (particularly)
release engineering, but came with no clear justification beyond "I
have an unquantifiable feeling that we can get better press coverage if
we do one release a year", which is extremely thin. At a bare minimum,
any significant release cycle change needs to come with a ground-up and
coherent justification of why *that* is the best way, right now, for
the Fedora project to produce little baby Fedoras.

It also seems bizarre to be having a 'release' conversation that
doesn't really seem to tie in at all with what's going on with
Modularity and Factory 2.0...since I thought those were the primary
drivers of planned major change to how we deliver Fedora.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

[Adam Williamson]

On Fri, 2016-12-09 at 13:18 +0100, Michael Schwendt wrote:
> The apparently random flow of poorly tested "rushed out" updates



I've had automatic updates, of all kinds, turned on on all of my
servers for at least the last four releases, and can think of maybe one
time one of them broke? This seems like a severe over-statement.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: a diversion into EPEL [was Re: Two more concrete ideas for what a once-yearly+update schedule would look like]

[Nikos Mavrogiannopoulos]

On Fri, 2016-12-09 at 11:17 -0500, Matthew Miller wrote:
> On Fri, Dec 09, 2016 at 11:07:32AM -0500, Colin Walters wrote:
> > > Anyways, in the big picture, while I don't speak for everyone on
> > > the Project Atomic side, I personally point users at CentOS
> > > first,
> > > unless I have some reason to think they want Fedora. Something
> > > like
> > > 80% of Fedora usage hitting the mirrors was desktop systems,
> > > right?
> > > I don't expect that to change personally.
> > 
> > Although..except for EPEL.  And how EPEL works should obviously be
> > part of this. Things would feel clearer if EPEL lived in CentOS now
> > perhaps.
> Right; in mirror traffic, EPEL is to Fedora Workstation as
> Workstation
> is to Server. :)
> 
> EPEL packages *are* Fedora packages, though — moving the project to
> CentOS isn't completely crazy, but would require a lot more
> integration and cooperation between the projects.

Right, it would have to be easy for maintainers to contribute in both.

> That's something I'd like to see anyway. I think there are a lot of
> opportunities for this with containers and modularity — if you can
> just run Fedora containers on CentOS or RHEL *directly*, why bother
> rebuilding them? 

I agree that can be an option in some cases, however, I can think of a
few cases which it cannot. (a) running centos7 on a container, without
epel you cannot have that additional software, (b) kernel features
which are available in Fedora but not in centos7, may cause the
software not to work if they don't detect the features on runtime, (c)
simplicity; not having to go through the path of having to run special
tools for scanning vulnerabilities in running containers.

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

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

[Josh Boyer]

On Fri, Dec 9, 2016 at 11:30 AM, Zbigniew Jędrzejewski-Szmek
 wrote:
> On Fri, Dec 09, 2016 at 01:18:31PM +0100, Michael Schwendt wrote:
>> On Thu, 8 Dec 2016 19:45:55 +0100, Christian Dersch wrote:
>>
>> > On 12/08/2016 07:26 PM, Dennis Gilmore wrote:
>> > > I would like to see us stop pushing non security updates to updates from
>> > > updates-testing entirely and do it in monthly batches instead.  we would 
>> > > push
>> > > daily security fixes and updates-testing.  However this would make 
>> > > atomic host
>> > > 2 week releases much less useful, as there would be no updates except 
>> > > for once
>> > > a month.
>> > >
>> > >
>> > What do you expect from monthly batches? I *really* don't like things
>> > like "patchdays". Besides security fixes there are also other situations
>> > like small but annoying bugs… IMHO the current model with updates repo
>> > works fine, I see no reason to make a change here.
>>
>> The apparently random flow of poorly tested "rushed out" updates is a
>> major drawback of Fedora's current release process. It reminds me too much
>> of the infamous dumping ground for packages.
>>
>> We jump over many hops to release a "stable" distribution. Then we take it
>> apart as we unleash more and more updates, which move away from what has
>> gone through the Alpha/Beta freeze and testing process. Too many packages
>> get changed and invalidate all the testing of previous releases.
>>
>> We also change the repo metadata too often due to this flood of updates.
>> Users already wonder why the metadata need to be refreshed so often? One
>> packager pushes a minor version update for some niche market font, for
>> example, and the repo changes for everyone.
>
> A strawman proposal: when updates are created, we now fill out a "severity"
> field. Let's make use of this field, and batch the way that updates are
> pushed out from updates-testing to updates:
> - urgent → right now (as fast as we can make it)
> - high → daily
> - medium → up to a week delay
> - low/unspecified → next biweekly batch
>
> (I put unspecified together with low, so that people learn to fill out the 
> field ;))

I did something like this many moons ago.  In the end, it was a wash.
Push frequency without repository separation basically means the
frequency is irrelevant because when the updates show up is entirely
dependent upon when the user runs 'dnf update' or similar.

> This would make the updates process nicer for users without
> adding much more complexity.

That is actually untrue because of how our updates backend process
works.  Doing it this way requires multiple pushes for the same
cumulative set of updates and it requires tooling to be written to do
the filtering.  So it is less complex for users, but more work for
those processing the updates.

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

corsepiu pushed to perl-HTML-Format (f24). "Update to HTML-Formatter-2.16. (..more)"

[notifications]

From 79fd51a1eafc9d52adc41f992777bd7c27c795e5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ralf=20Cors=C3=A9pius?= 
Date: Fri, 9 Dec 2016 17:31:00 +0100
Subject: Update to HTML-Formatter-2.16.

- Reflect upstream having switched to ExtUtils::MakeMaker.
- Spec cleanup.
---
 .gitignore|  2 +-
 perl-HTML-Format.spec | 20 
 sources   |  2 +-
 3 files changed, 14 insertions(+), 10 deletions(-)

diff --git a/.gitignore b/.gitignore
index e3257bc..8641a9c 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1 @@
-/HTML-Formatter-2.14.tar.gz
+/HTML-Formatter-2.16.tar.gz
diff --git a/perl-HTML-Format.spec b/perl-HTML-Format.spec
index afeaafb..8314d72 100644
--- a/perl-HTML-Format.spec
+++ b/perl-HTML-Format.spec
@@ -1,8 +1,8 @@
 # As of release 2.13, upstream renamed the package into HTML-Formatter
 
 Name:   perl-HTML-Format
-Version:2.14
-Release:4%{?dist}
+Version:2.16
+Release:1%{?dist}
 Summary:HTML formatter modules
 
 %if "%{version}" > "2.12"
@@ -12,7 +12,6 @@ Summary:HTML formatter modules
 %global tarname HTML-Format
 %endif
 
-Group:  Development/Libraries
 License:GPL+ or Artistic
 URL:http://search.cpan.org/dist/%{tarname}/
 Source0:
http://www.cpan.org/authors/id/N/NI/NIGELM/%{tarname}-%{version}.tar.gz
@@ -31,11 +30,11 @@ BuildRequires:  perl(Font::AFM) >= 1.17
 BuildRequires:  perl(HTML::Element) >= 3.15
 BuildRequires:  perl(HTML::TreeBuilder)
 BuildRequires:  perl(IO::File)
-BuildRequires:  perl(Module::Build)
 BuildRequires:  perl(Test::CPAN::Meta)
 BuildRequires:  perl(Test::EOL)
 BuildRequires:  perl(Test::More) >= 0.96
 BuildRequires:  perl(Test::NoTabs)
+BuildRequires:  perl(Test::Warnings)
 
 BuildRequires:  perl(Font::Metrics::Courier)
 BuildRequires:  perl(Font::Metrics::CourierBold)
@@ -85,15 +84,15 @@ A collection of modules that formats HTML as plaintext, 
PostScript or RTF.
 %setup -q -n %{tarname}-%{version}
 
 %build
-%{__perl} Build.PL installdirs=vendor
-./Build
+%{__perl} Makefile.PL installdirs=vendor NO_PACKLIST=1
+%{__make} %{?_smp_mflags}
 
 %install
-./Build install destdir=$RPM_BUILD_ROOT create_packlist=0
+%{__make} pure_install DESTDIR=$RPM_BUILD_ROOT
 %{_fixperms} $RPM_BUILD_ROOT/*
 
 %check
-./Build test
+%{__make} test
 
 %files -n perl-%{tarname}
 %doc Changes README
@@ -102,6 +101,11 @@ A collection of modules that formats HTML as plaintext, 
PostScript or RTF.
 %{_mandir}/man3/HTML*
 
 %changelog
+* Fri Dec 09 2016 Ralf Corsépius  - 2.16-1
+- Update to HTML-Formatter-2.16.
+- Reflect upstream having switched to ExtUtils::MakeMaker.
+- Spec cleanup.
+
 * Tue May 17 2016 Jitka Plesnikova  - 2.14-4
 - Perl 5.24 rebuild
 
diff --git a/sources b/sources
index 9cb1326..96efb13 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-af35f37c2114a355923d924aa8536253  HTML-Formatter-2.14.tar.gz
+16adca9bc55dbff85daa6c0ae74ff730  HTML-Formatter-2.16.tar.gz
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl-HTML-Format.git/commit/?h=f24=79fd51a1eafc9d52adc41f992777bd7c27c795e5
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

corsepiu pushed to perl-HTML-Format (f24). "Mandatory Perl build-requires added "

[notifications]

From 0a7393c8f36f8479cdc9c27332c5ab86b2cfbfea Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= 
Date: Fri, 24 Jun 2016 10:32:45 +0200
Subject: Mandatory Perl build-requires added
 

---
 perl-HTML-Format.spec | 1 +
 1 file changed, 1 insertion(+)

diff --git a/perl-HTML-Format.spec b/perl-HTML-Format.spec
index 2fee163..afeaafb 100644
--- a/perl-HTML-Format.spec
+++ b/perl-HTML-Format.spec
@@ -19,6 +19,7 @@ Source0:
http://www.cpan.org/authors/id/N/NI/NIGELM/%{tarname}-%{version}
 Requires:  perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo $version))
 
 BuildArch:  noarch
+BuildRequires:  perl-generators
 BuildRequires:  perl(base)
 BuildRequires:  perl(Carp)
 BuildRequires:  perl(Data::Dumper)
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl-HTML-Format.git/commit/?h=f24=0a7393c8f36f8479cdc9c27332c5ab86b2cfbfea
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

[Stephen John Smoogen]

On 9 December 2016 at 11:07, Colin Walters  wrote:
> On Thu, Dec 8, 2016, at 09:26 PM, Colin Walters wrote:
>
>> Anyways, in the big picture, while I don't speak for everyone on the Project 
>> Atomic side,
>> I personally point users at CentOS first, unless I have some reason to think 
>> they want Fedora.
>> Something like 80% of Fedora usage hitting the mirrors was desktop systems, 
>> right?
>> I don't expect that to change personally.
>
> Although..except for EPEL.  And how EPEL works should obviously be part of 
> this.
> Things would feel clearer if EPEL lived in CentOS now perhaps.

It might however EPEL relies on a large amount of infrastructure that
is tied deep in Fedora. Trying to 'move' it over to CentOS is not easy
without a lot of that infrastructure also moving over to CentOS or
starting from scratch over in CentOS. It also would take a lot of time
and effort that no one wants to fund but would like people to do for
them for free. That and every time it is brought up, various groups
want to use it as the time to restart every argument they lost
sometime in the past from repotags to putting it all in /opt to the
logo looks like a horse's ass.

[By the way, this isn't a "it shouldn't happen" as much as "beware the
surgery you are trying to do.. pus ridden gangrene will quickly set in
if not done well and will probably show up anyway."]

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



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

corsepiu pushed to perl-HTML-Format (f24). "Cleanup merger."

[notifications]

From ce5e0a4f9a36d216bc448bec0f2dbd0cdcd5d864 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ralf=20Cors=C3=A9pius?= 
Date: Fri, 9 Dec 2016 17:36:57 +0100
Subject: Cleanup merger.

---
 perl-HTML-Format.spec | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/perl-HTML-Format.spec b/perl-HTML-Format.spec
index 8314d72..2dc45db 100644
--- a/perl-HTML-Format.spec
+++ b/perl-HTML-Format.spec
@@ -106,9 +106,6 @@ A collection of modules that formats HTML as plaintext, 
PostScript or RTF.
 - Reflect upstream having switched to ExtUtils::MakeMaker.
 - Spec cleanup.
 
-* Tue May 17 2016 Jitka Plesnikova  - 2.14-4
-- Perl 5.24 rebuild
-
 * Thu Feb 04 2016 Fedora Release Engineering  - 
2.14-3
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_24_Mass_Rebuild
 
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl-HTML-Format.git/commit/?h=f24=ce5e0a4f9a36d216bc448bec0f2dbd0cdcd5d864
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

corsepiu pushed to perl-HTML-Format (f24). "Perl 5.24 rebuild"

[notifications]

From 8447b997da3ecd4d8d4215daae3f0eb1d91921a3 Mon Sep 17 00:00:00 2001
From: Jitka Plesnikova 
Date: Tue, 17 May 2016 11:52:42 +0200
Subject: Perl 5.24 rebuild

---
 perl-HTML-Format.spec | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/perl-HTML-Format.spec b/perl-HTML-Format.spec
index 2e6884c..2fee163 100644
--- a/perl-HTML-Format.spec
+++ b/perl-HTML-Format.spec
@@ -2,7 +2,7 @@
 
 Name:   perl-HTML-Format
 Version:2.14
-Release:3%{?dist}
+Release:4%{?dist}
 Summary:HTML formatter modules
 
 %if "%{version}" > "2.12"
@@ -101,6 +101,9 @@ A collection of modules that formats HTML as plaintext, 
PostScript or RTF.
 %{_mandir}/man3/HTML*
 
 %changelog
+* Tue May 17 2016 Jitka Plesnikova  - 2.14-4
+- Perl 5.24 rebuild
+
 * Thu Feb 04 2016 Fedora Release Engineering  - 
2.14-3
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_24_Mass_Rebuild
 
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl-HTML-Format.git/commit/?h=f24=8447b997da3ecd4d8d4215daae3f0eb1d91921a3
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

corsepiu pushed to perl-HTML-Format (f25). "Update to HTML-Formatter-2.16. (..more)"

[notifications]

From 79fd51a1eafc9d52adc41f992777bd7c27c795e5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ralf=20Cors=C3=A9pius?= 
Date: Fri, 9 Dec 2016 17:31:00 +0100
Subject: Update to HTML-Formatter-2.16.

- Reflect upstream having switched to ExtUtils::MakeMaker.
- Spec cleanup.
---
 .gitignore|  2 +-
 perl-HTML-Format.spec | 20 
 sources   |  2 +-
 3 files changed, 14 insertions(+), 10 deletions(-)

diff --git a/.gitignore b/.gitignore
index e3257bc..8641a9c 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1 @@
-/HTML-Formatter-2.14.tar.gz
+/HTML-Formatter-2.16.tar.gz
diff --git a/perl-HTML-Format.spec b/perl-HTML-Format.spec
index afeaafb..8314d72 100644
--- a/perl-HTML-Format.spec
+++ b/perl-HTML-Format.spec
@@ -1,8 +1,8 @@
 # As of release 2.13, upstream renamed the package into HTML-Formatter
 
 Name:   perl-HTML-Format
-Version:2.14
-Release:4%{?dist}
+Version:2.16
+Release:1%{?dist}
 Summary:HTML formatter modules
 
 %if "%{version}" > "2.12"
@@ -12,7 +12,6 @@ Summary:HTML formatter modules
 %global tarname HTML-Format
 %endif
 
-Group:  Development/Libraries
 License:GPL+ or Artistic
 URL:http://search.cpan.org/dist/%{tarname}/
 Source0:
http://www.cpan.org/authors/id/N/NI/NIGELM/%{tarname}-%{version}.tar.gz
@@ -31,11 +30,11 @@ BuildRequires:  perl(Font::AFM) >= 1.17
 BuildRequires:  perl(HTML::Element) >= 3.15
 BuildRequires:  perl(HTML::TreeBuilder)
 BuildRequires:  perl(IO::File)
-BuildRequires:  perl(Module::Build)
 BuildRequires:  perl(Test::CPAN::Meta)
 BuildRequires:  perl(Test::EOL)
 BuildRequires:  perl(Test::More) >= 0.96
 BuildRequires:  perl(Test::NoTabs)
+BuildRequires:  perl(Test::Warnings)
 
 BuildRequires:  perl(Font::Metrics::Courier)
 BuildRequires:  perl(Font::Metrics::CourierBold)
@@ -85,15 +84,15 @@ A collection of modules that formats HTML as plaintext, 
PostScript or RTF.
 %setup -q -n %{tarname}-%{version}
 
 %build
-%{__perl} Build.PL installdirs=vendor
-./Build
+%{__perl} Makefile.PL installdirs=vendor NO_PACKLIST=1
+%{__make} %{?_smp_mflags}
 
 %install
-./Build install destdir=$RPM_BUILD_ROOT create_packlist=0
+%{__make} pure_install DESTDIR=$RPM_BUILD_ROOT
 %{_fixperms} $RPM_BUILD_ROOT/*
 
 %check
-./Build test
+%{__make} test
 
 %files -n perl-%{tarname}
 %doc Changes README
@@ -102,6 +101,11 @@ A collection of modules that formats HTML as plaintext, 
PostScript or RTF.
 %{_mandir}/man3/HTML*
 
 %changelog
+* Fri Dec 09 2016 Ralf Corsépius  - 2.16-1
+- Update to HTML-Formatter-2.16.
+- Reflect upstream having switched to ExtUtils::MakeMaker.
+- Spec cleanup.
+
 * Tue May 17 2016 Jitka Plesnikova  - 2.14-4
 - Perl 5.24 rebuild
 
diff --git a/sources b/sources
index 9cb1326..96efb13 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-af35f37c2114a355923d924aa8536253  HTML-Formatter-2.14.tar.gz
+16adca9bc55dbff85daa6c0ae74ff730  HTML-Formatter-2.16.tar.gz
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl-HTML-Format.git/commit/?h=f25=79fd51a1eafc9d52adc41f992777bd7c27c795e5
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

corsepiu pushed to perl-HTML-Format (master). "Update to HTML-Formatter-2.16. (..more)"

[notifications]

From 79fd51a1eafc9d52adc41f992777bd7c27c795e5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ralf=20Cors=C3=A9pius?= 
Date: Fri, 9 Dec 2016 17:31:00 +0100
Subject: Update to HTML-Formatter-2.16.

- Reflect upstream having switched to ExtUtils::MakeMaker.
- Spec cleanup.
---
 .gitignore|  2 +-
 perl-HTML-Format.spec | 20 
 sources   |  2 +-
 3 files changed, 14 insertions(+), 10 deletions(-)

diff --git a/.gitignore b/.gitignore
index e3257bc..8641a9c 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1 @@
-/HTML-Formatter-2.14.tar.gz
+/HTML-Formatter-2.16.tar.gz
diff --git a/perl-HTML-Format.spec b/perl-HTML-Format.spec
index afeaafb..8314d72 100644
--- a/perl-HTML-Format.spec
+++ b/perl-HTML-Format.spec
@@ -1,8 +1,8 @@
 # As of release 2.13, upstream renamed the package into HTML-Formatter
 
 Name:   perl-HTML-Format
-Version:2.14
-Release:4%{?dist}
+Version:2.16
+Release:1%{?dist}
 Summary:HTML formatter modules
 
 %if "%{version}" > "2.12"
@@ -12,7 +12,6 @@ Summary:HTML formatter modules
 %global tarname HTML-Format
 %endif
 
-Group:  Development/Libraries
 License:GPL+ or Artistic
 URL:http://search.cpan.org/dist/%{tarname}/
 Source0:
http://www.cpan.org/authors/id/N/NI/NIGELM/%{tarname}-%{version}.tar.gz
@@ -31,11 +30,11 @@ BuildRequires:  perl(Font::AFM) >= 1.17
 BuildRequires:  perl(HTML::Element) >= 3.15
 BuildRequires:  perl(HTML::TreeBuilder)
 BuildRequires:  perl(IO::File)
-BuildRequires:  perl(Module::Build)
 BuildRequires:  perl(Test::CPAN::Meta)
 BuildRequires:  perl(Test::EOL)
 BuildRequires:  perl(Test::More) >= 0.96
 BuildRequires:  perl(Test::NoTabs)
+BuildRequires:  perl(Test::Warnings)
 
 BuildRequires:  perl(Font::Metrics::Courier)
 BuildRequires:  perl(Font::Metrics::CourierBold)
@@ -85,15 +84,15 @@ A collection of modules that formats HTML as plaintext, 
PostScript or RTF.
 %setup -q -n %{tarname}-%{version}
 
 %build
-%{__perl} Build.PL installdirs=vendor
-./Build
+%{__perl} Makefile.PL installdirs=vendor NO_PACKLIST=1
+%{__make} %{?_smp_mflags}
 
 %install
-./Build install destdir=$RPM_BUILD_ROOT create_packlist=0
+%{__make} pure_install DESTDIR=$RPM_BUILD_ROOT
 %{_fixperms} $RPM_BUILD_ROOT/*
 
 %check
-./Build test
+%{__make} test
 
 %files -n perl-%{tarname}
 %doc Changes README
@@ -102,6 +101,11 @@ A collection of modules that formats HTML as plaintext, 
PostScript or RTF.
 %{_mandir}/man3/HTML*
 
 %changelog
+* Fri Dec 09 2016 Ralf Corsépius  - 2.16-1
+- Update to HTML-Formatter-2.16.
+- Reflect upstream having switched to ExtUtils::MakeMaker.
+- Spec cleanup.
+
 * Tue May 17 2016 Jitka Plesnikova  - 2.14-4
 - Perl 5.24 rebuild
 
diff --git a/sources b/sources
index 9cb1326..96efb13 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-af35f37c2114a355923d924aa8536253  HTML-Formatter-2.14.tar.gz
+16adca9bc55dbff85daa6c0ae74ff730  HTML-Formatter-2.16.tar.gz
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl-HTML-Format.git/commit/?h=master=79fd51a1eafc9d52adc41f992777bd7c27c795e5
___
perl-devel mailing list -- perl-de...@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org