Bug 1086225

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.