Re: abrtd not running: applet complains
On 01/26/2010 10:02 PM, nodata wrote: Hi, When I disable abrtd, I get a tray applet complaining about this. Is there any precedent for this? I have bluetooth disabled, but I don't get a complaint for that.. Filed bug: https://bugzilla.redhat.com/show_bug.cgi?id=557866 This seems like you have an old version of abrt installed or at least the running applet is old version, because this behaviour was removed some time ago. Jirka attachment: jmoskovc.vcf-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphan: Empathy
On 01/27/2010 01:34 AM, Brian Pepple wrote: On Mon, 2010-01-25 at 21:18 -0800, Peter Gordon wrote: I've just released ownership of Empathy's Fedora package on all active branches (F-11, F-12, and devel). I've gone ahead and taken up ownership of this, but would welcome any co-maintainers that want to help out (in particular helping triage all the bugs opened for it). Later, /B I'd like to help you with the triage and maintenance. -- Best regards, Sergey Rudchenko -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Non-responsive maintainer for socat: Paul Wouters (pwouters)
Hi, Paul Wouters seems to be non-repsonsive for socat, there a two bugs open with no response within 6 months: https://bugzilla.redhat.com/show_bug.cgi?id=511310 https://bugzilla.redhat.com/show_bug.cgi?id=513720 He has been pinged by the reporter of the second bug twice on 2009-08-17 and 2009-12-13 and today by me. If there is no response by the end of the week, I would like to execute the FastTrack procedure: https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers#Fast_Track_procedure Then as many communication attempts as suggested in the normal case have been attempted, only with different intervals than one week. List of packages: https://admin.fedoraproject.org/pkgdb/users/packages/pwouters Regards Till pgpCWGXvfAly2.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Moving lspci and setpci from /sbin to /usr/sbin?
Hi all,
in Fedora we have pciutils binaries (lspci and setpci) in /sbin, both of them
use pciutils-libs (/usr/lib/...) and afaik this is how it works for ages.
I'd like to move them from /sbin to /usr/sbin to have them with the same prefix
as library has. Do you think it can break anything?
A few facts:
1)library is already in /usr/lib and lspci/setpci won't work without it
2)pci.ids (lives in hwdata package) is in /usr/share/hwdata
3)yum remove pciutils will remove only system-config-{firewall,network} as
dependencies
Do you think moving this is a bad idea? I think it should not break anything,
only problem can be with separate /usr partition but because of library in
/usr it would be already broken and I've not seen any complain about it ever.
If there are no complains, I'll move it next week (in rawhide only).
Cheers,
Michal Hlavinka
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Qtiplot 0.9.7.11 pushed to rawhide
It can fix Bug 511688 - FTBFS qtiplot-0.9-11.fc11 and Bug 517747 - QtiPlot crashes when trying to plot any graph. But I have no cvs rights to commit F-11 and F-12 branches. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Moving lspci and setpci from /sbin to /usr/sbin?
Hi Michal,
A few thoughts on this:
- on RHEL boxes, the dependency on libpci does not exist and lspci is
in /sbin. Therefore, on RHEL boxes, lspci will still work with a
broken /usr partition. I haven't heard of anyone absolutely needing
lspci on a system with a broken /usr partition, but it *is* possible
to use it. Moving it also breaks a pretty long tradition, but that
should matter too much. I actually prefer lspci to be in my path as a
normal user.
- it would be consistent if lsusb would make the same move to
/usr/sbin, if lspci goes that way.
- I noticed Debian puts lspci in /usr/bin. I'm curious about the
reason lspci is to remain in a sbin directory if it's being moved
anyway.
I haven't been involved in Fedora for that long, but I'd like to
participate in this discussion a bit, if that's ok :-)
Regards,
Maxim Burgerhout
ma...@wzzrd.com
GPG Fingerprint
EB11 5E56 E648 9D99 E8EF 05FB C513 6FD4 1302 B48A
On Wed, Jan 27, 2010 at 14:17, Michal Hlavinka mhlav...@redhat.com wrote:
Hi all,
in Fedora we have pciutils binaries (lspci and setpci) in /sbin, both of them
use pciutils-libs (/usr/lib/...) and afaik this is how it works for ages.
I'd like to move them from /sbin to /usr/sbin to have them with the same
prefix
as library has. Do you think it can break anything?
A few facts:
1)library is already in /usr/lib and lspci/setpci won't work without it
2)pci.ids (lives in hwdata package) is in /usr/share/hwdata
3)yum remove pciutils will remove only system-config-{firewall,network} as
dependencies
Do you think moving this is a bad idea? I think it should not break anything,
only problem can be with separate /usr partition but because of library in
/usr it would be already broken and I've not seen any complain about it ever.
If there are no complains, I'll move it next week (in rawhide only).
Cheers,
Michal Hlavinka
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 553140] Merge Review: perl-MailTools - Various mail-related perl modules
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=553140 Jaroslav Škarvada jskar...@redhat.com changed: What|Removed |Added Flag|fedora-review? |fedora-review+ --- Comment #1 from Jaroslav Škarvada jskar...@redhat.com 2010-01-27 09:11:56 EST --- perl-MailTools-2.06-1 MUST items: [YES] rpmplint is silent for spec and all RPMs. [YES] Package meets naming guidelines. [YES] Package meets packaging guidelines. [YES] Spec file matches base package name. [YES] License match license field in spec file. [YES] Licensing Guidelines are met. [YES] Spec file is legible and in American English. [YES] Sources match upstream. [YES] Package builds OK. [YES] BuildRequires is correct. [YES] Package doesn't bundle copies of system libraries. [YES] Package owns all the directories it creates. [YES] Package has no duplicity in %files. [YES] Permission on files are set properly. [YES] %clean section is correct. [YES] Spec file has consistant macro usage. [YES] Package is code or permissable content. [YES] %doc files don't affect runtime. [YES] No .la libtool archives. [YES][Perl] Package doesn't own files/directories that other packages own. [YES] Package has rm -rf $RPM_BUILD_ROOT at beginning of %install. [YES] All files are valid UTF-8. Should items: [YES] Package builds in mock. [YES] Package uses sane scriptlets. [YES] Package contains man pages. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Orphaning Candidate packages for removal due to FTBFS, implications
On Tue, Jan 19, 2010 at 02:42:58PM -0700, Kevin Fenzi wrote: On Sun, 17 Jan 2010 20:52:12 +0100 Till Maas opensou...@till.name wrote: The list of packages you announced that are going to be orphaned and the list of packages that were orphaned are not the same. recordmydesktop was on the to-be-orphaned list but afaics was not orphaned and also was not mentioned in your list about which provenpackager fixed which package. Odd. Not sure why it wasn't there. I mailed the maintainer and can orphan it. It is still not orphaned afaics. Regards Till pgpqaQa70AEbW.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Moving lspci and setpci from /sbin to /usr/sbin?
On Wednesday 27 January 2010 14:51:15 Maxim Burgerhout wrote:
Hi Michal,
A few thoughts on this:
- on RHEL boxes, the dependency on libpci does not exist and lspci is
in /sbin. Therefore, on RHEL boxes, lspci will still work with a
broken /usr partition. I haven't heard of anyone absolutely needing
lspci on a system with a broken /usr partition, but it *is* possible
to use it. Moving it also breaks a pretty long tradition, but that
should matter too much. I actually prefer lspci to be in my path as a
normal user.
well, on RHEL5 there is no pciutils-libs, so it does not depend on any library
in /usr/lib, but it depends at least on /usr/share/hwdata/pci.ids and without
it lspci is not that useful
- it would be consistent if lsusb would make the same move to
/usr/sbin, if lspci goes that way.
on the other hand lsusb requires library from /usr/lib (on RHEL5) so it is in
/sbin but won't work without mounted /usr (and there are also usb.ids)
- I noticed Debian puts lspci in /usr/bin. I'm curious about the
reason lspci is to remain in a sbin directory if it's being moved
anyway.
good question
I haven't been involved in Fedora for that long, but I'd like to
participate in this discussion a bit, if that's ok :-)
Regards,
Maxim Burgerhout
ma...@wzzrd.com
GPG Fingerprint
EB11 5E56 E648 9D99 E8EF 05FB C513 6FD4 1302 B48A
On Wed, Jan 27, 2010 at 14:17, Michal Hlavinka mhlav...@redhat.com wrote:
Hi all,
in Fedora we have pciutils binaries (lspci and setpci) in /sbin, both of
them use pciutils-libs (/usr/lib/...) and afaik this is how it works for
ages. I'd like to move them from /sbin to /usr/sbin to have them with
the same prefix as library has. Do you think it can break anything?
A few facts:
1)library is already in /usr/lib and lspci/setpci won't work without it
2)pci.ids (lives in hwdata package) is in /usr/share/hwdata
3)yum remove pciutils will remove only system-config-{firewall,network}
as dependencies
Do you think moving this is a bad idea? I think it should not break
anything, only problem can be with separate /usr partition but because
of library in /usr it would be already broken and I've not seen any
complain about it ever.
If there are no complains, I'll move it next week (in rawhide only).
Cheers,
Michal Hlavinka
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning Candidate packages for removal due to FTBFS, implications
On Tue, Jan 19, 2010 at 02:42:17PM -0700, Kevin Fenzi wrote: On Sun, 17 Jan 2010 20:48:25 +0100 Till Maas opensou...@till.name wrote: On Sat, Jan 16, 2010 at 10:39:50AM -0700, Kevin Fenzi wrote: On Sat, 16 Jan 2010 10:39:54 +0100 Till Maas opensou...@till.name wrote: Indeed. I don't see much activity from them. Have you tried sending them an email? If not, I can. No, please go ahead. I took the liberty right after I posted. Did also contact the recordmydesktop maintainer? I didn't then, but I did just now. (Of course that meant I had to send two emails... perhaps next time you could just mail them directly? :) You offered to write both of them and I agreed afaics. Nevertheless I did not mail them directly, because I hoped the full situation could be resolved in some clean way, e.g. just perform a non responsive maintainer procedure on all affected maintainers at once instead of all these quick actions that leave a lot of confusion. Nevertheless, it is too late now, anyhow. Regards Till pgpQgwcFnJvVr.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: disk woes: revive w/o-reboot after SATA START_STOP FAILED?
Hi Jim, On 01/27/2010 10:37 AM, Jim Meyering wrote: But today, there was no trace of it at all. /dev/sdb had disappeared altogether. Ominous. This is up-to-date F12 w/stock untainted 2.6.31.9-174.fc12.x86_64 on an Intel Q9450. Just today I had two spontaneous outages of my HDDs (kernel even didn't found the root partition one of that times). We have one commonality, the intel chipset. I didn't read the logs, I thought that was just a hardware glitch. However, such outages didn't happen for year I use the current hardware configuration. I think of a bug report for kernel component. 00:00.0 Host bridge: Intel Corporation 82G33/G31/P35/P31 Express DRAM Controller (rev 02) 00:01.0 PCI bridge: Intel Corporation 82G33/G31/P35/P31 Express PCI Express Root Port (rev 02) 00:03.0 Communication controller: Intel Corporation 82G33/G31/P35/P31 Express MEI Controller (rev 02) 00:19.0 Ethernet controller: Intel Corporation 82566DC-2 Gigabit Network Connection (rev 02) 00:1a.0 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #4 (rev 02) 00:1a.1 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #5 (rev 02) 00:1a.2 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #6 (rev 02) 00:1a.7 USB Controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #2 (rev 02) 00:1b.0 Audio device: Intel Corporation 82801I (ICH9 Family) HD Audio Controller (rev 02) 00:1c.0 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 1 (rev 02) 00:1c.1 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 2 (rev 02) 00:1c.2 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 3 (rev 02) 00:1c.3 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 4 (rev 02) 00:1c.4 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 5 (rev 02) 00:1d.0 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #1 (rev 02) 00:1d.1 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #2 (rev 02) 00:1d.2 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #3 (rev 02) 00:1d.7 USB Controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #1 (rev 02) 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev 92) 00:1f.0 ISA bridge: Intel Corporation 82801IH (ICH9DH) LPC Interface Controller (rev 02) 00:1f.2 IDE interface: Intel Corporation 82801IR/IO/IH (ICH9R/DO/DH) 4 port SATA IDE Controller (rev 02) 00:1f.3 SMBus: Intel Corporation 82801I (ICH9 Family) SMBus Controller (rev 02) 00:1f.5 IDE interface: Intel Corporation 82801I (ICH9 Family) 2 port SATA IDE Controller (rev 02) 01:00.0 VGA compatible controller: ATI Technologies Inc RV710 [Radeon HD 4350] 01:00.1 Audio device: ATI Technologies Inc R700 Audio Device [Radeon HD 4000 Series] 03:00.0 IDE interface: Marvell Technology Group Ltd. 88SE6101 single-port PATA133 interface (rev b1) -- Best regards, Sergey Rudchenko -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Non-responsive maintainer for socat: Paul Wouters (pwouters)
On Wed, 27 Jan 2010 11:50:44 +0100 Till Maas opensou...@till.name wrote: Hi, Paul Wouters seems to be non-repsonsive for socat, there a two bugs open with no response within 6 months: https://bugzilla.redhat.com/show_bug.cgi?id=511310 https://bugzilla.redhat.com/show_bug.cgi?id=513720 He has been pinged by the reporter of the second bug twice on 2009-08-17 and 2009-12-13 and today by me. If there is no response by the end of the week, I would like to execute the FastTrack procedure: https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers#Fast_Track_procedure Then as many communication attempts as suggested in the normal case have been attempted, only with different intervals than one week. List of packages: https://admin.fedoraproject.org/pkgdb/users/packages/pwouters I see that Paul did a commit yesterday and several others last week. Hopefully he's just swamped and would like to find another maintainer for the socat package. ;( kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning Candidate packages for removal due to FTBFS, implications
On Wed, Jan 27, 2010 at 10:39:38AM -0700, Kevin Fenzi wrote: On Wed, 27 Jan 2010 15:43:40 +0100 Till Maas opensou...@till.name wrote: On Tue, Jan 19, 2010 at 02:42:58PM -0700, Kevin Fenzi wrote: On Sun, 17 Jan 2010 20:52:12 +0100 Till Maas opensou...@till.name wrote: The list of packages you announced that are going to be orphaned and the list of packages that were orphaned are not the same. recordmydesktop was on the to-be-orphaned list but afaics was not orphaned and also was not mentioned in your list about which provenpackager fixed which package. Odd. Not sure why it wasn't there. I mailed the maintainer and can orphan it. It is still not orphaned afaics. Sorry about that, was hoping I would get a reply. Oh, then I misunderstood, I thought you got a reply saying that you can orphan it. I will then go on with a non responsive maintainer procedure. Regards Till pgprlTQjbM6Ur.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
The road to dropping xdvik
Dear All, We currently ship xdvik as a package separate to texlive (for a variety of reasons). Looking forward to when we ship texlive-2009, it'll be built as part of the texlive package build once more. However, even better would be to drop it entirely, for the following reasons: 1) It's a legacy piece of software which is barely maintained - a couple of times a year releases are made with small bugfixes, but there's no actual development 2) We patch it heavily to bodge in japanese support using a separate upstream patch from http://sourceforge.jp/projects/xdvi/, but this patch isn't actively maintained either, and rebasing that patch is a time sink. 3) The need to incoorporate the japanese patch, and also the desire to build against the system installed kpathsea shared lib rather than link statically means we end up hacing the autotools scripts and have to run autotools during package building, and worse, we have to use old autotools as the scripts are so crusty. 4) It's one of the few users of the Xaw(3d) toolkit in the repo, and also requires legacy font support (IIRC). However, it's not clear to me if okular and evince-dvi provide equivalent functionality that we're yet in a position to drop xdvik. Comments? If you use xdvik because other viewers don't give some particular functionality, it would be helpful if you stated what that functionality is. Cheers, Jonathan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Remove write permissions from executables
On Wed, Jan 27, 2010 at 04:10:39PM +0100, Benny Amorsen wrote: Mounting the fs read only is much easier and safer - and has long tradition. This is not feasible as a distribution policy. You can't guarantee that /usr/bin is on its own partition so you can mount it read only. of course it is not guaranteed. But it is not difficult to detect and I think plenty of sysadmins are doing it that way. Used to have many more advantages than just a marginal gain in security. Fedora certainly can not mandate this as a policy it would be nice if it would work with this common setup. Also, the advantage of the proposed change was that it would not affect e.g. yum upgrade. Creative use of mount --bind could perhaps achieve the same result, but not in a way which I consider sane. that would be indeed insane. But as has been mentioned rpm could have a hook to do some actions before and after modifying anything. All in all I think it's a shame that the original proposal didn't work out at this time. Having binaries owned by bin:bin does have Unix (but not Linux AFAIK) tradition behind it. now that you mention bin:bin, I remember the old days. Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fast-track Nonresponsive ma intainer: Sindre Pedersen Bjørdal (sindrepb)
Hi, Sindre Bjørdal seems to be non responsive. Thanks to the recent FTBFS mail, I fixed four bugs in recordmydesktop, that already had patches attached in Bugzilla and did not see any comment from sindrepb: https://admin.fedoraproject.org/updates/F12/FEDORA-2010-0604 The oldest bug was from 2009-09-23. The last build submitted by him is from 2009-09-26: http://koji.fedoraproject.org/koji/builds?userID=sindrepb There are 83 open Bugs assigned to him: https://bugzilla.redhat.com/buglist.cgi?resolution=---emailtype1=exactquery_format=advancedemailassigned_to1=1bug_status=NEWbug_status=ASSIGNEDbug_status=MODIFIEDbug_status=ON_DEVbug_status=ON_QAbug_status=VERIFIEDbug_status=RELEASE_PENDINGbug_status=POSTproduct=Fedoraproduct=Fedora%20EPELemail1=sindrepb%40fedoraproject.org One of these bugs is a non responsive maintainer tracker bug, where he was pinged once and did not respond: https://bugzilla.redhat.com/show_bug.cgi?id=516797 Also Kevin Fenzi tried to contact him via e-mail recently, but did not get a response. He owns 50 Packages: https://admin.fedoraproject.org/pkgdb/users/packages/sindrepb?acls=owner Regards Till pgp3nViiSVfRw.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The road to dropping xdvik
On Wed, 2010-01-27 at 18:04 +, Jonathan Underwood wrote: However, it's not clear to me if okular and evince-dvi provide equivalent functionality that we're yet in a position to drop xdvik. Comments? If you use xdvik because other viewers don't give some particular functionality, it would be helpful if you stated what that functionality is. As a heavy LaTeX user I would be really against dropping xdvi before there is some other app that runs as fast. Evince very slow - xdvi shows pages straight away, whereas evince often displays Loading... -- Jussi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The road to dropping xdvik
Jussi Lehtola on 01/27/2010 01:45 PM wrote: As a heavy LaTeX user I would be really against dropping xdvi before there is some other app that runs as fast. Evince very slow - xdvi shows pages straight away, whereas evince often displays Loading... How about profiling evince instead? perf should make it dead-simple for you. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora 13 Milestone Reached: Feature and Spin Submission Deadlines
A friendly reminder that yesterday, January 26, 2010, we reached the Feature and Spin submission deadline. Any new features or spins submitted after yesterday will be targeted for Fedora 14. A summary of the Fedora 13 milestones and exception process is here: https://fedoraproject.org/wiki/Important_Release_Milestones The next significant schedule milestone is Feature Freeze on February 9, 2010. At Feature Freeze it is expected that all features are *significantly* feature complete and ready for testing. https://fedoraproject.org/wiki/Feature_Freeze_Policy. Features which are not significantly feature complete at Feature Freeze will be reviewed on an exception basis by FESCo or deferred to Fedora 14. Thank you, John p.s. If you have questions about our release processes or milestones please reply to this email or contact me directly and I will be glad to assist. ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Moving lspci and setpci from /sbin to /usr/sbin?
Michal Hlavinka (mhlav...@redhat.com) said: Do you think moving this is a bad idea? I think it should not break anything, only problem can be with separate /usr partition but because of library in /usr it would be already broken and I've not seen any complain about it ever. Furthermore, most all of the information provided by lspci in a no-/usr recovery situation can be found in /sys if absolutely necessary. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Calibre: broken package dependencies?
Can't install Calibre on Fedora (KDE) as of today. Complains about an inferior version of python-cssutils. It seems to require a more bleeding edge version that is not in either updates-testing or rawhide. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: abrt not working in current Rawhide?
Adam Williamson (awill...@redhat.com) said: Just checking if I'm the only one - I can't find a bug report, though I'll probably file one. abrt doesn't seem to work in current Rawhide. The daemon and applet both claim to be running, but I never get an abrt pop-up when anything crashes (which happens a lot in current Rawhide...) Incompatiblity with the 2.6.32 kernel (it's in bugzilla). Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: abrtd not running: applet complains
On 27/01/10 09:29, Jiri Moskovcak wrote: On 01/26/2010 10:02 PM, nodata wrote: Hi, When I disable abrtd, I get a tray applet complaining about this. Is there any precedent for this? I have bluetooth disabled, but I don't get a complaint for that.. Filed bug: https://bugzilla.redhat.com/show_bug.cgi?id=557866 This seems like you have an old version of abrt installed or at least the running applet is old version, because this behaviour was removed some time ago. Jirka I have the latest version of F12 abrt installed. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New merge review tickets being opened
Jason L Tibbitts III (ti...@math.uh.edu) said: Some Red Hat employees are opening new merge review tickets for packages which were in extras long before the big core-extras merge. It looks like all of these packages are so old that the reviews predate the use of Red Hat's bugzilla for the purpose, and so those reviews were either done on the old mailing list or in the old fedora.us bugzilla (which I believe has been lost). No Fedora policy requires that these packages be re-reviewed. The evidence seems to point to some Red Hat policy requiring review tickets for these packages, although I can't seem to get a proper answer from someone who actually knows. There is a new internal process that encourages that packages have existing Fedora reviews. This is likely a consequence of that, although it's certainly never mentioned directly in the process. (I'd suspect that there is likely to be some uptick in merge review activity as well.) Given that the reviewers are currently overburdened and are barely able to keep up with existing submissions, plus the fact that we still have a few hundred of the original merge review tickets still open, I don't think that adding more to the pile is going to be remotely helpful. If there's a Red Hat policy which requires this, then Red Hat should be taking care of this instead of leaving it to the overburdened Fedora community. The fact that there's been no communication about it only adds insult to injury. I propose that the 'Product' on these tickets be changed to something other than 'Fedora' so that they don't appear to be part of any Fedora process. I'm happy to do that if someone can tell me which component to use. How so? They're reviews of Fedora packages. If the queue's not being processed quickly, the queue won't be processed quickly. If these reviews need quick attention, then I suspect resources will need to be assigned to them. If they don't, then they won't. I'm not convinced that adding 12 packages to the queue (the current count of these) is anything to worry about, given that we get more new submissions than that per week already without any other controls. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: boost update status
On Wed, 2010-01-27 at 14:13 -0800, Benjamin Kosnik wrote: ... looking pretty good. Thanks everybody! Some deps still need to be rebuilt (qpid). Here are some details from somewhat current rawhide reports cross indexed with koji: [snip] gnuradio python? http://koji.fedoraproject.org/koji/getfile?taskID=1936885name=build.log Missing python headers: looks like python-devel wasn't installed. Looking at http://koji.fedoraproject.org/koji/getfile?taskID=1936885name=root.log I see: DEBUG util.py:256:python.x86_64 0:2.6.4-7.fc13 DEBUG util.py:256:python-libs.x86_64 0:2.6.4-7.fc13 DEBUG util.py:256:python-nose.noarch 0:0.11.1-2.fc13 DEBUG util.py:256:python-setuptools.noarch 0:0.6.9-1.fc13 and no python-devel (see also http://koji.fedoraproject.org/koji/taskinfo?taskID=1936885 ) If this package is compiling against /usr/include/python2.6 it needs a BR on python-devel; perhaps this was implicit before, but something changed? I have made a few recent changes to python itself, hope I didn't break anything. [snip] Hope this is helpful Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Re:Qtiplot 0.9.7.11 pushed to rawhide
Am Mittwoch, den 27.01.2010, 22:00 +0800 schrieb Chen Lei: Is there any provenpackager that can help me to sync F-11 and F-12 branches with devel's, since the original ower of qtiplot doesn't maintain any packages for more than one year. See http://koji.fedoraproject.org/koji/userinfo?userID=251 at 2010-01-27 21:49:23，Chen Lei supercy...@163.com Wrote： It can fix Bug 511688 - FTBFS qtiplot-0.9-11.fc11 and Bug 517747 - QtiPlot crashes when trying to plot any graph. But I have no cvs rights to commit F-11 and F-12 branches. I think, you should try to ping the original owner and if he does not respond, take the package. (He seems to be nonresponsive since quite a while, so you could do the Fast Track Procedure.) See: http://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Moving lspci and setpci from /sbin to /usr/sbin?
On Wed, Jan 27, 2010 at 02:51:15PM +0100, Maxim Burgerhout wrote: - I noticed Debian puts lspci in /usr/bin. I'm curious about the reason lspci is to remain in a sbin directory if it's being moved anyway. +1, please. -- Matthew Miller mat...@mattdm.org http://mattdm.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Purging the F13 orphans
It's that time of the release cycle again, to purge the orphans before we get to feature freeze. Any unblocked orphans will be purged by the feature freeze. A list of unblocked orphans and the broken deps they would cause is at the end of this email. Taking ownership of an orphan on the devel collection will prevent them from being blocked. Remember, it is OK to let software die. Don't view this as a list of things that somebody should pick up if they have the spare time. Things should only be revived if there are actual users in need of the software. Unblocked orphan apt-mirror Unblocked orphan avarice Unblocked orphan backintime Unblocked orphan bauble Unblocked orphan clutter-gtkmm Unblocked orphan cluttermm Unblocked orphan cohoba Unblocked orphan dbxml Unblocked orphan dbxml-perl Unblocked orphan fbset Unblocked orphan gdome2 Unblocked orphan gfeed Unblocked orphan glade2 Unblocked orphan gmfsk Unblocked orphan gnome-common Unblocked orphan gtk-qt-engine Unblocked orphan gtk-sharp Unblocked orphan isight-firmware-tools Unblocked orphan jna-posix Unblocked orphan k3d Unblocked orphan keyjnote Unblocked orphan libFoundation Unblocked orphan libipoddevice Unblocked orphan libvisual Unblocked orphan libvisual-plugins Unblocked orphan libwps Unblocked orphan mhonarc Unblocked orphan moodbar Unblocked orphan nautilus-python Unblocked orphan nhpf Unblocked orphan nssbackup Unblocked orphan oooqs2 Unblocked orphan pdfedit Unblocked orphan pdumpfs Unblocked orphan perl-AnyEvent-XMPP Unblocked orphan perl-DDL-Oracle Unblocked orphan perl-Jemplate Unblocked orphan perl-MooseX-Traits-Attribute-CascadeClear Unblocked orphan perl-RRD-Simple Unblocked orphan perl-SVN-Mirror Unblocked orphan perl-SVN-Simple Unblocked orphan php-pear-Config Unblocked orphan pic2aa Unblocked orphan plotutils Unblocked orphan prctl Unblocked orphan python-pgsql Unblocked orphan qca Unblocked orphan qca-gnupg Unblocked orphan qca-ossl Unblocked orphan qca-tls Unblocked orphan qtoctave Unblocked orphan recordmydesktop Unblocked orphan roxterm Unblocked orphan sbackup Unblocked orphan showimg Unblocked orphan smarteiffel Unblocked orphan synce-kde Unblocked orphan uisp Unblocked orphan unifdef Unblocked orphan windowlab Unblocked orphan xhotkeys Unblocked orphan xmms-sid Unblocked orphan xqilla10 Unblocked orphan yoltia List of deps left behind by orphan removal: Orphan: cluttermm clutter-gtkmm requires libcluttermm-0.9.so.3 clutter-gtkmm requires cluttermm-devel = 0.9.4-3.20090907git.fc12 clutter-gtkmm-devel requires pkgconfig(cluttermm-0.9) = 0.9.4 clutter-gtkmm-devel requires cluttermm-devel = 0.9.4-3.20090907git.fc12 Orphan: dbxml dbxml-perl requires libdbxml-2.4.so dbxml-perl requires dbxml-devel = 2.4.16-0.5.fc12 Orphan: gdome2 workrave requires libgdome.so.0 workrave requires gdome2-devel = 0.8.1-9.fc12 Orphan: gnome-common anerley requires gnome-common = 2.28.0-1.fc12 at-spi requires gnome-common = 2.28.0-1.fc12 avant-window-navigator requires gnome-common = 2.28.0-1.fc12 control-center requires gnome-common = 2.28.0-1.fc12 cowbell requires gnome-common = 2.28.0-1.fc12 cups-pk-helper requires gnome-common = 2.28.0-1.fc12 dalston requires gnome-common = 2.28.0-1.fc12 epiphany requires gnome-common = 2.28.0-1.fc12 evolution requires gnome-common = 2.28.0-1.fc12 evolution-data-server requires gnome-common = 2.28.0-1.fc12 evolution-exchange requires gnome-common = 2.28.0-1.fc12 evolution-rspam requires gnome-common = 2.28.0-1.fc12 evolution-rss requires gnome-common = 2.28.0-1.fc12 gconf-editor requires gnome-common = 2.28.0-1.fc12 gedit requires gnome-common = 2.28.0-1.fc12 gedit-vala requires gnome-common = 2.28.0-1.fc12 gjs requires gnome-common = 2.28.0-1.fc12 gnome-commander requires gnome-common = 2.28.0-1.fc12 gnome-desktop requires gnome-common = 2.28.0-1.fc12 gnome-disk-utility requires gnome-common = 2.28.0-1.fc12 gnome-screensaver requires gnome-common = 2.28.0-1.fc12 gnome-session requires gnome-common = 2.28.0-1.fc12 gnome-shell requires gnome-common = 2.28.0-1.fc12 gnome-system-monitor requires gnome-common = 2.28.0-1.fc12 gnome-utils requires gnome-common = 2.28.0-1.fc12 gobject-introspection requires gnome-common = 2.28.0-1.fc12 gthumb requires gnome-common = 2.28.0-1.fc12 gtkhtml3 requires gnome-common = 2.28.0-1.fc12 hornsey requires gnome-common = 2.28.0-1.fc12 jana requires gnome-common = 2.28.0-1.fc12 libgnomecups requires gnome-common = 2.28.0-1.fc12 liblicense requires gnome-common = 2.28.0-1.fc12 moblin-app-installer requires gnome-common = 2.28.0-1.fc12 moblin-panel-applications requires gnome-common = 2.28.0-1.fc12 moblin-panel-media requires gnome-common = 2.28.0-1.fc12 moblin-panel-myzone requires gnome-common = 2.28.0-1.fc12 moblin-panel-pasteboard requires gnome-common = 2.28.0-1.fc12 moblin-panel-people requires
File MailTools-2.06.tar.gz uploaded to lookaside cache by pghmcfc
A file has been added to the lookaside cache for perl-MailTools: 3f90297c7f566cc0cc9c89ee47906abf MailTools-2.06.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
rpms/perl-MIME-Lite/devel perl-MIME-Lite.spec,1.15,1.16
Author: mmaslano
Update of /cvs/pkgs/rpms/perl-MIME-Lite/devel
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv22655
Modified Files:
perl-MIME-Lite.spec
Log Message:
Replace dos2unix with sed. No additional BR.
Index: perl-MIME-Lite.spec
===
RCS file: /cvs/pkgs/rpms/perl-MIME-Lite/devel/perl-MIME-Lite.spec,v
retrieving revision 1.15
retrieving revision 1.16
diff -u -p -r1.15 -r1.16
--- perl-MIME-Lite.spec 27 Jan 2010 10:24:43 - 1.15
+++ perl-MIME-Lite.spec 27 Jan 2010 10:44:43 - 1.16
@@ -26,8 +26,8 @@ not require that you have the Mail:: or
%prep
%setup -q -n MIME-Lite-%{version}
-dos2unix examples/*
-dos2unix contrib/README
+sed -i 's/\r//' examples/*
+sed -i 's/\r//' contrib/README
%build
%{__perl} Makefile.PL INSTALLDIRS=vendor
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 553142] Merge Review: perl-MIME-tools - Modules for parsing and creating MIME entities in Perl
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=553142 --- Comment #2 from Paul Howarth p...@city-fan.org 2010-01-27 06:32:10 EST --- (In reply to comment #1) MUST items: [NO] rpmplint is silent $ rpmlint *.rpm perl-MIME-tools.noarch: W: spurious-executable-perm /usr/share/doc/perl-MIME-tools-5.427/examples/mimeabuse perl-MIME-tools.noarch: W: spurious-executable-perm /usr/share/doc/perl-MIME-tools-5.427/examples/mimetour perl-MIME-tools.noarch: W: spurious-executable-perm /usr/share/doc/perl-MIME-tools-5.427/examples/mimesender perl-MIME-tools.noarch: W: spurious-executable-perm /usr/share/doc/perl-MIME-tools-5.427/examples/mimeprint perl-MIME-tools.noarch: W: spurious-executable-perm /usr/share/doc/perl-MIME-tools-5.427/examples/mimeref perl-MIME-tools.noarch: W: doc-file-dependency /usr/share/doc/perl-MIME-tools-5.427/examples/mimesender perl(Mail::Send) perl-MIME-tools.noarch: W: doc-file-dependency /usr/share/doc/perl-MIME-tools-5.427/examples/mimeref perl(Data::Dumper) 2 packages and 0 specfiles checked; 0 errors, 7 warnings. Note that, as commented in the spec file, the dependencies on perl(Mail::Send) and perl(Data::Dumper) are satisfied by packages that are already dependencies of perl-MIME-tools, so these are not additional dependencies. Having the example scripts executable makes them easier to try out and doesn't cause any additional problems. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 553140] Merge Review: perl-MailTools - Various mail-related perl modules
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=553140 Jaroslav Škarvada jskar...@redhat.com changed: What|Removed |Added Status|NEW |ASSIGNED CC||jskar...@redhat.com, ||mmasl...@redhat.com AssignedTo|nob...@fedoraproject.org|jskar...@redhat.com -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
rpms/perl-Crypt-OpenSSL-Random/devel perl-Crypt-OpenSSL-Random.spec, 1.9, 1.10
Author: kasal
Update of /cvs/pkgs/rpms/perl-Crypt-OpenSSL-Random/devel
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv30514
Modified Files:
perl-Crypt-OpenSSL-Random.spec
Log Message:
- fix the package name for error messages
Index: perl-Crypt-OpenSSL-Random.spec
===
RCS file:
/cvs/pkgs/rpms/perl-Crypt-OpenSSL-Random/devel/perl-Crypt-OpenSSL-Random.spec,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -p -r1.9 -r1.10
--- perl-Crypt-OpenSSL-Random.spec 4 Dec 2009 02:16:09 - 1.9
+++ perl-Crypt-OpenSSL-Random.spec 27 Jan 2010 16:53:46 - 1.10
@@ -1,11 +1,12 @@
Name: perl-Crypt-OpenSSL-Random
Version:0.04
-Release:10%{?dist}
+Release:11%{?dist}
Summary:Perl interface to OpenSSL for Random
License:GPL+ or Artistic
Group: Development/Libraries
URL:http://search.cpan.org/dist/Crypt-OpenSSL-Random/
Source0:
http://www.cpan.org/authors/id/I/IR/IROBERTS/Crypt-OpenSSL-Random-%{version}.tar.gz
+Patch0:perl-Crypt-OpenSSL-Random-name.patch
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildRequires: openssl openssl-devel perl(ExtUtils::MakeMaker)
@@ -17,6 +18,7 @@ pseudo-random number generator
%prep
%setup -q -n Crypt-OpenSSL-Random-%{version}
+%patch0 -p1 -b name
%build
%{__perl} Makefile.PL INSTALLDIRS=vendor
@@ -27,10 +29,9 @@ 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 \;
-find %{buildroot} -type f -name '*.bs' -size 0 -exec rm -f {} \;
-
+find %{buildroot} -type f \( -name .packlist -o \
+ -name '*.bs' -empty \) -exec rm {} \;
+find %{buildroot} -depth -type d -empty -exec rmdir {} \;
%{_fixperms} %{buildroot}/*
%check
@@ -48,6 +49,9 @@ rm -rf %{buildroot}
%{_mandir}/man3/*
%changelog
+* Wed Jan 27 2010 Stepan Kasal ska...@redhat.com - 0.04-11
+- fix the package name for error messages
+
* Fri Dec 4 2009 Stepan Kasal ska...@redhat.com - 0.04-10
- rebuild against perl 5.10.1
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
rpms/perl-Crypt-OpenSSL-Random/devel perl-Crypt-OpenSSL-Random-name.patch, NONE, 1.1
Author: kasal Update of /cvs/pkgs/rpms/perl-Crypt-OpenSSL-Random/devel In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv31371 Added Files: perl-Crypt-OpenSSL-Random-name.patch Log Message: - fix the package name for error messages perl-Crypt-OpenSSL-Random-name.patch: Random.xs |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- NEW FILE perl-Crypt-OpenSSL-Random-name.patch --- 2010-01-27 Stepan Kasal ska...@redhat.com * Random.xs: fix PACLAGE_NAME --- Crypt-OpenSSL-Random-0.04/Random.xs.name2006-01-06 15:49:32.0 +0100 +++ Crypt-OpenSSL-Random-0.04/Random.xs 2010-01-27 17:49:01.0 +0100 @@ -4,7 +4,7 @@ #include openssl/rand.h -#define PACKAGE_NAME Crypt::OpenSSL::RSA +#define PACKAGE_NAME Crypt::OpenSSL::Random MODULE = Crypt::OpenSSL::RandomPACKAGE = Crypt::OpenSSL::Random void -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File DateTime-TimeZone-1.10.tar.gz uploaded to lookaside cache by kasal
A file has been added to the lookaside cache for perl-DateTime: bdc85c10d9958298e41e294e8e9ea85d DateTime-TimeZone-1.10.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
rpms/perl-DateTime/devel .cvsignore, 1.25, 1.26 perl-DateTime.spec, 1.35, 1.36 sources, 1.25, 1.26
Author: kasal
Update of /cvs/extras/rpms/perl-DateTime/devel
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv13721
Modified Files:
.cvsignore perl-DateTime.spec sources
Log Message:
- new upstream version of DateTime-TimeZone
Index: .cvsignore
===
RCS file: /cvs/extras/rpms/perl-DateTime/devel/.cvsignore,v
retrieving revision 1.25
retrieving revision 1.26
diff -u -p -r1.25 -r1.26
--- .cvsignore 15 Jan 2010 19:27:56 - 1.25
+++ .cvsignore 27 Jan 2010 19:36:22 - 1.26
@@ -1,3 +1,3 @@
DateTime-0.53.tar.gz
DateTime-Locale-0.44.tar.gz
-DateTime-TimeZone-1.08.tar.gz
+DateTime-TimeZone-1.10.tar.gz
Index: perl-DateTime.spec
===
RCS file: /cvs/extras/rpms/perl-DateTime/devel/perl-DateTime.spec,v
retrieving revision 1.35
retrieving revision 1.36
diff -u -p -r1.35 -r1.36
--- perl-DateTime.spec 15 Jan 2010 19:27:57 - 1.35
+++ perl-DateTime.spec 27 Jan 2010 19:36:22 - 1.36
@@ -1,11 +1,11 @@
%define DT_version 0.53
%define DTLocale_version 0.44
-%define DTTimeZone_version 1.08
+%define DTTimeZone_version 1.10
Name: perl-DateTime
# must now be 0.xx00 to preserve upgrade path:
Version:%{DT_version}00
-Release:1%{?dist}
+Release:2%{?dist}
Epoch: 1
Summary:Date and time objects
License:GPL+ or Artistic
@@ -139,6 +139,9 @@ rm -rf $RPM_BUILD_ROOT
%{perl_vendorarch}/DateTime*.pm
%changelog
+* Wed Jan 27 2010 Stepan Kasal ska...@redhat.com - 1:0.5300-2
+- new upstream version of DateTime-TimeZone
+
* Fri Jan 15 2010 Stepan Kasal ska...@redhat.com - 1:0.5300-1
- new upstream version
- use Build.PL as Makefile.PL no longer exists
Index: sources
===
RCS file: /cvs/extras/rpms/perl-DateTime/devel/sources,v
retrieving revision 1.25
retrieving revision 1.26
diff -u -p -r1.25 -r1.26
--- sources 15 Jan 2010 19:27:57 - 1.25
+++ sources 27 Jan 2010 19:36:22 - 1.26
@@ -1,3 +1,3 @@
bc2db48557d9520ad5095895daa1cb0b DateTime-0.53.tar.gz
f2e4ba9f2de67d2296c92da2e7c8b27d DateTime-Locale-0.44.tar.gz
-5ea91e005828226e234d5fd7dbf6f894 DateTime-TimeZone-1.08.tar.gz
+bdc85c10d9958298e41e294e8e9ea85d DateTime-TimeZone-1.10.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
rpms/perl-Fedora-Bugzilla/devel perl-Fedora-Bugzilla.spec,1.7,1.8
Author: spot
Update of /cvs/pkgs/rpms/perl-Fedora-Bugzilla/devel
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv9928
Modified Files:
perl-Fedora-Bugzilla.spec
Log Message:
drop hardcoded Requires on MooseX::Traits::Attribute::CascadeClear
Index: perl-Fedora-Bugzilla.spec
===
RCS file: /cvs/pkgs/rpms/perl-Fedora-Bugzilla/devel/perl-Fedora-Bugzilla.spec,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -p -r1.7 -r1.8
--- perl-Fedora-Bugzilla.spec 15 Jan 2010 16:17:46 - 1.7
+++ perl-Fedora-Bugzilla.spec 28 Jan 2010 01:56:28 - 1.8
@@ -1,6 +1,6 @@
Name: perl-Fedora-Bugzilla
Version:0.13
-Release:1%{?dist}
+Release:2%{?dist}
Summary:Access Fedora's Bugzilla
Group: Development/Libraries
@@ -45,7 +45,6 @@ BuildRequires: perl(Test::More)
# not automagically picked up atm (grrr)
Requires: perl(Crypt::SSLeay)
Requires: perl(MooseX::MultiInitArg)
-Requires: perl(MooseX::Traits::Attribute::CascadeClear)
%description
The XML-RPC interface to bugzilla is quite useful, and while Bugzilla 3.x
@@ -94,6 +93,9 @@ rm -rf %{buildroot}
%changelog
+* Wed Jan 27 2010 Tom spot Callaway tcall...@redhat.com - 0.13-2
+- drop hardcoded requires on MooseX::Traits::Attribute::CascadeClear
+
* Fri Jan 15 2010 Tom spot Callaway tcall...@redhat.com - 0.13-1
- update to 0.13, change BR from MooseX::Traits::Attribute::CascadeClear to
MooseX::CascadeClearing
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
