[Bug 636803] Update mldonkey to ver. 3.0.5

2011-04-24 Thread bugzilla
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=636803

--- Comment #3 from Richard W.M. Jones rjo...@redhat.com 2011-04-24 16:45:27 
EDT ---
If you are a Fedora packager and are motivated, please ask for
co-maintainer on this package.

-- 
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.
___
ocaml-devel mailing list
ocaml-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/ocaml-devel


Re: FC15 beta testing result by my 76-year old uncle

2011-04-24 Thread Andy Green
On 04/23/2011 08:46 PM, Somebody in the thread at some point said:

Hi -

 I've setup FC15 beta for  my 76-year old uncle. The major issues
 encountered:
 * wake up from suspend didn't work on his laptop; on another one does

I thought my suspend was broken on this laptop.  But it turned out it is 
hit by a bug where the driver (nouveau) tries to reload firmwire in its 
resume code while userspace is still frozen.  That fails, but only after 
sitting there looking dead for 60s.  After the timeout, it resumes 
great.  So it might be worth trying.

 * logitech quickcam express doesn't work -- light goes on in
 Cheese/skype, but not image

I don't know about it specifically, but when I use my USB microscope I 
use Camorama.  Notice though it has no UI to select device, you have to 
give a switch --device=/dev/video1 on commandline if it's not the first 
video device.  It also might be worth a try.

-Andy
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


rawhide report: 20110424 changes

2011-04-24 Thread Rawhide Report
Compose started at Sun Apr 24 08:15:02 UTC 2011

Broken deps for x86_64
--
beldi-0.9.25-3.fc15.x86_64 requires libhal-storage.so.1()(64bit)
beldi-0.9.25-3.fc15.x86_64 requires libhal.so.1()(64bit)
beldi-0.9.25-3.fc15.x86_64 requires hal
callweaver-javascript-1.2.1-8.fc16.x86_64 requires libjs.so.1()(64bit)
camcardsync-0.1.1-4.fc15.x86_64 requires libhal.so.1()(64bit)
couchdb-1.0.2-2.fc16.x86_64 requires libjs.so.1()(64bit)
cpm-0.23-0.3.beta.fc12.x86_64 requires libdotconf-1.0.so.0()(64bit)
db4o-7.4-2.fc13.x86_64 requires mono(Mono.GetOptions) = 0:2.0.0.0
dbmail-3.0.0-0.3.rc1.fc15.x86_64 requires libevent-1.4.so.2()(64bit)
dbmail-auth-ldap-3.0.0-0.3.rc1.fc15.x86_64 requires 
libevent-1.4.so.2()(64bit)
dh-make-0.55-3.fc15.noarch requires debhelper
emerillon-0.1.2-14.fc15.x86_64 requires 
libchamplain-gtk-0.8.so.1()(64bit)
emerillon-0.1.2-14.fc15.x86_64 requires libchamplain-0.8.so.1()(64bit)
exaile-0.3.2.1-1.fc16.noarch requires hal
file-browser-applet-0.6.6-1.fc15.x86_64 requires 
libpanel-applet-2.so.0()(64bit)
gedit-valencia-0.3.0-4.fc14.x86_64 requires libvala-0.10.so.0()(64bit)
2:gimp-2.6.11-8.fc16.x86_64 requires libhal.so.1()(64bit)
glunarclock-0.34.1-1.fc14.x86_64 requires 
libpanel-applet-2.so.0()(64bit)
gnomad2-2.9.4-7.fc15.x86_64 requires libhal.so.1()(64bit)
gnome-applet-bubblemon-2.0.15-1.fc13.x86_64 requires 
libpanel-applet-2.so.0()(64bit)
gnome-applet-cpufire-1.6-3.fc14.x86_64 requires 
libpanel-applet-2.so.0()(64bit)
gnome-applet-globalmenu-0.7.9-1.fc15.x86_64 requires 
libpanel-applet-2.so.0()(64bit)
gnome-applet-grandr-0.4.1-2.fc12.x86_64 requires 
libpanel-applet-2.so.0()(64bit)
gnome-applet-music-2.5.1-5.fc15.x86_64 requires 
libpanel-applet-2.so.0()(64bit)
gnome-applet-sensors-2.2.7-4.fc15.i686 requires libpanel-applet-2.so.0
gnome-applet-sensors-2.2.7-4.fc15.x86_64 requires 
libpanel-applet-2.so.0()(64bit)
gnome-applet-sshmenu-3.18-3.fc15.noarch requires ruby(panelapplet2)
gnome-applet-window-picker-0.5.8-2.fc14.x86_64 requires 
libpanel-applet-2.so.0()(64bit)
1:gnome-applets-2.32.0-3.fc15.x86_64 requires 
libpanel-applet-3.so.0()(64bit)
1:gnome-applets-2.32.0-3.fc15.x86_64 requires 
libpanel-applet-2.so.0()(64bit)
1:gnome-applets-2.32.0-3.fc15.x86_64 requires libgweather.so.1()(64bit)
gnome-device-manager-0.2-6.fc15.x86_64 requires libhal.so.1()(64bit)
gnome-device-manager-devel-0.2-6.fc15.i686 requires hal-devel = 
0:0.5.10
gnome-device-manager-devel-0.2-6.fc15.i686 requires pkgconfig(hal)
gnome-device-manager-devel-0.2-6.fc15.x86_64 requires hal-devel = 
0:0.5.10
gnome-device-manager-devel-0.2-6.fc15.x86_64 requires pkgconfig(hal)
gnome-device-manager-libs-0.2-6.fc15.i686 requires libhal.so.1
gnome-device-manager-libs-0.2-6.fc15.i686 requires hal = 0:0.5.10
gnome-device-manager-libs-0.2-6.fc15.x86_64 requires 
libhal.so.1()(64bit)
gnome-device-manager-libs-0.2-6.fc15.x86_64 requires hal = 0:0.5.10
gnome-netstatus-2.28.2-1.fc15.x86_64 requires 
libpanel-applet-2.so.0()(64bit)
gnome-pilot-conduits-2.32.1-2.fc15.x86_64 requires 
libgpilotdconduit.so.3()(64bit)
gnome-pilot-conduits-2.32.1-2.fc15.x86_64 requires 
libgpilotd.so.5()(64bit)
gnome-pilot-conduits-2.32.1-2.fc15.x86_64 requires 
libgpilotdcm.so.4()(64bit)
gnome-python2-applet-2.32.0-1.fc14.x86_64 requires 
libpanel-applet-2.so.0()(64bit)
gnome-python2-brasero-2.32.0-1.fc14.x86_64 requires 
libbrasero-burn.so.1()(64bit)
gnome-python2-brasero-2.32.0-1.fc14.x86_64 requires 
libbrasero-media.so.1()(64bit)
gnome-python2-evince-2.32.0-1.fc14.x86_64 requires 
libevview.so.3()(64bit)
gnome-python2-evince-2.32.0-1.fc14.x86_64 requires 
libevdocument.so.3()(64bit)
gnome-python2-evolution-2.32.0-1.fc14.x86_64 requires 
libcamel-1.2.so.19()(64bit)
gnome-python2-gdl-2.25.3-22.fc15.x86_64 requires libgdl-1.so.3()(64bit)
gnome-python2-totem-2.32.0-1.fc14.x86_64 requires 
libgnome-media-profiles.so.0()(64bit)
gnome-rdp-0.2.3-6.fc12.x86_64 requires mono(Mono.Data.SqliteClient) = 
0:2.0.0.0
gnotime-2.3.0-8.fc15.x86_64 requires libgtkhtml-3.15.so.19()(64bit)
gnubiff-2.2.13-4.fc15.x86_64 requires libpanel-applet-2.so.0()(64bit)
gold-2.1.12.2-5.fc15.noarch requires perl(Data::Properties)
gpx-viewer-0.2.0-3.fc14.x86_64 requires libchamplain-0.6.so.0()(64bit)
gpx-viewer-0.2.0-3.fc14.x86_64 requires 
libchamplain-gtk-0.6.so.0()(64bit)
gpx-viewer-0.2.0-3.fc14.x86_64 requires libgdl-1.so.3()(64bit)
gyachi-plugin-libnotify-1.2.10-3.fc14.x86_64 requires 
libnotify.so.1()(64bit)
hal-info-20090716-4.fc15.noarch requires 

Possible to submit an update without obsoleting?

2011-04-24 Thread Richard W.M. Jones

In general I like the auto-obsoleting feature in Bodhi, but is there a
way to disable it for a particular update?

The reason is that I've got libguestfs-1.10.1-1.fc15 waiting to go
into stable.  I've also just built libguestfs-1.10.2-1.fc15 which is a
further update along the upstream stable branch.

If I submit this second update, it will auto-obsolete the first
update.  However the first update is perfectly fine in itself, and
more importantly it fixes a dependency problem.  If it gets obsoleted
then users will have to wait another 3-4 days in order to get the
dependency fix and won't be able to use the package at all during this
time.  My only choice seems to be to not submit the second update at
all, which means no one can test it, and the eventual release of it
will be later than it needs to be.  I'd like to pipeline the
updates.

This is a general problem with auto-obsoleting if the period between
releases  the period in updates-testing (which is the case in
libguestfs because of our quite rapid release schedule).  In the past
I've had chains of updates causing delays to get *any* package out of
3-4 weeks.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://et.redhat.com/~rjones/virt-df/
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: Possible to submit an update without obsoleting?

2011-04-24 Thread Frank Murphy
On 24/04/11 11:37, Richard W.M. Jones wrote:

 In general I like the auto-obsoleting feature in Bodhi, but is there a
 way to disable it for a particular update?


Not an answer to the problem?
But what about a fedorapeople repo?
Ask testers to enable it.


-- 
Regards,

Frank Murphy
UTF_8 Encoded
Friend of Fedora
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: Possible to submit an update without obsoleting?

2011-04-24 Thread Michael Schwendt
On Sun, 24 Apr 2011 11:37:41 +0100, RWMJ wrote:

 
 In general I like the auto-obsoleting feature in Bodhi, but is there a
 way to disable it for a particular update?
 
 The reason is that I've got libguestfs-1.10.1-1.fc15 waiting to go
 into stable.  I've also just built libguestfs-1.10.2-1.fc15 which is a
 further update along the upstream stable branch.
 
 If I submit this second update, it will auto-obsolete the first
 update.  However the first update is perfectly fine in itself, and
 more importantly it fixes a dependency problem.  If it gets obsoleted
 then users will have to wait another 3-4 days in order to get the
 dependency fix and won't be able to use the package at all during this
 time.  My only choice seems to be to not submit the second update at
 all, which means no one can test it, and the eventual release of it
 will be later than it needs to be.  I'd like to pipeline the
 updates.
 
 This is a general problem with auto-obsoleting if the period between
 releases  the period in updates-testing (which is the case in
 libguestfs because of our quite rapid release schedule).  In the past
 I've had chains of updates causing delays to get *any* package out of
 3-4 weeks.

It sounds as if bodhi would need to stop obsoleting an update that
is pending - stable, so you could submit the next test-update a little
bit earlier.Current behaviour (I think) is that bodhi obsoletes
updates until one is pushed to stable. 
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: Possible to submit an update without obsoleting?

2011-04-24 Thread Kevin Kofler
Michael Schwendt wrote:
 It sounds as if bodhi would need to stop obsoleting an update that
 is pending - stable, so you could submit the next test-update a little
 bit earlier.Current behaviour (I think) is that bodhi obsoletes
 updates until one is pushed to stable.

Bodhi actually doesn't obsolete an update that's queued for stable.

There's only a problem when you can't queue the previous update for stable 
yet because of those darn minimum testing requirements.

Kevin Kofler

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Driving ARM secondary rebuild with script - builddep tree?

2011-04-24 Thread Martin Langhoff
While smarter people than me fix the boostrapping of F14 on ARM, I am
looking at whether we can automate driving koji in an optimal order.

I am looking at mass-rebuild.py from the releng scripts repo; and at
yum-builddep.

 - mass-rebuild gets a git checkout, bumps the rev, commits, pushes,
we don't do that (!)

 - mass-rebuild counts on tags and on koji metadata indicating that a
pkg is blocked -- we don't do tags, and I don't know whether koji's
blocked metadata indicates a builddep check

 - if possible, we'd like to prioritize a particular set of packages
that is in the critical path for testing on our hw -- for that, I was
hoping to perform a recursive builddep tree, but it is... more complex
than it seems at first blush. Is there any tool that performs
recursive builddep checks, and defines an order (as yum does with deps
when planning an install?)

thanks!


m
-- 
 martin.langh...@gmail.com
 mar...@laptop.org -- Software Architect - OLPC
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: FC15 beta testing result by my 76-year old uncle

2011-04-24 Thread Marius Andreiana
Hi Andy


 Cheese/skype, but not image


 * logitech quickcam express doesn't work -- light goes on in
 I don't know about it specifically, but when I use my USB microscope I use
 Camorama.  Notice though it has no UI to select device, you have to give a
 switch --device=/dev/video1 on commandline if it's not the first video
 device.  It also might be worth a try.

Found this 1 year old kernel bug, it affects several cameras
https://bugzilla.redhat.com/show_bug.cgi?id=564597
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Driving ARM secondary rebuild with script - builddep tree?

2011-04-24 Thread Nathanael D. Noblet
On 04/24/2011 08:56 AM, Martin Langhoff wrote:
 While smarter people than me fix the boostrapping of F14 on ARM, I am
 looking at whether we can automate driving koji in an optimal order.

 I am looking at mass-rebuild.py from the releng scripts repo; and at
 yum-builddep.

   - mass-rebuild gets a git checkout, bumps the rev, commits, pushes,
 we don't do that (!)

   - mass-rebuild counts on tags and on koji metadata indicating that a
 pkg is blocked -- we don't do tags, and I don't know whether koji's
 blocked metadata indicates a builddep check

   - if possible, we'd like to prioritize a particular set of packages
 that is in the critical path for testing on our hw -- for that, I was
 hoping to perform a recursive builddep tree, but it is... more complex
 than it seems at first blush. Is there any tool that performs
 recursive builddep checks, and defines an order (as yum does with deps
 when planning an install?)

Not sure if it'll do the ordering the way you want - however look at 
smock.pl... It works well for me to build a set of RPMS where one 
depends on the other. I made two modifications to the original smock.pl 
I found online, one allows for multiple arch builds independently, the 
other uses threads to build each arch independently. My personal testing 
using time had the build finish ~50% faster when using threads. (3-4min 
vs 7min). I provided upstream with the patches but I'm not sure if they 
were applied or not. Either way not sure if it will solve your problem. 
If it does and you need/want the threaded patches let me know.


-- 
Nathanael d. Noblet
t 403.875.4613
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: wireless-tools/net-tools are DEPRECATED

2011-04-24 Thread Ben Boeckel
Chris Adams cmad...@hiwaay.net wrote:
 Once upon a time, Kevin Kofler kevin.kof...@chello.at said:
 Newsflash: the network service is DEPRECATED!!! That's what NetworkManager 
 is for.
 
 Newsflash: NM doesn't replace the network service yet.  Maybe when NM
 can do everything ifup/ifdown can do, the discussion about deprecation
 can happen, but until then, please stop saying NM replaces the network
 service.

One thing I liked a lot with my ifconfig scripts/wpa_supplicant pairing
is that when wireless is spotty, the network doesn't keep going up and
down. Instead, applications see lots of dropped packets. When
reauthentication can take 5 to 10s (or more), assuming that the
connection is steady when its just spotty can result in better behavior.
Also nice when quickly swapping ethernet cables. A network is gone
event gets different reactions from applications (particularly those
that are NM-aware which makes those applications MUCH more annoying to
deal with in these cases) than some packets were lost. An option to
persist connections despite something probably not actually existing
would be nice for situations like this.

--Ben

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: wireless-tools/net-tools are DEPRECATED

2011-04-24 Thread Kevin Kofler
Ben Boeckel wrote:
 One thing I liked a lot with my ifconfig scripts/wpa_supplicant pairing
 is that when wireless is spotty, the network doesn't keep going up and
 down. Instead, applications see lots of dropped packets. When
 reauthentication can take 5 to 10s (or more), assuming that the
 connection is steady when its just spotty can result in better behavior.
 Also nice when quickly swapping ethernet cables. A network is gone
 event gets different reactions from applications (particularly those
 that are NM-aware which makes those applications MUCH more annoying to
 deal with in these cases) than some packets were lost. An option to
 persist connections despite something probably not actually existing
 would be nice for situations like this.

I've found NM to actually be quite tolerant of spotty wireless connections. 
In fact, usually, it's me who triggers a reconnect (or if possible, a 
connect to a different access point, e.g. when I'm at the university in a 
shared building with the business university (WU), I try switching from 
eduroam to eduroam-wu when reception of my university's eduroam is poor), NM 
just happily stays connected even with 100% packet loss.

Kevin Kofler

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: wireless-tools/net-tools are DEPRECATED

2011-04-24 Thread Ben Boeckel
Kevin Kofler kevin.kof...@chello.at wrote:
 I've found NM to actually be quite tolerant of spotty wireless connections. 
 In fact, usually, it's me who triggers a reconnect (or if possible, a 
 connect to a different access point, e.g. when I'm at the university in a 
 shared building with the business university (WU), I try switching from 
 eduroam to eduroam-wu when reception of my university's eduroam is poor), NM 
 just happily stays connected even with 100% packet loss.

Ah, that's different than when I last used NM on my laptop due to these
issues (F13 beta-ish timeframe).

--Ben

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


PackageKit in Fedora 15 (beta)

2011-04-24 Thread Ilyes Gouta
Hi,

Removing PackageKit In Fedora 14 was easy and painless since it causes up to
5 packages, all *really* related to PackageKit in the form of a yum-plugin
and few other things.

On Fedora 15, trying to yum remove PackageKit causes the system to attempt
removing up to 74 MB worth of software, including gdm, empathy, bluez and
gnome-shell  Which is pointless.

Is it *really* required to have PackageKit so deeply integrated and made an
essential package on the system. AFAIK, it's essentially a helper and a
front-end for yum, right?

Is it possible to recover Fedora 14's lightweight dependencies set, for
PackageKit?

Thanks,

-Ilyes
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: PackageKit in Fedora 15 (beta)

2011-04-24 Thread Reindl Harald


Am 24.04.2011 20:04, schrieb Ilyes Gouta:
 Hi,
 
 Removing PackageKit In Fedora 14 was easy and painless since it causes up to 
 5 packages, all *really* related to
 PackageKit in the form of a yum-plugin and few other things.
 
 On Fedora 15, trying to yum remove PackageKit causes the system to attempt 
 removing up to 74 MB worth of
 software, including gdm, empathy, bluez and gnome-shell  Which is 
 pointless.
 
 Is it *really* required to have PackageKit so deeply integrated and made an 
 essential package on the system. AFAIK,
 it's essentially a helper and a front-end for yum, right?
 
 Is it possible to recover Fedora 14's lightweight dependencies set, for 
 PackageKit?
 
 Thanks,
 -Ilyes

generellay the dependecies are getting bigger with every release
it should be possible to install a leightweigt system

yes, hard-disk are getting cheaper but time!
on the other hand running 20-30 Fedora VMs on a SAN-Storage
disk space is not so cheap as at home and the overhead multiplies

means: i like to remove everything that is not active used because
distupgrades and normal updates are much bigger and especially on
servers everything which is not installed is not vulnerable



signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: PackageKit in Fedora 15 (beta)

2011-04-24 Thread Ilyes Gouta
Hi,

I filed a bug: https://bugzilla.redhat.com/show_bug.cgi?id=699263

https://bugzilla.redhat.com/show_bug.cgi?id=699263-Ilyes

On Sun, Apr 24, 2011 at 7:12 PM, Reindl Harald h.rei...@thelounge.netwrote:



 Am 24.04.2011 20:04, schrieb Ilyes Gouta:
  Hi,
 
  Removing PackageKit In Fedora 14 was easy and painless since it causes up
 to 5 packages, all *really* related to
  PackageKit in the form of a yum-plugin and few other things.
 
  On Fedora 15, trying to yum remove PackageKit causes the system to
 attempt removing up to 74 MB worth of
  software, including gdm, empathy, bluez and gnome-shell  Which is
 pointless.
 
  Is it *really* required to have PackageKit so deeply integrated and made
 an essential package on the system. AFAIK,
  it's essentially a helper and a front-end for yum, right?
 
  Is it possible to recover Fedora 14's lightweight dependencies set, for
 PackageKit?
 
  Thanks,
  -Ilyes

 generellay the dependecies are getting bigger with every release
 it should be possible to install a leightweigt system

 yes, hard-disk are getting cheaper but time!
 on the other hand running 20-30 Fedora VMs on a SAN-Storage
 disk space is not so cheap as at home and the overhead multiplies

 means: i like to remove everything that is not active used because
 distupgrades and normal updates are much bigger and especially on
 servers everything which is not installed is not vulnerable


 --
 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: PackageKit in Fedora 15 (beta)

2011-04-24 Thread Richard Hughes
On 24 April 2011 19:24, Ilyes Gouta ilyes.go...@gmail.com wrote:
 I filed a bug: https://bugzilla.redhat.com/show_bug.cgi?id=699263

I've commented on this, and closed it NOTABUG. Sorry.

Richard
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: wireless-tools/net-tools are DEPRECATED

2011-04-24 Thread Rahul Sundaram
On 04/24/2011 10:43 PM, Ben Boeckel wrote:
 Kevin Kofler kevin.kof...@chello.at wrote:
 I've found NM to actually be quite tolerant of spotty wireless connections. 
 In fact, usually, it's me who triggers a reconnect (or if possible, a 
 connect to a different access point, e.g. when I'm at the university in a 
 shared building with the business university (WU), I try switching from 
 eduroam to eduroam-wu when reception of my university's eduroam is poor), NM 
 just happily stays connected even with 100% packet loss.
 Ah, that's different than when I last used NM on my laptop due to these
 issues (F13 beta-ish timeframe)

It isn't useful to talk about NM from that time period anymore.  There
has been major rewrites of it and current NM is not even comparable
really.  Try the latest and then offer comments. 

Rahul

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: PackageKit in Fedora 15 (beta)

2011-04-24 Thread Rahul Sundaram
On 04/24/2011 11:54 PM, Ilyes Gouta wrote:
 Hi,

 I filed a bug:  https://bugzilla.redhat.com/show_bug.cgi?id=699263

 -Ilyes

PackageKit isn't just a yum frontend and is likely to be integrated more
and more with key components as we go forward.  If you aren't actively
using the GNOME or KDE frontend, just remove those and leave the
framework as it is. 

Rahul
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: PackageKit in Fedora 15 (beta)

2011-04-24 Thread Rahul Sundaram
On 04/25/2011 12:36 AM, Ilyes Gouta wrote:
 Rahul,

  If you aren't actively using the GNOME or KDE frontend, just remove
 those and leave the
  framework as it is.

 That was tough :)

 AFAIK (and I might be wrong) deep PacakgeKit integration wasn't
 clearly mentioned in Fedora 15's feature set list.

It isn't a feature that is driven by Fedora and hence it won't be in the
feature list.  It is just what happens when more upstream software take
advantage of it over time.. 


 I was just asking if it was possible to recover to a situation where
 the user would still have the choice, to use or not use PackageKit.
 That's all. Fedora 14 gave that choice.

 Alright, thanks for explaining!

Just leave it installed.  You don't have to use it.  That is still a
choice. 

Rahul

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: PackageKit in Fedora 15 (beta)

2011-04-24 Thread Ilyes Gouta
Hi Rahul,

 It isn't a feature that is driven by Fedora and hence it won't be in the
 feature list.  It is just what happens when more upstream software take
 advantage of it over time..

Yes, NOW it's clear! Thanks Rahul!

-Ilyes

On Sun, Apr 24, 2011 at 8:16 PM, Rahul Sundaram methe...@gmail.com wrote:

 On 04/25/2011 12:36 AM, Ilyes Gouta wrote:
  Rahul,
 
   If you aren't actively using the GNOME or KDE frontend, just remove
  those and leave the
   framework as it is.
 
  That was tough :)
 
  AFAIK (and I might be wrong) deep PacakgeKit integration wasn't
  clearly mentioned in Fedora 15's feature set list.

 It isn't a feature that is driven by Fedora and hence it won't be in the
 feature list.  It is just what happens when more upstream software take
 advantage of it over time..

 
  I was just asking if it was possible to recover to a situation where
  the user would still have the choice, to use or not use PackageKit.
  That's all. Fedora 14 gave that choice.
 
  Alright, thanks for explaining!

 Just leave it installed.  You don't have to use it.  That is still a
 choice.

 Rahul

 --
 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: Possible to submit an update without obsoleting?

2011-04-24 Thread Richard W.M. Jones
On Sun, Apr 24, 2011 at 03:57:00PM +0200, Kevin Kofler wrote:
 Michael Schwendt wrote:
  It sounds as if bodhi would need to stop obsoleting an update that
  is pending - stable, so you could submit the next test-update a little
  bit earlier.Current behaviour (I think) is that bodhi obsoletes
  updates until one is pushed to stable.
 
 Bodhi actually doesn't obsolete an update that's queued for stable.

OK, good to know.  I'm about to submit an update based on this
knowledge ...

 There's only a problem when you can't queue the previous update for
 stable yet because of those darn minimum testing requirements.

... however as you say there are deeper problems here like the
arbitrary testing period (which is stupid) and the fact that we can't
pipeline updates.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into Xen guests.
http://et.redhat.com/~rjones/virt-p2v
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: wireless-tools/net-tools are DEPRECATED

2011-04-24 Thread Tomasz Torcz
On Sun, Apr 24, 2011 at 07:10:48PM +0200, Kevin Kofler wrote:
 Ben Boeckel wrote:
  One thing I liked a lot with my ifconfig scripts/wpa_supplicant pairing
  is that when wireless is spotty, the network doesn't keep going up and
  down. Instead, applications see lots of dropped packets. When
  reauthentication can take 5 to 10s (or more), assuming that the
  connection is steady when its just spotty can result in better behavior.
  Also nice when quickly swapping ethernet cables. A network is gone
  event gets different reactions from applications (particularly those
  that are NM-aware which makes those applications MUCH more annoying to
  deal with in these cases) than some packets were lost. An option to
  persist connections despite something probably not actually existing
  would be nice for situations like this.
 
 I've found NM to actually be quite tolerant of spotty wireless connections. 
 In fact, usually, it's me who triggers a reconnect (or if possible, a 
 connect to a different access point, e.g. when I'm at the university in a 
 shared building with the business university (WU), I try switching from 
 eduroam to eduroam-wu when reception of my university's eduroam is poor), NM 
 just happily stays connected even with 100% packet loss.

  Well, I have opposite experience with my wired connection.  It takes only
about 5 flip-flop (carrier on/carrier off) in 10 seconds for NM to consider
connection down.

-- 
Tomasz Torcz God, root, what's the difference?
xmpp: zdzich...@chrome.pl God is more forgiving.

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


F-15 Branched report: 20110424 changes

2011-04-24 Thread Branched Report
Compose started at Sun Apr 24 13:16:25 UTC 2011

Broken deps for x86_64
--
collectd-mysql-4.10.2-2.fc15.x86_64 requires 
libmysqlclient.so.16()(64bit)
collectd-mysql-4.10.2-2.fc15.x86_64 requires 
libmysqlclient.so.16(libmysqlclient_16)(64bit)
cpm-0.23-0.3.beta.fc12.x86_64 requires libdotconf-1.0.so.0()(64bit)
db4o-7.4-2.fc13.x86_64 requires mono(Mono.GetOptions) = 0:2.0.0.0
dbmail-3.0.0-0.3.rc1.fc15.x86_64 requires libevent-1.4.so.2()(64bit)
dbmail-auth-ldap-3.0.0-0.3.rc1.fc15.x86_64 requires 
libevent-1.4.so.2()(64bit)
dh-make-0.55-3.fc15.noarch requires debhelper
eog-plugins-2.91.90-1.fc15.x86_64 requires 
libchamplain-gtk-0.10.so.0()(64bit)
eog-plugins-2.91.90-1.fc15.x86_64 requires 
libchamplain-0.10.so.0()(64bit)
1:fife-0.3.2-1.fc15.i686 requires libboost_regex.so.1.44.0
1:fife-0.3.2-1.fc15.i686 requires libboost_system.so.1.44.0
1:fife-0.3.2-1.fc15.i686 requires libboost_filesystem.so.1.44.0
1:fife-0.3.2-1.fc15.x86_64 requires libboost_regex.so.1.44.0()(64bit)
1:fife-0.3.2-1.fc15.x86_64 requires libboost_system.so.1.44.0()(64bit)
1:fife-0.3.2-1.fc15.x86_64 requires 
libboost_filesystem.so.1.44.0()(64bit)
file-browser-applet-0.6.6-1.fc15.x86_64 requires 
libpanel-applet-2.so.0()(64bit)
gcstar-1.6.1-3.fc15.noarch requires perl(Gtk2::ScrolledWindow)
gcstar-1.6.1-3.fc15.noarch requires perl(Gtk2::Dialog)
gcstar-1.6.1-3.fc15.noarch requires perl(Gtk2::Toolbar)
gcstar-1.6.1-3.fc15.noarch requires perl(Gtk2::TreeView)
gcstar-1.6.1-3.fc15.noarch requires perl(Gtk2::MenuBar)
gcstar-1.6.1-3.fc15.noarch requires perl(Gtk2::VBox)
gcstar-1.6.1-3.fc15.noarch requires perl(Gtk2::Window)
gcstar-1.6.1-3.fc15.noarch requires perl(Gtk2::MessageDialog)
glunarclock-0.34.1-1.fc14.x86_64 requires 
libpanel-applet-2.so.0()(64bit)
gnome-applet-bubblemon-2.0.15-1.fc13.x86_64 requires 
libpanel-applet-2.so.0()(64bit)
gnome-applet-cpufire-1.6-3.fc14.x86_64 requires 
libpanel-applet-2.so.0()(64bit)
gnome-applet-globalmenu-0.7.9-1.fc15.x86_64 requires 
libpanel-applet-2.so.0()(64bit)
gnome-applet-grandr-0.4.1-2.fc12.x86_64 requires 
libpanel-applet-2.so.0()(64bit)
gnome-applet-music-2.5.1-5.fc15.x86_64 requires 
libpanel-applet-2.so.0()(64bit)
gnome-applet-sensors-2.2.7-4.fc15.i686 requires libpanel-applet-2.so.0
gnome-applet-sensors-2.2.7-4.fc15.x86_64 requires 
libpanel-applet-2.so.0()(64bit)
gnome-applet-sshmenu-3.18-3.fc15.noarch requires ruby(panelapplet2)
gnome-applet-window-picker-0.5.8-2.fc14.x86_64 requires 
libpanel-applet-2.so.0()(64bit)
1:gnome-applets-2.32.0-3.fc15.x86_64 requires 
libpanel-applet-3.so.0()(64bit)
1:gnome-applets-2.32.0-3.fc15.x86_64 requires 
libpanel-applet-2.so.0()(64bit)
1:gnome-applets-2.32.0-3.fc15.x86_64 requires libgweather.so.1()(64bit)
gnome-netstatus-2.28.2-1.fc15.x86_64 requires 
libpanel-applet-2.so.0()(64bit)
gnome-pilot-conduits-2.32.1-2.fc15.x86_64 requires 
libgpilotd.so.5()(64bit)
gnome-pilot-conduits-2.32.1-2.fc15.x86_64 requires 
libgpilotdcm.so.4()(64bit)
gnome-pilot-conduits-2.32.1-2.fc15.x86_64 requires 
libgpilotdconduit.so.3()(64bit)
gnome-python2-applet-2.32.0-1.fc14.x86_64 requires 
libpanel-applet-2.so.0()(64bit)
gnome-python2-brasero-2.32.0-1.fc14.x86_64 requires 
libbrasero-media.so.1()(64bit)
gnome-python2-brasero-2.32.0-1.fc14.x86_64 requires 
libbrasero-burn.so.1()(64bit)
gnome-python2-evince-2.32.0-1.fc14.x86_64 requires 
libevview.so.3()(64bit)
gnome-python2-evince-2.32.0-1.fc14.x86_64 requires 
libevdocument.so.3()(64bit)
gnome-python2-evolution-2.32.0-1.fc14.x86_64 requires 
libcamel-1.2.so.19()(64bit)
gnome-python2-gdl-2.25.3-22.fc15.x86_64 requires libgdl-1.so.3()(64bit)
gnome-python2-totem-2.32.0-1.fc14.x86_64 requires 
libgnome-media-profiles.so.0()(64bit)
gnome-rdp-0.2.3-6.fc12.x86_64 requires mono(Mono.Data.SqliteClient) = 
0:2.0.0.0
gnome-themes-2.32.0-5.fc15.noarch requires gtk-theme-engine-clearlooks
gnomeradio-1.8-9.fc15.x86_64 requires libgtk-3.0.so.0()(64bit)
gnomeradio-1.8-9.fc15.x86_64 requires libgdk-3.0.so.0()(64bit)
gnotime-2.3.0-8.fc15.x86_64 requires libgtkhtml-3.15.so.19()(64bit)
gnubiff-2.2.13-4.fc15.x86_64 requires libpanel-applet-2.so.0()(64bit)
gnustep-back-0.18.0-4.fc14.x86_64 requires libobjc.so.2()(64bit)
gnustep-back-0.18.0-4.fc14.x86_64 requires 
libgnustep-base.so.1.20()(64bit)
gnustep-examples-1.3.0-4.fc15.x86_64 requires 
libgnustep-base.so.1.20()(64bit)
gnustep-examples-1.3.0-4.fc15.x86_64 requires libobjc.so.2()(64bit)
gnustep-gui-0.18.0-2.fc14.x86_64 requires 
libgnustep-base.so.1.20()(64bit)

[perl-String-Errf/f14/master] initial import (rhbz#678196)

2011-04-24 Thread Iain Arnell
Summary of changes:

  e374e59... initial import (rhbz#678196) (*)

(*) This commit already existed in another branch; no separate mail sent
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel


[perl-CPAN-Uploader/f14/master] (3 commits) ...update to 0.103000

2011-04-24 Thread Iain Arnell
Summary of changes:

  f0c22cb... - 661697 rebuild for fixing problems with vendorach/lib (*)
  a9a7f09... - Rebuilt for https://fedoraproject.org/wiki/Fedora_15_Mass (*)
  cc9588b... update to 0.103000 (*)

(*) This commit already existed in another branch; no separate mail sent
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel


[perl-DBIx-Class-Schema-Loader/f15/master] update to 0.07010

2011-04-24 Thread Iain Arnell
Summary of changes:

  60be66d... update to 0.07010 (*)

(*) This commit already existed in another branch; no separate mail sent
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel


File DateTime-TimeZone-1.33.tar.gz uploaded to lookaside cache by iarnell

2011-04-24 Thread Iain Arnell
A file has been added to the lookaside cache for perl-DateTime:

61eeb38b2a47041d03a197fff8dae1d9  DateTime-TimeZone-1.33.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel


[perl-DateTime] update DateTime::TimeZone to 1.33 (Olson 2011f)

2011-04-24 Thread Iain Arnell
commit b1ab4d26d27fa1bfb3df24a7d93e43fe3d07da71
Author: Iain Arnell iarn...@gmail.com
Date:   Sun Apr 24 11:15:03 2011 +0200

update DateTime::TimeZone to 1.33 (Olson 2011f)

 .gitignore |1 +
 perl-DateTime.spec |5 -
 sources|2 +-
 3 files changed, 6 insertions(+), 2 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index e98ce54..c30f860 100644
--- a/.gitignore
+++ b/.gitignore
@@ -8,3 +8,4 @@ DateTime-TimeZone-1.10.tar.gz
 /DateTime-TimeZone-1.26.tar.gz
 /DateTime-TimeZone-1.31.tar.gz
 /DateTime-TimeZone-1.32.tar.gz
+/DateTime-TimeZone-1.33.tar.gz
diff --git a/perl-DateTime.spec b/perl-DateTime.spec
index e35a32b..64d7256 100644
--- a/perl-DateTime.spec
+++ b/perl-DateTime.spec
@@ -1,6 +1,6 @@
 %define DT_version 0.66
 %define DTLocale_version 0.45
-%define DTTimeZone_version 1.32
+%define DTTimeZone_version 1.33
 
 Name:   perl-DateTime
 # must now be 0.xx00 to preserve upgrade path:
@@ -150,6 +150,9 @@ rm -rf $RPM_BUILD_ROOT
 %{perl_vendorarch}/DateTime*.pm
 
 %changelog
+* Sun Apr 24 2011 Iain Arnell iarn...@gmail.com 1:0.6600-4
+- update DateTime::TimeZone to 1.33 (Olson 2011f)
+
 * Wed Apr 06 2011 Iain Arnell iarn...@gmail.com 1:0.6600-4
 - update DateTime::TimeZone to 1.32 (Olson 2011e)
 
diff --git a/sources b/sources
index 6c558a4..3bc8218 100644
--- a/sources
+++ b/sources
@@ -1,3 +1,3 @@
 9399b5b430da65ac0b9056c0182a805b  DateTime-0.66.tar.gz
 8ba6a4b70f8fa7d987529c2e2c708862  DateTime-Locale-0.45.tar.gz
-0e6146dd3aa2e2a1d6f58fa23eae1de0  DateTime-TimeZone-1.32.tar.gz
+61eeb38b2a47041d03a197fff8dae1d9  DateTime-TimeZone-1.33.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel


[perl-DateTime] bump release too!

2011-04-24 Thread Iain Arnell
commit d77766f2e97a2af6bc1d6ed951bed0fdbfdf0d37
Author: Iain Arnell iarn...@gmail.com
Date:   Sun Apr 24 11:27:27 2011 +0200

bump release too!

 perl-DateTime.spec |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)
---
diff --git a/perl-DateTime.spec b/perl-DateTime.spec
index 64d7256..8ecdf42 100644
--- a/perl-DateTime.spec
+++ b/perl-DateTime.spec
@@ -5,7 +5,7 @@
 Name:   perl-DateTime
 # must now be 0.xx00 to preserve upgrade path:
 Version:%{DT_version}00
-Release:4%{?dist}
+Release:5%{?dist}
 Epoch:  1
 Summary:Date and time objects
 License:Artistic 2.0 and (GPL+ or Artistic)
@@ -150,7 +150,7 @@ rm -rf $RPM_BUILD_ROOT
 %{perl_vendorarch}/DateTime*.pm
 
 %changelog
-* Sun Apr 24 2011 Iain Arnell iarn...@gmail.com 1:0.6600-4
+* Sun Apr 24 2011 Iain Arnell iarn...@gmail.com 1:0.6600-5
 - update DateTime::TimeZone to 1.33 (Olson 2011f)
 
 * Wed Apr 06 2011 Iain Arnell iarn...@gmail.com 1:0.6600-4
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel


[perl-DateTime/f15/master] (2 commits) ...bump release too!

2011-04-24 Thread Iain Arnell
Summary of changes:

  b1ab4d2... update DateTime::TimeZone to 1.33 (Olson 2011f) (*)
  d77766f... bump release too! (*)

(*) This commit already existed in another branch; no separate mail sent
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel


[perl-DateTime/f14/master] (2 commits) ...bump release too!

2011-04-24 Thread Iain Arnell
Summary of changes:

  b1ab4d2... update DateTime::TimeZone to 1.33 (Olson 2011f) (*)
  d77766f... bump release too! (*)

(*) This commit already existed in another branch; no separate mail sent
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel


[perl-DateTime] fix the testing for loop

2011-04-24 Thread Iain Arnell
commit 1ac19c2a6abdce8671856f38c4a0bb2820c86590
Author: Iain Arnell iarn...@gmail.com
Date:   Sun Apr 24 11:39:29 2011 +0200

fix the testing for loop

 perl-DateTime.spec |7 +--
 1 files changed, 5 insertions(+), 2 deletions(-)
---
diff --git a/perl-DateTime.spec b/perl-DateTime.spec
index 8ecdf42..7e78a77 100644
--- a/perl-DateTime.spec
+++ b/perl-DateTime.spec
@@ -5,7 +5,7 @@
 Name:   perl-DateTime
 # must now be 0.xx00 to preserve upgrade path:
 Version:%{DT_version}00
-Release:5%{?dist}
+Release:6%{?dist}
 Epoch:  1
 Summary:Date and time objects
 License:Artistic 2.0 and (GPL+ or Artistic)
@@ -130,10 +130,10 @@ for d in DateTime-Locale-%{DTLocale_version} \
   cd $d
   ./Build test
   cd -
+done
 cd DateTime-TimeZone-%{DTTimeZone_version}
 make test
 cd -
-done
 
 %clean
 rm -rf $RPM_BUILD_ROOT
@@ -150,6 +150,9 @@ rm -rf $RPM_BUILD_ROOT
 %{perl_vendorarch}/DateTime*.pm
 
 %changelog
+* Sun Apr 24 2011 Iain Arnell iarn...@gmail.com 1:0.6600-6
+- fix the testing for loop
+
 * Sun Apr 24 2011 Iain Arnell iarn...@gmail.com 1:0.6600-5
 - update DateTime::TimeZone to 1.33 (Olson 2011f)
 
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel


[perl-DateTime/f15/master] fix the testing for loop

2011-04-24 Thread Iain Arnell
Summary of changes:

  1ac19c2... fix the testing for loop (*)

(*) This commit already existed in another branch; no separate mail sent
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel


[perl-DateTime/f14/master] fix the testing for loop

2011-04-24 Thread Iain Arnell
Summary of changes:

  1ac19c2... fix the testing for loop (*)

(*) This commit already existed in another branch; no separate mail sent
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel


[perl-DateTime/f13/master] update DateTime::TimeZone to 1.33

2011-04-24 Thread Iain Arnell
commit 6ac56f0942488686756b14b48809982588ceb5c8
Author: Iain Arnell iarn...@gmail.com
Date:   Sun Apr 24 11:38:38 2011 +0200

update DateTime::TimeZone to 1.33

 perl-DateTime.spec |   34 --
 1 files changed, 24 insertions(+), 10 deletions(-)
---
diff --git a/perl-DateTime.spec b/perl-DateTime.spec
index b0db240..388f1fd 100644
--- a/perl-DateTime.spec
+++ b/perl-DateTime.spec
@@ -1,11 +1,11 @@
 %define DT_version 0.53
 %define DTLocale_version 0.44
-%define DTTimeZone_version 1.10
+%define DTTimeZone_version 1.33
 
 Name:   perl-DateTime
 # must now be 0.xx00 to preserve upgrade path:
 Version:%{DT_version}00
-Release:2%{?dist}
+Release:3%{?dist}
 Epoch:  1
 Summary:Date and time objects
 License:GPL+ or Artistic
@@ -16,6 +16,7 @@ Source1:
http://www.cpan.org/authors/id/D/DR/DROLSKY/DateTime-TimeZone-%{
 Source2:
http://www.cpan.org/authors/id/D/DR/DROLSKY/DateTime-Locale-%{DTLocale_version}.tar.gz
 BuildRoot:  %(mktemp -ud %{_tmppath}/%{name}-%{version}-%{release}-XX)
 BuildRequires:  perl(Class::ISA)
+BuildRequires:  perl(Class::Load)
 BuildRequires:  perl(Class::Singleton) = 1.03
 BuildRequires:  perl(ExtUtils::CBuilder)
 BuildRequires:  perl(File::Find::Rule)
@@ -30,6 +31,7 @@ BuildRequires:  perl(Test::More) = 0.34
 BuildRequires:  perl(Test::Output)
 BuildRequires:  perl(Test::Pod) = 1.14
 BuildRequires:  perl(Test::Pod::Coverage) = 1.08
+BuildRequires:  perl(parent)
 Requires:   perl(Class::Singleton) = 1.03
 Requires:   perl(Params::Validate) = 0.91
 Requires:   perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo 
$version))
@@ -50,7 +52,7 @@ DateTime is a class for the representation of date/time 
combinations, and
 is part of the Perl DateTime project. For details on this project please
 see http://datetime.perl.org/. The DateTime site has a FAQ which may help
 answer many how do I do X? questions. The FAQ is at
-http://datetime.perl.org/?FAQ.
+http://datetime.perl.org/wiki/datetime/page/FAQ
 
 %prep
 %setup -q -T -c -n DateTimeBundle -a 0
@@ -58,8 +60,12 @@ http://datetime.perl.org/?FAQ.
 %setup -q -T -D -n DateTimeBundle -a 2
 
 (
-f=DateTime-%{DT_version}/lib/DateTime/LeapSecond.pm
+for f in \
+  DateTime-%{DT_version}/lib/DateTime/LeapSecond.pm \
+  DateTime-Locale-%{DTLocale_version}/Changes
+do
 iconv -f iso-8859-1 -t utf-8 $f  $f.utf8  mv $f.utf8 $f
+done
 )
 
 %build
@@ -69,8 +75,8 @@ cd DateTime-Locale-%{DTLocale_version}
 cd -
 
 cd DateTime-TimeZone-%{DTTimeZone_version}
-%{__perl} Build.PL installdirs=vendor
-./Build
+%{__perl} Makefile.PL installdirs=vendor
+make %{?_smp_mflags}
 cd -
 
 cd DateTime-%{DT_version}
@@ -85,14 +91,17 @@ cd -
 rm -rf $RPM_BUILD_ROOT
 
 for d in DateTime-Locale-%{DTLocale_version} \
-DateTime-TimeZone-%{DTTimeZone_version} \
-DateTime-%{DT_version}; do
+ DateTime-%{DT_version}; do
   cd $d
   ./Build install destdir=$RPM_BUILD_ROOT create_packlist=0
   cd -
 done
+cd DateTime-TimeZone-%{DTTimeZone_version}
+make pure_install DESTDIR=%{buildroot}
+cd -
 
 find $RPM_BUILD_ROOT -type f -name '*.bs' -size 0 -exec rm -f {} \;
+find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
 find $RPM_BUILD_ROOT -depth -type d -empty -exec rmdir {} \;
 
 %{_fixperms} $RPM_BUILD_ROOT/*
@@ -117,12 +126,14 @@ IS_MAINTAINER=1
 export IS_MAINTAINER
 
 for d in DateTime-Locale-%{DTLocale_version} \
-DateTime-TimeZone-%{DTTimeZone_version} \
-DateTime-%{DT_version}; do
+ DateTime-%{DT_version}; do
   cd $d
   ./Build test
   cd -
 done
+cd DateTime-TimeZone-%{DTTimeZone_version}
+make test
+cd -
 
 %clean
 rm -rf $RPM_BUILD_ROOT
@@ -139,6 +150,9 @@ rm -rf $RPM_BUILD_ROOT
 %{perl_vendorarch}/DateTime*.pm
 
 %changelog
+* Sun Apr 24 2011 Iain Arnell iarn...@gmail.com 1:0.5300-3
+- update DateTime::TimeZone to 1.33 (Olson 2011f)
+
 * Wed Jan 27 2010 Stepan Kasal ska...@redhat.com - 1:0.5300-2
 - new upstream version of DateTime-TimeZone
 
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel


[perl-DateTime/f13/master] upload DateTime-TimeZone-1.33 sources

2011-04-24 Thread Iain Arnell
commit 9dda884bfa9439f9b489bada609eb1a0226b6644
Author: Iain Arnell iarn...@gmail.com
Date:   Sun Apr 24 12:12:59 2011 +0200

upload DateTime-TimeZone-1.33 sources

 sources |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)
---
diff --git a/sources b/sources
index a02b024..247dd32 100644
--- a/sources
+++ b/sources
@@ -1,3 +1,3 @@
 bc2db48557d9520ad5095895daa1cb0b  DateTime-0.53.tar.gz
 f2e4ba9f2de67d2296c92da2e7c8b27d  DateTime-Locale-0.44.tar.gz
-bdc85c10d9958298e41e294e8e9ea85d  DateTime-TimeZone-1.10.tar.gz
+61eeb38b2a47041d03a197fff8dae1d9  DateTime-TimeZone-1.33.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


[Bug 699216] New: perl-Perl-Critic-Pulp-55 is available

2011-04-24 Thread bugzilla
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.

Summary: perl-Perl-Critic-Pulp-55 is available

https://bugzilla.redhat.com/show_bug.cgi?id=699216

   Summary: perl-Perl-Critic-Pulp-55 is available
   Product: Fedora
   Version: rawhide
  Platform: Unspecified
OS/Version: Unspecified
Status: NEW
  Keywords: FutureFeature, Triaged
  Severity: unspecified
  Priority: unspecified
 Component: perl-Perl-Critic-Pulp
AssignedTo: ppi...@redhat.com
ReportedBy: upstream-release-monitor...@fedoraproject.org
 QAContact: extras...@fedoraproject.org
CC: fedora-perl-devel-l...@redhat.com,
mmasl...@redhat.com, ppi...@redhat.com,
psab...@redhat.com
Classification: Fedora
  Story Points: ---


Latest upstream release: 55
Current version in Fedora Rawhide: 54
URL: http://search.cpan.org/dist/Perl-Critic-Pulp/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy

More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring

-- 
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 699220] New: perl-XML-Generator-1.03 is available

2011-04-24 Thread bugzilla
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.

Summary: perl-XML-Generator-1.03 is available

https://bugzilla.redhat.com/show_bug.cgi?id=699220

   Summary: perl-XML-Generator-1.03 is available
   Product: Fedora
   Version: rawhide
  Platform: Unspecified
OS/Version: Unspecified
Status: NEW
  Keywords: FutureFeature, Triaged
  Severity: unspecified
  Priority: unspecified
 Component: perl-XML-Generator
AssignedTo: psab...@redhat.com
ReportedBy: upstream-release-monitor...@fedoraproject.org
 QAContact: extras...@fedoraproject.org
CC: fedora-perl-devel-l...@redhat.com, psab...@redhat.com
Classification: Fedora
  Story Points: ---


Latest upstream release: 1.03
Current version in Fedora Rawhide: 1.01
URL: http://search.cpan.org/dist/XML-Generator/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy

More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring

-- 
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 699217] New: perl-threads-1.83 is available

2011-04-24 Thread bugzilla
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.

Summary: perl-threads-1.83 is available

https://bugzilla.redhat.com/show_bug.cgi?id=699217

   Summary: perl-threads-1.83 is available
   Product: Fedora
   Version: rawhide
  Platform: Unspecified
OS/Version: Unspecified
Status: NEW
  Keywords: FutureFeature, Triaged
  Severity: unspecified
  Priority: unspecified
 Component: perl-threads
AssignedTo: ppi...@redhat.com
ReportedBy: upstream-release-monitor...@fedoraproject.org
 QAContact: extras...@fedoraproject.org
CC: fedora-perl-devel-l...@redhat.com,
mmasl...@redhat.com, ppi...@redhat.com,
psab...@redhat.com
Classification: Fedora
  Story Points: ---


Latest upstream release: 1.83
Current version in Fedora Rawhide: 1.82
URL: http://search.cpan.org/dist/threads/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy

More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring

-- 
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 699218] New: perl-threads-shared-1.37 is available

2011-04-24 Thread bugzilla
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.

Summary: perl-threads-shared-1.37 is available

https://bugzilla.redhat.com/show_bug.cgi?id=699218

   Summary: perl-threads-shared-1.37 is available
   Product: Fedora
   Version: rawhide
  Platform: Unspecified
OS/Version: Unspecified
Status: NEW
  Keywords: FutureFeature, Triaged
  Severity: unspecified
  Priority: unspecified
 Component: perl-threads-shared
AssignedTo: ppi...@redhat.com
ReportedBy: upstream-release-monitor...@fedoraproject.org
 QAContact: extras...@fedoraproject.org
CC: fedora-perl-devel-l...@redhat.com,
mmasl...@redhat.com, ppi...@redhat.com,
psab...@redhat.com
Classification: Fedora
  Story Points: ---


Latest upstream release: 1.37
Current version in Fedora Rawhide: 1.36
URL: http://search.cpan.org/dist/threads-shared/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy

More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring

-- 
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 699219] New: perl-WWW-Mechanize-1.68 is available

2011-04-24 Thread bugzilla
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.

Summary: perl-WWW-Mechanize-1.68 is available

https://bugzilla.redhat.com/show_bug.cgi?id=699219

   Summary: perl-WWW-Mechanize-1.68 is available
   Product: Fedora
   Version: rawhide
  Platform: Unspecified
OS/Version: Unspecified
Status: NEW
  Keywords: FutureFeature, Triaged
  Severity: unspecified
  Priority: unspecified
 Component: perl-WWW-Mechanize
AssignedTo: cw...@alumni.drew.edu
ReportedBy: upstream-release-monitor...@fedoraproject.org
 QAContact: extras...@fedoraproject.org
CC: cw...@alumni.drew.edu,
fedora-perl-devel-l...@redhat.com
Classification: Fedora
  Story Points: ---


Latest upstream release: 1.68
Current version in Fedora Rawhide: 1.66
URL: http://search.cpan.org/dist/WWW-Mechanize/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy

More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring

-- 
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


[perl-HTML-Template/el6/master] fix failing test by adding missing BR, sync to rawhide

2011-04-24 Thread Tom Callaway
commit d793a6994b68f0166e3a203847ac33bfee4cee70
Author: Tom spot Callaway tcall...@redhat.com
Date:   Sun Apr 24 16:52:52 2011 -0400

fix failing test by adding missing BR, sync to rawhide

 perl-HTML-Template-manpages.patch |   75 +
 perl-HTML-Template.spec   |   22 ++-
 2 files changed, 96 insertions(+), 1 deletions(-)
---
diff --git a/perl-HTML-Template-manpages.patch 
b/perl-HTML-Template-manpages.patch
new file mode 100644
index 000..e8fed10
--- /dev/null
+++ b/perl-HTML-Template-manpages.patch
@@ -0,0 +1,75 @@
+diff -up HTML-Template-2.9/Template.pm.old HTML-Template-2.9/Template.pm
+--- HTML-Template-2.9/Template.pm.old  2007-01-29 20:32:21.0 +0100
 HTML-Template-2.9/Template.pm  2010-12-17 11:44:31.368712345 +0100
+@@ -14,7 +14,7 @@ extra tags, the simplest being TMPL_VAR
+ For example, test.tmpl:
+ 
+   html
+-  headtitleTest Template/title
++  headtitleTest Template/title/head
+   body
+   My Home Directory is TMPL_VAR NAME=HOME
+   p
+@@ -271,7 +271,7 @@ available.  As a final attempt, the file
+ directly.  See below for more information on HTML_TEMPLATE_ROOT and
+ the path option to new().
+ 
+-As a protection against infinitly recursive includes, an arbitary
++As a protection against infinitely recursive includes, an arbitrary
+ limit of 10 levels deep is imposed.  You can alter this limit with the
+ max_includes option.  See the entry for the max_includes option
+ below for more details.
+@@ -715,7 +715,7 @@ the order they appear:
+ The old associateCGI() call is still supported, but should be
+ considered obsolete.
+ 
+-NOTE: The parameter names are matched in a case-insensitve manner.  If
++NOTE: The parameter names are matched in a case-insensitive manner.  If
+ you have two parameters in a CGI object like 'NAME' and 'Name' one
+ will be chosen randomly by associate.  This behavior can be changed by
+ the following option.
+@@ -852,7 +852,7 @@ HTML::Template reads your template file 
+ template tags.
+ 
+ In the most simple usage, you simply assign a code reference to the
+-filter parameter.  This subroutine will recieve a single argument - a
++filter parameter.  This subroutine will receive a single argument - a
+ reference to a string containing the template file text.  Here is an
+ example that accepts templates with tags that look like !!!ZAP_VAR
+ FOO!!! and transforms them into HTML::Template tags:
+@@ -867,7 +867,7 @@ FOO!!! and transforms them into HTML::T
+   filter = $filter);
+ 
+ More complicated usages are possible.  You can request that your
+-filter receieve the template text as an array of lines rather than as
++filter receive the template text as an array of lines rather than as
+ a single scalar.  To do that you need to specify your filter using a
+ hash-ref.  In this form you specify the filter using the Csub key and
+ the desired argument format using the Cformat key.  The available
+@@ -902,7 +902,7 @@ unless they declare a different escape i
+ 
+ =back
+ 
+-=back 4
++=back
+ 
+ =cut
+ 
+@@ -2428,7 +2428,7 @@ Cparam() can be called in a number of 
+   $self-param(PARAM = 'value');
+ 
+   # with a subroutine reference that gets called to get the value
+-  # of the scalar.  The sub will recieve the template object as a
++  # of the scalar.  The sub will receive the template object as a
+   # parameter.
+   $self-param(PARAM = sub { return 'value' });   
+ 
+@@ -3263,7 +3263,7 @@ Q: How can I execute a program from insi
+ 
+ A: Short answer: you can't.  Longer answer: you shouldn't since this
+ violates the fundamental concept behind HTML::Template - that design
+-and code should be seperate.
++and code should be separate.
+ 
+ But, inevitably some people still want to do it.  If that describes
+ you then you should take a look at
diff --git a/perl-HTML-Template.spec b/perl-HTML-Template.spec
index a37f273..616dd15 100644
--- a/perl-HTML-Template.spec
+++ b/perl-HTML-Template.spec
@@ -1,15 +1,17 @@
 Name:   perl-HTML-Template
 Version:2.9
-Release:5%{?dist}
+Release:10%{?dist}
 Summary:Perl module to use HTML Templates
 
 Group:  Development/Libraries
 License:GPL+ or Artistic
 URL:http://search.cpan.org/dist/HTML-Template/
 Source0:
http://www.cpan.org/authors/id/S/SA/SAMTREGAR/HTML-Template-%{version}.tar.gz
+Patch0: perl-HTML-Template-manpages.patch
 BuildRoot:  %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
 
 BuildArch:  noarch
+BuildRequires:  perl(CGI)
 BuildRequires:  perl(Test::More)
 BuildRequires:  perl(ExtUtils::MakeMaker)
 BuildRequires:  perl(IPC::SharedCache)
@@ -29,6 +31,7 @@ in the Perl script.
 
 %prep
 %setup -q -n HTML-Template-%{version}
+%patch0 -p1 -b .manpages
 %{__perl} -pi -e 's/\r//g' README
 
 
@@ -61,6 +64,23 @@ rm -rf $RPM_BUILD_ROOT
 
 
 %changelog
+* Sun Apr 24 2011 Tom Callaway 

[perl-HTML-Template] fix failing test by adding missing BR, sync to rawhide

2011-04-24 Thread Tom Callaway
commit a70ae367e4ab60d9deae51e41616f76560961d18
Author: Tom spot Callaway tcall...@redhat.com
Date:   Sun Apr 24 16:59:52 2011 -0400

fix failing test by adding missing BR, sync to rawhide

 perl-HTML-Template.spec |6 +-
 1 files changed, 5 insertions(+), 1 deletions(-)
---
diff --git a/perl-HTML-Template.spec b/perl-HTML-Template.spec
index 0074e02..7944d29 100644
--- a/perl-HTML-Template.spec
+++ b/perl-HTML-Template.spec
@@ -1,6 +1,6 @@
 Name:   perl-HTML-Template
 Version:2.9
-Release:9%{?dist}
+Release:10%{?dist}
 Summary:Perl module to use HTML Templates
 
 Group:  Development/Libraries
@@ -30,6 +30,7 @@ in the Perl script.
 
 %prep
 %setup -q -n HTML-Template-%{version}
+%patch0 -p1 -b .manpages
 %{__perl} -pi -e 's/\r//g' README
 
 
@@ -62,6 +63,9 @@ rm -rf $RPM_BUILD_ROOT
 
 
 %changelog
+* Sun Apr 24 2011 Tom Callaway s...@fedoraproject.org - 2.9-10
+- actually apply man page fixes patch
+
 * Tue Feb 08 2011 Fedora Release Engineering rel-...@lists.fedoraproject.org 
- 2.9-9
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_15_Mass_Rebuild
 
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel


File Devel-EnforceEncapsulation-0.50.tgz uploaded to lookaside cache by pghmcfc

2011-04-24 Thread Paul Howarth
A file has been added to the lookaside cache for 
perl-Devel-EnforceEncapsulation:

434b5a9e99e1153282076680c9de29c5  Devel-EnforceEncapsulation-0.50.tgz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel


[perl-Devel-EnforceEncapsulation] Initial import of perl-Devel-EnforceEncapsulation-0.50-3

2011-04-24 Thread Paul Howarth
commit a45f142b845aa5ec15a023254f7a48dbe37608f5
Author: Paul Howarth p...@city-fan.org
Date:   Sun Apr 24 22:10:41 2011 +0100

Initial import of perl-Devel-EnforceEncapsulation-0.50-3

Encapsulation is the practice of creating subroutines to access the 
properties
of a class instead of accessing those properties directly. The advantage of
good encapsulation is that the author is permitted to change the internal
implementation of a class without breaking its usage.

Object-oriented programming in Perl is most commonly implemented via blessed
hashes. This practice makes it easy for users of a class to violate
encapsulation by simply accessing the hash values directly. Although less
common, the same applies to classes implemented via blessed arrays, scalars,
filehandles, etc.

This module is a hack to block those direct accesses. If you try to access a
hash value of an object from its own class, or a superclass or subclass, all
goes well. If you try to access a hash value from any other package, an
exception is thrown. The same applies to the scalar value of a blessed 
scalar,
entry in a blessed array, etc.

To be clear: this class is NOT intended for strict enforcement of
encapsulation. If you want bullet-proof encapsulation, use inside-out 
objects
or the like. Instead, this module is intended to be a development or 
debugging
aid in catching places where direct access is used against classes 
implemented
as blessed hashes.

To repeat: the encapsulation enforced here is a hack and is easily
circumvented. Please use this module for good (finding bugs), not evil 
(making
life harder for downstream developers).

 .gitignore   |1 +
 perl-Devel-EnforceEncapsulation.spec |   74 ++
 sources  |1 +
 3 files changed, 76 insertions(+), 0 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index e69de29..28302f8 100644
--- a/.gitignore
+++ b/.gitignore
@@ -0,0 +1 @@
+/Devel-EnforceEncapsulation-0.50.tgz
diff --git a/perl-Devel-EnforceEncapsulation.spec 
b/perl-Devel-EnforceEncapsulation.spec
new file mode 100644
index 000..679735c
--- /dev/null
+++ b/perl-Devel-EnforceEncapsulation.spec
@@ -0,0 +1,74 @@
+Name:  perl-Devel-EnforceEncapsulation
+Version:   0.50
+Release:   3%{?dist}
+Summary:   Find access violations to blessed objects
+Group: Development/Libraries
+License:   GPL+ or Artistic
+URL:   http://search.cpan.org/dist/Devel-EnforceEncapsulation/
+Source0:   
http://search.cpan.org/CPAN/authors/id/C/CL/CLOTHO/Devel-EnforceEncapsulation-%{version}.tgz
+BuildArch: noarch
+BuildRequires: perl(ExtUtils::MakeMaker)
+BuildRequires: perl(Test::More)
+BuildRequires: perl(Test::Pod)
+BuildRequires: perl(Test::Pod::Coverage)
+Requires:  perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
+
+%description
+Encapsulation is the practice of creating subroutines to access the properties
+of a class instead of accessing those properties directly. The advantage of
+good encapsulation is that the author is permitted to change the internal
+implementation of a class without breaking its usage.
+
+Object-oriented programming in Perl is most commonly implemented via blessed
+hashes. This practice makes it easy for users of a class to violate
+encapsulation by simply accessing the hash values directly. Although less
+common, the same applies to classes implemented via blessed arrays, scalars,
+filehandles, etc.
+
+This module is a hack to block those direct accesses. If you try to access a
+hash value of an object from its own class, or a superclass or subclass, all
+goes well. If you try to access a hash value from any other package, an
+exception is thrown. The same applies to the scalar value of a blessed scalar,
+entry in a blessed array, etc.
+
+To be clear: this class is NOT intended for strict enforcement of
+encapsulation. If you want bullet-proof encapsulation, use inside-out objects
+or the like. Instead, this module is intended to be a development or debugging
+aid in catching places where direct access is used against classes implemented
+as blessed hashes.
+
+To repeat: the encapsulation enforced here is a hack and is easily
+circumvented. Please use this module for good (finding bugs), not evil (making
+life harder for downstream developers).
+
+%prep
+%setup -q -n Devel-EnforceEncapsulation-%{version}
+
+%build
+perl Makefile.PL INSTALLDIRS=vendor
+make %{?_smp_mflags}
+
+%install
+make pure_install DESTDIR=%{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 AUTHOR_TEST=1 AUTHOR_TEST_CDOLAN=1
+
+%files
+%defattr(-,root,root,-)
+%doc CHANGES LICENSE README index.html
+%{perl_vendorlib}/Devel/

[perl-Devel-EnforceEncapsulation/f15/master] Initial import of perl-Devel-EnforceEncapsulation-0.50-3

2011-04-24 Thread Paul Howarth
Summary of changes:

  a45f142... Initial import of perl-Devel-EnforceEncapsulation-0.50-3 (*)

(*) This commit already existed in another branch; no separate mail sent
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel


[perl-Devel-EnforceEncapsulation/el6/master] Initial import of perl-Devel-EnforceEncapsulation-0.50-3

2011-04-24 Thread Paul Howarth
Summary of changes:

  a45f142... Initial import of perl-Devel-EnforceEncapsulation-0.50-3 (*)

(*) This commit already existed in another branch; no separate mail sent
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel


[perl-Devel-EnforceEncapsulation] Created tag perl-Devel-EnforceEncapsulation-0.50-3.el6

2011-04-24 Thread Paul Howarth
The lightweight tag 'perl-Devel-EnforceEncapsulation-0.50-3.el6' was created 
pointing to:

 a45f142... Initial import of perl-Devel-EnforceEncapsulation-0.50-3
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel


[perl-Devel-EnforceEncapsulation] Created tag perl-Devel-EnforceEncapsulation-0.50-3.fc15

2011-04-24 Thread Paul Howarth
The lightweight tag 'perl-Devel-EnforceEncapsulation-0.50-3.fc15' was created 
pointing to:

 a45f142... Initial import of perl-Devel-EnforceEncapsulation-0.50-3
--
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


Broken dependencies: perl-Math-Random-MT-Auto

2011-04-24 Thread buildsys


perl-Math-Random-MT-Auto has broken dependencies in the F-15 tree:
On x86_64:
perl-Math-Random-MT-Auto-6.16-2.fc15.x86_64 requires 
perl(Object::InsideOut) = 0:2.06
On i386:
perl-Math-Random-MT-Auto-6.16-2.fc15.i686 requires 
perl(Object::InsideOut) = 0:2.06
Please resolve this as soon as possible.


--
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