8:46 a.m.
New subject: [PATCH] bodhi-pungi: only run multi-arch SB on f31+
This is a fixup for d7713e6 where mulit-arch was enabled.
---
roles/bodhi2/backend/templates/pungi.rpm.conf.j2 | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/roles/bodhi2/backend/templates/pungi.rpm.conf.j2
b/roles/bodhi2/backend/templates/pungi.rpm.conf.j2
index 640ddf058..b83c9f4f5 100644
--- a/roles/bodhi2/backend/templates/pungi.rpm.conf.j2
+++ b/roles/bodhi2/backend/templates/pungi.rpm.conf.j2
@@ -193,8 +193,13 @@ ostree = {
"ostree_ref": "fedora/[[ release.version_int
]]/${basearch}/testing/silverblue",
[% endif %]
"tag_ref": False,
- "arches": ["x86_64", "ppc64le",
"aarch64" ],
- "failable": ["x86_64", "ppc64le",
"aarch64" ]
+ [% if release.version_int <= 30 %]
+ "arches": ["x86_64"],
+ "failable": ["x86_64"]
+ [% else %]
+ "arches": ["x86_64", "ppc64le",
"aarch64" ],
+ "failable": ["x86_64", "ppc64le",
"aarch64" ]
+ [% endif %]
},
]
}
--
2.20.1
1:19 p.m.
I didn't see anything patched on there so I am not sure what to review.
On Tue, 29 Oct 2019 at 09:49, Dusty Mabe <dusty(a)dustymabe.com> wrote:
[PATCH] bodhi-pungi: only run multi-arch SB on f31+
_______________________________________________
infrastructure mailing list -- infrastructure(a)lists.fedoraproject.org
To unsubscribe send an email to infrastructure-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedora...
--
Stephen J Smoogen.
1:45 p.m.
On Tue, Oct 29, 2019 at 02:19:00PM -0400, Stephen John Smoogen wrote:
I didn't see anything patched on there so I am not sure what to
review.
git-send-email always for some reason sends the actual patch as a
followup. So, look for the first followup to the orig message in the
thread...
kevin
--
On Tue, 29 Oct 2019 at 09:49, Dusty Mabe <dusty(a)dustymabe.com> wrote:
>
> [PATCH] bodhi-pungi: only run multi-arch SB on f31+
> _______________________________________________
> infrastructure mailing list -- infrastructure(a)lists.fedoraproject.org
> To unsubscribe send an email to infrastructure-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedora...
--
Stephen J Smoogen.
_______________________________________________
infrastructure mailing list -- infrastructure(a)lists.fedoraproject.org
To unsubscribe send an email to infrastructure-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedora...
1:30 a.m.
Kevin Fenzi wrote:
On Tue, Oct 29, 2019 at 02:19:00PM -0400, Stephen John
Smoogen wrote:
> I didn't see anything patched on there so I am not sure
> what to review.
git-send-email always for some reason sends the actual
patch as a followup. So, look for the first followup to
the orig message in the thread...
Hmm, that's not behavior I've ever seen from git send-email.
Is the git format-patch --thread option or format.thread
config variable set along with the --thread option to git
send-email? The defaults generally work.
Now, if we're talking about the ancient 1.x versions in
RHEL, maybe the defaults were different. Though even then,
I don't recall having this issue.
The one change I can recall that's in the vicinity was from
deep nested threads (where each patch was a reply to the
previous one) to shallow threads (where each patch in a
series is a reply to the cover-letter). That shouldn't come
into play at all with a single patch.
Is there a doc covering the process which I could follow and
try to reproduce (and hopefully help to avoid this)?
--
Todd
11:50 a.m.
On Thu, Oct 31, 2019 at 02:30:49AM -0400, Todd Zullinger wrote:
Kevin Fenzi wrote:
> On Tue, Oct 29, 2019 at 02:19:00PM -0400, Stephen John
> Smoogen wrote:
>> I didn't see anything patched on there so I am not sure
>> what to review.
>
> git-send-email always for some reason sends the actual
> patch as a followup. So, look for the first followup to
> the orig message in the thread...
Hmm, that's not behavior I've ever seen from git send-email.
Is the git format-patch --thread option or format.thread
config variable set along with the --thread option to git
send-email? The defaults generally work.
Now, if we're talking about the ancient 1.x versions in
RHEL, maybe the defaults were different. Though even then,
I don't recall having this issue.
The one change I can recall that's in the vicinity was from
deep nested threads (where each patch was a reply to the
previous one) to shallow threads (where each patch in a
series is a reply to the cover-letter). That shouldn't come
into play at all with a single patch.
Is there a doc covering the process which I could follow and
try to reproduce (and hopefully help to avoid this)?
For me, this is from batcave01 (so ancient rhel7 version) and
all I did was commit something, and do:
git send-email --compose --suppress-cc=all
--to=infrastructure(a)lists.fedoraproject.org --from kevin(a)scrye.com
--no-cc --no-bcc HEAD^
I can try with a more recent one next time...
kevin
2:23 p.m.
Hi Kevin,
Kevin Fenzi wrote:
On Thu, Oct 31, 2019 at 02:30:49AM -0400, Todd Zullinger wrote:
> Kevin Fenzi wrote:
>> On Tue, Oct 29, 2019 at 02:19:00PM -0400, Stephen John
>> Smoogen wrote:
>>> I didn't see anything patched on there so I am not sure
>>> what to review.
>>
>> git-send-email always for some reason sends the actual
>> patch as a followup. So, look for the first followup to
>> the orig message in the thread...
>
> Hmm, that's not behavior I've ever seen from git send-email.
> Is the git format-patch --thread option or format.thread
> config variable set along with the --thread option to git
> send-email? The defaults generally work.
...
For me, this is from batcave01 (so ancient rhel7 version) and
all I did was commit something, and do:
git send-email --compose --suppress-cc=all
--to=infrastructure(a)lists.fedoraproject.org --from kevin(a)scrye.com
--no-cc --no-bcc HEAD^
Ahh, this is from the `--compose` option. That's probably
better to use only when you're sending a patch series rather
than a single patch. (It's more or less the equivalent of
using the `--cover-letter` option with `git format-patch`.
For a single patch, the `--annotate` option is probably
better suited. That opens an editor with the patch where
you can enter some description of the patch (ideally between
the `---` and the diffstat, which ensures that text isn't
included it the patch is applied with `git am`). That way
you end up with a single message.
I looked at the docs for `git send-email` in EL7 and
`--annotate` is there, so it should work in that version.
--
Todd
5:56 p.m.
On Fri, Nov 01, 2019 at 03:23:22PM -0400, Todd Zullinger wrote:
Hi Kevin,
Ahh, this is from the `--compose` option. That's probably
better to use only when you're sending a patch series rather
than a single patch. (It's more or less the equivalent of
using the `--cover-letter` option with `git format-patch`.
For a single patch, the `--annotate` option is probably
better suited. That opens an editor with the patch where
you can enter some description of the patch (ideally between
the `---` and the diffstat, which ensures that text isn't
included it the patch is applied with `git am`). That way
you end up with a single message.
I looked at the docs for `git send-email` in EL7 and
`--annotate` is there, so it should work in that version.
Ah ha. Yeah, I was thinking --compose would let me add the description.
:)
will try --annotate next time.
(Or hopefully we have PR's before then)
kevin
6:11 p.m.
Kevin Fenzi wrote:
Ah ha. Yeah, I was thinking --compose would let me add the
description.
:)
Indeed, having --compose and --annotate is not the clearest
set of options.
I believe that upstream git considers it a misfeature to
have had git send-email handle any of the patch generation
bits. Using git format-patch and then sending the results
with git send-email after any edits and review is more often
recommended.
(Or hopefully we have PR's before then)
I always like solving problems by arranging to not have them
in the first place. Good luck on that project!
--
Todd
2:09 p.m.
+1 .. now I found it.
On Tue, 29 Oct 2019 at 14:19, Stephen John Smoogen <smooge(a)gmail.com> wrote:
I didn't see anything patched on there so I am not sure what to review.
On Tue, 29 Oct 2019 at 09:49, Dusty Mabe <dusty(a)dustymabe.com> wrote:
>
> [PATCH] bodhi-pungi: only run multi-arch SB on f31+
> _______________________________________________
> infrastructure mailing list -- infrastructure(a)lists.fedoraproject.org
> To unsubscribe send an email to infrastructure-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedora...
--
Stephen J Smoogen.
--
Stephen J Smoogen.
5:29 a.m.
pushed and ran playbook
Thanks!
On 10/29/19 3:09 PM, Stephen John Smoogen wrote:
> +1 .. now I found it.
>
> On Tue, 29 Oct 2019 at 14:19, Stephen John Smoogen <smooge(a)gmail.com> wrote:
>>
>> I didn't see anything patched on there so I am not sure what to review.
>>
>> On Tue, 29 Oct 2019 at 09:49, Dusty Mabe <dusty(a)dustymabe.com> wrote:
>>>
>>> [PATCH] bodhi-pungi: only run multi-arch SB on f31+
>>> _______________________________________________
>>> infrastructure mailing list -- infrastructure(a)lists.fedoraproject.org
>>> To unsubscribe send an email to infrastructure-leave(a)lists.fedoraproject.org
>>> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>>> List Archives:
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedora...
>>
>>
>>
>> --
>> Stephen J Smoogen.
>
>
>
1635
days inactive
1638
days old
infrastructure@lists.fedoraproject.org
11 comments
4 participants
participants (4)
-
Dusty Mabe -
Kevin Fenzi -
Stephen John Smoogen -
Todd Zullinger