F26 System Wide Change: Modular Server Preview
by Jan Kurik
= System Wide Change: Modular Server Preview =
https://fedoraproject.org/wiki/Changes/Modular_Server_Preview
Change owner(s):
* Langdon White <langdon(a)fedoraproject.org>
As we progress down the modularity path, we finally have enough
content, architecture and understanding that we would like to release
an edition of Fedora that is actually usable. However, as we aren't
ready for production yet, we would like to do a "preview" release so
that people can see it and try it but it doesn't actually take the
place of a production edition. As such this Change Proposal requests
that we set up a "Modular Server Edition" with some sort of flag that
indicates that it is meant for experimentation and not real use. We
plan to model the Server Edition in content and most use scenarios.
== Detailed Description ==
The modularity effort is fairly well known and significantly more
information may be found on the wiki or the YouTube Channel. In short,
modularity is attempting to disconnect the lifecycle of applications
from 1) each other 2) the operating system while still maintaining the
ease of use of a typical Linux Distro.
== Scope ==
* Proposal owners:
** The Modularity WG, Factory 2.0, Base Runtime, and Server WG teams
all have contributions to this effort. The work that each team is
doing is significant and wide ranging. However, as the release is
being managed in a "preview channel" none of the changes, whether
released on time or not, will impact any other aspect of Fedora. Also,
while we have high hopes for the amount of content we plan to release,
even a small percentage of that content being ready will be enough to
help prove the concept and generate feedback.
* Other developers:
** A limited number of Fedora Packagers will help to provide modules
and containers for this release of Modular Server. See
https://fedoraproject.org/wiki/Changes/ModuleBuildService for more
details.
* Release engineering:
** List of deliverables: Numerous but largely aligned with the Server
WG Logic Model (
https://kolinahr.fedorainfracloud.org/edit/57ff81347b76717eefcbc44b )
** Release engineering needs to create and deliver this new "edition."
The Factory 2 team is largely responsible. Ralph|Threebean has been
the primary point of contact thus far.
** A preview edition delivering the Modular Server
* Policies and guidelines:
** New guidelines are required, they are currently in Draft state and
we will be collecting feedback to them during the F26 lifecycle for
ratification prior to F27.
*** https://fedoraproject.org/wiki/Fedora_Packaging_Guidelines_for_Modules
*** https://fedoraproject.org/wiki/Container:Guidelines
** At this point there are no changes expected to existing guidelines
* Trademark approval: N/A (not needed for this Change)
** This is based on a Fedora Objective and, as a result, does not seem
to require Trademark approval even though it will carry the Trademark.
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
7 years, 2 months
Fedorahosted.org sunset reminder: 2017-02-28
by Kevin Fenzi
(This is a resend reminder, with some additional faq information)
Greetings.
Fedora Infrastructure currently maintains two sites for general open
source code hosting: fedorahosted.org and pagure.io.
Fedorahosted.org was established in late 2007 using Trac for issues and
wiki pages, Fedora Account System groups for access control and source
uploads, and offering a variety of Source Control Management tools
(git, svn, hg, bzr). With the rise of new workflows and source
repositories fedorahosted.org has ceased to grow, adding just one new
project this year and a handful the year before.
Pagure.io was established in 2015, and is a modern Flask/Python based
application. It is under rapid development and supports git repos for
source code, docs, and tickets. The pull request model is used for
changes along with many options for projects. Access control is
standalone. New projects are self service and added all the time.
Given the lack of growth and continued maintenance burden, Fedora
Infrastructure would like to retire fedorahosted.org and encourage all
its active projects to move to pagure.io (or whatever other place they
feel best meets their needs). We have tenatively scheduled this
retirement for February 28th, 2017.
The Infrastructure team has already contacted owners of the top ten
projects on Fedora Hosted for input on their needs. If your project
has special needs, please contact the Infrastructure team (details
below) to discuss options.
After the sunset date, we will continue to provide raw data from public
projects previously hosted at fedorahosted.org, but the service itself
will be closed. We hope to provide this data for download for a few
years, but won't provide it forever.
A quick FAQ:
Question: pagure.io has some issues/problems that prevent me from
moving my project there. What can I do?
Answer: Please file these issues against pagure:
https://pagure.io/pagure/issues/ and we will try and address them as
best we can. Note that not every feature request can be accommodated
but the team will consider all requests.
Question: How can I migrate my data from fedorahosted to pagure.io?
Answer: You can use the https://pagure.io/pagure-importer tool to
migrate trac data to pagure.io issues. Git repositories should be
easily migrated with a push to the new pagure.io repo. Releases can be
uploaded to pagure.io. There is also available a copr repo with the
latest version of the importer tool:
https://copr.fedorainfracloud.org/coprs/cverna/pagure-importer/
Question: I want to test things out, but not migrate yet, how can I do
that?
Answer: We have a https://stg.pagure.io/ test instance you are welcome
to create projects on and test importing data. Note that from time to
time we clear out this instance, so do not use it for any long term
use.
Question: What happens if I ignore this/don't get around to migrating
my project by the 2017-02-28 deadline?
Answer: We hope to provide the raw data from projects for download for
a while, so you should be able to download a tar.xz of your old git
repo and trac files, but it will be up to you to extract what you need
from them, and we won't host them forever. The data sunset period would
be at least several additional months.
Question: Does pagure.io support hg, bzr, svn or cvs?
Answer: no.
Question: I have a mailing list at lists.fedorahosted.org, what happens
to that?
Answer: We have no plans to retire lists.fedorahosted.org at this time.
All lists and archives will keep functioning. We hope soon to have a
lists.pagure.io domain available and projects that wish to migrate can
do so if they choose.
Question: I have more questions, where can I get more answers?
Answer: Feel free to ask on the infrastructure(a)lists.fedoraproject.org
list or #fedora-admin on IRC
Thanks,
kevin
7 years, 2 months
F26 System Wide Change: Parallel Installable Debuginfo
by Jan Kurik
= System Wide Change: Parallel Installable Debuginfo =
https://fedoraproject.org/wiki/Changes/ParallelInstallableDebuginfo
Change owner(s):
* Mark Wielaard <mjw AT redhat DOT com>
debuginfo packages can be installed in parallel to make it easier to
trace, profile and observe what programs are doing or to debug when
they have crashed. That way debugging, tracing or profiling programs
can be done independent of whether they are 32bit, 64bit, a slightly
newer or older version than currently installed or even from a
different architecture.
== Detailed Description ==
Currently only one version of a debuginfo package can be installed for
a given package. Even on a multi-lib system you cannot install the
64-bit and 32-bit versions of a debuginfo package in parallel
(technically you sometimes can, because of RPM file coloring, the
64bit version of the .debug files win over the 32bit version - causing
lots of confusion). But there are various situation where having
multiple versions of the debuginfo package installed help with
tracing, profiling, debugging and/or crash analysis (see the Benefit
to Fedora section below). There are various things provided by a
debuginfo file that might conflict preventing parallel installation of
different versions:
* build-id file /usr/lib/debug/.build-id/xx/yyyy...yyy which is a
symlink to the main ELF file.
* build-id.debug file /usr/lib/debug/.build-id/xx/yyyy...yyy.debug
which is a symlink to the .debug ELF file.
* The .debug files under /usr/lib/debug/ with file path names
mirroring the main ELF file paths under / with .debug added.
* The source files under /usr/src/debug/<name>-<version>/
They can be made non-conflicting in the following ways:
* The main build-id file should not be in the debuginfo file, but in
the main package (this was always a problem since the package and
debuginfo package installed might not match). If we want to make
usr/lib/debug/ a network resource then we will need to move the
symlink to another location (maybe /usr/lib/.build-id). Unfortunately
this means a change will be necessary for debuginfo consumers to that
depend on the old location. We could keep the old symlink and point it
to the new location to work around it. But I will audit the consumers
to see which depend on it and discuss if we can have a new standard
location.
* build-ids are globally unique identifiers. They will be different
across arches. But might match between minor releases if the exact
same ELF image is produced. The linker will get an option to hash in
the full nvr to make sure all build-ids are always fully unique.
* The .debug file names will be changed to main ELF file
name-vr.debug. This name will also be set in the .gnu_debuglink
section of the main file by changing the options given to eu-strip in
the rpm find-debuginfo.sh script.
* The source files will be moved under
/usr/src/debug/<name>-<version>-<release>.<arch>/. This needs changes
to the rpm debugedit program which rewrites the DWARF source file
information.
These changes will make all files in any debuginfo file unique so they
don't conflict when installed in parallel. There should be no changes
necessary to programs (gdb, perf, valgrind, systemtap,
systemd-coredump, eu-stack, abrt-hook-ccpp, etc.) that use build-ids
or .gnu_debuglink to lookup DWARF debug information and source
references for tracing, profiling and debugging.
It would be good to tweak dnf debuginfo-install to know about parallel
installable debuginfo packages and maybe have an easy option to
install the debuginfo for a core file or for the packages running in a
container.
Alternative solutions currently rejected:
* Move main ELF image build-id file under
/usr/lib/.build-id/xx/yyyy...yyy when moving into main pages. Because
existing programs probably depend on the link being under
/usr/lib/debug/.
* Since when the build-id is identifical also the ELF file is
identical we could mark all build-id.debug files as replacable in the
rpm. It isn't clear that works for symlinks though (but we could
reverse the symlink direction from debug file to build-id file). And
currently you can identify the exact package nvr installed given just
one build-id. That would be impossible if multiple packages could
contain the same build-id/ELF image file.
* Do away with the old .gnu_debuglink way of accessing files under
/usr/lib/debug and just not install .debug files and only support
build-id based debug lookups. Because it isn't clear build-ids are
100% available and all programs work with build-id lookups instead
through .gnu_debuglink names.
* Move the .debug files under a subdir like the sources.
/usr/lib/debug/<name>-<version>-<release>.<arch>/. This cannot easily
be expressed in .gnu_debuglink, which officially only allows a
basename.
== Scope ==
* Proposal owners: Patches have been developed against rpm debugedit
to accept a hash value to seed the build-id calculation, rewrite
source paths (currently source paths can only be smaller, this change
might create larger paths) and the rpm find-debuginfo.sh script to
change the paths, symlinks and .gnu_debuglink names as outlined in the
Detailed Description. And the dnf debuginfo-install plugin might be
patches to provide subcommands for pulling in debuginfo packages found
by build-id in core files and/or programs running in containers.
* Other developers: Upstream rpm and dnf maintainers have to review
the proposed patches. If accepted the package maintainers will have to
decide whether those patches can be backported for the next fedora
release. Once all changes are in a package debuginfo needs to be
regenerated before it becomes parallel installable. (Note most of this
has been done already during the F25 cycle. Only one outstanding patch
is not yet ready.)
* Release engineering: Needs to be discussed. In theory no changes
apart from those listed above are needed. But if we want to support
installing cross-architectures (not just multi-lib arch) debuginfo
then some way needs to be found to get those in the right repodata.
* List of deliverables: N/A (Still Unknown)
* Policies and guidelines: No changes, the debuginfo related rpm
macros won't change. They will just start producing parallel
installable debuginfo packages once all changes are in place.
* Trademark approval: N/A (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
7 years, 2 months
Fedora 26 Change Checkpoint: Proposal submission deadline (Changes
requiring mass rebuild)
by Jan Kurik
Greetings!
Today, on 2017-January-10, we have reached Fedora 26 Change
Checkpoint: Proposal submission deadline (Changes requiring mass
rebuild) [1].
At this point, only Changes not requiring mass rebuild will be
accepted for Fedora 26. Any Change Proposal requiring mass rebuild
should be scheduled for a later Fedora release.
System Wide as well as Self Contained Changes not causing a need for
mass rebuild are still accepted according to the F26 schedule [1].
[1] https://fedoraproject.org/wiki/Releases/26/Schedule
Regards,
Jan
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
7 years, 2 months
F26 Self Contained Change: Automated AMI test and release
by Jan Kurik
= Proposed Self Contained Change: Automated AMI test and release =
https://fedoraproject.org/wiki/Automated_AMI_test_and_release
Change owner(s):
* Kushal Das <mail AT kushaldas DOT in>
* Sayan Chowdhury <sayan DOT chowdhury2012 AT gmail DOT com>
We will test the AMI image we build on one single region using the
same tests used in Vagrant/local Autocloud testing, and if the tests
pass, then only the AMI will be uploaded to all the regions and
released.
== Detailed Description ==
Currenly fedming tool creates and uploads the AMI images to AWS, in
all the regions. It only tests the output /usr/bin/true command to
determine if an image is right or not.
The proposed change will split the process in the two parts. fedimg
will first upload the image to only one region and emit a fedmsg
message. Autocloud listening to these message will start testing the
image using the same tests it uses for Vagrant/Atomic qcow2. Autocloud
will upload the test details to ResultsDB. Fedimg will listen to
ResultsDB fedmsg messages for the results of the test and if all the
tests passes then then fedimg would copy the images to other regions
as well.
== Scope ==
* Proposal owners: to implement this Change
* Other developers: N/A (not a System Wide Change)
* Release engineering: N/A (not a System Wide Change)
* List of deliverables: N/A (not a System Wide Change)
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: N/A (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
7 years, 2 months
F26 System Wide Change: GCC7
by Jan Kurik
= System Wide Change: GCC7 =
https://fedoraproject.org/wiki/Changes/GCC7
Change owner(s):
* Jakub Jelínek <jakub AT redhat DOT com>
Switch GCC in Fedora 26 to 7.x.y, rebuild all packages with it, or
optionally rebuild just some packages with it and rebuild all packages
only in Fedora 27.
== Detailed Description ==
GCC 7 is currently in stage3, will move to stage4 on January 19th, in
prerelease state with only regression bugfixes and documentation fixes
allowed. The release will happen probably in the middle of April. We
are working on scratch gcc rpms and will perform a test mass rebuild.
== Scope ==
All packages should be rebuilt with the new gcc once it hits f26, or,
if there is not enough time for that, just all packages built after
the new gcc hits the buildroots.
* Proposal owners:
Build gcc in f26, rebuild packages that have direct dependencies on
exact gcc version (libtool, llvm, gcc-python-plugin, odb).
* Other developers:
First few days/weeks just voluntary rebuilds using the new system gcc,
if things fail, look at http://gcc.gnu.org/gcc-7/porting_to.html and
fix bugs in packages or, if there is a gcc bug or suspected gcc bug,
analyze and report.
* Release engineering:
Organize a mass rebuild, either in f26 or in f27
* Policies and guidelines:
No policies need to be changed
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
7 years, 2 months
F26 Self Contained Change: Transdiff
by Jan Kurik
= Proposed Self Contained Change: Transdiff =
https://fedoraproject.org/wiki/Changes/Transdiff
Change owner(s):
*Sundeep Anand <suanand AT redhat DOT com>
Often even after 100% translation in Zanata, few packages do not get
build with latest translations in Fedora. This result in poor
localization experience. Transdiff is a python program to run on
products installations for tracking translations with project upstream
and generate diff reports.
== Detailed Description ==
Often even after 100% translation in Zanata, few packages do not get
build with latest translations in Fedora. This result in poor
localization experience. Transdiff is a python program to run on
products installations for tracking translations with project upstream
and generate diff reports.
== Scope ==
* Proposal owners: Complete script and package it for Fedora.
* Other developers: N/A (not a System Wide Change)
* Release engineering: N/A (not a System Wide Change)
* List of deliverables: N/A (not a System Wide Change)
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: N/A (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
7 years, 2 months