Using poudriere to build of sendmail fails during staging when building on any of my jails using: 11.0-BETA1 r302967 amd64 12.0-CURRENT r302975 amd64 This happens two recently updated ports trees I have in use: head svn 2016-07-18 11:19:38 next portsnap 2016-07-18 11:19:19 I have the following set in the make.conf used during the build: OPTIONS_DEFAULT?= SHMEM SEM LA NIS IPV6 TLS SASL SASLAUTHD LDAP PICKY_HELO_CHECK MILTER MILTER_SHARED MILTER_POOL The problem occurs during staging and appears to be that on O/S > 11 /usr/bin/strip gets upset while doing /usr/bin/strip /wrkdirs/usr/ports/mail/sendmail/work/stage/usr/local/sbin/* The following is seen in the logging: strip: fchmod /wrkdirs/usr/ports/mail/sendmail/work/stage/usr/local/sbin/sendmail failed: Operation not permitted I hacked around with the Makefile to get more info to be logged during the build... id uid=65534(nobody) gid=65534(nobody) groups=65534(nobody) env MAKEFLAGS= .MAKE.LEVEL.ENV=MAKELEVEL ARCH=amd64 HAVE_COMPAT_IA32_KERN=YES\ LINUX_OSRELEASE=2.6.32 OPSYS=FreeBSD OSREL=11.0 OSVERSION=1100120 _OSRELEASE=11.0-BETA1 MAKELEVEL=1 META_MODE=normal .MAKE.LEVEL.ENV=MAKELEVEL NO_DEPENDS=yes SHELL=/usr/sbin/nologin HOME=/nonexistent USER=nobody UNAME_v=FreeBSD 11.0-BETA1 r302967 UNAME_r=11.0-BETA1 BLOCKSIZE=K MAIL=/var/mail/nobody STATUS=1 OPSYS=FreeBSD ARCH=amd64 SAVED_TERM=xterm MASTERMNT=/u1/jails/poudriere/data/.m/fm64v11-next-default/ref HTTP_PROXY=http://proxy.ci.com.au:3128 FORCE_PACKAGE=yes PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/nonexistent/bin _JAVA_VERSION_LIST_REGEXP=1.6\|1.7\|1.8\|1.6+\|1.7+\|1.8+ POUDRIERE_BUILD_TYPE=bulk PKGNAME=sendmail+tls+sasl2+ldap-8.15.2_1 OSREL=11.0 _OSRELEASE=11.0-BETA1 PYTHONBASE=/usr/local OLDPWD=/ _SMP_CPUS=8 PWD=/usr/ports/mail/sendmail HAVE_COMPAT_IA32_KERN=YES LINUX_OSRELEASE=2.6.32 MASTERNAME=fm64v11-next-default SCRIPTPREFIX=/usr/local/share/poudriere _JAVA_VENDOR_LIST_REGEXP=openjdk\|oracle\|sun POUDRIERE_VERSION=3.2-pre SCRIPTPATH=/usr/local/share/poudriere/bulk.sh CONFIGURE_MAX_CMD_LEN=262144 LIBEXECPREFIX=/usr/local/libexec/poudriere LOCALBASE=/usr/local PACKAGE_BUILDING=yes _JAVA_OS_LIST_REGEXP=native\|linux OSVERSION=1100120 FTP_PROXY=http://proxy.xxxxx:3128 ls -lo /wrkdirs/usr/ports/mail/sendmail/work/stage/usr/local/sbin/* -rwxr-xr-x 1 nobody nobody - 95481 Jul 22 07:07 /wrkdirs/usr/ports/mail/sendmail/work/stage/usr/local/sbin/editmap -rwxr-xr-x 1 nobody nobody - 84390 Jul 22 07:07 /wrkdirs/usr/ports/mail/sendmail/work/stage/usr/local/sbin/mailstats -rwxr-xr-x 1 nobody nobody - 99334 Jul 22 07:07 /wrkdirs/usr/ports/mail/sendmail/work/stage/usr/local/sbin/makemap -rwxr-xr-x 1 nobody nobody - 99329 Jul 22 07:07 /wrkdirs/usr/ports/mail/sendmail/work/stage/usr/local/sbin/praliases -rwxr-sr-x 1 nobody nobody - 819168 Jul 22 07:07 /wrkdirs/usr/ports/mail/sendmail/work/stage/usr/local/sbin/sendmail /usr/bin/strip /wrkdirs/usr/ports/mail/sendmail/work/stage/usr/local/sbin/* strip: fchmod /wrkdirs/usr/ports/mail/sendmail/work/stage/usr/local/sbin/sendmail failed: Operation not permitted *** Error code 1 I have temporarily worked around the problem by applying the following patch the the Makefile --- Makefile.orig 2016-06-27 10:20:29.152427000 +1000 +++ Makefile 2016-07-22 11:49:40.672278000 +1000 @@ -220,7 +220,12 @@ ${RM} ${STAGEDIR}${PREFIX}/man/cat*/* ${STRIP_CMD} ${STAGEDIR}${PREFIX}/bin/vacation ${STRIP_CMD} ${STAGEDIR}${PREFIX}/bin/rmail - ${STRIP_CMD} ${STAGEDIR}${PREFIX}/sbin/* + # strip fails on ${STAGEDIR}${PREFIX}/sbin/sendmail + #${STRIP_CMD} ${STAGEDIR}${PREFIX}/sbin/* + ${STRIP_CMD} ${STAGEDIR}${PREFIX}/sbin/editmap + ${STRIP_CMD} ${STAGEDIR}${PREFIX}/sbin/mailstats + ${STRIP_CMD} ${STAGEDIR}${PREFIX}/sbin/makemap + ${STRIP_CMD} ${STAGEDIR}${PREFIX}/sbin/praliases ${STRIP_CMD} ${STAGEDIR}${PREFIX}/libexec/* post-install-DOCS-on: I temporarily added the same debugging to a build using a FreeBSD 10 jail running 10.3-RELEASE-p5 amd64 updated via ftp on 2016-07-02 10:10:43 And it appears to do exactly the same thing but it works. The only obvious difference is that the FreeBSD 10 jail is using the gnu binutils strip command.
A commit references this bug: Author: marino Date: Fri Aug 19 22:19:11 UTC 2016 New revision: 420495 URL: https://svnweb.freebsd.org/changeset/ports/420495 Log: mail/sendmail: fix stage-qa error The strip command for sbin/sendmail fails due to the permissions of the program installed in the stage directory. Change the staged sendmail mode to 755 so that the strip command succeeds. The pkg-list specifies the final mode to be 2555. PR: 211353 Reported by: dave (ci.com.au) Final fix: marino@ Appproved by: maintainer timeout Changes: head/mail/sendmail/Makefile
Can I request not to be assigned PRs after they are closed? This practice is completely unnecessary. I'm already on the CC so if anyone responds, I would see it. I don't want to be assigned PRs after I close them with no action (for whatever reason) or if I fix them. Implicitly I'll take responsibility for any commit I make, but that doesn't extend to taking additional responsibility for the port or the PR. Continuing this practice will result in me doing nothing in the future. I don't know when this practice started, or where it was discussed, but I don't like it.
(In reply to John Marino from comment #2) Closing an issue is implicitly taking responsibility for it in the same way a commit in the tree is, as a decision is being made by the closer, whether with a change (commit) or not (rejected, feedback timeout). The scope is (can) not limited to the commit as any followup as a result of that commit is also implicitly related to the issue. The other reason for assignment is for accurate statistics and reporting (who did what when), and the fact that the default assignee of all ports issues being freebsd-ports-bugs (empty or unassigned), so that notifications go somewhere lest they never get actioned(read: assigned then resolved). If everyone used the issue tracker and not mailing lists, then issues would go from unassigned to assigned in that case. Having real assignees set as early as possible reduces the noise:signal ratio for every one else at all points during an issues lifetime, which still remains high. Issues being inaccurately or incompletely classified in the past, assignee or any field, is only evidence of inconsistent/adhoc issue tracking practices, not of a defacto standard. If this constitutes a genuine impact or burden on you, please email bugmeister@ where we can aim to understand the issue in more detail and discuss it in a more amenable manner and place.
Why should I have to continue to expend energy on what appears to be a unilateral action? Why is not my explicit request enough to put this to bed? I fundamentally disagree with most of what you said. You can't, on one hand, say that ports@FreeBSD.org means "community maintained" ports rather than unmaintained ports and on the other hand say that PRs can't be similarly community maintained. Most of what I do is spend a few hours of my time dispositioning old PRs because nobody else spent any effort to do so. That does NOT imply that I want any future responsibility for the PR. We are all responsible for individual commits we make, so clearly I accept that. I've said I don't want to be the "real assignee"; if I wanted that I would have changed the assignment myself. If this "policy" is already documented, please point to where it's published. I don't recall ever seeing a proposal on this asking for feedback. It just started happening.
by the way, you removed the actual maintainer, dinoex@ from the PR in order to give it to me, and I *really* have an issue about that. The maintainer, in most cases, should be the assignee no matter who actually commits.
This is the bug history: https://bugs.freebsd.org/bugzilla/show_activity.cgi?id=211353 I don't know what else to say other than what I said at the bottom of comment 3.
The end of comment #4 asked for where this publish is published and where it was discussed, so if there's nothing to say that probably means its not official policy and it wasn't developed publicly. Thus you could recognize that at least one person disagrees with it and you could say you will respect my desire not to change PR assignments (and for the matter, don't change titles when the new version is only subjectively better than the original). This is the second time it's come up. Please don't give me PR assignments any more. If bugmeister wants to come back in an official capacity and tell me to bump up a stump I'll accept it but truly limit all PR work to responding to those written against ports I maintain.