Re: Difference between i915drm and i915drmkms
Side note: we are collecting all bug reports for the new DRM/KMS that should be fixed before the 10.0 release here: https://wiki.netbsd.org/releng/netbsd-10/ If you know of any other PRs that should be listed there, please let me know. Martin
Re: Very recent NetBSD-current Xorg panic
On Sun, Jan 08, 2023 at 11:28:18AM +, Chavdar Ivanov wrote: > This morning I upgraded the instance to my yesterday's build - as of > 07/01/2023. Now Xorg dumps core as follows: Can you show the output of readelf -l /usr/X11R7/lib/modules/dri/i965_dri.so for the new build? It probably has 4 LOAD sections now, while the old one only had 2. Martin
Re: Very recent NetBSD-current Xorg panic
On Sun, Jan 08, 2023 at 01:15:01PM +, Chavdar Ivanov wrote: > As far as I understand it, there was a change with the dynamic loader at > this time? Yes, and after the ld.elf_so change the default linker options were adjusted, which makes testing this now a bit tricky (you can't just downgrad ld.elf_so). Martin
Re: binutils still failing on amd64
On Mon, Jan 02, 2023 at 12:17:11PM +1100, matthew green wrote: > oh yeah - this is only going to break r/o src tree builds, which is > also something i use as much as possible. Note that the official daily builds also use this (and have been failing since new binutils have been enabled for x86). Martin
Branching for netbsd-10 next week
Hey folks, after the EA changes are in current now and all tests look good, we can finally move on and branch for netbsd-10. Proposed date is next wednsday. We have quite a few things to finish before the final release, but this gets things moving - and I hope it will not take more than three months to get the release out of the door. Before the branch one final issue needs to be decided, and I would like to solicit your feedback on this: With the new EA-enabled variant of FFSv2 (see https://wiki.netbsd.org/features/UFS2ea/ for details) we have the choice to use ACLs and EAs on FFS file systems - which makes them incompatible with all prior releases and other operating systems - or to forbid them. The installer offers upto three options for FFS file systems: - FFSv1, typically only used with bootloaders that did not get FFSv2 support yet or firmware that loads the kernel directly (examples: mac68k or shark). - FFSv2, compatible with older releases but not supporting EAs/ACLs. In read-only mode partly compatible with other operating systems. - FFSv2ea, with full support for EAs and ACLs, but incompatible with all prior NetBSD releases and all other operating systems (the file system superblock has a different magic number, so will be rejected by older code). Currently the installer defaults to creating FFSv2ea file systems for new installations, so if you do intend to share a partition with older NetBSD kernels, be sure to change the filesystem type. This will require a good description in the release notes, and probably more extensions to the wiki page pointed to above. Now the question: should the default install really use this new FFS type, or should it default to plain FFSv2? The change is trivial and from my PoV both choices have serious downsides: - unaware users may install FFSv2ea file systems and later find the need to access them from older NetBSD kernels. "Downgrading" them is quite easy using the ufs2ea-flip tool mentioned in the wiki page, but it is not "plug & play". - if FFSv2ea is not the default, most new installs will create non-EA enabled file systems and - the EAs will not get much testing - packets from pkgsrc (like samba) will continue to have the corresponding options disabled by default - users will have a hard time to find the conversion options later. It is hidden in fsck_ffs(8) and quite simple: after having made sure your bootloader is up to date, boot to single user and run something like: "fsck_ffs -c ea /" So, what should be the default FFS type for new installs in netbsd-10 ? Martin
Re: Branching for netbsd-10 next week
On Fri, Dec 09, 2022 at 10:03:46AM +0100, Matthias Petermann wrote: > compatibility. However, if I understand correctly, this only affects new > installations? If I migrate an existing NetBSD 9 to 10, nothing changes in > the file system format. I.e. as long as I do not actively initite the > migration, I can always access it with NetBSD 9. Correct. No special action is needed if you never run any current kernel on it and file systems will remain plain FFSv2 (and have EAs deactivated). > How likely is it that I > will have to access the filesystem with NetBSD 9 after a new installation of > NetBSD 10? Not very, IMHO. And in the cases you want, there is a path to convert it. As Robert pointed out, you don't need to fiddle with the not-in-tree ufs2ea-flip tool, you can just use "fsck_ffs -c" from your -current (or netbsd-10) install. Martin
Re: /etc/protocols generation
On Thu, Dec 15, 2022 at 08:35:42PM -0500, Jan Schaumann wrote: > This, then would speak in favor of leaving the tools > in pkgsrc. Yes, and stop there. No point in automating more - just like the web files are generated by various tools from the meta-pkgs/netbsd-www pkg, the IANA-derived files can be created by whatever tools hidden in pkgsrc. Then for an update you do: - make sure you have the proper pkg(s) installed - download the latest versions and run the import tools on them - put the results in you source tree - do a full build to verify nothing broke and finaly either - install the resulting etc files on a test machine and run local ATF tests, or - do an Anita test run with the build results to verify there are no regressions. Licenses do not matter here, as long as the commited results are properly licensed. Martin
Re: Branching for netbsd-10 next week
On Thu, Dec 15, 2022 at 07:59:35PM +, Thomas Mueller wrote: > I will want to update my NetBSD installation from 9.99.82 from source > and am inclined toward 10.99.1 rather than 10.0_BETA. I use "cvs up > -dP -A" to update the source on base system and pkgsrc, currently am on > native X. As your current installation is in the "bad" time window, you will have to follow Chuck's guide to safely update: https://wiki.netbsd.org/features/UFS2ea/ But most likely you will decide to no not need EAs and the easy upgrade path is to stay with FFSv2 (i.e.: not run ufs2ea-flip, but only fsck). This is the path we expect most users to take. Martin
Re: Branching for netbsd-10 next week
On Sat, Dec 17, 2022 at 01:41:18AM -0500, Tom Lane wrote: > but I suppose that just reflects a branch existing in the CVS repo. Yes, and also that pullup ticket queues for -10 exist. > I don't see any sign of the branch being supported at, say, > > https://nycdn.netbsd.org/pub/NetBSD-daily/ > http://releng.netbsd.org/cgi-bin/builds.cgi It is building right now (see the second url): Currently building tag: netbsd-10 started at Sat Dec 17 04:29:51 UTC 2022 18 passed so far and when that build is done it will appear in the daily site and there will be armbsd.org images for it. Martin
Re: Branching for netbsd-10 next week
Just to wrap up this thread: - branch will probably happen in the next ~10h - default file system for new installations will be FFSv2 I will update docs and extend the wiki page about FFS2ea to show how to switch later, and also provide installation instructions how to select FFSv2ea right during installation (trivial to do, but better we have something to be found for later searches). Thanks to all the input provided on this list and off list! Martin
Re: 10_BETA: Nice QOL improvements to the installer
On Thu, Dec 22, 2022 at 08:05:02AM +0530, Mayuresh wrote: > Ok. So, it appears the -bios image has become redundant now. Or hasn't it? No, there are BIOSes out there that don't work with the hybrid bootloader. Martin
Re: Branching for netbsd-10 next week
On Sat, Dec 10, 2022 at 03:28:14PM +0100, Reinoud Zandijk wrote: > related, I think we should really iron out all installation issues that > plagued NetBSD before and were scorned on say Slashdot i.e. provide easy > install/live images with a gui installed, with optional extra variants with > say a complete xfce4 one with FF etc. and provide complete installs like the > live CD running as option in sysinst. You are free to work on that any time, but we are not going to delay the branch nor the release for any of that. Instead of (or as first step towards) a xfce4 install image I would prefer to have signed binary packages, but it seems impossible to do with the current pkgsrc infrastructure: https://wiki.netbsd.org/projects/project/Make_signed_binary_pkgs_for_NetBSD_happen/ Martin
Re: HEADS UP: UFS2 extended attribute changes will be committed tomorrow
On Mon, Nov 21, 2022 at 10:10:57PM -0800, Chuck Silvers wrote: > yes, there should be a way to tell sysinst to create UFS2ea rather than UFS2 > (or vice-versa if we make UFS2ea the default in sysinst). this was on my > list of outstanding issues but I think I was thinking that Martin would > take care of it (since he's been the one doing most of the sysinst changes > for a long time now). at any rate, either Martin or I will add this. I will add it soonish. Martin
Re: How to build only one part of NetBSD system
On Thu, Jan 19, 2023 at 05:33:03AM +, Thomas Mueller wrote:
> >From /usr/src/UPDATING,
>
> Recent changes:
> ^^^
>
> 20230112:
> New binutils require an updated ld.elf_so. If you are doing
> (unsupported) in-place self builds (with the -E flag to build.sh),
> make sure to have installed latest ld.elf_so before you rebuild
> userland.
>
> So how do I build /usr/src/lbexec/ld.elf_so preliminary to rebuilding the
> whole NetBSD (current)?
If you are not using something like "build.sh -E -D /" you should ignore that
entry.
> I tried going into libexec/ld.elf_so and running "make install" but that
> didn't work or even come close.
It would be something like:
cd src/libexec/ld.elf_so
${TOOLDIR}/bin/nbmake-${arch} dependall
${TOOLDIR}/bin/nbmake-${arch} install
> I don't think I could have used build.sh for just this component.
Right.
> I had two failed builds of NetBSD-current (10.99.2) before looking more
> closely at /usr/src/UPDATING.
Failed builds how? If you are using "build.sh -u" you may need to manually
clean the object dir for all instances of "binutils" (depending on when
you did the last sucessful build).
A safe way is to completely remove the object dir and build everything from
scratch.
Martin
Re: DNS name resolution not working in 10beta installer?
On Fri, Feb 24, 2023 at 06:22:50PM -0500, Tom Lane wrote: > So it doesn't seem to be a problem with DNS infrastructure, but the > installer doing something wrong. You should be able to test this again easily w/o doing a real installation and gather more information by using the Utility menu/Configure network option right after sysinst starts up. When it doesn't work, please ^Z sysinst and check ifconfig output and cat /etc/resolv.conf. Did you use dhcp auto configuration or entered the settings manualy? Martin
Re: LLONG_MAX not available from c++
On Fri, Mar 31, 2023 at 02:10:46PM +0200, Thomas Klausner wrote: > g++ in -current doesn't get this symbol when you include limits.h > (which lua does, since this is still C code) because of (from > /usr/include/machine/limits.h): > > #if defined(_ISOC99_SOURCE) || (__STDC_VERSION__ - 0) >= 199901L || \ > defined(_NETBSD_SOURCE) > #define ULLONG_MAX 0xULL /* max unsigned long long */ > #define LLONG_MAX 0x7fffLL/* max signed long long */ Which options does it pass to g++ ? For me just invoking "g++" defines __STDC_VERSION__ as 201710L, so should get the symbol: > g++ -dM -E - < /dev/null | fgrep STDC #define __STDC_UTF_16__ 1 #define __STDC_VERSION__ 201710L #define __GNUC_STDC_INLINE__ 1 #define __STDC_UTF_32__ 1 #define __STDC__ 1 #define __STDC_HOSTED__ 1 Martin
Re: LLONG_MAX not available from c++
On Fri, Mar 31, 2023 at 03:30:56PM -, Michael van Elst wrote: > There is magic involved. You mean: there are bugs - bah :-/ Martin
Re: LLONG_MAX not available from c++
On Fri, Mar 31, 2023 at 02:27:17PM -, Michael van Elst wrote: > c++ also doesn't define __STDC_VERSION__ nor _ISOC99_SOURCE. It defines the former but not the latter: > c++ -dM -E - < /dev/null | fgrep __STDC_VERSION__ #define __STDC_VERSION__ 201710L > c++ -dM -E - < /dev/null | fgrep __ISO > (at least w/o special -std= options) Martin
Re: GZIP warnings when building
On Wed, Feb 15, 2023 at 03:09:37PM +0100, Christian Groessler wrote: > Hi, > > probably known and considered not important, but I wanted to mention that > I'm getting warnings like this when building a release: Sounds like a local problem - what is in your $GZIP (and why)? Martin
Re: GZIP warnings when building
On Thu, Feb 16, 2023 at 06:18:54AM +1300, Lloyd Parkes wrote: > I saw this too. I think the way we select the gzip compression level (using > the GZIP environment variable) is now deprecated for some reason. I have not seen it anywhere, but I see we set GZIP=-9n for pax -z in src/distrib/sets/maketars. Martin
Re: GZIP warnings when building
On Thu, Feb 16, 2023 at 06:37:36AM +1300, Lloyd Parkes wrote:
> Oh, it's used to pass the compression level though pax to gzip. That's
> explain it. Maybe we should switch to --use-compress-program="nbgzip
> -LEVEL"???
The problem is that we only have ${TOOLDIR}/nbpax, but that invokes gunzip
via $PATH and there is no ${TOOLDIR}/gunzip.
So this causes a dependency on the host gunzip, which is why the problem
does not show up when building on NetBSD.
Martin
Re: Remove extra unlock in dm9000 driver
On Thu, Jul 06, 2023 at 10:10:37PM -0400, Lwazi Dube wrote: > ec->ec_flags |= ETHER_F_ALLMULTI; > -ETHER_UNLOCK(ec); I fixed it slightly different, thanks for catching it! Martin
Re: fdisk and alignment
On Sun, Jul 09, 2023 at 02:52:01PM +0100, David Brownlee wrote: > Does anyone know offhand what alignment Linux/FreeBSD/OpenBSD pick for > MBR formatting? You should avoid MBR :-) I don't know other systems defaults, but sysinst uses 4k for small disks and 2m for bigger, unless you switch to single sector mode where it takes your input verbatim. Martin
Re: fdisk and alignment
On Sun, Jul 09, 2023 at 08:54:56PM +0100, David Brownlee wrote: > In practice I think it would be better not to penalise current use of > "small" (120GB SSD or 64GB or or CF/USB devices) for an edge case of > older hardware I am not sure what you see as penalty here. I think two factors made the original size decisions sensible back then: - for large disks the space lost to alignment does not matter - native block sizes > 512 byte only happened for larger disks initially Overall it would be better to enforce alignment as least as large as the native block size on *any* disk - but IIRC it is quite hard to find that value in all cases. Martin
Re: -current build failure
On Sun, Jun 04, 2023 at 02:40:16PM +0200, Thomas Klausner wrote: > Hi! > > I just tried updating my -current but the build failed: > > build.sh -j 32 -x -V MKDEBUG=yes -V MKDEBUGLIB=yes -V MKLLVM=yes -V > NOGCCERROR=yes -T /usr/obj/tools.gcc -m amd64 -O /usr/obj/src.amd64 -D > /usr/obj/amd64.gcc.20230604 -R /usr/obj/amd64.gcc.20230604.release > distribution > > --- support-modules --- > g++: error: unrecognized command-line option '-stdlib=libc++' > g++: error: unrecognized command-line option '-fmodules'; did you mean > '-fmoduleinfo'? > g++: error: unrecognized command-line option '-fcxx-modules' > g++: error: unrecognized command-line option > '-fmodules-cache-path=./module.cache' > > > Any ideas how to fix this? I couldn't even compile a amd64 GENERIC kernel w/o the attached patch - CC_WNO_ADDRESS_OF_PACKED_MEMBER is undefined in kernel builds (but that hack sounds like the wrong way to fix things). Luke, what would be the correct fix? Martin Index: Makefile.amd64 === RCS file: /cvsroot/src/sys/arch/amd64/conf/Makefile.amd64,v retrieving revision 1.86 diff -u -p -r1.86 Makefile.amd64 --- Makefile.amd64 6 Jan 2023 15:35:06 - 1.86 +++ Makefile.amd64 4 Jun 2023 13:49:07 - @@ -22,6 +22,7 @@ USETOOLS?=no NEED_OWN_INSTALL_TARGET?=no NOSANITIZER= .include +.include USE_SSP?= yes
Re: Redirecting 80 to 443
On Wed, Jun 07, 2023 at 08:55:46AM +1200, Lloyd Parkes wrote: > The httpd manual page describes how to invoke Lua scripts, but these > aren't CGI scripts. The manual page also describes how to invoke CGI > scripts of course. I would try a special document root for the port 80 instance and place (as only content) a .bzabsredirect symbolic link there. Martin --8<-- [/tmp] martin@big-apple > mkdir www-port-80 [/tmp] martin@big-apple > cd www-port-80/ [/tmp/www-port-80] martin@big-apple > ln -s "https://my.server.com/; .bzabsredirect [/tmp/www-port-80] martin@big-apple > ll -a total 12 drwxr-xr-x 2 martin wheel 24 Jun 7 08:06 ./ drwxrwxrwt 10 rootwheel 288 Jun 7 08:05 ../ lrwxr-xr-x 1 martin wheel 22 Jun 7 08:06 .bzabsredirect@ -> https://my.server.com/ [/tmp/www-port-80] martin@big-apple > cd .. [/tmp] martin@big-apple > /usr/libexec/httpd www-port-80/ get / got request ``get /'' from host to port redirecting https://my.server.com/ HTTP/0.9 301 Document Moved Document Moved Document Moved This document had moved https://my.server.com/;>here
Re: Why can't a WireGuard interface route packets to itself?
On Mon, Jul 31, 2023 at 11:59:12PM +0200, logothesia wrote: > route(8) for a while, and all my attempts to coax it into inserting a > route to an interface in a different subnet than the gateway's so far > have failed. route add -iface should work. > > I expect that you will need to dig deeper into WireGuard. It's quite > > possible that this is a bug in WireGuard. Or you might just have something > > misconfigured. I don't know anything about WireGuard and only a little bit > > about PPPoE. > > Oh, I probably should have shared my config to begin with, my bad- here > goes: I can reproduce your issue on my wg(4) setup, it is not specific to your setup (and I was suprised by the behaviour too). Martin
Re: i386/openssl on amd64?
On Sun, Jul 30, 2023 at 10:05:15AM +0200, Jan-Hinrich Fessel wrote: > Hej there, > > tried that on several fresh installations now with src grabbed via cvs > checkout. No one else seeing this? > I am somewhat lost in how to fix this apart from modifying the source list > (md.amd64 that would be) > > because i see there: > grep openssl lists/base/md.amd64 > ./usr/lib/i386/openssl base-crypto-usr > ./usr/lib/i386/openssl/engines base-crypto-usr > ./usr/lib/i386/openssl/engines/dasync.sobase-crypto-usr > compat,pic,openssl=30 > ./usr/lib/i386/openssl/engines/devcrypto.so base-crypto-usr > compat,pic,openssl=30 > ./usr/lib/i386/openssl/engines/loader_attic.so base-crypto-usr > compat,pic,openssl=30 > ./usr/lib/i386/openssl/engines/ossltest.so base-crypto-usr > compat,pic,openssl=30 > ./usr/lib/i386/openssl/engines/padlock.so base-crypto-usr > compat,pic,openssl=30 > ./usr/lib/i386/openssl/modules base-crypto-usr > ./usr/lib/i386/openssl/modules/legacy.sobase-crypto-usr > compat,pic,openssl=30 This seem to be leftovers that should be removed, all "compat" handling for OpenSSL is done generically now (see src/etc/mtree/NetBSD.dist.compat.in) Do you build with MKCOMPAT=no or something? Martin
Re: i386/openssl on amd64?
On Sun, Jul 30, 2023 at 03:18:32PM +0200, Jan-Hinrich Fessel wrote: > Oh yes: > build.sh command:./build.sh -U -j 2 -M /usr/obj -O /usr/obj -R > /usr/src/releasedir.NetBSD-10.99.6-amd64 -D > /usr/obj/destdir.NetBSD-10.99.6-amd64 -X /usr/xsrc -x -V MKCOMPAT=no release > install-image > > so, that leads to the question: is MKCOMPAT=no incompatible with building a > release? > Can that be fixed by just declaring the offending directories also as compat, > like: > /usr/lib/i386/openssl/engines base-crypto-usr > compat No, the lib/i386/openssl entries should just be removed. It is a bug normally hidden by equivalent lines generated from the generic compat lib handling. Martin
Re: 10.0_BETA w/MKNSD=yes build fails after OpenSSL update
On Sat, Aug 12, 2023 at 06:41:14AM -0500, John D. Baker wrote: > The recent mega-pull-up of heimdal, bind, and OpenSSL 3.0 to > NetBSD-10.0_BETA: > > https://mail-index.netbsd.org/source-changes/2023/08/11/msg146890.html > > breaks builds which set MKNSD=YES. Should be fixed now. Martin
Re: Mounting NetBSD partition on voidlinux
On Wed, Jun 21, 2023 at 02:20:25PM +0200, Sagar Acharya wrote: > Also, linux doesn't have fsck_ffs and debian had support for ufs in ufsutils > a long time ago. > > I highly recommend that for such cases you have a small standalone source > which can be built for correcting such errors which can perhaps have > disklabel, fsck_ffs, etc. A user can use it locally! Sources are not very helpful for emergency recovery. Depending on your device (I don't know anything about the Lime2) you have various easy "binary only" recovery methods: - most popular for all machines that can boot from USB: boot a USB install image - my personal favorite: boot an install kernel for your device from u-boot via network - boot an install kernel for your device from another SD card and swap the cards after the installer starts (better only do that on ramdisk based installers where / is on the memorydisk during installation) On machines with multiple possible boot sources it is easier (and you can prepare for disaster upfront by having a spare "known good" boot setup around). For us to be able to help you more, we need to know details about your setup. Like: what boot medium are you using, what are the other available options - and maybe you can get better support on the port-arm mailing list. Martin
Re: Mounting NetBSD partition on voidlinux
On Wed, Jun 21, 2023 at 12:12:35PM +0200, Sagar Acharya wrote: > My NetBSD system has gotten corrupted. How do I mount my NetBSD partition on > voidlinux? The typical recovery doesn't involve any other OS. If your kernel works and finds the / partition you can "boot -sa" and select /rescue/init as init replacement, then fix things from there. If that doesn't work, just boot a USB installer and escape to shell, then fix whatever needs fixing. Martin
Re: Mounting NetBSD partition on voidlinux
On Wed, Jun 21, 2023 at 08:39:45PM +0200, Sagar Acharya wrote: > I am on a NetBSD 10 install now after sabotaging my fully good alpine due to > constraints of sd card. The memory card from which I want to retrieve data is > mounted at sd0 > > $ fsck_ffs /dev/sd0a > /dev/rsd0a[1] Floating point exception (core dumped) fsck_ffs /dev/sd0a Are you sure sd0a is the correct partition? What does the partition table look like? gpt show -a sd0 disklabel -r sd0 should show usefull hints. Martin
Re: Mounting NetBSD partition on voidlinux
On Wed, Jun 21, 2023 at 08:43:45PM +0200, Sagar Acharya wrote: > $ dkctl sd0 listwedges > /dev/rsd0: no wedges configured > > What are wedges? I get sectors which are 512 bytes long on physical disk. With "dkctl sd0 addwedge " you can use arbitrary "partitions" on disk sd0 without modifying its on-card partition information, so if you have a disk from a foreign system where NetBSD does not understand the partitioning scheme but you know the block offset/size of the file system you are interested in, you can create a "partition" at runtime and mount it (w/o changing the SD). They show up as /dev/dk* and they are automatically created e.g. for GPT partitions. Martin
Re: Mounting NetBSD partition on voidlinux
On Thu, Jun 22, 2023 at 03:47:27PM +0200, Sagar Acharya wrote: > I need something to repair this ufs2 partition. You did not answer the partitioning questions and it is hard to follow what you are doing and seeing. You can repair it easily with NetBSD's fsck(8). You can analyze it close with dumpfs(8). But first you really need to make sure you are accessing the correct partition on the SD card. Since it is a SD card it should be easy to make a full backup of it upfront - e.g. with dd, just in case. Martin
Re: tweaks needed for 10 branch
On Sat, Jul 01, 2023 at 05:47:53PM -0400, Andrew Cagney wrote: > just fyi, had to tweak this when building; to be honest I'm a bit puzzled Yes, puzzling - it is not clear what standard apple tools default to after latest updates. The easy fix is to use HOST_CFLAGS= (or is it HOST_CXXFLAGS?) to force an older standard (for that tools build). Martin
Re: Mediatek 7601U wireless chip porting
On Thu, Dec 21, 2023 at 04:59:36PM +0100, Fekete Zoltán wrote: > Is there any usb wifi chipset left on the list without a maintainer? I could > take one for my study if I could purchase hardware for that. Might be a > win-win. I think we have everything covered for the USB chipsets where we currently have drivers. There are lots of others out there though... Martin
Re: Mediatek 7601U wireless chip porting
On Thu, Dec 21, 2023 at 07:51:07AM +0100, Fekete Zoltán wrote: > Is anybody working on the same driver? > Has anybody tried it so far? > Is there any known hard limitation which blocks the porting to NetBSD? We have patches for that chipset for the new FreeBSD based wifi stack (and I have hardware). So it will likely be supported once we merge the new stack into -current. Martin
Re: unlink_if_ordinary undefined...
On Sun, Dec 31, 2023 at 02:19:01PM +, Chavdar Ivanov wrote: > As far as I could tell, the only place where this is defined in the system is > in > > nm /usr/libexec/lto-wrapper | grep unlink_if > 0006a842 T unlink_if_ordinary > > No idea about this, my google-fu apparently is not so strong to > suggest anything useful. It is a GNU libiberty utility function and probably should not be a dynamic symbol anywhere (but staticaly linked from -liberty). Martin
Re: Mediatek 7601U wireless chip porting
On Fri, Dec 22, 2023 at 08:06:40AM +0700, Robert Elz wrote: > Date:Thu, 21 Dec 2023 20:26:29 +0100 > From:=?ISO-8859-1?Q?Fekete_Zolt=E1n?= > Message-ID: <8bc45468-b662-4615-9c61-9981bd2b1...@minux.hu> > > | Using USB would have been a good starting point from a hardware > | availability perspective. > > It probably still could be, Martin's: > > | >There are lots of others out there though... > > was in reference to his earlier: > > | >for the USB chipsets where we currently have drivers. > > and indicates that there are more USB chipsets for which we > don't currently (not even in his, and others', unreleased yet version) > have drivers. There is probably a misunderstanding. The "list" I assumed we were talking about is at https://wiki.netbsd.org/wifi_driver_state_matrix/ There are no additional drivers popping up with the new stack by itself, besides (currently) two exceptions: the mtw one that started this discussion and the Intel linux one that Phil is working on. The Atheros chipset mentioned might fall into the AR10k group (I haven't checked details yet), where FreeBSD has a driver and we can (maybe) more or less easily adapt that driver with the new stack - but besides the (then) identical wifi API we have to deal with the different USB api (and ideally adapt to the usbwifi helper library). Martin
Re: Router setup
On Mon, Dec 25, 2023 at 12:58:27PM -0500, xuser wrote: > Does any one know how to setup ip forwarding on netbsd? In /etc/sysctl.conf add: net.inet.ip.forwarding=1 net.inet6.ip6.forwarding=1 Martin
Re: Can't build evbarm
On Thu, Jan 25, 2024 at 10:52:30AM +0100, Adam wrote: > > All builds are working again, if this still fails for you there must be > > a local problem in your setup. > > > > Martin > > My setup is cross-building NetBSD on macOS. But that doesn't explain the issues you are seeing, no host tools should be involved in that part or am I missing something? Can you start the build from scratch (remove obj and destdir upfront) and provide a bit more build output before the failure, please? Martin
Re: Can't build evbarm
On Sat, Jan 27, 2024 at 02:49:09AM +0700, Robert Elz wrote: > | It doesn't accept implicit function declarations. > > Yes, that's fine - you do not need to explain the issue, we all > understand that --- but there's supposed to be a prototype for > the function, it isn't intended to be implicit. Robert is right, the missing prototype is a bug in the makefiles. Adam: that your clang host compiler requires a newer C standard than C99 for building tools is another bug, you can probably add something like -std=c99 to HOST_CFLAGS / HOST_CXXFLAGS to fix that. Martin
Re: Can't build evbarm
On Fri, Jan 26, 2024 at 09:09:30PM +0100, Adam wrote: > Simple and elegant. No hacks involved. Because the declaration in the relevant header is already there, and the order does not matter. But the #ifdef around the declaration needs to do the right thing. No need to move things around and its like this code is compiled everwhere else where it is used. Martin
Re: Can't build evbarm
On Sat, Jan 27, 2024 at 03:33:06PM +0700, Robert Elz wrote: > Now that Christos moved the function around, that declaration in the > header is just noise, and could be removed. Yes, that would be consistent then (but isn't it against the new style rules?) Martin
Re: tmux-direct entry only has 8 colors
On Thu, Feb 01, 2024 at 03:13:42PM +, RVP wrote: > This looks like a bug in NetBSD. Minimal reproducer: > > ``` > $ cat tit > tit|TermInfo Test, > # if the second number is >32767, it disappears! > use=num, use=max, > # putting the bigger one first makes "promotion" happen. > # use=max, use=num, > > max|any number > INT16_MAX, > colors#32768, > > num|any num < INT16_MAX, > num#111, > > $ tic -x tit This is fallout from usr.bin/tic.c: -- revision 1.33 date: 2020-03-27 16:11:57 +0100; author: christos; state: Exp; lines: +21 -17; commitid: 2Q6C4aNTDvrFf32C; As described in tech-userlevel: - Modify the writing code to only write entries in the new format for the terminal descriptions that require it. - Store new format entries as @v3 - Store old format entries with clamped values as for backwards compatibility - Lookup first @v3 and then if that is not found. - Don't create terminfo2 anymore; old programs keep working with clamped entries, and new programs be able to use the wide fields with using the original db file. -- especially this part of process_entry: if (tic->rtype == TERMINFO_RTYPE) return process_entry(, flags | TIC_COMPAT_V1); but I don't understand how it is supposed to work. Martin
Re: Can't build evbarm
On Fri, Jan 26, 2024 at 03:03:24AM +0700, Robert Elz wrote: > Date:Thu, 25 Jan 2024 20:12:36 +0100 > From:Adam > Message-ID: > > | Correct, _LIBC_INTERNAL is not defined for tools/compat. > > I wonder what the difference is between your environment, and > a standard build on a NetBSD host. My guess is a system header (md2.h?) being found unintendly (either only on macOS or in case of NetBSD having the "right" bits in the system header). Adam, can you check the *.d file in your objdir correspoding to the failing compiler invocation and show us what system headers are mentioned there? Martin
Re: Can't build evbarm
On Thu, Jan 25, 2024 at 09:20:50AM +0100, Adam wrote: > Reverting lib/libc/hash/md2/md2.c to v1.7 fixes the build. All builds are working again, if this still fails for you there must be a local problem in your setup. Martin
Re: Can't build evbarm
On Fri, Jan 26, 2024 at 04:42:43PM +0100, Adam wrote: > % cat /tmp/pkgsrc/obj.aarch64/tools/compat/md2.d [..] > md2.o: > /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/assert.h > md2.o: /dist/src/tools/compat/md2.h > md2.o: /dist/src/tools/compat/../../include/md2.h OK, so that wasn't it. Martin
Re: Can't build evbarm
On Sat, Jan 20, 2024 at 10:50:27AM +0100, Adam wrote: > NetBSD-current fails to build on aarch64. > > Please, help :) As you can see here: https://releng.NetBSD.org/cgi-bin/builds.cgi it was not only evbarm/aarch64 affected, but all builds were broken. Robert fixed it in the meantime. Martin
Re: Can't build evbarm
On Sat, Jan 20, 2024 at 05:19:25PM +0700, Robert Elz wrote: > Not that particular one I didn't, didn't know about that particular > breakage, will look at it now. Oops, mixed the breakage - but thanks for fixing it now :-) Martin
Re: How to raise iwm0?
On Sun, Nov 19, 2023 at 02:44:04PM +0100, Lizbeth Mutterhunt, Ph.D wrote: > As axen0 fails to connect, I want to try the wlan0, but it won?t be able to > make a wlan0. I can?t find the iwm module in kernel config. Does it be named > differently (I?ve got it from FreeBSD) or is just the hardware bad. I mean > it?s unsupported, because I killed a Chromebook to an EFI machine. It?s a > Gemini Lake. wlan* is the FreeBSD name for VAP interfaces, you don't have that in NetBSD (unless you are running the wifi renovation branch). Martin
Re: new "compat" sets have really made sets harder to manage.
On Thu, Apr 25, 2024 at 10:43:43PM -, Christos Zoulas wrote: > Thank you. I think there should be one compat set list, not one > for each machine_arch, and only have a ad or md machine specific > file for the parts that are different. I.e. there should be a > base32/mi and a base32/shl.mi containing most of the data. I'd say even those should not exist, as the files in base/* already have all the information we need, and it is important to keep tags like compatfile and compatdebug working like they used to before the set list changes. Martin
Re: continuous ffs_blkfree_common panic
On Sat, May 04, 2024 at 12:12:35AM +0300, Andrius V wrote: > corrupted as well). After some actions crash is not reproducible > anymore though. I guess issue can be considered as some kind of fluke. Did you run a forced fsck on the file system? I usually boot single user and then do something like "fsck -fy /" if some obscure corruption has been observed. NetBSD does (a variant of) that automatically on the next reboot after a crash, but sometimes extra paranoia is usefull, especially when this could be something like hardware going bad (or the SSD firmware getting kicked to remap some spare sectors). Martin
Re: amdgpu laptops with 10 & current?
On Tue, May 14, 2024 at 05:39:21PM +, nia wrote: > > Which reminds me: whatever happened to the new wifi project? [..] > So, still ongoing, just slowly Yes, sorry about that - it will get a lot more attention now that 10.0, 9.4 and 8.3 are out of the door. Martin
Re: Minor sysupgrade issue
On Sat, Jun 01, 2024 at 06:41:19PM +0100, Chavdar Ivanov wrote:
> ptyfsoldnodes fix:
> [1] Bad system call ${HOST_SH} "${MAKEDEV_DIR}/MAKEDEV" -s
You need to run a new kernel before you install new userland.
In this case you hit the new version of dup3(2) which crashes on the
old kernel.
Martin
Re: recent openssh import seems to break sshd
On Wed, Jul 10, 2024 at 01:07:53PM +0200, Markus Kilbinger wrote: > Is anybody else seeing this? Yes, me: https://gnats.netbsd.org/58412 Martin
