Wednesday, 2020-08-19

*** kiwi_29 <kiwi_29!> has quit IRC00:08
*** kiwi_29 <kiwi_29!> has joined #yocto00:17
*** kiwi_29 <kiwi_29!> has quit IRC00:49
*** kiwi_29 <kiwi_29!> has joined #yocto00:49
*** kiwi_29 <kiwi_29!> has quit IRC00:55
*** kiwi_29 <kiwi_29!> has joined #yocto01:01
*** jellycode <jellycode!~jellycode@2601:408:8100:8270:35cf:602:80f5:dc> has quit IRC01:04
*** mattsm <mattsm!> has quit IRC01:10
*** kiwi_29 <kiwi_29!> has quit IRC01:16
*** kiwi_29 <kiwi_29!> has joined #yocto01:20
*** kaspter <kaspter!~Instantbi@> has joined #yocto01:23
*** camus1 <camus1!~Instantbi@> has joined #yocto01:48
*** kaspter <kaspter!~Instantbi@> has quit IRC01:49
*** camus1 is now known as kaspter01:49
*** kiwi_29 <kiwi_29!> has quit IRC01:51
*** kiwi_29 <kiwi_29!> has joined #yocto01:51
*** mattsm <mattsm!> has joined #yocto01:56
*** kiwi_29 <kiwi_29!> has quit IRC01:57
*** stbenz61 <stbenz61!> has joined #yocto02:02
*** stacktrust <stacktrust!> has quit IRC02:03
*** yocton_ <yocton_!~quassel@> has joined #yocto02:04
*** stacktrust <stacktrust!> has joined #yocto02:04
*** sstabellini <sstabellini!sstabellin@gateway/shell/xshellz/x-gnjzfccnzadguqmt> has quit IRC02:04
*** weltling <weltling!> has quit IRC02:04
*** otavio_ <otavio_!> has quit IRC02:04
*** weltling <weltling!> has joined #yocto02:04
*** sstabellini_ <sstabellini_!sstabellin@gateway/shell/xshellz/x-ztcavbaaemlmsyca> has joined #yocto02:04
*** otavio_ <otavio_!> has joined #yocto02:04
*** dl9pf_home <dl9pf_home!~quassel@opensuse/member/dl9pf> has quit IRC02:04
*** stbenz6 <stbenz6!> has quit IRC02:04
*** yocton <yocton!~quassel@> has quit IRC02:04
*** stbenz61 is now known as stbenz602:04
*** dl9pf_home <dl9pf_home!> has joined #yocto02:04
*** dl9pf_home <dl9pf_home!~quassel@opensuse/member/dl9pf> has joined #yocto02:04
*** [Sno] <[Sno]!> has joined #yocto02:05
*** sno <sno!> has quit IRC02:05
*** geheimnis` <geheimnis`!~geheimnis@> has quit IRC02:05
*** fray <fray!> has quit IRC02:05
*** mckoan|away <mckoan|away!~marco@unaffiliated/mckoan> has quit IRC02:05
*** kiwi_29 <kiwi_29!> has joined #yocto02:05
*** meow` <meow`!~sbourdeli@> has quit IRC02:06
*** dirbaio <dirbaio!> has quit IRC02:06
*** mckoan|away <mckoan|away!> has joined #yocto02:07
*** geheimnis` <geheimnis`!~geheimnis@> has joined #yocto02:07
*** grumble <grumble!~Thunderbi@freenode/staff/grumble> has quit IRC02:11
*** grumble <grumble!~Thunderbi@freenode/staff/grumble> has joined #yocto02:12
*** kiwi_29 <kiwi_29!> has quit IRC02:17
*** fray <fray!> has joined #yocto02:18
*** kiwi_29 <kiwi_29!> has joined #yocto02:18
*** kiwi_29 <kiwi_29!> has quit IRC02:19
*** hpsy1 <hpsy1!~hpsy@> has joined #yocto02:19
*** dirbaio <dirbaio!> has joined #yocto02:19
*** hpsy <hpsy!~hpsy@> has quit IRC02:20
*** kiwi_29 <kiwi_29!> has joined #yocto02:22
*** meow` <meow`!~sbourdeli@> has joined #yocto02:25
*** kiwi_29 <kiwi_29!> has quit IRC02:52
*** kiwi_29 <kiwi_29!> has joined #yocto02:52
*** kiwi_29 <kiwi_29!> has quit IRC03:09
*** sakoman <sakoman!> has quit IRC03:09
*** codusnocturnus <codusnocturnus!> has joined #yocto03:18
*** adelcast <adelcast!~adelcast@2605:6000:101c:3b5:c255:6326:5d60:1a29> has quit IRC03:44
*** georgem_home <georgem_home!uid210681@gateway/web/> has quit IRC05:03
*** zandrey <zandrey!> has quit IRC05:19
*** jobroe <jobroe!> has joined #yocto05:29
*** agust <agust!> has joined #yocto05:43
*** AndersD <AndersD!> has joined #yocto05:43
*** gtristan <gtristan!~tristanva@> has quit IRC05:48
*** zandrey <zandrey!~zandrey@> has joined #yocto05:58
*** LetoThe2nd <LetoThe2nd!uid453638@gateway/web/> has joined #yocto06:05
*** Moh3N <Moh3N!2ed17334@> has joined #yocto06:17
Moh3Nhello to all06:18
Moh3NI want to know what is my kernel source that yocto download it and working on it06:18
*** paulg <paulg!> has quit IRC06:18
Moh3Nin my kernel recipe I have : git://;branche=sdk-v2.0.x06:19
Moh3NI want to download this version of kernel source and upload it to my local git repo and then set my local adress to this recipe!! how I can do it ?06:20
*** beneth <beneth!> has joined #yocto06:24
Moh3Nthank you. I dont know this address : git://;branche=sdk-v2.0.x   I want to download it but I cant06:25
LetoThe2ndgit clone just as always.06:25
*** codusnocturnus <codusnocturnus!> has quit IRC06:26
LetoThe2ndspecifically, git clone git://
LetoThe2ndbut if that already is a show stopper, i strongly suggest starting out with some very *introductory* material.06:26
*** rcoote <rcoote!> has joined #yocto06:27
Moh3Nit says : unable to look up (port 9418) (No such host is known. )06:27
Moh3Nbut yocto used this address06:27
Moh3Nthank you06:28
LetoThe2ndyocto used this address?06:28
Moh3Nthis address is in my kernel recipe06:29
LetoThe2ndif i had to guess then, either the server is down or the recipe is massively outdated.06:29
Moh3Nmeybe, because there are many files in download directory and yocto use these files but I dont know which one of these files related to kernel!!!06:31
LetoThe2ndusually its called just like the src_uri06:32
Moh3Nwe are 3 teams that we want to work on one version on a source, we change the source code and I want to yocto use this source of kernel that we change it every day06:33
Moh3N(on = of a source) sorry for poor English06:34
*** gsalazar <gsalazar!5e3ce511@gateway/web/cgi-irc/> has joined #yocto06:34
*** fbre <fbre!91fdde45@> has joined #yocto06:36
LetoThe2ndthen put it onto your git server, make the recipe use it... all the usual techniques apply.06:37
Moh3NIm trying, thanks a lot06:49
*** T_UNIX <T_UNIX!uid218288@gateway/web/> has joined #yocto06:49
T_UNIXwhy is `/var/tmp/` specified using tmpfiles notion in , yet as a "file" (symlink) packaged in instead of a likewise line in06:50
T_UNIX ?06:50
*** frsc <frsc!> has joined #yocto06:51
*** jrdn <jrdn!> has quit IRC06:54
*** fl0v0 <fl0v0!~fvo@> has joined #yocto06:55
*** kaspter <kaspter!~Instantbi@> has quit IRC06:56
*** camus1 <camus1!~Instantbi@> has joined #yocto06:56
*** camus1 is now known as kaspter06:59
*** yacar_ <yacar_!> has joined #yocto07:07
*** goliath <goliath!> has joined #yocto07:07
*** gtristan <gtristan!~tristanva@> has joined #yocto07:36
*** mckoan|away is now known as mckoan07:39
mckoangood morning07:39
*** mckoan <mckoan!> has quit IRC07:40
*** mckoan <mckoan!~marco@unaffiliated/mckoan> has joined #yocto07:40
erbogood morning07:41
*** hpsy1 <hpsy1!~hpsy@> has quit IRC07:43
*** hpsy <hpsy!~hpsy@> has joined #yocto07:43
*** goliath <goliath!> has quit IRC07:45
*** chris_ber <chris_ber!~quassel@> has joined #yocto07:52
*** jmiehe <jmiehe!> has joined #yocto08:00
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto08:03
*** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has joined #yocto08:05
*** AndersD <AndersD!> has quit IRC08:08
*** osullivan99 <osullivan99!> has joined #yocto08:14
*** chris_ber <chris_ber!~quassel@> has quit IRC08:18
*** chris_ber <chris_ber!~quassel@> has joined #yocto08:20
*** ykrons_ is now known as ykrons08:20
*** [Sno] <[Sno]!> has quit IRC08:20
*** Moh3N <Moh3N!2ed17334@> has quit IRC08:22
ykronsI'm facing a strange issue. I have a build that randomly remains stuck on a "random package". The last log I have is "NOTE : Running noexec task xxx ..xxxx .. I understood the build task is an anchor for other task but has no job to do that is why it is mark as noexec. Is there any reason why such a task can be stuck or could it be the next task that is stuck ? Thanks for your help08:24
*** goliath <goliath!~goliath@> has joined #yocto08:26
*** hipr_c <hipr_c!> has quit IRC08:31
fbremaybe the build problems are because of a full hard disk or such things?08:32
ykronsfbre, 300GB HDD free and 18GB of RAM free when stuck ... so I don't think and usually yocto complains about lack of free space and stop tasks. Here it just remain silent.08:35
fbreI would try another machine and see if it still happens there08:37
RPykrons: try looking at the output from ps as that should have a partial taskname in the process name08:43
RPykrons: its almost certainly not the noexec tasks but something which started before that and hasn;t finished08:43
ykronsRP, fbre : I will try another machine and check running process when stuck08:45
*** [Sno] <[Sno]!~sno@> has joined #yocto08:47
*** ant__ <ant__!> has joined #yocto09:00
*** ant__ <ant__!> has quit IRC09:04
*** dexterlb <dexterlb!> has quit IRC09:05
fbreHi! I use "zeus". I added INITRAMFS_IMAGE = "core-image-tiny-initramfs" and INITRAMFS_IMAGE_BUNDLE = "1" to my local.conf. Then I managed to bitbake a .wic file which I wrote to SD card with dd. I boot into u-boot and setenv root=/dev/ram0 rootwait rw  there. Next I call    boot   . The Linux kernel starts and hangs on "Waiting for root device09:12
fbre/dev/ram0...". What could be wrong?09:12
*** mckoan is now known as mckoan|away09:14
fbreWithout changing root in u-boot everything is fine and yocto boots well and I can login on its prompt09:14
RPfbre: how do you know the initramfs isn't being booted and then switching to the main rootfs?09:19
RPfbre: sadly its been many years since I worked on initramfs so I don't remember the details09:20
*** mi99 <mi99!~asd@> has quit IRC09:23
*** emrius <emrius!> has joined #yocto09:27
emriusHey everyone, I see the filesize of /var/volatile/log/wtmp is increasing over time. AFAIK this file logs the login history for the `last` command. Now, I'm having a little trouble with a serial-getty connection (not sure where that stems from as I'm not using serial connectino.. anyway..). So this is the root for the `wtmp` filesize to increase09:32
emriuspermanently and significantly. I'm not needing any history for `last` in production. So my question is: how can I get rid or clear the file `wtmp` cleanly? Write a systemd that erases that file regularly would probably work but seems odd to me ...09:32
emriusAnd my second question is regarding the serial getty problem. I'm repeatedly seeing a serial connection restart and I'm wondering how to get rid of that.`serial-getty@ttyS0.service: Service has no hold-off time (RestartSec=0), scheduling restart.`09:33
RPemrius: wouldn't it be better to disable the problematic serial getty?09:34
RPIf you do that wtmp may be fine?09:34
*** xtron <xtron!~xtron@> has joined #yocto09:34
RPemrius: the SERIAL_CONSOLES variable comes to mind09:35
emriusYes. that would cure the root of the problem. Still I'm wondering if the device might run into trouble if e.g. someone repeatedly tries to login, filling up wtmp.09:35
emrius(side note: The device runs a pretty memory hungry application. Thus I want to make sure memory is cleanly handled)09:35
RPemrius: I'm sure wtmp can likely be disabled but you'd probably have to look at the systemd docs09:36
emriusRP Thanks! I had a look into that variable already. Can I simply clear that variable or will that have negative side effects?09:36
RPemrius: I think clearing it should be fine, you don't want a serial console...09:36
fbreRP: I added an echo output to in function mount_and_root(). If it was called I should see that echo message.09:37
emrius@RP ok! thanks! Then I'll go down that road09:37
fbreRP: I understand it as I have to set root=/dev/ram0 to let the kernel use the initramfs which I bundled with INITRAMFS_IMAGE_BUNDLE = "1" in local.conf09:38
RPfbre: Looking at the code, I'd go and check your kernel does have the initramfs included in it09:42
*** dexterlb <dexterlb!~dexterlb@2a01:9e40:2:2::2> has joined #yocto09:42
RPfbre: do_bundle_initramfs looks to call the kernel compile again with the initramfs specified. When you turn on the initramfs, does your kernel size increase?09:43
fbreRP: I just followed   and expect the initramfs to be bundled. The .wic file is slightly bigger than without that bundling (about 80KB).09:45
RPfbre: how big is the core-image-initramfs file?09:45
RPfbre: You're using an fsl kernel if I remember correctly and I'd worry they're doing something incompatible with the standard initramfs setup09:46
fbreRP: I have several files, I think you mean this one (?): core-image-tiny-initramfs-imx8mmevk-[timestamp].rootfs.cpio.gz = 11,8MB09:48
*** kaspter <kaspter!~Instantbi@> has quit IRC09:49
*** kaspter <kaspter!~Instantbi@> has joined #yocto09:49
fbreRP: The file I flash with dd is: core-image-minimal-imx8mmevk-[timestamp].rootfs.wic which I extract from core-image-minimal-imx8mmevk-[timestamp].rootfs.wic.bz209:49
RPfbre: right, so the kernel increasing 80kb for an 11MB initramfs doesn't add up09:50
fbreRP: Am I right that core-image-tiny-initramfs-...rootfs.cpio.gz is added up to that core-image-minimal......rootfs.wic.bz2?09:52
fbre... I mean actually usually09:53
RPfbre: no. Look at the do_bundle_initramfs task. It adds the initramfs image to the kernel binary09:53
RPfbre: I don't know if your layout puts the kernel into that wic image or not09:54
*** florian__ <florian__!~florian_k@Maemo/community/contributor/florian> has joined #yocto09:54
*** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has quit IRC09:57
fbreRP: The .log file says "Running task .... do_bundle_initramfs  ... do_deploy ... do_image_wic ...  do_image_complete ... do_populate_lic_deploy .... " all with "Started" and "Succeeded"10:00
*** [Sno] <[Sno]!~sno@> has quit IRC10:25
*** xtron <xtron!~xtron@> has quit IRC10:35
*** gourve_l <gourve_l!> has quit IRC10:36
*** xtron <xtron!> has joined #yocto10:38
*** xtron <xtron!> has quit IRC10:44
*** dexterlb <dexterlb!~dexterlb@2a01:9e40:2:2::2> has quit IRC10:52
*** dexterlb <dexterlb!~dexterlb@2a01:9e40:2:2::2> has joined #yocto10:53
*** [Sno] <[Sno]!> has joined #yocto10:54
RPfbre: right, but does the fsl kernel ignore that somehow?10:55
*** NiksDev <NiksDev!~NiksDev@> has quit IRC10:57
*** xtron <xtron!~xtron@> has joined #yocto10:57
*** NiksDev <NiksDev!~NiksDev@> has joined #yocto10:58
fbreRP: not sure what you mean with "fsl kernel ignore that". Well, I think, you're right and my situation currently is: The 11MB initramfs image is not bundled since the .wic file keeps the same size11:03
*** AndersD <AndersD!> has joined #yocto11:04
fbreRP: The question is how I should find out where it fails. I'm stumped11:04
RPfbre: The fsl layer is notorious for doing interesting things and causing workflows like this to break :(11:06
JaMais devtool expanding SRC_URI variable differently from bitbake itself? I have SRC_URI which uses variable and devtool modify works fine, but devtool finish complains about malformed URL11:09
JaMae.g. ROS_BRANCH ?= "branch=release/melodic/swri_nodelet"11:09
JaMaSRC_URI = "git://;${ROS_BRANCH};protocol=https"11:09
JaMaends with:     raise MalformedUrl(url, "The URL: '%s' is invalid: parameter %s does not specify a value (missing '=')" % (url, s))11:10
JaMabb.fetch2.MalformedUrl: The URL: 'git://;${ROS_BRANCH};protocol=https' is invalid: parameter ${ROS_BRANCH} does not specify a value (missing '=')11:10
RPJaMa: I'd suspect a bug somewhere :/11:10
RP(in devtool)11:11
JaMaok, will check11:12
emrius@RP I cleared the SERIAL_CONSOLES variable. Unfortunately, I can't seem to connect via ssh anymore to my device. Would that be expected?11:15
*** mrpelotazo <mrpelotazo!> has quit IRC11:19
JaMaRP: patch sent11:20
*** sstiller <sstiller!> has joined #yocto11:25
*** khem <khem!~khem@unaffiliated/khem> has quit IRC11:26
RPemrius: no, is it actually booting?11:29
fbrezandrey: Hi! Can you imagine why my  core-image-tiny-initramfs-...rootfs.cpio.gz is not added up to that core-image-minimal......rootfs.wic.bz2? The file size of the .wic file does not increase by the 11MB the initramfs is.11:29
fbre...this happens with NXP's "zeus"11:30
*** khem <khem!~khem@unaffiliated/khem> has joined #yocto11:32
*** berton <berton!~berton@> has joined #yocto11:36
emrius@RP yes. It's also asking for a password, but it's not letting me in. However, I realized that after removing the SERIAL_CONSOLES my image increased by 5 MB which I find very suspicious. I assume this change triggered a part to be recompiled which had greater impact. Hmpf... sometimes yocto is still a mystery to me...11:38
RPJaMa: does that write expanded data back to the recipe?11:38
RPemrius: that does sound like something else changed as well11:39
emrius@RP yeah I guess so. Definately not in my configuration. Keeping a close eye on that with git. But I have the feeling that dependency resolution/sstate/other is not as deterministic or fail safe as I wish it was. Or CTRL-C related stale parts... I don't know... Anyways, thanks for your help!11:41
*** rcoote <rcoote!> has quit IRC11:52
*** ak77 <ak77!~akrpic77@> has joined #yocto11:54
*** xtron <xtron!~xtron@> has quit IRC11:55
RPemrius: people love to blame sstate but the reality is we've seen very very few issues in that area, at least with oe-core11:59
*** TobSnyder <TobSnyder!> has joined #yocto11:59
RPemrius: if people do have a problem with sstate I ask they report it so we can fix it...12:00
emrius@RP yeah you are probably right. However, it's a little surprising changing the SERIAL_CONSOLE, bitbake and see 5 MB image increase and not being able to login anymore. Also reverting the change doesn't enable login anymore.12:01
emriusbut I can imaging CTRL-C can be risky? At least I think I remember reading this somewhere12:02
*** georgem_home <georgem_home!uid210681@gateway/web/> has joined #yocto12:03
*** rcoote <rcoote!> has joined #yocto12:06
*** TobSnyder <TobSnyder!> has quit IRC12:08
osullivan99hello i'm trying to port u-boot for board TQMa335x12:09
osullivan99i followed TI's guide on
osullivan99when I run bitbake core-image-minimal it doesn't rebuild anything, so where do I have to configure the make target for u-boot?12:12
*** yacar_ <yacar_!> has quit IRC12:14
*** kaspter <kaspter!~Instantbi@> has quit IRC12:20
*** berton <berton!~berton@> has quit IRC12:20
*** kaspter <kaspter!~Instantbi@> has joined #yocto12:21
*** berton <berton!~berton@> has joined #yocto12:21
JaMaRP: not from this _guess_recipe_update_mode function (it returns only 'patch' or 'srcrev')12:24
*** likewise <likewise!> has joined #yocto12:24
*** berton <berton!~berton@> has quit IRC12:26
RPJaMa: ah, that makes sense. I wasn't looking at the full context of the function12:30
RPJaMa: I wonder why its unexpanded12:30
likewisetoolchain-scripts.bbclass does TARGET_CC_ARCH_append-libc-musl = " -mmusl", but the expanded ${TARGET_CC_ARCH} in the shared toolchain script does not contain " -mmusl". Where would BitBake expand the _append?12:31
RPlikewise: does it do something like disabling OVERRIDES?12:32
likewiseOVERRIDES contains libc-musl12:32
RPlikewise: when its writing the toolchain script?12:33
likewiseRP: Apparently not, the " -mmusl" does not end up there.12:33
RPlikewise: try writing out OVERRIDES at the same time its writing out that variable?12:33
RPlikewise: I did see your email about it but I don't really have anything useful to suggest other than debugging it :/12:34
likewiseRP: Good suggestion. Will try.12:34
*** rcoote <rcoote!> has quit IRC12:36
likewiseRP: My Python debugging skills are lacking. That being said, can we use a Python debugger easily to debug our Python/Shell mix of classes and recipes?12:43
RPlikewise: using a debugging with OE is hard :(12:47
RPer, a debugger12:47
ak77can't get PREMIRRORS to work... i want to change git's protocol and username/password.. any example of that?12:53
ak77(from ssh to https, and user name from git@ to u:p@)12:54
*** AndersD <AndersD!> has quit IRC12:57
*** gsalazar <gsalazar!5e3ce511@gateway/web/cgi-irc/> has quit IRC12:59
likewiseRP: Thanks. The OVERRIDES seems indeed for the canadian cross tool build, no longer the target.13:04
likewiselinux-musl is still there, but the C library is libc-glibc13:05
likewise(So now I wonder if linux-musl is correct for the canadian cross toolchain as well....?)13:05
zandreyfbre: sorry for a lag - afternoon is busy... i have to check this setup myself, but i do not see anything in fsl community bsp (*not* NXP) that prevents the initramdisk to be bundled with kernel. the only thing i can think of so far it: which kernel image file is effectively packed in wic?13:05
zandreyis it the bundled one?13:06
zandreyfbre: have you maybe also tried to build FIT image and pack initramdisk into it instead?13:07
*** TundraMan <TundraMan!> has joined #yocto13:07
*** tgamblin_ is now known as tgamblin13:08
*** marka <marka!> has quit IRC13:08
fbrezandrey: Thanx for your reply! How can I find out which kernel image file is packed in wic? I don't also know what you're talking about with the other question since I don't know what a FIT image is at all13:11
*** kiwi_29 <kiwi_29!> has joined #yocto13:11
*** kiwi_29 <kiwi_29!> has quit IRC13:16
fbrezandrey: I'll go offline now, but will read the chat logs afterwards. So if you know an answer, don't hesitate to write here, I'll read it. See you all for today 8) (y)13:22
*** fbre <fbre!91fdde45@> has quit IRC13:22
*** gsalazar <gsalazar!5e3ce511@gateway/web/cgi-irc/> has joined #yocto13:22
*** adelcast <adelcast!~adelcast@2605:6000:101c:3b5:c255:6326:5d60:1a29> has joined #yocto13:24
*** xtron <xtron!~xtron@> has joined #yocto13:31
*** maze-BUG <maze-BUG!~Thunderbi@> has joined #yocto13:32
ak77hmm.. how can I disable failed fetch to try to download from ?13:36
*** xtron <xtron!~xtron@> has quit IRC13:37
*** xtron <xtron!~xtron@> has joined #yocto13:37
maze-BUGHi, ALL. I got a problem : bitbake doesn't append sysroot to CPPFLAGS13:38
maze-BUGI use CmakeList to build my module. The error:13:38
maze-BUG           fatal error: sys/mman.h: No such file or directory13:38
maze-BUG          6 | #include <sys/mman.h>13:38
maze-BUGwhich should in sysroot/usr/include13:38
maze-BUGhow to debug this?13:38
*** nayfe <nayfe!uid259604@gateway/web/> has joined #yocto13:39
kergothmaze-BUG: sysroot is passed in CC, so it doesn't need to be in the flags, generally, unless cmake.bbclass handles it differently.13:42
ak77maze-BUG, hmm.. it should. you use cmake class ? (inherit cmake)13:42
likewiseRP: TARGET_CC_ARCH_append-libc-musl = " -mmusl" to  TARGET_CC_ARCH_append-linux-musl = " -mmusl" will at least make it correct for SDK, as well as SDK/CMake13:42
maze-BUGak77: yes ,  "" inherit autotools qcommon qlicense qprebuilt cmake13:43
maze-BUGI my generate file can find this path:13:45
maze-BUGrule C_EXECUTABLE_LINKER__rotatetest13:45
maze-BUG 36   command =  ...  --sysroot=/local/mnt/workspace/
LetoThe2ndautotools AND cmake sounds... weird/wrong13:45
maze-BUGLetoThe2nd: Try close autotools,  still build error.13:47
RPlikewise: do you mean _append_libc-musl and _append_linux-musl ?13:47
RPI don't understand why the libc-musl append wouldn't work :/13:48
maze-BUGkergoth: How to check the cmake.bbclass. I don't think anyone changed this file.13:50
*** matthewzmd <matthewzmd!> has joined #yocto13:50
maze-BUGMy cmake.bbclass with this gerrit:13:51
*** paulg <paulg!> has joined #yocto13:52
*** chrysh <chrysh!> has quit IRC13:52
splatchI've ran into a trouble with my yocto build and usb device.. basically it doesn't get discovered. I see difference in my desktop and yocto handling of usb thing but I don't know where to start. What I have missed? Device is uart converter and uses STM32F0 microcontroller.13:56
splatchI probably miss some module or something, but how to find which one?13:56
fraystart with dmesg.. on the insertion of the USB device you should see a USB event logged.. if you do not, then you are likely missing a kernel config..13:56
frayif you do see an insertion event, but nothing happens.. then look at udev or systemd-udev.. it's probably missing a rule13:56
splatchI'm on earlier one - I see no event13:57
frayyou'll have to try to find the setting in the kernel and enble it13:57
*** jrdn <jrdn!> has joined #yocto13:58
LetoThe2ndit's a fray!!!13:59
*** sakoman <sakoman!> has joined #yocto14:00
*** Sasha62 <Sasha62!a5e1d0b2@> has joined #yocto14:01
fraytrying to be more present.. been really busy14:01
*** ericch <ericch!> has joined #yocto14:03
LetoThe2ndhey, i'm beeing cheerful. no more :)14:04
maze-BUGLooks like the gcc didn't fetch the include file in $sysroot/usr/include14:05
maze-BUGwhich chat should I join to ask this problem~?14:05
*** jobroe <jobroe!> has quit IRC14:12
*** like2wise <like2wise!> has joined #yocto14:14
*** likewise <likewise!> has quit IRC14:17
*** dexterlb <dexterlb!~dexterlb@2a01:9e40:2:2::2> has quit IRC14:17
*** hpsy <hpsy!~hpsy@> has quit IRC14:25
*** thaytan <thaytan!> has quit IRC14:25
*** hpsy <hpsy!~hpsy@> has joined #yocto14:26
*** sstiller <sstiller!> has quit IRC14:27
*** rcoote <rcoote!> has joined #yocto14:27
*** goliath <goliath!~goliath@> has quit IRC14:29
*** emrius <emrius!> has quit IRC14:30
*** dexterlb <dexterlb!~dexterlb@2a01:9e40:2:2::2> has joined #yocto14:32
chris_beri am using the imx8mmevk board to develop. Every time i baked a new image i have to turn off the boad, switching dip-switch, turn it on again, flash, turn off, switching dip-switch and finaly turn it on again. This seems to be unecessary. Is it possible to get rid of this? Maybe configure uboot to load from network? any ideas?14:42
LetoThe2ndwhy just "maybe"?14:44
splatchfray: clearly I miss usb_serial module, yet I am curious is there a way to determine that in reliable way.. ie by verbose logging at kernel level in properly functioning system?14:44
*** vicale <vicale!> has quit IRC14:44
*** kaspter <kaspter!~Instantbi@> has quit IRC14:45
*** likewiser <likewiser!> has joined #yocto14:46
chris_ber@LetoThe2nd: wasn't sure if this the proper way. If so i have to write a bbapend file to reconfigure uboot?14:46
LetoThe2ndchris_ber: if your u-boot already has all the necessary pieces, then it might also be enough to modify its environment manually to get started, and pour that into a proper u-boot configuration later.14:47
LetoThe2ndchris_ber: but please note, usually this takes ip/dhcp/tftp support in u-boot, as well as nfsroot/ipautoconfig support in the kernel, so this might require some action.14:48
*** like2wise <like2wise!> has quit IRC14:48
*** champagneg <champagneg!> has joined #yocto14:49
chris_berok, another solution to just copy a image via scp isn't a good idead or even possible?14:49
LetoThe2ndit depends(TM)14:50
LetoThe2ndbut AFAIK u-boot doesn't do ssh/scp :)14:50
chris_berby this i meant hard copy the image when the system is running14:51
LetoThe2ndit depends(TM)14:51
*** PaowZ <PaowZ!~vince@2a01:e35:2e3e:4ac0:718b:1494:d962:ec52> has quit IRC14:52
*** peterp <peterp!> has joined #yocto14:52
LetoThe2ndhow the image is actually used, like: is it an initrd or fitimage and you are running completely out of ram? then you can do that. for a live rootfs, overwriting is a bad idea. but then, how often is that process really necessary? once the system is a bit stabilized, you can usually use devtool to deploy/test your application during development.14:52
*** adelcast <adelcast!~adelcast@2605:6000:101c:3b5:c255:6326:5d60:1a29> has quit IRC14:53
chris_berok. because there are different situations i thought uboot via network fits best.14:54
LetoThe2nd"u-boot via network" and "scp by this i meant hard copy the image when the system is running" really don't go together, you'll have to make up your mind :P14:55
chris_bercan you give me an entrypoint where i have to start to check what "my" uboot is capable of? when i start the board i can't see any uboot-message. I only see the running image14:57
chris_berreally don't go together -> they don't, was just a noobie hope to get it easy14:57
LetoThe2ndif you are in the u-boot shell, type "help214:57
LetoThe2ndif the "tftpboot" command is there and you can bring up the ethernet interfaces, you are probably good to go.14:58
chris_berhow to get to the shell?14:59
LetoThe2ndusually by pressing a key. but might be board specific.15:00
chris_berthe first thing i see is the login prompt. so i fear i have to configure u boot in the first place15:00
*** gtristan <gtristan!~tristanva@> has quit IRC15:04
LetoThe2ndvery well possible, then.15:05
*** kiwi_29 <kiwi_29!> has joined #yocto15:11
*** kiwi_29 <kiwi_29!> has quit IRC15:15
*** like2wise <like2wise!> has joined #yocto15:17
*** xtron <xtron!~xtron@> has quit IRC15:19
frayJPEW / RP :  I think I found the problem.  The shlibs2/<lib>.list files are changing orders.  In packages.bbclass, the sonames that get writtent o this are not sorted..15:19
frayI might have a fix, but I'm working through it to check still15:19
*** likewiser <likewiser!> has quit IRC15:20
*** Konsgnx <Konsgnx!> has joined #yocto15:26
RPfray: ah, interesting. I thought we handled all that :(15:36
*** goliath <goliath!> has joined #yocto15:38
splatchlooking at my `lsusb -t` output I see:     |__ Port 11: Dev 22, If 0, Class=Vendor Specific Class, Driver=, 12M15:39
splatch    |__ Port 11: Dev 22, If 1, Class=Application Specific Interface, Driver=, 12M15:39
splatchwhy driver is empty?15:40
*** jmiehe <jmiehe!> has quit IRC15:45
*** chrysh <chrysh!> has joined #yocto15:45
*** likewiser <likewiser!> has joined #yocto15:48
khemRP: is there a way to get names of all recipes from bitbake that go into an image15:51
*** like2wise <like2wise!> has quit IRC15:51
*** gtristan <gtristan!~tristanva@> has joined #yocto15:52
RPkhem: BB_TASKDEPDATA is probably what you want15:52
kergothalternatively, query the installed packages after the fact and map that to recipes with pkgdata, perhaps? depends on what you're looking for and why15:56
*** frsc <frsc!> has quit IRC15:57
khemkergoth: I want to know recipe names in a image15:58
khemthat i can create a list15:58
*** fl0v0 <fl0v0!~fvo@> has quit IRC15:59
*** rubdos <rubdos!~rubdos@2a02:578:859d:700:8b44:5716:382d:a7da> has quit IRC16:03
*** codusnocturnus <codusnocturnus!> has joined #yocto16:05
*** florian__ <florian__!~florian_k@Maemo/community/contributor/florian> has quit IRC16:08
*** zandrey <zandrey!~zandrey@> has quit IRC16:10
*** rubdos <rubdos!~rubdos@2a02:578:859d:700:8b44:5716:382d:a7da> has joined #yocto16:10
*** gsalazar <gsalazar!5e3ce511@gateway/web/cgi-irc/> has quit IRC16:18
*** vicale <vicale!> has joined #yocto16:18
*** like2wise <like2wise!> has joined #yocto16:20
*** likewiser <likewiser!> has quit IRC16:22
*** chris_ber <chris_ber!~quassel@> has quit IRC16:23
*** geissonator <geissonator!~geissonat@> has joined #yocto16:27
*** rcw <rcw!~rcw@> has quit IRC16:29
*** thaytan <thaytan!> has joined #yocto16:32
JPEWfray: Ah, interesting16:35
*** likewiser <likewiser!> has joined #yocto16:52
*** like2wise <like2wise!> has quit IRC16:54
*** codusnocturnus <codusnocturnus!> has quit IRC16:55
*** vineela <vineela!~vtummala@> has joined #yocto16:55
*** kaspter <kaspter!~Instantbi@> has joined #yocto17:20
*** like2wise <like2wise!> has joined #yocto17:25
*** sstabellini_ <sstabellini_!sstabellin@gateway/shell/xshellz/x-ztcavbaaemlmsyca> has left #yocto17:25
*** likewiser <likewiser!> has quit IRC17:25
*** rcw <rcw!~rcw@> has joined #yocto17:51
*** LetoThe2nd <LetoThe2nd!uid453638@gateway/web/> has quit IRC17:52
*** like2wise <like2wise!> has quit IRC17:59
*** T_UNIX <T_UNIX!uid218288@gateway/web/> has quit IRC18:03
*** like2wise <like2wise!> has joined #yocto18:05
*** rcoote <rcoote!> has quit IRC18:11
*** codusnocturnus <codusnocturnus!> has joined #yocto18:20
*** adelcast <adelcast!~adelcast@2605:6000:101c:3b5:37f1:578e:8088:a1b4> has joined #yocto18:23
*** robbawebba <robbawebba!> has joined #yocto18:26
kergothfray: nicely done spotting that shlibs ordering issue18:27
frayworking on PR serice now..  turn that on and everything rebuilds each time18:34
*** like2wise <like2wise!> has quit IRC18:39
RPzeddii: " perf: backport a fix for confusing non-fatal error" - do we want to queue/test that or look for other fixes?18:39
zeddiithat's the only option for that issue at least. There may be some other failures lurking, since that one wasn't breaking the build .. but none the less needs to be fixed.18:40
RPzeddii: ok, I'll queue it. I just don't want to get shouted at :)18:41
armpitwe can queue confusion?18:41
RParmpit: that is permanently on tap these days18:42
*** likewise <likewise!> has joined #yocto18:49
kergothhmm, hashserve=auto + multiconfig blows up in connecting/reconnecting/etc to the server18:51
*** codusnocturnus <codusnocturnus!> has quit IRC18:56
*** kaspter <kaspter!~Instantbi@> has quit IRC18:57
*** comptroller <comptroller!> has joined #yocto19:01
*** roussinm <roussinm!> has quit IRC19:06
*** roussinm <roussinm!> has joined #yocto19:06
*** vineela <vineela!~vtummala@> has quit IRC19:08
*** berton <berton!~berton@> has joined #yocto19:10
frayok, so enabling PR then dumps PKGR nto pkgdata/runtime/* files..  so just a rebuild makes it no longer hash equivalent.. so we'll need to come up with a solution for that19:17
fray-PKGR: r0.019:18
fray+PKGR: r0.119:18
roussinmDoes the recipe path is included in the runtaskdeps for native recipes? We see rebuilds of recipe because the path stored in the sstate-cache object in the shared server is different then the one developer own pcs. We see the difference by using bitbake-diffsigs.
*** like2wise <like2wise!> has joined #yocto19:21
fullstopI think that kernel.bbclass is broken for 5.8+ kernels19:21
fraythat sounds like a recipe bug of some kind..  It really shouldn't be different AFAIK19:22
zeddiihow so ? I've been building and booting 5.8 for weeks, and just smoke tested 5.9-rc1 this morning19:22
fullstopwait, it's been fixed upstream19:22
zeddiiah that one. yah, that was fixed a while ago.19:23
fullstopmy version doesn't have [ -e Module.symvers ]19:23
*** likewise <likewise!> has quit IRC19:23
fullstopI'm on 3.1.119:23
fullstophmm.. now I need to check my branch setup because it should be there.19:25
fullstopoh, need to pull19:25
*** thaytan <thaytan!> has quit IRC19:30
*** vineela <vineela!~vtummala@> has joined #yocto19:44
*** likewiser <likewiser!> has joined #yocto19:53
roussinmIs the recipe path is taken in the sstate hash calculation for native recipe? If I copy shared sstate cache object from the server to my own PC and disable the sstate mirror, it will rebuild the recipe. When I diffsigs the task it shows recipes path changed because of my envrionement and the one of the server.?19:55
*** like2wise <like2wise!> has quit IRC19:55
frayJPEW any suggestions how to deal with the pkdata getting PKGR in it, causing the hashes to change?20:02
frayI've though maybe putting the PKGR into it's own file, then exclusing that from the hash comparison (if PR servie is enabled).. or not epanding PKGR's EXTENDPRAUTO, and adding the EXTENDPRAUTO to it's own file instead..20:03
fraycause presumably if teh user has changed teh PKGR (other then the auto) they'd want a new package, even if the contents don't chnge20:04
fullstopthat awkward moment when one change triggers a much larger rebuild than expected20:15
*** comptroller <comptroller!> has quit IRC20:18
*** comptroller <comptroller!> has joined #yocto20:27
*** thaytan <thaytan!> has joined #yocto20:37
*** vineela <vineela!~vtummala@> has quit IRC20:42
roussinmIt looks like that the path in the sstate-cache objects from the the model in the clean_basepath function: `b = b + ":" + a.rsplit(":", 1)[0]`, using only 1 split here to find the virtual:native string it looks like, but it pull the whole path of the recipe too. If I change the code to use 2 splits instead I do not get the absolute recipe path. Why is there the full path instead of only the recipe20:50
splatchone step forward, two steps back.. I managedto get usbutils working in the build and attempted to enumerate usb devices.. to my surprise there are just two devices and these are hubs. There is no usb/uart adapter I expected to see. I have "device descriptor read/64, error -71" messages which results in missing device. Complete dmesg output for usb initialization is here:20:56
splatchto make matter even more interesting.. it works with my local device but fails for customer20:57
splatchhow to read the error -71? I know device fails to initialize, but what does it mean?20:58
*** Konsgnx <Konsgnx!> has quit IRC21:00
*** NiksDev <NiksDev!~NiksDev@> has quit IRC21:01
*** NiksDev <NiksDev!~NiksDev@> has joined #yocto21:01
*** Sasha62 <Sasha62!a5e1d0b2@> has quit IRC21:06
JPEWfray: Ya, is for when the PRServer is used?21:12
*** berton <berton!~berton@> has quit IRC21:19
*** ant__ <ant__!> has joined #yocto21:28
*** zandrey <zandrey!> has joined #yocto21:39
*** beneth <beneth!> has left #yocto21:43
*** kiwi_29 <kiwi_29!> has joined #yocto21:46
robbawebbaHi, I'm having some trouble with statically linking a native variant of a recipe and I'd appreciate some guidance. The recipe I am trying to build is not yet upstreamed, and patches were submitted to the ML awhile ago:
*** matthewzmd <matthewzmd!> has quit IRC21:48
robbawebbahere are the errors I'm getting when building mfgtools-native with PKGCONFIG = "static" : Is there anything glaringly wrong with the recipe or the do_compile logs? I know this is not a supported recipe, so no worries if it's not possible ot help. any and all feedback is greatly appreciated!21:49
*** kiwi_29 <kiwi_29!> has quit IRC21:49
*** Ad0 <Ad0!~Ad0@> has quit IRC21:54
zandreyfbre: got in a very loong lag now, sorry for that. i took a look at the way how wic picks up the kernel: it does that by packing it via IMAGE_BOOT_FILES, which in turn picks up kernel image defined in KERNEL_IMAGETYPE21:55
zandreyfbre: what you can do is to inspect your fat32 partition in the wic to see if you have a kernel there with the size bigger than what you had before you enabled iniramdisk. then you have to make sure u-boot picks that one up, and not the kernel without it21:57
*** Ad0 <Ad0!~Ad0@> has joined #yocto22:01
zandreyi actually have a question from my side to the audience: does anyone uses fit images for aarch64 targets? i took a turn today to bundle the fit via its generated by kernel-fitimage and it turns out that kernel gets compressed. this is then failing to be inflated back by u-boot, and target does not boot. compression feature has been introduced a year ago, i've figured out the commit for that, and reverting it makes u-boot to load uncompressed22:03
zandreykernel just fine.22:03
*** matthewzmd <matthewzmd!> has joined #yocto22:03
zandreyhence the question: does anyone here uses fit images for aarch64 targets, and if yes - do you see same issues during load?22:04
*** rcw <rcw!~rcw@> has quit IRC22:11
*** jrdn <jrdn!> has quit IRC22:11
*** agust <agust!> has quit IRC22:30
mattsmzandrey: I am- what is your KERNEL_IMAGETYPE and IMAGE_BOOT_FILES22:31
zandreymattsm: KERNEL_IMAGETYPE = "Image"22:32
mattsmI set my KERNEL_IMAGETYPE to fitImage22:32
zandreyups, sorry! it is "fitImage", otherwise the fit would not even be built!22:32
zandreymattsm: the question is - do you have anything specific in u-boot to relocate fit to a different address so that it un-compresses kernel image to ${loadaddr}?22:34
mattsmI'm doing a fit image inside a wic image22:34
mattsmI did have to muck with u-boot, to change the bootcmd (not sure it's done right) BUT I don't have a compressed kernel22:35
mattsmor maybe I do but my bootm inside u-boot is not complaining22:35
mattsmhow is it failing to inflate?22:36
zandreycan you check the "compression" field during bootm execution?22:36
mattsmdoes it try at least or just try to execute a compressed kernel?22:36
zandreynope, it tries - but gives up with -5...22:36
marexzandrey: during load ?22:36
zandreymarex: yeap, exactly22:37
mattsm     Compression:  gzip compressed22:37
marexzandrey: like what, bootm fitimageaddr fails somehow ?22:37
mattsmI wonder if you are running out of memory, or something is overwritting something during the uncompress step22:37
zandreyif i disable compression - bootm is happy22:37
mattsmdo you have UBOOT_ENTRYPOINT and UBOOT_LOADADDRESS set properly?22:38
mattsmI guess so, if it works without gzip compression22:38
zandreymattsm: i have 27MB image and 64MB window for bootm configured22:39
zandrey11MB is the compressed one22:39
marexzandrey: pastebin the full output of your uboot problem, from power on until the failure22:39
ant__robbawebba, the warning is clear libusb_set_debug(libusb_context*, int) is deprecated22:39
marexzandrey: and pastebin 'env print' output22:39
ant__see i.e this workaround for another recipe
zandreymarex: i have a setup i can only access tomorrow, it is sitting on my desk in the office now. i'll do that first thing tomorrow.22:41
zandreymarex: u-boot version is 2020.04 btw22:41
marexzandrey: which SoC is that btw ?22:42
*** leon-anavi <leon-anavi!~Leon@> has quit IRC22:42
marexon arm64, you can hit the nasty thing that either , if you set fdt_high to -1 (or 0xffffffffffffffff) , the DT will be at 4-byte aligned address , while it must be at 8byte aligned address on arm6422:42
marexso stop using fdt_high=-1 and replace that with bootm_size22:42
marexthen U-Boot will figure the placement out on its own and it will be correct22:43
marexsadly, the nxp bsps are full of this fdt_high and initrd_high misuse22:43
marexthe other option is that you placed the kernel at the wrong address22:43
marexiirc per spec the aarch64 Image must be at 2MiB aligned offset22:44
marexso check that too22:44
zandreymarex: spot on! i've just dug out some old logs from the previous boots - indeed the fdt_high is set to -1!22:44
zandreymarex: i would try to fix this also tomorrow and try again! thanks for your tips! ;)22:45
marexzandrey: the nasty thing is, if the fitImage .its input changes (like even if a description changes in there somewhere by one character), the DT blob might just move by 4 bytes in that file22:45
marexand then you run into this, so then you keep re-running mkimage and wonder what is going on22:46
marexzandrey: rcar3 has examples of using bootm_size , so look at that and you should be all good22:46
ant__robbawebba, thats for the warnings, for the ld error (-lz -ldl -lbz2) try to inspect the native sysroot at first for the specified libs22:49
zandreymarex: thanks again - you just gave a lot of materials for digging! :) really appreciate that!22:53
ant__robbawebba, check that you have correctly specified with -L the paths for every .a22:58
*** ant__ <ant__!> has quit IRC22:58
khemrobbawebba: you need to install static version of glibc and libstdc++ on your build host23:06
*** vineela <vineela!~vtummala@> has joined #yocto23:09
*** ericch <ericch!> has quit IRC23:15
*** samvlewis <samvlewis!~samvlewis@> has quit IRC23:17
*** samvlewis <samvlewis!~samvlewis@> has joined #yocto23:21
robbawebbakhem: thanks! So after I install the static versions of clibc and libstdc++, it seems like that should cover all of the "standard" libraries that I'm missing, correct? Then I would follow ant__'s advice for making sure the other non-standard libraries like bz2 already exist in the native sysroot?23:22
*** likewiser <likewiser!> has quit IRC23:23
khemright add native dependencies e.g. bzip2-native etc23:44
*** yann <yann!> has quit IRC23:48
*** JaMa <JaMa!> has quit IRC23:53

Generated by 2.17.2 by Marius Gedminas - find it at!