FreeBSD ports you maintain which are out of date
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 +-+ devel/py-streamparse| 3.14.0 | 3.15.0 +-+ security/snort3 | 3.0.0-a4.243| 3.0.0-250 +-+ 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 Thanks. ___ 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"
[CFT] Mesa 18.3.0 update (mesa-libs, mesa-dri, libosmesa, clover)
Mesa provides OpenGL/Vulkan drivers for Intel/AMD cards and also VAAPI/VDPAU
drivers for AMD cards. Recently, a new minor version was released. So far it
was only tested Skylake with drm-stable-kmod on 13.0-CURRENT. Can someone test
on FreeBSD 11.2 for regressions? If you find any confirm previous version(s)
aren't affected then attach /var/log/Xorg.0.log and LIBGL_DEBUG=verbose output.
# Apply
$ fetch -qo /tmp/mesa-18.2.diff
'https://reviews.freebsd.org/D16571?download=true'
$ fetch -qo /tmp/mesa-18.3.diff
'https://reviews.freebsd.org/D17872?download=true'
$ patch -Efsp0 -i /tmp/mesa-18.2.diff -d /usr/ports
$ patch -Efsp0 -i /tmp/mesa-18.3.diff -d /usr/ports
$ make all deinstall install clean -C /usr/ports/graphics/mesa-libs
$ make all deinstall install clean -C /usr/ports/graphics/mesa-dri
# Undo
$ patch -REfsp0 -i /tmp/mesa-18.3.diff -d /usr/ports
$ patch -REfsp0 -i /tmp/mesa-18.2.diff -d /usr/ports
$ make all deinstall install clean -C /usr/ports/graphics/mesa-libs
$ make all deinstall install clean -C /usr/ports/graphics/mesa-dri
# Testing examples
- graphics/mesa-demos: glxgears, eglgears_x11
- multimedia/mpv: --hwdec=auto (VAAPI/VDPAU EGL interop)
- www/firefox: MOZ_ACCELERATED=1 MOZ_WEBRENDER=1 (GPU compositing)
- https://forums.freebsd.org/threads/unreal-engine-4.65300/
- devel/vulkan-tools: vulkaninfo
- games/vkquake or emulators/{ppsspp,rpcs3} with Vulkan renderer
___
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: Best way to deal with .pyc files?
On 12/6/18 11:17 AM, Michael Gmelin wrote:
>
>
>> On 6. Dec 2018, at 19:21, John Baldwin wrote:
>>
>> The devel/gdb port installs python scripts into
>> /usr/local/share/gdb/python.
>> If you then run kgdb as root (not that unusual), it will generate .pyc files
>> in
>> those directories that are not deleted by 'pkg delete'. What is the best
>> way to
>> handle this case? Should the pkg-plist include @rmtry entries for each pyc
>> file or is there a better way?
>>
>
> Pre-generate the pyc files on package build and install them with the port,
> so they become part of plist (there are examples of that in the ports tree,
> whenever possible for both py27 and py3x).
Ok. One follow-up question. GDB's python bindings work with both py2 and
py3, but the bindings are optional. Right now PYTHON is a port option
(but on by default). If I wanted to add flavors I would probably want them
to be conditional on the option, so the results would be 'gdb' and
'gdb-py3' packages by default, but if someone was using poudriere locally
and disabled python, I would only want to build a single 'gdb' without
python. So, can I make the flavors conditional on an option or is it too
late to define flavors after including bsd.ports.options.mk?
That is, can I do something this:
OPTIONS_DEFINE= PYTHON
OPTIONS_DEFAULT= PYTHON
.include
.if ${PORT_OPTIONS:MPYTHON}
USES_PYTHON= flavors
.endif
--
John Baldwin
___
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: New virtual (physical?) ports category: blockchain
On 12/6/18 5:28 PM, Robert wrote: So most of blockchain implementations and related libs reside in finance\net-p2p categories, I think neither of these sounds as a good category name. So I propose to move them into a separate category and name it: blockchain (tada). The list of candidates we already have is definitely larger than vietnamese\ukrainian etc so maybe worth a separate physical category? (though not as large as x11-clocks yet but I believe much more is coming...). wow that's more ports than I had realized were available, and i think it would be something that would help me personally. The only nit I have is that many of these seem to be crypto-currency specific. Reason I mention it is I think we'll see more blockchain tools come out that don't necessarily deal with crypto-currencies. Although it's a pretty silly differentiation to make that most people won't really care about :) +1 from me! -pete -- Pete Wright p...@nomadlogic.org @nomadlogicLA ___ 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"
