Hello Florian, Florian Viehweger <open...@out-of-creativity.de> wrote: > Hi, > > this is an revised update for chafa I released some time ago. > > Changes are listed here[1]. > > Some testing done on amd64. No issues found. I'll do some testing later > on i386. > > Tests on big endian architectures welcome. > > portcheck, 'make lib-depends-check' and 'make test' are happy. > > Comments?
diff looks fine minor one nit below. I've quickly tested on amd64 and it works well, thanks! :) > Thanks! > > [1] https://github.com/hpjansson/chafa/blob/master/NEWS > > > Index: Makefile > =================================================================== > RCS file: /cvs/ports/graphics/chafa/Makefile,v > retrieving revision 1.4 > diff -u -p -u -p -r1.4 Makefile > --- Makefile 19 Jun 2021 11:35:54 -0000 1.4 > +++ Makefile 10 Mar 2022 12:45:29 -0000 > @@ -1,9 +1,7 @@ > -# $OpenBSD: Makefile,v 1.4 2021/06/19 11:35:54 sthen Exp $ > - > COMMENT = character art facsimile generator > -DISTNAME = chafa-1.6.1 > +DISTNAME = chafa-1.8.0 > > -SHARED_LIBS += chafa 1.0 # 5.0 > +SHARED_LIBS += chafa 1.1 # 1.0 The format usually is SHARED_LIBS += library-name our-version # upstream-version judging by chafa/libchafa.la the upstream soversion is 6.0, so it should read +SHARED_LIBS += chafa 1.1 # 6.0 if we're interested in keeping the information. However, even if check_sym reports only additions, I think we should bump the major in this case. I took a look at the diff between 1.6.1 and 1.8.0 here (I've skipped the internal/ headers) https://github.com/hpjansson/chafa/compare/1.6.1...1.8.0 and in chafa/chafa-term-info.h there was this change: -#define CHAFA_TERM_SEQ_LENGTH_MAX 48 +#define CHAFA_TERM_SEQ_LENGTH_MAX 96 I did a quick grep and it seems that various functions are taking a buffer that must be _at least_ large CHAFA_TERM_SEQ_LENGTH_MAX. For instance: chafa/chafa-term-seq-doc.h: | /** | * chafa_term_info_emit_reset_terminal_soft: | * @term_info: A #ChafaTermInfo | * @dest: String destination | * | * Prints the control sequence for #CHAFA_TERM_SEQ_RESET_TERMINAL_SOFT. | * | * @dest must have enough space to hold | * #CHAFA_TERM_SEQ_LENGTH_MAX bytes, even if the emitted sequence is | * shorter. The output will not be zero-terminated. | * | * Returns: Pointer to first byte after emitted string | * | * Since: 1.6 | **/ | gchar *chafa_term_info_emit_reset_terminal_soft (const ChafaTermInfo | *term_info, gchar *dest ); (there are multiple functions like this) so a major bump is needed. > CATEGORIES = graphics > > @@ -15,10 +13,10 @@ MAINTAINER = Florian Viehweger <openbsd > PERMIT_PACKAGE = Yes > > WANTLIB += ICE MagickCore-6.Q16 MagickWand-6.Q16 SM X11 Xext Xt > -WANTLIB += bz2 c djvulibre expat fftw3 fontconfig freetype glib-2.0 > -WANTLIB += iconv intl jasper jbig jpeg lcms2 lzma m openjp2 pcre > -WANTLIB += png pthread raw_r tiff webp webpdemux webpmux xcb xml2 > -WANTLIB += z zstd > +WANTLIB += aom bz2 c dav1d de265 djvulibre expat fontconfig > +WANTLIB += freetype glib-2.0 heif iconv intl jasper jbig jpeg > +WANTLIB += lcms2 lzma m openjp2 pcre png pthread raw_r tiff webp > +WANTLIB += webpdemux webpmux x265 xcb xml2 z zstd this is just a matter of preference, but since we're updating the WANTLIB it could have been a chance to just paste the output from `make port-lib-depends-check' here without the extra indentation; I think it's easier to manage that way. your call tho :) Cheers Omar Polo
