Re: autodownloader, live spins and packaging
On 06/23/2009 08:26 AM, Bruno Wolff III wrote: 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. No. It doesn't. Check again. Rahul -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Building packages for EPEL
On Sun, Jun 21, 2009 at 10:40 AM, Dennis Gilmoreden...@ausil.us wrote: EPEL is now using koji to build instead of plague. please make sure that you update th common directory in your checkout to pick up the needed changes to submit builds. Bodhi support will come early next week to issue updates. the buildroots are only populated by packages from stable if you need to build against something in testing or that you have just build please email your request to epel-rel...@lists.fedoraproject.org Nice one, thanks for putting in the work for this! This will be encouragement for me to build my packages for EPEL as a matter of course. (Laziness on my part prevents me from learning a second process.) -- Mat Booth www.matbooth.co.uk -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Localization versus Requires: aspell-en
Rex Dieter wrote: See also: https://bugzilla.redhat.com/show_bug.cgi?id=494084 Which led to aspell-en conditional being added to comps (Unfortunately, that doesn't help all cases) IMHO the Requires: aspell-en should come back. English is the default everywhere (*), I think it's a reasonable expectation that English should always work even if there's no langpack installed. Those odd packages which have a langpack for US English should drag it in by default. (*) except for the odd broken program which has the default C locale messages in French, AFAIK there's one of those in RPM Fusion, those ought to be fixed as C is supposed to be US English; programs using British spelling in the default locale should also be fixed Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Pulseaudio question...
Nathanael D. Noblet wrote: I've opened a movie in totem, the main volume level is somewhere in the range of 70%, however totem is at about 4%. The movie is too quiet so I've upped the volume in totem to 19%. The main volume is now 84%. All fine and good. However if I modify the main volume at all (up or down), the main volume resets to whatever the main volume was before I changed totem's volume. If I in this case bring the main volume up to 84% again, totem is at the 19% I set it to... Is this expected behaviour? I think this is the flat volumes feature. It can be disabled by setting: flat-volumes = no in /etc/pulse/daemon.conf or ~/.pulse/daemon.conf . Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PolicyKit and malware, was: What I HATE about F11
David Zeuthen wrote: (I'm not subscribed to fedora-devel so if you want replies from me don't remove me from the Cc.) Hmmm, I can't directly CC folks through Gmane, the best I can do is to use the KNode feature which copies the text into KMail. An example where 1. is useful includes, funny enough, a last guard against having malware dial 1-900 numbers in other countries at $50 per hour That scenario has malware in it. So it contradicts your earlier statement that: Anyway, the goal of PolicyKit isn't to fix the cope with malware in your session problem. Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Update descriptions hosed
On Sat, Jun 20, 2009 at 08:25:16PM -0400, Todd Zullinger wrote: Christoph Wickert wrote: What happened to these updates? https://admin.fedoraproject.org/updates/F11/FEDORA-2009-5739 https://admin.fedoraproject.org/updates/F11/FEDORA-2009-5966 Is it a bodhi failure or a human one (both are from the same submitter) I believe I've seen this happen when an update submission fails for some reason and you need to fix some part if it. I'm assuming the URLs get encoded when the update is submitted and after the error, the update text doesn't get converted back properly. Yeah, this is a regression that occurred within bodhi that causes some data to be urlescaped when there are errors in the form. https://fedorahosted.org/bodhi/ticket/311 It's quite annoying, so hopefully we can figure out what the deal is soon. luke -- 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)
- Optimize for Atom I also don't get this one. Why not optimize for the cpu architectur in use by most fedora-x86 users, like p4 or c2d? It seems crazy to optimize for a cpu with maybe 5% market share, just because its the only x86 cpu left. (by the way, the via C7 is still sold too). - Clemens -- 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) said: - Optimize for Atom I also don't get this one. Why not optimize for the cpu architectur in use by most fedora-x86 users, like p4 or c2d? It seems crazy to optimize for a cpu with maybe 5% market share, just because its the only x86 cpu left. (by the way, the via C7 is still sold too). 1) Optimizing for P4 is ... messy 2) If you're using C2D, etc., you can already use the 64-bit distro. Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rpms/php-pecl-geoip/devel import.log, NONE, 1.1 php-pecl-geoip.spec, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2
On 06/23/2009 11:36 PM, topdog wrote: Author: topdog Update of /cvs/pkgs/rpms/php-pecl-geoip/devel In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv2525/devel On the commits mailing list, instead of the author name at the From field, I see only a nick name. Why is that? Rahul -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Pulseaudio question...
On Tue, 2009-06-23 at 17:49 +0200, Kevin Kofler wrote: Nathanael D. Noblet wrote: I've opened a movie in totem, the main volume level is somewhere in the range of 70%, however totem is at about 4%. The movie is too quiet so I've upped the volume in totem to 19%. The main volume is now 84%. All fine and good. However if I modify the main volume at all (up or down), the main volume resets to whatever the main volume was before I changed totem's volume. If I in this case bring the main volume up to 84% again, totem is at the 19% I set it to... Is this expected behaviour? I think this is the flat volumes feature. It can be disabled by setting: flat-volumes = no in /etc/pulse/daemon.conf or ~/.pulse/daemon.conf . It may be related, but it's not the way that's _supposed_ to work, AIUI. When working correctly, with flat volumes, the two volumes should be the same, I believe - if you set totem to 70%, the 'main' volume slider in g-v-c or pavucontrol should also be at 70%. so it sounds like it may be some bug within the flat volume implementation. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- 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)
1) Optimizing for P4 is ... messy 2) If you're using C2D, etc., you can already use the 64-bit distro. So why not stay with generic, where most users would benefit. Sure I could use 64-bit, as could all the others using 32-bit on 64-bit capable CPUs (I guess 50% of all fedora-x86 users). - Clemens -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: update mechanism for new releases
On 06/24/2009 01:42 AM, Martin Langhoff wrote: On Tue, Jun 23, 2009 at 9:10 PM, Mathieu Bridon (bochecha)boche...@fedoraproject.org wrote: RPM has seen a lot of improvements in speed and memory consumption Are there any improvements on recovery of unexpectedly failed transactions, such as OOM, kernel oops or hard power-off? I think such questions can be better answered in the RPM upstream mailing list. It would be good for you to bring your concerns there. http://lists.rpm.org/mailman/listinfo/rpm-maint I am sure the RPM developers would be very interested in them. It is not true that RPM/Yum developers treat mid transaction failures as insolvable problems. Rahul -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: update mechanism for new releases
On Wed, 24 Jun 2009, Rahul Sundaram wrote: On 06/24/2009 01:42 AM, Martin Langhoff wrote: On Tue, Jun 23, 2009 at 9:10 PM, Mathieu Bridon (bochecha)boche...@fedoraproject.org wrote: RPM has seen a lot of improvements in speed and memory consumption Are there any improvements on recovery of unexpectedly failed transactions, such as OOM, kernel oops or hard power-off? I think such questions can be better answered in the RPM upstream mailing list. It would be good for you to bring your concerns there. http://lists.rpm.org/mailman/listinfo/rpm-maint I am sure the RPM developers would be very interested in them. It is not true that RPM/Yum developers treat mid transaction failures as insolvable problems. they're not insolvable - they are just very very very hard. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: update mechanism for new releases
On Tue, 23 Jun 2009, Martin Langhoff wrote: On Tue, Jun 23, 2009 at 10:33 PM, Seth Vidalskvi...@fedoraproject.org wrote: they're not insolvable - they are just very very very hard. :-) At the end of the day, if the OS doesn't give you atomic multi-file transactions, and your %pre/%post scripts aren't also written perfectly atomically, I would say that it _is_ impossible. In any case, are there reasons to believe that behaviour in rpm has improved (in F11) in the face of a powerloss in the middle of a transaction? If we start doing OS upgrades and removing power at random points, what chance does rpm of recover/resume? It is an admittedly hard question. So here's the short version: if you're doing an upgrade via yum, it writes out all of what it was intending to do. And it will ( to some extent) try to play back out the remaining steps if it is interrupted. This is what yum-complete-transaction does. However, I would not say it is foolproof or even just mildly-dumb-person-proof. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
bodhi - testing back to pending?
Hi, all, I couldn't figure this out from the wiki: Do updates in -testing go back to pending if they're not pushed to stable in some amount of time? I'd like to see a tor security update make it to -updates. The package's page: https://admin.fedoraproject.org/updates/F10/FEDORA-2009-1522 indicates that it was pushed to -testing shortly after being submitted, but it's not there now, and bodhi never updated Bugzilla with a notice that it had been pushed to testing: https://bugzilla.redhat.com/show_bug.cgi?id=499438 Additionally, the package maintainer isn't able to get the bodhi client to work, so what is the right way to ask somebody to push it (back?) over to testing? If that's done, I think testers can give it the karma it needs to get out. Thanks, -Bill -- Bill McGonigle, Owner Work: 603.448.4440 BFC Computing, LLC Home: 603.448.1668 http://www.bfccomputing.com/Cell: 603.252.2606 Twitter, etc.: bill_mcgonigle Page: 603.442.1833 Email, IM, VOIP: b...@bfccomputing.com Blog: http://blog.bfccomputing.com/ VCard: http://bfccomputing.com/vcard/bill.vcf -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Rawhide updates?
Hi, Any sign of a rawhide push or has something gone amiss? TTFN Paul -- Sie können mich aufreizen und wirklich heiß machen! signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rpms/php-pecl-geoip/devel import.log, NONE, 1.1 php-pecl-geoip.spec, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2
On 06/23/2009 01:33 PM, Rahul Sundaram wrote: On 06/24/2009 01:59 AM, Todd Zullinger wrote: Rahul Sundaram wrote: On 06/23/2009 11:36 PM, topdog wrote: Author: topdog Update of /cvs/pkgs/rpms/php-pecl-geoip/devel In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv2525/devel On the commits mailing list, instead of the author name at the From field, I see only a nick name. Why is that? I _think_ this happens for users who mark their account data as private in FAS. This would slow down each cvs commit. Currently we use the user information on the cvs server to figure out the real-name:: sender_name = pwd.getpwuid(os.getuid())[4] That information is subject to the privacy policy as tmz says, therefore it doesn't show up in the passwd information. This is the fastest method we can use to synchronously send mail out with this information. Making this slower will cause every cvs commit to get that muchslower which is highly undesirable. It isn't particularly private if the full name and email address is revealed in the changelog. For better transparency, I think the full name must be in the From address in commit messages. I don't think that we legally can. The privacy policy determines what information we can pull from fas and use where other people can see it. We could parse the changelog for the user's real name but that depends on the cvs changelog including a certain structure of information which it might not. -Toshio signature.asc Description: OpenPGP digital signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: update mechanism for new releases
Martin Langhoff writes: On Tue, Jun 23, 2009 at 10:33 PM, Seth Vidalskvi...@fedoraproject.org wrote: they're not insolvable - they are just very very very hard. :-) At the end of the day, if the OS doesn't give you atomic multi-file transactions, and your %pre/%post scripts aren't also written perfectly atomically, I would say that it _is_ impossible. If the %pre/%post scripts are not atomic, it's impossible. However, atomic multi-file transaction support from the filesystem is not necessary. That part is perfectly solvable. pgpfPhDHNWLhy.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: X11 on intel (rawhide)
On Tue, Jun 23, 2009 at 14:12, Paul p...@all-the-johnsons.co.uk wrote: Hi, Following the last official rawhide update (21st was it?), my desktop has been hosed. I've updated to the latest xorg-server and intel drivers (plus a few others) as well as gdm and anything else I can think off. All updates have been pulled from koji between 4pm and 10.30pm (UK, GMT) All I'm now getting is gdm failing to start (it shows a box where the usernames are normally, but it's blank, then restarts X). When I look at the logs, I'm seeing the following at the bottom (xorg.0.log) Backtrace 0: /usr/bin/Xorg(xorg_backtrace+0x3b) [0x80a3afb] 1: /usr/bin/Xorg [0x80a71b5] 2: [0xd09410] 3: /usr/lib/libdrm_intel.so.1 [0xe44750] 4: /usr/lib/libdrm_intol.so.1.(drm_intel_bufmgr_destroy+0xf)[0xe412bf] 5: /usr/lib/xorg/modules/drivers/intel_drv.so [0xf80132] 6: /usr/bin/Xorg [0x80fbdfe] 7: /usr/bin/Xorg [0x80c4cc5] 8: /usr/bin/Xorg [0x80b200c] 9: /usr/lib/xorg/modules/extensions/libextmod.so [0x1753a1] 10:/usr/bin/Xorg [0x816f1a2] 11:/usr/bin/Xorg [0x80e4bc0] 12:/usr/bin/Xorg [0x81a9459] 13:/usr/bin/Xorg [0x80e1fc2] 14:/usr/lib/xorg/modules/extensions/libglx.so [0x2792ba] 15:/usr/bin/Xorg [0x8063238] 16:/lib/libc.so.6 (__libc_start_main+0xe6) [0x8c0a66] 17:/usr/bin/Xorg [0x8062d91] Segmentation fault at address 0xfa4 Chipset 965GM Any ideas on what can be causing gdm/x to behave like this and more over, how do I fix it? I also have a 965GM. For the last six months the intel driver has been pretty flaky with it. My current working config is with 2.6.30-6.fc12.i686.PAE intel driver 2.7.0-6.fc12 xorg-x11-server-common-1.6.1.901-5.fc11.i586 (et al) libdrm-2.4.12-0.1.fc12.i586 (note that I have to boot with mem=3G on a 4 gig machine, running in 32 bit, not 64 bit) The newer 2.6.31 kernels work but show Jun 22 18:57:23 localhost kernel: [drm:drm_wait_vblank] *ERROR* failed to acquire vblank counter, -22 (rant: why anyone would put debugging in a vertical blanking area i don't know, but it sure fills up the log quickly) The newer intel drivers past 2.7.0-6 don't work. Newer versions of xorg are also broken for me. Sometimes booting with nomodeset also helps, but again the recent versions have been painful for that. Things have been quite unstable for about six months for this chip, so don't expect anything to change quickly. darrell -- 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: 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. Mandriva versions updates like this: 1.0-1mdv2009.1: initial package release in 2009 Spring 1.0-1.1mdv2009.1: first update 1.0-1.2mdv2009.1: second update ... and so on. Meanwhile, in Cooker (development branch), it'll be proceeding like this: 1.0-2mdv2010.0 1.0-3mdv2010.0 and so on. In addition, Cooker gets an automated rebuild of all packages at the start of each new release cycle, so in practice, packages for one release are always newer than any official update for the previous release(*). Backports can theoretically be versioned so that they'd have the update problem, but in practice it doesn't often happen (and hey, backports are unsupported anyway, you get to keep both pieces!). The problem with this method is it involves a bit more work, because you can't just send the exact same build to Rawhide and to a stable release together. I suppose it might also be a bit tough to police automatically: MDV updates are gatekeeper-ed by the security team, so this is policed manually there (if you don't version your candidate update package properly, it doesn't get sent out as an update, and you get an email telling you what you did wrong). * - except if the automated rebuild somehow failed, and that package never got touched again in Cooker before the next stable release, but did get updated in the previous stable release. I've rarely if ever seen that actually happen, though. -- adamw -- 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?
Michael Schwendt wrote:
Then with the switch to koji+bodhi a few package owners complained loudly
about false positives that were caused by pending builds, which were not
found in the master repo yet. A few other package owners jumped upon the
train and questioned the usefulness of the script, since they were of the
opinion that breaking upgrade paths the way they did it with
updates-testing and stable updates would not be considered a problem.
The actual issue we complained about was that the script (the one querying
Koji) required Fn+1 updates to be = Fn updates-testing which makes no
sense at all. I wrote a patch to fix that:
http://repo.calcforge.org/f10/check-upgrade-paths.py.diff
but it got lost under Jesse Keating's endless pile of TODOs. :-( And it
seems the whole code is going to be rewritten for autoqa now and nobody
cares about having a working check-upgrade-paths.py until autoqa goes
live. :-(
It's also simply a crap decision if packagers quickly mark F10 updates as
stable while the corresponding F11 update has not seen any testing at all
(while it's stuck in the growing list of pending updates in bodhi or
waiting for release of F11).
In my experience, an update which is working fine on one release has a very
high probability of working just as well on the other ones, especially if
the package being updated was working in the first place (which are the
cases we really care about - if the package was broken, pushing an update
which is broken the same way doesn't make things worse). In the updates I
pushed, I only remember one case where it didn't, which was due to improper
use (string comparison instead of numeric comparison) of dist conditionals
(by another packager, who requested that update to be added to our update
set, I'd have never made that mistake myself, though I am to blame for not
proofreading the changes). Due to bad timing, that build hit stable
directly (it got added to our Qt 4.5.0 update set just before we decided to
finally push it to stable after a long time in testing), causing a broken
dependency on F9 (which I fixed in the next push). But this was an isolated
occurrence which was due to a blatant packaging mistake (which could even
be caught by automated QA - any spec file containing %{?fedora} with the
quotes is broken) and which a maintainer experienced with multi-release
updates won't make. So I don't see pushing identical updates built from
identical specfiles for 2 or 3 releases at the same time as evil at all.
Kevin Kofler
--
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 24, 2009, at 0:46, Adam Williamson awill...@redhat.com wrote: On Mon, 2009-06-22 at 09:31 +0200, 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. Mandriva versions updates like this: 1.0-1mdv2009.1: initial package release in 2009 Spring 1.0-1.1mdv2009.1: first update 1.0-1.2mdv2009.1: second update ... and so on. Meanwhile, in Cooker (development branch), it'll be proceeding like this: 1.0-2mdv2010.0 1.0-3mdv2010.0 and so on. In addition, Cooker gets an automated rebuild of all packages at the start of each new release cycle, so in practice, packages for one release are always newer than any official update for the previous release(*). Backports can theoretically be versioned so that they'd have the update problem, but in practice it doesn't often happen (and hey, backports are unsupported anyway, you get to keep both pieces!). The problem with this method is it involves a bit more work, because you can't just send the exact same build to Rawhide and to a stable release together. I suppose it might also be a bit tough to police automatically: MDV updates are gatekeeper-ed by the security team, so this is policed manually there (if you don't version your candidate update package properly, it doesn't get sent out as an update, and you get an email telling you what you did wrong). * - except if the automated rebuild somehow failed, and that package never got touched again in Cooker before the next stable release, but did get updated in the previous stable release. I've rarely if ever seen that actually happen, though. That severly limits what maintainers can put out as updates. Essentially no version bumps. -- 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?
Nathanael D. Noblet wrote: 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 So to RPM the fc10/fc11 isn't being compared, at least not that I can see... That yum update is now stable: https://admin.fedoraproject.org/updates/F10/FEDORA-2009-5328 so it is now NO LONGER POSSIBLE (!!!) and WILL NEVER (!) BE POSSIBLE AGAIN (!!!) to upgrade an updated Fedora 10 to Fedora 11 using the DVD installer without breaking yum. Only a respin can help... until the next yum update in F10! Upgrades using the DVD installer are broken by design. We got lucky until now, but this time the DVD has become completely useless for upgrades, unless you like having to fetch an updated yum by hand (which, if you are a KDE user, you have to do from runlevel 3 because KDE (including KDM) is also broken after the upgrade for basically the same reason yum is - good luck with the command-line ftp! I've had my fun fixing a relative's system that way), installing it with rpm -Uvh and then running it to fix the remaining breakage (e.g. KDE). Fedora CANNOT be upgraded with a method not including updates. We really need to fix the download page not to recommend the DVD for upgrades (and I'll ping the websites team about that). I think preupgrade = 1.1.0 is the only solution we can officially recommend. Kevin Kofler -- 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?
Jussi Lehtola wrote: Does anaconda currently force installs of core packages such as yum? No. This is quite important if the version in the old distro is newer than that on the DVD. You just end up with a broken yum. Kevin Kofler -- 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 11:40 -0400, TK009 wrote: As to the bug itself, I can not and will not speak for why it bothers the OP. To answer your question though, it bothers me because I don't want packages on my machine I don't need. As it is my machine that is reason enough. Size is irrelevant. It's important to note that this is not a reasonable expectation. Think about what it means when you use a distribution which implements dependencies, and a dependency-resolving package manager like yum. What you are saying is 'I would like to trade the bit-by-bit control of what is installed on my computer for the convenience of letting someone else worry about it'. Simply by the act of using Fedora you essentially affirm that you actually _don't_ want to have permanent bit-by-bit control of this nature. If you really want that, you should either run Slackware, LFS, or run Fedora but install everything from source or with rpm -Uvh (--nodeps when appropriate), and figure out dependencies yourself. As long as you cede the control of the decision of what software really 'requires' other software to your distribution, you should recognize that you can't then use I should have that control as an argument when talking about distribution dependencies. It's fine to suggest that such-and-such a dependency shouldn't really be there, but it's not fine to justify this by saying I should have control over what gets installed, because the whole point of dependencies is to save you the pain of worrying about that. Remember that ultimately Fedora _does_ grant you access to that level of control, should you choose to use it: rpm -e --nodeps is available and does what it says on the tin. The trade-off is you get the responsibility along with the power. :) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- 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?
Rahul Sundaram 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? The only solution to this particular problem is to stop claiming we support upgrade methods which don't include updates. The F11 DVD is no longer viable for upgrades as of the latest F10 yum update. We CANNOT recommend it for upgrades anymore. For future Fedora releases, there are 2 solutions: either we fix the DVD to use the repositories enabled on the installed system (updates etc.) like preupgrade now does (which also implies that it will have to refuse doing the upgrade if it can't connect to the network) or we drop support for upgrading from the DVD entirely (we could hide it behind an upgrade boot option like RHEL does). We can't just continue to break upgrade paths and call it the way things are done. There are 2 distinct issues: * upgrade paths from Fn + updates to the Fn+1 DVD. Those just cannot be maintained, we simply need to drop support for this kind of updates. If the DVD is to continue supporting upgrading, it needs to fetch updates from the network. * upgrade paths from Fn + updates to Fn+1 + updates. Those make sense to maintain. This is what the replies are focusing on. But this will not solve the original problem. Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Pulseaudio question...
On Tue, 2009-06-23 at 20:53 +0100, Adam Williamson wrote: On Tue, 2009-06-23 at 17:49 +0200, Kevin Kofler wrote: Nathanael D. Noblet wrote: I've opened a movie in totem, the main volume level is somewhere in the range of 70%, however totem is at about 4%. The movie is too quiet so I've upped the volume in totem to 19%. The main volume is now 84%. All fine and good. However if I modify the main volume at all (up or down), the main volume resets to whatever the main volume was before I changed totem's volume. If I in this case bring the main volume up to 84% again, totem is at the 19% I set it to... Is this expected behaviour? I think this is the flat volumes feature. It can be disabled by setting: flat-volumes = no in /etc/pulse/daemon.conf or ~/.pulse/daemon.conf . It may be related, but it's not the way that's _supposed_ to work, AIUI. When working correctly, with flat volumes, the two volumes should be the same, I believe - if you set totem to 70%, the 'main' volume slider in g-v-c or pavucontrol should also be at 70%. so it sounds like it may be some bug within the flat volume implementation. Or one of the numerous bugs in the application's volume control patch. Hopefully something to work on tomorrow if Lennart doesn't send me a huge batch of things to do in the F-12 volume control :) -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: XInput.h has moved to libXi
Peter Hutterer wrote: 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. To be more precise, it has moved to libXi-devel (where it belongs :-) ). Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: X11 on intel (rawhide)
Rawhide deployed a xorg-update, while various drivers haven't been updated so there's a version mismatch. I use the vesa driver for now (also quite unstable, due to what seem to be pixman bugs), however an updated intel-driver should be out soon (hopefully). - Clemens 2009/6/23 Paul p...@all-the-johnsons.co.uk: Hi, Following the last official rawhide update (21st was it?), my desktop has been hosed. I've updated to the latest xorg-server and intel drivers (plus a few others) as well as gdm and anything else I can think off. All updates have been pulled from koji between 4pm and 10.30pm (UK, GMT) All I'm now getting is gdm failing to start (it shows a box where the usernames are normally, but it's blank, then restarts X). When I look at the logs, I'm seeing the following at the bottom (xorg.0.log) Backtrace 0: /usr/bin/Xorg(xorg_backtrace+0x3b) [0x80a3afb] 1: /usr/bin/Xorg [0x80a71b5] 2: [0xd09410] 3: /usr/lib/libdrm_intel.so.1 [0xe44750] 4: /usr/lib/libdrm_intol.so.1.(drm_intel_bufmgr_destroy+0xf)[0xe412bf] 5: /usr/lib/xorg/modules/drivers/intel_drv.so [0xf80132] 6: /usr/bin/Xorg [0x80fbdfe] 7: /usr/bin/Xorg [0x80c4cc5] 8: /usr/bin/Xorg [0x80b200c] 9: /usr/lib/xorg/modules/extensions/libextmod.so [0x1753a1] 10:/usr/bin/Xorg [0x816f1a2] 11:/usr/bin/Xorg [0x80e4bc0] 12:/usr/bin/Xorg [0x81a9459] 13:/usr/bin/Xorg [0x80e1fc2] 14:/usr/lib/xorg/modules/extensions/libglx.so [0x2792ba] 15:/usr/bin/Xorg [0x8063238] 16:/lib/libc.so.6 (__libc_start_main+0xe6) [0x8c0a66] 17:/usr/bin/Xorg [0x8062d91] Segmentation fault at address 0xfa4 Chipset 965GM Any ideas on what can be causing gdm/x to behave like this and more over, how do I fix it? TTFN Paul -- Sie können mich aufreizen und wirklich heiß machen! -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: bodhi - testing back to pending?
Bill McGonigle wrote: Do updates in -testing go back to pending if they're not pushed to stable in some amount of time? No, they just sit there, unless they're explicitly unpushed. Additionally, the package maintainer isn't able to get the bodhi client to work Then he should just use the web interface, which works with any browser. Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rpm AutoRequires/AutoProvides and dsos not in linker path, do we care ?
Adam Jackson wrote: On Wed, 2009-06-17 at 10:06 -0400, Chuck Anderson wrote: On Wed, Jun 17, 2009 at 02:57:53PM +0100, Caolán McNamara wrote: b.2) extend the autorequires/autoprovides in some (handwaves) way to better indicate the desired match I like this idea better. AutoReq/Prov should only search system-wide deafult search paths for .so's, perl modules, and any other such objects that it supports. system-wide includes paths mentioned in /etc/ld.so.conf.d/*, which are files provided by other packages. Suddenly your search scope is unbounded again. Thought: Define system library directories to a sane default set. Start with this. For each package, when doing autoprovides calculation, recurse down the tree of rpms needed by this package. For any that change /etc/ld.so.conf.d, add the appropriate directory to the set of system library directories. Now see if the rpm installs any libraries into those locations. If so, those are autoprovides. Sound sane? -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- XFS is not something I look into the innards of, as I don't have enough chickens to sacrifice. -- Alan Cox -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: update mechanism for new releases
On Tue, 23 Jun 2009, Colin Walters wrote: On Tue, Jun 23, 2009 at 4:41 PM, Martin Langhoffmartin.langh...@gmail.com wrote: On Tue, Jun 23, 2009 at 10:33 PM, Seth Vidalskvi...@fedoraproject.org wrote: they're not insolvable - they are just very very very hard. :-) At the end of the day, if the OS doesn't give you atomic multi-file transactions, and your %pre/%post scripts aren't also written perfectly atomically, I would say that it _is_ impossible. Well, it's pretty clear how to make the dual root approach work. There was some work done on this way back in the Stateless project: http://fedoraproject.org/wiki/StatelessLinux Basically updates are applied into a side image, then on next reboot the new image is targeted, and the old one becomes the new update target. Short of some deduplication work, this has the downside that it doubles disk usage for the OS packages. I'm pretty sure Windows updates do something like this but on the filesystem level, where newly installed files don't actually overwrite the ones of the same name, but are put into a waiting state where the OS on the next reboot (befor elogin) will make them active. I'm not sure if that process is atomic - I bet it isn't, but it is a smaller window for failure. Besides the I ran out of laptop battery during yum problem, the other one that we really do need to solve that's related is that many applications can't handle files being removed under them. Firefox's versioned directories exacerbates this, but I've gotten weird failures from plenty of running applications which expect glade files, images, etc. from the old version to still be there. And we've still not handled the upgrading daemonX changes the db format in a backward incompatible way. problem. -sv -- 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)
On Tue, Jun 23, 2009 at 4:19 PM, Clemens Eissererlinuxhi...@gmail.com wrote: 1) Optimizing for P4 is ... messy 2) If you're using C2D, etc., you can already use the 64-bit distro. So why not stay with generic, where most users would benefit. Sure I could use 64-bit, as could all the others using 32-bit on 64-bit capable CPUs (I guess 50% of all fedora-x86 users). Fedora x86_64 is the solution for good performance for those systems. The difference between 32bit mode and 64bit mode dwarfs all the little compiler tweaks we could discuss. Optimizing for atom makes sense because it's the most modern hardware which doesn't have a higher performing alternative than the 32bit build. Moreover, as an in-order core it atom should gain more from optimization than most cpus and generally optimizations for atom are harmless or even beneficial for other CPUs, while optimization for highly out of order CPUs can be devastating for in-order cores. As you can see in Bill's post upthread optimizing for atom is mildly beneficial even to P4. Amusingly, on my own code at least -mtune=atom produces significantly faster code than -mtune=geode on my geode LX. P4 is pretty much a lost cause. The move to i686 from i586 itself will make P4 slower, while helping most everything else by about the same margin that it hurt p4. Optimizing for P4 will probably hurt everything, certainly atom. Atom systems are frequently battery powered, so improvements there can also to increased battery life. P4, OTOH, already requires a locally installed atomic power plant so energy isn't an issue there. ... -- 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)
+1 For the i686 with atom optimizations. This seems like a solid suggestion and Gregory's argument seems logical. -Adam (From my G1) On Jun 23, 2009 11:49 PM, Gregory Maxwell gmaxw...@gmail.com wrote: On Tue, Jun 23, 2009 at 4:19 PM, Clemens Eissererlinuxhi...@gmail.com wrote: 1) Optimizing for ... Fedora x86_64 is the solution for good performance for those systems. The difference between 32bit mode and 64bit mode dwarfs all the little compiler tweaks we could discuss. Optimizing for atom makes sense because it's the most modern hardware which doesn't have a higher performing alternative than the 32bit build. Moreover, as an in-order core it atom should gain more from optimization than most cpus and generally optimizations for atom are harmless or even beneficial for other CPUs, while optimization for highly out of order CPUs can be devastating for in-order cores. As you can see in Bill's post upthread optimizing for atom is mildly beneficial even to P4. Amusingly, on my own code at least -mtune=atom produces significantly faster code than -mtune=geode on my geode LX. P4 is pretty much a lost cause. The move to i686 from i586 itself will make P4 slower, while helping most everything else by about the same margin that it hurt p4. Optimizing for P4 will probably hurt everything, certainly atom. Atom systems are frequently battery powered, so improvements there can also to increased battery life. P4, OTOH, already requires a locally installed atomic power plant so energy isn't an issue there. ... -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/list... -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
rpms/perl-RT-Client-REST/F-11 perl-RT-Client-REST.spec, NONE, 1.1 sources, 1.1, 1.2
Author: cweyl
Update of /cvs/extras/rpms/perl-RT-Client-REST/F-11
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv24373
Modified Files:
sources
Added Files:
perl-RT-Client-REST.spec
Log Message:
* Mon Apr 20 2009 Chris Weyl cw...@alumni.drew.edu 0.37-1
- submission
--- NEW FILE perl-RT-Client-REST.spec ---
Name: perl-RT-Client-REST
Version:0.37
Release:1%{?dist}
# lib/RT/Client/REST.pm - GPLv2
# see also /usr/bin/rt from the rt3 package
License:GPLv2
Group: Development/Libraries
Summary:Talk to RT using REST protocol
Source:
http://search.cpan.org/CPAN/authors/id/D/DM/DMITRI/RT-Client-REST-%{version}.tar.gz
Url:http://search.cpan.org/dist/RT-Client-REST
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo $version))
BuildArch: noarch
BuildRequires: perl(Encode)
BuildRequires: perl(Error)
BuildRequires: perl(Exception::Class)
BuildRequires: perl(ExtUtils::MakeMaker)
BuildRequires: perl(HTTP::Cookies)
BuildRequires: perl(HTTP::Request::Common)
BuildRequires: perl(LWP)
BuildRequires: perl(Params::Validate)
# testing
BuildRequires: perl(Test::More)
BuildRequires: perl(Test::Exception)
BuildRequires: perl(Test::Pod)
BuildRequires: perl(Test::Pod::Coverage)
BuildRequires: perl(Test::Kwalitee)
%description
*RT::Client::REST* is */usr/bin/rt* converted to a Perl module. I needed
to implement some RT interactions from my application, but did not feel
that invoking a shell command is appropriate. Thus, I took *rt* tool,
written by Abhijit Menon-Sen, and converted it to an object-oriented
Perl module.
%prep
%setup -q -n RT-Client-REST-%{version}
cat Changes | iconv -f iso8859-1 -t utf8 x
mv x Changes
%build
%{__perl} Makefile.PL INSTALLDIRS=vendor
make %{?_smp_mflags}
%install
rm -rf %{buildroot}
make pure_install PERL_INSTALL_ROOT=%{buildroot}
find %{buildroot} -type f -name .packlist -exec rm -f {} ';'
find %{buildroot} -depth -type d -exec rmdir {} 2/dev/null ';'
%{_fixperms} %{buildroot}/*
%check
make test
%clean
rm -rf %{buildroot}
%files
%defattr(-,root,root,-)
%doc README Changes examples/
%{perl_vendorlib}/*
%{_mandir}/man3/*.3*
%changelog
* Mon Apr 20 2009 Chris Weyl cw...@alumni.drew.edu 0.37-1
- submission
* Sat Apr 18 2009 Chris Weyl cw...@alumni.drew.edu 0.37-0
- initial RPM packaging
- generated with cpan2dist (CPANPLUS::Dist::RPM version 0.0.8)
Index: sources
===
RCS file: /cvs/extras/rpms/perl-RT-Client-REST/F-11/sources,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- sources 23 Apr 2009 16:49:32 - 1.1
+++ sources 23 Jun 2009 06:07:38 - 1.2
@@ -0,0 +1 @@
+383bf572afdb8040641d4d413ef96476 RT-Client-REST-0.37.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 506389] Moose requires Test::Builder (which pulls in perl-devel)
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=506389 Chris Weyl cw...@alumni.drew.edu changed: What|Removed |Added Status|NEW |CLOSED Resolution||RAWHIDE --- Comment #3 from Chris Weyl cw...@alumni.drew.edu 2009-06-23 02:15:37 EDT --- Oof, yeah. I've been wanting soft-deps for ages for reasons along these lines... Ok, so I've done the split and committed/built it in rawhide. The packages soft-requiring it we'll have to add it manually *sigh* unless the package maintainers add it as a test_requires (which given how many of them use Module::Install should be trivial for them to do). I've also filed bugs in rt for the ones above (RT::Client::REST can be _very_ useful) -- except for Moose itself, of course -- so hopefully we'll be seeing test_requires metadata on them soon. I also didn't file one against DBIx::Class as they're still considering Moose to be a soft requires. RT#47258 to 63. I'm marking this CLOSED/RAWHIDE; we'll get it out to F-11/10, but not until we're through the current mass-Moose updates, at least. -- 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-Sys-SigAction/devel .cvsignore, 1.2, 1.3 perl-Sys-SigAction.spec, 1.5, 1.6 sources, 1.2, 1.3
Author: ixs
Update of /cvs/pkgs/rpms/perl-Sys-SigAction/devel
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv16959
Modified Files:
.cvsignore perl-Sys-SigAction.spec sources
Log Message:
* Thu Jun 23 2009 Andreas Thienemann andr...@bawue.net - 0.11-1
- Update to 0.11
Index: .cvsignore
===
RCS file: /cvs/pkgs/rpms/perl-Sys-SigAction/devel/.cvsignore,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -p -r1.2 -r1.3
--- .cvsignore 23 Mar 2007 14:13:38 - 1.2
+++ .cvsignore 23 Jun 2009 07:37:29 - 1.3
@@ -1 +1 @@
-Sys-SigAction-0.10.tar.gz
+Sys-SigAction-0.11.tar.gz
Index: perl-Sys-SigAction.spec
===
RCS file: /cvs/pkgs/rpms/perl-Sys-SigAction/devel/perl-Sys-SigAction.spec,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -p -r1.5 -r1.6
--- perl-Sys-SigAction.spec 27 Feb 2009 01:53:03 - 1.5
+++ perl-Sys-SigAction.spec 23 Jun 2009 07:37:29 - 1.6
@@ -1,6 +1,6 @@
Name: perl-Sys-SigAction
-Version:0.10
-Release:4%{?dist}
+Version:0.11
+Release:1%{?dist}
Summary:Perl extension for Consistent Signal Handling
License:GPL+ or Artistic
Group: Development/Libraries
@@ -49,11 +49,14 @@ rm -rf %{buildroot}
%{_mandir}/man3/*
%changelog
+* Thu Jun 23 2009 Andreas Thienemann andr...@bawue.net - 0.11-1
+- Update to 0.11
+
* Thu Feb 26 2009 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 0.10-4
- Rebuilt for https://fedoraproject.org/wiki/Fedora_11_Mass_Rebuild
* Thu Mar 06 2008 Tom spot Callaway tcall...@redhat.com - 0.10-3
-Rebuild for new perl
+- Rebuild for new perl
* Sun Jan 27 2008 Andreas Thienemann andr...@bawue.net 0.10-2
- Added Test::More to the BuildReqs
Index: sources
===
RCS file: /cvs/pkgs/rpms/perl-Sys-SigAction/devel/sources,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -p -r1.2 -r1.3
--- sources 23 Mar 2007 14:13:38 - 1.2
+++ sources 23 Jun 2009 07:37:29 - 1.3
@@ -1 +1 @@
-ba520c175ea5c41950f53e60801da476 Sys-SigAction-0.10.tar.gz
+e37f1e69d6ac6ea4a9ffd7f845753e79 Sys-SigAction-0.11.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-Tk/F-10 perl-Tk-events.patch, NONE, 1.1 perl-Tk.spec, 1.16, 1.17
Author: awjb
Update of /cvs/pkgs/rpms/perl-Tk/F-10
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv30888/F-10
Modified Files:
perl-Tk.spec
Added Files:
perl-Tk-events.patch
Log Message:
- fix events (#489228, #491536, #506496)
perl-Tk-events.patch:
--- NEW FILE perl-Tk-events.patch ---
--- pTk/mTk/generic/tk.h.orig 2007-05-05 20:41:02.0 +0200
+++ pTk/mTk/generic/tk.h2008-08-27 03:16:31.0 +0200
@@ -677,17 +677,15 @@
*
*---
*/
-#define VirtualEvent(LASTEvent)
-#define ActivateNotify (LASTEvent + 1)
-#define DeactivateNotify(LASTEvent + 2)
-#define MouseWheelEvent (LASTEvent + 3)
-#define TK_LASTEVENT(LASTEvent + 4)
+#define VirtualEvent(MappingNotify + 1)
+#define ActivateNotify (MappingNotify + 2)
+#define DeactivateNotify(MappingNotify + 3)
+#define MouseWheelEvent (MappingNotify + 4)
+#define TK_LASTEVENT(MappingNotify + 5)
#define MouseWheelMask (1L 28)
-
#define ActivateMask(1L 29)
#define VirtualEventMask(1L 30)
-#define TK_LASTEVENT(LASTEvent + 4)
/*
Index: perl-Tk.spec
===
RCS file: /cvs/pkgs/rpms/perl-Tk/F-10/perl-Tk.spec,v
retrieving revision 1.16
retrieving revision 1.17
diff -u -p -r1.16 -r1.17
--- perl-Tk.spec19 Mar 2009 15:28:34 - 1.16
+++ perl-Tk.spec22 Jun 2009 16:43:02 - 1.17
@@ -3,7 +3,7 @@
Name: perl-Tk
Version:804.028
-Release:7%{?dist}
+Release:8%{?dist}
Summary:Perl Graphical User Interface ToolKit
Group: Development/Libraries
@@ -17,6 +17,9 @@ Patch1: perl-Tk-debian.patch.gz
Patch2: perl-Tk-seg.patch
# fix interaction with XIM, bug #489228, upstream change r12589
Patch3:perl-Tk-XIM.patch
+# fix for bugs #491536 #489228 #506496 (see comment #8)
+# see http://rt.cpan.org/Public/Bug/Display.html?id=38746
+Patch4:perl-Tk-events.patch
# fix gif overflow in tk see CVE-2006-4484 and CVE-2007-6697 or #431518 and
# #431529
@@ -60,6 +63,7 @@ chmod -x pod/Popup.pod Tixish/lib/Tk/bal
# patch to fix #235666 ... seems like caching code is broken
%patch2 -p1 -b .seg
%patch3 -p1 -b .xim
+%patch4 -b .events
%patch100
%build
@@ -105,6 +109,10 @@ rm -rf $RPM_BUILD_ROOT
%exclude %{perl_vendorarch}/Tk/reindex.pl
%changelog
+* Mon Jun 15 2009 Andreas Bierfert andreas.bierfert[AT]lowlatency.de
+- 804.028-8
+- fix events (#489228, #491536, #506496)
+
* Thu Mar 19 2009 Stepan Kasal ska...@redhat.com - 804.028-7
- perl-Tk-XIM.patch (#489228)
--
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-Tk/F-11 perl-Tk-events.patch, NONE, 1.1 perl-Tk.spec, 1.17, 1.18
Author: awjb
Update of /cvs/pkgs/rpms/perl-Tk/F-11
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv30888/F-11
Modified Files:
perl-Tk.spec
Added Files:
perl-Tk-events.patch
Log Message:
- fix events (#489228, #491536, #506496)
perl-Tk-events.patch:
--- NEW FILE perl-Tk-events.patch ---
--- pTk/mTk/generic/tk.h.orig 2007-05-05 20:41:02.0 +0200
+++ pTk/mTk/generic/tk.h2008-08-27 03:16:31.0 +0200
@@ -677,17 +677,15 @@
*
*---
*/
-#define VirtualEvent(LASTEvent)
-#define ActivateNotify (LASTEvent + 1)
-#define DeactivateNotify(LASTEvent + 2)
-#define MouseWheelEvent (LASTEvent + 3)
-#define TK_LASTEVENT(LASTEvent + 4)
+#define VirtualEvent(MappingNotify + 1)
+#define ActivateNotify (MappingNotify + 2)
+#define DeactivateNotify(MappingNotify + 3)
+#define MouseWheelEvent (MappingNotify + 4)
+#define TK_LASTEVENT(MappingNotify + 5)
#define MouseWheelMask (1L 28)
-
#define ActivateMask(1L 29)
#define VirtualEventMask(1L 30)
-#define TK_LASTEVENT(LASTEvent + 4)
/*
Index: perl-Tk.spec
===
RCS file: /cvs/pkgs/rpms/perl-Tk/F-11/perl-Tk.spec,v
retrieving revision 1.17
retrieving revision 1.18
diff -u -p -r1.17 -r1.18
--- perl-Tk.spec19 Mar 2009 14:54:33 - 1.17
+++ perl-Tk.spec22 Jun 2009 16:43:02 - 1.18
@@ -3,7 +3,7 @@
Name: perl-Tk
Version:804.028
-Release:7%{?dist}
+Release:8%{?dist}
Summary:Perl Graphical User Interface ToolKit
Group: Development/Libraries
@@ -17,6 +17,9 @@ Patch1: perl-Tk-debian.patch.gz
Patch2: perl-Tk-seg.patch
# fix interaction with XIM, bug #489228, upstream change r12589
Patch3:perl-Tk-XIM.patch
+# fix for bugs #491536 #489228 #506496 (see comment #8)
+# see http://rt.cpan.org/Public/Bug/Display.html?id=38746
+Patch4:perl-Tk-events.patch
# fix gif overflow in tk see CVE-2006-4484 and CVE-2007-6697 or #431518 and
# #431529
@@ -60,6 +63,7 @@ chmod -x pod/Popup.pod Tixish/lib/Tk/bal
# patch to fix #235666 ... seems like caching code is broken
%patch2 -p1 -b .seg
%patch3 -p1 -b .xim
+%patch4 -b .events
%patch100
%build
@@ -105,6 +109,10 @@ rm -rf $RPM_BUILD_ROOT
%exclude %{perl_vendorarch}/Tk/reindex.pl
%changelog
+* Mon Jun 15 2009 Andreas Bierfert andreas.bierfert[AT]lowlatency.de
+- 804.028-8
+- fix events (#489228, #491536, #506496)
+
* Thu Mar 19 2009 Stepan Kasal ska...@redhat.com - 804.028-7
- perl-Tk-XIM.patch (#489228)
--
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-Tk/devel perl-Tk-getOpenFile.patch, NONE, 1.1 perl-Tk.spec, 1.18, 1.19
Author: awjb
Update of /cvs/pkgs/rpms/perl-Tk/devel
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv8673/devel
Modified Files:
perl-Tk.spec
Added Files:
perl-Tk-getOpenFile.patch
Log Message:
- fix getOpenFile (#487122)
perl-Tk-getOpenFile.patch:
--- NEW FILE perl-Tk-getOpenFile.patch ---
--- Tk/FBox.pm.orig 2009-06-22 19:18:49.0 +0200
+++ Tk/FBox.pm 2009-06-22 19:19:30.0 +0200
@@ -906,7 +906,7 @@
if ($w-cget('-multiple')) {
$selectFilePath = [];
for my $f (@{ $w-{'selectFile'} }) {
- push @$selectFilePath, JoinFile($w-_get_select_Path, $f);
+ push @$selectFilePath, JoinFile($w-_get_select_path, $f);
}
} else {
$selectFilePath = JoinFile($w-_get_select_path,
Index: perl-Tk.spec
===
RCS file: /cvs/pkgs/rpms/perl-Tk/devel/perl-Tk.spec,v
retrieving revision 1.18
retrieving revision 1.19
diff -u -p -r1.18 -r1.19
--- perl-Tk.spec22 Jun 2009 16:43:03 - 1.18
+++ perl-Tk.spec22 Jun 2009 17:26:19 - 1.19
@@ -3,7 +3,7 @@
Name: perl-Tk
Version:804.028
-Release:8%{?dist}
+Release:9%{?dist}
Summary:Perl Graphical User Interface ToolKit
Group: Development/Libraries
@@ -20,6 +20,9 @@ Patch3: perl-Tk-XIM.patch
# fix for bugs #491536 #489228 #506496 (see comment #8)
# see http://rt.cpan.org/Public/Bug/Display.html?id=38746
Patch4:perl-Tk-events.patch
+# fix for bug #487122
+# see http://rt.cpan.org/Public/Bug/Display.html?id=31989
+Patch5: perl-Tk-getOpenFile.patch
# fix gif overflow in tk see CVE-2006-4484 and CVE-2007-6697 or #431518 and
# #431529
@@ -64,6 +67,7 @@ chmod -x pod/Popup.pod Tixish/lib/Tk/bal
%patch2 -p1 -b .seg
%patch3 -p1 -b .xim
%patch4 -b .events
+%patch5 -b .getOpenFile
%patch100
%build
@@ -109,6 +113,10 @@ rm -rf $RPM_BUILD_ROOT
%exclude %{perl_vendorarch}/Tk/reindex.pl
%changelog
+* Mon Jun 22 2009 Andreas Bierfert andreas.bierfert[AT]lowlatency.de
+- 804.028-9
+- fix getOpenFile (#487122)
+
* Mon Jun 15 2009 Andreas Bierfert andreas.bierfert[AT]lowlatency.de
- 804.028-8
- fix events (#489228, #491536, #506496)
--
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-Tk/F-11 perl-Tk-getOpenFile.patch, NONE, 1.1 perl-Tk.spec, 1.18, 1.19
Author: awjb
Update of /cvs/pkgs/rpms/perl-Tk/F-11
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv8673/F-11
Modified Files:
perl-Tk.spec
Added Files:
perl-Tk-getOpenFile.patch
Log Message:
- fix getOpenFile (#487122)
perl-Tk-getOpenFile.patch:
--- NEW FILE perl-Tk-getOpenFile.patch ---
--- Tk/FBox.pm.orig 2009-06-22 19:18:49.0 +0200
+++ Tk/FBox.pm 2009-06-22 19:19:30.0 +0200
@@ -906,7 +906,7 @@
if ($w-cget('-multiple')) {
$selectFilePath = [];
for my $f (@{ $w-{'selectFile'} }) {
- push @$selectFilePath, JoinFile($w-_get_select_Path, $f);
+ push @$selectFilePath, JoinFile($w-_get_select_path, $f);
}
} else {
$selectFilePath = JoinFile($w-_get_select_path,
Index: perl-Tk.spec
===
RCS file: /cvs/pkgs/rpms/perl-Tk/F-11/perl-Tk.spec,v
retrieving revision 1.18
retrieving revision 1.19
diff -u -p -r1.18 -r1.19
--- perl-Tk.spec22 Jun 2009 16:43:02 - 1.18
+++ perl-Tk.spec22 Jun 2009 17:26:19 - 1.19
@@ -3,7 +3,7 @@
Name: perl-Tk
Version:804.028
-Release:8%{?dist}
+Release:9%{?dist}
Summary:Perl Graphical User Interface ToolKit
Group: Development/Libraries
@@ -20,6 +20,9 @@ Patch3: perl-Tk-XIM.patch
# fix for bugs #491536 #489228 #506496 (see comment #8)
# see http://rt.cpan.org/Public/Bug/Display.html?id=38746
Patch4:perl-Tk-events.patch
+# fix for bug #487122
+# see http://rt.cpan.org/Public/Bug/Display.html?id=31989
+Patch5: perl-Tk-getOpenFile.patch
# fix gif overflow in tk see CVE-2006-4484 and CVE-2007-6697 or #431518 and
# #431529
@@ -64,6 +67,7 @@ chmod -x pod/Popup.pod Tixish/lib/Tk/bal
%patch2 -p1 -b .seg
%patch3 -p1 -b .xim
%patch4 -b .events
+%patch5 -b .getOpenFile
%patch100
%build
@@ -109,6 +113,10 @@ rm -rf $RPM_BUILD_ROOT
%exclude %{perl_vendorarch}/Tk/reindex.pl
%changelog
+* Mon Jun 22 2009 Andreas Bierfert andreas.bierfert[AT]lowlatency.de
+- 804.028-9
+- fix getOpenFile (#487122)
+
* Mon Jun 15 2009 Andreas Bierfert andreas.bierfert[AT]lowlatency.de
- 804.028-8
- fix events (#489228, #491536, #506496)
--
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-Tk/devel perl-Tk-events.patch, NONE, 1.1 perl-Tk.spec, 1.17, 1.18
Author: awjb
Update of /cvs/pkgs/rpms/perl-Tk/devel
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv30888/devel
Modified Files:
perl-Tk.spec
Added Files:
perl-Tk-events.patch
Log Message:
- fix events (#489228, #491536, #506496)
perl-Tk-events.patch:
--- NEW FILE perl-Tk-events.patch ---
--- pTk/mTk/generic/tk.h.orig 2007-05-05 20:41:02.0 +0200
+++ pTk/mTk/generic/tk.h2008-08-27 03:16:31.0 +0200
@@ -677,17 +677,15 @@
*
*---
*/
-#define VirtualEvent(LASTEvent)
-#define ActivateNotify (LASTEvent + 1)
-#define DeactivateNotify(LASTEvent + 2)
-#define MouseWheelEvent (LASTEvent + 3)
-#define TK_LASTEVENT(LASTEvent + 4)
+#define VirtualEvent(MappingNotify + 1)
+#define ActivateNotify (MappingNotify + 2)
+#define DeactivateNotify(MappingNotify + 3)
+#define MouseWheelEvent (MappingNotify + 4)
+#define TK_LASTEVENT(MappingNotify + 5)
#define MouseWheelMask (1L 28)
-
#define ActivateMask(1L 29)
#define VirtualEventMask(1L 30)
-#define TK_LASTEVENT(LASTEvent + 4)
/*
Index: perl-Tk.spec
===
RCS file: /cvs/pkgs/rpms/perl-Tk/devel/perl-Tk.spec,v
retrieving revision 1.17
retrieving revision 1.18
diff -u -p -r1.17 -r1.18
--- perl-Tk.spec19 Mar 2009 14:54:33 - 1.17
+++ perl-Tk.spec22 Jun 2009 16:43:03 - 1.18
@@ -3,7 +3,7 @@
Name: perl-Tk
Version:804.028
-Release:7%{?dist}
+Release:8%{?dist}
Summary:Perl Graphical User Interface ToolKit
Group: Development/Libraries
@@ -17,6 +17,9 @@ Patch1: perl-Tk-debian.patch.gz
Patch2: perl-Tk-seg.patch
# fix interaction with XIM, bug #489228, upstream change r12589
Patch3:perl-Tk-XIM.patch
+# fix for bugs #491536 #489228 #506496 (see comment #8)
+# see http://rt.cpan.org/Public/Bug/Display.html?id=38746
+Patch4:perl-Tk-events.patch
# fix gif overflow in tk see CVE-2006-4484 and CVE-2007-6697 or #431518 and
# #431529
@@ -60,6 +63,7 @@ chmod -x pod/Popup.pod Tixish/lib/Tk/bal
# patch to fix #235666 ... seems like caching code is broken
%patch2 -p1 -b .seg
%patch3 -p1 -b .xim
+%patch4 -b .events
%patch100
%build
@@ -105,6 +109,10 @@ rm -rf $RPM_BUILD_ROOT
%exclude %{perl_vendorarch}/Tk/reindex.pl
%changelog
+* Mon Jun 15 2009 Andreas Bierfert andreas.bierfert[AT]lowlatency.de
+- 804.028-8
+- fix events (#489228, #491536, #506496)
+
* Thu Mar 19 2009 Stepan Kasal ska...@redhat.com - 804.028-7
- perl-Tk-XIM.patch (#489228)
--
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-Tk/F-10 perl-Tk-getOpenFile.patch,NONE,1.1
Author: awjb
Update of /cvs/pkgs/rpms/perl-Tk/F-10
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv10850
Added Files:
perl-Tk-getOpenFile.patch
Log Message:
- openfile patch
perl-Tk-getOpenFile.patch:
--- NEW FILE perl-Tk-getOpenFile.patch ---
--- Tk/FBox.pm.orig 2009-06-22 19:18:49.0 +0200
+++ Tk/FBox.pm 2009-06-22 19:19:30.0 +0200
@@ -906,7 +906,7 @@
if ($w-cget('-multiple')) {
$selectFilePath = [];
for my $f (@{ $w-{'selectFile'} }) {
- push @$selectFilePath, JoinFile($w-_get_select_Path, $f);
+ push @$selectFilePath, JoinFile($w-_get_select_path, $f);
}
} else {
$selectFilePath = JoinFile($w-_get_select_path,
--
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-Tk/F-10 perl-Tk.spec,1.17,1.18
Author: awjb
Update of /cvs/pkgs/rpms/perl-Tk/F-10
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv8673/F-10
Modified Files:
perl-Tk.spec
Log Message:
- fix getOpenFile (#487122)
Index: perl-Tk.spec
===
RCS file: /cvs/pkgs/rpms/perl-Tk/F-10/perl-Tk.spec,v
retrieving revision 1.17
retrieving revision 1.18
diff -u -p -r1.17 -r1.18
--- perl-Tk.spec22 Jun 2009 16:43:02 - 1.17
+++ perl-Tk.spec22 Jun 2009 17:26:18 - 1.18
@@ -3,7 +3,7 @@
Name: perl-Tk
Version:804.028
-Release:8%{?dist}
+Release:9%{?dist}
Summary:Perl Graphical User Interface ToolKit
Group: Development/Libraries
@@ -20,6 +20,9 @@ Patch3: perl-Tk-XIM.patch
# fix for bugs #491536 #489228 #506496 (see comment #8)
# see http://rt.cpan.org/Public/Bug/Display.html?id=38746
Patch4:perl-Tk-events.patch
+# fix for bug #487122
+# see http://rt.cpan.org/Public/Bug/Display.html?id=31989
+Patch5: perl-Tk-getOpenFile.patch
# fix gif overflow in tk see CVE-2006-4484 and CVE-2007-6697 or #431518 and
# #431529
@@ -64,6 +67,7 @@ chmod -x pod/Popup.pod Tixish/lib/Tk/bal
%patch2 -p1 -b .seg
%patch3 -p1 -b .xim
%patch4 -b .events
+%patch5 -b .getOpenFile
%patch100
%build
@@ -109,6 +113,10 @@ rm -rf $RPM_BUILD_ROOT
%exclude %{perl_vendorarch}/Tk/reindex.pl
%changelog
+* Mon Jun 22 2009 Andreas Bierfert andreas.bierfert[AT]lowlatency.de
+- 804.028-9
+- fix getOpenFile (#487122)
+
* Mon Jun 15 2009 Andreas Bierfert andreas.bierfert[AT]lowlatency.de
- 804.028-8
- fix events (#489228, #491536, #506496)
--
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-CGI-Application-Plugin-Session/devel import.log, NONE, 1.1 perl-CGI-Application-Plugin-Session.spec, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2
Author: eseyman
Update of /cvs/pkgs/rpms/perl-CGI-Application-Plugin-Session/devel
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv20085/devel
Modified Files:
.cvsignore sources
Added Files:
import.log perl-CGI-Application-Plugin-Session.spec
Log Message:
Initial import.
--- NEW FILE import.log ---
perl-CGI-Application-Plugin-Session-1_03-1_fc11:HEAD:perl-CGI-Application-Plugin-Session-1.03-1.fc11.src.rpm:1245797905
--- NEW FILE perl-CGI-Application-Plugin-Session.spec ---
Name: perl-CGI-Application-Plugin-Session
Version:1.03
Release:1%{?dist}
Summary:Add CGI::Session support to CGI::Application
License:GPL+ or Artistic
Group: Development/Libraries
URL:http://search.cpan.org/dist/CGI-Application-Plugin-Session/
Source0:
http://www.cpan.org/authors/id/C/CE/CEESHEK/CGI-Application-Plugin-Session-%{version}.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch: noarch
BuildRequires: perl(CGI::Application) = 3.21
BuildRequires: perl(CGI::Session) = 3.95
BuildRequires: perl(CGI::Simple)
BuildRequires: perl(Module::Build)
BuildRequires: perl(Test::Exception)
BuildRequires: perl(Test::More)
BuildRequires: perl(Test::Pod)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
%description
CGI::Application::Plugin::Session seamlessly adds session support to your
CGI::Application modules by providing a CGI::Session object that is
accessible from anywhere in the application.
%prep
%setup -q -n CGI-Application-Plugin-Session-%{version}
%build
%{__perl} Build.PL installdirs=vendor
./Build
%install
rm -rf $RPM_BUILD_ROOT
./Build install destdir=$RPM_BUILD_ROOT create_packlist=0
find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2/dev/null \;
%{_fixperms} $RPM_BUILD_ROOT/*
%check
./Build test
%clean
rm -rf $RPM_BUILD_ROOT
%files
%defattr(-,root,root,-)
%doc Changes README
%{perl_vendorlib}/*
%{_mandir}/man3/*
%changelog
* Mon Dec 22 2008 Emmanuel Seyman emmanuel.sey...@club-internet.fr 1.03-1
- Specfile autogenerated by cpanspec 1.77.
Index: .cvsignore
===
RCS file: /cvs/pkgs/rpms/perl-CGI-Application-Plugin-Session/devel/.cvsignore,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- .cvsignore 23 Jun 2009 17:33:37 - 1.1
+++ .cvsignore 23 Jun 2009 22:58:52 - 1.2
@@ -0,0 +1 @@
+CGI-Application-Plugin-Session-1.03.tar.gz
Index: sources
===
RCS file: /cvs/pkgs/rpms/perl-CGI-Application-Plugin-Session/devel/sources,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- sources 23 Jun 2009 17:33:37 - 1.1
+++ sources 23 Jun 2009 22:58:52 - 1.2
@@ -0,0 +1 @@
+4fd76fb77afc8b1cfe721b4bc0cdafbf CGI-Application-Plugin-Session-1.03.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-CGI-Application-Plugin-Session/F-11 import.log, NONE, 1.1 perl-CGI-Application-Plugin-Session.spec, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2
Author: eseyman
Update of /cvs/pkgs/rpms/perl-CGI-Application-Plugin-Session/F-11
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv23430/F-11
Modified Files:
.cvsignore sources
Added Files:
import.log perl-CGI-Application-Plugin-Session.spec
Log Message:
Initial import.
--- NEW FILE import.log ---
perl-CGI-Application-Plugin-Session-1_03-1_fc11:F-11:perl-CGI-Application-Plugin-Session-1.03-1.fc11.src.rpm:1245798014
--- NEW FILE perl-CGI-Application-Plugin-Session.spec ---
Name: perl-CGI-Application-Plugin-Session
Version:1.03
Release:1%{?dist}
Summary:Add CGI::Session support to CGI::Application
License:GPL+ or Artistic
Group: Development/Libraries
URL:http://search.cpan.org/dist/CGI-Application-Plugin-Session/
Source0:
http://www.cpan.org/authors/id/C/CE/CEESHEK/CGI-Application-Plugin-Session-%{version}.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch: noarch
BuildRequires: perl(CGI::Application) = 3.21
BuildRequires: perl(CGI::Session) = 3.95
BuildRequires: perl(CGI::Simple)
BuildRequires: perl(Module::Build)
BuildRequires: perl(Test::Exception)
BuildRequires: perl(Test::More)
BuildRequires: perl(Test::Pod)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
%description
CGI::Application::Plugin::Session seamlessly adds session support to your
CGI::Application modules by providing a CGI::Session object that is
accessible from anywhere in the application.
%prep
%setup -q -n CGI-Application-Plugin-Session-%{version}
%build
%{__perl} Build.PL installdirs=vendor
./Build
%install
rm -rf $RPM_BUILD_ROOT
./Build install destdir=$RPM_BUILD_ROOT create_packlist=0
find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2/dev/null \;
%{_fixperms} $RPM_BUILD_ROOT/*
%check
./Build test
%clean
rm -rf $RPM_BUILD_ROOT
%files
%defattr(-,root,root,-)
%doc Changes README
%{perl_vendorlib}/*
%{_mandir}/man3/*
%changelog
* Mon Dec 22 2008 Emmanuel Seyman emmanuel.sey...@club-internet.fr 1.03-1
- Specfile autogenerated by cpanspec 1.77.
Index: .cvsignore
===
RCS file: /cvs/pkgs/rpms/perl-CGI-Application-Plugin-Session/F-11/.cvsignore,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- .cvsignore 23 Jun 2009 17:33:37 - 1.1
+++ .cvsignore 23 Jun 2009 23:10:10 - 1.2
@@ -0,0 +1 @@
+CGI-Application-Plugin-Session-1.03.tar.gz
Index: sources
===
RCS file: /cvs/pkgs/rpms/perl-CGI-Application-Plugin-Session/F-11/sources,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- sources 23 Jun 2009 17:33:37 - 1.1
+++ sources 23 Jun 2009 23:10:10 - 1.2
@@ -0,0 +1 @@
+4fd76fb77afc8b1cfe721b4bc0cdafbf CGI-Application-Plugin-Session-1.03.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-CGI-Application-Plugin-Session/F-10 import.log, NONE, 1.1 perl-CGI-Application-Plugin-Session.spec, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2
Author: eseyman
Update of /cvs/pkgs/rpms/perl-CGI-Application-Plugin-Session/F-10
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv25104/F-10
Modified Files:
.cvsignore sources
Added Files:
import.log perl-CGI-Application-Plugin-Session.spec
Log Message:
Initial import.
--- NEW FILE import.log ---
perl-CGI-Application-Plugin-Session-1_03-1_fc11:F-10:perl-CGI-Application-Plugin-Session-1.03-1.fc11.src.rpm:1245798706
--- NEW FILE perl-CGI-Application-Plugin-Session.spec ---
Name: perl-CGI-Application-Plugin-Session
Version:1.03
Release:1%{?dist}
Summary:Add CGI::Session support to CGI::Application
License:GPL+ or Artistic
Group: Development/Libraries
URL:http://search.cpan.org/dist/CGI-Application-Plugin-Session/
Source0:
http://www.cpan.org/authors/id/C/CE/CEESHEK/CGI-Application-Plugin-Session-%{version}.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch: noarch
BuildRequires: perl(CGI::Application) = 3.21
BuildRequires: perl(CGI::Session) = 3.95
BuildRequires: perl(CGI::Simple)
BuildRequires: perl(Module::Build)
BuildRequires: perl(Test::Exception)
BuildRequires: perl(Test::More)
BuildRequires: perl(Test::Pod)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
%description
CGI::Application::Plugin::Session seamlessly adds session support to your
CGI::Application modules by providing a CGI::Session object that is
accessible from anywhere in the application.
%prep
%setup -q -n CGI-Application-Plugin-Session-%{version}
%build
%{__perl} Build.PL installdirs=vendor
./Build
%install
rm -rf $RPM_BUILD_ROOT
./Build install destdir=$RPM_BUILD_ROOT create_packlist=0
find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2/dev/null \;
%{_fixperms} $RPM_BUILD_ROOT/*
%check
./Build test
%clean
rm -rf $RPM_BUILD_ROOT
%files
%defattr(-,root,root,-)
%doc Changes README
%{perl_vendorlib}/*
%{_mandir}/man3/*
%changelog
* Mon Dec 22 2008 Emmanuel Seyman emmanuel.sey...@club-internet.fr 1.03-1
- Specfile autogenerated by cpanspec 1.77.
Index: .cvsignore
===
RCS file: /cvs/pkgs/rpms/perl-CGI-Application-Plugin-Session/F-10/.cvsignore,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- .cvsignore 23 Jun 2009 17:33:37 - 1.1
+++ .cvsignore 23 Jun 2009 23:20:02 - 1.2
@@ -0,0 +1 @@
+CGI-Application-Plugin-Session-1.03.tar.gz
Index: sources
===
RCS file: /cvs/pkgs/rpms/perl-CGI-Application-Plugin-Session/F-10/sources,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- sources 23 Jun 2009 17:33:37 - 1.1
+++ sources 23 Jun 2009 23:20:02 - 1.2
@@ -0,0 +1 @@
+4fd76fb77afc8b1cfe721b4bc0cdafbf CGI-Application-Plugin-Session-1.03.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-Net-Amazon/devel .cvsignore, 1.4, 1.5 perl-Net-Amazon.spec, 1.3, 1.4 sources, 1.4, 1.5
Author: iarnell
Update of /cvs/pkgs/rpms/perl-Net-Amazon/devel
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv5083
Modified Files:
.cvsignore perl-Net-Amazon.spec sources
Log Message:
* Wed Jun 24 2009 Iain Arnell iarn...@gmail.com 0.54-1
- update to latest upstream
Index: .cvsignore
===
RCS file: /cvs/pkgs/rpms/perl-Net-Amazon/devel/.cvsignore,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -p -r1.4 -r1.5
--- .cvsignore 13 Jun 2009 07:00:14 - 1.4
+++ .cvsignore 24 Jun 2009 04:03:39 - 1.5
@@ -1 +1 @@
-Net-Amazon-0.52.tar.gz
+Net-Amazon-0.54.tar.gz
Index: perl-Net-Amazon.spec
===
RCS file: /cvs/pkgs/rpms/perl-Net-Amazon/devel/perl-Net-Amazon.spec,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -p -r1.3 -r1.4
--- perl-Net-Amazon.spec13 Jun 2009 07:00:15 - 1.3
+++ perl-Net-Amazon.spec24 Jun 2009 04:03:39 - 1.4
@@ -1,5 +1,5 @@
Name: perl-Net-Amazon
-Version:0.52
+Version:0.54
Release:1%{?dist}
Summary:Framework for accessing amazon.com via REST
License:GPL+ or Artistic
@@ -54,6 +54,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Wed Jun 24 2009 Iain Arnell iarn...@gmail.com 0.54-1
+- update to latest upstream
+
* Sat Jun 13 2009 Iain Arnell iarn...@gmail.com 0.52-1
- update to latest upstream
Index: sources
===
RCS file: /cvs/pkgs/rpms/perl-Net-Amazon/devel/sources,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -p -r1.4 -r1.5
--- sources 13 Jun 2009 07:00:15 - 1.4
+++ sources 24 Jun 2009 04:03:39 - 1.5
@@ -1 +1 @@
-0a83d17c0e6bd66d559fdbfd9ff60cfe Net-Amazon-0.52.tar.gz
+822e13802950c1dfc0af23354dbf7c70 Net-Amazon-0.54.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
