nia <nia%NetBSD.org@localhost> writes: > On Wed, Aug 03, 2022 at 11:55:49AM -0400, Greg Troxel wrote: >> The hypothesis remains that there are no people that use NetBSD-8 with >> big desktop-type GUI programs that are obtained from TNF builds. There is still no counterexample to that statement. >> And therefore that we don't need to care e.g. that firefox might not >> work in recent official package sets. > > Saying it's just firefox is doing the brokenness a disservice. You are right that "just firefox" is off, but that's not what I said. I really meant "e.g." and thought about that phrasing. > Let's look at what's actually failing in the latest bulk build for -8: ok, and I am looking at what is on ftp.netbsd.org in the x86_64/8.0_2022Q2/All directory, as well as i386. > - lots of random python libraries 8/amd64 has 1491 py39-* packages. 9/aarch64 has 1515. The 9/amd64 build has 1426 this minute, and it's obviously not finished. So apparently 24 are missing. > - fortran [scietific python, etc...] -rw-r--r-- 1 pkgmastr netbsd 126932 Jul 24 01:02 amd64/8.0_2022Q2/All/blas-3.10.1.tgz -rw-r--r-- 1 pkgmastr netbsd 114860 Jul 27 23:32 i386/8.0_2022Q2/All/blas-3.10.1.tgz -rw-r--r-- 1 pkgmastr netbsd 3468436 Jul 24 01:24 amd64/8.0_2022Q2/All/lapack-3.10.1.tgz -rw-r--r-- 1 pkgmastr netbsd 3011388 Jul 27 23:45 i386/8.0_2022Q2/All/lapack-3.10.1.tgz -rw-r--r-- 1 pkgmastr netbsd 5309116 Jul 24 07:16 x86_64/8.0_2022Q2/All/py39-numpy-1.22.4nb2.tgz -rw-r--r-- 1 pkgmastr netbsd 5318028 Jul 28 00:20 i386/8.0_2022Q2/All/py39-numpy-1.22.4nb2.tgz [scipy I don't find] > - poppler -rw-r--r-- 1 pkgmastr netbsd 7446036 Jul 24 07:25 amd64/8.0_2022Q2/All/poppler-22.04.0.tgz -rw-r--r-- 1 pkgmastr netbsd 7263644 Jul 28 00:26 i386/8.0_2022Q2/All/poppler-22.04.0.tgz > - librsvg desktop, more or less. But on x86_64: -rw-r--r-- 1 pkgmastr netbsd 162896 Jul 20 13:09 x86_64/8.0_2022Q2/All/librsvg-2.40.21nb8.tgz -rw-r--r-- 1 pkgmastr netbsd 13093316 Jul 16 21:06 x86_64/8.0_2022Q2/All/librsvg-2.54.4.tgz There is some humor there about 'modern' and 80x bloat. > - nodejs enormous. unportable upstream; not much we can do. Older versions are there: -rw-r--r-- 1 pkgmastr netbsd 7471492 Jul 12 02:09 x86_64/8.0_2022Q2/All/nodejs-12.22.12nb1.tgz -rw-r--r-- 1 pkgmastr netbsd 7810332 Jul 27 13:29 x86_64/8.0_2022Q2/All/nodejs-14.20.0.tgz > - graphviz -rw-r--r-- 1 pkgmastr netbsd 4068352 Jul 9 13:26 i386/8.0_2022Q2/All/graphviz-2.50.0nb5.tgz -rw-r--r-- 1 pkgmastr netbsd 4483728 Jul 16 18:36 x86_64/8.0_2022Q2/All/graphviz-2.50.0nb5.tgz > - haskell unportable upstream; not much we can do. Not on i386, but: -rw-r--r-- 1 pkgmastr netbsd 70939864 Jul 8 20:45 x86_64/8.0_2022Q2/All/ghc-7.10.3nb7.tgz -rw-r--r-- 1 pkgmastr netbsd 78441444 Jul 12 04:03 x86_64/8.0_2022Q2/All/ghc-8.0.2nb6.tgz -rw-r--r-- 1 pkgmastr netbsd 149137664 Jul 8 20:38 x86_64/8.0_2022Q2/All/ghc-8.10.4nb4.tgz -rw-r--r-- 1 pkgmastr netbsd 115155444 Jul 27 01:51 x86_64/8.0_2022Q2/All/ghc-8.4.4nb6.tgz -rw-r--r-- 1 pkgmastr netbsd 143452332 Jul 8 16:26 x86_64/8.0_2022Q2/All/ghc-8.8.4nb6.tgz -rw-r--r-- 1 pkgmastr netbsd 147869380 Jul 8 16:06 x86_64/8.0_2022Q2/All/ghc-9.0.2nb1.tgz -rw-r--r-- 1 pkgmastr netbsd 153370528 Jul 24 08:09 x86_64/8.0_2022Q2/All/ghc-9.2.1nb2.tgz and pandoc is there too. > - gcc7 -rw-r--r-- 1 pkgmastr netbsd 61861916 Jul 27 23:28 i386/8.0_2022Q2/All/gcc7-7.5.0nb5.tgz -rw-r--r-- 1 pkgmastr netbsd 59762296 Jul 24 00:54 x86_64/8.0_2022Q2/All/gcc7-7.5.0nb5.tgz -rw-r--r-- 1 pkgmastr netbsd 67170524 Jul 10 07:52 i386/8.0_2022Q2/All/gcc8-8.4.0nb5.tgz -rw-r--r-- 1 pkgmastr netbsd 69024484 Jun 29 17:23 x86_64/8.0_2022Q2/All/gcc8-8.4.0nb5.tgz -rw-r--r-- 1 pkgmastr netbsd 67058236 Jun 30 17:36 i386/8.0_2022Q2/All/gcc9-9.3.0nb7.tgz -rw-r--r-- 1 pkgmastr netbsd 65079584 Jul 25 14:53 x86_64/8.0_2022Q2/All/gcc9-9.3.0nb7.tgz -rw-r--r-- 1 pkgmastr netbsd 76646492 Jun 29 03:47 i386/8.0_2022Q2/All/gcc10-10.3.0nb1.tgz -rw-r--r-- 1 pkgmastr netbsd 78897172 Jun 30 20:04 x86_64/8.0_2022Q2/All/gcc10-10.3.0nb1.tgz -rw-r--r-- 1 pkgmastr netbsd 89135768 Jul 1 12:02 i386/8.0_2022Q2/All/gcc12-12.1.0.tgz -rw-r--r-- 1 pkgmastr netbsd 91517720 Jul 5 15:28 x86_64/8.0_2022Q2/All/gcc12-12.1.0.tgz > - R -rw-r--r-- 1 pkgmastr netbsd 47744040 Jul 28 00:04 i386/8.0_2022Q2/All/R-4.2.0.tgz -rw-r--r-- 1 pkgmastr netbsd 47856880 Jul 24 04:35 x86_64/8.0_2022Q2/All/R-4.2.0.tgz > - erlang (bugs in Xen; -9 has a xenclock driver that works around it) ah, the only 'build bug' we have found so far. > ... and now the "desktop" stuff: > > - xfce > - mate > - qt5 > - fltk squarely "big GUI desktop", especially qt5. But the others are present. -rw-r--r-- 1 pkgmastr netbsd 1912 Jul 26 18:27 x86_64/8.0_2022Q2/All/xfce4-4.16.0nb3.tgz -rw-r--r-- 1 pkgmastr netbsd 1948 Jul 26 19:56 x86_64/8.0_2022Q2/All/mate-1.24.1nb1.tgz -rw-r--r-- 1 pkgmastr netbsd 1155436 Jul 10 09:57 i386/8.0_2022Q2/All/fltk-1.3.8.tgz -rw-r--r-- 1 pkgmastr netbsd 1154188 Jul 17 02:39 x86_64/8.0_2022Q2/All/fltk-1.3.8.tgz > The stuff that works is mostly the simplest (just C, no C++ or only > really old C++ standards) headless packages, your standard > apache/php/nginx/postgres job, which people can easily build > themselves. We are 99.9% talking about "what builds on the branch", and have identified only erlang as being troubled in this particular bulk build environment. > I'd say it'd be most honest to discontinue NetBSD 8 builds rather > than continue uploading really broken ones. For i386/8 there are only 1285 fewer packages than i386/9, so literally 95% of the packages for 9 are available on 8. Sure, there are some issues and many would matter for various people, but it's not "really broken" in a structural sense. Aside from erlang, the "build" is not broken, is what I take away from what you said. What has happened is that the upstream world has made changes that cause their packages to no longer build on old systems, and nobody, including the pkgsrc community, has fixed those upstreams. I don't think it's dishonest to have builds of what works. Really you have said that "8 is something that should no longer be used by anybody who wants to run code maintained by people who think it's ok to require recent compilers". I agree but the nature of free software is that people are welcome to run it. I also don't see it as a bug in pkgsrc if something doesn't build in pkgsrc if it does not build when manually following the upstream build instructions. If you think the statement in the announcements should be extended, please feel free to send text. Perhaps Note that many packages do not build on NetBSD 8 and other systems with non-recent compilers. Users of those systems are advised to check, as each branch is released, if what they would like to run is still buildable. (Most people contributing to pkgsrc run newer base systems.) would be better? Are there really people running 8 who do not understand what is going on? I sent a message inquiring about that, and so far *zero* people have admitted publically or privately to using the 8 builds on ftp.netbsd.org. Yes, a few people are running 8 but none of them has said that things they need aren't available; they are all well aware of this and running moderate server-type stuff. I don't think we should formally de-support NetBSD 8 prematurely. What support in pkgsrc really means is that we don't allow infrastructure changes that break 8. Upstreams breaking 8 is not something we can control, and we don't hold back updates. People who want to add optional old versions can do so, and there's a bit of that. All in all I don't think it's a good use of time to worry about this too much. Old operating systems age out for running new software -- that's just how the world is. People who want to struggle against that can, but I think they should work on fixing upstreams.
Attachment:
signature.asc
Description: PGP signature