stable

sssd-2.7.0-1.fc36

FEDORA-2022-cdc3365ffc created by pbrezina 2 years ago for Fedora 36

Rebase to latest upstream release.

Release notes: https://sssd.io/release-notes/sssd-2.7.0.html

How to install

Updates may require up to 24 hours to propagate to mirrors. If the following command doesn't work, please retry later:

sudo dnf upgrade --refresh --advisory=FEDORA-2022-cdc3365ffc

This update has been submitted for testing by pbrezina.

2 years ago

This update's test gating status has been changed to 'waiting'.

2 years ago

This update's test gating status has been changed to 'failed'.

2 years ago

This update's test gating status has been changed to 'passed'.

2 years ago

This update has been pushed to testing.

2 years ago
karma
User Icon mhayden commented & provided feedback 2 years ago
karma

No issues found.

This update can be pushed to stable now if the maintainer wishes

2 years ago
User Icon kruton commented & provided feedback 2 years ago
karma

The update works, but having f36 in testing and f35 in production creates a problem when doing a dnf system-upgrade from f35 to f36 now.

This update has been submitted for stable by bodhi.

2 years ago
User Icon bojan commented & provided feedback 2 years ago
karma

Works.

Now it seems this is having a problem...

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2078243

systemctl status sssd ○ sssd.service - System Security Services Daemon Loaded: loaded (/usr/lib/systemd/system/sssd.service; enabled; vendor preset: enabled) Active: inactive (dead) Condition: start condition failed at Sun 2022-04-24 21:04:16 -03; 1h 10min ago ├─ ConditionPathExists=|/etc/sssd/sssd.conf was not met └─ ConditionDirectoryNotEmpty=|/etc/sssd/conf.d was not met

systemd[1]: sssd.service - System Security Services Daemon was skipped because all trigger condition checks failed.

Let me explain my situation: five days ago I was running a F36 kde upgraded from F35, and the service was running fine. Since then I have reinstalled F36 KDE with a development iso and using my old /home (btrfs subvolume), and then re-enable the testing repos, thus upgrading again to this version of the package. And today I was aware that this service was not starting correctly.

It looks like SSSD is not configured anymore after you reinstalled the system.

Oops, it looks like this now is expected behavior of this package as dev explained at the bug ticket, sorry for spamming here.

So this was accepted as FE 4 days ago... when it will be pushed to stable?

User Icon filiperosset commented & provided feedback 2 years ago
karma

no regressions noted

User Icon atim commented & provided feedback 2 years ago
karma

FE accepted 6 days ago. Users still can't upgrade because of this issue.

adamwill edited this update.

2 years ago
User Icon adamwill commented & provided feedback 2 years ago

It wasn't pushed at first because we had a viable RC. By policy things that aren't in an RC we might ship cannot be pushed stable, because the frozen release repos must match the contents of the released images.

We declared no-go yesterday and we won't be shipping that RC, so things can be pushed stable again. But it wasn't pushed yesterday because nobody actually marked the update as fixing the bug. That link has to be in place for the tool we use to generate the push requests to include the update in the list.

This update has been pushed to stable.

2 years ago

Please login to add feedback.

Metadata
Type
unspecified
Karma
6
Signed
Content Type
RPM
Test Gating
Settings
Unstable by Karma
-3
Stable by Karma
3
Stable by Time
14 days
Dates
submitted
2 years ago
in testing
2 years ago
in stable
2 years ago
modified
2 years ago
BZ#2077856 package sssd-idp-2.7.0-1.fc35.x86_64 requires sssd-common = 2.7.0-1.fc35, but none of the providers can be installed
0
0

Automated Test Results