daily CVS update output
Updating src tree: P src/bin/sh/sh.1 Updating xsrc tree: Killing core files: Updating file list: -rw-rw-r-- 1 srcmastr netbsd 48416323 Sep 1 03:03 ls-lRA.gz
Re: modesetting vs intel in 10.0
On Thu, Aug 31, 2023 at 09:17:35PM +0100, Mike Pumford wrote: > On 30/08/2023 09:56, nia wrote: > > > I think detecting the year of manufacture is too much of a hard > > problem - there are simply too many new cards and I have no idea > > about a "cutoff point" where modesetting starts being OK (if it > > even isn't okay for any old cards at all - it should work as long > > as DRM/KMS works AFAIK) > > > Well speaking as someone whose older card worked fine under 9 and now just > ends up as a black screen with both the intel driver and the modesetting one > on 10.0. I'm more interesting in getting back to having a working > accelerated X setup. I did see the tearing on the intel driver on 9.x but it > was never bad enough to make me try the modesetting driver. > > For reference my now broken hardware is: > [ 1.008474] pci1: i/o space, memory space enabled, rd/line, wr/inv ok > [ 1.008474] i915drmkms0 at pci0 dev 2 function 0: Intel Haswell > Integrated Graphics Device (rev. 0x06) > > See kern/57268 for how my hardware fails. > > Mike OK, but this is not the question
Re: Repository conversion is temporarily suspended
Taylor R Campbell wrote in <20230831100948.710dd60...@jupiter.mumble.net>: |The automatic conversion of the NetBSD CVS repository to Fossil, Hg, |and Git is temporarily suspended until 2023-09-08. Not to mention FYI that git generated a "forced update" (ie not a clean fast-forward) here on my last monthly fetch of [remote "origin"] url = https://github.com/NetBSD/src.git fetch = +refs/heads/trunk:refs/remotes/origin/trunk fetch = +refs/heads/netbsd-8:refs/remotes/origin/netbsd-8 fetch = +refs/heads/netbsd-9:refs/remotes/origin/netbsd-9 Hasn't happened for long. |The rack space donated to TNF for the infrastructure is undergoing |renovation from 2023-08-28 to 2023-09-08. --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
Re: modesetting vs intel in 10.0
On 30/08/2023 09:56, nia wrote: I think detecting the year of manufacture is too much of a hard problem - there are simply too many new cards and I have no idea about a "cutoff point" where modesetting starts being OK (if it even isn't okay for any old cards at all - it should work as long as DRM/KMS works AFAIK) > Well speaking as someone whose older card worked fine under 9 and now just ends up as a black screen with both the intel driver and the modesetting one on 10.0. I'm more interesting in getting back to having a working accelerated X setup. I did see the tearing on the intel driver on 9.x but it was never bad enough to make me try the modesetting driver. For reference my now broken hardware is: [ 1.008474] pci1: i/o space, memory space enabled, rd/line, wr/inv ok [ 1.008474] i915drmkms0 at pci0 dev 2 function 0: Intel Haswell Integrated Graphics Device (rev. 0x06) See kern/57268 for how my hardware fails. Mike
Re: ERROR: No valid Python version
On Thu, 31 Aug 2023 at 14:14, Greg Troxel wrote: > > Chavdar Ivanov writes: > > > > > --- > > ===> Building binary package for libxslt-1.1.38nb1 > > => Creating binary package /usr/pkgsrc/packages/All/libxslt-1.1.38nb1.tgz > > ===> Installing binary package of libxslt-1.1.38nb1 > > pkg_add: A different version of libxslt-1.1.38nb1 is already > > installed: libxslt-1.1.38 > > pkg_add: 1 package addition failed > > *** Error code 1 > > > > > > The test run of 'pkg_chk -uq' has identified libxslt as a target for > > upgrade, but it is for some reason missing from the final list of > > installed packages as found by it, so it tries to install it instead > > of replace. > > > > This is done after 'pkgin ar', 'pkg_admin rebuild-tree', 'pkg_admin > > rebuild' and the above. I was running 'pkg_rolling-replace -suv' at > > the time. > > You snipped too much log; presumably it was replacing something else. Yes, it was replacing cmake at the time, which eventually needed libxslt. > > I don't know what's going on, and would suggest turning on set -x and > tracing the logs to see. My assumption on duty in these occasions is always that the problem is with my local tree and with the occasional messing I do with it; I try to avoid bothering the list with these and to find a solution myself; I mentioned the issue as I have had it a few times before. One reason might be that I started using 'pkg_rr -suv' recently, before I used to use ' -uvk', which, albeit not safe, at least goes through the whole process without intervention and usually does the job (but I understand why it shouldn't be used). I'll try to trace it. Chavdar --
Re: ERROR: No valid Python version
Chavdar Ivanov writes: > > --- > ===> Building binary package for libxslt-1.1.38nb1 > => Creating binary package /usr/pkgsrc/packages/All/libxslt-1.1.38nb1.tgz > ===> Installing binary package of libxslt-1.1.38nb1 > pkg_add: A different version of libxslt-1.1.38nb1 is already > installed: libxslt-1.1.38 > pkg_add: 1 package addition failed > *** Error code 1 > > > The test run of 'pkg_chk -uq' has identified libxslt as a target for > upgrade, but it is for some reason missing from the final list of > installed packages as found by it, so it tries to install it instead > of replace. > > This is done after 'pkgin ar', 'pkg_admin rebuild-tree', 'pkg_admin > rebuild' and the above. I was running 'pkg_rolling-replace -suv' at > the time. You snipped too much log; presumably it was replacing something else. I don't know what's going on, and would suggest turning on set -x and tracing the logs to see.
Re: ERROR: No valid Python version
While on the topic of pkg_rr, if I'm permitted to cut in, I have been getting strange errors suggesting a problem with the topological order of replacement perhaps: --- ===> Building binary package for libxslt-1.1.38nb1 => Creating binary package /usr/pkgsrc/packages/All/libxslt-1.1.38nb1.tgz ===> Installing binary package of libxslt-1.1.38nb1 pkg_add: A different version of libxslt-1.1.38nb1 is already installed: libxslt-1.1.38 pkg_add: 1 package addition failed *** Error code 1 The test run of 'pkg_chk -uq' has identified libxslt as a target for upgrade, but it is for some reason missing from the final list of installed packages as found by it, so it tries to install it instead of replace. This is done after 'pkgin ar', 'pkg_admin rebuild-tree', 'pkg_admin rebuild' and the above. I was running 'pkg_rolling-replace -suv' at the time. So it's manual replace and restart - again. Chavdar On Wed, 30 Aug 2023 at 14:59, Greg Troxel wrote: > > Riccardo Mottola writes: > > > Hi, > > > > Greg Troxel wrote: > >> did you cd to devel/scons (or really the PKGPATH of the installed pkg) > >> and type "make replace". The pkg_rr man page says, or should say, to do > >> that, and then to deal with that error as if it were not from pkg_rr. > > > > no, I didn't... I thought to have encountered some weird setup > > error. I did now. It fails with a cryptic message: > > the man page for pkg_rr asks that people not report "some make replace > that pkg_rr did failed" as a pkg_rr problem, because it's not really > true but mostly because the subset of peopel that don't like pkg_rr then > ignore your report, whereas some of them could perhaps be helpful if it > is properly reported as a simpler failure. > > >> perhaps, scons 3 is now limited to py27. > > > > Well it is trying to build the py27 version, also it is more "sane > > now" since it says: > > py27-scons-3.1.2nb7while with pkg_rr it was confused between the py310 > > and the "none" version: > > > > RR> Replacing py310-scons-3.1.2nb4 > > ===> Cleaning for none-scons-3.1.2nb7 > > > > In fact at the moment I have this one installed, according to pkg_info > > > > py310-scons-3.1.2nb4 Python-based, open-source build system > > > > so I suppose pkg_rr was right trying to subdtitute the py3 version > > Yes, the basic issue is that new scons3 dropped support for py3, and the > basic solution is to upgrade to 4, but we don't really have support for > that, and 99% people only have scons as a build tool (because somebody > else wrongly thought it was better than autoconf 5 years ago :-). > > >> I recommend "pkgin ar" before a rebuild run. > > > > Now it is a little late :-P > > You can still do it and continue. Unless you actually *want* scons3, > removing it is best. The tools that are needed for other things will > get built. > --
Repository conversion is temporarily suspended
The automatic conversion of the NetBSD CVS repository to Fossil, Hg, and Git is temporarily suspended until 2023-09-08. The rack space donated to TNF for the infrastructure is undergoing renovation from 2023-08-28 to 2023-09-08. Apologies for the inconvenience.
