Re: sysutils/screen-ncurses port

2020-05-04 Thread Baptiste Daroussin 
On Sun, May 03, 2020 at 01:10:58PM -0700, Cy Schubert wrote:
> In message <20200430130449.cwsf3x42o6w67...@ivaldir.net>, Baptiste 
> Daroussin wr
> ites:
> > 
> >
> > --mvhxgm4zl62unzlf
> > Content-Type: text/plain; charset=us-ascii
> > Content-Disposition: inline
> > Content-Transfer-Encoding: quoted-printable
> >
> > On Thu, Apr 30, 2020 at 05:56:54AM -0700, Cy Schubert wrote:
> > > In message <20200430075337.3wdzglshhorcd...@ivaldir.net>, Baptiste=20
> > > Daroussin wr
> > > ites:
> > > >=20
> > > >
> > > > --vwrr5drfobpkyvop
> > > > Content-Type: text/plain; charset=3Dus-ascii
> > > > Content-Disposition: inline
> > > > Content-Transfer-Encoding: quoted-printable
> > > >
> > > > On Wed, Apr 29, 2020 at 11:41:46AM -0700, Cy Schubert wrote:
> > > > > Would people be open to the idea of a sysutils/screen-ncurses port th=
> > at=3D
> > > > =3D20
> > > > > depends on devel/ncurses instead of ncureses in base? The reason for =
> > this=3D
> > > > =3D20
> > > > > is there are screen.* terminfo entries in devel/ncurses that don't ex=
> > ist =3D
> > > > in=3D20
> > > > > termcap(5). People who want that extra functionality would be advised=
> >  to=3D
> > > > =3D20
> > > > > install the alternative pkg or build the sysutils/screen port with th=
> > e=3D20
> > > > > appropriate option.
> > > > >=3D20
> > > > > Or, simply change the default from whatever ncurses is available to a=
> > lway=3D
> > > > s=3D20
> > > > > install devel/ncurses. People could always select one of the other op=
> > tion=3D
> > > > s.=3D20
> > > > > Personally, I'm not enamoured with this approach.
> > > >
> > > > I think it is a terrible idea, and we should fix the initial problem in=
> > stea=3D
> > > > d of
> > > > workarounding it.
> > > >
> > > > 1/ why those are not in our termcap(5) ? they should be added if they a=
> > re
> > > > missing. and MFC asap (prior 11.4 and 12.2 would be nice)
> > >=20
> > > I came to this conclusion last night after sending this email thread oud=
> > =20
> > > and will test it some time today.
> > >=20
> > > >
> > > > 2/ we should allow our base ncurses to get informations from newer term=
> > cap(=3D
> > > > 5) if
> > > > needed.
> > > > So far the default TERMCAP is
> > > > ${HOME}/.termcap{,.db}:/etc/termcap{,.db}:/usr/share/misc/termcap{,.db}
> > > >
> > > > First the user can be advise to point configure the $home/.termcap this=
> >  is =3D
> > > > for
> > > > quick now.
> >
> > that is in your scope via a pkg-message :D
> >
> > > >
> > > > Second for later futur proof mechanism we could modify our termcap read=
> > er (=3D
> > > > we
> > > > use our own, not the one in provided by ncurses). to be able to fetch t=
> > ermc=3D
> > > > ap
> > > > capabilities from /usr/local/share/misc/termcap/*.conf for example
> > > >
> > > > This way ports with random termcap info to add would be able to do it w=
> > itho=3D
> > > > ut
> > > > the requirement to wait for a commit in base and a MFC.
> > >=20
> > > This is probably outside of my scope at the moment but, yes, agreed.
> > >=20
> > I will then.
> > I added that to my TODO
> 
> There's already a utility in devel/ncurses called infotocap (and its 
> corresponding captoinfo) that already does this. Both are links to tic. Our 
> ncurses import includes tic. Looks like all that's needed is add it to 
> buildworld.
> 
> I can look at it later tonight. Seems like a quick win.
> 
That is not the point, tic won't work here except if create your own version or
use infotocap. Tic is for terminfo databases while we are still using the 
termcap for historical reason

Having both ncurses from ports and ncurses from base installed at the same time
can open a special can of worm so imho that is not really something we want to
look forward.

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: sysutils/screen-ncurses port

2020-05-04 Thread Cy Schubert 
In message <20200504072624.wlyd73pehq25t...@ivaldir.net>, Baptiste 
Daroussin wr
ites:
> 
>
> --ma2vde2ykv3k7k6b
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
>
> On Sun, May 03, 2020 at 01:10:58PM -0700, Cy Schubert wrote:
> > In message <20200430130449.cwsf3x42o6w67...@ivaldir.net>, Baptiste=20
> > Daroussin wr
> > ites:
> > >=20
> > >
> > > --mvhxgm4zl62unzlf
> > > Content-Type: text/plain; charset=3Dus-ascii
> > > Content-Disposition: inline
> > > Content-Transfer-Encoding: quoted-printable
> > >
> > > On Thu, Apr 30, 2020 at 05:56:54AM -0700, Cy Schubert wrote:
> > > > In message <20200430075337.3wdzglshhorcd...@ivaldir.net>, Baptiste=3D=
> 20
> > > > Daroussin wr
> > > > ites:
> > > > >=3D20
> > > > >
> > > > > --vwrr5drfobpkyvop
> > > > > Content-Type: text/plain; charset=3D3Dus-ascii
> > > > > Content-Disposition: inline
> > > > > Content-Transfer-Encoding: quoted-printable
> > > > >
> > > > > On Wed, Apr 29, 2020 at 11:41:46AM -0700, Cy Schubert wrote:
> > > > > > Would people be open to the idea of a sysutils/screen-ncurses por=
> t th=3D
> > > at=3D3D
> > > > > =3D3D20
> > > > > > depends on devel/ncurses instead of ncureses in base? The reason =
> for =3D
> > > this=3D3D
> > > > > =3D3D20
> > > > > > is there are screen.* terminfo entries in devel/ncurses that don'=
> t ex=3D
> > > ist =3D3D
> > > > > in=3D3D20
> > > > > > termcap(5). People who want that extra functionality would be adv=
> ised=3D
> > >  to=3D3D
> > > > > =3D3D20
> > > > > > install the alternative pkg or build the sysutils/screen port wit=
> h th=3D
> > > e=3D3D20
> > > > > > appropriate option.
> > > > > >=3D3D20
> > > > > > Or, simply change the default from whatever ncurses is available =
> to a=3D
> > > lway=3D3D
> > > > > s=3D3D20
> > > > > > install devel/ncurses. People could always select one of the othe=
> r op=3D
> > > tion=3D3D
> > > > > s.=3D3D20
> > > > > > Personally, I'm not enamoured with this approach.
> > > > >
> > > > > I think it is a terrible idea, and we should fix the initial proble=
> m in=3D
> > > stea=3D3D
> > > > > d of
> > > > > workarounding it.
> > > > >
> > > > > 1/ why those are not in our termcap(5) ? they should be added if th=
> ey a=3D
> > > re
> > > > > missing. and MFC asap (prior 11.4 and 12.2 would be nice)
> > > >=3D20
> > > > I came to this conclusion last night after sending this email thread =
> oud=3D
> > > =3D20
> > > > and will test it some time today.
> > > >=3D20
> > > > >
> > > > > 2/ we should allow our base ncurses to get informations from newer =
> term=3D
> > > cap(=3D3D
> > > > > 5) if
> > > > > needed.
> > > > > So far the default TERMCAP is
> > > > > ${HOME}/.termcap{,.db}:/etc/termcap{,.db}:/usr/share/misc/termcap{,=
> =2Edb}
> > > > >
> > > > > First the user can be advise to point configure the $home/.termcap =
> this=3D
> > >  is =3D3D
> > > > > for
> > > > > quick now.
> > >
> > > that is in your scope via a pkg-message :D
> > >
> > > > >
> > > > > Second for later futur proof mechanism we could modify our termcap =
> read=3D
> > > er (=3D3D
> > > > > we
> > > > > use our own, not the one in provided by ncurses). to be able to fet=
> ch t=3D
> > > ermc=3D3D
> > > > > ap
> > > > > capabilities from /usr/local/share/misc/termcap/*.conf for example
> > > > >
> > > > > This way ports with random termcap info to add would be able to do =
> it w=3D
> > > itho=3D3D
> > > > > ut
> > > > > the requirement to wait for a commit in base and a MFC.
> > > >=3D20
> > > > This is probably outside of my scope at the moment but, yes, agreed.
> > > >=3D20
> > > I will then.
> > > I added that to my TODO
> >=20
> > There's already a utility in devel/ncurses called infotocap (and its=20
> > corresponding captoinfo) that already does this. Both are links to tic. O=
> ur=20
> > ncurses import includes tic. Looks like all that's needed is add it to=20
> > buildworld.
> >=20
> > I can look at it later tonight. Seems like a quick win.
> >=20
> That is not the point, tic won't work here except if create your own versio=
> n or
> use infotocap. Tic is for terminfo databases while we are still using the=
> =20
> termcap for historical reason

I'm not suggesting replacing all of termcap. Just adding some converted 
screen.* entries.

>
> Having both ncurses from ports and ncurses from base installed at the same =
> time
> can open a special can of worm so imho that is not really something we want=
>  to
> look forward.

Some ports require ncurses from ports. Same can of worms as installing a 
kerberos or openssl port.


-- 
Cheers,
Cy Schubert 
FreeBSD UNIX: Web:  https://FreeBSD.org
NTP:   Web:  https://nwtime.org

The need of the many outweighs the greed of the few.


___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: sysutils/screen-ncurses port

2020-05-04 Thread Baptiste Daroussin 
On Mon, May 04, 2020 at 06:35:03AM -0700, Cy Schubert wrote:
> In message <20200504072624.wlyd73pehq25t...@ivaldir.net>, Baptiste 
> Daroussin wr
> ites:
> > 
> >
> > --ma2vde2ykv3k7k6b
> > Content-Type: text/plain; charset=us-ascii
> > Content-Disposition: inline
> > Content-Transfer-Encoding: quoted-printable
> >
> > On Sun, May 03, 2020 at 01:10:58PM -0700, Cy Schubert wrote:
> > > In message <20200430130449.cwsf3x42o6w67...@ivaldir.net>, Baptiste=20
> > > Daroussin wr
> > > ites:
> > > >=20
> > > >
> > > > --mvhxgm4zl62unzlf
> > > > Content-Type: text/plain; charset=3Dus-ascii
> > > > Content-Disposition: inline
> > > > Content-Transfer-Encoding: quoted-printable
> > > >
> > > > On Thu, Apr 30, 2020 at 05:56:54AM -0700, Cy Schubert wrote:
> > > > > In message <20200430075337.3wdzglshhorcd...@ivaldir.net>, Baptiste=3D=
> > 20
> > > > > Daroussin wr
> > > > > ites:
> > > > > >=3D20
> > > > > >
> > > > > > --vwrr5drfobpkyvop
> > > > > > Content-Type: text/plain; charset=3D3Dus-ascii
> > > > > > Content-Disposition: inline
> > > > > > Content-Transfer-Encoding: quoted-printable
> > > > > >
> > > > > > On Wed, Apr 29, 2020 at 11:41:46AM -0700, Cy Schubert wrote:
> > > > > > > Would people be open to the idea of a sysutils/screen-ncurses por=
> > t th=3D
> > > > at=3D3D
> > > > > > =3D3D20
> > > > > > > depends on devel/ncurses instead of ncureses in base? The reason =
> > for =3D
> > > > this=3D3D
> > > > > > =3D3D20
> > > > > > > is there are screen.* terminfo entries in devel/ncurses that don'=
> > t ex=3D
> > > > ist =3D3D
> > > > > > in=3D3D20
> > > > > > > termcap(5). People who want that extra functionality would be adv=
> > ised=3D
> > > >  to=3D3D
> > > > > > =3D3D20
> > > > > > > install the alternative pkg or build the sysutils/screen port wit=
> > h th=3D
> > > > e=3D3D20
> > > > > > > appropriate option.
> > > > > > >=3D3D20
> > > > > > > Or, simply change the default from whatever ncurses is available =
> > to a=3D
> > > > lway=3D3D
> > > > > > s=3D3D20
> > > > > > > install devel/ncurses. People could always select one of the othe=
> > r op=3D
> > > > tion=3D3D
> > > > > > s.=3D3D20
> > > > > > > Personally, I'm not enamoured with this approach.
> > > > > >
> > > > > > I think it is a terrible idea, and we should fix the initial proble=
> > m in=3D
> > > > stea=3D3D
> > > > > > d of
> > > > > > workarounding it.
> > > > > >
> > > > > > 1/ why those are not in our termcap(5) ? they should be added if th=
> > ey a=3D
> > > > re
> > > > > > missing. and MFC asap (prior 11.4 and 12.2 would be nice)
> > > > >=3D20
> > > > > I came to this conclusion last night after sending this email thread =
> > oud=3D
> > > > =3D20
> > > > > and will test it some time today.
> > > > >=3D20
> > > > > >
> > > > > > 2/ we should allow our base ncurses to get informations from newer =
> > term=3D
> > > > cap(=3D3D
> > > > > > 5) if
> > > > > > needed.
> > > > > > So far the default TERMCAP is
> > > > > > ${HOME}/.termcap{,.db}:/etc/termcap{,.db}:/usr/share/misc/termcap{,=
> > =2Edb}
> > > > > >
> > > > > > First the user can be advise to point configure the $home/.termcap =
> > this=3D
> > > >  is =3D3D
> > > > > > for
> > > > > > quick now.
> > > >
> > > > that is in your scope via a pkg-message :D
> > > >
> > > > > >
> > > > > > Second for later futur proof mechanism we could modify our termcap =
> > read=3D
> > > > er (=3D3D
> > > > > > we
> > > > > > use our own, not the one in provided by ncurses). to be able to fet=
> > ch t=3D
> > > > ermc=3D3D
> > > > > > ap
> > > > > > capabilities from /usr/local/share/misc/termcap/*.conf for example
> > > > > >
> > > > > > This way ports with random termcap info to add would be able to do =
> > it w=3D
> > > > itho=3D3D
> > > > > > ut
> > > > > > the requirement to wait for a commit in base and a MFC.
> > > > >=3D20
> > > > > This is probably outside of my scope at the moment but, yes, agreed.
> > > > >=3D20
> > > > I will then.
> > > > I added that to my TODO
> > >=20
> > > There's already a utility in devel/ncurses called infotocap (and its=20
> > > corresponding captoinfo) that already does this. Both are links to tic. O=
> > ur=20
> > > ncurses import includes tic. Looks like all that's needed is add it to=20
> > > buildworld.
> > >=20
> > > I can look at it later tonight. Seems like a quick win.
> > >=20
> > That is not the point, tic won't work here except if create your own versio=
> > n or
> > use infotocap. Tic is for terminfo databases while we are still using the=
> > =20
> > termcap for historical reason
> 
> I'm not suggesting replacing all of termcap. Just adding some converted 
> screen.* entries.
> 
> >
> > Having both ncurses from ports and ncurses from base installed at the same =
> > time
> > can open a special can of worm so imho that is not really something we want=
> >  to
> > look forward.
> 
> Some ports require ncurses from ports. Same can of worms as installing a 
> kerberos or openssl port.
> 
On head, no ports should have to now.

Best regards,

Update of multimedia/makemkv, looking for help and feedback to get it committed

2020-05-04 Thread Felix Palmen 
Hi all,

this is about
.

rodrigo@ already took it a while ago and he was very helpful in the
past, unfortunately I didn't hear from him any more since April, 23rd
and I last contacted him 3 days ago – I hope he is fine!

As MakeMKV disables older versions soon after new releases, there is
good reason to get this update in the tree soon. It was probably my
fault to combine the new version with an authorized change to also offer
a binary package in the future.

As for the creation of a package, this is already approved after sending
the explicit permission received from the copyright holder to core@.

What I'm asking you for is:

1. Feedback about the portlint issue that I described in a comment in
   the PR. I brought this up on IRC already and it seems such issues
   could be accepted for good reasons, but a comment in the port
   Makefile explaining these reasons would be very welcome?
2. Once this is sorted out, maybe someone to step in for getting this
   committed soon?

Thanks and BR,
Felix

-- 
 Dipl.-Inform. Felix Palmen ,.//..
 {web}  http://palmen-it.de  {jabber} [see email]   ,//palmen-it.de
 {pgp public key} http://palmen-it.de/pub.txt   //   """
 {pgp fingerprint} A891 3D55 5F2E 3A74 3965 B997 3EF2 8B0A BC02 DA2A


signature.asc
Description: PGP signature

Re: Bind 9.16 port error still lingers

2020-05-04 Thread Christoph Moench-Tegeder 
## The Doctor via freebsd-ports (freebsd-ports@freebsd.org):

> Well I did find a dead zone and still no dice.

That's unfortunate. Completely nothing in config, zones, journals
(if any)? Then it's either something totally obvious (obvious like
an elephant in the room) which we're missing; or something is completely
borked on your system. (BTW, where are you getting your packages from?)

That would be a good point to rebuild bind with debug symbols, so we
can get a meaningful stack trace; and if that narrows things down
perhaps some tactical log statements. Or you could try cutting your
config down to the bare minimum and if bind starts, work backwawrds
from there. Whatever you're more comfortable with.

Regards,
Christoph

-- 
Spare Space
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: FreeBSD Port: open-vm-tools-11.0.1_3,2

2020-05-04 Thread Kurt Buff - GSEC, GCIH 
 All,

Has been done?

I just built a new machine on our VMware cluster and tried to install this
from ports on 12.1-RELEASE-p3 with an updated tree, and it complained about
a dependency:

===>  python27-2.7.17_1 has known vulnerabilities:
python27-2.7.17_1 is vulnerable:
Python -- Regular Expression DoS attack against client
CVE: CVE-2020-8492
WWW:
https://vuxml.FreeBSD.org/freebsd/a27b0bb6-84fc-11ea-b5b4-641c67a117d8.html

Thanks,

Kurt

On Wed, Apr 29, 2020 at 2:11 PM Dutchman01 via freebsd-ports <
freebsd-ports@freebsd.org> wrote:

> Hi, new maintenance release is out,
>
> this port could use an upstream release.
>
>
>
> Can you please upgrade the port?
>
>
>
> Ty , regards,
>
> dutchy
>
> ___
> freebsd-ports@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
>
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: FreeBSD Port: open-vm-tools-11.0.1_3,2

2020-05-04 Thread Dewayne Geraghty 
Suggest that you add to make.conf
DISABLE_VULNERABILITIES=yes


On 5/05/2020 8:08 am, Kurt Buff - GSEC, GCIH wrote:
>  All,
> 
> Has been done?
> 
> I just built a new machine on our VMware cluster and tried to install this
> from ports on 12.1-RELEASE-p3 with an updated tree, and it complained about
> a dependency:
> 
> ===>  python27-2.7.17_1 has known vulnerabilities:
> python27-2.7.17_1 is vulnerable:
> Python -- Regular Expression DoS attack against client
> CVE: CVE-2020-8492
> WWW:
> https://vuxml.FreeBSD.org/freebsd/a27b0bb6-84fc-11ea-b5b4-641c67a117d8.html
> 
> Thanks,
> 
> Kurt
> 
> On Wed, Apr 29, 2020 at 2:11 PM Dutchman01 via freebsd-ports <
> freebsd-ports@freebsd.org> wrote:
> 
>> Hi, new maintenance release is out,
>>
>> this port could use an upstream release.
>>
>>
>>
>> Can you please upgrade the port?
>>
>>
>>
>> Ty , regards,
>>
>> dutchy
>>
>> ___
>> freebsd-ports@freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-ports
>> To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
>>
> ___
> freebsd-ports@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
> 

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: FreeBSD Port: open-vm-tools-11.0.1_3,2

2020-05-04 Thread Kurt Buff - GSEC, GCIH 
Saw that, and would prefer not at this point, given that this VM is part of
my security infrastructure.

I can take any performance hit while waiting for the fix.

Kurt

On Mon, May 4, 2020 at 4:41 PM Dewayne Geraghty <
dewa...@heuristicsystems.com.au> wrote:

> Suggest that you add to make.conf
> DISABLE_VULNERABILITIES=yes
>
>
> On 5/05/2020 8:08 am, Kurt Buff - GSEC, GCIH wrote:
> >  All,
> >
> > Has been done?
> >
> > I just built a new machine on our VMware cluster and tried to install
> this
> > from ports on 12.1-RELEASE-p3 with an updated tree, and it complained
> about
> > a dependency:
> >
> > ===>  python27-2.7.17_1 has known vulnerabilities:
> > python27-2.7.17_1 is vulnerable:
> > Python -- Regular Expression DoS attack against client
> > CVE: CVE-2020-8492
> > WWW:
> >
> https://vuxml.FreeBSD.org/freebsd/a27b0bb6-84fc-11ea-b5b4-641c67a117d8.html
> >
> > Thanks,
> >
> > Kurt
> >
> > On Wed, Apr 29, 2020 at 2:11 PM Dutchman01 via freebsd-ports <
> > freebsd-ports@freebsd.org> wrote:
> >
> >> Hi, new maintenance release is out,
> >>
> >> this port could use an upstream release.
> >>
> >>
> >>
> >> Can you please upgrade the port?
> >>
> >>
> >>
> >> Ty , regards,
> >>
> >> dutchy
> >>
> >> ___
> >> freebsd-ports@freebsd.org mailing list
> >> https://lists.freebsd.org/mailman/listinfo/freebsd-ports
> >> To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org
> "
> >>
> > ___
> > freebsd-ports@freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-ports
> > To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
> >
>
> ___
> freebsd-ports@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
>
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: FreeBSD Port: open-vm-tools-11.0.1_3,2

2020-05-04 Thread Kurt Buff - GSEC, GCIH 
On Mon, May 4, 2020 at 4:46 PM Josh Paetzel  wrote:
> On Mon, May 4, 2020, at 5:08 PM, Kurt Buff - GSEC, GCIH wrote:
> >  All,
> >
> > Has been done?
> >
> > I just built a new machine on our VMware cluster and tried to install this
> > from ports on 12.1-RELEASE-p3 with an updated tree, and it complained about
> > a dependency:
> >
> > ===>  python27-2.7.17_1 has known vulnerabilities:
> > python27-2.7.17_1 is vulnerable:
> > Python -- Regular Expression DoS attack against client
> > CVE: CVE-2020-8492
> > WWW:
> > https://vuxml.FreeBSD.org/freebsd/a27b0bb6-84fc-11ea-b5b4-641c67a117d8.html
> >
> > Thanks,
> >
> > Kurt
>
> That doesn't have anything to do with an open-vm-tools version bump.
>
> The issue you are seeing is due to the fact that 
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=245776 hasn't been 
> committed yet.
>
> --
>
> Thanks,
>
> Josh Paetzel

Got it. I'll keep an eye on that bug.

Thanks,

Kurt
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

FreeBSD ports you maintain which are out of date

2020-05-04 Thread portscout 
Dear port maintainer,

The portscout new distfile checker has detected that one or more of your
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. If any ports have already been updated, you can
safely ignore the entry.

You will not be e-mailed 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
+-+
science/afni| 20.1.05 | afni_20.1.06
+-+
sysutils/google-compute-engine-oslogin  | 20191018.00 | 20200504.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!
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"