* Re: b4 bugs / future improvements
2022-10-18 20:18 ` Konstantin Ryabitsev
@ 2022-10-18 20:29 ` Mark Brown
2022-10-18 20:37 ` Konstantin Ryabitsev
2022-10-19 2:05 ` Rob Herring
2022-10-19 8:01 ` Maxime Ripard
2 siblings, 1 reply; 15+ messages in thread
From: Mark Brown @ 2022-10-18 20:29 UTC (permalink / raw)
To: Konstantin Ryabitsev; +Cc: Maxime Ripard, users, tools
[-- Attachment #1: Type: text/plain, Size: 903 bytes --]
On Tue, Oct 18, 2022 at 04:18:04PM -0400, Konstantin Ryabitsev wrote:
> On Tue, Oct 18, 2022 at 05:36:20PM +0200, Maxime Ripard wrote:
> > - Generally speaking, rebasing a b4 series is a bit troublesome:
> >
> > - It's a bit tedious to do. One needs to rebase and then edit the
> > cover letter by hand without b4 being involved. I don't think doing
> > the rebase interface all over again is reasonable, but maybe we
> > could add a subcommand to set a new base?
> Interesting. I'm not sure I fully understand the problem, but then all my
> rebase tests were all very simple cases of running "git rebase <newtag>"
> Is there a reason why you have to manually edit the cover letter after a
> rebase?
If you're doing an inter-version changelog it's common to say something
like "rebased against foo" in there. It's a bit clearer about things
than base-commit.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: b4 bugs / future improvements
2022-10-18 20:29 ` Mark Brown
@ 2022-10-18 20:37 ` Konstantin Ryabitsev
2022-10-19 8:04 ` Maxime Ripard
0 siblings, 1 reply; 15+ messages in thread
From: Konstantin Ryabitsev @ 2022-10-18 20:37 UTC (permalink / raw)
To: Mark Brown; +Cc: Maxime Ripard, users, tools
On Tue, Oct 18, 2022 at 09:29:44PM +0100, Mark Brown wrote:
> > > - It's a bit tedious to do. One needs to rebase and then edit the
> > > cover letter by hand without b4 being involved. I don't think doing
> > > the rebase interface all over again is reasonable, but maybe we
> > > could add a subcommand to set a new base?
>
> > Interesting. I'm not sure I fully understand the problem, but then all my
> > rebase tests were all very simple cases of running "git rebase <newtag>"
>
> > Is there a reason why you have to manually edit the cover letter after a
> > rebase?
>
> If you're doing an inter-version changelog it's common to say something
> like "rebased against foo" in there. It's a bit clearer about things
> than base-commit.
No, I don't think that's what Maxime means -- "rebased against foo" can be
done using "b4 prep --edit-cover". I think there's two things going on:
1. he's using a different cover strategy that requires base-branch tracking
2. he's rebasing on a different branch, as opposed to a newer tag within the
same branch
That would indeed be as cumbersome as described (and why I'm using the "cover
letter as an empty commit at the start of the series" strategy as the
default).
Maxime, is that correct? I assume you're using "tip-commit"?
-K
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: b4 bugs / future improvements
2022-10-18 20:37 ` Konstantin Ryabitsev
@ 2022-10-19 8:04 ` Maxime Ripard
2022-10-19 19:16 ` Konstantin Ryabitsev
0 siblings, 1 reply; 15+ messages in thread
From: Maxime Ripard @ 2022-10-19 8:04 UTC (permalink / raw)
To: Konstantin Ryabitsev; +Cc: Mark Brown, users, tools
[-- Attachment #1: Type: text/plain, Size: 1831 bytes --]
On Tue, Oct 18, 2022 at 04:37:49PM -0400, Konstantin Ryabitsev wrote:
> On Tue, Oct 18, 2022 at 09:29:44PM +0100, Mark Brown wrote:
> > > > - It's a bit tedious to do. One needs to rebase and then edit the
> > > > cover letter by hand without b4 being involved. I don't think doing
> > > > the rebase interface all over again is reasonable, but maybe we
> > > > could add a subcommand to set a new base?
> >
> > > Interesting. I'm not sure I fully understand the problem, but then all my
> > > rebase tests were all very simple cases of running "git rebase <newtag>"
> >
> > > Is there a reason why you have to manually edit the cover letter after a
> > > rebase?
> >
> > If you're doing an inter-version changelog it's common to say something
> > like "rebased against foo" in there. It's a bit clearer about things
> > than base-commit.
>
> No, I don't think that's what Maxime means -- "rebased against foo" can be
> done using "b4 prep --edit-cover".
Yeah, I'm manually editing the JSON part. But tbf, I don't really know
why I started doing it, so it might be fixed for a while, or never an
issue in the first place.
> I think there's two things going on:
>
> 1. he's using a different cover strategy that requires base-branch tracking
> 2. he's rebasing on a different branch, as opposed to a newer tag within the
> same branch
If it causes any issue, then it could be the reason yeah. I do rebase
across different branches from time to time, so it might be why I
started doing so.
> That would indeed be as cumbersome as described (and why I'm using the "cover
> letter as an empty commit at the start of the series" strategy as the
> default).
>
> Maxime, is that correct? I assume you're using "tip-commit"?
I'm using the commit strategy
Maxime
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: b4 bugs / future improvements
2022-10-19 8:04 ` Maxime Ripard
@ 2022-10-19 19:16 ` Konstantin Ryabitsev
2022-10-20 8:41 ` Maxime Ripard
0 siblings, 1 reply; 15+ messages in thread
From: Konstantin Ryabitsev @ 2022-10-19 19:16 UTC (permalink / raw)
To: Maxime Ripard; +Cc: Mark Brown, users, tools
On Wed, Oct 19, 2022 at 10:04:39AM +0200, Maxime Ripard wrote:
> > > If you're doing an inter-version changelog it's common to say something
> > > like "rebased against foo" in there. It's a bit clearer about things
> > > than base-commit.
> >
> > No, I don't think that's what Maxime means -- "rebased against foo" can be
> > done using "b4 prep --edit-cover".
>
> Yeah, I'm manually editing the JSON part. But tbf, I don't really know
> why I started doing it, so it might be fixed for a while, or never an
> issue in the first place.
If you're using the "commit" (default) strategy, then you really don't need to
worry about the base-branch bit in the JSON tracking info.
> > I think there's two things going on:
> >
> > 1. he's using a different cover strategy that requires base-branch tracking
> > 2. he's rebasing on a different branch, as opposed to a newer tag within the
> > same branch
>
> If it causes any issue, then it could be the reason yeah. I do rebase
> across different branches from time to time, so it might be why I
> started doing so.
When we keep the cover letter at the start of the series, then we don't really
care about the base branch -- we know exactly where the series starts, so we
don't need to keep any information about the tracking branch around. Next time
you rebase, just ignore the base-branch entry.
I will look at improving the trailers matching logic in the near future
(that's unrelated to rebasing -- we just need to have a sane fall-back when
the patch-id changes).
-K
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: b4 bugs / future improvements
2022-10-19 19:16 ` Konstantin Ryabitsev
@ 2022-10-20 8:41 ` Maxime Ripard
0 siblings, 0 replies; 15+ messages in thread
From: Maxime Ripard @ 2022-10-20 8:41 UTC (permalink / raw)
To: Konstantin Ryabitsev; +Cc: Mark Brown, users, tools
[-- Attachment #1: Type: text/plain, Size: 1791 bytes --]
On Wed, Oct 19, 2022 at 03:16:33PM -0400, Konstantin Ryabitsev wrote:
> On Wed, Oct 19, 2022 at 10:04:39AM +0200, Maxime Ripard wrote:
> > > > If you're doing an inter-version changelog it's common to say something
> > > > like "rebased against foo" in there. It's a bit clearer about things
> > > > than base-commit.
> > >
> > > No, I don't think that's what Maxime means -- "rebased against foo" can be
> > > done using "b4 prep --edit-cover".
> >
> > Yeah, I'm manually editing the JSON part. But tbf, I don't really know
> > why I started doing it, so it might be fixed for a while, or never an
> > issue in the first place.
>
> If you're using the "commit" (default) strategy, then you really don't need to
> worry about the base-branch bit in the JSON tracking info.
I just tested and it indeed just works, sorry for the confusion :)
> > > I think there's two things going on:
> > >
> > > 1. he's using a different cover strategy that requires base-branch tracking
> > > 2. he's rebasing on a different branch, as opposed to a newer tag within the
> > > same branch
> >
> > If it causes any issue, then it could be the reason yeah. I do rebase
> > across different branches from time to time, so it might be why I
> > started doing so.
>
> When we keep the cover letter at the start of the series, then we don't really
> care about the base branch -- we know exactly where the series starts, so we
> don't need to keep any information about the tracking branch around. Next time
> you rebase, just ignore the base-branch entry.
>
> I will look at improving the trailers matching logic in the near future
> (that's unrelated to rebasing -- we just need to have a sane fall-back when
> the patch-id changes).
Awesome, thanks
Maxime
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: b4 bugs / future improvements
2022-10-18 20:18 ` Konstantin Ryabitsev
2022-10-18 20:29 ` Mark Brown
@ 2022-10-19 2:05 ` Rob Herring
2022-10-19 8:01 ` Maxime Ripard
2 siblings, 0 replies; 15+ messages in thread
From: Rob Herring @ 2022-10-19 2:05 UTC (permalink / raw)
To: Konstantin Ryabitsev; +Cc: Maxime Ripard, users, tools
On Tue, Oct 18, 2022 at 3:18 PM Konstantin Ryabitsev
<konstantin@linuxfoundation.org> wrote:
>
> On Tue, Oct 18, 2022 at 05:36:20PM +0200, Maxime Ripard wrote:
> > Hi Konstantin,
> >
> > Thanks again for b4, it's really great :)
>
> I'm glad you're trying out the "send" functionality, despite its experimental
> state -- your feedback is very welcome.
>
> > There's a bunch of things I have noticed in the recent weeks:
> >
> > - It looks like 87e0e464959c breaks msmtp which doesn't recognize the
> > -f option, and will just error out
>
> There's got to be something else going on, since -f is required for sendmail
> compatibility. The msmtp manpage specifically mentions that is supports it:
> https://manpages.ubuntu.com/manpages/trusty/man1/msmtp.1.html
>
> (see under "options specific to sendmail mode")
>
> > - Generally speaking, rebasing a b4 series is a bit troublesome:
> >
> > - It's a bit tedious to do. One needs to rebase and then edit the
> > cover letter by hand without b4 being involved. I don't think doing
> > the rebase interface all over again is reasonable, but maybe we
> > could add a subcommand to set a new base?
>
> Interesting. I'm not sure I fully understand the problem, but then all my
> rebase tests were all very simple cases of running "git rebase <newtag>"
>
> Is there a reason why you have to manually edit the cover letter after a
> rebase?
>
> > - If one sends a version, rebases, and then runs b4 trailers -u, then
> > no tag is found for that series. I assume it's because the
> > change-id has changed, but maybe for series that differ from the
> > last sent version we could also look for the last sent change-id?
>
> This is really strange, there's got to be something else going on. Here's a
> simple test I just did:
Isn't this the same issue I reported where the patch hash changes and
no trailers are found.
Rob
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: b4 bugs / future improvements
2022-10-18 20:18 ` Konstantin Ryabitsev
2022-10-18 20:29 ` Mark Brown
2022-10-19 2:05 ` Rob Herring
@ 2022-10-19 8:01 ` Maxime Ripard
2022-10-19 19:21 ` Konstantin Ryabitsev
2022-10-20 8:49 ` Maxime Ripard
2 siblings, 2 replies; 15+ messages in thread
From: Maxime Ripard @ 2022-10-19 8:01 UTC (permalink / raw)
To: Konstantin Ryabitsev; +Cc: users, tools
[-- Attachment #1: Type: text/plain, Size: 4923 bytes --]
On Tue, Oct 18, 2022 at 04:18:04PM -0400, Konstantin Ryabitsev wrote:
> > There's a bunch of things I have noticed in the recent weeks:
> >
> > - It looks like 87e0e464959c breaks msmtp which doesn't recognize the
> > -f option, and will just error out
>
> There's got to be something else going on, since -f is required for sendmail
> compatibility. The msmtp manpage specifically mentions that is supports it:
> https://manpages.ubuntu.com/manpages/trusty/man1/msmtp.1.html
>
> (see under "options specific to sendmail mode")
It might be the auto argument that confuses it then? I'll check.
> > - Generally speaking, rebasing a b4 series is a bit troublesome:
> >
> > - It's a bit tedious to do. One needs to rebase and then edit the
> > cover letter by hand without b4 being involved. I don't think doing
> > the rebase interface all over again is reasonable, but maybe we
> > could add a subcommand to set a new base?
>
> Interesting. I'm not sure I fully understand the problem, but then all my
> rebase tests were all very simple cases of running "git rebase <newtag>"
>
> Is there a reason why you have to manually edit the cover letter after a
> rebase?
I was under the impression that we needed to update the base-branch
field? b4 prep -e sets it, so I was assuming it was important, but I
might just be wrong and it's not needed.
> > - If one sends a version, rebases, and then runs b4 trailers -u, then
> > no tag is found for that series. I assume it's because the
> > change-id has changed, but maybe for series that differ from the
> > last sent version we could also look for the last sent change-id?
>
> This is really strange, there's got to be something else going on. Here's a
> simple test I just did:
>
> First, I create a new b4 prep branch from a random patch series, and base it
> off of tag v6.0:
>
> $ b4 prep -n test-rebase -F 20221018111232.4021-1-elic@nvidia.com -f v6.0
> Checking attestation on all messages, may take a moment...
> ---
> ✓ [PATCH 1/4] vdpa/mlx5: Fix rule forwarding VLAN to TIR
> ✓ [PATCH 2/4] vdpa/mlx5: Move some definitions to a new header file
> ✓ [PATCH 3/4] vdpa/mlx5: Add debugfs subtree
> ✓ [PATCH 4/4] vdpa/mlx5: Add RX counters to debugfs
> ---
> ✓ Signed: DKIM/nvidia.com
> ---
> Created new branch b4/test-rebase
> Applying 4 patches
> ---
> Applying: vdpa/mlx5: Fix rule forwarding VLAN to TIR
> Applying: vdpa/mlx5: Move some definitions to a new header file
> Applying: vdpa/mlx5: Add debugfs subtree
> Applying: vdpa/mlx5: Add RX counters to debugfs
> ---
> NOTE: any follow-up trailers were ignored; apply them with b4 trailers -u
>
> Next, I rebase it on v6.1-rc1:
>
> $ git rebase v6.1-rc1
> Successfully rebased and updated refs/heads/b4/test-rebase.
>
> Now I update the trailers:
>
> $ b4 trailers -u
> Calculating patch-ids from 4 commits
> Checking change-id "20221018-test-rebase-108ba0501f16"
> Grabbing search results from lore.kernel.org
> Nothing matching that query.
> Retrieving thread matching 20221018111232.4021-1-elic@nvidia.com
> Grabbing thread from lore.kernel.org/all/20221018111232.4021-1-elic%40nvidia.com/t.mbox.gz
> ---
> vdpa/mlx5: Fix rule forwarding VLAN to TIR
> + Reviewed-by: Si-Wei Liu <si-wei.liu@oracle.com> (✓ DKIM/oracle.com)
> vdpa/mlx5: Move some definitions to a new header file
> + Reviewed-by: Si-Wei Liu <si-wei.liu@oracle.com> (✓ DKIM/oracle.com)
> vdpa/mlx5: Add debugfs subtree
> + Reviewed-by: Si-Wei Liu <si-wei.liu@oracle.com> (✓ DKIM/oracle.com)
> ---
> Invoking git-filter-repo to update trailers.
> New history written in 1.26 seconds...
> Completely finished after 1.57 seconds.
> Trailers updated.
>
> I think I need to better understand your workflow to grasp where the
> disconnect is.
I just played around some more, and it looks that when the commit is
exactly the same, it's indeed able to find the trailers.
However, if there's a conflict (which is still fairly common when one
rebases) and we do a merge conflict resolution it's not able to anymore.
Rob's hint in his mail that there's a patch hash to retrieve the trailer
would explain it, the patch content (and context) has potentially
changed after a rebase.
> > And finally, and this is more of a feature request, now that it looks
> > like we have the list of all the older versions in the cover letter and
> > their base, could we have a subcommand to start a range-diff between an
> > older version and its base, and the current base and HEAD?
>
> It's already in master. :)
>
> b4 prep --compare-to vN
Oh, I missed it, it's awesome thanks :)
Maxime
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: b4 bugs / future improvements
2022-10-19 8:01 ` Maxime Ripard
@ 2022-10-19 19:21 ` Konstantin Ryabitsev
2022-10-20 8:49 ` Maxime Ripard
1 sibling, 0 replies; 15+ messages in thread
From: Konstantin Ryabitsev @ 2022-10-19 19:21 UTC (permalink / raw)
To: Maxime Ripard; +Cc: users, tools
[-- Attachment #1: Type: text/plain, Size: 1050 bytes --]
On Wed, Oct 19, 2022 at 10:01:40AM +0200, Maxime Ripard wrote:
> > Is there a reason why you have to manually edit the cover letter after a
> > rebase?
>
> I was under the impression that we needed to update the base-branch
> field? b4 prep -e sets it, so I was assuming it was important, but I
> might just be wrong and it's not needed.
Right, we set it initially for all cover letter strategies, but if you're
using the default "commit" strategy (keeping the cover letter in an empty
commit at the start of the series), then it's purely informational and we
don't use it for anything.
> However, if there's a conflict (which is still fairly common when one
> rebases) and we do a merge conflict resolution it's not able to anymore.
> Rob's hint in his mail that there's a patch hash to retrieve the trailer
> would explain it, the patch content (and context) has potentially
> changed after a rebase.
I'll work on fixing that -- I just need to do some yak shaving in pytest
so I can write some tests around it first.
-K
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: b4 bugs / future improvements
2022-10-19 8:01 ` Maxime Ripard
2022-10-19 19:21 ` Konstantin Ryabitsev
@ 2022-10-20 8:49 ` Maxime Ripard
2022-11-09 14:14 ` Maxime Ripard
2023-05-05 7:17 ` Maxime Ripard
1 sibling, 2 replies; 15+ messages in thread
From: Maxime Ripard @ 2022-10-20 8:49 UTC (permalink / raw)
To: Konstantin Ryabitsev; +Cc: users, tools
[-- Attachment #1: Type: text/plain, Size: 1517 bytes --]
On Wed, Oct 19, 2022 at 10:01:40AM +0200, Maxime Ripard wrote:
> On Tue, Oct 18, 2022 at 04:18:04PM -0400, Konstantin Ryabitsev wrote:
> > > There's a bunch of things I have noticed in the recent weeks:
> > >
> > > - It looks like 87e0e464959c breaks msmtp which doesn't recognize the
> > > -f option, and will just error out
> >
> > There's got to be something else going on, since -f is required for sendmail
> > compatibility. The msmtp manpage specifically mentions that is supports it:
> > https://manpages.ubuntu.com/manpages/trusty/man1/msmtp.1.html
> >
> > (see under "options specific to sendmail mode")
>
> It might be the auto argument that confuses it then? I'll check.
So, here's the behaviour I'm seeing:
$ printf "From: <maxime@cerno.tech>\nTo: <maxime@cerno.tech>\nSubject: Test\n\nTest Test." | msmtp -i -f auto maxime@cerno.tech
msmtp: recipient address maxime@cerno.tech not accepted by the server
msmtp: server message: 504 5.5.2 <auto>: Sender address rejected: need fully-qualified address
msmtp: could not send mail (account default from /home/max/.config/msmtp/config)
If I drop the -f auto, it works:
$ printf "From: <maxime@cerno.tech>\nTo: <maxime@cerno.tech>\nSubject: Test\n\nTest Test." | msmtp -i maxime@cerno.tech
$ echo $?
0
It seems to be related to
https://github.com/marlam/msmtp-mirror/issues/51 except I don't have
set_from_header in my config. I've tried to use allow_from_override and
force it to off, and it didn't help.
Maxime
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: b4 bugs / future improvements
2022-10-20 8:49 ` Maxime Ripard
@ 2022-11-09 14:14 ` Maxime Ripard
2022-11-29 17:14 ` Konstantin Ryabitsev
2023-05-05 7:17 ` Maxime Ripard
1 sibling, 1 reply; 15+ messages in thread
From: Maxime Ripard @ 2022-11-09 14:14 UTC (permalink / raw)
To: Konstantin Ryabitsev; +Cc: users, tools
Hi,
On Thu, Oct 20, 2022 at 10:49:30AM +0200, Maxime Ripard wrote:
> On Wed, Oct 19, 2022 at 10:01:40AM +0200, Maxime Ripard wrote:
> > On Tue, Oct 18, 2022 at 04:18:04PM -0400, Konstantin Ryabitsev wrote:
> > > > There's a bunch of things I have noticed in the recent weeks:
> > > >
> > > > - It looks like 87e0e464959c breaks msmtp which doesn't recognize the
> > > > -f option, and will just error out
> > >
> > > There's got to be something else going on, since -f is required for sendmail
> > > compatibility. The msmtp manpage specifically mentions that is supports it:
> > > https://manpages.ubuntu.com/manpages/trusty/man1/msmtp.1.html
> > >
> > > (see under "options specific to sendmail mode")
> >
> > It might be the auto argument that confuses it then? I'll check.
>
> So, here's the behaviour I'm seeing:
>
> $ printf "From: <maxime@cerno.tech>\nTo: <maxime@cerno.tech>\nSubject: Test\n\nTest Test." | msmtp -i -f auto maxime@cerno.tech
> msmtp: recipient address maxime@cerno.tech not accepted by the server
> msmtp: server message: 504 5.5.2 <auto>: Sender address rejected: need fully-qualified address
> msmtp: could not send mail (account default from /home/max/.config/msmtp/config)
>
> If I drop the -f auto, it works:
>
> $ printf "From: <maxime@cerno.tech>\nTo: <maxime@cerno.tech>\nSubject: Test\n\nTest Test." | msmtp -i maxime@cerno.tech
> $ echo $?
> 0
>
> It seems to be related to
> https://github.com/marlam/msmtp-mirror/issues/51 except I don't have
> set_from_header in my config. I've tried to use allow_from_override and
> force it to off, and it didn't help.
I just discovered something else.
For various reasons, on one of my series I keep a per-commit changelog,
in the commit log after a ---
This works generally fine, until I run b4 trailers -u which seems to
drop the entire content after --- when adding the tags.
Maxime
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: b4 bugs / future improvements
2022-11-09 14:14 ` Maxime Ripard
@ 2022-11-29 17:14 ` Konstantin Ryabitsev
2022-11-29 20:52 ` Maxime Ripard
0 siblings, 1 reply; 15+ messages in thread
From: Konstantin Ryabitsev @ 2022-11-29 17:14 UTC (permalink / raw)
To: Maxime Ripard; +Cc: users, tools
On Wed, Nov 09, 2022 at 03:14:59PM +0100, Maxime Ripard wrote:
> > It seems to be related to
> > https://github.com/marlam/msmtp-mirror/issues/51 except I don't have
> > set_from_header in my config. I've tried to use allow_from_override and
> > force it to off, and it didn't help.
>
> I just discovered something else.
>
> For various reasons, on one of my series I keep a per-commit changelog,
> in the commit log after a ---
>
> This works generally fine, until I run b4 trailers -u which seems to
> drop the entire content after --- when adding the tags.
This took a while to track and fix, but this should no longer happen in master
and stable-0.10.y. Thank you for the report.
-K
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: b4 bugs / future improvements
2022-11-29 17:14 ` Konstantin Ryabitsev
@ 2022-11-29 20:52 ` Maxime Ripard
0 siblings, 0 replies; 15+ messages in thread
From: Maxime Ripard @ 2022-11-29 20:52 UTC (permalink / raw)
To: Konstantin Ryabitsev; +Cc: users, tools
[-- Attachment #1: Type: text/plain, Size: 862 bytes --]
On Tue, Nov 29, 2022 at 12:14:53PM -0500, Konstantin Ryabitsev wrote:
> On Wed, Nov 09, 2022 at 03:14:59PM +0100, Maxime Ripard wrote:
> > > It seems to be related to
> > > https://github.com/marlam/msmtp-mirror/issues/51 except I don't have
> > > set_from_header in my config. I've tried to use allow_from_override and
> > > force it to off, and it didn't help.
> >
> > I just discovered something else.
> >
> > For various reasons, on one of my series I keep a per-commit changelog,
> > in the commit log after a ---
> >
> > This works generally fine, until I run b4 trailers -u which seems to
> > drop the entire content after --- when adding the tags.
>
> This took a while to track and fix, but this should no longer happen in master
> and stable-0.10.y. Thank you for the report.
Awesome, I'll give it a try, thanks a lot
Maxime
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: b4 bugs / future improvements
2022-10-20 8:49 ` Maxime Ripard
2022-11-09 14:14 ` Maxime Ripard
@ 2023-05-05 7:17 ` Maxime Ripard
1 sibling, 0 replies; 15+ messages in thread
From: Maxime Ripard @ 2023-05-05 7:17 UTC (permalink / raw)
To: Konstantin Ryabitsev; +Cc: users, tools
[-- Attachment #1: Type: text/plain, Size: 1734 bytes --]
On Thu, Oct 20, 2022 at 10:49:30AM +0200, Maxime Ripard wrote:
> On Wed, Oct 19, 2022 at 10:01:40AM +0200, Maxime Ripard wrote:
> > On Tue, Oct 18, 2022 at 04:18:04PM -0400, Konstantin Ryabitsev wrote:
> > > > There's a bunch of things I have noticed in the recent weeks:
> > > >
> > > > - It looks like 87e0e464959c breaks msmtp which doesn't recognize the
> > > > -f option, and will just error out
> > >
> > > There's got to be something else going on, since -f is required for sendmail
> > > compatibility. The msmtp manpage specifically mentions that is supports it:
> > > https://manpages.ubuntu.com/manpages/trusty/man1/msmtp.1.html
> > >
> > > (see under "options specific to sendmail mode")
> >
> > It might be the auto argument that confuses it then? I'll check.
>
> So, here's the behaviour I'm seeing:
>
> $ printf "From: <maxime@cerno.tech>\nTo: <maxime@cerno.tech>\nSubject: Test\n\nTest Test." | msmtp -i -f auto maxime@cerno.tech
> msmtp: recipient address maxime@cerno.tech not accepted by the server
> msmtp: server message: 504 5.5.2 <auto>: Sender address rejected: need fully-qualified address
> msmtp: could not send mail (account default from /home/max/.config/msmtp/config)
>
> If I drop the -f auto, it works:
>
> $ printf "From: <maxime@cerno.tech>\nTo: <maxime@cerno.tech>\nSubject: Test\n\nTest Test." | msmtp -i maxime@cerno.tech
> $ echo $?
> 0
I was finally able to figure that one out.
Git configuration option sendemail.envelopeSender has a special value
"auto" that will use the From address and pass that to sendmail's -f.
b4 uses sendemail.envelopeSender directly, passing "auto" directly which
results in the behaviour described above.
Maxime
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply [flat|nested] 15+ messages in thread