Bug 983760 - nscd packaging is broken
nscd packaging is broken
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: glibc (Show other bugs)
rawhide
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Siddhesh Poyarekar
Fedora Extras Quality Assurance
:
: 995632 1003194 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-07-11 18:18 EDT by Michal Jaegermann
Modified: 2016-11-24 07:13 EST (History)
14 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-08-19 07:47:24 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Michal Jaegermann 2013-07-11 18:18:15 EDT
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?

Version-Release number of selected component (if applicable):
glibc-2.17.90-4.fc20
Comment 1 Carlos O'Donell 2013-07-11 21:09:56 EDT
(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.
Comment 2 Michal Jaegermann 2013-07-11 23:14:04 EDT
(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.
Comment 3 Carlos O'Donell 2013-07-12 16:46:09 EDT
(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.
Comment 4 Michal Jaegermann 2013-07-12 18:04:09 EDT
(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).
Comment 5 Siddhesh Poyarekar 2013-07-12 20:49:00 EDT
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.
Comment 6 Marcela Mašláňová 2013-07-22 04:03:22 EDT
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.
Comment 7 Tomas Mraz 2013-07-22 05:35:15 EDT
Buildrequires: systemd fixes the problem.
Comment 8 Siddhesh Poyarekar 2013-07-22 05:38:51 EDT
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.
Comment 9 Siddhesh Poyarekar 2013-07-22 08:46:09 EDT
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.
Comment 10 Carlos O'Donell 2013-08-13 15:48:26 EDT
*** Bug 995632 has been marked as a duplicate of this bug. ***
Comment 11 Carlos O'Donell 2013-08-13 15:50:26 EDT
(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.
Comment 12 Siddhesh Poyarekar 2013-09-01 23:12:00 EDT
*** Bug 1003194 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.