The Fedora Packaging Committee has some open seats and is accepting
submissions from interested candidates to serve on the FPC.
The FPC would like to thank Orion Poplawski, and Jonathan Wakely for
their service.
This position involves not only reviewing Packaging Guideline drafts
submitted to the FPC for consideration, but also helping rewrite drafts
to resolve issues in a more acceptable fashion. Additionally, the FPC
reviews UID/GID soft static assignment.
Currently the FPC meets on IRC weekly, on Thursdays based around 12:00
east coast US time, for approximately an hour.
That can change slightly, but any new time would need to be good for
all the members (East Coast US and German TZs, at least).
FPC members serve for as long as they are willing, there are currently
no term limits. All decisions are voted on using a +1 (for), 0
(abstain), and -1 (against) mechanism, and all decisions must be
approved by a majority (+5). FPC Meetings do not happen if a quorum (5
members) is not present. Candidates who are interested should provide
the following details to the FPC for consideration, by emailing it
directly to me (james(a)fedoraproject.org)
The FPC will consider all candidates, but strongly prefers candidates
who have extensive experience packaging in Fedora. Due to the current
environment we will be accepting applications for the next _five_ weeks
(deadline Wednesday, 2018-06-24).
Name:
FAS Account:
Provenpackager? (Yes/No):
Main area of packaging interest/expertise:
Reason(s) for wanting to join the FPC:
Thanks in advance,
~James
Voting in the Fedora 32 elections is now open. Go to the Elections app
to cast[1] your vote. Voting closes at 23:59 UTC on Thursday 11 June.
Don't forget to claim your "I Voted" badge when you cast your ballot.
Links to candidate interviews are in the Elections app and on the
Community Blog[2].
[1] https://elections.fedoraproject.org/
[2] https://communityblog.fedoraproject.org/fedora-32-elections-voting-now-open/
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
https://fedoraproject.org/wiki/Changes/drop_mod_php
== Summary ==
mod_php (apache2handler) is an optional httpd module to execute PHP
scripts, not used.
== Owner ==
* Name: [[User:Remi| Remi Collet]]
* Email: remi at fedoraproject dot org
== Detailed Description ==
By default php-fpm is used for a few versions. mod_php is not
supported for threaded modules. mod_php usage also increases security
risk, sharing the same process than httpd.
Drop mod_php from php build. This will only affect user of httpd in
"prefork" mode, which will also use php-fpm.
php-fpm is already used but most users of httpd and nginx without any issue.
The "php" package will be kept as a metapackage, installing (weak
dependencies) most commonly used extension, thus reducing the
difference between "yum install php" (flat repository) and "yum module
install php" (modular repository).
== Benefit to Fedora ==
Only provide the modern way to execute PHP in a web server.
== Scope ==
PHP rebuild (mod_php build is already conditional)
* Other developers: N/A (not a System Wide Change)
* Release engineering: N/A
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
N/A (not a System Wide Change)
== How To Test ==
* install and play with your web applications
== User Experience ==
No change.
== Dependencies ==
None (dependency on "php" is already forbidden by Guidelines)
== Contingency Plan ==
* revert
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? N/A (not a System Wide Change), Yes/No
* Blocks product? product
== Documentation ==
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
https://fedoraproject.org/wiki/Changes/No_more_automagic_Python_bytecompila…
== Summary ==
See [[Changes/No_more_automagic_Python_bytecompilation]] and
[[Changes/No_more_automagic_Python_bytecompilation_phase_2]]. Now,
<code>%global _python_bytecompile_extra 1</code> won't be allowed
anymore and raises an error with a link to this change.
== Owner ==
* Name: [[User:lbalhar| Lumír Balhar]]
* Email: lbalhar(a)redhat.com
== Detailed Description ==
See the [[Changes/No_more_automagic_Python_bytecompilation#Detailed_Description|Detailed
Description of the previous Change Proposal]] and the
[[Changes/No_more_automagic_Python_bytecompilation#Detailed_Description|Detailed
Description of its phase 2]].
Currently, Fedora rawhide contains ~130 packages with `%global
_python_bytecompile_extra 1` in their specfiles but surprisingly only
42 of them actually ship any .pyc files outside the standard location
<code>/usr/lib(64)?/python[0-9]\.[0-9]+</code>. That might be caused
by either of the following:
* there is nothing to byte-compile — the statement is a leftover to be removed
* The automagic bytecompilation uses <code>/usr/bin/python</code> by
default (for historical reasons) but <code>/usr/bin/python</code> is
not present in the buildroot by default.
Our plan is to finish the announced removal of this automagic Python
bytecompilation, remove it from packages where it's not necessary and
fix it with <code>%py_byte_compile</code> for packages where it's
needed.
The [https://docs.fedoraproject.org/en-US/packaging-guidelines/Python_Appendix/#…
documentation] already contains the following paragraph:
If you have *.py files outside of the /usr/lib(64)?/pythonX.Y/
directories and you require those files to be byte compiled (e.g. it’s
an importable Python module) you MUST compile them explicitly using
the %py_byte_compile macro. Note that not all Python files are
importable Python modules; when in doubt, grep the sources for the
appropriate import statement.
so no changes have to be made there.
=== Affected packages ===
From 2020-05-20.
bugzilla
calamares
ceph
chromium
cinnamon-screensaver
edk2
eog-plugins
fish
fleet-commander-admin
fleet-commander-client
freecad
gaupol
gazebo
gdb
gedit
gedit-latex
gedit-plugins
git-cola
glusterfs
gnome-code-assistance
gnome-devel-docs
grass
gtk-doc
gtranslator
ibus
ibus-anthy
ibus-hangul
ibus-libpinyin
ibus-libzhuyin
ibus-pinyin
ibus-table
ibus-typing-booster
ibus-uniemoji
insight
kajongg
kdevelop-python
klatexformula
libpeas
libreoffice
libsmbios
libunity
lirc
lyx
mate-menu
mingw-glib2
mirrormanager2
odcs
onboard
otf2
paraview
pcs
php-opencloud-openstack
pygobject2
pygtk2
python-cherrypy
python-flask-silk
python-genshi
python-pycurl
python-reportlab
qpid-dispatch
rhythmbox
sems
sigul
soundconverter
sugar
sugar-abacus
sugar-browse
sugar-calculator
sugar-castle
sugar-chat
sugar-clock
sugar-colordeducto
sugar-countries
sugar-deducto
sugar-distance
sugar-finance
sugar-flip
sugar-flipsticks
sugar-fototoon
sugar-fractionbounce
sugar-getiabooks
sugar-imageviewer
sugar-implode
sugar-infoslicer
sugar-jukebox
sugar-kuku
sugar-labyrinth
sugar-locosugar
sugar-log
sugar-maze
sugar-measure
sugar-memorize
sugar-moon
sugar-nutrition
sugar-paint
sugar-physics
sugar-pippy
sugar-playgo
sugar-portfolio
sugar-pukllanapac
sugar-read
sugar-recall
sugar-record
sugar-ruler
sugar-speak
sugar-srilanka
sugar-starchart
sugar-stopwatch
sugar-story
sugar-terminal
sugar-turtleart
sugar-typing-turtle
sugar-view-slides
sugar-visualmatch
sugar-words
sugar-write
sugar-xoeditor
sugar-xoirc
sugar-yupana
synfigstudio
system-config-repo
system-switch-java
system-switch-mail
texlive
totem
transmageddon
ufw-kde
variety
virt-manager
vtk
xed
== Benefit to Fedora ==
More explicit specfiles when it comes to Python byte compilation. This
change also supports the dropping of unversioned
<code>%{__python}</code> macro.
== Scope ==
* Proposal owners: Change the brp-python-bytecompile script and macros
in redhat-rpm-config package, help with transforming the packages. See
https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/87
* Other developers: Maintainers of the mentioned python packages will
have to change their packages to use explicit
<code>%py_byte_compile</code>
* Release engineering: No Release engineering work is needed for this change
* Policies and guidelines: nothing to be changed
* Trademark approval: not needed
== Upgrade/compatibility impact ==
None expected.
== How To Test ==
Build a package with <code>%global _python_bytecompile_extra 1</code>.
The build should fail with an actionable error message.
== User Experience ==
The users of this change are packagers. The new behavior should make
byte-compilation more obvious, explicit, and discoverable.
Users of Fedora should not feel this (except if this change uncovers a
packaging bug).
== Contingency Plan ==
* Contingency mechanism: revert the changes in redhat-rpm-config
* Contingency deadline: none (not a System Wide Change)
* Blocks release? no (not a System Wide Change)
* Blocks product? no
== Documentation ==
The guidelines already contain up-to-date documentation.
== Release Notes ==
This change does not deserve Release Notes, it is not user-facing.
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
https://fedoraproject.org/wiki/Changes/NssGCMParams
== Summary ==
Because of changes to the PKCS #11 spec in PKCS #11 v3.0, NSS needs to
change the definition of CK_GCM_PARAMS in a source incompatible way.
Upstream made this change in NSS 3.52.
== Owner ==
* Name: [[User:rrelyea| Bob Relyea]]
* Email: rrelyea(a)redhat.com
== Detailed Description ==
PKCS #11 2.40 had a mismatch between the SPEC and the released header
file for CK_GCM_PARAMS. The latter is controlling. We created or
header based on the former. In PKCS #11 v3.0 the reconciled this, but
it left us with. The new (to NSS) definition has a new field ulIvBits,
which must be set correctly.
To solve this, the NSS 3.52 headers has both definitions:
CK_NSS_GCM_PARAMS is the original NSS definition and CK_GCM_PARAMS_V3
is the new (to NSS) definition. CK_GCM_PARAMS takes on one or the
other based on the definition of NSS_PKCS11_2_0_COMPAT.
The current NSS builds in fedora have changes the sense of this
#define to NSS_PKCS11_3_0_STRICT to get the new behavior, and keep the
old behavior by default. NSS builds will automatically switch back to
the upstream default in Fedora 34. None of the changes below actually
requires setting the NSS_PKCS11_3_STRICT define, though doing so can
test that all but option 1 is functioning.
Applications can fix this the following ways:
option 1
#define NSS_PKCS11_2_0_COMPAT 1
or compile with -DNSS_PKCS11_2_0_COMPAT
your app will compile and run using current and older versions of NSS,
but may break on newer tokens that use the new definition (same as the
previous behavior.
---------------------------------------------------------------
option 2
rename CK_GCM_PARAMS to CK_NSS_GCM_PARAMS (this will now require nss
>= 3.52 to compile, but won't change based on NSS_PKCS11_2_0_COMPAT).
Like option 2 it may break on newer tokens.
------------------------------------------------------------------
option 3
rename CK_GCM_PARAMS to CK_GCM_PARAMS_V3 and set ulIvBits to ulIvLen*8.
This will require nss >= 3.52 to compile and to run. Should run on all
run tokens.
-----------------------------------------------------------------
option 4
Move to PK11_AEADOp interface, which all requires nss >= 3.52 to
compile and run, but it's less surprising and the dependency will be
picked up automatically because you are using a new for 3.52
interface.
----------------------------------
Option 4 is the preferred solution. It takes advantage the the PKCS
#11 v3 interface for AES_GCM while removing any PCKS #11 param
structure dependency in the application. It also handles backward
compatibility on older tokens and automatically detects which flavor
of data structure is supported. It also would help with applications
that support two or more of AES_GCM, AES_CCM, and CHACHA_POLY.
== Benefit to Fedora ==
This change will keep fedora with the NSS upstream as well as make
Fedora compliant with the official OASIS PKCS #11 spec.
== Scope ==
* Proposal owners: NSS 3.52 has already had builds made with the
reverse sense. NSS will need to be rebuilt at the start of Fedora 34.
* Other developers: Developers need to choose one of these options by
fedora 34 or their rebuilt packages will fail at runtime.
option 1
#define NSS_PKCS11_2_0_COMPAT 1
or compile with -DNSS_PKCS11_2_0_COMPAT
your app will compile and run using current and older versions of NSS,
but may break on newer tokens that use the new definition (same as the
previous behavior.
---------------------------------------------------------------
option 2
rename CK_GCM_PARAMS to CK_NSS_GCM_PARAMS (this will now require nss
>= 3.52 to compile, but won't change based on NSS_PKCS11_2_0_COMPAT).
Like option 2 it may break on newer tokens.
------------------------------------------------------------------
option 3
rename CK_GCM_PARAMS to CK_GCM_PARAMS_V3 and set ulIvBits to ulIvLen*8.
This will require nss >= 3.52 to compile and to run. Should run on all
run tokens.
-----------------------------------------------------------------
option 4
Move to PK11_AEADOp interface, which all requires nss >= 3.52 to
compile and run, but it's less surprising and the dependency will be
picked up automatically because you are using a new for 3.52
interface.
----------------------------------
Option 4 is the preferred solution. It takes advantage the the PKCS
#11 v3 interface for AES_GCM while removing any PCKS #11 param
structure dependency in the application. It also handles backward
compatibility on older tokens and automatically detects which flavor
of data structure is supported. It also would help with applications
that support two or more of AES_GCM, AES_CCM, and CHACHA_POLY.
* Release engineering: [https://pagure.io/releng/issue/9486 #Releng
issue number 9486]
I believe there is no additional release engineering requirements for
this bug. Only packages which use CK_AES_GCM_PARAMS need action and
the action can happen outside the release process.
* Policies and guidelines: There isn't any policy or guideline
changes needed for this change.
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
There is no upgrade impact. There will be a source level
incompatibility on rebuild at fedora 34. This change is to allow a
transition in fedora 33 where source code can be updated in ways that
work in both fedora 33 and fedora 34 after recompile. There are no
binary compatibility issues (old applications compiled with the old
version of nss will continue to work).
== How To Test ==
#. Grep for CK_AES_GCM_PARAMS in our source tree. If it does not
appear, no further action is needed.
#. If you choose options 2-4, you can do a normal test build and run
your normal tests against any version of nss > 3.52
#. If you think you don't need to make a change, compile your package
with -DNSS_PKCS11_3_0_STRICT and run your normal tests. If everything
works should should not need further action.
#. option 1 would require building NSS without the patch and then
rebuilding with your package. Only use option 1 if you need to build
your package against older versions of nss.
NOTE: The effect of not changing will create a runtime issue where
your AES_GCM call will fail after recompiling.
== User Experience ==
Users who don't build their own packages will see no issues. Users
that build their own packages and use classic NSS AES_GCM will see
runtime failures after a rebuild unless they update their packages.
== Dependencies ==
nss-3.52 or greater.
== Contingency Plan ==
* Contingency mechanism:
If critical packages are not updated, the NSS team can turn off the
automatic move in fedora 34. If non-critical packages do not update,
then they will just fail on the first rebuild in fedora 34. Libreswan
is the only critical package we know of at this time that is affected.
Upstream already has the appropriate changes.
* Contingency deadline: beta freeze
* Blocks release? Yes, but only for critical packages.
== Documentation ==
Description contains the notes that upstream is working on, modified
for fedora. I'll include links once upstream has released them.
== Release Notes ==
Replicate the description in the release notes of fedora 33 and fedora
34. Users can make their own changes in fedora 33 before fedora 34 is
released.
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
Hello all,
As of the 26th of May 2020, Fedora 30 has reached its end of life for
updates and support. No further updates, including security updates,
will be available for Fedora 30. Fedora 31 will continue to receive
updates until approximately one month after the release of Fedora 33. The
maintenance schedule of Fedora releases is documented on the Fedora
Project wiki [0]. The Fedora Project wiki also contains instructions
[1] on how to upgrade from a previous release of Fedora to a version
receiving updates.
Mohan Boddu.
[0] https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle#Maintenance_Schedu…
[1] https://docs.fedoraproject.org/en-US/quick-docs/dnf-system-upgrade/
# Fedora Data Centre Move - What it means for you?
to: devel-announce(a)lists.fedoraproject.org
subject: Fedora Data Centre Move - What it means for you?
Good Morning,
As you may have heard in the past few months, most of the Fedora Infrastructure which is currently hosted in a data-center in Phoenix Arizona (USA) will be moving to a new datacenter in Virgina (USA) in just a few weeks now.
While we are doing our best to ensure a continuity of service to the project, there will be some consequences of this move.
The main issues will be that for several weeks:
- *Fedora's build capacity will be significantly reduced*.
- A few applications, not directly related to building Fedora, running in the Fedora Infrastructure will be offline (see link below)
Practically, this means that your build will wait longer to find a builder available and as a result the whole build process will feel slower. The builds per say should not be impacted though.
As a result, if you know today that you have some important packaging work to do, we invite you to try to prioritize it now if possible. Otherwise, if you have the opportunity to plan this work for after the move is done, it would save some resources for builds that cannot/should not wait (CVEs and alike).
In addition, during the move there will be no staging environment. This will directly impact very few people, but from an infrastructure point of view it also means that we try to avoid as much as possible updating applications (for example deploying a new account system or new releases) during that time.
To give you some insight on dates*:
- The week of June 8th we will be moving services from one data-center to the other, so there will be ongoing outages as resources are moved from one data center to one with diminished capacity.
- We are hoping to continue rebuilding the infrastructure in Virgnia the week of June 22nd as shipped hardware arrives at the new facility.
- The target deadline to complete the entire move and return to normal capacity in Fedora Infrastructure is July 28th
A couple of final notes:
- right after the end of the move, there is a mass-rebuild scheduled, so you could use this as an opportunity to let releng do the builds for you if you prepare everything in dist-git.
- Please try to avoid pinging nirik or smooge in the coming weeks so they can focus on this delicate exercise, but if you run into them, I'm sure they will appreciate your support or/and some cookies on irc (nirik++ smooge++)!
- Please bare with us while we're working on the move as responses to tickets/requests will likely be slower than usual.
A list of the applications that will be impacted by the colo move is available at:
https://hackmd.io/hpYYJQRjQy-oHxUS7IonIA
Thanks in advance for your understanding and help,
Aoife
* All the dates are subject to changes, going from networking issues, to servers dying because of the move, to a world-wide pandemic changing the working conditions in the data-center, but these are current estimates.
Hello fellow java package maintainers!
We are planning to bump the JDK from java-1.8.0-openjdk to java-11-openjdk for F33. Please see
https://fedoraproject.org/wiki/Changes/Java11
Short Story:
* if you have some java package, be aware that we are bumping JDK in rawhide
* Ensure your package builds and runs fine with JDK11 (see the
https://copr.fedorainfracloud.org/coprs/jvanek/java11/builds/)
* there is special tooling ready for this, before mass rebuild is launched
** See https://fedoraproject.org/wiki/Changes/Java11#copr_preliminary_rebuild
* If you do not want Fedora rotten with JDK8 for ever, continue reading
Long Story:
We ran a preliminary mass rebuild of javastack in copr repo
https://copr.fedorainfracloud.org/coprs/jvanek/java11/builds/ (select "all" instead of "25" at the
bottom), on packages requiring java,javac, java-devel, maven-local, ant, ivy & comp for build. You
can see, the result was quite dramatic:
1225 total; attempted to rebuild
483 failed; from those 191 are trivial failures (but if you fix it, there is no guarantee real
troubles are not hidden behind that)
186 succeeded
556 orphans or dead or otherwise tragic so the build did not even start
I would kindly ask you to search yourself in this list: https://jvanek.fedorapeople.org/java11/people
If you are here, please check status of your package in https://jvanek.fedorapeople.org/java11/init
(pain text of https://copr.fedorainfracloud.org/coprs/jvanek/java11/builds)
* If your package is "succeeded", congratulations nothing to do, and just keep en eye on JDK bump
* If there is "failed" but contains "- -" then it is probably orphan. If you wish to resurrect it,
please ensure it runs against JDK11 (see lower)
* If there is "failed" but failed in "seconds", then those packages failed so quickly, that the
build was in initial phases. That usually mean that you build with source/target lower then 1.6
JDK11 supports 1.6 and up. We recommend to bump the source/target to 1.8, to allow existence of
compact 1.8 packages alongside main javastack. See
https://fedoraproject.org/wiki/Changes/Java11#Wrong_source.2Ftarget_version. Don't forget to
upstream the patch, or maybe it is enough to update to more fresh upstream release which supports
JDK11? it may happen, that after the fix, your build will fail in more terrible way (see below)
* If there is "failed", and its none of above, then your package simply failed. Very often the
scary error may be fixed by bump to latest upstream version. JDK 11 is out for several years.
Please, try to fix the package. Don't hesitate to ask on devel(a)fedoraproject.org or
java-devel(a)fedoraproject.org or directly to me jvanek(a)redhat.com. If you fix the fail, feel free to
share your fix, it may help others.
We are trying to gather the most common issues at
https://fedoraproject.org/wiki/Changes/Java11#common_issues_packagers_can_f… .
Feel free to enhance the page, or write us your case (possibly both with solution and without) so
we can add it here.
Debugging Your failures.
The copr repo we maintain, contains builds of java-11-openjdk as system JDK, javapackages-tools
honoring that, and java-1.8.0-openjdk as non system JDK. Also it contains successfully rebuilt
packages. You can directly use this copr repo in several ways.
* first glance on error. On https://copr.fedorainfracloud.org/coprs/jvanek/java11/builds/ find your
build (select "all" instead of "25" at the bottom),
** Click its number, select chroot (currently fedora-32-x86_64 ) and check the logs. Main log is
build.log.gz.
* anything you push to rawhide, will automatically rebuild here in f32 chroot (we have a JDK in
rawhide broken a bit currently)
** It is the best approach. If you can fix your package in rawhide directly, without breaking the
rawhide too much, go for it
** If yo need to experiment, I have a mock config for you (generated from copr-cli mock-config
jvanek/java11 fedora-32-x86_64) which you can copy to your /etc/mock and use -
https://jvanek.fedorapeople.org/java11/jvanek-java11-fedora-32-x86_64.cfg . Eg:
sudo cp downloaded-fedora-32-x86_64.cfg /etc/mock/jvanek-java11-fedora-32-x86_64.cfg
# change spec, bump sources, apply patches
fedpkg srpm
mock -r jvanek-java11-fedora-32-x86_64 *.src.rpm
Or any other packaging workflow you use, and you can use against the copr repo.
Thank you very much for your help, there are 500 failures, and 1000 java packagers, but only 2
active members of java sig. Without your help, the JDK bump will be very hard.
Thank You!
On behalf of Fedora java group
J.