This non-parallelized target is useful for noticing core dumps
and preventing them from being clobbered as we run the test
suite. It will also notice leftover temporary files and
directories.
This make target was used on OpenBSD 7.3 to develop at least two
recent fixes:
e281363ba937 (lei:
Konstantin Ryabitsev wrote:
> Hello:
>
> I am curious what is the best approach to have a centrally managed set of lei
> searches, for example via config files tracked in git. For example, the file
> could look like this:
I don't have one nor have I thought about it until now...
I wonder if
Hello:
I am curious what is the best approach to have a centrally managed set of lei
searches, for example via config files tracked in git. For example, the file
could look like this:
mricon.toml:
[search.torvalds]
# All mail sent by torvalds
q =
This seems to work reasonably well across multiple BSDs and
Debian and smooth out differences in packaging granularity.
Declaring the $always_deps relationship between `Xapian'(.pm) and
libxapian means we can get rid of the OpenBSD-specific hack to
remove `xapian-bindings-perl' before other
Konstantin Ryabitsev wrote:
> Tested-by: Konstantin Ryabitsev
Thanks, pushed the series as
a37e3ab3740c24c3 (pop3: limit default mailbox to 1K messages, 2023-09-14)
392d251f97d46579 (pop3: support `?limit=$NUM' parameter in mailbox name,
2023-09-12)
On Thu, Sep 14, 2023 at 12:38:28AM +, Eric Wong wrote:
> > My initial target for deploying POP3 support is to allow Gmail users to
> > pull-subscribe to mailing lists, since Gmail is the #1 provider that we have
> > trouble with message delivery due to their draconian threshold limits.
> >
On Wed, Sep 13, 2023 at 10:03:26PM +, Eric Wong wrote:
> > What if we move the uuid into the password field -- it seems it belongs
> > there
> > anyway, as it's tied to the user cookie.
>
> I've thought about that, too; but it can get tricky since passwords
> aren't visible in most UIs.
The tab character causes inconsistent spacing on display,
and a single space seems fine, here.
---
lib/PublicInbox/WwwCoderepo.pm | 1 -
1 file changed, 1 deletion(-)
diff --git a/lib/PublicInbox/WwwCoderepo.pm b/lib/PublicInbox/WwwCoderepo.pm
index d7ac44ed..834145e9 100644
---
The fundamental difference which I originally missed when
implementing kqueue EVFILT_SIGNAL support is that it does not
consume signals like signalfd(2) does. In other words, with
EVFILT_SIGNAL, it's possible for a single signal to be delivered
twice if we unblock signals upon leaving the event
