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 %] }, ] }
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@dustymabe.com wrote:
[PATCH] bodhi-pungi: only run multi-arch SB on f31+ _______________________________________________ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-leave@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.fedorapro...
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@dustymabe.com wrote:
[PATCH] bodhi-pungi: only run multi-arch SB on f31+ _______________________________________________ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-leave@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.fedorapro...
-- Stephen J Smoogen. _______________________________________________ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-leave@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.fedorapro...
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)?
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@lists.fedoraproject.org --from kevin@scrye.com --no-cc --no-bcc HEAD^
I can try with a more recent one next time...
kevin
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@lists.fedoraproject.org --from kevin@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.
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
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!
+1 .. now I found it.
On Tue, 29 Oct 2019 at 14:19, Stephen John Smoogen smooge@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@dustymabe.com wrote:
[PATCH] bodhi-pungi: only run multi-arch SB on f31+ _______________________________________________ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-leave@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.fedorapro...
-- Stephen J Smoogen.
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@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@dustymabe.com wrote:
[PATCH] bodhi-pungi: only run multi-arch SB on f31+ _______________________________________________ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-leave@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.fedorapro...
-- Stephen J Smoogen.
infrastructure@lists.fedoraproject.org
-
Dusty Mabe -
Kevin Fenzi -
Stephen John Smoogen -
Todd Zullinger