Closed smoe closed 1 year ago
Could we also please consider the equivalent Fedora patch list: https://src.fedoraproject.org/rpms/boinc-client/tree/master
We were directed to that list during last week's contributor call, because it currently contains patches which were rejected by 'upstream' BOINC, but considered appropriate for the Fedora target audience. They perhaps fall into your third category.
I am the author of Fedora/EPEL patches. @RichardHaselgrove has well described why we ship them
With PR #3285 there shall now be a bit of a break as I get the impression that besides some rather easy ones there are already enough discussion points from which us Debian folks can learn about your preferred form and content of patches. Also, the imho most important bits you have seen, @LocutusOfBorg may find some more. The branches from which the respective pull requests are correspond to the file names in debian/patches.
Ah, this seems to explain why my BOINC manager quit starting BOINC in Fedora. I now just run boinc_client every time I log into Gnome and then have boinc manager connect to localhost where this all used to just happen automatically before by having boinc-manager as a startup app in gnome.
Ah, this seems to explain why my BOINC manager quit starting BOINC in Fedora.
@vwbusguy , I fail to grasp what exactly makes your boincmgr unhappy.
I just grabbed the source there and removed two patches from the spec and rebuilt - the first that prevents idle detection and the other that prevents the boinc manager from starting the boinc_client and now everything is happy again.
With respect to the FP package maintainer, I'm willing to setup a copr repository with these patches removed if it might be helpful for others that prefer the upstream capabilities.
@smoe - The problem seems to be with the Fedora patches, not the upstream boinc code. It seems the package maintainer expects that the only valid way to start BOINC should be through systemd and not through the boinc-manager, whereas both methods were previously options. The result was the creation of a patch that simply removed boinc-manager's abaility to start boinc-client even though the option remains in the GUI. Further, they hijacked idle detection because of an SELinux conflict rather than fixing the SELinux policy itself to allow it to function.
@vwbusguy, just FY, there were a lot of hot discussions about this functionality:
Thanks for the context, @AenBleidd. Removing those two patches that were added in the Fedora packaging have made my user experience with boinc-manager much better. If it's useful to anyone else, I'll fork it into a copr repo, so other Fedora users will have a choice between the upstream functionality and the Fedora maintainer's expectation on the behavior.
This comment here nails it: https://github.com/BOINC/boinc/pull/3028#issuecomment-470269114
Thank you, @vwbusguy - I think you've caught the essence of the arguments I've been making in the conference calls referred to in #3105 and elsewhere.
I do think that the long-term solution is to have parallel installation tools - one for the 'closed' target audience, where institutional users don't have permission to manage systemd services, and the other for the 'open' target audience, where users have full ownership and control of their own machines.
The 'open' audience - which I think Scott would class himself as a member of - has become used to having all files accessible in the user's home area, from the old but unmaintained v7.2.42 offered on BOINC's website. If, in effect, you are offering to replace that with a build from modern sources, the offer is awesome, and I thank you again.
But I do think we should consider this thoroughly before rushing into it, with an eye to documentation, future maintainability, and keeping the complexity and signposting to a minimum for new recruits to the world of BOINC. The next conference call is due to be held on 3 October, but at a time of day (early morning) which might be called inconsiderate in your timezone. But if you were able to subscribe to https://groups.google.com/a/ssl.berkeley.edu/forum/#!forum/boinc_dev, and watch out for the calling notice for the 17 October meeting, I'm sure we could ask @TheAspens and Keith Uplinger to reserve an agenda slot for this discussion.
@RichardHaselgrove To be clear, all I have done is taken the build that is currently shipped in Fedora and removed a couple of the patches added by @Germano0. The current version in Fedora is 7.16.1, so I'm not sure what would be different from 7.3.42. it's not what I've added, but rather I'm actually using something much closer to upstream.
https://src.fedoraproject.org/rpms/boinc-client/tree/master is the reference to the patches that Fedora users currently get if installed through Fedora or EPEL repos. Among other things, these packages now remove the ability for boinc to do idle detection in Fedora and for the ability for the BOINC manager to start the client at all. These packages did not always work this way, but it seems these changes were implented incrementally over the past six months, meaning that almost every Fedora update this year has removed functionality from boinc client/manager bit by bit and often apart from upstream code.
Ah. You're not the only one - I'm currently running another de-patched Manager, prepared by somebody else for exactly the same reasons. I think the bug I just reported in #3310 is also related to the changes over the last six months. We definitely need to decide on a plan to handle all this upstream.
Further, they hijacked idle detection because of an SELinux conflict rather than fixing the SELinux policy itself to allow it to function.
"Allow it to function"? BOINC client user idle time detection has never worked properly by running stat command on /dev/input device files. Please read https://github.com/BOINC/boinc/issues/1187#issuecomment-499520344
With respect to the FP package maintainer, I'm willing to setup a copr repository with these patches removed if it might be helpful for others that prefer the upstream capabilities.
No problem
@Germano0 - I don't know what to tell you. It's running fine for me now on my laptop on Fedora 30 without that patch. It's running docked with three displays, usb keyboard and mouse, and two chargers plugged in, and the idle detection still works. After removing the patch, I no longer have to manually toggle GPU processing on and off, which was highly tedious.
Every custom distro patch should be discussed and reviewed separately. I see no reason to keep this ticket open
So far so obvious, there should not be any need for a distro's packages to have any patches since all changes are either:
I would like to leave this issue here as an anchor and over time revisit all patches that have accumulated downstream over the past decade for Debian and Fedora.