Wednesday, 2022-03-02

*** GillesM <GillesM!> has joined #yocto00:25
*** GillesM <GillesM!> has quit IRC (Remote host closed the connection)00:25
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has quit IRC (Quit: jmiehe)00:41
*** prabhakarlad <prabhakarlad!> has joined #yocto00:44
*** camus <camus!~Instantbi@> has quit IRC (Ping timeout: 256 seconds)00:59
*** camus <camus!~Instantbi@> has joined #yocto00:59
*** Guest23 <Guest23!~Guest23@> has joined #yocto01:02
*** Guest23 is now known as zw01:02
*** shoragan <shoragan!~shoragan@user/shoragan> has quit IRC (Ping timeout: 250 seconds)01:04
*** shoragan <shoragan!~shoragan@user/shoragan> has joined #yocto01:05
*** jclsn7 <jclsn7!> has quit IRC (Ping timeout: 240 seconds)01:15
*** jclsn7 <jclsn7!> has joined #yocto01:21
*** qschulz <qschulz!> has quit IRC (Remote host closed the connection)01:32
*** qschulz <qschulz!> has joined #yocto01:35
*** Wouter0100 <Wouter0100!> has quit IRC (Remote host closed the connection)01:42
*** Wouter0100 <Wouter0100!> has joined #yocto01:42
tlwoerneri'm seeing quilt errors: "File series fully applied, ends at patch <patch>"01:49
*** jclsn7 <jclsn7!> has quit IRC (Ping timeout: 256 seconds)01:50
tlwoerneri can clear them out by doing a cleaning, but they come back again a day or so later01:50
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has joined #yocto01:51
*** jclsn7 <jclsn7!> has joined #yocto01:55
*** jclsn7 <jclsn7!> has quit IRC (Ping timeout: 240 seconds)02:01
*** jclsn7 <jclsn7!> has joined #yocto02:07
*** sakoman <sakoman!> has quit IRC (Quit: Leaving.)02:17
*** camus1 <camus1!~Instantbi@> has joined #yocto02:18
*** camus <camus!~Instantbi@> has quit IRC (Ping timeout: 256 seconds)02:19
*** camus1 is now known as camus02:19
*** sakoman <sakoman!> has joined #yocto02:20
*** jclsn7 <jclsn7!> has quit IRC (Ping timeout: 256 seconds)02:21
*** jclsn7 <jclsn7!> has joined #yocto02:26
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has quit IRC (Quit: jmiehe)02:28
*** jclsn7 <jclsn7!> has quit IRC (Ping timeout: 240 seconds)02:47
*** jclsn7 <jclsn7!> has joined #yocto02:54
*** camus1 <camus1!~Instantbi@> has joined #yocto02:58
*** camus <camus!~Instantbi@> has quit IRC (Ping timeout: 240 seconds)03:00
*** camus1 is now known as camus03:00
*** jclsn7 <jclsn7!> has quit IRC (Ping timeout: 240 seconds)03:01
*** jclsn7 <jclsn7!> has joined #yocto03:02
*** jclsn7 <jclsn7!> has quit IRC (Quit: Ping timeout (120 seconds))03:11
*** jclsn7 <jclsn7!> has joined #yocto03:11
*** kanavin_ <kanavin_!~Alexander@> has joined #yocto03:17
*** kanavin <kanavin!~Alexander@2a02:2454:29b:3b00:d35d:e3cf:58b5:748b> has quit IRC (Ping timeout: 240 seconds)03:18
*** jclsn7 <jclsn7!> has quit IRC (Quit: Ping timeout (120 seconds))03:20
*** jclsn7 <jclsn7!> has joined #yocto03:20
*** jclsn7 <jclsn7!> has quit IRC (Ping timeout: 240 seconds)03:26
*** jclsn7 <jclsn7!> has joined #yocto03:28
*** jclsn7 <jclsn7!> has quit IRC (Quit: Ping timeout (120 seconds))03:35
*** jclsn7 <jclsn7!> has joined #yocto03:35
*** jclsn7 <jclsn7!> has quit IRC (Quit: Ping timeout (120 seconds))03:46
*** jclsn7 <jclsn7!> has joined #yocto03:46
*** jclsn7 <jclsn7!> has quit IRC (Quit: Ping timeout (120 seconds))03:53
*** jclsn7 <jclsn7!> has joined #yocto03:53
*** jclsn74 <jclsn74!> has joined #yocto03:59
*** jclsn7 <jclsn7!> has quit IRC (Ping timeout: 260 seconds)04:01
*** jclsn74 is now known as jclsn704:01
*** sakoman <sakoman!> has quit IRC (Quit: Leaving.)04:24
*** nemik <nemik!> has quit IRC (Ping timeout: 240 seconds)04:34
*** amitk <amitk!~amit@> has joined #yocto04:53
*** zw <zw!~Guest23@> has quit IRC (Quit: Client closed)05:14
*** nemik <nemik!> has joined #yocto05:19
*** geoffhp <geoffhp!~Geoff@> has quit IRC (Ping timeout: 250 seconds)05:52
*** alessioigor <alessioigor!~alessioig@> has joined #yocto06:01
*** alessioigor <alessioigor!~alessioig@> has quit IRC (Quit: alessioigor)06:07
*** cb5r <cb5r!~cb5r@user/cb5r> has joined #yocto06:22
*** mixfix41 <mixfix41!~homefame@user/mixfix41> has quit IRC (Ping timeout: 240 seconds)06:24
*** mixfix41 <mixfix41!~homefame@user/mixfix41> has joined #yocto06:36
*** Wouter0100 <Wouter0100!> has quit IRC (Remote host closed the connection)06:49
*** Wouter0100 <Wouter0100!> has joined #yocto06:49
jclsn[m]Morning, any idea how to fix this?... (full message at
jclsn[m]Think this happens since I fetched the latest commits from linux-fslc07:01
*** hoba <hoba!~hoba@> has joined #yocto07:02
jclsn[m]I already tried `bitbake -c cleanall libxkbcommon`07:02
*** tre <tre!> has joined #yocto07:03
*** goliath <goliath!~goliath@user/goliath> has joined #yocto07:04
*** hoba <hoba!~hoba@> has quit IRC (Quit: Client closed)07:15
*** lucaceresoli <lucaceresoli!~lucaceres@> has joined #yocto07:19
*** Etheryon <Etheryon!~textual@> has joined #yocto07:24
*** frieder <frieder!> has joined #yocto07:33
*** mckoan|away is now known as mckoan07:42
mckoangood morning07:42
*** rob_w <rob_w!~rob@2001:a61:605d:cd01:d44e:13ad:7b79:ce8d> has joined #yocto07:43
*** camus1 <camus1!~Instantbi@> has joined #yocto07:49
*** camus <camus!~Instantbi@> has quit IRC (Ping timeout: 260 seconds)07:51
*** camus1 is now known as camus07:51
*** tgamblin_ <tgamblin_!~tgamblin@2607:fea8:c29d:d7c0:fa88:8bc5:c0d2:27cc> has joined #yocto07:57
*** tgamblin <tgamblin!~tgamblin@2607:fea8:c29d:d7c0:fa88:8bc5:c0d2:27cc> has quit IRC (Ping timeout: 240 seconds)07:58
*** kroon <kroon!> has joined #yocto08:12
jclsn[m]Really weird error. Happens with mesa and wayland-utils as well. Something must have changed in meta-freescale again08:12
jclsn[m]If I interpret it right, something in the SDK is missing08:12
*** alessioigor <alessioigor!~alessioig@> has joined #yocto08:14
*** alessioigor <alessioigor!~alessioig@> has quit IRC (Client Quit)08:15
kroonhuh. just got "ERROR: Worker process (943374) exited unexpectedly (1), shutting down..." in up2date dunfell08:23
*** dev1990 <dev1990!~dev@> has joined #yocto08:25
*** michalkotyla <michalkotyla!> has quit IRC (Quit: michalkotyla)08:28
*** Tokamak <Tokamak!~Tokamak@> has quit IRC (Ping timeout: 240 seconds)08:31
*** Tokamak <Tokamak!~Tokamak@> has joined #yocto08:33
*** Schlumpf <Schlumpf!~Schlumpf@> has joined #yocto08:37
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto08:45
*** qschulz <qschulz!> has quit IRC (Remote host closed the connection)08:54
dwagenkjclsn: when packaging shows weird errors I usually get rid of TMPDIR and rebuild from sstate. I  remember one occasion where even that wasn't enough and I switched from `PACKAGE_CLASSES = "package_rpm"` to `PACKAGE_CLASSES = "package_deb"`, rebuild and then switched back to fix it. I couldn't reproduce that Issue, otherwise I'd have written a bug-report.08:56
dwagenk^ jclsn08:56
*** Tokamak <Tokamak!~Tokamak@> has quit IRC (Ping timeout: 250 seconds)08:58
*** qschulz <qschulz!> has joined #yocto08:58
*** Tokamak <Tokamak!~Tokamak@> has joined #yocto09:00
*** pgowda_ <pgowda_!> has joined #yocto09:08
*** florian <florian!> has joined #yocto09:10
*** Habbie <Habbie!> has joined #yocto09:28
*** pasherring <pasherring!~pasherrin@2001:8a0:ec55:b200:228d:ee61:fbb7:9bb8> has joined #yocto09:35
*** mvlad <mvlad!~mvlad@2a02:2f08:4b12:b100:24d7:51ff:fed6:906d> has joined #yocto09:52
jclsn[m]<dwagenk> "jclsn: when packaging shows..." <- Thanks, I tried deleting tmp10:21
jclsn[m]Currently I am having device tree issues with linux-fslc though. It reports syntax errors, although the same tree has always worked in the past10:22
jclsn[m]Seems that the device tree include syntax with `#include` is not accepted anymore10:32
jclsn[m]Has something in `devicetree.bbclass` changed?10:35
kroonthe dts needs to go through cpp for "#include" to work10:45
*** osama3 <osama3!> has joined #yocto10:48
jclsn[m]kroon: Yes, I read that, but haven't really changed anything11:09
jclsn[m]Also the imx8mm.dtsi uses this syntax11:10
jclsn[m]So it seems to be normal syntax in meta-freescale11:11
jclsn[m]or linux-fslc11:11
*** meego <meego!~meego@2001:41d0:fe7e:c800:ac5a:af08:91fd:3db3> has joined #yocto11:20
*** tnovotny <tnovotny!> has joined #yocto11:24
jclsn[m]I recently fetched the upstream changes from linux-fslc. Something must have changed there11:26
*** prabhakarlad <prabhakarlad!> has quit IRC (Quit: Client closed)11:27
*** Schlumpf <Schlumpf!~Schlumpf@> has quit IRC (Quit: Client closed)11:36
RPSaur[m]: I merged your changes but sadly a test failure slipped through in all the patch juggling. I'm hoping my tweaks help resolve it11:37
EtheryonHello, I'm trying to install a local RPM, but I get this error when running the recipe. cpio: /opt: Cannot change mode to rwxr-xr-x: Operation not permitted (in additino to others Permission denied) any idea how I can investigate this?11:39
kanavin_Etheryon, where is the rpm coming from?11:45
Etheryondownloaded from a website11:50
Etheryonit's an external tool for which the company provides rpm for installation11:51
kanavin_Etheryon, you can't install random rpms onto yocto images11:53
kanavin_Etheryon, that rpm was build for a specific distribution, probably RHEL or Fedora, and isn't meant for yocto11:53
kanavin_Etheryon, is the source code for the tool available?11:54
Etheryonnop, commercial tool11:54
EtheryonOK, thanks, I'll look into another way of installing it11:55
pgowda_Downloaded latest master sources and ran bitbake meta-toolchain12:00
pgowda_binutils-cross-x86_64-2.38-r0 do_fetch is running for more than 2 hrs (unusually)12:00
pgowda_Tried on 2 machines with same issue12:00
pgowda_Plz let me know if anyone else is facing same issue12:00
*** otavio <otavio!> has joined #yocto12:03
EtheryonIf I have a shell script that's an installer, should I run it in my recipe in do_install ?12:07
kanavin_Etheryon, yes, if the shell script can be directed to install to ${D}12:14
kanavin_otherwise, run the script outside of yocto, then make a tarball of what it writes out12:14
kanavin_then put the tarball to SRC_URI12:14
kanavin_Etheryon, even then, the tool is probably using specific shared libraries, which yocto may not be able to provide12:15
EtheryonI've looked in the rpm, and it seems it's a java app, so I'm hoping it's fairly self-contained?12:15
Etheryonugh, seems like the shellscript also ends up trying to install an rpm package12:20
rburtonsee if it has a 'just unpack the contents' option12:21
*** tre <tre!> has quit IRC (Ping timeout: 240 seconds)12:21
rburton(installers are the worst)12:21
Etheryonseems to do this eventually. -  installCmd="rpm -U --replacepkgs --oldpackage '$packageFilePath'"12:22
*** Schlumpf <Schlumpf!~Schlumpf@> has joined #yocto12:22
Etheryonand runs it12:22
rburton*worst case* create a 'rpm' script that just does exit 0, and put it in PATH before running the installer12:22
rburtonis this a hand-written installer, or is it generated by a tool?12:23
Etheryoncan I reverse engineer the rpm and install it manually? Sorry I haven't worked with packages before12:23
rburtoni'm guessing the installer is one of those where its a giant shell script with the binaries embedded in it12:23
EtheryonI'm guessing by a tool12:23
Etheryonyeah seems so12:23
Etheryoncontains that12:24
Etheryonso I'm back to square one12:24
rburtonis this public?12:24
RPEtheryon: if you have an rpm, I'd just try and extract the files manually and see if they're usable12:24
Etheryonso the rpm has got 2 jars in it and a shell script file12:25
RPI think the script in scripts/ in oe-core may help create something you can get files from out of an rpm12:25
rburtonput the rpm in src_uri, bitbake will unpack it for you, ignore the installer, just put the jars in the right place12:26
Etheryonwhen I tried that I got that permission error I mentioned earlier12:29
Etheryoncpio: /opt: Cannot change mode to rwxr-xr-x: Operation not permitted12:29
Etheryoncpio: Cannot mkdir: Permission denied12:30
RPIt sounds like it is is trying to extract the files into the main host OS root filesystem :(12:30
Etheryoneventually cpio -id failed with return value 212:30
RPEtheryon: you could try manually extracting the files using the script. It is possible the rpm extraction code isn't working properly :/12:30
RPEtheryon: it doesn't get used often and problbably doesn't have good tests :(12:31
landgrafrpm2cpio *rpm | cpio -id should work12:31
landgrafif it doesn't... something wrong with the rpm I guess12:31
RPsomething like an ;unpack=0 in the SRC_URI should stop bitbake trying to do it for you which may be where the error comes from12:32
Etheryonshould that extract it in the local folder?12:32
RPcheck the manual for the right param, I'm not 100% sure12:32
landgrafyes, it should extract under curdir12:33
* landgraf uses it almost daily12:33
*** tre <tre!> has joined #yocto12:33
landgrafEtheryon: like this12:35
Etheryonsame error, I'm guessing they hard-coded the paths?12:35
landgrafis it public rpm?12:35
landgrafI mean can I find it somewhere?12:36
* landgraf is interested how it's possible12:36
landgrafEtheryon: rpm2tgz should create tgz archive and then you can take a look what's inside12:37
landgrafEtheryon: or maybe rpm -qpl <name>.rpm will give you some clues.12:38
Etheryonok - rpm2archive + extract gave me the tree which is supposed to be installed I guess12:42
Etheryonseems to contain the same paths as the error messages I was getting earlier12:42
EtheryonI guess I can use that via bitbake?12:43
Etheryonand rpm -qpl lists the file tree12:44
smurraymy guess is that rpm has a post-install that's trying to touch /opt, so you'll likely always have issues with it12:44
*** mckoan is now known as mckoan|away12:45
Etheryonit had files that it wants to put in /opt12:45
Etheryonhow could I check for this post-install script?12:45
landgrafsmurray:: rpm -qp --scripts  ?12:45
landgrafEtheryon: ^12:46
landgrafsmurray: sorry12:46
smurrayor look at the .spec file after rpm2cpio or the like12:46
landgrafsmurray: it can be a problem if you don't have spec :)12:46
smurrayis it possible to not have a spec file in a rpm?12:47
smurrayI've never pulled one apart that didn't have one, I've always believed rpm needed it12:48
Etheryonthe archive extracted doesn't contain one12:48
smurraythat seems odd to me12:48
smurrayanyways, I'd say just take jar files and install them yourself with your own recipe as has been suggested by others12:48
RPsmurray: do the rpms we generate contain the spec? that seems odd to me FWIW12:48
smurrayRP: yes?  There's always a generated one in the workdir12:49
landgrafsmurray: iirc spec is part of src.rpm not the binary one12:49
landgrafsmurray: for proprietary rpms you may not have spec (zoom, chrome etc)12:50
smurrayhrm, true, it could be that only RedHat/Fedora/etc. include them12:50
Etheryonso this is that rpm2archilve + unarchinve resulted in:
Etheryonso is it enough to copy over the contents of this archive?12:51
RPsmurray: we generate one and use it to build the rpm but it isn't included in the rpms themselves12:51
smurrayRP: okay, TIL ;)12:52
smurrayEtheryon: you'll have to see what all those shared libraries expect to be able to link to, as kanavin_ mentioned earlier12:53
landgrafEtheryon: most likely your rpm tries to own /opt and chmod it which is not good idea obviously. If it's done in %files section it's a problem. if it's %post you can try to install with noscript option (man page should mention this, iirc there's posibility)12:53
landgrafit's --noscripts12:54
Etheryonpostinstall scriptlet (using /bin/sh):     <- is this what I'm looking for? from the rpm -qp --scripts ouput12:57
cb5rHow do I get the correct compiler flag values for -march and -mcpu? I am trying to compile an old project with newer SDK and am getting the following error now: "switch '-mcpu=cortex-a9' conflicts with '-march=armv7-a' switch"12:59
landgrafEtheryon: yes12:59
smurrayRP: heh, I need coffee, thinking about it, it's been src.rpm's from RedHat/Fedora/etc. that I've pulled apart with rpm2cpio in the past13:01
landgrafsmurray: yup. it was13:04
cb5rNVM - I found the solution: Remove -march because its redundant anyway if compiling for a specific -mcpu. Nevertheless, I find the error message confusing...13:05
pasherringHey there! Is it possible to clean sstate for recipes from a given layer?13:05
qschulzpasherring: why would you need to do this? cleansstate is the last resort and should rarely be used. If something breaks the sstate-cache, it needs to be fixed :)13:10
pasherringqschulz, probably this has to do with my messed up workflow. I am trying to understand the meta-virtualization for rpi4, and I need to "swap" layers, from stock to some custom layer. And whenever I swap them, I notice that the changes go unoticed. :/13:12
pasherringAlso, I know I am probably doing something wrong xD But, I really want to understand the meta-virt and xen for the rpi4. So, probing is really the only way I found to "move forward"13:13
qschulzpasherring: if the change in the metadata (layers) is undetected, cleaning the sstate-cache won't help you13:16
pasherringoh well :/13:17
qschulzpasherring: how do you do the swap of layers?13:18
pasherringqschulz, changing the bblayers.conf13:18
qschulzpasherring: the bblayers from which directory?13:20
qschulzI seem to recall that some vendor provide their own bblayers.conf file with an install script to run before starting a build, hence the question13:20
*** tgamblin_ <tgamblin_!~tgamblin@2607:fea8:c29d:d7c0:fa88:8bc5:c0d2:27cc> has quit IRC (Quit: Leaving)13:20
pasherringqschulz, right, from build/conf/bblayers.conf13:20
*** tgamblin <tgamblin!~tgamblin@2607:fea8:c29d:d7c0:fa88:8bc5:c0d2:27cc> has joined #yocto13:21
*** lorenzo <lorenzo!> has joined #yocto13:28
lorenzoHi! I want to append a recipe that has a do_install_append that install some sample application. I am now compiling without these sample applications, so my objective is to create a .bbappend that changes that do_install_append. Is there a way to stop it from trying to install files that do no exists?13:31
lorenzoHave you ever faced a similar situation?13:32
smurraylorenzo: my usual approach there is to rm the files from ${D} in my own bbappend13:40
lorenzosmurray: sorry i was not clear. the issue is that the original recipe is installing also the samples like this "cp -f bin/example_* ${D}${datadir}/samples/bin/". The issue is that i have modified the compilation flags so that the samples are not created, thus the install task fails because it cannot find them.13:44
lorenzoWhile i was writing, i realized that instead of changing the compile flags and can simply delete them after they have been installed (as you suggested)13:44
lorenzoThank you13:44
Etheryontheoretically if I copy over the files, and all dependencies are met, and I do in do_install what the script for postinstall does,  it should work?13:45
smurraylorenzo: the other hack I could maybe see is to do_install_prepend to touch those files so the rm doesn't fail13:46
*** prabhakarlad <prabhakarlad!> has joined #yocto13:51
*** sakoman <sakoman!> has joined #yocto13:56
lorenzosmurray: I ended up touching a dummy file in the _prepend() and later deleting the whole folder in _append(). THank you very much!13:57
smurraylorenzo: you're welcome, good luck with your project14:00
meegoapologies if this question already pops up often here: anyone knows where i could buy a few CM4? I've already checked a dozen distributors and they're all out of stock14:02
meegoarf, wrong irc channel sorry :p14:03
*** lucaceresoli <lucaceresoli!~lucaceres@> has quit IRC (Remote host closed the connection)14:17
*** lucaceresoli <lucaceresoli!~lucaceres@> has joined #yocto14:18
*** dmoseley <dmoseley!~dmoseley@> has quit IRC (Quit: ZNC 1.8.2 -
*** Minvera <Minvera!~Minvera@user/Minvera> has joined #yocto14:27
*** dmoseley <dmoseley!~dmoseley@> has joined #yocto14:27
*** SSmoogen is now known as Ebeneezer_Smooge14:29
*** kroon <kroon!> has quit IRC (Quit: Leaving)14:29
smurraymeego: I check this now and again:
meegosmurray: that's super helpful, thanks!14:44
*** emrius_the_secon <emrius_the_secon!> has joined #yocto14:52
emrius_the_seconand here I am14:52
emrius_the_seconStrange, when using limechat OSX IRC client I'm getting an error... see #oe channel. However it seems to work from the web client *shrug*14:56
smurraythat error indicates the channel has the flag set that only clients coming in over a SSL/TLS connection can join, I assume you need to change the server connection settings in your client14:59
*** lorenzo <lorenzo!> has quit IRC (Quit: Client closed)14:59
emrius_the_seconsmurray thanks! I tried enabling SSL but the error persists. Hmm... nevermind, it works through the browser client15:01
emrius_the_seconAnyways, the cause that brought me here is the `pip_install_wheel` class which I tried to port back to dunfell. You may have seen this issue already so, I'm really sorry to bother again but I'd love to see this working and I feel that I'm just missing a detail <315:02
*** cb5r <cb5r!~cb5r@user/cb5r> has quit IRC (Quit: cb5r)15:07
*** cb5r <cb5r!~cb5r@user/cb5r> has joined #yocto15:08
moto-timoemrius_the_secon:  you need DEPENDS += “python3-aiohttp-native” if it is a build error15:08
emrius_the_seconSo, the issue I'm having is that the fetcher exists just fine. So, I'm guessing the wheel file has been fetched. I tried to grep the problem and find the wheel but couldn't. I'm wondering if somebody knows where it should be located15:08
emrius_the_seconmoto-timo thanks! I tried that but that didn't get me further.15:09
moto-timoYou will not be able to backport wheels to dunfelll… way to invasive15:09
*** rob_w <rob_w!~rob@2001:a61:605d:cd01:d44e:13ad:7b79:ce8d> has quit IRC (Quit: Leaving)15:09
emrius_the_seconok! Now, that is a clear perspective that I\ve been waiting for :)15:10
moto-timothis is why we are working so hard to get wheels into kirkstone (the next LTS)15:10
emrius_the_seconah ok! I'm really looking forward to that as it will be a great improvement! Thanks for the hard work!!!15:11
emrius_the_seconThe alternative approach I was taking is this
emrius_the_seconsee the comments beneath the answer by rober.berger15:12
emrius_the_seconEspecially this error stack trying to apply the auto-generated recipe (after some minor modifications)15:12
*** alimon <alimon!~alimon@> has quit IRC (Ping timeout: 252 seconds)15:13
emrius_the_seconApparently, during installation `` from the sources is executed which then attempts to import `aiohttp`. At installation time. Which left me a bit confused. Does anybody have a hint how to move forward with this?15:14
emrius_the_seconLet me add the `pytyhon3-aiohttp-native` again to see the exact error stack... wait a sec15:15
emrius_the_seconAh right (sorry about the confusion - there has been quite a bit of back and forth trying to make this work). When adding `DEPENDS += "python3-aiohttp-native"` this dependency can't be found. So, I'm not sure if I can just add a `PROVIDES += "python3-aiohttp-native"` to my python3-aiohttp recipe. But what actually surprises me is that this is a15:21
emrius_the_seconhard installation dependency. I'm really wondering why15:21
moto-timoBBCLASSEXTEND = “native”15:24
*** dmoseley <dmoseley!~dmoseley@> has quit IRC (Quit: ZNC 1.8.2 -
moto-timoNot PROVIDES15:25
emrius_the_seconDang! right!15:25
emrius_the_seconHang on15:25
*** manuel1985 <manuel1985!~manuel198@> has joined #yocto15:26
*** dmoseley <dmoseley!~dmoseley@> has joined #yocto15:27
*** alimon <alimon!~alimon@> has joined #yocto15:28
*** Thorn <Thorn!~Thorn@user/thorn> has quit IRC (Ping timeout: 260 seconds)15:30
*** vladest1 <vladest1!~Thunderbi@2001:1715:9d9c:c530:4f40:1f28:c9e1:8a81> has joined #yocto15:30
*** vladest <vladest!~Thunderbi@2001:1715:9d9c:c530:212c:b736:642c:42b7> has quit IRC (Ping timeout: 240 seconds)15:32
*** vladest1 is now known as vladest15:32
*** Thorn <Thorn!~Thorn@user/thorn> has joined #yocto15:33
emrius_the_seconOk, that seems to slowly let me proceed. I need to go through a couple of python dependencies and add the BBCLASSEXTEND="native". What I'm wondering however is: Why aren't all recipes extending bbclass "native" by default?15:38
moto-timoNo one needed it yet15:38
emrius_the_seconAh ok. That adds to my strange gut feeling wondering why this recipe needs that. Anyways, I'll patch a couple of recipes accordingly to see where this will take me15:39
emrius_the_seconmoto-timo thank you!15:39
moto-timoAnd native and nativesdk can add complexity, so not guaranteed to just work15:39
emrius_the_seconOk I'll give it a first try then I guess15:40
moto-timoUpstream module devs do some very strange things sometimes… this might be one of thos odd corner cases15:42
tlwoernerRP: i've been seeing lots of quilt errors on master lately: "File series fully applied, ends at patch <patch>"15:45
tlwoerneris that the openSUSE issue you've been seeing on the AB?15:45
*** lucaceresoli <lucaceresoli!~lucaceres@> has quit IRC (Remote host closed the connection)15:46
*** lucaceresoli <lucaceresoli!~lucaceres@> has joined #yocto15:46
emrius_the_seconmoto-timo that seems to work! I need to patch about 10 other recipes to provide the native packages but seems to do the job. Thanks!15:49
RPtlwoerner: no :/15:50
dwagenkHi. I'm currently trying to build an ext-sdk and it fails due to some of the layers not being in the same parent directory as COREBASE. The file doing the layer-copying (meta/lib/oe/ uses paths relative to COREBASE and seems to assume all layers are either in TOPDIR or in the same parent directory as COREBASE. Is my layer structure wrong, or is to narrow in what it accepts?15:50
RPnot sure which suse issue you mean :/15:50
RPbut I've not seen that error15:50
tlwoernerRP: okay i'll investigate/bisect. it's intermittent so... you know15:51
RPdwagenk: nobody has generalised that code I suspect, an eSDK needs to combine everything together which is tricky15:51
RPtlwoerner: all too well15:51
tlwoernerRP: also, so far i've only seen it in my jenkins builds, i haven't seen it on the cmdline, but that might just be a coincidence15:51
moto-timoemrius_the_secon: please send patches for master to fix those recipes15:52
moto-timoemrius_the_secon: after that , backport can be considered15:53
*** emrius_the_secon <emrius_the_secon!> has quit IRC (Ping timeout: 256 seconds)15:55
dwagenk@RP Yes, I see that. I've got a patch that would fix my problems and be more general, but at the cost of flattening the directory-structure, e.g. sdk/layers/meta-openembedded/meta-oe -> sdk/layers/meta-oe and sdk/layers/meta-openembedded/meta-networking -> sdk/layers/meta-networking, basically reverting OE-Core rev: 5a59a6997f41e606d088e3e86812de56f72f543b15:55
*** florian <florian!> has quit IRC (Quit: Ex-Chat)15:58
*** lucaceresoli <lucaceresoli!~lucaceres@> has quit IRC (Remote host closed the connection)15:58
*** lucaceresoli <lucaceresoli!~lucaceres@> has joined #yocto15:58
*** Dhruvag2000[m] <Dhruvag2000[m]!~dhruvag2k@2001:470:69fc:105::1:784> has quit IRC (Quit: You have been kicked for being idle)16:00
*** alvaropg[m] <alvaropg[m]!~alvaropgm@2001:470:69fc:105::1:1996> has quit IRC (Quit: You have been kicked for being idle)16:00
*** grembeter[m] <grembeter[m]!~grembeter@2001:470:69fc:105::1:4e8e> has quit IRC (Quit: You have been kicked for being idle)16:00
*** osama3 <osama3!> has quit IRC (Ping timeout: 272 seconds)16:01
*** meego <meego!~meego@2001:41d0:fe7e:c800:ac5a:af08:91fd:3db3> has quit IRC (Quit: Leaving...)16:03
*** tnovotny <tnovotny!> has quit IRC (Quit: Leaving)16:05
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has joined #yocto16:06
*** tre <tre!> has quit IRC (Remote host closed the connection)16:21
RPdwagenk: I worried that change might cause problems :(16:35
*** gsalazar <gsalazar!~gsalazar@> has joined #yocto16:35
*** cb5r <cb5r!~cb5r@user/cb5r> has quit IRC (Quit: cb5r)16:36
*** florian_kc <florian_kc!> has joined #yocto16:37
landgrafEtheryon: it should work but doesn't look like right way16:40
*** florian_kc <florian_kc!> has quit IRC (Quit: Ex-Chat)16:51
*** florian <florian!> has joined #yocto16:51
*** osama3 <osama3!~osama@> has joined #yocto17:08
* Ch^W_ has a hard time not seeing Armbian as yet another example of
*** Etheryon <Etheryon!~textual@> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…)17:22
*** osama3 <osama3!~osama@> has quit IRC (Ping timeout: 256 seconds)17:29
khem1: gettext-0.21-r0 do_configure - 10m6s (pid 1891836)17:29
khemand still going17:29
khem13m10s it took17:33
RPkhem: it is known to be slow17:33
khemyeah luckily not many images need target gettext17:33
khemits probably worth looking into speeding it up sometimes17:34
RPkhem: isn't an easy thing to fix :(17:41
khemyes I guessed so too17:44
*** pgowda_ <pgowda_!> has quit IRC (Quit: Connection closed for inactivity)17:53
*** frieder <frieder!> has quit IRC (Remote host closed the connection)18:00
*** pasherring <pasherring!~pasherrin@2001:8a0:ec55:b200:228d:ee61:fbb7:9bb8> has quit IRC (Remote host closed the connection)18:01
*** pasherring <pasherring!~pasherrin@2001:8a0:ec55:b200:228d:ee61:fbb7:9bb8> has joined #yocto18:02
*** pasherring <pasherring!~pasherrin@2001:8a0:ec55:b200:228d:ee61:fbb7:9bb8> has quit IRC (Remote host closed the connection)18:08
RPCh^W_: did make me laugh at "very slow"18:08
kergothThat's not accurate imo. Getting started isn't slow, it's the learning curve to go from beginner to a higher level of expertise that's slow18:10
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has quit IRC (Quit: jmiehe)18:10
*** florian <florian!> has quit IRC (Ping timeout: 240 seconds)18:12
RPkergoth: agreed, just made me laugh18:16
khemGetting started - very slow18:16
khemI think the real matrix should be time to finish line 🙂18:19
khemgetting into mess is quite quick everyone knows that, key is how easy is it to get out18:19
moto-timoThe long tail to deep understanding is long indeed18:41
*** starblue <starblue!> has joined #yocto18:47
*** florian <florian!> has joined #yocto18:48
*** manuel1985 <manuel1985!~manuel198@> has quit IRC (Quit: Leaving)18:53
*** dmoseley <dmoseley!~dmoseley@> has quit IRC (Quit: ZNC 1.8.2 -
*** dmoseley <dmoseley!~dmoseley@> has joined #yocto19:05
dwagenkRP: I solved the eSDK relative layer path problem and submitted a patch just now. My local eSDK build works fine now.19:08
*** jclsn7 <jclsn7!> has quit IRC (Ping timeout: 272 seconds)19:18
khemdwagenk: thanks for the patch, it helps with some custom distros to generate eSDK19:22
*** jclsn7 <jclsn7!> has joined #yocto19:22
*** amitk <amitk!~amit@> has quit IRC (Ping timeout: 272 seconds)19:26
*** sakoman <sakoman!> has quit IRC (Quit: Leaving.)19:35
kanavin_halstead, is there any movement with the AUH email issue? I've seen some mails from bots on the mailing lists, but AUH still isn't able to get through19:37
halsteadkanavin_: If it's still unresolved now is the time to fix it.19:40
kanavin_halstead, this is the current config19:41
kanavin_# SMTP server19:41
kanavin_# from whom should the mails arrive19:41
kanavin_# who should get the status mail with statistics, at the end19:41
kanavin_# who should be CCd with upgrade emails19:41
halsteadkanavin_: It's fixed for the AB via sendmail. Those smtp settings will work but not for the lists.19:42
halsteadkanavin_: I might be able to fix this without changes on your end. Let me try.19:43
kanavin_halstead, I was wondering if I should change the server to localhost:25 there19:43
halsteadkanavin_: not every worker is listening on localhost19:45
*** sakoman <sakoman!> has joined #yocto19:48
RPdwagenk: thanks. I think we may need to get some better tests for this...20:08
frayDoes anyone know if a 'git-lfs' (native or nativesdk) recipe exists?  I didn't find one, but I may have been looking in the wrong place20:18
fray(I have a repository that uses git-lfs, and it doesn't seem to work via the buildtools..)20:19
sgwzeddii: how much do you know about depmod?  Changing the debug generation for kernel modules seems to have triggered an issue when they are installed in an image and depmod finds both <module>.ko and .debug/<module>.ko, which causes depmod to fail.  A workaround would be for depmod to ignore .debug directories, thoughts?20:19
fraysgw, or move the debug modules into a different path20:20
sgwfray, yeah that would be another possiblity with having to change depmod, have a rootfs-postprocess that runs to move the /lib/modules/.../.debug/ files someplace20:21
sgwwithout having to change kmod, is what I meant.20:21
frayI was going to say, fix the package function that splits the binaries.. and move the split modules somewhere else..20:22
fraythere may already be a config switch for the path..20:22
frayor at least a limited set of places that need modification20:23
sgwfray, that's some of the code that I changed for the SBOM to enable, but I don't think there's a switch to change the location.20:24
fraysplit happens to:20:28
fray    dest = dv["libdir"] + os.path.dirname(src) + dv["dir"] + "/" + os.path.basename(src) + dv["append"]20:28
frayso dir and append can be modified20:28
fraydefault values are set here20:28
frayI don't see anything specific to kernel mdoules in that list, but it would certainly be easy to add something there and in the function "splitdebugfile" function for kernel modules20:29
fraywe used to have some stuff there for special cases already20:29
*** tgamblin <tgamblin!~tgamblin@2607:fea8:c29d:d7c0:fa88:8bc5:c0d2:27cc> has quit IRC (Read error: Connection reset by peer)20:29
fray(i.e. there is a splitstaticdebuginfo already.. would be reasonable to do a kernel module if something special was needed)20:30
sgwYeah, looking at that again, it might work20:30
*** tgamblin <tgamblin!~tgamblin@2607:fea8:c29d:d7c0::3a92> has joined #yocto20:30
sgwWe used to have kernel specific to skip the split/strip, which I removed for SBOM manglement20:30
*** tgamblin <tgamblin!~tgamblin@2607:fea8:c29d:d7c0::3a92> has quit IRC (Remote host closed the connection)20:32
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has quit IRC (Ping timeout: 240 seconds)20:41
kanavin_halstead, let me know when I can test it then20:48
zeddiisgw: w0t fray said20:49
halsteadkanavin_: Alright.20:53
halsteadkanavin_: Not yet. Its a bit more difficult then I expected. I might switch to localhost and install MTAs on all the workers. I'll let you know.20:56
RPhalstead: if it helps we could limit the workers we run auh on20:57
RPfray: there was something horrible about git-lfs which meant a recipe wasn't easy. I can't remember what now though20:58
halsteadRP: That would make it easier. I'll grab a list.20:58
fraygit-lfs requires go20:59
halsteadRP: For now what if we limit to AUH the Alma workers?20:59
kanavin_halstead, I don't mind that21:03
RPhalstead: I'll defer to kanavin_21:04
RPfray: that would be it :)21:04
frayya, after I asked I found the go thing.. I suspect 'nativesdk' go is a complete mess [if it even exists]21:06
RPfray: last time this came up we didn't have go in core21:07
frayYa, as far as I'm concerned it's not there either.. I REALLY have no desire to try to make this work right now21:09
*** tgamblin <tgamblin!~tgamblin@2607:fea8:c29d:d7c0::3a92> has joined #yocto21:12
*** mvlad <mvlad!~mvlad@2a02:2f08:4b12:b100:24d7:51ff:fed6:906d> has quit IRC (Remote host closed the connection)21:17
Ch^W_RP: I am always amused by that impression...21:23
halsteadkanavin_: If you change settings to point at localhost:25 and only run on the Alma workers that would be a good test.21:32
kanavin_halstead, let me first try a manual test, then I will submit a patch for the auh config21:32
* halstead has to run out for a bit.21:32
*** Tokamak <Tokamak!~Tokamak@> has quit IRC (Ping timeout: 240 seconds)21:32
*** vd <vd!> has quit IRC (Quit: WeeChat 3.4)21:33
*** Tokamak <Tokamak!~Tokamak@> has joined #yocto21:34
kanavin_halstead, sadly the email didnt show up on the oe-core list21:38
kanavin_>>> smtp = SMTP('localhost', 25)21:39
kanavin_>>> smtp.sendmail('','','test email from AUH')21:39
kanavin_>>> smtp.close()21:39
kanavin_the above works21:39
kanavin_>>> smtp = SMTP('localhost', 25)21:39
kanavin_>>> smtp.sendmail('','','test email from AUH')21:39
kanavin_>>> smtp.close()21:39
kanavin_and this does not21:39
kanavin_(that's python's prompt)21:39
kanavin_I'm on alma8-ty-121:39
kanavin_let me also try to send a 'well formed' email21:42
halsteadkanavin_: okay. If that fails I'll check into it after my appointment. Anything wrong with the from address will block it21:43
halsteadAnd I might need to allow that address again on the mailing list. Afk for an hour or so though.21:44
*** vd <vd!> has joined #yocto21:47
kanavin_halstead, looks like it went through \0/21:48
kanavin_halstead, let me know if auh config should be changed to use localhost:25 then21:50
halsteadI think that's the best way for now.22:04
kanavin_RP: I'm slightly confused with - none of these workers exist anymore. How is e.g. selftest-fedora then assigned to fedora workers?22:09
kanavin_RP: trying to figure out if pinning AUH to alma from this file (further down) would actually work22:09
*** gsalazar <gsalazar!~gsalazar@> has quit IRC (Ping timeout: 256 seconds)22:11
*** lucaceresoli <lucaceresoli!~lucaceres@> has quit IRC (Ping timeout: 256 seconds)22:29
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has joined #yocto22:38
RPkanavin_: we leave the old distros as a record of what we once did with older releases22:40
RPkanavin_: workers_wine is a good example of what you need22:41
RPkanavin_: oh, there may be a more up to date config on the controller :/22:41
*** vd <vd!> has quit IRC (Quit: WeeChat 3.4)22:43
*** vd <vd!> has joined #yocto22:43
RPkanavin_: pushed. There is already a workers_auh22:45
*** Minvera <Minvera!~Minvera@user/Minvera> has quit IRC (Remote host closed the connection)22:52
* RP feels happier we have a nearly green build again23:00
*** Schlumpf <Schlumpf!~Schlumpf@> has quit IRC (Quit: Client closed)23:00
*** dmoseley <dmoseley!~dmoseley@> has quit IRC (Quit: ZNC 1.8.2 -
*** dmoseley <dmoseley!~dmoseley@> has joined #yocto23:22
*** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV)23:26
*** leon-anavi <leon-anavi!~Leon@> has quit IRC (Remote host closed the connection)23:38
*** florian <florian!> has quit IRC (Ping timeout: 256 seconds)23:47
*** prabhakarlad <prabhakarlad!> has quit IRC (Quit: Client closed)23:47

Generated by 2.17.2 by Marius Gedminas - find it at!