Wouter0100 has quit [Remote host closed the connection]
Wouter0100 has joined #yocto
rsalveti has quit [Quit: Connection closed for inactivity]
rusam has joined #yocto
amitk has joined #yocto
rusam has quit [Quit: Leaving...]
sakoman has quit [Quit: Leaving.]
kroon has joined #yocto
olani_ has quit [Ping timeout: 246 seconds]
olani- has quit [Ping timeout: 246 seconds]
olani has quit [Ping timeout: 244 seconds]
rfuentess has joined #yocto
alessioigor has joined #yocto
alessioigor has quit [Client Quit]
Wouter0100 has quit [Remote host closed the connection]
Wouter0100 has joined #yocto
peoliye has quit [Quit: Client closed]
locutusofborg has joined #yocto
mvlad has joined #yocto
nemik has quit [Ping timeout: 256 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 244 seconds]
nemik has joined #yocto
matman has joined #yocto
<matman>
Having trouble figuring out how to have a different native compiler/gcc from target.. Is that not a thing?
<kroon>
matman, not sure I get what you are after. you want to build the target binaries with some specific compiler ?
<matman>
I want the target to use an older version of gcc/glibc but a newer version for native
vladest has quit [Quit: vladest]
<kroon>
matman, you want to be able to run an older gcc on the target ?
<kroon>
or build the target using an older gcc ?
<matman>
Sorry.. I want to compile the target with an older version of gcc..
<matman>
no gcc running on target
<kroon>
since yocto usually builds the cross-compiler for target (unless you are using an external toolchain), you'd need to modify whatever yocto release you are on to use that version of gcc
<kroon>
but I don't have much experience with external toolchains, maybe thats the easiest option
<matman>
I copied the gcc/glibc from pyro and they build and I can cross compile to target.. The problem is building an image the buildtools-tarball requires virtual/nativesdk-x86_64-sdk-linux-gcc-initial which does not exist
GNUmoon has quit [Remote host closed the connection]
<matman>
Perhaps I could play a game where I prefix the gcc compiler with a different name.. then preferred provider for PREFERRED_PROVIDER_virtual/${TARGET_PREFIX}gcc and friends....
GNUmoon has joined #yocto
<kroon>
well, this is where my yocto black magic skillz end unfortunately
xmn has quit [Ping timeout: 256 seconds]
twnqx has joined #yocto
nemik has quit [Ping timeout: 244 seconds]
nemik has joined #yocto
prabhakarlad has joined #yocto
nemik has quit [Ping timeout: 240 seconds]
nemik has joined #yocto
matman has quit [Read error: Connection reset by peer]
leon-anavi has joined #yocto
denisoft81 has joined #yocto
rusam has joined #yocto
denisoft81 has quit [Quit: Leaving]
rusam has quit [Quit: Leaving...]
florian has joined #yocto
<rburton>
next time matman appears can someone ask why buildtools-tarball is involved at all
nemik has quit [Ping timeout: 256 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 240 seconds]
nemik has joined #yocto
goliath has joined #yocto
rfuentess has quit [Remote host closed the connection]
Herrie has quit [Ping timeout: 246 seconds]
seninha has joined #yocto
rfuentess has joined #yocto
Herrie has joined #yocto
denisoft81 has joined #yocto
seninha has quit [Quit: Leaving]
seninha has joined #yocto
kroon has quit [Quit: Leaving]
florian__ has joined #yocto
kroon has joined #yocto
ardo has quit [Read error: Connection reset by peer]
ardo has joined #yocto
denisoft81 has quit [Quit: Leaving]
xmn has joined #yocto
TundraMan is now known as marka
kroon has quit [Quit: Leaving]
camus has quit [Ping timeout: 246 seconds]
roussinm has joined #yocto
<roussinm>
Yesterday I asked about how to get a complete native sysroot from the sdk and someone answered me with the build-extended-tarball, seems to works. But I was wondering, in theory, everything in there could be packaged inside a meta-toolchain-mysdk.bb, right? So I wouldn't have to build two recipes to get a complete sdk working.
<RP>
roussinm: I think that could work, yes
<roussinm>
RP: I don't think its possible to require or inherit the buildtools-extended-tarball?
<RP>
roussinm: no, that wouldn't work
<roussinm>
RP: hmm, how hard would it be to modify the recipe/code to make that possible?
<RP>
roussinm: probably easiest would be to move the TOOCHAIN_HOST_TASK definitions to an include file since I think ultimately it is that you're interested in?
sakoman has joined #yocto
<roussinm>
RP: Yes, that's what I was thinking too for a solution to my problem, moving them to a .inc.
leonanavi has joined #yocto
leon-anavi has quit [Ping timeout: 246 seconds]
OnkelUlla has quit [Ping timeout: 260 seconds]
florian__ has quit [Ping timeout: 240 seconds]
florian has quit [Quit: Ex-Chat]
GNUmoon has quit [Remote host closed the connection]
amitk has quit [Ping timeout: 246 seconds]
GNUmoon has joined #yocto
prabhakarlad has quit [Quit: Client closed]
wesm has left #yocto [#yocto]
ardo has quit [Ping timeout: 256 seconds]
ardo has joined #yocto
leonanavi has quit [Remote host closed the connection]
leon-anavi has joined #yocto
nemik has quit [Ping timeout: 240 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 240 seconds]
nemik has joined #yocto
mckoan is now known as mckoan|away
PascalBach[m] has quit [Quit: You have been kicked for being idle]
rfuentess has quit [Remote host closed the connection]
<tlwoerner>
a vendor BSP layer instructs me to run 2 bitbake commands, then hand-assemble the sd card by using artifacts from both bitbake commands
<tlwoerner>
i'm hoping to wic-ify the process
<tlwoerner>
i can have the 2nd bitbake command run by adding it to WKS_FILE_DEPENDS
<tlwoerner>
wic's "--source rootfs" doesn't seem to allow me to add arbitrary files to the image
<tlwoerner>
"--source bootimg-partition" does, but creates a separate /boot partition (which isn't what i need)
<tlwoerner>
so it looks like i have to create my own wic plugin
<tlwoerner>
one which is very similar to "--source rootfs" but allows me to add one arbitrary file from $DEPLOY_DIR_IMAGE
<tlwoerner>
is it possible to extend "--source rootfs" or do i have to start with a copy+paste of "--source rootfs" then extend it?
<sotaoverride>
why might PACKAGECONFIG_append = " python3" in a bbappend for libgpioid work but not somthing like DISTRO_FEATURES_append = " systemd wifi bluetooth python3" ??
<JaMa>
sotaoverride: bibake -e or bitbake-getvar will tell you faster than us
<RP>
sotaoverride: you're changing distro_features in a bbappend?
<sotaoverride>
RP: no, addting python3 as a distro feature doesnt work for libgpioid, but giving libgpioid a bbappend with PACKAGECONFIG_append = " python3" works
<smurray>
sotaoverride: python3 isn't a distro feature in oe-core, so I can't see why you'd expect that to work
<sotaoverride>
smurray, is there a doc or something which lists what all can be set as a distro feature in oe-core?
<sotaoverride>
or a bbclass or something even?
<smurray>
sotaoverride: and the libgpiod recipe would have to be looking at DISTRO_FEATURES, which it does not
<sotaoverride>
smurray: how do you get a recipe to start looking for distro features (just curious)
<smurray>
actually, I take that back, it does look for ptest in the version in meta-oe master
<sotaoverride>
ptest is a distro feature?
<sotaoverride>
what it that a python testing framwork or something?
<smurray>
p = package, ptest drives building self or unit tests into a -ptest package and installing them so they can be run on-target
<smurray>
sotaoverride: if you look for use of bb.utils.contains or bb.utils.filter with DISTRO_FEATURES, you'll find many examples in PACKAGECONFIG definitions in recipes
<smurray>
sotaoverride: as for all the valid distro features in oe-core / poky, I'm not aware of a single list, which is maybe a documentation project for someone
<Saur[m]>
Since any recipe in any layer can add a test for a new distro feature, I doubt making such a list is worth the trouble as it will basically always be out-of-date...
<sotaoverride>
smurray: whats libgpiod looking for ptest got to do with libgpiod being declared as a distro feature in oe-core or not?
<smurray>
sotaoverride: nothing, except it's an example of how using DISTRO_FEATURES to define PACKAGECONFIG, which is what you seem to be asking about
<Saur[m]>
There is nothing magical about `DISTRO_FEATURES`. It is just a variable. For anything to happen, recipes must explicitly look at it and decide themselves what to do if a given feature is set.
<sotaoverride>
Ok just to make sure we are all on the same page here, I was thinking if python3 is setup as a distro feature in my distro config, then indivudal recipes, like libgpiod, dont have to worry about adding python3 to their PACKAGECONFIG
<smurray>
that is definitely not the case
<sotaoverride>
yikes, ok let me just go readup a little on distro features first...
sakoman has quit [Quit: Leaving.]
sakoman has joined #yocto
leon-anavi has quit [Remote host closed the connection]
goliath has quit [Quit: SIGSEGV]
peoliye has joined #yocto
nemik has quit [Ping timeout: 246 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 246 seconds]
nemik has joined #yocto
peoliye has quit [Quit: Client closed]
florian__ has joined #yocto
florian__ has quit [Ping timeout: 240 seconds]
mvlad has quit [Quit: Leaving]
goliath has joined #yocto
nemik has quit [Ping timeout: 255 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 240 seconds]
peoliye has joined #yocto
nemik has joined #yocto
<Xagen>
is there a tool for migrating formats when moving from dunfell based recipes to kirkstone?
<smurray>
Xagen: see convert-overrides.py in scripts/contrib
<Saur[m]>
Xagen: And convert-variable-renames.py
nemik has quit [Ping timeout: 240 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 240 seconds]
nemik has joined #yocto
Vonter has quit [Ping timeout: 240 seconds]
halstead[m] has joined #yocto
halstead[m] has left #yocto [#yocto]
twnqx has quit [Ping timeout: 246 seconds]
<sotaoverride>
is thre a relatively simple example where cmake or some other build tool is picking up PACKAGECONFIG enabled features
<RP>
sotaoverride: cmake.bbclass just does EXTRA_OECMAKE:append = " ${PACKAGECONFIG_CONFARGS}"
<sotaoverride>
RP: ok so basically im just trying to find an easy to follow example where a set of PACKAGECONFIGs are opted for / selected. What are the known mechanisms of doing that ... ...
<sotaoverride>
for instance we have dlt-daemon_2.18.7.bb:PACKAGECONFIG[dlt-adaptor] = "-DWITH_DLT_ADAPTOR=ON,-DWITH_DLT_ADAPTOR=OFF,,dlt-daemon-systemd", now how do i set dlt-adaptor to -DWITH_DLT_ADAPTOR=ON for instance?
<sotaoverride>
RP: ok thats just adding dlt-adaptor to dlt-daemon's PACKAGECONFIG block. I want dlt-adaptor to be initialized with one of the possible features , -DWITH_DLT_ADAPTOR=ON,-DWITH_DLT_ADAPTOR=OFF,,dlt-daemon-systemd, how do I make that selection..
<sotaoverride>
PACKAGECONFIG:pn-dlt-daemon:append makes sense when I want to add on to the possible options for dlt-adaptor...
<sotaoverride>
Im more trying to figure how to select an option..
<RP>
sotaoverride: your question makes no sense. Either this feature is enabled (present in PACAGECONFIG) or it is disabled (not present in PACKAGECONFIG)
<RP>
sotaoverride: the items you list are the configuration options used in either case and runtime dependencies needed. Did you look at the manual for PACKAGECONFIG?
<RP>
sotaoverride: note that PACKAGECONFIG is a separate variable to PACKAGECONFIG[dlt-adapter] which is a flag of that variable
<RP>
PACKAGECONFIG "abuses" flags as it's implementation
tlwoerner has quit [Ping timeout: 255 seconds]
<sotaoverride>
RP: ive been looking at the manaul. Lets talk about the example in the manual for PACKAGECONFIG. The manaul says the gtk feature can have 3 possible options PACKAGECONFIG[gtk] = "--with-gtk3,--without-gtk3,gtk+3". What I dont quite understand is how these options are enabled.
<sotaoverride>
manuals just a little confusing when its comes to PACKAGECONFIG, I'll revist it later and try to make sense of it...
florian__ has joined #yocto
xmn has quit [Quit: ZZZzzz…]
florian__ has quit [Ping timeout: 248 seconds]
seninha has quit [Remote host closed the connection]