svn commit: r284377 - head/lib/libc/sys

[Jeremie Le Hen]

Author: jlh
Date: Sun Jun 14 07:47:18 2015
New Revision: 284377
URL: https://svnweb.freebsd.org/changeset/base/284377

Log:
  NetBSD commit log:
Use a constant array for the MIB. Newer LLVM decided that mib[] warranted
stack protections, with the obvious crash after the setup was done.
As a positive side effect, code size shrinks a bit.
  
  I'm not sure why this hasn't bitten us yes, but it is certainly possible and
  there are no real drawbacks to this change anyway.
  
  Submitted by: pfg
  Obtained from:NetBSD
  MFC after:1 week

Modified:
  head/lib/libc/sys/stack_protector.c

Modified: head/lib/libc/sys/stack_protector.c
==
--- head/lib/libc/sys/stack_protector.c Sun Jun 14 05:23:39 2015
(r284376)
+++ head/lib/libc/sys/stack_protector.c Sun Jun 14 07:47:18 2015
(r284377)
@@ -41,8 +41,8 @@ __FBSDID("$FreeBSD$");
 #include 
 #include "libc_private.h"
 
-extern int __sysctl(int *name, u_int namelen, void *oldp, size_t *oldlenp,
-void *newp, size_t newlen);
+extern int __sysctl(const int *name, u_int namelen, void *oldp,
+size_t *oldlenp, void *newp, size_t newlen);
 
 long __stack_chk_guard[8] = {0, 0, 0, 0, 0, 0, 0, 0};
 static void __guard_setup(void) __attribute__((__constructor__, __used__));
@@ -54,7 +54,7 @@ void __chk_fail(void);
 static void
 __guard_setup(void)
 {
-   int mib[2];
+   static const int mib[2] = { CTL_KERN, KERN_ARND };
size_t len;
int error;
 
@@ -65,12 +65,9 @@ __guard_setup(void)
if (error == 0 && __stack_chk_guard[0] != 0)
return;
 
-   mib[0] = CTL_KERN;
-   mib[1] = KERN_ARND;
-
len = sizeof(__stack_chk_guard);
-   if (__sysctl(mib, 2, __stack_chk_guard, &len, NULL, 0) == -1 ||
-   len != sizeof(__stack_chk_guard)) {
+   if (__sysctl(mib, nitems(mib), __stack_chk_guard, &len, NULL, 0) ==
+   -1 || len != sizeof(__stack_chk_guard)) {
/* If sysctl was unsuccessful, use the "terminator canary". */
((unsigned char *)(void *)__stack_chk_guard)[0] = 0;
((unsigned char *)(void *)__stack_chk_guard)[1] = 0;
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r284377 - head/lib/libc/sys

[Jeremie Le Hen]

On Sun, Jun 14, 2015 at 9:47 AM, Jeremie Le Hen  wrote:
> Author: jlh
> Date: Sun Jun 14 07:47:18 2015
> New Revision: 284377
> URL: https://svnweb.freebsd.org/changeset/base/284377
>
> Log:
>   NetBSD commit log:
> Use a constant array for the MIB. Newer LLVM decided that mib[] warranted
> stack protections, with the obvious crash after the setup was done.
> As a positive side effect, code size shrinks a bit.
>
>   I'm not sure why this hasn't bitten us yes, but it is certainly possible and
>   there are no real drawbacks to this change anyway.
>
>   Submitted by: pfg

Correction: Pedro only forwarded this to me.  The person who initially
discovered this is Oliver (cc'ed).

Sorry for that mistake!
-- 
Jeremie Le Hen
j...@freebsd.org
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r284378 - head/sys/kern

[Jeremie Le Hen]

Author: jlh
Date: Sun Jun 14 08:33:14 2015
New Revision: 284378
URL: https://svnweb.freebsd.org/changeset/base/284378

Log:
  nit: Rename racct_alloc_resource to racct_adjust_resource.
  
  This is more accurate as the amount can be negative.
  
  MFC after:2 weeks

Modified:
  head/sys/kern/kern_racct.c

Modified: head/sys/kern/kern_racct.c
==
--- head/sys/kern/kern_racct.c  Sun Jun 14 07:47:18 2015(r284377)
+++ head/sys/kern/kern_racct.c  Sun Jun 14 08:33:14 2015(r284378)
@@ -500,7 +500,7 @@ racct_destroy(struct racct **racct)
  * may be less than zero.
  */
 static void
-racct_alloc_resource(struct racct *racct, int resource,
+racct_adjust_resource(struct racct *racct, int resource,
 uint64_t amount)
 {
 
@@ -553,7 +553,7 @@ racct_add_locked(struct proc *p, int res
return (error);
}
 #endif
-   racct_alloc_resource(p->p_racct, resource, amount);
+   racct_adjust_resource(p->p_racct, resource, amount);
racct_add_cred_locked(p->p_ucred, resource, amount);
 
return (0);
@@ -587,11 +587,11 @@ racct_add_cred_locked(struct ucred *cred
SDT_PROBE(racct, kernel, rusage, add__cred, cred, resource, amount,
0, 0);
 
-   racct_alloc_resource(cred->cr_ruidinfo->ui_racct, resource, amount);
+   racct_adjust_resource(cred->cr_ruidinfo->ui_racct, resource, amount);
for (pr = cred->cr_prison; pr != NULL; pr = pr->pr_parent)
-   racct_alloc_resource(pr->pr_prison_racct->prr_racct, resource,
+   racct_adjust_resource(pr->pr_prison_racct->prr_racct, resource,
amount);
-   racct_alloc_resource(cred->cr_loginclass->lc_racct, resource, amount);
+   racct_adjust_resource(cred->cr_loginclass->lc_racct, resource, amount);
 }
 
 /*
@@ -631,7 +631,7 @@ racct_add_force(struct proc *p, int reso
PROC_LOCK_ASSERT(p, MA_OWNED);
 
mtx_lock(&racct_lock);
-   racct_alloc_resource(p->p_racct, resource, amount);
+   racct_adjust_resource(p->p_racct, resource, amount);
mtx_unlock(&racct_lock);
racct_add_cred(p->p_ucred, resource, amount);
 }
@@ -685,7 +685,7 @@ racct_set_locked(struct proc *p, int res
}
}
 #endif
-   racct_alloc_resource(p->p_racct, resource, diff_proc);
+   racct_adjust_resource(p->p_racct, resource, diff_proc);
if (diff_cred > 0)
racct_add_cred_locked(p->p_ucred, resource, diff_cred);
else if (diff_cred < 0)
@@ -747,7 +747,7 @@ racct_set_force_locked(struct proc *p, i
} else
diff_cred = diff_proc;
 
-   racct_alloc_resource(p->p_racct, resource, diff_proc);
+   racct_adjust_resource(p->p_racct, resource, diff_proc);
if (diff_cred > 0)
racct_add_cred_locked(p->p_ucred, resource, diff_cred);
else if (diff_cred < 0)
@@ -849,7 +849,7 @@ racct_sub(struct proc *p, int resource, 
 "than allocated %jd for %s (pid %d)", __func__, amount, resource,
(intmax_t)p->p_racct->r_resources[resource], p->p_comm, p->p_pid));
 
-   racct_alloc_resource(p->p_racct, resource, -amount);
+   racct_adjust_resource(p->p_racct, resource, -amount);
racct_sub_cred_locked(p->p_ucred, resource, amount);
mtx_unlock(&racct_lock);
 }
@@ -870,11 +870,11 @@ racct_sub_cred_locked(struct ucred *cred
 resource));
 #endif
 
-   racct_alloc_resource(cred->cr_ruidinfo->ui_racct, resource, -amount);
+   racct_adjust_resource(cred->cr_ruidinfo->ui_racct, resource, -amount);
for (pr = cred->cr_prison; pr != NULL; pr = pr->pr_parent)
-   racct_alloc_resource(pr->pr_prison_racct->prr_racct, resource,
+   racct_adjust_resource(pr->pr_prison_racct->prr_racct, resource,
-amount);
-   racct_alloc_resource(cred->cr_loginclass->lc_racct, resource, -amount);
+   racct_adjust_resource(cred->cr_loginclass->lc_racct, resource, -amount);
 }
 
 /*
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r284356 - head/usr.sbin/crunch/crunchgen

[Tijl Coosemans]

On Sat, 13 Jun 2015 22:01:21 + (UTC) Adrian Chadd  
wrote:
> Author: adrian
> Date: Sat Jun 13 22:01:21 2015
> New Revision: 284356
> URL: https://svnweb.freebsd.org/changeset/base/284356
> 
> Log:
>   Fix up crunchgen binary generation to work with external cross-build
>   tools.
>   
>   * Allow STRIP to be overridden by the environment
>   * Use CC to tie things together, not LD
>   
>   Tested:
>   
>   * i386, mips32
>   
>   Submitted by:   kan
> 
> Modified:
>   head/usr.sbin/crunch/crunchgen/crunchgen.c
> 
> Modified: head/usr.sbin/crunch/crunchgen/crunchgen.c
> ==
> --- head/usr.sbin/crunch/crunchgen/crunchgen.cSat Jun 13 20:15:44 
> 2015(r284355)
> +++ head/usr.sbin/crunch/crunchgen/crunchgen.cSat Jun 13 22:01:21 
> 2015(r284356)
> @@ -980,6 +980,7 @@ top_makefile_rules(FILE *outmk)
>   prog_t *p;
>  
>   fprintf(outmk, "LD?= ld\n");
> + fprintf(outmk, "STRIP?= strip\n");
>   if ( subtract_strlst(&libs, &libs_so) )
>   fprintf(outmk, "# NOTE: Some LIBS declarations below overridden 
> by LIBS_SO\n");
>  
> @@ -1027,7 +1028,7 @@ top_makefile_rules(FILE *outmk)
>   fprintf(outmk, "\t$(CC) -static -o %s %s.o $(CRUNCHED_OBJS) $(LIBS)\n",
>   execfname, execfname);
>   fprintf(outmk, ".endif\n");
> - fprintf(outmk, "\tstrip %s\n", execfname);
> + fprintf(outmk, "\t$(STRIP) %s\n", execfname);
>   fprintf(outmk, "realclean: clean subclean\n");
>   fprintf(outmk, "clean:\n\trm -f %s *.lo *.o *_stub.c\n", execfname);
>   fprintf(outmk, "subclean: $(SUBCLEAN_TARGETS)\n");
> @@ -1109,7 +1110,7 @@ prog_makefile_rules(FILE *outmk, prog_t 
>   fprintf(outmk, " $(%s_LIBS)", p->ident);
>  
>   fprintf(outmk, "\n");
> - fprintf(outmk, "\t$(LD) -dc -r -o %s.lo %s_stub.o $(%s_OBJPATHS)",
> + fprintf(outmk, "\t$(CC) -nostdlibs -dc -r -o %s.lo %s_stub.o 
> $(%s_OBJPATHS)",

Does CC understand -dc and -r?
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r284198 - head/bin/ls

[Slawa Olhovchenkov]

On Sat, Jun 13, 2015 at 05:13:31PM -0700, Craig Rodrigues wrote:

> The people I talk to use scripting languages like Python or Ruby,
> and devops frameworks like Ansible, Saltstack, Puppet, and Chef.
> They may do some quick prototyping and UI work with Javascript and HTML/CSS.
> Being able to generate JSON directly from system-level tools,
> and then analyze that in a Python script,

You need JSON from system-level tools for analyze that in a Python
script? Realy? Not plain text? or tab/space separated?
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r284198 - head/bin/ls

[Garrett Cooper]

On Jun 14, 2015, at 3:00, Slawa Olhovchenkov  wrote:

> On Sat, Jun 13, 2015 at 05:13:31PM -0700, Craig Rodrigues wrote:
> 
>> The people I talk to use scripting languages like Python or Ruby,
>> and devops frameworks like Ansible, Saltstack, Puppet, and Chef.
>> They may do some quick prototyping and UI work with Javascript and HTML/CSS.
>> Being able to generate JSON directly from system-level tools,
>> and then analyze that in a Python script,
> 
> You need JSON from system-level tools for analyze that in a Python
> script? Realy? Not plain text? or tab/space separated?

Having written a bunch of tools that parse plaintext, it’s a pain in the rear. 
It’s far easier to have JSON and a schema for working with that JSON when 
developing tools to parse things out.

Programmers are inherently lazy — the more we have to make them work, the more 
pushback we’re going to get from them as far as integrating FreeBSD’s concerned.

Thanks!


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: svn commit: r284198 - head/bin/ls

[Bruce Simpson]

On 14/06/2015 11:00, Slawa Olhovchenkov wrote:

On Sat, Jun 13, 2015 at 05:13:31PM -0700, Craig Rodrigues wrote:


The people I talk to use scripting languages like Python or Ruby,
and devops frameworks like Ansible, Saltstack, Puppet, and Chef.
They may do some quick prototyping and UI work with Javascript and HTML/CSS.
Being able to generate JSON directly from system-level tools,
and then analyze that in a Python script,


You need JSON from system-level tools for analyze that in a Python
script? Realy? Not plain text? or tab/space separated?



So, I am broadly in favour of keeping libxo -- providing the problems 
with its introduction are fixed.


I'm not even thinking of the "DevOps" space, but the R&D space, where 
Python and R are king.


Man pages are small beer and can be dealt with easily.

Control flow and regressions from previous functionality are another 
issue, and I am not for a moment going to duck out and suggest those 
responsible for introducing it aren't also responsible for fixing these 
specific issues.


But I have yet to see a coherent argument here -- size(1) numbers, RSS 
figures etc. -- about how it allegedly adds bloat. Most of what I've 
seen so far is POLA, NIH resistance, and hand-wavery.


If anything it helps to future proof the code as it stands, and make it 
easier for us to actually engineer the system for performance.


I tend to look upon counter-arguments against that last point as "The 
more we obfuscate, the harder it is to get found out that the code isn't 
actually that good."


So, if you read my previous response to this thread, I've clearly 
pointed out that: there are specific problems in parsing the output of 
these system tools as they stand.


If you don't believe this, you can have my yesterday morning/afternoon, 
where I was post-processing the output of 4000 individual "vmstat -z" 
and "vmstat -m" reports.


Another 1000 this morning, with more to follow. "Oh boy," I'd say to 
myself, "I wish I had libxo!"


This argument is not limited to base system utilities. For example: 
iperf 3.x has had a similar reworking of its reporting format to include 
JSON.


This is a massive improvement over iperf 2.x, which does not even 
clearly document its CSV fields; you have to read the source for that. 
JSON actually tags each field.


This reduces the time from experiment to analysed result significantly, 
just because I can easily see what each god damned number means.


Given, you need to read the source to understand why its naive 
sequencing algorithm breaks in multipath networking scenarios, but one 
should not have to do this just to get basic throughput results tabulated.


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

Re: svn commit: r284343 - in stable: 10/sys/kern 10/sys/sys 9/sys/kern 9/sys/sys

[Oliver Pinter]

On Sat, Jun 13, 2015 at 6:15 PM, John Baldwin  wrote:
> Author: jhb
> Date: Sat Jun 13 16:15:43 2015
> New Revision: 284343
> URL: https://svnweb.freebsd.org/changeset/base/284343
>
> Log:
>   MFC 283546:
>   Add KTR tracing for some MI ptrace events.
>
> Modified:
>   stable/10/sys/kern/kern_exit.c
>   stable/10/sys/kern/kern_fork.c
>   stable/10/sys/kern/kern_sig.c
>   stable/10/sys/kern/sys_process.c
>   stable/10/sys/sys/ktr.h
> Directory Properties:
>   stable/10/   (props changed)
>
> Changes in other areas also in this revision:
> Modified:
>   stable/9/sys/kern/kern_exit.c
>   stable/9/sys/kern/kern_fork.c
>   stable/9/sys/kern/kern_sig.c
>   stable/9/sys/kern/sys_process.c
>   stable/9/sys/sys/ktr.h
> Directory Properties:
>   stable/9/sys/   (props changed)
>   stable/9/sys/sys/   (props changed)
>
> Modified: stable/10/sys/kern/kern_exit.c
> ==
> --- stable/10/sys/kern/kern_exit.c  Sat Jun 13 16:13:31 2015
> (r284342)
> +++ stable/10/sys/kern/kern_exit.c  Sat Jun 13 16:15:43 2015
> (r284343)
> @@ -531,6 +531,8 @@ exit1(struct thread *td, int rv)
>  */
> while ((q = LIST_FIRST(&p->p_orphans)) != NULL) {
> PROC_LOCK(q);
> +   CTR2(KTR_PTRACE, "exit: pid %d, clearing orphan %d", p->p_pid,
> +   q->p_pid);
> clear_orphan(q);
> PROC_UNLOCK(q);
> }
> @@ -865,6 +867,9 @@ proc_reap(struct thread *td, struct proc
> t = proc_realparent(p);
> PROC_LOCK(t);
> PROC_LOCK(p);
> +   CTR2(KTR_PTRACE,
> +   "wait: traced child %d moved back to parent %d", p->p_pid,
> +   t->p_pid);
> proc_reparent(p, t);
> p->p_oppid = 0;
> PROC_UNLOCK(p);
> @@ -1219,6 +1224,10 @@ loop:
> PROC_UNLOCK(q);
> }
>
> +   CTR4(KTR_PTRACE,
> +   "wait: returning trapped pid %d status %#x (xstat %d) xthread %d",
> +   p->p_pid, W_STOPCODE(p->p_xstat), p->p_xstat,
> +   p->p_xthread != NULL ? p->p_xthread->td_tid : -1);
> PROC_UNLOCK(p);
> return (0);
> }
>
> Modified: stable/10/sys/kern/kern_fork.c
> ==
> --- stable/10/sys/kern/kern_fork.c  Sat Jun 13 16:13:31 2015
> (r284342)
> +++ stable/10/sys/kern/kern_fork.c  Sat Jun 13 16:15:43 2015
> (r284343)
> @@ -1056,6 +1056,9 @@ fork_return(struct thread *td, struct tr
> dbg = p->p_pptr->p_pptr;
> p->p_flag |= P_TRACED;
> p->p_oppid = p->p_pptr->p_pid;
> +   CTR2(KTR_PTRACE,
> +   "fork_return: attaching to new child pid %d: oppid %d",
> +   p->p_pid, p->p_oppid);
> proc_reparent(p, dbg);
> sx_xunlock(&proctree_lock);
> td->td_dbgflags |= TDB_CHILD;
>
> Modified: stable/10/sys/kern/kern_sig.c
> ==
> --- stable/10/sys/kern/kern_sig.c   Sat Jun 13 16:13:31 2015
> (r284342)
> +++ stable/10/sys/kern/kern_sig.c   Sat Jun 13 16:15:43 2015
> (r284343)
> @@ -2484,6 +2484,8 @@ ptracestop(struct thread *td, int sig)
>
> td->td_dbgflags |= TDB_XSIG;
> td->td_xsig = sig;
> +   CTR4(KTR_PTRACE, "ptracestop: tid %d (pid %d) flags %#x sig %d",
> +   td->td_tid, p->p_pid, td->td_dbgflags, sig);
> PROC_SLOCK(p);
> while ((p->p_flag & P_TRACED) && (td->td_dbgflags & TDB_XSIG)) {
> if (p->p_flag & P_SINGLE_EXIT) {
>
> Modified: stable/10/sys/kern/sys_process.c
> ==
> --- stable/10/sys/kern/sys_process.cSat Jun 13 16:13:31 2015
> (r284342)
> +++ stable/10/sys/kern/sys_process.cSat Jun 13 16:15:43 2015
> (r284343)
> @@ -432,6 +432,9 @@ ptrace_vm_entry(struct thread *td, struc
> free(freepath, M_TEMP);
> }
> }
> +   if (error == 0)
> +   CTR3(KTR_PTRACE, "PT_VM_ENTRY: pid %d, entry %d, start %p",
> +   p->p_pid, pve->pve_entry, pve->pve_start);
>
> return (error);
>  }
> @@ -826,6 +829,7 @@ kern_ptrace(struct thread *td, int req,
> if (p->p_flag & P_PPWAIT)
> p->p_flag |= P_PPTRACE;
> p->p_oppid = p->p_pptr->p_pid;
> +   CTR1(KTR_PTRACE, "PT_TRACE_ME: pid %d", p->p_pid);
> break;
>
> case PT_ATTACH:
> @@ -845,17 +849,25 @@ kern_ptrace(struct thread *t

Re: svn commit: r284198 - head/bin/ls

[Slawa Olhovchenkov]

On Sun, Jun 14, 2015 at 11:22:03AM +0100, Bruce Simpson wrote:

> On 14/06/2015 11:00, Slawa Olhovchenkov wrote:
> > On Sat, Jun 13, 2015 at 05:13:31PM -0700, Craig Rodrigues wrote:
> >
> >> The people I talk to use scripting languages like Python or Ruby,
> >> and devops frameworks like Ansible, Saltstack, Puppet, and Chef.
> >> They may do some quick prototyping and UI work with Javascript and 
> >> HTML/CSS.
> >> Being able to generate JSON directly from system-level tools,
> >> and then analyze that in a Python script,
> >
> > You need JSON from system-level tools for analyze that in a Python
> > script? Realy? Not plain text? or tab/space separated?
> >
> 
> So, I am broadly in favour of keeping libxo -- providing the problems 
> with its introduction are fixed.
> 
> I'm not even thinking of the "DevOps" space, but the R&D space, where 
> Python and R are king.
> 
> Man pages are small beer and can be dealt with easily.
> 
> Control flow and regressions from previous functionality are another 
> issue, and I am not for a moment going to duck out and suggest those 
> responsible for introducing it aren't also responsible for fixing these 
> specific issues.
> 
> But I have yet to see a coherent argument here -- size(1) numbers, RSS 
> figures etc. -- about how it allegedly adds bloat. Most of what I've 
> seen so far is POLA, NIH resistance, and hand-wavery.
> 
> If anything it helps to future proof the code as it stands, and make it 
> easier for us to actually engineer the system for performance.
> 
> I tend to look upon counter-arguments against that last point as "The 
> more we obfuscate, the harder it is to get found out that the code isn't 
> actually that good."
> 
> So, if you read my previous response to this thread, I've clearly 
> pointed out that: there are specific problems in parsing the output of 
> these system tools as they stand.
> 
> If you don't believe this, you can have my yesterday morning/afternoon, 
> where I was post-processing the output of 4000 individual "vmstat -z" 
> and "vmstat -m" reports.
> 
> Another 1000 this morning, with more to follow. "Oh boy," I'd say to 
> myself, "I wish I had libxo!"
> 
> This argument is not limited to base system utilities. For example: 
> iperf 3.x has had a similar reworking of its reporting format to include 
> JSON.
> 
> This is a massive improvement over iperf 2.x, which does not even 
> clearly document its CSV fields; you have to read the source for that. 
> JSON actually tags each field.
> 
> This reduces the time from experiment to analysed result significantly, 
> just because I can easily see what each god damned number means.
> 
> Given, you need to read the source to understand why its naive 
> sequencing algorithm breaks in multipath networking scenarios, but one 
> should not have to do this just to get basic throughput results tabulated.

Post-processing massive outputs and individual outputs is different
task. Anoder one -- one-line scripts. I am don't like some aspects of
ls/find outputs (for example -- date/time format changed depends of
age). Some utilites already have key for script-processing (zfs -H,
for example). I am don't see how libxo integrated to ls, but I see
that in other utilites format changed options don't tigh integrated:

 # zpool list -v 
NAME  SIZE  ALLOC   FREE  EXPANDSZ   FRAGCAP  DEDUP  HEALTH  ALTROOT
tank 46.2T  37.3M  46.2T - 0% 0%  1.00x  ONLINE  -
  mirror 2.72T  2.15M  2.72T - 0% 0%
da2  -  -  - -  -  -
da0  -  -  - -  -  -

 # zpool list -v -p
NAME  SIZE  ALLOC   FREE  EXPANDSZ   FRAGCAP  DEDUP  HEALTH  ALTROOT
tank 50818053046272  39088128  50818013958144 - 0%  0  
1.00x  ONLINE  -
  mirror 2.72T  2.15M  2.72T - 0% 0%
da2  -  -  - -  -  -
da0  -  -  - -  -  -

only 'total' format changed, not components.

And this is more complex problem for scripting/automating that JSON/plaint text.

Also, I am don't like pyton. I am use perl. For JSON parsing I am need 
additional modules.
I am can't easy use JSON output in one-lines shell pipes -- system utilites 
(like sort, awk, cut
and etc.) don't understand and parsed JSON. But understand tab/space/null 
separated stream.

vmstat have slight different problem -- no easy filtering.
gstat can't output in file/stream in looped mode.

All this problems don't resolved by JSON output.

I am don't talk about need or don't need libxo, good or bad code in libxo.
I am just about needing json output for system utilites.

I am see tons of utilites. Some utiltes born in FreeBSD. Some born in relative 
projects
(NetBSD, OpenBSD). Some GNU. And etc. Who do JSONification all of this? Who 
ported to libxo ZFS
utilites? clang oputput?
Or some utilites will be JSON, some -- not?
As I see, JSON output good only for Ans

Re: svn commit: r284198 - head/bin/ls

[Garrett Cooper]

On Jun 13, 2015, at 23:09, Steve Kargl  
wrote:

> On Sat, Jun 13, 2015 at 06:45:57PM -0700, Craig Rodrigues wrote:
>> On Sat, Jun 13, 2015 at 6:29 PM, Steve Kargl <
>> s...@troutmask.apl.washington.edu> wrote:
>> 
 
 Are you talking about this comment you made?
 
>>> https://lists.freebsd.org/pipermail/freebsd-current/2015-March/054899.html
 
 I can't make heads or tails of what you wrote, other than you seemed very
 angry.
 
>>> 
>>> I wasn't very angry.
>> 
>> It's hard for me to tell, really, since you submitted patches
>> with FUBAR in them, so you seemed pretty angry in that e-mail.
>> 
> 
> FUBAR is as good as what is already there.  Simply drawing
> attention to the people responsible for libxo's inclusion
> in FreeBSD that they need to fix it.

I see the benefit in libxo, but I see the argument in it being unnecessary 
bloat as well.

>>> Do you really believe that the Nd entries for these manpages are
>>> correct?
>>> 
>> 
>> I'm not an expert on the mdoc format, so I couldn't tell you.
>> If you can think of some patches to fix things, in the man pages,
>> would you be able to submit the patches to Phil, and have them incorporated
>> into the software to make it better?
> 
> There isn't a public mailing list or other mechanism to
> submit a patch.  One needs to sign up for an account.
> I have way too many accounts on way too many systems
> to sign up for a new account to send in a single patch.

Github is rather straightforward, but yes.. the workflow’s a bit different:
1. Fork project.
2. Create a branch for a “topic” (i.e. fix/enhance X).
3. Open a pull request (which will open an issue).

>> libxo is maintained at https://github.com/Juniper/libxo .
>> 
>> I don't know if you are willing/able to submit patches to the libxo project
>> on Github,
>> to help fix things.  That would be great if you could do that and help out.
> 
> It seems that libxo developers have no interest in FreeBSD documentation.

Not entirely true. They’re willing to work on the versioning problem I noted in 
the above issue.

> https://github.com/Juniper/libxo/issues/13
> 
> Those that imported/maintain libxo within FreeBSD should fix the
> documentation.

The problem was with the manpage to github link referencing -- which can 
change. FWIW I’m happy they have documentation, unlike our current defacto 
toolchain in FreeBSD (man clang makes me sad… I keep gcc installed just so I 
can refer to something halfway decent):

 -O0 Means "no optimization": this level compiles the fastest
 and generates the most debuggable code.

 -O1 Somewhere between -O0 and -O2.

 -O2 Moderate level of optimization which enables most
 optimizations.

Really clang? I didn’t realize that 1 was between 0 and 2...

Thanks.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: svn commit: r284343 - in stable: 10/sys/kern 10/sys/sys 9/sys/kern 9/sys/sys

[John Baldwin]

On 6/14/15 6:39 AM, Oliver Pinter wrote:
> On Sat, Jun 13, 2015 at 6:15 PM, John Baldwin  wrote:
> 
> Hi John!
> 
> Could you please MFC this commit too:
> 
> commit 4331ca7813ee01d1745c6ff2ced7030329586b30
> Author: jhb 
> Date:   Fri May 22 11:09:41 2015 +
> 
> Expand ktr_mask to be a 64-bit unsigned integer.
> 
> The mask does not really need to be updated with atomic operations and
> the downside of losing races during transitions is not great (it is
> not marked volatile, so those races are pretty wide open as it is).
> 
> Differential Revision:  https://reviews.freebsd.org/D2595
> Reviewed by:emaste, neel, rpaulo
> MFC after:  2 weeks

Hmm, I might not get too it in the near future.  The only reason I've
hesitated to do so is that it does slightly break the in-kernel ABI in
that 'ktr_mask' is a public symbol to kernel modules.  (I've used it in
various hackish tests where I would clear ktr_mask to 0 when some unusual
event happened so that the KTR trace buffer contained the events leading
up to the unusual event.)  OTOH, this is a bit of a special case, so I'm
not sure if this is part of the ABI that we really have to worry about.

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

svn commit: r284380 - in head/sys: kern sys

[Mateusz Guzik]

Author: mjg
Date: Sun Jun 14 14:08:52 2015
New Revision: 284380
URL: https://svnweb.freebsd.org/changeset/base/284380

Log:
  fd: move out actual fp installation to _finstall
  
  Use it in fd passing functions as the first step towards fd code cleanup.

Modified:
  head/sys/kern/kern_descrip.c
  head/sys/kern/uipc_usrreq.c
  head/sys/sys/filedesc.h

Modified: head/sys/kern/kern_descrip.c
==
--- head/sys/kern/kern_descrip.cSun Jun 14 11:08:27 2015
(r284379)
+++ head/sys/kern/kern_descrip.cSun Jun 14 14:08:52 2015
(r284380)
@@ -1750,26 +1750,18 @@ falloc_noinstall(struct thread *td, stru
 /*
  * Install a file in a file descriptor table.
  */
-int
-finstall(struct thread *td, struct file *fp, int *fd, int flags,
+void
+_finstall(struct filedesc *fdp, struct file *fp, int fd, int flags,
 struct filecaps *fcaps)
 {
-   struct filedesc *fdp = td->td_proc->p_fd;
struct filedescent *fde;
-   int error;
 
-   KASSERT(fd != NULL, ("%s: fd == NULL", __func__));
-   KASSERT(fp != NULL, ("%s: fp == NULL", __func__));
+   MPASS(fp != NULL);
if (fcaps != NULL)
filecaps_validate(fcaps, __func__);
+   FILEDESC_XLOCK_ASSERT(fdp);
 
-   FILEDESC_XLOCK(fdp);
-   if ((error = fdalloc(td, 0, fd))) {
-   FILEDESC_XUNLOCK(fdp);
-   return (error);
-   }
-   fhold(fp);
-   fde = &fdp->fd_ofiles[*fd];
+   fde = &fdp->fd_ofiles[fd];
 #ifdef CAPABILITIES
seq_write_begin(&fde->fde_seq);
 #endif
@@ -1783,6 +1775,24 @@ finstall(struct thread *td, struct file 
 #ifdef CAPABILITIES
seq_write_end(&fde->fde_seq);
 #endif
+}
+
+int
+finstall(struct thread *td, struct file *fp, int *fd, int flags,
+struct filecaps *fcaps)
+{
+   struct filedesc *fdp = td->td_proc->p_fd;
+   int error;
+
+   MPASS(fd != NULL);
+
+   FILEDESC_XLOCK(fdp);
+   if ((error = fdalloc(td, 0, fd))) {
+   FILEDESC_XUNLOCK(fdp);
+   return (error);
+   }
+   fhold(fp);
+   _finstall(fdp, fp, *fd, flags, fcaps);
FILEDESC_XUNLOCK(fdp);
return (0);
 }

Modified: head/sys/kern/uipc_usrreq.c
==
--- head/sys/kern/uipc_usrreq.c Sun Jun 14 11:08:27 2015(r284379)
+++ head/sys/kern/uipc_usrreq.c Sun Jun 14 14:08:52 2015(r284380)
@@ -1736,7 +1736,7 @@ unp_externalize(struct mbuf *control, st
int i;
int *fdp;
struct filedesc *fdesc = td->td_proc->p_fd;
-   struct filedescent *fde, **fdep;
+   struct filedescent **fdep;
void *data;
socklen_t clen = control->m_len, datalen;
int error, newfds;
@@ -1795,13 +1795,10 @@ unp_externalize(struct mbuf *control, st
goto next;
}
for (i = 0; i < newfds; i++, fdp++) {
-   fde = &fdesc->fd_ofiles[*fdp];
-   fde->fde_file = fdep[i]->fde_file;
-   filecaps_move(&fdep[i]->fde_caps,
-   &fde->fde_caps);
-   if ((flags & MSG_CMSG_CLOEXEC) != 0)
-   fde->fde_flags |= UF_EXCLOSE;
-   unp_externalize_fp(fde->fde_file);
+   _finstall(fdesc, fdep[i]->fde_file, *fdp,
+   (flags & MSG_CMSG_CLOEXEC) != 0 ? 
UF_EXCLOSE : 0,
+   &fdep[i]->fde_caps);
+   unp_externalize_fp(fdep[i]->fde_file);
}
FILEDESC_XUNLOCK(fdesc);
free(fdep[0], M_FILECAPS);

Modified: head/sys/sys/filedesc.h
==
--- head/sys/sys/filedesc.h Sun Jun 14 11:08:27 2015(r284379)
+++ head/sys/sys/filedesc.h Sun Jun 14 14:08:52 2015(r284380)
@@ -147,7 +147,9 @@ int dupfdopen(struct thread *td, struct 
 intfalloc(struct thread *td, struct file **resultfp, int *resultfd,
int flags);
 intfalloc_noinstall(struct thread *td, struct file **resultfp);
-intfinstall(struct thread *td, struct file *fp, int *resultfp, int flags,
+void   _finstall(struct filedesc *fdp, struct file *fp, int fd, int flags,
+   struct filecaps *fcaps);
+intfinstall(struct thread *td, struct file *fp, int *resultfd, int flags,
struct filecaps *fcaps);
 intfdalloc(struct thread *td, int minfd, int *result);
 intfdallocn(struct thread *td, int minfd, int *fds, int n);
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...

svn commit: r284381 - head/sys/kern

[Mateusz Guzik]

Author: mjg
Date: Sun Jun 14 14:10:05 2015
New Revision: 284381
URL: https://svnweb.freebsd.org/changeset/base/284381

Log:
  fd: reduce excessive zeroing on fd close
  
  fde_file as NULL is already an indicator of an unused fd. All other
  fields are populated when fp is installed.

Modified:
  head/sys/kern/kern_descrip.c

Modified: head/sys/kern/kern_descrip.c
==
--- head/sys/kern/kern_descrip.cSun Jun 14 14:08:52 2015
(r284380)
+++ head/sys/kern/kern_descrip.cSun Jun 14 14:10:05 2015
(r284381)
@@ -309,7 +309,7 @@ fdfree(struct filedesc *fdp, int fd)
seq_write_begin(&fde->fde_seq);
 #endif
fdefree_last(fde);
-   bzero(fde, fde_change_size);
+   fde->fde_file = NULL;
fdunused(fdp, fd);
 #ifdef CAPABILITIES
seq_write_end(&fde->fde_seq);
@@ -1651,7 +1651,6 @@ fdalloc(struct thread *td, int minfd, in
("fd_first_free() returned non-free descriptor"));
KASSERT(fdp->fd_ofiles[fd].fde_file == NULL,
("file descriptor isn't free"));
-   KASSERT(fdp->fd_ofiles[fd].fde_flags == 0, ("file flags are set"));
fdused(fdp, fd);
*result = fd;
return (0);
@@ -1766,8 +1765,7 @@ _finstall(struct filedesc *fdp, struct f
seq_write_begin(&fde->fde_seq);
 #endif
fde->fde_file = fp;
-   if ((flags & O_CLOEXEC) != 0)
-   fde->fde_flags |= UF_EXCLOSE;
+   fde->fde_flags = (flags & O_CLOEXEC) != 0 ? UF_EXCLOSE : 0;
if (fcaps != NULL)
filecaps_move(fcaps, &fde->fde_caps);
else
@@ -2852,7 +2850,7 @@ dupfdopen(struct thread *td, struct file
seq_write_begin(&newfde->fde_seq);
 #endif
memcpy(newfde, oldfde, fde_change_size);
-   bzero(oldfde, fde_change_size);
+   oldfde->fde_file = NULL;
fdunused(fdp, dfd);
 #ifdef CAPABILITIES
seq_write_end(&newfde->fde_seq);
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r284345 - in head: . bin/cat bin/chflags bin/chio bin/chmod bin/cp bin/csh bin/date bin/dd bin/df bin/domainname bin/echo bin/ed bin/expr bin/freebsd-version bin/getfacl bin/hostname b

[Dimitry Andric]

On 13 Jun 2015, at 21:20, Simon J. Gerraty  wrote:
> 
> Author: sjg
> Date: Sat Jun 13 19:20:56 2015
> New Revision: 284345
> URL: https://svnweb.freebsd.org/changeset/base/284345
> 
> Log:
>  Add META_MODE support.
> 
>  Off by default, build behaves normally.
>  WITH_META_MODE we get auto objdir creation, the ability to
>  start build from anywhere in the tree.
> 
>  Still need to add real targets under targets/ to build packages.
> 
>  Differential Revision:   D2796
>  Reviewed by: brooks imp
> 
> Added:
>  head/bin/cat/Makefile.depend   (contents, props changed)
>  head/bin/chflags/Makefile.depend   (contents, props changed)

Some questions about this commit, which I'm sure more people must have:
* Was it really necessary to commit hundreds of clearly generated files?
* Couldn't these be generated on the fly, or with some "make depend" like 
command?
* How to update these files, if you change anything in the 'real' Makefiles?
* Or are you now the maintainer of these .depend files? :-)

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: svn commit: r284356 - head/usr.sbin/crunch/crunchgen

[Adrian Chadd]

On 14 June 2015 at 02:41, Tijl Coosemans  wrote:
> On Sat, 13 Jun 2015 22:01:21 + (UTC) Adrian Chadd  
> wrote:
>> Author: adrian
>> Date: Sat Jun 13 22:01:21 2015
>> New Revision: 284356
>> URL: https://svnweb.freebsd.org/changeset/base/284356
>>
>> Log:
>>   Fix up crunchgen binary generation to work with external cross-build
>>   tools.
>>
>>   * Allow STRIP to be overridden by the environment
>>   * Use CC to tie things together, not LD
>>
>>   Tested:
>>
>>   * i386, mips32
>>
>>   Submitted by:   kan
>>
>> Modified:
>>   head/usr.sbin/crunch/crunchgen/crunchgen.c
>>
>> Modified: head/usr.sbin/crunch/crunchgen/crunchgen.c
>> ==
>> --- head/usr.sbin/crunch/crunchgen/crunchgen.cSat Jun 13 20:15:44 
>> 2015(r284355)
>> +++ head/usr.sbin/crunch/crunchgen/crunchgen.cSat Jun 13 22:01:21 
>> 2015(r284356)
>> @@ -980,6 +980,7 @@ top_makefile_rules(FILE *outmk)
>>   prog_t *p;
>>
>>   fprintf(outmk, "LD?= ld\n");
>> + fprintf(outmk, "STRIP?= strip\n");
>>   if ( subtract_strlst(&libs, &libs_so) )
>>   fprintf(outmk, "# NOTE: Some LIBS declarations below 
>> overridden by LIBS_SO\n");
>>
>> @@ -1027,7 +1028,7 @@ top_makefile_rules(FILE *outmk)
>>   fprintf(outmk, "\t$(CC) -static -o %s %s.o $(CRUNCHED_OBJS) $(LIBS)\n",
>>   execfname, execfname);
>>   fprintf(outmk, ".endif\n");
>> - fprintf(outmk, "\tstrip %s\n", execfname);
>> + fprintf(outmk, "\t$(STRIP) %s\n", execfname);
>>   fprintf(outmk, "realclean: clean subclean\n");
>>   fprintf(outmk, "clean:\n\trm -f %s *.lo *.o *_stub.c\n", execfname);
>>   fprintf(outmk, "subclean: $(SUBCLEAN_TARGETS)\n");
>> @@ -1109,7 +1110,7 @@ prog_makefile_rules(FILE *outmk, prog_t
>>   fprintf(outmk, " $(%s_LIBS)", p->ident);
>>
>>   fprintf(outmk, "\n");
>> - fprintf(outmk, "\t$(LD) -dc -r -o %s.lo %s_stub.o $(%s_OBJPATHS)",
>> + fprintf(outmk, "\t$(CC) -nostdlibs -dc -r -o %s.lo %s_stub.o 
>> $(%s_OBJPATHS)",
>
> Does CC understand -dc and -r?

Apparently?



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

Re: svn commit: r284356 - head/usr.sbin/crunch/crunchgen

[Tijl Coosemans]

On Sun, 14 Jun 2015 08:07:17 -0700 Adrian Chadd  wrote:
> On 14 June 2015 at 02:41, Tijl Coosemans  wrote:
>> On Sat, 13 Jun 2015 22:01:21 + (UTC) Adrian Chadd  
>> wrote:
>>> Author: adrian
>>> Date: Sat Jun 13 22:01:21 2015
>>> New Revision: 284356
>>> URL: https://svnweb.freebsd.org/changeset/base/284356
>>>
>>> Log:
>>>   Fix up crunchgen binary generation to work with external cross-build
>>>   tools.
>>>
>>>   * Allow STRIP to be overridden by the environment
>>>   * Use CC to tie things together, not LD
>>>
>>>   Tested:
>>>
>>>   * i386, mips32
>>>
>>>   Submitted by:   kan
>>>
>>> Modified:
>>>   head/usr.sbin/crunch/crunchgen/crunchgen.c
>>>
>>> Modified: head/usr.sbin/crunch/crunchgen/crunchgen.c
>>> ==
>>> --- head/usr.sbin/crunch/crunchgen/crunchgen.cSat Jun 13 20:15:44 
>>> 2015(r284355)
>>> +++ head/usr.sbin/crunch/crunchgen/crunchgen.cSat Jun 13 22:01:21 
>>> 2015(r284356)
>>> @@ -1109,7 +1110,7 @@ prog_makefile_rules(FILE *outmk, prog_t
>>>   fprintf(outmk, " $(%s_LIBS)", p->ident);
>>>
>>>   fprintf(outmk, "\n");
>>> - fprintf(outmk, "\t$(LD) -dc -r -o %s.lo %s_stub.o $(%s_OBJPATHS)",
>>> + fprintf(outmk, "\t$(CC) -nostdlibs -dc -r -o %s.lo %s_stub.o 
>>> $(%s_OBJPATHS)",
>>
>> Does CC understand -dc and -r?
> 
> Apparently?

Hmm, it's undocumented but it seems to recognise -r and pass it on to
the linker.  Not -dc though.  It's safer to use: -Wl,-dc -Wl,-r
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r284356 - head/usr.sbin/crunch/crunchgen

[Adrian Chadd]

On 14 June 2015 at 08:28, Tijl Coosemans  wrote:
> On Sun, 14 Jun 2015 08:07:17 -0700 Adrian Chadd  wrote:
>> On 14 June 2015 at 02:41, Tijl Coosemans  wrote:
>>> On Sat, 13 Jun 2015 22:01:21 + (UTC) Adrian Chadd  
>>> wrote:
 Author: adrian
 Date: Sat Jun 13 22:01:21 2015
 New Revision: 284356
 URL: https://svnweb.freebsd.org/changeset/base/284356

 Log:
   Fix up crunchgen binary generation to work with external cross-build
   tools.

   * Allow STRIP to be overridden by the environment
   * Use CC to tie things together, not LD

   Tested:

   * i386, mips32

   Submitted by:   kan

 Modified:
   head/usr.sbin/crunch/crunchgen/crunchgen.c

 Modified: head/usr.sbin/crunch/crunchgen/crunchgen.c
 ==
 --- head/usr.sbin/crunch/crunchgen/crunchgen.cSat Jun 13 20:15:44 
 2015(r284355)
 +++ head/usr.sbin/crunch/crunchgen/crunchgen.cSat Jun 13 22:01:21 
 2015(r284356)
 @@ -1109,7 +1110,7 @@ prog_makefile_rules(FILE *outmk, prog_t
   fprintf(outmk, " $(%s_LIBS)", p->ident);

   fprintf(outmk, "\n");
 - fprintf(outmk, "\t$(LD) -dc -r -o %s.lo %s_stub.o $(%s_OBJPATHS)",
 + fprintf(outmk, "\t$(CC) -nostdlibs -dc -r -o %s.lo %s_stub.o 
 $(%s_OBJPATHS)",
>>>
>>> Does CC understand -dc and -r?
>>
>> Apparently?
>
> Hmm, it's undocumented but it seems to recognise -r and pass it on to
> the linker.  Not -dc though.  It's safer to use: -Wl,-dc -Wl,-r

Ok. Would you mind committing it? I'm not near a FreeBSD machine at the moment.

Thanks!


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

svn commit: r284382 - head/usr.sbin/crunch/crunchgen

[Tijl Coosemans]

Author: tijl
Date: Sun Jun 14 15:40:17 2015
New Revision: 284382
URL: https://svnweb.freebsd.org/changeset/base/284382

Log:
  Tell the compiler that -dc and -r are linker flags.
  
  Reviewed by:  adrian

Modified:
  head/usr.sbin/crunch/crunchgen/crunchgen.c

Modified: head/usr.sbin/crunch/crunchgen/crunchgen.c
==
--- head/usr.sbin/crunch/crunchgen/crunchgen.c  Sun Jun 14 14:10:05 2015
(r284381)
+++ head/usr.sbin/crunch/crunchgen/crunchgen.c  Sun Jun 14 15:40:17 2015
(r284382)
@@ -1110,7 +1110,7 @@ prog_makefile_rules(FILE *outmk, prog_t 
fprintf(outmk, " $(%s_LIBS)", p->ident);
 
fprintf(outmk, "\n");
-   fprintf(outmk, "\t$(CC) -nostdlib -dc -r -o %s.lo %s_stub.o 
$(%s_OBJPATHS)",
+   fprintf(outmk, "\t$(CC) -nostdlib -Wl,-dc -Wl,-r -o %s.lo %s_stub.o 
$(%s_OBJPATHS)",
p->name, p->name, p->ident);
if (p->libs)
fprintf(outmk, " $(%s_LIBS)", p->ident);
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r284356 - head/usr.sbin/crunch/crunchgen

[Tijl Coosemans]

On Sun, 14 Jun 2015 08:31:32 -0700 Adrian Chadd  wrote:
> On 14 June 2015 at 08:28, Tijl Coosemans  wrote:
>> On Sun, 14 Jun 2015 08:07:17 -0700 Adrian Chadd  wrote:
>>> On 14 June 2015 at 02:41, Tijl Coosemans  wrote:
 On Sat, 13 Jun 2015 22:01:21 + (UTC) Adrian Chadd  
 wrote:
> Author: adrian
> Date: Sat Jun 13 22:01:21 2015
> New Revision: 284356
> URL: https://svnweb.freebsd.org/changeset/base/284356
>
> Log:
>   Fix up crunchgen binary generation to work with external cross-build
>   tools.
>
>   * Allow STRIP to be overridden by the environment
>   * Use CC to tie things together, not LD
>
>   Tested:
>
>   * i386, mips32
>
>   Submitted by:   kan
>
> Modified:
>   head/usr.sbin/crunch/crunchgen/crunchgen.c
>
> Modified: head/usr.sbin/crunch/crunchgen/crunchgen.c
> ==
> --- head/usr.sbin/crunch/crunchgen/crunchgen.cSat Jun 13 20:15:44 
> 2015(r284355)
> +++ head/usr.sbin/crunch/crunchgen/crunchgen.cSat Jun 13 22:01:21 
> 2015(r284356)
> @@ -1109,7 +1110,7 @@ prog_makefile_rules(FILE *outmk, prog_t
>   fprintf(outmk, " $(%s_LIBS)", p->ident);
>
>   fprintf(outmk, "\n");
> - fprintf(outmk, "\t$(LD) -dc -r -o %s.lo %s_stub.o $(%s_OBJPATHS)",
> + fprintf(outmk, "\t$(CC) -nostdlibs -dc -r -o %s.lo %s_stub.o 
> $(%s_OBJPATHS)",

 Does CC understand -dc and -r?
>>>
>>> Apparently?
>>
>> Hmm, it's undocumented but it seems to recognise -r and pass it on to
>> the linker.  Not -dc though.  It's safer to use: -Wl,-dc -Wl,-r
> 
> Ok. Would you mind committing it? I'm not near a FreeBSD machine at the 
> moment.

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

Re: svn commit: r284370 - head/usr.bin/kdump

[Dimitry Andric]

On 14 Jun 2015, at 05:30, Simon J. Gerraty  wrote:
> 
> Author: sjg
> Date: Sun Jun 14 03:30:39 2015
> New Revision: 284370
> URL: https://svnweb.freebsd.org/changeset/base/284370
> 
> Log:
>  Create proper targets for linux*syscalls.c
> 
> Modified:
>  head/usr.bin/kdump/Makefile

Is this supposed to fix things?  Even at r284381, I get:

===> usr.bin/kdump (depend)
sh /usr/src/usr.bin/kdump/mksubr /usr/obj/usr/src/tmp/usr/include >kdump_subr.c
env MACHINE=i386 CPP="cpp "  sh /usr/src/usr.bin/kdump/mkioctls print 
/usr/obj/usr/src/tmp/usr/include > ioctl.c
:1:10: fatal error: 'cam/cam_compat.h' file not found
#include 
 ^
1 error generated.
rm -f .depend
CC='cc  ' mkdep -f .depend -a-I/usr/src/usr.bin/kdump/../ktrace 
-I/usr/src/usr.bin/kdump -I/usr/src/usr.bin/kdump/../.. -I. -DHAVE_LIBCAPSICUM 
-DPF -std=gnu99   kdump_subr.c /usr/src/usr.bin/kdump/kdump.c ioctl.c 
/usr/src/usr.bin/kdump/../ktrace/subr.c
/usr/src/usr.bin/kdump/kdump.c:153:10: fatal error: 'linux_syscalls.c' file not 
found
#include 
 ^
1 error generated.
mkdep: compile failed
*** Error code 1

Stop.

Any idea?  I obviously do not see any linux_syscalls.c in the objdir.

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

svn commit: r284383 - head/sys/dev/filemon

[Simon J. Gerraty]

Author: sjg
Date: Sun Jun 14 16:31:06 2015
New Revision: 284383
URL: https://svnweb.freebsd.org/changeset/base/284383

Log:
  Latest clang uses openat(2).
  
  If the pathname is absolute or dirfd is AT_FDCWD we can
  handle it exactly like open(2).
  Otherwise we output an A record to indicate that the path of
  an open directory needs to be used (earlier in the trace).
  
  Differential Revision:D2810
  Reviewed by: jhb
  MFC after: a bit

Modified:
  head/sys/dev/filemon/filemon_wrapper.c

Modified: head/sys/dev/filemon/filemon_wrapper.c
==
--- head/sys/dev/filemon/filemon_wrapper.c  Sun Jun 14 15:40:17 2015
(r284382)
+++ head/sys/dev/filemon/filemon_wrapper.c  Sun Jun 14 16:31:06 2015
(r284383)
@@ -316,6 +316,68 @@ filemon_wrapper_open(struct thread *td, 
 }
 
 static int
+filemon_wrapper_openat(struct thread *td, struct openat_args *uap)
+{
+   int ret;
+   size_t done;
+   size_t len;
+   struct filemon *filemon;
+
+   if ((ret = sys_openat(td, uap)) == 0) {
+   /* Grab a read lock on the filemon inuse list. */
+   filemon_lock_read();
+
+   if ((filemon = filemon_pid_check(curproc)) != NULL) {
+   /* Lock the found filemon structure. */
+   filemon_filemon_lock(filemon);
+
+   copyinstr(uap->path, filemon->fname1,
+   sizeof(filemon->fname1), &done);
+
+   filemon->fname2[0] = '\0';
+   if (filemon->fname1[0] != '/' && uap->fd != AT_FDCWD) {
+   /*
+* rats - we cannot do too much about this.
+* the trace should show a dir we read
+* recently.. output an A record as a clue
+* until we can do better.
+*/
+   len = snprintf(filemon->msgbufr,
+   sizeof(filemon->msgbufr), "A %d %s\n",
+   curproc->p_pid, filemon->fname1);
+   filemon_output(filemon, filemon->msgbufr, len);
+   }
+   if (uap->flag & O_RDWR) {
+   /*
+* We'll get the W record below, but need
+* to also output an R to distingish from
+* O_WRONLY.
+*/
+   len = snprintf(filemon->msgbufr,
+   sizeof(filemon->msgbufr), "R %d %s%s\n",
+   curproc->p_pid, filemon->fname2, 
filemon->fname1);
+   filemon_output(filemon, filemon->msgbufr, len);
+   }
+
+
+   len = snprintf(filemon->msgbufr,
+   sizeof(filemon->msgbufr), "%c %d %s%s\n",
+   (uap->flag & O_ACCMODE) ? 'W':'R',
+   curproc->p_pid, filemon->fname2, filemon->fname1);
+   filemon_output(filemon, filemon->msgbufr, len);
+
+   /* Unlock the found filemon structure. */
+   filemon_filemon_unlock(filemon);
+   }
+
+   /* Release the read lock. */
+   filemon_unlock_read();
+   }
+
+   return (ret);
+}
+
+static int
 filemon_wrapper_rename(struct thread *td, struct rename_args *uap)
 {
int ret;
@@ -669,6 +731,7 @@ filemon_wrapper_install(void)
sv_table[SYS_execve].sy_call = (sy_call_t *) filemon_wrapper_execve;
sv_table[SYS_fork].sy_call = (sy_call_t *) filemon_wrapper_fork;
sv_table[SYS_open].sy_call = (sy_call_t *) filemon_wrapper_open;
+   sv_table[SYS_openat].sy_call = (sy_call_t *) filemon_wrapper_openat;
sv_table[SYS_rename].sy_call = (sy_call_t *) filemon_wrapper_rename;
sv_table[SYS_stat].sy_call = (sy_call_t *) filemon_wrapper_stat;
sv_table[SYS_unlink].sy_call = (sy_call_t *) filemon_wrapper_unlink;
@@ -687,6 +750,7 @@ filemon_wrapper_install(void)
sv_table[FREEBSD32_SYS_freebsd32_execve].sy_call = (sy_call_t *) 
filemon_wrapper_freebsd32_execve;
sv_table[FREEBSD32_SYS_fork].sy_call = (sy_call_t *) 
filemon_wrapper_fork;
sv_table[FREEBSD32_SYS_open].sy_call = (sy_call_t *) 
filemon_wrapper_open;
+   sv_table[FREEBSD32_SYS_openat].sy_call = (sy_call_t *) 
filemon_wrapper_openat;
sv_table[FREEBSD32_SYS_rename].sy_call = (sy_call_t *) 
filemon_wrapper_rename;
sv_table[FREEBSD32_SYS_freebsd32_stat].sy_call = (sy_call_t *) 
filemon_wrapper_freebsd32_stat;
sv_table[FREEBSD32_SYS_unlink].sy_call = (sy_call_t *) 
filemon_wrapper_unlink;
@@ -713,6 +777,7 @@ filemon_wrapper_de

Re: svn commit: r284198 - head/bin/ls

[Steve Kargl]

On Sun, Jun 14, 2015 at 11:22:03AM +0100, Bruce Simpson wrote:
> 
> But I have yet to see a coherent argument here -- size(1) numbers, RSS 
> figures etc. -- about how it allegedly adds bloat. Most of what I've 
> seen so far is POLA, NIH resistance, and hand-wavery.
> 

It is not alleged.  I actaully measured the bloat libxo
caused when w(1) was converted.

https://lists.freebsd.org/pipermail/freebsd-current/2015-March/054917.html

Here's the bloat with ls(1)

% ldd /bin/ls 
/bin/ls:
libutil.so.9 => /lib/libutil.so.9 (0x2807d000)
libncursesw.so.8 => /lib/libncursesw.so.8 (0x2808f000)
libc.so.7 => /lib/libc.so.7 (0x280db000)
% ll /bin/ls
-r-xr-xr-x  1 root  wheel  - 28568 Jun  7 21:01 /bin/ls*

% ldd /bin/ls
/bin/ls:
libutil.so.9 => /lib/libutil.so.9 (0x2807d000)
libncursesw.so.8 => /lib/libncursesw.so.8 (0x2808f000)
libxo.so.0 => /lib/libxo.so.0 (0x280db000)
libc.so.7 => /lib/libc.so.7 (0x280ec000)
laptop-kargl:kargl[204] ll /bin/ls
-r-xr-xr-x  1 root  wheel  - 31376 Jun 14 10:06 /bin/ls*

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

Re: svn commit: r284198 - head/bin/ls

[Adrian Chadd]

On 14 June 2015 at 10:10, Steve Kargl  wrote:
> On Sun, Jun 14, 2015 at 11:22:03AM +0100, Bruce Simpson wrote:
>>
>> But I have yet to see a coherent argument here -- size(1) numbers, RSS
>> figures etc. -- about how it allegedly adds bloat. Most of what I've
>> seen so far is POLA, NIH resistance, and hand-wavery.
>>
>
> It is not alleged.  I actaully measured the bloat libxo
> caused when w(1) was converted.
>
> https://lists.freebsd.org/pipermail/freebsd-current/2015-March/054917.html
>
> Here's the bloat with ls(1)
>
> % ldd /bin/ls
> /bin/ls:
> libutil.so.9 => /lib/libutil.so.9 (0x2807d000)
> libncursesw.so.8 => /lib/libncursesw.so.8 (0x2808f000)
> libc.so.7 => /lib/libc.so.7 (0x280db000)
> % ll /bin/ls
> -r-xr-xr-x  1 root  wheel  - 28568 Jun  7 21:01 /bin/ls*
>
> % ldd /bin/ls
> /bin/ls:
> libutil.so.9 => /lib/libutil.so.9 (0x2807d000)
> libncursesw.so.8 => /lib/libncursesw.so.8 (0x2808f000)
> libxo.so.0 => /lib/libxo.so.0 (0x280db000)
> libc.so.7 => /lib/libc.so.7 (0x280ec000)
> laptop-kargl:kargl[204] ll /bin/ls
> -r-xr-xr-x  1 root  wheel  - 31376 Jun 14 10:06 /bin/ls*

Plus 60k for the shared library.

I don't mind that too much right now - it's around an extra 4k of
overhead per binary right now.



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

Re: svn commit: r284345 - in head: . bin/cat bin/chflags bin/chio bin/chmod bin/cp bin/csh bin/date bin/dd bin/df bin/domainname bin/echo bin/ed bin/expr bin/freebsd-version bin/getfacl bin/hostname b

[Adrian Chadd]

Wait a second - y'all committed a bunch of dependencies that we aren't
supposed to edit directly?

So what's the process for making sure we don't stomp over the feet of
other people who are using the depend based builds?





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

svn commit: r284384 - head/sys/netinet

[Michael Tuexen]

Author: tuexen
Date: Sun Jun 14 17:48:44 2015
New Revision: 284384
URL: https://svnweb.freebsd.org/changeset/base/284384

Log:
  Stop the heartbeat timer when removing a net.
  Thanks to the reporter of
  https://code.google.com/p/sctp-refimpl/issues/detail?id=14
  for reporting the issue.
  
  MFC after: 3 days

Modified:
  head/sys/netinet/sctp_var.h

Modified: head/sys/netinet/sctp_var.h
==
--- head/sys/netinet/sctp_var.h Sun Jun 14 16:31:06 2015(r284383)
+++ head/sys/netinet/sctp_var.h Sun Jun 14 17:48:44 2015(r284384)
@@ -178,6 +178,7 @@ extern struct pr_usrreqs sctp_usrreqs;
if (SCTP_DECREMENT_AND_CHECK_REFCOUNT(&(__net)->ref_count)) { \
(void)SCTP_OS_TIMER_STOP(&(__net)->rxt_timer.timer); \
(void)SCTP_OS_TIMER_STOP(&(__net)->pmtu_timer.timer); \
+   (void)SCTP_OS_TIMER_STOP(&(__net)->hb_timer.timer); \
if ((__net)->ro.ro_rt) { \
RTFREE((__net)->ro.ro_rt); \
(__net)->ro.ro_rt = NULL; \
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r284345 - in head: . bin/cat bin/chflags bin/chio bin/chmod bin/cp bin/csh bin/date bin/dd bin/df bin/domainname bin/echo bin/ed bin/expr bin/freebsd-version bin/getfacl bin/hostname b

[Warner Losh]

> On Jun 14, 2015, at 12:46 AM, Craig Rodrigues  wrote:
> 
> On Sat, Jun 13, 2015 at 3:34 PM, Craig Rodrigues  wrote:
> >
> > On Sat, Jun 13, 2015 at 12:20 PM, Simon J. Gerraty  wrote:
> >>
> >> Author: sjg
> >> Date: Sat Jun 13 19:20:56 2015
> >> New Revision: 284345
> >> URL: https://svnweb.freebsd.org/changeset/base/284345
> >>
> >> Log:
> >>   Add META_MODE support.
> >
> >
> > Simon,
> >
> > Can you take a look at this:
> > https://jenkins.freebsd.org/job/FreeBSD_HEAD/2860/
> >
> >
> > The console output is showing this:
> >
> > + make -j 4 buildworld __MAKE_CONF=/builds/FreeBSD_HEAD/make.conf
> > make: "/builds/FreeBSD_HEAD/Makefile" line 102: Malformed conditional 
> > (${MK_META_MODE} == "yes")
> > make: Fatal errors encountered -- cannot continue
> > make: stopped in /builds/FreeBSD_HEAD
> > Build step 'Execute shell' marked build as failure
> >
> > This is using a FreeBSD 10.1 host to build HEAD.
> >
> 
>  I can reproduce the problem pretty quickly.
> I did this on a FreeBSD-CURRENT host:
> 
> # svn co svn://svn.freebsd.org/base/head src
> # cd src
> # make -V MK_META_MODE
> no
> 
> I did this on a FreeBSD 10.1-R host:
> 
> # svn co svn://svn.freebsd.org/base/head src
> # cd src
> # make -V MK_META_MODE
> make: "/root/src/Makefile" line 102: Malformed conditional (${MK_META_MODE} 
> == "yes")
> make: Fatal errors encountered -- cannot continue
> make: stopped in /root/src
> 
> FreeBSD 10.1 is using bmake as /usr/bin/make so fmake is not an issue here.
> I think the issue is that on FreeBSD 10.1, the /usr/share/mk files do
> not have the logic to define MK_META_MODE.
> 
> I am not sure if this is the right fix, but I did this:
> 
> Index: Makefile
> ===
> --- Makefile (revision 284374)
> +++ Makefile (working copy)
> @@ -99,7 +99,7 @@
>  #
>  # For more information, see the build(7) manual page.
>  #
> -.if ${MK_META_MODE} == "yes"
> +.if !empty(MK_META_MODE) && ${MK_META_MODE} == "yes"
>  # targets/Makefile plays the role of top-level
>  .include "targets/Makefile"
>  .else
> 
> 
> and that made things work for me on FreeBSD 10.1-R.

Since the src.opts.mk files isn’t included for src/Makefile, MK_META_MODE isn’t 
defined.

Warner



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: svn commit: r284198 - head/bin/ls

[Warner Losh]

> On Jun 13, 2015, at 8:40 PM, Craig Rodrigues  wrote:
> 
> On Sat, Jun 13, 2015 at 5:26 PM, Steve Kargl 
>  wrote:
> On Sat, Jun 13, 2015 at 05:13:31PM -0700, Craig Rodrigues wrote:
> >
> > For people who are trying to build FreeBSD-based embedded products with
> > modern web UI's,
> > this is *really* useful.
> >
> 
> Given the bloat caused by libxo, which I showed in March,
> I don't see how people working on embedded products could
> be thrilled with this.
> 
> Steve,
> 
> For people building embedded products these days,
> storage of gigabytes and even terabytes is often available,

Often, but not always. The bloat is another issue with libxo. It’s a problem
for the embedded routers that Adrian has been pushing. It is a problem with
many of the embedded boards I have. It isn’t too big of a problem with RPi
and the like because SD cards are a lot easier to upgrade than chip-down
NAND Flash parts.

> so the space increase that libxo provides is not that big a problem,
> at least for the last few products that I have worked on in the past few 
> years.

You are working on fairly big embedded.

Warner



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: svn commit: r284198 - head/bin/ls

[Warner Losh]

> On Jun 13, 2015, at 9:22 PM, Craig Rodrigues  wrote:
> 
> 
> 
> On Sat, Jun 13, 2015 at 6:00 PM, Adrian Chadd  wrote:
> >
> > I guarantee that no matter what you've worked on, there's
> > approximately five orders of magnitude of shipping devices whose
> > entire storage space can be measured in 1 digit megabytes. Each year.
> 
> (And yes - there's an appreciable set of them for which freebsd boots,
> runs and keeps running on them.0
> 
> You can buy em too, some of them even under $60.
> 
> Can FreeBSD now not run on these systems because of libxo?

Yes. The root image sizes for a reasonable subset of the system now exceeds
the flash that I have on my embedded arm boards. I have to spill over onto
the SD card if I want to make progress. Some trimming could be done, but 11
images are quite a bit bigger than 10 images for the same software.

Warner



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: svn commit: r284345 - in head: . bin/cat bin/chflags bin/chio bin/chmod bin/cp bin/csh bin/date bin/dd bin/df bin/domainname bin/echo bin/ed bin/expr bin/freebsd-version bin/getfacl bin/hostname b

[Adrian Chadd]

Hi,

+ make -j 4 buildworld __MAKE_CONF=/builds/FreeBSD_HEAD/make.conf
make: "/builds/FreeBSD_HEAD/Makefile" line 102: Malformed conditional
(${MK_META_MODE} == "yes")
make: Fatal errors encountered -- cannot continue
make: stopped in /builds/FreeBSD_HEAD
Build step 'Execute shell' marked build as failure
[WARNINGS] Skipping publisher since build result is FAILURE
IRC notifier plugin: Sending notification to: #freebsd-commits

.. do you have a fix for this? Or if you don't, would you mind backing
things out until you've come up with a solution?



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

Re: svn commit: r284198 - head/bin/ls

[Bruce Simpson]

On 14/06/2015 18:10, Steve Kargl wrote:

On Sun, Jun 14, 2015 at 11:22:03AM +0100, Bruce Simpson wrote:


But I have yet to see a coherent argument here -- size(1) numbers, RSS
figures etc. -- about how it allegedly adds bloat. Most of what I've
seen so far is POLA, NIH resistance, and hand-wavery.



It is not alleged.  I actaully measured the bloat libxo
caused when w(1) was converted.

...

Here's the bloat with ls(1)

...

Steve, that's still less than one 4KB page.

OK, so I find it difficult to believe -- in this day and age of 
pipeline-saving CMOV instructions -- that the overhead is as large as 
~2800 bytes, where I would have expected roughly half that.


But not knowing what compile options you used, or having information 
about sizes (and working sets - just listing file sizes is hand waving) 
across the libxo modified binaries, this still doesn't give a complete 
picture of the relative cost of the feature.


However, that's still a very modest increase, considering the 
architectural scope of the libxo change and what it provides.


Warner suggests that for some targets it is too much, and he might have 
a point. But if you look at That Other Operating System, this is 
generally dealt with there by deploying something like BusyBox instead.


I can understand why we don't want to go down that road -- in my 
experience, the choice of BusyBox sacrifices too much usability -- and 
would support a WITH_LIBXO for that reason alone. The extra bytes might 
even disappear in the noise after crunchgen.


I think it is also fair that the people who advocated for this in the 
beginning (not I, though I support it in principle) and did the work 
(not I either, ENOTIME) should have done this work up front. I've had to 
do it to justify similar changes in other projects.

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

Re: svn commit: r284198 - head/bin/ls

[Adrian Chadd]

We have busybox already - it's called bsdbox, and it's in base, and
we're already using it, and yes, it does pull in libxo. :)

I'm not worried about the size increase of libxo. That's the wrong
thing to focus on. If it gets much more bloated then I'll poke people
with the big "what are you thinking" stick. The issues people have
aren't size related, they're "this API needs improvement and we have
bugs introduced into tools."

I do like how zero percent of the comments are "hey, maybe we need
unit tests that run these tools and ensure they output the right
stuff." If this were ${WORK} and I were ${BOSS}, I'd have asked the
libxo developers to include unit tests before/after for each thing
they broke, so we don't have a repeat of this kind of thing. But, this
apparently isn't ${WORK} and I definitely don't want to be anyones
boss, so..



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

Re: svn commit: r284198 - head/bin/ls

[Steve Kargl]

On Sun, Jun 14, 2015 at 07:46:05PM +0100, Bruce Simpson wrote:
> On 14/06/2015 18:10, Steve Kargl wrote:
> > On Sun, Jun 14, 2015 at 11:22:03AM +0100, Bruce Simpson wrote:
> >>
> >> But I have yet to see a coherent argument here -- size(1) numbers, RSS
> >> figures etc. -- about how it allegedly adds bloat. Most of what I've
> >> seen so far is POLA, NIH resistance, and hand-wavery.
> >>
> >
> > It is not alleged.  I actaully measured the bloat libxo
> > caused when w(1) was converted.
> ...
> > Here's the bloat with ls(1)
> ...
> 
> Steve, that's still less than one 4KB page.

4KB for dynamic linking.  38KB for static linking.  

How many utilities are to be converted?  4KB (or 38KB)
can add up quickly.

> But not knowing what compile options you used, or having information 
> about sizes (and working sets - just listing file sizes is hand waving) 
> across the libxo modified binaries, this still doesn't give a complete 
> picture of the relative cost of the feature.

Default 'make buildworld' options with CPUTYPE?=core2.  So, -O2.
I also tested with CFLAGS+=-static in w(1) and ls(1)'s Makefile.
The numbers that I showed are from 'make buildworld'.  The only
difference is w(1) and ls(1) with/without the libxo change.  I
don't need to cook the numbers to fabricate some issue.  Choose
your favorite CFLAGS.  Use svn to get w(1) and ls(1) with/without
libxo.  It's not difficult.

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

svn commit: r284385 - head/lib/libthr/thread

[Konstantin Belousov]

Author: kib
Date: Sun Jun 14 19:19:46 2015
New Revision: 284385
URL: https://svnweb.freebsd.org/changeset/base/284385

Log:
  Fix typo in comment.
  
  MFC after:3 days

Modified:
  head/lib/libthr/thread/thr_sig.c

Modified: head/lib/libthr/thread/thr_sig.c
==
--- head/lib/libthr/thread/thr_sig.cSun Jun 14 17:48:44 2015
(r284384)
+++ head/lib/libthr/thread/thr_sig.cSun Jun 14 19:19:46 2015
(r284385)
@@ -293,8 +293,8 @@ check_cancel(struct pthread *curthread, 
 * 2) because _thr_ast() may be called by
 *THR_CRITICAL_LEAVE() which is used by rtld rwlock
 *and any libthr internal locks, when rtld rwlock
-*is used, it is mostly caused my an unresolved PLT.
-*those routines may clear the TDP_WAKEUP flag by
+*is used, it is mostly caused by an unresolved PLT.
+*Those routines may clear the TDP_WAKEUP flag by
 *invoking some system calls, in those cases, we
 *also should reenable the flag.
 * 3) thread is in sigsuspend(), and the syscall insists
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r284198 - head/bin/ls

[Craig Rodrigues]

On Sun, Jun 14, 2015 at 11:53 AM, Adrian Chadd  wrote:

> I do like how zero percent of the comments are "hey, maybe we need
> unit tests that run these tools and ensure they output the right
> stuff."
>

Actually you are wrong on that point.  See:

https://lists.freebsd.org/pipermail/svn-src-all/2015-June/105753.html

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

Re: svn commit: r284198 - head/bin/ls

[Adrian Chadd]

On 14 June 2015 at 12:25, Craig Rodrigues  wrote:
>
>
> On Sun, Jun 14, 2015 at 11:53 AM, Adrian Chadd  wrote:
>>
>> I do like how zero percent of the comments are "hey, maybe we need
>> unit tests that run these tools and ensure they output the right
>> stuff."
>
>
> Actually you are wrong on that point.  See:
>
> https://lists.freebsd.org/pipermail/svn-src-all/2015-June/105753.html
>
> --
> Craig
>

Woo! Glad to be wrong.


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

svn commit: r284386 - head/lib/libc/net

[Michael Tuexen]

Author: tuexen
Date: Sun Jun 14 20:16:36 2015
New Revision: 284386
URL: https://svnweb.freebsd.org/changeset/base/284386

Log:
  Fix name of a constant.
  
  MFC after: 3 days

Modified:
  head/lib/libc/net/sctp_bindx.3

Modified: head/lib/libc/net/sctp_bindx.3
==
--- head/lib/libc/net/sctp_bindx.3  Sun Jun 14 19:19:46 2015
(r284385)
+++ head/lib/libc/net/sctp_bindx.3  Sun Jun 14 20:16:36 2015
(r284386)
@@ -28,7 +28,7 @@
 .\" From: @(#)send.2   8.2 (Berkeley) 2/21/94
 .\" $FreeBSD$
 .\"
-.Dd December 15, 2006
+.Dd June 14, 2015
 .Dt SCTP_BINDX 3
 .Os
 .Sh NAME
@@ -71,7 +71,7 @@ must be one of the following values.
 This value indicates that the listed address(es) need to
 be added to the endpoint.
 .Pp
-.Dv SCTP_BINDX_DEL_ADDR
+.Dv SCTP_BINDX_REM_ADDR
 This value indicates that the listed address(es) need to
 be removed from the endpoint.
 .Pp
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r284387 - head/sys/vm

[Konstantin Belousov]

Author: kib
Date: Sun Jun 14 20:23:41 2015
New Revision: 284387
URL: https://svnweb.freebsd.org/changeset/base/284387

Log:
  Invalid pages do not need neither update of the activation count nor
  they coould be dirty.  Move the handling if the invalid pages in the
  inactive scan earlier.
  
  Remove some code duplication in the scan by introducing the
  'drop_page' label, which centralizes the object and the page unlock.
  
  Suggested and reviewed by:alc
  Sponsored by: The FreeBSD Foundation
  MFC after:2 weeks

Modified:
  head/sys/vm/vm_pageout.c

Modified: head/sys/vm/vm_pageout.c
==
--- head/sys/vm/vm_pageout.cSun Jun 14 20:16:36 2015(r284386)
+++ head/sys/vm/vm_pageout.cSun Jun 14 20:23:41 2015(r284387)
@@ -1159,6 +1159,17 @@ vm_pageout_scan(struct vm_domain *vmd, i
queues_locked = FALSE;
 
/*
+* Invalid pages can be easily freed. They cannot be
+* mapped, vm_page_free() asserts this.
+*/
+   if (m->valid == 0 && m->hold_count == 0) {
+   vm_page_free(m);
+   PCPU_INC(cnt.v_dfree);
+   --page_shortage;
+   goto drop_page;
+   }
+
+   /*
 * We bump the activation count if the page has been
 * referenced while in the inactive queue.  This makes
 * it less likely that the page will be added back to the
@@ -1192,15 +1203,10 @@ vm_pageout_scan(struct vm_domain *vmd, i
queues_locked = TRUE;
vm_page_requeue_locked(m);
}
-   VM_OBJECT_WUNLOCK(object);
-   vm_page_unlock(m);
-   goto relock_queues;
+   goto drop_page;
}
 
if (m->hold_count != 0) {
-   vm_page_unlock(m);
-   VM_OBJECT_WUNLOCK(object);
-
/*
 * Held pages are essentially stuck in the
 * queue.  So, they ought to be discounted
@@ -1209,7 +1215,7 @@ vm_pageout_scan(struct vm_domain *vmd, i
 * loop over the active queue below.
 */
addl_page_shortage++;
-   goto relock_queues;
+   goto drop_page;
}
 
/*
@@ -1224,14 +1230,7 @@ vm_pageout_scan(struct vm_domain *vmd, i
if (m->dirty == 0 && object->ref_count != 0)
pmap_remove_all(m);
 
-   if (m->valid == 0) {
-   /*
-* Invalid pages can be easily freed
-*/
-   vm_page_free(m);
-   PCPU_INC(cnt.v_dfree);
-   --page_shortage;
-   } else if (m->dirty == 0) {
+   if (m->dirty == 0) {
/*
 * Clean pages can be freed.
 */
@@ -1305,6 +1304,7 @@ vm_pageout_scan(struct vm_domain *vmd, i
vm_page_lock_assert(m, MA_NOTOWNED);
goto relock_queues;
}
+drop_page:
vm_page_unlock(m);
VM_OBJECT_WUNLOCK(object);
 relock_queues:
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r284345 - in head: . bin/cat bin/chflags bin/chio bin/chmod bin/cp bin/csh bin/date bin/dd bin/df bin/domainname bin/echo bin/ed bin/expr bin/freebsd-version bin/getfacl bin/hostname b

[Garrett Cooper]

On Jun 14, 2015, at 14:21, Simon J. Gerraty  wrote:

> Garrett Cooper  wrote:
>>> Great. More breakage:
>>> 
>>> $ fmake buildworld
> 
> Babt has committed enough changes to head in recent months that building
> with fmake is no longer an option.

Baptiste only committed one issue to share/bsd.links.mk that broke 
bootstrapping from upgrade_checks. I’m waiting for replies to my other private 
thread about deprecating/removing fmake so I can propose its official removal 
on -arch.

Breaking source upgrades to later versions is painful. We want to make sure 
fmake at least works with upgrade_checks so people can upgrade from earlier 
versions of 8/9/10 to 11 without having to deal with a lot of pain.

Thanks,


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: svn commit: r284345 - in head: . bin/cat bin/chflags bin/chio bin/chmod bin/cp bin/csh bin/date bin/dd bin/df bin/domainname bin/echo bin/ed bin/expr bin/freebsd-version bin/getfacl bin/hostname b

[Simon J. Gerraty]

Bryan Drewery  wrote:
> Is anything remaining from the projects/bmake branch?

I don't think so - apart from some merge botches ;-)
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r284345 - in head: . bin/cat bin/chflags bin/chio bin/chmod bin/cp bin/csh bin/date bin/dd bin/df bin/domainname bin/echo bin/ed bin/expr bin/freebsd-version bin/getfacl bin/hostname b

[Simon J. Gerraty]

Garrett Cooper  wrote:
> > Great. More breakage:
> > 
> > $ fmake buildworld

Babt has committed enough changes to head in recent months that building
with fmake is no longer an option.
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r284198 - head/bin/ls

[Garrett Cooper]

> On Jun 14, 2015, at 11:53, Adrian Chadd  wrote:
> 
> We have busybox already - it's called bsdbox, and it's in base, and
> we're already using it, and yes, it does pull in libxo. :)
> 
> I'm not worried about the size increase of libxo. That's the wrong
> thing to focus on. If it gets much more bloated then I'll poke people
> with the big "what are you thinking" stick. The issues people have
> aren't size related, they're "this API needs improvement and we have
> bugs introduced into tools."
> 
> I do like how zero percent of the comments are "hey, maybe we need
> unit tests that run these tools and ensure they output the right
> stuff." If this were ${WORK} and I were ${BOSS}, I'd have asked the
> libxo developers to include unit tests before/after for each thing
> they broke, so we don't have a repeat of this kind of thing. But, this
> apparently isn't ${WORK} and I definitely don't want to be anyones
> boss, so..

Ugh. I'll write the tests ;(...
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r284392 - head/usr.sbin/pw

[Baptiste Daroussin]

Author: bapt
Date: Sun Jun 14 21:50:38 2015
New Revision: 284392
URL: https://svnweb.freebsd.org/changeset/base/284392

Log:
  Change the documentation to reflect where the -V option should be used
  
  Suggested by: kientzle

Modified:
  head/usr.sbin/pw/pw.8

Modified: head/usr.sbin/pw/pw.8
==
--- head/usr.sbin/pw/pw.8   Sun Jun 14 21:14:47 2015(r284391)
+++ head/usr.sbin/pw/pw.8   Sun Jun 14 21:50:38 2015(r284392)
@@ -24,7 +24,7 @@
 .\"
 .\" $FreeBSD$
 .\"
-.Dd June 3, 2015
+.Dd June 14, 2015
 .Dt PW 8
 .Os
 .Sh NAME
@@ -278,7 +278,7 @@ flag may be used to override this behavi
 As an exception to the general rule where options must follow the operation
 type, the
 .Fl V
-flag may be used on the command line before the operation keyword.
+flag must be used on the command line before the operation keyword.
 .It Fl C Ar config
 By default,
 .Nm
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r284345 - in head: . bin/cat bin/chflags bin/chio bin/chmod bin/cp bin/csh bin/date bin/dd bin/df bin/domainname bin/echo bin/ed bin/expr bin/freebsd-version bin/getfacl bin/hostname b

[Simon J. Gerraty]

Adrian Chadd  wrote:

> Hi,
> 
> + make -j 4 buildworld __MAKE_CONF=/builds/FreeBSD_HEAD/make.conf
> make: "/builds/FreeBSD_HEAD/Makefile" line 102: Malformed conditional
> (${MK_META_MODE} == "yes")
> make: Fatal errors encountered -- cannot continue
> make: stopped in /builds/FreeBSD_HEAD
> Build step 'Execute shell' marked build as failure
> [WARNINGS] Skipping publisher since build result is FAILURE
> IRC notifier plugin: Sending notification to: #freebsd-commits
> 
> .. do you have a fix for this? Or if you don't, would you mind backing
> things out until you've come up with a solution?

My suggested fix is to use the sys.mk etc from head

make -m .../share/mk buildworld 

or the patch that craig suggested will avoid the above error, though not
sure that things will build if you don't use head's share/mk/
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r284345 - in head: . bin/cat bin/chflags bin/chio bin/chmod bin/cp bin/csh bin/date bin/dd bin/df bin/domainname bin/echo bin/ed bin/expr bin/freebsd-version bin/getfacl bin/hostname b

[Simon J. Gerraty]

Garrett Cooper  wrote:

> Breaking source upgrades to later versions is painful. We want to make
> sure fmake at least works with upgrade_checks so people can upgrade
> from earlier versions of 8/9/10 to 11 without having to deal with a
> lot of pain.

I agree but 8 -> 11 is a very big jump.
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r284345 - in head: . bin/cat bin/chflags bin/chio bin/chmod bin/cp bin/csh bin/date bin/dd bin/df bin/domainname bin/echo bin/ed bin/expr bin/freebsd-version bin/getfacl bin/hostname b

[Oliver Pinter]

On 6/15/15, Simon J. Gerraty  wrote:
> Garrett Cooper  wrote:
>
>> Breaking source upgrades to later versions is painful. We want to make
>> sure fmake at least works with upgrade_checks so people can upgrade
>> from earlier versions of 8/9/10 to 11 without having to deal with a
>> lot of pain.
>
> I agree but 8 -> 11 is a very big jump.

Simon, how can I update these dependency files? Is there any exact
command or make target or something magic-tool?

> ___
> svn-src-h...@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"
>
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r284393 - head/sys/netinet

[Michael Tuexen]

Author: tuexen
Date: Sun Jun 14 22:14:00 2015
New Revision: 284393
URL: https://svnweb.freebsd.org/changeset/base/284393

Log:
  Correctly detect the case where the last address is removed.
  
  MFC after: 3 days

Modified:
  head/sys/netinet/sctp_asconf.c

Modified: head/sys/netinet/sctp_asconf.c
==
--- head/sys/netinet/sctp_asconf.c  Sun Jun 14 21:50:38 2015
(r284392)
+++ head/sys/netinet/sctp_asconf.c  Sun Jun 14 22:14:00 2015
(r284393)
@@ -1328,6 +1328,7 @@ sctp_asconf_queue_add(struct sctp_tcb *s
 {
uint32_t status;
int pending_delete_queued = 0;
+   int last;
 
/* see if peer supports ASCONF */
if (stcb->asoc.asconf_supported == 0) {
@@ -1337,15 +1338,21 @@ sctp_asconf_queue_add(struct sctp_tcb *s
 * if this is deleting the last address from the assoc, mark it as
 * pending.
 */
-   if ((type == SCTP_DEL_IP_ADDRESS) && !stcb->asoc.asconf_del_pending &&
-   (sctp_local_addr_count(stcb) < 2)) {
-   /* set the pending delete info only */
-   stcb->asoc.asconf_del_pending = 1;
-   stcb->asoc.asconf_addr_del_pending = ifa;
-   atomic_add_int(&ifa->refcount, 1);
-   SCTPDBG(SCTP_DEBUG_ASCONF2,
-   "asconf_queue_add: mark delete last address pending\n");
-   return (-1);
+   if ((type == SCTP_DEL_IP_ADDRESS) && !stcb->asoc.asconf_del_pending) {
+   if (stcb->sctp_ep->sctp_flags & SCTP_PCB_FLAGS_BOUNDALL) {
+   last = (sctp_local_addr_count(stcb) == 0);
+   } else {
+   last = (sctp_local_addr_count(stcb) == 1);
+   }
+   if (last) {
+   /* set the pending delete info only */
+   stcb->asoc.asconf_del_pending = 1;
+   stcb->asoc.asconf_addr_del_pending = ifa;
+   atomic_add_int(&ifa->refcount, 1);
+   SCTPDBG(SCTP_DEBUG_ASCONF2,
+   "asconf_queue_add: mark delete last address 
pending\n");
+   return (-1);
+   }
}
/* queue an asconf parameter */
status = sctp_asconf_queue_mgmt(stcb, ifa, type);
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r284345 - in head: . bin/cat bin/chflags bin/chio bin/chmod bin/cp bin/csh bin/date bin/dd bin/df bin/domainname bin/echo bin/ed bin/expr bin/freebsd-version bin/getfacl bin/hostname b

[Simon J. Gerraty]

Dimitry Andric  wrote:
> Some questions about this commit, which I'm sure more people must have:

Sure, good questions and as you say, many likely thinking the same.

> * Was it really necessary to commit hundreds of clearly generated files?

Short answer is "yes" - since they are actually what makes the build
work.

> * Couldn't these be generated on the fly, or with some "make depend" like 
> command?

The whole point is to avoid that overhead.

> * How to update these files, if you change anything in the 'real' Makefiles?

For now don't worry about it, those of us that want to build/play with
meta mode will take care of updating them.

Simply building in meta mode is all that is needed to update them.

> * Or are you now the maintainer of these .depend files? :-)

For now, yes.  
I think that's the only reasonable approach at this early stage.

Thanks
--sjg

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

Re: svn commit: r284345 - in head: . bin/cat bin/chflags bin/chio bin/chmod bin/cp bin/csh bin/date bin/dd bin/df bin/domainname bin/echo bin/ed bin/expr bin/freebsd-version bin/getfacl bin/hostname b

[Garrett Cooper]

> On Jun 14, 2015, at 15:00, Simon J. Gerraty  wrote:
> 
> Garrett Cooper  wrote:
> 
>> Breaking source upgrades to later versions is painful. We want to make
>> sure fmake at least works with upgrade_checks so people can upgrade
>> from earlier versions of 8/9/10 to 11 without having to deal with a
>> lot of pain.
> 
> I agree but 8 -> 11 is a very big jump.

Yes. BOOTSTRAPPING in Makefile.inc1 implies that. Let's try and honor that as 
best possible.
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r284345 - in head: . bin/cat bin/chflags bin/chio bin/chmod bin/cp bin/csh bin/date bin/dd bin/df bin/domainname bin/echo bin/ed bin/expr bin/freebsd-version bin/getfacl bin/hostname b

[Oliver Pinter]

On 6/14/15, Simon J. Gerraty  wrote:
> Dimitry Andric  wrote:
>> Some questions about this commit, which I'm sure more people must have:
>
> Sure, good questions and as you say, many likely thinking the same.
>
>> * Was it really necessary to commit hundreds of clearly generated files?
>
> Short answer is "yes" - since they are actually what makes the build
> work.
>
>> * Couldn't these be generated on the fly, or with some "make depend" like
>> command?
>
> The whole point is to avoid that overhead.
>
>> * How to update these files, if you change anything in the 'real'
>> Makefiles?
>
> For now don't worry about it, those of us that want to build/play with
> meta mode will take care of updating them.
>
> Simply building in meta mode is all that is needed to update them.
>
>> * Or are you now the maintainer of these .depend files? :-)
>
> For now, yes.
> I think that's the only reasonable approach at this early stage.

Cool! What is you github account? I like to add your access to our
repo, and please fix this issue:
http://jenkins.hardenedbsd.org:8180/jenkins/job/HardenedBSD-master-amd64/133/consoleFull
>
> Thanks
> --sjg
>
> ___
> svn-src-h...@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"
>
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r284345 - in head: . bin/cat bin/chflags bin/chio bin/chmod bin/cp bin/csh bin/date bin/dd bin/df bin/domainname bin/echo bin/ed bin/expr bin/freebsd-version bin/getfacl bin/hostname b

[Baptiste Daroussin]

On Mon, Jun 15, 2015 at 12:06:15AM +0200, Oliver Pinter wrote:
> On 6/15/15, Simon J. Gerraty  wrote:
> > Garrett Cooper  wrote:
> >
> >> Breaking source upgrades to later versions is painful. We want to make
> >> sure fmake at least works with upgrade_checks so people can upgrade
> >> from earlier versions of 8/9/10 to 11 without having to deal with a
> >> lot of pain.
> >
> > I agree but 8 -> 11 is a very big jump.
> 
> Simon, how can I update these dependency files? Is there any exact
> command or make target or something magic-tool?

isn't bmake in the bootstrap tools?, it should just work as long as anything to
get into the point of having a bootstrapped bmake is fmake compatible.

Also note that bmake is available 9.3 and 8.4 will be EOLed in 15 days, also
bmake is avilable on all version via ports pkg install bmake then you can use it
to build the source.

Best regards,
Bapt


pgpHiokxoeDAM.pgp
Description: PGP signature

svn commit: r284394 - head

[Craig Rodrigues]

Author: rodrigc
Date: Sun Jun 14 22:36:27 2015
New Revision: 284394
URL: https://svnweb.freebsd.org/changeset/base/284394

Log:
  If MK_META_MODE is unset, assume a value of no.
  
  This is needed to build HEAD on FreeBSD 10.1,
  which has bmake, but does not have
  /usr/share/mk/src.opts.mk
  
  Reviewed by: sjg
  Reported by: jenkins

Modified:
  head/Makefile

Modified: head/Makefile
==
--- head/Makefile   Sun Jun 14 22:14:00 2015(r284393)
+++ head/Makefile   Sun Jun 14 22:36:27 2015(r284394)
@@ -99,7 +99,7 @@
 #
 # For more information, see the build(7) manual page.
 #
-.if ${MK_META_MODE} == "yes"
+.if ${MK_META_MODE:Uno} == "yes"
 # targets/Makefile plays the role of top-level
 .include "targets/Makefile"
 .else
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r284345 - in head: . bin/cat bin/chflags bin/chio bin/chmod bin/cp bin/csh bin/date bin/dd bin/df bin/domainname bin/echo bin/ed bin/expr bin/freebsd-version bin/getfacl bin/hostname b

[Adrian Chadd]

Hi,

I'm happy for this to be your baby and see how it all pans out in the
tree, but I thought we as a project learnt some lessons about checking
in autogenerated files.




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

Re: svn commit: r284345 - in head: . bin/cat bin/chflags bin/chio bin/chmod bin/cp bin/csh bin/date bin/dd bin/df bin/domainname bin/echo bin/ed bin/expr bin/freebsd-version bin/getfacl bin/hostname b

[Craig Rodrigues]

On Sun, Jun 14, 2015 at 3:37 PM, Adrian Chadd  wrote:

> Hi,
>
> I'm happy for this to be your baby and see how it all pans out in the
> tree, but I thought we as a project learnt some lessons about checking
> in autogenerated files.
>
>

Well, I would like to give Simon the benefit of the doubt here.
When I worked at Juniper, I worked first with John Birrell on the
early jbuild prototype, and later with Simon on the bmake + meta-mode
work.

Simon gave this presentation + video on meta-mode at BSDCan 2014:
http://www.bsdcan.org/2014/schedule/track/Hacking/460.en.html

I gave this preso on jbuild at BSDCan 2010:
https://www.bsdcan.org/2010/schedule/events/198.en.html

Inside Juniper, there were concerns expressed about checking in
generated dependency files.  I'm seeing the same concerns expressed by
the FreeBSD community. :)

It turns out that checking in the dependency files was the right way to go.
This has been battle tested inside Juniper, and it does workI've seen
it.

It turns out that running a dependency generation step at the beginning
of the build takes a long time.  When you are building something
on the scale of an operating system, like FreeBSD, or
something even huger, like JUNOS, this takes a non-trivial amount of time,
and gets worse as the size of the code grows.

Checking in the dependencies allows you to do some pretty amazing
stuff with the build, especially when you start integrating manifests
and packaging of the base system.

Now I will agree with Adrian on a couple of points:

(1)  For the initial go around, if Simon babysits the Makefile.depend files
  in HEAD that would be OK.  They are turned off by default
  anyways.

(2)  In the long run, having better documentation, tooling and procedures to
  update the
  Makefile.depend files will be definitely needed.
  Using automation systems like Jenkins would definitely help,
  but that's not the only way to do things.

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

Re: svn commit: r284198 - head/bin/ls

[Adrian Chadd]

On 14 June 2015 at 12:02, Garrett Cooper  wrote:
>
>> On Jun 14, 2015, at 11:53, Adrian Chadd  wrote:
>>
>> We have busybox already - it's called bsdbox, and it's in base, and
>> we're already using it, and yes, it does pull in libxo. :)
>>
>> I'm not worried about the size increase of libxo. That's the wrong
>> thing to focus on. If it gets much more bloated then I'll poke people
>> with the big "what are you thinking" stick. The issues people have
>> aren't size related, they're "this API needs improvement and we have
>> bugs introduced into tools."
>>
>> I do like how zero percent of the comments are "hey, maybe we need
>> unit tests that run these tools and ensure they output the right
>> stuff." If this were ${WORK} and I were ${BOSS}, I'd have asked the
>> libxo developers to include unit tests before/after for each thing
>> they broke, so we don't have a repeat of this kind of thing. But, this
>> apparently isn't ${WORK} and I definitely don't want to be anyones
>> boss, so..
>
> Ugh. I'll write the tests ;(...

I'm not your boss!

(but if you go and do it - great! thankyou! This is what should've
been neckbearded, not the rest of the thread!)


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

Re: svn commit: r284198 - head/bin/ls

[Garrett Cooper]

> On Jun 14, 2015, at 12:07, Adrian Chadd  wrote:
> 
>> On 14 June 2015 at 12:02, Garrett Cooper  wrote:
>> 
>>> On Jun 14, 2015, at 11:53, Adrian Chadd  wrote:
>>> 
>>> We have busybox already - it's called bsdbox, and it's in base, and
>>> we're already using it, and yes, it does pull in libxo. :)
>>> 
>>> I'm not worried about the size increase of libxo. That's the wrong
>>> thing to focus on. If it gets much more bloated then I'll poke people
>>> with the big "what are you thinking" stick. The issues people have
>>> aren't size related, they're "this API needs improvement and we have
>>> bugs introduced into tools."
>>> 
>>> I do like how zero percent of the comments are "hey, maybe we need
>>> unit tests that run these tools and ensure they output the right
>>> stuff." If this were ${WORK} and I were ${BOSS}, I'd have asked the
>>> libxo developers to include unit tests before/after for each thing
>>> they broke, so we don't have a repeat of this kind of thing. But, this
>>> apparently isn't ${WORK} and I definitely don't want to be anyones
>>> boss, so..
>> 
>> Ugh. I'll write the tests ;(...
> 
> I'm not your boss!
> 
> (but if you go and do it - great! thankyou! This is what should've
> been neckbearded, not the rest of the thread!)

A part of it, yeah.. Not having manpqges still makes it annoying when I have to 
figure out how things work ;(.

Next time someone else converts ANYTHING to libxo -- write tests FIRST to make 
sure you're not breaking legacy behavior. If you need help figuring out how to 
do that, I'll be more than happy to document it on a wiki page, with simple, 
concise directions.

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

Re: svn commit: r284345 - in head: . bin/cat bin/chflags bin/chio bin/chmod bin/cp bin/csh bin/date bin/dd bin/df bin/domainname bin/echo bin/ed bin/expr bin/freebsd-version bin/getfacl bin/hostname b

[Simon J. Gerraty]

Adrian Chadd  wrote:

> Wait a second - y'all committed a bunch of dependencies that we aren't
> supposed to edit directly?

Yes ;-)
If building using the normal buildworld etc you can ignore them.

> So what's the process for making sure we don't stomp over the feet of
> other people who are using the depend based builds?

Don't worry about it.
They will pretty much self repair.
I've had a lot of practice lately bootstrapping them for netbsd and
freebsd ;-)


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

Re: svn commit: r284345 - in head: . bin/cat bin/chflags bin/chio bin/chmod bin/cp bin/csh bin/date bin/dd bin/df bin/domainname bin/echo bin/ed bin/expr bin/freebsd-version bin/getfacl bin/hostname b

[Adrian Chadd]

On 14 June 2015 at 14:56, Simon J. Gerraty  wrote:
> Adrian Chadd  wrote:
>
>> Wait a second - y'all committed a bunch of dependencies that we aren't
>> supposed to edit directly?
>
> Yes ;-)
> If building using the normal buildworld etc you can ignore them.

Cool.

>> So what's the process for making sure we don't stomp over the feet of
>> other people who are using the depend based builds?
>
> Don't worry about it.
> They will pretty much self repair.
> I've had a lot of practice lately bootstrapping them for netbsd and
> freebsd ;-)

Cool. :)

Ok, let's see what happens..


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

Re: svn commit: r284370 - head/usr.bin/kdump

[Simon J. Gerraty]

Dimitry Andric  wrote:
> >  head/usr.bin/kdump/Makefile
> 
> Is this supposed to fix things?  Even at r284381, I get:

I did for me ...

> 
> ===> usr.bin/kdump (depend)
> sh /usr/src/usr.bin/kdump/mksubr /usr/obj/usr/src/tmp/usr/include 
> >kdump_subr.c
> env MACHINE=i386 CPP="cpp "  sh /usr/src/usr.bin/kdump/mkioctls print 
> /usr/obj/usr/src/tmp/usr/include > ioctl.c
> :1:10: fatal error: 'cam/cam_compat.h' file not found
> #include 
>  ^
> 1 error generated.

Yes I saw that too (before these changes IIRC) it appeared to be ignored.

> rm -f .depend
> CC='cc  ' mkdep -f .depend -a-I/usr/src/usr.bin/kdump/../ktrace 
> -I/usr/src/usr.bin/kdump -I/usr/src/usr.bin/kdump/../.. -I. 
> -DHAVE_LIBCAPSICUM -DPF -std=gnu99   kdump_subr.c 
> /usr/src/usr.bin/kdump/kdump.c ioctl.c /usr/src/usr.bin/kdump/../ktrace/subr.c
> /usr/src/usr.bin/kdump/kdump.c:153:10: fatal error: 'linux_syscalls.c' file 
> not found

That's why I added the explicit target.

> #include 
>  ^
> 1 error generated.
> mkdep: compile failed

Ah, they likely need to be hooked to beforedepend.
My flight is boarding, will look when I get back on line.

Sorry for the hiccup

> Any idea?  I obviously do not see any linux_syscalls.c in the objdir.
> 
> -Dimitry
> 
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r284396 - vendor/tzdata/tzdata2015e

[Edwin Groothuis]

Author: edwin
Date: Mon Jun 15 00:55:03 2015
New Revision: 284396
URL: https://svnweb.freebsd.org/changeset/base/284396

Log:
  Tag of tzdata 2015e

Added:
 - copied from r284395, vendor/tzdata/dist/
Directory Properties:
  vendor/tzdata/tzdata2015e/   (props changed)
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r284395 - vendor/tzdata/dist

[Edwin Groothuis]

Author: edwin
Date: Mon Jun 15 00:54:52 2015
New Revision: 284395
URL: https://svnweb.freebsd.org/changeset/base/284395

Log:
  Vendor import of tzdata2015e:
  
  Update to tzdata2015e:
  
Changes affecting future time stamps
  
  Morocco will suspend DST from 2015-06-14 03:00 through 2015-07-19 02:00,
  not 06-13 and 07-18 as we had guessed.  (Thanks to Milamber.)
  
  Assume Cayman Islands will observe DST starting next year, using US rules.
  Although it isn't guaranteed, it is the most likely.
  
  Obtained from: ftp://ftp.iana.org/tz/releases/

Modified:
  vendor/tzdata/dist/africa
  vendor/tzdata/dist/iso3166.tab
  vendor/tzdata/dist/northamerica
  vendor/tzdata/dist/southamerica
  vendor/tzdata/dist/zone1970.tab

Modified: vendor/tzdata/dist/africa
==
--- vendor/tzdata/dist/africa   Sun Jun 14 22:36:27 2015(r284394)
+++ vendor/tzdata/dist/africa   Mon Jun 15 00:54:52 2015(r284395)
@@ -338,9 +338,10 @@ Rule   Egypt   2007only-   Sep Thu>=1  
24:00   
 # time this summer, and carry out studies on the possibility of canceling the
 # practice altogether in future years."
 #
-# From Paul Eggert (2015-04-20):
-# For now, assume DST will be canceled.  Any resumption would likely
-# use different rules anyway.
+# From Paul Eggert (2015-04-24):
+# Yesterday the office of Egyptian President El-Sisi announced his
+# decision to abandon DST permanently.  See Ahram Online 2015-04-24.
+# 
http://english.ahram.org.eg/NewsContent/1/64/128509/Egypt/Politics-/Sisi-cancels-daylight-saving-time-in-Egypt.aspx
 
 Rule   Egypt   2008only-   Aug lastThu 24:00   0   -
 Rule   Egypt   2009only-   Aug 20  24:00   0   -
@@ -787,20 +788,41 @@ Zone Indian/Mauritius 3:50:00 -   LMT 1907
 # will resume again at 02:00 on Saturday, August 2, 2014
 # http://www.mmsp.gov.ma/fr/actualites.aspx?id=586
 
-# From Paul Eggert (2014-06-05):
-# For now, guess that later spring and fall transitions will use 2014's rules,
+# From Milamber (2015-06-08):
+# (Google Translation) The hour will thus be delayed 60 minutes
+# Sunday, June 14 at 3:00, the ministry said in a statement, adding
+# that the time will be advanced again 60 minutes Sunday, July 19,
+# 2015 at 2:00.  The move comes under 2.12.126 Decree of 26 Jumada I
+# 1433 (18 April 2012) and the decision of the Head of Government of
+# 16 N. 3-29-15 Chaaban 1435 (4 June 2015).
+# Source (french):
+# http://lnt.ma/le-maroc-reculera-dune-heure-le-dimanche-14-juin/
+#
+# From Milamber (2015-06-09):
+# http://www.mmsp.gov.ma/fr/actualites.aspx?id=863
+#
+# From Michael Deckers (2015-06-09):
+# [The gov.ma announcement] would (probably) make the switch on 2015-07-19 go
+# from 03:00 to 04:00 rather than from 02:00 to 03:00, as in the patch
+# I think the patch is correct and the quoted text is wrong; the text in
+#  agrees
+# with the patch.
+
+# From Paul Eggert (2015-06-08):
+# For now, guess that later spring and fall transitions will use 2015's rules,
 # and guess that Morocco will switch to standard time at 03:00 the last
-# Saturday before Ramadan, and back to DST at 02:00 the first Saturday after
-# Ramadan.  To implement this, transition dates for 2015 through 2037 were
+# Sunday before Ramadan, and back to DST at 02:00 the first Sunday after
+# Ramadan.  To implement this, transition dates for 2016 through 2037 were
 # determined by running the following program under GNU Emacs 24.3, with the
 # results integrated by hand into the table below.
-# (let ((islamic-year 1436))
+# (let ((islamic-year 1437))
+#   (require 'cal-islam)
 #   (while (< islamic-year 1460)
 # (let ((a (calendar-islamic-to-absolute (list 9 1 islamic-year)))
 #   (b (calendar-islamic-to-absolute (list 10 1 islamic-year)))
-#   (saturday 6))
-#   (while (/= saturday (mod (setq a (1- a)) 7)))
-#   (while (/= saturday (mod b 7))
+#   (sunday 0))
+#   (while (/= sunday (mod (setq a (1- a)) 7)))
+#   (while (/= sunday (mod b 7))
 # (setq b (1+ b)))
 #   (setq a (calendar-gregorian-from-absolute a))
 #   (setq b (calendar-gregorian-from-absolute b))
@@ -844,32 +866,30 @@ Rule  Morocco 2012only-   Aug 20  
 2:00   1:
 Rule   Morocco 2013only-   Jul  7   3:00   0   -
 Rule   Morocco 2013only-   Aug 10   2:00   1:00S
 Rule   Morocco 2013max -   Oct lastSun  3:00   0   -
-Rule   Morocco 20142022-   Mar lastSun  2:00   1:00S
+Rule   Morocco 20142021-   Mar lastSun  2:00   1:00S
 Rule   Morocco 2014only-   Jun 28   3:00   0   -
 Rule   Morocco 2014only-   Aug  2   2:00   1:00S
-Rule   Morocco 2015only-   Jun 13   3:

svn commit: r284397 - head/contrib/tzdata

[Edwin Groothuis]

Author: edwin
Date: Mon Jun 15 00:59:47 2015
New Revision: 284397
URL: https://svnweb.freebsd.org/changeset/base/284397

Log:
  MFV of 284395,tzdata2015e
  
  Update to tzdata2015e:
  
Changes affecting future time stamps
  
  Morocco will suspend DST from 2015-06-14 03:00 through 2015-07-19 02:00,
  not 06-13 and 07-18 as we had guessed.  (Thanks to Milamber.)
  
  Assume Cayman Islands will observe DST starting next year, using US rules.
  Although it isn't guaranteed, it is the most likely.

Modified:
  head/contrib/tzdata/africa
  head/contrib/tzdata/northamerica
  head/contrib/tzdata/southamerica
  head/contrib/tzdata/zone1970.tab
Directory Properties:
  head/contrib/tzdata/   (props changed)

Modified: head/contrib/tzdata/africa
==
--- head/contrib/tzdata/africa  Mon Jun 15 00:55:03 2015(r284396)
+++ head/contrib/tzdata/africa  Mon Jun 15 00:59:47 2015(r284397)
@@ -338,9 +338,10 @@ Rule   Egypt   2007only-   Sep Thu>=1  
24:00   
 # time this summer, and carry out studies on the possibility of canceling the
 # practice altogether in future years."
 #
-# From Paul Eggert (2015-04-20):
-# For now, assume DST will be canceled.  Any resumption would likely
-# use different rules anyway.
+# From Paul Eggert (2015-04-24):
+# Yesterday the office of Egyptian President El-Sisi announced his
+# decision to abandon DST permanently.  See Ahram Online 2015-04-24.
+# 
http://english.ahram.org.eg/NewsContent/1/64/128509/Egypt/Politics-/Sisi-cancels-daylight-saving-time-in-Egypt.aspx
 
 Rule   Egypt   2008only-   Aug lastThu 24:00   0   -
 Rule   Egypt   2009only-   Aug 20  24:00   0   -
@@ -787,20 +788,41 @@ Zone Indian/Mauritius 3:50:00 -   LMT 1907
 # will resume again at 02:00 on Saturday, August 2, 2014
 # http://www.mmsp.gov.ma/fr/actualites.aspx?id=586
 
-# From Paul Eggert (2014-06-05):
-# For now, guess that later spring and fall transitions will use 2014's rules,
+# From Milamber (2015-06-08):
+# (Google Translation) The hour will thus be delayed 60 minutes
+# Sunday, June 14 at 3:00, the ministry said in a statement, adding
+# that the time will be advanced again 60 minutes Sunday, July 19,
+# 2015 at 2:00.  The move comes under 2.12.126 Decree of 26 Jumada I
+# 1433 (18 April 2012) and the decision of the Head of Government of
+# 16 N. 3-29-15 Chaaban 1435 (4 June 2015).
+# Source (french):
+# http://lnt.ma/le-maroc-reculera-dune-heure-le-dimanche-14-juin/
+#
+# From Milamber (2015-06-09):
+# http://www.mmsp.gov.ma/fr/actualites.aspx?id=863
+#
+# From Michael Deckers (2015-06-09):
+# [The gov.ma announcement] would (probably) make the switch on 2015-07-19 go
+# from 03:00 to 04:00 rather than from 02:00 to 03:00, as in the patch
+# I think the patch is correct and the quoted text is wrong; the text in
+#  agrees
+# with the patch.
+
+# From Paul Eggert (2015-06-08):
+# For now, guess that later spring and fall transitions will use 2015's rules,
 # and guess that Morocco will switch to standard time at 03:00 the last
-# Saturday before Ramadan, and back to DST at 02:00 the first Saturday after
-# Ramadan.  To implement this, transition dates for 2015 through 2037 were
+# Sunday before Ramadan, and back to DST at 02:00 the first Sunday after
+# Ramadan.  To implement this, transition dates for 2016 through 2037 were
 # determined by running the following program under GNU Emacs 24.3, with the
 # results integrated by hand into the table below.
-# (let ((islamic-year 1436))
+# (let ((islamic-year 1437))
+#   (require 'cal-islam)
 #   (while (< islamic-year 1460)
 # (let ((a (calendar-islamic-to-absolute (list 9 1 islamic-year)))
 #   (b (calendar-islamic-to-absolute (list 10 1 islamic-year)))
-#   (saturday 6))
-#   (while (/= saturday (mod (setq a (1- a)) 7)))
-#   (while (/= saturday (mod b 7))
+#   (sunday 0))
+#   (while (/= sunday (mod (setq a (1- a)) 7)))
+#   (while (/= sunday (mod b 7))
 # (setq b (1+ b)))
 #   (setq a (calendar-gregorian-from-absolute a))
 #   (setq b (calendar-gregorian-from-absolute b))
@@ -844,32 +866,30 @@ Rule  Morocco 2012only-   Aug 20  
 2:00   1:
 Rule   Morocco 2013only-   Jul  7   3:00   0   -
 Rule   Morocco 2013only-   Aug 10   2:00   1:00S
 Rule   Morocco 2013max -   Oct lastSun  3:00   0   -
-Rule   Morocco 20142022-   Mar lastSun  2:00   1:00S
+Rule   Morocco 20142021-   Mar lastSun  2:00   1:00S
 Rule   Morocco 2014only-   Jun 28   3:00   0   -
 Rule   Morocco 2014only-   Aug  2   2:00   1:00S
-Rule   Morocco 2015only-   Jun 13   3:00   0   -
-Rule 

svn commit: r284398 - stable/10/contrib/tzdata

[Edwin Groothuis]

Author: edwin
Date: Mon Jun 15 01:01:25 2015
New Revision: 284398
URL: https://svnweb.freebsd.org/changeset/base/284398

Log:
  MFC of 284397,tzdata10:
  
  Update to tzdata2015e:
  
Changes affecting future time stamps
  
  Morocco will suspend DST from 2015-06-14 03:00 through 2015-07-19 02:00,
  not 06-13 and 07-18 as we had guessed.  (Thanks to Milamber.)
  
  Assume Cayman Islands will observe DST starting next year, using US rules.
  Although it isn't guaranteed, it is the most likely.

Modified:
  stable/10/contrib/tzdata/africa
  stable/10/contrib/tzdata/northamerica
  stable/10/contrib/tzdata/southamerica
  stable/10/contrib/tzdata/zone1970.tab

Modified: stable/10/contrib/tzdata/africa
==
--- stable/10/contrib/tzdata/africa Mon Jun 15 00:59:47 2015
(r284397)
+++ stable/10/contrib/tzdata/africa Mon Jun 15 01:01:25 2015
(r284398)
@@ -338,9 +338,10 @@ Rule   Egypt   2007only-   Sep Thu>=1  
24:00   
 # time this summer, and carry out studies on the possibility of canceling the
 # practice altogether in future years."
 #
-# From Paul Eggert (2015-04-20):
-# For now, assume DST will be canceled.  Any resumption would likely
-# use different rules anyway.
+# From Paul Eggert (2015-04-24):
+# Yesterday the office of Egyptian President El-Sisi announced his
+# decision to abandon DST permanently.  See Ahram Online 2015-04-24.
+# 
http://english.ahram.org.eg/NewsContent/1/64/128509/Egypt/Politics-/Sisi-cancels-daylight-saving-time-in-Egypt.aspx
 
 Rule   Egypt   2008only-   Aug lastThu 24:00   0   -
 Rule   Egypt   2009only-   Aug 20  24:00   0   -
@@ -787,20 +788,41 @@ Zone Indian/Mauritius 3:50:00 -   LMT 1907
 # will resume again at 02:00 on Saturday, August 2, 2014
 # http://www.mmsp.gov.ma/fr/actualites.aspx?id=586
 
-# From Paul Eggert (2014-06-05):
-# For now, guess that later spring and fall transitions will use 2014's rules,
+# From Milamber (2015-06-08):
+# (Google Translation) The hour will thus be delayed 60 minutes
+# Sunday, June 14 at 3:00, the ministry said in a statement, adding
+# that the time will be advanced again 60 minutes Sunday, July 19,
+# 2015 at 2:00.  The move comes under 2.12.126 Decree of 26 Jumada I
+# 1433 (18 April 2012) and the decision of the Head of Government of
+# 16 N. 3-29-15 Chaaban 1435 (4 June 2015).
+# Source (french):
+# http://lnt.ma/le-maroc-reculera-dune-heure-le-dimanche-14-juin/
+#
+# From Milamber (2015-06-09):
+# http://www.mmsp.gov.ma/fr/actualites.aspx?id=863
+#
+# From Michael Deckers (2015-06-09):
+# [The gov.ma announcement] would (probably) make the switch on 2015-07-19 go
+# from 03:00 to 04:00 rather than from 02:00 to 03:00, as in the patch
+# I think the patch is correct and the quoted text is wrong; the text in
+#  agrees
+# with the patch.
+
+# From Paul Eggert (2015-06-08):
+# For now, guess that later spring and fall transitions will use 2015's rules,
 # and guess that Morocco will switch to standard time at 03:00 the last
-# Saturday before Ramadan, and back to DST at 02:00 the first Saturday after
-# Ramadan.  To implement this, transition dates for 2015 through 2037 were
+# Sunday before Ramadan, and back to DST at 02:00 the first Sunday after
+# Ramadan.  To implement this, transition dates for 2016 through 2037 were
 # determined by running the following program under GNU Emacs 24.3, with the
 # results integrated by hand into the table below.
-# (let ((islamic-year 1436))
+# (let ((islamic-year 1437))
+#   (require 'cal-islam)
 #   (while (< islamic-year 1460)
 # (let ((a (calendar-islamic-to-absolute (list 9 1 islamic-year)))
 #   (b (calendar-islamic-to-absolute (list 10 1 islamic-year)))
-#   (saturday 6))
-#   (while (/= saturday (mod (setq a (1- a)) 7)))
-#   (while (/= saturday (mod b 7))
+#   (sunday 0))
+#   (while (/= sunday (mod (setq a (1- a)) 7)))
+#   (while (/= sunday (mod b 7))
 # (setq b (1+ b)))
 #   (setq a (calendar-gregorian-from-absolute a))
 #   (setq b (calendar-gregorian-from-absolute b))
@@ -844,32 +866,30 @@ Rule  Morocco 2012only-   Aug 20  
 2:00   1:
 Rule   Morocco 2013only-   Jul  7   3:00   0   -
 Rule   Morocco 2013only-   Aug 10   2:00   1:00S
 Rule   Morocco 2013max -   Oct lastSun  3:00   0   -
-Rule   Morocco 20142022-   Mar lastSun  2:00   1:00S
+Rule   Morocco 20142021-   Mar lastSun  2:00   1:00S
 Rule   Morocco 2014only-   Jun 28   3:00   0   -
 Rule   Morocco 2014only-   Aug  2   2:00   1:00S
-Rule   Morocco 2015only-   Jun 13   3:00   0   -
-Rule   Morocco 2015only

svn commit: r284399 - stable/9/contrib/tzdata

[Edwin Groothuis]

Author: edwin
Date: Mon Jun 15 01:02:10 2015
New Revision: 284399
URL: https://svnweb.freebsd.org/changeset/base/284399

Log:
  MFC of 284397,tzdata9:
  
  Update to tzdata2015e:
  
Changes affecting future time stamps
  
  Morocco will suspend DST from 2015-06-14 03:00 through 2015-07-19 02:00,
  not 06-13 and 07-18 as we had guessed.  (Thanks to Milamber.)
  
  Assume Cayman Islands will observe DST starting next year, using US rules.
  Although it isn't guaranteed, it is the most likely.

Modified:
  stable/9/contrib/tzdata/africa
  stable/9/contrib/tzdata/northamerica
  stable/9/contrib/tzdata/southamerica
  stable/9/contrib/tzdata/zone1970.tab
Directory Properties:
  stable/9/contrib/tzdata/   (props changed)

Modified: stable/9/contrib/tzdata/africa
==
--- stable/9/contrib/tzdata/africa  Mon Jun 15 01:01:25 2015
(r284398)
+++ stable/9/contrib/tzdata/africa  Mon Jun 15 01:02:10 2015
(r284399)
@@ -338,9 +338,10 @@ Rule   Egypt   2007only-   Sep Thu>=1  
24:00   
 # time this summer, and carry out studies on the possibility of canceling the
 # practice altogether in future years."
 #
-# From Paul Eggert (2015-04-20):
-# For now, assume DST will be canceled.  Any resumption would likely
-# use different rules anyway.
+# From Paul Eggert (2015-04-24):
+# Yesterday the office of Egyptian President El-Sisi announced his
+# decision to abandon DST permanently.  See Ahram Online 2015-04-24.
+# 
http://english.ahram.org.eg/NewsContent/1/64/128509/Egypt/Politics-/Sisi-cancels-daylight-saving-time-in-Egypt.aspx
 
 Rule   Egypt   2008only-   Aug lastThu 24:00   0   -
 Rule   Egypt   2009only-   Aug 20  24:00   0   -
@@ -787,20 +788,41 @@ Zone Indian/Mauritius 3:50:00 -   LMT 1907
 # will resume again at 02:00 on Saturday, August 2, 2014
 # http://www.mmsp.gov.ma/fr/actualites.aspx?id=586
 
-# From Paul Eggert (2014-06-05):
-# For now, guess that later spring and fall transitions will use 2014's rules,
+# From Milamber (2015-06-08):
+# (Google Translation) The hour will thus be delayed 60 minutes
+# Sunday, June 14 at 3:00, the ministry said in a statement, adding
+# that the time will be advanced again 60 minutes Sunday, July 19,
+# 2015 at 2:00.  The move comes under 2.12.126 Decree of 26 Jumada I
+# 1433 (18 April 2012) and the decision of the Head of Government of
+# 16 N. 3-29-15 Chaaban 1435 (4 June 2015).
+# Source (french):
+# http://lnt.ma/le-maroc-reculera-dune-heure-le-dimanche-14-juin/
+#
+# From Milamber (2015-06-09):
+# http://www.mmsp.gov.ma/fr/actualites.aspx?id=863
+#
+# From Michael Deckers (2015-06-09):
+# [The gov.ma announcement] would (probably) make the switch on 2015-07-19 go
+# from 03:00 to 04:00 rather than from 02:00 to 03:00, as in the patch
+# I think the patch is correct and the quoted text is wrong; the text in
+#  agrees
+# with the patch.
+
+# From Paul Eggert (2015-06-08):
+# For now, guess that later spring and fall transitions will use 2015's rules,
 # and guess that Morocco will switch to standard time at 03:00 the last
-# Saturday before Ramadan, and back to DST at 02:00 the first Saturday after
-# Ramadan.  To implement this, transition dates for 2015 through 2037 were
+# Sunday before Ramadan, and back to DST at 02:00 the first Sunday after
+# Ramadan.  To implement this, transition dates for 2016 through 2037 were
 # determined by running the following program under GNU Emacs 24.3, with the
 # results integrated by hand into the table below.
-# (let ((islamic-year 1436))
+# (let ((islamic-year 1437))
+#   (require 'cal-islam)
 #   (while (< islamic-year 1460)
 # (let ((a (calendar-islamic-to-absolute (list 9 1 islamic-year)))
 #   (b (calendar-islamic-to-absolute (list 10 1 islamic-year)))
-#   (saturday 6))
-#   (while (/= saturday (mod (setq a (1- a)) 7)))
-#   (while (/= saturday (mod b 7))
+#   (sunday 0))
+#   (while (/= sunday (mod (setq a (1- a)) 7)))
+#   (while (/= sunday (mod b 7))
 # (setq b (1+ b)))
 #   (setq a (calendar-gregorian-from-absolute a))
 #   (setq b (calendar-gregorian-from-absolute b))
@@ -844,32 +866,30 @@ Rule  Morocco 2012only-   Aug 20  
 2:00   1:
 Rule   Morocco 2013only-   Jul  7   3:00   0   -
 Rule   Morocco 2013only-   Aug 10   2:00   1:00S
 Rule   Morocco 2013max -   Oct lastSun  3:00   0   -
-Rule   Morocco 20142022-   Mar lastSun  2:00   1:00S
+Rule   Morocco 20142021-   Mar lastSun  2:00   1:00S
 Rule   Morocco 2014only-   Jun 28   3:00   0   -
 Rule   Morocco 2014only-   Aug  2   2:00   1:00S
-Rule   Morocco 2015only-   J

svn commit: r284400 - stable/8/share/zoneinfo

[Edwin Groothuis]

Author: edwin
Date: Mon Jun 15 01:03:21 2015
New Revision: 284400
URL: https://svnweb.freebsd.org/changeset/base/284400

Log:
  MFC of 284397,tzdata8:
  
  Update to tzdata2015e:
  
Changes affecting future time stamps
  
  Morocco will suspend DST from 2015-06-14 03:00 through 2015-07-19 02:00,
  not 06-13 and 07-18 as we had guessed.  (Thanks to Milamber.)
  
  Assume Cayman Islands will observe DST starting next year, using US rules.
  Although it isn't guaranteed, it is the most likely.

Modified:
  stable/8/share/zoneinfo/africa
  stable/8/share/zoneinfo/northamerica
  stable/8/share/zoneinfo/southamerica
  stable/8/share/zoneinfo/zone1970.tab
Directory Properties:
  stable/8/share/zoneinfo/   (props changed)

Modified: stable/8/share/zoneinfo/africa
==
--- stable/8/share/zoneinfo/africa  Mon Jun 15 01:02:10 2015
(r284399)
+++ stable/8/share/zoneinfo/africa  Mon Jun 15 01:03:21 2015
(r284400)
@@ -338,9 +338,10 @@ Rule   Egypt   2007only-   Sep Thu>=1  
24:00   
 # time this summer, and carry out studies on the possibility of canceling the
 # practice altogether in future years."
 #
-# From Paul Eggert (2015-04-20):
-# For now, assume DST will be canceled.  Any resumption would likely
-# use different rules anyway.
+# From Paul Eggert (2015-04-24):
+# Yesterday the office of Egyptian President El-Sisi announced his
+# decision to abandon DST permanently.  See Ahram Online 2015-04-24.
+# 
http://english.ahram.org.eg/NewsContent/1/64/128509/Egypt/Politics-/Sisi-cancels-daylight-saving-time-in-Egypt.aspx
 
 Rule   Egypt   2008only-   Aug lastThu 24:00   0   -
 Rule   Egypt   2009only-   Aug 20  24:00   0   -
@@ -787,20 +788,41 @@ Zone Indian/Mauritius 3:50:00 -   LMT 1907
 # will resume again at 02:00 on Saturday, August 2, 2014
 # http://www.mmsp.gov.ma/fr/actualites.aspx?id=586
 
-# From Paul Eggert (2014-06-05):
-# For now, guess that later spring and fall transitions will use 2014's rules,
+# From Milamber (2015-06-08):
+# (Google Translation) The hour will thus be delayed 60 minutes
+# Sunday, June 14 at 3:00, the ministry said in a statement, adding
+# that the time will be advanced again 60 minutes Sunday, July 19,
+# 2015 at 2:00.  The move comes under 2.12.126 Decree of 26 Jumada I
+# 1433 (18 April 2012) and the decision of the Head of Government of
+# 16 N. 3-29-15 Chaaban 1435 (4 June 2015).
+# Source (french):
+# http://lnt.ma/le-maroc-reculera-dune-heure-le-dimanche-14-juin/
+#
+# From Milamber (2015-06-09):
+# http://www.mmsp.gov.ma/fr/actualites.aspx?id=863
+#
+# From Michael Deckers (2015-06-09):
+# [The gov.ma announcement] would (probably) make the switch on 2015-07-19 go
+# from 03:00 to 04:00 rather than from 02:00 to 03:00, as in the patch
+# I think the patch is correct and the quoted text is wrong; the text in
+#  agrees
+# with the patch.
+
+# From Paul Eggert (2015-06-08):
+# For now, guess that later spring and fall transitions will use 2015's rules,
 # and guess that Morocco will switch to standard time at 03:00 the last
-# Saturday before Ramadan, and back to DST at 02:00 the first Saturday after
-# Ramadan.  To implement this, transition dates for 2015 through 2037 were
+# Sunday before Ramadan, and back to DST at 02:00 the first Sunday after
+# Ramadan.  To implement this, transition dates for 2016 through 2037 were
 # determined by running the following program under GNU Emacs 24.3, with the
 # results integrated by hand into the table below.
-# (let ((islamic-year 1436))
+# (let ((islamic-year 1437))
+#   (require 'cal-islam)
 #   (while (< islamic-year 1460)
 # (let ((a (calendar-islamic-to-absolute (list 9 1 islamic-year)))
 #   (b (calendar-islamic-to-absolute (list 10 1 islamic-year)))
-#   (saturday 6))
-#   (while (/= saturday (mod (setq a (1- a)) 7)))
-#   (while (/= saturday (mod b 7))
+#   (sunday 0))
+#   (while (/= sunday (mod (setq a (1- a)) 7)))
+#   (while (/= sunday (mod b 7))
 # (setq b (1+ b)))
 #   (setq a (calendar-gregorian-from-absolute a))
 #   (setq b (calendar-gregorian-from-absolute b))
@@ -844,32 +866,30 @@ Rule  Morocco 2012only-   Aug 20  
 2:00   1:
 Rule   Morocco 2013only-   Jul  7   3:00   0   -
 Rule   Morocco 2013only-   Aug 10   2:00   1:00S
 Rule   Morocco 2013max -   Oct lastSun  3:00   0   -
-Rule   Morocco 20142022-   Mar lastSun  2:00   1:00S
+Rule   Morocco 20142021-   Mar lastSun  2:00   1:00S
 Rule   Morocco 2014only-   Jun 28   3:00   0   -
 Rule   Morocco 2014only-   Aug  2   2:00   1:00S
-Rule   Morocco 2015only-   J

svn commit: r284402 - stable/6/share/zoneinfo

[Edwin Groothuis]

Author: edwin
Date: Mon Jun 15 01:04:01 2015
New Revision: 284402
URL: https://svnweb.freebsd.org/changeset/base/284402

Log:
  MFC of 284397,tzdata6:
  
  Update to tzdata2015e:
  
Changes affecting future time stamps
  
  Morocco will suspend DST from 2015-06-14 03:00 through 2015-07-19 02:00,
  not 06-13 and 07-18 as we had guessed.  (Thanks to Milamber.)
  
  Assume Cayman Islands will observe DST starting next year, using US rules.
  Although it isn't guaranteed, it is the most likely.

Modified:
  stable/6/share/zoneinfo/africa
  stable/6/share/zoneinfo/northamerica
  stable/6/share/zoneinfo/southamerica
  stable/6/share/zoneinfo/zone1970.tab
Directory Properties:
  stable/6/share/zoneinfo/   (props changed)

Modified: stable/6/share/zoneinfo/africa
==
--- stable/6/share/zoneinfo/africa  Mon Jun 15 01:03:40 2015
(r284401)
+++ stable/6/share/zoneinfo/africa  Mon Jun 15 01:04:01 2015
(r284402)
@@ -338,9 +338,10 @@ Rule   Egypt   2007only-   Sep Thu>=1  
24:00   
 # time this summer, and carry out studies on the possibility of canceling the
 # practice altogether in future years."
 #
-# From Paul Eggert (2015-04-20):
-# For now, assume DST will be canceled.  Any resumption would likely
-# use different rules anyway.
+# From Paul Eggert (2015-04-24):
+# Yesterday the office of Egyptian President El-Sisi announced his
+# decision to abandon DST permanently.  See Ahram Online 2015-04-24.
+# 
http://english.ahram.org.eg/NewsContent/1/64/128509/Egypt/Politics-/Sisi-cancels-daylight-saving-time-in-Egypt.aspx
 
 Rule   Egypt   2008only-   Aug lastThu 24:00   0   -
 Rule   Egypt   2009only-   Aug 20  24:00   0   -
@@ -787,20 +788,41 @@ Zone Indian/Mauritius 3:50:00 -   LMT 1907
 # will resume again at 02:00 on Saturday, August 2, 2014
 # http://www.mmsp.gov.ma/fr/actualites.aspx?id=586
 
-# From Paul Eggert (2014-06-05):
-# For now, guess that later spring and fall transitions will use 2014's rules,
+# From Milamber (2015-06-08):
+# (Google Translation) The hour will thus be delayed 60 minutes
+# Sunday, June 14 at 3:00, the ministry said in a statement, adding
+# that the time will be advanced again 60 minutes Sunday, July 19,
+# 2015 at 2:00.  The move comes under 2.12.126 Decree of 26 Jumada I
+# 1433 (18 April 2012) and the decision of the Head of Government of
+# 16 N. 3-29-15 Chaaban 1435 (4 June 2015).
+# Source (french):
+# http://lnt.ma/le-maroc-reculera-dune-heure-le-dimanche-14-juin/
+#
+# From Milamber (2015-06-09):
+# http://www.mmsp.gov.ma/fr/actualites.aspx?id=863
+#
+# From Michael Deckers (2015-06-09):
+# [The gov.ma announcement] would (probably) make the switch on 2015-07-19 go
+# from 03:00 to 04:00 rather than from 02:00 to 03:00, as in the patch
+# I think the patch is correct and the quoted text is wrong; the text in
+#  agrees
+# with the patch.
+
+# From Paul Eggert (2015-06-08):
+# For now, guess that later spring and fall transitions will use 2015's rules,
 # and guess that Morocco will switch to standard time at 03:00 the last
-# Saturday before Ramadan, and back to DST at 02:00 the first Saturday after
-# Ramadan.  To implement this, transition dates for 2015 through 2037 were
+# Sunday before Ramadan, and back to DST at 02:00 the first Sunday after
+# Ramadan.  To implement this, transition dates for 2016 through 2037 were
 # determined by running the following program under GNU Emacs 24.3, with the
 # results integrated by hand into the table below.
-# (let ((islamic-year 1436))
+# (let ((islamic-year 1437))
+#   (require 'cal-islam)
 #   (while (< islamic-year 1460)
 # (let ((a (calendar-islamic-to-absolute (list 9 1 islamic-year)))
 #   (b (calendar-islamic-to-absolute (list 10 1 islamic-year)))
-#   (saturday 6))
-#   (while (/= saturday (mod (setq a (1- a)) 7)))
-#   (while (/= saturday (mod b 7))
+#   (sunday 0))
+#   (while (/= sunday (mod (setq a (1- a)) 7)))
+#   (while (/= sunday (mod b 7))
 # (setq b (1+ b)))
 #   (setq a (calendar-gregorian-from-absolute a))
 #   (setq b (calendar-gregorian-from-absolute b))
@@ -844,32 +866,30 @@ Rule  Morocco 2012only-   Aug 20  
 2:00   1:
 Rule   Morocco 2013only-   Jul  7   3:00   0   -
 Rule   Morocco 2013only-   Aug 10   2:00   1:00S
 Rule   Morocco 2013max -   Oct lastSun  3:00   0   -
-Rule   Morocco 20142022-   Mar lastSun  2:00   1:00S
+Rule   Morocco 20142021-   Mar lastSun  2:00   1:00S
 Rule   Morocco 2014only-   Jun 28   3:00   0   -
 Rule   Morocco 2014only-   Aug  2   2:00   1:00S
-Rule   Morocco 2015only-   J

svn commit: r284401 - stable/7/share/zoneinfo

[Edwin Groothuis]

Author: edwin
Date: Mon Jun 15 01:03:40 2015
New Revision: 284401
URL: https://svnweb.freebsd.org/changeset/base/284401

Log:
  MFC of 284397,tzdata7:
  
  Update to tzdata2015e:
  
Changes affecting future time stamps
  
  Morocco will suspend DST from 2015-06-14 03:00 through 2015-07-19 02:00,
  not 06-13 and 07-18 as we had guessed.  (Thanks to Milamber.)
  
  Assume Cayman Islands will observe DST starting next year, using US rules.
  Although it isn't guaranteed, it is the most likely.

Modified:
  stable/7/share/zoneinfo/africa
  stable/7/share/zoneinfo/northamerica
  stable/7/share/zoneinfo/southamerica
  stable/7/share/zoneinfo/zone1970.tab
Directory Properties:
  stable/7/share/zoneinfo/   (props changed)

Modified: stable/7/share/zoneinfo/africa
==
--- stable/7/share/zoneinfo/africa  Mon Jun 15 01:03:21 2015
(r284400)
+++ stable/7/share/zoneinfo/africa  Mon Jun 15 01:03:40 2015
(r284401)
@@ -338,9 +338,10 @@ Rule   Egypt   2007only-   Sep Thu>=1  
24:00   
 # time this summer, and carry out studies on the possibility of canceling the
 # practice altogether in future years."
 #
-# From Paul Eggert (2015-04-20):
-# For now, assume DST will be canceled.  Any resumption would likely
-# use different rules anyway.
+# From Paul Eggert (2015-04-24):
+# Yesterday the office of Egyptian President El-Sisi announced his
+# decision to abandon DST permanently.  See Ahram Online 2015-04-24.
+# 
http://english.ahram.org.eg/NewsContent/1/64/128509/Egypt/Politics-/Sisi-cancels-daylight-saving-time-in-Egypt.aspx
 
 Rule   Egypt   2008only-   Aug lastThu 24:00   0   -
 Rule   Egypt   2009only-   Aug 20  24:00   0   -
@@ -787,20 +788,41 @@ Zone Indian/Mauritius 3:50:00 -   LMT 1907
 # will resume again at 02:00 on Saturday, August 2, 2014
 # http://www.mmsp.gov.ma/fr/actualites.aspx?id=586
 
-# From Paul Eggert (2014-06-05):
-# For now, guess that later spring and fall transitions will use 2014's rules,
+# From Milamber (2015-06-08):
+# (Google Translation) The hour will thus be delayed 60 minutes
+# Sunday, June 14 at 3:00, the ministry said in a statement, adding
+# that the time will be advanced again 60 minutes Sunday, July 19,
+# 2015 at 2:00.  The move comes under 2.12.126 Decree of 26 Jumada I
+# 1433 (18 April 2012) and the decision of the Head of Government of
+# 16 N. 3-29-15 Chaaban 1435 (4 June 2015).
+# Source (french):
+# http://lnt.ma/le-maroc-reculera-dune-heure-le-dimanche-14-juin/
+#
+# From Milamber (2015-06-09):
+# http://www.mmsp.gov.ma/fr/actualites.aspx?id=863
+#
+# From Michael Deckers (2015-06-09):
+# [The gov.ma announcement] would (probably) make the switch on 2015-07-19 go
+# from 03:00 to 04:00 rather than from 02:00 to 03:00, as in the patch
+# I think the patch is correct and the quoted text is wrong; the text in
+#  agrees
+# with the patch.
+
+# From Paul Eggert (2015-06-08):
+# For now, guess that later spring and fall transitions will use 2015's rules,
 # and guess that Morocco will switch to standard time at 03:00 the last
-# Saturday before Ramadan, and back to DST at 02:00 the first Saturday after
-# Ramadan.  To implement this, transition dates for 2015 through 2037 were
+# Sunday before Ramadan, and back to DST at 02:00 the first Sunday after
+# Ramadan.  To implement this, transition dates for 2016 through 2037 were
 # determined by running the following program under GNU Emacs 24.3, with the
 # results integrated by hand into the table below.
-# (let ((islamic-year 1436))
+# (let ((islamic-year 1437))
+#   (require 'cal-islam)
 #   (while (< islamic-year 1460)
 # (let ((a (calendar-islamic-to-absolute (list 9 1 islamic-year)))
 #   (b (calendar-islamic-to-absolute (list 10 1 islamic-year)))
-#   (saturday 6))
-#   (while (/= saturday (mod (setq a (1- a)) 7)))
-#   (while (/= saturday (mod b 7))
+#   (sunday 0))
+#   (while (/= sunday (mod (setq a (1- a)) 7)))
+#   (while (/= sunday (mod b 7))
 # (setq b (1+ b)))
 #   (setq a (calendar-gregorian-from-absolute a))
 #   (setq b (calendar-gregorian-from-absolute b))
@@ -844,32 +866,30 @@ Rule  Morocco 2012only-   Aug 20  
 2:00   1:
 Rule   Morocco 2013only-   Jul  7   3:00   0   -
 Rule   Morocco 2013only-   Aug 10   2:00   1:00S
 Rule   Morocco 2013max -   Oct lastSun  3:00   0   -
-Rule   Morocco 20142022-   Mar lastSun  2:00   1:00S
+Rule   Morocco 20142021-   Mar lastSun  2:00   1:00S
 Rule   Morocco 2014only-   Jun 28   3:00   0   -
 Rule   Morocco 2014only-   Aug  2   2:00   1:00S
-Rule   Morocco 2015only-   J

Re: svn commit: r284394 - head

[Garrett Cooper]

That won't fix fmake...



> On Jun 14, 2015, at 15:36, Craig Rodrigues  wrote:
> 
> Author: rodrigc
> Date: Sun Jun 14 22:36:27 2015
> New Revision: 284394
> URL: https://svnweb.freebsd.org/changeset/base/284394
> 
> Log:
>  If MK_META_MODE is unset, assume a value of no.
> 
>  This is needed to build HEAD on FreeBSD 10.1,
>  which has bmake, but does not have
>  /usr/share/mk/src.opts.mk
> 
>  Reviewed by: sjg
>  Reported by: jenkins
> 
> Modified:
>  head/Makefile
> 
> Modified: head/Makefile
> ==
> --- head/MakefileSun Jun 14 22:14:00 2015(r284393)
> +++ head/MakefileSun Jun 14 22:36:27 2015(r284394)
> @@ -99,7 +99,7 @@
> #
> # For more information, see the build(7) manual page.
> #
> -.if ${MK_META_MODE} == "yes"
> +.if ${MK_META_MODE:Uno} == "yes"
> # targets/Makefile plays the role of top-level
> .include "targets/Makefile"
> .else
> 
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r284370 - head/usr.bin/kdump

[Craig Rodrigues]

On Sun, Jun 14, 2015 at 9:16 AM, Dimitry Andric  wrote:

>
> ===> usr.bin/kdump (depend)
> sh /usr/src/usr.bin/kdump/mksubr /usr/obj/usr/src/tmp/usr/include
> >kdump_subr.c
> env MACHINE=i386 CPP="cpp "  sh /usr/src/usr.bin/kdump/mkioctls print
> /usr/obj/usr/src/tmp/usr/include > ioctl.c
> :1:10: fatal error: 'cam/cam_compat.h' file not found
> #include 
>


I got the same errors here:

https://jenkins.freebsd.org/job/FreeBSD_HEAD/2869/consoleFull

--- ioctl.c ---
:1:10: fatal error: 'cam/cam_compat.h' file not found
#include 
 ^
1 error generated.


--- depend_subdir_kdump ---
/builds/FreeBSD_HEAD/usr.bin/kdump/kdump.c:153:10: fatal error:
'linux_syscalls.c' file not found
#include 
 ^


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

Re: svn commit: r284198 - head/bin/ls

[Julian Elischer]

On 6/14/15 2:40 AM, Marcel Moolenaar wrote:

On Jun 13, 2015, at 1:19 PM, Julian Elischer  wrote:

On 6/13/15 11:38 PM, David Chisnall wrote:

On 13 Jun 2015, at 11:17, Ian Lepore  wrote:

If you would have told me a year ago that you had a simple scheme that
could make 30 years of experience maintaining code for unix-like systems
completely worthless I would have been skeptical, but it seems we're
well on our way.

There is a lot of heckling and unhelpful hyperbole in this thread.  Reading the 
xo_emit format strings takes a little bit of getting used to, but the same is 
true of printf - it’s just that we’re already used to printf.  The structured 
parts (xo_open_container, xo_close_container and friends) are clear and 
descriptive.  The changes are fairly invasive, but the benefits are also very 
large for anyone who is wanting to automate administration of FreeBSD systems.

If you have suggestions for how the libxo APIs could be improved, then please 
let us know - Phil is very reception to suggestions but objections along the 
lines of ‘it’s not what I’m used to and changes sometimes break things so we 
should never have changes’ are not helpful.

David


I made a suggestion for an alternate path in the previous thread.

https://lists.freebsd.org/pipermail/freebsd-current/2015-March/054855.html

but I have a job and kids so I can't object if I'm not listened to..
(no time to actually follow my own advice and produce working code.)

Not wanting to change all programs and instead write grammars for all
programs seems like a worse solution. The scope is the same (same
number of programs), but since the grammars and programs are two
distinct entities, it’s actually fairly hard to make sure both are
changed at the same time when so needed. It’s also not at all a
given that screen scrubbing is always easy enough to do that it
isn’t causing some sort of problems in specific situations. If
one wants to output JSON, XML and HTML you find that screen
scrubbing doesn’t even give you all the information you need. It’s
very natural to come to the conclusion that it’s easier to get the
data from the source and skip the entire non-lossless translation
phase.


But once you have the framework for handling grammars you can make
grammars for OTHER utilities that are not part of FreeBSD, and will
NEVER EVER EVER have libxo support. And as a bonus you leave the existing
programs alone entirely. I believe that in the end if you want to 
follow the path
of automatic harvesting of data, you'll need the grammar handler 
anyway because

all the 3rd party apps still require handling.

It's a tricky task but It would be a really fascinating project. 
Especially tools that would look at
existing output and allow the user to interactively identify tokens 
and landmarks of interest and

generate grammars.  We did this 20 years ago with scanned images..
So I'm sure it be done with ascii text.  Come to think of it, there 
must be some out there already..








--
Marcel Moolenaar
mar...@xcllnt.net



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

Re: svn commit: r284198 - head/bin/ls

[Julian Elischer]

On 6/14/15 10:48 AM, Adrian Chadd wrote:

On 13 June 2015 at 18:22, Craig Rodrigues  wrote:


On Sat, Jun 13, 2015 at 6:00 PM, Adrian Chadd  wrote:

I guarantee that no matter what you've worked on, there's
approximately five orders of magnitude of shipping devices whose
entire storage space can be measured in 1 digit megabytes. Each year.

(And yes - there's an appreciable set of them for which freebsd boots,
runs and keeps running on them.0

You can buy em too, some of them even under $60.


Can FreeBSD now not run on these systems because of libxo?

It's a tight squeeze as it is. Running in 8MB of flash (even if it's
compressed) is still an exercise in "what can you cut out."

My point isn't that it isn't running because of libxo; my point is
that arguing about "embedded" involving "lots of storage" is woefully
incorrect and will continue to be until those gigabytes of storage are
available for a penny. Which yes, I'm guessing will happen in my
career - but it's also quite likely code bloat will continue to chase
that upward.


do we have a WITHOUT_LIBXO option on sources?  I believe we should..




-adrian




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

Re: svn commit: r284345 - in head: . bin/cat bin/chflags bin/chio bin/chmod bin/cp bin/csh bin/date bin/dd bin/df bin/domainname bin/echo bin/ed bin/expr bin/freebsd-version bin/getfacl bin/hostname b

[Julian Elischer]

On 6/15/15 5:43 AM, Simon J. Gerraty wrote:

Dimitry Andric  wrote:

Some questions about this commit, which I'm sure more people must have:

Sure, good questions and as you say, many likely thinking the same.


* Was it really necessary to commit hundreds of clearly generated files?

Short answer is "yes" - since they are actually what makes the build
work.


* Couldn't these be generated on the fly, or with some "make depend" like 
command?

The whole point is to avoid that overhead.
As long as there is a REALLY EASY WAY to regenerate them and it's well 
documented,
(preferably in each generated file) and regenerating them generates 
EXACTLY the same output
each time unless there is a source change, (so svn doesn't see a 
change if there is none)

then I guess having them checked in is ok. (though a bit "yucky").
I'd like the ability to make a full make however that DOES regenerate 
them if I feel I have the time.



* How to update these files, if you change anything in the 'real' Makefiles?

For now don't worry about it, those of us that want to build/play with
meta mode will take care of updating them.

Simply building in meta mode is all that is needed to update them.


* Or are you now the maintainer of these .depend files? :-)

For now, yes.
I think that's the only reasonable approach at this early stage.

Thanks
--sjg






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

svn commit: r284403 - head

[Gregory Neil Shapiro]

Author: gshapiro
Date: Mon Jun 15 04:18:29 2015
New Revision: 284403
URL: https://svnweb.freebsd.org/changeset/base/284403

Log:
  Add a quick (?) note for users who may be having sendmail interoperability 
issues
  due to the recent (FreeBSD-SA-15:10.openssl) OpenSSL change to reject 512 bit
  DH parameters.  Affects 11-CURRENT and 10-STABLE.

Modified:
  head/UPDATING

Modified: head/UPDATING
==
--- head/UPDATING   Mon Jun 15 01:04:01 2015(r284402)
+++ head/UPDATING   Mon Jun 15 04:18:29 2015(r284403)
@@ -31,6 +31,30 @@ NOTE TO PEOPLE WHO THINK THAT FreeBSD 11
disable the most expensive debugging functionality run
"ln -s 'abort:false,junk:false' /etc/malloc.conf".)
 
+20150614:
+   The import of openssl to address the FreeBSD-SA-15:10.openssl
+   security advisory includes a change which rejects handshakes
+   with DH parameters below 768 bits.  sendmail releases prior
+   to 8.15.2 (not yet released), defaulted to a 512 bit
+   DH parameter setting for client connections.  To work around
+   this interoperability, sendmail can be configured to use a
+   2048 bit DH parameter by:
+
+   1. Edit /etc/mail/`hostname`.mc 
+   2. If a setting for confDH_PARAMETERS does not exist or
+  exists and is set to a string beginning with '5',
+  replace it with '2'.
+   3. If a setting for confDH_PARAMETERS exists and is set to
+  a file path, create a new file with:
+   openssl dhparam -out /path/to/file 2048
+   4. Rebuild the .cf file:
+   cd /etc/mail/; make; make install
+   5. Restart sendmail:
+   cd /etc/mail/; make restart
+
+   A sendmail patch is coming, at which time this file will be
+   updated.
+
 20150604:
Generation of legacy formatted entries have been disabled by default
in pwd_mkdb(8), as all base system consumers of the legacy formatted
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r284404 - stable/10

[Gregory Neil Shapiro]

Author: gshapiro
Date: Mon Jun 15 04:20:32 2015
New Revision: 284404
URL: https://svnweb.freebsd.org/changeset/base/284404

Log:
  MFC: Add a quick (?) note for users who may be having sendmail 
interoperability issues
   due to the recent (FreeBSD-SA-15:10.openssl) OpenSSL change to reject 
512 bit
   DH parameters.  Affects 11-CURRENT and 10-STABLE.

Modified:
  stable/10/UPDATING

Modified: stable/10/UPDATING
==
--- stable/10/UPDATING  Mon Jun 15 04:18:29 2015(r284403)
+++ stable/10/UPDATING  Mon Jun 15 04:20:32 2015(r284404)
@@ -16,6 +16,30 @@ from older versions of FreeBSD, try WITH
 stable/10, and then rebuild without this option. The bootstrap process from
 older version of current is a bit fragile.
 
+20150614:
+   The import of openssl to address the FreeBSD-SA-15:10.openssl
+   security advisory includes a change which rejects handshakes
+   with DH parameters below 768 bits.  sendmail releases prior
+   to 8.15.2 (not yet released), defaulted to a 512 bit
+   DH parameter setting for client connections.  To work around
+   this interoperability, sendmail can be configured to use a
+   2048 bit DH parameter by:
+
+   1. Edit /etc/mail/`hostname`.mc 
+   2. If a setting for confDH_PARAMETERS does not exist or
+  exists and is set to a string beginning with '5',
+  replace it with '2'.
+   3. If a setting for confDH_PARAMETERS exists and is set to
+  a file path, create a new file with:
+   openssl dhparam -out /path/to/file 2048
+   4. Rebuild the .cf file:
+   cd /etc/mail/; make; make install
+   5. Restart sendmail:
+   cd /etc/mail/; make restart
+
+   A sendmail patch is coming, at which time this file will be
+   updated.
+
 20150601:
chmod, chflags, chown and chgrp now affect symlinks in -R mode as
defined in symlink(7); previously symlinks were silently ignored.
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r284345 - in head: . bin/cat bin/chflags bin/chio bin/chmod bin/cp bin/csh bin/date bin/dd bin/df bin/domainname bin/echo bin/ed bin/expr bin/freebsd-version bin/getfacl bin/hostname b

[Julian Elischer]

On 6/15/15 6:56 AM, Craig Rodrigues wrote:
On Sun, Jun 14, 2015 at 3:37 PM, Adrian Chadd > wrote:


Hi,

I'm happy for this to be your baby and see how it all pans out
in the
tree, but I thought we as a project learnt some lessons about
checking
in autogenerated files.



Well, I would like to give Simon the benefit of the doubt here.
When I worked at Juniper, I worked first with John Birrell on the
early jbuild prototype, and later with Simon on the bmake + meta-mode
work.

Simon gave this presentation + video on meta-mode at BSDCan 2014:
http://www.bsdcan.org/2014/schedule/track/Hacking/460.en.html

I gave this preso on jbuild at BSDCan 2010:
https://www.bsdcan.org/2010/schedule/events/198.en.html

Inside Juniper, there were concerns expressed about checking in
generated dependency files.  I'm seeing the same concerns expressed by
the FreeBSD community. :)

It turns out that checking in the dependency files was the right way 
to go.
This has been battle tested inside Juniper, and it does workI've 
seen it.


It turns out that running a dependency generation step at the beginning
of the build takes a long time.  When you are building something
on the scale of an operating system, like FreeBSD, or
something even huger, like JUNOS, this takes a non-trivial amount of 
time,

and gets worse as the size of the code grows.

Checking in the dependencies allows you to do some pretty amazing
stuff with the build, especially when you start integrating manifests
and packaging of the base system.

Now I will agree with Adrian on a couple of points:

(1)  For the initial go around, if Simon babysits the 
Makefile.depend files

  in HEAD that would be OK.  They are turned off by default
  anyways.

(2)  In the long run, having better documentation, tooling and 
procedures to

  update the
  Makefile.depend files will be definitely needed.
  Using automation systems like Jenkins would definitely help,
  but that's not the only way to do things.


I think a make MAKE_MAKEFILE_DEPENDS=1 (build)world is an important 
step requirement..
i.e. starting with what is there, regenerate ALL of them.. Since the 
source tree is supposed to be read-only
this has to not happen by default but if it is possibe to force it, 
then svn  (or p4 or git) can easily figure out which ones changed (as 
long as two runs of the generation pass produce identical output) and 
check in any that changed.




--
Craig


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

Re: svn commit: r284198 - head/bin/ls

[Garrett Cooper]

On Jun 14, 2015, at 20:53, Julian Elischer  wrote:

> On 6/14/15 10:48 AM, Adrian Chadd wrote:
>> On 13 June 2015 at 18:22, Craig Rodrigues  wrote:
>>> 
>>> On Sat, Jun 13, 2015 at 6:00 PM, Adrian Chadd  wrote:
> I guarantee that no matter what you've worked on, there's
> approximately five orders of magnitude of shipping devices whose
> entire storage space can be measured in 1 digit megabytes. Each year.
 (And yes - there's an appreciable set of them for which freebsd boots,
 runs and keeps running on them.0
 
 You can buy em too, some of them even under $60.
>>> 
>>> Can FreeBSD now not run on these systems because of libxo?
>> It's a tight squeeze as it is. Running in 8MB of flash (even if it's
>> compressed) is still an exercise in "what can you cut out."
>> 
>> My point isn't that it isn't running because of libxo; my point is
>> that arguing about "embedded" involving "lots of storage" is woefully
>> incorrect and will continue to be until those gigabytes of storage are
>> available for a penny. Which yes, I'm guessing will happen in my
>> career - but it's also quite likely code bloat will continue to chase
>> that upward.
> 
> do we have a WITHOUT_LIBXO option on sources?  I believe we should..

+1. I would be more than happy to implement it by stubbing out the majority of 
the macros to something less invasive, but it might be a bit before I do that.
Thanks,


signature.asc
Description: Message signed with OpenPGP using GPGMail

svn commit: r284405 - in head: . share/mk

[Garrett Cooper]

Author: ngie
Date: Mon Jun 15 06:38:59 2015
New Revision: 284405
URL: https://svnweb.freebsd.org/changeset/base/284405

Log:
  Remove ALLOW_DEPRECATED_ATF_TOOLS/ATFFILE support from atf.test.mk
  
  The legacy atf tools were removed in atf 0.20
  
  MFC after: 2 weeks

Modified:
  head/UPDATING
  head/share/mk/atf.test.mk

Modified: head/UPDATING
==
--- head/UPDATING   Mon Jun 15 04:20:32 2015(r284404)
+++ head/UPDATING   Mon Jun 15 06:38:59 2015(r284405)
@@ -32,6 +32,12 @@ NOTE TO PEOPLE WHO THINK THAT FreeBSD 11
"ln -s 'abort:false,junk:false' /etc/malloc.conf".)
 
 20150614:
+   ALLOW_DEPRECATED_ATF_TOOLS/ATFFILE support has been removed from
+   atf.test.mk (included from bsd.test.mk). Please upgrade devel/atf
+   and devel/kyua to version 0.20+ and adjust any calling code to work
+   with Kyuafile and kyua.
+
+20150614:
The import of openssl to address the FreeBSD-SA-15:10.openssl
security advisory includes a change which rejects handshakes
with DH parameters below 768 bits.  sendmail releases prior

Modified: head/share/mk/atf.test.mk
==
--- head/share/mk/atf.test.mk   Mon Jun 15 04:20:32 2015(r284404)
+++ head/share/mk/atf.test.mk   Mon Jun 15 06:38:59 2015(r284405)
@@ -22,28 +22,10 @@ ATF_TESTS_C?=
 ATF_TESTS_CXX?=
 ATF_TESTS_SH?=
 
-# Whether to allow using the deprecated ATF tools or not.
-#
-# If 'yes', this file will generate Atffiles when requested and will also
-# support using the deprecated atf-run tool to execute the tests.
-ALLOW_DEPRECATED_ATF_TOOLS?= no
-
-# Knob to control the handling of the Atffile for this Makefile.
-#
-# If 'yes', an Atffile exists in the source tree and is installed into
-# TESTSDIR.
-#
-# If 'auto', an Atffile is automatically generated based on the list of test
-# programs built by the Makefile and is installed into TESTSDIR.  This is the
-# default and is sufficient in the majority of the cases.
-#
-# If 'no', no Atffile is installed.
-ATFFILE?= auto
-
 # Path to the prefix of the installed ATF tools, if any.
 #
 # If atf-run and atf-report are installed from ports, we automatically define a
-# realtest target below to run the tests using these tools.  The tools are
+# realregress target below to run the tests using these tools.  The tools are
 # searched for in the hierarchy specified by this variable.
 ATF_PREFIX?= /usr/local
 
@@ -121,67 +103,3 @@ ${_T}: ${ATF_TESTS_SH_SRC_${_T}}
mv ${.TARGET}.tmp ${.TARGET}
 .endfor
 .endif
-
-.if ${ALLOW_DEPRECATED_ATF_TOOLS} != "no"
-
-.if ${ATFFILE:tl} != "no"
-FILES+=Atffile
-FILESDIR_Atffile= ${TESTSDIR}
-
-.if ${ATFFILE:tl} == "auto"
-CLEANFILES+= Atffile Atffile.tmp
-
-Atffile: Makefile
-   @{ echo 'Content-Type: application/X-atf-atffile; version="1"'; \
-   echo; \
-   echo '# Automatically generated by atf-test.mk.'; \
-   echo; \
-   echo 'prop: test-suite = "'${TESTSUITE}'"'; \
-   echo; \
-   for tp in ${ATF_TESTS_C} ${ATF_TESTS_CXX} ${ATF_TESTS_SH} \
-   ${TESTS_SUBDIRS}; \
-   do \
-   echo "tp: $${tp}"; \
-   done; } >Atffile.tmp
-   @mv Atffile.tmp Atffile
-.endif
-.endif
-
-ATF_REPORT?= ${ATF_PREFIX}/bin/atf-report
-ATF_RUN?= ${ATF_PREFIX}/bin/atf-run
-.if exists(${ATF_RUN}) && exists(${ATF_REPORT})
-# Definition of the "make test" target and supporting variables.
-#
-# This target, by necessity, can only work for native builds (i.e. a freeBSD
-# host building a release for the same system).  The target runs ATF, which is
-# not in the toolchain, and the tests execute code built for the target host.
-#
-# Due to the dependencies of the binaries built by the source tree and how they
-# are used by tests, it is highly possible for a execution of "make test" to
-# report bogus results unless the new binaries are put in place.
-_TESTS_FIFO= ${.OBJDIR}/atf-run.fifo
-_TESTS_LOG= ${.OBJDIR}/atf-run.log
-CLEANFILES+= ${_TESTS_FIFO} ${_TESTS_LOG}
-realtest: .PHONY
-   @set -e; \
-   if [ -z "${TESTSDIR}" ]; then \
-   echo "*** No TESTSDIR defined; nothing to do."; \
-   exit 0; \
-   fi; \
-   cd ${DESTDIR}${TESTSDIR}; \
-   rm -f ${_TESTS_FIFO}; \
-   mkfifo ${_TESTS_FIFO}; \
-   tee ${_TESTS_LOG} < ${_TESTS_FIFO} | ${TESTS_ENV} ${ATF_REPORT} & \
-   set +e; \
-   ${TESTS_ENV} ${ATF_RUN} >> ${_TESTS_FIFO}; \
-   result=$${?}; \
-   wait; \
-   rm -f ${_TESTS_FIFO}; \
-   echo; \
-   echo "*** The verbatim output of atf-run has been saved to 
${_TESTS_LOG}"; \
-   echo "***"; \
-   echo &q

svn commit: r284406 - head/usr.bin/kdump

[Craig Rodrigues]

Author: rodrigc
Date: Mon Jun 15 06:44:22 2015
New Revision: 284406
URL: https://svnweb.freebsd.org/changeset/base/284406

Log:
  Use cpp -I$includedir
  
  "cpp -I$1" was expanding to "cpp -Iprint"
  which was not the proper directory
  of header files.

Modified:
  head/usr.bin/kdump/mkioctls

Modified: head/usr.bin/kdump/mkioctls
==
--- head/usr.bin/kdump/mkioctls Mon Jun 15 06:38:59 2015(r284405)
+++ head/usr.bin/kdump/mkioctls Mon Jun 15 06:44:22 2015(r284406)
@@ -39,7 +39,7 @@ case "${MACHINE}" in
 esac
 
 awk -v x="$ioctl_includes" 'BEGIN {print x}' |
-   $CPP -nostdinc -I$1 -dM -DCOMPAT_43TTY - |
+   $CPP -nostdinc -I$includedir -dM -DCOMPAT_43TTY - |
awk -v ioctl_includes="$ioctl_includes" -v style="$style" '
 BEGIN {
print "/* XXX obnoxious prerequisites. */"
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r284407 - head/usr.bin/kdump

[Craig Rodrigues]

Author: rodrigc
Date: Mon Jun 15 06:48:43 2015
New Revision: 284407
URL: https://svnweb.freebsd.org/changeset/base/284407

Log:
  Add ioctl.c, linux_syscalls.c, linux32_syscalls.c to beforedepend target.
  
  These files need to be generated before mkdep is run.

Modified:
  head/usr.bin/kdump/Makefile

Modified: head/usr.bin/kdump/Makefile
==
--- head/usr.bin/kdump/Makefile Mon Jun 15 06:44:22 2015(r284406)
+++ head/usr.bin/kdump/Makefile Mon Jun 15 06:48:43 2015(r284407)
@@ -23,7 +23,11 @@ NO_WERROR?=  YES
 
 CLEANFILES=ioctl.c kdump_subr.c kdump_subr.h
 
+beforedepend: ioctl.c
+
 .if (${MACHINE_ARCH} == "amd64" || ${MACHINE_ARCH} == "i386")
+beforedepend: linux_syscalls.c
+
 CLEANFILES+=   linux_syscalls.c
 kdump.o: linux_syscalls.c
 linux_syscalls.c:  linux_syscalls.conf
@@ -31,6 +35,8 @@ linux_syscalls.c: linux_syscalls.conf
${.CURDIR}/../../sys/${MACHINE_ARCH}/linux/syscalls.master 
${.CURDIR}/linux_syscalls.conf
 .endif
 .if (${MACHINE_ARCH} == "amd64")
+beforedepend: linux32_syscalls.c
+
 CLEANFILES+=   linux32_syscalls.c
 kdump.o: linux32_syscalls.c
 linux32_syscalls.c: linux32_syscalls.conf
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"