Fedora 32 Self-Contained Change proposal: Provide OpenType Bitmap Fonts
by Ben Cotton
https://fedoraproject.org/wiki/Changes/ProvideOpenTypeBitmapFonts
== Summary ==
This proposal plans to provide some additional popular bitmap fonts in
OpenType format to use with pango.
By providing some bitmap fonts from BDF/PCF format to OpenType format,
applications like gnome-terminal can continue to use some bitmap fonts
with the pango 1.44 package.
== Owner ==
* Name: [[User:pwu| Peng Wu]]
* Email: pwu(a)redhat.com
* Name: [[User:tagoh| Akira Tagoh]]
* Email: tagoh(a)redhat.com
== Detailed Description ==
In Fedora 31, pango has been upgraded to 1.44, and switched to use the
HarfBuzz library instead of FreeType.
But HarfBuzz doesn't support bitmap fonts or Adobe Type 1 fonts.
In gnome-terminal, the bitmap fonts can't be used.
In order to use the bitmap fonts with pango 1.44,
we propose to provide some additional popular bitmap fonts in OpenType
format by using fonttosfnt tool.
The bitmap font in OpenType format will be contained in new sub package.
User can choose to install the bitmap font either in legacy format or
OpenType format from different sub packages.
We plan to provide 5-10 bitmap fonts in OpenType format in some packages.
The current font candidates are bitmap-lucida-typewriter-fonts,
terminus-fonts and ucs-miscfixed-font.
== Benefit to Fedora ==
Some popular bitmap fonts are used by many users.
After providing the bitmap fonts in OpenType format, users can
continue to use the bitmap fonts in gnome-terminal, etc.
== Scope ==
* Proposal owners: Fonts SIG
* Other developers: N/A (not a System Wide Change)
* Release engineering: [https://pagure.io/releng/issues/9130 Releng issue 9130]
* 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 ==
N/A (not a System Wide Change)
== User Experience ==
After converting the bitmap fonts, users will be able to use the
popular bitmap fonts again with pango 1.44 in gnome-terminal, etc.
The OpenType bitmap fonts should have the similar shape for each
glyph, compared with the original bitmap fonts.
== Dependencies ==
N/A (not a System Wide Change)
== Contingency Plan ==
* Contingency mechanism: N/A (not a System Wide Change)
* Contingency deadline: N/A (not a System Wide Change)
== Release Notes ==
In Fedora 32, we provide bitmap fonts with modern font format
(OpenType Bitmap Font) to use with gnome-terminal and other
applications which uses pango for font rendering.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
4 years, 3 months
Fedora 32 Self-Contained Change proposal: Additional buildroot to
test x86-64 micro-architecture update
by Ben Cotton
https://fedoraproject.org/wiki/Changes/Additional_buildroot_to_test_x86-6...
== Summary ==
Create a dedicated buildroot to test packages built with x86-64
micro-architecture update.
== Owner ==
* Name: [[User:bookwar| Aleksandra Fedorova]]
* Email: [mailto:alpha@bookwar.info alpha(a)bookwar.info]
* Name: [[User:fweimer| Florian Weimer]]
* Email: [mailto:fweimer@redhat.com fweimer(a)redhat.com]
== Detailed Description ==
Fedora currently uses the original K8 micro-architecture (without
3DNow! and other AMD-specific parts) as the baseline for its x86_64
architecture. This baseline dates back to 2003 and has not been
updated since. As a result, performance of Fedora is not as good as it
could be on current CPUs.
Changing the main Fedora baseline to new CPUs in place
[[Changes/x86-64 micro-architecture update|was rejected]] as the user
base for older machines is still large. But we’d like to unblock the
development and testing of this feature.
== Benefit to Fedora ==
* Allow development and verification of the CPU baseline update in
Fedora without disrupting users of Fedora on older machines.
* Collect real life data on performance improvements, which can help
making decision on the baseline update.
* As soon as feature is accepted by the community, there will be a
smooth process to update baseline in the main Fedora, as all packages
will be already verified and tested to work against it.
* Until the switch of the main x86_64 architecture, interested parties
can install systems from the updated buildroot for performance
experiments.
== Scope ==
* Proposal owners:
** define new disttag for the buildroot
** provide updated gcc package which implements the new compiler
flags. It is expected that the new baseline will be implemented in a
new GCC -march= option for convenience.
** provide update to rpm-config package which changes default compiler
options for the disttag
** setup automation so that for each build submitted to Fedora Rawhide
there is a build submitted to the additional buildroot. Result of the
build task will be posted to Fedora Messaging and consumed by
ResultsDB, so that it appears in Bodhi
** setup automation to run periodic partial composes (via ODCS)
without installation media to generate repositories with these
packages
** update packaging documentation to mention new disttag and how it can be used
** create landing page to describe the purpose and usages of the
buildroot in Fedora Wiki
* Other developers:
** None. The goal is to build exactly the same sources in the
different buildroot environment. Thus maintainers supposed to work on
Fedora Rawhide packages as usual. With maybe additional source of
bugreports coming from the build failures.
* Release engineering: [https://pagure.io/releng/issue/9154 #9154]
** New buildroot needs to be configured in koji
** New compose configuration
* Policies and guidelines:
[https://pagure.io/packaging-committee/issue/941 #941]
** There will be a new disttag for the alternative buildroot and a new
conditional in the rpm spec for it.
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
N/A (not a System Wide Change)
== How To Test ==
(Will be updated with more details later)
For each new package submitted to Fedora Rawhide there will be a CI
pipeline which builds the same sources in the additional buildroot.
Build result will be posted to ResultsDB and will be visible in Bodhi
on the update page.
There also is going to be partial compose with all packages built in
the alternative buildroot.
To test these packages one can add the repository from the compose and
run a dystro-sync.
== User Experience ==
The alternative buildroot is going to be used for development and
testing. There will be no impact on users.
== Dependencies ==
N/A (not a System Wide Change)
== Contingency Plan ==
The only impact the feature has on the current Fedora development
process is: there will be additional test result which shows up in
Fedora Rawhide gating. Thus there is no risk for Fedora release
process.
If feature is not completed by Fedora 32 release, it is going to be
shifted to Fedora 33 cycle or cancelled.
* Contingency mechanism: N/A (not a System Wide Change)
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? N/A (not a System Wide Change)
== Documentation ==
There will be a landing page on wiki with details on the purpose and
usage of this buildroot.
== Release Notes ==
Preparation work has started for updating Fedora baseline to new CPUs.
While it has no effect on the current release, there is a test
environment which can be used by anyone interested in this work.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
4 years, 3 months
Fedora 33 Self-Contained Change proposal: retire python34
by Ben Cotton
https://fedoraproject.org/wiki/Changes/RetirePython34
== Summary ==
The {{package|python34}} package will be retired without replacement
from [[Releases/33|Fedora 33]]. Python 3.4 has been End of Life since
March 2019 and was kept around only to test software targeting EPEL 6
and Debian 8 “Jessie”. The removal is aligned with EPEL 6 EOL and
happens after the EOL of Debian 8.
== Owner ==
* Name: [[User:Churchyard|Miro Hrončok]]
* Email: mhroncok(a)redhat.com
== Detailed Description ==
The {{package|python34}} package with the Python interpreter in
version 3.4 is kept in Fedora only to make it possible for Fedora
users to test their software against the Python version shipped in
EPEL 6 and EPEL 7. RHEL 7 now contains Python 3.6.
[https://wiki.debian.org/LTS Debian 8 “Jessie” is End of Life in
2020-06]. [[EPEL|The EPEL 6 End of Life is planned for 2020-11]]. This
roughly corresponds with the
[https://fedorapeople.org/groups/schedule/f-33/f-33-key-tasks.html
Fedora 33 release date]. Hence, we decided to retire (completely
remove) {{package|python34}} from Fedora 33, before it gets released.
== Benefit to Fedora ==
The maintenance of Python 3.4 was getting harder and harder every
year. The support for Python 3.4 has disappeared from pip and an older
version of pip has to be bundled in {{package|python34}}, while pip
bundles even more old libraries. Support from tox and virtualenv will
eventually disappear as well.
There is no direct benefit here, except that we don't want to maintain
it anymore and we don't think it's a good idea either.
Consider this change proposal a louder orphaning, except that we will
continue to maintain the package in older released and supported
Fedoras (31 and 32). If you wish to continue maintaining Python 3.4 in
Fedora, please [[SIGs/Python|speak to us]] first.
== Scope ==
* Proposal owners: Retire {{package|python34}}. Obsolete it from
{{package|fedora-obsolete-packages}} if it causes troubles on
upgrades. Make sure no Fedora package depends on it in any way (incl.
weak dependencies).
* Other developers: N/A (not a System Wide Change)
* Release engineering: 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)
== Upgrade/compatibility impact ==
The package will no longer be available from the repositories, but it
may remain on existing installations. If it causes troubles on
upgrade, it needs to be obsoleted.
== How To Test ==
N/A (not a System Wide Change)
== User Experience ==
No more Python 3.4 to test user software on.
== Dependencies ==
N/A (not a System Wide Change)
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?) N/A (not a
System Wide Change)
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? N/A (not a System Wide Change)
== Documentation ==
N/A (not a System Wide Change)
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
4 years, 3 months
Fedora 33 Self-Contained Change proposal: retire python26
by Ben Cotton
https://fedoraproject.org/wiki/Changes/RetirePython26
== Summary ==
The {{package|python26}} package will be retired without replacement
from [[Releases/33|Fedora 33]]. Python 2.6 has been End of Life since
October 2013 and was kept around only to test software targeting
RHEL/EPEL 6. The removal is aligned with EPEL 6 EOL.
== Owner ==
* Name: [[User:Churchyard|Miro Hrončok]]
* Email: mhroncok(a)redhat.com
== Detailed Description ==
The {{package|python26}} package with the Python interpreter in
version 2.6 is kept in Fedora only to make it possible for Fedora
users to test their software against the Python version shipped in
RHEL 6.
[[EPEL|The EPEL 6 End of Life is planned for 2020-11]]. This roughly
corresponds with the
[https://fedorapeople.org/groups/schedule/f-33/f-33-key-tasks.html
Fedora 33 release date]. Hence, we decided to retire (completely
remove) {{package|python26}} from Fedora 33, before it gets released.
== Benefit to Fedora ==
The maintenance of Python 2.6 was getting harder and harder every
year. The support for Python 2.6 has disappeared from virtualenv, tox.
{{package|python26}} cannot be built against the new OpenSSL versions,
etc.
There is no direct benefit here, except that we don't want to maintain
it anymore and we don't think it's a good idea either.
Consider this change proposal a louder orphaning, except that we will
continue to maintain the package in older released and supported
Fedoras (31 and 32). If you wish to continue maintaining Python 2.6 in
Fedora, please [[SIGs/Python|speak to us]] first.
== Scope ==
* Proposal owners: Retire {{package|python26}}. Obsolete it from
{{package|fedora-obsolete-packages}} if it causes troubles on
upgrades. Make sure no Fedora package depends on it in any way (incl.
weak dependencies).
* Other developers: N/A (not a System Wide Change)
* Release engineering: 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)
== Upgrade/compatibility impact ==
The package will no longer be available from the repositories, but it
may remain on existing installations. If it causes troubles on
upgrade, it needs to be obsoleted.
== How To Test ==
N/A (not a System Wide Change)
== User Experience ==
No more Python 2.6 to test user software on.
== Dependencies ==
N/A (not a System Wide Change)
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?) N/A (not a
System Wide Change)
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? N/A (not a System Wide Change)
== Documentation ==
N/A
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
4 years, 3 months
Orphaned packages looking for new maintainers
by Miro Hrončok
The following packages are orphaned and will be retired when they
are orphaned for six weeks, unless someone adopts them. If you know for sure
that the package should be retired, please do so now with a proper reason:
https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life
Note: If you received this mail directly you (co)maintain one of the affected
packages or a package that depends on one. Please adopt the affected package or
retire your depending package to avoid broken dependencies, otherwise your
package will be retired when the affected package gets retired.
Request package ownership via the *Take* button in he left column on
https://src.fedoraproject.org/rpms/<pkgname>
Full report available at:
https://churchyard.fedorapeople.org/orphans-2020-01-06.txt
grep it for your FAS username and follow the dependency chain.
Package (co)maintainers Status Change
================================================================================
MochiKit orphan 3 weeks ago
dzen2 bstinson, dcantrel, fale, 5 weeks ago
lupinix, orphan
golang-github-codahale- go-sig, orphan 2 weeks ago
aesnicheck
i3-ipc cicku, fale, gchamoul, 5 weeks ago
lupinix, mpreisle, orphan
ike-scan orphan, pwouters 3 weeks ago
infinispan gil, orphan 6 weeks ago
maven-ant-plugin mizdebsk, orphan 4 weeks ago
maven-docck-plugin mizdebsk, orphan 4 weeks ago
maven-ear-plugin orphan 4 weeks ago
mcollective-qpid-plugin orphan, tdawson 3 weeks ago
multithreadedtc orphan 4 weeks ago
nbtscan orphan 3 weeks ago
nesc cicku, orphan 4 weeks ago
ninvaders orphan 3 weeks ago
oyranos orphan 3 weeks ago
pscan orphan 3 weeks ago
pykka orphan 0 weeks ago
python-dockerpty lsm5, orphan, ttomecek 3 weeks ago
python-flask-classy orphan 5 weeks ago
python-flask-debugtoolbar orphan 5 weeks ago
python-fsmonitor orphan 5 weeks ago
python-mongoengine bowlofeggs, echevemaster, 5 weeks ago
orphan
python-virtkey orphan 3 weeks ago
qpid-proton orphan 2 weeks ago
rubygem-awesome_spawn jstribny, orphan 4 weeks ago
rubygem-bootstrap-sass orphan 4 weeks ago
rubygem-charlock_holmes orphan 4 weeks ago
rubygem-faker orphan 1 weeks ago
rubygem-omniauth orphan 3 weeks ago
rubygem-orm_adapter orphan 4 weeks ago
saxon dbhole, dchen, jjohnstn, 5 weeks ago
mbooth, orphan
shed orphan 3 weeks ago
sound-theme-acoustic orphan 1 weeks ago
swingx orphan 0 weeks ago
tmuxinator orphan 3 weeks ago
tudu orphan 1 weeks ago
vttest cicku, orphan 3 weeks ago
xml-stylebook mizdebsk, orphan 5 weeks ago
The following packages require above mentioned packages:
See https://churchyard.fedorapeople.org/orphans-2020-01-06.txt
Grep it for your username and follow the dependency chain.
Affected (co)maintainers
abompard: qpid-proton
arobinso: multithreadedtc
ausil: qpid-proton
bkabrda: qpid-proton
bowlofeggs: python-mongoengine, qpid-proton
bstinson: dzen2
cicku: i3-ipc, nesc, vttest
cqi: qpid-proton
cverna: qpid-proton
dbhole: saxon
dcantrel: dzen2
dchen: saxon
dgoodwin: qpid-proton
dmach: qpid-proton
dodji: qpid-proton
dridi: vttest
echevemaster: python-mongoengine
ellert: maven-docck-plugin
error: python-dockerpty
fab: vttest
fale: i3-ipc, dzen2
frixxon: qpid-proton
frostyx: qpid-proton
fujiwara: qpid-proton
gchamoul: i3-ipc
gil: infinispan
go-sig: golang-github-codahale-aesnicheck
halfie: qpid-proton
infra-sig: qpid-proton
ingvar: vttest
irina: qpid-proton
jamesturner246: saxon
jcline: qpid-proton
jjohnstn: saxon
jlieskov: qpid-proton
jortel: qpid-proton
jplesnik: qpid-proton
jsteffan: vttest
jstribny: rubygem-awesome_spawn
jvymazal: qpid-proton
kellin: qpid-proton
kevin: qpid-proton, vttest
kgiusti: qpid-proton
leamas: qpid-proton
lef: multithreadedtc
lkundrak: qpid-proton
lsedlar: qpid-proton
lsm5: python-dockerpty
luhliarik: vttest
lupinix: i3-ipc, dzen2
maxamillion: qpid-proton
mbooth: saxon
mdarade: qpid-proton
mhlavink: vttest
mikem: qpid-proton
mildew: qpid-proton
mizdebsk: xml-stylebook, maven-docck-plugin, maven-ant-plugin
mohanboddu: qpid-proton
mpreisle: i3-ipc
ngompa: qpid-proton
nim: qpid-proton
onosek: qpid-proton
orion: qpid-proton
pingou: qpid-proton
ppisar: qpid-proton
puiterwijk: qpid-proton
pwouters: ike-scan
qwan: qpid-proton
ralph: qpid-proton
romanofski: qpid-proton
rsroka: qpid-proton
ruben: vttest
santiago: qpid-proton
sinnykumari: qpid-proton
sochotni: qpid-proton
tagoh: qpid-proton
tdawson: qpid-proton, mcollective-qpid-plugin
tosykora: qpid-proton
tross: qpid-proton
ttomecek: python-dockerpty, qpid-proton
twaugh: qpid-proton
vrutkovs: qpid-proton
wwoods: qpid-proton
xaeth: vttest
xiubli: qpid-proton
--
The script creating this output is run and developed by Fedora
Release Engineering. Please report issues at its pagure instance:
https://pagure.io/releng/
The sources of this script can be found at:
https://pagure.io/releng/blob/master/f/scripts/find_unblocked_orphans.py
4 years, 3 months
List of long term FTBFS packages to be retired in February
by Miro Hrončok
Dear maintainers.
Based on the latest fail to build from source policy, the following packages
will be retired from Fedora 32 approximately one week before branching (February
2020).
Policy:
https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fai...
The packages in rawhide were not successfully built at least since Fedora 30.
This report is based on dist tags.
Packages collected via:
https://github.com/hroncok/fedora-report-ftbfs-retirements/blob/master/ft...
If you see a package that was built, please let me know.
If you see a package that should be exempted from the process, please let me
know and we can work together to get a FESCo approval for that.
If you see a package that can be rebuilt, please do so.
Package (co)maintainers Latest build
================================================================================
elasticsearch hubbitus, jvanek, lbazan, Fedora 24
zbyszek
expresso jamielinux, nodejs-sig, Fedora 28
patches
libocrdma ocrdma Fedora 27
nuvola-app-google-calendar martinkg Fedora 29
nuvola-app-groove martinkg Fedora 28
nuvola-app-logitech-media- martinkg Fedora 29
server
nuvola-app-plex martinkg Fedora 29
nuvola-app-soundcloud martinkg Fedora 29
nuvola-app-yandex-music martinkg Fedora 29
shim-unsigned-aarch64 pjones Fedora 28
shim-unsigned-x64 pjones Fedora 28
The following packages require above mentioned packages:
Depending on: expresso (1)
nodejs-chrono (maintained by: jamielinux, nodejs-sig, tomh)
nodejs-chrono-1.0.5-10.fc31.src requires npm(expresso) = 0.9.2
Affected (co)maintainers
hubbitus: elasticsearch
jamielinux: expresso
jvanek: elasticsearch
lbazan: elasticsearch
martinkg: nuvola-app-soundcloud, nuvola-app-logitech-media-server,
nuvola-app-yandex-music, nuvola-app-groove, nuvola-app-google-calendar,
nuvola-app-plex
nodejs-sig: expresso
ocrdma: libocrdma
patches: expresso
pjones: shim-unsigned-aarch64, shim-unsigned-x64
tomh: expresso
zbyszek: elasticsearch
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
4 years, 3 months
koji / bodhi issues status update
by Kevin Fenzi
As some of you may know, we have been having issues with koji and bodhi
over the holidays. :( koji would sometimes not tag builds or error them
with odd error messages and bodhi wasn't pushing updates.
I'm happy to report that the underlying issue seems to be fixed now.
We hopefully will have a more detailed root cause next week.
However, due to the koji issues builds were in a state where bodhi
ejected many of them from updates pushes. We are working on cleaning
up the state of those updates and there's no need for maintainers to do
anything with those updates at this time.
Once we get the ejected builds cleaned up we should be able to resume
normal bodhi updates pushes.
Thanks everyone for your patience on this issue!
kevin
4 years, 3 months
