Re: Why do we need FC version attached to the package name?
On Jun 22, 2009, at 1:08, Dave Jones da...@redhat.com wrote: On Sun, Jun 21, 2009 at 04:56:07PM -0600, Nathanael D. Noblet wrote: I *wish* it made a difference. I did an upgrade am an left with a host of fc10 packages because the fc11 ones weren't considered newer. For example people with updates-testing enabled on fc10 got a non-upgraded yum because the versions were the same (except for fc10/fc11) and it stopped working because python went from 2.5 to 2.6. That's messed up. We used to check just before release time that this situation never occured. It should probably be added to the rel-eng release checklist if it isn't there already. Dave Not possible while we allow people to keep making updates to the older releases. Those updates quickly become version ( not just release even ) higher than the static copies on the release medium and repos. -- Jes -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why do we need FC version attached to the package name?
On 06/22/2009 12:54 PM, Jesse Keating wrote: Not possible while we allow people to keep making updates to the older releases. Those updates quickly become version ( not just release even ) higher than the static copies on the release medium and repos. Is there any proposed solution to this problem? We can't just continue to break upgrade paths and call it the way things are done. Rahul -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why do we need FC version attached to the package name?
On 22/06/09 08:24, Jesse Keating wrote: That's messed up. We used to check just before release time that this situation never occured. It should probably be added to the rel-eng release checklist if it isn't there already. Dave Not possible while we allow people to keep making updates to the older releases. Those updates quickly become version ( not just release even ) higher than the static copies on the release medium and repos. -- Jes Maybe, freeze all updates nearing a GA, FRank -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why do we need FC version attached to the package name?
On Jun 22, 2009, at 9:26, Rahul Sundaram sunda...@fedoraproject.org wrote: On 06/22/2009 12:54 PM, Jesse Keating wrote: Not possible while we allow people to keep making updates to the older releases. Those updates quickly become version ( not just release even ) higher than the static copies on the release medium and repos. Is there any proposed solution to this problem? We can't just continue to break upgrade paths and call it the way things are done. Rahul If you have any ideas I'd like to hear them. A super epoch has already been suggested but that just masks the problem and may cause unwanted downgrades. Any solution either involves severly limiting what kind of updates can be done or requiring network access during upgrades. -- Jes -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why do we need FC version attached to the package name?
On Jun 22, 2009, at 9:29, Frank Murphy frankl...@gmail.com wrote: On 22/06/09 08:24, Jesse Keating wrote: That's messed up. We used to check just before release time that this situation never occured. It should probably be added to the rel-eng release checklist if it isn't there already. Dave Not possible while we allow people to keep making updates to the older releases. Those updates quickly become version ( not just release even ) higher than the static copies on the release medium and repos. -- Jes Maybe, freeze all updates nearing a GA, And keep them frozen indefinitely? -- Jes -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why do we need FC version attached to the package name?
On Mon, 2009-06-22 at 09:31 +0200, Jesse Keating wrote: On Jun 22, 2009, at 9:26, Rahul Sundaram sunda...@fedoraproject.org wrote: On 06/22/2009 12:54 PM, Jesse Keating wrote: Not possible while we allow people to keep making updates to the older releases. Those updates quickly become version ( not just release even ) higher than the static copies on the release medium and repos. Is there any proposed solution to this problem? We can't just continue to break upgrade paths and call it the way things are done. If you have any ideas I'd like to hear them. A super epoch has already been suggested but that just masks the problem and may cause unwanted downgrades. Any solution either involves severly limiting what kind of updates can be done or requiring network access during upgrades. Does anaconda currently force installs of core packages such as yum? This is quite important if the version in the old distro is newer than that on the DVD. -- Jussi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why do we need FC version attached to the package name?
On 22/06/09 08:32, Jesse Keating wrote: Maybe, freeze all updates nearing a GA, And keep them frozen indefinitely? -- Jes Duh!, forgot the coffee. That would get the early adopters, then nearing EOL of current eg 9. Only allow updates for 11. Same when 10 is EOL. Just update most recent release Frank -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why do we need FC version attached to the package name?
On Jun 22, 2009, at 9:38, Frank Murphy frankl...@gmail.com wrote: On 22/06/09 08:32, Jesse Keating wrote: Maybe, freeze all updates nearing a GA, And keep them frozen indefinitely? -- Jes Duh!, forgot the coffee. That would get the early adopters, then nearing EOL of current eg 9. Only allow updates for 11. Same when 10 is EOL. Just update most recent release Doesn't actually help anything. People upgrading from the most recent release will run into issues unless we stop updates around devel freeze, which would leave more than a month without updates and would cut our 13 month life to 5 or so. -- Jes -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why do we need FC version attached to the package name?
On 06/22/2009 01:01 PM, Jesse Keating wrote: If you have any ideas I'd like to hear them. A super epoch has already been suggested but that just masks the problem and may cause unwanted downgrades. Any solution either involves severly limiting what kind of updates can be done or requiring network access during upgrades. I can't think of any fool proof solutions but there are a couple of things that might help: * Run checks on upgrade paths and inform the maintainers when are about to break an upgrade path (ie) before signing it. I noticed a few maintainers I talked to just weren't aware they were doing so and neither were they aware of the %dist.1 trick to workaround the problem atleast in some cases. They might choose to delay an update where it is feasible to do so. Not sure what we can do about security updates or critical bug fixes breaking the upgrade path for the next release. Ideally, the maintainer should have pushed it in sync for the two releases. * In preupgrade, if a user has updates-testing repo enabled, make sure it is enabled for the release they are upgrading to. I think I have a RFE filed on this. This is a bit of a corner case. Rahul Rahul -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: .spec file help - need buildrequires to depend on fedora version
On 22/06/09 03:15, Todd Zullinger wrote:
Carl Byington wrote:
My libpst package BuildRequires boost-devel, which works on older
systems (centos4 thru fedora 10), but for fedora 11 and devel, it
needs BuildRequires boost-python-devel. What is the preferred .spec
code to achieve that?
Something like this:
%if 0%{?fedora} 10
BuildRequires: boost-python-devel
%else
BuildRequires: boost-devel
%endif
Or you could buildreq one of the header files you actually need, e.g.
BuildRequires: /usr/include/boost/python.hpp
That should pull in whatever package contains the file.
Paul.
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
XInput.h has moved to libXi
Just a notice, if your package requires XInput.h to build, you will need to change the BuildRequires from xorg-x11-proto-devel to libXi. The header file has moved there. Reason: it's the library header file and shouldn't have been in the proto package in the first place (this applies to upstream as well of course). This applies to Rawhide only, not F11. Cheers, Peter -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why do we need FC version attached to the package name?
On Mon, Jun 22, 2009 at 01:14:55PM +0530, Rahul Sundaram wrote: On 06/22/2009 01:01 PM, Jesse Keating wrote: If you have any ideas I'd like to hear them. A super epoch has already been suggested but that just masks the problem and may cause unwanted downgrades. Any solution either involves severly limiting what kind of updates can be done or requiring network access during upgrades. I can't think of any fool proof solutions but there are a couple of things that might help: * Run checks on upgrade paths and inform the maintainers when are about to break an upgrade path (ie) before signing it. I noticed a few maintainers I talked to just weren't aware they were doing so and neither were they aware of the %dist.1 trick to workaround the problem atleast in some cases. They might choose to delay an update where it is feasible to do so. Not sure what we can do about security updates or critical bug fixes breaking the upgrade path for the next release. Ideally, the maintainer should have pushed it in sync for the two releases. I think you mean before pushing rather than signing, but this idea has been suggested before. The good thing is, we could possibly tie this into bodhi during update submission. It's fairly easy to do NEVR comparisons and we don't need full repos for the upgrade path checks to happen since we can use the update information and koji tags. The bad thing is, this suffers from the same problems every other auto-QA suggestion has. Namely, no code, nobody with time to write the code, and it potentially slows things down even more. josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why do we need FC version attached to the package name?
On 06/22/2009 04:49 PM, Josh Boyer wrote: I think you mean before pushing rather than signing, but this idea has been suggested before. Well, if you aren't going to push anyway, then signing it wouldn't be that useful, right? A koji build can be a trigger for the script check instead of a push in bodhi. The good thing is, we could possibly tie this into bodhi during update submission. It's fairly easy to do NEVR comparisons and we don't need full repos for the upgrade path checks to happen since we can use the update information and koji tags. The bad thing is, this suffers from the same problems every other auto-QA suggestion has. Namely, no code, nobody with time to write the code, and it potentially slows things down even more. Isn't the scripts Michael Schwendt refers to, not useful anymore? Even one with some false positives would be better than nothing. There is also the separate but related problem of maintainers ignoring issues that are being reported but that is a relatively smaller number. Rahul -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why do we need FC version attached to the package name?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 There are still packagers who bump %version or %release in old dist updates without considering the consequences with regard to dist upgrades. I think this is the real problem If this hits yum or any package yum depends on you have no chance for dist-upgrade I had the problem updating f8-f9 eith openssl-dependencies of installed yum-version which was installed in a version yum did not resolve because installed yum has dependencie of installed openssl and the yum-version from f9 was not resolved as to update. preupgrade did leave me with a unbootable system without a kernel after second try and finally i had to force the upgrade again form dvd - if this happens on a server you would wish to die :-) I think dist-upgrades with yum should be forced official because you can not upgrade a server from dvd or preupgrade because of downtime my experience is that upgrades with yum are much better if there are no broken dependencies because you can check and fix grub.conf, make manually updates, remove leaves and so on while the system is running and as sample apache serves his websites without downtime, so you have more time to look and think before you reboot and run into troubles. anaconda is a blackbox in this case -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAko/cggACgkQhmBjz394AnlfLACeJb50BGs8lSM6RtBI4XRhOV4Y RgsAnipX1IGn/9iYwt5fAD6T9o5q3pA1 =k3bM -END PGP SIGNATURE- -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why do we need FC version attached to the package name?
On Mon, Jun 22, 2009 at 04:53:10PM +0530, Rahul Sundaram wrote: On 06/22/2009 04:49 PM, Josh Boyer wrote: I think you mean before pushing rather than signing, but this idea has been suggested before. Well, if you aren't going to push anyway, then signing it wouldn't be that useful, right? A koji build can be a trigger for the script check Right, but pushing and signing are disjoint. instead of a push in bodhi. No, I don't think we want to do that yet. The way my brain sees it working is that a maintainer does a build and submits it into bodhi. When he/she submits it for test/stable, bodhi will run a quick upgrade path check and refuse to actually put it in the pending state if it breaks an upgrade path. The signing stuff is only done on updates that are accepted, so you don't have to worry about signing a useless build. The bad thing is, this suffers from the same problems every other auto-QA suggestion has. Namely, no code, nobody with time to write the code, and it potentially slows things down even more. Isn't the scripts Michael Schwendt refers to, not useful anymore? Even It's useful. It's generally after the fact though, and in the long run I think we want to be proactive, not reactive. josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: F11: LVM over MD is broken. Switch back to F10?
On Sun, 2009-06-21 at 18:15 -0500, Ian Pilcher wrote: You'll also want to watch out for https://bugzilla.redhat.com/show_bug.cgi?id=506189 Good times! Uggg... - Gilboa -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 11 wireless-tools yum erase?
On 06/21/2009 05:56 PM, Jeff Spaleta wrote: On Sun, Jun 21, 2009 at 6:50 AM, John W. Linvillelinvi...@redhat.com wrote: If a tool needs something to perform one of its functions it needs it. There isn't a anaconda-no-wireless package, etc. This speaks deeply to a cultural understanding as to what the concept of networking is. It seems obvious there are people who would like to consider wireless as optional. as this is an historic artifact of how networking tech has developed over time. I wonder, have we reached the point where other people have started to consider a wired network optional as well? -jef This is a good question. Laptops are becoming the norm if not already so, add smart devices and wireless is looking more like the standard rather than exception. We are not there quite yet though. To most (almost all) desktop users, wireless packages are superfluous. That is generally not the case with a laptop user. As long as they have the hardware to support both, they will continue to need (want) both. So no, I do not believe we've reached a point where wired would be concidered optional, not yet anyway. TK009 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 11 wireless-tools yum erase?
If a tool needs something to perform one of its functions it needs it. There isn't a anaconda-no-wireless package, etc. This speaks deeply to a cultural understanding as to what the concept of networking is. It seems obvious there are people who would like to consider wireless as optional. as this is an historic artifact of how networking tech has developed over time. I wonder, have we reached the point where other people have started to consider a wired network optional as well? -jef This is a good question. Laptops are becoming the norm if not already so, add smart devices and wireless is looking more like the standard rather than exception. We are not there quite yet though. To most (almost all) desktop users, wireless packages are superfluous. That is generally not the case with a laptop user. As long as they have the hardware to support both, they will continue to need (want) both. So no, I do not believe we've reached a point where wired would be concidered optional, not yet anyway. I would agree, just about all NetBooks (possibly all) still come with wired ethernet ports and given their price point I would expect that that platform to be the one to drop the wired ports first. Also a nummber of other devices that have only wireless still support usb ethernet out of the box to provide wired support. Peter -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why do we need FC version attached to the package name?
On 06/22/2009 05:35 PM, Josh Boyer wrote: Isn't the scripts Michael Schwendt refers to, not useful anymore? Even It's useful. It's generally after the fact though, and in the long run I think we want to be proactive, not reactive. I agree but we aren't even reacting much now. If the scripts run from infrastructure systems automatically as opposed to having someone run it manually, I suspect it would help fix most of the issues we are currently having. Rahul -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Packaging PHP
I'm currently packaging some PHP classes: if I follow the packaging guideline at http://fedoraproject.org/wiki/Packaging:PHP#File_Placement, class files should appear directly in /usr/share/php, not in an extension-specific sub-directory. This seems rather rude: this rule will sooner or later cause name collision between files from packages and the directory will grow up to a mess very fast. Would it be possible to alter this rule to allow package-specific sub-directories ? I know some packages go already this way (is it by special authorization?). Maybe my understanding of this simple rule is too strict. In this case, I think it should be stated in more permissive terms. Thanks for your replies Patrick -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why do we need FC version attached to the package name?
On Mon, Jun 22, 2009 at 06:20:07PM +0530, Rahul Sundaram wrote: On 06/22/2009 05:35 PM, Josh Boyer wrote: Isn't the scripts Michael Schwendt refers to, not useful anymore? Even It's useful. It's generally after the fact though, and in the long run I think we want to be proactive, not reactive. I agree but we aren't even reacting much now. If the scripts run from infrastructure systems automatically as opposed to having someone run it manually, I suspect it would help fix most of the issues we are currently having. True. Care to file a rel-eng ticket suggesting we setup a cronjob to do so? The script will likely need some rework and it may take some time, but the ticket is a good starting point. josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why do we need FC version attached to the package name?
Le Lun 22 juin 2009 15:26, Josh Boyer a écrit : True. Care to file a rel-eng ticket suggesting we setup a cronjob to do so? The script will likely need some rework and it may take some time, but the ticket is a good starting point. Can a ticket be opened to run other periodic checks for which scripts exist ? -- Nicolas Mailhot -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why do we need FC version attached to the package name?
On 06/22/2009 06:56 PM, Josh Boyer wrote: On Mon, Jun 22, 2009 at 06:20:07PM +0530, Rahul Sundaram wrote: On 06/22/2009 05:35 PM, Josh Boyer wrote: Isn't the scripts Michael Schwendt refers to, not useful anymore? Even It's useful. It's generally after the fact though, and in the long run I think we want to be proactive, not reactive. I agree but we aren't even reacting much now. If the scripts run from infrastructure systems automatically as opposed to having someone run it manually, I suspect it would help fix most of the issues we are currently having. True. Care to file a rel-eng ticket suggesting we setup a cronjob to do so? The script will likely need some rework and it may take some time, but the ticket is a good starting point. Here, you go https://fedorahosted.org/fedora-infrastructure/ticket/1471 Rahul -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Outage Notification - 2009-06-23 20:00 UTC
There will be an outage starting at 2009-06-23 20:00 UTC, which will last approximately 2 and a half hours. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d '2009-06-23 20:00 UTC' Affected Services: CVS / Source Control Unaffected Services: Buildsystem Database DNS Fedora Hosted Fedora People Fedora Talk Mail Mirror System Torrent Translation Services Websites Ticket Link: https://fedorahosted.org/fedora-infrastructure/ticket/1472 Reason for Outage: Step 1 of a two step migration process for cvs (moving to different hardware). If this goes well, step 2 will come later in the week. CVS commits will continue to work during this time. Lookaside cache availability will be intermittent. If a build fails, just re-try later. Contact Information: Please join #fedora-admin in irc.freenode.net or respond to this email to track the status of this outage. ___ Fedora-devel-announce mailing list fedora-devel-annou...@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 11 wireless-tools yum erase?
On Sun, 2009-06-21 at 13:01 +0100, Frank Murphy wrote: On 21/06/09 12:57, Michal Schmidt wrote: Someone already requested this: https://bugzilla.redhat.com/show_bug.cgi?id=480558 Good Why does it bother you? The package is not that big. It's not about size, it's about making sense. No wireless, therefore why wireless installed. Same reason the kernel installs a lot of drivers. If you, in the future, plug something wireless in, it'll work. It's also a question of maintainability. Sure, we could split up tons of packages and add code to all the tools to check runtime-availability of every tool they might use. But that's just insane, and increases the maintenance burden tremendously. So the tradeoff is between the packagers maintaining an ugly patch that upstream probably won't care about, against making the 5% of people who really want to remove wireless-tools happy. Every change like this increases the maintenance burden, and I'd argue that it's simply not worth it. There's also value to being able to just plug hardware in and have it work without downloading additional software. Dan -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 11 wireless-tools yum erase?
On Sun, 2009-06-21 at 13:59 +0200, Martin Sourada wrote: On Sun, 2009-06-21 at 12:14 +0100, Frank Murphy wrote: Why does yum erase wireless-tools want to: Removing for dependencies: anaconda firstboot rhpl system-config-(boot,date,date-docs,firewall, firewall-tui,keyboard,kickstart,language,lvm, network,network-tui,rootpassword,users,users-docs) This is a wired desktop, that has absolutely no need for wireless or indeed wpa-supplicant which want to remove: NetworkManager NetworkManager-gnome anaconda system-config-kickstart I know --nodeps could be used, or indeed use network service but currently have no problems with NM Bu how?, are they tied into so much. Frank I'm not sure about most of these, but I'd like to note that wpa-supplicant is not a wireless-only tool (that one of your sentences seem to imply). I use it at dorm to authenticate to wired network (as well as at home to authenticate to home wifi network). And because some NM features clearly require its presence, it would be broken if it did not require it. Which is exactly why NM requires the supplicant, because without it, you can't connect to 802.1x-protected *wired* networks like yours, and you can't just plug in a wifi adapter and have it work out of the box. Dan -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rpm package with many files inside
On Mon, Jun 22, 2009 at 02:55:04 -0400, Jan Chadima jchad...@redhat.com wrote: I need to create rpm package with cca 50-100 tiny files inside. The whole tree is about 2-3GB binary data. Koji dies with error: Unable to create immutable header region. There are existing bug Fedora seems to build file systems with around 2.5 M inodes these days (at least on ext3) and you are creating a number of files that is a significant fraction of that. I have some fairly full installs that already install uses about half of that (around 1.3 M inodes) on the root file system. A couple packages like this are going to break things with the default inode limits. (It used to be that the default number of inodes allowed scaled up to larger values; on the order of 10 M.) -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Changing the default 32-bit x86 arch for Fedora 12 (#2)
Glen Turner (g...@gdt.id.au) said: On 19/06/09 00:19, Bill Nottingham wrote: No, period - I haven't seen anyone in the community say that they're testing it on i586-class hardware. Hi Bill, Your wiki page has some jargon (i586) which I'm trying to reduce to manufacturer products, as you have already done for the AMD products. F12 x86 will not work on i586 (or i686 without CMOV) Intel Pentium Intel Pentium Pro PPro has cmov, AFAIK. Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Changing the default 32-bit x86 arch for Fedora 12 (#2)
No, period - I haven't seen anyone in the community say that they're testing it on i586-class hardware. Hi Bill, Your wiki page has some jargon (i586) which I'm trying to reduce to manufacturer products, as you have already done for the AMD products. F12 x86 will not work on i586 (or i686 without CMOV) Intel Pentium Intel Pentium Pro PPro has cmov, AFAIK. Yes, its i686. Peter -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rawhide report: 20090621 changes
Horst H. von Brand (vonbr...@inf.utfsm.cl) said: Rawhide Report rawh...@fedoraproject.org wrote: Compose started at Sun Jun 21 06:15:09 UTC 2009 Here (x86_64) yum tries to install a raft of *.i586 packages without matching *.x86_64 (like libfprint-0.1.0-8.pre2.fc12). Almost nothing is x86_64, it seems. Not even the kernel is available. BTW, yum-3.2.23-6.fc12.noarch A yum API change caused the compose to 'succeed', but in a very broken way. (See the PPC tree for more fun.) It will be fixed for the next rawhide, which may be tomorrows. Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Packaging PHP
Le 22/06/2009 16:46, Christopher Stone a écrit : On Mon, Jun 22, 2009 at 6:02 AM, Patrick MONNERATp...@datasphere.ch wrote: fedora-php-devel-list or fedora-packaging are better place for this discussion, already raised (by me) in : - https://www.redhat.com/archives/fedora-php-devel-list/2009-June/msg0.html - https://www.redhat.com/archives/fedora-packaging/2009-June/msg00087.html I'm currently packaging some PHP classes: if I follow the packaging guideline at http://fedoraproject.org/wiki/Packaging:PHP#File_Placement, class files should appear directly in /usr/share/php, not in an extension-specific sub-directory. Yes Guidelines is very short about this (but didn't say directly). This seems rather rude: this rule will sooner or later cause name collision between files from packages and the directory will grow up to a mess very fast. Yes, this seems really obvious Would it be possible to alter this rule to allow package-specific sub-directories ? I know some packages go already this way (is it by special authorization?). Guidelines didn't forbid the use of a subdirectory This even seems implicit (at least for some of us) Maybe my understanding of this simple rule is too strict. In this case, I think it should be stated in more permissive terms. You're supposed to be using subdirectories under /usr/share/php. Look at the php-Smarty package as an example, it was the first package to use this directory and I was the one who pushed to create this directory for other packages. The guidelines just need to be re-worded. Il will propose an Guidelines update ASAP. Please, fix your pending reviews to use a subdirectories. Regards Remi Regards, Chris -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why do we need FC version attached to the package name?
On Mon, Jun 22, 2009 at 8:32 AM, Dave Jonesda...@redhat.com wrote: Considering these updates are supposed to be for our 'stable' release, having them be in $nextrelease first seems like a good idea anyway. including rawhide? Do you want security fix updates to block on rawhide not composing in order to prevent an upgrade path breakage. -jef? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Packaging PHP
On Mon, 2009-06-22 at 07:46 -0700, Christopher Stone wrote: Hi Chris, You're supposed to be using subdirectories under /usr/share/php. Many thanks for precising it. The guidelines just need to be re-worded. Oh yes, please do ! Thanks for the reply Regards, Patrick -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Changing the default 32-bit x86 arch for Fedora 12 (#2)
Why can't you just leave it as-is? I mean is 1% improvement (for cpu intensive workload) really worth changing anything? Instead of messing arround with stuff like that, I guess a lot of code would benefit of beeing build with profile driven optimizations, which often yields a 5-15% improvement without sacrifycing anything. On amd64 it would even enable the auto-vectorizer (if enabled) to vectorize only parts which count, without bloating code unescessary. However that would be _real_ work, instead of just changing switches and discussing it forth and back ;) - Clemens -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why do we need FC version attached to the package name?
On Mon, 22 Jun 2009 14:18:39 -0400, Tom wrote: Jeff Spaleta writes: On Mon, Jun 22, 2009 at 8:32 AM, Dave Jones wrote: Considering these updates are supposed to be for our 'stable' release, having them be in $nextrelease first seems like a good idea anyway. including rawhide? Yes, with exceptions and creating a warning at least. See below. Do you want security fix updates to block on rawhide not composing in order to prevent an upgrade path breakage. Not really, although the same question applies also to the other dists. Theoretically it would be possible that temporary build problems with a newer dist could cause a security fix for an older dist to be blocked. (e.g. foo-2.1-1.fc10 being ready to be pushed, but fc11 being stuck at foo-2.0-1.fc11 because foo-2.1-1.fc11 fails to build due to arbitrary issues one can imagine) You could work around that by using a suitable definition of pushed. (You'd need a careful definition anyway, to not fail on an update request that's trying to push to all the back branches at once.) However, there's still an issue if rawhide is so badly broken that a package won't even *build* there, as we know happens occasionally. *Then* any such package that doesn't build in rawhide and would block updates for older dists shall be put onto a special MUST-FIX list that blocks Rawhide instead, so Rawhide cannot become the next Fedora release before these missing packages have been built successfully. With regard to security issues, you either run Rawhide already and then you may be vulnerable as long as the fix can't be built. Or you use an older dist release and you can get the fix for that dist, but in case of dependency problems and violated upgrade path to Rawhide, you can't upgrade to Rawhide. Tons better than upgrade issues between stable Fedora releases. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Suggestion for improvement https://admin.fedoraproject.org/community
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hallo, in the Fedora Weekly News there was an announcement about the new community portal for Fedora. After I have taken a first look, I want to make the following suggestion. It may be helpful if you can see on the user profile, if the user are a sponsor of the packager group. Nowaday, you have none indicator about this state on the user profile. Best Regards: Jochen Schmitt -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAko/2AEACgkQT2AHK6txfgysTQCdGGQmDPSt9nkslI4442Bf92Mt UiUAn2txpD2/0yZTGZcykAs/Wudx3mnd =3/JV -END PGP SIGNATURE- -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why do we need FC version attached to the package name?
On Jun 22, 2009, at 18:32, Dave Jones da...@redhat.com wrote: On Mon, Jun 22, 2009 at 09:31:32AM +0200, Jesse Keating wrote: On Jun 22, 2009, at 9:26, Rahul Sundaram sunda...@fedoraproject.org wrote: On 06/22/2009 12:54 PM, Jesse Keating wrote: Not possible while we allow people to keep making updates to the older releases. Those updates quickly become version ( not just release even ) higher than the static copies on the release medium and repos. Is there any proposed solution to this problem? We can't just continue to break upgrade paths and call it the way things are done. Rahul If you have any ideas I'd like to hear them. A super epoch has already been suggested but that just masks the problem and may cause unwanted downgrades. Any solution either involves severly limiting what kind of updates can be done or requiring network access during upgrades. How about something in bodhi that checks you aren't introducing this problem, forcing you to push a higher NVR package to $nextrelease first before you can push it to updates? Considering these updates are supposed to be for our 'stable' release, having them be in $nextrelease first seems like a good idea anyway. Doesn't actually help when upgrading from the static DVD or release repo. Updates to the new release have to be enabled at upgrade time for this to help. -- Jes -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Changing the default 32-bit x86 arch for Fedora 12 (#2)
Clemens Eisserer linuxhi...@gmail.com writes: I mean is 1% improvement (for cpu intensive workload) really worth changing anything? No, especially if it screws somebody (not me though). -- Krzysztof Halasa -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Spins SIG could use some more active participants
Our Spins SIG meetings have been pretty poorly attended recently (just nirik and I) and our Spins Wrangler for F11 has resigned from that position for F12. nirik does not have time to take a more active role and I want to limit my work in the Spins SIG to technical stuff and the Games Spin. I really don't have a good big picture view of Spins. I am not sure if kanarip has just been short on time recently or if he is looking to change his level of involvement in the Spins SIG on a long term basis. Besides needing a new wrangler, we need to get processes for recurring and discontinued Spins created. P.S. I screwed up the devel list address the first time I tried to send this. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rpm package with many files inside
Jan Chadima wrote: Hello All I need to create rpm package with cca 50-100 tiny files inside. The whole tree is about 2-3GB binary data. Koji dies with error: Unable to create immutable header region. There are existing bug One million files means (at 4KiB per file even if its length is one byte) about 4GiB of space on most filesystems (everyone except reiserfs, IIRC). And I don't want to imagine the stress that one-million-files rpms can cause to the rpm/yum machinery, which is quite slow even in normal usage. -- Roberto Ragusamail at robertoragusa.it -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: F11 deltarpms being built against rawhide base release
On Sat, Jun 20, 2009 at 08:16:30AM -0400, Josh Boyer wrote: On Sat, Jun 20, 2009 at 08:04:21AM -0400, Josh Boyer wrote: On Sat, Jun 20, 2009 at 01:49:14PM +0300, Jonathan Dieter wrote: On Sat, 2009-06-20 at 14:08 +1000, Bradley Baetz wrote: Hi, Running F11 (x86_64), I've noticed that not all updates have deltarpms built for them. It looks like there is one built for the package, but the source version is wrong. For example gvfs-1.2.3-6.f11 is in the latest set of updates. I currently have 1.2.3-2.f11 installed, but the drpm is gvfs-1.2.3-3.fc12_1.2.3-6.fc11.x86_64.drpm, (f12, not f11, and 1.2.3-3 never got pushed to f11) which won't work... Presumably there should be drpms built against release+prev-update, or ideally one drpm for any update released in the previous week. Other packages (openssl, qemu) don't seem to have .drpms built at all. I would suggest creating a bug report against createrepo for the wrong source rpm. This sounds more like a mash config issue than a createrepo bug. I've filed ticket 1938 against rel-eng. Hopefully we can get this fixed before the next updates push. I just pushed out a new version of bodhi into production with a fix. luke -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
autodownloader, live spins and packaging
I am the maintainer of the Live Games Spin and am looking for feedback on dealing with games (though this could apply to other types of packages as well) that have some of their content obtained using autodownloader. Currently I don't want to include games that can only be played using downloaded content on the Live Games Spin. I don't think that gives a good experience using the Live Games Spin as a demo (which is what I think its focus should be). And space is tight right now so cutting things that used the auotdownloader first was a useful way to get down to size. However, it's possible that lzma compression of live images might be available for F12, which would allow me to add back some game packages that had to be cut because of space. While I still wouldn't want to include games that were only playable using autodownloader, there are some packages that have some data included in Fedora and other data that gets downloaded. So that you can play some of the games without having to download data, but not all of them. For example the quake3 package is needed for some games in Fedora, but it makes menu items for some games that are only playable with large downloads. For the games spin, I'd like to be able to either not show menu items for the games that need downloaded data or have a way to not include the game stubs that need downloaded data to play. I don't believe the first option is allowed for spins. So I am thinking of filing RFEs against packages this applies to, to split out the autodownloader stuff into a separate rpm that is optional. Does this sound reasonable? If so, is this something that should be recommended in a packaging guideline? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
rpms/perl-Mouse/devel .cvsignore, 1.9, 1.10 perl-Mouse.spec, 1.10, 1.11 sources, 1.9, 1.10
Author: cweyl
Update of /cvs/extras/rpms/perl-Mouse/devel
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv12140
Modified Files:
.cvsignore perl-Mouse.spec sources
Log Message:
* Mon Jun 22 2009 Chris Weyl cw...@alumni.drew.edu 0.25-1
- auto-update to 0.25 (by cpan-spec-update 0.01)
- altered req on perl(Scalar::Util) (1.19 = 1.14)
Index: .cvsignore
===
RCS file: /cvs/extras/rpms/perl-Mouse/devel/.cvsignore,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -p -r1.9 -r1.10
--- .cvsignore 2 Jun 2009 07:16:59 - 1.9
+++ .cvsignore 22 Jun 2009 07:20:30 - 1.10
@@ -1 +1 @@
-Mouse-0.23.tar.gz
+Mouse-0.25.tar.gz
Index: perl-Mouse.spec
===
RCS file: /cvs/extras/rpms/perl-Mouse/devel/perl-Mouse.spec,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -p -r1.10 -r1.11
--- perl-Mouse.spec 2 Jun 2009 07:16:59 - 1.10
+++ perl-Mouse.spec 22 Jun 2009 07:20:30 - 1.11
@@ -1,5 +1,5 @@
Name: perl-Mouse
-Version:0.23
+Version:0.25
Release:1%{?dist}
License:GPL+ or Artistic
Group: Development/Libraries
@@ -25,7 +25,7 @@ BuildRequires: perl(Test::More) = 0.8
# recommends in rpm yet, let's manually require them here.
Requires: perl(Class::Method::Modifiers) = 1.01
Requires: perl(Test::Exception) = 0.27
-Requires: perl(Scalar::Util) = 1.19
+Requires: perl(Scalar::Util) = 1.14
Requires: perl(MRO::Compat) = 0.09
@@ -81,6 +81,10 @@ rm -rf %{buildroot}
%{_mandir}/man3/*.3*
%changelog
+* Mon Jun 22 2009 Chris Weyl cw...@alumni.drew.edu 0.25-1
+- auto-update to 0.25 (by cpan-spec-update 0.01)
+- altered req on perl(Scalar::Util) (1.19 = 1.14)
+
* Tue Jun 02 2009 Chris Weyl cw...@alumni.drew.edu 0.23-1
- auto-update to 0.23 (by cpan-spec-update 0.01)
- altered br on perl(Test::Exception) (0 = 0.21)
Index: sources
===
RCS file: /cvs/extras/rpms/perl-Mouse/devel/sources,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -p -r1.9 -r1.10
--- sources 2 Jun 2009 07:16:59 - 1.9
+++ sources 22 Jun 2009 07:20:31 - 1.10
@@ -1 +1 @@
-ee51652607053ee0be56aff304a5bc07 Mouse-0.23.tar.gz
+97dbe3320902d3e769795849c26884f7 Mouse-0.25.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
Fedora-perl-devel-list mailing list
Fedora-perl-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
rpms/perl-Mouse/F-11 perl-Mouse.spec,1.10,1.11 sources,1.9,1.10
Author: cweyl
Update of /cvs/extras/rpms/perl-Mouse/F-11
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv15393
Modified Files:
perl-Mouse.spec sources
Log Message:
* Mon Jun 22 2009 Chris Weyl cw...@alumni.drew.edu 0.25-1
- auto-update to 0.25 (by cpan-spec-update 0.01)
- altered req on perl(Scalar::Util) (1.19 = 1.14)
Index: perl-Mouse.spec
===
RCS file: /cvs/extras/rpms/perl-Mouse/F-11/perl-Mouse.spec,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -p -r1.10 -r1.11
--- perl-Mouse.spec 2 Jun 2009 07:27:56 - 1.10
+++ perl-Mouse.spec 22 Jun 2009 07:41:09 - 1.11
@@ -1,5 +1,5 @@
Name: perl-Mouse
-Version:0.23
+Version:0.25
Release:1%{?dist}
License:GPL+ or Artistic
Group: Development/Libraries
@@ -25,7 +25,7 @@ BuildRequires: perl(Test::More) = 0.8
# recommends in rpm yet, let's manually require them here.
Requires: perl(Class::Method::Modifiers) = 1.01
Requires: perl(Test::Exception) = 0.27
-Requires: perl(Scalar::Util) = 1.19
+Requires: perl(Scalar::Util) = 1.14
Requires: perl(MRO::Compat) = 0.09
@@ -81,6 +81,10 @@ rm -rf %{buildroot}
%{_mandir}/man3/*.3*
%changelog
+* Mon Jun 22 2009 Chris Weyl cw...@alumni.drew.edu 0.25-1
+- auto-update to 0.25 (by cpan-spec-update 0.01)
+- altered req on perl(Scalar::Util) (1.19 = 1.14)
+
* Tue Jun 02 2009 Chris Weyl cw...@alumni.drew.edu 0.23-1
- auto-update to 0.23 (by cpan-spec-update 0.01)
- altered br on perl(Test::Exception) (0 = 0.21)
Index: sources
===
RCS file: /cvs/extras/rpms/perl-Mouse/F-11/sources,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -p -r1.9 -r1.10
--- sources 2 Jun 2009 07:27:56 - 1.9
+++ sources 22 Jun 2009 07:41:09 - 1.10
@@ -1 +1 @@
-ee51652607053ee0be56aff304a5bc07 Mouse-0.23.tar.gz
+97dbe3320902d3e769795849c26884f7 Mouse-0.25.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
Fedora-perl-devel-list mailing list
Fedora-perl-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
rpms/perl-Mouse/F-10 perl-Mouse.spec,1.9,1.10 sources,1.9,1.10
Author: cweyl
Update of /cvs/extras/rpms/perl-Mouse/F-10
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv15459
Modified Files:
perl-Mouse.spec sources
Log Message:
* Mon Jun 22 2009 Chris Weyl cw...@alumni.drew.edu 0.25-1
- auto-update to 0.25 (by cpan-spec-update 0.01)
- altered req on perl(Scalar::Util) (1.19 = 1.14)
Index: perl-Mouse.spec
===
RCS file: /cvs/extras/rpms/perl-Mouse/F-10/perl-Mouse.spec,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -p -r1.9 -r1.10
--- perl-Mouse.spec 2 Jun 2009 07:28:01 - 1.9
+++ perl-Mouse.spec 22 Jun 2009 07:41:18 - 1.10
@@ -1,5 +1,5 @@
Name: perl-Mouse
-Version:0.23
+Version:0.25
Release:1%{?dist}
License:GPL+ or Artistic
Group: Development/Libraries
@@ -25,7 +25,7 @@ BuildRequires: perl(Test::More) = 0.8
# recommends in rpm yet, let's manually require them here.
Requires: perl(Class::Method::Modifiers) = 1.01
Requires: perl(Test::Exception) = 0.27
-Requires: perl(Scalar::Util) = 1.19
+Requires: perl(Scalar::Util) = 1.14
Requires: perl(MRO::Compat) = 0.09
@@ -81,6 +81,10 @@ rm -rf %{buildroot}
%{_mandir}/man3/*.3*
%changelog
+* Mon Jun 22 2009 Chris Weyl cw...@alumni.drew.edu 0.25-1
+- auto-update to 0.25 (by cpan-spec-update 0.01)
+- altered req on perl(Scalar::Util) (1.19 = 1.14)
+
* Tue Jun 02 2009 Chris Weyl cw...@alumni.drew.edu 0.23-1
- auto-update to 0.23 (by cpan-spec-update 0.01)
- altered br on perl(Test::Exception) (0 = 0.21)
Index: sources
===
RCS file: /cvs/extras/rpms/perl-Mouse/F-10/sources,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -p -r1.9 -r1.10
--- sources 2 Jun 2009 07:28:02 - 1.9
+++ sources 22 Jun 2009 07:41:18 - 1.10
@@ -1 +1 @@
-ee51652607053ee0be56aff304a5bc07 Mouse-0.23.tar.gz
+97dbe3320902d3e769795849c26884f7 Mouse-0.25.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
Fedora-perl-devel-list mailing list
Fedora-perl-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
[Bug 416781] SOAP::Lite contains useful examples not packaged under %doc
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=416781 --- Comment #7 from Jan Pazdziora jpazdzi...@redhat.com 2009-06-22 03:39:20 EDT --- Confirming fixed in perl-SOAP-Lite-0.710.08-2.fc11.noarch, thanks. -- 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 Fedora-perl-devel-list mailing list Fedora-perl-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
[Bug 506496] tkmib failed
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=506496 Jan Safranek jsafr...@redhat.com changed: What|Removed |Added CC||andreas.bierf...@lowlatency ||.de, ||fedora-perl-devel-l...@redh ||at.com Component|net-snmp|perl-Tk AssignedTo|jsafr...@redhat.com |andreas.bierf...@lowlatency ||.de --- Comment #1 from Jan Safranek jsafr...@redhat.com 2009-06-22 04:55:34 EDT --- I think you hit a bug in perl-Tk package, which is probably fixed upstream: http://rt.cpan.org/Public/Bug/Display.html?id=38746 -- 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 Fedora-perl-devel-list mailing list Fedora-perl-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
rpms/perl-Pod-Abstract/F-11 perl-Pod-Abstract.spec, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2
Author: mmaslano
Update of /cvs/pkgs/rpms/perl-Pod-Abstract/F-11
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv3657
Modified Files:
.cvsignore sources
Added Files:
perl-Pod-Abstract.spec
Log Message:
* Mon Jun 08 2009 Marcela MaÅ¡láÅová mmasl...@redhat.com 0.17-2
- fix rpmlint warnings
--- NEW FILE perl-Pod-Abstract.spec ---
Name: perl-Pod-Abstract
Version:0.17
Release:2%{?dist}
Summary:Abstract document tree for Perl POD documents
License:GPL+ or Artistic
Group: Development/Libraries
URL:http://search.cpan.org/dist/Pod-Abstract/
Source0:
http://www.cpan.org/authors/id/B/BL/BLILBURNE/Pod-Abstract-%{version}.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch: noarch
BuildRequires: perl(ExtUtils::MakeMaker)
BuildRequires: perl(IO::String)
BuildRequires: perl(Test::More)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
%description
POD::Abstract provides a means to load a POD (or POD compatible) document
without direct reference to it's syntax, and perform manipulations on the
abstract syntax tree.
%prep
%setup -q -n Pod-Abstract-%{version}
chmod 644 lib/Pod/Abstract/Filter/*.pm
%build
%{__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/*
%check
make test
%clean
rm -rf $RPM_BUILD_ROOT
%files
%defattr(-,root,root,-)
%doc Changes README
%{perl_vendorlib}/*
%{_mandir}/man3/*
%{_bindir}/paf
%{_mandir}/man1/paf.1.gz
%changelog
* Mon Jun 08 2009 Marcela MaÅ¡láÅová mmasl...@redhat.com 0.17-2
- fix rpmlint warnings
* Thu Jun 04 2009 Marcela MaÅ¡láÅová mmasl...@redhat.com 0.17-1
- Specfile autogenerated by cpanspec 1.78.
Index: .cvsignore
===
RCS file: /cvs/pkgs/rpms/perl-Pod-Abstract/F-11/.cvsignore,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- .cvsignore 20 Jun 2009 15:01:56 - 1.1
+++ .cvsignore 22 Jun 2009 11:36:15 - 1.2
@@ -0,0 +1 @@
+Pod-Abstract-0.17.tar.gz
Index: sources
===
RCS file: /cvs/pkgs/rpms/perl-Pod-Abstract/F-11/sources,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- sources 20 Jun 2009 15:01:57 - 1.1
+++ sources 22 Jun 2009 11:36:16 - 1.2
@@ -0,0 +1 @@
+414ed18145c1d8a73269d46de62c78a3 Pod-Abstract-0.17.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
Fedora-perl-devel-list mailing list
Fedora-perl-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
rpms/perl-Pod-Abstract/devel perl-Pod-Abstract.spec, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2
Author: mmaslano
Update of /cvs/pkgs/rpms/perl-Pod-Abstract/devel
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv5882
Modified Files:
.cvsignore sources
Added Files:
perl-Pod-Abstract.spec
Log Message:
* Mon Jun 08 2009 Marcela MaÅ¡láÅová mmasl...@redhat.com 0.17-2
- fix rpmlint warnings
--- NEW FILE perl-Pod-Abstract.spec ---
Name: perl-Pod-Abstract
Version:0.17
Release:2%{?dist}
Summary:Abstract document tree for Perl POD documents
License:GPL+ or Artistic
Group: Development/Libraries
URL:http://search.cpan.org/dist/Pod-Abstract/
Source0:
http://www.cpan.org/authors/id/B/BL/BLILBURNE/Pod-Abstract-%{version}.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch: noarch
BuildRequires: perl(ExtUtils::MakeMaker)
BuildRequires: perl(IO::String)
BuildRequires: perl(Test::More)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
%description
POD::Abstract provides a means to load a POD (or POD compatible) document
without direct reference to it's syntax, and perform manipulations on the
abstract syntax tree.
%prep
%setup -q -n Pod-Abstract-%{version}
chmod 644 lib/Pod/Abstract/Filter/*.pm
%build
%{__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/*
%check
make test
%clean
rm -rf $RPM_BUILD_ROOT
%files
%defattr(-,root,root,-)
%doc Changes README
%{perl_vendorlib}/*
%{_mandir}/man3/*
%{_bindir}/paf
%{_mandir}/man1/paf.1.gz
%changelog
* Mon Jun 08 2009 Marcela MaÅ¡láÅová mmasl...@redhat.com 0.17-2
- fix rpmlint warnings
* Thu Jun 04 2009 Marcela MaÅ¡láÅová mmasl...@redhat.com 0.17-1
- Specfile autogenerated by cpanspec 1.78.
Index: .cvsignore
===
RCS file: /cvs/pkgs/rpms/perl-Pod-Abstract/devel/.cvsignore,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- .cvsignore 20 Jun 2009 15:01:56 - 1.1
+++ .cvsignore 22 Jun 2009 11:46:00 - 1.2
@@ -0,0 +1 @@
+Pod-Abstract-0.17.tar.gz
Index: sources
===
RCS file: /cvs/pkgs/rpms/perl-Pod-Abstract/devel/sources,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- sources 20 Jun 2009 15:01:57 - 1.1
+++ sources 22 Jun 2009 11:46:00 - 1.2
@@ -0,0 +1 @@
+414ed18145c1d8a73269d46de62c78a3 Pod-Abstract-0.17.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
Fedora-perl-devel-list mailing list
Fedora-perl-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
rpms/perl-JSON/devel .cvsignore, 1.10, 1.11 perl-JSON.spec, 1.13, 1.14 sources, 1.10, 1.11
Author: cweyl
Update of /cvs/extras/rpms/perl-JSON/devel
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv7631
Modified Files:
.cvsignore perl-JSON.spec sources
Log Message:
* Mon Jun 22 2009 Chris Weyl cw...@alumni.drew.edu 2.15-1
- auto-update to 2.15 (by cpan-spec-update 0.01)
Index: .cvsignore
===
RCS file: /cvs/extras/rpms/perl-JSON/devel/.cvsignore,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -p -r1.10 -r1.11
--- .cvsignore 1 Mar 2009 23:38:33 - 1.10
+++ .cvsignore 22 Jun 2009 15:06:42 - 1.11
@@ -1 +1 @@
-JSON-2.14.tar.gz
+JSON-2.15.tar.gz
Index: perl-JSON.spec
===
RCS file: /cvs/extras/rpms/perl-JSON/devel/perl-JSON.spec,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -p -r1.13 -r1.14
--- perl-JSON.spec 1 Mar 2009 23:38:33 - 1.13
+++ perl-JSON.spec 22 Jun 2009 15:06:42 - 1.14
@@ -1,11 +1,11 @@
Name: perl-JSON
-Version:2.14
+Version:2.15
Release:1%{?dist}
Summary:Parse and convert to JSON (JavaScript Object Notation)
License:GPL+ or Artistic
Group: Development/Libraries
URL:http://search.cpan.org/dist/JSON/
-Source0:
http://www.cpan.org/authors/id/M/MA/MAKAMAKA/JSON-%{version}.tar.gz
+Source0:
http://search.cpan.org/CPAN/authors/id/M/MA/MAKAMAKA/JSON-%{version}.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch: noarch
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
@@ -27,7 +27,6 @@ Requires: perl(Scalar::Util)
Requires: perl(LWP::UserAgent)
Requires: perl(HTTP::Daemon)
-
%description
This module converts between JSON (JavaScript Object Notation) and Perl
data structure into each other. For JSON, See to
@@ -37,7 +36,7 @@ http://www.crockford.com/JSON/.
%setup -q -n JSON-%{version}
# make rpmlint happy...
-find . -type f -exec chmod -c -x {} +
+find . -type f -exec chmod -c -x {} +
find t/ -type f -exec perl -pi -e 's|^#! perl|#!/usr/bin/perl|' {} +
sed -i 's/\r//' README t/*
@@ -78,6 +77,9 @@ rm -rf %{buildroot}
%{_mandir}/man3/*
%changelog
+* Mon Jun 22 2009 Chris Weyl cw...@alumni.drew.edu 2.15-1
+- auto-update to 2.15 (by cpan-spec-update 0.01)
+
* Sun Mar 01 2009 Chris Weyl cw...@alumni.drew.edu 2.14-1
- update to 2.14
Index: sources
===
RCS file: /cvs/extras/rpms/perl-JSON/devel/sources,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -p -r1.10 -r1.11
--- sources 1 Mar 2009 23:38:33 - 1.10
+++ sources 22 Jun 2009 15:06:42 - 1.11
@@ -1 +1 @@
-340d2e9eb18406e18c88475d7aa25edc JSON-2.14.tar.gz
+15de50d89da9a0c389d3fb1a4aef84d0 JSON-2.15.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
Fedora-perl-devel-list mailing list
Fedora-perl-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
[Bug 491536] cssh is broken
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=491536 --- Comment #13 from Fedora Update System upda...@fedoraproject.org 2009-06-22 13:02:29 EDT --- perl-Tk-804.028-8.fc10 has been submitted as an update for Fedora 10. http://admin.fedoraproject.org/updates/perl-Tk-804.028-8.fc10 -- 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 Fedora-perl-devel-list mailing list Fedora-perl-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
[Bug 489228] Keyboard does not work in perl-Tk programs
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=489228 --- Comment #15 from Fedora Update System upda...@fedoraproject.org 2009-06-22 13:02:23 EDT --- perl-Tk-804.028-8.fc10 has been submitted as an update for Fedora 10. http://admin.fedoraproject.org/updates/perl-Tk-804.028-8.fc10 -- 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 Fedora-perl-devel-list mailing list Fedora-perl-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
[Bug 489228] Keyboard does not work in perl-Tk programs
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=489228 --- Comment #16 from Fedora Update System upda...@fedoraproject.org 2009-06-22 13:03:14 EDT --- perl-Tk-804.028-8.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/perl-Tk-804.028-8.fc11 -- 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 Fedora-perl-devel-list mailing list Fedora-perl-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
[Bug 506496] tkmib failed
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=506496 --- Comment #2 from Fedora Update System upda...@fedoraproject.org 2009-06-22 13:02:35 EDT --- perl-Tk-804.028-8.fc10 has been submitted as an update for Fedora 10. http://admin.fedoraproject.org/updates/perl-Tk-804.028-8.fc10 -- 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 Fedora-perl-devel-list mailing list Fedora-perl-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
[Bug 491536] cssh is broken
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=491536 --- Comment #14 from Fedora Update System upda...@fedoraproject.org 2009-06-22 13:03:19 EDT --- perl-Tk-804.028-8.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/perl-Tk-804.028-8.fc11 -- 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 Fedora-perl-devel-list mailing list Fedora-perl-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
[Bug 506496] tkmib failed
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=506496 --- Comment #3 from Fedora Update System upda...@fedoraproject.org 2009-06-22 13:03:24 EDT --- perl-Tk-804.028-8.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/perl-Tk-804.028-8.fc11 -- 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 Fedora-perl-devel-list mailing list Fedora-perl-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
[Bug 487122] getOpenFile fails if -multiple is set
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=487122 --- Comment #2 from Ieuan Clay ieuan.c...@bbsrc.ac.uk 2009-06-22 13:08:09 EDT --- http://rt.cpan.org/Public/Bug/Display.html?id=31989 Solves problem -- 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 Fedora-perl-devel-list mailing list Fedora-perl-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
[Bug 491536] cssh is broken
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=491536 --- Comment #15 from Need Real Name l...@nodata.co.uk 2009-06-22 13:14:25 EDT --- WFM THANKS! -- 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 Fedora-perl-devel-list mailing list Fedora-perl-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
[Bug 507490] New: Garbled text terminal display
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
Summary: Garbled text terminal display
https://bugzilla.redhat.com/show_bug.cgi?id=507490
Summary: Garbled text terminal display
Product: Fedora
Version: 11
Platform: x86_64
OS/Version: Linux
Status: NEW
Severity: low
Priority: low
Component: amavisd-new
AssignedTo: st...@silug.org
ReportedBy: sin...@gnu.org
QAContact: extras...@fedoraproject.org
CC: st...@silug.org, fedora-perl-devel-list@redhat.com
Classification: Fedora
Description of problem: From startx (init 3), or init 5, with framebuffer
enabled (I haven't tested with it disabled: vga=792) on a t61p, when X is
running I get garbled (wavey line) display on text terminal (it is usable, but
only typing blindly).
Steps to Reproduce:
1. Nvidia Quadro FX 570M
2. Nouveau driver (with or without xorg.conf)
3. From runlevel 3, run startx, or init 5 (with gdm)
4. Switch with C-M-Del-F{2..6} to text terminal
Actual results: Garbled display on text terminal
Expected results: Text terminal Login prompt (with /etc/issue text)
--
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
Fedora-perl-devel-list mailing list
Fedora-perl-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
[Bug 504389] RFE: update to 0.11
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=504389 Bernard Johnson bjohn...@symetrix.com changed: What|Removed |Added Blocks||507491 -- 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 Fedora-perl-devel-list mailing list Fedora-perl-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
[Bug 507490] Garbled text terminal display
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=507490 Jason Tibbitts ti...@math.uh.edu changed: What|Removed |Added CC|fedora-perl-devel-l...@redh |airl...@redhat.com, |at.com, st...@silug.org |a...@redhat.com, ||bske...@redhat.com Component|amavisd-new |xorg-x11-drv-nouveau AssignedTo|st...@silug.org |bske...@redhat.com --- Comment #1 from Jason Tibbitts ti...@math.uh.edu 2009-06-22 20:26:58 EDT --- I can't figure out what this could possibly have to do with amavisd-new. Reassigning to xorg-x11-drv-nouveau, although it might be better to assign it to kernel. -- 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 Fedora-perl-devel-list mailing list Fedora-perl-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
rpms/perl-JSON/F-10 perl-JSON.spec,1.10,1.11 sources,1.9,1.10
Author: cweyl
Update of /cvs/extras/rpms/perl-JSON/F-10
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv13487
Modified Files:
perl-JSON.spec sources
Log Message:
* Mon Jun 22 2009 Chris Weyl cw...@alumni.drew.edu 2.15-1
- auto-update to 2.15 (by cpan-spec-update 0.01)
Index: perl-JSON.spec
===
RCS file: /cvs/extras/rpms/perl-JSON/F-10/perl-JSON.spec,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -p -r1.10 -r1.11
--- perl-JSON.spec 13 Oct 2008 04:26:45 - 1.10
+++ perl-JSON.spec 23 Jun 2009 05:24:57 - 1.11
@@ -1,11 +1,11 @@
Name: perl-JSON
-Version:2.12
+Version:2.15
Release:1%{?dist}
Summary:Parse and convert to JSON (JavaScript Object Notation)
License:GPL+ or Artistic
Group: Development/Libraries
URL:http://search.cpan.org/dist/JSON/
-Source0:
http://www.cpan.org/authors/id/M/MA/MAKAMAKA/JSON-%{version}.tar.gz
+Source0:
http://search.cpan.org/CPAN/authors/id/M/MA/MAKAMAKA/JSON-%{version}.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch: noarch
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
@@ -27,7 +27,6 @@ Requires: perl(Scalar::Util)
Requires: perl(LWP::UserAgent)
Requires: perl(HTTP::Daemon)
-
%description
This module converts between JSON (JavaScript Object Notation) and Perl
data structure into each other. For JSON, See to
@@ -37,7 +36,7 @@ http://www.crockford.com/JSON/.
%setup -q -n JSON-%{version}
# make rpmlint happy...
-find . -type f -exec chmod -c -x {} +
+find . -type f -exec chmod -c -x {} +
find t/ -type f -exec perl -pi -e 's|^#! perl|#!/usr/bin/perl|' {} +
sed -i 's/\r//' README t/*
@@ -78,6 +77,18 @@ rm -rf %{buildroot}
%{_mandir}/man3/*
%changelog
+* Mon Jun 22 2009 Chris Weyl cw...@alumni.drew.edu 2.15-1
+- auto-update to 2.15 (by cpan-spec-update 0.01)
+
+* Sun Mar 01 2009 Chris Weyl cw...@alumni.drew.edu 2.14-1
+- update to 2.14
+
+* Thu Feb 26 2009 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 2.12-3
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_11_Mass_Rebuild
+
+* Thu Feb 26 2009 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 2.12-2
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_11_Mass_Rebuild
+
* Sun Oct 12 2008 Chris Weyl cw...@alumni.drew.edu 2.12-1
- update to 2.12
Index: sources
===
RCS file: /cvs/extras/rpms/perl-JSON/F-10/sources,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -p -r1.9 -r1.10
--- sources 13 Oct 2008 04:26:45 - 1.9
+++ sources 23 Jun 2009 05:24:57 - 1.10
@@ -1 +1 @@
-5719ba98f607003295d99952c2ac2ea7 JSON-2.12.tar.gz
+15de50d89da9a0c389d3fb1a4aef84d0 JSON-2.15.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
Fedora-perl-devel-list mailing list
Fedora-perl-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
rpms/perl-Moose/devel perl-Moose.spec,1.41,1.42
Author: cweyl
Update of /cvs/extras/rpms/perl-Moose/devel
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv19148
Modified Files:
perl-Moose.spec
Log Message:
* Mon Jun 22 2009 Chris Weyl cw...@alumni.drew.edu 0.81-2
- split off Test::Moose
Index: perl-Moose.spec
===
RCS file: /cvs/extras/rpms/perl-Moose/devel/perl-Moose.spec,v
retrieving revision 1.41
retrieving revision 1.42
diff -u -p -r1.41 -r1.42
--- perl-Moose.spec 9 Jun 2009 08:29:05 - 1.41
+++ perl-Moose.spec 23 Jun 2009 05:46:24 - 1.42
@@ -1,6 +1,6 @@
Name: perl-Moose
Version:0.81
-Release:1%{?dist}
+Release:2%{?dist}
Summary:Complete modern object system for Perl 5
License:GPL+ or Artistic
Group: Development/Libraries
@@ -74,6 +74,17 @@ While Moose is very much inspired by Per
tired or writing the same old boring Perl 5 OO code, and drooling over
Perl 6 OO. So instead of switching to Ruby, I wrote Moose :)
+%package -n perl-Test-Moose
+License:GPL+ or Artistic
+Group: Development/Libraries
+Summary:Test functions for Moose specific features
+Requires: %{name} = %{version}-%{release}
+
+%description -n perl-Test-Moose
+This module provides some useful test functions for Moose based classes.
+It is an experimental first release, so comments and suggestions are
+very welcome.
+
%prep
%setup -q -n Moose-%{version}
@@ -105,9 +116,19 @@ rm -rf %{buildroot}
%defattr(-,root,root,-)
%doc Changes README doap.rdf t/
%{perl_vendorlib}/*
+%exclude %{perl_vendorlib}/Test
%{_mandir}/man3/*
+%exclude %{_mandir}/man3/Test::Moose*
+
+%files -n perl-Test-Moose
+%defattr(-,root,root,-)
+%{perl_vendorlib}/Test
+%{_mandir}/man3/Test::Moose*
%changelog
+* Mon Jun 22 2009 Chris Weyl cw...@alumni.drew.edu 0.81-2
+- split off Test::Moose
+
* Tue Jun 09 2009 Chris Weyl cw...@alumni.drew.edu 0.81-1
- auto-update to 0.81 (by cpan-spec-update 0.01)
- altered br on perl(Class::MOP) (0.83 = 0.85)
@@ -258,10 +279,3 @@ rm -rf %{buildroot}
* Sat Sep 02 2006 Chris Weyl cw...@alumni.drew.edu 0.12-1
- Specfile autogenerated by cpanspec 1.69.1.
-
-Checking : Moose-0.79.tar.gz on
https://cvs.fedoraproject.org/repo/pkgs/upload.cgi...
-Uploading: Moose-0.79.tar.gz to
https://cvs.fedoraproject.org/repo/pkgs/upload.cgi...
-
-Source upload succeeded. Don't forget to commit the new ./sources file
-M sources
-M .cvsignore
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
Fedora-perl-devel-list mailing list
Fedora-perl-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
