On 23.7.2020 19:00, Adam Williamson wrote:
On Thu, 2020-07-23 at 01:42 +0000, Jóhann B. Guðmundsson wrote:
On 22.7.2020 23:40, Adam Williamson wrote:
On Wed, 2020-07-22 at 15:46 -0600, Chris Murphy wrote:
On Wed, Jul 22, 2020 at 1:11 PM Adam Williamson
<adamwill@xxxxxxxxxxxxxxxxx> wrote:
On Wed, 2020-07-22 at 11:46 -0600, Chris Murphy wrote:
Is is possible there's a significant minority who have workflows that
explicitly depend on chrony? If it's not possible, then I'd support
the working group just making the substitution for Workstation 33.
We literally just got done rewriting
https://fedoraproject.org/wiki/QA:Testcase_base_service_manipulation
(and the automated version of that test) to use chronyd on the basis
that it's a reliable service that we can rely on to exist in all tested
editions :/
Find and replace? :D
@core services
dnf-makecache.timer
auditd.service
plymouth-start.service
chrony isn't in either @core or @standard groups. It's in
server-product and workstation-product (anaconda-tools and
system-tools). But it may not be in Cloud, IoT, or CoreOS. I'm not
sure.
It's in everything we run the test on. We checked.
You don't get any more reliable service that exist in all tested
editions current and in the future other than those that come with the
system management framework as in you don't have to worry about specific
component being installed which might be subjected removal or being
broken due to some change which would break all the test right.
So what made QA choose Chrony in the first place?
"it's a reliable service that we can rely on to exist in all tested
editions". At least, that was the best candidate we could come up with.
We used to use sshd, but that became a problem because some tested
image (I forget which) no longer includes it.
I didn't suggest anything internal to systemd because a) it's at least
plausible there could be some kind of incompatibility issue which was
hidden on systemd-internal services, and b) the set of systemd services
we actually include and enable out of the box isn't particularly
consistent or reliable.
I'm not aware of any component of the systemd stack being exclude ( all
of them get shipped but might be enabled ) so I'm curious of what they
might be?
Timesyncd would be a perfect candidate as I had previously mentioned
elsewhere in this thread and this would probably break immediately in
Dracut if it would not work ( You probably have noticed now a bunch of
deprecation warning emitting in type units that reside in Dracut in the
bootup on F33, fixes pending upstream, Harald is probably on vacation
since they have not be merged yet ) so QA should be focusing more on
testing services that are being shipped in every edition as in if they
work or not ( but that ofcourse is much more work ).
JBG
_______________________________________________
desktop mailing list -- desktop@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to desktop-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/desktop@xxxxxxxxxxxxxxxxxxxxxxx
