EPEL Dependency broken for TurboGears-1.1.3-8.el7.noarch
Hi, I tried to install TurboGears-1.1.3 on my RedHat EL7 Beta server with yum install and got these error message: Error: Package: TurboGears-1.1.3-8.el7.noarch (epel) Requires: python-webtest Error: Package: python-cheetah-2.4.4-4.el7.x86_64 (epel) Requires: python-pygments Error: Package: python-sqlobject-1.2.2-3.el7.noarch (epel) Requires: postgresql-python Error: Package: python-genshi-0.7-3.el7.x86_64 (epel) Requires: python-babel = 0.8 You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles -nodigest Is there anyone caring this or do we have any plan to fix this dependency issue? Thank you in advance. -- Best Regards Jacky [wargaming.net] EgzO3mXGcK This e-mail may contain CONFIDENTIAL AND PROPRIETARY INFORMATION and/or PRIVILEGED AND CONFIDENTIAL COMMUNICATION intended solely for the recipient and, therefore, may not be retransmitted to any party outside of the recipient's organization without the prior written consent of the sender. If you have received this e-mail in error please notify the sender immediately by telephone or reply e-mail and destroy the original message without making a copy. Wargaming.net accepts no liability for any losses or damages resulting from infected e-mail transmissions and viruses in e-mail attachment. kgzO3mXGcg ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: EPEL Dependency broken for TurboGears-1.1.3-8.el7.noarch
I would suggest you using pip to install these packages. First these packages in repo are old and may not match your need. https://bugzilla.redhat.com/show_bug.cgi?id=852998 Second these packages are used for Fedora infrastructure apps, and since the technology is moving forwardly, these packages may be retired. Thanks. ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: EPEL Dependency broken for TurboGears-1.1.3-8.el7.noarch
Hi Christopher, Thanks for your quick response. I understand the situation and Turbogears-1.1.3 may be old. I also tried Turbogears2 (which is TurboGears2-2.3.0) and got these errors: Error: Package: python-transaction-1.4.1-1.el7.noarch (epel) Requires: python-zope-interface Error: Package: python-zope-sqlalchemy-0.7.2-1.el7.noarch (epel) Requires: python-zope-interface Error: Package: python-kajiki-0.3.5-1.el7.noarch (epel) Requires: babel Error: Package: python-genshi-0.7-3.el7.x86_64 (epel) Requires: python-babel = 0.8 Error: Package: python-repoze-who-2.1-1.el7.noarch (epel) Requires: python-zope-interface Error: Package: TurboGears2-2.3.0-0.2.git6da6959.el7.noarch (epel) Requires: python-jinja2 You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest Do you have any suggestion for this one? Thanks. -- Best Regards Jacky From: epel-devel-boun...@lists.fedoraproject.org [mailto:epel-devel-boun...@lists.fedoraproject.org] On Behalf Of Christopher Meng Sent: Friday, 14 March 2014 2:26 PM To: EPEL Development List Subject: Re: EPEL Dependency broken for TurboGears-1.1.3-8.el7.noarch I would suggest you using pip to install these packages. First these packages in repo are old and may not match your need. https://bugzilla.redhat.com/show_bug.cgi?id=852998 Second these packages are used for Fedora infrastructure apps, and since the technology is moving forwardly, these packages may be retired. Thanks. [wargaming.net] EgzO3mXGcK This e-mail may contain CONFIDENTIAL AND PROPRIETARY INFORMATION and/or PRIVILEGED AND CONFIDENTIAL COMMUNICATION intended solely for the recipient and, therefore, may not be retransmitted to any party outside of the recipient's organization without the prior written consent of the sender. If you have received this e-mail in error please notify the sender immediately by telephone or reply e-mail and destroy the original message without making a copy. Wargaming.net accepts no liability for any losses or damages resulting from infected e-mail transmissions and viruses in e-mail attachment. kgzO3mXGcg ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Retired update still showing in updates-testing
Hello, I pushed two packages as updates in bodhi a few weeks ago, but even before they reached updates-testing I revoked them. Now, after some weeks, I see that both are available from updates-testing but I don't see them in Bodhi. They are not in my list of updates or the generic updates-testing queue. It seems they have been removed from Bodhi but somehow they reached the repository anyway. The packages are these two: guacamole-client-0.8.3-5.fc20 guacamole-client-0.8.3-5.fc19 Can someone explain what has happened? Should I file a ticket somewhere? Thanks, --Simone -- You cannot discover new oceans unless you have the courage to lose sight of the shore (R. W. Emerson). http://xkcd.com/229/ http://negativo17.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Retired update still showing in updates-testing
On Thu, 2014-03-13 at 09:23 +0100, Simone Caronni wrote: The packages are these two: guacamole-client-0.8.3-5.fc20 guacamole-client-0.8.3-5.fc19 Can someone explain what has happened? Should I file a ticket somewhere? The builds are still tagged as testing, which is why they appear in the repositories: http://koji.fedoraproject.org/koji/buildinfo?buildID=500690 http://koji.fedoraproject.org/koji/buildinfo?buildID=500691 The solution is for you to untag the builds: $ koji untag-pkg f19-updates-testing guacamole-client-0.8.3-5.fc19 $ koji untag-pkg f20-updates-testing guacamole-client-0.8.3-5.fc20 Then at the next mash, they will be gone. I have no idea why they are still tagged, though. Maybe you removed the updates while the builds were being pushed, which tends to trip Bodhi up. Or maybe you hit a Bodhi bug. -- Mathieu -- 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: Retired update still showing in updates-testing
On 13 March 2014 09:33, Mathieu Bridon boche...@fedoraproject.org wrote: The solution is for you to untag the builds: $ koji untag-pkg f19-updates-testing guacamole-client-0.8.3-5.fc19 $ koji untag-pkg f20-updates-testing guacamole-client-0.8.3-5.fc20 Then at the next mash, they will be gone. I have no idea why they are still tagged, though. Maybe you removed the updates while the builds were being pushed, which tends to trip Bodhi up. Or maybe you hit a Bodhi bug. Thanks, I've already tried it but I can't tag/untag packages in Bodhi: $ koji untag-pkg f19-updates-testing guacamole-client-0.8.3-5.fc19 ActionNotAllowed: tag requires admin permission I think some admin intervention is needed. Regards, --Simone -- You cannot discover new oceans unless you have the courage to lose sight of the shore (R. W. Emerson). http://xkcd.com/229/ http://negativo17.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Retired update still showing in updates-testing
On Thu, 2014-03-13 at 09:41 +0100, Simone Caronni wrote: On 13 March 2014 09:33, Mathieu Bridon boche...@fedoraproject.org wrote: The solution is for you to untag the builds: $ koji untag-pkg f19-updates-testing guacamole-client-0.8.3-5.fc19 $ koji untag-pkg f20-updates-testing guacamole-client-0.8.3-5.fc20 Then at the next mash, they will be gone. I have no idea why they are still tagged, though. Maybe you removed the updates while the builds were being pushed, which tends to trip Bodhi up. Or maybe you hit a Bodhi bug. Thanks, I've already tried it but I can't tag/untag packages in Bodhi: $ koji untag-pkg f19-updates-testing guacamole-client-0.8.3-5.fc19 ActionNotAllowed: tag requires admin permission I think some admin intervention is needed. Ah, right... Open a rel-eng ticket, then. :) https://fedorahosted.org/rel-eng/newticket -- Mathieu -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Self Introduction: Kenjio NAKAYAMA
Hello everybody, I am Kenijro Nakayama, working at Red Hat in Japan as JBoss Technical Support Engineer. I like C++, python, and Emacs Lisp, and of cource I love Open Source Community so much [1]. Now, I try to release some packages [2][3][4][5][6]. If you like, please review it. Thank you! And Let's enjoy! [1] https://savannah.gnu.org/users/nak3 (I am a Emacs commiter.) [2] https://bugzilla.redhat.com/show_bug.cgi?id=1057991 (the_silver_searcher) [3] https://bugzilla.redhat.com/show_bug.cgi?id=1074143 (python-vmbuilder) [4] https://bugzilla.redhat.com/show_bug.cgi?id=1074147 (apt-cacher-ng) [5] https://bugzilla.redhat.com/show_bug.cgi?id=1074531 (mod_jk) Kenjiro Nakayama Kenjiro Nakayama knaka...@redhat.com GPG Key fingerprint = ED8F 049D E67A 727D 9A44 8E25 F44B E208 C946 5EB9 Red Hat K.K. Ebisu Neonato 8F, 1-18 Ebisu 4-chome, Shibuya-ku, Tokyo, Japan 150-0013 -- 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: Self Introduction: Kenjio NAKAYAMA
Welcome. Yours sincerely, Christopher Meng Noob here. http://cicku.me -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Fwd: Pycon Singapore Call for Proposals
Hi Guys, Please have a look on the message from the PyCon SG 2014 Organizing Committee. Feel free to propose your talks and tutorials on or before 30th of April 2014. Do not hesitate to contact Luther Goh of Python Community in Singapore in you need a clarification. Copying to Harish for his information. === Message from the Pycon Singapore organising committee: On behalf of the organizing committee of PyCon SG 2014, we are pleased to invite members of the community to submit talks and/or tutorials for the 2014 PyCon Singapore Conference, to be held in Singapore from June 18 to 20, 2014. Our highlight this year is the announcement of 2 keynote speakers - Kenneth Reitz (Python product owner at Heroku and Requests library author) [1], and David Cramer (engineering at Dropbox and founder at Sentry) [2]. Talk and Tutorial submission details can be found at https://pycon.sg/proposals/ And the submission deadline for both is April 30, 2014. For enquiries, please direct them to confere...@pycon.sg We look forward to receiving your submissions and to a great conference this year! Best regards, On behalf of the PyCon SG 2014 Organizing Committee [1]http://kennethreitz.org/about/ [2]http://justcramer.com/ -- Danishka Navin http://danishkanavin.blogspot.com http://twitter.com/danishkanavin http://www.flickr.com/photos/danishkanavin/ -- 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: Ruby 2.1
- Original Message - = Proposed System Wide Change: Ruby 2.1 = https://fedoraproject.org/wiki/Changes/Ruby_2.1 Change owner(s): Vít Ondruch vondr...@redhat.com Ruby 2.1 is the latest stable version of Ruby, with major increases in speed, memory efficiency and reliability. With this major update from Ruby 2.0.0 in Fedora 20 to Ruby 2.1 in Fedora 21, alongside JRuby, Fedora becomes the superior Ruby development platform. This Change was approved by FESCo on yesterdays meeting with a note: this requires a mini-mass rebuild for native ruby extensions so schedule needs to account for that. Jaroslav -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
F21 Self Contained Change: Security Policy In The Installer
= Proposed Self Contained Change: Security Policy In The Installer = https://fedoraproject.org/wiki/Changes/SecurityPolicyInTheInstaller Change owner(s): Vratislav Podzimek vpodz...@redhat.com There are many known tips and tricks how to make a system more secure, often depending on the use case for the system. With the OSCAP Anaconda Addon [1] and the SCAP Security Guide [2] projects, we may allow users choosing a security policy for their newly installed system. == Detailed Description == The OSCAP Anaconda Addon is a project implementing an Anaconda installer addon integrating the installer with the OpenSCAP toolkit to provide nice UX when it comes to security policy application. Its kickstart and GUI support allows users choosing a security policy for the newly installed system in an easy and nicely scaling way. The SCAP Security Guide project on the other hand focuses on development of so-called SCAP content for Fedora, RHEL and other projects. A SCAP content is a set of XML files defining rules that should be followed by the system together with checks and fixes used to check and fix system's state. It also defines profiles selecting some of the rules (or groups of rules) targetting various use cases. == Scope == We are basically all set. Both OSCAP Anaconda Addon (OAA) and SCAP Security Guide (SSG) are packages that can be installed by lorax to the installation compose (distributed images). The addon is then detected and loaded by the installer and the SCAP content provided by the SSG is automatically detected and loaded by the addon. Of course a lot of future development is expected in both of the projects to provide additional features, but even the current state provides nice features and good UX. * Proposal owners: Bug fixing of both the OAA and SSG is expected to be required, but there are no known major bugs. Further development especially on the SSG side may be requried to provide more security policies for various products/spins/use cases. * Release engineering: Few simple changes in the lorax templates will be needed to make the OAA and SSG included in the installer images. Patches are already available and will be submitted to the lorax maintainer (Brian Lane) who has agreed to review and help with them. [1] https://fedorahosted.org/oscap-anaconda-addon/ [2] https://fedorahosted.org/scap-security-guide/ ___ 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: F21 Self Contained Change: Security Policy In The Installer
2014-03-13 11:29 GMT+01:00 Jaroslav Reznik jrez...@redhat.com: There are many known tips and tricks how to make a system more secure, often depending on the use case for the system. With the OSCAP Anaconda Addon [1] and the SCAP Security Guide [2] projects, we may allow users choosing a security policy for their newly installed system. What is the proposed default configuration/policy? == Scope == * Release engineering: Few simple changes... your village pedant A Change with a Release Engineering section is unlikely to be self-contained /your village pedant Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 Self Contained Change: Security Policy In The Installer
There are many known tips and tricks how to make a system more secure, often depending on the use case for the system. With the OSCAP Anaconda Addon [1] and the SCAP Security Guide [2] projects, we may allow users choosing a security policy for their newly installed system. What is the proposed default configuration/policy? FWIW WRT to scap-security-guide content there's only one (common) profile at the moment. But it depends on the target group / volume / spin we would like this to be by default part of -- once this is clear in that case the profile can be adjusted / modified to prefer / select by default just rules intended for the target group of that system (e.g server rules for the server WG, cloud rules for the cloud WG etc.). Thank you Regards, Jan. -- Jan iankko Lieskovsky / Red Hat Security Technologies Team == Scope == * Release engineering: Few simple changes... your village pedant A Change with a Release Engineering section is unlikely to be self-contained /your village pedant Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- 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: Ruby 2.1
Dne 13.3.2014 10:43, Jaroslav Reznik napsal(a): - Original Message - = Proposed System Wide Change: Ruby 2.1 = https://fedoraproject.org/wiki/Changes/Ruby_2.1 Change owner(s): Vít Ondruch vondr...@redhat.com Ruby 2.1 is the latest stable version of Ruby, with major increases in speed, memory efficiency and reliability. With this major update from Ruby 2.0.0 in Fedora 20 to Ruby 2.1 in Fedora 21, alongside JRuby, Fedora becomes the superior Ruby development platform. This Change was approved by FESCo on yesterdays meeting with a note: this requires a mini-mass rebuild for native ruby extensions so schedule needs to account for that. Jaroslav Just for the record, bellow is the list of packages (147) which will need rebuild, obtained using: $ repoquery --disablerepo=* --enablerepo=rawhide --enablerepo=rawhide-source --arch=src --whatrequires 'ruby-devel' | sort | uniq The rubygem-* packages will need some changes, which you can apply by: https://github.com/voxik/fermig/blob/master/update.rb Let me know if you'd prefer to do the rebuild yourself, otherwise I'll rebuild your package. But prior the rebuild happens, I need to submit updated guidelines to FPC and I'll try to ask rel-eng for side tag, so this probably won't start sooner than 24th of March (date change reserved ;). Vít alexandria chipmunk clearsilver condor-wallaby eruby facter fantasdic gdal graphviz hiera hivex hyperestraier ice kazehakase libcaca libdmtx libguestfs libselinux libsolv libyui-bindings marisa mcollective migemo mingw-qpid-cpp obexftp openbabel openshift-origin-broker-util openwsman pcs player postgresql-plruby psi4 puppet qdbm qpid-qmf redland-bindings remctl root rrdtool ruby-RMagick ruby-RRDtool ruby-augeas ruby-aws ruby-bsearch ruby-gnome2 ruby-icon-artist ruby-korundum ruby-ldap ruby-libvirt ruby-mecab ruby-ncurses ruby-qt ruby-rhubarb ruby-romkan ruby-shadow ruby-spqr ruby-taglib rubygem-RedCloth rubygem-RubyInline rubygem-atk rubygem-atomic rubygem-bcrypt-ruby rubygem-bson_ext rubygem-cairo rubygem-cairo-gobject rubygem-charlock_holmes rubygem-curb rubygem-eventmachine rubygem-fast_xs rubygem-ferret rubygem-ffi rubygem-gdk3 rubygem-gdk_pixbuf2 rubygem-gherkin rubygem-gio2 rubygem-glib2 rubygem-goocanvas rubygem-goocanvas1 rubygem-gstreamer rubygem-gtk2 rubygem-gtk3 rubygem-gtksourceview2 rubygem-hpricot rubygem-idn rubygem-json rubygem-kgio rubygem-krb5-auth rubygem-levenshtein rubygem-linecache19 rubygem-mechanize rubygem-mkrf rubygem-mysql2 rubygem-narray rubygem-newgem rubygem-nokogiri rubygem-opengl rubygem-pam rubygem-pango rubygem-parseconfig rubygem-passenger rubygem-pg rubygem-pkg-config rubygem-poppler rubygem-posix-spawn rubygem-qpid_messaging rubygem-qpid_proton rubygem-raindrops rubygem-rdiscount rubygem-redcarpet rubygem-rkerberos rubygem-rmail rubygem-rspec-longrun rubygem-rsvg2 rubygem-ruby-debug-base19 rubygem-ruby-libvirt rubygem-rufus-scheduler rubygem-rugged rubygem-sequel rubygem-snmp rubygem-sqlite3 rubygem-syck rubygem-therubyracer rubygem-thin rubygem-typhoeus rubygem-unf_ext rubygem-virt-p2v rubygem-vte rubygem-xmlhash rubygem-xmlparser rubygem-zoom rubygems saslwrapper shogun simspark skf sshmenu stfl subversion uwsgi vim vim-command-t wallaby weechat xapian-bindings xchat-ruby xmms2 zorba -- 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: Ruby 2.1
On Thu, Mar 13, 2014 at 05:43:16AM -0400, Jaroslav Reznik wrote: - Original Message - = Proposed System Wide Change: Ruby 2.1 = https://fedoraproject.org/wiki/Changes/Ruby_2.1 Change owner(s): Vít Ondruch vondr...@redhat.com Ruby 2.1 is the latest stable version of Ruby, with major increases in speed, memory efficiency and reliability. With this major update from Ruby 2.0.0 in Fedora 20 to Ruby 2.1 in Fedora 21, alongside JRuby, Fedora becomes the superior Ruby development platform. This Change was approved by FESCo on yesterdays meeting with a note: this requires a mini-mass rebuild for native ruby extensions so schedule needs to account for that. Is a ruby 2.1 RPM available for us to test build our packages against? (I checked koji, doesn't appear to be any there.) Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://people.redhat.com/~rjones/virt-df/ -- 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: Security Policy In The Installer
2014-03-13 12:47 GMT+01:00 Jan Lieskovsky jlies...@redhat.com: There are many known tips and tricks how to make a system more secure, often depending on the use case for the system. With the OSCAP Anaconda Addon [1] and the SCAP Security Guide [2] projects, we may allow users choosing a security policy for their newly installed system. What is the proposed default configuration/policy? FWIW WRT to scap-security-guide content there's only one (common) profile at the moment. But it depends on the target group / volume / spin we would like this to be by default part of -- once this is clear in that case the profile can be adjusted / modified to prefer / select by default just rules intended for the target group of that system So, let me be more specific: If I install using the most default setup possible (not touching the policy spoke), will the installed system be affected by the policy / different from what is packaged in the RPMs? Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Ruby 2.1
Dne 13.3.2014 13:17, Richard W.M. Jones napsal(a): On Thu, Mar 13, 2014 at 05:43:16AM -0400, Jaroslav Reznik wrote: - Original Message - = Proposed System Wide Change: Ruby 2.1 = https://fedoraproject.org/wiki/Changes/Ruby_2.1 Change owner(s): Vít Ondruch vondr...@redhat.com Ruby 2.1 is the latest stable version of Ruby, with major increases in speed, memory efficiency and reliability. With this major update from Ruby 2.0.0 in Fedora 20 to Ruby 2.1 in Fedora 21, alongside JRuby, Fedora becomes the superior Ruby development platform. This Change was approved by FESCo on yesterdays meeting with a note: this requires a mini-mass rebuild for native ruby extensions so schedule needs to account for that. Is a ruby 2.1 RPM available for us to test build our packages against? (I checked koji, doesn't appear to be any there.) Rich. No, not yet ... I wanted to build in Copr, but it fails due to old Kernel :/ Nevertheless, you can checkout ruby from dist-git and you should be able to scratch-build in Koji for yourself from private-ruby-2.1 branch. HTH Vít -- 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: Security Policy In The Installer
There are many known tips and tricks how to make a system more secure, often depending on the use case for the system. With the OSCAP Anaconda Addon [1] and the SCAP Security Guide [2] projects, we may allow users choosing a security policy for their newly installed system. What is the proposed default configuration/policy? FWIW WRT to scap-security-guide content there's only one (common) profile at the moment. But it depends on the target group / volume / spin we would like this to be by default part of -- once this is clear in that case the profile can be adjusted / modified to prefer / select by default just rules intended for the target group of that system So, let me be more specific: If I install using the most default setup possible (not touching the policy spoke), will the installed system be affected by the policy / different from what is packaged in the RPMs? No (by default AFAICT). But since there will be oscap-anaconda-addon present in the compose / distro (if this proposal got approved), the user *before* / *in the moment* of the install will have chance to select which profile the installed system should be compliant to / in conformance with once installed. But should their preference be not to change / configure anything, they will still have chance to ignore the proposed Security Profile anaconda field, and use vanilla Fedora installation (as there wouldn't be the proposed enhancement present at all). Vrata, pls correct me if / where appropriate. Thank you Regards, Jan. -- Jan iankko Lieskovsky / Red Hat Security Technologies Team Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Base] Base Design WG agenda meeting 14. Mar 2014 15:00 UTC on #fedora-meeting
Call for agenda: If you have anything else for the agenda just let me know. Agenda: - Proposal to move meeting to summer time (14:00 UTC) - 2nd round of reviews of Tech Specs - Open floor Thanks regards, Phil -- Philipp Knirsch | Tel.: +49-711-96437-470 Manager Core Services| Fax.: +49-711-96437-111 Red Hat GmbH | Email: Phil Knirsch pknir...@redhat.com Wankelstrasse 5 | Web: http://www.redhat.com/ D-70563 Stuttgart, Germany -- 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: Ruby 2.1
On 13/03/2014 02:05 μμ, Vít Ondruch wrote: Dne 13.3.2014 10:43, Jaroslav Reznik napsal(a): - Original Message - = Proposed System Wide Change: Ruby 2.1 = https://fedoraproject.org/wiki/Changes/Ruby_2.1 Change owner(s): Vít Ondruch vondr...@redhat.com Ruby 2.1 is the latest stable version of Ruby, with major increases in speed, memory efficiency and reliability. With this major update from Ruby 2.0.0 in Fedora 20 to Ruby 2.1 in Fedora 21, alongside JRuby, Fedora becomes the superior Ruby development platform. This Change was approved by FESCo on yesterdays meeting with a note: this requires a mini-mass rebuild for native ruby extensions so schedule needs to account for that. Jaroslav Just for the record, bellow is the list of packages (147) which will need rebuild, obtained using: $ repoquery --disablerepo=* --enablerepo=rawhide --enablerepo=rawhide-source --arch=src --whatrequires 'ruby-devel' | sort | uniq The rubygem-* packages will need some changes, which you can apply by: https://github.com/voxik/fermig/blob/master/update.rb Let me know if you'd prefer to do the rebuild yourself, otherwise I'll rebuild your package. But prior the rebuild happens, I need to submit updated guidelines to FPC and I'll try to ask rel-eng for side tag, so this probably won't start sooner than 24th of March (date change reserved ;). I would go with whatever isn't updated till 24 March gets to be part of the mass rebuild :) -- FAS : axilleas GPG : 0xABF99BE5 Blog: http://axilleas.me -- 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: Security Policy In The Installer
On Thu, 2014-03-13 at 09:00 -0400, Jan Lieskovsky wrote: There are many known tips and tricks how to make a system more secure, often depending on the use case for the system. With the OSCAP Anaconda Addon [1] and the SCAP Security Guide [2] projects, we may allow users choosing a security policy for their newly installed system. What is the proposed default configuration/policy? FWIW WRT to scap-security-guide content there's only one (common) profile at the moment. But it depends on the target group / volume / spin we would like this to be by default part of -- once this is clear in that case the profile can be adjusted / modified to prefer / select by default just rules intended for the target group of that system So, let me be more specific: If I install using the most default setup possible (not touching the policy spoke), will the installed system be affected by the policy / different from what is packaged in the RPMs? No (by default AFAICT). But since there will be oscap-anaconda-addon present in the compose / distro (if this proposal got approved), the user *before* / *in the moment* of the install will have chance to select which profile the installed system should be compliant to / in conformance with once installed. But should their preference be not to change / configure anything, they will still have chance to ignore the proposed Security Profile anaconda field, and use vanilla Fedora installation (as there wouldn't be the proposed enhancement present at all). Vrata, pls correct me if / where appropriate. The current behaviour of the addon is to *not* select any profile by default. So unless the user visits the spoke and chooses some profile (and doesn't toggle the Apply security policy switch), no changes will be done to the installed system. So it's opt in solution, not an opt out one. -- Vratislav Podzimek Anaconda Rider | Red Hat, Inc. | Brno - Czech Republic -- 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: Help understanding Anaconda source - walk through needed.
Not sure yet but Anaconda has some specialised support for CPU's presumably the processor name at a minimum. On 12 March 2014 21:55, Jon jdisn...@gmail.com wrote: On Wed, Mar 12, 2014 at 4:16 PM, Aaron Gray aaronngray.li...@gmail.com wrote: Okay think I have got a handle on it now, the main python file in the root does not have a .py extension. Very helpful ! Another interesting thing is there is no ARM support which I will be needing at some point. Aaron On 12 March 2014 20:07, Aaron Gray aaronngray.li...@gmail.com wrote: Hi, I am looking for someone to walk me through the Anaconda source as I need to understand it and cannot find where its 'main' is and how it launches X Windows as I need to work out why the main installer is not working on my HP D140 G3's with MCA video controllers. https://git.fedorahosted.org/cgit/anaconda.git/tree/?h=f20-branch Hope someone kind person has time to help me. Regards, Aaron What kind of ARM support will you be looking to have? -Jon Disnard fas: parasense irc: masta -- -Jon -- 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: python packages versus pydoc -k
On 03/12/2014 06:12 PM, Toshio Kuratomi wrote: On Wed, Mar 12, 2014 at 12:18:17PM -0700, Josh Stone wrote: Do we have any packaging requirements or guidelines for python modules to behave nicely with pydoc? I've seen this break a number of times, and sometimes the bugs I've filed have been fixed, sometimes ignored. Before I go through another round, I'd like to know if we have (or should have) some official policy on this. We don't currently have any official guidelines on this. I know that pydoc can be broken. Because of how it works I'm not certain that we can fix it and keep it fixed. AIUI, pydoc works by importing the named module, then displaying its docstrings. Then pydoc -k does this for all modules in sys.path, looking for the specified keyword. A problem then arises if something in the path does protect itself with 'if __name__ == __main__:' to know when it's acting as a module or a script. (And if some module really doesn't want to support normal importing, it should not be installed in the path!) There's also packages that need a non-default version of a dependency in order to work. We've worked out ways to do this so that the module can be imported when we use them in an application but it will probably break with the way pydoc -k works. setuptools entrypoints can break unrelated code. It's probably another way that pydoc -k could be broken. [..] Of course, these are just the first exceptions I hit. Experience shows that fixing these will likely find more behind them. Yeah, I think there's a never ending treadmill here. Alright, I'll try not to let it bother me then. Thanks for your input. Josh -- 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: python packages versus pydoc -k
On Thu, Mar 13, 2014 at 09:11:12AM -0700, Josh Stone wrote: On 03/12/2014 06:12 PM, Toshio Kuratomi wrote: On Wed, Mar 12, 2014 at 12:18:17PM -0700, Josh Stone wrote: Of course, these are just the first exceptions I hit. Experience shows that fixing these will likely find more behind them. Yeah, I think there's a never ending treadmill here. Alright, I'll try not to let it bother me then. Yeah... which is not to stop you from filing bugs and working on fixes if you want... but I don't think we'll be able to maintain a working pydoc -k... there's jsut too many ways it can go wrong whenever a python package updates or is added. -Toshio pgpWmeCX6s4Sm.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 Self Contained Change: Security Policy In The Installer
How would this alter the default user installation experience? -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: python packages versus pydoc -k
On 03/12/2014 08:18 PM, Josh Stone wrote: For instance, right now I get: $ pydoc -k xyzzy lib2to3.fixes.fix_repr - Fixer that transforms `xyzzy` into repr(xyzzy). Traceback (most recent call last): File /usr/bin/pydoc, line 5, in module pydoc.cli() File /usr/lib64/python2.7/pydoc.py, line 2292, in cli apropos(val) File /usr/lib64/python2.7/pydoc.py, line 1992, in apropos ModuleScanner().run(callback, key, onerror=onerror) File /usr/lib64/python2.7/pydoc.py, line 1973, in run module = loader.load_module(modname) AttributeError: 'NoneType' object has no attribute 'load_module' It's hard to track that down, but with strace -e open it looks like somewhere in site-packages/rpm/. I couldn't figure out exactly which subpackage is triggering this. I really would like to get this fixed if it really is a problem in rpm-python. But someone needs to come up with some better error messages or other way of finding out what the actual problem is. After a quick view in the pydoc doc I am no longer sure that this is an rpm problem, though. This could also be a bug in pydoc or pkgutil or some other python module being processed. Florian -- 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: Security Policy In The Installer
On Thu, 2014-03-13 at 15:27 +0100, Vratislav Podzimek wrote: On Thu, 2014-03-13 at 09:00 -0400, Jan Lieskovsky wrote: There are many known tips and tricks how to make a system more secure, often depending on the use case for the system. With the OSCAP Anaconda Addon [1] and the SCAP Security Guide [2] projects, we may allow users choosing a security policy for their newly installed system. What is the proposed default configuration/policy? FWIW WRT to scap-security-guide content there's only one (common) profile at the moment. But it depends on the target group / volume / spin we would like this to be by default part of -- once this is clear in that case the profile can be adjusted / modified to prefer / select by default just rules intended for the target group of that system So, let me be more specific: If I install using the most default setup possible (not touching the policy spoke), will the installed system be affected by the policy / different from what is packaged in the RPMs? No (by default AFAICT). But since there will be oscap-anaconda-addon present in the compose / distro (if this proposal got approved), the user *before* / *in the moment* of the install will have chance to select which profile the installed system should be compliant to / in conformance with once installed. But should their preference be not to change / configure anything, they will still have chance to ignore the proposed Security Profile anaconda field, and use vanilla Fedora installation (as there wouldn't be the proposed enhancement present at all). Vrata, pls correct me if / where appropriate. The current behaviour of the addon is to *not* select any profile by default. So unless the user visits the spoke and chooses some profile (and doesn't toggle the Apply security policy switch), no changes will be done to the installed system. So it's opt in solution, not an opt out one. Will the spoke's label have some text like No security profile selected or somesuch when that's the case? Presumably the Begin Installation is insensitive until the Security Profile spoke is happy, like how other spokes work? I like the overall idea, but I'm slightly nervous about the UI. How, if at all, do security policies affect the UI in the *other* spokes? (sorry, I wasn't able to view your videos on this box, just the screenshots). For example, if you have a security profile which mandates that /tmp be on a separate partition or logical volume, does this affect the UI in the partitioning spoke? Similarly, if the profile forbids package telnet from being installed, does this show up somehow in the Software Selection spoke? (e.g. what if the user tries to manually select telnet within that spoke?). Likewise, does the Profile's password complexity requirements affect the password UI? Or is it a case of: review the issues listed in the Security Profile spoke, and figure out how do I fix this?, switch to the appropriate spoke, try to fix it, see if the Security Profile spoke is now happy, else repeat. That seems suboptimal, though what you've got may well be good enough for a first iteration (and I'm not volunteering to hack on it, so feel free to ignore me ;) ). Hope this is constructive; as I said, I like the proposal. Dave -- 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: Security Policy In The Installer
How would this alter the default user installation experience? Please have a look at the demo images / videos available at: https://fedorahosted.org/oscap-anaconda-addon/wiki/Demos Basically there would be one SECURITY section added (with SECURITY PROFILE subsection) into the Anaconda's installation summary screen. In that section user will be able to configure the further details wrt to intended / desired security policy to be applied. Of course, in the case they wouldn't like to configure any security policy and use just vanilla Fedora installation, the can ignore the security section, configure just those sections as configured (required to be configured) now (e.g. INSTALLATION SOURCE, SOFTWARE SELECTION etc.), and click the Begin Installation button. In that case no security profile would be applied. Thank you Regards, Jan. -- Jan iankko Lieskovsky / Red Hat Security Technologies Team -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- 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: python packages versus pydoc -k
On 03/13/2014 10:39 AM, Florian Festi wrote: On 03/12/2014 08:18 PM, Josh Stone wrote: For instance, right now I get: $ pydoc -k xyzzy lib2to3.fixes.fix_repr - Fixer that transforms `xyzzy` into repr(xyzzy). Traceback (most recent call last): File /usr/bin/pydoc, line 5, in module pydoc.cli() File /usr/lib64/python2.7/pydoc.py, line 2292, in cli apropos(val) File /usr/lib64/python2.7/pydoc.py, line 1992, in apropos ModuleScanner().run(callback, key, onerror=onerror) File /usr/lib64/python2.7/pydoc.py, line 1973, in run module = loader.load_module(modname) AttributeError: 'NoneType' object has no attribute 'load_module' It's hard to track that down, but with strace -e open it looks like somewhere in site-packages/rpm/. I couldn't figure out exactly which subpackage is triggering this. I really would like to get this fixed if it really is a problem in rpm-python. But someone needs to come up with some better error messages or other way of finding out what the actual problem is. After a quick view in the pydoc doc I am no longer sure that this is an rpm problem, though. This could also be a bug in pydoc or pkgutil or some other python module being processed. Sorry, I should have tried pdb first, because this one has nothing to do with rpm-python. I can see modname='PyQt4.uic.pyuic', and prior to the exception site is a line 'loader = importer.find_module(modname)', which is where the None came from. I can confirm this one in a clean mock root with just PyQt4 added (and its dependencies). This one might be a bug in the way pydoc -k iterates, because I can't even target that name directly: $ pydoc PyQt4.uic.pyuic no Python documentation found for 'PyQt4.uic.pyuic' $ python -c 'import PyQt4.uic.pyuic' Traceback (most recent call last): File string, line 1, in module ImportError: No module named pyuic FWIW, a clean mock root with python3-PyQt4 is fine with pydoc3 -k. -- 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: Security Policy In The Installer
On Thu, Mar 13, 2014 at 01:40:53PM -0400, Jan Lieskovsky wrote: Of course, in the case they wouldn't like to configure any security policy and use just vanilla Fedora installation, the can ignore the security section, configure just those sections as configured (required to be configured) now (e.g. INSTALLATION SOURCE, SOFTWARE SELECTION etc.), and click the Begin Installation button. In that case no security profile would be applied. The demos seem to cover the case where there's already data provided from the Kickstart file. What options are presented to the user if there's no oscap entry in Kickstart? Is the user expected to provide a path to download a policy? -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 Self Contained Change: Security Policy In The Installer
On Thu, Mar 13, 2014 at 01:40:53PM -0400, Jan Lieskovsky wrote: Of course, in the case they wouldn't like to configure any security policy and use just vanilla Fedora installation, the can ignore the security section, configure just those sections as configured (required to be configured) now (e.g. INSTALLATION SOURCE, SOFTWARE SELECTION etc.), and click the Begin Installation button. In that case no security profile would be applied. The demos seem to cover the case where there's already data provided from the Kickstart file. What options are presented to the user if there's no oscap entry in Kickstart? Is the user expected to provide a path to download a policy? Yes, there are two ways how to provide the policy - either via kickstart or via GUI by entering the HTTP / FTP URI [*] of the policy (in RPM package format) and clicking the Fetch data button. I can remember seeing some video from Vratislav demonstrating the 'fetch security policy in RPM format remotely' scenario too, but you are right it's not illustrated in those demos (yet). Vratislav, can you add demo video of this use case too? Thanks Regards, Jan. -- Jan iankko Lieskovsky / Red Hat Security Technologies Team [*] At the moment only HTTP / FTP options are allowed, but AFAIK there's support for more protocols planned. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- 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: Retired update still showing in updates-testing
Simone Caronni wrote: Hello, I pushed two packages as updates in bodhi a few weeks ago, but even before they reached updates-testing I revoked them. Did you delete the bodhi updates too? If so, (in short), don't do that. -- Rex -- 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: Security Policy In The Installer
On Thu, Mar 13, 2014 at 02:45:58PM -0400, Jan Lieskovsky wrote: The demos seem to cover the case where there's already data provided from the Kickstart file. What options are presented to the user if there's no oscap entry in Kickstart? Is the user expected to provide a path to download a policy? Yes, there are two ways how to provide the policy - either via kickstart or via GUI by entering the HTTP / FTP URI [*] of the policy (in RPM package format) and clicking the Fetch data button. Ok. I'm kind of struggling to imagine the scenario where a user actually wants to do that. What's the use-case for providing UI rather than limiting deployment to Kickstart? -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 Self Contained Change: Security Policy In The Installer
On Thu, 2014-03-13 at 14:45 -0400, Jan Lieskovsky wrote: On Thu, Mar 13, 2014 at 01:40:53PM -0400, Jan Lieskovsky wrote: Of course, in the case they wouldn't like to configure any security policy and use just vanilla Fedora installation, the can ignore the security section, configure just those sections as configured (required to be configured) now (e.g. INSTALLATION SOURCE, SOFTWARE SELECTION etc.), and click the Begin Installation button. In that case no security profile would be applied. The demos seem to cover the case where there's already data provided from the Kickstart file. What options are presented to the user if there's no oscap entry in Kickstart? Is the user expected to provide a path to download a policy? Yes, there are two ways how to provide the policy - either via kickstart or via GUI by entering the HTTP / FTP URI [*] of the policy (in RPM package format) and clicking the Fetch data button. The SCAP Security Guide content is loaded automatically (if available) and even when user clicks the Change content button, there is again the Use SCAP Security Guide button that gives them SSG back. Otherwise fetching data stream collection (XML), archive (zip or tarball) or RPM is supported so far. Other protocols and format types may be added in the future based on user feedback and requests. I can remember seeing some video from Vratislav demonstrating the 'fetch security policy in RPM format remotely' scenario too, but you are right it's not illustrated in those demos (yet). Vratislav, can you add demo video of this use case too? The RPM support is demonstrated in the following video preview: http://vpodzime.fedorapeople.org/oaa-0.4-changes.webm However, I see that a new commented video preview would explain a lot of common questions appearing in this discussion, so I'll record one tomorrow and post it here and on the feature page. Thanks for the useful and constructive feedback, guys! -- Vratislav Podzimek Anaconda Rider | Red Hat, Inc. | Brno - Czech Republic -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
F20: what connects the lid switch to triggering suspend?
My Lenovo X220, running up-to-date F20 occasionally gets into a state where closing the laptop lid does not trigger suspend. I want to narrow down on the problem, but I'm slightly lost on how the signal is routed through the stack. udev-?- systemd-suspend - kernel ? thank you! m -- martin.langh...@gmail.com - ask interesting questions - don't get distracted with shiny stuff - working code first ~ http://docs.moodle.org/en/User:Martin_Langhoff -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Introduction and packaging for Marconi
Hello everyone, I'm Jon and I've created a package for the openstack marconi project [1]. As I'm not yet a member of the packaging team, I will need a sponsor for this package. Any feedback is much appreciated. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1075822 -- Jon -- 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: F20: what connects the lid switch to triggering suspend?
On Thu, Mar 13, 2014 at 3:07 PM, Martin Langhoff martin.langh...@gmail.com wrote: My Lenovo X220, running up-to-date F20 occasionally gets into a state where closing the laptop lid does not trigger suspend. I want to narrow down on the problem, but I'm slightly lost on how the signal is routed through the stack. udev-?- systemd-suspend - kernel ? I wonder whether this is related to the fact that, on most Lenovos, if you press the suspect button twice without waiting long enough, the second press is ignored. --Andy, wearing his very-occasional-lenovo-driver-hacker hat thank you! m -- martin.langh...@gmail.com - ask interesting questions - don't get distracted with shiny stuff - working code first ~ http://docs.moodle.org/en/User:Martin_Langhoff -- 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: F21 Self Contained Change: Security Policy In The Installer
Existing NIST and Red Hat documentation on OpenSCAP says that it's for enterprise-level Linux infrastructure. Is any Fedora 21 product targeted mainly for enterprise deployment? Is OpenSCAP being retargeted for general purpose level infrastructure. If so, will (or should) at least a significant minority, say 33%, of GUI installer using end-users make use of this feature? What does setting a security profile in Anaconda achieve that can't be done, or done as effectively, post-install? Chris Murphy -- 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 1028653] Freshclam cannot notify clamd of database updates due to permission denied
https://bugzilla.redhat.com/show_bug.cgi?id=1028653 Raman Gupta rocketra...@gmail.com changed: What|Removed |Added Status|ON_QA |CLOSED Resolution|--- |CURRENTRELEASE Last Closed||2014-03-13 18:40:02 -- 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=SbENLNns1Fa=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: F20: what connects the lid switch to triggering suspend?
On Thu, Mar 13, 2014 at 6:38 PM, Andrew Lutomirski l...@mit.edu wrote: I wonder whether this is related to the fact that, on most Lenovos, if you press the suspect button twice without waiting long enough, the second press is ignored. Seems unlikelye. I am very careful with double-presses, and my testing was deliberate. When it gets the funk, it seems to ignore lid switch and clear individual presses of the power button. I need to look more in the logs, but they are bulky/noisy, so if I know what components are involved, I can narrow down on it. cheers, m -- martin.langh...@gmail.com - ask interesting questions - don't get distracted with shiny stuff - working code first ~ http://docs.moodle.org/en/User:Martin_Langhoff -- 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: Retired update still showing in updates-testing
On Thu, Mar 13, 2014 at 3:50 AM, Mathieu Bridon boche...@fedoraproject.org wrote: On Thu, 2014-03-13 at 09:41 +0100, Simone Caronni wrote: On 13 March 2014 09:33, Mathieu Bridon boche...@fedoraproject.org wrote: The solution is for you to untag the builds: $ koji untag-pkg f19-updates-testing guacamole-client-0.8.3-5.fc19 $ koji untag-pkg f20-updates-testing guacamole-client-0.8.3-5.fc20 Then at the next mash, they will be gone. I have no idea why they are still tagged, though. Maybe you removed the updates while the builds were being pushed, which tends to trip Bodhi up. Or maybe you hit a Bodhi bug. Thanks, I've already tried it but I can't tag/untag packages in Bodhi: $ koji untag-pkg f19-updates-testing guacamole-client-0.8.3-5.fc19 ActionNotAllowed: tag requires admin permission I think some admin intervention is needed. Ah, right... Open a rel-eng ticket, then. :) https://fedorahosted.org/rel-eng/newticket -- Mathieu Done! $ koji untag-build --force f19-updates-testing guacamole-client-0.8.3-5.fc19 $ koji untag-build --force f20-updates-testing guacamole-client-0.8.3-5.fc20 -- -Jon -- 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: F20: what connects the lid switch to triggering suspend?
On 03/13/2014 03:07 PM, Martin Langhoff wrote: My Lenovo X220, running up-to-date F20 occasionally gets into a state where closing the laptop lid does not trigger suspend. I want to narrow down on the problem, but I'm slightly lost on how the signal is routed through the stack. udev-?- systemd-suspend - kernel ? systemd - logind You could check that the input device for the lid switch is actually sending events. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
SSD disk over Fedora 20... ?
Dear devel mailing list, I would like to know more information about SSD in Fedora. How I can manage spaces, partition's disk and more? I read about SSD with TRIM support improvements more lyfe cycle durability between other things. I read too that a bad partition scheme would be dangerously decreases a life time of SSD considerably. I am bit worried. More people that buys a laptop with SSD, or buys SSD to install Fedora on It. Grretings! -- 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: SSD disk over Fedora 20... ?
On 13/03/14 08:10 PM, Álvaro Castillo wrote: Dear devel mailing list, I would like to know more information about SSD in Fedora. How I can manage spaces, partition's disk and more? I read about SSD with TRIM support improvements more lyfe cycle durability between other things. I read too that a bad partition scheme would be dangerously decreases a life time of SSD considerably. I am bit worried. More people that buys a laptop with SSD, or buys SSD to install Fedora on It. Grretings! I've been using an SSD in my laptop since Fedora 16 without issue. I used luks encryption, so I can't benefit from TRIM, and still no real issues. Keep good backups (same regardless of your disk type) and you're fine. As for partitioning and what-not, there is no difference. It's just another block device. The only real recommendation is to not use a swap partition. -- Digimer Papers and Projects: https://alteeve.ca/w/ What if the cure for cancer is trapped in the mind of a person without access to education? -- 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: Security Policy In The Installer
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Thu, Mar 13, 2014 at 04:40:01PM -0600, Chris Murphy wrote: Existing NIST and Red Hat documentation on OpenSCAP says that it's for enterprise-level Linux infrastructure. Is any Fedora 21 product targeted mainly for enterprise deployment? Is OpenSCAP being retargeted for general purpose level infrastructure. If so, will (or should) at least a significant minority, say 33%, of GUI installer using end-users make use of this feature? Coming from someone who used to have to configure systems to meet DISA STIG requirements I applaud this feature. One can use the same SCAP rules to audit their system later to look for changes in the system. Looking beyond the existing offerings of NIST-specific compliance, one can write their own rules for configuring their systems at install. I wouldn't look at this feature to only be useful for enterprise-level installations but rather flexible enough for any installation. What does setting a security profile in Anaconda achieve that can't be done, or done as effectively, post-install? You could have similar results using a kickstart file or some sort of script post-install but you'd end up duplicating the work to create the rules for install and auditing. I won't comment on the ease of using one over the other. - -- Eric - -- Eric Sparks Christensen Fedora Project spa...@fedoraproject.org - spa...@redhat.com 097C 82C3 52DF C64A 50C2 E3A3 8076 ABDE 024B B3D1 - -- -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQGcBAEBCgAGBQJTIk7vAAoJEB/kgVGp2CYvs78L/0Ft+nmGsaeiY6KZEDuwXFyL bEk3hOsPs/HkQvRz3BXfLHnKuy1P7tptVXIjzrWmiAU/uWrMpBPo2a79mQAvbJDR V9PqfSF7xTbXt5m6wfvDwgMoqn1bF3lrmC9s+fZYQi2UGjR820swUdoB+TJnmPVt E68Ty8I1Eeeeh92JOZrh26hUcyvVEqo7iuV8RtRsjkwEHi/PiUYmOloOoLoYprOW 0vkcd4u+rDwp8Wl+NoElL48Q/i1m5lt5gLTxBn1m22vw9H9Y3/vMcrLMXQlNMS0W c1xdOLeWlUdfN0imtiy9kw8mPl9urZw7PcVX4x3BcQlm4Hs8nWG27t1pL1uQGbuF EnvsnK7q1wTUIusv9uDmJAphDulljEq1BYEXmfZjvS+6tcx8zD4i9PG7Q5JsyWbZ FhHmKMgg6xCA8GUN4AEYEAUHFR86kgqAGaaGOL7J+oA5i9JT++/pWEae+eNjcskw Y84/kexmFSd0mHqwHaMtKEVRVdkwmxdcnoA0YvGMHA== =8Xoo -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: SSD disk over Fedora 20... ?
On Fri, 14 Mar 2014 01:24:37 +0100, Digimer wrote: I've been using an SSD in my laptop since Fedora 16 without issue. I used luks encryption, so I can't benefit from TRIM, You can but that is for users@ list and off-topic here, crypttab has option 'discard'. Jan -- 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: F20: what connects the lid switch to triggering suspend?
On Thu, 13.03.14 18:07, Martin Langhoff (martin.langh...@gmail.com) wrote: My Lenovo X220, running up-to-date F20 occasionally gets into a state where closing the laptop lid does not trigger suspend. I want to narrow down on the problem, but I'm slightly lost on how the signal is routed through the stack. udev-?- systemd-suspend - kernel ? The lid switch is exposed as input device in Linux. logind opens that device and reacts on it. However it gives DEs the chance to inhibit this if they desire so. Gnome at least doesn't inhibit it perminantly though, but some components might delay suspends, for example Telepathy to log you out of your Jabber server... Normally when you close the lid logind should log something about Lid closed or so... Look around the logs around this to figure out what mightbe going on. Lennart -- Lennart Poettering, Red Hat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Help understanding Anaconda source - walk through needed.
On Thu, 2014-03-13 at 14:38 +, Aaron Gray wrote: Not sure yet but Anaconda has some specialised support for CPU's presumably the processor name at a minimum. I'm not sure if I'm missing something or you are, but Anaconda doesn't really distinguish between CPUs, and it does support ARM. anaconda is a supported deployment method for Calxeda ARM systems in Fedora 20: https://fedoraproject.org/wiki/Architectures/ARM/F20/Installation#Calxeda_EnergyCore_.28HighBank_and_Midway.29 anaconda does have a concept of *platforms*. The various platforms are defined in blivet these days, in fact, in blivet/platform.py: class X86(Platform): class EFI(Platform): class MacEFI(EFI): class Aarch64EFI(EFI): class PPC(Platform): class IPSeriesPPC(PPC): class NewWorldPPC(PPC): class PS3(PPC): class S390(Platform): class ARM(Platform): class omapARM(ARM): and used in several places in blivet and anaconda (mainly partitioning and bootloader installation). 'Aarch64EFI' is for aarch64 systems using UEFI firmware, IIRC. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Bug 1061102] perl-Class-MethodMaker-2.20 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1061102 Ralf Corsepius rc040...@freenet.de changed: What|Removed |Added Status|NEW |CLOSED Resolution|--- |CURRENTRELEASE Assignee|berra...@redhat.com |rc040...@freenet.de Last Closed||2014-03-13 02:19:50 --- Comment #1 from Ralf Corsepius rc040...@freenet.de --- https://admin.fedoraproject.org/updates/FEDORA-2014-2592/perl-Class-MethodMaker-2.20-1.fc20?_csrf_token=3c4f163464b279cff596d8f30b7d093c2114a5a0 -- 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=AAuzOOeluAa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-PDL
perl-PDL has broken dependencies in the epel-7 tree: On ppc64: perl-PDL-2.7.0-2.el7.1.ppc64 requires perl(PDL::Slatec) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1073861] please provide epel7 builds
https://bugzilla.redhat.com/show_bug.cgi?id=1073861 Pavel Šimerda (pavlix) psime...@redhat.com changed: What|Removed |Added CC||t...@foobar.fi --- Comment #2 from Pavel Šimerda (pavlix) psime...@redhat.com --- *** Bug 1074260 has been marked as a duplicate of this bug. *** -- 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=nZWqzcRoi5a=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 1073861] please provide epel7 builds
https://bugzilla.redhat.com/show_bug.cgi?id=1073861 Anssi Johansson rhb...@miuku.net changed: What|Removed |Added CC||rhb...@miuku.net --- Comment #3 from Anssi Johansson rhb...@miuku.net --- (In reply to Pavel Šimerda (pavlix) from comment #0) The racoon2 package in epel7 depends on perl-Getopt-Simple which is present [...] and most likely epel6 For the record, perl-Getopt-Simple is not currently in epel6. -- 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=A01GDWZAQIa=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 IO-Socket-SSL-1.968.tar.gz uploaded to lookaside cache by pghmcfc
A file has been added to the lookaside cache for perl-IO-Socket-SSL: 033e9e15406e7cd9071f1ebc51c90da9 IO-Socket-SSL-1.968.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-IO-Socket-SSL] Update to 1.968
commit cb6319f8b2c43ea22ff147da50a87d5b764d7cac
Author: Paul Howarth p...@city-fan.org
Date: Thu Mar 13 13:28:41 2014 +
Update to 1.968
- New upstream release 1.968
- BEHAVIOR CHANGE: removed implicit defaults of
certs/server-{cert,key}.pem
for SSL_{cert,key}_file and ca/,certs/my-ca.pem for SSL_ca_file; these
defaults were deprecated since 1.951 (July 2013)
- Usable CA verification path on Windows etc.:
- Do not use Net::SSLeay::CTX_set_default_verify_paths any longer to set
system/build dependent default verification path, because there was no
way to retrieve these default values and check if they contained
usable
CA
- Instead, re-implement the same algorithm and export the results with
public function default_ca() and make it possible to overwrite it
- Also check for usable verification path during build; if no usable
path
is detected, require Mozilla::CA at build and try to use it at runtime
perl-IO-Socket-SSL.spec | 23 +++
sources |2 +-
2 files changed, 20 insertions(+), 5 deletions(-)
---
diff --git a/perl-IO-Socket-SSL.spec b/perl-IO-Socket-SSL.spec
index 6f3f63f..1a4ae65 100644
--- a/perl-IO-Socket-SSL.spec
+++ b/perl-IO-Socket-SSL.spec
@@ -1,5 +1,5 @@
Name: perl-IO-Socket-SSL
-Version: 1.967
+Version: 1.968
Release: 1%{?dist}
Summary: Perl library for transparent SSL
Group: Development/Libraries
@@ -17,7 +17,7 @@ BuildRequires:perl(ExtUtils::MakeMaker) = 6.46
BuildRequires: perl(IO::Select)
BuildRequires: perl(IO::Socket)
BuildRequires: perl(IO::Socket::INET)
-BuildRequires: perl(IO::Socket::INET6) = 2.55
+BuildRequires: perl(IO::Socket::INET6) = 2.62
BuildRequires: perl(Net::LibIDN)
BuildRequires: perl(Net::SSLeay) = 1.46
BuildRequires: perl(Scalar::Util)
@@ -30,7 +30,7 @@ BuildRequires:procps
BuildRequires: perl(IO::Socket::IP) = 0.20, perl(Socket) = 1.95
Requires: perl(IO::Socket::IP) = 0.20, perl(Socket) = 1.95
%else
-Requires: perl(IO::Socket::INET6) = 2.55, perl(Socket6)
+Requires: perl(IO::Socket::INET6) = 2.62, perl(Socket6)
%endif
Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
Requires: perl(Net::LibIDN)
@@ -49,7 +49,7 @@ mod_perl.
%setup -q -n IO-Socket-SSL-%{version}
%build
-perl Makefile.PL INSTALLDIRS=vendor
+echo n | perl Makefile.PL INSTALLDIRS=vendor
make %{?_smp_mflags}
%install
@@ -72,6 +72,21 @@ rm -rf %{buildroot}
%{_mandir}/man3/IO::Socket::SSL::Utils.3pm*
%changelog
+* Thu Mar 13 2014 Paul Howarth p...@city-fan.org - 1.968-1
+- Update to 1.968
+ - BEHAVIOR CHANGE: removed implicit defaults of certs/server-{cert,key}.pem
+for SSL_{cert,key}_file and ca/,certs/my-ca.pem for SSL_ca_file; these
+defaults were deprecated since 1.951 (July 2013)
+ - Usable CA verification path on Windows etc.:
+- Do not use Net::SSLeay::CTX_set_default_verify_paths any longer to set
+ system/build dependent default verification path, because there was no
+ way to retrieve these default values and check if they contained usable
+ CA
+- Instead, re-implement the same algorithm and export the results with
+ public function default_ca() and make it possible to overwrite it
+- Also check for usable verification path during build; if no usable path
+ is detected, require Mozilla::CA at build and try to use it at runtime
+
* Fri Feb 7 2014 Paul Howarth p...@city-fan.org - 1.967-1
- Update to 1.967
- Verify the hostname inside a certificate by default with a superset of
diff --git a/sources b/sources
index 5e1dad4..7190f67 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-78b84d50e5a04c19b1d3835514dece95 IO-Socket-SSL-1.967.tar.gz
+033e9e15406e7cd9071f1ebc51c90da9 IO-Socket-SSL-1.968.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-IO-Socket-SSL] Created tag perl-IO-Socket-SSL-1.968-1.fc21
The lightweight tag 'perl-IO-Socket-SSL-1.968-1.fc21' was created pointing to: cb6319f... Update to 1.968 -- 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 Module-Reader-0.002001.tar.gz uploaded to lookaside cache by jplesnik
A file has been added to the lookaside cache for perl-Module-Reader: e578ee4b48677c8a0637963976fd4218 Module-Reader-0.002001.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Module-Reader] Initial import
commit 564ad487fd4c43d612f41a5812079478ae40499d
Author: Jitka Plesnikova jples...@redhat.com
Date: Thu Mar 13 15:36:48 2014 +0100
Initial import
.gitignore |1 +
perl-Module-Reader.spec | 52 +++
sources |1 +
3 files changed, 54 insertions(+), 0 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index e69de29..3b543f1 100644
--- a/.gitignore
+++ b/.gitignore
@@ -0,0 +1 @@
+/Module-Reader-0.002001.tar.gz
diff --git a/perl-Module-Reader.spec b/perl-Module-Reader.spec
new file mode 100644
index 000..12b56d9
--- /dev/null
+++ b/perl-Module-Reader.spec
@@ -0,0 +1,52 @@
+Name: perl-Module-Reader
+Version:0.002001
+Release:1%{?dist}
+Summary:Read the source of a module like perl does
+License:GPL+ or Artistic
+Group: Development/Libraries
+URL:http://search.cpan.org/dist/Module-Reader/
+Source0:
http://www.cpan.org/authors/id/H/HA/HAARG/Module-Reader-%{version}.tar.gz
+BuildArch: noarch
+BuildRequires: perl
+BuildRequires: perl(ExtUtils::MakeMaker)
+BuildRequires: perl(strict)
+# Run-time
+BuildRequires: perl(base)
+BuildRequires: perl(Carp)
+BuildRequires: perl(constant)
+BuildRequires: perl(Exporter)
+BuildRequires: perl(File::Spec)
+# perl(IO::String) - requires only for Perl 5.008
+BuildRequires: perl(Scalar::Util)
+BuildRequires: perl(warnings)
+# Tests
+BuildRequires: perl(Test::More) = 0.88
+Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
+
+%description
+Reads the content of perl modules the same way perl does. This includes
+reading modules available only by @INC hooks, or filtered through them.
+
+%prep
+%setup -q -n Module-Reader-%{version}
+
+%build
+perl Makefile.PL INSTALLDIRS=vendor
+make %{?_smp_mflags}
+
+%install
+make pure_install DESTDIR=$RPM_BUILD_ROOT
+find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
+%{_fixperms} $RPM_BUILD_ROOT/*
+
+%check
+make test
+
+%files
+%doc Changes
+%{perl_vendorlib}/*
+%{_mandir}/man3/*
+
+%changelog
+* Wed Mar 12 2014 Jitka Plesnikova jples...@redhat.com 0.002001-1
+- Specfile autogenerated by cpanspec 1.78.
diff --git a/sources b/sources
index e69de29..8c19e61 100644
--- a/sources
+++ b/sources
@@ -0,0 +1 @@
+e578ee4b48677c8a0637963976fd4218 Module-Reader-0.002001.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 Task-Kensho-OOP-0.36.tar.gz uploaded to lookaside cache by jplesnik
A file has been added to the lookaside cache for perl-Task-Kensho-OOP: 14d8b0807daa77019308a1f938769ecb Task-Kensho-OOP-0.36.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-Task-Kensho-OOP] 0.36 bump
commit 6c6c3ddc904846a2de5b67a8f856f149ed36e0b9
Author: Jitka Plesnikova jples...@redhat.com
Date: Thu Mar 13 16:44:49 2014 +0100
0.36 bump
.gitignore|1 +
perl-Task-Kensho-OOP.spec | 11 +++
sources |2 +-
3 files changed, 9 insertions(+), 5 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 655f0ff..350e45f 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,2 +1,3 @@
/Task-Kensho-OOP-0.28.tar.gz
/Task-Kensho-OOP-0.35.tar.gz
+/Task-Kensho-OOP-0.36.tar.gz
diff --git a/perl-Task-Kensho-OOP.spec b/perl-Task-Kensho-OOP.spec
index 58d119c..893fd48 100644
--- a/perl-Task-Kensho-OOP.spec
+++ b/perl-Task-Kensho-OOP.spec
@@ -1,5 +1,5 @@
Name: perl-Task-Kensho-OOP
-Version:0.35
+Version:0.36
Release:1%{?dist}
Summary:A Glimpse at an Enlightened Perl (OOP)
License:GPL+ or Artistic
@@ -22,9 +22,9 @@ Requires: perl(:MODULE_COMPAT_%(eval `perl
-V:version`; echo $version))
Requires: perl(Task::Moose)
%description
-Task::Kensho is a first cut at building a list of recommended modules for
-Enlightened Perl development. This Task installs object oriented
-programming modules.
+Task::Kensho is a list of recommended modules for Enlightened Perl
+development. CPAN is wonderful, but there are too many wheels and you have
+to pick and choose amongst the various competing technologies.
%prep
%setup -q -n Task-Kensho-OOP-%{version}
@@ -48,6 +48,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Thu Mar 13 2014 Jitka Plesnikova jples...@redhat.com - 0.36-1
+- 0.36 bump
+
* Fri Jan 31 2014 Jitka Plesnikova jples...@redhat.com - 0.35-1
- 0.35 bump
diff --git a/sources b/sources
index 970446f..6b84a1f 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-261ae212de785cd98b5e3213cfa9c568 Task-Kensho-OOP-0.35.tar.gz
+14d8b0807daa77019308a1f938769ecb Task-Kensho-OOP-0.36.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
Broken dependencies: mojomojo
mojomojo has broken dependencies in the rawhide tree: On x86_64: mojomojo-1.10-1.fc20.noarch requires perl(HTML::FormFu::Element::reCAPTCHA) On i386: mojomojo-1.10-1.fc20.noarch requires perl(HTML::FormFu::Element::reCAPTCHA) On armhfp: mojomojo-1.10-1.fc20.noarch requires perl(HTML::FormFu::Element::reCAPTCHA) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Elasticsearch
perl-Elasticsearch has broken dependencies in the rawhide tree: On x86_64: perl-Elasticsearch-1.05-1.fc21.noarch requires perl(Hijk) = 0:0.12 On i386: perl-Elasticsearch-1.05-1.fc21.noarch requires perl(Hijk) = 0:0.12 On armhfp: perl-Elasticsearch-1.05-1.fc21.noarch requires perl(Hijk) = 0:0.12 Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Catalyst-Controller-HTML-FormFu
perl-Catalyst-Controller-HTML-FormFu has broken dependencies in the rawhide tree: On x86_64: perl-Catalyst-Controller-HTML-FormFu-0.09004-4.fc20.noarch requires perl(HTML::FormFu::MultiForm) On i386: perl-Catalyst-Controller-HTML-FormFu-0.09004-4.fc20.noarch requires perl(HTML::FormFu::MultiForm) On armhfp: perl-Catalyst-Controller-HTML-FormFu-0.09004-4.fc20.noarch requires perl(HTML::FormFu::MultiForm) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Language-Expr
perl-Language-Expr has broken dependencies in the rawhide tree: On x86_64: perl-Language-Expr-0.19-4.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) On i386: perl-Language-Expr-0.19-4.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) On armhfp: perl-Language-Expr-0.19-4.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1074958] perl-Task-Kensho-OOP-0.36 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1074958 Jitka Plesnikova jples...@redhat.com changed: What|Removed |Added Status|NEW |CLOSED Fixed In Version||perl-Task-Kensho-OOP-0.36-1 ||.fc21 Resolution|--- |RAWHIDE Last Closed||2014-03-13 12:02: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=ZljaZUWWW0a=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 Mail-IMAPClient-3.35.tar.gz uploaded to lookaside cache by nb
A file has been added to the lookaside cache for perl-Mail-IMAPClient: b1d79827aeb28ba5f73a03eed5c540e6 Mail-IMAPClient-3.35.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-Mail-IMAPClient] Update to 3.35
commit 25b3e783363f53f4f63d871d1ca2765ab8fb81f8
Author: Nick Bebout n...@fedoraproject.org
Date: Thu Mar 13 18:30:41 2014 -0500
Update to 3.35
.gitignore|1 +
perl-Mail-IMAPClient.spec |5 -
sources |2 +-
3 files changed, 6 insertions(+), 2 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index c120b19..dc3947b 100644
--- a/.gitignore
+++ b/.gitignore
@@ -6,3 +6,4 @@ Mail-IMAPClient-3.25.tar.gz
/Mail-IMAPClient-3.32.tar.gz
/Mail-IMAPClient-3.33.tar.gz
/Mail-IMAPClient-3.34.tar.gz
+/Mail-IMAPClient-3.35.tar.gz
diff --git a/perl-Mail-IMAPClient.spec b/perl-Mail-IMAPClient.spec
index e06f206..bd516e9 100644
--- a/perl-Mail-IMAPClient.spec
+++ b/perl-Mail-IMAPClient.spec
@@ -1,5 +1,5 @@
Name: perl-Mail-IMAPClient
-Version:3.34
+Version:3.35
Release:1%{?dist}
Summary:An IMAP Client API
Group: Development/Libraries
@@ -52,6 +52,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*.3*
%changelog
+* Thu Mar 13 2014 Nick Bebout n...@fedoraproject.org - 3.35-1
+- Upgrade to 3.35
+
* Thu Oct 17 2013 Nick Bebout n...@fedoraproject.org - 3.34-1
- Upgrade to 3.34
diff --git a/sources b/sources
index afda7a7..24bdd1a 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-163427d32f5fd7f53f1bd8adf1b639f2 Mail-IMAPClient-3.34.tar.gz
+b1d79827aeb28ba5f73a03eed5c540e6 Mail-IMAPClient-3.35.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-Mail-IMAPClient/f20] Update to 3.35
Summary of changes: 25b3e78... Update to 3.35 (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Mail-IMAPClient/f19] Update to 3.35
Summary of changes: 25b3e78... Update to 3.35 (*) (*) 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
[389-devel] please review: ticket 47750 - Fix coverity issues - part 5
https://fedorahosted.org/389/ticket/47740 https://fedorahosted.org/389/attachment/ticket/47740/0001-Ticket-47740-Fix-coverity-issues-Part-5.patch -- Mark Reynolds 389 Development Team Red Hat, Inc mreyno...@redhat.com -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
libvpx 1.3.0 ABI break
Hi all, libvpx-1.3.0 unexpectedly broke ABI without updating the .so name. See more info here https://bugzilla.redhat.com/show_bug.cgi?id=1068664 I'm rebuilding the gstreamer 0.10 and 1.0 packages now but there are more packages depending on libvpx. Wim ___ devel-announce mailing list devel-announce@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce
