ederibaucourt has quit [Ping timeout: 264 seconds]
florian has quit [Ping timeout: 260 seconds]
ederibaucourt has joined #yocto
Xagen has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
goliath has quit [Quit: SIGSEGV]
davidinux has quit [Ping timeout: 260 seconds]
<tlwoerner>
JPEW: moto-timo: in one of my early commits i thought i removed all references to the infradead mailing list, it's obviously dead and has been for a long time
davidinux has joined #yocto
starblue has quit [Ping timeout: 256 seconds]
starblue has joined #yocto
jclsn has quit [Ping timeout: 272 seconds]
jclsn has joined #yocto
Xagen has joined #yocto
Xagen has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
amitk has joined #yocto
Xagen has joined #yocto
|Xagen has joined #yocto
Xagen has quit [Ping timeout: 245 seconds]
sakman has joined #yocto
Abp has quit [Ping timeout: 252 seconds]
Guest78 has joined #yocto
Guest78 has quit [Client Quit]
changqing has joined #yocto
changqing has quit [Quit: Client closed]
sakoman has quit [Ping timeout: 246 seconds]
sakoman has joined #yocto
ecdhe has quit [Ping timeout: 268 seconds]
ecdhe has joined #yocto
Abp has joined #yocto
alessioigor has joined #yocto
rfuentess has joined #yocto
Abp has quit [Ping timeout: 252 seconds]
Abp has joined #yocto
leon-anavi has joined #yocto
rob_w has joined #yocto
legraps has joined #yocto
ehussain has joined #yocto
enok has joined #yocto
xmn has quit [Ping timeout: 245 seconds]
Jones42 has joined #yocto
Jones42 has quit [Client Quit]
Jones42Jones42 has joined #yocto
Jones42Jones42 has quit [Client Quit]
Jones42 has joined #yocto
Jones62 has joined #yocto
Jones62 has quit [Client Quit]
Jones42 has quit [Client Quit]
Kubu_work has joined #yocto
zwelch has quit [Ping timeout: 245 seconds]
michalk0 has joined #yocto
zwelch has joined #yocto
<michalk0>
Hi, I have one recipe that fetch internal git repo and build application, and I need to prepare second recipe that will use this same repo but in different way - second recipe will generate update packages by using scripts that are placed in this same repo. I am thinking about separated recipe, because these update files should not be placed in
<michalk0>
origin image. Do you recommend something specific for that case? I was thinking about preparing class file and inherit in two recipes, or prepare one directory with include and two recipes. Second way is more "clean" for me, but I am not sure how it should be done in best way
rob_w has quit [Remote host closed the connection]
<mcfrisk_>
michalk0: a single recipe (source package) can produce multiple output binary packaged (libs, bins, scripts, examples, docs, plugins, adons)
<mcfrisk_>
/packaged/packages/ ---> more coffee
michalk0 has quit [Quit: Client closed]
vladest has quit [Ping timeout: 260 seconds]
michalk0 has joined #yocto
locutusofborg has quit [Ping timeout: 264 seconds]
locutusofborg has joined #yocto
<michalk0>
mcfrisk_: about /packaged/packages - you mean path in build/tmp/work folder?
ablu has quit [Read error: Connection reset by peer]
locutusofborg_ has joined #yocto
michalk0 has quit [Quit: Client closed]
locutusofborg has quit [Ping timeout: 252 seconds]
<mcfrisk_>
michalk0: images are created using binary packages. recipes build source trees to produce those binary packages. A source tree can produce a lot of things which get packaged to different binary packages. Yes, multiple recipes can be built from a single source tree (SRC_URI) but also a single recipe can produce multiple output binary packages for different purposes
arielmrmx has quit [Ping timeout: 255 seconds]
michalk0 has quit [Quit: Client closed]
michalk0 has joined #yocto
florian_kc has joined #yocto
michalk0 has quit [Ping timeout: 250 seconds]
c-thaler has joined #yocto
michalk0 has joined #yocto
<rburton>
rfs613: so if its _task_ errors then that's nothing to do with packages in the rootfs, and all my suggestions were about packages in the rootfs. can you share the actual error log?
<michalk0>
mcfrisk_: thanks for the explanation :)
Jones42 has quit [Quit: Client closed]
Kubu_work has quit [Remote host closed the connection]
AdrianF has quit [Ping timeout: 256 seconds]
Kubu_work has joined #yocto
michalk0 has quit [Quit: Client closed]
sakoman has quit [Read error: Connection reset by peer]
sakoman has joined #yocto
michalk0 has joined #yocto
starblue has quit [Ping timeout: 268 seconds]
starblue has joined #yocto
michalk0 has quit [Quit: Client closed]
c-thaler has quit [Quit: Client closed]
amitk_ has joined #yocto
amitk has quit [Ping timeout: 256 seconds]
sakoman has quit [Ping timeout: 260 seconds]
<rfs613>
rburton: I reached the same conclusion... studied the logs (with -v -DD) and found a few red herrings... then finally decide to look at the code.
<rburton>
rfs613: seeing the log would let me help a lot more but I guess you end up building u-boot twice which deploys u-boot twice and they both ship the same filename
<rfs613>
rburton: it's looking at manifests from sstate-control. ANd indeed I can see a difference in those manifests between kirkstone & scarthgap.
<rfs613>
rburton: yep, we have to recipes for u-boot, both are built, and indeed they install files in do_deploy() to $DEPLOYDIR
<rfs613>
it is those files which are appearing in the sstate-control manifest, but only in scarthgap.
<rfs613>
on kirkstone the same manifest only has sysroot-providers/u-boot-foobar
<rfs613>
(but no actual filenames)
<LetoThe2nd>
RP: taking a skim read on your friend-making mail, my perspective is that now its the perfect point in time to do things like that.
<RP>
LetoThe2nd: right, this is definitely the time to do this kind of thing
<rfs613>
rburton: so, I think the warning is corret - both do_deploy() really are placing the same u-boot.bin into DEPLOYDOR, the second one overwrites the first.
<rfs613>
rburton: it's just that we got away with it previously (we also copy the file into a subdir with a different name, so the main u-boot.bin was of no concern)
<RP>
LetoThe2nd: we're allowed chainsaws? :)
<LetoThe2nd>
RP: we are.
* RP
suspects that is against an LF policy
* LetoThe2nd
is pretty sure that LF has no policy regarding yard or wood work.
sakoman has quit [Ping timeout: 268 seconds]
mvlad has joined #yocto
Jones42 has joined #yocto
Jones42 has quit [Changing host]
Jones42 has joined #yocto
ehussain has quit [Ping timeout: 260 seconds]
alessioigor has quit [Remote host closed the connection]
cgeye has quit [Quit: Client closed]
<rfs613>
rburton: alright, I got it now. U-boot has a do_install (stock one) as well as our custom do_deploy(). Since we have two copies of the recipe, the same do_install happens in each, and that causes the error. When i stub out do_install in one of our recipes, the error goes away.
<rfs613>
rburton: but I guess the interesting bit is that yocto is recording files during do_install, and reporting conflicts based on those, even when the packages are not being installed into rootfs. Which seems a bit odd?
<rburton>
its not. its recording the contents of the sysroots.
<RP>
rfs613: the issue is conflicts in the sysroots, not the target image
<RP>
DEPENDS = "a b" and a and b have overlapping files in the sysroot so the system errors and asks you which you want. Similar to that
<rfs613>
okay, but why are these (target binaries) going into sysroots? I though that was for sharing stuff (headers, libs) between recipes?
* rfs613
will be back in a few hours
<rburton>
rfs613: again, without seeing the logs its very hard to help. they're probab;y both deploying to the same place
goliath has joined #yocto
enok71 has joined #yocto
enok has quit [Ping timeout: 264 seconds]
enok71 is now known as enok
enok71 has joined #yocto
enok has quit [Ping timeout: 256 seconds]
enok71 is now known as enok
pbiel has joined #yocto
<pbiel>
Hi, I've got a question regarding scarthgap release, gcc version in particular. It seems that in the release the gcc 13.2 is included, however I'm not sure how to understand the following comment form "Notes" section: "GCC 14 scheduled after YP"
lthadeus_away has joined #yocto
<pbiel>
from*
lthadeus_away has quit [Client Quit]
<pbiel>
Does it mean that GCC version for scarthgap will lifted to gcc 14, after the gcc release?
<rburton>
no, it means master will get 14.x
<rburton>
scarthgap may well get 13.3
<RP>
yes, scarthgap will remain on 13 but update down the stable series there most likely
enok has quit [Quit: enok]
enok71 has joined #yocto
fabatera has joined #yocto
sakoman has joined #yocto
<fabatera>
Hi, how can I set the LICENSE when it's proprietary and the license file is inside the package being fetched/built?
<fabatera>
One idea is to set LICENSE = "Proprietary" and use LIC_FILES_CHKSUM ="path_to_the_unpacked_package_file"
<fabatera>
12:12
<fabatera>
Not sure this is the proper way of doing it
<rburton>
set LICENSE=CLOSED and you won't need to set LIC_FILES_CHKSUM, if you're not distributing the recipes
enok71 is now known as enok
<rburton>
if its a recipe that will be distributed then yeah, LIC_FILES_CHKSUM should point to the license text inside the tarball or whatever
<RP>
yocton: I've merged some patches to improve the patch metrics graphs for oe-core. I'm wondering if we want to copy those changes for meta-oe's graphs?
* RP
will probably get to it eventually but I'm open to help if anyone is interested :)
<yocton>
RP: most likely. Improvement on OE-Core graphs would surely benefit meta-oe graphs
<RP>
yocton: the oe-core ones aren't quite right yet but getting there
<yocton>
I'll send this to my padawan. He may find this interresting :)
Abp has quit [Read error: Connection reset by peer]
Marmottus11 has joined #yocto
Abp has joined #yocto
davidinux has quit [Quit: WeeChat 3.5]
rfuentess has quit [Remote host closed the connection]
sotaoverride is now known as Guest4069
Guest4069 has quit [Killed (cadmium.libera.chat (Nickname regained by services))]
xmn has joined #yocto
ctraven has joined #yocto
Abp has quit [Ping timeout: 246 seconds]
Abp has joined #yocto
AdrianF has joined #yocto
enok has quit [Ping timeout: 268 seconds]
florian_kc has quit [Ping timeout: 245 seconds]
florian has quit [Quit: Ex-Chat]
nerdboy has quit [Ping timeout: 252 seconds]
Kubu_work has quit [Quit: Leaving.]
nerdboy has joined #yocto
<rfs613>
rburton: RP: ERROR: test-image-1.0-r0 do_image_complete: The file /boot/u-boot.bin is installed by both u-boot-rzn1 and u-boot-rzn1-spkg, aborting
<rburton>
well, there you go
<rburton>
you're definitely installing two u-boot packages into your image
<rfs613>
no, the error is misleading
<rburton>
oh thats the sysroot validation.
<rburton>
you're depending on both and they both ship the same file
<rburton>
just make your image depend on the right bootloader?
<rfs613>
there are indeed two u-boot packages, and they both have a do_install, which indeed installs the same files into $DEPLOYDIR
<rburton>
and they're both being depended by your image
<rfs613>
neither of the u-boot packages produces a .deb (intentionaly). We have a do_deploy() in each package, which copies the file to another name/location.
<rfs613>
but we are inheriting the default do_install from u-boot recipe in oe-core. If I declare my own do_install to override that, problem goes away.
<rfs613>
IMAGE_INSTALL does not include either of the u-boot recipes.
<rfs613>
they onluy get build due to EXTRA_IMAGEDEPENDS
<rburton>
right
<rfs613>
so I am wondering now, why is do_install being called... i guess there's a dependency chain
<rburton>
that says "when building these images, also deploy these other recipes"
<rburton>
and you're deploying two u-boot recipes that ship the same file
<rburton>
just stop the image depending on _both_ u-boots
<RP>
rfs613: the problem isn't do_install, it is do_deploy
<rfs613>
ah but we want two u-boots to be built (but not installed into the image)
<RP>
ah, probably not. That is probably do_install
<rburton>
rfs613: whats the point of building two if one of them isn't being used?
<rfs613>
rburton: building in CI for multiple configurations/boards.
<rfs613>
yep, its' not present in my kirkstone branch... so that likely explains why we "got away" with this
<rfs613>
instead of having two recipes for u-boot, I should probably make use of UBOOT_MACHINE and UBOOT_CONFIG options in the stock recipe. But it's a little unclear to me, how to support config fragments in addition to multiple configs.
khem has joined #yocto
<khem>
RP: I would like to run few gcc-14 branch runs is AB bandwidth available ? I know we are close on scarthgap release so dont want to create more variability since it will create quite a lot of new sstate objects
<rburton>
khem: i did a side project with it and it worked lovely, so thanks for the branch
<dvergatal>
hmmm why setVar in one task does not make the change visible for another task of the same recipe?
<dvergatal>
if i do the same but with python __anonymous() {} than the change is visible...
<rburton>
iirc each task runs in its own copy of the data store, so you can't just bubble changes between tasks like that
<dvergatal>
rburton: aha and it is not possible?
<rburton>
(rp correct me if i'm wrong)
<rburton>
not between entirely independent tasks, no
<rburton>
you could re-run the later tasks, and bitbake would need to somehow know what those other data values were
<dvergatal>
aha I can do a prefunc
<rburton>
yeah they work, same context
<dvergatal>
ok got it
<dvergatal>
rburton: thx
sakoman has joined #yocto
<RP>
khem: we're ok from a scarthgap perpective but the autobuilder is below capacity at the moment for reasons. You can probably go ahead but carefully. Are you wanting a-full or targetted things?
<RP>
rburton: you are not wrong :)
<RP>
khem: I also have a heavy build running atm :(
enok has joined #yocto
<marex>
rfs613: u-boot should be working perfectly, what's up ?
florian_kc has joined #yocto
<rfs613>
marex: oh, this is a vendor created complexity, that broke on upgrade to scarthgap.
<rfs613>
but I am thinking whether we can eliminate it and just use the oe-core u-boot recipe
<khem>
RP: I plan to run it over weekend, I am still traveling
<marex>
rfs613: or by using mainline U-Boot ? :)
<rfs613>
the thing I'm not clear about, is: we want to generate two u-boot binaries, each with the same basic _defconfig, but a config fragment to adjust some settings.
<khem>
rfs613:look how meta-ti does it
* rfs613
looks
<marex>
rfs613: why do you need two u-boot builds per one OE build btw ?
<marex>
rfs613: isnt it possible to generate single u-boot binary ?
<rfs613>
marex: for a variety of reasons, we want to build multiple u-boots as part of the same OE build.
<marex>
hum
<rfs613>
marex: so the obvious one is secure vs non-secure boot.
<marex>
rfs613: you mean signed vs. unsigned ? On some SoCs that is possible with single binary :)
<marex>
rfs613: I generally try to stick to single multi-purpose binary because it is easier for users to decide which binary to install on their system ; if there is only one, the choice is easy
<rfs613>
marex: I mean stuff like CONFIG_ARMV7_NONSEC
<rfs613>
eg. which "world" are we executing in, and does u-boot switch worlds upon hand-off?
<marex>
rfs613: bootm_boot_mode env var can toggle between the two, can it not ?
<marex>
rfs613: my recollection may be fuzzy tho, and maybe this is better discussed in #u-boot
<rfs613>
some of this affects very early boot code, so it wuold be difficult to chang at runtime
<rfs613>
indeed, i'm not trying to fix uboot here, I was just trying to understand why we have problems building our recipes under scartgap... and I now know why that is ;-)
<marex>
rfs613: ack
<rfs613>
khem: the TI u-boot recipe is interesting, esp the u-boot-mergeconfig.inc ... they add a new variable for the fragments, instead of pickign them out of SRC_URI... which I like better, but I didn't even consider it before, as I didn't want to "swim upstream"
<rfs613>
(that was probably not the right phrase... I mean that the oe-core handles fragments by looking for *.config in SRC_URI... so I assumed this was the "correct" way... even though separate variable makes more sense to me!)
davidinux has joined #yocto
<denix>
rfs613, khem: u-boot recipe looks for *.cfg in SRC_URI for config fragments, correct. but it handles them out of order, unfortunately, as U-boot itself has the concept of config fragments with in-tree *.confg files. there's no way to apply OE out-of-tree *.cfg *AFTER* in-tree *.config, hence meta-ti had to add that extra handling...
<rfs613>
denix: ah yes, the *.config is in u-boot itself... whereas yocto uses *.cfg
<rfs613>
denix: i did not realize they are not handled in order... that could be problematic, resulting in differnent .config in the end
<denix>
indeed
<rfs613>
do you know if it happens for just *.cfg in the SRC_URI alone?
<khem>
rfs613: I did not suggest it for config fragments but how it runs multiple builds and generates multiple u-boots binaries
<khem>
merge config is pretty much handled by cml1 class anyway
<moto-timo>
rfs613: the mechanism with *.cfg fragments for the linux kernel is not (yet) implemented for u-boot.
<rfs613>
moto-timo: I've used patch files for this in the past, but they are a headache anytime you change the base config.
<moto-timo>
rfs613: that is the mechanism you have at this time.
<moto-timo>
has anybody done Yocto builds on Ubuntu 24.04 yet? Trying to create the crops container libegl1-mesa is no longer available, so I am not sure if it should be dropped or replaced with libegl1-mesa-dev