[PATCH] ci: workaround broken opensuse leap 15.5 tirpc
Temporarily disable '-Wmissing-include-dirs' becuase the libtirpc pkg-confog file has a bogus include dir. The headers can fortunately still be found since they are in the system include dir. Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> --- ci/gitlab/builds.yml | 2 ++ ci/manifest.yml | 2 ++ 2 files changed, 4 insertions(+) diff --git a/ci/gitlab/builds.yml b/ci/gitlab/builds.yml index 9ae2225e35..e1ea87db1b 100644 --- a/ci/gitlab/builds.yml +++ b/ci/gitlab/builds.yml @@ -332,6 +332,7 @@ x86_64-opensuse-leap-15-prebuilt-env: optional: true allow_failure: false variables: + CFLAGS: -Wno-missing-include-dirs NAME: opensuse-leap-15 RPM: skip @@ -340,6 +341,7 @@ x86_64-opensuse-leap-15-local-env: needs: [] allow_failure: false variables: + CFLAGS: -Wno-missing-include-dirs IMAGE: registry.opensuse.org/opensuse/leap:15.5 NAME: opensuse-leap-15 RPM: skip diff --git a/ci/manifest.yml b/ci/manifest.yml index 0e5a17a2bd..2af8e62f28 100644 --- a/ci/manifest.yml +++ b/ci/manifest.yml @@ -205,6 +205,8 @@ targets: - arch: x86_64 variables: RPM: skip + # Keep until fix for: https://bugzilla.opensuse.org/show_bug.cgi?id=1216862 + CFLAGS: -Wno-missing-include-dirs opensuse-tumbleweed: jobs: -- 2.41.0
On Fri, Nov 03, 2023 at 09:37:19AM -0400, Daniel P. Berrangé wrote:
Temporarily disable '-Wmissing-include-dirs' becuase the libtirpc pkg-confog file has a bogus include dir. The headers can fortunately still be found since they are in the system include dir.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
even though this patch does not apply for me for some reason, no idea why, it is valid and our CI fails without it, hence Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
--- ci/gitlab/builds.yml | 2 ++ ci/manifest.yml | 2 ++ 2 files changed, 4 insertions(+)
diff --git a/ci/gitlab/builds.yml b/ci/gitlab/builds.yml index 9ae2225e35..e1ea87db1b 100644 --- a/ci/gitlab/builds.yml +++ b/ci/gitlab/builds.yml @@ -332,6 +332,7 @@ x86_64-opensuse-leap-15-prebuilt-env: optional: true allow_failure: false variables: + CFLAGS: -Wno-missing-include-dirs NAME: opensuse-leap-15 RPM: skip
@@ -340,6 +341,7 @@ x86_64-opensuse-leap-15-local-env: needs: [] allow_failure: false variables: + CFLAGS: -Wno-missing-include-dirs IMAGE: registry.opensuse.org/opensuse/leap:15.5 NAME: opensuse-leap-15 RPM: skip diff --git a/ci/manifest.yml b/ci/manifest.yml index 0e5a17a2bd..2af8e62f28 100644 --- a/ci/manifest.yml +++ b/ci/manifest.yml @@ -205,6 +205,8 @@ targets: - arch: x86_64 variables: RPM: skip + # Keep until fix for: https://bugzilla.opensuse.org/show_bug.cgi?id=1216862 + CFLAGS: -Wno-missing-include-dirs
opensuse-tumbleweed: jobs: -- 2.41.0 _______________________________________________ Devel mailing list -- devel@lists.libvirt.org To unsubscribe send an email to devel-leave@lists.libvirt.org
On Mon, Nov 06, 2023 at 10:19:23AM +0100, Martin Kletzander wrote:
On Fri, Nov 03, 2023 at 09:37:19AM -0400, Daniel P. Berrangé wrote:
Temporarily disable '-Wmissing-include-dirs' becuase the libtirpc pkg-confog file has a bogus include dir. The headers can fortunately still be found since they are in the system include dir.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
even though this patch does not apply for me for some reason, no idea why, it is valid and our CI fails without it, hence
Ah, since the switch to the new ML I cannot apply any patch using git am: warning: quoted CRLF detected Applying: ci: workaround broken opensuse leap 15.5 tirpc Using index info to reconstruct a base tree... error: patch failed: ci/gitlab/builds.yml:332 error: ci/gitlab/builds.yml: patch does not apply error: patch failed: ci/manifest.yml:205
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
--- ci/gitlab/builds.yml | 2 ++ ci/manifest.yml | 2 ++ 2 files changed, 4 insertions(+)
diff --git a/ci/gitlab/builds.yml b/ci/gitlab/builds.yml index 9ae2225e35..e1ea87db1b 100644 --- a/ci/gitlab/builds.yml +++ b/ci/gitlab/builds.yml @@ -332,6 +332,7 @@ x86_64-opensuse-leap-15-prebuilt-env: optional: true allow_failure: false variables: + CFLAGS: -Wno-missing-include-dirs NAME: opensuse-leap-15 RPM: skip
@@ -340,6 +341,7 @@ x86_64-opensuse-leap-15-local-env: needs: [] allow_failure: false variables: + CFLAGS: -Wno-missing-include-dirs IMAGE: registry.opensuse.org/opensuse/leap:15.5 NAME: opensuse-leap-15 RPM: skip diff --git a/ci/manifest.yml b/ci/manifest.yml index 0e5a17a2bd..2af8e62f28 100644 --- a/ci/manifest.yml +++ b/ci/manifest.yml @@ -205,6 +205,8 @@ targets: - arch: x86_64 variables: RPM: skip + # Keep until fix for: https://bugzilla.opensuse.org/show_bug.cgi?id=1216862 + CFLAGS: -Wno-missing-include-dirs
opensuse-tumbleweed: jobs: -- 2.41.0 _______________________________________________ Devel mailing list -- devel@lists.libvirt.org To unsubscribe send an email to devel-leave@lists.libvirt.org
On Mon, Nov 06, 2023 at 10:37:28AM +0100, Martin Kletzander wrote:
On Mon, Nov 06, 2023 at 10:19:23AM +0100, Martin Kletzander wrote:
On Fri, Nov 03, 2023 at 09:37:19AM -0400, Daniel P. Berrangé wrote:
Temporarily disable '-Wmissing-include-dirs' becuase the libtirpc pkg-confog file has a bogus include dir. The headers can fortunately still be found since they are in the system include dir.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
even though this patch does not apply for me for some reason, no idea why, it is valid and our CI fails without it, hence
Ah, since the switch to the new ML I cannot apply any patch using git am:
warning: quoted CRLF detected Applying: ci: workaround broken opensuse leap 15.5 tirpc Using index info to reconstruct a base tree... error: patch failed: ci/gitlab/builds.yml:332 error: ci/gitlab/builds.yml: patch does not apply error: patch failed: ci/manifest.yml:205
Odd, I don't see any problems applying this patch from the ML, nor other patches recently posted. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
On Mon, Nov 06, 2023 at 10:37:28AM +0100, Martin Kletzander wrote:
On Mon, Nov 06, 2023 at 10:19:23AM +0100, Martin Kletzander wrote:
On Fri, Nov 03, 2023 at 09:37:19AM -0400, Daniel P. Berrangé wrote:
Temporarily disable '-Wmissing-include-dirs' becuase the libtirpc pkg-confog file has a bogus include dir. The headers can fortunately still be found since they are in the system include dir.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
even though this patch does not apply for me for some reason, no idea why, it is valid and our CI fails without it, hence
Ah, since the switch to the new ML I cannot apply any patch using git am:
warning: quoted CRLF detected Applying: ci: workaround broken opensuse leap 15.5 tirpc Using index info to reconstruct a base tree... error: patch failed: ci/gitlab/builds.yml:332 error: ci/gitlab/builds.yml: patch does not apply error: patch failed: ci/manifest.yml:205
Yeah, both me and Laine noticed this the other day. Patches look fine in mutt, but if you save them to a file they end up looking all wonky (see attached file for an example) and 'git am' won't like them. -- Andrea Bolognani / Red Hat / Virtualization
On Mon, Nov 06, 2023 at 01:47:20AM -0800, Andrea Bolognani wrote:
On Mon, Nov 06, 2023 at 10:37:28AM +0100, Martin Kletzander wrote:
On Mon, Nov 06, 2023 at 10:19:23AM +0100, Martin Kletzander wrote:
On Fri, Nov 03, 2023 at 09:37:19AM -0400, Daniel P. Berrangé wrote:
Temporarily disable '-Wmissing-include-dirs' becuase the libtirpc pkg-confog file has a bogus include dir. The headers can fortunately still be found since they are in the system include dir.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
even though this patch does not apply for me for some reason, no idea why, it is valid and our CI fails without it, hence
Ah, since the switch to the new ML I cannot apply any patch using git am:
warning: quoted CRLF detected Applying: ci: workaround broken opensuse leap 15.5 tirpc Using index info to reconstruct a base tree... error: patch failed: ci/gitlab/builds.yml:332 error: ci/gitlab/builds.yml: patch does not apply error: patch failed: ci/manifest.yml:205
Yeah, both me and Laine noticed this the other day. Patches look fine in mutt, but if you save them to a file they end up looking all wonky (see attached file for an example) and 'git am' won't like them.
Well that's strange. The version I sent was Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit What you have attached is Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Meanwhile when downloading from the archives Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable IOW, something in the mail chain is screwing around with the content. Aside from harming git am, this is almost certainly going to doom DKIM signatures and GPG signatures covering the content. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
On Mon, Nov 06, 2023 at 09:58:02AM +0000, Daniel P. Berrangé wrote:
On Mon, Nov 06, 2023 at 01:47:20AM -0800, Andrea Bolognani wrote:
On Mon, Nov 06, 2023 at 10:37:28AM +0100, Martin Kletzander wrote:
Ah, since the switch to the new ML I cannot apply any patch using git am:
warning: quoted CRLF detected Applying: ci: workaround broken opensuse leap 15.5 tirpc Using index info to reconstruct a base tree... error: patch failed: ci/gitlab/builds.yml:332 error: ci/gitlab/builds.yml: patch does not apply error: patch failed: ci/manifest.yml:205
Yeah, both me and Laine noticed this the other day. Patches look fine in mutt, but if you save them to a file they end up looking all wonky (see attached file for an example) and 'git am' won't like them.
Well that's strange.
The version I sent was
Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit
What you have attached is
Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64
Meanwhile when downloading from the archives
Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable
IOW, something in the mail chain is screwing around with the content.
Aside from harming git am, this is almost certainly going to doom DKIM signatures and GPG signatures covering the content.
So does that mean that the issue is server-side? I'm pretty sure Laine, Martin and I are all fetching emails using different tools, so that would sound more plausible, but it's weird that things apparently work fine for you? -- Andrea Bolognani / Red Hat / Virtualization
On Mon, Nov 06, 2023 at 02:21:16AM -0800, Andrea Bolognani wrote:
On Mon, Nov 06, 2023 at 09:58:02AM +0000, Daniel P. Berrangé wrote:
On Mon, Nov 06, 2023 at 01:47:20AM -0800, Andrea Bolognani wrote:
On Mon, Nov 06, 2023 at 10:37:28AM +0100, Martin Kletzander wrote:
Ah, since the switch to the new ML I cannot apply any patch using git am:
warning: quoted CRLF detected Applying: ci: workaround broken opensuse leap 15.5 tirpc Using index info to reconstruct a base tree... error: patch failed: ci/gitlab/builds.yml:332 error: ci/gitlab/builds.yml: patch does not apply error: patch failed: ci/manifest.yml:205
Yeah, both me and Laine noticed this the other day. Patches look fine in mutt, but if you save them to a file they end up looking all wonky (see attached file for an example) and 'git am' won't like them.
Well that's strange.
The version I sent was
Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit
What you have attached is
Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64
Meanwhile when downloading from the archives
Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable
IOW, something in the mail chain is screwing around with the content.
Aside from harming git am, this is almost certainly going to doom DKIM signatures and GPG signatures covering the content.
So does that mean that the issue is server-side? I'm pretty sure Laine, Martin and I are all fetching emails using different tools, so that would sound more plausible, but it's weird that things apparently work fine for you?
I guess I tested the wrong mail. I can apply patches from Laine, but I cannot apply from Michal. I think the trigger is non-ASCII7 characters (ie accents) in the sender name (or possibly the Signed-off-by), causing software to re-encode turn the message into base64 With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
On Mon, Nov 06, 2023 at 10:26:36AM +0000, Daniel P. Berrangé wrote:
On Mon, Nov 06, 2023 at 02:21:16AM -0800, Andrea Bolognani wrote:
So does that mean that the issue is server-side? I'm pretty sure Laine, Martin and I are all fetching emails using different tools, so that would sound more plausible, but it's weird that things apparently work fine for you?
I guess I tested the wrong mail. I can apply patches from Laine, but I cannot apply from Michal.
I think the trigger is non-ASCII7 characters (ie accents) in the sender name (or possibly the Signed-off-by), causing software to re-encode turn the message into base64
Until this is sorted out, passing --quoted-cr=strip to 'git am' seems to do the trick. -- Andrea Bolognani / Red Hat / Virtualization
On 11/6/23 11:54, Andrea Bolognani wrote:
On Mon, Nov 06, 2023 at 10:26:36AM +0000, Daniel P. Berrangé wrote:
On Mon, Nov 06, 2023 at 02:21:16AM -0800, Andrea Bolognani wrote:
So does that mean that the issue is server-side? I'm pretty sure Laine, Martin and I are all fetching emails using different tools, so that would sound more plausible, but it's weird that things apparently work fine for you?
I guess I tested the wrong mail. I can apply patches from Laine, but I cannot apply from Michal.
I think the trigger is non-ASCII7 characters (ie accents) in the sender name (or possibly the Signed-off-by), causing software to re-encode turn the message into base64
Until this is sorted out, passing
--quoted-cr=strip
to 'git am' seems to do the trick.
Alternatively, might as well start sending base64 encoded patches, list re-encodes them anyway: git send-email --transfer-encoding=base64 ... Michal
On Mon, Nov 06, 2023 at 12:45:22PM +0100, Michal Prívozník wrote:
On 11/6/23 11:54, Andrea Bolognani wrote:
On Mon, Nov 06, 2023 at 10:26:36AM +0000, Daniel P. Berrangé wrote:
On Mon, Nov 06, 2023 at 02:21:16AM -0800, Andrea Bolognani wrote:
So does that mean that the issue is server-side? I'm pretty sure Laine, Martin and I are all fetching emails using different tools, so that would sound more plausible, but it's weird that things apparently work fine for you?
I guess I tested the wrong mail. I can apply patches from Laine, but I cannot apply from Michal.
I think the trigger is non-ASCII7 characters (ie accents) in the sender name (or possibly the Signed-off-by), causing software to re-encode turn the message into base64
Until this is sorted out, passing
--quoted-cr=strip
to 'git am' seems to do the trick.
Alternatively, might as well start sending base64 encoded patches, list re-encodes them anyway:
git send-email --transfer-encoding=base64 ...
Please don't. base64 encoding is horrible if someone needs to just view mbox contents directly. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
On 11/6/23 7:16 AM, Daniel P. Berrangé wrote:
On Mon, Nov 06, 2023 at 12:45:22PM +0100, Michal Prívozník wrote:
On 11/6/23 11:54, Andrea Bolognani wrote:
On Mon, Nov 06, 2023 at 10:26:36AM +0000, Daniel P. Berrangé wrote:
On Mon, Nov 06, 2023 at 02:21:16AM -0800, Andrea Bolognani wrote:
So does that mean that the issue is server-side? I'm pretty sure Laine, Martin and I are all fetching emails using different tools, so that would sound more plausible, but it's weird that things apparently work fine for you?
I guess I tested the wrong mail. I can apply patches from Laine, but I cannot apply from Michal.
I think the trigger is non-ASCII7 characters (ie accents) in the sender name (or possibly the Signed-off-by), causing software to re-encode turn the message into base64
Until this is sorted out, passing
--quoted-cr=strip
to 'git am' seems to do the trick.
Alternatively, might as well start sending base64 encoded patches, list re-encodes them anyway:
git send-email --transfer-encoding=base64 ...
Please don't. base64 encoding is horrible if someone needs to just view mbox contents directly.
Maybe Michal just forgot the </s> at the end of his comment? Yeah, there have been occasions when I was doing some random thing and clicked on a link that led to a page that was just base64, and it really is not a pleasing experience. Seriously, if accented characters in mail wasn't triggering this before, then hopefully it's possible to make it work correctly now with the "newer better stronger faster mailman" (Copyright (c) Daft Punk) <whatyearisthis.gif>
On Fri, Nov 03, 2023 at 09:37:19AM -0400, Daniel P. Berrangé wrote:
Temporarily disable '-Wmissing-include-dirs' becuase the libtirpc pkg-confog file has a bogus include dir. The
pkg-config
+++ b/ci/manifest.yml @@ -205,6 +205,8 @@ targets: - arch: x86_64 variables: RPM: skip + # Keep until fix for: https://bugzilla.opensuse.org/show_bug.cgi?id=1216862 + CFLAGS: -Wno-missing-include-dirs
Thanks for filing the bug. Assuming that you have tried this in CI and it did what it was supposed to, Reviewed-by: Andrea Bolognani <abologna@redhat.com> -- Andrea Bolognani / Red Hat / Virtualization
participants (5)
-
Andrea Bolognani -
Daniel P. Berrangé -
Laine Stump -
Martin Kletzander -
Michal Prívozník