Re: svn commit: r343416 - head/bin/sh

[Larry Rosenman]

On 01/24/2019 8:34 pm, Rodney W. Grimes wrote:

In message , Devin
Teske writ
es:
>
>
> --Apple-Mail=_191072C8-B951-49CB-AA8D-792ADC82A31D
> Content-Transfer-Encoding: quoted-printable
> Content-Type: text/plain;
>charset=us-ascii
>
>
>
> > On Jan 24, 2019, at 5:35 PM, Cy Schubert  =
> wrote:
> >=20
> > Agreed re samples though a comment in the default should point the =
> user to samples. Samples could also include some nifty tricks too, some =
> of which are in fortune or Power Tools.
>
> What is this "Power Tools" you speak of (honest question)

UNIX Power Tools. It's an O'Reilly book that should have been entitled
Common Sense UNIX.


If I can find my copy you can have it Devin.

If you can't find yours, Rod, I can send mine.

--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r337791 - in head: crypto/openssl crypto/openssl/apps crypto/openssl/crypto crypto/openssl/crypto/asn1 crypto/openssl/crypto/bio crypto/openssl/crypto/bn crypto/openssl/crypto/bn/asm c

[Larry Rosenman]

On Thu, Aug 16, 2018 at 11:34:59AM -0700, Bryan Drewery wrote:
> On 8/16/18 11:21 AM, Larry Rosenman wrote:
> > On Thu, Aug 16, 2018 at 02:02:52PM -0400, Jung-uk Kim wrote:
> >> On 18. 8. 16., Larry Rosenman wrote:
> >>> On Thu, Aug 16, 2018 at 01:48:40PM -0400, Jung-uk Kim wrote:
> >>>> On 18. 8. 16., Ravi Pokala wrote:
> >>>>> -Original Message-
> >>>>> From:  on behalf of Jung-uk Kim 
> >>>>> 
> >>>>> Date: 2018-08-14, Tuesday at 10:48
> >>>>> To: , , 
> >>>>> 
> >>>>> Subject: svn commit: r337791 - in head: crypto/openssl 
> >>>>> crypto/openssl/apps crypto/openssl/crypto crypto/openssl/crypto/asn1 
> >>>>> crypto/openssl/crypto/bio crypto/openssl/crypto/bn 
> >>>>> crypto/openssl/crypto/bn/asm cr...
> >>>>>
> >>>>>> Author: jkim
> >>>>>> Date: Tue Aug 14 17:48:02 2018
> >>>>>> New Revision: 337791
> >>>>>> URL: https://svnweb.freebsd.org/changeset/base/337791
> >>>>>>
> >>>>>> Log:
> >>>>>>   Merge OpenSSL 1.0.2p.
> >>>>>
> >>>>> Is it just me, or did this change break all the worlds?
> >>>>>
> >>>>> I got errors like this:
> >>>>>
> >>>>> 
> >>>>> /usr/bin/ld: error: undefined symbol: main
> >>>>>>>> referenced by crt1.c:74 
> >>>>>>>> (/usr/home/rpokala/freebsd/clean/base/head/lib/csu/amd64/crt1.c:74)
> >>>>>>>>   
> >>>>>>>> /build/usr/home/rpokala/freebsd/clean/base/head/amd64.amd64/tmp/usr/lib/crt1.o:(_start)
> >>>>>
> >>>>> /usr/bin/ld: error: undefined symbol: Fssh_error
> >>>>>>>> referenced by moduli.c:257 
> >>>>>>>> (/usr/home/rpokala/freebsd/clean/base/head/crypto/openssh/moduli.c:257)
> >>>>>>>>   /tmp/moduli-6780ab.o:(Fssh_gen_candidates)
> >>>>> 
> >>>>>
> >>>>> At first I thought it was because I was rebuilding without cleaning, 
> >>>>> but I nuked the tree and rebuilt from scratch, and got the same error.
> >>>>>
> >>>>> I didn't bisect it to this change, but it's the only recent change to 
> >>>>> crypto...
> >>>>
> >>>> I built worlds many times and I haven't seen such problem.  In fact,
> >>>> Jenkins didn't break on amd64 after the commit.
> >>>>
> >>>> https://ci.freebsd.org/job/FreeBSD-head-amd64-build/9888/
> >>> Do you or jenkins run with meta-mode?  That seems to be a necessary
> >>> condition for the failure.
> >> I don't do meta-mode.  I don't know much about Jenkins build but I don't
> >> think it does.  Is it a requirement now?
> >>
> 
> Jenkins doesn't use META_MODE and it's not a requirement.

Can you (bdrewery@) possibly diagnose why meta-mode is messing this up
with the moduli file?

> 
> > It's not a requirement, but seems to be implicated in this failure.
> > 
> > Cc'ing bdrewery@ for the meta mode stuff.
> > 
> > 
> >> Jung-uk Kim
> >>
> > 
> > 
> > 
> > 
> 
> 
> -- 
> Regards,
> Bryan Drewery
> 




-- 
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 5708 Sabbia Drive, Round Rock, TX 78665-2106


signature.asc
Description: PGP signature

Re: svn commit: r337791 - in head: crypto/openssl crypto/openssl/apps crypto/openssl/crypto crypto/openssl/crypto/asn1 crypto/openssl/crypto/bio crypto/openssl/crypto/bn crypto/openssl/crypto/bn/asm c

[Larry Rosenman]

On Thu, Aug 16, 2018 at 02:02:52PM -0400, Jung-uk Kim wrote:
> On 18. 8. 16., Larry Rosenman wrote:
> > On Thu, Aug 16, 2018 at 01:48:40PM -0400, Jung-uk Kim wrote:
> >> On 18. 8. 16., Ravi Pokala wrote:
> >>> -Original Message-
> >>> From:  on behalf of Jung-uk Kim 
> >>> 
> >>> Date: 2018-08-14, Tuesday at 10:48
> >>> To: , , 
> >>> 
> >>> Subject: svn commit: r337791 - in head: crypto/openssl 
> >>> crypto/openssl/apps crypto/openssl/crypto crypto/openssl/crypto/asn1 
> >>> crypto/openssl/crypto/bio crypto/openssl/crypto/bn 
> >>> crypto/openssl/crypto/bn/asm cr...
> >>>
> >>>> Author: jkim
> >>>> Date: Tue Aug 14 17:48:02 2018
> >>>> New Revision: 337791
> >>>> URL: https://svnweb.freebsd.org/changeset/base/337791
> >>>>
> >>>> Log:
> >>>>   Merge OpenSSL 1.0.2p.
> >>>
> >>> Is it just me, or did this change break all the worlds?
> >>>
> >>> I got errors like this:
> >>>
> >>> 
> >>> /usr/bin/ld: error: undefined symbol: main
> >>>>>> referenced by crt1.c:74 
> >>>>>> (/usr/home/rpokala/freebsd/clean/base/head/lib/csu/amd64/crt1.c:74)
> >>>>>>   
> >>>>>> /build/usr/home/rpokala/freebsd/clean/base/head/amd64.amd64/tmp/usr/lib/crt1.o:(_start)
> >>>
> >>> /usr/bin/ld: error: undefined symbol: Fssh_error
> >>>>>> referenced by moduli.c:257 
> >>>>>> (/usr/home/rpokala/freebsd/clean/base/head/crypto/openssh/moduli.c:257)
> >>>>>>   /tmp/moduli-6780ab.o:(Fssh_gen_candidates)
> >>> 
> >>>
> >>> At first I thought it was because I was rebuilding without cleaning, but 
> >>> I nuked the tree and rebuilt from scratch, and got the same error.
> >>>
> >>> I didn't bisect it to this change, but it's the only recent change to 
> >>> crypto...
> >>
> >> I built worlds many times and I haven't seen such problem.  In fact,
> >> Jenkins didn't break on amd64 after the commit.
> >>
> >> https://ci.freebsd.org/job/FreeBSD-head-amd64-build/9888/
> > Do you or jenkins run with meta-mode?  That seems to be a necessary
> > condition for the failure.
> I don't do meta-mode.  I don't know much about Jenkins build but I don't
> think it does.  Is it a requirement now?
> 
It's not a requirement, but seems to be implicated in this failure.

Cc'ing bdrewery@ for the meta mode stuff.


> Jung-uk Kim
> 




-- 
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 5708 Sabbia Drive, Round Rock, TX 78665-2106


signature.asc
Description: PGP signature

Re: svn commit: r337791 - in head: crypto/openssl crypto/openssl/apps crypto/openssl/crypto crypto/openssl/crypto/asn1 crypto/openssl/crypto/bio crypto/openssl/crypto/bn crypto/openssl/crypto/bn/asm c

[Larry Rosenman]

On Thu, Aug 16, 2018 at 01:48:40PM -0400, Jung-uk Kim wrote:
> On 18. 8. 16., Ravi Pokala wrote:
> > -Original Message-
> > From:  on behalf of Jung-uk Kim 
> > 
> > Date: 2018-08-14, Tuesday at 10:48
> > To: , , 
> > 
> > Subject: svn commit: r337791 - in head: crypto/openssl crypto/openssl/apps 
> > crypto/openssl/crypto crypto/openssl/crypto/asn1 crypto/openssl/crypto/bio 
> > crypto/openssl/crypto/bn crypto/openssl/crypto/bn/asm cr...
> > 
> >> Author: jkim
> >> Date: Tue Aug 14 17:48:02 2018
> >> New Revision: 337791
> >> URL: https://svnweb.freebsd.org/changeset/base/337791
> >>
> >> Log:
> >>   Merge OpenSSL 1.0.2p.
> > 
> > Is it just me, or did this change break all the worlds?
> > 
> > I got errors like this:
> > 
> > 
> > /usr/bin/ld: error: undefined symbol: main
> >>>> referenced by crt1.c:74 
> >>>> (/usr/home/rpokala/freebsd/clean/base/head/lib/csu/amd64/crt1.c:74)
> >>>>   
> >>>> /build/usr/home/rpokala/freebsd/clean/base/head/amd64.amd64/tmp/usr/lib/crt1.o:(_start)
> > 
> > /usr/bin/ld: error: undefined symbol: Fssh_error
> >>>> referenced by moduli.c:257 
> >>>> (/usr/home/rpokala/freebsd/clean/base/head/crypto/openssh/moduli.c:257)
> >>>>   /tmp/moduli-6780ab.o:(Fssh_gen_candidates)
> > 
> > 
> > At first I thought it was because I was rebuilding without cleaning, but I 
> > nuked the tree and rebuilt from scratch, and got the same error.
> > 
> > I didn't bisect it to this change, but it's the only recent change to 
> > crypto...
> 
> I built worlds many times and I haven't seen such problem.  In fact,
> Jenkins didn't break on amd64 after the commit.
> 
> https://ci.freebsd.org/job/FreeBSD-head-amd64-build/9888/
Do you or jenkins run with meta-mode?  That seems to be a necessary
condition for the failure. 


> 
> Jung-uk Kim
> 




-- 
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 5708 Sabbia Drive, Round Rock, TX 78665-2106


signature.asc
Description: PGP signature

Re: svn commit: r337791 - in head: crypto/openssl crypto/openssl/apps crypto/openssl/crypto crypto/openssl/crypto/asn1 crypto/openssl/crypto/bio crypto/openssl/crypto/bn crypto/openssl/crypto/bn/asm c

[Larry Rosenman]

On Thu, Aug 16, 2018 at 10:42:42AM -0700, Ravi Pokala wrote:
> -Original Message-
> From:  on behalf of Jung-uk Kim 
> 
> Date: 2018-08-14, Tuesday at 10:48
> To: , , 
> 
> Subject: svn commit: r337791 - in head: crypto/openssl crypto/openssl/apps 
> crypto/openssl/crypto crypto/openssl/crypto/asn1 crypto/openssl/crypto/bio 
> crypto/openssl/crypto/bn crypto/openssl/crypto/bn/asm cr...
> 
> > Author: jkim
> > Date: Tue Aug 14 17:48:02 2018
> > New Revision: 337791
> > URL: https://svnweb.freebsd.org/changeset/base/337791
> > 
> > Log:
> >   Merge OpenSSL 1.0.2p.
> 
> Is it just me, or did this change break all the worlds?
> 
> I got errors like this:
> 
> 
> /usr/bin/ld: error: undefined symbol: main
> >>> referenced by crt1.c:74 
> >>> (/usr/home/rpokala/freebsd/clean/base/head/lib/csu/amd64/crt1.c:74)
> >>>   
> >>> /build/usr/home/rpokala/freebsd/clean/base/head/amd64.amd64/tmp/usr/lib/crt1.o:(_start)
> 
> /usr/bin/ld: error: undefined symbol: Fssh_error
> >>> referenced by moduli.c:257 
> >>> (/usr/home/rpokala/freebsd/clean/base/head/crypto/openssh/moduli.c:257)
> >>>   /tmp/moduli-6780ab.o:(Fssh_gen_candidates)
> 
> 
> At first I thought it was because I was rebuilding without cleaning, but I 
> nuked the tree and rebuilt from scratch, and got the same error.
> 
> I didn't bisect it to this change, but it's the only recent change to 
> crypto...
> 
see the discussion over on -current.  a 2nd svn up post the error will
fix it till the next one.


> -Ravi (rpokala@)
> 
> 
> _______
> svn-src-all@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/svn-src-all
> To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

-- 
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 5708 Sabbia Drive, Round Rock, TX 78665-2106


signature.asc
Description: PGP signature

Re: svn commit: r333919 - in head/contrib/file: . doc magic magic/Magdir python src tests

[Larry Rosenman]

On Sun, May 20, 2018 at 10:44:54PM +0200, Stefan Esser wrote:
> Am 20.05.18 um 22:30 schrieb Antoine Brodin:
> > On Sun, May 20, 2018 at 7:06 AM, Eitan Adler <ead...@freebsd.org> wrote:
> >> Author: eadler
> >> Date: Sun May 20 05:06:42 2018
> >> New Revision: 333919
> >> URL: https://svnweb.freebsd.org/changeset/base/333919
> >>
> >> Log:
> >>   MFV: file 5.33
> >>
> >>   Merge the latest file(1) in.
> >>
> >>   Relevent Changelog:
> >>   - extend the support for ${x?:} expansions for magic descriptions
> >>   - add support for ${x?:} in mime types to handle pie binaries.
> >>   - add support for negative offsets (offsets from the end of file)
> >>   - close the file on error when writing magic
> >>
> >>   Relnotes: yes
> > 
> > Hi,
> > 
> > This breaks the ports tree,  please revert and request an exp-run.
> 
> This seems to be the cause of LIB_DEPENDS not being correctly checked.
> 
> I have fixed this locally with the following patch to find-lib.sh:
> 
> Index: Mk/Scripts/find-lib.sh
> ===
> --- Mk/Scripts/find-lib.sh(Revision 470484)
> +++ Mk/Scripts/find-lib.sh(Arbeitskopie)
> @@ -27,7 +27,9 @@
>  for libdir in ${dirs} ; do
>   test -f ${libdir}/${lib} || continue
>   libfile=${libdir}/${lib}
> - [ `file -b -L --mime-type ${libfile}` = "application/x-sharedlib" ] || 
> continue
> - echo $libfile
> - break
> + case `file -b -L --mime-type ${libfile}` in
> + application/x-pie-executable|application/x-sharedlib)
> + echo $libfile
> + break ;;
> + esac
>  done
> 
> This works for amd64 at least ...

seems to work for me as well (also amd64). 


-- 
Larry Rosenman https://people.FreeBSD.org/~ler/
Phone: +1 214-642-9640 E-Mail: l...@freebsd.org
US Mail: 5708 Sabbia Drive, Round Rock, TX 78665-2106


signature.asc
Description: PGP signature

Re: svn commit: r318757 - head

[Larry Rosenman]

On 5/24/17, 1:01 PM, "O. Hartmann" <ohartm...@walstatt.org> wrote:

Am Wed, 24 May 2017 19:40:46 +0200
"O. Hartmann" <ohartm...@walstatt.org> schrieb:

> Am Wed, 24 May 2017 12:28:51 -0500
> Larry Rosenman <l...@lerctr.org> schrieb:
> 
> > I fixed my issues by force-rebuilding perl and all installed p5-* 
ports. 
> > 
> >   
> 
> 
> This isn't possible in my case :-(
> 
> lang/perl rebuilds all right, but every p5-* ports fails with
> 
> [...]
> Checking if your kit is complete...
> ListUtil.c: loadable library and perl binaries are mismatched (got 
handshake key
> 0xd200080, needed 0xdf00080) 
> *** Error code 1
> 
> I tried to rebuild also via portmaster -f, no success. Now, I growing 
bunch of ports
> showing up with this mysterious error.
> 
> To which port "ListUtil.c" might belong to?
> 
> Rebuilding autotools (which I suspected first) also fails ...
> 
> 

... it seems, as K. belousov mentioned prior regarding different ABI, all 
p5-* ports need
to be deleted by force ... They rebuild properly afterwards.

Which is essentially what I did re: Poudriere (poudriere bulk –C –j  -p 
 -f )

 


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

Re: svn commit: r318757 - head

[Larry Rosenman]

-- 
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281
 
 

On 5/24/17, 12:40 PM, "O. Hartmann" <ohartm...@walstatt.org> wrote:

Am Wed, 24 May 2017 12:28:51 -0500
    Larry Rosenman <l...@lerctr.org> schrieb:

> I fixed my issues by force-rebuilding perl and all installed p5-* ports. 
> 
> 


This isn't possible in my case :-(

lang/perl rebuilds all right, but every p5-* ports fails with

[...]
Checking if your kit is complete...
ListUtil.c: loadable library and perl binaries are mismatched (got 
handshake key
0xd200080, needed 0xdf00080) 
*** Error code 1

I tried to rebuild also via portmaster -f, no success. Now, I growing bunch 
of ports
showing up with this mysterious error.

To which port "ListUtil.c" might belong to?

Rebuilding autotools (which I suspected first) also fails ...


I rebuilt all in Poudriere and it was fine.




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

Re: svn commit: r318757 - head

[Larry Rosenman]

I fixed my issues by force-rebuilding perl and all installed p5-* ports. 


-- 
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281
 


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

Re: svn commit: r318757 - head

[Larry Rosenman]

The initial failure was NOT, except that the PostgreSQL build builds a PL/Perl 
interpreter that MIGHT
Be considered that.

It was unexpected.


-- 
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281
 
 

On 5/24/17, 8:33 AM, "Konstantin Belousov" <kostik...@gmail.com> wrote:

On Wed, May 24, 2017 at 08:06:34AM -0500, Larry Rosenman wrote:
> The initial failure:
> 
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=peripatus=2017-05-23%2019%3A17%3A42
> 
> I then recompiled perl, and got:
> borg.lerctr.org /home/pgbuildfarm $ cd /home/pgbuildfarm/bin/latest && 
./run_branches.pl --run-all --config=/home/pgbuildfarm/conf/build-farm.conf
> Socket.c: loadable library and perl binaries are mismatched (got 
handshake key 0xd200080, needed 0xdf00080)
> borg.lerctr.org /home/pgbuildfarm/bin/latest $
> 
> force rebuilding and installing perl and all p5-* ports fixed that. 
From what I understand in reading some perl bugs and perl source, perl
performs some validation of the structures shared between the perl
interpreter and XS libraries loaded into it. So I am almost sure that
you have perl itself and some module built against different src/ bases.

Is it true ?  If yes, then this is user error.  You are trying to mix
two binaries built against incompatible ABI.

> 
> 
> 
> -- 
> Larry Rosenman http://www.lerctr.org/~ler
> Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
> US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281
>  
>  
> 
> On 5/24/17, 4:05 AM, "Konstantin Belousov" <kostik...@gmail.com> wrote:
> 
> On Tue, May 23, 2017 at 04:46:14PM -0500, Larry Rosenman wrote:
> > My PostgreSQL buildfarm animal BROKE with this change until I force 
rebuilt
> > lang/perl5.24
> > and all my p5-* ports. 
> So what was the symptoms and the error, exactly ?
> 
> A lot of efforts were spent to ensure that _consistent_ set of old 
binaries
> and libraries would run without issues on the new system.  I mean that
> if you have binaries and libraries built on pre-ino64 system, which do
> not reference any libraries built on post ino64, except system 
libraries
> (like libc/libthr etc), everything should work.  This feature was the
> main cause of long delay finishing ino64.
> 
> > 
> > emulators/qemu-user-static also won???t compile (sbruno@ is on this 
one).
> This is a separate issue.
> 
> > 
> > Poudriere did *NOT* force a fuill rebuild even though 
freebsd-version *WAS* bumped. 
> > 
    > > Is there a hazard for others here?
> > 
> > Or more info needed in /usr/{src,ports}/UPDATING?
> > 
> > 
> > -- 
> > Larry Rosenman http://www.lerctr.org/~ler
> > Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
> > US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281
> >   
> > 
> > 
> > 
> 
> 



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

Re: svn commit: r318757 - head

[Larry Rosenman]

The initial failure:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=peripatus=2017-05-23%2019%3A17%3A42

I then recompiled perl, and got:
borg.lerctr.org /home/pgbuildfarm $ cd /home/pgbuildfarm/bin/latest && 
./run_branches.pl --run-all --config=/home/pgbuildfarm/conf/build-farm.conf
Socket.c: loadable library and perl binaries are mismatched (got handshake key 
0xd200080, needed 0xdf00080)
borg.lerctr.org /home/pgbuildfarm/bin/latest $

force rebuilding and installing perl and all p5-* ports fixed that. 



-- 
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281
 
 

On 5/24/17, 4:05 AM, "Konstantin Belousov" <kostik...@gmail.com> wrote:

On Tue, May 23, 2017 at 04:46:14PM -0500, Larry Rosenman wrote:
> My PostgreSQL buildfarm animal BROKE with this change until I force 
rebuilt
> lang/perl5.24
> and all my p5-* ports. 
So what was the symptoms and the error, exactly ?

A lot of efforts were spent to ensure that _consistent_ set of old binaries
and libraries would run without issues on the new system.  I mean that
if you have binaries and libraries built on pre-ino64 system, which do
not reference any libraries built on post ino64, except system libraries
(like libc/libthr etc), everything should work.  This feature was the
main cause of long delay finishing ino64.

> 
> emulators/qemu-user-static also won???t compile (sbruno@ is on this one).
This is a separate issue.

> 
> Poudriere did *NOT* force a fuill rebuild even though freebsd-version 
*WAS* bumped. 
> 
> Is there a hazard for others here?
> 
> Or more info needed in /usr/{src,ports}/UPDATING?
> 
> 
> -- 
> Larry Rosenman http://www.lerctr.org/~ler
> Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
> US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281
>   
> 
> 
> 



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

Re: svn commit: r318757 - head

[Larry Rosenman]

borg.lerctr.org /home/ler $ sudo poudriere jail -l
JAILNAME   VERSION  ARCH  METHOD   TIMESTAMP   PATH
p103amd64  10.3-RELEASE-p18 amd64 http 2017-04-23 08:39:24 
/usr/local/poudriere/jails/p103amd64
p103i386   10.3-RELEASE-p18 i386  http 2017-04-23 08:40:44 
/usr/local/poudriere/jails/p103i386
p110amd64  11.0-RELEASE-p10 amd64 http 2017-05-15 14:54:58 
/usr/local/poudriere/jails/p110amd64
p110i386   11.0-RELEASE-p9  i386  http 2017-04-23 08:41:48 
/usr/local/poudriere/jails/p110i386
live   12.0-CURRENT amd64 src=/usr/src 2017-05-23 13:39:40 
/usr/local/poudriere/jails/live
pHEADamd64 12.0-CURRENT amd64 src=/usr/src 2017-04-24 17:15:13 
/usr/local/poudriere/jails/pHEADamd64
p120armv6  12.0-CURRENT r317340 arm.armv6 svn+https2017-04-23 10:07:40 
/usr/local/poudriere/jails/p110borg.lerctr.org 
/usr/local/etc/poudriere.d/jails/live $ cat version
12.0-CURRENT
borg.lerctr.org /usr/local/etc/poudriere.d/jails/live $armv6
borg.lerctr.org /home/ler $


borg.lerctr.org /usr/local/poudriere/data/packages/live-host-ports $ cat 
.jailversion
12.0-CURRENT
borg.lerctr.org /usr/local/poudriere/data/packages/live-host-ports $



-- 
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281
 
 

On 5/23/17, 6:08 PM, "Bryan Drewery" <bdrew...@freebsd.org> wrote:

On 5/23/2017 2:46 PM, Larry Rosenman wrote:
> My PostgreSQL buildfarm animal BROKE with this change until I force 
rebuilt
> lang/perl5.24
> and all my p5-* ports. 
> 
> emulators/qemu-user-static also won’t compile (sbruno@ is on this one).
> 
> Poudriere did *NOT* force a fuill rebuild even though freebsd-version 
*WAS* bumped. 
> 

It should have.
What version are you using?
Can you show output of 'poudriere jail -l' please?
And show /usr/local/etc/poudriere.d/jails/JAILNAME/version
And show the .jailversion output from your PACKAGES directory.

> Is there a hazard for others here?
> 
> Or more info needed in /usr/{src,ports}/UPDATING?
> 
> 


-- 
Regards,
Bryan Drewery




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

Re: svn commit: r318757 - head

[Larry Rosenman]

My PostgreSQL buildfarm animal BROKE with this change until I force rebuilt
lang/perl5.24
and all my p5-* ports. 

emulators/qemu-user-static also won’t compile (sbruno@ is on this one).

Poudriere did *NOT* force a fuill rebuild even though freebsd-version *WAS* 
bumped. 

Is there a hazard for others here?

Or more info needed in /usr/{src,ports}/UPDATING?


-- 
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281
  


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

Re: svn commit: r317061 - in head: libexec/rpc.rstatd sys/amd64/amd64 sys/amd64/include sys/arm/arm sys/arm/include sys/arm64/include sys/cddl/contrib/opensolaris/uts/common/fs/zfs sys/compat/linprocf

[Larry Rosenman]

On 4/18/17, 2:58 PM, "Alan Somers"  wrote:

On Mon, Apr 17, 2017 at 11:34 AM, Gleb Smirnoff  wrote:
> Author: glebius
> Date: Mon Apr 17 17:34:47 2017
> New Revision: 317061
> URL: https://svnweb.freebsd.org/changeset/base/317061
>
> Log:
>   - Remove 'struct vmmeter' from 'struct pcpu', leaving only global 
vmmeter
> in place.  To do per-cpu stats, convert all fields that previously 
were
> maintained in the vmmeters that sit in pcpus to counter(9).
>   - Since some vmmeter stats may be touched at very early stages of boot,
> before we have set up UMA and we can do counter_u64_alloc(), provide 
an
> early counter mechanism:
> o Leave one spare uint64_t in struct pcpu, named 
pc_early_dummy_counter.
> o Point counter(9) fields of vmmeter to 
pcpu[0].pc_early_dummy_counter,
>   so that at early stages of boot, before counters are allocated we 
already
>   point to a counter that can be safely written to.
> o For sparc64 that required a whole dummy pcpu[MAXCPU] array.
>
>   Further related changes:
>   - Don't include vmmeter.h into pcpu.h.
>   - vm.stats.vm.v_swappgsout and vm.stats.vm.v_swappgsin changed to 
64-bit,
> to match kernel representation.
>   - struct vmmeter hidden under _KERNEL, and only vmstat(1) is an 
exclusion.
>
>   This is based on benno@'s 4-year old patch:
>   https://lists.freebsd.org/pipermail/freebsd-arch/2013-July/014471.html
>
>   Reviewed by:  kib, gallatin, marius, lidl
>   Differential Revision:https://reviews.freebsd.org/D10156
>
This change broke backwards compatibility with old top binaries.  When
I use a kernel at version 317094 but a top from 14-April, I get the
error "top: sysctl(vm.stats.vm.v_swappgsin...) failed: Cannot allocate
memory".  I get the same error when running top from an 11.0-RELEASE
jail.  Can you please add backward compatibility shims?

-Alan
It also broke emulators/virtualbox-ose-kmod 



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

Re: svn commit: r316874 - head/sys/kern

[Larry Rosenman]

This looks MUCH better, startup was it’s usual speedy self.

 

 

-- 

Larry Rosenman http://www.lerctr.org/~ler

Phone: +1 214-642-9640 E-Mail: l...@lerctr.org

US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281

 

 

 

From: Maksym Sobolyev <sobo...@sippysoft.com> on behalf of Maxim Sobolev 
<sobo...@freebsd.org>
Date: Saturday, April 15, 2017 at 1:22 PM
To: "O. Hartmann" <ohartm...@walstatt.org>
Cc: Larry Rosenman <l...@lerctr.org>, Peter Wemm <pe...@wemm.org>, 
src-committers <src-committ...@freebsd.org>, <svn-src-all@freebsd.org>, Hiroki 
Sato <h...@freebsd.org>, Hiren Panchasara <hi...@freebsd.org>, 
<svn-src-h...@freebsd.org>, Ngie Cooper <yaneurab...@gmail.com>
Subject: Re: svn commit: r316874 - head/sys/kern

 

I've committed another fix for the syslogd code in question which should 
hopefully make it functional again. Peter, please let me know if you still 
having any issues. Thanks!

 

-Max

 

On Sat, Apr 15, 2017 at 8:46 AM, O. Hartmann <ohartm...@walstatt.org> wrote:

Am Sat, 15 Apr 2017 08:05:23 -0500
Larry Rosenman <l...@lerctr.org> schrieb:


> On 4/15/17, 6:00 AM, "Maxim Sobolev" <owner-svn-src-...@freebsd.org on behalf 
> of
> sobo...@freebsd.org> wrote:
>
> Peter, Ngie, none of this stuff is really directly related to the
> shutdown(2) change, so I'll probably let Hiroki to clean it up.
>
> -Max
>
>
> I’ve backed off to my previous root.  Is someone working on this?  It’s 
> PAINFUL.
>

[...]

Processes do not even hang when system is booting/spinning up.

On my router project, I've running asterisk13 on a small appliance. Starting 
asterisk
with "service asterisk start" starts the service, but then, stopping the 
service calling
"service asterisk stop" reports

Asterisk ending (0).

but the process is still running as top reveals:

  PID USERNAME   THR PRI NICE   SIZERES STATE   C   TIMEWCPU COMMAN
 1352 asterisk19  520   105M 25284K uwrlck  3  17:40  67.94% asteri
[...]

This is weird :-(

kill -9 1352 works. Finally.

Regards,
Oliver
--
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).

 

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

Re: svn commit: r316874 - head/sys/kern

[Larry Rosenman]

On 4/15/17, 6:00 AM, "Maxim Sobolev"  wrote:

Peter, Ngie, none of this stuff is really directly related to the
shutdown(2) change, so I'll probably let Hiroki to clean it up.

-Max
 

I’ve backed off to my previous root.  Is someone working on this?  It’s PAINFUL.



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

Re: svn commit: r316938 - head/sbin/savecore

[Larry Rosenman]

On 4/14/17, 9:16 PM, "Conrad Meyer" <c...@freebsd.org> wrote:

On Fri, Apr 14, 2017 at 7:02 PM, Larry Rosenman <l...@lerctr.org> wrote:
> It looked like the netdump code might need some stuff for current 
–CURRENT.

Not for the server (netdumpd) — it's just a simple UDP daemon that
writes incoming UDP streams to disk.

Best,
Conrad


I was referring to the code to actually dump to netdumpd.



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

Re: svn commit: r316938 - head/sbin/savecore

[Larry Rosenman]

It looked like the netdump code might need some stuff for current –CURRENT. 


-- 
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281
 
 

On 4/14/17, 9:00 PM, "Conrad Meyer" <c...@freebsd.org> wrote:

Larry,

You just need to run netdumpd on the nearby server.  It could be a
port (although I'm not aware that it is ported yet).

Best,
Conrad

On Fri, Apr 14, 2017 at 6:37 PM, Larry Rosenman <l...@lerctr.org> wrote:
> On 4/14/17, 8:35 PM, "Rodney W. Grimes" <free...@pdx.rh.cn85.dnsmgr.net> 
wrote:
>
>> Yeah, I have the following:
> > borg.lerctr.org /home/ler $ swapctl -l
> > Device:   1024-blocks Used:
> > /dev/mfid0p38388608 0
> > /dev/mfid1p38388608 0
> > /dev/mfid2p38388608 0
> > /dev/mfid3p38388608 0
> > /dev/mfid4p38388608 0
> > /dev/mfid5p38388608 0
> > borg.lerctr.org /home/ler $ sysctl hw.physmem
> > hw.physmem: 137368682496
> > borg.lerctr.org /home/ler $
> >
> > SO 6 8G partitions (48G), but the dump is larger than 8G.
>
> Larry,
>   This is a very good concern and point given todays more
> common huge memory foot prints and lots of spindles.  I'll
> keep this in they back of my mind as I tromp around in the
> dump code.  I have another solution that may work for you
> and that is to use Netdump rather than swapdump.  This
> basically eliminates the trip to swap space and you end
> up going to savecore style output on the netdump server.
>
> --
> Rod Grimes 
rgri...@freebsd.org
>
> What does it take for NetDump to work to a FreeNAS (9.10 nightly) server 
since that’s what is “next to” this server?
>
>
>



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

Re: svn commit: r316938 - head/sbin/savecore

[Larry Rosenman]

On 4/14/17, 8:59 PM, "Rodney W. Grimes"  wrote:

> On 4/14/17, 8:35 PM, "Rodney W. Grimes"  
wrote:
> 
> > Yeah, I have the following:
> > borg.lerctr.org /home/ler $ swapctl -l
> > Device:   1024-blocks Used:
> > /dev/mfid0p38388608 0
> > /dev/mfid1p38388608 0
> > /dev/mfid2p38388608 0
> > /dev/mfid3p38388608 0
> > /dev/mfid4p38388608 0
> > /dev/mfid5p38388608 0
> > borg.lerctr.org /home/ler $ sysctl hw.physmem
> > hw.physmem: 137368682496
> > borg.lerctr.org /home/ler $
> > 
> > SO 6 8G partitions (48G), but the dump is larger than 8G. 
> 
> Larry,
>   This is a very good concern and point given todays more
> common huge memory foot prints and lots of spindles.  I'll
> keep this in they back of my mind as I tromp around in the
> dump code.  I have another solution that may work for you
> and that is to use Netdump rather than swapdump.  This
> basically eliminates the trip to swap space and you end
> up going to savecore style output on the netdump server.
> 
> -- 
> Rod Grimes 
rgri...@freebsd.org
> 
> What does it take for NetDump to work to a FreeNAS (9.10 nightly) server 
since that?s what is ?next to? this server?  

As a netdump server FreeNAS would be fairly trivial to compile the netdump
client code for.I should have running 11.0 and 10.2 code around
some place.

-- 
Rod Grimes 
rgri...@freebsd.org

I’m also running:
borg.lerctr.org /home/ler $ uname -a
FreeBSD borg.lerctr.org 12.0-CURRENT FreeBSD 12.0-CURRENT #23 r316945: Fri Apr 
14 18:37:13 CDT 2017 r...@borg.lerctr.org:/usr/obj/usr/src/sys/VT-LER  amd64
borg.lerctr.org /home/ler $




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

Re: svn commit: r316938 - head/sbin/savecore

[Larry Rosenman]

On 4/14/17, 8:35 PM, "Rodney W. Grimes"  wrote:

> Yeah, I have the following:
> borg.lerctr.org /home/ler $ swapctl -l
> Device:   1024-blocks Used:
> /dev/mfid0p38388608 0
> /dev/mfid1p38388608 0
> /dev/mfid2p38388608 0
> /dev/mfid3p38388608 0
> /dev/mfid4p38388608 0
> /dev/mfid5p38388608 0
> borg.lerctr.org /home/ler $ sysctl hw.physmem
> hw.physmem: 137368682496
> borg.lerctr.org /home/ler $
> 
> SO 6 8G partitions (48G), but the dump is larger than 8G. 

Larry,
  This is a very good concern and point given todays more
common huge memory foot prints and lots of spindles.  I'll
keep this in they back of my mind as I tromp around in the
dump code.  I have another solution that may work for you
and that is to use Netdump rather than swapdump.  This
basically eliminates the trip to swap space and you end
up going to savecore style output on the netdump server.

-- 
Rod Grimes 
rgri...@freebsd.org

What does it take for NetDump to work to a FreeNAS (9.10 nightly) server since 
that’s what is “next to” this server?  


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

Re: svn commit: r316938 - head/sbin/savecore

[Larry Rosenman]

On 4/14/17, 3:46 PM, "Ngie Cooper (yaneurabeya)" <yaneurab...@gmail.com> wrote:


> On Apr 14, 2017, at 13:43, Larry Rosenman <l...@lerctr.org> wrote:
> 
> On 4/14/17, 3:39 PM, "Ngie Cooper (yaneurabeya)" 
<owner-svn-src-...@freebsd.org on behalf of yaneurab...@gmail.com> wrote:
> 
>> On Apr 14, 2017, at 13:37, Larry Rosenman <l...@lerctr.org> wrote:
>> 
>> On 4/14/17, 3:33 PM, "Ngie Cooper (yaneurabeya)" <yaneurab...@gmail.com> 
wrote:
>> 
>>> On Apr 14, 2017, at 13:26, Larry Rosenman <l...@lerctr.org> wrote:
>>> 
>>> On 4/14/17, 3:19 PM, "Ngie Cooper (yaneurabeya)" 
<owner-svn-src-...@freebsd.org on behalf of yaneurab...@gmail.com> wrote:
>>> 
>>>> On Apr 14, 2017, at 13:14, Slawa Olhovchenkov <s...@zxy.spb.ru> wrote:
>>>> 
>>>> On Fri, Apr 14, 2017 at 01:49:51PM -0600, Alan Somers wrote:
>>>> 
>>>>> On Fri, Apr 14, 2017 at 1:41 PM, Ngie Cooper <n...@freebsd.org> wrote:
>>>>>> Author: ngie
>>>>>> Date: Fri Apr 14 19:41:48 2017
>>>>>> New Revision: 316938
>>>>>> URL: https://svnweb.freebsd.org/changeset/base/316938
>>>>>> 
>>>>>> Log:
>>>>>> savecore: fix space calculation with respect to `minfree` in 
check_space(..)
>>>>>> 
>>>>>> - Use strtoll(3) instead of atoi(3), because atoi(3) limits the
>>>>>> representable data to INT_MAX. Check the values received from
>>>>>> strtoll(3), trimming trailing whitespace off the end to maintain
>>>>>> POLA.
>>>>>> - Use `KiB` instead of `kB` when describing free space, total space,
>>>>>> etc. I am now fully aware of `KiB` being the IEC standard for 1024
>>>>>> bytes and `kB` being the IEC standard for 1000 bytes.
>>>>>> - Store available number of KiB in `available` so it can be more
>>>>>> easily queried and compared to ensure that there are enough KiB to
>>>>>> store the dump image on disk.
>>>>>> - Print out the reserved space on disk, per `minfree`, so end-users
>>>>>> can troubleshoot why check_space(..) is reporting that there isn't
>>>>>> enough free space.
>>>>>> 
>>>>>> MFC after:7 weeks
>>>>>> Reviewed by:  Anton Rang <r...@acm.com> (earlier diff), cem (earlier 
diff)
>>>>>> Tested with:  positive/negative cases (see review); make tinderbox
>>>>>> Sponsored by: Dell EMC Isilon
>>>>>> Differential Revision:D10379
>>>>> 
>>>>> The free space calculation is still uselessly conservative, because it
>>>>> doesn't account for the fact that core dumps will always be either
>>>>> spare or compressed.  The result is that savecore will frequently
>>>>> refuse to save corefiles even when there's plenty of space.  I
>>>>> proposed removing the space check altogether in
>>>>> https://reviews.freebsd.org/D2587.  However, I agreed to wait until
>>>>> after the compressed core dump feature was merged, because then mostly
>>>>> accurate space checks will be possible.  AFAIK the compressed core
>>>>> dump feature still hasn't been finished.
>>>> 
>>>> Is posible (in the future) to use multiple swaps (on multiple disks)
>>>> for save core dumps?
>>> 
>>>  Multiple swap devices is already handled by savecore(8), if one uses 
fstab(5) or dumpon(8). Otherwise, you must invoke savecore(8) on individual 
devices.
>>> 
>>>  As far as saving to multiple disks is concerned, I would hope that one 
is using a redundancy capable filesystem (zfs) or RAID-like technology 
(gmirror, graid, LSI Fusion’s RAID product line) to stripe and/or mirror the 
data across multiple disks.
>> 
>>   …
>> 
>>> How do I use multiple devices to have the system dump on all of my 
swap?  I got a message about not enough space, but there (I think) was enough 
between multiple drives….
>> 
>>   Something like:
>> 
>>   - Create a zpool
>>   - Mount zpool to /crashdumps
>>   - Change dumpdir in /etc/rc.conf to be /crashdumps, 

Re: svn commit: r316938 - head/sbin/savecore

[Larry Rosenman]

On 4/14/17, 3:39 PM, "Ngie Cooper (yaneurabeya)" <owner-svn-src-...@freebsd.org 
on behalf of yaneurab...@gmail.com> wrote:


> On Apr 14, 2017, at 13:37, Larry Rosenman <l...@lerctr.org> wrote:
> 
> On 4/14/17, 3:33 PM, "Ngie Cooper (yaneurabeya)" <yaneurab...@gmail.com> 
wrote:
> 
>> On Apr 14, 2017, at 13:26, Larry Rosenman <l...@lerctr.org> wrote:
>> 
>> On 4/14/17, 3:19 PM, "Ngie Cooper (yaneurabeya)" 
<owner-svn-src-...@freebsd.org on behalf of yaneurab...@gmail.com> wrote:
>> 
>>> On Apr 14, 2017, at 13:14, Slawa Olhovchenkov <s...@zxy.spb.ru> wrote:
>>> 
>>> On Fri, Apr 14, 2017 at 01:49:51PM -0600, Alan Somers wrote:
>>> 
>>>> On Fri, Apr 14, 2017 at 1:41 PM, Ngie Cooper <n...@freebsd.org> wrote:
>>>>> Author: ngie
>>>>> Date: Fri Apr 14 19:41:48 2017
>>>>> New Revision: 316938
>>>>> URL: https://svnweb.freebsd.org/changeset/base/316938
>>>>> 
>>>>> Log:
>>>>> savecore: fix space calculation with respect to `minfree` in 
check_space(..)
>>>>> 
>>>>> - Use strtoll(3) instead of atoi(3), because atoi(3) limits the
>>>>>  representable data to INT_MAX. Check the values received from
>>>>>  strtoll(3), trimming trailing whitespace off the end to maintain
>>>>>  POLA.
>>>>> - Use `KiB` instead of `kB` when describing free space, total space,
>>>>>  etc. I am now fully aware of `KiB` being the IEC standard for 1024
>>>>>  bytes and `kB` being the IEC standard for 1000 bytes.
>>>>> - Store available number of KiB in `available` so it can be more
>>>>>  easily queried and compared to ensure that there are enough KiB to
>>>>>  store the dump image on disk.
>>>>> - Print out the reserved space on disk, per `minfree`, so end-users
>>>>>  can troubleshoot why check_space(..) is reporting that there isn't
>>>>>  enough free space.
>>>>> 
>>>>> MFC after:7 weeks
>>>>> Reviewed by:  Anton Rang <r...@acm.com> (earlier diff), cem (earlier 
diff)
>>>>> Tested with:  positive/negative cases (see review); make tinderbox
>>>>> Sponsored by: Dell EMC Isilon
>>>>> Differential Revision:D10379
>>>> 
>>>> The free space calculation is still uselessly conservative, because it
>>>> doesn't account for the fact that core dumps will always be either
>>>> spare or compressed.  The result is that savecore will frequently
>>>> refuse to save corefiles even when there's plenty of space.  I
>>>> proposed removing the space check altogether in
>>>> https://reviews.freebsd.org/D2587.  However, I agreed to wait until
>>>> after the compressed core dump feature was merged, because then mostly
>>>> accurate space checks will be possible.  AFAIK the compressed core
>>>> dump feature still hasn't been finished.
>>> 
>>> Is posible (in the future) to use multiple swaps (on multiple disks)
>>> for save core dumps?
>> 
>>   Multiple swap devices is already handled by savecore(8), if one uses 
fstab(5) or dumpon(8). Otherwise, you must invoke savecore(8) on individual 
devices.
>> 
>>   As far as saving to multiple disks is concerned, I would hope that one 
is using a redundancy capable filesystem (zfs) or RAID-like technology 
(gmirror, graid, LSI Fusion’s RAID product line) to stripe and/or mirror the 
data across multiple disks.
> 
>…
> 
>> How do I use multiple devices to have the system dump on all of my swap? 
 I got a message about not enough space, but there (I think) was enough between 
multiple drives….
> 
>Something like:
> 
>- Create a zpool
>- Mount zpool to /crashdumps
>- Change dumpdir in /etc/rc.conf to be /crashdumps, e.g., echo 
‘dumpdir=/crashdumps’
> 
>?
>HTH,
>-Ngie
> 
>PS The issue with lack of space might be the issue that Alan brought 
up earlier with compressed dumps and overly conservative free space checks, or 
it might be the fact that dumpdir (default: /var/crash) is full.
> 
> 
> I was talking about the actual crashdump to swap by the system.  
/var/crash has 10T of space (my 

Re: svn commit: r316938 - head/sbin/savecore

[Larry Rosenman]

On 4/14/17, 3:33 PM, "Ngie Cooper (yaneurabeya)" <yaneurab...@gmail.com> wrote:


> On Apr 14, 2017, at 13:26, Larry Rosenman <l...@lerctr.org> wrote:
> 
> On 4/14/17, 3:19 PM, "Ngie Cooper (yaneurabeya)" 
<owner-svn-src-...@freebsd.org on behalf of yaneurab...@gmail.com> wrote:
> 
>> On Apr 14, 2017, at 13:14, Slawa Olhovchenkov <s...@zxy.spb.ru> wrote:
>> 
>> On Fri, Apr 14, 2017 at 01:49:51PM -0600, Alan Somers wrote:
>> 
>>> On Fri, Apr 14, 2017 at 1:41 PM, Ngie Cooper <n...@freebsd.org> wrote:
>>>> Author: ngie
>>>> Date: Fri Apr 14 19:41:48 2017
>>>> New Revision: 316938
>>>> URL: https://svnweb.freebsd.org/changeset/base/316938
>>>> 
>>>> Log:
>>>> savecore: fix space calculation with respect to `minfree` in 
check_space(..)
>>>> 
>>>> - Use strtoll(3) instead of atoi(3), because atoi(3) limits the
>>>>   representable data to INT_MAX. Check the values received from
>>>>   strtoll(3), trimming trailing whitespace off the end to maintain
>>>>   POLA.
>>>> - Use `KiB` instead of `kB` when describing free space, total space,
>>>>   etc. I am now fully aware of `KiB` being the IEC standard for 1024
>>>>   bytes and `kB` being the IEC standard for 1000 bytes.
>>>> - Store available number of KiB in `available` so it can be more
>>>>   easily queried and compared to ensure that there are enough KiB to
>>>>   store the dump image on disk.
>>>> - Print out the reserved space on disk, per `minfree`, so end-users
>>>>   can troubleshoot why check_space(..) is reporting that there isn't
>>>>   enough free space.
>>>> 
>>>> MFC after:7 weeks
>>>> Reviewed by:  Anton Rang <r...@acm.com> (earlier diff), cem (earlier 
diff)
>>>> Tested with:  positive/negative cases (see review); make tinderbox
>>>> Sponsored by: Dell EMC Isilon
>>>> Differential Revision:D10379
>>> 
>>> The free space calculation is still uselessly conservative, because it
>>> doesn't account for the fact that core dumps will always be either
>>> spare or compressed.  The result is that savecore will frequently
>>> refuse to save corefiles even when there's plenty of space.  I
>>> proposed removing the space check altogether in
>>> https://reviews.freebsd.org/D2587.  However, I agreed to wait until
>>> after the compressed core dump feature was merged, because then mostly
>>> accurate space checks will be possible.  AFAIK the compressed core
>>> dump feature still hasn't been finished.
>> 
>> Is posible (in the future) to use multiple swaps (on multiple disks)
>> for save core dumps?
> 
>Multiple swap devices is already handled by savecore(8), if one uses 
fstab(5) or dumpon(8). Otherwise, you must invoke savecore(8) on individual 
devices.
> 
>As far as saving to multiple disks is concerned, I would hope that one 
is using a redundancy capable filesystem (zfs) or RAID-like technology 
(gmirror, graid, LSI Fusion’s RAID product line) to stripe and/or mirror the 
data across multiple disks.

…

> How do I use multiple devices to have the system dump on all of my swap?  
I got a message about not enough space, but there (I think) was enough between 
multiple drives….

Something like:

- Create a zpool
- Mount zpool to /crashdumps
- Change dumpdir in /etc/rc.conf to be /crashdumps, e.g., echo 
‘dumpdir=/crashdumps’

?
HTH,
-Ngie

PS The issue with lack of space might be the issue that Alan brought up 
earlier with compressed dumps and overly conservative free space checks, or it 
might be the fact that dumpdir (default: /var/crash) is full.


I was talking about the actual crashdump to swap by the system.  /var/crash has 
10T of space (my root pool).




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

Re: svn commit: r316938 - head/sbin/savecore

[Larry Rosenman]

On 4/14/17, 3:19 PM, "Ngie Cooper (yaneurabeya)"  wrote:


> On Apr 14, 2017, at 13:14, Slawa Olhovchenkov  wrote:
> 
> On Fri, Apr 14, 2017 at 01:49:51PM -0600, Alan Somers wrote:
> 
>> On Fri, Apr 14, 2017 at 1:41 PM, Ngie Cooper  wrote:
>>> Author: ngie
>>> Date: Fri Apr 14 19:41:48 2017
>>> New Revision: 316938
>>> URL: https://svnweb.freebsd.org/changeset/base/316938
>>> 
>>> Log:
>>>  savecore: fix space calculation with respect to `minfree` in 
check_space(..)
>>> 
>>>  - Use strtoll(3) instead of atoi(3), because atoi(3) limits the
>>>representable data to INT_MAX. Check the values received from
>>>strtoll(3), trimming trailing whitespace off the end to maintain
>>>POLA.
>>>  - Use `KiB` instead of `kB` when describing free space, total space,
>>>etc. I am now fully aware of `KiB` being the IEC standard for 1024
>>>bytes and `kB` being the IEC standard for 1000 bytes.
>>>  - Store available number of KiB in `available` so it can be more
>>>easily queried and compared to ensure that there are enough KiB to
>>>store the dump image on disk.
>>>  - Print out the reserved space on disk, per `minfree`, so end-users
>>>can troubleshoot why check_space(..) is reporting that there isn't
>>>enough free space.
>>> 
>>>  MFC after:7 weeks
>>>  Reviewed by:  Anton Rang  (earlier diff), cem (earlier 
diff)
>>>  Tested with:  positive/negative cases (see review); make tinderbox
>>>  Sponsored by: Dell EMC Isilon
>>>  Differential Revision:D10379
>> 
>> The free space calculation is still uselessly conservative, because it
>> doesn't account for the fact that core dumps will always be either
>> spare or compressed.  The result is that savecore will frequently
>> refuse to save corefiles even when there's plenty of space.  I
>> proposed removing the space check altogether in
>> https://reviews.freebsd.org/D2587.  However, I agreed to wait until
>> after the compressed core dump feature was merged, because then mostly
>> accurate space checks will be possible.  AFAIK the compressed core
>> dump feature still hasn't been finished.
> 
> Is posible (in the future) to use multiple swaps (on multiple disks)
> for save core dumps?

Multiple swap devices is already handled by savecore(8), if one uses 
fstab(5) or dumpon(8). Otherwise, you must invoke savecore(8) on individual 
devices.

As far as saving to multiple disks is concerned, I would hope that one is 
using a redundancy capable filesystem (zfs) or RAID-like technology (gmirror, 
graid, LSI Fusion’s RAID product line) to stripe and/or mirror the data across 
multiple disks.



Thanks!
-Ngie

How do I use multiple devices to have the system dump on all of my swap?  I got 
a message about not enough space, but there (I think) was enough between 
multiple drives….




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

svn commit: r311859 - head/usr.bin/calendar/calendars

[Larry Rosenman]

Author: ler (ports committer)
Date: Tue Jan 10 05:37:53 2017
New Revision: 311859
URL: https://svnweb.freebsd.org/changeset/base/311859

Log:
  Add my birthday to calendar.freebsd
  
  Approved by:  adamw (Mentor)
  Differential Revision:https://reviews.freebsd.org/D9119

Modified:
  head/usr.bin/calendar/calendars/calendar.freebsd

Modified: head/usr.bin/calendar/calendars/calendar.freebsd
==
--- head/usr.bin/calendar/calendars/calendar.freebsdTue Jan 10 05:33:34 
2017(r311858)
+++ head/usr.bin/calendar/calendars/calendar.freebsdTue Jan 10 05:37:53 
2017(r311859)
@@ -310,6 +310,7 @@
 09/20  Kevin Lo <ke...@freebsd.org> born in Taipei, Taiwan, Republic of China, 
1972
 09/21  Gleb Kurtsou <g...@freebsd.org> born in Minsk, Belarus, 1984
 09/22  Bryan Drewery <bdrew...@freebsd.org> born in San Diego, California, 
United States, 1984
+09/24  Larry Rosenman <l...@freebsd.org> born in Queens, New York, United 
States, 1957
 09/27  Neil Blakey-Milner <n...@freebsd.org> born in Port Elizabeth, South 
Africa, 1978
 09/27  Renato Botelho <ga...@freebsd.org> born in Araras, Sao Paulo, Brazil, 
1979
 09/28  Greg Lehey <g...@freebsd.org> born in Melbourne, Victoria, Australia, 
1948
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r311852 - head/share/misc

[Larry Rosenman]

Author: ler (ports committer)
Date: Tue Jan 10 04:31:56 2017
New Revision: 311852
URL: https://svnweb.freebsd.org/changeset/base/311852

Log:
  Add myself to committers-ports.dot
  
  Approved by:  adamw (mentor)
  Differential Revision:https://reviews.freebsd.org/D9117

Modified:
  head/share/misc/committers-ports.dot

Modified: head/share/misc/committers-ports.dot
==
--- head/share/misc/committers-ports.dotTue Jan 10 04:17:53 2017
(r311851)
+++ head/share/misc/committers-ports.dotTue Jan 10 04:31:56 2017
(r311852)
@@ -144,6 +144,7 @@ laszlof [label="Frank Laszlo\nlaszlof@Fr
 lawrance [label="Sam Lawrance\nlawra...@freebsd.org\n2005/04/11\n2007/02/21"]
 lbr [label="Lars Balker Rasmussen\n...@freebsd.org\n2006/04/30"]
 leeym [label="Yen-Ming Lee\nle...@freebsd.org\n2002/08/14"]
+ler [label="Larry Rosenman\n...@freebsd.org\n2017/01/09"]
 lev [label="Lev Serebryakov\n...@freebsd.org\n2003/06/17"]
 lifanov [label="Nikolai Lifanov\nlifa...@freebsd.org\n2016/12/11"]
 linimon [label="Mark Linimon\nlini...@freebsd.org\n2003/10/23"]
@@ -252,6 +253,7 @@ znerd [label="Ernst de Haan\nznerd@FreeB
 
 adamw -> ahze
 adamw -> jylefort
+adamw -> ler
 adamw -> mezz
 adamw -> pav
 adamw -> woodsb02
@@ -554,6 +556,7 @@ rene -> bar
 rene -> cmt
 rene -> crees
 rene -> jgh
+rene -> ler
 rene -> olivierd
 
 rm -> koobs
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r306509 - in head/sys: fs/nandfs kern sys ufs/ffs

[Larry Rosenman]

On 2016-09-30 14:01, Mateusz Guzik wrote:

On Fri, Sep 30, 2016 at 01:58:16PM -0400, Larry Rosenman wrote:

On 2016-09-30 13:55, Mateusz Guzik wrote:
>On Fri, Sep 30, 2016 at 01:36:26PM -0400, Larry Rosenman wrote:
>>On 2016-09-30 13:28, Mateusz Guzik wrote:
>>>On Fri, Sep 30, 2016 at 01:18:45PM -0400, Shawn Webb wrote:
>>>>On Fri, Sep 30, 2016 at 05:11:03PM +, Mateusz Guzik wrote:
>>>>> Author: mjg
>>>>> Date: Fri Sep 30 17:11:03 2016
>>>>> New Revision: 306509
>>>>> URL: https://svnweb.freebsd.org/changeset/base/306509
>>>>>
>>>>> Log:
>>>>>   vfs: remove the __bo_vnode field from struct vnode
>>>>>
>>>>>   The pointer can be obtained using __containerof instead.
>>>>>
>>>>>   Reviewed by: kib
>>>>
>>>>Should __FreeBSD_Version be bumped?
>>>>
>>>
>>>Unlikely. It can be in an odd case it turns out there is a module which
>>>is using the field.
>>
>>Can someone do me a favor and make sure sysutils/lsof still
>>compiles/works?
>>
>>I'm OOT at the moment, and have a test IPv6 patch on my 12 system.
>
>I just ran lsof and it worked fine at least for the basic case.
>
>Apparently it indeed still goes through kernel memory. Did anyone ask
>the author what kind of interfaces would they want to NOT have to do
>this?
>
>Also, it looks like it constains some kind of a loop to imitate
>closefrom.
>
>On truss I see over 3.7 milion (yes, MILION) calls to close. Like this:
>close(3773297)   ERR#9 'Bad file
>descriptor'
>close(3773298)   ERR#9 'Bad file
>descriptor'
>close(3773299)   ERR#9 'Bad file
>descriptor'
>close(3773300)   ERR#9 'Bad file
>descriptor'
>close(3773301)   ERR#9 'Bad file
>descriptor'
>close(3773302)   ERR#9 'Bad file
>descriptor'
>close(3773303)   ERR#9 'Bad file
>descriptor'
>[snip]
>
>At least for freebsd this can be patched with the use of closefrom() on
>all supported releases.
>
>Arguably this may be a side effect of limits set too high, perhaps
>linux
>sets them sigifnicanly lower and the problem is not that terrible.

We've had this discussion before (re: interfaces). I thought the
current versions of lsof only close
the first 1k FD's.  (what version of lsof is this? on 12-CURRENT?)



This is 4.90.g,8 "formally" built for 11.0. The typical limit for fd is
1024 on linux, while it is higher on fbsd. I presume it goes up to the
limit. (as in, ulimit -n)

So what's up with the discussion on interfaces?

The current state seems detrimental to everyone.


Vic Abell (Author, Retired from Purdue, 70+ yrs old) has to maintain 
portability to

other OS's, and every time we go through this discussion it drops off.

You are welcome to try again, but I wouldn't bet on it.

Vic Abell <vab...@lsof.comcastbiz.net>


--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r306509 - in head/sys: fs/nandfs kern sys ufs/ffs

[Larry Rosenman]

On 2016-09-30 13:55, Mateusz Guzik wrote:

On Fri, Sep 30, 2016 at 01:36:26PM -0400, Larry Rosenman wrote:

On 2016-09-30 13:28, Mateusz Guzik wrote:
>On Fri, Sep 30, 2016 at 01:18:45PM -0400, Shawn Webb wrote:
>>On Fri, Sep 30, 2016 at 05:11:03PM +, Mateusz Guzik wrote:
>>> Author: mjg
>>> Date: Fri Sep 30 17:11:03 2016
>>> New Revision: 306509
>>> URL: https://svnweb.freebsd.org/changeset/base/306509
>>>
>>> Log:
>>>   vfs: remove the __bo_vnode field from struct vnode
>>>
>>>   The pointer can be obtained using __containerof instead.
>>>
>>>   Reviewed by: kib
>>
>>Should __FreeBSD_Version be bumped?
>>
>
>Unlikely. It can be in an odd case it turns out there is a module which
>is using the field.

Can someone do me a favor and make sure sysutils/lsof still
compiles/works?

I'm OOT at the moment, and have a test IPv6 patch on my 12 system.


I just ran lsof and it worked fine at least for the basic case.

Apparently it indeed still goes through kernel memory. Did anyone ask
the author what kind of interfaces would they want to NOT have to do
this?

Also, it looks like it constains some kind of a loop to imitate
closefrom.

On truss I see over 3.7 milion (yes, MILION) calls to close. Like this:
close(3773297)   ERR#9 'Bad file 
descriptor'
close(3773298)   ERR#9 'Bad file 
descriptor'
close(3773299)   ERR#9 'Bad file 
descriptor'
close(3773300)   ERR#9 'Bad file 
descriptor'
close(3773301)   ERR#9 'Bad file 
descriptor'
close(3773302)   ERR#9 'Bad file 
descriptor'
close(3773303)   ERR#9 'Bad file 
descriptor'

[snip]

At least for freebsd this can be patched with the use of closefrom() on
all supported releases.

Arguably this may be a side effect of limits set too high, perhaps 
linux

sets them sigifnicanly lower and the problem is not that terrible.


We've had this discussion before (re: interfaces). I thought the current 
versions of lsof only close

the first 1k FD's.  (what version of lsof is this? on 12-CURRENT?)


--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r306509 - in head/sys: fs/nandfs kern sys ufs/ffs

[Larry Rosenman]

On 2016-09-30 13:28, Mateusz Guzik wrote:

On Fri, Sep 30, 2016 at 01:18:45PM -0400, Shawn Webb wrote:

On Fri, Sep 30, 2016 at 05:11:03PM +, Mateusz Guzik wrote:
> Author: mjg
> Date: Fri Sep 30 17:11:03 2016
> New Revision: 306509
> URL: https://svnweb.freebsd.org/changeset/base/306509
>
> Log:
>   vfs: remove the __bo_vnode field from struct vnode
>
>   The pointer can be obtained using __containerof instead.
>
>   Reviewed by: kib

Should __FreeBSD_Version be bumped?



Unlikely. It can be in an odd case it turns out there is a module which
is using the field.


Can someone do me a favor and make sure sysutils/lsof still 
compiles/works?


I'm OOT at the moment, and have a test IPv6 patch on my 12 system.

--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r303099 - head/sys/kern

[Larry Rosenman]

This broke my build:
--- imgact_elf32.o ---
In file included from /usr/src/sys/kern/imgact_elf32.c:31:
/usr/src/sys/kern/imgact_elf.c:1663:8: error: format specifies type 
'size_t' (aka 'unsigned long') but the argument has type 'Elf32_Off' 
(aka 'unsigned int') [-Werror,-Wformat]

 ehdr->e_shoff, hdrsize - sizeof(Elf_Shdr)));
 ^
/usr/src/sys/sys/systm.h:86:17: note: expanded from macro 'KASSERT'
kassert_panic msg;  
\

  ^~~



On 2016-07-20 11:59, Conrad E. Meyer wrote:

Author: cem
Date: Wed Jul 20 16:59:36 2016
New Revision: 303099
URL: https://svnweb.freebsd.org/changeset/base/303099

Log:
  Extend ELF coredump to support more than 65535 segments

  The ELF e_phnum field is only 16 bits wide. To support more than
65535 segments
  (program headers), Sun's "Linker and Libraries Guide" table 7-7 (or 
12-7,
  depending on document version) prescribes a special first section 
header where

  sh_info represents the real number of program headers.

  Test code to follow, when it is ready.

  Reference:http://docs.oracle.com/cd/E18752_01/pdf/817-1984.pdf

  Reviewed by:  emaste, markj
  Sponsored by: EMC / Isilon Storage Division
  Differential Revision:https://reviews.freebsd.org/D7255

Modified:
  head/sys/kern/imgact_elf.c

Modified: head/sys/kern/imgact_elf.c
==
--- head/sys/kern/imgact_elf.c  Wed Jul 20 16:48:25 2016(r303098)
+++ head/sys/kern/imgact_elf.c  Wed Jul 20 16:59:36 2016(r303099)
@@ -1323,6 +1323,8 @@ __elfN(coredump)(struct thread *td, stru
 * Collect info about the core file header area.
 */
hdrsize = sizeof(Elf_Ehdr) + sizeof(Elf_Phdr) * (1 + seginfo.count);
+   if (seginfo.count + 1 >= PN_XNUM)
+   hdrsize += sizeof(Elf_Shdr);
__elfN(prepare_notes)(td, , );
coresize = round_page(hdrsize + notesz) + seginfo.size;

@@ -1618,10 +1620,10 @@ __elfN(puthdr)(struct thread *td, void *
 {
Elf_Ehdr *ehdr;
Elf_Phdr *phdr;
+   Elf_Shdr *shdr;
struct phdr_closure phc;

ehdr = (Elf_Ehdr *)hdr;
-   phdr = (Elf_Phdr *)((char *)hdr + sizeof(Elf_Ehdr));

ehdr->e_ident[EI_MAG0] = ELFMAG0;
ehdr->e_ident[EI_MAG1] = ELFMAG1;
@@ -1645,14 +1647,43 @@ __elfN(puthdr)(struct thread *td, void *
ehdr->e_flags = 0;
ehdr->e_ehsize = sizeof(Elf_Ehdr);
ehdr->e_phentsize = sizeof(Elf_Phdr);
-   ehdr->e_phnum = numsegs + 1;
ehdr->e_shentsize = sizeof(Elf_Shdr);
-   ehdr->e_shnum = 0;
ehdr->e_shstrndx = SHN_UNDEF;
+   if (numsegs + 1 < PN_XNUM) {
+   ehdr->e_phnum = numsegs + 1;
+   ehdr->e_shnum = 0;
+   } else {
+   ehdr->e_phnum = PN_XNUM;
+   ehdr->e_shnum = 1;
+
+   ehdr->e_shoff = ehdr->e_phoff +
+   (numsegs + 1) * ehdr->e_phentsize;
+   KASSERT(ehdr->e_shoff == hdrsize - sizeof(Elf_Shdr),
+   ("e_shoff: %zu, hdrsize - shdr: %zu",
+ehdr->e_shoff, hdrsize - sizeof(Elf_Shdr)));
+
+   shdr = (Elf_Shdr *)((char *)hdr + ehdr->e_shoff);
+   memset(shdr, 0, sizeof(*shdr));
+   /*
+* A special first section is used to hold large segment and
+* section counts.  This was proposed by Sun Microsystems in
+* Solaris and has been adopted by Linux; the standard ELF
+* tools are already familiar with the technique.
+*
+* See table 7-7 of the Solaris "Linker and Libraries Guide"
+* (or 12-7 depending on the version of the document) for more
+* details.
+*/
+   shdr->sh_type = SHT_NULL;
+   shdr->sh_size = ehdr->e_shnum;
+   shdr->sh_link = ehdr->e_shstrndx;
+   shdr->sh_info = numsegs + 1;
+   }

/*
 * Fill in the program header entries.
 */
+   phdr = (Elf_Phdr *)((char *)hdr + ehdr->e_phoff);

/* The note segement. */
phdr->p_type = PT_NOTE;
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"


--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r301226 - in head: etc etc/defaults etc/periodic/security etc/rc.d lib lib/libblacklist libexec libexec/blacklistd-helper share/mk tools/build/mk usr.sbin usr.sbin/blacklistctl usr.sbi

[Larry Rosenman]

On 2016-06-06 12:25, Ian Lepore wrote:

On Mon, 2016-06-06 at 13:24 -0400, Kurt Lidl wrote:

On 6/6/16 1:22 PM, Ian Lepore wrote:
> No, it should still not be enabled by default.  Maybe it should be
> enabled in response to some question in the installer, or maybe
> even
> better, enabled only if some firewall software that understands it
> is
> also enabled.  But afaik, all the available firewalls are disabled
> by
> default in defaults/rc.conf, and this should be too.

I have already committed a change to turn it off by default.

-Kurt



Yeah, I saw that, thanks.  I was just repsonding to the notion that it
should be re-enabled by default some day.

-- Ian

as an example adding to Ian, my Firewall is a pfSense box NOT on the 
same physical box.


I do NOT need nor want blacklistd running, as NOTHING local can be done.

--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r296428 - head/sys/boot/common

[Larry Rosenman]

On Sun, Mar 06, 2016 at 05:11:11PM -0800, Julian Elischer wrote:
> On 6/03/2016 7:57 AM, Dimitry Andric wrote:
> > Author: dim
> > Date: Sun Mar  6 15:57:43 2016
> > New Revision: 296428
> > URL: https://svnweb.freebsd.org/changeset/base/296428
> >
> > Log:
> >Since kernel modules can now contain sections of type SHT_AMD64_UNWIND,
> >the boot loader should not skip over these anymore while loading images.
> >Otherwise the kernel can still panic when it doesn't find the .eh_frame
> >section belonging to the .rela.eh_frame section.
> >
> >Unfortunately this will require installing boot loaders from sys/boot
> >before attempting to boot with a new kernel.
> 
> what happens to someone who doesn't replace their bootblocks?
> Or is this just the loader?
> 
> The general way we have handled this sort of thing in the past is that 
> we do something
> that produces a nagging message for a decent time before it becomes 
> mandatory.
> 
> I don't like the idea of people being caught unaware by this..
> 
> Can you please give a more detailed description of what happens?


In this case it's the loader.  I just upgraded a second laptop and did NOT 
replace
the boot block (boot1.efi), but DID populate /boot (and actually a full world), 
and 
it booted fine,


> 
> >
> >Reviewed by: kib
> >MFC after:   2 weeks
> >X-MFC-With:  r296419
> >
> > Modified:
> >head/sys/boot/common/load_elf_obj.c
> >
> > Modified: head/sys/boot/common/load_elf_obj.c
> > ==
> > --- head/sys/boot/common/load_elf_obj.c Sun Mar  6 14:37:49 2016
> > (r296427)
> > +++ head/sys/boot/common/load_elf_obj.c Sun Mar  6 15:57:43 2016
> > (r296428)
> > @@ -221,6 +221,9 @@ __elfN(obj_loadimage)(struct preloaded_f
> > switch (shdr[i].sh_type) {
> > case SHT_PROGBITS:
> > case SHT_NOBITS:
> > +#if defined(__i386__) || defined(__amd64__)
> > +   case SHT_AMD64_UNWIND:
> > +#endif
> > lastaddr = roundup(lastaddr, shdr[i].sh_addralign);
> > shdr[i].sh_addr = (Elf_Addr)lastaddr;
> > lastaddr += shdr[i].sh_size;
> >
> >
> 
> ___
> svn-src-all@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/svn-src-all
> To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

-- 
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 7011 W Parmer Ln, Apt 1115, Austin, TX 78729-6961
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r285139 - in head: lib/libnv sys/conf sys/contrib/libnv sys/kern sys/sys

[Larry Rosenman]

On 2015-07-09 15:31, Baptiste Daroussin wrote:

On Thu, Jul 09, 2015 at 01:29:54PM -0700, Peter Wemm wrote:

On Saturday, July 04, 2015 04:33:38 PM Mariusz Zaborski wrote:
 Author: oshogbo
 Date: Sat Jul  4 16:33:37 2015
 New Revision: 285139
 URL: https://svnweb.freebsd.org/changeset/base/285139

 Log:
   Move the nvlist source and private includes from sys/kern to seperate
   directory sys/contrib/libnv.

   The goal of this operation is to NOT install header files which shouldn't
   be used outside the nvlist library.

   head/sys/contrib/libnv/nvlist.c
  - copied, changed from r285128, head/sys/kern/subr_nvlist.c

You have broken kernel builds for the freebsd.org cluster.  By 
renaming

subr_nvlist.o to nvlist.o you now cause:

make[2]: .../Makefile line 3143: warning: duplicate script for 
target

nvpair.o ignored
make[2]: .../Makefile line 1260: warning: using previous script for
nvpair.o defined here



linking kernel.debug
nvpair.o: In function `illumos_nvlist_add_nvlist':
/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1136: 
multiple

definition of `illumos_nvlist_add_nvlist'
nvpair.o:/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1136:
first defined here
nvpair.o: In function `illumos_nvlist_add_nvpair':
/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1971: 
multiple

definition of `illumos_nvlist_add_nvpair'
nvpair.o:/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1971:
first defined here


I'm going to attempt to revert this for the freebsd.org cluster 
because I need

it to compile for openssl.

You probably want to specify that this happens when zfs is built in the 
kernel

not as a module.

Best regards,
Bapt

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=201356

has a patch

--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 108 Turvey Cove, Hutto, TX 78634-5688
___
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: r284417 - in head: cddl/lib gnu/lib/libgcc gnu/lib/libssp lib/libalias/libalias lib/libalias/modules lib/libbegemot lib/libc lib/libcam lib/libcapsicum lib/libcasper lib/libcrypt lib/l

[Larry Rosenman]

On 2015-06-15 11:10, Baptiste Daroussin wrote:

On Mon, Jun 15, 2015 at 08:54:25AM -0700, Peter Wemm wrote:

On Monday, June 15, 2015 03:34:21 PM Baptiste Daroussin wrote:
 Author: bapt
 Date: Mon Jun 15 15:34:20 2015
 New Revision: 284417
 URL: https://svnweb.freebsd.org/changeset/base/284417

 Log:
   Enforce overwritting SHLIBDIR

   Since METAMODE has been added, sys.mk loads bsd.mkopt.mk which ends load
 loading bsd.own.mk which then defines SHLIBDIR before all the Makefile.inc
 everywhere.

   This makes /lib being populated again.

   Reported by: many

I don't understand how this metamode crap could possibly have been 
tested with

things of this magnitude turning up.


You may also notice that my fix does not work for lib32 and I don't 
know how

to fix lib32 at this point

Bapt
I'm STILL getting weird failures at 284417 -- trying a clean build (not 
-DNO_CLEAN).



--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 108 Turvey Cove, Hutto, TX 78634-5688

___
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: r270745 - in head: bin/ps sys/compat/freebsd32 sys/kern sys/sys

[Larry Rosenman]

...done.
Loaded symbols for /boot/kernel/ipmi.ko.symbols
Reading symbols from /boot/kernel/ipmi_linux.ko.symbols...done.
Loaded symbols for /boot/kernel/ipmi_linux.ko.symbols
Reading symbols from /boot/kernel/radeonkms.ko.symbols...done.
Loaded symbols for /boot/kernel/radeonkms.ko.symbols
Reading symbols from /boot/kernel/iicbb.ko.symbols...done.
Loaded symbols for /boot/kernel/iicbb.ko.symbols
Reading symbols from /boot/kernel/iicbus.ko.symbols...done.
Loaded symbols for /boot/kernel/iicbus.ko.symbols
Reading symbols from /boot/kernel/iic.ko.symbols...done.
Loaded symbols for /boot/kernel/iic.ko.symbols
Reading symbols from /boot/kernel/drm2.ko.symbols...done.
Loaded symbols for /boot/kernel/drm2.ko.symbols
Reading symbols from /boot/kernel/radeonkmsfw_R100_cp.ko.symbols...done.
Loaded symbols for /boot/kernel/radeonkmsfw_R100_cp.ko.symbols
Reading symbols from /boot/kernel/fdescfs.ko.symbols...done.
Loaded symbols for /boot/kernel/fdescfs.ko.symbols
Reading symbols from /boot/kernel/uhid.ko.symbols...done.
Loaded symbols for /boot/kernel/uhid.ko.symbols
Reading symbols from /boot/modules/vboxnetflt.ko...done.
Loaded symbols for /boot/modules/vboxnetflt.ko
Reading symbols from /boot/kernel/netgraph.ko.symbols...done.
Loaded symbols for /boot/kernel/netgraph.ko.symbols
Reading symbols from /boot/kernel/ng_ether.ko.symbols...done.
Loaded symbols for /boot/kernel/ng_ether.ko.symbols
Reading symbols from /boot/modules/vboxnetadp.ko...done.
Loaded symbols for /boot/modules/vboxnetadp.ko
#0  doadump (textdump=1) at pcpu.h:219
219 pcpu.h: No such file or directory.
in pcpu.h
(kgdb) #0  doadump (textdump=1) at pcpu.h:219
#1  0x80a15227 in kern_reboot (howto=260)
at /usr/src/sys/kern/kern_shutdown.c:447
#2  0x80a157c8 in vpanic (fmt=value optimized out, 
ap=value optimized out) at /usr/src/sys/kern/kern_shutdown.c:746
#3  0x80a15813 in panic (fmt=0x0)
at /usr/src/sys/kern/kern_shutdown.c:675
#4  0x80a1ce47 in _sx_assert (sx=0x0, what=value optimized out, 
file=0x0, line=0) at /usr/src/sys/kern/kern_sx.c:1086
#5  0x80a0611c in fill_kinfo_proc (p=0xf80257916000, 
kp=0xfe100c640250) at /usr/src/sys/kern/kern_proc.c:795
#6  0x80a06cc7 in kern_proc_out (p=0xf80257916000, 
sb=0xf800241c8400, flags=2) at /usr/src/sys/kern/kern_proc.c:1205
#7  0x809c0709 in elf32_note_procstat_proc (
arg=value optimized out, sb=value optimized out, 
sizep=0xf80024267dd8) at imgact_elf.c:1787
#8  0x809bea02 in elf32_coredump (td=value optimized out, 
vp=0xf802708f9000, limit=value optimized out, flags=0)
at imgact_elf.c:1618
#9  0x80a18c4b in sigexit (td=0xf80270e5d000, sig=11)
at /usr/src/sys/kern/kern_sig.c:3297
#10 0x80a19318 in postsig (sig=value optimized out)
at /usr/src/sys/kern/kern_sig.c:2837
#11 0x80a60727 in ast (framep=value optimized out)
at /usr/src/sys/kern/subr_trap.c:275
#12 0x80e08e09 in doreti_ast ()
at /usr/src/sys/amd64/amd64/exception.S:676
#13 0x0814f470 in ?? ()
#14 0x0814f430 in ?? ()
#15 0x in ?? ()
Current language:  auto; currently minimal
(kgdb) 


-- 
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 108 Turvey Cove, Hutto, TX 78634-5688
___
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: r268840 - head/usr.sbin/unbound/local-setup

[Larry Rosenman]

should this be noted in UPDATING to re-gen the files locally or 
something?




On 2014-07-18 07:33, Dag-Erling Smørgrav wrote:

Author: des
Date: Fri Jul 18 12:33:22 2014
New Revision: 268840
URL: http://svnweb.freebsd.org/changeset/base/268840

Log:
  Use a combination of unblock-lan-zones (r268839) and domain-insecure
  to fix reverse lookups on networks using private addresses.

Modified:
  head/usr.sbin/unbound/local-setup/local-unbound-setup.sh

Modified: head/usr.sbin/unbound/local-setup/local-unbound-setup.sh
==
--- head/usr.sbin/unbound/local-setup/local-unbound-setup.shFri Jul
18 11:32:44 2014(r268839)
+++ head/usr.sbin/unbound/local-setup/local-unbound-setup.shFri Jul
18 12:33:22 2014(r268840)
@@ -33,6 +33,7 @@
 user=
 unbound_conf=
 forward_conf=
+lanzones_conf=
 workdir=
 confdir=
 chrootdir=
@@ -59,6 +60,7 @@ set_defaults() {
: ${confdir:=${workdir}/conf.d}
: ${unbound_conf:=${workdir}/unbound.conf}
: ${forward_conf:=${workdir}/forward.conf}
+   : ${lanzones_conf:=${workdir}/lan-zones.conf}
: ${anchor:=${workdir}/root.key}
: ${pidfile:=/var/run/local_unbound.pid}
: ${resolv_conf:=/etc/resolv.conf}
@@ -73,7 +75,8 @@ set_defaults() {
 #
 set_chrootdir() {
chrootdir=${workdir}
-   for file in ${unbound_conf} ${forward_conf} ${anchor} ; do
+   for file in ${unbound_conf} ${forward_conf} \
+   ${lanzones_conf} ${anchor} ; do
if [ ${file#${workdir%/}/} = ${file} ] ; then
echo warning: ${file} is outside ${workdir} 2
chrootdir=
@@ -171,6 +174,7 @@ gen_resolvconf_conf() {
 #
 gen_forward_conf() {
echo # Generated by $self
+   echo # Do not edit this file.
echo forward-zone:
echo name: .
for forwarder ; do
@@ -183,6 +187,42 @@ gen_forward_conf() {
 }

 #
+# Generate lan-zones.conf
+#
+gen_lanzones_conf() {
+   echo # Generated by $self
+   echo # Do not edit this file.
+   echo server:
+   echo # Unblock reverse lookups for LAN addresses
+   echo unblock-lan-zones: yes
+   echo domain-insecure: 10.in-addr.arpa.
+   echo domain-insecure: 127.in-addr.arpa.
+   echo domain-insecure: 16.172.in-addr.arpa.
+   echo domain-insecure: 17.172.in-addr.arpa.
+   echo domain-insecure: 18.172.in-addr.arpa.
+   echo domain-insecure: 19.172.in-addr.arpa.
+   echo domain-insecure: 20.172.in-addr.arpa.
+   echo domain-insecure: 21.172.in-addr.arpa.
+   echo domain-insecure: 22.172.in-addr.arpa.
+   echo domain-insecure: 23.172.in-addr.arpa.
+   echo domain-insecure: 24.172.in-addr.arpa.
+   echo domain-insecure: 25.172.in-addr.arpa.
+   echo domain-insecure: 26.172.in-addr.arpa.
+   echo domain-insecure: 27.172.in-addr.arpa.
+   echo domain-insecure: 28.172.in-addr.arpa.
+   echo domain-insecure: 29.172.in-addr.arpa.
+   echo domain-insecure: 30.172.in-addr.arpa.
+   echo domain-insecure: 31.172.in-addr.arpa.
+   echo domain-insecure: 168.192.in-addr.arpa.
+   echo domain-insecure: 254.169.in-addr.arpa.
+   echo domain-insecure: d.f.ip6.arpa.
+   echo domain-insecure: 8.e.ip6.arpa.
+   echo domain-insecure: 9.e.ip6.arpa.
+   echo domain-insecure: a.e.ip6.arpa.
+   echo domain-insecure: b.e.ip6.arpa.
+}
+
+#
 # Generate unbound.conf
 #
 gen_unbound_conf() {
@@ -197,6 +237,9 @@ gen_unbound_conf() {
if [ -f ${forward_conf} ] ; then
echo include: ${forward_conf}
fi
+   if [ -f ${lanzones_conf} ] ; then
+   echo include: ${lanzones_conf}
+   fi
if [ -d ${confdir} ] ; then
echo include: ${confdir}/*.conf
fi
@@ -323,6 +366,13 @@ main() {
fi

#
+   # Generate lan-zones.conf.
+   #
+   local tmp_lanzones_conf=$(mktemp -u ${lanzones_conf}.X)
+   gen_lanzones_conf ${tmp_lanzones_conf}
+   replace ${lanzones_conf} ${tmp_lanzones_conf}
+
+   #
# Generate unbound.conf.
#
local tmp_unbound_conf=$(mktemp -u ${unbound_conf}.X)
___
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


--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 (c) E-Mail: l...@lerctr.org
US Mail: 108 Turvey Cove, Hutto, TX 78634-5688
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src

Re: svn commit: r192625 - in head: . lib/libc/stdtime usr.sbin/zic

[Larry Rosenman]

On Sat, May 23, 2009 12:53 pm, M. Warner Losh wrote:
 In message: 200905230631.n4n6vosa046...@svn.freebsd.org
 Edwin Groothuis ed...@freebsd.org writes:
 :   After the installation of this code and the running of zic(8), you
 :   need to run tzsetup(8) again to install the new datafile.

 Please add an UPDATING entry for this, since we are going to get
 complaints about it...

 Warner
There is one:
20090523:
The newly imported zic(8) produces a new format in the
output. Please run tzsetup(8) to install the newly created
data to /etc/localtime.


-- 
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 512-248-2683 E-Mail: l...@lerctr.org
US Mail: 430 Valona Loop, Round Rock, TX 78681-3893


___
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