EPEL epel beta report: 20140306 changes
Compose started at Thu Mar 6 08:15:11 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 1:centerim-4.22.10-14.el7.x86_64 requires perl(Time::ParseDate) check-mk-1.2.2p2-2.el7.x86_64 requires mod_python chm2pdf-0.9.1-13.el7.noarch requires python-chm chm2pdf-0.9.1-13.el7.noarch requires htmldoc 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 koji-vm-1.8.0-2.el7.noarch requires python-virtinst lnst-2-1.el7.noarch requires python-pyroute2 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 mcollective-common-2.4.1-1.el7.noarch requires rubygem(systemu) mcollective-common-2.4.1-1.el7.noarch requires rubygem(stomp) nagios-plugins-nrpe-2.15-1.el7.x86_64 requires nagios-plugins 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 phoronix-test-suite-4.8.6-1.el7.noarch requires php-fpdf 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 postgrey-1.34-12.el7.noarch requires perl(Net::Server::Multiplex) postgrey-1.34-12.el7.noarch requires perl(Net::Server::Daemonize) postgrey-1.34-12.el7.noarch requires perl(Net::Server) postgrey-1.34-12.el7.noarch requires perl(BerkeleyDB) python-social-auth-0.1.19-1.el7.noarch requires python-requests-oauthlib = 0:0.3.0 qt4pas-2.5-3.el7.x86_64 requires fpc-src racoon2-20100526a-27.el7.x86_64 requires perl-Getopt-Simple 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 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 1:centerim-4.22.10-14.el7.ppc64 requires perl(Time::ParseDate) check-mk-1.2.2p2-2.el7.ppc64 requires mod_python 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 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 docker-registry-0.6.5-1.el7.noarch requires python-glanceclient docker-registry-0.6.5-1.el7.noarch requires python-backports-lzma fedmsg-0.7.6-2.el7.noarch requires python-requests globus-gram-job-manager-pbs-1.6-7.el7.ppc64 requires torque-client globus-gram-job-manager-sge-1.7-2.el7.ppc64 requires gridengine httpie-0.8.0-1.el7.noarch requires python-requests koji-vm-1.8.0-2.el7.noarch requires python-virtinst lnst-2-1.el7.noarch requires python-pyroute2 lxc-templates-0.9.0-3.el7.ppc64 requires dpkg lxc-templates-0.9.0-3.el7.ppc64 requires debootstrap lxc-templates-0.9.0-3.el7.ppc64 requires busybox mcollective-common-2.4.1-1.el7.noarch requires rubygem(systemu) mcollective-common-2.4.1-1.el7.noarch requires rubygem(stomp) nagios-plugins-nrpe-2.15-1.el7.ppc64 requires
EPEL Thunderbird and/or claws-mail in epel 7 beta
Hi, Will the subject packages be included in epel 7? I don't see them listed on the web pages at http://dl.fedoraproject.org/pub/epel/beta/7/SRPMS/repoview/ tia ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: EPEL Thunderbird and/or claws-mail in epel 7 beta
On 6 March 2014 13:24, Orion Poplawski or...@cora.nwra.com wrote: On 03/06/2014 10:24 AM, Clyde E. Kunkel wrote: Hi, Will the subject packages be included in epel 7? I don't see them listed on the web pages at http://dl.fedoraproject.org/pub/epel/beta/7/SRPMS/repoview/ tia Someone will have to step up and maintain them there. (I hope it doesn't end up being me). Fairly surprised that TB isn't in RHEL, I guess they're just backing evolution. Jan - any interest? Thunderbird is going to be a pain for the EPEL rules. It would have to keep up with the other items that are in RHEL (xulrunner and firefox) which could mean API changes when they go from long-term to long term. -- Stephen J Smoogen. ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
EPEL Fedora 5 updates-testing report
The following Fedora EPEL 5 Security updates need testing: Age URL 684 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2012-5630/bugzilla-3.2.10-5.el5 174 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-11560/fail2ban-0.8.10-4.el5 138 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-11893/libguestfs-1.20.12-1.el5 113 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-12091/bip-0.8.9-1.el5 103 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-12169/gc-7.1-6.el5 18 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0581/augeas-1.2.0-1.el5 18 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0541/drupal7-ctools-1.4-1.el5 12 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0645/easy-rsa-2.2.2-1.el5 5 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0702/mod_auth_shadow-2.3-2.el5 1 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0745/imapsync-1.584-2.el5 1 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0752/libssh-0.5.5-2.el5 The following builds have been pushed to Fedora EPEL 5 updates-testing cherokee-1.2.101-4.el5 libburn-1.3.6-1.el5 libisoburn-1.3.6-1.el5 libisofs-1.3.6-1.el5 Details about builds: cherokee-1.2.101-4.el5 (FEDORA-EPEL-2014-0764) Flexible and Fast Webserver Update Information: Remove the upstream logo due to https://fedorahosted.org/fesco/ticket/1230 ChangeLog: * Wed Mar 5 2014 Toshio Kuratomi tos...@fedoraproject.org - 1.2.101-4 - Remove the upstream cherokee logo due to: https://fedorahosted.org/fesco/ticket/1230 References: [ 1 ] Bug #681339 - Images containing Cherokee project logo violate Fedora project guidelines https://bugzilla.redhat.com/show_bug.cgi?id=681339 libburn-1.3.6-1.el5 (FEDORA-EPEL-2014-0759) Library for reading, mastering and writing optical discs Update Information: Changes towards previous version 1.3.4 == libburn novelties - * New system adapter for NetBSD libisofs novelties -- * Bug fix: Division by zero if HFS+ was combined with TOC emulation for overwritable media * New API call iso_write_opts_set_joliet_utf16() and ability to read Joliet names as UTF-16BE * New API call iso_conv_name_chars() libisoburn and xorriso novelties * Bug fix: libisofs: Division by zero if HFS+ was combined with TOC emulation for overwritable media * Bug fix: -list_speeds did not work any more with old CD drives; regression introduced by release 1.3.4 * Bug fix: -check_media marked untested sectors in sector map as valid * Bug fix: Paths with symbolic links preceding .. were not interpreted properly * New isoburn_igopt_set_relaxed() relaxation isoburn_igopt_joliet_utf16 * New -compliance rule joliet_utf16, new -as mkisofs option -joliet-utf16 * New -find test -bad_outname, new -find action print_outname * New API call isoburn_conv_name_chars() * libburn: New system adapter for NetBSD ChangeLog: * Wed Mar 5 2014 Robert Scheck rob...@fedoraproject.org 1.3.6-1 - Update to upstream 1.3.6 (#1072835) References: [ 1 ] Bug #1072839 - libisofs-1.3.6 is available https://bugzilla.redhat.com/show_bug.cgi?id=1072839 [ 2 ] Bug #1072835 - libburn-1.3.6 is available https://bugzilla.redhat.com/show_bug.cgi?id=1072835 [ 3 ] Bug #1072838 - libisoburn-1.3.6 is available https://bugzilla.redhat.com/show_bug.cgi?id=1072838 libisoburn-1.3.6-1.el5 (FEDORA-EPEL-2014-0759) Library to enable creation and expansion of ISO-9660 filesystems Update Information: Changes towards previous version 1.3.4 == libburn novelties - * New system adapter for NetBSD libisofs novelties -- * Bug fix: Division by zero if HFS+ was combined with TOC emulation for overwritable media * New API call iso_write_opts_set_joliet_utf16() and ability to read Joliet
Re: EPEL Requesting i3* packages for RHEL7
I'm the i3* maintainer now. I will do this of course, but before RHEL7 pushed to final release, please don't rush. Thanks. ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: java headless
On Thu 06 Mar 2014 12:58:46 AM CET Sérgio Basto wrote: Hi , is java-headless, jre (Java Runtime Environment) ? if not, what is the difference ? . Headless is a subset of full JRE without support for some graphical operations, sound etc (i.e. desktop features that are usually useless on servers or other headless machines). -- Stanislav Ochotnicky sochotni...@redhat.com Software Engineer - Developer Experience PGP: 7B087241 Red Hat Inc. http://cz.redhat.com pgpbAUvYY9l2j.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: hierarchical comps groups proposal
My concern would be how deeply woven the current format is into our tools - it's yum, PK, DNF, anaconda, and all the tools built on top of it. It's exposed in kickstart. It's expected to be handled by older versions on upgrade, or even by mock when constructing arbitrary build roots. So care would need to be taken to figure out a good way to land this all at once, in a way that's backwards compatible enough to not break other things. True, so maybe Miloslav's suggestion of using XML entities to implement this might indeed the safest and most pragmatic at this time. Presumably that would only need changes to the generation of comps.xml files themselves. Jens ps (In the long term I would not mind seeing more drastic changes though, like maybe even changing to YAML format or something similar.) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
pdftk retired?
I just git a broken dependencies notice for a package that I maintain. The reason is that pdftk got retired just the other day. I may have missed a corresponding post on fedora-devel, but I think a heads up notice to maintainers of depending packages may be in order before you retire a package, as a general idea. You see, unretiring a package is so much more work than changing maintainership. As for pdftk: I see 2 failed builds for version 1.45 and none for the current version 2.02 (which probably breaks the api anyways). What are the plans? Retire pdftk completely? Start fresh with pdftk2? pdflabs, the maker of pdftk, provide binary as well as source rpms for pdftk 2.02, by the way. I might even look into packaging it but don't want to duplicate any existing efforts. Michael -- 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: Lohit Odia Gurumukhi font naming
Two changes done 1. Moved page with correct name for Gurmukhi script. https://fedoraproject.org/wiki/Changes/Lohit_Odia_Gurmukhi 2. Propose this change as a System wide since might be there are some other packages i am not aware using old names. Let me know if anything still missing. Best Regards, Pravin Satpute On 6 March 2014 10:00, pravin@gmail.com pravin@gmail.com wrote: On 6 March 2014 09:26, Kevin Kofler kevin.kof...@chello.at wrote: Jaroslav Reznik wrote: = Proposed Self Contained Change: Lohit Odia Gurumukhi font naming = https://fedoraproject.org/wiki/Changes/Lohit_Odia_Gurumukhi Change owner(s): Pravin Satpute psatp...@redhat.com According to: http://snehakore.blogspot.com/2014/02/improvements-of-lohit-gurmukhi-2910.html the name should be Gurmukhi, not Gurumukhi. My bad. I will fix this, looks like i need to create different page with proper title. Regards, Pravin Satpute -- 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: pdftk retired?
On Thu, 06 Mar 2014 11:31:18 +0100 Michael J Gruber m...@fedoraproject.org wrote: I just git a broken dependencies notice for a package that I maintain. The reason is that pdftk got retired just the other day. I may have missed a corresponding post on fedora-devel, but I think a heads up notice to maintainers of depending packages may be in order before you retire a package, as a general idea. You see, unretiring a package is so much more work than changing maintainership. As for pdftk: I see 2 failed builds for version 1.45 and none for the current version 2.02 (which probably breaks the api anyways). What are the plans? Retire pdftk completely? Start fresh with pdftk2? pdflabs, the maker of pdftk, provide binary as well as source rpms for pdftk 2.02, by the way. I might even look into packaging it but don't want to duplicate any existing efforts. Michael +1 pdftk is a very important package, so new (co)maintainers shouldn't be hard to find. -- Susi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: pdftk retired?
On 03/06/2014 11:31 AM, Michael J Gruber wrote: As for pdftk: I see 2 failed builds for version 1.45 and none for the current version 2.02 (which probably breaks the api anyways). What are the plans? Retire pdftk completely? Start fresh with pdftk2? pdftk has a hard dependency on GCJ because it's a C++ program that uses a Java library (iText) through CNI. I once tried to rewrite the C++ part in Java, but the existing command line parser is quite involved, so I didn't quite get there. Switch to pdftk version 2 doesn't change the basic architecture of the program. (We really want to get rid of GCJ.) -- 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: pdftk retired?
On Thu, Mar 06, 2014 at 12:03:46PM +0100, Florian Weimer wrote: pdftk has a hard dependency on GCJ because it's a C++ program that uses a Java library (iText) through CNI. I once tried to rewrite the C++ part in Java, but the existing command line parser is quite involved, so I didn't quite get there. Switch to pdftk version 2 doesn't change the basic architecture of the program. (We really want to get rid of GCJ.) An additional reason is the fact, that pdftk2 may depend on iText5 or later. For licensing reasons Fedora only provides iText-2.1.7 at the last release of iText wihout any known licensing issues. That are the two reasons why I'm not able to support pdftk on Fedora anymore and was forced to reitred this package. I'm sorry for nayone who maintaining any package with dependencies on this package. Best Regards: Jochen Schmitt -- 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: Add amd map parser to autofs
= Proposed Self Contained Change: Add amd map parser to autofs = https://fedoraproject.org/wiki/Changes/Add_amd_map_parser_to_autofs Change owner(s): Ian Kent ra...@themaw.net The am-utils package provides automount services for automount maps that use an amd format. However, the am-utils project has not been actively maintained for quite a while now. The am-utils package in Fedora has significant problems that are not easily resolved so an amd format parser is to be added to the autofs package. == Detailed Description == The am-utils package provides automount services for automount maps that use an amd format. Unfortunately the am-utils project has not been actively maintained for quite a while now. The am-utils package in Fedora has significant problems that are not easily resolved so an amd format parser is to be added to the autofs package. The goal is to implement enough of the am-utils amd map parsing functionality to cover a large portion of the use cases provided by the am-utils package. Once this is done it will be up to users to describe the missing am-utils feature they need which will then be considered for addition in the upstream implementation. == Scope == The implementation of this functionality is restricted to the autofs package. Some areas of this change will require changes to code common to the autofs parser and the amd parser and the amd parser will leverage existing autofs functionality but there is a high level of code separation because of the way parse modules are added to autofs. Initially the change will be added as a path series to the autofs package, later when an upstream beta is released the source will be updated, finally when autofs-5.1.0 is released the source will updated again. The release schedule has not been decided yet but the plan is to release a beta soon followed by 5.1.0 with the timing dependant on community feedback. Not all the changes (planned for 5.1.0 but not the amd parser itself) will be included in 5.1.0, they will be added as time permits via minor version updates. This is because the amd parser is considered an important feature and needs to be made available sooner rather than later. * Proposal owners: upstream the change is nearly ready to be committed to the master branch and a beta released. If the beta is released soon enough updating the Fedora autofs package source is all that will be needed. If not then the existing patch series can be added to the autofs package in the mean time. * Other developers: N/A (not a System Wide Change) * Release engineering: N/A (not a System Wide Change) * Policies and guidelines: N/A (not a System Wide Change) ___ 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
[Fwd: Rebase of PyGreSQL to 4.1.1 into fedora rawhide]
I apologize if someone read that message twice. I sent it yesterday, but I am not able to find it. Forwarded Message From: Jozef Mlich jml...@redhat.com To: devel@lists.fedoraproject.org Date: Wed, 05 Mar 2014 12:59:43 +0100 Dear Fedora developers, I would like to push new version of PyGreSQL into Fedora rawhide (rhbz#1071940). Currently, there is 4.0-8 in Fedora. Please check the PyGreSQL changelog for more details. http://www.pygresql.org/changelog.html Please let me know, if there is some problem with new package. I have made an scratch build for you. http://koji.fedoraproject.org/koji/taskinfo?taskID=6599616 Here is a list of packages, which could be affected by this change. $ repoquery --releasever=rawhide --disablerepo=* --enablerepo=fedora-source --archlist=src --whatrequires PyGreSQL $ repoquery --releasever=rawhide --disablerepo=* --enablerepo=fedora --whatrequires PyGreSQL koji-hub-0:1.8.0-2.fc20.noarch koji-utils-0:1.8.0-2.fc20.noarch koji-web-0:1.8.0-2.fc20.noarch nf3d-0:0.8-2.fc21.noarch openerp-0:6.1-6.20130408_234645.fc20.noarch openerp7-0:7.0-4.20140109_002644.fc21.noarch python-eucadmin-0:3.3.0-0.5.20130408git32052445.fc20.noarch python-sqlobject-0:1.5.1-1.fc21.noarch In case nobody complains, I will push update into rawhide next week. regards, -- Jozef Mlich jml...@redhat.com Associate Software Engineer - EMEA ENG Developer Experience Mobile: +420 604 217 719 http://cz.redhat.com/ Red Hat, Inc. -- Jozef Mlich jml...@redhat.com Associate Software Engineer - EMEA ENG Developer Experience Mobile: +420 604 217 719 http://cz.redhat.com/ Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Beta2 of clojure-1.6.0 hits Rawhide
Hello, I will announce that a prerelease of clojure-1.6.0 has hit Rawhide. For detailted information about the changes of the upcoming releae of clujure please refer the upstream homepage [1]. Best Regards: Jochen Schmitt [1} http://clojure.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: pdftk retired?
On 03/06/2014 12:03 PM, Susi Lehtola wrote: On Thu, 06 Mar 2014 11:31:18 +0100 Michael J Gruber m...@fedoraproject.org wrote: I just git a broken dependencies notice for a package that I maintain. The reason is that pdftk got retired just the other day. I may have missed a corresponding post on fedora-devel, but I think a heads up notice to maintainers of depending packages may be in order before you retire a package, as a general idea. You see, unretiring a package is so much more work than changing maintainership. As for pdftk: I see 2 failed builds for version 1.45 and none for the current version 2.02 (which probably breaks the api anyways). What are the plans? Retire pdftk completely? Start fresh with pdftk2? pdflabs, the maker of pdftk, provide binary as well as source rpms for pdftk 2.02, by the way. I might even look into packaging it but don't want to duplicate any existing efforts. Michael +1 pdftk is a very important package, so new (co)maintainers shouldn't be hard to find. +++1 Joachim Backes -- Fedora release 20 (Heisenbug) Kernel-3.13.5-202.fc20.x86_64 Joachim Backes joachim.bac...@rhrk.uni-kl.de https://www-user.rhrk.uni-kl.de/~backes/de-index.html https://www-user.rhrk.uni-kl.de/~backes/en-index.html -- 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: Summary/Minutes from today's FESCo Meeting (2014-03-05)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/06/2014 02:06 AM, Tomasz Torcz wrote: On Wed, Mar 05, 2014 at 03:57:02PM -0500, Bill Nottingham wrote: * #1230Requesting FESCo address Cherokee logo issue (notting, 18:48:47) * LINK: https://fedorahosted.org/fesco/ticket/1230 (notting, 18:48:47) * AGREED: FESCo decision reiterated. Package will be retired Monday if not fixed. (+:7,-:0,0:0) (notting, 18:54:42) Seriously? Retiring useful package? Isn't that a bit of overkill? (Yes, I'm grumpy because I'm using Cherokee). This has been discussed ad nauseam. The reasoning was that upstream ships imagery that is in violation of Fedora's policy not to ship offensive material. We gave the upstream maintainer two weeks to remove that imagery and update the package and have now extended that through Monday. Moreover, Toshio Kuratomi has now gone and used his provenpackager powers[1] to remove these offensive images and rebuild, which means that the package will remain. As for it being overkill: Fedora has policies for a reason. Regardless of the utility of a particular package, if its presence in the distribution is offensive (and thereby risks alienating users and contributors or potentially leading to legal action), then it has to be dealt with accordingly. [1] http://koji.fedoraproject.org/koji/buildinfo?buildID=502771 -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlMYcVQACgkQeiVVYja6o6NsJgCfRlz9kj65/KP1qj27AAGx0GjA 8b4An1PZy62DQ9ovQSHy9xiLKSIqLfA9 =kYp7 -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: Schedule for Thursday's FPC Meeting (2014-03-06 17:00 UTC)
Could someone add https://fedorahosted.org/fpc/ticket/392 to the agenda for today's meeting? I believe I have provided all the information the FPC asked for the last time it was discussed. Rob On 03/05/2014 04:27 PM, James Antill wrote: Following is the list of topics that will be discussed in the FPC meeting Thursday at -MM-DD 16:00 UTC in #fedora-meeting-1 on irc.freenode.net. Local time information (via. rktime): 2014-03-06 09:00 Thu US/Pacific PST 2014-03-06 12:00 Thu US/Eastern EST 2014-03-06 17:00 Thu UTC - 2014-03-06 17:00 Thu Europe/London - 2014-03-06 18:00 Thu Europe/Paris CET 2014-03-06 18:00 Thu Europe/Berlin CET 2014-03-06 22:30 Thu Asia/Calcutta IST --new day-- 2014-03-07 01:00 Fri Asia/Singapore SGT 2014-03-07 01:00 Fri Asia/Hong_Kong HKT 2014-03-07 02:00 Fri Asia/Tokyo JST 2014-03-07 03:00 Fri Australia/Brisbane EST Links to all tickets below can be found at: https://fedorahosted.org/fpc/report/12 = Followups = (approval and retirement sections already passed, /opt exception passed) #topic #339 software collections in Fedora .fpc 339 https://fedorahosted.org/fpc/ticket/339 #topic #382 Go Packaging Guidelines Draft .fpc 382 https://fedorahosted.org/fpc/ticket/382 #topic #385 workarounds for rpm symlink - directory issue .fpc 385 https://fedorahosted.org/fpc/ticket/385 #topic #391 Exception for bundled libraries in icecat .fpc 391 https://fedorahosted.org/fpc/ticket/391 #topic #395 Mono guidelines include hard-coded library paths .fpc 395 https://fedorahosted.org/fpc/ticket/395 #topic #396 Reserve static UID/GID for OpenStack ironic daemon .fpc 396 https://fedorahosted.org/fpc/ticket/396 #topic #397 Please, choose an ID number for a new group called input .fpc 397 https://fedorahosted.org/fpc/ticket/397 = New business = #topic #398 Tilde in version .fpc 398 https://fedorahosted.org/fpc/ticket/398 #topic #399 request for bundled library exception - clustal omega .fpc 399 https://fedorahosted.org/fpc/ticket/399 #topic #400 Exception for bundled library FoX in exciting .fpc 400 https://fedorahosted.org/fpc/ticket/400 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at: https://fedorahosted.org/fpc/report/12 If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fpc, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Sshd getting 'dyntransition' AVC's in SElinux enforcing mode
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/06/2014 01:45 AM, Dan Callaghan wrote: Excerpts from Dan Callaghan's message of 2014-03-06 16:43:26 +1000: Excerpts from Daniel J Walsh's message of 2014-01-03 01:46:44 +1000: This is caused by sshd running with the wrong label, It should be running as sshd_t not init_t. If the executable labeled sshd_exec_t? ls -lZ /usr/sbin/sshd restorecon -v /usr/sbin/sshd should fix the label. I started getting the same AVC denials a week or so ago. My /usr/sbin/sshd was indeed wrongly labelled: $ ll -Z /usr/sbin/sshd -rwxr-xr-x. root root unconfined_u:object_r:bin_t:s0 /usr/sbin/sshd $ sudo restorecon -v /usr/sbin/sshd restorecon reset /usr/sbin/sshd context unconfined_u:object_r:bin_t:s0-unconfined_u:object_r:sshd_exec_t:s0 What I'm wondering is, how did it become wrongly labelled? Nothing else on my filesystem was wrong, according to restorecon. The errors only appear in my logs after sshd was restarted on 24 Feb for a yum upgrade. The updated packages included: selinux-policy-3.12.1-122.fc20.noarch openssh-server-6.4p1-3.fc20.x86_64 (among many others). Any hints on how I can figure out what went wrong with the labelling of /usr/sbin/sshd? Oh, I forgot that the yum upgrade on 24 Feb was actually from F19-F20, just like Philip who originally started this thread. I suppose that means we just write it off as upgrading between releases is not supported then... I don't know what happened. We have seen this bug usually when people are updating from older Fedoras to F20. It is strange, and I would figure it is something with rpm, or something in the sshd package. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlMYgsgACgkQrlYvE4MpobNdEwCfTyrlhx/WCsZumpK5VM62zWBF 1RMAoL3Pi7RK1zebSH+OwKL4eAxjJYSL =mwRc -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: Summary/Minutes from today's FESCo Meeting (2014-03-05)
sgallagh wrote: Seriously? Retiring useful package? Isn't that a bit of overkill? (Yes, I'm grumpy because I'm using Cherokee). This has been discussed ad nauseam. The reasoning was that upstream ships imagery that is in violation of Fedora's policy not to ship offensive material. [...] Considering the inherently political and subjective nature of this, could those policy terms be clarified so that offensiveness is defined simply by fesco construal? - FChE -- 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: Summary/Minutes from today's FESCo Meeting (2014-03-05)
On Thu, Mar 6, 2014 at 3:47 PM, Frank Ch. Eigler f...@redhat.com wrote: sgallagh wrote: Seriously? Retiring useful package? Isn't that a bit of overkill? (Yes, I'm grumpy because I'm using Cherokee). This has been discussed ad nauseam. The reasoning was that upstream ships imagery that is in violation of Fedora's policy not to ship offensive material. [...] Considering the inherently political and subjective nature of this, could those policy terms be clarified so that offensiveness is defined simply by fesco construal? I doubt that this can be defined .. it has to be a case by case basis. For instance we named a release beefy miracle and that might have been offensive for some people (ex. in India)., but apparently no one cared enough to officially complain. -- 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: Summary/Minutes from today's FESCo Meeting (2014-03-05)
On Thu, Mar 06, 2014 at 15:50:37 +0100, drago01 drag...@gmail.com wrote: For instance we named a release beefy miracle and that might have been offensive for some people (ex. in India)., but apparently no one cared enough to officially complain. That depends on what you mean by official. I believe this issue got raised for the board. But the issue was raised close to the release, which may have tilted the decision toward keeping the name. -- 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: Summary/Minutes from today's FESCo Meeting (2014-03-05)
Hi On Thu, Mar 6, 2014 at 9:50 AM, drago01 wrote: For instance we named a release beefy miracle and that might have been offensive for some people (ex. in India)., but apparently no one cared enough to officially complain. I certainly did file a complaint against generic-logos which has a similar problem with Fedora Board which in turn dismissed my concern and failed to answer my follow up question and I gave up on it. That is of course artwork that Fedora itself is upstream of rather than merely something we package. One would hope that the new standard applies to concerns outside of U.S as well. Rahul -- 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-Net-GitHub/epel7] (6 commits) ...0.56 bump
Summary of changes: e09fc3e... - Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass (*) 3bd36cb... Perl 5.18 rebuild (*) ff127e8... 0.53 bump (*) aa25e92... 0.54 bump (*) de61f8d... 0.55 bump, no code changes (*) 3b6fae0... 0.56 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-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Proposal: Don't show applications in the software center with XPM icons
XPM is an old standard for icons used by a very small number of desktop packages in Fedora. The XPM icons are normally small, mostly 8 bit, and usually without an alpha channel and look very bad in the software center. I'm going to propose for F21 that we drop support for XPM in the metadata extractor and only show apps with GIF, PNG and SVG icons. The list of affected GUI applications is here: TeXmacs cycle flamerobin gnurobots linsmith mup pari-gp pgadmin3 qtel qucs xsensors As usual, I'd like to push packagers to get upstream to ship a more modern (and high resolution, *with* alpha channel) icon in PNG or SVG format, but packagers can also just replace the icon referenced in the .desktop file if upstream is unwilling / dead and a good replacement is available. Comments welcome, Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
review swap: cscppc, cswrap
Hi, is anyone willing to review or swap reviews of the following packages? * cscppc - A compiler wrapper that runs cppcheck in background, available at https://bugzilla.redhat.com/1066026 * cswrap - Generic compiler wrapper, available at https://bugzilla.redhat.com/1066028 Basic info and motivation for adding these packages to Fedora is available at http://kdudka.fedorapeople.org/static-analysis-devconf14.pdf. Thanks in advance! Kamil -- 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: Summary/Minutes from today's FESCo Meeting (2014-03-05)
On Thu, Mar 06, 2014 at 03:50:37PM +0100, drago01 wrote: For instance we named a release beefy miracle and that might have been offensive for some people (ex. in India)., but apparently no one cared enough to officially complain. Additionally, there is a fundamental difference here. The problem isn't that someone might be offended -- people might be (and are) offended by anything. The problem is that the logo refers to a marginalized race of people using stereotyped imagery. While many people do not eat beef and hold cows sacred, the beefy miracle logo does not make any reference to those people. If it did, it too would have been a problem. -- Matthew Miller-- Fedora Project--mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Re: Packaging guideline for a library using either Qt4 or Qt5
Laurent Rineau wrote: Do you suggest that the upstream project should have a different library name when it is compiled with Qt4 and Qt5? Yes. library name *and* header path (and anything else that may potentially conflict). -- 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: Summary/Minutes from today's FESCo Meeting (2014-03-05)
On Thu, Mar 6, 2014 at 6:00 PM, Matthew Miller mat...@fedoraproject.org wrote: On Thu, Mar 06, 2014 at 03:50:37PM +0100, drago01 wrote: For instance we named a release beefy miracle and that might have been offensive for some people (ex. in India)., but apparently no one cared enough to officially complain. Additionally, there is a fundamental difference here. The problem isn't that someone might be offended -- people might be (and are) offended by anything. The problem is that the logo refers to a marginalized race of people using stereotyped imagery. While many people do not eat beef and hold cows sacred, the beefy miracle logo does not make any reference to those people. If it did, it too would have been a problem. I don't think this difference matters in practice for those people. -- 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: Proposal: Don't show applications in the software center with XPM icons
Not showing app, because they have bad looking icons, seems like a bad idea to me. what about using some cairo magic to merge the .xpm icon with some other .png frame to make it look better http://stackoverflow.com/questions/10983739/how-to-composite-multiple-png-into-a-single-png-using-gtk-cairo cairo should be able to load XPM, as far as I know Or just show some standard icon base on the app category Tim On Thu, Mar 6, 2014 at 4:41 PM, Richard Hughes hughsi...@gmail.com wrote: XPM is an old standard for icons used by a very small number of desktop packages in Fedora. The XPM icons are normally small, mostly 8 bit, and usually without an alpha channel and look very bad in the software center. I'm going to propose for F21 that we drop support for XPM in the metadata extractor and only show apps with GIF, PNG and SVG icons. The list of affected GUI applications is here: TeXmacs cycle flamerobin gnurobots linsmith mup pari-gp pgadmin3 qtel qucs xsensors As usual, I'd like to push packagers to get upstream to ship a more modern (and high resolution, *with* alpha channel) icon in PNG or SVG format, but packagers can also just replace the icon referenced in the .desktop file if upstream is unwilling / dead and a good replacement is available. Comments welcome, Richard -- 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: Summary/Minutes from today's FESCo Meeting (2014-03-05)
On Thu, Mar 6, 2014 at 4:10 PM, Bruno Wolff III br...@wolff.to wrote: On Thu, Mar 06, 2014 at 15:50:37 +0100, drago01 drag...@gmail.com wrote: For instance we named a release beefy miracle and that might have been offensive for some people (ex. in India)., but apparently no one cared enough to officially complain. That depends on what you mean by official. I believe this issue got raised for the board. OK I seem to have missed that. But the issue was raised close to the release, which may have tilted the decision toward keeping the name. Really? Changing a name has way less of an effect then removing a package (ok removing the package was the last resort) but still. But anyway my point was rather we have been inconsistent in enforcing this rule anyway because everyone else have different opinions on what offending means (see Matthews reply) ... so trying to come up with a definition wouldn't really work because some people would be well ... offended ... by the definition of offended ... so lets not open this can of worms. -- 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: hierarchical comps groups proposal
On Wed, Mar 05, 2014 at 03:40:34AM -0500, Jens Petersen wrote: I would like to suggest the idea of adding support for hierarchical comps groups to Fedora. Worth noting that it _used_ to have that functionality and it was dropped. With the Fedora.next initiative now seems a good time to do this. It should probably be made a system-wide change proposal (I only noticed the deadline this week!) I would be happy to help (at least) prepare a Change proposal for this, specially if other people (stakeholders) are willing to help make this happen. Primary stakeholders would be: - yum/dnf - anaconda (possibly insulated from this by yum? Not sure.) - product/spin maintainers - comps file maintainers - installation docs writers - users with existing kickstart files Others? -- Matthew Miller-- Fedora Project--mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: pdftk retired?
On 03/06/2014 06:41 AM, Jochen Schmitt wrote: On Thu, Mar 06, 2014 at 12:03:46PM +0100, Florian Weimer wrote: pdftk has a hard dependency on GCJ because it's a C++ program that uses a Java library (iText) through CNI. I once tried to rewrite the C++ part in Java, but the existing command line parser is quite involved, so I didn't quite get there. Switch to pdftk version 2 doesn't change the basic architecture of the program. (We really want to get rid of GCJ.) An additional reason is the fact, that pdftk2 may depend on iText5 or later. For licensing reasons Fedora only provides iText-2.1.7 at the last release of iText wihout any known licensing issues. That are the two reasons why I'm not able to support pdftk on Fedora anymore and was forced to reitred this package. I'm sorry for nayone who maintaining any package with dependencies on this package. This is why pdftk died. We can't include iText5+ because of its licensing issues. ~tom == ¸.·´¯`·.´¯`·.¸¸.·´¯`·.¸(((º OSAS @ Red Hat University Outreach || Fedora Special Projects || Fedora Legal -- 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: Re: Packaging guideline for a library using either Qt4 or Qt5
Laurent Rineau wrote: Do you suggest that the upstream project should have a different library name when it is compiled with Qt4 and Qt5? Yes, see Rex Dieter's reply. Why is that better than the following suggestion: /usr/lib64/libQGLViewer.so - libQGLViewer.so.2.5.1 /usr/lib64/libQGLViewer.so.2.5.1 /usr/lib64/Qt5/libQGLViewer.so - libQGLViewer.so.2.5.1 /usr/lib64/Qt5/libQGLViewer.so.2.5.1 Because that suggestion relies on rpath (yuck!), -L flags and similar hacks to select the correct version. It also tries to establish a standard /usr/lib64/Qt5 that has no uptake from other packages, the other upstreams are renaming their libraries (e.g., all the KDE ones, and even Qt itself). The Qt 5 version should be something like: /usr/lib64/libQGLViewer-qt5.so → libQGLViewer-qt5.so.2.5.1 /usr/lib64/libQGLViewer-qt5.so.2.5.1 (Please do not rename the Qt 4 version, for backwards compatibility.) And the libQGLViewer-qt5.so name should really get upstreamed. 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
Re: Summary/Minutes from today's FESCo Meeting (2014-03-05)
Rahul Sundaram wrote: I certainly did file a complaint against generic-logos which has a similar problem with Fedora Board which in turn dismissed my concern and failed to answer my follow up question and I gave up on it. That is of course artwork that Fedora itself is upstream of rather than merely something we package. One would hope that the new standard applies to concerns outside of U.S as well. That's the crux of the issue, offensive is really interpreted as offensive to people in the USA. That just does not make sense for a worldwide distribution, nor even for an international company. 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
Re: Summary/Minutes from today's FESCo Meeting (2014-03-05)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/06/2014 03:02 PM, Kevin Kofler wrote: Rahul Sundaram wrote: I certainly did file a complaint against generic-logos which has a similar problem with Fedora Board which in turn dismissed my concern and failed to answer my follow up question and I gave up on it. That is of course artwork that Fedora itself is upstream of rather than merely something we package. One would hope that the new standard applies to concerns outside of U.S as well. That's the crux of the issue, offensive is really interpreted as offensive to people in the USA. That just does not make sense for a worldwide distribution, nor even for an international company. This statement is blatantly false. Brought to our attention, FESCo would treat similar instances the same way worldwide. I don't want to start listing marginalized groups in Europe, Asia and Africa (that might be offensive in and of itself), but they exist and would be accorded the same courtesy. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlMY1ogACgkQeiVVYja6o6P/cwCfURlBAW3bEng/slt4FKYiSl6o L4YAni5lP+DN5BhBKxeWI2crEEx2H4No =JFHG -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: Read this if your package includes a status notifier / system tray icon
I wrote: PS: I wrote: --+-- GTK+ (2 or 3) | You must use Canonical's libappindicator, which is | interoperable with the KDE implementation. It is | already packaged in Fedora. Several GTK+ packages | already support it, for those, it is only a | matter of adding the BuildRequires | (libappindicator-devel for GTK+ 2, | libappindicator-gtk3-devel for GTK+ 3). For some | others, patches to add libappindicator support | are available from Ubuntu. --+-- By the way, it cannot hurt to enable support for libappindicator NOW. This will, in fact, improve the integration into the current KDE Plasma Workspaces (which have been supporting the new status notifier protocol for a long time now) in several ways: PPS: The following packages are built against libappindicator on Ubuntu: -- libappindicator1 --- alarm-clock-applet clipit cryptkeeper flush gir1.2-appindicator-0.1 gnome-ppp libappindicator-dev libappindicator0.1-cil libgtk2-appindicator-perl linuxdcpp nautilus-dropbox parcellite python-appindicator quicksynergy -- libappindicator0.1-cil --- libappindicator0.1-cil-dev sparkleshare tasque tomboy -- libgtk2-appindicator-perl --- shutter -- gir1.2-appindicator-0.1 --- libappindicator-dev -- libappindicator3-1 --- cryptkeeper diodon gir1.2-appindicator3-0.1 indicator-application indicator-multiload libappindicator3-dev libbrasero-media3-1 network-manager-gnome psensor remmina steadyflow transmission-gtk transmission-remote-gtk uget update-notifier vino -- gir1.2-appindicator3-0.1 --- gtimelog indicator-cpufreq kazam libappindicator3-dev onboard ubiquity-frontend-gtk unity-autopilot -- python-appindicator --- aws-status cherrytree classicmenu-indicator deluge-gtk glipper gtk-recordmydesktop hamster-indicator indicator-china-weather lernid radiotray sbackup-gtk virt-manager winswitch (list compiled by Harald Sitter from Kubuntu). In Fedora, currently only gnome-rdp (a Mono application from SourceForge) is built against libappindicator-sharp, and only because upstream made the dependency mandatory. There is a big room for improvement there. 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
Re: Default invocation of pytest for qadevel projects
On Thu, 6 Mar 2014 07:29:32 -0700 Tim Flink tfl...@redhat.com wrote: On Thu, 6 Mar 2014 05:44:15 -0500 (EST) Kamil Paral kpa...@redhat.com wrote: For the qadevel projects I'm aware of, we've been using pytest for our unit/functional test runner. As part of the shared configuration, tests are split up into two categories, unit and functional. Unit tests are fast, do not touch the network, database or filesystem (there are some exceptions to that last part, though). Functional tests tend to be more integration tests that can set up a database or do other actions which fall outside of the previous definition of unit test. When you run pytest without any extra args, only the unit tests are run. The '--functional' arg is needed to enable collection and execution of the functional tests. Kamil recently made a request [1] to do one of two things: [1] https://phab.qadevel.cloud.fedoraproject.org/T89 1. Change the default such that functional tests are collected and exclude them from collection using a '--unit' arg 2. Change the functional arg from '--functional' to something shorter, like '--func' * note that there are restrictions on which args we can use. For example, '-f' is not allowed as single letter args are reserved for pytest itself As stated in T89, I don't have a strong opinion on this as long as it's possible to exclude the functional tests from collection and we make the same change across all of our active projects. However, I wanted to put this up for a wider discussion before changing things. Any other thoughts on this proposed change? I should remember to read the mailing list before the Phab comments. I already closed the task as wontfix with my comment included: https://phab.qadevel.cloud.fedoraproject.org/T89#9 I agree that you have a point in running just the unit tests by default. For my workflow, sure. On the other hand, I'm not sure what other peoples' workflow looks like and if it reduces confusion, we may be better off changing the defaults to run functional tests. As I stated in the ticket, as long as I can turn off the functional tests with a command line arg, my workflow won't be affected. Other thoughts on which is a better default? Changing --functional to --func would be nice, though. It even matches the file prefix for func tests, 'functest_'. Sure, I'm game for changing that. The two args that come to mind are: * --long (more generic than functional) * --func (short for functional) Any thoughts on which of those (if either) would be better? Tim Using --func would be a clean and concise way to specify that. Enhances readability as well. // Mike signature.asc Description: PGP signature ___ qa-devel mailing list qa-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/qa-devel
Re: Summary/Minutes from today's FESCo Meeting (2014-03-05)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/06/2014 03:11 PM, Stephen Gallagher wrote: On 03/06/2014 03:02 PM, Kevin Kofler wrote: Rahul Sundaram wrote: I certainly did file a complaint against generic-logos which has a similar problem with Fedora Board which in turn dismissed my concern and failed to answer my follow up question and I gave up on it. That is of course artwork that Fedora itself is upstream of rather than merely something we package. One would hope that the new standard applies to concerns outside of U.S as well. That's the crux of the issue, offensive is really interpreted as offensive to people in the USA. That just does not make sense for a worldwide distribution, nor even for an international company. This statement is blatantly false. Brought to our attention, FESCo would treat similar instances the same way worldwide. I don't want to start listing marginalized groups in Europe, Asia and Africa (that might be offensive in and of itself), but they exist and would be accorded the same courtesy. (Also Australia, sorry. Not ignored on purpose.) I think I can leave Antarctica off the list safely, though. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlMY13sACgkQeiVVYja6o6M6lgCfRg9g7YPnMhL8X5eUX0BPMHc6 UvwAnR0ksKBySPj8EeIy5UNRjqpZF2Tg =r9P1 -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: Read this if your package includes a status notifier / system tray icon
On Thu, Mar 6, 2014 at 5:30 AM, Kevin Kofler kevin.kof...@chello.at wrote: PS: I wrote: --+--- GTK+ (2 or 3) | You must use Canonical's libappindicator, which is | interoperable with the KDE implementation. It is | already packaged in Fedora. Several GTK+ packages | already support it, for those, it is only a matter | of adding the BuildRequires (libappindicator-devel | for GTK+ 2, libappindicator-gtk3-devel for GTK+ | 3). For some others, patches to add | libappindicator support are available from Ubuntu. --+--- By the way, it cannot hurt to enable support for libappindicator NOW. This will, in fact, improve the integration into the current KDE Plasma Workspaces (which have been supporting the new status notifier protocol for a long time now) in several ways: * The icons are a lot less likely to be subject to flicker and other graphical glitches than with XEmbed. Err .. this sounds like a bug in how KDE handles them. There is no reason why they should flicker (they don't in other environments either). * The icons can be rescaled to a different size. Starting from kde-workspace 4.11.6, Plasma now supports high-DPI displays by making system tray icons larger than the legacy 24 pixels on such displays. Legacy icons are not limited to 24x24 pixels that's a myth. There are broken apps out there (hello skype) but they don't have to be broken. -- 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: Read this if your package includes a status notifier / system tray icon
On Thu, 2014-03-06 at 00:07 +0100, Kevin Kofler wrote: That was the excuse for not supporting the spec in GNOME Shell: http://lists.freedesktop.org/archives/xdg/2010-January/011228.html A very bad excuse, considering that, as I pointed out, the spec GNOME proposes using instead (the Galago spec) is worse when it comes to that! Please stop rewriting history. The spec was proposed, flaws were pointed out in the review, and there was no willingness to address those flaws in any meaningful way. You can consider it an 'excuse' all you want, but from my perspective, it was the right decision. -- 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: Summary/Minutes from today's FESCo Meeting (2014-03-05)
Stephen Gallagher wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/06/2014 03:11 PM, Stephen Gallagher wrote: On 03/06/2014 03:02 PM, Kevin Kofler wrote: Rahul Sundaram wrote: I certainly did file a complaint against generic-logos which has a similar problem with Fedora Board which in turn dismissed my concern and failed to answer my follow up question and I gave up on it. That is of course artwork that Fedora itself is upstream of rather than merely something we package. One would hope that the new standard applies to concerns outside of U.S as well. That's the crux of the issue, offensive is really interpreted as offensive to people in the USA. That just does not make sense for a worldwide distribution, nor even for an international company. This statement is blatantly false. Brought to our attention, FESCo would treat similar instances the same way worldwide. I don't want to start listing marginalized groups in Europe, Asia and Africa (that might be offensive in and of itself), but they exist and would be accorded the same courtesy. (Also Australia, sorry. Not ignored on purpose.) I think I can leave Antarctica off the list safely, though. Now the Polynesians are feeling left out because you didn't say Oceania. ;-þ -- Björn Persson 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: Read this if your package includes a status notifier / system tray icon
Matthias Clasen wrote: Please stop rewriting history. The spec was proposed, flaws were pointed out in the review, and there was no willingness to address those flaws in any meaningful way. The purported flaws were of 2 kinds: * claims of underspecification that are irrelevant in practice because it was obvious to everyone (other than GNOME, perhaps) how the intended rendering looks like (similar to the XEmbed system tray icons, just without the technical limitations of the XEmbed hack), * change requests that would have broken compatibility with the existing implementations of the protocol already in wide use for little to no practical benefit, such as nitpicking about the names of some D-Bus methods. It is no surprise that those issues were not addressed. And how is that different from all those specs coming from the GNOME camp, that are always of the take it or leave it kind? You can consider it an 'excuse' all you want, but from my perspective, it was the right decision. Thanks for showing again how GNOME does not give a darn about interoperability with other desktops. (See also how BOTH the GTK+ theme integration for Qt and the Qt/KDE theme integration for GTK+ are always worked on exclusively by KDE developers.) Sometimes one has to make compromises in the name of interoperability. I don't see how it would make gnome-shell worse to just give the status notifiers using the new protocol the same treatment given to the legacy XEmbed ones (stuff them in the message tray by default, and let TopIcons work with them)). 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
Re: Read this if your package includes a status notifier / system tray icon
drago01 wrote: Legacy icons are not limited to 24x24 pixels that's a myth. In practice, they are. Ask Martin Gräßlin and/or Aaron Seigo for details. 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
Re: F20 Self Contained Change: Snapshot and Rollback Tool
On 07/17/2013 04:39 AM, Jaroslav Reznik wrote: = Proposed Self Contained Change: Snapshot and Rollback Tool = https://fedoraproject.org/wiki/Changes/Rollback Change owner(s): Stephen Gallagher sgall...@redhat.com, Colin Walters walt...@redhat.com With the advent of thinly-provisioned LVM pools, it has become possible for us to implement full-system LVM snapshotting for recording rollback points. We are planning to support this for yum updates and eventually fedup upgrades going forwards. This change request notes the addition of new tools provided by the roller-derby project to present an interface and a CLI for managing and initiating rollbacks. == Detailed description == The roller-derby project will be providing a library and a CLI for creating, labeling and managing LVM snapshots (plus non-LVM backups of /boot), oriented primarily towards rpm-managed data, but useful beyond that. The yum plugin yum-plugin-fs-snapshot will be updated to consume this library and save the system state in a compatible format. The roller-derby CLI tool will provide an interactive and scriptable interface for manipulating these snapshots and determining when to remove older ones. It will also allow the tagging of snapshots as known-good, to be skipped when automatically-trimming for space. The roller-derby project will likely provide a small daemon to keep track of the available space in the LVM pool to proactively clean up snapshots before the system runs out of space. In order to prevent loss of data when rebooting into an snapshot, the roller-derby CLI will allow saving a snapshot of the current state before rolling back and will provide tools to allow mounting of that current state to recover changes that have occurred since the rollback point. == Scope == The scope of this project is the completion of the initial release of the roller-derby project and the inclusion of thinly-provisioned LVM as an option in the Anaconda installer [1]. Proposal owners: We need to complete the roller-derby project. Other than the Anaconda change referenced above, all dependencies are available in Fedora already. Other developers: OS Installer Support for LVM Thin Provisioning Release engineering: N/A (not a System Wide Change) Policies and guidelines: N/A (not a System Wide Change) [1] https://fedoraproject.org/wiki/Changes/InstallerLVMThinProvisioningSupport I this project dead? I'm casting about to tools to manage lvm snapshots and roller-derby sounded promising. Any other tools out there? -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com -- 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: Read this if your package includes a status notifier / system tray icon
On Fri, Mar 7, 2014 at 12:18 AM, Kevin Kofler kevin.kof...@chello.at wrote: Matthias Clasen wrote: Please stop rewriting history. The spec was proposed, flaws were pointed out in the review, and there was no willingness to address those flaws in any meaningful way. The purported flaws were of 2 kinds: * claims of underspecification that are irrelevant in practice because it was obvious to everyone [...] If that's the case why can't it be in the spec then? Why leave it out and assume that everyone would do X ? -- 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 Self Contained Change: Snapshot and Rollback Tool
On Mar 6, 2014, at 4:27 PM, Orion Poplawski or...@cora.nwra.com wrote: Other developers: OS Installer Support for LVM Thin Provisioning Release engineering: N/A (not a System Wide Change) Policies and guidelines: N/A (not a System Wide Change) [1] https://fedoraproject.org/wiki/Changes/InstallerLVMThinProvisioningSupport I this project dead? I'm casting about to tools to manage lvm snapshots and roller-derby sounded promising. Any other tools out there? There's a recent snapshot/rollback thread on the desktop list that relates to this. LVM thin provisioning support is in the Fedora 20 installer (it fails to produce a bootable system, the post-install fix for which is listed in Fedora 20 common bugs). However, if OSTree is used, then there isn't a hard requirement on either LVM Thin Provisioning or Btrfs. 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
Re: Proposal: Don't show applications in the software center with XPM icons
Apps with ugly icons and ugly design results in bad user experience IMO. They should not be displayed in the software center. If devs want an icon, there are lots of icon designers out there who can contribute one. You just need to ask. On 7 March 2014 00:21, Tim Lauridsen tim.laurid...@gmail.com wrote: Not showing app, because they have bad looking icons, seems like a bad idea to me. what about using some cairo magic to merge the .xpm icon with some other .png frame to make it look better http://stackoverflow.com/questions/10983739/how-to-composite-multiple-png-into-a-single-png-using-gtk-cairo cairo should be able to load XPM, as far as I know Or just show some standard icon base on the app category Tim On Thu, Mar 6, 2014 at 4:41 PM, Richard Hughes hughsi...@gmail.com wrote: XPM is an old standard for icons used by a very small number of desktop packages in Fedora. The XPM icons are normally small, mostly 8 bit, and usually without an alpha channel and look very bad in the software center. I'm going to propose for F21 that we drop support for XPM in the metadata extractor and only show apps with GIF, PNG and SVG icons. The list of affected GUI applications is here: TeXmacs cycle flamerobin gnurobots linsmith mup pari-gp pgadmin3 qtel qucs xsensors As usual, I'd like to push packagers to get upstream to ship a more modern (and high resolution, *with* alpha channel) icon in PNG or SVG format, but packagers can also just replace the icon referenced in the .desktop file if upstream is unwilling / dead and a good replacement is available. Comments welcome, Richard -- 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 -- Satyajit Sahoo Profile - Facebook, Google+ Artwork - DeviantArt -- 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 1057012] abi-compliance-checker-1.99.9 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1057012 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #3 from Fedora Update System upda...@fedoraproject.org --- Package abi-compliance-checker-1.99.9-1.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing abi-compliance-checker-1.99.9-1.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-3462/abi-compliance-checker-1.99.9-1.fc20 then log in and leave karma (feedback). -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=RJgpCCgtv0a=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 958821] Threaded glob segfaults
https://bugzilla.redhat.com/show_bug.cgi?id=958821 Jitka Plesnikova jples...@redhat.com changed: What|Removed |Added Fixed In Version||perl-5.18.2-289.fc20 --- Comment #6 from Jitka Plesnikova jples...@redhat.com --- The fix has been in 5.18.2 (perl-5.18.2-289.fc20). -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=t5hT1jMLdEa=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 239333] Branch perl-Net-Server for EPEL
https://bugzilla.redhat.com/show_bug.cgi?id=239333 Jon Ciesla limburg...@gmail.com changed: What|Removed |Added Flags|fedora-cvs? |fedora-cvs+ -- 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=SNDuVYlKwfa=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 239333] Branch perl-Net-Server for EPEL
https://bugzilla.redhat.com/show_bug.cgi?id=239333 --- Comment #3 from Jon Ciesla limburg...@gmail.com --- Git done (by process-git-requests). -- 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=gEkFeyqg27a=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 AnyEvent-XMPP-0.55.tar.gz uploaded to lookaside cache by psabata
A file has been added to the lookaside cache for perl-AnyEvent-XMPP: 0c23bd2905b593bc5d51e04b89410322 AnyEvent-XMPP-0.55.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-AnyEvent-XMPP] 0.55 bugfix bump
commit d74466d6f10305b3112343f42e888ddf11f854db
Author: Petr Šabata con...@redhat.com
Date: Thu Mar 6 14:10:01 2014 +0100
0.55 bugfix bump
.gitignore |1 +
perl-AnyEvent-XMPP.spec | 17 -
sources |2 +-
3 files changed, 14 insertions(+), 6 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index b371633..40aeed1 100644
--- a/.gitignore
+++ b/.gitignore
@@ -2,3 +2,4 @@ AnyEvent-XMPP-0.51.tar.gz
/AnyEvent-XMPP-0.52.tar.gz
/AnyEvent-XMPP-0.53.tar.gz
/AnyEvent-XMPP-0.54.tar.gz
+/AnyEvent-XMPP-0.55.tar.gz
diff --git a/perl-AnyEvent-XMPP.spec b/perl-AnyEvent-XMPP.spec
index d85e7f2..2edce50 100644
--- a/perl-AnyEvent-XMPP.spec
+++ b/perl-AnyEvent-XMPP.spec
@@ -1,6 +1,6 @@
Name: perl-AnyEvent-XMPP
-Version:0.54
-Release:4%{?dist}
+Version:0.55
+Release:1%{?dist}
Summary:Implementation of the XMPP Protocol
License:GPL+ or Artistic
Group: Development/Libraries
@@ -8,12 +8,13 @@ URL:http://search.cpan.org/dist/AnyEvent-XMPP/
Source0:
http://www.cpan.org/authors/id/M/MS/MSTPLBG/AnyEvent-XMPP-%{version}.tar.gz
Patch0: AnyEvent-XMPP-0.51-timezone.patch
BuildArch: noarch
-BuildRequires: perl(base)
-BuildRequires: perl(constant)
+BuildRequires: perl
BuildRequires: perl(AnyEvent)
BuildRequires: perl(AnyEvent::Handle)
BuildRequires: perl(AnyEvent::Socket)
BuildRequires: perl(Authen::SASL)
+BuildRequires: perl(base)
+BuildRequires: perl(constant)
BuildRequires: perl(Data::Dumper)
BuildRequires: perl(Digest::SHA)
BuildRequires: perl(Encode)
@@ -23,9 +24,12 @@ BuildRequires: perl(IO::Handle)
BuildRequires: perl(MIME::Base64)
BuildRequires: perl(Net::LibIDN)
BuildRequires: perl(Object::Event)
+BuildRequires: perl(overload)
BuildRequires: perl(Scalar::Util)
+BuildRequires: perl(strict)
BuildRequires: perl(Test::More)
BuildRequires: perl(Time::Local)
+BuildRequires: perl(warnings)
BuildRequires: perl(XML::Parser::Expat)
BuildRequires: perl(XML::Twig)
BuildRequires: perl(XML::Writer)
@@ -52,7 +56,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
@@ -64,6 +68,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Thu Mar 06 2014 Petr Šabata con...@redhat.com - 0.55-1
+- 0.55 bugfix bump
+
* Sat Aug 03 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 0.54-4
- Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild
diff --git a/sources b/sources
index c2eb5d6..5dec29b 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-20b008e67537eb3125e4376a0ba09883 AnyEvent-XMPP-0.54.tar.gz
+0c23bd2905b593bc5d51e04b89410322 AnyEvent-XMPP-0.55.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-AnyEvent-XMPP/f20] 0.55 bugfix bump
Summary of changes: d74466d... 0.55 bugfix bump (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-AnyEvent-XMPP/f19] (3 commits) ...0.55 bugfix bump
Summary of changes: dd43f5a... Perl 5.18 rebuild (*) a44255e... - Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass (*) d74466d... 0.55 bugfix 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
[Bug 1071639] perl-AnyEvent-XMPP-0.55 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1071639 --- Comment #1 from Fedora Update System upda...@fedoraproject.org --- perl-AnyEvent-XMPP-0.55-1.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/perl-AnyEvent-XMPP-0.55-1.fc20 -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=J7tlTDKTJca=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 Net-Domain-TLD-1.70.tar.gz uploaded to lookaside cache by spot
A file has been added to the lookaside cache for perl-Net-Domain-TLD: 025709d5c48461ff8b647254ac3cffbc Net-Domain-TLD-1.70.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-Domain-TLD] 1.70
commit c426ffa013d256a08bd143546e3463c72997936b
Author: Tom Callaway s...@fedoraproject.org
Date: Thu Mar 6 08:50:30 2014 -0500
1.70
.gitignore |1 +
perl-Net-Domain-TLD.spec |7 +--
sources |2 +-
3 files changed, 7 insertions(+), 3 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 774750c..d89436d 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,2 +1,3 @@
Net-Domain-TLD-1.68.tar.gz
/Net-Domain-TLD-1.69.tar.gz
+/Net-Domain-TLD-1.70.tar.gz
diff --git a/perl-Net-Domain-TLD.spec b/perl-Net-Domain-TLD.spec
index a915404..e1cd76c 100644
--- a/perl-Net-Domain-TLD.spec
+++ b/perl-Net-Domain-TLD.spec
@@ -1,6 +1,6 @@
Name: perl-Net-Domain-TLD
-Version:1.69
-Release:3%{?dist}
+Version:1.70
+Release:1%{?dist}
Summary:Work with TLD names
Group: Development/Libraries
License:GPL+ or Artistic
@@ -52,6 +52,9 @@ rm -rf $RPM_BUILD_ROOT
%changelog
+* Thu Mar 6 2014 Tom Callaway s...@fedoraproject.org - 1.70-1
+- update to 1.70
+
* Sat Aug 03 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 1.69-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild
diff --git a/sources b/sources
index dde518e..d1a6dab 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-91c1bbf87994e966775994de2179f09b Net-Domain-TLD-1.69.tar.gz
+025709d5c48461ff8b647254ac3cffbc Net-Domain-TLD-1.70.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 1071639] perl-AnyEvent-XMPP-0.55 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1071639 --- Comment #2 from Fedora Update System upda...@fedoraproject.org --- perl-AnyEvent-XMPP-0.55-1.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/perl-AnyEvent-XMPP-0.55-1.fc19 -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=9FJ2VyGQI7a=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 Email-MIME-1.926.tar.gz uploaded to lookaside cache by spot
A file has been added to the lookaside cache for perl-Email-MIME: fd8b06d1bf7b8599bdcf808f49908451 Email-MIME-1.926.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-Email-MIME] 1.926
commit 7045f6fff684d4b992475e4e7f73caf02ae630d9
Author: Tom Callaway s...@fedoraproject.org
Date: Thu Mar 6 09:22:36 2014 -0500
1.926
perl-Email-MIME.spec |5 -
sources |2 +-
2 files changed, 5 insertions(+), 2 deletions(-)
---
diff --git a/perl-Email-MIME.spec b/perl-Email-MIME.spec
index aace717..cb657c4 100644
--- a/perl-Email-MIME.spec
+++ b/perl-Email-MIME.spec
@@ -1,5 +1,5 @@
Name: perl-Email-MIME
-Version:1.924
+Version:1.926
Release:1%{?dist}
Summary:Easy MIME message parsing
@@ -79,6 +79,9 @@ make test TEST_FILES=$(echo $(find xt/ -name '*.t'))
%changelog
+* Thu Mar 6 2014 Tom Callaway s...@fedoraproject.org - 1.926-1
+- update to 1.926
+
* Sun Aug 11 2013 Paul Howarth p...@city-fan.org - 1.924-1
- Update to 1.924
- Update use of Email::MIME::ContentType to match new, fixed hash keys:
diff --git a/sources b/sources
index b2ddd3b..9604acd 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-d639114a3c2f5a98725f55f744a888f2 Email-MIME-1.924.tar.gz
+fd8b06d1bf7b8599bdcf808f49908451 Email-MIME-1.926.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-Email-MIME/epel7] 1.926
commit fd2e6371c77608bde8b0c603b7b545f73ae87f2f
Author: Tom Callaway s...@fedoraproject.org
Date: Thu Mar 6 09:42:19 2014 -0500
1.926
perl-Email-MIME.spec | 73 ++---
sources |2 +-
2 files changed, 63 insertions(+), 12 deletions(-)
---
diff --git a/perl-Email-MIME.spec b/perl-Email-MIME.spec
index 54b8e06..cb657c4 100644
--- a/perl-Email-MIME.spec
+++ b/perl-Email-MIME.spec
@@ -1,5 +1,5 @@
Name: perl-Email-MIME
-Version:1.911
+Version:1.926
Release:1%{?dist}
Summary:Easy MIME message parsing
@@ -9,18 +9,36 @@ URL:http://search.cpan.org/dist/Email-MIME/
Source0:
http://www.cpan.org/authors/id/R/RJ/RJBS/Email-MIME-%{version}.tar.gz
BuildArch: noarch
-BuildRequires: perl(Email::Date::Format)
-BuildRequires: perl(Email::MIME::ContentType) = 1.011
-BuildRequires: perl(Email::MIME::Encodings) = 1.313
+# Module Build
+BuildRequires: perl(ExtUtils::MakeMaker) = 6.30
+# Module Runtime
+BuildRequires: perl(Carp)
+BuildRequires: perl(Email::Address)
BuildRequires: perl(Email::MessageID)
-BuildRequires: perl(Email::Simple) = 2.004
-BuildRequires: perl(ExtUtils::MakeMaker)
+BuildRequires: perl(Email::MIME::ContentType) = 1.016
+BuildRequires: perl(Email::MIME::Encodings) = 1.314
+BuildRequires: perl(Email::Simple) = 2.102
+BuildRequires: perl(Email::Simple::Creator)
+BuildRequires: perl(Email::Simple::Header)
+BuildRequires: perl(Encode) = 1.9801
+BuildRequires: perl(MIME::Base64)
BuildRequires: perl(MIME::Types) = 1.13
-BuildRequires: perl(Test::MinimumVersion)
-BuildRequires: perl(Test::Pod) = 1.14
-BuildRequires: perl(Test::Pod::Coverage) = 1.08
-Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
+BuildRequires: perl(parent)
+BuildRequires: perl(Scalar::Util)
+# Test Suite
+BuildRequires: perl(blib)
+BuildRequires: perl(Capture::Tiny)
+BuildRequires: perl(Symbol)
+BuildRequires: perl(Test::More) = 0.96
+BuildRequires: perl(utf8)
+BuildRequires: perl(version) 0.99
+# Release Tests
+BuildRequires: perl(Test::Pod) = 1.41
+# Runtime
+Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
+Requires: perl(Email::Simple::Creator)
Requires: perl(MIME::Types) = 1.13
+
Obsoletes: perl-Email-MIME-Creator 1.457
Obsoletes: perl-Email-MIME-Modifier 1.445
Provides: perl-Email-MIME-Creator = %{version}
@@ -45,12 +63,12 @@ make %{?_smp_mflags}
%install
make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT
find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} ';'
-find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2/dev/null ';'
chmod -R u+w $RPM_BUILD_ROOT/*
%check
make test
+make test TEST_FILES=$(echo $(find xt/ -name '*.t'))
%files
@@ -61,6 +79,39 @@ make test
%changelog
+* Thu Mar 6 2014 Tom Callaway s...@fedoraproject.org - 1.926-1
+- update to 1.926
+
+* Sun Aug 11 2013 Paul Howarth p...@city-fan.org - 1.924-1
+- Update to 1.924
+ - Update use of Email::MIME::ContentType to match new, fixed hash keys:
+type/subtype
+
+* Fri Aug 9 2013 Paul Howarth p...@city-fan.org - 1.923-1
+- Update to 1.923
+ - Repackage, remove PEP links, update bugtracker
+ - Try to encode headers based on the header structure, if it has one, rather
+than treating the header as a big string in all cases
+ - Do not call parts_set during walk_parts unless the parts have actually
+changed
+ - When trying to decode a body, fall back to 7bit if the encoding is unknown;
+trying to create a new body in an unknown encoding is still forbidden
+ - Avoid undefined warnings in debug_structure (CPAN RT#82388)
+ - Better error message when the given body is a ref but not a scalar
+(CPAN RT#59205)
+ - Do not consider the part-ending CRLF part of the body
+- Update build-reqs as per upstream requirements
+- Explicitly run the release tests
+- Drop %%defattr, redundant since rpm 4.4
+- Don't need to remove empty directories from the buildroot
+- Classify buildreqs by usage
+
+* Sat Aug 03 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 1.911-3
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild
+
+* Wed Jul 31 2013 Petr Pisar ppi...@redhat.com - 1.911-2
+- Perl 5.18 rebuild
+
* Sat Feb 23 2013 Ralf Corsépius corse...@fedoraproject.org - 1.911-1
- Add BR: perl(ExtUtils::MakeMaker) (Fix FTBFS #914270).
- Upstream update.
diff --git a/sources b/sources
index fec12b5..9604acd 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-82323a45ba1a3beec649f969f408c078 Email-MIME-1.911.tar.gz
+fd8b06d1bf7b8599bdcf808f49908451 Email-MIME-1.926.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-Domain-TLD/epel7] 1.70
commit 36811635edcad2d174e1efb9f118eb45502efc80
Author: Tom Callaway s...@fedoraproject.org
Date: Thu Mar 6 09:42:42 2014 -0500
1.70
perl-Net-Domain-TLD.spec | 11 ++-
sources |2 +-
2 files changed, 11 insertions(+), 2 deletions(-)
---
diff --git a/perl-Net-Domain-TLD.spec b/perl-Net-Domain-TLD.spec
index da73b90..e1cd76c 100644
--- a/perl-Net-Domain-TLD.spec
+++ b/perl-Net-Domain-TLD.spec
@@ -1,5 +1,5 @@
Name: perl-Net-Domain-TLD
-Version:1.69
+Version:1.70
Release:1%{?dist}
Summary:Work with TLD names
Group: Development/Libraries
@@ -52,6 +52,15 @@ rm -rf $RPM_BUILD_ROOT
%changelog
+* Thu Mar 6 2014 Tom Callaway s...@fedoraproject.org - 1.70-1
+- update to 1.70
+
+* Sat Aug 03 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 1.69-3
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild
+
+* Wed Jul 17 2013 Petr Pisar ppi...@redhat.com - 1.69-2
+- Perl 5.18 rebuild
+
* Tue Feb 26 2013 Petr Pisar ppi...@redhat.com - 1.69-1
- 1.69 bump
diff --git a/sources b/sources
index dde518e..d1a6dab 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-91c1bbf87994e966775994de2179f09b Net-Domain-TLD-1.69.tar.gz
+025709d5c48461ff8b647254ac3cffbc Net-Domain-TLD-1.70.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 Email-Simple-2.203.tar.gz uploaded to lookaside cache by spot
A file has been added to the lookaside cache for perl-Email-Simple: bb4bd46417522d86ae21186370c9b49d Email-Simple-2.203.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-Email-Simple] 2.203
commit f310335e0e8c2638b82c3137d892482a386aae12
Author: Tom Callaway s...@fedoraproject.org
Date: Thu Mar 6 09:53:36 2014 -0500
2.203
.gitignore |1 +
perl-Email-Simple.spec | 10 +++---
sources|2 +-
3 files changed, 9 insertions(+), 4 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 3203c01..5d3971b 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,2 +1,3 @@
Email-Simple-2.100.tar.gz
/Email-Simple-2.102.tar.gz
+/Email-Simple-2.203.tar.gz
diff --git a/perl-Email-Simple.spec b/perl-Email-Simple.spec
index 482609e..4ba105a 100644
--- a/perl-Email-Simple.spec
+++ b/perl-Email-Simple.spec
@@ -1,6 +1,6 @@
Name: perl-Email-Simple
-Version:2.102
-Release:4%{?dist}
+Version:2.203
+Release:1%{?dist}
Summary:Simple parsing of RFC2822 message format and headers
Group: Development/Libraries
@@ -10,10 +10,11 @@ Source0:
http://www.cpan.org/authors/id/R/RJ/RJBS/Email-Simple-%{version}
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch: noarch
+BuildRequires: perl(Carp)
BuildRequires: perl(Test::Pod) = 1.14
BuildRequires: perl(Test::Pod::Coverage) = 1.08
BuildRequires: perl(Test::MinimumVersion)
-BuildRequires: perl(Test::More) = 0.47
+BuildRequires: perl(Test::More) = 0.96
BuildRequires: perl(ExtUtils::MakeMaker), perl(Email::Date::Format)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
Requires: perl(Email::Date::Format)
@@ -63,6 +64,9 @@ rm -rf $RPM_BUILD_ROOT
%changelog
+* Thu Mar 6 2014 Tom Callaway s...@fedoraproject.org - 2.203-1
+- update to 2.203
+
* Sat Aug 03 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 2.102-4
- Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild
diff --git a/sources b/sources
index d24825a..51471d9 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-68809cf88371b5688bbc399f909cd493 Email-Simple-2.102.tar.gz
+bb4bd46417522d86ae21186370c9b49d Email-Simple-2.203.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-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-Prolog-Yaswi
perl-Language-Prolog-Yaswi has broken dependencies in the rawhide tree: On x86_64: perl-Language-Prolog-Yaswi-0.21-16.fc21.x86_64 requires libswipl.so.6.6.1()(64bit) On i386: perl-Language-Prolog-Yaswi-0.21-16.fc21.i686 requires libswipl.so.6.6.1 On armhfp: perl-Language-Prolog-Yaswi-0.21-16.fc21.armv7hl requires libswipl.so.6.6.1 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
[perl-Email-Simple/epel7] 2.203
commit b9c0341ffcc10290427ab6cd15274d0dbf64e436
Author: Tom Callaway s...@fedoraproject.org
Date: Thu Mar 6 12:59:31 2014 -0500
2.203
perl-Email-Simple.spec | 16 +---
sources|2 +-
2 files changed, 14 insertions(+), 4 deletions(-)
---
diff --git a/perl-Email-Simple.spec b/perl-Email-Simple.spec
index 372686c..4ba105a 100644
--- a/perl-Email-Simple.spec
+++ b/perl-Email-Simple.spec
@@ -1,6 +1,6 @@
Name: perl-Email-Simple
-Version:2.102
-Release:2%{?dist}
+Version:2.203
+Release:1%{?dist}
Summary:Simple parsing of RFC2822 message format and headers
Group: Development/Libraries
@@ -10,10 +10,11 @@ Source0:
http://www.cpan.org/authors/id/R/RJ/RJBS/Email-Simple-%{version}
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch: noarch
+BuildRequires: perl(Carp)
BuildRequires: perl(Test::Pod) = 1.14
BuildRequires: perl(Test::Pod::Coverage) = 1.08
BuildRequires: perl(Test::MinimumVersion)
-BuildRequires: perl(Test::More) = 0.47
+BuildRequires: perl(Test::More) = 0.96
BuildRequires: perl(ExtUtils::MakeMaker), perl(Email::Date::Format)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
Requires: perl(Email::Date::Format)
@@ -63,6 +64,15 @@ rm -rf $RPM_BUILD_ROOT
%changelog
+* Thu Mar 6 2014 Tom Callaway s...@fedoraproject.org - 2.203-1
+- update to 2.203
+
+* Sat Aug 03 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 2.102-4
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild
+
+* Wed Jul 31 2013 Petr Pisar ppi...@redhat.com - 2.102-3
+- Perl 5.18 rebuild
+
* Thu Feb 14 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 2.102-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_19_Mass_Rebuild
diff --git a/sources b/sources
index d24825a..51471d9 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-68809cf88371b5688bbc399f909cd493 Email-Simple-2.102.tar.gz
+bb4bd46417522d86ae21186370c9b49d Email-Simple-2.203.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-Email-MIME-ContentType/epel7] 1.017
commit a1a318862961d8b89c27bb9b0e12b6d0abda35d3
Author: Tom Callaway s...@fedoraproject.org
Date: Fri Mar 7 01:18:05 2014 -0500
1.017
perl-Email-MIME-ContentType.spec | 49 +
sources |2 +-
2 files changed, 39 insertions(+), 12 deletions(-)
---
diff --git a/perl-Email-MIME-ContentType.spec b/perl-Email-MIME-ContentType.spec
index 538d264..95cf0b7 100644
--- a/perl-Email-MIME-ContentType.spec
+++ b/perl-Email-MIME-ContentType.spec
@@ -1,6 +1,6 @@
Name: perl-Email-MIME-ContentType
-Version:1.015
-Release:14%{?dist}
+Version:1.017
+Release:1%{?dist}
Summary:Parse a MIME Content-Type Header
Group: Development/Libraries
@@ -9,16 +9,27 @@ URL:
http://search.cpan.org/dist/Email-MIME-ContentType/
Source0:
http://www.cpan.org/authors/id/R/RJ/RJBS/Email-MIME-ContentType-%{version}.tar.gz
BuildArch: noarch
-BuildRequires: perl(ExtUtils::MakeMaker)
-BuildRequires: perl(Test::Pod)
-BuildRequires: perl(Test::Pod::Coverage)
+BuildRequires: perl(blib)
+BuildRequires: perl(Capture::Tiny)
+BuildRequires: perl(Carp)
+BuildRequires: perl(Exporter) = 5.57
+BuildRequires: perl(ExtUtils::MakeMaker) = 6.30
+BuildRequires: perl(strict)
+BuildRequires: perl(Test::More) = 0.96
+BuildRequires: perl(Test::Pod) = 1.41
+BuildRequires: perl(version) 0.99
+BuildRequires: perl(warnings)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
%description
-This module is responsible for parsing email content type headers
-according to section 5.1 of RFC 2045. It returns a hash as above, with
-entries for the discrete type, the composite type, and a hash of
-attributes.
+This module is responsible for parsing email content type headers according
+to section 5.1 of RFC 2045. It returns a hash with entries for the type, the
+subtype, and a hash of attributes.
+
+For backward compatibility with a really unfortunate misunderstanding of RFC
+2045 by the early implementors of this module, 'discrete' and 'composite' are
+also present in the returned hashref, with the values of 'type' and 'subtype'
+respectively.
%prep
@@ -33,22 +44,38 @@ make %{?_smp_mflags}
%install
make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT
find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} ';'
-find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2/dev/null ';'
chmod -R u+w $RPM_BUILD_ROOT/*
%check
make test
+make test TEST_FILES=$(echo $(find xt/ -name '*.t'))
%files
-%defattr(-,root,root,-)
%doc Changes LICENSE README
%{perl_vendorlib}/Email/
%{_mandir}/man3/*.3pm*
%changelog
+* Sun Aug 11 2013 Paul Howarth p...@city-fan.org - 1.017-1
+- Update to 1.017
+ - Correct the longstanding and embarrassing misuse of discrete and
+composite to mean type and subtype; the returned data still contains
+the wrong old names so your code shouldn't break
+ - Repackage to update bugtracker, repo, etc.
+ - Make $STRICT_PARAMS actually work! (CPAN RT#87460)
+- Don't need to remove empty directories from the buildroot
+- Drop %%defattr, redundant since rpm 4.4
+- Explicitly run the release tests
+
+* Sat Aug 03 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 1.015-16
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild
+
+* Sat Jul 20 2013 Petr Pisar ppi...@redhat.com - 1.015-15
+- Perl 5.18 rebuild
+
* Sun Feb 24 2013 Ralf Corsépius corse...@fedoraproject.org - 1.015-14
- Add BR: perl(ExtUtils::MakeMaker) (Fix FTBFS #914271).
- Modernize spec.
diff --git a/sources b/sources
index ffae28b..fcf9b5f 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-f098ffed16ccab03a3bd51449eba175f Email-MIME-ContentType-1.015.tar.gz
+b1e241f07b525c427774003274e363fd Email-MIME-ContentType-1.017.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 Email-MIME-Encodings-1.315.tar.gz uploaded to lookaside cache by spot
A file has been added to the lookaside cache for perl-Email-MIME-Encodings: 0fbe906d7918430750b1ba766cf95151 Email-MIME-Encodings-1.315.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 1066374] perl-Socket6-0.25 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1066374 --- Comment #3 from Fedora Update System upda...@fedoraproject.org --- perl-Socket6-0.25-1.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report. -- 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=sG8It6BBrSa=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-Email-MIME-Encodings] 1.315
commit 286ce0648492d12b5bb6f5ec8d421a0921737913
Author: Tom Callaway s...@fedoraproject.org
Date: Fri Mar 7 01:30:18 2014 -0500
1.315
perl-Email-MIME-Encodings.spec |5 -
sources|2 +-
2 files changed, 5 insertions(+), 2 deletions(-)
---
diff --git a/perl-Email-MIME-Encodings.spec b/perl-Email-MIME-Encodings.spec
index 8f4ea61..9f14f29 100644
--- a/perl-Email-MIME-Encodings.spec
+++ b/perl-Email-MIME-Encodings.spec
@@ -1,5 +1,5 @@
Name: perl-Email-MIME-Encodings
-Version:1.314
+Version:1.315
Release:1%{?dist}
Summary:Unified interface to MIME encoding and decoding
@@ -48,6 +48,9 @@ make test
%changelog
+* Fri Mar 7 2014 Tom Callaway s...@fedoraproject.org - 1.315-1
+- update to 1.315
+
* Fri Aug 9 2013 Paul Howarth p...@city-fan.org - 1.314-1
- Update to 1.314
- Add a third argument to encode/decode/codec to allow a fallback codec
diff --git a/sources b/sources
index faffc32..3afe08c 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-f87825cfb386bdc1cca4c8cf29713bf3 Email-MIME-Encodings-1.314.tar.gz
+0fbe906d7918430750b1ba766cf95151 Email-MIME-Encodings-1.315.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 Email-MessageID-1.404.tar.gz uploaded to lookaside cache by spot
A file has been added to the lookaside cache for perl-Email-MessageID: 4dc2f45a665dde29e6f0cf8b94befba9 Email-MessageID-1.404.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-Email-MessageID] 1.404
commit e3badd8d7e9ef67561730f6374d0e6c559f3d321
Author: Tom Callaway s...@fedoraproject.org
Date: Fri Mar 7 01:33:42 2014 -0500
1.404
.gitignore|1 +
perl-Email-MessageID.spec |8 ++--
sources |2 +-
3 files changed, 8 insertions(+), 3 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index e6e20c7..a045756 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1,2 @@
/Email-MessageID-1.402.tar.gz
+/Email-MessageID-1.404.tar.gz
diff --git a/perl-Email-MessageID.spec b/perl-Email-MessageID.spec
index 02a6328..692f8fe 100644
--- a/perl-Email-MessageID.spec
+++ b/perl-Email-MessageID.spec
@@ -1,6 +1,6 @@
Name: perl-Email-MessageID
-Version:1.402
-Release:3%{?dist}
+Version:1.404
+Release:1%{?dist}
Summary:Generate world unique message-ids
Group: Development/Libraries
@@ -13,6 +13,7 @@ BuildRequires: perl(Email::Address) = 1.80
BuildRequires: perl(ExtUtils::MakeMaker)
BuildRequires: perl(Test::Pod) = 1.14
BuildRequires: perl(Test::Pod::Coverage) = 1.08
+BuildRequires: perl(Sys::Hostname)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
# rpm misses this
Requires: perl(Email::Address)
@@ -50,6 +51,9 @@ make test
%changelog
+* Fri Mar 7 2014 Tom Callaway s...@fedoraproject.org - 1.404-1
+- update to 1.404
+
* Sat Aug 03 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 1.402-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild
diff --git a/sources b/sources
index 8c3632d..0438d85 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-ceadc7110336fa0de0da5e2c49be8235 Email-MessageID-1.402.tar.gz
+4dc2f45a665dde29e6f0cf8b94befba9 Email-MessageID-1.404.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 1062886] perl-Net-GitHub-0.56 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1062886 --- Comment #3 from Fedora Update System upda...@fedoraproject.org --- perl-Net-GitHub-0.56-1.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report. -- 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=jSyW7hUcJxa=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 1066374] perl-Socket6-0.25 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1066374 --- Comment #4 from Fedora Update System upda...@fedoraproject.org --- perl-Socket6-0.25-1.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report. -- 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=YiPXFdELiia=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 1062886] perl-Net-GitHub-0.56 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1062886 --- Comment #4 from Fedora Update System upda...@fedoraproject.org --- perl-Net-GitHub-0.56-1.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report. -- 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=CoLU0M9Bbaa=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-Email-MessageID/epel7] 1.404
commit 0efed8d86139645dc39b343a2bfd1ec64eb86deb
Author: Tom Callaway s...@fedoraproject.org
Date: Fri Mar 7 01:50:58 2014 -0500
1.404
perl-Email-MessageID.spec | 12 +++-
sources |2 +-
2 files changed, 12 insertions(+), 2 deletions(-)
---
diff --git a/perl-Email-MessageID.spec b/perl-Email-MessageID.spec
index d9161e8..692f8fe 100644
--- a/perl-Email-MessageID.spec
+++ b/perl-Email-MessageID.spec
@@ -1,5 +1,5 @@
Name: perl-Email-MessageID
-Version:1.402
+Version:1.404
Release:1%{?dist}
Summary:Generate world unique message-ids
@@ -13,6 +13,7 @@ BuildRequires: perl(Email::Address) = 1.80
BuildRequires: perl(ExtUtils::MakeMaker)
BuildRequires: perl(Test::Pod) = 1.14
BuildRequires: perl(Test::Pod::Coverage) = 1.08
+BuildRequires: perl(Sys::Hostname)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
# rpm misses this
Requires: perl(Email::Address)
@@ -50,6 +51,15 @@ make test
%changelog
+* Fri Mar 7 2014 Tom Callaway s...@fedoraproject.org - 1.404-1
+- update to 1.404
+
+* Sat Aug 03 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 1.402-3
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild
+
+* Sun Jul 21 2013 Petr Pisar ppi...@redhat.com - 1.402-2
+- Perl 5.18 rebuild
+
* Sun Feb 24 2013 Ralf Corsépius corse...@fedoraproject.org - 1.402-1
- Add BR: per(ExtUtils::MakeMaker) (Fix FTBFS #914273).
- Upstream update.
diff --git a/sources b/sources
index 8c3632d..0438d85 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-ceadc7110336fa0de0da5e2c49be8235 Email-MessageID-1.402.tar.gz
+4dc2f45a665dde29e6f0cf8b94befba9 Email-MessageID-1.404.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-Email-MIME-Encodings] missing BR
commit e7c2675db35c1f7a59b457e5add38f2bc7785d43
Author: Tom Callaway s...@fedoraproject.org
Date: Fri Mar 7 01:56:44 2014 -0500
missing BR
perl-Email-MIME-Encodings.spec |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
---
diff --git a/perl-Email-MIME-Encodings.spec b/perl-Email-MIME-Encodings.spec
index 9f14f29..9cc0360 100644
--- a/perl-Email-MIME-Encodings.spec
+++ b/perl-Email-MIME-Encodings.spec
@@ -14,6 +14,7 @@ BuildRequires: perl(MIME::Base64) = 3.05
BuildRequires: perl(MIME::QuotedPrint) = 3.03
BuildRequires: perl(Test::Pod)
BuildRequires: perl(Test::Pod::Coverage)
+BuildRequires: perl(Capture::Tiny)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
%description
--
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-Email-MIME-Encodings/epel7] 1.315
commit a6f1b7987724d48d8b2beb0019a261cc90dc185d
Author: Tom Callaway s...@fedoraproject.org
Date: Fri Mar 7 02:02:38 2014 -0500
1.315
perl-Email-MIME-Encodings.spec | 25 -
sources|2 +-
2 files changed, 21 insertions(+), 6 deletions(-)
---
diff --git a/perl-Email-MIME-Encodings.spec b/perl-Email-MIME-Encodings.spec
index 362c0df..9cc0360 100644
--- a/perl-Email-MIME-Encodings.spec
+++ b/perl-Email-MIME-Encodings.spec
@@ -1,6 +1,6 @@
Name: perl-Email-MIME-Encodings
-Version:1.313
-Release:13%{?dist}
+Version:1.315
+Release:1%{?dist}
Summary:Unified interface to MIME encoding and decoding
Group: Development/Libraries
@@ -14,6 +14,7 @@ BuildRequires: perl(MIME::Base64) = 3.05
BuildRequires: perl(MIME::QuotedPrint) = 3.03
BuildRequires: perl(Test::Pod)
BuildRequires: perl(Test::Pod::Coverage)
+BuildRequires: perl(Capture::Tiny)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
%description
@@ -34,7 +35,6 @@ make %{?_smp_mflags}
%install
make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT
find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} ';'
-find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2/dev/null ';'
chmod -R u+w $RPM_BUILD_ROOT/*
@@ -43,13 +43,28 @@ make test
%files
-%defattr(-,root,root,-)
-%doc Changes README
+%doc Changes LICENSE README
%{perl_vendorlib}/Email/
%{_mandir}/man3/*.3pm*
%changelog
+* Fri Mar 7 2014 Tom Callaway s...@fedoraproject.org - 1.315-1
+- update to 1.315
+
+* Fri Aug 9 2013 Paul Howarth p...@city-fan.org - 1.314-1
+- Update to 1.314
+ - Add a third argument to encode/decode/codec to allow a fallback codec
+- Package upstream's LICENSE file
+- Drop %%defattr, redundant since rpm 4.4
+- Don't need to remove empty directories from the buildroot
+
+* Sat Aug 03 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 1.313-15
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild
+
+* Sat Jul 20 2013 Petr Pisar ppi...@redhat.com - 1.313-14
+- Perl 5.18 rebuild
+
* Sun Feb 24 2013 Ralf Corsépius corse...@fedoraproject.org - 1.313-13
- Add BR: perl(ExtUtils::MakeMaker) (Fix FTBFS #914272).
- Modernize spec.
diff --git a/sources b/sources
index 084d454..3afe08c 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-f2580c816fb0c4b2a256540a385bf4fb Email-MIME-Encodings-1.313.tar.gz
+0fbe906d7918430750b1ba766cf95151 Email-MIME-Encodings-1.315.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-Language-Prolog-Yaswi] Rebuild against pl-6.6.2
commit 10162be06f3cf528c13b537ef659f68da6832cc7
Author: Petr Písař ppi...@redhat.com
Date: Fri Mar 7 08:25:29 2014 +0100
Rebuild against pl-6.6.2
perl-Language-Prolog-Yaswi.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Language-Prolog-Yaswi.spec b/perl-Language-Prolog-Yaswi.spec
index 45b4c45..a3debf4 100644
--- a/perl-Language-Prolog-Yaswi.spec
+++ b/perl-Language-Prolog-Yaswi.spec
@@ -1,6 +1,6 @@
Name: perl-Language-Prolog-Yaswi
Version:0.21
-Release:16%{?dist}
+Release:17%{?dist}
Summary:Yet another interface to SWI-Prolog
License:GPL+ or Artistic
Group: Development/Libraries
@@ -65,6 +65,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Fri Mar 07 2014 Petr Pisar ppi...@redhat.com - 0.21-17
+- Rebuild against pl-6.6.2
+
* Thu Jan 02 2014 Petr Pisar ppi...@redhat.com - 0.21-16
- Rebuild against pl-6.6.1
--
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-HTML-Mason/f20] Upstream update.
Summary of changes: 60eb7fe... Upstream update. (*) (*) 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
Re: D19 Comments and Diff
I also want to avoid increasing the maintenance burden of having a
bunch of tests that look for things which don't really need to be
tested (setting data members, checking default values etc.)
I agree, there is stuff that kind of can be taken for granted.
Coincidentally, I have an anecdote to tell... of this morning.
I have went ahead and implemented Tim's suggestion here:
https://phab.qadevel.cloud.fedoraproject.org/D19?id=49#inline-127
A damn simple change, just replace (slightly modified for readability):
self._result = None
with
self._result = 'NEEDS_INSPECTION'
in the constructor and a trivial adjustment in the result getter.
However, my 'trivial' tests actually saved me:
=== FAILURES ===
___ TestCheckDetail.test_init_raise
self = testing.test_check.TestCheckDetail instance at 0x2fc1d88
def test_init_raise(self):
'''Test instance creation that raises an error - invalid parameters'''
with pytest.raises(exc.TaskotronValueError):
check.CheckDetail(result='INVALID TYPE')
E Failed: DID NOT RAISE
testing/test_check.py:38: Failed
__ TestCheckDetail.test_update_result __
self = testing.test_check.TestCheckDetail instance at 0x343f638
def test_update_result(self):
'''Test 'update_result' method'''
# basic use case
self.cd.update_result('FAILED')
assert self.cd.result == 'FAILED'
E assert 'NEEDS_INSPECTION' == 'FAILED'
E - NEEDS_INSPECTION
E + FAILED
testing/test_check.py:66: AssertionError
2 failed, 50 passed, 1 skipped in 0.32 seconds
So, even those simple tests have some value, sometimes.
Of course, there's no point in testing whether simple class.attr = value
statement really works. But if attr is a property (having setter/getter), now
it starts to make sense. And also if the documentation says it should have some
default value (other than None), it's useful to test it. I don't think it's
strictly required, but I definitely wouldn't call it unnecessary.
___
qa-devel mailing list
qa-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/qa-devel
Re: D19 Comments and Diff
That being said, I don't really want to start off with tests that are putting too many asserts into the one test. Some combinations are fine but I'd prefer erring on the side of separating things out a bit too much for now rather than risk setting an example of large, monolithic tests. I agree, and it's especially important for more complex code. But in this case, I think I've hit the sweet spot. The tests are really simple, and therefore they can be clustered together (in a reasonable extent) for improved readability and reduced test code length. By the way, I've pushed some more revisions of the patch. It contains 64 lines of code + 144 lines of documentation and whitespace, and 208 lines of code of tests. Pylint score is 100% and test coverage is 100%. I think it's my best code ever, by all metrics ;) Let's not be too nitpicky here. ___ qa-devel mailing list qa-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/qa-devel
Re: Default invocation of pytest for qadevel projects
On Thu, 6 Mar 2014 05:44:15 -0500 (EST) Kamil Paral kpa...@redhat.com wrote: For the qadevel projects I'm aware of, we've been using pytest for our unit/functional test runner. As part of the shared configuration, tests are split up into two categories, unit and functional. Unit tests are fast, do not touch the network, database or filesystem (there are some exceptions to that last part, though). Functional tests tend to be more integration tests that can set up a database or do other actions which fall outside of the previous definition of unit test. When you run pytest without any extra args, only the unit tests are run. The '--functional' arg is needed to enable collection and execution of the functional tests. Kamil recently made a request [1] to do one of two things: [1] https://phab.qadevel.cloud.fedoraproject.org/T89 1. Change the default such that functional tests are collected and exclude them from collection using a '--unit' arg 2. Change the functional arg from '--functional' to something shorter, like '--func' * note that there are restrictions on which args we can use. For example, '-f' is not allowed as single letter args are reserved for pytest itself As stated in T89, I don't have a strong opinion on this as long as it's possible to exclude the functional tests from collection and we make the same change across all of our active projects. However, I wanted to put this up for a wider discussion before changing things. Any other thoughts on this proposed change? I should remember to read the mailing list before the Phab comments. I already closed the task as wontfix with my comment included: https://phab.qadevel.cloud.fedoraproject.org/T89#9 I agree that you have a point in running just the unit tests by default. For my workflow, sure. On the other hand, I'm not sure what other peoples' workflow looks like and if it reduces confusion, we may be better off changing the defaults to run functional tests. As I stated in the ticket, as long as I can turn off the functional tests with a command line arg, my workflow won't be affected. Other thoughts on which is a better default? Changing --functional to --func would be nice, though. It even matches the file prefix for func tests, 'functest_'. Sure, I'm game for changing that. The two args that come to mind are: * --long (more generic than functional) * --func (short for functional) Any thoughts on which of those (if either) would be better? Tim signature.asc Description: PGP signature ___ qa-devel mailing list qa-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/qa-devel
Re: Default invocation of pytest for qadevel projects
Any thoughts on which of those (if either) would be better? I do not really mind either, and do not have any strong preference. I'm used to having the non-functional tests run by default, but I can easily manage any way we decide to do it. j. ___ qa-devel mailing list qa-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/qa-devel
Re: Default invocation of pytest for qadevel projects
- Original Message - From: Tim Flink tfl...@redhat.com To: qa-devel@lists.fedoraproject.org Sent: Thursday, March 6, 2014 3:29:32 PM Subject: Re: Default invocation of pytest for qadevel projects On Thu, 6 Mar 2014 05:44:15 -0500 (EST) Kamil Paral kpa...@redhat.com wrote: For the qadevel projects I'm aware of, we've been using pytest for our unit/functional test runner. As part of the shared configuration, tests are split up into two categories, unit and functional. Unit tests are fast, do not touch the network, database or filesystem (there are some exceptions to that last part, though). Functional tests tend to be more integration tests that can set up a database or do other actions which fall outside of the previous definition of unit test. When you run pytest without any extra args, only the unit tests are run. The '--functional' arg is needed to enable collection and execution of the functional tests. Kamil recently made a request [1] to do one of two things: [1] https://phab.qadevel.cloud.fedoraproject.org/T89 1. Change the default such that functional tests are collected and exclude them from collection using a '--unit' arg 2. Change the functional arg from '--functional' to something shorter, like '--func' * note that there are restrictions on which args we can use. For example, '-f' is not allowed as single letter args are reserved for pytest itself As stated in T89, I don't have a strong opinion on this as long as it's possible to exclude the functional tests from collection and we make the same change across all of our active projects. However, I wanted to put this up for a wider discussion before changing things. Any other thoughts on this proposed change? I should remember to read the mailing list before the Phab comments. I already closed the task as wontfix with my comment included: https://phab.qadevel.cloud.fedoraproject.org/T89#9 I agree that you have a point in running just the unit tests by default. For my workflow, sure. On the other hand, I'm not sure what other peoples' workflow looks like and if it reduces confusion, we may be better off changing the defaults to run functional tests. As I stated in the ticket, as long as I can turn off the functional tests with a command line arg, my workflow won't be affected. Other thoughts on which is a better default? I don't have a strong feeling about either but I'd run all the tests by default if I had to choose (given that functional ones don't run forever, which is not the case at this point). Changing --functional to --func would be nice, though. It even matches the file prefix for func tests, 'functest_'. Sure, I'm game for changing that. The two args that come to mind are: * --long (more generic than functional) * --func (short for functional) Any thoughts on which of those (if either) would be better? --func sounds better to me. Martin ___ qa-devel mailing list qa-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/qa-devel
