Re: Build error when crypto and swcrypto are omitted from kernel
On Sun, May 10, 2020 at 07:52:42PM -, Michael van Elst wrote: > And I'd like to talk to Martin, since 100% of the task is done if > we just add the missing dependency without the option. Lets start with just the dependency and see if everything fits in the next build run. We can add the option later if needed (I don't like a SMALL option as it is very unspecific). Martin
daily CVS update output
Updating src tree: P src/crypto/dist/ipsec-tools/src/setkey/token.l P src/distrib/sets/lists/comp/ad.aarch64 P src/distrib/sets/lists/tests/mi P src/doc/HACKS P src/external/bsd/dhcpcd/dist/src/dhcpcd.c P src/lib/libc/arch/aarch64/genassym.cf P src/lib/libc/arch/aarch64/gen/_setjmp.S P src/lib/libc/arch/aarch64/gen/setjmp.S P src/lib/libc/arch/hppa/sys/brk.S P src/lib/libc/arch/hppa/sys/sbrk.S P src/lib/libc/gen/Makefile.inc P src/libexec/ld.elf_so/arch/hppa/hppa_reloc.c P src/libexec/ld.elf_so/arch/hppa/rtld_start.S P src/share/mk/bsd.lib.mk P src/sys/arch/aarch64/aarch64/cpu.c P src/sys/arch/aarch64/conf/Makefile.aarch64 P src/sys/arch/aarch64/include/Makefile P src/sys/arch/aarch64/include/armreg.h P src/sys/arch/aarch64/include/asm.h P src/sys/arch/aarch64/include/setjmp.h U src/sys/arch/aarch64/include/trap.h P src/sys/arch/amd64/amd64/machdep.c P src/sys/arch/x86/include/cpu_rng.h P src/sys/arch/x86/x86/cpu_rng.c P src/sys/dev/nvmm/x86/nvmm_x86_svm.c P src/sys/dev/nvmm/x86/nvmm_x86_vmx.c P src/sys/uvm/files.uvm P src/usr.bin/make/unit-tests/Makefile U src/usr.bin/make/unit-tests/dollar.exp U src/usr.bin/make/unit-tests/dollar.mk P src/usr.sbin/cpuctl/arch/aarch64.c P src/usr.sbin/rtadvd/rtadvd.c Updating xsrc tree: Killing core files: Updating release-8 src tree (netbsd-8): Updating release-8 xsrc tree (netbsd-8): Updating release-9 src tree (netbsd-9): U doc/CHANGES-9.1 P external/cddl/osnet/dist/uts/common/fs/zfs/zfs_vnops.c P external/cddl/osnet/dist/uts/common/fs/zfs/zfs_znode.c P sys/dev/usb/if_cdce.c Updating release-9 xsrc tree (netbsd-9): Updating file list: -rw-rw-r-- 1 srcmastr netbsd 38105437 May 11 03:11 ls-lRA.gz
Re: pkgtools/pkgin 0.16.1 fails build under -current
On Sun, 10 May 2020 at 23:41, Chavdar Ivanov wrote: > > Hi, > > I get: > ... Same happens with multimedia/libmp4v2, but for this one needs also -Wno-stringop-truncation . > # compile pkgin-0.16.1/tools.o > gcc -O2 -I/usr/include -I/usr/pkg/include -fPIE-std=gnu99 > -Werror-DHAVE_NBCOMPAT_H=1 > -I/usr/pkgsrc/pkgtools/pkgin/work/libnbcompat -I/usr/include > -I/usr/pkg/include -DPKGIN_VERSION=\""0.16.1 for NetB > SD-9.99.60 x86_64"\" -DHAVE_NBCOMPAT_H=1 > -I/usr/pkgsrc/pkgtools/pkgin/work/libnbcompat -I/usr/include > -I/usr/pkg/include -g -DLOCALBASE=\"/usr/pkg\" > -DPKG_SYSCONFDIR=\"/usr/pkg/etc\" > -DPKGIN_DBDIR=\"/var/db/pkgin\" > -DPKGTOOLS=\"/usr/pkg/sbin\" -DHAVE_CONFIG_H -D_LARGEFILE_SOURCE > -D_LARGE_FILES -DCHECK_MACHINE_ARCH=\"x86_64\" -I. -I/usr/pkg/include > -ctools.c > tools.c: In function 'strreplace': > tools.c:170:4: error: 'strncat' specified bound depends on the length > of the source argument [-Werror=stringop-overflow=] > strncat(buf, to, tolen); > ^~~ > tools.c:166:10: note: length computed here > tolen = strlen(to); > ^~ > cc1: all warnings being treated as errors > *** Error code 1 > > For lack of understanding, adding > > CFLAGS+= -Wno-stringop-overflow > > to the Makefile completes the build, but probably is not the right thing to > do. > > Chavdar > > > -- > --
pkgtools/pkgin 0.16.1 fails build under -current
Hi, I get: ... # compile pkgin-0.16.1/tools.o gcc -O2 -I/usr/include -I/usr/pkg/include -fPIE-std=gnu99 -Werror-DHAVE_NBCOMPAT_H=1 -I/usr/pkgsrc/pkgtools/pkgin/work/libnbcompat -I/usr/include -I/usr/pkg/include -DPKGIN_VERSION=\""0.16.1 for NetB SD-9.99.60 x86_64"\" -DHAVE_NBCOMPAT_H=1 -I/usr/pkgsrc/pkgtools/pkgin/work/libnbcompat -I/usr/include -I/usr/pkg/include -g -DLOCALBASE=\"/usr/pkg\" -DPKG_SYSCONFDIR=\"/usr/pkg/etc\" -DPKGIN_DBDIR=\"/var/db/pkgin\" -DPKGTOOLS=\"/usr/pkg/sbin\" -DHAVE_CONFIG_H -D_LARGEFILE_SOURCE -D_LARGE_FILES -DCHECK_MACHINE_ARCH=\"x86_64\" -I. -I/usr/pkg/include -ctools.c tools.c: In function 'strreplace': tools.c:170:4: error: 'strncat' specified bound depends on the length of the source argument [-Werror=stringop-overflow=] strncat(buf, to, tolen); ^~~ tools.c:166:10: note: length computed here tolen = strlen(to); ^~ cc1: all warnings being treated as errors *** Error code 1 For lack of understanding, adding CFLAGS+= -Wno-stringop-overflow to the Makefile completes the build, but probably is not the right thing to do. Chavdar --
Re: Build error when crypto and swcrypto are omitted from kernel
On Sun, 10 May 2020, Michael van Elst wrote:
p...@whooppee.com (Paul Goyette) writes:
Well, 90%+ of the effort has already been expended, so why not?
90%+ is probably the time needed to test optional builds in the future.
FWIW, I have just successfully completed my build of my custom kernel
(and an entire ``build.sh release'') and it correctly included the
rijndael stuff (even without the two {,sw}crypto pseudo-devices).
And I'd like to talk to Martin, since 100% of the task is done if
we just add the missing dependency without the option. Even an
#ifdef SMALL could be easier to maintain.
Yep, that would work, too. I'm open to either approach, just would
like to move forward.
++--+---+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org |
++--+---+
Re: Build error when crypto and swcrypto are omitted from kernel
p...@whooppee.com (Paul Goyette) writes:
>> Well, 90%+ of the effort has already been expended, so why not?
90%+ is probably the time needed to test optional builds in the future.
>FWIW, I have just successfully completed my build of my custom kernel
>(and an entire ``build.sh release'') and it correctly included the
>rijndael stuff (even without the two {,sw}crypto pseudo-devices).
And I'd like to talk to Martin, since 100% of the task is done if
we just add the missing dependency without the option. Even an
#ifdef SMALL could be easier to maintain.
--
--
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."
Re: Build error when crypto and swcrypto are omitted from kernel
On Sun, 10 May 2020, Paul Goyette wrote:
On Sun, 10 May 2020, Michael van Elst wrote:
p...@whooppee.com (Paul Goyette) writes:
FWIW, here's an additional patch to update the options(4) man page:
But is it worth the effort to make 16kB optional ?
Well, 90%+ of the effort has already been expended, so why not?
FWIW, I have just successfully completed my build of my custom kernel
(and an entire ``build.sh release'') and it correctly included the
rijndael stuff (even without the two {,sw}crypto pseudo-devices).
I'd be happy to do the commit if you don't want to expend any further
effort here.
++--+---+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org |
++--+---+
Re: Build error when crypto and swcrypto are omitted from kernel
On Sun, 10 May 2020, Michael van Elst wrote: p...@whooppee.com (Paul Goyette) writes: FWIW, here's an additional patch to update the options(4) man page: But is it worth the effort to make 16kB optional ? Well, 90%+ of the effort has already been expended, so why not? ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: Build error when crypto and swcrypto are omitted from kernel
p...@whooppee.com (Paul Goyette) writes: >FWIW, here's an additional patch to update the options(4) man page: But is it worth the effort to make 16kB optional ? -- -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Re: Build error when crypto and swcrypto are omitted from kernel
On Sun, 10 May 2020, Michael van Elst wrote: On Sun, May 10, 2020 at 08:46:30AM -0700, Paul Goyette wrote: Here is a patch that makes encrypted swap (but not rijndael) optional: http://ftp.netbsd.org/pub/NetBSD/misc/mlelstv/uvm_swap.diff That looks good to me, too. I guess you should also add VM_SWAPCRYPT option to various kernels (GENERIC*, XEN3*, ...)? It's a default option in sys/conf/std. Individual kernels can disable it with 'no options VMSWAPCRYPT'. Yeah, found that. FWIW, here's an additional patch to update the options(4) man page: Index: share/man/man4/options.4 === RCS file: /cvsroot/src/share/man/man4/options.4,v retrieving revision 1.512 diff -u -p -r1.512 options.4 --- share/man/man4/options.424 Apr 2020 13:54:56 - 1.512 +++ share/man/man4/options.410 May 2020 17:11:27 - @@ -2221,6 +2221,9 @@ for port specific details including avai .It Cd options VMSWAP Enable paging device/file support. This option is on by default. +.It Cd options VMSWAPCRYPT +Enable encryption of swapfile. +This option is on by default. .It Cd options PDPOLICY_CLOCKPRO Use CLOCK-Pro, an alternative page replace policy. .El ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: Build error when crypto and swcrypto are omitted from kernel
On Sun, 10 May 2020, Paul Goyette wrote: Here is a patch that makes encrypted swap (but not rijndael) optional: http://ftp.netbsd.org/pub/NetBSD/misc/mlelstv/uvm_swap.diff That looks good to me, too. I guess you should also add VM_SWAPCRYPT option to various kernels (GENERIC*, XEN3*, ...)? Oh never mind - you already added it to std. :) Please commit. ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: Build error when crypto and swcrypto are omitted from kernel
Here is a patch that makes encrypted swap (but not rijndael) optional: http://ftp.netbsd.org/pub/NetBSD/misc/mlelstv/uvm_swap.diff That looks good to me, too. I guess you should also add VM_SWAPCRYPT option to various kernels (GENERIC*, XEN3*, ...)? Please commit. ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: Build error when crypto and swcrypto are omitted from kernel
On Sun, 10 May 2020, Michael van Elst wrote: On Sun, May 10, 2020 at 07:54:06AM -0700, Paul Goyette wrote: Prior to the encrypted-swap commit, a kernel configured without the ``pseudo-device crypto'' was able to link and run successfully. (Any attempt to use rijndael results in an auto-load of the crypto module.) Even without 'pseudo-device crypto' some kernels still build, as long as the dependency to the rijndael files exists in the kernel configuration. This is e.g. true if you built with wlan drivers or cgd. Here is a patch that makes encrypted swap (but not rijndael) optional: http://ftp.netbsd.org/pub/NetBSD/misc/mlelstv/uvm_swap.diff which might be useful to create small kernels (it's just about 16kB). Otherwise you could just add the dependency to uvm unconditionally. Seems to me that any attempt to enable encrypted-swap should also trigger an auto-load for the crypto module. Appropriate module hooks should be used to avoid the undefined symbols. The rijndael code is not a module, and the crypto module is neither used nor referenced, it shouldn't be loaded then. You would be perfectly right if it wasn't rijndael but e.g. des. Ah, OK, I got it now. Thanks for your patience. ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: Build error when crypto and swcrypto are omitted from kernel
On Sun, May 10, 2020 at 07:54:06AM -0700, Paul Goyette wrote: > Prior to the encrypted-swap commit, a kernel configured without the > ``pseudo-device crypto'' was able to link and run successfully. (Any > attempt to use rijndael results in an auto-load of the crypto module.) Even without 'pseudo-device crypto' some kernels still build, as long as the dependency to the rijndael files exists in the kernel configuration. This is e.g. true if you built with wlan drivers or cgd. > > Here is a patch that makes encrypted swap (but not rijndael) optional: > > > > http://ftp.netbsd.org/pub/NetBSD/misc/mlelstv/uvm_swap.diff > > > > which might be useful to create small kernels (it's just about 16kB). > > > > Otherwise you could just add the dependency to uvm unconditionally. > > Seems to me that any attempt to enable encrypted-swap should also > trigger an auto-load for the crypto module. Appropriate module hooks > should be used to avoid the undefined symbols. The rijndael code is not a module, and the crypto module is neither used nor referenced, it shouldn't be loaded then. You would be perfectly right if it wasn't rijndael but e.g. des. Greetings, -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Re: Build error when crypto and swcrypto are omitted from kernel
> Date: Sun, 10 May 2020 13:44:49 - > From: mlel...@serpens.de (Michael van Elst) > > Here is a patch that makes encrypted swap (but not rijndael) optional: > > http://ftp.netbsd.org/pub/NetBSD/misc/mlelstv/uvm_swap.diff > > which might be useful to create small kernels (it's just about 16kB). LGTM, feel free to commit.
Re: Build error when crypto and swcrypto are omitted from kernel
On Sun, 10 May 2020, Michael van Elst wrote: p...@whooppee.com (Paul Goyette) writes: the kernel. Without this, the kernel fails to link, with undefined references to several symbols: rijndael_cipherInit rijndael_blockEncrypt rijndael_blockDecrypt rijndael_makeKey Since the two crypto devices are optional (and run-time loadable) components of the kernel, it seems to me that encrypted-swap should also be optional. rijndael isn't (yet) optional as it is required by ipsec and wlan code. We just miss the dependency for the encrypted swap functionality. Prior to the encrypted-swap commit, a kernel configured without the ``pseudo-device crypto'' was able to link and run successfully. (Any attempt to use rijndael results in an auto-load of the crypto module.) Here is a patch that makes encrypted swap (but not rijndael) optional: http://ftp.netbsd.org/pub/NetBSD/misc/mlelstv/uvm_swap.diff which might be useful to create small kernels (it's just about 16kB). Otherwise you could just add the dependency to uvm unconditionally. Seems to me that any attempt to enable encrypted-swap should also trigger an auto-load for the crypto module. Appropriate module hooks should be used to avoid the undefined symbols. ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: Build error when crypto and swcrypto are omitted from kernel
p...@whooppee.com (Paul Goyette) writes: >the kernel. Without this, the kernel fails to link, with undefined >references to several symbols: > rijndael_cipherInit > rijndael_blockEncrypt > rijndael_blockDecrypt > rijndael_makeKey >Since the two crypto devices are optional (and run-time loadable) >components of the kernel, it seems to me that encrypted-swap should >also be optional. rijndael isn't (yet) optional as it is required by ipsec and wlan code. We just miss the dependency for the encrypted swap functionality. Here is a patch that makes encrypted swap (but not rijndael) optional: http://ftp.netbsd.org/pub/NetBSD/misc/mlelstv/uvm_swap.diff which might be useful to create small kernels (it's just about 16kB). Otherwise you could just add the dependency to uvm unconditionally. -- -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Re: i386 Xen integration breaks linking NET4501 kernel
On Sun, May 10, 2020 at 02:36:15PM +0200, Rhialto wrote: > Probably similarly, linking fails when building an amd64 MODULAR kernel, > with some Xen-related undefined symbol errors: Yes I posted a question to tech-kern, asking how to resolve this, I got no reply so far. -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Build error when crypto and swcrypto are omitted from kernel
With the recent introduction of swap encryption, it is now mandatory to include "pseudo-device crypto" and/or "pseudo-device swcrypto" in the kernel. Without this, the kernel fails to link, with undefined references to several symbols: rijndael_cipherInit rijndael_blockEncrypt rijndael_blockDecrypt rijndael_makeKey Since the two crypto devices are optional (and run-time loadable) components of the kernel, it seems to me that encrypted-swap should also be optional. ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: i386 Xen integration breaks linking NET4501 kernel
Probably similarly, linking fails when building an amd64 MODULAR kernel, with some Xen-related undefined symbol errors: building standard kern library create vers.c compile MODULAR/vers.o link MODULAR/netbsd /vol1/rhialto/tools.amd64/bin/x86_64--netbsd-ld: hypervisor.o: in function `xenkernfs_init': /mnt/vol1/rhialto/cvs/src/sys/arch/xen/xen/hypervisor.c:787: undefined reference to `kernfs_addentry' /vol1/rhialto/tools.amd64/bin/x86_64--netbsd-ld: xenbus_dev.o: in function `xenbus_kernfs_init': /mnt/vol1/rhialto/cvs/src/sys/arch/xen/xenbus/xenbus_dev.c:86: undefined reference to `kernfs_alloctype' /vol1/rhialto/tools.amd64/bin/x86_64--netbsd-ld: /mnt/vol1/rhialto/cvs/src/sys/arch/xen/xenbus/xenbus_dev.c:90: undefined reference to `kernfs_addentry' /vol1/rhialto/tools.amd64/bin/x86_64--netbsd-ld: /mnt/vol1/rhialto/cvs/src/sys/arch/xen/xenbus/xenbus_dev.c:93: undefined reference to `kernfs_alloctype' /vol1/rhialto/tools.amd64/bin/x86_64--netbsd-ld: /mnt/vol1/rhialto/cvs/src/sys/arch/xen/xenbus/xenbus_dev.c:97: undefined reference to `kernfs_addentry' -Olaf. -- Olaf 'Rhialto' Seibert -- rhialto at falu dot nl ___ Anyone who is capable of getting themselves made President should on \X/ no account be allowed to do the job. --Douglas Adams, "THGTTG" signature.asc Description: PGP signature
Re: pkgsrc current dbus build failure
On 09.05.2020 12:53, Roland Illig wrote: On 08.05.2020 18:36, Ron Georgia wrote: Thank you for pointing that out. I am updating now. I downloaded the NetBSD-9.99.60-amd64-install.img (date stamped May 07, 2020) this morning and installed on my Lenovo X200. I did select the option to download pkgsrc. I changed the path from stable to current and that is what was pulled in. I didn't find NetBSD-9.99.60-amd64-install.img anywhere, therefore I used another ISO image. I installed NetBSD 8 in a VM and, like you, changed the pkgsrc path from stable to current. This way, pkgsrc was downloaded from https://ftp.netbsd.org/pub/pkgsrc/current/, where all files have been updated today in the morning. I would expect that these files are updated daily. There are exactly 7 days between 2020-05-02 and 2020-05-09 though, therefore it could also be that the files are updated weekly. I don't think that's the case, we'll see tomorrow. Indeed the archives in /pub/pkgsrc/current/ are only updated weekly. The pkgsrc tree with the individual files is updated daily though. In such a case you can always "cvs update" locally since the archives include the CVS metadata.
