daily CVS update output

2024-03-21 Thread NetBSD source update


Updating src tree:
P src/lib/libc/gen/sysconf.3
P src/share/man/man4/acpihed.4
P src/sys/dev/pci/if_vioif.c

Updating xsrc tree:


Killing core files:




Updating file list:
-rw-rw-r--  1 srcmastr  netbsd  45962062 Mar 22 03:03 ls-lRA.gz


Re: make replace failing with python module conflicts

2024-03-21 Thread Riccardo Mottola
Hi Greg!

it's always you replying to me.. thank you! Long time NetBSD...

Greg Troxel wrote:
> Two options:
> 
>   A) pkg_delete -f the py311-foo that are now included in python base
>   package
> 
>   B) using pbulk, a separate machine, etc., build a binary package set of
>   everything you need and update with pkgin
> 
>   (use someone else's binary packagss, but this is like B)
> 


ok solution A) was the one I tried to avoid... but went for it. I
continued repeating pkg_rolling-replace -uv several times.
Python packages were a nightmare. e.g suppse "py-foo" it exists several
times for different python versions.
py27-foo, py310-foo, py31-foo and so on.

First run, it works, e.g. py310 version. Then it tries to build py311
and  pkg_rr finds a stale workdir and bails out. I manually make a
clean, restart and it will die at the next one and so on.

Now, after the python nightmare seems done... other packages built and I
end with pkg_rr building "nothing".

lintpkgsrc tells me:

Scan Makefiles: 19568 packages
Version mismatch: 'py-cairo' 1.18.2nb5 vs 1.26.0
Unknown package: 'py-gobject' version 2.28.7nb5
Unknown package: 'py-gtk2' version 2.24.0nb47
Version mismatch: 'py-setuptools' 44.1.1nb1 vs 69.1.1


so I have two packages which don't exist? pkg_info doesn't know about
them.. and two mismatched packages

Riccardo

PS: is there some tool to check reverse library dependencies in NetBSD?
a bit like rev-upgrade of MacPorts or Gentoo's revdep-rebuild.. just to
know everything is consistent looking at the binrary, since the
rebuiild-tree could be incomplete tue to unknown packages


Re: gdb crashes on current

2024-03-21 Thread Brett Lymn
On Wed, Mar 20, 2024 at 10:02:41PM +, Patrick Welche wrote:
> 
> Just had a go, and "tui enable" doesn't get as far as libcurses
> 

How odd.  I tried this on my system which was last updated June 14 last
year and both running gdb then doing tui enable or just running gdb -tui
Just Works(tm).

I have gdb:

GNU gdb (GDB) 11.0.50.20200914-git

I guess I will have to update and see what happens.

> 
> but "gdb -tui" does:
> 
> Thread 1 "" received signal SIGSEGV, Segmentation faultprefresh (pad=0x0, 
> pbegy=0, pbegx=0, sbegy=1, sbegx=5, smaxy=0, smaxx=78)
> at /usr/src/lib/libcurses/refresh.c:511
> 511 pad->pbegy = pbegy;
> (gdb) bt
> #0  prefresh (pad=0x0, pbegy=0, pbegx=0, sbegy=1, sbegx=5, smaxy=0, smaxx=78)
> at /usr/src/lib/libcurses/refresh.c:511

Pad being NULL is a Bad Thing.  That variable should contain a pointer
to a WINDOW structure.

-- 
Brett Lymn
--
Sent from my NetBSD device.

"We are were wolves",
"You mean werewolves?",
"No we were wolves, now we are something else entirely",
"Oh"