Re: [new] mail/aerc - terminal email client
"James Cook" wrote: > On Mon May 2, 2022 at 12:25 AM UTC, James Cook wrote: > > > It's based on a previous submission by Raymond (+cc). I've enabled the > > > notmuch support (but not really tried it yet) and updated it, plus some > > > other minor tweaks. > > > > It is working for me with notmuch. I'm sending this with your aerc port. > > This is my first time using aerc. Thanks for porting it! > > > > -- > > James > > There is a quirk which I forgot to mention: when I do a notmuch search > using :cf, the new "folder" is added to the left with the number of > results, but the right pane says "(no messages)". If I :cf with the same > search a second time, the messages appear. > > It seems the messages appear as long as I've :cf'd with that specific > search before in the same session; it still works if I do intermediate > searches. Maybe some kind of cacheing is involved? very much likely. have you tried reporting it upstream? :) P.S.: the wizard bug was fixed today \o/
Re: [new] mail/aerc - terminal email client
On Mon May 2, 2022 at 12:25 AM UTC, James Cook wrote: > > It's based on a previous submission by Raymond (+cc). I've enabled the > > notmuch support (but not really tried it yet) and updated it, plus some > > other minor tweaks. > > It is working for me with notmuch. I'm sending this with your aerc port. > This is my first time using aerc. Thanks for porting it! > > -- > James There is a quirk which I forgot to mention: when I do a notmuch search using :cf, the new "folder" is added to the left with the number of results, but the right pane says "(no messages)". If I :cf with the same search a second time, the messages appear. It seems the messages appear as long as I've :cf'd with that specific search before in the same session; it still works if I do intermediate searches. Maybe some kind of cacheing is involved? -- James
Re: [new] mail/aerc - terminal email client
Omar Polo wrote: > "James Cook" wrote: > > > It's based on a previous submission by Raymond (+cc). I've enabled the > > > notmuch support (but not really tried it yet) and updated it, plus some > > > other minor tweaks. > > > > It is working for me with notmuch. I'm sending this with your aerc port. > > This is my first time using aerc. Thanks for porting it! > > thanks for testing! I'm using aerc in a box where I don't want to sync > locally the mail (otherwise I'd be using mu+mblaze there too probably), > so I didn't have an (easy) mean to test notmuch. > > I've also find out why `make clean' failed: I'm not propagating > MODGO_FLAGS to the upstream makefile. With that fixed, cleaning works > fine. this broke with go.port.mk, but it's now fixed; make sure to update the port tree before trying the tarball. Stuart hit the crash in the setup too, I've reported it upstream and added a README for time being. aerc.tar.gz Description: GNU Zip compressed data
Re: [new] mail/aerc - terminal email client
"James Cook" wrote: > > It's based on a previous submission by Raymond (+cc). I've enabled the > > notmuch support (but not really tried it yet) and updated it, plus some > > other minor tweaks. > > It is working for me with notmuch. I'm sending this with your aerc port. > This is my first time using aerc. Thanks for porting it! thanks for testing! I'm using aerc in a box where I don't want to sync locally the mail (otherwise I'd be using mu+mblaze there too probably), so I didn't have an (easy) mean to test notmuch. I've also find out why `make clean' failed: I'm not propagating MODGO_FLAGS to the upstream makefile. With that fixed, cleaning works fine. aerc.tar.gz Description: GNU Zip compressed data
Re: [new] mail/aerc - terminal email client
> It's based on a previous submission by Raymond (+cc). I've enabled the > notmuch support (but not really tried it yet) and updated it, plus some > other minor tweaks. It is working for me with notmuch. I'm sending this with your aerc port. This is my first time using aerc. Thanks for porting it! -- James
[new] mail/aerc - terminal email client
Hello ports, Please find attached a tarball for aerc, a terminal email client: % pkg_info aerc Information for inst:aerc-0.9.0 Comment: terminal email client Description: Aerc is a terminal email client with IMAP and Maildir support. Features include asynchronous IMAP and IMAP IDLE support, a tabbed multitasking interface, built-in terminal multiplexer, and customizable rendering filters for message parts. Maintainer: Omar Polo WWW: https://aerc-mail.org It's based on a previous submission by Raymond (+cc). I've enabled the notmuch support (but not really tried it yet) and updated it, plus some other minor tweaks. The previous issue with MODGO_VERSION still applies, so we can't use 0.9.0 as MODGO_VERSION but rather the 0.0.0-timestamp stuff. There's an issue with `make clean' which is unable to clean go stuff after building due to permission errors. There's also a bug in the program itself: if you happen to have a long password and are using a small xterm window, the initial setup wizard may crash due to "drawing outside of the context", so make sure to have an xterm wide enough :) Raymond: are you still interested in aerc? I'd be happy to leave the maintainership to you, or to co-maintain it if you prefer. aerc.tar.gz Description: application/gzip
Re: [NEW] mail/aerc 0.4.0
On Fri Jul 31, 2020 at 7:28 AM EDT, Raymond E. Pasco wrote: > This diff should fix WRKDIST and enable go ports to be patched again. And, dependent on that diff, the attached port replaces go-libvterm with a properly dynamic-linking go-libvterm, and depends on devel/libvterm from ports. aerc-0.4.0.tar.gz Description: GNU Zip compressed data
Re: [NEW] mail/aerc 0.4.0
This diff should fix WRKDIST and enable go ports to be patched again.
diff --git a/lang/go/go.port.mk b/lang/go/go.port.mk
index 0d254934f32..32a367a29bb 100644
--- a/lang/go/go.port.mk
+++ b/lang/go/go.port.mk
@@ -107,6 +107,7 @@ MODGO_SETUP_WORKSPACE = mkdir -p ${WRKSRC:H}; mv
${MODGO_SUBDIR} ${WRKSRC};
WRKSRC ?= ${WRKDIR}/${MODGO_MODNAME}@${MODGO_VERSION}
MODGO_SETUP_WORKSPACE =ln -sf ${WRKSRC} ${WRKDIR}/${MODGO_MODNAME}
.endif
+WRKDIST = ${WRKSRC}
INSTALL_STRIP =
.if ${MODGO_TYPE:L:Mbin}
--
2.27.0
Re: [NEW] mail/aerc 0.4.0
On Thu Jul 30, 2020 at 12:35 AM EDT, Raymond E. Pasco wrote: > - The previous time around, with a vendor directory, I was able to patch > the go-libvterm module to link against devel/libvterm instead of > bringing along its own libvterm. I am no longer quite sure how to do > this with the newer Go ports tools because patches apply to WRKDIST, > which doesn't resolve to a directory that actually exists at any point > during the build; if I come up with a fix I'll email it here. Oh, and the way the build works, it doesn't actually "download" the modules from /usr/ports/distfiles until after patch anyway. If we had patching capability on the main distribution, maybe we could patch its go.mod to use an alternate module that properly uses cgo pkg-config. This ecosystem is a real headache. :)
[NEW] mail/aerc 0.4.0
With the arrival of the new Go ports tools, I wanted to try mail/aerc again. Here's my attempt. Notes: - Because upstream uses git tags like 0.4.0 instead of v0.4.0, proxy.golang.org relegates him to v0.0.0-longsuffix hell instead of letting him use real versions. I have no opinion on this important bikeshed, but the MODGO_VERSION you see here is in fact 0.4.0. - portgen go based its module list on go.mod from the only version it was able to fetch, the latest commit, but I changed the modules back to what they were in 0.4.0. - The previous time around, with a vendor directory, I was able to patch the go-libvterm module to link against devel/libvterm instead of bringing along its own libvterm. I am no longer quite sure how to do this with the newer Go ports tools because patches apply to WRKDIST, which doesn't resolve to a directory that actually exists at any point during the build; if I come up with a fix I'll email it here. aerc-0.4.0.tar.gz Description: GNU Zip compressed data
Re: [NEW] mail/aerc
On Mon Mar 30, 2020 at 3:48 PM, Omar Polo wrote: > There's only one thing that I would like to report, as I think it's > an error. In the default config, in the filters section, there are > some paths that I don't expect: > > > subject,~^\[PATCH=awk -f > /usr/ports/pobj/aerc-0.3.0/fake-amd64/usr/local/share/aerc/filters/hldiff > #text/html=/usr/ports/pobj/aerc-0.3.0/fake-amd64/usr/local/share/aerc/filters/html > text/*=awk -f > /usr/ports/pobj/aerc-0.3.0/fake-amd64/usr/local/share/aerc/filters/plaintext Thanks for the report. My config generated the correct paths, but I'll try to reproduce and fix this on my end.
Re: [NEW] mail/aerc
On Sat, Feb 01, 2020 at 03:29:25AM -0500, Raymond E. Pasco wrote: > - I used a modified distfile provided by abieber with a vendor directory, > which is necessary due to the large number of go package dependencies. > > - The custom version of go-libvterm used by aerc upstream includes an > (unmodified) bundled copy of libvterm itself, which causes issues with > the build. I instead link against devel/libvterm. > > - One filter script shipped with aerc (to display HTML email) depends on > socksify (provided by security/dante) and www/w3m. I did not include these > as RUN_DEPENDS because this is an optional script disabled by default, > but I'm not sure whether this approach is correct. > > - cgo in go 1.13 (but not go 1.14) considers ~ an invalid path character, > but the top-level package name here (and therefore WRKSRC) contains an ~. > I remedied this by moving the vendor directory contents up to the level > of the MODGO_WORKSPACE. This workaround shouldn't be necessary when go > 1.14 is released. > > - aerc can be built with notmuch support, but notmuch isn't in ports (yet?), > so I didn't bother with this. Thank you for porting this! I'm trying it and so far it seems to work. There's only one thing that I would like to report, as I think it's an error. In the default config, in the filters section, there are some paths that I don't expect: subject,~^\[PATCH=awk -f /usr/ports/pobj/aerc-0.3.0/fake-amd64/usr/local/share/aerc/filters/hldiff #text/html=/usr/ports/pobj/aerc-0.3.0/fake-amd64/usr/local/share/aerc/filters/html text/*=awk -f /usr/ports/pobj/aerc-0.3.0/fake-amd64/usr/local/share/aerc/filters/plaintext In the port makefile there is a rule to generate aerc.conf that use sed to replace @SHAREDDIR@ to $SHAREDDIR. I tried to add SHAREDDIR=/usr/local/share/aerc to MAKE_FLAGS but it didn't work. (this on a updated -current on amd64) -- /Omar Polo
Re: [NEW] mail/aerc
On Mon, Feb 10, 2020 at 09:10:15AM -0700, Aaron Bieber wrote:
> On Sat, 01 Feb 2020 at 03:29:25 -0500, Raymond E. Pasco wrote:
> > - I used a modified distfile provided by abieber with a vendor directory,
> > which is necessary due to the large number of go package dependencies.
> >
> > - The custom version of go-libvterm used by aerc upstream includes an
> > (unmodified) bundled copy of libvterm itself, which causes issues with
> > the build. I instead link against devel/libvterm.
> >
> > - One filter script shipped with aerc (to display HTML email) depends on
> > socksify (provided by security/dante) and www/w3m. I did not include these
> > as RUN_DEPENDS because this is an optional script disabled by default,
> > but I'm not sure whether this approach is correct.
> >
> > - cgo in go 1.13 (but not go 1.14) considers ~ an invalid path character,
> > but the top-level package name here (and therefore WRKSRC) contains an ~.
> > I remedied this by moving the vendor directory contents up to the level
> > of the MODGO_WORKSPACE. This workaround shouldn't be necessary when go
> > 1.14 is released.
> >
> > - aerc can be built with notmuch support, but notmuch isn't in ports (yet?),
> > so I didn't bother with this.
>
> It looks good to me. I'd like to pass in MODGO_FLAGS so we can have verbose
> info when DEBUG is set. Something like:
> MAKE_ENV += GOFLAGS="${MODGO_FLAGS}"
>
> But it seems the "-p ${MAKE_JOBS}" bit from go.port.mk isn't getting parsed
> properly in this case.
>
> Anyway, if that bit can be sorted out, OK abieber@ for import!
ok jung@ as well (convinced by sthen's args earlier in this thread)
Re: [NEW] mail/aerc
Whoops, last message bounced from the list due to a bug in the very
email client in question (although it went through to Aaron). Grabbed a
patch from their list to address this for now, attached; the diff to
go.port.mk is also reproduced below.
diff --git a/lang/go/go.port.mk b/lang/go/go.port.mk
index 983c3990706..21bccbd7053 100644
--- a/lang/go/go.port.mk
+++ b/lang/go/go.port.mk
@@ -67,7 +67,7 @@ MODGO_SETUP_WORKSPACE = mkdir -p ${WRKSRC:H}; mv
${MODGO_SUBDIR} ${WRKSRC};
CATEGORIES += lang/go
MODGO_BUILD_TARGET = ${MODGO_BUILD_CMD} ${ALL_TARGET}
-MODGO_FLAGS += -v -p ${MAKE_JOBS}
+MODGO_FLAGS += -v -p=${MAKE_JOBS}
.if empty(DEBUG)
# by default omit symbol table, debug information and DWARF symbol table
aerc.tgz
Description: GNU Zip compressed data
Re: [NEW] mail/aerc
On Wed, 12 Feb 2020 at 22:26:24 -0500, Raymond E. Pasco wrote:
> On Mon Feb 10, 2020 at 9:10 AM, Aaron Bieber wrote:
> > It looks good to me. I'd like to pass in MODGO_FLAGS so we can have
> > verbose
> > info when DEBUG is set. Something like:
> > MAKE_ENV += GOFLAGS="${MODGO_FLAGS}"
> >
> >
> > But it seems the "-p ${MAKE_JOBS}" bit from go.port.mk isn't getting
> > parsed
> > properly in this case.
>
> Go is being a real pain here. It seems to want the syntax to be -p=1
> rather than -p 1 - however, it only cares to *enforce* this when it's in
> the GOFLAGS environment variable and not when it's regular command line
> flags, as MODGO_FLAGS ordinarily are by go.port.mk. The below diff to
> go.port.mk makes it work, and doesn't break the couple other lang/go
> ports I tried; combined with the attached port it respects the flags.
>
> diff --git a/lang/go/go.port.mk b/lang/go/go.port.mk
> index 983c3990706..21bccbd7053 100644
> --- a/lang/go/go.port.mk
> +++ b/lang/go/go.port.mk
> @@ -67,7 +67,7 @@ MODGO_SETUP_WORKSPACE = mkdir -p ${WRKSRC:H}; mv
> ${MODGO_SUBDIR} ${WRKSRC};
> CATEGORIES += lang/go
>
> MODGO_BUILD_TARGET = ${MODGO_BUILD_CMD} ${ALL_TARGET}
> -MODGO_FLAGS += -v -p ${MAKE_JOBS}
> +MODGO_FLAGS += -v -p=${MAKE_JOBS}
>
> .if empty(DEBUG)
> # by default omit symbol table, debug information and DWARF symbol
> table
>
Tested a few ports with this (dnscontrol, gopass, ogvt, go-tools and a few
others that set MODGO_FLAGS), no issues found.
OK abieber@
--
PGP: 0x1F81112D62A9ADCE / 3586 3350 BFEA C101 DB1A 4AF0 1F81 112D 62A9 ADCE
Re: [NEW] mail/aerc
On Sat, 01 Feb 2020 at 03:29:25 -0500, Raymond E. Pasco wrote:
> - I used a modified distfile provided by abieber with a vendor directory,
> which is necessary due to the large number of go package dependencies.
>
> - The custom version of go-libvterm used by aerc upstream includes an
> (unmodified) bundled copy of libvterm itself, which causes issues with
> the build. I instead link against devel/libvterm.
>
> - One filter script shipped with aerc (to display HTML email) depends on
> socksify (provided by security/dante) and www/w3m. I did not include these
> as RUN_DEPENDS because this is an optional script disabled by default,
> but I'm not sure whether this approach is correct.
>
> - cgo in go 1.13 (but not go 1.14) considers ~ an invalid path character,
> but the top-level package name here (and therefore WRKSRC) contains an ~.
> I remedied this by moving the vendor directory contents up to the level
> of the MODGO_WORKSPACE. This workaround shouldn't be necessary when go
> 1.14 is released.
>
> - aerc can be built with notmuch support, but notmuch isn't in ports (yet?),
> so I didn't bother with this.
It looks good to me. I'd like to pass in MODGO_FLAGS so we can have verbose
info when DEBUG is set. Something like:
MAKE_ENV += GOFLAGS="${MODGO_FLAGS}"
But it seems the "-p ${MAKE_JOBS}" bit from go.port.mk isn't getting parsed
properly in this case.
Anyway, if that bit can be sorted out, OK abieber@ for import!
--
PGP: 0x1F81112D62A9ADCE / 3586 3350 BFEA C101 DB1A 4AF0 1F81 112D 62A9 ADCE
Re: [NEW] mail/aerc
On 2020/02/08 23:39, Joerg Jung wrote: > On Sat, Feb 01, 2020 at 03:29:25AM -0500, Raymond E. Pasco wrote: > > - I used a modified distfile provided by abieber with a vendor directory, > > which is necessary due to the large number of go package dependencies. > > IMHO, bundling things defeats the purpose of ports/package system. What > do you do if a dependency got a security update? Grep all distfiles if > bundled somewhere and re-roll and depend on abieber (no offense!) to > handle that? > > How about adding the dependencies as own ports instead? We do the same > for python, perl, etc. I know, this is a lot of work, may be portgen > can be tricked into handling go first... Python and Perl's own packaging systems are generally friendly with standard OS packaging systems (sometimes incompatible changes happen and we have to update a chain of ports to handle it, but these affect users on all OS so it doesn't usually stay a big problem for too long). go (and others like node/npm, rust/cargo, maven) standard ecosystems work differently - actively encouraging incompatible changes by providing the mechanism to pin to a particular version as standard - and in most cases by statically linking so there's no conflict with files on disk. The downside as you rightly say is that security updates don't propagate, but that's baked into the whole ecosystem, it's not sanely possible to change that in ports. If we did try to then: - we would be actively fighting build systems to do what we want. it's already tricky enough to avoid network fetches during build (though this does seem to be getting better), but converting these dependencies to ports would be orders of magnitude worse - we would likely need to have multiple incompatible versions of the same thing to satisfy different dependencies - with static-linked languages we would still have to chase the dependency tree and bump revisions every time we update a "library" port (it's not like it would even save disk space), we don't have the shared library version mechanism, or even "load at runtime" like perl/python to let us bypass this It would be possible to convert to a multi-distfile port instead (like rust/cargo ports do) but really we need better infrastructure before that's a good idea - until that happens bundling a vendored tarball makes it *easier* to update (as long as there's a comment in the Makefile showing how) than making it multi-distfile. > > - aerc can be built with notmuch support, but notmuch isn't in ports (yet?), > > so I didn't bother with this. > > There were some submissions for notmuch in the past, but afaik never > imported. It isn't finished. It still has use-after-frees and some other problems showing up in the test suite.
Re: [NEW] mail/aerc
On Sat, Feb 01, 2020 at 03:29:25AM -0500, Raymond E. Pasco wrote: > - I used a modified distfile provided by abieber with a vendor directory, > which is necessary due to the large number of go package dependencies. IMHO, bundling things defeats the purpose of ports/package system. What do you do if a dependency got a security update? Grep all distfiles if bundled somewhere and re-roll and depend on abieber (no offense!) to handle that? How about adding the dependencies as own ports instead? We do the same for python, perl, etc. I know, this is a lot of work, may be portgen can be tricked into handling go first... > - The custom version of go-libvterm used by aerc upstream includes an > (unmodified) bundled copy of libvterm itself, which causes issues with > the build. I instead link against devel/libvterm. What issues? However, using the existing port makes sense, but why have you still bundled it? > - One filter script shipped with aerc (to display HTML email) depends on > socksify (provided by security/dante) and www/w3m. I did not include these > as RUN_DEPENDS because this is an optional script disabled by default, > but I'm not sure whether this approach is correct. I suggest to add a note to package readme. > - cgo in go 1.13 (but not go 1.14) considers ~ an invalid path character, > but the top-level package name here (and therefore WRKSRC) contains an ~. > I remedied this by moving the vendor directory contents up to the level > of the MODGO_WORKSPACE. This workaround shouldn't be necessary when go > 1.14 is released. Weird. > - aerc can be built with notmuch support, but notmuch isn't in ports (yet?), > so I didn't bother with this. There were some submissions for notmuch in the past, but afaik never imported. Other than that, I tested your port and it works for me. Would be nice to have this imported. Thanks, Regards, Joerg
[NEW] mail/aerc
- I used a modified distfile provided by abieber with a vendor directory, which is necessary due to the large number of go package dependencies. - The custom version of go-libvterm used by aerc upstream includes an (unmodified) bundled copy of libvterm itself, which causes issues with the build. I instead link against devel/libvterm. - One filter script shipped with aerc (to display HTML email) depends on socksify (provided by security/dante) and www/w3m. I did not include these as RUN_DEPENDS because this is an optional script disabled by default, but I'm not sure whether this approach is correct. - cgo in go 1.13 (but not go 1.14) considers ~ an invalid path character, but the top-level package name here (and therefore WRKSRC) contains an ~. I remedied this by moving the vendor directory contents up to the level of the MODGO_WORKSPACE. This workaround shouldn't be necessary when go 1.14 is released. - aerc can be built with notmuch support, but notmuch isn't in ports (yet?), so I didn't bother with this. aerc.tgz Description: GNU Zip compressed data
