mingw-qt (qt4)
by Thomas Sailer
I am planning to orphan mingw-qt.
Reasons:
- it fails to build on F28, presumably due to the __debug_install_post
hook not generating the debugsource lists properly
- releng/Till complains that the build log is now 3Gbytes long (due to
more elaborate compiler diagnostics)
Fixing this is more work than I'm willing to do.
Furthermore, the last released version of 4.8 is 3 years old, and we
have qt5 in mingw. Keeping qt4 alive seems like more work than it's worth...
Thomas
5 years, 10 months
Cfitsio soname bump
by Sergio Pascual
Hello, I'm going to build new cfitsio 3.450 in Rawhide. This involves a
soname bump. Notice that I plan to do the same in F28 (with a buildroot
override, etc) as cfitsio has security issues
https://bugzilla.redhat.com/show_bug.cgi?id=1570484
The list of dependencies I get are:
$ dnf --releasever rawhide repoquery --whatrequires cfitsio --alldeps --srpm
CCfits-0:2.5-7.fc29.src
astrometry-0:0.73-4.fc29.src
bes-0:3.17.4-7.fc29.src
cfitsio-0:3.430-1.fc29.src
cpl-0:7.0-8.fc29.src
gdal-0:2.2.4-2.fc29.src
healpix-0:3.31-10.fc29.src
indi-apogee-0:1.6.2-3.fc29.src
indi-gphoto-0:1.6.2-4.fc29.src
kst-0:2.0.8-20.fc29.src
kstars-1:2.9.3-2.fc29.src
libindi-0:1.6.2-3.fc29.src
luminance-hdr-0:2.5.1-11.fc29.src
nightview-0:0.3.3-27.fc29.src
perl-Astro-FITS-CFITSIO-0:1.11-7.fc29.src
phd2-0:2.6.5-1.fc29.src
pyfits-0:3.5-3.fc29.src
python-astropy-0:3.0.1-1.fc29.src
python-fitsio-0:0.9.11-5.fc29.src
python-healpy-0:1.11.0-4.fc29.src
python2-astropy-0:2.0.5-2.fc29.src
root-0:6.12.06-2.fc29.src
siril-0:0.9.8.3-3.fc29.src
skyviewer-0:1.0.1-14.fc29.src
ufraw-0:0.22-12.fc29.src
vips-0:8.6.2-4.fc29.src
wcslib-0:5.18-1.fc29.src
Regards
5 years, 10 months
F29 Self Contained Change: java-11-openjdk - next LTS OpenJDK release
and future main JDK in Fedora
by Jan Kurik
= Proposed Self Contained Change: java-11-openjdk - next LTS OpenJDK
release and future main JDK in Fedora =
https://fedoraproject.org/wiki/Changes/java-11-openjdk-TechPreview
Owner(s):
* Jiri Vanek <jvanek at redhat dot com>
OpenJDK have LTS release cadence of 2 years. JDK11, next LTS is to be
released September 2018. Next LTS is JDK15, expected in 2020. This
proposal, is proposing new package - java-11-openjdk, based on this
LTS OpenJDK 11, which will be tech preview of next Main JDK for fedora
(30?).
See same process with JDK8, current main JDK, and JDK7 before.
JDK8 tehc preview: https://fedoraproject.org/wiki/Features/Java8TechPreview
JDK8 made main JDK: https://fedoraproject.org/wiki/Changes/Java8
See announcement:
http://mail.openjdk.java.net/pipermail/discuss/2017-September/004281.html
See java SIG plans:
https://jvanek.fedorapeople.org/devconf/2018/changesInjavaReleaseProcess.pdf
== Detailed description ==
JDK11 is next major, LTS, release of Java platform. It is bringing
many cool improvements - http://openjdk.java.net/projects/jdk/11/ and
is landing to your Fedora. Where it will be maintained for f27 and
newer.
To understand JAva release process, See announcement:
http://mail.openjdk.java.net/pipermail/discuss/2017-September/004281.html
and See java SIG plans:
https://jvanek.fedorapeople.org/devconf/2018/changesInjavaReleaseProcess.pdf
. So this is package, containing exact LTS version of OpenJDK
You will always be allowed to install Used LTS in fedora build root,
alongside with latest STS via alternatives. Also JDK8 will be with us
for some time
The fate of JDK10 is about to be decided - it can be updated to JDK11
or obsoleted by java-11-openjdk. In all cases, it will be later
updated to JDK12. Also in all cases separate package will be created
for any LTS JDK - next is java-11-openjdk,
All those packages java-1.8.0-oepnjdk, java-openjdk and
java-11-openjdk will be installable in parallel. You can also have
installed several versiosn of java-openjdk installed next to each
other. They are in your /usr/lib/jvm/java-X-openjdk-v-r.a directory.
Where X is major - like 1.8.0, 9, 10, 11 or 12.
== Scope ==
* Proposal owners:
This is isolated change. The maintainers of OpenJDK in Fedora must
build the binaries, and keep them working. To keep jdk8 and jd10
installable in parallel.
* Other developers:
Should start to check theirs packages against JDK11, as it will
replace JDK8 sooner or later. This is still nothing official, and you
can get troubles when trying it with rpmbuild, as your dependencies
may (more likely will) pull JDK8 into build root. But you can try to
compile your sources against JDK10 to see how your upstream get
adapted to modules, and possibly start to upstream patches.
* Release engineering:
https://pagure.io/releng/issue/7527
* 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
JBoss EAP Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
5 years, 10 months
F29 System Wide Change: The tzdata transition to 'vanguard' format
by Jan Kurik
= Proposed System Wide Change: The tzdata transition to 'vanguard' format =
https://fedoraproject.org/wiki/Changes/TZDATA-VANGUARD
Owner(s):
* Patsy Franklin <pfrankli at redhat dot com>
As of tzdata-2018e, the upstream will now default to using the
'vanguard' data format including negative DST offsets. As a
fall-back, the 'rearguard' data format is still available on F28, F27
and F26.
== Detailed description ==
tzdata-2018e defaults to the 'vanguard' data format. This format
includes the POSIX compliant implementations of negative DST offsets
which have been an issue for both Java and ICU parsers. We plan to
transition to this default format in F29.
== Scope ==
* Proposal owners:
Implement the proposal.
* Other developers:
Developers need to ensure that their packages are able to correctly
parse and/or build with the new tzdata 'vanguard' format.
* Release engineering:
The tzdata maintainer will ensure that the package builds and passes
all tests on F29.
RelEng ticket: https://pagure.io/releng/issue/7510 #7510
* Policies and guidelines:
The policies and guidelines do not need to be updated.
* Trademark approval:
Not needed for this change
--
Jan Kuřík
JBoss EAP Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
5 years, 10 months
F29 System Wide Change: Move /usr/bin/python into a separate package
by Jan Kurik
= Proposed System Wide Change: Move /usr/bin/python into a separate package =
https://fedoraproject.org/wiki/Changes/Move_usr_bin_python_into_separate_...
Owner(s):
* Petr Viktorin <python-devel at lists dot fedoraproject dot org>
* Miro Hrončok <churchyard at fedoraproject dot org>
Reflecting the recent changes of
https://www.python.org/dev/peps/pep-0394/ PEP 394 -- ''The "python"
Command on Unix-Like Systems'', we are moving /usr/bin/python from the
python2 package into a separate package called
python-unversioned-command.
python2 will recommend this package.
This means Fedora users will get it automatically with python2, but
they might opt-out and remove it. In Fedora's build system, only
packages explicitly buildrequiring /usr/bin/python will get it.
This change obsoletes "Avoid /usr/bin/python in RPM build" change.
== Detailed description ==
=== Motivation ===
The meaning of the python command is ambiguous: it might mean either
Python 2 or Python 3, depending on context. The upstream
recommendation (PEP 394), which we try to follow in Fedora, is that
users -- not distros, and not sysadmins -- should be in control of the
python command.
Specifically, this means distro-packaged software should use python2
or python3 explicitly. Fedora's Python packaging guidelines have
suggested this since February 2015, and demand it since August 2017.
However, enforcing this guideline (which we will need to actually
allow users to safely change their python command) is problematic.
"Avoid /usr/bin/python in RPM_Build" change didn't work: most of the
packagers didn't change anything and too many packages still use the
python command.
Instead of developing custom hacks, we are now utilizing a more
systematic solution: If your package still needs /usr/bin/python to
build, explicitly BuildRequire it. If your package needs
/usr/bin/python to run, explicitly Require it. (In both cases, try to
use /usr/bin/python2 or /usr/bin/python3 instead if possible.)
We are also expecting some buildsystems (autools, cmake, etc.) to
automatically use /usr/bin/python2 if /usr/bin/python is unavailable,
so the problem might go away more naturally.
=== PEP 394 and how it is mapped to this change ===
Upstream PEP 394 -- The "python" Command on Unix-Like Systems
describes how the python command should behave. In Fedora, that's
/usr/bin/python. The PEP was recently updated to reflect upstream's
evolving views on the situation. Notable new information from the PEP
is:
In controlled environments aimed at expert users, where being explicit
is valued over user experience (for example, in test environments and
package build systems), distributions may choose to not provide the
python command even if python2 is available. (All software in such a
controlled environment must use python3 or python2 rather than python,
which means scripts that deliberately use python need to be modified
for such environments.)
We consider Fedora's build machinery a controlled environments aimed
at expert users.
=== What's changing ===
"Avoid /usr/bin/python in RPM_Build" change is reverted. Packages that
follow its Quick Opt-Out section (i.e. set
PYTHON_DISALLOW_AMBIGUOUS_VERSION) will be fixed by the owners of this
change.
/usr/bin/python remains a symbolic link to /usr/bin/python2. However,
it is moved to a new python-unversioned-command package (technically a
subpackage of python2). python2 package will only recommend
/usr/bin/python.
Packages that need /usr/bin/python to build will need to BuildRequire
it. Packages that need /usr/bin/python to be used by users will need
to Require it. In both cases, the packager should avoid the need and
only fallback to (Build)Requiring /usr/bin/python as a temporary
workaround.
The new package will virtually provide python, ensuring that dnf
install python will make the python command available.
=== Effect on automatic bytecompilation ===
When "No more automagic Python bytecompilation" change is done,
packages that byte-compile files outside of Python directories should
switch to the new behavior described in that change, and should not be
impacted by this change. However, if that change is delayed or
reverted, packagers that rely on the old behavior when byte compiling
files will need to set %__python to python2 or python3 explicitly.
=== Effect on %__python and other ambiguous RPM macros ===
Using ambiguous Python macros (%{__python}, %{python_sitelib}...) is
forbidden and your package will fail to build if you still use those
without redefining %__python. Either switch to explicitly versioned
macros (%{__python2}, %{python2_sitelib}, %{__python3}...) or set
__python to an explicit Python version.
== Scope ==
* Proposal owners:
** Split the packages as described in ''Detailed Description''.
** Fix packages that use PYTHON_DISALLOW_AMBIGUOUS_VERSION to
BuildRequire /usr/bin/python instead.
* Other developers:
** Maintainers of packages that use /usr/bin/python need to switch to
using /usr/bin/python3 or /usr/bin/python2 explicitly (with help from
''Proposal owners'' if needed).
*** While doing that, consider switching your package to Python 3
only, if the Python 2 bits are unused in Fedora. (This is not
necessarily required for this change, however it will make your
packaging job easier.)
*** If that can't be done in a timely manner, fallback to
(Build)Requiring /usr/bin/python as a temporary workaround.
* Release engineering:
** https://pagure.io/releng/issue/7511 #7511
** List of deliverables: N/A (not needed for this Change)
* Policies and guidelines:
** Already existing: "packages in Fedora ... MUST call the proper
executable for the needed python major version directly, either
/usr/bin/python2 or /usr/bin/python3 as appropriate" from
Packaging:Python#Multiple_Python_Runtimes..
* Trademark approval:
N/A (not needed for this Change)
--
Jan Kuřík
JBoss EAP Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
5 years, 10 months