Re: new "compat" sets have really made sets harder to manage.
> On Apr 26, 2024, at 12:37 AM, Martin Husemann wrote: > > On Thu, Apr 25, 2024 at 10:43:43PM -, Christos Zoulas wrote: >> Thank you. I think there should be one compat set list, not one >> for each machine_arch, and only have a ad or md machine specific >> file for the parts that are different. I.e. there should be a >> base32/mi and a base32/shl.mi containing most of the data. > > I'd say even those should not exist, as the files in base/* already have > all the information we need, and it is important to keep tags like > compatfile and compatdebug working like they used to before the set list > changes. > Martin Good point! So it could all be done with some MKCOMPATSETS=yes option christos
Re: new "compat" sets have really made sets harder to manage.
In article , nia wrote: >I've thought about this a bit more and I want to write a separate >script for generating the compat set lists, the current one is a >little confusing (it tries to do a lot of things) and isn't really >suited to generating a list based on another list. > >I'll work on this when I have time. Thank you. I think there should be one compat set list, not one for each machine_arch, and only have a ad or md machine specific file for the parts that are different. I.e. there should be a base32/mi and a base32/shl.mi containing most of the data. christos
Re: build.sh kernel does not finish with endless nbctfmerge run
In article <4b5a66e1-7a3e-48ce-9ace-f9249e75f...@mailbox.org>, J. Hannken-Illjes wrote: >I also added an abort() when _dwarf_get_reloc_size() returns on >"/* unknown relocation. */" and this killed nbctfconvert() as > >_dwarf_get_reloc_size () >_dwarf_elf_init () >dwarf_elf_init () >dw_read () >main () > >For me nbctfmerge on kernels succeeds after up to 30 minutes, but the >resulting CTF sections are long too big and look very strange: Yes, I also reproduced it. Back to the drawing board... christos
Re: build.sh kernel does not finish with endless nbctfmerge run
I don't think that's the problem. I added abort() calls just before the return
0 and
they never fire for me (and the kernel built has the right CTF information).
Nevertheless
I think that the relocation code is not used in the CTF code; it just parsers
the debug
dwarf into and builds CTF stabs from them. I think that the threading code in
ctf is
problematic because we had this problem in the past.
christos
> On Mar 29, 2024, at 9:43 PM, Ryo ONODERA wrote:
>
> Hi,
>
> The following two commits cause endless nbctfmerge run
> at end of build.sh kernel=GENERIC for me.
> My environment is NetBSD/amd64 10.99.10 of yesterday.
>
> Could you investigate my problem?
>
> Module Name: src
> Committed By: christos
> Date: Wed Mar 27 21:53:06 UTC 2024
>
> Modified Files:
> src/external/bsd/elftoolchain/dist/libdwarf: libdwarf_reloc.c
>
> Log Message:
> Don't try to compile the arch-specific relocation code if we don't have the
> built-in headers (for tools)
>
> To generate a diff of this commit:
> cvs rdiff -u -r1.5 -r1.6 \
>src/external/bsd/elftoolchain/dist/libdwarf/libdwarf_reloc.c
>
> Module Name: src
> Committed By: christos
> Date: Wed Mar 27 21:54:43 UTC 2024
>
> Modified Files:
> src/tools: Makefile.nbincludes
> src/tools/elftoolchain/libdwarf: Makefile
>
> Log Message:
> Remove dependency to elfdefinitions.h, this is a mess, since it needs
> ${TOOL_M4} which might not be available yet.
>
> To generate a diff of this commit:
> cvs rdiff -u -r1.7 -r1.8 src/tools/Makefile.nbincludes
> cvs rdiff -u -r1.4 -r1.5 src/tools/elftoolchain/libdwarf/Makefile
>
>
> Thank you.
>
> --
> Ryo ONODERA // r...@tetera.org
> PGP fingerprint = 82A2 DC91 76E0 A10A 8ABB FD1B F404 27FA C7D1 15F3
Re: new BIND in 10.0_RC5/sparc dies w/Bus error
On 2024-03-05 1:13 am, matthew green wrote:
ah. the problem is that struct isc_nmhandle grew a pointer member,
adding 4 bytes to the struct size, and it uses C99 [] variable array
for the final member, which is later assigned to other pointers, and
this memory was now only 4-byte aligned. this hack patch works to
stop named crashing for me, but i'll let christos figure out what the
right general solution here is.
.mrg.
Index: lib/isc/netmgr/netmgr-int.h
===
RCS file:
/cvsroot/src/external/mpl/bind/dist/lib/isc/netmgr/netmgr-int.h,v
retrieving revision 1.8.2.1
diff -p -u -r1.8.2.1 netmgr-int.h
--- lib/isc/netmgr/netmgr-int.h 25 Feb 2024 15:47:24 - 1.8.2.1
+++ lib/isc/netmgr/netmgr-int.h 5 Mar 2024 06:12:50 -
@@ -276,7 +276,7 @@ struct isc_nmhandle {
LINK(isc_nmhandle_t) active_link;
#endif
void *opaque;
- char extra[];
+ char extra[] __attribute__((__aligned__(8)));
};
typedef enum isc__netievent_type {
Perhaps:
union {
void *p;
long double d;
long long lld;
intmax_t im;
} extra[];
Or simpler:
struct {
void *p;
} extra[];
Does the second form work?
christos
Re: new BIND in 10.0_RC5/sparc dies w/Bus error
On 2024-03-05 1:13 am, matthew green wrote:
ah. the problem is that struct isc_nmhandle grew a pointer member,
adding 4 bytes to the struct size, and it uses C99 [] variable array
for the final member, which is later assigned to other pointers, and
this memory was now only 4-byte aligned. this hack patch works to
stop named crashing for me, but i'll let christos figure out what the
right general solution here is.
.mrg.
Index: lib/isc/netmgr/netmgr-int.h
===
RCS file:
/cvsroot/src/external/mpl/bind/dist/lib/isc/netmgr/netmgr-int.h,v
retrieving revision 1.8.2.1
diff -p -u -r1.8.2.1 netmgr-int.h
--- lib/isc/netmgr/netmgr-int.h 25 Feb 2024 15:47:24 - 1.8.2.1
+++ lib/isc/netmgr/netmgr-int.h 5 Mar 2024 06:12:50 -
@@ -276,7 +276,7 @@ struct isc_nmhandle {
LINK(isc_nmhandle_t) active_link;
#endif
void *opaque;
- char extra[];
+ char extra[] __attribute__((__aligned__(8)));
};
typedef enum isc__netievent_type {
Does the following work, and is it more palatable?
union {
void *p;
long double d;
long long lld;
intmax_t im;
} extra[];
or just:
--
christos
Re: bug in ftp(1)?
In article , Thomas Klausner wrote: >Hi! > >When fetching the distfile for mail/courier-unicode, I see: > >=> Bootstrap dependency digest>=20211023: found digest-20220214 >=> Fetching courier-unicode-2.3.0.tar.bz2 >=> Total size: 657354 bytes >Trying [2606:4700:4400::ac40:9691]:443 ... >Requesting >https://sourceforge.net/projects/courier/files/courier-unicode/2.3.0/courier-unicode-2.3.0.tar.bz2 >ftp: Receiving HTTP reply: Input line is too long >fetch: Unable to fetch expected file courier-unicode-2.3.0.tar.bz2 >... > >wget fetches the file fine. On HEAD you can use -b now. christos
Re: Can't build evbarm
I don't know what's different in your build, but reeling.netbsd.org shows all
the builds are working. Are you cross building?
christos
> On Jan 25, 2024, at 3:20 AM, Adam wrote:
>
>> Today, the build fails while making tools:
>>
>>
>> --- md2.lo ---
>> /dist/src/tools/compat/../../lib/libc/hash/md2/md2.c:130:4: error: call to
>> undeclared function 'MD2Transform'; ISO C99 and later do not support
>> implicit function declarations [-Wimplicit-function-declaration]
>> MD2Transform(context); /* resets i */
>> ^
>> /dist/src/tools/compat/../../lib/libc/hash/md2/md2.c:163:1: error:
>> conflicting types for 'MD2Transform'
>> MD2Transform(MD2_CTX *context)
>> ^
>> /dist/src/tools/compat/../../lib/libc/hash/md2/md2.c:130:4: note: previous
>> implicit declaration is here
>> MD2Transform(context); /* resets i */
>> ^
>> 2 errors generated.
>
> Reverting lib/libc/hash/md2/md2.c to v1.7 fixes the build.
>
> As I understand, MD2Transform() is used (in MD2Update()) before it is
> defined, so to fix it properly I suggest the following patch.
>
> Commit?
>
> Kind regards,
> Adam
>
>
>
> diff -u -r1.8 md2.c
> --- md2.c 20 Jan 2024 14:52:47 - 1.8
> +++ md2.c 25 Jan 2024 08:17:43 -
> @@ -113,6 +113,30 @@
> memset(>X[0], 0, sizeof(context->X));
> }
> +/*
> + * XXX This should not be visible, but due to an accident, it is
> + * XXX so it must remain so.
> + */
> +/*static*/ void
> +MD2Transform(MD2_CTX *context)
> +{
> + uint32_t l, j, k, t;
> +
> + /* set block "3" and update "checksum" */
> + for (l = context->C[15], j = 0; j < 16; j++) {
> + context->X[32 + j] = context->X[j] ^ context->X[16 + j];
> + l = context->C[j] ^= S[context->X[16 + j] ^ l];
> + }
> +
> + /* mangle input block */
> + for (t = j = 0; j < 18; t = (t + j) % 256, j++)
> + for (k = 0; k < 48; k++)
> + t = context->X[k] = (context->X[k] ^ S[t]);
> +
> + /* reset input pointer */
> + context->i = 16;
> +}
> +
> void
> MD2Update(MD2_CTX *context, const unsigned char *input, unsigned int inputLen)
> {
> @@ -155,28 +179,4 @@
> MD2Init(context);
> }
> -/*
> - * XXX This should not be visible, but due to an accident, it is
> - * XXX so it must remain so.
> - */
> -/*static*/ void
> -MD2Transform(MD2_CTX *context)
> -{
> - uint32_t l, j, k, t;
> -
> - /* set block "3" and update "checksum" */
> - for (l = context->C[15], j = 0; j < 16; j++) {
> - context->X[32 + j] = context->X[j] ^ context->X[16 + j];
> - l = context->C[j] ^= S[context->X[16 + j] ^ l];
> - }
> -
> - /* mangle input block */
> - for (t = j = 0; j < 18; t = (t + j) % 256, j++)
> - for (k = 0; k < 48; k++)
> - t = context->X[k] = (context->X[k] ^ S[t]);
> -
> - /* reset input pointer */
> - context->i = 16;
> -}
> -
> #endif /* !HAVE_MD2_H */
Re: kerberos issues with 10.0_BETA post openssl update
In article <20230904103054.553e160...@jupiter.mumble.net>, Taylor R Campbell wrote: >> Date: Mon, 4 Sep 2023 16:46:35 +1200 >> From: Mark Davies >> >> Having updated from a 10.0_BETA built in march to one built couple >> of weeks ago (post the openssl3 merge) I'm now seeing various >> kerberos issues that I wasn't seeing before. > >Can you share `ldd /usr/libexec/kadmind' on the machine where it's >crashing? Wondering whether it's mixing shlib versions in one address >space, like https://gnats.netbsd.org/57603 (though that's not the same >issue because you're only using things in base). > >Can you install the debug set on one of the affected systems where you >can reproduce a problem to get more information out of the stack >traces? You must be mixing the old and new versions of the OpenSSL libraries. Kerberos works fine for me in HEAD. christos
Re: MKCROSSGDB=yes broken in new gdb?
Ah, I took care of gmp in the mknative case only. Let me fix it.
christos
> On Aug 13, 2023, at 10:09 PM, matthew green wrote:
>
>> I pass it in LDFLAGS=-L${GMPOBJ}
>
> ? this doesn't help gmp.h being missing... i don't know what is up
> and for me, it works because pkgsrc gmp is installed.
>
>
> .mrg.
>
>> christos
>>
>>> On Aug 13, 2023, at 2:41 PM, matthew green wrote:
>>>
>>> FWIW, when i was looking at why my build worked it seems that
>>> the build is thinking it's building against the tools gmp but
>>> the -I path to find it is missing, but -I/usr/pkg/include is
>>> so that for me i'm getting the host gmp.h, but it's linking
>>> the tools libgmp.a.
signature.asc
Description: Message signed with OpenPGP
Re: MKCROSSGDB=yes broken in new gdb?
I pass it in LDFLAGS=-L${GMPOBJ}
christos
> On Aug 13, 2023, at 2:41 PM, matthew green wrote:
>
> FWIW, when i was looking at why my build worked it seems that
> the build is thinking it's building against the tools gmp but
> the -I path to find it is missing, but -I/usr/pkg/include is
> so that for me i'm getting the host gmp.h, but it's linking
> the tools libgmp.a.
signature.asc
Description: Message signed with OpenPGP
Re: Build error
In article ,
Paul Goyette wrote:
>On Tue, 20 Jun 2023, Paul Goyette wrote:
>
>> On Tue, 20 Jun 2023, Paul Goyette wrote:
>>
>>> With sources updated on 2023-06-20 at 17:26:58 UTC and building into
>>> a completely empty $DESTDIR I am getting
>>>
>>>
>>> == 2 missing files in DESTDIR
>>> Files in flist but missing from DESTDIR.
>>> File wasn't installed ?
>>> --
>>> ./usr/lib/i386/libvers_g.a
>>> ./usr/lib/libvers_g.a
>>> end of 2 missing files ==
>>>
>>> Any clues?
>>
>> FWIW, this build was with all 3 of DEBUG{,LIB,KERNEL} set.
>
>Looks like this debug library goes away with the new heimdal.
>
>I'll commit the changes as soon as I get a clean build.
It was a bug to install it before because LIBISPRIVATE was missing
christos
Re: Automated report: NetBSD-current/i386 test failure
In article <1617.1685135...@jacaranda.noi.kre.to>, Robert Elz wrote: > >I'll keep looking, and see if there is a reasonable path forward, which >allows rump's bizarre etfs to function as needed, without completely >breaking normal unix pathname resolution semantics. Perhaps add a flag to the mount command to not do the realpath check? christos
Re: Build fails with MKCOMPAT=no
I think that the mistake is that we have the openssl/i386 directories in
NetBSD.dist.x86_64 where they should only be NetBSD.dist.xcompat.in.
christos
> On May 16, 2023, at 3:28 AM, Adam wrote:
>
> I still require the second patch, or the build fails with
>
> checkflist ===> distrib/sets
>
> === 1 extra files in DESTDIR =
> Files in DESTDIR but missing from flist.
> File is obsolete or flist is out of date ?
> --
> ./usr/lib/i386
> = end of 1 extra files ===
>
> --- checkflist ---
>
> *** Failed target: checkflist
> *** Failed commands:
> ${SETSCMD} ${.CURDIR}/checkflist ${MAKEFLIST_FLAGS} ${CHECKFLIST_FLAGS}
> ${METALOG.unpriv}
> => cd /dist/src/distrib/sets && DESTDIR=/tmp/pkgsrc/destdir.amd64
> MACHINE=amd64 MACHINE_ARCH=x86_64 AWK=/dist/tools.amd64/bin/nbawk
> CKSUM=/dist/tools.amd64/bin/nbcksum DB=/dist/tools.amd64/bin/nbdb
> EGREP=/dist/tools.amd64/bin/nbgrep\ -E HOST_SH=/bin/sh
> MAKE=/dist/tools.amd64/bin/nbmake MKTEMP=/dist/tools.amd64/bin/nbmktemp
> MTREE=/dist/tools.amd64/bin/nbmtree PAX=/dist/tools.amd64/bin/nbpax
> COMPRESS_PROGRAM=/dist/tools.amd64/bin/nbxz GZIP=-n XZ_OPT=-9
> TAR_SUFF=tar.xz PKG_CREATE=/dist/tools.amd64/bin/nbpkg_create
> SED=/dist/tools.amd64/bin/nbsed TSORT=/dist/tools.amd64/bin/nbtsort\ -q
> /bin/sh /dist/src/distrib/sets/checkflist -L base -M
> /tmp/pkgsrc/destdir.amd64/METALOG.sanitised
> *** [checkflist] Error code 1
>
>
>
>> Only the first one should be needed, since the second one already has other
>> ./usr/lib/i386/... I'll commit it, thanks!
>>
>> christos
>>
>>> On May 11, 2023, at 5:28 AM, Adam wrote:
>>>
>>> Currently, building -current/amd64 fails with MKCOMPAT=no, as etc/mtree and
>>> sets expect /usr/lib/i386 to exist. I have a fix, but I'm not sure it won't
>>> break for MKCOMPAT=yes, or maybe the usr/lib/i386 is not a proper directory
>>> for these files?
>>>
>>> --- etc/mtree/NetBSD.dist.x86_64 10 May 2023 15:52:50 - 1.17
>>> +++ etc/mtree/NetBSD.dist.x86_64 11 May 2023 09:27:59 -
>>> @@ -5,6 +5,7 @@
>>> ./usr/include/i386
>>> ./usr/include/x86
>>> ./usr/include/xen
>>> +./usr/lib/i386
>>> ./usr/lib/i386/openssl
>>> ./usr/lib/i386/openssl/modules
>>> ./usr/lib/i386/openssl/engines
>>> --- distrib/sets/lists/base/md.amd64 10 May 2023 15:52:07 - 1.288
>>> +++ distrib/sets/lists/base/md.amd64 11 May 2023 09:27:59 -
>>> @@ -11,6 +11,7 @@
>>> ./usr/lib/i386/libproc.so.1.0 base-compat-shlib compat,pic,dtrace
>>> ./usr/lib/i386/librtld_db.so.0 base-compat-shlib compat,pic,dtrace
>>> ./usr/lib/i386/librtld_db.so.0.0 base-compat-shlib compat,pic,dtrace
>>> +./usr/lib/i386 base-crypto-usr
>>> ./usr/lib/i386/openssl base-crypto-usr
>>> ./usr/lib/i386/openssl/engines base-crypto-usr
>>> ./usr/lib/i386/openssl/modules base-crypto-usr
>>>
>>> Kind regards,
>>> Adam
>>
signature.asc
Description: Message signed with OpenPGP
Re: Build fails with MKCOMPAT=no
Only the first one should be needed, since the second one already has other ./usr/lib/i386/... I'll commit it, thanks! christos > On May 11, 2023, at 5:28 AM, Adam wrote: > > Currently, building -current/amd64 fails with MKCOMPAT=no, as etc/mtree and > sets expect /usr/lib/i386 to exist. I have a fix, but I'm not sure it won't > break for MKCOMPAT=yes, or maybe the usr/lib/i386 is not a proper directory > for these files? > > --- etc/mtree/NetBSD.dist.x86_64 10 May 2023 15:52:50 - 1.17 > +++ etc/mtree/NetBSD.dist.x86_64 11 May 2023 09:27:59 - > @@ -5,6 +5,7 @@ > ./usr/include/i386 > ./usr/include/x86 > ./usr/include/xen > +./usr/lib/i386 > ./usr/lib/i386/openssl > ./usr/lib/i386/openssl/modules > ./usr/lib/i386/openssl/engines > --- distrib/sets/lists/base/md.amd64 10 May 2023 15:52:07 - 1.288 > +++ distrib/sets/lists/base/md.amd64 11 May 2023 09:27:59 - > @@ -11,6 +11,7 @@ > ./usr/lib/i386/libproc.so.1.0 base-compat-shlib > compat,pic,dtrace > ./usr/lib/i386/librtld_db.so.0base-compat-shlib > compat,pic,dtrace > ./usr/lib/i386/librtld_db.so.0.0 base-compat-shlib > compat,pic,dtrace > +./usr/lib/i386 base-crypto-usr > ./usr/lib/i386/opensslbase-crypto-usr > ./usr/lib/i386/openssl/enginesbase-crypto-usr > ./usr/lib/i386/openssl/modulesbase-crypto-usr > > Kind regards, > Adam signature.asc Description: Message signed with OpenPGP
Re: Total sysupgrade failure - 10.99.3 -> 10.99.3, 4 days difference
In article , Chavdar Ivanov wrote: >On Tue, 18 Apr 2023 at 22:16, Chavdar Ivanov wrote: >> >> Hi, >> >> I do my builds with sysbuild and my upgrades with sysupgrade, many >> years now, basically since these two tools were made available. I >> haven't had much problems with them so far. >> >> My previous build was from 14th of April and worked just fine. Today I >> did another one, after completing a two day pkg-rolling-replace, and >> got: >> >> 100% >|*| >> 43015 KiB8.57 MiB/s00:00 ETA >> sysupgrade: I: Extracting comp into / >> /usr/lib/libc.so.12: Undefined symbol "_libc_init" (symnum = 3700) >> sysupgrade: I: Extracting games into / >> ... >> /usr/lib/libc.so.12: Undefined symbol "_libc_init" (symnum = 3700) >> sysupgrade: I: Extracting xserver into / >> /usr/lib/libc.so.12: Undefined symbol "_libc_init" (symnum = 3700) >> sysupgrade: I: Upgrading /etc interactively >> /bin/sh: Undefined symbol "optreset" (symnum = 16) >> sysupgrade: I: Performing postinstall checks >> /bin/sh: Undefined symbol "optreset" (symnum = 16) >> /bin/sh: Undefined symbol "optreset" (symnum = 16) >> sysupgrade: E: Some postinstall(8) checks have failed >> .. >> # sh >> >>sh: Undefined symbol "optreset" (symnum = 16) >> # /sbin/zpool status >> >> /sbin/zpool: Undefined symbol "suboptarg" (symnum = 17) >> # /sbin/reboot >> >> /lib/libutil.so.7: Undefined symbol "ifm_type_descriptions" (symnum = >> 6) >> Yup, that was my fault. It was broken for a few hours and you caught it during that time. If it makes you feel any better I got bitten the same way, but thanks for /rescue :-) christos
Re: failure to build guile 2.2.7 on current with current
In article <3082cabd-cc6a-cca3-c425-a27ab8e83...@libero.it>, Riccardo Mottola wrote: >Hi, > >I just upgraded to 10.99.2 via sysinst. I updated pkgsrc and started >rolling-replace. > >Guile dies this way: > >  SNARF regex-posix.doc >  CCLD    libguile-2.2.la >ld: .libs/libguile_2.2_la-posix.o: in function `scm_tmpnam': >posix.c:(.text+0x10e9): warning: warning: tmpnam() possibly used >unsafely, use mkstemp() or mkdtemp() >  CCLD    guile >ld: ./.libs/libguile-2.2.so: warning: warning: tmpnam() possibly used >unsafely, use mkstemp() or mkdtemp() >  GEN     guile-procedures.texi >guile: uncaught throw to wrong-type-arg: (#f Wrong type to apply: ~S >((10 (13 15 5 (guile) define-module* . #f) (5 ice-9 threads) (5 . >#:filename) (5 . >/usr/pkgsrc/lang/guile22/work/guile-2.2.7/module/ice-9/threads.scm) (5 . >#:imports) (5 ((ice-9 match)) ((ice-9 control))) (5 . #:exports) (5 >begin-thread make-thread with-mutex monitor parallel letpar par-map >par-for-each n-par-map n-par-for-each n-for-each-par-map >%thread-handler) (5 . #:replacements) (5 call-with-new-thread yield >cancel-thread join-thread thread? make-mutex make-recursive-mutex >lock-mutex try-mutex unlock-mutex mutex? mutex-owner mutex-level >mutex-locked? make-condition-variable wait-condition-variable >signal-condition-variable broadcast-condition-variable >condition-variable? current-thread all-threads thread-exited? >total-processor-count current-processor-count))) ((10 (13 15 5 (guile) >define-module* . #f) (5 ice-9 threads) (5 . #:filename) (5 . >/usr/pkgsrc/lang/guile22/work/guile-2.2.7/module/ice-9/threads.scm) (5 . >#:imports) (5 ((ice-9 match)) ((ice-9 control))) (5 . #:exports) (5 >begin-thread make-thread with-mutex monitor parallel letpar par-map >par-for-each n-par-map n-par-for-each n-for-each-par-map >%thread-handler) (5 . #:replacements) (5 call-with-new-thread yield >cancel-thread join-thread thread? make-mutex make-recursive-mutex >lock-mutex try-mutex unlock-mutex mutex? mutex-owner mutex-level >mutex-locked? make-condition-variable wait-condition-variable >signal-condition-variable broadcast-condition-variable >condition-variable? current-thread all-threads thread-exited? >total-processor-count current-processor-count >Cannot exit gracefully when init is in progress; aborting. >cat: stdout: Broken pipe >[1]  Done(1)                cat alist.doc array-handle.doc >array-map.doc a... | >      Abort trap             GUILE_AUTO_COMPILE=0 >../meta/build-env >guild s... >gmake[3]: *** [Makefile:4281: guile-procedures.texi] Error 1 > > >looks like guile is dying while compiling its own code, right? anyone >else seeing something similar? That should be fixed too if you update rtld. christos
Re: gnucash coredump on startup
In article , Thomas Klausner wrote: >On Sun, Jan 08, 2023 at 11:58:09PM +0100, Thomas Klausner wrote: >> On Sat, Jan 07, 2023 at 03:42:00PM -, Christos Zoulas wrote: >> > In article , >> > Thomas Klausner wrote: >> > >Hi! >> > > >> > >I've just replaced my 10.99.2/20221231 userland (kernel slightly >> > >older, but also 10.99.2) with a 10.99.2/20230107 kernel+userland. >> > > >> > >Now gnucash dumps core on startup: >> > >> > Could be rtld related. Can you try with the older ld_elf.so? >> >> I can't go back with just that one, but I did the following test: >> >> Downgraded my whole userland to 20221231: >> gnucash works >> >> install ld_elf.so from 20230107: >> gnucash dumps core >> >> install ld_elf.so from 20221231: >> gnucash works >> >> So yes, definitely an issue in ld_elf.so :) > >After christos' commits from the last hours, this bug is fixed - both >gnucash and guile (old binaries) still work on an updated system. > >I'll re-build the system from scratch next and report if there are any >issues. > >Thanks, christos! Don't thank me for something I broke in the first place :-) But yes, I think it is all working again now! christos
Re: ldscripts not cleaned up
In article , Thomas Klausner wrote: >On Sun, Jan 08, 2023 at 08:48:24PM -0000, Christos Zoulas wrote: >> In article , >> Thomas Klausner wrote: >> >Hi! >> > >> >NetBSD after the switch to binutils 2.39 does not install the >> >following files any longer, but they are not marked as obsolete >> >either: >> > >> >/usr/libdata/ldscripts/elf_k1om.x >> >/usr/libdata/ldscripts/elf_k1om.xbn >> >/usr/libdata/ldscripts/elf_k1om.xc >> >/usr/libdata/ldscripts/elf_k1om.xd >> >/usr/libdata/ldscripts/elf_k1om.xdc >> >/usr/libdata/ldscripts/elf_k1om.xdw >> >/usr/libdata/ldscripts/elf_k1om.xn >> >/usr/libdata/ldscripts/elf_k1om.xr >> >/usr/libdata/ldscripts/elf_k1om.xs >> >/usr/libdata/ldscripts/elf_k1om.xsc >> >/usr/libdata/ldscripts/elf_k1om.xsw >> >/usr/libdata/ldscripts/elf_k1om.xu >> >/usr/libdata/ldscripts/elf_k1om.xw >> >/usr/libdata/ldscripts/elf_l1om.x >> >/usr/libdata/ldscripts/elf_l1om.xbn >> >/usr/libdata/ldscripts/elf_l1om.xc >> >/usr/libdata/ldscripts/elf_l1om.xd >> >/usr/libdata/ldscripts/elf_l1om.xdc >> >/usr/libdata/ldscripts/elf_l1om.xdw >> >/usr/libdata/ldscripts/elf_l1om.xn >> >/usr/libdata/ldscripts/elf_l1om.xr >> >/usr/libdata/ldscripts/elf_l1om.xs >> >/usr/libdata/ldscripts/elf_l1om.xsc >> >/usr/libdata/ldscripts/elf_l1om.xsw >> >/usr/libdata/ldscripts/elf_l1om.xu >> >/usr/libdata/ldscripts/elf_l1om.xw >> > >> >Should new binutils install them, or should they be marked as obsolete? >> > >> They should be marked as obsolete... > >Done! > Thanks, well, only for the platform that has 239 christos
Re: ldscripts not cleaned up
In article , Thomas Klausner wrote: >Hi! > >NetBSD after the switch to binutils 2.39 does not install the >following files any longer, but they are not marked as obsolete >either: > >/usr/libdata/ldscripts/elf_k1om.x >/usr/libdata/ldscripts/elf_k1om.xbn >/usr/libdata/ldscripts/elf_k1om.xc >/usr/libdata/ldscripts/elf_k1om.xd >/usr/libdata/ldscripts/elf_k1om.xdc >/usr/libdata/ldscripts/elf_k1om.xdw >/usr/libdata/ldscripts/elf_k1om.xn >/usr/libdata/ldscripts/elf_k1om.xr >/usr/libdata/ldscripts/elf_k1om.xs >/usr/libdata/ldscripts/elf_k1om.xsc >/usr/libdata/ldscripts/elf_k1om.xsw >/usr/libdata/ldscripts/elf_k1om.xu >/usr/libdata/ldscripts/elf_k1om.xw >/usr/libdata/ldscripts/elf_l1om.x >/usr/libdata/ldscripts/elf_l1om.xbn >/usr/libdata/ldscripts/elf_l1om.xc >/usr/libdata/ldscripts/elf_l1om.xd >/usr/libdata/ldscripts/elf_l1om.xdc >/usr/libdata/ldscripts/elf_l1om.xdw >/usr/libdata/ldscripts/elf_l1om.xn >/usr/libdata/ldscripts/elf_l1om.xr >/usr/libdata/ldscripts/elf_l1om.xs >/usr/libdata/ldscripts/elf_l1om.xsc >/usr/libdata/ldscripts/elf_l1om.xsw >/usr/libdata/ldscripts/elf_l1om.xu >/usr/libdata/ldscripts/elf_l1om.xw > >Should new binutils install them, or should they be marked as obsolete? > They should be marked as obsolete... christos
Re: gnucash coredump on startup
In article , Thomas Klausner wrote: >Hi! > >I've just replaced my 10.99.2/20221231 userland (kernel slightly >older, but also 10.99.2) with a 10.99.2/20230107 kernel+userland. > >Now gnucash dumps core on startup: Could be rtld related. Can you try with the older ld_elf.so? christos
Re: nss_winbind not functional anymore on NetBSD 9.99.106 and Samba 4.16.5
Does this help? https://ogris.de/samba/unix-active-directory.html christos > On Dec 21, 2022, at 11:31 AM, Kunihiro Yasukouchi > wrote: > > Hi, > > little bit old topic,,, > >> combination NetBSD 9.99.106 and Samba 4.16.5(from pkgsrc 2022Q3), >> the name resolution for usernames / groups via nss_winbind does not work >> anymore. > I've also faced this issue on NetBSD 9.99.10[68], 10.99.1 and net/samba4 > 4.16.x, 4.17.x > > however, > NetBSD 9.99.108, 10.99.1, 10_BETA and net/samba4 4.15.x (latest > pkgsrc-2022Q2) is no problem. > > I could not find any change about winbind/nss_winbind on Samba release notes, > but some libraries linked to nss_winbind.so would be changed, > > for example, samba 4.15.x on NetBSD > % ldd /usr/lib/nss_winbind.so.0 > /usr/lib/nss_winbind.so.0: >-lwinbind-client-samba4 => > /usr/pkg/lib/samba/private/libwinbind-client-samba4.so >-lreplace-samba4 => /usr/pkg/lib/samba/private/libreplace-samba4.so >-lc.12 => /usr/lib/libc.so.12 >-lpthread.1 => /usr/lib/libpthread.so.1 > > > on the other hands, samba 4.16.x or later on NetBSD > % ldd /usr/lib/nss_winbind.so.0 > /usr/lib/nss_winbind.so.0: >-lpthread.1 => /usr/lib/libpthread.so.1 >-lc.12 => /usr/lib/libc.so.12 > > on any Linux or FreeBSD are also same, but working appropriately. > > like Matthias, winbind itself works well. wbinfo -u/-g retrieve information > from AD. > only via nss don't work well. > > >> Is there a way to view nsdispatch or the name service switch mechanism >> in more detail or to enable additional logging? > >> Has anyone observed the same problem and might have an idea what the >> problem is? > I'm looking for any solution, too... > > Regards, > -- > kei > > > In article (Subject: nss_winbind not functional anymore on NetBSD 9.99.106 > and Samba 4.16.5 >Date: Mon, 14 Nov 2022 11:06:20 +0100) > You(Matthias Petermann ) wrote : > >> Hello all, >> >> I have been using NetBSD 9.99.99 with Samba 4.15.9 (from pkgsrc >> 2022Q2) as Windows Domain Controller for a while now which worked >> well. >> >> Since I switched to the combination NetBSD 9.99.106 and Samba 4.16.5 >> (from pkgsrc 2022Q3), the name resolution for usernames / groups via >> nss_winbind does not work anymore. >> >> The Windows clients are not directly affected by this, since the nss >> mechanism, especially on the Unix side, ensures that the correct >> plaintext names can be displayed for the numeric user and group ids >> assigned by Samba - for example, with ls. The workaround at the moment >> is to work with the numeric IDs. This is inconvenient and error-prone. >> >> As proof, I try to display the user information for the built-in >> domain administrator account via id command: >> >> ``` >> net$ id Administrator >> id: Administrator: No such user >> ``` >> >> I have checked the following so far: >> >> 1) Basic function kerberos with kinit / klist. >> >> ``` >> net$ kinit Administrator >> Administrator@TEST.LOCAL's Password: >> >> net$ klist >> Credentials cache: FILE:/tmp/krb5cc_1000 >>Principal: Administrator@TEST.LOCAL >> >> IssuedExpires Principal >> Nov 14 10:42:45 2022 Nov 14 20:42:45 2022 krbtgt/TEST.LOCAL@TEST.LOCAL >> ``` >> >> 2) Joining the Domain from a Windows 11 Prof 22H2 based host >> >> - works >> >> 3) Basic function winbind >> >> ``` >> net$ wbinfo -i Administrator >> TEST\administrator:*:0:100::/home/TEST/administrator:/bin/false >> >> net$ wbinfo -g Administrator >> TEST\cert publishers >> TEST\ras and ias servers >> TEST\allowed rodc password replication group >> TEST\denied rodc password replication group >> TEST\dnsadmins >> TEST\enterprise read-only domain controllers >> TEST\domain admins >> TEST\domain users >> TEST\domain guests >> TEST\domain computers >> TEST\domain controllers >> TEST\schema admins >> TEST\enterprise admins >> TEST\group policy creator owners >> TEST\read-only domain controllers >> TEST\dnsupdateproxy >> ``` >> >> 4) /etc/nsswitch.conf >> >> ``` >> group: files winbind >> group_compat: nis >> hosts: files dns >> netgroup: files [notfound=return] nis >> networks: files >> passwd: files winbind >> passwd_compat: nis >> shells: files >> ``` >> >> 5) libnss winbind >> >> ``` >> net$ ls -la /usr/lib/nss_winbind.so.0 >> >> lrwxr-xr-x 1 root wheel 30 Nov 14 09:56 /usr/lib/nss_winbind.so.0 -> >> /usr/pkg/lib/libnss_winbind.so >> ``` >> >> 6) Ktrace of the "id" command (excerpts) >> >> ``` >> net$ ktrace id Administrator >> id: Administrator: No such user >> net$ kdump >> >> 592592 id CALL open(0x785c601b43b8,0x40,0x1b6) >> 592592 id NAMI "/etc/nsswitch.conf" >> 592592 id RET open 3 >> 592 592 id CALL >> >> mmap(0,0x7000,PROT_READ|PROT_WRITE,0x1002,0x,0,0) >> 592592 id RET mmap 132338150055936/0x785c606ca000 >> 592 592 id CALL >> >>
Re: ctfmerge i/o error
In article ,
Patrick Welche wrote:
>While trying to build a release, I am having trouble trying to make
>GENERIC_KASLR.debug, so manually, I tried
>
>cd /usr/obj/sys/arch/amd64/compile.amd64/GENERIC_KASLR
>make clean
>make dependall
>
>and repeatedly get
>
># link GENERIC_KASLR/netbsd
>ld -Map netbsd.map --cref -T netbsd.ldscript -Ttext 0x8020
>-e start --split-by-file=0x10 -r -d -X -o netbsd
>${SYSTEM_OBJ:[@]:Nswapnetbsd.o} ${EXTRA_OBJ} vers.o swapnetbsd.o
>NetBSD 9.99.108 (GENERIC_KASLR) #4: Wed Dec 14 10:40:49 CST 2022
> textdata bss dec hex filename
>21686890 686136 466512 2283953815c80f2 netbsd
>ERROR: ctfmerge: netbsd.ctf: Cannot finalize temp file: I/O error:
>Operation already in progress
>*** Error code 1
>
>which is not a message I recognize. FWIW /usr/obj is a ZFS filesystem, but
>this hasn't caused trouble so far...
>
>Thoughts?
Can you ktrace to find out what syscall caused EALREADY. zfs uses EALREADY
for TX_WRITE, when a block is already being synced according to my quick
glance to the code. I am not sure how this stuff is supposed to work, but
I don't think that this error is supposed to be returned by filesystem
related syscalls, but only for connect(2)?
Best,
christos
Re: /etc/protocols generation
Sounds good to me, perhaps something like src/etc/refresh-data/ with some structure under there? christos > On Nov 28, 2022, at 2:46 PM, Jan Schaumann wrote: > > Hello, > > I just spent some time shaving the /etc/protocols > generation yak. As best as I can tell the process how > that file is maintained is not documented and consists > of: > > 1) building the pkgsrc/net/iana-etc package > > This package pulls a few scripts from > http://sethwklein.net/iana-etc, which hasn't seen > updates since 2008. It then patches those scripts to > our needs and runs them to generate the files > 'protocols' and 'services'. > > 2) running the ATF tests from src/tests/lib/libc/net > > This assumes the updated files are іnstalled in /etc/ > as well as that you know to run the test. > > > 3) Copying the updated file into src/etc/. > > Prior to my recent changes to the iana-etc scripts, > this further required you to know that you had to > manually make / merge a few changes to the file. > Unsurprisingly, this frequently led to these changes > being reverted, then re-added. Still, this makes > tracking such changes difficult and notably outside of > the main source tree. > > > All of this strikes me as fragile. I'd like to > suggest to instead pull in glue / scripts to generate, > test, and update the file src/etc/ directly via > 'make', so that maintenance of the file is > self-contained within the source tree. > > Two questions: > > (a) Does that sound reasonable? > (b) Where should such helper scripts or glue live? > Directly in src/etc/Makefile, src/etc/gluescript, ...? > Or somewhere else? > > -Jan signature.asc Description: Message signed with OpenPGP
Re: Functional differences when using ntpd as NTP client on NTP-NetBSD 9.3<-->10 ?
In article <3407f89f-6d30-f1a5-d013-77176f249...@petermann-it.de>, Matthias Petermann wrote: >Hello all, > >I use ntpd in my Qemu/nvmm VMs as a client to synchronise the (otherwise >lagging) clocks. For this purpose, ntpd runs on the host and >synchronises on the internet. The ntpd in the VM only knows the host as >the only time source and is configured in such a way that it does not >give up even in the case of major deviations. This means, I use mostly >the defaults with the following adjustments: > >``` >$ doas vi /etc/ntp.conf > > tinker panic 0 stepout 30 > > #tos minsane 2 > > server 192.168.2.10 burst minpoll 4 maxpoll 6 true >``` > >This works reliably in the VMs with NetBSD 9.3 as guest. Deviations are >regularly compensated for by stepping. > >In the VMs with NetBSD 9.99.99 as guest, for some reason no stepping >takes place. As a consequence, in a short time deviations of several >seconds up to minutes occur. > >NetBSD 9.3 contains ntpd 4.2.8p11. In my build of NetBSD 9.99.99, ntpd >4.2.8p14 is included, but I have also seen that p15 is now in the tree. >Does anyone know if there have been any functional changes between these >three versions that could account for this behaviour? > >(I am aware that such questions are tricky in the virtualisation >context. For what it's worth, the host is running on NetBSD 9.3 with >HZ=1000, all VMs are running with HZ=100, and the Qemu processes are set >to "near real-time" priority in the host via Schedctl (SCHED_FIFO). >Since I have been using this setup with NetBSD 9.3 VMs, I have had no >more problems with clock synchronisation. With said NetBSD 9.99.99 VM, >all these host-side optimisations don't seem to help. Since the external >configuration is the same (same virtual CPU count), I suspect the cause >is more on the side of ntpd (or other internal changes that I'm not >thinking about at all right now). > >As always, I'm grateful for any helpful hints - chrony is compiling in >the background and I'll test it tonight as a workaround. from man ntp.conf: The quality and reliability of the suite of associations discovered by the manycast client is determined by the NTP mitigation algorithms and the minclock and minsane values specified in the tos configuration command. At least minsane candidate servers must be available and the mitigation algorithms produce at least minclock survivors in order to synchronize the clock. Byzantine agreement principles require at least four candidates in order to correctly discard a single falseticker. For legacy purposes, minsane defaults to 1 and minclock defaults to 3. For manycast service minsane should be explicitly set to 4, assuming at least that number of servers are available. How many clocks are you synchronizing against? Could it be that you end up with fewer than minclock servers? christos
Re: readlink(1) realpath(1) and POSIX
In article <14374.1657965...@jacaranda.noi.kre.to>, Robert Elz wrote: >POSIX is planning to add readlink(1) in the next version. Nothing >special to say about that (makes no real difference to us, we have it >already, they will specify only the common options.) > >But while doing that, they looked at the -f option, and saw in coreutils >that their man page says to use realpath(1) instead of readlink -f > >(They never even got as far as detecting that our readlink -f and the >coreutils readlink -f don't act the same). > >So, it was asked whether other systems have realpath(1) - we do, kamil@ >added it back in Feb 2020, with the comment: > > Port realpath(1) from FreeBSD > > realpath(1) wraps realpath(3) and returns resolved physical path. > > This utility shipped with GNU and FreeBSD is sometimes > used in scripts in the wild. > >It is currently in HEAD only - it will be in 10 when that gets released. > >So, POSIX has more or less decided to skip the -f option of readlink, >and require realpath(1) instead (realpath(3) has been around in POSIX for ages, >but is an XSI option ... realpath(1) won't be, just mandatory (probably)). > >However, FreeBSD's realpath(1) (now also ours) and the coreutils realpath(1) >are substantially different beasts - the FreeBSD version is (as kamil said) >just a wrapper around realpath(3) and is quite simple. > >coreutils realpath is a monstrous mess.Fortunately, POSIX aren't >proposing standardising almost any of that, just the basic functionality >which replaces readlink -f. > >Unfortunately, for POSIX (and us) basic realpath (as in "realpath file") >has the same basic operational difference as readlink -f has between the >BSD & GNU implementations. Ours is literally: "call realpath(3), if it >returns something, print that, otherwise it is an error". Theirs allows >the final component in the expanded and canonicalized path to not exist. >(Their doc does not say what "not exist" really means in the hard cases, >but from testing their implementation, it is clear that if namei() returns >ENOENT for the final component, that is an allowed case, any other error >return is not). > >The people who use this demand that functionality remain (I'm still unclear >on why - if the file is not to be created, who cares what its canonical path >would be, if it is, create it first using the known name, and canonicalize >later should work I would have thought ... but they don't agree - they say, >that if we want to know if it exists, we can canonicalise first, then test -e >though for a long time I wasn't sure how that was a rational counter argument, >I'm still not). > >For a while I thought we could just do (in C, not exactly this) if >realpath($FILE) fails: > echo $(realpath $(dirname $FILE))/$(basename $FILE) >(with appropriate tests for when $FILE has no '/' etc), but that doesn't >work - it is not just the last component of the $FILE arg which is allowed not >to exist (though that case is part of it) but where that component exists, >and is a symlink, and the last component of that doesn't exist, or exists >and is another symlink for which ... this can go on (almost) forever. > >The current POSIX proposal is to specify "realpath -e" (which is a coreutils >arg which makes theirs act just like ours) and also invent a new -E >arg, which would make ours work like theirs. It would be unspecified >which was the default - ie: all scripts would need to use one of those >options to be portable. The allowed result when neither option is given is >made even more bizarre to cater for a built in realpath in mksh, which >is even wackier in its default (and only) behaviour (inexplicable in some >cases) than the coreutils version - but the mksh one takes exactly 1 arg, >the path name, and simply execs realpath from the filesystem if anything >different is passed to it, so "realpath -[Ee] file" will bypass that >implementation and run a real one instead. > >I have added -E support to our realpath(1) (that is, to the .c, haven't >gotten around to the man page yet) and of course -e (which is more or >less a no-op). For now, I have made the default be -E if neither option >is given, which returns the same result as we currently get in cases >we do not currently produce an error, and makes our implementation more >compatible with (the small part that is sane) of the coreutils implementation. > >I am not proposing adding any of their myriad other useless options, with >the sole possible exception of -z (which causes their realpath to use \0 >rather than \n between output paths, and makes it a little safer in the >possible presence of paths containing newline chars when more than one >path arg is given ... the POSIX version (currently) will only specify >realpath working with a required single file arg .. our version (the FreeBSD >version), defaults to "." if no file is given, coreutils don't do that, >and both versions process as many file args as are given). > >The source file
Re: Can I divorce readlink(1) from stat(1) ?
In article <3880.1655748...@jacaranda.noi.kre.to>, Robert Elz wrote: >Currently readlink(1) and stat(1) (and I do mean the man pages) >have a very unhealthy relationship. > >They're currently bound together based upon the accident of >their parentage - that is, there is no readlink.c, readlink >the command is accomplished by using stat with a particular >set of options. That could easily have been done with a sh >script, but instead is done by combining the two into one >binary which tests argv[0] to decide what to do. > >That's all fine, and I am not proposing changing anything about >the way the code works, or is implemented. > >But, the man page (there is currently just one for both) is a mess. >Go read it (use either name, you get the same thing) and take a look. > >The two commands have an (almost) completely unrelated option sets, >they are designed to do quite different things (even though stat can >obviously be made to do what readlink does), and documenting them as >if they were just minor variations on each other (like say, printf(3) >and fprintf(3)) is just wrong. > >So, I'd like to give them each a man page of their own (they can each >SEE ALSO the other, though the readink -> stat direction is the more >important one for that). > >Any objections? Go for it! Thanks, christos
Re: Interesting output from npfctl
In article , John Klos wrote: >Hi, > >One of my blocklist files ended up with a duplicate entry, and npfctl >reload had this to say: > >npfctl reload >npfctl: ?8t?f??K???H?5d? > > 6e 70 66 63 74 6c 3a 20 83 38 11 74 e5 66 90 e8 |npfctl: .8.t.f..| >0010 4b f3 ff ff 48 8d 35 64 a6 0a|K...H.5d..| > >NetBSD-9.99.97 from 23-May-2022, amd64. > Should be fixed with: /cvsroot/src/lib/libnpf/npf.c,v <-- npf.c new revision: 1.50; previous revision: 1.49 christos
Re: Crash on various Supermicro motherboards
In article , <6b...@6bone.informatik.uni-leipzig.de> wrote: >Hello, > >I now have the backtrace: > >https://speicherwolke.uni-leipzig.de/index.php/s/cFXAbL6axwHpKkL What CPUs are these? I don't see the cpu lines in the avi... christos
Re: Recent install images do not install netbsd.gdb
> On Jan 15, 2022, at 9:43 AM, pin wrote: > >>> What should I run now instead? > >> If you have MKDEBUG set in your build or have installed the debug sets: > > Thanks! > I don't think I follow, though. Sorry. > > I didn't build this kernel, the system was installed from a daily-build image. > >> # gdb --eval-command="file /netbsd" --eval-command="target kvm > > Do you mean the debug symbols are baked into the kernel now? The kernel debug symbols are installed in /usr/libdata/netbsd-.debug and the debugger knows to look for them there. They are in the debug set. Did you install that? >> Now, there should be also be a netbsd.gdb in the sets if you have >> MKDEBUGKERNEL >> defined. > > I did run > # find / -name netbds.gdb > > and it returned nothing. Ok, that is not a problem as long as the previous works :-) christos signature.asc Description: Message signed with OpenPGP
Re: Recent install images do not install netbsd.gdb
In article , pin wrote: > > >Sent with ProtonMail Secure Email. > >âââââââ Original Message âââââââ > >On Friday, January 14th, 2022 at 12:15 PM, Martin Husemann > wrote: > > >> The debug information moved, it is now stored in an external debug file >> >> in /usr/libdata/debug. >> >> Martin > >Thank you! >But, where is netbsd.gdb located? I can't find it. >I used to run > ># gdb --eval-command="file /netbsd.gdb" --eval-command="target kvm >netbsd.0.core" --eval-command "bt" > >What should I run now instead? If you have MKDEBUG set in your build or have installed the debug sets: # gdb --eval-command="file /netbsd" --eval-command="target kvm Now, there should be also be a netbsd.gdb in the sets if you have MKDEBUGKERNEL defined. christos christos
Re: execute statically-linked linux files
In article <91bb6459-8ec6-ad30-6c35-4cb9831d...@sdf.org>,
RVP wrote:
>I forgot this:
>
>---START PATCH---
>--- sys/miscfs/procfs/procfs_vnops.c.orig 2021-12-09 04:11:22.778882692
>+
>+++ sys/miscfs/procfs/procfs_vnops.c 2022-01-06 22:24:06.003672573 +
>@@ -1400,6 +1400,7 @@
> nc++;
> }
> if (error) {
>+ procfs_proc_unlock(p);
> ncookies = nc;
> break;
> }
>@@ -1454,6 +1455,7 @@
> nc++;
> }
> if (error) {
>+ procfs_proc_unlock(p);
> ncookies = nc;
> break;
> }
>---END PATCH---
>
>A couple of procfs_proc_unlock()s are missing in the
>error path.
Fixed, thanks!
christos
Re: netbsd-9.99.93 crash
In article , <6b...@6bone.informatik.uni-leipzig.de> wrote: >Does that help? > >Regards >Uwe I have the same issue and I can reproduce this on demand. I have disabled IPv6 on this router. christos
Re: building "distribution sets" fails due to missing kernel "*.debug" files
In article ,
John D. Baker wrote:
>I routinely build "distribution sets" for "playstation2" since the
>kernel doesn't build.
>
>Since the addition of the "netbsd-${CONF}.debug" files, building the
>debug set fails if the expected kernels were not built.
>
>In the case of "playstation2", it also wants the "*.debug" files for
>32-bit "evbmips-mipsel" kernels:
>
>== 8 missing files in DESTDIR
>Files in flist but missing from DESTDIR.
>File wasn't installed ?
>--
>./usr/libdata/debug/netbsd-aumac0-ALCHEMY.debug
>./usr/libdata/debug/netbsd-aumac0-DBAU1500.debug
>./usr/libdata/debug/netbsd-aumac0-DBAU1550.debug
>./usr/libdata/debug/netbsd-aumac0-INSTALL_OMSAL400.debug
>./usr/libdata/debug/netbsd-aumac0-MTX-1.debug
>./usr/libdata/debug/netbsd-aumac0-OMSAL400.debug
>./usr/libdata/debug/netbsd-reth0-CPMBR1400.debug
>./usr/libdata/debug/netbsd-sd0a-CPMBR1400.debug
> end of 8 missing files ==
>
>Can things be conditioned so that if the kernel wasn't built, it is not
>an error to not have the ".debug" file for it--particularly if you're
>building a platform related to another as "playstation2" is related to
>"evbmips", but has it's own kernel config (which isn't built either)?
I think we just need to fix the sets properly. The sets system is versatile
enough, but it is a little complicated (or at least I don't understand it
well enough yet).
christos
Re: Recent compiler_rt changes
In article , Adam wrote: >Greetings, > >Something has got broken with the recent changes for compiler_rt >(https://mail-index.netbsd.org/source-changes/2021/09/17/msg132320.html). >Now my build fails with > >x86_64--netbsd-install: >/tmp/pkgsrc/destdir.amd64/usr/lib/clang/9.0.0/include/sanitizer/allocator_interface.h.inst.b01IaH: > mkstemp: No such file or directory > >I guess Clang version should be set to 13.0.0, but instead it's >hard-coded as 9.0.0 in: >- external/bsd/compiler_rt/lib/clang/include/sanitizer/Makefile >- external/bsd/compiler_rt/lib/clang/include/xray/Makefile >- external/bsd/compiler_rt/lib/clang/share/Makefile > >Any idea how to fix this? I am fixing it. christos
Re: /bin/sh tabcomplete
This is a side effect of the change to add file-completion for commands. Fixed. christos > On Sep 14, 2021, at 6:24 AM, Robert Elz wrote: > >Date:Tue, 14 Sep 2021 09:19:36 +0100 >From:Patrick Welche >Message-ID: > > | It seems that after updating a box from August -current to yesterday's > | -current, /bin/sh's tabcomplete no longer escapes spaces? > > If something changed there, it must be related to the way that libedit now > works, Christos? > > kre signature.asc Description: Message signed with OpenPGP
Re: Problem with -fsanitize=leak and libpthread
In article <20210810124709.vhixir5hl5g7l...@yt.nih.at>, Thomas Klausner wrote: >-=-=-=-=-=- > >Hi! > >I was looking for memory leaks in a threaded program using >-fsanitize=leak when I had a weird issue with pthread_join not working >after pthread_cancel. > >So I wrote a small test program. When I compile this with leak >detection, it doesn't even start: > >==23045==Sanitizer CHECK failed: >/usr/src/external/gpl3/gcc/dist/libsanitizer/sanitizer_common/sanitizer_thread_registry.cc:284 > ((tid)) < ((n_contexts_)) (4294967295, 1) > >Any ideas? > >To reproduce, install NetBSD/9.99.88/amd64 and do > >gcc -g -fsanitize=leak -o join join.c -lpthread >./join I used cc -fsanitize=leak -pthread join.c -o join and it worked christos
Re: Weird ldd problem
In article , Chavdar Ivanov wrote: >I have to read more to understand it though... It is a kernel issue. The kernel is passing an executable pathname that is not an absolute path and RTLD correctly refuses to honor $ORIGIN. christos
Re: Blank screen when build packages
In article , David H. Gutteridge wrote: > >This is probably PR 56223. This is PR56223 from the video and I just committed a change to fix it. christos
Re: Blank screen when build packages
In article <1943061623074...@mail.yandex.ru>, Dmitrii Postolov wrote: >Hi! Sorry for my bad English... > >NetBSD 9.99.83 GENERIC Sun Jun 6 2021 > >After install NetBSD 9.99.83 and download and unpack pkgsrc-current, I >try to build some apps >from pkgsrc, for example 'editors/nano'. Afrer 'make install clean' the >app begin to build but >after some time the screen is blank and build stop. There is no this problem in >NetBSD 9.2_STABLE and pkgsrc-current. > >How can I resolve this problem in NetBSD 9.99.x? Looks like your build is probably sending some escape char to the console that makes it blank. Can you redirect stdout and stderr to a file? christos
Re: Automated report: NetBSD-current/i386 build failure
In article <24751.41935.824926.178...@guava.gson.org>, Andreas Gustafsson wrote: >The i386 build is still failing, but now with a different error: > > --- in6_pcb.o --- > /tmp/build/2021.05.27.08.58.29-i386/src/sys/netinet6/in6_pcb.c: In >function 'in6_pcblookup_port': > cc1: error: function may return address of local variable >[-Werror=return-local-addr] > >/tmp/build/2021.05.27.08.58.29-i386/src/sys/netinet6/in6_pcb.c:1056:26: >note: declared here > 1056 | struct vestigial_inpcb better; >| ^~ > >It's not clear to me which of the commits made since christos first >broke the build could have triggered this, nor why this is not >affecting all ports. Fixed in: cvs commit bsd.own.mk /cvsroot/src/share/mk/bsd.own.mk,v <-- bsd.own.mk new revision: 1.1251; previous revision: 1.1250 christos
Re: Automated report: NetBSD-current/i386 build failure
In article , Christos Zoulas wrote: >In article <24751.41935.824926.178...@guava.gson.org>, >Andreas Gustafsson wrote: >>The i386 build is still failing, but now with a different error: >> >> --- in6_pcb.o --- >> /tmp/build/2021.05.27.08.58.29-i386/src/sys/netinet6/in6_pcb.c: In >>function 'in6_pcblookup_port': >> cc1: error: function may return address of local variable >>[-Werror=return-local-addr] >> >>/tmp/build/2021.05.27.08.58.29-i386/src/sys/netinet6/in6_pcb.c:1056:26: >>note: declared here >> 1056 | struct vestigial_inpcb better; >>| ^~ >> >>It's not clear to me which of the commits made since christos first >>broke the build could have triggered this, nor why this is not >>affecting all ports. > >That code is tricky and the compiler usage analysis might not be figuring >out that this can't happen. When I last looked at it, I considered simplifying >it so that it is obvious that this can't happen. I think that did it :-) Modified Files: src/external/gpl3/gcc: README.gcc10 src/share/mk: bsd.own.mk Log Message: switch mips* and i386 to GCC 10. I guess I'll have to simplify it for real now :-) christos
Re: Automated report: NetBSD-current/i386 build failure
In article <24751.41935.824926.178...@guava.gson.org>, Andreas Gustafsson wrote: >The i386 build is still failing, but now with a different error: > > --- in6_pcb.o --- > /tmp/build/2021.05.27.08.58.29-i386/src/sys/netinet6/in6_pcb.c: In >function 'in6_pcblookup_port': > cc1: error: function may return address of local variable >[-Werror=return-local-addr] > >/tmp/build/2021.05.27.08.58.29-i386/src/sys/netinet6/in6_pcb.c:1056:26: >note: declared here > 1056 | struct vestigial_inpcb better; >| ^~ > >It's not clear to me which of the commits made since christos first >broke the build could have triggered this, nor why this is not >affecting all ports. That code is tricky and the compiler usage analysis might not be figuring out that this can't happen. When I last looked at it, I considered simplifying it so that it is obvious that this can't happen. christos
Re: Automated report: NetBSD-current/i386 build failure
Fixed...
christos
> On Apr 18, 2021, at 9:39 AM, Andreas Gustafsson wrote:
>
> The i386 build is still failing, with errors like these:
>
> --- dependall-tmux ---
>
> /tmp/build/2021.04.18.12.05.29-i386/src/external/bsd/tmux/dist/cmd-display-menu.c:
> In function 'cmd_display_menu_get_position':
>
> /tmp/build/2021.04.18.12.05.29-i386/src/external/bsd/tmux/dist/cmd-display-menu.c:158:8:
> error: comparison of integer expressions of different signedness: 'long int'
> and 'u_int' {aka 'unsigned int'} [-Werror=sign-compare]
>158 | if (n >= tty->sy)
>|^~
>
> /tmp/build/2021.04.18.12.05.29-i386/src/external/bsd/tmux/dist/cmd-display-menu.c:191:8:
> error: comparison of integer expressions of different signedness: 'long int'
> and 'u_int' {aka 'unsigned int'} [-Werror=sign-compare]
>191 | if (n >= tty->sy)
>|^~
>
> /tmp/build/2021.04.18.12.05.29-i386/src/external/bsd/tmux/dist/cmd-display-menu.c:239:8:
> error: comparison of integer expressions of different signedness: 'long int'
> and 'u_int' {aka 'unsigned int'} [-Werror=sign-compare]
>239 | if (n < h)
>|^
>
> --
> Andreas Gustafsson, g...@gson.org
signature.asc
Description: Message signed with OpenPGP
Re: mail/sendmail not relaying on netbsd-9/sparc, problem with OpenSSL update?
> On Apr 9, 2021, at 6:38 PM, matthew green wrote: > >> Different to other asm code that e.g. properly detetects various VIS >> instructions that may or may not be available on the current CPU, the code >> in ghash-sparcv9.pl is plain sparcv9 code and can not be enabled for our >> sparc builds. >> >> Christos, can you disable all "modes" asm and request pullup? >> I can quickly test on -current... > > for a quick fix, this is OK, but long term, these are built > for sparc64 compat32 as well, and benefit from having this > code in place. > > John's point about __arch64__ may be relevant -- i'm pretty > sure that, before, that would only be set for sparc64 builds, > be it 32 or 64 bit userland, since that target defaults to > __arch64__ (which means sparcv9, not 64 bit ABI.) so if > this has been removed, we're now building this code on sparc > as well as sparc64 (both ways), which is new, and clearly it > is buggy. That's right. The reason the bug surfaced is that I made the code look like upstream to reduce our local diffs. christos signature.asc Description: Message signed with OpenPGP
Re: mail/sendmail not relaying on netbsd-9/sparc, problem with OpenSSL update?
Well, the assembly block is enabled only if we have vis3 instructions:
# elif defined(GHASH_ASM_SPARC)
if (OPENSSL_sparcv9cap_P[0] & SPARCV9_VIS3) {
gcm_init_vis3(ctx->Htable, ctx->H.u);
ctx->gmult = gcm_gmult_vis3;
CTX__GHASH(gcm_ghash_vis3);
} else {
gcm_init_4bit(ctx->Htable, ctx->H.u);
ctx->gmult = gcm_gmult_4bit;
CTX__GHASH(gcm_ghash_4bit);
}
What does OPENSSL_sparcv9_cap_P[0] contain.
christos
> On Apr 8, 2021, at 7:04 AM, Martin Husemann wrote:
>
> On Thu, Apr 08, 2021 at 02:36:07AM -0500, John D. Baker wrote:
>> -# if defined(__arch64__)
>> -# define GHASH_ASM_SPARC
>> -# define GCM_FUNCREF_4BIT
>> +# define GHASH_ASM_SPARC
>> +# define GCM_FUNCREF_4BIT
>> extern unsigned int OPENSSL_sparcv9cap_P[];
>> void gcm_init_vis3(u128 Htable[16], const u64 Xi[2]);
>> void gcm_gmult_vis3(u64 Xi[2], const u128 Htable[16]);
>> void gcm_ghash_vis3(u64 Xi[2], const u128 Htable[16], const u8 *inp,
>> size_t len);
>> -# endif
>> [...]
>>
>> That is, before the pull-up of OpenSSL 1.1.1k, the "GHASH_ASM_SPARC"
>> macro was conditionally defined iff "__arch64__" was also defined--
>> likely an internal compiler definition.
>
> I had a look and can reproduce the issue localy (without sendmail
> involved) - a simple:
>
> openssl s_client -starttls smtp -connect ${MAIL_SERVER}:25
>
> does it.
>
> Different to other asm code that e.g. properly detetects various VIS
> instructions that may or may not be available on the current CPU, the code
> in ghash-sparcv9.pl is plain sparcv9 code and can not be enabled for our
> sparc builds.
>
> Christos, can you disable all "modes" asm and request pullup?
> I can quickly test on -current...
>
> Martin
signature.asc
Description: Message signed with OpenPGP
Re: Partial reads on unix domain sockets
In article ,
Tom Ivar Helbekkmo wrote:
>Some time last year, probably late summer or autumn, a change was made
>that caused transfer of small chunks of data over unix domain sockets to
>have a higher chance of resulting in a read() getting only part of the
>chunk.
>
>While there is no guarantee of a one to one relationship between writes
>and reads, it seems that some applications expect this. In my case, it
>was jack (pkgsrc/audio/jack) that failed. It comes with, among other
>things, a daemon, jackd, and a library for use by clients wishing to
>connect to it. Communication between jackd and its clients became
>impossible with this change, because the code in jack expects to be able
>to exchange C structs between server and clients. The jackd server has
>a thread that uses poll() to wait for available packets from clients,
>and when something arrives, it is read with code like this example:
>
> if (read (client_fd, , sizeof(req)) != sizeof(req)) {
> jack_error ("cannot read ACK connection request from client");
> return -1;
> }
>
>The client_fd is an open unix domain stream socket, and it is *not* in
>non-blocking mode. The structs being transfered are of various sizes,
>and can, from a casual inspection of the header files, be up to a couple
>of hundred bytes long.
>
>Data is written to the sockets using code like this:
>
> if (write (reply_fd, , sizeof(req)) < (ssize_t)sizeof(req)) {
> jack_error ("cannot write request result to client");
> return -1;
> }
>
>Meanwhile, in the client library, the code at the other end of this
>communication is simply:
>
> if (write (fd, , sizeof(req)) != sizeof(req)) {
> jack_error ("cannot write event connect request to server (%s)",
> strerror (errno));
> close (fd);
> return -1;
> }
>
> if (read (fd, , sizeof(res)) != sizeof(res)) {
> jack_error ("cannot read event connect result from server (%s)",
> strerror (errno));
> close (fd);
> return -1;
> }
>
>Obviously, poll() will return, with information about available data,
>before the entire chunk written by the other end is available.
>
>I haven't filed a PR on this, as it isn't technically an error in
>NetBSD. However, if there is a wide-spread belief out there that code
>such as this will "just work" (I'm guessing it "just works" on Linux,
>just like it does on NetBSD < 10), and it's not otherwise detrimental to
>have the data from a single write() call all be available to the reader
>of the socket before triggering a select() or poll() that's waiting for
>it, then maybe such an adjustment should be considered.
Can you please file a PR with an example to keep track of it. It is a behavior
change after all and we should understand why it happened.
christos
Re: cmake hang ... again
In article , Manuel Bouyer wrote: >On Tue, Apr 06, 2021 at 02:24:50PM +0100, Chavdar Ivanov wrote: >> Hi, >> >> It may or may not be linked to the recent rather enthralling >> discussion about the entropy; I don't know. I've asked for ideas in >> the past, but couldn't figure out what to do if it hits me again. >> >> Usually I run -current on amd64, updating the systems on average 2-3 >> times a week; I also use pkgsrc-head and again, 2-3 times a month I >> cvs update my pkgsrc tree, together with a ' git pull' in wip, and I >> run 'pkg_rolling-replace'. >> >> Each and every run of pkg_rolling-replace gets me to a seemingly >> identical hang in cmake in a single package - misc/kdepim4 , in >> apparently the same spot. with similar trace. Attaching to the process > >I see the same thing in bulk builds, with various kde packages. >When I asked I've been told that this was a known issue, but without fix ... I've looked for a specific PR for that problem and while we have multiple PR/s for jemalloc we don't have one for this issue. Can we open one? Does linking with -lgnumalloc avoid the issue? christos
Re: -current tar(1) breakage
In article , Joerg Sonnenberger wrote: >On Sat, Apr 03, 2021 at 08:14:34PM -0000, Christos Zoulas wrote: >> In article , Joerg Sonnenberger > wrote: >> >On Sat, Apr 03, 2021 at 01:15:15AM -0400, Christos Zoulas wrote: >> >> Yes, I think that the appropriate change is to make those assertions >> >> so if there is a broken filesystem/syscall there is a more obvious >> >> error (rather than infinite loop in read or core-dump in iconv), but let's >> >> see what joerg thinks about all that. >> > >> >The infinite loops are perfectly reasonable behavior for broken kernel >> >input and found in other tools using the interface. IMO the kernel >> >should always do a sanity cap for puffs/fuse here. >> >> Yes, but defensive programming is good. >> >> >The iconv coredump is a buffer overflow, but nothing libarchive can do >> >about. The memory allocated for the dirent is based on the namemax of >> >the filesystem and we kind of have to trust the filesystem to do what it >> >promised. The system call doesn't have a size argument... >> >> Right, but it can check if the size makes sense before using it. > >The next filesystem will put one in the field and we are back... There is a difference between sub-optimal performance and core-dumping or infinite-looping. christos
Re: -current tar(1) breakage
In article , Joerg Sonnenberger wrote: >On Sat, Apr 03, 2021 at 01:15:15AM -0400, Christos Zoulas wrote: >> Yes, I think that the appropriate change is to make those assertions >> so if there is a broken filesystem/syscall there is a more obvious >> error (rather than infinite loop in read or core-dump in iconv), but let's >> see what joerg thinks about all that. > >The infinite loops are perfectly reasonable behavior for broken kernel >input and found in other tools using the interface. IMO the kernel >should always do a sanity cap for puffs/fuse here. Yes, but defensive programming is good. >The iconv coredump is a buffer overflow, but nothing libarchive can do >about. The memory allocated for the dirent is based on the namemax of >the filesystem and we kind of have to trust the filesystem to do what it >promised. The system call doesn't have a size argument... Right, but it can check if the size makes sense before using it. Yes, we expect the OS to return something reasonable in those cases, but we can sanity check the values we compute (for buffers) so that the program does not crash. An assertion in this case would have saved a lot of debugging time. christos
Re: -current tar(1) breakage
Yes, I think that the appropriate change is to make those assertions so if there is a broken filesystem/syscall there is a more obvious error (rather than infinite loop in read or core-dump in iconv), but let's see what joerg thinks about all that. Best, christos > On Apr 2, 2021, at 5:13 PM, RVP wrote: > > On Fri, 2 Apr 2021, Christos Zoulas wrote: > >>> f_iosize is also overridden (512 vs. 4k from FUSE-ext2). >> >> I think all that initialization is done here: >> https://nxr.netbsd.org/xref/src/lib/libpuffs/subr.c#102 >> and here: >> https://nxr.netbsd.org/xref/src/sys/fs/puffs/puffs_vfsops.c#211 >> > > Yes, I noticed those. > >> I am not sure if the puffs stavfs values are supposed to reflect the >> values of the underlying filesystem or they are supposed to be standard >> values for puffs filesystems (which seems to be the case). >> > > OK. > >> I believe I have fixed that. >> > > Excellent! Where, though? Will you then be changing the libarchive fixes > to something else? asserts or error-returns from > setup_current_filesystem() maybe? > > -RVP signature.asc Description: Message signed with OpenPGP
Re: -current tar(1) breakage
Inline below... > On Apr 2, 2021, at 3:14 AM, RVP wrote: > > On Thu, 1 Apr 2021, Christos Zoulas wrote: > >>> On Apr 1, 2021, at 7:56 PM, RVP wrote: >>> >>> But, there is a problem here, though: copy_statvfs_info() overrides >>> the FUSE-supplied f_namemax (EXT2_NAME_LEN = 255): >> >> Yes, puffs is special... Let me think what's the best way to fix that. >> > > f_iosize is also overridden (512 vs. 4k from FUSE-ext2). I think all that initialization is done here: https://nxr.netbsd.org/xref/src/lib/libpuffs/subr.c#102 and here: https://nxr.netbsd.org/xref/src/sys/fs/puffs/puffs_vfsops.c#211 I am not sure if the puffs stavfs values are supposed to reflect the values of the underlying filesystem or they are supposed to be standard values for puffs filesystems (which seems to be the case). > >>> >>> No idea--didn't look too deeply into this. Are you able to >>> reproduce this issue? >>> >> >> I am trying to follow the steps you described. I don't see the unmount >> and remount though... >> > > I can reliably get a f_namemax of 0 using this script: I believe I have fixed that. Best, christos signature.asc Description: Message signed with OpenPGP
Re: -current tar(1) breakage
> On Apr 1, 2021, at 7:56 PM, RVP wrote:
>
> On Thu, 1 Apr 2021, Christos Zoulas wrote:
>
>> RVP wrote:
>>>
>>> Indeed. Bug #56083 is caused by the wrong function being called:
>>>
>>> diff -u /usr/src/sys/fs/puffs/puffs_vfsops.c{.orig,}
>>> --- /usr/src/sys/fs/puffs/puffs_vfsops.c.orig 2020-02-27
>>> 22:12:53.0 +
>>> +++ /usr/src/sys/fs/puffs/puffs_vfsops.c2021-03-30
>>> 12:02:35.402544154 +
>>> @@ -503,7 +503,7 @@
>>> */
>>>copy_statvfs_info(sbp, mp);
>>>if (!error) {
>>> - statvfs_to_puffs_statvfs(sbp, _msg->pvfsr_sb);
>>> + puffs_statvfs_to_statvfs(_msg->pvfsr_sb, sbp);
>>>}
>>
>> This is not exactly right either, I fixed it.
>
> Yes. What I did above is wrong. copy_statvfs_info() should come after
> puffs_statvfs_to_statvfs(). Otherwise, you end up with a mount with
> empty to and from names--yeesh.
>
> But, there is a problem here, though: copy_statvfs_info() overrides
> the FUSE-supplied f_namemax (EXT2_NAME_LEN = 255):
Yes, puffs is special... Let me think what's the best way to fix that.
>
> $ ./a.out /mnt/work/dmesg.txt svfs.f_frsize: 4096
> svfs.f_iosize: 512
> svfs.f_bsize: 4096
> svfs.f_namemax: 511 <-- not EXT2_NAME_LEN
>
>>> The statvfs-filling sequence starting at line 219 doesn't look right
>>> either:
>>>
>>>219 struct statvfs *sb = STATVFSBUF_GET();
>>>220 puffs_statvfs_to_statvfs(>pa_svfsb, sb);
>>>221 copy_statvfs_info(sb, mp);
>>>222 STATVFSBUF_PUT(sb);
>>>223
>>>224 statvfs_to_puffs_statvfs(>mnt_stat, >pa_svfsb);
>>
>> Why?
>>
>
> Well, because, it seems to me, that the values copied into `sb'
> are just discarded. This confused me when I saw it first because
> the puffs statvfs copy functions reverse the usual convention of
> having a (dest, src) argument order--they have (src, dest).
> copy_statvfs_info() has it the usual way.
Yes, when I wrote them I was debating about the order of the arguments:
follow the function name order or destination first...
>> The question is where does NFS return a 0 namelen...
>>
>
> No idea--didn't look too deeply into this. Are you able to
> reproduce this issue?
>
I am trying to follow the steps you described. I don't see the unmount
and remount though...
christos
signature.asc
Description: Message signed with OpenPGP
Re: -current tar(1) breakage
In article ,
RVP wrote:
>On Thu, 1 Apr 2021, Joerg Sonnenberger wrote:
>
>> This should be fixed in the kernel. Seriously, stop adding more code to
>> deal with garbage from the kernel.
>>
>
>Indeed. Bug #56083 is caused by the wrong function being called:
>
>diff -u /usr/src/sys/fs/puffs/puffs_vfsops.c{.orig,}
>--- /usr/src/sys/fs/puffs/puffs_vfsops.c.orig 2020-02-27
>22:12:53.0 +
>+++ /usr/src/sys/fs/puffs/puffs_vfsops.c2021-03-30
>12:02:35.402544154 +
>@@ -503,7 +503,7 @@
> */
> copy_statvfs_info(sbp, mp);
> if (!error) {
>- statvfs_to_puffs_statvfs(sbp, _msg->pvfsr_sb);
>+ puffs_statvfs_to_statvfs(_msg->pvfsr_sb, sbp);
> }
This is not exactly right either, I fixed it.
>The statvfs-filling sequence starting at line 219 doesn't look right
>either:
>
> 219 struct statvfs *sb = STATVFSBUF_GET();
> 220 puffs_statvfs_to_statvfs(>pa_svfsb, sb);
> 221 copy_statvfs_info(sb, mp);
> 222 STATVFSBUF_PUT(sb);
> 223
> 224 statvfs_to_puffs_statvfs(>mnt_stat, >pa_svfsb);
Why?
The question is where does NFS return a 0 namelen...
christos
Re: -current tar(1) breakage
What is the NFS server? Because on NetBSD it returns 255... statvfs.c Description: Binary data christos > On Mar 31, 2021, at 5:21 PM, RVP wrote: > > On Sat, 27 Mar 2021, Hauke Fath wrote: > >> [...] >> Reading symbols from /bin/tar... >> Reading symbols from /usr/libdata/debug//bin/tar.debug... >> [New process 10317] >> Core was generated by `tar'. >> Program terminated with signal SIGSEGV, Segmentation fault. >> #0 0x7f0a03467866 in _citrus_iconv_convert >> (nresults=0x7f7fff902d18, flags=0, outbytes=0x7f7fff902d98, >> out=0x7f7fff902d90, >> inbytes=0x7f7fff902d88, in=0x7f7fff902d80, cv=0x7f0a057c40e0) at >> /usr/src/lib/libc/citrus/citrus_iconv.h:61 >> 61 _DIAGASSERT(cv && cv->cv_shared && cv->cv_shared->ci_ops && >> (gdb) bt >> #0 0x7f0a03467866 in _citrus_iconv_convert >> (nresults=0x7f7fff902d18, flags=0, outbytes=0x7f7fff902d98, >> out=0x7f7fff902d90, >> inbytes=0x7f7fff902d88, in=0x7f7fff902d80, cv=0x7f0a057c40e0) at >> /usr/src/lib/libc/citrus/citrus_iconv.h:61 >> #1 _iconv (handle=handle@entry=0x7f0a057c40e0, >> in=in@entry=0x7f7fff902d80, szin=szin@entry=0x7f7fff902d88, >> out=out@entry=0x7f7fff902d90, >> szout=szout@entry=0x7f7fff902d98) at >> /usr/src/lib/libc/iconv/iconv.c:97 >> > > This iconv() trace is very misleading. The bug triggered by the > NFS server returning 0 for .f_namemax in a statvfs() call. > > Fix: > ---START--- > diff -urN a/libarchive/dist/libarchive/archive_read_disk_posix.c > b/libarchive/dist/libarchive/archive_read_disk_posix.c > --- a/libarchive/dist/libarchive/archive_read_disk_posix.c2019-07-24 > 13:50:23.0 + > +++ b/libarchive/dist/libarchive/archive_read_disk_posix.c2021-03-31 > 12:01:37.437510048 + > @@ -1713,7 +1713,7 @@ > t->current_filesystem->noatime = 0; > > /* Set maximum filename length. */ > - t->current_filesystem->name_max = sfs.f_namemax; > + t->current_filesystem->name_max = (sfs.f_namemax == 0) ? NAME_MAX : > sfs.f_namemax; > return (ARCHIVE_OK); > } > > ---END--- > > Isn't the NFS server supposed to return NFS_MAXNAMLEN? > > -RVP signature.asc Description: Message signed with OpenPGP
Re: -current tar(1) breakage
I didn't expect output, but I wanted to look at the pointer data. Does it contain 0xa5 now instead of other random strings? christos > On Mar 27, 2021, at 6:06 PM, Hauke Fath > wrote: > > On Sat, 27 Mar 2021 17:04:58 -0400, Christos Zoulas wrote: >> Maybe we are accessing freed memory? Can you run it with: >> >> env MALLOC_CONF='junk:true' > > No output: > > [hauke@i386-pxe] /<6>xemacs-21.4.24/lisp > env MALLOC_CONF='junk:true' > tar -cf /dev/null . > Segmentation fault (core dumped) > [hauke@i386-pxe] /<6>xemacs-21.4.24/lisp > > > -- > Hauke Fath > Linnéweg 7 > 64342 Seeheim-Jugenheim > Germany signature.asc Description: Message signed with OpenPGP
Re: -current tar(1) breakage
Maybe we are accessing freed memory? Can you run it with:
env MALLOC_CONF='junk:true'
christos
> On Mar 27, 2021, at 1:51 PM, Anders Magnusson wrote:
>
>
>> (gdb) print *cv
>> $1 = {cv_shared = 0x6c652e73, cv_closure = 0x761713184050}
>> (gdb) print *cv->shared
>> There is no member named shared.
>> (gdb) print *cv->cv_shared
>> Cannot access memory at address 0x6c652e73
>> (gdb) print *cv->cv_shared->ci_ops
>> Cannot access memory at address 0x6c652e73
>> (gdb)
>
> 0x6c652e73 == "s.el" (ascii) so it sounds like something
> uninitialized/overwritten.
>
> -- R
signature.asc
Description: Message signed with OpenPGP
Re: -current tar(1) breakage
Joerg thinks that this is an nfs issue (a bug with nfs giving incorrect data). Nevertheless can you print *cv, print *cv->shared print *cv->shared->ci_ops Thanks, christos > On Mar 27, 2021, at 12:12 PM, Hauke Fath > wrote: > > On Sat, 27 Mar 2021 09:22:16 -0400, Christos Zoulas wrote: >> Can't you just download the pre-build ones? Assuming you are using >> reproducible builds, we might get lucky? > > [...] > Reading symbols from /bin/tar... > Reading symbols from /usr/libdata/debug//bin/tar.debug... > [New process 10317] > Core was generated by `tar'. > Program terminated with signal SIGSEGV, Segmentation fault. > #0 0x7f0a03467866 in _citrus_iconv_convert > (nresults=0x7f7fff902d18, flags=0, outbytes=0x7f7fff902d98, > out=0x7f7fff902d90, >inbytes=0x7f7fff902d88, in=0x7f7fff902d80, cv=0x7f0a057c40e0) at > /usr/src/lib/libc/citrus/citrus_iconv.h:61 > 61_DIAGASSERT(cv && cv->cv_shared && cv->cv_shared->ci_ops && > (gdb) bt > #0 0x7f0a03467866 in _citrus_iconv_convert > (nresults=0x7f7fff902d18, flags=0, outbytes=0x7f7fff902d98, > out=0x7f7fff902d90, >inbytes=0x7f7fff902d88, in=0x7f7fff902d80, cv=0x7f0a057c40e0) at > /usr/src/lib/libc/citrus/citrus_iconv.h:61 > #1 _iconv (handle=handle@entry=0x7f0a057c40e0, > in=in@entry=0x7f7fff902d80, szin=szin@entry=0x7f7fff902d88, > out=out@entry=0x7f7fff902d90, >szout=szout@entry=0x7f7fff902d98) at > /usr/src/lib/libc/iconv/iconv.c:97 > #2 0x7f0a05483834 in iconv_strncat_in_locale (as=0x7f0a05762158, > _p=, length=, sc=0x7f0a056eb000) >at > /usr/src/external/bsd/libarchive/dist/libarchive/archive_string.c:2039 > #3 0x7f0a054844ba in archive_strncat_l > (as=as@entry=0x7f0a05762158, _p=, n=, > sc=) >at > /usr/src/external/bsd/libarchive/dist/libarchive/archive_string.c:1998 > #4 0x7f0a0548459a in archive_strncpy_l > (as=as@entry=0x7f0a05762158, _p=, n=, > sc=) >at > /usr/src/external/bsd/libarchive/dist/libarchive/archive_string.c:1944 > #5 0x7f0a054847d9 in archive_mstring_get_mbs_l > (aes=0x7f0a05762110, p=0x7f7fff902eb8, length=0x7f7fff902ee8, > sc=) >at > /usr/src/external/bsd/libarchive/dist/libarchive/archive_string.c:4005 > #6 0x7f0a0547b810 in _archive_entry_pathname_l (entry= out>, p=, len=, sc=) >at > /usr/src/external/bsd/libarchive/dist/libarchive/archive_entry.c:598 > #7 0x7f0a0541f051 in get_entry_pathname (a=0x7f0a057b6000, > entry=, name=, length=, >sc=) at > /usr/src/external/bsd/libarchive/dist/libarchive/archive_write_set_format_pax.c:428 > #8 0x7f0a0541f5da in archive_write_pax_header (a=0x7f0a057b6000, > entry_original=0x7f0a05761500) >at > /usr/src/external/bsd/libarchive/dist/libarchive/archive_write_set_format_pax.c:839 > #9 0x7f0a0546a1da in _archive_write_header (_a=0x7f0a057b6000, > entry=0x7f0a05761500) >at > /usr/src/external/bsd/libarchive/dist/libarchive/archive_write.c:650 > #10 0x7b008ac2 in write_entry > (bsdtar=bsdtar@entry=0x7f7fff9037f0, a=a@entry=0x7f0a057b6000, > entry=0x7f0a05761500) >at /usr/src/external/bsd/libarchive/dist/tar/write.c:974 > #11 0x7b008cac in write_file (entry=, > a=0x7f0a057b6000, bsdtar=0x7f7fff9037f0) >at /usr/src/external/bsd/libarchive/dist/tar/write.c:962 > #12 write_hierarchy (bsdtar=bsdtar@entry=0x7f7fff9037f0, > a=a@entry=0x7f0a057b6000, path=path@entry=0x7f7fff9042f2 ".") >at /usr/src/external/bsd/libarchive/dist/tar/write.c:941 > #13 0x7b00907e in write_archive (a=a@entry=0x7f0a057b6000, > bsdtar=bsdtar@entry=0x7f7fff9037f0) >at /usr/src/external/bsd/libarchive/dist/tar/write.c:513 > #14 0x7b0098a4 in tar_mode_c > (bsdtar=bsdtar@entry=0x7f7fff9037f0) at > /usr/src/external/bsd/libarchive/dist/tar/write.c:247 > #15 0x7b00ba4d in main (argc=, argv= out>) at /usr/src/external/bsd/libarchive/dist/tar/bsdtar.c:910 > (gdb) > > HTH, > Hauke > > -- > Hauke Fath > Linnéweg 7 > 64342 Seeheim-Jugenheim > Germany signature.asc Description: Message signed with OpenPGP
Re: -current tar(1) breakage
Can't you just download the pre-build ones? Assuming you are using reproducible builds, we might get lucky? christos > On Mar 27, 2021, at 9:09 AM, Hauke Fath > wrote: > > On Fri, 26 Mar 2021 20:08:40 +0100, Hauke Fath wrote: >> On Fri, 26 Mar 2021 14:41:56 -0400, Christos Zoulas wrote: >>> Can you install the debug sets? >> >> Will do - have to build them first, though. > > Sorry, the build died. It wants more than 20 GB for objects, which I > currently don't have on that machine... > > Cheerio, > Hauke > > -- > Hauke Fath > Linnéweg 7 > 64342 Seeheim-Jugenheim > Germany signature.asc Description: Message signed with OpenPGP
Re: -current tar(1) breakage
On Mar 26, 6:52pm, ha...@espresso.rhein-neckar.de (Hauke Fath) wrote: -- Subject: Re: -current tar(1) breakage | On Fri, 26 Mar 2021 16:28:38 - (UTC), Christos Zoulas wrote: | > What does the core file show? | | Reading symbols from /usr/bin/tar... | (No debugging symbols found in /usr/bin/tar) | [New process 29527] | Core was generated by `tar'. | Program terminated with signal SIGSEGV, Segmentation fault. | #0 0x74e0e8667866 in iconv () from /lib/libc.so.12 | (gdb) bt | #0 0x74e0e8667866 in iconv () from /lib/libc.so.12 | #1 0x74e0ea683834 in ?? () from /usr/lib/libarchive.so.4 | #2 0x74e0ea6844ba in archive_strncat_l () from=20 | /usr/lib/libarchive.so.4 | #3 0x74e0ea6847d9 in archive_mstring_get_mbs_l () from=20 | /usr/lib/libarchive.so.4 | #4 0x74e0ea61f051 in ?? () from /usr/lib/libarchive.so.4 | #5 0x74e0ea61f5da in ?? () from /usr/lib/libarchive.so.4 | #6 0x74e0ea66a1da in ?? () from /usr/lib/libarchive.so.4 | #7 0x000155a08ac2 in write_entry () | #8 0x000155a08cac in write_hierarchy () | #9 0x000155a0907e in write_archive () | #10 0x000155a098a4 in tar_mode_c () | #11 0x000155a0ba4d in main () | (gdb) Can you install the debug sets? | Also, from a 'ktrace -di': | | [...] | 29527 29527 tar CALL __acl_get_fd(7,4,0x74e0ea5dc000) | 29527 29527 tar RET __acl_get_fd -1 errno 45 Operation not=20 | supported | 29527 29527 tar CALL =20 | mmap(0,0x5000,PROT_READ|PROT_WRITE,0x1002,0= | x,0,0) | 29527 29527 tar RET mmap 128509353488384/0x74e0ea5d7000 | 29527 29527 tar CALL munmap(0x74e0ea5d7000,0x5000) | 29527 29527 tar RET munmap 0 | 29527 29527 tar CALL =20 | mmap(0,0x6000,PROT_READ|PROT_WRITE,0xd001002= | ,0x,0,0) | 29527 29527 tar RET mmap 128509353484288/0x74e0ea5d6000 | 29527 29527 tar CALL munmap(0x74e0ea5db000,0x1000) | 29527 29527 tar RET munmap 0 | 29527 29527 tar CALL __acl_get_fd(7,2,0x74e0ea5d6000) | 29527 29527 tar RET __acl_get_fd -1 errno 45 Operation not=20 | supported | 29527 29527 tar CALL extattr_list_fd(7,1,0,0) | 29527 29527 tar RET extattr_list_fd -1 errno 45 Operation not=20 | supported | 29527 29527 tar CALL close(7) | 29527 29527 tar RET close 0 | 29527 29527 tar CALL fchdir(3) | 29527 29527 tar RET fchdir 0 | 29527 29527 tar PSIG SIGSEGV SIG_DFL: code=3DSEGV_MAPERR,=20 | addr=3D0x68, trap=3D6) | 29527 29527 tar NAMI "tar.core" I was hoping that this would show the filename but it does not. Thanks, christos
Re: sys.mk broken for single-suffix rules since 1.144 (2021/11/09)
In article ,
Greg A. Woods wrote:
>-=-=-=-=-=-
>
>I just noticed that on my recently upgraded -current machines that I
>couldn't build simple programs from single source files with a
>"portable" Makefile any more.
>
>Instead the program binaries were being put into foo.o files!
>
>It looks like rev. 1.144 of sys.mk was a bit too over-zealous.
>
>I'll send this as a PR also, but perhaps those running -current on
>development machines might need a more urgent fix.
>
>Here are my patches that include the fix, and also clean up the use of
>various flags in LINK.* (remove CPPFLAGS and add LDSTATIC) and introduce
>COMPILE_LINK.* macros to be used with the direct source to target binary
>rules (single-suffix rules) such as ".c:" (and finally also split the
>settings for debugger and optimizer flags).
>
>The key parts are to revert the change to use ${OBJECT_TARGET} in the
>single-suffix rules like ".c:" since ctfconvert(1) won't work on
>(static?) linked binaries, and because of course we still need the
>final output file to be the filename _without_ any suffix!
Thanks, I fixed the shuttle-rule issue, but let's split the LDSTATIC
and the OPTIM into separate commits. DBG has side effects too (other
Makefiles set it) so it should be done very carefully.
christos
Re: net/net-snmp configure failure under -current
In article , Chavdar Ivanov wrote: >Hi, > >This package fails configure as recent libwrap.so refers to libblocklist: >... >configure:25104: result: no >configure:25117: checking for TCP wrappers library -lwrap linked with -lnsl >configure:25133: gcc -o conftest -DNETSNMP_ENABLE_IPV6 >-fno-strict-aliasing -DNETSNMP_REMOVE_U64 -O2 -Dnetbsd1 >-DSOL_IP=IPPROTO_IP -I/usr/include -I/usr/pkg/include >-D_XOPEN_SOURCE_EXTENDED=1 -I/usr/pkg/include/ncurses -Unetbsd >-Dnetbsd=netbsd -I/usr/include -I/usr/pkg/include >-D_XOPEN_SOURCE_EXTENDED=1 -I/usr/pkg/include/ncurses >-I/usr/lib/include -L/usr/lib -Wl,-R/usr/lib -L/usr/pkg/lib >-Wl,-R/usr/pkg/lib/perl5/5.32.0/x86_64-netbsd-thread-multi/CORE >-Wl,-R/usr/pkg/lib -L/usr/lib/lib conftest.c -lelf -ldes -lm -lwrap >>&5 >ld: /usr/lib/libwrap.so: undefined reference to `blocklist_sa_r' >ld: /usr/lib/libwrap.so: undefined reference to `blocklist_open' >ld: /usr/lib/libwrap.so: undefined reference to `blocklist_r' >configure:25133: $? = 1 >configure: failed program was/ > >... > >Adding > >LDFLAGS+= -lblocklist > >to the Makefile allows the build to complete, but surely this is not >the right and proper thing to do, as it should be conditional to the >OS version I guess. Yes, the right fix is to record the dependency at the shared library level. I left it commented out, but now I will uncomment it. christos
Re: sed and xentools413
We could do it this way -G (enable GNU), or have it on by default and add (-P disable gnu/posix mode). christos > On Mar 8, 2021, at 10:36 AM, Martin Husemann wrote: > > On Mon, Mar 08, 2021 at 03:29:32PM -, Christos Zoulas wrote: >> Yes, we can turn on REG_GNU in regcomp in sed to support \s so that it >> behaves >> like gnused. Before it was silently ignoring the backslash. > > Is this worth a sed command line switch (like -E) ? > > Martin signature.asc Description: Message signed with OpenPGP
Re: sed and xentools413
In article <20210308152211.os2woq5ipxfpt...@yt.nih.at>, Thomas Klausner wrote: >On Mon, Mar 08, 2021 at 03:13:48PM +, Patrick Welche wrote: >> I'm assuming a WORKSFORME response for xentools413, so wondering >> whether something changed in -current sed that would explain the >> above. > >Haven't tried it yet, but perhaps this changed the sed behavior as well: > >Module Name:src >Committed By: christos >Date: Tue Feb 23 22:14:59 UTC 2021 > >Modified Files: >src/lib/libc/regex: cname.h engine.c re_format.7 regcomp.c regerror.c >regex.3 regex2.h regexec.c regfree.c utils.h >Removed Files: >src/lib/libc/regex: cclass.h > >Log Message: >sync with FreeBSD: >- NLS support >- GNU extensions >- bug fixes Yes, we can turn on REG_GNU in regcomp in sed to support \s so that it behaves like gnused. Before it was silently ignoring the backslash. christos
Re: xhci driver crashes FreeBSD bhyve hypervisor
In article , Darrin B. Jewell wrote: > >As I recently reported in this forum, I have obtained a FreeBSD based >NAS system from https://www.truenas.com/truenas-mini/ > >This system provides the bhyve hypervisor for running virtual >machines and I recently attempted to boot NetBSD 9.1 on it. >Unfortunately, the xhci driver appears to crash the hypervisor. > > pid 6925 (bhyve), jid 0, uid 0: exited on signal 11 > >I've included the virtual netbsd system console below >when I booted the NetBSD-9.1-amd64.iso cdrom image from the >default distribution. > >Recompiling and removing the xhci driver avoids this crash >and allows NetBSD to function in this environment. > >I'll report here any further details if I get the time to >debug this crash. A segv on the hypervisor is the hypervisor's fault. I would report it to them. christos
Re: Help with libcurses and lynx under NetBSD-9 and -current?
As Roy wrote TERMINFO_COMPILE is defined by default so it should parse $TERMCAP by default. If that does not work properly, it is either an issue with the termcap->terming translation, or with the termcap entry. christos > On Jan 27, 2021, at 4:21 PM, RVP wrote: > > On Wed, 27 Jan 2021, Christos Zoulas wrote: > >> I think we can make our libterminfo do the same by shuffling a few ifdefs >> around :-) >> > > Is that how libterminfo is going to be built from on (with $TERMCAP > support restored)? > > -RVP signature.asc Description: Message signed with OpenPGP
Re: Help with libcurses and lynx under NetBSD-9 and -current?
In article ,
RVP wrote:
>This might be due to the fact that window(1) relies on setting a
>custom TERMCAP environment variable to inform programs running
>under it of the term. capabilities it supports, and the curses
>library no longer makes use of that.
>
>With ncurses, building it with the `--enable-termcap' option
>makes it use the TERMCAP variable if it set in the environment.
>
>The ncurses(w) in pkgsrc is not built with that option, so, I
>compiled the latest ncurses from source with that option added
>and lynx -show_cursor worked just fine under window(1).
>
>-RVP
I think we can make our libterminfo do the same by shuffling a few ifdefs
around :-)
christos
Index: term.c
===
RCS file: /cvsroot/src/lib/libterminfo/term.c,v
retrieving revision 1.34
diff -u -u -r1.34 term.c
--- term.c 5 Apr 2020 14:53:39 - 1.34
+++ term.c 27 Jan 2021 17:51:27 -
@@ -368,7 +368,6 @@
return _ti_dbgetterm(term, e, name, flags);
c = NULL;
-#ifdef TERMINFO_COMPILE
if (e == NULL && (c = getenv("TERMCAP")) != NULL) {
if (*c != '\0' && *c != '/') {
c = strdup(c);
@@ -379,6 +378,10 @@
}
}
+#ifndef TERMINFO_COMPILE
+ if (e != NULL && *e == '/')
+ return _ti_dbgetterm(term, e, name, flags);
+#else
if (e != NULL) {
TIC *tic;
Re: undefined references to strlist_match
In article <87o8hdfkfp@brownie.elements.tetera.org>,
Ryo ONODERA wrote:
>Hi,
>
>When my laptop builds NetBSD/amd64-current on NetBSD/amd64-current,
>I get the following error.
>My DTRACE7 kernel is almost as same as GENERIC, except no options DIAGNOSTIC.
>
>x.o ieee8023ad_lacp_sm_ptx.o ieee8023ad_lacp_sm_tx.o
>ieee8023ad_lacp_debug.o ieee8023_tlv.o devsw.o ioconf.o
>/usr/world/9.99/amd64/obj/sys/arch/amd64/compile/DTRACE7/lib/kern/libkern.o
>vers.o swapnetbsd.o
># link DTRACE7/netbsd
>/usr/world/9.99/amd64/tools/bin/x86_64--netbsd-ld -Map netbsd.map --cref
>-T netbsd.ldscript -Ttext 0x8020 -e start -z
>max-page-size=0x20 -X -o netbsd ${SYSTEM_OBJ:[@]:Nswapnetbsd.o}
>${EXTRA_OBJ} vers.o swapnetbsd.o
>/usr/world/9.99/amd64/tools/bin/x86_64--netbsd-ld: subr_autoconf.o: in
>function `device_compatible_match_strlist_internal':
>/usr/src/sys/kern/subr_autoconf.c:2458: undefined reference to `strlist_match'
>/usr/world/9.99/amd64/tools/bin/x86_64--netbsd-ld:
>/usr/src/sys/kern/subr_autoconf.c:2458: undefined reference to
>`strlist_pmatch'
>/usr/world/9.99/amd64/tools/bin/x86_64--netbsd-ld:
>/usr/src/sys/kern/subr_autoconf.c:2458: undefined reference to
>`strlist_match'
>/usr/world/9.99/amd64/tools/bin/x86_64--netbsd-ld:
>/usr/src/sys/kern/subr_autoconf.c:2458: undefined reference to
>`strlist_pmatch'
>*** [netbsd] Error code 1
>
>nbmake[1]: stopped in /usr/world/9.99/amd64/obj/sys/arch/amd64/compile/DTRACE7
>1 error
>
>nbmake[1]: stopped in /usr/world/9.99/amd64/obj/sys/arch/amd64/compile/DTRACE7
>
>ERROR: Failed to make all in
>"/usr/world/9.99/amd64/obj/sys/arch/amd64/compile/DTRACE7"
>*** BUILD ABORTED ***
>*** Error code 1
>
>Stop.
>make: stopped in /usr/src
>
>
>I think strlist.c is not included in libkern.o.
>The following patch works for my environment.
>
>Index: sys/lib/libkern/Makefile.libkern
>===
>RCS file: /cvsroot/src/sys/lib/libkern/Makefile.libkern,v
>retrieving revision 1.49
>diff -u -r1.49 Makefile.libkern
>--- sys/lib/libkern/Makefile.libkern 30 Jun 2020 16:20:02 - 1.49
>+++ sys/lib/libkern/Makefile.libkern 25 Jan 2021 03:26:24 -
>@@ -87,6 +87,8 @@
> SRCS+=strncat.c strncmp.c strncpy.c strpbrk.c strspn.c
> SRCS+=strcasecmp.c strncasecmp.c
>
>+SRCS+=strlist.c
>+
> SRCS+=xlat_mbr_fstype.c
>
> SRCS+=heapsort.c ptree.c radixtree.c rb.c rpst.c
>
>
>Does anyone have the same issue?
Yes, and this is how I fixed it :-)
christos
Re: crash in amd64 -current
In article , Paul Goyette wrote: >With sources updated a few hours ago (2021-01-21 at 17:17:48 UTC) I am >getting the following crash as soon as it tries to start syslogd: > > breakpoint() at breakpoint+0x5 > vpanic() at vpanic+0x156 > snprintf() at snprintf > kqueue_check() at kqueue_check+0x183 > kevent1() at kevent1+0x49f > sys___kevent50() at sys___kevent50+0x33 > syscall() at syscall+0x23e > --- syscall (number 435) --- > syscall+0x23e: > >Also, why the heck does savecore(8) complain when I use the -N option? > > # savecore -fN /netbsd.bad.gdb > savecore: dumpdev /dev/console is tty; override kernel Seems that the dump device it finds by reading the kernel namelist from /netbsd.bad.gdb ends up being /dev/console... Is the machine you are running gdb the same as the machine that produced the dump? because the dev_t it read from the kernel namelist matched the dev_t for the console on the local machine in /dev. christos
Re: Automated report: NetBSD-current/i386 build success
Fixed, thanks! christos > On Dec 6, 2020, at 8:02 AM, Andreas Gustafsson wrote: > > The NetBSD Test Fixture wrote: >> The NetBSD-current/i386 build is working again. > > It is, but the amd64 build is failing with: > > === 1 extra files in DESTDIR = > Files in DESTDIR but missing from flist. > File is obsolete or flist is out of date ? > -- > ./usr/bin/gdbserver > = end of 1 extra files === > > -- > Andreas Gustafsson, g...@gson.org signature.asc Description: Message signed with OpenPGP
Re: acpi panic on Dell Optiplex 760 (i82Q45 chip set)
In article ,
John D. Baker wrote:
>After updating to the latest -current (9.99.76) with the recent ACPI
>subsystem update, my Dell Optiplex 760 panics attaching acpi0:
Something is overwriting allocated memory. Can you find which free does
this?
Cleanup:
if (Hid)
{
ACPI_FREE (Hid);
}
if (Uid)
{
ACPI_FREE (Uid);
}
if (CidList)
{
ACPI_FREE (CidList);
}
if (Cls)
{
ACPI_FREE (Cls);
}
If you have netbsd.gdb and the crash file it should be simple...
christos
Re: MAKEDEV ptm devices and /dev/pts
In article <73bb3f04-c271-422d-ace2-10aab3bf9...@nmsu.edu>, Brook Milligan wrote: >I notice what appears to be an incompatibility under some circumstances >between fstab and MAKEDEV. > >- /etc/fstab has an entry for the mount point /dev/pts > >- /dev/pts is not created as part of system installation (unlike >/dev/altq and /dev/fd, which are empty directories) > >- /dev/pts is instead created by MAKEDEV when ptm devices are created, >which is part of all) but not init) > >This means that /dev created by init on a memory filesystem will not >contain /dev/pty (or the ptm* devices). > >There are at least several solutions to this: > >- create an empty /dev/pts directory during installation as is done for >/dev/altq and /dev/fd. > >- teach init) to also create the ptm devices > >- remove the ptyfs entry from /etc/fstab > >- ... ? > >The first option seems simplest, but if the ptm* devices should always >be available and ptyfs is supposed to work in all cases, then the second >option is required. > >What is the best way forward? Martin just fixed it. christos
Re: Using wg(4) with a commerical VPN provider
In article <3b48572b-2b4e-40fa-98bf-403729c2e...@me.com>,
Jason Thorpe wrote:
>
>> On Nov 10, 2020, at 5:49 PM, Brad Spencer wrote:
>>
>> --- sys/net/if_wg.c.DIST 2020-10-26 10:36:30.391354264 -0400
>> +++ sys/net/if_wg.c 2020-10-30 19:13:46.910323221 -0400
>> @@ -98,8 +98,8 @@
>> #include
>> #include
>>
>> -#ifdef INET6
>> #include
>> +#ifdef INET6
>> #include
>> #include
>> #include
>> @@ -1611,7 +1611,16 @@
>> wg_get_so_by_af(struct wg_softc *wg, const int af)
>> {
>>
>> +#if defined(INET) && defined(INET6)
>> return (af == AF_INET) ? wg->wg_so4 : wg->wg_so6;
>> +#else
>> +#ifdef INET
>> +return wg->wg_so4;
>> +#endif
>> +#ifdef INET6
>> +return wg->wg_so6;
>> +#endif
>> +#endif
>> }
>
>Seems ... not great to put #ifdefs like this in something that can be
>build as a module?
Module builds handle this by turning on all options during the build...
christos
Re: sponsor NetBSD for 2020 https://github.com/sponsors/NetBSD
In article , Jeffrey Walton wrote: >On Tue, Nov 10, 2020 at 11:53 AM Jason Thorpe wrote: >> >> > On Nov 10, 2020, at 6:18 AM, Jeffrey Walton wrote: >> > >> > NetBSD should consider Amazon, too. They have a program for donations >> > to nonprofits. Amazon is a big marketplace with lots of users. The >> > trust relationship is already in place for millions of potential >> > donors. >> >> Yah, that's Amazon Smile, and NetBSD is already on it. > >Oh, interesting. I've looked for NetBSD swag but I have not been able >to find it. Confer, https://www.amazon.com/s?k=netbsd. > >The search results provide a lot of books. On page 7 of the results >there are a couple of FreeBSD and OpenBSD stickers. There's also a >cool looking UNIX coffe mug. But nothing from NetBSD. > >Where's the cool swag :) https://www.netbsd.org/gallery/devotionalia.html christos
Re: Build failure for ``no options PTRACE''
In article <293ee35a-90b6-fe89-42ca-9adfbc9db...@netbsd.org>, Kamil Rytarowski wrote: >-=-=-=-=-=- >-=-=-=-=-=- > >On 18.10.2020 15:00, Paul Goyette wrote: >> >> I'm getting lost inside all this elf stuff :) > >ptrace is not really pluggable and the maintenance burden to have part >of it as loadable modules questions the usefulness of this. > >My request to demodularize it stands. A lot of the kernel is difficult to modularize, because it was not designed this way. I think that there is value in modularization because it reveals the dependencies between subsystems (global variables and functions). Even if we decide to de-modularize ptrace, we should understand what prevents us from modularizing things and design ways to make things more plugin oriented. Yes, I agree that we should not make ifdef's hell or add complexity which will end up in more bugs and fragility, but if we don't try, we will not know. christos
Re: Build failure for ``no options PTRACE''
In article ,
Paul Goyette wrote:
>For a custom kernel build with ``no options PTRACE'' and ``no options
>COREDUMP'' defined, and sources updated on 2020-10-16 at 13:18:24 UTC,
>I get the following linker error:
>
># link SPEEDY/netbsd
>/build/netbsd-local/tools/x86_64/amd64/bin/x86_64--netbsd-ld -Map
>netbsd.map --cref -T netbsd.ldscript -Ttext 0x8020 -e start
>-z max-page-size=0x20 -X -o netbsd ${SYSTEM_OBJ:[@]:Nswapnetbsd.o}
>${EXTRA_OBJ} vers.o swapnetbsd.o
>/build/netbsd-local/tools/x86_64/amd64/bin/x86_64--netbsd-ld:
>process_machdep.o: in function `ptrace_machdep_dorequest':
>/build/netbsd-local/src/sys/arch/amd64/amd64/process_machdep.c:329:
>undefined reference to `ptrace_update_lwp'
>/build/netbsd-local/tools/x86_64/amd64/bin/x86_64--netbsd-ld:
>/build/netbsd-local/src/sys/arch/amd64/amd64/process_machdep.c:372:
>undefined reference to `ptrace_update_lwp'
>*** [netbsd] Error code 1
>
>nbmake: stopped in /build/netbsd-local/obj/amd64/sys/arch/amd64/compile/SPEEDY
>1 error
>
>nbmake: stopped in /build/netbsd-local/obj/amd64/sys/arch/amd64/compile/SPEEDY
>
>ERROR: Failed to make all in
>"/build/netbsd-local/obj/amd64/sys/arch/amd64/compile/SPEEDY"
>*** BUILD ABORTED ***
process_machdep.c provides 2 functions:
The read+write regs functions: used by ptrace and coredump
The machdep ptrace function: handling used only by ptrace
These dependencies are not reflected correctly in the patch below.
Perhaps we want a regs module by splitting and then coredump
and ptrace depends on that.
This patch puts process_machdep.c in the ptrace module, and
moves all the coredump functions in the coredump module. I have
only compile-tested this.
christos
Index: arch/amd64/amd64/process_machdep.c
===
RCS file: /cvsroot/src/sys/arch/amd64/amd64/process_machdep.c,v
retrieving revision 1.48
diff -u -u -r1.48 process_machdep.c
--- arch/amd64/amd64/process_machdep.c 15 Oct 2020 17:37:35 - 1.48
+++ arch/amd64/amd64/process_machdep.c 17 Oct 2020 13:19:59 -
@@ -76,7 +76,9 @@
#include
__KERNEL_RCSID(0, "$NetBSD: process_machdep.c,v 1.48 2020/10/15 17:37:35
mgorny Exp $");
+#ifdef _KERNEL_OPT
#include "opt_xen.h"
+#endif
#include
#include
#include
Index: arch/amd64/conf/MODULAR
===
RCS file: /cvsroot/src/sys/arch/amd64/conf/MODULAR,v
retrieving revision 1.17
diff -u -u -r1.17 MODULAR
--- arch/amd64/conf/MODULAR 27 Sep 2020 13:48:49 - 1.17
+++ arch/amd64/conf/MODULAR 17 Oct 2020 13:19:59 -
@@ -4,8 +4,6 @@
# XXX: incomplete
include "arch/amd64/conf/GENERIC"
-optionsMODULAR # new style module(7) framework
-optionsMODULAR_DEFAULT_AUTOLOAD
-no acpicpu* at cpu?
-no est0 at cpu0
@@ -85,6 +83,9 @@
-no optionsAIO
+-no optionsPTRACE
+-no optionsCOREDUMP
+
-no acpiacad* at acpi?# ACPI AC Adapter
-no acpibat* at acpi?# ACPI Battery
-no acpibut* at acpi?# ACPI Button
Index: arch/amd64/conf/files.amd64
===
RCS file: /cvsroot/src/sys/arch/amd64/conf/files.amd64,v
retrieving revision 1.117
diff -u -u -r1.117 files.amd64
--- arch/amd64/conf/files.amd64 15 Oct 2020 17:40:13 - 1.117
+++ arch/amd64/conf/files.amd64 17 Oct 2020 13:19:59 -
@@ -47,7 +47,7 @@
file arch/amd64/amd64/gdt.c machdep
file arch/amd64/amd64/machdep.c machdep
file arch/amd64/amd64/prekern.c kaslr
-file arch/amd64/amd64/process_machdep.c machdep
+file arch/amd64/amd64/process_machdep.c machdep & ptrace
file arch/amd64/amd64/trap.c machdep
file arch/x86/x86/fpu.c machdep
file arch/x86/x86/dbregs.c machdep
Index: kern/compat_stub.c
===
RCS file: /cvsroot/src/sys/kern/compat_stub.c,v
retrieving revision 1.19
diff -u -u -r1.19 compat_stub.c
--- kern/compat_stub.c 20 Nov 2019 19:37:53 - 1.19
+++ kern/compat_stub.c 17 Oct 2020 13:20:00 -
@@ -280,6 +280,8 @@
struct coredump_offset_hook_t coredump_offset_hook;
struct coredump_write_hook_t coredump_write_hook;
struct coredump_netbsd_hook_t coredump_netbsd_hook;
+struct coredump_elf32_hook_t coredump_elf32_hook;
+struct coredump_elf64_hook_t coredump_elf64_hook;
struct uvm_coredump_walkmap_hook_t uvm_coredump_walkmap_hook;
struct uvm_coredump_count_segs_hook_t uvm_coredump_count_segs_hook;
Index: kern/core_elf32.c
===
RCS file: /cvsroot/src/sys/kern/core_elf32.c,v
retrieving revision 1.65
diff -u -u -r1.65 core_elf32.c
--- kern/core_elf32.c 10 Oct 2020 00:10:06 - 1.65
+++ kern/core_elf32.c 17 Oct 2020 13:20:00 -
@@ -109,7 +109,7 @@
#define elf_fpreg
Re: gdb - undefined reference to `std::__1::codecvt::id'
In article , Kamil Rytarowski wrote: >-=-=-=-=-=- >-=-=-=-=-=- > >On 29.09.2020 16:09, Roy Marples wrote: >> #     link gdb/gdb >> /usr/tools/bin/x86_64--netbsd-clang++   --sysroot=/ >> -Wl,--warn-shared-textrel -Wl,-z,relro  -pie     -o gdb gdb.o >> -Wl,-rpath-link,/lib -L=/lib >> -L/home/roy/src/hg/src/external/gpl3/gdb/lib/libgdb/obj.amd64 -lgdb >> -L/home/roy/src/hg/src/external/gpl3/gdb/lib/libopcodes/obj.amd64 >> -lopcodes -L/home/roy/src/hg/src/external/gpl3/gdb/lib/libbfd/obj.amd64 >> -lbfd >> -L/home/roy/src/hg/src/external/gpl3/gdb/lib/libdecnumber/obj.amd64 >> -ldecnumber >> -L/home/roy/src/hg/src/external/gpl3/gdb/lib/libgdbsupport/obj.amd64 >> -lgdbsupport >> -L/home/roy/src/hg/src/external/gpl3/gdb/lib/libctf/obj.amd64 -lctf >> -L/home/roy/src/hg/src/external/gpl3/gdb/lib/libgnulib/obj.amd64 >> -lgnulib >>  -L/home/roy/src/hg/src/external/gpl3/gdb/lib/libreadline/obj.amd64 >> -lreadline -lterminfo >> -L/home/roy/src/hg/src/external/gpl3/gdb/lib/libiberty/obj.amd64 >> -liberty -lexpat -llzma -lz -lcurses -lintl -lm -lkvm -lutil >> /usr/tools/bin/x86_64--netbsd-ld: >> >/home/roy/src/hg/src/external/gpl3/gdb/lib/libgdb/obj.amd64/libgdb.a(string_view-selftests.o): >> in function `std::__1::basic_filebuf >>>::basic_filebuf()': >> >string_view-selftests.c:(.text._ZNSt3__113basic_filebufIcNS_11char_traitsIcEEEC2Ev[_ZNSt3__113basic_filebufIcNS_11char_traitsIcEEEC2Ev]+0x94): >> undefined reference to `std::__1::codecvt::id' >> /usr/tools/bin/x86_64--netbsd-ld: >> >string_view-selftests.c:(.text._ZNSt3__113basic_filebufIcNS_11char_traitsIcEEEC2Ev[_ZNSt3__113basic_filebufIcNS_11char_traitsIcEEEC2Ev]+0xc4): >> undefined reference to `std::__1::codecvt::id' >> /usr/tools/bin/x86_64--netbsd-ld: >> >/home/roy/src/hg/src/external/gpl3/gdb/lib/libgdb/obj.amd64/libgdb.a(string_view-selftests.o): >> in function `std::__1::basic_filebuf >>>::imbue(std::__1::locale const&)': >> >string_view-selftests.c:(.text._ZNSt3__113basic_filebufIcNS_11char_traitsIcEEE5imbueERKNS_6localeE[_ZNSt3__113basic_filebufIcNS_11char_traitsIcEEE5imbueERKNS_6localeE]+0x13): >> undefined reference to `std::__1::codecvt::id' >> x86_64--netbsd-clang: error: linker command failed with exit code 1 (use >> -v to see invocation) >> *** Error code 1 >> >> What went wrong? >> My very limited knowledge of C++ and google foo says codecvt should be >> part of libc++? >> >> Roy > >The basesystem libc++ is too old for C++ applications like GDB. > >A workaround is to force old GDB. Or use gcc instead of clang :-) christos
Re: Finding errors in build logs
In article <24432.50312.48649.508...@guava.gson.org>, Andreas Gustafsson wrote: >On June 21, Simon J. Gerraty wrote: >> > It would be helpful for both human and robotic users if error messages >> > consistently included the word "error", or if there was some other easy >> > way of identifying them in the build log. >> >> The regex 'make.*stopped' is the best clue to look for since it will >> always be present. > >It is not present in this recent log extract: > > >http://releng.netbsd.org/b5reports/i386/2020/2020.09.27.13.59.24/build.log.tail > >I also checked the full log, and it's not there, either. Yes, I have a log that does not contain it either. http://www.zoulas.com/~christos/NetBSD/make.amd64-x86_64.release.out It finishes with: --- obj-crypto/external --- ERROR: Failed to make release *** BUILD ABORTED *** I suggest that we revert the change that minimize the error messages in the parallel make until this is undestood. This is not the first time this happened to me. christos
Re: ctype and gcc9
In article <20200921083148.GA17688@quantz>, Patrick Welche wrote: >Since gcc9, essentially every ctype using piece of software fails with > > error: array subscript has type 'char' [-Werror=char-subscripts] > >which prompts a style question: cast every argument of every call to >a ctype function in every piece of software to (unsigned char), or >-Wno-error=char-subscripts], or something else? cast to unsigned char. The ctype functions have undefined behavior for negative values other than -1. The code is buggy. christos
Re: NetBSD bug/misbehavior in vdprintf
In article <20200829174525.ga25...@bec.de>, Joerg Sonnenberger wrote: > >It is, there is always some internal buffering for fprintf, so in >principle you can flush, ack the error, flush again etc. Indeed, https://pubs.opengroup.org/onlinepubs/9699919799/functions/fputc.html lists all the errors (unfortunately our man pages don't), and the first one, EAGAIN, implies that stdio should work with non-blocking file descriptors. Retrying after clearerr(3), should work. christos
Re: NetBSD bug/misbehavior in vdprintf
In article , Rob Newberry wrote: >(Also posting to tech-userlevel...) > > >NetBSD's implementation of vdprintf makes a special check -- if the >descriptor is in non-blocking mode, it needs to be a regular file (I >think I read that code correctly). But it apparently doesn't have this >check problem for vfprintf. I think it's been there a long time (since >the introduction of vdprintf), but it makes vdprintf behave differently >than vfprintf. In my view, "vfprintf( FILE, ...)" and "vdprintf( >fileno( FILE ), ... )" ought to behave the same -- but they don't (on >NetBSD) if "fileno( FILE )" has been marked non-blocking and it's not a >regular file. You are right, it should work and I removed the test. christos
Re: tunefs throws mount error
In article , Michael van Elst wrote: >ci4...@gmail.com (Chavdar Ivanov) writes: > >># tunefs -o time /dev/rdk5 >>tunefs: tuning /dev/rdk5 >>tunefs: optimization preference remains unchanged as time >>tunefs: mount of /dev/dk1 on / updated <== > >If the device is "mounted", tunefs triggers a mount -u to push >changes into the kernel. > >The check is done by calling fstatvfs(), and if successful the >update is done on f_mntonname. > >That's a recent change (2020-04-09) and at least the check is bogus >because fstatvfs() also succeeds when the device isn't mounted (and >returns the filesystem where /dev lives, usually the root filesystem). Should behave better now... christos
Re: [PATCH] net/samba4: relocate Sysvol to persist between reboots & move variable data out of /usr/pkg/etc/...
Done, thanks! christos > On Jul 27, 2020, at 8:49 PM, Matthias Petermann wrote: > > Hello everyone, > > with the introduction of FFS ACLs Samba can be used as windows domain > controller (DC). The DC needs a directory to persist its policies and scripts > - the so called Sysvol. > > The creation of the Sysvol typically takes place during the domain > provisioning with samba-tool. At the moment, the default Samba4 from pkgsrc > is configured to put Sysvol below /var/run/sysvol. Unfortunately, there is a > critical issue with this location: Everything inside /var/run gets purged as > part of the systems startup sequence. So this means losing all your policies, > ultimately a corruption of the domain controller state at the next reboot. > > Therefore, Sysvol needs to be relocated to a persistent place. > > I checked how this is implemented elsewhere: > > * On Linux systems Sysvol is typically located at /var/lib/samba/sysvol > * On FreeBSD the location is /var/db/samba4/sysvol > > As /var/lib is not mentioned in HIER(7) at all, I guess this is Linux > specific. Therefore I would propose the FreeBSD-way and put it below > /var/db/samba4/sysvol. In addition to that I think it would be a good idea to > relocate the variable Samba data (databases, caches) currently located at > /usr/pkg/etc/samba/private) as well. My proposal for the target is > /var/db/samba4/private. > > Attached is a patch which applies to pkgsrc-current. I did perform the usual > tests (removing all previous configuration and databases, provisioning a new > domain, joining a Windows client to the domain) - no issues so far. > > What do you think? > > Kind regards > Matthias > signature.asc Description: Message signed with OpenPGP
Re: Samba DC provisioning fails with ACL-enabled NetBSD-current
Be very careful and use a separate partition for sysvol because Matthias reported fs corruption which I have not looked at yet. christos > On Jul 23, 2020, at 7:39 PM, Chavdar Ivanov wrote: > > On Thu, 23 Jul 2020 at 16:25, Chavdar Ivanov <mailto:ci4...@gmail.com>> wrote: >> >> On Thu, 23 Jul 2020 at 15:59, Christos Zoulas wrote: >>> >>> You are missing: >>> >>> PKG_OPTIONS.samba4= acl >> >> Unfortunately not - this is the line: >> >> PKG_OPTIONS.samba4=acl avahi ldap pam winbind >> >> and I get: >> >> #... /net/samba4 ❯ make show-options >> Any of the following general options may be selected: >>acl Enable POSIX ACL support. >>ads Enable Windows Active Directory support. >>avahiEnable DNS service discovery and multicast DNS support. >>fam Support using File Alteration Monitor (FAM). >>ldap Enable LDAP support. >>pam Enable PAM support. >>winbind Enable name-service switch daemon support using >> Windows Servers. >> >> These options are enabled by default: >>ads avahi ldap pam winbind >> >> These options are currently enabled: >>acl ads avahi ldap pam winbind >> >> You can select which build options to use by setting PKG_DEFAULT_OPTIONS >> or PKG_OPTIONS.samba4. >> >> As I said, configure definitely has --with-acl-support and the log >> file indicates attempts to find the bits in question, so it is >> something else. >> >> This is a fairly used pkgsrc build host, perhaps something has gone >> wrong at some stage; I have another one setup with much less changes >> since the original modification, I'll cvs update the whole tree and >> after a rolling-replace will try one more to build samba4 with ad >> support. > > > The build on the second pkgsrc host produced a working dc. The two > pkgsrc hosts use the same /etc/mk.conf file, with the exception that > on the first - failed one - the default python is 3.7, hereas on the > second one it is 3.8, if this matters. > > Now some domain joining... > >> >>> >>> in /etc/mk.conf >>> >>> christos >>> >>>> On Jul 23, 2020, at 9:54 AM, Chavdar Ivanov >>> <mailto:ci4...@gmail.com>> wrote: >>>> > ... > Chavdar signature.asc Description: Message signed with OpenPGP
Re: Samba DC provisioning fails with ACL-enabled NetBSD-current
You are missing:
PKG_OPTIONS.samba4= acl
in /etc/mk.conf
christos
> On Jul 23, 2020, at 9:54 AM, Chavdar Ivanov wrote:
>
> I decided to try the same procedure under -current. It failed with the same:
>
> ...
> File "/usr/pkg/lib/python3.7/site-packages/samba/provision/__init__.py",
> line 1707, in setsysvolacl
>raise ProvisioningError("Samba was compiled without the posix ACL
> support that s3fs requires. "
> ...
>
> I checked the config.log file of the samba4 build and found in bin/config.log:
>
> # using /usr/pkgsrc/net/samba4/work/samba-4.12.5/buildtools/bin/waf
> configure --prefix=/usr/pkg --infodir=/usr/pkg/info
> --mandir=/usr/pkg/man --datarootdir=/usr/pkg/share/samba --libdir=
> --localedir=/usr/pkg/share/locale --docdir=/usr/pkg/share/doc/samba
> --with-statedir=/var/run --with-privatedir=/usr/pkg/etc/samba/private
> --with-piddir=/var/run --with-cachedir=/var/run
> --with-lockdir=/var/run --with-logfilebase=/var/log
> --with-sockets-dir=/var/run --with-modulesdir=/usr/pkg/lib/samba
> --with-privatelibdir=/usr/pkg/lib/samba/private
> --with-privileged-socket-dir=/var/run
> --with-configdir=/usr/pkg/etc/samba --with-libiconv=/usr/pkg
> --abi-check-disable --disable-symbol-versions --jobs=4 --without-gpgme
> --without-regedit --with-acl-support --with-ads --disable-cups
> --without-fam --with-ldap --with-pam
> --with-pammodulesdir=/usr/pkg/lib/samba/security --with-winbind
> --enable-avahi
>
> So '--with-acl-support' is present. Further down it checks for a
> number of other acl related include files, does not find libacl.h, but
> finds acl.h; it can't find the library, though I don't know if it
> should - I couldn't find any.
>
> The rest of the requirements have been apparently fulfilled; the
> samba4 build is from this morning after the latest modifications to
> the package; I've modified /etc/fstab to add posix1eacls and ran
> tunefs, so I get
>
> ➜ xci getfacl .
> # file: .
> # owner: xci
> # group: users
> user::rwx
> group::r-x
> other::r-x
>
> Am I missing something else? I ran the provision command with '-d 10'
> and got a 151MB log file, ending with
> ...
> dfs_samba4: connect to service[Unknown Service (snum == -1)]
> vfswrap_fs_capabilities: timestamp resolution of sec available on
> share (null), directory /
> vfs_ChDir to /
> vfs_ChDir: vfs_ChDir got /
> dfs_samba4_disconnect() connect to service[(null)].
> ERROR(): Provision failed -
> ProvisioningError: Samba was compiled without the posix ACL support
> that s3fs requires. Try installing libacl1-dev or libacl-devel, then
> re-run configure and make.
> File "/usr/pkg/lib/python3.7/site-packages/samba/netcmd/domain.py",
> line 505, in run
>backend_store_size=backend_store_size)
> File "/usr/pkg/lib/python3.7/site-packages/samba/provision/__init__.py",
> line 2366, in provision
>backend_store_size=backend_store_size)
> File "/usr/pkg/lib/python3.7/site-packages/samba/provision/__init__.py",
> line 1992, in provision_fill
>names.domaindn, lp, use_ntvfs)
> File "/usr/pkg/lib/python3.7/site-packages/samba/provision/__init__.py",
> line 1707, in setsysvolacl
>raise ProvisioningError("Samba was compiled without the posix ACL
> support that s3fs requires. "
>
>
>
> Chavdar
>
>
>
> On Mon, 20 Jul 2020 at 17:44, Matthias Petermann wrote:
>>
>> Hello Christos and Patrick,
>>
>> Thank you very much for your quick help. It works with the POSIX.1E ACLs
>> and I now seem to have a domain controller running on NetBSD. What a
>> great day :-) I will now install a Windows as a Xen guest and try to
>> join the domain.
>>
>> Kind regards
>> Matthias
>
>
>
> --
>
signature.asc
Description: Message signed with OpenPGP
Re: nss_winbind Segmentation fault -
In article , Matthias Petermann wrote: > >...I forgot to mention that I had to update the PLIST to make the >package install. Great, I've committed the patch! christos
Re: nss_winbind Segmentation fault -
I am having trouble building pkgsrc. Can you try: https://www.netbsd.org/~christos/samba4.diff <https://www.netbsd.org/~christos/samba4.diff> christos > On Jul 21, 2020, at 11:45 AM, Matthias Petermann wrote: > > Hello Christos, > > Am 21.07.2020 um 16:40 schrieb Christos Zoulas: >> In article , >> Matthias Petermann wrote: >>> Hello Christos, >>> >>> Thank you for your tip - I have come a little further. Am I correctly >>> interpreting the debugger output that the memory address of the integer >>> pointer from groupc points to empty/unallocated memory? >> Yes, but the issue is that there is an argument missing. I am fixing it. > > that sounds good - I'm happy to help with testing! But no hurry :-) > > Kind regards > Matthias signature.asc Description: Message signed with OpenPGP
Re: nss_winbind Segmentation fault -
In article , Matthias Petermann wrote: >Hello Christos, > >Thank you for your tip - I have come a little further. Am I correctly >interpreting the debugger output that the memory address of the integer >pointer from groupc points to empty/unallocated memory? Yes, but the issue is that there is an argument missing. I am fixing it. christos
Re: nss_winbind Segmentation fault - (was: Re: Samba DC provisioning fails with ACL-enabled NetBSD-current)
groupc must be NULL. You probably want to install the debug sets so that you can also see how libc is calling nsdispatch. christos > On Jul 20, 2020, at 7:24 PM, Matthias Petermann wrote: > > ) signature.asc Description: Message signed with OpenPGP
Re: recent changes to pthread_fork.c:fork() cause static linking to fail if the app provides its own malloc()
In article , Greg A. Woods wrote: >-=-=-=-=-=- > >At Tue, 14 Jul 2020 20:05:57 - (UTC), chris...@astron.com (Christos >Zoulas) wrote: >Subject: Re: recent changes to pthread_fork.c:fork() cause static >linking to fail if the app provides its own malloc() >> >> It is not only _malloc_prefork(), it is also _malloc_postfork() and >> _malloc_postfork_child(). The easiest way to fix things is to provide >> them as no-op. > >Indeed. > >I guess this will have to be the way. Perhaps some proper documentation >could/should be written about how to do this and exactly what APIs are >necessary to override the internal malloc() entirely. > >Note that this is necessary in cases of malloc() et al in particular >for both static-linked and dynamic linked programs. http://cvsweb.netbsd.org/bsdweb.cgi/~checkout~/pkgsrc/shells/tcsh/patches/patch-tc.alloc.c?rev=1.3=text/plain
Re: recent changes to pthread_fork.c:fork() cause static linking to fail if the app provides its own malloc()
In article <7171.1594774...@splode.eterna.com.au>, matthew green wrote: >Martin Husemann writes: >> On Tue, Jul 14, 2020 at 02:49:00AM +0200, Joerg Sonnenberger wrote: >> > Replacing malloc is just as invalid from a strict standard compliance >> > perspective, so *shrug* >> >> Why is that? >> >> We have e.g. shells/standalone-tcsh that does it. Is it broken now? > >it was, yes. i worked around it a few days ago. I fixed it by adding the 3 functions to tc.alloc.c both in pkgsrc and upstream. christos
Re: recent changes to pthread_fork.c:fork() cause static linking to fail if the app provides its own malloc()
In article <20200714004900.gb84...@bec.de>, Joerg Sonnenberger wrote: >On Mon, Jul 13, 2020 at 04:28:56PM -0700, Greg A. Woods wrote: >> At Tue, 14 Jul 2020 00:28:46 +0200, Joerg Sonnenberger wrote: >> Subject: Re: recent changes to pthread_fork.c:fork() cause static >linking to fail if the app provides its own malloc() >> > >> > On Mon, Jul 13, 2020 at 03:05:17PM -0700, Greg A. Woods wrote: >> > > I think it is the following change (and perhaps more similar/related >> > > changes) which breaks static linking of applications which wish to >> > > supply their own implementation of malloc(), and which call, e.g., >> > > fork(): >> > >> > I consider it a strong WONTFIX. It's no different from not poviding >> > posix_memalign etc. >> >> >> Well, _malloc_prefork() is explicitly called with an underscore leading >> the identifier name, so strictly speaking it's invalid for an >> application to define it. (and it's not documented, nor in any standard >> that I can find, with or without the leading underscore). > >Replacing malloc is just as invalid from a strict standard compliance >perspective, so *shrug* > >I have absolutely no intention of dealing with more complexity than >necessary for the libc and libpthread interaction for a fringe case. If >it fails explicitly, I would actually consider it an improvement. It is not only _malloc_prefork(), it is also _malloc_postfork() and _malloc_postfork_child(). The easiest way to fix things is to provide them as no-op. christos
Re: postinstall removed yet another "obsolete" system library that was still used....
In article , Greg A. Woods wrote: >-=-=-=-=-=- > >So I just upgraded a system from an old 8.99 -current to a newer 9.99 >current and "postinstall fix obsolete" removed my /usr/lib/libgomp.so.1* > >However this library was still in use by installed packages (due, I >think, to a dependency of libgd on libgomp, thus every gd-using package >is now G.D. broke)! > >I propose that the rule documented in src/distrib/lists/base/shl.mi be >far more strictly observed, even for libraries that appear and disappear >between releases (i.e. for -current), at least for the ".major" link and >the file it points to. If they were never there in a release, never >mentioning them as obsolete in releases should be just fine (i.e. they >were never there, so never mentioning them is the correct thing to do). > >On the other hand we could first fix postinstall to be more careful by >getting it to fetch all the "REQUIRED" values from package BUILD_INFO >like this: > > pkg_info -a -Q REQUIRES | sort -u > >and then have it noisily refuse to remove any obsolete file still in >this "required" list. This would allow us to mention all old/upgraded >shared libraries as obsolete, including those from between releases. Of >course this only protects things installed via pkgsrc, and there's still >the risk of subsequently needing to install a binary package built for >an older release which needs one of these "obsolete" files, but at least >pkg_add can (be made to if it doesn't already) notice this and abort. That is a good idea. Perhaps even pkg_info -a -Q REQUIRES | fgrep -v /usr/pkg | sort -u christos
Re: blacklist -> blocklist in current
https://www.theregister.com/2020/06/15/github_replaces_master_with_main/ <https://www.theregister.com/2020/06/15/github_replaces_master_with_main/> christos > On Jun 15, 2020, at 2:35 PM, Kamil Rytarowski wrote: > > Signed PGP part > On 15.06.2020 20:05, Alexander Nasonov wrote: >> Christos Zoulas wrote: >>> >>> Hello folks, >>> >>> I've renamed blacklist to blocklist, so if you are currently using it, >>> you should rename things accordingly: >>> >>> - rc.conf variable >>> - /var/db/blacklist.db file >>> - npf table name >>> >>> Apologies for the inconvenience, >> >> I doubt that you can express a concept of exclusion without offending >> anyone. E.g. the new term reminds me of blockades. >> >> https://en.wikipedia.org/wiki/List_of_historical_blockades >> > > Whitelist/blacklist is a regular term in computing. I have never seen > 'blocklisting' before. > > According to grep.app: blacklisting 4560 results vs blocklisting 51, > while blocklisting is (or was) more associated with other terms like > listing block coverage (as opposed to branch coverage). > > New name/term is confusing. > > > signature.asc Description: Message signed with OpenPGP
Re: commit-guidelines (was Re: blacklist -> blocklist in current)
+ core. christos > On Jun 16, 2020, at 3:31 PM, Alexander Nasonov wrote: > > Christos Zoulas wrote: >> >> >>> On Jun 16, 2020, at 2:17 PM, Alexander Nasonov wrote: >>> >>> If my reading of the current commit guideline is correct, a case >>> of renaming already released application doesn't fall into the >>> "obvious" fix because some people can possibly object to breaking >>> backward compatibility. >> >> You are correct, and this is why I discussed it with core before doing it. >> In fact >> the name "block" instead of "deny" was suggested by a core member: I chose >> "block" over "deny" because of similarity to the previous name, >> and because some of the API's start with "bl_" and would not need to be >> modified. If "deny" was chosen instead, these would probably need to be >> changed to "dl_" and that prefix is associated with the dynamic linker. > > Clause 4 (and probably others) needs a serious overhaul to make > sure that all cases that needs a review reach everyone who has a > voice (and who can potentially object) before involving the Core, > if necessary. > > The current wording isn't inclusive, period. > > -- > Alex signature.asc Description: Message signed with OpenPGP
Re: blacklist -> blocklist in current
> On Jun 16, 2020, at 2:17 PM, Alexander Nasonov wrote: > > If my reading of the current commit guideline is correct, a case > of renaming already released application doesn't fall into the > "obvious" fix because some people can possibly object to breaking > backward compatibility. You are correct, and this is why I discussed it with core before doing it. In fact the name "block" instead of "deny" was suggested by a core member: I chose "block" over "deny" because of similarity to the previous name, and because some of the API's start with "bl_" and would not need to be modified. If "deny" was chosen instead, these would probably need to be changed to "dl_" and that prefix is associated with the dynamic linker. Best, christos signature.asc Description: Message signed with OpenPGP
Re: blacklist -> blocklist in current
In article <02813400-41f9-cec9-84d0-ed3ccd2a8...@netbsd.org>, Kamil Rytarowski wrote: >-=-=-=-=-=- >Perpetuating this Western-centric stereotype in such renames is abusive >to the white East people, that used to be on the black skin side of the >human history (Slavic ethnicity has etymology in the word 'slave' - do >you want to rename us?). Putting it into throats of the rest of the >global East world is offensive. At least the renames won't take away the >title of "the White Negroes of Europe" as given with brotherhood and >respect by Jean-Jacques Dessalines to so called Polanders (and >perpetuated in the Hayti constitution from 1805). The fact that >Americans did not follow the Last Will of the founding father of United >States Kosciuszko (Polish by origin) of liberating slaves (Jefferson the >3rd president preferred to keep the slaves for better profit) and >instead vandalized his memorial in the recent days is just meaningful. > I think that you would agree that owners of applications should be allowed to name them as they please. And that me renaming my application causes equal "abuse" (inconvenience) to everyone. christos
Re: blacklist -> blocklist in current
Hi Marc, When I wrote this in 2015 I did not consider the terms blacklist/whitelist offensive, or associated them with race. If as was going to name the program today I would have chosen differently; perhaps I would have chosen 'denylist' instead of 'blocklist', (I smirk because the spell-checker autocorrected blocklist to blacklist even when I had it in quotes and I had to change it back), but I would not have called it blacklist. I made the poor naming choice in 2015, and I needed to fix it. I decided to do it quickly, and I did not want to have a discussion about it -- I was going to do it anyway. I believe that as insignificant and annoying that change might seem to some, it is a move in the right direction and I hope that it will inspire/encourage others to make similar changes where appropriate. We should be all doing whatever we can to correct social/race/gender/sex injustices/prejudices around us, and every little bit helps. Best, christos > On Jun 15, 2020, at 3:02 PM, Marc Balmer wrote: > > And you just do that based on you own opinion, without previous discussion, > breaking existing confugurations, and all you have to offer is a „sorry for > the inconvenience“? > > That inconvenience was not needed and nobody asked for it. > >> Am 15.06.2020 um 04:02 schrieb Christos Zoulas : >> >> >> Hello folks, >> >> I've renamed blacklist to blocklist, so if you are currently using it, >> you should rename things accordingly: >> >> - rc.conf variable >> - /var/db/blacklist.db file >> - npf table name >> >> Apologies for the inconvenience, >> >> christos signature.asc Description: Message signed with OpenPGP
blacklist -> blocklist in current
Hello folks, I've renamed blacklist to blocklist, so if you are currently using it, you should rename things accordingly: - rc.conf variable - /var/db/blacklist.db file - npf table name Apologies for the inconvenience, christos
Re: kernel diagnostic assertion "semcnt >= 0" failed
In article , Benny Siegert wrote: >On Sat, Jun 6, 2020 at 7:04 PM Christos Zoulas wrote: >> I know, but my comment still holds. This has been working for a while. >> Does it fail the same way with NetBSD-9? > >Sorry, I didn't see this. No, it works fine in NetBSD-9 on the same machine. So it must be some newer changes and I suspect the pshared semaphores. Please file a PR. christos
