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)
risca has joined #yocto
rewitt2 has quit [Remote host closed the connection]
xmn has quit [Ping timeout: 265 seconds]
<Ch^W> v0n: You should be able to. It is defined in the wic image type bbclass.
<Ch^W> Ok I gave up fighting with bison 3.7.5 and downgraded to 3.5.4 from Dunfell. That appears to be working just fine. FWIW, 3.7.2 (from Gatesgarth) exhibited the same issues.
mckoan|away has quit [Ping timeout: 244 seconds]
<override> window 4
mranostaj has quit [Remote host closed the connection]
mranostaj has joined #yocto
mckoan|away has joined #yocto
<override> is devtool just losing it again or do I actually need to cater to the unmet depedencies shown at the end - https://paste.ee/p/0TgDo
<khem> Ch^W: it will be good if you can narrow it down to crash and push it as a bug into bugzilla so we do not lose the info
jpuhlman__ has joined #yocto
jpuhlman_ has quit [Ping timeout: 258 seconds]
<khem> override: if you are using devtool to add new recipe then be aware it that it only is best effort in creating a recipe which can be used as baseline to finalize a working recipe. while many a times it just does the job perfectly there could be cases where it wont. So idea is to create the template and edit it to make it work as desired
<khem> so if its not catching all dependencies, we would like it to, but if it does not then they have to be edited manually
<override> khem - I get that, but the pastebin I shared earlier .. the recipe builds fine, but Im not sure why devtool has those comments at the end about adding some additional rdepends. Just confused if I should bring all those packages in, or if theyre already getting picked up from somewhere becuase the recipe builds..
otavio has quit [Remote host closed the connection]
otavio has joined #yocto
RobertBerger has joined #yocto
rber|res has quit [Ping timeout: 268 seconds]
<override> Running into this multiple providers issue, which I dont know ho to git rid of - https://paste.ee/p/T7e4T
<override> :window 4
lus-ito[m] has joined #yocto
<override> any quick solutions about ^ preferred providers or something?
<override> khem?
<khem> building is one thing but some packages maybe needed when running the resulting packages so its suggesting those maybe needed in RDEPENDS_${PN}
<khem> but it can not be sure
<override> cool, I guess I need to bring those in..
<override> and how about that multiple providers thing? how should I go about that
<Ch^W> khem: Thanks, I will do that. So far I have determined that this is the last known good bison recipe (for me at least) 73f05ba5 (openembedded-core). That is bison 3.6.4.
<khem> override: remove that semicolon
<Ch^W> I built the current Hardknott SDK using Thud's GCC 8. I did not use the extended buildtools at the time. I almost wonder if I should try rebuilding the SDK using the extended buildtools so I build it with GCC 10.
<override> cool, thanks. Ill look up that syntax too.
<Ch^W> As if this is some compiler building the compiler problem.
<khem> override: also show the recipe you are building after editing and read through manual on how to specify syntax etc. and learning anatomy of recipe is also helpful
lus-ito[m] has left #yocto [#yocto]
<khem> Ch^W: whats your host distro when you are building you build host OS
<khem> the bug might be indirecttly injected two levels removed
<khem> although I doubt it will happen, its perhaps some kink in new bison
<Ch^W> khem: This is a lineage. Originally it was Ubuntu, way back when. Then we built a fully running SDK VM with pyro, and then just built the thud SDK from that.
<Ch^W> So Ubunto -> Pyro based VM -> Thud based VM -> Hardknott based VM
<Ch^W> *Ubuntu
<override> Thanks, yeah I gotta look up what the ; and those ,,,, are for for these rdepends. This is what im building now - https://paste.ee/p/MgoRL khem
<Ch^W> I would assume building the Hardknott SDK vm in the old thud VM *with* the extended build tools would break any chain like that.
<khem> Ch^W: ok I would simply suggest to see if you can generate a stack trace when it crashed and we can track it from ther e
<Ch^W> khem: I can do that. Should I submit it to the yocto bugzilla?
<khem> override: python3-typing is not independent package ( ipk/rpm/dpkg ) its bundled into python3-core itself so remove it from RDEPENDS
<override> oh, okay..
<khem> there is python3-typing-extensions if you need that
<khem> Ch^W: yes plz
<override> sometimes the devtools give me this RDEPENDS_${PN} += "python3-core python3-typing"
<override> is that a bug then?
<khem> override: you can use some tools to find out who provides what e.g. oe-pkgdata-util find-path "*typing.py"
<khem> it will show you which package provides typing python module
<khem> python3-core: /usr/lib/python3.9/typing.py
<khem> so it means its coming from python3-core which when added to RDEPENDS_${PN} will be enough for runtime and python3-core is provides by python3 recipe so having python3 in DEPENDS will ensure that needed stuff during build time is available
otavio has quit [Ping timeout: 252 seconds]
<khem> oe-pkgdata-util lookup-recipe python3-core will show you which recipe will provide python3-core package in your env
<khem> so thats how you can navigate from file namespace to package to recipe and so on
hpsy has joined #yocto
<override> yeah, I was kinda using that for the packages devtool would leaves out in the comments. The oe-pkgdata-util path to package
<override> thanks khem
hpsy1 has quit [Ping timeout: 265 seconds]
<override> ill just double check all my rdpends too - t he ones devtool put in
otavio has joined #yocto
<Ch^W> Huh... it in fact is appearing to be a compiler issue.
<khem> you mean host compiler?
<Ch^W> Yes, which is built from gcc8 in thud.
<Ch^W> I installed buildtools-extended *AND* deleted tmp-glibc/hosttools (I forgot to do the latter earlier today).
<khem> so gcc10 built with gcc8 for host ?
<Ch^W> And the build of gobject-introspection works perectly. No more bison bug.
<Ch^W> khem: Yup
jpnurmi has quit [Ping timeout: 252 seconds]
<Ch^W> I thing the last time anyone got to legitimately blame the compiler was in the 1970's ;)
<khem> but I thought your host SDK was hardknott based so thats new enough you should not need buildtools for that
<Ch^W> khem: Close
shoragan has quit [Ping timeout: 264 seconds]
<khem> yeah hosttools are usually for arcane distros
<khem> or for building older releases on newer distros
<Ch^W> Or for when gcc8 builds a broken gcc10...
bjobjo has quit [Ping timeout: 252 seconds]
<khem> hmm we do have supported distros which have gcc8
<Ch^W> We had been using this thud based VM for years. But this happens when we build hardknott with it and deploy it as a VM.
<khem> so perhaps its a yocto gcc8 bug
<khem> perhaps or some combinatiton
<Ch^W> khem: It would seem as if.
<Ch^W> Or maybe I needed to go one step further? gcc8 -> gcc10(from8) -> gcc10(from gcc10)
bjobjo has joined #yocto
jpnurmi has joined #yocto
<Ch^W> Since the intermediate gcc10 would not be built with gcc10 semantics.
<Ch^W> I assumed that was not the case. But...
<Ch^W> s/case/necessary/
shoragan has joined #yocto
<Ch^W> Ok... I am going to build a new hardknott VM with buildtools-extended set as it currently is. Then I am going to see if the problem replicates in the new VM without buildtools-extended.
<Ch^W> That is going to take all night.
<Ch^W> That should at least tell me if it is a gcc8->gcc10 problem or a problem with our SDK image recipe.
<override> Thanks khem.. I can bitbake all the new recipes now I think.. Need to build an image and run it on the board now
<khem> good deal
<khem> Ch^W: yeah
<Ch^W> khem: When you introduced gcc10, do you build gcc10 from a bootstrapped gcc10 (i.e. gcc9 -> gcc10)? Or could you just go from gcc9 -> gcc10 and consider it done? I am unfamiliar with guarantee the gcc project provides.
<khem> we do not bootstrap from scratch
<khem> we use host GCC as starting point
<khem> ideally one could do 3-stage bootstrap
prabhakarlad has quit [Ping timeout: 246 seconds]
Spooster has joined #yocto
Spooster has quit [Remote host closed the connection]
williamh89 has quit [Ping timeout: 246 seconds]
camus1 has joined #yocto
camus has quit [Ping timeout: 258 seconds]
camus1 is now known as camus
roussinm has quit [Quit: WeeChat 3.3-dev]
RobW has joined #yocto
xmn has joined #yocto
rcw has quit [Ping timeout: 252 seconds]
camus has quit [Ping timeout: 258 seconds]
davidinux has quit [Ping timeout: 258 seconds]
davidinux has joined #yocto
yates_work has joined #yocto
dtometzki has joined #yocto
camus has joined #yocto
paulg has quit [Ping timeout: 258 seconds]
georgem has quit [Quit: Connection closed for inactivity]
risca has quit [Ping timeout: 258 seconds]
risca has joined #yocto
zyga-mbp has joined #yocto
Guest5466 has joined #yocto
Guest5466 has quit [Client Quit]
ant_ has quit [Quit: Leaving]
rob_w has joined #yocto
goliath has joined #yocto
risca has quit [Ping timeout: 252 seconds]
zpfvo has joined #yocto
tperrot has quit [Ping timeout: 265 seconds]
risca has joined #yocto
bjobjo has joined #yocto
bjobjo has quit [Changing host]
leon-anavi has joined #yocto
tnovotny has joined #yocto
tperrot has joined #yocto
vmeson has quit [Ping timeout: 252 seconds]
PascalBach[m] has joined #yocto
camus1 has joined #yocto
camus has quit [Ping timeout: 265 seconds]
camus1 is now known as camus
vmeson has joined #yocto
<PascalBach[m]> Is it possible to update the sysroots folder of an extracted eSDK. The use case is that I'm primarily using the eSDK to develop a C++ application directly with CMake, by sourcing the provided environment- file. Now I would like to update a library the applications dependes on. This I can easily do with devtool modify. The problem I'm facing now is that I can't bring this change back into the environment as seen by CMake. I tried to do
<PascalBach[m]> "devtool build build-sysroots" but that doesn't work.
zpfvo has quit [Quit: Leaving.]
florian has joined #yocto
<PascalBach[m]> If this would work it would allow for a very nice workflow, where the developers can work on the main application using the familiar and efficient CMake workflow. But when they need to update a dependency they can rely on devtool to do that and also quickly test this. This way we don't need an additional package manager like conan or vcpkg.
zpfvo has joined #yocto
xmn has quit [Quit: ZZZzzz…]
tnovotny has quit [Quit: Leaving]
davidinux1 has joined #yocto
prabhakarlad has joined #yocto
davidinux has quit [Ping timeout: 265 seconds]
davidinux1 has quit [Ping timeout: 252 seconds]
davidinux1 has joined #yocto
davidinux1 has quit [Ping timeout: 258 seconds]
davidinux1 has joined #yocto
LetoThe2nd has joined #yocto
<LetoThe2nd> yo dudX
zyga-mbp has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
camus1 has joined #yocto
camus has quit [Remote host closed the connection]
camus1 is now known as camus
inittab has quit [Quit: leaving]
zyga-mbp has joined #yocto
mranostaj has quit [Ping timeout: 252 seconds]
RobertBerger has quit [Ping timeout: 252 seconds]
<rburton> RP: is ~August 1st too late for a glibc upgrade
RobertBerger has joined #yocto
<LetoThe2nd> rburton: which year?
<rburton> does it matter? :)
RobertBerger has quit [Ping timeout: 258 seconds]
<LetoThe2nd> dark matter.
davidinux1 has quit [Ping timeout: 258 seconds]
davidinux1 has joined #yocto
zyga-mbp has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<kanavin> rburton, I suppose it depends on whether khem (or you!) would be doing pre-testing with it before it's out, but starting integration work only after it's been tagged and released might be a bit too late
<RP> rburton: khem has pre-release patches ready for testing so if we start now...
<RP> kanavin: ^^^
zyga-mbp has joined #yocto
<rburton> aha, that might have all the mte integrated
<rburton> it does
tnovotny has joined #yocto
xmn has joined #yocto
kayterina has joined #yocto
leon-anavi has quit [Remote host closed the connection]
georgem has joined #yocto
leon-anavi has joined #yocto
davidinux1 is now known as davidinux
<otavio> Is someone aware of anything causing bitbake to get stuck? no progress in parsing metadata and like
<otavio> We are seeing this in two different build servers
<RP> otavio: is autorev enabled?
LocutusOfBorg has quit [Ping timeout: 268 seconds]
<otavio> RP: nops; very minimal local.conf
<RP> otavio: I'm not aware of anything
williamh89 has joined #yocto
<otavio> ahhh
<otavio> CONNECTIVITY_CHECK_URIS = ""
<otavio> solves it
<otavio> % curl -vv https://www.example.com
<otavio> * Trying 93.184.216.34:443...
<otavio> * Trying 2606:2800:220:1:248:1893:25c8:1946:443...
<otavio> * Immediate connect fail for 2606:2800:220:1:248:1893:25c8:1946: Network is unreachable
<otavio> RP: does it work in your end?
mranostaj has joined #yocto
leon-anavi has quit [Remote host closed the connection]
leon-anavi has joined #yocto
prabhakarlad has quit [Quit: Client closed]
<override> Hey everyone, I'm hoping to put an end to writing this recipe for a python app saga today. last night I got as far as making the recipes for the depencies not freak out when I'd run them with bitbake. Thanks for all the help with that. Now Im putting togethet a recipe for the application itself. I'm trying to figure out: 1)where/how I run the setup.py from in the application recipe. Should I just add
<override> IMAGE_INSTALL_append = " name of the recipe for application", or do I need to add all the dependencies in local.conf? This what the python application recipe looks like right now - https://paste.ee/p/T4Z6K
<RP> otavio: works here
<RP> * Connected to www.example.com (2606:2800:220:1:248:1893:25c8:1946) port 443 (#0
<RP> otavio: sounds like your ipv6 has some issue
prabhakarlad has joined #yocto
<rsalveti> otavio: I have this issue quite frequently with my isp, when just ipv6 gets broken for whatever reason
<tgamblin> override: you only need to do IMAGE_INSTALL_append = " recipename" in local.conf and its dependencies should be included in the built image as well
camus1 has joined #yocto
<override> tgamblin: thanks, really appreciate it. Can you link me to some recipies for python apps that call setup.py? Any pointers/reccomendations work. Im also reading up on it on the side.
camus has quit [Ping timeout: 268 seconds]
camus1 is now known as camus
<override> tgamblin: thanks!
paulg has joined #yocto
berton has joined #yocto
LocutusOfBorg has joined #yocto
Spooster has joined #yocto
<sgw> RP: Morning, did my v2 qmp change work better? I think I know what happened I was using selftest (stupidly) instead of do_testimage
<rburton> override: 99% of recipes in meta-python do. inherit setuptools3 does most of the magic, or if your thing is on pypi then inherit pypi does even more for you (sets up SRC_URI, for example)
camus has quit [Ping timeout: 265 seconds]
camus has joined #yocto
<override> rburton: cool, ill take a look. aiming to test this out on the actual board today. want to check if it'll still complain about any dependencies..
rob_w has quit [Quit: Leaving]
Spooster has quit [Remote host closed the connection]
<override> rburton: did you mean 99% of recipes in meta-python install using setup.py ?
<rburton> yes
<rburton> making up numbers, obviously
<rburton> but most python uses that
<override> ok let me grep for that ..
<rburton> as i said, inherit setuptools3 does it for yo
<rburton> so you won't find many references to setup.py directly in meta-python
<override> I see
<override> so like what does it end up looking like, like what step in the recpie would make the python package end up sitting the filesystem on the target.. I'm a total noob at using setup.py etc..
<override> or should I say a total noob at a whole lot of everything
<rburton> does the setup.py just setuptools or just distutils?
<override> it has a call to the setup function - https://github.com/Opentrons/opentrons/blob/edge/robot-server/setup.py
<rburton> setuptools
<rburton> so inherit setuptools3 in your recipe
<override> ok
<rburton> and that will handle configure/compile/install
<override> so I just inherit setuptools3 and im done?
<rburton> yes
<override> oh, wow.
<override> interesting
<RP> abelloni: the v2 was ok from sgw right?
<rburton> override: the pypi inherit sets up the SRC_URI to fetch from pypi, and the setuptools does the configure/compile/install
<otavio> RP: rsalveti: thx. In fact it was the IPv4 which was out
<override> nice. I was aware of the pypi bit, Tim taught me that. Just got to the configure/compile/install bits today
<otavio> * Trying 93.184.216.34:443...
<otavio> * Trying 2606:2800:220:1:248:1893:25c8:1946:443...
<otavio> * Immediate connect fail for 2606:2800:220:1:248:1893:25c8:1946: Network is unreachable
florian has quit [Read error: Connection reset by peer]
<otavio> * Connected to www.example.com (93.184.216.34) port 443 (#0)
<otavio> now worksed
<otavio> * ALPN, offering h2
florian has joined #yocto
<sgw> RP: I won't be on the Tech call today due to the SBOM plugfest, but you can ping me here if needed.
sakoman has joined #yocto
<williamh89> so to enable a packageconfig, do I just specify it in the PACKAGECONFIG variable?
<williamh89> for example there is PACKAGECONFIG[kmsdrm].. to enable it, I put PACKAGECONFIG = "kmsdrm" ?
<rburton> yes
<rburton> the flags in [] lists the set of possible config options
<rburton> and the value of PACKAEGCONFIG itself is the set of selected ones
<override> rburton: can you please help me get past this bump now, error - https://paste.ee/p/9Kpwz recipe - https://paste.ee/p/1ShYA
<rburton> https://github.com/Opentrons/opentrons <-- you check this out, but that isn't where the setup.py is
<override> oh, right. let me see whats up with that.
<rburton> set DISTUTILS_SETUP_PATH to the path where setup.py actually is
<rburton> it defaults to ${S}
<rburton> see distutils3.bbclass
<RP> sgw: ok, thanks. I think it is working
<override> rbuton: ok, thanks. That makes a lot of sense.
patrick_r has joined #yocto
<patrick_r> hello
<patrick_r> just a question about the kernel, I need to add the nfs support module to the kernel of the image, what's the best way to go about it?
<OutBackDingo> ok any insight as to why im hitting a run.do_image_box2_sdimg.1946: parted: not found
<OutBackDingo> | WARNING: exit code 127 from a shell command.
<OutBackDingo> i have inherit image_types ij the bbclass
<rburton> you don't have a depends anywhere on parted-native
<rburton> image types can set depends
Spooster has joined #yocto
Spooster has quit [Remote host closed the connection]
Spooster has joined #yocto
zyga-mbp has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<OutBackDingo> do_image_box2-sdimg[depends] += " \
<OutBackDingo> parted-native \
<OutBackDingo> parted \
<OutBackDingo> dosfstools-native \
<OutBackDingo> mtools-native \
<OutBackDingo> virtual/kernel:do_deploy \
<OutBackDingo> virtual/bootloader:do_deploy \
<OutBackDingo> "
<OutBackDingo> rburton: it is there
<rburton> i'd use -e to verify it is actually there
<rburton> (and remove the target parted)
<OutBackDingo> rburton: ok not fasmiliar with "use -e to verify it is actually there"
Spooster has quit [Remote host closed the connection]
Spooster has joined #yocto
<rburton> bitbake -e myimagename|less, search for the depends line you set
zyga-mbp has joined #yocto
<OutBackDingo> ahh you mena in biitbake... ok
Spooster has quit [Read error: Connection reset by peer]
Spooster has joined #yocto
<OutBackDingo> [depends] " parted-native mtools-native dosfstools-native virtual/kernel:do_deploy
<OutBackDingo> virtual/bootloader:do_deploy "
<OutBackDingo> appears to exists
wesm has quit [Ping timeout: 265 seconds]
camus has quit [Remote host closed the connection]
camus has joined #yocto
<RP> OutBackDingo: shouldn't there be a :do_populate_sysroot at the end of those?
Guest50 has joined #yocto
wesm has joined #yocto
patrick_r has quit [Quit: Client closed]
<OutBackDingo> RP: as in ?
<OutBackDingo> do_image_zipabox2-sdimg[depends] += " \
<OutBackDingo> mtools-native:do_populate_sysroot \
<OutBackDingo> virtual/kernel:do_deploy \
<OutBackDingo> dosfstools-native:do_populate_sysroot \
<OutBackDingo> parted-native:do_populate_sysroot \
<OutBackDingo> virtual/bootloader:do_deploy \
<OutBackDingo> "
<rburton> yes
Guest50 has quit [Quit: Client closed]
<OutBackDingo> welp rebuilding it fresh now so we will see
<rburton> i presume you didn't wipe sstate so thats a few seconds right
<paulbarker> RP and anyone else interested: Results of running `reuse lint` on bitbake: https://pastebin.com/afCuL5K8
<paulbarker> The tools wants a top level `LICENSES` directory with full text for all used licenses which is probably unnecessarily strict
<tlwoerner> i've always found the license of the recipe itself to be rather curious
<paulbarker> tlwoerner: The licenses of patch files are the ones I find curious
<tlwoerner> paulbarker: yes, that too
kayterina has quit [Remote host closed the connection]
tnovotny has quit [Quit: Leaving]
<OutBackDingo> rburton: ermm nope same error :(
<rburton> OutBackDingo: is the -sdimg intentional in your depends line? the log says _sdimg
<OutBackDingo> i would think yes, it was all converted up from pyro
<OutBackDingo> according to the guide, i can change it to _sdimg
<OutBackDingo> doesnt hurt to kick it
<rburton> you most likely should
zyga-mbp has quit [Quit: Textual IRC Client: www.textualapp.com]
Vonter has joined #yocto
rber|res has joined #yocto
camus1 has joined #yocto
zpfvo has quit [Remote host closed the connection]
camus has quit [Ping timeout: 258 seconds]
camus1 is now known as camus
williamh89 has quit [Ping timeout: 246 seconds]
Vineela has joined #yocto
rfs613 has joined #yocto
LetoThe2nd has quit [Quit: Connection closed for inactivity]
nerdboy has quit [Ping timeout: 268 seconds]
<berton> Hi! I'm running a populate_sdk task and seeing this on log:
<berton> check_data_file_clashes: Package kmsxx-dbg wants to install file /home/builder/build/tmp/work/foo-poky-linux/core-image-minimal/1.0-r0/sdk/image/opt/bar/sysroots/aarch64-poky-linux/usr/bin/.debug/kmstest
<berton>
<berton> But that file is already provided by package * libdrm-dbg
<berton>
<berton> The install_complementary function runs this install https://git.openembedded.org/openembedded-core/tree/meta/lib/oe/package_manager/__init__.py#n401, with attempt_only=True,
<berton>
<berton> I see this comment https://git.openembedded.org/openembedded-core/tree/meta/lib/oe/package_manager/__init__.py#n346, but "file is already provided by package" is not an error?
<OutBackDingo> rburton: ok thats also a fail... open for more ideas :)
nerdboy has joined #yocto
Spooster has quit [Remote host closed the connection]
florian has quit [Ping timeout: 268 seconds]
ant_ has joined #yocto
Spooster has joined #yocto
florian has joined #yocto
florian has quit [Ping timeout: 268 seconds]
berton has quit [Ping timeout: 244 seconds]
Spooster has quit [Remote host closed the connection]
BCMM has joined #yocto
Spooster has joined #yocto
Vonter has quit [Ping timeout: 252 seconds]
LetoThe2nd has joined #yocto
warthog9 has quit [Ping timeout: 264 seconds]
florian has joined #yocto
berton has joined #yocto
Spooster has quit [Remote host closed the connection]
Spooster has joined #yocto
warthog9 has joined #yocto
sgw has quit [Ping timeout: 244 seconds]
berton has quit [Remote host closed the connection]
sgw has joined #yocto
BCMM has quit [Quit: Konversation terminated!]
camus1 has joined #yocto
camus has quit [Ping timeout: 268 seconds]
camus1 is now known as camus
bluelightning has quit [Quit: Konversation terminated!!!111]
Spooster has quit [Remote host closed the connection]
prabhakarlad has quit [Quit: Client closed]
prabhakarlad has joined #yocto
<vmeson> khem: Is there a reason that meta-browser hasn't created a hardknott branch ?
sgw has quit [Ping timeout: 258 seconds]
<khem> vmeson: usually it tries to validate master with multiple releases
<khem> e.g. backup to dunfell,
<khem> building browsers is not for faint machines, so thats best which can be done
sgw has joined #yocto
<override> hey khem, had a rather basic question for you where all would this script be install stuff on the target, like what path - https://paste.ee/p/73Ir5
<override> having a hard time finding stuff on the target
<override> oh nevermind did a find . -name and found some stuff
Spooster has joined #yocto
<marex> hey, is there some smarter way of running yocto-check-layer in CI ? It takes quite a while to comb through the layers, so I was wondering if there is some way to improve that
<marex> also, what else do I want to run in CI to validate layer changes, patchreview.py looks nice, anything else ?
bluelightning has joined #yocto
Vonter has joined #yocto
Vonter has quit [Ping timeout: 258 seconds]
<override> khem: with all the recipes etc I added yester should something like python -version work on the target?
camus has quit [Remote host closed the connection]
camus has joined #yocto
<override> trying to coming up with a plan to validate the python package I added to the image .. see if it runs into any run time dependencies missing or something
leon-anavi has quit [Quit: Leaving]
prabhakarlad has quit [Quit: Client closed]
Vonter has joined #yocto
florian has quit [Ping timeout: 268 seconds]
hpsy1 has joined #yocto
goliath has quit [Quit: SIGSEGV]
hpsy has quit [Ping timeout: 258 seconds]
LetoThe2nd has quit [Quit: Connection closed for inactivity]
xmn has quit [Ping timeout: 265 seconds]
<override> /usr/bin/python3.8 seems to work so I think python and all is working fine - will try to run something from the packaage now khem:
xmn has joined #yocto
<khem> yeah you might want to look into adding ptest for your package perhaps using pytest or something
hpsy has joined #yocto
hpsy1 has quit [Ping timeout: 258 seconds]
Vonter has quit [Ping timeout: 258 seconds]
<Ch^W> khem: I rebuilt the SDK image against 3.3.1 buildtools-extended only. I had to add some .h files from local /usr/include as well as local copies of libcap, libzstd, and the free command, but otherwise the build worked flawlessly.
<Ch^W> khem: VM comes up, but same problem building gobject-introspection.
<Ch^W> So either it is my image recipe, or GCC10 built from hardknott sources, breaks bison-native.
<Ch^W> *bison-native >= 3.7.1 that is.
<Ch^W> I think I have enough information to make it worth writing up a bug.
Vonter has joined #yocto