qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Brad Smith <brad@comstyle.com>
To: "Daniel P. Berrangé" <berrange@redhat.com>,
	"Peter Maydell" <peter.maydell@linaro.org>
Cc: Thomas Huth <thuth@redhat.com>, Greg Kurz <groug@kaod.org>,
	QEMU Developers <qemu-devel@nongnu.org>,
	qemu-arm <qemu-arm@nongnu.org>, qemu-ppc <qemu-ppc@nongnu.org>,
	John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>,
	David Gibson <david@gibson.dropbear.id.au>
Subject: Re: [PATCH 3/3] dtc: Update to version 1.6.1
Date: Fri, 1 Oct 2021 13:54:32 -0400	[thread overview]
Message-ID: <9bbfbede-0b93-d9ea-cad9-2e7a32c0ebbf@comstyle.com> (raw)
In-Reply-To: <YVbYavVeV/OmYON6@redhat.com>

On 10/1/2021 5:44 AM, Daniel P. Berrangé wrote:

> On Fri, Oct 01, 2021 at 10:37:51AM +0100, Peter Maydell wrote:
>> On Fri, 1 Oct 2021 at 10:10, Daniel P. Berrangé <berrange@redhat.com> wrote:
>>> On Thu, Sep 30, 2021 at 09:10:12AM +0200, Thomas Huth wrote:
>>>> On 27/08/2021 14.09, Thomas Huth wrote:
>>>>> The dtc submodule is currently pointing to non-release commit. It's nicer
>>>>> if submodules point to release versions instead and since dtc 1.6.1 is
>>>>> available now, let's update to that version.
>>> Most of our supported platforms don't have version 1.6.1 available.
>>>
>>> As a general goal IMHO we should be seeking to eliminate bundling of
>>> 3rd party modules that are commonly available in distros. We've
>>> carried dtc for a hell of a long time, and if we keep updating our
>>> submodule we'll keep relyin on new features, and never be able to
>>> drop it because it will always be newer than what's in the distros.
>>>
>>> So personally I think we should never again update dtc and capstone
>>> modules. If we want to take adbantage of new features, then do that
>>> through conditional compilation, as we do for any of the other 3rd
>>> party libraries consumed.
>> I agree in general, but (per the commit message here) our dtc
>> submodule is currently pointing at some random not-a-release
>> commit in upstream dtc. We should at least move forward to
>> whatever the next released dtc after that is, before we say
>> "no more dtc updates".
> Yep, if we want to fix it onto an official version tag, that's
> OK, just not jumping right to very latest version. We might want
> to move it backwards to better align with what we're targetting
> in the support
>
> Best I can tell the distros currently have these versions:
>
>       - Alpine 3.14 - 1.6.1
>       - CentOS 8 - 1.6.0
>       - Debian 10 - 1.4.7
>       - Fedora 33 - 1.6.0
>       - OpenSUSE Leap 15.3 - 1.5.1
>       - Ubuntu 18.04 - 1.4.5
>       - FreeBSD Ports - 1.6.0
>       - OpenBSD Ports - 1.6.0
I already updated OpenBSD to 1.6.1.
>       - macOS HomeBrew - 1.6.1
>       - Windows MSys2 - 1.6.0
>
>
> Regards,
> Daniel


  parent reply	other threads:[~2021-10-01 17:58 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-27 12:08 [PATCH 0/3] dtc: Fixes for the fdt check and update submodule to 1.6.1 Thomas Huth
2021-08-27 12:08 ` [PATCH 1/3] meson.build: Fix the check for a usable libfdt Thomas Huth
2021-08-27 12:09 ` [PATCH 2/3] meson.build: Don't use internal libfdt if the user requested the system libfdt Thomas Huth
2021-08-27 13:05   ` Philippe Mathieu-Daudé
2021-08-27 12:09 ` [PATCH 3/3] dtc: Update to version 1.6.1 Thomas Huth
2021-09-30  7:10   ` Thomas Huth
2021-09-30 11:56     ` Greg Kurz
2021-10-01  1:42       ` David Gibson
2021-10-01  1:41     ` David Gibson
2021-10-01  9:08     ` Daniel P. Berrangé
2021-10-01  9:37       ` Peter Maydell
2021-10-01  9:44         ` Daniel P. Berrangé
2021-10-01  9:51           ` Peter Maydell
2021-10-01  9:57             ` Peter Maydell
2021-10-01 11:41           ` Thomas Huth
2021-10-02  4:35             ` David Gibson
2021-10-01 17:54           ` Brad Smith [this message]
2021-10-01 18:08             ` Brad Smith
2021-08-27 12:22 ` [PATCH 0/3] dtc: Fixes for the fdt check and update submodule to 1.6.1 Marc-André Lureau
2021-08-27 15:17 ` [PATCH 4/3] gitlab-ci: Don't try to use the system libfdt in the debian job Thomas Huth

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9bbfbede-0b93-d9ea-cad9-2e7a32c0ebbf@comstyle.com \
    --to=brad@comstyle.com \
    --cc=berrange@redhat.com \
    --cc=david@gibson.dropbear.id.au \
    --cc=glaubitz@physik.fu-berlin.de \
    --cc=groug@kaod.org \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-arm@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@nongnu.org \
    --cc=thuth@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).