F30 Self-Contained Change proposal: Ibus-typing-booster default for
Indian languages
by Ben Cotton
https://fedoraproject.org/wiki/Changes/Ibus_typing_booster_default_for_in...
== Summary ==
Make ibus-typing-booster the default input method for Indian languages.
== Owner ==
* Name: [[User:Mfabian|Mike Fabian]]
* Email: <mfabian(a)redhat.com>
== Detailed Description ==
Currently, ibus-m17n is the default input method for Indian languages
in Fedora. ibus-typing-booster uses the same libm17n used by
ibus-m17n to support input for Indian languages and thus it can do
everything ibus-m17n can do. But on top of that, ibus-typing-booster
supports predictive input by remembering user input and by using words
from dictionaries. Therefore, ibus-typing-booster is a more useful input method
for these languages.
== Benefit to Fedora ==
A better input experience for users of Indian languages.
== Scope ==
* Proposal owners:
The langtable package has data about default input methods. Change this data.
But the data in langtable is currently apparently not used by
gnome-initial setup.
The list of default input methods used by gnome-initial-setup us stored in
<pre>
libgnome-desktop/default-input-sources.h
</pre>
Currently there are the following default input methods for the Indian locales:
<pre>
static DefaultInputSource default_input_sources[] =
{
...
{ "as_IN", "ibus", "m17n:as:phonetic" },
...
{ "bn_IN", "ibus", "m17n:bn:inscript" },
...
{ "gu_IN", "ibus", "m17n:gu:inscript" },
...
{ "hi_IN", "ibus", "m17n:hi:inscript" },
...
{ "kn_IN", "ibus", "m17n:kn:kgp" },
...
{ "mai_IN", "ibus", "m17n:mai:inscript" },
...
{ "ml_IN", "ibus", "m17n:ml:inscript" },
...
{ "mr_IN", "ibus", "m17n:mr:inscript" },
...
{ "or_IN", "ibus", "m17n:or:inscript" },
...
{ "pa_IN", "ibus", "m17n:pa:inscript" },
...
{ "sd_IN", "ibus", "m17n:sd:inscript" },
...
{ "ta_IN", "ibus", "m17n:ta:tamil99" },
...
{ "te_IN", "ibus", "m17n:te:inscript" },
...
{ "ur_IN", "ibus", "m17n:ur:phonetic" },
...
</pre>
Here, "m17n:as:phonetic" would need to be replaced with "typing-booster".
And similar for the other Indian languages.
ibus-typing-booster selects the default input method to use
from the locale when it is first started. For the above Indian
locales ibus-typing-booster >= 2.4.2 has the same default
m17n input methods as libgnome-desktop/default-input-sources.h,
except that it always uses inscript2 instead of inscript by default.
* Other developers: 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 ==
Nothing should happen when upgrading from a previous version of Fedora.
If a user used ibus-m17n before the upgrade, he will still use it
after the upgrade.
This change proposal only changes the default input method for an
Indian language
for new installs or new user accounts.
== How To Test ==
Do a new installation of Fedora 30 in an Indian language. Log into Gnome.
See what input method is suggested by default by gnome-initial-setup.
== User Experience ==
Easier input of Indian language because of predictive input.
== Dependencies ==
gnome-initial-setup
== Contingency Plan ==
* Contingency mechanism: Leave the default input methods as they are
now and move the change to Fedora 31
* Contingency deadline: Fedora 30 Beta release
* Blocks release? No.
* Blocks product? No.
--
Ben Cotton
Fedora Program Manager
TZ=America/Indiana/Indianapolis
5 years, 2 months
F30 Self-Contained Change proposal: libcrypt.so.1 (compatibility
library for POSIX): Let encrypt, encrypt_r, setkey, setkey_r, and fcrypt
return ENOSYS instead of performing any real operation
by Ben Cotton
Remove real functionality from encrypt, encrypt_r, setkey, setkey_r,
and fcrypt from the libxcrypt.so.1 compatibility library and let those
functions set "errno" to "ENOSYS" when invoked.
== Owner ==
* Name: [[User:besser82 | Björn Esser]] <besser82(a)fedoraproject.org>
== Detailed Description ==
In [[Changes/FullyRemoveDeprecatedAndUnsafeFunctionsFromLibcrypt | the
system-wide change: "Fully remove deprecated and unsafe functions from
libcrypt"]] we propose to remove the named functions from the system
default so-version of the crypt library, which is a pre-requirement
for this change. It basically is a follow-up announcing to remove the
real functionality from those functions in the POSIX-compatibility
version of the crypt library as well, and replace them with fully
POSIX-compilant stubs, that properly indicate those functions are not
supported.
This change was basically filed, because it may require additional
documentation apart from the system-wide change, that is a
pre-requirement for this one.
== Benefit to Fedora ==
Third-party applications, which still use / require these unsafe
functions cannot use them anymore, which is the key benefit of this
change for our users.
== Scope ==
* Proposal owners: Implement the needed changes in the
libxcrypt-compat package.
* Other developers: N/A (not a System Wide Change)
* Release engineering: N/A, as this is a follow-up of an already
evaluated 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 ==
No impact, as nothing in the distribution uses those functions.
Third-party applications that are distributed in pre-compiled / binary
form only, may have a reduced set of features. Since POSIX explicitly
states those functions shall set "errno" to "ENOSYS", if the
functionality is not available nor implemented, third-party
application that start to malfunction are broken by design.
== Dependencies ==
N/A (not a System Wide Change)
== Contingency Plan ==
Revert the change and rebuild libxcrypt.
== Documentation ==
The version of the libcrypt.so.1 library included with Fedora 30 for
POSIX-compatibility has entirely removed the functionality of the
encrypt, encrypt_r, setkey, setkey_r, and fcrypt functions, while
keeping fully binary compatibility with existing (third-party)
applications possibly still using those funtions. If such an
application attemps to call one of these functions, the corresponding
function will indicate that it is not supported by the system in a
POSIX-compliant way.
All existing binary executables linked against glibc's libcrypt should
work unmodified with this version of the libcrypt.so.1 library
supplied by the libxcrypt-compat package.
== Release Notes ==
See the paragraph about documentation above.
--
Ben Cotton
Fedora Program Manager
TZ=America/Indiana/Indianapolis
5 years, 2 months
F30 System-Wide Change proposal (update): DNF Better Counting (was:
DNF UUID)
by Ben Cotton
This is an updated version of the DNF UUID proposal based on feedback
received on the mailing list.
https://fedoraproject.org/wiki/Changes/DNF_Better_Counting
== Summary ==
Right now, we estimate installed Fedora systems by counting unique IP
addresses which show up in our updates mirror statistics. We need
better data than that. There are some proposals for more complicated
systems, but a quick thing we can
This is an update of a
[https://fedoraproject.org/w/index.php?title=Changes/DNF_UUID&oldid=531449
previous proposal] to use a UUID to distinguish unique systems, as
openSUSE does (see https://metrics.opensuse.org/). See also
[https://lists.fedoraproject.org/archives/list/council-discuss@lists.fedor...
this previous Fedora Council discussion] and
[https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
this devel list thread].
== Owner ==
* Name: [[User:mattdm|Matthew Miller]]
* Email: mattdm
== Detailed Description ==
=== The problem ===
* A. Currently, we can only count Fedora OS use by observing IP
addresses. This is subject to undercounting due to NAT — and to
overcounting due to short DHCP leases and laptops moving between work
or school and home or coffee shop.
* B. We can count what releases are observed, but we can’t distinguish variants.
* C. We can’t count quickly because various logs are copied back to a
central server and data is not consistent for several days.
=== Constraints ===
* The Fedora community cares about privacy and is adverse to tracking
measures. We don't want to track; just count.
* For this reason, we don’t want to use any identifier like
/etc/machine-id which may be used for other purposes — or in fact any
UUID at all
* And, also for that reason, there needs to be a relatively easy way to opt out.
* This needs to work with Yum/DNF, MicroDNF, PackageKit, Cockpit,
rpm-ostree, GNOME Software, Muon, and software update mechanisms used
in other spins.
* We need to be able to distinguish between short-lived instances
(like temporary containers or test machines) and actual installations.
=== Non-Goals ===
* We don’t want to track users, just count systems.
* Except for distinguishing temporary installations from “real” use,
we don’t need to track systems over time. We just want a daily or
weekly moment-in-time count.
* Being able to see how systems are upgraded over time might be
interesting but isn’t as important as privacy concerns.
== Proposal ==
# Add VARIANT_ID (see [[Changes/Label Our Variants]]) to string
reported to when metadata is requested from fedora update servers
# Current requests include machine architecture and Fedora OS version
as part of the path; we may want to also put those in a standard
format for easy processing (implementation detail)
# Add a new "countme" variable. This variable will:
#* Start as a "true" value,
#* Reset to a "false" value the first time the client successfully
makes a request to Fedora mirror servers, and
#* Be reset to a "true" value after seven days.
This way, rather than filtering by unique IP addresses, we can count
only the "true" requests, so we count each machine once — but no more
than once.
==== Options for "true" values ====
Rather than a simple boolean, we'd like the "countme" variable to act
as an increment-counter. That is, it would be "1" the first week, "2"
the second week, "3" the third week, and so on. This will let us sort
out short-lived test or CI infrastructure machines and get a better
picture of how systems are used over time, without tracking individual
systems. Optionally, we could have a cap on the maximum value to
mitigate risk of uniqueness for systems which have been running for a
very long time (it may be that there are only a few systems running
for exactly 327 weeks, for example). As the supported lifetime of a
Fedora release is about 30 months, a logical cutoff would be around 60
weeks — the counter could go from "59" to "old".
== Benefit to Fedora ==
* Better metrics overall
* Public stats page updated automatically
* Better knowledge of relative use of different variants
* Insight into Fedora's use in short-lived test systems and temporary
containers vs. longer-term installations
== Scope ==
* Proposal owners: work with DNF team and infrastructure to implement
the countme feature and corresponding backend data collection
* DNF team: feature work
* Maintainers of other package management tools: make sure feature
works in these cases as well
* Other developers: Spin maintainers should make sure that VARIANT_ID
is being set in /etc/os-release
* Release engineering: may need changes to fedora-repos package
** List of deliverables: affects all deliverables
* Policies and guidelines: none
* Trademark approval: none
== Upgrade/compatibility impact ==
Older versions will not have the counting enabled; we will keep
collecting stats in the traditional way for those systems.
== How To Test ==
Once the system is in place, we will see data collected.
== User Experience ==
User experience will not change. Users who wish to opt out of counting
will have an easy way to do so.
== Dependencies ==
Package managers.
== Contingency Plan ==
* Contingency mechanism: continue counting the old way
* Contingency deadline: does not block release; we can ship with the
feature incomplete, although it would certainly be most useful to have
it available at GA
* Blocks release? No
* Blocks product? No
== Documentation ==
Release notes need to be written, and documentation describing how to opt out.
== Release Notes ==
This needs to be written but depends on exact implementation.
--
Ben Cotton
Fedora Program Manager
TZ=America/Indiana/Indianapolis
5 years, 2 months
Orphaned packages to be retired
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
I plan to retire packages that were already announced 3 times next Monday.
Unorphan/unretire packages at https://pagure.io/releng/issues
(I still cannot unorphan packages, but rest assured that I monitor the tracker
and I'm not retiring packages that have open request for unorphaning.)
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.
Remarks: Some packages got retired already but are not yet blocked. There are
already retired packages in this list (namely the golang packages and lzma).
Also: Some packages are falsely reported as orphaned for 60+ weeks. The issue
was reported and I won't retire them sooner than after real 6 weeks. Sorry about
that.
Package (co)maintainers Status Change
================================================================================
RunSnakeRun orphan 0 weeks ago
autotrash frafra, orphan, robyduck 2 weeks ago
bluecove orphan 6 weeks ago
bouml orphan 3 weeks ago
bouml-doc 0 weeks ago
dnsyo codeblock, orphan 0 weeks ago
ecryptfs-simple orphan 4 weeks ago
fasd orphan 2 weeks ago
golang-github- go-sig, jchaloup, orphan 11 weeks ago
AudriusButkevicius-kcp-go
golang-github- go-sig, orphan 11 weeks ago
AudriusButkevicius-pfilter
golang-github-calmh-luhn go-sig, jchaloup, orphan 11 weeks ago
golang-github-ccding-go-stun go-sig, jchaloup, orphan 11 weeks ago
golang-github-cznic-b go-sig, jchaloup, orphan 11 weeks ago
golang-github-cznic-fileutil go-sig, jchaloup, orphan 11 weeks ago
golang-github-cznic-golex go-sig, jchaloup, orphan 11 weeks ago
golang-github-cznic-internal go-sig, jchaloup, orphan 11 weeks ago
golang-github-cznic-lex go-sig, jchaloup, orphan 11 weeks ago
golang-github-cznic-lexer go-sig, jchaloup, orphan 11 weeks ago
golang-github-cznic-lldb go-sig, jchaloup, orphan 11 weeks ago
golang-github-cznic-mathutil go-sig, jchaloup, orphan 11 weeks ago
golang-github-cznic-ql go-sig, jchaloup, orphan 11 weeks ago
golang-github-cznic-sortutil go-sig, jchaloup, orphan 11 weeks ago
golang-github-cznic-strutil go-sig, jchaloup, orphan 11 weeks ago
golang-github-cznic-zappy go-sig, jchaloup, orphan 11 weeks ago
golang-github-edsrzf-mmap-go go-sig, jchaloup, orphan 11 weeks ago
golang-github-klauspost- go-sig, jchaloup, orphan 11 weeks ago
reedsolomon
golang-github-remyoudompheng- go-sig, jchaloup, orphan 11 weeks ago
bigfft
golang-github-templexxx-cpufeat go-sig, jchaloup, orphan 11 weeks ago
golang-github-templexxx- go-sig, jchaloup, orphan 11 weeks ago
reedsolomon
golang-github-templexxx-xor go-sig, jchaloup, orphan 11 weeks ago
golang-github-tjfoc-gmsm go-sig, jchaloup, orphan 11 weeks ago
golang-github-xtaci-kcp-go go-sig, jchaloup, orphan 11 weeks ago
golang-github-xtaci-smux go-sig, jchaloup, orphan 11 weeks ago
golang-github-zillode-notify go-sig, orphan 11 weeks ago
gossip orphan 13 weeks ago
hdapsd orphan 7 weeks ago
hoard orphan 27 weeks ago
jlibrtp orphan 4 weeks ago
jmake orphan 4 weeks ago
libgltf orphan 5 weeks ago
lzma cicku, fale, mjakubicek, 65 weeks ago
orphan
maven-downloader orphan 13 weeks ago
maven-jsf-plugin orphan 13 weeks ago
maven-jxr akurtakov, orphan 13 weeks ago
nuvola-app-8tracks orphan 12 weeks ago
nuvola-app-deezer orphan 12 weeks ago
nuvola-app-google-play-music orphan 12 weeks ago
nuvola-app-jango orphan 12 weeks ago
nuvola-app-mixcloud orphan 12 weeks ago
openid4java-team orphan 13 weeks ago
parprouted orphan, roma 7 weeks ago
pcapfix cicku, orphan 7 weeks ago
pg_journal orphan, pkubat 7 weeks ago
php-ZendFramework heffer, orphan, remi 6 weeks ago
port-allocator-maven-plugin galileo, orphan 13 weeks ago
python-adns orphan, rvokal 5 weeks ago
python-ansible-tower-cli fale, orphan 7 weeks ago
python-ceilometermiddleware orphan 66 weeks ago
python-cookies adamwill, orphan 2 weeks ago
python-gnocchiclient orphan 75 weeks ago
python-kafka orphan 75 weeks ago
python-pankoclient orphan 75 weeks ago
python-parsley ishcherb, lbazan, orphan 2 weeks ago
python-pytimeparse orphan 75 weeks ago
python-pyuv orphan 7 weeks ago
python-ripe-atlas-cousteau orphan 2 weeks ago
python-ripe-atlas-sagan orphan 2 weeks ago
python-socketIO-client orphan 2 weeks ago
python-softlayer orphan 7 weeks ago
python-txsocksx lbazan, orphan 2 weeks ago
python-xhtml2pdf orphan 5 weeks ago
ratproxy orphan 7 weeks ago
ripe-atlas-tools orphan 2 weeks ago
scite orphan 6 weeks ago
supernova orphan 5 weeks ago
takari-local-repository galileo, orphan 13 weeks ago
tinyca2 orphan, pwouters 6 weeks ago
tristripper orphan 4 weeks ago
unp mstuchli, orphan, python-sig 0 weeks ago
wifi-radar blackfile, orphan 2 weeks ago
The following packages require above mentioned packages:
Depending on: golang-github-cznic-fileutil (4), status change: 2018-10-24 (11
weeks ago)
golang-github-cznic-internal (maintained by: go-sig, jchaloup, orphan)
golang-github-cznic-internal-1.0.0-9.20180831git4747030.fc30.src requires
golang(github.com/cznic/fileutil) = 0-0.11.20180831git6a051e7.fc30
golang-github-cznic-lex (maintained by: go-sig, jchaloup, orphan)
golang-github-cznic-lex-0-0.8.20180831git68050f5.fc30.src requires
golang(github.com/cznic/fileutil) = 0-0.11.20180831git6a051e7.fc30
golang-github-cznic-lexer (maintained by: go-sig, jchaloup, orphan)
golang-github-cznic-lexer-0-0.8.20180831git52ae786.fc30.src requires
golang(github.com/cznic/fileutil) = 0-0.11.20180831git6a051e7.fc30
golang-github-cznic-lldb (maintained by: go-sig, jchaloup, orphan)
golang-github-cznic-lldb-1.1.0-8.fc30.src requires
golang(github.com/cznic/fileutil) = 0-0.11.20180831git6a051e7.fc30
Depending on: golang-github-cznic-mathutil (4), status change: 2018-10-24 (11
weeks ago)
golang-github-cznic-b (maintained by: go-sig, jchaloup, orphan)
golang-github-cznic-b-0-0.9.20180831git35e9bbe.fc30.src requires
golang(github.com/cznic/mathutil) = 0-0.15.20180831gitca4c9f2.fc30
golang-github-cznic-fileutil (maintained by: go-sig, jchaloup, orphan)
golang-github-cznic-fileutil-0-0.11.20180831git6a051e7.fc30.src requires
golang(github.com/cznic/mathutil) = 0-0.15.20180831gitca4c9f2.fc30
golang-github-cznic-sortutil (maintained by: go-sig, jchaloup, orphan)
golang-github-cznic-sortutil-0-0.8.20180831git4c73428.fc30.src requires
golang(github.com/cznic/mathutil) = 0-0.15.20180831gitca4c9f2.fc30
golang-github-cznic-strutil (maintained by: go-sig, jchaloup, orphan)
golang-github-cznic-strutil-0-0.9.20180831git529a34b.fc30.src requires
golang(github.com/cznic/mathutil) = 0-0.15.20180831gitca4c9f2.fc30
Depending on: golang-github-klauspost-reedsolomon (2), status change: 2018-10-24
(11 weeks ago)
golang-github-AudriusButkevicius-kcp-go (maintained by: go-sig, jchaloup, orphan)
golang-github-AudriusButkevicius-kcp-go-0-0.8.20171227git5d7d1a8.fc30.src
requires golang(github.com/klauspost/reedsolomon) = 1.6-6.20180704git925cb01.fc30
golang-github-xtaci-kcp-go (maintained by: go-sig, jchaloup, orphan)
golang-github-xtaci-kcp-go-4.3.1-2.fc30.src requires
golang(github.com/klauspost/reedsolomon) = 1.6-6.20180704git925cb01.fc30
Depending on: golang-github-templexxx-cpufeat (2), status change: 2018-10-22 (11
weeks ago)
golang-github-templexxx-reedsolomon (maintained by: go-sig, jchaloup, orphan)
golang-github-templexxx-reedsolomon-0.1.1-4.fc30.src requires
golang(github.com/templexxx/cpufeat) = 0-0.4.20180724gitcef66df.fc30
golang-github-templexxx-xor (maintained by: go-sig, jchaloup, orphan)
golang-github-templexxx-xor-0.1.2-4.fc30.src requires
golang(github.com/templexxx/cpufeat) = 0-0.4.20180724gitcef66df.fc30
Depending on: php-ZendFramework (2), status change: 2018-12-01 (6 weeks ago)
ganglia (maintained by: georgiou, ggillies, noodles, terjeros)
ganglia-web-3.7.2-23.fc29.i686 requires php-ZendFramework = 1.12.20-5.fc29
webacula (maintained by: kanarip, tim4dev)
webacula-5.0.3-13.fc29.noarch requires php-ZendFramework = 1.12.20-5.fc29
Depending on: python-adns (1), status change: 2018-12-06 (5 weeks ago)
transmission-remote-cli (maintained by: satyak)
transmission-remote-cli-1.7.0-9.fc29.noarch requires python2-adns = 1.2.1-23.fc28
Depending on: python-cookies (1), status change: 2018-12-29 (2 weeks ago)
python-responses (maintained by: athoscr)
python-responses-0.9.0-5.fc30.src requires python3-cookies = 2.2.1-13.fc29
python3-responses-0.9.0-5.fc30.noarch requires python3.7dist(cookies) = 2.2.1
Depending on: python-kafka (1), status change: 2017-08-04 (75 weeks ago)
python-oslo-messaging (maintained by: apevec, gchamoul, markmc, ndipanov)
python-oslo-messaging-5.35.1-1.fc30.src requires python2-kafka = 1.4.3-1.fc29,
python3-kafka = 1.4.3-1.fc29
python2-oslo-messaging-tests-5.35.1-1.fc30.noarch requires python2-kafka =
1.4.3-1.fc29
python3-oslo-messaging-tests-5.35.1-1.fc30.noarch requires python3-kafka =
1.4.3-1.fc29
Depending on: python-pytimeparse (1), status change: 2017-08-04 (75 weeks ago)
python-agate (maintained by: jujens)
python-agate-1.6.1-4.fc30.src requires python3dist(pytimeparse) = 1.1.5
python3-agate-1.6.1-4.fc30.noarch requires python3.7dist(pytimeparse) = 1.1.5
Depending on: python-socketIO-client (1), status change: 2018-12-28 (2 weeks ago)
python-ripe-atlas-cousteau (maintained by: orphan)
python-ripe-atlas-cousteau-1.3-9.fc30.src requires python3-socketIO-client =
0.7.2-3.fc30
Depending on: python-txsocksx (1), status change: 2018-12-26 (2 weeks ago)
torbrowser-launcher (maintained by: limb, pjp)
torbrowser-launcher-0.3.1-3.fc30.noarch requires python2-txsocksx =
1.15.0.2-9.fc29
Affected (co)maintainers
adamwill: python-cookies
akurtakov: maven-jxr
apevec: python-kafka
athoscr: python-cookies
blackfile: wifi-radar
cicku: lzma, pcapfix
codeblock: dnsyo
fale: lzma, python-ansible-tower-cli
frafra: autotrash
galileo: port-allocator-maven-plugin, takari-local-repository
gchamoul: python-kafka
georgiou: php-ZendFramework
ggillies: php-ZendFramework
go-sig: golang-github-cznic-fileutil, golang-github-AudriusButkevicius-pfilter,
golang-github-calmh-luhn, golang-github-cznic-lexer, golang-github-cznic-ql,
golang-github-remyoudompheng-bigfft, golang-github-xtaci-kcp-go,
golang-github-cznic-internal, golang-github-templexxx-xor,
golang-github-cznic-mathutil, golang-github-cznic-b, golang-github-cznic-lldb,
golang-github-AudriusButkevicius-kcp-go, golang-github-ccding-go-stun,
golang-github-cznic-golex, golang-github-cznic-sortutil,
golang-github-zillode-notify, golang-github-xtaci-smux,
golang-github-edsrzf-mmap-go, golang-github-templexxx-reedsolomon,
golang-github-templexxx-cpufeat, golang-github-cznic-strutil,
golang-github-klauspost-reedsolomon, golang-github-cznic-lex,
golang-github-tjfoc-gmsm, golang-github-cznic-zappy
heffer: php-ZendFramework
ishcherb: python-parsley
jchaloup: golang-github-cznic-fileutil, golang-github-calmh-luhn,
golang-github-cznic-lexer, golang-github-cznic-ql,
golang-github-remyoudompheng-bigfft, golang-github-xtaci-kcp-go,
golang-github-cznic-internal, golang-github-templexxx-xor,
golang-github-cznic-mathutil, golang-github-cznic-b, golang-github-cznic-lldb,
golang-github-AudriusButkevicius-kcp-go, golang-github-ccding-go-stun,
golang-github-cznic-golex, golang-github-cznic-sortutil,
golang-github-xtaci-smux, golang-github-edsrzf-mmap-go,
golang-github-templexxx-reedsolomon, golang-github-templexxx-cpufeat,
golang-github-cznic-strutil, golang-github-klauspost-reedsolomon,
golang-github-cznic-lex, golang-github-tjfoc-gmsm, golang-github-cznic-zappy
jujens: python-pytimeparse
kanarip: php-ZendFramework
lbazan: python-txsocksx, python-parsley
limb: python-txsocksx
markmc: python-kafka
mjakubicek: lzma
mstuchli: unp
ndipanov: python-kafka
noodles: php-ZendFramework
pjp: python-txsocksx
pkubat: pg_journal
pwouters: tinyca2
python-sig: unp
remi: php-ZendFramework
robyduck: autotrash
roma: parprouted
rvokal: python-adns
satyak: python-adns
terjeros: php-ZendFramework
tim4dev: php-ZendFramework
Orphans (80): RunSnakeRun autotrash bluecove bouml bouml-doc dnsyo
ecryptfs-simple fasd golang-github-AudriusButkevicius-kcp-go
golang-github-AudriusButkevicius-pfilter golang-github-calmh-luhn
golang-github-ccding-go-stun golang-github-cznic-b
golang-github-cznic-fileutil golang-github-cznic-golex
golang-github-cznic-internal golang-github-cznic-lex
golang-github-cznic-lexer golang-github-cznic-lldb
golang-github-cznic-mathutil golang-github-cznic-ql
golang-github-cznic-sortutil golang-github-cznic-strutil
golang-github-cznic-zappy golang-github-edsrzf-mmap-go
golang-github-klauspost-reedsolomon
golang-github-remyoudompheng-bigfft
golang-github-templexxx-cpufeat
golang-github-templexxx-reedsolomon golang-github-templexxx-xor
golang-github-tjfoc-gmsm golang-github-xtaci-kcp-go
golang-github-xtaci-smux golang-github-zillode-notify gossip
hdapsd hoard jlibrtp jmake libgltf lzma maven-downloader
maven-jsf-plugin maven-jxr nuvola-app-8tracks nuvola-app-deezer
nuvola-app-google-play-music nuvola-app-jango nuvola-app-mixcloud
openid4java-team parprouted pcapfix pg_journal php-ZendFramework
port-allocator-maven-plugin python-adns python-ansible-tower-cli
python-ceilometermiddleware python-cookies python-gnocchiclient
python-kafka python-pankoclient python-parsley python-pytimeparse
python-pyuv python-ripe-atlas-cousteau python-ripe-atlas-sagan
python-socketIO-client python-softlayer python-txsocksx
python-xhtml2pdf ratproxy ripe-atlas-tools scite supernova
takari-local-repository tinyca2 tristripper unp wifi-radar
Orphans (dependend on) (11): golang-github-cznic-fileutil
golang-github-cznic-mathutil golang-github-klauspost-reedsolomon
golang-github-templexxx-cpufeat php-ZendFramework python-adns
python-cookies python-kafka python-pytimeparse
python-socketIO-client python-txsocksx
Orphans (rawhide) for at least 6 weeks (dependend on) (7):
golang-github-cznic-fileutil golang-github-cznic-mathutil
golang-github-klauspost-reedsolomon
golang-github-templexxx-cpufeat php-ZendFramework python-kafka
python-pytimeparse
Orphans (rawhide) (not depended on) (69): RunSnakeRun autotrash
bluecove bouml bouml-doc dnsyo ecryptfs-simple fasd
golang-github-AudriusButkevicius-kcp-go
golang-github-AudriusButkevicius-pfilter golang-github-calmh-luhn
golang-github-ccding-go-stun golang-github-cznic-b
golang-github-cznic-golex golang-github-cznic-internal
golang-github-cznic-lex golang-github-cznic-lexer
golang-github-cznic-lldb golang-github-cznic-ql
golang-github-cznic-sortutil golang-github-cznic-strutil
golang-github-cznic-zappy golang-github-edsrzf-mmap-go
golang-github-remyoudompheng-bigfft
golang-github-templexxx-reedsolomon golang-github-templexxx-xor
golang-github-tjfoc-gmsm golang-github-xtaci-kcp-go
golang-github-xtaci-smux golang-github-zillode-notify gossip
hdapsd hoard jlibrtp jmake libgltf lzma maven-downloader
maven-jsf-plugin maven-jxr nuvola-app-8tracks nuvola-app-deezer
nuvola-app-google-play-music nuvola-app-jango nuvola-app-mixcloud
openid4java-team parprouted pcapfix pg_journal
port-allocator-maven-plugin python-ansible-tower-cli
python-ceilometermiddleware python-gnocchiclient
python-pankoclient python-parsley python-pyuv
python-ripe-atlas-cousteau python-ripe-atlas-sagan
python-softlayer python-xhtml2pdf ratproxy ripe-atlas-tools scite
supernova takari-local-repository tinyca2 tristripper unp
wifi-radar
Orphans (rawhide) for at least 6 weeks (not dependend on) (50):
bluecove golang-github-AudriusButkevicius-kcp-go
golang-github-AudriusButkevicius-pfilter golang-github-calmh-luhn
golang-github-ccding-go-stun golang-github-cznic-b
golang-github-cznic-golex golang-github-cznic-internal
golang-github-cznic-lex golang-github-cznic-lexer
golang-github-cznic-lldb golang-github-cznic-ql
golang-github-cznic-sortutil golang-github-cznic-strutil
golang-github-cznic-zappy golang-github-edsrzf-mmap-go
golang-github-remyoudompheng-bigfft
golang-github-templexxx-reedsolomon golang-github-templexxx-xor
golang-github-tjfoc-gmsm golang-github-xtaci-kcp-go
golang-github-xtaci-smux golang-github-zillode-notify gossip
hdapsd hoard lzma maven-downloader maven-jsf-plugin maven-jxr
nuvola-app-8tracks nuvola-app-deezer nuvola-app-google-play-music
nuvola-app-jango nuvola-app-mixcloud openid4java-team parprouted
pcapfix pg_journal port-allocator-maven-plugin
python-ansible-tower-cli python-ceilometermiddleware
python-gnocchiclient python-pankoclient python-pyuv
python-softlayer ratproxy scite takari-local-repository tinyca2
Depending packages (rawhide) (20): ganglia
golang-github-AudriusButkevicius-kcp-go golang-github-cznic-b
golang-github-cznic-fileutil golang-github-cznic-internal
golang-github-cznic-lex golang-github-cznic-lexer
golang-github-cznic-lldb golang-github-cznic-sortutil
golang-github-cznic-strutil golang-github-templexxx-reedsolomon
golang-github-templexxx-xor golang-github-xtaci-kcp-go
python-agate python-oslo-messaging python-responses
python-ripe-atlas-cousteau torbrowser-launcher
transmission-remote-cli webacula
Packages depending on packages orphaned (rawhide) for more than 6
weeks (16): ganglia golang-github-AudriusButkevicius-kcp-go
golang-github-cznic-b golang-github-cznic-fileutil
golang-github-cznic-internal golang-github-cznic-lex
golang-github-cznic-lexer golang-github-cznic-lldb
golang-github-cznic-sortutil golang-github-cznic-strutil
golang-github-templexxx-reedsolomon golang-github-templexxx-xor
golang-github-xtaci-kcp-go python-agate python-oslo-messaging
webacula
--
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
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
5 years, 2 months
F30 System-Wide Change proposal: Replace Comps Language Group With Langpacks
by Ben Cotton
Congratulations to the last System-Wide Change proposal of F30!
https://fedoraproject.org/wiki/Changes/Replace_Comps_Language_Group_With_...
== Summary ==
Language support groups in Comps file will get replaced by langpacks
package. With this Change we want meta-packages like langpacks-ja to
also install required fonts and input-methods for the given language.
== Owner ==
* Name: [[User:petersen| Jens Petersen]]
* Email: petersen at fedoraproject dot org
* Name: [[User:pnemade| Parag Nemade]]
* Email: pnemade at fedoraproject dot org
== Detailed Description ==
This change will remove the need of having the language specific comps
groups in Fedora.
We already have ''langpacks-*'' packages in Fedora since F24.
Currently they are installing language packages for translations,
dictionaries etc. but not fonts or input-methods. With this Change we
will try to install fonts and input-methods as well.
E.g. if you net-install Fedora in Japanese language then installation
of any base package like libreoffice-core or man-pages are installing
automatically libreoffice-langpack-ja or man-pages-ja but langpacks-ja
is not installing any Japanese font or input-method.
But now with using RPM tags or weak dependencies like Supplements, we
can get font as well as input-method packages installed as well on the
system.
There is no need of language comps groups to exist, they will be
replaced by langpacks.
This Change is originally submitted at https://pagure.io/i18n/issue/97
== Benefit to Fedora ==
Users can install complete language support now using langpacks only.
This will also help to remove the language support groups from the
comps file.
== Scope ==
* Proposal owners: Check all langpacks providing packages (like fonts,
input-methods) add Supplements tag in their SPEC file and build them.
We will track the progress of this Change in
[https://copr.fedorainfracloud.org/coprs/pnemade/langpacks/ Langpacks
Copr] project.
* Other developers: To all other developers of packages who provides
langpacks, they need to add the Supplements tag as given in this
[https://fedoraproject.org/wiki/Packaging:Langpacks Langpacks
guideline] to each langpack subpackage.
* Release engineering: none
* Policies and guidelines: none
== Upgrade/compatibility impact ==
None.
== How To Test ==
* [[QA:Langpacks]]
== User Experience ==
Currently users can get complete language support installed only using
"''dnf group install <lang-support>''" command. After this Change gets
implemented end users can get language support installed using
meta-packages "''langpacks-<langcode>"'' only
== Dependencies ==
No Other Change depend on this.
== Contingency Plan ==
* Contingency mechanism: If this change is not completed by final
development freeze then we need to target this for F31. We are just
proposing to add additional information in langpacks packages that is
Supplements tag. This should not affect individual langpacks packages
installation by dnf.
* Contingency deadline: I don't think we will need anything to revert
or apply any contingency plan here if this is not completed by beta
freeze.
* Blocks release? No
* Blocks product? N/A
== Documentation ==
* Need to add about this in the Release notes
--
Ben Cotton
Fedora Program Manager
TZ=America/Indiana/Indianapolis
5 years, 2 months
OUTAGE: Koji system 2019-01-11 -> 2019-01-14
by Stephen John Smoogen
Planned Outage - Koji Services - 2019-01-11 22:00 UTC
There will be an koji outage starting at 2019-01-11 22:00 UTC, which
will last approximately 4 days.
To convert UTC to your local time, take a look at
http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run:
date -d '2019-01-11 22:00UTC'
Reason for outage:
The facility that houses the Fedora s390 server will have a major
power outage starting 2019-01-11 22:00 UTC and ending 2019-01-14 22:00
UTC. During this time the s390 builders will not be available and all
builds will be queued up until they are available and will not
complete.
Affected Services:
koji and related services which make composes and builds
Ticket Link:
https://pagure.io/fedora-infrastructure/issue/7429
Please join #fedora-admin or #fedora-noc on irc.freenode.net or add
comments to the ticket for this outage above.
--
Stephen J Smoogen.
5 years, 2 months
F30 Self-Contained Change proposal: Avoid Fedora-specific build flags
in non-RPM Python extensions
by Ben Cotton
https://fedoraproject.org/wiki/Changes/Python_Extension_Flags
== Summary ==
The build flags (<code>CFLAGS</code>, <code>CXXFLAGS</code> and
<code>LDFLAGS</code>) saved in the Python's distutils module for
building extension modules are switched from:
* <code>%{build_cflags}</code>,
* <code>%{build_cxxflags}</code> and
* <code>%{build_ldflags}</code>
to:
* <code>%{extension_cflags}</code>,
* <code>%{extension_cxxflags}</code> and
* <code>%{extension_ldflags}</code>.
This [https://src.fedoraproject.org/rpms/redhat-rpm-config/blob/master/f/buildf...
currently means] that no GCC plugins (such as annobin) are activated
and no GCC spec files (<code>-specs=</code> arguments) are used by
default when building Python extension modules (e.g. with
<code>python3 setup.py build</code>).
The {{package|python3-devel}} package will lose its runtime dependency
on {{package|redhat-rpm-config}} (which was only required for annobin
support and GCC spec files).
The change will affect building extension modules by users, outside of
the RPM environment. The Python standard library and Fedora's Python 3
RPM packages are still built with the "traditional" set of flags
(<code>%{build_cflags}</code> and friends), unless the package uses
nonstandard methods to build the extensions.
Only Python 3.7 ({{package|python3}}) and 3.6 ({{package|python36}})
will be changed.
== Owner ==
* Name: [[User:Churchyard|Miro Hrončok]], [[User:Cstratak|Charalampos
Stratakis]]
* Email: python-maint(a)redhat.com
=== The Problem ===
When Python is built, it saves the flags (<code>CFLAGS</code>,
<code>CXXFLAGS</code> and <code>LDFLAGS</code>) for further use when
building extension modules into a designated <code>Makefile</code>.
The distutils module (a component responsible for building Python
packages and extension modules) then reads the file and applies the
flags. You can see the file at
<code>/usr/lib64/python3.7/config-3.7m-x86_64-linux-gnu/Makefile</code>
in {{package|python3-libs}}. This is mostly done to make user-built
extension modules binary compatible with the Python interpreter they
are being built for.
Traditionally (=before this change), the {{package|python3}} package
was created in a way that it simply saved the same set of flags used
for building itself.
This proved problematic as the flags used to build Fedora packages
grew specific things (not actually needed for binary compatibility of
the extension modules) and several workarounds needed to be made, most
specifically the {{package|python3-devel}} package got a runtime
dependency on {{package|redhat-rpm-config}}:
* https://bugzilla.redhat.com/show_bug.cgi?id=1217376
* https://bugzilla.redhat.com/show_bug.cgi?id=1496757
* https://bugzilla.redhat.com/show_bug.cgi?id=1218294
The problematic flags are GCC plugins (such as annobin) and GCC spec
files (<code>-specs=</code> arguments).
Example: Any Python developer using Fedora automatically builds Python
extension modules with annobin and hardening flags by default even if
they don't need that. They might build the extension on Fedora, test
it and later ship it and build it on a CI that is not based on Fedora
and get different results.
=== The Solution ===
The solution is not to save the problematic flags, but only the flags
needed. Until recently, this would be hackish, but
[https://src.fedoraproject.org/rpms/redhat-rpm-config/blob/master/f/buildf...
a designated set of flags] was created in Fedora 30, supposed to be
used by extension builders (such as the Python's distutil module):
<code>%{extension_cflags}</code>, <code>%{extension_cxxflags}</code>
and <code>%{extension_ldflags}</code>.
The [https://src.fedoraproject.org/rpms/redhat-rpm-config/blob/master/f/buildf...
documentation for the flags] currently reads:
<blockquote>
The current set of differences are:
* No GCC plugins (such as annobin) are activated.
* No GCC spec files (<code>-specs=</code> arguments) are used.
Additional flags may be removed in the future if they prove to be
incompatible with alternative toolchains.
</blockquote>
Python already had (incomplete) support for specifying different sets
of flags for itself and for the extensions. In Python 3.7.2 and 3.6.8
the ability was completed by providing a way to do this for
<code>LDFAGS</code> (this was actually driven by Fedora's needs).
Currently we are able to set a different set of flags for building
Python and for building user extension modules. The code implementing
this change can be inspected at
[https://src.fedoraproject.org/rpms/python3/pull-request/75 Fedora
python3 PR #75] and [https://github.com/python/cpython/pull/10900
CPython PR #10900].
=== Impact on users building extension modules ===
When an user compiles a Python extension module outside of RPMBuild
and does not specify any flags explicitly, this is what they used to
have:
$ python3 setup.py build
running build
running build_ext
building 'demo' extension
creating build
creating build/temp.linux-x86_64-3.7
gcc -pthread -Wno-unused-result -Wsign-compare
-DDYNAMIC_ANNOTATIONS_ENABLED=1 -DNDEBUG -O2 -g -pipe -Wall
-Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
-Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong
-grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection
-D_GNU_SOURCE -fPIC -fwrapv -fPIC -I/usr/include/python3.7m -c demo.c
-o build/temp.linux-x86_64-3.7/demo.o
creating build/lib.linux-x86_64-3.7
gcc -pthread -shared -Wl,-z,relro -Wl,-z,now
-specs=/usr/lib/rpm/redhat/redhat-hardened-ld -g
build/temp.linux-x86_64-3.7/demo.o -L/usr/lib64 -lpython3.7m -o
build/lib.linux-x86_64-3.7/demo.cpython-37m-x86_64-linux-gnu.so
After the change, they will get:
$ python3 setup.py build
running build
running build_ext
building 'demo' extension
creating build
creating build/temp.linux-x86_64-3.7
gcc -pthread -Wno-unused-result -Wsign-compare
-DDYNAMIC_ANNOTATIONS_ENABLED=1 -DNDEBUG -O2 -g -pipe -Wall
-Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
-Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong
-grecord-gcc-switches -m64 -mtune=generic -fasynchronous-unwind-tables
-fstack-clash-protection -fcf-protection -D_GNU_SOURCE -fPIC -fwrapv
-fPIC -I/usr/include/python3.7m -c demo.c -o
build/temp.linux-x86_64-3.7/demo.o
creating build/lib.linux-x86_64-3.7
gcc -pthread -shared -Wl,-z,relro -Wl,--as-needed -Wl,-z,now -g
build/temp.linux-x86_64-3.7/demo.o -L/usr/lib64 -lpython3.7m -o
build/lib.linux-x86_64-3.7/demo.cpython-37m-x86_64-linux-gnu.so
Users are able to provide their own flags by setting the
<code>CFLAGS</code>/<code>CXXFLAGS</code> and <code>LDFLAGS</code>
environment variables. They can, for example, opt-in for annobin if
they wish to do so.
=== Impact on RPM packages building extension modules ===
When the spec file of the package sets the
<code>CFLAGS</code>/<code>CXXFLAGS</code> and <code>LDFLAGS</code>
variables to the expected Fedora values (e.g.
<code>CFLAGS=${RPM_OPT_FLAGS} LDFLAGS=${RPM_LD_FLAGS}</code> or
<code>%{build_cflags}</code>, <code>%{build_cxxflags}</code>,
<code>%{build_ldflags}</code>, <code>%{optflags}</code> etc.)
everything works as expected. The currently documented way of building
Python packages (<code>%py3_build</code> and
<code>%py3_install</code>)
[https://src.fedoraproject.org/rpms/python-rpm-macros/blob/master/f/macros...
does this] for you, we recommend using it.
There might be some differences in the log, because the flags
concatenate. Here is the example from the {{package|python-psycopg2 }}
build.log.
Before this change:
gcc -pthread -DDYNAMIC_ANNOTATIONS_ENABLED=1 -DNDEBUG '''-O2 -g -pipe
-Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
-Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong
-grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic
-fasynchronous-unwind-tables -fstack-clash-protection
-fcf-protection''' -D_GNU_SOURCE -fPIC -fwrapv '''-O2 -g -pipe -Wall
-Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
-Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong
-grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic
-fasynchronous-unwind-tables -fstack-clash-protection
-fcf-protection''' -fPIC -DPSYCOPG_DEFAULT_PYDATETIME=1
-DPSYCOPG_VERSION=2.7.5 (dt dec pq3 ext lo64) -DPG_VERSION_NUM=110000
-DHAVE_LO64=1 -I/usr/include/python3.7m -I. -I/usr/include
-I/usr/include/pgsql/server -c psycopg/psycopgmodule.c -o
build/temp.linux-x86_64-3.7/psycopg/psycopgmodule.o
-Wdeclaration-after-statement
After this change:
gcc -pthread -DDYNAMIC_ANNOTATIONS_ENABLED=1 -DNDEBUG '''-O2 -g -pipe
-Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
-Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong
-grecord-gcc-switches -m64 -mtune=generic -fasynchronous-unwind-tables
-fstack-clash-protection -fcf-protection''' -D_GNU_SOURCE -fPIC
-fwrapv '''-O2 -g -pipe -Wall -Werror=format-security
-Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions
-fstack-protector-strong -grecord-gcc-switches
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic
-fasynchronous-unwind-tables -fstack-clash-protection
-fcf-protection''' -fPIC -DPSYCOPG_DEFAULT_PYDATETIME=1
-DPSYCOPG_VERSION=2.7.5 (dt dec pq3 ext lo64) -DPG_VERSION_NUM=110000
-DHAVE_LO64=1 -I/usr/include/python3.7m -I. -I/usr/include
-I/usr/include/pgsql/server -c psycopg/psycopgmodule.c -o
build/temp.linux-x86_64-3.7/psycopg/psycopgmodule.o
-Wdeclaration-after-statement
If the package does <code>python3 setup.py build</code> to build the
extension modules manually without setting the flags, the flags are
not set properly. This is probably very rare. Even before the
<code>%py3_build</code> and <code>%py3_install</code> macros, the
preferred way was to call:
CFLAGS="$RPM_OPT_FLAGS" %{__python} setup.py build # from EL4
However, <code>LDFLAGS</code> are not set in that example.
There are 485 packages that have the <code>%{python3_sitearch}</code>
macro in them and hence are most likely to build Python extension
modules.
Out of those, 173 have <code>setup.py</code> directly in the spec. 65
have <code>setup.py build</code>. Change owners will go trough the
list and provide fixes. Packages are encouraged to switch to the
<code>%py3_build</code> macro themselves.
Worst case: Some package won't have annobin.
=== Python interpreters affected by this change ===
This change is fully possible (without backporting) in Python 3.6.8 /
3.7.2 or newer. Hence we'll only change the {{package|python3}} and
{{package|python36}} packages.
We'll keep older Pythons intact and let them finish their lifetime as
they are. Newer Python versions will inherit this change.
PyPy 3 ({{package|pypy3}}) might eventually be updated to a version
that supports this fully. Since no packages in Fedora use PyPy 3,
we'll update it then without a change proposal and we'll document the
fact on this Change page. (If any package starts using PyPy 3 untill
then, we'll coordinate with the maintainer/s).
== Benefit to Fedora ==
Python developers will get more upstream-like experience when building
Python extension modules.
Python developers won't need {{package|redhat-rpm-macros}} (and dozens
of other language-specific packages that go with that) installed just
to do so.
New decisions made about the distro packages won't necessarily affect
Python developers building their extension modules.
== Scope ==
* Proposal owners:
** Review, merge and build the
[https://src.fedoraproject.org/rpms/python3/pull-request/75 pull
request with the implementation].
** Go through the packages manually invoking <code>setup.py</code> to
build extension modules and provide fixes. Update to
<code>%py3_build</code> where possible, set the flags manually
otherwise.
* Other developers: Are encouraged to switch to
<code>%py3_build</code> (but they don't need to do anything, this is
not a System Wide Change).
* Release engineering: [https://pagure.io/releng/issue/8027 #8027]
(mass rebuild not needed, no releng impact anticipated).
* Policies and guidelines: already in place.
== Upgrade/compatibility impact ==
Not anticipated. Extension modules (built for the same Python version)
are compatible with the interpreter with or without the removed flags
back and forth.
== How To Test ==
=== For users (Python developers) ===
# build your favorite Python extension module in venv or outside venv
with <code>setup.py build</code> or <code>setup.py build_ext</code>
# observe the used flags and check annobin and <code>-specs</code>
'''are not there''', report bugs for {{package|python3}} otherwise
(and block our tracking bug)
# check if the extension works as expected
=== For packagers (Fedora contributors) ===
# build your favorite RPM package with Python extension module
# observe the used flags and check annobin and <code>-specs</code>
'''are there''', report bugs for that package otherwise (and block our
tracking bug)
# check if the package works as expected
== User Experience ==
See '''Benefit to Fedora''' above.
== Dependencies ==
Changes in {{package|redhat-rpm-config}} are already done.
We will check dependent Fedora packages.
== Contingency Plan ==
* Contingency mechanism: Change owners can revert the change at any
point. If removing the {{package|redhat-rpm-config}} dependency turns
out to be problematic, it can be added back until the problem is
fixed.
* Contingency deadline: final freeze
* Blocks release? No
* Blocks product? None
== Documentation ==
This page is the documentation.
== Release Notes ==
TBD.
--
Ben Cotton
Fedora Program Manager
TZ=America/Indiana/Indianapolis
5 years, 2 months
F30 System-Wide Change proposal: Reset locale if not available
by Ben Cotton
https://fedoraproject.org/wiki/Changes/Reset-locale-if-not-available
== Summary ==
When logging in over ssh or another mechanism, locale settings are
forwarded. If the destination does not support that locale, C.UTF-8
will be used instead.
== Owner ==
* Name: [[User:Zbyszek | Zbigniew Jędrzejewski-Szmek]]
* Email: zbyszek(a)in.waw.pl
== Detailed Description ==
This is a continuation of [[Changes/Remove glibc-langpacks-all from
buildroot]]. With that change implemented, it is much more likely for
a system to only support C.UTF-8 or some other small set of locales.
When logging in into such an image from a normal system that uses a
"full" locale like en_US.UTF-8 or the equivalent for another language,
those locale settings are forwarded, resulting in a session with
invalid locale settings and errors from various tools.
The same problem could occur previously, for example when logging in
from a desktop with LANG=fr_FR.UTF-8 to a container with only
en_EN.UTF-8 installed.
To avoid this, the locale setting will be reset to C.UTF-8 if the
current setting is "invalid" (not found).
We already have a mechanism to reset locale information if it is
unusable. `/etc/profile.d/lang.sh` will unset
Japanese/Korean/Chinese/... locales only the tty, because the kernel
cannot display such fonts properly, so we switch to `en_US.UTF-8` to
get ''something'' displayed. The same mechanism will be used for this.
== Benefit to Fedora ==
Avoid stupid warnings like
<pre>
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LC_CTYPE = "fr_FR.UTF-8",
LANG = "en_US.UTF-8"
...
are supported and installed on your system.
perl: warning: Falling back to a fallback locale ("en_US.UTF-8").
</pre>
== Scope ==
* Proposal owners:
** Provide a patch to `/etc/profile.d/lang.{sh,csh}` to check if the
inherited locale is present, and if not, reset to C.UTF-8.
* Other developers: n/a
* Release engineering: https://pagure.io/releng/issue/8036
** List of deliverables: N/A
* Policies and guidelines: no changes needed
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
I ''think'' this should be beneficial in all cases. I doubt that
anyone runs with broken locale settings on purpose.
== How To Test ==
Login to a different machine with a locale not installed on that
machine. Verify that the locale is set to C.UTF-8. If the locale is
installed on the target machine, it should not be reset.
== User Experience ==
Slightly easier ssh sessions.
See also [https://bugzilla.redhat.com/show_bug.cgi?id=1432426 1432426].
== Dependencies ==
None.
== Contingency Plan ==
Revert the change to `/etc/profile.d/lang.*`.
* Contingency mechanism: revert the patch, rebuild `setup` package
* Contingency deadline: any time before relase
* Blocks release? no
* Blocks product? no
== Documentation ==
None needed.
== Release Notes ==
Locale settings will be reset to C.UTF-8 when logging into a machine
which does not have the locale that is used on the source machine.
--
Ben Cotton
Fedora Program Manager
TZ=America/Indiana/Indianapolis
5 years, 2 months
F30: System-Wide Change proposal: DNF UUID
by Ben Cotton
https://fedoraproject.org/wiki/Changes/DNF_UUID
== Summary ==
Right now, we estimate installed Fedora systems by counting unique IP
addresses which show up in our updates mirror statistics. We need
better data than that. There are some proposals for more complicated
systems, but a quick thing we can do is implement a per-system UUID
(unique identifier) and count that instead of IP addresses.
This is what openSUSE does — see https://metrics.opensuse.org/ for
live stats. See also
[https://lists.fedoraproject.org/archives/list/council-discuss@lists.fedor...
this previous Fedora Council discussion] for background.
== Owner ==
* Name: [[User:mattdm|Matthew Miller]]
* Email: mattdm
== Detailed Description ==
=== The problem ===
* A. Currently, we can only count Fedora OS use by observing IP
addresses. This is subject to undercounting due to NAT — and to
overcounting due to short DHCP leases and laptops moving between work
or school and home or coffee shop.
* B. We can count what releases are observed, but we can’t distinguish variants.
* C. We can’t count quickly because various logs are copied back to a
central server and data is not consistent for several days.
=== Constraints ===
* The Fedora community cares about privacy and is adverse to tracking
measures. We don't want to track; just count.
* For this reason, we don’t want to use any identifier like
/etc/machine-id which may be used for other purposes.
* And, also for that reason, there needs to be a relatively easy way to opt out.
* This needs to work with Yum/DNF, MicroDNF, PackageKit, Cockpit,
rpm-ostree, GNOME Software, Muon, Apper, and software update
mechanisms used in other spins.
* We need to be able to distinguish between short-lived instances
(like temporary containers or test machines) and actual installations.
=== Non-Goals ===
* We don’t want to track users, just count systems.
* Except for distinguishing temporary installations from “real” use,
we don’t need to track systems over time. We just want a daily or
weekly moment-in-time count.
* Being able to see how systems are upgraded over time might be
interesting but isn’t as important as privacy concerns.
=== Other Elements ===
* VARIANT_ID will be set in /etc/os-release. See [[Changes/Label Our
Variants]] We want that, plus VERSION_ID and machine architecture.
* We may also want each report to contain a boolean flag showing
whether the system has been in use for at least 24 hours to help
separately categorize test and other throw-away instances.
* openSUSE already uses a UUID in zypper; this is ground already traveled
* Yum and DNF have built in support for fileset variables which can be
‘removed’ to deal with privacy issues.
See https://bugzilla.redhat.com/show_bug.cgi?id=1542060
== Benefit to Fedora ==
* Better metrics overall
* Public stats page updated automatically
* Better knowledge of relative use of different variants
* Insight into Fedora's use in short-lived test systems and temporary
containers vs. longer-term installations
== Scope ==
* Proposal owners: work with DNF team and infrastructure to implement
the UUID feature and corresponding backend data collection
* DNF team: feature work
* Maintainers of other package management tools: make sure feature
works in these cases as well
* Other developers: Spin maintainers should make sure that VARIANT_ID
is being set in /etc/os-release
** List of deliverables: affects all deliverables
* Policies and guidelines: none
* Trademark approval: none
== Upgrade/compatibility impact ==
Older versions will not have the UUID counting enabled; we will keep
collecting stats in the traditional way for those systems.
== How To Test ==
Once the system is in place, we will see data collected.
== User Experience ==
User experience will not change. Users who wish to opt out of counting
will have an easy way to do so.
== Dependencies ==
Package managers.
== Contingency Plan ==
* Contingency mechanism: continue counting the old way
* Contingency deadline: does not block release; we can ship with the
feature incomplete, although it would certainly be most useful to have
it available at GA
* Blocks release? No
* Blocks product? No
== Documentation ==
Release notes need to be written, and documentation describing how to opt out.
== Release Notes ==
This needs to be written but depends on exact implementation.
--
Ben Cotton
Fedora Program Manager
TZ=America/Indiana/Indianapolis
5 years, 2 months