RE: svn commit: r268641 - head/usr.sbin/service

2014-07-15 Thread dteske 


> -Original Message-
> From: owner-src-committ...@freebsd.org [mailto:owner-src-
> committ...@freebsd.org] On Behalf Of Mateusz Guzik
> Sent: Tuesday, July 15, 2014 12:16 PM
> To: Bryan Drewery
> Cc: Devin Teske; src-committ...@freebsd.org; svn-src-...@freebsd.org; svn-
> src-h...@freebsd.org
> Subject: Re: svn commit: r268641 - head/usr.sbin/service
> 
> On Tue, Jul 15, 2014 at 12:59:05PM -0500, Bryan Drewery wrote:
> > On 7/14/2014 9:18 PM, Devin Teske wrote:
> > > Author: dteske
> > > Date: Tue Jul 15 02:18:55 2014
> > > New Revision: 268641
> > > URL: http://svnweb.freebsd.org/changeset/base/268641
> > >
> > > Log:
> > >   Fix an issue with service(8) where utilities such as screen(1) and 
> > > tmux(1)
> > >   would behave differently when utilizing rc-script was invoked manually
> vs.
> > >   service(8). The issue being that these utilities require the TERM 
> > > environ
> > >   variable to be set and service(8) was not passing it down.
> > >
> > >   Reported by:Michael Dexter 
> > >   PR: bin/191869
> > >   Reviewed by:allanjude
> > >   MFC after:  3 days
> > >   X-MFC-to:   stable/10, stable/9
> > >
> > > Modified:
> > >   head/usr.sbin/service/service.sh
> > >
> > > Modified: head/usr.sbin/service/service.sh
> > >
> ==
> 
> > > --- head/usr.sbin/service/service.sh  Tue Jul 15 01:03:29 2014
>   (r268640)
> > > +++ head/usr.sbin/service/service.sh  Tue Jul 15 02:18:55 2014
>   (r268641)
> > > @@ -139,7 +139,7 @@ cd /
> > >  for dir in /etc/rc.d $local_startup; do
> > >   if [ -x "$dir/$script" ]; then
> > >   [ -n "$VERBOSE" ] && echo "$script is located in $dir"
> > > - exec env -i HOME=/ PATH=/sbin:/bin:/usr/sbin:/usr/bin
> $dir/$script $*
> > > + exec env -i HOME=/ PATH=/sbin:/bin:/usr/sbin:/usr/bin
> TERM="$TERM" $dir/$script $*
> > >   fi
> > >  done
> > >
> > >
> >
> > Hm, I'm not sure about this. The "behaves differently" is exactly the
> > reason for service(8). It runs with a clean environment such as the boot
> > does. Running an rc script without service(8) will give wrong behavior
> > in many scripts that do not match boot-time behavior.
> >
> 
> Indeed, the whole point is to NOT inherit anything from calling process.
> 

I would argue that not all programs are going to like having
a nearly empty environment. Things like TERM and SHLVL
at the very least should be passed (after-all, the boot process
takes place on [a] a terminal and [b] in a shell).

Blatting out the environment feels rude and non-UNIXy.
UNIX programs can, and should expect at a minimum to
be able to interrogate the environment they are running
within -- destroying all vestiges of that environment purely
for the sake of saying "it's clean" seems counter to the
UNIX pathos.


> > As far as I can tell, TERM is not set on boot. So the rc script would
> > also not work on boot. So this change is wrong.
> >
> 
> Yes, but maybe there is a sensible default that could be used?
> 

I argue that the sensible default should be what was inherited.
Otherwise, if you want to (for example) change said default from
cons25 to xterm (just as a well-known example) then you risk
having to make the change in more than one place (rather than
letting it trickle down from ttys(5)).

Furthermore, while I can believe that TERM is not set for rc.d
scripts (because I tested it), I see no reason why this has to be.
By the time the boot process has started, we have invoked init(8)
and it has processed ttys(5) and we should know what type of
terminal we are on. Since we ought to know this information, why
_not_ pass it along to the boot scripts so that, god forbid, a boot
script might be able to handle different terminal types appropriately
(read: serial console situation). The alternative would be that the
startup script would have to invoke some C code utilizing isatty(3)
etc. on stdin which seems like more of a kludge than just revealing
$TERM.

> Alternatively, one would have to fixup rc scripts using tmux to do
> what's best for them.
> 

The only thing that will work as a patch to an rc-script to allow said rc-
script to utilize tmux or screen would be to manually set the TERM
variable to some guessed value. Considering the less-than-desired
outcome from using the wrong TERM variable, it seems obvious to me
that this is a less-than-desired solution (versus

RE: svn commit: r268641 - head/usr.sbin/service

2014-07-15 Thread dteske 
 

 

From: Benjamin Kaduk [mailto:bjkf...@gmail.com] 
Sent: Tuesday, July 15, 2014 7:24 PM
To: dte...@freebsd.org
Cc: Bryan Drewery; svn-src-head@freebsd.org; svn-src-...@freebsd.org; 
src-committ...@freebsd.org
Subject: Re: svn commit: r268641 - head/usr.sbin/service

 

On Tue, Jul 15, 2014 at 10:13 PM, mailto:dte...@freebsd.org> > wrote:


Blatting out the environment feels rude and non-UNIXy.

UNIX programs can, and should expect at a minimum to
be able to interrogate the environment they are running
within -- destroying all vestiges of that environment purely
for the sake of saying "it's clean" seems counter to the
UNIX pathos.

 

 

I'm not sure I can square this sense of "non-UNIXy" with the long-standing 
documented behavior of cron to only set SHELL, PATH, LOGNAME, and HOME.  Surely 
cron is Unixy...

 

[Devin Teske] 

Last time I checked, cron did not define the UNIX standard.

That is to say, that simply because cron decides to export

those exact 4 variables does not mean that all of UNIX

should never export any other variable.

 

I define non-UNIXy as chicanery that makes working in a

POSIX environment more difficult. In this particular case,

the issue is that should I want to find out what type of

terminal my *terminal* program is running on, I shouldn't

have to fight the system to determine the answer. Rather,

the system should (unless it has damn-good reason) freely

offer information that divulges what environment the

program is running in.

 

I am not making the argument that boot-scripts should

have access to every environment variable in the parent

namespace, but I am arguing that standard UNIX idioms

such as $TERM _should_ be provided (not providing them

is imho non-UNIX like).

-- 

Devin

___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

RE: svn commit: r268641 - head/usr.sbin/service

2014-07-15 Thread dteske 


> -Original Message-
> From: owner-src-committ...@freebsd.org [mailto:owner-src-
> committ...@freebsd.org] On Behalf Of Mateusz Guzik
> Sent: Tuesday, July 15, 2014 12:16 PM
> To: Bryan Drewery
> Cc: Devin Teske; src-committ...@freebsd.org; svn-src-...@freebsd.org; svn-
> src-h...@freebsd.org
> Subject: Re: svn commit: r268641 - head/usr.sbin/service
> 
> On Tue, Jul 15, 2014 at 12:59:05PM -0500, Bryan Drewery wrote:
> > On 7/14/2014 9:18 PM, Devin Teske wrote:
> > > Author: dteske
> > > Date: Tue Jul 15 02:18:55 2014
> > > New Revision: 268641
> > > URL: http://svnweb.freebsd.org/changeset/base/268641
> > >
> > > Log:
> > >   Fix an issue with service(8) where utilities such as screen(1) and 
> > > tmux(1)
> > >   would behave differently when utilizing rc-script was invoked manually
> vs.
> > >   service(8). The issue being that these utilities require the TERM 
> > > environ
> > >   variable to be set and service(8) was not passing it down.
> > >
> > >   Reported by:Michael Dexter 
> > >   PR: bin/191869
> > >   Reviewed by:allanjude
> > >   MFC after:  3 days
> > >   X-MFC-to:   stable/10, stable/9
> > >
> > > Modified:
> > >   head/usr.sbin/service/service.sh
> > >
> > > Modified: head/usr.sbin/service/service.sh
> > >
> ==
> 
> > > --- head/usr.sbin/service/service.sh  Tue Jul 15 01:03:29 2014
>   (r268640)
> > > +++ head/usr.sbin/service/service.sh  Tue Jul 15 02:18:55 2014
>   (r268641)
> > > @@ -139,7 +139,7 @@ cd /
> > >  for dir in /etc/rc.d $local_startup; do
> > >   if [ -x "$dir/$script" ]; then
> > >   [ -n "$VERBOSE" ] && echo "$script is located in $dir"
> > > - exec env -i HOME=/ PATH=/sbin:/bin:/usr/sbin:/usr/bin
> $dir/$script $*
> > > + exec env -i HOME=/ PATH=/sbin:/bin:/usr/sbin:/usr/bin
> TERM="$TERM" $dir/$script $*
> > >   fi
> > >  done
> > >
> > >
> >
> > Hm, I'm not sure about this. The "behaves differently" is exactly the
> > reason for service(8). It runs with a clean environment such as the boot
> > does. Running an rc script without service(8) will give wrong behavior
> > in many scripts that do not match boot-time behavior.
> >
> 
> Indeed, the whole point is to NOT inherit anything from calling process.
> 

If that were the point, then we have an issue. Because as it stands,
service(8) does _not_ accurately provide the same environment as boot.

Take the following boot script:

dte...@scribe9.vicor.com ~ $ cat /etc/rc.d/foo
#!/bin/sh
# PROVIDE: foo
set > /tmp/termtest
. /etc/rc.subr
name=foo
rcvar=foo_enable
command="/usr/local/bin/tmux"
foo_flags="new -s foo ls"
load_rc_config $name
run_rc_command "$1"

Now reboot to find the following in /tmp/termtest:

dte...@scribe9.vicor.com ~ $ cat /tmp/termtest
HOME=/
ID=/usr/bin/id
IDCMD='if [ -x /usr/bin/id ]; then /usr/bin/id -un; fi'
IFS='
'
JID=0
OPTIND=1
PATH=/sbin:/bin:/usr/sbin:/usr/bin
PPID=1
PS1='# '
PS2='> '
PS4='+ '
PS='/bin/ps -ww'
PWD=/
RC_PID=19
SYSCTL=/sbin/sysctl
SYSCTL_N='/sbin/sysctl -n'
SYSCTL_W=/sbin/sysctl
_arg=faststart
_boot=faststart
_file=/etc/rc.d/foo
_rc_conf_loaded=true
_rc_elem=/etc/rc.d/foo
_rc_elem_done=' /etc/rc.d/sysctl /etc/rc.d/hostid /etc/rc.d/zvol 
/etc/rc.d/dumpon /etc/rc.d/ddb /etc/rc.d/initrandom /etc/rc.d/geli 
/etc/rc.d/gbde /etc/rc.d/encswap /etc/rc.d/ccd /etc/rc.d/swap1 /etc/rc.d/fsck 
/etc/rc.d/root /etc/rc.d/mdconfig /etc/rc.d/hostid_save 
/etc/rc.d/mountcritlocal /etc/rc.d/zfs /etc/rc.d/var /etc/rc.d/cleanvar 
/etc/rc.d/FILESYSTEMS '
_rc_namevarlist='program chroot chdir flags fib nice user group groups'
_rc_subr_loaded=:
accept_sourceroute=NO
accounting_enable=NO
allscreens_flags=''
allscreens_kbdflags=''
always_force_depends=NO
amd_enable=NO
amd_flags='-a /.amd_mnt -l syslog /host /etc/amd.map /net /etc/amd.map'
amd_map_program=NO
amd_program=/usr/sbin/amd
apm_enable=NO
apmd_enable=NO
apmd_flags=''
arpproxy_all=NO
atm_arps=''
atm_enable=NO
atm_pvcs=''
auditd_enable=NO
auditd_flags=''
auditd_program=/usr/sbin/auditd
auditdistd_enable=NO
auditdistd_flags=''
auditdistd_program=/usr/sbin/auditdistd
autoboot=yes
background_dhclient=NO
background_fsck=YES
background_fsck_delay=60
bhyve_enable=NO
bhyve_profiles='virt1 virt2'
blanktime=300
boo

RE: svn commit: r268641 - head/usr.sbin/service

2014-07-15 Thread dteske 


> -Original Message-
> From: owner-src-committ...@freebsd.org [mailto:owner-src-
> committ...@freebsd.org] On Behalf Of Bryan Drewery
> Sent: Tuesday, July 15, 2014 10:59 AM
> To: Devin Teske; src-committ...@freebsd.org; svn-src-...@freebsd.org; svn-
> src-h...@freebsd.org
> Subject: Re: svn commit: r268641 - head/usr.sbin/service
> 
[snip]
> Running an rc script without service(8) will give wrong behavior
> in many scripts that do not match boot-time behavior.
> 
> As far as I can tell, TERM is not set on boot. So the rc script would
> also not work on boot. So this change is wrong.

So we're saying that service should only be used for boot-scripts
when in reality not all rc.d scripts may be used at boot but some
may be used as "service" scripts invoked only at multi-user runtime?
-- 
Devin

___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

RE: svn commit: r268641 - head/usr.sbin/service

2014-07-15 Thread dteske 


> -Original Message-
> From: Bryan Drewery [mailto:bdrew...@freebsd.org]
> Sent: Tuesday, July 15, 2014 8:44 PM
> To: dte...@freebsd.org; 'Mateusz Guzik'
> Cc: src-committ...@freebsd.org; svn-src-...@freebsd.org; svn-src-
> h...@freebsd.org
> Subject: Re: svn commit: r268641 - head/usr.sbin/service
> 
> On 7/15/14, 9:48 PM, dte...@freebsd.org wrote:
> >
> >
> >> -Original Message-
> >> From: owner-src-committ...@freebsd.org [mailto:owner-src-
> >> committ...@freebsd.org] On Behalf Of Mateusz Guzik
> >> Sent: Tuesday, July 15, 2014 12:16 PM
> >> To: Bryan Drewery
> >> Cc: Devin Teske; src-committ...@freebsd.org; svn-src-...@freebsd.org;
> svn-
> >> src-h...@freebsd.org
> >> Subject: Re: svn commit: r268641 - head/usr.sbin/service
> >>
> >> On Tue, Jul 15, 2014 at 12:59:05PM -0500, Bryan Drewery wrote:
> >>> On 7/14/2014 9:18 PM, Devin Teske wrote:
> >>>> Author: dteske
> >>>> Date: Tue Jul 15 02:18:55 2014
> >>>> New Revision: 268641
> >>>> URL: http://svnweb.freebsd.org/changeset/base/268641
> >>>>
> >>>> Log:
> >>>>Fix an issue with service(8) where utilities such as screen(1)
and
> tmux(1)
> >>>>would behave differently when utilizing rc-script was invoked
> manually
> >> vs.
> >>>>service(8). The issue being that these utilities require the TERM
> environ
> >>>>variable to be set and service(8) was not passing it down.
> >>>>
> >>>>Reported by:  Michael Dexter 
> >>>>PR:   bin/191869
> >>>>Reviewed by:  allanjude
> >>>>MFC after:3 days
> >>>>X-MFC-to: stable/10, stable/9
> >>>>
> >>>> Modified:
> >>>>head/usr.sbin/service/service.sh
> >>>>
> >>>> Modified: head/usr.sbin/service/service.sh
> >>>>
> >>
> ==
> >> 
> >>>> --- head/usr.sbin/service/service.sh Tue Jul 15 01:03:29 2014
> >>(r268640)
> >>>> +++ head/usr.sbin/service/service.sh Tue Jul 15 02:18:55 2014
> >>(r268641)
> >>>> @@ -139,7 +139,7 @@ cd /
> >>>>   for dir in /etc/rc.d $local_startup; do
> >>>>  if [ -x "$dir/$script" ]; then
> >>>>  [ -n "$VERBOSE" ] && echo "$script is located in
$dir"
> >>>> -exec env -i HOME=/
PATH=/sbin:/bin:/usr/sbin:/usr/bin
> >> $dir/$script $*
> >>>> +exec env -i HOME=/
PATH=/sbin:/bin:/usr/sbin:/usr/bin
> >> TERM="$TERM" $dir/$script $*
> >>>>  fi
> >>>>   done
> >>>>
> >>>>
> >>>
> >>> Hm, I'm not sure about this. The "behaves differently" is exactly the
> >>> reason for service(8). It runs with a clean environment such as the
boot
> >>> does. Running an rc script without service(8) will give wrong
behavior
> >>> in many scripts that do not match boot-time behavior.
> >>>
> >>
> >> Indeed, the whole point is to NOT inherit anything from calling
process.
> >>
> >
> > If that were the point, then we have an issue. Because as it stands,
> > service(8) does _not_ accurately provide the same environment as boot.
> >
> > Take the following boot script:
> >
> > dte...@scribe9.vicor.com ~ $ cat /etc/rc.d/foo
> > #!/bin/sh
> > # PROVIDE: foo
> > set > /tmp/termtest
> > . /etc/rc.subr
> > name=foo
> > rcvar=foo_enable
> > command="/usr/local/bin/tmux"
> > foo_flags="new -s foo ls"
> > load_rc_config $name
> > run_rc_command "$1"
> >
> > Now reboot to find the following in /tmp/termtest:
> >
> > dte...@scribe9.vicor.com ~ $ cat /tmp/termtest
> > HOME=/
> > ID=/usr/bin/id
> > IDCMD='if [ -x /usr/bin/id ]; then /usr/bin/id -un; fi'
> > IFS='
> > '
> > JID=0
> > OPTIND=1
> > PATH=/sbin:/bin:/usr/sbin:/usr/bin
> > PPID=1
> > PS1='# '
> > PS2='> '
> > PS4='+ '
> > PS='/bin/ps -ww'
> > PWD=/
> > RC_PID=19
> > SYSCTL=/sbin/sysctl
> > SYSCTL_N='/sbin/sysctl -n'
> > SYSCTL_W=/sbin/sys

RE: svn commit: r268641 - head/usr.sbin/service

2014-07-15 Thread dteske 


> -Original Message-
> From: Jordan Hubbard [mailto:jordanhubb...@me.com]
> Sent: Tuesday, July 15, 2014 9:39 PM
> To: dte...@freebsd.org
> Cc: Mateusz Guzik; Bryan Drewery; src-committ...@freebsd.org; svn-src-
> a...@freebsd.org; svn-src-head@freebsd.org
> Subject: Re: svn commit: r268641 - head/usr.sbin/service
> 
> On Jul 15, 2014, at 7:13 PM, dte...@freebsd.org wrote:
> 
> > I would argue that not all programs are going to like having
> > a nearly empty environment. Things like TERM and SHLVL
> > at the very least should be passed (after-all, the boot process
> > takes place on [a] a terminal and [b] in a shell).
> 
> Having launchd scrub every processes environment down to nothing, then
> have environment variables be set explicitly as part of that processes'
> "launch contract" was one of the best decisions we ever made at Apple.
> 
> The Unix process environment is a septic tank, and that's actually being
kind
> since most septic tanks don't also contain bottles of nerve gas and the
> occasional live hand grenade.  Many parts of the environment are trivially
> attackable, and if anyone on the CC line thinks they know the full extent
of
> that attack surface, they're wrong.  Not because there aren't some
> extremely smart Unix people in the audience, but because it's simply
> impossible to know how each and every environment variable will be used,
> how it can overflow, or how it can be used to permute a program's behavior
> in unpredictable ways.   Even if the intention isn't to be hostile, you
can still
> cause some truly Heisenbergian results by having the environment be
> unpredictable in nature.
> 
> It may not be "Unixy", but Unix didn't grow up in a world with millions of
> instances of itself or the big, bad Internet encompassing pretty much
every
> country on earth.  Changes need to be made to keep up with the times, and
> you can rest assured that FreeBSD's competition is making those changes or
> has already made them.
> 
> I also find it a frankly weird assertion that a background service would
care
> about the value of TERM.  That sounds like a pretty warped service to me,
> since assuming interactivity is more the exception than the rule these
days.
> 

Odd indeed. An rc.d script needs to know $TERM so it can launch a background
instance of screen or tmux. The rc.d script itself doesn't use $TERM but the
instance of screen or tmux needs it else it thinks you're not on a terminal
(maybe
the proper thing is to patch screen and tmux ;D).
-- 
Devin

___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

RE: svn commit: r268641 - head/usr.sbin/service

2014-07-15 Thread dteske 
 

 

From: Jordan Hubbard [mailto:jordanhubb...@me.com] 
Sent: Tuesday, July 15, 2014 9:42 PM
To: dte...@freebsd.org
Cc: Benjamin Kaduk; Bryan Drewery; svn-src-head@freebsd.org;
svn-src-...@freebsd.org; src-committ...@freebsd.org
Subject: Re: svn commit: r268641 - head/usr.sbin/service

 

 

On Jul 15, 2014, at 7:40 PM, dte...@freebsd.org 
wrote:





I define non-UNIXy as chicanery that makes working in a

POSIX environment more difficult

 

POSIX does not define or mandate any specific set of environment variables.
OS X is POSIX and UNIX03 compliant (and qualified to use the Unix trademark,
unlike FreeBSD), and I've already described its behavior with respect to
environment variables.  Be careful how you sling terms like POSIX or UnixT
around. ;-)

 

[Devin Teske] 

(smiles) Will do. However I'm re-reading my statement and holding

to the meaning I've interred it:

 

Windows has POSIX compliance

Mac OS X has POSIX compliance

So does Linux, as does FreeBSD

 

If working in one of these POSIX environments (note: the Windows POSIX

environment I use is MinGW) compiling C code, using standard POSIX APIs,

etc. I view the overall environment as being non-UNIXy if that POSIX

environment is not properly integrated.

 

Now, my statement's standpoint is that if my POSIX system has the API

calls to inter the terminal type I'm being run within, is the overall system

outside ignoring this POSIX-made-available information?

 

So example would be Windows as being non-UNIXy (this I believe we agree

upon). Non-UNIXy because while I can load the MinGW or SFU or Cygwin

layers to access POSIX-compliant APIs, Windows itself could care less about

that layer. It's not integrated.

 

Skipping Mac OS X, looking at FreeBSD, my statement was designed to

encapsulate that we actively seek to maintain great compliance with POSIX

and also (maybe this is the leap; but I would think) try to make sure we

integrate that information as often as possible. (and thus, not force
someone

to build a layer on-top of the boot process to re-access the data that
should

perhaps already be made available -- e.g., $TERM to know what we're running

within).

-- 

Devin

___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

RE: svn commit: r268641 - head/usr.sbin/service

2014-07-15 Thread dteske 


> -Original Message-
> From: adrian.ch...@gmail.com [mailto:adrian.ch...@gmail.com] On Behalf
> Of Adrian Chadd
> Sent: Tuesday, July 15, 2014 10:19 PM
> To: Mark Linimon
> Cc: Devin Teske; Mateusz Guzik; Bryan Drewery; svn-src-head@freebsd.org;
> svn-src-...@freebsd.org; src-committ...@freebsd.org
> Subject: Re: svn commit: r268641 - head/usr.sbin/service
> 
> On 15 July 2014 22:08, Mark Linimon  wrote:
> > On Tue, Jul 15, 2014 at 07:13:44PM -0700, dte...@freebsd.org wrote:
> >> destroying all vestiges of that environment purely for the sake of
> >> saying "it's clean" seems counter to the UNIX pathos.
> >
> > I think you mean "ethos" here, but frankly I like it better this way.
> 
> I'm a bit confused by this thread.
> 
> screen and tmux are interactive processes. They're not designed to be
> run as UNIX services.
> 
> Why is this even happening?
> 
> 

You can instantiate a pre-detached named-session.
-- 
Devin

___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

RE: svn commit: r268641 - head/usr.sbin/service

2014-07-16 Thread dteske 


> -Original Message-
> From: owner-src-committ...@freebsd.org [mailto:owner-src-
> committ...@freebsd.org] On Behalf Of O'Connor, Daniel
> Sent: Wednesday, July 16, 2014 1:58 AM
> To: Adrian Chadd
> Cc: Mark Linimon; Mateusz Guzik; svn-src-...@freebsd.org; Bryan Drewery;
> src-committ...@freebsd.org; svn-src-head@freebsd.org; Devin Teske
> Subject: Re: svn commit: r268641 - head/usr.sbin/service
> 
> 
> On 16 Jul 2014, at 14:49, Adrian Chadd  wrote:
> > On 15 July 2014 22:08, Mark Linimon  wrote:
> >> On Tue, Jul 15, 2014 at 07:13:44PM -0700, dte...@freebsd.org wrote:
> >>> destroying all vestiges of that environment purely for the sake of
> >>> saying "it's clean" seems counter to the UNIX pathos.
> >>
> >> I think you mean "ethos" here, but frankly I like it better this way.
> >
> > I'm a bit confused by this thread.
> >
> > screen and tmux are interactive processes. They're not designed to be
> > run as UNIX services.
> >
> > Why is this even happening?
> 
> The mine craft server port uses tmux so you can fiddle with the MC console
> later.
> 
> Neither screen nor tmux cares if TERM is set when it is run, e.g.
> 
> [midget 18:25] ~ >env -i /usr/local/bin/tmux new-session -d
> [midget 18:25] ~ >tmux ls
> 0: 1 windows (created Wed Jul 16 18:25:33 2014) [241x38]
> 
> [midget 18:26] ~ >env -i /usr/local/bin/screen -d -m
> [midget 18:26] ~ >screen -ls
> There are screens on:
>   30081..midget   (Detached)
> 3 Sockets in /tmp/screens/S-darius.
> 

Looks like "-d" is the magic that needs to be used in rc.d scripts.

Thanks! I'll start spreading that knowledge and reverse r268641.
-- 
Devin

___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

RE: svn commit: r268641 - head/usr.sbin/service

2014-07-16 Thread dteske 


> -Original Message-
> From: Devin Teske [mailto:de...@shxd.cx]
> Sent: Wednesday, July 16, 2014 9:20 AM
> To: 'O'Connor, Daniel'; 'Adrian Chadd'
> Cc: 'Mark Linimon'; 'Mateusz Guzik'; 'svn-src-...@freebsd.org'; 'Bryan
> Drewery'; 'src-committ...@freebsd.org'; 'svn-src-head@freebsd.org'; 'Devin
> Teske'
> Subject: RE: svn commit: r268641 - head/usr.sbin/service
> 
> 
> 
> > -Original Message-
> > From: owner-src-committ...@freebsd.org [mailto:owner-src-
> > committ...@freebsd.org] On Behalf Of O'Connor, Daniel
> > Sent: Wednesday, July 16, 2014 1:58 AM
> > To: Adrian Chadd
> > Cc: Mark Linimon; Mateusz Guzik; svn-src-...@freebsd.org; Bryan Drewery;
> > src-committ...@freebsd.org; svn-src-head@freebsd.org; Devin Teske
> > Subject: Re: svn commit: r268641 - head/usr.sbin/service
> >
> >
> > On 16 Jul 2014, at 14:49, Adrian Chadd  wrote:
> > > On 15 July 2014 22:08, Mark Linimon  wrote:
> > >> On Tue, Jul 15, 2014 at 07:13:44PM -0700, dte...@freebsd.org wrote:
> > >>> destroying all vestiges of that environment purely for the sake of
> > >>> saying "it's clean" seems counter to the UNIX pathos.
> > >>
> > >> I think you mean "ethos" here, but frankly I like it better this way.
> > >
> > > I'm a bit confused by this thread.
> > >
> > > screen and tmux are interactive processes. They're not designed to be
> > > run as UNIX services.
> > >
> > > Why is this even happening?
> >
> > The mine craft server port uses tmux so you can fiddle with the MC
console
> > later.
> >
> > Neither screen nor tmux cares if TERM is set when it is run, e.g.
> >
> > [midget 18:25] ~ >env -i /usr/local/bin/tmux new-session -d
> > [midget 18:25] ~ >tmux ls
> > 0: 1 windows (created Wed Jul 16 18:25:33 2014) [241x38]
> >
> > [midget 18:26] ~ >env -i /usr/local/bin/screen -d -m
> > [midget 18:26] ~ >screen -ls
> > There are screens on:
> > 30081..midget   (Detached)
> > 3 Sockets in /tmp/screens/S-darius.
> >
> 
> Looks like "-d" is the magic that needs to be used in rc.d scripts.
> 
> Thanks! I'll start spreading that knowledge and reverse r268641.

Reverted. Thanks much!
-- 
Devin

___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

RE: svn commit: r270283 - head/usr.sbin/bsdconfig/share/packages

2014-08-21 Thread dteske 


> -Original Message-
> From: owner-src-committ...@freebsd.org [mailto:owner-src-
> committ...@freebsd.org] On Behalf Of Bryan Drewery
> Sent: Thursday, August 21, 2014 10:17 AM
> To: Devin Teske; src-committ...@freebsd.org; svn-src-...@freebsd.org; svn-
> src-h...@freebsd.org
> Subject: Re: svn commit: r270283 - head/usr.sbin/bsdconfig/share/packages
> 
> On 8/21/2014 12:15 PM, Devin Teske wrote:
> > Author: dteske
> > Date: Thu Aug 21 17:15:09 2014
> > New Revision: 270283
> > URL: http://svnweb.freebsd.org/changeset/base/270283
> >
> > Log:
> >   Add `-A' flag to pkg-install(8) invocation when installing dependencies.
> 
> Thank you!!
> 

To my recollection, nobody brought this to my attention before yesterday.
-- 
Devin

___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

RE: svn commit: r264243 - in head/etc: . rc.d

2014-04-08 Thread dteske 


> -Original Message-
> From: John Baldwin [mailto:j...@freebsd.org]
> Sent: Tuesday, April 8, 2014 6:17 AM
> To: Devin Teske
> Cc: src-committ...@freebsd.org; svn-src-...@freebsd.org; svn-src-
> h...@freebsd.org
> Subject: Re: svn commit: r264243 - in head/etc: . rc.d
> 
> On Monday, April 07, 2014 6:40:29 pm Devin Teske wrote:
> > Author: dteske
> > Date: Mon Apr  7 22:40:29 2014
> > New Revision: 264243
> > URL:
> > https://urldefense.proofpoint.com/v1/url?u=http://svnweb.freebsd.org/c
> >
> hangeset/base/264243&k=%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0A&r=
> Mrjs6vR4%
> >
> 2Faj2Ns9%2FssHJjg%3D%3D%0A&m=x4%2FOSlYxZmvxfxF1vsS2F3iOmYffhRw
> 7e5mRGSs
> >
> LUeM%3D%0A&s=f09e9f49a3e96b674c5845e5ca0b0ffe54de091cfb020683aa2
> fc358b
> > 8f7182d
> >
> > Log:
> >   Loosen the processing of *_IF_aliasN vars to be less strict. Previously,
> >   the first alias had to be _alias0 and processing stopped at the first non-
> >   defined variable (preventing gaps). Allowing gaps gives the administrator
> >   the ability to group aliases in an adhoc manner and also lifts the
> >   requirement to renumber aliases simply to comment-out an existing one.
> >   Aliases are processed in numerical ascending order.
> >
> >   Discussed on: -rc
> >   MFC after:1 week
> 
> Forgot to mention mdconfig in the log message (or did you mean to commit
> that separately)?
> 

Nah, forgot to mention mdconfig in the commit message as you state.
-- 
Devin



_
The information contained in this message is proprietary and/or confidential. 
If you are not the intended recipient, please: (i) delete the message and all 
copies; (ii) do not disclose, distribute or use the message in any manner; and 
(iii) notify the sender immediately. In addition, please be aware that any 
message addressed to our domain is subject to archiving and review by persons 
other than the intended recipient. Thank you.
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

RE: svn commit: r274203 - head

2014-11-06 Thread dteske 


> -Original Message-
> From: Steve Kargl [mailto:s...@troutmask.apl.washington.edu]
> Sent: Thursday, November 6, 2014 3:05 PM
> To: Devin Teske
> Cc: src-committ...@freebsd.org; svn-src-...@freebsd.org; svn-src-
> h...@freebsd.org
> Subject: Re: svn commit: r274203 - head
> 
> On Thu, Nov 06, 2014 at 10:53:50PM +, Devin Teske wrote:
> > Author: dteske
> > Date: Thu Nov  6 22:53:50 2014
> > New Revision: 274203
> > URL: https://svnweb.freebsd.org/changeset/base/274203
> >
> > Log:
> >   SUBDIR_DEPENDS__ in lib/Makefile is not working out so well for me.
> >   Add to using _prebuild_libs in (top-level) Makefile.inc1.
> >   NB: Unbreak build yet again (we'll get this right eventually)
> 
> Any chance that you can test your changes before committing?
> 

I don't have a -CURRENT box; and -CURRENT is giving different results.
-- 
Devin


___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

RE: svn commit: r274203 - head

2014-11-06 Thread dteske 


> -Original Message-
> From: owner-src-committ...@freebsd.org [mailto:owner-src-
> committ...@freebsd.org] On Behalf Of Steve Kargl
> Sent: Thursday, November 6, 2014 4:56 PM
> To: NGie Cooper
> Cc: Devin Teske; src-committ...@freebsd.org; svn-src-...@freebsd.org; svn-
> src-h...@freebsd.org
> Subject: Re: svn commit: r274203 - head
> 
> On Thu, Nov 06, 2014 at 03:19:19PM -0800, NGie Cooper wrote:
> > On Thu, Nov 6, 2014 at 3:06 PM,   wrote:
> > >
> > >> -Original Message-
> > >> From: Steve Kargl [mailto:s...@troutmask.apl.washington.edu]
> > >> Sent: Thursday, November 6, 2014 3:05 PM
> > >> To: Devin Teske
> > >> Cc: src-committ...@freebsd.org; svn-src-...@freebsd.org; svn-src-
> > >> h...@freebsd.org
> > >> Subject: Re: svn commit: r274203 - head
> > >>
> > >> On Thu, Nov 06, 2014 at 10:53:50PM +, Devin Teske wrote:
> > >> > Author: dteske
> > >> > Date: Thu Nov  6 22:53:50 2014
> > >> > New Revision: 274203
> > >> > URL: https://svnweb.freebsd.org/changeset/base/274203
> > >> >
> > >> > Log:
> > >> >   SUBDIR_DEPENDS__ in lib/Makefile is not working out so well for
me.
> > >> >   Add to using _prebuild_libs in (top-level) Makefile.inc1.
> > >> >   NB: Unbreak build yet again (we'll get this right eventually)
> > >>
> > >> Any chance that you can test your changes before committing?
> > >>
> > >
> > > I don't have a -CURRENT box; and -CURRENT is giving different results.
> >
> > freefall's a pretty good build box for starters potentially (just
> > point MAKEOBJDIRPREFIX to $HOME/obj)
> >
> > The real problem is that there's some build tiering that's taking
> > place between different portions of the build, and depending on when
> > and how things get done, things can go awry.
> >
> 
> Yes, things can sometimes go awry.  But, getting a daily email (if
> not more than one a day) from jenkins-admin is verging on spam
> (i.e., a procmail rule to send these messages to /dev/null).
> 
> And to be clear, I'm not picking specifically on Devin.  Jenkins
> seems to be upset with a few other committers, too.
> 

Ugh; I fixed *my* build issue, but yeah... the build appears to still
be broken. This time appears to not be related to anything I've done.

--- rescue.all__D ---
echo "int _crunched_cat_stub(int argc, char **argv, char **envp){return
main(argc,argv,envp);}" >cat_stub.c
make[5]: make[5]: don't know how to make
/home/dteske/obj/home/dteske/src/freebsd_svn/base/head/rescue/rescue//home/d
teske/src/freebsd_svn/base/head/bin/cat/cat.o. Stop

make[5]: stopped in
/home/dteske/obj/home/dteske/src/freebsd_svn/base/head/rescue/rescue
*** [rescue] Error code 2
-- 
Devin

___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

RE: svn commit: r274203 - head

2014-11-06 Thread dteske 


> -Original Message-
> From: owner-src-committ...@freebsd.org [mailto:owner-src-
> committ...@freebsd.org] On Behalf Of dte...@freebsd.org
> Sent: Thursday, November 6, 2014 5:33 PM
> To: 'Steve Kargl'; 'NGie Cooper'
> Cc: 'Devin Teske'; src-committ...@freebsd.org; svn-src-...@freebsd.org;
> svn-src-head@freebsd.org
> Subject: RE: svn commit: r274203 - head
> 
> 
> 
> > -Original Message-
> > From: owner-src-committ...@freebsd.org [mailto:owner-src-
> > committ...@freebsd.org] On Behalf Of Steve Kargl
> > Sent: Thursday, November 6, 2014 4:56 PM
> > To: NGie Cooper
> > Cc: Devin Teske; src-committ...@freebsd.org; svn-src-...@freebsd.org;
> svn-
> > src-h...@freebsd.org
> > Subject: Re: svn commit: r274203 - head
> >
> > On Thu, Nov 06, 2014 at 03:19:19PM -0800, NGie Cooper wrote:
> > > On Thu, Nov 6, 2014 at 3:06 PM,   wrote:
> > > >
> > > >> -Original Message-
> > > >> From: Steve Kargl [mailto:s...@troutmask.apl.washington.edu]
> > > >> Sent: Thursday, November 6, 2014 3:05 PM
> > > >> To: Devin Teske
> > > >> Cc: src-committ...@freebsd.org; svn-src-...@freebsd.org; svn-src-
> > > >> h...@freebsd.org
> > > >> Subject: Re: svn commit: r274203 - head
> > > >>
> > > >> On Thu, Nov 06, 2014 at 10:53:50PM +, Devin Teske wrote:
> > > >> > Author: dteske
> > > >> > Date: Thu Nov  6 22:53:50 2014
> > > >> > New Revision: 274203
> > > >> > URL: https://svnweb.freebsd.org/changeset/base/274203
> > > >> >
> > > >> > Log:
> > > >> >   SUBDIR_DEPENDS__ in lib/Makefile is not working out so well for
> me.
> > > >> >   Add to using _prebuild_libs in (top-level) Makefile.inc1.
> > > >> >   NB: Unbreak build yet again (we'll get this right eventually)
> > > >>
> > > >> Any chance that you can test your changes before committing?
> > > >>
> > > >
> > > > I don't have a -CURRENT box; and -CURRENT is giving different
results.
> > >
> > > freefall's a pretty good build box for starters potentially (just
> > > point MAKEOBJDIRPREFIX to $HOME/obj)
> > >
> > > The real problem is that there's some build tiering that's taking
> > > place between different portions of the build, and depending on when
> > > and how things get done, things can go awry.
> > >
> >
> > Yes, things can sometimes go awry.  But, getting a daily email (if
> > not more than one a day) from jenkins-admin is verging on spam
> > (i.e., a procmail rule to send these messages to /dev/null).
> >
> > And to be clear, I'm not picking specifically on Devin.  Jenkins
> > seems to be upset with a few other committers, too.
> >
> 
> Ugh; I fixed *my* build issue, but yeah... the build appears to still
> be broken. This time appears to not be related to anything I've done.
> 
> --- rescue.all__D ---
> echo "int _crunched_cat_stub(int argc, char **argv, char **envp){return
> main(argc,argv,envp);}" >cat_stub.c
> make[5]: make[5]: don't know how to make
> /home/dteske/obj/home/dteske/src/freebsd_svn/base/head/rescue/rescu
> e//home/d
> teske/src/freebsd_svn/base/head/bin/cat/cat.o. Stop
> 
> make[5]: stopped in
> /home/dteske/obj/home/dteske/src/freebsd_svn/base/head/rescue/rescu
> e
> *** [rescue] Error code 2
> --
> Devin
> 

Command I used was:

time make -j10 SRCCONF=/dev/null MAKEOBJDIRPREFIX=$HOME/obj buildworld

It took 32m49s to get to the error.

Here's the hardware:
  CPU: Intel(R) Xeon(R) CPU   E5410  @ 2.33GHz (2327.55-MHz
K8-class CPU)
real memory  = 68719476736 (65536 MB)
avail memory = 65626365952 (62586 MB)
FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs
-- 
Devin

___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

RE: svn commit: r274394 - in head/usr.sbin: bsdconfig/timezone tzsetup

2014-11-11 Thread dteske 


> -Original Message-
> From: owner-src-committ...@freebsd.org [mailto:owner-src-
> committ...@freebsd.org] On Behalf Of Nathan Whitehorn
> Sent: Tuesday, November 11, 2014 11:42 AM
> To: Devin Teske; src-committ...@freebsd.org; svn-src-...@freebsd.org; svn-
> src-h...@freebsd.org
> Subject: Re: svn commit: r274394 - in head/usr.sbin: bsdconfig/timezone
> tzsetup
> 
> 
> On 11/11/14 11:37, Devin Teske wrote:
> > Author: dteske
> > Date: Tue Nov 11 19:37:17 2014
> > New Revision: 274394
> > URL: https://svnweb.freebsd.org/changeset/base/274394
> >
> > Log:
> >Default `bsdconfig timezone' and `tzsetup' to `-s' in a VM.
> >
> >Recommended by:  cperciva
> >Reviewed by: cperciva
> >Relnotes:tzsetup and bsdconfig now assume that the "hardware" 
> > clock
> inside a VM is set to UTC
> >
> > Modified:
> >head/usr.sbin/bsdconfig/timezone/timezone
> >head/usr.sbin/tzsetup/tzsetup.c
> >
> > Modified: head/usr.sbin/bsdconfig/timezone/timezone
> >
> ==
> 
> > --- head/usr.sbin/bsdconfig/timezone/timezone   Tue Nov 11 19:12:57
> 2014  (r274393)
> > +++ head/usr.sbin/bsdconfig/timezone/timezone   Tue Nov 11 19:37:17
> 2014  (r274394)
> > @@ -62,7 +62,7 @@ _PATH_WALL_CMOS_CLOCK="/etc/wall_cmos_cl
> >   REALLYDOIT=1
> >   REINSTALL=
> >   USEDIALOG=1
> > -SKIPUTC=
> > +SKIPUTC= # See MAIN
> >   VERBOSE=
> >   TZ_OR_FAIL=
> >   CHROOTENV=
> > @@ -119,6 +119,9 @@ dialog_menu_main()
> >
> >
> ##
> ## MAIN
> >
> > +# Skip initial question regarding UTC v. Wall-Clock time if run in VM
> > +[ "$( sysctl -n kern.vm_guest 2> /dev/null )" = "none" ] || SKIPUTC=1
> > +
> >   # Incorporate rc-file if it exists
> >   [ -f "$HOME/.bsdconfigrc" ] && f_include "$HOME/.bsdconfigrc"
> >
> >
> > Modified: head/usr.sbin/tzsetup/tzsetup.c
> >
> ==
> 
> > --- head/usr.sbin/tzsetup/tzsetup.c Tue Nov 11 19:12:57 2014
>   (r274393)
> > +++ head/usr.sbin/tzsetup/tzsetup.c Tue Nov 11 19:37:17 2014
>   (r274394)
> > @@ -47,6 +47,7 @@ __FBSDID("$FreeBSD$");
> >   #include 
> >   #include 
> >   #include 
> > +#include 
> >
> >   #include 
> >
> > @@ -910,8 +911,16 @@ main(int argc, char **argv)
> >   {
> > chartitle[64], prompt[128];
> > int c, fd, rv, skiputc;
> > +char   vm_guest[16] = "";
> > +size_t len = sizeof(vm_guest);
> >
> > skiputc = 0;
> > +
> > +   /* Default skiputc to 1 for VM guests */
> > +if (sysctlbyname("kern.vm_guest", vm_guest, &len, NULL, 0) == 0 &&
> > +   strcmp(vm_guest, "none") != 0)
> > +skiputc = 1;
> > +
> > while ((c = getopt(argc, argv, "C:nrs")) != -1) {
> > switch(c) {
> > case 'C':
> >
> 
> You've mixed tabs and spaces here. Could you fix it?

Fixed. Thanks.
-- 
Devin


___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

RE: svn commit: r274925 - in head: lib/libc/sys lib/libdpv sbin/ipfw share/man/man4 share/man/man4/man4.arm share/man/man9 sys/boot/common sys/boot/i386/gptzfsboot usr.bin/dpv

2014-11-24 Thread dteske 


> -Original Message-
> From: owner-src-committ...@freebsd.org [mailto:owner-src-
> committ...@freebsd.org] On Behalf Of Joel Dahl
> Sent: Sunday, November 23, 2014 1:00 PM
> To: src-committ...@freebsd.org; svn-src-...@freebsd.org; svn-src-
> h...@freebsd.org
> Subject: svn commit: r274925 - in head: lib/libc/sys lib/libdpv sbin/ipfw
> share/man/man4 share/man/man4/man4.arm share/man/man9
> sys/boot/common sys/boot/i386/gptzfsboot usr.bin/dpv
> 
> Author: joel (doc committer)
> Date: Sun Nov 23 21:00:00 2014
> New Revision: 274925
> URL: https://svnweb.freebsd.org/changeset/base/274925
> 
> Log:
>   Misc mdoc fixes:
> 
>   - Remove superfluous paragraph macros.
>   - Remove/fix empty or incorrect macros.
>   - Sort sections into conventional order.
>   - Terminate quoted strings properly.
>   - Remove EOL whitespace.
> 
> Modified:
[snip]
>   head/lib/libdpv/dpv.3
[snip]
>   head/usr.bin/dpv/dpv.1
[snip]
> Modified: head/lib/libdpv/dpv.3
> ==
> 
> --- head/lib/libdpv/dpv.3 Sun Nov 23 19:13:17 2014(r274924)
> +++ head/lib/libdpv/dpv.3 Sun Nov 23 21:00:00 2014(r274925)
> @@ -502,7 +502,7 @@ This does not effect
>  .Xr Xdialog 1 ,
>  which renders the color escape sequences as plain text.
>  See
> -.Do Li
> +.Do
>  embedded "\\Z" sequences
>  .Dc
>  in
> 
[snip]
> Modified: head/usr.bin/dpv/dpv.1
> ==
> 
> --- head/usr.bin/dpv/dpv.1Sun Nov 23 19:13:17 2014(r274924)
> +++ head/usr.bin/dpv/dpv.1Sun Nov 23 21:00:00 2014(r274925)
> @@ -104,7 +104,7 @@ Do not use the default interface of
>  .Xr dialog 3 ,
>  but instead spawn an instance of
>  .Xr dialog 1 .
> -The path to
> +The path to
>  .Xr dialog 1
>  is taken from the
>  .Ev DIALOG
> @@ -308,7 +308,6 @@ is required.
>  .It Pa $HOME/.dialogrc
>  .El
>  .Sh EXAMPLES
> -.Pp
>  Simple example to show how fast
>  .Xr yes 1
>  produces lines
> @@ -358,7 +357,18 @@ Zeroing a disk:
>  .Bd -literal -offset indent
>  dpv -o /dev/md42 < /dev/zero
>  .Ed
> -.Pp
> +.Sh SEE ALSO
> +.Xr dialog 1 ,
> +.Xr dialog 3 ,
> +.Xr sh 1 ,
> +.Xr Xdialog 1
> +.Sh HISTORY
> +A
> +.Nm
> +utility first appeared in
> +.Fx 11.0 .
> +.Sh AUTHORS
> +.An Devin Teske Aq dte...@freebsd.org
>  .Sh BUGS
>  .Xr Xdialog 1 ,
>  when given both
> @@ -410,21 +420,9 @@ This does not effect
>  .Xr Xdialog 1 ,
>  which renders the color escape sequences as plain text.
>  See
> -.Do Li
> +.Do
>  embedded "\\Z" sequences
>  .Dc
>  in
>  .Xr dialog 1
>  for additional information.
> -.Sh SEE ALSO
> -.Xr dialog 1 ,
> -.Xr dialog 3 ,
> -.Xr sh 1 ,
> -.Xr Xdialog 1
> -.Sh HISTORY
> -A
> -.Nm
> -utility first appeared in
> -.Fx 11.0 .
> -.Sh AUTHORS
> -.An Devin Teske Aq dte...@freebsd.org

Should these changes be MFC'd to stable/10, stable/9?
-- 
Devin

___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

RE: svn commit: r264935 - head/release/amd64

2014-04-25 Thread dteske 


> -Original Message-
> From: Nathan Whitehorn [mailto:nwhiteh...@freebsd.org]
> Sent: Friday, April 25, 2014 3:09 PM
> To: Glen Barber
> Cc: src-committ...@freebsd.org; svn-src-...@freebsd.org; svn-src-
> h...@freebsd.org
> Subject: Re: svn commit: r264935 - head/release/amd64
> 
> 
> On 04/25/14 15:06, Glen Barber wrote:
> > On Fri, Apr 25, 2014 at 02:58:34PM -0700, Nathan Whitehorn wrote:
> >> On 04/25/14 14:52, Glen Barber wrote:
> >>> On Fri, Apr 25, 2014 at 02:46:46PM -0700, Nathan Whitehorn wrote:
>  I appreciate the caution. Thanks for the clarification! I'm
>  planning to get EFI support into the installer this weekend.
> >>> Speaking of the installer...
> >>>
> >>> How difficult would it be to be able to select a kernel for
> >>> installation if more than one kernel.${foo}.txz is provided on the
install
> medium?
> >>>
> >>> The use case I have in mind is where kernel.VT.txz is extracted to
> >>> /boot/kernel.VT (which I believe the loader menu already supports
> >>> multi-kernel), an alternate kernel can be chosen for booting and
> >>> then can subsequently be chosen as the installed kernel during the
> >>> extract phase.
> >>>
> >>> This would actually cut down quite a bit on snapshot build times,
> >>> since right now I have to do a separate build for each kernel.
> >>>
> >>> Thoughts?
> >>>
> >>> Glen
> >>>
> >> Not that hard. If you want to just add extra optional kernels, the
> >> installer doesn't even need any patches -- you just have to add it to
> >> the make release logic (and MANIFEST) as an extra tarball. Installing
> >> it to /boot/kernel would require removing the logic in
> >> bsdinstall/scripts/auto that removes "kernel" from the menu as a
> nonoptional package.
> > Hmm, if I remember correctly, last time I booted an installer with
> > multiple kernels, there were no options for the kernel in the
> > distribution menu.  Or do you mean that if it were marked as optional,
> > they would appear?
> >
> > Anyway, the release logic already supports 'KERNCONF="GENERIC VT"'
> > listing of multiple kernels, so that is not an issue.
> >
> > Thanks!
> >
> > Glen
> >
> 
> They just need to be in the MANIFEST file somehow. I guess they aren't
> being added by release(7)? All the installer does is list that file -- and
remove
> kernel.txz and base.txz by hand.

So where sysinstall last we left it supported only two optional
distributions,
the kernel-debug distribution and "local" distribution, bsdinstall supports
as many as you stuff into the manifest.
-- 
Devin

_
The information contained in this message is proprietary and/or confidential. 
If you are not the intended recipient, please: (i) delete the message and all 
copies; (ii) do not disclose, distribute or use the message in any manner; and 
(iii) notify the sender immediately. In addition, please be aware that any 
message addressed to our domain is subject to archiving and review by persons 
other than the intended recipient. Thank you.
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

RE: svn commit: r266553 - head/release/scripts

2014-05-26 Thread dteske 


> -Original Message-
> From: owner-src-committ...@freebsd.org [mailto:owner-src-
> committ...@freebsd.org] On Behalf Of Nathan Whitehorn
> Sent: Monday, May 26, 2014 7:40 AM
> To: Tijl Coosemans; Warner Losh
> Cc: Ian Lepore; Baptiste Daroussin; svn-src-head@freebsd.org; Glen Barber;
> svn-src-...@freebsd.org; src-committ...@freebsd.org
> Subject: Re: svn commit: r266553 - head/release/scripts
> 
> On 05/26/14 02:35, Tijl Coosemans wrote:
> > On Sat, 24 May 2014 19:00:18 -0600 Warner Losh wrote:
> >> On May 24, 2014, at 5:53 PM, Warner Losh  wrote:
> >>> On May 24, 2014, at 5:13 PM, Tijl Coosemans  wrote:
>  There isn't necessarily any chroot environment.  There's one
>  kernel, two equally valid ABIs (ILP32 and LP64) and any binary like
>  uname might use either of them.  If uname -p returns a different
>  result depending on which of these two ABIs it was compiled for
>  that could be a problem for any script that uses it.
> >>> Well, it depends on what you want to do with the script, eh? If you
> >>> want to know the ABI of the native binary uname, that?s one thing.
> >>> But if you want to know the supported ABIs, you are doing it wrong by
> using uname.
> >>> You should be using sysctl kern.supported_abi. That will tell you
> >>> all the ABIs that you can install packages for on this machine,
> >>> which is what you really want to know. So I?m having trouble
> >>> connecting the dots between this and what you are saying here.
> >>>
> >>> I still am absolutely flabbergasted why the MACHINE_ARCH names
> >>> aren?t necessary and sufficient for packaging. I?ve yet to see any
> >>> coherent reason to not use them.
> >> Why do I care that they match? Good question. When I was doing
> >> FreeNAS, I looked at integrating pkgng into nanobsd. At the time this
> >> was quite difficult because every single architecture name was
> >> different between pkgng and MACHINE_ARCH.  This would mean I?d have
> >> to drag around a huge table to know how to translate one to the other
> >> (there was no simple regex either, and things like mipsn32 wouldn?t
> >> have fit into the scheme at the time). I would very much like us to
> >> see us keep these names in sync and avoid large translation tables that
> are difficult to maintain.
> >>
> >> Now, do you need to get it from uname -p? No. If you want to parse
> >> elf files to get it, that?s fine, so long as the names map directly
> >> to the MACHINE_ARCH names that we?ve been using for years. They
> >> completely describe the universe of supported platforms. Are they
> >> perfect? No, around the edge there may be an odd-ball that?s possible
> >> to build, but is unsupported and likely doesn?t work at all. Have we
> >> learned from these mistakes? Yes. Anything that?s actively supported
> >> has a proper name. This name is needed, btw, so that any machine can
> >> self-host, a nice feature of the /usr/src system.
> > ABI consists of the following elements:
> >
> > - OS
> > - OS ABI version (major version number in FreeBSD)
> > - instruction set
> > - programming model (ILP32 or LP64)
> > - byte order (little/big endian)
> >
> > These are almost orthogonal dimensions in the sense that almost any
> > combination is possible.  (A combination that isn't possible is a
> > 32-bit instruction set with LP64.)
> >
> > What you are asking for now is to combine two dimensions into one and
> > combination in this case means multiplication so if you have 3
> > instruction sets and 2 programming models, the combined dimension
> > needs
> > 6 different values.  You need to make the case for why you think this
> > is a good idea.  For the past 20 years we got away with this because
> > on every installation of FreeBSD we only used one programming model at
> > a time.  This is still the case for byte order of course.
> >
> > What I'm saying is to keep the option open for installations with
> > multiple programming models, where most binaries could use ILP32 and
> > only the ones that actually need a 64-bit address space use LP64.
> > You query the instruction set using uname and the programming models
> > using getconf.
> >
> > I suppose you could replace the "x86" in the pkg scheme with
> > i386/amd64, but then you'd still be talking about i386:32, amd64:32
> > and amd64:64 instead of x86:32, x86:x32 and x86:64.
> >
> 
> No. We support multiple "models" now and have for ten years. That's what
> MACHINE_ARCH is for: it defines the choice of the last three things you
list
> above. Specifically, a shared value of MACHINE_ARCH guarantees and OS
> version guarantees, in FreeBSD-land, complete binary compatibility of
> executables. Kernels support multiple ones, in general (e.g. i386 binaries
on
> amd64, powerpc binaries on powerpc64). They may support more in the
> future (x32 on amd64, potentially even cross-endian binaries). We have a
> nice flexible scheme in FreeBSD for supporting this. If you want to find
out
> the list of the things the installed kernel can run,

RE: svn commit: r272393 - head/etc

2014-10-01 Thread dteske 


> -Original Message-
> From: owner-src-committ...@freebsd.org [mailto:owner-src-
> committ...@freebsd.org] On Behalf Of Hiroki Sato
> Sent: Wednesday, October 1, 2014 8:38 PM
> To: cperc...@freebsd.org
> Cc: src-committ...@freebsd.org; svn-src-...@freebsd.org; svn-src-
> h...@freebsd.org
> Subject: Re: svn commit: r272393 - head/etc
> 
> Colin Percival  wrote
>   in <542caabb.5090...@freebsd.org>:
> 
> cp> On 10/01/14 18:16, Hiroki Sato wrote:
> cp> >   This is an attempt to solve a problem that rc.d scripts from
third-party
> cp> >   software do not have entries in /etc/defaults/rc.conf.
> cp>
> cp> Isn't this why we have the
> cp> > : ${foo_enable="NO"}
> cp> idiom in ports rc.d files?
> cp>
> cp> >   The fact that
> cp> >   load_rc_config() reads rc.conf only once and /etc/rc invokes the
> function
> cp> >   before running rc.d scripts made developers confused for a long
time
> because
> cp> >   load_rc_config() just before run_rc_command() in each rc.d script
> overrides
> cp> >   variables only when the script is directly invoked, not from
/etc/rc.
> cp>
> cp> If a script is setting variables for its own use, there's no need to
use
> cp> functions from rc.subr -- it can just set the variables directly.  If
a
> cp> script is editing rc.conf, sending a SIGALRM to $$ will signal /etc/rc
to
> cp> re-source rc.conf.
> cp>
> cp> I'm really not clear on what this commit accomplishes.
> 
>  The primary purpose is to make it clear which variables are used in
>  the script for *user configuration* and provide a consistent writing
>  style for scripts from both base and ports.  More specifically, I
>  want to implement a way to list user-configurable variables and which
>  one is changed from the default value, by effectively replacing
>  functionality of defaults/rc.conf with set_rcvar().
> 
>  Use of : ${foo="NO"} idiom after load_rc_config() works as you
>  pointed out.  However, it does not work with listing variables.
>  Plus, there are many scripts written in an inconsistent way.  Some
>  scripts call load_rc_config() multiple times, some have the idioms
>  between load_rc_config() and run_rc_command(), and some have them
>  mistakenly before load_rc_config().  I think this is due to confusion
>  about how load_rc_config() works and all of them can be
>  fixed/rewritten consistently of course, but I think gathering
>  definitions at the head of the scripts and making them being defined
>  at the end of load_rc_config() as set_rcvar_obsolete() does are more
>  intuitive.
> 

I'm going to chime in here. I'm equally befuddled because
for years (properly understanding load_rc_config()) would
just create a file under /etc/rc.conf.d/.

There's your stand-in for /etc/defaults/rc.conf right there;
a file in the little-known and even less talked-about
/etc/rc.conf.d/ directory -- where I believe you it is that
one precisely does what it is you're looking for (based on
your description).
-- 
Devin

___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

RE: svn commit: r241149 - in head/usr.sbin: . bsdconfig/share sysrc

2012-10-03 Thread dteske 


> -Original Message-
> From: Doug Barton [mailto:do...@freebsd.org]
> Sent: Wednesday, October 03, 2012 11:51 AM
> To: Devin Teske
> Cc: src-committ...@freebsd.org; svn-src-...@freebsd.org; svn-src-
> h...@freebsd.org
> Subject: Re: svn commit: r241149 - in head/usr.sbin: . bsdconfig/share sysrc
> 
> Was this discussed on freebsd-rc@ at some point, and I just missed it?

Everybody seems to suggest some other list. -arch, -rc, -hackers, -sysinstall,
etc.

With respect to -rc ... it's very much possible this was discussed there too.

I can recall bringing up the topic at least 3 times in the past 2 years (on
various lists). It was always met with the same enthusiastic "YES"

If we want to rehash this yet again one more time, let's pick a list and have
at-it one last time.
-- 
Devin

P.S. You'd be right to claim that there aren't any _recent_ discussions on
importing this code, and that's entirely because it took me a _really_ long time
to prepare the code once it was decided that we were going to import it. I spent
more than 6 months reworking the code for this purpose (import to base).

_
The information contained in this message is proprietary and/or confidential. 
If you are not the intended recipient, please: (i) delete the message and all 
copies; (ii) do not disclose, distribute or use the message in any manner; and 
(iii) notify the sender immediately. In addition, please be aware that any 
message addressed to our domain is subject to archiving and review by persons 
other than the intended recipient. Thank you.
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

RE: svn commit: r241149 - in head/usr.sbin: . bsdconfig/share sysrc

2012-10-03 Thread dteske 


> -Original Message-
> From: Jeremie Le Hen [mailto:j...@freebsd.org]
> Sent: Wednesday, October 03, 2012 9:59 AM
> To: Devin Teske
> Cc: src-committ...@freebsd.org; svn-src-...@freebsd.org; svn-src-
> h...@freebsd.org
> Subject: Re: svn commit: r241149 - in head/usr.sbin: . bsdconfig/share sysrc
> 
> Hi Devin,
> 
> On Wed, Oct 03, 2012 at 02:32:47AM +, Devin Teske wrote:
> > Author: dteske
> > Date: Wed Oct  3 02:32:47 2012
> > New Revision: 241149
> > URL: http://svn.freebsd.org/changeset/base/241149
> >
> > Log:
> >   Import sysutils/sysrc from the ports tree (current version 5.1). Importing
> >   disconnected under the WITH_BSDCONFIG flag (a good idea since this version
> of
> >   sysrc(8) indeed requires the `sysrc.subr' module installed by
bsdconfig(8)).
> >
> >   Multiple reasons sysrc should not simply continue to live in ports. The
most
> >   important being that it is tightly coupled with the base.
> >
> >   Approved by:  adrian (co-mentor)
> 
> Don't you expect to MFC this?
> 

Neither bsdconfig(8) nor sysrc(8) are actually shipping with FreeBSD _yet_, so
there's technically nothing to MFC (other than disconnected code).

Currently, at the time of this writing, you need to use WITH_BSDCONFIG when
compiling/installing the operating system from source to get this great
software.

The suggestion to import this code "disconnected" was made by both Julian and
phk based on the fact that nobody was available (after months of waiting,
searching, and pleading) to review the >20k lines of code.

Furthermore, the code should not be "connected" (taking away the need to set
WITH_BSDCONFIG to get this software) until bsdconfig(8) can function as a "full
and complete" replacement to sysinstall(8). Currently, what's missing from
bsdconfig(8) that makes it a less-than-ideal replacement for sysinstall is:

a. The lack of package management (discussions on -hackers led to the
predisposition that we should focus our efforts on embracing PKGNG)

b. help-file integration ("*.help" files used by sysinstall(8) need to be
brought over and hooked-into bsdconfig(8))

When those two tasks are done, then bsdconfig(8) will be ready to take on
active-duty as *the* replacement to sysinstall(8) -- meaning, we'll remove the
need to have WITH_BSDCONFIG declared).

At that moment, bsdconfig(8) ought to be a candidate for MFC -- but until then,
the only thing an MFC buys me is double-work maintaining two disconnected
branches instead of one.

For those that want to test bsdconfig(8) and sysrc(8) on a STABLE release, never
fear: you can simply execute the following to install these to any release (but
do note that bsdconfig(8) requires dialog(1) from 9.0 or higher):

# Assuming /usr/src holds a HEAD release
cd /usr/src/usr.sbin/bsdconfig
make all install
cd ../sysrc
make all install

Last, but not least, you may be asking what bsdconfig(8) has to do with
sysrc(8). Quite simply, sysrc(8) requires /usr/share/bsdconfig/sysrc.subr
as-provided by bsdconfig(8).
-- 
Devin

_
The information contained in this message is proprietary and/or confidential. 
If you are not the intended recipient, please: (i) delete the message and all 
copies; (ii) do not disclose, distribute or use the message in any manner; and 
(iii) notify the sender immediately. In addition, please be aware that any 
message addressed to our domain is subject to archiving and review by persons 
other than the intended recipient. Thank you.
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"