Firefox and Cliqz tabs crashing at GOV.UK government pages

[Graham Perrin]

On 08/04/2020 20:23, Graham Perrin wrote:

> Firefox 75.0_1,1 tabs crashing or mis-rendering at some www.gov.uk pages
>
> Most noticeable today at . 
Screenshots available on request.

>
> AFAICT the same types of problem with 75.0_1,1 on both r357746 and 
r359628.


The problem persists with r359750, is reproducible with a different user 
account, is reproducible with Cliqz browser. As far as I can tell, only 
bugging UK.GOV government pages.


Occasionally a page will appear OK (e.g. the screen to the left at 
), more often the page will appear 
wrong (screen to the right, safe mode).


Most often: the tab will crash before the screen can be read. Crashes 
seem to occur at load time, towards the tail end of content loading or 
rendering.


More shots of what appears to be mis-rendering, Firefox with a refreshed 
profile in safe mode:





I have .core files from both Firefox and Cliqz, should I report a bug?

(Also I'd like to take this opportunity to learn how to interpret parts 
of a .core file, I'll do what I can with man pages but might need to 
seek help in IRC.)




grahamperrin@momh167-gjp4-8570p:~ % date ; uname -v
Sat 11 Apr 2020 01:09:15 BST
FreeBSD 13.0-CURRENT #52 r359750: Fri Apr 10 03:33:09 BST 2020 
root@momh167-gjp4-8570p:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG

grahamperrin@momh167-gjp4-8570p:~ % pkg query '%o %v %R' cliqz firefox
www/cliqz 1.34.0_1 FreeBSD
www/firefox 75.0_1,1 FreeBSD
grahamperrin@momh167-gjp4-8570p:~ %

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: buildkernel failure because ctfconvert not installed

[Warner Losh]

On Fri, Apr 10, 2020, 11:36 AM Rodney W. Grimes <
freebsd-...@gndrsh.dnsmgr.net> wrote:

> > On Fri, Apr 10, 2020 at 10:45 AM Rodney W. Grimes <
> > freebsd-...@gndrsh.dnsmgr.net> wrote:
> >
> > > > 
> > > > In message <9f03fb79-a0ad-3c11-9a50-bc7731882...@fastmail.com>, Yuri
> > > Pankov writes:
> > > > >Trond Endrest?l wrote:
> > > > >> On Thu, 9 Apr 2020 10:56+0200, Gary Jennejohn wrote:
> > > > >>
> > > > >>> OK, I figured it out.
> > > > >>>
> > > > >>> I used to have MK_CTF=no in src.conf, but I recently changed it
> to
> > > > >>> WITH_CTF=no.
> > > > >>
> > > > >> It's either WITH_xxx=yes or WITHOUT_xxx=yes
> > >
> >
> > It's either -DWITH_FOO or -DWITHOUT_FOO. yes or no  never enters into it.
>
> Then we *COULD*, maybe even *SHOULD* check for a value and
> complain if one is set.
>

No. We should not. That breaks other people.


>
> >
> > > > >Or even WITH_xxx= or WITHOUT_xxx=, src.conf(5) explicitly states
> that
> > > > >value is NOT checked:
> > > > >
> > > > >The values of variables are ignored regardless of their setting;
> even
> > > if
> > > > >  they would be set to "FALSE" or "NO".  The presence of an option
> > > > >causes it to be honored by make(1).
> > > >
> > > > That is not even close to POLA-compliance...
> > >
> >
> > It took 20 years for someone to notice. If it takes 20 years to be
> > astonished, I suspect that it comes close to 'least' by any sane measure.
>
> I do not see the word *recent* in POLA.
> As far as I can tell POLA is time invariant.
>

Time is relevant.

>
> > > I am not a fan of it either, not sure when this idea came about
> > > of doing WITH_ and WITHOUT and ignoring the set value, but it
> > > is very non POLA given how many variables we do have with set values.
> > >
> >
> > We've literally ignored the value for the last 20 years or so (we started
> > in the 4.x time frame). This is the first time it's come up. It's hard to
> > make a convincing POLA argument based on this data.
>
> Wrong or bad for 20 years makes it no less wrong.
>

It's not wrong.

> We specifically ignored it because we had crazy s*** in the tree like
> > NOSHARED=no meaning something. And it wasn't quite the something you'd
> > think it would mean without careful study (it meant do link this shared,
> > which is straight forward enough. But it didn't mean do create this
> library
> > as shared).
>
> What you call crazy s*** is just double negatives, and though it is
> poor it actually has clear symantics.
>
> You want crazy s***
> WITH_xxx=yes
> WITH_xxx=no
> do exactly the same thing!   Now thats crazy s***
>

I didn't read the docs and things broke.

>
> >
> > > > Obviously negative values ("false", "no") should either be reported
> as
> > > > errors or preferably be respected.
> > >
> >
> > You can't make something foolproof because fools are so ingenious. Also,
> > turns out it's trickier to "fix" than you might think.
>
> It really isnt hard to fix... just stop using, then later allowing a value
> on WITH_xxx or WITHOUT_xxx.
>

It takes them time to find out why the documented thing has changed.

Right now we could add a warning if a value is set, people would slowly
> weed out this poor use, and in time up the warning to an error.
>

Not sure this would be popular. Lots of places set some value. This would
be way worse.

>
> > We almost certainly are not going to change this.
> Your position, others are free to disagree, as I do.
>

Others haven't been maintaining the build system. Others didn't carefully
negotiate the current behavior among different warring factions as a
compromise everyone was happy with. Others haven't been working for 20
years to keep it consistent. So while it is just an opinion, it's one
that's informed by long experience with many different issues and scenarios
that have come up over time.

> Why aren't we going to
> > change it? It took 20 years for someone to complain and it may break
> > currently working scripts that rely on the documented behavior of the
> > variable being defined to define WITH_FOO=n for  some crazy reason. And
> > this isn't a theoretical example, I know of at least two build systems
> that
> > define WITH_FOO or WITHOUT_FOO to some value. Also, does WITHOUT_FOO=no
> > mean "I don't want foo"? or "I don't not want foo?" So if you don't do it
> > for WITHOUT but do to it for WITH, you wind up with another mess of
> > inconsistency, or you wind up getting close to have NOSHARED=no again.
>
> See proposed "change and fix".
>

I've seen no code. I can't say for sure without looking at the code
proposed.

Warner

> Warner
> --
> Rod Grimes
> rgri...@freebsd.org
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: buildkernel failure because ctfconvert not installed

[Rodney W. Grimes]

> On Fri, Apr 10, 2020 at 10:45 AM Rodney W. Grimes <
> freebsd-...@gndrsh.dnsmgr.net> wrote:
> 
> > > 
> > > In message <9f03fb79-a0ad-3c11-9a50-bc7731882...@fastmail.com>, Yuri
> > Pankov writes:
> > > >Trond Endrest?l wrote:
> > > >> On Thu, 9 Apr 2020 10:56+0200, Gary Jennejohn wrote:
> > > >>
> > > >>> OK, I figured it out.
> > > >>>
> > > >>> I used to have MK_CTF=no in src.conf, but I recently changed it to
> > > >>> WITH_CTF=no.
> > > >>
> > > >> It's either WITH_xxx=yes or WITHOUT_xxx=yes
> >
> 
> It's either -DWITH_FOO or -DWITHOUT_FOO. yes or no  never enters into it.

Then we *COULD*, maybe even *SHOULD* check for a value and
complain if one is set.

> 
> 
> > > >Or even WITH_xxx= or WITHOUT_xxx=, src.conf(5) explicitly states that
> > > >value is NOT checked:
> > > >
> > > >The values of variables are ignored regardless of their setting; even
> > if
> > > >  they would be set to "FALSE" or "NO".  The presence of an option
> > > >causes it to be honored by make(1).
> > >
> > > That is not even close to POLA-compliance...
> >
> 
> It took 20 years for someone to notice. If it takes 20 years to be
> astonished, I suspect that it comes close to 'least' by any sane measure.

I do not see the word *recent* in POLA.
As far as I can tell POLA is time invariant.

> 
> > I am not a fan of it either, not sure when this idea came about
> > of doing WITH_ and WITHOUT and ignoring the set value, but it
> > is very non POLA given how many variables we do have with set values.
> >
> 
> We've literally ignored the value for the last 20 years or so (we started
> in the 4.x time frame). This is the first time it's come up. It's hard to
> make a convincing POLA argument based on this data.

Wrong or bad for 20 years makes it no less wrong.

> We specifically ignored it because we had crazy s*** in the tree like
> NOSHARED=no meaning something. And it wasn't quite the something you'd
> think it would mean without careful study (it meant do link this shared,
> which is straight forward enough. But it didn't mean do create this library
> as shared).

What you call crazy s*** is just double negatives, and though it is
poor it actually has clear symantics.

You want crazy s***
WITH_xxx=yes
WITH_xxx=no
do exactly the same thing!   Now thats crazy s***

> 
> 
> > > Obviously negative values ("false", "no") should either be reported as
> > > errors or preferably be respected.
> >
> 
> You can't make something foolproof because fools are so ingenious. Also,
> turns out it's trickier to "fix" than you might think.

It really isnt hard to fix... just stop using, then later allowing a value
on WITH_xxx or WITHOUT_xxx.

Right now we could add a warning if a value is set, people would slowly
weed out this poor use, and in time up the warning to an error.

> 
> We almost certainly are not going to change this.
Your position, others are free to disagree, as I do.

> Why aren't we going to
> change it? It took 20 years for someone to complain and it may break
> currently working scripts that rely on the documented behavior of the
> variable being defined to define WITH_FOO=n for  some crazy reason. And
> this isn't a theoretical example, I know of at least two build systems that
> define WITH_FOO or WITHOUT_FOO to some value. Also, does WITHOUT_FOO=no
> mean "I don't want foo"? or "I don't not want foo?" So if you don't do it
> for WITHOUT but do to it for WITH, you wind up with another mess of
> inconsistency, or you wind up getting close to have NOSHARED=no again.

See proposed "change and fix".  

> Warner
-- 
Rod Grimes rgri...@freebsd.org
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: buildkernel failure because ctfconvert not installed

[Warner Losh]

On Fri, Apr 10, 2020 at 10:45 AM Rodney W. Grimes <
freebsd-...@gndrsh.dnsmgr.net> wrote:

> > 
> > In message <9f03fb79-a0ad-3c11-9a50-bc7731882...@fastmail.com>, Yuri
> Pankov writes:
> > >Trond Endrest?l wrote:
> > >> On Thu, 9 Apr 2020 10:56+0200, Gary Jennejohn wrote:
> > >>
> > >>> OK, I figured it out.
> > >>>
> > >>> I used to have MK_CTF=no in src.conf, but I recently changed it to
> > >>> WITH_CTF=no.
> > >>
> > >> It's either WITH_xxx=yes or WITHOUT_xxx=yes
>

It's either -DWITH_FOO or -DWITHOUT_FOO. yes or no  never enters into it.


> > >Or even WITH_xxx= or WITHOUT_xxx=, src.conf(5) explicitly states that
> > >value is NOT checked:
> > >
> > >The values of variables are ignored regardless of their setting; even
> if
> > >  they would be set to "FALSE" or "NO".  The presence of an option
> > >causes it to be honored by make(1).
> >
> > That is not even close to POLA-compliance...
>

It took 20 years for someone to notice. If it takes 20 years to be
astonished, I suspect that it comes close to 'least' by any sane measure.


> I am not a fan of it either, not sure when this idea came about
> of doing WITH_ and WITHOUT and ignoring the set value, but it
> is very non POLA given how many variables we do have with set values.
>

We've literally ignored the value for the last 20 years or so (we started
in the 4.x time frame). This is the first time it's come up. It's hard to
make a convincing POLA argument based on this data.

We specifically ignored it because we had crazy s*** in the tree like
NOSHARED=no meaning something. And it wasn't quite the something you'd
think it would mean without careful study (it meant do link this shared,
which is straight forward enough. But it didn't mean do create this library
as shared).


> > Obviously negative values ("false", "no") should either be reported as
> > errors or preferably be respected.
>

You can't make something foolproof because fools are so ingenious. Also,
turns out it's trickier to "fix" than you might think.

We almost certainly are not going to change this. Why aren't we going to
change it? It took 20 years for someone to complain and it may break
currently working scripts that rely on the documented behavior of the
variable being defined to define WITH_FOO=n for  some crazy reason. And
this isn't a theoretical example, I know of at least two build systems that
define WITH_FOO or WITHOUT_FOO to some value. Also, does WITHOUT_FOO=no
mean "I don't want foo"? or "I don't not want foo?" So if you don't do it
for WITHOUT but do to it for WITH, you wind up with another mess of
inconsistency, or you wind up getting close to have NOSHARED=no again.

Warner
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: buildkernel failure because ctfconvert not installed

[Rodney W. Grimes]

> 
> In message <9f03fb79-a0ad-3c11-9a50-bc7731882...@fastmail.com>, Yuri Pankov 
> writes:
> >Trond Endrest?l wrote:
> >> On Thu, 9 Apr 2020 10:56+0200, Gary Jennejohn wrote:
> >> 
> >>> OK, I figured it out.
> >>>
> >>> I used to have MK_CTF=no in src.conf, but I recently changed it to
> >>> WITH_CTF=no.
> >> 
> >> It's either WITH_xxx=yes or WITHOUT_xxx=yes.
> >
> >Or even WITH_xxx= or WITHOUT_xxx=, src.conf(5) explicitly states that 
> >value is NOT checked:
> >
> >The values of variables are ignored regardless of their setting; even if 
> >  they would be set to "FALSE" or "NO".  The presence of an option 
> >causes it to be honored by make(1).
> 
> That is not even close to POLA-compliance...

I am not a fan of it either, not sure when this idea came about
of doing WITH_ and WITHOUT and ignoring the set value, but it
is very non POLA given how many variables we do have with set values.

> 
> Obviously negative values ("false", "no") should either be reported as
> errors or preferably be respected.
> 
> PS: [This is not the bikeshed you are looking for]

BLUE!

> Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
-- 
Rod Grimes rgri...@freebsd.org
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: .debug files, skip?

[Kevin Oberman]

On Fri, Apr 10, 2020 at 4:07 AM Andriy Gapon  wrote:

> On 10/04/2020 09:55, Alexey Dokuchaev wrote:
> > On Sun, Apr 05, 2020 at 07:41:38PM -0400, Ed Maste wrote:
> >> On Sun, 5 Apr 2020 at 08:32, Jeffrey Bouquet wrote:
> >>>
> >>> A recent build[k,w] [ ** stable  12.1] and many .debug files I'd
> >>> like to skip if poss. A knob?
> >>
> >> Yes, from src.conf(5):
> >>  WITHOUT_DEBUG_FILES
> >>  Set to avoid building or installing standalone debug
> >>  files for each executable binary and shared library.
> >
> > I have "MK_DEBUG_FILES=no" in /etc/make.conf, which one is more correct?
>
> WITHOUT_.
>
> See bsd.mkopt.mk.
>
> # Users should generally define WITH_FOO or WITHOUT_FOO, but the build
> # system should use MK_FOO={yes,no} when it needs to override the
> # user's desires or default behavior.
>
> --
> Andriy Gapon
>

Or see src.conf man page which states:
The values of variables are ignored regardless of their setting; even if
they would be set to “FALSE” or “NO”.  The presence of an option causes it
to be honored by make(1).

Kevin Oberman, Network Engineer, Retired
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: lib/libsysdecode /usr/include/./sys/pioctl.h:45:2: error: " is deprecated

[Julian H. Stacey]

Brooks Davis wrote:
> 
> --TB36FDmn/VVEgNH/
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
> 
> On Thu, Apr 09, 2020 at 11:49:47PM +0200, Julian H. Stacey wrote:
> > Anyoe else seeing this on current ?
> >=20
> > =3D=3D=3D> lib/libsysdecode (all)
> > env CPP=3D"cpp" MK_PF=3D"yes"  /bin/sh /usr/src/lib/libsysdecode/mkioctls=
>  /usr/include > ioctl.c.tmp
> > In file included from :97:
> > /usr/include/./sys/pioctl.h:45:2: warning: " is deprecated,=
>  ptrace() should be used instead"
> >   [-W#warnings]
> > #warning " is deprecated, ptrace() should be used instead"
> >  ^
> > 1 warning generated.
> > if [ ! -e ioctl.c ] || ! cmp -s ioctl.c ioctl.c.tmp; then  mv -f ioctl.c.=
> tmp ioctl.c;  fi
> > cc  -O2 -pipe -fno-common   -I/data/release/s1/usr/obj/usr/src/amd64.amd6=
> 4/lib/libsysdecode -I/usr/src/sys -I/usr/src/libexec/rtld-elf -DPF -g -MD  =
> -MF.depend.ioctl.o -MTioctl.o -std=3Dgnu99 -Wno-format-zero-length -fstack-=
> protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unu=
> sed-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wre=
> turn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter =
> -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls =
> -Wold-style-definition -Wno-pointer-sign -Wmissing-variable-declarations -W=
> thread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variab=
> le  -Qunused-arguments-c ioctl.c -o ioctl.o
> > In file included from ioctl.c:126:
> > /usr/include/./sys/pioctl.h:45:2: error: " is deprecated, p=
> trace() should be used instead"
> >   [-Werror,-W#warnings]
> > #warning " is deprecated, ptrace() should be used instead"
> 
> Hmm, I thought that the default removal of obsolete headers would at
> least get right of the header in WORLDTMP, but now I'm wondering if
> there's an additional boundary condition.  (I'm surprised there isn't a
> --sysroot in your compiler command which is presumably why you're
> getting the system sys/pioctl.h...)
> 
> You can do a clean build or work around it by removing ioctl.c in
> /lib/libsysdecode and /obj-lib32/lib/libsysdecode.

Thanks Brooks
World builds after:
cd /usr/src;make delete-old
remove /usr/include/sys/pioctl.h?

I had mistakenly omitted make delete-old
  (As I ran 2 sequential make worlds on progressively upgraded
  generic src/, without running my usual interleaved script
  http://berklix.com/~jhs/bin/.csh/customise which patches
  src/Makefile.inc1 so delete-old does not rm lots of things I want
  to retain eg:

   /etc/amd.map /etc/host.conf /etc/namedb
   /etc/namedb/PROTO.localhost-v6.rev /etc/namedb/PROTO.localhost.rev
   /etc/namedb/make-localhost /etc/newsyslog.conf.d/amd.conf
   /etc/rc.d/amd /etc/rc.d/nsswitch /usr/bin/pawd /usr/bin/rlogin
   /usr/bin/rsh /usr/include/sys/pioctl.h /usr/libexec/rlogind
   /usr/libexec/rshd /usr/sbin/amd /usr/sbin/amq /usr/sbin/mk-amd-map
   /usr/share/man/man1/pawd.1.gz /usr/share/man/man5/amd.conf.5.gz
   /usr/share/man/man8/amd.8.gz /usr/share/man/man8/amq.8.gz
   /usr/share/man/man8/mk-amd-map.8.gz
   /var/named/etc/namedb/PROTO.localhost.rev
   /var/named/etc/namedb/make-localhost /var/named/etc/namedb/named.root

To stop delete-old causing local damage, my customise applies an ugly diff
 
http://berklix.com/~jhs/src/bsd/fixes/FreeBSD/src/jhs/Makefile.inc1.releases.REL=CURRENT.diff

Better if we could enhance src/Makefile.inc1 delete-old to read a local list 
of exceptions, as does mergemaster from /etc/mergemaster.rc IGNORE_FILES=   ?

Cheers
--
Julian Stacey, Consultant Systems Engineer, BSD Linux http://berklix.com/jhs/
http://berklix.org/corona/   Brexit 31 Dec 2020 will damage UK & EU yet more.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: .debug files, skip?

[Andriy Gapon]

On 10/04/2020 09:55, Alexey Dokuchaev wrote:
> On Sun, Apr 05, 2020 at 07:41:38PM -0400, Ed Maste wrote:
>> On Sun, 5 Apr 2020 at 08:32, Jeffrey Bouquet wrote:
>>>
>>> A recent build[k,w] [ ** stable  12.1] and many .debug files I'd
>>> like to skip if poss. A knob?
>>
>> Yes, from src.conf(5):
>>  WITHOUT_DEBUG_FILES
>>  Set to avoid building or installing standalone debug
>>  files for each executable binary and shared library.
> 
> I have "MK_DEBUG_FILES=no" in /etc/make.conf, which one is more correct?

WITHOUT_.

See bsd.mkopt.mk.

# Users should generally define WITH_FOO or WITHOUT_FOO, but the build
# system should use MK_FOO={yes,no} when it needs to override the
# user's desires or default behavior.

-- 
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: 12-STABLE: BEARSSL: liblua compiler error: too few arguments to function call

[Hartmann, O.]

On Thu, 9 Apr 2020 22:07:59 -0700
"Simon J. Gerraty"  wrote:

> Hartmann, O.  wrote:
> 
> > While recent CURRENT doesn't show any problems, 12-STABLE (r359768)
> > drops out from buildworld with the error shown below when option
> > 
> > WITH_BEARSSL= YES  
> 
> Sorry, I did buildworld just before committing r359735
> but I use ficl, - missed the below for lua.
> Will fix.
> 
> > 
> > is set in /etc/src.conf
> > 
> > [...]
> > Building /usr/obj/usr/src/amd64.amd64/stand/liblua/lutils.o
> > --- lstd.o ---
> > /usr/src/stand/liblua/lstd.c:86:44: error: too few arguments to
> > function call, expected 5, have 4 if (verify_file(fd, filename, 0,
> > VE_GUESS) < 0) { ~~~  ^
> > /usr/src/lib/libsecureboot/h/verify_file.h:50:1: note:
> > 'verify_file'  

Thank you.
oh



pgplNrVJvjJ1D.pgp
Description: OpenPGP digital signature

Re: buildkernel failure because ctfconvert not installed

[Poul-Henning Kamp]

In message <9f03fb79-a0ad-3c11-9a50-bc7731882...@fastmail.com>, Yuri Pankov 
writes:
>Trond Endrestøl wrote:
>> On Thu, 9 Apr 2020 10:56+0200, Gary Jennejohn wrote:
>> 
>>> OK, I figured it out.
>>>
>>> I used to have MK_CTF=no in src.conf, but I recently changed it to
>>> WITH_CTF=no.
>> 
>> It's either WITH_xxx=yes or WITHOUT_xxx=yes.
>
>Or even WITH_xxx= or WITHOUT_xxx=, src.conf(5) explicitly states that 
>value is NOT checked:
>
>The values of variables are ignored regardless of their setting; even if 
>  they would be set to "FALSE" or "NO".  The presence of an option 
>causes it to be honored by make(1).

That is not even close to POLA-compliance...

Obviously negative values ("false", "no") should either be reported as
errors or preferably be respected.

PS: [This is not the bikeshed you are looking for]
 

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: .debug files, skip?

[Alexey Dokuchaev]

On Sun, Apr 05, 2020 at 07:41:38PM -0400, Ed Maste wrote:
> On Sun, 5 Apr 2020 at 08:32, Jeffrey Bouquet wrote:
> >
> > A recent build[k,w] [ ** stable  12.1] and many .debug files I'd
> > like to skip if poss. A knob?
> 
> Yes, from src.conf(5):
>  WITHOUT_DEBUG_FILES
>  Set to avoid building or installing standalone debug
>  files for each executable binary and shared library.

I have "MK_DEBUG_FILES=no" in /etc/make.conf, which one is more correct?

./danfe
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"