Bug 1389762

Proposed as a Blocker and Freeze Exception for 25-final by Fedora user hadess using the blocker tracking app because:

 Advertised functionality is not working as expected.
References:
http://news.softpedia.com/news/fedora-25-linux-to-offer-better-dual-gpu-integration-in-the-gnome-3-22-desktop-509680.shtml

This meets all the requirements of auto-acceptance, so I'll take it and get a PR ready for fedora-release.

I'm going to put this in the default preset for all Fedora Editions for now. If Server decides to disable it in their preset, we can modify that later.

https://pagure.io/fedora-release/pull-request/59 (Rawhide)
https://pagure.io/fedora-release/pull-request/60 (F25)

FYI, you haven't given any reason to treat this as a blocker. When filing something as a potential blocker, please cite the blocker criterion that you think it is failing:

https://fedoraproject.org/wiki/Fedora_25_Alpha_Release_Criteria
https://fedoraproject.org/wiki/Fedora_25_Beta_Release_Criteria
https://fedoraproject.org/wiki/Fedora_25_Final_Release_Criteria

As of right now, I'm assuming that this new feature doesn't work, but dual-GPU systems aren't generally broken. If that's the case, I'm -1 blocker, +1 FE.

Those aren't linked from the form I filled in. FWIW, it's worse than a regression when a new feature doesn't work as (quite widely) advertised.

(In reply to Bastien Nocera from comment #5)
> Those aren't linked from the form I filled in. FWIW, it's worse than a
> regression when a new feature doesn't work as (quite widely) advertised.

If you used https://qa.fedoraproject.org/blockerbugs/propose_bug (which the comment indicates) those pages are linked.

That being said, as long as this hasn't *broken* existing functionality, it's not a blocker. I'm still fine with +1 Freeze Exception.

If you really feel that getting this working needs to be a blocker, contact FESCo and ask for them to make a ruling. They're the only group with privilege to assert blocker status without a previously-written criterion.

At this point, I'd say that it's likely just academic, since if all that was missing was the preset, then this is basically solved (just waiting for a merge so we can test it). We're not even in Freeze yet, so if this gets merged before next Tuesday, all should be well.

Yeah, I wouldn't sweat the blocker bureaucracy at this point. We clearly have enough time to make the release here.

Discussed during the 2016-10-31 blocker review meeting: [1]

The decision to classify this bug as a RejectedBlocker and an AcceptedFreezeException was made as the bug does not fit any existing criteria; incomplete changes are not inherently release blocking. However, this will be classified as an AcceptedFreezeException.

Note that FESCo can declare this bug a blocker if so chosen to.

[1] https://meetbot.fedoraproject.org/fedora-blocker-review/2016-10-31/f25-blocker-review.2016-10-31-16.01.txt

fedora-release-25-0.12 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2016-399b120d6e

fedora-release-25-0.14 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2016-bdcaf5493c

fedora-release-25-0.12 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-399b120d6e

fedora-release-25-0.14 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-bdcaf5493c

Just for the record, adding this service introduces a different bug: switcheroo-control exits 1 if there is "No switcheroo support available" (i.e. the system doesn't have hybrid graphics), which causes the service to fail.

The relevant criterion has a get-out clause - "All system services present after installation with one of the release-blocking package sets must start properly, unless they require hardware which is not present." - so it's not technically a blocker, but this is still dumb, we shouldn't have a service which we know full well will fail on many machines. We should tweak either switcheroo-control or the service somehow not to fail in this case. I will file a separate bug.

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

<kwizart> adamw, switcheroo-control.service isn't automatically loaded, (despite having the workstation 25-0
<kwizart> 25-0.14 rpm
<adamw> kwizart: mmf, i suppose it may be missing a scriptlet to handle updates
<adamw> try 'systemctl preset switcheroo-control.service' or similar

(In reply to Adam Williamson from comment #15)
> <kwizart> adamw, switcheroo-control.service isn't automatically loaded,
> (despite having the workstation 25-0
> <kwizart> 25-0.14 rpm
> <adamw> kwizart: mmf, i suppose it may be missing a scriptlet to handle
> updates
> <adamw> try 'systemctl preset switcheroo-control.service' or similar

That's not its job though. It does run "preset" on install. fedora-release is supposed to update the preset services, no? (I mean, how would the switcheroo-control package know that its preset changed, it didn't install it)

(In reply to Bastien Nocera from comment #16)
> (In reply to Adam Williamson from comment #15)
> > <kwizart> adamw, switcheroo-control.service isn't automatically loaded,
> > (despite having the workstation 25-0
> > <kwizart> 25-0.14 rpm
> > <adamw> kwizart: mmf, i suppose it may be missing a scriptlet to handle
> > updates
> > <adamw> try 'systemctl preset switcheroo-control.service' or similar
> 
> That's not its job though. It does run "preset" on install. fedora-release
> is supposed to update the preset services, no? (I mean, how would the
> switcheroo-control package know that its preset changed, it didn't install
> it)

We can't run the preset on update because that command resets user-specified operations. So if a user had previously run `systemctl disable switcheroo-control.service` manually, running `systemctl preset` results in it being re-enabled. This would be unexpected by an end-user.

I don't think it's possible to detect whether such a manual change has been made, either.

So the best we can do is ensure that new installations have the preset properly loaded and tell people who are upgrading from a pre-release to either manually run `systemctl preset`, `systemctl preset switcheroo-control.service` or `systemctl enable switcheroo-control.service` and then run `systemctl start switcheroo-control.service` or reboot.

(In reply to Bastien Nocera from comment #16)
> (In reply to Adam Williamson from comment #15)
> > <kwizart> adamw, switcheroo-control.service isn't automatically loaded,
> > (despite having the workstation 25-0
> > <kwizart> 25-0.14 rpm
> > <adamw> kwizart: mmf, i suppose it may be missing a scriptlet to handle
> > updates
> > <adamw> try 'systemctl preset switcheroo-control.service' or similar
> 
> That's not its job though. It does run "preset" on install. fedora-release
> is supposed to update the preset services, no? (I mean, how would the
> switcheroo-control package know that its preset changed, it didn't install
> it)

we do not change services post system install so we do not undo user changes, in this case it may be worth getting a exception from FESCo to enable reseting the preset for switcheroo-control.service  it would mean that users who disable it will get it re-enabled on updates and can not realistically disable it if there is problems outside forcing it to be removed

Meh, since it's only been there for like a week or two, probably not worth it, we can just mention it on a mailing list or something as sgallagh said.

Created attachment 1217085 [details]
patch to add trigger script to re-preset on upgrades

When upgrading from old fedora-release:

$ systemctl list-unit-files switcheroo-control.service
UNIT FILE                  STATE   
switcheroo-control.service disabled

$ sudo dnf upgrade ./switcheroo-control-1.0-2.fc26.x86_64.rpm ./fedora-release-26-0.4.noarch.rpm
...

$ systemctl list-unit-files switcheroo-control.service
UNIT FILE                  STATE  
switcheroo-control.service enabled

Check that state is preserved on subsequent upgrades: 

$ sudo systemctl disable switcheroo-control.service
Removed /etc/systemd/system/graphical.target.wants/switcheroo-control.service.

$ systemctl list-unit-files switcheroo-control.service
UNIT FILE                  STATE   
switcheroo-control.service disabled

$ sudo dnf reinstall ./switcheroo-control-1.0-2.fc26.x86_64.rpm
...

$ systemctl list-unit-files switcheroo-control.service
UNIT FILE                  STATE   
switcheroo-control.service disabled

This version is for rawhide, for F25 fedora_release_min_version should be 25-0.14.

generic-release-25-1 fedora-release-25-1 fedora-repos-25-1 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2016-7b70ad9b8e

(In reply to Zbigniew Jędrzejewski-Szmek from comment #20)
> Created attachment 1217085 [details]
> patch to add trigger script to re-preset on upgrades
> 
> When upgrading from old fedora-release:
> 
> $ systemctl list-unit-files switcheroo-control.service
> UNIT FILE                  STATE   
> switcheroo-control.service disabled
> 
> $ sudo dnf upgrade ./switcheroo-control-1.0-2.fc26.x86_64.rpm
> ./fedora-release-26-0.4.noarch.rpm
> ...
> 
> $ systemctl list-unit-files switcheroo-control.service
> UNIT FILE                  STATE  
> switcheroo-control.service enabled
> 
> Check that state is preserved on subsequent upgrades: 
> 
> $ sudo systemctl disable switcheroo-control.service
> Removed
> /etc/systemd/system/graphical.target.wants/switcheroo-control.service.
> 
> $ systemctl list-unit-files switcheroo-control.service
> UNIT FILE                  STATE   
> switcheroo-control.service disabled
> 
> $ sudo dnf reinstall ./switcheroo-control-1.0-2.fc26.x86_64.rpm
> ...
> 
> $ systemctl list-unit-files switcheroo-control.service
> UNIT FILE                  STATE   
> switcheroo-control.service disabled
> 
> This version is for rawhide, for F25 fedora_release_min_version should be
> 25-0.14.

This really isn't necessary, it turns out. The only people at risk for this are those who installed the switcheroo-control package before fedora-release was updated (which basically means people who updated a prerelease of Fedora 25 in the last week). That's a small enough sample set of people who *did* click through the prerelease timbuktu warning that I don't think there's a desperate need to account for it.

Anyone upgrading from Fedora 24 or earlier will install the package for the first time during the upgrade and its %systemd_post macro will cause the preset to be applied.

fedora-release-25-0.12 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report.

I think we need 0.14, right?

fedora-release-25-1, fedora-repos-25-1, generic-release-25-1 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-7b70ad9b8e

fedora-release-25-1, fedora-repos-25-1, generic-release-25-1 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report.

fedora-release-25-0.12 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report.