[Bug 1214735] perl-PAR-1.009 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1214735 --- Comment #4 from Fedora Update System upda...@fedoraproject.org --- perl-PAR-1.009-1.fc22 has been submitted as an update for Fedora 22. https://admin.fedoraproject.org/updates/perl-PAR-1.009-1.fc22 -- You are receiving this mail because: You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
libgdata-0.17.1 soname bump
Hello everybody, The recently released libgdata-0.17.1 has bumped its soname. The highlights are support for version 3 of the YouTube API, and an initial port to version 2 of the Drive API. This is only for rawhide. I will be rebuilding affected packages. Cheers, Debarshi pgpl6YVdn6arI.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
pghmcfc uploaded Sub-Name-0.14.tar.gz for perl-Sub-Name
211ca38767145b6c362da3b821a5abca Sub-Name-0.14.tar.gz http://pkgs.fedoraproject.org/lookaside/pkgs/perl-Sub-Name/Sub-Name-0.14.tar.gz/211ca38767145b6c362da3b821a5abca/Sub-Name-0.14.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 1201978] dracut assumes BIOS time is UTC closed without fixing again
Why does this bug exist only in Fedora, not in openSUSE or Mageia or *buntu? All my systems are multiboot, so only a select very few are on UTC. None that are on UTC have Fedora installed. This means every Fedora boot takes about twice as long or longer than anything else takes, waiting on all the unnecessary FS checks. -- The wise are known for their understanding, and pleasant words are persuasive. Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
pghmcfc pushed to perl-Sub-Name (master). Update to 0.14 (..more)
From bf76d7e9e113912b4e2dbe779374bf428d201dc8 Mon Sep 17 00:00:00 2001
From: Paul Howarth p...@city-fan.org
Date: Fri, 24 Apr 2015 11:52:57 +0100
Subject: Update to 0.14
- New upstream release 0.14
- Remove mandatory dependencies for optional test
- Mark the test with B::C as TODO, as it seems to fail frequently and should
not block normal installations
diff --git a/perl-Sub-Name.spec b/perl-Sub-Name.spec
index 223419f..ca3856f 100644
--- a/perl-Sub-Name.spec
+++ b/perl-Sub-Name.spec
@@ -1,7 +1,7 @@
# TODO: BR: perl(B::C) when available
Name: perl-Sub-Name
-Version: 0.13
+Version: 0.14
Release: 1%{?dist}
Summary: Name - or rename - a sub
License: GPL+ or Artistic
@@ -17,11 +17,11 @@ BuildRequires: perl(warnings)
BuildRequires: perl(XSLoader)
# Test Suite
BuildRequires: perl(B::Deparse)
-BuildRequires: perl(Devel::CheckBin)
BuildRequires: perl(File::Spec)
BuildRequires: perl(Test::More) = 0.88
# Optional Tests
BuildRequires: perl(CPAN::Meta) = 2.120900
+BuildRequires: perl(Devel::CheckBin)
# Runtime
Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
@@ -63,6 +63,12 @@ make test
%{_mandir}/man3/Sub::Name.3*
%changelog
+* Fri Apr 24 2015 Paul Howarth p...@city-fan.org - 0.14-1
+- Update to 0.14
+ - Remove mandatory dependencies for optional test
+ - Mark the test with B::C as TODO, as it seems to fail frequently and should
+not block normal installations
+
* Sun Mar 29 2015 Paul Howarth p...@city-fan.org - 0.13-1
- Update to 0.13
- Fix optional test of interaction with B::C that sometimes invalidly failed
diff --git a/sources b/sources
index 9dccc62..9463e90 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-7e4881f8b2f00a4ff31f6b54061bd5cc Sub-Name-0.13.tar.gz
+211ca38767145b6c362da3b821a5abca Sub-Name-0.14.tar.gz
--
cgit v0.10.2
http://pkgs.fedoraproject.org/cgit/perl-Sub-Name.git/commit/?h=masterid=bf76d7e9e113912b4e2dbe779374bf428d201dc8
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
pghmcfc pushed to perl-Module-Build-XSUtil (perl-Module-Build-XSUtil-0.15-1.fc23). Update to 0.15 (..more)
From 781470abecf1687da732c5e9a0c2e20f4a0e6f17 Mon Sep 17 00:00:00 2001
From: Paul Howarth p...@city-fan.org
Date: Fri, 24 Apr 2015 11:40:57 +0100
Subject: Update to 0.15
- New upstream release 0.15
- Update XSHelper to fix STATIC_INLINE for gcc -std=c89
diff --git a/perl-Module-Build-XSUtil.spec b/perl-Module-Build-XSUtil.spec
index 19d351f..5da223a 100644
--- a/perl-Module-Build-XSUtil.spec
+++ b/perl-Module-Build-XSUtil.spec
@@ -1,7 +1,7 @@
Summary: A Module::Build class for building XS modules
Name: perl-Module-Build-XSUtil
-Version: 0.14
-Release: 2%{?dist}
+Version: 0.15
+Release: 1%{?dist}
License: GPL+ or Artistic
URL: https://github.com/hideo55/Module-Build-XSUtil
Source0:
https://cpan.metacpan.org/authors/id/H/HI/HIDEAKIO/Module-Build-XSUtil-%{version}.tar.gz
@@ -61,6 +61,10 @@ perl Build.PL --installdirs=vendor
%{_mandir}/man3/Module::Build::XSUtil.3*
%changelog
+* Fri Apr 24 2015 Paul Howarth p...@city-fan.org - 0.15-1
+- Update to 0.15
+ - Update XSHelper to fix STATIC_INLINE for gcc -std=c89
+
* Tue Oct 7 2014 Paul Howarth p...@city-fan.org - 0.14-2
- Sanitize for Fedora submission
diff --git a/sources b/sources
index 4c3b09a..a786e52 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-40045cdd0730d09abc05423f7c103adb Module-Build-XSUtil-0.14.tar.gz
+23f695909296f5d34fb09535a1238a61 Module-Build-XSUtil-0.15.tar.gz
--
cgit v0.10.2
http://pkgs.fedoraproject.org/cgit/perl-Module-Build-XSUtil.git/commit/?h=perl-Module-Build-XSUtil-0.15-1.fc23id=781470abecf1687da732c5e9a0c2e20f4a0e6f17
--
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-Net-DNS-SEC
perl-Net-DNS-SEC has broken dependencies in the rawhide tree: On x86_64: perl-Net-DNS-SEC-0.22-1.fc23.noarch requires perl(Digest::GOST::CryptoPro) perl-Net-DNS-SEC-0.22-1.fc23.noarch requires perl(Digest::GOST) = 0:0.06 perl-Net-DNS-SEC-0.22-1.fc23.noarch requires perl(Crypt::OpenSSL::ECDSA) = 0:0.06 perl-Net-DNS-SEC-0.22-1.fc23.noarch requires perl(Crypt::OpenSSL::ECDSA) = 0:0.05 perl-Net-DNS-SEC-0.22-1.fc23.noarch requires perl(Crypt::OpenSSL::EC) = 0:1.01 perl-Net-DNS-SEC-0.22-1.fc23.noarch requires perl(Crypt::OpenSSL::EC) = 0:0.5 On i386: perl-Net-DNS-SEC-0.22-1.fc23.noarch requires perl(Digest::GOST::CryptoPro) perl-Net-DNS-SEC-0.22-1.fc23.noarch requires perl(Digest::GOST) = 0:0.06 perl-Net-DNS-SEC-0.22-1.fc23.noarch requires perl(Crypt::OpenSSL::ECDSA) = 0:0.06 perl-Net-DNS-SEC-0.22-1.fc23.noarch requires perl(Crypt::OpenSSL::ECDSA) = 0:0.05 perl-Net-DNS-SEC-0.22-1.fc23.noarch requires perl(Crypt::OpenSSL::EC) = 0:1.01 perl-Net-DNS-SEC-0.22-1.fc23.noarch requires perl(Crypt::OpenSSL::EC) = 0:0.5 On armhfp: perl-Net-DNS-SEC-0.22-1.fc23.noarch requires perl(Digest::GOST::CryptoPro) perl-Net-DNS-SEC-0.22-1.fc23.noarch requires perl(Digest::GOST) = 0:0.06 perl-Net-DNS-SEC-0.22-1.fc23.noarch requires perl(Crypt::OpenSSL::ECDSA) = 0:0.06 perl-Net-DNS-SEC-0.22-1.fc23.noarch requires perl(Crypt::OpenSSL::ECDSA) = 0:0.05 perl-Net-DNS-SEC-0.22-1.fc23.noarch requires perl(Crypt::OpenSSL::EC) = 0:1.01 perl-Net-DNS-SEC-0.22-1.fc23.noarch requires perl(Crypt::OpenSSL::EC) = 0:0.5 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: dnf caches
On 24/04/15 10:40, Radek Holy wrote: - Original Message - From: Pádraig Brady p...@draigbrady.com To: Development discussions related to Fedora devel@lists.fedoraproject.org Sent: Thursday, April 23, 2015 8:11:45 PM Subject: Re: dnf caches On 23/04/15 18:44, drago01 wrote: On Thu, Apr 23, 2015 at 7:07 PM, Pádraig Brady p...@draigbrady.com wrote: My Fedora 22 system prompted me that there was a new coreutils package for update. Rather than clicking restart and install in the GUI I tried to: # dnf install coreutils Using metadata from Tue Apr 21 19:54:02 2015 (1 day, 21:50:24 hours old) Package coreutils-8.23-8.fc22.x86_64 is already installed, skipping. Ok fair enough, the updating system is using a separate cache to dnf. Not ideal, but anyway how do I update the dnf cache? I tried: # dnf check-update coreutils Using metadata from Thu Apr 23 17:42:54 2015 (0:01:19 hours old) coreutils.x86_64 Given the above found the new coreutils, I thought an install would now work, though unfortunately it doesn't. Shouldn't dnf be looking at the timestamps of the repo in each invocation (without -C) and updating the metadata if needed? I presume that's what yum does since I never had an issue with this. I tried explicitly cleaning the cache like this: # dnf --disablerepo=* --enablerepo=updates clean metadata Cleaning repos: updates 5 metadata files removed 2 dbcache files removed How do I refresh the cache? dnf --refresh whatever ... where whatever can be install foo or update etc. Great thanks. BTW --refresh is mentioned but not described in dnf --help. It would be could to add a description. Could you please file a bug? https://github.com/pixelb/dnf/pull/1 cheers, Pádraig -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
pghmcfc pushed to perl-Sub-Name (perl-Sub-Name-0.14-1.fc23). Update to 0.14 (..more)
From bf76d7e9e113912b4e2dbe779374bf428d201dc8 Mon Sep 17 00:00:00 2001
From: Paul Howarth p...@city-fan.org
Date: Fri, 24 Apr 2015 11:52:57 +0100
Subject: Update to 0.14
- New upstream release 0.14
- Remove mandatory dependencies for optional test
- Mark the test with B::C as TODO, as it seems to fail frequently and should
not block normal installations
diff --git a/perl-Sub-Name.spec b/perl-Sub-Name.spec
index 223419f..ca3856f 100644
--- a/perl-Sub-Name.spec
+++ b/perl-Sub-Name.spec
@@ -1,7 +1,7 @@
# TODO: BR: perl(B::C) when available
Name: perl-Sub-Name
-Version: 0.13
+Version: 0.14
Release: 1%{?dist}
Summary: Name - or rename - a sub
License: GPL+ or Artistic
@@ -17,11 +17,11 @@ BuildRequires: perl(warnings)
BuildRequires: perl(XSLoader)
# Test Suite
BuildRequires: perl(B::Deparse)
-BuildRequires: perl(Devel::CheckBin)
BuildRequires: perl(File::Spec)
BuildRequires: perl(Test::More) = 0.88
# Optional Tests
BuildRequires: perl(CPAN::Meta) = 2.120900
+BuildRequires: perl(Devel::CheckBin)
# Runtime
Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
@@ -63,6 +63,12 @@ make test
%{_mandir}/man3/Sub::Name.3*
%changelog
+* Fri Apr 24 2015 Paul Howarth p...@city-fan.org - 0.14-1
+- Update to 0.14
+ - Remove mandatory dependencies for optional test
+ - Mark the test with B::C as TODO, as it seems to fail frequently and should
+not block normal installations
+
* Sun Mar 29 2015 Paul Howarth p...@city-fan.org - 0.13-1
- Update to 0.13
- Fix optional test of interaction with B::C that sometimes invalidly failed
diff --git a/sources b/sources
index 9dccc62..9463e90 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-7e4881f8b2f00a4ff31f6b54061bd5cc Sub-Name-0.13.tar.gz
+211ca38767145b6c362da3b821a5abca Sub-Name-0.14.tar.gz
--
cgit v0.10.2
http://pkgs.fedoraproject.org/cgit/perl-Sub-Name.git/commit/?h=perl-Sub-Name-0.14-1.fc23id=bf76d7e9e113912b4e2dbe779374bf428d201dc8
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: dnf caches
- Original Message - From: Pádraig Brady p...@draigbrady.com To: Development discussions related to Fedora devel@lists.fedoraproject.org Sent: Thursday, April 23, 2015 8:11:45 PM Subject: Re: dnf caches On 23/04/15 18:44, drago01 wrote: On Thu, Apr 23, 2015 at 7:07 PM, Pádraig Brady p...@draigbrady.com wrote: My Fedora 22 system prompted me that there was a new coreutils package for update. Rather than clicking restart and install in the GUI I tried to: # dnf install coreutils Using metadata from Tue Apr 21 19:54:02 2015 (1 day, 21:50:24 hours old) Package coreutils-8.23-8.fc22.x86_64 is already installed, skipping. Ok fair enough, the updating system is using a separate cache to dnf. Not ideal, but anyway how do I update the dnf cache? I tried: # dnf check-update coreutils Using metadata from Thu Apr 23 17:42:54 2015 (0:01:19 hours old) coreutils.x86_64 Given the above found the new coreutils, I thought an install would now work, though unfortunately it doesn't. Shouldn't dnf be looking at the timestamps of the repo in each invocation (without -C) and updating the metadata if needed? I presume that's what yum does since I never had an issue with this. I tried explicitly cleaning the cache like this: # dnf --disablerepo=* --enablerepo=updates clean metadata Cleaning repos: updates 5 metadata files removed 2 dbcache files removed How do I refresh the cache? dnf --refresh whatever ... where whatever can be install foo or update etc. Great thanks. BTW --refresh is mentioned but not described in dnf --help. It would be could to add a description. Could you please file a bug? I also see that `dnf install` no longer updates a package, I now need to: dnf --refresh upgrade coreutils Yes, we know about it. The current behaviour makes sense but doing the upgrade is more consistent with the documentation. We will fix it. thanks! Pádraig. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- Radek Holý Associate Software Engineer Software Management Team Red Hat Czech -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
pghmcfc uploaded Module-Build-XSUtil-0.15.tar.gz for perl-Module-Build-XSUtil
23f695909296f5d34fb09535a1238a61 Module-Build-XSUtil-0.15.tar.gz http://pkgs.fedoraproject.org/lookaside/pkgs/perl-Module-Build-XSUtil/Module-Build-XSUtil-0.15.tar.gz/23f695909296f5d34fb09535a1238a61/Module-Build-XSUtil-0.15.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
pghmcfc pushed to perl-Module-Build-XSUtil (master). Update to 0.15 (..more)
From 781470abecf1687da732c5e9a0c2e20f4a0e6f17 Mon Sep 17 00:00:00 2001
From: Paul Howarth p...@city-fan.org
Date: Fri, 24 Apr 2015 11:40:57 +0100
Subject: Update to 0.15
- New upstream release 0.15
- Update XSHelper to fix STATIC_INLINE for gcc -std=c89
diff --git a/perl-Module-Build-XSUtil.spec b/perl-Module-Build-XSUtil.spec
index 19d351f..5da223a 100644
--- a/perl-Module-Build-XSUtil.spec
+++ b/perl-Module-Build-XSUtil.spec
@@ -1,7 +1,7 @@
Summary: A Module::Build class for building XS modules
Name: perl-Module-Build-XSUtil
-Version: 0.14
-Release: 2%{?dist}
+Version: 0.15
+Release: 1%{?dist}
License: GPL+ or Artistic
URL: https://github.com/hideo55/Module-Build-XSUtil
Source0:
https://cpan.metacpan.org/authors/id/H/HI/HIDEAKIO/Module-Build-XSUtil-%{version}.tar.gz
@@ -61,6 +61,10 @@ perl Build.PL --installdirs=vendor
%{_mandir}/man3/Module::Build::XSUtil.3*
%changelog
+* Fri Apr 24 2015 Paul Howarth p...@city-fan.org - 0.15-1
+- Update to 0.15
+ - Update XSHelper to fix STATIC_INLINE for gcc -std=c89
+
* Tue Oct 7 2014 Paul Howarth p...@city-fan.org - 0.14-2
- Sanitize for Fedora submission
diff --git a/sources b/sources
index 4c3b09a..a786e52 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-40045cdd0730d09abc05423f7c103adb Module-Build-XSUtil-0.14.tar.gz
+23f695909296f5d34fb09535a1238a61 Module-Build-XSUtil-0.15.tar.gz
--
cgit v0.10.2
http://pkgs.fedoraproject.org/cgit/perl-Module-Build-XSUtil.git/commit/?h=masterid=781470abecf1687da732c5e9a0c2e20f4a0e6f17
--
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
F-22 Branched report: 20150424 changes
Compose started at Fri Apr 24 07:15:02 UTC 2015 Broken deps for armhfp -- [Sprog] Sprog-0.14-27.fc20.noarch requires perl(:MODULE_COMPAT_5.18.0) [aeskulap] aeskulap-0.2.2-0.19beta1.fc22.armv7hl requires libofstd.so.3.6 aeskulap-0.2.2-0.19beta1.fc22.armv7hl requires liboflog.so.3.6 aeskulap-0.2.2-0.19beta1.fc22.armv7hl requires libijg8.so.3.6 aeskulap-0.2.2-0.19beta1.fc22.armv7hl requires libijg16.so.3.6 aeskulap-0.2.2-0.19beta1.fc22.armv7hl requires libijg12.so.3.6 aeskulap-0.2.2-0.19beta1.fc22.armv7hl requires libdcmnet.so.3.6 aeskulap-0.2.2-0.19beta1.fc22.armv7hl requires libdcmjpeg.so.3.6 aeskulap-0.2.2-0.19beta1.fc22.armv7hl requires libdcmimgle.so.3.6 aeskulap-0.2.2-0.19beta1.fc22.armv7hl requires libdcmimage.so.3.6 aeskulap-0.2.2-0.19beta1.fc22.armv7hl requires libdcmdata.so.3.6 [avro] avro-mapred-1.7.5-9.fc22.noarch requires hadoop-mapreduce avro-mapred-1.7.5-9.fc22.noarch requires hadoop-client [bro] broccoli-2.3-1.fc22.armv7hl requires bro-2.3 python-broccoli-2.3-1.fc22.armv7hl requires bro-2.3 [collectd] collectd-gmond-5.4.2-1.fc22.armv7hl requires libganglia-3.6.0.so.0 [crystal] crystal-2.2.1-2.fc22.armv7hl requires libkdecorations.so.4 [dnssec-check] dnssec-check-1.14.0.1-4.fc20.armv7hl requires libval-threads.so.14 dnssec-check-1.14.0.1-4.fc20.armv7hl requires libsres.so.14 [gcc-python-plugin] gcc-python2-debug-plugin-0.13-2.fc22.armv7hl requires gcc = 0:4.9.2-1.fc22 gcc-python2-plugin-0.13-2.fc22.armv7hl requires gcc = 0:4.9.2-1.fc22 gcc-python3-debug-plugin-0.13-2.fc22.armv7hl requires gcc = 0:4.9.2-1.fc22 gcc-python3-plugin-0.13-2.fc22.armv7hl requires gcc = 0:4.9.2-1.fc22 [kde-style-skulpture] kde-style-skulpture-0.2.4-9.fc22.armv7hl requires libkdecorations.so.4 [kfilefactory] kfilefactory-0.1.1-8.fc21.noarch requires kdebase-workspace [leksah] ghc-leksah-devel-0.12.1.3-16.fc22.armv7hl requires ghc-devel(utf8-string-0.3.7-013ef9ad8ac70ebb11df31f487b74f26) ghc-leksah-devel-0.12.1.3-16.fc22.armv7hl requires ghc-devel(unix-2.6.0.1-7550b9ae9dbc74e4d6570cc239a29030) ghc-leksah-devel-0.12.1.3-16.fc22.armv7hl requires ghc-devel(transformers-0.3.0.0-23508e0b4a1c1bc1cf2c2de3bb13e90c) ghc-leksah-devel-0.12.1.3-16.fc22.armv7hl requires ghc-devel(time-1.4.0.1-970760bdd865d8b6cafac382276795a2) ghc-leksah-devel-0.12.1.3-16.fc22.armv7hl requires ghc-devel(text-0.11.3.1-17cae9ba49c3f3d533bf78a6e387f543) ghc-leksah-devel-0.12.1.3-16.fc22.armv7hl requires ghc-devel(strict-0.3.2-04f0cc1e99eff2196c0a7cd16d748b37) ghc-leksah-devel-0.12.1.3-16.fc22.armv7hl requires ghc-devel(regex-tdfa-1.1.8-0b03687c4e38c00ef92e9445170081e2) ghc-leksah-devel-0.12.1.3-16.fc22.armv7hl requires ghc-devel(regex-base-0.93.2-6a541a53412d1d7d310fa69bca50c85f) ghc-leksah-devel-0.12.1.3-16.fc22.armv7hl requires ghc-devel(pretty-1.1.1.0-2de27f83b2c1c65d629a564e9e01b27d) ghc-leksah-devel-0.12.1.3-16.fc22.armv7hl requires ghc-devel(parsec-3.1.3-a8bebef411959de671abb0f1f7da556f) ghc-leksah-devel-0.12.1.3-16.fc22.armv7hl requires ghc-devel(old-time-1.1.0.1-29c02e2b3bbdfd9a5756f0c46f4d6071) ghc-leksah-devel-0.12.1.3-16.fc22.armv7hl requires ghc-devel(network-2.4.1.2-82f6bcf79fe0252b3ab387e8dcb82e71) ghc-leksah-devel-0.12.1.3-16.fc22.armv7hl requires ghc-devel(mtl-2.1.2-2f2cd438035824ec2bed4811930bc232) ghc-leksah-devel-0.12.1.3-16.fc22.armv7hl requires ghc-devel(ltk-0.12.1.0-2fbb10498719be9dbdbb3d9f8adedbec) ghc-leksah-devel-0.12.1.3-16.fc22.armv7hl requires ghc-devel(leksah-server-0.12.1.2-7dbd70c9f5e4dd8b3b5efcb6597b3bfd) ghc-leksah-devel-0.12.1.3-16.fc22.armv7hl requires ghc-devel(hslogger-1.2.1-43834164508859009a3cc8aef7fd1e84) ghc-leksah-devel-0.12.1.3-16.fc22.armv7hl requires ghc-devel(gtksourceview2-0.12.5.0-588b179d0562576f9afa46559cebf79f) ghc-leksah-devel-0.12.1.3-16.fc22.armv7hl requires ghc-devel(gtk-0.12.5.0-2342a114ec8897cecfdda15ac92aed08) ghc-leksah-devel-0.12.1.3-16.fc22.armv7hl requires ghc-devel(glib-0.12.5.0-1b94df160e141377711a221615168695) ghc-leksah-devel-0.12.1.3-16.fc22.armv7hl requires ghc-devel(gio-0.12.5.0-b012293268f349d8f05c73d053798c7b) ghc-leksah-devel-0.12.1.3-16.fc22.armv7hl requires ghc-devel(ghc-7.6.3-18fc786f8ad3478b9bb568d865b0e48d) ghc-leksah-devel-0.12.1.3-16.fc22.armv7hl requires ghc-devel(filepath-1.3.0.1-62570c67b40fb99e7078c0d179220531) ghc-leksah-devel-0.12.1.3-16.fc22.armv7hl requires ghc-devel(enumerator-0.4.19-a164f71ed1088e349dd8bc4cdee8e449) ghc-leksah-devel-0.12.1.3-16.fc22.armv7hl requires ghc-devel(directory-1.2.0.1-504c99535d64699e20e001d81b577d06) ghc-leksah-devel-0.12.1.3-16.fc22.armv7hl requires
Broken dependencies: perl-Satcon
perl-Satcon has broken dependencies in the F-22 tree: On x86_64: perl-Satcon-1.20-3.fc21.noarch requires perl(:MODULE_COMPAT_5.18.2) On i386: perl-Satcon-1.20-3.fc21.noarch requires perl(:MODULE_COMPAT_5.18.2) On armhfp: perl-Satcon-1.20-3.fc21.noarch requires perl(:MODULE_COMPAT_5.18.2) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Is it too late in the F22 cycle to upgrade cross-gcc to gcc-5?
On Fri, Apr 24, 2015 at 9:59 AM, David Howells dhowe...@redhat.com wrote: It's taken quite a long time to sort out the bugs in gcc-5 with regard to lesser-used arches, so I've only just managed to get cross-gcc in rawhide upgraded to gcc-5, despite the main gcc package having got there a while ago. Is it too late in the F22 cycle now to upgrade cross-gcc there to gcc-5? I'm not entirely sure what depends on it or how to find out? I don't think anything in the distro depends on the cross compilers. There's no associated Change, etc. Unless there's something I'm missing, you should be able to update them, build, and file an update in Bodhi to get the appropriate karma. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Is it too late in the F22 cycle to upgrade cross-gcc to gcc-5?
On Fri, Apr 24, 2015 at 02:59:09PM +0100, David Howells wrote: It's taken quite a long time to sort out the bugs in gcc-5 with regard to lesser-used arches, so I've only just managed to get cross-gcc in rawhide upgraded to gcc-5, despite the main gcc package having got there a while ago. Is it too late in the F22 cycle now to upgrade cross-gcc there to gcc-5? I'm not entirely sure what depends on it or how to find out? IMNSHO it would be much better if both gcc and cross-gcc were the same version, less confusion for users... So I support updating cross-gcc to 5.1.1. Jakub -- 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 1215148] perl-Config-Any-0.25 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1215148 --- Comment #2 from Upstream Release Monitoring upstream-release-monitor...@fedoraproject.org --- Scratch build succeeded http://koji.fedoraproject.org/koji/taskinfo?taskID=9558543 -- You are receiving this mail because: You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1215148] New: perl-Config-Any-0.25 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1215148 Bug ID: 1215148 Summary: perl-Config-Any-0.25 is available Product: Fedora Version: rawhide Component: perl-Config-Any Keywords: FutureFeature, Triaged Assignee: emman...@seyman.fr Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: emman...@seyman.fr, mmasl...@redhat.com, perl-devel@lists.fedoraproject.org, psab...@redhat.com, robinlee.s...@gmail.com Latest upstream release: 0.25 Current version/release in rawhide: 0.24-4.fc22 URL: http://search.cpan.org/dist/Config-Any/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. -- You are receiving this mail because: You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1215148] perl-Config-Any-0.25 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1215148 --- Comment #1 from Upstream Release Monitoring upstream-release-monitor...@fedoraproject.org --- Created attachment 1018450 -- https://bugzilla.redhat.com/attachment.cgi?id=1018450action=edit [patch] Update to 0.25 (#1215148) -- You are receiving this mail because: You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: dnf caches
- Original Message - From: Pádraig Brady p...@draigbrady.com To: Development discussions related to Fedora devel@lists.fedoraproject.org Sent: Friday, April 24, 2015 11:58:53 AM Subject: Re: dnf caches On 24/04/15 10:40, Radek Holy wrote: - Original Message - From: Pádraig Brady p...@draigbrady.com To: Development discussions related to Fedora devel@lists.fedoraproject.org Sent: Thursday, April 23, 2015 8:11:45 PM Subject: Re: dnf caches On 23/04/15 18:44, drago01 wrote: On Thu, Apr 23, 2015 at 7:07 PM, Pádraig Brady p...@draigbrady.com wrote: My Fedora 22 system prompted me that there was a new coreutils package for update. Rather than clicking restart and install in the GUI I tried to: # dnf install coreutils Using metadata from Tue Apr 21 19:54:02 2015 (1 day, 21:50:24 hours old) Package coreutils-8.23-8.fc22.x86_64 is already installed, skipping. Ok fair enough, the updating system is using a separate cache to dnf. Not ideal, but anyway how do I update the dnf cache? I tried: # dnf check-update coreutils Using metadata from Thu Apr 23 17:42:54 2015 (0:01:19 hours old) coreutils.x86_64 Given the above found the new coreutils, I thought an install would now work, though unfortunately it doesn't. Shouldn't dnf be looking at the timestamps of the repo in each invocation (without -C) and updating the metadata if needed? I presume that's what yum does since I never had an issue with this. I tried explicitly cleaning the cache like this: # dnf --disablerepo=* --enablerepo=updates clean metadata Cleaning repos: updates 5 metadata files removed 2 dbcache files removed How do I refresh the cache? dnf --refresh whatever ... where whatever can be install foo or update etc. Great thanks. BTW --refresh is mentioned but not described in dnf --help. It would be could to add a description. Could you please file a bug? https://github.com/pixelb/dnf/pull/1 cheers, Pádraig -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Thank you. If I could have yet another wish, choose rpm-software-management/dnf as the base fork next time. Thank you. -- Radek Holý Associate Software Engineer Software Management Team Red Hat Czech -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Is it too late in the F22 cycle to upgrade cross-gcc to gcc-5?
It's taken quite a long time to sort out the bugs in gcc-5 with regard to lesser-used arches, so I've only just managed to get cross-gcc in rawhide upgraded to gcc-5, despite the main gcc package having got there a while ago. Is it too late in the F22 cycle now to upgrade cross-gcc there to gcc-5? I'm not entirely sure what depends on it or how to find out? David -- 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: Is it too late in the F22 cycle to upgrade cross-gcc to gcc-5?
Josh Boyer jwbo...@fedoraproject.org wrote: I don't think anything in the distro depends on the cross compilers. There's no associated Change, etc. Unless there's something I'm missing, you should be able to update them, build, and file an update in Bodhi to get the appropriate karma. I was under the impression there was some boot-time stuff that depended on them, but I don't remember which package and I'm not sure how to find out barring asking on this list. David -- 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 824089] CVE-2011-2082 rt3: Multiple security flaws fixed in upstream v3.8.12 and v4.0.6 versions [epel-all]
https://bugzilla.redhat.com/show_bug.cgi?id=824089 --- Comment #1 from David A. Cafaro d...@cafaro.net --- This bug is VERY old, do we have an udpate/patch for this? -- You are receiving this mail because: You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[EPEL-devel] EPEL meeting minutes
17:00:57 smooge #startmeeting EPEL 17:00:57 zodbot Meeting started Fri Apr 24 17:00:57 2015 UTC. The chair is smooge. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:00:57 zodbot Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:01:02 smooge #meetingname epel 17:01:02 zodbot The meeting name has been set to 'epel' 17:01:14 smooge #chairs avij nirik bstinson dgilmore Evolution 17:01:22 smooge #chair avij nirik bstinson dgilmore Evolution 17:01:22 zodbot Current chairs: Evolution avij bstinson dgilmore nirik smooge 17:01:40 smooge #topic Robot Roll Call 17:01:49 smooge Tom Servo here as your majordomo 17:01:57 nirik hey all 17:02:13 bstinson yay epel meeting! 17:03:13 Evolution here. 17:03:31 smooge #topic New Meeting Time 17:04:00 smooge So one of the issues with EPEL meetings is trying to find a time where they can occur when people are able to focus on them versus other scheduled tasks 17:04:26 nirik always a struggle with all meetings. 17:04:55 smooge lesson 1. whenisgood.com is not the place for me to set this up. whenisgood.net is the correct place 17:05:14 smooge does anyone currently have a whenisgood account? 17:05:38 nirik nope. There was also some more open source one someone mentioned a while back, but I can't recall the name now 17:08:48 nirik http://doodle.com/ 17:08:51 nirik I think that was it 17:11:07 smooge lesson 2. these things are pain in the ass 17:11:32 nirik yeah 17:12:04 bstinson ^^this, /me is digging to see if i have an old doodle account 17:12:25 smooge bstinson, you ok setting up the invitations? Or do you want me to? 17:13:06 bstinson if you're already in go ahead, i'm waiting on a password reset email from doodle 17:15:50 smooge I am not setting up an account but was doing the complete free thing 17:18:00 smooge could someone pm me avij's email 17:19:34 smooge .fasinfo avij 17:19:35 zodbot smooge: User: avij, Name: Anssi Johansson, email: rhb...@miuku.net, Creation: 2012-06-16, IRC Nick: avij, Timezone: Europe/Helsinki, Locale: en, GPG key ID: , Status: active 17:19:38 zodbot smooge: Approved Groups: cla_fpca cla_done 17:20:39 smooge ok so the poll in doodle is absolutely useless from the free account settings 17:20:46 smooge I can only ask you what day to use 17:20:56 nirik ah, bah 17:20:58 Evolution that's... suboptimal 17:21:18 smooge bstinson, might have more options when his account gets reopened 17:21:36 smooge ok I will work on something but let us move to the next time 17:21:41 smooge s/time/item/ 17:21:46 bstinson you can action that to me 17:21:51 bstinson still waiting on the reset email 17:22:13 smooge #action bstinson will create meeting invite for upcoming meetings in doodle or whenisgood depending on what is possible 17:22:54 smooge bstinson, please use UTC so people don't have to deal with did this send in my time zone or bstinson's timezone type worries 17:23:12 smooge #topic New Chair System 17:23:36 * nirik proposed rotating chair on the list. 17:23:41 nirik what do folks think? 17:23:58 smooge I personally think that this is a good idea 17:24:14 bstinson i think that would spread out the load a little bit 17:24:16 Evolution worksforme 17:24:16 bstinson +1 from me 17:25:01 smooge 3 votes for rotating chair, 2 abstains 17:25:29 smooge #agreed EPSCO will use rotating chair system to host future meetings. 3 +1 votes 2 abstains 17:25:48 smooge #topic Status of python3 17:26:03 smooge nirik, I think you had some status on this 17:26:05 nirik I need to work on epel-rpm-macros. 17:26:08 nirik it's still on my list. 17:26:15 nirik just havent had time 17:26:36 smooge okie dokie 17:26:47 nirik so, thats all really... will try and get er done 17:26:52 smooge #topic Open Floor 17:26:59 smooge Any other issues? 17:27:27 Evolution are there anough packages to warrant another killing spree 17:27:32 Evolution *orphaned* 17:28:30 Evolution also, is there any reason for epel-specific involvement in the upcoming FAD? 17:28:45 Evolution /end random thought from my side 17:29:00 nirik I think tyll_ has been culling orphans with the 6weeks orphaned thing still. 17:29:07 nirik and we are getting down to a small list. 17:29:35 Evolution oh, I didn't realize he was actively dealing with it. that's good news. -- Stephen J Smoogen. ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
[Bug 1215296] perl-Tangerine-0.15 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1215296 --- Comment #1 from Upstream Release Monitoring upstream-release-monitor...@fedoraproject.org --- Created attachment 1018653 -- https://bugzilla.redhat.com/attachment.cgi?id=1018653action=edit [patch] Update to 0.15 (#1215296) -- You are receiving this mail because: You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1215296] New: perl-Tangerine-0.15 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1215296 Bug ID: 1215296 Summary: perl-Tangerine-0.15 is available Product: Fedora Version: rawhide Component: perl-Tangerine Keywords: FutureFeature, Triaged Assignee: psab...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: jples...@redhat.com, perl-devel@lists.fedoraproject.org, psab...@redhat.com Latest upstream release: 0.15 Current version/release in rawhide: 0.14-1.fc23 URL: http://search.cpan.org/dist/Tangerine/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. -- You are receiving this mail because: You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1215297] New: perl-Text-CSV_XS-1.17 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1215297 Bug ID: 1215297 Summary: perl-Text-CSV_XS-1.17 is available Product: Fedora Version: rawhide Component: perl-Text-CSV_XS Keywords: FutureFeature, Triaged Assignee: psab...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: mmasl...@redhat.com, perl-devel@lists.fedoraproject.org, psab...@redhat.com Latest upstream release: 1.17 Current version/release in rawhide: 1.16-1.fc23 URL: http://search.cpan.org/dist/Text-CSV_XS/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. -- You are receiving this mail because: You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1214766] perl-XML-LibXML-2.0119 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1214766 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #5 from Fedora Update System upda...@fedoraproject.org --- Package perl-XML-LibXML-2.0119-1.fc22: * should fix your issue, * was pushed to the Fedora 22 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing perl-XML-LibXML-2.0119-1.fc22' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2015-6823/perl-XML-LibXML-2.0119-1.fc22 then log in and leave karma (feedback). -- You are receiving this mail because: You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1215291] perl-DateTime-TimeZone-1.88 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1215291 --- Comment #1 from Upstream Release Monitoring upstream-release-monitor...@fedoraproject.org --- Created attachment 1018643 -- https://bugzilla.redhat.com/attachment.cgi?id=1018643action=edit [patch] Update to 1.88 (#1215291) -- You are receiving this mail because: You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1215291] New: perl-DateTime-TimeZone-1.88 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1215291 Bug ID: 1215291 Summary: perl-DateTime-TimeZone-1.88 is available Product: Fedora Version: rawhide Component: perl-DateTime-TimeZone Keywords: FutureFeature, Triaged Assignee: psab...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: iarn...@gmail.com, perl-devel@lists.fedoraproject.org, psab...@redhat.com Latest upstream release: 1.88 Current version/release in rawhide: 1.87-1.fc23 URL: http://search.cpan.org/dist/DateTime-TimeZone/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. -- You are receiving this mail because: You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: [Bug 1201978] dracut assumes BIOS time is UTC closed without fixing again
Felix Miata mrmazda at earthlink.net writes: Just as a workaround, you CAN make a Windows box use UTC for the RTC... Multiboot is not a universe limited to Windows and Linux, and certainly not only the latest version of either. And, there's a whole LAN to consider, not one PC in isolation. AFAIK, Windows is the only OS that has trouble using UTC for the RTC. When I acquire a new PC or motherboard, I set its clock to match the rest of the clocks in the building, neighborhood and city, so the sun is overhead somewhere around noon. That's how time is supposed to be. It's up to a PC to adjust to me and my environment, not vice versa, and when I boot a floppy I don't need to look at a watch, TV or wall clock to see what time it really is. If you're using a laptop and travel between time zones, there is no permanent local time. And even if you stay in one place, if your local time is subject to Daylight Saving, the fact that it can go backwards when changing from DT to ST causes problems for the OS. See https://www.cl.cam.ac.uk/~mgk25/mswish/ut-rtc.html . To avoid that, the time used by the RTC should increase monotonically. Also, when people share files, if their RTCs are in different time zones, it's impossible to know exactly how to interpret a file's timestamps, since they depend on the originating PC's time zone. The only way to avoid these problems is for everyone to have their RTC set on the same monotonically increasing time, and UTC is the natural choice. -- 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 1214699] perl-App-cpanminus-1.7031 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1214699 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #5 from Fedora Update System upda...@fedoraproject.org --- Package perl-App-cpanminus-1.7031-1.fc22: * should fix your issue, * was pushed to the Fedora 22 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing perl-App-cpanminus-1.7031-1.fc22' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2015-6789/perl-App-cpanminus-1.7031-1.fc22 then log in and leave karma (feedback). -- You are receiving this mail because: You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1215291] perl-DateTime-TimeZone-1.88 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1215291 --- Comment #2 from Upstream Release Monitoring upstream-release-monitor...@fedoraproject.org --- Scratch build succeeded http://koji.fedoraproject.org/koji/taskinfo?taskID=9563092 -- You are receiving this mail because: You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1215296] perl-Tangerine-0.15 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1215296 --- Comment #2 from Upstream Release Monitoring upstream-release-monitor...@fedoraproject.org --- Scratch build failed http://koji.fedoraproject.org/koji/taskinfo?taskID=9563387 -- You are receiving this mail because: You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1215297] perl-Text-CSV_XS-1.17 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1215297 --- Comment #1 from Upstream Release Monitoring upstream-release-monitor...@fedoraproject.org --- Created attachment 1018654 -- https://bugzilla.redhat.com/attachment.cgi?id=1018654action=edit [patch] Update to 1.17 (#1215297) -- You are receiving this mail because: You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1214713] perl-File-ShareDir-ProjectDistDir-1.000007 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1214713 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #5 from Fedora Update System upda...@fedoraproject.org --- Package perl-File-ShareDir-ProjectDistDir-1.07-1.fc22: * should fix your issue, * was pushed to the Fedora 22 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing perl-File-ShareDir-ProjectDistDir-1.07-1.fc22' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2015-6753/perl-File-ShareDir-ProjectDistDir-1.07-1.fc22 then log in and leave karma (feedback). -- You are receiving this mail because: You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: [Bug 1201978] dracut assumes BIOS time is UTC closed without fixing again
Andre Robatino composed on 2015-04-25 00:25 (UTC): Felix Miata composed: Just as a workaround, you CAN make a Windows box use UTC for the RTC... Multiboot is not a universe limited to Windows and Linux, and certainly not only the latest version of either. And, there's a whole LAN to consider, not one PC in isolation. AFAIK, Windows is the only OS that has trouble using UTC for the RTC. Have you ever used DOS or OS/2? I don't remember ever seeing options at installation time to choose anything other than local in either one. Same for W95, W98, WXP W7. How they were set up initially is how they will remain. When I acquire a new PC or motherboard, I set its clock to match the rest of the clocks in the building, neighborhood and city, so the sun is overhead somewhere around noon. That's how time is supposed to be. It's up to a PC to adjust to me and my environment, not vice versa, and when I boot a floppy I don't need to look at a watch, TV or wall clock to see what time it really is. If you're using a laptop and travel between time zones, No laptop, no cell phone, no traveling among time zones. there is no permanent local time. And even if you stay in one place, if your local time is subject to Daylight Saving, the fact that it can go backwards when changing from DT to ST causes problems for the OS. See Bigger problems trying to retrofit, assuming the possibility even exists for any in particular, loads of diverse installations to UTC, or track which have been converted or didn't need to be or can't be, and which not, than to have them reboot after or shut down while the clocks change. https://www.cl.cam.ac.uk/~mgk25/mswish/ut-rtc.html . To avoid that, the time used by the RTC should increase monotonically. Also, when people share files, if their RTCs are in different time zones, it's impossible to know exactly how to interpret a file's timestamps, since they depend on the originating PC's time zone. The only way to avoid these problems is for everyone to have their RTC set on the same monotonically increasing time, and UTC is the natural choice. That UTC is the ideal choice for most use cases does not justify making it the only choice for all installations. This is still FOSS, home of choice and multiple ways to get things done. All your base are not belong to us yet. -- The wise are known for their understanding, and pleasant words are persuasive. Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [EPEL-devel] Call for Agenda EPEL meeting 2014-04-24
On Thu, 23 Apr 2015 09:25:32 -0600 Stephen John Smoogen smo...@gmail.com wrote: 1. New Meeting Time? I'm pretty flexable. Perhaps someone could do a whenisgood? 2. New EPEL chair? As I am sure smooge will attest, this is kind of a high burnout thing doing all the meetings and such. So, I'd like to propose we do what we did with FESCo a while back: rotate the chair every week. Each week a different person is responsible for gathering the agenda, running the meeting, making sure tickets are closed, etc. Thoughts? 3. Items to be worked on? There's still work pending on the python3 stuff. I will try and do my part later today or this weekend (make a epel-rpm-macros package). Aside that not sure whats cooking. Perhaps have meeting keywords on tickets people want to discuss. kevin pgpZgA1l0VFng.pgp Description: OpenPGP digital signature ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: Is it too late in the F22 cycle to upgrade cross-gcc to gcc-5?
Cole Robinson crobi...@redhat.com wrote: FWIW qemu firmware pacakges build with cross-gcc: ipxe, seabios, SLOF, openbios. We want to build for the target architecture but ship as noarch, since the roms aren't used by the host machine but only used by qemu-system-*, which should run on any host arch. Which of the cross compilers do these use? David -- 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: Is it too late in the F22 cycle to upgrade cross-gcc to gcc-5?
(why does this list screw up reply-all!? ) On 04/24/2015 10:35 AM, David Howells wrote: Cole Robinson crobi...@redhat.com wrote: FWIW qemu firmware pacakges build with cross-gcc: ipxe, seabios, SLOF, openbios. We want to build for the target architecture but ship as noarch, since the roms aren't used by the host machine but only used by qemu-system-*, which should run on any host arch. Which of the cross compilers do these use? ipxe, seabios, sgabios: binutils-x86_64-linux-gnu gcc-x86_64-linux-gnu openbios: gcc-powerpc64-linux-gnu gcc-sparc64-linux-gnu SLOF: gcc-powerpc64-linux-gnu - Cole -- 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: Is it too late in the F22 cycle to upgrade cross-gcc to gcc-5?
Cole Robinson crobi...@redhat.com wrote: ipxe, seabios, sgabios: binutils-x86_64-linux-gnu gcc-x86_64-linux-gnu openbios: gcc-powerpc64-linux-gnu gcc-sparc64-linux-gnu SLOF: gcc-powerpc64-linux-gnu They all build on x86_64 F21 with the new cross gcc. David -- 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 1215297] perl-Text-CSV_XS-1.17 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1215297 --- Comment #2 from Upstream Release Monitoring upstream-release-monitor...@fedoraproject.org --- Scratch build succeeded http://koji.fedoraproject.org/koji/taskinfo?taskID=9563397 -- You are receiving this mail because: You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: [Bug 1201978] dracut assumes BIOS time is UTC closed without fixing again
Andre Robatino robatino at fedoraproject.org writes: it looks like OS/2 is capable of keeping its RTC in TAI (which AIUI is basically the same as UTC except that TAI doesn't have leap seconds, so TAI is real time, and UTC is TAI interspersed with leap seconds, so both increase monotonically, but UTC has jumps). Actually, I have that backwards, after a little reading it appears that UTC basically pauses during each leap second (but doesn't go backwards). TAI is currently 35 seconds ahead of UTC and that increases by one each time there's a leap second. -- 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: [Bug 1201978] dracut assumes BIOS time is UTC closed without fixing again
Andre Robatino composed on 2015-04-25 01:55 (UTC): The only reason Linux or any other OS needs to support having the RTC on local time for now is as a workaround to coexist with broken Windows. Not investing resources in disturbing sleeping dogs is a reason that is always important to some people. -- The wise are known for their understanding, and pleasant words are persuasive. Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Bug 1201978] dracut assumes BIOS time is UTC closed without fixing again
Felix Miata mrmazda at earthlink.net writes: AFAIK, Windows is the only OS that has trouble using UTC for the RTC. Have you ever used DOS or OS/2? I don't remember ever seeing options at installation time to choose anything other than local in either one. Same for W95, W98, WXP W7. How they were set up initially is how they will remain. The last four are Windows and DOS is the predecessor to Windows. I'm not familiar with OS/2, but from http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/keeping-time-in-os2.html it looks like OS/2 is capable of keeping its RTC in TAI (which AIUI is basically the same as UTC except that TAI doesn't have leap seconds, so TAI is real time, and UTC is TAI interspersed with leap seconds, so both increase monotonically, but UTC has jumps). https://www.cl.cam.ac.uk/~mgk25/mswish/ut-rtc.html . To avoid that, the time used by the RTC should increase monotonically. Also, when people share files, if their RTCs are in different time zones, it's impossible to know exactly how to interpret a file's timestamps, since they depend on the originating PC's time zone. The only way to avoid these problems is for everyone to have their RTC set on the same monotonically increasing time, and UTC is the natural choice. That UTC is the ideal choice for most use cases does not justify making it the only choice for all installations. This is still FOSS, home of choice and multiple ways to get things done. All your base are not belong to us yet. UTC (or maybe TAI which some have argued is better) should be ideal for all use cases, if Microsoft ever gets around to fixing Windows. All OSes I know of, even Windows, know how to display local time to the user, who wouldn't have to know or care what the RTC is set to, if Windows wasn't broken. You'd tell it what your local time zone is, it gets either UTC or TAI via NTP, sets the RTC to that, converts from that to your local time, and displays that to you. And as long as you multiboot only between non-Microsoft OSes, it works fine and in that case there is no advantage to having the RTC on local time. The only reason Linux or any other OS needs to support having the RTC on local time for now is as a workaround to coexist with broken Windows. -- 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 824089] CVE-2011-2082 rt3: Multiple security flaws fixed in upstream v3.8.12 and v4.0.6 versions [epel-all]
https://bugzilla.redhat.com/show_bug.cgi?id=824089 --- Comment #3 from David A. Cafaro d...@cafaro.net --- Thanks for the update and info. I'll take this back to the Security Team and see how we want to handle this. We have been working on policy to have packages that are abandoned removed so that's less of an issue than the dependency worries (which will take some thought). -- You are receiving this mail because: You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 824089] CVE-2011-2082 rt3: Multiple security flaws fixed in upstream v3.8.12 and v4.0.6 versions [epel-all]
https://bugzilla.redhat.com/show_bug.cgi?id=824089 Ralf Corsepius rc040...@freenet.de changed: What|Removed |Added CC||rc040...@freenet.de --- Comment #2 from Ralf Corsepius rc040...@freenet.de --- [Fedora maintainer speaking - I do not maintain rt in EPEL] (In reply to David A. Cafaro from comment #1) This bug is VERY old, do we have an udpate/patch for this? None that I am aware of. rt3 was abandoned upstream. In Fedora = 21, rt3 has been replaced with rt4 (rt-4.2.x) and is effectively abandoned/dead in Fedora 20. It's only still present in F20, because I missed to EOL it in time before F20 was released and because packages can't be removed from Fedora after release. I do not think trying to backport the changes from rt4 or trying to develop actual bug-fixes is feasible (checking other distros could be worth a try, though). Instead I'd recommend to remove rt3 from all EPELs and - should there be sufficient interest - somebody to try adding rt4 (4.0.x or 4.2.x) to EPEL. However, due to the long chain of deps on (modern) perl-modules and CentOS/RHEL's packaging policies, I would expect this to be a challenging, almost impossible task. -- You are receiving this mail because: You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Tangerine 0.15
I've just pushed new Tangerine, v0.15, to CPAN. Updates should land in Fedora and EPEL in the coming weeks. There are quite a few things about this release I'd like to point out: - The utility lives in its own distribution now and will have to be installed separately. I'll submit it for package review soon. - The module now requires fewer dependencies as I abandoned Mo in favour of perl's native object system. - I adopted the common terminology and renamed the main methods, hook types and modes. `provides' is now called `package', `use' is `compile' and `require' is `runtime'. The old names are still available for backwards compatibility. - The utility output is slightly different now, reflecting on the abovementioned change. - Parallel scanning is supported and it's on by default, automagically spawning just the right number of workers. This can be adjusted with the -j option. - You can now generate metadata diffs, comparing directories or tarballs. Thanks to Paul for this suggestion -- it's really quite handy when doing package updates. - Fixed some nasty bugs in module name and version filters. - It's all much cleaner and faster now :) Cheers, Petr pgpJueBntBKDI.pgp Description: PGP signature -- 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: Is it too late in the F22 cycle to upgrade cross-gcc to gcc-5?
On 04/24/2015 10:18 AM, Josh Boyer wrote: On Fri, Apr 24, 2015 at 9:59 AM, David Howells dhowe...@redhat.com wrote: It's taken quite a long time to sort out the bugs in gcc-5 with regard to lesser-used arches, so I've only just managed to get cross-gcc in rawhide upgraded to gcc-5, despite the main gcc package having got there a while ago. Is it too late in the F22 cycle now to upgrade cross-gcc there to gcc-5? I'm not entirely sure what depends on it or how to find out? I don't think anything in the distro depends on the cross compilers. FWIW qemu firmware pacakges build with cross-gcc: ipxe, seabios, SLOF, openbios. We want to build for the target architecture but ship as noarch, since the roms aren't used by the host machine but only used by qemu-system-*, which should run on any host arch. That doesn't impact whether cross-gcc should be updated, just pointing it out for completeness. - Cole -- 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: [Bug 1201978] dracut assumes BIOS time is UTC closed without fixing again
Felix Miata mrmazda at earthlink.net writes: Why does this bug exist only in Fedora, not in openSUSE or Mageia or *buntu? All my systems are multiboot, so only a select very few are on UTC. None that are on UTC have Fedora installed. This means every Fedora boot takes about twice as long or longer than anything else takes, waiting on all the unnecessary FS checks. Just as a workaround, you CAN make a Windows box use UTC for the RTC, there's a registry hack. Google RealTimeIsUniversal. I've done this on all my Windows/Fedora machines. There are some minor issues in Windows (which you'll read about in doing the above search), but if you only use Windows rarely, it's nothing serious. -- 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: [Bug 1201978] dracut assumes BIOS time is UTC closed without fixing again
Andre Robatino composed on 2015-04-24 19:44 (UTC): Felix Miata wrote: Why does this bug exist only in Fedora, not in openSUSE or Mageia or *buntu? All my systems are multiboot, so only a select very few are on UTC. None that are on UTC have Fedora installed. This means every Fedora boot takes about twice as long or longer than anything else takes, waiting on all the unnecessary FS checks. Just as a workaround, you CAN make a Windows box use UTC for the RTC... Multiboot is not a universe limited to Windows and Linux, and certainly not only the latest version of either. And, there's a whole LAN to consider, not one PC in isolation. When I acquire a new PC or motherboard, I set its clock to match the rest of the clocks in the building, neighborhood and city, so the sun is overhead somewhere around noon. That's how time is supposed to be. It's up to a PC to adjust to me and my environment, not vice versa, and when I boot a floppy I don't need to look at a watch, TV or wall clock to see what time it really is. -- The wise are known for their understanding, and pleasant words are persuasive. Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
