Attached is an updated version of Brian Callahan's port of
net/purple-hangouts.
(https://marc.info/?l=openbsd-ports&m=151484340626848&w=2)
I contacted Brian who said:
--8<---cut here---start->8---
I don't use it so take over maintainer and send it to the
lis
On Sat, Apr 20, 2019 at 10:39:28PM -0400, Daniel Jakots wrote:
> On Sat, 20 Apr 2019 19:22:07 -0700, Andrew Hewus Fresh
> wrote:
>
> > tl;dr, fixes portgen(1) for python modules that have distnames that
> > start with py-.
>
> Thanks for working on that!
>
> One suggestion, does a DISTNAME of "
On Sat, Apr 20, 2019 at 10:44:39PM -0400, Kurt Mosiejczuk wrote:
> On Sat, Apr 20, 2019 at 10:39:28PM -0400, Daniel Jakots wrote:
> > On Sat, 20 Apr 2019 19:22:07 -0700, Andrew Hewus Fresh
> > wrote:
>
> > > tl;dr, fixes portgen(1) for python modules that have distnames that
> > > start with py-.
> http://build-failures.rhaalovely.net/powerpc/last/security/suricata.log
> http://build-failures.rhaalovely.net/sparc64/last/security/suricata.log
Suricata is one of these ports having issues with thread local storage
with base-gcc and C99.
This diff defines COMPILER, so we use ports-gcc inst
On Sat, 20 Apr 2019 19:22:07 -0700, Andrew Hewus Fresh
wrote:
> tl;dr, fixes portgen(1) for python modules that have distnames that
> start with py-.
Thanks for working on that!
One suggestion, does a DISTNAME of "python-foo" is renamed to "py-foo"
by portgen(1)?
The first result (as an exampl
tl;dr, fixes portgen(1) for python modules that have distnames that
start with py-.
I'm not quite sure why things were done this way, I'm assuming it was
for ruby, but it was getting us into a loop that unsurprisingly confuses
the ports system.
$ portgen py py-cpuinfo
> Arguments.h:103:22: error: 'constexpr' needed for in-class
> initialization of static data member
It's again due to the fact that gcc-8 uses C++14 as its default C++
standard.
Expanding the use of C++03 to any compiler fixes the build on
macppc/ports-gcc-8.
The test suite was partly broken b
> src/cmeta.cpp:1386:16: error: converting to 'bool' from
> 'std::nullptr_t' requires direct-initialization [-fpermissive]
> return NULL;
Again, it breaks because it wants C++<11. Building libmp4v2
with C++03 for any compiler fixes the issue.
It has been successfully tested on macppc/po
> http://build-failures.rhaalovely.net/sparc64/last/comms/hackrf.log
> http://build-failures.rhaalovely.net/powerpc/last/comms/hackrf.log
Big endianness cannot be detected with base-gcc.
I've not much to say, using ports-gcc instead just works :)
Works fine on macppc/ports-gcc-{8,4.9}.
OK?
Hi ports,
Hylafax doesn't build with ports-gcc-8:
> FaxRecvInfo.c++:115:20: error: ISO C++ forbids comparison between
> pointer and integer [-fpermissive]
Using C++03 like we're doing currently with base-clang doesn't help. It
appears that Debian has fixes [0] for gcc>=7, i used them.
The diff
- Remove rc_pre
On 4/20/19, Horia Racoviceanu wrote:
> - Remove defaults
> - Use syslog
> - Fix templates
>
> On 4/19/19, Stuart Henderson wrote:
>> This has various things (in Makefile and the rc script) explicitly set
>> to the default (MAINTAINER, daemon_flags, daemon_rtable, etc), please
>>
- Remove defaults
- Use syslog
- Fix templates
On 4/19/19, Stuart Henderson wrote:
> This has various things (in Makefile and the rc script) explicitly set
> to the default (MAINTAINER, daemon_flags, daemon_rtable, etc), please just
> leave those lines out.
>
> The logging setup in this rc script
On Fri, Mar 29 2019, Matthias Kilian wrote:
> Hi,
>
> On Fri, Mar 29, 2019 at 09:38:24PM +0100, Jeremie Courreges-Anglas wrote:
>> > update to poppler-0.75.0, some bug fixes, and a new program (pdfattach)
>> > in poppler-utils.
> [...]
>> Just to be clear: do you plan to commit this before 6.5 is
On Wed, Jan 23, 2019 at 08:26:23AM +0100, Rafael Sadowski wrote:
> On Mon Jan 21, 2019 at 10:23:25AM -0700, Tracey Emery wrote:
> > After some additional testing, I found a leak. So, here is a new port to
> > include
> > that fix. The flaw wasn't discovered until I decided to hammer the daemon
>
On Sat, Apr 20 2019, Thomas Frohwein wrote:
> ping - catch up with sdl2-mixer for 6.6?
One minor nit,
> On Sat, Jan 19, 2019 at 03:00:58PM -0800, Thomas Frohwein wrote:
>> Hi,
>>
>> This diff updates sdl2-mixer from 2.0.2 to 2.0.4. Main changes are
>> addition of Opus support via audio/opusfile
ping - catch up with sdl2-mixer for 6.6?
On Sat, Jan 19, 2019 at 03:00:58PM -0800, Thomas Frohwein wrote:
> Hi,
>
> This diff updates sdl2-mixer from 2.0.2 to 2.0.4. Main changes are
> addition of Opus support via audio/opusfile and some bugfixes. Official
> changelog [1]:
>
> 2.0.4:
> * Removed
Thanks jsg, I've appended the following to DESCR so users will now up
front whether it works on their machine:
At least OpenGL 4.1 is required, which is supported by
3rd generation Intel Core i3/i5/i7 "Ivy Bridge" processors and
ATI/AMD TeraScale 2 "Evergreen" chipsets or l
On Sat, Apr 20, 2019 at 12:42:05PM +0200, Klemens Nanni wrote:
> Here's bonzomatic, working fine so far on my X230 with OpenGL 4.2 so I
> can play with shaders. Controls in the UI work, the visuals render
> perfectly fluid in the background.
>
> Somehow midi input is not working yet and I cannot
On 2019/04/20 12:42, Klemens Nanni wrote:
> Here's bonzomatic, working fine so far on my X230 with OpenGL 4.2 so I
> can play with shaders. Controls in the UI work, the visuals render
> perfectly fluid in the background.
>
> Somehow midi input is not working yet and I cannot see the little
> text
shader.glsl was not meant to be in the tarball, but since you see it:
That's the default code you start with, it was written to $PWD while I
was running bonzomatic from the ports directory.
Here's bonzomatic, working fine so far on my X230 with OpenGL 4.2 so I
can play with shaders. Controls in the UI work, the visuals render
perfectly fluid in the background.
Somehow midi input is not working yet and I cannot see the little
texture previews while coding, but I'd like to work on thi
On 2019/04/20 12:25, Alessandro DE LAURENZIS wrote:
> Hello Stuart,
>
> On 18/04/2019 18:07, Stuart Henderson wrote:
> [...]
> > > > - the pypi tarball doesn't include the tests, which I instead enabled
> > > > using the one from github; is this acceptable?
> >
> > I usually prefer pypi over gith
Hello Stuart,
On 18/04/2019 18:07, Stuart Henderson wrote:
[...]
- the pypi tarball doesn't include the tests, which I instead enabled
using the one from github; is this acceptable?
I usually prefer pypi over github, because pypi uses uploaded files
rather than autogenerated ones which are sub
23 matches
Mail list logo
