From: Florian Fainelli <f.fainelli@gmail.com>
To: Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
Arnout Vandecappelle <arnout@mind.be>
Cc: d.lang@abatec.at, marcin@bis.org.pl,
"Yann E. MORIN" <yann.morin.1998@free.fr>,
buildroot@buildroot.org
Subject: Re: [Buildroot] Indicating upstream status [was: [PATCH] package/bluez5_utils: Fix builds with musl-libc]
Date: Wed, 29 Mar 2023 05:39:44 -0700 [thread overview]
Message-ID: <f4e1e805-4ab0-e187-8001-c5cfa9c0be00@gmail.com> (raw)
In-Reply-To: <20230329112855.6110cf8d@windsurf>
On 3/29/2023 2:28 AM, Thomas Petazzoni wrote:
> On Wed, 29 Mar 2023 11:06:47 +0200
> Arnout Vandecappelle <arnout@mind.be> wrote:
>
>> Yeah, that's why I propose "Upstream:" - it's generic enough to cover all of
>> these cases. The contents can be freeform I think, check-package should just
>> check that the Upstream tag is present. And the documentation should give
>> examples of the five cases you mention.
>
> Sure.
Yocto uses the following format [1]:
Upstream-status:
(Pending|Submitted|Accepted|Backport|Denied|Inappropriate [reason])
would you want to adopt something similar? OpenWrt to some extent does
something like that as well although in a less unified fashion,
sometimes the patches are placed in a specific patch directory
(backport-x.y.z, upstream-x.y.z) and sometimes that information is
placed in the patch file itself.
[1]:
http://wiki.yoctoproject.org/wiki/Best_Known_Methods_%28BKMs%29_for_Package_Updating#Patch_Comments
>
>> The "patch taken from downstream" is the only one which doesn't fit in the
>> "Upstream" thing. But it's also a situation we don't really like: we basically
>> don't want local patches, and a patch taken from some other distro _is_ a local
>> patch.
>
> The reality is that we have such patches (for example to fix musl build
> issues), and we somehow have to live with them.
>
> Thomas
--
Florian
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
next prev parent reply other threads:[~2023-03-29 12:39 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-26 13:09 [Buildroot] [PATCH] package/bluez5_utils: Fix builds with musl-libc Florian Fainelli
2023-03-28 20:25 ` Yann E. MORIN
2023-03-29 8:44 ` [Buildroot] Indicating upstream status [was: [PATCH] package/bluez5_utils: Fix builds with musl-libc] Arnout Vandecappelle
2023-03-29 8:50 ` Thomas Petazzoni via buildroot
2023-03-29 9:06 ` Arnout Vandecappelle
2023-03-29 9:28 ` Thomas Petazzoni via buildroot
2023-03-29 12:39 ` Florian Fainelli [this message]
2023-03-30 7:03 ` Arnout Vandecappelle
2023-03-30 12:21 ` Thomas Petazzoni via buildroot
2023-03-30 12:33 ` Arnout Vandecappelle
2023-03-31 7:28 ` Thomas Petazzoni via buildroot
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=f4e1e805-4ab0-e187-8001-c5cfa9c0be00@gmail.com \
--to=f.fainelli@gmail.com \
--cc=arnout@mind.be \
--cc=buildroot@buildroot.org \
--cc=d.lang@abatec.at \
--cc=marcin@bis.org.pl \
--cc=thomas.petazzoni@bootlin.com \
--cc=yann.morin.1998@free.fr \
/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