NetBSD Problem Report #59530

From www@netbsd.org  Fri Jul 18 05:46:05 2025
Return-Path: <www@netbsd.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256
	 client-signature RSA-PSS (2048 bits) client-digest SHA256)
	(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id 4FD071A9239
	for <gnats-bugs@gnats.NetBSD.org>; Fri, 18 Jul 2025 05:46:05 +0000 (UTC)
Message-Id: <20250718054603.DEFA31A923A@mollari.NetBSD.org>
Date: Fri, 18 Jul 2025 05:46:03 +0000 (UTC)
From: netbsd.open.source@softhome.ca
Reply-To: netbsd.open.source@softhome.ca
To: gnats-bugs@NetBSD.org
Subject: Ports: lsof : The Operating System version (10.1) does not match 10.0
X-Send-Pr-Version: www-1.0

>Number:         59530
>Category:       pkg
>Synopsis:       Ports: lsof : The Operating System version (10.1) does not match 10.0
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    pkg-manager
>State:          analyzed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Jul 18 05:50:00 +0000 2025
>Closed-Date:    
>Last-Modified:  Tue Sep 02 06:30:02 +0000 2025
>Originator:     John L. Males
>Release:        10.1
>Organization:
>Environment:
NetBSD hostname.domain 10.1 NetBSD 10.1 (GENERIC) #0: Mon Dec 16 13:08:11 UTC 2024  mkrepro@mkrepro.NetBSD.org:/usr/src/sys/arch/amd64/compile/GENERIC amd64
>Description:
When tried to install lsof via pkgin received message "The Operating System version (10.1) does not match 10.0".

The reason for high priority is I feel lsof information is needed to report a serious bug with potential to cause premature ssd or NVMe wear/failure.
>How-To-Repeat:
1) Clean install of NetBSD 10.1 via "https://cdn.netbsd.org/pub/NetBSD/NetBSD-10.1/images/NetBSD-10.1-amd64-install.img.gz".

2) As root user install pkgin via pkg_add per:
export PKG_PATH=http://ftp.netbsd.org/pub/pkgsrc/packages/NetBSD/amd64/10.1/All
pkg_add -v pkgin

3) As root user install any package(s):
pkgin install lscpu dmidecode

4) As root user install lsof:
pkgin install lsof

5) Console result of (4):

calculating dependencies...done.

2 packages to install:
  lsof-4.91nb7 osabi-NetBSD-10.0

0 to remove, 0 to refresh, 0 to upgrade, 2 to install
298K to download, 1067K of additional disk space will be used

proceed ? [Y/n] y
[1/2] lsof-4.91nb7.tgz                                                                                                                                      100%  295KB 294.6KB/s   00:00    
[2/2] osabi-NetBSD-10.0.tgz                                                                                                                                 100% 3284     3.2KB/s   00:00    
[1/2] installing osabi-NetBSD-10.0...
The Operating System version (10.1) does not match 10.0
To force installation of this package, add CHECK_OSABI=no to pkg_install.conf
[2/2] installing lsof-4.91nb7...
The Operating System version (10.1) does not match 10.0
To force installation of this package, add CHECK_OSABI=no to pkg_install.conf
pkg_install warnings: 0, errors: 3
pkg_install error log can be found in /var/db/pkgin/pkg_install-err.log
reading local summary...
processing local summary...

Note I had installed xfce4 and various GUI and cli programs prior to installing lsof.  I have shortened how to repeat problem to cli based to save time in hopes my assumption how to repeat is as noted above.



>Fix:

>Release-Note:

>Audit-Trail:

Responsible-Changed-From-To: port-amd64-maintainer->pkg-manager
Responsible-Changed-By: gutteridge@NetBSD.org
Responsible-Changed-When: Fri, 18 Jul 2025 12:09:06 +0000
Responsible-Changed-Why:
pkgsrc ticket.

State-Changed-From-To: open->feedback
State-Changed-By: gutteridge@NetBSD.org
State-Changed-When: Fri, 18 Jul 2025 12:26:56 +0000
State-Changed-Why:
The lsof package contains patching that can be very specific to a
kernel change (which is sometimes internal and not even marked by a
version bump), so it sets OSVERSION_SPECIFIC as a warning, which has
the ramification you're seeing here.

TNF binary packages are built to match any major version, against the
earliest release (10.0 in this case), so this will trigger the mismatch
error by design. For 10.0 vs 10.1, there should be no actual issue for
this package.

You have two options here. One is to simply follow the instructions in
the message, that is, "add CHECK_OSABI=no to pkg_install.conf". That
should be safe to do in this context (with this package). The other is
to build the package from source instead. (That brings its own not
recommended approach of mixing binary and locally-built packages, but
is relatively simple for this particular example.)

From: "John L. Males" <netbsd.open.source@softhome.ca>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: pkg/59530 (Ports: lsof : The Operating System version (10.1)
 does not match 10.0)
Date: Sat, 19 Jul 2025 03:43:11 +0000

 Hello,

 Thanks for reply.

 I need to cover important points related to reply, but will not be
 able to do so for several days.

 The reason for several days to reply with important points to this
 bug is I need to organized alot of information due to pkgin install
 of some needed archive application few hours ago trashed my NetBSD
 system in very extensive serious ways. I has taken me few hours
 to at least return to sort of OK with my NetBSD system.  I still
 have alot of damage assessment to still conduct and if issues still
 exist how I need to fix any outstanding damage issues.  Once I have
 complete damage assessment for what damage I can at least find that
 will need to have additional information taken this extensive
 information needs to be organized before I can even attempt to open
 a new bug report in likewise organized manner and detail.

 Once I have the bug report of pkgin trashing my NetBSD system
 submitted I will return to this bug report to cover important
 points related to prior reply of this bug report.



 John L. Males
 Toronto, Ontario
 Canada

 2025-07-19 03:28+0000 UTC eMail Start
 2025-07-19 03:43+0000 UTC
 2025-07-18 23:43-0400 EDT

 *****Not GPG/PG Signed*****



 On Date: Fri, 18 Jul 2025 12:26:56 +0000 (UTC)
 From: gutteridge@NetBSD.org
 To:
 pkg-manager@netbsd.org,pkgsrc-bugs@netbsd.org,gnats-admin@netbsd.org,gutteridge@NetBSD.org,netbsd.open.source@softhome.ca
 Cc: Subject: Re: pkg/59530 (Ports: lsof : The Operating System
 version (10.1) does not match 10.0)
 [snip]

From: "John L. Males" <netbsd.open.source@softhome.ca>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: pkg/59530
Date: Sat, 19 Jul 2025 05:36:08 +0000

 Hello,

 I have sense my prior attempt to update the bug report was not
 successful.

 I am sending eMail in hopes this attempt will update the bug report.


 John L. Males
 Toronto, Ontario
 Canada

 2025-07-19 05:32+0000 UTC eMail Start
 2025-07-19 05:36+0000 UTC
 2025-07-19 01:36-0400 EDT

 *****Not GPG/PG Signed*****



 On Date: Sat, 19 Jul 2025 04:30:03 +0000 (UTC)
 From: "John L. Males via gnats" <gnats-admin@NetBSD.org>
 To:
 pkg-manager@netbsd.org,gnats-admin@netbsd.org,pkgsrc-bugs@netbsd.org,netbsd.open.source@softhome.ca
 Cc: Subject: Re: pkg/59530 (Ports: lsof : The Operating System
 version (10.1) does not match 10.0)



 > The following reply was made to PR pkg/59530; it has been noted
 > by GNATS.
 > 
 > From: "John L. Males" <netbsd.open.source@softhome.ca>
 > To: gnats-bugs@netbsd.org
 > Cc: 
 > Subject: Re: pkg/59530 (Ports: lsof : The Operating System
 > version (10.1) does not match 10.0)
 > Date: Sat, 19 Jul 2025 03:43:11 +0000
 > 
 >  Hello,
 >  
 >  Thanks for reply.
 >  
 >  I need to cover important points related to reply, but will not
 > be able to do so for several days.
 >  
 >  The reason for several days to reply with important points to
 > this bug is I need to organized alot of information due to pkgin
 > install of some needed archive application few hours ago trashed
 > my NetBSD system in very extensive serious ways. I has taken me
 > few hours to at least return to sort of OK with my NetBSD
 > system.  I still have alot of damage assessment to still conduct
 > and if issues still exist how I need to fix any outstanding
 > damage issues.  Once I have complete damage assessment for what
 > damage I can at least find that will need to have additional
 > information taken this extensive information needs to be
 > organized before I can even attempt to open a new bug report in
 > likewise organized manner and detail. 
 >  Once I have the bug report of pkgin trashing my NetBSD system
 >  submitted I will return to this bug report to cover important
 >  points related to prior reply of this bug report.
 >  
 >  
 >  
 >  John L. Males
 >  Toronto, Ontario
 >  Canada
 >  
 >  2025-07-19 03:28+0000 UTC eMail Start
 >  2025-07-19 03:43+0000 UTC
 >  2025-07-18 23:43-0400 EDT
 >  
 >  *****Not GPG/PG Signed*****
 >  
 >  
 >  
 >  On Date: Fri, 18 Jul 2025 12:26:56 +0000 (UTC)
 >  From: gutteridge@NetBSD.org
 >  To:
 >  pkg-manager@netbsd.org,pkgsrc-bugs@netbsd.org,gnats-admin@netbsd.org,gutteridge@NetBSD.org,netbsd.open.source@softhome.ca
 >  Cc: Subject: Re: pkg/59530 (Ports: lsof : The Operating System
 >  version (10.1) does not match 10.0)
 >  [snip]
 >  

From: "John L. Males" <netbsd.open.source@softhome.ca>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: pkg/59530
Date: Sun, 24 Aug 2025 02:48:05 +0000

 Hello,

 Sorry, but few more bugs not reported have occurred further
 distracting time need to organized pkgin bug report wiping out my
 NetBSD system as noted prior.

 The suggestion related to this bug:

 > You have two options here. One is to simply follow the
 > instructions in the message, that is, "add CHECK_OSABI=no to
 > pkg_install.conf". That should be safe to do in this context
 > (with this package). The other is to build the package from
 > source instead. (That brings its own not recommended approach of
 > mixing binary and locally-built packages, but is relatively
 > simple for this particular example.)

 Raises these concerns:

 1) Assuming "add" "CHECK_OSABI=no" is added to "pkg_install.conf"
 "should be safe" is safe then raises the possibility that other
 package(s) that would otherwise have issue(s) and may not be safe
 with "add CHECK_OSABI=no" in the "pkg_install.conf".

 2) This is even more complicated if a package installing via pkgin
 does not need "CHECK_OSABI=no" in "pkg_install.conf", but one or
 more required packages needed to install requested package would
 where one or more of those required packages is not safe to install
 with "CHECK_OSABI=no" in "pkg_install.conf".

 3) Clearly the other option to build from package source implies
 many possible issues with package compatibility to binary packages
 installed with pkgin.  This sounds like will will lead to all
 sorts of problems short and long term.  I know this first hand
 having built major package from source that then wants this
 "different" version of package(s) that then leads to many more
 packages that have to be built, and repeat often many times thatat
 times means one basically has to rebuild almost all packages from
 source.

 4) So far it appears there is no way to just build the package as
 binary for pkgin to install such that something like (2) or results
 from (3) does not need to be done to do so, prevent need for
 complications of (3), and not need "alternate" (3) and many issues
 can result in short and long term. 


 John L. Males
 Toronto, Ontario
 Canada

 2025-08-24 02:19+0000 UTC eMail Start
 2025-08-24 02:48+0000 UTC
 2025-08-23 22:48-0400 EDT

 *****Not GPG/PG Signed*****



 On Date: Sat, 19 Jul 2025 05:40:02 +0000 (UTC)
 From: "John L. Males via gnats" <gnats-admin@NetBSD.org>
 To:
 pkg-manager@netbsd.org,gnats-admin@netbsd.org,pkgsrc-bugs@netbsd.org,netbsd.open.source@softhome.ca
 Cc: Subject: Re: pkg/59530



 > The following reply was made to PR pkg/59530; it has been noted
 > by GNATS.
 > 
 > From: "John L. Males" <netbsd.open.source@softhome.ca>
 > To: gnats-bugs@netbsd.org
 > Cc: 
 > Subject: Re: pkg/59530
 > Date: Sat, 19 Jul 2025 05:36:08 +0000
 > 
 >  Hello,
 >  
 >  I have sense my prior attempt to update the bug report was not
 >  successful.
 >  
 >  I am sending eMail in hopes this attempt will update the bug
 > report. 
 >  
 >  John L. Males
 >  Toronto, Ontario
 >  Canada
 >  
 >  2025-07-19 05:32+0000 UTC eMail Start
 >  2025-07-19 05:36+0000 UTC
 >  2025-07-19 01:36-0400 EDT
 >  
 >  *****Not GPG/PG Signed*****
 >  
 >  
 >  
 >  On Date: Sat, 19 Jul 2025 04:30:03 +0000 (UTC)
 >  From: "John L. Males via gnats" <gnats-admin@NetBSD.org>
 >  To:
 >  pkg-manager@netbsd.org,gnats-admin@netbsd.org,pkgsrc-bugs@netbsd.org,netbsd.open.source@softhome.ca
 >  Cc: Subject: Re: pkg/59530 (Ports: lsof : The Operating System
 >  version (10.1) does not match 10.0)
 >  
 >  
 >  
 >  > The following reply was made to PR pkg/59530; it has been noted
 >  > by GNATS.
 >  > 
 >  > From: "John L. Males" <netbsd.open.source@softhome.ca>
 >  > To: gnats-bugs@netbsd.org
 >  > Cc: 
 >  > Subject: Re: pkg/59530 (Ports: lsof : The Operating System
 >  > version (10.1) does not match 10.0)
 >  > Date: Sat, 19 Jul 2025 03:43:11 +0000
 >  > 
 >  >  Hello,
 >  >  
 >  >  Thanks for reply.
 >  >  
 >  >  I need to cover important points related to reply, but will
 >  > not be able to do so for several days.
 >  >  
 >  >  The reason for several days to reply with important points to
 >  > this bug is I need to organized alot of information due to
 >  > pkgin install of some needed archive application few hours ago
 >  > trashed my NetBSD system in very extensive serious ways. I has
 >  > taken me few hours to at least return to sort of OK with my
 >  > NetBSD system.  I still have alot of damage assessment to
 >  > still conduct and if issues still exist how I need to fix any
 >  > outstanding damage issues.  Once I have complete damage
 >  > assessment for what damage I can at least find that will need
 >  > to have additional information taken this extensive
 >  > information needs to be organized before I can even attempt to
 >  > open a new bug report in likewise organized manner and detail. 
 >  >  Once I have the bug report of pkgin trashing my NetBSD system
 >  >  submitted I will return to this bug report to cover important
 >  >  points related to prior reply of this bug report.
 >  >  
 >  >  
 >  >  
 >  >  John L. Males
 >  >  Toronto, Ontario
 >  >  Canada
 >  >  
 >  >  2025-07-19 03:28+0000 UTC eMail Start
 >  >  2025-07-19 03:43+0000 UTC
 >  >  2025-07-18 23:43-0400 EDT
 >  >  
 >  >  *****Not GPG/PG Signed*****
 >  >  
 >  >  
 >  >  
 >  >  On Date: Fri, 18 Jul 2025 12:26:56 +0000 (UTC)
 >  >  From: gutteridge@NetBSD.org
 >  >  To:
 >  >  pkg-manager@netbsd.org,pkgsrc-bugs@netbsd.org,gnats-admin@netbsd.org,gutteridge@NetBSD.org,netbsd.open.source@softhome.ca
 >  >  Cc: Subject: Re: pkg/59530 (Ports: lsof : The Operating System
 >  >  version (10.1) does not match 10.0)
 >  >  [snip]
 >  >  
 >  

From: "David H. Gutteridge" <david@gutteridge.ca>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: pkg/59530 (Ports: lsof : The Operating System version (10.1)
 does not match 10.0)
Date: Mon, 25 Aug 2025 20:04:46 -0400

 On Sun, 24 Aug 2025 at 02:48:05 +0000, John L. Males wrote:
 > Hello,
 >=20
 >  Sorry, but few more bugs not reported have occurred further
 >  distracting time need to organized pkgin bug report wiping out my
 >  NetBSD system as noted prior.
 >=20
 >  The suggestion related to this bug:
 >=20
 >  > You have two options here. One is to simply follow the
 >  > instructions in the message, that is, "add CHECK_OSABI=3Dno to
 >  > pkg_install.conf". That should be safe to do in this context
 >  > (with this package). The other is to build the package from
 >  > source instead. (That brings its own not recommended approach of
 >  > mixing binary and locally-built packages, but is relatively
 >  > simple for this particular example.)
 >=20
 >  Raises these concerns:
 >=20
 >  1) Assuming "add" "CHECK_OSABI=3Dno" is added to "pkg_install.conf"
 >  "should be safe" is safe then raises the possibility that other
 >  package(s) that would otherwise have issue(s) and may not be safe
 >  with "add CHECK_OSABI=3Dno" in the "pkg_install.conf".
 >=20
 >  2) This is even more complicated if a package installing via pkgin
 >  does not need "CHECK_OSABI=3Dno" in "pkg_install.conf", but one or
 >  more required packages needed to install requested package would
 >  where one or more of those required packages is not safe to install
 >  with "CHECK_OSABI=3Dno" in "pkg_install.conf".

 Yes, though there are over 29,000 packages in pkgsrc. There are
 presently only ten actual packages that set OSVERSION_SPECIFIC (plus
 one that is for build-only purposes, x11-links).

 benchmarks/hbench/Makefile:20:OSVERSION_SPECIFIC=3D	YES
 devel/p5-perl-headers/Makefile:20:OSVERSION_SPECIFIC=3D	yes
 devel/debugcon_printf/Makefile:14:OSVERSION_SPECIFIC=3D	YES
 emulators/haxm/Makefile:14:OSVERSION_SPECIFIC=3D	YES
 lang/STk/Makefile:16:OSVERSION_SPECIFIC=3D	yes
 net/net-snmp/Makefile:30:OSVERSION_SPECIFIC=3D	YES
 net/oidentd/Makefile:18:OSVERSION_SPECIFIC=3D	YES
 pkgtools/x11-links/Makefile:29:OSVERSION_SPECIFIC=3D	yes
 sysutils/libgtop/Makefile:14:OSVERSION_SPECIFIC=3D	YES
 sysutils/lsof/Makefile:24:OSVERSION_SPECIFIC=3D	yes
 sysutils/pftop/Makefile:16:OSVERSION_SPECIFIC=3D	yes

 (Of these, libgtop has the biggest potential footprint, since it gets
 pulled in by the gnome and mate meta-packages. Most of these are leaf
 packages that won't be pulled in by anything else.)

 This is one reason why this topic hasn't seen any attention. No one
 has touched the related mk infrastructure in about fifteen years.

 >  3) Clearly the other option to build from package source implies
 >  many possible issues with package compatibility to binary packages
 >  installed with pkgin.  This sounds like will will lead to all
 >  sorts of problems short and long term.  I know this first hand
 >  having built major package from source that then wants this
 >  "different" version of package(s) that then leads to many more
 >  packages that have to be built, and repeat often many times thatat
 >  times means one basically has to rebuild almost all packages from
 >  source.

 lsof has no true binary dependencies on other pkgsrc packages. It only
 links against libraries in the base system. So there is no concern here
 for this package. (That's what I meant before by "relatively simple",
 though I realize that wasn't clear.)

 /usr/pkg/sbin/lsof:
 	-lutil.7 =3D> /usr/lib/libutil.so.7
 	-lc.12 =3D> /usr/lib/libc.so.12
 	-lkvm.6 =3D> /usr/lib/libkvm.so.6

 (There could potentially be concern with #1 above, of course.)

 It does "depend" on perl, but that is only because it comes with
 example scripts that wrap "lsof" calls inside scripting.

 >  4) So far it appears there is no way to just build the package as
 >  binary for pkgin to install such that something like (2) or results
 >  from (3) does not need to be done to do so, prevent need for
 >  complications of (3), and not need "alternate" (3) and many issues
 >  can result in short and long term.=20

 Yes, well, to me there's more than one topic here. One is that you seem
 to want to use lsof immediately. The options mentioned are your choices.
 Realistically, it's not likely the broader OSABI item will get attention
 any time soon, nor will TNF be building different binary packages for
 each "minor" release given they should all be binary compatible in
 actuality. People have discussed the broader topic internally, and
 indeed questioned whether several of the packages that set
 OSVERSION_SPECIFIC should really do so, but so many packages, so little
 time is often the name of the game, unfortunately.

 Regards,

 Dave

State-Changed-From-To: feedback->analyzed
State-Changed-By: gutteridge@NetBSD.org
State-Changed-When: Tue, 26 Aug 2025 00:07:34 +0000
State-Changed-Why:
Feedback received, and further explanation provided back.

From: "John L. Males" <netbsd.open.source@softhome.ca>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: pkg/59530 (Ports: lsof : The Operating System version (10.1)
 does not match 10.0)
Date: Tue, 2 Sep 2025 06:26:01 +0000

 Dave,

 I would suggest this issue be closed or if makes sense placed into
 "bucket".

 "Bucket" suggestion re "presently only ten actual packages that set
 OSVERSION_SPECIFIC (plus one that is for build-only purposes,
 x11-links)" and "People have discussed the broader topic
 internally, and indeed questioned whether several of the packages
 that set OSVERSION_SPECIFIC should really do so".  I understand the
 reference to MK not touched in 15 years, but only 10 packages.  I
 know how simple and easy sounds compared to "29,000 packages in
 pkgsrc" may or may not involve alot of time or then again maybe
 very simple, easy, and little time to remove OSVERSION_SPECIFIC
 completely.  I would think all else equal 10 packages does not make
 difference from build time compared to "29,000 packages in pkgsrc".

 I will not install lsof due to required "add" "CHECK_OSABI=no" to
 "pkg_install.conf".  Not because it is difficult to do so.  I will
 not based on my many years of software engineering dealing with
 issues that originated from mixed versions/code/design bases.

 One case in point that different versions of OS were issues
 such that at times the need for specific set of fixes were not
 possible as the set of fixes where exclusive to one or more forks
 of same OS version.  In end engineering of a major industry name
 had to spend months to merge the different versions of OSs and
 rework many fixes to work with one version of OS.

 I have also seen first hand same forking same version into many
 exclusive of other forks API call definition and/or functionality
 of developer API developed/sold by (different to prior example)
 major software name in industry.  API differences means of couse
 APBI issues.  This API product is used by developers of
 many companies, often large, for product development in house or
 to sell was on hold for well over year as major industry name merged
 back to one version.  Again over year to merge back indicates again
 how far and extensive the different forks of same API had been
 allowed to continue.

 In both cases above the point of have to merge was forced due to
 reaching point cannot manage code nor even effect new fixes as new
 fixes would break all forked versions.  Hence time to maintain and
 unable to fix forced the year plus needed to merge code and in many
 cases redo many prior fixes from scratch.

 Just one of many first hand examples.  I have not mentioned where
 when I build the source of product fails at build or test of build
 phase due to source not on "same page" for all code "checked in".

 I needed to give perspective on why I have decided I have.  I am
 not sure if any have seen in any sense some manner of the examples
 I have provided as my reasoning for my decision.  Again I know
 first hand many times where fix for complex issues was simple and
 easy despite expecting otherwise, and flip side of expected easy
 bug to take little time/effort takes weeks, months, or more.  Not
 always case for simple or complex looking bugs, but one never knows
 at times if will be simple bug is easy/short time and complex bug
 needs notable time and effort.


 John L. Males
 Toronto, Ontario
 Canada

 2025-09-02 05:36+0000 UTC eMail Start
 2025-09-02 06:26+0000 UTC
 2025-09-02 02:26-0400 EDT

 *****Not GPG/PG Signed*****



 On Date: Tue, 26 Aug 2025 00:05:01 +0000 (UTC)
 From: "David H. Gutteridge via gnats" <gnats-admin@NetBSD.org>
 To:
 pkg-manager@netbsd.org,gnats-admin@netbsd.org,pkgsrc-bugs@netbsd.org,netbsd.open.source@softhome.ca
 Cc: Subject: Re: pkg/59530 (Ports: lsof : The Operating System
 version (10.1) does not match 10.0)



 [snip to reduce duplication and improve readability of gnats issue]

>Unformatted:

Home	PR Database Search