On Thu, Jul 9, 2026 at 8:07 PM Mike Crowe via lists.openembedded.org <[email protected]> wrote: > > Hi Yoann, > > On Tuesday 07 July 2026 at 10:54:38 +0200, Yoann Congal wrote: > > On Mon Jun 29, 2026 at 6:50 PM CEST, Mike Crowe via lists.openembedded.org > > wrote: > > > From: Mike Crowe <[email protected]> > > > > > > Take upstream patch that stops sysoptions.h unconditionally turning > > > DROPBEAR_DSS back on even when it has been disabled (which is the > > > default). > > > > > > Signed-off-by: Mike Crowe <[email protected]> > > > --- > > > ...PBEAR_DSS-is-only-forced-for-fuzzing.patch | 29 +++++++++++++++++++ > > > .../recipes-core/dropbear/dropbear_2022.83.bb | 1 + > > > 2 files changed, 30 insertions(+) > > > create mode 100644 > > > meta/recipes-core/dropbear/dropbear/0001-Fix-so-DROPBEAR_DSS-is-only-forced-for-fuzzing.patch > > > > > > diff --git > > > a/meta/recipes-core/dropbear/dropbear/0001-Fix-so-DROPBEAR_DSS-is-only-forced-for-fuzzing.patch > > > > > > b/meta/recipes-core/dropbear/dropbear/0001-Fix-so-DROPBEAR_DSS-is-only-forced-for-fuzzing.patch > > > new file mode 100644 > > > index 0000000000..b9705a2bbb > > > --- /dev/null > > > +++ > > > b/meta/recipes-core/dropbear/dropbear/0001-Fix-so-DROPBEAR_DSS-is-only-forced-for-fuzzing.patch > > > @@ -0,0 +1,29 @@ > > > +From c7dfaebd5f6a4cde4198f4d2a7baabaa1f632274 Mon Sep 17 00:00:00 2001 > > > +From: Matt Johnston <[email protected]> > > > +Date: Tue, 6 Dec 2022 22:34:11 +0800 > > > +Subject: [PATCH] Fix so DROPBEAR_DSS is only forced for fuzzing > > > + > > > +Regression from 787391ea3b5af2acf5e3c83372510f0c79477ad7, > > > +was missing fuzzing conditional > > > + > > > +Upstream-Status: Backport > > > [https://github.com/mkj/dropbear/commit/c043efb47c3173072fa636ca0da0d19875d4511f] > > > > This patch is missing your signed-off-by. > > Well, it's not my patch. :) > > I wasn't aware that I was expected to add one to the patch itself for a > backport. > > https://docs.yoctoproject.org/scarthgap/contributor-guide/recipe-style-guide.html > doesn't seem to say that a SoB should be added to the patch. It does say: > > | Of course, if another person later takes care of submitting this patch > | upstream, the status should be changed to Submitted [where], and an > | additional Signed-off-by: line should be added to the patch by the person > | claiming responsibility for upstreaming. > > which sort of implies that a SoB should be added for original patches that > are suitable for upstreaming but this patch is a backport which originated > upstream (without a SoB) which isn't the same thing. > > Adding a SoB to an unmodified upstream backport patch feels like > appropriation on my part, but I can do so if that's the policy. >
You're certifying that the patch you're submitting is appropriately licensed; it says nothing about who authored it. -- Alex Kiernan
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#240591): https://lists.openembedded.org/g/openembedded-core/message/240591 Mute This Topic: https://lists.openembedded.org/mt/120033783/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
