EPEL group creation requests.
With cinnamon and mate being added for epel7, how would one go about requesting that groups be created for them, similar to the xfce group? -- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77 ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: repo XML file schemas
On 03/27/2014 06:54 PM, Aaron Gray wrote: 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 ! These are just unique strings, you are not supposed to use these URIs to fetch data. See this discussion of the similar problem with DTD URIs: http://www.w3.org/blog/systeam/2008/02/08/w3c_s_excessive_dtd_traffic/ If you find any software that fetches these resources by default, please report it. -- Florian Weimer / Red Hat Product Security Team -- 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: repo XML file schemas
On 2014-03-27, Aaron Gray aaronngray.li...@gmail.com wrote: 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 ! XML name space URI is just an identifier. There does not have to be any document or a service reachable. Even the domain name does not have to exist. That does not mean that the format (e.g. as an XML Schema) should no be somewhere documented. -- Petr -- 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
- Original Message - 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 It should be. (or used by anyone?), It's used by anyone who needs ObexPush and ObexFTP targets for their phones. It's also natively integrated in GNOME's Sharing settings, or needs an easy way to share files between machines. but maybe we could finally really solve https://bugzilla.redhat.com/show_bug.cgi?id=235682, while we are at it. :) It's still smaller than pulling in perl, which some packages seem to do willy-nilly. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
EPEL epel beta report: 20140328 changes
Compose started at Fri Mar 28 08:15:03 UTC 2014 Broken deps for x86_64 -- 2ping-2.0-2.el7.noarch requires perl(Digest::CRC) RemoteBox-1.7-1.el7.noarch requires rdesktop RemoteBox-1.7-1.el7.noarch requires perl-Gtk2 bodhi-server-0.9.8-2.el7.noarch requires python-simplemediawiki bodhi-server-0.9.8-2.el7.noarch requires python-fedora-turbogears 1:centerim-4.22.10-14.el7.x86_64 requires perl(Time::ParseDate) check-mk-1.2.4-1.el7.x86_64 requires mod_python chemtool-1.6.14-1.el7.x86_64 requires openbabel chm2pdf-0.9.1-13.el7.noarch requires python-chm chm2pdf-0.9.1-13.el7.noarch requires htmldoc cscppc-1.0.3-1.el7.x86_64 requires cppcheck = 0:1.58 docker-registry-0.6.5-1.el7.noarch requires redis docker-registry-0.6.5-1.el7.noarch requires python-rsa docker-registry-0.6.5-1.el7.noarch requires python-redis docker-registry-0.6.5-1.el7.noarch requires python-keystoneclient docker-registry-0.6.5-1.el7.noarch requires python-glanceclient docker-registry-0.6.5-1.el7.noarch requires python-backports-lzma globus-gram-job-manager-pbs-1.6-7.el7.x86_64 requires torque-client globus-gram-job-manager-sge-1.7-2.el7.x86_64 requires gridengine lxc-templates-0.9.0-3.el7.x86_64 requires dpkg lxc-templates-0.9.0-3.el7.x86_64 requires debootstrap lxc-templates-0.9.0-3.el7.x86_64 requires busybox mate-desktop-1.8.0-2.el7.x86_64 requires mate-panel mate-desktop-1.8.0-2.el7.x86_64 requires mate-control-center-filesystem mate-screensaver-1.8.0-1.el7.x86_64 requires mate-keyring-pam mate-settings-daemon-1.8.0-1.el7.x86_64 requires mate-control-center-filesystem mate-themes-1.8.1-0.1.git20140304.5a900ef.el7.noarch requires gtk2-engines mate-themes-1.8.1-0.1.git20140304.5a900ef.el7.noarch requires gtk-murrine-engine mcollective-common-2.4.1-1.el7.noarch requires rubygem(systemu) mcollective-common-2.4.1-1.el7.noarch requires rubygem(stomp) nf3d-0.8-2.el7.noarch requires python-visual openpgpkey-milter-0.3-1.el7.noarch requires python-pymilter openpgpkey-milter-0.3-1.el7.noarch requires python-gnupg php-phpseclib-crypt-aes-0.3.5-2.el7.noarch requires php-pear(phpseclib.sourceforge.net/Crypt_Rijndael) = 0:0.3.0 plowshare-0.9.4-0.46.20140112git.el7.noarch requires caca-utils python-tgcaptcha2-0.2.0-5.el7.noarch requires python-fedora-turbogears qt4pas-2.5-3.el7.x86_64 requires fpc-src rabbitvcs-core-0.16-1.el7.noarch requires python-dulwich rabbitvcs-core-0.16-1.el7.noarch requires pysvn rabbitvcs-nautilus-0.16-1.el7.x86_64 requires nautilus-python rabbitvcs-thunar-0.16-1.el7.x86_64 requires thunarx-python rabbitvcs-thunar-0.16-1.el7.x86_64 requires thunar rubygem-gssapi-1.1.2-3.el7.noarch requires rubygem(ffi) = 0:1.0.1 rubygem-mizuho-0.9.20-2.el7.noarch requires rubygem(sqlite3) rubygem-rspec-2.14.1-1.el7.noarch requires rubygem(rspec-mocks) = 0:2.14.1 rubygem-rspec-2.14.1-1.el7.noarch requires rubygem(rspec-expectations) = 0:2.14.1 rubygem-rspec-2.14.1-1.el7.noarch requires rubygem(rspec-core) = 0:2.14.1 rubygem-simplecov-0.7.1-8.el7.noarch requires rubygem(simplecov-html) = 0:0.7.1 rubygem-simplecov-0.7.1-8.el7.noarch requires rubygem(multi_json) = 0:1.0 rubygem-term-ansicolor-1.2.2-3.el7.noarch requires rubygem(tins) 0:1 rubygem-term-ansicolor-1.2.2-3.el7.noarch requires rubygem(tins) = 0:0.8 spectrwm-2.5.0-1.el7.x86_64 requires xlockmore spectrwm-2.5.0-1.el7.x86_64 requires dmenu Broken deps for ppc64 -- 2ping-2.0-2.el7.noarch requires perl(Digest::CRC) RemoteBox-1.7-1.el7.noarch requires rdesktop RemoteBox-1.7-1.el7.noarch requires perl-Gtk2 bodhi-server-0.9.8-2.el7.noarch requires python-simplemediawiki bodhi-server-0.9.8-2.el7.noarch requires python-fedora-turbogears 1:centerim-4.22.10-14.el7.ppc64 requires perl(Time::ParseDate) check-mk-1.2.4-1.el7.ppc64 requires mod_python chemtool-1.6.14-1.el7.ppc64 requires openbabel chm2pdf-0.9.1-13.el7.noarch requires python-chm chm2pdf-0.9.1-13.el7.noarch requires htmldoc cloud-init-0.7.2-8.el7.noarch requires python-requests cloud-init-0.7.2-8.el7.noarch requires dmidecode cscppc-1.0.3-1.el7.ppc64 requires cppcheck = 0:1.58 docker-registry-0.6.5-1.el7.noarch requires redis docker-registry-0.6.5-1.el7.noarch requires python-rsa docker-registry-0.6.5-1.el7.noarch requires python-requests docker-registry-0.6.5-1.el7.noarch requires python-redis docker-registry-0.6.5-1.el7.noarch requires python-keystoneclient
Re: Heads up: Mesa/LLVM rebase and OpenGTL retirement in F20
Hi 2014-03-27 21:02 GMT+01:00 Adam Jackson a...@redhat.com: 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. The following source packages will also be updated for the llvm rebase: dragonegg gambas3 pocl pure python-llvmpy I have patched python-llvmpy to work with llvm 3.4, so it should be a problem. The patched package (0.12.4-19 has been built in Rawhide but not in F20, to avoid re building the same thing twice. Regards, Sergio -- 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: Firefox Gtk3 test package
Martin Stransky stransky at redhat.com writes: On 01/13/2014 04:16 PM, Christopher Meng wrote: On Mon, Jan 13, 2014 at 11:15 PM, Martin Stransky stransky at redhat.com wrote: Hi guys, first $SUBJ is available at: http://stransky.fedorapeople.org/FirefoxGtk3/ It's just a src.spm and plugin support it not finished (don't browse youtube ) but may work as a preview. I'll provide Fedora builds and repo later. You can build it on copr! Good idea! http://copr.fedoraproject.org/coprs/stransky/FirefoxGtk3/ ma. First off, thank you so much for this! I have been using it and it is stunning. The difference is huge. It also seems to be the only browser that has supported my HiDPI display (perhaps that's thanks to gtk3?). One thing that I have been waiting for is separate processes for each tab to start working. Right now, when I enable it, it causes the entire window to turn grey. On that note, I haven't seen a new build in a while! When can we hope for an update? -- 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: Firefox Gtk3 test package
On 03/28/2014 11:44 AM, Kẏra wrote: First off, thank you so much for this! I have been using it and it is stunning. The difference is huge. Thanks! It also seems to be the only browser that has supported my HiDPI display (perhaps that's thanks to gtk3?). That's a great news, I was not aware of it. One thing that I have been waiting for is separate processes for each tab to start working. Right now, when I enable it, it causes the entire window to turn grey. How do you enable it? Can you file a BZ# for that at bugzilla.redhat.com? On that note, I haven't seen a new build in a while! When can we hope for an update? There are some patches waiting upstream for review so when those are done. I'd like also update the firefox-gtk3 build to Firefox 31. ma. -- 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 Fri, Mar 28, 2014 at 1:54 AM, Paulo César Pereira de Andrade paulo.cesar.pereira.de.andr...@gmail.com wrote: 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 If that works we should probably use it for F20 to avoid retiring a package mid release. -- 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: repo XML file schemas
Are there XML Schemas for the repo files available anywhere please ? Aaron On 28 March 2014 08:32, Petr Pisar ppi...@redhat.com wrote: On 2014-03-27, Aaron Gray aaronngray.li...@gmail.com wrote: 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 ! XML name space URI is just an identifier. There does not have to be any document or a service reachable. Even the domain name does not have to exist. That does not mean that the format (e.g. as an XML Schema) should no be somewhere documented. -- Petr -- 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
Re: Firefox Gtk3 test package
Martin Stransky stransky at redhat.com writes: On 03/28/2014 11:44 AM, Kẏra wrote: First off, thank you so much for this! I have been using it and it is stunning. The difference is huge. Thanks! It also seems to be the only browser that has supported my HiDPI display (perhaps that's thanks to gtk3?). That's a great news, I was not aware of it. One thing that I have been waiting for is separate processes for each tab to start working. Right now, when I enable it, it causes the entire window to turn grey. How do you enable it? Can you file a BZ# for that at bugzilla.redhat.com? In about:config, set the browser.tabs.remote preference to 'true' More info here: https://wiki.mozilla.org/Electrolysis did you mean the mozilla bug tracker? what product would i file it under at redhat's? On that note, I haven't seen a new build in a while! When can we hope for an update? There are some patches waiting upstream for review so when those are done. I'd like also update the firefox-gtk3 build to Firefox 31. cool! can you link to bugs / review pages for those patches so that we can track their progress? updating the build to FF31 also sounds great [= -- 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 06:18 PM, Simo Sorce wrote: 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. Yes, see elsewhere in this thread. I was forgetting that the remote capability doesn't happen in-process, it happens as part of the SSSD daemon (which obviously wouldn't use PrivateNetwork=yes). It's more of a risk with the old nss_ldap, but I don't think we even ship that anymore (replaced with nss-pam-ldapd) As long as this isn't in any way interfering with UNIX sockets (which it must not be, if nscd would work), then I see no issue here with SSSD. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlM1YTkACgkQeiVVYja6o6NlMQCgqPy86NQ175UsOzQ6Og3ODbbe YOMAoIBO0ZhbueWMlTdwFKYT2IhhNt/s =GyTT -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 18:18 -0400, Simo Sorce wrote: 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. Also let me add that NSCD wouldn't be a good solution anyway. NSCD is dumb (reason why we have our own similar mmap cache in nss_sss instead of using NSCD), and has no idea of the status of the network and will expire all caches after a while whether you regain access to the network or not, plus IIRC enumeration is never handled via NSCD so some operations will still fail hard. 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: Maybe it's time to get rid of tcpwrappers/tcpd?
On 03/20/2014 08:05 PM, Lennart Poettering wrote: On Thu, 20.03.14 12:20, Stephen John Smoogen (smo...@gmail.com) wrote: I doubt there are many people even using them anymore, firewalls are more comprehensive and a lot more powerful, and while every admin knows firewalls, I figure only very few know tcpd/tcpwrap, and even fewer ever actively make use of them... Actually they are used quite a bit in various service worlds. Mainly for ssh and email for dealing with scanners. [DenyHosts is a boon in this area.] The reason for using a secondary tool is that depth of security. Well, all mails servers as well as sshd have much better ways to do such filtering. sshd has Match, Postfix for example has smtpd_client_restrictions=, and so on. I'd like to note that you can't just replace deny.hosts using Match block in sshd_config. - using libwrap, a connection is dropped before the protocol version exchange so a client can't even check the server's identification string. While using Match block, a client and a server exchange id strings, negotiate the transport layer parameters, exchange keys and establish encrypted connection. - in Match block, you can only change keywords related to authentication or ssh sessions - every change in sshd_config has to be confirmed by sshd restart, while changing hosts.deny doesn't need any other action Petr Again, I have no doubt that some people still use tcpwrappers. But I'd argue that is clearly the excpetion, not the rule, and they'd better use something different, and that we should be creating an excellent distro, instead of a one that features horrible software... Over the years I have found that there are multiple of attacks which will nullify one layer of protection at one point or another. Having a second level or third level of protection is a boon when this happens. Well, it certainly makes sense to combine a firewall with let's say selinux with maybe postfix/ssh acls. Then you already have three layers of protection, of very good protection. But of all possible options tcpwrap is the absolute worst choice. And we should be able to deprecate and remove stuff from our core OS if we think it is crap. I mean, there are two sides of the medal: sure multiple layers of protection might be a good thing, but you also make things a lot more complex with each one, and you involve more possibly exploitable code -- and tcpwrap is simply bad code, that's a fact. So you have to balance things out: is something a layer that is worth the trouble? Or does having it around make things worse? I am of the opinion that tcpwrap indeed does make things worse. Sure, three layers of condoms probably make sex safer, but then again, if one of them is made of 10 year old half-decomposed goat intestines, then maybe the sex is a lot less fun, too... At the enterprise level firewalls can come under a different set of change control rules than something like tcpwrappers which is considered application level. While I would like to be able to make a simple change in a firewall, I can end up spending a month until I can. Application controls are usually an hour or so signoff. This means that if tcp-wrappers is going then something will need to be able to replace it to meet that large scale concern. [Automatic firewall controls like firewalld have to be disabled or put into a manual changes only mode in these areas for change control purposes. ] Well, that really sounds like a specific issue of your company... Really, I don't think the question whether the bureaucracy of some hypothetical company makes a distinction between tcwrap and firewalls has no place in the discussion whether we should support tcpwrap in our distro or not. I can't argue on the code maintainability or layout. Not my area of expertise. I can say that if tcpd/libtcpwrappers were to go away that something equivalent would need to be built to replace it for the ability to fine tune at a layer below the firewall. Why? Other than your hypothetical bureaucracy, is there anything that tcpwrap can do that firewalls can't do, that really deserves to be supported? I really can't see anything... [1] tcpd comes from a time when there weren't local firewalls available in all Unix systems, so they built something like them in userspace. But that time is long long gone, and pretty much any Linux installation I know nowadays has a firewall compiled into the kernel... Lennart [1] well, sure tcpwrap resolves DNS dynamically and can use that for access control, but people who bind access control to DNS really should find a different job than administrator... -- Petr Lautrbach Security Technologies Red Hat Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com. signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org
Re: Maybe it's time to get rid of tcpwrappers/tcpd?
Am 28.03.2014 14:39, schrieb Petr Lautrbach: On 03/20/2014 08:05 PM, Lennart Poettering wrote: On Thu, 20.03.14 12:20, Stephen John Smoogen (smo...@gmail.com) wrote: I doubt there are many people even using them anymore, firewalls are more comprehensive and a lot more powerful, and while every admin knows firewalls, I figure only very few know tcpd/tcpwrap, and even fewer ever actively make use of them... Actually they are used quite a bit in various service worlds. Mainly for ssh and email for dealing with scanners. [DenyHosts is a boon in this area.] The reason for using a secondary tool is that depth of security. Well, all mails servers as well as sshd have much better ways to do such filtering. sshd has Match, Postfix for example has smtpd_client_restrictions=, and so on. I'd like to note that you can't just replace deny.hosts using Match block in sshd_config. - using libwrap, a connection is dropped before the protocol version exchange so a client can't even check the server's identification string. While using Match block, a client and a server exchange id strings, negotiate the transport layer parameters, exchange keys and establish encrypted connection. which is *layered* security that is the same reason why put the rules in iptables is only a uneducated phrase and anybody who will put all his security in a single layer sooner or later regret that mistake - every change in sshd_config has to be confirmed by sshd restart, while changing hosts.deny doesn't need any other action no - try it out! make a fatal syntax error in sshd_config and in case of a remote machine make sure you don't close the last connection because you will not reach the machine again otherwise signature.asc Description: OpenPGP digital 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: Maybe it's time to get rid of tcpwrappers/tcpd?
Am 28.03.2014 14:48, schrieb Petr Lautrbach: On 03/28/2014 02:44 PM, Reindl Harald wrote: - every change in sshd_config has to be confirmed by sshd restart, while changing hosts.deny doesn't need any other action no - try it out! make a fatal syntax error in sshd_config and in case of a remote machine make sure you don't close the last connection because you will not reach the machine again otherwise [14:46:53 root@malas ~ ]# /usr/sbin/sshd -T /etc/ssh/sshd_config: line 157: Bad configuration option: blbla /etc/ssh/sshd_config line 157: Directive 'blbla' is not allowed within a Match block [14:46:55 root@malas ~ ]# ssh localhost Fedora release 21 (Rawhide) root@localhost's password: not sure which options are connection specific but there are for sure ones which do not need a restart and get effective for every new connection, i have not the time to seek and reproduce that but it's a fact from real work expierience signature.asc Description: OpenPGP digital 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: Heads up: Mesa/LLVM rebase and OpenGTL retirement in F20
While Heisenbereg isn't the newbie friendly distro that Mint or Ubuntu are but many new to Enterprise linux use this and that could seriously cause some bad blood type issues with end-users I'm also for at least getting the upstream approval for mid release modding if not FesCO Corey W Sheldon Owner, 1st Class Mobile Shine 310.909.7672 www.facebook.com/1stclassmobileshine On Fri, Mar 28, 2014 at 11:15 AM, Adam Jackson a...@redhat.com wrote: On Fri, 2014-03-28 at 07:39 -0400, Jaroslav Reznik wrote: +1 And yep, it should go to FESCo - this has much more bigger scope than 10.0.3 due to LLVM update. You know I'm more than ok with updates to Fn-1 but this one should be coordinated very well. Can you (or anyone else) elaborate on the issues you're concerned with here? If I'm going to have to play Simon Says about this I'd like some opportunity to address (or at least investigate) concerns ahead of time. - 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 -- 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 03/28/2014 04:37 PM, Adam Jackson wrote: RHEL's Mesa at this point links against a private build of llvm that is explicitly _not_ part of The Platform, for exactly this reason: it's not something we can commit to supporting for any use beyond Mesa itself, even in the extreme short term. This might be a good way forward for Fedora as well to avoid changing the system-wide llvm ABI mid release. -- Kalev -- 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 Fri, 2014-03-28 at 11:21 -0400, Corey Sheldon wrote: While Heisenbereg isn't the newbie friendly distro that Mint or Ubuntu are but many new to Enterprise linux use this and that could seriously cause some bad blood type issues with end-users I'm also for at least getting the upstream approval for mid release modding if not FesCO Upstream approval? Mesa doesn't care what we ship. If you mean will RHEL mind if we do this, hello, my name's Adam, I've been doing most of the packaging grunt work for graphics in RHEL for the last six-ish years, including mass rebases in RHEL6 for the last three. I'm pretty sure I'm okay with it. - 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: Heads up: Mesa/LLVM rebase and OpenGTL retirement in F20
On Thu, 2014-03-27 at 13:40 -0700, Adam Williamson wrote: 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. :) OpenGTL here is something of an implementation detail. RHEL's Mesa at this point links against a private build of llvm that is explicitly _not_ part of The Platform, for exactly this reason: it's not something we can commit to supporting for any use beyond Mesa itself, even in the extreme short term. It might be nice if Fedora adopted the common practice (among other OSes with interface assurances) of at least attempting to define stability levels. Whose action item would that be? - 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: Heads up: Mesa/LLVM rebase and OpenGTL retirement in F20
Adam Jackson (a...@redhat.com) said: On Fri, 2014-03-28 at 07:39 -0400, Jaroslav Reznik wrote: +1 And yep, it should go to FESCo - this has much more bigger scope than 10.0.3 due to LLVM update. You know I'm more than ok with updates to Fn-1 but this one should be coordinated very well. Can you (or anyone else) elaborate on the issues you're concerned with here? If I'm going to have to play Simon Says about this I'd like some opportunity to address (or at least investigate) concerns ahead of time. 1) the removal of OpenGTL mid-stream breaking user or other apps (and we can't truly remove it anyway - it stays in the F20 release repo) This may be solvable by use of the patch mentioned elsewhere in this thread. 2) as the policy is to not update ABI on libraries, it requires an exception. Concerns would be about the number of apps affected, coordinating the release of all dependent apps, how likely user/other apps might be broken by this ABI update. 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
Re: Desktop racing problem in F20
On 28 March 2014 10:47, Pete Zaitcev zait...@redhat.com wrote: Dear Fedorians: Recently, I was hitting a number of odd behaviours that look like races. Filed a couple of bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1082092 https://bugzilla.redhat.com/show_bug.cgi?id=1082095 But this feels unsatisfactory, because reproducibility is extremely low for all cases. Bugs aren't going to cut it. So, I'm wondering if anyone has an idea where to dig. Here's what I recall seeing: - The audio volume applet does not always react to plugging headphones. Re-plug and it goes away. - Screensaver forgetting to blank. Move cursor and problem disappears. - Applications may not map on screen on start. Click on activity again usually fixes the problem. Well I have seen all of these in the last 2 weeks on Fedora 19 so I am not sure what exactly is going on. The audio seems to have started with the 3.13 series but I am not exactly sure. The screensaver has happened on and off and as you said it is racy. The applications happens every now and then.. what is even funnier is that the application is running but doesn't seem to be mapped anywhere. Not sure how to better debug any of these issues to help figure out what is going on. -- Stephen J Smoogen. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Attempting to contact three unresponsive maintainers
Greetings, we've been told that the email addresses for three package maintainers are no longer valid. I'm starting the unresponsive maintainer policy to find out if they are still interested in maintaining their packages (and if so, have them update their email addresses in FAS). If they're not interested in maintaining or we can't locate them I'll have FESCo orphan the packages so that others can take them over. If you have a way to contact any of these maintainers, please let them know that we'd appreciate knowing what to do with their packages. Thanks! Maintainers: * awnuk -- former email address aw...@redhat.com - comaintainer of dogtag-pki, dogtag-pki-theme, pki-console, pki-core, pki-ra, and pki-tps * llim -- Lawrence Lim -- former email address l...@redhat.com - Bugzilla owner of redhat-lsb * osier -- Osier Yang -- former email address jy...@redhat.com - comaintainer of libvirt If we get to the point of removing acls for these people, only redhat-lsb will need a new owner. The other packages just have these package maintainers as comaintianers. -Toshio pgpMjXb1h8e6a.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
Fedora Present and Future: a Fedora.next 2014 Update (Part II, “What’s Happening?”)
I promised a while ago that I would provide a text version of my talk at DevConf, for people who couldn't make it and because sitting through a video of me standing up there going on and on doesn't really make for good followup discussion. I posted a link to the first part last week: http://fedoramagazine.org/fedora-present-and-future-a-fedora-next-2014-update-part-i-why/ and now, Part II: http://fedoramagazine.org/fedora-present-and-future-a-fedora-next-2014-update-part-ii-whats-happening/ And as I said last week, I will take questions, comments, complaints, in any media including replies here, on the article, on the social media, or at any bar or coffee shop within walking distance of Boston's MBTA. -- Matthew Miller-- Fedora Project--mat...@fedoraproject.org Tepid change for the somewhat better! -- 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 Fri, 2014-03-28 at 07:39 -0400, Jaroslav Reznik wrote: +1 And yep, it should go to FESCo - this has much more bigger scope than 10.0.3 due to LLVM update. You know I'm more than ok with updates to Fn-1 but this one should be coordinated very well. Can you (or anyone else) elaborate on the issues you're concerned with here? If I'm going to have to play Simon Says about this I'd like some opportunity to address (or at least investigate) concerns ahead of time. - 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
Desktop racing problem in F20
Dear Fedorians: Recently, I was hitting a number of odd behaviours that look like races. Filed a couple of bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1082092 https://bugzilla.redhat.com/show_bug.cgi?id=1082095 But this feels unsatisfactory, because reproducibility is extremely low for all cases. Bugs aren't going to cut it. So, I'm wondering if anyone has an idea where to dig. Here's what I recall seeing: - The audio volume applet does not always react to plugging headphones. Re-plug and it goes away. - Screensaver forgetting to blank. Move cursor and problem disappears. - Applications may not map on screen on start. Click on activity again usually fixes the problem. I think there were more, I just can't remember them all. In each instance it's easy to blame firmware, kernel, whatever. But there are several. If RAM was bad, I imagine I'd see crashes. But no, system is stable. Also, F19 worked fine. Of course it's most difficult to find a black cat in dark room when it is not in the room, so I'm wondering if I'm seeing things. If anyone else is seeing a sudden onset of racing behaviours after upgrade to F20, please let me know. -- 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
Re: EPEL group creation requests.
On Fri, 28 Mar 2014 08:52:20 -0500 Jim Perrin jper...@centos.org wrote: With cinnamon and mate being added for epel7, how would one go about requesting that groups be created for them, similar to the xfce group? epel uses the same comps repo as Fedora: https://git.fedorahosted.org/cgit/comps.git/ Just add in https://git.fedorahosted.org/cgit/comps.git/tree/comps-epel7.xml.in kevin signature.asc Description: PGP signature ___ epel-devel mailing list epel-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: Heads up: Mesa/LLVM rebase and OpenGTL retirement in F20
On Fri, 2014-03-28 at 11:38 -0400, Bill Nottingham wrote:
Adam Jackson (a...@redhat.com) said:
Can you (or anyone else) elaborate on the issues you're concerned with
here? If I'm going to have to play Simon Says about this I'd like some
opportunity to address (or at least investigate) concerns ahead of time.
1) the removal of OpenGTL mid-stream breaking user or other apps
(and we can't truly remove it anyway - it stays in the F20 release repo)
This may be solvable by use of the patch mentioned elsewhere in this thread.
Yeah, I'm happy to apply that patch. I'm not sure I could do much
validation on it beyond running OpenGTL's own tests though (or, I guess,
pulling an old version of calligra and trying to exercise it that way).
2) as the policy is to not update ABI on libraries, it requires an
exception. Concerns would be about the number of apps affected, coordinating
the release of all dependent apps, how likely user/other apps might be
broken by this ABI update.
In terms of Fedora proper, it's a pretty short list:
- eclipse-cdt-llvm, syntastic-llvm, gedit-code-assistance, and
kate-plugin-cpphelper all use clang to do various levels of realtime
parsing for things like syntax highlighting and etc; depressingly
there's even a libclang.so (yep, not versioned!) whose abi has almost
certainly changed, which the latter two do use, so probably they should
be rebuilt even in f21
- xorg-x11-drv-vmware - mesa-libxatracker - llvm-libs; testable by
booting a kvm with a vmware gpu (I think, there's been multiple
generations and the one kvm emulates might not be one requiring the
xatracker bits) or, obviously, under vmware
- pocl is an opencl implementation with no consumers, but with a
testsuite
- pure is a programming language with a test suite; I don't know of any
other packages containing pure code though (rimshot)
- OpenGTL is covered above
- dragonegg is an llvm backend for gcc, with a test suite
- gambas3 is a visual basic clone; it does not appear to have a test
suite, but the IDE is at least self-hosting
- python{,3}-llvmpy are python wrappers around libLLVM, with a test
suite
- ghc apparently uses llvm as a backend on arm; I'm assuming it has a
test suite because Haskell
And, of course, mesa-{dri,vdpau}-drivers contain drivers using LLVM.
So, ~12 packages outside llvm and mesa, not all of which necessarily
need an update (depends how much clang's output changes between 3.3 and
3.4). Excluding mesa these are mostly leaf packages, well outside the
critical path, typically self-contained, and quite unlikely to break
booting to the desktop for anyone.
That most of them appear to have test suites is heartening, the irony is
that running them for the llvm rebase would almost certainly be more
verification than went into them for F20 gold. Still, we can at least
establish a baseline and compare for regressions.
That said, I haven't looked for other consumers in outside repositories,
and I can't possibly know every llvm-using app in the world even if I
did look.
- 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
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-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perltidy] Update to 20140328
commit 8f4ac8b8f541f632d325b63153a1ec0e22db6002
Author: Paul Howarth p...@city-fan.org
Date: Fri Mar 28 15:31:48 2014 +
Update to 20140328
- New upstream release 20140328
- Fixed CPAN RT#94190 and debian Bug #742004: perltidy.LOG file left
behind;
the problem was caused by the memoization speedup patch in version
20121207: an unwanted flag was being set, which caused a LOG to be
written
if perltidy was called multiple times
- New default behavior for LOG files: if the source is from an array or
string (through a call to the perltidy module) then a LOG output is only
possible if a logfile stream is specified; this is to prevent unexpected
perltidy.LOG files
- Fixed debian Bug #740670, insecure temporary file usage; File::Temp is
now
used to get a temporary file (CVE-2014-2277)
- Any -b (--backup-and-modify-in-place) flag is silently ignored when a
source stream, destination stream, or standard output is used; this is
because the -b flag may have been in a .perltidyrc file and warnings
break
Test::NoWarnings
- Drop upstreamed patch for CVE-2014-2277
- Classify buildreqs by usage
perltidy.spec | 51 +--
sources |3 +--
2 files changed, 38 insertions(+), 16 deletions(-)
---
diff --git a/perltidy.spec b/perltidy.spec
index 09de9c3..724f2dd 100644
--- a/perltidy.spec
+++ b/perltidy.spec
@@ -1,23 +1,33 @@
Name: perltidy
-Version: 20130922
-Release: 2%{?dist}
+Version: 20140328
+Release: 1%{?dist}
Summary: Tool for indenting and re-formatting Perl scripts
License: GPLv2+
URL: http://perltidy.sourceforge.net/
Source0:
http://www.cpan.org/modules/by-module/Perl/Perl-Tidy-%{version}.tar.gz
-Source1:
http://cdn.debian.net/debian/pool/main/p/perltidy/perltidy_20130922-1.debian.tar.xz
-Patch0:perltidy-20130922-tmpnamdoc.patch
-Patch1:Perl-Tidy-utf8.patch
+Patch0:Perl-Tidy-utf8.patch
BuildArch: noarch
+# Module Build
+BuildRequires: perl
+BuildRequires: perl(ExtUtils::MakeMaker)
+# Module Runtime
BuildRequires: perl(Carp)
BuildRequires: perl(constant)
BuildRequires: perl(Cwd)
BuildRequires: perl(Exporter)
-BuildRequires: perl(ExtUtils::MakeMaker)
+BuildRequires: perl(File::Basename)
+BuildRequires: perl(File::Copy)
+BuildRequires: perl(File::Spec)
+BuildRequires: perl(File::Temp)
BuildRequires: perl(Getopt::Long)
BuildRequires: perl(IO::File)
+BuildRequires: perl(strict)
+BuildRequires: perl(vars)
+# Test Suite
BuildRequires: perl(Test)
+# Runtime
Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
+Requires: perl(File::Spec)
Provides: perl-Perl-Tidy = %{version}-%{release}
%description
@@ -32,16 +42,10 @@ errors with missing or extra braces, parentheses, and
square brackets
because it is very good at localizing errors.
%prep
-%setup -q -n Perl-Tidy-%{version} -a 1
-
-# Fix from Debian for insecure temporary file usage (CVE-2014-2277, #1074721)
-patch -p1 -i debian/patches/fix_insecure_tmpnam_usage_740670
-
-# Related man page fix
-%patch0 -p1
+%setup -q -n Perl-Tidy-%{version}
# Re-format documentation as UTF-8
-%patch1
+%patch0
# Don't need Windows batch file
rm examples/pt.bat
@@ -69,6 +73,25 @@ make test
%{_mandir}/man3/Perl::Tidy.3*
%changelog
+* Fri Mar 28 2014 Paul Howarth p...@city-fan.org - 20140328-1
+- Update to 20140328
+ - Fixed CPAN RT#94190 and debian Bug #742004: perltidy.LOG file left behind;
+the problem was caused by the memoization speedup patch in version
+20121207: an unwanted flag was being set, which caused a LOG to be written
+if perltidy was called multiple times
+ - New default behavior for LOG files: if the source is from an array or
+string (through a call to the perltidy module) then a LOG output is only
+possible if a logfile stream is specified; this is to prevent unexpected
+perltidy.LOG files
+ - Fixed debian Bug #740670, insecure temporary file usage; File::Temp is now
+used to get a temporary file (CVE-2014-2277)
+ - Any -b (--backup-and-modify-in-place) flag is silently ignored when a
+source stream, destination stream, or standard output is used; this is
+because the -b flag may have been in a .perltidyrc file and warnings break
+Test::NoWarnings
+- Drop upstreamed patch for CVE-2014-2277
+- Classify buildreqs by usage
+
* Tue Mar 25 2014 Paul Howarth p...@city-fan.org - 20130922-2
- Cosmetic spec changes:
- Use tabs
diff --git a/sources b/sources
index 534b7cd..080a1d8 100644
--- a/sources
+++ b/sources
@@ -1,2 +1 @@
-efc831bc9f238ae037dae22c41b6ba31 Perl-Tidy-20130922.tar.gz
-0fa0cdb8817f6faf4cb97efa3d3ebb25 perltidy_20130922-1.debian.tar.xz
+a33f908663934bdd67aa915e25f89f45 Perl-Tidy-20140328.tar.gz
--
Fedora Extras Perl SIG
http
[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 #27 from Dan Horák d...@danny.cz ---
this function from SSLeay.xs
UV get_my_thread_id(void) /* returns threads-tid() value */
{
dSP;
UV tid = 0;
int count = 0;
#ifdef USE_ITHREADS
ENTER;
SAVETMPS;
PUSHMARK(SP);
XPUSHs(sv_2mortal(newSVpv(threads, 0)));
PUTBACK;
count = call_method(tid, G_SCALAR|G_EVAL);
SPAGAIN;
if (SvTRUE(ERRSV) || count != 1)
/* if threads not loaded or an error occurs return 0 */
tid = 0;
else
tid = (UV)POPi;
PUTBACK;
FREETMPS;
LEAVE;
#endif
return tid;
}
expands to
UV get_my_thread_id(void)
{
SV **sp = (((PerlInterpreter
*)pthread_getspecific(PL_thr_key))-Istack_sp);
UV tid = 0;
int count = 0;
Perl_push_scope(((PerlInterpreter *)pthread_getspecific(PL_thr_key)));
Perl_save_int(((PerlInterpreter *)pthread_getspecific(PL_thr_key)),
(int*)(((PerlInterpreter *)pthread_getspecific(PL_thr_key))-Itmps_floor)),
(((PerlInterprete
r *)pthread_getspecific(PL_thr_key))-Itmps_floor) = (((PerlInterpreter
*)pthread_getspecific(PL_thr_key))-Itmps_ix);
(void)( { if (++(((PerlInterpreter
*)pthread_getspecific(PL_thr_key))-Imarkstack_ptr) == (((PerlInterpreter
*)pthread_getspecific(PL_thr_key))-Imarkstack_max))
Perl_markstack_grow(((PerlInterpreter *)pthread_getspecific(PL_thr_key)));
*(((PerlInterpreter *)pthread_getspecific(PL_thr_key))-Imarkstack_ptr) =
(I32)((sp) - (((P
erlInterpreter *)pthread_getspecific(PL_thr_key))-Istack_base)); } );
((void)(__builtin_expectPerlInterpreter
*)pthread_getspecific(PL_thr_key))-Istack_max) - sp (int)(1),0) (sp =
Perl_stack_grow(((PerlInterpreter *)pthrea
d_getspecific(PL_thr_key)), sp,sp,(int) (1, *++sp =
(Perl_sv_2mortal(((PerlInterpreter *)pthread_getspecific(PL_thr_key)),
Perl_newSVpv(((PerlInterpreter *)pthrea
d_getspecific(PL_thr_key)), threads,0;
(((PerlInterpreter *)pthread_getspecific(PL_thr_key))-Istack_sp) = sp;
count = Perl_call_method(((PerlInterpreter
*)pthread_getspecific(PL_thr_key)), tid,2|8);
sp = (((PerlInterpreter *)pthread_getspecific(PL_thr_key))-Istack_sp);
if *((0+PerlInterpreter
*)pthread_getspecific(PL_thr_key))-Ierrgv))-sv_u.svu_gp)-gp_sv ?
((0+PerlInterpreter
*)pthread_getspecific(PL_thr_key))-Ierrgv))-sv_u.svu_gp)-gp_sv) :
((0+(Perl_gv_add_by_type(((PerlInterpreter *)pthread_getspecific(PL_thr_key)),
PerlInterpreter
*)pthread_getspecific(PL_thr_key))-Ierrgv)),SVt_NULL))-sv_u.svu_gp)-gp_sv
*((0+PerlInterpreter
*)pthread_getspecific(PL_thr_key))-Ierrgv))-sv_u.svu_gp)-gp_sv ?
((0+PerlInterpreter
*)pthread_getspecific(PL_thr_key))-Ierrgv))-sv_u.svu_gp)-gp_sv) :
((0+(Perl_gv_add_by_type(((PerlInterpreter *)pthread_getspecific(PL_thr_key)),
PerlInterpreter
*)pthread_getspecific(PL_thr_key))-Ierrgv)),SVt_NULL))-sv_u.svu_gp)-gp_sv-sv_flags
0x0020) ? Perl_sv_2bool_flags(((PerlInterpreter
*)pthread_getspecific(PL_thr_key)), (*((0+PerlInterpreter
*)pthread_getspecific(PL_thr_key))-Ierrgv))-sv_u.svu_gp)-gp_sv ?
((0+PerlInterpreter
*)pthread_getspecific(PL_thr_key))-Ierrgv))-sv_u.svu_gp)-gp_sv) :
((0+(Perl_gv_add_by_type(((PerlInterpreter *)pthread_getspecific(PL_thr_key)),
PerlInterpreter
*)pthread_getspecific(PL_thr_key))-Ierrgv)),SVt_NULL))-sv_u.svu_gp)-gp_sv))),2)
: ( !(((*((0+PerlInterpreter
*)pthread_getspecific(PL_thr_key))-Ierrgv))-sv_u.svu_gp)-gp_sv ?
((0+PerlInterpreter
*)pthread_getspecific(PL_thr_key))-Ierrgv))-sv_u.svu_gp)-gp_sv) :
((0+(Perl_gv_add_by_type(((PerlInterpreter *)pthread_getspecific(PL_thr_key)),
PerlInterpreter
*)pthread_getspecific(PL_thr_key))-Ierrgv)),SVt_NULL))-sv_u.svu_gp)-gp_sv-sv_flags
(0x0100|0x0200|0x0400|0x0800|
0x1000|0x2000|0x4000|0x8000) ||
(((svtype)(((*((0+PerlInterpreter
*)pthread_getspecific(PL_thr_key))-Ierrgv))-sv_u.svu_gp)-gp_sv ?
((0+PerlInterpreter
*)pthread_getspecific(PL_thr_key))-Ierrgv))-sv_u.svu_gp)-gp_sv) :
((0+(Perl_gv_add_by_type(((PerlInterpreter *)pthread_getspecific(PL_thr_key)),
PerlInterpreter
*)pthread_getspecific(PL_thr_key))-Ierrgv)),SVt_NULL))-sv_u.svu_gp)-gp_sv-sv_flags
0xff)) == SVt_REGEXP || (((*((0+PerlInterpreter
*)pthread_getspecific(PL_thr_key))-Ierrgv))-sv_u.svu_gp)-gp_sv ?
((0+PerlInterpreter
*)pthread_getspecific(PL_thr_key))-Ierrgv))-sv_u.svu_gp)-gp_sv) :
((0+(Perl_gv_add_by_type(((PerlInterpreter *)pthread_getspecific(PL_thr_key)),
PerlInterpreter
*)pthread_getspecific(PL_thr_key))-Ierrgv)),SVt_NULL))-sv_u.svu_gp)-gp_sv-sv_flags
(0xff|0x4000|0x8000|0x0100)) == (SVt_PVLV|0x0100))) ? 0 :
(((*((0+PerlInterpreter
*)pthread_getspecific(PL_thr_key))-Ierrgv))-sv_u.svu_gp)-gp_sv ?
((0+PerlInterpreter
*)pthread_getspecific(PL_thr_key))-Ierrgv))-sv_u.svu_gp)-gp_sv) :
((0+(Perl_gv_add_by_type(((PerlInterpreter *)pthread_getspecific(PL_thr_key)),
PerlInterpreter
Re: Maybe it's time to get rid of tcpwrappers/tcpd?
On 03/28/2014 02:44 PM, Reindl Harald wrote: - every change in sshd_config has to be confirmed by sshd restart, while changing hosts.deny doesn't need any other action no - try it out! make a fatal syntax error in sshd_config and in case of a remote machine make sure you don't close the last connection because you will not reach the machine again otherwise [14:46:53 root@malas ~ ]# /usr/sbin/sshd -T /etc/ssh/sshd_config: line 157: Bad configuration option: blbla /etc/ssh/sshd_config line 157: Directive 'blbla' is not allowed within a Match block [14:46:55 root@malas ~ ]# ssh localhost Fedora release 21 (Rawhide) root@localhost's password: Petr -- Petr Lautrbach Security Technologies Red Hat Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com. signature.asc Description: OpenPGP digital 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
[perl-Role-Tiny] Break build-cycle
commit 22172ce5259b1d3edf02b645b3eaad967d96508f
Author: Petr Písař ppi...@redhat.com
Date: Fri Mar 28 14:42:19 2014 +0100
Break build-cycle
perl-Role-Tiny → perl-namespace-autoclean → perl-Moose → perl-Test-Spelling
→
perl-Pod-Spell → perl-File-ShareDir-ProjectDistDir → perl-Path-IsDev →
perl-Role-Tiny
perl-Role-Tiny.spec | 12 +++-
1 files changed, 11 insertions(+), 1 deletions(-)
---
diff --git a/perl-Role-Tiny.spec b/perl-Role-Tiny.spec
index 766eedf..24b4f01 100644
--- a/perl-Role-Tiny.spec
+++ b/perl-Role-Tiny.spec
@@ -1,6 +1,6 @@
Name: perl-Role-Tiny
Version:1.003002
-Release:1%{?dist}
+Release:2%{?dist}
Summary:A nouvelle cuisine portion size slice of Moose
License:GPL+ or Artistic
Group: Development/Libraries
@@ -16,7 +16,12 @@ BuildRequires: perl(Exporter)
BuildRequires: perl(ExtUtils::MakeMaker)
BuildRequires: perl(lib)
BuildRequires: perl(mro)
+%if !%{defined perl_bootstrap}
+# Cycle: perl-Role-Tiny → perl-namespace-autoclean → perl-Moose →
+# perl-Test-Spelling → perl-Pod-Spell → perl-File-ShareDir-ProjectDistDir →
+# perl-Path-IsDev → perl-Role-Tiny
BuildRequires: perl(namespace::autoclean)
+%endif
BuildRequires: perl(Test::Fatal) = 0.003
BuildRequires: perl(Test::More) = 0.96
BuildRequires: perl(strict)
@@ -55,6 +60,11 @@ make test
%{_mandir}/man3/*
%changelog
+* Tue Mar 25 2014 Petr Pisar ppi...@redhat.com - 1.003002-2
+- Break build-cycle: perl-Role-Tiny → perl-namespace-autoclean → perl-Moose →
+ perl-Test-Spelling → perl-Pod-Spell → perl-File-ShareDir-ProjectDistDir →
+ perl-Path-IsDev → perl-Role-Tiny
+
* Fri Oct 18 2013 Miro Hrončok mhron...@redhat.com - 1.003002-1
- 1.003002 bump
--
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
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-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Heads up: Mesa/LLVM rebase and OpenGTL retirement in F20
On Fri, 2014-03-28 at 16:45 +0100, Kalev Lember wrote: On 03/28/2014 04:37 PM, Adam Jackson wrote: RHEL's Mesa at this point links against a private build of llvm that is explicitly _not_ part of The Platform, for exactly this reason: it's not something we can commit to supporting for any use beyond Mesa itself, even in the extreme short term. This might be a good way forward for Fedora as well to avoid changing the system-wide llvm ABI mid release. Eh. We've done an llvm rebase before: dmt:~% koji -q latest-pkg f18 llvm llvm-3.1-11.fc18 f18 salimma dmt:~% koji -q latest-pkg f18-updates llvm llvm-3.3-0.4.rc2.fc18 f18-updates ajax People were pretty eager for it then, too, and we even did it _because_ we wanted a Mesa rebase to go with it. llvm upstream doesn't do stable branches, so there's really not a good solution here. And tbf llvm really is a research project more than a compiler in a lot of ways, anyone building against it is going to discover they're building on sand eventually, regardless of when Fedora updates it. That said I'm not intrinsically opposed to doing, say, compat-llvm (in fact I suggested it in F18). Though if I had to choose between that and mesa-private-llvm in Fedora... I dunno, they're both kind of terrible. compat-llvm would let us stick to the rule about not shipping the same source in two packages, but m-p-l might have marginally better performance. Neither one seems as sane to me as just accepting llvm as not actually ABI. - 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: Heads up: Mesa/LLVM rebase and OpenGTL retirement in F20
On Thu, 2014-03-27 at 22:25 -0400, Jens Petersen wrote: 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. Thanks for letting me know! ghc doesn't show up as an llvm-libs consumer on amd64 so I hadn't caught this. Is it possible to build the llvm backend on other arches, even if only locally? That might at least allow me to shake out issues with the llvm code outside of actual codegen. - 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 Self Contained Change: Apache Mesos
Jaroslav Reznik (jrez...@redhat.com) said: - 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. Makes sense. Perhaps part of FESCo approval could be filling that field in where necessary. 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
Re: Heads up: Mesa/LLVM rebase and OpenGTL retirement in F20
On Fri, Mar 28, 2014 at 11:37:24AM -0400, Adam Jackson wrote: It might be nice if Fedora adopted the common practice (among other OSes with interface assurances) of at least attempting to define stability levels. Whose action item would that be? Agreed, and, FESCo. -- Matthew Miller-- Fedora Project--mat...@fedoraproject.org Tepid change for the somewhat better! -- 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
Matthew Miller (mat...@fedoraproject.org) said: On Fri, Mar 28, 2014 at 11:37:24AM -0400, Adam Jackson wrote: It might be nice if Fedora adopted the common practice (among other OSes with interface assurances) of at least attempting to define stability levels. Whose action item would that be? Agreed, and, FESCo. The fun part would be whether we start enforcing that *in* Fedora, or whether we keep the current policy that anything in the Fedora repository is an acceptable ABI to use for anything else in the Fedora repository. (To be clear, I don't think that scales in the long term.) 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
[Bug 1072256] perl-Date-Manip-6.43 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1072256 Petr Šabata psab...@redhat.com changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-Date-Manip-6.43-1.fc21 Resolution|--- |RAWHIDE Last Closed||2014-03-28 14:38:07 -- 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=2nvY2ZvkIFa=cc_unsubscribe -- 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: Desktop racing problem in F20
On Fri, 28 Mar 2014 10:53:23 -0600 Stephen John Smoogen smo...@gmail.com wrote: Well I have seen all of these in the last 2 weeks on Fedora 19 so I am not sure what exactly is going on. Thanks for sharing. Perhaps some bad updates went in? If we only see the 3 areas, it may be 3 unrelated bugs. I just asked in case there are 10 races. Did you file any bugs? I'll be happy to dedup. -- 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
Re: Maybe it's time to get rid of tcpwrappers/tcpd?
On Thu, 20 Mar 2014 20:05:21 +0100 Lennart Poettering mzerq...@0pointer.de wrote: Well, all mails servers as well as sshd have much better ways to do such filtering. sshd has Match, The sshd's Match does not have any historic criteria (e.g. sshd does not keep a database of previous login attempts). It is not possible to import an address match from elsewhere either (where e.g. denyhosts could write it). In short, Match cannot replay fail2ban and denyhosts, as far as I can see. I think your original idea of using firewalls was better. Someone just has to implement it. Unfortunately, I'm neck-deep in cloud storage at the moment, so I'm not volunteering. -- 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
Re: Maybe it's time to get rid of tcpwrappers/tcpd?
On Thu, 20 Mar 2014 18:34:22 +0100 Lennart Poettering mzerq...@0pointer.de wrote: I doubt there are many people even using them anymore, firewalls are more comprehensive and a lot more powerful, and while every admin knows firewalls, I figure only very few know tcpd/tcpwrap, and even fewer ever actively make use of them... I use tcpwrappers through denyhosts, which write out /etc/hosts.deny. Then openssh-server then uses the tcpwrappers to apply the rules (AFAIK). When I investigated it, denyhosts was superior to fail2ban due to the latter doing some crazy stuff with iptables that made me uncomfortable. Also, this: Installing: fail2ban noarch 0.9-0.3.git1f1a561.fc20fedora 261 k Installing for dependencies: ed x86_64 1.10-1.fc20updates 72 k gamin-python x86_64 0.1.10-15.fc20 fedora 34 k python-inotify noarch 0.9.4-4.fc20 fedora 49 k systemd-python x86_64 208-15.fc20updates 80 k I agree that tcpwrappers should die in favour of firewalls. Folks working on fail2ban are already considering integration with firewalld, which seems like a great idea. Too bad fail2ban is just as crusty as tcpwrappers. If we only had denyhosts that executed firewall-cmd... -- 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
Planned Outage: Mass reboots/Upgrades - 2014-04-01 21:00 UTC
Planned Outage: Mass reboots/Upgrades - 2014-04-01 21:00 UTC There will be an outage starting at 2014-04-01 21:00 UTC, which will last approximately 4 hours. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d '2014-04-01 21:00 UTC' Reason for outage: We will be rebooting all servers to pick up the latest system updates. Additionally we will be upgrading the koji build system to 1.9.0. During the outage window some services may be down and then back up again, but no single service should be down more than a few minutes, and some services may not be affected at all. Affected Services: Ask Fedora - http://ask.fedoraproject.org/ Badges - https://badges.fedoraproject.org/ BFO - http://boot.fedoraproject.org/ Blockerbugs - https://qa.fedoraproject.org/blockerbugs/ Bodhi - https://admin.fedoraproject.org/updates/ Buildsystem - http://koji.fedoraproject.org/ GIT / Source Control - pkgs.fedoraproject.org Darkserver - https://darkserver.fedoraproject.org/ DNS - ns-sb01.fedoraproject.org, ns02.fedoraproject.org, ns04.fedoraproject.org, ns05.fedoraproject.org Docs - http://docs.fedoraproject.org/ Elections - https://admin.fedoraproject.org/voting Email system Fedmsg busmon - http://apps.fedoraproject.org/busmon Fedora Account System - https://admin.fedoraproject.org/accounts/ Fedora Community - https://admin.fedoraproject.org/community/ Fedora Calendar - https://apps.fedoraproject.org/calendar/ Fedora Hosted - https://fedorahosted.org/ Fedora OpenID - https://id.fedoraproject.org/ Fedora People - http://fedorapeople.org/ Main Website - http://fedoraproject.org/ Mirror List - https://mirrors.fedoraproject.org/ Mirror Manager - https://admin.fedoraproject.org/mirrormanager/ Package Database - https://admin.fedoraproject.org/pkgdb/ QA Services Secondary Architectures Spins - http://spins.fedoraproject.org/ Start - http://start.fedoraproject.org/ Torrent - http://torrent.fedoraproject.org/ Wiki - http://fedoraproject.org/wiki/ Unaffected Services: Contact Information: Ticket Link: https://fedorahosted.org/fedora-infrastructure/ticket/4280 Please join #fedora-admin or #fedora-noc on irc.freenode.net or add comments to the ticket for this outage above. signature.asc Description: PGP signature ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: rawhide report: 20140328 changes
On Fri, 28 Mar 2014 16:04:29 -0400 Corey Sheldon sheldon.co...@gmail.com wrote: question on binutils for fc21 attempted to update via fc21 and rawide repos and got a norepomd errordid the baseurl change for fc21 ? no. Sounds like it might be a transitory mirror issue? If it persists, paste the entire output of the yum update for us? kevin signature.asc 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: Heads up: Mesa/LLVM rebase and OpenGTL retirement in F20
Kalev Lember wrote: This might be a good way forward for Fedora as well to avoid changing the system-wide llvm ABI mid release. No, most definitely not! Let me introduce you to our old friend, the symbol conflict. By way of libGL linking LLVM, if some other library uses a private LLVM, and an application links both libGL and that library, it crashes due to symbol conflicts. And this is EXACTLY what already happened with OpenGTL on several distributions, including Fedora: http://www.valdyas.org/fading/index.cgi/2011/10/08#llvm The only fix for that issue, and the one we implemented, was linking OpenGTL (and also Mesa, which had also been using a private LLVM before) against the system LLVM. The distros which didn't do that kept having that fatal crash. Now, it turns out that the current Krita no longer uses OpenGTL, and I'm not aware of any application using it, so I don't really care what you do to it anymore. (We already retired it in Rawhide.) But please DO NOT use a private LLVM in any other package (and especially not in Mesa – again, to avoid the symbol conflicts, BOTH Mesa AND the other LLVM-using package(s) MUST link to the shared LLVM library). You WILL hit this same issue. You have been warned. Kevin Kofler -- 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 1081883] New: perl-Scriptalicious-1.16 tests hang randomly
https://bugzilla.redhat.com/show_bug.cgi?id=1081883 Bug ID: 1081883 Summary: perl-Scriptalicious-1.16 tests hang randomly Product: Fedora Version: 20 Component: perl-Scriptalicious Assignee: ppi...@redhat.com Reporter: ppi...@redhat.com QA Contact: extras...@fedoraproject.org CC: mmasl...@redhat.com, perl-devel@lists.fedoraproject.org, ppi...@redhat.com t/04-fork.t tests hangs randomly in F20. -- 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=UH8eaRrbbIa=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 1081883] perl-Scriptalicious-1.16 tests hang randomly
https://bugzilla.redhat.com/show_bug.cgi?id=1081883 Petr Pisar ppi...@redhat.com changed: What|Removed |Added External Bug ID||CPAN 85999 -- 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=QWY9MJzChga=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 #23 from Dan Horák d...@danny.cz --- (In reply to Carlos O'Donell from comment #22) (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. oh, I did the same couple days ago, but forgot to mention it here :-) -- 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=Ps5EmIVWhua=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 Tomas Hoger tho...@redhat.com changed: What|Removed |Added Whiteboard|impact=important,public=201 |impact=important,public=201 |40327,reported=20140318,sou |40327,reported=20140318,sou |rce=distros,cvss2=6.8/AV:N/ |rce=distros,cvss2=6.8/AV:N/ |AC:M/Au:N/C:P/I:P/A:P,rhel- |AC:M/Au:N/C:P/I:P/A:P,rhel- |6/libyaml=affected,rhel-7/l |6/libyaml=affected,rhel-7/l |ibyaml=affected,rhscl-1/lib |ibyaml=affected,rhscl-1/rub |yaml=affected,mrg-1/libyaml |y193-libyaml=affected,rhscl |=wontfix,mrg-2/libyaml=wont |-1/libyaml=affected,mrg-1/l |fix,rhn_satellite_5.3/libya |ibyaml=wontfix,mrg-2/libyam |ml=affected,rhn_satellite_5 |l=wontfix,rhn_satellite_5.3 |.4/libyaml=affected,rhn_sat |/libyaml=affected,rhn_satel |ellite_5.5/libyaml=affected |lite_5.4/libyaml=affected,r |,rhn_satellite_5.6/libyaml= |hn_satellite_5.5/libyaml=af |affected,rhn_satellite_6/li |fected,rhn_satellite_5.6/li |byaml=affected,rhui-2/libya |byaml=affected,rhn_satellit |ml=wontfix,sam-1/libyaml=af |e_6/libyaml=affected,rhui-2 |fected,cfme-5/mingw-libyaml |/libyaml=wontfix,sam-1/liby |=affected,cfme-5/ruby193-li |aml=affected,cfme-5/mingw-l |byaml=affected,openstack-3/ |ibyaml=affected,cfme-5/ruby |libyaml=affected,openstack- |193-libyaml=affected,openst |3/ruby193-libyaml=affected, |ack-3/libyaml=affected,open |openstack-4/libyaml=affecte |stack-3/ruby193-libyaml=aff |d,openshift-enterprise-1/ru |ected,openstack-4/libyaml=a |by193-libyaml=affected,open |ffected,openshift-enterpris |shift-1/ruby193-libyaml=aff |e-1/ruby193-libyaml=affecte |ected,fedora-all/libyaml=af |d,openshift-1/ruby193-libya |fected,epel-all/libyaml=aff |ml=affected,fedora-all/liby |ected,fedora-all/perl-YAML- |aml=affected,epel-all/libya |LibYAML=affected,epel-6/per |ml=affected,fedora-all/perl |l-YAML-LibYAML=affected |-YAML-LibYAML=affected,epel ||-6/perl-YAML-LibYAML=affect ||ed -- 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=QPep8q3XUVa=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 Tomas Hoger tho...@redhat.com changed: What|Removed |Added Whiteboard|impact=moderate,public=2014 |impact=moderate,public=2014 |0127,reported=20131122,sour |0127,reported=20131122,sour |ce=redhat,cvss2=4.3/AV:A/AC |ce=redhat,cvss2=4.3/AV:A/AC |:H/Au:N/C:P/I:P/A:P,rhel-6/ |:H/Au:N/C:P/I:P/A:P,rhel-6/ |libyaml=affected,rhel-7/lib |libyaml=affected,rhel-7/lib |yaml=affected,rhscl-1/libya |yaml=affected,rhscl-1/ruby1 |ml=affected,fedora-all/liby |93-libyaml=affected,rhscl-1 |aml=affected,epel-all/libya |/libyaml=affected,fedora-al |ml=affected,mrg-1/libyaml=w |l/libyaml=affected,epel-all |ontfix,mrg-2/libyaml=wontfi |/libyaml=affected,mrg-1/lib |x,rhn_satellite_5.3/libyaml |yaml=wontfix,mrg-2/libyaml= |=wontfix,rhn_satellite_5.4/ |wontfix,rhn_satellite_5.3/l |libyaml=wontfix,rhn_satelli |ibyaml=wontfix,rhn_satellit |te_5.5/libyaml=wontfix,rhn_ |e_5.4/libyaml=wontfix,rhn_s |satellite_5.6/libyaml=wontf |atellite_5.5/libyaml=wontfi |ix,rhn_satellite_6/libyaml= |x,rhn_satellite_5.6/libyaml |affected,rhn_satellite_6/ru |=wontfix,rhn_satellite_6/li |by193-libyaml=affected,rhui |byaml=affected,rhn_satellit |-2/libyaml=defer,sam-1/liby |e_6/ruby193-libyaml=affecte |aml=defer,cfme-5/mingw-liby |d,rhui-2/libyaml=defer,sam- |aml=wontfix,cfme-5/ruby193- |1/libyaml=defer,cfme-5/ming |libyaml=wontfix,openstack-3 |w-libyaml=wontfix,cfme-5/ru |/libyaml=affected,openstack |by193-libyaml=wontfix,opens |-3/ruby193-libyaml=affected |tack-3/libyaml=affected,ope |,openstack-4/libyaml=affect |nstack-3/ruby193-libyaml=af |ed,openshift-enterprise-1/r |fected,openstack-4/libyaml= |uby193-libyaml=wontfix,open |affected,openshift-enterpri |shift-1/ruby193-libyaml=aff |se-1/ruby193-libyaml=wontfi |ected,fedora-all/perl-YAML- |x,openshift-1/ruby193-libya |LibYAML=affected,epel-6/per |ml=affected,fedora-all/perl |l-YAML-LibYAML=affected |-YAML-LibYAML=affected,epel ||-6/perl-YAML-LibYAML=affect ||ed -- 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=WGGM9wXR0ja=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-Test-LeakTrace] Break build-cycle
commit 1d73f407e71d3cae02055fdcf6da52189c060a12
Author: Petr Písař ppi...@redhat.com
Date: Thu Mar 27 17:32:16 2014 +0100
Break build-cycle
perl-Test-LeakTrace → perl-Test-Spelling → perl-Pod-Spell
→ perl-File-SharedDir-ProjectDistDir → perl-Path-Tiny → perl-Unicode-UTF8
→ perl-Test-LeakTrace
perl-Test-LeakTrace.spec | 12 +++-
1 files changed, 11 insertions(+), 1 deletions(-)
---
diff --git a/perl-Test-LeakTrace.spec b/perl-Test-LeakTrace.spec
index 9606c16..838e083 100644
--- a/perl-Test-LeakTrace.spec
+++ b/perl-Test-LeakTrace.spec
@@ -13,7 +13,7 @@
Name: perl-Test-LeakTrace
Summary: Trace memory leaks
Version: 0.14
-Release: 7%{?dist}
+Release: 8%{?dist}
License: GPL+ or Artistic
Group: Development/Libraries
URL: http://search.cpan.org/dist/Test-LeakTrace/
@@ -24,7 +24,12 @@ BuildRequires: perl(ExtUtils::MakeMaker) = 6.30
BuildRequires: perl(Test::More) = 0.62
BuildRequires: perl(Test::Pod) = 1.14
BuildRequires: perl(Test::Pod::Coverage) = 1.04
+%if !%{defined perl_bootstrap}
+# Cycle: perl-Test-LeakTrace → perl-Test-Spelling → perl-Pod-Spell
+# → perl-File-SharedDir-ProjectDistDir → perl-Path-Tiny → perl-Unicode-UTF8
+# → perl-Test-LeakTrace
BuildRequires: perl(Test::Spelling), %{speller}-en
+%endif
BuildRequires: perl(Test::Synopsis)
%if 0%{?with_valgrind}
BuildRequires: perl(Test::Valgrind)
@@ -99,6 +104,11 @@ rm -rf %{buildroot}
%{_mandir}/man3/Test::LeakTrace::Script.3pm*
%changelog
+* Tue Mar 25 2014 Petr Pisar ppi...@redhat.com - 0.14-8
+- Break build-cycle: perl-Test-LeakTrace → perl-Test-Spelling → perl-Pod-Spell
+ → perl-File-SharedDir-ProjectDistDir → perl-Path-Tiny → perl-Unicode-UTF8
+ → perl-Test-LeakTrace
+
* Sun Aug 04 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 0.14-7
- Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File ctstream-17 uploaded to lookaside cache by ppisar
A file has been added to the lookaside cache for ctstream: 4ca09c556d000628b675edf0687d56d8 ctstream-17 -- 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
[ctstream] Version 17 bump
commit 14c203b2547c2c367c46ff0ba9a5ad5c584a6f62
Author: Petr Písař ppi...@redhat.com
Date: Fri Mar 28 09:51:17 2014 +0100
Version 17 bump
.gitignore|1 +
ctstream.spec |5 -
sources |2 +-
3 files changed, 6 insertions(+), 2 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index e774857..d0073dd 100644
--- a/.gitignore
+++ b/.gitignore
@@ -7,3 +7,4 @@
/ctstream-12
/ctstream-13
/ctstream-15
+/ctstream-17
diff --git a/ctstream.spec b/ctstream.spec
index dbb4f39..58e5737 100644
--- a/ctstream.spec
+++ b/ctstream.spec
@@ -1,5 +1,5 @@
Name: ctstream
-Version:15
+Version:17
Release:1%{?dist}
Summary:Get URLs of Czech Television video streams
Group: Applications/Internet
@@ -23,6 +23,9 @@ install %{SOURCE0} %{buildroot}%{_bindir}/%{name}
%{_bindir}/*
%changelog
+* Fri Mar 28 2014 Petr Pisar ppi...@redhat.com - 17-1
+- Version 17 bump
+
* Mon Feb 17 2014 Petr Pisar ppi...@redhat.com - 15-1
- Version 15 bump
diff --git a/sources b/sources
index b8dc71b..8487afa 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-ee75490936cf8a559ba649cf54fee50c ctstream-15
+4ca09c556d000628b675edf0687d56d8 ctstream-17
--
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
[ctstream/f20] Version 17 bump
Summary of changes: 14c203b... Version 17 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
[ctstream/f19] Version 17 bump
commit 899ae57d90fc1b2e02b6a203eee79007b3323413
Author: Petr Písař ppi...@redhat.com
Date: Fri Mar 28 09:51:17 2014 +0100
Version 17 bump
.gitignore|1 +
ctstream.spec |5 -
sources |2 +-
3 files changed, 6 insertions(+), 2 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index e774857..d0073dd 100644
--- a/.gitignore
+++ b/.gitignore
@@ -7,3 +7,4 @@
/ctstream-12
/ctstream-13
/ctstream-15
+/ctstream-17
diff --git a/ctstream.spec b/ctstream.spec
index 4198f61..b735853 100644
--- a/ctstream.spec
+++ b/ctstream.spec
@@ -1,5 +1,5 @@
Name: ctstream
-Version:15
+Version:17
Release:1%{?dist}
Summary:Get URLs of Czech Television video streams
Group: Applications/Internet
@@ -23,6 +23,9 @@ install %{SOURCE0} %{buildroot}%{_bindir}/%{name}
%{_bindir}/*
%changelog
+* Fri Mar 28 2014 Petr Pisar ppi...@redhat.com - 17-1
+- Version 17 bump
+
* Mon Feb 17 2014 Petr Pisar ppi...@redhat.com - 15-1
- Version 15 bump
diff --git a/sources b/sources
index b8dc71b..8487afa 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-ee75490936cf8a559ba649cf54fee50c ctstream-15
+4ca09c556d000628b675edf0687d56d8 ctstream-17
--
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 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 #24 from Dan Horák d...@danny.cz --- Created attachment 879767 -- https://bugzilla.redhat.com/attachment.cgi?id=879767action=edit output when running the test with LD_DEBUG=versions -- 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=ut6s2VMtJ9a=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 Devel-EnforceEncapsulation-0.51.tar.gz uploaded to lookaside cache by pghmcfc
A file has been added to the lookaside cache for perl-Devel-EnforceEncapsulation: 37bf6c85c0c6b03d0a80e76c8920ba48 Devel-EnforceEncapsulation-0.51.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-Devel-EnforceEncapsulation] Update to 0.51
commit 2bd65453484b2eae7a6df2333b652d90a85e88ae
Author: Paul Howarth p...@city-fan.org
Date: Fri Mar 28 10:07:20 2014 +
Update to 0.51
- New upstream release 0.51
- Fix for change in overload behavior in Perl 5.17 onwards (CPAN RT#77486)
- This release by CDOLAN - update source URL
.gitignore|1 +
Devel-EnforceEncapsulation-0.50-rt77486.patch | 31 -
perl-Devel-EnforceEncapsulation.spec | 17 +++--
sources |2 +-
4 files changed, 11 insertions(+), 40 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 28302f8..9914fd8 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1,2 @@
/Devel-EnforceEncapsulation-0.50.tgz
+/Devel-EnforceEncapsulation-[0-9.]*.tar.gz
diff --git a/perl-Devel-EnforceEncapsulation.spec
b/perl-Devel-EnforceEncapsulation.spec
index e05182c..cd7d2e1 100644
--- a/perl-Devel-EnforceEncapsulation.spec
+++ b/perl-Devel-EnforceEncapsulation.spec
@@ -1,12 +1,11 @@
Name: perl-Devel-EnforceEncapsulation
-Version: 0.50
-Release: 11%{?dist}
+Version: 0.51
+Release: 1%{?dist}
Summary: Find access violations to blessed objects
Group: Development/Libraries
License: GPL+ or Artistic
URL: http://search.cpan.org/dist/Devel-EnforceEncapsulation/
-Source0:
http://search.cpan.org/CPAN/authors/id/C/CL/CLOTHO/Devel-EnforceEncapsulation-%{version}.tgz
-Patch0:Devel-EnforceEncapsulation-0.50-rt77486.patch
+Source0:
http://search.cpan.org/CPAN/authors/id/C/CD/CDOLAN/Devel-EnforceEncapsulation-%{version}.tar.gz
BuildArch: noarch
BuildRequires: perl(Carp)
BuildRequires: perl(English)
@@ -47,9 +46,6 @@ life harder for downstream developers).
%prep
%setup -q -n Devel-EnforceEncapsulation-%{version}
-# Fix for change in overload behavior in Perl 5.17 onwards (CPAN RT#77486)
-%patch0
-
%build
perl Makefile.PL INSTALLDIRS=vendor
make %{?_smp_mflags}
@@ -63,11 +59,16 @@ find %{buildroot} -type f -name .packlist -exec rm -f {} \;
make test AUTHOR_TEST=1 AUTHOR_TEST_CDOLAN=1
%files
-%doc CHANGES LICENSE README index.html
+%doc CHANGES LICENSE README
%{perl_vendorlib}/Devel/
%{_mandir}/man3/Devel::EnforceEncapsulation.3pm*
%changelog
+* Fri Mar 28 2014 Paul Howarth p...@city-fan.org - 0.51-1
+- Update to 0.51
+ - Fix for change in overload behavior in Perl 5.17 onwards (CPAN RT#77486)
+- This release by CDOLAN - update source URL
+
* Sat Aug 03 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 0.50-11
- Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild
diff --git a/sources b/sources
index 345d376..7f138d2 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-434b5a9e99e1153282076680c9de29c5 Devel-EnforceEncapsulation-0.50.tgz
+37bf6c85c0c6b03d0a80e76c8920ba48 Devel-EnforceEncapsulation-0.51.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-Devel-EnforceEncapsulation] Created tag perl-Devel-EnforceEncapsulation-0.51-1.fc21
The lightweight tag 'perl-Devel-EnforceEncapsulation-0.51-1.fc21' was created pointing to: 2bd6545... Update to 0.51 -- 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 CPAN-Meta-Requirements-2.125.tar.gz uploaded to lookaside cache by pghmcfc
A file has been added to the lookaside cache for perl-CPAN-Meta-Requirements: 1cb395d655f47e28640374a196300ef2 CPAN-Meta-Requirements-2.125.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-CPAN-Meta-Requirements] Update to 2.125
commit 02ca4fbec50e96fe254b5f4156f11109e18b7ade
Author: Paul Howarth p...@city-fan.org
Date: Fri Mar 28 11:18:27 2014 +
Update to 2.125
- New upstream release 2.125
- On Perls prior to v5.12, CPAN::Meta::Requirements will force UNINST=1
when
necessary to remove stale copies from ExtUtils::MakeMaker
- Updated Makefile.PL logic to support PERL_NO_HIGHLANDER
- README.PATCHING renamed to CONTRIBUTING
- Classify buildreqs by usage
- Add note about logically-impossible constraints to %description
.gitignore |3 +-
perl-CPAN-Meta-Requirements.spec | 72 +++---
sources |2 +-
3 files changed, 46 insertions(+), 31 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 807c8c3..d8cc2c8 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,2 +1 @@
-/CPAN-Meta-Requirements-2.121.tar.gz
-/CPAN-Meta-Requirements-2.122.tar.gz
+/CPAN-Meta-Requirements-[0-9.]*.tar.gz
diff --git a/perl-CPAN-Meta-Requirements.spec b/perl-CPAN-Meta-Requirements.spec
index e9fa585..77e5475 100644
--- a/perl-CPAN-Meta-Requirements.spec
+++ b/perl-CPAN-Meta-Requirements.spec
@@ -1,37 +1,43 @@
Name: perl-CPAN-Meta-Requirements
-Version:2.122
-Release:292%{?dist}
+Version:2.125
+Release:1%{?dist}
Summary:Set of version requirements for a CPAN dist
License:GPL+ or Artistic
Group: Development/Libraries
URL:http://search.cpan.org/dist/CPAN-Meta-Requirements/
Source0:
http://www.cpan.org/authors/id/D/DA/DAGOLDEN/CPAN-Meta-Requirements-%{version}.tar.gz
BuildArch: noarch
-BuildRequires: perl(Carp)
+# Build
+BuildRequires: perl
BuildRequires: perl(ExtUtils::MakeMaker)
-BuildRequires: perl(File::Find)
-BuildRequires: perl(File::Temp)
+# Module
+BuildRequires: perl(Carp)
BuildRequires: perl(Scalar::Util)
-BuildRequires: perl(Test::More)
-%if !%{defined perl_bootstrap}
-BuildRequires: perl(Test::Script)
-%endif
BuildRequires: perl(version) = 0.77
-# for author/release tests
+# Test
+BuildRequires: perl(File::Spec::Functions)
+BuildRequires: perl(File::Temp)
+BuildRequires: perl(IO::Handle)
+BuildRequires: perl(IPC::Open3)
+BuildRequires: perl(List::Util)
+BuildRequires: perl(Test::More)
+# Extra Tests (not run when bootstrapping due to circular build dependencies)
%if !%{defined perl_bootstrap} ! ( 0%{?rhel} )
+BuildRequires: perl(English)
BuildRequires:
perl(Perl::Critic::Policy::Lax::ProhibitStringyEval::ExceptForRequire)
+BuildRequires: perl(Perl::Critic::Policy::Miscellanea::RequireRcsKeywords)
BuildRequires: perl(Pod::Coverage::TrustPod)
BuildRequires: perl(Pod::Wordlist::hanekomu)
BuildRequires: perl(Test::CPAN::Meta)
+BuildRequires: perl(Test::MinimumVersion)
BuildRequires: perl(Test::Perl::Critic)
-BuildRequires: perl(Test::Pod)
-BuildRequires: perl(Test::Pod::Coverage)
+BuildRequires: perl(Test::Pod) = 1.41
+BuildRequires: perl(Test::Pod::Coverage) = 1.08
BuildRequires: perl(Test::Portability::Files)
-BuildRequires: perl(Test::Requires)
-BuildRequires: perl(Test::Spelling) aspell-en
-BuildRequires: perl(Test::Version)
+BuildRequires: perl(Test::Spelling) = 0.12, aspell-en
+BuildRequires: perl(Test::Version) = 0.04
%endif
-
+# Runtime
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
%{?perl_default_filter}
@@ -44,9 +50,12 @@ Provides: perl(CPAN::Meta::Requirements) =
%{version}000
%description
A CPAN::Meta::Requirements object models a set of version constraints like
-those specified in the META.yml or META.json files in CPAN distributions.
-It can be built up by adding more and more constraints, and it will reduce
-them to the simplest representation.
+those specified in the META.yml or META.json files in CPAN distributions. It
+can be built up by adding more and more constraints, and it will reduce them
+to the simplest representation.
+
+Logically impossible constraints will be identified immediately by thrown
+exceptions.
%prep
%setup -q -n CPAN-Meta-Requirements-%{version}
@@ -57,23 +66,30 @@ make %{?_smp_mflags}
%install
make pure_install DESTDIR=%{buildroot}
-
find %{buildroot} -type f -name .packlist -exec rm -f {} \;
-
-%{_fixperms} %{buildroot}/*
+%{_fixperms} %{buildroot}
%check
-%if %{defined perl_bootstrap} || ( 0%{?rhel} )
-rm -rf xt
+make test AUTHOR_TESTING=1
+%if !%{defined perl_bootstrap} ! ( 0%{?rhel} )
+make test TEST_FILES=$(echo $(find xt/ -name '*.t'))
%endif
-make test TEST_FILES=t/*.t xt/*/*.t
%files
-%doc Changes LICENSE perlcritic.rc README README.PATCHING
-%{perl_vendorlib}/*
-%{_mandir}/man3/*
+%doc Changes CONTRIBUTING LICENSE perlcritic.rc README
+%{perl_vendorlib}/CPAN/
+%{_mandir}/man3/CPAN::Meta::Requirements.3pm*
%changelog
+* Fri Mar 28 2014 Paul Howarth p...@city-fan.org - 2.125-1
+- Update to 2.125
+ - On Perls prior to v5.12, CPAN::Meta::Requirements will
[perl-CPAN-Meta-Requirements] Created tag perl-CPAN-Meta-Requirements-2.125-1.fc21
The lightweight tag 'perl-CPAN-Meta-Requirements-2.125-1.fc21' was created pointing to: 02ca4fb... Update to 2.125 -- 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 Michal Toman mto...@redhat.com changed: What|Removed |Added CC||mto...@redhat.com --- Comment #25 from Michal Toman mto...@redhat.com --- Running the build step by step I've found that a simple 'use Net::SSLeay' causes a segfault when used with the newer glibc. Attaching a backtrace. -- 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=SF3xG0m0Sia=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 #26 from Michal Toman mto...@redhat.com --- Created attachment 879794 -- https://bugzilla.redhat.com/attachment.cgi?id=879794action=edit backtrace -- 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=EeMDR1z56wa=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-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: 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
File Perl-Tidy-20140328.tar.gz uploaded to lookaside cache by pghmcfc
A file has been added to the lookaside cache for perltidy: a33f908663934bdd67aa915e25f89f45 Perl-Tidy-20140328.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
[perltidy] Created tag perltidy-20140328-1.fc21
The lightweight tag 'perltidy-20140328-1.fc21' was created pointing to: 8f4ac8b... Update to 20140328 -- 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 Date-Manip-6.43.tar.gz uploaded to lookaside cache by psabata
A file has been added to the lookaside cache for perl-Date-Manip: 205d4a158d367dffaca217d55679a51a Date-Manip-6.43.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-Date-Manip] 6.43 bump, no code changes
commit 22201ff9ace9af0cfead1559540aad5e4458dd17
Author: Petr Šabata con...@redhat.com
Date: Fri Mar 28 19:34:15 2014 +0100
6.43 bump, no code changes
.gitignore |1 +
perl-Date-Manip.spec |7 +--
sources |2 +-
3 files changed, 7 insertions(+), 3 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 5292193..40fb8ca 100644
--- a/.gitignore
+++ b/.gitignore
@@ -20,3 +20,4 @@ Date-Manip-6.07.tar.gz
/Date-Manip-6.40.tar.gz
/Date-Manip-6.41.tar.gz
/Date-Manip-6.42.tar.gz
+/Date-Manip-6.43.tar.gz
diff --git a/perl-Date-Manip.spec b/perl-Date-Manip.spec
index 6500bee..5ecc514 100644
--- a/perl-Date-Manip.spec
+++ b/perl-Date-Manip.spec
@@ -1,5 +1,5 @@
Name: perl-Date-Manip
-Version:6.42
+Version:6.43
Release:1%{?dist}
Summary:Date manipulation routines
Group: Development/Libraries
@@ -55,12 +55,15 @@ perl Build.PL installdirs=vendor
./Build test
%files
-%doc HISTORY LICENSE README README.first
+%doc LICENSE README README.first
%{perl_vendorlib}/Date/
%{_mandir}/man[13]/*.[13]*
%{_bindir}/dm_*
%changelog
+* Fri Mar 28 2014 Petr Šabata con...@redhat.com - 6.43-1
+- 6.43 bump, no code changes
+
* Tue Dec 03 2013 Petr Pisar ppi...@redhat.com - 6.42-1
- 6.42 bump
diff --git a/sources b/sources
index 31c78de..286a274 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-70ec592364c3f7f5aea26a852f2dc8ed Date-Manip-6.42.tar.gz
+205d4a158d367dffaca217d55679a51a Date-Manip-6.43.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
File Net-GitHub-0.57.tar.gz uploaded to lookaside cache by psabata
A file has been added to the lookaside cache for perl-Net-GitHub: b6a7426ebca1f2ee4d47e101530059b3 Net-GitHub-0.57.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-Net-GitHub] 0.57, POD fixes
commit 9d552a01e20ea4a72d1cb9da64c6235440347aee
Author: Petr Šabata con...@redhat.com
Date: Fri Mar 28 20:04:01 2014 +0100
0.57, POD fixes
.gitignore |1 +
perl-Net-GitHub.spec |5 -
sources |2 +-
3 files changed, 6 insertions(+), 2 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 1950647..0da406d 100644
--- a/.gitignore
+++ b/.gitignore
@@ -16,3 +16,4 @@ Net-GitHub-0.22.tar.gz
/Net-GitHub-0.54.tar.gz
/Net-GitHub-0.55.tar.gz
/Net-GitHub-0.56.tar.gz
+/Net-GitHub-0.57.tar.gz
diff --git a/perl-Net-GitHub.spec b/perl-Net-GitHub.spec
index f26fa2d..be950f9 100644
--- a/perl-Net-GitHub.spec
+++ b/perl-Net-GitHub.spec
@@ -1,6 +1,6 @@
Name: perl-Net-GitHub
Summary:Perl interface for github.com
-Version:0.56
+Version:0.57
Release:1%{?dist}
License:GPL+ or Artistic
Group: Development/Libraries
@@ -52,6 +52,9 @@ make test
%{_mandir}/man3/*.3*
%changelog
+* Fri Mar 28 2014 Petr Šabata con...@redhat.com - 0.57-1
+- 0.57, POD fixes
+
* Tue Feb 25 2014 Petr Šabata con...@redhat.com - 0.56-1
- 0.56 bump
diff --git a/sources b/sources
index 673aa46..17d9d14 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-cafc46564d625bc89fb3bfcc9093520f Net-GitHub-0.56.tar.gz
+b6a7426ebca1f2ee4d47e101530059b3 Net-GitHub-0.57.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1073958] perl-Net-GitHub-0.57 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1073958 Petr Šabata psab...@redhat.com changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-Net-GitHub-0.57-1.fc21 Resolution|--- |RAWHIDE Last Closed||2014-03-28 15:04:52 -- 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=4wupTZfmZ2a=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 Test-Strict-0.23.tar.gz uploaded to lookaside cache by psabata
A file has been added to the lookaside cache for perl-Test-Strict: 582ccb43e24bcad40aaf00a24b5311fb Test-Strict-0.23.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-Test-Strict] 0.23 bump, warnings and strict API change
commit 660e9fc594375e16c15d2a9bf32bc67366571520
Author: Petr Šabata con...@redhat.com
Date: Fri Mar 28 20:14:23 2014 +0100
0.23 bump, warnings and strict API change
.gitignore|1 +
perl-Test-Strict.spec | 22 ++
sources |2 +-
3 files changed, 16 insertions(+), 9 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index f6e2c02..abbca5d 100644
--- a/.gitignore
+++ b/.gitignore
@@ -6,3 +6,4 @@ Test-Strict-0.13.tar.gz
/Test-Strict-0.20.tar.gz
/Test-Strict-0.21.tar.gz
/Test-Strict-0.22.tar.gz
+/Test-Strict-0.23.tar.gz
diff --git a/perl-Test-Strict.spec b/perl-Test-Strict.spec
index 895b212..9a28ded 100644
--- a/perl-Test-Strict.spec
+++ b/perl-Test-Strict.spec
@@ -1,24 +1,27 @@
Name: perl-Test-Strict
-Version:0.22
-Release:2%{?dist}
+Version:0.23
+Release:1%{?dist}
# see lib/Test/Strict.pm
License:GPL+ or Artistic
Group: Development/Libraries
Summary:Check syntax, presence of use strict/warnings, and test coverage
Source:
http://search.cpan.org/CPAN/authors/id/S/SZ/SZABGAB/Test-Strict-%{version}.tar.gz
Url:http://search.cpan.org/dist/Test-Strict
-Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
+Requires: perl(:MODULE_COMPAT_%(eval $(perl -V:version); echo $version))
BuildArch: noarch
-BuildRequires: perl(Devel::Cover)
+BuildRequires: perl
+BuildRequires: perl(Config)
BuildRequires: perl(ExtUtils::MakeMaker)
BuildRequires: perl(File::Find)
+BuildRequires: perl(File::Spec)
BuildRequires: perl(File::Temp)
BuildRequires: perl(FindBin)
-BuildRequires: perl(Moose)
-BuildRequires: perl(Moose::Autobox)
+BuildRequires: perl(strict)
BuildRequires: perl(Test::Builder)
BuildRequires: perl(Test::More)
-BuildRequires: perl(Test::Pod)
+BuildRequires: perl(Test::Pod) = 1.00
+BuildRequires: perl(Test::Pod::Coverage) = 1.00
+BuildRequires: perl(vars)
%description
Test::Strict lets you check the syntax, presence of use strict; and
@@ -34,7 +37,7 @@ make %{?_smp_mflags}
%install
make pure_install DESTDIR=%{buildroot}
-find %{buildroot} -type f -name .packlist -exec rm -f {} ';'
+find %{buildroot} -type f -name .packlist -exec rm -f {} +
%{_fixperms} %{buildroot}/*
%check
@@ -46,6 +49,9 @@ make test
%{_mandir}/man3/*.3*
%changelog
+* Fri Mar 28 2014 Petr Šabata con...@redhat.com - 0.23-1
+- 0.23 bump, warnings and strict API change
+
* Sat Aug 03 2013 Petr Pisar ppi...@redhat.com - 0.22-2
- Perl 5.18 rebuild
diff --git a/sources b/sources
index 19ca602..8f863ac 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-41b588f3a376a574747b38641dbf2cf8 Test-Strict-0.22.tar.gz
+582ccb43e24bcad40aaf00a24b5311fb Test-Strict-0.23.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1073964] perl-Test-Strict-0.23 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1073964 Petr Šabata psab...@redhat.com changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-Test-Strict-0.23-1.fc2 ||1 Resolution|--- |RAWHIDE Last Closed||2014-03-28 15:17:11 -- 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=uEWa1Yc7dYa=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 MooX-HandlesVia-0.001005.tar.gz uploaded to lookaside cache by corsepiu
A file has been added to the lookaside cache for perl-MooX-HandlesVia: 298db139865d00bcdcb73190d22884c4 MooX-HandlesVia-0.001005.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-MooX-HandlesVia] Initial Import.
commit 694d4cffa58104fd0f3566bf7c5fdf5b3ddfe22a
Author: Ralf Corsépius corse...@fedoraproject.org
Date: Sat Mar 29 04:03:42 2014 +0100
Initial Import.
.gitignore|1 +
perl-MooX-HandlesVia.spec | 76 +
sources |1 +
3 files changed, 78 insertions(+), 0 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index e69de29..4ec0ae9 100644
--- a/.gitignore
+++ b/.gitignore
@@ -0,0 +1 @@
+/MooX-HandlesVia-0.001005.tar.gz
diff --git a/perl-MooX-HandlesVia.spec b/perl-MooX-HandlesVia.spec
new file mode 100644
index 000..fcb8e7d
--- /dev/null
+++ b/perl-MooX-HandlesVia.spec
@@ -0,0 +1,76 @@
+Name: perl-MooX-HandlesVia
+Version:0.001005
+Release:2%{?dist}
+Summary:NativeTrait-like behavior for Moo
+License:GPL+ or Artistic
+Group: Development/Libraries
+URL:http://search.cpan.org/dist/MooX-HandlesVia/
+Source0:
http://www.cpan.org/authors/id/M/MA/MATTP/MooX-HandlesVia-%{version}.tar.gz
+BuildArch: noarch
+BuildRequires: perl(Class::Method::Modifiers)
+BuildRequires: perl(Data::Perl) = 0.002006
+BuildRequires: perl(ExtUtils::MakeMaker) = 6.30
+BuildRequires: perl(Module::Runtime)
+BuildRequires: perl(Moo) = 1.003000
+BuildRequires: perl(Moo::Role)
+BuildRequires: perl(MooX::Types::MooseLike::Base) = 0.23
+BuildRequires: perl(Role::Tiny::With)
+BuildRequires: perl(Test::Exception)
+BuildRequires: perl(Test::Fatal)
+BuildRequires: perl(Test::More)
+BuildRequires: perl(namespace::autoclean)
+BuildRequires: perl(namespace::clean)
+BuildRequires: perl(overload)
+BuildRequires: perl(strict)
+BuildRequires: perl(strictures) = 1
+BuildRequires: perl(warnings)
+
+# Redundant to BR: perl(Data::Perl)
+BuildRequires: perl(Data::Perl::Role::Bool)
+BuildRequires: perl(Data::Perl::Role::Code)
+BuildRequires: perl(Data::Perl::Role::Collection::Array)
+BuildRequires: perl(Data::Perl::Role::Collection::Hash)
+BuildRequires: perl(Data::Perl::Role::Counter)
+BuildRequires: perl(Data::Perl::Role::Number)
+BuildRequires: perl(Data::Perl::Role::String)
+
+Requires: perl(Data::Perl) = 0.002006
+Requires: perl(Moo) = 1.003000
+Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
+
+%description
+MooX::HandlesVia is an extension of Moo's 'handles' attribute
+functionality. It provides a means of proxying functionality from an
+external class to the given atttribute. This is most commonly used as a way
+to emulate 'Native Trait' behavior that has become commonplace in Moose
+code, for which there was no Moo alternative.
+
+%prep
+%setup -q -n MooX-HandlesVia-%{version}
+
+%build
+%{__perl} Makefile.PL INSTALLDIRS=vendor
+make %{?_smp_mflags}
+
+%install
+make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT
+
+find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
+
+%{_fixperms} $RPM_BUILD_ROOT/*
+
+%check
+make test
+
+%files
+%doc Changes LICENSE README TODO
+%{perl_vendorlib}/*
+%{_mandir}/man3/*
+
+%changelog
+* Tue Mar 25 2014 Ralf Corsépius corse...@fedoraproject.org 0.001005-2
+- Reflect review.
+- Do not package dist.ini, README.mkdn, META.json.
+
+* Fri Mar 21 2014 Ralf Corsépius corse...@fedoraproject.org 0.001005-1
+- Initial Fedora package.
diff --git a/sources b/sources
index e69de29..6790f50 100644
--- a/sources
+++ b/sources
@@ -0,0 +1 @@
+298db139865d00bcdcb73190d22884c4 MooX-HandlesVia-0.001005.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-MooX-HandlesVia/f20] Initial Import.
Summary of changes: 694d4cf... 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
[Bug 1082196] New: Please update perl-Role-Tiny to at least rawhide
https://bugzilla.redhat.com/show_bug.cgi?id=1082196 Bug ID: 1082196 Summary: Please update perl-Role-Tiny to at least rawhide Product: Fedora Version: 19 Component: perl-Role-Tiny Assignee: iarn...@gmail.com Reporter: rc040...@freenet.de QA Contact: extras...@fedoraproject.org CC: iarn...@gmail.com, perl-devel@lists.fedoraproject.org Please update perl-Role-Tiny to at least 1.003002 (== current rawhide) Description of problem: Some packages, which depend on Role::Tiny have begun to depend on perl(Role::Tiny) = 1.003002 Role::Tiny in CPAN is 1.003003, F20+rawhide ship perl-Role-Tiny-1.003002 F19 only ships perl-Role-Tiny-1.002005 = It currently is impossible to fix/upgrade F19 some packages, whose dependency chain contains Role::Tiny. Version-Release number of selected component (if applicable): perl-Role-Tiny-1.002005 -- 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=5LF5jFj7WOa=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 1079473] perl-GnuPG-Interface broken dependencies
https://bugzilla.redhat.com/show_bug.cgi?id=1079473 Bug 1079473 depends on bug 1079615, which changed state. Bug 1079615 Summary: Review Request: perl-MooX-HandlesVia - NativeTrait-like behavior for Moo https://bugzilla.redhat.com/show_bug.cgi?id=1079615 What|Removed |Added Status|ASSIGNED|CLOSED Resolution|--- |RAWHIDE -- 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=8GSgEvDKwOa=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 1082198] New: Please update perl-Moo to at lease f20
https://bugzilla.redhat.com/show_bug.cgi?id=1082198 Bug ID: 1082198 Summary: Please update perl-Moo to at lease f20 Product: Fedora Version: 19 Component: perl-Moo Assignee: iarn...@gmail.com Reporter: rc040...@freenet.de QA Contact: extras...@fedoraproject.org CC: iarn...@gmail.com, perl-devel@lists.fedoraproject.org Please update perl-Moo to at least f20 (perl-Moo-1.003001) Description of problem: F19 ships perl-Moo-1.002000. This is too old for some packages I am trying to add to Fedora. -- 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=Cmvu9husqOa=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 1082198] Please update perl-Moo to at lease f20
https://bugzilla.redhat.com/show_bug.cgi?id=1082198 Ralf Corsepius rc040...@freenet.de changed: What|Removed |Added Depends On||1082196 Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1082196 [Bug 1082196] Please update perl-Role-Tiny to at least rawhide -- 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=IubBW8AZl2a=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 1082196] Please update perl-Role-Tiny to at least rawhide
https://bugzilla.redhat.com/show_bug.cgi?id=1082196 Ralf Corsepius rc040...@freenet.de changed: What|Removed |Added Blocks||1082198 Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1082198 [Bug 1082198] Please update perl-Moo to at lease f20 -- 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=jM9XvDY1R7a=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 1082203] New: perl-MooX-HandlesVia missing deps on f19
https://bugzilla.redhat.com/show_bug.cgi?id=1082203 Bug ID: 1082203 Summary: perl-MooX-HandlesVia missing deps on f19 Product: Fedora Version: 19 Component: perl-MooX-HandlesVia Assignee: rc040...@freenet.de Reporter: rc040...@freenet.de QA Contact: extras...@fedoraproject.org CC: perl-devel@lists.fedoraproject.org, rc040...@freenet.de Description of problem: F19 lacks some dependencies required to build perl-MooX-HandlesVia. Additional info: This is a tracking bug to remind myself, when f19 is ready to build perl-MooX-HandlesVia -- 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=q8gHKs899oa=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 1082203] perl-MooX-HandlesVia missing deps on f19
https://bugzilla.redhat.com/show_bug.cgi?id=1082203 Ralf Corsepius rc040...@freenet.de changed: What|Removed |Added Depends On||1082198 Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1082198 [Bug 1082198] Please update perl-Moo to at least f20 -- 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=0MksUkhTDoa=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 1082198] Please update perl-Moo to at least f20
https://bugzilla.redhat.com/show_bug.cgi?id=1082198 Ralf Corsepius rc040...@freenet.de changed: What|Removed |Added Blocks||1082203 Summary|Please update perl-Moo to |Please update perl-Moo to |at lease f20|at least f20 Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1082203 [Bug 1082203] perl-MooX-HandlesVia missing deps on f19 -- 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=bRlw4blpdZa=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
Planned Outage: Mass reboots/Upgrades - 2014-04-01 21:00 UTC
Planned Outage: Mass reboots/Upgrades - 2014-04-01 21:00 UTC There will be an outage starting at 2014-04-01 21:00 UTC, which will last approximately 4 hours. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d '2014-04-01 21:00 UTC' Reason for outage: We will be rebooting all servers to pick up the latest system updates. Additionally we will be upgrading the koji build system to 1.9.0. During the outage window some services may be down and then back up again, but no single service should be down more than a few minutes, and some services may not be affected at all. Affected Services: Ask Fedora - http://ask.fedoraproject.org/ Badges - https://badges.fedoraproject.org/ BFO - http://boot.fedoraproject.org/ Blockerbugs - https://qa.fedoraproject.org/blockerbugs/ Bodhi - https://admin.fedoraproject.org/updates/ Buildsystem - http://koji.fedoraproject.org/ GIT / Source Control - pkgs.fedoraproject.org Darkserver - https://darkserver.fedoraproject.org/ DNS - ns-sb01.fedoraproject.org, ns02.fedoraproject.org, ns04.fedoraproject.org, ns05.fedoraproject.org Docs - http://docs.fedoraproject.org/ Elections - https://admin.fedoraproject.org/voting Email system Fedmsg busmon - http://apps.fedoraproject.org/busmon Fedora Account System - https://admin.fedoraproject.org/accounts/ Fedora Community - https://admin.fedoraproject.org/community/ Fedora Calendar - https://apps.fedoraproject.org/calendar/ Fedora Hosted - https://fedorahosted.org/ Fedora OpenID - https://id.fedoraproject.org/ Fedora People - http://fedorapeople.org/ Main Website - http://fedoraproject.org/ Mirror List - https://mirrors.fedoraproject.org/ Mirror Manager - https://admin.fedoraproject.org/mirrormanager/ Package Database - https://admin.fedoraproject.org/pkgdb/ QA Services Secondary Architectures Spins - http://spins.fedoraproject.org/ Start - http://start.fedoraproject.org/ Torrent - http://torrent.fedoraproject.org/ Wiki - http://fedoraproject.org/wiki/ Unaffected Services: Contact Information: Ticket Link: https://fedorahosted.org/fedora-infrastructure/ticket/4280 Please join #fedora-admin or #fedora-noc on irc.freenode.net or add comments to the ticket for this outage above. signature.asc Description: PGP signature ___ devel-announce mailing list devel-announce@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce
