From: Robin Roevens <robin.roevens@disroot.org>
To: development@lists.ipfire.org
Subject: [PATCH v2 0/5] Fix Bug#12935 + cosmetic changes/enhancements
Date: Thu, 06 Oct 2022 19:59:53 +0200 [thread overview]
Message-ID: <20221006175958.11036-1-robin.roevens@disroot.org> (raw)
[-- Attachment #1: Type: text/plain, Size: 2591 bytes --]
Hi all
After processing, tackling and implementing all remarks Michael gave
about previous version, I hereby present you v2 of this patchset.
As the other patchset that I submitted, containing small cosmetic
changes on services.cgi, depended on v1 of this patchset; I have now
included those changes in this set instead of reposting those again as a
seperate set. Those cosmetics (patch 3-5) are not part of the fix for
bug#12935.
I'm quite confident that the code of addonctrl is now much
better/cleaner by implementing and handling Michael's concerns. There
is now even more errorchecking going on (mainly for system errors).
I know Core 171 went in Testing, but as there currently are already 2
bugreports concering this fix (#12916 was also linked to this today);
I'm assuming quite a few IPFire users are currently experiencing
problems with the services.cgi page. So, if possible and feasable, I
think it would be a good idea to try to include this one in CU171 (at
least patch 1 and 2) ?
If there are still concerns/remarks about this new version, I'll try to
handle them asap.
For reference, the content of the summary mail that was sent with v1 of
the patch:
---
This patchset fixes Bug#12935
(https://bugzilla.ipfire.org/show_bug.cgi?id=12935)
Summary:
Addons where the initscript does not match the addon-name and addons with
multiple initscripts are now listed on services.cgi since CU170.
But addonctrl still expected addon name to be equal to
initscript name; Hence starting/stopping/enabling/disabling of such
addons was not possible.
This has always been like that, but that problem was hidden as
services.cgi also did not display those addon services.
After discussing this with Adolf on the Bug report, we concluded that we
should adapt addonctrl to work with the new addon metadata
Services-field instead.
I basically rewrote addonctrl to not only use the new services metadata
but also to have better errorchecking and added the posibility to check
if a service is currently enabled or disabled.
As a result services.cgi no longer has to go checking the precense of
runlevel initscripts, but can just ask addonctrl.
I also added a warning to services.cgi if a runlevel initscript does not
exists, to prevent the user from wondering why he can't enable a
specific service. (Adolf pointed out some services don't install
runlevel initscripts by default)
More details in the bugreport and in the commit-messages of the patches.
---
Regards
Robin
--
Dit bericht is gescanned op virussen en andere gevaarlijke
inhoud door MailScanner en lijkt schoon te zijn.
next reply other threads:[~2022-10-06 17:59 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-06 17:59 Robin Roevens [this message]
2022-10-06 17:59 ` [PATCH v2 1/5] misc-progs: addonctrl: Add support for 'Services' metadata Robin Roevens
2022-10-07 15:01 ` Michael Tremer
2022-10-08 23:09 ` Robin Roevens
2022-10-10 10:04 ` Michael Tremer
2022-10-10 12:27 ` Robin Roevens
2022-10-10 13:27 ` Michael Tremer
2022-10-06 17:59 ` [PATCH v2 2/5] services.cgi: Fix status/actions on services with name != addon name Robin Roevens
2022-10-06 17:59 ` [PATCH v2 3/5] services.cgi: minor cosmetics Robin Roevens
2022-10-06 18:52 ` Bernhard Bitsch
2022-10-06 17:59 ` [PATCH v2 4/5] services.cgi: add restart action and restrict action usage Robin Roevens
2022-10-06 17:59 ` [PATCH v2 5/5] services.cgi: add link to addon config if ui exists for it Robin Roevens
2022-10-06 18:48 ` Bernhard Bitsch
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20221006175958.11036-1-robin.roevens@disroot.org \
--to=robin.roevens@disroot.org \
--cc=development@lists.ipfire.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox