EPEL Fedora 6 updates-testing report
The following Fedora EPEL 6 Security updates need testing: Age URL 704 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2012-5620/bugzilla-3.4.14-2.el6 134 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-12079/bip-0.8.9-1.el6 51 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0440/fwsnort-1.6.4-1.el6 46 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0483/boinc-client-7.2.33-3.git1994cc8.el6 36 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0590/oath-toolkit-2.0.2-4.el6 12 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0845/asterisk-1.8.26.1-1.el6 12 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0846/mediawiki119-1.19.13-1.el6 12 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0852/lighttpd-1.4.35-1.el6 8 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0888/v8-3.14.5.10-7.el6 8 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0889/moodle-2.4.9-1.el6 2 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0938/seamonkey-2.21-5.ESR_24.4.0.el6 1 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0951/check-mk-1.2.4-1.el6 0 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0972/munin-2.0.19-2.el6 0 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0980/perl-YAML-LibYAML-0.38-4.el6 The following builds have been pushed to Fedora EPEL 6 updates-testing cscppc-1.0.3-1.el6 cswrap-1.0.3-1.el6 munin-2.0.19-2.el6 open-vm-tools-9.4.0-8.el6 ovirt-engine-cli-3.4.0.5-1.el6 ovirt-engine-sdk-python-3.4.0.6-1.el6 perl-Rose-DB-Object-0.811-1.el6 perl-YAML-LibYAML-0.38-4.el6 python-iso8601-0.1.10-1.el6 yapet-1.0-1.el6 Details about builds: cscppc-1.0.3-1.el6 (FEDORA-EPEL-2014-0978) A compiler wrapper that runs cppcheck in background Update Information: initial packaging References: [ 1 ] Bug #1066026 - Review Request: cscppc - A compiler wrapper that runs cppcheck in background https://bugzilla.redhat.com/show_bug.cgi?id=1066026 cswrap-1.0.3-1.el6 (FEDORA-EPEL-2014-0976) Generic compiler wrapper Update Information: initial packaging References: [ 1 ] Bug #1066028 - Review Request: cswrap - Generic compiler wrapper https://bugzilla.redhat.com/show_bug.cgi?id=1066028 munin-2.0.19-2.el6 (FEDORA-EPEL-2014-0972) Network-wide graphing framework (grapher/gatherer) Update Information: minor bugfix release: - BZ# 1081254: Start asyncd after node - BZ# 1028075: munin-node doesn't get added to chkconfig Upstream update to 2.0.18, fixes CVE-2013-6359 ChangeLog: * Wed Mar 26 2014 D. Johnson fenri...@fedoraproject.org - 2.0.19-2 - BZ# 1081254: Start asyncd after node - BZ# 1028075: munin-node doesn't get added to chkconfig References: [ 1 ] Bug #1037888 - CVE-2013-6048 CVE-2013-6359 munin: two denial of service flaws fixed in 2.0.18 https://bugzilla.redhat.com/show_bug.cgi?id=1037888 open-vm-tools-9.4.0-8.el6 (FEDORA-EPEL-2014-0967) Open Virtual Machine Tools for virtual machines hosted on VMware Update Information: Added package dependencies to address BZ#1045709 and BZ#1077320. ChangeLog: * Wed Mar 26 2014 Ravindra Kumar ravindraku...@vmware.com - 9.4.0-8 - Add missing package dependency on 'which' (BZ#1045709) * Tue Mar 25 2014 Ravindra Kumar ravindraku...@vmware.com - 9.4.0-7 - Add -D_DEFAULT_SOURCE to suppress warning as suggested in https://sourceware.org/bugzilla/show_bug.cgi?id=16632 * Fri Mar 21 2014 Ravindra Kumar ravindraku...@vmware.com - 9.4.0-6 - Add missing package dependencies (BZ#1045709, BZ#1077320) * Tue Feb 18 2014 Igor Gnatenko i.gnatenko.br...@gmail.com - 9.4.0-5 - Fix FTBFS
RFC: httpd-filesystem proposal
We're proposing to add an httpd-filesystem subpackage which will simplify some dependency problems; particularly for packages which want to contain files owned by the apache user, but don't need a dependency on httpd itself. https://bugzilla.redhat.com/show_bug.cgi?id=1081453 Any comments welcome, either here on the bug. Regards, Joe -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: RFC: httpd-filesystem proposal
On Thu, Mar 27, 2014 at 11:41:55AM +, Joe Orton wrote: We're proposing to add an httpd-filesystem subpackage which will simplify some dependency problems; particularly for packages which want to contain files owned by the apache user, but don't need a dependency on httpd itself. https://bugzilla.redhat.com/show_bug.cgi?id=1081453 Any comments welcome, either here on the bug. +1 to more subpacking for httpd. I don't think gnome-user-share is installed by default anymore (or used by anyone?), but maybe we could finally really solve https://bugzilla.redhat.com/show_bug.cgi?id=235682, while we are at it. :) -- Matthew Miller-- Fedora Project--mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: PrivateDevices=yes and PrivateNetwork=yes For Long-Running Services
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/27/2014 12:30 AM, William Brown wrote: On Wed, 2014-03-26 at 13:43 -0400, Stephen Gallagher wrote: On 03/26/2014 10:06 AM, Jaroslav Reznik wrote: snip Note that PrivateNetwork=yes should not be used for: 1. Services that actually require network access (with the exception of daemons only needing socket activation) 2. Services which may be used to execute arbitrary user or administrator supplied programs. (see above) 3. Services which might need to resolve non-system user and group names. Since on some setups resolving non-system users might require network access to an LDAP or NIS server, enabling this option on might break resolving of these user names. Note however that system users/groups are always resolvable even without network access. Hence it is safe to enable this option for daemons which just need to resolve their own system user or group name. This may not be a safe statement to make. I personally know of a great many deployments where admins have removed the local accounts for their services and instead rely on LDAP accounts. (This is mostly to guarantee that the file ownership of these services is the same user on all systems, which they may not be if the local account was created using the 'get-next-free-id' approach). We'd need to think very hard about whether any service should have this turned on by default. If we *do* enable it by default, we should also carefully document how to turn it off for those services if they rely on centrally-managed accounts. Would PrivateNetwork break interactions with SSSD? If you used that to provide nsswitch, then it may not be such an issue. Hmm, good point. It would be talking to SSSD via a local socket. Naturally this feature wouldn't affect the SSSD daemon. So yeah, that would probably work just fine. I didn't think that all the way through originally. This probably can break people using nss_ldap or nss_winbind, though. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlM0FEwACgkQeiVVYja6o6NTGwCdFSprsfcoYN52RwfUcL9+ZoGA rtcAoJnWcV7mC8wO/YHtbQ9UTnhoQKrF =dOqN -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: PrivateDevices=yes and PrivateNetwork=yes For Long-Running Services
On Thu, 2014-03-27 at 08:06 -0400, Stephen Gallagher wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/27/2014 12:30 AM, William Brown wrote: On Wed, 2014-03-26 at 13:43 -0400, Stephen Gallagher wrote: On 03/26/2014 10:06 AM, Jaroslav Reznik wrote: snip Note that PrivateNetwork=yes should not be used for: 1. Services that actually require network access (with the exception of daemons only needing socket activation) 2. Services which may be used to execute arbitrary user or administrator supplied programs. (see above) 3. Services which might need to resolve non-system user and group names. Since on some setups resolving non-system users might require network access to an LDAP or NIS server, enabling this option on might break resolving of these user names. Note however that system users/groups are always resolvable even without network access. Hence it is safe to enable this option for daemons which just need to resolve their own system user or group name. This may not be a safe statement to make. I personally know of a great many deployments where admins have removed the local accounts for their services and instead rely on LDAP accounts. (This is mostly to guarantee that the file ownership of these services is the same user on all systems, which they may not be if the local account was created using the 'get-next-free-id' approach). We'd need to think very hard about whether any service should have this turned on by default. If we *do* enable it by default, we should also carefully document how to turn it off for those services if they rely on centrally-managed accounts. Would PrivateNetwork break interactions with SSSD? If you used that to provide nsswitch, then it may not be such an issue. Hmm, good point. It would be talking to SSSD via a local socket. Naturally this feature wouldn't affect the SSSD daemon. So yeah, that would probably work just fine. I didn't think that all the way through originally. This probably can break people using nss_ldap or nss_winbind, though. Only people using the old nss_ldap. nss_ldapd, nss_winbind, like nss_sss talks to a daemon on a local socket. I honestly think people should stop using the old nss_ldap, and I think most already migrated to one of the superior choices in Fedora land, so I see no particular issue from this point of view. however there are deployments that still need to access ldap directly in some case (I am thinking autofs maps store on ldap for example). Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: What will happen to XFCE, LXDE, Mate, Cinnemon in Fedora.Next
On Mar 25, 2014 8:27 PM, Dan Mashal dan.mas...@gmail.com wrote: On Tue, Mar 25, 2014 at 1:07 PM, Kevin Kofler kevin.kof...@chello.at wrote: My point is that it must ALSO be possible to install the preferred desktop directly, without installing GNOME first. Exactly this. Installing MATE from the spin is not exactly the same thing as installing it from the netinstall or the DVD. The spin does not include the same packages as the DVD and the netinstall due to size constraints. If we can keep the netinstall, which allows people to do exactly this, then I really could careless what happens with workstation (and I'm also a happy camper, as I imagine you and many others would be too). Dan -- Can this difference be fixed with a mate-firstboot ui, ie these additional applications are recommended for use with MATE, would you like to check off the ones that interest you and install them ? --Pete -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Review swap...
Ive got a package review for compat-qpid-cpp [1] and am willing to trade reviews. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1080583 -- Darryl L. Pierce mcpie...@gmail.com http://mcpierce.blogspot.com/ Famous last words: I wonder what happens if we do it this way? pgpbqW8iloRrU.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 Self Contained Change: Apache Mesos
- Original Message - Jaroslav Reznik (jrez...@redhat.com) said: = Proposed Self Contained Change: Apache Mesos = https://fedoraproject.org/wiki/Changes/ApacheMesos Change owner(s): Timothy St. Clair tstcl...@redhat.com Apache Mesos [1] is a cluster manager for sharing distributed application frameworks. This change brings Mesos to Fedora, which many have called a micro-kernel for the data center. Are we clustering Changes by products they may effect, or should be tied to in marketing? For example, this and Tachyon seem like natural marketing points for Fedora Cloud. And more are coming. But I added Product field (*) to the EmptyTemplate, it could be used to sort Changes to products and as heads up for marketing. Or another possibility is to create Wiki category. I can process both. We already touched it with Stephen on Server meeting. (*) it's optional. Jaroslav Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Unresponsive maintainer: wolfy
Hello, Anyone knows how could I contact wolfy? I've tried to reach him at IRC and known e-mail addresses, without a response. His FAS address bounces and sponsor does not know how to contact him either. I hope he's doing fine. He maintains an EPEL branch of the package (Pound) I'd like to see in epel7 and I'm wondering if he's willing to maintain the epel7 branch. Thank you, Lubo -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Taskotron Data Interfaces
It's Task-o-tron, it suggests it's meant to execute _tasks_ :-) On the other hand, check is more specific than task, it explains the purpose better. I guess native speakers will need to deal with language subtleties. I just want to be consistent in naming, it helps us and our users, that's all. Yeah, consistency is important. Personally, I'm ok with leaving stuff like libtaskotron.check for the moment - that's what we're working on. Do you think that changing things over to TaskDetail etc. would make taskotron easier to understand? I think it's OK as it is for the moment. Once we intend to release some public API, we can go through it and make it more consistent. Only time will tell if 'tasks' and 'checks' use the same interface and behave completely the same, or if they are two separate things. ___ qa-devel mailing list qa-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/qa-devel
Request for help with slic3r crash
Hi, I really need help with fixing a crash in slic3r that bothers me for a long time. See https://github.com/alexrj/Slic3r/issues/1636#issuecomment-31219661 and https://bugzilla.redhat.com/show_bug.cgi?id=1046006 Steps to reproduce: Run slic3r on F20 from this scratch build: http://koji.fedoraproject.org/koji/taskinfo?taskID=6603224 1) On Print setting tab, Advanced, Other, Threads enter value 1 (such as 2) 2) From File menu select Quick slice... 3) Select any (valid) STL* file 4) Observe the crash * Get one here: http://churchyard.fedorapeople.org/pypy-test.stl Upstream cannot reproduce the bug (I guess it's Fedora specific) and is probably not interested in fixing this. I guess the crash is happening in Wx. Thanks for any hint. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Schedule for Thursday's FPC Meeting (2014-03-27 17:00 UTC) (next week back to 16:00 UTC)
On Wed, Mar 26, 2014 at 09:45:14PM +0100, Miloslav Trmač wrote: 2014-03-26 20:51 GMT+01:00 James Antill ja...@fedoraproject.org: (approval and retirement sections already passed, /opt exception passed) #topic #339 software collections in Fedora .fpc 339 https://fedorahosted.org/fpc/ticket/339 I can't help seeing this on the agenda for a long time (the ticket has been opened 7 months ago), including 3 months with no activity in the ticket, and now 2 months since last activity in the ticket. Mailing list discussions also vary between vigorous in some months and essentially zero in other months. Is there some work going on elsewhere that I'm missing? If not, what are the constraints that prevent quicker decision making? Mirek There have been many problems in the past which I think I've gone into elsewhere. Current things that are being worked on: I have one set of scls built: http://copr-fe.cloud.fedoraproject.org/coprs/toshio/SCL-Test-Python2.4/ Have to push the lessons from that into the guideline draft and also have to update it with some more discussion that happened between Jan and myself (after testing that those proposals will work). Current build of scl-utils with patches I've found necessary applied: http://copr-fe.cloud.fedoraproject.org/coprs/toshio/SCL-Test-scl-utils/ The filesystem paths patch from that is a blocker but seems to be stalled: https://bugzilla.redhat.com/show_bug.cgi?id=105 The byte compile patch I have to work on incorporating some feedback from Jan before trying to push it upstream. I also need to build something that makes use of statefiles and conf files. to test this out. mariadb or a postgresql package are good candidates. hhorak had mentioned testing this simply by changing the paths in a package (rather than changing scl-utils) and the general strategy works. That's pretty much where we're at. -Toshio pgpIZXS70xlFa.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: PrivateDevices=yes and PrivateNetwork=yes For Long-Running Services
2014-03-26 15:06 GMT+01:00 Jaroslav Reznik jrez...@redhat.com: == Detailed Description == When PrivateDevices=yes is set in the [Service] section of a systemd service unit file, the processes run for the service will run in a private file system namespace IIRC the kernel has had some issues with scaling to dozens or hundreds of namespaces (which was noticeable with Docker). Can I assume these are either fixed or not applicable to this usage? == Scope == * Policies and guidelines: It might be nice to update the packaging policies to also recommend making use of these settings. Yes, it might be. Do you plan to propose such a guideline update to FPC, or is this an if somebody else cares item? Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: PrivateDevices=yes and PrivateNetwork=yes For Long-Running Services
2014-03-26 15:06 GMT+01:00 Jaroslav Reznik jrez...@redhat.com: == Detailed Description == When PrivateDevices=yes... Furthermore, the CAP_MKNOD capability is removed. Finally, the devices cgroup controller is used to ensure that no access to device nodes except the listed ones is possible. When PrivateNetwork=yes ... 4. This also disconnects the AF_UNIX abstract namespace 5. This also disconnects the AF_NETLINK and AF_AUDIT socket families How much does this overlap existing SELinux policy? Would it make sense to have both configured from a single source? It seems to me that every inconsistency between the systemd unit file and the SELinux policy must be a bug; could we eliminate this class of bugs entirely, or if fully automated extraction of the information between the two data sets weren't feasible, would it make sense to have and regularly run tools that compare the two policies? Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
repo XML file schemas
Hi, The Fedora XML repo file schemas seem to have disappeared. metadata xmlns=http://linux.duke.edu/metadata/common; xmlns:rpm=http://linux.duke.edu/metadata/rpm; packages=14364 duke.edu no longer seem to host them ! Looking for a response, Aaron -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: PrivateDevices=yes and PrivateNetwork=yes For Long-Running Services
On 03/27/2014 01:49 PM, Miloslav Trmač wrote: 2014-03-26 15:06 GMT+01:00 Jaroslav Reznik jrez...@redhat.com: == Detailed Description == When PrivateDevices=yes... Furthermore, the CAP_MKNOD capability is removed. Finally, the devices cgroup controller is used to ensure that no access to device nodes except the listed ones is possible. When PrivateNetwork=yes ... 4. This also disconnects the AF_UNIX abstract namespace 5. This also disconnects the AF_NETLINK and AF_AUDIT socket families How much does this overlap existing SELinux policy? Would it make sense to have both configured from a single source? It seems to me that every inconsistency between the systemd unit file and the SELinux policy must be a bug; could we eliminate this class of bugs entirely, or if fully automated extraction of the information between the two data sets weren't feasible, would it make sense to have and regularly run tools that compare the two policies? Mirek It doesn't really overlap with SELinux, just adds another layer of security. And gives the administrator more flexibility on how he configures his services. I do not think there are two many confined domains that need mknod, and most confined domains are not allowed to look at many device nodes. In a way this can eliminate SELinux avcs, from apps just doing the equiv of ls -l /dev -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Heads up: Mesa/LLVM rebase and OpenGTL retirement in F20
We'd like to update to Mesa 10.1 in Fedora 20, since the cycle is so long before F21 and (among other goodies) it enables OpenGL 3.3 on some newer Radeons. This implies rebasing LLVM 3.4, and that's where it gets a little awkward: the OpenGTL package only works up to LLVM 3.3. However, OpenGTL is dead upstream, and the only thing requiring it in F20 gold - calligra-krita, by way of libQtGTL - has already been updated to Obsolete OpenGTL. As far as I know OpenGTL is the only such package we have requiring LLVM 3.3, so the rest of the rebase should just be a matter of updating to match F21. The following source packages will also be updated for the llvm rebase: dragonegg gambas3 pocl pure python-llvmpy If there are no serious objections I'll try to get this all into testing early next week. If you _do_ happen to be using OpenGTL for something in F20, now would be an excellent time for you to start working on porting it to current LLVM. - ajax -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: PrivateDevices=yes and PrivateNetwork=yes For Long-Running Services
2014-03-27 20:57 GMT+01:00 Daniel J Walsh dwa...@redhat.com: On 03/27/2014 01:49 PM, Miloslav Trmač wrote: 2014-03-26 15:06 GMT+01:00 Jaroslav Reznik jrez...@redhat.com: == Detailed Description == When PrivateDevices=yes... Furthermore, the CAP_MKNOD capability is removed. Finally, the devices cgroup controller is used to ensure that no access to device nodes except the listed ones is possible. When PrivateNetwork=yes ... 4. This also disconnects the AF_UNIX abstract namespace 5. This also disconnects the AF_NETLINK and AF_AUDIT socket families How much does this overlap existing SELinux policy? Would it make sense to have both configured from a single source? It seems to me that every inconsistency between the systemd unit file and the SELinux policy must be a bug; could we eliminate this class of bugs entirely, or if fully automated extraction of the information between the two data sets weren't feasible, would it make sense to have and regularly run tools that compare the two policies? Mirek It doesn't really overlap with SELinux, just adds another layer of security. Layers tend to overlap :) in affected areas, if not in specific implementation. And gives the administrator more flexibility on how he configures his services. I do not think there are two many confined domains that need mknod, and most confined domains are not allowed to look at many device nodes. So, could we generate a starting list of daemons to be restricted by PrivateDevices by looking for domains that aren't allowed in the SELinux policy to look at device nodes? And use the fixes previously done in the SELinux policy to notice daemons that actually do need access to devices without ever publishing a RPM with a too constrained systemd unit to users? That's where I was going with this--possibly up to possible full bidirectional synchronization between SELinux and systemd units. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[perl-MooseX-Types-Stringlike] Created tag perl-MooseX-Types-Stringlike-0.002-1.el7
The lightweight tag 'perl-MooseX-Types-Stringlike-0.002-1.el7' was created pointing to: bf41294... Initial import (perl-MooseX-Types-Stringlike-0.002-1) -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-MooseX-Types-Stringlike] Created tag perl-MooseX-Types-Stringlike-0.002-1.fc19
The lightweight tag 'perl-MooseX-Types-Stringlike-0.002-1.fc19' was created pointing to: bf41294... Initial import (perl-MooseX-Types-Stringlike-0.002-1) -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-MooseX-Types-Stringlike] Created tag perl-MooseX-Types-Stringlike-0.002-1.fc21
The lightweight tag 'perl-MooseX-Types-Stringlike-0.002-1.fc21' was created pointing to: bf41294... Initial import (perl-MooseX-Types-Stringlike-0.002-1) -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-MooseX-Types-Stringlike] Created tag perl-MooseX-Types-Stringlike-0.002-1.fc20
The lightweight tag 'perl-MooseX-Types-Stringlike-0.002-1.fc20' was created pointing to: bf41294... Initial import (perl-MooseX-Types-Stringlike-0.002-1) -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: F21 System Wide Change: PrivateDevices=yes and PrivateNetwork=yes For Long-Running Services
On 03/27/2014 04:03 PM, Miloslav Trmač wrote: 2014-03-27 20:57 GMT+01:00 Daniel J Walsh dwa...@redhat.com: On 03/27/2014 01:49 PM, Miloslav Trmač wrote: 2014-03-26 15:06 GMT+01:00 Jaroslav Reznik jrez...@redhat.com: == Detailed Description == When PrivateDevices=yes... Furthermore, the CAP_MKNOD capability is removed. Finally, the devices cgroup controller is used to ensure that no access to device nodes except the listed ones is possible. When PrivateNetwork=yes ... 4. This also disconnects the AF_UNIX abstract namespace 5. This also disconnects the AF_NETLINK and AF_AUDIT socket families How much does this overlap existing SELinux policy? Would it make sense to have both configured from a single source? It seems to me that every inconsistency between the systemd unit file and the SELinux policy must be a bug; could we eliminate this class of bugs entirely, or if fully automated extraction of the information between the two data sets weren't feasible, would it make sense to have and regularly run tools that compare the two policies? Mirek It doesn't really overlap with SELinux, just adds another layer of security. Layers tend to overlap :) in affected areas, if not in specific implementation. And gives the administrator more flexibility on how he configures his services. I do not think there are two many confined domains that need mknod, and most confined domains are not allowed to look at many device nodes. So, could we generate a starting list of daemons to be restricted by PrivateDevices by looking for domains that aren't allowed in the SELinux policy to look at device nodes? And use the fixes previously done in the SELinux policy to notice daemons that actually do need access to devices without ever publishing a RPM with a too constrained systemd unit to users? That's where I was going with this--possibly up to possible full bidirectional synchronization between SELinux and systemd units. Mirek Yes I think that is a good idea. I would look at all domains that need access to non standard devices and eliminate them from the list. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[perl-Path-Tiny] Created tag perl-Path-Tiny-0.052-1.el7
The lightweight tag 'perl-Path-Tiny-0.052-1.el7' was created pointing to: 3487eea... Update to 0.052 -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: F21 System Wide Change: Java 8
Hi, * Stephen John Smoogen smo...@gmail.com [2014-03-26 11:55]: I would say that there needs to be something a bit larger than a rebuild but a mass test so that you end up with finding out that someone's hack to make java-7 do something neat isn't java-8 runtime saying 'crash'. What about holding a Test Day [1] for this? Do you have anything else in mind? Thanks, Omair [1] https://fedoraproject.org/wiki/QA/Test_Days -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: What will happen to XFCE, LXDE, Mate, Cinnemon in Fedora.Next
On Thu, 2014-03-27 at 07:40 -0600, Pete Travis wrote: On Mar 25, 2014 8:27 PM, Dan Mashal dan.mas...@gmail.com wrote: On Tue, Mar 25, 2014 at 1:07 PM, Kevin Kofler kevin.kof...@chello.at wrote: My point is that it must ALSO be possible to install the preferred desktop directly, without installing GNOME first. Exactly this. Installing MATE from the spin is not exactly the same thing as installing it from the netinstall or the DVD. The spin does not include the same packages as the DVD and the netinstall due to size constraints. If we can keep the netinstall, which allows people to do exactly this, then I really could careless what happens with workstation (and I'm also a happy camper, as I imagine you and many others would be too). Dan -- Can this difference be fixed with a mate-firstboot ui, ie these additional applications are recommended for use with MATE, would you like to check off the ones that interest you and install them ? Hum. This is actually kind of an interesting idea. If we could somehow encode the selected groups in the live image for anaconda to pass on to the installed system, the post-install tool could becomes fairly trivial and generic. All it has to do really is a 'yum/dnf groupinstall @installed_group_a @installed_group_b etc etc', and I think that should fill in any available 'missing packages' from the repositories, for a live or DVD install. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Heads up: Mesa/LLVM rebase and OpenGTL retirement in F20
On Thu, 2014-03-27 at 16:02 -0400, Adam Jackson wrote: We'd like to update to Mesa 10.1 in Fedora 20, since the cycle is so long before F21 and (among other goodies) it enables OpenGL 3.3 on some newer Radeons. This implies rebasing LLVM 3.4, and that's where it gets a little awkward: the OpenGTL package only works up to LLVM 3.3. However, OpenGTL is dead upstream, and the only thing requiring it in F20 gold - calligra-krita, by way of libQtGTL - has already been updated to Obsolete OpenGTL. As far as I know OpenGTL is the only such package we have requiring LLVM 3.3, so the rest of the rebase should just be a matter of updating to match F21. The following source packages will also be updated for the llvm rebase: dragonegg gambas3 pocl pure python-llvmpy If there are no serious objections I'll try to get this all into testing early next week. If you _do_ happen to be using OpenGTL for something in F20, now would be an excellent time for you to start working on porting it to current LLVM. I can absolutely see the reasons for doing this, but...can it at least go through a fesco rubber stamp? Let's face it, entirely deprecating a library we shipped as part of the gold release seems to be a pretty flagrant violation of the update policy, and really ought to be granted a formal exception at the very least if it's going to go ahead. As a result, we should avoid major updates of packages within a stable release. Updates should aim to fix bugs, and not introduce features, particularly when those features would materially affect the user or developer experience. ABI changes in general are very strongly discouraged https://fedoraproject.org/wiki/Updates_Policy#Stable_Releases Fedora *is* a platform, not just a set of packages, however half-assedly we conform to that vision, so I guess I just feel a bit uncomfortable not at least putting up a few hoops for this to jump through. :) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[REGRESSION] ovpn can't build and can't connect to host (SSL3_GET_SERVER_CERTIFICATE)
Hi, please take a look for critical bug[0] in openssl or gnutls (I don't know howto debug more better where bug) [0]https://bugzilla.redhat.com/show_bug.cgi?id=1081708 -- -Igor Gnatenko -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: PrivateDevices=yes and PrivateNetwork=yes For Long-Running Services
On Wed, 26.03.14 11:28, Bill Nottingham (nott...@splat.cc) wrote: Jaroslav Reznik (jrez...@redhat.com) said: = Proposed System Wide Change: PrivateDevices=yes and PrivateNetwork=yes For Long-Running Services = https://fedoraproject.org/wiki/Changes/PrivateDevicesAndPrivateNetwork Change owner(s): Lennart Poettering lennart at poettering dot net, Dan Walsh, Kay Sievers Let's make Fedora more secure by default! Recent systemd versions provide two per-service switches PrivateDevices=yes/no and PrivateNetwork=yes/no which enable services to run without access to any physical devices in /dev, or without access to kind of network sockets. So far this has seen little use in Fedora, and with this Fedora Change we'd like to change this, and enable these for all long-running services that do not require device/network access. Can you define 'recent' here? While we wouldn't want to change the behavior of existing F20 or earlier services, it would be worthwhile to know if packages built for EPEL 7 could/should use this feature as well. Both PrivateDevices= and PrivateNetwork= I'd only advocate to use on F21 really. PrivateNetwork= should mostly work the same way on F20 already, however with one exception. On F20 and older the notification socket systemd used as backend for sd_notify() and friends was in the abstract namespace which is affected by PrivateNetwork=. This means PrivateNetwork= effectively breaks sd_notify() there. On F21 we moved the socket into the file system instead, which is unaffected by PrivateNetwork=, hence sd_notify() works fine there, regardless if PrivateNetwork() is used or not. (Note that moving the socket is not compat breakage since it was mostly dynamic previously, and hence people already had to check $NOTIFY_SOCKET for it, which allowed us to cleanly move it to a different place. PrivateDevices= is only available in F21. I filed this as feature for F21, and that's what it is about. Since the differences in the effect of PrivateNetwork= between F20 and F21 are hard to explain I really would prefer to focus on F21 only for this. Hope that makes sense, Lennart -- Lennart Poettering, Red Hat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: PrivateDevices=yes and PrivateNetwork=yes For Long-Running Services
On Wed, 26.03.14 13:43, Stephen Gallagher (sgall...@redhat.com) wrote: Note that PrivateNetwork=yes should not be used for: 1. Services that actually require network access (with the exception of daemons only needing socket activation) 2. Services which may be used to execute arbitrary user or administrator supplied programs. (see above) 3. Services which might need to resolve non-system user and group names. Since on some setups resolving non-system users might require network access to an LDAP or NIS server, enabling this option on might break resolving of these user names. Note however that system users/groups are always resolvable even without network access. Hence it is safe to enable this option for daemons which just need to resolve their own system user or group name. This may not be a safe statement to make. I personally know of a great many deployments where admins have removed the local accounts for Well, this assumption is built into a lot of software we do, for example all across device management, tmpfiles and suchlike. System users must be resolvable without network, we cannot delay bootup for these components, just because the network isn't up yet... It's OK to if normal users are only resolvable with the network round. And it's OK to sync system user IDs across the network, but they must be resolvable at any time -- they are integral part of the core OS after all. People can use a caching daemon (like sssd?) if they like, to make sure the system users stay in syn across the network, but removing them from /etc/passwed entirely is nothing we ever supported or should support. I mean, it's even OK if people hack things that way, if they want to shoot themselves in the foot, and know what they do. But that really shouldn't stop us from deploying PrivateNetwork=yes, since there is a very easy way out for them: just enable nscd. With nscd enabled the NSS calls will go via the nscd AF_UNIX socket in the fs (which is connectable, regardless of PrivateNetwork=yes), and then the actual query is made from nscd. Or actually, to top that, people who have setups like that, and store their user databases on the network, for example in LDAP, are the ones nscd has been written for in the first place, and hence there's really very little changing for them. But anyway, it's a hack to allow system users to be removed from /etc/passwd. It's already broken if you want to support that, you have to file bugs to udev, tmpfiles and so on. And yuck, I don't even see how that could ever work... We'd need to think very hard about whether any service should have this turned on by default. If we *do* enable it by default, we should also carefully document how to turn it off for those services if they rely on centrally-managed accounts. I think we can cover this one line: if you do something like that, don't. if you insist, use nscd. And that should be enough. Lennart -- Lennart Poettering, Red Hat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: PrivateDevices=yes and PrivateNetwork=yes For Long-Running Services
On Thu, 2014-03-27 at 22:59 +0100, Lennart Poettering wrote: On Wed, 26.03.14 13:43, Stephen Gallagher (sgall...@redhat.com) wrote: Note that PrivateNetwork=yes should not be used for: 1. Services that actually require network access (with the exception of daemons only needing socket activation) 2. Services which may be used to execute arbitrary user or administrator supplied programs. (see above) 3. Services which might need to resolve non-system user and group names. Since on some setups resolving non-system users might require network access to an LDAP or NIS server, enabling this option on might break resolving of these user names. Note however that system users/groups are always resolvable even without network access. Hence it is safe to enable this option for daemons which just need to resolve their own system user or group name. This may not be a safe statement to make. I personally know of a great many deployments where admins have removed the local accounts for Well, this assumption is built into a lot of software we do, for example all across device management, tmpfiles and suchlike. System users must be resolvable without network, we cannot delay bootup for these components, just because the network isn't up yet... It's OK to if normal users are only resolvable with the network round. And it's OK to sync system user IDs across the network, but they must be resolvable at any time -- they are integral part of the core OS after all. People can use a caching daemon (like sssd?) if they like, to make sure the system users stay in syn across the network, but removing them from /etc/passwed entirely is nothing we ever supported or should support. I mean, it's even OK if people hack things that way, if they want to shoot themselves in the foot, and know what they do. But that really shouldn't stop us from deploying PrivateNetwork=yes, since there is a very easy way out for them: just enable nscd. With nscd enabled the NSS calls will go via the nscd AF_UNIX socket in the fs (which is connectable, regardless of PrivateNetwork=yes), and then the actual query is made from nscd. Or actually, to top that, people who have setups like that, and store their user databases on the network, for example in LDAP, are the ones nscd has been written for in the first place, and hence there's really very little changing for them. But anyway, it's a hack to allow system users to be removed from /etc/passwd. It's already broken if you want to support that, you have to file bugs to udev, tmpfiles and so on. And yuck, I don't even see how that could ever work... We'd need to think very hard about whether any service should have this turned on by default. If we *do* enable it by default, we should also carefully document how to turn it off for those services if they rely on centrally-managed accounts. I think we can cover this one line: if you do something like that, don't. if you insist, use nscd. And that should be enough. It is doable without issues and withut needing nscd with sssd, so I do not think we need to CYA with this line at all. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Heads up: Mesa/LLVM rebase and OpenGTL retirement in F20
2014-03-27 17:40 GMT-03:00 Adam Williamson awill...@redhat.com: On Thu, 2014-03-27 at 16:02 -0400, Adam Jackson wrote: We'd like to update to Mesa 10.1 in Fedora 20, since the cycle is so long before F21 and (among other goodies) it enables OpenGL 3.3 on some newer Radeons. This implies rebasing LLVM 3.4, and that's where it gets a little awkward: the OpenGTL package only works up to LLVM 3.3. However, OpenGTL is dead upstream, and the only thing requiring it in F20 gold - calligra-krita, by way of libQtGTL - has already been updated to Obsolete OpenGTL. As far as I know OpenGTL is the only such package we have requiring LLVM 3.3, so the rest of the rebase should just be a matter of updating to match F21. The following source packages will also be updated for the llvm rebase: dragonegg gambas3 pocl pure python-llvmpy If there are no serious objections I'll try to get this all into testing early next week. If you _do_ happen to be using OpenGTL for something in F20, now would be an excellent time for you to start working on porting it to current LLVM. I can absolutely see the reasons for doing this, but...can it at least go through a fesco rubber stamp? Let's face it, entirely deprecating a library we shipped as part of the gold release seems to be a pretty flagrant violation of the update policy, and really ought to be granted a formal exception at the very least if it's going to go ahead. As a result, we should avoid major updates of packages within a stable release. Updates should aim to fix bugs, and not introduce features, particularly when those features would materially affect the user or developer experience. ABI changes in general are very strongly discouraged https://fedoraproject.org/wiki/Updates_Policy#Stable_Releases Fedora *is* a platform, not just a set of packages, however half-assedly we conform to that vision, so I guess I just feel a bit uncomfortable not at least putting up a few hoops for this to jump through. :) This patch may be useful: https://abf.rosalinux.ru/openmandriva/opengtl/blob/master/opengtl-0.9.18-llvm-3.4.patch -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net Paulo -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Heads up: Mesa/LLVM rebase and OpenGTL retirement in F20
Hi, We'd like to update to Mesa 10.1 in Fedora 20, since the cycle is so long before F21 and (among other goodies) it enables OpenGL 3.3 on some newer Radeons. This implies rebasing LLVM 3.4, and that's where it gets a little awkward: the OpenGTL package only works up to LLVM 3.3. One concern from me is that ghc on ARM uses llvm as its compiler backend. To be honest things are already bad enough for ghc with llvm-3.3 there that I am not sure if they could get much worse with 3.4... ;) though really need to test (3.2 was better). I haven't seen any Haskell build regressions yet though with llvm-3.4 in Rawhide relative to 3.3 at least. (ghc-7.6.3 officially supports only llvm = 3.1, but ghc-7.8, which will be released soon and I am planning to ship it in F21, will support 3.4. Maybe I should add Requires: llvm = 3.4 at that time to ghc.spec for ARM.;) Jens -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Bug 1081385] New: CVE-2013-6393 perl-YAML-LibYAML: libyaml: heap-based buffer overflow when parsing YAML tags [fedora-all]
https://bugzilla.redhat.com/show_bug.cgi?id=1081385 Bug ID: 1081385 Summary: CVE-2013-6393 perl-YAML-LibYAML: libyaml: heap-based buffer overflow when parsing YAML tags [fedora-all] Product: Fedora Version: 20 Component: perl-YAML-LibYAML Keywords: Security, SecurityTracking Severity: medium Priority: medium Assignee: jples...@redhat.com Reporter: mmcal...@redhat.com QA Contact: extras...@fedoraproject.org CC: jples...@redhat.com, p...@city-fan.org, perl-devel@lists.fedoraproject.org Blocks: 1033990 (CVE-2013-6393) This is an automatically created tracking bug! It was created to ensure that one or more security vulnerabilities are fixed in affected versions of Fedora. For comments that are specific to the vulnerability please use bugs filed against the Security Response product referenced in the Blocks field. For more information see: http://fedoraproject.org/wiki/Security/TrackingBugs When creating a Bodhi update request, please use the bodhi submission link noted in the next comment(s). This will include the bug IDs of this tracking bug as well as the relevant top-level CVE bugs. Please also mention the CVE IDs being fixed in the RPM changelog and the Bodhi notes field when available. Please note: this issue affects multiple supported versions of Fedora. Only one tracking bug has been filed; please ensure that it is only closed when all affected versions are fixed. [bug automatically created by: add-tracking-bugs] Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1033990 [Bug 1033990] CVE-2013-6393 libyaml: heap-based buffer overflow when parsing YAML tags -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=W6bjOxzSJua=cc_unsubscribe -- 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 1033990] CVE-2013-6393 libyaml: heap-based buffer overflow when parsing YAML tags
https://bugzilla.redhat.com/show_bug.cgi?id=1033990 Murray McAllister mmcal...@redhat.com changed: What|Removed |Added Depends On||1081385 Depends On||1081386 --- Comment #41 from Murray McAllister mmcal...@redhat.com --- Created perl-YAML-LibYAML tracking bugs for this issue: Affects: fedora-all [bug 1081385] Affects: epel-6 [bug 1081386] Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1081385 [Bug 1081385] CVE-2013-6393 perl-YAML-LibYAML: libyaml: heap-based buffer overflow when parsing YAML tags [fedora-all] https://bugzilla.redhat.com/show_bug.cgi?id=1081386 [Bug 1081386] CVE-2013-6393 perl-YAML-LibYAML: libyaml: heap-based buffer overflow when parsing YAML tags [epel-6] -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=JaLIZHJJVma=cc_unsubscribe -- 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 epel-7 tree: On ppc64: perl-PDL-2.7.0-2.el7.1.ppc64 requires perl(PDL::Slatec) 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
[Bug 995748] perl-Net-Amazon-S3-0.59-1.fc20 does not include s3cl script and manpage
https://bugzilla.redhat.com/show_bug.cgi?id=995748 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Depends On||1081468 Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1081468 [Bug 1081468] Review Request: perl-Term-ProgressBar-Simple - Simpler progress bars -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=5SVeONxfIFa=cc_unsubscribe -- 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-YAML-LibYAML] Add fixes for CVE-2013-6393 and CVE-2014-2525
commit da43da31bb1dba3e2801e062aa179ac8d50aa538
Author: Paul Howarth p...@city-fan.org
Date: Thu Mar 27 13:52:30 2014 +
Add fixes for CVE-2013-6393 and CVE-2014-2525
- Fix LibYAML input sanitization errors (CVE-2014-2525)
- Fix heap-based buffer overflow when parsing YAML tags (CVE-2013-6393)
YAML-LibYAML-0.41-CVE-2013-6393.patch | 177 +
YAML-LibYAML-0.41-CVE-2014-2525.patch | 38 +++
perl-YAML-LibYAML.spec| 14 +++-
3 files changed, 228 insertions(+), 1 deletions(-)
---
diff --git a/YAML-LibYAML-0.41-CVE-2013-6393.patch
b/YAML-LibYAML-0.41-CVE-2013-6393.patch
new file mode 100644
index 000..e914e71
--- /dev/null
+++ b/YAML-LibYAML-0.41-CVE-2013-6393.patch
@@ -0,0 +1,177 @@
+# HG changeset patch
+# User Kirill Simonov x...@resolvent.net
+# Date 1391406104 21600
+# Node ID f859ed1eb757a3562b98a28a8ce69274bfd4b3f2
+# Parent da9bc6f12781a583076c7b60d057df5d7b50f96f
+Guard against overflows in indent and flow_level.
+
+--- LibYAML/scanner.c
LibYAML/scanner.c
+@@ -615,11 +615,11 @@
+ */
+
+ static int
+-yaml_parser_roll_indent(yaml_parser_t *parser, int column,
+-int number, yaml_token_type_t type, yaml_mark_t mark);
++yaml_parser_roll_indent(yaml_parser_t *parser, ptrdiff_t column,
++ptrdiff_t number, yaml_token_type_t type, yaml_mark_t mark);
+
+ static int
+-yaml_parser_unroll_indent(yaml_parser_t *parser, int column);
++yaml_parser_unroll_indent(yaml_parser_t *parser, ptrdiff_t column);
+
+ /*
+ * Token fetchers.
+@@ -1103,7 +1103,7 @@
+ */
+
+ int required = (!parser-flow_level
+- parser-indent == (int)parser-mark.column);
++ parser-indent == (ptrdiff_t)parser-mark.column);
+
+ /*
+ * A simple key is required only when it is the first token in the current
+@@ -1176,6 +1176,9 @@
+
+ /* Increase the flow level. */
+
++if (parser-flow_level == INT_MAX)
++return 0;
++
+ parser-flow_level++;
+
+ return 1;
+@@ -1206,8 +1209,8 @@
+ */
+
+ static int
+-yaml_parser_roll_indent(yaml_parser_t *parser, int column,
+-int number, yaml_token_type_t type, yaml_mark_t mark)
++yaml_parser_roll_indent(yaml_parser_t *parser, ptrdiff_t column,
++ptrdiff_t number, yaml_token_type_t type, yaml_mark_t mark)
+ {
+ yaml_token_t token;
+
+@@ -1226,6 +1229,9 @@
+ if (!PUSH(parser, parser-indents, parser-indent))
+ return 0;
+
++if (column INT_MAX)
++return 0;
++
+ parser-indent = column;
+
+ /* Create a token and insert it into the queue. */
+@@ -1254,7 +1260,7 @@
+
+
+ static int
+-yaml_parser_unroll_indent(yaml_parser_t *parser, int column)
++yaml_parser_unroll_indent(yaml_parser_t *parser, ptrdiff_t column)
+ {
+ yaml_token_t token;
+
+--- LibYAML/yaml_private.h
LibYAML/yaml_private.h
+@@ -7,6 +7,7 @@
+
+ #include assert.h
+ #include limits.h
++#include stddef.h
+
+ /*
+ * Memory management.
+# HG changeset patch
+# User Kirill Simonov x...@resolvent.net
+# Date 1391409843 21600
+# Node ID af3599437a87162554787c52d8b16eab553f537b
+# Parent 0df2fb962294f3a6df1450a3e08c6a0f74f9078c
+Forgot to set the error state.
+
+--- LibYAML/scanner.c
LibYAML/scanner.c
+@@ -1176,8 +1176,10 @@
+
+ /* Increase the flow level. */
+
+-if (parser-flow_level == INT_MAX)
++if (parser-flow_level == INT_MAX) {
++parser-error = YAML_MEMORY_ERROR;
+ return 0;
++}
+
+ parser-flow_level++;
+
+@@ -1229,8 +1231,10 @@
+ if (!PUSH(parser, parser-indents, parser-indent))
+ return 0;
+
+-if (column INT_MAX)
++if (column INT_MAX) {
++parser-error = YAML_MEMORY_ERROR;
+ return 0;
++}
+
+ parser-indent = column;
+
+Description: CVE-2013-6393: yaml_stack_extend: guard against integer overflow
+ This is a hardening patch also from Florian Weimer
+ fwei...@redhat.com. It is not required to fix this CVE however it
+ improves the robustness of the code against future issues by avoiding
+ large node ID's in a central place.
+Origin: https://bugzilla.redhat.com/show_bug.cgi?id=1033990
+Bug-RedHat: https://bugzilla.redhat.com/show_bug.cgi?id=1033990
+Bug-Debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=737076
+Last-Update: 2014-01-29
+---
+# HG changeset patch
+# User Florian Weimer fwei...@redhat.com
+# Date 1389274355 -3600
+# Thu Jan 09 14:32:35 2014 +0100
+# Node ID 034d7a91581ac930e5958683f1a06f41e96d24a2
+# Parent a54d7af707f25dc298a7be60fd152001d2b3035b
+yaml_stack_extend: guard against integer overflow
+
+--- LibYAML/api.c
LIBYAML/api.c
+@@ -117,7 +117,12 @@
+ YAML_DECLARE(int)
+ yaml_stack_extend(void **start, void **top, void **end)
+ {
+-void *new_start = yaml_realloc(*start, ((char *)*end - (char *)*start)*2);
++void *new_start;
++
++if ((char *)*end - (char *)*start = INT_MAX / 2)
++ return 0;
++
++new_start =
[perl-YAML-LibYAML/f20] Add fixes for CVE-2013-6393 and CVE-2014-2525
Summary of changes: da43da3... Add fixes for CVE-2013-6393 and CVE-2014-2525 (*) (*) 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
[Bug 1078083] CVE-2014-2525 libyaml: heap-based buffer overflow when parsing URLs
https://bugzilla.redhat.com/show_bug.cgi?id=1078083 --- Comment #22 from John Eckersberg jecke...@redhat.com --- Can you please create a tracking bug for epel-all as well? -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=myKGdCsLiKa=cc_unsubscribe -- 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-YAML-LibYAML/epel7] (3 commits) ...Add fixes for CVE-2013-6393 and CVE-2014-2525
Summary of changes: 3560fff... Perl 5.18 rebuild (*) 3e843d9... - Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass (*) da43da3... Add fixes for CVE-2013-6393 and CVE-2014-2525 (*) (*) 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-YAML-LibYAML/f19] (3 commits) ...Add fixes for CVE-2013-6393 and CVE-2014-2525
Summary of changes: 3560fff... Perl 5.18 rebuild (*) 3e843d9... - Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass (*) da43da3... Add fixes for CVE-2013-6393 and CVE-2014-2525 (*) (*) 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
Broken dependencies: mojomojo
mojomojo has broken dependencies in the rawhide tree: On x86_64: mojomojo-1.10-1.fc20.noarch requires perl(HTML::FormFu::Element::reCAPTCHA) On i386: mojomojo-1.10-1.fc20.noarch requires perl(HTML::FormFu::Element::reCAPTCHA) On armhfp: mojomojo-1.10-1.fc20.noarch requires perl(HTML::FormFu::Element::reCAPTCHA) 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-Catalyst-Controller-HTML-FormFu
perl-Catalyst-Controller-HTML-FormFu has broken dependencies in the rawhide tree: On x86_64: perl-Catalyst-Controller-HTML-FormFu-0.09004-4.fc20.noarch requires perl(HTML::FormFu::MultiForm) On i386: perl-Catalyst-Controller-HTML-FormFu-0.09004-4.fc20.noarch requires perl(HTML::FormFu::MultiForm) On armhfp: perl-Catalyst-Controller-HTML-FormFu-0.09004-4.fc20.noarch requires perl(HTML::FormFu::MultiForm) 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-Language-Expr
perl-Language-Expr has broken dependencies in the rawhide tree: On x86_64: perl-Language-Expr-0.19-4.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) On i386: perl-Language-Expr-0.19-4.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) On armhfp: perl-Language-Expr-0.19-4.fc19.noarch requires perl(:MODULE_COMPAT_5.16.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-GnuPG-Interface
perl-GnuPG-Interface has broken dependencies in the rawhide tree: On x86_64: perl-GnuPG-Interface-0.50-1.fc21.noarch requires perl(MooX::late) perl-GnuPG-Interface-0.50-1.fc21.noarch requires perl(MooX::HandlesVia) On i386: perl-GnuPG-Interface-0.50-1.fc21.noarch requires perl(MooX::late) perl-GnuPG-Interface-0.50-1.fc21.noarch requires perl(MooX::HandlesVia) On armhfp: perl-GnuPG-Interface-0.50-1.fc21.noarch requires perl(MooX::late) perl-GnuPG-Interface-0.50-1.fc21.noarch requires perl(MooX::HandlesVia) 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
[Bug 1081559] perl-YAML-LibYAML bundles yaml-1.0.4
https://bugzilla.redhat.com/show_bug.cgi?id=1081559 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Summary|perl-YAML-LibYAML bundler |perl-YAML-LibYAML bundles |yaml-1.0.4 |yaml-1.0.4 -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=bEE9XGEtUta=cc_unsubscribe -- 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 1081559] perl-YAML-LibYAML bundler yaml-1.0.4
https://bugzilla.redhat.com/show_bug.cgi?id=1081559 Petr Pisar ppi...@redhat.com changed: What|Removed |Added See Also||https://bugzilla.redhat.com ||/show_bug.cgi?id=498203 -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=LzgrwKDy9ga=cc_unsubscribe -- 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 1081559] New: perl-YAML-LibYAML bundler yaml-1.0.4
https://bugzilla.redhat.com/show_bug.cgi?id=1081559 Bug ID: 1081559 Summary: perl-YAML-LibYAML bundler yaml-1.0.4 Product: Fedora Version: rawhide Component: perl-YAML-LibYAML Severity: high Assignee: jples...@redhat.com Reporter: ppi...@redhat.com QA Contact: extras...@fedoraproject.org CC: jples...@redhat.com, p...@city-fan.org, perl-devel@lists.fedoraproject.org perl-YAML-LibYAML bundles yaml sources. yaml-1.0.4 with two small modifications in emmiter.c and scanner.c. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=NQ1kUHtESna=cc_unsubscribe -- 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 Term-ProgressBar-Quiet-0.31.tar.gz uploaded to lookaside cache by ppisar
A file has been added to the lookaside cache for perl-Term-ProgressBar-Quiet: 2ed5b6ac5d480a14ff3233a58987a2e4 Term-ProgressBar-Quiet-0.31.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-Term-ProgressBar-Quiet] Import
commit 1ceff8e6ca1ea261e7ae31e572255fbb861dbb60
Author: Petr Písař ppi...@redhat.com
Date: Thu Mar 27 16:12:27 2014 +0100
Import
.gitignore |1 +
perl-Term-ProgressBar-Quiet.spec | 53 ++
sources |1 +
3 files changed, 55 insertions(+), 0 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index e69de29..05c273b 100644
--- a/.gitignore
+++ b/.gitignore
@@ -0,0 +1 @@
+/Term-ProgressBar-Quiet-0.31.tar.gz
diff --git a/perl-Term-ProgressBar-Quiet.spec b/perl-Term-ProgressBar-Quiet.spec
new file mode 100644
index 000..3ab9256
--- /dev/null
+++ b/perl-Term-ProgressBar-Quiet.spec
@@ -0,0 +1,53 @@
+Name: perl-Term-ProgressBar-Quiet
+Version:0.31
+Release:1%{?dist}
+Summary:Provide a progress meter if run interactively
+License:GPL+ or Artistic
+Group: Development/Libraries
+URL:http://search.cpan.org/dist/Term-ProgressBar-Quiet/
+Source0:
http://www.cpan.org/authors/id/L/LB/LBROCARD/Term-ProgressBar-Quiet-%{version}.tar.gz
+BuildArch: noarch
+BuildRequires: perl
+BuildRequires: perl(ExtUtils::MakeMaker)
+BuildRequires: perl(strict)
+BuildRequires: perl(warnings)
+# Run-time:
+BuildRequires: perl(IO::Interactive)
+BuildRequires: perl(Term::ProgressBar)
+BuildRequires: perl(Test::MockObject)
+# Tests:
+BuildRequires: perl(lib)
+BuildRequires: perl(Test::More)
+# Optional tests:
+BuildRequires: perl(Test::Pod) = 1.14
+Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
+
+%description
+Term::ProgressBar is a wonderful module for showing progress bars on the
+terminal. This module acts very much like that module when it is run
+interactively. However, when it is not run interactively (for example,
+as a cron job) then it does not show the progress bar.
+
+%prep
+%setup -q -n Term-ProgressBar-Quiet-%{version}
+
+%build
+perl Makefile.PL INSTALLDIRS=vendor
+make %{?_smp_mflags}
+
+%install
+make pure_install DESTDIR=$RPM_BUILD_ROOT
+find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
+%{_fixperms} $RPM_BUILD_ROOT/*
+
+%check
+make test
+
+%files
+%doc CHANGES README
+%{perl_vendorlib}/*
+%{_mandir}/man3/*
+
+%changelog
+* Thu Mar 27 2014 Petr Pisar ppi...@redhat.com 0.31-1
+- Specfile autogenerated by cpanspec 1.78.
diff --git a/sources b/sources
index e69de29..4266a39 100644
--- a/sources
+++ b/sources
@@ -0,0 +1 @@
+2ed5b6ac5d480a14ff3233a58987a2e4 Term-ProgressBar-Quiet-0.31.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-YAML-LibYAML/el6] Add fixes for CVE-2013-6393 and CVE-2014-2525
commit 2e17fd3f16300ddd36d5bf1664bd6eee50a8494e
Author: Paul Howarth p...@city-fan.org
Date: Thu Mar 27 13:52:30 2014 +
Add fixes for CVE-2013-6393 and CVE-2014-2525
- Fix LibYAML input sanitization errors (CVE-2014-2525)
- Fix heap-based buffer overflow when parsing YAML tags (CVE-2013-6393)
YAML-LibYAML-0.38-CVE-2013-6393.patch | 105 +
YAML-LibYAML-0.38-CVE-2014-2525.patch | 38
perl-YAML-LibYAML.spec| 16 +-
3 files changed, 157 insertions(+), 2 deletions(-)
---
diff --git a/YAML-LibYAML-0.38-CVE-2013-6393.patch
b/YAML-LibYAML-0.38-CVE-2013-6393.patch
new file mode 100644
index 000..61186cb
--- /dev/null
+++ b/YAML-LibYAML-0.38-CVE-2013-6393.patch
@@ -0,0 +1,105 @@
+--- LibYAML/api.c
LibYAML/api.c
+@@ -117,7 +117,12 @@ yaml_string_join(
+ YAML_DECLARE(int)
+ yaml_stack_extend(void **start, void **top, void **end)
+ {
+-void *new_start = yaml_realloc(*start, ((char *)*end - (char *)*start)*2);
++void *new_start;
++
++if ((char *)*end - (char *)*start = INT_MAX / 2)
++ return 0;
++
++new_start = yaml_realloc(*start, ((char *)*end - (char *)*start)*2);
+
+ if (!new_start) return 0;
+
+--- LibYAML/scanner.c
LibYAML/scanner.c
+@@ -615,11 +615,11 @@ yaml_parser_decrease_flow_level(yaml_par
+ */
+
+ static int
+-yaml_parser_roll_indent(yaml_parser_t *parser, int column,
+-int number, yaml_token_type_t type, yaml_mark_t mark);
++yaml_parser_roll_indent(yaml_parser_t *parser, ptrdiff_t column,
++ptrdiff_t number, yaml_token_type_t type, yaml_mark_t mark);
+
+ static int
+-yaml_parser_unroll_indent(yaml_parser_t *parser, int column);
++yaml_parser_unroll_indent(yaml_parser_t *parser, ptrdiff_t column);
+
+ /*
+ * Token fetchers.
+@@ -1103,7 +1103,7 @@ yaml_parser_save_simple_key(yaml_parser_
+ */
+
+ int required = (!parser-flow_level
+- parser-indent == (int)parser-mark.column);
++ parser-indent == (ptrdiff_t)parser-mark.column);
+
+ /*
+ * A simple key is required only when it is the first token in the current
+@@ -1174,6 +1174,11 @@ yaml_parser_increase_flow_level(yaml_par
+
+ /* Increase the flow level. */
+
++if (parser-flow_level == INT_MAX) {
++parser-error = YAML_MEMORY_ERROR;
++return 0;
++}
++
+ parser-flow_level++;
+
+ return 1;
+@@ -1204,8 +1209,8 @@ yaml_parser_decrease_flow_level(yaml_par
+ */
+
+ static int
+-yaml_parser_roll_indent(yaml_parser_t *parser, int column,
+-int number, yaml_token_type_t type, yaml_mark_t mark)
++yaml_parser_roll_indent(yaml_parser_t *parser, ptrdiff_t column,
++ptrdiff_t number, yaml_token_type_t type, yaml_mark_t mark)
+ {
+ yaml_token_t token;
+
+@@ -1224,6 +1229,11 @@ yaml_parser_roll_indent(yaml_parser_t *p
+ if (!PUSH(parser, parser-indents, parser-indent))
+ return 0;
+
++if (column INT_MAX) {
++parser-error = YAML_MEMORY_ERROR;
++return 0;
++}
++
+ parser-indent = column;
+
+ /* Create a token and insert it into the queue. */
+@@ -1252,7 +1262,7 @@ yaml_parser_roll_indent(yaml_parser_t *p
+
+
+ static int
+-yaml_parser_unroll_indent(yaml_parser_t *parser, int column)
++yaml_parser_unroll_indent(yaml_parser_t *parser, ptrdiff_t column)
+ {
+ yaml_token_t token;
+
+@@ -2572,7 +2582,7 @@ yaml_parser_scan_tag_uri(yaml_parser_t *
+
+ /* Resize the string to include the head. */
+
+-while (string.end - string.start = (int)length) {
++while ((size_t)(string.end - string.start) = length) {
+ if (!yaml_string_extend(string.start, string.pointer, string.end))
{
+ parser-error = YAML_MEMORY_ERROR;
+ goto error;
+--- LibYAML/yaml_private.h
LibYAML/yaml_private.h
+@@ -7,6 +7,7 @@
+
+ #include assert.h
+ #include limits.h
++#include stddef.h
+
+ /*
+ * Memory management.
diff --git a/YAML-LibYAML-0.38-CVE-2014-2525.patch
b/YAML-LibYAML-0.38-CVE-2014-2525.patch
new file mode 100644
index 000..8dfa5b0
--- /dev/null
+++ b/YAML-LibYAML-0.38-CVE-2014-2525.patch
@@ -0,0 +1,38 @@
+Description: CVE-2014-2525: Fixes heap overflow in yaml_parser_scan_uri_escapes
+ The heap overflow is caused by not properly expanding a string before
+ writing to it in function yaml_parser_scan_uri_escapes in scanner.c.
+
+Origin: backport,
https://bitbucket.org/xi/libyaml/commits/bce8b60f0b9af69fa9fab3093d0a41ba243de048
+Author: Salvatore Bonaccorso car...@debian.org
+Last-Update: 2014-03-20
+Applied-Upstream: 0.1.6
+
+--- LibYAML/scanner.c
LibYAML/scanner.c
+@@ -2617,6 +2617,9 @@ yaml_parser_scan_tag_uri(yaml_parser_t *
+ /* Check if it is a URI-escape sequence. */
+
+ if (CHECK(parser-buffer, '%')) {
++if (!STRING_EXTEND(parser, string))
++goto error;
++
+ if (!yaml_parser_scan_uri_escapes(parser,
+
File MooX-0.101.tar.gz uploaded to lookaside cache by corsepiu
A file has been added to the lookaside cache for perl-MooX: c35d73fc38aceb7edec1b5560abe4e2d MooX-0.101.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-YAML-LibYAML] Created tag perl-YAML-LibYAML-0.38-4.el6
The lightweight tag 'perl-YAML-LibYAML-0.38-4.el6' was created pointing to: 2e17fd3... Add fixes for CVE-2013-6393 and CVE-2014-2525 -- 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-YAML-LibYAML] Created tag perl-YAML-LibYAML-0.41-4.el7
The lightweight tag 'perl-YAML-LibYAML-0.41-4.el7' was created pointing to: da43da3... Add fixes for CVE-2013-6393 and CVE-2014-2525 -- 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-YAML-LibYAML] Created tag perl-YAML-LibYAML-0.41-4.fc21
The lightweight tag 'perl-YAML-LibYAML-0.41-4.fc21' was created pointing to: da43da3... Add fixes for CVE-2013-6393 and CVE-2014-2525 -- 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-YAML-LibYAML] Created tag perl-YAML-LibYAML-0.41-4.fc19
The lightweight tag 'perl-YAML-LibYAML-0.41-4.fc19' was created pointing to: da43da3... Add fixes for CVE-2013-6393 and CVE-2014-2525 -- 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-YAML-LibYAML] Created tag perl-YAML-LibYAML-0.41-4.fc20
The lightweight tag 'perl-YAML-LibYAML-0.41-4.fc20' was created pointing to: da43da3... Add fixes for CVE-2013-6393 and CVE-2014-2525 -- 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-MooX/f20] Initial import.
Summary of changes: b998375... Initial import. (*) (*) 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-MooX/f19] Initial import.
Summary of changes: b998375... Initial import. (*) (*) 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-Term-ProgressBar-Quiet/f20] Import
Summary of changes: 1ceff8e... Import (*) (*) 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
[Bug 1081382] CVE-2014-2525 perl-YAML-LibYAML: libyaml: heap-based buffer overflow when parsing URLs [fedora-all]
https://bugzilla.redhat.com/show_bug.cgi?id=1081382 --- Comment #2 from Fedora Update System upda...@fedoraproject.org --- perl-YAML-LibYAML-0.41-4.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/perl-YAML-LibYAML-0.41-4.fc19 -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=U5lRpNoqxBa=cc_unsubscribe -- 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 1081385] CVE-2013-6393 perl-YAML-LibYAML: libyaml: heap-based buffer overflow when parsing YAML tags [fedora-all]
https://bugzilla.redhat.com/show_bug.cgi?id=1081385 --- Comment #2 from Fedora Update System upda...@fedoraproject.org --- perl-YAML-LibYAML-0.41-4.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/perl-YAML-LibYAML-0.41-4.fc19 -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=A8nlS6UTFRa=cc_unsubscribe -- 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 1081382] CVE-2014-2525 perl-YAML-LibYAML: libyaml: heap-based buffer overflow when parsing URLs [fedora-all]
https://bugzilla.redhat.com/show_bug.cgi?id=1081382 --- Comment #3 from Fedora Update System upda...@fedoraproject.org --- perl-YAML-LibYAML-0.41-4.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/perl-YAML-LibYAML-0.41-4.fc20 -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=dOA7g9ALeda=cc_unsubscribe -- 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 1081385] CVE-2013-6393 perl-YAML-LibYAML: libyaml: heap-based buffer overflow when parsing YAML tags [fedora-all]
https://bugzilla.redhat.com/show_bug.cgi?id=1081385 --- Comment #3 from Fedora Update System upda...@fedoraproject.org --- perl-YAML-LibYAML-0.41-4.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/perl-YAML-LibYAML-0.41-4.fc20 -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=wHpJJlgX39a=cc_unsubscribe -- 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-Net-Amazon-S3] Enable s3cl tool
commit 94ce32ee4e8d6200b94b89badcfcd41214cd
Author: Petr Písař ppi...@redhat.com
Date: Thu Mar 27 13:48:11 2014 +0100
Enable s3cl tool
And modernize spec files etc.
.rpmlint|2 +
perl-Net-Amazon-S3.spec | 152 ---
2 files changed, 40 insertions(+), 114 deletions(-)
---
diff --git a/.rpmlint b/.rpmlint
new file mode 100644
index 000..7d0c218
--- /dev/null
+++ b/.rpmlint
@@ -0,0 +1,2 @@
+from Config import *
+addFilter(spelling-error .* (amazonaws|http|scalable));
diff --git a/perl-Net-Amazon-S3.spec b/perl-Net-Amazon-S3.spec
index b32ede4..c76e3ba 100644
--- a/perl-Net-Amazon-S3.spec
+++ b/perl-Net-Amazon-S3.spec
@@ -1,77 +1,58 @@
-# Noarch packages don't generate any debuginfo
-%global debug_package %{nil}
-
-Summary: Use the Amazon Simple Storage Service (S3)
-Name: perl-Net-Amazon-S3
-Version: 0.59
-Release: 1%{?dist}
-License: GPL+ or Artistic
-Group: Development/Libraries
-URL: http://search.cpan.org/dist/Net-Amazon-S3/
-Source0:
http://search.cpan.org/CPAN/authors/id/P/PF/PFIG/Net-Amazon-S3-%{version}.tar.gz
-BuildRoot: %(mktemp -ud %{_tmppath}/%{name}-%{version}-%{release}-XX)
-
-BuildArch: noarch
-# Module Build
+Summary:Use the Amazon Simple Storage Service (S3)
+Name: perl-Net-Amazon-S3
+Version:0.59
+Release:2%{?dist}
+License:GPL+ or Artistic
+Group: Development/Libraries
+URL:http://search.cpan.org/dist/Net-Amazon-S3/
+Source0:
http://search.cpan.org/CPAN/authors/id/P/PF/PFIG/Net-Amazon-S3-%{version}.tar.gz
+BuildArch: noarch
BuildRequires: perl
BuildRequires: perl(ExtUtils::MakeMaker) = 6.30
-# Module Runtime
+BuildRequires: perl(strict)
+BuildRequires: perl(warnings)
+# Run-time:
BuildRequires: perl(Carp)
BuildRequires: perl(Data::Stream::Bulk::Callback)
BuildRequires: perl(DateTime::Format::HTTP)
BuildRequires: perl(Digest::HMAC_SHA1)
BuildRequires: perl(Digest::MD5)
BuildRequires: perl(Digest::MD5::File)
+BuildRequires: perl(File::Find::Rule)
BuildRequires: perl(File::stat)
+BuildRequires: perl(Getopt::Long)
BuildRequires: perl(HTTP::Date)
BuildRequires: perl(HTTP::Status)
BuildRequires: perl(IO::File) = 1.14
BuildRequires: perl(LWP::UserAgent::Determined)
BuildRequires: perl(MIME::Base64)
+BuildRequires: perl(MIME::Types)
BuildRequires: perl(Moose) = 0.85
BuildRequires: perl(Moose::Util::TypeConstraints)
BuildRequires: perl(MooseX::StrictConstructor) = 0.16
BuildRequires: perl(MooseX::Types::DateTime::MoreCoercions) = 0.07
+BuildRequires: perl(Path::Class)
+BuildRequires: perl(Pod::Usage)
BuildRequires: perl(Regexp::Common)
+# Term::Encoding is optional
+BuildRequires: perl(Term::ProgressBar::Simple)
BuildRequires: perl(URI)
BuildRequires: perl(URI::Escape)
BuildRequires: perl(URI::QueryParam)
BuildRequires: perl(XML::LibXML)
BuildRequires: perl(XML::LibXML::XPathContext)
-# Requirements of s3cl (some not yet in Fedora, so we exclude the script for
now)
-BuildRequires: perl(File::Find::Rule)
-BuildRequires: perl(Getopt::Long)
-BuildRequires: perl(MIME::Types)
-BuildRequires: perl(Path::Class)
-BuildRequires: perl(Pod::Usage)
-BuildRequires: perl(strict)
-#BuildRequires: perl(Term::Encoding)
-#BuildRequires: perl(Term::ProgressBar::Simple)
-BuildRequires: perl(warnings)
-# Test Suite
+# Tests:
+# English not used
BuildRequires: perl(File::Find)
BuildRequires: perl(File::Temp)
+BuildRequires: perl(lib)
BuildRequires: perl(LWP::Simple)
BuildRequires: perl(Test::Exception)
BuildRequires: perl(Test::More)
BuildRequires: perl(vars)
-# Release Tests
-# CHANGES file should be called Changes before t/release-cpan-changes.t can
work
-#BuildRequires: perl(Test::CPAN::Changes)
-BuildRequires: perl(Test::CPAN::Meta)
-BuildRequires: perl(Test::CPAN::Meta::JSON)
-BuildRequires: perl(Test::DistManifest)
-BuildRequires: perl(Test::MinimumVersion)
-BuildRequires: perl(Test::Mojibake)
-BuildRequires: perl(Test::NoTabs)
-BuildRequires: perl(Test::Pod) = 1.41
-BuildRequires: perl(Test::Portability::Files)
-BuildRequires: perl(Test::Synopsis)
-BuildRequires: perl(Test::Vars)
-BuildRequires: perl(Test::Version)
-# Runtime
-Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo $version))
-
+# Optional tests:
+BuildRequires: perl(Test::Script) = 1.05
+Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
%description
This module provides a Perlish interface to Amazon S3. From the
@@ -84,96 +65,39 @@ inexpensive data storage infrastructure that Amazon uses to
run its own
global network of web sites. The service aims to maximize benefits of
scale and to pass those benefits on to developers.
-To find out more about S3, please visit: http://s3.amazonaws.com/
+To find out more about S3, please visit http://s3.amazonaws.com/.
%prep
%setup -q -n Net-Amazon-S3-%{version}
-
# Get rid of unnecessary exec bits
-find lib -name '*.pm' -exec chmod -c -x {} ';'
-
+find lib -name '*.pm' -exec chmod -c -x {} +
+# Fix
[perl-Net-Amazon-S3/f20] Enable s3cl tool
Summary of changes: 94ce32e... Enable s3cl tool (*) (*) 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
[Bug 995748] perl-Net-Amazon-S3-0.59-1.fc20 does not include s3cl script and manpage
https://bugzilla.redhat.com/show_bug.cgi?id=995748 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|NEW |MODIFIED Fixed In Version||perl-Net-Amazon-S3-0.59-2.f ||c21 -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=H26krYa4jKa=cc_unsubscribe -- 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 1064271] perl-Net-SSLeay tests failing on s390(x) with glibc-2.18.90-21.fc21
https://bugzilla.redhat.com/show_bug.cgi?id=1064271 --- Comment #21 from Dan Horák d...@danny.cz --- reduced reproducer - install F-20 - update glibc from http://fedora.danny.cz/s390/glibc-2.18.90-20.fc21.dh.1/ - it is glibc-2.18.90-20.fc21 + commit 93a45ff1 - rpmbuild --rebuild http://fedora.danny.cz/s390/perl-Net-SSLeay-1.58-1.fc21.src.rpm for every failed test following info appears in kernel log: [ 6672.505145] User process fault: interruption code 0x6003B in SSLeay.so[3fff665+89000] [ 6672.505155] failing address: 0 [ 6672.505159] CPU: 0 PID: 16420 Comm: perl Not tainted 3.13.6-200.fc20.s390x #1 [ 6672.505162] task: 72333c98 ti: 5859c000 task.ti: 5859c000 [ 6672.505176] User PSW : 070500018000 03fff66b682c (0x3fff66b682c) [ 6672.505178]R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:1 AS:0 CC:0 PM:0 EA:3 User GPRS: 88af88e8 887cc010 [ 6672.505185]03fffcedc360 0001 0020 03fff66db0e8 [ 6672.505188] 0001 88aca5a8 03fffd1ed3a0 [ 6672.505192]03fffcebb000 03fff66ceff0 03fff66b6826 03852bd8 [ 6672.505202] User Code: 03fff66b681a: e320b016llgf %r2,0(%r11) 03fff66b6820: c0e5fffd273c brasl %r14,3fff665b698 #03fff66b6826: e31026b80004 lg %r1,1720(%r2) 03fff66b682c: e3101014 lg %r1,16(%r1) 03fff66b6832: e3201002 ltg %r2,0(%r1) 03fff66b6838: e320b016 llgf%r2,0(%r11) 03fff66b683e: a78402ed brc 8,3fff66b6e18 03fff66b6842: c0e5fffd272b brasl %r14,3fff665b698 [ 6672.505324] Last Breaking-Event-Address: [ 6672.505328] [03fffcecf64e] 0x3fffcecf64e -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=IZYuDYNbLHa=cc_unsubscribe -- 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 995748] perl-Net-Amazon-S3-0.59-1.fc20 does not include s3cl script and manpage
https://bugzilla.redhat.com/show_bug.cgi?id=995748 --- Comment #2 from Fedora Update System upda...@fedoraproject.org --- perl-IO-Interactive-0.0.6-1.fc20, perl-Term-ProgressBar-Simple-0.03-1.fc20, perl-Term-ProgressBar-Quiet-0.31-1.fc20, perl-Net-Amazon-S3-0.59-2.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/perl-Net-Amazon-S3-0.59-2.fc20,perl-Term-ProgressBar-Simple-0.03-1.fc20,perl-IO-Interactive-0.0.6-1.fc20,perl-Term-ProgressBar-Quiet-0.31-1.fc20 -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=6b9CyZlB2Ha=cc_unsubscribe -- 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
[pkgdb] perl-Module-Install-GithubMeta ownership changed
Package perl-Module-Install-GithubMeta in Fedora EPEL 7 is now owned by pghmcfc To make changes to this package see: https://admin.fedoraproject.org/pkgdb/acls/name/perl-Module-Install-GithubMeta -- 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
[pkgdb] perl-Module-Install-AutoLicense ownership changed
Package perl-Module-Install-AutoLicense in Fedora EPEL 7 is now owned by pghmcfc To make changes to this package see: https://admin.fedoraproject.org/pkgdb/acls/name/perl-Module-Install-AutoLicense -- 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
[pkgdb] perl-Module-Install-ReadmeFromPod ownership changed
Package perl-Module-Install-ReadmeFromPod in Fedora EPEL 7 is now owned by pghmcfc To make changes to this package see: https://admin.fedoraproject.org/pkgdb/acls/name/perl-Module-Install-ReadmeFromPod -- 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 MooseX-Types-Stringlike-0.002.tar.gz uploaded to lookaside cache by pghmcfc
A file has been added to the lookaside cache for perl-MooseX-Types-Stringlike: cc9113b5dfb29189f6383da2b55ef61d MooseX-Types-Stringlike-0.002.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-MooseX-Types-Stringlike] Initial import (perl-MooseX-Types-Stringlike-0.002-1)
commit bf41294b1fbf2095fdfa33473820de56ba9013a1
Author: Paul Howarth p...@city-fan.org
Date: Thu Mar 27 19:10:47 2014 +
Initial import (perl-MooseX-Types-Stringlike-0.002-1)
This module provides a more general version of the Str type. If coercions
are
enabled, it will accept objects that overload stringification and coerces
them
into strings.
.gitignore|1 +
perl-MooseX-Types-Stringlike.spec | 56 +
sources |1 +
3 files changed, 58 insertions(+), 0 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index e69de29..6ba62fc 100644
--- a/.gitignore
+++ b/.gitignore
@@ -0,0 +1 @@
+/MooseX-Types-Stringlike-[0-9.]*.tar.gz
diff --git a/perl-MooseX-Types-Stringlike.spec
b/perl-MooseX-Types-Stringlike.spec
new file mode 100644
index 000..57a509e
--- /dev/null
+++ b/perl-MooseX-Types-Stringlike.spec
@@ -0,0 +1,56 @@
+Name: perl-MooseX-Types-Stringlike
+Summary: Moose type constraints for strings or string-like objects
+Version: 0.002
+Release: 1%{?dist}
+License: ASL 2.0
+URL: http://search.cpan.org/dist/MooseX-Types-Stringlike/
+Source0:
http://search.cpan.org/CPAN/authors/id/D/DA/DAGOLDEN/MooseX-Types-Stringlike-%{version}.tar.gz
+BuildArch: noarch
+# Module Build
+BuildRequires: perl
+BuildRequires: perl(ExtUtils::MakeMaker) = 6.17
+# Module Runtime
+BuildRequires: perl(MooseX::Types)
+BuildRequires: perl(MooseX::Types::Moose)
+BuildRequires: perl(overload)
+BuildRequires: perl(strict)
+BuildRequires: perl(warnings)
+# Test Suite
+BuildRequires: perl(File::Spec::Functions)
+BuildRequires: perl(List::Util)
+BuildRequires: perl(Moose)
+BuildRequires: perl(Test::More) = 0.96
+# Optional Test Requirements
+BuildRequires: perl(CPAN::Meta)
+BuildRequires: perl(CPAN::Meta::Requirements)
+# Runtime
+Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
+
+%description
+This module provides a more general version of the Str type. If coercions are
+enabled, it will accept objects that overload stringification and coerces them
+into strings.
+
+%prep
+%setup -q -n MooseX-Types-Stringlike-%{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 {} ';'
+%{_fixperms} %{buildroot}
+
+%check
+make test
+
+%files
+%doc Changes CONTRIBUTING LICENSE README
+%{perl_vendorlib}/MooseX/
+%{_mandir}/man3/MooseX::Types::Stringlike.3*
+
+%changelog
+* Thu Mar 27 2014 Paul Howarth p...@city-fan.org - 0.002-1
+- Initial RPM version
diff --git a/sources b/sources
index e69de29..297e8a5 100644
--- a/sources
+++ b/sources
@@ -0,0 +1 @@
+cc9113b5dfb29189f6383da2b55ef61d MooseX-Types-Stringlike-0.002.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-Module-Install-GithubMeta/epel7] (3 commits) ...0.26 bump
Summary of changes: 4e92866... Perl 5.18 rebuild (*) 1492d70... 0.24 bump (*) eb77dff... 0.26 bump (*) (*) 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-Module-Install-GithubMeta] Created tag perl-Module-Install-GithubMeta-0.26-1.el7
The lightweight tag 'perl-Module-Install-GithubMeta-0.26-1.el7' was created pointing to: eb77dff... 0.26 bump -- 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-MooseX-Types-Stringlike/epel7] Initial import (perl-MooseX-Types-Stringlike-0.002-1)
Summary of changes: bf41294... Initial import (perl-MooseX-Types-Stringlike-0.002-1) (*) (*) 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-Module-Install-AutoLicense] Created tag perl-Module-Install-AutoLicense-0.08-4.el7
The lightweight tag 'perl-Module-Install-AutoLicense-0.08-4.el7' was created pointing to: 7ab6f54... - Rebuilt for https://fedoraproject.org/wiki/Fedora_19_Mass -- 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-MooseX-Types-Stringlike/f20] Initial import (perl-MooseX-Types-Stringlike-0.002-1)
Summary of changes: bf41294... Initial import (perl-MooseX-Types-Stringlike-0.002-1) (*) (*) 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-Module-Install-ReadmeFromPod/epel7] (3 commits) ...0.22 bump
Summary of changes: 85236ad... - Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass (*) c1a039e... Perl 5.18 rebuild (*) f0b9ca3... 0.22 bump (*) (*) 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-Module-Install-ReadmeFromPod] Created tag perl-Module-Install-ReadmeFromPod-0.22-1.el7
The lightweight tag 'perl-Module-Install-ReadmeFromPod-0.22-1.el7' was created pointing to: f0b9ca3... 0.22 bump -- 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-Unicode-UTF8/epel7] Update to 0.60
Summary of changes: c43958d... Update to 0.60 (*) (*) 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-MooseX-Types-Stringlike/f19] Initial import (perl-MooseX-Types-Stringlike-0.002-1)
Summary of changes: bf41294... Initial import (perl-MooseX-Types-Stringlike-0.002-1) (*) (*) 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-Unicode-UTF8] Created tag perl-Unicode-UTF8-0.60-1.el7
The lightweight tag 'perl-Unicode-UTF8-0.60-1.el7' was created pointing to: c43958d... Update to 0.60 -- 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-Path-Tiny/epel7] (14 commits) ...Update to 0.052
Summary of changes: 903ae30... Update to 0.032 (*) 377cfde... Update to 0.033 (*) 98b5658... Update to 0.034 (*) f7b7c3d... Update to 0.035 (*) d7330cf... Update to 0.037 (*) 803eaaa... Update to 0.038 (*) 201e3e3... Update to 0.040 (*) 6f37b27... Update to 0.041 (*) b895f8d... Update to 0.042 (*) 8356598... Update to 0.043 (*) 88fced6... Update to 0.044 (*) b00bff7... Update to 0.049 (*) 9ac1162... Update to 0.051 (*) 3487eea... Update to 0.052 (*) (*) 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
[Bug 1055297] perl-Rose-DB-Object-0.811 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1055297 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #5 from Fedora Update System upda...@fedoraproject.org --- Package perl-Rose-DB-Object-0.811-1.el6: * should fix your issue, * was pushed to the Fedora EPEL 6 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=epel-testing perl-Rose-DB-Object-0.811-1.el6' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0973/perl-Rose-DB-Object-0.811-1.el6 then log in and leave karma (feedback). -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=R4FpCbiLCEa=cc_unsubscribe -- 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 1064271] perl-Net-SSLeay tests failing on s390(x) with glibc-2.18.90-21.fc21
https://bugzilla.redhat.com/show_bug.cgi?id=1064271 --- Comment #22 from Carlos O'Donell codon...@redhat.com --- (In reply to Dan Horák from comment #20) and commit 93a45ff1ca6d459618bb0cf93580c4b2809a4b61 Author: Andreas Krebbel kreb...@linux.vnet.ibm.com Date: Tue Jan 7 09:36:31 2014 +0100 S/390: Make jmp_buf extendible. is the problem ... I've contacted Andreas upstream and asked him for help looking into this since he is the author of the patch. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=fSZy67uKnZa=cc_unsubscribe -- 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 1078083] CVE-2014-2525 libyaml: heap-based buffer overflow when parsing URLs
https://bugzilla.redhat.com/show_bug.cgi?id=1078083 Murray McAllister mmcal...@redhat.com changed: What|Removed |Added Depends On||1081856 --- Comment #23 from Murray McAllister mmcal...@redhat.com --- Created libyaml tracking bugs for this issue: Affects: epel-all [bug 1081856] Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1081856 [Bug 1081856] CVE-2014-2525 libyaml: heap-based buffer overflow when parsing URLs [epel-all] -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=Izp1yAhq3Ua=cc_unsubscribe -- 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 1078083] CVE-2014-2525 libyaml: heap-based buffer overflow when parsing URLs
https://bugzilla.redhat.com/show_bug.cgi?id=1078083 --- Comment #24 from Murray McAllister mmcal...@redhat.com --- (In reply to John Eckersberg from comment #22) Can you please create a tracking bug for epel-all as well? Done. Sorry about that! -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=DBuyg1kaYza=cc_unsubscribe -- 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
[389-devel] please review: Ticket 47655 - Improve import logging and abort handling
https://fedorahosted.org/389/ticket/47655 https://fedorahosted.org/389/attachment/ticket/47655/0001-Ticket-47655-Improve-import-logging-and-abort-proces.patch -- Mark Reynolds 389 Development Team Red Hat, Inc mreyno...@redhat.com -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
[389-devel] please review: Ticket 47756 - Improve import logging and abort handling
Had the wrong ticket number https://fedorahosted.org/389/ticket/47756 https://fedorahosted.org/389/attachment/ticket/47756/0001-Ticket-47756-Improve-import-logging-and-abort-proces.patch -- Mark Reynolds 389 Development Team Red Hat, Inc mreyno...@redhat.com -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
