Description of problem: Looks like sssd.service.in wasn't properly expanded during build and the default path with libexec got into RPMs.
I pushed a workaround to Rawhide to unbreak people who are running that OS. The core of the problem is that the patch that changed unit-file generation results in the service file being generated and statically included in the tarball. As a result, when building the tarball into an RPM, the paths are not recreated.
Upstream ticket: https://fedorahosted.org/sssd/ticket/2314
(In reply to Stephen Gallagher from comment #1) > I pushed a workaround to Rawhide to unbreak people who are running that OS. > > The core of the problem is that the patch that changed unit-file generation > results in the service file being generated and statically included in the > tarball. As a result, when building the tarball into an RPM, the paths are > not recreated. sssd.service was not regenerated, because init system was not systemd (default is sysv) Please revert your workaround and enable systemd -make %{?_smp_mflags} all docs +rm -f src/sysv/systemd/sssd.service + +make %{?_smp_mflags} all docs src/sysv/systemd/sssd.service Problem is not with upstrem srpm because: %if (0%{?use_systemd} == 1) %global with_initscript --with-initscript=systemd --with-systemdunitdir=%{_unitdir} %else %global with_initscript --with-initscript=sysv %endif In older version, it worked only by chance in fedora. sssd.service was regenerated every time (configure must be executed), but wrong file was generated with non-standard prefix #2293 I agree that generated files should not be included in tarball #22314 because we would have noticed missing sssd.service in koji buld if generated files hadn't been included in tarball.
(In reply to Lukas Slebodnik from comment #3) > (In reply to Stephen Gallagher from comment #1) > > I pushed a workaround to Rawhide to unbreak people who are running that OS. > > > > The core of the problem is that the patch that changed unit-file generation > > results in the service file being generated and statically included in the > > tarball. As a result, when building the tarball into an RPM, the paths are > > not recreated. > sssd.service was not regenerated, because init system was not systemd > (default is sysv) > > Please revert your workaround and enable systemd > No, let's release 1.11.5.1 instead today and put that into rawhide. A minor version must be compilable and usable with the same flags as the previous one, we can't break existing packages without a warning in release notes like this.
(In reply to Jakub Hrozek from comment #4) > No, let's release 1.11.5.1 instead today and put that into rawhide. A minor > version must be compilable 1.11.5 was compilable 1.11.5.1 will be compilable no change > and usable with the same flags as the previous 1.11.5 wasn't usable 1.11.5.1 will not be usable *WITH THE SAME FLAGS* no change > one, we can't break existing packages without a warning in release notes > like this. It worked only by chance.
I've saved changes very fast. The bug is also in fedora 19 and fedora 20, but rawhide has enabled updates-testing by default.
Could we make Makefile.am regenerate the file when running 'make all' ? It's just a text file after all, it doesn't have to be conditionalizes, does it?
Makefile will generate sssd.service when running 'make all' if initscript is systemd sh-4.2$ grep HAVE_SYSTEMD_UNIT_TRUE Makefile.in sh-4.2$ grep -n HAVE_SYSTEMD_UNIT_TRUE Makefile.in 169:@HAVE_SYSTEMD_UNIT_TRUE@am__append_36 = \ 170:@HAVE_SYSTEMD_UNIT_TRUE@ src/sysv/systemd/sssd.service 13729:@HAVE_SYSTEMD_UNIT_TRUE@ mkdir -p $(DESTDIR)$(systemdunitdir) If package was configured without systemd previous lines will be commented out. #am__append_36 = \ # src/sysv/systemd/sssd.service and makefile will not generate sssd.service by default. "make src/sysv/systemd/sssd.service" will generate this file(Stephen's workaround), because there is not ifdef around target src/sysv/systemd/sssd.service. src/sysv/systemd/sssd.service: src/sysv/systemd/sssd.service.in Makefile @$(MKDIR_P) src/sysv/systemd/ $(replace_script)
I compared three spec files: from fedora, from opensuse and from upstream. The configure script was called with argument "--with-initscript=systemd" only in the upstream spec file. The patch from mail https://lists.fedorahosted.org/pipermail/sssd-devel/2014-April/019090.html will solve problem in incompatible way. sssd.service will not be generated. It is better than shipping wrong service file (1.11.5) I am fine with minor release 1.11.5.1
Fixed upstream: baf3646f5ac2c76d6c2ca59c465d2e2431664274
sssd-1.11.5.1-1.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/sssd-1.11.5.1-1.fc20
sssd-1.11.5.1-1.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/sssd-1.11.5.1-1.fc19
Package sssd-1.11.5.1-1.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing sssd-1.11.5.1-1.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-5106/sssd-1.11.5.1-1.fc20 then log in and leave karma (feedback).
sssd-1.11.5.1-1.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.
sssd-1.11.5.1-1.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.