Bug 191223

Comment 1 John Marino 2014-06-20 20:06:08 UTC

Assign to maintainer and CC kwm whom I believe did the actual staging.

Found on poudriere bulk -t (FreeBSD 10/amd64)

Comment 2 John Marino 2014-07-27 19:56:24 UTC

Here is the latest result (FreeBSD 10/AMD64/Poudriere 3.0.16)

===========================================================================
====> Running Q/A tests (stage-qa)
====> Checking for pkg-plist issues (check-plist)
===> Parsing plist
===> Checking for items in STAGEDIR missing from pkg-plist
Error: Orphaned: @unexec rmdir "/var/run/hald/hald-local" >/dev/null 2>&1 || :
Error: Orphaned: @unexec rmdir "/var/run/hald/hald-runner" >/dev/null 2>&1 || :
===> Checking for directories owned by MTREEs
===> Checking for directories handled by dependencies
Warning: Possibly owned by dependency: @dirrmtry share/PolicyKit/policy
Warning: Possibly owned by dependency: @dirrmtry share/PolicyKit
Warning: Possibly owned by dependency: @unexec rmdir "/var/lib" >/dev/null 2>&1 || :
===> Checking for items in pkg-plist which are not in STAGEDIR
===> Error: Plist issues found.
*** Error code 1


I think the hald-local, hald-runner errors are false.  This is from the pkg-plist:

@unexec rm -f /var/run/hald/hald.pid 2>/dev/null || true
@unexec rm -rf /var/run/hald/hald-local 2>/dev/null || true
@unexec rm -rf /var/run/hald/hald-runner 2>/dev/null || true
@unexec rmdir /var/run/hald 2>/dev/null || true
@unexec rmdir /var/cache/hald 2>/dev/null || true
@unexec rmdir /var/lib/hal 2>/dev/null || true
@unexec rmdir /var/lib 2>/dev/null || true


when I run "make makeplist", I get something like: 

@unexec rmdir /var/run/hald/hald-local 2>/dev/null || true
@unexec rmdir /var/run/hald/hald-runner 2>/dev/null || true
@unexec rmdir /var/run/hald 2>/dev/null || true
@unexec rmdir /var/cache/hald 2>/dev/null || true
@unexec rmdir /var/lib/hal 2>/dev/null || true
@unexec rmdir /var/lib 2>/dev/null || true

I think hal pkg-plist is technically correct, but the plist check is bad.  I can think of some hacks to fool the check, but I am philosophically against that.

What's the best way to address this?  And what about the "possibly owned" errors?

Comment 3 John Marino 2014-08-10 12:23:36 UTC

Hal is used in a lot of ports, and this keeps breaking my "poudriere bulk -t" runs, so I'm going to change "unexec rm -rf" to "unexec rmdir" to workaround check-plist inadequacies.

Unless somebody says something very soon.  This PR timed out LONG ago.

Comment 4 commit-hook 2014-08-13 19:11:02 UTC

A commit references this bug:

Author: marino
Date: Wed Aug 13 19:10:46 UTC 2014
New revision: 364801
URL: http://svnweb.freebsd.org/changeset/ports/364801

Log:
  sysutils/hal: Adjust pkg-plist so it passes stage-qa and leftover checks

  Hal was not passing poudriere testport or poudriere bulk -t runs due
  to failing the stage-qa tests and later a leftover check with
  /var/lib/PolicyKit/user-haldaemon.auths.  The reported error is actually
  not wrong, but rather an inadequacy in the check-plist logic.  However,
  hald is a dependency for a lot of ports and it keeps breaking bulk -t
  runs, so I switched "@unexec rm -rf" to "@unexec rmdir" to that it would
  build cleanly in poudriere (gnome@ had fair warning!).  If the check-plist
  logic is improved in the future, this can be changed back to the better
  "rm -rf" command then.

  While here, stop trying to remove directories that PolicyKit installed
  because this will always fail.  This clears up stage-qa warnings.

  PR:		191223
  Submitted by:	marino
  Approved by:	maintainer timeout (2 months, 2 pings)

Changes:
  head/sysutils/hal/Makefile
  head/sysutils/hal/pkg-plist

Comment 5 John Marino 2014-08-13 19:13:55 UTC

I hope this fix is satisfactory to all.