On Sun Aug 14, 2022 at 4:15 PM CDT, Vlad-Stefan Harbuz wrote:
> On Sun Aug 14, 2022 at 7:17 PM BST, Jose Lombera wrote:
> >     ld: warning: fenv.o: missing .note.GNU-stack section implies executable stack
> >     ld: NOTE: This behaviour is deprecated and will be removed in a future version of the linker
>
> Already being tracked in https://todo.sr.ht/~sircmpwn/hare/748

Thanks!

OS: Debian testing (bookworm)
BFD version: GNU ld (GNU Binutils for Debian) 2.38.90.20220713

Building hare using BFD linker complains about linker section:

    $ make
    [...]
    LD      .bin/hare
    ld: warning: fenv.o: missing .note.GNU-stack section implies executable stack
    ld: NOTE: This behaviour is deprecated and will be removed in a future version of the linker
    HARE    .bin/harec2
    ld: warning: temp.rt.9.o: missing .note.GNU-stack section implies executable stack
    ld: NOTE: This behaviour is deprecated and will be removed in a future version of the linker
    HARE    .bin/haredoc

Cleanup existing PartSwitcher before recreating a new one when command
:toggle-headers is executed, ensuring existing part pagers are cleaned
up.  This fixes a leak in pager processes when :toggle-headers is
executed repeatedly without closing the message.

Signed-off-by: Jose Lombera <jose@lombera.dev>
---
I'm not familiar with the codebase, not sure this is the most
appropriate solution.

To reproduce the issue, in aerc:

1. Open a message.
2. Call :toggle-headers several times.  Every call leaks pager
[message trimmed]

On Thu Jul 14, 2022 at 8:27 PM CDT, Caleb Heuer wrote:
> > some mail clients use different heuristics for "threading" messages
> > when displaying them.
>
> I'm sure you're correct. Aerc doesn't show threads, so I was
> basing that on Migadu's webmail and the Samsung mail app on my
> smartphone.

FYI, threading is supported by aerc since v0.7.0.  See option
threading-enabled in aerc-config(5).

Ensure abbreviated commit SHA1 of fixed length in computed version
regardless of user's configuration.  Choose length 12 as safe value.

Link: https://github.com/git/git/commit/dce96489162b05ae3463741f7f0365ff56f0de36

Signed-off-by: Jose Lombera <jose@lombera.dev>
---
V1 -> V2: increase length to 12 (from 8).

 Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index 9d43e9b7ad19..66dc1563d032 100644
[message trimmed]

On Thu Jul 14, 2022 at 4:11 PM CDT, Robin Jarry wrote:
> Hi there, this is a nice addition.
>
> Since you are not using the default --abbrev=7 value, why not go all the
> way and force it to 12?
>
> https://github.com/git/git/commit/dce96489162b05ae3463741f7f0365ff56f0de36

Fine by me.  No particular reason I chose 8, but thought some people
might find 12 excessive :).

I'll send patch V2.

Ensure abbreviated commit SHA1 of fixed length in computed version
regardless of user's configuration.

Signed-off-by: Jose Lombera <jose@lombera.dev>
---
I was hit by this when doing

  $ make
  $ sudo make install

Since I have core.abbrev=12 in my global git config, the version
generated in the first command (using my user's config) and the second
one (using root's config) was different, triggering the build of aerc
all over again by the second command.  This meant go dependencies were
[message trimmed]

On Mon Jul 11, 2022 at 11:07 PM CDT,  wrote:
> Hello,
>
> First off, thanks for creating such a fun language!
>
> I was working on a project in Hare on and off. Whenever starting again I would pull
> and rebuild harec and the stdlib every time before I started working (don't wanna
> get left behind!).
>
> Of course, after one pull I started getting some harec crash:
>
> $ hare run test.ha
> harec: src/types.c:448: const struct type *tagged_select_subtype(const struct type *, const struct type *): Assertion `tagged->storage == STORAGE_TAGGED' failed.
> Error: harec: exited with signal 6

On Fri Jul 1, 2022 at 2:24 AM CDT, Drew DeVault wrote:
> On Mon Jun 20, 2022 at 7:33 AM CEST, Jose Lombera wrote:
> > So I was thinking what would be the correct way to fix this.  The first
> > idea that comes to mind is to add additional cases for each one of the
> > members of errors::error, similarly than is already done for
> > errors::opaque.  This is the most straightforward (and probably correct)
> > solution.  However, it basically means duplicating the implementation of
> > errors::strerror() inside exec::strerror().  So I tried the following
>
> Can we not just add a match case on errors::error? WE can ditch the
> opaque branch as well.

Yeah, sorry, I was not quite familiar yet with match expression rules
when I wrote the email.  It was clearer to me later when I read the

On Thu Jun 30, 2022 at 11:50 AM CDT, Przemysław Kamiński wrote:
> Yes, attachments are forbidden (I got a suggestion to use plaintext mail 
> actually).
>
> Here is the screenshot:
> https://filen.io/d/01cd9002-6655-4115-987f-f88fd64cca68#!7hVaTMq5l1v3K7WEe1JMIRKjEI2VJtYx
>

I'm only guessing, but maybe you have to choose one of
Public/Unlisted/Private.  It would still be a bug in paste.sr.ht for not
handling this correctly, though.

- Lombera