| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC | 00:08 | |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto | 00:17 | |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC | 00:49 | |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto | 00:49 | |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC | 00:55 | |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto | 01:01 | |
| *** jellycode <jellycode!~jellycode@2601:408:8100:8270:35cf:602:80f5:dc> has quit IRC | 01:04 | |
| *** mattsm <mattsm!~mattsm@76-205-175-243.lightspeed.austtx.sbcglobal.net> has quit IRC | 01:10 | |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC | 01:16 | |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto | 01:20 | |
| *** kaspter <kaspter!~Instantbi@58.246.136.202> has joined #yocto | 01:23 | |
| *** camus1 <camus1!~Instantbi@58.246.136.202> has joined #yocto | 01:48 | |
| *** kaspter <kaspter!~Instantbi@58.246.136.202> has quit IRC | 01:49 | |
| *** camus1 is now known as kaspter | 01:49 | |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC | 01:51 | |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto | 01:51 | |
| *** mattsm <mattsm!~mattsm@76-205-175-243.lightspeed.austtx.sbcglobal.net> has joined #yocto | 01:56 | |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC | 01:57 | |
| *** stbenz61 <stbenz61!~stbenz@ipbcc08e73.dynamic.kabel-deutschland.de> has joined #yocto | 02:02 | |
| *** stacktrust <stacktrust!~stacktrus@cpe-24-90-105-219.nyc.res.rr.com> has quit IRC | 02:03 | |
| *** yocton_ <yocton_!~quassel@51.15.170.227> has joined #yocto | 02:04 | |
| *** stacktrust <stacktrust!~stacktrus@cpe-24-90-105-219.nyc.res.rr.com> has joined #yocto | 02:04 | |
| *** sstabellini <sstabellini!sstabellin@gateway/shell/xshellz/x-gnjzfccnzadguqmt> has quit IRC | 02:04 | |
| *** weltling <weltling!~toll@klapt.com> has quit IRC | 02:04 | |
| *** otavio_ <otavio_!~otavio@static.203.17.243.136.clients.your-server.de> has quit IRC | 02:04 | |
| *** weltling <weltling!~toll@klapt.com> has joined #yocto | 02:04 | |
| *** sstabellini_ <sstabellini_!sstabellin@gateway/shell/xshellz/x-ztcavbaaemlmsyca> has joined #yocto | 02:04 | |
| *** otavio_ <otavio_!~otavio@static.203.17.243.136.clients.your-server.de> has joined #yocto | 02:04 | |
| *** dl9pf_home <dl9pf_home!~quassel@opensuse/member/dl9pf> has quit IRC | 02:04 | |
| *** stbenz6 <stbenz6!~stbenz@ipbcc08e73.dynamic.kabel-deutschland.de> has quit IRC | 02:04 | |
| *** yocton <yocton!~quassel@51.15.170.227> has quit IRC | 02:04 | |
| *** stbenz61 is now known as stbenz6 | 02:04 | |
| *** dl9pf_home <dl9pf_home!~quassel@static.253.98.203.116.clients.your-server.de> has joined #yocto | 02:04 | |
| *** dl9pf_home <dl9pf_home!~quassel@opensuse/member/dl9pf> has joined #yocto | 02:04 | |
| *** [Sno] <[Sno]!~sno@p5b25b03a.dip0.t-ipconnect.de> has joined #yocto | 02:05 | |
| *** sno <sno!~sno@p5b25b03a.dip0.t-ipconnect.de> has quit IRC | 02:05 | |
| *** geheimnis` <geheimnis`!~geheimnis@23.226.237.192> has quit IRC | 02:05 | |
| *** fray <fray!~fray@kernel.crashing.org> has quit IRC | 02:05 | |
| *** mckoan|away <mckoan|away!~marco@unaffiliated/mckoan> has quit IRC | 02:05 | |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto | 02:05 | |
| *** meow` <meow`!~sbourdeli@107.159.31.190> has quit IRC | 02:06 | |
| *** dirbaio <dirbaio!~dirbaio@nsmbhd.net> has quit IRC | 02:06 | |
| *** mckoan|away <mckoan|away!~marco@host-79-3-92-72.business.telecomitalia.it> has joined #yocto | 02:07 | |
| *** geheimnis` <geheimnis`!~geheimnis@23.226.237.192> has joined #yocto | 02:07 | |
| *** grumble <grumble!~Thunderbi@freenode/staff/grumble> has quit IRC | 02:11 | |
| *** grumble <grumble!~Thunderbi@freenode/staff/grumble> has joined #yocto | 02:12 | |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC | 02:17 | |
| *** fray <fray!~fray@kernel.crashing.org> has joined #yocto | 02:18 | |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto | 02:18 | |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC | 02:19 | |
| *** hpsy1 <hpsy1!~hpsy@92.118.12.72> has joined #yocto | 02:19 | |
| *** dirbaio <dirbaio!~dirbaio@nsmbhd.net> has joined #yocto | 02:19 | |
| *** hpsy <hpsy!~hpsy@92.118.12.13> has quit IRC | 02:20 | |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto | 02:22 | |
| *** meow` <meow`!~sbourdeli@107.159.31.190> has joined #yocto | 02:25 | |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC | 02:52 | |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto | 02:52 | |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC | 03:09 | |
| *** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has quit IRC | 03:09 | |
| *** codusnocturnus <codusnocturnus!~codusnoct@ip68-98-225-84.ph.ph.cox.net> has joined #yocto | 03:18 | |
| *** adelcast <adelcast!~adelcast@2605:6000:101c:3b5:c255:6326:5d60:1a29> has quit IRC | 03:44 | |
| *** georgem_home <georgem_home!uid210681@gateway/web/irccloud.com/x-ohuxmphurbruygjw> has quit IRC | 05:03 | |
| *** zandrey <zandrey!~zandrey@cable-static2-2-7.rsnweb.ch> has quit IRC | 05:19 | |
| *** jobroe <jobroe!~manjaro-u@p579eb6a1.dip0.t-ipconnect.de> has joined #yocto | 05:29 | |
| *** agust <agust!~agust@p508b6ab0.dip0.t-ipconnect.de> has joined #yocto | 05:43 | |
| *** AndersD <AndersD!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has joined #yocto | 05:43 | |
| *** gtristan <gtristan!~tristanva@175.211.69.194> has quit IRC | 05:48 | |
| *** zandrey <zandrey!~zandrey@193.8.40.126> has joined #yocto | 05:58 | |
| *** LetoThe2nd <LetoThe2nd!uid453638@gateway/web/irccloud.com/x-hzdwtqvblcymoatp> has joined #yocto | 06:05 | |
| *** Moh3N <Moh3N!2ed17334@46.209.115.52> has joined #yocto | 06:17 | |
| Moh3N | hello to all | 06:18 |
|---|---|---|
| Moh3N | I want to know what is my kernel source that yocto download it and working on it | 06:18 |
| *** paulg <paulg!~paulg@198-84-145-15.cpe.teksavvy.com> has quit IRC | 06:18 | |
| Moh3N | in my kernel recipe I have : git://git.freescale.com/ppc/sdk/linux.git;branche=sdk-v2.0.x | 06:19 |
| Moh3N | I 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 |
| LetoThe2nd | https://www.yoctoproject.org/docs/current/kernel-dev/kernel-dev.html | 06:23 |
| LetoThe2nd | specifically, https://www.yoctoproject.org/docs/current/kernel-dev/kernel-dev.html#working-with-your-own-sources | 06:23 |
| *** beneth <beneth!~beneth@irc.beneth.fr> has joined #yocto | 06:24 | |
| Moh3N | thank you. I dont know this address : git://git.freescale.com/ppc/sdk/linux.git;branche=sdk-v2.0.x I want to download it but I cant | 06:25 |
| LetoThe2nd | git clone just as always. | 06:25 |
| *** codusnocturnus <codusnocturnus!~codusnoct@ip68-98-225-84.ph.ph.cox.net> has quit IRC | 06:26 | |
| LetoThe2nd | specifically, git clone git://git.freescale.com/ppc/sdk/linux.git | 06:26 |
| LetoThe2nd | but if that already is a show stopper, i strongly suggest starting out with some very *introductory* material. | 06:26 |
| *** rcoote <rcoote!~rcoote@221-224-024-217.ip-addr.vsenet.de> has joined #yocto | 06:27 | |
| Moh3N | it says : unable to look up git.freescale.com (port 9418) (No such host is known. ) | 06:27 |
| Moh3N | but yocto used this address | 06:27 |
| Moh3N | thank you | 06:28 |
| LetoThe2nd | yocto used this address? | 06:28 |
| Moh3N | this address is in my kernel recipe | 06:29 |
| LetoThe2nd | if i had to guess then, either the server is down or the recipe is massively outdated. | 06:29 |
| Moh3N | meybe, 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 |
| LetoThe2nd | usually its called just like the src_uri | 06:32 |
| Moh3N | we 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 day | 06:33 |
| Moh3N | (on = of a source) sorry for poor English | 06:34 |
| *** gsalazar <gsalazar!5e3ce511@gateway/web/cgi-irc/kiwiirc.com/ip.94.60.229.17> has joined #yocto | 06:34 | |
| *** fbre <fbre!91fdde45@145.253.222.69> has joined #yocto | 06:36 | |
| LetoThe2nd | then put it onto your git server, make the recipe use it... all the usual techniques apply. | 06:37 |
| Moh3N | Im trying, thanks a lot | 06:49 |
| *** T_UNIX <T_UNIX!uid218288@gateway/web/irccloud.com/x-bfpclsmyxbkxnwxw> has joined #yocto | 06:49 | |
| T_UNIX | hi | 06:49 |
| T_UNIX | why is `/var/tmp/` specified using tmpfiles notion in http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-core/initscripts/initscripts-1.0/volatiles?h=zeus , yet as a "file" (symlink) packaged in http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-core/base-files/base-files_3.0.14.bb?h=zeus instead of a likewise line in | 06:50 |
| T_UNIX | http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-core/systemd/systemd/00-create-volatile.conf?h=zeus ? | 06:50 |
| *** frsc <frsc!~frsc@i6DFA84A1.versanet.de> has joined #yocto | 06:51 | |
| *** jrdn <jrdn!~jrdn@S010668ff7b6b7383.ok.shawcable.net> has quit IRC | 06:54 | |
| *** fl0v0 <fl0v0!~fvo@88.130.218.41> has joined #yocto | 06:55 | |
| *** kaspter <kaspter!~Instantbi@58.246.136.202> has quit IRC | 06:56 | |
| *** camus1 <camus1!~Instantbi@58.246.136.202> has joined #yocto | 06:56 | |
| *** camus1 is now known as kaspter | 06:59 | |
| *** yacar_ <yacar_!~yacar_@static-css-csd-172251.business.bouyguestelecom.com> has joined #yocto | 07:07 | |
| *** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has joined #yocto | 07:07 | |
| *** gtristan <gtristan!~tristanva@110.11.238.91> has joined #yocto | 07:36 | |
| *** mckoan|away is now known as mckoan | 07:39 | |
| mckoan | good morning | 07:39 |
| *** mckoan <mckoan!~marco@host-79-3-92-72.business.telecomitalia.it> has quit IRC | 07:40 | |
| *** mckoan <mckoan!~marco@unaffiliated/mckoan> has joined #yocto | 07:40 | |
| erbo | good morning | 07:41 |
| *** hpsy1 <hpsy1!~hpsy@92.118.12.72> has quit IRC | 07:43 | |
| *** hpsy <hpsy!~hpsy@92.118.12.72> has joined #yocto | 07:43 | |
| *** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has quit IRC | 07:45 | |
| *** chris_ber <chris_ber!~quassel@213.138.44.181> has joined #yocto | 07:52 | |
| *** jmiehe <jmiehe!~Thunderbi@p578c106e.dip0.t-ipconnect.de> has joined #yocto | 08:00 | |
| *** leon-anavi <leon-anavi!~Leon@78.130.197.211> has joined #yocto | 08:03 | |
| *** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has joined #yocto | 08:05 | |
| *** AndersD <AndersD!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has quit IRC | 08:08 | |
| *** osullivan99 <osullivan99!~osullivan@host-82-135-4-50.static.customer.m-online.net> has joined #yocto | 08:14 | |
| ykrons_ | Hello | 08:15 |
| *** chris_ber <chris_ber!~quassel@213.138.44.181> has quit IRC | 08:18 | |
| *** chris_ber <chris_ber!~quassel@213.138.44.181> has joined #yocto | 08:20 | |
| *** ykrons_ is now known as ykrons | 08:20 | |
| *** [Sno] <[Sno]!~sno@p5b25b03a.dip0.t-ipconnect.de> has quit IRC | 08:20 | |
| *** Moh3N <Moh3N!2ed17334@46.209.115.52> has quit IRC | 08:22 | |
| ykrons | I'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 .. xxxx.bb:do_build). 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 help | 08:24 |
| *** goliath <goliath!~goliath@82.150.214.1> has joined #yocto | 08:26 | |
| *** hipr_c <hipr_c!463c38d2@rrcs-70-60-56-210.central.biz.rr.com> has quit IRC | 08:31 | |
| fbre | maybe the build problems are because of a full hard disk or such things? | 08:32 |
| ykrons | fbre, 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 |
| fbre | I would try another machine and see if it still happens there | 08:37 |
| RP | ykrons: try looking at the output from ps as that should have a partial taskname in the process name | 08:43 |
| RP | ykrons: its almost certainly not the noexec tasks but something which started before that and hasn;t finished | 08:43 |
| ykrons | RP, fbre : I will try another machine and check running process when stuck | 08:45 |
| *** [Sno] <[Sno]!~sno@195.14.209.36> has joined #yocto | 08:47 | |
| *** ant__ <ant__!~ant__@host-195-31-129-205.business.telecomitalia.it> has joined #yocto | 09:00 | |
| *** ant__ <ant__!~ant__@host-195-31-129-205.business.telecomitalia.it> has quit IRC | 09:04 | |
| *** dexterlb <dexterlb!~dexterlb@qtrp.org> has quit IRC | 09:05 | |
| fbre | Hi! 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 device | 09:12 |
| fbre | /dev/ram0...". What could be wrong? | 09:12 |
| *** mckoan is now known as mckoan|away | 09:14 | |
| fbre | Without changing root in u-boot everything is fine and yocto boots well and I can login on its prompt | 09:14 |
| RP | fbre: how do you know the initramfs isn't being booted and then switching to the main rootfs? | 09:19 |
| RP | fbre: sadly its been many years since I worked on initramfs so I don't remember the details | 09:20 |
| *** mi99 <mi99!~asd@85.254.96.13> has quit IRC | 09:23 | |
| *** emrius <emrius!5840fa9b@dslb-088-064-250-155.088.064.pools.vodafone-ip.de> has joined #yocto | 09:27 | |
| emrius | Hey 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 increase | 09:32 |
| emrius | permanently 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 |
| emrius | And 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 |
| RP | emrius: wouldn't it be better to disable the problematic serial getty? | 09:34 |
| RP | If you do that wtmp may be fine? | 09:34 |
| *** xtron <xtron!~xtron@103.113.103.164> has joined #yocto | 09:34 | |
| RP | emrius: the SERIAL_CONSOLES variable comes to mind | 09:35 |
| emrius | Yes. 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 |
| RP | emrius: I'm sure wtmp can likely be disabled but you'd probably have to look at the systemd docs | 09:36 |
| emrius | RP Thanks! I had a look into that variable already. Can I simply clear that variable or will that have negative side effects? | 09:36 |
| RP | emrius: I think clearing it should be fine, you don't want a serial console... | 09:36 |
| fbre | RP: I added an echo output to init-live.sh 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 road | 09:37 |
| fbre | RP: 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.conf | 09:38 |
| RP | fbre: Looking at the code, I'd go and check your kernel does have the initramfs included in it | 09:42 |
| *** dexterlb <dexterlb!~dexterlb@2a01:9e40:2:2::2> has joined #yocto | 09:42 | |
| RP | fbre: 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 |
| fbre | RP: I just followed https://www.yoctoproject.org/docs/3.1/dev-manual/dev-manual.html#building-an-initramfs-image and expect the initramfs to be bundled. The .wic file is slightly bigger than without that bundling (about 80KB). | 09:45 |
| RP | fbre: how big is the core-image-initramfs file? | 09:45 |
| RP | fbre: You're using an fsl kernel if I remember correctly and I'd worry they're doing something incompatible with the standard initramfs setup | 09:46 |
| fbre | RP: I have several files, I think you mean this one (?): core-image-tiny-initramfs-imx8mmevk-[timestamp].rootfs.cpio.gz = 11,8MB | 09:48 |
| *** kaspter <kaspter!~Instantbi@58.246.136.202> has quit IRC | 09:49 | |
| *** kaspter <kaspter!~Instantbi@58.246.136.202> has joined #yocto | 09:49 | |
| fbre | RP: 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.bz2 | 09:49 |
| RP | fbre: right, so the kernel increasing 80kb for an 11MB initramfs doesn't add up | 09:50 |
| fbre | RP: 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 usually | 09:53 |
| RP | fbre: no. Look at the do_bundle_initramfs task. It adds the initramfs image to the kernel binary | 09:53 |
| RP | fbre: I don't know if your layout puts the kernel into that wic image or not | 09:54 |
| *** florian__ <florian__!~florian_k@Maemo/community/contributor/florian> has joined #yocto | 09:54 | |
| *** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has quit IRC | 09:57 | |
| fbre | RP: 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@195.14.209.36> has quit IRC | 10:25 | |
| *** xtron <xtron!~xtron@103.113.103.164> has quit IRC | 10:35 | |
| *** gourve_l <gourve_l!~laurent@40.72.95.92.rev.sfr.net> has quit IRC | 10:36 | |
| *** xtron <xtron!~xtron@host-3-net-103-160-119.mobilinkinfinity.net.pk> has joined #yocto | 10:38 | |
| *** xtron <xtron!~xtron@host-3-net-103-160-119.mobilinkinfinity.net.pk> has quit IRC | 10:44 | |
| *** dexterlb <dexterlb!~dexterlb@2a01:9e40:2:2::2> has quit IRC | 10:52 | |
| *** dexterlb <dexterlb!~dexterlb@2a01:9e40:2:2::2> has joined #yocto | 10:53 | |
| *** [Sno] <[Sno]!~sno@p5b25b03a.dip0.t-ipconnect.de> has joined #yocto | 10:54 | |
| RP | fbre: right, but does the fsl kernel ignore that somehow? | 10:55 |
| *** NiksDev <NiksDev!~NiksDev@192.91.75.12> has quit IRC | 10:57 | |
| *** xtron <xtron!~xtron@103.113.103.41> has joined #yocto | 10:57 | |
| *** NiksDev <NiksDev!~NiksDev@192.91.101.30> has joined #yocto | 10:58 | |
| fbre | RP: 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 size | 11:03 |
| *** AndersD <AndersD!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has joined #yocto | 11:04 | |
| fbre | RP: The question is how I should find out where it fails. I'm stumped | 11:04 |
| RP | fbre: The fsl layer is notorious for doing interesting things and causing workflows like this to break :( | 11:06 |
| JaMa | is 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 URL | 11:09 |
| JaMa | e.g. ROS_BRANCH ?= "branch=release/melodic/swri_nodelet" | 11:09 |
| JaMa | SRC_URI = "git://github.com/swri-robotics-gbp/marti_common-release;${ROS_BRANCH};protocol=https" | 11:09 |
| JaMa | ends with: raise MalformedUrl(url, "The URL: '%s' is invalid: parameter %s does not specify a value (missing '=')" % (url, s)) | 11:10 |
| JaMa | bb.fetch2.MalformedUrl: The URL: 'git://github.com/swri-robotics-gbp/marti_common-release;${ROS_BRANCH};protocol=https' is invalid: parameter ${ROS_BRANCH} does not specify a value (missing '=') | 11:10 |
| RP | JaMa: I'd suspect a bug somewhere :/ | 11:10 |
| RP | (in devtool) | 11:11 |
| JaMa | ok, will check | 11: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!~mrpelotaz@HSI-KBW-078-042-006-202.hsi3.kabel-badenwuerttemberg.de> has quit IRC | 11:19 | |
| JaMa | RP: patch sent | 11:20 |
| *** sstiller <sstiller!~sstiller@b2b-94-79-174-114.unitymedia.biz> has joined #yocto | 11:25 | |
| *** khem <khem!~khem@unaffiliated/khem> has quit IRC | 11:26 | |
| RP | emrius: no, is it actually booting? | 11:29 |
| fbre | zandrey: 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 #yocto | 11:32 | |
| *** berton <berton!~berton@181.220.78.182> has joined #yocto | 11: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 |
| RP | JaMa: does that write expanded data back to the recipe? | 11:38 |
| RP | emrius: that does sound like something else changed as well | 11: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!~rcoote@221-224-024-217.ip-addr.vsenet.de> has quit IRC | 11:52 | |
| *** ak77 <ak77!~akrpic77@193.46.75.3> has joined #yocto | 11:54 | |
| ak77 | hello! | 11:54 |
| *** xtron <xtron!~xtron@103.113.103.41> has quit IRC | 11:55 | |
| RP | emrius: people love to blame sstate but the reality is we've seen very very few issues in that area, at least with oe-core | 11:59 |
| *** TobSnyder <TobSnyder!~schneider@ip5f5aa32f.dynamic.kabel-deutschland.de> has joined #yocto | 11:59 | |
| RP | emrius: 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 |
| emrius | but I can imaging CTRL-C can be risky? At least I think I remember reading this somewhere | 12:02 |
| *** georgem_home <georgem_home!uid210681@gateway/web/irccloud.com/x-zxycrabosvmsnwup> has joined #yocto | 12:03 | |
| *** rcoote <rcoote!~rcoote@221-224-024-217.ip-addr.vsenet.de> has joined #yocto | 12:06 | |
| *** TobSnyder <TobSnyder!~schneider@ip5f5aa32f.dynamic.kabel-deutschland.de> has quit IRC | 12:08 | |
| osullivan99 | hello i'm trying to port u-boot for board TQMa335x | 12:09 |
| osullivan99 | i followed TI's guide on https://software-dl.ti.com/processor-sdk-linux/esd/docs/06_03_00_106/AM335X/linux/How_to_Guides/Board_Port/U-Boot.html | 12:09 |
| osullivan99 | when 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_!~yacar_@static-css-csd-172251.business.bouyguestelecom.com> has quit IRC | 12:14 | |
| *** kaspter <kaspter!~Instantbi@58.246.136.202> has quit IRC | 12:20 | |
| *** berton <berton!~berton@181.220.78.182> has quit IRC | 12:20 | |
| *** kaspter <kaspter!~Instantbi@58.246.136.202> has joined #yocto | 12:21 | |
| *** berton <berton!~berton@181.220.78.182> has joined #yocto | 12:21 | |
| JaMa | RP: not from this _guess_recipe_update_mode function (it returns only 'patch' or 'srcrev') | 12:24 |
| *** likewise <likewise!~Leon@145-132-74-106.fixed.kpn.net> has joined #yocto | 12:24 | |
| *** berton <berton!~berton@181.220.78.182> has quit IRC | 12:26 | |
| RP | JaMa: ah, that makes sense. I wasn't looking at the full context of the function | 12:30 |
| RP | JaMa: I wonder why its unexpanded | 12:30 |
| likewise | toolchain-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 |
| RP | likewise: does it do something like disabling OVERRIDES? | 12:32 |
| likewise | OVERRIDES contains libc-musl | 12:32 |
| RP | likewise: when its writing the toolchain script? | 12:33 |
| likewise | RP: Apparently not, the " -mmusl" does not end up there. | 12:33 |
| RP | likewise: try writing out OVERRIDES at the same time its writing out that variable? | 12:33 |
| RP | likewise: I did see your email about it but I don't really have anything useful to suggest other than debugging it :/ | 12:34 |
| likewise | RP: Good suggestion. Will try. | 12:34 |
| *** rcoote <rcoote!~rcoote@221-224-024-217.ip-addr.vsenet.de> has quit IRC | 12:36 | |
| likewise | RP: 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 |
| RP | likewise: using a debugging with OE is hard :( | 12:47 |
| RP | er, a debugger | 12:47 |
| ak77 | can'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!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has quit IRC | 12:57 | |
| *** gsalazar <gsalazar!5e3ce511@gateway/web/cgi-irc/kiwiirc.com/ip.94.60.229.17> has quit IRC | 12:59 | |
| likewise | RP: Thanks. The OVERRIDES seems indeed for the canadian cross tool build, no longer the target. | 13:04 |
| likewise | OVERRIDES=task-generate-content:linux-musl:x86-64:pn-meta-environment-qemux86-64:qemuall:qemux86-64:nodistro:class-cross-canadian:libc-glibc:forcevariable | 13:04 |
| likewise | linux-musl is still there, but the C library is libc-glibc | 13:05 |
| likewise | (So now I wonder if linux-musl is correct for the canadian cross toolchain as well....?) | 13:05 |
| zandrey | fbre: 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 |
| zandrey | is it the bundled one? | 13:06 |
| zandrey | fbre: have you maybe also tried to build FIT image and pack initramdisk into it instead? | 13:07 |
| *** TundraMan <TundraMan!~marka@198-84-181-245.cpe.teksavvy.com> has joined #yocto | 13:07 | |
| *** tgamblin_ is now known as tgamblin | 13:08 | |
| *** marka <marka!~marka@198-84-181-245.cpe.teksavvy.com> has quit IRC | 13:08 | |
| fbre | zandrey: 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 all | 13:11 |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto | 13:11 | |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC | 13:16 | |
| fbre | zandrey: 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@145.253.222.69> has quit IRC | 13:22 | |
| *** gsalazar <gsalazar!5e3ce511@gateway/web/cgi-irc/kiwiirc.com/ip.94.60.229.17> has joined #yocto | 13:22 | |
| *** adelcast <adelcast!~adelcast@2605:6000:101c:3b5:c255:6326:5d60:1a29> has joined #yocto | 13:24 | |
| *** xtron <xtron!~xtron@103.113.103.48> has joined #yocto | 13:31 | |
| *** maze-BUG <maze-BUG!~Thunderbi@180.166.53.21> has joined #yocto | 13:32 | |
| ak77 | hmm.. how can I disable failed fetch to try to download from http://sources.openembedded.org/... ? | 13:36 |
| *** xtron <xtron!~xtron@103.113.103.48> has quit IRC | 13:37 | |
| *** xtron <xtron!~xtron@103.113.103.48> has joined #yocto | 13:37 | |
| maze-BUG | Hi, ALL. I got a problem : bitbake doesn't append sysroot to CPPFLAGS | 13:38 |
| maze-BUG | I use CmakeList to build my module. The error: | 13:38 |
| maze-BUG | fatal error: sys/mman.h: No such file or directory | 13:38 |
| maze-BUG | 6 | #include <sys/mman.h> | 13:38 |
| maze-BUG | which should in sysroot/usr/include | 13:38 |
| maze-BUG | how to debug this? | 13:38 |
| *** nayfe <nayfe!uid259604@gateway/web/irccloud.com/x-nxuwieoqwobtnhze> has joined #yocto | 13:39 | |
| kergoth | maze-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 |
| ak77 | maze-BUG, hmm.. it should. you use cmake class ? (inherit cmake) | 13:42 |
| likewise | RP: 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/CMake | 13:42 |
| maze-BUG | ak77: yes , "" inherit autotools qcommon qlicense qprebuilt cmake | 13:43 |
| maze-BUG | I my generate file rules.ninja can find this path: | 13:45 |
| maze-BUG | rule C_EXECUTABLE_LINKER__rotatetest | 13:45 |
| maze-BUG | 36 command = ... --sysroot=/local/mnt/workspace/lv.au.0.1.0/poky/build/tmp-glibc/work/sa8155-oe-linux/display-tests/git-r1/recipe-sysroot | 13:45 |
| LetoThe2nd | autotools AND cmake sounds... weird/wrong | 13:45 |
| maze-BUG | LetoThe2nd: Try close autotools, still build error. | 13:47 |
| RP | likewise: do you mean _append_libc-musl and _append_linux-musl ? | 13:47 |
| RP | I don't understand why the libc-musl append wouldn't work :/ | 13:48 |
| maze-BUG | kergoth: How to check the cmake.bbclass. I don't think anyone changed this file. | 13:50 |
| *** matthewzmd <matthewzmd!~user@216-58-109-18.cpe.distributel.net> has joined #yocto | 13:50 | |
| maze-BUG | My cmake.bbclass with this gerrit: | 13:51 |
| maze-BUG | 1b15cc6e65c18cda7888a2eef1f55bf0a660ae7e | 13:51 |
| *** paulg <paulg!~paulg@198-84-145-15.cpe.teksavvy.com> has joined #yocto | 13:52 | |
| *** chrysh <chrysh!~chrysh@someserver.de> has quit IRC | 13:52 | |
| splatch | I'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 |
| splatch | I probably miss some module or something, but how to find which one? | 13:56 |
| fray | start 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 |
| fray | if you do see an insertion event, but nothing happens.. then look at udev or systemd-udev.. it's probably missing a rule | 13:56 |
| splatch | I'm on earlier one - I see no event | 13:57 |
| fray | you'll have to try to find the setting in the kernel and enble it | 13:57 |
| *** jrdn <jrdn!~jrdn@S010668ff7b6b7383.ok.shawcable.net> has joined #yocto | 13:58 | |
| LetoThe2nd | it's a fray!!! | 13:59 |
| *** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has joined #yocto | 14:00 | |
| *** Sasha62 <Sasha62!a5e1d0b2@165.225.208.178> has joined #yocto | 14:01 | |
| fray | trying to be more present.. been really busy | 14:01 |
| *** ericch <ericch!~ericch@50-205-235-218-static.hfc.comcastbusiness.net> has joined #yocto | 14:03 | |
| LetoThe2nd | hey, i'm beeing cheerful. no more :) | 14:04 |
| maze-BUG | Looks like the gcc didn't fetch the include file in $sysroot/usr/include | 14:05 |
| maze-BUG | which chat should I join to ask this problem~? | 14:05 |
| *** jobroe <jobroe!~manjaro-u@p579eb6a1.dip0.t-ipconnect.de> has quit IRC | 14:12 | |
| *** like2wise <like2wise!~Leon@145-132-74-106.fixed.kpn.net> has joined #yocto | 14:14 | |
| *** likewise <likewise!~Leon@145-132-74-106.fixed.kpn.net> has quit IRC | 14:17 | |
| *** dexterlb <dexterlb!~dexterlb@2a01:9e40:2:2::2> has quit IRC | 14:17 | |
| *** hpsy <hpsy!~hpsy@92.118.12.72> has quit IRC | 14:25 | |
| *** thaytan <thaytan!~thaytan@180-150-69-32.b49645.syd.nbn.aussiebb.net> has quit IRC | 14:25 | |
| *** hpsy <hpsy!~hpsy@92.118.12.72> has joined #yocto | 14:26 | |
| *** sstiller <sstiller!~sstiller@b2b-94-79-174-114.unitymedia.biz> has quit IRC | 14:27 | |
| *** rcoote <rcoote!~rcoote@221-224-024-217.ip-addr.vsenet.de> has joined #yocto | 14:27 | |
| *** goliath <goliath!~goliath@82.150.214.1> has quit IRC | 14:29 | |
| *** emrius <emrius!5840fa9b@dslb-088-064-250-155.088.064.pools.vodafone-ip.de> has quit IRC | 14:30 | |
| *** dexterlb <dexterlb!~dexterlb@2a01:9e40:2:2::2> has joined #yocto | 14:32 | |
| chris_ber | i 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 |
| LetoThe2nd | why just "maybe"? | 14:44 |
| splatch | fray: 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!~vicale@dyn-13-cust157.netit.se> has quit IRC | 14:44 | |
| *** kaspter <kaspter!~Instantbi@58.246.136.202> has quit IRC | 14:45 | |
| *** likewiser <likewiser!~Leon@145-132-74-106.fixed.kpn.net> has joined #yocto | 14: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 |
| LetoThe2nd | chris_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 |
| LetoThe2nd | chris_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!~Leon@145-132-74-106.fixed.kpn.net> has quit IRC | 14:48 | |
| *** champagneg <champagneg!~gchamp@ipagstaticip-d73c7528-4de5-0861-800b-03d8b15e3869.sdsl.bell.ca> has joined #yocto | 14:49 | |
| chris_ber | ok, another solution to just copy a image via scp isn't a good idead or even possible? | 14:49 |
| LetoThe2nd | it depends(TM) | 14:50 |
| LetoThe2nd | but AFAIK u-boot doesn't do ssh/scp :) | 14:50 |
| chris_ber | by this i meant hard copy the image when the system is running | 14:51 |
| LetoThe2nd | it depends(TM) | 14:51 |
| *** PaowZ <PaowZ!~vince@2a01:e35:2e3e:4ac0:718b:1494:d962:ec52> has quit IRC | 14:52 | |
| *** peterp <peterp!8717f5a7@135-23-245-167.cpe.pppoe.ca> has joined #yocto | 14:52 | |
| LetoThe2nd | how 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 IRC | 14:53 | |
| chris_ber | ok. 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 :P | 14:55 |
| chris_ber | can 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 image | 14:57 |
| chris_ber | really don't go together -> they don't, was just a noobie hope to get it easy | 14:57 |
| LetoThe2nd | if you are in the u-boot shell, type "help2 | 14:57 |
| LetoThe2nd | "help" | 14:58 |
| LetoThe2nd | if the "tftpboot" command is there and you can bring up the ethernet interfaces, you are probably good to go. | 14:58 |
| chris_ber | how to get to the shell? | 14:59 |
| LetoThe2nd | usually by pressing a key. but might be board specific. | 15:00 |
| chris_ber | the first thing i see is the login prompt. so i fear i have to configure u boot in the first place | 15:00 |
| *** gtristan <gtristan!~tristanva@110.11.238.91> has quit IRC | 15:04 | |
| LetoThe2nd | very well possible, then. | 15:05 |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto | 15:11 | |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC | 15:15 | |
| *** like2wise <like2wise!~Leon@145-132-74-106.fixed.kpn.net> has joined #yocto | 15:17 | |
| *** xtron <xtron!~xtron@103.113.103.48> has quit IRC | 15:19 | |
| fray | JPEW / 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 |
| fray | I might have a fix, but I'm working through it to check still | 15:19 |
| *** likewiser <likewiser!~Leon@145-132-74-106.fixed.kpn.net> has quit IRC | 15:20 | |
| *** Konsgnx <Konsgnx!~Konsgnx3@66-109-34-138.tvc-ip.com> has joined #yocto | 15:26 | |
| RP | fray: ah, interesting. I thought we handled all that :( | 15:36 |
| *** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has joined #yocto | 15:38 | |
| splatch | looking at my `lsusb -t` output I see: |__ Port 11: Dev 22, If 0, Class=Vendor Specific Class, Driver=, 12M | 15:39 |
| splatch | |__ Port 11: Dev 22, If 1, Class=Application Specific Interface, Driver=, 12M | 15:39 |
| splatch | why driver is empty? | 15:40 |
| *** jmiehe <jmiehe!~Thunderbi@p578c106e.dip0.t-ipconnect.de> has quit IRC | 15:45 | |
| *** chrysh <chrysh!~chrysh@someserver.de> has joined #yocto | 15:45 | |
| *** likewiser <likewiser!~Leon@145-132-74-106.fixed.kpn.net> has joined #yocto | 15:48 | |
| khem | RP: is there a way to get names of all recipes from bitbake that go into an image | 15:51 |
| *** like2wise <like2wise!~Leon@145-132-74-106.fixed.kpn.net> has quit IRC | 15:51 | |
| *** gtristan <gtristan!~tristanva@175.211.69.194> has joined #yocto | 15:52 | |
| RP | khem: BB_TASKDEPDATA is probably what you want | 15:52 |
| kergoth | alternatively, query the installed packages after the fact and map that to recipes with pkgdata, perhaps? depends on what you're looking for and why | 15:56 |
| *** frsc <frsc!~frsc@i6DFA84A1.versanet.de> has quit IRC | 15:57 | |
| khem | kergoth: I want to know recipe names in a image | 15:58 |
| khem | that i can create a list | 15:58 |
| *** fl0v0 <fl0v0!~fvo@88.130.218.41> has quit IRC | 15:59 | |
| *** rubdos <rubdos!~rubdos@2a02:578:859d:700:8b44:5716:382d:a7da> has quit IRC | 16:03 | |
| *** codusnocturnus <codusnocturnus!~codusnoct@ip68-98-225-84.ph.ph.cox.net> has joined #yocto | 16:05 | |
| *** florian__ <florian__!~florian_k@Maemo/community/contributor/florian> has quit IRC | 16:08 | |
| *** zandrey <zandrey!~zandrey@193.8.40.126> has quit IRC | 16:10 | |
| *** rubdos <rubdos!~rubdos@2a02:578:859d:700:8b44:5716:382d:a7da> has joined #yocto | 16:10 | |
| *** gsalazar <gsalazar!5e3ce511@gateway/web/cgi-irc/kiwiirc.com/ip.94.60.229.17> has quit IRC | 16:18 | |
| *** vicale <vicale!~vicale@dyn-13-cust157.netit.se> has joined #yocto | 16:18 | |
| *** like2wise <like2wise!~Leon@145-132-74-106.fixed.kpn.net> has joined #yocto | 16:20 | |
| *** likewiser <likewiser!~Leon@145-132-74-106.fixed.kpn.net> has quit IRC | 16:22 | |
| *** chris_ber <chris_ber!~quassel@213.138.44.181> has quit IRC | 16:23 | |
| *** geissonator <geissonator!~geissonat@129.41.86.5> has joined #yocto | 16:27 | |
| *** rcw <rcw!~rcw@45.72.241.84> has quit IRC | 16:29 | |
| *** thaytan <thaytan!~thaytan@180-150-69-32.b49645.syd.nbn.aussiebb.net> has joined #yocto | 16:32 | |
| JPEW | fray: Ah, interesting | 16:35 |
| *** likewiser <likewiser!~Leon@145-132-74-106.fixed.kpn.net> has joined #yocto | 16:52 | |
| *** like2wise <like2wise!~Leon@145-132-74-106.fixed.kpn.net> has quit IRC | 16:54 | |
| *** codusnocturnus <codusnocturnus!~codusnoct@ip68-98-225-84.ph.ph.cox.net> has quit IRC | 16:55 | |
| *** vineela <vineela!~vtummala@134.134.139.76> has joined #yocto | 16:55 | |
| *** kaspter <kaspter!~Instantbi@112.65.53.200> has joined #yocto | 17:20 | |
| *** like2wise <like2wise!~Leon@145-132-74-106.fixed.kpn.net> has joined #yocto | 17:25 | |
| *** sstabellini_ <sstabellini_!sstabellin@gateway/shell/xshellz/x-ztcavbaaemlmsyca> has left #yocto | 17:25 | |
| *** likewiser <likewiser!~Leon@145-132-74-106.fixed.kpn.net> has quit IRC | 17:25 | |
| *** rcw <rcw!~rcw@45.72.241.84> has joined #yocto | 17:51 | |
| *** LetoThe2nd <LetoThe2nd!uid453638@gateway/web/irccloud.com/x-hzdwtqvblcymoatp> has quit IRC | 17:52 | |
| *** like2wise <like2wise!~Leon@145-132-74-106.fixed.kpn.net> has quit IRC | 17:59 | |
| *** T_UNIX <T_UNIX!uid218288@gateway/web/irccloud.com/x-bfpclsmyxbkxnwxw> has quit IRC | 18:03 | |
| *** like2wise <like2wise!~Leon@145-132-74-106.fixed.kpn.net> has joined #yocto | 18:05 | |
| *** rcoote <rcoote!~rcoote@221-224-024-217.ip-addr.vsenet.de> has quit IRC | 18:11 | |
| *** codusnocturnus <codusnocturnus!~codusnoct@ip68-98-225-84.ph.ph.cox.net> has joined #yocto | 18:20 | |
| *** adelcast <adelcast!~adelcast@2605:6000:101c:3b5:37f1:578e:8088:a1b4> has joined #yocto | 18:23 | |
| *** robbawebba <robbawebba!~rob@8-3-93-140.starry-inc.net> has joined #yocto | 18:26 | |
| kergoth | fray: nicely done spotting that shlibs ordering issue | 18:27 |
| fray | working on PR serice now.. turn that on and everything rebuilds each time | 18:34 |
| *** like2wise <like2wise!~Leon@145-132-74-106.fixed.kpn.net> has quit IRC | 18:39 | |
| RP | zeddii: " perf: backport a fix for confusing non-fatal error" - do we want to queue/test that or look for other fixes? | 18:39 |
| zeddii | that'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 |
| RP | zeddii: ok, I'll queue it. I just don't want to get shouted at :) | 18:41 |
| armpit | we can queue confusion? | 18:41 |
| RP | armpit: that is permanently on tap these days | 18:42 |
| *** likewise <likewise!~Leon@145-132-74-106.fixed.kpn.net> has joined #yocto | 18:49 | |
| kergoth | hmm, hashserve=auto + multiconfig blows up in connecting/reconnecting/etc to the server | 18:51 |
| kergoth | interesting | 18:51 |
| *** codusnocturnus <codusnocturnus!~codusnoct@ip68-98-225-84.ph.ph.cox.net> has quit IRC | 18:56 | |
| *** kaspter <kaspter!~Instantbi@112.65.53.200> has quit IRC | 18:57 | |
| *** comptroller <comptroller!~comptroll@47-213-220-127.paolcmtc01.res.dyn.suddenlink.net> has joined #yocto | 19:01 | |
| *** roussinm <roussinm!~mroussin@ipagstaticip-d73c7528-4de5-0861-800b-03d8b15e3869.sdsl.bell.ca> has quit IRC | 19:06 | |
| *** roussinm <roussinm!~mroussin@ipagstaticip-d73c7528-4de5-0861-800b-03d8b15e3869.sdsl.bell.ca> has joined #yocto | 19:06 | |
| *** vineela <vineela!~vtummala@134.134.139.76> has quit IRC | 19:08 | |
| *** berton <berton!~berton@181.220.78.182> has joined #yocto | 19:10 | |
| fray | ok, 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 that | 19:17 |
| fray | -PKGR: r0.0 | 19:18 |
| fray | +PKGR: r0.1 | 19:18 |
| roussinm | Does 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. https://hastebin.com/sejikofive.js | 19:20 |
| *** like2wise <like2wise!~Leon@145-132-74-106.fixed.kpn.net> has joined #yocto | 19:21 | |
| fullstop | I think that kernel.bbclass is broken for 5.8+ kernels | 19:21 |
| fray | that sounds like a recipe bug of some kind.. It really shouldn't be different AFAIK | 19:22 |
| zeddii | how so ? I've been building and booting 5.8 for weeks, and just smoke tested 5.9-rc1 this morning | 19:22 |
| fullstop | wait, it's been fixed upstream | 19:22 |
| fullstop | https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/kernel.bbclass#n486 | 19:22 |
| zeddii | ah that one. yah, that was fixed a while ago. | 19:23 |
| fullstop | my version doesn't have [ -e Module.symvers ] | 19:23 |
| *** likewise <likewise!~Leon@145-132-74-106.fixed.kpn.net> has quit IRC | 19:23 | |
| fullstop | I'm on 3.1.1 | 19:23 |
| fullstop | hmm.. now I need to check my branch setup because it should be there. | 19:25 |
| fullstop | oh, need to pull | 19:25 |
| *** thaytan <thaytan!~thaytan@180-150-69-32.b49645.syd.nbn.aussiebb.net> has quit IRC | 19:30 | |
| *** vineela <vineela!~vtummala@134.134.139.76> has joined #yocto | 19:44 | |
| *** likewiser <likewiser!~Leon@145-132-74-106.fixed.kpn.net> has joined #yocto | 19:53 | |
| roussinm | Is 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!~Leon@145-132-74-106.fixed.kpn.net> has quit IRC | 19:55 | |
| fray | JPEW any suggestions how to deal with the pkdata getting PKGR in it, causing the hashes to change? | 20:02 |
| fray | I'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 |
| fray | cause presumably if teh user has changed teh PKGR (other then the auto) they'd want a new package, even if the contents don't chnge | 20:04 |
| fullstop | that awkward moment when one change triggers a much larger rebuild than expected | 20:15 |
| *** comptroller <comptroller!~comptroll@47-213-220-127.paolcmtc01.res.dyn.suddenlink.net> has quit IRC | 20:18 | |
| *** comptroller <comptroller!~comptroll@47-213-220-127.paolcmtc01.res.dyn.suddenlink.net> has joined #yocto | 20:27 | |
| *** thaytan <thaytan!~thaytan@180-150-69-32.b49645.syd.nbn.aussiebb.net> has joined #yocto | 20:37 | |
| *** vineela <vineela!~vtummala@134.134.139.76> has quit IRC | 20:42 | |
| roussinm | It looks like that the path in the sstate-cache objects from the the siggen.py 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 recipe | 20:50 |
| roussinm | name? | 20:50 |
| splatch | one 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 |
| splatch | https://gist.github.com/splatch/7af459c29826048a36b89b8971374206 | 20:56 |
| splatch | to make matter even more interesting.. it works with my local device but fails for customer | 20:57 |
| splatch | how to read the error -71? I know device fails to initialize, but what does it mean? | 20:58 |
| *** Konsgnx <Konsgnx!~Konsgnx3@66-109-34-138.tvc-ip.com> has quit IRC | 21:00 | |
| *** NiksDev <NiksDev!~NiksDev@192.91.101.30> has quit IRC | 21:01 | |
| *** NiksDev <NiksDev!~NiksDev@192.91.75.12> has joined #yocto | 21:01 | |
| *** Sasha62 <Sasha62!a5e1d0b2@165.225.208.178> has quit IRC | 21:06 | |
| JPEW | fray: Ya, is for when the PRServer is used? | 21:12 |
| *** berton <berton!~berton@181.220.78.182> has quit IRC | 21:19 | |
| *** ant__ <ant__!~ant__@host-82-60-190-157.retail.telecomitalia.it> has joined #yocto | 21:28 | |
| *** zandrey <zandrey!~zandrey@cable-static2-2-7.rsnweb.ch> has joined #yocto | 21:39 | |
| *** beneth <beneth!~beneth@irc.beneth.fr> has left #yocto | 21:43 | |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto | 21:46 | |
| robbawebba | Hi, 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: https://patchwork.openembedded.org/patch/162252/ | 21:46 |
| *** matthewzmd <matthewzmd!~user@216-58-109-18.cpe.distributel.net> has quit IRC | 21:48 | |
| robbawebba | here are the errors I'm getting when building mfgtools-native with PKGCONFIG = "static" : https://paste.ubuntu.com/p/TgGFjZth4C/. 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!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC | 21:49 | |
| *** Ad0 <Ad0!~Ad0@93.124.245.194> has quit IRC | 21:54 | |
| zandrey | fbre: 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_IMAGETYPE | 21:55 |
| zandrey | fbre: 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 it | 21:57 |
| *** Ad0 <Ad0!~Ad0@93.124.245.194> has joined #yocto | 22:01 | |
| zandrey | i 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 uncompressed | 22:03 |
| zandrey | kernel just fine. | 22:03 |
| *** matthewzmd <matthewzmd!~user@216-58-109-18.cpe.distributel.net> has joined #yocto | 22:03 | |
| zandrey | hence 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@45.72.241.84> has quit IRC | 22:11 | |
| *** jrdn <jrdn!~jrdn@S010668ff7b6b7383.ok.shawcable.net> has quit IRC | 22:11 | |
| *** agust <agust!~agust@p508b6ab0.dip0.t-ipconnect.de> has quit IRC | 22:30 | |
| mattsm | zandrey: I am- what is your KERNEL_IMAGETYPE and IMAGE_BOOT_FILES | 22:31 |
| zandrey | mattsm: KERNEL_IMAGETYPE = "Image" | 22:32 |
| mattsm | I set my KERNEL_IMAGETYPE to fitImage | 22:32 |
| zandrey | ups, sorry! it is "fitImage", otherwise the fit would not even be built! | 22:32 |
| zandrey | mattsm: 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 |
| mattsm | I'm doing a fit image inside a wic image | 22:34 |
| mattsm | I did have to muck with u-boot, to change the bootcmd (not sure it's done right) BUT I don't have a compressed kernel | 22:35 |
| mattsm | or maybe I do but my bootm inside u-boot is not complaining | 22:35 |
| mattsm | how is it failing to inflate? | 22:36 |
| zandrey | can you check the "compression" field during bootm execution? | 22:36 |
| mattsm | does it try at least or just try to execute a compressed kernel? | 22:36 |
| zandrey | nope, it tries - but gives up with -5... | 22:36 |
| marex | zandrey: during load ? | 22:36 |
| zandrey | marex: yeap, exactly | 22:37 |
| mattsm | Compression: gzip compressed | 22:37 |
| marex | zandrey: like what, bootm fitimageaddr fails somehow ? | 22:37 |
| mattsm | I wonder if you are running out of memory, or something is overwritting something during the uncompress step | 22:37 |
| zandrey | if i disable compression - bootm is happy | 22:37 |
| mattsm | do you have UBOOT_ENTRYPOINT and UBOOT_LOADADDRESS set properly? | 22:38 |
| mattsm | I guess so, if it works without gzip compression | 22:38 |
| zandrey | mattsm: i have 27MB image and 64MB window for bootm configured | 22:39 |
| zandrey | 11MB is the compressed one | 22:39 |
| marex | zandrey: pastebin the full output of your uboot problem, from power on until the failure | 22:39 |
| ant__ | robbawebba, the warning is clear libusb_set_debug(libusb_context*, int) is deprecated | 22:39 |
| marex | zandrey: and pastebin 'env print' output | 22:39 |
| ant__ | see i.e this workaround for another recipe https://patchwork.kernel.org/patch/10324613/ | 22:40 |
| zandrey | marex: 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 |
| zandrey | marex: u-boot version is 2020.04 btw | 22:41 |
| marex | zandrey: which SoC is that btw ? | 22:42 |
| zandrey | imx8mm | 22:42 |
| *** leon-anavi <leon-anavi!~Leon@78.130.197.211> has quit IRC | 22:42 | |
| marex | on 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 arm64 | 22:42 |
| marex | so stop using fdt_high=-1 and replace that with bootm_size | 22:42 |
| marex | then U-Boot will figure the placement out on its own and it will be correct | 22:43 |
| marex | sadly, the nxp bsps are full of this fdt_high and initrd_high misuse | 22:43 |
| marex | the other option is that you placed the kernel at the wrong address | 22:43 |
| marex | iirc per spec the aarch64 Image must be at 2MiB aligned offset | 22:44 |
| marex | so check that too | 22:44 |
| zandrey | marex: spot on! i've just dug out some old logs from the previous boots - indeed the fdt_high is set to -1! | 22:44 |
| zandrey | marex: i would try to fix this also tomorrow and try again! thanks for your tips! ;) | 22:45 |
| marex | zandrey: 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 file | 22:45 |
| marex | and then you run into this, so then you keep re-running mkimage and wonder what is going on | 22:46 |
| marex | zandrey: rcar3 has examples of using bootm_size , so look at that and you should be all good | 22: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 libs | 22:49 |
| zandrey | marex: thanks again - you just gave a lot of materials for digging! :) really appreciate that! | 22:53 |
| marex | sure | 22:54 |
| ant__ | robbawebba, check that you have correctly specified with -L the paths for every .a | 22:58 |
| ant__ | gn | 22:58 |
| *** ant__ <ant__!~ant__@host-82-60-190-157.retail.telecomitalia.it> has quit IRC | 22:58 | |
| khem | robbawebba: you need to install static version of glibc and libstdc++ on your build host | 23:06 |
| *** vineela <vineela!~vtummala@134.134.139.76> has joined #yocto | 23:09 | |
| *** ericch <ericch!~ericch@50-205-235-218-static.hfc.comcastbusiness.net> has quit IRC | 23:15 | |
| *** samvlewis <samvlewis!~samvlewis@45.32.247.239> has quit IRC | 23:17 | |
| *** samvlewis <samvlewis!~samvlewis@45.32.247.239> has joined #yocto | 23:21 | |
| robbawebba | khem: 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!~Leon@145-132-74-106.fixed.kpn.net> has quit IRC | 23:23 | |
| khem | right add native dependencies e.g. bzip2-native etc | 23:44 |
| *** yann <yann!~yann@91-170-159-152.subs.proxad.net> has quit IRC | 23:48 | |
| *** JaMa <JaMa!~martin@ip-109-238-218-228.aim-net.cz> has quit IRC | 23:53 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!