Bug 983760

(In reply to Michal Jaegermann from comment #0)
> Description of problem:
> 
> Updating nscd results in the following:
> 
>   Updating   : nscd-2.17.90-4.fc20.x86_64                              
> 133/282 
> /var/tmp/rpm-tmp.WzzUcd: line 1: fg: no job control
> warning: %post(nscd-2.17.90-4.fc20.x86_64) scriptlet failed, exit status 1
> 
> Not that surprising after a peek at an output from 'rpm -q --scripts nscd'
> part of which comes as:
> .......
> postinstall scriptlet (using /bin/sh):
> %systemd_post nscd.service
> preuninstall scriptlet (using /bin/sh):
> %systemd_preun nscd.service
> postuninstall scriptlet (using /bin/sh):
> if test $1 = 0; then
>   /usr/sbin/userdel nscd > /dev/null 2>&1 || :
> fi
> %systemd_postun_with_restart nscd.service
> 
> and that means the same trouble in three scriptlets.  How these
> '%systemd_...' were supposed to be expanded?

The %systemd_* are special scriptlets guaranteed to be there by the Requires on systemd.

They are documented here:
http://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Macroized_scriptlets_.28Fedora_18.2B.29

Are you certain this is the problem?

The output `fg: no job control` is more worrying to me. Have you somehow hacked your system shell to use a shell that has no job control?

Cheers,
Carlost.

(In reply to Carlos O'Donell from comment #1)

> 
> The %systemd_* are special scriptlets guaranteed to be there by the Requires
> on systemd.

That is right; but scriplets are executed by /bin/sh.  How do you think a shell is supposed to deal with %systemd_post if it was not expanded first by a packaging process?  Ah, right, "fg: no job control" is a fully expected response.

> Are you certain this is the problem?

I have seen variation of really the same issue many times already.  It seems that some rpm macros were not properly included.

(In reply to Michal Jaegermann from comment #2)
> (In reply to Carlos O'Donell from comment #1)
> 
> > 
> > The %systemd_* are special scriptlets guaranteed to be there by the Requires
> > on systemd.
> 
> That is right; but scriplets are executed by /bin/sh.  How do you think a
> shell is supposed to deal with %systemd_post if it was not expanded first by
> a packaging process?  Ah, right, "fg: no job control" is a fully expected
> response.

I agree that I do not expect the shell to be able to execute `%systemd_post'.

I agree that `bash -c <command>` would fail with `bash: line X: fg: no job control', so it does indeed seem like an unprocessed variable makes it to the shell.

> > Are you certain this is the problem?
> 
> I have seen variation of really the same issue many times already.  It seems
> that some rpm macros were not properly included.

The Fedora packaging recommendations simply say that a package needs a Requires on systemd and that should be enough for the use of these scriptlets.

Given your familiarity with the problem, do you know what else needs to be done?

Cheers,
Carlos.

(In reply to Carlos O'Donell from comment #3)

> 
> Given your familiarity with the problem, do you know what else needs to be
> done?

I am "familiar" in that sense that I have seen instances on various occasions.  I do not know details of this particular one. In general you have to ensure that definitions of rpm macros you are using are present and that they are expanded when you are building your packages.

As the first cut I would check what happens if you are trying 'rpm --eval "%systemd_post argument"' in your build environment.  On a Fedora 18 installation this prints:

if [ $1 -eq 1 ] ; then 
        # Initial installation 
        /usr/bin/systemctl preset argument >/dev/null 2>&1 || : 
fi 

and that is a kind of a code I would expect in a final package.  OTOH 'rpm --eval "%systemd_postx argument"' will show

%systemd_postx argument

because that macro is not defined so it will get passed as a literal (and you will see 'fg: no job control' if it will make into an rpm package scriplets).

It's an untested guess but maybe this is because we depend on systemd-units and not systemd.  I'll test it later and if that's the case, I'll make the change.

I guess systemd-units shouldn't be needed anymore according to guidelines. I've opened a ticket for fpc:
https://fedorahosted.org/fpc/ticket/318
There is a bug in guidelines or in dependencies.

Buildrequires: systemd fixes the problem.

Thanks for the confirmation.  I've got a scratch build in progress to test this and another change.  I'll push a real build once I've verified both.

Tomas, I misread your comment - I had changed systemd-units to systemd to match the packaging guidelines and that (obviously it seems) failed to work.  I'll hold out on resolving this till the ticket for fpc is resolved.

*** Bug 995632 has been marked as a duplicate of this bug. ***

(In reply to Siddhesh Poyarekar from comment #9)
> Tomas, I misread your comment - I had changed systemd-units to systemd to
> match the packaging guidelines and that (obviously it seems) failed to work.
> I'll hold out on resolving this till the ticket for fpc is resolved.

Note:

Changed 11 hours ago by mmaslano 

    Status changed from new to closed
    Resolution set to fixed

Solution is to add BR: systemd in all packages using macro.

*** Bug 1003194 has been marked as a duplicate of this bug. ***