The next Tuesday, on 2018-Mar-06, we will reach two important
milestones of the Fedora 28 release [1]:
== Change Checkpoint: 100% Code Complete Deadline [2] ==
* New accepted changes must 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.
== Beta Freeze [3] ==
Only packages which fix accepted blocker or freeze exception bugs [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.
[1] https://fedoraproject.org/wiki/Releases/28/Schedule
[2] https://fedoraproject.org/wiki/Changes/Policy
[3] https://fedoraproject.org/wiki/Milestone_freezes
[4] https://qa.fedoraproject.org/blockerbugs/milestone/28/beta/buglist
Regards,
Jan
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
Greetings.
Per this fesco ticket:
https://pagure.io/fesco/issue/1714
I have created the Fedora 28 spins/labs page:
https://fedoraproject.org/wiki/Releases/28/Spins
All spin maintainers/owners/interested parties should test their spins
and at least update this wiki page with beta/final testing. Spins that
don't have at least one tester at Beta may be dropped and not shipped in
Final, so PLEASE make sure at least someone tests.
Spin maintainers are also encouraged to test their spin more often and
make sure it's composing correctly every day for Branched f28 and rawhide.
Thanks,
kevin
Hi All,
Fedora 28 has now been branched, please be sure to do a git pull
--rebase to pick up the new branch, as an additional reminder
rawhide/f29 has been completely isolated from previous releases, so
this means that anything you do for f28 you also have to do in the
master branch and do a build there. There will be a Fedora 28 compose
ASAP and it'll appear
http://dl.fedoraproject.org/pub/fedora/linux/development/28/ once
complete. Please be sure to check it out. Bodhi is currently not
active for Fedora 28, it will be enabled in a weeks time when we hit
Beta change freeze point in the Fedora 28 schedule[1].
Mohan Boddu.
[1] https://fedoraproject.org/wiki/Releases/28/Schedule
Greetings!
Today, on 2018-Feb-20, we have reached Fedora 28 Change
Checkpoint:Completion deadline (testable) [1].
At this point, all accepted changes [2] should be substantially
complete, and testable. Additionally, if a change is to be enabled by
default, it must be enabled at Change Completion deadline as well.
Change tracking bug should be set to the MODIFIED state to indicate it
achieved completeness.
Incomplete and non testable Changes [3] will be reported to FESCo on
2018-Feb-23 meeting. Contingency plan for System Wide Changes in case
of serious doubts regarding Change completion, will be activated.
[1] https://fedoraproject.org/wiki/Releases/28/Schedule
[2] https://fedoraproject.org/wiki/Releases/28/ChangeSet
[3] http://red.ht/2BEyQt0
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hey,
today I've split⁰ librpmsign from rpm-build-libs into its own subpackage rpm-
sign-libs.
This resulted into 8 packages disappearing from buildroot¹².
This should not be a problem, but still useful to know.
⁰ https://src.fedoraproject.org/rpms/rpm/c/99d6687a36647cb307b789d19921a34154…
c671
¹ gnupg2, gnutls, ima-evm-utils, libassuan, libksba, libusbx, nettle, npth
² 171 → 163 packages
- --
- -Igor Gnatenko
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlqMHnsACgkQaVcUvRu8
X0wmUhAAtx5N4EQ+ulMHDkWyi1p96RGojp0H0xMudlai54sJOU/0FvNe8y0e0o6H
ZERhdDKDgl7KtNEhSS/KsL+8Siog2PCSDv3SbwGrfeqegCRz/qOq4gqPsdLdkgCu
dNtUNpvVIBwrTcNSU7igVnlnz5b9Su3TcCBunca3vCEEU5MKtEWQTYqFIjxOAjBX
NGkuvmoY3hj07IP9Vh0q0VNyHCBfsXmVHruN9b8VFZx9IcEJ2OguQ6cFVzoeyeeI
p4dlKza3znXeS53GtDA7WMGBEl/EI8Czh2/5JXgBZrshshfCY84pa2kZo0igC/3m
lAbTCvGtqt8V4HW2RPttQsEtvTrRseuXWRXvNIcrXXiTaB6XyRaf58tY3jWerK5k
3KlDyMSNvD6neSrk7ujykX5Wh4qQAvmvSrjEeYAPpwIoBh1uAH1yKQJ1THPSxwff
9u/kU7bnGfJOIMAi0AQR3jNBxFVWZzEZisA/k6M5RwKLdb+Lvcxpz39wTSzqd0SE
0dMP5VWZ50P9JGh+xmWPtYWId7qzbYsXxzLBTwtbDZNfoUGxawF8jsxLN35tsgw9
Mojw9R34uq1ytPYcg6tIX2tryDW2oBm9AhKPC6+WKCjJeQIZze1YzL+cdFsd0aba
9+smUVTWBRaXI6CL9luXkjSG4jzu7C2Fb7Fvb4/PZ0bM0ZtNhUk=
=wlgf
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Over this weekend I've performed scratch-mass-rebuild without having gcc and
gcc-c++ in buildroot of all Fedora packages, many of which failed due to random
reasons and I grepped all logs for some common errors found by analyzing
hundreds of build logs.
Guidelines: https://fedoraproject.org/wiki/Packaging:C_and_C%2B%2B#BuildRequire
s_and_Requies
The grep output is located here:
https://ignatenkobrain.fedorapeople.org/gcc-removal.txt
Some packages might be missed due to short koji outage, broken dependencies and
so on, but majority of real failures is below.
If you fixed package(s), found false positive, found missing packages in list
or anything else -- please let me know.
Note to packages which use CMake buildsystem. When you have project(xxx) in
CMakeLists.txt it checks both for C and CXX compilers. So you might encounter
packages where you have BuildRequires: gcc and it fails on CXX compiler (even
you think you don't need it). Solution for this is to send patch to upstream
switching to something like project(xxx C), or if problem is opposite to
project(xxx CXX).
List of packages and respective maintainers:
https://ignatenkobrain.fedorapeople.org/gcc-removal-pkgs.txt
- --
- -Igor Gnatenko
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlqJs1QACgkQaVcUvRu8
X0xxkRAAj56QZYSxzDXiMyvM9eLdVS0Qrt9jiNa66rasIbDVciTym7WQoV2CXxM+
ZxaOCYU8eyxOhE1rx36KITJ7SgU6ugLu2dVZlG/QR8vH3RTqJPV/GWhM/WUAgaon
f/SPwTIMk31qvEuKwlqLgNH1rwpRH2NfWVelZChwi1zXOglMvIHakV7sSedYy2i9
bmVvf/1ylj/NbaI6FaLUqg81UQhUulD8RYeZi1cyxSpit/4aysP7ixCb4MLizmwH
uNUO0y//xxL0hMSShmfTlsPXowU+NpkzV+lFQ/k2X4KcCZWMabfCt69TdyTbYlj5
ai8oFGNI94Tv6rrzR/Rirfl/eODtdaaeNqyg/MBze6hYpS2w2oezOEmdYvlpJ7Xo
z0fN/vIus1SeeyIKWo4KYHZYRX6g2nTCUeGYJqvCIRVxS9UJsy45C/HlnIWTtedn
Dyp9O/0aSDhY+ErPQi64+HloZrY7p+KsCzPNc9HdzLbhnfM5IUn2TmO+qHngBSlY
zGNfpOsBmmllSuBftWDfiayh8C9sBUpGT9693iyQYXPIwjZkQSHAclDZa7naN3Oy
NKQaqVOsDmgDDP9xVOyr/Aue3jQk/8QHraM5DgO05L6lXHwdm+rjIdbb7CU2rFF7
Gl14+kSFP7yufRQiS6Gt96eN4ePxSuD7XjiT/9GicztDXypNeX8=
=KRiO
-----END PGP SIGNATURE-----
= Proposed Self Contained Change: FedoraScientific VagrantBox =
https://fedoraproject.org/wiki/Changes/FedoraScientific_VagrantBox
Owner(s):
* Amit Saha <amitsaha dot in at gmail dot com>
Fedora Scientific is currently delivered as ISOs. Shipping vagrant
boxes will give potential users a friendlier option to try out Fedora
Scientific while keeping their current operating system.
== Detailed description ==
Vagrant boxes for Fedora Scientific will allow users to easily run
Fedora Scientific in a virtual machine. This can be useful for users
who are using another operating system as their host operating system
and not have to manually download the ISO, and go through the
installation process which can be unfamiliar or unnecessary hassle for
users who may be new to Fedora or Linux.
== Scope ==
* Proposal owners:
This will require creating pungi configuration as well as new
kickstarts to be able to build the vagrant boxes for Fedora
Scientific.
* Other developers:
N/A (not a System Wide Change)
* Release engineering:
https://pagure.io/releng/issue/7324
** 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
Greetings.
There's some packages that have been orphaned by FESCo and are seeking a
new point of contact to stay in the collection.
If you are interested in becoming the point of contact for these, please
note it in the appropriate ticket below for quickest processing.
(no need to reopen the ticket, just add your fas name and what packages
you want to take)
https://pagure.io/fesco/issue/1839
rpms/clamz
rpms/inkboy-fonts
Thanks,
kevin
I'm going to be submitting an update for libmodulemd today for all released
branches of Fedora. This is *technically* in conflict with the Stable
Updates Policy, but it is both necessary and should be safe to accomplish.
1) The teams that were planning to switch to it from the previous
python-modulemd have not yet done so or are just starting to, so it's not
believed there is anything currently running in production with the older
version.
2) The API is *source*-compatible, but not binary-compatible (hence the
soname bump), so it will just require a rebuild if anyone *is* using it.
3) The reason for the API change is that certain semantics around ownership
of memory have changed. This mostly impacts the GObject Introspection
bindings for other languages such as Python, but as it technically changes
the ABI contract, bumping soname was the correct thing to do.
[f26] https://bodhi.fedoraproject.org/updates/FEDORA-2018-f731883394
[f27] https://bodhi.fedoraproject.org/updates/FEDORA-2018-a1c9076f1f
Proposed System Wide Change: Remove GCC from BuildRoot
https://fedoraproject.org/wiki/Changes/Remove_GCC_from_BuildRoot
Owner(s):
* Igor Gnatenko <ignatenkobrain at fedoraproject dot org>
Removing gcc and gcc-c++ from default buildroot in Koji and mock.
== Detailed description ==
Since beginning of Fedora, gcc (and gcc-c++) are installed in every
buildroot. Times have changed and nowadays many of packages are not
written in C/C++, they are written in Python, Ruby, Node.js, Go, Rust,
OCaml, Perl and so on so they don't need to have C/C++ compiler.
Installing gcc and gcc-c++ takes time so if we remove it, we can
improve build times for many of the packages.
== Scope ==
* Proposal owners:
Remove gcc, gcc-c++ from build group in Koji and from buildsys-build
group in comps.
* Other developers:
Maintainers should follow guidelines and add BuildRequires: gcc if
they need it during build (this guideline exists for long time).
* Release engineering: [https://pagure.io/releng/issue/7317 #7317]
** List of deliverables:
N/A (not a System Wide Change)
* Policies and guidelines:
Nothing needed, guidelines already have paragraph about listing all
required BuildRequires.
* 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