Re: [fix] mail/gmime: Fix rfc2047 token decoding logic for base64 encodings
Ok
—
Antoine
> On 16 Aug 2023, at 07:57, Stefan Hagen wrote:
>
> Stuart Henderson wrote (2023-08-14 18:04 CEST):
>>> On 2023/08/14 10:40, Antoine Jacoutot wrote:
>>> On Mon, Aug 14, 2023 at 08:44:25AM +0200, Stefan Hagen wrote:
Hi,
there's a bug in gmime, which is affecting mail/mu. It doesn't look like
there will be a new gmime release anytime soon. Can we cherry-pick this
fix?
Maintainer on CC.
>>>
>>> I am OK with this but could you use a regular patch instead of fetching from
>>> github?
>>
>> +1 million
>>
>
> Sure, here's the same as a regular patch.
>
>
> Index: mail/gmime30/Makefile
> ===
> RCS file: /cvs/ports/mail/gmime30/Makefile,v
> retrieving revision 1.23
> diff -u -p -u -p -r1.23 Makefile
> --- mail/gmime30/Makefile5 Nov 2022 17:06:28 -1.23
> +++ mail/gmime30/Makefile16 Aug 2023 05:53:40 -
> @@ -4,7 +4,7 @@ GH_ACCOUNT=jstedfast
> GH_PROJECT=gmime
> GH_TAGNAME=3.2.13
> PKGNAME=gmime30-${GH_TAGNAME}
> -REVISION=0
> +REVISION=1
>
> SHARED_LIBS += gmime-3.02.2 # 213.0
>
> Index: mail/gmime30/patches/patch-gmime_gmime-utils_c
> ===
> RCS file: mail/gmime30/patches/patch-gmime_gmime-utils_c
> diff -N mail/gmime30/patches/patch-gmime_gmime-utils_c
> --- /dev/null1 Jan 1970 00:00:00 -
> +++ mail/gmime30/patches/patch-gmime_gmime-utils_c16 Aug 2023 05:53:40
> -
> @@ -0,0 +1,26 @@
> +Fix rfc2047 token decoding logic for base64 encodings
> +Bug report: https://github.com/djcb/mu/issues/2429
> +
> +Index: gmime/gmime-utils.c
> +--- gmime/gmime-utils.c.orig
> gmime/gmime-utils.c
> +@@ -1789,10 +1789,16 @@ rfc2047_token_decode (rfc2047_token *token, unsigned
> c
> +const unsigned char *inbuf = (const unsigned char *) token->text;
> +size_t len = token->length;
> +
> +-if (token->encoding == 'B')
> ++if (token->encoding == 'B') {
> ++/* Note: A state of -1 means that a previous rfc2047 encoded-word
> token ended with an '=' (aka 'eof'),
> ++ * so we need to reset the state. */
> ++if (*state == -1)
> ++*state = 0;
> ++
> +return g_mime_encoding_base64_decode_step (inbuf, len, outbuf,
> state, save);
> +-else
> +-return quoted_decode (inbuf, len, outbuf, state, save);
> ++}
> ++
> ++return quoted_decode (inbuf, len, outbuf, state, save);
> + }
> +
> + static char *
> Index: mail/gmime30/patches/patch-tests_test-mime_c
> ===
> RCS file: /cvs/ports/mail/gmime30/patches/patch-tests_test-mime_c,v
> retrieving revision 1.3
> diff -u -p -u -p -r1.3 patch-tests_test-mime_c
> --- mail/gmime30/patches/patch-tests_test-mime_c16 Apr 2022 07:34:04
> -1.3
> +++ mail/gmime30/patches/patch-tests_test-mime_c16 Aug 2023 05:53:40 -
> @@ -1,4 +1,4 @@
> -64bit time_t
> +64bit time_t + Test for rfc2047 token decoding logic for base64 encodings
>
> Index: tests/test-mime.c
> --- tests/test-mime.c.orig
> @@ -12,3 +12,13 @@ Index: tests/test-mime.c
>
> if (tz_offset != dates[i].tzone)
> throw (exception_new ("timezones do not match"));
> +@@ -408,6 +408,9 @@ static struct {
> + "blah:\tI am broken",
> + "blah:\tI am broken" },
> + #endif
> ++{ "=?UTF-8?B?SGVsbG8=?= =?UTF-8?B?IHdvcmxk?=",
> ++ "Hello world",
> ++ "Hello world" },
> +{ "=?iso-8859-1?Q?Copy_of_Rapport_fra_Norges_R=E5fisklag=2Edoc?=",
> + "Copy of Rapport fra Norges R\xc3\xa5" "fisklag.doc",
> + "Copy of Rapport fra Norges =?iso-8859-1?q?R=E5fisklag=2Edoc?=" },
Re: [fix] mail/gmime: Fix rfc2047 token decoding logic for base64 encodings
Stuart Henderson wrote (2023-08-14 18:04 CEST):
> On 2023/08/14 10:40, Antoine Jacoutot wrote:
> > On Mon, Aug 14, 2023 at 08:44:25AM +0200, Stefan Hagen wrote:
> > > Hi,
> > >
> > > there's a bug in gmime, which is affecting mail/mu. It doesn't look like
> > > there will be a new gmime release anytime soon. Can we cherry-pick this
> > > fix?
> > >
> > > Maintainer on CC.
> >
> > I am OK with this but could you use a regular patch instead of fetching from
> > github?
>
> +1 million
>
Sure, here's the same as a regular patch.
Index: mail/gmime30/Makefile
===
RCS file: /cvs/ports/mail/gmime30/Makefile,v
retrieving revision 1.23
diff -u -p -u -p -r1.23 Makefile
--- mail/gmime30/Makefile 5 Nov 2022 17:06:28 - 1.23
+++ mail/gmime30/Makefile 16 Aug 2023 05:53:40 -
@@ -4,7 +4,7 @@ GH_ACCOUNT= jstedfast
GH_PROJECT=gmime
GH_TAGNAME=3.2.13
PKGNAME= gmime30-${GH_TAGNAME}
-REVISION= 0
+REVISION= 1
SHARED_LIBS += gmime-3.02.2 # 213.0
Index: mail/gmime30/patches/patch-gmime_gmime-utils_c
===
RCS file: mail/gmime30/patches/patch-gmime_gmime-utils_c
diff -N mail/gmime30/patches/patch-gmime_gmime-utils_c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ mail/gmime30/patches/patch-gmime_gmime-utils_c 16 Aug 2023 05:53:40
-
@@ -0,0 +1,26 @@
+Fix rfc2047 token decoding logic for base64 encodings
+Bug report: https://github.com/djcb/mu/issues/2429
+
+Index: gmime/gmime-utils.c
+--- gmime/gmime-utils.c.orig
gmime/gmime-utils.c
+@@ -1789,10 +1789,16 @@ rfc2047_token_decode (rfc2047_token *token, unsigned c
+ const unsigned char *inbuf = (const unsigned char *) token->text;
+ size_t len = token->length;
+
+- if (token->encoding == 'B')
++ if (token->encoding == 'B') {
++ /* Note: A state of -1 means that a previous rfc2047
encoded-word token ended with an '=' (aka 'eof'),
++ * so we need to reset the state. */
++ if (*state == -1)
++ *state = 0;
++
+ return g_mime_encoding_base64_decode_step (inbuf, len, outbuf,
state, save);
+- else
+- return quoted_decode (inbuf, len, outbuf, state, save);
++ }
++
++ return quoted_decode (inbuf, len, outbuf, state, save);
+ }
+
+ static char *
Index: mail/gmime30/patches/patch-tests_test-mime_c
===
RCS file: /cvs/ports/mail/gmime30/patches/patch-tests_test-mime_c,v
retrieving revision 1.3
diff -u -p -u -p -r1.3 patch-tests_test-mime_c
--- mail/gmime30/patches/patch-tests_test-mime_c16 Apr 2022 07:34:04
- 1.3
+++ mail/gmime30/patches/patch-tests_test-mime_c16 Aug 2023 05:53:40
-
@@ -1,4 +1,4 @@
-64bit time_t
+64bit time_t + Test for rfc2047 token decoding logic for base64 encodings
Index: tests/test-mime.c
--- tests/test-mime.c.orig
@@ -12,3 +12,13 @@ Index: tests/test-mime.c
if (tz_offset != dates[i].tzone)
throw (exception_new ("timezones do not
match"));
+@@ -408,6 +408,9 @@ static struct {
+ "blah:\tI am broken",
+ "blah:\tI am broken" },
+ #endif
++ { "=?UTF-8?B?SGVsbG8=?= =?UTF-8?B?IHdvcmxk?=",
++"Hello world",
++"Hello world" },
+ { "=?iso-8859-1?Q?Copy_of_Rapport_fra_Norges_R=E5fisklag=2Edoc?=",
+ "Copy of Rapport fra Norges R\xc3\xa5" "fisklag.doc",
+ "Copy of Rapport fra Norges =?iso-8859-1?q?R=E5fisklag=2Edoc?=" },
[new] x11/windowmaker/paginator
This is a simple port of a desktop pager dockapp for WindowMaker and similar window managers. I was not sure whether I should send this port, since it is a program I wrote myself; but it may be useful for other people out there using WindowMaker, so here's a try. I understand if it were not accepted. Tested with x11/windowmaker and x11/fluxbox. Ok? paginator.tar.gz Description: application/tar-gz
devel/libmtp: update to 1.1.21
There are a bunch of commits, but I don't see any changelog. Can people test this with their (least) favourite phone and USB stack? It doesn't help with my problems, but doesn't make stuff worse, either. Index: Makefile === RCS file: /cvs/ports/devel/libmtp/Makefile,v retrieving revision 1.45 diff -u -p -r1.45 Makefile --- Makefile23 Feb 2023 13:27:23 - 1.45 +++ Makefile15 Aug 2023 18:38:16 - @@ -1,9 +1,9 @@ COMMENT= Media Transfer Protocol (MTP) implementation -DISTNAME= libmtp-1.1.19 +DISTNAME= libmtp-1.1.21 CATEGORIES=devel -SHARED_LIBS += mtp 7.1 # 13.0 +SHARED_LIBS += mtp 7.2 # 13.0.4 HOMEPAGE= http://libmtp.sourceforge.net/ Index: distinfo === RCS file: /cvs/ports/devel/libmtp/distinfo,v retrieving revision 1.20 diff -u -p -r1.20 distinfo --- distinfo23 Feb 2023 13:27:23 - 1.20 +++ distinfo15 Aug 2023 17:57:55 - @@ -1,2 +1,2 @@ -SHA256 (libmtp-1.1.19.tar.gz) = 3rSvb2P15xIVz6f7lheVJikgtOxstLYn9VswsYqjMig= -SIZE (libmtp-1.1.19.tar.gz) = 855810 +SHA256 (libmtp-1.1.21.tar.gz) = xP+lq4yPSMkbAEfy4lPBAcQY1WlqXtZcg5kipCgIcqc= +SIZE (libmtp-1.1.21.tar.gz) = 862703
Re: aerc/colorize: disable broken OSC 8
Hi,
On Tue Aug 15, 2023 at 5:40 PM CEST, Omar Polo wrote:
> Hello,
>
> aerc (via the libexec colorize) uses the OSC 8 sequence to mark up
> URLs for the terminal emulator. This seems to be currently broken,
> I'm investigating with upstream to understand if this is an aerc or
> tcell-term bug or something else. However, for the time being I'd
> propose to just disable the OSC 8 sequence outputting.
>
> It's broken on (at least)
>
> - xterm
> - urxvt
> - alacritty
> - gnome-terminal
>
> I never noticed before because i use cat(1) as filter for emails.
> volker@ noticed it.
I actually use colordiff in ports as my main filter for `text/plain`
mails so I guess that is why I haven't noticed anything either.
> thoughts/ok?
Tested the patch in various terminals and runs fine on amd64.
I'm fine with the diff.
Best Regards,
Thim Cederlund
>
> Index: Makefile
> ===
> RCS file: /home/cvs/ports/mail/aerc/Makefile,v
> retrieving revision 1.10
> diff -u -p -r1.10 Makefile
> --- Makefile 5 Jun 2023 09:10:52 - 1.10
> +++ Makefile 15 Aug 2023 15:21:41 -
> @@ -5,7 +5,7 @@ MODGO_VERSION = v0.0.0-20230511091235-f1
>
> V = 0.15.2
> DISTNAME = aerc-$V
> -REVISION = 0
> +REVISION = 1
>
> CATEGORIES = mail
>
> Index: patches/patch-filters_colorize_c
> ===
> RCS file: patches/patch-filters_colorize_c
> diff -N patches/patch-filters_colorize_c
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-filters_colorize_c 15 Aug 2023 15:30:38 -
> @@ -0,0 +1,27 @@
> +disable OSC 8; tcell-term has issues with it.
> +
> +Index: filters/colorize.c
> +--- filters/colorize.c.orig
> filters/colorize.c
> +@@ -415,6 +415,7 @@ static inline size_t print_notabs(const char *in, size
> + }
> +
> + static void print_osc8(const char *url, size_t len, size_t id, bool email) {
> ++#if 0
> + print("\x1b]8;");
> + if (url != NULL) {
> + printf("id=colorize-%lu;", id);
> +@@ -427,6 +428,13 @@ static void print_osc8(const char *url, size_t len, si
> + print(";");
> + }
> + print("\x1b\\");
> ++#else
> ++if (url != NULL) {
> ++if (email)
> ++print("mailto://";);
> ++print_notabs(url, len);
> ++}
> ++#endif
> + }
> +
> + static void diff_chunk(const char *in)
Re: aerc/colorize: disable broken OSC 8
On Tue, Aug 15, 2023 at 05:40:11PM +0200, Omar Polo wrote: > Hello, > > aerc (via the libexec colorize) uses the OSC 8 sequence to mark up > URLs for the terminal emulator. This seems to be currently broken, > I'm investigating with upstream to understand if this is an aerc or > tcell-term bug or something else. However, for the time being I'd > propose to just disable the OSC 8 sequence outputting. > > It's broken on (at least) > > - xterm > - urxvt xterm and urxvt ignore OSC 8. I'm surprised that no one responded to this https://www.mail-archive.com/rxvt-unicode@lists.schmorp.de/msg02181.html because Marc is more inclined to be polite about that feature than I. Anyway, I'd expect OpenBSD to disable it, because they took the time to think about the ways it will be abused :-) > - alacritty > - gnome-terminal these support the feature (but only in a desktop session) -- Thomas E. Dickey https://invisible-island.net
[Update] fonts/juliamono
A simple update to fonts/juliamono: tested working fine (though, as with any font update, it will tend to mess up running applications, which then need to be restarted). Laurie diff --git fonts/juliamono/Makefile fonts/juliamono/Makefile index 500dcc97953..ae484ee76db 100644 --- fonts/juliamono/Makefile +++ fonts/juliamono/Makefile @@ -1,6 +1,6 @@ COMMENT = typeface carefully crafted & designed for computer screens -V =0.048 +V =0.050 DISTNAME = JuliaMono PKGNAME = juliamono-$V diff --git fonts/juliamono/distinfo fonts/juliamono/distinfo index 43f857f43fc..4f6167524e4 100644 --- fonts/juliamono/distinfo +++ fonts/juliamono/distinfo @@ -1,2 +1,2 @@ -SHA256 (JuliaMono-0.048.tar.gz) = J804RqJjpvSx00G0PRjN9wYIvQnsAXWUsZaJGWXdJ1M= -SIZE (JuliaMono-0.048.tar.gz) = 31773698 +SHA256 (JuliaMono-0.050.tar.gz) = 5EZQVkVBAeSjWFgWtOGG1wmXAUAf2qX71Wf6/SUk6qM= +SIZE (JuliaMono-0.050.tar.gz) = 32756039
Re: aerc/colorize: disable broken OSC 8
On 2023/08/15 20:09:13 +0200, Volker Schlecht wrote: > As discussed off-list with op@, the proposed patch still leads to URLs > (or email addresses) being duplicated, i.e. > > t...@example.com > > turns into > > mailto://test@example.comt...@example.com > > I'm attaching two proposals > > aerc-leave-mailto.diff: > > Essentially op@'s diff with a tweak that fixes the URL duplication > > aerc-nuke-osc8.diff > > Turns print_osc8 into a no-op, and also removes the insertion of > mailto:// into perfectly fine email addresses. > > My personal preferred solution is aerc-nuke-osc8.diff, because ... > WTF :-) But it does noticeably alter the default behavior of aerc. I prefer it too. The fact that I kept mailto:// in my original diff was due to a misunderstanding in how the function is supposed to work ^^" > NB: op@ pointed out the following mailing list discussion as a reference: > > https://lists.sr.ht/~rjarry/aerc-devel/%3C20230318192505.137426-1-contact%40kchibisov.com%3E#%3C3PNHXOUZBEXRM.2LN4162DTJ5 part of the issue is our less(1) mangling the OSC 8 escape codes, but this issues is present in aerc' :term too which doesn't use less(1) AFAIK. Will continue to investigate in this, but for the time being I think it's better to disable these fancy escape codes :-) so, ok op@ for the "nuke" diff. thanks!
Re: aerc/colorize: disable broken OSC 8
As discussed off-list with op@, the proposed patch still leads to URLs
(or email addresses) being duplicated, i.e.
t...@example.com
turns into
mailto://test@example.comt...@example.com
I'm attaching two proposals
aerc-leave-mailto.diff:
Essentially op@'s diff with a tweak that fixes the URL duplication
aerc-nuke-osc8.diff
Turns print_osc8 into a no-op, and also removes the insertion of
mailto:// into perfectly fine email addresses.
My personal preferred solution is aerc-nuke-osc8.diff, because ...
WTF :-) But it does noticeably alter the default behavior of aerc.
NB: op@ pointed out the following mailing list discussion as a reference:
https://lists.sr.ht/~rjarry/aerc-devel/%3C20230318192505.137426-1-contact%40kchibisov.com%3E#%3C3PNHXOUZBEXRM.2LN4162DTJ5Index: Makefile
===
RCS file: /cvs/ports/mail/aerc/Makefile,v
retrieving revision 1.10
diff -u -p -r1.10 Makefile
--- Makefile 5 Jun 2023 09:10:52 - 1.10
+++ Makefile 15 Aug 2023 16:27:09 -
@@ -5,7 +5,7 @@ MODGO_VERSION = v0.0.0-20230511091235-f1
V = 0.15.2
DISTNAME = aerc-$V
-REVISION = 0
+REVISION = 1
CATEGORIES = mail
Index: patches/patch-filters_colorize_c
===
RCS file: patches/patch-filters_colorize_c
diff -N patches/patch-filters_colorize_c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-filters_colorize_c 15 Aug 2023 16:27:09 -
@@ -0,0 +1,26 @@
+disable OSC 8; tcell-term has issues with it.
+
+Index: filters/colorize.c
+--- filters/colorize.c.orig
filters/colorize.c
+@@ -415,6 +415,7 @@ static inline size_t print_notabs(const char *in, size
+ }
+
+ static void print_osc8(const char *url, size_t len, size_t id, bool email) {
++#if 0
+ print("\x1b]8;");
+ if (url != NULL) {
+ printf("id=colorize-%lu;", id);
+@@ -427,6 +428,12 @@ static void print_osc8(const char *url, size_t len, si
+ print(";");
+ }
+ print("\x1b\\");
++#else
++ if (url != NULL) {
++ if (email)
++ print("mailto://");
++ }
++#endif
+ }
+
+ static void diff_chunk(const char *in)
Index: Makefile
===
RCS file: /cvs/ports/mail/aerc/Makefile,v
retrieving revision 1.10
diff -u -p -r1.10 Makefile
--- Makefile 5 Jun 2023 09:10:52 - 1.10
+++ Makefile 15 Aug 2023 17:55:53 -
@@ -5,7 +5,7 @@ MODGO_VERSION = v0.0.0-20230511091235-f1
V = 0.15.2
DISTNAME = aerc-$V
-REVISION = 0
+REVISION = 1
CATEGORIES = mail
Index: patches/patch-filters_colorize_c
===
RCS file: patches/patch-filters_colorize_c
diff -N patches/patch-filters_colorize_c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-filters_colorize_c 15 Aug 2023 17:55:53 -
@@ -0,0 +1,21 @@
+disable OSC 8; tcell-term has issues with it.
+
+Index: filters/colorize.c
+--- filters/colorize.c.orig
filters/colorize.c
+@@ -415,6 +415,7 @@ static inline size_t print_notabs(const char *in, size
+ }
+
+ static void print_osc8(const char *url, size_t len, size_t id, bool email) {
++#if 0
+ print("\x1b]8;");
+ if (url != NULL) {
+ printf("id=colorize-%lu;", id);
+@@ -427,6 +428,7 @@ static void print_osc8(const char *url, size_t len, si
+ print(";");
+ }
+ print("\x1b\\");
++#endif
+ }
+
+ static void diff_chunk(const char *in)
Re: Fix sysutils/ugrep ug+/ugrep+ scripts
On 8/15/2023 11:54 AM, Volker Schlecht wrote: > > The port currently installs two shell scripts named ug+ and ugrep+ that > refer to /bin/bash. > > I was thinking about proposing a dependency on bash, but we'd still need > to patch the two scripts that look to me like perfectly fine Posix sh, > so I propose to patch them to use /bin/sh > > Thoughts? OK? > > cheers, > Volker Sure, but can you try pushing this upstream as well? Thanks. ~Brian
Fix sysutils/ugrep ug+/ugrep+ scripts
The port currently installs two shell scripts named ug+ and ugrep+ that
refer to /bin/bash.
I was thinking about proposing a dependency on bash, but we'd still need
to patch the two scripts that look to me like perfectly fine Posix sh,
so I propose to patch them to use /bin/sh
Thoughts? OK?
cheers,
VolkerIndex: Makefile
===
RCS file: /cvs/ports/sysutils/ugrep/Makefile,v
retrieving revision 1.43
diff -u -p -r1.43 Makefile
--- Makefile 14 Aug 2023 21:21:46 - 1.43
+++ Makefile 15 Aug 2023 15:48:57 -
@@ -5,6 +5,8 @@ GH_ACCOUNT = Genivia
GH_PROJECT = ugrep
GH_TAGNAME = v3.12.7
+REVISION = 0
+
MAINTAINER = Brian Callahan
# BSD
Index: patches/patch-bin_ug+
===
RCS file: patches/patch-bin_ug+
diff -N patches/patch-bin_ug+
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-bin_ug+ 15 Aug 2023 15:48:57 -
@@ -0,0 +1,9 @@
+Index: bin/ug+
+--- bin/ug+.orig
bin/ug+
+@@ -1,4 +1,4 @@
+-#!/bin/bash
++#!/bin/sh
+ filters=
+ if [ -x "$(command -v pdftotext)" ] && pdftotext --help 2>&1 | ugrep -qw Poppler ; then
+ filters="${filters}${filters:+,}pdf:pdftotext % -"
Index: patches/patch-bin_ugrep+
===
RCS file: patches/patch-bin_ugrep+
diff -N patches/patch-bin_ugrep+
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-bin_ugrep+ 15 Aug 2023 15:48:57 -
@@ -0,0 +1,9 @@
+Index: bin/ugrep+
+--- bin/ugrep+.orig
bin/ugrep+
+@@ -1,4 +1,4 @@
+-#!/bin/bash
++#!/bin/sh
+ filters=
+ if [ -x "$(command -v pdftotext)" ] && pdftotext --help 2>&1 | ugrep -qw Poppler ; then
+ filters="${filters}${filters:+,}pdf:pdftotext % -"
aerc/colorize: disable broken OSC 8
Hello,
aerc (via the libexec colorize) uses the OSC 8 sequence to mark up
URLs for the terminal emulator. This seems to be currently broken,
I'm investigating with upstream to understand if this is an aerc or
tcell-term bug or something else. However, for the time being I'd
propose to just disable the OSC 8 sequence outputting.
It's broken on (at least)
- xterm
- urxvt
- alacritty
- gnome-terminal
I never noticed before because i use cat(1) as filter for emails.
volker@ noticed it.
thoughts/ok?
Index: Makefile
===
RCS file: /home/cvs/ports/mail/aerc/Makefile,v
retrieving revision 1.10
diff -u -p -r1.10 Makefile
--- Makefile5 Jun 2023 09:10:52 - 1.10
+++ Makefile15 Aug 2023 15:21:41 -
@@ -5,7 +5,7 @@ MODGO_VERSION = v0.0.0-20230511091235-f1
V =0.15.2
DISTNAME = aerc-$V
-REVISION = 0
+REVISION = 1
CATEGORIES = mail
Index: patches/patch-filters_colorize_c
===
RCS file: patches/patch-filters_colorize_c
diff -N patches/patch-filters_colorize_c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-filters_colorize_c15 Aug 2023 15:30:38 -
@@ -0,0 +1,27 @@
+disable OSC 8; tcell-term has issues with it.
+
+Index: filters/colorize.c
+--- filters/colorize.c.orig
filters/colorize.c
+@@ -415,6 +415,7 @@ static inline size_t print_notabs(const char *in, size
+ }
+
+ static void print_osc8(const char *url, size_t len, size_t id, bool email) {
++#if 0
+ print("\x1b]8;");
+ if (url != NULL) {
+ printf("id=colorize-%lu;", id);
+@@ -427,6 +428,13 @@ static void print_osc8(const char *url, size_t len, si
+ print(";");
+ }
+ print("\x1b\\");
++#else
++ if (url != NULL) {
++ if (email)
++ print("mailto://";);
++ print_notabs(url, len);
++ }
++#endif
+ }
+
+ static void diff_chunk(const char *in)
Re: NEW: wayland/foot
On Tue, Aug 15, 2023 at 02:01:54PM +0100, Stuart Henderson wrote:
> If it's installing to ${SYSCONFDIR}/xdg/foot then it also needs
> to @sample ${SYSCONFDIR}/xdg/, however I don't think it actually
> reads config from /etc/xdg/ (unless XDG env vars are set, it
> just looks in ~/.config) so I think it's a bit confusing to
> install the sample file there, I'd just include the copy in
> share/examples.
>
I did check that it does read /etc/xdg/foot/foot.ini if
~/.config/foot/foot.ini doesn't exist (and not XDG_ env vars are set).
> Missing dep on wayland-protocols
>
> I can't test further without uchar.h :)
>
> I'd trim DESCR down a bit and get rid of the markdown formatting,
> e.g.
Thanks.
>
> --
> Foot, the fast, lightweight and minimalistic Wayland terminal emulator.
>
> * DE agnostic
> * Server/daemon mode
> * User configurable font fallback
> * On-the-fly font resize
> * On-the-fly DPI font size adjustment
> * Scrollback search
> * Keyboard driven URL detection
> * Color emoji support
> * IME (via 'text-input-v3')
> * Multi-seat
> * True Color (24bpp)
> * Synchronized Updates support
> * Sixel image support
>
> Configuration is done in ~/.config/foot/foot.ini (a template can be
> found in ${PREFIX}/share/examples/foot).
> -
>
>
> On 2023/08/14 18:43, Matthieu Herrb wrote:
> > foot is a Wayland terminal emulator with more features than havoc.
> > Among others, It's the default terminal in the default sway config.
> >
> > It depends on the 3 ports I sent earlier, plus an implementation of
> > the and char32_t implementation in libc. schwarze@ has
> > kindly provided a diff for this and he will send it out for reviews
> > shortly.
> >
> > ok (once OpenBSD has uchar.h ?) comments ?
> >
> > --
> > Matthieu Herrb
>
>
--
Matthieu Herrb
Re: lang/ocaml and IBT WAS: amd64: IBT bulk build breakage
On 11 Aug 2023, at 12:51, Stuart Henderson wrote: > > yes, for amd64 it's intel Tiger Lake (11th gen) and newer, models of the > format iX-11XXX, iX-12XXX, iX-13XXX. no AMD CPUs. On ark.intel.com, look > for "Control-Flow Enforcement Technology" (the intel term which covers > both shadow stacks and indirect branch tracking). > > for arm64 currently only on Apple M2. Thanks for all the pointers! Every machine for 100 miles around me seems to be an AMD these days, so I've ordered myself a Raptor Lake NUC to be my new OpenBSD desktop. As soon as that arrives I'll take a look at the native code compiler output (unless someone else beats me to it). In the meanwhile I think we should go for updating the OCaml ports to 5.1.0 so that a patch against trunk will be manageable... The only roadbump is from Daniel Dickman, who wrote: > Fine with me so long as compcert continues to work on i386. I think the > only impact is potentially running slower? That’s fine with me. > > That being said I think there were some challenges with newer coq on > i386. So maybe the end is close for compcert on that platform? Indeed, I think it's time to move to a 64-bit license after so many years. I strongly suspect you're the only user of OpenBSD/i386 compcert these days, so it's worth just asking for an upgrade of the license to shift to 64-bit. OCaml 5 will definitely be bytecode-only for 32-bit architectures for the foreseeable future. This in turn pushes up memory requirements (due to the extra boxing of values), which makes it more likely that Compcert/Coq will hit the 4GB process limit. Anil
Re: lang/ocaml and IBT WAS: amd64: IBT bulk build breakage
On 8 Aug 2023, at 20:49, Volker Schlecht wrote: > > Cc: Maintainer > > On 7/31/23 14:28, Christian Weisgerber wrote: >> I managed to run a full bulk build on my T14 G3 with IBT. Kudos >> to Lenovo for engineering a laptop that can build for days on end >> without melting down. >> The following ports fail to build: >> devel/ocaml-menhir # OCaml >> sysutils/opam # OCaml >> x11/lablgtk3# OCaml >> I included an uncommitted USE_NOBTICF fix for sysutils/findlib, but >> there seems to remain another problem with some OCaml ports. > > With the attached patch, I get a lang/ocaml that builds ocaml-menhir and > lablgtk3 successfully on my IBT enabled amd64 machine. I’m just catching up; is a recent amd64 snapshot enough to get an IBT-enabled system? I’m testing out OCaml 5.1~rc1, and the testsuite fully passes. Might be easier to just upgrade to that instead. It would mean turning i386 and arm32 into bytecode-only architectures, but that’s got to happen at some stage. Anil
Re: NEW: wayland/foot
If it's installing to ${SYSCONFDIR}/xdg/foot then it also needs
to @sample ${SYSCONFDIR}/xdg/, however I don't think it actually
reads config from /etc/xdg/ (unless XDG env vars are set, it
just looks in ~/.config) so I think it's a bit confusing to
install the sample file there, I'd just include the copy in
share/examples.
Missing dep on wayland-protocols
I can't test further without uchar.h :)
I'd trim DESCR down a bit and get rid of the markdown formatting, e.g.
--
Foot, the fast, lightweight and minimalistic Wayland terminal emulator.
* DE agnostic
* Server/daemon mode
* User configurable font fallback
* On-the-fly font resize
* On-the-fly DPI font size adjustment
* Scrollback search
* Keyboard driven URL detection
* Color emoji support
* IME (via 'text-input-v3')
* Multi-seat
* True Color (24bpp)
* Synchronized Updates support
* Sixel image support
Configuration is done in ~/.config/foot/foot.ini (a template can be
found in ${PREFIX}/share/examples/foot).
-
On 2023/08/14 18:43, Matthieu Herrb wrote:
> foot is a Wayland terminal emulator with more features than havoc.
> Among others, It's the default terminal in the default sway config.
>
> It depends on the 3 ports I sent earlier, plus an implementation of
> the and char32_t implementation in libc. schwarze@ has
> kindly provided a diff for this and he will send it out for reviews
> shortly.
>
> ok (once OpenBSD has uchar.h ?) comments ?
>
> --
> Matthieu Herrb
Re: NEW: devel/libstdthreads
On 2023/08/15 13:33, Stuart Henderson wrote: > On 2023/08/14 18:36, Matthieu Herrb wrote: > > Hi, > > > > This is another port needed by upcoming Wayland applications, but it > > could also be put in base. > > libstdthreads is a straightforward port of the FreeBSD code to > > implement the C11 standard threads library. > > Needs NO_TEST, and pre-install is not needed (mtree is already run to > populate the install tree before fake-install, so this dir already > exists). oh, and WANTLIB = pthread > > In FreeBSD it is provided as a separate library (libstdthreds) whereas > > in NetBSD it's integrated in libpthread. > > > > What do you think ? > > OK with the above tweaks. > > No real opinion on adding as a separate library vs in libpthread, > but adding as a port doesn't preclude moving to libpthread later if > wanted. >
Re: NEW: devel/libstdthreads
On 2023/08/14 18:36, Matthieu Herrb wrote: > Hi, > > This is another port needed by upcoming Wayland applications, but it > could also be put in base. > libstdthreads is a straightforward port of the FreeBSD code to > implement the C11 standard threads library. Needs NO_TEST, and pre-install is not needed (mtree is already run to populate the install tree before fake-install, so this dir already exists). > In FreeBSD it is provided as a separate library (libstdthreds) whereas > in NetBSD it's integrated in libpthread. > > What do you think ? OK with the above tweaks. No real opinion on adding as a separate library vs in libpthread, but adding as a port doesn't preclude moving to libpthread later if wanted.
Re: [NEW] www/azorius
On 2023/08/14 18:13:27 +0200, gonzalo wrote:
>
>
> On 8/10/23 01:05, Horia Racoviceanu wrote:
> > Hi,
> >
> > This is a port for Azorius, a social link aggregator and comment
> > forum. It federates with other instances via ActivityPub.
> >
> > Homepage: https://humungus.tedunangst.com/r/azorius
> > Introduction: https://flak.tedunangst.com/post/azorius-01
> > Flagships instance: https://azorius.net
> >
> > We're looking for comments and testing please.
> ping, any OK to put this in? :)
haven't tested, but looks fine to me. ok op@ to import.
nitpick: in the README it should use TRUEPREFIX rather than LOCALBASE:
-Please see ${LOCALBASE}/share/doc/azorius
+Please see ${TRUEPREFIX}/share/doc/azorius
Re: [Update] devel/github-backup
On 2023/08/15 09:44:59 +0100, Laurence Tratt wrote:
> On Sat, Jul 29, 2023 at 08:00:55AM +0100, Laurence Tratt wrote:
>
> Looking for OKs for this update.
committed, thanks!
> Laurie
>
> > This updates devel/github-backup (by several versions) to the latest
> > version.
> > Tested in several situations where I use GitHub backups.
> >
> >
> > Laurie
> >
> >
> > diff --git devel/github-backup/Makefile devel/github-backup/Makefile
> > index 94c06944a39..3fd54ae871c 100644
> > --- devel/github-backup/Makefile
> > +++ devel/github-backup/Makefile
> > @@ -1,8 +1,7 @@
> > COMMENT = backup a github user or organization
> >
> > -MODPY_EGG_VERSION =0.33.0
> > +MODPY_EGG_VERSION =0.43.1
> > PKGNAME = github-backup-${MODPY_EGG_VERSION}
> > -REVISION = 2
> >
> > GH_ACCOUNT = josegonzalez
> > GH_PROJECT = python-github-backup
> > diff --git devel/github-backup/distinfo devel/github-backup/distinfo
> > index f7ad1766a08..cc27230affa 100644
> > --- devel/github-backup/distinfo
> > +++ devel/github-backup/distinfo
> > @@ -1,2 +1,2 @@
> > -SHA256 (python-github-backup-0.33.0.tar.gz) =
> > cHsqn5Hyy+WQJxCYabZWgEUAraihSH5j0lkIK6rRxjY=
> > -SIZE (python-github-backup-0.33.0.tar.gz) = 21775
> > +SHA256 (python-github-backup-0.43.1.tar.gz) =
> > nbAzjAbxbMXWyCqawpkyvS8SMKQleSa69+DsbSSNXow=
> > +SIZE (python-github-backup-0.43.1.tar.gz) = 26723
> >
Re: [Update] print/ps2eps
On Mon, Jul 31, 2023 at 03:02:05PM +0100, Laurence Tratt wrote: Looking for OKs for this update too (which also fixes the download site -- the old one no longer works). Laurie > The patch below updates print/ps2eps to the latest version. This has > moved homepage since the last update. I also no longer use this, so am > dropping maintainership, though I did find a couple of old files to test > on to make sure the new version works OK! > > > Laurie > > > diff --git print/ps2eps/Makefile print/ps2eps/Makefile > index 5d4a2b47710..c61b7345c26 100644 > --- print/ps2eps/Makefile > +++ print/ps2eps/Makefile > @@ -1,17 +1,14 @@ > COMMENT= convert Postscript to Encapsulated Postscript > > -DISTNAME=ps2eps-1.68 > +DISTNAME=ps2eps-1.70 > CATEGORIES= print > -REVISION = 0 > > -HOMEPAGE=http://www.tm.uka.de/~bless/ps2eps.html > - > -MAINTAINER= Laurence Tratt > +HOMEPAGE= > https://telematics.tm.kit.edu/english/staff_bless.php?tab=%5B1512%5D > > # GPL > PERMIT_PACKAGE= Yes > > -MASTER_SITES=http://www.tm.uka.de/~bless/ > +MASTER_SITES=https://tm.kit.edu/~bless/ > > RUN_DEPENDS= print/ghostscript/gnu > > diff --git print/ps2eps/distinfo print/ps2eps/distinfo > index e589adfbaad..bb717500604 100644 > --- print/ps2eps/distinfo > +++ print/ps2eps/distinfo > @@ -1,2 +1,2 @@ > -SHA256 (ps2eps-1.68.tar.gz) = sI8S7tiJZdGJEmH7cOh8fjo/MXLrwxvbeZSnzoVN2SU= > -SIZE (ps2eps-1.68.tar.gz) = 97304 > +SHA256 (ps2eps-1.70.tar.gz) = OmaBwxd6+a4yZFnFfoT+kIKdUp0kf8Mq5/ZuiDnoGxE= > +SIZE (ps2eps-1.70.tar.gz) = 135657 >
Re: [Update] devel/github-backup
On Sat, Jul 29, 2023 at 08:00:55AM +0100, Laurence Tratt wrote:
Looking for OKs for this update.
Laurie
> This updates devel/github-backup (by several versions) to the latest version.
> Tested in several situations where I use GitHub backups.
>
>
> Laurie
>
>
> diff --git devel/github-backup/Makefile devel/github-backup/Makefile
> index 94c06944a39..3fd54ae871c 100644
> --- devel/github-backup/Makefile
> +++ devel/github-backup/Makefile
> @@ -1,8 +1,7 @@
> COMMENT = backup a github user or organization
>
> -MODPY_EGG_VERSION = 0.33.0
> +MODPY_EGG_VERSION = 0.43.1
> PKGNAME =github-backup-${MODPY_EGG_VERSION}
> -REVISION = 2
>
> GH_ACCOUNT = josegonzalez
> GH_PROJECT = python-github-backup
> diff --git devel/github-backup/distinfo devel/github-backup/distinfo
> index f7ad1766a08..cc27230affa 100644
> --- devel/github-backup/distinfo
> +++ devel/github-backup/distinfo
> @@ -1,2 +1,2 @@
> -SHA256 (python-github-backup-0.33.0.tar.gz) =
> cHsqn5Hyy+WQJxCYabZWgEUAraihSH5j0lkIK6rRxjY=
> -SIZE (python-github-backup-0.33.0.tar.gz) = 21775
> +SHA256 (python-github-backup-0.43.1.tar.gz) =
> nbAzjAbxbMXWyCqawpkyvS8SMKQleSa69+DsbSSNXow=
> +SIZE (python-github-backup-0.43.1.tar.gz) = 26723
>
Re: NEW: devel/tllist
On Tue, Aug 15, 2023 at 12:10:09AM +0100, Stuart Henderson wrote:
> On 2023/08/14 18:33, Matthieu Herrb wrote:
> > Hi,
> >
> > This is the first of a set of new ports for Wayland applications.
> >
> > tllist is a simple typed linked list header file only library.
> >
> > ok? comments?
> >
> > --
> > Matthieu Herrb
>
> SIZE (1.1.0.tar.gz) = 7639
>
> this filename is a slight problem, it can be handled with a slightly
> fiddly DISTFILES {url} syntax, might be this but I have been to the pub
> and not tested so could be wrong ;)
>
> DISTFILES = tllist-{}${V}${EXTRACT_SUFX}
>
Thanks. This works. I've fixed all my codeberg hosted ports. like
that.
--
Matthieu Herrb
