Contribution workflow
Hello, It was said to me that the main way to contribute is via bugzilla. So last year, I wrote tickets 270798, 273569, 273568 and got no response since. On github, repo freebsd-ports, I have pull-request 241 which I think will have a similar fate as the bugzilla tickets. I do realize that the github repo is supposed to be publish only, but if you look, some pull requests are being accepted and it is better than being ignored. That brings up the question: Firstly, are requests for new ports supposed to be sent via bugzilla? Secondly, is the wait time on bugzilla normal behaviour or am I missing some part of the contribution process here? Thirdly, how can one become a maintainer to help clear up the waiting line of bugs, pull-requests &c?
Re: Contribution workflow
> On Mar 11, 2024, at 11:18 AM, Adam Labus wrote: > > Hello, > > It was said to me that the main way to contribute is via bugzilla. So last > year, I wrote tickets 270798, 273569, 273568 and got no response since. On > github, repo freebsd-ports, I have pull-request 241 which I think will have a > similar fate as the bugzilla tickets. I do realize that the github repo is > supposed to be publish only, but if you look, some pull requests are being > accepted and it is better than being ignored. > That brings up the question: > Firstly, are requests for new ports supposed to be sent via bugzilla? > Secondly, is the wait time on bugzilla normal behaviour or am I missing some > part of the contribution process here? Thirdly, how can one become a > maintainer to help clear up the waiting line of bugs, pull-requests &c? Hi, The main point of contribution is still Bugzilla. The problem is committers often do not go through all PRs so can miss those tickets. There are two ways to have it priotized: 1. If you are submitting a new port with your email as the MAINTAINER add the flag maintainer-approval to + so it automatically goes through the filter and is shown in the maintainer approved PRs which are often easier to handle by a committer without any problems. When I am idle I also look through that list before moving into other lists. 2. After creating the PR send a mail in this list which attracts more attention. Or jump into the IRC channel to ask someone to look into it. Github PRs are mostly ignored as those cannot be merged there. When you setup the MAINTAINER email to yourself you automatically become the maintainer but that doesn't give you the skip from the queue or waiting time. You can become a committer to avoid those queues and commit yourself but that is a long process. As that requires certain level of contribution and maintenance of ports. Then a committer might approach you whether if you are interested to become a committer. But for that you must nudge a committer so badly that they will get bored of you and punish you with a commit bit. :D Hope that helps you answer the question. Kind regards, Moin signature.asc Description: Message signed with OpenPGP
Committer request for audio/logitechmediaserver
Hello, Could someone please commit bug 277299? https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277299 It is an update to Logitech Media Server and it would be good to have this updated since the "mysqueezebox.com" service for these devices is going down in March. This is the latest version that has support for newer plugins that will work once the service is gone. I'm the maintainer and have approved the change. I've been running locally with this for the past two weeks with no problems. And others have approached me asking for an update. So, it would be nice to have this committed. Thank you in advance, -- Trenton
Re: Contribution workflow
On Mon, Mar 11, 2024 at 1:27 PM Moin Rahman wrote: > > Github PRs are mostly ignored as those cannot be merged there. Not really, there is a lot of stuff coming from GitHub. Yes, you can't merge them via web UI, but it is still simple with gh CLI. I do merge contributions from GitHub from time to time.
Re: Contribution workflow
> On Mar 11, 2024, at 1:37 PM, Gleb Popov wrote: > > On Mon, Mar 11, 2024 at 1:27 PM Moin Rahman wrote: >> >> Github PRs are mostly ignored as those cannot be merged there. > > Not really, there is a lot of stuff coming from GitHub. Yes, you can't > merge them via web UI, but it is still simple with gh CLI. I do merge > contributions from GitHub from time to time. There are still some part of the pie apart from `mostly` and you fall in that part. :D signature.asc Description: Message signed with OpenPGP
Re: Contribution workflow
Hi, On Mon, 11 Mar 2024, at 11:27, Moin Rahman wrote: > 2. After creating the PR send a mail in this list which attracts more > attention. Or jump into the IRC channel to ask someone to look into it. According to this rule, the process actually is duplicate here every PR. Because this rules hasn't any conditions specified.
Re: Contribution workflow
> On Mar 11, 2024, at 2:28 PM, Denis Shaposhnikov wrote: > > Hi, > > On Mon, 11 Mar 2024, at 11:27, Moin Rahman wrote: >> 2. After creating the PR send a mail in this list which attracts more >> attention. Or jump into the IRC channel to ask someone to look into it. > > According to this rule, the process actually is duplicate here every PR. > Because this rules hasn't any conditions specified. > What I have mentioned are neither rules nor best practices. Those are just to put your PRs up in the queue of priorities for a committer's workflow. :) signature.asc Description: Message signed with OpenPGP
Re: Committer request for audio/logitechmediaserver
On 11/03/24 12:48, Trenton Schulz wrote: Hello, Could someone please commit bug 277299? https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277299 It is an update to Logitech Media Server and it would be good to have this updated since the "mysqueezebox.com" service for these devices is going down in March. This is the latest version that has support for newer plugins that will work once the service is gone. I'm the maintainer and have approved the change. I've been running locally with this for the past two weeks with no problems. And others have approached me asking for an update. So, it would be nice to have this committed. Thank you in advance, -- Trenton took, regards.
Re: FreeBSD ports community is broken [port building configuration notes]
[The armv7 poudriere bulk finished.] On Mar 10, 2024, at 13:10, Mark Millard wrote: > [poudriere bulk status update.] > > On Mar 5, 2024, at 18:43, Mark Millard wrote: > >> [I noticed that my SWAP figures were not self consistent for the armv7.] >> >> On Feb 18, 2024, at 09:50, Mark Millard wrote: >> >>> [I also forgot to mention an important FreeBSD configuration setting >>> as well. It is not specific to poudriere use.] >>> On Feb 18, 2024, at 09:13, Mark Millard wrote: [I forgot to mention the armv7 core count involved: 4] On Feb 18, 2024, at 08:52, Mark Millard wrote: > Aryeh Friedman wrote on > Date: Sun, 18 Feb 2024 10:37:06 UTC : > >> It should not require >> prodiere running on a supermassive machine to work (in many cases >> portmaster and make install recursion fail where prodiere works). > > As for configuring for small, slow systems relative to > resource use, I provide some settings that I've > historically used below. Then I have some other notes > after that material. > > For a 2 GiByte RAM armv7 system with 3 GiByte swap space > and a UFS file system, no use of tmpfs in normal operation > (since it competes for RAM+SWAP generally): >> >> Actually: 2 GiByte RAM armv7 has 3.6 GiByte SWAP space, with >> some margin. Ever so slightly over 3.8 GiBytes got the mistuning >> warning but there is variability across builds so I try to avoid >> repeated adjustments by picking somewhat smaller. >> FYI: The armv7 has 4 cores. > /usr/local/etc/poudriere.conf has . . . > > NO_ZFS=yes > USE_TMPFS=no > PARALLEL_JOBS=2 > ALLOW_MAKE_JOBS=yes > MAX_EXECUTION_TIME=432000 > NOHANG_TIME=432000 > MAX_EXECUTION_TIME_EXTRACT=14400 > MAX_EXECUTION_TIME_INSTALL=14400 > MAX_EXECUTION_TIME_PACKAGE=57600 > MAX_EXECUTION_TIME_DEINSTALL=14400 > > /usr/local/etc/poudriere.d/make.conf has . . . > > MAKE_JOBS_NUMBER=2 I'll note that I'd switched to using MAKE_JOB_NUMBER_LIMIT and do not use MAKE_JOB_NUMBER any more. So: MAKE_JOB_NUMBER_LIMIT=2 > /etc/fstab does not specify any tmpfs use or the > like: avoids competing for RAM+SWAP. > > The 3 GiBytes of swap space is deliberate: RAM+SWAP > is important for all means of building in such a > context: there are a bunch of ports that have > large memory use for building in all cases. > > [armv7 allows around RAM+SWAP=2.5*RAM before >> >> That equation should have been RAM+SWAP==2.8*RAM >> (with margin considered), so SWAP==1.8*RAM. (With >> a small enough RAM 2.7*RAM might need to be used, >> for example.) >> >> So the 2 GiByte RAM leads to a 5.6 GiByte RAM+SWAP >> for the builders and other uses to share. >> >> I may set up a modern experiment to see if the >> combination: >> >> PARALLEL_JOBS=2 >> ALLOW_MAKE_JOBS=yes (with MAKE_JOBS_NUMBER=2) Again, now: MAKE_JOB_NUMBER_LIMIT=2 >> still completes for a build that would end up with >> llvm18 and rust likely building in parallel for >> much of the time (if it completed okay, anyway). >> Something like 265 ports would be queued, the last >> few of which include some use of llvm18 and of >> rust. >> >> . . . >> > tradeoff/mistuning notices are generated. aarch64 > and amd64 allow more like RAM+SWAP=3.4*RAM before I've not validated the 3.4 figure. It is likely a bit low. > such notices are reported. The detailed multiplier > changes some from build to build, so I leave > margin in my figures to avoid the notices.] > > I also historically use USB SSD/NVMe media, no > spinning rust, no microsd cards or such. >>> >>> /boot/loader.conf has . . . >>> >>> # >>> # Delay when persistent low free RAM leads to >>> # Out Of Memory killing of processes: >>> vm.pageout_oom_seq=120 >>> >>> This is important to allowing various things >>> to complete. (The default is 12. 120 is not >>> the maximum but has been appropriate in my >>> context. The figure is not in time units but >>> larger increases the observed delay so more >>> work gets done before OOM activity starts.) >>> >>> Using vm.pageout_oom_seq is not specific to >>> poudriere use. >>> > As far as more ports building in poudriere than in > "portmaster and make install recursion" in other > respects than resources: it is easier to make ports > build in poudriere. It provides the simpler/cleaner > context for the individual builders. More things > lead to failure outside poudriere that are just not > issues when poudriere is used so more care is needed > setting up the ports for the likes of portmaster use. > (And, yes, I used to use portmaster.) The required > range of testing contexts is wider for use of the > likes of portmaster to know that the port build will > just work in the full range of contexts. > > Such issues adds to the port maintainer/committer
Building for aarch64
I had absolutely no success with running poudriere under qemu emulation. There are always a bunch of packages that failed to build for various changing reasons. Running poudriere on an Apple Silicon Mac works really well, though. Not one failed package so far and much faster than under emulation, of course. So I thought this might be useful information for the list ports and arm: https://oliver-epper.de/posts/poudriere-on-m1-mac/ greetings Oliver Epper
Re: Proposed ports deprecation and removal policy
11.03.2024 4:49, Daniel Engberg wrote: >>> Ports can be removed immediately if one of the following conditions is met: >>> >>> - Upstream distfile is no longer available from the original source/mirror >>> (Our and other distcaches e.g. Debian, Gentoo, etc do not count as >>> "available") >>> - Upstream WWW is unavailable: deprecate, remove after 3 months >> [skip] >>>A port can be deprecated and subsequently removed if: >>> - Upstream declared the version EOL or officially stopped development. >>> DEPRECATED should be set as soon as the planned removal date is know. >> >> Objection to quoted reasons. A software not developed anymore but still >> works fine >> after years is best software ever. Do not touch it, please. >> >> Some examples: >> >> mail/qpopper abadoned by Qualcomm years ago >> russian/d1489created by ache@ who passed away years >> ago >> net/quagga abadonware but still best OSPF implementation >> for FreeBSD kernel >> net-im/pidgin-manualsize abadoned by initial author years ago >> databases/oracle8-client the only known library to link native FreeBSD >> code with for OracleDB connection >> >> Do not "fix" what ain't broken. >> > Eugene > > I'm going to assume that there will be a PR or something regarding maintained > ports either way. I maintain most of listed ports. > As far as the "Do not "fix" what ain't broken" argument goes one major > concern is how do you know > especially regarding to Internet facing services? Not every port deals with public Internet and services therein. > Qpopper (for example) has been dropped by pretty much every distro > https://repology.org/project/qpopper/versions and upstream is dead so there's > no hub for communication. And not need to, practice shows. > There likely aren't many eyes on the software by now (I guess for both good > and bad reasons) > but it might also very well bite you or users in the end. Until then, it works and let it be. > That being said, all software contains bugs True. The question is, do any of bugs affect particular setup? If not, let it be. > including active projects so it's not like it's a clean cut in terms of > security concerns (wordpress) > but you'll likely see issues being adressed and reported when software is > more widely available. > If upstream is dead it's very likely that security reports ends up in some > package repo, > random hosted fork or such and never finds it way outside of it. There are private networks not exposed to untrusted users or hosts not affected by any security concerns, including one-user-only. No need to break their setups. > Quagga is in a similar position, pfsense seems to point users to frr and > there's also other software such as bird/bird2. frr development is Linux-centric and its OSPF implementation has some problems under FreeBSD ignored by developers, it cannot be a replacement (can't tell for bird/bird2). Quagga ospfd/bgpd work fine, let it be. > According to https://www.orafaq.com/wiki/Oracle_8 Oracle 8 support ended 20 > years ago, > it's also marked as i386 only so its days are counted. This is userland library and we have no plans to eliminate userland i386 support yet. No alternatives, also. > Nothing is stopping people to use an overlay but not everything needs to be > in or rather stay the "public" repo forever. Not forever. While it works fine. Eugene
portsfallout.com stopped updating on 2024-02-23
Is it known who is the contact person for portsfallout.com ? Thanks, Yuri
Re: FreeBSD ports community is broken [port building configuration notes]
[I should have noted howthe processor frequency is heandled.] > On Mar 11, 2024, at 08:50, Mark Millard wrote: > > [The armv7 poudriere bulk finished.] > > On Mar 10, 2024, at 13:10, Mark Millard wrote: > >> [poudriere bulk status update.] >> >> On Mar 5, 2024, at 18:43, Mark Millard wrote: >> >>> [I noticed that my SWAP figures were not self consistent for the armv7.] >>> >>> On Feb 18, 2024, at 09:50, Mark Millard wrote: >>> [I also forgot to mention an important FreeBSD configuration setting as well. It is not specific to poudriere use.] > On Feb 18, 2024, at 09:13, Mark Millard wrote: > > [I forgot to mention the armv7 core count involved: 4] > > On Feb 18, 2024, at 08:52, Mark Millard wrote: > >> Aryeh Friedman wrote on >> Date: Sun, 18 Feb 2024 10:37:06 UTC : >> >>> It should not require >>> prodiere running on a supermassive machine to work (in many cases >>> portmaster and make install recursion fail where prodiere works). >> >> As for configuring for small, slow systems relative to >> resource use, I provide some settings that I've >> historically used below. Then I have some other notes >> after that material. >> >> For a 2 GiByte RAM armv7 system with 3 GiByte swap space >> and a UFS file system, no use of tmpfs in normal operation >> (since it competes for RAM+SWAP generally): >>> >>> Actually: 2 GiByte RAM armv7 has 3.6 GiByte SWAP space, with >>> some margin. Ever so slightly over 3.8 GiBytes got the mistuning >>> warning but there is variability across builds so I try to avoid >>> repeated adjustments by picking somewhat smaller. >>> > FYI: The armv7 has 4 cores. > >> /usr/local/etc/poudriere.conf has . . . >> >> NO_ZFS=yes >> USE_TMPFS=no >> PARALLEL_JOBS=2 >> ALLOW_MAKE_JOBS=yes >> MAX_EXECUTION_TIME=432000 >> NOHANG_TIME=432000 >> MAX_EXECUTION_TIME_EXTRACT=14400 >> MAX_EXECUTION_TIME_INSTALL=14400 >> MAX_EXECUTION_TIME_PACKAGE=57600 >> MAX_EXECUTION_TIME_DEINSTALL=14400 >> >> /usr/local/etc/poudriere.d/make.conf has . . . >> >> MAKE_JOBS_NUMBER=2 > > I'll note that I'd switched to using MAKE_JOB_NUMBER_LIMIT > and do not use MAKE_JOB_NUMBER any more. So: > > MAKE_JOB_NUMBER_LIMIT=2 > >> /etc/fstab does not specify any tmpfs use or the >> like: avoids competing for RAM+SWAP. >> >> The 3 GiBytes of swap space is deliberate: RAM+SWAP >> is important for all means of building in such a >> context: there are a bunch of ports that have >> large memory use for building in all cases. >> >> [armv7 allows around RAM+SWAP=2.5*RAM before >>> >>> That equation should have been RAM+SWAP==2.8*RAM >>> (with margin considered), so SWAP==1.8*RAM. (With >>> a small enough RAM 2.7*RAM might need to be used, >>> for example.) >>> >>> So the 2 GiByte RAM leads to a 5.6 GiByte RAM+SWAP >>> for the builders and other uses to share. >>> >>> I may set up a modern experiment to see if the >>> combination: >>> >>> PARALLEL_JOBS=2 >>> ALLOW_MAKE_JOBS=yes (with MAKE_JOBS_NUMBER=2) > > Again, now: MAKE_JOB_NUMBER_LIMIT=2 > >>> still completes for a build that would end up with >>> llvm18 and rust likely building in parallel for >>> much of the time (if it completed okay, anyway). >>> Something like 265 ports would be queued, the last >>> few of which include some use of llvm18 and of >>> rust. >>> >>> . . . >>> >> tradeoff/mistuning notices are generated. aarch64 >> and amd64 allow more like RAM+SWAP=3.4*RAM before > > I've not validated the 3.4 figure. It is likely a bit low. > >> such notices are reported. The detailed multiplier >> changes some from build to build, so I leave >> margin in my figures to avoid the notices.] >> >> I also historically use USB SSD/NVMe media, no >> spinning rust, no microsd cards or such. /boot/loader.conf has . . . # # Delay when persistent low free RAM leads to # Out Of Memory killing of processes: vm.pageout_oom_seq=120 This is important to allowing various things to complete. (The default is 12. 120 is not the maximum but has been appropriate in my context. The figure is not in time units but larger increases the observed delay so more work gets done before OOM activity starts.) Using vm.pageout_oom_seq is not specific to poudriere use. >> As far as more ports building in poudriere than in >> "portmaster and make install recursion" in other >> respects than resources: it is easier to make ports >> build in poudriere. It provides the simpler/cleaner >> context for the individual builders. More things >> lead to failure outside poudriere that are just not >> issues when poudriere is used so more care is needed >> setting up the ports for the likes of portmaster use. >> (And, yes
Re: Proposed ports deprecation and removal policy
On 2/28/24 11:22, Florian Smeets wrote: Ports can be removed immediately if one of the following conditions is met: - Upstream distfile is no longer available from the original source/mirror (Our and other distcaches e.g. Debian, Gentoo, etc do not count as "available") Such removal can't be immediate and unconditional. Software can be perfectly useful and used by many users, but (1) Some government compelled the upstream developer to remove it for political reasons, for example to suppress users' privacy. This actually happened with one port this year when Chinese government forced its removal. We need to help such software to remain available when many users exist. (2) The upstream forgot to renew the domain, so it became temporarily unavailable. The situation of apparently disappeared tarballs should be considered on a case-by-case basis, not in a blanket fashion. Thanks, Yuri
Re: Proposed ports deprecation and removal policy
On 2024-03-11T18:22:57.000+01:00, Eugene Grosbein wrote: > 11.03.2024 4:49, Daniel Engberg wrote: > > > > > > > > > > > Ports can be removed immediately if one of the following conditions > > > > is met: > > > > > > > > - Upstream distfile is no longer available from the original > > > > source/mirror > > > > (Our and other distcaches e.g. Debian, Gentoo, etc do not count as > > > > "available") > > > > - Upstream WWW is unavailable: deprecate, remove after 3 months > > > [skip] > > > > > > > A port can be deprecated and subsequently removed if: > > > > - Upstream declared the version EOL or officially stopped development. > > > > DEPRECATED should be set as soon as the planned removal date is know. > > > > > > Objection to quoted reasons. A software not developed anymore but still > > > works fine > > > after years is best software ever. Do not touch it, please. > > > > > > Some examples: > > > > > > mail/qpopper abadoned by Qualcomm years ago > > > russian/d1489 created by ache@ who passed away years ago > > > net/quagga abadonware but still best OSPF implementation for FreeBSD > > > kernel > > > net-im/pidgin-manualsize abadoned by initial author years ago > > > databases/oracle8-client the only known library to link native FreeBSD > > > code with for OracleDB connection > > > > > > Do not "fix" what ain't broken. > > > > > Eugene > > > > I'm going to assume that there will be a PR or something regarding > > maintained ports either way. > > I maintain most of listed ports. > > > >As far as the "Do not "fix" what ain't broken" argument goes one major > > concern is how do you know > > especially regarding to Internet facing services? > > Not every port deals with public Internet and services therein. > > > >Qpopper (for example) has been dropped by pretty much every distro > > https://repology.org/project/qpopper/versions and upstream is dead so > > there's no hub for communication. > > And not need to, practice shows. > > > >There likely aren't many eyes on the software by now (I guess for both > > good and bad reasons) > > but it might also very well bite you or users in the end. > > Until then, it works and let it be. > > > >That being said, all software contains bugs > > True. The question is, do any of bugs affect particular setup? If not, let it > be. > > > >including active projects so it's not like it's a clean cut in terms of > > security concerns (wordpress) > > but you'll likely see issues being adressed and reported when software is > > more widely available. > > If upstream is dead it's very likely that security reports ends up in some > > package repo, > > random hosted fork or such and never finds it way outside of it. > > There are private networks not exposed to untrusted users or hosts not > affected by any security concerns, > including one-user-only. No need to break their setups. > > > >Quagga is in a similar position, pfsense seems to point users to frr and > > there's also other software such as bird/bird2. > > frr development is Linux-centric and its OSPF implementation has some > problems under FreeBSD ignored by developers, > it cannot be a replacement (can't tell for bird/bird2). Quagga ospfd/bgpd > work fine, let it be. > > > >According to https://www.orafaq.com/wiki/Oracle_8 Oracle 8 support ended > > 20 years ago, > > it's also marked as i386 only so its days are counted. > > This is userland library and we have no plans to eliminate userland i386 > support yet. > No alternatives, also. > > > >Nothing is stopping people to use an overlay but not everything needs to > > be in or rather stay the "public" repo forever. > > Not forever. While it works fine. > Eugene Since your average user is connected to the Internet to utilize ports and/or packages I think a sound assumption would be that Internet is going to be an attack vector. While we can't safeguard for every possible scenario we do have the ability however to "protect" users to some extent. VuXML (CVE reporting, upstream etc) and ports security team exists for this very reason, if upstream reporting facilities aren't available then there's a higher risk of security reports and patches slipping by. This is one of the reasons why many repositories remove abandonware, outdated versions etc. Not saying it's valid argument but given our efforts try to keep users safe in general that approach seems reasonable? Taking it to the extreme I'm not sure putting a banner saying something like "X probably works fine on a private network with trusted hosts" is going to send a positive and reassuring message or tell people when shit hits the fan "It's abandonware, you're on your own and you should've known better" . Another possible option would be to add something to the port's matedata that makes pkg aware and easy notiable like using a specific color for portname
Re: portsfallout.com stopped updating on 2024-02-23
On Mon, Mar 11, 2024, at 16:41, Yuri wrote:
> Is it known who is the contact person for portsfallout.com ?
>
>
> Thanks,
>
> Yuri
I’ll take a look. It appears to be an issue with Scrapy and a new version of
the Twisted dependency.
Traceback (most recent call last):
File "/usr/local/bin/scrapy", line 33, in
sys.exit(load_entry_point('Scrapy==2.5.1', 'console_scripts', 'scrapy')())
File "/usr/local/lib/python3.9/site-packages/scrapy/cmdline.py", line 144, in
execute
cmd.crawler_process = CrawlerProcess(settings)
File "/usr/local/lib/python3.9/site-packages/scrapy/crawler.py", line 281, in
__init__
install_shutdown_handlers(self._signal_shutdown)
File "/usr/local/lib/python3.9/site-packages/scrapy/utils/ossignal.py", line
19, in install_shutdown_handlers
reactor._handleSignals()
AttributeError: 'PollReactor' object has no attribute '_handleSignals'
Regards,
--
Danilo G. Baio
Re: portsfallout.com stopped updating on 2024-02-23
On Mon, Mar 11, 2024, at 17:55, Danilo G. Baio wrote: > On Mon, Mar 11, 2024, at 16:41, Yuri wrote: >> Is it known who is the contact person for portsfallout.com ? >> >> >> Thanks, >> >> Yuri > > > I’ll take a look. It appears to be an issue with Scrapy and a new > version of the Twisted dependency. Done. https://portsfallout.com/ has been updated. I plan to submit an update for www/py-scrapy by tomorrow, pending the completion of the build tests. -- Danilo G. Baio
Unmaintained FreeBSD ports which are out of date
Dear port maintainers, The portscout new distfile checker has detected that one or more unmaintained ports appears to be out of date. Please take the opportunity to check each of the ports listed below, and if possible and appropriate, submit/commit an update. Please consider also adopting this port. If any ports have already been updated, you can safely ignore the entry. An e-mail will not be sent again for any of the port/version combinations below. Full details can be found at the following URL: http://portscout.freebsd.org/po...@freebsd.org.html Port| Current version | New version +-+ cad/ifcopenshell| 0.6.0 | blenderbim-240311 +-+ devel/tinygo| 0.19.0 | v0.31.2 +-+ multimedia/gmmlib | 22.3.9 | intel-gmmlib-22.3.18 +-+ net/pjsip | 2.13.1 | 2.14.1 +-+ sysutils/google-compute-engine-oslogin | 20191018.00 | 20240311.00 +-+ If any of the above results are invalid, please check the following page for details on how to improve portscout's detection and selection of distfiles on a per-port basis: http://portscout.freebsd.org/info/portscout-portconfig.txt Reported by:portscout!
