Re: PEAR not entirely in EPEL?
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
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
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
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
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
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
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?
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?
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?
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?
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?
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
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?
-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?
-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
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?
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
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?
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
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
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
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)
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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