Remove Sys V Init support from RPM distribution. by JohanSaaw · Pull Request #106 · LMS-Community/slimserver-platforms

JohanSaaw · 2026-02-24T13:42:25Z

Fedora. RedHat and SUSE moved from Sys V Init to systemd in 2011 (Fedora
v. 15) and 2014 (RHEL7 and openSUSE/SLES 12) respectively.

The LMS RPM package has supported Sys V Init and systemd in parallel since
v. 8.2. The RPM package installs the systemd support by default if the OS
use systemd (users can of course change this after installation, but why
would they?).

I think it is now time to remove the support for Sys V Init. This mainly
means removing the Sys V Init script and some logic in the RPM spec file.

The file /etc/sysconfig/lyrionmusicserver was used to pass basic start-up
configuration to the Sys V Init script. This file has now been replaced
with a stub file pointing to a file explaining how to change the start-up
configuration using systemd drop in files for the systemd unit.

Further changes:

a small fix to the logrotate configuration.
added a dependency on systemd in the RPM spec file (%systemd_requires)

As all the RPM based distributions use systemd now, and have done it for an extended period of time, it is no longer necessary for the Lyrion RPM package to support Sys V Init.

Updated and improved information on how to use systemd drop in files to amend/change the start-up parameters of Lyrion Music Server

The file /etc/sysconfig/lyrionmusicserver was used to configure start-up parameters for the Lyrion Music Server when it was controlled by Sys V Init. The file can also be used by systemd, but it fits very badly in the concept of systemd. It is better not to use it at all. The file is thus replaced by a stub file with some information and a pointer to the README.systemd file.

The use of pgrep in the postrotate section was wrong

The Init script file has been removed. Logic for migrating non-standard Sys V Init configuration to systemd has been removed, The systemd unit file is now properly installed using standard RPM techniques Added dependency on system (%systemd_requires) as the package provides a unit file.

The Sys V Init is outdated. Removed the parallel support of Sys V init. Now only supporting systemd.

Some further small teaks to the explanations to make it more readable.

Made some changes to improve the explanations on how to use drop in files for the systemd unit file.

Removed references to Sys V Init in the README file.

JohanSaaw · 2026-02-24T13:44:41Z

Hi,

I have a further question. The RPM sepc file has a require statement for PERL to be v 5.10 or higher. I have seen the change to remove PERL binaries for versions 5.20 and earlier.

Should I also bump the spec file require statement to require PERL version 5.22 or higher?

Regards, Johan

michaelherger

Thanks for this PR! As you know I'm no expert in this area...

@mavit - would you mind sharing your review thoughts of this suggested change?

michaelherger · 2026-02-24T19:09:51Z

+        # send USR1 to lyriuonmusicserver PID to reset logging
+        /bin/kill -USR1 `pgrep lyrionmusicser 2>&1` >/dev/null 2>&1 || true


typo in comment, change on purpose in the process name?

Hi,

Sorry for the typo. I'll fix that straight away.

The change in the process name is the main error that I fixed in that file. The pgrep command uses the string in the /proc/[pid]/stat file to find the PID. In that file only the first 15 characters of the command is used. If you pass longer strings to pgrep it will not find anything, unless you pass the string with the -f flag (and I have seen that this can lead to other unwanted side effects).

If you look at the logrotate file in the Debian package you will see the same there. They have also shortened squeezeboxserver.

But it is only good if someone else has a look at this too. Also maybe at the question about the required version of PERL in the RPM spec file.

Regards, Johan

Fixed a silly typo in a comment.

mavit · 2026-02-26T13:53:37Z

Should I also bump the spec file require statement to require PERL version 5.22 or higher?

Seems sensible. We should probably also mention the maximum supported version, so:

Requires: (perl >= 5.22 and perl < 5.43)

For maximum accuracy, we could even:

Requires: (perl(:MODULE_COMPAT_5.22.0) or \
           perl(:MODULE_COMPAT_5.24.0) or \
           perl(:MODULE_COMPAT_5.26.0) or \
           perl(:MODULE_COMPAT_5.28.0) or \
           perl(:MODULE_COMPAT_5.30.0) or \
           perl(:MODULE_COMPAT_5.32.0) or \
           perl(:MODULE_COMPAT_5.34.0) or \
           perl(:MODULE_COMPAT_5.36.0) or \
           perl(:MODULE_COMPAT_5.38.0) or \
           perl(:MODULE_COMPAT_5.40.0) or \
           perl(:MODULE_COMPAT_5.42.0))

mavit · 2026-02-26T13:14:46Z

    postrotate
-        /bin/kill -USR1 `pgrep lyrionmusicserver >/dev/null 2>&1` >/dev/null 2>&1 || true
+        # send USR1 to lyrionmusicserver PID to reset logging
+        /bin/kill -USR1 `pgrep lyrionmusicser 2>&1` >/dev/null 2>&1 || true


Now that we know that we have systemd, how about the following, to deliver the signal without guessing the process from its name?

Suggested change

/bin/kill -USR1 `pgrep lyrionmusicser 2>&1` >/dev/null 2>&1 || true

systemctl --kill-whom=main --signal=USR1 kill lyrionmusicserver.service

@mavit ,

Thanks for this suggestion. I was looking at this possibility too, but in the end decided against it, mostly because I did not want to change too much. But as you think this is better, then I'll add this. I would just like to do one small change and that is to use the full path to systemctl:

/usr/bin/systemctl --kill-whom=main --signal=USR1 kill lyrionmusicserver.service

Do you have any objections?

Regards, Johan

Looks good to me.

mavit · 2026-02-26T13:25:41Z


 # FHS compatible directory structure
-mkdir -p $RPM_BUILD_ROOT%{_sysconfdir}/init.d
+mkdir -p $RPM_BUILDROOT%{_unitdir}


We need the following to ensure we have the %{_unitdir} macro:

BuildRequires: systemd-rpm-macros

https://docs.fedoraproject.org/en-US/packaging-guidelines/Systemd/#packaging_filesystem

@mavit,

OK, will do this. I guess I was lucky that it worked on my server without that macro. I will let you all know when I have implemented and tested this.

Regards, Johan

mavit · 2026-02-26T14:03:29Z

+/usr/bin/systemctl enable  %{shortname}.service >/dev/null 2>&1 || :
+/usr/bin/systemctl restart %{shortname}.service >/dev/null 2>&1 || :


The idea of unconditionally enabling the service when the package is upgraded, even if the user has previously disabled it, makes me uneasy. Could we use presets and scriptlets instead?

https://docs.fedoraproject.org/en-US/packaging-guidelines/Scriptlets/#_systemd

@mavit,

Yes I know this is strange, but it has always been like this, even before systemd support was introduced. The RPM scripts enabled and started the service. Please allow me some time to read up on the guide lines, and then I'll update the respective scripts.

Regards, Johan

JohanSaaw · 2026-02-27T15:42:59Z

Should I also bump the spec file require statement to require PERL version 5.22 or higher?

Seems sensible. We should probably also mention the maximum supported version, so:

Requires: (perl >= 5.22 and perl < 5.43)

For maximum accuracy, we could even:

Requires: (perl(:MODULE_COMPAT_5.22.0) or \
           perl(:MODULE_COMPAT_5.24.0) or \
           perl(:MODULE_COMPAT_5.26.0) or \
           perl(:MODULE_COMPAT_5.28.0) or \
           perl(:MODULE_COMPAT_5.30.0) or \
           perl(:MODULE_COMPAT_5.32.0) or \
           perl(:MODULE_COMPAT_5.34.0) or \
           perl(:MODULE_COMPAT_5.36.0) or \
           perl(:MODULE_COMPAT_5.38.0) or \
           perl(:MODULE_COMPAT_5.40.0) or \
           perl(:MODULE_COMPAT_5.42.0))

@mavit,

I had a look at the Require statement and I have done some tests. I ran into problems so I had to read up a bit before I got it working.

According to

https://rpm-software-management.github.io/rpm/manual/dependencies.html

"Requires" lines can't be continued over several lines (the short paragraph just above the "Conflicts" section). If your proposal with the MODULE_COMPAT_X.XX.X statements is rewritten into a single long line, then it works.

As such a long "Requires" line is not really readable, I would prefer to use your other proposal:

Requires: (perl >= 5.22 and perl < 5.43)

This format works on SUSE based distributions but not on Fedora/RedHat based distributions. Instead the format:

Requires: (perl(:VERSION) >= 5.22 and perl(:VERSION) < 5.43)

must be used.

There is, however, one more snag. Boolean conditions in Requires statements are only allowed in RPM 4.13 and above. CentOS 7, RHEL 7, Fedora 26 and older use older versions of RPM. In the SUSE world, openSUSE and SLES before 15.0 used older versions of RPM.

I don't know whether this is only a theoretical issue, i.e. if anyone runs LMS on such old versions of RedHat/SUSE distributions, or not. If it actually is a real issue, then it can be worked around like this in the spec file:

Requires: Perl >=5.22
Conflicts: Perl >=5.43

What do you think?

Regards, Johan

Suggestion by mavit, to use systemctl functionality to signal lyruionmusicserver with USR1 after log rotation.

- Added systemd as pre-requisite with the %systemd_requires macro. - Added BuildRequires systemd-rpm-macros - Added use of systemd_pre, systemd_preun, systemd_post and systemd_postun_with_restart to initialise and handle the unit file and service correctly. - Added a systemd preset file to enable lyrionmusicserver at installation time. - Added logic to start lyrionmusicserver immediately during install if it is a first time installation. Upgrades will follow the packaging rules.

Added a systemd preset file to enable lyrionmusicserver immediately at installation.

Added in wrong location.

Added systemd preset file for RPM. Removed Sys V init file for RPM.

JohanSaaw · 2026-02-28T16:23:54Z

@mavit , @michaelherger ,

I have committed changes to my fork now that addresses the points raised by mavit.

/etc/logrotate.d/lyrionmusicserver.conf
Added the suggestion made by mavit with the small difference to use the full path for the systemctl command.
Added BuildRequires: systemd-rpm-macros
perl version requirements
This was more difficult than I thought it would be. This is mostly due to the fact that Fedora/RedHat and SUSE handles version capabilities of perl differently.

The statement

(perl >= 5.22 and perl < 5.43)

Will only work on SUSE flavours

(perl(:VERSION) >= 5.22 and perl(:VERSION) < 5.43)

Will only work on Fedora/RedHat flavours.

This one
Requires: perl >= 5.22
Conflicts: perl >= 5.43

Does not work on Fedora/RedHat

If we really want to have a perl requirement for both larger or equal to 5.22 and less than 5.43 we need to use the long statement given by mavit here above. But it has to be re-written in a single line as "Requires:" statements can't be written on several lines with line continuation characters. So I ended up with:

Requires: (perl(:MODULE_COMPAT_5.22.0) or perl(:MODULE_COMPAT_5.24.0) or perl(:MODULE_COMPAT_5.26.0) or perl(:MODULE_COMPAT_5.28.0) or perl(:MODULE_COMPAT_5.30.0) or perl(:MODULE_COMPAT_5.32.0) or perl(:MODULE_COMPAT_5.34.0) or perl(:MODULE_COMPAT_5.36.0) or perl(:MODULE_COMPAT_5.38.0) or perl(:MODULE_COMPAT_5.40.0) or perl(:MODULE_COMPAT_5.42.0))

I should mention one more thing, it is only possible to use boolean logic in Requires statements on RPM 4.13 and newer. I think there is an overlap, at least in the RedHat world with version using Perl 5.22 and RPM versions lower than 4.13. I don't know how much of a problem this would be.

Added systemd_*, macros in the respective RPM scriptlets.
Added a systemd preset file to make sure that lyrionmusicserver is enabled at install.
Added logic to start the lyrionmusicserver during install IF IT IS A FIRST TIME INSTALL

During upgrades the service will remain disabled if it was disabled before the upgrade started. Also if the service was stopped before the upgrade, it will remain stopped after the upgrade. And of course if the service was enabled and running before the upgrade it will remain that way after the upgrade.

I have tested this on openSUSE Leap, openSUSE tumbleweed, Rocky 10 and Fedora 43.

Please let me know if you have any questions or remarks.

Regards, Johan

JohanSaaw · 2026-02-28T21:11:04Z

I am really sorry, I have to retract what I said about the "Requires" statement for perl here above.

I did some more testing on older versions of SUSE and the "Requires" statement I chose does not work on openSUSE 15.6.

I am afraid I need to do more testing.

Regards, Johan

Refined the perl Requires statement to work on both SUSE and RedHat based distros. Will work with both rpm and zypper/dnf commands. Now requires minimum v 5.22 and less than v. 5.43. Also changed Recommends: perl(IO::Socket::SSL) to Requires: perl(IO::Socket::SSL) As I noticed that a lot of functionality in LMS will not work without that.

JohanSaaw · 2026-03-02T10:34:46Z

@mavit , @michaelherger

I have done some more testing and I can conclude that some of my testing was made more difficult than necessary because I am old. When I sit with a Linux command line in front of me, I instinctively write "rpm -ivh ..." when I want to install anything, rather than "zypper in ..." or "dnf install ..." respectively.

Another complication is that SUSE distros and RedHat based distros have chosen different methods to

Anyway, I have found that this Requires statement work on opensuse Leap 15.X, opensuse Leap 15, opensuse Tumbleweed, Rocky, v 8, 9, 10 and Fedora 43

Requires: ((perl >= 5.22 or perl(:VERSION) >= 5.22) with (perl < 5.43 or perl(:VERSION) < 5.43))

This works irrespectively of whether rpm or zypper/dnf is used to install the packages.
The disadvantage is that it will only work on OS versions using RPM v 4.14 and higher (the "with" operator was only introduced in RPM v. 4.14). This means that it will no longer be possible to install the package on Rocky, Alma and CentOS 7. Fedora started using RPM 4.14 with v. 27.

It will still work on older SUSE distributions (with earlier RPM versions) , but only when using zypper in that case.

Please also note that the current LMS 9.1 package can only be installed on Rocky 8 with dnf and not with RPM. Installing it with dnf will pull in 113 perl packages that are not really necessary.

I have committed the corresponding changes to my fork.

I am now finally confident that I found a working solution and would appreciate your feedback.

Regards, Johan

Co-authored-by: Peter Oliver <github.com@mavit.org.uk>

JohanSaaw · 2026-03-02T12:44:28Z

@mavit ,

Thanks, accepted that correction.

Regards, Johan

Co-authored-by: Peter Oliver <github.com@mavit.org.uk>

@mavit

Removed and updated Require statements as advised by @mavit.

JohanSaaw · 2026-05-28T14:18:39Z

Also, while doing the tests I also revisited my thoughts around the Require statements. I think I would now favour the following:

Only check the minimum PERL version.
This will ensure that the behaviour at installation time is not changed, i.e. users will get the known message that they run an unsupported version of PERL. I think it is unnecessary to add a hurdle (a small hurdle) for those who don't mind compiling the PERL modules themselves.

I think the hurdle is beneficial. It signals to the user as soon as possible that some form of manual intervention will be required. For example, a user running, e.g., the lyrionmusicserver-9.1.0-1 RPM, who attempts to upgrade their system to Fedora 45 (containing Perl 4.44) will have the upgrade fail before it starts. They can then decide whether to delay the upgrade or go hunting for a newer LMS RPM. I think this is preferable to letting them go ahead with the upgrade, only to discover afterwards that LMS is broken.

Not add Requires for the PERL modules that will be pulled in with the PERL core
Again, in my opinion it is better not change the behaviour known by the users of the RPM package.

I think my suggestion in #106 (comment) is best, since it makes no practical change for most users, but allows those who what to save disk space to do that.

OK, I don't mind very much how we do it. I only normally tend to change as little as possible in the behaviour of scripts/programs I edit. I'll update the spec file in my branch and then we will have to wait and see what Michael writes.

Regards, Johan

michaelherger · 2026-05-28T14:36:27Z

I've been lurking, happily, because I'm glad there are people out there who know these things. I wouldn't. I really don't have much to add to the discussion...

Followed advice from Mavit about Requires: statments

mavit

Added a few minor nit-picks.

Co-authored-by: Peter Oliver <github.com@mavit.org.uk>

Improving comments. Co-authored-by: Peter Oliver <github.com@mavit.org.uk>

Improve comments. Co-authored-by: Peter Oliver <github.com@mavit.org.uk>

Improve comments Co-authored-by: Peter Oliver <github.com@mavit.org.uk>

Because the systemd-* RPM macros differs between Red Hat and SUSE distributions. Special handling of the macro systemd_pre is necessary. Is now scripted to be evaluated during installation rather than at build time.

mavit

Looks good to me. Thanks for persisting with it.

JohanSaaw · 2026-06-05T09:26:52Z

Hi,

Thanks for checking it all.

Regards, Johan

michaelherger · 2026-06-05T09:53:15Z

Thanks guys! Are we good to merge?

And what should be the changelog one-liner?

JohanSaaw · 2026-06-05T11:11:36Z

Hi,

Yes I think we we are good to merge.

What about this for the One-liner

"Removal of SYSV Init support and better systemd support."

Regards, Johan

JohanSaaw · 2026-06-05T11:27:29Z

maybe add that this is for the RPM package only so,

"Removal of SYSV Init support and better systemd support in the RPM package for Red Hat/SUSE."

michaelherger · 2026-06-05T15:32:58Z

Thanks a lot!

JohanSaaw · 2026-06-07T08:43:52Z

@michaelherger ,

I don't see a new build of the RPM package after your merge. Is it because of the complaints I see here above that I haven't signed off my commits?

Regards, Johan

michaelherger · 2026-06-07T10:29:57Z

Build failed with:

INFO: Moving /home/runner/work/slimserver/slimserver/work/lyrionmusicserver.tgz to /home/runner/work/slimserver/slimserver/work/rpm/SOURCES...
  warning: line 143: It's not recommended to have unversioned Obsoletes: Obsoletes:	logitechmediaserver
  warning: line 144: It's not recommended to have unversioned Obsoletes: Obsoletes:	SliMP3
  warning: line 145: It's not recommended to have unversioned Obsoletes: Obsoletes:	slimserver
  warning: line 146: It's not recommended to have unversioned Obsoletes: Obsoletes:	squeezeboxserver
  warning: line 147: It's not recommended to have unversioned Obsoletes: Obsoletes:	squeezecenter
  warning: line 143: It's not recommended to have unversioned Obsoletes: Obsoletes:	logitechmediaserver
  warning: line 144: It's not recommended to have unversioned Obsoletes: Obsoletes:	SliMP3
  warning: line 145: It's not recommended to have unversioned Obsoletes: Obsoletes:	slimserver
  warning: line 146: It's not recommended to have unversioned Obsoletes: Obsoletes:	squeezeboxserver
  warning: line 147: It's not recommended to have unversioned Obsoletes: Obsoletes:	squeezecenter
  warning: bogus date in %changelog: Wed Jun 02 2026 Johan Saaw
  error: Failed build dependencies:
  	systemd-rpm-macros is needed by lyrionmusicserver-9.2.0-0.1.1780673646.noarch

Is this a dependency I'd have to load on the build host? The runner (on Github) is an Ubuntu 22.04 (see https://github.com/actions/runner-images/blob/ubuntu22/20260525.156/images/ubuntu/Ubuntu2204-Readme.md). They don't have Fedora or the like runners... Would you have a great idea how to fix this?

JohanSaaw · 2026-06-07T13:21:41Z

Hi,

Yes the package systemd-rpm-macros is a build requirement. It contains a single file /usr/lib/rpm/macros.d/macros.systemd.

Unfortunately I have no experience with Ubuntu and even less experience with building RPM packages on Ubuntu. I did some searching for Ubuntu and of course the corresponding macros/scriptlets have completely different names.

A really horrible solution would be to remove the "BuildRequires: rpm_systemd-macros" in the spec file and drop the file "/usr/lib/rpm/macros.d/macros.systemd" on the build host, and hope for the best.

An equally horrible solution would be that I replaced thos macros with shell script code.

Maybe @mavit, knows how to solve this elegantly.

Regards, Johan

michaelherger · 2026-06-07T20:48:39Z

I'm currently trying to make it build in a Fedora container instead. Can you access https://github.com/michaelherger/slimserver/actions/runs/27104259169/job/79990444015?

It's failing with:

*** ERROR: ./usr/share/lyrionmusicserver/CPAN/DBI/Shell/SQLMinus.pm has shebang which doesn't start with '/' (perl -w)

Is this something you've seen before?

michaelherger · 2026-06-08T03:54:52Z

Ok, could get past that by removing the executable bit from all the *.pm files.

michaelherger · 2026-06-08T03:59:20Z

But now that new file is about 25% smaller than before... is it using a different compression? Could you please sanity check this copy? https://downloads.nixda.ch/lyrionmusicserver-9.2.0-0.1.UNKNOWN.noarch.rpm

Scratch that - I didn't push this PR to my repo clone on which I'm testing this out.

~~I'll also have to figure out why the timestamp is UNKNOWN...~~

New build to test: https://downloads.nixda.ch/lyrionmusicserver-9.2.0-0.1.1780895307.noarch.rpm

michaelherger · 2026-06-08T05:57:16Z

https://lyrion.org/downloads/#v920-development-build is now up to date. Thanks again!

JohanSaaw · 2026-06-08T07:19:50Z

Good morning,

Thanks for your efforts!

I have tested the build now. It works without any issues. I have tested on different versions of SUSE and on different flavours of Red Hat based distributions. I tested clean installs and upgrades. I assume that this will complicate your build procedure in the future. Is that a problem?

May I ask what was the reason for the "UNKNOWN" string in the resulting RPM file? I have the same when I build on my own server here at home. I would like to understand the reason.

Regards, Johan

michaelherger · 2026-06-08T08:04:01Z

UNKNOWN: in our case it was lack of git in the Fedora container the build step is using now. Github would automatically (and rather silently: you have to read the output carefully to understand it...) fall back to using their own APIs in an action/checkout step if git tools were not available on the host. But I'd later use git to read the checkout's revision and latest timestamp to create the revision. This then failed and fell back to UNKNOWN. Once I added installation of git to the build steps the issue was resolved.

I don't know how you're testing. Are you using the buildme.pl script, too?

JohanSaaw · 2026-06-08T10:36:26Z

OK, I don't have git installed on my Linux server either, so probably that is the reason then.

Yes I use the buildme.pl script. I download the repositories, unpack them and then I run the buildme.pl script. I think it is time for me to start looking at installing git and maybe also learn a bit more about it.

michaelherger · 2026-06-08T10:57:10Z

Git is worth the learning curve! I often use it even only locally, without pushing code anywhere, just to have a history of changes etc. And I'm not a power user at all. Just the basics like having different versions, change history, branches etc.

JohanSaaw added 10 commits February 24, 2026 12:19

Delete the Sys V init file for RHEL and SUSE based distibutions.

fe506cb

As all the RPM based distributions use systemd now, and have done it for an extended period of time, it is no longer necessary for the Lyrion RPM package to support Sys V Init.

Updated infrmation on how to use unit drop in files for Lyrion

a6d5bfb

Updated and improved information on how to use systemd drop in files to amend/change the start-up parameters of Lyrion Music Server

Fix an error in the logrotate config.

541cafb

The use of pgrep in the postrotate section was wrong

Removal of Sys V Init support

8e4d931

The Sys V Init is outdated. Removed the parallel support of Sys V init. Now only supporting systemd.

Fix small error in logrtate config

026208e

Remove Sys V Init support

13d7116

Some further small teaks to the explanations to make it more readable.

Remove Sys V Init support

56d277e

Made some changes to improve the explanations on how to use drop in files for the systemd unit file.

Remove Sys V Init support

a320f9e

Removed references to Sys V Init in the README file.

michaelherger reviewed Feb 24, 2026

View reviewed changes

Fix error in logrotate.conf

1dadef3

Fixed a silly typo in a comment.

mavit suggested changes Feb 26, 2026

View reviewed changes

JohanSaaw added 5 commits February 27, 2026 20:13

Use systemctl to signal LMS after log rotation.

7f71b68

Suggestion by mavit, to use systemctl functionality to signal lyruionmusicserver with USR1 after log rotation.

Add systemd preset file for Lyrion

5de74b9

Added a systemd preset file to enable lyrionmusicserver immediately at installation.

Delete README.systemd

c328263

Added in wrong location.

Added systemd preset file for RPM

b69756d

Added systemd preset file for RPM. Removed Sys V init file for RPM.

JohanSaaw requested review from mavit and michaelherger March 2, 2026 10:34

mavit reviewed Mar 2, 2026

View reviewed changes

Comment thread redhat/lyrionmusicserver.spec

Update redhat/lyrionmusicserver.spec

158ea76

Co-authored-by: Peter Oliver <github.com@mavit.org.uk>

JohanSaaw and others added 2 commits May 28, 2026 16:04

Update redhat/lyrionmusicserver.spec

faf2900

Co-authored-by: Peter Oliver <github.com@mavit.org.uk>

Removed and updated Requires

6d2a3d7

Removed and updated Require statements as advised by @mavit.

JohanSaaw requested a review from mavit May 30, 2026 09:15

Further amendments to Requires: statements

d7458d2

Followed advice from Mavit about Requires: statments

mavit reviewed Jun 1, 2026

View reviewed changes

Comment thread redhat/lyrionmusicserver.spec Outdated

Comment thread redhat/lyrionmusicserver.spec Outdated

Comment thread redhat/lyrionmusicserver.spec Outdated

Comment thread redhat/lyrionmusicserver.spec Outdated

JohanSaaw and others added 5 commits June 2, 2026 07:55

Update redhat/lyrionmusicserver.spec

753b27c

Co-authored-by: Peter Oliver <github.com@mavit.org.uk>

Update redhat/lyrionmusicserver.spec

49d3a0b

Improving comments. Co-authored-by: Peter Oliver <github.com@mavit.org.uk>

Update redhat/lyrionmusicserver.spec

f34106e

Improve comments. Co-authored-by: Peter Oliver <github.com@mavit.org.uk>

Update redhat/lyrionmusicserver.spec

62def39

Improve comments Co-authored-by: Peter Oliver <github.com@mavit.org.uk>

Solved issue with RPM macro systemd-pre

aac4fb8

Because the systemd-* RPM macros differs between Red Hat and SUSE distributions. Special handling of the macro systemd_pre is necessary. Is now scripted to be evaluated during installation rather than at build time.

mavit approved these changes Jun 3, 2026

View reviewed changes

michaelherger merged commit c3c7215 into LMS-Community:public/9.2 Jun 5, 2026
1 check failed

		# send USR1 to lyriuonmusicserver PID to reset logging
		/bin/kill -USR1 `pgrep lyrionmusicser 2>&1` >/dev/null 2>&1 \|\| true

	/bin/kill -USR1 `pgrep lyrionmusicser 2>&1` >/dev/null 2>&1 \|\| true
	systemctl --kill-whom=main --signal=USR1 kill lyrionmusicserver.service

		/usr/bin/systemctl enable %{shortname}.service >/dev/null 2>&1 \|\| :
		/usr/bin/systemctl restart %{shortname}.service >/dev/null 2>&1 \|\| :

Conversation

JohanSaaw commented Feb 24, 2026

Uh oh!

JohanSaaw commented Feb 24, 2026

Uh oh!

michaelherger left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mavit commented Feb 26, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

JohanSaaw commented Feb 27, 2026

Uh oh!

JohanSaaw commented Feb 28, 2026

Uh oh!

JohanSaaw commented Feb 28, 2026

Uh oh!

JohanSaaw commented Mar 2, 2026

Uh oh!

Uh oh!

JohanSaaw commented Mar 2, 2026

Uh oh!

JohanSaaw commented May 28, 2026

Uh oh!

michaelherger commented May 28, 2026

Uh oh!

mavit left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

mavit left a comment

Choose a reason for hiding this comment

Uh oh!

JohanSaaw commented Jun 5, 2026

Uh oh!

michaelherger commented Jun 5, 2026

Uh oh!

JohanSaaw commented Jun 5, 2026

Uh oh!

JohanSaaw commented Jun 5, 2026

Uh oh!

michaelherger commented Jun 5, 2026

Uh oh!

Uh oh!

JohanSaaw commented Jun 7, 2026

Uh oh!

michaelherger commented Jun 7, 2026

Uh oh!

JohanSaaw commented Jun 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

michaelherger commented Jun 7, 2026

Uh oh!

michaelherger commented Jun 8, 2026

Uh oh!

michaelherger commented Jun 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

JohanSaaw commented Jun 7, 2026 •

edited

Loading

michaelherger commented Jun 8, 2026 •

edited

Loading

michaelherger commented Jun 8, 2026 •

edited

Loading