devel-announce May 2017

devel-announce@lists.fedoraproject.org

6 participants
16 discussions

F27 Self Contained Change: Making sudo pip Safe (Again)
by Jan Kurik 31 May '17

31 May '17

= Proposed Self Contained Change: Making sudo pip Safe (Again) = https://fedoraproject.org/wiki/Changes/Making_sudo_pip_safe Change owner(s): * Michal Cyprian <mcyprian AT redhat DOT com> * Petr Viktorin <pviktori AT redhat DOT com> * Tomas Orsava <torsava AT redhat DOT com> * Miro Hroncok <mhroncok AT redhat DOT com> At the present time, running sudo pip3 in Fedora is not safe. Pip shares its installation directory with dnf, can remove dnf-managed files and generally break the Python 3 interpreter. We propose a series of measures that will make it safe to use. == Detailed Description == The danger of using sudo pip3 stems from the fact that both Python dnf packages and sudo pip3 install modules to the same location, namely /usr/lib/pythonX.Y/site-packages. We aim to move the working directory for sudo pip3 to a more appropriate location: /usr/local/lib/pythonX.Y/site-packages, and modify the Python 3 interpreter in Fedora to scan both above mentioned locations when importing modules. In addition, system-python—a stripped down version of Python 3 for use by system tools—will not read the sudo pip3 install location, making it more secure by being less susceptible to interference by user-downloaded modules. From the technical standpoint, this will be accomplished by changing the install prefix setting of the distutils install command in the /usr/bin/python3 executable from /usr/ to /usr/local. pip3 and distutils will thereafter use this prefix when determining where to install modules. In addition, the paths /usr/local/lib/pythonX.Y/site-packages and /usr/local/lib64/pythonX.Y/site-packages will be added to the front of the sys.path variable so that modules are imported preferentially from there. These settings, however, will not be modified for the system-python binary, the /usr/bin/python3 executable when running with -I option specified, nor when an RPM build is detected. Therefore, Python RPM packages will continue to be built with the correct installation path for system modules. The purpose of this change is not to make sudo pip a standard way to install Python packages. Virtual environments and pip3 install --user should still be the prefered options. Nevertheless, sudo pip is far too prevalent an instruction in various guides and installation notes throughout the Internet that there is little hope of changing users' behaviour in this regard. == Scope == * Proposal owners: Modify the distutils install command as described above. Modify the site.py script to add additional paths to sys.path when it is needed. * Other developers: N/A (not a System Wide Change) * Release engineering: https://pagure.io/releng/issue/6820 * List of deliverables: N/A (not a System Wide Change) * Policies and guidelines: N/A (not a System Wide Change) * Trademark approval: Not needed for this Change -- Jan Kuřík Platform & Fedora Program Manager Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic

1 0

F27 System Wide Change: Rsyslog log format change proposal
by Jan Kurik 29 May '17

29 May '17

= Proposed System Wide Change: Rsyslog log format change proposal = https://fedoraproject.org/wiki/Changes/RsyslogLogFormat Change owner(s): * Radovan Sroka <rsroka AT redhat DOT com> * Roman Pavelka <rpavelka AT redhat DOT com> Currently Fedora uses RSYSLOG_TraditionalFileFormat as a default format for timestamps in its logs. There is missing year and timezone. This proposal aims to change this by adopting ISO 8601 and RFC 3339 compliant timestamp format known as RSYSLOG_FileFormat instead of current RSYSLOG_TraditionalFileFormat. == Detailed Description == Currently Fedora, RHEL and CentOS use RSYSLOG_TraditionalFileFormat for log’s timestamp, so timestamps in files like /var/log/messages, /var/log/cron and /var/log/secure looks like e.g.: May 29 13:37:50 localhost systemd: Starting Fingerprint Authentication Daemon... This format has few disadvantages * Does not include year which sometimes may be needed, mostly when doing long term analysis or some investigation. * Does not include timezone which may be important piece when working with system scattered around the globe. * It is not standard format. Standards are ISO 8601 and more strict RFC 3339 We would propose to change this to defaults to standard format with timezone included. We are suggesting new RSYSLOG_FileFormat that looks like e.g.: 2017-05-29T13:40:50.976409+02:00 localhost systemd: Stopping System Logging Service... == Scope == * Proposal owners: - commit necessary changes - create rsyslog build * Other developers: none * Release engineering: Releng#6818 https://pagure.io/releng/issue/6818 * List of deliverables: Not affected * Policies and guidelines: Not affected * Trademark approval: Not needed for this Change -- Jan Kuřík Platform & Fedora Program Manager Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic

1 0

PkgDB and the ArbitraryBranching Change
by Ralph Bean 26 May '17

26 May '17

Hello, As part of the Factory 2.0 and Modularity efforts[1], we’ve been developing a plan to migrate to an “arbitrary” branching model from our current model of one branch per release (as had been discussed at Flock and DevConf[2]). The main motivation behind this is to enable functionality required by Modularity[3] and to ultimately reduce some package maintenance burden. For some packages, it makes sense to have only a single branch that feeds into multiple releases. For other packages, it makes sense to have multiple branches which correlate with multiple upstream minor releases. Today, our source branches are tied to the distro release, via PkgDB. We want to decouple that and use modules to put it all back together again. To make this happen requires significant infrastructure changes. Our proposed plan[4] is to decommission PkgDB entirely and to replace it with a combination of PDC[5] and pagure over dist-git. (Tangentially, getting pagure over dist-git to play nicely with PkgDB was a challenge. This route gets us to a pull-request interface for spec files quicker.) We have brought this Change to FESCo[6][7][8] who expressed general agreement on the project but also concern that the community may be caught by off guard by the removal of PkgDB. As part of this change, we have proposed a timeline[9] that outlines the steps we plan to take to actually proceed with the migration. Please review that if you have time and provide feedback. We are most concerned with missing scripts/tools that may rely on PkgDB’s API. If you can think of any that we may have overlooked, please let us know and we will add it to the timeline! We are meeting again with FESCo next Friday, June 2nd, where a decision will be made on the Change. Any feedback before that would be greatly appreciated. Ralph and Matt, From the so-called Factory 2.0 team [1] https://fedoraproject.org/wiki/Infrastructure/Factory2 [2] https://youtu.be/5gqccjyjwFk?t=26m27s [3] https://docs.pagure.org/modularity/ [4] https://fedoraproject.org/wiki/Infrastructure/Factory2/Focus/ArbitraryBranc… [5] https://fedoraproject.org/wiki/Changes/ProductDefinitionCenter [6] https://fedoraproject.org/wiki/Changes/ArbitraryBranching [7] https://meetbot.fedoraproject.org/teams/fesco/fesco.2017-05-19-16.00.html [8] https://meetbot.fedoraproject.org/teams/fesco/fesco.2017-05-26-16.00.html [9] https://fedoraproject.org/wiki/Changes/ArbitraryBranching#Timeline

1 0

Fedora 26 Beta status is NO-GO
by Jan Kurik 25 May '17

25 May '17

Release status of the Fedora 26 Beta is NO-GO. Due to missing RC of Fedora 26 Beta release and presence of blocker bugs [1] we are delaying release of Fedora 26 Beta for one week. There is going to be one more Go/No-Go meeting the next Thursday, June 1st, 2017 at 17:00 UTC to verify we are ready for the release. For more information please find the logs or minutes from the meeting [2][3]. [1] https://qa.fedoraproject.org/blockerbugs/milestone/26/beta/buglist [2] https://meetbot.fedoraproject.org/fedora-meeting-2/2017-05-25/f26-beta-go-n… [3] https://meetbot.fedoraproject.org/fedora-meeting-2/2017-05-25/f26-beta-go-n… Regards, Jan -- Jan Kuřík Platform & Fedora Program Manager Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic

1 0

F27 System Wide Change: Ruby on Rails 5.1
by Jan Kurik 25 May '17

25 May '17

= Proposed System Wide Change:Ruby on Rails 5.1 = https://fedoraproject.org/wiki/Changes/Ruby_on_Rails_5.1 Change owner(s): * Pavel Valena <pvalena AT redhat DOT com> * Vít Ondruch <vondruch AT redhat DOT com> * Jun Aruga <jaruga AT redhat DOT com> Ruby on Rails 5.1 is the latest version of well known web framework written in Ruby. == Detailed Description == The Ruby on Rails stack is evolving quickly and Fedora needs to keep pace with it. Therefore the whole Ruby on Rails stack should be updated from 5.0 in Fedora 26 to 5.1 (latest version) in Fedora 27. This will ensure that all the Ruby developers using Fedora have the latest and greatest RPM-packaged Ruby on Rails. == Scope == * Proposal owners: - The whole Rails stack has to be updated - Some dependencies of the Rails stack will need update - Packages need to be created/updated - - rubygem-actioncable - - rubygem-actionmaile - - rubygem-actionpack - - rubygem-actionview - - rubygem-activejob - - rubygem-activemodel - - rubygem-activerecord - - rubygem-activesupport - - rubygem-rails - - rubygem-railties - - rubygem-arel * Other developers: Update Rails dependent packages to be working with Ruby on Rails 5.1 * Release engineering: Not needed * List of deliverables: No changes * Policies and guidelines: Not needed * Trademark approval: Not needed -- Jan Kuřík Platform & Fedora Program Manager Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic

1 0

Fedora 26 Beta Release Readiness Meeting on Thursday, May 25 @ 19:00 UTC
by Jan Kurik 21 May '17

21 May '17

Join us on irc.freenode.net in #fedora-meeting-2 for the Fedora 26 Beta Release Readiness Meeting meeting. The meeting is going to be held on Thursday, May 25, 2017 at 19:00 UTC. Please check the [1] link for your time zone. We will meet to make sure we are coordinated and ready for the Beta release of Fedora 26. Please note that this meeting is going to be held even if the release is delayed at the Go/No-Go meeting on the same day two hours earlier. You may received this message several times, but it is by purpose to open this meeting to the teams and to raise awareness, so hopefully more team representatives will come to this meeting. This meeting works best when we have representatives from all of the teams. For more information please check the [2] link. [1] https://apps.fedoraproject.org/calendar/meeting/5759/ [2] https://fedoraproject.org/wiki/Release_Readiness_Meetings Thank you for your support, Regards, Jan -- Jan Kuřík Platform & Fedora Program Manager Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic

1 0

Fedora 26 Beta Go/No-Go Meeting on Thursday, May 25 @ 17:00 UTC
by Jan Kurik 21 May '17

21 May '17

Join us on irc.freenode.net in #fedora-meeting-2 for this important meeting, wherein we shall determine the readiness of the Fedora 26 Beta. The meeting is going to be held on Thursday, May 25, 2017 at 17:00 UTC. Please check the [1] link for your time zone. Before each public release Development, QA and Release Engineering meet to determine if the release criteria are met for a particular release. This meeting is called the Go/No-Go Meeting. Verifying that the Release criteria are met is the responsibility of the QA Team. Release Candidate (RC) availability and good QA coverage are prerequisites for the Go/No-Go meeting. If you have any bug on the list, please help us with Beta release. If we won't be ready by Thursday, we will use this meeting to review blockers and decide what to do. In the meantime, please keep also an eye on the Fedora 26 Beta Blocker list [2]. For more details about this meeting please follow the [3] link. [1] https://apps.fedoraproject.org/calendar/meeting/5760/ [2] http://qa.fedoraproject.org/blockerbugs/milestone/26/beta/buglist [3] https://fedoraproject.org/wiki/Go_No_Go_Meeting Thank you in advance for your support. Regards, Jan -- Jan Kuřík Platform & Fedora Program Manager Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic

1 0

Fedora 26 Beta Freeze
by Mohan Boddu 16 May '17

16 May '17

Hi all, Today is an important day on the Fedora 26 schedule[1], with two significant cut-offs. Today is the Beta freeze[2]. This means that only packages which fix accepted blocker or freeze exception bugs[3][4] will be marked as 'stable' and included in the Beta composes. Other builds will remain in updates-testing until the Beta release is approved, at which point the Beta freeze is lifted and packages can move to 'stable' as usual until the Final freeze. Finally, Today is the '100% code complete deadline' Change Checkpoint[5], meaning that Fedora 26 Changes must now be code complete, meaning all the code required to enable to the new change is finished. The level of code completeness is reflected as tracker bug state ON_QA. The change does not have to be fully tested by this deadline'. Regards Mohan Boddu [1] https://fedoraproject.org/wiki/Releases/26/Schedule [2] https://fedoraproject.org/wiki/Milestone_freezes [3] https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process [4] https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process [5] https://fedoraproject.org/wiki/Changes/Policy

1 0

UPDATE: Bugzilla 5 beta server is back online
by Christine Freitas 15 May '17

15 May '17

Hello All, The Bugzilla 5 beta server [1] is back online. We encourage you to test your current scripts and take part in the beta discussions on the Fedora development list [2]. Partners and customers may also use their existing communications channels to share feedback or questions. We've extended the beta window and ask that you provide feedback or questions by Wednesday, June 14th. The official release date for Bugzilla 5 will be determined based on the beta feedback. We will communicate to you as the beta continues to progress. For more information refer to: https://beta-bugzilla.redhat.com/page.cgi?id=whats-new.html https://beta-bugzilla.redhat.com/page.cgi?id=release-notes.html https://beta-bugzilla.redhat.com/page.cgi?id=faq.html https://beta-bugzilla.redhat.com/docs/en/html/using/index.html https://beta-bugzilla.redhat.com/docs/en/html/api/index.html Cheers, the Red Hat Bugzilla team. 1: https://beta-bugzilla.redhat.com/ 2: https://lists.fedoraproject.org/archives/list/devel%40lists. fedoraproject.org/

1 0

F27 System Wide Change: Perl 5.26
by Jan Kurik 12 May '17

12 May '17

= Proposed System Wide Change: Perl 5.26 = https://fedoraproject.org/wiki/Changes/perl5.26 Change owner(s): * Jitka Plesníková <jplesnik AT redhat DOT com> * Petr Písař <ppisar AT redhat DOT com> A new perl 5.26 version brings a lot of changes done over a year of development. Perl 5.26 will be released 5/20/2017. See 5.26.0-RC perldelta for more details about preparing release. http://search.cpan.org/dist/perl-5.26.0-RC1/pod/perldelta.pod == Detailed Description == New perl is released every year and updates containing mainly bug fixes follow during the year. The 5.26.0 version is stable release this year. == Scope == Every Perl package will be rebuilt in a dedicated f27-perl build-root against perl 5.26.0 and then if no major problem emerges the packages will be merged back to f27 build-root. * Proposal owners: New perl and all packages requiring perl or a Perl module will be rebuilt into f27-perl build-root. * Other developers: Owners of packages that fail to rebuild, mainly perl-sig users, will be asked using Bugzilla to fix or remove their packages from the distribution. * Release engineering: Release engineers will be asked for new f27-perl build-root inheriting from f27 build-root. After successful finishing the rebuild, they will be asked to merge f27-perl packages back to f27 build-root. * Policies and guidelines: No policies have to be modified to complete this change. -- Jan Kuřík Platform & Fedora Program Manager Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

devel-announce May 2017