Re: [dev] [dwm] with SIGCHLD commit, dwm cannot launch dmenu_extended.
Voila, one single line of change make dmenu_extended_run launch again!
git diff dwm.c
diff --git a/dwm.c b/dwm.c
index c2bd871..f8f83f8 100644
--- a/dwm.c
+++ b/dwm.c
@@ -1653,6 +1653,7 @@ spawn(const Arg *arg)
if (dpy)
close(ConnectionNumber(dpy));
setsid();
+ signal(SIGCHLD, SIG_DFL);
execvp(((char **)arg->v)[0], (char **)arg->v);
die("dwm: execvp '%s' failed:", ((char **)arg->v)[0]);
On 08.04.23 23:02, Storkman wrote:
> On Sat, Apr 08, 2023 at 04:28:15PM +0200, p...@mailbox.org wrote:
> > Hello everyone,
> >
> > I bind keyboard shortcut to launch dmenu_extended[1] in dwm, what works
> > flawlessly before the `Use sigaction(SA_NOCLDWAIT) for SIGCHLD
> > handling` [1] commit, since dmenu_extended does not change anything here,
> > is this a regression or bug introduced with this commit or
> > dmenu_extended need to adapt to conform the change? thanks.
>
> From sigaction(2):
> > A child created via fork(2) inherits a copy of its parent's signal
> > dispositions.
> > During an execve(2), the dispositions of handled signals are reset to the
> > default;
> > the dispositions of ignored signals are left unchanged.
>
> This would explain why running programs affected by this through st works,
> since it runs "signal(SIGCHLD, SIG_DFL)" before executing the shell
> (st.c:715).
>
> Adding "signal(SIGCHLD, SIG_DFL)" before execvp in spawn() at dwm.c:1657 fixes
> anki and mpv with youtube-dl for me.
>
> >
> > [1] https://github.com/MarkHedleyJones/dmenu-extended/
> > [2]
> > https://git.suckless.org/dwm/commit/712d6639ff8e863560328131bbb92b248dc9cde7.html
> >
>
Re: [dev] [dwm] with SIGCHLD commit, dwm cannot launch dmenu_extended.
On Sat, Apr 08, 2023 at 04:28:15PM +0200, p...@mailbox.org wrote: > Hello everyone, > > I bind keyboard shortcut to launch dmenu_extended[1] in dwm, what works > flawlessly before the `Use sigaction(SA_NOCLDWAIT) for SIGCHLD > handling` [1] commit, since dmenu_extended does not change anything here, > is this a regression or bug introduced with this commit or > dmenu_extended need to adapt to conform the change? thanks. >From sigaction(2): > A child created via fork(2) inherits a copy of its parent's signal > dispositions. > During an execve(2), the dispositions of handled signals are reset to the > default; > the dispositions of ignored signals are left unchanged. This would explain why running programs affected by this through st works, since it runs "signal(SIGCHLD, SIG_DFL)" before executing the shell (st.c:715). Adding "signal(SIGCHLD, SIG_DFL)" before execvp in spawn() at dwm.c:1657 fixes anki and mpv with youtube-dl for me. > > [1] https://github.com/MarkHedleyJones/dmenu-extended/ > [2] > https://git.suckless.org/dwm/commit/712d6639ff8e863560328131bbb92b248dc9cde7.html >
Re: [dev] [dwm] with SIGCHLD commit, dwm cannot launch dmenu_extended.
On 23/04/08 07:24PM, p...@mailbox.org wrote:
> static const char *dmenu_extend[] = { "dmenu_extended_run", NULL };
How about:
> > (Try changing your
> > dmenu_extended keybind to something else and see if that works or not).
1. What happens if you use:
static const char *dmenu_extend[] = { "dmenu_run", NULL };
2. What happens when you run from the terminal emulator:
2.a:
$ dmenu_extended_run
2.b:
$ which dmenu_extended_run
3. What happens if you add the path obtained from 2.b to the command
> static const char *dmenu_extend[] = { "dmenu_extended_run", NULL };
^-- here, before 'd'?
signature.asc
Description: PGP signature
Re: [dev] [dwm] with SIGCHLD commit, dwm cannot launch dmenu_extended.
I built dwm based on https://aur.archlinux.org/packages/dwm-git
> diff config.h src/dwm/config.def.h
> 62d61
> < static const char *dmenu_extend[] = { "dmenu_extended_run", NULL };
> 67d65
> < { MODKEY, XK_o, spawn, {.v =
> dmenu_extend } },
in config.h involved only those two lines of change
> uname -a
> Linux hostname 6.2.10-arch1-1 #1 SMP PREEMPT_DYNAMIC Fri, 07 Apr 2023
> 02:10:43 + x86_64 GNU/Linux
On 08.04.23 21:17, Hiltjo Posthuma wrote:
> Hi,
>
> Please provide more information about your operating system etc.
>
> This is with vanilla dwm and only the above change applied? (If not please do
> so).
>
> Thanks,
>
> --
> Kind regards,
> Hiltjo
>
Re: [dev] [dwm] with SIGCHLD commit, dwm cannot launch dmenu_extended.
On Sat, Apr 08, 2023 at 07:24:07PM +0200, p...@mailbox.org wrote:
> - patch is disabled
> - `dwm 2> ~/dwm.log` shows nothing
>
> define command as
>
> static const char *dmenu_extend[] = { "dmenu_extended_run", NULL };
>
> bind the command to a keyboard shortcut
>
> static Key keys[] = {
> MODKEY, XK_o, spawn, {.v =
> dmenu_extend } },
> ...
> };
>
> same config, revert to 89f9905 dmenu_extend just works.
>
> On 08.04.23 21:45, NRK wrote:
> > Hi,
> >
> > On Sat, Apr 08, 2023 at 04:28:15PM +0200, p...@mailbox.org wrote:
> > > I bind keyboard shortcut to launch dmenu_extended[1] in dwm, what works
> > > flawlessly before the `Use sigaction(SA_NOCLDWAIT) for SIGCHLD
> > > handling` [1] commit, since dmenu_extended does not change anything here,
> > > is this a regression or bug introduced with this commit or
> > > dmenu_extended need to adapt to conform the change? thanks.
> >
> > You'll need to provide more information. What does your config look
> > like? Does dwm print any error message to stderr? Did you try to
> > reproduce with a vanilla dwm? Etc.
> >
> > Without providing more information it's not possible to say what's going
> > on here, especially because that commit doesn't really do anything to
> > process launching. Which takes me to the question, how did you verify
> > that it's this commit that's causing the problem?
> >
> > Because the commit right before it (89f9905 grabkeys: Avoid missing
> > events when a keysym maps to multiple keycodes) seems like something
> > that might actually mess with keybinds. (Try changing your
> > dmenu_extended keybind to something else and see if that works or not).
> >
> > - NRK
> >
>
Hi,
Please provide more information about your operating system etc.
This is with vanilla dwm and only the above change applied? (If not please do
so).
Thanks,
--
Kind regards,
Hiltjo
Re: [dev] [dwm] with SIGCHLD commit, dwm cannot launch dmenu_extended.
- patch is disabled
- `dwm 2> ~/dwm.log` shows nothing
define command as
static const char *dmenu_extend[] = { "dmenu_extended_run", NULL };
bind the command to a keyboard shortcut
static Key keys[] = {
MODKEY, XK_o, spawn, {.v =
dmenu_extend } },
...
};
same config, revert to 89f9905 dmenu_extend just works.
On 08.04.23 21:45, NRK wrote:
> Hi,
>
> On Sat, Apr 08, 2023 at 04:28:15PM +0200, p...@mailbox.org wrote:
> > I bind keyboard shortcut to launch dmenu_extended[1] in dwm, what works
> > flawlessly before the `Use sigaction(SA_NOCLDWAIT) for SIGCHLD
> > handling` [1] commit, since dmenu_extended does not change anything here,
> > is this a regression or bug introduced with this commit or
> > dmenu_extended need to adapt to conform the change? thanks.
>
> You'll need to provide more information. What does your config look
> like? Does dwm print any error message to stderr? Did you try to
> reproduce with a vanilla dwm? Etc.
>
> Without providing more information it's not possible to say what's going
> on here, especially because that commit doesn't really do anything to
> process launching. Which takes me to the question, how did you verify
> that it's this commit that's causing the problem?
>
> Because the commit right before it (89f9905 grabkeys: Avoid missing
> events when a keysym maps to multiple keycodes) seems like something
> that might actually mess with keybinds. (Try changing your
> dmenu_extended keybind to something else and see if that works or not).
>
> - NRK
>
Re: [dev] report mx.suckless.org tls issue
they are not enforcing tls, since mx.suckless.org supported tls before, according to their log, last time mx.suckless.org has tls on 2023-02-06, so they use the cache for the following email delivery, but out of a sudden, mx.suckless.org downgrade to non tls, so email failed to deliver. so my question is downgrade from tls to non-tls on mx.suckless.org is a deliberated step? On 08.04.23 16:19, Joseph Graham wrote: > Is your mail provider enforcing mandatory TLS? > > On Saturday, 8 April 2023 15:40:21 BST p...@mailbox.org wrote: > > Hello everyone, > > > > I try to post to the list, but randomly failed with the error `TLS is > > required, but was not offered by host mx.suckless.org` I report the > > issue [1] to my email provider, it seems that mx.suckless.org somehow does > > not properly configured. > > > > [1] > > https://userforum.mailbox.org/topic/6527-tls-is-required-but-was-not-offere > > d-by-host > > > > >
Re: [dev] report mx.suckless.org tls issue
I am using the wrong words "not properly configured", what I mean is, since mx.suckless.org supported tls connection before, but right now mx.suckless.org downgraded to non tls, is this deliberately to be doing so? On 08.04.23 18:54, Quentin Rameau wrote: > > Hello everyone, > > Hi PFX, > > > I try to post to the list, but randomly failed with the error `TLS is > > required, but was not offered by host mx.suckless.org` I report the > > issue [1] to my email provider, it seems that mx.suckless.org somehow does > > not properly configured. > > > > [1] > > https://userforum.mailbox.org/topic/6527-tls-is-required-but-was-not-offered-by-host > > Sorry but I don't speak German, could you explain what the conclusiont they > came to, > for saying that mx.suckless.org isn't “properly configured”? >
Re: [dev] report mx.suckless.org tls issue
> Hello everyone, Hi PFX, > I try to post to the list, but randomly failed with the error `TLS is > required, but was not offered by host mx.suckless.org` I report the > issue [1] to my email provider, it seems that mx.suckless.org somehow does > not properly configured. > > [1] > https://userforum.mailbox.org/topic/6527-tls-is-required-but-was-not-offered-by-host Sorry but I don't speak German, could you explain what the conclusiont they came to, for saying that mx.suckless.org isn't “properly configured”?
Re: [dev] [dwm] with SIGCHLD commit, dwm cannot launch dmenu_extended.
Hi, On Sat, Apr 08, 2023 at 04:28:15PM +0200, p...@mailbox.org wrote: > I bind keyboard shortcut to launch dmenu_extended[1] in dwm, what works > flawlessly before the `Use sigaction(SA_NOCLDWAIT) for SIGCHLD > handling` [1] commit, since dmenu_extended does not change anything here, > is this a regression or bug introduced with this commit or > dmenu_extended need to adapt to conform the change? thanks. You'll need to provide more information. What does your config look like? Does dwm print any error message to stderr? Did you try to reproduce with a vanilla dwm? Etc. Without providing more information it's not possible to say what's going on here, especially because that commit doesn't really do anything to process launching. Which takes me to the question, how did you verify that it's this commit that's causing the problem? Because the commit right before it (89f9905 grabkeys: Avoid missing events when a keysym maps to multiple keycodes) seems like something that might actually mess with keybinds. (Try changing your dmenu_extended keybind to something else and see if that works or not). - NRK
Re: [dev] report mx.suckless.org tls issue
Is your mail provider enforcing mandatory TLS? On Saturday, 8 April 2023 15:40:21 BST p...@mailbox.org wrote: > Hello everyone, > > I try to post to the list, but randomly failed with the error `TLS is > required, but was not offered by host mx.suckless.org` I report the > issue [1] to my email provider, it seems that mx.suckless.org somehow does > not properly configured. > > [1] > https://userforum.mailbox.org/topic/6527-tls-is-required-but-was-not-offere > d-by-host
[dev] report mx.suckless.org tls issue
Hello everyone, I try to post to the list, but randomly failed with the error `TLS is required, but was not offered by host mx.suckless.org` I report the issue [1] to my email provider, it seems that mx.suckless.org somehow does not properly configured. [1] https://userforum.mailbox.org/topic/6527-tls-is-required-but-was-not-offered-by-host
[dev] [dwm] with SIGCHLD commit, dwm cannot launch dmenu_extended.
Hello everyone, I bind keyboard shortcut to launch dmenu_extended[1] in dwm, what works flawlessly before the `Use sigaction(SA_NOCLDWAIT) for SIGCHLD handling` [1] commit, since dmenu_extended does not change anything here, is this a regression or bug introduced with this commit or dmenu_extended need to adapt to conform the change? thanks. [1] https://github.com/MarkHedleyJones/dmenu-extended/ [2] https://git.suckless.org/dwm/commit/712d6639ff8e863560328131bbb92b248dc9cde7.html
