ndec changed the topic of #yocto to: "Welcome to the Yocto Project | Learn more: https://www.yoctoproject.org | Join us or Speak at Yocto Project Summit (2022.05) May 17 - 19, more: https://yoctoproject.org/summit | Join the community: https://www.yoctoproject.org/community | IRC logs available at https://www.yoctoproject.org/irc/ | Having difficulty on the list or with someone on the list, contact YP community mgr ndec"
npcomp has joined #yocto
GLumen_ has quit [Ping timeout: 248 seconds]
qschulz has quit [Remote host closed the connection]
qschulz has joined #yocto
turkeykittin has quit [Quit: Connection closed]
RobertBerger has joined #yocto
rber|res has quit [Ping timeout: 260 seconds]
sakoman has quit [Quit: Leaving.]
astlep has joined #yocto
nemik has quit [Ping timeout: 250 seconds]
nemik has joined #yocto
thomasd13 has joined #yocto
nemik has quit [Ping timeout: 246 seconds]
nemik has joined #yocto
alessioigor has joined #yocto
alessioigor has quit [Client Quit]
kranzo has joined #yocto
alejandrohs has quit [Remote host closed the connection]
kranzo has quit [Ping timeout: 252 seconds]
alejandrohs has joined #yocto
frieder has joined #yocto
tomzy_0 has joined #yocto
kroon has joined #yocto
starblue has joined #yocto
frieder has quit [Quit: Leaving]
frieder has joined #yocto
mvlad has joined #yocto
rob_w has joined #yocto
goliath has joined #yocto
thomas_ has joined #yocto
thomasd13 has quit [Ping timeout: 256 seconds]
leon-anavi has quit [Quit: Leaving]
kranzo has joined #yocto
tomzy_0 has quit [Quit: Client closed]
hcg has joined #yocto
Thomas_Roos has joined #yocto
Thomas_Roos is now known as thomas-roos
thomas-roos is now known as ThomasRoos
astlep has quit [Ping timeout: 256 seconds]
Lihis has quit [Remote host closed the connection]
Lihis has joined #yocto
ThomasRoos has quit [Quit: Client closed]
GNUmoon has quit [Ping timeout: 240 seconds]
kanavin has quit [Remote host closed the connection]
Guest82 has joined #yocto
kanavin has joined #yocto
danielt has quit [Quit: Bridge terminating on SIGTERM]
dwagenk has quit [Quit: Bridge terminating on SIGTERM]
Tartarus has quit [Quit: Bridge terminating on SIGTERM]
guysoft[m] has quit [Quit: Bridge terminating on SIGTERM]
cb5r has quit [Quit: Bridge terminating on SIGTERM]
PortiaOld[m] has quit [Quit: Bridge terminating on SIGTERM]
zyga[m] has quit [Quit: Bridge terminating on SIGTERM]
ericson2314 has quit [Quit: Bridge terminating on SIGTERM]
kayterina[m] has quit [Quit: Bridge terminating on SIGTERM]
mait[m] has quit [Quit: Bridge terminating on SIGTERM]
BignauxRonan[m] has quit [Quit: Bridge terminating on SIGTERM]
Alban[m] has quit [Quit: Bridge terminating on SIGTERM]
Lcvette[m] has quit [Quit: Bridge terminating on SIGTERM]
janvermaete[m] has quit [Quit: Bridge terminating on SIGTERM]
nk058[m] has quit [Quit: Bridge terminating on SIGTERM]
lrusak[m] has quit [Quit: Bridge terminating on SIGTERM]
jquaresma[m] has quit [Quit: Bridge terminating on SIGTERM]
UmaKadam[m] has quit [Quit: Bridge terminating on SIGTERM]
yudjinn[m] has quit [Quit: Bridge terminating on SIGTERM]
thierryE[m] has quit [Quit: Bridge terminating on SIGTERM]
ejoerns[m] has quit [Quit: Bridge terminating on SIGTERM]
hpsy[m] has quit [Quit: Bridge terminating on SIGTERM]
nagua[m] has quit [Quit: Bridge terminating on SIGTERM]
falk0n[m] has quit [Quit: Bridge terminating on SIGTERM]
tokamak[m] has quit [Quit: Bridge terminating on SIGTERM]
hmw[m] has quit [Quit: Bridge terminating on SIGTERM]
shoragan[m] has quit [Quit: Bridge terminating on SIGTERM]
kleist[m] has quit [Quit: Bridge terminating on SIGTERM]
coref[m] has quit [Quit: Bridge terminating on SIGTERM]
agherzan has quit [Quit: Bridge terminating on SIGTERM]
scosu[m] has quit [Quit: Bridge terminating on SIGTERM]
Amarjargal[m] has quit [Quit: Bridge terminating on SIGTERM]
T_UNIX[m] has quit [Quit: Bridge terminating on SIGTERM]
sahitya[m] has quit [Quit: Bridge terminating on SIGTERM]
VigneshSekar[m] has quit [Quit: Bridge terminating on SIGTERM]
khem has quit [Quit: Bridge terminating on SIGTERM]
deee101[m] has quit [Quit: Bridge terminating on SIGTERM]
Saur[m] has quit [Quit: Bridge terminating on SIGTERM]
jclsn[m] has quit [Quit: Bridge terminating on SIGTERM]
elfenix[m] has quit [Quit: Bridge terminating on SIGTERM]
barath has quit [Quit: Bridge terminating on SIGTERM]
sielicki has quit [Quit: Bridge terminating on SIGTERM]
fabatera[m] has quit [Quit: Bridge terminating on SIGTERM]
glembo[m] has quit [Quit: Bridge terminating on SIGTERM]
qrsBRWNanyall[m] has quit [Quit: Bridge terminating on SIGTERM]
kp7299[m] has quit [Quit: Bridge terminating on SIGTERM]
amahnui[m] has quit [Quit: Bridge terminating on SIGTERM]
lexano[m] has quit [Quit: Bridge terminating on SIGTERM]
rfuentess has joined #yocto
khem has joined #yocto
mckoan|away is now known as mckoan
<mckoan> good morning
shoragan[m] has joined #yocto
ejoerns[m] has joined #yocto
dwagenk has joined #yocto
lexano[m] has joined #yocto
falk0n[m] has joined #yocto
elfenix[m] has joined #yocto
zyga[m] has joined #yocto
barath has joined #yocto
sahitya[m] has joined #yocto
PortiaOld[m] has joined #yocto
hmw[m] has joined #yocto
kayterina[m] has joined #yocto
cb5r has joined #yocto
danielt has joined #yocto
Amarjargal[m] has joined #yocto
jquaresma[m] has joined #yocto
ericson2314 has joined #yocto
BignauxRonan[m] has joined #yocto
guysoft[m] has joined #yocto
Tartarus has joined #yocto
lrusak[m] has joined #yocto
tokamak[m] has joined #yocto
UmaKadam[m] has joined #yocto
amahnui[m] has joined #yocto
deee101[m] has joined #yocto
kleist[m] has joined #yocto
fabatera[m] has joined #yocto
yudjinn[m] has joined #yocto
agherzan has joined #yocto
Saur[m] has joined #yocto
Lcvette[m] has joined #yocto
janvermaete[m] has joined #yocto
GillesM has joined #yocto
GillesM is now known as Imaginatif
nk058[m] has joined #yocto
sielicki has joined #yocto
hpsy[m] has joined #yocto
coref[m] has joined #yocto
Imaginatif is now known as imaginatif
glembo[m] has joined #yocto
qrsBRWNanyall[m] has joined #yocto
imaginatif has quit [Client Quit]
T_UNIX[m] has joined #yocto
Alban[m] has joined #yocto
mait[m] has joined #yocto
thierryE[m] has joined #yocto
kp7299[m] has joined #yocto
VigneshSekar[m] has joined #yocto
<Guest82> Good morning all, I have a question regarding CVE-2022-24765. I'm trying to build an image on Ubuntu 20.04.4 LTS with Git 2.36.0 installed via ppa. My poky branch is on master, and in bitbake.conf (line 789) I see that there should be a workaround for this issue by marking all directories safe. Despite this I still get the fatal "unsafe repository"
<Guest82> error during build on one of the repositories. Marking the specific directory as safe in my .gitconfig doesn't help. Have any of you encountered a similar issue?
nagua[m] has joined #yocto
jclsn[m] has joined #yocto
scosu[m] has joined #yocto
amahnui1 has joined #yocto
<LetoThe2nd> yo dudX
ThomasRoos has joined #yocto
<thomas_> Guest82, similar symptoms. I just ended up to downgrade git to 2.30.0
tnovotny has joined #yocto
prabhakarlad has joined #yocto
<Guest82> Hi thomas_, thanks for your quick reply and confirmation. Both patches are indeed in place in my source dir. I will try to downgrade too and report back if that works for now.
nemik has quit [Ping timeout: 260 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 260 seconds]
nemik has joined #yocto
tre has joined #yocto
GNUmoon has joined #yocto
ThomasRoos has quit [Ping timeout: 252 seconds]
grma has joined #yocto
<Guest82> Hi thomas_, you've made my day! Downgrading worked so thanks a lot for your suggestion :)
<thomas_> Guest82, no problem. Have a nice day!
huseyinkozan has joined #yocto
rob_w has quit [Remote host closed the connection]
ThomasRoos has joined #yocto
alessioigor has joined #yocto
<agherzan> Do we have any ways of improving the error:
<agherzan> ERROR: Variable BB_ENV_EXTRAWHITE has been renamed to BB_ENV_PASSTHROUGH_ADDITIONS
<LetoThe2nd> agherzan you mean improving the error message?
<agherzan> I get a considerable amount of reports where users are confused on what this actually means. And the first assumption is that there is a lingering variable in the metadata (as opposed to the shell env).
<agherzan> As opposed to a env variable from an old env initialisation.
<LetoThe2nd> agherzan: the error message might be expanded to give the background of the renaming.
<agherzan> LetoThe2nd: how do you mean?
landgraf has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
<LetoThe2nd> agherzan: the rename didn't happen out of thin air, it was part of a major change concerning inclusive language. so my impression is that the error could point to some document/resource that explains the rationale, and describes the fact that this refers to both environment and metadata.
<RP> LetoThe2nd: I think the issue is that people don't realise it is the shell environment
<LetoThe2nd> RP: thats what i mean - it can be both.
alessioigor has quit [Client Quit]
<landgraf> RP: yup. We don't :) I mean it took me a while to realize what's going on when I sources kirkstone from the same shell session I used to build dunfell
<agherzan> LetoThe2nd: that makes sense. I'm fine with any additional information we could provide. I'm not sure if we can clearly state at that point the provenance of the variable. I guess it would be ideal to have the error clearly stating that the offending variable is in the env not in metadata
<RP> LetoThe2nd: it can. I thought we'd done some early check on the environment though :/
<RP> agherzan: https://git.yoctoproject.org/poky/commit/?id=478cb0ce2c71273799695240845a687aaac0cb0c - the intent was you'd see "Variable %s from the shell environment has been renamed to %s"
huseyinkozan has quit [Quit: Konversation terminated!]
<agherzan> Right. So that doesn't work as expected
<agherzan> landgraf: ^
<kanavin> RP: I'm preparing a gigantic version update patchset, then we could talk about esdk perhaps
nemik has quit [Ping timeout: 256 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 248 seconds]
kroon has quit [Quit: Leaving]
nemik has joined #yocto
<RP> kanavin: sounds good, thanks
PortiaOld[m] has quit [Quit: You have been kicked for being idle]
* RP thinks we need to rewrite a few of the contributing docs and readmes
<LetoThe2nd> reminder here too, that we have an awesome schedule lined up for the yocto project summit! https://pretalx.com/yocto-project-summit-2022-05/schedule/#
<RP> LetoThe2nd: shouldn;t there be a link to register somewhere on there?
<LetoThe2nd> RP: hmm seems like the platform doesn't put one on the schedule page :-(
xmn has quit [Ping timeout: 240 seconds]
<RP> LetoThe2nd: Thanks, I worked it out but just thought it odd even the logo at the top didn't link there
<LetoThe2nd> RP: yeah i realized only once you mentioned it too.
<LetoThe2nd> ndec: thoughts?
tomzy_0 has joined #yocto
<ndec> RP: LetoThe2nd , that's an interesting feedback.. let me check..
<ndec> well you're right, we can't change it. it's probably worth reporting it to pretalx. that seems like a simple feature, and a good addition.
<ndec> i will report it. thx
<RP> ndec: thanks, I think it would help
nemik has quit [Ping timeout: 256 seconds]
bps has joined #yocto
bps has quit [Changing host]
bps has joined #yocto
nemik has joined #yocto
<thomas_> I have a question about generating the SDK for a specific image with yocto: The SDK consists of two parts right? First, the toolchain to build against the target, and second the complete target filesystem.
<thomas_> Is that correct?
<LetoThe2nd> thomas_: not exactly target filesystem, rather sysroot. but for the sake of explanation, its close enough.
<thomas_> Okay lets say I installed a package (libA) on my image. Now I would like to have it also on the sysroot which was generated by SDK. Because I need to develop my linux-userspace app.
<LetoThe2nd> thomas_: it should be there automatically.
<thomas_> Would this libA be also picked up by the SDK-job of yocto, to be deployed on the SDK sysroot?
<thomas_> okay
Guest49 has joined #yocto
<thomas_> Are there any differences, between the "normal" targetfs and the rootfs of the SDK? I ask this strange questions, because I've stuck with the TI (arago) way of populate an SDK
<Guest49> Hi, is the linux kernel a separate yocto layer? I have dunfell and want to update the kernel to a newer version but not the distro.
<thomas_> For example, the rootfs of arago SDK does NOT include libA. But my normal image does. So I'm wondering if I could replace the rootfs of arago SDK just with my normal targetfs
<qschulz> Guest49: no, but they usually are in BSP layers (if following best practices)
<RP> thomas_: the target rootfs often doesn't have dev headers but in general the files are the same, just a different set of them in each
<LetoThe2nd> Guest49: closest thing probably is https://gitlab.com/pbarker/meta-linux-mainline
<qschulz> Guest49: in short, just backport ("import") or create a newer recipe for your kernel in your dunfell layer
<LetoThe2nd> Guest49: other than that, look at the BSP, you might want to derive a custom one.
<LetoThe2nd> qschulz: hi5
<thomas_> RP, so I could just define a "dev-image" on my own, replace all "packages" with "packages-dev" and would come close enough to the normal SDK rootfs?
<Guest49> qschulz: I have meta-freescale. Is that the BSP layer?
<RP> thomas_: probably :)
<thomas_> Are there any "internal oe-mechanism" which do exactly this for most used packages (for the do_populate_sdk task)? For example the linux-kernel?
<qschulz> Guest49: very likely yes
<thomas_> I would live to ask denix about this. There must be an idea behind arago to handle this case. (Creating SDK for custom image)
florian_kc is now known as florian
<thomas_> *love
<RP> thomas_: normally you can get an SDK for a given image with the populate_sdk task ?
<thomas_> RP, unfortunately not for the TI image. They have an different way to do this
<RP> thomas_: I'd have thought the mechanism would still be there unless the specifically remove it
<thomas_> I ended up with some EXTERNAL_ARM_TOOLCHAIN error, so I tried to go the TI way, but it seems the targetfs from image differs with the one of their SDK
<RP> thomas_: external toolchains do complicate things
<thomas_> Their build is complicated. There are three different toolchains, two different target cores which are configured via multiconfig
<thomas_> So I'm not sure, if the normal way via do_populate_sdk should work with arago
nemik has quit [Ping timeout: 260 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 248 seconds]
nemik has joined #yocto
<Guest49> I have yocto dunfell with a freescale BSP linux-fslc-imx_5.4.bb saying SRCBRANCH = "5.4-1.0.0-imx" and LINUX_VERSION = "5.4.61". Can I simply change it to a newer kernel branch and linux version? Is this separated from the rest of the yocto distro?
<Guest49> ...I mean I'd like to create a linux-fslc-imx_5.4.bbappend  file and override the SRCBRANCH and LINUX_VERSION to use a 2.10 kernel
<Guest49> ...in my own yocto layer. Is this a good idea?
<thomas_> At least I've done this that way. Override the used kernel sources in my own layer
starblue has quit [Ping timeout: 248 seconds]
<thomas_> Probably, you have to change/specify kernel config and devicetree as well
starblue has joined #yocto
<Guest49> thomas_: Is your message a reply to me?
<thomas_> Guest49, yes
<Guest49> ah OK. Thanx!
<agherzan> RP: landgraf re the shell env error: BB_ENV_PASSTHROUGH_ADDITIONS
<agherzan> https://git.yoctoproject.org/poky/commit/?id=478cb0ce2c71273799695240845a687aaac0cb0c uses BB_RENAMED_VARIABLES to validate the shell env but the rename didn't reach the definition in bitabek.conf: https://git.yoctoproject.org/poky/tree/meta/conf/bitbake.conf#n93
<agherzan> Is this as simple as defining a BB_RENAMED_VARIABLES entry for BB_ENV_EXTRAWHITE?
Domin1k has joined #yocto
F_Adrian has joined #yocto
<agherzan> Currently it is handled in the smart dictionary
<Guest49> Which .conf file says whether linux-fslc_5.10.bb or linux-fslc-imx_5.4.bb should be used from meta-freescale/recipes-kernel/linux ?
<RP> agherzan: Isn't that in the list in data_smart.py though?
<kranzo> Guest49: check bitbake -e for virtual/kernel to see the variable expansion
<thomas_> Guest49, i think there comes the priorities of layers into the game
<agherzan> RP: that is the thing. It is in bitbake_renamed_vars but that throws a generic rename error. The shell specific error uses BB_RENAMED_VARIABLES.
<RP> agherzan: the shell specific error is using if k in bb.data_smart.bitbake_renamed_vars: ?
<qschulz> Guest49: use PREFERRED_VERSION_linux-fslc = "5.10%" in your machine conf file
<qschulz> that should probably be enough
<qschulz> maybe virtual/kernel instead of linux-fslc, but you'll see
<agherzan> No, the shell specific error uses BB_RENAMED_VARIABLES. While the generic rename error uses bb.data_smart.bitbake_renamed_vars
<agherzan> Maybe I'm wrong
<agherzan> Let me double check
<agherzan> You are right. landgraf what is the exact error you are seeing on your side?
<Domin1k> Hi everybody. Does someone know if it's possible to get the "Copyright notice" of every Package that bitbake build for an image? All i get currently get is a licence list that includes the packages and its licenses.
<rburton> isn't the LICENSE field sufficient?
<landgraf> agherzan: "ERROR: Variable BB_ENV_EXTRAWHITE has been renamed to BB_ENV_PASSTHROUGH_ADDITIONS" ERROR: Variable BB_ENV_EXTRAWHITE from the shell environment has been renamed to BB_ENV_PASSTHROUGH_ADDITIONS ERROR: Exiting to allow enviroment variables to be corrected
<agherzan> landgraf: so the error correctly reports that the rename is from the shell env.
<landgraf> agherzan: it was reported on project's channel today by user. I had this issue few weeks ago not today.
<RP> agherzan: people don't read :(
<landgraf> agherzan: second one. yes
<Domin1k> I'm not an expert with  licensing. But for example: https://github.com/curl/curl/blob/master/COPYING says: "Permission to use, copy, modify, and distribute this software for any purpose
<Domin1k> with or without fee is hereby granted, provided that the above copyright
<Domin1k> notice and this permission notice appear in all copies."
<agherzan> RP: sorry for the noise. I'll come back if needed
<RP> agherzan: perhaps we change it ti read Shell environment variable XXX has been renamed to YYY
<agherzan> RP: That doesn't sound bad but that was not my aim here. I thought it is wrongly omitting the shell mention.
nemik has quit [Ping timeout: 260 seconds]
nemik has joined #yocto
<rburton> Domin1k: are you concerned about the 'appear in all copies' bit? assuming you don't take the curl tarball, delete the COPYING file, and then redistribute it you're good. the binary isn't a copy.
adrian_ has joined #yocto
F_Adrian has quit [Ping timeout: 248 seconds]
<Domin1k> rburton: It's not actually me that is concerned about it. It's my team leader. Our Product that uses yocto to build the target-image shows a QR-Code with an link to a License-Website. An external service provider that is resposible for this website requested the licenses in cyclonedx SBOM format and should include the Copyright notice. Thats why im
<Domin1k> asking about it.
<rburton> what you care about is the license texts, which are available
<Domin1k> How is it done in other products that use yocto? Do they show any Copyright notice for each packag?
<RP> Domin1k: presumably you provide the sources somewhere and the copyrights are included with the sources
nemik has quit [Ping timeout: 248 seconds]
nemik has joined #yocto
<rburton> latest release has a sbom class to generate a spdx file
<Domin1k> The problem is we have to use a quite old release (Rocko) for our product.
<rburton> ah, rocko, end-of-life in november 2018
<Domin1k> We thought we don't need to provide the sources. We just sell our products B2B
<rburton> if you're distributing binaries you need to provide the sources for the GPL bits
<rburton> *at least* GPL bits
<Domin1k> I know that rocko is end-of-life
<rburton> it's fairly easy to generate a list of recipes and their license statements
<Domin1k> OK If it's easy could you please tell me how?
<rburton> RP: speaking of which, I guess I should finish off https://git.yoctoproject.org/poky-contrib/commit/?h=ross/mut&id=af2cfb732b5d8b0c20520f9cb997b18a813aee4d and submit it
<Domin1k> Do you know any example License-Website of a Product that actually uses yocto to build their image?
<Domin1k> rburton: Thanks!
<kayterina[m]> is this a yocto or bitbake variable? I am searching for in tin the documentation for what it does: ROOTFS_BOOTSTRAP_INSTALL
<rburton> kayterina[m]: yocto. image.bbclass sets ROOTFS_BOOTSTRAP_INSTALL = "run-postinsts"
<kayterina[m]> What does the variable do? It is overriden in the image to be empty.
<rburton> it pulls run-postinsts into the image so that postinsts can be run on first boot
<rburton> some images disable this as they don't boot (eg containers)
amahnui1 has quit [Quit: Connection closed for inactivity]
<RP> rburton: probably :)
<RP> Domin1k: the way most people solve this issue with the copyright is by providing the sources, it is easy and there is no good reason not to provide them really
<RP> Domin1k: We have a mechanism to extract the licenses, we don't have any markup saying where all the copyright headers are. If you want to just provide the copyright headers, you'd have to add recipe markup saying where they all were
<RP> Domin1k: license issues depend a lot on your legal department so you need their guidance on what to provide. There are many products out there based on Yocto Project, you'd have to look at their websites to see what they do
<kayterina[m]> I have a dependency from a my-image.bb to another image like this:
<kayterina[m]> do_image[depends] += "my-image-rootfs:do_build"
<kayterina[m]> do_build is the default bitbake task. Does that mean that my-image-rootfs.bb gets parsed and since it contains IMAGE_INSTALL += "packagegroup-.... etc ", IMAGE_INSTALL gets appended for my-image?
<kayterina[m]> In practice, I do not see the variable IMAGE_INSTALL to include anything more than what my-image.bb sets it to.
<rburton> no
<rburton> it just means that my-image-rootfs's do_build task runs before my-image:do_image task runs
<rburton> there's no copying of assignments
<rburton> if you want to use an image recipe as a base for another image recipe then just 'require other-image.bb'
tnovotny has quit [Quit: Leaving]
chrysh has quit [Ping timeout: 260 seconds]
neverpanic has quit [Ping timeout: 256 seconds]
nemik has quit [Ping timeout: 248 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 252 seconds]
nemik has joined #yocto
pgowda_ has joined #yocto
slips3 has joined #yocto
otavio has quit [Remote host closed the connection]
otavio has joined #yocto
slips3 has quit [Quit: Ping timeout (120 seconds)]
<kayterina[m]> I am trying to trace how a certain packagegroup gets included in the recipe and this do_image[depends] is the closest I could find. How do I see what an image has included?
kroon has joined #yocto
<kroon> RP, "git checkout 2.0" gives a warning, which is a little annoying. I think it was avoided in the 1.x branches since tag names were of the form x.y.z, not x.y
<kroon> RP, this is in the bitbake git repo
neverpanic has joined #yocto
<RP> kroon: not sure what to do about that :/
<kroon> RP, rename the 2.0 tag to 2.0.0 ?
<kroon> well... i dunno
<kroon> its not the end of the world
<thomas_> http://dpaste.com//AM5DE3DEY : How to deal with this kind of conflicts? I think these are rather opkg conflicts than bitbake (?)
<RP> kroon: signed tags so I can't do it :/
<thomas_> This paste works better: https://dpaste.com/AM5DE3DEY.txt
<rburton> thomas_: looks like you have arago saying 'install openssh' but your image saying 'install dropbear', and you can't install both
<kroon> RP, ok
<thomas_> rburton, thanks! :)
<rburton> thomas_: easiest to not install dropbear
<sveinse> I'm trying to migrate my layer and system over to kirkstone, and it fails on git access to bitbucket.org. Temporary failure in name resolution. Is there a new jail/containerization on network access from within the recipe build?
Guest49 has quit [Quit: Guest49]
<rburton> yes, you can't access the network outside of fetch tasks
<rburton> so no sneakily going and fetching more code in do_configure
Domin1k has quit [Quit: Client closed]
<sveinse> Thank you
jatedev has joined #yocto
<jatedev> What does nut mean in stable/{branch}-nut in contrib repositories?
<RP> jatedev: next under test
nemik has quit [Ping timeout: 252 seconds]
nemik has joined #yocto
<thomas_> Are these "Disfavor package:" at the end something to worry about? https://dpaste.com/A5WWULDYL.txt
<thomas_> Because, the SDK installer hangs here: "Setting it up...ls: cannot access '.../install/environment-setup-*': No such file or directory
nemik has quit [Ping timeout: 256 seconds]
nemik has joined #yocto
PascalBach[m] has joined #yocto
spawn has joined #yocto
spawn has quit [Client Quit]
amahnui1 has joined #yocto
jmiehe has joined #yocto
vladest has quit [Quit: vladest]
sakoman has joined #yocto
vladest has joined #yocto
otavio has quit [Remote host closed the connection]
otavio has joined #yocto
oleksandr has joined #yocto
sashko has quit [Ping timeout: 276 seconds]
jmiehe has quit [Quit: jmiehe]
mckoan is now known as mckoan|away
oleksandr has quit [Remote host closed the connection]
oleksandr has joined #yocto
nemik has quit [Ping timeout: 256 seconds]
kroon has quit [Quit: Leaving]
nemik has joined #yocto
oleksandr has quit [Ping timeout: 248 seconds]
astlep has joined #yocto
nemik has quit [Ping timeout: 248 seconds]
thomas_ has quit [Ping timeout: 246 seconds]
nemik has joined #yocto
otavio has quit [Remote host closed the connection]
otavio has joined #yocto
florian has quit [Quit: Ex-Chat]
ecdhe has joined #yocto
ecdhe has quit [Read error: Connection reset by peer]
hcg has quit [Quit: Client closed]
sashko has joined #yocto
Guest82 has quit [Quit: Client closed]
sashko has quit [Ping timeout: 260 seconds]
kranzo has quit [Quit: Client closed]
florian has joined #yocto
sashko has joined #yocto
sashko has quit [Remote host closed the connection]
sashko has joined #yocto
Tyaku has joined #yocto
<Tyaku> Hi, Yesterday I made a recipe for a software at a specific version and it was working. Today I change the commit (I was not on the last release) and on this commit I have problems:
<Tyaku> The software works on Ubuntu, The software works on Yocto target when I manually build it using the Yocto toolchain (it's a cmake project).
tre has quit [Remote host closed the connection]
<Tyaku> But the software build by bitbake crash on started. : *** buffer overflow detected ***:[ 743.717591] audit: type=1701 audit(1651677629.332:7): auid=4294967295 uid=0 gid=0 ses=4294967295 pid=1504 comm="main_thread" exe="/usr/bin/cpcd" sig=6 res=1
<Tyaku> *crash when started.
<qschulz> Tyaku: check the flags used by the toolchain by yocto
<qschulz> run.do_compile in ${WORKDIR}/temp
<Tyaku> Exactly, I think we don't have the same flags, as for example the binary size are really diffrent (probably stripping not applied with the toolchain)
<qschulz> i've seen badly written software fail when different optimization levels were used
sashko has quit [Ping timeout: 256 seconds]
<Tyaku> I don't understand "run.do_compile in ${WORKDIR}/temp"
<qschulz> Tyaku: each recipe has a work directory, ${WORKDIR} is the path to it
<qschulz> in there you have a temp directory with all logs
<qschulz> run.do_compile is exactly what will be run by bitbake for the do_compile task
<Tyaku> Thanks, I have it, i'm going to compare with the project build with the toolchain
rfuentess has quit [Remote host closed the connection]
<Tyaku> Hum not easy, there are differences but they are maybe not "important". The optimizations seems to be equals (do_compile: https://pastebin.com/8uYtEFmv, script that init environment: https://pastebin.com/nXHaS2QL)
<Tyaku> Some of differences in flags are "-fmacro-prefix -fdebug-prefix fdebug-prefix-map .. " from bitbake but as the optimizations are the same I think there is no big difference
<Tyaku> oh but... -fstack-protector-strong
<qschulz> Tyaku: you can try to disable it with SECURITY_STACK_PROTECTOR="" in your recipe I think
<qschulz> and see if this results in something that works better
<qschulz> then, you should really investigate, because I don't think that's a great idea to keep it disabled
amahnui1 has quit [Quit: Connection closed for inactivity]
ThomasRoos has quit [Quit: Client closed]
<Tyaku> I will try to see it tomorrow, currently I don't have solutions. I have to find the correct way to compare the flags because I'm not sure if it is (or not) used when I compile the project with cmake + yocto toolchain on ubuntu. The parameter is present in the script that initialize the environement but not sure if it's taken during the build.
<Tyaku> I try to force it on CFLAGS too see if there is a difference but NOP
<Tyaku> Woh poh poh. Yeah I have to check the flags correctly.
<Tyaku> /usr/bin/cpcd: ELF 64-bit LSB pie executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, BuildID[sha1]=80be98a07569c15ad1c7be2df079e74ec5405406, for GNU/Linux 3.14.0, stripped
<Tyaku> /tmp/cpcd: ELF 64-bit LSB pie executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, BuildID[sha1]=b15b0b6915f912944c65440d01321d7e4d171e17, for GNU/Linux 3.14.0, with debug_info, not stripped
<Tyaku> "with debug_info"
<Tyaku> I will check tomorrow. Thanks bye.
leon-anavi has joined #yocto
OnkelUlla has quit [Read error: Connection reset by peer]
Tyaku has quit [Quit: Lost terminal]
ecdhe has joined #yocto
<sveinse> I have a web-application that I'd like to package and it has a package.json/package-lock.json. How can I write the recipe in order to fetch the npm modules from this package manifest?
<Tokamak> is it possible to define a raw python function in a machine conf file? I'm hitting ParseError w/ little indication as to why. unparsed line: 'def insanity(d):'
<rburton> if its failing to parse the function header, that tells you that functions can't be parsed there :)
<rburton> throw the code in a class and add it to INHERIT?
<Tokamak> Tried that as well, but instead of a Python Error, i'm getting the python call VAR = "$(@insanity(d)}" trickling all the way down to the bash file (unevaluated).
<Tokamak> Is there a limitation on the parser in machine.conf files? e.g. no python calls / definitions?
<vvn> Do I really need the formfactor package to have a functional touchscreen? It looks like a custom open embedded application
<rburton> you can replace the users of formfactor, sure
pgowda_ has quit [Quit: Connection closed for inactivity]
florian has quit [Ping timeout: 276 seconds]
florian has joined #yocto
<sveinse> I'm trying to convert a large git repo with subrepo into gitsm:// but I get loads of warnings that submodule references are not absolute. Isn't `git@github.com:someone/something.git` considered an absolute reference? It's pretty standard
<sveinse> hmm, has Fetcher issues with git-lfs?
<sveinse> I'm getting lots of errors like "Error downloading..", "ssh: Could not resolve hostname bitbucket.org: Temporary failure in name resolution". Sounds to be related to the close down of network access from recipes in kirkstone. How can I work around this?
florian has quit [Ping timeout: 260 seconds]
<sveinse> I found this that should fix LFS contents https://lists.openembedded.org/g/bitbake-devel/topic/patch_v2_bitbake/80035073?p=,,,20,0,0,0::recentpostdate%2Fsticky,,,20,2,0,80035073
<sveinse> Could there be an issue with LFS in subrepos under gitsm?
<rburton> sveinse: possibly. there most likely are no tests for it. if you can replicate with a tiny repository then a test can be created
<rburton> https://git.yoctoproject.org/git-submodule-test/ is the test repo for git submodules, feel free to extend it with some lfs attributes in a branch if you want
<sveinse> While investigating this, is there a temp workaround to allow network access within the task? We're stuck
<jsbronder> sveinse: `do_mytask[network] = "1"`? https://docs.yoctoproject.org/4.0/migration-guides/migration-4.0.html
<sveinse> jsbronder: haha, I missed that specific entry in the migration guide. In Norway we have a saying that is something along the lines of "the first thing you get blind with is your eyes". Thank you.
<jsbronder> It's a lot easier when you know what to search for and which document to do so in ;)
sashko has joined #yocto
sashko has quit [Ping timeout: 246 seconds]
florian has joined #yocto
nemik has quit [Ping timeout: 248 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 256 seconds]
nemik has joined #yocto
<sveinse> LFS in gitsm does indeed work when setting `do_unpack[network] = "1"`. Getting closer to an confirmation that it's a bug
GillesM has joined #yocto
frieder has quit [Remote host closed the connection]
GillesM has quit [Client Quit]
zyga-mbp has joined #yocto
nemik has quit [Ping timeout: 256 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 246 seconds]
nemik has joined #yocto
sashko has joined #yocto
sashko has quit [Ping timeout: 260 seconds]
BWhitten has joined #yocto
florian_kc has joined #yocto
<yudjinn[m]> hello, is there an example of using AWS to dynamically spin up a high-CPU machine and run bitbake?
florian has quit [Ping timeout: 260 seconds]
<rburton> yudjinn[m]: too many variables for there to be 'one' way to do that really
creich has joined #yocto
<yudjinn[m]> rburton: I figured, just wanted to know if there were some example of doing it at all; I'm sure it'll just be a EC2 instance with a boat load of cores and memory
florian_kc has quit [Ping timeout: 260 seconds]
leon-anavi has quit [Remote host closed the connection]
BWhitten has quit [Ping timeout: 250 seconds]
mvlad has quit [Remote host closed the connection]
tomzy_0 has quit [Quit: Client closed]
<khem> zeddii AMD is creating platforms with Yocto I did not know :) https://www.phoronix.com/scan.php?page=news_item&px=AMD-Hiring-Embedded-Yocto
florian_kc has joined #yocto
creich has quit [Quit: Leaving]
guysoft42 has joined #yocto
guysoft42 has quit [Ping timeout: 252 seconds]
nemik has quit [Ping timeout: 252 seconds]
nemik has joined #yocto
<sveinse> yudjinn[m]: One way could be to have a build front-end, something 24/7 that hosts and manages the builds/build lanes. When a build is triggered a high-perf VM is spun up, all layers downloaded, yocto built and output uploaded to the build front-end server and finally shut down. We're considering such a setup for us in Azure.
sashko has joined #yocto
<yudjinn[m]> sveinse: I'm less concerned with needing a frontend, I'd like to even manually submit builds. I plan on figuring out this in more detail, but wanted to know if anyone knew of an example or writeup doing something similar
<sveinse> Since yocto/bitbake doesn't really approach any configuration management (except local.conf, site.conf, et.al), there will have to be made a framework on top of yocto. -- Depending on the circumstance of what and how the yocto artifacts will be used and deployed.
sashko has quit [Ping timeout: 246 seconds]
<yudjinn[m]> sveinse: yep, we manage different builds as submodules or branches, so a manual submittal would make more sense
adrian_ has quit [Ping timeout: 260 seconds]
<sveinse> We have a top-repo which is a git submodule repo containing all the (pinned) layers and a build/conf dir with the specifics for that build. Each branch of this repo corresponds to a separate build lane. And on top of this is a custom build management system that manages build versions and are packaging the yocto images into customer deployable formats.
dev1990 has quit [Quit: Konversation terminated!]
florian_kc has quit [Ping timeout: 256 seconds]
florian_kc has joined #yocto
florian_kc has quit [Ping timeout: 260 seconds]
jatedev has quit [Quit: Client closed]
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #yocto
dreese has joined #yocto
nemik has quit [Ping timeout: 248 seconds]
nemik has joined #yocto