Re: Devices without power management support: dm0 dm1 (LVM / Device Mapper prevents ACPI Sleep State 3)
On Wed, Jan 15, 2020 at 07:25:10AM +0100, Matthias Petermann wrote:
> Hello Maya,
>
> many thanks for your response. I used the patch in my NetBSD 9.0 (RC1)
> kernel and rebuilt it. However, it does not seem to be the solution to the
> problem. If i want to send the system to sleep, the message still appears:
>
> [92,499360] Devices without power management support: dm0 dm1
>
> For security, I have added additional logging - should that actually appear
> in the kernel log?
>
> ...
> static void
> dm_attach(device_t parent, device_t self, void *aux)
> {
> aprint_error("dm_attach called\n");
> ...
>
> static int
> dm_detach(device_t self, int flags)
> {
> dm_dev_t *dmv;
> aprint_error("dm_detach called\n");
> ...
>
> Since I don't see any of this in the log, I'm not sure at all whether the
> code is actually executed. Is it generally the case that all device drivers
> are "detached" before entering ACPI Sleep state 3? Or could this be a
> special case?
You will need to rebuild the modules, not the kernel.
build.sh modules
sudo build.sh ... installmodules=/
Is how I usually do it.
Re: Devices without power management support: dm0 dm1 (LVM / Device Mapper prevents ACPI Sleep State 3)
m...@petermann-it.de (Matthias Petermann) writes: >Hello Maya, >many thanks for your response. I used the patch in my NetBSD 9.0 (RC1)=20 >kernel and rebuilt it. However, it does not seem to be the solution to=20 >the problem. If i want to send the system to sleep, the message still=20 >appears: > [92,499360] Devices without power management support: dm0 dm1 The dm driver is probably loaded as a module. You also need to rebuild and install the modules. -- -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Re: Devices without power management support: dm0 dm1 (LVM / Device Mapper prevents ACPI Sleep State 3)
Hello Maya,
many thanks for your response. I used the patch in my NetBSD 9.0 (RC1)
kernel and rebuilt it. However, it does not seem to be the solution to
the problem. If i want to send the system to sleep, the message still
appears:
[92,499360] Devices without power management support: dm0 dm1
For security, I have added additional logging - should that actually
appear in the kernel log?
...
static void
dm_attach(device_t parent, device_t self, void *aux)
{
aprint_error("dm_attach called\n");
...
static int
dm_detach(device_t self, int flags)
{
dm_dev_t *dmv;
aprint_error("dm_detach called\n");
...
Since I don't see any of this in the log, I'm not sure at all whether
the code is actually executed. Is it generally the case that all device
drivers are "detached" before entering ACPI Sleep state 3? Or could this
be a special case?
Best wishes
Matthias
On 14.01.20 07:13, m...@netbsd.org wrote:
The pmf_device_register go appearing in most drivers is what is
responsible for whitelisting drivers.
So something like this might do.
Index: device-mapper.c
===
RCS file: /cvsroot/src/sys/dev/dm/device-mapper.c,v
retrieving revision 1.59
diff -u -r1.59 device-mapper.c
--- device-mapper.c 22 Dec 2019 13:16:09 - 1.59
+++ device-mapper.c 14 Jan 2020 06:13:17 -
@@ -245,6 +245,8 @@
static void
dm_attach(device_t parent, device_t self, void *aux)
{
+ if (!pmf_device_register(self, NULL, NULL))
+ aprint_error_dev(self, "couldn't establish power handler\n");
}
/*
@@ -259,6 +261,8 @@
{
dm_dev_t *dmv;
+ pmf_device_deregister(self);
+
/* Detach device from global device list */
if ((dmv = dm_dev_detach(self)) == NULL)
return ENOENT;
smime.p7s
Description: S/MIME Cryptographic Signature
daily CVS update output
Updating src tree: P src/doc/CHANGES P src/external/bsd/libarchive/dist/libarchive/archive_write_disk_posix.c P src/lib/libc/thread-stub/thread-stub.c P src/sbin/rndctl/Makefile P src/share/man/man4/piixpm.4 P src/share/man/man4/wd.4 P src/share/mk/bsd.own.mk P src/sys/arch/arm/imx/if_enet.c P src/sys/arch/arm/imx/if_enet_imx6.c P src/sys/arch/arm/imx/if_enet_imx7.c P src/sys/arch/arm/imx/if_enetvar.h P src/sys/arch/arm/imx/imx6_board.c P src/sys/arch/arm/imx/imx6_pcie.c P src/sys/arch/arm/imx/imx6_usdhc.c P src/sys/arch/arm/imx/imx7_usdhc.c P src/sys/arch/arm/imx/imxgpio.c P src/sys/arch/arm/imx/imxgpiovar.h P src/sys/arch/arm/imx/imxuart.c P src/sys/arch/arm/imx/fdt/files.imx6 P src/sys/arch/arm/imx/fdt/if_enet_imx.c P src/sys/arch/arm/imx/fdt/imx6_com.c P src/sys/arch/arm/imx/fdt/imx6_gpio.c P src/sys/arch/arm/imx/fdt/imx6_iomux.c P src/sys/arch/arm/imx/fdt/imx6_sdhc.c U src/sys/arch/arm/imx/fdt/imx7_gpc.c U src/sys/arch/arm/imx/fdt/imx8mq_ccm.c U src/sys/arch/arm/imx/fdt/imx8mq_ccm.h U src/sys/arch/arm/imx/fdt/imx8mq_usbphy.c U src/sys/arch/arm/imx/fdt/imx_ccm.c U src/sys/arch/arm/imx/fdt/imx_ccm.h U src/sys/arch/arm/imx/fdt/imx_ccm_composite.c U src/sys/arch/arm/imx/fdt/imx_ccm_extclk.c U src/sys/arch/arm/imx/fdt/imx_ccm_fixed.c U src/sys/arch/arm/imx/fdt/imx_ccm_fixed_factor.c U src/sys/arch/arm/imx/fdt/imx_ccm_gate.c P src/sys/arch/evbarm/conf/GENERIC64 P src/sys/arch/evbarm/conf/files.generic64 P src/sys/arch/ia64/stand/ia64/ski/ssc.c P src/sys/arch/x68k/stand/boot/boot.c P src/sys/arch/x68k/stand/boot_ufs/boot.S P src/sys/arch/x68k/stand/boot_ufs/boot_ufs.h P src/sys/dev/ata/wd.c P src/sys/dev/fdt/dwc3_fdt.c P src/sys/dev/mii/ipgphy.c P src/sys/dev/pci/if_stge.c P src/sys/dev/pci/if_stgereg.h P src/sys/dev/pci/piixpm.c P src/sys/dev/pci/piixpmreg.h P src/usr.bin/ktruss/dump.c P src/usr.sbin/sysinst/mbr.c Updating xsrc tree: Killing core files: Updating release-7 src tree (netbsd-7): Updating release-7 xsrc tree (netbsd-7): Updating release-8 src tree (netbsd-8): Updating release-8 xsrc tree (netbsd-8): Updating file list: -rw-rw-r-- 1 srcmastr netbsd 35241892 Jan 15 03:11 ls-lRA.gz
bug in build for RPi (GENERIC)
*--- dependall-exec_elf32
---/c/usr/src/obj/tooldir.NetBSD-9.99.17-evbarm/bin/nbctfconvert -L VERSION
exec_elf32.o--- core_elf32.o ---# compile
exec_elf32/core_elf32.o/c/usr/src/obj/tooldir.NetBSD-9.99.17-evbarm/bin/armv7--netbsdelf-eabihf-gcc
-O2 -g -std=gnu99-Wall -Wstrict-prototypes -Wmissing-prototypes
-Wpointer-arith -Wno-sign-compare -Wsystem-headers -Wno-traditional
-Wa,--fatal-warnings -Wreturn-type -Wswitch\ -Wshadow -Wcast-qual
-Wwrite-strings -Wextra -Wno-unused-parameter -Wno-sign-compare -Werror
-ffreestanding -fno-strict-aliasing -Wno-pointer-sign -fno-common
-fno-unwind-tables -mfloat-abi=soft -I/c/usr/src/common/include
-DDIAGNOSTIC --sysroot=/c/usr/src/o\bj/destdir.evbarm -DEXEC_ELF32
-DPAX_ASLR -I/c/usr/src/common/include -DDIAGNOSTIC -nostdinc -I.
-I/c/usr/src/sys/modules/exec_elf32 -isystem /c/usr/src/sys -isystem
/c/usr/src/sys/arch -isystem /c/usr/src/sys/../common/include -D_KERNEL
-D_LKM -D_MODULE -DSYSCTL\_INCLUDE_DESCR -c
/c/usr/src/sys/kern/core_elf32.c--- dependall-compat_netbsd32
---/tmp/genassym.g0QgV8/assym.c: In function
'f64':/tmp/genassym.g0QgV8/assym.c:57:1: error: asm operand 0 probably
doesn't match constraints [-Werror] __asm("XYZZY VM_MIN_ADDRESS %0" : : "n"
(VM_MIN_ADDRESS)); ^/tmp/genassym.g0QgV8/assym.c:58:1: error: asm
operand 0 probably doesn't match constraints [-Werror] __asm("XYZZY
VM_MAXUSER_ADDRESS %0" : : "n" (VM_MAXUSER_ADDRESS)); ^---
dependall-udf
---/c/usr/src/obj/tooldir.NetBSD-9.99.17-evbarm/bin/nbctfconvert -L VERSION
udf_vfsops.o--- dependall-compat_netbsd32
---/tmp/genassym.g0QgV8/assym.c:97:1: error: asm operand 0 probably doesn't
match constraints [-Werror] __asm("XYZZY PAGE_MASK %0" : : "n"
(PAGE_MASK)); ^/tmp/genassym.g0QgV8/assym.c:98:1: error: asm operand 0
probably doesn't match constraints [-Werror] __asm("XYZZY PAGE_SIZE %0" : :
"n" (PAGE_SIZE)); ^/tmp/genassym.g0QgV8/assym.c:57:1: error: impossible
constraint in 'asm' __asm("XYZZY VM_MIN_ADDRESS %0" : : "n"
(VM_MIN_ADDRESS)); ^/tmp/genassym.g0QgV8/assym.c:58:1: error:
impossible constraint in 'asm' __asm("XYZZY VM_MAXUSER_ADDRESS %0" : : "n"
(VM_MAXUSER_ADDRESS)); ^/tmp/genassym.g0QgV8/assym.c:97:1: error:
impossible constraint in 'asm' __asm("XYZZY PAGE_MASK %0" : : "n"
(PAGE_MASK)); ^/tmp/genassym.g0QgV8/assym.c:98:1: error: impossible
constraint in 'asm' __asm("XYZZY PAGE_SIZE %0" : : "n" (PAGE_SIZE)); ^~~*~~
Automated report: NetBSD-current/i386 build success
The NetBSD-current/i386 build is working again. The following commits were made between the last failed build and the successful build: 2020.01.14.22.55.27 msaitoh src/sys/dev/pci/piixpmreg.h,v 1.12 2020.01.14.23.13.36 christos src/sbin/rndctl/Makefile,v 1.5 Log files can be found at: http://releng.NetBSD.org/b5reports/i386/commits-2020.01.html#2020.01.14.23.13.36
Automated report: NetBSD-current/i386 build failure
This is an automatically generated notice of a NetBSD-current/i386 build failure. The failure occurred on babylon5.netbsd.org, a NetBSD/amd64 host, using sources from CVS date 2020.01.14.16.48.18. An extract from the build.sh output follows: /tmp/bracket/build/2020.01.14.16.48.18-i386/tools/bin/i486--netbsdelf-gcc -msoft-float -mno-mmx -mno-sse -mno-avx -mindirect-branch=thunk -mindirect-branch-register -ffreestanding -fno-zero-initialized-in-bss -fno-delete-null-pointer-checks -O2 -fno-omit-frame-pointer -fstack-protector -Wstack-protector --param ssp-buffer-size=1 -fno-strict-aliasing -fno-common -std=gnu99 -Werror -Wall -Wno-main -Wno-format-zero-length -Wpointer-arith -Wmissing-prototypes -Wstrict-prototypes -Wold-style-definition -Wswitch -Wshadow -Wcast-qual -Wwrite-strings -Wno-unreachable-code -Wno-pointer-sign -Wno-attributes -Wextra -Wno-unused-parameter -Wold-style-definition -Wno-sign-compare --sysroot=/tmp/bracket/build/2020.01.14.16.48.18-i386/destdir -Di386 -I. -I/tmp/bracket/build/2020.01.14.16.48.18-i386/src/sys/external/bsd/acpica/dist -I/tmp/bracket/build/2020.01.14.16.48.18-i386/src/sys/external/bsd/libnv/dist -I/tmp/bracket/build/2020.01.14.16.48.18-i386/src/sys/../common/lib/libx86emu -I/tmp/bra cket/build/2020.01.14.16.48.18-i386/src/sys/../common/lib/libc/misc -I/tmp/bracket/build/2020.01.14.16.48.18-i386/src/sys/../common/include -I/tmp/bracket/build/2020.01.14.16.48.18-i386/src/sys/arch -I/tmp/bracket/build/2020.01.14.16.48.18-i386/src/sys -nostdinc -DCOMPAT_UTILS -DDIAGNOSTIC -DCOMPAT_44 -D_KERNEL -D_KERNEL_OPT -std=gnu99 -I/tmp/bracket/build/2020.01.14.16.48.18-i386/src/sys/lib/libkern/../../../common/lib/libc/quad -I/tmp/bracket/build/2020.01.14.16.48.18-i386/src/sys/lib/libkern/../../../common/lib/libc/string -I/tmp/bracket/build/2020.01.14.16.48.18-i386/src/sys/lib/libkern/../../../common/lib/libc/arch/i386/string -D_FORTIFY_SOURCE=2 -I/tmp/bracket/build/2020.01.14.16.48.18-i386/src/sys/external/isc/atheros_hal/dist -I/tmp/bracket/build/2020.01.14.16.48.18-i386/src/sys/external/isc/atheros_hal/ic -I/tmp/bracket/build/2020.01.14.16.48.18-i386/src/sys/../common/include -I/tmp/bracket/build/2020.01.14.16.48.18-i386/src/sys/external/bsd/libnv/dist -I/tmp/bracket/build/ 2020.01.14.16.48.18-i386/src/sys/external/bsd/acpica/dist--- kern-LEGACY --- sd/drm2/include -I/tmp/bracket/build/2020.01.14.16.48.18-i386/src/sys/external/bsd/drm2/include -I/tmp/bracket/build/2020.01.14.16.48.18-i386/src/sys/external/bsd/drm2/include/drm -I/tmp/bracket/build/2020.01.14.16.48.18-i386/src/sys/external/bsd/common/include -I/tmp/bracket/build/2020.01.14.16.48.18-i386/src/sys/external/bsd/drm2/dist/include -I/tmp/bracket/build/2020.01.14.16.48.18-i386/src/sys/external/bsd/drm2/dist/include/drm -I/tmp/bracket/build/2020.01.14.16.48.18-i386/src/sys/external/bsd/drm2/dist/uapi -I/tmp/bracket/build/2020.01.14.16.48.18-i386/src/sys/external/bsd/drm2/dist -D__KERNEL__ -DCONFIG_BACKLIGHT_CLASS_DEVICE=0 -DCONFIG_BACKLIGHT_CLASS_DEVICE_MODULE=0 -DCONFIG_DRM_FBDEV_EMULATION=1 -DCONFIG_FB=0 -I/tmp/bracket/build/2020.01.14.16.48.18-i386/src/sys/../common/include -I/tmp/bracket/build/2020.01.14.16.48.18-i386/src/sys/external/bsd/libnv/dist -I/tmp/bracket/build/2020.01.14.16.48.18-i386/src/sys/external/bsd/drm2/i915drm -I/tmp/bracket/build/2020.01.14.16.4 8.18-i386/src/sys/external/bsd/drm2/dist/drm/i915 -DCONFIG_DRM_I915_FBDEV=1 -DCONFIG_DRM_I915_PRELIMINARY_HW_SUPPORT=0 -DCONFIG_DRM_FBDEV_EMULATION=1 -I/tmp/bracket/build/2020.01.14.16.48.18-i386/src/sys/external/bsd/drm2/include/radeon -I/tmp/bracket/build/2020.01.14.16.48.18-i386/src/sys/external/bsd/drm2/radeon -I/tmp/bracket/build/2020.01.14.16.48.18-i386/src/sys/external/bsd/drm2/dist/drm/amd/include -I/tmp/bracket/build/2020.01.14.16.48.18-i386/src/sys/external/bsd/drm2/dist/drm/radeon -I/tmp/bracket/build/2020.01.14.16.48.18-i386/src/sys/external/bsd/drm2/dist/drm/nouveau -I/tmp/bracket/build/2020.01.14.16.48.18-i386/src/sys/external/bsd/drm2/dist/drm/nouveau/include -I/tmp/bracket/build/2020.01.14.16.48.18-i386/src/sys/external/bsd/drm2/dist/drm/nouveau/include/nvkm -I/tmp/bracket/build/2020.01.14.16.48.18-i386/src/sys/external/bsd/drm2/dist/drm/nouveau/nvkm -I/tmp/bracket/build/2020.01.14.16.48.18-i386/src/sys/external/bsd/drm2/nouveau -DCONFIG_NOUVEAU_DEBUG=5 -DCONFIG_NOUV EAU_DEBUG_DEFAULT=3 -I/tmp/bracket/build/2020.01.14.16.48.18-i386/src/sys/external/bsd/acpica/dist/include -c /tmp/bracket/build/2020.01.14.16.48.18-i386/src/sys/arch/x86/pci/dwiic_pci.c -o dwiic_pci.o --- kern-INSTALL --- --- piixpm.o --- /tmp/bracket/build/2020.01.14.16.48.18-i386/src/sys/dev/pci/piixpm.c: In function 'piixpm_i2c_sb800_release_bus': /tmp/bracket/build/2020.01.14.16.48.18-i386/src/sys/dev/pci/piixpm.c:566:10: error: 'AMDFCH41_SMBUS_PORTMASK' undeclared (first use in this function); did you mean 'AMDFCH41_SMBUS_EN'? mask = AMDFCH41_SMBUS_PORTMASK;
Re: userland build failure in libgomp
Riccardo Mottola wrote: >I confirm the peristent build failure, even if starting totally from >scratch (clean obj dir) and no -u flag. >Built tools first, then distribution. Same error, on amd64 > >could it be that the combination >MKLLVM = no >HAVE_LLVM=no >MKLLVMRT = no > >is not supported? You could test this by building without those options, you should get a gcc toolchain. I use MKLLVMRT=no for several architectures and did a full build a couple of days ago. You also shouldn't need to build the tools as a separate step, just do a clean build of the distribution target. Delete the old tools first.
Re: userland build failure in libgomp
Hi all!
I confirm the peristent build failure, even if starting totally from
scratch (clean obj dir) and no -u flag.
Built tools first, then distribution. Same error, on amd64
could it be that the combination
MKLLVM = no
HAVE_LLVM=no
MKLLVMRT = no
is not supported?
the error is:
# compile libgomp/oacc-init.o
/usr/src/obj/tooldir.NetBSD-9.99.34-amd64/bin/x86_64--netbsd-clang -O2
-march=core2 -pthread -std=gnu99 -Wno-sign-compare
-Wno-pointer-sign -Wall -Wstrict-prototypes -Wmissing-prototypes
-Wpointer-arith -Wno-sign-compare-Werror -Wno-conversion -fPIE
-Wno-stack-protector -Wno-missing-prototypes
--sysroot=/usr/src/obj/destdir.amd64 -DHAVE_CONFIG_H
-I/usr/src/external/gpl3/gcc/dist/libgomp
-I/usr/src/external/gpl3/gcc/dist/libgomp/config/posix
-I/usr/src/external/gpl3/gcc/dist/libgcc
-I/usr/src/external/gpl3/gcc/dist/include
-I/usr/src/external/gpl3/gcc/lib/libgomp/arch/x86_64 -c
/usr/src/external/gpl3/gcc/dist/libgomp/oacc-init.c -o oacc-init.o
/usr/src/external/gpl3/gcc/dist/libgomp/oacc-init.c:632:21: error:
unknown attribute '__optimize__' ignored
[-Werror,-Wunknown-attributes]
int __attribute__ ((__optimize__ ("O2")))
^
/usr/src/external/gpl3/gcc/dist/libgomp/oacc-init.c:635:10: error: use
of unknown builtin '__builtin_acc_on_device'
[-Wimplicit-function-declaration]
return __builtin_acc_on_device (dev);
so it looks clang is being executed, inside the tooldir freshly built!
Riccardo
Riccardo Mottola wrote:
Hi List!
Yesterday, I did a new CVS update. I did rebuild tools and userland.
I ad mit, to save some time, I used the "-u" update flag. The issue came
up again however.
I will try today again, without an update build.
Re: net/net-snmp build failure on 9.99.37
On Tue, 14 Jan 2020 at 18:28, Greg Troxel wrote: > > This appears to be a broken tar issue surounding hardlinks and Christos > has backed it out. So perhaps update and rebuild and try again. I vaguely remember similar discussion sometimes ago. > > I can see why you refer to 9.33.37 as a version of NetBSD, but really it > is not a name for a specific version. That last number is increased > when there is an internal ABI change, but many other things happen > within the operating system that do not change that version number. So > it is probably best to give the time at which you updated. I understand; that bsd-own.mk change has happened in the interval between my last 9.99.36 and first 9.99.37 build; it is not related to the reason the bump to .37 was done . > > > Thanks, Chavdar --
Re: net/net-snmp build failure on 9.99.37
This appears to be a broken tar issue surounding hardlinks and Christos has backed it out. So perhaps update and rebuild and try again. I can see why you refer to 9.33.37 as a version of NetBSD, but really it is not a name for a specific version. That last number is increased when there is an internal ABI change, but many other things happen within the operating system that do not change that version number. So it is probably best to give the time at which you updated.
Re: net/net-snmp build failure on 9.99.37
On Tue, 14 Jan 2020 at 15:43, Patrick Welche wrote: > > On Tue, Jan 14, 2020 at 03:20:46PM +, Chavdar Ivanov wrote: > > To complete the analysis, I tried to upgrade a 9.99.36 system to > > 9.99.37 by booting off the ISO file I previously used for the clean > > installation described above. > > > > It failed in a similar was as with sysupgrade : > > > > ls -l /sbin /bin /usr/sbin /usr/bin | egrep 'wheel[ \t]*0' | wc -l > > 91 > > (the clean installation returns 0). > > > > It gets less clear after this... But at the moment I can't see how to > > upgrade to 9.99.37. > > I just hit the same thing without using sysupgrade. > > Essentially tar built in I'm not sure which window can't unpack symlinks. > > On a couple of days old -current/amd64 > > grab base.tar.xz > tar -tzvf base.tar.xz | grep rebootsee that it's a symlink > tar -xzpvf base.tar.xz -C /see that /sbin/reboot is a zero > length file > cd / && pax -r -v -z -pe -f base.tar.xzsee that /sbin/reboot is fine Prior to 9.99.37 we have: $ ls -li /bin/tar /bin/pax /bin/cpio 13081639 -r-xr-xr-x 3 root wheel 166288 Jan 12 17:00 /bin/cpio 13081639 -r-xr-xr-x 3 root wheel 166288 Jan 12 17:00 /bin/pax 13081639 -r-xr-xr-x 3 root wheel 166288 Jan 12 17:00 /bin/tar Hardlinks; in 9.99.37 we have: ~ ls -li /bin/tar /bin/cpio /bin/pax 181767 -r-xr-xr-x 1 root wheel 50288 Jan 14 03:10 /bin/cpio 181784 -r-xr-xr-x 1 root wheel 166288 Jan 14 03:57 /bin/pax 181796 -r-xr-xr-x 1 root wheel 82352 Jan 14 03:10 /bin/tar different files, but pax is the same as on 9.99.36, at least sizewise. So the easiest way to sort oneself out of this is to hard-link /bin/pax to the others and carry on the update. > > Oddly - now repeat the tar, and also find that it is fine. > > So the work around seems to be "use pax". The surpise is that then tar is > fixed. > > > Cheers, > > Patrick --
Re: net/net-snmp build failure on 9.99.37
On Tue, 14 Jan 2020 at 15:43, Patrick Welche wrote: > > On Tue, Jan 14, 2020 at 03:20:46PM +, Chavdar Ivanov wrote: > > To complete the analysis, I tried to upgrade a 9.99.36 system to > > 9.99.37 by booting off the ISO file I previously used for the clean > > installation described above. > > > > It failed in a similar was as with sysupgrade : > > > > ls -l /sbin /bin /usr/sbin /usr/bin | egrep 'wheel[ \t]*0' | wc -l > > 91 > > (the clean installation returns 0). > > > > It gets less clear after this... But at the moment I can't see how to > > upgrade to 9.99.37. > > I just hit the same thing without using sysupgrade. > > Essentially tar built in I'm not sure which window can't unpack symlinks. > > On a couple of days old -current/amd64 > > grab base.tar.xz > tar -tzvf base.tar.xz | grep rebootsee that it's a symlink > tar -xzpvf base.tar.xz -C /see that /sbin/reboot is a zero > length file > cd / && pax -r -v -z -pe -f base.tar.xzsee that /sbin/reboot is fine > > Oddly - now repeat the tar, and also find that it is fine. > > So the work around seems to be "use pax". The surpise is that then tar is > fixed. And I find the following: (on the system with many - 92 - zero length files in *bin directories): nbuild# ls -l bin/test -r-xr-xr-x 1 root wheel 0 Jan 14 03:57 bin/test test is zero length nbuild# /bin/tar xopf ../base.tar.xz ./bin extracting the whole ./bin over *existing* directory nbuild# ls -l bin/test -r-xr-xr-x 1 root wheel 0 Jan 14 03:57 bin/test # test is still zero length nbuild# mv bin bin.old # hiding the whole bin directory nbuild# /bin/tar xopf ../base.tar.xz ./bin ksh: /bin/tar: not found # me stpid nbuild# /bin.old/tar xopf ../base.tar.xz ./bin # extracting in a fresh place nbuild# ls -l bin/test -r-xr-xr-x 2 root wheel 18808 Jan 14 03:57 bin/test# now test is ok. So there is apparently some bsdtar bug here, > > > Cheers, > > Patrick --
Re: net/net-snmp build failure on 9.99.37
On Tue, Jan 14, 2020 at 03:20:46PM +, Chavdar Ivanov wrote: > To complete the analysis, I tried to upgrade a 9.99.36 system to > 9.99.37 by booting off the ISO file I previously used for the clean > installation described above. > > It failed in a similar was as with sysupgrade : > > ls -l /sbin /bin /usr/sbin /usr/bin | egrep 'wheel[ \t]*0' | wc -l > 91 > (the clean installation returns 0). > > It gets less clear after this... But at the moment I can't see how to > upgrade to 9.99.37. I just hit the same thing without using sysupgrade. Essentially tar built in I'm not sure which window can't unpack symlinks. On a couple of days old -current/amd64 grab base.tar.xz tar -tzvf base.tar.xz | grep rebootsee that it's a symlink tar -xzpvf base.tar.xz -C /see that /sbin/reboot is a zero length file cd / && pax -r -v -z -pe -f base.tar.xzsee that /sbin/reboot is fine Oddly - now repeat the tar, and also find that it is fine. So the work around seems to be "use pax". The surpise is that then tar is fixed. Cheers, Patrick
Re: net/net-snmp build failure on 9.99.37
On Tue, 14 Jan 2020 at 14:20, Chavdar Ivanov wrote:
>
> On Tue, 14 Jan 2020 at 13:41, Patrick Welche wrote:
> >
> > On Tue, Jan 14, 2020 at 01:28:15PM +, Chavdar Ivanov wrote:
> > > Clean installation from the same ISO file is fine, so it probably was
> > > sysupgrade failure induced by the different tar.
> >
> > You did quite some detective work! (Yes, I don't use sysupgrade...)
>
> It's one of the things you get accustomed to, I have been using it for
> ages without many problems; occasionally they do occur, e.g. in
> September some bump in the shared libraries stopped the final
> etcupdate stages from completing properly; in that case it was enough
> to repeat the process and all was well. In this case I probably will
> update manually.
>
> BTW in case anybody is interested, I tried the abovementioned ISO -
> 9.99.37 - to install as a guest under XCP-NG, which one should have
> been aware by this time is the fully functional free version of what
> used to be XenServer. Using UEFI mode I was even able to get X running
> with the modesetting driver (obviously the DRI{2} bits do not load).
> The only problem so far is with the mouse; the cursor somehow only
> goes along the edges of the screen in a rather unpredictable manner -
> both on the Xorchestra console and the Xcp-ng center.
To complete the analysis, I tried to upgrade a 9.99.36 system to
9.99.37 by booting off the ISO file I previously used for the clean
installation described above.
It failed in a similar was as with sysupgrade :
ls -l /sbin /bin /usr/sbin /usr/bin | egrep 'wheel[ \t]*0' | wc -l
91
(the clean installation returns 0).
It gets less clear after this... But at the moment I can't see how to
upgrade to 9.99.37.
>
>
> >
> >
> > Cheers,
> >
> > Patrick
>
>
>
> --
>
--
Re: net/net-snmp build failure on 9.99.37
On Tue, 14 Jan 2020 at 13:41, Patrick Welche wrote:
>
> On Tue, Jan 14, 2020 at 01:28:15PM +, Chavdar Ivanov wrote:
> > Clean installation from the same ISO file is fine, so it probably was
> > sysupgrade failure induced by the different tar.
>
> You did quite some detective work! (Yes, I don't use sysupgrade...)
It's one of the things you get accustomed to, I have been using it for
ages without many problems; occasionally they do occur, e.g. in
September some bump in the shared libraries stopped the final
etcupdate stages from completing properly; in that case it was enough
to repeat the process and all was well. In this case I probably will
update manually.
BTW in case anybody is interested, I tried the abovementioned ISO -
9.99.37 - to install as a guest under XCP-NG, which one should have
been aware by this time is the fully functional free version of what
used to be XenServer. Using UEFI mode I was even able to get X running
with the modesetting driver (obviously the DRI{2} bits do not load).
The only problem so far is with the mouse; the cursor somehow only
goes along the edges of the screen in a rather unpredictable manner -
both on the Xorchestra console and the Xcp-ng center.
>
>
> Cheers,
>
> Patrick
--
Re: net/net-snmp build failure on 9.99.37
On Tue, 14 Jan 2020 at 12:45, Chavdar Ivanov wrote: > > I was able to downgrade to 9.99.36 using sysupgrade after linking > /usr/bin/tar to /usr/pkg/bin/bsdtar, as /bin/tar /bin/pax and > /bin/cpio were also of length 0 on my 9.99.37... > > Unintended consequences. > > On Tue, 14 Jan 2020 at 12:40, Chavdar Ivanov wrote: > > > > On Tue, 14 Jan 2020 at 12:29, Patrick Welche wrote: > > > > > > On Tue, Jan 14, 2020 at 12:22:26PM +, Chavdar Ivanov wrote: > > > > There is no point testing. ktruss gcc on 9.99.37 exits after onlly 130 > > > > lines... > > > > > > FWIW, an update build.sh from yesterday, so 9.99.37/amd64, works for me: > > > $ ls -l `which gcc` > > > -r-xr-xr-x 2 root wheel 1045384 Jan 13 17:43 /usr/bin/gcc > > > $ gcc --version > > > gcc (nb1 20190930) 8.3.0 Clean installation from the same ISO file is fine, so it probably was sysupgrade failure induced by the different tar. > > > > I suspect it is the switch to bsdtar - bsd.own.mk change - combined > > with the fact that we both used sysutils/sysupgrade to get to 9.00.37. > > > > cvs diff -u -r 1.1169 -r 1.1170 bsd.own.mk > >] 12:30 PM > > Index: bsd.own.mk > > === > > RCS file: /cvsroot/src/share/mk/bsd.own.mk,v > > retrieving revision 1.1169 > > retrieving revision 1.1170 > > diff -u -r1.1169 -r1.1170 > > --- bsd.own.mk 14 Dec 2019 10:59:25 - 1.1169 > > +++ bsd.own.mk 12 Jan 2020 16:11:51 - 1.1170 > > @@ -1,4 +1,4 @@ > > -# $NetBSD: bsd.own.mk,v 1.1169 2019/12/14 10:59:25 mrg Exp $ > > +# $NetBSD: bsd.own.mk,v 1.1170 2020/01/12 16:11:51 christos Exp $ > > > > # This needs to be before bsd.init.mk > > .if defined(BSD_MK_COMPAT_FILE) > > @@ -1082,6 +1082,7 @@ > > _MKVARS.yes= \ > > MKATF \ > > MKBINUTILS \ > > + MKBSDTAR \ > > MKCOMPLEX MKCVS MKCXX \ > > MKDOC MKDTC \ > > MKDYNAMICROOT \ > > @@ -1205,7 +1206,6 @@ > > MKARGON2 \ > > MKARZERO \ > > MKBSDGREP \ > > - MKBSDTAR \ > > MKCATPAGES MKCOMPATTESTS MKCOMPATX11 MKCTF \ > > MKDEBUG MKDEBUGLIB MKDTRACE \ > > MKEXTSRC \ > > > > (moves MKBSDTAR from those predefined as NO to YES). > > > > > ... > > > > > > > > > Cheers, > > > > > > Patrick > > > > > > > > -- > > > > > > -- > --
Re: net/net-snmp build failure on 9.99.37
I was able to downgrade to 9.99.36 using sysupgrade after linking /usr/bin/tar to /usr/pkg/bin/bsdtar, as /bin/tar /bin/pax and /bin/cpio were also of length 0 on my 9.99.37... Unintended consequences. On Tue, 14 Jan 2020 at 12:40, Chavdar Ivanov wrote: > > On Tue, 14 Jan 2020 at 12:29, Patrick Welche wrote: > > > > On Tue, Jan 14, 2020 at 12:22:26PM +, Chavdar Ivanov wrote: > > > There is no point testing. ktruss gcc on 9.99.37 exits after onlly 130 > > > lines... > > > > FWIW, an update build.sh from yesterday, so 9.99.37/amd64, works for me: > > $ ls -l `which gcc` > > -r-xr-xr-x 2 root wheel 1045384 Jan 13 17:43 /usr/bin/gcc > > $ gcc --version > > gcc (nb1 20190930) 8.3.0 > > I suspect it is the switch to bsdtar - bsd.own.mk change - combined > with the fact that we both used sysutils/sysupgrade to get to 9.00.37. > > cvs diff -u -r 1.1169 -r 1.1170 bsd.own.mk >] 12:30 PM > Index: bsd.own.mk > === > RCS file: /cvsroot/src/share/mk/bsd.own.mk,v > retrieving revision 1.1169 > retrieving revision 1.1170 > diff -u -r1.1169 -r1.1170 > --- bsd.own.mk 14 Dec 2019 10:59:25 - 1.1169 > +++ bsd.own.mk 12 Jan 2020 16:11:51 - 1.1170 > @@ -1,4 +1,4 @@ > -# $NetBSD: bsd.own.mk,v 1.1169 2019/12/14 10:59:25 mrg Exp $ > +# $NetBSD: bsd.own.mk,v 1.1170 2020/01/12 16:11:51 christos Exp $ > > # This needs to be before bsd.init.mk > .if defined(BSD_MK_COMPAT_FILE) > @@ -1082,6 +1082,7 @@ > _MKVARS.yes= \ > MKATF \ > MKBINUTILS \ > + MKBSDTAR \ > MKCOMPLEX MKCVS MKCXX \ > MKDOC MKDTC \ > MKDYNAMICROOT \ > @@ -1205,7 +1206,6 @@ > MKARGON2 \ > MKARZERO \ > MKBSDGREP \ > - MKBSDTAR \ > MKCATPAGES MKCOMPATTESTS MKCOMPATX11 MKCTF \ > MKDEBUG MKDEBUGLIB MKDTRACE \ > MKEXTSRC \ > > (moves MKBSDTAR from those predefined as NO to YES). > > > ... > > > > > > Cheers, > > > > Patrick > > > > -- > --
Re: net/net-snmp build failure on 9.99.37
On Tue, 14 Jan 2020 at 12:29, Patrick Welche wrote: > > On Tue, Jan 14, 2020 at 12:22:26PM +, Chavdar Ivanov wrote: > > There is no point testing. ktruss gcc on 9.99.37 exits after onlly 130 > > lines... > > FWIW, an update build.sh from yesterday, so 9.99.37/amd64, works for me: > $ ls -l `which gcc` > -r-xr-xr-x 2 root wheel 1045384 Jan 13 17:43 /usr/bin/gcc > $ gcc --version > gcc (nb1 20190930) 8.3.0 I suspect it is the switch to bsdtar - bsd.own.mk change - combined with the fact that we both used sysutils/sysupgrade to get to 9.00.37. cvs diff -u -r 1.1169 -r 1.1170 bsd.own.mk ] 12:30 PM Index: bsd.own.mk === RCS file: /cvsroot/src/share/mk/bsd.own.mk,v retrieving revision 1.1169 retrieving revision 1.1170 diff -u -r1.1169 -r1.1170 --- bsd.own.mk 14 Dec 2019 10:59:25 - 1.1169 +++ bsd.own.mk 12 Jan 2020 16:11:51 - 1.1170 @@ -1,4 +1,4 @@ -# $NetBSD: bsd.own.mk,v 1.1169 2019/12/14 10:59:25 mrg Exp $ +# $NetBSD: bsd.own.mk,v 1.1170 2020/01/12 16:11:51 christos Exp $ # This needs to be before bsd.init.mk .if defined(BSD_MK_COMPAT_FILE) @@ -1082,6 +1082,7 @@ _MKVARS.yes= \ MKATF \ MKBINUTILS \ + MKBSDTAR \ MKCOMPLEX MKCVS MKCXX \ MKDOC MKDTC \ MKDYNAMICROOT \ @@ -1205,7 +1206,6 @@ MKARGON2 \ MKARZERO \ MKBSDGREP \ - MKBSDTAR \ MKCATPAGES MKCOMPATTESTS MKCOMPATX11 MKCTF \ MKDEBUG MKDEBUGLIB MKDTRACE \ MKEXTSRC \ (moves MKBSDTAR from those predefined as NO to YES). > ... > > > Cheers, > > Patrick --
Re: net/net-snmp build failure on 9.99.37
On Tue, Jan 14, 2020 at 12:22:26PM +, Chavdar Ivanov wrote: > There is no point testing. ktruss gcc on 9.99.37 exits after onlly 130 > lines... FWIW, an update build.sh from yesterday, so 9.99.37/amd64, works for me: $ ls -l `which gcc` -r-xr-xr-x 2 root wheel 1045384 Jan 13 17:43 /usr/bin/gcc $ gcc --version gcc (nb1 20190930) 8.3.0 ... Cheers, Patrick
Re: net/net-snmp build failure on 9.99.37
On Tue, 14 Jan 2020 at 12:22, Rares Aioanei wrote: > > Meanwhile, I found that at least /usr/bin/gcc and /sbin/reboot are > empty files. I upgraded to 9.99.37 via "sysupgrade auto $URL". I do essentially the same, but with self-built versions. In my case /sbin/reboot appears OK, but /usr/bin/lex is also of length 0. I guess bad update moment. Back to downgrading. > > On Tue, Jan 14, 2020 at 2:18 PM Chavdar Ivanov wrote: > > > > On Tue, 14 Jan 2020 at 11:57, Rares Aioanei wrote: > > > > > > Unsure if related or not, but I updated pkgsrc, then ran > > > "pkg_rolling-replace -u" . Suddenly gcc3 became a dependency to > > > py-setuptools, and gcc3 needs binutils, which fails at the configure > > > step with "C compiler cannot create executables". I switched to > > > another terminal, wrote a short hello world in C and indeed, gcc > > > (/usr/bin/gcc) does nothing, not even an error. Even "gcc -v" does > > > nothing, and afterwards, "echo $?" returns 0. FWIW, I rebooted, to no > > > avail. Also running 9.99.37, amd64, VBox guest, Linux host. > > > > That confirms my suspicions as well. At present I am updating an > > XCP-NG guest, which was running 9.99.26; I updated first pkgsrc and > > confirmed everything works as expected. Next I am bringing it up to > > 9.99.36, testing and finally will do the same with 9.99.37. > > > > > > > > On Tue, Jan 14, 2020 at 1:06 PM Chavdar Ivanov wrote: > > > > > > > > On Tue, 14 Jan 2020 at 10:52, Chavdar Ivanov wrote: > > > > > > > > > > Hi, > > > > > > > > > > I bumped up my development machine to 9.99.37; after that I usually > > > > > rebuild pkgtools/osabi and all that depend on it; this usually does > > > > > not cause problems (with the exception of lsof, which I had installed > > > > > some times ago and which does not build any more at all, as it is > > > > > using apparently internal to the kernel interfaces). > > > > > > > > > > This time it failed to build net/net-snmp, as it for some reason > > > > > decided that it has a build dependency of devel/binutils from > > > > > lang/gcc3 (which I do not have built and installed so far).;binutils > > > > > fails to build at the extract stage - as it claims built-in dependency > > > > > on itself: > > > > > root➜pkgsrc/devel/binutils» make clean > > > > > [10[6/1788] > > > > > ===> Cleaning for binutils-2.26.1nb1 > > > > > root➜pkgsrc/devel/binutils» make extract > > > > > [10:18:31] > > > > > => Bootstrap dependency digest>=20010302: found digest-20190127 > > > > > => Checksum SHA1 OK for binutils-2.26.1.tar.bz2 > > > > > => Checksum RMD160 OK for binutils-2.26.1.tar.bz2 > > > > > => Checksum SHA512 OK for binutils-2.26.1.tar.bz2 > > > > > ===> Installing dependencies for binutils-2.26.1nb1 > > > > > => Tool dependency libtool-base>=2.4.2nb9: found libtool-base-2.4.6nb2 > > > > > => Tool dependency bison>=1.0: found bison-3.4.2 > > > > > => Tool dependency gmake>=3.81: found gmake-4.2.1nb1 > > > > > => Build dependency cwrappers>=20150314: found cwrappers-20180325 > > > > > => Full dependency gcc3-c>=3.3.5nb1: NOT found > > > > > => Verifying reinstall for ../../lang/gcc3-c > > > > > => Bootstrap dependency digest>=20010302: found digest-20190127 > > > > > => Checksum SHA1 OK for gcc-3.3.6.tar.bz2 > > > > > => Checksum RMD160 OK for gcc-3.3.6.tar.bz2 > > > > > => Checksum SHA512 OK for gcc-3.3.6.tar.bz2 > > > > > ===> Installing dependencies for gcc3-c-3.3.6nb1 > > > > > => Tool dependency ccache-[0-9]*: found ccache-3.7.6 > > > > > => Tool dependency gmake>=3.81: found gmake-4.2.1nb1 > > > > > => Build dependency cwrappers>=20150314: found cwrappers-20180325 > > > > > => Full dependency binutils>=2.13.2.1: NOT found > > > > > => Verifying reinstall for ../../devel/binutils > > > > > ERROR: This package has set PKG_FAIL_REASON: > > > > > ERROR: Circular dependency detected > > > > > *** Error code 1 > > > > > > > > > > Stop. > > > > > make[2]: stopped in /usr/pkgsrc/devel/binutils > > > > > *** Error code 1 > > > > > > > > > > I ran 'make -dA'; at one stage it sets _NEED_GCC3. > > > > > > > > > > Anyway; this hasn't happen before; the pkgsrc tree was updated on the > > > > > 5th of January and pkg_rolling-replace was carried out (with a number > > > > > of failures, but overall OK). The last successful net-snmp build was > > > > > on the 11th of January under 9.99.36: > > > > > > > > > > # ls -l /usr/pkgsrc/packages/All/net-snmp-5.7.3nb12.tgz > > > > > -rw-r--r-- 1 root wheel 4065659 Jan 11 23:19 > > > > > /usr/pkgsrc/packages/All/net-snmp-5.7.3nb12.tgz > > > > > > > > > > > > > I was a bit too quick to hit 'return' on this mail. I can't build > > > > *anything* now under 9.99.37; to be sure, I updated pkgsrc and hid the > > > > present /etc/mk.conf. > > > > > > > > Any build using gcc tries to use gcc3 and then fails with the circular > > > > dependency of devel/binutils. > > > > > > > > > Chavdar >
Re: net/net-snmp build failure on 9.99.37
On Tue, 14 Jan 2020 at 12:18, Chavdar Ivanov wrote: > > On Tue, 14 Jan 2020 at 11:57, Rares Aioanei wrote: > > > > Unsure if related or not, but I updated pkgsrc, then ran > > "pkg_rolling-replace -u" . Suddenly gcc3 became a dependency to > > py-setuptools, and gcc3 needs binutils, which fails at the configure > > step with "C compiler cannot create executables". I switched to > > another terminal, wrote a short hello world in C and indeed, gcc > > (/usr/bin/gcc) does nothing, not even an error. Even "gcc -v" does > > nothing, and afterwards, "echo $?" returns 0. FWIW, I rebooted, to no > > avail. Also running 9.99.37, amd64, VBox guest, Linux host. > > That confirms my suspicions as well. At present I am updating an > XCP-NG guest, which was running 9.99.26; I updated first pkgsrc and > confirmed everything works as expected. Next I am bringing it up to > 9.99.36, testing and finally will do the same with 9.99.37. There is no point testing. ktruss gcc on 9.99.37 exits after onlly 130 lines... I will have to downgrade the machine. > > > > > On Tue, Jan 14, 2020 at 1:06 PM Chavdar Ivanov wrote: > > > > > > On Tue, 14 Jan 2020 at 10:52, Chavdar Ivanov wrote: > > > > > > > > Hi, > > > > > > > > I bumped up my development machine to 9.99.37; after that I usually > > > > rebuild pkgtools/osabi and all that depend on it; this usually does > > > > not cause problems (with the exception of lsof, which I had installed > > > > some times ago and which does not build any more at all, as it is > > > > using apparently internal to the kernel interfaces). > > > > > > > > This time it failed to build net/net-snmp, as it for some reason > > > > decided that it has a build dependency of devel/binutils from > > > > lang/gcc3 (which I do not have built and installed so far).;binutils > > > > fails to build at the extract stage - as it claims built-in dependency > > > > on itself: > > > > root➜pkgsrc/devel/binutils» make clean > > > > [10[6/1788] > > > > ===> Cleaning for binutils-2.26.1nb1 > > > > root➜pkgsrc/devel/binutils» make extract > > > > [10:18:31] > > > > => Bootstrap dependency digest>=20010302: found digest-20190127 > > > > => Checksum SHA1 OK for binutils-2.26.1.tar.bz2 > > > > => Checksum RMD160 OK for binutils-2.26.1.tar.bz2 > > > > => Checksum SHA512 OK for binutils-2.26.1.tar.bz2 > > > > ===> Installing dependencies for binutils-2.26.1nb1 > > > > => Tool dependency libtool-base>=2.4.2nb9: found libtool-base-2.4.6nb2 > > > > => Tool dependency bison>=1.0: found bison-3.4.2 > > > > => Tool dependency gmake>=3.81: found gmake-4.2.1nb1 > > > > => Build dependency cwrappers>=20150314: found cwrappers-20180325 > > > > => Full dependency gcc3-c>=3.3.5nb1: NOT found > > > > => Verifying reinstall for ../../lang/gcc3-c > > > > => Bootstrap dependency digest>=20010302: found digest-20190127 > > > > => Checksum SHA1 OK for gcc-3.3.6.tar.bz2 > > > > => Checksum RMD160 OK for gcc-3.3.6.tar.bz2 > > > > => Checksum SHA512 OK for gcc-3.3.6.tar.bz2 > > > > ===> Installing dependencies for gcc3-c-3.3.6nb1 > > > > => Tool dependency ccache-[0-9]*: found ccache-3.7.6 > > > > => Tool dependency gmake>=3.81: found gmake-4.2.1nb1 > > > > => Build dependency cwrappers>=20150314: found cwrappers-20180325 > > > > => Full dependency binutils>=2.13.2.1: NOT found > > > > => Verifying reinstall for ../../devel/binutils > > > > ERROR: This package has set PKG_FAIL_REASON: > > > > ERROR: Circular dependency detected > > > > *** Error code 1 > > > > > > > > Stop. > > > > make[2]: stopped in /usr/pkgsrc/devel/binutils > > > > *** Error code 1 > > > > > > > > I ran 'make -dA'; at one stage it sets _NEED_GCC3. > > > > > > > > Anyway; this hasn't happen before; the pkgsrc tree was updated on the > > > > 5th of January and pkg_rolling-replace was carried out (with a number > > > > of failures, but overall OK). The last successful net-snmp build was > > > > on the 11th of January under 9.99.36: > > > > > > > > # ls -l /usr/pkgsrc/packages/All/net-snmp-5.7.3nb12.tgz > > > > -rw-r--r-- 1 root wheel 4065659 Jan 11 23:19 > > > > /usr/pkgsrc/packages/All/net-snmp-5.7.3nb12.tgz > > > > > > > > > > I was a bit too quick to hit 'return' on this mail. I can't build > > > *anything* now under 9.99.37; to be sure, I updated pkgsrc and hid the > > > present /etc/mk.conf. > > > > > > Any build using gcc tries to use gcc3 and then fails with the circular > > > dependency of devel/binutils. > > > > > > > Chavdar > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > -- > > > > > > > -- > --
Re: net/net-snmp build failure on 9.99.37
Meanwhile, I found that at least /usr/bin/gcc and /sbin/reboot are empty files. I upgraded to 9.99.37 via "sysupgrade auto $URL". On Tue, Jan 14, 2020 at 2:18 PM Chavdar Ivanov wrote: > > On Tue, 14 Jan 2020 at 11:57, Rares Aioanei wrote: > > > > Unsure if related or not, but I updated pkgsrc, then ran > > "pkg_rolling-replace -u" . Suddenly gcc3 became a dependency to > > py-setuptools, and gcc3 needs binutils, which fails at the configure > > step with "C compiler cannot create executables". I switched to > > another terminal, wrote a short hello world in C and indeed, gcc > > (/usr/bin/gcc) does nothing, not even an error. Even "gcc -v" does > > nothing, and afterwards, "echo $?" returns 0. FWIW, I rebooted, to no > > avail. Also running 9.99.37, amd64, VBox guest, Linux host. > > That confirms my suspicions as well. At present I am updating an > XCP-NG guest, which was running 9.99.26; I updated first pkgsrc and > confirmed everything works as expected. Next I am bringing it up to > 9.99.36, testing and finally will do the same with 9.99.37. > > > > > On Tue, Jan 14, 2020 at 1:06 PM Chavdar Ivanov wrote: > > > > > > On Tue, 14 Jan 2020 at 10:52, Chavdar Ivanov wrote: > > > > > > > > Hi, > > > > > > > > I bumped up my development machine to 9.99.37; after that I usually > > > > rebuild pkgtools/osabi and all that depend on it; this usually does > > > > not cause problems (with the exception of lsof, which I had installed > > > > some times ago and which does not build any more at all, as it is > > > > using apparently internal to the kernel interfaces). > > > > > > > > This time it failed to build net/net-snmp, as it for some reason > > > > decided that it has a build dependency of devel/binutils from > > > > lang/gcc3 (which I do not have built and installed so far).;binutils > > > > fails to build at the extract stage - as it claims built-in dependency > > > > on itself: > > > > root➜pkgsrc/devel/binutils» make clean > > > > [10[6/1788] > > > > ===> Cleaning for binutils-2.26.1nb1 > > > > root➜pkgsrc/devel/binutils» make extract > > > > [10:18:31] > > > > => Bootstrap dependency digest>=20010302: found digest-20190127 > > > > => Checksum SHA1 OK for binutils-2.26.1.tar.bz2 > > > > => Checksum RMD160 OK for binutils-2.26.1.tar.bz2 > > > > => Checksum SHA512 OK for binutils-2.26.1.tar.bz2 > > > > ===> Installing dependencies for binutils-2.26.1nb1 > > > > => Tool dependency libtool-base>=2.4.2nb9: found libtool-base-2.4.6nb2 > > > > => Tool dependency bison>=1.0: found bison-3.4.2 > > > > => Tool dependency gmake>=3.81: found gmake-4.2.1nb1 > > > > => Build dependency cwrappers>=20150314: found cwrappers-20180325 > > > > => Full dependency gcc3-c>=3.3.5nb1: NOT found > > > > => Verifying reinstall for ../../lang/gcc3-c > > > > => Bootstrap dependency digest>=20010302: found digest-20190127 > > > > => Checksum SHA1 OK for gcc-3.3.6.tar.bz2 > > > > => Checksum RMD160 OK for gcc-3.3.6.tar.bz2 > > > > => Checksum SHA512 OK for gcc-3.3.6.tar.bz2 > > > > ===> Installing dependencies for gcc3-c-3.3.6nb1 > > > > => Tool dependency ccache-[0-9]*: found ccache-3.7.6 > > > > => Tool dependency gmake>=3.81: found gmake-4.2.1nb1 > > > > => Build dependency cwrappers>=20150314: found cwrappers-20180325 > > > > => Full dependency binutils>=2.13.2.1: NOT found > > > > => Verifying reinstall for ../../devel/binutils > > > > ERROR: This package has set PKG_FAIL_REASON: > > > > ERROR: Circular dependency detected > > > > *** Error code 1 > > > > > > > > Stop. > > > > make[2]: stopped in /usr/pkgsrc/devel/binutils > > > > *** Error code 1 > > > > > > > > I ran 'make -dA'; at one stage it sets _NEED_GCC3. > > > > > > > > Anyway; this hasn't happen before; the pkgsrc tree was updated on the > > > > 5th of January and pkg_rolling-replace was carried out (with a number > > > > of failures, but overall OK). The last successful net-snmp build was > > > > on the 11th of January under 9.99.36: > > > > > > > > # ls -l /usr/pkgsrc/packages/All/net-snmp-5.7.3nb12.tgz > > > > -rw-r--r-- 1 root wheel 4065659 Jan 11 23:19 > > > > /usr/pkgsrc/packages/All/net-snmp-5.7.3nb12.tgz > > > > > > > > > > I was a bit too quick to hit 'return' on this mail. I can't build > > > *anything* now under 9.99.37; to be sure, I updated pkgsrc and hid the > > > present /etc/mk.conf. > > > > > > Any build using gcc tries to use gcc3 and then fails with the circular > > > dependency of devel/binutils. > > > > > > > Chavdar > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > -- > > > > > > > -- >
Re: net/net-snmp build failure on 9.99.37
On Tue, 14 Jan 2020 at 11:57, Rares Aioanei wrote: > > Unsure if related or not, but I updated pkgsrc, then ran > "pkg_rolling-replace -u" . Suddenly gcc3 became a dependency to > py-setuptools, and gcc3 needs binutils, which fails at the configure > step with "C compiler cannot create executables". I switched to > another terminal, wrote a short hello world in C and indeed, gcc > (/usr/bin/gcc) does nothing, not even an error. Even "gcc -v" does > nothing, and afterwards, "echo $?" returns 0. FWIW, I rebooted, to no > avail. Also running 9.99.37, amd64, VBox guest, Linux host. That confirms my suspicions as well. At present I am updating an XCP-NG guest, which was running 9.99.26; I updated first pkgsrc and confirmed everything works as expected. Next I am bringing it up to 9.99.36, testing and finally will do the same with 9.99.37. > > On Tue, Jan 14, 2020 at 1:06 PM Chavdar Ivanov wrote: > > > > On Tue, 14 Jan 2020 at 10:52, Chavdar Ivanov wrote: > > > > > > Hi, > > > > > > I bumped up my development machine to 9.99.37; after that I usually > > > rebuild pkgtools/osabi and all that depend on it; this usually does > > > not cause problems (with the exception of lsof, which I had installed > > > some times ago and which does not build any more at all, as it is > > > using apparently internal to the kernel interfaces). > > > > > > This time it failed to build net/net-snmp, as it for some reason > > > decided that it has a build dependency of devel/binutils from > > > lang/gcc3 (which I do not have built and installed so far).;binutils > > > fails to build at the extract stage - as it claims built-in dependency > > > on itself: > > > root➜pkgsrc/devel/binutils» make clean > > > [10[6/1788] > > > ===> Cleaning for binutils-2.26.1nb1 > > > root➜pkgsrc/devel/binutils» make extract > > > [10:18:31] > > > => Bootstrap dependency digest>=20010302: found digest-20190127 > > > => Checksum SHA1 OK for binutils-2.26.1.tar.bz2 > > > => Checksum RMD160 OK for binutils-2.26.1.tar.bz2 > > > => Checksum SHA512 OK for binutils-2.26.1.tar.bz2 > > > ===> Installing dependencies for binutils-2.26.1nb1 > > > => Tool dependency libtool-base>=2.4.2nb9: found libtool-base-2.4.6nb2 > > > => Tool dependency bison>=1.0: found bison-3.4.2 > > > => Tool dependency gmake>=3.81: found gmake-4.2.1nb1 > > > => Build dependency cwrappers>=20150314: found cwrappers-20180325 > > > => Full dependency gcc3-c>=3.3.5nb1: NOT found > > > => Verifying reinstall for ../../lang/gcc3-c > > > => Bootstrap dependency digest>=20010302: found digest-20190127 > > > => Checksum SHA1 OK for gcc-3.3.6.tar.bz2 > > > => Checksum RMD160 OK for gcc-3.3.6.tar.bz2 > > > => Checksum SHA512 OK for gcc-3.3.6.tar.bz2 > > > ===> Installing dependencies for gcc3-c-3.3.6nb1 > > > => Tool dependency ccache-[0-9]*: found ccache-3.7.6 > > > => Tool dependency gmake>=3.81: found gmake-4.2.1nb1 > > > => Build dependency cwrappers>=20150314: found cwrappers-20180325 > > > => Full dependency binutils>=2.13.2.1: NOT found > > > => Verifying reinstall for ../../devel/binutils > > > ERROR: This package has set PKG_FAIL_REASON: > > > ERROR: Circular dependency detected > > > *** Error code 1 > > > > > > Stop. > > > make[2]: stopped in /usr/pkgsrc/devel/binutils > > > *** Error code 1 > > > > > > I ran 'make -dA'; at one stage it sets _NEED_GCC3. > > > > > > Anyway; this hasn't happen before; the pkgsrc tree was updated on the > > > 5th of January and pkg_rolling-replace was carried out (with a number > > > of failures, but overall OK). The last successful net-snmp build was > > > on the 11th of January under 9.99.36: > > > > > > # ls -l /usr/pkgsrc/packages/All/net-snmp-5.7.3nb12.tgz > > > -rw-r--r-- 1 root wheel 4065659 Jan 11 23:19 > > > /usr/pkgsrc/packages/All/net-snmp-5.7.3nb12.tgz > > > > > > > I was a bit too quick to hit 'return' on this mail. I can't build > > *anything* now under 9.99.37; to be sure, I updated pkgsrc and hid the > > present /etc/mk.conf. > > > > Any build using gcc tries to use gcc3 and then fails with the circular > > dependency of devel/binutils. > > > > > Chavdar > > > > > > > > > -- > > > > > > > > > > > -- > > --
Re: net/net-snmp build failure on 9.99.37
Unsure if related or not, but I updated pkgsrc, then ran "pkg_rolling-replace -u" . Suddenly gcc3 became a dependency to py-setuptools, and gcc3 needs binutils, which fails at the configure step with "C compiler cannot create executables". I switched to another terminal, wrote a short hello world in C and indeed, gcc (/usr/bin/gcc) does nothing, not even an error. Even "gcc -v" does nothing, and afterwards, "echo $?" returns 0. FWIW, I rebooted, to no avail. Also running 9.99.37, amd64, VBox guest, Linux host. On Tue, Jan 14, 2020 at 1:06 PM Chavdar Ivanov wrote: > > On Tue, 14 Jan 2020 at 10:52, Chavdar Ivanov wrote: > > > > Hi, > > > > I bumped up my development machine to 9.99.37; after that I usually > > rebuild pkgtools/osabi and all that depend on it; this usually does > > not cause problems (with the exception of lsof, which I had installed > > some times ago and which does not build any more at all, as it is > > using apparently internal to the kernel interfaces). > > > > This time it failed to build net/net-snmp, as it for some reason > > decided that it has a build dependency of devel/binutils from > > lang/gcc3 (which I do not have built and installed so far).;binutils > > fails to build at the extract stage - as it claims built-in dependency > > on itself: > > root➜pkgsrc/devel/binutils» make clean > > [10[6/1788] > > ===> Cleaning for binutils-2.26.1nb1 > > root➜pkgsrc/devel/binutils» make extract > > [10:18:31] > > => Bootstrap dependency digest>=20010302: found digest-20190127 > > => Checksum SHA1 OK for binutils-2.26.1.tar.bz2 > > => Checksum RMD160 OK for binutils-2.26.1.tar.bz2 > > => Checksum SHA512 OK for binutils-2.26.1.tar.bz2 > > ===> Installing dependencies for binutils-2.26.1nb1 > > => Tool dependency libtool-base>=2.4.2nb9: found libtool-base-2.4.6nb2 > > => Tool dependency bison>=1.0: found bison-3.4.2 > > => Tool dependency gmake>=3.81: found gmake-4.2.1nb1 > > => Build dependency cwrappers>=20150314: found cwrappers-20180325 > > => Full dependency gcc3-c>=3.3.5nb1: NOT found > > => Verifying reinstall for ../../lang/gcc3-c > > => Bootstrap dependency digest>=20010302: found digest-20190127 > > => Checksum SHA1 OK for gcc-3.3.6.tar.bz2 > > => Checksum RMD160 OK for gcc-3.3.6.tar.bz2 > > => Checksum SHA512 OK for gcc-3.3.6.tar.bz2 > > ===> Installing dependencies for gcc3-c-3.3.6nb1 > > => Tool dependency ccache-[0-9]*: found ccache-3.7.6 > > => Tool dependency gmake>=3.81: found gmake-4.2.1nb1 > > => Build dependency cwrappers>=20150314: found cwrappers-20180325 > > => Full dependency binutils>=2.13.2.1: NOT found > > => Verifying reinstall for ../../devel/binutils > > ERROR: This package has set PKG_FAIL_REASON: > > ERROR: Circular dependency detected > > *** Error code 1 > > > > Stop. > > make[2]: stopped in /usr/pkgsrc/devel/binutils > > *** Error code 1 > > > > I ran 'make -dA'; at one stage it sets _NEED_GCC3. > > > > Anyway; this hasn't happen before; the pkgsrc tree was updated on the > > 5th of January and pkg_rolling-replace was carried out (with a number > > of failures, but overall OK). The last successful net-snmp build was > > on the 11th of January under 9.99.36: > > > > # ls -l /usr/pkgsrc/packages/All/net-snmp-5.7.3nb12.tgz > > -rw-r--r-- 1 root wheel 4065659 Jan 11 23:19 > > /usr/pkgsrc/packages/All/net-snmp-5.7.3nb12.tgz > > > > I was a bit too quick to hit 'return' on this mail. I can't build > *anything* now under 9.99.37; to be sure, I updated pkgsrc and hid the > present /etc/mk.conf. > > Any build using gcc tries to use gcc3 and then fails with the circular > dependency of devel/binutils. > > > Chavdar > > > > > > -- > > > > > > -- >
Re: net/net-snmp build failure on 9.99.37
On Tue, 14 Jan 2020 at 10:52, Chavdar Ivanov wrote: > > Hi, > > I bumped up my development machine to 9.99.37; after that I usually > rebuild pkgtools/osabi and all that depend on it; this usually does > not cause problems (with the exception of lsof, which I had installed > some times ago and which does not build any more at all, as it is > using apparently internal to the kernel interfaces). > > This time it failed to build net/net-snmp, as it for some reason > decided that it has a build dependency of devel/binutils from > lang/gcc3 (which I do not have built and installed so far).;binutils > fails to build at the extract stage - as it claims built-in dependency > on itself: > root➜pkgsrc/devel/binutils» make clean > [10[6/1788] > ===> Cleaning for binutils-2.26.1nb1 > root➜pkgsrc/devel/binutils» make extract > [10:18:31] > => Bootstrap dependency digest>=20010302: found digest-20190127 > => Checksum SHA1 OK for binutils-2.26.1.tar.bz2 > => Checksum RMD160 OK for binutils-2.26.1.tar.bz2 > => Checksum SHA512 OK for binutils-2.26.1.tar.bz2 > ===> Installing dependencies for binutils-2.26.1nb1 > => Tool dependency libtool-base>=2.4.2nb9: found libtool-base-2.4.6nb2 > => Tool dependency bison>=1.0: found bison-3.4.2 > => Tool dependency gmake>=3.81: found gmake-4.2.1nb1 > => Build dependency cwrappers>=20150314: found cwrappers-20180325 > => Full dependency gcc3-c>=3.3.5nb1: NOT found > => Verifying reinstall for ../../lang/gcc3-c > => Bootstrap dependency digest>=20010302: found digest-20190127 > => Checksum SHA1 OK for gcc-3.3.6.tar.bz2 > => Checksum RMD160 OK for gcc-3.3.6.tar.bz2 > => Checksum SHA512 OK for gcc-3.3.6.tar.bz2 > ===> Installing dependencies for gcc3-c-3.3.6nb1 > => Tool dependency ccache-[0-9]*: found ccache-3.7.6 > => Tool dependency gmake>=3.81: found gmake-4.2.1nb1 > => Build dependency cwrappers>=20150314: found cwrappers-20180325 > => Full dependency binutils>=2.13.2.1: NOT found > => Verifying reinstall for ../../devel/binutils > ERROR: This package has set PKG_FAIL_REASON: > ERROR: Circular dependency detected > *** Error code 1 > > Stop. > make[2]: stopped in /usr/pkgsrc/devel/binutils > *** Error code 1 > > I ran 'make -dA'; at one stage it sets _NEED_GCC3. > > Anyway; this hasn't happen before; the pkgsrc tree was updated on the > 5th of January and pkg_rolling-replace was carried out (with a number > of failures, but overall OK). The last successful net-snmp build was > on the 11th of January under 9.99.36: > > # ls -l /usr/pkgsrc/packages/All/net-snmp-5.7.3nb12.tgz > -rw-r--r-- 1 root wheel 4065659 Jan 11 23:19 > /usr/pkgsrc/packages/All/net-snmp-5.7.3nb12.tgz > I was a bit too quick to hit 'return' on this mail. I can't build *anything* now under 9.99.37; to be sure, I updated pkgsrc and hid the present /etc/mk.conf. Any build using gcc tries to use gcc3 and then fails with the circular dependency of devel/binutils. > Chavdar > > > -- > --
net/net-snmp build failure on 9.99.37
Hi, I bumped up my development machine to 9.99.37; after that I usually rebuild pkgtools/osabi and all that depend on it; this usually does not cause problems (with the exception of lsof, which I had installed some times ago and which does not build any more at all, as it is using apparently internal to the kernel interfaces). This time it failed to build net/net-snmp, as it for some reason decided that it has a build dependency of devel/binutils from lang/gcc3 (which I do not have built and installed so far).;binutils fails to build at the extract stage - as it claims built-in dependency on itself: root➜pkgsrc/devel/binutils» make clean [10[6/1788] ===> Cleaning for binutils-2.26.1nb1 root➜pkgsrc/devel/binutils» make extract [10:18:31] => Bootstrap dependency digest>=20010302: found digest-20190127 => Checksum SHA1 OK for binutils-2.26.1.tar.bz2 => Checksum RMD160 OK for binutils-2.26.1.tar.bz2 => Checksum SHA512 OK for binutils-2.26.1.tar.bz2 ===> Installing dependencies for binutils-2.26.1nb1 => Tool dependency libtool-base>=2.4.2nb9: found libtool-base-2.4.6nb2 => Tool dependency bison>=1.0: found bison-3.4.2 => Tool dependency gmake>=3.81: found gmake-4.2.1nb1 => Build dependency cwrappers>=20150314: found cwrappers-20180325 => Full dependency gcc3-c>=3.3.5nb1: NOT found => Verifying reinstall for ../../lang/gcc3-c => Bootstrap dependency digest>=20010302: found digest-20190127 => Checksum SHA1 OK for gcc-3.3.6.tar.bz2 => Checksum RMD160 OK for gcc-3.3.6.tar.bz2 => Checksum SHA512 OK for gcc-3.3.6.tar.bz2 ===> Installing dependencies for gcc3-c-3.3.6nb1 => Tool dependency ccache-[0-9]*: found ccache-3.7.6 => Tool dependency gmake>=3.81: found gmake-4.2.1nb1 => Build dependency cwrappers>=20150314: found cwrappers-20180325 => Full dependency binutils>=2.13.2.1: NOT found => Verifying reinstall for ../../devel/binutils ERROR: This package has set PKG_FAIL_REASON: ERROR: Circular dependency detected *** Error code 1 Stop. make[2]: stopped in /usr/pkgsrc/devel/binutils *** Error code 1 I ran 'make -dA'; at one stage it sets _NEED_GCC3. Anyway; this hasn't happen before; the pkgsrc tree was updated on the 5th of January and pkg_rolling-replace was carried out (with a number of failures, but overall OK). The last successful net-snmp build was on the 11th of January under 9.99.36: # ls -l /usr/pkgsrc/packages/All/net-snmp-5.7.3nb12.tgz -rw-r--r-- 1 root wheel 4065659 Jan 11 23:19 /usr/pkgsrc/packages/All/net-snmp-5.7.3nb12.tgz Chavdar --
Re: userland build failure in libgomp
Hi List!
Yesterday, I did a new CVS update. I did rebuild tools and userland.
I ad mit, to save some time, I used the "-u" update flag. The issue came
up again however.
I will try today again, without an update build.
Riccardo
Riccardo Mottola wrote:
# compile libgomp/oacc-init.o
/usr/src/obj/tooldir.NetBSD-9.99.34-amd64/bin/x86_64--netbsd-clang -O2
-march=core2 -pthread -std=gnu99 -Wno-sign-compare
-Wno-pointer-sign -Wall -Wstrict-prototypes -Wmissing-prototypes
-Wpointer-arith -Wno-sign-compare -Werror -Wno-conversion -fPIE
-Wno-stack-protector -Wno-missing-prototypes
--sysroot=/usr/src/obj/destdir.amd64 -DHAVE_CONFIG_H
-I/usr/src/external/gpl3/gcc/dist/libgomp
-I/usr/src/external/gpl3/gcc/dist/libgomp/config/posix
-I/usr/src/external/gpl3/gcc/dist/libgcc
-I/usr/src/external/gpl3/gcc/dist/include
-I/usr/src/external/gpl3/gcc/lib/libgomp/arch/x86_64 -c
/usr/src/external/gpl3/gcc/dist/libgomp/oacc-init.c -o oacc-init.o
/usr/src/external/gpl3/gcc/dist/libgomp/oacc-init.c:632:21: error:
unknown attribute '__optimize__' ignored
[-Werror,-Wunknown-attributes]
int __attribute__ ((__optimize__ ("O2")))
^
/usr/src/external/gpl3/gcc/dist/libgomp/oacc-init.c:635:10: error: use
of unknown builtin '__builtin_acc_on_device'
[-Wimplicit-function-declaration]
return __builtin_acc_on_device (dev);
^
