Re: [Proposal] Ring-based Packaging Policies
On 02/12/2015 07:32 PM, Stephen Gallagher wrote: (Logistical note: please keep all replies to this thread on devel@lists.fedoraproject.org) tl;dr Shall we consider requiring a lesser package review for packages that are not present on Product or Spin install media? == Premise == So, some time ago, we started talking about dividing up the Fedora package set into a series of rings. One of the driving purposes behind this idea was to re-evaluate our policies for packaging in each of these rings. In first place, let me mention that I am not fond of these rings and would prefer this idea to be dumped. * The no-bundled-libraries policy means that when a library module requires an update, it means that only one package needs to be modified in order to enhance all applications on the system that consumes it. This is a significant time-saver when it comes to dealing with (increasingly common) security vulnerabilities. It is significant improver and key feature to avoid and fight bugs and vulnerability. Actually I believe, those people who endorse bundling may not have experienced yet the harm bundling can cause and indeed has caused in the early days of Linux. === Disadvantages === * Very strict policies often leads to potential packagers giving up. That's on purpose. Of cause we the #1 objective is quality, but we set the hurdles high to weed out low-quality code and drive-by package submissions. Both were actual problems in the early days of Fedora. * Package reviews for less-interesting packages (such as those for less popular SIGs) often remain un-reviewed for weeks, months or even years. Well, this had been a problem of the Fedora review process ever since, which has many origins, IMO. 1. Open reviews are hard to find. 2. The principle of assigning reviews (owning reviews) discourages prospective reviewers. 3. Interesting packages/reviews are hard to find. I think Fedora has reached the point, most new submissions only address niches. 4. There are people who seem to be striving for badges, by picking low hanging fruits (easy packages). IMO, these people are harmful to Fedora because they are violently locking out other reviewers. 5. The administrational noise. Fedora has adopted an amount of bureaucracy and administrational overhead, which is driving away packagers (Just count the steps and mails maintainers receive until a package has been released). I for one can not avoid to simply erase them because the amount is overwhelming. ... == Analysis == First, I will make an assumption based on the First Foundation: We as the Fedora Project want people to have access to the software that they desire. We may disagree on how that is to be achieved, but I believe the goal is the same. Second, I will call attention to the fact that different Fedora users have very different needs from the software. For example, those running Fedora Server and Fedora Cloud are likely far more concerned with Fedora as a *deployment* platform than they are as a *development* platform. Correct. To me, e.g. Fedora Server and Cloud are not of any interest. No problem with this, unless it's going to harm my deployment. Packaging software for development and packaging it for real-world deployment can be very different. I do not agree. IMO, these are simply different configurations. But I agree insofar, as Fedora doesn't have the appropriate tooling to support such configurations. == Conclusion == So that is my proposal to consider for Fedora 23+ (it's too late in the Fedora 22 cycle to consider this, but I'd prefer starting the F23 discussion right away). Comments and suggestions are strongly encouraged. I regret, but IMO, the rings and different spins are just a waste of valuable and apparently scarce resources, which should better be invested elsewhere in Fedora. 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
[Bug 1192372] New: perl-Data-Peek-0.43 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1192372 Bug ID: 1192372 Summary: perl-Data-Peek-0.43 is available Product: Fedora Version: rawhide Component: perl-Data-Peek Keywords: FutureFeature, Triaged Assignee: jples...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: jples...@redhat.com, perl-devel@lists.fedoraproject.org, ppi...@redhat.com Latest upstream release: 0.43 Current version/release in Fedora Rawhide: 0.42-1.fc22 URL: http://search.cpan.org/dist/Data-Peek/ 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 Soon this service will be implemented by a new system: https://release-monitoring.org/ It will require to manage monitored projects via a new web interface. Please make yourself familiar with the new system to ease the transition. -- 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=cD2r9Kejvma=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 1192376] New: perl-libwww-perl-6.10 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1192376 Bug ID: 1192376 Summary: perl-libwww-perl-6.10 is available Product: Fedora Version: rawhide Component: perl-libwww-perl Keywords: FutureFeature, Triaged Assignee: ppi...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: mmasl...@redhat.com, perl-devel@lists.fedoraproject.org, ppi...@redhat.com Latest upstream release: 6.10 Current version/release in Fedora Rawhide: 6.08-2.fc22 URL: http://search.cpan.org/dist/libwww-perl/ 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 Soon this service will be implemented by a new system: https://release-monitoring.org/ It will require to manage monitored projects via a new web interface. Please make yourself familiar with the new system to ease the transition. -- 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=Seb62pilIma=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 1186281] perl-MooX-Options-4.017 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1186281 Upstream Release Monitoring upstream-release-monitor...@fedoraproject.org changed: What|Removed |Added Summary|perl-MooX-Options-4.016 is |perl-MooX-Options-4.017 is |available |available --- Comment #1 from Upstream Release Monitoring upstream-release-monitor...@fedoraproject.org --- Latest upstream release: 4.017 Current version/release in Fedora Rawhide: 4.015-1.fc22 URL: http://search.cpan.org/dist/MooX-Options/ 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 Soon this service will be implemented by a new system: https://release-monitoring.org/ It will require to manage monitored projects via a new web interface. Please make yourself familiar with the new system to ease the transition. -- 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=PHwwwJr1Uva=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] New: perl-Test-Inter-1.06 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1192382 Bug ID: 1192382 Summary: perl-Test-Inter-1.06 is available Product: Fedora Version: rawhide Component: perl-Test-Inter Keywords: FutureFeature, Triaged Assignee: ppi...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: mmasl...@redhat.com, perl-devel@lists.fedoraproject.org, ppi...@redhat.com Latest upstream release: 1.06 Current version/release in Fedora Rawhide: 1.05-5.fc22 URL: http://search.cpan.org/dist/Test-Inter/ 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 Soon this service will be implemented by a new system: https://release-monitoring.org/ It will require to manage monitored projects via a new web interface. Please make yourself familiar with the new system to ease the transition. -- 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=cQCXtjEy9ja=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: [Proposal] Ring-based Packaging Policies
On Fri Feb 13 2015 at 2:02:27 AM Colin Walters walt...@verbum.org wrote: On Thu, Feb 12, 2015, at 01:32 PM, Stephen Gallagher wrote: tl;dr Shall we consider requiring a lesser package review for packages that are not present on Product or Spin install media? It's worth noting here that having two levels is not really going to be new to the ecosystem; e.g. Ubuntu has had Main/Universe for quite a while: https://help.ubuntu.com/community/Repositories/Ubuntu I just have one question: You're defining this split at the *runtime* level. Last I saw the Base working group was trying to cut down BuildRequires (but sadly I haven't seen them fighting Requires yet - I would love if someone did that for Perl) If Ring 0 packages BuildRequire Ring 1 (or further) packages, ultimately their quality is going to be somewhat contingent on them. Using bundling as a differentiator though, it does seem like there's likely a lot less pressure to require quick security updates for BuildRequires. Anyways, something I think is missing from here is more details on how this on the install media set distinction is maintained over time. If it isn't separate (yum) repositories it seems like it's going to be hard to enforce. (Who would notice if a package in 0 started depending on a ring 1? Would that imply the new dependency needed another review pass?) Having bumped into bundled library issues in the past, this to me sounds like a good idea... provided exclude libraries at the beginning. So: this should only leaf packages, plus applications that happen to have add-on packages that depend on them, and only those that are not Ring 0 (not shipped in one of the install media). A nice alternative is to use the staging area we talked about for this Ring 1 category. Best regards, -- Michel -- 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: Mock, Rawhide and DNF
On Fri, Feb 13, 2015 at 09:35:30AM +0100, Miroslav Suchy wrote: Hi, I just released mock-1.2.7. It have - beside one small bug and new F22 configs - one important change. The rawhide configs have this one line included: config_opts['package_manager'] = 'dnf' which means that Mock will use DNF for building packages for rawhide targets. There are two consequences, which I would like to point out. This change is done only in Mock, but not in Koji. M.McLean is working on Koji code enhancement, which allow to do this change in Koji too. The ETA is 1-3 months. During this transient period Koji will use YUM for rawhide targets, while your local mock builds will use DNF. We would like to use this period to get broader testing of Mock+DNF before it reach Koji. If you experience some problem (I believe there will be none) please report it, so we can address it before we deploy this change on Koji. RHEL/EPEL users do not have DNF available, therefore they are unable to build packages for Fedora Rawhide. There is however a workaround. Just change this line: config_opts['package_manager'] = 'dnf' to this: config_opts['package_manager'] = 'yum' or you can simply delete it because Yum is the default. Or you can pass --yum to mock. Could it be an idea to check if /usr/bin/dnf exists (or if dnf can be found in $PATH) before calling dnf and if not a) warn the user and b) switch back to yum? This would make mock run out of the box for RHEL/EPEL users as well. 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
[Bug 1192369] New: perl-Apache-LogRegex-1.60 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1192369 Bug ID: 1192369 Summary: perl-Apache-LogRegex-1.60 is available Product: Fedora Version: rawhide Component: perl-Apache-LogRegex Keywords: FutureFeature, Triaged Assignee: psab...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: gavin.he...@gmail.com, perl-devel@lists.fedoraproject.org, psab...@redhat.com, st...@silug.org Latest upstream release: 1.60 Current version/release in Fedora Rawhide: 1.52-1.fc22 URL: http://search.cpan.org/dist/Apache-LogRegex/ 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 Soon this service will be implemented by a new system: https://release-monitoring.org/ It will require to manage monitored projects via a new web interface. Please make yourself familiar with the new system to ease the transition. -- 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=pCa2srAmRaa=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 1192371] New: perl-CGI-4.13 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1192371 Bug ID: 1192371 Summary: perl-CGI-4.13 is available Product: Fedora Version: rawhide Component: perl-CGI Keywords: FutureFeature, Triaged Assignee: jples...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: jples...@redhat.com, perl-devel@lists.fedoraproject.org Latest upstream release: 4.13 Current version/release in Fedora Rawhide: 4.04-2.fc22 URL: http://search.cpan.org/dist/CGI/ 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 Soon this service will be implemented by a new system: https://release-monitoring.org/ It will require to manage monitored projects via a new web interface. Please make yourself familiar with the new system to ease the transition. -- 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=JjsYqjmfzla=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 1192370] New: perl-Capture-Tiny-0.28 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1192370 Bug ID: 1192370 Summary: perl-Capture-Tiny-0.28 is available Product: Fedora Version: rawhide Component: perl-Capture-Tiny Keywords: FutureFeature, Triaged Assignee: psab...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: perl-devel@lists.fedoraproject.org, psab...@redhat.com Latest upstream release: 0.28 Current version/release in Fedora Rawhide: 0.27-1.fc22 URL: http://search.cpan.org/dist/Capture-Tiny/ 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 Soon this service will be implemented by a new system: https://release-monitoring.org/ It will require to manage monitored projects via a new web interface. Please make yourself familiar with the new system to ease the transition. -- 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=9JNnOYQK6Ea=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 1192373] New: perl-DBD-CSV-0.48 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1192373 Bug ID: 1192373 Summary: perl-DBD-CSV-0.48 is available Product: Fedora Version: rawhide Component: perl-DBD-CSV Keywords: FutureFeature, Triaged Assignee: psab...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: mmasl...@redhat.com, p...@city-fan.org, perl-devel@lists.fedoraproject.org, psab...@redhat.com Latest upstream release: 0.48 Current version/release in Fedora Rawhide: 0.46-1.fc22 URL: http://search.cpan.org/dist/DBD-CSV/ 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 Soon this service will be implemented by a new system: https://release-monitoring.org/ It will require to manage monitored projects via a new web interface. Please make yourself familiar with the new system to ease the transition. -- 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=df5CvDFqrna=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 1192374] New: perl-Dist-Zilla-Plugin-ReadmeFromPod-0.32 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1192374 Bug ID: 1192374 Summary: perl-Dist-Zilla-Plugin-ReadmeFromPod-0.32 is available Product: Fedora Version: rawhide Component: perl-Dist-Zilla-Plugin-ReadmeFromPod Keywords: FutureFeature, Triaged Assignee: ppi...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com, psab...@redhat.com Latest upstream release: 0.32 Current version/release in Fedora Rawhide: 0.30-1.fc22 URL: http://search.cpan.org/dist/Dist-Zilla-Plugin-ReadmeFromPod/ 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 Soon this service will be implemented by a new system: https://release-monitoring.org/ It will require to manage monitored projects via a new web interface. Please make yourself familiar with the new system to ease the transition. -- 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=soe6G5xNUMa=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 1192377] New: perl-List-Compare-0.43 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1192377 Bug ID: 1192377 Summary: perl-List-Compare-0.43 is available Product: Fedora Version: rawhide Component: perl-List-Compare Keywords: FutureFeature, Triaged Assignee: psab...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: mmasl...@redhat.com, perl-devel@lists.fedoraproject.org, psab...@redhat.com Latest upstream release: 0.43 Current version/release in Fedora Rawhide: 0.41-1.fc22 URL: http://search.cpan.org/dist/List-Compare/ 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 Soon this service will be implemented by a new system: https://release-monitoring.org/ It will require to manage monitored projects via a new web interface. Please make yourself familiar with the new system to ease the transition. -- 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=RisaBzvsb7a=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 1192381] New: perl-Socket-2.018 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1192381 Bug ID: 1192381 Summary: perl-Socket-2.018 is available Product: Fedora Version: rawhide Component: perl-Socket Keywords: FutureFeature, Triaged Assignee: ppi...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: mmasl...@redhat.com, perl-devel@lists.fedoraproject.org, ppi...@redhat.com Latest upstream release: 2.018 Current version/release in Fedora Rawhide: 2.017-1.fc22 URL: http://search.cpan.org/dist/Socket/ 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 Soon this service will be implemented by a new system: https://release-monitoring.org/ It will require to manage monitored projects via a new web interface. Please make yourself familiar with the new system to ease the transition. -- 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=N68SoUFGCSa=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 1192380] New: perl-Pod-Usage-1.65 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1192380 Bug ID: 1192380 Summary: perl-Pod-Usage-1.65 is available Product: Fedora Version: rawhide Component: perl-Pod-Usage Keywords: FutureFeature, Triaged Assignee: ppi...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com Latest upstream release: 1.65 Current version/release in Fedora Rawhide: 1.64-3.fc22 URL: http://search.cpan.org/dist/Pod-Usage/ 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 Soon this service will be implemented by a new system: https://release-monitoring.org/ It will require to manage monitored projects via a new web interface. Please make yourself familiar with the new system to ease the transition. -- 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=UtfZvmKrIFa=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 1192379] New: perl-Pod-Perldoc-3.25 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1192379 Bug ID: 1192379 Summary: perl-Pod-Perldoc-3.25 is available Product: Fedora Version: rawhide Component: perl-Pod-Perldoc Keywords: FutureFeature, Triaged Assignee: ppi...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: mmasl...@redhat.com, perl-devel@lists.fedoraproject.org, ppi...@redhat.com Latest upstream release: 3.25 Current version/release in Fedora Rawhide: 3.24-4.fc22 URL: http://search.cpan.org/dist/Pod-Perldoc/ 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 Soon this service will be implemented by a new system: https://release-monitoring.org/ It will require to manage monitored projects via a new web interface. Please make yourself familiar with the new system to ease the transition. -- 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=DpB8p6MpKTa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Pod-Perldoc/f22] 3.25 bump
Summary of changes: d2d46cb... 3.25 bump (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1192379] perl-Pod-Perldoc-3.25 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1192379 --- Comment #1 from Petr Pisar ppi...@redhat.com --- Bug-fix update suitable for F≥22. -- 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=Yw3nRz45wwa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Pod-Perldoc] 3.25 bump
commit d2d46cbdc0cb5f2cf70b8d03f75366918b9f1eae
Author: Petr Písař ppi...@redhat.com
Date: Fri Feb 13 10:54:03 2015 +0100
3.25 bump
.gitignore|1 +
perl-Pod-Perldoc.spec | 15 ---
sources |2 +-
3 files changed, 10 insertions(+), 8 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 2635e43..ec3605b 100644
--- a/.gitignore
+++ b/.gitignore
@@ -6,3 +6,4 @@
/Pod-Perldoc-3.21.tar.gz
/Pod-Perldoc-3.23.tar.gz
/Pod-Perldoc-3.24.tar.gz
+/Pod-Perldoc-3.25.tar.gz
diff --git a/perl-Pod-Perldoc.spec b/perl-Pod-Perldoc.spec
index fb79724..9fb7f2d 100644
--- a/perl-Pod-Perldoc.spec
+++ b/perl-Pod-Perldoc.spec
@@ -1,15 +1,14 @@
%bcond_without tk
-%global cpan_version 3.24
Name: perl-Pod-Perldoc
# let's overwrite the module from perl.srpm
-Version:%(echo '%{cpan_version}' | sed 's/_/./')
-Release:4%{?dist}
+Version:3.25
+Release:1%{?dist}
Summary:Look up Perl documentation in Pod format
License:GPL+ or Artistic
Group: Development/Libraries
URL:http://search.cpan.org/dist/Pod-Perldoc/
-Source0:
http://www.cpan.org/authors/id/M/MA/MALLEN/Pod-Perldoc-%{cpan_version}.tar.gz
+Source0:
http://www.cpan.org/authors/id/M/MA/MALLEN/Pod-Perldoc-%{version}.tar.gz
BuildArch: noarch
BuildRequires: perl
BuildRequires: perl(ExtUtils::MakeMaker)
@@ -20,7 +19,7 @@ BuildRequires: perl(warnings)
BuildRequires: groff-base
BuildRequires: perl(Carp)
BuildRequires: perl(Config)
-# Encode not used by tests
+BuildRequires: perl(Encode)
BuildRequires: perl(Fcntl)
BuildRequires: perl(File::Basename)
BuildRequires: perl(File::Spec::Functions)
@@ -43,7 +42,6 @@ BuildRequires: perl(Pod::Text::Termcap)
# Text::ParseWords not used by tests
BuildRequires: perl(vars)
# Tests:
-BuildRequires: perl(base)
BuildRequires: perl(Test::More)
# Optional tests:
%if !%{defined perl_bootstrap}
@@ -83,7 +81,7 @@ in the perl installation tree or in a perl script, and
displays it via
the perl library modules.
%prep
-%setup -q -n Pod-Perldoc-%{cpan_version}
+%setup -q -n Pod-Perldoc-%{version}
%build
perl Makefile.PL INSTALLDIRS=vendor
@@ -105,6 +103,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Fri Feb 13 2015 Petr Pisar ppi...@redhat.com - 3.25-1
+- 3.25 bump
+
* Mon Sep 15 2014 Petr Pisar ppi...@redhat.com - 3.24-4
- Enable perl(Tk) tests
diff --git a/sources b/sources
index e9f48dc..5418fc8 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-a43ce0682d8a1d4a7b01c65600b45054 Pod-Perldoc-3.24.tar.gz
+4991ce24fab9900312f11d9c8ab7576f Pod-Perldoc-3.25.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File Pod-Perldoc-3.25.tar.gz uploaded to lookaside cache by ppisar
A file has been added to the lookaside cache for perl-Pod-Perldoc: 4991ce24fab9900312f11d9c8ab7576f Pod-Perldoc-3.25.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1192379] perl-Pod-Perldoc-3.25 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1192379 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-Pod-Perldoc-3.25-1.fc2 ||3 Resolution|--- |NEXTRELEASE Last Closed||2015-02-13 05:07:11 --- Comment #2 from Petr Pisar ppi...@redhat.com --- Fixes as perl-Pod-Perldoc-3.25-1.fc22 in F22. -- 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=TTOpMuaqPBa=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: New Phabricator on qadevel-stg
I've built new rpms for phabricator and deployed them to staging. https://phab.qadevel-stg.cloud.fedoraproject.org/ If you have a bit of time, please help poke at the staging instance so we have some confidence that deploying the new versions to production won't break things horribly :) I tried common ticket/diff operations and I haven't seen any problems. ___ qa-devel mailing list qa-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/qa-devel
Re: Mock, Rawhide and DNF
On Friday, February 13, 2015, Pierre-Yves Chibon pin...@pingoured.fr wrote: On Fri, Feb 13, 2015 at 09:35:30AM +0100, Miroslav Suchy wrote: RHEL/EPEL users do not have DNF available, therefore they are unable to build packages for Fedora Rawhide. There is however a workaround. Just change this line: config_opts['package_manager'] = 'dnf' to this: config_opts['package_manager'] = 'yum' or you can simply delete it because Yum is the default. Or you can pass --yum to mock. Could it be an idea to check if /usr/bin/dnf exists (or if dnf can be found in $PATH) before calling dnf and if not a) warn the user and b) switch back to yum? This would make mock run out of the box for RHEL/EPEL users as well. Mock needs to check if /usr/bin/dnf is a file instead of a symlink as well since I've created a symlink on my system. (a little bit strange though) -- Yours sincerely, Christopher Meng http://cicku.me -- 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: [Proposal] Ring-based Packaging Policies
* Paul Howarth [12/02/2015 20:05] : We generally have requires for most optional functionality in Perl packages at the moment, to avoid bugs being raised about missing dependencies when people try to use that optional functionality. Based on past emails, I suspect that Colin wishes nothing in Base depended on perl (ie. he wants Base to be perl-free), not that Perl packages had optional Requires. Emmanuel -- 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: sorting yum/dnf metadata and metadata diffs
On 13.02.2015 08:11, Casey Jao wrote: How feasible would it be to keep the listings in primary.xml and filelists.xml sorted by package name and arch? Doing so could open the door to simple and efficient diffs of repository metadata. Something like pdiffs in Debian? Those two are by far the largest metadata files. If the observed improvements are typical, then keeping those files in order and hosting the diffs between the present and the previous few days (and modifying dnf to look for those diffs) could substantially reduce the amount of data that users must download every time a repository is updated, which for a fast-moving OS like Fedora could happen nearly every day. If only amount of download data matters then why not compress primary.xml and filelists.xml with xz? 11646147 primary.xml.gz 8676976 primary.xml.xz 30607019 filelists.xml.gz 23661236 filelists.xml.xz But yeah, it can make dnf/yum use more cpu power to uncompress them each time they want to use that data. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Mock, Rawhide and DNF
Hi, I just released mock-1.2.7. It have - beside one small bug and new F22 configs - one important change. The rawhide configs have this one line included: config_opts['package_manager'] = 'dnf' which means that Mock will use DNF for building packages for rawhide targets. There are two consequences, which I would like to point out. This change is done only in Mock, but not in Koji. M.McLean is working on Koji code enhancement, which allow to do this change in Koji too. The ETA is 1-3 months. During this transient period Koji will use YUM for rawhide targets, while your local mock builds will use DNF. We would like to use this period to get broader testing of Mock+DNF before it reach Koji. If you experience some problem (I believe there will be none) please report it, so we can address it before we deploy this change on Koji. RHEL/EPEL users do not have DNF available, therefore they are unable to build packages for Fedora Rawhide. There is however a workaround. Just change this line: config_opts['package_manager'] = 'dnf' to this: config_opts['package_manager'] = 'yum' or you can simply delete it because Yum is the default. Or you can pass --yum to mock. However you should be aware that you are using different depsolving and you may get slightly different result. And last one notice: I built mock-1.2.7 only for rawhide, F22 and F21 for now. I will create updates for F20, Epel7 and EL6 on Wednesday next week as I do not want to interrupt quarantine period of previous update in bodhi, which carry some important fixes. 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: sorting yum/dnf metadata and metadata diffs
Hi, there's been some work in progress already: https://bugzilla.redhat.com/show_bug.cgi?id=850896 Proof-of-concept code (to be merged into dnf/createrepo_c in the future): https://github.com/Tojaj/DeltaRepo The idea behind that is simple: * create deltas as small repos on server * download deltas on client * do in-memory mergerepo on client (or cache it on disk if it makes sense) I consider this approach better than making diffs, especially because it's simple, clean and it can work with any repo format (sqlite, xml or mix of both). - daniel Dne 13.2.2015 v 08:11 Casey Jao napsal(a): How feasible would it be to keep the listings in primary.xml and filelists.xml sorted by package name and arch? Doing so could open the door to simple and efficient diffs of repository metadata. I recently ran some quick tests using python and elementtree. While the F21 primary.xml files from 2/7 and 2/9 both weigh around 2.6M compressed and ~18M uncompressed, sorting them and running a simple line-by-line comparison revealed a diff of ~500K, which compressed down to ~70K. A similar procedure on the 8M filelists.xml yielded a diff which compressed to ~200K. Those two are by far the largest metadata files. If the observed improvements are typical, then keeping those files in order and hosting the diffs between the present and the previous few days (and modifying dnf to look for those diffs) could substantially reduce the amount of data that users must download every time a repository is updated, which for a fast-moving OS like Fedora could happen nearly every day. -- Daniel Mach dm...@redhat.com Release Engineering, 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: sorting yum/dnf metadata and metadata diffs
How feasible would it be to keep the listings in primary.xml and filelists.xml sorted by package name and arch? Doing so could open the door to simple and efficient diffs of repository metadata. Createrepo_c [1] keeps packages sorted by filename [2] by default. Sorting based on filenames was chosen intentionally, a package basename usually consists of name-version-release.arch - so the sorting is more deterministic than just name and arch. Tomas [1] https://github.com/Tojaj/createrepo_c [2] https://github.com/Tojaj/createrepo_c/blob/master/src/createrepo_c.c#L111 -- 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 1192377] perl-List-Compare-0.43 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1192377 --- Comment #1 from Fedora Update System upda...@fedoraproject.org --- perl-List-Compare-0.43-1.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/perl-List-Compare-0.43-1.fc21 -- 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=C8AXXT8zDQa=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 1190421] perl-List-Compare-0.40 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1190421 --- Comment #2 from Fedora Update System upda...@fedoraproject.org --- perl-List-Compare-0.43-1.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/perl-List-Compare-0.43-1.fc21 -- 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=u0zzUqCUZxa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File List-Compare-0.43.tar.gz uploaded to lookaside cache by psabata
A file has been added to the lookaside cache for perl-List-Compare: 5a5024219599ebf7b1539e3642738b8c List-Compare-0.43.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-List-Compare/f21] 0.43 bump, performance enhancements
Summary of changes: 3b4ea3b... 0.43 bump, performance enhancements (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-List-Compare] 0.43 bump, performance enhancements
commit 3b4ea3b2e0a9864f95c4448eee97381e8e260990
Author: Petr Šabata con...@redhat.com
Date: Fri Feb 13 12:23:57 2015 +0100
0.43 bump, performance enhancements
.gitignore |1 +
perl-List-Compare.spec |5 -
sources|2 +-
3 files changed, 6 insertions(+), 2 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 944624b..e4710be 100644
--- a/.gitignore
+++ b/.gitignore
@@ -2,3 +2,4 @@ List-Compare-0.37.tar.gz
/List-Compare-0.38.tar.gz
/List-Compare-0.39.tar.gz
/List-Compare-0.41.tar.gz
+/List-Compare-0.43.tar.gz
diff --git a/perl-List-Compare.spec b/perl-List-Compare.spec
index c41ead2..d5581e3 100644
--- a/perl-List-Compare.spec
+++ b/perl-List-Compare.spec
@@ -1,5 +1,5 @@
Name: perl-List-Compare
-Version:0.41
+Version:0.43
Release:1%{?dist}
Summary:Compare elements of two or more lists
Group: Development/Libraries
@@ -46,6 +46,9 @@ make test
%{_mandir}/man3/*.3*
%changelog
+* Fri Feb 13 2015 Petr Šabata con...@redhat.com - 0.43-1
+- 0.43 bump, performance enhancements
+
* Mon Feb 09 2015 Petr Šabata con...@redhat.com - 0.41-1
- 0.41 bump
diff --git a/sources b/sources
index 07950e5..b5235e2 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-0548ef748248a59fedb342dc2115e8cf List-Compare-0.41.tar.gz
+5a5024219599ebf7b1539e3642738b8c List-Compare-0.43.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-List-Compare/f22] 0.43 bump, performance enhancements
Summary of changes: 3b4ea3b... 0.43 bump, performance enhancements (*) (*) 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: I wrote small script to list FTBFS koji entries
On 02/12/2015 08:51 PM, Marcin Juszkiewicz wrote: I plan to make something like Ubuntu has [2] which was great help when I was working on fixing packages while working for Canonical. With Michael Simacek we are working on Koschei [1,2] - a service for tracking package buildability status. I would like you to consider using Koschei. We can discuss adding missing features you need. Koschei currently tracks only 3143 of all Fedora packages, but interested parties are welcome to add more packages. [1] https://fedoraproject.org/wiki/Koschei [2] http://koschei.cloud.fedoraproject.org/ -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Proposal to (formally/easily) allowing multiple versions of the same library installable
Dear all, I don't know if this has been discussed before, but I didn't find any. Summary: I have a proposal to make it easier for maintainers to have multiple versions of the same library in distro (by making it *naturally* possible) (and with minimal maintenance overhead), and for users/developers to get their desired version(s) installed. Proposal in brief: instead of packaging libfoo as libfoo, the maintainer *can* package it as libfooVER (e.g. libfoo2) and create libfoo/libfoo-devel package which depends on libfoo2/libfoo2-devel. Now, libfoo-3 package can be packaged as libfoo3, and both can be installed simultaneously (assuming that they provide different .so versions, otherwise it could be provided as an update to libfoo2). Notice that once libfoo2 is in the repos, newer versions (libfoo3/libfoo4) should not require a package review. Introduction: As a developer, it happened to me a lot to *wish* my Fedora version could also have a newer version of libfoo, and I'm not forced to either upgrade to/wait for the next Fedora release or install the package just to get a newer version. Also, I've seen many situations in which I or another user wanted to have multiple versions of the same library installed (e.g. to run some third party programs). Currently, this is not possible in Fedora because RPM doesn't allow you to install multiple versions of the same package (e.g. libfoo). But, this has been workaround from time to time for some libraries; a good example is Qt. Qt can't be easily upgraded to version 5 since many fundamental packages (e.g. KDE) depend on it, but if Fedora didn't provide Qt5 packages it would be left behind considerably. So, you can see qt5-* packages in Fedora repository (IIRC, a similar situation has happened for Qt3-Qt4 upgrade). However, they certainly had to review all such qt5 packages, and also this is a temporary solution for this library. Proposal: let's make it possible to have multiple versions of the same library installed, as far as their .so version permits that. 1. Include the base version of the library into its package name. So, instead of libfoo we can have libfoo2, libfoo3, libfoo4. 2. No reviews are required for new libfooX packages (as it is not required right now when you update your libfoo package). 3. For each Fedora release, there is libfoo/libfoo-devel packages which Require the default version of libfoo packages for that release. For example, libfoo.fc20/libfoo-devel.fc20 will Require libfoo2/libfoo2-devel; for F21 libfoo3/libfoo3-devel and for F22/Rawhide libfoo4/libfoo4-devel. 4. Each Fedora release can provide at least 3 versions of libfoo. e.g. F21 provides libfoo3 as default libfoo, libfoo2 as compat package, and libfoo3 as 'latest stable version'. This should not create much burden for the maintainer, since he is already maintaining these 3 versions for different Fedora release versions. Now, he can provide all of them in all active Fedora releases. 5. Packages should either built against the 'default version' (build requiring libfoo-devel), or the next version if strictly needed. Building against 'old' version should be discouraged/forbidden. So, in above example, no F21 packages are allowed to be built against libfoo2, which is the compatibility libfoo package in F21. For -devel packages, two methods can be allowed: 1. Simple: -devel packages conflict with each other, so while you can have multiple versions of libfoo installed, you can have only a single version of libfoo-devel installed 2. Flexible: Provide the possibility of installing multiple -devel versions, and a method to select the default one, like the alternatives system. More details can be discussed, but I think it's enough for now. I want to see what others think about the whole idea. Details can be worked out if the idea seems interesting. Q: Can't a packager do it already? Why propose it as a 'proposal'? A: Yes, he can, but it'll be hard; mainly because he'll need to put new versions of the library for review. Also, I suggest it as a 'recommended practice' for packaging libraries. IMHO, this method will have many advantages, and can make it much easier to provide COPR repositories or similar to experiment with new things on a stable Fedora release without affecting other installed software. Also, it might make it possible to install and experiment with some packages from Rawhide/next Fedora release directly on your current release. As a developer, it makes the version of available libraries for development less bounded to Fedora version. Regards, Hedayat -- 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: amending the new package process
On 01/24/2015 07:14 PM, Kevin Kofler wrote: Ralf Corsepius wrote: This is not entirely true. GCC and related projects apply a pretty complex peer review process, with defined roles and privileges. (Cf. the file MAINTAINERS in GCC's sourcetree for details). Somewhat over-simplified the process condenses into All proposed changes must be peer-reviewed by somebody who is formally in charge of a component to be changed. Exceptions apply for obvious changes. It has been a while since I have last been following the GCC mailing lists (so this may or may not have changed since then), but at least back then, a maintainer for a given part of GCC was allowed to commit to that part of GCC without having it reviewed by a second person, and a global maintainer was allowed to commit to ANY part of GCC without having it reviewed by a second person. If you were allowed to approve other people's commits, you were also allowed to approve your own. There were also people only allowed to write after approval, but that was only the default/least-trusted level of commit access granted, and write after approval developers were also not allowed to review other people's submissions (unlike our system where any packager can review other packager's submissions, but never their own). Has this changed since? No. It is as you describe. Andrew. -- 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: amending the new package process
On Fri, Feb 13, 2015 at 11:55:02AM +, Andrew Haley wrote: On 01/24/2015 07:14 PM, Kevin Kofler wrote: Ralf Corsepius wrote: This is not entirely true. GCC and related projects apply a pretty complex peer review process, with defined roles and privileges. (Cf. the file MAINTAINERS in GCC's sourcetree for details). Somewhat over-simplified the process condenses into All proposed changes must be peer-reviewed by somebody who is formally in charge of a component to be changed. Exceptions apply for obvious changes. It has been a while since I have last been following the GCC mailing lists (so this may or may not have changed since then), but at least back then, a maintainer for a given part of GCC was allowed to commit to that part of GCC without having it reviewed by a second person, and a global maintainer was allowed to commit to ANY part of GCC without having it reviewed by a second person. If you were allowed to approve other people's commits, you were also allowed to approve your own. There were also people only allowed to write after approval, but that was only the default/least-trusted level of commit access granted, and write after approval developers were also not allowed to review other people's submissions (unlike our system where any packager can review other packager's submissions, but never their own). Has this changed since? No. It is as you describe. No, we don't have global maintainers for quite a few years, only global reviewers who aren't allowed to approve their own changes. And, while we have various maintainers that for some part of code are allowed to approve their own changes, we have also many reviewers of particular parts of code that can approve only changes from other people but not their own. Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Proposal to (formally/easily) allowing multiple versions of the same library installable
On Fri, 2015-02-13 at 15:21 +0330, Hedayat Vatankhah wrote: Dear all, I don't know if this has been discussed before, but I didn't find any. Summary: I have a proposal to make it easier for maintainers to have multiple versions of the same library in distro (by making it *naturally* possible) (and with minimal maintenance overhead), and for users/developers to get their desired version(s) installed. Proposal in brief: instead of packaging libfoo as libfoo, the maintainer *can* package it as libfooVER (e.g. libfoo2) and create libfoo/libfoo-devel package which depends on libfoo2/libfoo2-devel. Now, libfoo-3 package can be packaged as libfoo3, and both can be installed simultaneously (assuming that they provide different .so versions, otherwise it could be provided as an update to libfoo2). Notice that once libfoo2 is in the repos, newer versions (libfoo3/libfoo4) should not require a package review. I'm not against it, for the libraries which provide proper symbol versioning. Otherwise, if you only rely on the soname, you may end up in a situation where a program crashes because of inter-dependencies which make it link with both libfoo1 and libfoo2 which provide the same (but most likely incompatible) symbols. regards, Nikos -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[perl-Apache-LogRegex/f22] 1.60 bump
Summary of changes: 8df4071... 1.60 bump (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Dist-Zilla-Plugin-ReadmeFromPod/f22] 0.32 bump
Summary of changes: 6691f37... 0.32 bump (*) (*) 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
MongoDB Security Defaults
Hello, After reading this article[1] on how many totally unsecured mongodb installations there are on the internet, I noticed a recent (and worrying) change in the defaults on Fedora's mongodb package. In January, the Fedora rawhide package for mongo[2] was changed to listen on all interfaces by default, but I haven't been able to find any information about why it was changed. To help protect users, I think the default should be changed back to localhost only. Operators can change this setting post-install if needed, hopefully after assessing how risky it is to have an open-world database. This change could probably be reverted safely as-is, since (I hope) nobody is running production mongo clusters on rawhide. Debian and Ubuntu have mongodb set to (by default) only listen on localhost[3], which is sane and normal for a database that does *no authentication of any kind* by default. The same has been true of MongoDB Inc.'s[4] example config since approximately 2013[5]. [1]: http://thehackernews.com/2015/02/mongodb-database-hacking.html [2]: http://pkgs.fedoraproject.org/cgit/mongodb.git/tree/mongodb.conf?id=be37804b64d9a9b8e8f305d5a89a9c477deac619 [3]: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/utopic/mongodb/utopic/view/head:/debian/mongodb.conf [4]: https://github.com/mongodb/mongo/blob/master/rpm/mongod.conf [5]: https://github.com/mongodb/mongo/commit/f8699f77f90ff9b24d23729644ee7cd7ed0e9600 -- Ryan Brown / Software Engineer, Openstack / Red Hat, Inc. -- 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: [Proposal] Ring-based Packaging Policies
On Fri, 13 Feb 2015 13:54:59 +0100, Ralf Corsepius wrote: Meanwhile, we've had much more critical vulnerablities in widely used libs (Remember heartbleed), which all have been quite easy to fix packaging-wise. IMO, to a great portion, thanks to having mostly banned static linkage and bundling. There's more to it, too. Static linking is not only a risk with regard to security vulnerabilites. You cannot retest against an updated static lib without relinking the dependencies. You don't learn about new runtime breakage (or regressions) caused by the changed static lib, because the programs still use an old lib linked into them. The changed lib may have been out for many weeks as an update, but nothing test-drives it. What a surprise, if the lib were found to cause a sudden problem for a minor rebuild of a program. Or worse, if the rebuild were released quickly because of expecting it to be harmless, but the static lib under the hood has changed and breaks runtime for users. -- 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: [Proposal] Ring-based Packaging Policies
On 13 February 2015 at 13:06, Michael Schwendt mschwe...@gmail.com wrote: On Thu, 12 Feb 2015 16:49:13 -0500, Stephen Gallagher wrote: On Thu, 2015-02-12 at 20:18 +0100, Alec Leamas wrote: On 12/02/15 19:32, Stephen Gallagher wrote: (Logistical note: please keep all replies to this thread on devel@lists.fedoraproject.org) tl;dr Shall we consider requiring a lesser package review for packages that are not present on Product or Spin install media? Thanks for bringing this up. We really need to do something about this, and the proposal is likely to get things rolling. This is really about two things, right? A lighter review and a general bundling exception for packages not in the core (?) Ultimately, it's about one thing: Help get more software into Fedora without scaring people away. What is the background for this? Who has been scared away? Is this about a few vocal people, who boycott everything related to packaging guidelines and update guidelines? We've had a few incidents like that *many* years ago when somebody wanted to put pressure on the Fedora Project because things are not done in the same way as preferred by such people. IMO: What scares away people primarly is the actual maintenance period during the life-cycle of a Fedora. Somebody, who is afraid of making mistakes, whether small or large, will likely not join at all. Somebody, who takes the requirements too lightly, will run into trouble sooner than later. A good example is the first lib upgrade that bumps the soname and has been pushed to stable without even testing installation, because of treating the repo like a dumping ground. The sudden requirements to learn about what needs to be done to prevent this (ABI checks, buildroot overrides, rebuilds) make some people think twice whether they want to maintain the packages at Fedora. Plus, in order to rebuild dependencies, they would need to co-maintain the dependencies (for commit access) or actively communicate with the maintainers of the deps. For some this is too much effort to be worthwhile. Actually, a question I have about this is how it will impact people trying to become maintainers. When I last checked (it may have changed) the only way to do that was to create a new package. Typically that will be a package you're interested in getting into Fedora which may be non-trivial and benefit from someone more experienced doing it, or it might be somewhat arbitrarily chosen if you want to help maintain an existing package. So, is that implicit test (can you package according to the guidelines?) going to become easier? Is it necessary to then have a second level of approval before you can work on core packages if you started on a non-core package? Should becoming a maintainer become a bit more decoupled from the process of actually preparing a package? This doesn't really affect the proposal at hand, but it would be useful to know. -- imalone http://ibmalone.blogspot.co.uk -- 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 1192381] perl-Socket-2.018 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1192381 --- Comment #4 from Fedora Update System upda...@fedoraproject.org --- perl-Socket-2.018-1.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/perl-Socket-2.018-1.fc20 -- 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=ZOBEILIC4sa=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 1191491] perl-Socket-2.017 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1191491 --- Comment #5 from Fedora Update System upda...@fedoraproject.org --- perl-Socket-2.018-1.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/perl-Socket-2.018-1.fc20 -- 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=0A1MoUZG8Qa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File Capture-Tiny-0.28.tar.gz uploaded to lookaside cache by psabata
A file has been added to the lookaside cache for perl-Capture-Tiny: 2923ba0524f4f42a6022f3ef1ca1913d Capture-Tiny-0.28.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-Capture-Tiny/f22] 0.28 bump
Summary of changes: dc5f63f... 0.28 bump (*) (*) 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
Tested patches for openqa_fedora_tools to use fedfind and wikitcms, fix some result submissions
OK, I completed my fedfind/wikitcms conversion patch for openqa_fedora_tools. I also fixed up some of the test case submission data bits - they broke with relval report-auto (instead of jskladan's version of non-interactive result submission) because they didn't quite grok the 'test instance' concept report-auto follows. Note this needs the very latest git wikitcms. I don't think latest relval or fedfind is strictly required, but may as well bump them anyway. I've installed the current wikitcms on fedora-qa-01. I will cut new releases tomorrow. I have tested this on fedora-qa-01, it ran and submitted a full set of results for 2015-02-07. I believe it should work for Branched nightlies (if we wind up nominating any) and TC/RC builds also, which is a significant win. I did test this a bit: https://fedora-qa-01.lab.bos.redhat.com/tests/15 is a one-job run against F21 Final RC5, you can see it successfully got the ISO and started the test but the test fails because the 'Timbuktu' screen isn't there. I revised the openqa_trigger.py CLI to use argparse; it has the same basic modes as before but the syntax is a bit different. 'openqa_trigger.py current' runs against the 'current' compose event if it has not already done so (what just plain 'openqa_trigger.py' did before). 'openqa_trigger.py event' takes the same 'version id' arguments as 'relval report-auto' and runs tasks (but does not automatically report results) against the specified compose (what you used to get by passing args, approximately, but much more robust and capable). The basic approach is that openqa_trigger gets a ValidationEvent from python-wikitcms - either the Wiki.current_event property for 'current', or the event specified, obtained via the newly-added Wiki.get_validation_event(), for 'event'. For 'event' it then just goes ahead and runs the jobs and prints the IDs. For 'current' it checks the last run compose version for each arch and runs if needed, as before. The ValidationEvent's 'sortname' property is the value written out to PERSISTENT to track the 'last run' - this property is intended to always sort compose events 'correctly', so we should always run when appropriate even when going from Rawhide to Branched, Branched to a TC, TC to RC, RC to (next milestone) TC. On both paths it gets a fedfind.Release object via the ValidationEvent - ValidationEvents have a ff_release property which is the fedfind.Release object that matches that event. It then queries fedfind for image locations using a query that tries to get just *one* generic-ish network install image for each arch. It passes the location to download_image(), which is just download_rawhide_iso() renamed and does the same job, only it can be simpler now. From there it works pretty much as before, except we use the ValidationEvent's 'version' property as the BUILD setting for OpenQA, and report_job_results get_relval_commands() is tweaked slightly to parse this properly to produce a correct report-auto command. Probably the most likely bits to break here are the sortname thing (see wikitcms helpers.py fedora_release_sort(), it's pretty stupid, I should re-write it) and the image query, which might wind up getting more than one image depending on how exactly the F22 Alpha composes look. I'll keep a close eye on that. We can always take the list from fedfind and further filter it so we have just one image per arch. Image objects have a .arch attribute so this will be easy to do if necessary. I *could* give the fedfind query code a 'I'm feeling lucky'- ish mode to only return one image per (whatever), but not sure if that would be too specialized, I'll think about it. Please do ask any questions :) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net From 55d5d1b4ce4bfd7ae7c239c8aca03bceee2f1f06 Mon Sep 17 00:00:00 2001 From: Adam Williamson awill...@redhat.com Date: Thu, 12 Feb 2015 19:32:27 -0800 Subject: [PATCH 1/3] use python-wikitcms and fedfind to handle events and images This removes a bunch of template-y bits that fedfind does better, and should make things work for all validation events. The CLI for openqa_trigger is completely redone to use argparse and check values and stuff. The syntax for the event sub-command is purposely similar to relval report-auto. Note this requires wikitcms changes currently in git master. --- tools/openqa_trigger/openqa_trigger.py | 159 +++-- tools/openqa_trigger/report_job_results.py | 7 +- 2 files changed, 108 insertions(+), 58 deletions(-) diff --git a/tools/openqa_trigger/openqa_trigger.py b/tools/openqa_trigger/openqa_trigger.py index 9406d0c..7424c8b 100755 --- a/tools/openqa_trigger/openqa_trigger.py +++ b/tools/openqa_trigger/openqa_trigger.py @@ -7,15 +7,15 @@ import urlgrabber import os.path import sys import subprocess +import argparse +import
[Bug 1192370] perl-Capture-Tiny-0.28 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1192370 Petr Šabata psab...@redhat.com changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-Capture-Tiny-0.28-1.fc ||22 Resolution|--- |RAWHIDE Last Closed||2015-02-13 07:54:33 -- 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=ImlRJe2FMVa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Socket/f22] 2.018 bump
Summary of changes: f24c353... 2.018 bump (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Socket/f20] 2.018 bump
commit 5de7dbd179584a5d66ca5a12eb1ed3666796b486
Author: Petr Písař ppi...@redhat.com
Date: Fri Feb 13 14:31:05 2015 +0100
2.018 bump
.gitignore |1 +
perl-Socket.spec |7 +--
sources |2 +-
3 files changed, 7 insertions(+), 3 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 0134237..373542b 100644
--- a/.gitignore
+++ b/.gitignore
@@ -21,3 +21,4 @@
/Socket-2.015.tar.gz
/Socket-2.016.tar.gz
/Socket-2.017.tar.gz
+/Socket-2.018.tar.gz
diff --git a/perl-Socket.spec b/perl-Socket.spec
index c9c70b2..5013672 100644
--- a/perl-Socket.spec
+++ b/perl-Socket.spec
@@ -1,6 +1,6 @@
Name: perl-Socket
Epoch: 1
-Version:2.017
+Version:2.018
Release:1%{?dist}
Summary:Networking constants and support functions
License:GPL+ or Artistic
@@ -60,7 +60,10 @@ make test
%{_mandir}/man3/*
%changelog
-* Wed Feb 11 2015 Petr Pisar ppi...@redhat.com - 2:2.017-1
+* Fri Feb 13 2015 Petr Pisar ppi...@redhat.com - 1:2.018-1
+- 2.018 bump
+
+* Wed Feb 11 2015 Petr Pisar ppi...@redhat.com - 1:2.017-1
- 2.017 bump
* Thu Oct 09 2014 Petr Pisar ppi...@redhat.com - 1:2.016-1
diff --git a/sources b/sources
index 0272cd5..e61fc15 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-829a70b5f3b4ab45205147e5eb6059de Socket-2.017.tar.gz
+d735fd2a339c4676e0e3733af327cc09 Socket-2.018.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1192381] perl-Socket-2.018 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1192381 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|ASSIGNED|MODIFIED Fixed In Version||perl-Socket-2.018-1.fc23 --- Comment #2 from Petr Pisar ppi...@redhat.com --- Fixed as perl-Socket-2.018-1.fc22 in F22. -- 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=lK96Vresfca=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: recent/new Plasma5 crashes under investigation
On 13.02.2015 15:53, Rex Dieter wrote: Rex Dieter wrote: KDE SIG is investigating some recent/serious reported crasher bugs in rawhide, notably: Could not sync environment to dbus. (startkde) https://bugzilla.redhat.com/show_bug.cgi?id=1191171 and (an older one, but the situation has gotten worse recently): Qt5 application crashes when connecting/disconnecting displays https://bugzilla.redhat.com/show_bug.cgi?id=1083664 https://bugreports.qt.io/browse/QTBUG-44388 Initial theories are that gcc5 landing may have something to do with it, since the recent crashes go away reverting to pre-gcc5 builds of the same packages. and now Qt(4) doesn't build either, bug, https://bugzilla.redhat.com/show_bug.cgi?id=1192464 Any help, advice would be appreciated (particularly input from gcc maintainers). FESCo, work on the Plasma5 change/feature is suffering due to this. I'm close to having a small test case for the Qt5 crash - hope I can file a bug by this evening/tomorrow. -- 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
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. 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. Hello, I am probably working on solving this already :), may be in a bit different way. (I'm around s390 and ppc kojis.) http://185.8.164.10/[package/tag] (location will change in about a week) Initial ideas belong to sharkcz :). It can for now just show overview of tags and package in tag across all Fedora's kojis. It is still heavy WIP. I'm now overcoming slowness of koji responsiveness using local DB synced with kojis by watching fedmsg. Overview of FTBFS is my next top priority, later with some sort of task tracking and comment system, as lot of FTBFS have common cause and affects multiple (secondary) kojis, and generally to help coordinate our resources/manpower on fixing stuff(to avoid fixing the same/similar bug up to 4 times). I will soon upload sources on github. Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Bug 1192374] perl-Dist-Zilla-Plugin-ReadmeFromPod-0.32 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1192374 --- Comment #1 from Petr Pisar ppi...@redhat.com --- Improvement suitable for F≥22. -- 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=grp0qe5vyDa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Socket/f21] 2.018 bump
commit 6cc22cd3285da0247f565813918acb3eff8e3faf
Author: Petr Písař ppi...@redhat.com
Date: Fri Feb 13 14:31:05 2015 +0100
2.018 bump
.gitignore |1 +
perl-Socket.spec |7 +--
sources |2 +-
3 files changed, 7 insertions(+), 3 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 0134237..373542b 100644
--- a/.gitignore
+++ b/.gitignore
@@ -21,3 +21,4 @@
/Socket-2.015.tar.gz
/Socket-2.016.tar.gz
/Socket-2.017.tar.gz
+/Socket-2.018.tar.gz
diff --git a/perl-Socket.spec b/perl-Socket.spec
index ee0d02d..d1e778b 100644
--- a/perl-Socket.spec
+++ b/perl-Socket.spec
@@ -1,6 +1,6 @@
Name: perl-Socket
Epoch: 1
-Version:2.017
+Version:2.018
Release:1%{?dist}
Summary:Networking constants and support functions
License:GPL+ or Artistic
@@ -60,7 +60,10 @@ make test
%{_mandir}/man3/*
%changelog
-* Wed Feb 11 2015 Petr Pisar ppi...@redhat.com - 2:2.017-1
+* Fri Feb 13 2015 Petr Pisar ppi...@redhat.com - 1:2.018-1
+- 2.018 bump
+
+* Wed Feb 11 2015 Petr Pisar ppi...@redhat.com - 1:2.017-1
- 2.017 bump
* Thu Oct 09 2014 Petr Pisar ppi...@redhat.com - 1:2.016-1
diff --git a/sources b/sources
index 0272cd5..e61fc15 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-829a70b5f3b4ab45205147e5eb6059de Socket-2.017.tar.gz
+d735fd2a339c4676e0e3733af327cc09 Socket-2.018.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1192374] perl-Dist-Zilla-Plugin-ReadmeFromPod-0.32 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1192374 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-Dist-Zilla-Plugin-Read ||meFromPod-0.32-1.fc23 Resolution|--- |NEXTRELEASE Last Closed||2015-02-13 08:41:42 --- Comment #2 from Petr Pisar ppi...@redhat.com --- Fixed as perl-Dist-Zilla-Plugin-ReadmeFromPod-0.32-1.fc22 in F22. -- 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=2fjiBwT6n2a=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Apache-LogRegex] 1.60 bump
commit 8df40713d227f390a19a3994a75a2efc3c6eecfc
Author: Petr Šabata con...@redhat.com
Date: Fri Feb 13 14:04:07 2015 +0100
1.60 bump
.gitignore|1 +
perl-Apache-LogRegex.spec |5 -
sources |2 +-
3 files changed, 6 insertions(+), 2 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index fbaacbb..b9e3e9f 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1,2 @@
/Apache-LogRegex-1.52.tar.gz
+/Apache-LogRegex-1.60.tar.gz
diff --git a/perl-Apache-LogRegex.spec b/perl-Apache-LogRegex.spec
index 74ee792..7693619 100644
--- a/perl-Apache-LogRegex.spec
+++ b/perl-Apache-LogRegex.spec
@@ -1,5 +1,5 @@
Name: perl-Apache-LogRegex
-Version:1.52
+Version:1.60
Release:1%{?dist}
Summary:Parse a line from an Apache logfile into a hash
License:GPL+ or Artistic
@@ -41,6 +41,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Fri Feb 13 2015 Petr Šabata con...@redhat.com - 1.60-1
+- 1.60 bump
+
* Tue Nov 11 2014 Petr Šabata con...@redhat.com - 1.52-1
- 1.52 bump
- Modernize spec
diff --git a/sources b/sources
index 0228628..a794b5c 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-bf8d0944bddbf6dac8164dea4ebc9277 Apache-LogRegex-1.52.tar.gz
+3f6ab3b4a12093fbcf3b2628416a8ea4 Apache-LogRegex-1.60.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File Apache-LogRegex-1.60.tar.gz uploaded to lookaside cache by psabata
A file has been added to the lookaside cache for perl-Apache-LogRegex: 3f6ab3b4a12093fbcf3b2628416a8ea4 Apache-LogRegex-1.60.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-Dist-Zilla-Plugin-ReadmeFromPod] 0.32 bump
commit 6691f37d5f9d6f8de73c6a52d3a7a1ae7e42d80a
Author: Petr Písař ppi...@redhat.com
Date: Fri Feb 13 14:17:56 2015 +0100
0.32 bump
.gitignore|1 +
perl-Dist-Zilla-Plugin-ReadmeFromPod.spec | 10 +++---
sources |2 +-
3 files changed, 9 insertions(+), 4 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 1cc13d4..af11c61 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,2 +1,3 @@
/Dist-Zilla-Plugin-ReadmeFromPod-0.21.tar.gz
/Dist-Zilla-Plugin-ReadmeFromPod-0.30.tar.gz
+/Dist-Zilla-Plugin-ReadmeFromPod-0.32.tar.gz
diff --git a/perl-Dist-Zilla-Plugin-ReadmeFromPod.spec
b/perl-Dist-Zilla-Plugin-ReadmeFromPod.spec
index b9fd833..f75d7ea 100644
--- a/perl-Dist-Zilla-Plugin-ReadmeFromPod.spec
+++ b/perl-Dist-Zilla-Plugin-ReadmeFromPod.spec
@@ -1,5 +1,5 @@
Name: perl-Dist-Zilla-Plugin-ReadmeFromPod
-Version:0.30
+Version:0.32
Release:1%{?dist}
Summary:Automatically convert POD to a README for Dist::Zilla
License:GPL+ or Artistic
@@ -16,8 +16,8 @@ BuildRequires: perl(warnings)
BuildRequires: perl(Dist::Zilla::Role::FilePruner)
BuildRequires: perl(Dist::Zilla::Role::InstallTool) = 5
BuildRequires: perl(IO::String)
+BuildRequires: perl(List::Util) = 1.33
BuildRequires: perl(Moose)
-BuildRequires: perl(Moose::Autobox)
BuildRequires: perl(Pod::Readme) = 1.1.1
# Tests:
BuildRequires: perl(File::Spec)
@@ -57,11 +57,15 @@ make pure_install DESTDIR=%{buildroot}
make test
%files
-%doc Changes LICENSE README.md
+%license LICENSE
+%doc Changes README.md
%{perl_vendorlib}/*
%{_mandir}/man3/*
%changelog
+* Fri Feb 13 2015 Petr Pisar ppi...@redhat.com - 0.32-1
+- 0.32 bump
+
* Wed Dec 10 2014 Petr Pisar ppi...@redhat.com - 0.30-1
- 0.30 bump
diff --git a/sources b/sources
index 52e1d62..aba5190 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-98513b54f70d55ae28b399e25b6e5e4c Dist-Zilla-Plugin-ReadmeFromPod-0.30.tar.gz
+3fe5436402731b966bc36571476b31b6 Dist-Zilla-Plugin-ReadmeFromPod-0.32.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File Socket-2.018.tar.gz uploaded to lookaside cache by ppisar
A file has been added to the lookaside cache for perl-Socket: d735fd2a339c4676e0e3733af327cc09 Socket-2.018.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1192381] perl-Socket-2.018 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1192381 --- Comment #3 from Fedora Update System upda...@fedoraproject.org --- perl-Socket-2.018-1.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/perl-Socket-2.018-1.fc21 -- 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=ypCoxcPblsa=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 1191491] perl-Socket-2.017 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1191491 --- Comment #4 from Fedora Update System upda...@fedoraproject.org --- perl-Socket-2.018-1.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/perl-Socket-2.018-1.fc21 -- 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=kSagiZR1DYa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Capture-Tiny] 0.28 bump
commit dc5f63fa7f33e7add5392d15ee90114ee087d44e
Author: Petr Šabata con...@redhat.com
Date: Fri Feb 13 13:48:14 2015 +0100
0.28 bump
.gitignore |1 +
perl-Capture-Tiny.spec | 25 ++---
sources|2 +-
3 files changed, 12 insertions(+), 16 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index d60d78c..d7d7211 100644
--- a/.gitignore
+++ b/.gitignore
@@ -17,3 +17,4 @@ Capture-Tiny-0.08.tar.gz
/Capture-Tiny-0.25.tar.gz
/Capture-Tiny-0.26.tar.gz
/Capture-Tiny-0.27.tar.gz
+/Capture-Tiny-0.28.tar.gz
diff --git a/perl-Capture-Tiny.spec b/perl-Capture-Tiny.spec
index 35fe730..ba923bd 100644
--- a/perl-Capture-Tiny.spec
+++ b/perl-Capture-Tiny.spec
@@ -1,5 +1,5 @@
Name: perl-Capture-Tiny
-Version:0.27
+Version:0.28
Release:1%{?dist}
Summary:Capture STDOUT and STDERR from Perl, XS or external programs
License:ASL 2.0
@@ -8,7 +8,7 @@ URL:http://search.cpan.org/dist/Capture-Tiny/
Source0:
http://www.cpan.org/authors/id/D/DA/DAGOLDEN/Capture-Tiny-%{version}.tar.gz
BuildArch: noarch
BuildRequires: perl
-BuildRequires: perl(ExtUtils::MakeMaker) = 6.17
+BuildRequires: perl(ExtUtils::MakeMaker) = 6.76
BuildRequires: perl(strict)
BuildRequires: perl(warnings)
# Run-time:
@@ -23,18 +23,10 @@ BuildRequires: perl(Scalar::Util)
# Tests only:
BuildRequires: perl(Config)
BuildRequires: perl(File::Spec::Functions)
-BuildRequires: perl(lib)
BuildRequires: perl(IO::File)
-BuildRequires: perl(List::Util)
+BuildRequires: perl(lib)
BuildRequires: perl(Test::More) = 0.62
-BuildRequires: perl(version)
-# Optional tests:
-%if !%{defined perl_bootstrap}
-BuildRequires: perl(Inline)
-BuildRequires: perl(Inline::C)
-BuildRequires: perl(Parse::RecDescent)
-%endif
-Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
+Requires: perl(:MODULE_COMPAT_%(eval $(perl -V:version); echo
$version))
%description
Capture::Tiny provides a simple, portable way to capture anything sent to
@@ -48,23 +40,26 @@ in any particular situation and just use this one.
%setup -q -n Capture-Tiny-%{version}
%build
-perl Makefile.PL INSTALLDIRS=perl
+perl Makefile.PL INSTALLDIRS=perl NO_PACKLIST=1
make %{?_smp_mflags}
%install
make pure_install DESTDIR=%{buildroot}
-find %{buildroot} -type f -name .packlist -exec rm -f {} +
%{_fixperms} %{buildroot}/*
%check
make test
%files
-%doc Changes examples LICENSE README Todo
+%license LICENSE
+%doc Changes examples README Todo
%{perl_privlib}/*
%{_mandir}/man3/*
%changelog
+* Fri Feb 13 2015 Petr Šabata con...@redhat.com - 0.28-1
+- 0.28 bump
+
* Wed Nov 12 2014 Petr Šabata con...@redhat.com - 0.27-1
- 0.27 bump
- META changes only
diff --git a/sources b/sources
index 76b7fb8..6cf153c 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-63ee233f1dfaa75c5233839407b87ae3 Capture-Tiny-0.27.tar.gz
+2923ba0524f4f42a6022f3ef1ca1913d Capture-Tiny-0.28.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-Socket] 2.018 bump
commit f24c35384866a718c5092c57675619caff858bdf
Author: Petr Písař ppi...@redhat.com
Date: Fri Feb 13 14:31:05 2015 +0100
2.018 bump
.gitignore |1 +
perl-Socket.spec |5 -
sources |2 +-
3 files changed, 6 insertions(+), 2 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 0134237..373542b 100644
--- a/.gitignore
+++ b/.gitignore
@@ -21,3 +21,4 @@
/Socket-2.015.tar.gz
/Socket-2.016.tar.gz
/Socket-2.017.tar.gz
+/Socket-2.018.tar.gz
diff --git a/perl-Socket.spec b/perl-Socket.spec
index 5300bfa..54c3d21 100644
--- a/perl-Socket.spec
+++ b/perl-Socket.spec
@@ -1,6 +1,6 @@
Name: perl-Socket
Epoch: 2
-Version:2.017
+Version:2.018
Release:1%{?dist}
Summary:Networking constants and support functions
License:GPL+ or Artistic
@@ -60,6 +60,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Fri Feb 13 2015 Petr Pisar ppi...@redhat.com - 2:2.018-1
+- 2.018 bump
+
* Wed Feb 11 2015 Petr Pisar ppi...@redhat.com - 2:2.017-1
- 2.017 bump
diff --git a/sources b/sources
index 0272cd5..e61fc15 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-829a70b5f3b4ab45205147e5eb6059de Socket-2.017.tar.gz
+d735fd2a339c4676e0e3733af327cc09 Socket-2.018.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1192381] perl-Socket-2.018 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1192381 --- Comment #1 from Petr Pisar ppi...@redhat.com --- A bug-fix release suitable for all Fedoras. -- 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=62hCH07RBOa=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: [Proposal] Ring-based Packaging Policies
On Fri, 2015-02-13 at 13:54 +0100, Ralf Corsepius wrote: On 02/13/2015 10:56 AM, Petr Spacek wrote: Modified version of Zbyszek's idea with time constraints follows: 1) Accept the new package into Fedora N even with bundled libraries. I am inclined to be Fedora needs to encounter a serious vulnerability originating from bundling, such that you guys comprehend, why bundling is utterly stupid ;) For those who don't know what I am talking about: Many years ago (IIRC, ~1999), nobody cared about static linkage or bundling. At this time, it was common to statically link and/or bundle libraries. Then a critically vulnerability was found in libz affecting all Linux distros. Nobody knew which packages all bundled and/or statically linked against different versions of libz. It took months for all Linux distributions to identify their vulnerable packages, to find solutions and to release security-fixes. Meanwhile, we've had much more critical vulnerablities in widely used libs (Remember heartbleed), which all have been quite easy to fix packaging-wise. IMO, to a great portion, thanks to having mostly banned static linkage and bundling. I'd like to point out something that I think you missed in my initial email. I'm not saying that anything should be allowed to bundle software transparently. The primary problem we faced back in '99 was that *we didn't know what was bundling libz*. With an enforced virtual Provides: bundled(foo) we can at least get an accurate listing of the set of packages that would need to be updated in the event of a vulnerability. Also, as mentioned in another thread, I'm certainly open to the idea of making some specific exceptions to the rule (such as you may not bundle packages like libz that have a long history of vulnerability). In other words, I think it might be reasonable to have bundling in the outer rings be a blacklist rather than a whitelist, so long as we can always find out with a simple repoquery what contains a package. 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: How to become a packager (was: Re: [Proposal] Ring-based Packaging Policies)
Hi On Fri, Feb 13, 2015 at 11:40 AM, Ian Malone wrote: Thanks. I think when I'd looked at it I'd discounted the review and comment on others' submissions process as it would seem to require you to have a better idea of what you're doing than the person submitting the package, and potentially just creating noise when other people are looking at it too. Yes, probably a good idea maintainers know how to package. :) You are also discounting the path of being a co-maintainer first. Random fire'n'forget builds in a public Fedora repo would be something that would scare me. This is sort of a situation we have by default, as it's simpler for people to package into the SUSE public repo. Not sure how. Please explain. If the goal is to make it easier to do fire and forget builds, then koji scratch builds and perhaps copr seems to be a good option. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[perl-CGI] 4.13 bump
commit 4e46f2b642dfafbd49ab9dbcd7a569be7fbf68e6
Author: Jitka Plesnikova jples...@redhat.com
Date: Fri Feb 13 17:13:18 2015 +0100
4.13 bump
.gitignore |1 +
CGI-4.04-Make-Test-Deep-tests-optional.patch | 39
...t-Deep-and-Test-NoWarnings-tests-optional.patch | 100
perl-CGI.spec | 24 -
sources|2 +-
5 files changed, 121 insertions(+), 45 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 32b7dd9..e860440 100644
--- a/.gitignore
+++ b/.gitignore
@@ -11,3 +11,4 @@
/CGI.pm-4.02.tar.gz
/CGI.pm-4.03.tar.gz
/CGI-4.04.tar.gz
+/CGI-4.13.tar.gz
diff --git a/CGI-4.13-Make-Test-Deep-and-Test-NoWarnings-tests-optional.patch
b/CGI-4.13-Make-Test-Deep-and-Test-NoWarnings-tests-optional.patch
new file mode 100644
index 000..83348e0
--- /dev/null
+++ b/CGI-4.13-Make-Test-Deep-and-Test-NoWarnings-tests-optional.patch
@@ -0,0 +1,100 @@
+diff -up CGI-4.13/t/param_list_context.t.orig CGI-4.13/t/param_list_context.t
+--- CGI-4.13/t/param_list_context.t.orig 2015-02-13 14:29:41.074521085
+0100
CGI-4.13/t/param_list_context.t2015-02-13 15:11:32.430400441 +0100
+@@ -4,7 +4,7 @@ use strict;
+ use warnings;
+
+ use Test::More tests = 7;
+-use Test::Deep;
++
+ use Test::Warn;
+
+ use CGI ();
+@@ -30,11 +30,15 @@ warning_like
+ calling -param with args in list context warns
+ ;
+
+-cmp_deeply(
++SKIP: {
++skip 'Test::Deep module is not available', 1 unless
++eval 'use Test::Deep 0.11; 1';
++cmp_deeply(
+ [ sort @params ],
+ [ qw/ checkers chess / ],
+ 'CGI::param()',
+-);
++);
++}
+
+ warnings_are
+ { @params = $q-multi_param('game') }
+@@ -42,11 +46,15 @@ warnings_are
+ no warnings calling multi_param
+ ;
+
+-cmp_deeply(
++SKIP: {
++skip 'Test::Deep module is not available', 1 unless
++eval 'use Test::Deep 0.11; 1';
++cmp_deeply(
+ [ sort @params ],
+ [ qw/ checkers chess / ],
+ 'CGI::multi_param'
+-);
++);
++}
+
+ $CGI::LIST_CONTEXT_WARN = 0;
+
+diff -up CGI-4.13/t/request.t.orig CGI-4.13/t/request.t
+--- CGI-4.13/t/request.t.orig 2014-12-01 10:11:15.0 +0100
CGI-4.13/t/request.t 2015-02-13 16:16:56.594560316 +0100
+@@ -4,8 +4,6 @@ use strict;
+ use warnings;
+
+ use Test::More tests = 45;
+-use Test::Deep;
+-use Test::NoWarnings;
+
+ use CGI ();
+ use Config;
+@@ -118,7 +116,9 @@ $q-_reset_globals;
+ is_deeply [ sort $q-$_( 'keywords' ) ], [ qw/ dragon tiger / ],
+ $_ keywords for qw/ param url_param /;
+
+- {
++ SKIP: {
++ skip 'Test::Deep module is not available', 3 unless
++ (eval 'use Test::Deep 0.11; 1' eval 'use
Test::NoWarnings; 1');
+ $^W++;
+
+ CGI::_reset_globals;
+diff -up CGI-4.13/t/util.t.orig CGI-4.13/t/util.t
+--- CGI-4.13/t/util.t.orig 2015-02-13 14:22:19.296463091 +0100
CGI-4.13/t/util.t 2015-02-13 14:28:16.804556263 +0100
+@@ -6,7 +6,6 @@
+ $| = 1;
+
+ use Test::More tests = 77;
+-use Test::Deep;
+ use Config;
+ use_ok ( 'CGI::Util', qw(escape unescape rearrange) );
+
+@@ -62,6 +61,10 @@ for ( 1 .. 20 ) {
+ %args,
+ );
+
++SKIP: {
++ skip 'Test::Deep module is not available', 1 unless
++ eval 'use Test::Deep 0.11; 1';
++
+ cmp_deeply(
+ [ @ordered ],
+ [
+@@ -77,5 +80,6 @@ for ( 1 .. 20 ) {
+ ],
+ 'rearrange not sensitive to hash key ordering'
+ );
++}
+ }
+
diff --git a/perl-CGI.spec b/perl-CGI.spec
index c5207f7..27dcd05 100644
--- a/perl-CGI.spec
+++ b/perl-CGI.spec
@@ -1,12 +1,12 @@
Name: perl-CGI
Summary:Handle Common Gateway Interface requests and responses
-Version:4.04
-Release:2%{?dist}
+Version:4.13
+Release:1%{?dist}
License:(GPL+ or Artistic) and Artistic 2.0
Group: Development/Libraries
Source0:
http://search.cpan.org/CPAN/authors/id/L/LE/LEEJO/CGI-%{version}.tar.gz
-# Make Test::Deep tests optional as it's not in the core in contrast to the CGI
-Patch0: CGI-4.04-Make-Test-Deep-tests-optional.patch
+# Make Test::Deep and Test::NoWarnings tests optional as it's not in the core
in contrast to the CGI
+Patch0:
CGI-4.13-Make-Test-Deep-and-Test-NoWarnings-tests-optional.patch
URL:http://search.cpan.org/dist/CGI
BuildArch: noarch
BuildRequires: perl
@@ -20,8 +20,11 @@ BuildRequires: perl(deprecate)
%endif
BuildRequires: perl(Exporter)
BuildRequires: perl(File::Spec) = 0.82
+BuildRequires: perl(File::Temp)
+BuildRequires: perl(HTML::Entities)
BuildRequires: perl(if)
BuildRequires: perl(overload)
+BuildRequires: perl(parent)
BuildRequires: perl(strict)
BuildRequires: perl(vars)
BuildRequires: perl(warnings)
@@ -29,15 +32,20 @@
[Bug 1192371] perl-CGI-4.13 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1192371 Jitka Plesnikova jples...@redhat.com changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-CGI-4.13-1.fc23 Resolution|--- |RAWHIDE Last Closed||2015-02-13 11:24:14 -- 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=Fnche74Tqja=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: Mock, Rawhide and DNF
On 13. 2. 2015 at 19:10:01, Christopher Meng wrote: On Friday, February 13, 2015, Pierre-Yves Chibon pin...@pingoured.fr wrote: On Fri, Feb 13, 2015 at 09:35:30AM +0100, Miroslav Suchy wrote: RHEL/EPEL users do not have DNF available, therefore they are unable to build packages for Fedora Rawhide. There is however a workaround. Just change this line: config_opts['package_manager'] = 'dnf' to this: config_opts['package_manager'] = 'yum' or you can simply delete it because Yum is the default. Or you can pass --yum to mock. Could it be an idea to check if /usr/bin/dnf exists (or if dnf can be found in $PATH) before calling dnf and if not a) warn the user and b) switch back to yum? This would make mock run out of the box for RHEL/EPEL users as well. Mock needs to check if /usr/bin/dnf is a file instead of a symlink as well since I've created a symlink on my system. (a little bit strange though) Not even this is going to be sufficient, as we plan to release a transition script /usr/bin/yum. This will be installed if people choose not to install yum and it will redirect user to /usr/bin/dnf, much like service redirects to systemctl. Thanks Jan -- 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 build failure: noarch vs. arch?
Jerry James wrote on 02/14/2015 12:23 AM: On Thu, Feb 12, 2015 at 9:28 AM, gil punto...@libero.it wrote: as i wrote in my e-mail titled jni libraries fails in koji i have the same problem i haven't done any changes in koji client config I tried the csdp build again this morning to see if perhaps the problem is nondeterministic. It failed again: http://koji.fedoraproject.org/koji/taskinfo?taskID=8921616 Does anybody have any idea at all why some archful packages are being treated as if they were noarch? It doesn't affect mock builds, just koji builds. Note that this fails on buildSRPMFromSCM, i.e. when creating srpm, and not on buildArch (armv7hl, i686, x86_64), where rpmbuild the newly created srpm is executed. So when using mock, usually srpm is already there on your local disc. But on koji, first koji tries to create srpm from SCM (git repository), and when creating srpm, koji uses: /usr/bin/rpmbuild -bs --target noarch --nodeps foo.spec i.e. creating srpm is always done as noarch. Then after creating srpm, arch-dependent (sometimes independent) rpmbuild foo.src.rpm is executed. Regards, Mamoru -- 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: [Proposal] Ring-based Packaging Policies
On 02/13/2015 04:51 PM, Matthew Miller wrote: On Fri, Feb 13, 2015 at 04:43:53PM +0100, Ralf Corsepius wrote: words, I think it might be reasonable to have bundling in the outer rings be a blacklist rather than a whitelist, so long as we can always find out with a simple repoquery what contains a package. To me, this idea is not helpful. All it does is to send upstreams a message which encourages to disregard the issues of bundling, to work dirty and not to care about their coding quality. I think the stark reality is that few upstreams these days care about any message we send, for or against coding quality. We're just not in a strong position there, as much as I'd love it if we were. I disagree - We need to send a message, to raise awareness about these issues (Beware the beginnigs!) and to be explict againt people who bundle. Or differently: Not-bunlding is one of the key features, which fuels Linux befamed security. If you're dropping this, we worse than Windows. 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
Cython-0.22-1.fc22 not tagged as an update candidate
Build was OK, but bodhi is giving an error: bodhi -n -r F22 -t enhancement -N 'see: https://github.com/cython/cython/blob/master/CHANGES.rst ' Cython-0.22-1.fc22 Creating a new update for Cython-0.22-1.fc22 Cython-0.22-1.fc22 not tagged as an update candidate http://koji.fedoraproject.org/koji/buildinfo?buildID=611056 -- -- Those who don't understand recursion are doomed to repeat it -- 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: Fedora 22 Mass Branching
On Fri, 13 Feb 2015 12:55:23 +0100 Mikolaj Izdebski mizde...@redhat.com wrote: On 02/12/2015 10:40 AM, Peter Robinson wrote: Is the koji rawhide repo not pointing to the new F23 builds/repo somehow? My otf2-1.5.1-1.fc23 build doesn't appear to be showing up. http://koji.fedoraproject.org/koji/taskinfo?taskID=8902498 It's pointed to f-23 just fine http://koji.fedoraproject.org/koji/buildtargetinfo?name=rawhide rawhide tag inherits from f22, not f23 $ koji taginfo rawhide Tag: rawhide [197] Arches: armv7hl i686 x86_64 Groups: LOCKED Targets that build into this tag: rawhide-repo-holder (rawhide, repo#454545: 2015-02-13 11:32:13.316963) This tag is a buildroot for one or more targets Current repo: repo#454545: 2015-02-13 11:32:13.316963 Targets that build from this tag: rawhide-repo-holder Inheritance: 1 f22 [271] Yep. This was a problem... fixed now. Tomorrow's rawhide should actually be rawhide. ;) kevin pgpUGeS4Vhb2G.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
[perl/f21] Regenerate a2p.c bug #1177672
commit 68db1ab2dac194b2ac7bfbf09e42f13610ff9ebf
Author: Jitka Plesnikova jples...@redhat.com
Date: Fri Feb 13 17:04:05 2015 +0100
Regenerate a2p.c bug #1177672
perl.spec | 14 +-
1 files changed, 13 insertions(+), 1 deletions(-)
---
diff --git a/perl.spec b/perl.spec
index 8020d2d..baa6421 100644
--- a/perl.spec
+++ b/perl.spec
@@ -30,7 +30,7 @@
Name: perl
Version:%{perl_version}
# release number must be even higher, because dual-lived modules will be
broken otherwise
-Release:305%{?dist}
+Release:306%{?dist}
Epoch: %{perl_epoch}
Summary:Practical Extraction and Report Language
Group: Development/Languages
@@ -144,6 +144,9 @@ BuildRequires: systemtap-sdt-devel
BuildRequires: gdbm-devel
%endif
+# Regenerate a2p.c bug #1177672
+BuildRequires: byacc
+
# For tests
BuildRequires: procps, rsyslog
@@ -2060,6 +2063,12 @@ rm -rf 'cpan/Memoize/Memoize/NDBM_File.pm'
sed -i '\|cpan/Memoize/Memoize/NDBM_File.pm|d' MANIFEST
%endif
+# Regenerate a2p.c bug #1177672
+pushd x2p
+yacc a2p.y
+mv -f y.tab.c a2p.c
+popd
+
%build
echo RPM Build arch: %{_arch}
@@ -3738,6 +3747,9 @@ sed \
# Old changelog entries are preserved in CVS.
%changelog
+* Fri Feb 13 2015 Jitka Plesnikova jples...@redhat.com - 4:5.18.1-306
+- Regenerate a2p.c (BZ#1177672)
+
* Thu Oct 30 2014 Petr Pisar ppi...@redhat.com - 4:5.18.4-305
- Create site paths by cpan for the first time (bug #1132321)
--
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 1177672] [abrt] perl: yyparse(): a2p killed by SIGSEGV
https://bugzilla.redhat.com/show_bug.cgi?id=1177672 --- Comment #16 from Fedora Update System upda...@fedoraproject.org --- perl-5.18.4-292.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/perl-5.18.4-292.fc20 -- 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=a3GVZwZxZba=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: Cython-0.22-1.fc22 not tagged as an update candidate
On Fri, 13 Feb 2015 11:53:09 -0500 Neal Becker ndbeck...@gmail.com wrote: Build was OK, but bodhi is giving an error: bodhi -n -r F22 -t enhancement -N 'see: https://github.com/cython/cython/blob/master/CHANGES.rst ' Cython-0.22-1.fc22 Creating a new update for Cython-0.22-1.fc22 Cython-0.22-1.fc22 not tagged as an update candidate http://koji.fedoraproject.org/koji/buildinfo?buildID=611056 Bodhi is not yet enabled for branched. It will be enabled at the bodhi enablement point in the schedule: https://fedoraproject.org/wiki/Releases/22/Schedule https://fedoraproject.org/wiki/Updates_Policy#Bodhi_enabling Until then, branched acts like rawhide. kevin pgpUBR3Fe9Ksk.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: Proposal to (formally/easily) allowing multiple versions of the same library installable
Hedayat Vatankhah wrote: It is possible, but it'll need package reviews for each new version. Yes, it is a new package so a new review will be required (for either the old-compat or the new-parallel-installable version). this requirement for an additional review is likely non-negotiable. Also, it should be probably added to packaging guidelines for library packaging as the default/recommended method (including the possible issues that might need attention, as stated in the other reply). Sure, additional documentation is always welcome. Are you willing to help write some? -- 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
[perl/f20] Regenerate a2p.c bug #1177672
commit acbbb74c8442aa623d73b82e150ffd7b9a2ad896
Author: Jitka Plesnikova jples...@redhat.com
Date: Fri Feb 13 17:04:05 2015 +0100
Regenerate a2p.c bug #1177672
perl.spec | 14 +-
1 files changed, 13 insertions(+), 1 deletions(-)
---
diff --git a/perl.spec b/perl.spec
index 630b198..60fee9a 100644
--- a/perl.spec
+++ b/perl.spec
@@ -31,7 +31,7 @@
Name: perl
Version:%{perl_version}
# release number must be even higher, because dual-lived modules will be
broken otherwise
-Release:291%{?dist}
+Release:292%{?dist}
Epoch: %{perl_epoch}
Summary:Practical Extraction and Report Language
Group: Development/Languages
@@ -132,6 +132,9 @@ BuildRequires: systemtap-sdt-devel
BuildRequires: gdbm-devel
%endif
+# Regenerate a2p.c bug #1177672
+BuildRequires: byacc
+
# For tests
BuildRequires: procps, rsyslog
@@ -1979,6 +1982,12 @@ rm -rf 'cpan/Memoize/Memoize/NDBM_File.pm'
sed -i '\|cpan/Memoize/Memoize/NDBM_File.pm|d' MANIFEST
%endif
+# Regenerate a2p.c bug #1177672
+pushd x2p
+yacc a2p.y
+mv -f y.tab.c a2p.c
+popd
+
%build
echo RPM Build arch: %{_arch}
@@ -3621,6 +3630,9 @@ sed \
# Old changelog entries are preserved in CVS.
%changelog
+* Fri Feb 13 2015 Jitka Plesnikova jples...@redhat.com - 4:5.18.1-292
+- Regenerate a2p.c (BZ#1177672)
+
* Thu Oct 30 2014 Petr Pisar ppi...@redhat.com - 4:5.18.4-291
- Create site paths by cpan for the first time (bug #1132321)
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File CGI-4.13.tar.gz uploaded to lookaside cache by jplesnik
A file has been added to the lookaside cache for perl-CGI: 1de46434384fc0e59da6b6b407130c20 CGI-4.13.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-CGI/f22] 4.13 bump
commit 0e2038f2f5976ede4e2c7cc549d96b7e24607827
Author: Jitka Plesnikova jples...@redhat.com
Date: Fri Feb 13 17:13:18 2015 +0100
4.13 bump
.gitignore |1 +
CGI-4.04-Make-Test-Deep-tests-optional.patch | 39
...t-Deep-and-Test-NoWarnings-tests-optional.patch | 100
perl-CGI.spec | 24 -
sources|2 +-
5 files changed, 121 insertions(+), 45 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 32b7dd9..e860440 100644
--- a/.gitignore
+++ b/.gitignore
@@ -11,3 +11,4 @@
/CGI.pm-4.02.tar.gz
/CGI.pm-4.03.tar.gz
/CGI-4.04.tar.gz
+/CGI-4.13.tar.gz
diff --git a/CGI-4.13-Make-Test-Deep-and-Test-NoWarnings-tests-optional.patch
b/CGI-4.13-Make-Test-Deep-and-Test-NoWarnings-tests-optional.patch
new file mode 100644
index 000..83348e0
--- /dev/null
+++ b/CGI-4.13-Make-Test-Deep-and-Test-NoWarnings-tests-optional.patch
@@ -0,0 +1,100 @@
+diff -up CGI-4.13/t/param_list_context.t.orig CGI-4.13/t/param_list_context.t
+--- CGI-4.13/t/param_list_context.t.orig 2015-02-13 14:29:41.074521085
+0100
CGI-4.13/t/param_list_context.t2015-02-13 15:11:32.430400441 +0100
+@@ -4,7 +4,7 @@ use strict;
+ use warnings;
+
+ use Test::More tests = 7;
+-use Test::Deep;
++
+ use Test::Warn;
+
+ use CGI ();
+@@ -30,11 +30,15 @@ warning_like
+ calling -param with args in list context warns
+ ;
+
+-cmp_deeply(
++SKIP: {
++skip 'Test::Deep module is not available', 1 unless
++eval 'use Test::Deep 0.11; 1';
++cmp_deeply(
+ [ sort @params ],
+ [ qw/ checkers chess / ],
+ 'CGI::param()',
+-);
++);
++}
+
+ warnings_are
+ { @params = $q-multi_param('game') }
+@@ -42,11 +46,15 @@ warnings_are
+ no warnings calling multi_param
+ ;
+
+-cmp_deeply(
++SKIP: {
++skip 'Test::Deep module is not available', 1 unless
++eval 'use Test::Deep 0.11; 1';
++cmp_deeply(
+ [ sort @params ],
+ [ qw/ checkers chess / ],
+ 'CGI::multi_param'
+-);
++);
++}
+
+ $CGI::LIST_CONTEXT_WARN = 0;
+
+diff -up CGI-4.13/t/request.t.orig CGI-4.13/t/request.t
+--- CGI-4.13/t/request.t.orig 2014-12-01 10:11:15.0 +0100
CGI-4.13/t/request.t 2015-02-13 16:16:56.594560316 +0100
+@@ -4,8 +4,6 @@ use strict;
+ use warnings;
+
+ use Test::More tests = 45;
+-use Test::Deep;
+-use Test::NoWarnings;
+
+ use CGI ();
+ use Config;
+@@ -118,7 +116,9 @@ $q-_reset_globals;
+ is_deeply [ sort $q-$_( 'keywords' ) ], [ qw/ dragon tiger / ],
+ $_ keywords for qw/ param url_param /;
+
+- {
++ SKIP: {
++ skip 'Test::Deep module is not available', 3 unless
++ (eval 'use Test::Deep 0.11; 1' eval 'use
Test::NoWarnings; 1');
+ $^W++;
+
+ CGI::_reset_globals;
+diff -up CGI-4.13/t/util.t.orig CGI-4.13/t/util.t
+--- CGI-4.13/t/util.t.orig 2015-02-13 14:22:19.296463091 +0100
CGI-4.13/t/util.t 2015-02-13 14:28:16.804556263 +0100
+@@ -6,7 +6,6 @@
+ $| = 1;
+
+ use Test::More tests = 77;
+-use Test::Deep;
+ use Config;
+ use_ok ( 'CGI::Util', qw(escape unescape rearrange) );
+
+@@ -62,6 +61,10 @@ for ( 1 .. 20 ) {
+ %args,
+ );
+
++SKIP: {
++ skip 'Test::Deep module is not available', 1 unless
++ eval 'use Test::Deep 0.11; 1';
++
+ cmp_deeply(
+ [ @ordered ],
+ [
+@@ -77,5 +80,6 @@ for ( 1 .. 20 ) {
+ ],
+ 'rearrange not sensitive to hash key ordering'
+ );
++}
+ }
+
diff --git a/perl-CGI.spec b/perl-CGI.spec
index c5207f7..27dcd05 100644
--- a/perl-CGI.spec
+++ b/perl-CGI.spec
@@ -1,12 +1,12 @@
Name: perl-CGI
Summary:Handle Common Gateway Interface requests and responses
-Version:4.04
-Release:2%{?dist}
+Version:4.13
+Release:1%{?dist}
License:(GPL+ or Artistic) and Artistic 2.0
Group: Development/Libraries
Source0:
http://search.cpan.org/CPAN/authors/id/L/LE/LEEJO/CGI-%{version}.tar.gz
-# Make Test::Deep tests optional as it's not in the core in contrast to the CGI
-Patch0: CGI-4.04-Make-Test-Deep-tests-optional.patch
+# Make Test::Deep and Test::NoWarnings tests optional as it's not in the core
in contrast to the CGI
+Patch0:
CGI-4.13-Make-Test-Deep-and-Test-NoWarnings-tests-optional.patch
URL:http://search.cpan.org/dist/CGI
BuildArch: noarch
BuildRequires: perl
@@ -20,8 +20,11 @@ BuildRequires: perl(deprecate)
%endif
BuildRequires: perl(Exporter)
BuildRequires: perl(File::Spec) = 0.82
+BuildRequires: perl(File::Temp)
+BuildRequires: perl(HTML::Entities)
BuildRequires: perl(if)
BuildRequires: perl(overload)
+BuildRequires: perl(parent)
BuildRequires: perl(strict)
BuildRequires: perl(vars)
BuildRequires: perl(warnings)
@@ -29,15 +32,20 @@
Re: How to become a packager (was: Re: [Proposal] Ring-based Packaging Policies)
On 13 February 2015 at 15:35, Michael Schwendt mschwe...@gmail.com wrote: On Fri, 13 Feb 2015 14:00:07 +, Ian Malone wrote: Actually, a question I have about this is how it will impact people trying to become maintainers. When I last checked (it may have changed) the only way to do that was to create a new package. That isn't the only way to become a packager. And it hasn't changed for a very long time: https://fedoraproject.org/wiki/Category:Package_Maintainers - https://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group Submitting a new package is just _one_ of multiple ways to find a sponsor, since it is an opportunity to demonstrate that you know packaging. Thanks. I think when I'd looked at it I'd discounted the review and comment on others' submissions process as it would seem to require you to have a better idea of what you're doing than the person submitting the package, and potentially just creating noise when other people are looking at it too. Yes, probably a good idea maintainers know how to package. :) Random fire'n'forget builds in a public Fedora repo would be something that would scare me. This is sort of a situation we have by default, as it's simpler for people to package into the SUSE public repo. -- imalone http://ibmalone.blogspot.co.uk -- 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 build failure: noarch vs. arch?
On Sat, 14 Feb 2015 00:45:50 +0900
Mamoru TASAKA mtas...@fedoraproject.org wrote:
Note that this fails on buildSRPMFromSCM, i.e. when creating srpm,
and not on buildArch (armv7hl, i686, x86_64), where rpmbuild the
newly created srpm is executed.
So when using mock, usually srpm is already there on your local disc.
But on koji, first koji tries to create srpm from SCM (git
repository), and when creating srpm, koji uses:
/usr/bin/rpmbuild -bs --target noarch --nodeps foo.spec
i.e. creating srpm is always done as noarch. Then after creating srpm,
arch-dependent (sometimes independent) rpmbuild foo.src.rpm is
executed.
This is not the case. Please see the earlier posts in this thread. ;)
I think this might be a mock bug.
http://koji.fedoraproject.org/koji/taskinfo?taskID=8921617
% koji mock-config --task 8921617 | grep target
config_opts['target_arch'] = 'x86_64'
but yet:
ENTER do(['bash', '--login', '-c', '/usr/bin/rpmbuild -bs --target noarch
--nodeps /builddir/build/SPECS/csdp.spec'],
chrootPath='/var/lib/mock/f23-build-2951435-454610/root'shell=FalseprintOutput=Falseenv={'LANG':
'en_US.UTF-8', 'TERM': 'vt100', 'SHELL': '/bin/bash', 'HOSTNAME': 'mock',
'PROMPT_COMMAND': 'printf \x1b]0;mock-chroot\x07mock-chroot', 'HOME':
'/builddir', 'PATH':
'/usr/bin:/bin:/usr/sbin:/sbin'}gid=425user='mockbuild'timeout=86400logger=mockbuild.trace_decorator.getLog
object at 0x7fdce02535d0uid=1000)
Executing command: ['bash', '--login', '-c', '/usr/bin/rpmbuild -bs --target
noarch --nodeps /builddir/build/SPECS/csdp.spec'] with env {'LANG':
'en_US.UTF-8', 'TERM': 'vt100', 'SHELL': '/bin/bash', 'HOSTNAME': 'mock',
'PROMPT_COMMAND': 'printf \x1b]0;mock-chroot\x07mock-chroot', 'HOME':
'/builddir', 'PATH': '/usr/bin:/bin:/usr/sbin:/sbin'} and shell False
Can you file a bug against mock and we can see if the mock maintainers
can track it down?
kevin
pgpKMeQeahAd3.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: Proposal to (formally/easily) allowing multiple versions of the same library installable
Rex Dieter wrote: Sure, additional documentation is always welcome. Are you willing to help write some? My apologies, re-reading the whole thread, including the initial post, I see you did have a specific proposal... to which I responded separately to a couple of points (but otherwise, a good start). -- 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: Proposal to (formally/easily) allowing multiple versions of the same library installable
On Fri, 13 Feb 2015 15:21:17 +0330 Hedayat Vatankhah hedayat@gmail.com wrote: Dear all, I don't know if this has been discussed before, but I didn't find any. ...snip... Proposal: let's make it possible to have multiple versions of the same library installed, as far as their .so version permits that. 1. Include the base version of the library into its package name. So, instead of libfoo we can have libfoo2, libfoo3, libfoo4. 2. No reviews are required for new libfooX packages (as it is not required right now when you update your libfoo package). But the thing is, it's really difficult to get right details about the new package. Forget to change a name somewhere or a provides or obsoletes. People mess this up all the time. Also, this would vary library to library. Some things change slowly and only support 1 release, some things (cough *ffmpeg*) change version every release. So in some cases 3 is too many, and in others not enough. 3. For each Fedora release, there is libfoo/libfoo-devel packages which Require the default version of libfoo packages for that release. For example, libfoo.fc20/libfoo-devel.fc20 will Require libfoo2/libfoo2-devel; for F21 libfoo3/libfoo3-devel and for F22/Rawhide libfoo4/libfoo4-devel. So, you would need t move these 'default' provides to different versions on different branches? Doable, but again, someone could merge back a change and mess up this, so it sounds pretty delicate. ...snip... For -devel packages, two methods can be allowed: 1. Simple: -devel packages conflict with each other, so while you can have multiple versions of libfoo installed, you can have only a single version of libfoo-devel installed Bad idea. Conflicts are horrible and to be avoided. 2. Flexible: Provide the possibility of installing multiple -devel versions, and a method to select the default one, like the alternatives system. More complexity... but also there is: 3. What we do today: make sure all versions are parallel installable. More details can be discussed, but I think it's enough for now. I want to see what others think about the whole idea. Details can be worked out if the idea seems interesting. Q: Can't a packager do it already? Why propose it as a 'proposal'? A: Yes, he can, but it'll be hard; mainly because he'll need to put new versions of the library for review. Also, I suggest it as a 'recommended practice' for packaging libraries. So, the gist of the proposal is to avoid reviewing new compat packages? Is this really such a burden? IMHO, this method will have many advantages, and can make it much easier to provide COPR repositories or similar to experiment with new things on a stable Fedora release without affecting other installed software. Also, it might make it possible to install and experiment with some packages from Rawhide/next Fedora release directly on your current release. As a developer, it makes the version of available libraries for development less bounded to Fedora version. kevin pgpLCjwt_7Qci.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: MongoDB Security Defaults
On 02/13/2015 11:25 AM, Frank Ch. Eigler wrote: Ryan S. Brown rya...@redhat.com writes: [...] In January, the Fedora rawhide package for mongo[2] was changed to listen on all interfaces by default [...] To help protect users, I think the default should be changed back to localhost only. [...] We have a slew of network-servers in the fedora distribution. Apprx. none of them are supposed to be turned on just by virtue of rpm installation (so, require an explicit systemctl enable), and apprx. none of them get through the system-default firewalld setup. The out-of-the-box risk is therefore nil. As far as the firewall setup: if they wouldn't get through the firewall, then there's already extra configuration for operators that want to make it available to everyone. Why not also have it listen by default on localhost as an additional safety measure. Especially since *that's how it is in all current releases*. There's no benefit to moving away from the (sane) default of localhost-only. If you'd like to pursue a distro-wide change for this interface-binding level of security, please consider pursuing it via a Fedora Change type process rather than piecemeal package-by-package. I didn't consider this as a distro-wide change, I'll look at the existing policies and see if there are any that cover this. -- Ryan Brown / Software Engineer, Openstack / Red Hat, Inc. -- 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 build failure: noarch vs. arch?
a fix for this problem is:
(see
http://pkgs.fedoraproject.org/cgit/java-service-wrapper.git/tree/java-service-wrapper.spec
)
# rpmbuild 4.6 support
%if ! 0%{?__isa_bits}
%ifarch x86_64 ia64 ppc64 sparc64 s390x alpha ppc64le aarch64
%global __isa_bits 64
%else
%global __isa_bits 32
%endif
%endif
Il 13/02/2015 19:11, Kevin Fenzi ha scritto:
On Sat, 14 Feb 2015 00:45:50 +0900
Mamoru TASAKA mtas...@fedoraproject.org wrote:
Note that this fails on buildSRPMFromSCM, i.e. when creating srpm,
and not on buildArch (armv7hl, i686, x86_64), where rpmbuild the
newly created srpm is executed.
So when using mock, usually srpm is already there on your local disc.
But on koji, first koji tries to create srpm from SCM (git
repository), and when creating srpm, koji uses:
/usr/bin/rpmbuild -bs --target noarch --nodeps foo.spec
i.e. creating srpm is always done as noarch. Then after creating srpm,
arch-dependent (sometimes independent) rpmbuild foo.src.rpm is
executed.
This is not the case. Please see the earlier posts in this thread. ;)
I think this might be a mock bug.
http://koji.fedoraproject.org/koji/taskinfo?taskID=8921617
% koji mock-config --task 8921617 | grep target
config_opts['target_arch'] = 'x86_64'
but yet:
ENTER do(['bash', '--login', '-c', '/usr/bin/rpmbuild -bs --target noarch --nodeps
/builddir/build/SPECS/csdp.spec'],
chrootPath='/var/lib/mock/f23-build-2951435-454610/root'shell=FalseprintOutput=Falseenv={'LANG':
'en_US.UTF-8', 'TERM': 'vt100', 'SHELL': '/bin/bash', 'HOSTNAME': 'mock', 'PROMPT_COMMAND': 'printf
\x1b]0;mock-chroot\x07mock-chroot', 'HOME': '/builddir', 'PATH':
'/usr/bin:/bin:/usr/sbin:/sbin'}gid=425user='mockbuild'timeout=86400logger=mockbuild.trace_decorator.getLog
object at 0x7fdce02535d0uid=1000)
Executing command: ['bash', '--login', '-c', '/usr/bin/rpmbuild -bs --target noarch --nodeps
/builddir/build/SPECS/csdp.spec'] with env {'LANG': 'en_US.UTF-8', 'TERM': 'vt100', 'SHELL':
'/bin/bash', 'HOSTNAME': 'mock', 'PROMPT_COMMAND': 'printf
\x1b]0;mock-chroot\x07mock-chroot', 'HOME': '/builddir', 'PATH':
'/usr/bin:/bin:/usr/sbin:/sbin'} and shell False
Can you file a bug against mock and we can see if the mock maintainers
can track it down?
kevin
--
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: [Proposal] Ring-based Packaging Policies
On 02/12/2015 07:32 PM, Stephen Gallagher wrote: Second, I will call attention to the fact that different Fedora users have very different needs from the software. For example, those running Fedora Server and Fedora Cloud are likely far more concerned with Fedora as a *deployment* platform than they are as a *development* platform. Folks running Fedora Workstation or the KDE spin are likely to be somewhat more interested in the development side of things (though not exclusively). Fedora Workstation includes very, very few development-related packages, to the degree that it is completely unusable (by itself) for almost all developers. Many important development tools are completely outside the Fedora.Next package set. Previously, they were just a “yum install” away, and there was little difference in practice. I'm worried that this proposal will have a negative affect on the quality of non-core packages (over time at least). === Core Packages === Any package that is provided on a release-blocking medium (which at present includes Fedora Atomic, Fedora Cloud, Fedora Server, Fedora Workstation, the KDE Spin and several ARM images) must comply exactly with the packaging guidelines as they are written today. These packages must receive a full package review *when they are added to the install media*. Any package present on the media if this proposal is adopted is exempted from this requirement. Any package to newly appear on the install media after this time *should* (I hate that word...) receive a new package review, even if it is already present in Fedora. Based on the comments above, I think the definition is much too narrow. It excludes fundamental development infrastructure such as autoconf and cmake, and tools like gdb and valgrind. I have nothing against the proposal in principle (to some extent, it just reflects existing practice), but I do think we need a different definition for the set of core packages. By the way, this cuts in the other direction as well—I think the proposed definition makes Docker and Kubernetes core packages (at least eventually), and I think its developers really, really want a wide-ranging bundling exception. -- Florian Weimer / Red Hat Product Security -- 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: [Proposal] Ring-based Packaging Policies
On 13 February 2015 at 09:05, Ralf Corsepius rc040...@freenet.de wrote: On 02/13/2015 04:51 PM, Matthew Miller wrote: On Fri, Feb 13, 2015 at 04:43:53PM +0100, Ralf Corsepius wrote: words, I think it might be reasonable to have bundling in the outer rings be a blacklist rather than a whitelist, so long as we can always find out with a simple repoquery what contains a package. To me, this idea is not helpful. All it does is to send upstreams a message which encourages to disregard the issues of bundling, to work dirty and not to care about their coding quality. I think the stark reality is that few upstreams these days care about any message we send, for or against coding quality. We're just not in a strong position there, as much as I'd love it if we were. I disagree - We need to send a message, to raise awareness about these issues (Beware the beginnigs!) and to be explict againt people who bundle. Or differently: Not-bunlding is one of the key features, which fuels Linux befamed security. If you're dropping this, we worse than Windows. How do we send this message? Because it is clear other people are out of ideas on how to do this in a way that software that people want to use care about. -- 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
[Test-Announce] 2015-02-16 @ 1700 UTC ** Fedora Blocker Review Meeting
# F22 Blocker Review meeting # Date: 2015-02-16 # Time: 1700 UTC # Location: #fedora-blocker-review on irc.freenode.net It's Blocker Review time again! While we don't yet have an Alpha TC to test, testing against rawhide has continued. The results have yielded a couple proposed blockers: 3 Alpha and 2 Final. If you want to take a look at the proposed or accepted blockers, the full list can be found here: https://qa.fedoraproject.org/blockerbugs/ Make sure to click through the milestones to see how many we have before the meeting! We'll be evaluating these bugs to see if they violate any of the Release Criteria and warrant the blocking of a release if they're not fixed. Information on the release criteria for F22 can be found on the wiki [0]. For more information about the Blocker and Freeze exception process, check out these links: - https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process - https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process And for those of you who are curious how a Blocker Review Meeting works - or how it's supposed to go and you want to run one - check out the SOP on the wiki: - https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting Have a good weekend and see you Monday! [0] https://fedoraproject.org/wiki/Fedora_Release_Criteria -- // Mike -- Fedora QA freenode: roshi http://roshi.fedorapeople.org ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Mass Fortran rebuilds due to new GCC?
I need FORTRAN for R and R packages - if it's not 100% for the R ecosystme I'd consider any bugs to be at least blockers for beta, if not alpha. On Fri, Feb 13, 2015 at 12:59 PM, Björn Esser bjoern.es...@gmail.com wrote: Am Freitag, den 13.02.2015, 13:53 -0700 schrieb Kevin Fenzi: On Fri, 13 Feb 2015 12:47:07 -0800 Susi Lehtola jussileht...@fedoraproject.org wrote: Hi, as has happened many times before, the GCC bump in rawhide has broken all Fortran packages, desperately needing a mass rebuild. Can you expand on the breakage? Is it that they no longer rebuild? Or that they no longer run? I think, he's talking about the fact they are segfaulting… ;) Unfortunately, rpm is blissfully unaware of any breakage happening (BZ #1192617) so maintainers won't even know when this breakage happens. Before I start rebuilding packages, are there any plans to do the rebuilds soon..? There is no mass rebuild this cycle. It would be good to isolate the scope here and see what needs to be rebuilt. Do you have a list of all affected packages or a way to come up with one? Why is mass rebuild skipped this time? For this particular case it is: repoquery --whatrequires libgfortran Cheers, Björn -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- OSJourno: Robust Power Tools for Digital Journalists http://www.znmeb.mobi/stories/osjourno-robust-power-tools-for-digital-journalists Remember, if you're traveling to Bactria, Hump Day is Tuesday and Thursday. -- 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: Mass Fortran rebuilds due to new GCC?
On Fri, Feb 13, 2015 at 01:53:12PM -0700, Kevin Fenzi wrote: On Fri, 13 Feb 2015 12:47:07 -0800 Susi Lehtola jussileht...@fedoraproject.org wrote: as has happened many times before, the GCC bump in rawhide has broken all Fortran packages, desperately needing a mass rebuild. Can you expand on the breakage? Is it that they no longer rebuild? Or that they no longer run? The ABI has not changed, libgfortran is backwards compatible, the only thing that changed is (as with any GCC version bump) the *.mod file format. Not all Fortran packages ship modules... Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Mass Fortran rebuilds due to new GCC?
On Fri, 13 Feb 2015 12:47:07 -0800 Susi Lehtola jussileht...@fedoraproject.org wrote: Hi, as has happened many times before, the GCC bump in rawhide has broken all Fortran packages, desperately needing a mass rebuild. Can you expand on the breakage? Is it that they no longer rebuild? Or that they no longer run? Unfortunately, rpm is blissfully unaware of any breakage happening (BZ #1192617) so maintainers won't even know when this breakage happens. Before I start rebuilding packages, are there any plans to do the rebuilds soon..? There is no mass rebuild this cycle. It would be good to isolate the scope here and see what needs to be rebuilt. Do you have a list of all affected packages or a way to come up with one? kevin pgpcV0mjohQg_.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
[389-devel] please review: Ticket 48003 - Start building lib389 test suite in 389 DS
This patch started writing the test suite for 389 DS. Eventually all of TET will be ported to lib389 tests in 389 DS. https://fedorahosted.org/389/ticket/48003 https://fedorahosted.org/389/attachment/ticket/48003/0001-Ticket-48003-build-suite-framework.patch -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: [Proposal] Ring-based Packaging Policies
On Fri, Feb 13, 2015 at 6:06 AM, Michael Schwendt mschwe...@gmail.com wrote: On Thu, 12 Feb 2015 16:49:13 -0500, Stephen Gallagher wrote: Ultimately, it's about one thing: Help get more software into Fedora without scaring people away. What is the background for this? Who has been scared away? Here's one review where the submitter worked very hard to jump through all the hoops until it came to the FPC bundling exception process. It's my opinion that Carlos would be a Fedora package maintainer today if that FPC process hadn't taken so long. https://bugzilla.redhat.com/682544 In IRC, I've seen other users abandon ship earlier, once the prospective developers are told that their goal of packaging X in Fedora or EPEL would require doing some work to unbundle some library. It's hardly a theoretical problem. I have no idea of the scope, of course, but it does happen. For myself, I believe in unbundling libraries, and I believe Linux distros like Fedora and Debian contribute a great deal to the health of the overall FOSS ecosystem. Certain upstream developers enjoy lambasting distributions regarding bundling policies, and I wish these same developers could step back and acknowledge how many patches and improvements have also come upstream as a result of the distros' work (unbundling work included). Matt, you mentioned in another email in this thread that upstreams don't care about the messages that we send. I agree that some upstreams don't care about certain classes of problems, but they do care about others. For example, XBMC hates that we've unbundled ffmpeg, but on the other hand, they're quite happy to take our patches to fix format-string bugs that Fedora's GCC defaults bring to light. Things are not all rosy, but they're not all bleak, either. Here's the new policy that I would vote for: 1) We allow bundled libraries, and each bundled library MUST have a virtual Provides: bundled(foo) in the RPM spec. (The packager SHOULD provide a version number too, with the admission that it is sometimes difficult to get this number correct.) 2) If another packager comes up with a patch to unbundle the library and files the patch in Bugzilla, then the package maintainer MUST take the patch. 3) If the package maintainer disagrees with the patch for whatever reason (maybe it's a feature regression, or whatever), they MUST bring it to the FPC for arbitration. The FPC must take into account the loss of functionality that unbundling could imply. This revised policy would lower the barrier to entry for newcomers, and still leave room for more advanced contributors to do the work if they desired to do so. - Ken -- 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: [Proposal] Ring-based Packaging Policies
On Fri, 13 Feb 2015 17:45:23 -0700, Ken Dreyer wrote: On Thu, 12 Feb 2015 16:49:13 -0500, Stephen Gallagher wrote: Ultimately, it's about one thing: Help get more software into Fedora without scaring people away. What is the background for this? Who has been scared away? Here's one review where the submitter worked very hard to jump through all the hoops until it came to the FPC bundling exception process. It's my opinion that Carlos would be a Fedora package maintainer today if that FPC process hadn't taken so long. https://bugzilla.redhat.com/682544 So, everybody's grief is just the unbundling policy? Is that the only thing that scares away people? Everything related to this proposal is only because of bundling? Here's the new policy that I would vote for: 1) We allow bundled libraries, and each bundled library MUST have a virtual Provides: bundled(foo) in the RPM spec. (The packager SHOULD provide a version number too, with the admission that it is sometimes difficult to get this number correct.) 2) If another packager comes up with a patch to unbundle the library and files the patch in Bugzilla, then the package maintainer MUST take the patch. 3) If the package maintainer disagrees with the patch for whatever reason (maybe it's a feature regression, or whatever), they MUST bring it to the FPC for arbitration. The FPC must take into account the loss of functionality that unbundling could imply. This revised policy would lower the barrier to entry for newcomers, and still leave room for more advanced contributors to do the work if they desired to do so. Isn't the combination of 2) and 3) a potential threat that will scare away the maintainer again? (especially if upstream doesn't accept the patch) -- 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-DBD-CSV] 0.48 bump
commit 8289ee15033124e5d91d0102221d917ea16e71b0
Author: Petr Šabata con...@redhat.com
Date: Fri Feb 13 13:09:59 2015 +0100
0.48 bump
perl-DBD-CSV.spec | 12 +++-
sources |2 +-
2 files changed, 8 insertions(+), 6 deletions(-)
---
diff --git a/perl-DBD-CSV.spec b/perl-DBD-CSV.spec
index 5cad68e..30acb19 100644
--- a/perl-DBD-CSV.spec
+++ b/perl-DBD-CSV.spec
@@ -1,5 +1,5 @@
Name: perl-DBD-CSV
-Version:0.46
+Version:0.48
Release:1%{?dist}
Summary:DBI driver for CSV files
Group: Development/Libraries
@@ -8,7 +8,7 @@ URL:http://search.cpan.org/dist/DBD-CSV/
Source0:
http://search.cpan.org/CPAN/authors/id/H/HM/HMBRAND/DBD-CSV-%{version}.tgz
BuildArch: noarch
BuildRequires: perl
-BuildRequires: perl(ExtUtils::MakeMaker)
+BuildRequires: perl(ExtUtils::MakeMaker) = 6.76
BuildRequires: perl(File::Spec)
BuildRequires: perl(lib)
BuildRequires: perl(strict)
@@ -29,7 +29,7 @@ BuildRequires: perl(charnames)
BuildRequires: perl(Cwd)
BuildRequires: perl(Encode)
BuildRequires: perl(Test::More) = 0.90
-Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
+Requires: perl(:MODULE_COMPAT_%(eval $(perl -V:version); echo
$version))
Requires: perl(DBD::File) = 0.42
Requires: perl(DBI) = 1.628
Requires: perl(SQL::Statement) = 1.405
@@ -51,12 +51,11 @@ MS Excel data.
chmod -c a-x ChangeLog README lib/DBD/*.pm lib/Bundle/DBD/*.pm
%build
-perl Makefile.PL INSTALLDIRS=vendor
+perl Makefile.PL INSTALLDIRS=vendor NO_PACKLIST=1
make %{?_smp_mflags}
%install
make pure_install DESTDIR=%{buildroot}
-find %{buildroot} -type f -name .packlist -exec rm -f {} +
%{_fixperms} %{buildroot}
%check
@@ -70,6 +69,9 @@ make test
%exclude %{perl_vendorlib}/DBI/Test
%changelog
+* Fri Feb 13 2015 Petr Šabata con...@redhat.com - 0.48-1
+- 0.48 bump
+
* Sun Nov 16 2014 Paul Howarth p...@city-fan.org - 0.46-1
- 0.46 bump
diff --git a/sources b/sources
index 7c28186..b8e1ff3 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-80c898d34920b50a6b958a06734eef2f DBD-CSV-0.46.tgz
+11391a868171dfe493f0a907d8c33596 DBD-CSV-0.48.tgz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File DBD-CSV-0.48.tgz uploaded to lookaside cache by psabata
A file has been added to the lookaside cache for perl-DBD-CSV: 11391a868171dfe493f0a907d8c33596 DBD-CSV-0.48.tgz -- 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
