On 2/21/2018 12:43 AM, Brian Inglis wrote:
On 2018-02-20 11:41, Yaakov Selkowitz wrote:
NAME=ffcall
...
PKG_NAMES="libffcall0 libffcall-devel"
libffcall0_CONTENTS=...
libffcall_devel_OBSOLETES="ffcall"
libffcall_devel_CONTENTS=...
Does this generate the ("virtual") package setup entry for:
@
On 2018-02-20 11:41, Yaakov Selkowitz wrote:
> NAME=ffcall
> ...
> PKG_NAMES="libffcall0 libffcall-devel"
> libffcall0_CONTENTS=...
> libffcall_devel_OBSOLETES="ffcall"
> libffcall_devel_CONTENTS=...
Does this generate the ("virtual") package setup entry for:
@ ffcall
...
category: _obsolete
requ
On 2/20/2018 1:41 PM, Yaakov Selkowitz wrote:
On 2018-02-20 09:47, Ken Brown wrote:
A few years ago I adopted ffcall (32-bit only) in order to keep it from
disappearing from the distro:
The latest upstream release builds on 64-bit Cygwin, so I'd like to
update the package, and I'd like to find
On 2018-02-20 09:47, Ken Brown wrote:
> A few years ago I adopted ffcall (32-bit only) in order to keep it from
> disappearing from the distro:
>
> The latest upstream release builds on 64-bit Cygwin, so I'd like to
> update the package, and I'd like to find a sensible way of breaking it
> up into
On 20/02/2018 16:47, Ken Brown wrote:
A few years ago I adopted ffcall (32-bit only) in order to keep it from
disappearing from the distro:
https://sourceware.org/ml/cygwin-apps/2015-07/msg00092.html
But I'm not starting from scratch, and users of the existing ffcall will
need the new
A few years ago I adopted ffcall (32-bit only) in order to keep it from
disappearing from the distro:
https://sourceware.org/ml/cygwin-apps/2015-07/msg00092.html
The latest upstream release builds on 64-bit Cygwin, so I'd like to
update the package, and I'd like to find a sensible way of bre
