Re: Comaintaining and/or help for qucs and freehdl
Le 09/07/2011 02:47, Bruno Wolff III a écrit : On Sun, Jul 03, 2011 at 22:30:01 +0200, Eric Tanguyeric.tan...@gmail.com wrote: At the same time qucs-0.0.16 were out a new version of freehdl appeared 0.0.8 but when i try to build it i have an error about rpath and i don't know how to solve it : Could you help me for this problem also ? I did a local build of freehdl 0.0.8 and I didn't get an rpath warning. I ran rpmlint on the output rpm and didn't see any reference to rpath. (There were some other things that were complained about.) Ok so i just redo a local build on my x86_64 system and i still have an error not a warning about rpath : ERROR 0001: file '/usr/bin/freehdl-v2cc' contains a standard rpath '/usr/lib64' in [/usr/lib64] erreur: Mauvais status de sortie pour /var/tmp/rpm-tmp.3B2Wl7 (%install) So it seems the problem is x86_64 related ? Eric -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[OT] Stray Cats were added?
Hello all: (Yes, Curiosity killed the cat, but never mind!) I saw this message towards the end of building a custom Fedora spin: 0 Stray cats were added.. Was wondering what's the background? Cheers, Amit -- http://echorand.me -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Comaintaining and/or help for qucs and freehdl
On Sat, Jul 09, 2011 at 08:37:05 +0200, Eric Tanguy eric.tan...@gmail.com wrote: Le 09/07/2011 02:47, Bruno Wolff III a écrit : On Sun, Jul 03, 2011 at 22:30:01 +0200, Eric Tanguyeric.tan...@gmail.com wrote: At the same time qucs-0.0.16 were out a new version of freehdl appeared 0.0.8 but when i try to build it i have an error about rpath and i don't know how to solve it : Could you help me for this problem also ? I did a local build of freehdl 0.0.8 and I didn't get an rpath warning. I ran rpmlint on the output rpm and didn't see any reference to rpath. (There were some other things that were complained about.) Ok so i just redo a local build on my x86_64 system and i still have an error not a warning about rpath : ERROR 0001: file '/usr/bin/freehdl-v2cc' contains a standard rpath '/usr/lib64' in [/usr/lib64] erreur: Mauvais status de sortie pour /var/tmp/rpm-tmp.3B2Wl7 (%install) So it seems the problem is x86_64 related ? Possibly. You might want to try to do a scratch build and see if you see the same thing. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
nonresponsive package maintainer (gget)
Does anyone know how to contact the maintainer (Ant Bryan)? https://bugzilla.redhat.com/show_bug.cgi?id=711629 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Lack of space on /
On Fri, Jul 08, 2011 at 09:47:13AM +0100, Paul F. Johnson wrote: Hi, Something strange has happened on my system. At the start of last week, / was reporting that I had about 8Gb free. It now reports that / is completely full. chkrootkit is reporting nothing untoward. I have noticed that putting things in the wastebasket and then saying empty hasn't been doing so recently, but that shouldn't account for 8Gb! Any ideas? This is the wrong list to be asking this question. Nevertheless, a quick shout out to the amazing power of KDE Filelight ... http://kde-apps.org/content/show.php/filelight?content=99561 Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Comaintaining and/or help for qucs and freehdl
Le 09/07/2011 09:29, Bruno Wolff III a écrit : On Sat, Jul 09, 2011 at 08:37:05 +0200, Eric Tanguyeric.tan...@gmail.com wrote: Le 09/07/2011 02:47, Bruno Wolff III a écrit : On Sun, Jul 03, 2011 at 22:30:01 +0200, Eric Tanguyeric.tan...@gmail.com wrote: At the same time qucs-0.0.16 were out a new version of freehdl appeared 0.0.8 but when i try to build it i have an error about rpath and i don't know how to solve it : Could you help me for this problem also ? I did a local build of freehdl 0.0.8 and I didn't get an rpath warning. I ran rpmlint on the output rpm and didn't see any reference to rpath. (There were some other things that were complained about.) Ok so i just redo a local build on my x86_64 system and i still have an error not a warning about rpath : ERROR 0001: file '/usr/bin/freehdl-v2cc' contains a standard rpath '/usr/lib64' in [/usr/lib64] erreur: Mauvais status de sortie pour /var/tmp/rpm-tmp.3B2Wl7 (%install) So it seems the problem is x86_64 related ? Possibly. You might want to try to do a scratch build and see if you see the same thing. You are right. The scratch build build fine and the package is now on bodhi. I can't understand why there was a problem on my local build! Thanks Eric -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Comaintaining and/or help for qucs and freehdl
Le 09/07/2011 14:53, Bruno Wolff III a écrit : If you aren't using fedpkg to do the local build, you might not be passing the correct config options. I seem to remember that %config passes an argument that says not to use rpath. It's correct. If i use fedpkg mockbuild there is no error whereas if i use rpmbuild -bb freehdl.spec i have an rpath error. This a bug ? If yes i'm not sure how to report it. Eric -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Comaintaining and/or help for qucs and freehdl
On Sat, Jul 09, 2011 at 18:50:43 +0200, Eric Tanguy eric.tan...@gmail.com wrote: Le 09/07/2011 14:53, Bruno Wolff III a écrit : If you aren't using fedpkg to do the local build, you might not be passing the correct config options. I seem to remember that %config passes an argument that says not to use rpath. It's correct. If i use fedpkg mockbuild there is no error whereas if i use rpmbuild -bb freehdl.spec i have an rpath error. This a bug ? If yes i'm not sure how to report it. No its not a bug. When you use fedpkg some different settings are made. I am not sure of the exact mechanism. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Comaintaining and/or help for qucs and freehdl
On Sat, Jul 9, 2011 at 6:50 PM, Eric Tanguy eric.tan...@gmail.com wrote: Le 09/07/2011 14:53, Bruno Wolff III a écrit : If you aren't using fedpkg to do the local build, you might not be passing the correct config options. I seem to remember that %config passes an argument that says not to use rpath. It's correct. If i use fedpkg mockbuild there is no error whereas if i use rpmbuild -bb freehdl.spec i have an rpath error. This a bug ? If yes i'm not sure how to report it. I suspect the behavior is caused by https://fedoraproject.org/wiki/PackagingGuidelines#Beware_of_Rpath : your local system has rpmdevtools installed, which changes rpm configuration to perform the rpath check. mock uses a minimal chroot which doesn't include rpmdevtools, thus the check is not performed. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Comaintaining and/or help for qucs and freehdl
On Sat, Jul 9, 2011 at 6:50 PM, Eric Tanguy eric.tan...@gmail.com wrote: Le 09/07/2011 14:53, Bruno Wolff III a écrit : If you aren't using fedpkg to do the local build, you might not be passing the correct config options. I seem to remember that %config passes an argument that says not to use rpath. It's correct. If i use fedpkg mockbuild there is no error whereas if i use rpmbuild -bb freehdl.spec i have an rpath error. This a bug ? If yes i'm not sure how to report it. I suspect the behavior is caused by https://fedoraproject.org/wiki/PackagingGuidelines#Beware_of_Rpath : your local system has rpmdevtools installed, which changes rpm configuration to perform the rpath check. mock uses a minimal chroot which doesn't include rpmdevtools, thus the check is not performed. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Comaintaining and/or help for qucs and freehdl
On Sat, Jul 09, 2011 at 19:30:56 +0200, Miloslav Trmač m...@volny.cz wrote: On Sat, Jul 9, 2011 at 6:50 PM, Eric Tanguy eric.tan...@gmail.com wrote: Le 09/07/2011 14:53, Bruno Wolff III a écrit : If you aren't using fedpkg to do the local build, you might not be passing the correct config options. I seem to remember that %config passes an argument that says not to use rpath. It's correct. If i use fedpkg mockbuild there is no error whereas if i use rpmbuild -bb freehdl.spec i have an rpath error. This a bug ? If yes i'm not sure how to report it. I suspect the behavior is caused by https://fedoraproject.org/wiki/PackagingGuidelines#Beware_of_Rpath : your local system has rpmdevtools installed, which changes rpm configuration to perform the rpath check. mock uses a minimal chroot which doesn't include rpmdevtools, thus the check is not performed. In this case I don't think that applies. I used fedpkg to do a local build without mock and have rpmdevtools installed and I didn't see a warning about rpath. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Comaintaining and/or help for qucs and freehdl
Le 09/07/2011 19:20, Bruno Wolff III a écrit : On Sat, Jul 09, 2011 at 19:30:56 +0200, Miloslav Trmačm...@volny.cz wrote: On Sat, Jul 9, 2011 at 6:50 PM, Eric Tanguyeric.tan...@gmail.com wrote: Le 09/07/2011 14:53, Bruno Wolff III a écrit : If you aren't using fedpkg to do the local build, you might not be passing the correct config options. I seem to remember that %config passes an argument that says not to use rpath. It's correct. If i use fedpkg mockbuild there is no error whereas if i use rpmbuild -bb freehdl.spec i have an rpath error. This a bug ? If yes i'm not sure how to report it. I suspect the behavior is caused by https://fedoraproject.org/wiki/PackagingGuidelines#Beware_of_Rpath : your local system has rpmdevtools installed, which changes rpm configuration to perform the rpath check. mock uses a minimal chroot which doesn't include rpmdevtools, thus the check is not performed. In this case I don't think that applies. I used fedpkg to do a local build without mock and have rpmdevtools installed and I didn't see a warning about rpath. If i do fedpkg local i obtain the same rpath error as running rpmbuild. The question is : why rpmdevtools make problem about rpath whereas koji build fine ? Eric -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: biosdevname in fedora 15 - why is this inconsistency?
On Fri, Jul 08, 2011 at 10:22:07AM -0600, Petrus de Calguarium wrote: Tom Hughes wrote: Did you upgrade this machine from an earlier version of Fedora? If so then I suspect the old names will stick because you will have udev persistent naming rules for them. No, I did a clean install. I installed a week before the first Test Candidate for the first Release Candidate of the Alpha for Fedora 15 came out. I indicated in the bug that we had a few last-minute fixes for this feature that landed around that time frame; it's possible that the pre-f15-alpha build he has missed such fixes. Otherwise, it's not obvious why it would fail. Petrus says he'll try again after F16 is released. -- Matt Domsch Technology Strategist Dell | Office of the CTO -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: Is it wrong?
On 07/08/2011 10:57 AM, Michal Schmidt wrote: On 07/08/2011 03:57 PM, Steve Dickson wrote: On 07/08/2011 08:23 AM, Lennart Poettering wrote: So, I'd suggest strongly not to try starting all services from a single file. There's a reason why we explicitly forbid having more than one ExecStart= in a unit file (except for Type=oneshot services). Thank you for this explanation. It appears your definition of a service might be a bit too simple for many subsystems. You seem to think that on service will only start one system daemon, which is not the case in the more complex subsystems. Each of the daemons can have its own unit file. We don't have to map the old initscripts to systemd units 1:1. So one service can not have multiple daemons? Also, you should not spawn forking processes in ExecStartPre=, that's not what it is for. In fact I am pretty sure I will change systemd now to kill off all remaining processes after each ExecStartPre= command now that I am aware that people are misusing it like this. If they are not for forking off process, what are the for? ExecStartPre= are for set up commands that do not leaved fork processes behind when they exit. Meaning they are not for daemon processes, which does make sense... It seems quite logical that one would use a number of ExecStartPre= commands to do some set up and then use the ExecStart= to start the daemon. Well, that's exactly how they're used. Do some preparation in ExecStartPre and run the daemon in ExecStart. ExecStartPre= is executed strictly in order, and in the order they appear in the unit file. True, but there is no synchronization. Meaning first process can end after the second process, which think is a problem. This must be some misunderstanding, or you're seeing an unusual bug. It just cannot happen. The second ExecStartPre of the unit is run after the first one exits, not earlier. Or do you mean synchronization among several units? Then you want to specify ordering dependencies (Before, After). Please take a look at https://bugzilla.redhat.com/show_bug.cgi?id=699040#c35 It sure looks like one process is being started for another one ends... steved. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: Is it wrong?
On 07/08/2011 10:57 AM, Lennart Poettering wrote: On Fri, 08.07.11 09:57, Steve Dickson (ste...@redhat.com) wrote: I am pretty sure systemd-devel is the better place to discuss this. But here are a few comments after reading throught the bug report: I didn't know it existed... That would have been the first big free software project without any mailing list, wouldn't it? Point! :-) Yes, we want that people place each service in an individual service file. Only then we can supervise the services properly. It is possible to spawn multiple high-level processes from a single service, but that is mostly intended as compat kludge to support SysV init scripts where this is possible. In general however, we want people to do have a 1:1 mapping. Only then we can restart services if needed, we can catch crashes, and show proper information about your service. So, I'd suggest strongly not to try starting all services from a single file. There's a reason why we explicitly forbid having more than one ExecStart= in a unit file (except for Type=oneshot services). Thank you for this explanation. It appears your definition of a service might be a bit too simple for many subsystems. You seem to think that on service will only start one system daemon, which is not the case in the more complex subsystems. Well, I doubt about the many. In fact, I am aware of only one other occasion where people were wondering about this. And often the problems are only perceived problems, because people try to translate their sysv scripts 1:1 and are unwilling to normalize their scripts while doing so. So basically what you are saying is a service can never consist of more than one system daemon. Also, you should not spawn forking processes in ExecStartPre=, that's not what it is for. In fact I am pretty sure I will change systemd now to kill off all remaining processes after each ExecStartPre= command now that I am aware that people are misusing it like this. If they are not for forking off process, what are the for? It seems quite logical that one would use a number of ExecStartPre= commands to do some set up and then use the ExecStart= to start the daemon. This is a misunderstanding. What I tried to say is that they should not be used to spawn off processes that fork and stay in the background. Processes in ExecStartPre= are executed synchronously: we wait for them to finish before we start the next one, and they should not try to play games with that and spawn stuff in the background. That's what I meant by saying you should not spawn *forking* processes in ExecStartPre=. Maybe a better way to says is ExecStartPre= should not be used for daemon process? ExecStartPre= is executed strictly in order, and in the order they appear in the unit file. True, but there is no synchronization. Meaning first process can end after the second process, which think is a problem. There is synchronization. As I made clear a couple of times, we never start more than one ExecStartPre= process at a time. We start the next one only after the previous one finished. Looking at https://bugzilla.redhat.com/show_bug.cgi?id=699040#c35 appears this is not the case... I believe that services should be enabled/disabled at one place only, and that is where you can use systemctl enable and systemctl disable. Adding a service-specific second-level of disabling in /etc/sysconfig/ is confusing to the user, and not necessary. You'll do a great service to your users if they can enable/disable all individual services the same way. (And UI writers will be thankful for that too) In a simple subsystem maybe, but many subsystems have a large number of configuration knobs that are needed so the subsystem can function in a large number of different environments. So in the past its been very handy and straightforward to be able to tweak one file to set configurations on different, but related, subsystems. Well, nothing stops you from reading the same configuration file from multiple services. We do that all the time, for example for /etc/resolv.conf. True... but the point is before systemd, an admin could tweak one /etc/sysconfig file which define which daemon were started and how they were configured... Unless I'm missing something that is no longer the case... The admin will have to explicitly define each an every daemon they need to run and how they are configured.. all by hand... This is not going to work: ExecStart=$FOO bar waldo I.e. variable substitution for the binary path (it will work for the arguments, just not for the binary path). This limitation is necessary due to some SELinux innerworkings in systemd. It's a limitation we probably could fix if we wanted to, but tbh I find it quite questionable if you spawn two completely different binaries and still call it by the same service file. Spawning different binaries to do set up, like exporting directories
Re: [fedora-arm] Fedora 15 ARM hardfp Virtual FAD (Fedora Activity Day) - FRIDAY
On Fri, 2011-07-08 at 00:52 -0400, Jon Masters wrote: We are hosting another one of our regular Fedora 15 hardfp Virtual Fedora Activity Day today Friday July 8th, at 14:00UTC (10:00 Eastern Daylight Time). The purpose of this session is to co-ordinate the bootstrap of F15 hardfp (hardware floating point). Going forward, the proposal is that these remain on Fridays, and at the same time. As a followup, we now have a working yum installation. Next week, we will be working on support for mock. Once we have these, we can build up missing dependencies, then rebuild everything we have with rpmbuild. At that point, we can rebuild everything within mock and Koji-fyificate. It's becoming clear that several points do need raising with FESCo: * Fedora should (IMO) institute mandatory mass rebuilds. Either every cycle, or every other cycle. I've briefly discussed with Dennis. Bootstrapping (and similar activities) are far easier with a clean set of deps, which is the case for F15. It should always be the case that we know everything builds and self-hosts through a mass rebuild per cycle. * Fedora would benefit from an explicit position on the dependency explosion we're seeing in basic packages. Without going off too far into my personal opinions on a need to respect UNIX heritage, etc. I will say that the explosion of requirements is going to be a problem for any future efforts and will get worse without guidance. Meanwhile, enjoy working yum. Next week, working mock, hopefully. Thanks, Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [fedora-arm] Fedora 15 ARM hardfp Virtual FAD (Fedora Activity Day) - FRIDAY
On Sun, Jul 10, 2011 at 12:45 AM, Jon Masters j...@redhat.com wrote: On Fri, 2011-07-08 at 00:52 -0400, Jon Masters wrote: We are hosting another one of our regular Fedora 15 hardfp Virtual Fedora Activity Day today Friday July 8th, at 14:00UTC (10:00 Eastern Daylight Time). The purpose of this session is to co-ordinate the bootstrap of F15 hardfp (hardware floating point). Going forward, the proposal is that these remain on Fridays, and at the same time. As a followup, we now have a working yum installation. Next week, we will be working on support for mock. Once we have these, we can build up missing dependencies, then rebuild everything we have with rpmbuild. At that point, we can rebuild everything within mock and Koji-fyificate. It's becoming clear that several points do need raising with FESCo: * Fedora should (IMO) institute mandatory mass rebuilds. Either every cycle, or every other cycle. I've briefly discussed with Dennis. Bootstrapping (and similar activities) are far easier with a clean set of deps, which is the case for F15. It should always be the case that we know everything builds and self-hosts through a mass rebuild per cycle. * Fedora would benefit from an explicit position on the dependency explosion we're seeing in basic packages. Without going off too far into my personal opinions on a need to respect UNIX heritage, etc. I will say that the explosion of requirements is going to be a problem for any future efforts and will get worse without guidance. Meanwhile, enjoy working yum. Next week, working mock, hopefully. Thanks, Jon. I agree, we must have a bootstrapping guide. -- Itamar Reis Peixoto msn, google talk: ita...@ispbrasil.com.br +55 11 4063 5033 (FIXO SP) +55 34 9158 9329 (TIM) +55 34 8806 3989 (OI) +55 34 3221 8599 (FIXO MG) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
File XML-RSS-LibXML-0.3101.tar.gz uploaded to lookaside cache by iarnell
A file has been added to the lookaside cache for perl-XML-RSS-LibXML: fda8cbca02c84ee19754f29098f82fcc XML-RSS-LibXML-0.3101.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-XML-RSS-LibXML/f14] (3 commits) ...update to 0.3101
Summary of changes: 61665f9... - 661697 rebuild for fixing problems with vendorach/lib (*) 1314d64... - Rebuilt for https://fedoraproject.org/wiki/Fedora_15_Mass (*) 30a87c6... update to 0.3101 (*) 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-XML-RSS-LibXML/f14: 3/3] update to 0.3101
commit 30a87c65dec86527250736eb4b3a6407e0f82f21
Author: Iain Arnell iarn...@gmail.com
Date: Sat Jul 9 09:05:53 2011 +0200
update to 0.3101
.gitignore |1 +
perl-XML-RSS-LibXML.spec | 16 +++-
sources |2 +-
3 files changed, 9 insertions(+), 10 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 93a747d..d314b81 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1,2 @@
XML-RSS-LibXML-0.3100.tar.gz
+/XML-RSS-LibXML-0.3101.tar.gz
diff --git a/perl-XML-RSS-LibXML.spec b/perl-XML-RSS-LibXML.spec
index cb97419..3c6c02b 100644
--- a/perl-XML-RSS-LibXML.spec
+++ b/perl-XML-RSS-LibXML.spec
@@ -1,12 +1,11 @@
Name: perl-XML-RSS-LibXML
-Version:0.3100
-Release:3%{?dist}
+Version:0.3101
+Release:1%{?dist}
Summary:XML::RSS with XML::LibXML
License:GPL+ or Artistic
Group: Development/Libraries
URL:http://search.cpan.org/dist/XML-RSS-LibXML/
Source0:
http://www.cpan.org/authors/id/D/DM/DMAKI/XML-RSS-LibXML-%{version}.tar.gz
-BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch: noarch
BuildRequires: perl(Class::Accessor::Fast)
BuildRequires: perl(DateTime::Format::Mail)
@@ -40,8 +39,6 @@ sed -i -e '/^auto_install/d' Makefile.PL
make %{?_smp_mflags}
%install
-rm -rf $RPM_BUILD_ROOT
-
make pure_install DESTDIR=$RPM_BUILD_ROOT
find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
@@ -52,16 +49,17 @@ find $RPM_BUILD_ROOT -depth -type d -exec rmdir {}
2/dev/null \;
%check
TEST_POD=yep make test
-%clean
-rm -rf $RPM_BUILD_ROOT
-
%files
-%defattr(-,root,root,-)
%doc Changes
%{perl_vendorlib}/*
%{_mandir}/man3/*
%changelog
+* Sat Jul 09 2011 Iain Arnell iarn...@gmail.com 0.3101-1
+- update to latest upstream version
+- clean up spec for modern rpmbuild
+- remove unnecessary explicit requires
+
* Wed Feb 09 2011 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 0.3100-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_15_Mass_Rebuild
diff --git a/sources b/sources
index bba6b39..7d227e8 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-785545e7994367c32db771430eb8e6ca XML-RSS-LibXML-0.3100.tar.gz
+fda8cbca02c84ee19754f29098f82fcc XML-RSS-LibXML-0.3101.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-XML-RSS-LibXML/f14] remove premature changelog entry
commit 200a01dd72357e08b492e77569d72d7974ea6cc0 Author: Iain Arnell iarn...@gmail.com Date: Sat Jul 9 09:11:50 2011 +0200 remove premature changelog entry perl-XML-RSS-LibXML.spec |1 - 1 files changed, 0 insertions(+), 1 deletions(-) --- diff --git a/perl-XML-RSS-LibXML.spec b/perl-XML-RSS-LibXML.spec index 3c6c02b..d75b3b2 100644 --- a/perl-XML-RSS-LibXML.spec +++ b/perl-XML-RSS-LibXML.spec @@ -58,7 +58,6 @@ TEST_POD=yep make test * Sat Jul 09 2011 Iain Arnell iarn...@gmail.com 0.3101-1 - update to latest upstream version - clean up spec for modern rpmbuild -- remove unnecessary explicit requires * Wed Feb 09 2011 Fedora Release Engineering rel-...@lists.fedoraproject.org - 0.3100-3 - Rebuilt for https://fedoraproject.org/wiki/Fedora_15_Mass_Rebuild -- 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-XML-RSS-LibXML] (3 commits) ...remove unnecessary explicit requires
Summary of changes: 30a87c6... update to 0.3101 (*) 200a01d... remove premature changelog entry (*) d74a659... remove unnecessary explicit requires (*) 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-XML-RSS-LibXML: 3/3] remove unnecessary explicit requires
commit d74a65948fd469a1246e9f9d2db557696cec631c
Author: Iain Arnell iarn...@gmail.com
Date: Sat Jul 9 09:13:22 2011 +0200
remove unnecessary explicit requires
perl-XML-RSS-LibXML.spec |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
---
diff --git a/perl-XML-RSS-LibXML.spec b/perl-XML-RSS-LibXML.spec
index d75b3b2..d6a1abf 100644
--- a/perl-XML-RSS-LibXML.spec
+++ b/perl-XML-RSS-LibXML.spec
@@ -19,8 +19,6 @@ BuildRequires: perl(Test::Warn)
BuildRequires: perl(UNIVERSAL::require)
BuildRequires: perl(XML::LibXML) = 1.66
BuildRequires: perl(XML::LibXML::XPathContext)
-Requires: perl(Class::Accessor::Fast)
-Requires: perl(Exporter)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
%{?perl_default_filter}
@@ -58,6 +56,7 @@ TEST_POD=yep make test
* Sat Jul 09 2011 Iain Arnell iarn...@gmail.com 0.3101-1
- update to latest upstream version
- clean up spec for modern rpmbuild
+- remove unnecessary explicit requires
* Wed Feb 09 2011 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 0.3100-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_15_Mass_Rebuild
--
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-XML-RSS-LibXML/f15] (3 commits) ...remove unnecessary explicit requires
Summary of changes: 30a87c6... update to 0.3101 (*) 200a01d... remove premature changelog entry (*) d74a659... remove unnecessary explicit requires (*) (*) 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
File Test-Spec-0.37.tar.gz uploaded to lookaside cache by iarnell
A file has been added to the lookaside cache for perl-Test-Spec: fed96687deb122dbf1e0c281b3e2ba20 Test-Spec-0.37.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-Test-Spec] update to 0.37
commit c7cf825fdfc8a68f569a0bcc7d8477f6fba89dca
Author: Iain Arnell iarn...@gmail.com
Date: Sat Jul 9 10:18:20 2011 +0200
update to 0.37
.gitignore |1 +
perl-Test-Spec.spec |5 -
sources |2 +-
3 files changed, 6 insertions(+), 2 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 6b29fd0..5dcf177 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,3 +1,4 @@
/Test-Spec-0.31.tar.gz
/Test-Spec-0.32.tar.gz
/Test-Spec-0.33.tar.gz
+/Test-Spec-0.37.tar.gz
diff --git a/perl-Test-Spec.spec b/perl-Test-Spec.spec
index 16ec451..2f3b955 100644
--- a/perl-Test-Spec.spec
+++ b/perl-Test-Spec.spec
@@ -1,5 +1,5 @@
Name: perl-Test-Spec
-Version:0.33
+Version:0.37
Release:1%{?dist}
Summary:Write tests in a declarative specification style
License:GPL+ or Artistic
@@ -58,6 +58,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Sat Jul 09 2011 Iain Arnell iarn...@gmail.com 0.37-1
+- update to latest upstream version
+
* Sat Jun 25 2011 Iain Arnell iarn...@gmail.com 0.33-1
- update to latest upstream version
diff --git a/sources b/sources
index 45a8d0c..287b1fc 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-1271d96c3c491fa9cb828f64a329c42e Test-Spec-0.33.tar.gz
+fed96687deb122dbf1e0c281b3e2ba20 Test-Spec-0.37.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-Application-Dispatch] Update to 3.0.4, add BR, remove TODO
commit 8b7104f12591850488de4d62a2471f86c3e8e42d
Author: Emmanuel Seyman emmanuel.sey...@club-internet.fr
Date: Sat Jul 9 21:39:16 2011 +0200
Update to 3.0.4, add BR, remove TODO
.gitignore |1 +
perl-CGI-Application-Dispatch.spec | 13 ++---
sources|2 +-
3 files changed, 12 insertions(+), 4 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 897eaa0..72e9b89 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,3 +1,4 @@
CGI-Application-Dispatch-2.17.tar.gz
/CGI-Application-Dispatch-2.18.tar.gz
/CGI-Application-Dispatch-3.00.tar.gz
+/CGI-Application-Dispatch-3.04.tar.gz
diff --git a/perl-CGI-Application-Dispatch.spec
b/perl-CGI-Application-Dispatch.spec
index b41ac5d..8157495 100644
--- a/perl-CGI-Application-Dispatch.spec
+++ b/perl-CGI-Application-Dispatch.spec
@@ -1,6 +1,6 @@
Name: perl-CGI-Application-Dispatch
-Version:3.00
-Release:2%{?dist}
+Version:3.04
+Release:1%{?dist}
Summary:Dispatch requests to CGI::Application based objects
License:GPL+ or Artistic
Group: Development/Libraries
@@ -9,8 +9,10 @@ Source0:
http://www.cpan.org/authors/id/M/MA/MARKSTOS/CGI-Application-Dis
BuildArch: noarch
BuildRequires: perl(CGI)
BuildRequires: perl(CGI::Application) = 4.50
+BuildRequires: perl(CGI::PSGI)
BuildRequires: perl(Exception::Class)
BuildRequires: perl(Exception::Class::TryCatch)
+BuildRequires: perl(HTTP::Exception)
BuildRequires: perl(Module::Build)
BuildRequires: perl(Plack)
BuildRequires: perl(Test::LongString)
@@ -44,11 +46,16 @@ find $RPM_BUILD_ROOT -depth -type d -exec rmdir {}
2/dev/null \;
./Build test
%files
-%doc Changes TODO
+%doc Changes
%{perl_vendorlib}/*
%{_mandir}/man3/*
%changelog
+* Fri Jul 08 2011 Emmanuel Seyman emmanuel.sey...@club-internet.fr - 3.04-1
+- Update to 3.04
+- Add HTTP::Exception and CGI::PSGI to the BuildRequires
+- Lose the TODO file
+
* Tue Jun 21 2011 Marcela Mašláňová mmasl...@redhat.com - 3.00-2
- Perl mass rebuild
diff --git a/sources b/sources
index f5a55cf..591f8b5 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-81323cdf46c8dd8191d6a50edfc79bff CGI-Application-Dispatch-3.00.tar.gz
+29958e996b9b19240ff4f16cc28668f5 CGI-Application-Dispatch-3.04.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
