Thank you for the heads-up. Building everything from source on this machine is not viable. I have a 32GB SSD and the building directories would probably "eat that up". I had no issue moving from 2018Q1 to Q2 (well except for a sync delay and a lost symlink to 8 quickly solved by posting here) or from Q2 to Q3. As mentioned, I just love minimalism and this system is a keeper, currently 2.6GB used disk space and I hardly need anything else. I can, and most probably will, roll back to 2018Q3, or even to current but, the thing is that something is wrong with 2018Q4 binaries,again firefox was just an example, as I happen to come across it when midori failed to launch but, there could be more.
Den tors 17 jan. 2019 kl 20:15 skrev Robert Nestor <rnes...@mac.com>: > I’ve noticed inconsistencies with the pre-built package archives since > about the time of NetBSD 6.2. Whenever I’ve done a clean install of NetBSD > (7.x , 8.x or -current) and then try to install some packages from almost > any corresponding package archive, I usually run into issues with > incompatible libraries. I’m not sure how it happens that packages in the > archive end up this way. > > One solution I’ve been trying with some success is to checkout the pkgsrc > that corresponds to the archive I want to use and build the packages that > are of interest to me using a pbulk build setup. However, that exposes > another issues that has me completely stumped - some packages that exist in > the package archive fail to build on my system. 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? I’m beginning to suspect that maybe the packages in the 2018Q4 > archive on the server were not built under a stock NetBSD 8.0 system, or > there are some special setups used that aren’t reflected in the pkg build > setup. It might be interesting to compare the contents of mk.conf for > example it see if that might explain the differences.
