Re: EPEL RHEL 7 Workstation optional channel in Fedora's Koji
On 2 June 2014 16:46, T.C. Hollingsworth tchollingswo...@gmail.com wrote: On Mon, Jun 2, 2014 at 1:59 AM, Simone Caronni negativ...@gmail.com wrote: Hello, I was looking to build a package on epel7 that is relying on jansson-devel. The -devel subpackage is generated as normally from the main jansson package, but in case of epel7 the resulting rpm is included in the Workstation-optional channel: http://ftp.redhat.com/redhat/rhel/rc/7/Workstation-optional/x86_64/os/Packages/ Have these packages being left out intentionally or not? Is there any chance to see these packages added in Koji? Otherwise building for epel7 can get really complicated. I'd suggest filing a bug in bugzilla first, explaining the pain this causes downstream addon repositories like EPEL. For all we know the -devel subpackage is only missing in Server due to some oversight. Opened this one, hope it's correct: https://fedorahosted.org/rel-eng/ticket/5915 Thanks regards, --Simone -- You cannot discover new oceans unless you have the courage to lose sight of the shore (R. W. Emerson). http://xkcd.com/229/ http://negativo17.org/ ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
EPEL epel beta report: 20140603 changes
Compose started at Tue Jun 3 08:15:02 UTC 2014 New package: hawkey-0.4.16-1.el7 Library providing simplified C and Python API to libsolv New package: ldapdiff-1.4.1-4.el7 Tool for incremental LDAP directory updates based on ldif files New package: libewf-20130416-1.el7 Library for the Expert Witness Compression Format (EWF) New package: libtelnet-0.21-5.el7 TELNET protocol parsing framework New package: rear-1.16.1-1.el7 Relax-and-Recover is a Linux disaster recovery and system migration tool Updated Packages: gsoap-2.8.16-3.el7 -- * Mon Jun 02 2014 Mattias Ellert mattias.ell...@fysast.uu.se - 2.8.16-3 - Fix for IPv4 only hosts libsolv-0.6.1-1.git6d968f1.el7 -- * Tue May 27 2014 Aleš Kozumplík a...@redhat.com - 0.6.1-1.git6d968f1 - Rebase to upstream 6d968f1 - Fix RhBug:1049209 * Fri Apr 25 2014 Jan Silhan jsil...@redhat.com - 0.6.1-0.gitf78f5de - Rebase to 0.6.0, upstream commit f78f5de. * Thu Apr 24 2014 Vít Ondruch vondr...@redhat.com - 0.6.0-0.git05baf54.1 - Rebuilt for https://fedoraproject.org/wiki/Changes/Ruby_2.1 * Wed Apr 09 2014 Jan Silhan jsil...@redhat.com - 0.6.0-0.git05baf54 - Rebase to 0.6.0, upstream commit 05baf54. * Mon Dec 16 2013 Aleš Kozumplík akozu...@redhat.com - 0.4.1-1.gitbcedc98 - Rebase upstream bcedc98 - Fix RhBug:1051917. * Mon Dec 16 2013 Aleš Kozumplík akozu...@redhat.com - 0.4.1-0.gita8e47f1 - Rebase to 0.4.1, upstream commit a8e47f1. * Fri Nov 22 2013 Zdenek Pavlas zpav...@redhat.com - 0.4.0-2.git4442b7f - Rebase to 0.4.0, upstream commit 4442b7f. - support DELTA_LOCATION_BASE for completeness php-horde-content-2.0.4-1.el7 - * Tue Jun 03 2014 Remi Collet r...@fedoraproject.org - 2.0.4-1 - Update to 2.0.4 - run test suite during build python-django-evolution-0.7.2-1.el7 --- * Mon Jun 02 2014 Stephen Gallagher sgall...@redhat.com 0.7.2-1 - New upstream release 0.7.2 - http://downloads.reviewboard.org/releases/django-evolution/0.7/django_evolution-0.7.2.NEWS - Fixed a crash from no-op column renames on PostgreSQL python-qpid-0.26-1.el7 -- * Fri May 30 2014 Darryl L. Pierce dpie...@redhat.com - 0.26-1 - Rebased on Qpid 0.26. python-qpid_messaging-0.26-2.el7 * Mon Jun 02 2014 Darryl L. Pierce dpie...@redhat.com - 0.26-2 - Updated dependencies to use virtual qpid packages. - Resolves: BZ#1103572 qpid-qmf-0.24-21.el7 * Mon Jun 02 2014 Darryl L. Pierce dpie...@redhat.com - 0.24-21 - Missed the arch reference on one requires. * Mon Jun 02 2014 Darryl L. Pierce dpie...@redhat.com - 0.24-20 - Added arch reference to qpid client requirement. - Resolves: BZ#1103373 * Fri May 23 2014 David Tardon dtar...@redhat.com - 0.24-19 - rebuild for boost 1.55.0 * Thu May 22 2014 Darryl L. Pierce dpie...@redhat.com - 0.24-18 - Changed dependencies on qpid-cpp-client to be qpid(client). socket_wrapper-1.1.0-1.el7 -- * Mon Jun 02 2014 - Andreas Schneider a...@redhat.com - 1.1.0-1 - Update to version 1.1.0. Summary: Added Packages: 5 Removed Packages: 0 Modified Packages: 8 ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: EPEL RHEL 7 Workstation optional channel in Fedora's Koji
On Tue, Jun 3, 2014 at 1:29 AM, Simone Caronni negativ...@gmail.com wrote: On 2 June 2014 16:46, T.C. Hollingsworth tchollingswo...@gmail.com wrote: I'd suggest filing a bug in bugzilla first, explaining the pain this causes downstream addon repositories like EPEL. For all we know the -devel subpackage is only missing in Server due to some oversight. Opened this one, hope it's correct: https://fedorahosted.org/rel-eng/ticket/5915 Well actually I meant to ask RHEL release engineering to add jansson-devel to the Server repository along with the main jansson package. It seems kind of silly to have the main package in Server and the -devel package in Workstation. You can file a bug with RHEL rel-eng here: https://bugzilla.redhat.com/enter_bug.cgi?product=Red%20Hat%20Enterprise%20Linux%207component=relengversion=7.0 Of course, supporting Workstation in general would be very nice, so your other ticket is warranted, but I think getting this particular problem fixed on the RHEL side would still be a good idea regardless of the outcome of that. -T.C. ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: EPEL RHEL 7 Workstation optional channel in Fedora's Koji
On 3 June 2014 11:29, T.C. Hollingsworth tchollingswo...@gmail.com wrote: You can file a bug with RHEL rel-eng here: https://bugzilla.redhat.com/enter_bug.cgi?product=Red%20Hat%20Enterprise%20Linux%207component=relengversion=7.0 Of course, supporting Workstation in general would be very nice, so your other ticket is warranted, but I think getting this particular problem fixed on the RHEL side would still be a good idea regardless of the outcome of that. Bug filed with an edited text from the releng one. Regards, --Simone -- You cannot discover new oceans unless you have the courage to lose sight of the shore (R. W. Emerson). http://xkcd.com/229/ http://negativo17.org/ ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
EPEL Fedora 6 updates-testing report
The following Fedora EPEL 6 Security updates need testing: Age URL 773 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2012-5620/bugzilla-3.4.14-2.el6 120 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0440/fwsnort-1.6.4-1.el6 104 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0590/oath-toolkit-2.0.2-4.el6 64 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-1011/php-ZendFramework-1.12.5-1.el6 18 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-1414/gajim-0.14.4-4.el6 13 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-1471/chicken-4.8.0.6-2.el6 10 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-1477/drupal7-views-3.8-1.el6 10 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-1475/moodle-2.4.10-1.el6 6 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-1522/check-mk-1.2.4p2-2.el6 4 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-1536/xmlsec1-1.2.19-3.el6 0 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-1563/mono-2.10.8-2.el6,libgdiplus-2.10-1.el6 The following builds have been pushed to Fedora EPEL 6 updates-testing libgdiplus-2.10-1.el6 libmediainfo-0.7.69-1.el6 mediainfo-0.7.69-1.el6 mono-2.10.8-2.el6 php-horde-content-2.0.4-1.el6 python-django-evolution-0.7.2-1.el6 ratools-0.5.2-3.el6 xpdf-3.04-2.el6 Details about builds: libgdiplus-2.10-1.el6 (FEDORA-EPEL-2014-1563) An implementation of the GDI+ API Update Information: - update ChangeLog: * Mon Jun 2 2014 Leigh Scott leigh123li...@googlemail.com - 2.10-1 - 2.10 release libmediainfo-0.7.69-1.el6 (FEDORA-EPEL-2014-1567) Library for supplies technical and tag information about a video or audio file Update Information: Update to 0.7.69 ChangeLog: * Tue Jun 3 2014 Vasiliy N. Glazov vasc...@gmail.com 0.7.69-1 - Update to 0.7.69 * Fri May 23 2014 Vasiliy N. Glazov vasc...@gmail.com 0.7.68-2 - Update for tinyxml2 changes mediainfo-0.7.69-1.el6 (FEDORA-EPEL-2014-1565) Supplies technical and tag information about a video or audio file (CLI) Update Information: Update to 0.7.69 ChangeLog: * Tue Jun 3 2014 Vasiliy N. Glazov vasc...@gmail.com 0.7.69-1 - Update to 0.7.69 mono-2.10.8-2.el6 (FEDORA-EPEL-2014-1563) A .NET runtime environment Update Information: - update ChangeLog: * Mon Jun 2 2014 Leigh Scott leigh123li...@googlemail.com - 2.10.8-2 - rebuild against mono-core * Mon Jun 2 2014 Leigh Scott leigh123li...@googlemail.com - 2.10.8-1 - Update to 2.10.8 - bootstrap build for epel php-horde-content-2.0.4-1.el6 (FEDORA-EPEL-2014-1568) Tagging application Update Information: * [jan] Fix date format for 'created' column. ChangeLog: * Tue Jun 3 2014 Remi Collet r...@fedoraproject.org - 2.0.4-1 - Update to 2.0.4 - run test suite during build python-django-evolution-0.7.2-1.el6 (FEDORA-EPEL-2014-1561) Schema evolution for Django Update Information: Fixed a crash from no-op column renames on PostgreSQL Fixed a crash from no-op column renames on MySQL Note to Review Board users: this will fix an issue when upgrading from 1.5.x to 2.0.
Re: EPEL Maintaining libntlm for ppc64
NO. Feel free to do that. ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: Current FTBFS packages (was Re: [ACTION REQUIRED] Retiring packages for Fedora 21)
On Mon, Jun 02, 2014 at 09:42:02PM -0400, Rahul Sundaram wrote: Hi On Mon, Jun 2, 2014 at 5:57 PM, Till Maas wrote: gdome2 sundaram I have retired this already. What more should I do? You need to retire it in pkgdb. Btw. the retiring reason could be improved in the dead.package file. Regards Till -- 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: Current FTBFS packages (was Re: [ACTION REQUIRED] Retiring packages for Fedora 21)
On Mon, 2 Jun 2014 23:54:10 +0200 Till Maas opensou...@till.name wrote: On Mon, Jun 02, 2014 at 04:36:28PM -0400, Al Dunsmuir wrote: Please do not start deleting ppc32-only packages. A few of us would like to resurrect ppc32, likely initially as a Fedora Remix. Deleting ppc32-only packages just adds more work to that effort. ok, but I guess there is no package left that is not properly configured in primary koji. If you continue with this effort, please re-open the rel-eng ticket in my other e-mail regarding yaboot. In the past it wasn't possible to block secondary arch only package in primary koji after it was introduced there, because during some releng action (branching, mass rebuild?) it affected also the secondary koji. Or pkgdb, maybe both. The result was that secondary arch only package was not accessible for commits and blocked in secondary koji and we had to resolve it manually with dgilmore. So please be careful. I think the problem was that pkgdb had no information about arches, it worked globally. Dan -- 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: Fwd: Ophaning lcms(1)
Hi, On 06/02/2014 10:39 PM, Nicolas Chauvet wrote: Hello, I'm orphaning lcms, this package has seen few security issue and upstream claim it's deprecated over lcms2 rhel 7 doesn't depends on it for the few package, so it might be an option not to build lcms support for certain package # repoquery --whatrequires liblcms.so.1 --source DevIL-1.7.8-16.fc20.src.rpm I've just kicked of a build of DevIL which drops the use of lcms, so DevIL can be taken of the list. Regards, Hans -- 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: Fwd: Ophaning lcms(1)
On Mon, Jun 02, 2014 at 10:39:56PM +0200, Nicolas Chauvet wrote: Hello, I'm orphaning lcms, this package has seen few security issue and upstream claim it's deprecated over lcms2 # repoquery --whatrequires liblcms.so.1 --source entangle-0.5.3-2.fc20.src.rpm FYI the repo you're pointing to is outdated - current Fedora 20 updates is on version 0.6.0, which uses lcms2 instead. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- 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: Fwd: Ophaning lcms(1)
On 02.06.2014 23:07, Toshio Kuratomi wrote: On Mon, Jun 02, 2014 at 10:39:56PM +0200, Nicolas Chauvet wrote: python-pillow-2.2.1-4.fc20.src.rpm This one can be fixed by upgrading to 2.3.0 (or greater. 2.4.0 is current). 2.4.0 is what's in rawhide. Not sure if that's safe to push back to f20 and earlier. (Although I see that there's an insecure use of tempfile CVE that was ficed in 2.3.1 so maybe it makes sense to update even if there is API breakage.) @smani: Do you have more information here? -Toshio The API has never been broken as far as I can tell. I guess we could update to 2.4.0 (although given the number of packages which depend on pillow I wasn't planning to do so in a stable release), or otherwise we could backport [1]. But, more generally, why introduce such a change in a stable release? Can't lcms just be removed for F21+? Sandro [1] https://github.com/python-pillow/Pillow/pull/380 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Env and Stack WG meeting (2014-06-03)
No agenda, meeting cancelled. Marcela -- 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: Build lua libraries also for compat-lua?
On 05/29/2014 06:31 PM, Tomasz Torcz wrote: On Tue, May 13, 2014 at 11:17:39AM +0200, Jan Kaluža wrote: Hi, I'm playing with an idea of building lua libraries against compat-lua to allow luajit working with them. My initial motivation for this is that there are projects which don't work with Lua-5.2 and developers for various reasons don't want to port it to lua-5.2 yet (for example Prosody package). I'm OK with creating bugs and patches against some basic lua modules (basically the ones I need myself for Prosody :) ), but at first I wanted to ask Lua people here what do they think about it? Hi, Was there any progress with this? I'd love to see working Prosody package in F20. I have persuaded one proven packager to do this change in Fedora Rawhide and it looks there is no problem with it and Prosody is working in Rawhide now. I think I will ask him to backport this into F20, so I can rebuild Prosody in F20 too. Regards, Jan Kaluza -- 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: Fwd: Ophaning lcms(1)
On Mon, Jun 2, 2014 at 5:23 PM, Till Maas opensou...@till.name wrote: On Mon, Jun 02, 2014 at 10:39:56PM +0200, Nicolas Chauvet wrote: # repoquery --whatrequires liblcms.so.1 --source cinepaint-1.4-5.fc20.src.rpm cmyktool-0.1.6-0.6.pre1.fc20.src.rpm DevIL-1.7.8-16.fc20.src.rpm entangle-0.5.3-2.fc20.src.rpm f-spot-0.8.2-11.fc20.src.rpm geeqie-1.1-13.fc20.src.rpm gimp-separate+-0.5.8-10.fc20.src.rpm hylafax+-5.5.4-1.fc20.src.rpm libmng-1.0.10-12.fc20.src.rpm mate-image-viewer-1.6.2-2.fc20.src.rpm oyranos-0.4.0-12.fc20.src.rpm photoprint-0.4.2-0.12.pre2.fc20.src.rpm python-pillow-2.2.1-4.fc20.src.rpm rawstudio-2.0-12.fc20.src.rpm rawstudio-2.0-12.fc20.src.rpm sK1-0.9.1-0.8.pre_rev730.fc20.src.rpm Ther inkscape (maintained by: limb, duffy, lkundrak) inkscape-0.48.4-16.fc21.src requires lcms-devel = 1.19-11.fc21 rawstudio (maintained by: giallu) Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct libmng uses lcms2 in rawhide, and I just updated inkscape to do the same. -- http://cecinestpasunefromage.wordpress.com/ in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Test-Announce] June 2014 Rawhide validation matrices are up!
Hey folks! Just a note that I've put up the validation matrices for June 2014 (thanks pwhalen and satellit for the reminders): https://fedoraproject.org/wiki/Test_Results:Fedora_21_Rawhide_2014_06_Install https://fedoraproject.org/wiki/Test_Results:Fedora_21_Rawhide_2014_06_Base please enter results from Rawhide testing during May in these pages, not the 2014_05 ones. Those are archived for posterity now. :) In case anyone needs a refresher on this testing - https://lists.fedoraproject.org/pipermail/test/2014-April/120792.html , https://lists.fedoraproject.org/pipermail/test/2014-April/120931.html . I've transferred the 201406 results folks had put in the 201405 pages across. of course, anyone can create these pages, not just me! Here's a pseudo-SOP. There's no template - go into the edit history of the current month's page and find the 'clean' version of the page - the last edit before any actual results are added. Copy and paste that as the basis of the new page. Change all occurrences of the month's name and search/replace occurrences of '2014xx' (e.g. I replaced '201405' with '201406' this time). That should do it. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-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
retrace server broken?
-- Running report_uReport ---
Server responded with an error: 'Validation failed: Element 'frames' is missing'
reporter-ureport failed with exit code 1
('report_uReport' exited with 1)
--- Running report_EmergencyAnalysis ---
Compressing data
Sending /var/tmp/oops-2014-06-03-13:41:11-7574-0.tar.gz to
https://retrace.fedoraproject.org/faf/dumpdirs/new/
Successfully sent /var/tmp/oops-2014-06-03-13:41:11-7574-0.tar.gz to
https://retrace.fedoraproject.org/faf/dumpdirs/new/
!DOCTYPE HTML PUBLIC -//IETF//DTD HTML 2.0//EN
htmlhead
title500 Internal Server Error/title
/headbody
h1Internal Server Error/h1
pThe server encountered an internal error or
misconfiguration and was unable to complete
your request./p
pPlease contact the server administrator,
webmas...@fedoraproject.org and inform them of the time the error occurred,
and anything you might have done that may have
caused the error./p
pMore information about this error may be available
in the server error log./p
hr
addressApache/2.2.15 (Red Hat) Server at retrace.fedoraproject.org Port
443/address
/body/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: retrace server broken?
On Tue, Jun 3, 2014 at 12:42 PM, Neal Becker ndbeck...@gmail.com wrote:
-- Running report_uReport ---
Server responded with an error: 'Validation failed: Element 'frames' is
missing'
reporter-ureport failed with exit code 1
('report_uReport' exited with 1)
I'm seeing the same, and have been for several days. Seems it's been
reported at https://github.com/abrt/abrt/issues/817
-Jared
--
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: Docker Container Image
On Fri, 2014-04-11 at 14:19 +0200, Jaroslav Reznik wrote: = Proposed Self Contained Change: Docker Container Image = https://fedoraproject.org/wiki/Changes/Docker_Container_Image Change owner(s): Lokesh Mandvekar l...@fedoraproject.org, Dennis Gilmore den...@ausil.us This is Fedora running inside Docker. Currently, there are non-official images in the docker index, but we'd like them to really come out of release engineering. == Detailed Description == The public docker registry [1] hosts many fedora images [2] including an unprefixed (semi-official) image [3]. However, this image doesn't have rel-eng approval which would be required for a fully official image. == Scope == * Proposal owners: The proposal owner needs to build the image tarballs with the official kickstart scripts and make them available to docker's stackbrew repo, which is used by the Docker maintainers to build unprefixed images. Release Engineering approval/intervention would be needed at some point (details still TBD) * Other developers: N/A (not a System Wide Change) * Release engineering: Official Release Engineering image approval. Process still TBD. * Policies and guidelines: N/A (not a System Wide Change) NECRO ALERT So, this adds yet another to our rather teetering pile of deliverables to consider the relative importance / status of, and for releng to generate zillions of times per cycle. What Fedora exactly is the image going to contain? Fedora Server? Fedora Cloud? Will it be a part of either of those products? If not, what is its status, exactly? Who's responsible for it? Is it considered a primary or frontline or whatever Fedora deliverable? Who's going to test it? How's it going to be promoted in relation to all our other deliverables? (I'm late on this, and I see the Change has been approved already, but I'm not sure if any of the above questions were answered). -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Current FTBFS packages (was Re: [ACTION REQUIRED] Retiring packages for Fedora 21)
On 06/01/2014 05:24 AM, Till Maas wrote: R-bigmemory spot, spot RETIRED log4net spot, cicku, spot Fixed and built in rawhide: log4net-1.2.13-1.fc21 netgospot, spot RETIRED rpc2 spot, nhorman, spot Fixed and built in rawhide: rpc2-2.10-9.fc21 tkimgspot, spot Fixed and built in rawhide (I hate this package so much, it is the definition of crufty): tkimg-1.4-16.fc21 xsupplicant spot, spot Fixed and built in rawhide: xsupplicant-2.2.0-8.fc21 ~tom == ¸.·´¯`·.´¯`·.¸¸.·´¯`·.¸(((º OSAS @ Red Hat University Outreach || Fedora Special Projects || Fedora Legal attachment: tcallawa.vcf-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Workstation: Enable Software Collections
On Sun, 2014-04-20 at 18:56 +0200, Kevin Kofler wrote: Jaroslav Reznik wrote, on behalf of Matthias Clasen: The Software Collections repositories will be enabled by default. So we now allow shipping the configuration for third-party repositories, even enabled by default? Is April 1st still not over yet? If you want those packages in Fedora, they need to get into the Fedora repository. THREAD NECRO ALERT I wouldn't put it as strongly as Kevin, but I do have some concerns about the implications here. Notably, https://www.softwarecollections.org/en/docs/licensing/ states: We do not review source or packages for suitability of purpose, quality, or licensing Fedora provides rather stronger guarantees on that front in our 'official' repositories. It seems like SCL has more or less the same policies and intents as Fedora, but is explicitly less proactive about 'policing' them. It therefore seems like this feature increases the risk to Fedora as a whole of 'blessing' badly broken or incorrectly licensed software. It would be nice to emphasize the distinction between software from the Fedora repositories and software from the SCL project, at least. yum and dnf do this to at least a limited extent already (you can see what repo a package is coming from, when you install it), but have we considered whether that's sufficient, and if it would be worthwhile to try and improve on it? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Current FTBFS packages (was Re: [ACTION REQUIRED] Retiring packages for Fedora 21)
On Tuesday, June 3, 2014, 2:37:49 AM, Dan Horák wrote: On Mon, 2 Jun 2014 23:54:10 +0200 Till Maas opensou...@till.name wrote: On Mon, Jun 02, 2014 at 04:36:28PM -0400, Al Dunsmuir wrote: Please do not start deleting ppc32-only packages. A few of us would like to resurrect ppc32, likely initially as a Fedora Remix. Deleting ppc32-only packages just adds more work to that effort. ok, but I guess there is no package left that is not properly configured in primary koji. If you continue with this effort, please re-open the rel-eng ticket in my other e-mail regarding yaboot. In the past it wasn't possible to block secondary arch only package in primary koji after it was introduced there, because during some releng action (branching, mass rebuild?) it affected also the secondary koji. Or pkgdb, maybe both. The result was that secondary arch only package was not accessible for commits and blocked in secondary koji and we had to resolve it manually with dgilmore. So please be careful. I think the problem was that pkgdb had no information about arches, it worked globally. Thanks for the heads-up! -- 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: Fwd: Ophaning lcms(1)
https://apps.fedoraproject.org/packages/lcms/bugs/all lists a CVE. If lcms-11 is no longer going to be maintained in Fedora that (and any other) security flaws won't be addressed. It's therefore advisable for them to update to the new version of lcms if feasible. The affected packager would likely want to take ownership of lcms-1 and patch the security issues. -Toshio -- 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: Docker Container Image
On Tue, Jun 03, 2014 at 12:35:00PM -0700, Adam Williamson wrote: What Fedora exactly is the image going to contain? Fedora Server? Fedora Cloud? Will it be a part of either of those products? If not, what is its status, exactly? Who's responsible for it? Is it considered a primary or frontline or whatever Fedora deliverable? Who's going to test it? How's it going to be promoted in relation to all our other deliverables? Those are some excellent questions. Tentative answers: - It will contain its own spin of Fedora. - The Fedora Cloud WG will be responsible initially, but long-term it might be better in Env Stacks. - Primary or frontline or whatever -- um, we need to get back to you on that. - Cloud WG will test it; see above. - The intention is to (I'm late on this, and I see the Change has been approved already, but I'm not sure if any of the above questions were answered). Yeah, I don't think definitively. I made a ticket https://fedorahosted.org/cloud/ticket/65 and we'll talk about it Thursday. -- Matthew Miller-- Fedora Project--mat...@fedoraproject.org Tepid change for the somewhat better! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fwd: Ophaning lcms(1)
On 03.06.2014 23:20, Toshio Kuratomi wrote: https://apps.fedoraproject.org/packages/lcms/bugs/all lists a CVE. If lcms-11 is no longer going to be maintained in Fedora that (and any other) security flaws won't be addressed. It's therefore advisable for them to update to the new version of lcms if feasible. The affected packager would likely want to take ownership of lcms-1 and patch the security issues. -Toshio If it is a matter of patching security issues for the remaining lifetime of F19 and F20, I don't mind doing so if no-one of the current maintainers will. Sandro -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Five Things in Fedora This Week (2014-06-03)
Reposted from http://fedoramagazine.org/five-things-in-fedora-this-week-2014-06-03/ Fedora is a big project, and it’s hard to follow it all. This series highlights interesting happenings in five different areas every week. It isn’t comprehensive news coverage — just quick summaries with links to each. Here are the five things for June 3rd, 2014: New Fedora Project Leader - So, there is a new Fedora Project Leader, and, despite inital rumors, it’s not an anthropomorphic hotdog. I'm excited to be able to say: it's me. I wrote a blog post about it: First Thoughts as Fedora Project Leader. Right now, the practical consequence is that this is going to be a more terse 5tFTW than usual. (I’m sure there will be more consequences later.) And, of course, thanks again to outgoing FPL Robyn Bergeron! Don't miss her parting thoughts blog post. * http://fedoramagazine.org/is-this-the-new-fedora-project-leader/ * http://fedoramagazine.org/first-thoughts-as-fedora-project-leader/ * http://robyn.io/2014/06/03/new-fpl/ Bodhi2 and Taskotron Activity Day - Bodhi is Fedora’s system for pushing out security and bugfix updates. Taskotron is our new system for QA automation. The former is getting a much-needed update and integration with the latter at the Bodhi2 and Taskotron Fedora Activity Days going on right now in Denver, Colorado. Fedora Infrastructure Lead Kevin Fenzi has reports from day 1 and day 2. * http://bodhi.fedoraproject.org * https://fedoraproject.org/wiki/Taskotron * http://fedoraproject.org/wiki/FAD_Bodhi2_Taskotron_2014 * http://www.scrye.com/wordpress/nirik/2014/06/01/bodhi2-taskotron-fad-day-1/ * http://www.scrye.com/wordpress/nirik/2014/06/03/bodhi2-taskotron-fad-day-2/ Fedora Server / CentOS SLS -- As part of the new community-based direction, the CentOS project has several new Special Interest Groups around Storage, Virtualization, and so on. There is a proposal to create a Simplified Linux Server (SLS) SIG. This has the mission to deliver [...] turnkey CentOS-based solutions that are managed via a web and/or REST-based interface. The focus is on taking the various application silos and providing a cohesive solution to simplify deployment and maintenance. This has a lot of overlap with the upcoming Fedora Server, and the groups working on each had a joint meeting to discuss common goals and sharing effort. It looks like this will be a productive collaboration for users and developers of both distros. * http://wiki.centos.org/SpecialInterestGroup * http://wiki.centos.org/SpecialInterestGroup/SLS]%20(not%20to%20be%20confused,%20of%20course,%20with%201992's%20Softlanding%20Linux%20System](http://en.wikipedia.org/wiki/Softlanding_Linux_System * http://fedoraproject.org/wiki/Server * https://lists.fedoraproject.org/pipermail/server/2014-May/001135.html Fedora Regional Community Index --- This one isn’t new, but it’s one of those things that’s been around for a while which many people may not be aware of: the Region-Specific Fedora Websites index, at http://fedoracommunity.org/. This site lists different domains and subdomains with local resources all around the world. Check it out to find groups in your area which you might not have been aware of, or just to see what Fedora looks like around the globe. * http://fedoracommunity.org/ FUDCon Beijing 2014 Reports --- FUDCon APAC (Asia-Pacific) was held last month in Beijing, China. Reports are in from Aditya Patawari, Ankur Sinha, Somvannda Kong, Nitesh Narayan Lal, Jiří Eischmann, and Robert Mayr. * http://devel.adityapatawari.com/2014/05/fudcon-beijing-day-1/ * http://ankursinha.in/blog/2014/05/29/fudcon-beijing-day-1-and-day-0/ * http://fedoracambodia.wordpress.com/2014/05/31/my-first-trip-of-fedora-project-to-fudcon-beijing-china/ * http://niteshnarayanlal.blogspot.com/2014/05/fudcon-beijing-2014-kick-off.html * http://eischmann.wordpress.com/2014/06/02/fudcon-apac-2014-in-beijing/ * http://morefedora.blogspot.com/2014/06/fudcon-apac-beijing-day-0-robert-mayr.html -- Matthew Miller mat...@fedoraproject.org Fedora Project Leader -- 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 1103668] perl-DBD-Pg-3.3.0 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1103668 Jitka Plesnikova jples...@redhat.com changed: What|Removed |Added Status|NEW |CLOSED Fixed In Version||perl-DBD-Pg-3.3.0-1.fc21 Resolution|--- |RAWHIDE Last Closed||2014-06-03 04:44:34 -- 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=UGHkvs0wjWa=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 1104075] New: perl-Crypt-CipherSaber-1.00-13.fc21 FTBFS: Failed test 'autogenerating and autoreading IV should also round-trip'
https://bugzilla.redhat.com/show_bug.cgi?id=1104075 Bug ID: 1104075 Summary: perl-Crypt-CipherSaber-1.00-13.fc21 FTBFS: Failed test 'autogenerating and autoreading IV should also round-trip' Product: Fedora Version: rawhide Component: perl-Crypt-CipherSaber Assignee: xav...@bachelot.org Reporter: ppi...@redhat.com QA Contact: extras...@fedoraproject.org CC: perl-devel@lists.fedoraproject.org, xav...@bachelot.org External Bug ID: CPAN 28370 perl-Crypt-CipherSaber-1.00-13.fc21 sometimes fails to build in F21 due to tests: # Failed test 'autogenerating and autoreading IV should also round-trip' # at t/fh_encrypt.t line 115. # Looks like you failed 1 test of 6. t/fh_encrypt.t Dubious, test returned 1 (wstat 256, 0x100) Failed This happens only sometimes. -- 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=MZA703Krpra=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 1104134] New: perl-Test-Unit-0.25-17.fc21 FTBFS: t/assert.t test fails randomly
https://bugzilla.redhat.com/show_bug.cgi?id=1104134
Bug ID: 1104134
Summary: perl-Test-Unit-0.25-17.fc21 FTBFS: t/assert.t test
fails randomly
Product: Fedora
Version: rawhide
Component: perl-Test-Unit
Assignee: xav...@bachelot.org
Reporter: ppi...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org,
xav...@bachelot.org
External Bug ID: CPAN 87017
perl-Test-Unit-0.25-17.fc21 fails to build randomly due to test in F21:
[...]
not ok ERROR test_assert_deep_equals
t/tlib/AssertTest.pm:500 - test_assert_deep_equals(Class::Inner::__A20)
Expected Test::Unit::Failure `(?^mx:^Structures\ begin\ differing\ at: $ \n
\S*\s* \$a .* = .* (?-x:HASH) .* $ \n
\S*\s* \$b .* = .* (?-x:not exist))', got `Structures begin differing
at:
$a-{john}{spouse}{spouse}{name} = 'John Doe'
$b-{john}{spouse}{spouse}{name} = 'Baby Doll'
'
ok PASS test_assert_str_equals
ok PASS test_fail_assert_not_null
ok PASS test_succeed_assert_null
ok PASS test_assert_raises
ok PASS test_assert_equals
ok PASS test_ok_not_equals
ok PASS test_numericness
ok PASS test_success_assert_not_equals
ok PASS test_multi_assert
ok PASS test_ok_boolean
ok PASS test_fail_assert_not_equals
ok PASS test_assert_equals_null
ok PASS test_fail_assert_null
ok PASS test_assert
ok PASS test_ok_equals
ok PASS test_assert_matches
ok PASS test_succeed_assert_not_null
ok PASS test_ok_bad_args
ok PASS test_fail
Failed 1/40 subtests
Test Summary Report
---
t/assert.t (Wstat: 0 Tests: 40 Failed: 1)
Failed test: 21
--
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=dZ0bQoiJL0a=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 1104137] New: perl-YAML-0.92-1.fc21 FTBFS: t/release-pod-syntax.t fails if perl_bootstrap is enabled
https://bugzilla.redhat.com/show_bug.cgi?id=1104137 Bug ID: 1104137 Summary: perl-YAML-0.92-1.fc21 FTBFS: t/release-pod-syntax.t fails if perl_bootstrap is enabled Product: Fedora Version: rawhide Component: perl-YAML Assignee: st...@silug.org Reporter: ppi...@redhat.com QA Contact: extras...@fedoraproject.org CC: perl-devel@lists.fedoraproject.org, psab...@redhat.com, st...@silug.org perl-YAML-0.92-1.fc21 fails to boot-strap: t/regexp.t ... ok Can't locate Test/Pod.pm in @INC (you may need to install the Test::Pod module) (@INC contains: /home/test/fedora/perl-YAML/YAML-0.92/blib/lib /home/test/fedora/perl-YAML/YAML-0.92/blib/arch /usr/local/lib64/perl5 /usr/local/share/perl5 /usr/lib64/perl5/vendor_perl /usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5 .) at t/release-pod-syntax.t line 12. BEGIN failed--compilation aborted at t/release-pod-syntax.t line 12. t/release-pod-syntax.t ... Dubious, test returned 2 (wstat 512, 0x200) Obviously the dependency on Test::Pod is not optional when running release tests with make test RELEASE_TESTING=1. -- 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=UHZFshLRPga=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 1104137] perl-YAML-0.92-1.fc21 FTBFS: t/release-pod-syntax.t fails if perl_bootstrap is enabled
https://bugzilla.redhat.com/show_bug.cgi?id=1104137 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|st...@silug.org |ppi...@redhat.com -- 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=LvwO3FLE9va=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 1104137] perl-YAML-0.92-1.fc21 FTBFS: t/release-pod-syntax.t fails if perl_bootstrap is enabled
https://bugzilla.redhat.com/show_bug.cgi?id=1104137 Petr Pisar ppi...@redhat.com changed: What|Removed |Added URL||https://github.com/ingydotn ||et/yaml-pm/issues/24 -- 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=aMgNkg7BwLa=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 1104137] perl-YAML-0.92-1.fc21 FTBFS: t/release-pod-syntax.t fails if perl_bootstrap is enabled
https://bugzilla.redhat.com/show_bug.cgi?id=1104137 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-YAML-0.92-2.fc21 Resolution|--- |RAWHIDE Last Closed||2014-06-03 07:34:33 -- 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=dLWjUizdoqa=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 1103670] perl-File-pushd-1.007 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1103670 Petr Šabata psab...@redhat.com changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-File-pushd-1.007-1.fc2 ||1 Resolution|--- |RAWHIDE Last Closed||2014-06-03 08:21:32 -- 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=QURahoOc3ua=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 813532] RFE , please build EPEL6 perl-AppConfig
https://bugzilla.redhat.com/show_bug.cgi?id=813532 Steve Traylen steve.tray...@cern.ch changed: What|Removed |Added Status|NEW |CLOSED Resolution|--- |CANTFIX Last Closed||2014-06-03 08:40:57 --- Comment #1 from Steve Traylen steve.tray...@cern.ch --- perl-AppConfig seems to be in main RHEL now. -- 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=PRxUjdKYyxa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[389-devel] Please review: [389 Project] #47763: winsync plugin modify is broken
https://fedorahosted.org/389/ticket/47763 https://fedorahosted.org/389/attachment/ticket/47763/0001-Ticket-47763-winsync-plugin-modify-is-broken.patch Thanks to Carsten Grzemba for the patch. Made minimum changes such as replacing the direct access to the bv_len in Slapi_Value with slapi_value_get_length. -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: Coding Style
Outside any header requirements or directive documentation requirements,
are there any changes to PEP8 that folks want to make? If so, please
list the exceptions and why you think they should be adopted.
E251 =
libtaskotron/directives/bodhi_comment_directive.py:247:67: E251 unexpected
spaces around keyword / parameter equals
libtaskotron/directives/bodhi_comment_directive.py:247:69: E251 unexpected
spaces around keyword / parameter equals
libtaskotron/directives/bodhi_comment_directive.py:293:13: E251 unexpected
spaces around keyword / parameter equals
libtaskotron/directives/bodhi_comment_directive.py:293:15: E251 unexpected
spaces around keyword / parameter equals
libtaskotron/directives/bodhi_comment_directive.py:293:31: E251 unexpected
spaces around keyword / parameter equals
libtaskotron/directives/bodhi_comment_directive.py:293:33: E251 unexpected
spaces around keyword / parameter equals
libtaskotron/directives/bodhi_comment_directive.py:426:28: E251 unexpected
spaces around keyword / parameter equals
libtaskotron/directives/bodhi_comment_directive.py:426:30: E251 unexpected
spaces around keyword / parameter equals
libtaskotron/directives/bodhi_comment_directive.py:427:33: E251 unexpected
spaces around keyword / parameter equals
libtaskotron/directives/bodhi_comment_directive.py:427:35: E251 unexpected
spaces around keyword / parameter equals
libtaskotron/directives/bodhi_comment_directive.py:428:29: E251 unexpected
spaces around keyword / parameter equals
libtaskotron/directives/bodhi_comment_directive.py:428:31: E251 unexpected
spaces around keyword / parameter equals
def _is_comment_needed(old_result, comment_time, result, time_span = None):
-or-
outcome = _post_testresult(self.bodhi_api, detail.item,
env_data['checkname'],
detail.outcome,
url = http://example.com;,
doreport = input_data['doreport'],
arch = detail.keyvals.get('arch', 'noarch'),
)
Josef is used to add spaces between keyword name and its value in method
definitions or method calls. Personally, I find it more readable according to
PEP8 (with no space), but Josef claims the opposite :)
E128
libtaskotron/check.py:94:17: E128 continuation line under-indented for visual
indent
libtaskotron/check.py:97:21: E128 continuation line under-indented for visual
indent
libtaskotron/check.py:209:21: E128 continuation line under-indented for visual
indent
raise exc.TaskotronValueError('output' parameter must be a
mutable sequence of strings. Yours was: %s % type(output))
This is a braindead check. You have a limited line length, and it is happens
that you need to type the opening bracket shortly before the end of the line,
PEP8 imagines you end up providing the rest of the code as a short column of
text underneath it. Like this:
raise exc.TaskotronValueError('output' parameter must be a
mutable sequence of strings.
Yours was: %s % type(output))
or you break the line immediately after the opening bracket, like this:
raise exc.TaskotronValueError(
'output' parameter must be a
mutable sequence of strings. Yours was: %s % type(output))
Still, the most readable code I believe is the first one, against PEP8.
E303
libtaskotron/check.py:88:5: E303 too many blank lines (2)
libtaskotron/check.py:110:5: E303 too many blank lines (2)
libtaskotron/check.py:115:5: E303 too many blank lines (2)
libtaskotron/check.py:122:5: E303 too many blank lines (2)
libtaskotron/check.py:142:5: E303 too many blank lines (2)
libtaskotron/check.py:148:5: E303 too many blank lines (2)
libtaskotron/check.py:165:5: E303 too many blank lines (2)
libtaskotron/check.py:189:5: E303 too many blank lines (2)
libtaskotron/check.py:224:5: E303 too many blank lines (2)
This forbids you from adding two blank lines between class methods. Another
braindead checks.
E124
libtaskotron/bodhi_utils.py:146:25: E124 closing bracket does not match visual
indentation
log.warn(The build %s is a part of two different updates: '%s'
and '%s'. That's probably a bug in Bodhi. % (build,
failures[build]['title'], build2update[build]['title'])
)
Because PEP8 wants this:
log.warn(The build %s is a part of two different updates: '%s'
and '%s'. That's probably a bug in Bodhi. % (build,
failures[build]['title'], build2update[build]['title'])
)
In a longer line of text, having the closing bracket really matching the
opening one (the first example) is much easier on the eyes.
E122 =
Re: Coding Style
But if there's a strong desire for more columns, I'll manage. Can't hinder the team, can I? :) Also, we should mention that by default the maximal line length is set to 79, not 80. Let's just set it to 80 (as we already use it in the code), and forget about the heretic 100 idea :) ___ qa-devel mailing list qa-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/qa-devel
Re: Coding Style
On Tue, 3 Jun 2014 09:29:49 -0400 (EDT)
Kamil Paral kpa...@redhat.com wrote:
Outside any header requirements or directive documentation
requirements, are there any changes to PEP8 that folks want to
make? If so, please list the exceptions and why you think they
should be adopted.
E251 =
Josef is used to add spaces between keyword name and its value in
method definitions or method calls. Personally, I find it more
readable according to PEP8 (with no space), but Josef claims the
opposite :)
Personally, I agree with Josef on this one. My habit is to put the
spaces in there and I tend to find it a bit more readable but I don't
have any really strong feelings on it and have been training myself to
not put the spaces in there.
E128
libtaskotron/check.py:94:17: E128 continuation line under-indented
for visual indent libtaskotron/check.py:97:21: E128 continuation line
under-indented for visual indent libtaskotron/check.py:209:21: E128
continuation line under-indented for visual indent
snip
Still, the most readable code I believe is the first one, against
PEP8.
In my opinion, the first example is the least readable of the three and
I really don't like having code formatted like that.
E303
libtaskotron/check.py:88:5: E303 too many blank lines (2)
This forbids you from adding two blank lines between class methods.
Another braindead checks.
Eh, I'm not all that partial to either point of view. They're different
ways of looking at things.
E124
libtaskotron/bodhi_utils.py:146:25: E124 closing bracket does not
match visual indentation
log.warn(The build %s is a part of two different
updates: '%s' and '%s'. That's probably a bug in Bodhi. % (build,
failures[build]['title'],
build2update[build]['title']) )
Because PEP8 wants this:
log.warn(The build %s is a part of two different
updates: '%s' and '%s'. That's probably a bug in Bodhi. % (build,
failures[build]['title'],
build2update[build]['title']) )
In a longer line of text, having the closing bracket really matching
the opening one (the first example) is much easier on the eyes.
Honestly, I don't really notice things like this. I had to stare at the
two examples for a while before I realized what the difference was. I'm
fine with keeping this restriction
E122 =
libtaskotron/runner.py:127:17: E122 continuation line missing
indentation or outdented
raise TaskotronYamlError(Input yaml should contain
correct 'input' section (a mapping). Yours was: %s % type(
self.taskdata['input']))
I don't really understand the purpose of this error. If I move
'type(' to the third line, it goes away.
I agree with Josef on this one. In general, I don't like having
calls hat start on one line like that and continue onto the next line
and am fine with keeping this enabled.
E265
libtaskotron/directives/bodhi_comment_directive.py:422:13: E265 block
comment should start with '# '
#TODO: replace url with proper URL
Me and Josef are used to avoid the space in these cases. We can
re-learn, of course. But it's very common to write it this way.
Yeah, I had to relearn that habit as well but I'm of the opinion that
having a space between '#' and the rest of the comment does make many
comments easier to read.
E111, E113
libtaskotron/config_defaults.py:53:35: E111 indentation is not a
multiple of four libtaskotron/config_defaults.py:53:35: E113
unexpected indentation
bodhi_posting_comments_span =
4320 #: # 3 days (3*24*60 = 4320)
This is a nice example how automated style checks impede visual
coding. In this case, it makes absolute sense to have the comment
written in this way. However, if we suppress E111 and E113 globally,
we might miss some potential problems elsewhere. I'm not sure if we
can suppress certain warnings only in a selected block of code, but
if we check for PEP8 automatically, we should find out. There will be
more use cases like this one.
The '#:' is for making sphinx format the comments differently when
rendering docs, no? Why can't the comment explaining that 3 days is
4320 minutes be inline?
Why is making the indentation a clean multiple of 4 not an option here?
Granted, that wouldn't fix both errors but it would fix one of them.
Sooo, I'm not exactly a big fan of automated PEP8 checking (I had to
disable it in Spyder, because it was driving me mad), but it might be
somewhat useful, if we configure some exceptions to the general rules.
What about using pylint instead of the pep8 tool. While I realize it
isn't 100% of what pep8 covers, they're close and AFAIK, pylint is
quite a bit more configurable than pep8 compliance checkers are.
Outside of any one (or more than one) person's dislike of
Re: Coding Style
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/04/2014 02:01 PM, Tim Flink wrote: Of the concerns you raised, I'm not terribly opposed to most of them other than E128 and E122. I'm not crazy about dropping E265, though. One thing to watch with pep8 is it has the notion of ignored by default errors. If you start turning additional errors off, you need to make sure to turn those ones off as well. (my own major gripe is with E121, since that was based on a misreading of the PEP, which has since been clarified: https://github.com/jcrocholl/pep8/issues/256) Cheers, Nick. - -- Nick Coghlan Red Hat Hosted Shared Services Software Engineering Development, Brisbane Testing Solutions Team Lead -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTjqEaAAoJEHEkJo9fMO/LIJcH/i/C6YmfezKHmPXC0NaBlBcf /YW+BTNYIInELC1QRG6WDOUplmXhFQ68Fn1taCp2MaMtB4QB10MkcBiRaHqAdwS9 0t2k0RNEbrPO58XgN2P0FcLbdn+rcRM27KOKwdfchiBoqOzebobw40PKQwe1KYNp K62QrfX/Mrfiadz+mCt54rcmpDyelfevd9+GwLCgAyVoI1techvh12kcitvGfnj6 6cG4bXuyHrnvaOXCqjp4ZeXGNBnBPPbVi8dvwvYOLmv00uRQusVyuOiYTcshO1SO qce/kIT+i3AEJlYoKjCLEs9Sq+toTNqxS/4kyiS9ewFKs4ztnTW54JEcPEAHUZg= =2JPd -END PGP SIGNATURE- ___ qa-devel mailing list qa-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/qa-devel
