Re: Bug in the guide, npf exaple of gatewayapp

[David H. Gutteridge]

On Sun, 18 Feb 2024, at 11:37:49 + (UTC), adr wrote:

On Sun, 4 Feb 2024, adr wrote:

Hi, in the example 24.8, $localnet is set to 192.168.0.1/24, the
host identifier should be 0.

Should I send a bug report, or could someone quickly make this
no-brainer fix?


Just to be clear, this is not bikeshedding. Apart of been incorrect
by using a host address instead of a network address, the example
won't work.


I've adjusted this, it should be what you expect (and republished) now.

Thanks,

Dave

Re: mlterm 3.9.2 Failed to open pty

[David H. Gutteridge]

On Thu, 21 Jul 2022 at 21:13:25 +0900, Rin Okuyama wrote:

On 2022/07/21 19:23, RVP wrote:

   Looking at baselib/configure.in:279, the pty-type check programs
   only #include  w/o pulling in . Depending on
   what pkgsrc's CFLAGS are, this could result in the 2 programs not
   compiling at all, and the configure thinking that only BSD ptys
   are present.

   Hope this helps...


Unfortunately no. It *does* builds only if O_RDWR and O_NOCTTY are
defined. No matter whether posix_openpt(3) is declared or not.

However, posix_openpt(O_RDWR | O_NOCTTY) returns -1 for some
conditions. I've not reproduced this behavior for freshly-installed
NetBSD/amd64 9.2.

Maybe this is worth for PR...


The cause of the issue is that the package uses AC_RUN_IFELSE to check
if the posix_openpt(3) call *succeeds at runtime[1]*, not just if it
compiles and links. If the build environment is sandboxed, then the
call to open /dev/ptmx will fail, and the package will fall back to the
old "bsd" implementation instead.

The fix would be to remove the runtime check in the configure script,
if we want it reliably building in official (presumably sandboxed)
builds. I've had to do that in the past for other packages that did
something similar.

(I assume that's how the OP's issue arose, but I didn't see anything in
the thread about where mlterm is coming from, e.g., an official binary
package from NetBSD, or something built by the user in a sandboxed
environment, or something else. In any case, I can reproduce this in a
sandboxed pbulk environment, where it builds as expected outside of it,
so I investigated.)

I've also added a note to this effect in PR pkg/56936.

1. See baselib/configure.in starting at line 279

Regards,

Dave

Re: Option -p in apropos(1)

[David H. Gutteridge]

On Tue, 2022-05-17 at 08:24 -0400, David H. Gutteridge wrote:
> On 2022-05-17 04:33, Rocky Hotas wrote:
> > On mag 16 21:51, David H. Gutteridge wrote:
> > 
> > > It does accept $PAGER as a definition of what tool to use for the
> > > purpose, though that wasn't documented in the apropos(1) man page.
> > > I
> > > just added it.
> > 
> > FTR, for some reason in my default env(1) variable PAGER is not set:
> > it
> > is empty. However, if (for example) I try to set it to `more', 
> > apropos(1)
> > behaves as described yesterday, so there are no improvements.
> 
> Yes, it won't be set by default, no more than $APROPOS would be. I
> didn't mean to imply setting it will fix your issue, I was just noting
> it wasn't documented before. You'd have to try a patched version of
> the apropos(1) command.

This (along with other fixes) has now been pulled up to the netbsd-9
branch, so the next releng build of 9.2_STABLE will include it.

Regards,

Dave

Re: Option -p in apropos(1)

[David H. Gutteridge]

On Tue, 2022-05-17 at 07:59 +, RVP wrote:
> On Mon, 16 May 2022, David H. Gutteridge wrote:
> 
> > Thanks for this, I've applied a similar patch to HEAD. Assuming
> > everyone's satisfied, I could request a pullup to netbsd-9.
> > 
> 
> Thanks for that. Another patch below:
> 
> 1. Ignore SIGPIPE so that we're not killed in the middle of some
>     DB operation by a botched $PAGER:
> 
> $ env PAGER=/non-existent apropos -p ...
> 
> 2. Return proper exit status in case of write errors:
> 
> $ apropos ... >/dev/full || echo fail
> 
[...]

Thanks, I've applied that basically verbatim.

Cheers,

Dave

Re: Option -p in apropos(1)

[David H. Gutteridge]

On 2022-05-17 04:33, Rocky Hotas wrote:

On mag 16 21:51, David H. Gutteridge wrote:


It does accept $PAGER as a definition of what tool to use for the
purpose, though that wasn't documented in the apropos(1) man page. I
just added it.


FTR, for some reason in my default env(1) variable PAGER is not set: it
is empty. However, if (for example) I try to set it to `more', 
apropos(1)

behaves as described yesterday, so there are no improvements.


Yes, it won't be set by default, no more than $APROPOS would be. I
didn't mean to imply setting it will fix your issue, I was just noting
it wasn't documented before. You'd have to try a patched version of the
apropos(1) command.

Regards,

Dave

Re: Option -p in apropos(1)

[David H. Gutteridge]

On Mon, 16 May 2022 at 21:05:59 +0200, Steffen Nurpmeso wrote:
>Rocky Hotas wrote in
> <20220516180129.gwvmvesgw4dxeage@delpotro>:
> |On mag 16 18:11, Rocky Hotas wrote:
> |> 
> |> Am I doing something wrong?
> ...
> |perl5320delta (1)   what is new for perl v5.32.0
> |...Configure  4 For clang++, add "#include " to Configure's
> |probes for "futimes", "strtoll", "strtoul", "strtoull", "strtouq",
> |otherwise the probes would fail to compile.  4 Use a compile and run
> |test for "lchown" to satisfy clang++ which should more...
> |
> |--More--(byte 3792)myhostname$
> |
> |Where `myhostname$' is my bash prompt. So, more(1) tries to start,
but
> |it immediately exits.
> ...
>I have no idea but does the program combo honour $LESS and if so
>does it contain use of alternate screen and quit-at-eof?
>What does "LESS= apropos X" do?
>And are there terminal controls somewhere in the one page.
>Other than that it gets more complicated.

It does accept $PAGER as a definition of what tool to use for the
purpose, though that wasn't documented in the apropos(1) man page. I
just added it.

Due to evidently historical reasons (as I understand it), interestingly
the man(1) code handles this rather differently than apropos(1) does,
with more considerations (about checking and sanitizing input), and a
different call to run the pager.

Regards,

Dave

Re: Option -p in apropos(1)

[David H. Gutteridge]

On Mon, 16 May 2022 at 20:33:40 + (UTC), RVP wrote:
>On Mon, 16 May 2022, Rocky Hotas wrote:
>>Pager formatting is enabled by default (so, it doesn't need neither
>>option -p, nor option -P), but the pager is not activated. Results
>>are presented as if the option was not specified.
>
>apropos should call pclose(). Please try this patch below:
>
>---START---
>diff -urN usr.sbin/makemandb.orig/apropos.c
usr.sbin/makemandb/apropos.c
>--- usr.sbin/makemandb.orig/apropos.c  2017-11-25 14:29:38.0
+
>+++ usr.sbin/makemandb/apropos.c   2022-05-16 20:26:55.134310194
+
>@@ -249,6 +249,7 @@
>   if (aflags.format == APROPOS_HTML)
>   fprintf(cbdata.out, "\n\n\n");
>
>+  pclose(cbdata.out);
>   free(query);
>
>   if (aflags.sections) {
>---END---

Thanks for this, I've applied a similar patch to HEAD. Assuming
everyone's satisfied, I could request a pullup to netbsd-9.

Regards,

Dave

Re: Kernel panic on amd A8 Apu Radeon 7 is there anything i can do ?

[David H. Gutteridge]

On Sun, 17 Apr 2022 13:49:40 +0300, chris greek wrote:

Kernel panic on amd A8 Apu Radeon  7 is there anything i can do ?
I'm out of gpu because it was too old i guess  and until my new
arrives i want to use
the integrated gpu but i can't
I tried also the current without any luck
On linux to select the amdgpu driver instead of radeon i had to enter
these parameters
radeon.cik_support=0 amdgpu.cik_support=1
Any way i can pass these parameters on the module or something.
I got either kernel panic or a message that says it can't load kaveri 
firmware

and then kernel panic

I have installed the gpufw firmware but still no luck
Any help would be appreciated and sorry for bothering you.


It sounds like you've hit an issue where the specific firmware files
needed for your GPU aren't installed by NetBSD. This is likely the same
as this PR:
http://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=54976

I also had this problem with similar hardware, and solved it simply by
manually installing all the files found in kernel.org's linux-firmware
tree for Radeon:

https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/radeon

You probably already know this, but you can download full snapshots of
linux-firmware like this:

https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/snapshot/linux-firmware-20220411.tar.gz

Then place the Radeon files at /libdata/firmware/radeon. Basically, you
probably need some of the files with lowercase names, rather than the
uppercase versions.

You shouldn't need most of them, but I don't know the full gamut of the
files you may need, so it's simpler to just add them all.

I hope this helps. If not, you may want to file a PR, as it's something
different.

Regards,

Dave

Re: man

[David H. Gutteridge]

On Mon, 2022-03-07 at 21:09 -0500, David H. Gutteridge wrote:
> On Sun, 6 Mar 2022 at 10:19:51 -0500, C Chapman wrote:
> > I can't get the -m option to work with man. When I enter
> > 
> > man -m /usr/pkg/heirloom-doctools/man/
> > 
> > man searches the default paths first. The man page says it should do
> > it last.
> > 
> > I am using version 9.2 and the tcsh shell.
> 
> Hello,
> 
> Yes, you've found a regression caused by a code refactoring from
> twelve
> years ago that mistakenly appended rather than prepended the -m
> argument(s) to the search paths. I've fixed that in HEAD earlier this
> evening, and will request a pull-up to the netbsd-9 branch in a few
> days, assuming no fallout (I don't think there should be any).

This has now been pulled up to both the netbsd-8 and netbsd-9 branches,
so it will be in 9.3 (and is of course also available if you're tracking
the branch as 9.2_STABLE).

Regards,

Dave

Re: man

[David H. Gutteridge]

On Sun, 6 Mar 2022 at 10:19:51 -0500, C Chapman wrote:
> I can't get the -m option to work with man. When I enter
> 
> man -m /usr/pkg/heirloom-doctools/man/
> 
> man searches the default paths first. The man page says it should do
> it last.
> 
> I am using version 9.2 and the tcsh shell.

Hello,

Yes, you've found a regression caused by a code refactoring from twelve
years ago that mistakenly appended rather than prepended the -m
argument(s) to the search paths. I've fixed that in HEAD earlier this
evening, and will request a pull-up to the netbsd-9 branch in a few
days, assuming no fallout (I don't think there should be any).

Thanks for reporting this.

Regards,

Dave

Re: Problems unpacking sets with ftp -o

[David H. Gutteridge]

On Fri, 30 Apr 2021 at 11:32:10 -0400, Louis Guillaume wrote:
>Hello!
>
>My longtime update method for netbsd systems (since NetBSD 1.6 or so) 
>summarized...
>
>1. Retrieve/unpack the kernel
>  # cd /
># ftp -o "|pax -zrvpe" 
>http://nyftp.netbsd.org/pub/NetBSD-daily/netbsd-9/latest/amd64/binary/sets/kern-XEN3_DOMU.tar.xz
>
>2. reboot
>
>3. Retrieve unpack the sets
>
>  # for i in base comp games modules man misc text ;do
>> ftp -o "|pax -zrvpe" 
>> http://nyftp.netbsd.org/pub/NetBSD-daily/netbsd-9/latest/amd64/binary/sets/${i}.tar.xz
>  > done
>
>4. Get the etc.tar.xz and run etcupdate on it.
>  # cd /usr/INSTALL
># ftp 
>http://nyftp.netbsd.org/pub/NetBSD-daily/netbsd-9/latest/amd64/binary/sets/etc.tar.xz
>  # etcupdate -d / -s /usr/INSTALL/etc.tgz
>
>5. Reboot.
>
>
>But this doesn't work as of recent. Step 3 breaks. It seems that since moving 
>from .tgz to .tar.xz archives I have this problem.
>
>The kernel works fine, but for the sets, I get the following problem after a 
>while...
>
>./usr/share/locale/zh_CN.GB18030
>./usr/share/locale/zh_CN.GB18030/LC_CTYPEgzip: Unexpected end of input
>
>pax: End of archive volume 1 reached
>pax: ustar vol 1, 4942 files, 189618300 bytes read, 0 bytes written in 36 secs 
>(5267175 bytes/sec)
>
>ATTENTION! pax archive volume change required.
>Ready for archive volume: 2
>Input archive name or "." to quit pax.
>98% |* | 40544 KiB 750.71 
>KiB/s - stalled -^C
>pax: Signal caught, cleaning up.
>
>
>As if the pipe to pax is misbehaving.
>
>Any thoughts on this? My workaround is to download everything to /usr/INSTALL 
>first. Then pax works fine in the loop.

Hello,

Have you tried passing --xz, given that's the archive format used now
(not -z for gzip)? I.e., ftp -o "|pax --xz -rvpe" ...

Regards,

Dave

Re: firefox68 / netbsd-8 : mostly black window

[David H. Gutteridge]

On Sat, 16 May 2020 at 17:09:25 +0200, is wrote:
> am I the only one experiencing this?
> 
> lots of
> 
> [4147, Main Thread] WARNING: failed to open shm: Not supported: file
> /pkg_comp/obj/pkgsrc/www/firefox68/default/firefox-
> 68.7.0/ipc/chromium/src/base/shared_memory_posix.cc, line 142
> Crash Annotation GraphicsCriticalError: |[0][GFX1-]: Failed to lock
> new back buffer. (t=2.47329) |[586][GFX1-]: Failed to lock new back
> buffer. (t=41.8046) |[587][GFX1-]: Failed to lock new back buffer.
> (t=41.8443) |[588][GFX1-]: Failed to 
> 
> on stdout/err
> 
> The Window stays white background, with some black rectangles (e.g., 
> blindly opening a menu adds a corresponding rectangle)
> 
> Blindly opening an URL shows the title as the windows title (rendered
> by the
> window manager) - onlye rendering seems to be broken.
> 
> This is 
> 
> NetBSD henrietta 8.1 NetBSD 8.1 (GENERIC) #3: Sun Jun 16 12:30:46 CEST
> 2019  is@neuerserver:/var/itch/sources/8.0/obj.amd64/sys/arch/amd64/co
> mpile/GENERIC amd64
> 
> build environment was 8.0ish, firefox 68.7 from 2020Q1.

Does your machine have a (tmpfs-backed) /var/shm available? The error
message suggests that it doesn't. (I just noticed this post now, I'm
assuming it relates to your other posts about Firefox.)

Regards,

Dave

Re: xfce4 startup issue

[David H. Gutteridge]

On Sat, 9 Feb 2019, at 16:38:18 -0600, Robert Nestor wrote:
> I’m still trying to isolate the problem I’m seeing.  Did notice that
> hal is no longer dragged in when I install xfce4 from current or
> 2018Q4, so I’ve eliminated it in my install.  Avahi was being pulled
> in when I installed seamonkey, so I’ve disabled it for the time
> being.  Where I am now is testing with 2018Q4 packages.  With dbus
> disabled xfce comes up and more or less runs. (Mouse clicks and window
> movement is really hit or miss.)  With dbus enabled xfce hangs at the
> autostart point but it takes a long time to get there and I’m not
> finding any errors in the logs.  Haven’t tried the same install using 
> current versions of packages, but it’s on my list of things to do.

The mouse click and window movement issue may be related to this PR:
http://gnats.netbsd.org/53718. If so, any insights you can share would
be appreciated. I'm one of the lucky ones: I can't reproduce it.

Dave

Re: xfce4 startup issue

[David H. Gutteridge]

On Fri, 8 Feb 2019, at 15:13:35 -0600, Robert Nestor wrote:
> As suggested by David Gutteridge, I commented out the startup of the
> dbus, hal and avahi daemons in rc.conf.  When I did this, xfce4 came
> up and appeared to be working.  So that begs the question, why the
> install of xfce4 also installs these daemons and why aren’t they
> working in 2018Q4 and current where they do work out of 2017Q4 pkgsrc.

The answer is different depending on the component. hal is no longer
maintained upstream and so is deprecated. E.g., it was removed as a
direct dependency of xfce4-thunar in 2015, and was removed as an
indirect dependency of the same (via gvfs) in mid-2018 (in the pkgsrc
2018Q2 branch). I don't know what else you have installed that may
depend on it, but you won't need it for Xfce anymore. It should not
be pulled in in a clean installation of meta-pkgs/xfce4.

avahi gets pulled in via dependencies, e.g. pulseaudio. Whether you
want to have it running or not is up to you: I don't presume to tell
anyone what to do with their machines. (Personally, I don't run it,
because I have no need for it.)

dbus is definitely still required. How and when you activate it can
vary, e.g. some users include an invocation in their .xinitrc so it
only launches if they're starting a relevant X session. If it's not
explicitly launched by any means, you should find it will start on
demand by Xfce anyway. (It does for me.) 

Dave

Re: xfce4 startup issue

[David H. Gutteridge]

On Thu, 7 Feb 2019, at 10:11:22 -0600, Robert Nestor wrote:
> Running NetBSD 8.0_STABLE on an amd64 system using xfce4 and related
> packages from pkgsrc-2017Q4 which has been working.  But there are
> some minor nits, so I’ve tried upgrading my installed packages to
> those found in either pkgsrc-2018Q4 or -current.  I see the same
> problem in both though; xfce4 doesn’t start and I see the same
> messages during startup on a clean install of the system:
> 
> dbus-daemon[1027]: [system] Rejected send message, 1 matched rules;
> type=“method_call”, sender=“:1.0” (uid=0, pid=1135,
> comm=“/usr/pkg/sbin/hald ”)
> interface=“org.freedesktop.ConsoleKitManager” member=“GetSeats”
> errorname=“(nset)” requested_reply=“0”
> destination=“org.freedesktop.ConsoleKit” (dubs)
> /etc/rc.d/hald exited with code 1
> 
> avadi-daemon[790]: dbus_bus_request_name(): Connection “:1.1” is not
> allowed to own the service “org.freedesktop.Avahi” due to security
> policies in the configuration file
> /etc/rc.d/avahidaemon exited with code 1
> 
> Digging into the problem I notice that the directories for hal, dbus
> and avahi have all moved from /usr/pkg/etc to /etc.  Comparing the
> files in these directories shows changes in the dbus-
> 1/system.d/ConsoleKit.conf file, but using the one from 2017Q4 doesn’t
> improve or correct the startup problems.
> 
> In all three setups (2017Q4, 2018Q4 and current) I have hal, dbus and
> avahidaemon set to YES in /etc/rc.conf.

What happens if you disable these three in rc.conf and simply issue
"startxfce4" from the command line? Does it fail to start? Are you
seeing any error messages from xfce4 itself?

Regards,

Dave

Re: libstdc++.so.7 is missing

[David H. Gutteridge]

On Sun, 2019-01-20 at 22:26 +0100, Pedro Pinho wrote:
> Sometimes it's a bit strange with mailing lists ;)
> I've installed gcc6-libs and that fixed the problem. I'm really happy for it 
> and would like to thank you all for bearing with me.
> I've been testing the browser for 15min and its working. Although, I have to 
> figure out why its eating ~70% of my cpu, i5 quad-core on some pages.

Good to hear. So that implies there's an issue where midori or one of
its dependencies requires a pkgsrc version of gcc-libs, but this isn't
noted in a way that makes package installation tools aware. I'll have a
look at this when I have a moment.

Dave

Re: libstdc++.so.7 is missing

[David H. Gutteridge]

On Sun, 2019-01-20 at 17:34 +0100, Pedro Pinho wrote:
> The symlink was just a test, I've removed it as I got another missing library.
> 
> Here's the output of ldd /usr/pkg/bin/midori https://pastebin.com/h6wbXvBu
> and the output of ldd /usr/pkg/lib/lib*.so https://pastebin.com/UPT68xaw
> the last one, i.e. ldd /usr/pkg/bin gives just read error: Operation not 
> supported by device
> 
> I see if I get the time to compile midori from pkgsrc later today.

I looked at the midori package that was uploaded on or after January
14th, and it has "@blddep gcc6-6.5.0nb2" noted. If you don't have the
package gcc6-libs-6.5.0nb3.tgz from the Q4 build installed, please add
it and report the results. (If that fixes your problem, then there's a
package that needs to be corrected.)

If not, separately, as Greg noted, we need to disentangle what requires
what. Looking at your ldd output for midori, we see both libstdc++.7
and .8 get referenced. That on its own isn't enough, because some of
the non-pkgsrc libraries that are referenced there definitely require
.8, e.g. it's pulling in libGL from xbase, which links against .8.

And, separately again, yes, I see gimp is missing from the Q4 packages.
I guess either it didn't build for some reason or the uploaded packages
are incomplete. Whoever supports those binary pkg builds would have to
comment here.

Dave

Re: libstdc++.so.7 is missing

[David H. Gutteridge]

On Sat, 2019-01-19 at 17:58 -0500, David H. Gutteridge wrote:
> On Sat, 2019-01-19 at 23:43 +0100, Pedro Pinho wrote:
> > Back at home!
> > I've just erased my disk using gpsrted-live usb and made a fresh
> > install from the image here, 
> > http://ftp.fr.netbsd.org/pub/NetBSD-daily/netbsd-8/201901151910Z/images/
> > 
> > NetBSD 8.0 STABLE arch amd64
> > 
> > Pointed pkgin to 
> > http://ftp.fr.netbsd.org/pub/pkgsrc/packages/NetBSD/amd64/8.0/All/
> > 
> > and pulled my binary packages. Launching midori from xterm outputs
> > libstdc++.so.7 is missing. Tried symlinking libsrdc++.so.8 to
> > libstdc++.so.7 to no avail. Can't launch midori. 
> > It would be ok with firefox but, as mentioned already, firefox is
> > not
> > there!!
> > 
> > Any suggestions?!
> 
> Please post the output of ldd against the midori binary.
> 
> Dave

To clarify, you'll presumably get "-lstdc++.7 => not found", which
isn't too helpful of itself. I wanted to see in totality what it links
against on your system, and if there is anything else missing it needs.
It would be more helpful, actually, to see what the @blddep and @pkgdep
entries in its pkgdb +CONTENTS file are.

Dave

Re: libstdc++.so.7 is missing

[David H. Gutteridge]

On Sat, 2019-01-19 at 23:43 +0100, Pedro Pinho wrote:
> Back at home!
> I've just erased my disk using gpsrted-live usb and made a fresh install from 
> the image here, 
> http://ftp.fr.netbsd.org/pub/NetBSD-daily/netbsd-8/201901151910Z/images/
> 
> NetBSD 8.0 STABLE arch amd64
> 
> Pointed pkgin to 
> http://ftp.fr.netbsd.org/pub/pkgsrc/packages/NetBSD/amd64/8.0/All/
> 
> and pulled my binary packages. Launching midori from xterm outputs 
> libstdc++.so.7 is missing. Tried symlinking libsrdc++.so.8 to libstdc++.so.7 
> to no avail. Can't launch midori. 
> It would be ok with firefox but, as mentioned already, firefox is not there!!
> 
> Any suggestions?!
> Thx!

Though I don't think this is the most likely answer here, another
possibility is that the problem packages have been built on a machine
running an 8.0_BETA release from prior to Oct. 12, 2017. Because prior
to that, libstdc++.so.7 existed, and then it was replaced with .8.[1]

This may be the reason I see things like this with the builds found for
powerpc/8.0_2018Q3:

blackbox:
-lSM.7 => /usr/X11R7/lib/libSM.so.7
-lICE.7 => /usr/X11R7/lib/libICE.so.7
-lc.12 => /usr/lib/libc.so.12
-lX11.7 => /usr/X11R7/lib/libX11.so.7
-lxcb.2 => /usr/X11R7/lib/libxcb.so.2
-lXau.7 => /usr/X11R7/lib/libXau.so.7
-lXdmcp.7 => /usr/X11R7/lib/libXdmcp.so.7
-lXext.7 => /usr/X11R7/lib/libXext.so.7
-lstdc++.7 => not found
-lm.0 => /usr/lib/libm.so.0
-lgcc_s.1 => /usr/lib/libgcc_s.so.1

1. 
http://cvsweb.netbsd.org/bsdweb.cgi/src/distrib/sets/lists/base/shl.mi?rev=1.817.2.2=text/x-cvsweb-markup_with_tag=netbsd-8

Dave

Re: libstdc++.so.7 is missing

[David H. Gutteridge]

On Sat, 2019-01-19 at 23:43 +0100, Pedro Pinho wrote:
> Back at home!
> I've just erased my disk using gpsrted-live usb and made a fresh
> install from the image here, 
> http://ftp.fr.netbsd.org/pub/NetBSD-daily/netbsd-8/201901151910Z/images/
> 
> NetBSD 8.0 STABLE arch amd64
> 
> Pointed pkgin to 
> http://ftp.fr.netbsd.org/pub/pkgsrc/packages/NetBSD/amd64/8.0/All/
> 
> and pulled my binary packages. Launching midori from xterm outputs
> libstdc++.so.7 is missing. Tried symlinking libsrdc++.so.8 to
> libstdc++.so.7 to no avail. Can't launch midori. 
> It would be ok with firefox but, as mentioned already, firefox is not
> there!!
> 
> Any suggestions?!

Please post the output of ldd against the midori binary.

Dave

Re: libstdc++.so.7 is missing

[David H. Gutteridge]

On Thu, 17 Jan 2019, at 14:43:18 +0100, Marc Baudoin wrote:
> Martin Husemann  écrit :
> > On Thu, Jan 17, 2019 at 02:35:34PM +0100, Pedro Pinho wrote:
> > > Nope, this was/is 8.0 from the start.
> > 
> > And you did not have any pkgs pre-installed?
> > 
> > The problem is that 8.0 had libstdc++.so.8.0, and nothing compiled for 8.0
> > should ever refer to libstdc++.so.7.
> 
> It depends where this libstdc++.so.7 is.  On my system (8.0 from
> the start also), gcc packages install several versions of
> libstdc++.so.7:
> 
> /usr/pkg/gcc6/lib/libstdc++.so.7
> /usr/pkg/gcc6/lib/libstdc++.so.7.22
> /usr/pkg/gcc6/lib/libstdc++.so.7.22-gdb.py
> /usr/pkg/gcc6/x86_64--netbsd/lib/libstdc++.so.7
> /usr/pkg/gcc6/x86_64--netbsd/lib/libstdc++.so.7.22
> /usr/pkg/gcc6/x86_64--netbsd/lib/libstdc++.so.7.22-gdb.py
> /usr/pkg/gcc8/lib/libstdc++.so.7
> /usr/pkg/gcc8/lib/libstdc++.so.7.25
> /usr/pkg/gcc8/lib/libstdc++.so.7.25-gdb.py

Yes, for NetBSD 7 and 8, firefox needs a newer version of GCC than the
base system provides, so you will end up with something like:

ldd /usr/pkg/lib/firefox/firefox

/usr/pkg/lib/firefox/firefox:
-lpthread.1 => /usr/lib/libpthread.so.1
-lc.12 => /usr/lib/libc.so.12
-lstdc++.7 => /usr/pkg/gcc6/x86_64--netbsd/lib/./libstdc++.so.7
-lm.0 => /usr/lib/libm.so.0
-lgcc_s.1 => /usr/pkg/gcc6/x86_64--netbsd/lib/./libgcc_s.so.1

So perhaps what happened is the necessary gcc-libs package (e.g., in my
example above, gcc6-libs) didn't get pulled in for some reason.

Dave

Re: libstdc++.so.7 is missing

[David H. Gutteridge]

On Thu, 17 Jan 2019, at 11:57:36 -0600, Robert Nestor wrote:
>[...]
>One good example is if I check out the sources for pkgsrc-2018Q4 and
>try building the meta-pkg xfce4 it fails, but the binary archive for it
>exists on the server.  Assuming the sources are the same for both my
>build and the one that was posted on the server then the question
>becomes, what’s different in the two build setups? [...]

Could you provide the specific error you're seeing when trying to build
meta-pkgs/xfce4?

Dave

Re: Wireless USB Adapter

[David H. Gutteridge]

On Mon, 01 Oct 2018, at 22:40:48 +, imgli...@protonmail.com wrote:
> So, I took a look at 
http://netbsd.gw.com/cgi-bin/man-cgi?urtwn+4.i386+NetBSD-8.0
> and despite the fact the my specific device is not listed on the
> hardware list, its chipset is listed as one of the supported ones.
> If the chipset is supported, then why it is loaded as ugen when I
> plug it on my laptop?

Hi,

In general, in order for a USB device to be recognized, your specific
device details have to be added to a devices list and the driver. While
I see someone else has already responded who's indicated it's not such
a simple matter with your specific device, adding the details is the
minimum required. (You reminded me I wanted to submit a PR to do this
for another WiFi USB device, which is working for me:
http://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=53647 )

Regards,

Dave

man.netbsd.org is down

[David H. Gutteridge]

Hi,

I thought I'd mention it seems man.netbsd.org (a.k.a. netbsd.gw.com)
has been down for at least the last two days. (I happened to notice
because I have occasion to check NetBSD man pages while I don't have
access to a NetBSD machine.)

Regards,

Dave

Re: pflogd consume CPU

[David H . Gutteridge]

On 2016-02-07, at 10:39 PM, David H. Gutteridge wrote:
> On Sun, Feb 07, 2016 at 23:12:02 +0100, Manuel Bouyer wrote:
>> On Sun, Feb 07, 2016 at 08:06:35PM +0100, Manuel Bouyer wrote:
>>> On Mon, Feb 08, 2016 at 12:06:54AM +0900, Miwa Susumu wrote:
>>>> 2016-02-07 1:15 GMT+09:00 Christos Zoulas <christos%astron.com@localhost>:
>>>>>>>> pflogd process consume CPU.
>>>>>>>> Because of that in load average is too high.
>>>>>>> Can you ktrace it?
>>>>>> this is kdump output.
>>>>>> sakura# kdump ktrace.out
>>>>>>  974  1 pflogd   EMUL  "netbsd"
>>>>>>  974  1 pflogd   CALL  read(3,0xbb912000,0x8)
>>>>>>  974  1 pflogd   RET   read -1 errno 35 Resource temporarily 
>>>>>> unavailable
>>>>> And what does 'fstat -p 974' say about fd 3?
>>>> 
>>>> fd 3 is bpf.
>>> 
>>> I've seen something similar with arpwatch (might have been against bpf too),
>>> and with nagios reading a pipe (see my post today on current-users@
>>> about this).
>> 
>> I guess this is a 32bit host (i386 maybe) ?
> 
> I've been encountering this for the past few months on i386, as
> originally reported back in September. I haven't ever seen the same
> issue on evbarm, both architectures running 7.0_STABLE and using PF.
> 
> http://mail-index.netbsd.org/netbsd-users/2015/09/24/msg016939.html

I'm now encountering this on my evbarm machine as well. I'm not sure
why it's now acting up, as nothing's changed concerning the network
and nothing's changed concerning the machine other than releng
pull-ups to the netbsd-7 branch. Probably just co-incidence.

Dave

Re: pflogd consume CPU

[David H. Gutteridge]

On Sun, Feb 07, 2016 at 23:12:02 +0100, Manuel Bouyer wrote:
>On Sun, Feb 07, 2016 at 08:06:35PM +0100, Manuel Bouyer wrote:
>> On Mon, Feb 08, 2016 at 12:06:54AM +0900, Miwa Susumu wrote:
>> > 2016-02-07 1:15 GMT+09:00 Christos Zoulas :
>> > pflogd process consume CPU.
>> > Because of that in load average is too high.
>> > >>> Can you ktrace it?
>> > >>this is kdump output.
>> > >>sakura# kdump ktrace.out
>> > >>   974  1 pflogd   EMUL  "netbsd"
>> > >>   974  1 pflogd   CALL  read(3,0xbb912000,0x8)
>> > >>   974  1 pflogd   RET   read -1 errno 35 Resource temporarily 
>> > >> unavailable
>> > > And what does 'fstat -p 974' say about fd 3?
>> > 
>> > fd 3 is bpf.
>> 
>> I've seen something similar with arpwatch (might have been against bpf too),
>> and with nagios reading a pipe (see my post today on current-users@
>> about this).
>
>I guess this is a 32bit host (i386 maybe) ?

I've been encountering this for the past few months on i386, as
originally reported back in September. I haven't ever seen the same
issue on evbarm, both architectures running 7.0_STABLE and using PF.

http://mail-index.netbsd.org/netbsd-users/2015/09/24/msg016939.html

Regards,

Dave

Issue with pflogd consuming 100% of CPU

[David H. Gutteridge]

Hi all,

On one of my machines I'm finding that pflogd consistently ends up
getting stuck in a loop where it consumes close to 100% of the CPU.
This is with the netbsd-7 branch, on i386. This never happens on an
evbarm machine, also running netbsd-7, with a similar use case, which
is curious.

I tried using ktrace, which doesn't really tell me all that much
beyond that it's looping trying to access a resource that never
becomes available. I don't see any command line options that would
increase pflogd's verbosity or such. And it doesn't log anything
useful. All I get from ktrace is:

1055  1 pflogd   RET   read -1 errno 35 Resource temporarily unavailable
1055  1 pflogd   CALL  read(3,0xbb912000,0x8)

Has anyone else seen this? Or has any insight? (Other than suggesting
alternate packet filters...)

I've been using PF on NetBSD for over ten years and have never seen
this issue before. I have to manually restart pflogd regularly to work
around this, which is kind of annoying.

Regards,

Dave