FreeBSD ports you maintain which are out of date

2020-03-01 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
+-+
math/R-cran-forcats | 0.3.0   | 0.5.0
+-+


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"


Re: Unable to run "pkg update -f" on 13-CURRENT

2020-03-01 Thread Kubilay Kocak

On 2/03/2020 2:47 pm, Neel Chauhan wrote:

Hi freebsd-ports@,

I am running FreeBSD 13-CURRENT and I am getting this error on a "pkg 
update":


pkg: wrong architecture: FreeBSD:13.0:amd64 instead of FreeBSD:13:amd64
pkg: repository FreeBSD contains packages with wrong ABI: 
FreeBSD:13.0:amd64


I am running FreeBSD 13-CURRENT r358510.

Why is this happening?

I also filed a bug on Bugzilla: 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=244549


-Neel

===

https://www.neelc.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"


There's a known issue with the official FreeBSD package builders (which 
use ports-mgmt/pkg-devel) causing mismatched ABI error messages for 
package users after a recent pkg-devel update.


Pull request addressing the issue has been submitted by Kyle (CC'd):

https://github.com/freebsd/pkg/pull/1817

The change needs to be deployed to the build cluster to resolve the issue
___
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"


Unable to run "pkg update -f" on 13-CURRENT

2020-03-01 Thread Neel Chauhan

Hi freebsd-ports@,

I am running FreeBSD 13-CURRENT and I am getting this error on a "pkg 
update":


pkg: wrong architecture: FreeBSD:13.0:amd64 instead of FreeBSD:13:amd64
pkg: repository FreeBSD contains packages with wrong ABI: 
FreeBSD:13.0:amd64


I am running FreeBSD 13-CURRENT r358510.

Why is this happening?

I also filed a bug on Bugzilla: 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=244549


-Neel

===

https://www.neelc.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: ports-mgmt/poudriere-devel does not follow options

2020-03-01 Thread Martin Neubauer


On 01/03/2020 10:06, Miroslav Lachman wrote:
> I migrated from "poudriere" to "poudriere-devel" about week ago that's
> when I noticed this problem. That's why I suspect poudriere-devel.
> Everything worked for me for years with poudriere.
> 
> I search my command history and I never called poudriere options with -j
> 
> It was like
> poudriere options -z php71m103 -p default -c mail/dovecot
> graphics/py-pillow www/nginx
> poudriere options -z php71m103 -p default -c ports-mgmt/poudriere-devel
> poudriere options -z php71m103 -p default -f
> /usr/local/etc/poudriere.d/pkglists/php71m103
> poudriere bulk -j 11_3_amd64 -z php71m103 -p default -c -f
> /usr/local/etc/poudriere.d/pkglists/php71m103
> 
> I don't know when / what command exactly created
> 11_3_amd64-default-php71m103-options in disk.
I admit that's looking odd, but even if the exact command that led to
the presence of that directory can't be reconstructed, it should at
least be possible to gather some information regarding the time that
happened. "ls -lU" should give at least some starting point.



signature.asc
Description: OpenPGP digital signature


Re: When to use TMPPLIST instead of pkg-plist?

2020-03-01 Thread Mathieu Arnold
On Sat, Feb 29, 2020 at 11:29:18AM -0800, Chris wrote:
> On Sat, 29 Feb 2020 11:02:23 +0100 Mateusz Piotrowski 0...@freebsd.org said
> 
> > On 2/29/20 12:15 AM, Mathieu Arnold wrote:
> > > On Fri, Feb 28, 2020 at 10:06:19PM +0100, Mateusz Piotrowski wrote:
> > >> Do we have any (perhaps unwritten) policy for when to use TMPPLIST? And
> > > when
> > >> should a port maintainer stick to pkg-plist?
> > > We do not.  A port maintainer should stick to pkg-plist.
> > 
> > That's what I thought.
> > 
> > Is there a reason for it? Does it all boil down to that fact that
> > pkg-plist is much more explicit and easier to debug/review? Or there is
> > another reason?
> TMPPLIST is an artifact of the QA process when making a port. It is used

So, I stopped reading there because as this is wrong, all that comes
afterwards was also ;-)

TMPPLIST is the file where all of PLIST_FILES/DIR go after being
processsed for %%FOO%% placeholders, it is where pkg-plist ends up, also
after being processed for placeholders.

It is also where stuff get added, like .info files from the INFO
variable, @ldconfig calls from USE_LDCONFIG, rc file from USE_RC_SUBR,
docs and examples from PORTDOCS and PORTEXAMPLES, and probably a few
other things pile up in there.

All in all, TMPPLIST is the temporary file where every file, directory,
keyword... utimately every part of the framework, end up putting what
needs to end up in the package.

It is also used in the QA process, to tell the user if stuff is wrong
wrt what is really installed, but it is not the other way round.


-- 
Mathieu Arnold


signature.asc
Description: PGP signature


Re: Linux-steam-utils

2020-03-01 Thread Kurt Jaeger
Hi!

> Alex S has done a lot of hard work on a steam port and many other things on
> freebsd in this area. Can we get some eyeballs on his steam port. Much
> Appreciated.
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=244207

I'm testbuilding right now. As I'm not a gamer at all, can someone
do some run-tests and explain how to use that port ?

-- 
p...@opsec.eu+49 171 3101372Now what ?
___
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"


Linux-steam-utils

2020-03-01 Thread Nick Wolff
Hi All,

Alex S has done a lot of hard work on a steam port and many other things on
freebsd in this area. Can we get some eyeballs on his steam port. Much
Appreciated.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=244207

Hope you don't mind this email alex just saw lack of response for some
really fantastic work.

Also of interest

NVshim: Shim to use vulkan with freebsd because nvidia doesn't build
certain libraries with there drivers.
https://github.com/shkhln/nvshim

linuxlator-steam-utils: The repo that the above port pulls from
https://github.com/shkhln/linuxulator-steam-utils
___
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: ports/243787: [NEW PORT] net/mcjoin: Simple multicast testing application for UNIX

2020-03-01 Thread John W. O'Brien
On 2020/03/01 03:35, Kurt Jaeger wrote:
> Hi!
> 
>> This contribution [0] has been awaiting attention for about four weeks,
>> since 2020-02-01 22:20:44 UTC. Are there any friendly, neighborhood
>> committers who would be willing and available to take it?
>>
>> [0] https://bugs.freebsd.org/243787
> 
> Done. Thanks for the cool application, I already have a use case for this 8-)
> 
> Btw, the cause of the delay is a large surge in open ports PRs in
> the last 3-5 weeks, from approx. 250 to 430.
> 

Thank you, Kurt. I understand that folks have a lot of demands on their
time, PR surge or not, and appreciate your taking the time on this one.

-- 
John W. O'Brien
OpenPGP keys:
0x33C4D64B895DBF3B



signature.asc
Description: OpenPGP digital signature


Re: good gui bit-torrent client?

2020-03-01 Thread Yuri Pankov
On 29 Feb 2020, at 22:39, Miroslav Lachman <000.f...@quip.cz> wrote:
> 
> Robert Huff wrote on 2020/02/29 00:49:
>>  I used to use azureus/vuze, but it hasn't been maintained is
>> quite a while.
>>  So I changed to deluge ... which now has a dependency
>> semi-permanently BROKEN.
>>  What can people recommend as a replacement?
> 
> I used uTurrent in Windows times. When I switched to FreeBSD on my desktop I 
> used Vuze / Azureus. But it was resource hungry and at some point in time no 
> longer works for me.
> Then I tried qBittorrent and I am very happy with it. Simple, stable, good 
> looking with my KDE.
> 
> net-p2p/qbittorrent is my choice

Same here, using it on FreeBSD/macOS/Windows and not seeing any issues (even 
without KDE on FreeBSD).
___
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"


sysutils/munin-*

2020-03-01 Thread Andy Farkas


Trying to setup munin on my home server but it ain't going so well.


[note: to save typing $(WWW) == /usr/local/www/]


I've installed apache24 web server and can see the home page.

The root index.html file is in $(WWW)/apache24/data/ and I can view it 
in a browser. Good.



Then I Installed rrdtool, munin-common, munin-master and munin-node.

I did 'munin-node-configure --shell | sh -x' to populate plugins.


There are now 2 new directories created in $(WWW):

 $(WWW)/cgi-bin/  (munin cgi scripts)

 $(WWW)/munin/  (munin .html files)


This seems wrong because apache has no way to see them.


So I moved $(WWW)/munin/ into $(WWW)/apache24/data/ and did a

'ln -s apache24/data/munin/ munin' in the $(WWW) directory, then

copied the files in $(WWW)/cgi-bin/ into $(WWW)/apache24/cgi-bin/


Yay! I can view munin stuff at http://www.mysite/munin/

I think this is what the munin port should've done in the first place.


Any comments so far?


My story continues because it is not working properly yet.

I know munin-master is working because I'm getting an email

every 5 minutes from munin-cron. It says:


"Undefined subroutine ::graph called at 
/usr/local/lib/perl5/site_perl/Munin/Master/GraphOld.pm line 1406."



and no graphs are showing, only broken-image icons.


Any pointers on where to look to fix this?


Thanks,


-andyf


___
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: ports-mgmt/poudriere-devel does not follow options

2020-03-01 Thread Miroslav Lachman

Martin Neubauer wrote on 2020/03/01 02:00:



On 01/03/2020 00:29, Miroslav Lachman wrote:

Martin Neubauer wrote on 2020/02/29 23:44:


[...]


But I am talking about "poudriere options" taking different saved
options than "poudriere bulk".
The "poudriere options" does not show me any dialog because they are all
set in "default-php71m103-options" and then "poudriere bulk" ignore
settings in "default-php71m103-options".
That is a bug from my point of view. Both commands should work with the
same set of stored options. Otherwise if "poudriere bulk" wants options
from "11_3_amd64-default-php71m103-options" I am not able to set those
options by calling "poudriere options".

If the issued command lines were in fact those from your earlier mail,
then you did in fact request two different option sets. If you also add
"-j 11_3_amd64" to the "poudriere options" call, you should access the
same option set the "poudriere bulk" run did.


I migrated from "poudriere" to "poudriere-devel" about week ago that's 
when I noticed this problem. That's why I suspect poudriere-devel. 
Everything worked for me for years with poudriere.


I search my command history and I never called poudriere options with -j

It was like
poudriere options -z php71m103 -p default -c mail/dovecot 
graphics/py-pillow www/nginx

poudriere options -z php71m103 -p default -c ports-mgmt/poudriere-devel
poudriere options -z php71m103 -p default -f 
/usr/local/etc/poudriere.d/pkglists/php71m103
poudriere bulk -j 11_3_amd64 -z php71m103 -p default -c -f 
/usr/local/etc/poudriere.d/pkglists/php71m103


I don't know when / what command exactly created 
11_3_amd64-default-php71m103-options in disk.


You are right that anything after that is "expected behaviour", a bit 
unexpected to me.


Kind regards
Miroslav Lachman
___
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: ports/243787: [NEW PORT] net/mcjoin: Simple multicast testing application for UNIX

2020-03-01 Thread Kurt Jaeger
Hi!

> This contribution [0] has been awaiting attention for about four weeks,
> since 2020-02-01 22:20:44 UTC. Are there any friendly, neighborhood
> committers who would be willing and available to take it?
> 
> [0] https://bugs.freebsd.org/243787

Done. Thanks for the cool application, I already have a use case for this 8-)

Btw, the cause of the delay is a large surge in open ports PRs in
the last 3-5 weeks, from approx. 250 to 430.

-- 
p...@opsec.eu+49 171 3101372Now what ?
___
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"