| *** lexano <lexano!~lexano@pool-174-119-69-134.cpe.net.cable.rogers.com> has quit IRC (Ping timeout: 264 seconds) | 00:52 | |
| *** davidinux <davidinux!~davidinux@45.11.82.37> has quit IRC (Ping timeout: 268 seconds) | 01:04 | |
| *** davidinux <davidinux!~davidinux@45.11.82.48> has joined #yocto | 01:06 | |
| *** Jones42_ <Jones42_!~Jones42@user/Jones42> has joined #yocto | 01:45 | |
| *** Jones42 <Jones42!~Jones42@user/Jones42> has quit IRC (Ping timeout: 240 seconds) | 01:48 | |
| *** jclsn <jclsn!~jclsn@2a04:4540:6532:e400:2ce:39ff:fecf:efcd> has quit IRC (Ping timeout: 268 seconds) | 02:01 | |
| *** jclsn <jclsn!~jclsn@2a04:4540:650f:fe00:2ce:39ff:fecf:efcd> has joined #yocto | 02:03 | |
| *** sgw <sgw!~swold@user/sgw> has quit IRC (Quit: Leaving.) | 02:23 | |
| *** Ad0 <Ad0!~Ad0@93.124.245.194> has quit IRC (Ping timeout: 260 seconds) | 03:03 | |
| *** jmd <jmd!~user@2001:a61:2b57:a201:4b92:15ba:c66d:13b9> has joined #yocto | 04:41 | |
| *** amitk <amitk!~amit@58.84.62.221> has joined #yocto | 04:43 | |
| *** Ad0 <Ad0!~Ad0@93.124.245.194> has joined #yocto | 05:13 | |
| *** jmd <jmd!~user@2001:a61:2b57:a201:4b92:15ba:c66d:13b9> has quit IRC (Remote host closed the connection) | 05:42 | |
| *** jmd <jmd!~user@2001:a61:2b57:a201:4b92:15ba:c66d:13b9> has joined #yocto | 05:43 | |
| *** jmd <jmd!~user@2001:a61:2b57:a201:4b92:15ba:c66d:13b9> has quit IRC (Remote host closed the connection) | 05:43 | |
| *** BhsTalel <BhsTalel!~BhsTalel@147.161.164.164> has joined #yocto | 05:54 | |
| BhsTalel | Hello everyone, | 05:56 |
|---|---|---|
| BhsTalel | I am working for a company that does not allow their Linux servers to access full Internet, so they told me they are only allowed to create a list of mirrors that Yocto uses to add them to their Firewall, | 05:56 |
| BhsTalel | Is this idea possible ? Because I know that there are some major mirrors for Yocto that do not change, but I think the idea is not possible for making Yocto works only with specific mirrors, also one cannot collect all mirrors for sure | 05:56 |
| BhsTalel | What do you think about this ? | 05:56 |
| *** goliath <goliath!~goliath@user/goliath> has joined #yocto | 05:57 | |
| *** alperak <alperak!uid641238@id-641238.ilkley.irccloud.com> has joined #yocto | 06:22 | |
| *** kevans <kevans!~kevans91@user/kevans> has joined #yocto | 06:24 | |
| *** ablu <ablu!~m-bfyrfh@user/Ablu> has quit IRC (Ping timeout: 252 seconds) | 06:45 | |
| *** ablu <ablu!~m-bfyrfh@user/Ablu> has joined #yocto | 06:47 | |
| *** ablu <ablu!~m-bfyrfh@user/Ablu> has quit IRC (Ping timeout: 255 seconds) | 06:52 | |
| *** ablu <ablu!~m-bfyrfh@user/Ablu> has joined #yocto | 06:55 | |
| *** ablu <ablu!~m-bfyrfh@user/Ablu> has quit IRC (Ping timeout: 256 seconds) | 07:00 | |
| landgraf | BhsTalel: try this one http://downloads.yoctoproject.org/mirror/sources/ | 07:02 |
| *** ablu <ablu!~m-bfyrfh@user/Ablu> has joined #yocto | 07:04 | |
| *** rfuentess <rfuentess!~rfuentess@lfbn-lyo-1-1566-5.w90-52.abo.wanadoo.fr> has joined #yocto | 07:08 | |
| *** leon-anavi <leon-anavi!~Leon@46.55.231.62> has joined #yocto | 07:11 | |
| *** zpfvo <zpfvo!~fvo@i59F5CDE4.versanet.de> has joined #yocto | 07:12 | |
| *** enok <enok!~Thunderbi@94.191.152.61.mobile.tre.se> has joined #yocto | 07:16 | |
| *** prabhakalad <prabhakalad!~prabhakar@147.161.225.104> has quit IRC (Quit: Konversation terminated!) | 07:19 | |
| *** prabhakalad <prabhakalad!~prabhakar@147.161.225.104> has joined #yocto | 07:20 | |
| *** enok <enok!~Thunderbi@94.191.152.61.mobile.tre.se> has quit IRC (Ping timeout: 240 seconds) | 07:39 | |
| *** altru <altru!~altru@static-css-ccs-204145.business.bouyguestelecom.com> has joined #yocto | 07:40 | |
| *** Saur_Home5 <Saur_Home5!~Saur_Home@94-137-113-31.customers.ownit.se> has quit IRC (Quit: Client closed) | 07:41 | |
| *** Saur_Home5 <Saur_Home5!~Saur_Home@94-137-113-31.customers.ownit.se> has joined #yocto | 07:41 | |
| *** xmn <xmn!~xmn@2600:4040:9398:a200:80dd:46d3:671a:7c9d> has quit IRC (Ping timeout: 246 seconds) | 07:50 | |
| *** mbulut <mbulut!~mbulut@ip1f128e51.dynamic.kabel-deutschland.de> has joined #yocto | 07:59 | |
| *** mischief <mischief!~mischief@2601:646:100:23:2efd:a1ff:feba:38aa> has quit IRC (Quit: WeeChat 4.1.1) | 08:15 | |
| *** mischief <mischief!~mischief@2601:646:100:23:2efd:a1ff:feba:38aa> has joined #yocto | 08:17 | |
| rburton | BhsTalel: the downloads.yoctoproject.org mirror covers everything in oe-core and hopefully meta-oe too, but it won't cover _all_ sources you'll need so you need to figure something out. you can download on another machine (eg bitbake world --runall fetch) to create a local source mirror and copy that to the servers? | 08:31 |
| *** enok <enok!~Thunderbi@c-4550e353.06-290-73746f71.bbcust.telenor.se> has joined #yocto | 08:32 | |
| BhsTalel | rburton The issue that we don't have Linux hosts, it is not allowed to have Linux hosts, and other solutions like (WSL, docker, ...) cannot work too, so I need to figure out the full list of mirrors, | 08:33 |
| BhsTalel | maybe I will start with the downloads.yoctoproject.org mirror and for every FetchError I will collect the new mirror | 08:33 |
| RP | https://github.com/kpcyrd/what-the-src/commit/e78e79217174cd7eb0868a36e935863b25e154d0#diff-b335630551682c19a781afebcf4d07bf978fb1f8ac04c6bf87428ed5106870f5 - "integrate Yocto Project". Not sure how well that will work but its a start I guess | 08:33 |
| BhsTalel | RP is that a suggestion for me ? | 08:35 |
| RP | BhsTalel: no | 08:35 |
| *** Guest13 <Guest13!~Guest13@132.198.137.78.rev.vodafone.pt> has joined #yocto | 08:36 | |
| Guest13 | hello. i have an automatic ci/cd that builds images. however, sometimes i get the following error | 08:37 |
| Guest13 | Bitbake Fetcher Error: FetchError('Unable to fetch URL from any source.', 'git://git.toradex.com/linux-toradex.git;protocol=git;branch=toradex_5.4-2.3.x-imx') | 08:37 |
| Guest13 | im not sure why it happens, but re-building usually fixes it. | 08:37 |
| Guest13 | is there any workaround for this? (e.g, retry fetch multiple times?) | 08:37 |
| qschulz | Guest13: the work around is to mirror it locally once you have fetched it. Network is unreliable so keeping as much as possible locally helps with that | 08:40 |
| qschulz | and also, makes things much faster AND is kinder to those git servers that are then less hit :) | 08:41 |
| Guest13 | qschulz how do I do that? | 08:42 |
| qschulz | Guest13: the easiest is to share DL_DIR between your CI workers | 08:43 |
| qschulz | Guest13: you can also do this through a custom PREMIRRORS, c.f. https://docs.yoctoproject.org/dev-manual/efficiently-fetching-sources.html?highlight=premirrors | 08:44 |
| Guest13 | do i need a separate machine for the mirrors? | 08:49 |
| Guest13 | i suppose i cant use it in the same machine as the ci job since it runs in docker | 08:49 |
| qschulz | I personally only use a shared DL_DIR over NFS between our different CI workers | 08:49 |
| qschulz | I would only set a PREMIRRORS if you want users to build stuff locally and make use of that local mirror | 08:50 |
| qschulz | same for SSTATE_DIR, I share that over NFS | 08:50 |
| qschulz | but if I had users of that sstate cache, I would make it a SSTATE_MIRROR | 08:50 |
| qschulz | basically, shared dir = read-write, mirror = read-only from user perspective | 08:50 |
| Guest13 | so if source_mirror_url is set and the ci worker doesnt find anything there, what happens? | 09:01 |
| Guest13 | it skips, or fetches and stores it there? | 09:02 |
| Guest13 | (i suppose since its ready only, it just skips?) | 09:02 |
| qschulz | Guest13: the mirror is read-only, your worker will hit the mirror first (provided you set it up as PREMIRRORS), if not found, will it the other PREMIRRORS if any, then upstream (as listed in SRC_URI), if not, then in MIRRORS | 09:02 |
| qschulz | and download this locally in its DL_DIR | 09:02 |
| qschulz | sorry, it'll look first into its own DL_DIR, if not found then goes to the premirrors first, then upstream, then mirrors | 09:03 |
| qschulz | so each worker would download locally, ideally from the premirror you've set up | 09:03 |
| qschulz | something has to feed this mirror though otherwise it'll stay empty (as it's read-only from user perspective) | 09:04 |
| Guest13 | so, recapping, for CI workers, i should use the read-write which is | 09:04 |
| Guest13 | export BB_ENV_PASSTHROUGH_ADDITIONS="DL_DIR SSTATE_DIR" | 09:04 |
| Guest13 | export DL_DIR="${HOME}/data/bitbake.downloads" | 09:04 |
| Guest13 | export SSTATE_DIR="${HOME}/data/bitbake.sstate" | 09:04 |
| Guest13 | for user perspective, they can use the bitbake.dowloads setting the mirrors, right? | 09:04 |
| *** mvlad <mvlad!~mvlad@2a02:2f05:821a:fb00:e88e:21ff:fe65:be18> has joined #yocto | 09:04 | |
| qschulz | Guest13: I think they could yes, but make it a PREMIRROR for your users | 09:06 |
| qschulz | otherwise they may modify DL_DIR | 09:06 |
| qschulz | and you don't want that | 09:06 |
| qschulz | e.g. a user runs bitbake -c cleanall <recipe> and one of your CI worker is running and fetching this tarball at the same time it's being removed => problems | 09:06 |
| qschulz | (in any case, never run -c cleanall or -c cleansstate on anything that is using a shared build directory, shared download directory or shared sstate cache | 09:07 |
| Guest13 | variables: | 09:16 |
| Guest13 | KAS_ALLOW_ROOT: "yes" | 09:16 |
| Guest13 | KAS_PREMIRRORS: "git@my.orgcom: https://my.org.com/git/" | 09:16 |
| Guest13 | DEBIAN_FRONTEND: "noninteractive" | 09:16 |
| Guest13 | BB_ENV_PASSTHROUGH_ADDITIONS: "DL_DIR SSTATE_DIR" | 09:16 |
| Guest13 | DL_DIR: "10.11.2.33:/srv/nfs/bitbake.downloads/" | 09:16 |
| Guest13 | SSTATE_DIR: "10.11.2.33:/srv/nfs/bitbake.sstate/" | 09:16 |
| Guest13 | script: | 09:16 |
| Guest13 | - kas build $PLATFORM | 09:16 |
| Guest13 | im getting WARNING: Invalid mirror data file:///10.11.2.33:/srv/nfs/bitbake.downloads/ tho | 09:16 |
| qschulz | Guest13: BTW, DL_DIR and SSTATE_DIR are already passed by kas to bitbake so no need to explicit it | 09:17 |
| qschulz | Guest13: well, the error is quite self-explanatory? | 09:17 |
| qschulz | it's trying to access DL_DIR as file | 09:17 |
| qschulz | if you're using kas-container, you probably need to mount the NFS externally and pass it as a volume to your container | 09:18 |
| qschulz | otherwise, mount it outside of kas and pass the path on the local filesystem to kas in DL_DIR/SSTATE_DIR | 09:18 |
| Guest13 | oh. im running kas docker image with normal kas | 09:19 |
| *** wooosaiiii <wooosaiiii!~Thunderbi@89-212-21-243.static.t-2.net> has quit IRC (Ping timeout: 256 seconds) | 09:22 | |
| *** wooosaiiii <wooosaiiii!~Thunderbi@89-212-21-243.static.t-2.net> has joined #yocto | 09:23 | |
| ldywicki | @qschulz the snippet with variables section is github action statement :) | 09:25 |
| * ldywicki just to avoid confusion | 09:25 | |
| *** mckoan|away is now known as mckoan | 09:27 | |
| qschulz | https://github.com/agherzan/meta-raspberrypi/blob/master/.github/workflows/mirror.yml this seems to be setting up some cache? | 09:27 |
| qschulz | ah never mind, didn't take the time to read what that was doing | 09:27 |
| qschulz | no clue how to do this on non self-hosted workers | 09:28 |
| qschulz | we have a self-hosted GitLab instance + workers, so we have some ansible mounting this NFS on the host, then have it exposed inside the gitlab worker via volumes | 09:29 |
| Guest13 | FROM ubuntu:latest | 09:35 |
| Guest13 | RUN apt-get update && apt-get install -y nfs-common | 09:35 |
| Guest13 | ENV NFS_SERVER 10.11.2.33 | 09:35 |
| Guest13 | ENV NFS_SHARE /srv/nfs/bitbake.downloads/ | 09:35 |
| Guest13 | RUN mkdir -p /mnt/nfs | 09:35 |
| Guest13 | CMD ["mount.nfs", "$NFS_SERVER:$NFS_SHARE", "/mnt/nfs"] | 09:35 |
| Guest13 | trying to mount it on the docker image, no success for now :( | 09:35 |
| *** Saur_Home5 <Saur_Home5!~Saur_Home@94-137-113-31.customers.ownit.se> has quit IRC (Quit: Client closed) | 09:43 | |
| *** Jones42__ <Jones42__!~Jones42@user/Jones42> has joined #yocto | 09:44 | |
| *** Saur_Home5 <Saur_Home5!~Saur_Home@94-137-113-31.customers.ownit.se> has joined #yocto | 09:44 | |
| *** Jones42_ <Jones42_!~Jones42@user/Jones42> has quit IRC (Read error: Connection reset by peer) | 09:46 | |
| *** enok <enok!~Thunderbi@c-4550e353.06-290-73746f71.bbcust.telenor.se> has quit IRC (Ping timeout: 240 seconds) | 09:47 | |
| *** altru <altru!~altru@static-css-ccs-204145.business.bouyguestelecom.com> has quit IRC (Quit: Client closed) | 09:57 | |
| qschulz | BTW, before I forget, do **NOT** access DL_DIR/SSTATE_DIR at the same through NFS and through another fs, the flock doesn't work across those (been there :) ) | 10:05 |
| *** enok <enok!~Thunderbi@94.191.153.32> has joined #yocto | 10:06 | |
| *** enok <enok!~Thunderbi@94.191.153.32> has quit IRC (Ping timeout: 268 seconds) | 10:13 | |
| *** florian_kc <florian_kc!~florian@port-217-146-132-69.static.as20676.net> has joined #yocto | 10:18 | |
| *** enok <enok!~Thunderbi@c-4550e353.06-290-73746f71.bbcust.telenor.se> has joined #yocto | 10:20 | |
| *** lexano <lexano!~lexano@pool-174-119-69-134.cpe.net.cable.rogers.com> has joined #yocto | 10:50 | |
| *** Saur_Home5 <Saur_Home5!~Saur_Home@94-137-113-31.customers.ownit.se> has quit IRC (Quit: Client closed) | 11:00 | |
| *** Saur_Home5 <Saur_Home5!~Saur_Home@94-137-113-31.customers.ownit.se> has joined #yocto | 11:00 | |
| *** Guest13 <Guest13!~Guest13@132.198.137.78.rev.vodafone.pt> has quit IRC (Quit: Client closed) | 11:02 | |
| *** Kubu_work <Kubu_work!~kubu@lfbn-nan-1-335-137.w82-120.abo.wanadoo.fr> has joined #yocto | 11:22 | |
| *** BhsTalel <BhsTalel!~BhsTalel@147.161.164.164> has quit IRC (Quit: Client closed) | 11:24 | |
| *** enok71 <enok71!~Thunderbi@c-4550e353.06-290-73746f71.bbcust.telenor.se> has joined #yocto | 11:24 | |
| *** enok <enok!~Thunderbi@c-4550e353.06-290-73746f71.bbcust.telenor.se> has quit IRC (Ping timeout: 240 seconds) | 11:27 | |
| *** enok71 is now known as enok | 11:27 | |
| *** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV) | 11:31 | |
| *** enok71 <enok71!~Thunderbi@c-4550e353.06-290-73746f71.bbcust.telenor.se> has joined #yocto | 11:44 | |
| *** enok <enok!~Thunderbi@c-4550e353.06-290-73746f71.bbcust.telenor.se> has quit IRC (Quit: enok) | 11:44 | |
| *** enok72 <enok72!~Thunderbi@c-4550e353.06-290-73746f71.bbcust.telenor.se> has joined #yocto | 11:44 | |
| *** florian_kc <florian_kc!~florian@port-217-146-132-69.static.as20676.net> has quit IRC (Ping timeout: 272 seconds) | 11:45 | |
| *** enok71 <enok71!~Thunderbi@c-4550e353.06-290-73746f71.bbcust.telenor.se> has quit IRC (Ping timeout: 268 seconds) | 11:49 | |
| *** enok72 <enok72!~Thunderbi@c-4550e353.06-290-73746f71.bbcust.telenor.se> has quit IRC (Ping timeout: 268 seconds) | 11:49 | |
| *** BhsTalel <BhsTalel!~BhsTalel@147.161.255.82> has joined #yocto | 12:00 | |
| *** altru <altru!~altru@static-css-ccs-204145.business.bouyguestelecom.com> has joined #yocto | 12:02 | |
| *** MrCryo <MrCryo!~MrCryo@user/MrCryo> has joined #yocto | 12:12 | |
| *** goliath <goliath!~goliath@user/goliath> has joined #yocto | 12:15 | |
| *** xmn <xmn!~xmn@2600:4040:9398:a200:81f6:eb78:8ac8:507a> has joined #yocto | 12:25 | |
| *** Jones42_ <Jones42_!~Jones42@user/Jones42> has joined #yocto | 12:27 | |
| *** Guest60 <Guest60!~Guest60@vpn.friedhelm-loh-group.com> has joined #yocto | 12:27 | |
| Guest60 | Hey, anyone have any experience building Yocto Linux under Gentoo? | 12:27 |
| *** alessioigor <alessioigor!~alessioig@185.178.95.238> has joined #yocto | 12:30 | |
| *** Jones42__ <Jones42__!~Jones42@user/Jones42> has quit IRC (Ping timeout: 268 seconds) | 12:30 | |
| mihai | Guest60: go ahead, maybe it's not even gentoo specific what you're about to ask or state | 12:34 |
| RP | qschulz: it is supposed to work, that is probably your nfs setup | 12:34 |
| RP | qschulz: well, no supposed, it does on the autobuilder | 12:34 |
| rburton | notably though the AB has a NAS appliance for the NFS server that is not linux | 12:36 |
| qschulz | RP: so you have one worker using e.g. ext4, and another using NFS with the content from the ext4 fs and it works just fine? | 12:36 |
| landgraf | Guest60: I use gentoo to build YP based linux yes | 12:37 |
| *** mihai <mihai!~mihai@user/mihai> has quit IRC (Ping timeout: 268 seconds) | 12:44 | |
| RP | qschulz: I was thinking that the nas can change and work with files but as rburton says, that is a BSD NAS appliance | 12:44 |
| RP | I've only done local ext4 shared over NFS | 12:45 |
| *** mihai <mihai!~mihai@user/mihai> has joined #yocto | 12:46 | |
| qschulz | RP: it's been a very long time (2 years probably?) since the IT looked into it, so I cannot provide more info than we just stopped doing this entirely and migrated everything over NFS, even when the NFS was basically localhost | 12:48 |
| RP | qschulz: fair enough,I have some memory of this now. Would be nice to understand what went wrong as in theory it should work | 12:49 |
| *** prabhakarlad <prabhakarlad!~prabhakar@147.161.225.85> has joined #yocto | 12:50 | |
| qschulz | https://libera.irclog.whitequark.org/yocto/2022-11-22 | 12:51 |
| *** prabhakarlad <prabhakarlad!~prabhakar@147.161.225.85> has quit IRC (Client Quit) | 12:51 | |
| *** prabhakarlad <prabhakarlad!~prabhakar@147.161.225.85> has joined #yocto | 12:51 | |
| *** prabhakalad <prabhakalad!~prabhakar@147.161.225.104> has quit IRC (Ping timeout: 268 seconds) | 12:53 | |
| qschulz | https://libera.irclog.whitequark.org/yocto/2022-11-22#33389454; | 12:53 |
| qschulz | funny how the discussion started the exact same way, just a year and a half later :D | 12:54 |
| *** prabhakarlad <prabhakarlad!~prabhakar@147.161.225.85> has quit IRC (Ping timeout: 260 seconds) | 12:57 | |
| *** hiagofranco <hiagofranco!~hiagofran@67.159.246.222> has joined #yocto | 12:58 | |
| *** BhsTalel <BhsTalel!~BhsTalel@147.161.255.82> has quit IRC (Quit: Client closed) | 13:00 | |
| *** Saur_Home5 <Saur_Home5!~Saur_Home@94-137-113-31.customers.ownit.se> has quit IRC (Quit: Client closed) | 13:02 | |
| *** Saur_Home5 <Saur_Home5!~Saur_Home@94-137-113-31.customers.ownit.se> has joined #yocto | 13:02 | |
| *** Guest60 <Guest60!~Guest60@vpn.friedhelm-loh-group.com> has quit IRC (Quit: Client closed) | 13:03 | |
| *** sgw <sgw!~swold@user/sgw> has joined #yocto | 13:22 | |
| *** florian_kc <florian_kc!~florian@port-217-146-132-69.static.as20676.net> has joined #yocto | 13:24 | |
| *** amitk <amitk!~amit@58.84.62.221> has quit IRC (Ping timeout: 264 seconds) | 13:38 | |
| *** florian_kc <florian_kc!~florian@port-217-146-132-69.static.as20676.net> has quit IRC (Remote host closed the connection) | 13:51 | |
| *** hiagofranco <hiagofranco!~hiagofran@67.159.246.222> has quit IRC (Quit: Client closed) | 13:52 | |
| qschulz | I'm a bit perplex with what bitbake returns in DEPENDS for my PACKAGECONFIG varflag | 13:58 |
| qschulz | I have | 13:58 |
| qschulz | PACKAGECONFIG[gallium] = "-Dgallium-drivers=${@strip_comma('${GALLIUMDRIVERS}')}, -Dgallium-drivers='', libdrm ${@'libclc' if 'iris' in d.getVar('GALLIUMDRIVERS', '').split(',') else ''}" | 13:59 |
| *** enok <enok!~Thunderbi@94.191.152.212> has joined #yocto | 13:59 | |
| qschulz | but it keeps it inline somehow, and then for the native variant of the recipe, I get 'libclc'-native if-native 'iris'-native etc.... in DEPENDS | 13:59 |
| qschulz | keeps it inline -> keeps it unexpanded/unresolved | 14:00 |
| *** vthor <vthor!~thor@user/vthor> has joined #yocto | 14:01 | |
| qschulz | using an intermediate variable made it work... what am I missing here? | 14:01 |
| RP | qschulz: is there some kind of conditional inherit involved? or how/where is PACKAGECONFIG set? | 14:18 |
| RP | it is probably related to how/when/where the PACKAGECONFIG code is processed | 14:19 |
| qschulz | RP: upstream master-next branch + https://lore.kernel.org/openembedded-core/20240531-panthor-v1-2-1a76fd752c1b@cherry.de/ | 14:20 |
| qschulz | it's the mesa recipe | 14:21 |
| qschulz | mmm could be the anonymous python then I guess | 14:22 |
| *** enok <enok!~Thunderbi@94.191.152.212> has quit IRC (Ping timeout: 240 seconds) | 14:24 | |
| qschulz | but d.getVar in the anonymous function should expand this by default as that's the default value for getVar method from the DataSmart | 14:25 |
| RP | qschulz: could be some sort of quoting problem, or a genuine bug | 14:26 |
| qschulz | RP: I was already surprised by ${@strip_comma('${GALLIUMDRIVERS}')} (already in the recipe) | 14:26 |
| qschulz | RP: moving ${@'libclc' if 'iris' in d.getVar('GALLIUMDRIVERS', '').split(',') else ''} to VAR= and then use ${VAR} in PACKAGECONFIG[gallium] worked just fine | 14:27 |
| *** MrCryo <MrCryo!~MrCryo@user/MrCryo> has quit IRC (Remote host closed the connection) | 14:27 | |
| qschulz | so doesn't seem to be a quoting issue? | 14:27 |
| RP | qschulz: I suspect the regex bitbake is using to find code to run or something so two ${@} usages or something | 14:28 |
| qschulz | RP: then a corner case somewhere because we have multiple regex in PROVIDES of the same recipe for example (though on a newline each....) | 14:30 |
| qschulz | sorry, multiple inline python | 14:31 |
| qschulz | this mesa update is a bit of a nightmare for someone who knows nothing of mesa nor meson :) | 14:31 |
| *** Jones42__ <Jones42__!~Jones42@user/Jones42> has joined #yocto | 14:32 | |
| *** Jones42_ <Jones42_!~Jones42@user/Jones42> has quit IRC (Ping timeout: 246 seconds) | 14:36 | |
| *** vvn <vvn!~vivien@bras-base-mtrlpq02huw-grc-03-174-88-247-147.dsl.bell.ca> has joined #yocto | 14:39 | |
| Xogium | mesa, meson, that already sounds confusing ;p | 14:49 |
| *** michael_e <michael_e!~michael_e@user/michael-e:30278> has joined #yocto | 15:02 | |
| *** rfuentess <rfuentess!~rfuentess@lfbn-lyo-1-1566-5.w90-52.abo.wanadoo.fr> has quit IRC (Remote host closed the connection) | 15:06 | |
| *** enok <enok!~Thunderbi@94.191.152.98.mobile.tre.se> has joined #yocto | 15:09 | |
| *** michael_e <michael_e!~michael_e@user/michael-e:30278> has quit IRC (Quit: Client closed) | 15:14 | |
| *** sgw <sgw!~swold@user/sgw> has quit IRC (Quit: Leaving.) | 15:24 | |
| *** enok <enok!~Thunderbi@94.191.152.98.mobile.tre.se> has quit IRC (Quit: enok) | 15:27 | |
| *** enok <enok!~Thunderbi@94.191.152.98.mobile.tre.se> has joined #yocto | 15:27 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.238> has quit IRC (Quit: Client closed) | 15:38 | |
| qschulz | khem: I'm trying to work out the mesa-native 24.1.0 recipe and we now need libclc for x86 hosts (iris Gallium driver requires clc now...) | 15:40 |
| qschulz | khem: however I get: | 15:40 |
| qschulz | The file /usr/lib/libLLVMPasses.a is installed by both llvm-native and clang-native, aborting | 15:40 |
| qschulz | master branch on meta-clang | 15:40 |
| qschulz | have you seen this already or is this one more new issue (which could be PEBKAC :) ) I found in the last couple of days :( ? | 15:43 |
| *** enok <enok!~Thunderbi@94.191.152.98.mobile.tre.se> has quit IRC (Read error: Connection reset by peer) | 15:44 | |
| *** enok <enok!~Thunderbi@94.191.152.98> has joined #yocto | 15:45 | |
| *** mckoan is now known as mckoan|away | 15:47 | |
| *** leon-anavi <leon-anavi!~Leon@46.55.231.62> has quit IRC (Quit: Leaving) | 15:47 | |
| *** enok <enok!~Thunderbi@94.191.152.98> has quit IRC (Ping timeout: 240 seconds) | 15:49 | |
| qschulz | RP: I FOUND THE ISSUE! | 15:53 |
| qschulz | So, it seems that we do a split by comma in PACKAGECONFIG before running the inline python | 15:54 |
| qschulz | and since I used a comma in my inline python... it broke the parsing in weird ways that didn't fully break the parsing | 15:54 |
| qschulz | just put the rest of the stuff in RDEPENDS (IIRC that's what after DEPENDS in the PACKAGECONFIG[v] entry?) | 15:55 |
| qschulz | So that's why putting it in another variable made it work | 15:55 |
| qschulz | so not sure what to do with this, is this an actual bug or not? | 15:55 |
| qschulz | because I'm not sure we want to expand everything in PACKAGECONFIG[v] before we split by comma? | 15:56 |
| RP | qschulz: oh, interesting. I wonder if we should detect/warn about that | 15:59 |
| *** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV) | 15:59 | |
| *** altru <altru!~altru@static-css-ccs-204145.business.bouyguestelecom.com> has quit IRC (Quit: Client closed) | 16:00 | |
| *** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has quit IRC (Quit: Ex-Chat) | 16:03 | |
| *** wdouglass <wdouglass!~user@dhcp-pa-67-20-246-179.consolidated.net> has joined #yocto | 16:09 | |
| wdouglass | Hi all. Is there a variable i can use in a .bbappend file that refers to the location of the .bbappend file, and not the original recipe? I'm trying to do something like `FILESEXTRAPATHS:prepend := "${THISDIR}/files:"` but it resolves to the wrong location | 16:10 |
| qschulz | wdouglass: that's exactly what this does | 16:11 |
| qschulz | wdouglass: but I think you may be looking at the wrong thing, can you explain what you're trying to do and what's happening? | 16:11 |
| *** tgamblin <tgamblin!~tgamblin@d24-150-219-207.home.cgocable.net> has quit IRC (Ping timeout: 246 seconds) | 16:15 | |
| qschulz | khem: never mind, it's because we both have gallium and gallium-llvm in mesa-native and that gallium now requires lblc-native which brings clang-native as well.... | 16:15 |
| wdouglass | I'm trying to add functionality to a devkit which defines a bunch of packages in place with EXTERNALSRCDIR. It uses a config file that matches the SDK development board, and not the custom board i'm designing. I can override the board config in one of the tools that comes from upstream in a make argument, so i've created a BBAPPEND that looks like this: https://pastebin.com/uCxUzeX5 | 16:15 |
| *** tgamblin <tgamblin!~tgamblin@d24-150-219-207.home.cgocable.net> has joined #yocto | 16:16 | |
| wdouglass | I think because of EXTERNALSRCDIR, it's not actually copying `board_config` anywhere, and ${B} is referring to the source directory for the upstream package | 16:16 |
| wdouglass | but if i change the last line to be | 16:16 |
| wdouglass | EXTRA_OEMAKE:append = " BOARD_CONFIG=${THISDIR}/board_config" | 16:16 |
| wdouglass | then the upstream looks in the original recipe directory, and not the bbappend location | 16:17 |
| qschulz | yup, expected | 16:17 |
| wdouglass | so my question is -- what do? how do i get it to find `board_config` in the right place? | 16:17 |
| qschulz | you can use BBAPPEND_LOCATION := "${THISDIR} and then EXTRA_OEMAKE:append = " BOARD_CONFIG=${BBAPPEND_LOCATION}/board_config" | 16:17 |
| wdouglass | Oh interesting | 16:18 |
| qschulz | BUT, this isn't ideal ayway | 16:18 |
| wdouglass | what is ideal? it seems not-obvious to me when all of these things get parsed | 16:18 |
| qschulz | your SRC_URI should put this file somewhere available to your recipe | 16:18 |
| qschulz | in everything but the current master branch of Yocto, it's WORKDIR | 16:18 |
| wdouglass | I understand. can i undo the `inherit externalsrc` that's in the original recipe? I'm trying very hard not to patch the upstream sdk | 16:19 |
| qschulz | so if you use BOARD_CONFIG=${WORKDIR}/board_config this could probably work | 16:19 |
| wdouglass | ok i'll give that a shot | 16:19 |
| qschulz | wdouglass: no, you cannot uninherit stuff as far as I know | 16:19 |
| *** tgamblin <tgamblin!~tgamblin@d24-150-219-207.home.cgocable.net> has quit IRC (Read error: Connection reset by peer) | 16:19 | |
| *** tgamblin <tgamblin!~tgamblin@d24-150-219-207.home.cgocable.net> has joined #yocto | 16:20 | |
| wdouglass | ${WORKDIR}/board_config worked! thanks a ton qshulz! | 16:20 |
| *** sudip_ is now known as sudip | 16:20 | |
| qschulz | note that using WORKDIR is a bit finicky, so I could suggest using destsuffix into e.g. ${S} for example and then use ${S} instead of WORKDIR | 16:21 |
| qschulz | the issue being that if you remove the SRC_URI, the file will still exist (except if you remove your whole TMPDIR) | 16:21 |
| qschulz | (well, the one for the recipe, that is) | 16:21 |
| qschulz | hence why we're migrating to UNPACKDIR now | 16:21 |
| qschulz | sorry, not destsuffix but subdir | 16:22 |
| qschulz | https://docs.yoctoproject.org/bitbake/bitbake-user-manual/bitbake-user-manual-fetching.html#the-unpack | 16:22 |
| wdouglass | well because of the externalsrc inherit, ${S} is the upstream source directory | 16:22 |
| wdouglass | so it doesn't seem right to put stuff there | 16:22 |
| *** zpfvo <zpfvo!~fvo@i59F5CDE4.versanet.de> has quit IRC (Remote host closed the connection) | 16:23 | |
| qschulz | true | 16:23 |
| qschulz | nothing better to suggest right now | 16:23 |
| rburton | for not-master, WORKDIR/ is the right thing | 16:23 |
| qschulz | rburton: yes, but still not always working | 16:23 |
| wdouglass | ok thank you guys very much (because of my vendor, i'm stuck on kirkstone for the time being, so i'm a bit behind the times anyway)' | 16:23 |
| qschulz | wdouglass: kirkstone is not THAT bad, you still have two years to prepare for the next update ;) | 16:24 |
| wdouglass | :) | 16:24 |
| *** jmd <jmd!~user@2001:a61:2b57:a201:4b92:15ba:c66d:13b9> has joined #yocto | 16:25 | |
| *** tgamblin_ <tgamblin_!~tgamblin@d24-150-219-207.home.cgocable.net> has joined #yocto | 16:32 | |
| *** tgamblin <tgamblin!~tgamblin@d24-150-219-207.home.cgocable.net> has quit IRC (Ping timeout: 268 seconds) | 16:33 | |
| *** tgamblin_ is now known as tgamblin | 16:36 | |
| qschulz | RP: ah, discovered that packageconfig-conflicts-for-f1 isn't expanded at all? Tried to use with inline python or a variable and it didn't parse | 16:39 |
| *** jmd <jmd!~user@2001:a61:2b57:a201:4b92:15ba:c66d:13b9> has left #yocto (ERC 5.4 (IRC client for GNU Emacs 28.2)) | 16:39 | |
| *** enok <enok!~Thunderbi@94.191.152.98> has joined #yocto | 16:45 | |
| *** enok <enok!~Thunderbi@94.191.152.98> has quit IRC (Ping timeout: 240 seconds) | 16:53 | |
| *** enok <enok!~Thunderbi@c-4550e353.06-290-73746f71.bbcust.telenor.se> has joined #yocto | 17:16 | |
| *** amitk <amitk!~amit@58.84.62.221> has joined #yocto | 17:26 | |
| *** dankm <dankm!~dan@user/dankm> has quit IRC (Remote host closed the connection) | 17:38 | |
| *** amitk <amitk!~amit@58.84.62.221> has quit IRC (Ping timeout: 240 seconds) | 17:40 | |
| *** dankm <dankm!~dan@user/dankm> has joined #yocto | 17:40 | |
| *** amitk <amitk!~amit@58.84.62.221> has joined #yocto | 17:42 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.238> has joined #yocto | 17:57 | |
| *** alperak <alperak!uid641238@id-641238.ilkley.irccloud.com> has quit IRC (Quit: Connection closed for inactivity) | 18:12 | |
| *** xmn <xmn!~xmn@2600:4040:9398:a200:81f6:eb78:8ac8:507a> has quit IRC (Ping timeout: 240 seconds) | 18:15 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.238> has quit IRC (Quit: Client closed) | 18:21 | |
| *** xmn <xmn!~xmn@2600:4040:9398:a200:d33:d792:9f32:52c2> has joined #yocto | 18:24 | |
| *** enok <enok!~Thunderbi@c-4550e353.06-290-73746f71.bbcust.telenor.se> has quit IRC (Ping timeout: 240 seconds) | 18:37 | |
| *** vthor_ <vthor_!~thor@2806:10a6:6:1b6e:58f7:ccf0:86bd:aa00> has joined #yocto | 18:40 | |
| *** vthor <vthor!~thor@user/vthor> has quit IRC (Ping timeout: 255 seconds) | 18:41 | |
| *** florian <florian!~florian@dynamic-078-048-062-212.78.48.pool.telefonica.de> has joined #yocto | 18:53 | |
| *** mbulut <mbulut!~mbulut@ip1f128e51.dynamic.kabel-deutschland.de> has quit IRC (Ping timeout: 268 seconds) | 18:57 | |
| *** amitk <amitk!~amit@58.84.62.221> has quit IRC (Remote host closed the connection) | 19:01 | |
| *** kevans_ <kevans_!~kevans91@user/kevans> has joined #yocto | 19:06 | |
| *** vthor_ <vthor_!~thor@2806:10a6:6:1b6e:58f7:ccf0:86bd:aa00> has quit IRC (Quit: kill -9 $pid) | 19:06 | |
| *** kevans <kevans!~kevans91@user/kevans> has quit IRC (Ping timeout: 268 seconds) | 19:08 | |
| *** Saur_Home5 <Saur_Home5!~Saur_Home@94-137-113-31.customers.ownit.se> has quit IRC (Quit: Client closed) | 19:20 | |
| *** Saur_Home5 <Saur_Home5!~Saur_Home@94-137-113-31.customers.ownit.se> has joined #yocto | 19:20 | |
| *** enok <enok!~Thunderbi@c-4550e353.06-290-73746f71.bbcust.telenor.se> has joined #yocto | 19:31 | |
| *** xmn <xmn!~xmn@2600:4040:9398:a200:d33:d792:9f32:52c2> has quit IRC (Ping timeout: 268 seconds) | 19:39 | |
| *** kevans_ is now known as kevans | 19:43 | |
| *** Haxxa <Haxxa!~Haxxa@116.255.4.123> has quit IRC (Quit: Haxxa flies away.) | 20:15 | |
| *** Haxxa <Haxxa!~Haxxa@116.255.4.123> has joined #yocto | 20:18 | |
| khem | RP: seeing this https://snips.sh/f/WXadi0hKch with latest maater-next any ideas ? | 20:21 |
| *** enok <enok!~Thunderbi@c-4550e353.06-290-73746f71.bbcust.telenor.se> has quit IRC (Ping timeout: 240 seconds) | 20:23 | |
| khem | this is binutils for musl on target and I wonder why its complaining about ld-linux-x86-64.so.2()(64bit) which comes from glibc | 20:23 |
| *** mvlad <mvlad!~mvlad@2a02:2f05:821a:fb00:e88e:21ff:fe65:be18> has quit IRC (Remote host closed the connection) | 20:25 | |
| *** enok <enok!~Thunderbi@c-4550e353.06-290-73746f71.bbcust.telenor.se> has joined #yocto | 20:26 | |
| *** wdouglass <wdouglass!~user@dhcp-pa-67-20-246-179.consolidated.net> has left #yocto (ERC 5.5.0.29.1 (IRC client for GNU Emacs 29.1)) | 20:28 | |
| RP | khem: no idea on that :/ | 20:29 |
| khem | and its using plain poky | 20:29 |
| RP | it is as if it has lost the glibc provides | 20:29 |
| RP | hmm, rc1 is a bust | 20:33 |
| * RP merges a fix and tried an rc2 | 20:38 | |
| *** Saur_Home5 <Saur_Home5!~Saur_Home@94-137-113-31.customers.ownit.se> has quit IRC (Quit: Client closed) | 20:57 | |
| *** Saur_Home5 <Saur_Home5!~Saur_Home@94-137-113-31.customers.ownit.se> has joined #yocto | 20:57 | |
| *** roussinm <roussinm!~mroussin@142.115.196.7> has joined #yocto | 21:10 | |
| roussinm | We are using qsb (qt shader tool), and it lives in the native part of the sdk. Let's say you have a SDK from mickledore and someone using a host Ubuntu 24. When `qsb` runs on shader it will fail because of linkage on libGLdispatch.so.0 on the host machine. `/$SDKPATH/lib/libc.so.6: version `GLIBC_2.38` not found (required by /lib/x86_64-linux-gnu/libGLdispatch.so.0)` If you use an older version of | 21:18 |
| roussinm | Ubuntu it now works. If we upgrade to newer yocto version it now works again. Wondering if this is more of how we use the tool, qt issue or yocto sdk issue? We don't really need to target multiple version of glsl, we don't build for hlsl and metal either, so maybe the tool is useless to us? | 21:18 |
| *** enok <enok!~Thunderbi@c-4550e353.06-290-73746f71.bbcust.telenor.se> has quit IRC (Ping timeout: 240 seconds) | 21:29 | |
| *** Saur_Home5 <Saur_Home5!~Saur_Home@94-137-113-31.customers.ownit.se> has quit IRC (Quit: Client closed) | 21:32 | |
| *** Saur_Home5 <Saur_Home5!~Saur_Home@94-137-113-31.customers.ownit.se> has joined #yocto | 21:32 | |
| RP | roussinm: you need the libc in the SDK to be >= than the host libc. The newer yocto build will have a newer libc | 21:44 |
| *** florian <florian!~florian@dynamic-078-048-062-212.78.48.pool.telefonica.de> has quit IRC (Ping timeout: 260 seconds) | 21:52 | |
| roussinm | Is that always a requirement? | 21:53 |
| RP | roussinm: it depends how much you're mixing up the binaries/libs | 21:55 |
| roussinm | RP: I guess here the problem is the GL library, because cmake works correctly. | 21:55 |
| RP | roussinm: right, that would do it | 21:55 |
| RP | the problems start when mixing elements of both, then you need the SDK to be >= | 21:56 |
| roussinm | RP: I think that's pretty much only tool that we need that uses libGLdispatch. Wondering if libglvnd would help? | 21:57 |
| *** Saur_Home5 <Saur_Home5!~Saur_Home@94-137-113-31.customers.ownit.se> has quit IRC (Quit: Client closed) | 22:18 | |
| *** Saur_Home5 <Saur_Home5!~Saur_Home@94-137-113-31.customers.ownit.se> has joined #yocto | 22:19 | |
| RP | roussinm: I don't know enough about that specifically to comment. I've just spent far too long with linking errors like that | 22:21 |
| *** Kubu_work <Kubu_work!~kubu@lfbn-nan-1-335-137.w82-120.abo.wanadoo.fr> has quit IRC (Quit: Leaving.) | 22:28 | |
| *** xmn <xmn!~xmn@2600:4040:9398:a200:54c4:5748:1682:3016> has joined #yocto | 22:33 | |
| *** mbulut <mbulut!~mbulut@ip1f128e48.dynamic.kabel-deutschland.de> has joined #yocto | 23:09 | |
| Xogium | so I have a system where the only storage medium is micro sd. I *hate* micro sd, but I don't have much choice in the matter... Somehow today, the overlayfs I have sitting on top of my a/b rootfs shows as totally fine when examine from another machine, but when booted up, the system has various strange things. For instance the machine id was actually visible in /etc/locale.conf, and my rauc system config had | 23:23 |
| Xogium | been seemingly replaced by the keymap for a remote control. Those files were not altered in the real rootfs however (squashfs) and not present when examining the overlayfs somewhere else. I guess, what I'm asking here is, does it sounds like that micro sd is on its way out, or what ? | 23:23 |
| Xogium | trying to rm the affected files just said, stale file handle | 23:24 |
| Xogium | no expert but to me it sounds like the whole setup is about to crumble heh | 23:25 |
| *** mbulut <mbulut!~mbulut@ip1f128e48.dynamic.kabel-deutschland.de> has quit IRC (Ping timeout: 268 seconds) | 23:25 | |
| khem | RP: the binutils issue does not happen when building on debian12 container but only on latest archlinux so I guess some future problem that I am seeing | 23:44 |
| *** ablu <ablu!~m-bfyrfh@user/Ablu> has quit IRC (Ping timeout: 252 seconds) | 23:48 | |
| *** ablu <ablu!~m-bfyrfh@user/Ablu> has joined #yocto | 23:57 | |
Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!