* Does the service require post-rpm-installation configuration in order to be useful (for example, does it need manual edits to a configuration file)? No, it doesn't. * Does the service listen on a network socket for connections originating on a separate physical or virtual machine? No, it does not. * Is the service non-persistent (i.e. run once at startup and exit)? No, it runs and stays running if the machine has certain capabilities (dual-GPU support via the switcheroo kernel interface) * What is the exact name (or names) of the systemd unit files to be enabled? switcheroo-control.service * Is this request for all Fedora deliverables or only for some Editions (list them)? It's required for Fedora Workstation (and likely other graphical spins)
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.