| *** florian_kc <florian_kc!~florian@dynamic-002-243-060-125.2.243.pool.telefonica.de> has quit IRC (Ping timeout: 250 seconds) | 00:36 | |
| *** dev1990 <dev1990!~dev@81.168.185.188> has quit IRC (Quit: Konversation terminated!) | 00:39 | |
| *** dmoseley <dmoseley!~dmoseley@24.96.56.90> has quit IRC (Ping timeout: 240 seconds) | 01:29 | |
| *** dmoseley <dmoseley!~dmoseley@24.96.56.90> has joined #yocto | 01:31 | |
| *** dmoseley <dmoseley!~dmoseley@24.96.56.90> has quit IRC (Ping timeout: 250 seconds) | 01:36 | |
| *** dmoseley <dmoseley!~dmoseley@24.96.56.90> has joined #yocto | 01:37 | |
| *** dmoseley <dmoseley!~dmoseley@24.96.56.90> has quit IRC (Ping timeout: 250 seconds) | 01:41 | |
| *** dmoseley <dmoseley!~dmoseley@24.96.56.90> has joined #yocto | 01:42 | |
| *** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has quit IRC (Quit: Leaving.) | 01:44 | |
| *** camus <camus!~Instantbi@58.246.136.202> has joined #yocto | 02:09 | |
| *** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has joined #yocto | 02:39 | |
| *** marka <marka!~marka@198-84-181-245.cpe.teksavvy.com> has quit IRC (Quit: ZNC 1.8.2 - https://znc.in) | 02:53 | |
| *** geoff__ <geoff__!~geoff@cpe-107-185-48-203.socal.res.rr.com> has quit IRC (Quit: Leaving) | 03:20 | |
| *** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has quit IRC (Remote host closed the connection) | 03:28 | |
| *** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has joined #yocto | 03:28 | |
| *** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has quit IRC (Ping timeout: 240 seconds) | 03:44 | |
| *** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has joined #yocto | 04:55 | |
| *** wooosaiiii <wooosaiiii!~wooo@89-212-21-243.static.t-2.net> has quit IRC (Remote host closed the connection) | 05:01 | |
| *** wooosaii <wooosaii!~wooo@89-212-21-243.static.t-2.net> has quit IRC (Remote host closed the connection) | 05:01 | |
| *** wooosaiiii <wooosaiiii!~wooo@89-212-21-243.static.t-2.net> has joined #yocto | 05:02 | |
| *** wooosaii <wooosaii!~wooo@89-212-21-243.static.t-2.net> has joined #yocto | 05:02 | |
| *** marka <marka!~marka@198-84-181-245.cpe.teksavvy.com> has joined #yocto | 05:05 | |
| *** amitk <amitk!~amit@103.208.71.109> has joined #yocto | 05:22 | |
| *** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has quit IRC (Quit: jmiehe) | 05:24 | |
| *** goliath <goliath!~goliath@user/goliath> has joined #yocto | 05:29 | |
| *** ziga_ <ziga_!~ziga@89-212-219-192.dynamic.t-2.net> has joined #yocto | 05:55 | |
| *** ziga_ <ziga_!~ziga@89-212-219-192.dynamic.t-2.net> has quit IRC (Read error: Connection reset by peer) | 05:58 | |
| *** huseyinkozan <huseyinkozan!~hk@31.223.46.173> has joined #yocto | 06:08 | |
| *** djsands <djsands!~djsands@tel3187236.lnk.telstra.net> has quit IRC (Quit: Client closed) | 06:23 | |
| *** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has quit IRC (Ping timeout: 276 seconds) | 06:46 | |
| *** kroon <kroon!~kroon@37-247-29-68.customers.ownit.se> has joined #yocto | 06:54 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto | 07:04 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has quit IRC (Client Quit) | 07:08 | |
| *** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has joined #yocto | 07:12 | |
| *** rob_w <rob_w!~bob@host-82-135-31-73.customer.m-online.net> has joined #yocto | 07:20 | |
| coldspark29[m] | Morning | 07:20 |
|---|---|---|
| coldspark29[m] | What is the difference between linux-imx and linux-fslc? It is not clear to me | 07:20 |
| kroon | coldspark29[m], check the SUMMARY/DESCRIPTION for the corresponding recipes | 07:30 |
| coldspark29[m] | So linux-fslc is community and linux-imx is from NXP. Does linux-fslc have graphics support? | 07:33 |
| *** mckoan|away is now known as mckoan | 07:44 | |
| mckoan | good morning | 07:45 |
| mckoan | coldspark29[m]: linux-fslc has graphics support as well | 07:47 |
| mckoan | coldspark29[m]: we usually use only linux-fslc | 07:48 |
| mckoan | coldspark29[m]: but actually depends on your vendor BSP | 07:48 |
| coldspark29[m] | We have our custom board based on an imx8mm | 07:49 |
| coldspark29[m] | s/imx8mm/imx8/ | 07:49 |
| *** kroon <kroon!~kroon@37-247-29-68.customers.ownit.se> has quit IRC (Quit: Leaving) | 07:53 | |
| *** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has joined #yocto | 07:54 | |
| coldspark29[m] | On gatesgarth we based it on the official imx8mm configuration and that worked | 07:55 |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has joined #yocto | 07:59 | |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has quit IRC (Ping timeout: 240 seconds) | 08:08 | |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has joined #yocto | 08:08 | |
| *** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has quit IRC (Quit: Leaving) | 08:12 | |
| *** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has joined #yocto | 08:12 | |
| *** leon-anavi <leon-anavi!~Leon@46.55.231.62> has joined #yocto | 08:16 | |
| *** gsalazar <gsalazar!~gsalazar@161.230.168.194> has joined #yocto | 08:22 | |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has quit IRC (Ping timeout: 240 seconds) | 08:22 | |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has joined #yocto | 08:23 | |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has quit IRC (Ping timeout: 240 seconds) | 08:27 | |
| *** dev1990 <dev1990!~dev@81.168.185.188> has joined #yocto | 08:27 | |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has joined #yocto | 08:28 | |
| *** Schlumpf <Schlumpf!~Schlumpf@62.157.232.203> has joined #yocto | 08:32 | |
| *** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has joined #yocto | 08:45 | |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has quit IRC (Ping timeout: 240 seconds) | 08:48 | |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has joined #yocto | 08:49 | |
| coldspark29[m] | qschulz: Why does kas not automatically fetch new commits from the layers? I always have to delete the layer and run kas checkout again | 09:08 |
| *** otavio_ <otavio_!~otavio@201-34-65-230.user3p.brasiltelecom.net.br> has joined #yocto | 09:10 | |
| *** otavio <otavio!~otavio@201-34-65-230.user3p.brasiltelecom.net.br> has quit IRC (Read error: Connection reset by peer) | 09:10 | |
| qschulz | coldspark29[m]: I don't have this problem as I use commit hashes and not branch names | 09:24 |
| coldspark29[m] | qschulz: I thought so. It is a pity that this isn't possible | 09:35 |
| coldspark29[m] | Does bitbake not support Gitlab btw? I am getting a fetcher failure, which I can't seem to solve | 09:36 |
| qschulz | bitbake perfectly supports gitlab | 09:37 |
| qschulz | we need more info to be able to help | 09:37 |
| coldspark29[m] | I am getting a fetcher failure... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/79bdf5368c9c68f7a848d53c9c8e9eb0b8f41bac) | 09:41 |
| coldspark29[m] | I do have the right ssh keys and can perfectly check it out manually | 09:41 |
| coldspark29[m] | * I am getting a fetcher failure... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/c0646d25fc05c20ef7e800952da24b2a79da016c) | 09:42 |
| coldspark29[m] | First I was changing the @ from git@gitlab to git://gitlab, but I don't know what else to change | 09:43 |
| coldspark29[m] | I just exchanged the Gerrit repository with the one from Gitlab. That is all | 09:44 |
| qschulz | coldspark29[m]: it's a slash and not a colon between the url and the repo IIRC | 09:47 |
| qschulz | before vti-basesystem | 09:47 |
| coldspark29[m] | I already tried that and in fact it isn't | 09:48 |
| coldspark29[m] | This is the link I get from Gitlab git@scm-ih-02.custom.de:mymachine-basesystem/meta-custom.git | 09:49 |
| coldspark29[m] | when I click on clone and copy paste the link | 09:49 |
| hmw[m] | Hi, i think i mis somthing in my distro im getting no key input in the qt application ( qt.qpa.wayland: xkbcommon not available on this build, not performing key mapping) | 09:50 |
| qschulz | coldspark29[m]: the URL you get from gitlab with ssh protocol is not the one you should put in SRC_URI | 09:51 |
| qschulz | Replace : by / | 09:51 |
| coldspark29[m] | I tried that and it doesn't work | 09:52 |
| coldspark29[m] | and bitbake should be able to use the one I get from Gitlab imo | 09:52 |
| qschulz | https://git.yoctoproject.org/poky/tree/scripts/lib/recipetool/create.py#n374 | 09:52 |
| qschulz | that's not exactly the code Bitbake is using but it gives you a reason for that | 09:53 |
| qschulz | coldspark29[m]: is your browser able to deal with that kind of URL? | 09:53 |
| qschulz | I don't think so, because it isn't a URL :) | 09:53 |
| qschulz | : usually splits domain name and port | 09:53 |
| qschulz | I'm not saying it cannot be done, I'm just explaining why it is currently like this (or at least the reason I see) | 09:54 |
| coldspark29[m] | qschulz: No, because the protocol is ssh | 09:54 |
| coldspark29[m] | I hear you but it still doesn't work with those fixes | 09:55 |
| coldspark29[m] | I tried everything. Exchanging @ for ://, : for / and removing the .git at the end | 09:55 |
| qschulz | coldspark29[m]: are you building with kas-container? | 09:56 |
| coldspark29[m] | s/for/with/, s/for/with/ | 09:56 |
| coldspark29[m] | No Pyrex | 09:56 |
| coldspark29[m] | But both have the same outcome | 09:56 |
| qschulz | git://gitlab.com/you/yourproject.git;protocol=ssh is what's it's suypposed to be | 09:57 |
| qschulz | yeah but they are building in a container | 09:57 |
| *** frieder <frieder!~frieder@i4DF677E2.static.tripleplugandplay.com> has joined #yocto | 09:58 | |
| qschulz | so yourssh-agent needs to be running and passed to the container | 09:58 |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has quit IRC (Ping timeout: 256 seconds) | 09:58 | |
| qschulz | coldspark29[m]: SSH_AUTH_SOCK | 09:58 |
| qschulz | env variable that needs to be passed to Pyrex (see pyrex.ini I think) | 09:59 |
| coldspark29[m] | I already did that | 09:59 |
| coldspark29[m] | That was also necessary when the repo was still on Gerrit | 10:00 |
| qschulz | true | 10:00 |
| *** frieder <frieder!~frieder@i4DF677E2.static.tripleplugandplay.com> has quit IRC (Remote host closed the connection) | 10:00 | |
| coldspark29[m] | Ah actually no | 10:01 |
| coldspark29[m] | I was just binding the .ssh directory | 10:01 |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has joined #yocto | 10:01 | |
| coldspark29[m] | But well the same error occurs | 10:02 |
| coldspark29[m] | Just tried it | 10:02 |
| qschulz | otherwise, it seems you can enter the Pyrex container by running pyrex-shell and try git clone of your gitlab repo there just to make sure it isn't an issue with the keys | 10:02 |
| *** dlan <dlan!~dennis@gentoo/developer/dlan> has quit IRC (Remote host closed the connection) | 10:02 | |
| *** frieder <frieder!~frieder@i4DF677E2.static.tripleplugandplay.com> has joined #yocto | 10:03 | |
| coldspark29[m] | No issue there | 10:04 |
| *** kanavin <kanavin!~Alexander@2a02:2454:29b:3b00:d35d:e3cf:58b5:748b> has quit IRC (Remote host closed the connection) | 10:05 | |
| qschulz | what's your SRC_URI now? | 10:05 |
| qschulz | FYI, mounting .ssh in containers is not a good practice security wise | 10:07 |
| qschulz | hence the use of SSH_AUTH_SOCK instead | 10:07 |
| qschulz | which forwards the SSH agent without having the private key (and authorized_keys, known_hosts et al) in the container | 10:08 |
| *** kanavin <kanavin!~Alexander@2a02:2454:29b:3b00:d35d:e3cf:58b5:748b> has joined #yocto | 10:09 | |
| *** frieder <frieder!~frieder@i4DF677E2.static.tripleplugandplay.com> has quit IRC (Remote host closed the connection) | 10:11 | |
| *** frieder <frieder!~frieder@i4DF677E2.static.tripleplugandplay.com> has joined #yocto | 10:11 | |
| coldspark29[m] | Do you just uncomment SSH_AUTH_SOCK? | 10:17 |
| coldspark29[m] | SRC_URI = "git://our.company.de/mymachine-basesystem/linux-imx.git;protocol=ssh;branch=${SRCBRANCH}" | 10:18 |
| coldspark29[m] | coldspark29[m]: Yeah I guess... | 10:20 |
| qschulz | and envvars= I assume | 10:22 |
| *** dlan <dlan!~dennis@gentoo/developer/dlan> has joined #yocto | 10:22 | |
| ad__ | hi, on dunfell, i cannot see separate rootfs files before the image is created. Is ther ean option to allow this ? | 10:24 |
| qschulz | and envsockproxy I assume coldspark29[m] | 10:31 |
| qschulz | ad__: not sure to understand the question. What do you want to do exactly? | 10:31 |
| coldspark29[m] | Yeah, it doesn't work. Maybe something is wrong with our local Gitlab server. | 10:37 |
| qschulz | coldspark29[m]: which distribution are you using currently on your desktop/ | 10:40 |
| coldspark29[m] | Ubuntu | 10:41 |
| qschulz | what I could suggest is to ditch pyrex for a moment and build directly from your system. | 10:41 |
| qschulz | by using master poky for example | 10:41 |
| coldspark29[m] | So use kas build? | 10:41 |
| qschulz | and just run bitbake -c fetch your-recipe | 10:41 |
| qschulz | until you get it working | 10:41 |
| qschulz | at least we'd know it's not something weird with bitbake+containers | 10:41 |
| coldspark29[m] | kas builds on the host, doesn't it? | 10:42 |
| qschulz | use bitbake directly, i.e. source oe-init=build-env ../build from the poky git repo | 10:42 |
| qschulz | the less tools in play, the better | 10:42 |
| coldspark29[m] | Same issue on the host | 10:44 |
| coldspark29[m] | It is not a Pyrex issue | 10:44 |
| qschulz | coldspark29[m]: wait | 10:47 |
| qschulz | no I don't know | 10:49 |
| coldspark29[m] | Yeah me neither | 10:50 |
| coldspark29[m] | What an awful week already :D | 10:50 |
| qschulz | also, not sure it's really worth putting a kernel behind ssh auth since it's all open-source but eh :) | 10:51 |
| coldspark29[m] | Yeah I know | 10:52 |
| coldspark29[m] | My colleague thinks it is easier to host the kernel ourselves and just commit our patches | 10:52 |
| coldspark29[m] | Plus they want to be able to build in case the network should be down | 10:53 |
| coldspark29[m] | Like that ever happens... | 10:53 |
| * qschulz coughs upstream coughs the coughs patches | 10:53 | |
| *** kroon <kroon!~kroon@37-247-29-68.customers.ownit.se> has joined #yocto | 10:53 | |
| ad__ | qschulz: in some yocto version i can see all the target rootfs files in a specific dictory, actually in this dunfell not. Maybe it get deleted after packing ext4 image ? | 10:53 |
| qschulz | but yeah it's extremly common to have fork of the Linux kernel | 10:53 |
| qschulz | if the network being down is an issue, just host a PRE_MIRROR on your premises and you're done with this problem | 10:54 |
| coldspark29[m] | Which would fail in this case :P | 10:55 |
| qschulz | ad__: do you have INHERIT rm_work in your local.conf? otherwise, I think it might be in tmp/work/<machine>/<image-name> | 10:55 |
| qschulz | coldspark29[m]: what would fail? | 10:55 |
| *** florian_kc <florian_kc!~florian@port-217-146-132-69.static.as20676.net> has joined #yocto | 10:55 | |
| coldspark29[m] | The PREMIRROR source | 10:56 |
| coldspark29[m] | Being our Gitlab server | 10:56 |
| qschulz | ad__: yocto/build/tmp/work/puma_haikou-poky-linux/core-image-minimal/1.0-r0/rootfs is where's mine | 10:56 |
| coldspark29[m] | '!"§'gmrl"!)&%§= | 10:56 |
| coldspark29[m] | which is anger expressed in pre-emoji times | 10:57 |
| qschulz | coldspark29[m]: no no no, the PREMIRROR is an HTTP server serving the tarball you have in your build/downloads | 10:57 |
| qschulz | and it'll ask this PREMIRROR server first before going for the upstream URL | 10:57 |
| qschulz | if your company is going to do a lot of CI, I would highly recmomend looking into hosting your own PREMIRROR and a SSTATE_MIRROR | 10:58 |
| coldspark29[m] | But you can't push to repos checked out with http | 10:58 |
| qschulz | coldspark29[m]: yocto does not push to repo, it's read-only | 10:58 |
| coldspark29[m] | CI? | 10:58 |
| qschulz | continuous intgegration | 10:58 |
| coldspark29[m] | Yeah, but first things first. I can't even build this bloody honister release | 10:59 |
| qschulz | basically building automatically your images/distros for you (and ideally testing them right after) | 10:59 |
| qschulz | sure | 10:59 |
| coldspark29[m] | So frustrating | 10:59 |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has quit IRC (Ping timeout: 256 seconds) | 11:03 | |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has joined #yocto | 11:03 | |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has quit IRC (Ping timeout: 240 seconds) | 11:08 | |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has joined #yocto | 11:08 | |
| *** pgowda_ <pgowda_!uid516182@id-516182.ilkley.irccloud.com> has joined #yocto | 11:12 | |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has quit IRC (Ping timeout: 240 seconds) | 11:13 | |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has joined #yocto | 11:13 | |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has quit IRC (Ping timeout: 256 seconds) | 11:17 | |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has joined #yocto | 11:18 | |
| rburton | RP: vim and lighttpd cve fixes sent | 11:21 |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has quit IRC (Ping timeout: 240 seconds) | 11:33 | |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has joined #yocto | 11:33 | |
| *** florian_kc <florian_kc!~florian@port-217-146-132-69.static.as20676.net> has quit IRC (Ping timeout: 250 seconds) | 11:35 | |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has quit IRC (Ping timeout: 240 seconds) | 11:37 | |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has joined #yocto | 11:37 | |
| RP | rburton: awesome, thanks :) | 11:46 |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has quit IRC (Ping timeout: 240 seconds) | 11:57 | |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has joined #yocto | 11:57 | |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has quit IRC (Ping timeout: 240 seconds) | 12:02 | |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has joined #yocto | 12:02 | |
| rburton | zeddii: 99% sure you broke python3-dtc | 12:04 |
| rburton | (100% sure0 | 12:05 |
| RP | rburton: clearly we need better tests :/ | 12:08 |
| rburton | the 'port to setuptools' result in do packaging happening | 12:08 |
| rburton | s/do/no/ | 12:09 |
| coldspark29[m] | @qschulz It is git://git@gitlab.com/project/repo.git | 12:09 |
| coldspark29[m] | It worked from the host like this | 12:09 |
| coldspark29[m] | Now that it has fetched, it doesn't fetch again. Is there a way to force the refetch to test it for Pyrex as well? | 12:10 |
| *** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Ping timeout: 250 seconds) | 12:11 | |
| *** camus1 <camus1!~Instantbi@58.246.136.202> has joined #yocto | 12:12 | |
| *** davidinux <davidinux!~davidinux@37.120.201.222> has quit IRC (Quit: WeeChat 2.8) | 12:13 | |
| *** camus1 is now known as camus | 12:14 | |
| coldspark29[m] | I tried `clean` and `cleansstate` without success | 12:19 |
| qschulz | coldspark29[m]: -c fetch -f (note that any task run with -f will require a cleansstate at one point int time) | 12:22 |
| qschulz | coldspark29[m]: otherwise, -c cleanall IIRC | 12:22 |
| coldspark29[m] | Yep that worked | 12:28 |
| coldspark29[m] | and fetching only works if I bind the .ssh directory. SSH_AUTH_SOCK is not sufficient | 12:28 |
| coldspark29[m] | which is insecure you said | 12:29 |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has quit IRC (Ping timeout: 240 seconds) | 12:31 | |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has joined #yocto | 12:32 | |
| *** davidinux <davidinux!~davidinux@37.120.201.222> has joined #yocto | 12:35 | |
| *** otavio_ <otavio_!~otavio@201-34-65-230.user3p.brasiltelecom.net.br> has quit IRC (Remote host closed the connection) | 12:36 | |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has quit IRC (Ping timeout: 240 seconds) | 12:36 | |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has joined #yocto | 12:37 | |
| qschulz | coldspark29[m]: from within containers, run `ssh-add -l`. If a pubkey is not returned, you need to fiddle with things | 12:43 |
| coldspark29[m] | qschulz: That is too complicated. I will just bind the .ssh container from now. We are in our own network anyway and it is readonly | 12:44 |
| coldspark29[m] | Pyrex really loses its charm if you have to fiddle with things inside the container. | 12:45 |
| coldspark29[m] | Any other idea here @JPEW? | 12:48 |
| coldspark29[m] | s/Any other idea here @JPEW?/Any other idea here JPEW ?/ | 12:48 |
| *** Schlumpf <Schlumpf!~Schlumpf@62.157.232.203> has quit IRC (Quit: Client closed) | 12:53 | |
| *** otavio <otavio!~otavio@201-34-65-230.user3p.brasiltelecom.net.br> has joined #yocto | 12:55 | |
| *** Saur <Saur!~pkj@proxy01.se.axis.com> has joined #yocto | 12:56 | |
| qschulz | coldspark29[m]: mmmm, I did mount read-only ~/.ssh/known_hosts. I think otherwise it complains .ssh/known_hosts does not exist when trying to add your gitlab server to it. While when it's mounted RO, it just fails to write to it but does not fail the build. But that's very vague recollection from months ago | 12:58 |
| qschulz | I haven't used Pyrex for a while now | 12:58 |
| *** oberonc <oberonc!~oberonc@109-186-99-217.bb.netvision.net.il> has joined #yocto | 12:58 | |
| qschulz | also, it's very likely your host distribution is compatible with honister branch. I am on fedora35 and I don't build inside container locally | 12:58 |
| oberonc | Gםא איןד קררםר וגרןמע נןאנשלק: | 12:58 |
| oberonc | kernel-image-bzimage-5.10.63-yocto-standard-5.10.63+git0+e0147386e9_c4f9e689da-r0.intel_x86_64: sha256 check failed: 6386446dea6133df79e77296ec5862eb2173735f6f3d3287711e26c3c37ebdc9 vs cecfb00ba16f5925ec58da8cf7e2e59e668015263fc696c72c71730a9cbcaaf7 | 12:59 |
| oberonc | Package "kernel-image-bzimage-5.10.63-yocto-standard-5.10.63+git0+e0147386e9_c4f9e689da-r0.intel_x86_64" from local repository "oe-repo" has incorrect checksum | 12:59 |
| oberonc | Error: Some packages from local repository have incorrect checksum | 12:59 |
| oberonc | -> Got this error during 'bitbake': | 12:59 |
| oberonc | something to do with the git repository ? | 12:59 |
| oberonc | how can I solve this ? | 13:00 |
| coldspark29[m] | qschulz: It is, but I don't like to see warnings | 13:00 |
| qschulz | you can mount it read-write too if you want | 13:03 |
| coldspark29[m] | Yeah I guess | 13:04 |
| *** gsalazar_ <gsalazar_!~gsalazar@194.38.148.130> has joined #yocto | 13:24 | |
| *** gsalazar <gsalazar!~gsalazar@161.230.168.194> has quit IRC (Ping timeout: 240 seconds) | 13:26 | |
| zeddii | rburton: hah. I had that same fix, but I was just switching to a new SRCREV to pick it up. | 13:34 |
| rburton | they need to get on and make a new release | 13:38 |
| *** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has joined #yocto | 13:38 | |
| zeddii | maybe, the pypi stuff rob is doing is likely slowing things down. | 13:39 |
| rburton | zeddii: how far are you bumping the SRCREV? | 13:41 |
| rburton | go enough and they move setup.py to another directory and you'll have the same problem again | 13:41 |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has quit IRC (Ping timeout: 256 seconds) | 13:41 | |
| zeddii | to the tip. one from early jan, IIRC. I was adapting to it over the weekend, when I did a build on a new machine and my old dtc wasn't around to save the day. | 13:41 |
| zeddii | not sure what happened on my main builder, it is not taking 5 minutes to clean dtc so I can test. | 13:42 |
| zeddii | s/not/now | 13:42 |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has joined #yocto | 13:42 | |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has quit IRC (Ping timeout: 256 seconds) | 13:47 | |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has joined #yocto | 13:48 | |
| rburton | clean is overrated | 13:49 |
| *** ar__ <ar__!~akiCA@user/akica> has joined #yocto | 13:49 | |
| rburton | i have a mini script builddifftron, git checkout sha1 ; bitbake foo ; git checkout sha2; bitbake foo; buildhistory-diff. Useful for stuff like 'builddifftron master featurebranch image-recipe' | 13:50 |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has quit IRC (Ping timeout: 240 seconds) | 13:52 | |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has joined #yocto | 13:53 | |
| JPEW | coldspark29[m]: SSH_AUTH_SOCK is supposed to work, iirc, but we don't it's it so it's possible it got broken. We just bind in .ssh. | 13:55 |
| JPEW | Holiday here, so I'm afk and can't check right now | 13:55 |
| *** Schlumpf <Schlumpf!~Schlumpf@62.157.232.203> has joined #yocto | 13:57 | |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has quit IRC (Ping timeout: 240 seconds) | 13:57 | |
| RP | who is cancelling my builds on the autobuilder? :/ | 13:57 |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has joined #yocto | 13:58 | |
| *** Thorn <Thorn!~Thorn@user/thorn> has quit IRC (Remote host closed the connection) | 13:58 | |
| *** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has joined #yocto | 14:00 | |
| *** camus1 <camus1!~Instantbi@58.246.136.202> has joined #yocto | 14:01 | |
| *** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Ping timeout: 256 seconds) | 14:01 | |
| *** camus1 is now known as camus | 14:01 | |
| *** gsalazar_ is now known as gsalazar | 14:02 | |
| *** gsalazar <gsalazar!~gsalazar@194.38.148.130> has quit IRC (Quit: Leaving) | 14:02 | |
| *** gsalazar <gsalazar!~gsalazar@194.38.148.130> has joined #yocto | 14:03 | |
| coldspark29[m] | <JPEW> "Holiday here, so I'm afk and can..." <- Alright thank your for answering then. Enjoy your holidays! | 14:11 |
| *** kroon <kroon!~kroon@37-247-29-68.customers.ownit.se> has quit IRC (Quit: Leaving) | 14:12 | |
| coldspark29[m] | Does anyone have an idea what this means? Corrupted sstate-cache? Has happened quite frequenctly lately... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/69add98992744e6c81bf614069a1c3d1843db30e) | 14:12 |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has quit IRC (Ping timeout: 256 seconds) | 14:13 | |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has joined #yocto | 14:14 | |
| *** codavi <codavi!~akiCA@user/akica> has joined #yocto | 14:15 | |
| coldspark29[m] | Only solution is to delete the tmp directory and start over so far | 14:17 |
| *** ar__ <ar__!~akiCA@user/akica> has quit IRC (Ping timeout: 250 seconds) | 14:18 | |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has quit IRC (Ping timeout: 256 seconds) | 14:18 | |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has joined #yocto | 14:18 | |
| *** jatedev <jatedev!~jatedev@63.148.217.19> has joined #yocto | 14:19 | |
| rburton | coldspark29[m]: is the sstate on a 'normal' filesystem? | 14:20 |
| rburton | or are you doing something like having recipes with : in their name | 14:21 |
| coldspark29[m] | ext4 | 14:21 |
| rburton | a good start would be to catch the valueerror and print out f | 14:21 |
| rburton | figure out what the bad input is | 14:21 |
| *** ilunev <ilunev!~koolkhel@80.72.17.178> has joined #yocto | 14:21 | |
| coldspark29[m] | rburton: Well, I am on honister so I was figuring this has something to do with the override syntax script I used. The one that you showed me | 14:22 |
| coldspark29[m] | rburton: How? | 14:22 |
| coldspark29[m] | -DDD ? | 14:22 |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has quit IRC (Ping timeout: 240 seconds) | 14:23 | |
| coldspark29[m] | The other weird thing is that there doesn't seem to be a pattern. You can run the command and build successfully the first time. Then when you run again, without having changed anything, this happens. | 14:23 |
| coldspark29[m] | So it's trying to split a filename by : | 14:27 |
| coldspark29[m] | Guess something went wrong porting to honister | 14:28 |
| coldspark29[m] | Or the sstate-cache from gatesgarth is not compatbile with the new syntax | 14:28 |
| qschulz | coldspark29[m]: sstate-caches from different versions aren't mixed so that shouldn't be possible | 14:29 |
| coldspark29[m] | Okay, so I will hold back my delete impulse | 14:30 |
| coldspark29[m] | But how to debug this | 14:30 |
| coldspark29[m] | How can I catch the value it is processing | 14:31 |
| qschulz | you add what rburton is suggesting in the python scripts of bitbake I assume | 14:31 |
| rburton | yeah, find out what it is splitting | 14:32 |
| *** alimon <alimon!~alimon@2806:10b7:3:1a01:2c32:cfff:fe8e:de1f> has joined #yocto | 14:33 | |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has joined #yocto | 14:35 | |
| coldspark29[m] | How? | 14:36 |
| coldspark29[m] | Ah you mean just print the value. Sure | 14:37 |
| coldspark29[m] | The printed value doesn't land in the shell | 14:41 |
| coldspark29[m] | :q | 14:42 |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has quit IRC (Ping timeout: 240 seconds) | 14:47 | |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has joined #yocto | 14:48 | |
| coldspark29[m] | I am going to delete everything now. This is too annoying | 14:48 |
| kanavin | RP: I guess it was me, they were hanging for something like 16 hours or more | 14:53 |
| kanavin | qemuarm-ltp is particularly not doing well lately | 14:53 |
| kanavin | they were all almost complete, except for one hanging job | 14:55 |
| RP | kanavin: could you at least ask before you do that? We really need to go and debug these which is why I'd left it around | 14:57 |
| kanavin | I will, apologies. Typically no one pays attention to those and arm workers get blocked :-/ | 14:58 |
| RP | kanavin: right, but someone needs to dive and and work out what the issue is :( | 14:59 |
| kanavin | RP: I have an update patchbomb upcoming, so if anything hangs there, I'll look at it. | 15:00 |
| vd | is it a bad idea to derive multiple distro configs (requiring a common one) to isolate build profiles, rather than managing and switching between multiple local.conf? | 15:00 |
| kanavin | RP: https://git.yoctoproject.org/poky-contrib/log/?h=akanavin/package-version-updates | 15:00 |
| kanavin | this should roll up our update backlog nicely | 15:00 |
| qschulz | vd: local.conf should be local to the dev/build machine. Typically variables such as SSTATE_DIR or DL_DIR in there for example. Ideally, it should be left untouched from the moment you source oe-init-buildenv. Might want to add DISTRO= and MACHINE= in it but I don't put anything else than the mentioned variables in local.conf | 15:02 |
| *** Konsgn <Konsgn!~Konsgn@user/Konsgn> has joined #yocto | 15:02 | |
| rburton | coldspark29[m]: bb.error() will write it to the console | 15:03 |
| Konsgn | Hi All, How would one modify u-boot so it doesn't load the am335x-pocketbeagle.dtb file? I see the findfdt script, but not where in the u-boot it is instantiate | 15:04 |
| Konsgn | working off of bbb-meta | 15:05 |
| vd | qschulz: here's my concern. I need multiple variants of my builds, developer, customer-branded, etc. The "classic" yocto way would be to set a few variables in the local.conf. But it seems messy when you need to build multiple variants like this at the same time. Having for example a foo-dev variant of the main distro seemed ideal so you could build a common image with MACHINE=bar | 15:06 |
| vd | DISTRO=foo-customer1. | 15:06 |
| kergoth | That doesn't seem unreasonable | 15:08 |
| qschulz | you probably would need to feedle with the default PACKAGE_ARCH value I guess | 15:09 |
| qschulz | fiddle? | 15:09 |
| qschulz | eh, english's hard | 15:09 |
| qschulz | and make use of DISTROOVERRIDES mechanism too probably | 15:09 |
| vd | Having multiple image can be an option too, but with complex images (like embedded images), it creates a lot of duplicate rather than relying on a fixed set of image names. | 15:09 |
| qschulz | biggest benefit of using images instead of distros is that you can build them all at the same time with only one bitbake command | 15:10 |
| *** rob_w <rob_w!~bob@host-82-135-31-73.customer.m-online.net> has quit IRC (Quit: Leaving) | 15:10 | |
| vd | true | 15:11 |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has quit IRC (Ping timeout: 256 seconds) | 15:12 | |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has joined #yocto | 15:13 | |
| vd | I guess I must try to make it work with multiple images and find a way to avoid too much duplication. | 15:14 |
| kergoth | qschulz, vd: multiconfig is an option with multiple distros, though depending on the exactly configurations being changed you might also need to separate TMPDIR to be per-multiconfig | 15:14 |
| kergoth | but that would give you the single bitbake command | 15:15 |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has quit IRC (Ping timeout: 240 seconds) | 15:17 | |
| qschulz | kergoth: isn't it technically abusing multiconfig? | 15:18 |
| vd | kergoth: true. I dropped the idea of multiconfig because I figured out SSTATE wasn't shared between them and multiconfig even though they are a cool feature, must be ideally used only for embedded different config into one another. Abusing them only for parallel builds doesn't seem like a good idea | 15:18 |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has joined #yocto | 15:18 | |
| kergoth | I don't believe that's the case, and the purpose is to build multiple configurations at once, how that's utilized is entirely up to you, i wouldn't consider using it to build multiple configs an abuse, that's literally the name :) | 15:19 |
| kergoth | Also some external tooling specifically utilizes it for multiple machines and config sets, see garmin's whisk for example (https://github.com/garmin/whisk) | 15:20 |
| *** leonanavi <leonanavi!~Leon@46.55.231.62> has joined #yocto | 15:20 | |
| kergoth | Now whether it meets your particular needs is of course a different question, but I don't personally think it's out of scope | 15:21 |
| kergoth | Just my opinion, of course. | 15:22 |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has quit IRC (Ping timeout: 240 seconds) | 15:23 | |
| *** leon-anavi <leon-anavi!~Leon@46.55.231.62> has quit IRC (Ping timeout: 256 seconds) | 15:23 | |
| *** ilunev <ilunev!~koolkhel@80.72.17.178> has quit IRC (Quit: Textual IRC Client: www.textualapp.com) | 15:23 | |
| vd | kergoth: I did believe that for a while. But what about the shared sstate? Isn't it limited with multiconfig? | 15:23 |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has joined #yocto | 15:23 | |
| kergoth | I've seen shared state utilized across multiconfig boundaries, for example native recipes aren't rebuilt when switching from one multiconfig to another, even when they use different tmpdirs. | 15:25 |
| vd | hum ok | 15:25 |
| vd | kergoth: I think the "issue" here is that you may use yocto to simple build an image (or a few), or use it as a "build system framework" to set up a complex build-all-you-need system. The latter brings in the headache regarding multiple distros, tools managing local.conf fragments, many images, etc. | 15:27 |
| vd | Trying to keep things simple in this case is not that easy :-) | 15:27 |
| *** mvlad <mvlad!~mvlad@2a02:2f08:4e02:5400:24d7:51ff:fed6:906d> has joined #yocto | 15:28 | |
| kergoth | I think it's just that the situation *is* complecated, so using yocto to solve it also is :) But the fact that there isn't always a single best *way* to do it adds to confusion at times. The flexibility is both an asset and a liability :) | 15:29 |
| vd | kergoth: exactly. | 15:30 |
| vd | So far I've figured out that the simpler the better, so I will try to stick with a single distro and multiple images, even though it duplicates a lot. | 15:32 |
| qschulz | what is duplicated? | 15:32 |
| Saur | Well, one image recipe can require another, so you might be able to have a base image recipe and then extend it into the actual image recipes you need. | 15:33 |
| qschulz | you can also have classes inherited by image recipes | 15:33 |
| qschulz | but as for all recipes, you cannot impact other recipes from your image recipe | 15:34 |
| *** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has quit IRC (Ping timeout: 240 seconds) | 15:36 | |
| coldspark29[m] | <rburton> "coldspark29: bb.error() will..." <- Thanks | 15:37 |
| *** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has joined #yocto | 15:38 | |
| kayterina[m] | hello. Are 10 minutes a logical time for parsing recipes in a project? | 15:38 |
| qschulz | kayterina[m]: it depends on the build machine and the number of recipes to parse | 15:39 |
| kayterina[m] | it is a big project I suppose, running in docker in wsl. ok. | 15:40 |
| qschulz | I've seen <insert very bad vendor> BSP layer take AGES to parse on a 32c machine | 15:40 |
| Saur | Parsing our 4500 recipes takes 45 seconds on my machine (8 cores with HT) | 15:40 |
| qschulz | yeah 10min seems a lot but depends on the machine | 15:41 |
| *** manuel1985 <manuel1985!~manuel198@62.99.131.178> has joined #yocto | 15:41 | |
| kayterina[m] | i7-4600U CPU, with 8gb ram given to the wsl. | 15:42 |
| qschulz | although, parsing should get faster overtime since it's cached | 15:42 |
| *** oberonc <oberonc!~oberonc@109-186-99-217.bb.netvision.net.il> has quit IRC (Quit: Client closed) | 15:43 | |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has quit IRC (Ping timeout: 256 seconds) | 15:46 | |
| rburton | more ram would be nice, and worst case if the layer is using autorev or similar it will be doing network operations during the parse, which can really slow things down | 15:47 |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has joined #yocto | 15:47 | |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has quit IRC (Ping timeout: 240 seconds) | 15:52 | |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has joined #yocto | 15:52 | |
| vd | kergoth: qschulz: well quick shower and kergoth is right once again, multiconfigs aren't abusing the build system. In fact tools like kas wrapping local.conf fragments in yaml are. I can keep one distro, a fixed set of default images, and a few conf/multiconfig/<customerX>.conf files appending TMPDIR/DEPLOY_DIR with "/${BB_CURRENT_MC}" and including tweaks for branding. | 15:58 |
| *** manuel1985 <manuel1985!~manuel198@62.99.131.178> has quit IRC (Quit: Leaving) | 16:03 | |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has quit IRC (Ping timeout: 240 seconds) | 16:03 | |
| qschulz | vd: I meant using multiconfig for building effectively multiple flavors of something for the same board. In my mind, multiconfig is for systems with two or more OS running on the same target | 16:04 |
| qschulz | e.g. Cortex-A + Cortex-M | 16:04 |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has joined #yocto | 16:04 | |
| vd | qschulz: true, but not necessarily | 16:06 |
| vd | I see it as a clean way to store fixed build configs, rather than documenting local.conf snippets in a README | 16:07 |
| *** Schlumpf <Schlumpf!~Schlumpf@62.157.232.203> has quit IRC (Quit: Client closed) | 16:09 | |
| *** marc1 <marc1!~marc@ipagstaticip-ad9375f2-382c-b511-8ac1-9541f69fe50f.sdsl.bell.ca> has quit IRC (Read error: Connection reset by peer) | 16:19 | |
| *** frieder <frieder!~frieder@i4DF677E2.static.tripleplugandplay.com> has quit IRC (Remote host closed the connection) | 16:26 | |
| kergoth | I think both are viable use cases for it, but depends on your needs | 16:26 |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has quit IRC (Ping timeout: 256 seconds) | 16:32 | |
| *** pgowda_ <pgowda_!uid516182@id-516182.ilkley.irccloud.com> has quit IRC (Quit: Connection closed for inactivity) | 16:32 | |
| *** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has quit IRC (Quit: Client closed) | 16:32 | |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has joined #yocto | 16:33 | |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has quit IRC (Ping timeout: 240 seconds) | 16:37 | |
| *** jatedev <jatedev!~jatedev@63.148.217.19> has quit IRC (Quit: Client closed) | 16:37 | |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has joined #yocto | 16:37 | |
| rburton | hm sure i saw a function somewhere to map a path to a layer name | 16:40 |
| *** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has joined #yocto | 16:40 | |
| kergoth | rburton: bb.utils.get_file_layer() will get the layer name for a file in a layer | 16:50 |
| kergoth | I used to have a class which would set LAYERDIR_name for each layer that didn't do so in their layer.conf and then used get_file_layer() to get the LAYERDIR for the current recipe. Dropped it ages ago since id idn't need it anymore | 16:51 |
| *** osama <osama!~osama@eth1-fw1-nbg6.eb.noris.de> has joined #yocto | 16:56 | |
| *** jatedev <jatedev!~jatedev@63.148.217.19> has joined #yocto | 16:58 | |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has quit IRC (Quit: Leaving.) | 17:03 | |
| rburton | RP: what's the state of depending on py3.7 on the host? I can't remember if there is a distro still clinging to 3.6. | 17:07 |
| rburton | (which was EOL last month) | 17:08 |
| RP | rburton: I really don't remember | 17:20 |
| *** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has quit IRC (Quit: Ex-Chat) | 17:23 | |
| *** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has quit IRC (Quit: xmn) | 17:24 | |
| vd | did something change with the wic.vdmk image type? | 17:27 |
| rburton | RP: me neither :( | 17:27 |
| *** osama <osama!~osama@eth1-fw1-nbg6.eb.noris.de> has quit IRC (Ping timeout: 256 seconds) | 17:28 | |
| *** mckoan is now known as mckoan|away | 17:40 | |
| moto-timo | RHEL 7.7 was still Python 3.6 at last | 17:41 |
| moto-timo | check | 17:41 |
| Konsgn | what is a series file? | 17:42 |
| Konsgn | Patch remove-redundant-yyloc-global.patch is already applied; check your series file.. | 17:42 |
| *** ziga_ <ziga_!~ziga@89-212-219-192.dynamic.t-2.net> has joined #yocto | 18:10 | |
| ziga_ | How can I know which device tree files were used to create the final .dtb which is then included in the image? | 18:11 |
| Konsgn | you can have many dtb's made at once, the loaded dtb then gets selected by your u-boot settings/enviroment | 18:12 |
| Konsgn | first place to look would be uEnv.txt | 18:13 |
| ziga_ | In which folder inside the build directory would I find this? U-boots? | 18:14 |
| *** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Ping timeout: 256 seconds) | 18:15 | |
| alex88 | is there a way to have BUILD_ID increment on every build in os-release package? it seems the last time it changed the value is when I've I've changed the os-release.bbappend I have | 18:15 |
| *** camus <camus!~Instantbi@58.246.136.202> has joined #yocto | 18:15 | |
| Konsgn | you should be able to see dtb's in tmp/deploy/images/blah/ there you will find dtb's ... at least in my case. | 18:17 |
| Konsgn | they also end up packaged into the root filesystem image in the /boot/ directory... again... in my case | 18:17 |
| *** huseyinkozan <huseyinkozan!~hk@31.223.46.173> has quit IRC (Quit: Konversation terminated!) | 18:19 | |
| ziga_ | Thank you. | 18:19 |
| Konsgn | btw, the u-boot enviroment has a really comfortable fdt tool to examine the loaded device tree | 18:21 |
| Konsgn | fdt info/ fdt print allow you to print out entries. | 18:21 |
| *** rgov[m] <rgov[m]!~rgovmatri@2001:470:69fc:105::1:6c47> has joined #yocto | 18:27 | |
| rgov[m] | I'm trying to debug a build failure when using KERNEL_DEVICETREE_BUNDLE = "1". I posted about it on https://lists.yoctoproject.org/g/yocto/message/55886. Is anyone familiar with that? | 18:30 |
| *** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Remote host closed the connection) | 18:31 | |
| *** camus <camus!~Instantbi@58.246.136.202> has joined #yocto | 18:31 | |
| *** Tokamak <Tokamak!~Tokamak@172.58.188.35> has joined #yocto | 18:32 | |
| *** amitk <amitk!~amit@103.208.71.109> has quit IRC (Ping timeout: 240 seconds) | 18:35 | |
| alex88 | if I want to remove DATETIME in BUILD_ID[vardepsexclude] here http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-core/os-release/os-release.bb?h=hardknott#n26, what's the syntax I should use? | 18:38 |
| alex88 | I've tried BUILD_ID[vardepsexclude]:remove = "DATETIME" but it says ParseError | 18:38 |
| kergoth | if they didn't use an intermediate variable you can't use :remove, as it doesn't work on flags | 18:39 |
| kergoth | you'd have to use anonymous python to remove it programmatically | 18:39 |
| kergoth | python () { d.setVarFlag('BUILD_ID', 'vardepsexclude', ' '.join(v for v in d.getVarFlag('BUILD_ID', 'vardepsexclude').split() if v != 'DATETIME')) } or so | 18:40 |
| alex88 | oh ok got it, I'll se if I can get it to work, trying to just assign it to "" doesn't.. it says "The metadata is not deterministic and this needs to be fixed." | 18:40 |
| alex88 | thanks a lot for the example! | 18:40 |
| kergoth | It's correct, trying to let the checksums include a date/timestamp is going to end in failure, as it'll change every time the recipe is parsed, and it's parsed more than once even in a single build | 18:41 |
| kergoth | I'd suggest taking a step back to revisit the purpose | 18:41 |
| alex88 | oh, ok, so it might be probably better to set the variable somewhere else | 18:42 |
| kergoth | removing it from vardepsexclude will also make that recipe rebuild itself every time you do a bitbake build | 18:43 |
| *** leonanavi <leonanavi!~Leon@46.55.231.62> has quit IRC (Quit: Leaving) | 18:43 | |
| alex88 | that's kind of what I want, because I want the os-release file to change on every build to include the build timestamp | 18:43 |
| alex88 | to be able to keep track of what's in each release by knowing the build it comes from | 18:44 |
| alex88 | unless there's a more "yocto-way" of doing so | 18:44 |
| rburton | alex88: image-buildinfo | 18:45 |
| alex88 | oh, ok, let me try that | 18:46 |
| vmeson | Konsgn: not sure if anyone already answered but a series file is a quilt term: https://linux.die.net/man/1/quilt | 18:47 |
| alex88 | there's no timestamp in that, but the git commit might be enough! | 18:52 |
| *** florian_kc <florian_kc!~florian@dynamic-093-132-001-179.93.132.pool.telefonica.de> has joined #yocto | 18:53 | |
| *** codavi <codavi!~akiCA@user/akica> has quit IRC (Ping timeout: 240 seconds) | 18:58 | |
| rgov[m] | I want to add a function to execute after poky/meta/classes/kernel-uboot.bbclass's uboot_prep_kimage. Would it be correct to create a .bbappend file in my layer's recipes directory and write `uboot_prep_kimage_append () { ... }` ? | 18:59 |
| alex88 | I've just copied that bbclass and added the timestamp myself, thanks! | 19:01 |
| alex88 | nvm, timestamp isn't updated... :/ | 19:05 |
| Konsgn | thanks vmeson | 19:18 |
| *** jatedev <jatedev!~jatedev@63.148.217.19> has quit IRC (Quit: Client closed) | 19:21 | |
| *** jatedev <jatedev!~jatedev@63.148.217.19> has joined #yocto | 19:23 | |
| *** otavio <otavio!~otavio@201-34-65-230.user3p.brasiltelecom.net.br> has quit IRC (Remote host closed the connection) | 19:41 | |
| zeddii | grass was sticking out before this storm! | 19:43 |
| zeddii | up arrow gone wrong! | 19:43 |
| *** otavio <otavio!~otavio@201-34-65-230.user3p.brasiltelecom.net.br> has joined #yocto | 19:47 | |
| *** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has quit IRC (Quit: jmiehe) | 20:20 | |
| *** agrue <agrue!~agrue@host-23-251-65-139.VALOLT4.epbfi.com> has quit IRC (Quit: ZNC 1.7.5+deb4 - https://znc.in) | 20:24 | |
| *** agrue <agrue!~agrue@host-23-251-65-139.VALOLT4.epbfi.com> has joined #yocto | 20:25 | |
| alex88 | oh using the datetime from python works! finally | 20:26 |
| *** marka <marka!~marka@198-84-181-245.cpe.teksavvy.com> has quit IRC (Quit: ZNC 1.8.2 - https://znc.in) | 20:33 | |
| *** TundraMan <TundraMan!~marka@198-84-181-245.cpe.teksavvy.com> has joined #yocto | 20:39 | |
| *** TundraMan <TundraMan!~marka@198-84-181-245.cpe.teksavvy.com> has quit IRC (Remote host closed the connection) | 20:39 | |
| *** TundraMan <TundraMan!~marka@198-84-181-245.cpe.teksavvy.com> has joined #yocto | 20:41 | |
| vd | qschulz: multiconfigs are very slow though :) | 20:44 |
| *** mvlad <mvlad!~mvlad@2a02:2f08:4e02:5400:24d7:51ff:fed6:906d> has quit IRC (Remote host closed the connection) | 20:53 | |
| LetoThe2nd | o dudX | 20:59 |
| LetoThe2nd | can anybody give me a short rundown of this arm edk2 thing? | 21:00 |
| *** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has quit IRC (Ping timeout: 276 seconds) | 21:00 | |
| *** florian_kc <florian_kc!~florian@dynamic-093-132-001-179.93.132.pool.telefonica.de> has quit IRC (Ping timeout: 240 seconds) | 21:07 | |
| *** Guest68 <Guest68!~Guest68@modemcable113.46-82-70.mc.videotron.ca> has joined #yocto | 21:08 | |
| Guest68 | Hello Everyone. Starting with Honister, I can't access the network from do_compile (for example, calling ping result in "ping: socket: Operation not permitted", of course, ping from the command line works correctly) | 21:10 |
| vd | how can I print FILESEXTRAPATHS for recipe? | 21:10 |
| rfs613 | vd: maybe with bitbake -e recipename | grep FILESEXTRAPATHS= | 21:25 |
| rgov[m] | I’m trying to build the kernel with the in-tree lpc32xx_defconfig (https://github.com/torvalds/linux/blob/master/arch/arm/configs/lpc32xx_defconfig), so I set the variable KBUILD_DEFCONFIG = "lpc32xx_defconfig" . | 21:26 |
| rgov[m] | But I notice if I inspect my .config file after the fact, some of the settings didn’t make it over. Like CONFIG_ARCH_LPC32XX should definitely be set. | 21:26 |
| *** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has quit IRC (Quit: Client closed) | 21:26 | |
| rfs613 | rgov[m]: might be due to configuration fragments being added? Maybe check KCONFIG_MODE setting. | 21:27 |
| *** tangofoxtrot <tangofoxtrot!~tangofoxt@user/tangofoxtrot> has quit IRC (Remote host closed the connection) | 21:30 | |
| rgov[m] | rfs613: The docs say "An “in-tree” defconfig file can be selected via the KBUILD_DEFCONFIG variable. KCONFIG_MODE does not need to be explicitly set." I do not set it anywhere. | 21:31 |
| LetoThe2nd | Guest68: why would you want to do that anyways? it's called do_compile, not do_network_stuff | 21:31 |
| rburton | LetoThe2nd: quite a vague question. It’s UEFI firmware, for arm. Same as what runs on x86. | 21:32 |
| Guest68 | LetoThe2nd: because the do_compile calls the dart compiler, which in turn, needs to download package from the net | 21:33 |
| *** tangofoxtrot <tangofoxtrot!~tangofoxt@user/tangofoxtrot> has joined #yocto | 21:35 | |
| LetoThe2nd | Guest68: well AFAIK yocto doesn't actively block network access unless you set BB_NO_NETWORK = "1" (or similar, not sure about the exact name), but random network accesses by random toolchains in random tasks are the blueprint of broken reproducibility, therefore discouraged | 21:35 |
| LetoThe2nd | rburton: so in th meta-arm context, its... a uefi firmware drop-in, and which is the first stage in bootloading? or not? | 21:36 |
| *** florian_kc <florian_kc!~florian@dynamic-093-132-001-179.93.132.pool.telefonica.de> has joined #yocto | 21:37 | |
| *** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV) | 21:38 | |
| *** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has joined #yocto | 21:41 | |
| rfs613 | rgov[m]: while the manual should be correct, I know that we had to set the MODE in our recipe, and it was related to getting the config to come out correctly. This was done a few years back and details are foggy. | 21:43 |
| *** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has joined #yocto | 21:44 | |
| *** florian_kc <florian_kc!~florian@dynamic-093-132-001-179.93.132.pool.telefonica.de> has quit IRC (Ping timeout: 250 seconds) | 21:46 | |
| *** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has quit IRC (Quit: Leaving) | 22:09 | |
| *** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has joined #yocto | 22:09 | |
| zeddii | it's better to just set it. That part of the manual hasn't been clear for years now, and this is the second time in a week I've had it mentioned. | 22:15 |
| zeddii | once I get out from under a pile of other things, I plan to update the docs. | 22:15 |
| *** xperia64 <xperia64!~xperia64@pool-71-115-223-249.syrcny.fios.verizon.net> has joined #yocto | 22:17 | |
| bluelightning | anyone had an issue where bitbake sometimes waits forever after showing a parsing error instead of exiting? I'm debugging it now (on top of dunfell) | 22:41 |
| *** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has joined #yocto | 22:48 | |
| RP | bluelightning: that does sound familiar | 22:58 |
| RP | bluelightning: https://git.yoctoproject.org/poky/commit/bitbake?id=ec2ba25376916857ec4cb66a9081fba8b7099d07 | 22:59 |
| RP | bluelightning: https://git.yoctoproject.org/poky/commit/bitbake?id=bf411441f5368284ae6a6ac9707c689f48973083 | 22:59 |
| bluelightning | nice, thanks - those do look like they might help | 23:00 |
| RP | bluelightning: could be something else but I think that is what was triggering my memory | 23:01 |
| bluelightning | shoot, for a moment I thought it had fixed it but then the hang reproduced again :/ | 23:04 |
| *** florian_kc <florian_kc!~florian@dynamic-093-132-001-179.93.132.pool.telefonica.de> has joined #yocto | 23:06 | |
| *** dev1990 <dev1990!~dev@81.168.185.188> has quit IRC (Quit: Konversation terminated!) | 23:25 | |
| *** otavio <otavio!~otavio@201-34-65-230.user3p.brasiltelecom.net.br> has quit IRC (Ping timeout: 250 seconds) | 23:27 | |
| *** otavio <otavio!~otavio@201-34-65-230.user3p.brasiltelecom.net.br> has joined #yocto | 23:29 | |
| *** TundraMan <TundraMan!~marka@198-84-181-245.cpe.teksavvy.com> has quit IRC (Quit: ZNC 1.8.2 - https://znc.in) | 23:30 | |
| *** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has quit IRC (Quit: jmiehe) | 23:33 | |
| *** marka <marka!~marka@198-84-181-245.cpe.teksavvy.com> has joined #yocto | 23:37 | |
| *** paulg <paulg!~paulg@104-195-159-20.cpe.teksavvy.com> has quit IRC (Ping timeout: 240 seconds) | 23:40 | |
| *** paulg <paulg!~paulg@104-195-159-20.cpe.teksavvy.com> has joined #yocto | 23:41 | |
| rgov[m] | The kernel image produced by Poky is much larger than the one I get if I just manually do a Linux build with `make intree_defconfig && make all` -- if I diff the .config files I see a couple options creeping in like CONFIG_NET_INGRESS=y. Where are these happening? Is there a diagnostic I can use to track them down? | 23:59 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!