Heads-up: grpc 1.41.0 coming to Rawhide with C (core) and C++ soname
bumps
by Ben Beasley
In one week (October 6), or slightly later, I will build grpc 1.41.0 for
Rawhide (F36). Fedora 35 will remain on 1.39.1.
As is traditional for minor releases of grpc, the C++ ABI was broken
(soversion bumped from 1.40 to 1.41). This time, the C (core) ABI was
also broken (soversion bumped from 18 to 19).
I will coordinate builds in a side tag of packages that use the C (core)
and/or C++ libraries. Maintainers of the following packages should have
received this email directly:
• bear
• frr
• perl-grpc-xs
Packages that use the Python bindings should be unaffected, as there
should be no incompatible API changes:
• buildstream
• python-chirpstack-api
• python-etcd3
• python-google-api-core
• python-google-cloud-core
• python-grpc-google-iam
• python-opencensus (orphaned)
• python-opencensus-proto
• python-opentelemetry
• python-pytest-grpc
• python-xds-protos
1 year, 11 months
F37 Change: Enable read only /sysroot for Fedora Silverblue & Kinoite
(Self-Contained Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/Silverblue_Kinoite_readonly_sysroot
== Summary ==
This change is about enabling an opt-in ostree feature that re-mounts
`/sysroot` as read only to avoid accidental changes.
Users and administrators are not expected to directly interact with
the content available there and should instead use the interface
offered by rpm-ostree, GNOME Software or (soon) Plasma Discover to
manage their system.
== Owner ==
* Name: [[User:Siosm| Timothée Ravier]], [[User:Tpopela| Tomáš
Popela]], [[User:jkonecny| Jiří Konečný]]
* Email: siosm(a)fedoraproject.org, tpopela(a)fedoraproject.org, jkonecny(a)redhat.com
* FESCo shepherd: [[User:Ngompa| Neal Gompa]] ngompa(a)fedoraproject.org
== Detailed Description ==
On rpm-ostree based systems, the real root (the root directory of the
root partition on the disk) is mounted under the `/sysroot` path. By
default it contains the state of the system (the content of `var` and
`etc`) as well as the system versions themselves (each versioned copy
of `/usr`) in the ostree repository (`/ostree/repo`).
This change is about enabling an opt-in ostree feature that re-mounts
`/sysroot` as read only to avoid accidental changes.
Users and administrators are not expected to directly interact with
the content available there and should instead use the interface
offered by rpm-ostree, GNOME Software or (soon) Plasma Discover to
manage their system.
Example of issue: https://github.com/fedora-silverblue/issue-tracker/issues/232
This change replicates for Fedora Silverblue/Kinoite what has been
done in Fedora CoreOS in a previous release.
== Feedback ==
None so far.
== Benefit to Fedora ==
This will make Fedora Silverblue/Kinoite more robust to accidental
damage from users.
== Scope ==
* Proposal owners:
** Work on the changes requires for new installations (potentially
Anaconda configuration changes) and support for in place updates for
existing installations (requires a two step process).
* Other developers:
** Potential Anaconda changes required.
* 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 Objectives: N/A
== Upgrade/compatibility impact ==
We will create a systemd unit that perform the updates in place for
existing systems. This will require a two step process (changing the
existing kernel arguments, and then enabling the ostree feature). Once
the feature is enabled, user won't be able to rollback to previous
deployments where the kernel argument is not set. We will have to
clearly document that in the documentation for easier troubleshooting.
== How To Test ==
Only try the following if you are confortable debugging an un-bootable
system and have made backups!
`$ sudo rpm-ostree kargs --append-if-missing=rw`
`$ sudo ostree config --repo=/sysroot/ostree/repo set "sysroot.readonly" "true"`
`$ sudo systemctl reboot`
Note that you can not "rollback" to the previous deployment to undo
this change. You will have to boot into a Live ISO and edit the config
file in the ostree repo to remove this config option.
== User Experience ==
There should be no visible change in user experience.
== Dependencies ==
Requires changes in Anaconda (maybe just config?) to set default kargs
and property on ostree repo for new installations.
== Contingency Plan ==
Revert the change before the release.
== Documentation ==
N/A (not a System Wide Change)
== Release Notes ==
TODO
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
1 year, 11 months
VERY late notification emails
by Richard Shaw
I almost wrote this a week ago but decided not to as it's been recently
discussed but this is really annoying. 6 days later is more than useless.
Previously it was blamed, at least partially, on the mass rebuild, but
clearly that should no longer be an issue by now?
I know I can turn them off, but I actually LIKE the messages if they were
delivered promptly.
Is there really nothing we can do about this?
Thanks,
Richard
---------- Forwarded message ---------
From: <notifications(a)fedoraproject.org>
Date: Sun, Feb 27, 2022 at 6:09 PM
Subject: hobbes1069's mingw-fltk-1.3.8-1.fc36 completed
To: <hobbes1069(a)gmail.com>
Notification time stamped 2022-02-21 13:42:00 UTC
hobbes1069's mingw-fltk-1.3.8-1.fc36 completed
http://koji.fedoraproject.org/koji/buildinfo?buildID=1921324
2 years
Do we have any policy for disabling inactive users
by Mattia Verga
Just being paranoid here: do we have any policy / automatism for
disabling "power" users (in packager group or like) which have been
inactive for long time?
I'm no security expert, but an inactive user account may be hacked
without noticing and if such account have powers like being in the
packager group may inject bad things in the distribution.
I also imagine the case where a user no more use their email address and
that become available to someone else. The new user may easily reset the
password and gain access to the old Fedora account (provided that the
old user didn't use 2fa).
Does it make sense to start thinking to prune inactive packagers without
waiting someone to start the "unresponsive maintainer policy"? Maybe a
script could check user activities in src.fedoraproject.org and send a
warning email if no activity is made in one year?
Mattia
2 years
GNOME (and Cinnamon) issues in Rawhide: status report, including
gnome-bluetooth soname issues
by Adam Williamson
Hey folks! While we're working through fixing this up, I wanted to send
out a note about what's going on.
tl;dr summary: GNOME is broken in Rawhide, and blueberry (Cinnamon's
bluetooth app) may have dep issues temporarily. If you need GNOME to
work, downgrade gnome-shell and mutter. Otherwise, apologies for the
rough ride, hold onto your hats, we're trying to get things fixed up.
Full version: gnome-shell and mutter 42~beta builds were run yesterday.
For Fedora 36 they were done in a sidetag, but for Rawhide, no sidetag
yet existed, so unfortunately they went straight to the main Rawhide
tag and were included in yesterday's compose.
It turns out having those packages at 42~beta but older versions of
other packages gives you a broken GNOME; anyone who updated to Rawhide
yesterday will likely see GNOME crash to the "Oh no!" screen on boot.
To deal with that for now, the best thing to do is to downgrade gnome-
shell and mutter back to the previous builds from Koji.
Since the builds have been in a compose, we can't untag them from
Rawhide, we can only move forwards. So we're trying to build enough of
the rest of GNOME 42~beta to get things working again, but it turns out
quite a lot of stuff needs to be built for that.
A particular pain point is gnome-bluetooth. gnome-shell 42~beta needs
gnome-bluetooth 42, but the new gnome-bluetooth changes the library
API. We noticed that Cinnamon's bluetooth app, blueberry, is built
against the old gnome-bluetooth API, and there are no patches upstream
to handle this.
That left us in an awkward spot. Ideally what should happen is the
gnome-bluetooth soname bump would be announced and Leigh would have a
week to figure out what to do for blueberry/cinnamon. But if we do that
now, GNOME would be broken for a week in Rawhide, which is not ideal.
The solution we decided on is to bump gnome-bluetooth to 42~beta, but
add a gnome-bluetooth3.34 compat package, which should keep blueberry
working until Cinnamon folks can come up with a plan. David King
submitted the package, and I reviewed it:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2039855
and it should be built soon. blueberry will need to be rebuilt with its
deps changed a bit, but that should be all. It would be ideal if Leigh
could take over maintenance of this package as long as it's needed.
As things stand right now, gnome-bluetooth 42~beta is built for Rawhide
but gnome-bluetooth3.34 is not yet; depending on exactly when we get it
built it may just miss today's compose, meaning Cinnamon image compose
would be broken for that day, and updates of Rawhide Cinnamon systems
to that day's packages would likely have issues. Most of the other
packages we think we need to build to make GNOME work again are done,
but gnome-control-center is proving tricky; I got some work done
towards getting it to build, but wasn't able to get it all the way, so
I've left a couple of PRs:
https://src.fedoraproject.org/rpms/colord-gtk/pull-request/1
https://src.fedoraproject.org/rpms/gnome-control-center/pull-request/10
and David is going to pick it up and move forward. I'll check back in
in the morning.
Thanks folks, and sorry again for the trouble!
--
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net
2 years, 1 month
F36 Beta blocker status summary
by Ben Cotton
Now that we've reached the branch point, it's time to start doing
weekly blocker summaries again! Beta freeze begins on 22 February and
the current target Beta release date is 15 March.
Action summary
====================
Accepted blockers
-----------------
1. anaconda — When running anaconda on Wayland with two keyboard
layouts configured, hitting any modifier key with the second layout
selected switches to the first layout — ASSIGNED
ACTION: Maintainers to diagnose issue
2. distribution — Fedora 36 backgrounds not present on
release-blocking desktops (GNOME, KDE) — NEW
ACTION: Maintainers to update background packages
3. fedora-release — fedora-release-identity-cloud says "Cloud
Edition", Cloud has not been an edition for years — NEW
ACTION: Maintainers to update fedora-release-identity-cloud or
group-with-such-authority to waive this.
4. kwin — openQA clicks in anaconda on KDE stop working shortly after
it starts — NEW
ACTION: Maintainers to diagnose issue
5. libinput — GNOME doesn't accept input from wireless keyboard if
there's not another "keyboard" input available — NEW
ACTION: Maintainers to diagnose issue
6. linux-firmware — Fedora 36: Server boot x86_64 image exceeds
maximum size — ASSIGNED
ACTION: None
Proposed blockers
-----------------
1. distribution — Some variants are missing /etc/resolv.conf symlink
(use systemd-resolved) — POST
ACTION: QA to verify issue is resolved
2. dnf — exclude_from_weak_autodetect=true effectively renders rich
weak dependencies useless — NEW
ACTION: dnf maintainers to decide on approach for "instally only newly
recommended packages" proposal
Bug-by-bug detail
=============
Accepted blockers
-----------------
1. anaconda — https://bugzilla.redhat.com/show_bug.cgi?id=2016613 — ASSIGNED
When running anaconda on Wayland with two keyboard layouts configured,
hitting any modifier key with the second layout selected switches to
the first layout
adamwill's research shows that this bug has existed since F25, but
became more viisble after KDE switched to Wayland by default. This bug
was deferred to F36 Beta under the "too hard to fix" exception.
There's ongoing discussion trying to come up with a potential fix,
however we still seem to be a long way from that point.
2. distribution — https://bugzilla.redhat.com/show_bug.cgi?id=2052654 — NEW
Fedora 36 backgrounds not present on release-blocking desktops (GNOME, KDE)
The usual desktop background blocker.
3. fedora-release — https://bugzilla.redhat.com/show_bug.cgi?id=2018271 — NEW
fedora-release-identity-cloud says "Cloud Edition", Cloud has not been
an edition for years
Waived from F35 final under the "late blocker exception." Cloud WG is
working on a proposal to re-promote Cloud to Edition status, but that
will not happen for F36 release cycle.
4. kwin — https://bugzilla.redhat.com/show_bug.cgi?id=2047503 — NEW
openQA clicks in anaconda on KDE stop working shortly after it starts
Shortly after the installer starts, mouse clicks in openQA stop
working. Using 'development mode' which allows for manual interaction
still works. This bug only affects KDE, and appears to have been
introduced in the KDE Plasma 5.24 pre-release on 2022-01-19. This bug
is accepted under the "hinders execution of required Beta test plans"
criterion.
5. libinput — https://bugzilla.redhat.com/show_bug.cgi?id=2017043 — NEW
GNOME doesn't accept input from wireless keyboard if there's not
another "keyboard" input available
On some hardware, devices with multiple capabilities that include
keyboard do not get registered as a keyboard. Thus they only work if
another keyboard is connected. It seems to mostly (or exclusively)
affect some ARM hardware.
6. linux-firmware —
https://bugzilla.redhat.com/show_bug.cgi?id=2031214 — ASSIGNED
Fedora 36: Server boot x86_64 image exceeds maximum size
Fedora-Server-netinst-x86_64-36-20220210.n.0.iso is 731906048 bytes,
which is below the maximum size of 734003200. This bug can probably be
closed until the image exceeds the limit again.
Proposed blockers
-----------------
1. distribution — https://bugzilla.redhat.com/show_bug.cgi?id=2032085 — POST
Some variants are missing /etc/resolv.conf symlink (use systemd-resolved)
Some variants are not using systemd-resolved as intended. With some
recently-merged changes to Anaconda, this appears to be working
correctly now.
2. dnf — https://bugzilla.redhat.com/show_bug.cgi?id=2033130 — NEW
exclude_from_weak_autodetect=true effectively renders rich weak
dependencies useless
Behavior introduced by the "Enable exclude_from_weak_autodetect by
default in LIBDNF" System-Wide Change appear to have undesired effects
in some use cases, particularly with language packs. It appears that a
robust fix is technically difficult, and the Change owners are
discussing reverting this Change for F36 (see BZ 2013327).
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
2 years, 1 month
F37 Change: Curl-minimal as default (System-Wide Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/CurlMinimal_as_Default
== Summary ==
`libcurl-minimal` and `curl-minimal` will be installed by default
instead of `libcurl` and `curl`.
The "minimal" variants provide only a subset of protocols (HTTP, HTTPS, FTP).
The full versions can be explicitly requested as `libcurl-full` and `curl-full`.
== Owner ==
* Name: [[User:Zbyszek| Zbigniew Jędrzejewski-Szmek]]
* Email: zbyszek at in.waw.pl
* Name: [[User:Kdudka| Kamil Dudka]]
* Email: kdudka at redhat.com
== Detailed Description ==
The `curl` package provides two sets of subpackages: `curl`+`libcurl`
and `curl-minimal`+`libcurl+minimal`.
`curl-minimal`+`libcurl-minimal` are compiled with various
semi-obsolete protocols and infrequently-used features disabled:
DICT, GOPHER, IMAP, LDAP, LDAPS, MQTT, NTLM, POP3, RTSP, SMB, SMTP,
SFTP, SCP, TELNET, TFTP, brotli compression, IDN2 names.
(Both variants support HTTP, HTTPS, and FTP.)
`curl-minimal` has `Provides:curl` and `libcurl-minimal` has `Provides:libcurl`.
This means that both sets can be used to satisfy a dependency on
`curl` or `libcurl`.
`curl` has the virtual `Provides:curl-full` and `libcurl` has the
virtual `Provides:libcurl-full`.
The user or another package can explicitly pull in the full variants,
e.g. with `dnf install curl-full`
or `Requires: libcurl-full`.
With this change, `Suggests: libcurl-minimal` or `Suggests:
curl-minimal` will be added to a few packages
that already have a dependency on `libcurl` or `curl`.
Currently, doing this for `systemd` and `rpm` is planned.
Effectively, `dnf` will install the minimal variants, unless another
package has a stronger dependency on the full variants.
== Benefit to Fedora ==
There are two separate motivations for this.
Those infrequently used protocols are less tested than the common ones
and are a source of security bugs.
Most users are not using those protocols anyway, so disabling them
reduces the bug and attack surface.
(In fact, many applications already call `curl_easy_setopt(c,
CURLOPT_PROTOCOLS, …)` to internally
limit what protocols are supported. So even if `libcurl` is swapped
for `libcurl-minimal` for many
uses this will not be a difference.)
The packages for the minimal variants are smaller:
a trivial installation with `curl-minimal`+`libcurl+minimal` is 18 MB
download, 57 MB installed size, 50 packages;
the same with `curl-full` and `libcurl-full` is 21 MB download, 65
installed size, 62 packages.
Thus we save 8 MB, reducing the initial size by 12%.
== Scope ==
* Proposal owners:
Create pull requests to add `Suggests: curl-minimal` or `Suggests:
libcurl-minimal` as appropriate
to packages which already require `curl` or `libcurl`: `rpm` and `systemd`.
This means that any installation (which should be most of them) will
get the minimal variants.
* Other developers:
For packages that use the full variants: add `Recommends: curl-full`
or `Recommends: libcurl-full` or
`Requires: curl-full` or `Requires: libcurl-full` as appropriate.
* Release engineering:
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives:
== Upgrade/compatibility impact ==
Users who use curl or another application which uses libcurl with the
removed protocols will lose support for those protocols. They will
need to explicitly install the full variants.
== How To Test ==
`dnf swap curl curl-minimal` or `dnf swap libcurl libcurl-minimal` and
check that `curl` and other applications using `libcurl` still work.
== User Experience ==
This should be not be noticed by users, except as noted above in
Upgrade/compatibility impact.
== Dependencies ==
== Contingency Plan ==
Remove the additions of Suggests, or even add explicit Recommends or Requires.
* Contingency deadline: any time, possibly even after the final release
* Blocks release? No
== Documentation ==
This page should be enough.
== Release Notes ==
`curl-minimal` and `libcurl-minimal` are installed by default. The
support for various obsolete protocols is unavailable by default
through curl (DICT, GOPHER, IMAP, LDAP, LDAPS, MQTT, NTLM, POP3, RTSP,
SMB, SMTP, SFTP, SCP, TELNET, TFTP, brotli compression, IDN2 names).
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
2 years, 1 month
F37 Change: Boost 1.78 upgrade (System-Wide Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/F37Boost178
== Summary ==
This change brings Boost 1.78 to Fedora. This will mean Fedora ships
with a recent upstream Boost release.
== Owner ==
* Name: [[User:trodgers| Thomas Rodgers]]
* Email: trodgers(a)redhat.com
== Detailed Description ==
The aim is to synchronize Fedora with the most recent Boost release.
Because ABI stability is absent from Boost, this entails rebuilding of
all dependent packages. This also entails the change owner assisting
maintainers of client packages in decoding cryptic boost-ese seen in
output from g++.
The equivalent changes for previous releases were
[[Changes/F35Boost176]], [[Changes/F34Boost175]],
[[Changes/F33Boost173]], [[Changes/F30Boost169|Fedora 30 Change]],
[[Changes/F29Boost167|Fedora 29 Change]], [[Changes/F28Boost166|Fedora
28 Change]], [[Changes/F27Boost164|Fedora 27 Change]],
[[Changes/F26Boost163|Fedora 26 Change]], [[Changes/F25Boost161|Fedora
25 Change]], [[Changes/F24Boost160|Fedora 24 Change]],
[[Changes/F23Boost159|Fedora 23 Change]] and
[[Changes/F22Boost158|Fedora 22 Change]].
== Benefit to Fedora ==
Fedora 37 includes Boost 1.78.
Fedora will stay relevant, as far as Boost clients are concerned.
Boost 1.78 does not bring any new components, but includes two new
header-only libraries from Boost 1.77 -
* Describe: A C++14 reflection library. Provides macros for describing
enumerators and struct/class members, and primitives for querying this
information.
* Lambda2: A C++14, dependency-free, single header lambda library.
Allows simple function objects to be constructed via expressions such
as _1 + 5, _1 % 2 == 0, _1 > _2, or _1 == ' ' || _1 == '\t'.
Boost 1.78 also includes many fixes and enhancements to existing components.
== Scope ==
* Proposal owners:
** Build will be done with Boost.Build v2 (which is the
upstream-sanctioned way of building Boost)
** Request a "f37-boost"
[https://docs.pagure.org/releng/sop_adding_side_build_targets.html
build system tag]
([http://lists.fedoraproject.org/pipermail/devel/2011-November/159908.html
discussion]):
** Build boost into that tag (take a look at the
[http://koji.fedoraproject.org/koji/buildinfo?buildID=606493 build
#606493] for inspiration)
** Post a request for rebuilds to fedora-devel
** Work on rebuilding dependent packages in the tag.
** When most is done, re-tag all the packages to rawhide
** Watch fedora-devel and assist in rebuilding broken Boost clients
(by fixing the client, or Boost).
* Other developers:
** Those who depend on Boost DSOs will have to rebuild their packages.
Feature owners will alleviate some of this work as indicated above,
and will assist those whose packages fail to build in debugging them.
* Release engineering: TODO <!-- [https://pagure.io/releng/issue/9421
#9421] --> (a check of an impact with Release Engineering is needed)
* Policies and guidelines:
** Apart from scope, this is business as usual, so no new policies, no
new guidelines.
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
* No manual configuration or data migration needed.
* Some impact on other packages needing code changes to rebuild.
Historically this hasn't been too much of a problem and could always
be resolved before deadline.
== How To Test ==
* No special hardware is needed.
* Integration testing simply consists of installing Boost packages
(`dnf install boost`) on Fedora and checking that it does not break
other packages (see below for a way to obtain a list of boost
clients).
== User Experience ==
* Expected to remain largely the same.
* Developers building third-party software on Fedora may need to
rebuild against the new Boost packages, and may need to adjust their
code if the new Boost release is not source-compatible.
== Dependencies ==
Packages that must be rebuilt:
<code>$ dnf repoquery -s --releasever=rawhide --whatrequires
libboost\* --disablerepo=* --enablerepo=fedora | sort -u</code>
All clients:
<code>$ dnf repoquery --releasever=rawhide --archlist=src
--whatrequires boost-devel --disablerepo='*'
--enablerepo=fedora-source</code>
== Contingency Plan ==
* Contingency mechanism: Worst case scenario is to abandon the update
and simply ship F37 with Boost 1.76, which is already in rawhide.
* Blocks release? No
* Blocks product? None
== Documentation ==
* https://www.boost.org/users/history/version_1_78_0.html (released on
8th December 2021)
* https://www.boost.org/users/history/version_1_77_0.html (released on
11 August 2021)
* https://www.boost.org/development/index.html
== Release Notes ==
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
2 years, 1 month