Re: gdbm license change
On 12/12/2011 07:15 PM, Toshio Kuratomi wrote: On Mon, Dec 12, 2011 at 06:08:53PM +0100, Honza Horak wrote: On 12/09/2011 10:01 PM, Tom Callaway wrote: On 11/15/2011 03:19 AM, Honza Horak wrote: If there are some license issues not easy to solve, there is still a compat-gdbm package, which ships gdbm-1.8.3 with GPLv2+. The problem is that compat-gdbm has no -devel package, and we cannot use the gdbm-devel package for this. Since Thorsten Kukuk is unwilling to relicense ypserv to resolve the licensing conflict, we are left with the following options: * Modify compat-gdbm to have a true -devel package (this will almost certainly require namespacing it somehow, like libgdbm_old.so) I like this one, since it seems to be the easiest solution from my POV. Be wary of making a quick estimate of the amount of work involved here. Taking on a true compat-gdbm for this role means that you would be taking over code that is no longer supported by upstream for an indefinite time period. You would then be responsible for solving all bugs in the package and fixing them yourself. There might also be a legal line that needs to be observed here as the gdbm-1.8.x maintainer cannot use GPLv3+ code (the new gdbm) to help make fixes to the GPLv2+ code so it may be that you actually cannot maintain both packages yourself probably should discuss with spot just what would be okay in this case. To me, the easiest solution for you is probably going to be dropping ypserv from the distribution. But if that's not possible, then attempting to convince the gdbm upstream to switch back to GPLv2+ would likely be a worthwhile investment. I've asked gdbm upstream to do so, waiting for response right now. Dropping ypserv isn't possible because there is no alternative for NIS server. Honza But I don't see necessary to solve conflicts using renaming library and header files. I'd rather just let compat-gdbm-devel and gdbm-devel sub-packages to conflict (use Conflicts: explicitly), since it doesn't make sense to me to have both packages installed at the same time (base packages won't conflict). Then we don't have to change anything but Requires: in packages like ypserv. Please, let me know if you see any problems when solving that this way. The Fedora Packaging Guidelines forbid this. http://fedoraproject.org/wiki/Packaging:Conflicts ( IIRC, this was last revisited this year and it was decided that the guideline should continue to prohibit Conflicts. You're welcome to bring it up again but you would probably want to find the packaging meeting notes where relaxing the conflicts guideline was discussed and be sure that you're bringing new ideas to the table instead of rehashing the ones already discussed.) -Toshio -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes from today's FESCO meeting (2011-12-12 at 1800 UTC)
Dne 12.12.2011 21:16, Ken Dreyer napsal(a): On Mon, Dec 12, 2011 at 12:24 PM, Stephen Gallaghersgall...@redhat.com wrote: * #715 Provenpackager education/status/brainstorming (sgallagh, 18:43:02) There was some discussion a while back about preventing certain extensions from being uploaded to the lookaside cache. Could .patch be added to that list? - Ken .spec should be added to black list especially. Vit -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: P2P Packaging/Koji Cloud
On 12/07/2011 06:20 PM, Denis Arnaud wrote: As a side note, rather than using Snap (and Augeas, and...), we (in my department) tend to prefer Chef (http://www.opscode.com/chef/), which has got a broader scope, and allows much more complex configurations and automation tasks. Denis Chef, like puppet, is a great tool. But it is somewhat different than Snap, Augeas, etc. With chef, puppet, etc. The end user sets up centralized recipes which describe what systems should look like, how they behave, etc. With Snap, you have an existing system which you would like to use as the basis to replicate at some later point (either locally or elsewhere). In any case, slightly off topic, but Snap is now in Fedora (well updates-testing, will be pushed to updates at the end of this week, sooner if I can get +1 karma). Plus alot more features have gone in / are being pushed, including much expanded documentation, a test harness, and the start of the ability to migrate snapshots between hosts (eg backup an Ubuntu system, restore on Fedora). Stay tuned for more updates! -Mo -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Tips on how to handle tmpfile changes
On Wed, 07.12.11 09:37, Michael Cronenworth (m...@cchtml.com) wrote: The vnstat service has traditionally run as the root user. This was fixed in Fedora 16 and higher to run as the vnstat user, but the same fix was just introduced[1] into Fedora 15. There is a problem with this fix in that it requires systemd-tmpfiles to be run to create the new /run/vnstat directory required to store the pid file. This new directory also required the /etc/vnstat.conf file to be changed as the PidFile variable tells vnstat where to create the pid file. The end result is that after a package update the service will fail to start unless they manually create the /run/vnstat directory and update their config file. Not a very nice requirement IMO. 1. Is it appropriate for the RPM to call systemd-tmpfiles or is there a better way to create the new tmpfile directory? Yes, systemd-tmpfiles is considered part of the systemd ABI and thus stable and documented (systemd-tmpfiles(8)). If you want to run it from a spec file, do so with a command line like this: systemd-tmpfiles --create /usr/lib/tmpfiles.d/vnstat.conf Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ARPACK soname bump [Was Re: ARPACK - Change of upstream]
FYI, ARPACK 3.0, featuring a soname bump, has been built in rawhide. If it becomes necessary, I'll build the update in released branches as well. -- Jussi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes from today's FESCO meeting (2011-12-12 at 1800 UTC)
On Tue, 2011-12-13 at 14:06 -0500, J. Bruce Fields wrote: On Mon, Dec 12, 2011 at 01:22:06PM -0800, Toshio Kuratomi wrote: To some extent I agree with both sgallagh's sentiment and the logical conclusion you're drawing. However, I think the lookaside cache is a necessary optimization/compromise to the ideal of putting everything into version control, though. Current technology would make it prohibitive in terms of packager time (and for some packages, space on developer's machines) to put tarballs into git as the cloned repository would then contain every single new tarball the package ever had. I'd be curious to know how expensive that actually was. I'd think delta-compression could make it quite reasonable for the typical project. (Exceptions including things like games with lots of binary data in each release.) Nearly all packages are released as a compressed tarball. So any change in the package is likely to result in a delta of the binary image that is close enough to 100% as makes no difference. signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
File CPAN-Meta-YAML-0.005.tar.gz uploaded to lookaside cache by pghmcfc
A file has been added to the lookaside cache for perl-CPAN-Meta-YAML: b006f77a16aac0c471ed17c52e1ca648 CPAN-Meta-YAML-0.005.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-CPAN-Meta-YAML] Update to 0.005
commit 88d25ef80da6ff4cae87a69afb45134eccc9ed7e
Author: Paul Howarth p...@city-fan.org
Date: Tue Dec 13 19:49:48 2011 +
Update to 0.005
- New upstream release 0.005
- Fix documentation to clarify that users are responsible for UTF-8
encoding/decoding
.gitignore |3 +--
perl-CPAN-Meta-YAML.spec |7 ++-
sources |2 +-
3 files changed, 8 insertions(+), 4 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 2191ce1..0e7046c 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,2 +1 @@
-/CPAN-Meta-YAML-0.003.tar.gz
-/CPAN-Meta-YAML-0.004.tar.gz
+/CPAN-Meta-YAML-[0-9.]*.tar.gz
diff --git a/perl-CPAN-Meta-YAML.spec b/perl-CPAN-Meta-YAML.spec
index 1ad267e..e4a24c7 100644
--- a/perl-CPAN-Meta-YAML.spec
+++ b/perl-CPAN-Meta-YAML.spec
@@ -5,7 +5,7 @@
%global old_test_more %(perl -MTest::More -e 'print (($Test::More::VERSION
0.88) ? 1 : 0);' 2/dev/null || echo 0)
Name: perl-CPAN-Meta-YAML
-Version: 0.004
+Version: 0.005
Release: 1%{?dist}
Summary: Read and write a subset of YAML for CPAN Meta files
License: GPL+ or Artistic
@@ -74,6 +74,11 @@ rm -rf %{buildroot}
%{_mandir}/man3/CPAN::Meta::YAML.3pm*
%changelog
+* Tue Dec 13 2011 Paul Howarth p...@city-fan.org - 0.005-1
+- Update to 0.005:
+ - Fix documentation to clarify that users are responsible for UTF-8
+encoding/decoding
+
* Wed Sep 7 2011 Paul Howarth p...@city-fan.org - 0.004-1
- Update to 0.004:
- Generated from ADAMK/YAML-Tiny-1.50.tar.gz
diff --git a/sources b/sources
index c0cb032..855a1f2 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-120025b9fd39b9dbfeb6ffc5f4a2dd8d CPAN-Meta-YAML-0.004.tar.gz
+b006f77a16aac0c471ed17c52e1ca648 CPAN-Meta-YAML-0.005.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-CPAN-Meta-YAML] Created tag perl-CPAN-Meta-YAML-0.005-1.fc17
The lightweight tag 'perl-CPAN-Meta-YAML-0.005-1.fc17' was created pointing to: 88d25ef... Update to 0.005 -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 760472] Upgrade to new upstream version
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=760472 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #4 from Fedora Update System upda...@fedoraproject.org 2011-12-13 14:57:57 EST --- Package perl-Directory-Queue-1.4-1.el6: * should fix your issue, * was pushed to the Fedora EPEL 6 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=epel-testing perl-Directory-Queue-1.4-1.el6' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-EPEL-2011-5226/perl-Directory-Queue-1.4-1.el6 then log in and leave karma (feedback). -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
update of python-markdown
Hi, this is a heads up that I plan on updating python-markdown to the latest version 2.1.0 in rawhide within the next days; please test whether your package still works as expected after the update. There are some backward-incompatible changes, see https://github.com/waylan/Python-Markdown/blob/2.1.0.final/docs/release-2.1.0.md . Affected packages: % repoquery --repoid=rawhide-source --archlist=src --whatrequires python-markdown lastuser-0:0.1-3.20110724gitf41a49.fc17.src python-cheetah-0:2.4.4-2.fc15.src transifex-0:1.1.0-4.fc17.src % repoquery --repoid=rawhide --whatrequires python-markdown bodhi-server-0:0.8.5-1.fc17.noarch python-cheetah-0:2.4.4-2.fc15.x86_64 timeline-0:0.14.0-3.fc17.noarch transifex-0:1.1.0-4.fc17.noarch -- Thomas Moschny thomas.mosc...@gmail.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes from today's FESCO meeting (2011-12-12 at 1800 UTC)
On Tue, Dec 13, 2011 at 02:12:30PM -0500, Stephen Gallagher wrote: On Tue, 2011-12-13 at 14:06 -0500, J. Bruce Fields wrote: On Mon, Dec 12, 2011 at 01:22:06PM -0800, Toshio Kuratomi wrote: To some extent I agree with both sgallagh's sentiment and the logical conclusion you're drawing. However, I think the lookaside cache is a necessary optimization/compromise to the ideal of putting everything into version control, though. Current technology would make it prohibitive in terms of packager time (and for some packages, space on developer's machines) to put tarballs into git as the cloned repository would then contain every single new tarball the package ever had. I'd be curious to know how expensive that actually was. I'd think delta-compression could make it quite reasonable for the typical project. (Exceptions including things like games with lots of binary data in each release.) Nearly all packages are released as a compressed tarball. So any change in the package is likely to result in a delta of the binary image that is close enough to 100% as makes no difference. You'd want to uncompress before checking in. Or even expand before checking in--git diff and git grep would then be a lot more useful. You'd no longer have a copy of exactly what you downloaded, but someone with a copy of the download could mechanically verify that you'd imported the same content. You could still keep the .tar.gz in the lookaside cache, but you wouldn't normally need to go look at it. --b. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora 14 End of Life
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 As of 09 December 2011, Fedora 14 has reached its end of life for updates and support. No further updates, including security updates, will be available for Fedora 14. A previous reminder was sent on November 8th [0]. Fedora 15 will continue to receive updates until approximately one month after the release of Fedora 17. The maintenance schedule of Fedora releases is documented on the Fedora Project wiki [1]. The Fedora Project wiki also contains instructions [2] on how to upgrade from a previous release of Fedora to a version receiving updates. Dennis [0] http://lists.fedoraproject.org/pipermail/announce/2011-November/003010.html [1] https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle#Maintenance_Schedule [2] http://fedoraproject.org/wiki/DistributionUpgrades -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) iEYEARECAAYFAk7nu/oACgkQkSxm47BaWfcIzQCeLak/LN1R9eCsDpyHNHyybqkD v+kAoLQmOGjqbwY9bbU3IbEuo4xb24tz =FJuU -END PGP SIGNATURE- ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes from today's FESCO meeting (2011-12-12 at 1800 UTC)
On Tue, Dec 13, 2011 at 9:53 PM, J. Bruce Fields bfie...@redhat.com wrote: On Tue, Dec 13, 2011 at 02:12:30PM -0500, Stephen Gallagher wrote: On Tue, 2011-12-13 at 14:06 -0500, J. Bruce Fields wrote: On Mon, Dec 12, 2011 at 01:22:06PM -0800, Toshio Kuratomi wrote: To some extent I agree with both sgallagh's sentiment and the logical conclusion you're drawing. However, I think the lookaside cache is a necessary optimization/compromise to the ideal of putting everything into version control, though. Current technology would make it prohibitive in terms of packager time (and for some packages, space on developer's machines) to put tarballs into git as the cloned repository would then contain every single new tarball the package ever had. I'd be curious to know how expensive that actually was. I'd think delta-compression could make it quite reasonable for the typical project. (Exceptions including things like games with lots of binary data in each release.) Nearly all packages are released as a compressed tarball. So any change in the package is likely to result in a delta of the binary image that is close enough to 100% as makes no difference. You'd want to uncompress before checking in. Or even expand before checking in--git diff and git grep would then be a lot more useful. You'd no longer have a copy of exactly what you downloaded, but someone with a copy of the download could mechanically verify that you'd imported the same content. You could still keep the .tar.gz in the lookaside cache, but you wouldn't normally need to go look at it. What's the benefit of all the overhead (=growing size of the repos and doing this as an extra step, not just uploading the tarball)? Adding a VCS key [1] to the spec, so you can look at the uncompressed source, which all of vcs diff/grep, makes more sense to me. (This only assumes upstreams repo will stay reachable.) Unpackaging the tarball and adding a lot of data to the git repository only makes it bigger and bigger and you can't really compare that git repo to the upstream one (Maybe sharing some patches, but I guess no pull etc will work). Greetings, Tom [1] http://fedoraproject.org/wiki/User:Walters/Packaging_VCS_key_proposal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 767147] New: perl-MooseX-Types-DateTime-ButMaintained-0.13 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: perl-MooseX-Types-DateTime-ButMaintained-0.13 is available https://bugzilla.redhat.com/show_bug.cgi?id=767147 Summary: perl-MooseX-Types-DateTime-ButMaintained-0.13 is available Product: Fedora Version: rawhide Platform: Unspecified OS/Version: Unspecified Status: NEW Keywords: FutureFeature, Triaged Severity: unspecified Priority: unspecified Component: perl-MooseX-Types-DateTime-ButMaintained AssignedTo: mmasl...@redhat.com ReportedBy: upstream-release-monitor...@fedoraproject.org QAContact: extras...@fedoraproject.org CC: fedora-perl-devel-l...@redhat.com, mmasl...@redhat.com Classification: Fedora Story Points: --- Type: --- Regression: --- Mount Type: --- Documentation: --- Latest upstream release: 0.13 Current version in Fedora Rawhide: 0.11 URL: http://search.cpan.org/dist/MooseX-Types-DateTime-ButMaintained/ 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 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File MooseX-Types-DateTime-ButMaintained-0.13.tar.gz uploaded to lookaside cache by psabata
A file has been added to the lookaside cache for perl-MooseX-Types-DateTime-ButMaintained: 0683177e7791c7c6dff12b3e0faa735e MooseX-Types-DateTime-ButMaintained-0.13.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-MooseX-Types-DateTime-ButMaintained] 0.13 bump
commit e8512057083973386506822cb1a37aa2811eeff6
Author: Petr Šabata con...@redhat.com
Date: Tue Dec 13 14:45:56 2011 +0100
0.13 bump
.gitignore|1 +
perl-MooseX-Types-DateTime-ButMaintained.spec | 37 +++-
sources |2 +-
3 files changed, 19 insertions(+), 21 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 8bcb9de..36bbb85 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1,2 @@
MooseX-Types-DateTime-ButMaintained-0.11.tar.gz
+/MooseX-Types-DateTime-ButMaintained-0.13.tar.gz
diff --git a/perl-MooseX-Types-DateTime-ButMaintained.spec
b/perl-MooseX-Types-DateTime-ButMaintained.spec
index 52759dc..8ff16a7 100644
--- a/perl-MooseX-Types-DateTime-ButMaintained.spec
+++ b/perl-MooseX-Types-DateTime-ButMaintained.spec
@@ -1,27 +1,27 @@
Name: perl-MooseX-Types-DateTime-ButMaintained
-Version:0.11
-Release:6%{?dist}
+Version:0.13
+Release:1%{?dist}
Summary:DateTime related constraints and coercions for Moose
License:GPL+ or Artistic
Group: Development/Libraries
URL:
http://search.cpan.org/dist/MooseX-Types-DateTime-ButMaintained/
Source0:
http://www.cpan.org/authors/id/E/EC/ECARROLL/MooseX-Types-DateTime-ButMaintained-%{version}.tar.gz
-BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch: noarch
BuildRequires: perl(DateTime)
BuildRequires: perl(DateTime::Locale)
BuildRequires: perl(DateTime::TimeZone) = 0.96
BuildRequires: perl(ExtUtils::MakeMaker)
BuildRequires: perl(Moose) = 0.41
-BuildRequires: perl(MooseX::Types) = 0.04
-BuildRequires: perl(namespace::clean) = 0.08
+BuildRequires: perl(MooseX::Types) = 0.30
+BuildRequires: perl(MooseX::Types::Moose) = 0.30
+BuildRequires: perl(namespace::autoclean)
BuildRequires: perl(Olson::Abbreviations)
+# Tests
+BuildRequires: perl(Locale::Maketext)
+BuildRequires: perl(Moose::Util::TypeConstraints)
BuildRequires: perl(Test::Exception) = 0.27
BuildRequires: perl(Test::More)
BuildRequires: perl(Test::use::ok) = 0.02
-Requires: perl(Moose) = 0.41
-Requires: perl(MooseX::Types) = 0.04
-Requires: perl(namespace::clean) = 0.08
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
%description
@@ -37,28 +37,25 @@ PERL5_CPANPLUS_IS_RUNNING=1 %{__perl} Makefile.PL
INSTALLDIRS=vendor
make %{?_smp_mflags}
%install
-rm -rf $RPM_BUILD_ROOT
-
-make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT
-
-find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
-find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2/dev/null \;
-
-%{_fixperms} $RPM_BUILD_ROOT/*
+make pure_install PERL_INSTALL_ROOT=%{buildroot}
+find %{buildroot} -type f -name .packlist -exec rm -f {} \;
+find %{buildroot} -depth -type d -exec rmdir {} 2/dev/null \;
+%{_fixperms} %{buildroot}/*
%check
make test
-%clean
-rm -rf $RPM_BUILD_ROOT
-
%files
-%defattr(-,root,root,-)
%doc Changes
%{perl_vendorlib}/*
%{_mandir}/man3/*
%changelog
+* Tue Dec 13 2011 Petr Šabata con...@redhat.com - 0.13-1
+- 0.13 bump
+- Remove now obsolete Buildroot and defattr
+- Removing runtime deps since they get autodetected (including versions) now
+
* Tue Jul 19 2011 Petr Sabata con...@redhat.com - 0.11-6
- Perl mass rebuild
diff --git a/sources b/sources
index d5c3d84..acbf5ed 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-7dacf16bfedf3910247000e006be5b15
MooseX-Types-DateTime-ButMaintained-0.11.tar.gz
+0683177e7791c7c6dff12b3e0faa735e
MooseX-Types-DateTime-ButMaintained-0.13.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 767147] perl-MooseX-Types-DateTime-ButMaintained-0.13 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=767147 Petr Šabata psab...@redhat.com changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-MooseX-Types-DateTime- ||ButMaintained-0.13-1.fc17 Resolution||RAWHIDE Last Closed||2011-12-13 08:58:38 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File Devel-Comments-v1.1.4.tar.gz uploaded to lookaside cache by ppisar
A file has been added to the lookaside cache for perl-Devel-Comments: fd83e3fbad70bcd911acd4d0343da7e2 Devel-Comments-v1.1.4.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-Devel-Comments] Import
commit c9fdab2584523f51aa5017995cb2e9704fd1984e
Author: Petr Písař ppi...@redhat.com
Date: Tue Dec 13 16:00:50 2011 +0100
Import
.gitignore |1 +
perl-Devel-Comments.spec | 68 ++
sources |1 +
3 files changed, 70 insertions(+), 0 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index e69de29..5383b38 100644
--- a/.gitignore
+++ b/.gitignore
@@ -0,0 +1 @@
+/Devel-Comments-v1.1.4.tar.gz
diff --git a/perl-Devel-Comments.spec b/perl-Devel-Comments.spec
new file mode 100644
index 000..39fdbc5
--- /dev/null
+++ b/perl-Devel-Comments.spec
@@ -0,0 +1,68 @@
+Name: perl-Devel-Comments
+Version:1.1.4
+Release:1%{?dist}
+Summary:Debug with executable smart comments to logs
+License:GPL+ or Artistic
+Group: Development/Libraries
+URL:http://search.cpan.org/dist/Devel-Comments/
+Source0:
http://www.cpan.org/authors/id/X/XI/XIONG/developer-tools/Devel-Comments-v%{version}.tar.gz
+BuildArch: noarch
+# Compile-time:
+BuildRequires: perl(Module::Build)
+# Run-time:
+BuildRequires: perl(Carp)
+BuildRequires: perl(Data::Dumper)
+BuildRequires: perl(Filter::Simple) = 0.8
+BuildRequires: perl(IO::Capture::Tie_STDx)
+BuildRequires: perl(IO::Capture::Stdout)
+BuildRequires: perl(List::Util)
+BuildRequires: perl(Text::Balanced) = 2
+BuildRequires: perl(version) = 0.77
+# Tests only:
+BuildRequires: perl(lib)
+BuildRequires: perl(Test::More) = 0.94
+BuildRequires: perl(Test::Deep)
+BuildRequires: perl(Try::Tiny)
+BuildRequires: perl(IO::Capture::Stderr::Extended)
+BuildRequires: perl(IO::Capture::Stdout::Extended)
+Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
+Requires: perl(Filter::Simple) = 0.8
+Requires: perl(Test::More) = 0.94
+Requires: perl(Text::Balanced) = 2
+
+# Remove under-specifed dependencies
+%global __requires_exclude
%{?__requires_exclude:%__requires_exclude|}^perl\\(Filter::Simple|Text::Balanced\\)\\s*$
+
+%description
+Devel::Comments is a source filter for your Perl code, intended to be used
+only during development. Specially-formatted 'smart' comments are replaced by
+executable code to dump variables to screen or to file, display loop progress
+bars, or enforce conditions. These smart comments can all be disabled at once
+by commenting out the use Devel::Comments line, whereupon they return to
+being simple, dumb comments. Your debugging code can remain in place,
+guaranteed harmless, ready for the next development cycle.
+
+%prep
+%setup -q -n Devel-Comments-v%{version}
+
+%build
+%{__perl} Build.PL installdirs=vendor
+./Build
+
+%install
+./Build install destdir=$RPM_BUILD_ROOT create_packlist=0
+find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2/dev/null \;
+%{_fixperms} $RPM_BUILD_ROOT/*
+
+%check
+./Build test
+
+%files
+%doc Changes README
+%{perl_vendorlib}/*
+%{_mandir}/man3/*
+
+%changelog
+* Mon Dec 12 2011 Petr Pisar ppi...@redhat.com 1.1.4-1
+- Specfile autogenerated by cpanspec 1.78.
+- Remove BuildRoot and defattr from spec code.
diff --git a/sources b/sources
index e69de29..c701aa9 100644
--- a/sources
+++ b/sources
@@ -0,0 +1 @@
+fd83e3fbad70bcd911acd4d0343da7e2 Devel-Comments-v1.1.4.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 Mail-IMAPClient-3.30.tar.gz uploaded to lookaside cache by nb
A file has been added to the lookaside cache for perl-Mail-IMAPClient: a1965d99f1e25bab580e19e6546f433d Mail-IMAPClient-3.30.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-Mail-IMAPClient] Upgrade to 3.30
commit 061ba596562fb7ddd12c0816be93d1be8cda8a5a
Author: Nick Bebout n...@fedoraproject.org
Date: Tue Dec 13 17:13:04 2011 -0600
Upgrade to 3.30
.gitignore|1 +
perl-Mail-IMAPClient.spec |7 +--
sources |2 +-
3 files changed, 7 insertions(+), 3 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index be0936f..c4be2b4 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,3 +1,4 @@
Mail-IMAPClient-3.25.tar.gz
/Mail-IMAPClient-3.27.tar.gz
/Mail-IMAPClient-3.28.tar.gz
+/Mail-IMAPClient-3.30.tar.gz
diff --git a/perl-Mail-IMAPClient.spec b/perl-Mail-IMAPClient.spec
index 3ec2ea2..8baa2e1 100644
--- a/perl-Mail-IMAPClient.spec
+++ b/perl-Mail-IMAPClient.spec
@@ -1,6 +1,6 @@
Name: perl-Mail-IMAPClient
-Version:3.28
-Release:2%{?dist}
+Version:3.30
+Release:1%{?dist}
Summary:An IMAP Client API
Group: Development/Libraries
License:GPL+ or Artistic
@@ -52,6 +52,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*.3*
%changelog
+* Tue Dec 13 2011 Nick Bebout n...@fedoraproject.org - 3.30-1
+- Upgrade to 3.30
+
* Mon Jun 20 2011 Marcela Mašláňová mmasl...@redhat.com - 3.28-2
- Perl mass rebuild
diff --git a/sources b/sources
index 5cb958a..ee6cb17 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-32cad582491bff59817e45fb39736a9d Mail-IMAPClient-3.28.tar.gz
+a1965d99f1e25bab580e19e6546f433d Mail-IMAPClient-3.30.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-Mail-IMAPClient/f15] (2 commits) ...Upgrade to 3.30
Summary of changes: 81337ec... Perl mass rebuild (*) 061ba59... Upgrade to 3.30 (*) (*) 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-Mail-IMAPClient/f16] Upgrade to 3.30
Summary of changes: 061ba59... Upgrade to 3.30 (*) (*) 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
Fedora 14 End of Life
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 As of 09 December 2011, Fedora 14 has reached its end of life for updates and support. No further updates, including security updates, will be available for Fedora 14. A previous reminder was sent on November 8th [0]. Fedora 15 will continue to receive updates until approximately one month after the release of Fedora 17. The maintenance schedule of Fedora releases is documented on the Fedora Project wiki [1]. The Fedora Project wiki also contains instructions [2] on how to upgrade from a previous release of Fedora to a version receiving updates. Dennis [0] http://lists.fedoraproject.org/pipermail/announce/2011-November/003010.html [1] https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle#Maintenance_Schedule [2] http://fedoraproject.org/wiki/DistributionUpgrades -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) iEYEARECAAYFAk7nu/oACgkQkSxm47BaWfcIzQCeLak/LN1R9eCsDpyHNHyybqkD v+kAoLQmOGjqbwY9bbU3IbEuo4xb24tz =FJuU -END PGP SIGNATURE- ___ devel-announce mailing list devel-announce@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce
