Re: new emulators/libchdr

2023-04-27 Thread bentley
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 version specs, it's also confusing to some people (who
think it's like REVISION and gets removed on update, etc.). I try to
avoid EPOCH generally, but I don't try too hard.



Re: new emulators/libchdr

2023-04-26 Thread Stuart Henderson
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 less
> than 1.0; but rolling back from 1.0 now that it's been committed would
> mean a guaranteed EPOCH now. Stick with 1.0pl20230220 and no EPOCH.

Agreed (though 0plXX looks a bit odd to me and I'd probably go for
0.0.2023 in that case)

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.



Re: new emulators/libchdr

2023-04-26 Thread bentley
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 committed would
mean a guaranteed EPOCH now. Stick with 1.0pl20230220 and no EPOCH.

The rest of your diff is ok with me.



Re: new emulators/libchdr

2023-04-26 Thread Nam Nguyen
"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 codebase which read up to CHDv4
>> with OS-dependent features removed, and CHDv5 support backported from
>> MAME's current C++ codebase.
>>
>> OK to import?
>
> The commit history lists some changes we might want: null dereference
> fix, buffer overrun fix, additional codec. Any reason not to base the
> port on the latest commit?
>
> It would be better to use a lower version number than 1.0, in case
> they make a release with a version like 0.1 that would necessitate
> EPOCH. Maybe even just use "0pl20221022"...

Sorry about that. I imported it as is, so I will change to 0pl with
EPOCH. Here is an inline diff that does the following:

- bump EPOCH because version is erroneously marked 1.0. start with 0pl
  in order to leave room for future release names.
- update to 0pl20230220
- major bump chdr because long --> long long in function signature

while here:
- add devel category
- build with system zlib and add z to WANTLIB
- add license marker for lzma and zlib

details on major bump:

check_sym doesn't reveal much.

/usr/local/lib/libchdr.so.0.0 --> /usr/local/lib/libchdr.so.1.0
No dynamic export changes
External reference changes:
added:
inflate
inflateEnd
inflateInit2_
inflateReset

However, diffing headers
(https://namtsui.com/public/chdr_major_bump.txt) reveals that long was
changed to INT64 aka long long. Types changed in an incompatible way in
a public header (coretypes.h), so a major bump is warranted.

-   int (*fseek)(struct chd_core_file*, long, int);
+   int (*fseek)(struct chd_core_file*, INT64, int);

-static inline int core_fseek(core_file* fp, long offset, int whence) {
+static inline int core_fseek(core_file* fp, INT64 offset, int whence) {

emulators/flycast still compiles.

OK?

Index: Makefile
===
RCS file: /cvs/ports/emulators/libchdr/Makefile,v
retrieving revision 1.1.1.1
diff -u -p -u -p -r1.1.1.1 Makefile
--- Makefile25 Apr 2023 19:21:00 -  1.1.1.1
+++ Makefile26 Apr 2023 17:47:43 -
@@ -1,20 +1,27 @@
 COMMENT =  library for reading MAME's CHDv1-v5 formats
 
-V =1.0pl20221022
+V =0pl20230220
+EPOCH =0
 DISTNAME = libchdr-$V
 
 GH_ACCOUNT =   rtissera
 GH_PROJECT =   libchdr
-GH_COMMIT =464044e6cc5c7cfeb331906f4ef67d13dd4c83b6
+GH_COMMIT =fec8ab94212cc65d9d9a62cb3da924f5830c04b0
 
-SHARED_LIBS += chdr0.0 # 0.1
+SHARED_LIBS += chdr1.0 # 0.1
 
-CATEGORIES =   emulators games
+CATEGORIES =   emulators devel games
 
 HOMEPAGE = https://github.com/rtissera/libchdr
 
+CONFIGURE_ARGS +=  -DWITH_SYSTEM_ZLIB=ON
+
 # BSD 3-Clause
+# Public Domain (lzma)
+# zlib (zlib)
 PERMIT_PACKAGE =   Yes
+
+WANTLIB += z
 
 MODULES =  devel/cmake
 
Index: distinfo
===
RCS file: /cvs/ports/emulators/libchdr/distinfo,v
retrieving revision 1.1.1.1
diff -u -p -u -p -r1.1.1.1 distinfo
--- distinfo25 Apr 2023 19:21:00 -  1.1.1.1
+++ distinfo26 Apr 2023 17:47:43 -
@@ -1,2 +1,2 @@
-SHA256 (libchdr-1.0pl20221022-464044e6.tar.gz) = 
HCAG/ah/3ijsvk2mkJPQZHc0IqifbqnCMRXTC4YVOf4=
-SIZE (libchdr-1.0pl20221022-464044e6.tar.gz) = 1748201
+SHA256 (libchdr-0pl20230220-fec8ab94.tar.gz) = 
i4fxorIt44yfsWdRN8jxl0MQW4NzrYynDs8DpjngT88=
+SIZE (libchdr-0pl20230220-fec8ab94.tar.gz) = 1748513



Re: new emulators/libchdr

2023-04-25 Thread bentley
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 OS-dependent features removed, and CHDv5 support backported from
> MAME's current C++ codebase.
>
> OK to import?

The commit history lists some changes we might want: null dereference
fix, buffer overrun fix, additional codec. Any reason not to base the
port on the latest commit?

It would be better to use a lower version number than 1.0, in case
they make a release with a version like 0.1 that would necessitate
EPOCH. Maybe even just use "0pl20221022"...