dl9pf changed the topic of #yocto to: Welcome to the Yocto Project | Learn more: http://www.yoctoproject.org | Join the community: http://www.yoctoproject.org/community | Channel logs available at https://www.yoctoproject.org/irc/ and https://libera.irclog.whitequark.org/yocto/ | Having difficulty on the list, or with someone on the list? Contact YP community mgr Nicolas Dechesne (ndec)
qschulz has quit [Read error: Connection reset by peer]
qschulz has joined #yocto
jwillikers has quit [Remote host closed the connection]
goliath has quit [Quit: SIGSEGV]
tgamblin has quit [Remote host closed the connection]
tgamblin has joined #yocto
zyga-mbp has quit [Ping timeout: 265 seconds]
zyga-mbp has joined #yocto
robbawebba has quit [Quit: WeeChat 3.2]
camus has joined #yocto
camus1 has joined #yocto
camus has quit [Read error: Connection reset by peer]
camus1 is now known as camus
sakoman has quit [Quit: Leaving.]
FredO has quit [Quit: Leaving]
FredO has joined #yocto
camus1 has joined #yocto
camus has quit [Ping timeout: 265 seconds]
camus1 is now known as camus
cocoJoe has joined #yocto
te_johan has quit [Remote host closed the connection]
paulg has quit [Ping timeout: 265 seconds]
xmn has quit [Ping timeout: 252 seconds]
r4ge has quit [Ping timeout: 260 seconds]
te_johan has joined #yocto
Vonter has quit [Ping timeout: 252 seconds]
Vonter has joined #yocto
roussinm has quit [Quit: WeeChat 3.3-dev]
Vonter has quit [Ping timeout: 252 seconds]
Vonter has joined #yocto
Guest61 has joined #yocto
frieder has joined #yocto
fbre has joined #yocto
zpfvo has joined #yocto
creich_ has quit [Quit: Leaving]
creich has joined #yocto
<wCPO> If I want a recipe executing only do_deploy, should I just add a noop do_install and "addtask deploy after do_install" or is there a smarter way?
<kanavin> the sad truth about warnings is that they never get fixed, and people just ignore them
<kanavin> the best course of action is to give everyone hard errors, even though this inevitably causes anger
rfuentess has joined #yocto
<kanavin> Linus discovers what (I think) RP had known for years ;)
<RP> kanavin: heh :)
<kanavin> RP: but perhaps overwhelming people could have been avoided - warnings to errors could be a gradual pre-planned and clearly scheduled transition rather than a flag day
<kanavin> (I mean in the kernel, not in yocto :)
<kanavin> and btw rngd swelling and causing oom is potentially serious, I'll try to look time permitting
<mihai> that's the first take after major gcc upgrade which changes warnings into errors, first commits disables errors :)
<wyre> is ${S} by default ${WORKDIR}=
<wyre> s/=/\?/
goliath has joined #yocto
<mihai> wCPO: you could disable them do_task[noexec] = "1"
<mihai> not sure if it's smarter
<mihai> the same is done for image recipes, afaik
<qschulz> wyre: no
<wyre> I'm trying to make a proper do_fetch task but my gitlab repo is private and I'm not sure if deploy tokens could help me
<qschulz> wyre: bitbake -e <anyrecipe> | less and go to the first line starting with S=, then look into the history of the variable, the first line is usually the default
<wyre> oh, I see
manuel1985 has joined #yocto
<qschulz> recommended to use ssh key access that is setup for the building machine
<qschulz> by far the easiest I assume
<qschulz> (that's all I have ever used)
<wyre> qschulz, do you have some doc as guide?
<wyre> qschulz, the problem is I'm using a docker container
<qschulz> wyre: nothing to be done on yocto side except specify protocol to be ssh
<qschulz> wyre: ssh-agent forwarding is the answer
<qschulz> Pyrex does it, CROPS might be doing it, I imagine kas is doing it too
<qschulz> -v $SSH_AUTH_SOCK:/tmp/ssh_auth_sock -e SSH_AUTH_SOCK=/tmp/ssh_auth_sock -e SSH_AGENT_PID is what I pass to custom containers (crops seems to require this from my shell history)
<qschulz> -v ~/.ssh/known_hosts:/home/pokyuser/.ssh/known_hosts:ro also
<qschulz> but really, you should just use whatever is already available instead of reinventing the wheel
<qschulz> if it does not fully match your use case, you can patch/fork/contribute to it and or extend it
<qschulz> RP: I like the argument being "the layer works with multiple poky releases without doing anything". Literally in the same sentence or the next one "I just needed to backport this class"... So are you saying it is in fact not compatible :D?
<wyre> qschulz, you mean when you do the docker run command?
tnovotny has joined #yocto
<qschulz> and yeah, I've circonvened that check at my previous company too.. And considering how many warnings there were when I arrived and how concerned the devs were about them, we sure don't want to turn it into a warning :D
<wyre> qschulz, also ... where should I specify ssh as protocol for yocto?
camus1 has joined #yocto
camus has quit [Ping timeout: 252 seconds]
camus1 is now known as camus
<qschulz> wyre: see the link to the git fetcher
<qschulz> wyre: yes, for CROPS i add those arguments to podman (should be more or less the same for Docker) when running the container
<qschulz> Pyrex should be doing it for you IIRC
<RP> kanavin: with the warnings/errors you need to get them under control over time
<RP> kanavin: I was wondering about rngd, whether it really was using all the memory and why
prabhakarlad has joined #yocto
<kanavin> RP: I am watching another lttng stress-test going on now. ps aux give:
<kanavin> root 328 7.2 48.4 1283444 985008 ? Ssl 07:52 1:12 /usr/sbin/rngd -r /dev/hwrng
<kanavin> this does not look healthy at all
<kanavin> I'll check if this is x86 specific
<wyre> cannot I set SRCREV as a branch name?
<kanavin> wyre, what's the use case?
kmaincent2 is now known as kmaincent
<kanavin> RP: much healthier on arm:
<kanavin> root 326 0.9 0.0 300628 1996 ? Ssl 05:20 1:40 /usr/sbin/rngd -r /dev/hwrng
<qschulz> wyre: see git fetcher link above, there's a branch parameter
<qschulz> and also https://docs.yoctoproject.org/ref-manual/variables.html#term-AUTOREV which I assume is what you're after (auto-pulling new commits of a branch?) Note that this is seen as a development feature only and shouldn't be used for any release build
<wyre> qschulz, I apparently have to set SRCREV
<RP> kanavin: that does seem rather worrying
<wyre> qschulz, ok, I've set SRCREV as ${AUTOREV} but bitbake is not able to fetch the repository, despite I'm able to clone it with git:// (ssh) from the inside of the container
<wyre> I can see a message saying "fatal: Unable to look up git@gitlab.com (port 9418) (Name or service not known)"
<qschulz> wyre: SRCREV should store the commit hash
te_johan has quit [Quit: Leaving...]
<qschulz> if not set to AUTOREV
<wyre> it's set to AUTOREV
<qschulz> the commit needs to be available in the branch passed in the "branch" parameter of the git fetcher. if it's not specified, it's master
<wyre> I've specified the branch, sure
<wyre> I mean, I've specified the branch with branch parameter and SRCREV is set as "${AUTOREV}"
<wyre> here is my recipe http://ix.io/3yge
<qschulz> wyre: can your container actually do a git clone of that specific git repo?
<wyre> qschulz, apparently it can
<wyre> I've tested it manually and it's able to fetch it
<qschulz> wyre: carefully read the git fetcher documentation
<qschulz> it's ; and not ,
<qschulz> you're missing the protocol argument I told you
<qschulz> and the URL is incorrect, use the clone button on gitlab for ssh connection, after gitlab.com you should have a : and not a /
<qschulz> and S should be set to ${WORKDIR}/git
<wyre> ok, done http://ix.io/3ygf and still the same https://bpa.st/XSKQ
<wyre> in fact I've replaced : with / to try if that was the problem
<qschulz> you're missing protocol=ssh in the git fetcher
<wyre> qschulz, well, I've set also protocol but still doesn't fetch https://bpa.st/WIMQ
<qschulz> and the recipe?
<qschulz> wyre: i told you about the protocol of the git fetcher
<qschulz> it's an argument
<qschulz> I didn't tell you to replace git with ssh
<wyre> sure
Guest4845 has joined #yocto
<Guest4845> Hello (cruel) World!
<wyre> qschulz, I mean, I didn't replace git with ssh ๐Ÿ˜ž I'm not sure why bitbake is printing urls with ssh://
<qschulz> then I guess try with / instead of : in the URL since it says it cannot resolve git@gitlab.com:whatever. After that, I'm clueless sorry
florian has joined #yocto
<wCPO> When would I use do_<stage>[depends] over just DEPENDS ?
<kanavin> RP: not too worrying for master branch. There's a botched upstream release of libjitterentropy in my branch, with that reverted rngd is back to normal.
<kanavin> RP: issue filed, update deferred https://github.com/smuellerDD/jitterentropy-library/issues/69
<RP> kanavin: good to at least know the cause, thanks!
Xagen has quit [Ping timeout: 252 seconds]
<kanavin> RP: this means we may have achieved issue-free ptests for lttng - I'll run the robustness tests a few more times. They've yet to fail on arm.
<kanavin> (I hope the x86 fail was in fact due to rngd)
<wyre> qschulz, now it works, thank you ๐Ÿ˜€, the problem now is that python3 cannot find setup.py but I guess I can deal with it
<qschulz> wyre: :+1:
Xagen has joined #yocto
leon-anavi has joined #yocto
<fbre> Hi, if the .c file is located in .../build/tmp/work-shared/mymachine/kernel-source/drivers/net/ethernet/freescale, in which folder does bitbake put the .o file?
<fbre> ...on building the kernel
<RP> kanavin: I think that lttng-relayd segfault is still out there but yes, it is good progress
<kanavin> RP: I haven't seen that yet with 2.13.0 versions
<qschulz> fbre: in the tmp/work/mymachine/<linux-kernel-recipe>/<linux-kernel-version>/<git probably>
<wyre> qschulz, should S be set as the same folder where setup.py is?
<wyre> I don't get why it says pwm/pwm.sh doesn't exist but it's there ๐Ÿค” https://bpa.st/F32Q
<qschulz> wyre: likely yes, or set DISTUTILS_SETUP_PATH correctly
<RP> kanavin: it is relatively rare and I think load related, you're on relatively quiet autobuilders
<qschulz> wyre: you probably need to add ${S} or ${WORKDIR} in front of your pwm/pwm.sh path
<RP> kanavin: are we looking better on the multiconfig change?
<kanavin> RP: yes, I think I wrote a comment in the bug about it
<wyre> qschulz, I'd say before I had not to add ${S} but now apparently I need it, you are right :think
<wyre> ๐Ÿค”
<qschulz> wyre: do_install runs in ${B} IIRC
<qschulz> it's set to S by default IIRC but there is probably something changing it then
zyga-mbp has quit [Quit: Textual IRC Client: www.textualapp.com]
<fbre> qschulz, yeah right (y) thanx
<RP> kanavin: ah, thanks. Somehow refreshing wasn't working
<fbre> and build/drivers/net/ethernet/freescale there
<wyre> qschulz, so I guess I should also set B as ${S}, right?
<qschulz> wyre: no, you usuallyt want the outcome of a build to be separate from the sources
<qschulz> some software can only be built within the source directory but that's deemed to be a bug
<wyre> so then is better to use ${S} in the install commands inside do_install?
BCMM has joined #yocto
<fbre> hmm... I deleted the .o files in that work subdir but they are not build again with bitbake, even with a cleansstate
florian_kc has joined #yocto
<fbre> ...ok, now I've found a way to rebuild them...
Belsirk has joined #yocto
rfuentess has quit [Read error: Connection reset by peer]
tnovotny has quit [Read error: Connection reset by peer]
tnovotny has joined #yocto
zyga-mbp has joined #yocto
tnovotny_ has joined #yocto
tnovotny has quit [Ping timeout: 265 seconds]
<rburton> fbre: bitbake [recipe] -C unpack will force a rebuild
goliath has quit [Quit: SIGSEGV]
xmn has joined #yocto
<fbre> Does anybody know if the imx-freescale stuff will switch the kernel version from 5.4 to 4.10 in the near future?
<fbre> รคh 5.10
<rburton> you'll need to ask them directly i expect
<fbre> thought some freescale guys are around here, but you're right, likely the plans are top-secret
<qschulz> fbre: meta-imx seems to have a hardknott branch with 5.10?
xmn has quit [Ping timeout: 265 seconds]
<qschulz> fbre: I did say meta-imx which is the vendor tree
<qschulz> meta-freescale is community maintained IIRC
<qschulz> so feel free to send a patch to migrate to 5.10 :)
<fbre> I use poky+meta-openembedded+meta-mingw+meta-freescale+meta-mystuff
<fbre> This is for the imx8
<fbre> Not sure what you mean with meta-imx
<qschulz> NXP works on meta-imx only
<fbre> A while back I switched to the free version because people here recommended that to me
<fbre> I'm not sure, but am I right meta-freescale is the alternative community version and meta-imx is the vendor version?
<fbre> sorry for asking odd questions, I'm just trying to recall
<fbre> ...what I have forgotten
<qschulz> that's what I said a few lines above :)
<fbre> ok, thanx
<qschulz> since meta-frescale is community maintained, patches are welcome, if you want 5.10 ASAP, you can add support for it and then contribute back to the layer :)
<fbre> no, I don't want it, I just check what is available. Because I check the newer sources of all those available branches. And I compare them against my "old" dunfell version. I want to know whether a ethernet driver bug is fixed or not.
zyga-mbp has quit [Read error: Connection reset by peer]
zyga-mbp has joined #yocto
<fbre> I already check the branch "hardknott" of meta-freescale. But that ugly ethernet driver bug still happens after I merged those newer sources back to my old dunfell sources
<fbre> *checked
<qschulz> https://git.yoctoproject.org/cgit/cgit.cgi/meta-freescale/tree/recipes-kernel/linux ..... there seems to be a 5.10 kernel already available?
<fbre> qschulz, the imx8 uses linux-fslc-imx_5.4.bb
zyga-mbp has quit [Read error: Connection reset by peer]
<fbre> ah OK, thanx, I'll check that. Until now I thought I can only use linux-fslc-imx but not linux-imx
zyga-mbp has joined #yocto
<wyre> I've included i2c-tools in my image recipe but I haven't i2cdetect
<wyre> just i2ctransfer
<qschulz> wyre: oe-pkgdata-util find-path '*i2cdetect*' and add the package to your image
<wyre> qschulz, unable to find any package producing path i2cdetect
<wyre> but I'm not sure why I have not that binary in my image
<wyre> however I have i2ctransfer ๐Ÿ˜ฅ
<qschulz> and the oe-pkgdata-uitil returns something for i2ctransfer?
<wyre> qschulz, sure, busybox-ptest
<wyre> but I've i2c-tools in my image recipe!
<wyre> oh, just in PKG_DEBUG ๐Ÿ˜ฅ
goliath has joined #yocto
<RP> kanavin: that zstd compression thing looks like the number of threads is getting encoded into the rpms somehow which is bad :/
<RP> kanavin: are the rpms the same with varying numbers of compression threads?
<kanavin> RP: I had already fixed it, I just would like to know how poisoned items made it into reproducible builds (which are not supposed to utilize sstate)
<kanavin> RP: they are
<kanavin> the reason it's not seen with xz is because AB hardcodes the number of threads
<RP> kanavin: reproducible builds use sstate for half the build
<kanavin> RP: but the other half is also saying 'zstd'
<kanavin> from the abelloni's likn
<RP> kanavin: both sides of the build looked to encode it in that build, yes
<RP> kanavin: I think abelloni used the series from the mailing list
<kanavin> RP: right, those were before I added the fix
<RP> kanavin: that would explain things
<kanavin> and it was marked as RFC, meaning, do not queue into builds ;)
<RP> kanavin: abelloni and I are trying to work out how to queue the non-master patches that are still flowing in. Leaving them just ends up as a different kind of nightmare (hence the kirkstone-next brancht that appeared)
<JPEW> Ugh, is that zstd thing specific to rpms? I didn't see that when I used the standalone utilities
<kanavin> RP: right, but that particular RFC set shouldn't be queued - it was strictly for comments, and will be resent later when things reopen for merging
<kanavin> JPEW, nothing is broken, there was just a mixup with not fully tested patchset
<JPEW> Ah got it
* JPEW needs more coffee
paulg has joined #yocto
Belsirk is now known as rfuentess
<RP> kanavin: if the right set is ready now I'm wondering if we should queue that just so people know what is done and what isn't?
jwillikers has joined #yocto
<yates_work> in meta/recipes-devtools/gcc, there are several recipes related to gcc, e.g., gcc_{pv}.bb, gcc-cross_{pv}.bb, gcc-cross-canadian_{pv}.bb, gcc-source_{pv}.bb, etc. is there a document describing what each of these is for?
<yates_work> i need to modify the way crti.S is assembled for our cross-gcc, and there are multiple crti.S files and multiple recipes involved. i am confused.
<yates_work> we are using glibc
<kanavin> RP: I'm running a-full on it right now, once that completes, I can send the whole thing to oe-core http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=akanavin/package-version-updates
<yates_work> there is also the libgcc stuff there, which is one of the packages which contain a version of crti.S, such as libgcc_{pv}.bb and libgcc-initial_{pv}.bb. i'd really like to know what the difference of those is for.
otavio has quit [Quit: leaving]
otavio has joined #yocto
Guest4845 has quit [Ping timeout: 256 seconds]
troth has joined #yocto
tlwoerner has joined #yocto
zpfvo has quit [Ping timeout: 245 seconds]
zpfvo has joined #yocto
raido has joined #yocto
<raido> Hi Yocto community! I am wondering, is it possible to run any task from `devshell`, like do_configure? When trying to just run the script from /temp/ folder from devshell, it will not work.
<raido> This will give an error: ./run.do_fetch.4700: line 2: syntax error near unexpected token `(' ./run.do_fetch.4700: line 2: `def do_fetch(d):'
<qschulz> raido: I assume you need to prefix this with `python` since it's probably a python taks
<raido> it is a python task. Sorry, did not mention that yes, running as ```python run.do_fetch.4700``` will give similar error:
<raido> Traceback (most recent call last):
<raido> File "run.do_fetch.4700", line 6, in <module>
<raido> do_fetch(d)
<raido> NameError: name 'd' is not defined
<qschulz> mmmm I think there's devpyshell too? don't know what it's for though
<raido> May be my yocto version is too old, it doesn't have devpshell :(
<raido> and.. I have not heard it about anyway
<raido> sorrry...
Guest61 has quit [Ping timeout: 256 seconds]
tnovotny_ has quit [Read error: Connection reset by peer]
tnovotny_ has joined #yocto
tnovotny has joined #yocto
zyga-mbp has quit [Quit: Textual IRC Client: www.textualapp.com]
tnovotny_ has quit [Ping timeout: 252 seconds]
<raido> But would be great to have it. And anyway - there is little information about this in documentation pages.
Guest45 has joined #yocto
<Guest45> is it possible to set partitions permissions using a wic kickstart file? "part /data --ondisk mmcblk0 --fstype=ext4 --label data --align 4096 --size=5000"
andy99 has joined #yocto
<andy99> Hello everyone, I have some other question based on previous discussion about the initramfs+fitimage. This commit prevent installing the kernel https://github.com/openembedded/openembedded-core/commit/1b67fd9ac74935fa41e960478c54e45422339138 . So how it's being installed into rootfs from deploy folder?
sakoman has joined #yocto
mattsm has quit [Quit: The Lounge - https://thelounge.chat]
OutBackDingo has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
OutBackDingo has joined #yocto
Guest87 has joined #yocto
<Guest87> How can I track down dependencies in an image? E.g. have an image containing libxml2 and want to find what package is pulling that in.
angolini has joined #yocto
raido has quit [Ping timeout: 265 seconds]
<andy99> Guest87: Do you have the opkg or buildhistory?
<paulg> I'm sure there are more elegant ways, but brute force always works. You can blacklist libxml2 and then see who complains.
<Guest87> buildhistory I have. I can add opkg package manager if that helps.
<rburton> the ghetto way of blacklisting libxml2 and seeing what fails does work :)
<rburton> or bitbake [imagename] -g -u taskexp
* paulg wallows in duct tape and bailing wire and cable ties.
fbre has quit [Quit: fbre]
<paulg> ...stored in an old non-functional refridgerator on the porch ; near the car up on blocks.
ecdhe has quit [Ping timeout: 252 seconds]
mattsm has joined #yocto
ecdhe has joined #yocto
<Guest87> blacklisting is done via PACKAGE_EXCLUDE in image?
<qschulz> yeah or local.conf
cocoJoe has quit [Quit: Client closed]
andy99 has quit [Quit: Leaving]
cocoJoe has joined #yocto
<Guest87> looks like libarchive pulls in libxml2. not sure why, because PACKAGECONFIG does not have libxml
<qschulz> Guest87: bitbake -e libarchive and then grep for libxml2
<Guest87> yes I see it in PACKAGECONFIG then
<qschulz> read the history of the PACKAGECONFIG variable just above the line starting with PACKAGECONFIG= and you'll see where it comes from
<rburton> yes
<rburton> that says on target builds, turn on libxml
<Guest87> but DISTRO_FEATURES does not have acl and xattr.
<rburton> ignore line 14
<rburton> line 13 is the cause
goliath has quit [Quit: SIGSEGV]
<rburton> just do a PACKAGECONFIG_remove to force it off
<Guest87> but in my bbappend i have set it hard. isn't that sufficient?
<rburton> no, because the append will append
<rburton> well, you could do PACKAGECONFIG_forcevariable = "these and exactly these option"
<rburton> appends won't happen then
roussinm has joined #yocto
<sgw> what am I getting blamed for now? Everyone knows I am a trouble makers!
<RP> sgw: from 2013!
<sgw> Just took a while for everyone to catch up to what we were doing!
vd has quit [Quit: Client closed]
fray has quit [Ping timeout: 256 seconds]
<Guest87> ok I will use the PACKAGECONFIG_remove to get rid of libxml2 in libarchive. that works for me for now.
tnovotny has quit [Quit: Leaving]
<wyre> I've included lmsensors in my image recipe, and I'm having a message saying "nothing provides lmsensors-isatools needed by lmsensors-3.6.0-r0.cortex7t2hf_neon"
<wyre> why is that? should I add some extra layer? ๐Ÿค”
<wyre> rburton, and how can I get it the backported version?
<rburton> you apply that change to your branch
<rburton> or submit the patch as a backport and wait for it to be applied
<wyre> my branch?
<wyre> you mean in the meta-oe layer?
<qschulz> or override the whole RDEPENDS_${PN} in a bbappend so that it does not have isatools in there
<rburton> just a remove in a bbappend would be sufficient
<rburton> with a comment pointing to the real fix so you know to remove it in the future
<wyre> rburton, could you give me some example?
<rburton> RDEPENDS_${PN}_remove = "lm-sensors-isatools"
vd has joined #yocto
<wyre> rburton, and how should I call the bbappend file?
<wyre> lmsensors_3.6.0.bbappend, i guess, right?
<qschulz> yes
<qschulz> rburton: except if they plan to support an x86 machine with their yocto builds but yeah :)
<wyre> it's still trying to fetch the dependency ๐Ÿ˜ฅ
<qschulz> check that your bbappend is applied by running bitbake-layers show-appends lmsensors
<qschulz> if yes, then check the output of bitbake -e lmsensors to see where the mistake is
<wyre> apparently it's being applied
<rburton> oh the recipe uses ${PN}-isatools, so i guess you need to put that
jmiehe has joined #yocto
<wyre> you mean RDEPENDS_${PN}-isatools_remove ?
goliath has joined #yocto
<rburton> no, the value you're removing
<qschulz> rburton: I think the issue is that you wrote lm-sensors-isatools and it should be lmsensors-isatools
<rburton> yeah that would also be a problem
<qschulz> damn distro which cannot agree on the same naming for lmsensors
<rburton> mine was very much an example ;)
<qschulz> lmsensors, lm_sensors, shellcheck, ShellCheck, ugh
cocoJoe has quit [Quit: Client closed]
rfuentess has quit [Remote host closed the connection]
Guest45 has quit [Quit: Client closed]
vd has quit [Quit: Client closed]
Guest45 has joined #yocto
arunss has joined #yocto
zpfvo has quit [Remote host closed the connection]
<Guest45> does wic have a way of setting permissions on a partition?
<rburton> partitions don't have permissions
<rburton> the file system has permissions
<rburton> the permissions are set by those at rootfs generation time, and will be the same as what is in the packages
<Guest45> with wic, i am generating an ext4 filesystem like this "part /data --ondisk mmcblk0 --fstype=ext4 --label data --align 4096 --size=5000"
_whitelogger has joined #yocto
florian has quit [Quit: Ex-Chat]
arunss has quit [Remote host closed the connection]
arunss has joined #yocto
florian_kc has quit [Ping timeout: 260 seconds]
cocoJoe has joined #yocto
manuel1985 has quit [Quit: Leaving]
arunss has quit [Remote host closed the connection]
arunss has joined #yocto
Guest45 has quit [Quit: Client closed]
<arunss> I have a custom machine with 64-bit kernel and 32-bit userspace, using multilib. Target builds fine, however SDK seems to compile userspace packages for both 32 and 64-bit arch. Is there anyway I can specify SDK to build only for 32-bit?
florian_kc has joined #yocto
vd has joined #yocto
Glenn has joined #yocto
TMoore has joined #yocto
TMoore has quit [Client Quit]
Glenn has quit [Client Quit]
mfe has quit [Quit: WeeChat 3.2]
BCMM has quit [Ping timeout: 252 seconds]
TMoore has joined #yocto
elfenix|cloud has joined #yocto
<TMoore> I am trying to dynamically modify the LIC_FILES_CHKSUM in a custom task that executes prior to the do_populate_lic task. I am able to append to the LIC_FILES_CHKSUM using `appendVar` however when the do_populate_lic (or any following task) executes it does not contain any of my appended license files. I see that if I modify LIC_FILES_CHKSUM in an
<TMoore> anonymous python function the modification is seen in do_populate_lic. I would like to avoid an anonymous function since it is executed several times. Why are changes to the LIC_FILES_CHKSUM removed when the custom task completes? Is there any way to make these updates persist for processing in a different task (e.g. do_populate_lic)?
marc1 has joined #yocto
florian_kc is now known as florian
sakoman has quit [Quit: Leaving.]
yates_work has quit [Remote host closed the connection]
sakoman has joined #yocto
<vd> openembedded-core has no honister branch?
<smurray> tmoore: AIUI tasks get their own task-specific copies of the datastore, but RP would be the person who could answer definitively if he's around
<vd> how do you guys deal with version bump? especially with this override syntax change
<vd> I cannot bump some layers because they now use the new syntax, but there's no honister branch nowhere so I don't quite understand the expected update process here
cocoJoe has quit [Quit: Client closed]
vd has quit [Quit: Client closed]
Guest87 has quit [Quit: Client closed]
prabhakarlad has quit [Quit: Client closed]
prabhakarlad has joined #yocto
vd has joined #yocto
* vd is back
frieder has quit [Remote host closed the connection]
goliath has quit [Quit: SIGSEGV]
<rburton> vd: honister isn't out yet, use master branch
yannd has quit [Remote host closed the connection]
TMoore has quit [Quit: Client closed]
<vd> rburton ho ok, makes sense
<vd> I'll wait
otavio has quit [Remote host closed the connection]
<RP> smurray: I may be back, tmoore is gone though. Your right FWIW
goliath has joined #yocto
<RP> You're...
lexano has quit [Ping timeout: 252 seconds]
lexano has joined #yocto
lexano has quit [Ping timeout: 265 seconds]
wooosaiiii has quit [Ping timeout: 256 seconds]
wooosaiiii has joined #yocto
xmn has joined #yocto
lexano has joined #yocto
wooosaiiii has quit [Ping timeout: 265 seconds]
wooosaiiii has joined #yocto
sakoman has quit [Quit: Leaving.]
leon-anavi has quit [Quit: Leaving]
sakoman has joined #yocto
camus1 has joined #yocto
camus has quit [Ping timeout: 265 seconds]
camus1 is now known as camus
gsalazar has quit [Ping timeout: 245 seconds]
wooosaiiii has quit [Ping timeout: 252 seconds]
wooosaiiii has joined #yocto
prabhakarlad has quit [Quit: Client closed]
bq has joined #yocto
<bq> Hi all. Aside from implementing my own bbclass, is there a built-in way of banning/disallowing nobranch=1 in SRC_URI?
<bq> I'm mostly interested in checking that nobody has specified nobranch=1 when committing code to master, since it's a common pitfall our devs fall into for introducing silly/subtle bugs
dev1990 has quit [Quit: Konversation terminated!]