Re: lang/mono6 fails build under -current

[Chavdar Ivanov <ci4ic4%gmail.com@localhost>]

On Fri, 15 May 2020 at 22:44, <maya%netbsd.org@localhost> wrote:
>
> On Tue, May 12, 2020 at 02:41:19PM +0100, Chavdar Ivanov wrote:
> > On Tue, 12 May 2020 at 14:03, <maya%netbsd.org@localhost> wrote:
> > >
> > > On Mon, May 11, 2020 at 05:25:03PM +0100, Chavdar Ivanov wrote:
> > > > Has anybody been able to build lang/mono6 under reasonably recent
> > > > -current? I keep getting exciting crashes in various places, seem not
> > > > to repeat, e.g.
> > >
> > >
> > > I can build it.
> > >
> > > Setup:
> > > userland: 9.99.51 (early March)
> > > kernel: 9.99.59 (early May)
> >
> > Userland and kernel from yesterday, 11th of May
> > >
> > > GCC 8.4.0
> >
> > Ditto
> >
> > > binutils 2.31.1
> >
> > As far as I can see it, on this version of the system it is 2.34:
> >
> > nm -V
> > GNU nm (NetBSD Binutils nb1) 2.34.
> >
> > I never run kernel and userland from different versions, as I use
> > sysbuild and sysupgrade.
>
>  I am failing to reproduce it on 9.99.61. Any other guesses for what
>  might be different on your setup?

No idea. It is a laptop with i7-3820QM CPU and 20GB memory, following
-current, both the OS and pkgsrc, with many pkg_rolling-replace under
its belt. Perhaps it is time to reinstall it...

I spun a new VM (XCP-NG pvhvm domU, with just 4 virtual CPUs and 2GB
memory), extracted and updated pkgsrc as of yesterday, mono6 built
fine and I was then able to install the package on the troubled
system:

$ mono --version
Mono JIT compiler version 6.8.0.105 (tarball Sat May 16 22:47:11 BST 2020)
Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors.
www.mono-project.com
        TLS:           __thread
        SIGSEGV:       normal
        Notification:  kqueue
        Architecture:  amd64
        Disabled:      none
        Misc:          softdebug
        Interpreter:   yes
        LLVM:          supported, not enabled.
        Suspend:       preemptive
        GC:            sgen (concurrent by default)

The thing is, while pkg_rolling-replace does simplify the gradual
updates of packages, there are situations it can't deal with; e.g. 4-5
days ago I updated and ran pkg_rolling-replace, which completed rather
well, with only about 10 packages failing due to being obsoleted etc.;
all the tex packages I have installed upgraded without a problem.
Yesterday I did another update, this time rolling-replace rendered
hundreds of failed upgrades among the tex packages. The reason (one of
the reasons) turned out to be a new version of kpathsea - 6.3.2 -
which now depends on mktexlsr package; this one has been split from
kpathsea and contains a file - well, mktexlsr - which is also part of
kpathsea-6.3.1; so mktexlsr can't be installed over kpathsea, and
kpathsea can't be upgraded as mktexlsr is missing... And this was not
the only problem.





-- 
----