Hi Richard
On Wednesday, 1 March 2023 23:33:22 NZDT Richard Purdie wrote:
> After reading an email about encouraging best practises when supporting
> older software releases, it got me thinking about our LTS and spdx/sbom
> support. We don't have create-spdx there and our official policy says
>
On Friday, 10 September 2021 19:54:11 NZST Richard Purdie wrote:
> > > Do we change the master branch to something else? I personally have a
> > > preference for "devel" over "main" regardless of what others are doing
> > > as it matches what it is in our case. Changing that alone is days of
> > >
FWIW whilst this does fall outside normal policies, I think this is a
reasonable course of action under the (fairly exceptional) circumstances. We
would of course have to review future situations on a case-by-case basis.
Paul
On Wednesday, 3 June 2020 21:27:00 NZST Richard Purdie wrote:
> Hi
d be contacted prior (not yet slated
> for
> removal)
>
> Remove - the layer should be removed from this branch's index
>
> (master only)
>
> LAST - number of days since the last commit, if !COMPAT is detected.
>
>
> Stats:
>
> (in all cases the number
On Thursday, 5 December 2019 7:48:11 PM NZDT Nicolas Dechesne wrote:
> On Thu, Dec 5, 2019 at 3:08 AM Paul Eggleton
> wrote:
> > FYI I came across repology.org which tells you the version of various
> > packages in each distro, though it's not ideal:
> >
> > https
stro or only between two distros. I
think in this instance we have the information we need though.
Cheers,
Paul
--
Paul Eggleton
Intel System Software Products
___
Openembedded-architecture mailing list
Openembedded-architecture@lists.openembedded.org
http
fine what the criteria is (for setting flags either
manually or automatically) I think we can do that.
Cheers
Paul
--
Paul Eggleton
Intel System Software Products
___
Openembedded-architecture mailing list
Openembedded-architecture@lists.openembedd
ls on layers getting deleted - if the original maintainer is dropping a
layer, it might be decided in some cases that it's in everyone's best interest
to have someone else pick it up immediately - depends on the layer and the
situation. FWIW though I'm happy to grant yourself and others rights on the
l
hen we last attempted to fetch it, so we can produce report on and/or
automatically flag layers where the repo is gone for a long time (if we can't
fetch a layer for e.g. 30 days, assuming it wasn't prevented from happening by
some local issue I think we can safely
y what you do want masked -
that I think we would be best advised not to make any more use of it than we
currently do, especially if it's only to save a bit of time parsing.
Cheers
Paul
--
Paul Eggleton
Intel System Software Products
___
Openembedd
On Tuesday, 4 September 2018 7:54:55 PM NZST
richard.pur...@linuxfoundation.org wrote:
> On Tue, 2018-09-04 at 16:18 +1200, Paul Eggleton wrote:
> > In the layer index / RRS code I have found that if it tries to use
> > bitbake's git fetcher to access a git repository on github th
11 matches
Mail list logo
