Re: CVS commit: src
Hi, Please fix usr.sbin/postinstall/postinstall for _rtadvd user and group. 2013/7/9 Roy Marples r...@netbsd.org: Module Name:src Committed By: roy Date: Tue Jul 9 09:34:59 UTC 2013 Modified Files: src/etc: group master.passwd src/etc/mtree: special src/etc/rc.d: rtadvd src/usr.sbin/rtadvd: dump.c rtadvd.c rtadvd.h Log Message: Add _rtadvd user and group. Add a chroot dir for the _rtadvd user. Drop privs to the user _rtadvd after acquiring our socket. When rc.d/rtadvd starts or reloads, the rtadvd config file is copied into the chroot before starting or reloading rtadvd itself. Create a symlink from /var/run/rtadvd.dump to the chroot Inital idea from OpenBSD patch rtadvd.c r1.36 To generate a diff of this commit: cvs rdiff -u -r1.31 -r1.32 src/etc/group cvs rdiff -u -r1.46 -r1.47 src/etc/master.passwd cvs rdiff -u -r1.145 -r1.146 src/etc/mtree/special cvs rdiff -u -r1.7 -r1.8 src/etc/rc.d/rtadvd cvs rdiff -u -r1.10 -r1.11 src/usr.sbin/rtadvd/dump.c cvs rdiff -u -r1.43 -r1.44 src/usr.sbin/rtadvd/rtadvd.c cvs rdiff -u -r1.12 -r1.13 src/usr.sbin/rtadvd/rtadvd.h Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
Re: CVS commit: src/usr.bin/make
In article krbu04$2j1$1...@ger.gmane.org,
Christos Zoulas chris...@astron.com wrote:
Module Name: src
Committed By: sjg
Date: Sat Jul 6 18:19:17 UTC 2013
Modified Files:
src/usr.bin/make: main.c var.c
Log Message:
If using gmake's MAKELEVEL; use it the same way
Now you put it back the way it was before which is wrong. Gmake does not
behave this way. Before your change the following Makefile printed:
This is still broken. Renaming the variable is not a fix either.
Consider the case where we switched from bmake to gmake as the
pkgsrc wrapper. The packages that depend on $MAKELEVEL being 0 or
unset would still break. So the proper fix for the 2 packages that
broke is to make pkgsrc unset MAKELEVEL before invoking gmake.
So to fix those:
- revert the changes so that MAKELEVEL again works the same way as in gmake.
- add glue to invoke gmake with MAKELEVEL unset.
christos
--- Makefile ---
all:
echo makelevel=${MAKELEVEL} make=${MAKE} makeflags=${MAKEFLAGS}
echo .makelevel=${.MAKELEVEL}
${MAKE} l1
l1:
echo makelevel=${MAKELEVEL} make=${MAKE} makeflags=${MAKEFLAGS}
echo .makelevel=${.MAKELEVEL}
--- Output gmake ---
echo makelevel=0 make=gmake makeflags=
makelevel=0 make=gmake makeflags=
echo .makelevel=
.makelevel=
gmake l1
gmake[1]: Entering directory `/u/christos'
echo makelevel=1 make=gmake makeflags=w
makelevel=1 make=gmake makeflags=w
echo .makelevel=
.makelevel=
gmake[1]: Leaving directory `/u/christos'
--- Output make before your fixes ---
echo makelevel=0 make=make makeflags=
makelevel=0 make=make makeflags=
echo .makelevel=0
.makelevel=0
make l1
echo makelevel=1 make=make makeflags=
makelevel=1 make=make makeflags=
echo .makelevel=1
.makelevel=1
--- Output make after your fixes --
echo makelevel=1 make=/usr/src/usr.bin/make/obj.amd64/make makeflags=
makelevel=1 make=/usr/src/usr.bin/make/obj.amd64/make makeflags=
echo .makelevel=
.makelevel=
/usr/src/usr.bin/make/obj.amd64/make l1
echo makelevel=2 make=/usr/src/usr.bin/make/obj.amd64/make makeflags=
makelevel=2 make=/usr/src/usr.bin/make/obj.amd64/make makeflags=
echo .makelevel=
.makelevel=
As I mentioned before, it makes no sense to keep the variable internally at
X and pass it to the program at X + 1, and as demonstrated, this is not
what gmake does.
christos
Re: CVS commit: src/usr.bin/make
From: chris...@astron.com (Christos Zoulas), Date: Wed, 10 Jul 2013 13:08:49 + (UTC) In article krbu04$2j1$1...@ger.gmane.org, Christos Zoulas chris...@astron.com wrote: Module Name: src Committed By:sjg Date:Sat Jul 6 18:19:17 UTC 2013 Modified Files: src/usr.bin/make: main.c var.c Log Message: If using gmake's MAKELEVEL; use it the same way Now you put it back the way it was before which is wrong. Gmake does not behave this way. Before your change the following Makefile printed: This is still broken. Renaming the variable is not a fix either. Consider the case where we switched from bmake to gmake as the pkgsrc wrapper. The packages that depend on $MAKELEVEL being 0 or unset would still break. So the proper fix for the 2 packages that broke is to make pkgsrc unset MAKELEVEL before invoking gmake. So to fix those: - revert the changes so that MAKELEVEL again works the same way as in gmake. - add glue to invoke gmake with MAKELEVEL unset. Hi, I feel second idea is not so good. Because pkgsrc creates symlink, work/.tools/bin/make, for our make and gmake. So with gmake in USE_TOOLS, it is symlink for /usr/pkg/bin/gmake, and without gmake in USE_TOOLS, it is for /usr/bin/make. I cannot distinguish them with filename. Thank you. -- Ryo ONODERA // ryo...@yk.rim.or.jp PGP fingerprint = 82A2 DC91 76E0 A10A 8ABB FD1B F404 27FA C7D1 15F3
Re: CVS commit: src/usr.bin/make
In article 20130710.232445.202823964487691297.ryo...@yk.rim.or.jp, Ryo ONODERA ryo...@yk.rim.or.jp wrote: From: chris...@astron.com (Christos Zoulas), Date: Wed, 10 Jul 2013 13:08:49 + (UTC) In article krbu04$2j1$1...@ger.gmane.org, Christos Zoulas chris...@astron.com wrote: Module Name:src Committed By: sjg Date: Sat Jul 6 18:19:17 UTC 2013 Modified Files: src/usr.bin/make: main.c var.c Log Message: If using gmake's MAKELEVEL; use it the same way Now you put it back the way it was before which is wrong. Gmake does not behave this way. Before your change the following Makefile printed: This is still broken. Renaming the variable is not a fix either. Consider the case where we switched from bmake to gmake as the pkgsrc wrapper. The packages that depend on $MAKELEVEL being 0 or unset would still break. So the proper fix for the 2 packages that broke is to make pkgsrc unset MAKELEVEL before invoking gmake. So to fix those: - revert the changes so that MAKELEVEL again works the same way as in gmake. - add glue to invoke gmake with MAKELEVEL unset. Hi, I feel second idea is not so good. Because pkgsrc creates symlink, work/.tools/bin/make, for our make and gmake. So with gmake in USE_TOOLS, it is symlink for /usr/pkg/bin/gmake, and without gmake in USE_TOOLS, it is for /usr/bin/make. I cannot distinguish them with filename. It is simple: 1. You unset it for all (easiest+safest) 2. You create a shell script instead of a symlink that does: unset MAKELEVEL exec /usr/pkg/bin/gmake $@ christos
Re: CVS commit: src/usr.bin/make
From: chris...@astron.com (Christos Zoulas), Date: Wed, 10 Jul 2013 15:08:39 + (UTC) In article 20130710.232445.202823964487691297.ryo...@yk.rim.or.jp, Ryo ONODERA ryo...@yk.rim.or.jp wrote: From: chris...@astron.com (Christos Zoulas), Date: Wed, 10 Jul 2013 13:08:49 + (UTC) In article krbu04$2j1$1...@ger.gmane.org, Christos Zoulas chris...@astron.com wrote: Module Name: src Committed By: sjg Date: Sat Jul 6 18:19:17 UTC 2013 Modified Files: src/usr.bin/make: main.c var.c Log Message: If using gmake's MAKELEVEL; use it the same way Now you put it back the way it was before which is wrong. Gmake does not behave this way. Before your change the following Makefile printed: This is still broken. Renaming the variable is not a fix either. Consider the case where we switched from bmake to gmake as the pkgsrc wrapper. The packages that depend on $MAKELEVEL being 0 or unset would still break. So the proper fix for the 2 packages that broke is to make pkgsrc unset MAKELEVEL before invoking gmake. So to fix those: - revert the changes so that MAKELEVEL again works the same way as in gmake. - add glue to invoke gmake with MAKELEVEL unset. Hi, I feel second idea is not so good. Because pkgsrc creates symlink, work/.tools/bin/make, for our make and gmake. So with gmake in USE_TOOLS, it is symlink for /usr/pkg/bin/gmake, and without gmake in USE_TOOLS, it is for /usr/bin/make. I cannot distinguish them with filename. It is simple: 1. You unset it for all (easiest+safest) 2. You create a shell script instead of a symlink that does: unset MAKELEVEL exec /usr/pkg/bin/gmake $@ Thanks for your explanation. In pkgsrc case, shell script may work. Outside pkgsrc, some program may be broken by this make(1) change. I vote to revert the changes so that MAKELEVEL again works the same way as in gmake. Thank you. -- Ryo ONODERA // ryo...@yk.rim.or.jp PGP fingerprint = 82A2 DC91 76E0 A10A 8ABB FD1B F404 27FA C7D1 15F3
