Re: FESCO request to revert password confirmation change in F22
Kevin Kofler wrote: The user surely knows better what a good password is than the software does. If the user picks a crappy password, there's probably a good reason. There are two possible reasons why you would say that. Either you haven't even looked at the Ars Technica articles that have been discussed in this thread, or else you believe that a majority of users of all sorts of web services think it's all right if all the spies and script kiddies in the world have full access to their accounts. Björn Persson pgpTJmoZV1fI6.pgp Description: OpenPGP digital signatur -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
File parent-0.231.tar.gz uploaded to lookaside cache by pghmcfc
A file has been added to the lookaside cache for perl-parent: 6598dc010917282a5bc3864092a75256 parent-0.231.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-parent/f22] (2 commits) ...Update to 0.231
Summary of changes: cc17c57... Update to 0.229 (*) ffd05d0... Update to 0.231 (*) (*) 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-parent] Created tag perl-parent-0.231-1.fc22
The lightweight tag 'perl-parent-0.231-1.fc22' was created pointing to: ffd05d0... Update to 0.231 -- 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 1197767] perl-Math-Int64 FTBFS on s390 due to failing test
https://bugzilla.redhat.com/show_bug.cgi?id=1197767 David Dick dd...@cpan.org changed: What|Removed |Added Status|NEW |CLOSED Resolution|--- |NEXTRELEASE Last Closed||2015-03-10 05:45:34 --- Comment #1 from David Dick dd...@cpan.org --- Fixed by upstream (Salvador Fandiño García). Sample build can be seen at http://s390.koji.fedoraproject.org/koji/taskinfo?taskID=1751203 committed to master. -- 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=0tKOOwOJPia=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 CPAN-Meta-2.150001.tar.gz uploaded to lookaside cache by pghmcfc
A file has been added to the lookaside cache for perl-CPAN-Meta: 99184aff262ed8065f19b4027e8e39ca CPAN-Meta-2.150001.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 Module-Find-0.13.tar.gz uploaded to lookaside cache by pghmcfc
A file has been added to the lookaside cache for perl-Module-Find: 28a11699901c2b07795ad59827d6ee66 Module-Find-0.13.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: FESCO request to revert password confirmation change in F22
On 10 Mar 2015, at 07:00, Matěj Cepl wrote: On 2015-03-10, 10:15 GMT, Björn Persson wrote: The user surely knows better what a good password is than the software does. If the user picks a crappy password, there's probably a good reason. There are two possible reasons why you would say that. Either you haven't even looked at the Ars Technica articles that have been discussed in this thread, or else you believe that a majority of users of all sorts of web services think it's all right if all the spies and script kiddies in the world have full access to their accounts. I think certainly there should be some protection against passwords like monkey (why monkey and not kangaroo, for example?) or iloveyou (as the Pope Francis said our message should be based on love not hate!), but when it tries to do too much more it is getting in the way even to the people who actually know what they are talking about. VM machine used only for temporary compilation on the old platform just doesn't have to have 63-random-chars password from https://www.grc.com/passwords.htm At the risk of complicating someone's life: Given that pattern-based attacks make meaningful password quality checking nigh impossible, why not just drop password quality checks. Instead, give a simple explanation that a secure password should: * be at least xx random characters in length, utilize both lower and upper case letters, as well as numerals and special characters, and not contain any human recognizable pattern -- and that any pattern that one can easily remember is probably insecure; or * be generated by a suitably random password generator, such as a 7 word Diceware password. Then embed a random password generator, such as /usr/bin/apg, and give the user a choice of generating a random password of whatever length the user wants, or simply entering whatever insecure password the user deems appropriate given the anticipated use of the installed OS. -- Mike -- 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-parent] Update to 0.231
commit ffd05d09c98de35ecb1e0d85620dbb4fa6f8d91c
Author: Paul Howarth p...@city-fan.org
Date: Tue Mar 10 11:53:27 2015 +
Update to 0.231
- New upstream release 0.231
- Restore test compatibility where Perl does not provide
Config::non_bincompat_options (CPAN RT#102626)
perl-parent.spec | 9 +++--
sources | 2 +-
2 files changed, 8 insertions(+), 3 deletions(-)
---
diff --git a/perl-parent.spec b/perl-parent.spec
index fa4a9eb..a36d36a 100644
--- a/perl-parent.spec
+++ b/perl-parent.spec
@@ -1,6 +1,6 @@
Name: perl-parent
Epoch: 1
-Version: 0.229
+Version: 0.231
Release: 1%{?dist}
Summary: Establish an ISA relationship with base classes at compile time
License: GPL+ or Artistic
@@ -10,7 +10,7 @@ Source0:
http://search.cpan.org/CPAN/authors/id/C/CO/CORION/parent-%{version}.ta
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(id -nu)
BuildArch: noarch
# Build:
-BuildRequires: perl = 4:5.13.10
+BuildRequires: perl
BuildRequires: perl(ExtUtils::MakeMaker)
# Run-time:
BuildRequires: perl(strict)
@@ -61,6 +61,11 @@ rm -rf %{buildroot}
%{_mandir}/man3/parent.3*
%changelog
+* Tue Mar 10 2015 Paul Howarth p...@city-fan.org - 1:0.231-1
+- Update to 0.231
+ - Restore test compatibility where Perl does not provide
+Config::non_bincompat_options (CPAN RT#102626)
+
* Sat Mar 7 2015 Paul Howarth p...@city-fan.org - 1:0.229-1
- Update to 0.229
- Add link to (Github) repository
diff --git a/sources b/sources
index 568542e..a3b39ef 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-960cd501d0a1f551ef72d6c77c8bc66b parent-0.229.tar.gz
+6598dc010917282a5bc3864092a75256 parent-0.231.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-CPAN-Meta] Update to 2.150001
commit 88101723215373fb36c08d2f7a7c8202d6541276
Author: Paul Howarth p...@city-fan.org
Date: Tue Mar 10 10:59:40 2015 +
Update to 2.150001
- New upstream release 2.150001
- Include allowed values for license field in 1.x historic licenses rather
than linking to Module::Build
- Documented when fragment merging became available
perl-CPAN-Meta.spec | 32 +++-
sources | 2 +-
2 files changed, 20 insertions(+), 14 deletions(-)
---
diff --git a/perl-CPAN-Meta.spec b/perl-CPAN-Meta.spec
index 9ad6280..80cddcc 100644
--- a/perl-CPAN-Meta.spec
+++ b/perl-CPAN-Meta.spec
@@ -1,23 +1,22 @@
Name: perl-CPAN-Meta
Summary:Distribution metadata for a CPAN dist
-Version:2.143240
-Release:2%{?dist}
+Version:2.150001
+Release:1%{?dist}
License:GPL+ or Artistic
-Group: Development/Libraries
-Source0:
http://search.cpan.org/CPAN/authors/id/D/DA/DAGOLDEN/CPAN-Meta-%{version}.tar.gz
URL:http://search.cpan.org/dist/CPAN-Meta/
+Source0:
http://search.cpan.org/CPAN/authors/id/D/DA/DAGOLDEN/CPAN-Meta-%{version}.tar.gz
BuildArch: noarch
# Build
BuildRequires: perl
BuildRequires: perl(ExtUtils::MakeMaker) = 6.17
-BuildRequires: perl(strict)
-BuildRequires: perl(warnings)
# Module
BuildRequires: perl(Carp)
BuildRequires: perl(CPAN::Meta::Requirements) = 2.121
BuildRequires: perl(Parse::CPAN::Meta) = 1.4414
BuildRequires: perl(Scalar::Util)
+BuildRequires: perl(strict)
BuildRequires: perl(version) = 0.88
+BuildRequires: perl(warnings)
# Main test suite
BuildRequires: perl(Data::Dumper)
BuildRequires: perl(File::Basename)
@@ -32,16 +31,17 @@ Requires: perl(:MODULE_COMPAT_%(eval $(perl
-V:version); echo $version))
Requires: perl(version) = 0.88
%{?perl_default_filter}
+
# Remove under-specified dependencies
-%global __requires_exclude
%{?__requires_exclude:%__requires_exclude|}^perl\\(CPAN::Meta::Requirements\\)$
+%global __requires_exclude
%{?__requires_exclude:%__requires_exclude|}^perl\\(CPAN::Meta::Converter\\)$
+%global __requires_exclude
%{__requires_exclude}|^perl\\(CPAN::Meta::Requirements\\)$
%global __requires_exclude %{__requires_exclude}|^perl\\(Parse::CPAN::Meta\\)
= 1.4400
%description
-Software distributions released to the CPAN include a META.json or,
-for older distributions, META.yml, which describes the distribution,
-its contents, and the requirements for building and installing the
-distribution. The data structure stored in the META.json file is described
-in CPAN::Meta::Spec.
+Software distributions released to the CPAN include a META.json or, for older
+distributions, META.yml, which describes the distribution, its contents, and
+the requirements for building and installing the distribution. The data
+structure stored in the META.json file is described in CPAN::Meta::Spec.
%prep
%setup -q -n CPAN-Meta-%{version}
@@ -63,7 +63,7 @@ make test
%files
%license LICENSE
-%doc Changes CONTRIBUTING history README Todo t/
+%doc Changes CONTRIBUTING.mkdn history README Todo t/
%{perl_vendorlib}/CPAN/
%{_mandir}/man3/CPAN::Meta.3*
%{_mandir}/man3/CPAN::Meta::Converter.3*
@@ -80,6 +80,12 @@ make test
%{_mandir}/man3/CPAN::Meta::Validator.3*
%changelog
+* Tue Mar 10 2015 Paul Howarth p...@city-fan.org - 2.150001-1
+- Update to 2.150001
+ - Include allowed values for license field in 1.x historic licenses rather
+than linking to Module::Build
+ - Documented when fragment merging became available
+
* Tue Jan 13 2015 Petr Pisar ppi...@redhat.com - 2.143240-2
- Correct dependencies
diff --git a/sources b/sources
index 2681d7b..337046c 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-c07f73197dc3ba869d131e94d1ab93fb CPAN-Meta-2.143240.tar.gz
+99184aff262ed8065f19b4027e8e39ca CPAN-Meta-2.150001.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-CPAN-Meta] Created tag perl-CPAN-Meta-2.150001-1.fc22
The lightweight tag 'perl-CPAN-Meta-2.150001-1.fc22' was created pointing to: 8810172... Update to 2.150001 -- 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-CPAN-Meta] Created tag perl-CPAN-Meta-2.150001-1.fc23
The lightweight tag 'perl-CPAN-Meta-2.150001-1.fc23' was created pointing to: 8810172... Update to 2.150001 -- 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: Issue with yum/systemd?
On 03/10/2015 03:13 AM, Dave Johansen wrote: #0 0xb76debac in __kernel_vsyscall () #1 0xb7510d03 in __waitpid_nocancel () from /lib/libpthread.so.0 #2 0xb6fa4842 in rpmScriptRun () from /lib/librpm.so.3 #3 0xb6f83c53 in runScript () from /lib/librpm.so.3 #4 0xb6f8434f in runInstScript () from /lib/librpm.so.3 #5 0xb6f8531b in rpmpsmRun () from /lib/librpm.so.3 #6 0xb6f9a3cb in rpmteProcess () from /lib/librpm.so.3 #7 0xb6fa1714 in rpmtsRun () from /lib/librpm.so.3 [...] It looks like yum is waiting on some process. It's waiting for a package scriptlet to finish. Is there a way I can tell what the process is and why it hasn't returned yet? Any other ideas on how I can figure out what is going wrong? You need to look for the child processes of yum and see what they're doing. Michal -- 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 1200306] New: Dependency problem with perl-libs
https://bugzilla.redhat.com/show_bug.cgi?id=1200306
Bug ID: 1200306
Summary: Dependency problem with perl-libs
Product: Fedora
Version: 21
Component: perl
Assignee: jples...@redhat.com
Reporter: frank-buett...@gmx.net
QA Contact: extras...@fedoraproject.org
CC: cw...@alumni.drew.edu, iarn...@gmail.com,
jples...@redhat.com, ka...@ucw.cz,
perl-devel@lists.fedoraproject.org, ppi...@redhat.com,
psab...@redhat.com, rc040...@freenet.de,
tcall...@redhat.com
Description of problem:
yum check reports:
4:perl-5.18.4-306.fc21.x86_64 has missing requires of perl-libs = ('4',
'5.18.4', '306.fc21')
4:perl-libs-5.18.4-306.fc21.x86_64 provides ('perl-libs', 'EQ', ('4', '5.18.4',
'306.fc21')) but it cannot be found
but rpm -q perl-libs reports:
perl-libs-5.18.4-306.fc21.x86_64
yum reinstall perl will install 32 libs:(
Reinstalling:
perlx86_64
4:5.18.4-306.fc21updates
8.1 M
Installing for dependencies:
glibc i686
2.20-8.fc21 updates
4.1 M
nss-softokn-freebl i686
3.17.4-1.fc21updates
195 k
perl-libs i686
4:5.18.4-306.fc21updates
717 k
What goes wrong?
--
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=vLyUSeXz2Oa=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: [EPEL-devel] xfce 4.12 for EPEL7?
Am 09.03.2015 um 17:17 schrieb Adam Miller: On Mon, Mar 9, 2015 at 10:43 AM, Rainer Traut tr...@gmx.de wrote: are there any plans to update xfce4 to latest release? There's been some discussion about it over on the Fedora XFCE SIG mailing list: https://lists.fedoraproject.org/pipermail/xfce/2015-March/002229.html https://lists.fedoraproject.org/pipermail/xfce/2015-March/002237.html There's also a COPR that's been setup to be a working space while some things are sorted out, it's not yet usable but I thought I'd point out that it exists and work is being done: https://copr.fedoraproject.org/coprs/maxamillion/epel7-xfce412/ Thx Adam for your answer. I will keep fingers crossed for 4.12. Rainer ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: F22: gnomekeyring no longer remembering unlocked ssh keys?
On Tue, Mar 10, 2015 at 11:12 AM, Hans de Goede hdego...@redhat.com wrote: Hi All, I've setup things so that the first time I want to unlock an ssh keys I need to explicitly type the unlock password (I do not want this to get remembered and the keys to automatically get unlocked the moment I log in). This used to work fine in F21 and in F22 till aprox 1-2 weeks ago. But now my unlock password is no longer cached at all, also not runtime, so I need to retype it even if I've just typed it 5 seconds ago. This is a bit too secure / inconvenient for me. Am I the only one seeing this ? Is this a deliberate change or a bug ? https://bugzilla.gnome.org/show_bug.cgi?id=744280 TL;DR: It is a bug ... fixed upstream. -- 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 1200306] Dependency problem with perl-libs
https://bugzilla.redhat.com/show_bug.cgi?id=1200306 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Assignee|jples...@redhat.com |ppi...@redhat.com --- Comment #1 from Petr Pisar ppi...@redhat.com --- Very probably the problem is not in the perl as 'perl' and 'perl-libs' packages are built from the same source package. So either your mirror, package database or package manager is broken. First verify this procedure does not work for you: $ repoquery --requires perl | grep perl-libs perl-libs perl-libs = 4:5.18.4-306.fc21 $ repoquery --whatprovides 'perl-libs = 4:5.18.4-306.fc21' perl-libs-4:5.18.4-306.fc21.x86_64 perl-libs-4:5.18.4-306.fc21.x86_64 perl-libs-4:5.18.4-306.fc21.i686 The second command is built from output of the first command. -- 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=f9NmPnlSGwa=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-Module-Find] Created tag perl-Module-Find-0.13-1.fc23
The lightweight tag 'perl-Module-Find-0.13-1.fc23' was created pointing to: 250e15e... Update to 0.13 -- 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-Find] Created tag perl-Module-Find-0.13-1.fc22
The lightweight tag 'perl-Module-Find-0.13-1.fc22' was created pointing to: 250e15e... Update to 0.13 -- 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-parent] Created tag perl-parent-0.231-1.fc23
The lightweight tag 'perl-parent-0.231-1.fc23' was created pointing to: ffd05d0... Update to 0.231 -- 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
Preupgrade-assistant assessment tool for upgrades in Fedora (does NOT replace FedUp)
Hi folks, I would like to briefly announced preupgrade-assistant as a tool for assess system before an upgrade by FedUp. Preupgrade-assistant is available since F22 [1] and can be used only for upgrades from major version to major version +1. It uses oscap project [4] and especially SCE (Script Check Engine) for assess the system [5]. Currently now it is not needed to install them before an FedUp. But could be useful after the upgrade. We will see in the future if FedUp will call API of preupgrade-assistant. What preupgrade-assistant does? 1) It *does not* replace *FedUp* but can enhanced upgrades. 2) It does *NOT* modify upgraded system before the upgrade. 3) It executes set of contents and informs user if package is somehow changed in the next release and what steps are needed for proper work on the next major version. 4) Because of preupgrade-assistant needs to have access all files therefore it needs to be executed under root. 5) Information gathered by preupgrade-assistant are stored in /root/preupgrade directory. 6) After a whole assessment user see a report with table what potential problems could arise after the upgrade. If user knows that he can fix the problem after the upgrade then he can create a postupgrade script which can do that automatically. This issue needs to called from FedUp after the upgrade and will be implemented later on. Pull request to FedUp is going to be created soon. Contents are optional of course and it depends on user if he wants to create it. If user thinks that contents is suitable then he can follow up packaging guidelines [2]. User has not create a XML file but 3 files like - INI file - Bash or Python script for checking the system - text file how to solve the problem after the upgrade. Preupgrade-assistant has been presented on DevConf2015 [3]. [1] https://fedoraproject.org/wiki/Changes/Preupgrade_Assistant [2] https://fedoraproject.org/wiki/Packaging:PreupgradeAssistant [3] https://www.youtube.com/watch?v=F7SFtE_2TrY [4] http://www.open-scap.org/page/Documentation [5] http://www.open-scap.org/page/SCE -- Petr Hracek Software Engineer Developer Experience Red Hat, Inc Mob: +420777056169 email: phra...@redhat.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
Broken dependencies: polymake
polymake has broken dependencies in the F-22 tree: On x86_64: polymake-2.13-18.git20141013.fc22.x86_64 requires perl = 4:5.20.1 On i386: polymake-2.13-18.git20141013.fc22.i686 requires perl = 4:5.20.1 On armhfp: polymake-2.13-18.git20141013.fc22.armv7hl requires perl = 4:5.20.1 Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Module-Find] Update to 0.13
commit 250e15e01fc018235af35f9530f579671348c54a
Author: Paul Howarth p...@city-fan.org
Date: Tue Mar 10 11:27:17 2015 +
Update to 0.13
- New upstream release 0.13
- Link to Module::Pluggable and Class::Factory::Util in SEE ALSO
- Align package name parsing with how perl does it (allowing single quotes
as module separator)
- Classify buildreqs by usage
perl-Module-Find.spec | 31 ---
sources | 2 +-
2 files changed, 25 insertions(+), 8 deletions(-)
---
diff --git a/perl-Module-Find.spec b/perl-Module-Find.spec
index f995998..358a54d 100644
--- a/perl-Module-Find.spec
+++ b/perl-Module-Find.spec
@@ -1,6 +1,6 @@
Name: perl-Module-Find
-Version: 0.12
-Release: 3%{?dist}
+Version: 0.13
+Release: 1%{?dist}
Summary: Find and use installed modules in a (sub)category
Group: Development/Libraries
License: GPL+ or Artistic
@@ -8,16 +8,26 @@ URL: http://search.cpan.org/dist/Module-Find/
Source0:
http://search.cpan.org/CPAN/authors/id/C/CR/CRENZ/Module-Find-%{version}.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(id -nu)
BuildArch: noarch
-BuildRequires: perl(Exporter)
+# Module Build
+BuildRequires: perl
BuildRequires: perl(ExtUtils::MakeMaker)
+BuildRequires: perl(Pod::Perldoc)
+# Module Runtime
+BuildRequires: perl(Exporter)
BuildRequires: perl(File::Find)
BuildRequires: perl(File::Spec)
+BuildRequires: perl(strict)
+BuildRequires: perl(warnings)
+# Test Suite
BuildRequires: perl(lib)
-BuildRequires: perl(Pod::Perldoc)
BuildRequires: perl(Test::More)
-BuildRequires: perl(Test::Pod)
-BuildRequires: perl(Test::Pod::Coverage)
+# Optional Tests
+BuildRequires: perl(Test::CPAN::Meta)
+BuildRequires: perl(Test::Pod) = 1.14
+BuildRequires: perl(Test::Pod::Coverage) = 1.04
+# Runtime
Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
+Requires: perl(Exporter)
%description
Module::Find lets you find and use modules in categories. This can be very
@@ -50,9 +60,16 @@ rm -rf %{buildroot}
%files
%doc Changes README examples/
%{perl_vendorlib}/Module/
-%{_mandir}/man3/Module::Find.3pm*
+%{_mandir}/man3/Module::Find.3*
%changelog
+* Tue Mar 10 2015 Paul Howarth p...@city-fan.org - 0.13-1
+- Update to 0.13
+ - Link to Module::Pluggable and Class::Factory::Util in SEE ALSO
+ - Align package name parsing with how perl does it (allowing single quotes
+as module separator)
+- Classify buildreqs by usage
+
* Wed Aug 27 2014 Jitka Plesnikova jples...@redhat.com - 0.12-3
- Perl 5.20 rebuild
diff --git a/sources b/sources
index 6a337ca..5da1354 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-abd614f3ebca68b4e7cc474400a8c0f2 Module-Find-0.12.tar.gz
+28a11699901c2b07795ad59827d6ee66 Module-Find-0.13.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 Math-Int64-0.51.tar.gz uploaded to lookaside cache by ddick
A file has been added to the lookaside cache for perl-Math-Int64: 164fa8a45e769a9dc4e1f9496a102e7d Math-Int64-0.51.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-Math-Int64] Upgrade to 0.51 to correct s390 build issues
commit 1ab82971e8f8885e34c86214969907ba9407663f
Author: David Dick dd...@cpan.org
Date: Tue Mar 10 20:41:00 2015 +1100
Upgrade to 0.51 to correct s390 build issues
.gitignore | 1 +
perl-Math-Int64.spec | 21 +++--
sources | 2 +-
3 files changed, 21 insertions(+), 3 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 0ed9365..3e24f21 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1,2 @@
/Math-Int64-0.34.tar.gz
+/Math-Int64-0.51.tar.gz
diff --git a/perl-Math-Int64.spec b/perl-Math-Int64.spec
index 468b85b..bbbcf3d 100644
--- a/perl-Math-Int64.spec
+++ b/perl-Math-Int64.spec
@@ -1,5 +1,5 @@
Name: perl-Math-Int64
-Version:0.34
+Version:0.51
Release:1%{?dist}
Summary:Manipulate 64 bits integers in Perl
License:(GPL+ or Artistic) and Public Domain and BSD
@@ -7,15 +7,24 @@ Group: Development/Libraries
URL:http://search.cpan.org/dist/Math-Int64/
Source0:
http://www.cpan.org/modules/by-module/Math/Math-Int64-%{version}.tar.gz
BuildRequires: perl
+BuildRequires: perl(base)
BuildRequires: perl(Carp)
BuildRequires: perl(Config)
+BuildRequires: perl(Capture::Tiny)
BuildRequires: perl(constant)
BuildRequires: perl(Exporter)
BuildRequires: perl(ExtUtils::MakeMaker)
+BuildRequires: perl(ExtUtils::CBuilder)
+BuildRequires: perl(File::Basename)
+BuildRequires: perl(File::Spec)
+BuildRequires: perl(File::Temp)
+BuildRequires: perl(IO::Handle)
BuildRequires: perl(overload)
BuildRequires: perl(strict)
+BuildRequires: perl(Scalar::Util)
BuildRequires: perl(Storable)
BuildRequires: perl(Test::More)
+BuildRequires: perl(Text::ParseWords)
BuildRequires: perl(warnings)
BuildRequires: perl(XSLoader)
Requires: perl(XSLoader)
@@ -43,11 +52,19 @@ find $RPM_BUILD_ROOT -type f -name '*.bs' -size 0 -exec rm
-f {} \;
make test
%files
-%doc Changes README examples
+%if 0%{?_licensedir:1}
+%license COPYING
+%else
+%doc COPYING
+%endif
+%doc Changes README.md examples
%{perl_vendorarch}/auto/*
%{perl_vendorarch}/Math*
%{_mandir}/man3/*
%changelog
+* Tue Mar 10 2015 David Dick dd...@cpan.org - 0.51-1
+- Upgrade to 0.51 to correct s390 build issues
+
* Thu Feb 19 2015 David Dick dd...@cpan.org - 0.34-1
- Initial release
diff --git a/sources b/sources
index 68ea6c6..1d79b9a 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-dd4b06121b0b6741271da3026a32f719 Math-Int64-0.34.tar.gz
+164fa8a45e769a9dc4e1f9496a102e7d Math-Int64-0.51.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: gnomekeyring no longer remembering unlocked ssh keys?
Hi All, I've setup things so that the first time I want to unlock an ssh keys I need to explicitly type the unlock password (I do not want this to get remembered and the keys to automatically get unlocked the moment I log in). This used to work fine in F21 and in F22 till aprox 1-2 weeks ago. But now my unlock password is no longer cached at all, also not runtime, so I need to retype it even if I've just typed it 5 seconds ago. This is a bit too secure / inconvenient for me. Am I the only one seeing this ? Is this a deliberate change or a bug ? Regards, Hans p.s. It seems that my problems with removable media not automounting are gone with the 3.15.91 gnome update, good work! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Failing rawhide builds in Copr
I have been approached by some of you, who already found out that rawhide builds in Copr are failing with: DEBUG util.py:388: rpmlib(ScriptletExpansion) = 4.9.0-1 is needed by glibc-common-2.21.90-5.fc23.x86_64 This is caused by https://bugzilla.redhat.com/show_bug.cgi?id=156477 Unless this is resolved, there is nothing I can do about it. Sincerly Mirek -- 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: FESCO request to revert password confirmation change in F22
On 2015-03-10, 10:15 GMT, Björn Persson wrote: The user surely knows better what a good password is than the software does. If the user picks a crappy password, there's probably a good reason. There are two possible reasons why you would say that. Either you haven't even looked at the Ars Technica articles that have been discussed in this thread, or else you believe that a majority of users of all sorts of web services think it's all right if all the spies and script kiddies in the world have full access to their accounts. I think certainly there should be some protection against passwords like monkey (why monkey and not kangaroo, for example?) or iloveyou (as the Pope Francis said our message should be based on love not hate!), but when it tries to do too much more it is getting in the way even to the people who actually know what they are talking about. VM machine used only for temporary compilation on the old platform just doesn't have to have 63-random-chars password from https://www.grc.com/passwords.htm 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-CPAN-Meta/f22] Update to 2.150001
Summary of changes: 8810172... Update to 2.150001 (*) (*) 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-Module-Find/f22] Update to 0.13
Summary of changes: 250e15e... Update to 0.13 (*) (*) 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
[Bug 1199969] perl-DateTime-Format-DateManip-0.04-17.fc23 FTBFS: Failed test 'Parse Date 'March 23, 2003''
https://bugzilla.redhat.com/show_bug.cgi?id=1199969 Petr Pisar ppi...@redhat.com changed: What|Removed |Added External Bug ID||CPAN 102670 -- 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=94kSFqRJFUa=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
[Test-Announce] Announcing the release of Fedora 22 Alpha!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Fedora 22 Alpha Release Announcement The Fedora 22 Alpha release has arrived, with a preview of the latest free and open source technology under development. Take a peek inside! • Get Fedora 22 Alpha Workstation https://getfedora.org/en/workstation/prerelease/ • Get Fedora 22 Alpha Server https://getfedora.org/en/server/prerelease/ • Get Fedora 22 Alpha Cloud https://getfedora.org/en/cloud/prerelease/ • Get Fedora 22 Alpha Spins https://spins.fedoraproject.org/prerelease What is the Alpha release? == The Alpha release contains all the exciting features of Fedora 22's editions in a form that anyone can help test. This testing, guided by the Fedora QA team, helps us target and identify bugs. When these bugs are fixed, we make a Beta release available. A Beta release is code-complete and bears a very strong resemblance to the third and final release. The final release of Fedora 22 is expected in May. We need your help to make Fedora 22 the best release yet, so please take some time to download and try out the Alpha and make sure the things that are important to you are working well. If you find a bug, please report it – every bug you uncover is a chance to improve the experience for millions of Fedora users worldwide. Together, we can make Fedora 22 another rock-solid release. We have a culture of coordinating new features and pushing fixes upstream as much as feasible, and your feedback will help improve not only Fedora but Linux and free software on the whole. Fedora 22 Cloud === The Fedora 22 Cloud Edition builds on the work completed during the Fedora 21 cycle, and brings in a number of improvements that make Fedora 22 a superb choice for running Linux in the cloud. Ready for the Fedora 22 release, we have: • The latest versions of rpm-ostree and rpm-ostree-toolbox. You can even use rpm-ostree-toolbox to generate your own Atomic hosts from a custom set of packages. • A Vagrant image for Fedora 22 Atomic Host and Cloud Images. We're supplying Vagrant boxes that work with KVM or VirtualBox, so users on Fedora will be able to easily consume the Vagrant images with KVM, and users on Mac OS X or Windows can use the VirtualBox image. • Tunir: A new, lightweight Continuous Integration (CI) tool for rapid testing of cloud images. While being driven by the need for simple CI for the Cloud Working Group, it's generic enough to be used by anyone to configure and run jobs/tests on their local system. Fedora 22 Server The Fedora 22 Server Edition brings several changes that will improve Fedora for use as a server in your environment. • Database Server Role: Fedora 21 introduced Rolekit, a daemon for Linux systems that provides a stable D-Bus interface to manage deployment of server roles. The Fedora 22 release adds onto that work with a database server role based on PostgreSQL. • Cockpit Updates: The Cockpit Web-based management application has been updated to the latest upstream release which adds many new features as well as a modular design for adding new functionality. Fedora 22 Workstation = As always, Fedora carries a number of improvements to make life better for its desktop users! Here's some of the goodness you'll get in Fedora 22 Workstation edition. Enhancements: • The GNOME Shell notification system has been redesigned and subsumed into the calendar widget. • The Terminal now notifies you when a long running job completes. • The login screen now uses Wayland by default. This is a step towards replacing X with Wayland, and users should not actually notice the difference. • Installation of GStreamer codecs, fonts, and certain document types is now handled by Software, instead of gnome-packagekit. • The Automatic Bug Reporting Tool (ABRT) now features better notifications, and uses the privacy control panel in GNOME to control information sent. Appearance: • The Nautilus file manager has been improved to use GActions, from the deprecated GtkAction APIs, for a better, more consistent experience. • The GNOME Shell has a refreshed theme for better usability. • The Qt/Adwaita theme is now code complete, and Qt notifications have been improved for smoother experience using Qt-based apps in Workstation. Under the covers: • The libinput library is now used for both X11 and Wayland for consistent input device handling. Spins • Plasma 5, the successor to KDE Plasma 4, is now the default workspace in the Fedora KDE spin. • The Xfce spin has been updated to Xfce 4.12 just in time for the Alpha release. This release has an enormous number of improvements, including HiDPI support, improvements to window tiling, support for Gtk3 plugins, and many improvements for
[Bug 1200306] Dependency problem with perl-libs
https://bugzilla.redhat.com/show_bug.cgi?id=1200306
--- Comment #3 from Petr Pisar ppi...@redhat.com ---
This looks good.
I think the key error is:
4:perl-libs-5.18.4-306.fc21.x86_64 provides ('perl-libs', 'EQ', ('4',
'5.18.4', '306.fc21')) but it cannot be found
I've never seen such error message. Maybe it means that the package is listed
in the database but not available as a file in the mirror.
What kind of yum implementation do you use? YUM or DNF (rpm -qf /usr/bin/yum)?
--
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=vYRbKlAbNla=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: Issue with yum/systemd?
Dave Johansen davejohan...@gmail.com writes: I posted this issue on the users mailing list but didn't get a response ( https://lists.fedoraproject.org/pipermail/users/2015-March/459083.html ), so I thought I'd try here. I did a yum remove on F21 and it hung after the 2nd of 8 .rpms and systemd has been using ~40% of the CPU since then. Here's the stacktrace from yum: #0 0xb76debac in __kernel_vsyscall () #1 0xb7510d03 in __waitpid_nocancel () from /lib/libpthread.so.0 #2 0xb6fa4842 in rpmScriptRun () from /lib/librpm.so.3 #3 0xb6f83c53 in runScript () from /lib/librpm.so.3 #4 0xb6f8434f in runInstScript () from /lib/librpm.so.3 #5 0xb6f8531b in rpmpsmRun () from /lib/librpm.so.3 #6 0xb6f9a3cb in rpmteProcess () from /lib/librpm.so.3 #7 0xb6fa1714 in rpmtsRun () from /lib/librpm.so.3 #8 0xb6fd0f0a in rpmts_Run () from /usr/lib/python2.7/site-packages/rpm/_rpm.so #9 0xb758a609 in PyCFunction_Call () from /lib/libpython2.7.so.1.0 #10 0xb754a645 in PyObject_Call () from /lib/libpython2.7.so.1.0 #11 0xb75e6f33 in PyEval_CallObjectWithKeywords () from /lib/libpython2.7.so.1.0 #12 0xb75616c6 in methoddescr_call () from /lib/libpython2.7.so.1.0 #13 0xb754a645 in PyObject_Call () from /lib/libpython2.7.so.1.0 #14 0xb75eb187 in PyEval_EvalFrameEx () from /lib/libpython2.7.so.1.0 #15 0xb75ecfe1 in PyEval_EvalFrameEx () from /lib/libpython2.7.so.1.0 #16 0xb75ee1ea in PyEval_EvalCodeEx () from /lib/libpython2.7.so.1.0 #17 0xb75ecf11 in PyEval_EvalFrameEx () from /lib/libpython2.7.so.1.0 #18 0xb75ee1ea in PyEval_EvalCodeEx () from /lib/libpython2.7.so.1.0 #19 0xb75ecf11 in PyEval_EvalFrameEx () from /lib/libpython2.7.so.1.0 #20 0xb75ee1ea in PyEval_EvalCodeEx () from /lib/libpython2.7.so.1.0 #21 0xb75ecf11 in PyEval_EvalFrameEx () from /lib/libpython2.7.so.1.0 #22 0xb75ee1ea in PyEval_EvalCodeEx () from /lib/libpython2.7.so.1.0 #23 0xb75ecf11 in PyEval_EvalFrameEx () from /lib/libpython2.7.so.1.0 #24 0xb75ee1ea in PyEval_EvalCodeEx () from /lib/libpython2.7.so.1.0 #25 0xb75ee344 in PyEval_EvalCode () from /lib/libpython2.7.so.1.0 #26 0xb76078db in run_mod () from /lib/libpython2.7.so.1.0 #27 0xb7608d70 in PyRun_FileExFlags () from /lib/libpython2.7.so.1.0 #28 0xb760a163 in PyRun_SimpleFileExFlags () from /lib/libpython2.7.so.1.0 #29 0xb760a6c8 in PyRun_AnyFileExFlags () from /lib/libpython2.7.so.1.0 #30 0xb761c911 in Py_Main () from /lib/libpython2.7.so.1.0 #31 0x08048578 in main () It looks like yum is waiting on some process. Is there a way I can tell what the process is and why it hasn't returned yet? Any other ideas on how I can figure out what is going wrong? Thanks, Dave This is somewhat reminiscent of [1]. Any chance that the process that actually uses the cpu is dbus related? [1] https://bugzilla.redhat.com/show_bug.cgi?id=1186018 Cheers, -- Jan Synacek Software Engineer, Red Hat signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
ocaml expert for review?
Hi, I've tried to package two ocaml-based packages. I have no idea about the language and tried to follow the guidelines in [0]. If there any experts in packaging in that language I'd appreciate a review (in exchange for another review if needed): https://bugzilla.redhat.com/show_bug.cgi?id=1200384 https://bugzilla.redhat.com/show_bug.cgi?id=1200389 regards, Nikos [0]. https://fedoraproject.org/wiki/Packaging:OCaml?rd=Packaging/OCaml -- 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 1200306] Dependency problem with perl-libs
https://bugzilla.redhat.com/show_bug.cgi?id=1200306 --- Comment #2 from Frank Büttner frank-buett...@gmx.net --- My output: repoquery --requires perl | grep perl-libs: perl-libs perl-libs = 4:5.18.4-306.fc21 repoquery --whatprovides 'perl-libs = 4:5.18.4-306.fc21': perl-libs-4:5.18.4-306.fc21.x86_64 perl-libs-4:5.18.4-306.fc21.i686 This was happened after update from F20 to F21 if it helps. -- 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=YO1FFqSKNga=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 1200306] Dependency problem with perl-libs
https://bugzilla.redhat.com/show_bug.cgi?id=1200306 --- Comment #4 from Frank Büttner frank-buett...@gmx.net --- I use Yum. rpm -qf /usr/bin/yum will result in: yum-3.4.3-153.fc21.noarch What I think that is mysterious, that an yum reinstall perl, will find the 64 package of perl and then the perl-libs package will be resolved to an 32 bit package. Resolving Dependencies -- Running transaction check --- Package perl.x86_64 4:5.18.4-306.fc21 will be reinstalled -- Processing Dependency: perl-libs = 4:5.18.4-306.fc21 for package: 4:perl-5.18.4-306.fc21.x86_64 -- Processing Dependency: perl-libs for package: 4:perl-5.18.4-306.fc21.x86_64 -- 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=1030uMExt4a=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: Updating engineering and scientific group in comps
On Tue, 2015-03-10 at 00:54 -0400, Amit Saha wrote: Hi, I would like to make the following change to the engineering and scientific group: diff --git a/comps-f22.xml.in b/comps-f22.xml.in index 7b03241..af70ac6 100644 --- a/comps-f22.xml.in +++ b/comps-f22.xml.in @@ -1449,6 +1449,10 @@ packagereq type=mandatorymaxima/packagereq packagereq type=mandatoryoctave/packagereq packagereq type=mandatorypython-matplotlib/packagereq + packagereq type=mandatorypython-matplotlib-tk/packagereq + packagereq type=mandatorypython-ipython/packagereq + packagereq type=mandatorypython-ipython-console/packagereq + packagereq type=mandatorypython-ipython-notebook/packagereq packagereq type=mandatoryR/packagereq packagereq type=mandatoryscipy/packagereq packagereq type=mandatoryspeedcrunch/packagereq @@ -1570,6 +1574,7 @@ packagereq type=optionalpython-biopython/packagereq packagereq type=optionalpython-cvxopt/packagereq packagereq type=optionalpython-networkx/packagereq + packagereq type=optionalpython-pandas/packagereq packagereq type=optionalpython-theano/packagereq packagereq type=optionalqalculate-gtk/packagereq packagereq type=optionalqalculate-kde/packagereq and similar change for f23 as well. Is there any objection? I am not sure if I have the right permissions to push this change as well..but that is another problem to solve. Yay ipython! Looks fine to me. - ajax -- 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 1198131] perl-Moo-2.000000 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1198131 Emmanuel Seyman emman...@seyman.fr changed: What|Removed |Added Status|NEW |CLOSED Resolution|--- |RAWHIDE Last Closed||2015-03-10 09:12:07 --- Comment #3 from Emmanuel Seyman emman...@seyman.fr --- Built for and mashed in 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=GC8EzcrpAQa=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: ImageMagick update to 6.9.0-9. So-name bump: libMagick++-6.Q16.so.3 - libMagick++-6.Q16.so.6
On Monday, 09 March 2015 at 16:06, Pavel Alexeev wrote: 06.03.2015 19:34, Kevin Fenzi пишет: On Fri, 6 Mar 2015 11:31:45 -0500 Rich Mattes richmat...@gmail.com wrote: There's no planned f22 rebuild for gcc5, as f22 defaults to -D_GLIBCXX_USE_CXX11_ABI=0. These issues are cropping up in f23. There should probably be a mass rebuild for f23, and sooner rather than later as rawhide is currently a big game of whack-a-mole when building c++ packages. As soon as gcc folks say things are settled down enough to do one, we can look at scheduling one. ;) It would be a shame to do it too soon though and have a bug requiring another one. I've been rebuilding things as I run into them being broken. (The other day it was the gobby stack: net6, libxml++, obby, gobby). Is it ok to rebuild all dependencies f.e. for fix build issue with pfstools introduced by that update? Or just fill bugzilla issues for owners? If a simple rebuild works, I'd say go ahead and do it. If it's more complicated, file a bug and attach any necessary patches (and ask the POC if you can act on it yourself). That's what I usually do. Regards, -- Fedora http://fedoraproject.org/wiki/User:Rathann RPMFusion http://rpmfusion.org Faith manages. -- Delenn to Lennier in Babylon 5:Confessions and Lamentations -- 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: ImageMagick update to 6.9.0-9. So-name bump: libMagick++-6.Q16.so.3 - libMagick++-6.Q16.so.6
On 03/10/2015 01:30 PM, Dominik 'Rathann' Mierzejewski wrote: On Monday, 09 March 2015 at 16:06, Pavel Alexeev wrote: 06.03.2015 19:34, Kevin Fenzi пишет: On Fri, 6 Mar 2015 11:31:45 -0500 Rich Mattes richmat...@gmail.com wrote: There's no planned f22 rebuild for gcc5, as f22 defaults to -D_GLIBCXX_USE_CXX11_ABI=0. These issues are cropping up in f23. There should probably be a mass rebuild for f23, and sooner rather than later as rawhide is currently a big game of whack-a-mole when building c++ packages. As soon as gcc folks say things are settled down enough to do one, we can look at scheduling one. ;) It would be a shame to do it too soon though and have a bug requiring another one. I've been rebuilding things as I run into them being broken. (The other day it was the gobby stack: net6, libxml++, obby, gobby). Is it ok to rebuild all dependencies f.e. for fix build issue with pfstools introduced by that update? Or just fill bugzilla issues for owners? If a simple rebuild works, I'd say go ahead and do it. It only partially does. If it's more complicated, Right now, many issues/problems are interacting and affecting packages simultanously, which occasionally render fixing these issues quite complicated. So far I've hit: - GCC-5.0 - Hardening - boost upgrade - ImageMagick - autotool upgrade. Openly said, the situation on f23 is a mess. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Guidelines change] Changes to the packaging guidelines
Here are the recent changes to the packaging guidelines:
The documentation section of the guidelines has been updated to include
a prohibition on using both %doc and direct installation of files into
%_pkgdocdir.
* https://fedoraproject.org/wiki/Packaging:Guidelines#Documentation
*
https://fedoraproject.org/w/index.php?title=Packaging%3AGuidelinesdiff=405928oldid=405492
* https://fedorahosted.org/fpc/ticket/338
-
The Python guidelines were modified to clarify the use of unversioned
macros (%__python instead of %__python2 or %__python3, for example).
* https://fedoraproject.org/wiki/Packaging:Python
*
https://fedoraproject.org/w/index.php?title=Packaging%3APythondiff=406053oldid=405394
* https://fedorahosted.org/fpc/ticket/498
-
Guidelines for Preupgrade Assistant packages have been added.
* https://fedoraproject.org/wiki/Packaging:PreupgradeAssistant
* https://fedorahosted.org/fpc/ticket/495
-
Corrected a typo/logic error in the bootstrapping guidelines:
* https://fedorahosted.org/fpc/ticket/501
*
https://fedoraproject.org/w/index.php?title=Packaging%3AGuidelinesdiff=405381oldid=403811
-
If a package builds a module for multiple python interpreters, it must
be done below the source tree and not in the %{py3dir} anymore. For an
example see:
* http://fedoraproject.org/wiki/Packaging:Python#Building_more_than_once
-
The guidelines on library bundling have been expanded to provide
information on some additional cases where the packaging committee may
grant exceptions.
*
https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Some_reasons_you_might_be_granted_an_exception
*
https://fedoraproject.org/w/index.php?title=Packaging%3ANo_Bundled_Librariesdiff=406057oldid=383256
* https://fedorahosted.org/fpc/ticket/391#comment:13
___
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
Re: ocaml expert for review?
On Tue, Mar 10, 2015 at 02:38:37PM +0100, Nikos Mavrogiannopoulos wrote: Hi, I've tried to package two ocaml-based packages. I have no idea about the language and tried to follow the guidelines in [0]. If there any experts in packaging in that language I'd appreciate a review (in exchange for another review if needed): https://bugzilla.redhat.com/show_bug.cgi?id=1200384 https://bugzilla.redhat.com/show_bug.cgi?id=1200389 I've added a few comments, but I don't have time to do a full review right now. [0]. https://fedoraproject.org/wiki/Packaging:OCaml?rd=Packaging/OCaml Unfortunately these guidelines are rather out of date. The intention is (and has been for quite a number of years) to update the packaging guidelines to match the de facto packaging of OCaml packages in Fedora. If someone wants to get started on that, I can certainly help out with it. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Guidelines change] Changes to the packaging guidelines
Here are the recent changes to the packaging guidelines:
The documentation section of the guidelines has been updated to include
a prohibition on using both %doc and direct installation of files into
%_pkgdocdir.
* https://fedoraproject.org/wiki/Packaging:Guidelines#Documentation
*
https://fedoraproject.org/w/index.php?title=Packaging%3AGuidelinesdiff=405928oldid=405492
* https://fedorahosted.org/fpc/ticket/338
-
The Python guidelines were modified to clarify the use of unversioned
macros (%__python instead of %__python2 or %__python3, for example).
* https://fedoraproject.org/wiki/Packaging:Python
*
https://fedoraproject.org/w/index.php?title=Packaging%3APythondiff=406053oldid=405394
* https://fedorahosted.org/fpc/ticket/498
-
Guidelines for Preupgrade Assistant packages have been added.
* https://fedoraproject.org/wiki/Packaging:PreupgradeAssistant
* https://fedorahosted.org/fpc/ticket/495
-
Corrected a typo/logic error in the bootstrapping guidelines:
* https://fedorahosted.org/fpc/ticket/501
*
https://fedoraproject.org/w/index.php?title=Packaging%3AGuidelinesdiff=405381oldid=403811
-
If a package builds a module for multiple python interpreters, it must
be done below the source tree and not in the %{py3dir} anymore. For an
example see:
* http://fedoraproject.org/wiki/Packaging:Python#Building_more_than_once
-
The guidelines on library bundling have been expanded to provide
information on some additional cases where the packaging committee may
grant exceptions.
*
https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Some_reasons_you_might_be_granted_an_exception
*
https://fedoraproject.org/w/index.php?title=Packaging%3ANo_Bundled_Librariesdiff=406057oldid=383256
* https://fedorahosted.org/fpc/ticket/391#comment:13
___
devel-announce mailing list
devel-announce@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
Re: [EPEL-devel] Process for supporting of new architectures
Peter Robinson pbrobin...@gmail.com wrote: ...snip... 1) Who is championing an architecture? Primarily IBM, but this will widen with the OpenPOWER foundation and it's members widening and HW from that initiative starting to become available. In the case of aarch64, if that happens, there will be similarities through Linaro Enterprise Group (LEG). Would we then have a tracker bug and a way for maintainers to call on these resources when/if their packages don't build? 2) Where do developers get access to hardware that they can debug issues if they want to. I'll let Mike (from IBM) answer this one in detail but there's a number of Universities hosting publicly accessible instances of HW with a process in place, Linaro has similar process with access to aarch64 HW running Fedora releases. This would be good to know. 3) How do we remove an architecture for whatever reasons? [Possible ones could be it turns out that CentOS i686 is dropped after one subrelease... or PPC64be is dropped by IBM because everyone moved to PPC64le. Or Itanium3 comes out and no one wants x86_64.] I don't see that would be any different to how we dropped PPC from mainline Fedora back in the F-12/13 timeframe but the architectures, once added to core RHEL, will be supported for the lifecycle of RHEL so I don't see that this process would be any different to how we dropped i686 or any of the 32 bit architectures in the transition from el6 - el7. I personally don't think it's actually worth expending too much time on this process until the issue arises, cross the bridge when we get there so to speak. I'm assuming we would keep ppc64 around too for now on the rhel's we support? ...snip... I don't see those issues any different to any of the other architectures or hardware that's needed to run Fedora infrastructure whether it be servers, storage or network. We have Enterprise support on the HW with all due process. Well, we don't have any ppc-le builders currently for EPEL. I guess this would need to be figured out off list first? We do have secondary arch Fedora ones, but the EPEL builders are in the primary koji, so they would need to be their own thing and have support, etc. I dont think we want to share builders with Fedora secondary ppc... We can figure this out off list tho. Some of the new P8 hardware that was recently racked is intended to be for EPEL on ppc64/ppc64le, I just need to get it configured and build VMs done etc From an infrastructure PoV the advantage that Power8 hardware has is that it's much closer to x86 in a number of ways and it'll enable us to mimic the deployment of things like virt builders in a single contiguous manner across all architectures to enable more simplified standardised manner to ease burden and increase automation from an infra PoV Thats good. ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: FESCO request to revert password confirmation change in F22
On Tue, Mar 10, 2015 at 5:38 PM, Björn Persson Bjorn@rombobjörn.se wrote: In the hope of clearing up any misunderstandings I'll make these statements: Thanks for the clarifications. My own clarification is that what I wrote is directed at large, not only to you personally. Usage of you was intended to be plural/generic. · The assertion that users in general know what a good password is is not a valid argument, because it's so obviously false that it's plain ridiculous. I'm uncertain how these things are even graded. There's a wide assortment of opinions on the subject, so I'm not convinced the problem is well enough understood by experts let alone users in general. What probability of a successful brute force attack distinguishes between good and weak passwords? Enough of this is sufficiently complicated by features such as rate limiting, attempt limits, reducing attack surface in various ways, that the same password may be sufficiently good in one case but not another. And users in general have no way of knowing or assessing such things. To what degree are they simply lucky because they're never or only very lightly and rarely attacked? There are many distortions here. · A policy that would permit Tr0ub4dor3 because it contains upper case, lower case, digits and symbols, but forbid correct horse battery staple because it's all lower case, would be counterproductive and a terrible mistake. Sure. Literally those passwords are disqualified because they're published. But as far as password types go, any leetspeak encoded dictionary word or words is suboptimal. It's a question of attack efficiency at what point in an attack a 3-4 word passphrase is guessed relative to leetspeak words, I have no idea if efficiency algorithms figure that leetspeak is more or less likely to be chosen by a human user thinking it meaningfully obfuscates attacks. The actual intended Anaconda password policy is unclear, not least of which is it's not stated in the UI. The change log suggests an 8 character passphrase with some complexity is necessary, however in practice it requires 10+ characters with some complexity. Completely random 8 and 9 character passwords are rejected. Efficiency wise, I'd expect passwords of 8 characters with some complexity to be guessed before 3-4 word passphrases. However, I'd expect 3-4 word passphrases guessed before password of 10-12 characters with some complexity. And in any case efficiency wise I think without any other mitigating factors like rate and attempt limiting, the time frame for a successful attack is sufficiently short for all of these that the password quality change proposed lacks efficacy and doesn't solve the problem it's intended to solve, and and a high UX cost. So I'd still say, if Fedora really wants to go down the road of being a policy enforcer (uncertain), if it really thinks it has the political capital with the community that this sort of might does make right, I'd say they're better off using it in a bold meaningful fashion rather than one that's next to meaningless. And that'd mean disallowing anything less than 25 characters. Give or take. -- Chris Murphy -- 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: Issue with yum/systemd?
On Tue, Mar 10, 2015 at 7:53 PM, Dave Johansen davejohan...@gmail.com wrote: On Tue, Mar 10, 2015 at 5:10 AM, Michal Schmidt mschm...@redhat.com wrote: On 03/10/2015 03:13 AM, Dave Johansen wrote: #0 0xb76debac in __kernel_vsyscall () #1 0xb7510d03 in __waitpid_nocancel () from /lib/libpthread.so.0 #2 0xb6fa4842 in rpmScriptRun () from /lib/librpm.so.3 #3 0xb6f83c53 in runScript () from /lib/librpm.so.3 #4 0xb6f8434f in runInstScript () from /lib/librpm.so.3 #5 0xb6f8531b in rpmpsmRun () from /lib/librpm.so.3 #6 0xb6f9a3cb in rpmteProcess () from /lib/librpm.so.3 #7 0xb6fa1714 in rpmtsRun () from /lib/librpm.so.3 [...] It looks like yum is waiting on some process. It's waiting for a package scriptlet to finish. Here's the contents of the script that it's waiting on: if [ $1 -eq 0 ] ; then # Package removal, not upgrade systemctl --no-reload disable minetest@default.service /dev/null 21 || : systemctl stop minetest@default.service /dev/null 21 || : fi Sorry for the multiple emails. It's stuck on the call to stop the service. When I run status, I prints the following: . minetest@default.service - Minetest multiplayer server w/ default.conf server config Loaded: loaded (/usr/lib/system/system/minetest@.service; disabled) Active: inactive (dead) Any recommendations on what I should do next to diagnose the source of the problem? 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
Re: libinput soname bump
On Tue, Mar 10, 2015 at 03:37:48PM +1000, Peter Hutterer wrote: libinput 0.12 had a soname bump. I've rebuilt weston, clutter, mutter, xorg-x11-drv-libinput in rawhide, the F22 packages will follow tomorrow. done, bodhi update is here: https://admin.fedoraproject.org/updates/mutter-3.15.91-2.fc22,xorg-x11-drv-libinput-0.8.0-2.fc22,clutter-1.21.6-2.fc22,weston-1.7.0-2.fc22,libinput-0.12.0-1.fc22 Cheers, Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [EPEL-devel] Process for supporting of new architectures
On Tuesday, March 10, 2015 03:43:03 PM Michael Wolf wrote: Peter Robinson pbrobinson at gmail.com wrote: ...snip... 1) Who is championing an architecture? Primarily IBM, but this will widen with the OpenPOWER foundation and it's members widening and HW from that initiative starting to become available. In the case of aarch64, if that happens, there will be similarities through Linaro Enterprise Group (LEG). Would we then have a tracker bug and a way for maintainers to call on these resources when/if their packages don't build? 2) Where do developers get access to hardware that they can debug issues if they want to. I'll let Mike (from IBM) answer this one in detail but there's a number of Universities hosting publicly accessible instances of HW with a process in place, Linaro has similar process with access to aarch64 HW running Fedora releases. This would be good to know. 3) How do we remove an architecture for whatever reasons? [Possible ones could be it turns out that CentOS i686 is dropped after one subrelease... or PPC64be is dropped by IBM because everyone moved to PPC64le. Or Itanium3 comes out and no one wants x86_64.] I don't see that would be any different to how we dropped PPC from mainline Fedora back in the F-12/13 timeframe but the architectures, once added to core RHEL, will be supported for the lifecycle of RHEL so I don't see that this process would be any different to how we dropped i686 or any of the 32 bit architectures in the transition from el6 - el7. I personally don't think it's actually worth expending too much time on this process until the issue arises, cross the bridge when we get there so to speak. I'm assuming we would keep ppc64 around too for now on the rhel's we support? ...snip... I don't see those issues any different to any of the other architectures or hardware that's needed to run Fedora infrastructure whether it be servers, storage or network. We have Enterprise support on the HW with all due process. Well, we don't have any ppc-le builders currently for EPEL. I guess this would need to be figured out off list first? We do have secondary arch Fedora ones, but the EPEL builders are in the primary koji, so they would need to be their own thing and have support, etc. I dont think we want to share builders with Fedora secondary ppc... We can figure this out off list tho. Some of the new P8 hardware that was recently racked is intended to be for EPEL on ppc64/ppc64le, I just need to get it configured and build VMs done etc Just out of curiosity how many systems are currently in place to do the EPEL builds for BE ppc64? There is currently two builders for ppc64 Dennis signature.asc Description: This is a digitally signed message part. ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: Issue with yum/systemd?
On Tue, Mar 10, 2015 at 5:10 AM, Michal Schmidt mschm...@redhat.com wrote: On 03/10/2015 03:13 AM, Dave Johansen wrote: #0 0xb76debac in __kernel_vsyscall () #1 0xb7510d03 in __waitpid_nocancel () from /lib/libpthread.so.0 #2 0xb6fa4842 in rpmScriptRun () from /lib/librpm.so.3 #3 0xb6f83c53 in runScript () from /lib/librpm.so.3 #4 0xb6f8434f in runInstScript () from /lib/librpm.so.3 #5 0xb6f8531b in rpmpsmRun () from /lib/librpm.so.3 #6 0xb6f9a3cb in rpmteProcess () from /lib/librpm.so.3 #7 0xb6fa1714 in rpmtsRun () from /lib/librpm.so.3 [...] It looks like yum is waiting on some process. It's waiting for a package scriptlet to finish. Here's the contents of the script that it's waiting on: if [ $1 -eq 0 ] ; then # Package removal, not upgrade systemctl --no-reload disable minetest@default.service /dev/null 21 || : systemctl stop minetest@default.service /dev/null 21 || : fi -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Schedule for Wednesday's FESCo Meeting (2015-03-11)
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-03-11 18:00 UTC' Links to all tickets below can be found at: https://fedorahosted.org/fesco/report/9 = Followups = #topic #1412 anaconda password change is causing consternation among the user community please review this policy decision .fesco 1412 https://fedorahosted.org/fesco/ticket/1412 = New business = #topic #1420 policy change: admins (non-POC) should be able to retire packages .fesco 1420 https://fedorahosted.org/fesco/ticket/1420 #topic #1421 FESCO Decision on COPR/Playground in GNOME Software .fesco 1421 https://fedorahosted.org/fesco/ticket/1421 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at https://fedorahosted.org/fesco/report/9 If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: FESCO request to revert password confirmation change in F22
On Tue, Mar 10, 2015 at 4:15 AM, Björn Persson Bjorn@rombobjörn.se wrote: Kevin Kofler wrote: The user surely knows better what a good password is than the software does. If the user picks a crappy password, there's probably a good reason. There are two possible reasons why you would say that. Either you haven't even looked at the Ars Technica articles that have been discussed in this thread, or else you believe that a majority of users of all sorts of web services think it's all right if all the spies and script kiddies in the world have full access to their accounts. I do not deny that weak passwords in certain contexts expose users to risks *I* don't feel comfortable with. Educating them is appropriate to the degree I think it's an obligation. Coercing them is inappropriate to the degree I'd rather see them hacked. Propose an ethical challenge to that. What's been proposed (and implemented) in the installer right now embraces the slipper slope of taking responsibility for a class of users. This is fraught with epistemic questions, including ethical ones. And the choice is to go after very weak passwords, but not weak ones. Why? What happens to this debate if the minimum passphrase is set to 25 characters? This has sound basis, congruent with all of the concerns from various popular web sites and services, to the cited XKCD, Ars Technica, Schneier articles, and others I've cited elsewhere including security@ list on this topic. Today Schneier raises the possibility the NSA has broken Microsoft's BitLocker. And yet we're debating whether to babysit users passwords. It's a juxtaposition that amuses me greatly. But it's a digression. So why not a 25 character limit? How does that change the debate? I for one would stop even debating it. I think even Kevin could consider just giving up the debate, because at that point, there would be thousands of users who would be having conniption fits. I doubt anyone would dispute this. So what does that tell us? It tells us people don't like being coerced. They don't like their judgement questioned. And it tells us password enforcement proponents presume that all of these ethical problems can be swept under the rug when there are few complainers. Ergo, might makes right. And promptly you've arrived at the very old debate of Thrasymachus. You do not get to just set it aside just because you don't like either its questions or its conclusions. What is Fedora going to be as it grows up? An enforcer of principles? An encourager of principles? An aggressive educator of principles? Let's try a real world example: Briefly opine on the fact on my mobile device I don't set a password at all. It's just a lock screen. Anyone can unlock it. I also don't encrypt it. Does it make you nervous on my behalf? Do you think it's bad judgment? Do you lock and/or encrypt your wallet? If not, why not? How is a mobile device different from a wallet (other than the obvious physical differences)? Are Google, Cyanogen, Apple, Microsoft acting wrongly by permitting no passwords on mobile devices? If so, why would they do this? I use a relatively strong 6 word passphrase for FDE on my laptop however. How do you account for this difference in policy? If you can't explain this sufficiently that you can enable it as an enforceable policy, I don't see how you've done the very basic (though extremely difficult and expensive) epistemic work to start forcing people to change their behavior rather than just educate them. Because without that, I think you'll lack sufficient mandate for a might makes right policy. -- Chris Murphy -- 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: Self Introduction : Chandan Kumar
On Tue, Mar 10, 2015 at 11:43:59PM +0530, Chandan kumar wrote: Hi, Myself is Chandan Kumar. Welcome to Fedora. I contribute to Upstream OpenStack-tempest [1.] Recently i have started contributing to RDO packaging. The openstack-oslo team has released a new python package `debtcollector`.[2.] For that i have submitted a package review request at https://bugzilla.redhat.com/show_bug.cgi?id=1200520 . It is my first package and i am looking to get sponsored for this package. Please review this package and let us know if any modifications are required. I made some commnt on the review. Zbyszek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Self Introduction : Chandan Kumar
Hi, Myself is Chandan Kumar. I contribute to Upstream OpenStack-tempest [1.] Recently i have started contributing to RDO packaging. The openstack-oslo team has released a new python package `debtcollector`.[2.] For that i have submitted a package review request at https://bugzilla.redhat.com/show_bug.cgi?id=1200520 . It is my first package and i am looking to get sponsored for this package. Please review this package and let us know if any modifications are required. Links: [1.] http://stackalytics.com/report/users/chandankumar-093047 [2.] http://docs.openstack.org/developer/debtcollector Thanks Chandan Kumar -- 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: FESCO request to revert password confirmation change in F22
On Tue, Mar 10, 2015 at 2:16 PM, Chris Murphy li...@colorremedies.com wrote: So why not a 25 character limit? That's maybe confusing. Why not a 25 character minimum? -- Chris Murphy -- 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] Process for supporting of new architectures
On 10 March 2015 at 14:43, Michael Wolf m...@linux.vnet.ibm.com wrote: Peter Robinson pbrobinson at gmail.com wrote: We can figure this out off list tho. Some of the new P8 hardware that was recently racked is intended to be for EPEL on ppc64/ppc64le, I just need to get it configured and build VMs done etc Just out of curiosity how many systems are currently in place to do the EPEL builds for BE ppc64? One physical system with two virtual boxes on it. It was on a temporary loan that seems to have crept into longer term. [There originally was going to be a longer term replacement system but that was put on hiatus to get the KVM aware 7 series systems.] -- Stephen J Smoogen. ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: FESCO request to revert password confirmation change in F22
Björn Persson wrote: Kevin Kofler wrote: The user surely knows better what a good password is than the software does. If the user picks a crappy password, there's probably a good reason. There are two possible reasons why you would say that. Either you haven't even looked at the Ars Technica articles that have been discussed in this thread, or else you believe that a majority of users of all sorts of web services think it's all right if all the spies and script kiddies in the world have full access to their accounts. The replies to that message make me wonder if perhaps some people misunderstood what I meant. I haven't clearly expressed any opinions about enforced requirements on passphrases, and some people may have made assumptions about my opinions. In the hope of clearing up any misunderstandings I'll make these statements: · The fact that we don't have a good algorithm for calculating passphrase quality is a good argument against trying to enforce a minimum passphrase quality. · The fact that use cases exist where there is little need for access control – for example temporary and isolated test installations – is a valid argument against trying to enforce a minimum passphrase quality. · The assertion that users in general know what a good password is is not a valid argument, because it's so obviously false that it's plain ridiculous. · A policy that would permit Tr0ub4dor3 because it contains upper case, lower case, digits and symbols, but forbid correct horse battery staple because it's all lower case, would be counterproductive and a terrible mistake. Björn Persson pgprS4myxtORW.pgp Description: OpenPGP digital signatur -- 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: Pidgin Lync-collab COPR
David Woodhouse dw...@infradead.org writes: I've *just* managed to commit the in-call DTMF support that has been kicking around for about 4 years! ... In the meantime though, any additional testing would be welcome... For the interested, this patch is now in F21 testing: https://admin.fedoraproject.org/updates/pidgin-2.10.11-2.fc21 -- Jan Synacek Software Engineer, Red Hat signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
wxGTK C++ ABI issues
On 02/19/2015 08:15 AM, Jakub Jelinek wrote: On Thu, Feb 19, 2015 at 04:12:43PM +0100, Frantisek Kluknavsky wrote: a list of things that usually break with each new gcc (like fortran modules) would be nice to avoid a lot of pain with debugging. Does it already exist? WxGTK keeps a string WX_BUILD_OPTIONS_SIGNATURE currently saying 2.8 (no debug,Unicode,compiler with C++ ABI 1002,wx containers,compatible with 2.4,compatible with 2.6) and it is checked at runtime. C++ ABI is supposed to be unchanged in Fedora 22. This string changed anyway because __GXX_ABI_VERSION in gcc changed. Is this expected/correct? Each freshly rebuilt wx application will crash now. After wxGTK is rebuilt, each old application will crash. A provenpackager should probably step in. That is a WxGTK bug. __GXX_ABI_VERSION can change, but usually the result is still ABI compatible, g++ emits just some aliases when mangling has changed. Jakub Could we please get this fixed? F22 is broken with this at the moment. https://bugzilla.redhat.com/show_bug.cgi?id=1200611 -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.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: Self Introduction : Chandan Kumar
Hi Chandan, start by doing informal reviews and linking them back in your own review. Then you have a deps to package before: python-wrapt. Regards, H. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
