F39 Change Proposal: Sericea and Sway Spin Xorg-less (Self Contained)
by Aoife Moloney
https://fedoraproject.org/wiki/Changes/sericea-xorgless
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.
== Summary ==
At the moment Sericea and Sway Spin ship with xorg-x11 packages.
This proposal aims to remove xorg-x11 packages from such artifacts.
== Owner ==
* Name: [[User:alebastr| Aleksei Bavshin]], [[User:Fale|Fabio
Alessandro Locati]], Sway SIG
** Primary contact person: Fabio Alessandro Locati
* Email: fale(a)fedoraproject.org
== Detailed Description ==
At the moment Sericea and Sway Spin require the installation of
xorg-x11 due to the use of `sddm-x11`.
When we started working on F38 we were not fully convinced on the
stability of SDDM-Wayland, so we opted for the safer bet: SDDM-X11.
Though, since Sway is Wayland-only, it would make sense for Sericea
and Sway Spin to prefer the use of `sddm-wayland-sway`.
== Feedback ==
So far only positive feedback have been provided on this idea.
== Benefit to Fedora ==
This change will allow Sericea and Sway Spin artifacts to ship without xorg-x11.
== Scope ==
* Proposal owners: change the default in comps
* Other developers: N/A
* Release engineering: N/A
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Community Initiatives: N/A
== Upgrade/compatibility impact ==
When the users will update their Fedora installation, the change will
occur in their boxes automatically. No direct impact nor configuration
change is required.
== How To Test ==
# Install `sddm-wayland-sway`
# Reboot and test the login
== User Experience ==
`sddm-wayland-sway` should have a slightly positive experience for
users, with less bugs in some edge cases than `sddm-x11`. Majority of
users should not be able to notice the difference.
== Dependencies ==
N/A
== Contingency Plan ==
If unexpected issues will be created by this change, we can easily
rollback to `sddm-x11` by changing back the comps packages.
* 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), Yes/No
== Documentation ==
N/A (not a System Wide Change)
== Release Notes ==
--
Aoife Moloney
Product Owner
Community Platform Engineering Team
Red Hat EMEA
Communications House
Cork Road
Waterford
1 year
F39 Change Proposal: Further reduce Fedora-specific build flags in
non-RPM Python extensions (Self Contained)
by Aoife Moloney
https://fedoraproject.org/wiki/Changes/Python_Extension_Flags_Reduction
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.
== Summary ==
<!-- A sentence or two summarizing what this change is and what it
will do. This information is used for the overall changeset summary
page for each release. Note that motivation for the change should be
in the Benefit to Fedora section below, and this part should answer
the question "What?" rather than "Why?". -->
Continuing the work started with
https://fedoraproject.org/wiki/Changes/Python_Extension_Flags, this
change is about further reducing the build and linker flags (CFLAGS
and LDFLAGS) saved internally in the Python interpreter for use by
distutils and other build systems. Compiling non-RPM Python extension
modules will carry only the compiler flags required for binary
compatibility with the interpreter they were built against and not
Fedora specific ones.
Practically that means the only Fedora derived flag will be
<code>-fexceptions</code> and Python will apply its own upstream
hardcoded ones, making the final flag set for a non-RPM compiled
Python extension as follows:
* <code>-Wsign-compare -DDYNAMIC_ANNOTATIONS_ENABLED=1 -DNDEBUG
-fexceptions</code>
Python C extensions built as rpm's will '''not''' be affected.
The current main Python interpreter on Fedora 39 will be modified
(Python 3.12) and Python 3.6-3.11 will follow.
This change will affect every package that provides support for
extension builders via utilizing the <code>%{extension...flags}</code>
macros which at the time being is only Python.
== Owner ==
* Name: [[User:cstratak| Charalampos Stratakis]]
* Email: python-maint AT redhat.com
== Detailed Description ==
After implementing
https://fedoraproject.org/wiki/Changes/Python_Extension_Flags we
uncoupled some distro specific compilation and linker flags propagated
to C extensions.
However with an ever increasing set of compiler flags being added and
applied distro-wide, as compilers and security standards evolve (e.g.
-D_FORTIFY_SOURCE=3) it becomes an increasingly complex job to vet
each flag that might leak into user-built Python C extensions through
the Python interpreter. Instead of removing only some flags and
letting the rest follow through, we will be taking a more proactive
approach by removing all the compiler and linker flags, except the
ones that are required to maintain the binary compatibility with the
Python interpreter the extensions were built against which is
<code>-fexceptions</code>. We will also preserve the ones that Python
hardcodes itself through the Makefile.
Similarly, when a user builds their own C programs, no compiler flags
are applied by default and the user is free to making their own
decision. Bringing the compilation of Python C extensions closer to
that experience is the next logical step.
Currently a user-built Python C extension will be built with:
CFLAGS:
<code>
-Wsign-compare -DDYNAMIC_ANNOTATIONS_ENABLED=1 -DNDEBUG -O2
-fexceptions -g -grecord-gcc-switches -pipe -Wall
-Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3
-Wp,-D_GLIBCXX_ASSERTIONS -fstack-protector-strong -m64
-mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection
-fcf-protection -D_GNU_SOURCE -fPIC -fwrapv -O2 -fexceptions -g
-grecord-gcc-switches -pipe -Wall -Werror=format-security
-Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS
-fstack-protector-strong -m64 -mtune=generic
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection
-D_GNU_SOURCE -fPIC -fwrapv -O2 -fexceptions -g
-grecord-gcc-switches -pipe -Wall -Werror=format-security
-Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS
-fstack-protector-strong -m64 -mtune=generic
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection
-D_GNU_SOURCE -fPIC -fwrapv
</code>
LDFLAGS:
<code>
'-Wl,-z,relro -Wl,--as-needed -Wl,-z,now -Wl,--build-id=sha1 -g
-Wl,-z,relro -Wl,--as-needed -Wl,-z,now -Wl,--build-id=sha1 -g'
</code>
After this change:
CFLAGS:
<code>
-Wsign-compare -DDYNAMIC_ANNOTATIONS_ENABLED=1 -DNDEBUG -fexceptions
-fexceptions -fexceptions
</code>
LDFLAGS:
None
== Feedback ==
The initial thread that inspired this change was
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
== Benefit to Fedora ==
Python developers will get more upstream-like experience when building
Python extension modules and also closer to building vanilla C
programs. Also new decisions made about the distro-wide compiler flags
won't necessarily affect Python developers building their extension
modules.
In addition any Python developer using Fedora will have the capability
to build the extension on Fedora, test it and later ship it and build
it on a CI or other systems that are not based on Fedora.
== Scope ==
* Proposal owners: Review, merge and build the
[https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/252
redhat-rpm-config PR] and the apply the relevant changes in the Python
interpreters ([https://src.fedoraproject.org/rpms/python3.11/pull-request/111
example from python3.11])
* Other developers: No requirements apart from welcoming testing their
C extensions
* Release engineering: No mass rebuild required and no releng impact
anticipated.[https://pagure.io/releng/issues #Releng issue number]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
== 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 your favorite build system
# observe the used flags and check that the full set of flags are
'''are not there''' as mentioned in the detailed description, report
bugs for {{package|python3.12}} 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 that the full set of flags '''are
there''' and not the reduced one, 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 are required in {{package|redhat-rpm-config}} along with the
Python interpreters.
== Contingency Plan ==
* Contingency mechanism: Change owners can revert the change at any point.
* Contingency deadline: final freeze (not a System Wide Change)
* Blocks release? No
== Documentation ==
N/A (not a System Wide Change)
== Release Notes ==
--
Aoife Moloney
Product Owner
Community Platform Engineering Team
Red Hat EMEA
Communications House
Cork Road
Waterford
1 year
PSA: Rawhide - what to do if switch to dnf5 fails because dnf is
protected
by Adam Williamson
I've heard a couple of folks report that they tried updating a Rawhide
system or container and it failed with:
Problem: The operation would result in removing the following protected packages: dnf
The problem seems to be caused by doing the upgrade with an older dnf
installed. dnf-4.15.1-1.fc39 was tagged into Rawhide on May 18th, and
it dropped the protection of dnf (and yum). So there was a month or so
where the 'current' dnf package you got on Rawhide update dropped the
protection of dnf itself, and if you updated to that version before the
dnf5-by-default update arrived this week, your upgrade to dnf5 should
go fine.
However, if you *didn't* update your system to dnf-4.15.1-1.fc39,
you'll encounter this problem when you try to update now, because the
older dnf build you have installed still considers itself protected.
You have a couple of options if you're stuck in this situation: either
update to 4.15.1 first (by grabbing the packages from
https://koji.fedoraproject.org/koji/buildinfo?buildID=2202454 and
updating them), or rename or edit the file
/etc/dnf/protected.d/dnf.conf so dnf is no longer protected. After
doing that, the upgrade should work correctly.
It's also been reported that using the pre-switchover dnf5 to do the
switchover upgrade (the one that makes dnf5 the default and removes
dnf) may not work. If it doesn't, then just use dnf to run that upgrade
instead.
Sorry for any trouble caused by this!
--
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @adamw(a)fosstodon.org
https://www.happyassassin.net
1 year
F39 Change Proposal:
by Aoife Moloney
https://fedoraproject.org/wiki/Changes/ibus-anthy_1.5.15
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.
== Summary ==
In ibus-anthy 1.5.15, the icon tag will be added to the metainfo, the
Japanese era is updated for 2023, the candidate window is enhanced for
OSK(On-Screen Keyboard).
== Owner ==
* Name: [[User:Fujiwara|Takao Fujiwara]]
* Email: fujiwara [at] redhat [dot] com
== Detailed Description ==
* ibus-anthy already has the icon but it wasn't indicated in the
metainfo. Also screenshots and keywords are updated.
* ibus-anthy will convert the Japanese era and "2023" mutually
* ibus-anthy determines a clicked item on the candidate window but
also will commit the clicked item on the candidate window in case of
enabling the OSK(On-Screen Keyboard) mode in GNOME Wayland.
== Feedback ==
== Benefit to Fedora ==
The metainfo data is updated within the ibus-anthy package, Japanese
era is updated in a ibus-anthy dictionary file, the OSK mode is
available only if the OSK is enabled and ibus-anthy switches the
candidate mode.
== Scope ==
* Proposal owners: ibus-anthy
* Other developers:
* Release engineering: [https://pagure.io/releng/issues #Releng issue number]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Community Initiatives:
== Upgrade/compatibility impact ==
== How To Test ==
1. Enable ibus-anthy
2. Run gnome-text-editor
3. Type "2023" or "れいわ5" and space keys
4. The Japanese era and 2023 is converted mutually
1. Enable OSK and ibus-anthy
2. Run gnome-text-editor
3. Click "a" and space x 2 keys in OSK and show the candidate window
4. Click a candidate string on the candidate window
5. The selected candidate string is committed in gnome-text-editor
== User Experience ==
The metainfo data is relative with gnome-software and I hope the
ibus-anthy section will be updated. Japanese era has been rarely used
in Japanese documents and the ibus-anthy conversion will be useful.
The OSK usability will be enhanced with the mouse.
== Dependencies ==
== Contingency Plan ==
* Contingency mechanism: Revert the change to ibus-anthy.
* Contingency deadline: Beta release
* Blocks release? No
== Documentation ==
N/A
== Release Notes ==
--
Aoife Moloney
Product Owner
Community Platform Engineering Team
Red Hat EMEA
Communications House
Cork Road
Waterford
1 year
F39 Change Proposal: Golang1.21 (System-Wide)
by Aoife Moloney
https://fedoraproject.org/wiki/Changes/golang1.21
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.
== Summary ==
Update of Go (golang package) to the upcoming version 1.21 in Fedora 39.
== Owner ==
* Name: [[User:alexsaezm| Alejandro Sáez Morollón]]
* Email: asm(a)redhat.com
== Detailed Description ==
Update of Go (golang package) to the upcoming version 1.21 in Fedora
39. Go 1.21 is expected to be released in August 2023. A mass rebuild
of all of the dependent packages is required.
== Feedback ==
No feedback yet.
== Benefit to Fedora ==
Up-to-date and latest Go release will be delivered to Fedora users.
Being close to upstream allows us to avoid security issues and provide
more up-to-date features.
Therefore Fedora will be providing a reliable development platform for
Go language and projects written in it.
For a complete list of changes, see upstream change notes at
https://tip.golang.org/doc/go1.21
== Scope ==
* Proposal owners:
Rebase Golang package in Fedora 39, and help resolve possible issues
found during package rebuilds.
* Other developers:
Fix possible issues, with help from Golang maintainers.
* Release engineering: [https://pagure.io/releng/issues #Releng issue number]
Rebuild of dependent packages as part of planned mass-rebuild.
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Community Initiatives: It doesn't align directly with
the current objectives but it helps maintain the quality of the
project.
== Upgrade/compatibility impact ==
No upgrade or compatibility impact.
== How To Test ==
# Install golang 1.21 from rawhide and use it to build your
application(s)/package(s).
# Scratch build against rawhide.
# Your application/package built using golang 1.21 should work as expected.
== User Experience ==
Users will have a newer version of Go, with new features described in
the release notes and security fixes
== Dependencies ==
<pre>
dnf repoquery -q --releasever=rawhide --disablerepo='*'
--qf='%{name}' --enablerepo=fedora-source --enablerepo=updates-source
--enablerepo=updates-testing-source --archlist=src --whatrequires
'golang'
dnf repoquery -q --releasever=rawhide --disablerepo='*'
--qf='%{name}' --enablerepo=fedora-source --enablerepo=updates-source
--enablerepo=updates-testing-source --archlist=src --whatrequires
'compiler(go-compiler)'
dnf repoquery -q --releasever=rawhide --disablerepo='*'
--qf='%{name}' --enablerepo=fedora-source --enablerepo=updates-source
--enablerepo=updates-testing-source --archlist=src --whatrequires
'go-rpm-macros'
</pre>
<pre>
Omitted due to the number of packages listed: ~2000.
</pre>
== Contingency Plan ==
* Contingency mechanism: Revert to Go 1.20.X if significant issues are
discovered <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Contingency deadline: Beta freeze
== Documentation ==
https://tip.golang.org/doc/go1.21
== Release Notes ==
--
Aoife Moloney
Product Owner
Community Platform Engineering Team
Red Hat EMEA
Communications House
Cork Road
Waterford
1 year
Rawhide update gating on openQA tests will be enabled Wednesday
by Adam Williamson
Hey folks! So, as per https://pagure.io/fesco/issue/3011 , we plan to
enable gating of Rawhide updates on openQA test results on Wednesday.
What does this mean?
For many updates, nothing at all: only updates on the critical path
will be gated.
For most critical path updates: instead of the build(s) being tagged
and going into the buildroot immediately after the build, the update
will go into a "waiting" state for about two hours, then - when the
tests have all passed - the builds will be tagged and put in the
buildroot. This is just the same as for branched and stable updates.
For the few critical path updates where a gating test fails: the
packages will not be tagged or reach the buildroot. The QA team should
notice the failure, investigate, and either fix the problem or file
some kind of issue report linked from the update on Bodhi within 24
hours. If this does not happen, or the update needs urgent attention,
please contact the QA team on Fedora Chat, or by email to test@ .
If you believe a gating failure may be a false alarm, you can click the
"Re-Run Tests" button in Bodhi to have the test re-run. If you are
*very very sure* it is a false alarm, and the need is urgent, you can
click the "Waive Results" button in Bodhi to waive the failure and have
the update tagged, but please only do this if there's really no
alternative. Please note that waiving a failure comes with a risk that
the same failure will happen for *every subsequent update*, causing
each of them to be gated, because the waived update will immediately
reach the buildroot, and openQA uses the buildroot as its "base"
package set for testing. Really, please don't do this unless you're
very sure!
If you have a big set or chain of builds to do and you don't want to
have to wait two hours between dependent builds: use a side tag! Side
tags are self-service now. You can just request one, it will be created
within minutes, and you can do your builds on the side tag. No gating
applies to side tags. When you're done, create an update from the side
tag in Bodhi (the web UI has support for this), and it will be tested
and gated as a single unit (the openQA tests will run once on the
update as a whole). See
https://docs.fedoraproject.org/en-US/rawhide-gating/multi-builds/ for a
walk-through of this process.
The display of gating status and test results on the Bodhi web
interface should be clear, consistent and accurate. If you find it is
not in any way, please file a ticket on Bodhi and tag me on it.
If this turns out to be a bad idea, we can and will easily revert it,
so please don't panic. :)
Thanks everyone!
--
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @adamw(a)fosstodon.org
https://www.happyassassin.net
_______________________________________________
devel-announce mailing list -- devel-announce(a)lists.fedoraproject.org
To unsubscribe send an email to devel-announce-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedora...
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
1 year
go-sig status
by Mikel Olasagasti
Hi all,
This mail is just a heads up on go-sig delicate current status.
After a "non-responsive" process for one of the go-sig members[1], a
lot of go-sig packages become orphans. This maintainer has been
working for years creating hundreds of packages and updating them.
The orphaning process caused that ~2100/~2300 go-sig packages to be
affected directly or indirectly. The current number is 1633/2373
packages affected. The list of currently affected packages can easily
be checked using package-dashboard[2] and clicking on the 'orphan'
(little person) button at the top right.
IIUC in little more than 4 weeks all those orphaned packages will be
retired and that can cause massive impact. Indirectly affected
packages include docker (moby-engine), containerd, rclone, restic or
gopass to name a few. Some packages might be key for some people, some
might just disappear without causing major noise.
I adopted ~100 packages needed by packages I maintain and I'm in the
process to update them. More hands will be needed to take the rest
and/or review new deps required by the updates.
And that's it. As this may create some bad press if some of those
packages vanish, I just wanted to alert devel-list.
Kind regards,
Mikel
[1] https://pagure.io/fesco/issue/2999
[2] https://packager-dashboard.fedoraproject.org/dashboard?groups=go-sig
1 year
Re: What is Fedora?
by Philip Wyett
On Wed, 2023-06-21 at 17:18 -0400, JT wrote:
>
> > How are you downloading RHEL ISO images?
>
> I already sent you the URL in a prior response:
> https://developers.redhat.com/products/rhel/download
>
> > Please do not tell me to take a deep breath and relax. Show some respect.
>
> I am being respectful, I've been trying to explain to you that this isn't anything to get
> stressed out over. I've calmly addressed the questions you've raised.
> What you are worried about is not possible because of the legal requirements of the GPL which Red
> Hat has accepted by using GPL licensed code.
>
> You're stressing out over a non issue... you dont need to stress over this... aka... you can
> relax... it's going to be ok.
>
> If me addressing your concerns and telling you that you dont need to worry is disrespectful...
> well... I'm sorry that you think I'm being disrespectful. I'm trying to make you feel better by
> explaining that you dont need to be worried.
>
I did say I tried this, but nobody is listening...
Attached:
One mage saying Download/Signup
One image when you click on download at no cost and you need to login or create an account.
Beauty of using clean VM's
https://pasteboard.co/eCfDDb13IIOL.png
https://pasteboard.co/AXwSb6XWmeTN.png
Regards
Phil
Associations:
* Debian Maintainer (DM)
* Fedora/EPEL Maintainer.
* Contributor member of the AlmaLinux foundation.
WWW: https://kathenas.org
Buy Me a Coffee: https://www.buymeacoffee.com/kathenasorg
Twitter: @kathenasorg
Instagram: @kathenasorg
IRC: kathenas
GPG: 724AA9B52F024C8B
1 year