<qschulz>
argonautx: you should use _append in configuration files BTW, otherwise I don't know, are you sure that /usr/src/kernel directory is in kernel-devsrc? oe-pkgdata-util find-path /usr/src/kernel
<qschulz>
jonesv[m]: no, this does not work. You need to pass the exact path to your init script, not the directory
<qschulz>
17:55:00 qschulz | jonesv[m]: a file can only appear in one package, so the first FILES to have a regex matching the file gets it
kayterina has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
alessioigor has quit [Client Quit]
alessioigor has joined #yocto
BCMM has joined #yocto
florian has joined #yocto
kayterina has quit [Read error: Connection reset by peer]
kayterina has joined #yocto
<sstiller>
How can I disable a PACKAGECONFIG entry for target only and leave it for -native?
<sstiller>
I want to remove python from my target. I figured out, that PACKAGECONFIG_remove += "python" removes the runtime dependency for a lot of recipes.
<sstiller>
But now I get issues with itstool-native which requires python support of libxml2.
<qschulz>
sstiller: PACKAGECONFIG_remove_class-target, but it'd probably be cleaner to just redefine PACKAGECONFIG for the target with PACKAGECONFIG_class-target =
twinning[m] has quit [Quit: You have been kicked for being idle]
zpfvo has quit [Ping timeout: 240 seconds]
jmlemetayer[m] has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
alessioigor has quit [Client Quit]
alessioigor has joined #yocto
zpfvo has joined #yocto
<sstiller>
@qschulz: Thank you! PACKAGECONFIG_remove_class-target does not work, (PACKAGECONFIG_class-target is not set). Setting PACKAGECONFIG_class-target seems to work.
<sstiller>
Does it mean, that now I have to check all the used recipes for their (default) PACKAGECONFIG values and decide, if I need them?
<mrpelotazo>
what could cause a package listed in IMAGE_INTALL_append in an image recipe to not be installed in the image?
<wCPO>
Is there a preferred task to add do_deploy after/before if I have a recipe with only do_deploy?
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
alessioigor has quit [Remote host closed the connection]
alessioigor has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
goliath has joined #yocto
<rburton>
ndec_: was the BoF recorded?
<ndec_>
yes
<rburton>
ndec_: is there any where i can watch it?
<rburton>
the schedule just links to the zoom
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
<ndec_>
rburton: right. it doesn't seem to be there yet.. they told us it would be recorded and available.. i will ask around.
<rburton>
thanks
<qschulz>
sstiller: PACKAGECONFIG_remove_class-target should work, are you sure you didn't type PACKAGECONFIG_class-target_remove instead?
<qschulz>
mrpelotazo: first, check with bitbake -e <image_recipe> that your package is really in IMAGE_INSTALL
<qschulz>
if it is, check that your package actually contains what you expect it to contains with oe-pkgdata-util list-pkg-files <pkg>
<sstiller>
qschulz: I did some tests with libxml2. The default PACKAGECONFIG is "python ipv6"
<sstiller>
PACKAGECONFIG_class-target = "ipv6" --> same as above
<sstiller>
PACKAGECONFIG_pn-libxml2_class-target = "ipv6" --> breaks the compilation of libxml2-native and does other strange things. But the resulting PACKAGECONFIG variable looks good.
<sstiller>
PACKAGECONFIG_remove_pn-libxml2 = "python" --> same as above
<sstiller>
PACKAGECONFIG_remove_class-target = "python3" --> no visible effect.
<sstiller>
PACKAGECONFIG_remove = "python" --> also removes python from the libxml2-native, what I don't want
Schlumpf has joined #yocto
<qschulz>
sstiller: are you modifying this PACKAGECONFIG from a bbappend?
<qschulz>
also is this a typo or did you write PACKAGECONFIG_remove_class-target = "python3" instead of PACKAGECONFIG_remove_class-target = "python" ?
<sstiller>
The typo is only here in the IRC. It's not in a .bbappend. I was hoping that I can disable python for all recipes in one place (distro conf).
<RP>
sstiller: if doing that from a config file, *always* use a pn- override in there
<qschulz>
RP: the point is they don't want to have it package specific, they want it global
<qschulz>
like, to apply to all recipes
* RP
isn't convinced that is a great idea
<qschulz>
s/package specific/recipe specific/ (ugh, this pn naming still messes up with my brain)
<qschulz>
-with for proper english :)
<qschulz>
sstiller: proper way would be to have a bbappend per recipe, and possibly a PACKAGE_EXCLUDE = "python" (maybe python-core?) so that you're almost sure it does not make it to the image if you forget to append to a recipe using python
<qschulz>
also... PACKAGECONFIG is not the only way to pull in python in your image, it can be in DEPENDS and in RDEPENDS/RRECOMMENDS too
camus has quit [Ping timeout: 268 seconds]
<qschulz>
I don't think you'll be able to have a generic solution for this unfortunately
camus has joined #yocto
<RP>
I'd have thought PACKAGECONFIG_remove_class-target would "work" but might have some interesting side effects
leon-anavi has quit [Quit: Leaving]
rob_w has quit [Quit: Leaving]
yates has quit [Remote host closed the connection]
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
leon-anavi has joined #yocto
camus has quit [Quit: camus]
<qschulz>
RP: me too, surprised it does not work /me shrugs
<jsandman>
Hello! How do people manage having multiple MACHINE configurations when generating eSDK? Surely there is no need to generate several eSDK installers as the eSDK will build whatever MACHINE you select in local.conf. It is just a bit strange generating an eSDK selecting a MACHINE and then building other arquitectures inside this eSDK.
<jsandman>
Is there something like the multiarch thing that can be setup for bitbake?
xmn has quit [Ping timeout: 245 seconds]
Schlumpf has quit [Quit: Client closed]
override_ has quit [Quit: Lost terminal]
override1 has quit [Quit: Lost terminal]
override has quit [Quit: Lost terminal]
<sstiller>
qschulz: PACKAGECONFIG_remove_class-target_pn-XXX usually works. And if not, PACKAGECONFIG_remove_class-target in a bbappend helps.
override has joined #yocto
<override>
trying to remember what can I put in my image recipe/config to get a compressed rootfs along with its bmap and hash.
<qschulz>
ndec_: I'll try to write a proper mail but I think we could move the content of yocto-docs/documentation/sphinx-static into its own git repo and just fetch its master branch for every doc release we have
<qschulz>
then it's always in sync and there's only one change to make
<qschulz>
though they still are duplicated for each version of the docs, so it
<qschulz>
s just a different way to do the find command we currently have
<ndec_>
i would be curious to find out how others are doing it.. we are not doing something too unique here..
<qschulz>
RP: AFAICT, only 3.3 has this issue but I'd need to check
<RP>
qschulz: I just remember once putting X.X.0 into the distro config and the world ended, I had to rebuild the release
<RP>
qschulz: the tags are shared in the same format with other repos
<qschulz>
RP: I meant, really moving the tag to another commit, not changing the naming convention
<qschulz>
(though, that was something I raised on the ML too but that was not what I wanted to talk about right now :) )
<RP>
qschulz: ah, that could be ok. they're signed so you'd have to talk to michael
<RP>
(MichaelH)
<qschulz>
RP: that'd be nice, because currently 3.3 (and not 3.3.1, 3.3.2, etc..) is detected as dev release
<qschulz>
RP: ok, I'll send an RFC patch and Cc Michael in addition to usual ML and people :)
<qschulz>
ndec_: BTW, we probably could have your release array in a different js file in a different repo and use $.load() from jquery, on paper that seems possible
<zeddii>
override: do you have bmap in your IMAGE_FSTYPES ?
<qschulz>
ndec_: abort, got my thoughts mixed up. sorry for the noise :)
ex-bugsbunny has joined #yocto
<JPEW>
RP: I didn't see the email to comment, but on the image-artifacts-name change, isn't BUILD_REPRODUCIBLE_BINARIES == "1" the thing to check instead of inherits("reproducible_build") ?
<RP>
JPEW: we're effectively getting rid of that I think as it doesn't really work
<RP>
JPEW: patches aren't emailed yet, I was trying to get them to actually work first
<RP>
JPEW: the sstatesig one is horrible :(
<JPEW>
RP: Yes... I saw that
<RP>
JPEW: (it got worse)
jwillikers has joined #yocto
jwillikers has quit [Remote host closed the connection]
artri has joined #yocto
jwillikers has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
alessioigor has quit [Remote host closed the connection]
alessioigor has joined #yocto
alessioigor has joined #yocto
whuang0389 has joined #yocto
artri has quit [Quit: Leaving]
<dwagenk>
Wow, the biggest files in my yocto DL_DIR are github.com.android.platform_frameworks_base, around 3 GB, no matter if it's the git dir or the tar.gz mirror tarball. And what is it there for? A couple MB of ttf fonts from meta-oe/recipes-graphics/ttf-fonts/ttf-droid_git.bb
<dwagenk>
Now looking into ways to minimize this. But the subpath parameter for the git fetcher is only relevant for the do_unpack step, not for downloads and the tarball mirrors.
<dwagenk>
Partially cloning git repositories seems to be possible with recent git versions, but would need adaptions in the git fetcher.
<dwagenk>
Maybe downloading the 9 ttf files + accompanying license file individually via the wget fetcher would be an alternative. Not the nicest solution, but downloading and storing ~3GB of useless data is also not nice. Especially since we plan to archive the sources for each release to have full offline rebuildable releases.
<override>
zeddii:: thanks, ill try adding bmap to IMAGE_FSTYPES
<override>
also trying to remeber, to get a recipe template for a python project from a git repo, we can just do devtool add recipe-name-here url-to-repo-here ?
<qschulz>
dwagenk: BB_GIT_SHALLOW="1" ?
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
sakoman has joined #yocto
<qschulz>
wondering no why that is not the default?
<qschulz>
now*
<dwagenk>
qschulz first time I see that variable. As far as I understand git shallow cloning it justs skips parts of the history. But this is so big, because of the files contained in the git repository.
Guest9115 has joined #yocto
<override>
ive started getting this weird FileNotFoundError when I try making devtool fetch from a repo tool and create me a recipe
<override>
any idea why that might be?
<override>
used to work for me in the past
<Guest9115>
I need to split SRCPV in a bb recipe. Is there a util functio to use for that? Looking thru oe.utils but could not find anything.
<RP>
dwagenk: one of the side effect of shallow clones is cut down mirror tarballs
<RP>
qschulz: shallow clones have uses but are hard to update the checkouts and so on so have downsides
<dwagenk>
RP ok, will try that. Downloading and temporarily storing unneeded data is fine. As long as I don't have to archive it all I'll be happy with the solution.
<RP>
dwagenk: I think it might also use the subpath parameter but it may pay to glance at the fetcher code
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
<dwagenk>
RP: tried that, since it would be a very easy adaption (setting subpath=data/fonts in the SRC_URI instead instead of setting S to ${WORKDIR}/git/data/fonts). It doesn't change the size of downloads and mirror tarballs. I haven't looked into the code, but I'm pretty sure it's only used during the do_unpack step.
oobitots has quit [Ping timeout: 256 seconds]
<RP>
dwagenk: I mean both shallow and subpath
<dwagenk>
ah OK, I'll try the combination!
<RP>
dwagenk: looking at the code I think you're right and I'm confusing some code paths
<JosefHolzmayrThe>
fabatera: & doesn't make much sense with nographic, and you usually don't need to pass machine and image. what happens with just "runqemu nographic slirp"?
<RP>
JPEW: around? I think I've stumbled onto code you changed for reproducibility and am finding different breakage :/
<RP>
JPEW: 'INSTALL_DATA': 'FIXME_HOSTTOOLS_DIR/install -c -m 644',,vs 'INSTALL_DATA': 'FIXME_HOSTTOOLS_DIR/install -c -m ' \n '644' was the original issue I was trying to fix
<RP>
JPEW: but it looks like there are things making assumptions about a variable per line
tnovotny has quit [Quit: Leaving]
<override>
thought i was maybe mixing up devtool with recipetool but neither worked
<override>
hmm
<override>
wonder what im doing wrong here
<override>
i wonder i wonder
<JPEW>
RP: I'm a little confused about your patch because are reformatting the sysconfig files in do_package?
<JPEW>
Oh, are you trying to reformat them for the sysroot also?
<fabatera[m]>
<JosefHolzmayrThe> "fabatera: & doesn't make much..." <- It is starting normally (builder is slow today). But I wanted to send it to the background, continue development and test with devtool deploy-target
<JosefHolzmayrThe>
fabatera: i'd rather use tmux or screen and run it in two distinct terminals
Flumpy33 has quit [Ping timeout: 240 seconds]
sstiller has quit [Quit: Leaving]
oobitots has joined #yocto
<override>
so i accidently deleted build/workspace
<dwagenk>
RP qschulz Down to a mirror tarball of around 100MB with BB_GIT_SHALLOW.
<override>
is threre a way to regenrate it? my minimal image recipe and all arent working either
<dwagenk>
no difference with subpath+shallow vs just shallow.
<fabatera[m]>
Alrigth! I was following one of your videos actually. :)
<fabatera[m]>
Then I've watched another video from Tim Orling sending it to background (without nographic, but it doesn't work for me). Thanks!
<fabatera[m]>
<JosefHolzmayrThe> "fabatera: i'd rather use tmux or..." <- Regarding my answer above
<ex-bugsbunny>
hi
<ex-bugsbunny>
I currently have a problem with bitbake-layers in conjunction with a self written python script and hope to find an answer here after my internet search didn't help me
<ex-bugsbunny>
my script shall set up build environment for a bsp by creating local.conf and bblayers.conf with the help of standard oe-init-build-env script (generating standard files if not yet present) and modifying it afterward
<ex-bugsbunny>
for modification of bblayers.conf I normally use "bitbake-layers add-layer" for all additionally needed layers
<dwagenk>
RP: I don't think subpath can be used to strip dwn the mirror tarball even further. The tarball contains a (shallow) bare git repository, while the subpath affects the checked out sources only.
<ex-bugsbunny>
in the past that worked without problems, but for a new bsp for an intel based board, the intel bsp config include configuration snippets which are part of one of their layers
<ex-bugsbunny>
consequentially, adding layers with bitbake-layers fails due to a not startable bitbake server caused by missing configuration files residing in one of the layers to be added, a classical chicken/egg problem ;-/
<ex-bugsbunny>
is there a possibility to use bitbake-layers command add-layer without involving any checks by a server?
<ex-bugsbunny>
I'd like to avoid hand crafting layer management given that there actually is a standard tool for that :-D
<qschulz>
ex-bugsbunny: kas does layer management so maybe there's something to check there for you (or even replace your tool with it?)
<ex-bugsbunny>
qschulz: oh, never heard of that, I'll definitely have a look, thanks for that :-)
<ex-bugsbunny>
qschulz: but I fear that this is no quick solution, so is there any chance to get that running with bitbake-layers nevertheless?
<fabatera[m]>
Josef Holzmayr (TheYoctoJester): to run 2 distinct terminals as you said, do you run environment script for each terminal or there is a way to use the environment that was set first?
<JosefHolzmayrThe>
yup, source it two times?
otavio has quit [Read error: Connection reset by peer]
vd has joined #yocto
<ex-bugsbunny>
agherzan: I'm not familiar with layer index, but is dunfell the standard branch for the repo in gitlab? if not, it could be worth setting it accordingly and test again; if already the case I fear I cannot be of any help ;-/
<agherzan>
ex-bugsbunny: it is. The default and only branch
<ex-bugsbunny>
abelloni: ok, just thought to mention it, because I once created an empty repo in gitlab which got pushed an existing local one; that time the default branch was still master (gitlab default) but the pushed repo lacked such a branch - hopefully someone else has an answer ...
<agherzan>
ex-bugsbunny: you've mentioned the wrong person :) But yeah, sadly it's not that simple. Index doesn't seem to have a way to be told in regards to the branch name it should be looking for. Or at least I don't know how to do it.
pgowda has quit [Quit: Connection closed for inactivity]
kayterina has quit [Remote host closed the connection]
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
<ex-bugsbunny>
ups, sorry abelloni for accidentally addressing you ... >.<
<ex-bugsbunny>
agherzan: yeah, I should have guessed that you already checked that simple solutions ;-/
<agherzan>
It's fine - sometime they are not that obvious.
dev1990 has joined #yocto
oobitots has quit [Quit: Client closed]
oobitots has joined #yocto
marc1 has quit [Read error: Connection reset by peer]
marc1 has joined #yocto
oobitots has quit [Quit: Client closed]
<RP>
dwagenk: right, I was mis- remembering, sorry
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
alessioigor has quit [Remote host closed the connection]
alessioigor has joined #yocto
alessioigor has quit [Remote host closed the connection]
alessioigor has joined #yocto
otavio has joined #yocto
oobitots has joined #yocto
CarlesFernandez[ has quit [Quit: You have been kicked for being idle]
<vd>
Hi there -- I have trouble understanding when to use a site.conf. Let's say I want to tweak my distro and build for a specific customer, e.g. changing the splash screen image, or prefixing build artifact names. I was currently doing this in a multiconfig file to isolate a customer build. Should it be a site.conf scenario instead?
<vd>
RP might have explained that to me once, but I'm not quite sure
<RP>
vd: I personally use site.conf as a way to specify things specific to my local machine setup like SSTATE_DIR and DL_DIR
<vd>
RP: I see, like setting IMAGE_VERSION_SUFFIX to the CI/CD build number before building?
<RP>
vd: I'd normally use auto.conf for all the CI bits
<RP>
vd: it is really up to the user to decide how to use the files ultimately, there isn't a "wrong" answer
whuang0389 has quit [Quit: Client closed]
zpfvo has quit [Quit: Leaving.]
<vd>
site.conf resides only in build/conf, contrary to a multiconfig which can be part of the layer configuration, right?
<vd>
JPEW: does whisk put its generated configuration in local.conf or auto.conf?
<RP>
vd: in general yes but it could actually be in the layers
<RP>
JPEW: I added reformat_sysconfig.py to do_install and it breaks python3-dbus the same way as my change did
<vd>
RP: may I ask how would you personally split the "vanilla" configuration, from the customers customization? (different TMPDIR, tuned artifact names and other software branding tweaks)
<JPEW>
vd: auto.conf
<RP>
vd: customer is local.conf and site.conf, the other config should come from the layers, filename less important
<RP>
JPEW: It really shouldn't do this :/
<vd>
JPEW: another point for whisk. kas tweaks local.conf and I hate it ( rburton might hate it too ;-) )
<vd>
ho, interesting. bitbake "wrappers" shouldn't generate their abstracted configuration in auto.conf?
<JPEW>
RP: Oh is there a different one?
<JPEW>
RP, vd: Sorry I was wrong. It writes site.conf (not sure if that is any better :)
<JPEW>
vd: Ya, I purposely avoided local.conf
<vd>
RP: ha ha, that is a bit confusing for sure. Put differently, what is the best way to store and load customer-specific tweaks? I am currently using a multiconfig per customer, but that might be wrong. Maybe an `include somedir/${CUSTOMER}.conf` in somefile.conf would be preferred?
<RP>
vd: I was about to say you can also add your own config files
<vd>
that seems right, but what would be preferable for "somedir" and "somefile.conf"?
florian has quit [Quit: Ex-Chat]
<override>
finally figured out why recipetool was acting up for me
Tokamak has quit [Read error: Connection reset by peer]
<ex-bugsbunny>
talking about multiconfig and how to properly use, I am also a little puzzled in that respect: the intel bsp I talked about uses multiconfig for different configurations of one board (like different kernel versions or RT PREEMPT settings) but also for different boards (actually different processor generations); while the latter seems an adequate
<ex-bugsbunny>
use of multiconfig I would expect the latter rather to use different MACHINEs (unless the same game with various image/kernel/whatever configurations is played again)
<ex-bugsbunny>
so what is common sense/best practice here?
jmiehe has quit [Quit: jmiehe]
Tokamak has joined #yocto
<ex-bugsbunny>
(different configurations can also mean different images in that case)
mckoan is now known as mckoan|away
<vd>
ex-bugsbunny: even though a multiconfig is yet another config layer, I personally strongly bind it to TMPDIR. Because you can reference images from a different multiconfig (mcdepends), it is strongly advised to use a different TMPDIR for each multiconfig (since it is usually used to build potentially incompatible images like a different
<vd>
architecture or libc.
mranosta1 has joined #yocto
dlan has quit [Ping timeout: 268 seconds]
dmoseley_ has joined #yocto
alex88_ has joined #yocto
BCMM_ has joined #yocto
dlan has joined #yocto
davidinux1 has joined #yocto
Vonter_ has joined #yocto
qschulz_ has joined #yocto
BCMM has quit [*.net *.split]
Vonter has quit [*.net *.split]
mranostaj has quit [*.net *.split]
dmoseley has quit [*.net *.split]
davidinux has quit [*.net *.split]
mihai has quit [*.net *.split]
m4ho has quit [*.net *.split]
qschulz has quit [*.net *.split]
Starfoxxes has quit [*.net *.split]
alex88 has quit [*.net *.split]
angolini has quit [*.net *.split]
tgamblin has quit [*.net *.split]
wooosaiii has joined #yocto
user_ has joined #yocto
rfuentess_ has joined #yocto
jsandman7 has joined #yocto
jsandman has quit [Read error: Connection reset by peer]
user_123 has quit [Read error: Connection reset by peer]
wooosaii has quit [Read error: Connection reset by peer]
jsandman7 is now known as jsandman
alessioigor has quit [Remote host closed the connection]
mihai has joined #yocto
Starfoxxes has joined #yocto
angolini has joined #yocto
tgamblin has joined #yocto
mranosta1 is now known as mranostaj
rfuentess has quit [Ping timeout: 265 seconds]
alessioigor has joined #yocto
m4ho has joined #yocto
troth has quit [Ping timeout: 265 seconds]
bunk has quit [Quit: leaving]
bunk has joined #yocto
troth has joined #yocto
bunk has quit [Client Quit]
bunk has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
woky_ has joined #yocto
dlan_ has joined #yocto
Ch^W_ has joined #yocto
locutusofborg_ has joined #yocto
rfs613_alt has joined #yocto
alejandr1 has joined #yocto
dev1990_ has joined #yocto
linkliu62 has joined #yocto
FredO3 has quit [Read error: Connection reset by peer]
override_ has joined #yocto
iokill_ has joined #yocto
lexano_ has joined #yocto
zyga has joined #yocto
Lihis_ has joined #yocto
woky has quit [Ping timeout: 265 seconds]
dlan has quit [Ping timeout: 265 seconds]
zyga-mbp has quit [Ping timeout: 265 seconds]
linkliu61 has quit [Ping timeout: 265 seconds]
rfs613 has quit [Ping timeout: 265 seconds]
locutusofborg has quit [Ping timeout: 265 seconds]
grma has quit [Ping timeout: 265 seconds]
Ch^W has quit [Ping timeout: 265 seconds]
nerdboy has quit [Ping timeout: 265 seconds]
alejandrohs has quit [Ping timeout: 265 seconds]
raghavgururajan has quit [Ping timeout: 265 seconds]
rfuentess_ has quit [Remote host closed the connection]
jamestperk is now known as jamesp
oobitots has joined #yocto
frieder has quit [Remote host closed the connection]
jamesp is now known as jamestperk
gchamp has joined #yocto
yates has joined #yocto
<yates>
why does yocto test applications (not shared libraries) for .text relocations? I thought that since applications are not shared, there is no need to make them PIC
<yates>
WARNING: libcap-2.43-r0 do_package_qa: QA Issue: libcap-bin: ELF binary /usr/sbin/setcap has relocations in .text
<gchamp>
hi, getting error "pod2man command not found" at binutils-cross-x86_64:do_compile (poky hardknott b98a5771598), adding `inherit perlnative` to binutils.inc fixes it, but is the right fix?
florian has joined #yocto
<vd>
RP: is there such a thing as building a specific distro "version"?
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
alessioigor has quit [Remote host closed the connection]
alessioigor has joined #yocto
alessioigor has quit [Client Quit]
alessioigor has joined #yocto
ant__ has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
<yates>
tlwoerner: wasn't it you who informed me that the sdk can be built with "bitbake meta-toolchain" the other day?
<yates>
does the documentation need to be updated?
<tlwoerner>
well, if you logged the conversation, i did mention the "-c populate_sdk" way of doing it
<tlwoerner>
no, there are 2 ways of doing it
<tlwoerner>
however, there is a slight difference
<tlwoerner>
"bitbake meta-toolchain" will only create an eSDK, a basic cross-toolchain
<yates>
tlwoerner: what is basic about it? i.e., what is it missing?
<tlwoerner>
"-c populate_sdk" will build the eSDK but will also consider the contents of your image and populate the cross toolchain with any packages you've specific
<tlwoerner>
s/specific/specified
<tlwoerner>
lets say you want to use your sdk to cross-compile an application that depends on a library
<tlwoerner>
in order to build the application, the cross-compiled library would need to be available to your cross toolchain
<yates>
i see
<tlwoerner>
so if all you had was a basic sdk toolchain, you'd have to start by first cross-compiling the library, then installing it somewhere where your toolchain could find it
<tlwoerner>
then you could go ahead and cross-compile your application
<yates>
right
<yates>
i understand
<tlwoerner>
however, if you create an "image" that includes the library, then if you do "bitbake <image> -c populate_sdk" then bitbake will create the cross toolchain, and cross compile the library, and package them up into the sdk
<tlwoerner>
then all you'd have to do is use the sdk to cross-compile the application, and the sdk tools would "magically" find the headers and library when building the app
<tlwoerner>
in summary:
<tlwoerner>
"bitbake meta-toolchain" is just a plain, basic cross toolchain (sdk)
<yates>
but it still seems to me this distinction should be made in the sdk doc, don't you think? it seems the doc should inform the reader that the limited form of the sdk is available without building an entire image
<tlwoerner>
-c populate_sdk is the sdk plus any libraries/headers/etc prepopulated
<tlwoerner>
i don't disagree with that
<tlwoerner>
maybe submit some documentation patches to michaelo and see what he thinks? ;-)
<yates>
yes, good idea - i will. i'm already on the mailing list
<tlwoerner>
ah i see, earlier i said the docs didn't need to be updated. sorry i misunderstood i thought you meant the docs should be updated to remove the -c populate_sdk option
<tlwoerner>
yes (i'm flip-flopping :-)
<tlwoerner>
the docs could stand some updating in this area (if that's what they say, i'm not sure i've read that part of the docs)
oobitots has quit [Quit: Client closed]
<tlwoerner>
i use the reference manual a lot, but the other ones not so much :-(
<yates>
acknowledging that my situation is uncommon, it was a big deal for me since we are bringing up a brand new arch and our goal was to build a patched kernel, for which the "full" sdk is not required, and there were parts of the image build which were (and still are) not working.
<yates>
like u-boot.
<tlwoerner>
if u-boot isn't working yet, you can create an image that doesn't include it, then use the -c populate_sdk thingy
<yates>
hey, no problem in the flip-flopping - thanks for your excellent help!
<tlwoerner>
that way you get the sdk and any libraries/headers in your sdk
<yates>
how do you build an image without a bootloader?!?
<tlwoerner>
an "image" doesn't need a bootloader if you're not planning to boot it (yet) ;-)
<tlwoerner>
an "image" is just a collection of dependent things to build ;-)
<yates>
where is the list of those "things" specified?
<yates>
wait, i think i can find that.
<tlwoerner>
depends on what "image" is (e.g. core-image-minimal, core-image-base, etc)
<tlwoerner>
the machine file specifies which bootloader to use, or not
<vd>
tlwoerner: but an image cannot override the preferred provider or preferred version of a package, right?
<yates>
set "PREFERRED_PROVIDERS_u-boot ="?
<yates>
"PREFERRED_PROVIDER_u-boot ="?
<tlwoerner>
vd: offhand i don't know, it wouldn't be the best place to do it, not for the kernel or bootloader
<yates>
i can just jam my actual machine files - i've just created a rough version of them for our board
<tlwoerner>
yates: if you've already set the PREFERRED_PROVIDER_virtual/bootloader to "u-boot" then you can specify which u-boot with PREFERRED_PROVIDER_u-boot
<yates>
tlwoerner: right, so just set it to nothing? "PREFERRED_PROVIDER_u-boot=" ?
<vd>
but that cannot be done within an image recipe I believe.
<tlwoerner>
(sometimes a BSP layer defined multiple u-boot providers: one for upstream, on from the vendor)
<vd>
it has to be done from an higher configuration file
<tlwoerner>
yates: i thought i had blogged about this, but turns out i hadn't. i have a draft blog post i started in 2019 :-)
Emantor has quit [Ping timeout: 252 seconds]
perdmann has quit [Ping timeout: 246 seconds]
mario-goulart has quit [Ping timeout: 264 seconds]
mario-goulart has joined #yocto
Emantor has joined #yocto
vd has quit [Ping timeout: 256 seconds]
ex-bugsbunny has quit [Ping timeout: 256 seconds]
Guest9115 has quit [Ping timeout: 256 seconds]
prabhakarlad has quit [Ping timeout: 256 seconds]
vd has joined #yocto
perdmann has joined #yocto
<JPEW>
RP: Seems like the python parser errors out after 40,000 characters in a single line; we probably never noticed in the do_package version because the paths are shorter
<JPEW>
I'm re-writing the reformat script to account for this
<moto_timo[m]>
JPEW: that makes some sense
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
alessioigor has quit [Client Quit]
<vd>
I just got that in fact you could have local.conf in your main layer's conf directory and it'd be picked if build/conf/local.conf doesn't exist
<vd>
and same for auto.conf, site.conf, etc.
<vd>
and those are openembedded specific. Bitbake specific configuration files are only conf/bblayers.conf and conf/bitbake.conf. Am I correct?
<RP>
JPEW: oh, interesting. I hadn't managed to debug that :/
prabhakarlad has joined #yocto
<JPEW>
RP: Patch sent.... I have another idea if that one turns out to be non-reproducible (most likely due to pprint differences in host python)
goliath has quit [Quit: SIGSEGV]
Tokamak has quit [Read error: Connection reset by peer]
Tokamak has joined #yocto
<RP>
JPEW: awesome, thanks. I was struggling to see that one
dgriego has quit [Ping timeout: 252 seconds]
dgriego has joined #yocto
mtudan has joined #yocto
dgriego has quit [Read error: Connection reset by peer]
<mtudan>
hi all, it happens to me that particular file is only added to recipe-sysroot-native and not to recipe-sysroot... any idea how to debug this and add it to recipe-sysroot as well?
locutusofborg_ is now known as locutusofborg
locutusofborg has quit [Changing host]
locutusofborg has joined #yocto
dgriego has joined #yocto
<RP>
JPEW: that does looks like it will work, thanks
<JPEW>
RP: Great! Like I said, keep an eye on the repro build output just in case
argonautx has quit [Quit: Leaving]
florian has quit [Ping timeout: 252 seconds]
xmn has joined #yocto
<RP>
JPEW: will do, it was that it tested it with
mtudan has quit [Quit: Client closed]
goliath has joined #yocto
yates has quit [Remote host closed the connection]
florian has joined #yocto
jwillikers has quit [Remote host closed the connection]
leon-anavi has quit [Quit: Leaving]
florian has quit [Ping timeout: 250 seconds]
dev1990_ has quit [Quit: Konversation terminated!]