* [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.