On Thu, May 13, 2021 at 3:48 PM Richard Purdie
wrote:
>
> On Thu, 2021-05-13 at 17:33 -0400, colin walters wrote:
> >
> > On Thu, May 13, 2021, at 4:08 PM, Richard Purdie wrote:
> > >
> > > The advice to anyone hitting this issue is to add in the correct branch
> > > to the SRC_URI. It is simple a
On Thu, 2021-05-13 at 17:33 -0400, colin walters wrote:
>
> On Thu, May 13, 2021, at 4:08 PM, Richard Purdie wrote:
> >
> > The advice to anyone hitting this issue is to add in the correct branch
> > to the SRC_URI. It is simple and easy to do, can be in bbappends
> > or even changed via anonymo
On Thu, May 13, 2021, at 4:08 PM, Richard Purdie wrote:
>
> The advice to anyone hitting this issue is to add in the correct branch
> to the SRC_URI. It is simple and easy to do, can be in bbappends
> or even changed via anonymous python and similar if necessary. We've already
> found the issue
On Thu, 13 May 2021 at 22:34, Benjamin Gilbert
wrote:
> Tarballs, commits on published branches, and annotated tags are all
> supposed to be stable artifacts. But I don't know of any general
> expectation that a specific branch continues to exist, other than the one
> created by Bitbake. GitHub
On Thu, May 13, 2021 at 01:09 PM, Richard Purdie wrote:
>
> Some of our users have complained, yes. That isn't a conscious decision on
>
> "our" part, just a rather unfortunate and unplanned consequence of the
> fact
> we're pretty strict about declaring where we get our sources.
>
> The advice
On Thu, May 13, 2021 at 01:07 PM, Alexander Kanavin wrote:
>
> It's not that different from deleting or archiving old tarball downloads -
> yes it keeps things clean and tidy for upstream, but it will break
> someone's automated build that way, no matter how obsolete the code being
> downloaded.
On Thu, 2021-05-13 at 14:25 +, Peter Kjellerstedt wrote:
> > Another reason we have the branch name is so that we can ls-remote the
> > repo
> > when using AUTOREV for SRCREV. We've tried to make it so that once a url
> > is established in SRC_URI, you can make it use AUTOREV without changes to
On Thu, 2021-05-13 at 09:27 -0400, colin walters wrote:
>
> On Thu, May 13, 2021, at 3:08 AM, Richard Purdie wrote:
> >
> > I had a look at the code to try and remind myself why it is doing this.
>
> Thanks!
>
> > The best answer I found is that it does support filtered fetching of
> > remote
On Thu, 13 May 2021 at 21:54, Benjamin Gilbert
wrote:
> They're not useless though. As a layer maintainer I absolutely want those
> checks, as I want to be aware of any branch configuration changes upstream,
> and to ensure I'm not accepting a change in source revision that points to
> an unattac
On 13.05.21 21:54, Benjamin Gilbert wrote:
On Thu, May 13, 2021 at 12:36 PM, Alexander Kanavin wrote:
They're not useless though. As a layer maintainer I absolutely want
those checks, as I want to be aware of any branch configuration
changes upstream, and to ensure I'm not accepting
On Thu, May 13, 2021 at 12:36 PM, Alexander Kanavin wrote:
>
> They're not useless though. As a layer maintainer I absolutely want those
> checks, as I want to be aware of any branch configuration changes
> upstream, and to ensure I'm not accepting a change in source revision that
> points to an
And IMHO deleting branches upstream is just bad practice. From a
Yocto/OE perspective I have to consider that people might want to build
stuff in 5yrs or even 10yrs from now.
a more reasonable pattern would be to branch off from master to main,
make main the new default but leave master untouche
On Thu, 13 May 2021 at 21:25, Benjamin Gilbert
wrote:
> Deleting the branch normally affects people who are in the project's
> developer community and pay attention to its announcements. Those folks
> can then simply update their local checkouts and move on with their lives.
> Everyone else just
On Thu, May 13, 2021 at 3:25 PM Benjamin Gilbert wrote:
>
> On Thu, May 13, 2021 at 12:04 PM, Bruce Ashfield wrote:
>
> Deleting the branch penalizes existing developers, which projects might be
> willing to do. Git branch names don't usually have any effect on users.
>
> I'm not sure I see the d
On Thu, May 13, 2021 at 12:04 PM, Bruce Ashfield wrote:
>
>
>> Deleting the branch penalizes existing developers, which projects might be
>> willing to do. Git branch names don't usually have any effect on users.
>
> I'm not sure I see the distinction you are trying to draw.
Deleting the branc
On Thu, May 13, 2021 at 3:02 PM Benjamin Gilbert wrote:
>
> On Thu, May 13, 2021 at 06:36 AM, Bruce Ashfield wrote:
>
> The problem is that your build system is penalizing upstream projects that
> are trying to migrate
> to using `main`.
>
> Similarly those same projects are completely deleting t
On Thu, May 13, 2021 at 06:36 AM, Bruce Ashfield wrote:
>
>
>> The problem is that your build system is penalizing upstream projects that
>> are trying to migrate
>> to using `main`.
>
> Similarly those same projects are completely deleting those branches,
> versus no longer making them the def
> Subject: Re: [OE-core] master/main branch renaming and bitbake
>
> On Wed, 2021-05-12 at 17:11 -0700, Andre McCurdy wrote:
> > On Wed, May 12, 2021 at 2:23 PM Alexander Kanavin
> > wrote:
> > >
> > > And by the way, another reason to check that revision is li
On Thu, May 13, 2021 at 9:27 AM colin walters wrote:
>
>
>
> On Thu, May 13, 2021, at 3:08 AM, Richard Purdie wrote:
> >
> > I had a look at the code to try and remind myself why it is doing this.
>
> Thanks!
>
> > The best answer I found is that it does support filtered fetching of
> > remotes, i
On Thu, May 13, 2021, at 3:08 AM, Richard Purdie wrote:
>
> I had a look at the code to try and remind myself why it is doing this.
Thanks!
> The best answer I found is that it does support filtered fetching of
> remotes, i.e. it can and will only pull the branch it wants/needs rather
> than
On Wed, 2021-05-12 at 17:11 -0700, Andre McCurdy wrote:
> On Wed, May 12, 2021 at 2:23 PM Alexander Kanavin
> wrote:
> >
> > And by the way, another reason to check that revision is linked to a
> > branch is when SRCREV is updated - we need some reassurance that the
> > updated SRCREV comes fro
On Wed, May 12, 2021 at 2:23 PM Alexander Kanavin
wrote:
>
> And by the way, another reason to check that revision is linked to a branch
> is when SRCREV is updated - we need some reassurance that the updated SRCREV
> comes from the same branch as previous SRCREV, or that if the branch has
> ch
And by the way, another reason to check that revision is linked to a branch
is when SRCREV is updated - we need some reassurance that the updated
SRCREV comes from the same branch as previous SRCREV, or that if the branch
has changed, it's explicitly visible in the diff and explained in the
commit
On Wed, 12 May 2021 at 22:44, Colin Walters wrote:
> On Wed, May 12, 2021, at 4:40 PM, Alexander Kanavin wrote:
> > For ostree, yes:
> > http://git.openembedded.org/meta-openembedded/log/?h=master-next
> >
> > For the generic case, no. It's not a good idea to start guessing what
> > the upstream
On Wed, May 12, 2021, at 4:40 PM, Alexander Kanavin wrote:
> For ostree, yes:
> http://git.openembedded.org/meta-openembedded/log/?h=master-next
>
> For the generic case, no. It's not a good idea to start guessing what
> the upstream did.
What is the goal of the `branch=` specification? I can
meta-oe/master
https://lists.openembedded.org/g/openembedded-devel/message/91252
meta-oe/hardknott
https://lists.openembedded.org/g/openembedded-devel/message/91253
meta-oe/gatesgarth
https://lists.openembedded.org/g/openembedded-devel/message/91254
meta-oe/dunfell
https://lists.openembedded.org/g/
For ostree, yes:
http://git.openembedded.org/meta-openembedded/log/?h=master-next
For the generic case, no. It's not a good idea to start guessing what the
upstream did.
Alex
On Wed, 12 May 2021 at 22:34, colin walters wrote:
> (Sorry I think this isn't the right list, but I happen to still b
(Sorry I think this isn't the right list, but I happen to still be subscribed
to this one so...)
Can someone please tell me there's a fix for yocto/bitbake failing if the
master branch is renamed?
https://github.com/ostreedev/ostree/issues/2360
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all me
28 matches
Mail list logo
