On Tue Jan 28, 2020 at 07:40:18PM +0100, Klemens Nanni wrote:
>
> 1.8.26: Ludovic Rousseau
> 3 January 2020
> - Use poll() instead of select() to allow file descriptor higher than
> FD_SETSIZE
> - Enable reader filtering by default
> - pcsc-spy:
> . Do not read output buffer after error
> . A
On Wed, Jan 29, 2020 at 06:44:53AM +0100, Rafael Sadowski wrote:
> I would like get rid of productivity/qhacc. It's a terrible accounting
> tool (independently of Qt3). We have much more feature-rich, stable,
> easy to use accounting tools for web,qt,gtk,cli in the tree.
>
> OK to remove?
OK kn (m
On Tue, Jan 28, 2020 at 09:19:05AM -0700, Tracey Emery wrote:
> On Tue, Jan 28, 2020 at 07:33:41AM -0700, Tracey Emery wrote:
> > On Tue, Jan 28, 2020 at 07:42:04AM +0100, Martin Reindl wrote:
> > > On Mon, Jan 27, 2020 at 04:06:03PM -0700, Tracey Emery wrote:
> > > > Hello ports,
> > > >
> > > >
On Mon Jan 20, 2020 at 06:32:54PM -0500, Brian Callahan wrote:
>
>
> On 2020-01-10 9:19 AM, Brian Callahan wrote:
> > Hi ports --
> >
> > Attached is an update to HandBrake. Please test.
> > Changelog is here:
> > https://github.com/HandBrake/HandBrake/releases/tag/1.3.1
> >
> > OK?
> >
> > ~B
Hi All
All our consumers only use the qt5 FLAVOR so here is an update diff
which removes the the qt4 pieces and bump to the latest stable version
on github. I did the same like the quazip update from Brian Callahan a
couple days before. Added @pkgpath and bump all consumers.
Comments, OK?
Rafael
On Mon, 27 Jan 2020 00:37:46 +0100
Charlene Wendling wrote:
> Hi,
>
> To start with, the game is not maintained upstream, and as the server
> has glib2 deprecation warnings, it may not be built in a close future.
> It does not run on x86 due to a BROKEN p5-SDL on these 2 archs, and
> updating p5
On Mon, Jan 27, 2020 at 08:08:57AM +, wen heping wrote:
> Thank your OK, afresh1@ !
> But I can not fetch the distfile without the CPAN_AUTHOR line here.
I apologize for being unclear, I didn't mean to remove it completely,
just move it away from where portgen guessed (wrongly) that it should
On Wed, Jan 29, 2020 at 04:49:29PM -0800, Nam Nguyen wrote:
> Kurt Mosiejczuk writes:
> > Committed.
> > --Kurt
> Thank you for the feedback and testing. I think you forgot to commit
> patches/patch-libs_python_src_converter_builtin_converters_cpp (along
> with another REVISION bump when adding
Kurt Mosiejczuk writes:
> On Wed, Jan 29, 2020 at 09:25:14PM +, Stuart Henderson wrote:
>> On 2020/01/28 23:18, Kurt Mosiejczuk wrote:
>> > I just ran this on my speedy amd64 test machine and it built to completion.
>> > It also packaged up. I haven't run any further tests though.
>
>> Thanks.
On Wed, Jan 29, 2020 at 09:25:14PM +, Stuart Henderson wrote:
> On 2020/01/28 23:18, Kurt Mosiejczuk wrote:
> > I just ran this on my speedy amd64 test machine and it built to completion.
> > It also packaged up. I haven't run any further tests though.
> Thanks. i386 bulk is a couple of hours
On Wed, Jan 29, 2020 at 08:41:33PM +0100, Gabriel Kihlman wrote:
> Works for me with ssh and pkcs11 (onepin-opensc-pkcs11.so).
Thanks for testing.
> It was a bit weird that opensc-tool -V still printed 0.19.0 so maybe
> bump the OPESC_SCM_VERSION variable in configure.ac?
>
> configure.ac:OPENSC_
On 2020/01/28 23:18, Kurt Mosiejczuk wrote:
> I just ran this on my speedy amd64 test machine and it built to completion.
> It also packaged up. I haven't run any further tests though.
Thanks. i386 bulk is a couple of hours away from finishing with no fallout
yet (and I really don't expect any now
- either use the directory "vips", or name the package "libvips",
just pick one or the other. "PKGNAME= lib${DISTNAME}" will do if you want
libvips.
(if it's better known as a library then prefer "libvips", if it's better
known for the tools then prefer just "vips").
- seems more like a port that
On 2020/01/29 21:06, Stephane Guedon wrote:
> Just as I got validated for libvips 8.9.0, a new version came out,
> namely 8.9.1, so here it is.
>
> comments ?
Let's just polish 8.9.0 for now since it has more review already (and I've
already downloaded it and it's pretty big..:) then send an upd
Klemens Nanni writes:
> Lots of new support, improvements but also CVE fixes, see
> https://github.com/OpenSC/OpenSC/wiki#news
>
> The shared libraries gained exported symbols but did not lose any, so
> I'm bumping their minors.
>
> Keeps working for me on amd64
Works for me with ssh and pkcs1
Just as I got validated for libvips 8.9.0, a new version came out,
namely 8.9.1, so here it is.
comments ?
libvips.8.9.1.tar.gz
Description: application/compressed-tar
Enclosed diff brings icewm to 1.6.4. Overview of changes can be found at
https://github.com/ice-wm/icewm/releases/. While here update HOMEPAGE.
(Lightly) run tested on amd64.
Comments/OK?
diff --git Makefile Makefile
index 15af55123f5..9f2b5b35bdd 100644
--- Makefile
+++ Makefile
@@ -3,13 +3,13
Hi :)
On Wed, 29 Jan 2020 13:00:38 +
wen heping wrote:
> Hi, ports@:
>
> Here is a simple patch for www/p5-HTML-TableContentParser to
> update to 0.302.
> It build well and pass all tests on amd64-current system.
> No other ports depends on it.
I've found no issues at all.
OK c
Hi, ports@:
Here is a simple patch for www/p5-HTML-TableContentParser to
update to 0.302.
It build well and pass all tests on amd64-current system.
No other ports depends on it.
Cheers !
wen
Index: Makefile
===
RCS file:
Here is the revised patch, which switch back RUN_DEPENDS to
p5-WWW-Form-UrlEncoded.
wen
发件人: Charlene Wendling
发送时间: 2020年1月27日 19:10
收件人: ports@openbsd.org
抄送: wen heping
主题: Re: [Update] www/p5-HTTP-Entity-Parser : Update to 0.22
Hi,
On Mon, 27 Jan 2020 1
Hello,
I already sent this some time ago and even got feedback from sthen and kmos,
but then these two ports kind of dozed of a bit.
As a reminder:
py-cftime: time and date handling utility functions from netcdf4-python
py-netcdf4: Python interface to the netCDF C library
In the meantime, I've m
On Sun, Jan 26, 2020 at 02:32:50PM +0100, Charlene Wendling wrote:
> Hi!
>
> NBlood being based on EDuke32, i've spotted the same atomics issue
> later during the current bulk:
>
> > enet.cpp:(.text+0x2e20): undefined reference to `__atomic_load_8'
> > enet.cpp:(.text+0x2e98): undefined reference
Hi,
@rsadowski pointed out that the port we have is rather old,
despite having much higher version number than recent versions.
attached an update to the latest, now using Qt5 instead of Qt3.
Had to patch it to work around a clang vs. gcc oddity (or bug?).
It starts up for me, but can't test mu
23 matches
Mail list logo