* [PATCH] fixed typos in kubernetes recipe
@ 2022-09-20 11:34 Guenther Meyer
2022-09-20 12:03 ` [meta-virtualization] " Bruce Ashfield
0 siblings, 1 reply; 5+ messages in thread
From: Guenther Meyer @ 2022-09-20 11:34 UTC (permalink / raw)
To: meta-virtualization
[-- Attachment #1.1: Type: text/plain, Size: 414 bytes --]
Hi,
I had a problem building the kubernetes package after upgrading to
kirkstone, the error is also documented here:
https://errors.yoctoproject.org/Errors/Details/657132/
The typo is still present in the master branch.
A patch to fix this is attached.
I don't know if this is the correct way to submit a patch, as this is
my first contribution. So feel free to correct me, if I'm wrong.
Guenther
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: 0001-kubernetes-fixed-typos.patch --]
[-- Type: text/x-patch, Size: 1928 bytes --]
From 7ec9bdc39ead89446aa7063a48afe8eeb3cce029 Mon Sep 17 00:00:00 2001
From: Guenther Meyer <g.meyer@signum-media.de>
Date: Tue, 20 Sep 2022 13:04:06 +0200
Subject: [PATCH] kubernetes: fixed typos
After upgrading from honister to kirkstone the build always failed
during the package_write_ipk step, because the package name has
been overwritten because of the typo in FILES.
While investigating, I discovered another typo in class-devupstream.
Signed-off-by: Guenther Meyer <g.meyer@signum-media.de>
---
recipes-containers/kubernetes/kubernetes_git.bb | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/recipes-containers/kubernetes/kubernetes_git.bb b/recipes-containers/kubernetes/kubernetes_git.bb
index 96cae5c..170a938 100644
--- a/recipes-containers/kubernetes/kubernetes_git.bb
+++ b/recipes-containers/kubernetes/kubernetes_git.bb
@@ -13,7 +13,7 @@ PE = "1"
BBCLASSEXTEND = "devupstream:target"
LIC_FILES_CHKSUM:class-devupstream = "file://src/import/LICENSE;md5=3b83ef96387f14655fc854ddc3c6bd57"
DEFAULT_PREFERENCE:class-devupstream = "-1"
-SRC_URI:classedevupstream = "git://github.com/kubernetes/kubernetes.git;branch=master;name=kubernetes;protocol=https \
+SRC_URI:class-devupstream = "git://github.com/kubernetes/kubernetes.git;branch=master;name=kubernetes;protocol=https \
git://github.com/kubernetes/release;branch=master;name=kubernetes-release;destsuffix=git/release;protocol=https \
"
SRCREV_kubernetes:class-devupstream = "d2f6eb6339de25cef04850b6d9be8335d52324cd"
@@ -142,7 +142,7 @@ FILES:kube-proxy = "${bindir}/kube-proxy"
FILES:${PN}-misc = "${bindir} ${sysconfdir}/sysctl.d"
ALLOW_EMPTY:${PN}-host = "1"
-FILE:${PN}-host = "${BIN_PREFIX}/bin/k8s-init"
+FILES:${PN}-host = "${BIN_PREFIX}/bin/k8s-init"
RDEPENDS:${PN}-host = "${PN}"
RRECOMMENDS:${PN} = "\
--
2.37.3
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [meta-virtualization] [PATCH] fixed typos in kubernetes recipe
2022-09-20 11:34 [PATCH] fixed typos in kubernetes recipe Guenther Meyer
@ 2022-09-20 12:03 ` Bruce Ashfield
2022-09-26 8:24 ` Guenther Meyer
0 siblings, 1 reply; 5+ messages in thread
From: Bruce Ashfield @ 2022-09-20 12:03 UTC (permalink / raw)
To: Guenther Meyer; +Cc: meta-virtualization
On Tue, Sep 20, 2022 at 7:31 AM Guenther Meyer <g.meyer@signum-media.de> wrote:
>
> Hi,
>
> I had a problem building the kubernetes package after upgrading to
> kirkstone, the error is also documented here:
> https://errors.yoctoproject.org/Errors/Details/657132/
>
> The typo is still present in the master branch.
Interesting that RPM handles the typo properly. As you can see from
the commit logs, I've been upgrading and building kubernetes over the
past week without any issues (but I use rpm as the package manager).
>
> A patch to fix this is attached.
> I don't know if this is the correct way to submit a patch, as this is
> my first contribution. So feel free to correct me, if I'm wrong.
The patch itself looks fine, the only issue for easy processing is
that it is attached to email, versus being the email. If you send the
patch with git-send-email, it will take care of those details.
That being said, don't worry about re-submitting it, I can detach the
patch and apply it.
Bruce
>
> Guenther
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#7620): https://lists.yoctoproject.org/g/meta-virtualization/message/7620
> Mute This Topic: https://lists.yoctoproject.org/mt/93801075/1050810
> Group Owner: meta-virtualization+owner@lists.yoctoproject.org
> Unsubscribe: https://lists.yoctoproject.org/g/meta-virtualization/unsub [bruce.ashfield@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>
--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [meta-virtualization] [PATCH] fixed typos in kubernetes recipe
2022-09-20 12:03 ` [meta-virtualization] " Bruce Ashfield
@ 2022-09-26 8:24 ` Guenther Meyer
2022-09-26 12:48 ` Bruce Ashfield
0 siblings, 1 reply; 5+ messages in thread
From: Guenther Meyer @ 2022-09-26 8:24 UTC (permalink / raw)
To: meta-virtualization
On Tue, 20 Sep 2022 08:03:21 -0400
"Bruce Ashfield" <bruce.ashfield@gmail.com> wrote:
> The patch itself looks fine, the only issue for easy processing is
> that it is attached to email, versus being the email. If you send the
> patch with git-send-email, it will take care of those details.
I never used git-send-email - didn't know it - and I don't know if I
like it because of security reasons. I also thought it would be easier
to review/merge a patch if it is received as an attachment instead of
inline.
So what is the workflow after a patch is received via email? Is there
some (automatic) tooling, or what is happening until a patch is merged?
I'm accustomed to using the fork/commit/merge workflow that most
projects with github/gitlab repositories have. I guess there is nothing
like that (planned) in Yocto?
Not that I want it currently, but who decides who will get commit
access to the Yocto repos?
> That being said, don't worry about re-submitting it, I can detach the
> patch and apply it.
Thanks for merging the patch into master!
Will the patch also be merged into kirkstone? What is the workflow here?
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [meta-virtualization] [PATCH] fixed typos in kubernetes recipe
2022-09-26 8:24 ` Guenther Meyer
@ 2022-09-26 12:48 ` Bruce Ashfield
2022-09-30 9:31 ` Guenther Meyer
0 siblings, 1 reply; 5+ messages in thread
From: Bruce Ashfield @ 2022-09-26 12:48 UTC (permalink / raw)
To: Guenther Meyer; +Cc: meta-virtualization
On Mon, Sep 26, 2022 at 4:24 AM Guenther Meyer <g.meyer@signum-media.de> wrote:
>
> On Tue, 20 Sep 2022 08:03:21 -0400
> "Bruce Ashfield" <bruce.ashfield@gmail.com> wrote:
>
> > The patch itself looks fine, the only issue for easy processing is
> > that it is attached to email, versus being the email. If you send the
> > patch with git-send-email, it will take care of those details.
>
> I never used git-send-email - didn't know it - and I don't know if I
> like it because of security reasons. I also thought it would be easier
> to review/merge a patch if it is received as an attachment instead of
> inline.
git send-email is heavily used, both in the OE ecosystem and many
others. I'm not sure I follow what security concerns you might have
with it .. but if you have anything specific let us know. Because it
would affect all projects using it!
As for attachments, they are harder to work with than inline patches.
The tooling, replies, and well known (kernel-style) workflow is based
around being able to reply inline and discuss patches. There's plenty
of references for how the flow works, and I wouldn't do it justice by
trying to paraphrase it here.
>
> So what is the workflow after a patch is received via email? Is there
> some (automatic) tooling, or what is happening until a patch is merged?
>
It is a pretty standard maintainer workflow. I receive the patches,
queue and test them. I have some of my own CI scripts, as do others
that run against the repository. If a patch needs extra testing or longer
to soak for comments, I'll often stage them in a master-next branch.
For smaller changes, I often just pull them directly into master. I then
follow up to let the submitter know the patch is merged, or provide
change review feedback.
> I'm accustomed to using the fork/commit/merge workflow that most
> projects with github/gitlab repositories have. I guess there is nothing
> like that (planned) in Yocto?
>
It depends on the repository, the project and the maintainer. For
the patch volume on meta-virtualzation, the tried and true method
of patches to the mailing list work. This aligns with OE core, poky
and many of the other ecosystem layers. But like anything in an
open source project .. it just depends.
The different types of workflows are very well known by the overall
yocto/OE project communities, and we've had some very long
discussions on the topic. You can find them archives on the various
OpenEmbedded Core or OpenEmbedded architecture mailing lists
or in the minutes of the various in person summits we've had over
the years.
> Not that I want it currently, but who decides who will get commit
> access to the Yocto repos?
>
There's no single yocto project repository. The project is an umbrella
with many different subprojects, layers and maintainers. So push
access varies by project.
Most (if not all) of the projects work on a maintainer model.
>
> > That being said, don't worry about re-submitting it, I can detach the
> > patch and apply it.
>
> Thanks for merging the patch into master!
> Will the patch also be merged into kirkstone? What is the workflow here?
>
Either on submission of the patch, someone can indicate that the change
is for master, and another branch. Or once it merges to master, they
can follow up and ask for a backport to an older branch.
In either case, the change needs to be a bugfix, versus a new feature.
I consider this a request to backport, so I've cherry-picked the patch
and merged it to kirkstone.
Bruce
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#7628): https://lists.yoctoproject.org/g/meta-virtualization/message/7628
> Mute This Topic: https://lists.yoctoproject.org/mt/93801075/1050810
> Group Owner: meta-virtualization+owner@lists.yoctoproject.org
> Unsubscribe: https://lists.yoctoproject.org/g/meta-virtualization/unsub [bruce.ashfield@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>
--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [meta-virtualization] [PATCH] fixed typos in kubernetes recipe
2022-09-26 12:48 ` Bruce Ashfield
@ 2022-09-30 9:31 ` Guenther Meyer
0 siblings, 0 replies; 5+ messages in thread
From: Guenther Meyer @ 2022-09-30 9:31 UTC (permalink / raw)
To: meta-virtualization
[-- Attachment #1: Type: text/plain, Size: 770 bytes --]
On Mon, 26 Sep 2022 08:48:50 -0400
"Bruce Ashfield" <bruce.ashfield@gmail.com> wrote:
> git send-email is heavily used, both in the OE ecosystem and many
> others. I'm not sure I follow what security concerns you might have
> with it .. but if you have anything specific let us know. Because it
> would affect all projects using it!
Thank you for all the information!
As I understand, git send-email connects directly to an SMTP server to
send out the patch. Inside a company network this could be a problem
because it's usually not allowed that an arbitrary binary can send
emails directly, at least in my experience.
> I consider this a request to backport, so I've cherry-picked the patch
> and merged it to kirkstone.
Thanks!
Guenther
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2022-09-30 9:32 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2022-09-20 11:34 [PATCH] fixed typos in kubernetes recipe Guenther Meyer
2022-09-20 12:03 ` [meta-virtualization] " Bruce Ashfield
2022-09-26 8:24 ` Guenther Meyer
2022-09-26 12:48 ` Bruce Ashfield
2022-09-30 9:31 ` Guenther Meyer
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.