i686 kernel bug priority plan
Hello Fellow Contributors! Our kernel team has been adrift in bugs roughly forever. The time we spend on triage is time we don't get to spend fixing substantial bugs on hardware lots of people are using, especially new/emergent hardware. We have spoken previously about the difficulty of kernel bug triage as a Fedora effort, and also about future kernel direction at Flock 2014[1]. The Fedora kernel engineers are taking a new approach we think will result in a better kernel overall. We can do more substantial fixes for users, have more interaction upstream, and minimize burnout for the team members. Not coincidentally, we think this will correspondingly strengthen relations between Fedora and kernel communities. We enjoy a healthy relationship there, but we're always looking to do better. If we pursue the goal of fixing bugs based on impact, we can enjoy these benefits. We see impact as a combination of incidence rate and criticality. But as with all things there are tradeoffs. One of the tradeoffs we foresee is that i686 bugs are unlikely to rise to such a high level of impact. Plenty of bugs are common across architectures, and fixing those bugs will benefit i686 too. This is an opportunity for community members for whom i686 is a passion to join the team to participate in the bugfixing required. We previously called out the need for assistance[2], but had no substantial response. We hope that being transparent about our priorities will prompt interested community members to help. If you are interested to help, here are some resources to get started: * Kernel team wiki page: https://fedoraproject.org/wiki/Kernel -- includes mailing list and IRC information * Bugzilla query: http://tinyurl.com/k6zhz34 -- some example bugs that could use your help It's possible down the road that, if there is no community interest in i686, the project might look at other options such as making i686 a secondary architecture. This is not because we want to drive away 32-bit users; but we're passionate about making the Fedora kernel work well for the majority of our user base. This prioritization helps us get closer to that goal. Our Fedora kernel engineers are devoted full time to supporting Fedora. Just as any other community members, we have to choose where to spend our cycles because those cycles are finite. With this strategy we think we can make Fedora a better system overall, across all our editions. Thanks josh, for the Fedora Kernel Team [1] http://www.youtube.com/watch?v=F9E0FF4XFDw [2] http://jwboyer.livejournal.com/49909.html -- 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: i686 kernel bug priority plan
This is an opportunity for community members for whom i686 is a passion to join the team to participate in the bugfixing required. We previously called out the need for assistance[2], but had no substantial response. We hope that being transparent about our priorities will prompt interested community members to help. If you are interested to help, here are some resources to get started: snip Given our past history with passive requests for help, I think it might be beneficial to put a time limit on things. For example, if no i686 Kernel SIG steps up and agrees to handle bugs on that platform, we should strongly consider demoting i686 to secondary architecture for installation media at the Fedora 23 branch point (about six months from now). Note: I'm only suggesting that we would demote the kernel and install media, *NOT* the 32-bit runtime libraries on an x86_64 system; we would still need to be building those. How do you propose demoting to secondary only the kernel/install without the userspace? Do you mean de-emphasise the i686 bit platform? 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: i686 kernel bug priority plan
On 02/25/2015 01:50 PM, Stephen Gallagher wrote: i686 Kernel SIG steps up and agrees to handle bugs on that platform Interesting so you are saying that the kernel sub community is effectively only x86_64 If you are going down that road you better ask for every arch kernel SIG to emerge or step up in the process. Where does ARM fit in this plan JBG -- 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: Why sysrq is limited to only sync command on official fedora kernel?
On Wed, Feb 25, 2015 at 8:54 AM, Ali AlipourR alipoo...@gmail.com wrote: Hi, Why sysrq is limited to only sync command on official fedora kernel? The kernel itself isn't limited. It's just set that way in /usr/lib/sysctl.d/50-default.conf which is provided by systemd. You can edit that file, create your own in /etc/sysctrl.d/, or (as root) set it to whatever you would like via /proc/sys/kernel/sysrq. 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
[perl-UNIVERSAL-require/f22] Update to 0.18
Summary of changes: c157510... Update to 0.18 (*) (*) 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-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[PkgDB] limb updated perl-Monitoring-Plugin
user: limb created branch epel7 on package perl-Monitoring-Plugin To make changes to this package see: https://admin.fedoraproject.org/pkgdb/package/perl-Monitoring-Plugin -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[PkgDB] limb:perl-Monitoring-Plugin watchbugzilla set to Approved
user: limb set for jpo acl: watchbugzilla of package: perl-Monitoring-Plugin from: to: Approved on branch: epel7 To make changes to this package see: https://admin.fedoraproject.org/pkgdb/package/perl-Monitoring-Plugin -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[PkgDB] limb:perl-Monitoring-Plugin watchbugzilla set to Approved
user: limb set for jpo acl: watchbugzilla of package: perl-Monitoring-Plugin from: to: Approved on branch: el6 To make changes to this package see: https://admin.fedoraproject.org/pkgdb/package/perl-Monitoring-Plugin -- 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: i686 kernel bug priority plan
On Wed, Feb 25, 2015 at 9:15 AM, Peter Robinson pbrobin...@gmail.com wrote: On Wed, Feb 25, 2015 at 2:14 PM, Peter Robinson pbrobin...@gmail.com wrote: i686 Kernel SIG steps up and agrees to handle bugs on that platform Interesting so you are saying that the kernel sub community is effectively only x86_64 If you are going down that road you better ask for every arch kernel SIG to emerge or step up in the process. Where does ARM fit in this plan The ARM SIG has always been primary on the ARM kernel and associated issues. For that matter so have aarch64/ppc64/s390 SIGs Yes, and they are model examples of teams passionate about something and working towards it. I try and give all the credit for the success of those architectures to those teams whenever possible. The Fedora kernel engineers do very very little for those kernels, so a hearty thank you once more. 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: i686 kernel bug priority plan
i686 Kernel SIG steps up and agrees to handle bugs on that platform Interesting so you are saying that the kernel sub community is effectively only x86_64 If you are going down that road you better ask for every arch kernel SIG to emerge or step up in the process. Where does ARM fit in this plan The ARM SIG has always been primary on the ARM kernel and associated issues. For that matter so have aarch64/ppc64/s390 SIGs Should not the kernel list be renamed to x86_64 to be in-line with and follow the tradition of the other architectures mailinglist setup? No, if you read the list archives there's discussions across all architectures about the kernel there, the arch SIG lists cover userspace, testing and other things other than just kernel. 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: Why sysrq is limited to only sync command on official fedora kernel?
On Wed, Feb 25, 2015 at 9:35 AM, Ali AlipourR alipoo...@gmail.com wrote: Why sysrq is limited to only sync command on official fedora kernel? The kernel itself isn't limited. It's just set that way in /usr/lib/sysctl.d/50-default.conf which is provided by systemd. You can edit that file, create your own in /etc/sysctrl.d/, or (as root) set it to whatever you would like via /proc/sys/kernel/sysrq. Of course it can be changed at runtime, but I mean why official fedora kernel shouldn't be configured to allow all (or at least a wider subset) of sysrq commands by default? Maybe we're getting hung up on a terminology issue, but this isn't a kernel configuration issue. It's something userspace is doing. This way official fedora live CDs are unsuitable for system recovery tasks; you have to change sysrq value every time you use live CDs or build your own live CD. That's a good point. Since the live images have a rescue mode, maybe there is a way to use a different value when booted into that. How that would look, I'm not sure. Maybe dracut would need to include an override file in the initramfs. 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
[Bug 1196050] perl-Params-Validate-1.18 testsuite failure on f20
https://bugzilla.redhat.com/show_bug.cgi?id=1196050 --- Comment #6 from Paul Howarth p...@city-fan.org --- Updates built and submitted, along with buildroot overrides, which are now in the F-20 buildroot so you should be able to build in koji now. -- 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=1h2vi0EsAZa=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 1196195] perl-Pod-Spell-1.16 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1196195 --- Comment #1 from Upstream Release Monitoring upstream-release-monitor...@fedoraproject.org --- Scratch build succeeded http://koji.fedoraproject.org/koji/taskinfo?taskID=9069407 -- 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=I53fH678Uta=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: repo-mirrorlist quality control?
On 02/25/2015 01:49 PM, Richard Z wrote: Hi, when doing yum update in the last few weeks I am seeing thousands of errors like (1/2): _local/primary_db| 3.4 MB 00:00 updates/21/i386/primary_db FAILED http://mirror.netcologne.de/fedora/linux/updates/21/i386/repodata/1f20884a6cce1ba8e28bb19e6dd364fe787906c1f0504c0d06e0fb1be8ab07ac-primary.sqlite.bz2: [Errno 14] HTTP Error 404 - Not Found Trying other mirror. updates/21/i386/primary_db FAILED http://mirror.fraunhofer.de/dl.fedoraproject.org/fedora/linux/updates/21/i386/repodata/1f20884a6cce1ba8e28bb19e6dd364fe787906c1f0504c0d06e0fb1be8ab07ac-primary.sqlite.bz2: [Errno 14] curl#18 - transfer closed with 1521891 bytes remaining to read Trying other mirror. (2/2): updates/21/i386/primary_db | 4.5 MB 03:26 updates/21/i386/updateinfo FAILED http://mirror.netcologne.de/fedora/linux/updates/21/i386/repodata/343502d43eec1d45e0f951d2c2d3373a146515d175e61c1609b44391f93cf08a-updateinfo.xml.gz: [Errno 14] HTTP Error 404 - Not Found Trying other mirror. updates/21/i386/pkgtagsFAILED http://mirror.netcologne.de/fedora/linux/updates/21/i386/repodata/6803dec7b564b291cead9d2b720a47bb73da52577e7f25e5b9df41582455f7a1-pkgtags.sqlite.gz: [Errno 14] HTTP Error 404 - Not Found Trying other mirror. (1/2): updates/21/i386/updateinfo | 644 kB 01:28 (2/2): updates/21/i386/pkgtags | 1.4 MB 03:11 and http://mirror.netcologne.de/fedora/linux/updates/21/i386/drpms/autocorr-en-4.3.5.2-11.fc21_4.3.6.2-3.fc21.noarch.drpm: [Errno 14] HTTP Error 404 - Not Found Trying other mirror. While very rarely some other mirrors have problems, netcologne seems to be failing systematically for me. Is it just me? No, it's not just you and it's not just the mirrors you list. Sometimes all Europe mirrors seem to be out of sync (This had happened yesterday.), with mirrormanager still reporting them as functional. Seems to me as if mirrormanager is dysfunctional, which then unhides deficiencies in yum/dnf and mock. Is there some place to report? I have no idea, except that I am feeling quite sour about this, as well. 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
Re: i686 kernel bug priority plan
On Wed, 2015-02-25 at 14:30 +0100, drago01 wrote: On Wed, Feb 25, 2015 at 2:15 PM, Josh Boyer jwbo...@fedoraproject.org wrote: Hello Fellow Contributors! [...] It's possible down the road that, if there is no community interest in i686, the project might look at other options such as making i686 a secondary architecture. This is not because we want to drive away 32-bit users; but we're passionate about making the Fedora kernel work well for the majority of our user base. This prioritization helps us get closer to that goal. Just to make this clear because this has suggestion has been brought up multiple times ... while there might be less interests in running a i686 kernel the story is very different for i686 user space (mostly libraries but also applications like wine) even on a x86_64 host kernel. So don't draw a line from no interests in i686 kernel to no interesst in the i686 architecture and therefore it should be secondary .. its not as simple as with a completely isolated architecture like ppc. Right, Josh isn't talking about retiring the i686 runtime (particularly in terms of multiarch support on x86_64). Merely that work on i686-specific bugs in the kernel are going to see less attention so they can focus their limited resources on bugs with a wider impact. signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Why sysrq is limited to only sync command on official fedora kernel?
Hi, Why sysrq is limited to only sync command on official fedora kernel? Regards, Ali -- 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-Test-Version/f20] (9 commits) ...Update to 1.004001
Summary of changes: cc17dcb... Update to 1.002004 (*) ebcd0ba... Bootstrap epel7 build (*) dc10383... Bootstrap build for epel7 done (*) 4d0a7ce... - Rebuilt for https://fedoraproject.org/wiki/Fedora_21_Mass (*) 8b96eaf... Perl 5.20 rebuild (*) 89cc0f4... Perl 5.20 re-rebuild of bootstrapped packages (*) 822c9f8... Update to 1.003001 (*) 6dee4ce... Update to 1.004000 (*) 1a5274b... Update to 1.004001 (*) (*) 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
Re: RFC : in-development flag for packages
On Mon, 2015-02-23 at 17:03 +0200, Yanko Kaneti wrote: On Mon, 2015-02-23 at 14:39 +, Petr Pisar wrote: On 2015-02-22, Yanko Kaneti yan...@declera.com wrote: Introduce an in-development flag for packages in Fedora. I like the confession that no in-developemnt code gets magically stable after half year of sitting in the Rawhide. Indeed that was part of my thinking. In-development packaging that might never reach maturity is a fact of life and the idea was for us to embrace it and manage it in the same place where we manage everything else. Thanks for the feedback. I'm somewhat of the opinion that code should never land in Rawhide that isn't stable upstream (or expected to be within that Fedora release cycle). Code that isn't ready and won't be ready in time belongs in a COPR. signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Why sysrq is limited to only sync command on official fedora kernel?
Am 25.02.2015 um 15:35 schrieb Ali AlipourR: Why sysrq is limited to only sync command on official fedora kernel? The kernel itself isn't limited. It's just set that way in /usr/lib/sysctl.d/50-default.conf which is provided by systemd. You can edit that file, create your own in /etc/sysctrl.d/, or (as root) set it to whatever you would like via /proc/sys/kernel/sysrq. Of course it can be changed at runtime, but I mean why official fedora kernel shouldn't be configured to allow all (or at least a wider subset) of sysrq commands by default? This way official fedora live CDs are unsuitable for system recovery tasks; you have to change sysrq value every time you use live CDs or build your own live CD it is nothing someone is using regulary and that settings are security settings recommended by most auditing tools signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[perl-Test-Version] Created tag perl-Test-Version-1.004001-1.fc20
The lightweight tag 'perl-Test-Version-1.004001-1.fc20' was created pointing to: 1a5274b... Update to 1.004001 -- 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-UNIVERSAL-require] Update to 0.18
commit c157510fd4949a85df36b241643e141190960ac8
Author: Paul Howarth p...@city-fan.org
Date: Wed Feb 25 13:24:41 2015 +
Update to 0.18
- New upstream release 0.18
- Skip the taint test if Perl was compiled without taint support
- Changed use of use vars to our
- Added strict and warnings to PREREQ_PM
- Classify buildreqs by usage
perl-UNIVERSAL-require.spec | 28 +---
sources | 2 +-
2 files changed, 22 insertions(+), 8 deletions(-)
---
diff --git a/perl-UNIVERSAL-require.spec b/perl-UNIVERSAL-require.spec
index 6556f63..36f41e5 100644
--- a/perl-UNIVERSAL-require.spec
+++ b/perl-UNIVERSAL-require.spec
@@ -1,6 +1,6 @@
Name: perl-UNIVERSAL-require
-Version:0.17
-Release:3%{?dist}
+Version:0.18
+Release:1%{?dist}
Summary:Require() modules from a variable
Group: Development/Libraries
License:GPL+ or Artistic
@@ -8,15 +8,22 @@ URL:http://search.cpan.org/dist/UNIVERSAL-require/
Source0:
http://search.cpan.org/CPAN/authors/id/N/NE/NEILB/UNIVERSAL-require-%{version}.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(id -nu)
BuildArch: noarch
+# Module Build
BuildRequires: perl
-BuildRequires: perl(Carp)
BuildRequires: perl(ExtUtils::MakeMaker)
-BuildRequires: perl(lib)
+# Module Runtime
+BuildRequires: perl(Carp)
BuildRequires: perl(strict)
-BuildRequires: perl(Test::More) = 0.47
-BuildRequires: perl(vars)
+BuildRequires: perl(UNIVERSAL)
BuildRequires: perl(warnings)
+# Test Suite
+BuildRequires: perl(Config)
+BuildRequires: perl(Exporter)
+BuildRequires: perl(lib)
+BuildRequires: perl(Test::More) = 0.47
+# Runtime
Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
+Requires: perl(UNIVERSAL)
# Filter bogus provide for perl(UNIVERSAL) (rpm 4.9 onwards)
%global __provides_exclude ^perl\\(UNIVERSAL\\)
@@ -50,9 +57,16 @@ rm -rf $RPM_BUILD_ROOT
%files
%doc Changes README
%{perl_vendorlib}/UNIVERSAL/
-%{_mandir}/man3/UNIVERSAL::require.3pm*
+%{_mandir}/man3/UNIVERSAL::require.3*
%changelog
+* Wed Feb 25 2015 Paul Howarth p...@city-fan.org - 0.18-1
+- Update to 0.18
+ - Skip the taint test if Perl was compiled without taint support
+ - Changed use of use vars to our
+ - Added strict and warnings to PREREQ_PM
+- Classify buildreqs by usage
+
* Wed Aug 27 2014 Jitka Plesnikova jples...@redhat.com - 0.17-3
- Perl 5.20 rebuild
diff --git a/sources b/sources
index 180798e..a0c807a 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-3b99222dec970cca4a0c86bf8b17a0f3 UNIVERSAL-require-0.17.tar.gz
+2cdfd54bc7e270c77456a8e929a091b3 UNIVERSAL-require-0.18.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: New Upstream Release Monitoring Systems
On Tue, Feb 24, 2015 at 11:42:49AM -0700, Dave Johansen wrote: On Tue, Feb 24, 2015 at 9:51 AM, Pierre-Yves Chibon pin...@pingoured.fr wrote: On Tue, Feb 24, 2015 at 10:33:34AM -0600, Michael Catanzaro wrote: A A This looks cool. A A On Fri, Feb 20, 2015 at 2:36 PM, Ralph Bean rb...@redhat.com wrote: A A A - Enable the monitoring flag for that Fedora package in pkgdb2[4]. A A I think this is the step people will forget to do. If there was at least a A A reminder on the release-monitoring website, that would be helpful. This is now `on` by default for every new package added to pkgdb. For the old one you will have to do it manually (or via a script using the API). Could a one time report be generated and sent to the mailing? Or is the list too long for that to be feasible? Rather than doing a one-time script/report I wrote a script anyone can run as often as they would like: http://blog.pingoured.fr/index.php?post/2015/02/25/Check-your-packages-in-pkgdb-and-anitya Pierre -- 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: i686 kernel bug priority plan
On Wed, Feb 25, 2015 at 8:30 AM, drago01 drag...@gmail.com wrote: On Wed, Feb 25, 2015 at 2:15 PM, Josh Boyer jwbo...@fedoraproject.org wrote: Hello Fellow Contributors! [...] It's possible down the road that, if there is no community interest in i686, the project might look at other options such as making i686 a secondary architecture. This is not because we want to drive away 32-bit users; but we're passionate about making the Fedora kernel work well for the majority of our user base. This prioritization helps us get closer to that goal. Just to make this clear because this has suggestion has been brought up multiple times ... while there might be less interests in running a i686 kernel the story is very different for i686 user space (mostly libraries but also applications like wine) even on a x86_64 host kernel. Yes. The paragraph didn't say kernel and it certainly didn't say that the kernel team would be proposing demotion. It's simply possible that the rest of the project might look at the results that way. So don't draw a line from no interests in i686 kernel to no interesst in the i686 architecture and therefore it should be secondary .. its not as simple as with a completely isolated architecture like ppc. Actually, even your example is flawed. ppc64 ran ppc userspace almost exclusively until the RHEL6 era. It's really kind of the same thing. The major difference being that both of those architectures lacked much in the way of users and support at the time they were demoted. Anyway, thanks for your comment. It is helpful. 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
[PkgDB] limb:perl-Monitoring-Plugin watchcommits set to Approved
user: limb set for jpo acl: watchcommits of package: perl-Monitoring-Plugin from: to: Approved on branch: epel7 To make changes to this package see: https://admin.fedoraproject.org/pkgdb/package/perl-Monitoring-Plugin -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[PkgDB] limb updated perl-Monitoring-Plugin
user: limb created branch el6 on package perl-Monitoring-Plugin To make changes to this package see: https://admin.fedoraproject.org/pkgdb/package/perl-Monitoring-Plugin -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[PkgDB] limb:perl-Monitoring-Plugin approveacls set to Approved
user: limb set for jpo acl: approveacls of package: perl-Monitoring-Plugin from: to: Approved on branch: el6 To make changes to this package see: https://admin.fedoraproject.org/pkgdb/package/perl-Monitoring-Plugin -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[PkgDB] limb:perl-Monitoring-Plugin commit set to Approved
user: limb set for jpo acl: commit of package: perl-Monitoring-Plugin from: to: Approved on branch: el6 To make changes to this package see: https://admin.fedoraproject.org/pkgdb/package/perl-Monitoring-Plugin -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[PkgDB] limb:perl-Monitoring-Plugin watchcommits set to Approved
user: limb set for jpo acl: watchcommits of package: perl-Monitoring-Plugin from: to: Approved on branch: el6 To make changes to this package see: https://admin.fedoraproject.org/pkgdb/package/perl-Monitoring-Plugin -- 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: i686 kernel bug priority plan
i686 Kernel SIG steps up and agrees to handle bugs on that platform Interesting so you are saying that the kernel sub community is effectively only x86_64 If you are going down that road you better ask for every arch kernel SIG to emerge or step up in the process. Where does ARM fit in this plan The ARM SIG has always been primary on the ARM kernel and associated issues. 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
[PkgDB] limb:perl-Monitoring-Plugin commit set to Approved
user: limb set for jpo acl: commit of package: perl-Monitoring-Plugin from: to: Approved on branch: epel7 To make changes to this package see: https://admin.fedoraproject.org/pkgdb/package/perl-Monitoring-Plugin -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[PkgDB] limb:perl-Monitoring-Plugin approveacls set to Approved
user: limb set for jpo acl: approveacls of package: perl-Monitoring-Plugin from: to: Approved on branch: epel7 To make changes to this package see: https://admin.fedoraproject.org/pkgdb/package/perl-Monitoring-Plugin -- 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: New Upstream Release Monitoring Systems
On Wed, Feb 25, 2015 at 03:08:40PM +0100, Vít Ondruch wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dne 24.2.2015 v 14:25 Pierre-Yves Chibon napsal(a): https://release-monitoring.org/projects/updates/failed Weird pagination When you filter? Yes I found this out and it's fixed in git Pierre -- 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: i686 kernel bug priority plan
On 02/25/2015 02:15 PM, Peter Robinson wrote: On Wed, Feb 25, 2015 at 2:14 PM, Peter Robinson pbrobin...@gmail.com wrote: i686 Kernel SIG steps up and agrees to handle bugs on that platform Interesting so you are saying that the kernel sub community is effectively only x86_64 If you are going down that road you better ask for every arch kernel SIG to emerge or step up in the process. Where does ARM fit in this plan The ARM SIG has always been primary on the ARM kernel and associated issues. For that matter so have aarch64/ppc64/s390 SIGs Should not the kernel list be renamed to x86_64 to be in-line with and follow the tradition of the other architectures mailinglist setup? JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[PkgDB] jplesnik:perl-Monitoring-Plugin watchbugzilla set to Obsolete
user: jplesnik set for jplesnik acl: watchbugzilla of package: perl-Monitoring-Plugin from: Approved to: Obsolete on branch: master To make changes to this package see: https://admin.fedoraproject.org/pkgdb/package/perl-Monitoring-Plugin -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[PkgDB] jplesnik:perl-Monitoring-Plugin watchbugzilla set to Obsolete
user: jplesnik set for jplesnik acl: watchbugzilla of package: perl-Monitoring-Plugin from: to: Obsolete on branch: epel7 To make changes to this package see: https://admin.fedoraproject.org/pkgdb/package/perl-Monitoring-Plugin -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[PkgDB] jplesnik:perl-Monitoring-Plugin watchbugzilla set to Obsolete
user: jplesnik set for jplesnik acl: watchbugzilla of package: perl-Monitoring-Plugin from: Approved to: Obsolete on branch: f22 To make changes to this package see: https://admin.fedoraproject.org/pkgdb/package/perl-Monitoring-Plugin -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[PkgDB] jplesnik:perl-Monitoring-Plugin watchcommits set to Obsolete
user: jplesnik set for jplesnik acl: watchcommits of package: perl-Monitoring-Plugin from: Approved to: Obsolete on branch: master To make changes to this package see: https://admin.fedoraproject.org/pkgdb/package/perl-Monitoring-Plugin -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[PkgDB] jplesnik:perl-Monitoring-Plugin watchbugzilla set to Obsolete
user: jplesnik set for jplesnik acl: watchbugzilla of package: perl-Monitoring-Plugin from: to: Obsolete on branch: el6 To make changes to this package see: https://admin.fedoraproject.org/pkgdb/package/perl-Monitoring-Plugin -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[PkgDB] jplesnik:perl-Monitoring-Plugin watchcommits set to Obsolete
user: jplesnik set for jplesnik acl: watchcommits of package: perl-Monitoring-Plugin from: to: Obsolete on branch: epel7 To make changes to this package see: https://admin.fedoraproject.org/pkgdb/package/perl-Monitoring-Plugin -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[PkgDB] jplesnik:perl-Monitoring-Plugin watchcommits set to Obsolete
user: jplesnik set for jplesnik acl: watchcommits of package: perl-Monitoring-Plugin from: Approved to: Obsolete on branch: f22 To make changes to this package see: https://admin.fedoraproject.org/pkgdb/package/perl-Monitoring-Plugin -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File UNIVERSAL-require-0.18.tar.gz uploaded to lookaside cache by pghmcfc
A file has been added to the lookaside cache for perl-UNIVERSAL-require: 2cdfd54bc7e270c77456a8e929a091b3 UNIVERSAL-require-0.18.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: i686 kernel bug priority plan
On Wed, Feb 25, 2015 at 2:15 PM, Josh Boyer jwbo...@fedoraproject.org wrote: Hello Fellow Contributors! [...] It's possible down the road that, if there is no community interest in i686, the project might look at other options such as making i686 a secondary architecture. This is not because we want to drive away 32-bit users; but we're passionate about making the Fedora kernel work well for the majority of our user base. This prioritization helps us get closer to that goal. Just to make this clear because this has suggestion has been brought up multiple times ... while there might be less interests in running a i686 kernel the story is very different for i686 user space (mostly libraries but also applications like wine) even on a x86_64 host kernel. So don't draw a line from no interests in i686 kernel to no interesst in the i686 architecture and therefore it should be secondary .. its not as simple as with a completely isolated architecture like ppc. -- 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 1192382] perl-Test-Inter-1.06 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1192382 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Fixed In Version|perl-Test-Inter-1.06-1.fc20 |perl-Test-Inter-1.06-1.fc21 --- Comment #6 from Fedora Update System upda...@fedoraproject.org --- perl-Test-Inter-1.06-1.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=Ws1qd5eFuWa=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 1192382] perl-Test-Inter-1.06 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1192382 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version|perl-Test-Inter-1.06-1.fc23 |perl-Test-Inter-1.06-1.fc20 Resolution|--- |ERRATA Last Closed||2015-02-25 08:30:59 --- Comment #5 from Fedora Update System upda...@fedoraproject.org --- perl-Test-Inter-1.06-1.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=lQ9ft4vV6Ja=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: arcanist broken with latest update
I've also seen another (probably related) TB in arcanist when trying to run 'arc patch' but haven't gotten far enough into that to figure out exactly what's going on. $ arc diff develop You have not specified any reviewers. Continue anyway? [y/N] y Linting... No lint engine configured for this project. Running unit tests... No unit test engine is configured for this project. Exception ERR-CONDUIT-CORE: Failed to load class or interface 'JsonLintJsonParser': the class or interface 'JsonLintJsonParser' is not defined in the library map for any loaded phutil library. If this symbol was recently added or moved, your library map may be out of date. You can rebuild the map by running 'arc liberate'. For more information, see: http://www.phabricator.com/docs/phabricator/article/libphutil_Libraries_User_Guide.html (Run with `--trace` for a full exception trace.) Seems to be affecting everyone. However, you can use arc diff develop --preview and then fill the remaining fields in the review request manually. A bit more work, but works. You can also use this to update an existing review request. So there is a workaround. Actually, it seems that the exception shown above is not fatal, and all the patches I tried to submit for review *were* actually submitted! So, you might not need to use --preview, just use `arc diff` as usual, and then look into Phabricator or into `arc list` and make sure it got created properly. ___ qa-devel mailing list qa-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/qa-devel
Re: Why sysrq is limited to only sync command on official fedora kernel?
Why sysrq is limited to only sync command on official fedora kernel? The kernel itself isn't limited. It's just set that way in /usr/lib/sysctl.d/50-default.conf which is provided by systemd. You can edit that file, create your own in /etc/sysctrl.d/, or (as root) set it to whatever you would like via /proc/sys/kernel/sysrq. Of course it can be changed at runtime, but I mean why official fedora kernel shouldn't be configured to allow all (or at least a wider subset) of sysrq commands by default? This way official fedora live CDs are unsuitable for system recovery tasks; you have to change sysrq value every time you use live CDs or build your own live CD. Regards, Ali -- 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-UNIVERSAL-require] Created tag perl-UNIVERSAL-require-0.18-1.fc22
The lightweight tag 'perl-UNIVERSAL-require-0.18-1.fc22' was created pointing to: c157510... Update to 0.18 -- 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: i686 kernel bug priority plan
On Wed, 2015-02-25 at 08:15 -0500, Josh Boyer wrote: snip This is an opportunity for community members for whom i686 is a passion to join the team to participate in the bugfixing required. We previously called out the need for assistance[2], but had no substantial response. We hope that being transparent about our priorities will prompt interested community members to help. If you are interested to help, here are some resources to get started: snip Given our past history with passive requests for help, I think it might be beneficial to put a time limit on things. For example, if no i686 Kernel SIG steps up and agrees to handle bugs on that platform, we should strongly consider demoting i686 to secondary architecture for installation media at the Fedora 23 branch point (about six months from now). Note: I'm only suggesting that we would demote the kernel and install media, *NOT* the 32-bit runtime libraries on an x86_64 system; we would still need to be building those. signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New Upstream Release Monitoring Systems
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dne 24.2.2015 v 14:25 Pierre-Yves Chibon napsal(a): https://release-monitoring.org/projects/updates/failed Weird pagination Vít -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJU7ddnAAoJEAzgnueZF7h8BGYP/jCRcMcGX2jDnd0tegwer9I8 PxGrSH2+Gis5aSOoa9qhgxJU8JkcepT/koMnySiNRry7XD+kO4x8BtmihVdmwNJd IG/UjTZi5l2Thf43f2Uf+fOhR40RwXa9UPhUf0o0xRfDqdndXWQrbCMq8xOoOreG VvXDpQHu5+LigiOaMkxtypLDNp/iOFxdzD5/VGvRWMB6D8r9xWf+LFpLfCNSUgEG py7G4wb1wF0rr5UF1//X4FLE9YFpOEXQe75lUE6cPZzPAfblHcBwAuUEDFf5Hesw ure+Px3aNu+5vdK0SFsTJA2tstvknMS05NwIYoU7iJL8P7jrCBox9Qx4TgDfCRLw XPxejkFkqhkdvLZDfTVSwtjJRZGt9sLgyFTIBBfsHW1gXcFpViB3+EthG/RW/yge q/10wyImglz1oXfXU/c7Q2QTZCJl6CcS37M+o9giESY3gQBLgDEvE5TxTVHe2hd+ iSl9YcQrzn/nHZ7LzNuxVbPS1N1OdkmJgRz0MUhAVHAIX5hEHPHvpUMMJ5aFoFha n5LRSQ/ZWcoJeTnZThyKFDns5q/gumc9sTTdQbNEX5kwEgbiMz9JU5xSK6N4zotl I/83ZGnsfPHCu6fgnd/VP/7+vBymMM1CVblmRuPTMuHizuFwnbCEmsnrLyp11gB8 2zMSIgvJLTa/RFOYViLp =vCIZ -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[PkgDB] jplesnik:perl-Monitoring-Plugin watchcommits set to Obsolete
user: jplesnik set for jplesnik acl: watchcommits of package: perl-Monitoring-Plugin from: to: Obsolete on branch: el6 To make changes to this package see: https://admin.fedoraproject.org/pkgdb/package/perl-Monitoring-Plugin -- 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
arcanist broken with latest update
I've also seen another (probably related) TB in arcanist when trying to run 'arc patch' but haven't gotten far enough into that to figure out exactly what's going on. $ arc diff develop You have not specified any reviewers. Continue anyway? [y/N] y Linting... No lint engine configured for this project. Running unit tests... No unit test engine is configured for this project. Exception ERR-CONDUIT-CORE: Failed to load class or interface 'JsonLintJsonParser': the class or interface 'JsonLintJsonParser' is not defined in the library map for any loaded phutil library. If this symbol was recently added or moved, your library map may be out of date. You can rebuild the map by running 'arc liberate'. For more information, see: http://www.phabricator.com/docs/phabricator/article/libphutil_Libraries_User_Guide.html (Run with `--trace` for a full exception trace.) Seems to be affecting everyone. However, you can use arc diff develop --preview and then fill the remaining fields in the review request manually. A bit more work, but works. You can also use this to update an existing review request. So there is a workaround. ___ qa-devel mailing list qa-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/qa-devel
repo-mirrorlist quality control?
Hi, when doing yum update in the last few weeks I am seeing thousands of errors like (1/2): _local/primary_db| 3.4 MB 00:00 updates/21/i386/primary_db FAILED http://mirror.netcologne.de/fedora/linux/updates/21/i386/repodata/1f20884a6cce1ba8e28bb19e6dd364fe787906c1f0504c0d06e0fb1be8ab07ac-primary.sqlite.bz2: [Errno 14] HTTP Error 404 - Not Found Trying other mirror. updates/21/i386/primary_db FAILED http://mirror.fraunhofer.de/dl.fedoraproject.org/fedora/linux/updates/21/i386/repodata/1f20884a6cce1ba8e28bb19e6dd364fe787906c1f0504c0d06e0fb1be8ab07ac-primary.sqlite.bz2: [Errno 14] curl#18 - transfer closed with 1521891 bytes remaining to read Trying other mirror. (2/2): updates/21/i386/primary_db | 4.5 MB 03:26 updates/21/i386/updateinfo FAILED http://mirror.netcologne.de/fedora/linux/updates/21/i386/repodata/343502d43eec1d45e0f951d2c2d3373a146515d175e61c1609b44391f93cf08a-updateinfo.xml.gz: [Errno 14] HTTP Error 404 - Not Found Trying other mirror. updates/21/i386/pkgtagsFAILED http://mirror.netcologne.de/fedora/linux/updates/21/i386/repodata/6803dec7b564b291cead9d2b720a47bb73da52577e7f25e5b9df41582455f7a1-pkgtags.sqlite.gz: [Errno 14] HTTP Error 404 - Not Found Trying other mirror. (1/2): updates/21/i386/updateinfo | 644 kB 01:28 (2/2): updates/21/i386/pkgtags | 1.4 MB 03:11 and http://mirror.netcologne.de/fedora/linux/updates/21/i386/drpms/autocorr-en-4.3.5.2-11.fc21_4.3.6.2-3.fc21.noarch.drpm: [Errno 14] HTTP Error 404 - Not Found Trying other mirror. While very rarely some other mirrors have problems, netcologne seems to be failing systematically for me. Is it just me? Is there some place to report? Richard --- Name and OpenPGP keys available from pgp key servers -- 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 1196195] New: perl-Pod-Spell-1.16 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1196195 Bug ID: 1196195 Summary: perl-Pod-Spell-1.16 is available Product: Fedora Version: rawhide Component: perl-Pod-Spell Keywords: FutureFeature, Triaged Assignee: jples...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: jples...@redhat.com, mmasl...@redhat.com, perl-devel@lists.fedoraproject.org Latest upstream release: 1.16 Current version/release in rawhide: 1.15-3.fc22 URL: http://search.cpan.org/dist/Pod-Spell/ 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 -- 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=TpgBibKoXta=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 1163219] perl-DateTime-TimeZone-Tzfile-0.010 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1163219 --- Comment #2 from Fedora Update System upda...@fedoraproject.org --- perl-DateTime-TimeZone-Tzfile-0.010-1.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=pSBW5sxM2aa=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: i686 kernel bug priority plan
On Wed, Feb 25, 2015 at 2:14 PM, Peter Robinson pbrobin...@gmail.com wrote: i686 Kernel SIG steps up and agrees to handle bugs on that platform Interesting so you are saying that the kernel sub community is effectively only x86_64 If you are going down that road you better ask for every arch kernel SIG to emerge or step up in the process. Where does ARM fit in this plan The ARM SIG has always been primary on the ARM kernel and associated issues. For that matter so have aarch64/ppc64/s390 SIGs 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: Why sysrq is limited to only sync command on official fedora kernel?
On 02/25/2015 03:04 PM, Josh Boyer wrote: On Wed, Feb 25, 2015 at 8:54 AM, Ali AlipourR alipoo...@gmail.com wrote: Hi, Why sysrq is limited to only sync command on official fedora kernel? The kernel itself isn't limited. It's just set that way in /usr/lib/sysctl.d/50-default.conf which is provided by systemd. You can edit that file, The file in /usr will be overwritten by the next package update. create your own in /etc/sysctl.d/, Yes, local configuration belongs to /etc. See also man sysctl.d. or (as root) set it to whatever you would like via /proc/sys/kernel/sysrq. Or pass sysrq_always_enabled on the kernel command line. sysrq_always_enabled [KNL] Ignore sysrq setting - this boot parameter will neutralize any effect of /proc/sys/kernel/sysrq. Useful for debugging. 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
[perl-UNIVERSAL-require] Created tag perl-UNIVERSAL-require-0.18-1.fc23
The lightweight tag 'perl-UNIVERSAL-require-0.18-1.fc23' was created pointing to: c157510... Update to 0.18 -- 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
koji OpenSSL.SSL.SysCallError: (-1, 'Unexpected EOF')
hi on my F20 system happen this problem any ideas? regards gil koji -d build rawhide --scratch ~/rpmbuild/SRPMS/google-http-java-client-1.19.0-1.fc20.src.rpm successfully connected to hub Uploading srpm: ~/rpmbuild/SRPMS/google-http-java-client-1.19.0-1.fc20.src.rpm 2015-02-25 16:18:58,752 [DEBUG] koji: Fast upload: /home/gil/rpmbuild/SRPMS/google-http-java-client-1.19.0-1.fc20.src.rpm to cli-build/1424877538.234305.uPdSYJZW/google-http-java-client-1.19.0-1.fc20.src.rpm 2015-02-25 16:19:11,472 [DEBUG] koji: Fast upload: ~/rpmbuild/SRPMS/google-http-java-client-1.19.0-1.fc20.src.rpm complete. 356914 bytes in 12.2 seconds Created task: 9070889 Task info: http://koji.fedoraproject.org/koji/taskinfo?taskID=9070889 Watching tasks (this may be safely interrupted)... 9070889 build (rawhide, google-http-java-client-1.19.0-1.fc20.src.rpm): open (buildvm-21.phx2.fedoraproject.org) 9070890 buildArch (google-http-java-client-1.19.0-1.fc20.src.rpm, noarch): open (arm02-builder22.arm.fedoraproject.org) Traceback (most recent call last): File /usr/bin/koji, line 6245, in module rv = locals()[command].__call__(options, session, args) File /usr/bin/koji, line 972, in handle_build return watch_tasks(session, [task_id], quiet=build_opts.quiet) File /usr/bin/koji, line 479, in watch_tasks changed = task.update() File /usr/bin/koji, line 384, in update self.info = self.session.getTaskInfo(self.id, request=True) File /usr/lib/python2.7/site-packages/koji/__init__.py, line 1555, in __call__ return self.__func(self.__name,args,opts) File /usr/lib/python2.7/site-packages/koji/__init__.py, line 1898, in _callMethod return self._sendCall(handler, headers, request) File /usr/lib/python2.7/site-packages/koji/__init__.py, line 1809, in _sendCall return self._sendOneCall(handler, headers, request) File /usr/lib/python2.7/site-packages/koji/__init__.py, line 1829, in _sendOneCall response = cnx.getresponse() File /usr/lib/python2.7/httplib.py, line 1045, in getresponse response.begin() File /usr/lib/python2.7/httplib.py, line 409, in begin version, status, reason = self._read_status() File /usr/lib/python2.7/httplib.py, line 365, in _read_status line = self.fp.readline(_MAXLINE + 1) File /usr/lib/python2.7/socket.py, line 476, in readline data = self._sock.recv(self._rbufsize) File /usr/lib/python2.7/site-packages/koji/ssl/SSLConnection.py, line 140, in recv return con.recv(bufsize, flags) OpenSSL.SSL.SysCallError: (-1, 'Unexpected EOF') -- 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: i686 kernel bug priority plan
On Wed, 2015-02-25 at 14:01 +, Peter Robinson wrote: This is an opportunity for community members for whom i686 is a passion to join the team to participate in the bugfixing required. We previously called out the need for assistance[2], but had no substantial response. We hope that being transparent about our priorities will prompt interested community members to help. If you are interested to help, here are some resources to get started: snip Given our past history with passive requests for help, I think it might be beneficial to put a time limit on things. For example, if no i686 Kernel SIG steps up and agrees to handle bugs on that platform, we should strongly consider demoting i686 to secondary architecture for installation media at the Fedora 23 branch point (about six months from now). Note: I'm only suggesting that we would demote the kernel and install media, *NOT* the 32-bit runtime libraries on an x86_64 system; we would still need to be building those. How do you propose demoting to secondary only the kernel/install without the userspace? Do you mean de-emphasise the i686 bit platform? Well, that was more a political and rel-eng statement than a technical one. Effectively, we'd not build the kernel package or do release- blocking composes of i686 media. However, the Koji build-system would still have to be capable of producing i686 builds as a primary architecture. So yes, from a purely technical standpoint, it's a muddy statement. signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: I wrote small script to list FTBFS koji entries
On 12.02.2015 20:51, Marcin Juszkiewicz wrote: Hi As my work usually is around fixing packages which failed to build on AArch64 I spend lot of time with Koji. Today I started writing script which has to list all current FTBFS entries from selected Koji instance - kind like [1] does but with few extras: - no packages which got built later - no repeated entries I plan to make something like Ubuntu has [2] which was great help when I was working on fixing packages while working for Canonical. No idea how far I will go with it but something like generator for such page is on my to do list. https://fedorapeople.org/~hrw/ftbfs.html is what I got. Still rough and require polishing but shows what I wanted to get. Current version of script is on [3]. My Python skills maybe are not the greatest ones but script works for me. Patches, ideas, bugs are welcome. 1. http://arm.koji.fedoraproject.org/koji/builds?state=3order=-build_id 2. http://qa.ubuntuwire.com/ftbfs/ 3. https://github.com/hrw/fedora-koji-scripts -- 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: Taking ownership of html2text on EPEL6
On 01/09/2015 02:41 PM, Troy Dawson wrote: Hi, I will be taking ownership of html2text on EPEL6. I am already the maintainer for EPEL7, but I missed the notification that the EPEL6 version was being orphaned because of filters. Troy Dawson Hi All, This has turned out to be much more painful than the documentation [1] would have you believe. Anyway, I've eventually managed to become the maintainer for EPEL6, but my problem now is that it's blocked. I cannot build the package. Can someone unblock html2text on epel6 and/or point me to the documentation that says how to unblock a package. Thank You Troy p.s. If someone wants to talk with me about updating the documentation, I can talk to you about the pain points. But I didn't want that to be the focus of this email. [1] http://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers#Claiming_Ownership_of_an_Orphaned_Package_Procedure -- 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: repo-mirrorlist quality control?
Am 25.02.2015 um 16:10 schrieb Kevin Fenzi: If so, then you have cached metadata thats older than a few days. If not, then it's indeed those mirrors that are out of sync mirrors are regulary out of sync you can see that even with /var/cache/yum as tempfs often signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Why sysrq is limited to only sync command on official fedora kernel?
On 02/25/2015 03:43 PM, Josh Boyer wrote: On Wed, Feb 25, 2015 at 9:35 AM, Ali AlipourR alipoo...@gmail.com wrote: Why sysrq is limited to only sync command on official fedora kernel? The kernel itself isn't limited. It's just set that way in /usr/lib/sysctl.d/50-default.conf which is provided by systemd. You can edit that file, create your own in /etc/sysctrl.d/, or (as root) set it to whatever you would like via /proc/sys/kernel/sysrq. Of course it can be changed at runtime, but I mean why official fedora kernel shouldn't be configured to allow all (or at least a wider subset) of sysrq commands by default? Maybe we're getting hung up on a terminology issue, but this isn't a kernel configuration issue. It's something userspace is doing. This way official fedora live CDs are unsuitable for system recovery tasks; you have to change sysrq value every time you use live CDs or build your own live CD. That's a good point. Since the live images have a rescue mode, maybe there is a way to use a different value when booted into that. How that would look, I'm not sure. Maybe dracut would need to include an override file in the initramfs. I don't follow the reasoning. Why am I more likely to need SysRq in rescue mode than in normal boot? 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
Re: Why sysrq is limited to only sync command on official fedora kernel?
it is nothing someone is using regulary and that settings are security settings recommended by most auditing tools security part is admit able, but still I think it is too much strict, e.g. what is security problem of having 'r' request enabled? (specially considering that fedora uses relatively unstable gnome-shell) Regards, Ali -- 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: repo-mirrorlist quality control?
On Wed, 25 Feb 2015 16:29:14 +0100 Ralf Corsepius rc040...@freenet.de wrote: If so, then you have cached metadata thats older than a few days. No. If not, then it's indeed those mirrors that are out of sync. These mirrors are out of sync. Whether you like it or not, mirrormanager is dysfunctional. That is not very helpfull. The problem is that managing mirrors is not a simple problem, it's a very complex one. You have to see when repos change on the master side, you have to reply to lots and lots and lots of requests from users for that data. You have to try and check mirrors to see they are up to date, but you can't check every single file on every single mirror, so you check what you can and hope it matches up. You also cannot check every mirror all the time, you have to stagger things. You also cannot run any code on any mirror beyond simple scripts that mirrors choose to run or not. Also some mirrors are up to date on some content and not others, so you have to adjust for that (ie, some don't carry isos or debuginfo, but otherwise all other packages). If you have a simple solution to this problem, I look forward to your proof of concept. It is a provable matter of fact that it points users (yum, mock, ...) to broken and out of sync mirrors. There will be such times, sure. I don't see any way of eliminating that. We can reduce it as much as we can with the resources we have. There are some things we can do: * If there's a mirror that is reporting that it's up to date, but is not, we can remove it from the list and ask mirror admins to check it. * In mirrorlists and metalinks we provide a list of mirrors. If some are out of sync, yum/dnf should move on to the next and retry. It sounds like you might see some cases where your metadata is updated locally and all mirrors fail? Please report such bugs. https://fedorahosted.org/mirrormanager/ * We can try and urge more mirrors to sync based on fedmsg (using last-sync) instead of just randomly N times a day. They would then reduce load on master mirrors and get content faster: https://fedoraproject.org/wiki/Infrastructure/Mirroring#Mirror_Frequency * We can finish deploying our mirrormanager2 re-write. It doesn't add many/any new features, but it moves mirrormanager to a codebase we can work on more easily and bugfix/add features to. https://github.com/fedora-infra/mirrormanager2 Constructive bugs, ideas or patches welcome. kevin pgpFnNGccG1Dq.pgp Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Bug 1196195] perl-Pod-Spell-1.16 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1196195 --- Comment #2 from Upstream Release Monitoring upstream-release-monitor...@fedoraproject.org --- jplesnik's perl-Pod-Spell-1.16-1.fc23 completed http://koji.fedoraproject.org/koji/buildinfo?buildID=615049 -- 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=mE1kSQKAqSa=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: Why sysrq is limited to only sync command on official fedora kernel?
On Wed, Feb 25, 2015 at 9:53 AM, Michal Schmidt mschm...@redhat.com wrote: On 02/25/2015 03:43 PM, Josh Boyer wrote: On Wed, Feb 25, 2015 at 9:35 AM, Ali AlipourR alipoo...@gmail.com wrote: Why sysrq is limited to only sync command on official fedora kernel? The kernel itself isn't limited. It's just set that way in /usr/lib/sysctl.d/50-default.conf which is provided by systemd. You can edit that file, create your own in /etc/sysctrl.d/, or (as root) set it to whatever you would like via /proc/sys/kernel/sysrq. Of course it can be changed at runtime, but I mean why official fedora kernel shouldn't be configured to allow all (or at least a wider subset) of sysrq commands by default? Maybe we're getting hung up on a terminology issue, but this isn't a kernel configuration issue. It's something userspace is doing. This way official fedora live CDs are unsuitable for system recovery tasks; you have to change sysrq value every time you use live CDs or build your own live CD. That's a good point. Since the live images have a rescue mode, maybe there is a way to use a different value when booted into that. How that would look, I'm not sure. Maybe dracut would need to include an override file in the initramfs. I don't follow the reasoning. Why am I more likely to need SysRq in rescue mode than in normal boot? Rescue mode quite often translates to debug mode as well. Things hang, you need to know why, etc. SysRq isn't always required, but it is another tool in the box. 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
[perl-Pod-Spell/f22] 1.16 bump
commit de569bd4c211e8f63ac57bb8b44663e8d237add5
Author: Jitka Plesnikova jples...@redhat.com
Date: Wed Feb 25 16:46:18 2015 +0100
1.16 bump
.gitignore | 1 +
perl-Pod-Spell.spec | 14 +++---
sources | 2 +-
3 files changed, 9 insertions(+), 8 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 17d313b..c24521c 100644
--- a/.gitignore
+++ b/.gitignore
@@ -10,3 +10,4 @@ Pod-Spell-1.01.tar.gz
/Pod-Spell-1.13.tar.gz
/Pod-Spell-1.14.tar.gz
/Pod-Spell-1.15.tar.gz
+/Pod-Spell-1.16.tar.gz
diff --git a/perl-Pod-Spell.spec b/perl-Pod-Spell.spec
index 2c96fed..9014f23 100644
--- a/perl-Pod-Spell.spec
+++ b/perl-Pod-Spell.spec
@@ -1,6 +1,6 @@
Name: perl-Pod-Spell
-Version:1.15
-Release:3%{?dist}
+Version:1.16
+Release:1%{?dist}
Summary:A formatter for spell-checking POD
Group: Development/Libraries
License:Artistic 2.0
@@ -24,17 +24,13 @@ BuildRequires: perl(Pod::Escapes)
BuildRequires: perl(Pod::Parser)
BuildRequires: perl(Text::Wrap)
# Tests:
-BuildRequires: perl(English)
BuildRequires: perl(File::Spec)
-BuildRequires: perl(File::Spec::Functions)
BuildRequires: perl(File::Temp)
BuildRequires: perl(IO::Handle)
BuildRequires: perl(IPC::Open3)
-BuildRequires: perl(List::Util)
BuildRequires: perl(Test::Deep)
BuildRequires: perl(Test::More) = 0.88
BuildRequires: perl(utf8)
-BuildRequires: perl(version)
Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
%description
@@ -61,7 +57,8 @@ chmod -R u+w %{buildroot}/*
make test
%files
-%doc Changes CONTRIBUTING LICENSE README
+%license LICENSE
+%doc Changes CONTRIBUTING README
%{_bindir}/podspell
%{perl_vendorlib}/Pod/
%{perl_vendorlib}/auto/share/dist/Pod-Spell/
@@ -69,6 +66,9 @@ make test
%{_mandir}/man3/*.3pm*
%changelog
+* Wed Feb 25 2015 Jitka Plesnikova jples...@redhat.com - 1.16-1
+- 1.16 bump
+
* Fri Aug 29 2014 Jitka Plesnikova jples...@redhat.com - 1.15-3
- Perl 5.20 rebuild
diff --git a/sources b/sources
index e369bdb..8824b66 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-fce6fe5ae7ae8ebf140ddbbec36e4f8c Pod-Spell-1.15.tar.gz
+3a58091842ca89dbe7e72887700d7a68 Pod-Spell-1.16.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Pod-Spell] 1.16 bump
commit 43375dc4da60fdfdaeb435049dfb66baf4846fc6
Author: Jitka Plesnikova jples...@redhat.com
Date: Wed Feb 25 16:46:18 2015 +0100
1.16 bump
.gitignore | 1 +
perl-Pod-Spell.spec | 14 +++---
sources | 2 +-
3 files changed, 9 insertions(+), 8 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 17d313b..c24521c 100644
--- a/.gitignore
+++ b/.gitignore
@@ -10,3 +10,4 @@ Pod-Spell-1.01.tar.gz
/Pod-Spell-1.13.tar.gz
/Pod-Spell-1.14.tar.gz
/Pod-Spell-1.15.tar.gz
+/Pod-Spell-1.16.tar.gz
diff --git a/perl-Pod-Spell.spec b/perl-Pod-Spell.spec
index 2c96fed..9014f23 100644
--- a/perl-Pod-Spell.spec
+++ b/perl-Pod-Spell.spec
@@ -1,6 +1,6 @@
Name: perl-Pod-Spell
-Version:1.15
-Release:3%{?dist}
+Version:1.16
+Release:1%{?dist}
Summary:A formatter for spell-checking POD
Group: Development/Libraries
License:Artistic 2.0
@@ -24,17 +24,13 @@ BuildRequires: perl(Pod::Escapes)
BuildRequires: perl(Pod::Parser)
BuildRequires: perl(Text::Wrap)
# Tests:
-BuildRequires: perl(English)
BuildRequires: perl(File::Spec)
-BuildRequires: perl(File::Spec::Functions)
BuildRequires: perl(File::Temp)
BuildRequires: perl(IO::Handle)
BuildRequires: perl(IPC::Open3)
-BuildRequires: perl(List::Util)
BuildRequires: perl(Test::Deep)
BuildRequires: perl(Test::More) = 0.88
BuildRequires: perl(utf8)
-BuildRequires: perl(version)
Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
%description
@@ -61,7 +57,8 @@ chmod -R u+w %{buildroot}/*
make test
%files
-%doc Changes CONTRIBUTING LICENSE README
+%license LICENSE
+%doc Changes CONTRIBUTING README
%{_bindir}/podspell
%{perl_vendorlib}/Pod/
%{perl_vendorlib}/auto/share/dist/Pod-Spell/
@@ -69,6 +66,9 @@ make test
%{_mandir}/man3/*.3pm*
%changelog
+* Wed Feb 25 2015 Jitka Plesnikova jples...@redhat.com - 1.16-1
+- 1.16 bump
+
* Fri Aug 29 2014 Jitka Plesnikova jples...@redhat.com - 1.15-3
- Perl 5.20 rebuild
diff --git a/sources b/sources
index e369bdb..8824b66 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-fce6fe5ae7ae8ebf140ddbbec36e4f8c Pod-Spell-1.15.tar.gz
+3a58091842ca89dbe7e72887700d7a68 Pod-Spell-1.16.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: repo-mirrorlist quality control?
On Wed, 25 Feb 2015 13:49:47 +0100 Richard Z r...@linux-m68k.org wrote: Hi, when doing yum update in the last few weeks I am seeing thousands of errors like ...snip... and http://mirror.netcologne.de/fedora/linux/updates/21/i386/drpms/autocorr-en-4.3.5.2-11.fc21_4.3.6.2-3.fc21.noarch.drpm: [Errno 14] HTTP Error 404 - Not Found Trying other mirror. Does a: 'yum clean all' then retrying help/solve it? If so, then you have cached metadata thats older than a few days. If not, then it's indeed those mirrors that are out of sync. While very rarely some other mirrors have problems, netcologne seems to be failing systematically for me. Is it just me? Is there some place to report? You can report it to the mirror-admin list ( https://admin.fedoraproject.org/mailman/listinfo/mirror-admin) Or bring it up to infrastructure folks and we can try and contact the mirror admins directly for that mirror. Perhaps one thing we should revsit is dnf/yum metadata caching times on the various repos to align with how often we push updates. kevin pgp7mbHJh3GzS.pgp Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: repo-mirrorlist quality control?
On 02/25/2015 04:10 PM, Kevin Fenzi wrote: On Wed, 25 Feb 2015 13:49:47 +0100 Richard Z r...@linux-m68k.org wrote: Hi, when doing yum update in the last few weeks I am seeing thousands of errors like ...snip... and http://mirror.netcologne.de/fedora/linux/updates/21/i386/drpms/autocorr-en-4.3.5.2-11.fc21_4.3.6.2-3.fc21.noarch.drpm: [Errno 14] HTTP Error 404 - Not Found Trying other mirror. Does a: 'yum clean all' then retrying help/solve it? If so, then you have cached metadata thats older than a few days. No. If not, then it's indeed those mirrors that are out of sync. These mirrors are out of sync. Whether you like it or not, mirrormanager is dysfunctional. It is a provable matter of fact that it points users (yum, mock, ...) to broken and out of sync mirrors. 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
Re: koji OpenSSL.SSL.SysCallError: (-1, 'Unexpected EOF')
Il 25/02/2015 16:32, Kevin Fenzi ha scritto: See: https://lists.fedoraproject.org/pipermail/devel/2015-January/207036.html kevin thanks! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: koji OpenSSL.SSL.SysCallError: (-1, 'Unexpected EOF')
See: https://lists.fedoraproject.org/pipermail/devel/2015-January/207036.html kevin pgpvhRy6yWFJN.pgp Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
File Pod-Spell-1.16.tar.gz uploaded to lookaside cache by jplesnik
A file has been added to the lookaside cache for perl-Pod-Spell: 3a58091842ca89dbe7e72887700d7a68 Pod-Spell-1.16.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: gcc 5 C++ string issue
Orion Poplawski or...@cora.nwra.com writes:
On 02/24/2015 05:22 PM, Kevin Kofler wrote:
Orion Poplawski wrote:
Getting:
/builddir/build/BUILD/mrpt-1.0.2/libs/base/include/mrpt/utils/mrpt_macros.h:296:150:
error: no match for 'operator' (operand types are
'std::basic_ostreamchar' and 'std::ostringstream {aka
std::__cxx11::basic_ostringstreamchar}')
#define ASSERT_NOT_EQUAL_( __A, __B) { if (__A==__B) {
#std::ostringstream
s;sASSERT_NOT_EQUAL_(#__A,#__B) failed with\n#__A=
__A \n#__B=__B; THROW_EXCEPTION(s.str()) } }
Any idea what wrong here?
The following patch fixes the compilation issue:
diff -up mrpt-1.0.2/libs/hwdrivers/src/CImpinjRFID.cpp\~
mrpt-1.0.2/libs/hwdrivers/src/CImpinjRFID.cpp
--- mrpt-1.0.2/libs/hwdrivers/src/CImpinjRFID.cpp~ 2013-01-05
00:23:15.0 +0100
+++ mrpt-1.0.2/libs/hwdrivers/src/CImpinjRFID.cpp 2015-02-25
16:55:48.628178380 +0100
@@ -97,7 +97,7 @@ void CImpinjRFID::startDriver()
const int ret = ::system(cmdline.str().c_str());
if (0!=ret)
- std::cerr [CImpinjRFID::startDriver] Error ( ret )
invoking command:\n cmdline std::endl;
+ std::cerr [CImpinjRFID::startDriver] Error ( ret )
invoking command:\n cmdline.str() std::endl;
system::exitThread(); // JL-Emil: Really needed? If not, just
remove...
}
I don't know why this stopped working, but it never did the intended
thing as written anyway.
With this out of the way, I'm getting a bunch of the following:
../../lib/libmrpt-maps.so.1.0.2: undefined reference to
`pcl::PCDWriter::setLockingPermissions(std::__cxx11::basic_stringchar,
std::char_traitschar, std::allocatorchar const,
boost::interprocess::file_lock)'
So pcl should be rebuilt for new ABI it seems.
Thanks,
Petr
--
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: Hardened builds
Mamoru TASAKA wrote: Hello: I've got a package that is currently failing to build in Rawhide. It has a home-brewed garbage collector inside, and it appears the GC is confused about which objects are on the stack, and which are on the heap. I want to try building without the hardening flags to see if that has something to do with the problem. According to https://fedorahosted.org/fesco/ticket/1384 the way to do this is to put: %global _hardened_build 0 at the top of the spec file. But that doesn't work with a local mock build. I still see -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 in the compiler flags and -specs=/usr/lib/rpm/redhat/redhat-hardened-ld in the linker flags. Does %undefine _hardened_build help? that version works for me -- Rex -- 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: Why sysrq is limited to only sync command on official fedora kernel?
Am 25.02.2015 um 18:47 schrieb Chris Adams: Once upon a time, Reindl Harald h.rei...@thelounge.net said: when you are on a machine where you have pysical only keyboard and mouse it is not - not every PC stands in front of your face - think about kiosk mode and so on... But Fedora out-of-the-box is not secured for that already. An admin needs to do additional configuration to secure for a console does NOT have physical access and console user is NOT admin setup no - but it makes a difference if you need to care abot 20 or 200 things to secure - many even don't know about sysrq and so would never come to the idea secure sysrq too and so have an unknown door wide open the users which know about it can enable it that's the whole purpose of secure defaults signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Taking ownership of html2text on EPEL6
Dne 25.2.2015 v 17:18 Troy Dawson napsal(a): On 01/09/2015 02:41 PM, Troy Dawson wrote: Hi, I will be taking ownership of html2text on EPEL6. I am already the maintainer for EPEL7, but I missed the notification that the EPEL6 version was being orphaned because of filters. Troy Dawson Hi All, This has turned out to be much more painful than the documentation [1] would have you believe. Anyway, I've eventually managed to become the maintainer for EPEL6, but my problem now is that it's blocked. I cannot build the package. Can someone unblock html2text on epel6 and/or point me to the documentation that says how to unblock a package. Thank You Troy p.s. If someone wants to talk with me about updating the documentation, I can talk to you about the pain points. But I didn't want that to be the focus of this email. [1] http://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers#Claiming_Ownership_of_an_Orphaned_Package_Procedure Quoting from [1]: 5. Request that the Release Engineering team http://fedoraproject.org/wiki/ReleaseEngineering unblock the package for the releases that the package should be un-retired for via their trac instance https://fedorahosted.org/rel-eng/newticket. In this request, please post a link to the completed re-review and clearly specify which branches should be unblocked. So you were are on the right path. Vít [1] http://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers#Claiming_Ownership_of_a_Retired_Package -- 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: [Scitech] OpenBabel rebase to pre-2.4 (current Git master)
On Wed, Feb 25, 2015 at 1:14 PM, Dominik 'Rathann' Mierzejewski domi...@greysector.net wrote: Affected packages: IQmol https://bugzilla.redhat.com/show_bug.cgi?id=1196090 avogadro https://bugzilla.redhat.com/show_bug.cgi?id=1196090 Are avogadro and IQmol affected by the same bug, or was this a mistake? -- 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: Why sysrq is limited to only sync command on official fedora kernel?
Once upon a time, Reindl Harald h.rei...@thelounge.net said: when you are on a machine where you have pysical only keyboard and mouse it is not - not every PC stands in front of your face - think about kiosk mode and so on... But Fedora out-of-the-box is not secured for that already. An admin needs to do additional configuration to secure for a console does NOT have physical access and console user is NOT admin setup. -- Chris Adams li...@cmadams.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: repo-mirrorlist quality control?
On 02/25/2015 06:22 PM, Kevin Fenzi wrote: On Wed, 25 Feb 2015 17:47:47 +0100 Ralf Corsepius rc040...@freenet.de wrote: In another (much smaller) project, when pushing updates, we had removed all mirrors from our mirrorlists and had let the server poll repodata/repomd.xml from the mirrors to re-adde a mirror to the mirrorlists if this file matched. Of course, this is a primitive heuristic, but it had worked quite well for us. yeah, sadly we don't have any ability to push to mirrors, they have to pull from us. I sense a misunderstanding. With pushing I was referring to uploading/publishing a package to the repository on the master. The mirrors were polling ad lib, at intervals at their preference. I.e. when updating the master repository on the server, we emptied our mirrorlists, and let the _master_ poll repomd.xmls from the _mirrors_. When it found a mirror's repomd.xml was in sync, the mirrors was re-add to our mirrorlists on the server. The mirrormanager crawler pulls repomd.xml from each mirror when it crawls and compares it. However, as noted we can't poll all mirrors all the time. This sounds pretty much like the same approach we had taken. It is a provable matter of fact that it points users (yum, mock, ...) to broken and out of sync mirrors. There will be such times, sure. Here (Germany), in recent times, they happen almost daily. My guess is the fedora flavors, the launch of f22 and the mass-rebuild on rawhide are showing their nasty side. So, to be clear you see daily where 'yum update' gives you all mirrors erroring out and you cannot get a update list? And 'yum clean all' doesn't help? As I am heavily using mock, I am fairly often seeing this issue with mock. With mock w/ rawhide I am even observing hard build-breakdowns (Seems to me as if something in f21's mock was changed to not let it use mirrors) The next time this happens can you file a ticket with the output? I can try - However, during some periods in recent weeks, these incidents were so frequent, I'd not to anything else but filing tickets ;) 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
Re: New Upstream Release Monitoring Systems
Dne 25.2.2015 v 15:23 Pierre-Yves Chibon napsal(a): On Wed, Feb 25, 2015 at 03:08:40PM +0100, Vít Ondruch wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dne 24.2.2015 v 14:25 Pierre-Yves Chibon napsal(a): https://release-monitoring.org/projects/updates/failed Weird pagination When you filter? I just opened the page and click to go forward, no filtering. Yes I found this out and it's fixed in git Thx. Vít -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Agenda for Env-and-Stacks WG meeting (2015-02-26)
HEADS UP -- new time and place; since we would have a collision in #fedora-meeting and it seems to be better to have meetings on the same channel every week, let's meet at #fedora-meeting-2. WG meeting will be at 13:00 UTC (08:00 EST, 14:00 Brno, 8:00 Boston, 22:00 Tokyo, 23:00 Brisbane) in #fedora-meeting-2 on Freenode. = Topics = * Follow-ups * Dockerfiles recommended tips * Playground repo revisiting * Open Floor -- 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: Why sysrq is limited to only sync command on official fedora kernel?
On Wed, 25.02.15 18:05, Ali AlipourR (alipoo...@gmail.com) wrote: Why sysrq is limited to only sync command on official fedora kernel? The kernel itself isn't limited. It's just set that way in /usr/lib/sysctl.d/50-default.conf which is provided by systemd. You can edit that file, create your own in /etc/sysctrl.d/, or (as root) set it to whatever you would like via /proc/sys/kernel/sysrq. Of course it can be changed at runtime, but I mean why official fedora kernel shouldn't be configured to allow all (or at least a wider subset) of sysrq commands by default? We generally default secure. The thing is that with sysrq you can kill arbitrary processes if you have acecss to the console, and other things, and that's just too security sensitive. This way official fedora live CDs are unsuitable for system recovery tasks; you have to change sysrq value every time you use live CDs or build your own live CD. I figure for livecds it would be fine to override this. Lennart -- Lennart Poettering, Red Hat -- 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: Why sysrq is limited to only sync command on official fedora kernel?
Once upon a time, Lennart Poettering mzerq...@0pointer.de said: We generally default secure. The thing is that with sysrq you can kill arbitrary processes if you have acecss to the console, and other things, and that's just too security sensitive. There are other useful things, like sync, remount read-only, reboot, poweroff, that we already allow console users to do other ways by default. Allowing them to do them through SysRq seems like a good idea IMHO. -- Chris Adams li...@cmadams.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: repo-mirrorlist quality control?
On Wed, 25 Feb 2015 17:47:47 +0100 Ralf Corsepius rc040...@freenet.de wrote: The user-side of this problem is quite simple: The metalinks/mirrorlists as being used in yum or mock configs are pointing to mirrors, which are broken or out of sync. I.e. the metalinks/mirrorlist are incorrect. Sure. Although in many cases there's also cached repodata causing this, so the mirrors are ok, but the client is requesting old data that none of them have anymore. I don't know how fedora mirror works, esp. whether they are polling or whether they served with pushes. They pull at whatever schedule they like. Many mirrors also mirror other distros or open source projects. Many of them could be running some other linux, or not even linux at all. In another (much smaller) project, when pushing updates, we had removed all mirrors from our mirrorlists and had let the server poll repodata/repomd.xml from the mirrors to re-adde a mirror to the mirrorlists if this file matched. Of course, this is a primitive heuristic, but it had worked quite well for us. yeah, sadly we don't have any ability to push to mirrors, they have to pull from us. The mirrormanager crawler pulls repomd.xml from each mirror when it crawls and compares it. However, as noted we can't poll all mirrors all the time. It is a provable matter of fact that it points users (yum, mock, ...) to broken and out of sync mirrors. There will be such times, sure. Here (Germany), in recent times, they happen almost daily. My guess is the fedora flavors, the launch of f22 and the mass-rebuild on rawhide are showing their nasty side. So, to be clear you see daily where 'yum update' gives you all mirrors erroring out and you cannot get a update list? And 'yum clean all' doesn't help? The next time this happens can you file a ticket with the output? We can try and see if we can see whats happening and how to improve it. I don't see any way of eliminating that. We can reduce it as much as we can with the resources we have. IMO, the issues yum/mock/dnf have, partially need to be worked-around by heuristics in yum/mock/dnf. The caching part for sure. I sometimes observe yum and mock seemingly to lock up to dead mirrors (downloaded metadata is older than previous one) and not to try a more recent mirror. Yeah, that sounds like a bug indeed. I also occasionally see consecutive yum/mock runs to re-iterate and fail over apparently the same mirrorlists (I feel, it retries by priority and therefore always stumbles of the same broken/dead mirrors). Having a past of scientific work on Genetic Algorithms, my first try would be to introduce some randomness into (mirror) selection - It would help to breakout of deterministic causes :-) There should be randomness in mirrorlists/metalinks. It has a weight and mixes up the list so it's not always hitting the highest weight ones. (BTW, I would advise everyone to use metalinks (the default) over plain mirrorlists). There are some things we can do: * If there's a mirror that is reporting that it's up to date, but is not, we can remove it from the list and ask mirror admins to check it. * In mirrorlists and metalinks we provide a list of mirrors. If some are out of sync, yum/dnf should move on to the next and retry. My feel is, this currently doesn't work. The worst cases seem to be yum alternating between several high-priorized broken/dead mirrors. We should then figure out whats causing this and notify the causing component. ;) It sounds like you might see some cases where your metadata is updated locally and all mirrors fail? Please report such bugs. https://fedorahosted.org/mirrormanager/ Yes, this had happened for a longer period (24 hours) some time last week (IIRC, Thursday) and for a shorter period (2-4 hours) yesterday. My guess is, all EU f22/rawhide mirrors were out of sync during these times. Odd. mirrorlists are one of our most visible services. On those rare occasions we have broken them, we get users reporting the issue in minutes. If all EU mirrors were not working I would expect a number of reports. Also, we have a number of tier1 mirrors in EU that stay pretty in sync normally. * We can try and urge more mirrors to sync based on fedmsg (using last-sync) instead of just randomly N times a day. They would then reduce load on master mirrors and get content faster: https://fedoraproject.org/wiki/Infrastructure/Mirroring#Mirror_Frequency * We can finish deploying our mirrormanager2 re-write. It doesn't add many/any new features, but it moves mirrormanager to a codebase we can work on more easily and bugfix/add features to. https://github.com/fedora-infra/mirrormanager2 Sorry, lack of knowledge on these details :( Constructive bugs, ideas or patches welcome. In this case, I am mostly a p***ed user, who is struggling ;) I understand. I'd love to make things better, but we need to
Re: repo-mirrorlist quality control?
On 02/25/2015 04:46 PM, Kevin Fenzi wrote: On Wed, 25 Feb 2015 16:29:14 +0100 Ralf Corsepius rc040...@freenet.de wrote: If so, then you have cached metadata thats older than a few days. No. If not, then it's indeed those mirrors that are out of sync. These mirrors are out of sync. Whether you like it or not, mirrormanager is dysfunctional. That is not very helpfull. The user-side of this problem is quite simple: The metalinks/mirrorlists as being used in yum or mock configs are pointing to mirrors, which are broken or out of sync. I.e. the metalinks/mirrorlist are incorrect. The problem is that managing mirrors is not a simple problem, I don't know how fedora mirror works, esp. whether they are polling or whether they served with pushes. In another (much smaller) project, when pushing updates, we had removed all mirrors from our mirrorlists and had let the server poll repodata/repomd.xml from the mirrors to re-adde a mirror to the mirrorlists if this file matched. Of course, this is a primitive heuristic, but it had worked quite well for us. It is a provable matter of fact that it points users (yum, mock, ...) to broken and out of sync mirrors. There will be such times, sure. Here (Germany), in recent times, they happen almost daily. My guess is the fedora flavors, the launch of f22 and the mass-rebuild on rawhide are showing their nasty side. I don't see any way of eliminating that. We can reduce it as much as we can with the resources we have. IMO, the issues yum/mock/dnf have, partially need to be worked-around by heuristics in yum/mock/dnf. I sometimes observe yum and mock seemingly to lock up to dead mirrors (downloaded metadata is older than previous one) and not to try a more recent mirror. I also occasionally see consecutive yum/mock runs to re-iterate and fail over apparently the same mirrorlists (I feel, it retries by priority and therefore always stumbles of the same broken/dead mirrors). Having a past of scientific work on Genetic Algorithms, my first try would be to introduce some randomness into (mirror) selection - It would help to breakout of deterministic causes :-) There are some things we can do: * If there's a mirror that is reporting that it's up to date, but is not, we can remove it from the list and ask mirror admins to check it. * In mirrorlists and metalinks we provide a list of mirrors. If some are out of sync, yum/dnf should move on to the next and retry. My feel is, this currently doesn't work. The worst cases seem to be yum alternating between several high-priorized broken/dead mirrors. It sounds like you might see some cases where your metadata is updated locally and all mirrors fail? Please report such bugs. https://fedorahosted.org/mirrormanager/ Yes, this had happened for a longer period (24 hours) some time last week (IIRC, Thursday) and for a shorter period (2-4 hours) yesterday. My guess is, all EU f22/rawhide mirrors were out of sync during these times. * We can try and urge more mirrors to sync based on fedmsg (using last-sync) instead of just randomly N times a day. They would then reduce load on master mirrors and get content faster: https://fedoraproject.org/wiki/Infrastructure/Mirroring#Mirror_Frequency * We can finish deploying our mirrormanager2 re-write. It doesn't add many/any new features, but it moves mirrormanager to a codebase we can work on more easily and bugfix/add features to. https://github.com/fedora-infra/mirrormanager2 Sorry, lack of knowledge on these details :( Constructive bugs, ideas or patches welcome. In this case, I am mostly a p***ed user, who is struggling ;) 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
Re: Why sysrq is limited to only sync command on official fedora kernel?
On Wed, 25.02.15 11:16, Chris Adams (li...@cmadams.net) wrote: Once upon a time, Lennart Poettering mzerq...@0pointer.de said: We generally default secure. The thing is that with sysrq you can kill arbitrary processes if you have acecss to the console, and other things, and that's just too security sensitive. There are other useful things, like sync, remount read-only, reboot, poweroff, that we already allow console users to do other ways by default. Allowing them to do them through SysRq seems like a good idea IMHO. Hmm? Syncing is allowed to my knowledge. C-a-d and gdm allow a clean reboot/poweroff. But sysrq does an abnormal reboot/poweroff, which we cannot allow. Similar, remounting read-only is also security senstive, which we cannot allow. Without being logged in there's very little you can do on a host right now, and sysrq should not open up more there by default. Lennart -- Lennart Poettering, Red Hat -- 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: gcc 5 C++ string issue
On 02/25/2015 09:04 AM, Petr Machata wrote:
Orion Poplawski or...@cora.nwra.com writes:
On 02/24/2015 05:22 PM, Kevin Kofler wrote:
Orion Poplawski wrote:
Getting:
/builddir/build/BUILD/mrpt-1.0.2/libs/base/include/mrpt/utils/mrpt_macros.h:296:150:
error: no match for 'operator' (operand types are
'std::basic_ostreamchar' and 'std::ostringstream {aka
std::__cxx11::basic_ostringstreamchar}')
#define ASSERT_NOT_EQUAL_( __A, __B) { if (__A==__B) {
#std::ostringstream
s;sASSERT_NOT_EQUAL_(#__A,#__B) failed with\n#__A=
__A \n#__B=__B; THROW_EXCEPTION(s.str()) } }
Any idea what wrong here?
The following patch fixes the compilation issue:
diff -up mrpt-1.0.2/libs/hwdrivers/src/CImpinjRFID.cpp\~
mrpt-1.0.2/libs/hwdrivers/src/CImpinjRFID.cpp
--- mrpt-1.0.2/libs/hwdrivers/src/CImpinjRFID.cpp~2013-01-05
00:23:15.0 +0100
+++ mrpt-1.0.2/libs/hwdrivers/src/CImpinjRFID.cpp 2015-02-25
16:55:48.628178380 +0100
@@ -97,7 +97,7 @@ void CImpinjRFID::startDriver()
const int ret = ::system(cmdline.str().c_str());
if (0!=ret)
- std::cerr [CImpinjRFID::startDriver] Error ( ret )
invoking command:\n cmdline std::endl;
+ std::cerr [CImpinjRFID::startDriver] Error ( ret )
invoking command:\n cmdline.str() std::endl;
system::exitThread(); // JL-Emil: Really needed? If not, just
remove...
}
I don't know why this stopped working, but it never did the intended
thing as written anyway.
I see now that this was fixed upstream a while back -
https://github.com/jlblancoc/mrpt/commit/0b92b07314e990f61c8b24c475a9a66a45559019
It appears that the Fedora version of mrpt is quite out of date as 1.3.0 is
available - https://bugzilla.redhat.com/show_bug.cgi?id=1196299
With this out of the way, I'm getting a bunch of the following:
../../lib/libmrpt-maps.so.1.0.2: undefined reference to
`pcl::PCDWriter::setLockingPermissions(std::__cxx11::basic_stringchar,
std::char_traitschar, std::allocatorchar const,
boost::interprocess::file_lock)'
So pcl should be rebuilt for new ABI it seems.
Yup.
Thanks,
Petr
Thank you!
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane or...@nwra.com
Boulder, CO 80301 http://www.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: Why sysrq is limited to only sync command on official fedora kernel?
On Wed, 25 Feb 2015, Lennart Poettering wrote: Hmm? Syncing is allowed to my knowledge. C-a-d and gdm allow a clean reboot/poweroff. But sysrq does an abnormal reboot/poweroff, which we cannot allow. Similar, remounting read-only is also security senstive, which we cannot allow. Without being logged in there's very little you can do on a host right now, and sysrq should not open up more there by default. You must have forgotten your university days The alternative to not being able to sync-umount-boot using sysrq is to flip the switch. I'd rather have them use sysrq. I said it when they closed X ctrl-alt-backspace and I'll say it now. When you are on console with the power plug, preventing these actions is stupid. Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Why sysrq is limited to only sync command on official fedora kernel?
Am 25.02.2015 um 18:37 schrieb Paul Wouters: On Wed, 25 Feb 2015, Lennart Poettering wrote: Hmm? Syncing is allowed to my knowledge. C-a-d and gdm allow a clean reboot/poweroff. But sysrq does an abnormal reboot/poweroff, which we cannot allow. Similar, remounting read-only is also security senstive, which we cannot allow. Without being logged in there's very little you can do on a host right now, and sysrq should not open up more there by default. You must have forgotten your university days The alternative to not being able to sync-umount-boot using sysrq is to flip the switch. I'd rather have them use sysrq. I said it when they closed X ctrl-alt-backspace and I'll say it now. When you are on console with the power plug, preventing these actions is stupid when you are on a machine where you have pysical only keyboard and mouse it is not - not every PC stands in front of your face - think about kiosk mode and so on... signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Legacy implementations of the Java platform in Fedora
On 02/24/2015 06:41 PM, Miloslav Trmač wrote: Hello, java would be the preferred JRE in Fedora. The package would have no content, but it would have Requires on preferred Fedora JRE, currently java-1.8.0-openjdk. This could be easily changed as default JRE changes. The same is for other binary subpackages of java, respectively. All system packages would require subpackages of java as they do now (unless there is good reason not to). Users that install java would get latest JRE, which would be updated to new major versions as they become default. Older JDKs would not be removed during update (unless there is no maintainer and they are obsoleted as currently), AFAIK nothing obsoletes a package just because it is orphaned… If no volunteer shows up for maintenance of old JDK then it would be deprecated and obsoleted, as it's was done with previous JDK packages. How would that work _exactly_? 1. JDK-(N+1) is first shipped. The maintainer of JDK-N intends not to package it, so JDK-(N+1) includes Obsoletes:JDK-N from the start. 2. Someone revives JDK-N. Oops, it cannot be installed because JDK-(N+1) obsoletes it. 3. JDK-(N+1) is updated to remove the Obsoletes: . Oops, upgrades from older Fedora versions will no longer remove JDK-N for users who didn’t ask for the legacy version. This is the problem that the renaming to -legacy is supposed to prevent. Though, perhaps it would work equally well to have Obsoletes:JDK-N $version-($release+1); this would still allow updating the older Fedora with bug fixes for JDK-N but to be removed on upgrade, as long as the $release number is kept low enough. And the possible -legacy package could then be represented simply by shipping a version with a bigger $release. 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: RFC : in-development flag for packages
On 25 February 2015 at 06:41, Stephen Gallagher sgall...@redhat.com wrote: On Mon, 2015-02-23 at 17:03 +0200, Yanko Kaneti wrote: On Mon, 2015-02-23 at 14:39 +, Petr Pisar wrote: On 2015-02-22, Yanko Kaneti yan...@declera.com wrote: Introduce an in-development flag for packages in Fedora. I like the confession that no in-developemnt code gets magically stable after half year of sitting in the Rawhide. Indeed that was part of my thinking. In-development packaging that might never reach maturity is a fact of life and the idea was for us to embrace it and manage it in the same place where we manage everything else. Thanks for the feedback. I'm somewhat of the opinion that code should never land in Rawhide that isn't stable upstream (or expected to be within that Fedora release cycle). Code that isn't ready and won't be ready in time belongs in a COPR. I have a couple of questions. 1) Does this change how most (or a sizable group of) developers see what rawhide is meant for? 2) To what extent does the COPR process need to be made more production ready and integrated into the build system to make those developers want to use it? The COPR code is well done, but the resources it relies on are not. The cloud it runs on is a this is something we work on when we have free 10 minutes versus a Saturday through Sunday 24/7/365 utility that we treat the main builders. As long as we aren't treating the COPR builders at that level, most developers are going to do builds on the main builders on the off chance that something is wrong or worse yet slooow. They will then just push to rawhide since it is an easy workflow. -- Stephen J Smoogen. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Taking ownership of html2text on EPEL6
On 02/25/2015 10:23 AM, Vít Ondruch wrote: Dne 25.2.2015 v 17:18 Troy Dawson napsal(a): On 01/09/2015 02:41 PM, Troy Dawson wrote: Hi, I will be taking ownership of html2text on EPEL6. I am already the maintainer for EPEL7, but I missed the notification that the EPEL6 version was being orphaned because of filters. Troy Dawson Hi All, This has turned out to be much more painful than the documentation [1] would have you believe. Anyway, I've eventually managed to become the maintainer for EPEL6, but my problem now is that it's blocked. I cannot build the package. Can someone unblock html2text on epel6 and/or point me to the documentation that says how to unblock a package. Thank You Troy p.s. If someone wants to talk with me about updating the documentation, I can talk to you about the pain points. But I didn't want that to be the focus of this email. [1] http://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers#Claiming_Ownership_of_an_Orphaned_Package_Procedure Quoting from [1]: 5. Request that the Release Engineering team http://fedoraproject.org/wiki/ReleaseEngineering unblock the package for the releases that the package should be un-retired for via their trac instance https://fedorahosted.org/rel-eng/newticket. In this request, please post a link to the completed re-review and clearly specify which branches should be unblocked. So you were are on the right path. Vít [1] http://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers#Claiming_Ownership_of_a_Retired_Package Thank you Vit, that was exactly what I was looking for. I don't know why I missed that. Troy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Orphaned packages up for new point of contact
The following packages had their point of contact changed to orphan based on: https://fedorahosted.org/fesco/ticket/1417 apt -- Debian's Advanced Packaging Tool with RPM support ( master f22 f21 f20 ) arpack -- Fortran 77 subroutines for solving large scale eigenvalue problems ( master f22 f21 f20 ) chrpath -- Modify rpath of compiled programs ( master f22 f21 f20 ) fail2ban -- Daemon to ban hosts that cause multiple authentication errors ( master f22 f21 f20 ) fakechroot -- Gives a fake chroot environment ( master f22 f21 f20 ) fakeroot -- Gives a fake root environment ( master f22 f21 f20 ) fedora-package-config-apt -- Fedora configuration files for the apt-rpm package manager ( master f22 f21 f20 ) freenx-server -- Free Software (GPL) Implementation of the NX Server ( master f22 f21 f20 ) greylistd -- Greylisting daemon ( master f22 f21 f20 ) ivtv-firmware -- Firmware for the Hauppauge PVR 250/350/150/500/USB2 model series ( master f22 f21 f20 ) ivtv-utils -- Tools for the iTVC15/16 and CX23415/16 driver ( master f22 f21 f20 ) libcdaudio -- Control operation of a CD-ROM when playing audio CDs ( master f22 f21 f20 ) maildrop -- Mail delivery agent with filtering abilities ( master f22 f21 f20 ) mediawiki-openid -- The OpenID extension for MediaWiki ( master f22 f21 f20 ) perl-Text-CharWidth -- Get number of occupied columns of a string on terminal ( master f22 f21 f20 ) perl-Text-WrapI18N -- Line wrapping with support for several locale setups ( master f22 f21 f20 ) php-pear-Auth-OpenID -- PHP OpenID ( master f22 f21 f20 ) po4a -- A tool maintaining translations anywhere ( master f22 f21 f20 ) synaptic -- Graphical frontend for APT package manager. ( master f22 f21 f20 ) vtk -- The Visualization Toolkit - A high level 3D visualization library ( master f22 f21 f20 ) vtkdata -- Example data file for VTK ( master f22 f21 f20 ) Feel free to take any you wish to keep in the collection. kevin pgpFXyBZLZOh9.pgp Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: RFC : in-development flag for packages
On Wed, 25 Feb 2015 21:40:57 +0200 Yanko Kaneti yan...@declera.com wrote: Rawhide should absolutely be a site for early integration work, but it really should NOT be a place to dump nightly builds. There are many people that actually use Rawhide as a day-to-day system and treating it like a dumping ground is a really bad idea. Sure, I am one of those people, and building often and having it work are not mutually exclusive. Especially if we can grow some minimal continuous integration testing for the core platform. Completely agreed. I hope soon we will be closer to this as we change things for signing all rawhide packages. As part of that change we will have a koji tag of stuff pending for the next compose and we could then see about hooking in some tests there and/or when things land in the buildroot. kevin pgpHIbdcQSaw5.pgp Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Orphaned packages up for new point of contact
On 02/25/2015 12:48 PM, Kevin Fenzi wrote: The following packages had their point of contact changed to orphan based on: https://fedorahosted.org/fesco/ticket/1417 fail2ban -- Daemon to ban hosts that cause multiple authentication errors ( master f22 f21 f20 ) vtk -- The Visualization Toolkit - A high level 3D visualization library ( master f22 f21 f20 ) vtkdata -- Example data file for VTK ( master f22 f21 f20 ) Taken as I've been maintaining them for a while now. I've approved the outstanding ACL requests as well. As always, co-maintainers welcome. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.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
Schedule for Thursday's FPC Meeting (2015-02-26 17:00 UTC) Followup:7 New:1
Following is the list of topics that will be discussed in the FPC
meeting Thursday at 2015-02-26 17:00 UTC in #fedora-meeting-1 on
irc.freenode.net.
Local time information (via. rktime):
2015-02-26 09:00 Thu US/Pacific PST
2015-02-26 12:00 Thu US/Eastern EST
2015-02-26 17:00 Thu UTC -
2015-02-26 17:00 Thu Europe/London -
2015-02-26 18:00 Thu Europe/Paris CET
2015-02-26 18:00 Thu Europe/Berlin CET
2015-02-26 22:30 Thu Asia/Calcutta IST
--new day--
2015-02-27 01:00 Fri Asia/Singapore SGT
2015-02-27 01:00 Fri Asia/Hong_Kong HKT
2015-02-27 02:00 Fri Asia/Tokyo JST
2015-02-27 03:00 Fri Australia/Brisbane EST
Links to all tickets below can be found at:
https://fedorahosted.org/fpc/report/13
= Followups =
#topic #126 bundling exception for scintilla
.fpc 126
https://fedorahosted.org/fpc/ticket/126
#topic #248 python-feedgenerator - a standalone version of a bundled library
.fpc 248
https://fedorahosted.org/fpc/ticket/248
#topic #303 Consider reverting decision to ban %{?_isa} in BuildRequires
.fpc 303
https://fedorahosted.org/fpc/ticket/303
#topic #325 Temporary bundling exception of yajl library
.fpc 325
https://fedorahosted.org/fpc/ticket/325
#topic #338 %doc and %_pkgdocdir duplicate files and cause conflicts
.fpc 338
https://fedorahosted.org/fpc/ticket/338
#topic #435 %py3dir not removed by rpmbuild --clean
.fpc 435
https://fedorahosted.org/fpc/ticket/435
#topic #497 Clean up BuildRequires section; don't try to define the
minimal build env
.fpc 497
https://fedorahosted.org/fpc/ticket/497
= New business =
#topic #501 Fix bootstrap guidelines
.fpc 501
https://fedorahosted.org/fpc/ticket/501
= Open Floor =
For more complete details, please visit each individual ticket. The
report of the agenda items can be found at:
https://fedorahosted.org/fpc/report/13
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/fpc,
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
[perl-Finance-Quote/f21] Fix some UK fund sources
Summary of changes: 042ca5e... Fix some UK fund sources (*) (*) 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
Re: Hardened builds
On Wed, Feb 25, 2015 at 9:53 AM, Rex Dieter rdie...@math.unl.edu wrote: Mamoru TASAKA wrote: Does %undefine _hardened_build help? that version works for me Hmmm, am I doing something wrong? I've tried both: %undefine _hardened_build and: %undefine _hardened_build %global _hardened_build 0 at the top of the spec file, and in both cases, I still see the hardened specs in CFLAGS and LDFLAGS when %configure is invoked. I've got the right spec file inside the mock root. I don't understand why this worked for you and isn't working for me. -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
