From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: redhat.com, ip: 209.132.183.28, mailfrom: lersek@redhat.com) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by groups.io with SMTP; Wed, 26 Jun 2019 05:18:34 -0700 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id AD9B2307D90D; Wed, 26 Jun 2019 12:18:22 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-117-47.ams2.redhat.com [10.36.117.47]) by smtp.corp.redhat.com (Postfix) with ESMTP id 4696C5C224; Wed, 26 Jun 2019 12:18:19 +0000 (UTC) Subject: Re: [edk2-devel] [PATCH v3 0/4] OvmfPkg: CSM boot fixes To: David Woodhouse , devel@edk2.groups.io References: <15ABBC9A305FBCEC.16820@groups.io> <536d4b904ecc507b84eaefd8c34510e72e38ec67.camel@infradead.org> From: "Laszlo Ersek" Message-ID: Date: Wed, 26 Jun 2019 14:18:19 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <536d4b904ecc507b84eaefd8c34510e72e38ec67.camel@infradead.org> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.48]); Wed, 26 Jun 2019 12:18:22 +0000 (UTC) X-Groupsio-MsgNum: 42891 Content-Type: multipart/mixed; boundary="------------B50A753B176A00C1075AD014" Content-Language: en-US --------------B50A753B176A00C1075AD014 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 06/26/19 13:43, David Woodhouse wrote: > On Wed, 2019-06-26 at 12:37 +0100, David Woodhouse wrote: >> For v3, leaving out the cosmetic parts that touch code outside OvmfPkg. >> This series is now purely the correctness fixes within OvmfPkg which are >> required to make CSM boots work properly again. >> >> The first two patches allow NVMe and VirtIO disks to be used as Legacy >> boot targets, since nobody really uses IDE any more. >> >> The third avoids using QemuVideoDxe when we have CSM, as the INT 10h >> shim installed by QemuVideoDxe conflicts with a real legacy video BIOS >> being installed. >> >> Finally, avoid placing PCI BARs above 4GiB. Strictly speaking we only >> need this for PCI devices which might be natively supported by the CSM >> BIOS, like NVMe. Devices with an OpRom already get special-cased to stay >> below 4GiB. But an IncompatiblePciDeviceSupportProtocol implementation >> doesn't get to see the PCI device class; only the vendor/device IDs so >> we can't use it for that purpose to downgrade more selectively. Instead, >> just default to putting everything below 4GiB. > > Btw, these four patches alone are pushed to > http://git.infradead.org/users/dwmw2/edk2.git/shortlog/refs/heads/csm-ovmfpkg > > But... this cover letter has been detached from the thread with the patches. > When git-send-email created them, the cover letter had > Message-Id: <20190626113742.819933-1-dwmw2@infradead.org> > > All the subsequent patches had: > References: <20190626113742.819933-1-dwmw2@infradead.org> > > But they all get their message-id corrupted on the way through the > list, it seems. So the References: headers in the patches are > referencing a Message-ID: that no longer exists. > > Why does the list do this? Can it be turned off, please? Yes, it can be turned off. It is a common hiccup for new subscribers (the groups.io default is broken). I think we meant to document it somewhere (outside of the mailing list archive), and I guess we may have even done so, but currently a non-list reference escapes me. Anyway, please see the attached messages -- and then please log in to your groups.io account, locate Account Preferences Email Preferences My Posts I always want copies of my own emails and *uncheck* it. Because, in reality, that checkbox stands for "munge my Message-IDs so that GMail doesn't de-duplicate my own emails when the list reflects them to me". But, two wrongs don't make a right :/ Thanks, Laszlo > Or at the very least, can it be set to mangle References: and In-Reply- > To: headers to match the corruption it introduces into the Message-Id: > headers and at least keep threading intact? That still doesn't keep > things in sync with messages that *don't* go through the list though, > so fixing it not to do any corruption at all would be best. > --------------B50A753B176A00C1075AD014 Content-Type: message/rfc822; name="Attached Message" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Attached Message" Subject: Re: [edk2-devel] Groups.io Eval - Step 9 From: Laszlo Ersek To: Stephano Cetola Cc: devel@edk2.groups.io References: <7969c322-a5ae-fa7d-73ee-600aae34c5de@redhat.com> Message-ID: <578e211a-e5f2-6195-46b2-df25ebea0fce@redhat.com> Date: Wed, 6 Mar 2019 10:52:48 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Hi Stephano, On 03/05/19 22:29, Laszlo Ersek wrote: > Thanks. I'll check step 12 soon. > >> (12) I check both locally, and in the web archive, whether the >> threading is nested (that is, not flattened), over steps (09) >> through (11). Unfortunately, currently fails the threading / nesting requirement. This is how the thread looks like, considering those copies of the messages that we sent to each other directly: "I'm emailing the list and CC'ing Laszlo." Message-ID: <-----+ | "This is indeed suitable for filtering." | In-Reply-To: ---+ Message-ID: <7969c322-a5ae-fa7d-73ee-600aae34c5de@redhat.com> <------------------------+ | "This email should cover us for step 11" | In-Reply-To: <7969c322-a5ae-fa7d-73ee-600aae34c5de@redhat.com> ----------------------+ Message-ID: <------+ | "Thanks. I'll check step 12 soon" | In-Reply-To: ----+ Message-ID: As you can see, the following happened (correctly): - both your MUA (or SMTP server) and my MUA (or SMTP server) generated a fresh Message-ID header whenever a message was sent, - both your MUA (or SMTP server) and my MUA (or SMTP server) copied the Message-ID of the email being responded to into the "In-Reply-To" field of the response. These ensured a complete linkage for the thread, and indeed the thread appears with correct nesting in my personal mailbox. In turn, this is how the thread looks like, when we investigate those copies of the same messages that were reflected by the list (in other words, those that have the "List-Id: " header set): "I'm emailing the list and CC'ing Laszlo." Message-ID: <-----+ | "This is indeed suitable for filtering." | In-Reply-To: ---+ Message-ID: <15891DA65810CEBF.717@groups.io> !!! "This email should cover us for step 11" In-Reply-To: <7969c322-a5ae-fa7d-73ee-600aae34c5de@redhat.com> Message-ID: <------+ | "Thanks. I'll check step 12 soon" | In-Reply-To: ----+ Message-ID: <15892D4A5DAD2B11.29479@groups.io> !!! Please note the two Message-IDs that I marked with "!!!". did not honor the Message-IDs that my MUA (or SMTP server) generated: in the list-reflected copies, replaced those Message-IDs with new ones that it generated itself. (For some reason, did this only for messages that were sent by me.) As a result, in my list folder, the threading is broken. The message that you sent in response to mine (i.e. where you wrote "This email should cover us for step 11") does not chain to where I wrote "This is indeed suitable for filtering", in my list folder. This must be fixed -- must absolutely honor the original Message-IDs in *all* messages that it reflects --, otherwise threading will be broken in everyone's list folder. Correctly nested threading is also a requirement for posting patches to the list. (I realize that we might move the patch workflow to another medium, but that is a separate effort. We should not switch both services at the same time, but in stages.) ... Ahh, the following discussion entry indicates that falsifies the Message-ID field *only for the sender* (i.e., only for me in this case): https://groups.io/g/GroupManagersForum/message/8420 And they mean it as a workaround for a GMail bug: > What that option does is cause Groups.io to replace the message's > Message-ID field when sending it back to you. That's a recent change: > it used to replace the field in the copy sent to everyone else as > well. > > This only affects users whose email service (such as Gmail) hides > messages from you if you already have them, in your inbox or your Sent > folder. Changing the ID makes it a different message. This is obviously totally bonkers. GMail screws up threading (by de-duplicating messages reflected by the list back to the sender), so let's try to hack around that, via changing the message-id... and in the process, screw up threading in *conformant* MUAs?! This insanity must stop. I definitely need my own messages relfected to me, with the proper List-Id header, and with the original Message-ID intact. It's pure lunacy that bug compatibility with GMail should break correctly behaving MUAs. Do you know if has an account setting that says "send me copies with original Message-IDs"? ... Well, the text that I quoted above seems to refer to the following option: "Account | Preferences | Email Preferences | My Posts | I always want copies of my own emails". This is a good option, but it needs a sub-option where I can disable the Message-ID regeneration. Can we report a bug to ? (Because, yes, this is a bug, which they introduced intentionally for working around GMail's madness.) Thanks! Laszlo --------------B50A753B176A00C1075AD014 Content-Type: message/rfc822; name="Attached Message" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Attached Message" Return-Path: stephanoc@gmail.com Received: from zmta01.collab.prod.int.phx2.redhat.com (LHLO zmta01.collab.prod.int.phx2.redhat.com) (10.5.81.8) by zmail17.collab.prod.int.phx2.redhat.com with LMTP; Thu, 7 Mar 2019 19:54:41 -0500 (EST) Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by zmta01.collab.prod.int.phx2.redhat.com (Postfix) with ESMTP id 09BBB1868A3 for ; Thu, 7 Mar 2019 19:54:41 -0500 (EST) Received: by smtp.corp.redhat.com (Postfix) id 04E3660C5F; Fri, 8 Mar 2019 00:54:41 +0000 (UTC) Delivered-To: lersek@redhat.com Received: from mx1.redhat.com (ext-mx14.extmail.prod.ext.phx2.redhat.com [10.5.110.43]) by smtp.corp.redhat.com (Postfix) with ESMTPS id F3B7D60BE5 for ; Fri, 8 Mar 2019 00:54:40 +0000 (UTC) Received: from mail-ua1-f54.google.com (mail-ua1-f54.google.com [209.85.222.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 13F7F3092651 for ; Fri, 8 Mar 2019 00:54:40 +0000 (UTC) Received: by mail-ua1-f54.google.com with SMTP id s15so10859824uap.6 for ; Thu, 07 Mar 2019 16:54:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=EcmrY60oZFxGi9eXLsnTpo8HS5vMBvJXolv7kaaBK00=; b=sTUGGrLrLFUkrQU9qpNJ4pXbZdPDxGihNZmYDgUBhR6h/l+3yhSR/90b1z1AXOsxT8 T4k1tMICjPu44hhA+Z34nulXUUpTBVCrja9EAzVlQulIN3THC8Wvk8bBm7PwDpFTuZTl nNX1TI4tfj+Y8idzeM8Yn01GknVzMIsOe1A/xuIRbB2u5kjyoqI99ni0GOn37qBsEKtG R0bJrgEA5g9J9fS27b8S8qtvcqVAvgFyhScsxUDd3l3njanGHdH85tzjBNdxA5MfIBi/ MGU+1qon+J3BKKqxPPuyuqMXklgbvta4vLUWz7rBMTX4/5rgsTK6bl9CAvd1jImbyxNx BZVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=EcmrY60oZFxGi9eXLsnTpo8HS5vMBvJXolv7kaaBK00=; b=PbDE4wJjOsGqw/UN2WX3wtvNYbzwPB8bg+81f0ZXP4Ok4aSY4IpIjZ+4DyziSq4NjW Q2pNPNplTr3NmM1dfpnk2qjrEop5/3r7ZKEdGVlOpiWofOrIuY/p4mPSvZXRvnNIaIP5 G1rT9koDYa2XxNsAHCLGN7hMUrTh7Lk1rFM1K1OMPs8N0x4ZJN81MDgqyewxjbXaIQYT 02hGBQdRDZYqCUV6Qqep1kxrma+KPXJAO0tU5fO/yjvaOmmjedv+WxsJjn7VIMqiuTn7 SI0jfvQu9lqGQjK8nxrSG18Vocr78nDqsUVh3qJEJf/yRyCcPV9+yY6qIsAeXKf6E6/X nmdw== X-Gm-Message-State: APjAAAV0dD2gT0ezdoqjXBy9DpQUFFAzG473nd1lhK+TyBLQmoy9FNbV O/ZsuCaFjk0KTc1ndhM/mqHOLWMNt7LQcnF9dveN1zOe X-Google-Smtp-Source: APXvYqwzFRo0eaz3qQBobMVqxJdcnpZ0hHxkWyTJjHB9KtuqQdEJEL+absn4loE7ohOBhplwu5X92mBCEeAJ2gL2ytI= X-Received: by 2002:ab0:6556:: with SMTP id x22mr8372704uap.10.1552006479012; Thu, 07 Mar 2019 16:54:39 -0800 (PST) MIME-Version: 1.0 References: <7969c322-a5ae-fa7d-73ee-600aae34c5de@redhat.com> <578e211a-e5f2-6195-46b2-df25ebea0fce@redhat.com> In-Reply-To: <578e211a-e5f2-6195-46b2-df25ebea0fce@redhat.com> From: Stephano Cetola Date: Thu, 7 Mar 2019 16:54:28 -0800 Message-ID: Subject: Re: [edk2-devel] Groups.io Eval - Step 9 To: Laszlo Ersek Cc: devel@edk2.groups.io Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.43]); Fri, 08 Mar 2019 00:54:40 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.43]); Fri, 08 Mar 2019 00:54:40 +0000 (UTC) for IP:'209.85.222.54' DOMAIN:'mail-ua1-f54.google.com' HELO:'mail-ua1-f54.google.com' FROM:'stephanoc@gmail.com' RCPT:'' X-RedHat-Spam-Score: -0.11 (DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS) 209.85.222.54 mail-ua1-f54.google.com 209.85.222.54 mail-ua1-f54.google.com X-Scanned-By: MIMEDefang 2.84 on 10.5.110.43 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 On Wed, Mar 6, 2019 at 1:52 AM Laszlo Ersek wrote: > Do you know if has an account setting that says "send me > copies with original Message-IDs"? > > ... Well, the text that I quoted above seems to refer to the following > option: "Account | Preferences | Email Preferences | My Posts | I always > want copies of my own emails". This is a good option, but it needs a > sub-option where I can disable the Message-ID regeneration. > > Can we report a bug to ? (Because, yes, this is a bug, which > they introduced intentionally for working around GMail's madness.) As it turns out, I believe that check box is simply a poorly worded checkbox. From their GroupManagersForum: https://groups.io/g/GroupManagersForum/message/15410 > Groups.io never fails to send your own emailed posts back to your email. = Assuming of course that your subscription is set up to receive all messages= by email. I take this to mean that the default setting in their system is to *always* send all the emails to you, even those emails where you are the sender. > > The issue is that Gmail customarily "hides" them (puts them into your Sen= t folder, not your Inbox). So most Gmail users' impression (including those= using a POP or IMAP client) is that Groups.io isn't returning their messag= es - unless the Message-ID substitution option (I always want copies of my = own emails) in their Account Preferences is checked. So, in essence, that checkbox should have a parenthetical addendum: (munge my Message-ID). :) To fix this issue, we should simply need to uncheck that box. We should still see our emails, but the Message-IDs will no longer be changed. I'm going to subscribe with my linux.intel.com email and test this theory, but assuming it does work, I believe this will fix our Message-ID issue. Cheers, Stephano --------------B50A753B176A00C1075AD014 Content-Type: message/rfc822; name="Attached Message" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Attached Message" Return-Path: stephanoc@gmail.com Received: from zmta01.collab.prod.int.phx2.redhat.com (LHLO zmta01.collab.prod.int.phx2.redhat.com) (10.5.81.8) by zmail17.collab.prod.int.phx2.redhat.com with LMTP; Thu, 7 Mar 2019 20:15:23 -0500 (EST) Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by zmta01.collab.prod.int.phx2.redhat.com (Postfix) with ESMTP id 1955F1868A3 for ; Thu, 7 Mar 2019 20:15:23 -0500 (EST) Received: by smtp.corp.redhat.com (Postfix) id 14D9818B14; Fri, 8 Mar 2019 01:15:23 +0000 (UTC) Delivered-To: lersek@redhat.com Received: from mx1.redhat.com (ext-mx06.extmail.prod.ext.phx2.redhat.com [10.5.110.30]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 0F6EA60C5F for ; Fri, 8 Mar 2019 01:15:23 +0000 (UTC) Received: from mail-ua1-f45.google.com (mail-ua1-f45.google.com [209.85.222.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 32A46356F8 for ; Fri, 8 Mar 2019 01:15:22 +0000 (UTC) Received: by mail-ua1-f45.google.com with SMTP id r21so10866197uan.11 for ; Thu, 07 Mar 2019 17:15:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Oz7Jdk1+LUwd/AS9p/3XgrhB1zCHz4q+8v3QAan441k=; b=RNQbMSakfu3Xg0ExzMFvbXAWgO2vFIIoropVQakWfl9ilyESeEUuBne0poZGt1O76+ +ZU4tnhHYO06x3KnyBsTe7ccP7mzFmv/yi3iqHTvQPTIMlQChJ/z7BWPG2FFrGbydZus 6VMigVadvlZ6Y749lT4pcnhgQlLtOKpzEDKiLDugIAP5UDXSOP2q75lS4j5LHry1A5uA gFTUBnCZp5hhHSUXmnJ4YQXlF666s/EapBy2ieXoERgbWdquOstXDxb51+yY/61b7nQZ 2/trMoAJ7xuNDhVB4chFfOvQ8kZj3ObOhoPKVNb/5JK/XJNgvwhBkRatnEQB4Sf1cqmF Gzsg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Oz7Jdk1+LUwd/AS9p/3XgrhB1zCHz4q+8v3QAan441k=; b=WcMFLWNTlRT0LAeNv+Zaacn5pD4Q+2+rTaqdslNl1WeTrhcnUj7oFcrkJsmpwWg6bB Qx/bB5V0QqUXK/mhfZmkyyQS4r6/BirsEtDZwMOm1Uru97wwOwMx56ZPoBnfDzL3zNSg iZS6vui63HSK7itbgyfi/l4t8Vlv2Nzjn8nNLbYSxTirkjDU0h0rIzjR3guLSt3GFwDd ZjD0akLoImU/FzZJq9y9zqbOD9KIJBdyh7d9wTApZTUkWMjeHA3aGVtFrlf60eQt2fyX e4Efcjotex1QP1ZevkotCABfpmHghVH6eFXkAmAu86GfEjpzIj7AHwQddmzZlbGYNdMK dGsg== X-Gm-Message-State: APjAAAXCQpK9y/CbGxpONxGpDnFIz0K/AQMzNe7t2yvkzjDEDa5bX56C DT2HTTK2McFjGsafL+uBFTuIuw0RTcnv3OQws6vroA== X-Google-Smtp-Source: APXvYqxuTQziAY4wSvmMRULOBjge9CbBDmgfuySiTBl5rmG62J+yRcd2A+MLKit1p5zVLTy1Ut56ExqAZSsY52XjUog= X-Received: by 2002:a9f:3707:: with SMTP id z7mr8615534uad.25.1552007721099; Thu, 07 Mar 2019 17:15:21 -0800 (PST) MIME-Version: 1.0 References: <7969c322-a5ae-fa7d-73ee-600aae34c5de@redhat.com> <578e211a-e5f2-6195-46b2-df25ebea0fce@redhat.com> In-Reply-To: From: Stephano Cetola Date: Thu, 7 Mar 2019 17:15:10 -0800 Message-ID: Subject: Re: [edk2-devel] Groups.io Eval - Step 9 To: Laszlo Ersek Cc: devel@edk2.groups.io Content-Type: text/plain; charset="UTF-8" X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Fri, 08 Mar 2019 01:15:22 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Fri, 08 Mar 2019 01:15:22 +0000 (UTC) for IP:'209.85.222.45' DOMAIN:'mail-ua1-f45.google.com' HELO:'mail-ua1-f45.google.com' FROM:'stephanoc@gmail.com' RCPT:'' X-RedHat-Spam-Score: -0.11 (DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS) 209.85.222.45 mail-ua1-f45.google.com 209.85.222.45 mail-ua1-f45.google.com X-Scanned-By: MIMEDefang 2.78 on 10.5.110.30 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 On Thu, Mar 7, 2019 at 4:54 PM Stephano Cetola wrote: > I'm going to subscribe with my linux.intel.com email and test this > theory, but assuming it does work, I believe this will fix our > Message-ID issue. Verified. If I uncheck that box, my linux.intel.com email will still receive *all* emails (even those sent from me), however it will *not* munge the Message-ID. Let me know if you do not see similar results. I'm glad I used gmail (webmail) to test this. It is a terrible mailing-list-email experience, but is a more thorough test. :) Cheers, Stephano --------------B50A753B176A00C1075AD014--