F27 Self Contained Change: Making sudo pip Safe (Again)
by Jan Kurik
= 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
6 years, 4 months
F27 System Wide Change: Rsyslog log format change proposal
by Jan Kurik
= 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
6 years, 4 months
PkgDB and the ArbitraryBranching Change
by Ralph Bean
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/ArbitraryBra...
[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
6 years, 4 months
F27 System Wide Change: Ruby on Rails 5.1
by Jan Kurik
= 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
6 years, 4 months
Fedora 26 Beta Release Readiness Meeting on Thursday, May 25 @ 19:00 UTC
by Jan Kurik
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
6 years, 4 months
Fedora 26 Beta Go/No-Go Meeting on Thursday, May 25 @ 17:00 UTC
by Jan Kurik
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
6 years, 4 months
F27 System Wide Change: Perl 5.26
by Jan Kurik
= 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
6 years, 4 months