NACK: [j/linux-raspi v2 RESEND4 PATCH 0/2] Make snapcraft.yaml work
Masahiro Yamada
masahiro.yamada at canonical.com
Wed Feb 14 05:42:34 UTC 2024
On Fri, Feb 9, 2024 at 6:34 PM Juerg Haefliger
<juerg.haefliger at canonical.com> wrote:
>
> On Thu, 8 Feb 2024 12:35:53 +0000
> Dimitri John Ledkov <dimitri.ledkov at canonical.com> wrote:
>
> > Hi
> >
> > On Wed, 7 Feb 2024 at 06:46, Juerg Haefliger
> > <juerg.haefliger at canonical.com> wrote:
> > >
> > > Still missing the requested SRU tag and SRU justification. Why are you
> > > refusing to follow our process?
Because this patch is not related to SRU in the first place.
Given the inflexible SRU policy and process,
I understood even adding a single snapcraft.yaml
is disallowed.
> > >
> > > ...Juerg
> > >
> >
> > This is however not a .deb feature at all; nor should it end up in the
> > changelog. I'm not sure there is anything SRUish to justify here.
>
> It's a modification of the kernel source code of a stable kernel, so yes it's
> an SRU change. Whether that is user-visible or not is irrelevant and
> can be noted in the bug report. People have tooling to scrub the
> mailing list and missing SRU tags will/might drop patches. Checking the SRU
> justification in the bug report is one of the review steps. Why is it so hard
> to follow the documented process and make the life of the people involved
> easier?
>
> ...Juerg
>
>
> > Separately, I want to try to see if doing this build in launchpad out
> > of the full kernel git tree will even work, due to the sheer size of
> > the clone to be done. In the past that would time out. That's why all
> > of our recipes are usually maintained out of tree. I am pondering if
> > this should just be a branch with snapcraft.yaml alone on the
> > ~canonical-kernel-snaps 22 snapcraft recipes repo only, with
> > snapcraft.yaml doing git clone of the pi kernel packaging repo with
> > depth set to 1.
Or, we can create a separate graveyard repository.
"Here is a collection of rejected but useful snapcraft.yaml files"
You can locally drop it into the corresponding kernel repository.
It would be easier to do this for IOT kernels,
and having it in-tree is aligned with how snapcraft works.
https://bugs.launchpad.net/shiner/+bug/2047831
Anyway, I cannot get consensus for this.
Give up.
> >
> > >
> > > On Wed, 7 Feb 2024 11:22:04 +0900
> > > Masahiro Yamada <masahiro.yamada at canonical.com> wrote:
> > >
> > > > linux-raspi added snapcraft.yaml more than a decade ago,
> > > > which is not functional at all.
> > > >
> > > > Remove the old one, and re-implement working snapcraft.yaml.
> > > >
> > > > BugLink: https://bugs.launchpad.net/bugs/2051468
> > > >
> > > >
> > > >
> > > > Masahiro Yamada (2):
> > > > UBUNTU: [Packaging] Remove old snapcraft.yaml
> > > > UBUNTU: [Packaging] Add snapcraft.yaml for building uc22 pi-kernel
> > > > snap
> > > >
> > > > snapcraft.yaml | 175 ++++++++++++++++++++++++++++++++++++++++---------
> > > > 1 file changed, 145 insertions(+), 30 deletions(-)
> > > >
> > >
> > > --
> > > kernel-team mailing list
> > > kernel-team at lists.ubuntu.com
> > > https://lists.ubuntu.com/mailman/listinfo/kernel-team
> >
> >
> >
>
More information about the kernel-team
mailing list