File perl5i-v2.13.1.tar.gz uploaded to lookaside cache by pghmcfc
A file has been added to the lookaside cache for perl-perl5i: c69d503122e7bd242ddbe2fc2c464018 perl5i-v2.13.1.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-perl5i] Update to 2.13.1
commit 753007950a80657ba7772c8ee0be2ed583654839
Author: Paul Howarth p...@city-fan.org
Date: Wed Jan 7 09:42:21 2015 +
Update to 2.13.1
- New upstream release 2.13.1
- Upgrade utf8::all requirement to get consistent @ARGV behaviour
- The latest autodie is recommended for load time and memory usage
improvements (GH#284)
- Change how we import utf8::all so @ARGV is translated appropriately
(GH#279)
- Update autobox to avoid segfaults during global destruction (GH#283,
CPAN RT#71777)
...tests-broken-with-utf8-all-0.013-or-later.patch | 31 ---
perl-perl5i.spec | 41
sources|2 +-
3 files changed, 26 insertions(+), 48 deletions(-)
---
diff --git a/perl-perl5i.spec b/perl-perl5i.spec
index bffa6bb..a3fcd13 100644
--- a/perl-perl5i.spec
+++ b/perl-perl5i.spec
@@ -1,12 +1,11 @@
Name: perl-perl5i
Summary: Fix as much of Perl 5 as possible in one pragma
-Version: 2.13.0
-Release: 4%{?dist}
+Version: 2.13.1
+Release: 1%{?dist}
License: GPL+ or Artistic
Group: Development/Libraries
URL: https://metacpan.org/release/perl5i
Source0:
http://cpan.metacpan.org/authors/id/M/MS/MSCHWERN/perl5i-v%{version}.tar.gz
-Patch0:
0001-Fix-ARGV-tests-broken-with-utf8-all-0.013-or-later.patch
# Module Build
BuildRequires: perl
BuildRequires: perl(lib)
@@ -31,6 +30,7 @@ BuildRequires:perl(File::Spec)
BuildRequires: perl(Hash::FieldHash) = 0.06
BuildRequires: perl(Hash::Merge::Simple) = 0.04
BuildRequires: perl(Hash::StoredIterator) = 0.007
+BuildRequires: perl(Import::Into) = 1.002003
BuildRequires: perl(IO::Handle)
BuildRequires: perl(IPC::System::Simple) = 1.18
BuildRequires: perl(JSON) = 2.17
@@ -49,7 +49,7 @@ BuildRequires:perl(Time::y2038)
BuildRequires: perl(Try::Tiny) = 0.02
BuildRequires: perl(Want) = 0.18
BuildRequires: perl(YAML::Any) = 0.70
-BuildRequires: perl(autobox) = 2.70
+BuildRequires: perl(autobox) = 2.80
BuildRequires: perl(autobox::Core) = 1.0
BuildRequires: perl(autobox::List::Util) = 20090629
BuildRequires: perl(autobox::dump) = 20090426
@@ -64,7 +64,7 @@ BuildRequires:perl(open)
BuildRequires: perl(overload)
BuildRequires: perl(parent) = 0.221
BuildRequires: perl(true::VERSION) = 0.16
-BuildRequires: perl(utf8::all) = 0.002
+BuildRequires: perl(utf8::all) = 0.015
BuildRequires: perl(version) = 0.77
# Test Suite
BuildRequires: perl(Config)
@@ -95,6 +95,7 @@ Requires: perl(File::Spec)
Requires: perl(Hash::FieldHash) = 0.06
Requires: perl(Hash::Merge::Simple) = 0.04
Requires: perl(Hash::StoredIterator) = 0.007
+Requires: perl(Import::Into) = 1.002003
Requires: perl(IPC::System::Simple) = 1.18
Requires: perl(JSON) = 2.17
Requires: perl(List::MoreUtils) = 0.22
@@ -108,7 +109,7 @@ Requires: perl(Text::Wrap) = 2009.0305
Requires: perl(Try::Tiny) = 0.02
Requires: perl(Want) = 0.18
Requires: perl(YAML::Any) = 0.70
-Requires: perl(autobox) = 2.70
+Requires: perl(autobox) = 2.80
Requires: perl(autobox::Core) = 1.0
Requires: perl(autobox::List::Util) = 20090629
Requires: perl(autobox::dump) = 20090426
@@ -118,13 +119,15 @@ Requires: perl(if)
Requires: perl(indirect) = 0.24
Requires: perl(parent) = 0.221
Requires: perl(true::VERSION) = 0.16
-Requires: perl(utf8::all) = 0.002
+Requires: perl(utf8::all) = 0.015
# Filter underspecified dependencies
%global __requires_exclude ^perl\\(CLASS\\)$
%global __requires_exclude %__requires_exclude|^perl\\(Carp::Fix::1_25\\)$
+%global __requires_exclude
%__requires_exclude|^perl\\(Devel::Declare::MethodInstaller::Simple\\)$
%global __requires_exclude %__requires_exclude|^perl\\(Hash::FieldHash\\)$
%global __requires_exclude %__requires_exclude|^perl\\(Hash::StoredIterator\\)$
+%global __requires_exclude %__requires_exclude|^perl\\(Import::Into\\)$
%global __requires_exclude %__requires_exclude|^perl\\(Module::Load\\)$
%global __requires_exclude %__requires_exclude|^perl\\(Try::Tiny\\)$
%global __requires_exclude %__requires_exclude|^perl\\(Want\\)$
@@ -153,10 +156,6 @@ like a branch you control) and implement it yourself.
%prep
%setup -q -n perl5i-v%{version}
-# Upstream fix for compatibility with utf8::all ≳ 0.013
-# https://github.com/evalEmpire/perl5i/pull/280
-%patch0 -p1
-
%build
perl Build.PL --installdirs=vendor --optimize=%{optflags}
./Build
@@ -175,13 +174,23 @@ perl Build.PL --installdirs=vendor
--optimize=%{optflags}
%{perl_vendorlib}/perl5i.pm
%{perl_vendorlib}/perl5i/
%doc %{perl_vendorlib}/perl5ifaq.pod
-%{_mandir}/man3/perl5i.3pm*
-%{_mandir}/man3/perl5i::Meta.3pm*
-%{_mandir}/man3/perl5i::Signature.3pm*
-%{_mandir}/man3/perl5i::latest.3pm*
-%{_mandir}/man3/perl5ifaq.3pm*
+%{_mandir}/man3/perl5i.3*
[perl-perl5i] Created tag perl-perl5i-2.13.1-1.fc22
The lightweight tag 'perl-perl5i-2.13.1-1.fc22' was created pointing to: 7530079... Update to 2.13.1 -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Module-Path/f20] Make the SPEC compatible with F20
commit 325417acdb496776acd28b59d20a498f508f26fb
Author: Petr Šabata con...@redhat.com
Date: Wed Jan 7 11:01:25 2015 +0100
Make the SPEC compatible with F20
perl-Module-Path.spec |8
1 files changed, 4 insertions(+), 4 deletions(-)
---
diff --git a/perl-Module-Path.spec b/perl-Module-Path.spec
index b1f5a36..e3d244f 100644
--- a/perl-Module-Path.spec
+++ b/perl-Module-Path.spec
@@ -8,7 +8,7 @@ URL:http://search.cpan.org/dist/Module-Path/
Source0:
http://www.cpan.org/authors/id/N/NE/NEILB/Module-Path-%{version}.tar.gz
BuildArch: noarch
BuildRequires: perl
-BuildRequires: perl(ExtUtils::MakeMaker) = 6.76
+BuildRequires: perl(ExtUtils::MakeMaker)
BuildRequires: perl(strict)
BuildRequires: perl(warnings)
# Run-time:
@@ -35,19 +35,19 @@ any symbolic links.
sed -i -e '1s|^#!.*|#!%{__perl}|' bin/mpath
%build
-perl Makefile.PL INSTALLDIRS=vendor NO_PACKLIST=1
+perl Makefile.PL INSTALLDIRS=vendor
make %{?_smp_mflags}
%install
make pure_install DESTDIR=$RPM_BUILD_ROOT
+find %{buildroot} -type f -name .packlist -exec rm -f {} +
%{_fixperms} $RPM_BUILD_ROOT/*
%check
make test
%files
-%license LICENSE
-%doc Changes README
+%doc Changes README LICENSE
%{_bindir}/*
%{perl_vendorlib}/*
%{_mandir}/man1/*
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File Test-Simple-1.001014.tar.gz uploaded to lookaside cache by pghmcfc
A file has been added to the lookaside cache for perl-Test-Simple: db7f57fd595e3e1c93c972307a88fa6e Test-Simple-1.001014.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Test-Simple] Update to 1.001014
commit 11aedb5e1fea879359662d3604a58af0a5511b72
Author: Paul Howarth p...@city-fan.org
Date: Wed Jan 7 10:17:02 2015 +
Update to 1.001014
- New upstream release 1.001014
- Fix a unit test that broke on some platforms with spaces in the $^X path
- Add a test to ensure that the Changes file is updated
perl-Test-Simple.spec | 12 +---
sources |2 +-
2 files changed, 10 insertions(+), 4 deletions(-)
---
diff --git a/perl-Test-Simple.spec b/perl-Test-Simple.spec
index 99c2c40..ec695ea 100644
--- a/perl-Test-Simple.spec
+++ b/perl-Test-Simple.spec
@@ -1,10 +1,10 @@
# For versioned provides
-%global T_T_Version 0.112
-%global T_u_o_Version 0.14
+%global T_T_Version 0.114
+%global T_u_o_Version 0.16
Name: perl-Test-Simple
Summary:Basic utilities for writing tests
-Version:1.001012
+Version:1.001014
Release:1%{?dist}
License:GPL+ or Artistic
URL:http://search.cpan.org/dist/Test-Simple
@@ -36,6 +36,7 @@ BuildRequires: perl(File::Basename)
BuildRequires: perl(File::Spec)
BuildRequires: perl(IO::Pipe)
BuildRequires: perl(lib)
+BuildRequires: perl(List::Util)
BuildRequires: perl(POSIX)
BuildRequires: perl(threads)
# Runtime
@@ -110,6 +111,11 @@ make test AUTHOR_TESTING=1
%{_mandir}/man3/Test::use::ok.3*
%changelog
+* Wed Jan 7 2015 Paul Howarth p...@city-fan.org - 1.001014-1
+- Update to 1.001014
+ - Fix a unit test that broke on some platforms with spaces in the $^X path
+ - Add a test to ensure that the Changes file is updated
+
* Wed Dec 24 2014 Paul Howarth p...@city-fan.org - 1.001012-1
- Update to 1.001012
- Move test that was dropped in the wrong directory
diff --git a/sources b/sources
index 4fa8474..256c630 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-6782dbc93e7eb267e81e14aa0f3b8fa7 Test-Simple-1.001012.tar.gz
+db7f57fd595e3e1c93c972307a88fa6e Test-Simple-1.001014.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Test-Simple] Created tag perl-Test-Simple-1.001014-1.fc22
The lightweight tag 'perl-Test-Simple-1.001014-1.fc22' was created pointing to: 11aedb5... Update to 1.001014 -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: System-wide crypto policy transition tracker
On Tue, 2015-01-06 at 18:41 +0100, Till Maas wrote: On Tue, Jan 06, 2015 at 04:20:55PM +0100, Nikos Mavrogiannopoulos wrote: I've created a transition tracker to system-wide crypto policy at: https://bugzilla.redhat.com/show_bug.cgi?id=1179209 Should the proposed changes be pushed upstream or is this a Fedora-only thing? This is relevant to Fedora only. Whether there are bits that can be sent upstream depends on the changes done by maintainers. regards, Nikos -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: System-wide crypto policy transition tracker
On Tue, 2015-01-06 at 12:16 -0500, Christopher wrote: Are there any guidelines for enforcing crypto policies in Java applications. Primarily, I was thinking about those Java applications that use JSSE system properties or similar user-driven configuration to specify keystores. Are those affected by this crypto policy at all? Not yet. I haven't started a process on that, as I'd like to have time to spend on the successful deployment on openssl, gnutls and hopefully nss. However, maybe we don't need to do everything in a serialized way. If you are interested in that, may I suggest to fill feature request with the relevant java packages shipped in fedora? I've put a tracker of the crypto policies applicability at: https://fedoraproject.org/wiki/User:Nmav/FedoraCryptoPolicies Also, what about situations where SSL/TLS is off by default in the application, but is an available as an optional feature, if the user configures it? Since users are obliged to configure it, it seems there's not much for a packager to do in those situations, because that depends on the user's configuration, right? I'm not sure I understand the question. Let's see wget. wget http://www.amazon.com no ssl wget https://www.amazon.com ssl with system wide policies wget --secure-protocol=TLSv1 - application/user specific policy That is the default policies should be used if the user simply asks for SSL/TLS without being more specific. regards, Nikos -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: System-wide crypto policy transition tracker
On Tue, 2015-01-06 at 11:27 -0600, Michael Cronenworth wrote: On 01/06/2015 09:20 AM, Nikos Mavrogiannopoulos wrote: I've created a transition tracker to system-wide crypto policy at: https://bugzilla.redhat.com/show_bug.cgi?id=1179209 Currently it contains bugs filled against openssl and gnutls applications in Fedora. If you use some application which utilizes SSL/TLS and isn't included in the tracker feel free to request it use the policy, and include a link to the bug report in the tracker. Do you have any desire to see this feature in MinGW? Currently we build with your default policy patch but we do not supply a MinGW crypto-policies. Not sure about it. I guess that there shouldn't be anything related to system-wide policies there because that software is intended to be run in a different OS than fedora. So I wouldn't put anything related with system-wide policies there. regards, Nikos -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Schedule for Wednesday's FESCo Meeting (2015-01-07)
- Original Message - Following is the list of topics that will be discussed in the FESCo meeting Wednesday at 18:00UTC in #fedora-meeting on irc.freenode.net. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '2015-01-07 18:00 UTC' Links to all tickets below can be found at: https://fedorahosted.org/fesco/report/9 = Followups = #topic #1372 Workstation Product defaults to wide-open firewall https://fedorahosted.org/fesco/ticket/1372 #topic #1349 Fedora 22 scheduling strategy (and beyond) https://fedorahosted.org/fesco/ticket/1349 #topic #1198 Possible changes to Fedora EOL bug procedure https://fedorahosted.org/fesco/ticket/1198 #topic #1326 change to fesco replacement process? https://fedorahosted.org/fesco/ticket/1326 And FESCo elections are coming soon - draft schedule is on Elections page. We intentionally skipped break, we'll be a bit out of one month period from release but... Jaroslav -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: System-wide crypto policy transition tracker
On Wed, 2015-01-07 at 09:18 +0100, Petr Spacek wrote: Currently it contains bugs filled against openssl and gnutls applications in Fedora. If you use some application which utilizes SSL/TLS and isn't included in the tracker feel free to request it use the policy, and include a link to the bug report in the tracker. The tracker also contains a dependency on NSS respecting the system crypto policy: https://bugzilla.redhat.com/show_bug.cgi?id=1157720 I wonder what is your plan moving forward. Is it going to be 'TLS policy'? Or are you planning to generalize it in future? The greater plan was to apply to all crypto protocol apps. That depends of course on turning various non-compatible knobs on different software. My plan is to extend the policies step by step, but if you or anyone else would feel like extending it now to an application or protocol he/she uses, feel free. I've put a tracker page at: https://fedoraproject.org/wiki/User:Nmav/FedoraCryptoPolicies E.g. DNSSEC-related software can be configured which algorithm list and key sizes too. I guess that the same applies to GnuPG. The difficult part as I see it now is having each application/library involved get its settings from a preconfigured file that is automatically generated. If that is straightforward then only a translation from existing three policies (LEGACY, DEFAULT, FUTURE), to the application's format is needed. regards, Nikos -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: System-wide crypto policy transition tracker
On Tue, 2015-01-06 at 09:55 -0700, Kevin Fenzi wrote: Currently it contains bugs filled against openssl and gnutls applications in Fedora. If you use some application which utilizes SSL/TLS and isn't included in the tracker feel free to request it use the policy, and include a link to the bug report in the tracker. The tracker also contains a dependency on NSS respecting the system crypto policy: https://bugzilla.redhat.com/show_bug.cgi?id=1157720 I'm co-maintainer on one affected package. I note that the bug is against F21. Shouldn't this work be done now in rawhide? It's up to the maintainer to decide. The original plan was to have all gnutls and openssl packages in F22, but there is nothing prohibiting a maintainer enabling that feature in F21. regards, Nikos -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: System-wide crypto policy transition tracker
On 6.1.2015 16:20, Nikos Mavrogiannopoulos wrote: Hello, I've created a transition tracker to system-wide crypto policy at: https://bugzilla.redhat.com/show_bug.cgi?id=1179209 Currently it contains bugs filled against openssl and gnutls applications in Fedora. If you use some application which utilizes SSL/TLS and isn't included in the tracker feel free to request it use the policy, and include a link to the bug report in the tracker. The tracker also contains a dependency on NSS respecting the system crypto policy: https://bugzilla.redhat.com/show_bug.cgi?id=1157720 I wonder what is your plan moving forward. Is it going to be 'TLS policy'? Or are you planning to generalize it in future? E.g. DNSSEC-related software can be configured which algorithm list and key sizes too. I guess that the same applies to GnuPG. In other words, should the policy be able to express something like 'do not trust MD5, SHA1, DES, RC4, RSA 1024 bits anymore' ? IMHO it would be extremely handy - it would allow us to quickly react when something is seriously broken without patching all affected applications in Fedora. -- Petr^2 Spacek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[perl-Math-Round] Created tag perl-Math-Round-0.07-1.fc22
The lightweight tag 'perl-Math-Round-0.07-1.fc22' was created pointing to: 2c378aa... Update to 0.07 -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1179569] perl-Log-Any-Adapter-0.11-6.fc22 FTBFS: Can't continue after import errors at /usr/share/perl5/vendor_perl/Log/Any.pm
https://bugzilla.redhat.com/show_bug.cgi?id=1179569 --- Comment #1 from Ralf Corsepius rc040...@freenet.de --- Could you explain, why you filed this BZ? I was under the impression perl-Log-Any-Adapter was absorbed by perl-Log-Any and to be perl-Log-Any to be removed? -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=OYc6UCRl40a=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Log-Any-Adapter
perl-Log-Any-Adapter has broken dependencies in the rawhide tree: On x86_64: perl-Log-Any-Adapter-0.11-6.fc22.noarch requires perl(Log::Any::Adapter::Core) On i386: perl-Log-Any-Adapter-0.11-6.fc22.noarch requires perl(Log::Any::Adapter::Core) On armhfp: perl-Log-Any-Adapter-0.11-6.fc22.noarch requires perl(Log::Any::Adapter::Core) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Where is yaws?
On Sat, 2015-01-03 at 14:58 +0800, Christopher Meng wrote: Hi, I'd like to know why yaws was retired as it's a Web server still being used by many people, can someone tell me what happened there in the past? I feel unaccountably unhappy when I see that almost other major distributions ship it still with the latest 1.99 version however I can only install yaws in EPEL7 only with a dated 1.98 version. Well, noone volunteered to maintain it? I sort of needed it for EPEL until a couple of months ago so I kept it alive until recently where another volunteer picked it up. If you need it outside of EPEL free to re-add it I guess? The EPEL package should work fine with Fedora and I think update to 1.99 will be just a minimal effort. I'll review it for you if you file a review request. Thanks Lubo -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [EPEL-devel] Proposal for Python 3 packaging in EPEL 7
- Original Message - Hi all, I know I've been promising this for quite some time to several people, so I finally managed to put together a proposal for packaging Python 3 in EPEL 7 (it'd also scale to EPEL 6 for that matter). I've created a wiki page [1] with the proposal and I'd like to hear comments and thoughts on it. There are some TODOs and variants in few places - I'd like to hear your opinions on these, or perhaps suggestions on better approaches. I'll create new documents with the updated proposal at some points during the discussion, so that people can easily see where the proposal is going without having to compare wiki revisions. Is there any other list/interested parties that should be put in CC of this mail? If so, please feel free to respond and do that yourself. Thanks! -- Regards, Slavek Kabrda [1] https://fedoraproject.org/wiki/User:Bkabrda/EPEL7_Python3 Let's reiterate: - Nick Coghlan posted an interesting proposal to the discussion section in my proposal (my reaction is in the blue frame) [1]. I'd appreciate more comments on this. - From the feedback gathered on this list: - We should have /usr/bin/python3 pointing to a python3X build. The question is which one this will be during transitional periods between 3X and 3X+1. My thinking is that we should point /usr/bin/python3 to 3X+1 at the time of retiring 3X (IMO there is no ideal time to do that, so it's not really important). - As for dist-git possibilities, Orion would prefer to use current dist-git repos with epel-7 branches. It's not my preference (for reasons mentioned in the proposal), but I'm not against it if that is what others wish. - Stephen Smoogen mentioned that the transitional period during which python3X and python3X+1 exist can be anywhere from 6 weeks to 2 months. I'm starting to think that we should only specify the minimum time for which 3X will be kept. So my proposal would be sth. like 3X is kept for minimum of 6 weeks in parallel to 3X+1. After this, it is retired as soon as all stakeholders have rebuilt against 3X+1. (keeping it a bit vague is a good thing here, I think) - As I noted in one of my emails, we don't have to worry about conflicts with RHSCL. New collections from RHSCL will be named with rh- prefix and thus won't conflict with python3X stacks. Since it doesn't seem that there was anything very problematic, let's discuss the points mentioned above after which I should be able to finalize the proposal and make it official (and then we could all get to building :)). I'm quite sure that we'll still hit some technical issues, e.g. macro naming for parallel stacks, but I believe we can discuss and solve these on the way. Thanks. -- Regards, Slavek Kabrda [1] https://fedoraproject.org/wiki/User_talk:Bkabrda/EPEL7_Python3#Sharing_Packages_between_Python_3_installations.3F ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
[PkgDB] limb:perl-IPC-Signal approveacls set to Approved
user: limb set for mrunge acl: approveacls of package: perl-IPC-Signal from: to: Approved on branch: epel7 To make changes to this package see: https://admin.fedoraproject.org/pkgdb/package/perl-IPC-Signal -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[PkgDB] limb updated perl-IPC-Signal
user: limb created branch epel7 on package perl-IPC-Signal To make changes to this package see: https://admin.fedoraproject.org/pkgdb/package/perl-IPC-Signal -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[PkgDB] limb:perl-IPC-Signal watchcommits set to Approved
user: limb set for mrunge acl: watchcommits of package: perl-IPC-Signal from: to: Approved on branch: epel7 To make changes to this package see: https://admin.fedoraproject.org/pkgdb/package/perl-IPC-Signal -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[PkgDB] limb:perl-IPC-Signal commit set to Approved
user: limb set for mrunge acl: commit of package: perl-IPC-Signal from: to: Approved on branch: epel7 To make changes to this package see: https://admin.fedoraproject.org/pkgdb/package/perl-IPC-Signal -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[PkgDB] limb:perl-IPC-Signal watchbugzilla set to Approved
user: limb set for mrunge acl: watchbugzilla of package: perl-IPC-Signal from: to: Approved on branch: epel7 To make changes to this package see: https://admin.fedoraproject.org/pkgdb/package/perl-IPC-Signal -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Where is yaws?
On Wed, Jan 7, 2015 at 6:42 PM, Lubomir Rintel lkund...@v3.sk wrote: On Sat, 2015-01-03 at 14:58 +0800, Christopher Meng wrote: Hi, I'd like to know why yaws was retired as it's a Web server still being used by many people, can someone tell me what happened there in the past? I feel unaccountably unhappy when I see that almost other major distributions ship it still with the latest 1.99 version however I can only install yaws in EPEL7 only with a dated 1.98 version. Well, noone volunteered to maintain it? I sort of needed it for EPEL until a couple of months ago so I kept it alive until recently where another volunteer picked it up. If you need it outside of EPEL free to re-add it I guess? The EPEL package should work fine with Fedora and I think update to 1.99 will be just a minimal effort. I'll review it for you if you file a review request. Be grateful to see that it's still alive in EPEL channel, with an elder version though. I just wandered in the VZ systems and then found yaws is no longer available for Fedora users, that'd be unhandy for deploying packages. I will submit review requests later as I'm still out of time. Thanks! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
F22 System Wide Change: Fedora 22 Boost 1.58 Uplift
= Proposed System Wide Change: Fedora 22 Boost 1.58 Uplift = https://fedoraproject.org/wiki/Changes/F22Boost158 Change owner(s): Petr Machata pmach...@redhat.com This change brings Boost 1.57.0 or later to Fedora 22. We generally aim to ship 1.58.0, as that seems likely to make it (hence the Change name), but 1.57.0 is out and available now. == Detailed Description == The aim is to synchronize Fedora with the most recent Boost release. Because ABI stability is one of explicit Boost non-goals, this entails rebuilding of all dependent packages. This has also always entailed yours truly assisting maintainers of client packages in decoding cryptic boostese seen in output from g++. Such care is to be expected this time around as well. Boost 1.58 doesn't have firm schedule yet. I don't think there is even a provisional schedule at this point. We may have to package Boost 1.57 instead. Here is the Fedora 21 Change [1], should you need it. == Scope == Rebasing Boost has a fairly large impact on Fedora. For Fedora 20, the scope was: about 130 packages _must_ be rebuilt due to ABI breakage inherent in bumping Boost sonames. There were almost 250 client packages total. I expect these numbers to stay in the same ballpark for Fedora 22. * Proposal owners: ** Build will be done with Boost.Build v2 (which is upstream-sanctioned way of building Boost) ** Request a boost build system tag ** Build boost into that tag ** Post a request for rebuilds to fedora-devel ** Work on rebuilding dependent packages in the tag. ** When most is done, re-tag all the packages to rawhide ** Watch fedora-devel and assist in rebuilding broken Boost clients (by fixing the client, or Boost). * Other developers: Those who depend on Boost DSO's will have to rebuild their packages. Feature owners will alleviate some of this work as indicated above, and will assist those whose packages fail to build in debugging them. * Release engineering: Side tag creation. * Policies and guidelines: Apart from scope, this is business as usual, so no policies, no guidelines. [1] https://fedoraproject.org/wiki/Changes/F21Boost156 ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Bug 1179566] perl-Date-Calc-6.3-17.fc22 FTBFS: tests fail
https://bugzilla.redhat.com/show_bug.cgi?id=1179566 Petr Šabata psab...@redhat.com changed: What|Removed |Added External Bug ID||CPAN 101232 -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=L2c5tNgxLAa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
rawhide report: 20150107 changes
Compose started at Wed Jan 7 05:15:05 UTC 2015 Broken deps for i386 -- [Sprog] Sprog-0.14-27.fc20.noarch requires perl(:MODULE_COMPAT_5.18.0) [aeskulap] aeskulap-0.2.2-0.19beta1.fc22.i686 requires libofstd.so.3.6 aeskulap-0.2.2-0.19beta1.fc22.i686 requires liboflog.so.3.6 aeskulap-0.2.2-0.19beta1.fc22.i686 requires libijg8.so.3.6 aeskulap-0.2.2-0.19beta1.fc22.i686 requires libijg16.so.3.6 aeskulap-0.2.2-0.19beta1.fc22.i686 requires libijg12.so.3.6 aeskulap-0.2.2-0.19beta1.fc22.i686 requires libdcmnet.so.3.6 aeskulap-0.2.2-0.19beta1.fc22.i686 requires libdcmjpeg.so.3.6 aeskulap-0.2.2-0.19beta1.fc22.i686 requires libdcmimgle.so.3.6 aeskulap-0.2.2-0.19beta1.fc22.i686 requires libdcmimage.so.3.6 aeskulap-0.2.2-0.19beta1.fc22.i686 requires libdcmdata.so.3.6 [boswars] boswars-2.7-5.fc22.i686 requires libtolua++-5.1.so [cab] cab-0.1.9-12.fc22.i686 requires cabal-dev [dnssec-check] dnssec-check-1.14.0.1-4.fc20.i686 requires libval-threads.so.14 dnssec-check-1.14.0.1-4.fc20.i686 requires libsres.so.14 [fawkes] fawkes-lua-0.5.0-19.fc22.i686 requires libtolua++-5.1.so fawkes-plugin-katana-0.5.0-19.fc22.i686 requires libtolua++-5.1.so fawkes-plugin-pantilt-0.5.0-19.fc22.i686 requires libtolua++-5.1.so fawkes-plugin-roomba-0.5.0-19.fc22.i686 requires libtolua++-5.1.so fawkes-plugin-skiller-0.5.0-19.fc22.i686 requires libtolua++-5.1.so [freeipa] freeipa-server-trust-ad-4.1.2-1.fc22.i686 requires libpdb.so.0(PDB_0) freeipa-server-trust-ad-4.1.2-1.fc22.i686 requires libpdb.so.0 [gcc-python-plugin] gcc-python2-debug-plugin-0.13-2.fc22.i686 requires gcc = 0:4.9.2-1.fc22 gcc-python2-plugin-0.13-2.fc22.i686 requires gcc = 0:4.9.2-1.fc22 gcc-python3-debug-plugin-0.13-2.fc22.i686 requires gcc = 0:4.9.2-1.fc22 gcc-python3-plugin-0.13-2.fc22.i686 requires gcc = 0:4.9.2-1.fc22 [guacamole-server] libguac-client-rdp-0.9.3-1.fc22.i686 requires libfreerdp-utils.so.1.2 libguac-client-rdp-0.9.3-1.fc22.i686 requires libfreerdp-core.so.1.2 libguac-client-rdp-0.9.3-1.fc22.i686 requires libfreerdp-codec.so.1.2 libguac-client-rdp-0.9.3-1.fc22.i686 requires libfreerdp-cache.so.1.2 [ibus-libpinyin] ibus-libpinyin-1.6.92-4.fc22.i686 requires libopencc.so.1 [ibus-libzhuyin] ibus-libzhuyin-1.6.99.20140929-1.fc22.i686 requires libopencc.so.1 [nifti2dicom] nifti2dicom-0.4.9-1.fc22.i686 requires libitksys-4.6.so.1 nifti2dicom-0.4.9-1.fc22.i686 requires libitkopenjpeg-4.6.so.1 nifti2dicom-0.4.9-1.fc22.i686 requires libitkdouble-conversion-4.6.so.1 nifti2dicom-0.4.9-1.fc22.i686 requires libitkNetlibSlatec-4.6.so.1 nifti2dicom-0.4.9-1.fc22.i686 requires libITKznz-4.6.so.1 nifti2dicom-0.4.9-1.fc22.i686 requires libITKniftiio-4.6.so.1 nifti2dicom-0.4.9-1.fc22.i686 requires libITKgiftiio-4.6.so.1 nifti2dicom-0.4.9-1.fc22.i686 requires libITKWatersheds-4.6.so.1 nifti2dicom-0.4.9-1.fc22.i686 requires libITKVtkGlue-4.6.so.1 nifti2dicom-0.4.9-1.fc22.i686 requires libITKVideoIO-4.6.so.1 nifti2dicom-0.4.9-1.fc22.i686 requires libITKVideoCore-4.6.so.1 nifti2dicom-0.4.9-1.fc22.i686 requires libITKVTK-4.6.so.1 nifti2dicom-0.4.9-1.fc22.i686 requires libITKVNLInstantiation-4.6.so.1 nifti2dicom-0.4.9-1.fc22.i686 requires libITKStatistics-4.6.so.1 nifti2dicom-0.4.9-1.fc22.i686 requires libITKSpatialObjects-4.6.so.1 nifti2dicom-0.4.9-1.fc22.i686 requires libITKReview-4.6.so.1 nifti2dicom-0.4.9-1.fc22.i686 requires libITKQuadEdgeMesh-4.6.so.1 nifti2dicom-0.4.9-1.fc22.i686 requires libITKPolynomials-4.6.so.1 nifti2dicom-0.4.9-1.fc22.i686 requires libITKPath-4.6.so.1 nifti2dicom-0.4.9-1.fc22.i686 requires libITKOptimizersv4-4.6.so.1 nifti2dicom-0.4.9-1.fc22.i686 requires libITKOptimizers-4.6.so.1 nifti2dicom-0.4.9-1.fc22.i686 requires libITKNrrdIO-4.6.so.1 nifti2dicom-0.4.9-1.fc22.i686 requires libITKMetaIO-4.6.so.1 nifti2dicom-0.4.9-1.fc22.i686 requires libITKMesh-4.6.so.1 nifti2dicom-0.4.9-1.fc22.i686 requires libITKLabelMap-4.6.so.1 nifti2dicom-0.4.9-1.fc22.i686 requires libITKKLMRegionGrowing-4.6.so.1 nifti2dicom-0.4.9-1.fc22.i686 requires libITKIOXML-4.6.so.1 nifti2dicom-0.4.9-1.fc22.i686 requires libITKIOVTK-4.6.so.1 nifti2dicom-0.4.9-1.fc22.i686 requires libITKIOTransformMatlab-4.6.so.1 nifti2dicom-0.4.9-1.fc22.i686 requires libITKIOTransformInsightLegacy-4.6.so.1 nifti2dicom-0.4.9-1.fc22.i686 requires libITKIOTransformHDF5-4.6.so.1 nifti2dicom-0.4.9-1.fc22.i686 requires libITKIOTransformBase-4.6.so.1 nifti2dicom-0.4.9-1.fc22.i686 requires libITKIOTIFF-4.6.so.1
[perl-Sub-Identify] Update to 0.10
commit f4d497f21e6d3740ebb2eb0702c63164322601a0
Author: Paul Howarth p...@city-fan.org
Date: Wed Jan 7 11:50:44 2015 +
Update to 0.10
- New upstream release 0.10
- Fix test failure due to hard-coded filenames
perl-Sub-Identify.spec | 10 +++---
sources|2 +-
2 files changed, 8 insertions(+), 4 deletions(-)
---
diff --git a/perl-Sub-Identify.spec b/perl-Sub-Identify.spec
index 5763149..4dd8991 100644
--- a/perl-Sub-Identify.spec
+++ b/perl-Sub-Identify.spec
@@ -1,5 +1,5 @@
Name: perl-Sub-Identify
-Version: 0.08
+Version: 0.10
Release: 1%{?dist}
Summary: Retrieve names of code references
License: GPL+ or Artistic
@@ -55,12 +55,16 @@ make test
rm -rf %{buildroot}
%files
-%doc Changes TODO.mdown t/
+%doc Changes README.mdown TODO.mdown t/
%{perl_vendorarch}/auto/Sub/
%{perl_vendorarch}/Sub/
-%{_mandir}/man3/Sub::Identify.3pm*
+%{_mandir}/man3/Sub::Identify.3*
%changelog
+* Wed Jan 7 2015 Paul Howarth p...@city-fan.org - 0.10-1
+- Update to 0.10
+ - Fix test failure due to hard-coded filenames
+
* Thu Sep 18 2014 Paul Howarth p...@city-fan.org - 0.08-1
- Update to 0.08
- Add test for function prototypes
diff --git a/sources b/sources
index 3ce5553..c69bb7e 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-07fbd43c37a26f3ac1e12e854a5146dd Sub-Identify-0.08.tar.gz
+08bb2f22c85007d2cbb0eb9541c77355 Sub-Identify-0.10.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
F22 Self Contained Change: Lohit2 Odia Telugu
= Proposed Self Contained: Lohit2 Odia Telugu = https://fedoraproject.org/wiki/Changes/Lohit2_Odia_Telugu Change owner(s): Pravin Satpute prav...@fedoraproject.org Lohit2 project aims to make open type tables of Indian fonts effective and efficient following various standard around font technology including Unicode, Open type specification, Adobe font naming guidelines. During Fedora 22 Lohit upstream planning to release Lohit Odia and Lohit Telugu with completely rewritten open type tables. == Detailed Description == Lohit Odia and Telugu fonts are available from 2004. Over the years number of redundant and incorrect open type rules got added into this to cope up with different layout engine available with Pango, Qt and ICU. We started using Harfbuzz-NG unified shaper in Fedora from Fedora 19. Its time to clean-up Odia and Telugu open type tables and make them effective and efficient by following all the standards around font technology. Under Lohit2 project this is happening with Fedora 22 release cycle. == Scope == * Proposal owners: Update fonts to the new upstream * Other developers: N/A (not a System Wide Change) * Release engineering: N/A (not a System Wide Change) * Policies and guidelines: N/A (not a System Wide Change) ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
F22 Self Contained Change: New Default Console Font
= Proposed Self Contained: New Default Console Font = https://fedoraproject.org/wiki/Changes/NewDefaultConsoleFont Change owner(s): Marko Myllynen mylly...@redhat.com, Mike FABIAN mfab...@fedoraproject.org A new console font, eurlatgr, was recently added to kbd and it should be better default console font for European based languages written in Latin or Greek script. eurlatgr is based on latarcyrheb-sun16 so the typeface does not change. == Detailed Description == eurlatgr would bring these changes over the current default latarcyrheb-sun16: * full compatibility with latarcyrheb-sun16 for Latin script and special characters * Arabic/Cyrillic/Hebrew are not supported at all by eurlatgr so those users should still stay with latarcyrheb-sun16 * non-European languages written in Latin script (like Vietnamese) are not fully supported but perhaps a bit more so than with latarcyrheb-sun16 * the only non-Arabic/Cyrillic/Hebrew characters not present in eurlatgr but in latarcyrheb-sun16 are U+F800 and U+F804 which are not valid Unicode characters so the use case for them is unclear, especially today. These could be re-added if there's a real need for them but if not, dropping them is ok * full support for all European languages written in Latin script * full support for Greek * full support for a huge list of characters and character sets (see Documentation below) * support for a wide range of accented Latin characters not present in latarcyrheb-sun16 to allow people to write their names correctly * support for glyphs used by some systemd(1) utilities * support for glyphs used by man(1) (see e.g. the bottom of unicode(7) how some characters are not displayed properly under latarcyrheb-sun16) * support for glyphs that have become popular recently, like the smiley (☺) and arrows (e.g. →) == Scope == * Adjust langtable rules to prefer eurlatgr instead of latarcyrheb-sun16 for the languages supported by eurlatgr. Review additional related tools (anaconda, dracut, systemd) to see whether any defaults need to be changed. * Other developers: N/A (not a System Wide Change) * Release engineering: N/A (not a System Wide Change) * Policies and guidelines: N/A (not a System Wide Change) ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Bug 1179569] perl-Log-Any-Adapter-0.11-6.fc22 FTBFS: Can't continue after import errors at /usr/share/perl5/vendor_perl/Log/Any.pm
https://bugzilla.redhat.com/show_bug.cgi?id=1179569 Fedora Admin XMLRPC Client fedora-admin-xml...@redhat.com changed: What|Removed |Added Assignee|rc040...@freenet.de |extras-orphan@fedoraproject ||.org --- Comment #2 from Fedora Admin XMLRPC Client fedora-admin-xml...@redhat.com --- This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=5gZvwrX1l2a=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[PkgDB] corsepiu updated package: perl-Log-Any-Adapter status to Retired [master]
user: corsepiu updated package: perl-Log-Any-Adapter status from: Approved to Retired on branch: master To make changes to this package see: https://admin.fedoraproject.org/pkgdb/package/perl-Log-Any-Adapter -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1178719] Please EOL perl-Log-Any-Adapter in Rawhide
https://bugzilla.redhat.com/show_bug.cgi?id=1178719 Fedora Admin XMLRPC Client fedora-admin-xml...@redhat.com changed: What|Removed |Added Assignee|rc040...@freenet.de |extras-orphan@fedoraproject ||.org --- Comment #1 from Fedora Admin XMLRPC Client fedora-admin-xml...@redhat.com --- This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=idy2MGZoh4a=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Deleting f20-gnome-3-12 copr
On Jan 7, 2015 6:00 AM, Richard Hughes hughsi...@gmail.com wrote: I'm planning to delete https://copr.fedoraproject.org/coprs/rhughes/f20-gnome-3-12/ this week. The original description always had This COPR will be updated until Fedora 21 has been released or until the entropy death of the universe, whichever happens first. so I don't altogether feel too guilty about abandoning it. Does anyone have any objections or wants to volunteer to take it over before I delete the repo? Richard -- While recognizing the massive maintenance burden of this COPR, I suspect the majority of objections will come from the enthusiast end user type - you know, the ones that are so eager to try the new thing they read about that they blow right past the description. This COPR received a lot of publicity; fedoramagazine articles, social media, blog posts, etc. Can you work in similar signal for end users? Besides the online content, I think even an integrated warning from within the GNOME session would be cool. I could show you a dozen examples from ask.fp.o where users encounter a 404, your repo has gone away and they do not understand it. /backseatdriver --Pete -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[perl-Sub-Identify] Created tag perl-Sub-Identify-0.10-1.fc22
The lightweight tag 'perl-Sub-Identify-0.10-1.fc22' was created pointing to: f4d497f... Update to 0.10 -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
F22 System Wide Change: Harden all packages with position-independent code
= Proposed System Wide Change: Harden all packages with position-independent code = https://fedoraproject.org/wiki/Changes/Harden_all_packages_with_position-independent_code Change owner(s): Till Maas opensou...@till.name, Moez Roy moez@gmail.com Harden all packages with position-independent code to limit the damage from certain security vulnerabilities. == Detailed Description == Currently, the Packaging Guidelines allow maintainers to decide whether their packages use position-independent code (PIC). There are rules that say that a lot of packages should use PIC, but in reality a lot of packages do not use PIC even if they must. Also since a lot of packages if not all potentially process untrusted input, it makes sense for these packages to use PIC to enhance the security of Fedora. Therefore I propose to build all packages with PIC by changing RPM to use the appropriate flags by default. References: * https://fedorahosted.org/rel-eng/ticket/6049 * There should be several mails about this on the devel list == Scope == * Proposal owners: Help writing the new packaging guidelines. * Other developers: Change the rpm macros to build packages by default with PIC/PIE flags (i.e. set _hardened_package to 1 by default). * Release engineering: Do a mass rebuild for all arch packages * Policies and guidelines: Adjust the Packaging Guidelines to allow non-PIC packages only if the package is not working otherwise and require a tracker bug similar to packages not working on certain archs. Update the Guidelines to reflect the new defaults. ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Software Collections mostly unanswered questions
Hi, as promised there is a wiki page [1] with mostly questions that seem to be unanswered so far. Some of those questions have already some proposed answer, but this is still subject of discussion. This was prepared to move forward since it seems the SCL topic is too complex now. Let's discuss the topics on Env and Stacks mailing list and vote on controversial items on some of the next Env and Stacks meeting. Recommended way to start a discussion: 1) Open up a discussion about a specific topic on the ML (may be one question or can cover more related questions). 2) add a link to the ML thread into the wiki page [1], so the discussion is tracked (feel free to add new question to the wiki if not mentioned there yet) [1] https://fedoraproject.org/wiki/Env_and_Stacks/Projects/SoftwareCollectionsInFedora Honza -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Bug 1179567] perl-Date-Pcalc-6.1-11.fc22 FTBFS: tests fail
https://bugzilla.redhat.com/show_bug.cgi?id=1179567 Petr Šabata psab...@redhat.com changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-Date-Pcalc-6.1-12.fc22 Resolution|--- |RAWHIDE Last Closed||2015-01-07 09:17:26 -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=3txMYzghNCa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Date-Pcalc] Adapt the test suite for the 2015-2115 era
commit e9413795589b22fec40dea391cdb9fe990d28d24
Author: Petr Šabata con...@redhat.com
Date: Wed Jan 7 15:16:32 2015 +0100
Adapt the test suite for the 2015-2115 era
Date-Pcalc-6.1-century.patch | 433 ++
perl-Date-Pcalc.spec | 46 -
2 files changed, 468 insertions(+), 11 deletions(-)
---
diff --git a/Date-Pcalc-6.1-century.patch b/Date-Pcalc-6.1-century.patch
new file mode 100644
index 000..614033d
--- /dev/null
+++ b/Date-Pcalc-6.1-century.patch
@@ -0,0 +1,433 @@
+From d8fddafea015740755ddcb24da1388996303502f Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Petr=20=C5=A0abata?= con...@redhat.com
+Date: Wed, 7 Jan 2015 14:40:19 +0100
+Subject: [PATCH] Adapt the test suite for the next 100 years
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+We're now closer to year 2064 than 1964, therefore dates with two-digit
+years decode differently now.
+
+Signed-off-by: Petr Šabata con...@redhat.com
+---
+ t/f016.t | 32
+ t/f027.t | 44 ++--
+ t/f028.t | 44 ++--
+ 3 files changed, 60 insertions(+), 60 deletions(-)
+
+diff --git a/t/f016.t b/t/f016.t
+index 98069a4..60cc3fa 100644
+--- a/t/f016.t
b/t/f016.t
+@@ -15,19 +15,19 @@ print 1..25\n;
+
+ $n = 1;
+ if ((($year,$mm,$dd) = Decode_Date_EU(3.1.64))
+-($year==1964)($mm==1)($dd==3))
++($year==2064)($mm==1)($dd==3))
+ {print ok $n\n;} else {print not ok $n\n;}
+ $n++;
+ if ((($year,$mm,$dd) = Decode_Date_EU(3 1 64))
+-($year==1964)($mm==1)($dd==3))
++($year==2064)($mm==1)($dd==3))
+ {print ok $n\n;} else {print not ok $n\n;}
+ $n++;
+ if ((($year,$mm,$dd) = Decode_Date_EU(03.01.64))
+-($year==1964)($mm==1)($dd==3))
++($year==2064)($mm==1)($dd==3))
+ {print ok $n\n;} else {print not ok $n\n;}
+ $n++;
+ if ((($year,$mm,$dd) = Decode_Date_EU(03/01/64))
+-($year==1964)($mm==1)($dd==3))
++($year==2064)($mm==1)($dd==3))
+ {print ok $n\n;} else {print not ok $n\n;}
+ $n++;
+ if ((($year,$mm,$dd) = Decode_Date_EU(3. Ene 1964,4))
+@@ -35,11 +35,11 @@ if ((($year,$mm,$dd) = Decode_Date_EU(3. Ene 1964,4))
+ {print ok $n\n;} else {print not ok $n\n;}
+ $n++;
+ if ((($year,$mm,$dd) = Decode_Date_EU(Geburtstag: 3. Januar '64 in
Backnang/W�rttemberg,3))
+-($year==1964)($mm==1)($dd==3))
++($year==2064)($mm==1)($dd==3))
+ {print ok $n\n;} else {print not ok $n\n;}
+ $n++;
+ if ((($year,$mm,$dd) = Decode_Date_EU(03-Jan-64))
+-($year==1964)($mm==1)($dd==3))
++($year==2064)($mm==1)($dd==3))
+ {print ok $n\n;} else {print not ok $n\n;}
+ $n++;
+ if ((($year,$mm,$dd) = Decode_Date_EU(3.Jan1964,6))
+@@ -47,19 +47,19 @@ if ((($year,$mm,$dd) = Decode_Date_EU(3.Jan1964,6))
+ {print ok $n\n;} else {print not ok $n\n;}
+ $n++;
+ if ((($year,$mm,$dd) = Decode_Date_EU(3Jan64,0))
+-($year==1964)($mm==1)($dd==3))
++($year==2064)($mm==1)($dd==3))
+ {print ok $n\n;} else {print not ok $n\n;}
+ $n++;
+ if ((($year,$mm,$dd) = Decode_Date_EU(030164))
+-($year==1964)($mm==1)($dd==3))
++($year==2064)($mm==1)($dd==3))
+ {print ok $n\n;} else {print not ok $n\n;}
+ $n++;
+ if ((($year,$mm,$dd) = Decode_Date_EU(3ja64))
+-($year==1964)($mm==1)($dd==3))
++($year==2064)($mm==1)($dd==3))
+ {print ok $n\n;} else {print not ok $n\n;}
+ $n++;
+ if ((($year,$mm,$dd) = Decode_Date_EU(3164))
+-($year==1964)($mm==1)($dd==3))
++($year==2064)($mm==1)($dd==3))
+ {print ok $n\n;} else {print not ok $n\n;}
+ $n++;
+
+@@ -72,15 +72,15 @@ unless (($year,$mm,$dd) = Decode_Date_EU(29.2.1995))
+ $n++;
+
+ if ((($year,$mm,$dd) = Decode_Date_US(1 3 64))
+-($year==1964)($mm==1)($dd==3))
++($year==2064)($mm==1)($dd==3))
+ {print ok $n\n;} else {print not ok $n\n;}
+ $n++;
+ if ((($year,$mm,$dd) = Decode_Date_US(01/03/64))
+-($year==1964)($mm==1)($dd==3))
++($year==2064)($mm==1)($dd==3))
+ {print ok $n\n;} else {print not ok $n\n;}
+ $n++;
+ if ((($year,$mm,$dd) = Decode_Date_US(Jan 3 '64))
+-($year==1964)($mm==1)($dd==3))
++($year==2064)($mm==1)($dd==3))
+ {print ok $n\n;} else {print not ok $n\n;}
+ $n++;
+ if ((($year,$mm,$dd) = Decode_Date_US(Jan 3 1964))
+@@ -96,15 +96,15 @@ if ((($year,$mm,$dd) = Decode_Date_US(Jan31964))
+ {print ok $n\n;} else {print not ok $n\n;}
+ $n++;
+ if ((($year,$mm,$dd) = Decode_Date_US(Jan364))
+-($year==1964)($mm==1)($dd==3))
++($year==2064)($mm==1)($dd==3))
+ {print ok $n\n;} else {print not ok $n\n;}
+ $n++;
+ if ((($year,$mm,$dd) = Decode_Date_US(ja364))
+-($year==1964)($mm==1)($dd==3))
++($year==2064)($mm==1)($dd==3))
+ {print ok $n\n;} else {print not ok $n\n;}
+ $n++;
+ if ((($year,$mm,$dd) = Decode_Date_US(1364))
+-($year==1964)($mm==1)($dd==3))
++($year==2064)($mm==1)($dd==3))
+ {print ok $n\n;} else {print not ok $n\n;}
+ $n++;
+
+diff --git a/t/f027.t b/t/f027.t
+index 3070fd7..4a686dc 100644
+--- a/t/f027.t
b/t/f027.t
+@@ -41,47 +41,47 @@ if ((($year,$mm,$dd) = Decode_Date_US2(_00134_))
+ $n++;
+
+ if ((($year,$mm,$dd) =
[perl-Date-Calc] Adapt the test suite for the 2015-2115 era
commit daa100e0bc469c3e5d62c64a97d1d8ac1542a534
Author: Petr Šabata con...@redhat.com
Date: Wed Jan 7 15:37:11 2015 +0100
Adapt the test suite for the 2015-2115 era
Date-Calc-6.3-century.patch | 433 +++
perl-Date-Calc.spec | 59 ---
2 files changed, 465 insertions(+), 27 deletions(-)
---
diff --git a/Date-Calc-6.3-century.patch b/Date-Calc-6.3-century.patch
new file mode 100644
index 000..b810482
--- /dev/null
+++ b/Date-Calc-6.3-century.patch
@@ -0,0 +1,433 @@
+From e65ad7f563386aa0bf43f6de9e2b3f2dc49e565d Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Petr=20=C5=A0abata?= con...@redhat.com
+Date: Wed, 7 Jan 2015 14:45:13 +0100
+Subject: [PATCH] Adapt the test suite for the next 100 years
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+We're now closer to year 2064 than 1964, therefore dates with two-digit
+years decode differently now.
+
+Signed-off-by: Petr Šabata con...@redhat.com
+---
+ t/f016.t | 32
+ t/f027.t | 44 ++--
+ t/f028.t | 44 ++--
+ 3 files changed, 60 insertions(+), 60 deletions(-)
+
+diff --git a/t/f016.t b/t/f016.t
+index 1adfc8a..5d2eab2 100644
+--- a/t/f016.t
b/t/f016.t
+@@ -17,19 +17,19 @@ print 1..25\n;
+
+ $n = 1;
+ if ((($year,$mm,$dd) = Decode_Date_EU(3.1.64))
+-($year==1964)($mm==1)($dd==3))
++($year==2064)($mm==1)($dd==3))
+ {print ok $n\n;} else {print not ok $n\n;}
+ $n++;
+ if ((($year,$mm,$dd) = Decode_Date_EU(3 1 64))
+-($year==1964)($mm==1)($dd==3))
++($year==2064)($mm==1)($dd==3))
+ {print ok $n\n;} else {print not ok $n\n;}
+ $n++;
+ if ((($year,$mm,$dd) = Decode_Date_EU(03.01.64))
+-($year==1964)($mm==1)($dd==3))
++($year==2064)($mm==1)($dd==3))
+ {print ok $n\n;} else {print not ok $n\n;}
+ $n++;
+ if ((($year,$mm,$dd) = Decode_Date_EU(03/01/64))
+-($year==1964)($mm==1)($dd==3))
++($year==2064)($mm==1)($dd==3))
+ {print ok $n\n;} else {print not ok $n\n;}
+ $n++;
+ if ((($year,$mm,$dd) = Decode_Date_EU(3. Ene 1964,4))
+@@ -37,11 +37,11 @@ if ((($year,$mm,$dd) = Decode_Date_EU(3. Ene 1964,4))
+ {print ok $n\n;} else {print not ok $n\n;}
+ $n++;
+ if ((($year,$mm,$dd) = Decode_Date_EU(Geburtstag: 3. Januar '64 in
Backnang/W�rttemberg,3))
+-($year==1964)($mm==1)($dd==3))
++($year==2064)($mm==1)($dd==3))
+ {print ok $n\n;} else {print not ok $n\n;}
+ $n++;
+ if ((($year,$mm,$dd) = Decode_Date_EU(03-Jan-64))
+-($year==1964)($mm==1)($dd==3))
++($year==2064)($mm==1)($dd==3))
+ {print ok $n\n;} else {print not ok $n\n;}
+ $n++;
+ if ((($year,$mm,$dd) = Decode_Date_EU(3.Jan1964,6))
+@@ -49,19 +49,19 @@ if ((($year,$mm,$dd) = Decode_Date_EU(3.Jan1964,6))
+ {print ok $n\n;} else {print not ok $n\n;}
+ $n++;
+ if ((($year,$mm,$dd) = Decode_Date_EU(3Jan64,0))
+-($year==1964)($mm==1)($dd==3))
++($year==2064)($mm==1)($dd==3))
+ {print ok $n\n;} else {print not ok $n\n;}
+ $n++;
+ if ((($year,$mm,$dd) = Decode_Date_EU(030164))
+-($year==1964)($mm==1)($dd==3))
++($year==2064)($mm==1)($dd==3))
+ {print ok $n\n;} else {print not ok $n\n;}
+ $n++;
+ if ((($year,$mm,$dd) = Decode_Date_EU(3ja64))
+-($year==1964)($mm==1)($dd==3))
++($year==2064)($mm==1)($dd==3))
+ {print ok $n\n;} else {print not ok $n\n;}
+ $n++;
+ if ((($year,$mm,$dd) = Decode_Date_EU(3164))
+-($year==1964)($mm==1)($dd==3))
++($year==2064)($mm==1)($dd==3))
+ {print ok $n\n;} else {print not ok $n\n;}
+ $n++;
+
+@@ -74,15 +74,15 @@ unless (($year,$mm,$dd) = Decode_Date_EU(29.2.1995))
+ $n++;
+
+ if ((($year,$mm,$dd) = Decode_Date_US(1 3 64))
+-($year==1964)($mm==1)($dd==3))
++($year==2064)($mm==1)($dd==3))
+ {print ok $n\n;} else {print not ok $n\n;}
+ $n++;
+ if ((($year,$mm,$dd) = Decode_Date_US(01/03/64))
+-($year==1964)($mm==1)($dd==3))
++($year==2064)($mm==1)($dd==3))
+ {print ok $n\n;} else {print not ok $n\n;}
+ $n++;
+ if ((($year,$mm,$dd) = Decode_Date_US(Jan 3 '64))
+-($year==1964)($mm==1)($dd==3))
++($year==2064)($mm==1)($dd==3))
+ {print ok $n\n;} else {print not ok $n\n;}
+ $n++;
+ if ((($year,$mm,$dd) = Decode_Date_US(Jan 3 1964))
+@@ -98,15 +98,15 @@ if ((($year,$mm,$dd) = Decode_Date_US(Jan31964))
+ {print ok $n\n;} else {print not ok $n\n;}
+ $n++;
+ if ((($year,$mm,$dd) = Decode_Date_US(Jan364))
+-($year==1964)($mm==1)($dd==3))
++($year==2064)($mm==1)($dd==3))
+ {print ok $n\n;} else {print not ok $n\n;}
+ $n++;
+ if ((($year,$mm,$dd) = Decode_Date_US(ja364))
+-($year==1964)($mm==1)($dd==3))
++($year==2064)($mm==1)($dd==3))
+ {print ok $n\n;} else {print not ok $n\n;}
+ $n++;
+ if ((($year,$mm,$dd) = Decode_Date_US(1364))
+-($year==1964)($mm==1)($dd==3))
++($year==2064)($mm==1)($dd==3))
+ {print ok $n\n;} else {print not ok $n\n;}
+ $n++;
+
+diff --git a/t/f027.t b/t/f027.t
+index a06cb99..1b70ffb 100644
+--- a/t/f027.t
b/t/f027.t
+@@ -43,47 +43,47 @@ if ((($year,$mm,$dd) = Decode_Date_US2(_00134_))
+ $n++;
+
+ if ((($year,$mm,$dd) =
Re: Deleting f20-gnome-3-12 copr
On 2015-01-07, 14:13 GMT, Pete Travis wrote: While recognizing the massive maintenance burden of this COPR, I suspect the majority of objections will come from the enthusiast end user type - you know, the ones that are so eager to try the new thing they read about that they blow right past the description. This COPR received a lot of publicity; fedoramagazine articles, social media, blog posts, etc. Shouldn't such COPR be part of Rawhide anyway? People who wants the bleeding edge stuff usually don't sit on F20 forever, do they? Matěj -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[perl-Compress-Raw-Lzma] Created tag perl-Compress-Raw-Lzma-2.068-2.fc22
The lightweight tag 'perl-Compress-Raw-Lzma-2.068-2.fc22' was created pointing to: 261beec... Rebuild for xz-5.2.0 in Rawhide (#1179255) -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File Sub-Identify-0.10.tar.gz uploaded to lookaside cache by pghmcfc
A file has been added to the lookaside cache for perl-Sub-Identify: 08bb2f22c85007d2cbb0eb9541c77355 Sub-Identify-0.10.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Test-Warnings] Update to 0.020
commit 0e5f252be654b48ed9f90c90bba291be46d1d2f2
Author: Paul Howarth p...@city-fan.org
Date: Wed Jan 7 12:24:58 2015 +
Update to 0.020
- New upstream release 0.020
- Re-release to fix problematic $VERSION declaration (CPAN RT#101239)
perl-Test-Warnings.spec |6 +-
sources |2 +-
2 files changed, 6 insertions(+), 2 deletions(-)
---
diff --git a/perl-Test-Warnings.spec b/perl-Test-Warnings.spec
index b08e557..2b5ae59 100644
--- a/perl-Test-Warnings.spec
+++ b/perl-Test-Warnings.spec
@@ -1,5 +1,5 @@
Name: perl-Test-Warnings
-Version: 0.019
+Version: 0.020
Release: 1%{?dist}
Summary: Test for warnings and the lack of them
License: GPL+ or Artistic
@@ -73,6 +73,10 @@ make test
%{_mandir}/man3/Test::Warnings.3*
%changelog
+* Wed Jan 7 2015 Paul Howarth p...@city-fan.org - 0.020-1
+- Update to 0.020
+ - Re-release to fix problematic $VERSION declaration (CPAN RT#101239)
+
* Fri Dec 19 2014 Paul Howarth p...@city-fan.org - 0.019-1
- Update to 0.019
- Fix test to allow for special characters (e.g. MSWin32 file separators) in
diff --git a/sources b/sources
index b8198f1..d80832a 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-aea67df04fa0080b596891b0f640f301 Test-Warnings-0.019.tar.gz
+c5d923fd727fea3f4b3aa91bad5ccf47 Test-Warnings-0.020.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1178719] Please EOL perl-Log-Any-Adapter in Rawhide
https://bugzilla.redhat.com/show_bug.cgi?id=1178719 Ralf Corsepius rc040...@freenet.de changed: What|Removed |Added Assignee|extras-orphan@fedoraproject |rc040...@freenet.de |.org| -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=o4r01lZm51a=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1179569] perl-Log-Any-Adapter-0.11-6.fc22 FTBFS: Can't continue after import errors at /usr/share/perl5/vendor_perl/Log/Any.pm
https://bugzilla.redhat.com/show_bug.cgi?id=1179569 Ralf Corsepius rc040...@freenet.de changed: What|Removed |Added Status|NEW |CLOSED Resolution|--- |EOL Assignee|extras-orphan@fedoraproject |rc040...@freenet.de |.org| Last Closed||2015-01-07 07:43:28 --- Comment #3 from Ralf Corsepius rc040...@freenet.de --- Package was retired from rawhide - closing -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=iQr3zyex6ta=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Agenda for Env-and-Stacks WG meeting (2015-01-07)
#fedora-meeting: Env and Stacks (2015-01-07) Meeting started by hhorak at 12:02:19 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2015-01-07/env-and-stacks.2015-01-07-12.02.log.html . Meeting summary --- * devpi work is in progress, the code is quite complex, so it'll take some time before having implemented it. upstream seems keen on the idea, but it seems they don't have enough time to do it themselves (hhorak, 12:11:26) * Follow-up: SCLs (hhorak, 12:12:26) * LINK: https://fedoraproject.org/wiki/Env_and_Stacks/Projects/SoftwareCollectionsInFedora (hhorak, 12:13:41) * scls are a long complex topic, let's start discussions about questions on ML and then perhaps vote about discussed things on one of next meetings (hhorak, 12:25:48) * ACTION: hhorak will post the link to the ML and will encourage to discuss on ML (hhorak, 12:26:31) * Env and Stacks elections (hhorak, 12:29:12) * According to Changing These Rules note in Governance Charter we may revisit rules of the working group after elections, but currently there are no specific things to change (hhorak, 12:36:05) * Open Floor (hhorak, 12:39:40) * ACTION: everybody to look at the python 3 in EPEL proposal from bkabrda at https://lists.fedoraproject.org/pipermail/epel-devel/2014-December/010548.html (hhorak, 12:50:01) Meeting ended at 13:32:06 UTC. Action Items * hhorak will post the link to the ML and will encourage to discuss on ML * everybody to look at the python 3 in EPEL proposal from bkabrda at https://lists.fedoraproject.org/pipermail/epel-devel/2014-December/010548.html Action Items, by person --- * bkabrda * everybody to look at the python 3 in EPEL proposal from bkabrda at https://lists.fedoraproject.org/pipermail/epel-devel/2014-December/010548.html * hhorak * hhorak will post the link to the ML and will encourage to discuss on ML * **UNASSIGNED** * (none) People Present (lines said) --- * juhp_ (52) * hhorak (45) * bkabrda (18) * langdon (18) * zodbot (4) * vpavlin (1) * jzeleny (1) * samkottler (0) * sicampbell (0) * tjanez (0) * juhp (0) * ncoghlan (0) * pkovar (0) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Deleting f20-gnome-3-12 copr
On Wed, Jan 7, 2015 at 3:13 PM, Pete Travis li...@petetravis.com wrote: On Jan 7, 2015 6:00 AM, Richard Hughes hughsi...@gmail.com wrote: I'm planning to delete https://copr.fedoraproject.org/coprs/rhughes/f20-gnome-3-12/ this week. The original description always had This COPR will be updated until Fedora 21 has been released or until the entropy death of the universe, whichever happens first. so I don't altogether feel too guilty about abandoning it. Does anyone have any objections or wants to volunteer to take it over before I delete the repo? Richard -- While recognizing the massive maintenance burden of this COPR, I suspect the majority of objections will come from the enthusiast end user type - you know, the ones that are so eager to try the new thing they read about that they blow right past the description. Well one might think that those kind of users have updated to F21 to get the new shiny stuff anyway. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Bug 1179567] perl-Date-Pcalc-6.1-11.fc22 FTBFS: tests fail
https://bugzilla.redhat.com/show_bug.cgi?id=1179567 Petr Šabata psab...@redhat.com changed: What|Removed |Added External Bug ID||CPAN 101232 --- Comment #2 from Petr Šabata psab...@redhat.com --- Yes, this is the same code as in Date::Calc. The issue is already reported upstream for Date::Calc. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=4oRx7VKTsGa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File Test-Warnings-0.020.tar.gz uploaded to lookaside cache by pghmcfc
A file has been added to the lookaside cache for perl-Test-Warnings: c5d923fd727fea3f4b3aa91bad5ccf47 Test-Warnings-0.020.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Log-Any-Adapter] Obsoleted by perl-Log-Any (RHBZ#1178719).
commit 8808c54450cd8cd9de09118662cce01663aaeb40 Author: Ralf Corsépius corse...@fedoraproject.org Date: Wed Jan 7 13:35:37 2015 +0100 Obsoleted by perl-Log-Any (RHBZ#1178719). .gitignore|1 - dead.package |1 + perl-Log-Any-Adapter.spec | 103 - sources |1 - 4 files changed, 1 insertions(+), 105 deletions(-) --- diff --git a/dead.package b/dead.package new file mode 100644 index 000..fb539be --- /dev/null +++ b/dead.package @@ -0,0 +1 @@ +Obsoleted by perl-Log-Any (RHBZ#1178719). -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Test-Warnings] Created tag perl-Test-Warnings-0.020-1.fc22
The lightweight tag 'perl-Test-Warnings-0.020-1.fc22' was created pointing to: 0e5f252... Update to 0.020 -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: What exactly is a bundled library? (was Re: apitrace, bundled libbacktrace)
On Wed, Jan 7, 2015 at 7:39 PM, Adam Williamson adamw...@fedoraproject.org wrote: On Tue, 2014-08-19 at 15:19 +0400, Pavel Alexeev wrote: Sorry for the old thread. But it is very interesting question to clearly determine bundled library to which returning happened again and again. Does it hang again now or something indeed changed? Yeah, I'm still interested in other people's thoughts on this, I rather expected it to get more traction when first posted. I guess I'll try one more bump (this one) and if still no-one bites, we can file an FPC ticket, perhaps. I don't think it's possible to get a perfectly blank-and-white definition of what constitutes a bundled library. Of course there's always the obvious cases where a project copies one in to their source tree more-or-less verbatim. That being said I think one thing that helps make it more clear is to look at the guidelines in reverse, meaning why don't we allow/like bundled libraries? Overall the primary drivers from the wiki page seems to be security, so when dealing with the grey area perhaps looking at things from a security perspective may help. In the specific case I ran into one of the package suites I've been working on technically bundles a modified copy of xmlrpcpp. However, it is quite modified, upstream is dead, it's not already in Fedora, and the author I'm working with only uses it for communication between his suite of programs and has no intention of offering it as a separate library. So again, from a security point of view: - It's not in Fedora so there's no code/library duplication - Upstream is dead so there's no one to send the code to upstream - It's not going to get used by another package in Fedora because it's not offered as a separate library. The final determination during the review was that it was far enough into the grey area to not be considered a bundled library and practically that makes sense when you think about the requirement to add a virtual provide to the package, in my case there's no upstream name to use due to the amount of modification nor a specific version I could tie it to. Don't know if this helps any with the discussion but just sharing my experience dealing with package reviews. Thanks, Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[perl-POSIX-strftime-Compiler/f21: 3/3] Merge cleanup.
commit a52090f04d89fe11370d0de7b81b674a9561a950
Author: Ralf Corsépius corse...@fedoraproject.org
Date: Thu Jan 8 08:25:53 2015 +0100
Merge cleanup.
perl-POSIX-strftime-Compiler.spec |3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
---
diff --git a/perl-POSIX-strftime-Compiler.spec
b/perl-POSIX-strftime-Compiler.spec
index 05195c7..491bb72 100644
--- a/perl-POSIX-strftime-Compiler.spec
+++ b/perl-POSIX-strftime-Compiler.spec
@@ -56,9 +56,6 @@ find $RPM_BUILD_ROOT -depth -type d -exec rmdir {}
2/dev/null \;
- Upstream update.
- Remove BR: perl(CPAN::Meta), BR: perl(CPAN::Meta::Prereqs).
-* Wed Aug 27 2014 Jitka Plesnikova jples...@redhat.com - 0.40-2
-- Perl 5.20 rebuild
-
* Thu Aug 21 2014 Ralf Corsépius corse...@fedoraproject.org - 0.40-1
- Fix Australia/Darwin test (RHBZ#1132033).
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-POSIX-strftime-Compiler/f21] (3 commits) ...Merge cleanup.
Summary of changes: 9cac297... Perl 5.20 rebuild (*) c79c330... Upstream update. (*) a52090f... Merge cleanup. (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-POSIX-strftime-Compiler/f20] (4 commits) ...Merge remote-tracking branch 'origin/f21' into f20
Summary of changes: 9cac297... Perl 5.20 rebuild (*) c79c330... Upstream update. (*) a52090f... Merge cleanup. (*) d9a2952... Merge remote-tracking branch 'origin/f21' into f20 (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-POSIX-strftime-Compiler/f20: 4/4] Merge remote-tracking branch 'origin/f21' into f20
commit d9a295284c466cd1007b8632e61f2b54d0eea0c4 Merge: c4a3bc7 a52090f Author: Ralf Corsépius corse...@fedoraproject.org Date: Thu Jan 8 08:30:37 2015 +0100 Merge remote-tracking branch 'origin/f21' into f20 .gitignore|2 +- perl-POSIX-strftime-Compiler.spec |8 +--- sources |2 +- 3 files changed, 7 insertions(+), 5 deletions(-) --- -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Params-Validate] Upstream update.
commit 57e96bec693c499710037ab47926a407fa492087
Author: Ralf Corsépius corse...@fedoraproject.org
Date: Thu Jan 8 07:43:48 2015 +0100
Upstream update.
- Reflect upstream changes.
.gitignore|2 +-
perl-Params-Validate.spec | 17 +
sources |2 +-
3 files changed, 15 insertions(+), 6 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 4fecdc7..dbffe69 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1 @@
-/Params-Validate-1.13.tar.gz
+/Params-Validate-1.16.tar.gz
diff --git a/perl-Params-Validate.spec b/perl-Params-Validate.spec
index 0f15f60..979c3d7 100644
--- a/perl-Params-Validate.spec
+++ b/perl-Params-Validate.spec
@@ -15,8 +15,8 @@
Summary: Params-Validate Perl module
Name: perl-Params-Validate
-Version: 1.13
-Release: 4%{?dist}
+Version: 1.16
+Release: 1%{?dist}
License: Artistic 2.0
Group: Development/Libraries
URL: http://search.cpan.org/dist/Params-Validate/
@@ -51,16 +51,21 @@ BuildRequires: perl(Readonly::XS)
%if %{with release_tests}
# For release testing tests
+BuildRequires: perl(Pod::Coverage::TrustPod)
+BuildRequires: perl(LWP::Protocol::https)
BuildRequires: perl(Test::CPAN::Changes)
BuildRequires: perl(Test::EOL)
BuildRequires: perl(Test::NoTabs)
+BuildRequires: perl(Test::LeakTrace)
BuildRequires: perl(Test::Pod) = 1.41
BuildRequires: perl(Test::Pod::Coverage) = 1.04
BuildRequires: perl(Test::Pod::LinkCheck)
BuildRequires: perl(Test::Pod::No404s)
-BuildRequires: perl(LWP::Protocol::https)
BuildRequires: perl(Test::Spelling)
+BuildRequires: perl(Test::Synopsis)
BuildRequires: aspell-en
+# Optional:
+BuildRequires: perl(Test::Portability::Files)
%endif
%{?perl_default_filter}
@@ -91,13 +96,17 @@ find $RPM_BUILD_ROOT -type d -depth -exec rmdir {}
2/dev/null ';'
%{?with_release_tests:RELEASE_TESTING=1} %{!?with_network:SKIP_POD_NO404S=1}
./Build test
%files
-%doc Changes LICENSE README TODO
+%doc Changes LICENSE TODO
%{perl_vendorarch}/Params
%{perl_vendorarch}/auto/Params
%{perl_vendorarch}/Attribute
%{_mandir}/man3/*
%changelog
+* Thu Jan 08 2015 Ralf Corsépius corse...@fedoraproject.org - 1.16-1
+- Upstream update.
+- Reflect upstream changes.
+
* Sun Sep 07 2014 Jitka Plesnikova jples...@redhat.com - 1.13-4
- Perl 5.20 re-rebuild of bootstrapped packages
diff --git a/sources b/sources
index d4d0bc4..8b90971 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-51061593757a172a98ce15097e2da5d6 Params-Validate-1.13.tar.gz
+616c869002972046a6b82d96687d09cb Params-Validate-1.16.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File Params-Validate-1.16.tar.gz uploaded to lookaside cache by corsepiu
A file has been added to the lookaside cache for perl-Params-Validate: 616c869002972046a6b82d96687d09cb Params-Validate-1.16.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: \n in taskotron's depcheck messages
On Wed, Jan 07, 2015 at 07:58:49AM -0700, Dave Johansen wrote: On Tue, Jan 6, 2015 at 4:12 PM, Kevin Fenzi ke...@scrye.com wrote: On Tue, 6 Jan 2015 16:04:07 -0700 Dave Johansen davejohan...@gmail.com wrote: I'm not sure if this is the right place to post this, but there are \n's in the messages from taskotron's depcheck. The problem is that some email clients (gmail in particular) parse that as part of the URL and make the links incorrect. It's a pretty minor thing, but would make it a lot easier to use and hopefully is an easy fix. Likely related to: https://fedorahosted.org/bodhi/ticket/767 Ya, that looks like the same issue. Good to hear it's already on the radar. Thanks, Dave This started occurring after we upgraded from postgresql-server-8.4.20-1.el6 to postgresql-server-9.2.7-1.el7, and is probably a python-sqlobject bug. I pushed out a new version of bodhi this morning that works around this issue in the mean time. luke pgpre_RVThIEP.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[perl-Params-Validate/f21] (4 commits) ...Merge cleanup.
Summary of changes: 7bc9eaf... Perl 5.20 rebuild (*) 76ccfc1... Perl 5.20 re-rebuild of bootstrapped packages (*) 57e96be... Upstream update. (*) 758c671... Merge cleanup. (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Params-Validate/f21: 4/4] Merge cleanup.
commit 758c6712f280f8208613dfc2b7feefb910df3cb4
Author: Ralf Corsépius corse...@fedoraproject.org
Date: Thu Jan 8 07:45:41 2015 +0100
Merge cleanup.
perl-Params-Validate.spec |6 --
1 files changed, 0 insertions(+), 6 deletions(-)
---
diff --git a/perl-Params-Validate.spec b/perl-Params-Validate.spec
index 979c3d7..f75ec1f 100644
--- a/perl-Params-Validate.spec
+++ b/perl-Params-Validate.spec
@@ -107,12 +107,6 @@ find $RPM_BUILD_ROOT -type d -depth -exec rmdir {}
2/dev/null ';'
- Upstream update.
- Reflect upstream changes.
-* Sun Sep 07 2014 Jitka Plesnikova jples...@redhat.com - 1.13-4
-- Perl 5.20 re-rebuild of bootstrapped packages
-
-* Fri Aug 29 2014 Jitka Plesnikova jples...@redhat.com - 1.13-3
-- Perl 5.20 rebuild
-
* Sun Aug 17 2014 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 1.13-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_21_22_Mass_Rebuild
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-POSIX-strftime-Compiler] Upstream update.
commit c79c330a3822a2c1c40363adc77fbb3de68ccb57
Author: Ralf Corsépius corse...@fedoraproject.org
Date: Thu Jan 8 08:24:34 2015 +0100
Upstream update.
- Remove BR: perl(CPAN::Meta), BR: perl(CPAN::Meta::Prereqs).
.gitignore|2 +-
perl-POSIX-strftime-Compiler.spec | 10 ++
sources |2 +-
3 files changed, 8 insertions(+), 6 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index f57e06e..09c2552 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1 @@
-/POSIX-strftime-Compiler-0.40.tar.gz
+/POSIX-strftime-Compiler-0.41.tar.gz
diff --git a/perl-POSIX-strftime-Compiler.spec
b/perl-POSIX-strftime-Compiler.spec
index 8b88eb5..05195c7 100644
--- a/perl-POSIX-strftime-Compiler.spec
+++ b/perl-POSIX-strftime-Compiler.spec
@@ -1,6 +1,6 @@
Name: perl-POSIX-strftime-Compiler
-Version:0.40
-Release:2%{?dist}
+Version:0.41
+Release:1%{?dist}
Summary:GNU C library compatible strftime for loggers and servers
License:GPL+ or Artistic
Group: Development/Libraries
@@ -10,8 +10,6 @@ Source0:
http://www.cpan.org/authors/id/K/KA/KAZEBURO/POSIX-strftime-Comp
BuildArch: noarch
BuildRequires: perl = 0:5.008004
BuildRequires: perl(Carp)
-BuildRequires: perl(CPAN::Meta)
-BuildRequires: perl(CPAN::Meta::Prereqs)
BuildRequires: perl(Exporter)
BuildRequires: perl(File::Basename)
BuildRequires: perl(File::Spec)
@@ -54,6 +52,10 @@ find $RPM_BUILD_ROOT -depth -type d -exec rmdir {}
2/dev/null \;
%{_mandir}/man3/*
%changelog
+* Thu Jan 08 2015 Ralf Corsépius corse...@fedoraproject.org - 0.41-1
+- Upstream update.
+- Remove BR: perl(CPAN::Meta), BR: perl(CPAN::Meta::Prereqs).
+
* Wed Aug 27 2014 Jitka Plesnikova jples...@redhat.com - 0.40-2
- Perl 5.20 rebuild
diff --git a/sources b/sources
index fc9eb43..abb4f2d 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-6b6fb6e767c42443c0bf91ccd82e34d3 POSIX-strftime-Compiler-0.40.tar.gz
+3cb849778e00f5d3894e7e78c2e629ce POSIX-strftime-Compiler-0.41.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File POSIX-strftime-Compiler-0.41.tar.gz uploaded to lookaside cache by corsepiu
A file has been added to the lookaside cache for perl-POSIX-strftime-Compiler: 3cb849778e00f5d3894e7e78c2e629ce POSIX-strftime-Compiler-0.41.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Params-Validate/f20: 7/7] Merge cleanup.
commit 2613abe81499863d258b848b01d03a37c90a4789
Author: Ralf Corsépius corse...@fedoraproject.org
Date: Thu Jan 8 07:48:53 2015 +0100
Merge cleanup.
perl-Params-Validate.spec |3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
---
diff --git a/perl-Params-Validate.spec b/perl-Params-Validate.spec
index e52ea60..0d5ad74 100644
--- a/perl-Params-Validate.spec
+++ b/perl-Params-Validate.spec
@@ -107,9 +107,6 @@ find $RPM_BUILD_ROOT -type d -depth -exec rmdir {}
2/dev/null ';'
- Upstream update.
- Reflect upstream changes.
-* Sun Aug 17 2014 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 1.13-2
-- Rebuilt for https://fedoraproject.org/wiki/Fedora_21_22_Mass_Rebuild
-
* Mon Jun 30 2014 Ralf Corsépius corse...@fedoraproject.org - 1.13-1
- Upstream update.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Params-Validate/f20] (7 commits) ...Merge cleanup.
Summary of changes: 4852e3c... - Rebuilt for https://fedoraproject.org/wiki/Fedora_21_22_M (*) 7bc9eaf... Perl 5.20 rebuild (*) 76ccfc1... Perl 5.20 re-rebuild of bootstrapped packages (*) 57e96be... Upstream update. (*) 758c671... Merge cleanup. (*) 5700b58... Merge remote-tracking branch 'origin/f21' into f20 2613abe... Merge cleanup. (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Params-Validate/f20: 6/7] Merge remote-tracking branch 'origin/f21' into f20
commit 5700b58b2f5b6ad6003ec5be96dc480b0f0330c7 Merge: 316d30b 758c671 Author: Ralf Corsépius corse...@fedoraproject.org Date: Thu Jan 8 07:48:25 2015 +0100 Merge remote-tracking branch 'origin/f21' into f20 .gitignore|2 +- perl-Params-Validate.spec | 18 +++--- sources |2 +- 3 files changed, 17 insertions(+), 5 deletions(-) --- -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Deleting f20-gnome-3-12 copr
Hi On Wed, Jan 7, 2015 at 4:18 PM, Stephen Gallagher wrote: /me reiterates his usual argument that we need to have a graphical fedup front-end in Workstation to help people upgrade when it's time... That is kind of a basic requirement. We need to do more. We need to inform people when their release is going EOL and we also need to automatically prompt users to upgrade whenever there is a new release (ie) some integration between GNOME Software/Apper and Fedup Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [EPEL-devel] [EPEL] #29: Make sure RHEL 7 mariadb update migrates into EPEL 7 buildroot
#29: Make sure RHEL 7 mariadb update migrates into EPEL 7 buildroot --+ Reporter: ellert | Owner: epel-wranglers Type: defect | Status: closed Priority: major| Milestone: Component: Package request |Version: Resolution: fixed| Keywords: --+ Comment (by ellert): Worked this time: https://koji.fedoraproject.org/koji/taskinfo?taskID=8551058 Thank you for looking in to it. -- Ticket URL: https://fedorahosted.org/epel/ticket/29#comment:4 EPEL https://fedoraproject.org/wiki/EPEL Extra Packages for Enterprise Linux ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
[Bug 1176933] perl-Filter-1.53 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1176933 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version|perl-Filter-1.53-1.fc22 |perl-Filter-1.53-1.fc21 Resolution|--- |ERRATA Last Closed||2015-01-07 18:55:42 --- Comment #5 from Fedora Update System upda...@fedoraproject.org --- perl-Filter-1.53-1.fc21 has been pushed to the Fedora 21 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. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=Gvm7OhKxlua=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Mail bounce for packager carllibpst
I wanted to inquire about supporting an epel7 branch of f2c but my mail to f2c-owner bounced. Upon checking if there were multiple maintainers, I found only one carllibpst. It appears he only owns two packages so it's probably not a major issue but even his fas account name includes the package libpst which indicates to me he may have very limited interest in supporting packages. All that being said, does anyone have another method of getting a hold of him? Thanks, Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [EPEL-devel] [CentOS-devel] Meeting face to face CentOS Project and EPEL
- Original Message - From: Karanbir Singh kbsi...@centos.org To: centos-de...@centos.org, EPEL Development List epel-devel@lists.fedoraproject.org Sent: Thursday, January 1, 2015 8:27:16 PM Subject: [CentOS-devel] Meeting face to face CentOS Project and EPEL hi, crossposting this to centos-devel and epel-devel we are working to arrange a meeting with the EPEL folks at Fosdem 2015, on 31st Jan at 7pm ( venue to be confirmed ), to try and workout some options on how the two efforts might best co-ordinate. A key part of the conversation would also focus on how SIGs and other contributors to downstream repos in centos.org can interface with and set expectations on the epel repos. Everyone able to make it please let me know your names so I can track attendance and make reservations accordingly. Yes, I plan to be there. --Rich ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
[perl-List-MoreUtils] Created tag perl-List-MoreUtils-0.402-1.fc22
The lightweight tag 'perl-List-MoreUtils-0.402-1.fc22' was created pointing to: 95778ff... Update to 0.402 -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Summary/Minutes from today's FESCo Meeting (2015-01-07)
=== #fedora-meeting: FESCO (2015-01-07) === Meeting started by sgallagh at 18:01:22 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2015-01-07/fesco.2015-01-07-18.01.log.html . Meeting summary --- * init process (sgallagh, 18:01:22) * #1372 Workstation Product defaults to wide-open firewall (sgallagh, 18:04:36) * AGREED: FESCo trusts the Workstation WG to properly research and develop a sensible firewall solution and will stay out of the way. (+5, 3, -0) (sgallagh, 18:40:04) * sgallagh volunteers to act as a security consultant to the Workstation team if they are interested. (sgallagh, 18:41:07) * #1349 Fedora 22 scheduling strategy (and beyond) (sgallagh, 18:41:13) * LINK: http://fedoraproject.org/wiki/Releases/22/Schedule (mattdm, 18:43:55) * change submission deadline in _less than two weeks_ (mattdm, 18:44:51) * AGREED: FESCo would like for F22 to strictly adhere to a schedule, rather than adjusting the schedule based on submitted features. We intend to enforce the contingency plan very strictly this cycle (+8, 0, -0) (sgallagh, 19:04:19) * Tentative date for side-tag merge is 2015-01-28 (sgallagh, 19:09:55) * Tentative date for mass rebuild (if needed) is 2015-01-30 (sgallagh, 19:10:05) * ACTION: jreznik to send schedule reminder announcement (sgallagh, 19:12:05) * AGREED: FESCo approves the current proposed schedule with a planned final delivery on 2015-05-19 (+8, 0, -0) (sgallagh, 19:15:08) * #1198 Possible changes to Fedora EOL bug procedure (sgallagh, 19:17:46) * F19 EOL warning will be sent today. We will auto-close all remaining bugs in one month. (sgallagh, 19:28:14) * #1378 F22 System Wide Change: Elasticsearch - https://fedoraproject.org/wiki/Changes/Elasticsearch (sgallagh, 19:28:23) * AGREED: Change is approved. The approach is OK, please resubmit with a real contingency plan. (+7, 0, -1) (sgallagh, 19:51:03) * #1379 F22 System Wide Change: Change xorg input stack to use libinput - https://fedoraproject.org/wiki/Changes/LibinputForXorg (sgallagh, 19:51:28) * AGREED: Approved with two caveats: 1) Both GNOME and KDE must be updated by the contingency date or it goes into effect and 2) the contingency plan should note that it will may require reverting changes to the control panels as well. (+7, 0, -0) (sgallagh, 19:57:46) * #1380 F22 System Wide Change: wxPython 3 - https://fedoraproject.org/wiki/Changes/wxPython3 (sgallagh, 19:58:16) * AGREED: Change is approved. (+7, 0, -0) (sgallagh, 20:04:45) * Next week's chair (sgallagh, 20:04:53) * mattdm to chair next week's meeting (sgallagh, 20:06:14) * Elections (sgallagh, 20:06:19) * LINK: http://fedoraproject.org/wiki/Elections (jreznik_pp, 20:07:08) * LINK: https://fedoraproject.org/wiki/Elections (sgallagh, 20:07:12) * Elections will open for nominations on January 13th. Voting will open on January 27th. (sgallagh, 20:11:57) * Open Floor (sgallagh, 20:12:03) Meeting ended at 20:13:30 UTC. Action Items * jreznik to send schedule reminder announcement Action Items, by person --- * jreznik * jreznik to send schedule reminder announcement * **UNASSIGNED** * (none) People Present (lines said) --- * sgallagh (196) * mattdm (87) * nirik (86) * mitr (73) * jreznik (71) * jwb (68) * t8m (60) * kalev (35) * thozza (27) * hadess (22) * drago01 (20) * zodbot (18) * jreznik_pp (13) * twoerner (12) * mcatanzaro (5) * mclasen (5) * mmaslano (0) * stickster (0) * dgilmore (0) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Deleting f20-gnome-3-12 copr
On 7 January 2015 at 09:47, Pete Travis li...@petetravis.com wrote: On Jan 7, 2015 7:23 AM, drago01 drag...@gmail.com wrote: On Wed, Jan 7, 2015 at 3:13 PM, Pete Travis li...@petetravis.com wrote: On Jan 7, 2015 6:00 AM, Richard Hughes hughsi...@gmail.com wrote: I'm planning to delete https://copr.fedoraproject.org/coprs/rhughes/f20-gnome-3-12/ this week. The original description always had This COPR will be updated until Fedora 21 has been released or until the entropy death of the universe, whichever happens first. so I don't altogether feel too guilty about abandoning it. Does anyone have any objections or wants to volunteer to take it over before I delete the repo? Richard -- While recognizing the massive maintenance burden of this COPR, I suspect the majority of objections will come from the enthusiast end user type - you know, the ones that are so eager to try the new thing they read about that they blow right past the description. Well one might think that those kind of users have updated to F21 to get the new shiny stuff anyway. -- The kind of users that are always driving for the latest shiny thing, yes. The users that read about some shiny thing on the internet, were interested, and plowed through the instructions without really understanding the implications, no. I'm just suggesting a little courtesy and further instruction for the latter. In any case, there *will* be some perplexed folks out there when it gets turned off. I can share links when I see them if you like :) We have all been on the Internet long enough to know that there is a segment of users who will complain even if they had been hand delivered notes that stuff was EOL. I think just doing what you originally suggested and mailing to announce and possibly Fedora Magazine will suffice. :) -- Stephen J Smoogen. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [EPEL-devel] [EPEL] #29: Make sure RHEL 7 mariadb update migrates into EPEL 7 buildroot
#29: Make sure RHEL 7 mariadb update migrates into EPEL 7 buildroot --+ Reporter: ellert | Owner: epel-wranglers Type: defect | Status: new Priority: major| Milestone: Component: Package request |Version: Resolution: | Keywords: --+ Comment (by ellert): It has now been two days and I still get the old broken mariadb-devel in the koji EPEL 7 buildroot: https://koji.fedoraproject.org/koji/taskinfo?taskID=8549403 An EPEL 7 local mock build works now since it uses the updated package. Is there some hiccup somewhere? -- Ticket URL: https://fedorahosted.org/epel/ticket/29#comment:2 EPEL https://fedoraproject.org/wiki/EPEL Extra Packages for Enterprise Linux ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: F22 System Wide Change: Harden all packages with position-independent code
On Wed, Jan 7, 2015 at 5:30 AM, Josh Boyer jwbo...@fedoraproject.org wrote: We just went over something very much like this for x86_64 packages with FESCo ticket 1113: https://fedorahosted.org/fesco/ticket/1113 Could you perhaps review that and elaborate on the differences between that proposal and this one if there are any? Additionally, could you cover any of the concerns listed there that apply to this proposal? josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Hi Josh, That ticket is over 20 months old. It was discussed at time when Fedora 19 was in beta stage. I believe alot has changed since then. Since Fedora 20 pre-link is already disabled by default. The security landscape has changed. With the major publicity from Heartbleed and ShellShock, I believe more people are now security conscious than before. Hopefully, they will understand the need for compromise in system performance in order to protect the system from being exploited. For example: here http://lcamtuf.blogspot.com/2014/10/psa-dont-run-strings-on-untrusted-files.html (CVE-2014-8485) it states Many Linux distributions ship *strings* without ASLR, making potential attacks easier and more reliable - a situation reminiscent of one of the recent bugs in *bash*. Which links here: http://lcamtuf.blogspot.com/2014/10/bash-bug-how-we-finally-cracked.html (CVE-2014-6277) and (CVE-2014-6278) and states The issue is also made worse by the fact that only relatively few distributions were building bash as a position-independent executable that could be fully protected by ASLR. -Moez -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Harden all packages with position-independent code
I originally made a request to rel-eng here: https://fedorahosted.org/rel-eng/ticket/6049 - Long running packages in F21 that 'MUST enable the PIE compiler flags' Here https://fedoraproject.org/wiki/Packaging:Guidelines#PIE it says If your package meets any of the following criteria you MUST enable the PIE compiler flags: Your package is long running. This means it's likely to be started and kept running until the machine is rebooted... [root@localhost liveuser]# checksec --proc-all | grep No PIE Xorg.bin 1037 Partial RELRO Canary found NX enabledNo PIE gnome-session 1227 Partial RELRO Canary found NX enabledNo PIE at-spi-bus-laun 1300 Partial RELRO Canary found NX enabledNo PIE at-spi2-registr 1308 Partial RELRO Canary found NX enabledNo PIE gvfsd 1318 Partial RELRO Canary found NX enabledNo PIE gvfsd-fuse 1322 Partial RELRO Canary found NX enabledNo PIE gnome-settings- 1339 Partial RELRO Canary found NX enabledNo PIE gnome-keyring-d 1344 Partial RELRO Canary found NX enabledNo PIE gnome-shell 1455 Partial RELRO Canary found NX enabledNo PIE gsd-printer 1486 Partial RELRO Canary found NX enabledNo PIE dconf-service 1504 Partial RELRO Canary found NX enabledNo PIE gnome-shell-cal 1514 Partial RELRO Canary found NX enabledNo PIE evolution-sourc 1520 Partial RELRO Canary found NX enabledNo PIE goa-daemon 1526 Partial RELRO Canary found NX enabledNo PIE ibus-daemon 1530 Partial RELRO Canary found NX enabledNo PIE mission-control 1534 Partial RELRO Canary found NX enabledNo PIE ibus-dconf 1541 Partial RELRO Canary found NX enabledNo PIE ibus-x11 1543 Partial RELRO Canary found NX enabledNo PIE caribou 1571 Partial RELRO Canary found NX enabledNo PIE gvfs-udisks2-vo 1586 Partial RELRO Canary found NX enabledNo PIE gvfs-afc-volume 1594 Partial RELRO Canary found NX enabledNo PIE gvfs-mtp-volume 1600 Partial RELRO Canary found NX enabledNo PIE gvfs-gphoto2-vo 1605 Partial RELRO Canary found NX enabledNo PIE gvfs-goa-volume 1610 Partial RELRO Canary found NX enabledNo PIE evolution-alarm 1662 Partial RELRO Canary found NX enabledNo PIE tracker-miner-a 1665 Partial RELRO Canary found NX enabledNo PIE tracker-store 1670 Partial RELRO Canary found NX enabledNo PIE seapplet 1671 Partial RELRO Canary found NX enabledNo PIE tracker-extract 1676 Partial RELRO Canary found NX enabledNo PIE tracker-miner-u 1680 Partial RELRO Canary found NX enabledNo PIE gnome-software 1681 Partial RELRO Canary found NX enabledNo PIE tracker-miner-f 1683 Partial RELRO Canary found NX enabledNo PIE evolution-calen 1710 Partial RELRO Canary found NX enabledNo PIE ibus-engine-sim 1740 Partial RELRO No canary foundNX enabledNo PIE gnome-terminal- 1870 Partial RELRO Canary found NX enabledNo PIE gconfd-2 1876 Partial RELRO Canary found NX enabledNo PIE bash 1879 Partial RELRO Canary found NX enabledNo PIE bash 1910 Partial RELRO Canary found NX enabledNo PIE firefox 5931 Partial RELRO Canary found NX enabledNo PIE gvfsd-metadata 6054 Partial RELRO Canary found NX enabledNo PIE oosplash 6140 Partial RELRO Canary found NX enabledNo PIE gvfsd-burn 6166 Partial RELRO Canary found NX enabledNo PIE soffice.bin 6227 Partial RELRO No canary foundNX enabledNo PIE evince 6278 Partial RELRO Canary found NX enabledNo PIE gvfsd-trash 6296 Partial RELRO Canary found NX enabledNo PIE nautilus 6319 Partial RELRO Canary found NX enabledNo PIE bash 6339 Partial RELRO Canary found NX enabledNo PIE python 6366 Partial RELRO No canary foundNX enabledNo PIE sedispatch678 Partial RELRO Canary found NX enabledNo PIE firewalld722 Partial RELRO No canary foundNX enabledNo PIE mcelog728 Partial RELRO Canary found NX enabledNo PIE grep 8620 Partial RELRO Canary found NX enabledNo PIE [root@localhost
Re: Deleting f20-gnome-3-12 copr
On Wed, 2015-01-07 at 16:15 +, Richard Hughes wrote: On 7 January 2015 at 16:01, Bill Nottingham nott...@splat.cc wrote: While I'm not volunteeering to maintain this, I do ask - what is the reason for deleting it vs. just leaving it around in a EOL state where it's not being updated? There are a couple of packages with security bugs. Unfortunately, deleting the repo doesn't do anything to address that. Either way, anyone currently running it won't be able to update away from it (short of upgrading to Fedora 21). /me reiterates his usual argument that we need to have a graphical fedup front-end in Workstation to help people upgrade when it's time... signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [EPEL-devel] [CentOS-devel] Meeting face to face CentOS Project and EPEL
Karanbir Singh wrote: we are working to arrange a meeting with the EPEL folks at Fosdem 2015, on 31st Jan at 7pm ( venue to be confirmed ), to try and workout some options on how the two efforts might best co-ordinate. A key part of the conversation would also focus on how SIGs and other contributors to downstream repos in centos.org can interface with and set expectations on the epel repos. I will be at FOSDEM too, and would like to see how CentOS can work better with EPEL to provide a better Xfce experience - possibly through a SIG... Either the proposed Alternative Desktop SIG, or a Xfce SIG like in Fedora. The goal would be a good CentOS Xfce experience, and possibly a live spin. https://fedoraproject.org/wiki/SIGs/Xfce http://spins.fedoraproject.org/xfce/ http://dl.fedoraproject.org/pub/epel/6/x86_64/repoview/xfce-desktop.group.html http://dl.fedoraproject.org/pub/epel/7/x86_64/repoview/xfce-desktop.group.html --anders ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: Ramblings and questions regarding Fedora, but stemming from gnome-software and desktop environments
/*Bill Nottingham nott...@splat.cc*/ wrote on Wed, 7 Jan 2015 10:56:31 -0500: Hedayat Vatankhah (hedayat@gmail.com) said: /*Bill Nottingham nott...@splat.cc*/ wrote on Tue, 6 Jan 2015 11:39:27 -0500: ... - Even searching for -devel packages implies a target == host build sensibility that is relevant mostly to those developing Fedora, and not to most of those developers that I run into on a day-to-day basis (and likely not the developers we're targeting.) They're interested in using mock along with system libraries for RHEL/CentOS, using pip/npm/rubygems, etc. So you mean that Fedora target developers are either using dynamic languages, or they develop native software for RHEL/CentOS?! So you believe that target == rhel/centos? And native software developers for *modern* distros are not targets? This is really offending. RHEL/CentOS themselves should mainly target their developers. I guess that most of the developers you run into are working for RedHat. ... Not at Red Hat now, but what I'm saying is that the developers I interact with are targeting mainly Ubuntu LTS and CentOS/RHEL, even if their devel platform is Fedora. It goes back to uses of Fedora in production - while Fedora Server certainly wants to change this, most all of the *deployed* server systems that people are targeting for their code aren't Fedora. Once you assume that you want to support the use case of developers using Fedora to develop for things that aren't Fedora, I just feel that worrying about a package tool for installing -devel packages pales in trying to streamline the workflows the developers needs around using things like mock and jenkins as build tools, and test environments that aren't even local to the machine at all, whether they involve virtualization, containers, or remote cloud services. Well, I agree completely that solving the issue of installing -devel packages is not enough to make Fedora suitable for developers; but it is certainly needed. However, it would be even better if Fedora can be a great general purpose development platform supporting development for other targets such as RHEL/CentOS, Ubuntu and even Windows (using mingw toolchain + wine, and then maybe virtual environments/remote access to run/test/debug on real Windows OS); which could expand to development for embedded devices/OSes like Android. But, IMHO, support for none of these should be more important than native Fedora development; specially since targeting OSes like RHEL/CentOS/Ubuntu LTS is usually important for developers for commercial software. Someone who is developing free(open source) software usually prefers to use 'latest and greatest', for which usually Fedora and it's -devel packages are one of the best things available out there. And I think free software developers should be top priority for Fedora compared to others. There is nothing wrong with supporting others, but the main target developers should be free software developers, and they are less likely to need using mock or RHEL system libraries. Regards, Hedayat Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Deleting f20-gnome-3-12 copr
On Wed, Jan 7, 2015 at 3:48 PM, Matěj Cepl mc...@cepl.eu wrote: On 2015-01-07, 14:13 GMT, Pete Travis wrote: While recognizing the massive maintenance burden of this COPR, I suspect the majority of objections will come from the enthusiast end user type - you know, the ones that are so eager to try the new thing they read about that they blow right past the description. This COPR received a lot of publicity; fedoramagazine articles, social media, blog posts, etc. Shouldn't such COPR be part of Rawhide anyway? What does that even mean? The packages where in rawhide at that time. The purpose of the COPR was to provide it to people who do *not* want to run rawhide. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Deleting f20-gnome-3-12 copr
On Wed, Jan 07, 2015 at 03:23:27PM +0100, drago01 wrote: On Wed, Jan 7, 2015 at 3:13 PM, Pete Travis li...@petetravis.com wrote: On Jan 7, 2015 6:00 AM, Richard Hughes hughsi...@gmail.com wrote: I'm planning to delete https://copr.fedoraproject.org/coprs/rhughes/f20-gnome-3-12/ this week. The original description always had This COPR will be updated until Fedora 21 has been released or until the entropy death of the universe, whichever happens first. so I don't altogether feel too guilty about abandoning it. Does anyone have any objections or wants to volunteer to take it over before I delete the repo? Richard -- While recognizing the massive maintenance burden of this COPR, I suspect the majority of objections will come from the enthusiast end user type - you know, the ones that are so eager to try the new thing they read about that they blow right past the description. Well one might think that those kind of users have updated to F21 to get the new shiny stuff anyway. Announcing to the following should do the trick for those who haven't boarded the F21 boat: (1) announce@ (echoed to users@) (2) Fedora Magazine (echoed per usual to social media) -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ The open source story continues to grow: http://opensource.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Bug 1179255] Rebuild for new xz-5.2.0
https://bugzilla.redhat.com/show_bug.cgi?id=1179255 Paul Howarth p...@city-fan.org changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-Compress-Raw-Lzma-2.06 ||8-2.fc22 Resolution|--- |RAWHIDE Last Closed||2015-01-07 10:01:48 --- Comment #3 from Paul Howarth p...@city-fan.org --- Build done: http://koji.fedoraproject.org/koji/taskinfo?taskID=8547242 -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=KaoxzXH4mqa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
F22 System Wide Change: Ruby 2.2
= Proposed System Wide Change: Ruby 2.2 = https://fedoraproject.org/wiki/Changes/Ruby_2.2 Change owner(s): Vít Ondruch vondr...@redhat.com Ruby 2.2 is the latest stable version of Ruby. Many new features and improvements are included for the increasingly diverse and expanding demands for Ruby. With this major update from Ruby 2.1 in Fedora 21 to Ruby 2.2 in Fedora 22, alongside JRuby, Fedora becomes the superior Ruby development platform. == Detailed Description == Ruby 2.2 is upstream's new major release of Ruby. Notable changes are: * Incremental GC * Symbol GC * core libraries: ** Support Unicode 7.0 ** New methods in Enumerable, Float, File and String classes * bundled libraries ** Updated Psych 2.0.6, Rake 10.4.0, RDoc 4.2.0, Update RubyGems 2.4.4+, test- unit 3.0.7, minitest 5.4.3 ** Deprecate mathn, DL * C API ** Remove deprecated APIs Ruby 2.2 is source level backward compatible with Ruby 2.1, so your software will continue to work. == Scope == * Proposal owners: ** Finish packaging of Ruby 2.2. Current changes available in private-ruby-2.2 branch of ruby package in dist-git. ** Rebuilding of Ruby packages providing native extensions (i.e. packages which depends on libruby). * Other developers: ** Rebuild of packages with binary extensions (i.e. packages which depends on libruby) will be handled automatically, but some packages might need fixes/updates to support Ruby 2.2 properly. * Release engineering: ** Separate Koji tag for package rebuild will be needed. The same tag will be used for Ruby on Rails 4.2 change proposal as well. * Policies and guidelines: ** Since testrb tool suggested by guidelines to execute test suite was deprecated, the packaging guidelines needs minor update to reflect this change (fortunately this change was already reflected in most packages). ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Bug 1179255] Rebuild for new xz-5.2.0
https://bugzilla.redhat.com/show_bug.cgi?id=1179255 Bug 1179255 depends on bug 1023718, which changed state. Bug 1023718 Summary: xz-5.2.0 [stable] is available https://bugzilla.redhat.com/show_bug.cgi?id=1023718 What|Removed |Added Status|MODIFIED|CLOSED Resolution|--- |RAWHIDE -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=V93653JeN9a=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1179255] Rebuild for new xz-5.2.0
https://bugzilla.redhat.com/show_bug.cgi?id=1179255 --- Comment #2 from Pavel Raiskup prais...@redhat.com --- (In reply to Paul Howarth from comment #1) let me know when 5.2.0 is available in Rawhide Done. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=ksTK3yyULga=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Compress-Raw-Lzma] Rebuild for xz-5.2.0 in Rawhide (#1179255)
commit 261beec74192928998eb8a0c87541a406112f455
Author: Paul Howarth p...@city-fan.org
Date: Tue Jan 6 19:34:22 2015 +
Rebuild for xz-5.2.0 in Rawhide (#1179255)
perl-Compress-Raw-Lzma.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Compress-Raw-Lzma.spec b/perl-Compress-Raw-Lzma.spec
index 0abf3c5..80e0720 100644
--- a/perl-Compress-Raw-Lzma.spec
+++ b/perl-Compress-Raw-Lzma.spec
@@ -1,6 +1,6 @@
Name: perl-Compress-Raw-Lzma
Version: 2.068
-Release: 1%{?dist}
+Release: 2%{?dist}
Summary: Low-level interface to lzma compression library
Group: Development/Libraries
License: GPL+ or Artistic
@@ -69,6 +69,9 @@ make test
%{_mandir}/man3/Compress::Raw::Lzma.3*
%changelog
+* Tue Jan 6 2015 Paul Howarth p...@city-fan.org - 2.068-2
+- Rebuild for xz-5.2.0 in Rawhide (#1179255)
+
* Wed Dec 24 2014 Paul Howarth p...@city-fan.org - 2.068-1
- Update to 2.068 (no changes)
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: \n in taskotron's depcheck messages
On Tue, Jan 6, 2015 at 4:12 PM, Kevin Fenzi ke...@scrye.com wrote: On Tue, 6 Jan 2015 16:04:07 -0700 Dave Johansen davejohan...@gmail.com wrote: I'm not sure if this is the right place to post this, but there are \n's in the messages from taskotron's depcheck. The problem is that some email clients (gmail in particular) parse that as part of the URL and make the links incorrect. It's a pretty minor thing, but would make it a lot easier to use and hopefully is an easy fix. Likely related to: https://fedorahosted.org/bodhi/ticket/767 Ya, that looks like the same issue. Good to hear it's already on the radar. Thanks, Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Bug 1179566] perl-Date-Calc-6.3-17.fc22 FTBFS: tests fail
https://bugzilla.redhat.com/show_bug.cgi?id=1179566 Petr Šabata psab...@redhat.com changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-Date-Calc-6.3-18.fc22 Resolution|--- |RAWHIDE Last Closed||2015-01-07 09:59:41 -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=okNrweq2tNa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: System-wide crypto policy transition tracker
On Wed, 7 Jan 2015, Petr Spacek wrote: The tracker also contains a dependency on NSS respecting the system crypto policy: https://bugzilla.redhat.com/show_bug.cgi?id=1157720 I wonder what is your plan moving forward. Is it going to be 'TLS policy'? Or are you planning to generalize it in future? E.g. DNSSEC-related software can be configured which algorithm list and key sizes too. I guess that the same applies to GnuPG. In other words, should the policy be able to express something like 'do not trust MD5, SHA1, DES, RC4, RSA 1024 bits anymore' But you cannot make such a statement covering such widely different deployments of crypto. HMAC-MD5 in IPsec is quite different from MD5 in CA certificates which is different from MD5 in DNSSEC. If you want to make statements about what is deemed unsafe for use, you quickly end up at something like the various NIST BCPs/FIPS standards. IMHO it would be extremely handy - it would allow us to quickly react when something is seriously broken without patching all affected applications in Fedora. Are you suggesting fedora moves to FIPS=1? :) Fedora isn't as tighly regulated for crypto libraries or crypto settings as RHEL is. It takes a lot of efford to find software that has private copies of functions (like MD5 hashing copied from ssleay/openssl) and sometimes it is not even used for security (eg squid cache objects use a private md5 function) and I probably don't want to know what packages do for random. Raising the bar to IETF standards or NIST FIPS requirements might be good though. The fedora software that is also shipped in RHEL should already meet those requirements. Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Ramblings and questions regarding Fedora, but stemming from gnome-software and desktop environments
Hedayat Vatankhah (hedayat@gmail.com) said: /*Bill Nottingham nott...@splat.cc*/ wrote on Tue, 6 Jan 2015 11:39:27 -0500: ... - Even searching for -devel packages implies a target == host build sensibility that is relevant mostly to those developing Fedora, and not to most of those developers that I run into on a day-to-day basis (and likely not the developers we're targeting.) They're interested in using mock along with system libraries for RHEL/CentOS, using pip/npm/rubygems, etc. So you mean that Fedora target developers are either using dynamic languages, or they develop native software for RHEL/CentOS?! So you believe that target == rhel/centos? And native software developers for *modern* distros are not targets? This is really offending. RHEL/CentOS themselves should mainly target their developers. I guess that most of the developers you run into are working for RedHat. ... Not at Red Hat now, but what I'm saying is that the developers I interact with are targeting mainly Ubuntu LTS and CentOS/RHEL, even if their devel platform is Fedora. It goes back to uses of Fedora in production - while Fedora Server certainly wants to change this, most all of the *deployed* server systems that people are targeting for their code aren't Fedora. Once you assume that you want to support the use case of developers using Fedora to develop for things that aren't Fedora, I just feel that worrying about a package tool for installing -devel packages pales in trying to streamline the workflows the developers needs around using things like mock and jenkins as build tools, and test environments that aren't even local to the machine at all, whether they involve virtualization, containers, or remote cloud services. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Deleting f20-gnome-3-12 copr
Pete Travis (li...@petetravis.com) said: On Jan 7, 2015 6:00 AM, Richard Hughes hughsi...@gmail.com wrote: I'm planning to delete https://copr.fedoraproject.org/coprs/rhughes/f20-gnome-3-12/ this week. The original description always had This COPR will be updated until Fedora 21 has been released or until the entropy death of the universe, whichever happens first. so I don't altogether feel too guilty about abandoning it. Does anyone have any objections or wants to volunteer to take it over before I delete the repo? Richard -- While recognizing the massive maintenance burden of this COPR, I suspect the majority of objections will come from the enthusiast end user type - you know, the ones that are so eager to try the new thing they read about that they blow right past the description. This COPR received a lot of publicity; fedoramagazine articles, social media, blog posts, etc. While I'm not volunteeering to maintain this, I do ask - what is the reason for deleting it vs. just leaving it around in a EOL state where it's not being updated? We don't remove EOL releases, for example. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [EPEL-devel] [EPEL] #29: Make sure RHEL 7 mariadb update migrates into EPEL 7 buildroot
#29: Make sure RHEL 7 mariadb update migrates into EPEL 7 buildroot --+ Reporter: ellert | Owner: epel-wranglers Type: defect | Status: closed Priority: major| Milestone: Component: Package request |Version: Resolution: fixed| Keywords: --+ Changes (by kevin): * resolution: = fixed * status: new = closed Comment: ok. I think I found where it was caching when it should not have been. Can you please retry your build now? -- Ticket URL: https://fedorahosted.org/epel/ticket/29#comment:3 EPEL https://fedoraproject.org/wiki/EPEL Extra Packages for Enterprise Linux ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: F22 System Wide Change: Harden all packages with position-independent code
Am 07.01.2015 um 23:04 schrieb Till Maas: On Wed, Jan 07, 2015 at 08:30:03AM -0500, Josh Boyer wrote: We just went over something very much like this for x86_64 packages with FESCo ticket 1113: https://fedorahosted.org/fesco/ticket/1113 Could you perhaps review that and elaborate on the differences between that proposal and this one if there are any? Additionally, could you cover any of the concerns listed there that apply to this proposal? I proposed to make it the default for all archs and not only x86_64. From what I understand, the only reason it was not accepted is because it was felt that the performance penalty is not worth the security gains from this. I do not have objective numbers about how many exploits that happened could be prevented with PIE and how many effort it took to clean up after exploits compared to how much the performance penalty for PIE costs. in doubt a successful exploit does that much damage that you no longer bother about some percent of performance and i really don't understand all that performance discussions i built *all* server packages running on our Fedora machines *long before* -fstack-protector-strong became available with -fstack-protector-all and i really care about every piece of performance but not for the price of lower security yes i maintain all my apache, postfix, dovecot, mysql, php and what not packages in a own repo with maximized security options for 7 years now and any tool not in the Fedora repos get a hardened build too *but* i do not care about 5% performance because the time, money and reputation impact caused by a successful exploit destroying and leaking user data justifies to protect with all available technology and in doubt if you need the 5% performance it justifies just go out and buy a faster machine yes, i talk about servers - because on a workstation it *really* don't matter if LibreOffice the first time of a day starts a second longer except for beenchmarking as digital p*** enlargement However, the experts that I talked about this think the protection is worth it. I was also told that there were exploits where PIE helped to mitigate them. i asked after Shellshock and reading that one of the issues would have been mitigated on teh security list and referred to the 20 month old tickt Nevertheless, nevertheless, thank you for the ticket link, it contains a lot of interesting information. However it is said that even though the packaging guidelines were mentioned there, they were kept in an unclear/contradictory state. But this is also a new data point, even though it was highlighted more 20 months ago to FeSCo, there are still a lot of packages violating the Guideline i filed *countless* bugreports for packages violating this in the past 2 years, many of them got fixed in the meantime the main problem is long running - look how many prcoesses are started on a ordinary desktop setup on-demand and than run forever and you get a picture frankly, even the browser, mailprogramm, messenger and so on are in fact *long running* even if they are not servcices because most users start them and have them running until logout, often over days and guess what - all of this apps are processing untrsuted data from the network, at the end of the day LibreOffice does too - just open a attachment from a email and hit a unfixed security bug which shows that the current process does not really work. And if PIE is not really considered to worth it, the guidelines should be adjusted to reflect this. Currently it does not seem to be the case that most/all packages that should be using PIE do not use it because maintainer actively decided against it, but just because it is not the default. The criteria for this is: | Your package accepts/processes untrusted input. This seems to be about every package that I use, because I most if not all tools process untrusted data from the Internet that's the point - in doubt even cat/grep prcoeed untrusted input from the web by watch a simple logfile, there where even exploits http://httpd.apache.org/security/vulnerabilities_22.html mod_rewrite does not filter terminal escape sequences from logs, which could make it easier for attackers to insert those sequences into terminal emulators containing vulnerabilities related to escape sequences. *every* application at the end of the day is at risk to proceed untrsuted input from the web - and if it is only because it has to deal with some download from the internt, in that context it don't matter if it is long running or not signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: smuxi builds stalled
On Wed, 07 Jan 2015 13:59:29 +0100 Antonio Trande anto.tra...@gmail.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all. Rawhide smuxi builds seem blocked on Koji; this is my third attempt: http://koji.fedoraproject.org/koji/taskinfo?taskID=8541548 No errors, but stopped. This is SPEC that generates Smuxi's RPMs: http://pkgs.fedoraproject.org/cgit/smuxi.git/tree/smuxi.spec This might be this (or related to this) mono problem: https://bugzilla.redhat.com/show_bug.cgi?id=1128499 kevin pgpykWdBQv_aw.pgp Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Harden all packages with position-independent code
On Wed, 7 Jan 2015 13:17:36 -0800 Moez Roy moez@gmail.com wrote: I originally made a request to rel-eng here: https://fedorahosted.org/rel-eng/ticket/6049 - Long running packages in F21 that 'MUST enable the PIE compiler flags' ...snip... The above packages don't seem to have PIE enabled. Some of them don't meet the 'long running' critera. They just happen to be running when you ran your check. Can someone from releng enable hardening on as many Long running packages as possible before the next F21 Release Candidate. No. This is not a releng task. This is something that should be done by (in order): - The maintainers of these packages. - Interested/motivated provenpackagers who want to make the changes and bring the packages in line with guidelines. - Some other group FESCo is able to task with it (which really might come down to just them). But since this change is for just globally enabling it, probibly the best thing to do is wait for this change to be accepted and a mass rebuild instead of worrying now about specific packages. kevin pgpfuD7sMWzn5.pgp Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Harden all packages with position-independent code
On Wed, Jan 07, 2015 at 08:30:03AM -0500, Josh Boyer wrote: We just went over something very much like this for x86_64 packages with FESCo ticket 1113: https://fedorahosted.org/fesco/ticket/1113 Could you perhaps review that and elaborate on the differences between that proposal and this one if there are any? Additionally, could you cover any of the concerns listed there that apply to this proposal? I proposed to make it the default for all archs and not only x86_64. From what I understand, the only reason it was not accepted is because it was felt that the performance penalty is not worth the security gains from this. I do not have objective numbers about how many exploits that happened could be prevented with PIE and how many effort it took to clean up after exploits compared to how much the performance penalty for PIE costs. However, the experts that I talked about this think the protection is worth it. I was also told that there were exploits where PIE helped to mitigate them. Nevertheless, nevertheless, thank you for the ticket link, it contains a lot of interesting information. However it is said that even though the packaging guidelines were mentioned there, they were kept in an unclear/contradictory state. But this is also a new data point, even though it was highlighted more 20 months ago to FeSCo, there are still a lot of packages violating the Guideline, which shows that the current process does not really work. And if PIE is not really considered to worth it, the guidelines should be adjusted to reflect this. Currently it does not seem to be the case that most/all packages that should be using PIE do not use it because maintainer actively decided against it, but just because it is not the default. The criteria for this is: | Your package accepts/processes untrusted input. This seems to be about every package that I use, because I most if not all tools process untrusted data from the Internet. Kind regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: What exactly is a bundled library? (was Re: apitrace, bundled libbacktrace)
On Tue, 2014-08-19 at 15:19 +0400, Pavel Alexeev wrote: 13.06.2014 01:42, Adam Williamson пишет: On Tue, 2014-05-13 at 18:56 +0200, Sandro Mani wrote: Hi, apitrace 5.0 bundles libbacktrace, which looks like is living within the gcc sources. libbacktrace is not build as a shared library from the gcc sources, and not packaged. Is it feasible to build libbacktrace as a shared library and ship it in a corresponding package? Or should I rather go for a bundling exception request? So in writing a reply to this, I noticed the guidelines around this are actually fairly unclear and subject to interpretation. The section on this topic from https://fedoraproject.org/wiki/Packaging:Guidelines reads: Duplication of system libraries A package should not include or build against a local copy of a library that exists on a system. The package should be patched to use the system libraries. This prevents old bugs and security holes from living on after the core system libraries have been fixed. In this RPM packaging context, the definition of the term 'library' includes: compiled third party source code resulting in shared or static linkable files, interpreted third party source code such as Python, PHP and others. At this time JavaScript intended to be served to a web browser on another computer is specifically exempted from this but this will likely change in the future. Note that for C and C++ there's only one system in Fedora but for some other languages we have parallel stacks. For instance, python, python3, jython, and pypy are all implementations of the python language but they are separate interpreters with slightly different implementations of the language. Each stack is considered its own system and can each contain its own copy of a library. *entirely* clear, though, really. The page https://fedoraproject.org/wiki/Packaging :No_Bundled_Libraries has all sorts of rationale and process stuff, but still no clear definition of precisely what it is that constitutes a bundled library. Even more confusingly, https://fedoraproject.org/wiki/Packaging :Treatment_Of_Bundled_Libraries seems to have a rather different definition from that given on Packaging:Guidelines. It reads: (bundled libraries being defined as libraries which exist and are mantained independently, whether or not they are packaged separately for Fedora) to me, that seems fundamentally different from the definition that is somewhat unclearly implied on the Packaging:Guidelines page. Has this been considered before? Is there a superior definition somewhere, or an accepted interpretation which is consistent with both pages? Do we in fact need a section in Packaging:Guidelines and then two separate 'subsidiary' pages all on the topic of bundled libraries? Would it make more sense to combine all the details onto a single subsidiary page and have Packaging:Guidelines just have a very short sort of 'summary' and a link to that one subsidiary page? Would that reduce the likelihood of confusion? Thanks! I've seen several cases in the Real World where 'bundled' libraries that are not a part of the Fedora repositories were considered to be OK under the policy, which is a possible interpretation of the policy as given on Packaging:Guidelines, but doesn't really seem to be a possible interpretation of the policy as given on Packaging:Treatment_Of_Bundled_Libraries (as it explicitly states whether or not they are packaged separately for Fedora). This could have considerable implementations for webapps if it were interpreted strictly, I think. Sorry for the old thread. But it is very interesting question to clearly determine bundled library to which returning happened again and again. Does it hang again now or something indeed changed? Yeah, I'm still interested in other people's thoughts on this, I rather expected it to get more traction when first posted. I guess I'll try one more bump (this one) and if still no-one bites, we can file an FPC ticket, perhaps. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
