Re: Broken dependencies: perl-MooseX-Role-Matcher
On Mon, Sep 12, 2011 at 2:13 PM, build...@fedoraproject.org wrote: perl-MooseX-Role-Matcher has broken dependencies in the F-16 tree: On x86_64: perl-MooseX-Role-Matcher-0.05-2.fc15.noarch requires perl(:MODULE_COMPAT_5.12.4) On i386: perl-MooseX-Role-Matcher-0.05-2.fc15.noarch requires perl(:MODULE_COMPAT_5.12.4) Please resolve this as soon as possible. Hmm... I couldn't build the package - the error from fedpkg build like already built. -- With Best Regards, Andy Shevchenko -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Broken dependencies: perl-MooseX-Role-Matcher
On Mon, Sep 12, 2011 at 2:22 PM, Emmanuel Seyman emmanuel.sey...@club-internet.fr wrote: Hmm... I couldn't build the package - the error from fedpkg build like already built. You need to bump the release number up a notch if you want to rebuild a package. The problem is there is a _new_ package. It was something wrong during creation it for F16 branch. Now, I'm just wondering how to avoid stupid work of unnecessary bumping (by the way in two branches) release number. -- With Best Regards, Andy Shevchenko -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Broken dependencies: perl-MooseX-Role-Matcher
On Mon, Sep 12, 2011 at 2:51 PM, Iain Arnell iarn...@gmail.com wrote: On Mon, Sep 12, 2011 at 1:17 PM, Andy Shevchenko andy.shevche...@gmail.com wrote: On Mon, Sep 12, 2011 at 2:13 PM, build...@fedoraproject.org wrote: perl-MooseX-Role-Matcher has broken dependencies in the F-16 tree: On x86_64: perl-MooseX-Role-Matcher-0.05-2.fc15.noarch requires perl(:MODULE_COMPAT_5.12.4) On i386: perl-MooseX-Role-Matcher-0.05-2.fc15.noarch requires perl(:MODULE_COMPAT_5.12.4) Please resolve this as soon as possible. Hmm... I couldn't build the package - the error from fedpkg build like already built. Looks like you just need to submit the f16 build to bodhi. I thought so, but there is no f16 build available in bodhi. -- With Best Regards, Andy Shevchenko -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Broken dependencies: perl-MooseX-Role-Matcher
On Mon, Sep 12, 2011 at 6:38 PM, Iain Arnell iarn...@gmail.com wrote: Looks like you just need to submit the f16 build to bodhi. I thought so, but there is no f16 build available in bodhi. The build is tagged trashcan so I'm not sure you can still do that. Can you untrash it with koji tag-pkg f16-updates-candidate perl-MooseX-Role-Matcher-0.05-2.fc16? Then bodhi submission should work. Oh, thanks. It seems to work. At least I have submitted an update via fedpkg update. -- With Best Regards, Andy Shevchenko -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [renrot] Comment out Requires(hint)
On Mon, Jun 20, 2011 at 12:32 PM, Petr Sabata psab...@fedoraproject.org wrote: Comment out Requires(hint) +- Commenting Requires(hint) out since fedpkg refuses to work with it From my point of view it looks like a problem in fedpkg rather than in a package. What is the background of intentional reducing the functionality of the rpm and package itself? -- With Best Regards, Andy Shevchenko -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [renrot] Comment out Requires(hint)
On Mon, Jun 20, 2011 at 2:13 PM, Florian Festi ffe...@redhat.com wrote: On 06/20/2011 01:01 PM, Paul Howarth wrote: I believe it's rpm 4.9 that objects to Requires(hint), not fedpkg itself. Previous RPM versions accepted arbitrary flags within the parentheses. This clearly is a bug that was fixed with rpm 4.9. Requires(hint) never worked (same for Requires(Pony)). Does it mean we are still don't have suggestions? Anyway, it seems more proper to get it fixed is to put normal Request tag instead of Request(smth). Isn't it? -- With Best Regards, Andy Shevchenko -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re:
On Sat, Jun 11, 2011 at 7:20 AM, Sergio Belkin seb...@gmail.com wrote: ./configure LDFLAGS=-no-install snip configure:3659: gcc -no-install conftest.c 5 gcc: error: unrecognized option '-no-install' I've found an example here: It's useful if someone wants to avoid the wrappers generation (look at the end): http://www.flameeyes.eu/autotools-mythbuster/libtool/wrappers.html Perhaps ./configure LDFLAGS=-no-install is somewhat heterodox Official page of autotools tells nothing like that example: http://sources.redhat.com/autobook/autobook/autobook_89.html I guess it makes sense only as make option, not configure. -- With Best Regards, Andy Shevchenko -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Adding patches in a SPEC
You need to do patch on top of source tree container mycoolpkg-5.3/ /Makefile /source.c ... mycoolpkg-5.3.new/ /Makefile /source.c ... run diff -ruN -p mycoolpkg-5.3 mycoolpkg-5.3.new Another way: mycoolpkg-5.3/ /Makefile /Makefile.orig ... gendiff mycoolpkg-5.3 .orig mycoolpkg-fix.patch On Tue, Nov 16, 2010 at 5:43 PM, Eric Sparks Christensen spa...@fedoraproject.org wrote: I've never had to add a patch to a SPEC file before and I can't seem to make it work. The patch is to make a modification to the Makefile. I created the patch (diff -u) and put that in my SOURCES directory. I included the Patch0: line and then called the patch in %prep using %patch0 (no switches). When I run rpmbuild I get the following: [u...@system rpmbuild]$ rpmbuild -ba SPECS/gpredict.spec Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.ILyyD6 + umask 022 + cd /home/user/rpmbuild/BUILD + LANG=C + export LANG + unset DISPLAY + cd /home/user/rpmbuild/BUILD + rm -rf gpredict-1.2 + /usr/bin/gzip -dc /home/user/rpmbuild/SOURCES/gpredict-1.2.tar.gz + /bin/tar -xf - + STATUS=0 + '[' 0 -ne 0 ']' + cd gpredict-1.2 + /bin/chmod -Rf a+rX,u+w,g-w,o-w . + echo 'Patch #0 (gpredict-1.2-DSO.patch):' Patch #0 (gpredict-1.2-DSO.patch): + /bin/cat /home/user/rpmbuild/SOURCES/gpredict-1.2-DSO.patch + /usr/bin/patch -s -p0 --fuzz=0 The text leading up to this was: -- |--- Makefile 2010-11-15 20:07:20.676418835 -0500 |+++ Makefile 2010-11-15 21:35:53.803407014 -0500 -- File to patch: It appears to not find Makefile. Most likely I'm just failing to do something correctly here. Can someone point me in the proper direction? Thanks, Eric -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- With Best Regards, Andy Shevchenko -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: bugzilla bugzappers?
As far as I understand the process you might just recheck your bug report against last official release and bump version in the corresponding field if the bug is still reproducible. Otherwise, no-one is interested to improve 2-3years old _desktop_ system. On Wed, Nov 3, 2010 at 10:41 PM, Bert Desmet b...@devnox.be wrote: hi! This is something I got in my mail box today. As I don't have a valid answer for this, maybe someone else can answer for me? cheers, Bert the url of the blog of the guy: http://www.krisbuytaert.be/blog/ == the mail == Dear Fedoracommunity, Over the course of the day I recieved 22^3 mails from your friendly Bug Zapper. Most of those bugs where bugs I had reported upon crashes using bug-buddy. Bugs on different desktop tools such as .. synergy, evolution, gwibber , gnome-settings and probably some others I do understand that I development goes on and on .. and your fancy devs don't care anymore about bugs I reported on Fedora 12 as they are all hacking on Fedora 15. But what I don't get is that non of these bugs was ever touched, they've been automatically created , and automatically closed a href=http://tieguy.org/blog/2004/09/;Luis/a already told us ages ago .. that every project needs a bugmaster apparently Fedora replaced that bugmaster with a Bug Zapper. So can someone please explain my why I should continue to try to improve Fedora by reporting bugs ? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- With Best Regards, Andy Shevchenko -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: orphan most of my packages
On Mon, Oct 11, 2010 at 11:39 AM, Pavel Alexeev (aka Pahan-Hubbitus) fo...@hubbitus.com.ru wrote: I took uniconvertor it is needed for ImageMagick. jfyi: new version of it requires the sk1libs package which is absent (still?) in Fedora. Additionally I have some patches for older version. I could send them to you if you want. uniconvertor -- Universal vector graphics translator Thanks. -- With Best Regards, Andy Shevchenko -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Upgrade Banshee to 1.8.0 in F13
Agree if the maintainer enables the MPRISv2 support there. On Mon, Oct 11, 2010 at 7:20 PM, Nathaniel McCallum nathan...@natemccallum.com wrote: I'd like to propose that we upgrade banshee (and banshee-community-extensions) to 1.8.0 in F13. I estimate that this will close about half our open bugs. Doing this will require the following package upgrades in F13: * clutter-sharp - Upgrade (I'm pretty sure Banshee is the only user) * gio-sharp - New * gudev-sharp - New * gkeyfile-sharp - New * gtk-sharp-beans - New * libgpod - Upgrade (0.7.93 0.7.95; bugfix release) The only thing complicated here is the buildroot override requirement and making sure that we ship the new banshee-community-extensions in the same update as the new banshee. Currently, I do not think it is feasible to backport this to F12, so F13 would be the latest version. Thoughts? Comments? Nathaniel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- With Best Regards, Andy Shevchenko -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Upgrade Banshee to 1.8.0 in F13
There is the file in the source tree called 'Banshee.Mpris.addin.xml'. It contains plugin info (? sorry, I'm not familiar with c# projects at all), where defaultEnabled=false And commit which brought that support tells the same by default it's disabled On Mon, Oct 11, 2010 at 8:00 PM, Nathaniel McCallum nathan...@natemccallum.com wrote: I don't actually see that as a build option in either banshee or banshee-community-extensions. Am I missing something? Nathaniel On 10/11/2010 12:38 PM, Andy Shevchenko wrote: Agree if the maintainer enables the MPRISv2 support there. On Mon, Oct 11, 2010 at 7:20 PM, Nathaniel McCallum nathan...@natemccallum.com wrote: I'd like to propose that we upgrade banshee (and banshee-community-extensions) to 1.8.0 in F13. I estimate that this will close about half our open bugs. Doing this will require the following package upgrades in F13: * clutter-sharp - Upgrade (I'm pretty sure Banshee is the only user) * gio-sharp - New * gudev-sharp - New * gkeyfile-sharp - New * gtk-sharp-beans - New * libgpod - Upgrade (0.7.93 0.7.95; bugfix release) The only thing complicated here is the buildroot override requirement and making sure that we ship the new banshee-community-extensions in the same update as the new banshee. Currently, I do not think it is feasible to backport this to F12, so F13 would be the latest version. Thoughts? Comments? Nathaniel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- With Best Regards, Andy Shevchenko -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Upgrade Banshee to 1.8.0 in F13
Ah, if I understand correctly you don't need to do anything. It's just default which is off, and could be on by user demand. But, it would be better to have the default is on. On Mon, Oct 11, 2010 at 8:18 PM, Nathaniel McCallum nathan...@natemccallum.com wrote: Christian, do you have any objections to enabling this? Nathaniel On 10/11/2010 01:16 PM, Andy Shevchenko wrote: There is the file in the source tree called 'Banshee.Mpris.addin.xml'. It contains plugin info (? sorry, I'm not familiar with c# projects at all), where defaultEnabled=false And commit which brought that support tells the same by default it's disabled On Mon, Oct 11, 2010 at 8:00 PM, Nathaniel McCallum nathan...@natemccallum.com wrote: I don't actually see that as a build option in either banshee or banshee-community-extensions. Am I missing something? Nathaniel On 10/11/2010 12:38 PM, Andy Shevchenko wrote: Agree if the maintainer enables the MPRISv2 support there. On Mon, Oct 11, 2010 at 7:20 PM, Nathaniel McCallum nathan...@natemccallum.com wrote: I'd like to propose that we upgrade banshee (and banshee-community-extensions) to 1.8.0 in F13. I estimate that this will close about half our open bugs. Doing this will require the following package upgrades in F13: * clutter-sharp - Upgrade (I'm pretty sure Banshee is the only user) * gio-sharp - New * gudev-sharp - New * gkeyfile-sharp - New * gtk-sharp-beans - New * libgpod - Upgrade (0.7.93 0.7.95; bugfix release) The only thing complicated here is the buildroot override requirement and making sure that we ship the new banshee-community-extensions in the same update as the new banshee. Currently, I do not think it is feasible to backport this to F12, so F13 would be the latest version. Thoughts? Comments? Nathaniel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- With Best Regards, Andy Shevchenko -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
orphan most of my packages
Hello, I have no more time to support the following packages in the Fedora. jack-audio-connection-kit -- The Jack Audio Connection Kit klamav -- Clam Anti-Virus on the KDE Desktop man-pages-uk -- Ukrainian man pages from the Linux Documentation Project python-alsa -- Python binding for the ALSA library qstat -- Real-time Game Server Status for FPS game servers uniconvertor -- Universal vector graphics translator -- With Best Regards, Andy Shevchenko -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Simultaneous Fedora and upstream git usage
On Sun, Sep 12, 2010 at 2:35 AM, Ben Boeckel maths...@gmail.com wrote: What I remember from FUDCon Toronto was that fedpkg could download the tarball, explode it into /tmp or something, do a `git init; git commit -a -m Tarball` and then there'd be some way to export patches on top of this commit back into the Fedora repository and get the PatchXX: and %patchXX lines in the spec easily. It's not what I would like to discuss, but it's really useful to such sources where upstream isn't a git-backed. Allowing maintainers to push full upstream repositories into the Fedora repositories isn't something I'd recommend doing. It also makes maintaining git-backed upstreams different than other version controls (imagine checking out Qt's repository to do a one liner change to the spec file). To be more clear, a) I'm talking about pull upstream to the _local_ repository; b) of course the feature should be optional, IOW fedpkg might have support of pulling remote sources from VCS (actually good to have VCS-URL inside spec); c) ... may be smth. else what I miss ... -- With Best Regards, Andy Shevchenko -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Simultaneous Fedora and upstream git usage
Every one who is use a git everyday knows that it has support of joining several repositories in one local repository (especially if it has a common base). I would use such feature for packages hosted in git repositories. So, the idea is to keep 2-in-1: - Fedora's git as a holder and main repository - upstream/* branches for an upstream sources (real package sources) Advantages are in keeping things together and simplify maintaining packages in Fedora with upstreamed patches (commits). It also reminds the Debian's scheme where the repository contains two branches and two kind of tags accordingly. Any suggestions or improvements to this scheme? -- With Best Regards, Andy Shevchenko -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Git question
On Tue, Aug 24, 2010 at 4:21 PM, Jochen Schmitt joc...@herr-schmitt.de wrote: Am 24.08.10 14:55, schrieb Steve Dickson: How I merge the latests changes from the remotes/origin/f13/master on to my f13/user/steved/pnfs-13 remote branch? I think git cherry-pick is the command whar you want to use. cherry-pick is useful when you take patches from one _custom_ branch to another. I case of master branch the rebase is more convenient, I think. -- With Best Regards, Andy Shevchenko -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: jack2
On Tue, May 11, 2010 at 6:17 PM, Orcan Ogetbil oget.fed...@gmail.com wrote: For F-13 it may be a little late. So shall we make this an F-14 target? I see new commit to the koji. Thanks for working on jack2, but the question is why the package name is jack-audio-connection-kit? As far as I know the package name should be derived from the main tarball name. -- With Best Regards, Andy Shevchenko -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: jack2
On Tue, Jul 20, 2010 at 5:04 PM, Orcan Ogetbil oget.fed...@gmail.com wrote: On Tue, Jul 20, 2010 at 2:30 AM, Andy Shevchenko wrote: question is why the package name is jack-audio-connection-kit? As far as I know the package name should be derived from the main tarball name. I thought about doing that once. Jack1's and jack2's source codes are distributed on the same website [1], We know that JACK stands for Jack-Audio-Connection-Kit. So there shouldn't be any confusion. There is rule in Fedora http://fedoraproject.org/wiki/PackageNamingGuidelines#General_Naming In our case it's a bit odd. However, I vote to call package in the same way as main tarball. -- With Best Regards, Andy Shevchenko -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: jack2
On Thu, Nov 5, 2009 at 5:23 PM, Andy Shevchenko andy.shevche...@gmail.com wrote: Hello. Nowadays the jack project has two branches - old jack (1) branch with version 0.116.2 and new one called jack2 version 1.9.3. I'd like to gather opinions and suggestions about applying new version for F13. Please, share your thoughts! Thank you. Recently I have received following letters: -- message -- From: Adrian Knoth a...@drcomp.erfurt.thur.de Date: Wed, Mar 31, 2010 at 2:55 PM Subject: Coordinated jackd upgrade To: andy.shevche...@gmail.com Hi Andy! I'm the Debian maintainer for jackd, ardour, ffado, qjackctl and some more packages related to pro-audio. After a long discussion, the Debian Multimedia Team decided to switch to jackd2 in squeeze, our upcoming release. We already coordinated with Ubuntu, they'll also switch ASAP, though it's too late for their soon to be released Lucid. We also contacted Opensuse (yesterday, answer pending), and now Fedora. The idea is to have all major Linux distros using the same jackd version, so users don't experience different levels of functionality depending on the distro they use, non-applicable recipes from the Internet, missing features and so on. The rationale for our switch to jackd2: * ABI-compatible drop-in replacement for jackd1, so no need to change or recompile any application * SMP support. jackd1 can only use one processor/core * soundcard reservation. jackd2 can talk to pulseaudio via DBUS to acquire the soundcard, so no need to manually shutdown or rip off PA when a user wants to start jackd. * support for ladish session manager (http://ladish.org) In general: more features, more everything. The Fedora-derived pro-audio CCRMA distro uses jackd2, the Gentoo pro-audio overlay uses jackd2, Ubuntu-Studio64 uses it and so on and so on... We have our jackd2 package almost ready, so if you like, we can send you a tarball if this helps. How do you feel about this coordinated approach? Cheerio -- message -- From: Adrian Knoth a...@drcomp.erfurt.thur.de Date: Wed, Mar 31, 2010 at 4:16 PM Subject: Re: Coordinated jackd upgrade To: Andy Shevchenko andy.shevche...@gmail.com On Wed, Mar 31, 2010 at 03:02:08PM +0200, Andy Shevchenko wrote: Hi! Hi Andy! Because this is private message I would like to ask about possibility to forward this mail to the fedora-devel@ mailing list. Of course, feel free to forward and if need be CC me, just in case you want me to reply to something... this also holds true for this mail. I see you've been discussing the very same problems. ;) Here are some decisions we made: * only one package, that is, we ship jackd2, not jackd1+jackd2. There's no need for two packages, jackd1-jackd2 are drop-in replacements to each other. Consequently, we avoid virtual packages. * Realtime permissions: our jackd package creates the file /etc/security/limits.d/audio.conf with the following content: @audio - rtprio 95 @audio - memlockunlimited The jackd2 package is missing manpages. For a start, we'll simply copy them from jackd1, but let me talk to upstream. This needs to be solved in jackd2 anyway. -- With Best Regards, Andy Shevchenko -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
File Net-Google-AuthSub-0.5.tar.gz uploaded to lookaside cache by andriy
A file has been added to the lookaside cache for perl-Net-Google-AuthSub: edd1363bd9db1e96d2cd2d4893d62537 Net-Google-AuthSub-0.5.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
rpms/perl-Net-Google-AuthSub/F-11 perl-Net-Google-AuthSub.spec, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2
Author: andriy
Update of /cvs/extras/rpms/perl-Net-Google-AuthSub/F-11
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv1072
Modified Files:
.cvsignore sources
Added Files:
perl-Net-Google-AuthSub.spec
Log Message:
Initial import (accepted in #478683)
--- NEW FILE perl-Net-Google-AuthSub.spec ---
Name: perl-Net-Google-AuthSub
Version:0.5
Release:1%{?dist}
Summary:Provides interface to interact with sites that implement Google
style AuthSub
Group: Development/Libraries
# From AuthSub.pm
License:GPL+ or Artistic
URL:http://search.cpan.org/dist/Net-Google-AuthSub/
Source0:
http://search.cpan.org/CPAN/authors/id/S/SI/SIMONW/Net-Google-AuthSub-%{version}.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch: noarch
BuildRequires: perl(LWP::UserAgent)
BuildRequires: perl(Test::More) = 0.62
BuildRequires: perl(URI)
BuildRequires: perl(Module::Build)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo $version))
%description
AuthSub is Google's method of authentication for their web
services. It is also used by other web sites.
You can read more about it here.
http://code.google.com/apis/accounts/Authentication.html
A Google Group for AuthSub is here.
http://groups.google.com/group/Google-Accounts-API
%prep
%setup -q -n Net-Google-AuthSub-%{version}
%build
%{__perl} Build.PL installdirs=vendor
./Build
%install
rm -rf $RPM_BUILD_ROOT
./Build install destdir=$RPM_BUILD_ROOT create_packlist=0
find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2/dev/null ';'
chmod -R u+w $RPM_BUILD_ROOT/*
%check
./Build test
%clean
rm -rf $RPM_BUILD_ROOT
%files
%defattr(-,root,root,-)
%doc Changes
%{perl_vendorlib}/*
%{_mandir}/man3/*.3*
%changelog
* Sun Nov 08 2009 Andy Shevchenko a...@smile.org.ua - 0.5-1
- update to version 0.5
* Sun Nov 09 2008 Andy Shevchenko a...@smile.org.ua - 0.4-1
- initial build for Fedora
Index: .cvsignore
===
RCS file: /cvs/extras/rpms/perl-Net-Google-AuthSub/F-11/.cvsignore,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- .cvsignore 7 Feb 2010 21:27:08 - 1.1
+++ .cvsignore 8 Feb 2010 21:45:37 - 1.2
@@ -0,0 +1 @@
+Net-Google-AuthSub-0.5.tar.gz
Index: sources
===
RCS file: /cvs/extras/rpms/perl-Net-Google-AuthSub/F-11/sources,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- sources 7 Feb 2010 21:27:09 - 1.1
+++ sources 8 Feb 2010 21:45:37 - 1.2
@@ -0,0 +1 @@
+edd1363bd9db1e96d2cd2d4893d62537 Net-Google-AuthSub-0.5.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
