Re: build error with MKX11MOTIF=yes in mk.conf
> MKX11MOTIF=yes This is the first time that I hear of this make variable :) I'd file a PR. -- Benny
Re: issues while doing pkgs update on py37-scons
It's a bug in pkg_rr. It gets confused by py27-foo vs. py37-foo etc. Just go to the scons directory and "make package-install PYTHON_VERSION_DEFAULT=37", then restart pkg_rr. On Wed, Jun 26, 2019 at 12:20 PM Riccardo Mottola wrote: > > Hi, > > after having updated userland, I am also updating pkgsrc "from source" > and am running pkg_rolling-replace -uv > > It fails however: > > RR> Building dependency graph for installed packages > RR> Tsorting dependency graph > RR> Selecting serf (www/serf) as next package to replace > RR> Checking if serf has new depends... > RR> serf has the following new depends (need to re-tsort): > rr> [python37 py37-scons] > RR> Tsorting dependency graph > pkg_info: can't find package `py37-scons' > *** Couldn't extract PKGPATH from installed package py37-scons > *** Please read the errors listed above, fix the problem, > *** then re-run pkg_rolling-replace to continue. > disc$ > > > ok.. it says fix the problem, but what is the problem and how do I fix > it? is it a package definition issue or does my pkg database have issues > locally? > > Riccardo -- Benny
Re: problems upgrading go112 (and go111) on NetBSD-8.99.32/amd64
Try rebuilding lang/go14 perhaps? You could also try editing lang/go112/Makefile and setting GOROOT_BOOTSTRAP to /usr/pkg/go111. On Sun, Apr 14, 2019 at 11:26 PM Greg A. Woods wrote: > > So, the following has been happening (and for go111), but I don't > understand the errors, nor have I any clue as to their cause. > > Note that I do have Go 1.11.1 installed and working A-OK on this same > machine, but built against somewhat older OS. > > 13:31 [510] $ go version > go version go1.11.1 netbsd/amd64 > > 13:43 [516] $ /usr/sbin/pkg_info -Q BUILD_HOST go111 > NetBSD future 7.99.34 NetBSD 7.99.34 (XEN3_DOMU) #2: Sun Jul 9 > 15:31:37 PDT 2017 > woods@future:/build/woods/future/current-amd64-amd64-obj/building/work/woods/m-NetBSD-current/sys/arch/amd64/compile/XEN3_DOMU > amd64 > > The host is now a reasonably recent current build (running in a Xen > domU): > > NetBSD future 8.99.32 NetBSD 8.99.32 (XEN3_DOMU) #0: Mon Feb 4 > 15:01:05 PST 2019 > woods@future:/build/woods/future/current-amd64-amd64-obj/building/work/woods/m-NetBSD-current/sys/arch/amd64/compile/XEN3_DOMU > amd64 > > The only thing that I think I've done since upgrading (and upgrading > other packages) is to run "postinstall fix obsolete" to clean out a > bunch of old cruft, most notably old libraries (there was more than a > couple of years of cruft lying about). > > When building the go111 package I encounter very similar errors. > > I'm posting here instead of just submitting a PR or issue on github > because I've been unable to find very much at all relating to these > errors, and I don't know how to diagnose it much deeper. On the other > hand I'll be first to admit that my installation isn't quite standard > (it's definitely not an out-of-the-stock-ISO install), and so I would > really like to dig deeper to find the root cause of the problem as I'm > guessing this is a problem specific to my system and not something more > generic as I've found no other complaints about upgrading Go on > NetBSD/amd64. > > The only thing that's close seems to be about the confusing nature of > some of the linker errors: https://github.com/golang/go/issues/29852 > (but that's unrelated to the root cause of the specific errors I see) > > (Adding '-v' to the "make.bash" invocation doesn't really show anything > more useful or interesting at all, especially not the exact command-line > that's failing.) > > 13:21 [506] $ cd lang/go112 > /usr/pkgsrc/lang/go112 > 13:21 [507] $ make clean > ===> Cleaning for go112-1.12.1nb1 > make13:21 [508] $ make > => Bootstrap dependency digest>=20010302: found digest-20180917 > => Checksum SHA1 OK for go1.12.1.src.tar.gz > => Checksum RMD160 OK for go1.12.1.src.tar.gz > => Checksum SHA512 OK for go1.12.1.src.tar.gz > ===> Installing dependencies for go112-1.12.1nb1 > => Tool dependency gtar-base>=1.13.25: found gtar-base-1.30 > => Build dependency go14-1.4*: found go14-1.4.3nb7 > => Full dependency bash-[0-9]*: found bash-4.4.019 > => Full dependency perl>=5.0: found perl-5.28.0nb2 > ===> Overriding tools for go112-1.12.1nb1 (in > /var/package-obj/woods/lang/go112/work/.tools) > ===> Extracting for go112-1.12.1nb1 > /bin/rm -r -f > /var/package-obj/woods/lang/go112/work/go/test/fixedbugs/issue27836* > ===> Patching for go112-1.12.1nb1 > => Applying pkgsrc patches for go112-1.12.1nb1 > No such line 530 in input file, ignoring > ===> Creating toolchain wrappers for go112-1.12.1nb1 > => Creating AS wrapper: /var/package-obj/woods/lang/go112/work/.wrapper/bin/as > ==> Searching for 'AS' program in: > /var/package-obj/woods/lang/go112/work/.wrapper/bin:/var/package-obj/woods/lang/go112/work/.buildlink/bin:/var/package-obj/woods/lang/go112/work/.gcc/bin:/var/package-obj/woods/lang/go112/work/.tools/bin:/usr/pkg/bin:/home/more/woods/go/bin:/home/more/woods/bin:/usr/bin:/bin:/usr/pkg/bin:/usr/local/bin:/usr/X11R7/bin:/usr/games: > ==> using '/usr/bin/as' for AS wrapper script > => Creating CC wrapper: > /var/package-obj/woods/lang/go112/work/.wrapper/bin/gcc > => Linking CC wrapper: /var/package-obj/woods/lang/go112/work/.wrapper/bin/cc > => Linking CC wrapper: /var/package-obj/woods/lang/go112/work/.wrapper/bin/ada > => Creating CPP wrapper: > /var/package-obj/woods/lang/go112/work/.wrapper/bin/cpp > => Creating CXX wrapper: > /var/package-obj/woods/lang/go112/work/.wrapper/bin/c++ > => Linking CXX wrapper: > /var/package-obj/woods/lang/go112/work/.wrapper/bin/g++ > => Linking CXX wrapper: /var/package-obj/woods/lang/go112/work/.wrapper/bin/CC > => Linking CXX wrapper: > /var/package-obj/woods/lang/go112/work/.wrapper/bin/cxx > => Creating FC wrapper: > /var/package-obj/woods/lang/go112/work/.wrapper/bin/gfortran > => Linking FC wrapper: /var/package-obj/woods/lang/go112/work/.wrapper/bin/f77 > => Linking FC wrapper: /var/package-obj/woods/lang/go112/work/.wrapper/bin/g77 > => Creating LD wrapper: /var/package-obj/woods/lang/go112/work/.wrapper/bin/ld > ==> Searching for
Re: gpt type for zfs?
Can’t you make a pool based on the various do devices? That's what I do. Sevan Janiyan schrieb am Sa. 28. März 2020 um 23:07: > > > On 28/03/2020 21:56, Thomas Klausner wrote: > > Are ZFS users on NetBSD using fbsd-zfs or avoiding gpt? :) > > ZFS doesn't actually care the filesystem time, it's happy to initialise > whatever device node you point at it. I actually partition things up in > sysinst as fat32 partitions. > > Regarding GPT, I connected up a pool which I created on MacOS some years > back to my laptop running 9.99.52, turns out I'd used a GPT scheme, I > couldn't actually import the pool because dk(4) hogs the device. (I > meant to try disabling dk support and retrying but haven't gotten around > to it yet). > > > Sevan > -- Benny
Re: How long to build from source?
The short answer: It depends. Slightly longer: Does the laptop have an SSD, an NVMe disk or a spinning hard drive? Which build options do you choose -- for instance, do you want to build X as well, do you want to build the graphics acceleration stuff (which requires building LLVM IIRC), etc. pp. I think it's going to be a couple hours. You could run the build overnight if you want. On Fri, May 8, 2020 at 1:44 PM nottobay wrote: > > I have a 5 year old a8 laptop. How can I figure out how long compiling the > current source will take? -- Benny
kernel diagnostic assertion "semcnt >= 0" failed
Hi! On a Pinebook Pro running NetBSD 9.99.64 from last Monday (with 9.0 userland), I can reliably make the kernel panic by running "npm install firebase-tools". During the post-install script (I believe it's from the protobufjs NPM package), the kernel does panic: kernel diagnostic assertion "semcnt >= 0" failed: file "/usr/src/sys/kern/kern_uidinfo.c", line 241 (see the photo at https://photos.app.goo.gl/kExDEXGPVmYJAg5f7 for full output) Christos, Sevan suggested that you had touched that code this year. Do you know anything about this? -- Benny
Re: kernel diagnostic assertion "semcnt >= 0" failed
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. -- Benny
Re: usb handling broken with -current
On Thu, 30 Jul 2020, Martin Husemann wrote: On Thu, Jul 30, 2020 at 10:55:05AM -0400, MLH wrote: Jul 29 12:04:59 tiamat /netbsd: [ 96208.8263223] uhub3: autoconfiguration error: device problem, disabling port 2 I see that every now and then on some machines/host controllers. It is not exactly reproducable (for me) though. I see this on the right USB port on the Pinebook Pro every now and then. On the other hand, a USB Wi-Fi in the left port has more device timeouts when in use. -- Benny
Re: [HEADS UP] pkgsrc default database directory changed
On Sat, Dec 5, 2020 at 9:19 PM Thomas Klausner wrote: > http://pkgsrc.org/news/pkgdb-change/ Thanks, that's helpful. I need some more advice. Apparently, I have gotten into a split-brain situation where /usr/sbin/pkg_info and /usr/pkg/sbin/pkg_info show me disjoint sets of packages. I would like to merge the two databases without reinstalling everything, if possible. For pkgdb, I imagine that moving all directories from /var/db/pkg to /usr/pkg/pkgdb should work. But how do I reconcile pkgdb.refcount? -- Benny
Re: cvs update aborted by broken pipe on server
On Tue, Dec 1, 2020 at 1:44 AM Thomas Mueller wrote: > Will this problem be relieved when NetBSD repository switches to mercurial, > and when is the switch to mercurial expected (time estimate)? You can try this out right now and pull the NetBSD source from anonhg.netbsd.org. As an added benefit, it is much quicker to pull updates. -- Benny
Re: HEADS UP: Merging drm update
On Sun, Dec 19, 2021 at 2:35 PM nia wrote:
> > > > I'm planning to merge the drm update this weekend -- a cvs import and
> > > > merge commit, plus about 1300 commits on top of that from the git
> > > > repository.
>
> thank you Maya and Taylor for this monumental effort!
Yes, thank you, this is great!! :)
Meanwhile, I built a new kernel from HEAD on my Pinebook Pro. There is
a bit of a pause when DRM is initialized during boot, and X is
basically unusable -- it takes a minute or so to draw the login screen
(slim).
On the console, I see these:
[ 5.3118036] video0 at uvideo0: Sonix Technology Co., Ltd. (0x0c45)
USB Camera (0x6321), rev 2.00/0.00, addr 3
[ 12.4019283] {drm:netbsd:drm_atomic_helper_wait_for_dependencies+0x788}
*ERROR* [CRTC:38:crtc-1] flip_done timed out
[ 22.4020997] {drm:netbsd:drm_atomic_helper_wait_for_dependencies+0x7f8}
*ERROR* [CONNECTOR:35:eDP-1] flip_done timed out
[ 32.4022714] {drm:netbsd:drm_atomic_helper_wait_for_dependencies+0x824}
*ERROR* [PLANE:36:plane-1] flip_done timed out
[ 32.4022714] warning:
/usr/src/src/sys/external/bsd/drm2/dist/drm/drm_atomic_helper.c:1083:
driver forgot to call drm_crtc_vblank_off()
[ 32.4022714] warning:
/usr/src/src/sys/external/bsd/drm2/dist/drm/drm_atomic_helper.c:2313:
new_crtc_state->event
[ 42.4024501] {drm:netbsd:drm_atomic_helper_wait_for_dependencies+0x788}
*ERROR* [CRTC:38:crtc-1] flip_done timed out
[ 52.4026288] {drm:netbsd:drm_atomic_helper_wait_for_dependencies+0x7f8}
*ERROR* [CONNECTOR:35:eDP-1] flip_done timed out
[ 62.4028023] {drm:netbsd:drm_atomic_helper_wait_for_dependencies+0x824}
*ERROR* [PLANE:36:plane-1] flip_done timed out
[ 62.6028057] warning:
/usr/src/src/sys/external/bsd/drm2/dist/drm/drm_atomic_helper.c:2313:
new_crtc_state->event
[...]
[ 78.4135804] {drm:netbsd:drm_atomic_helper_wait_for_dependencies+0x788}
*ERROR* [CRTC:38:crtc-1] flip_done timed out
[ 88.4140717] {drm:netbsd:drm_atomic_helper_wait_for_dependencies+0x7f8}
*ERROR* [CONNECTOR:35:eDP-1] flip_done timed out
[ 98.4146493] {drm:netbsd:drm_atomic_helper_wait_for_dependencies+0x824}
*ERROR* [PLANE:36:plane-1] flip_done timed out
[ 98.4146493] warning:
/usr/src/src/sys/external/bsd/drm2/dist/drm/drm_atomic_helper.c:2313:
new_crtc_state->event
[ 109.6452513] {drm:netbsd:drm_atomic_helper_wait_for_dependencies+0x788}
*ERROR* [CRTC:38:crtc-1] flip_done timed out
[ 119.6458660] {drm:netbsd:drm_atomic_helper_wait_for_dependencies+0x7f8}
*ERROR* [CONNECTOR:35:eDP-1] flip_done timed out
[ 129.6464760] {drm:netbsd:drm_atomic_helper_wait_for_dependencies+0x824}
*ERROR* [PLANE:36:plane-1] flip_done timed out
[ 129.6464760] warning:
/usr/src/src/sys/external/bsd/drm2/dist/drm/drm_atomic_helper.c:2313:
new_crtc_state->event
This is not working as intended, I suppose? :)
--
Benny
--
Benny
Re: upgrade - no more high res console 9.99.93
On Mon, Feb 14, 2022 at 10:17 AM Riccardo Mottola wrote: > I actually found that the framebuffer is working. It is using a low-res > text, but I see the text is not "scaled" as instead the BIOS console > Is it intentional? can I go hi-res? This sounds like you have the default kernel font, which is either 8x16 pixels (IIRC) or a 2x upscaled version of the same. The kernel chooses the font that gets you the closest to an 80x24 display, so you likely see the upscaled version. I imagine before your upgrade, you had the 8x16 font, which fits a lot (but tiny) text on the screen. The solution is to compile a kernel with a different font, or to load one dynamically. The Spleen fonts look great and are available up to 16x32 -- not scaled up, but pixel-perfect. The Go font is also nice and available in large sizes. -- Benny
Re: NetBSD 10.0 timeline and branch status
> > Unfortunately the additional shared library changes require another round > of package rebuilds from scratch. Everyond building packages against > netbsd-10: please start a new round from scratch. Does that mean the pkgsrc-2023Q2 binary packages for 10_BETA 2 that have been published recently are useless on a new 10_BETA install? That’s too bad. I was looking forward to using those packages to set up some new CI build machines. Should I wait for the 2023Q3 builds then? — Benny
Error (cross) building tools from macOS
Hi! I tried to build NetBSD-current from source on a Macbook Air M2. However, the tools build fails because gcc cannot find zstd while linking. My command line was: % ./build.sh -j 6 -N 1 -U -O ../obj -m evbarm -a aarch64 release Any ideas? The relevant extract from the build log is: clang: warning: argument unused during compilation: '-no-pie' [-Wunused-command-line-argument] clang: warning: argument unused during compilation: '-no-pie' [-Wunused-command-line-argument] Undefined symbols for architecture arm64: "_ZSTD_compress", referenced from: Undefined symbols for architecture arm64: "_ZSTD_compress", referenced from: lto_end_compression(lto_compression_stream*) in libbackend.a(lto-compress.o) lto_end_compression(lto_compression_stream*) in libbackend.a(lto-compress.o) "_ZSTD_compressBound", referenced from: "_ZSTD_compressBound", referenced from: lto_end_compression(lto_compression_stream*) in libbackend.a(lto-compress.o) lto_end_compression(lto_compression_stream*) in libbackend.a(lto-compress.o) "_ZSTD_decompress", referenced from: lto_end_uncompression(lto_compression_stream*, lto_compression) in libbackend.a(lto-compress.o) "_ZSTD_decompress", referenced from: lto_end_uncompression(lto_compression_stream*, lto_compression) in libbackend.a(lto-compress.o) "_ZSTD_getErrorName", referenced from: lto_end_compression(lto_compression_stream*) in libbackend.a(lto-compress.o) lto_end_uncompression(lto_compression_stream*, lto_compression) in libbackend.a(lto-compress.o) "_ZSTD_getErrorName", referenced from: lto_end_compression(lto_compression_stream*) in libbackend.a(lto-compress.o) lto_end_uncompression(lto_compression_stream*, lto_compression) in libbackend.a(lto-compress.o) "_ZSTD_getFrameContentSize", referenced from: "_ZSTD_getFrameContentSize", referenced from: lto_end_uncompression(lto_compression_stream*, lto_compression) in libbackend.a(lto-compress.o) lto_end_uncompression(lto_compression_stream*, lto_compression) in libbackend.a(lto-compress.o) "_ZSTD_isError", referenced from: "_ZSTD_isError", referenced from: lto_end_compression(lto_compression_stream*) in libbackend.a(lto-compress.o) lto_end_uncompression(lto_compression_stream*, lto_compression) in libbackend.a(lto-compress.o) lto_end_compression(lto_compression_stream*) in libbackend.a(lto-compress.o) lto_end_uncompression(lto_compression_stream*, lto_compression) in libbackend.a(lto-compress.o) "_ZSTD_maxCLevel", referenced from: "_ZSTD_maxCLevel", referenced from: lto_end_compression(lto_compression_stream*) in libbackend.a(lto-compress.o) lto_end_compression(lto_compression_stream*) in libbackend.a(lto-compress.o) ld: symbol(s) not found for architecture arm64 clang: error: linker command failed with exit code 1 (use -v to see invocation) nbgmake[1]: *** [lto-dump] Error 1 nbgmake[1]: *** Waiting for unfinished jobs ld: symbol(s) not found for architecture arm64 clang: error: linker command failed with exit code 1 (use -v to see invocation) nbgmake[1]: *** [lto1] Error 1 nbgmake: *** [all-gcc] Error 2 — Benny
Re: updating kernel AND modules
> The NetBSD guide does not talk about kernel modules at all in the > updating section > (https://www.netbsd.org/docs/guide/en/chap-kernel.html, > http://netbsd.org/docs/guide/en/chap-updating.html) > > What is the current best-practice method for that? I do upgrades using sysupgrade. „sysupgrade auto“ does the right thing w.r.t. modules. Otherwise, if you want to reboot with the new kernel, you should run „sysupgrade modules“ before. Building from source, I do ./build.sh kernel=GENERIC modules # install kernel sudo ./build.sh installmodules=/ like the others in the thread suggested. — Benny
Re: Error (cross) building tools from macOS
> Am 19.09.2023 um 06:50 schrieb Lloyd Parkes : > > Maybe ../obj wasn't clean? > > I built with "build.sh -j 6 -U -m evbarm -a aarch64 ... tools" on an M1 Pro > and it completed fine. This was just after doing two Xcode updates and one > macOS Sonoma update today. Thanks for the data point! obj was clean, I had just deleted it before starting the build. However, I found the solution now: I (used to) have a Homebrew for amd64 in /usr/local, which was put there as part of the Apple Game Porting toolkit. This has been the cause of other build failures in the past, since a lot of configure scripts are hard-wired to prefer Homebrew over anything you pass in :( Deleting the Homebrew installation in /usr/local makes the build succeed. — Benny
Re: 10.0 BETA: How to boot using UEFI or grub
On Sun, 25 Dec 2022, Mayuresh wrote: Also, can someone with grub knowhow please advise on the grub error in my last post? Even after insmod of part_gpt, part_bsd, knetbsd says "unknown filesystem" Perhaps you set up 10_BETA with the extended-attribute (ffs2ea) filesystem. This one has a different superblock, so the FFS support in GRUB does not recognize it. I assume the solution is to either get rid of EA support, or patch grub. Has someone sent such a patch upstream? -- Benny
Re: Upgrading a 90s laptop from 5.1 to 10 -- no FD or CDROM
On Thu, Dec 21, 2023 at 4:07 AM wrote: > > > Hi I would say to take to hard drive out and use some other computer to > > install NetBSD 10 on it or use qemu. > > to use qemu install the drive in a linux machine with the linux boot drive > > and run "qemu-system-i386 -cpu pentium -m 64 -cdrom > > NetBSD-10.0rc1-i386.iso -hda /dev/oldlaptopsdisk" > > where NetBSD-10.0rc1-i386.iso is the netbsd install iso and > > "/dev/oldlaptopsdisk" is the device to the old laptops drive > > xu...@sdf.org > > SDF Public Access UNIX System - http://sdf.org There are several more things you could do: 1. Install NetBSD 10 onto a CF card. Update the bootloader on the HDD, then boot with "boot /netbsd10 root=sd0a" or something like that. That will show you if NetBSD 10 works at all. 2. Update the bootloader, install the NetBSD 10 kernel and https://cdn.netbsd.org/pub/NetBSD/NetBSD-10.0_RC1/i386/installation/miniroot/miniroot.kmod. Load the miniroot module from the bootloader, and you will have an installer. You could perhaps use that installer to do the installation as per #1. 3. Instead of gdt's scripts, there is also sysupgrade from pkgsrc. You can do "sysupgrade fetch kernel modules", reboot, then do the other steps. -- Benny
