Re: [OE-core] [bitbake-devel] RFC: exposing information about the SRC_URI(s)/branch via buildhistory (or similar mechanism)

2019-08-16 Thread chris.laplante--- via Openembedded-core
> > I think this supports my point about being more interested in patches > > allowing people to extend/customise buildhistory than just adding X. > > > > Whilst we want to have good defaults, there are always going to be > > niche cases for people wanting to extend it... > > > Agreed. Then we

Re: [OE-core] [bitbake-devel] RFC: exposing information about the SRC_URI(s)/branch via buildhistory (or similar mechanism)

2019-08-01 Thread chris.laplante--- via Openembedded-core
We’re well aware of the limitations and possibility of failed builds, as I said we hardcode revisions using SRCREV overrides when necessary. It’s been working well for us so far. So, respectfully, I think that’s not relevant to the discussion. Chris From: Alexander Kanavin Sent: Thursday,

Re: [OE-core] [bitbake-devel] RFC: exposing information about the SRC_URI(s)/branch via buildhistory (or similar mechanism)

2019-08-01 Thread Mark Hatle
On 8/1/19 11:51 AM, chris.laplante--- via bitbake-devel wrote: > Hello all, > >   > > Most of my team’s closed source recipes use something like the following: > >   > > SRC_URI = "git://git@host/path;protocol=ssh;branch=${BRANCH}" > > SRCREV = “${AUTOREV}” > > BRANCH ??= “master” > >   >

Re: [OE-core] [bitbake-devel] RFC: exposing information about the SRC_URI(s)/branch via buildhistory (or similar mechanism)

2019-08-01 Thread Alexander Kanavin
Apologies, but I think you should drop the practice of using AUTOREV. This completely destroys reproducibility of builds, and makes them susceptible to global breakage when someone pushes a broken commit into one of the component repositories. Yes, bumping SRCREV is annoying, but a) it can be