Stuart Henderson writes:
> EPOCH isn't really a problem, the main thing (apart from ugly version
> numbers in PKGNAME) is that it can give some surprises with version
> specs in dependencies/@conflict lines/etc.
Yes, EPOCH is a necessary thing sometimes and not a "problem." Besides
its effect on
On 2023/04/26 12:11, bent...@openbsd.org wrote:
> Nam Nguyen writes:
> > Sorry about that. I imported it as is, so I will change to 0pl with
> > EPOCH.
>
> No need for that. The 0pl suggestion (only a suggestion) was to avoid
> hypothetical EPOCH in the future if upstream picks a version number
Nam Nguyen writes:
> Sorry about that. I imported it as is, so I will change to 0pl with
> EPOCH.
No need for that. The 0pl suggestion (only a suggestion) was to avoid
hypothetical EPOCH in the future if upstream picks a version number less
than 1.0; but rolling back from 1.0 now that it's been
"Anthony J. Bentley" writes:
> Nam Nguyen writes:
>> Please find attached libchdr. libchdr is a dependency for
>> emulators/flycast, which I will send shortly.
>>
>> DESCR:
>>
>> libchdr is a standalone library for reading MAME's CHDv1-v5 formats.
>>
>> The code is based off of MAME's old C
Nam Nguyen writes:
> Please find attached libchdr. libchdr is a dependency for
> emulators/flycast, which I will send shortly.
>
> DESCR:
>
> libchdr is a standalone library for reading MAME's CHDv1-v5 formats.
>
> The code is based off of MAME's old C codebase which read up to CHDv4
> with
Please find attached libchdr. libchdr is a dependency for
emulators/flycast, which I will send shortly.
DESCR:
libchdr is a standalone library for reading MAME's CHDv1-v5 formats.
The code is based off of MAME's old C codebase which read up to CHDv4
with OS-dependent features removed, and
