One option is to install the files into sysroot-destdir/ (there's a
way to extend what gets copied there beyond the standard set of
headers/libraries) in addition to packaging them, then make a new
recipe that DEPENDS on all the recipes that do that sysroot
installation, and then it will have the
I wonder what is the use case? Perhaps there's a way to achieve that
in some other way altogether?
Alex
On Thu, 23 May 2024 at 11:46, gauravpathak129 via
lists.yoctoproject.org
wrote:
>
> Hello Experts,
>
> I am wondering if there is any built in "Yocto way" of listing all the
>
You need to delete the build folder, not the poky folder. You also need to
start a new shell session.
Alex
On Thu 23. May 2024 at 7.37, SasiKumar E via Lists.Yoctoproject.Org
wrote:
> yes Alex, I have deleted the poky folder itself and retried the steps
> provided in the URL "
>
You might want to try to bisect poky? If there’s any fix, it needs to be
justified with something else than ‘unbreaks passwords in recipes’.
Alex
On Wed 22. May 2024 at 8.15, Lukas Weiß via Lists.Yoctoproject.Org
wrote:
> You are definitely right, we should switch to another auth mechanism.
Delete everything including your build folder and start from scratch I guess?
I cannot help if you don't describe exact steps that you are taking,
particularly when you are changing configuration or deleting things.
Alex
On Wed, 22 May 2024 at 06:57, SasiKumar E via lists.yoctoproject.org
Supplying passwords this way is a terrible idea, and isn't supported
(there's a comment in git fetcher source stating that explicitly). You
should transition everything to ssh (at which point the issue will go
away anyway), or place the https secrets into a more secure location
(man gitcredentials
You need to re-run bitbake after you make changes to configuration in
build/conf/local.conf or other files there.
runqemu itself won't trigger a rebuild, it only starts qemu. If for
example the machine changes, then the files are going to be expected
in different locations and only bitbake will
Your name is 'Mike' and your email is 'chiefsleepy...@gmail.com'. That
is not a real identity or an introduction. I'd want to know who you
are, who is your employer, and what is your project and product. Just
like in real life.
Alex
On Tue, 21 May 2024 at 14:31, mlynch via
Please:
a) introduce yourself;
b) formulate a question.
Alex
On Mon, 20 May 2024 at 09:47, SasiKumar E via lists.yoctoproject.org
wrote:
>
> I followed all the instructions as per the quick build, initially qemu had
> run for the second time it is not working and resulting to this error
>
>
>
Please tell us where that layer is hosted. There's no guarantee that
its maintainer reads this list or is going to see your question.
Also do introduce yourself; asking questions anonymously is not polite
and lessens your chances of anyone reacting.
Alex
On Sat, 18 May 2024 at 14:05, Mike via
Yeah, I was confused. This is the authoritative source:
https://wiki.yoctoproject.org/wiki/Releases
Neverthless mickledore is no longer supported (and nanbield is out of
support shortly).
Alex
On Thu, 16 May 2024 at 12:29, dhanyalakshmi.k via lists.yoctoproject.org
wrote:
> Thank You Alex for
I understand this is not exactly helpful, but someone subverted yocto
completely with ls-image-main recipe. Putting Ubuntu into target
images is not supported, tested or recommended, and if any issues
occur you're on your own. Or ask the developers of that 'layerscape'
thing.
Also mickledore is
Oh, and: please introduce yourself as well. It's not polite to fire
off support questions without saying who you are and what are you
working on.
Alex
On Thu, 16 May 2024 at 11:37, Alexander Kanavin via
lists.yoctoproject.org
wrote:
>
> " - package ubuntu-main-22.04.2-r0.aarch64 f
" - package ubuntu-main-22.04.2-r0.aarch64 from oe-repo obsoletes
libc6-dbg provided by libc6-dbg-2.35-r0.aarch64 from oe-repo"
This ubuntu-main package is highly suspect and shouldn't be present.
Can you look into where it's coming from, how is formed, and why is it
there to begin with? We
following setting?
>
> RDEPENDS:${PN} += “sqlite3”
>
>
>
> I have added this (RDEPENDS_${PN} += "sqlite3") to the recipe but I see the
> same error!!
>
>
>
>
>
> Regards,
>
> Qi
>
>
>
> From: yocto@lists.yoctoproject.org On Behal
Can you show the complete recipe?
Alex
On Tue 14. May 2024 at 9.56, Altous, Salahaldeen via lists.yoctoproject.org
wrote:
> Hi All,
>
> I have one yocto recipe which is using libsqlite3, the compile task is OK
> but I got this error with do_package_qa
>
> /usr/lib/libexample.so.0.2.3 contained
You need to look into build logs and build directory for the kernel
recipe to see what modules are being built and packaged.
Alex
On Mon, 13 May 2024 at 02:02, Worik Stanton via lists.yoctoproject.org
wrote:
>
> Friends
>
> Where in a yocto build can I find the definition of a package for
On Wed, 8 May 2024 at 23:19, Worik Stanton via lists.yoctoproject.org
wrote:
> The system (before a build) has two subdirectories:
>
> * layers: Consists of "meta-*" directories, and "openembedded-core" all git
> repositories pinned to particular commits
> * meta-mybuild: Consisting of
On Thu, 9 May 2024 at 12:36, Richard Purdie via lists.yoctoproject.org
wrote:
> > I have a dummy question regarding the file://DIRECTORY/ in recipe
> > usage, we are using this mechanism to directly point at a source
> > repository with potentially lots of subfolders, etc. Does bitbake
> > track
I'm not sure I understand how this would even be possible? You can't
generate SPDX until you have the binary artefacts and they've been
split into packages as far as I understand. The spdx code in yocto
explicitly establishes that relation between tasks.
Alex
On Wed, 8 May 2024 at 13:59,
On Wed, 8 May 2024 at 05:38, Worik Stanton via lists.yoctoproject.org
wrote:
> The "whomever" has gone away, and I am on my own!
>
> Where do I start resolving a dependency like this?
First of all, please introduce yourself like I'm sure you would when
you meet new people in real life. Who you
On Thu, 25 Apr 2024 at 10:16, Altous, Salahaldeen via
Lists.Yoctoproject.Org
wrote:
> the reason behind that, that this company have one external module which
> development in the past with an early version of this library and currently
> there is a new module which developed with the new
On Thu, 25 Apr 2024 at 10:10, Altous, Salahaldeen via
Lists.Yoctoproject.Org
wrote:
> The 3rd party is using only The Yocto SDK (not the eSDK), they want to test
> pre-release for one or two libs which are not included in the machine conf
> yet.
>
> If I provide a pre-build sstate-cache, which
You should find out why people want same that library in different
versions in the first place. This indicates some kind of dysfunction
in the product development process.
Alex
On Wed, 24 Apr 2024 at 16:59, Altous, Salahaldeen via
lists.yoctoproject.org
wrote:
>
> Hi,
>
> can I install Multiple
I would suggest that you teach the 3rd party to set up a Yocto build
and provide pre-built sstate cache to them. We've added SDK features
directly into it, and incremental updates are both possible and easy
in that setup (just pull from the layer repos and rerun bitbake as
instructed).
Alex
On
:
>
> Hi Alex
>
> thanks for your quick reply.
>
> On Tue, Apr 23, 2024 at 05:02 AM, Alexander Kanavin wrote:
>
> I think you can simply make it a class and put under
> classes/some.bbclass? Plenty of recipes in oe-core do this, see e.g.
> gnomebase.bbcl
I think you can simply make it a class and put under
classes/some.bbclass? Plenty of recipes in oe-core do this, see e.g.
gnomebase.bbclass.
Alex
On Tue, 23 Apr 2024 at 13:57, Altous, Salahaldeen via
lists.yoctoproject.org
wrote:
>
> Hi All,
>
> I need a common place holder to share one include
openssh recipe (or its appends) does not control what gets installed
into the image, only how openssh gets split into packages. To see what
gets installed you need to find the image recipe and modify that as
appropriate.
Alex
On Wed, 17 Apr 2024 at 13:56, Nitesh D via lists.yoctoproject.org
Hello Rayhan,
I forgot to say, linux-yocto is not the right place to ask general
yocto questions (it's for developing the linux kernel in yocto).
Please use the yocto group instead.
Alex
On Mon, 15 Apr 2024 at 14:41, inbrayhan via lists.yoctoproject.org
wrote:
>
> [Edited Message Follows]
>
>
k the .deb into
that location).
Alex
On Mon, 15 Apr 2024 at 13:35, Alexander Kanavin via
lists.yoctoproject.org
wrote:
>
> First of all, please introduce yourself. What is your name? Who do you
> work for? What is the product you are working on?
>
> Second, please show the recipe exact
First of all, please introduce yourself. What is your name? Who do you
work for? What is the product you are working on?
Second, please show the recipe exactly as it is (don't censor or
otherwise modify it), and then also show what happens when you run
bitbake with it, because what I'm seeing
at 09:10, Alexander Kanavin via lists.yoctoproject.org
wrote:
> I think you have to get an expert to boot your system and look at it
> directly. If we can’t reproduce the issue, it’s just too much effort to
> exchange emails for no reward at all other than thanks. It’s open source,
>
s LD_PRELOAD related
> error.
>
> On Sun, 24 Mar 2024, 8:53 am Ashu Joshi, wrote:
>
>> I am not able to figure out.. Is there any way we can override the
>> location where application looks for python may be in recipe file or some
>> setting, conf file?
>>
>>
output in target's terminal.
>
> /usr/lib/python3.8 $
> /usr/lib/python3.8 $ find -iname "encodings"
> ./encodings
>
>
> On Fri, Mar 22, 2024 at 1:29 PM Alexander Kanavin
> wrote:
>
>> This means the python installation on the target is incomplete/broken.
>>
on3 because when i try to start python by writing
> python3 in target's terminal, i get above error message related to
> encodings.
>
> On Fri, Mar 22, 2024 at 11:48 AM Alexander Kanavin
> wrote:
>
>> You need to first start python3 and run it there, not directly from the
>&g
You need to first start python3 and run it there, not directly from the
shell.
Alex
On Fri, 22 Mar 2024 at 07:00, Ashu Joshi wrote:
> It doesn't allow me to run import encodings as it is giving another error
> import:not found
>
> On Thu, Mar 21, 2024 at 7:53 PM Alexander Kana
epasTransport.service"
>> FILES_${PN} += "/usr/share/settings.yml"
>>
>> Error was basically because of commented code wherein I was trying to
>> export the entire directory. I have commented out that for now.. I found
>> that by creating rpm or opkg pa
Please share your complete recipe and all of the error message, otherwise
it’s impossible to tell what is happening.
Alex
On Thu 21. Mar 2024 at 8.29, Ashu Joshi wrote:
> Hello,
> I am trying to install wirpas_gateway package from pypi using yocto
> recipe.. Once service is build completely
On Wed, 20 Mar 2024 at 11:55, Ross Burton wrote:
> I’d be against removing _all_ arm hosts from the quick build. With the
> in-progress changes to the autobuilder hosting we should be able to retire
> the slower Arm workers and a build running on the Arm hosts shouldn’t be a
> problem. It
Hello,
I feel that a-quick builds as they are have ceased to be quick or
lightweight, and I'd like to trim heavy items from them. The goal is
to:
- have a-quick complete in under an hour with fully populated sstate
- lessen the load on arm workers in particular; there is not enough of
them, and
You can try to issue 'bitbake -e easyloggingpp' which will print all
variables and how their values are formed. Look particularly for
PACKAGES and FILES entries, as those will contain clues as to why the
file isn't being picked up by packaging.
Alex
On Mon, 18 Mar 2024 at 19:05, Bratiranjan
On Thu, 14 Mar 2024 at 12:45, Ross Burton wrote:
> The rationale behind this is that changes to the recipe/sources may mean the
> patch no longer applies correctly if the PACKAGECONFIG is enable/disabled,
> but that combination wasn’t tested.
Even if all such patches apply cleanly in all their
On Thu, 14 Mar 2024 at 10:04, Saswati Nayak wrote:
> My scenario will be , Suppose I am having a layer meta-A and in this layer
> some directories structure is there such as recipes-bsp, recipes-kernel etc.
> in recipes-bsp I have a recipe atf_1.0.bb which has few keys which are stored
> in
The idiomatic pattern is to reject conditional patches in code review,
Seriously, not a good idea - try to find a way to apply the patch
without conditions, and trigger the condition through a configuration
option, or runtime check.
Alex
On Wed, 13 Mar 2024 at 17:40, Joel Winarske wrote:
>
>
Perhaps you can explain what is in that directory, and why do you need
access to it from another layer. It's not a common scenario.
Alex
On Wed, 13 Mar 2024 at 11:38, Saswati Nayak wrote:
>
> Hello All,
>
> I require guidance on utilizing a file directory present in the
> 'meta-x'
Can you publish the layer somewhere? It's hard to tell what is going
on, but perhaps you could check which task creates which artefacts in
deploy directory, and consult the bitbake manual about task
dependencies so they can be run in correct order.
Alex
On Thu, 7 Mar 2024 at 11:13, Bratiranjan
Can you start runqemu without the nographic option, and copy-paste
what it prints? There are clues as to how it sets up networking in
there.
Alex
On Sat, 9 Mar 2024 at 19:59, Xylopyrographer wrote:
>
> Thanks for the reply.
>
> Still a bit green with all this but from the QEMU VM, sshd is
Hello,
It helps if you explain the use case. What is the original file name,
and what is the name of the symlink, and why do you need to create
one?
Alex
On Tue, 5 Mar 2024 at 11:54, Bratiranjan Acharya
wrote:
>
> Hi,
>
> I hope this email finds you well. I have a question regarding a specific
On Thu, 29 Feb 2024 at 10:26, Patrick Huesmann wrote:
> Your suggestion will probably get rid of a lot of complexity in our recipe
> that tried to work around bitbake's limitations. But I'm still not sure how
> to tackle the original problem (AUTOINC from PRSERV for file:// and http://
>
Oh mercy me. Yocto isn't designed for this; everything is assuming
that SRCREV, SRC_URI and PV are static and set in the recipe.
So I would rather implement the logic to determine what they are in an
external script, and run that prior to bitbake. The script would write
the dynamic values into an
At this point you need to show the recipe. Because I don't understand
how packages can have dedicated source revision, if source revision is
set by the recipe, and is the same for all packages it makes... where
is the problem here?
Alex
On Wed, 28 Feb 2024 at 16:15, wrote:
>
> As far as I can
You can check if existing recipes in oe-core get correct PKGV into
package files, there's plenty of them, e.g. xinput-calibrator, or any
other that adds +git to PV (without zero at the end).
Alex
On Wed, 28 Feb 2024 at 14:17, wrote:
>
> Great! This was exactly the bit of information I was
Note that the package version has 'git0' in it. That zero is supposed
to be filled in by PR server, and if this doesn't happen, something is
misconfigured, or there's a bug.
You can find the code that does this in
meta/classes-global/package.bbclass, particularly look for PKGV
manipulations in
Welcome to PR service which you need to run and use during yocto builds:
https://wiki.yoctoproject.org/wiki/PR_Service
Alex
On Wed, 28 Feb 2024 at 12:56, wrote:
>
> Hi,
>
> I noticed a strange behavior of dnf not updating a package from the package
> feed, and when I told it to explicitly
On Tue, 27 Feb 2024 at 08:20, wrote:
> Thank you for your reply. I already tried to use cmake instead of autotools
> but the error I got was that there was no CMakeLists for the compilation.
>
> Then I tried to set:
>
>
> OECMAKE_GENERATOR = "Unix Makefiles"
>
> But another error appears:
>
>
It is not entirely clear what is happening. The recipe depends on
python3-pip (not the native), but somehow pip3 executable still ends
up in the native sysroot. Then pip3 can't find its own modules, which
means that either the modules are not there (in recipe-sysroot-native/
that is), or it's
On Fri, 23 Feb 2024 at 12:32, Konstantin Aladyshev
wrote:
> Thanks for the response! What would be a proper way to fix this problem then?
1. show how to reproduce the issue in plain poky master.
2. check why none of the tests expose the issue. You can for example
grep related keywords in
If you want help or fixes, you need to show how to reproduce the issue
with plain poky master via specific steps, and not just discuss
problems in your local setup.
Alex
On Fri, 23 Feb 2024 at 11:35, Konstantin Aladyshev
wrote:
>
> Hello!
>
> 'kgit-s2q' in the linux recipe tries to use 'git
It's probably just a simple oversight. If the problematic code path is
not taken in automated tests, no one will see the issue when it's
introduced by the commit.
Alex
On Thu, 22 Feb 2024 at 16:11, Konstantin Aladyshev
wrote:
>
> Hello!
> I was investigating some problems with the `devtool
On Sun, 18 Feb 2024 at 16:50, wrote:
>
> Thanks for your reply.
>
> I have go through your recommend article, and I have a question. "Yocto is an
> open source collaboration project" and in my opinion "open source
> collaboration project" is a process of create and maintain open source
>
I think you could start with this page
https://www.yoctoproject.org/development/technical-overview/
Alex
On Sun 18. Feb 2024 at 11.56, wrote:
> Hi everyone,
>
> I am new to Yocto and sorry for my poor english. I have a question is
> that, what actually Yocto is?. I am so confuse about this
That said, if the difference between distros is only in specific
recipe settings, then I think the builds will reuse each other's
sstate, other than the recipes that differ, and their consumers.
Alex
On Sun, 28 Jan 2024 at 13:48, Alexander Kanavin via
lists.yoctoproject.org
wrote:
>
> T
There's no way around this: you can't build the same recipe in two
different ways for two different images in the same DISTRO. The
different behavior has to be specified through config files and picked
up at runtime, and not through build time settings. All products and
builds and CI
Putting image specific tweaks into local.conf is not a good practice.
Local.conf should be extremely minimal, and ideally contain only
MACHINE and DISTRO.
I would do it with two different image recipes that share almost
everything via common .inc, except ROOTFS_POSTPROCESS_COMMAND. You can
find
On the image level you can only control which packages go into it.
Kernel modules are all split into their own packages, so you can
install (or not) what you want.
Building the same userspace recipe slightly differently for different
images isn't possible. You need to accept that and find some
Multiple machines has a heavy cost, as you effectively double the
amount of builds (and build times) just so you can enable or not some
features in the kernel on the exact same hardware. I would suggest to
keep the same machine and same distro, and just make multiple images
(maybe even in the same
Producing docker or some other container with yocto is not impossible,
but it's a huge maintenance headache. From my experience every
developer team wants 'their stuff' in it, and of course they never
clean up something they no longer need. So the artefact grows in size
indefinitely. There's also
I would suggest not trying to figure out PACKAGECONFIGs just yet, but
rather go to the source of the error: inspect ${T}/log.do_configure
and ${T}/run.do_configure. Are options to enable/disable python passed
in? If yes, then something in PACKAGECONFIG settings doesn't quite
work. If no, then
Note the existing tests in meta/lib/oeqa/runtime/cases/dnf.py - the do
use a remote http repo to install a file, but the repo configuration
is supplied on command line with --repofrompath, and upgrading is not
tested.
Alex
On Fri, 12 Jan 2024 at 15:05, Michael Opdenacker via
You need to inspect ${T}/log.do_rootfs for your image to check what is
actually being installed.
Also check the packages for simple-local to verify that they contain
what you expect to see on the image.
Alex
On Tue, 9 Jan 2024 at 17:01, Daniele Lugli wrote:
>
>
I'd say including recipes across layers is not a good idea to begin
with. Rather copy, rename and tweak it.
Alex
On Tue, 9 Jan 2024 at 11:42, Daniele Lugli wrote:
>
> Thank you Marco,
>
> it is there:
>
> # POKY_BBLAYERS_CONF_VERSION is increased each time build/conf/bblayers.conf
> # changes
I think it's not being tested due to lack of a dedicated maintainer.
If you can come up with fixes, they'll be taken, but having regression
tests requires dedicated manpower to take care of both the tests and
the fixes.
Generally icecc is not the first option when it comes to speeding up
builds:
It helps if you provide the context. What is the end goal here, what
is the number used for? Maybe there's a different approach altogether
for the problem you have.
Alex
On Fri, 29 Dec 2023 at 08:39, Gileon Chai wrote:
>
> Thank you for your reply.
> HELLO's value in two bbfiles is same when
On Fri, 22 Dec 2023 at 16:24, Michael Opdenacker
wrote:
> If I understand correctly, even after I define a new
> 'poky-binary-distro' distro in meta-poky (if agreed), I'll still have to
> add a new image to config.json, but indeed not touching existing ones.
You don't need new images, but you
oduced for releases
> at https://downloads.yoctoproject.org/releases/yocto/, as they currently
> don't have package management enabled.
>
> Signed-off-by: Michael Opdenacker
> CC: Alexander Kanavin
>
> ---
> Note: could not test this change!
>
> Changes in V2:
> - Add conte
And also, why here, and not in oe-core? Any such custom tweaks add to
the friction and mismatches between local builds and autobuilder
builds, especially when one fails but not the other.
Alex
On Fri, 22 Dec 2023 at 12:51, Alexander Kanavin via
lists.yoctoproject.org
wrote:
>
> Wai
Wait, why?
Alex
On Fri, 22 Dec 2023 at 12:48, Michael Opdenacker via
lists.yoctoproject.org
wrote:
>
> From: Michael Opdenacker
>
> Signed-off-by: Michael Opdenacker
>
> ---
> Note: could not test this change!
> ---
> config.json | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
>
)
> SDK Team | Ambarella Shanghai
>
> -Original Message-
> From: Alexander Kanavin
> Sent: Thursday, December 21, 2023 4:40 AM
> To: yocto@lists.yoctoproject.org; Ming Wen
> Cc: ross.bur...@arm.com; Song-Jun Han ; Jian Tang
>
> Subject: [EXT] Re: [yocto] do_popul
On Wed, 20 Dec 2023 at 01:51, Ming Wen wrote:
> Song-Jun and myself are in the same team. We spent some efforts to make it
> happen for " do_populate_sdk_ext" finally by fixing some issue in Poky(we're
> using latest Kirkstone 4.0). But as you mentioned, when we tried the
> generated eSDK, we
Zeus has been EOL for a long time. You need to first upgrade to a
supported yocto release.
Alex
On Mon, 18 Dec 2023 at 13:29, Monsees, Steven C (US)
wrote:
>
>
>
> Is there any documentation or guidance you can provide on porting Yocto for
> centos7 to 8 ?
>
> I am currently working centos7
We're working to improve sharing of builds (I posted a prototype
recenty), but for now the simplest is to copy sstate cache and
download cache manually: together they will prevent others from doing
full rebuilds. You also need build/conf/ and all the layers of course.
Alex
On Wed, 6 Dec 2023 at
You should look at log.do_rootfs for your image (in $WORKDIR under
temp/) to see what is happening at the actual package transaction.
Also, find the package which should pull in the one that's missing (in
tmp/deploy for example), and inspect that it does indeed contain the
dependency.
Alex
On
You need to try plain poky then because the error does not happen
there. Then figure out where the difference is.
Alex
On Fri, 1 Dec 2023 at 12:56, Mans Zigher wrote:
>
> I have now tried building a multitude of different machines and
> switched to core-minimal-image and still I get these
I'm afraid you do have to update your yocto to something where spdx is
supported. That's why we constantly urge everyone to stay close to
upstream yocto, and have a process where that happens regularly,
otherwise you will not be able to fulfil business requirements for
your products in the longer
On Thu, 23 Nov 2023 at 13:14, Ross Burton wrote:
>
> On 23 Nov 2023, at 12:00, Alexander Kanavin wrote:
> >
> > matchbox-terminal depends on vte, and latest vte enables gtk4 support.
>
> Are you sure?
>
> https://git.yoctoproject.org/poky/tree/meta/recipes-support
matchbox-terminal depends on vte, and latest vte enables gtk4 support.
Also, I do not understand how the fix works. How does installing
additional packages into an image resolve a conflict between two
packages installing different files into the same location?
Alex
On Thu, 23 Nov 2023 at 12:50,
I think no one actually anticipated all these corner cases when
devtool was written. In general it's simply not designed to handle
multiple sources in SRC_URI, it can do (tarball or git)+patches, and
not any of the other options. No one is expecting a fix for all of
them, perhaps it's best to keep
On Sun, 5 Nov 2023 at 20:43, wrote:
> Another topic where additional meta data about the sstate-cache seams
> to be beneficial is sstate-mirror retention. Knowing which artifact was
> compiled for which tag or commit of the bitbake layer could help to
> wipe out some artifacts which are not
On Fri, 3 Nov 2023 at 10:37, Alexander Kanavin via
lists.yoctoproject.org
wrote:
>
> Ka-boom:
> https://autobuilder.yoctoproject.org/typhoon/#/builders/130/builds/59
"
ERROR: Command . ./oe-init-build-env; bitbake-layers add-layer
/home/pokybuild/yocto-worker/auh/build/auto-upgrade
Ka-boom:
https://autobuilder.yoctoproject.org/typhoon/#/builders/130/builds/59
Alex
On Thu, 2 Nov 2023 at 16:21, Yoann Congal wrote:
>
> setup-auh and run-auh were doing what the AB config.json does:
> * creating repo checkouts: Now use NEEDREPOS
> * configuring bitbake env: Now use extravars
>
On Thu, 2 Nov 2023 at 10:02, Alexander Kanavin via
lists.yoctoproject.org
wrote:
> So here's what I'd like to try:
>
> - write a new populate_build_replica task that writes a few things
> under ${WORKDIR}/replica
> -- setup-layers json and script
> (another option is to co
On Thu, 2 Nov 2023 at 09:32, wrote:
> Sorry for repeating some parts which we already had in other emails.
> But I tried to summarize the lengthy discussion a bit in one place.
So here's what I'd like to try:
- write a new populate_build_replica task that writes a few things
under
On Wed, 1 Nov 2023 at 16:45, wrote:
> I think these differences between SDK and bitbake environment are no
> longer required and they have been problematic. I would try to make the
> bitbake environment usable like the eSDK environment was without trying
> to replicate all the details of the eSDK
On Wed, 1 Nov 2023 at 15:18, wrote:
> We are currently experimenting with replacing the eSDK installer with
> the bitbake build environment for our users. Part of this
> transformation is, of course, the shared sstate-cache, for which this
> discussion seems quite relevant. The workflow we are
On Tue, 31 Oct 2023 at 13:28, Richard Purdie
wrote:
> > Then we can pull all of it together into 'devtool esdk '
> > command (or similar), which would enter the esdk environment directly
> > via:
> > - running 'bitbake meta-ide-support'
> > - running the above mentioned bitbake local.conf task
On Mon, 30 Oct 2023 at 16:02, Alexander Kanavin via
lists.openembedded.org
wrote:
> So here's what could be done:
>
> - esdk tools become symlinks in poky/scripts/esdk-tools/. esdk
> environment script puts that in PATH, rather than some custom
> esdk-specific location (the c
On Mon, 30 Oct 2023 at 15:07, Richard Purdie
wrote:
> > a) esdk sets a number of variables from its initialization script that
> > aid with cross-compiling components directly (e.g. the core use case
> > of SDKs). Normal mode doesn't do that, but recently added
> > meta-ide-support will generate
On Thu, 14 Sept 2023 at 14:56, Richard Purdie
wrote:
> There are design elements to this work. We need to work out how we can
> make eSDK and "normal" builds more similar and less of an overhead to
> switch between one and the other. A "bblock all" command does partly
> get you to an eSDK
Thanks, I'm also just now testing the change that also prints what
sstate paths were actually requested when the test fails due to
missing objects.
Alex
On Fri, 27 Oct 2023 at 10:56, Richard Purdie
wrote:
>
> On Fri, 2023-10-27 at 09:21 +0200, Alexander Kanavin wrote:
> >
Signed-off-by: Alexander Kanavin
---
config.py | 1 +
1 file changed, 1 insertion(+)
diff --git a/config.py b/config.py
index 50945b4..0da4c0a 100644
--- a/config.py
+++ b/config.py
@@ -132,6 +132,7 @@ builders_others = [
"buildperf-alma8",
"reproducible-meta-oe&qu
1 - 100 of 682 matches
Mail list logo
