Wouter0100 has quit [Read error: Connection reset by peer]
Wouter0100 has joined #yocto
pgowda_ has joined #yocto
prabhakarlad has quit [Quit: Client closed]
sakoman has quit [Quit: Leaving.]
GNUmoon has quit [Ping timeout: 276 seconds]
xmn has quit [Ping timeout: 256 seconds]
GNUmoon has joined #yocto
k4wsys[m] has left #yocto [#yocto]
alessioigor has joined #yocto
alessioigor has quit [Quit: alessioigor]
<user_>
I trying to print pdf format in the yocto base system using cups library in meta layer, but it is not printing. I am able to print the pdf format in the ubuntu system using the same filter.
vd has quit [Quit: Client closed]
vd has joined #yocto
jpuhlman_ has joined #yocto
deuteron has joined #yocto
geoff_parker has joined #yocto
jpuhlman has quit [Ping timeout: 256 seconds]
<deuteron>
Hey all, how would I go about debugging this: When reparsing REDACTED, the basehash value changed from fa336d603a0e9a9e0edf20fb512a33df to 0b0a44b5fdf3d383d4e0829beff765fa. The metadata is not deterministic and this needs to be fixed.
<deuteron>
I'm trying to add support to the hg fetcher for a "branch" parameter SRC_URI.
geoff_parker has quit [Client Quit]
rob_w has joined #yocto
rob_w has quit [Remote host closed the connection]
rob_w has joined #yocto
<user_>
Hi
pbergin has joined #yocto
vd has quit [Ping timeout: 256 seconds]
<JosefHolzmayrThe>
deuteron: that usually happens if the value of some variable changes. example, are date/time involved somewhere?
<deuteron>
I don't think so. Perhaps AUTOREV is changing between parses somewhow.
<JosefHolzmayrThe>
i think diffsigs or dumpsigs orwhatsitcalled could help you, but its quite a bit beyond my knowledge, sorry.
kyrix has joined #yocto
mckoan|away is now known as mckoan
<mckoan>
good morning
<deuteron>
JosefHolzmayrThe: I seem to have fixed it somehow...
<JosefHolzmayrThe>
\o/
<deuteron>
Perhaps just something stale in sstate?
<deuteron>
Who knows...
<JosefHolzmayrThe>
depending on your situation you can either start digging deeper now, or stick with it.
<deuteron>
Haha, now it's back.
rfuentess has joined #yocto
ana_gasi has joined #yocto
rob_w has quit [Remote host closed the connection]
zyga-mbp has joined #yocto
zww has joined #yocto
zww has left #yocto [#yocto]
zww has joined #yocto
prabhakarlad has joined #yocto
zww has quit [Quit: WeeChat 2.8]
wenwuZhang has joined #yocto
kroon has quit [Quit: Leaving]
<creich>
hey guys, is there a reason for bitbake to NOT put an explicit REDEPEND to the image even though i install a pacakge that uses this REDEPEND?
<creich>
shouldn't it get intalled to the image as well
rob_w has joined #yocto
zyga-mbp has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zyga-mbp has joined #yocto
leon-anavi has joined #yocto
tre has joined #yocto
<qschulz>
creich: no, how do you know your package is not in the imagE?
<creich>
the files of the package are not in the rootfs.
zyga-mbp has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<creich>
but if i explicitly add the library to IMAGE_INSTALL it works as expacted again
<mckoan>
wyre: I just finished a training based on their board last week
<wyre>
oh, I see mckoan thank you ... but I'm still not sure where is actually u-boot if inside the sd card or flashed in NAND
<wyre>
I thought when I close a specific jumper I was running u-boot from sdcard ... but this should implies every SoM will boot with the very same sd card
<wyre>
however some SoMs are able to boot it but some other aren't able
<wyre>
so I'm not sure what's the difference between UBOOT_CONFIG="sd" and UBOOT_CONFIG="nand"
wenwuZhang has quit [Quit: WeeChat 2.8]
<mckoan>
wyre: UBOOT_CONFIG ??= "sd" therefore it will be built for SDcard
<wyre>
sure, so I shouldn't need to set UBOOT_CONFIG in local.conf when building an sdcard image
<mckoan>
wyre: no, that's the default for this machine
<wyre>
but ... despite I've not set that variable or set to UBOOT_CONFIG="sd" ... this SoM is not able to boot just from sdcard I'm having a zimage: Bad magic!
<mckoan>
wyre: which machine?
<wyre>
which apparently doesn't make sense as the u-boot in the sdcard is set to boot the contents of that sdcard
<wyre>
mckoan, I'm not actually using meta-engicam repo anymore, sice I want to build dunfell ... Engicam people recommended me meta-engicam-nxp
<wyre>
dunfell-community-bsp branch
<wyre>
but I'd like to clarify this point about where is actually u-boot flashed
<mckoan>
wyre: I never tested that repo, please ask to Engicam then
<wyre>
and why in the case u-boot is flashed at both (sdcard and nand when I use prboot.sh (engicam script to flash the bootloader)) ... why the u-boot sdcard is not able to boot the sdcard contents?
<wyre>
or why this is successful depending on the SoM I try to boot it
<wyre>
s/I try to boot it/where I'm trying to boot it/
<wyre>
and I think this point is quite similar for all hardware
<wyre>
bc it's more a question about how is u-boot handled in the build process and if it's actually included in the .wic image file
<wyre>
that I'm using to flash my sdcard
ana_gasi has quit [Quit: Client closed]
<wyre>
for sure the u-boot environment depends on if you boot with the jumper closed or not, because I've noticed this experimentally
<wyre>
but I'm not sure if just is the u-boot environment or the whole u-boot
wenwuZhang has joined #yocto
kroon has quit [Quit: Leaving]
wenwuZhang has quit [Client Quit]
wenwuZhang has joined #yocto
leon-anavi has quit [Ping timeout: 256 seconds]
wenwuZhang has quit [Remote host closed the connection]
ana_gasi has joined #yocto
<qschulz>
wyre: anything BSP related is machine specific, there's no rule. It's perfectly possible to have U-Boot boot from eMMC but have its environment stored on SPI-NOR.
<qschulz>
You could even have the SPL in SPI-NOR and U-Boot proper on the SD card
<wyre>
qschulz, SPI-NOR?
<wyre>
and SPL?
<qschulz>
therefore there's also no rule for the wic image. The wic image anyway is just a container (see it as an .iso)
<qschulz>
so the answer is "It depends"
<qschulz>
as always with BSP and HW :)
<qschulz>
SPI-NOR is a storage medium
<wyre>
oh, just like a NAND but thorugh SPI I guess
<qschulz>
SPL stands for second stage bootloader, most likely the bootloader part that is running in SRAM and initializes the DRAM and then loads the full U-Boot into DRAM and jump to it
<qschulz>
the terms don't matter much, I just wanted to highlight that we can't answer your question because it depends on too many things, most of which aren't really related to Yocto
<wyre>
qschulz, you mean it depends on the vendor?
<wyre>
manufacturer?
kayterina has joined #yocto
<qschulz>
wyre: it depends on all actors on the HW side
<qschulz>
and also policy
<wyre>
qschulz, and could I figure this out from the meta-engicam-nxp layer? 🤔
<qschulz>
if you have multiple storage media, then you have multiple options
<qschulz>
wyre: the whole point is Yocto has nothing to do with it, except the wic file.
<qschulz>
so you need to dig into U-Boot recipe and code to understand which defconfig was used, then figure out where the environment is loaded
<qschulz>
usually from U-Boot environment you can find where the kernel is loaded too, etc..
leon-anavi has quit [Remote host closed the connection]
RaulM has joined #yocto
leon-anavi has joined #yocto
RaulM has quit [Ping timeout: 252 seconds]
nrossi[m] has joined #yocto
leonanavi has joined #yocto
wenwuZhang has joined #yocto
leon-anavi has quit [Ping timeout: 252 seconds]
wenwuZhang has quit [Ping timeout: 256 seconds]
pbergin has quit [Quit: Leaving]
ana_gasi has quit [Quit: Client closed]
leonanavi has quit [Remote host closed the connection]
rob_w has quit [Remote host closed the connection]
leon-anavi has joined #yocto
wenwuZhang has joined #yocto
prabhakarlad has quit [Quit: Client closed]
wenwuZhang has quit [Ping timeout: 256 seconds]
RaulM has joined #yocto
frieder has joined #yocto
wenwuZhang has joined #yocto
wenwuZhang has quit [Remote host closed the connection]
zpfvo has quit [Ping timeout: 256 seconds]
zpfvo has joined #yocto
Habbie has joined #yocto
zpfvo has quit [Ping timeout: 252 seconds]
zpfvo has joined #yocto
zpfvo has quit [Ping timeout: 245 seconds]
zpfvo has joined #yocto
zpfvo has quit [Ping timeout: 252 seconds]
zpfvo has joined #yocto
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #yocto
kroon has joined #yocto
troth has quit [Ping timeout: 252 seconds]
sakoman has joined #yocto
troth has joined #yocto
frieder has quit [Remote host closed the connection]
sstiller has quit [Remote host closed the connection]
johntoomey has joined #yocto
camus has quit [Quit: camus]
hpsy has joined #yocto
zpfvo has quit [Ping timeout: 252 seconds]
zpfvo has joined #yocto
maoti__ has joined #yocto
zpfvo has quit [Ping timeout: 256 seconds]
zpfvo has joined #yocto
jpuhlman_ has quit [Ping timeout: 256 seconds]
florian_kc has quit [Ping timeout: 256 seconds]
<dvorkindmitry>
when SRC_URI[sha256sum] is required?
<rburton>
dvorkindmitry: every time a file in SRC_URI is fetched with http
<dvorkindmitry>
if I am using git://...proto=http is it required?
<dvorkindmitry>
https, sorry
<dvorkindmitry>
git://...;protocol=https
<rburton>
no, that's a git fetch
<dacav>
I'm a bit confused by the [e]SDK concept.
<dacav>
The first image I've built was against the repository I share with my team. There's a lot going on there, but I don't think I had to do anything special in order to cross compile: the bitbake invocation take care of everything.
<dacav>
I've also tried to clone yocto and build a vanilla image for x86_64 (just following the quick build steps). Bitbake took care of everything in this case too.
<fray>
an 'SDK" is a compiler + sysroot you use to build your apps.. 'eSDK' is a bundle of the bitbake and layers that you can use for rebuilding the operating system (and making changes)
<fray>
so they have a different, but related, purpose..
<fray>
you can build an SDK from the eSDK..
<fray>
but I always consider it application (singular) vs system building/development
<dacav>
So, I use the SDK to build my software for the target system
<dacav>
I've got a eSDK somewhere then, because it does bundle bitbake, for instance
kroon has quit [Quit: Leaving]
<fray>
yes.
<dacav>
which bitbake -> $poky/bitbake/bin/bitbake
<fray>
Note, if you want to PACKAGE your software for target, then you need the eSDK to build/compile/package
<dacav>
so does bitbake bundle the eSDK?
<dacav>
err... sorry
<fray>
eSDK is constructed from the bitbake + layers used to build the eSDK..
<dacav>
does *poky* bundle it?
<fray>
bitbake is just an engine.. similar to 'make' in concept.
<dacav>
yes, I mistyped
<fray>
the layers (starting with the core a.k.a. meta) is the OpenEmbedded Core definition which drives the build.. and then additional layers add more functionality.
<fray>
poky is made up of a bundle of bitbake + meta + Yocto Project layers..
<dacav>
Ah, so it is because of poky that I don't have to worry of getting the eSDK
<dacav>
but then it is said that qemu is sort-of part of the sdk, although it should be installed separately. which qemu-xxx -> /usr/bin/qemu-xxx. So for that I'm not using any bundled software
kayterina has quit [Read error: Connection reset by peer]
<fray>
some SDKs come bundled with QEMU (and images), but most do not. That is really up to the person building you an SDK.
<fray>
My own SDKs I DO bundle qemu with it, but don't bundle images -- those come separately from other sources.. then the user can use the compiler to build their applicatiosn and deploy them with scp, etc.
<dacav>
Mh... still confused, sorry. Why is the distinction necessary?
<dacav>
For example, if bitbake builds the image for me, why do I need the pre-compiled images? -- apart maybe speed, but then the image won't contain my software
<fray>
it's about use-cases
<dacav>
Or is it something like (1) I get the SDK only -> compiler, sysroot, and (2) I get the image, and (3) I develop my software, use (1) to build and (22) to test...
<dacav>
s/22/2/
<fray>
As an APPLICATION developer, most people have no desire (or sometimes the OS developers restricts) the app developer from building/changing the OS
<fray>
As an OS developer, I WANT the ability to build the OS, and place my applications on top
<dacav>
Ok, I think I got it now
<fray>
So if I'm doing OS development, I usually provide to the app developers an SDK and image(s)
<fray>
as a hybrid App/OS developers (application but needs to customize the OS), then I'd do the eSDK..
<dacav>
Thank you, fray
<fray>
no problem.. the key is YP stuff is flexible for workflows.. but it also does lead to some confusion to make sure you (and the people you work with) are as efficient and working the way they want as possible
akiCA has joined #yocto
codavi has joined #yocto
akiCA has quit [Ping timeout: 256 seconds]
tre has quit [Remote host closed the connection]
kiran_ has joined #yocto
vd has joined #yocto
florian has quit [Quit: Ex-Chat]
kroon has joined #yocto
RaulM has quit [Ping timeout: 252 seconds]
zpfvo has quit [Ping timeout: 252 seconds]
kiran_ has quit [Remote host closed the connection]
zpfvo has joined #yocto
rfuentess has quit [Remote host closed the connection]
kiran_ has joined #yocto
zpfvo has quit [Ping timeout: 256 seconds]
dev1990 has joined #yocto
prabhakarlad has joined #yocto
mckoan is now known as mckoan|away
jorschulko has joined #yocto
<fray>
I did that a few years back, and the feedback was ignored by maintainers.. It isn't hard to do it again honestly..
<fray>
oops wrong channel
jmiehe has quit [Ping timeout: 268 seconds]
kroon has quit [Quit: Leaving]
jorschulko has quit [Ping timeout: 256 seconds]
jorschulko has joined #yocto
pgowda_ has quit [Quit: Connection closed for inactivity]
RaulM has joined #yocto
dj has joined #yocto
leon-anavi has quit [Remote host closed the connection]
RaulM has quit [Ping timeout: 256 seconds]
jorschulko has quit [Read error: Connection reset by peer]
jorschulko has joined #yocto
RaulM has joined #yocto
jorschulko has quit [Quit: leaving]
kroon has joined #yocto
angolini has quit [Quit: Connection closed for inactivity]
RaulM has quit [Ping timeout: 256 seconds]
johntoomey has quit [Ping timeout: 256 seconds]
kroon has quit [Quit: Leaving]
dj has quit [Remote host closed the connection]
RaulM has joined #yocto
hpsy has quit [Remote host closed the connection]
MauroAnjo has joined #yocto
<vd>
from a distro config, should you add packages to image recipes via IMAGE_INSTALL:append, CORE_IMAGE_EXTRA_INSTALL +=, or DISTRO_EXTRA_RDEPENDS/RRECOMMENDS:append?
<vd>
(e.g. packagegroup-core-full-cmdline)
<MauroAnjo>
I can't use bb.utils.contais to append if a package is present on IMAGE_INSTALL? like: ${@bb.utils.contains("IMAGE_INSTALL", "package-name", "true", "false", d)}
RaulM has quit [Ping timeout: 256 seconds]
<vd>
MauroAnjo what is it you're trying to append?
<MauroAnjo>
@vd cmake EXTRA_OECMAKE option, it needs to add some options if packages are present
<vd>
are you doing this from an image recipe?
<MauroAnjo>
no, a layer recipe
<vd>
MauroAnjo: IMAGE_INSTALL is a variable inherited from image.bbclass, is your recipe inheriting this class directly or indirectly?
xmn has joined #yocto
<vd>
MauroAnjo the simpler for what you're trying to achieve is adding a custom variable in your configuration file (local, machine or distro) and using it instead of IMAGE_INSTALL in your above snippet. Same to append the package to your images.
<MauroAnjo>
hum, so a recipe inside a layer will have no way of being aware what packages will be installed?
<vd>
MauroAnjo installed packages are a image recipe thing. You can compile a package without necessarily a image.
<vd>
A image recipe is a compilation of integrated package, but a package by itself has no notion of installed packages whatsoever
<MauroAnjo>
got it, makes sense :) thanks! Will try another approach for this
<vd>
PACKAGECONFIG might be what you're looking for
<vd>
many packages do things like PACKAGECONFIG[foo] = "${@bb.utils.contains("DISTRO_FEATURES", "foo", "--with-foo", "", d)} for example
MauroAnjo has quit [Quit: Client closed]
MauroAnjo has joined #yocto
wenwuZhang has joined #yocto
<MauroAnjo>
looking at the docs to check, but I thought PACKAGECONFIG would be used on build commands, this options I'm trying to conditionally append are on configure part of CMAKE
<vd>
EXTRA_OECMAKE += "${@bb.utils.contains("MY_VARIABLE", "foo", "--foo", "", d)}" will be just fine then
<MauroAnjo>
oh, it seems PACKAGECONFIG worked :)
<vd>
with MY_VARIABLE ??= "" (or a sane default value) in the recipe, and MY_VARIABLE ?= "foobar" in your config files.
wenwuZhang has quit [Ping timeout: 256 seconds]
geoffhp has joined #yocto
RaulM has joined #yocto
MauroAnjo has quit [Ping timeout: 256 seconds]
florian_kc has joined #yocto
dkl_ has quit [Quit: %quit%]
dkl has joined #yocto
kroon has joined #yocto
prabhakarlad has quit [Quit: Client closed]
codavi has quit [Ping timeout: 256 seconds]
jmiehe has joined #yocto
kiran_ has quit [Ping timeout: 252 seconds]
<RP>
sakoman: do we have that db cve exclusions patch in master?
RaulM has quit [Ping timeout: 256 seconds]
florian_kc has quit [Ping timeout: 252 seconds]
stkw0 has joined #yocto
otavio has quit [Remote host closed the connection]
florian_kc has joined #yocto
kroon has quit [Quit: Leaving]
kroon has joined #yocto
<kroon>
RP, what are your thoughts about backporting the deterministic ranlib/ar patches to dunfell/hardknott (once they are stable) ?
<kroon>
stable, as in the patches i mean
<RP>
kroon: probably risky and not of enough benefit to a majority of users?
<RP>
kroon: are you using/testing them there?
<RP>
kroon: I did see your questions, the summit and other meetings has meant I've not managed to formulate replies again, sorry :/
<kroon>
RP, yup, but i have no problem with keeping them locally applied
<kroon>
RP, dont sweat it, i know you are busy guy
<RP>
kroon: I just worry you think I'm ignoring you which I'm not! :)
<kroon>
RP, not at all
<RP>
kroon: you have good questions which are hard to answer! :)
dev1990 has quit [Quit: Konversation terminated!]
<RP>
kroon: Like you, I think I'm torn on whether the cross/native is worth the effort or not. I think I am roughly leaning in favour of trying to go further but that python-native issue you raised is annoying :/
<RP>
kroon: I did wonder if we could work around it with LD_LIBRARY_PATH
<kroon>
RP, aha. that is an interesting idea
<RP>
it doesn't work in general as we can't get it everywhere it may be needed but the python case may be possible to tweak
dev1990 has joined #yocto
<kroon>
RP, hmm I don't see why it wouldn't work everywhere..
<RP>
kroon: you can't selectively apply it to only our "native" binaries
<kroon>
RP, what breaks if we put "export LD_LIBRARY_PATH=..." in native.bbclass ?
<RP>
kroon: the host binaries would start trying to load libs from that path too