Re: PEAR not entirely in EPEL?

2012-07-13 Thread Jorge Gallegos
That explains it. Thanks a lot!

~kad (android'ed)
On Jul 12, 2012 10:31 PM, Remi Collet fed...@famillecollet.com wrote:

 Le 13/07/2012 07:22, Jorge Gallegos a écrit :
  Hello everyone,
 
  Am I reading this right? the main PEAR package is not in any EPEL
  version:
 
  https://admin.fedoraproject.org/pkgdb/acls/name/php-pear
 
  However some PEAR libraries *are* in EPEL, which confuses me a
  little bit. How come some libraries are there but not php-pear?

 php-pear is part of the main repository.

 version 1.4.9 on RHEL-5
 version 1.9.4 on RHEL-6

 remi
 
 
  Thanks in advance
 
 
 


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

2012-07-13 Thread Matthias Runge

On 07/12/2012 07:08 PM, Jitesh Shah wrote:

django-recaptcha
Looking deeper into upstream, I think, this package should be 
deprecated. I'd replace it with a django-recaptcha solutuion from

https://github.com/praekelt/django-recaptcha

gnome-rdp
libdwarf
tcptrack

Jitesh


Thank you for caring about those packages and your work for fedora!

--
Matthias Runge mru...@matthias-runge.de
   mru...@fedoraproject.org


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

Re: Updates: karma and timeouts

2012-07-13 Thread Jan Kratochvil
On Thu, 12 Jul 2012 15:09:05 +0200, Darryl L. Pierce wrote:
 I think if those packages are languishing, it's like
 the packager was already notified and chose not to push.

Package goes into testing with the goal to get into stable.  Therefore by
default it should go into stable when it gets approved for it.

There must be a specific reason one puts package into testing and later not
wanting to push it to stable.  If such reason appears one revokes the package
anyway.


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

Re: [HEADS-UP] Rawhide: /tmp is now on tmpfs

2012-07-13 Thread Roberto Ragusa
On 07/12/2012 09:54 PM, Harald Hoyer wrote:

 Again.. tmpfs is restricted to half the RAM size by default. You can't
 store 8-9GB of trash.. only 2GB, which might land on swap over time.

As I have already pointed out some time ago, isn't a bizarre situation
that as an application developer I can either use malloc() and store things
up to RAM+swap (lets' say 4+6=10GB) or use temporary files and store
things up to RAM/2 (lets' say 4/2=2GB)?

Once upon a time you used to use files to go *beyond* RAM limits.

And the answer to this objection is? move to /var/tmp.
So patch everything (and good luck with closed source stuff).

Wouldn't have been more reasonable to create a /ramtmp and patch
the applications? (this would have just been patched for speed, not
patched for correctness as the sort case).
Hey, wait, we already have /dev/shm. So we just had to patch
the applications (if anyone cares).


-- 
   Roberto Ragusamail at robertoragusa.it


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

Re: Orphaning packages

2012-07-13 Thread Tom Hughes

On 12/07/12 18:08, Jitesh Shah wrote:


libdwarf


I've taken this.

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/


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

Re: Orphaning packages

2012-07-13 Thread Matthias Runge

On 07/12/2012 07:08 PM, Jitesh Shah wrote:

django-recaptcha
gnome-rdp

In fact, these package have already been taken by somebody without
announcement here.
--
Matthias Runge mru...@matthias-runge.de
   mru...@fedoraproject.org


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

Re: Orphaning packages

2012-07-13 Thread Patrick Uiterwijk
I have taken tcptrack
Op 12 jul. 2012 19:08 schreef Jitesh Shah jitesh.1...@gmail.com het
volgende:

 django-recaptcha
 gnome-rdp
 libdwarf
 tcptrack

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

Set bash's shell option nullglob by default?

2012-07-13 Thread Roman Rakus

Hi,
I have a question about nullglob bash's shell option. I want to hear 
opinions.

The behavior is nicely described in bash reference manual [1]
By default, the nullglob is turned off. And it tends people to use bad 
habits in shell scripting.
In my POV the nullglob could be turned on by default. However, i would 
like to hear opinions from others.


It is possible it can break many scripts even in rpm's scriptlets, but 
as I already said, it's because bad habits. So the main gain will be the 
people will learn how is the globbing in bash and in the whole 
environment working.


RR

[1] http://www.gnu.org/software/bash/manual/bashref.html#Filename-Expansion

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

Re: Set bash's shell option nullglob by default?

2012-07-13 Thread Scott Schmit
On Fri, Jul 13, 2012 at 01:56:29PM +0200, Roman Rakus wrote:
 Hi,
 I have a question about nullglob bash's shell option. I want to hear
 opinions.
 The behavior is nicely described in bash reference manual [1]
 By default, the nullglob is turned off. And it tends people to use
 bad habits in shell scripting.
 In my POV the nullglob could be turned on by default. However, i
 would like to hear opinions from others.
 
 It is possible it can break many scripts even in rpm's scriptlets,
 but as I already said, it's because bad habits. So the main gain
 will be the people will learn how is the globbing in bash and in the
 whole environment working.

So ls *.foo should list the entire directory if no files match *.foo?
It's a bad habit for me to expect ls *.foo to return nothing in this
case? You're going to need to convince me.

-- 
Scott Schmit


smime.p7s
Description: S/MIME cryptographic signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Set bash's shell option nullglob by default?

2012-07-13 Thread Roman Rakus

On 07/13/2012 02:06 PM, Scott Schmit wrote:

So ls *.foo should list the entire directory if no files match *.foo?
It's a bad habit for me to expect ls *.foo to return nothing in this
case? You're going to need to convince me.
And if there are directories ending with .foo? Hopefully you are not 
using such things in scripts.

OK, in interactive shells `ls *' is not that wrong.

printf '%s\n' *.foo
for file in *.foo; do ... done

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

Re: Set bash's shell option nullglob by default?

2012-07-13 Thread Tomas Mraz
On Fri, 2012-07-13 at 13:56 +0200, Roman Rakus wrote: 
 Hi,
 I have a question about nullglob bash's shell option. I want to hear 
 opinions.
 The behavior is nicely described in bash reference manual [1]
 By default, the nullglob is turned off. And it tends people to use bad 
 habits in shell scripting.
 In my POV the nullglob could be turned on by default. However, i would 
 like to hear opinions from others.

This could cause serious surprising breakages of scripts with strange
consequences. I'm strictly against this change. If something at all
should be changed in this regard to break bad habits then it should be
the failglob option although I am not convinced that it is too good idea
either.
-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb

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

Re: Set bash's shell option nullglob by default?

2012-07-13 Thread Roman Rakus

On 07/13/2012 02:19 PM, Tomas Mraz wrote:

This could cause serious surprising breakages of scripts with strange
consequences. I'm strictly against this change. If something at all
should be changed in this regard to break bad habits then it should be
the failglob option although I am not convinced that it is too good idea
either.

I was thinking about failglob also, but it is not that useful like it looks.

for name in *; do ...; done

In the current state, if there isn't any file, the name variable will 
contain *.

With nullglob name will be empty and script continues after the for loop.
With failglob it will print error message. I think it is not useful.

But you are right, it will cause many breakages (even surprising).

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

Re: Orphaning packages

2012-07-13 Thread Luis Enrique Bazán De León
I take dejango-recaptcha and gnome-rdp, sorry answer to late

2012/7/13 Patrick Uiterwijk puiterw...@gmail.com

 I have taken tcptrack
 Op 12 jul. 2012 19:08 schreef Jitesh Shah jitesh.1...@gmail.com het
 volgende:

 django-recaptcha
 gnome-rdp
 libdwarf
 tcptrack

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




-- 
Luis Enrique Bazán De León
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Set bash's shell option nullglob by default?

2012-07-13 Thread Bryn M. Reeves
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/13/2012 01:06 PM, Scott Schmit wrote:
 On Fri, Jul 13, 2012 at 01:56:29PM +0200, Roman Rakus wrote:
 Hi, I have a question about nullglob bash's shell option. I want
 to hear opinions. The behavior is nicely described in bash
 reference manual [1] By default, the nullglob is turned off. And
 it tends people to use bad habits in shell scripting. In my POV
 the nullglob could be turned on by default. However, i would like
 to hear opinions from others.
 
 It is possible it can break many scripts even in rpm's
 scriptlets, but as I already said, it's because bad habits. So
 the main gain will be the people will learn how is the globbing
 in bash and in the whole environment working.
 
 So ls *.foo should list the entire directory if no files match
 *.foo? It's a bad habit for me to expect ls *.foo to return nothing
 in this case? You're going to need to convince me.

I wouldn't back this change either but that's not the behaviour of
nullglob. If nothing matches the glob the word remains unchanged (i.e.
*.foo - *.foo):

$ ls *.foo
ls: cannot access *.foo: No such file or directory

$ echo *.foo
*.foo

Regards,
Bryn.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlAAFTIACgkQ6YSQoMYUY956BgCgicpLdJr4nM7NBwYOSJS9kQVe
8qoAoJKEtqaWJ0SAbT2UXK7URkSaxXV+
=H6xC
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Set bash's shell option nullglob by default?

2012-07-13 Thread Bryn M. Reeves
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/13/2012 01:31 PM, Bryn M. Reeves wrote:
 I wouldn't back this change either but that's not the behaviour of 
 nullglob. If nothing matches the glob the word remains unchanged
 (i.e. *.foo - *.foo):

Eh, nevermind.. not enough coffee.

Bryn.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlAAFYMACgkQ6YSQoMYUY94DnACgkaZ3RgDOq98rMsVREgwYMBnG
fokAoI9qRfmYOpIv9wzq7u7VMCMCq1zv
=MTCR
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Updates: karma and timeouts

2012-07-13 Thread Darryl L. Pierce
On Fri, Jul 13, 2012 at 08:37:19AM +0200, Jan Kratochvil wrote:
 On Thu, 12 Jul 2012 15:09:05 +0200, Darryl L. Pierce wrote:
  I think if those packages are languishing, it's like
  the packager was already notified and chose not to push.
 
 Package goes into testing with the goal to get into stable.  Therefore by
 default it should go into stable when it gets approved for it.

But tacit approval is not the same as having been tested by third
parties and verified as working.
 
 There must be a specific reason one puts package into testing and later not
 wanting to push it to stable.  If such reason appears one revokes the package
 anyway.

And that reason mam be I want three people to test it and give it
karma and it's not happened yet. No reason to revoke the package, it
just has been tested by enough people in the packager's opinion.

-- 
Darryl L. Pierce mcpie...@gmail.com
http://mcpierce.multiply.com/
What do you care what people think, Mr. Feynman?


pgpQ2Oye7TM8P.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Set bash's shell option nullglob by default?

2012-07-13 Thread Björn Persson
Roman Rakus wrote:
 By default, the nullglob is turned off. And it tends people to use bad 
 habits in shell scripting.

What habits exactly, and why are those habits bad?

 In my POV the nullglob could be turned on by default. However, i would 
 like to hear opinions from others.

Changing a programming language under the programmers' feet it almost never a 
good idea. Shall I start setting all Bash options explicitly in every single 
shell script just so that I'll know how the language works even if someone 
changes the defaults on me?

Björn Persson


signature.asc
Description: This is a digitally signed message part.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

make distcheck is exploitable: get a fixed automake

2012-07-13 Thread Jim Meyering
If you run make distcheck (the rule generated by automake),
be sure that it is safe.  Until a few days ago, running that
rule in a directory readable by others would put you at risk
from a local attacker.  It can be exploited reliably.
It's fixed in the latest, automake-12.2

http://bugzilla.redhat.com/CVE-2012-3386
http://savannah.gnu.org/forum/forum.php?forum_id=7294

One work-around is to ensure that your build directory
is not readable by the potential attacker.  A more general
(but more onerous) approach is to use a restrictive umask,
e.g. by adding umask 077 to some shell start-up file.
But don't do that lightly, since there are still plenty of
tools that are unprepared for that.  Personally, I've had
a umask of 077 for the last few years because I'm rather
paranoid, but it has also caused trouble, and I've had to
learn when to invoke tools in a subshell like this

(umask 022; run some tool)

especially as root.

To see if you have a vulnerable Makefile.in file, run this:

find . -name Makefile.in|xargs grep chmod.a+w

it usually finds problems in the top-level Makefile.in.
If you see any matching line, say like this,

./Makefile.in:  chmod -R a-w $(distdir); chmod a+w $(distdir)

then that rule is vulnerable: install a patched automake
and/or just change a+w to u+w on that line.

Note that just installing a fixed automake is not enough.
You must also rerun it, in order to regenerate each offending
Makefile.in.  This means that if you ever unpack an old tarball
and run make distcheck using that, you may be vulnerable.

If you're about to make a release, be sure to regenerate your
Makefile.in files with a fixed automake before doing that so
that people who use your release tarball are not vulnerable.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Set bash's shell option nullglob by default?

2012-07-13 Thread David Levine
Roman wrote:

 It is possible it can break many scripts even in rpm's
 scriptlets, but as I already said, it's because bad
 habits. So the main gain will be the people will learn how
 is the globbing in bash and in the whole environment
 working.

Please don't.  If an author or maintainer wants to save
themself from bad habits, they can put shopt -s nullglob
near the top of their bash scripts.

Let's not break many, many existing scripts.

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

Re: [HEADS-UP] Rawhide: /tmp is now on tmpfs

2012-07-13 Thread Dennis Jacobfeuerborn
On 07/13/2012 09:14 AM, Roberto Ragusa wrote:
 On 07/12/2012 09:54 PM, Harald Hoyer wrote:
 
 Again.. tmpfs is restricted to half the RAM size by default. You can't
 store 8-9GB of trash.. only 2GB, which might land on swap over time.
 
 As I have already pointed out some time ago, isn't a bizarre situation
 that as an application developer I can either use malloc() and store things
 up to RAM+swap (lets' say 4+6=10GB) or use temporary files and store
 things up to RAM/2 (lets' say 4/2=2GB)?
 
 Once upon a time you used to use files to go *beyond* RAM limits.
 
 And the answer to this objection is? move to /var/tmp.
 So patch everything (and good luck with closed source stuff).

An application (closed source or not) that plans to store non-trivial
amounts of data somewhere should have a mechanism/config option to let the
user specify where to store that data. Simply hoping that you can dump X
gigabytes of data in some hard-coded place is not a good idea.

 Wouldn't have been more reasonable to create a /ramtmp and patch
 the applications? (this would have just been patched for speed, not
 patched for correctness as the sort case).
 Hey, wait, we already have /dev/shm. So we just had to patch
 the applications (if anyone cares).

That way *every* application would have to be patched. Using /var/tmp is
only required for a small number of apps that actually have more specific
needs regarding the data they intend to put there.
Indeed in many cases it might be better for an application to actually
manage the temporary-ness of the file(s) in question themselves and
store/manage them in /var/lib/app instead.

Regards,
  Dennis

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

Re: [HEADS-UP] Rawhide: /tmp is now on tmpfs

2012-07-13 Thread Brian Wheeler

On 07/13/2012 10:14 AM, Dennis Jacobfeuerborn wrote:

On 07/13/2012 09:14 AM, Roberto Ragusa wrote:

On 07/12/2012 09:54 PM, Harald Hoyer wrote:


Again.. tmpfs is restricted to half the RAM size by default. You can't
store 8-9GB of trash.. only 2GB, which might land on swap over time.

As I have already pointed out some time ago, isn't a bizarre situation
that as an application developer I can either use malloc() and store things
up to RAM+swap (lets' say 4+6=10GB) or use temporary files and store
things up to RAM/2 (lets' say 4/2=2GB)?

Once upon a time you used to use files to go *beyond* RAM limits.

And the answer to this objection is? move to /var/tmp.
So patch everything (and good luck with closed source stuff).

An application (closed source or not) that plans to store non-trivial
amounts of data somewhere should have a mechanism/config option to let the
user specify where to store that data. Simply hoping that you can dump X
gigabytes of data in some hard-coded place is not a good idea.


Sure, its not a good idea, but its been done for decades...successfully.


Wouldn't have been more reasonable to create a /ramtmp and patch
the applications? (this would have just been patched for speed, not
patched for correctness as the sort case).
Hey, wait, we already have /dev/shm. So we just had to patch
the applications (if anyone cares).

That way *every* application would have to be patched. Using /var/tmp is
only required for a small number of apps that actually have more specific
needs regarding the data they intend to put there.


And right here is the problem.  The more specific need is now based on 
size of the data relative to the amount of memory in the machine.   
That's just messed up.


Does anaconda on F18 put /home and / on different volumes?  I did a 
rawhide install using the F17 and all defaults and they're combined.  
Under this scenario I have sizeof(rootfs) - 5G of disk I can potentially 
use for /tmp.  Under the tmpfs scheme I have 1G (this is a 2G VM) .  The 
answer is, of course, to use /var/tmp -- which only moved the problem 
and didn't do squat except to generate a bunch of patches which amounted 
to s|/tmp|/var/tmp|g


To make this a default was a dumb decision which has never been 
adequately justified.  I did finally see some performance numbers for a 
software build, but that isn't the general case and I can't believe the 
benefits touted even impact the general case, especially given the size 
limitations of /tmp.




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

Re: [HEADS-UP] Rawhide: /tmp is now on tmpfs

2012-07-13 Thread Reindl Harald


Am 12.07.2012 21:54, schrieb Harald Hoyer:
 Again.. tmpfs is restricted to half the RAM size by default. You can't
 store 8-9GB of trash.. only 2GB, which might land on swap over time.

is it limited to half the RAM or 2 GB?
on my machine half the RAM is 8 GB

what about a application storing 4 GB in /tmp
no longer possible

however, it is still bullshit AS DEFAULT
do not touch users RAM for temp crap

if the application thinks it is useful to buffer
something in the RAm it can do this since many
years and THIS is the memory you can swap out
if needed

why do some people all the time introduce braindead
changes for the sake of the change? leave the system
as it is if it works fine and search a hobby beside
IT if you are bored!





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

Schedule for Monday's FESCo meeting (2012-07-16)

2012-07-13 Thread Bill Nottingham
Following is the list of topics that will be discussed in the FESCo
meeting Monday at 17:00UTC (1:00pm EDT) in #fedora-meeting on
irc.freenode.net.

Links to all tickets below can be found at: 
https://fedorahosted.org/fesco/report/9

= Followups =

- none at this time -

= New business =

#topic #889 Retire orphaned packages only after co-maintainers have been 
notified as it happens in the nonresponsive maintainers procedure
.fesco 889

#topic #890 F18 Feature: KDE Plasma Workspaces 4.9 - 
https://fedoraproject.org/wiki/Features/KDE49
.fesco 890

#topic #891 F18 Feature: Eucalyptus - 
https://fedoraproject.org/wiki/Features/Eucalyptus
.fesco 891

#topic #892 F18 Feature: GNOME IBus Integration - 
https://fedoraproject.org/wiki/Features/GNOMEIBusIntegration
.fesco 892

#topic #893 F18 Feature: GSS Proxy - 
https://fedoraproject.org/wiki/Features/gss-proxy
.fesco 893

#topic #894 F18 Feature: ibus-libpinyin - 
https://fedoraproject.org/wiki/Features/ibus-libpinyin
.fesco 894

#topic #895 F18 Feature: Ibus-Typing-Booster - 
https://fedoraproject.org/wiki/Features/Typing-Booster
.fesco 895

= Open Floor = 

For more complete details, please visit each individual ticket.  The
report of the agenda items can be found at
https://fedorahosted.org/fesco/report/9

If you would like to add something to this agenda, you can reply to
this e-mail, file a new ticket at https://fedorahosted.org/fesco,
e-mail me directly, or bring it up at the end of the meeting, during
the open floor topic. Note that added topics may be deferred until
the following meeting. 

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

Re: make distcheck is exploitable: get a fixed automake

2012-07-13 Thread Richard W.M. Jones
On Fri, Jul 13, 2012 at 03:34:53PM +0200, Jim Meyering wrote:
 It's fixed in the latest, automake-12.2

I think you mean 1.12.2 :-)

 http://bugzilla.redhat.com/CVE-2012-3386
 http://savannah.gnu.org/forum/forum.php?forum_id=7294

However I don't think I see any fixed Fedora builds (1.12.2 or 1.11.6)
yet.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming blog: http://rwmj.wordpress.com
Fedora now supports 80 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

[bucardo] Depend on perl ABI as each perl package

2012-07-13 Thread Petr Pisar
commit d8571fc5de8045e09c892de85cdff9652c72d747
Author: Petr Písař ppi...@redhat.com
Date:   Fri Jul 13 08:48:48 2012 +0200

Depend on perl ABI as each perl package

 bucardo.spec |6 +-
 1 files changed, 5 insertions(+), 1 deletions(-)
---
diff --git a/bucardo.spec b/bucardo.spec
index e9bde38..b6ca795 100644
--- a/bucardo.spec
+++ b/bucardo.spec
@@ -1,7 +1,7 @@
 %define realname Bucardo
 Name:   bucardo
 Version:4.5.0
-Release:1%{?dist}
+Release:2%{?dist}
 Summary:Postgres replication system for both multi-master and 
multi-slave operations
 
 Group:  Applications/Databases
@@ -26,6 +26,7 @@ BuildRequires:  perl(Net::SMTP)
 # available from fedora 10
 BuildRequires:  perl(DBIx::Safe)
 
+Requires:  perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo $version))
 Requires:  perl(ExtUtils::MakeMaker)
 Requires:  postgresql-plperl
 
@@ -94,6 +95,9 @@ rm -rf $RPM_BUILD_ROOT
 %dir %{_localstatedir}/run/bucardo
 
 %changelog
+* Fri Jul 13 2012 Petr Pisar ppi...@redhat.com - 4.5.0-2
+- Depend on perl ABI as each perl package
+
 * Thu Jul 12 2012 Itamar ita...@ispbrasil.com.br - 4.5.0-1
 - new version 4.5.0
 
--
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 839001] rt3 upgrade from testing is missing dependencies

2012-07-13 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=839001

--- Comment #4 from Rainer Traut rainer.tr...@awaro.com ---
Yes, update works now:

[root@rt3 backups]# yum update rt3\* --enablerepo=epel-testing -y
Loaded plugins: downloadonly
Setting up Update Process
Resolving Dependencies
-- Running transaction check
--- Package rt3.noarch 0:3.8.10-2.el6.1 will be updated
--- Package rt3.noarch 0:3.8.13-1.el6.2 will be an update
--- Package rt3-mailgate.noarch 0:3.8.10-2.el6.1 will be updated
--- Package rt3-mailgate.noarch 0:3.8.13-1.el6.2 will be an update
-- Finished Dependency Resolution

Dependencies Resolved

=
 Package Arch  Version 
   Repository   Size
=
Updating:
 rt3 noarch3.8.13-1.el6.2  
   epel-testing2.4 M
 rt3-mailgatenoarch3.8.13-1.el6.2  
   epel-testing 29 k

Transaction Summary
=
Upgrade   2 Package(s)

Total download size: 2.4 M
Downloading Packages:
(1/2): rt3-3.8.13-1.el6.2.noarch.rpm   
  | 2.4 MB 00:01
(2/2): rt3-mailgate-3.8.13-1.el6.2.noarch.rpm  
  |  29 kB 00:00
-
Total  
 377 kB/s | 2.4 MB 00:06
Running rpm_check_debug
Running Transaction Test
Transaction Test Succeeded
Running Transaction
  Updating   : rt3-mailgate-3.8.13-1.el6.2.noarch  
 1/4
  Updating   : rt3-3.8.13-1.el6.2.noarch   
 2/4
  Cleanup: rt3-3.8.10-2.el6.1.noarch   
 3/4
  Cleanup: rt3-mailgate-3.8.10-2.el6.1.noarch  
 4/4
  Verifying  : rt3-mailgate-3.8.13-1.el6.2.noarch  
 1/4
  Verifying  : rt3-3.8.13-1.el6.2.noarch   
 2/4
  Verifying  : rt3-3.8.10-2.el6.1.noarch   
 3/4
  Verifying  : rt3-mailgate-3.8.10-2.el6.1.noarch  
 4/4

Updated:
  rt3.noarch 0:3.8.13-1.el6.2 
rt3-mailgate.noarch 0:3.8.13-1.el6.2

Complete!

-- 
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 746941] perl-Mojolicious-3.07 is available

2012-07-13 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=746941

--- Comment #67 from Upstream Release Monitoring 
upstream-release-monitor...@fedoraproject.org ---
Latest upstream release: 3.07
Current version in Fedora Rawhide: 3.0
URL: http://search.cpan.org/dist/Mojolicious/

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

-- 
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 746941] perl-Mojolicious-3.07 is available

2012-07-13 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=746941

Upstream Release Monitoring upstream-release-monitor...@fedoraproject.org 
changed:

   What|Removed |Added

Summary|perl-Mojolicious-3.06 is|perl-Mojolicious-3.07 is
   |available   |available

-- 
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 839909] New: perl-YAML-0.82 is available

2012-07-13 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=839909

Bug ID: 839909
  Keywords: FutureFeature, Triaged
QA Contact: extras...@fedoraproject.org
  Severity: unspecified
   Version: rawhide
  Priority: unspecified
CC: perl-devel@lists.fedoraproject.org, st...@silug.org
  Assignee: st...@silug.org
   Summary: perl-YAML-0.82 is available
Regression: ---
  Story Points: ---
Classification: Fedora
OS: Unspecified
  Reporter: upstream-release-monitor...@fedoraproject.org
  Type: ---
 Documentation: ---
  Hardware: Unspecified
Mount Type: ---
Status: NEW
 Component: perl-YAML
   Product: Fedora

Latest upstream release: 0.82
Current version in Fedora Rawhide: 0.81
URL: http://search.cpan.org/dist/YAML/

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

-- 
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 839815] RFE: [PATCH] Add Miscellanea::RequireRcsKeywords, dropped from Perl-Critic

2012-07-13 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=839815

Petr Pisar ppi...@redhat.com changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #1 from Petr Pisar ppi...@redhat.com ---
That sounds reasonable. I will add it.

-- 
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 839815] RFE: [PATCH] Add Miscellanea::RequireRcsKeywords, dropped from Perl-Critic

2012-07-13 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=839815

Petr Pisar ppi...@redhat.com changed:

   What|Removed |Added

 Attachment #597914|0   |1
   is patch||
 Attachment #597914|application/x-download  |text/plain
  mime type||

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

File Mojolicious-3.07.tar.gz uploaded to lookaside cache by yaneti

2012-07-13 Thread Yanko Kaneti
A file has been added to the lookaside cache for perl-Mojolicious:

f4eaa5dcf6a859550a0d3ccf0565823e  Mojolicious-3.07.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-Mojolicious] Update to 3.07

2012-07-13 Thread Yanko Kaneti
commit b95c6e47ff414e39d146da894166a5c9fc8941be
Author: Yanko Kaneti yan...@declera.com
Date:   Fri Jul 13 11:37:35 2012 +0300

Update to 3.07

 .gitignore|1 +
 perl-Mojolicious.spec |7 +--
 sources   |2 +-
 3 files changed, 7 insertions(+), 3 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 04d1bdf..bb82618 100644
--- a/.gitignore
+++ b/.gitignore
@@ -45,3 +45,4 @@ Mojolicious-0.26.tar.gz
 /Mojolicious-2.95.tar.gz
 /Mojolicious-2.98.tar.gz
 /Mojolicious-3.0.tar.gz
+/Mojolicious-3.07.tar.gz
diff --git a/perl-Mojolicious.spec b/perl-Mojolicious.spec
index 043d64c..4894a03 100644
--- a/perl-Mojolicious.spec
+++ b/perl-Mojolicious.spec
@@ -1,6 +1,6 @@
 Name:   perl-Mojolicious
-Version:3.0
-Release:2%{?dist}
+Version:3.07
+Release:1%{?dist}
 Summary:A next generation web framework for Perl
 License:Artistic 2.0
 Group:  Development/Libraries
@@ -53,6 +53,9 @@ make test
 %{_mandir}/man3/*
 
 %changelog
+* Fri Jul 13 2012 Yanko Kaneti yan...@declera.com - 3.07-1
+- Update to 3.07
+
 * Thu Jun 28 2012 Petr Pisar ppi...@redhat.com - 3.0-2
 - Perl 5.16 rebuild
 
diff --git a/sources b/sources
index 4e202dc..78e3bd1 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-8d713ae4b6aa2be914d2a49d654a5e62  Mojolicious-3.0.tar.gz
+f4eaa5dcf6a859550a0d3ccf0565823e  Mojolicious-3.07.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-Perl-Critic-More] Add Miscellanea::RequireRcsKeywords droped from Perl::Critic

2012-07-13 Thread Petr Pisar
commit d442ac3025dab662b1d78d52f003de75e97ef9c4
Author: Petr Písař ppi...@redhat.com
Date:   Fri Jul 13 10:47:39 2012 +0200

Add Miscellanea::RequireRcsKeywords droped from Perl::Critic

 ...ore-1.000-Miscellanea::RequireRcsKeywords.patch |  236 
 perl-Perl-Critic-More.spec |   18 +-
 2 files changed, 248 insertions(+), 6 deletions(-)
---
diff --git a/Perl-Critic-More-1.000-Miscellanea::RequireRcsKeywords.patch 
b/Perl-Critic-More-1.000-Miscellanea::RequireRcsKeywords.patch
new file mode 100644
index 000..d266026
--- /dev/null
+++ b/Perl-Critic-More-1.000-Miscellanea::RequireRcsKeywords.patch
@@ -0,0 +1,236 @@
+--- Changes
 Changes
+@@ -14,6 +14,8 @@
+  Policy moved:
+  * ValuesAndExpressions::ProhibitMagicNumbers has been moved into the
+core Perl::Critic distribution.
++ * Miscellanea::RequireRcsKeywords has been moved here from the core
++   Perl::Critic distribution (RT #69546).
+ 
+  Dependencies:
+  * Now requires Perl::Critic 1.082.
+--- lib/Perl/Critic/Policy/Miscellanea/RequireRcsKeywords.pm
 lib/Perl/Critic/Policy/Miscellanea/RequireRcsKeywords.pm
+@@ -0,0 +1,202 @@
++##
++#  $URL: 
http://perlcritic.tigris.org/svn/perlcritic/trunk/distributions/Perl-Critic/lib/Perl/Critic/Policy/Miscellanea/RequireRcsKeywords.pm
 $
++# $Date: 2011-12-21 14:40:10 -0800 (Wed, 21 Dec 2011) $
++#   $Author: thaljef $
++# $Revision: 4106 $
++##
++
++package Perl::Critic::Policy::Miscellanea::RequireRcsKeywords;
++
++use 5.006001;
++use strict;
++use warnings;
++use Readonly;
++
++use List::MoreUtils qw(none);
++
++use Perl::Critic::Utils qw{
++:booleans :characters :severities :data_conversion
++};
++
++use base 'Perl::Critic::Policy';
++
++our $VERSION = '1.000';
++
++#-
++
++Readonly::Scalar my $EXPL = [ 441 ];
++
++#-
++
++sub supported_parameters {
++return (
++{
++name= 'keywords',
++description = 'The keywords to require in all files.',
++default_string  = $EMPTY,
++behavior= 'string list',
++},
++);
++}
++
++sub default_severity  { return $SEVERITY_LOW  }
++sub default_themes{ return qw(core more pbp cosmetic) }
++sub applies_to{ return 'PPI::Document'}
++
++#-
++
++sub initialize_if_enabled {
++my ($self, $config) = @_;
++
++# Any of these lists
++$self-{_keyword_sets} = [
++
++# Minimal svk/svn
++[qw(Id)],
++
++# Expansive svk/svn
++[qw(Revision HeadURL Date)],
++
++# cvs?
++[qw(Revision Source Date)],
++];
++
++# Set configuration, if defined.
++my @keywords = keys %{ $self-{_keywords} };
++if ( @keywords ) {
++$self-{_keyword_sets} = [ [ @keywords ] ];
++}
++
++return $TRUE;
++}
++
++#-
++
++sub violates {
++my ( $self, $elem, $doc ) = @_;
++my @viols = ();
++
++my $nodes = $self-_find_wanted_nodes($doc);
++for my $keywordset_ref ( @{ $self-{_keyword_sets} } ) {
++if ( not $nodes ) {
++my $desc = 'RCS keywords '
++. join( ', ', map {\$$_\$} @{$keywordset_ref} )
++. ' not found';
++push @viols, $self-violation( $desc, $EXPL, $doc );
++}
++else {
++my @missing_keywords =
++grep
++{
++my $keyword_rx = qr \$ $_ .* \$ xms;
++! ! none { m/$keyword_rx/xms } @{$nodes}
++}
++@{$keywordset_ref};
++
++if (@missing_keywords) {
++# Provisionally flag a violation. See below.
++my $desc =
++'RCS keywords '
++. join( ', ', map {\$$_\$} @missing_keywords )
++. ' not found';
++push @viols, $self-violation( $desc, $EXPL, $doc );
++}
++else {
++# Hey! I'm ignoring @viols for other keyword sets
++# because this one is complete.
++return;
++}
++}
++}
++
++return @viols;
++}
++
++#-
++
++sub _find_wanted_nodes {
++my ( $self, $doc ) = @_;
++my @wanted_types = qw(Pod Comment Quote::Single Quote::Literal End);
++my @found =  map { @{ $doc-find(PPI::Token::$_) || [] } } 
@wanted_types;
++push @found, grep { $_-content() 

[Bug 839815] RFE: [PATCH] Add Miscellanea::RequireRcsKeywords, dropped from Perl-Critic

2012-07-13 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=839815

Petr Pisar ppi...@redhat.com changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
   Fixed In Version||perl-Perl-Critic-More-1.000
   ||-6.fc18
 Resolution|--- |RAWHIDE
Last Closed||2012-07-13 05:05:06

-- 
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 839953] New: Main perl package pulls in perl-devel

2012-07-13 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=839953

Bug ID: 839953
QA Contact: extras...@fedoraproject.org
  Severity: unspecified
   Version: rawhide
  Priority: unspecified
CC: cw...@alumni.drew.edu, iarn...@gmail.com,
jples...@redhat.com, ka...@ucw.cz, lkund...@v3.sk,
mmasl...@redhat.com,
perl-devel@lists.fedoraproject.org, ppi...@redhat.com,
psab...@redhat.com, rc040...@freenet.de,
tcall...@redhat.com
  Assignee: mmasl...@redhat.com
   Summary: Main perl package pulls in perl-devel
Regression: ---
  Story Points: ---
Classification: Fedora
OS: Unspecified
  Reporter: p...@city-fan.org
  Type: Bug
 Documentation: ---
  Hardware: Unspecified
Mount Type: ---
Status: NEW
 Component: perl
   Product: Fedora

Created attachment 598025
  -- https://bugzilla.redhat.com/attachment.cgi?id=598025action=edit
Move the rest of ExtUtils-ParseXS into its sub-package

Installing the perl 5.16.0 (build 225) package pulls in the perl-devel package
too. This is because there are remnants of the ExtUtils-ParseXS distribution
that have not been moved from the main perl package to the
perl-ExtUtils-ParseXS sub-package.

Attached patch fixes this for me.

-- 
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] Move the rest of ExtUtils-ParseXS into its sub-package

2012-07-13 Thread Petr Pisar
commit 07df355afa39553ea292c8ae72d2e3e78d575578
Author: Paul Howarth p...@city-fan.org
Date:   Fri Jul 13 10:32:24 2012 +0100

Move the rest of ExtUtils-ParseXS into its sub-package

Move the rest of ExtUtils-ParseXS into its sub-package, so that the main
perl package doesn't need to pull in perl-devel

Signed-off-by: Paul Howarth p...@city-fan.org
Signed-off-by: Petr Písař ppi...@redhat.com

 perl.spec |   42 +-
 1 files changed, 41 insertions(+), 1 deletions(-)
---
diff --git a/perl.spec b/perl.spec
index 30541ab..0c58b44 100644
--- a/perl.spec
+++ b/perl.spec
@@ -26,7 +26,7 @@
 Name:   perl
 Version:%{perl_version}
 # release number must be even higher, because dual-lived modules will be 
broken otherwise
-Release:225%{?dist}
+Release:226%{?dist}
 Epoch:  %{perl_epoch}
 Summary:Practical Extraction and Report Language
 Group:  Development/Languages
@@ -1748,11 +1748,29 @@ sed \
 %exclude %{_mandir}/man3/ExtUtils::testlib.3*
 
 # ExtUtils::ParseXS
+%exclude %dir %{privlib}/ExtUtils/ParseXS/
+%exclude %dir %{privlib}/ExtUtils/Typemaps/
 %exclude %{privlib}/ExtUtils/ParseXS.pm
+%exclude %{privlib}/ExtUtils/ParseXS.pod
+%exclude %{privlib}/ExtUtils/ParseXS/Constants.pm
+%exclude %{privlib}/ExtUtils/ParseXS/CountLines.pm
+%exclude %{privlib}/ExtUtils/ParseXS/Utilities.pm
+%exclude %{privlib}/ExtUtils/Typemaps.pm
+%exclude %{privlib}/ExtUtils/Typemaps/Cmd.pm
+%exclude %{privlib}/ExtUtils/Typemaps/InputMap.pm
+%exclude %{privlib}/ExtUtils/Typemaps/OutputMap.pm
+%exclude %{privlib}/ExtUtils/Typemaps/Type.pm
 %exclude %{privlib}/ExtUtils/xsubpp
 %exclude %{_bindir}/xsubpp
 %exclude %{_mandir}/man1/xsubpp*
 %exclude %{_mandir}/man3/ExtUtils::ParseXS.3*
+%exclude %{_mandir}/man3/ExtUtils::ParseXS::Constants.3*
+%exclude %{_mandir}/man3/ExtUtils::ParseXS::Utilities.3*
+%exclude %{_mandir}/man3/ExtUtils::Typemaps.3*
+%exclude %{_mandir}/man3/ExtUtils::Typemaps::Cmd.3*
+%exclude %{_mandir}/man3/ExtUtils::Typemaps::InputMap.3*
+%exclude %{_mandir}/man3/ExtUtils::Typemaps::OutputMap.3*
+%exclude %{_mandir}/man3/ExtUtils::Typemaps::Type.3*
 
 # File::Fetch
 %exclude %{privlib}/File/Fetch.pm
@@ -2224,11 +2242,29 @@ sed \
 %{_mandir}/man3/ExtUtils::testlib.3*
 
 %files ExtUtils-ParseXS
+%dir %{privlib}/ExtUtils/ParseXS/
+%dir %{privlib}/ExtUtils/Typemaps/
 %{privlib}/ExtUtils/ParseXS.pm
+%{privlib}/ExtUtils/ParseXS.pod
+%{privlib}/ExtUtils/ParseXS/Constants.pm
+%{privlib}/ExtUtils/ParseXS/CountLines.pm
+%{privlib}/ExtUtils/ParseXS/Utilities.pm
+%{privlib}/ExtUtils/Typemaps.pm
+%{privlib}/ExtUtils/Typemaps/Cmd.pm
+%{privlib}/ExtUtils/Typemaps/InputMap.pm
+%{privlib}/ExtUtils/Typemaps/OutputMap.pm
+%{privlib}/ExtUtils/Typemaps/Type.pm
 %{privlib}/ExtUtils/xsubpp
 %{_bindir}/xsubpp
 %{_mandir}/man1/xsubpp*
 %{_mandir}/man3/ExtUtils::ParseXS.3*
+%{_mandir}/man3/ExtUtils::ParseXS::Constants.3*
+%{_mandir}/man3/ExtUtils::ParseXS::Utilities.3*
+%{_mandir}/man3/ExtUtils::Typemaps.3*
+%{_mandir}/man3/ExtUtils::Typemaps::Cmd.3*
+%{_mandir}/man3/ExtUtils::Typemaps::InputMap.3*
+%{_mandir}/man3/ExtUtils::Typemaps::OutputMap.3*
+%{_mandir}/man3/ExtUtils::Typemaps::Type.3*
 
 %files File-Fetch
 %{privlib}/File/Fetch.pm
@@ -2533,6 +2569,10 @@ sed \
 
 # Old changelog entries are preserved in CVS.
 %changelog
+* Fri Jul 13 2012 Paul Howarth p...@city-fan.org 4:5.16.0-226
+- Move the rest of ExtUtils-ParseXS into its sub-package, so that the main
+  perl package doesn't need to pull in perl-devel (bug #839953)
+
 * Mon Jul 02 2012 Jitka Plesnikova jples...@redhat.com 4:5.16.0-225
 - Fix broken atof (bug #835452)
 
--
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 839953] Main perl package pulls in perl-devel

2012-07-13 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=839953

Petr Pisar ppi...@redhat.com changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
   Fixed In Version||perl-5.16.0-226.fc18
 Resolution|--- |RAWHIDE
   Assignee|mmasl...@redhat.com |ppi...@redhat.com
Last Closed||2012-07-13 07:56:16

--- Comment #1 from Petr Pisar ppi...@redhat.com ---
Good catch. Applied.

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

Broken dependencies: perl-Unix-Statgrab

2012-07-13 Thread buildsys


perl-Unix-Statgrab has broken dependencies in the rawhide tree:
On x86_64:
perl-Unix-Statgrab-0.04-13.fc17.x86_64 requires 
perl(:MODULE_COMPAT_5.14.2)
On i386:
perl-Unix-Statgrab-0.04-13.fc17.i686 requires 
perl(:MODULE_COMPAT_5.14.2)
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

Broken dependencies: perl-PDL

2012-07-13 Thread buildsys


perl-PDL has broken dependencies in the rawhide tree:
On x86_64:
perl-PDL-2.4.10-1.fc17.x86_64 requires perl(:MODULE_COMPAT_5.14.2)
On i386:
perl-PDL-2.4.10-1.fc17.i686 requires perl(:MODULE_COMPAT_5.14.2)
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

Broken dependencies: perl-Class-InsideOut

2012-07-13 Thread buildsys


perl-Class-InsideOut has broken dependencies in the rawhide tree:
On x86_64:
perl-Class-InsideOut-1.10-6.fc17.noarch requires 
perl(:MODULE_COMPAT_5.14.2)
On i386:
perl-Class-InsideOut-1.10-6.fc17.noarch requires 
perl(:MODULE_COMPAT_5.14.2)
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