| *** jsbronder <jsbronder!~jsbronder@cold-front.org> has quit IRC (Remote host closed the connection) | 00:08 | |
| *** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV) | 00:10 | |
| *** jsbronder <jsbronder!~jsbronder@user/jbronder> has joined #yocto | 00:13 | |
| *** xmn <xmn!~xmn@p200300c37f2e9900655dc723b53a0eed.dip0.t-ipconnect.de> has quit IRC (Quit: ZZZzzz…) | 00:14 | |
| *** BCMM <BCMM!~BCMM@user/bcmm> has quit IRC (Remote host closed the connection) | 00:38 | |
| *** tp43_ <tp43_!~ndeem@2001:1970:501a:e201:7dd8:7bb5:b166:9697> has quit IRC (Ping timeout: 258 seconds) | 01:55 | |
| *** dlan <dlan!~dennis@gentoo/developer/dlan> has quit IRC (Quit: leaving) | 02:19 | |
| *** dlan <dlan!~dennis@gentoo/developer/dlan> has joined #yocto | 02:19 | |
| *** tp43_ <tp43_!~ndeem@2001:1970:501a:e201:7dd8:7bb5:b166:9697> has joined #yocto | 02:24 | |
| *** dlan <dlan!~dennis@gentoo/developer/dlan> has quit IRC (Quit: leaving) | 02:26 | |
| *** dlan <dlan!~dennis@gentoo/developer/dlan> has joined #yocto | 02:27 | |
| *** dlan <dlan!~dennis@gentoo/developer/dlan> has quit IRC (Client Quit) | 02:30 | |
| *** dlan <dlan!~dennis@gentoo/developer/dlan> has joined #yocto | 02:31 | |
| *** sakoman <sakoman!~steve@172.243.4.16> has quit IRC (Quit: Leaving.) | 02:34 | |
| *** sakoman <sakoman!~steve@172.243.4.16> has joined #yocto | 03:13 | |
| *** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Ping timeout: 248 seconds) | 03:16 | |
| *** camus <camus!~Instantbi@58.246.136.202> has joined #yocto | 03:16 | |
| *** paulg <paulg!~boodler@104-195-159-20.cpe.teksavvy.com> has quit IRC (Ping timeout: 248 seconds) | 04:14 | |
| *** rpcme <rpcme!~rpcme@52.95.4.25> has quit IRC (Quit: Ping timeout (120 seconds)) | 04:33 | |
| *** sakoman <sakoman!~steve@172.243.4.16> has quit IRC (Quit: Leaving.) | 05:11 | |
| *** amitk <amitk!~amit@103.208.69.35> has joined #yocto | 05:25 | |
| *** davidinux <davidinux!~davidinux@217.138.219.36> has joined #yocto | 05:47 | |
| mihai | yo | 05:52 |
|---|---|---|
| *** rob_w <rob_w!~bob@host-82-135-31-73.customer.m-online.net> has joined #yocto | 05:55 | |
| *** roussinm <roussinm!~mroussin@bras-base-qubcpq1306w-grc-21-184-145-222-193.dsl.bell.ca> has quit IRC (Quit: WeeChat 3.3-dev) | 05:57 | |
| *** Ad0 <Ad0!~Ad0@93.124.245.194> has quit IRC (Ping timeout: 252 seconds) | 06:24 | |
| *** Ad0 <Ad0!~Ad0@93.124.245.194> has joined #yocto | 06:31 | |
| *** sbach <sbach!~sbach@user/sbach> has quit IRC (Read error: Connection reset by peer) | 06:40 | |
| *** sbach <sbach!~sbach@user/sbach> has joined #yocto | 06:40 | |
| *** rob_w <rob_w!~bob@host-82-135-31-73.customer.m-online.net> has quit IRC (Ping timeout: 252 seconds) | 06:54 | |
| *** rob_w <rob_w!~bob@host-82-135-31-73.customer.m-online.net> has joined #yocto | 06:55 | |
| *** zpfvo <zpfvo!~fvo@i59F44C1B.versanet.de> has joined #yocto | 06:59 | |
| *** zyga <zyga!~zyga@ip-81-15-135-168.unregistered.net.exatel.pl> has joined #yocto | 07:00 | |
| *** leon-anavi <leon-anavi!~Leon@78.130.197.211> has joined #yocto | 07:00 | |
| *** d0ku <d0ku!~d0ku@178.43.198.70.ipv4.supernova.orange.pl> has joined #yocto | 07:01 | |
| *** dgriego <dgriego!~dgriego@user/dgriego> has quit IRC (Ping timeout: 258 seconds) | 07:04 | |
| *** lexano <lexano!~lexano@cpe00e06722f0e4-cm98524a70e35e.cpe.net.cable.rogers.com> has quit IRC (Ping timeout: 268 seconds) | 07:07 | |
| *** dgriego <dgriego!~dgriego@user/dgriego> has joined #yocto | 07:07 | |
| *** tp43_ <tp43_!~ndeem@2001:1970:501a:e201:7dd8:7bb5:b166:9697> has quit IRC (Ping timeout: 250 seconds) | 07:14 | |
| *** lexano <lexano!~lexano@cpe00e06722f0e4-cm98524a70e35e.cpe.net.cable.rogers.com> has joined #yocto | 07:16 | |
| *** dgriego <dgriego!~dgriego@user/dgriego> has quit IRC (Ping timeout: 258 seconds) | 07:27 | |
| *** dgriego <dgriego!~dgriego@user/dgriego> has joined #yocto | 07:29 | |
| *** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has joined #yocto | 07:31 | |
| wCPO | I'm adding a new file to the initramfs with a initramfs-framework_1.0.bbappend creating a new package. How should I install the new package? PACKAGE_INSTALL += "initramfs-module-foo" in local.conf? | 07:41 |
| mihai | wCPO: presuming you are using core-image-minimal-initramfs, you could install it with INITRAMFS_SCRIPTS:append = " initramfs-module-foo" | 07:51 |
| wCPO | mihai: we have our own image with "require recipes-extended/images/kvm-image-minimal.bb", kvm-image-minimal inherit core-image. | 07:59 |
| mihai | wCPO: ok, that's fine :) I meant using core-image-minimal-initramfs as initramfs / initrd | 08:01 |
| *** xmn <xmn!~xmn@p200300c37f2e9900d0da590799d0287b.dip0.t-ipconnect.de> has joined #yocto | 08:06 | |
| *** mcon <mcon!~Thunderbi@host-79-23-91-44.retail.telecomitalia.it> has joined #yocto | 08:10 | |
| *** Frozen-compiler <Frozen-compiler!~Frozen-co@95.168.120.19> has joined #yocto | 08:11 | |
| Frozen-compiler | Hey | 08:12 |
| Frozen-compiler | Am looking at this variable IMAGE_BOOT_FILES | 08:12 |
| Frozen-compiler | https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#var-IMAGE_BOOT_FILES | 08:12 |
| Frozen-compiler | I can understand the kernel or grub being placed in a boot partition. But why would you want to put u-boot there ever? | 08:13 |
| Frozen-compiler | I guess there could be some special cases where u-boot is used even further in the bootlader chain (SPL -> somehting which can read the boot partition -> u-boot). | 08:14 |
| Frozen-compiler | But I haven't seen any cases for that. | 08:14 |
| qschulz | Frozen-compiler: BeagleBone boards booting from SD card do use the boot partition to get the SPL and U-Boot binaries AFAIR | 08:18 |
| qschulz | and in any case, it's just an example to show what you can do :) | 08:20 |
| qschulz | also, please use docs.yoctoproject.org now :) | 08:20 |
| Frozen-compiler | Oh, really. Thanks. I guess that means their bootloader in ROM can already read partition data as well as file systems. | 08:20 |
| Frozen-compiler | O, didn't know about docs.yoctoproject.org, thanks! Will do | 08:20 |
| *** goliath <goliath!~goliath@user/goliath> has joined #yocto | 08:31 | |
| *** mranosta1 <mranosta1!~mranostaj@185.193.126.133> has joined #yocto | 08:35 | |
| *** lucaceresoli <lucaceresoli!~lucaceres@77.244.183.192> has joined #yocto | 08:38 | |
| lucaceresoli | hi, I have a vendor layer adding more MACHINEOVERRIDES than I would like: | 08:45 |
| lucaceresoli | MACHINEOVERRIDES_prepend_zynqmpev = "mali400:vcu:" | 08:45 |
| lucaceresoli | I want to remove the 'mali400:' prefix in my own machine conf, how can I do it? | 08:45 |
| lucaceresoli | anything like MACHINEOVERRIDES_remove than works with colon-separated lists? | 08:46 |
| lukma | Dear Community: | 08:49 |
| lukma | When creating foo-dbg package (with included .debug stuff) | 08:49 |
| lukma | I do encounter following error: "RecursionError: maximum recursion depth exceeded in comparison " | 08:49 |
| lukma | I do guess that the created directories and files consume so much resources that python on the build machine returns this error | 08:50 |
| lukma | hence, the question - is it possible to increase the stacksize from the Yocto/OE? (via e.g. local.conf) | 08:50 |
| lukma | Or I need to fiddle with 'ulimit' in the shell which runs bitbake builds ? | 08:51 |
| mihai | lucaceresoli: have you tried it with _remove, actually :remove ? | 08:53 |
| lukma | To be more precise - "Failure expanding variable SUMMARY:glibc-tests-dbg, expression was ${SUMMARY} - Debugging files which triggered exception RecursionError: maximum recursion depth exceeded in comparison" | 08:54 |
| lukma | When I have only PACKAGES = "${PN}" - without the '-dbg' one everything works correctly | 08:54 |
| lukma | even better :-) -> SUMMARY:${PN}-gdb·=·"foo" fixes the issue .... | 08:55 |
| lucaceresoli | mihai, yes, but :remove does not seem to work: | 08:57 |
| lucaceresoli | ERROR: ParseError at [...]: unparsed line: 'MACHINEOVERRIDES:remove = "mali400:"' | 08:58 |
| qschulz | if python anonymous function work in configuration file, you could try to d.setVar(MACHINEOVERRIDES) in there | 09:00 |
| qschulz | lucaceresoli: otherwise, next step is just to define your own machine configuration file that is loosely based on the one from your vendor | 09:01 |
| qschulz | usually MACHINEOVERRIDES is modified via =. operator (or .= ?) | 09:01 |
| qschulz | in which case you could redefine the whole MACHINEOVERRIDES | 09:01 |
| qschulz | but I wouldn't surprised if :remove only works on space-separated lists to be sure to have an exact match and not a substring | 09:02 |
| bantu | Hello everyone. What is the expected process for adding the packages of MACHINE_EXTRA_RRECOMMENDS to my image? | 09:04 |
| lucaceresoli | qschulz, anonymous python sounded interesting, but unfortunately does not work: | 09:04 |
| lucaceresoli | unparsed line: 'python __anonymous () {' | 09:04 |
| qschulz | yeah not too surprised tbh :) | 09:05 |
| qschulz | lucaceresoli: and what about: MACHINEOVERRIDES := ${@d.setVar('MACHINEOVERRIDES').replace('mali400:', '')} or something similar? | 09:06 |
| qschulz | in your conf file | 09:06 |
| qschulz | sorry, d.getVar | 09:06 |
| qschulz | hopefully the _append and _prepend are forced to be evaluated when := is used | 09:07 |
| lucaceresoli | qschulz: looks promising. it parses at least :) | 09:11 |
| *** BCMM <BCMM!~BCMM@user/bcmm> has joined #yocto | 09:12 | |
| qschulz | lucaceresoli: bitbake -e to check the value of the variable :) | 09:12 |
| qschulz | or bitbake-getvar now I think? never used it so can't say :| | 09:12 |
| lucaceresoli | qschulz: yes, that's what I'm using but replace() seems to do the wrong thing :-O | 09:13 |
| qschulz | lucaceresoli: ow so? | 09:15 |
| lucaceresoli | qschulz: looks like things are evaluated in the "wrong" order ("wrong" with respect to what I would like) | 09:16 |
| lucaceresoli | By adding: | 09:16 |
| lucaceresoli | MACHINEOVERRIDES := '${@d.getVar("MACHINEOVERRIDES").replace("mali400:", "")}' | 09:17 |
| lucaceresoli | I get as a result: | 09:17 |
| lucaceresoli | $ bitbake -e | grep ^MACHINEOVERRIDES | 09:17 |
| lucaceresoli | MACHINEOVERRIDES="mali400:vcu:vcu:zynqmpev:zynqmp:cortexa72-cortexa53:aarch64:armv8a:sc3c" | 09:17 |
| lucaceresoli | Note: the original string was: "mali400:vcu:zynqmpev:zynqmp:cortexa72-cortexa53:aarch64:armv8a:sc3c" | 09:17 |
| lucaceresoli | Instead or removing "mali400:" it added a "vcu:" in the middle | 09:18 |
| qschulz | lucaceresoli: where did you add this MACHINEOVERRIDES in the conf file? | 09:18 |
| qschulz | before/after the include/require? | 09:18 |
| lucaceresoli | as if the line in the bsp layed doing 'MACHINEOVERRIDES_prepend_zynqmpev = "mali400:vcu:"' were executed twice, with my python line in between the two | 09:19 |
| lucaceresoli | I added the magic line at the very end of my machine conf file, way after the includes | 09:19 |
| qschulz | if you pipe to | awk '/^# \$FOOBAR \[/,/^FOOBAR/' | 09:23 |
| qschulz | you should have the history of MACHINEOVERRIDES and understand where the second vcu is coming from | 09:24 |
| qschulz | but in any case, not working :/ | 09:24 |
| lucaceresoli | qschulz: stupid me, I haven't done it yet! | 09:24 |
| qschulz | you could do the same trick with OVERRIDES though | 09:25 |
| qschulz | maybe that'd work? But bad vendor layer, bad :p | 09:28 |
| *** amitk_ <amitk_!~amit@103.208.71.65> has joined #yocto | 09:29 | |
| qschulz | it makes VERY little sense to use machine overrides as overrides for MACHINEOVERRIDES :) | 09:29 |
| lucaceresoli | qschulz: I've been looking into the history of MACHINEOVERRIDES and it looks fine... I'm more and more puzzled | 09:29 |
| lucaceresoli | qschulz: gaah, my current best plan is to not include that .inc file anymore and just copy the lines I need in my own | 09:30 |
| *** amitk <amitk!~amit@103.208.69.35> has quit IRC (Ping timeout: 250 seconds) | 09:31 | |
| lucaceresoli | qschulz: but thanks for the support! | 09:32 |
| qschulz | lucaceresoli: that is a good plan | 09:33 |
| qschulz | we usually recommend ditching whatever you receive from the vendor and only import (maybe even rewrite) the recipes/conf files you really need | 09:33 |
| lucaceresoli | qschulz: very wise recommendation! For some reason I always try to keep my layer minimal and reuse the base layers as far as possible, but it's not always a good idea, practically speaking. | 09:35 |
| abelloni | well, what is coming from the silicon vendor usually makes sense, what is coming from SoM vendors, I would definitively trash | 09:50 |
| RP | rburton: we have a weird issue with buildtools that your test is highlighting. Basically the pseudo-native built on a system using new buildtools doesn't work to run native binaries | 09:54 |
| RP | relocation error: /home/pokybuild/yocto-worker/buildtools/build/./build/tmp/work/x86_64-nativesdk-pokysdk-linux/buildtools-extended-tarball/1.0-r0/testimage-sdk/bitbake-build-mklpu__g/tmp/sysroots-components/x86_64/pseudo-native/usr/lib/pseudo/lib64/libpseudo.so: symbol dlerror, version GLIBC_2.2.5 not defined in file libc.so.6 with link time reference | 09:54 |
| RP | which is because it should look in libdl afaict | 09:54 |
| *** abelloni <abelloni!~abelloni@scw.piout.net> has quit IRC (Quit: leaving) | 09:56 | |
| RP | rburton: I think it was your staticdev packaging which breaks it. I can fix that but I've realised that any distro with glibc 2.34 by default will break pseudo :( | 10:06 |
| wCPO | mihai: I'm still trying to grasp yocto :) Adding INITRAMFS_SCRIPTS:append = " initramfs-module-non-existing" to our image doesn't seem to change anything. PACKAGE_INSTALL += "initramfs-module-ramrootfs" neither, hmm | 10:06 |
| rburton | RP: huh | 10:07 |
| qschulz | bantu: if you inherit core-image in your image recipe and do NOT have NO_RECOMMENDATIONS set or redefine CORE_IMAGE_BASE_INSTALL, you should have nothing to do | 10:10 |
| *** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Read error: Connection reset by peer) | 10:16 | |
| *** camus1 <camus1!~Instantbi@58.246.136.202> has joined #yocto | 10:16 | |
| *** camus1 is now known as camus | 10:18 | |
| RP | rburton: well, I can't make it work at all, it isn't your patch, its deeper :( | 10:19 |
| rburton | oh great and our CI just broke with the pkgconfig thing jama had | 10:22 |
| RP | I don't know how to fix pseudo with glibc 2.34, I don't have the linker knowledge :( | 10:22 |
| bantu | qschulz: I am using core-image-minimal (which inherits core-image) and don't have any of the other options. I see the packages being built but not included in the image. | 10:31 |
| cocoJoe | core-image set IMAGE_INSTALL ?= "${CORE_IMAGE_BASE_INSTALL} | 10:37 |
| cocoJoe | but core-image-minimal redefine IMAGE_INSTALL | 10:38 |
| cocoJoe | to only include packagegroup-core-boot | 10:39 |
| qschulz | cocoJoe: thanks, missed that one :) | 10:44 |
| * kanavin thinks gnulib should jump off a cliff right now | 10:45 | |
| *** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Ping timeout: 240 seconds) | 10:49 | |
| *** camus <camus!~Instantbi@58.246.136.202> has joined #yocto | 10:49 | |
| cocoJoe | qschulz you are welcome :-D I am struggling with it now, I can get my image to stop including packagegroup-base-extended | 10:51 |
| rburton | RP: looks like clone3 is causing a lot of the problems in containers. is that correctly handled by pseudo? | 10:52 |
| *** abiliomarques <abiliomarques!~abiliomar@44-147-177-143.ftth.glasoperator.nl> has joined #yocto | 10:53 | |
| abiliomarques | hi, I'm trying to compile the basic QEMU image, but I get #error "Please port gnulib freadahead.c to your platform! Look at the definition of fflush, fread, ungetc on your system, then report this to bug-gnulib." while building m4-native | 10:55 |
| rburton | guessing that you're using a pretty old release | 10:55 |
| rburton | what release of yocto are you using | 10:55 |
| rburton | ? | 10:55 |
| mihai | wCPO: you need to add that to a .conf file or in a .bbappend to core-image-minimal-initramfs | 10:56 |
| abiliomarques | well, now that you mention it... I blindly googled quick start and followed the instructions that seemed familiar. I wanted to get the environment warm while I had the lunch break... and yeah, says 2.0 on the URL | 10:56 |
| rburton | abiliomarques: switch to the latest release, it will work | 10:58 |
| *** abelloni <abelloni!~abelloni@shells.bootlin.com> has joined #yocto | 10:58 | |
| abiliomarques | is building the jethro branch ... not to use it as an excuse, but on top of the documentation it says "for the latest version of this manual... see (link)" ... but says "associated with this yocto project release" | 10:59 |
| rburton | RP: so i'm doing the same as you, can you share the uninative tarball you're using? | 11:00 |
| abiliomarques | I should read before assuming things, but I guess other open source projects trained me to click the link to get to the latest documentation (as for the project) | 11:00 |
| rburton | (url of) | 11:00 |
| RP | rburton: how do you mean you're doing the same as me? | 11:01 |
| rburton | abiliomarques: you've obviously not been trained enough by google to check the versions. google constantly returns old docs for our docs | 11:01 |
| rburton | RP: what uninative tarball are you using? | 11:01 |
| RP | rburton: the new 3.3 one merged in master | 11:01 |
| rburton | ah ok | 11:01 |
| rburton | ah yes i didn't see that merge :) | 11:02 |
| rburton | well there goes my theory of making the builds fail in nspawn | 11:02 |
| wCPO | mihai: thanks. I had a suspicion it was something like that. The image and initramfs two different things :) | 11:02 |
| abiliomarques | I know what you mean, I normally get there, and then click on the link on top that bring you to the latest version of the document for the project, not for the release (that's what I mean with other projects "trained me", pavlov style) I'm sorry for such a rookie mistake | 11:03 |
| mihai | wCPO: yup :) | 11:04 |
| wCPO | So the file is indeed getting added now. Now I just need to figure why a qemuboot.conf isn't created for the newest iso | 11:21 |
| RP | Does anyone know if you can tell ld to link to a weak symbol? | 11:28 |
| *** xmn <xmn!~xmn@p200300c37f2e9900d0da590799d0287b.dip0.t-ipconnect.de> has quit IRC (Ping timeout: 250 seconds) | 11:30 | |
| *** xmn <xmn!~xmn@p200300c37f2e9900d0da590799d0287b.dip0.t-ipconnect.de> has joined #yocto | 11:35 | |
| wCPO | "addtask do_write_qemuboot_conf after do_rootfs before do_image" so if I have only modified the initramfs, would it run? | 11:48 |
| override_ | I have an emmc partition /dev/mmcblk0p3 and in my yocto deploy dir I have a rootfs image Verdin-iMX8MM-image.rootfs.ext4, I need suggestions for ways of brining over the rootfs image to the said partition. Feel like what im currently doing is long winded, doing extra mounts.. Is there a way of doing this with just bmap, no cp and mount? | 11:55 |
| *** rob_w <rob_w!~bob@host-82-135-31-73.customer.m-online.net> has quit IRC (Remote host closed the connection) | 11:55 | |
| cocoJoe | override_ is the /dev/mmcblk0p3 on the same machine as the yocto deploy dir? | 11:59 |
| cocoJoe | I have use IMAGE_FSTYPES += "wic wic.bmap" and then bmaptool copy image.wic /dev/mmcblk0p3 | 12:00 |
| override_ | cocoJee, /dev/mmc/blk0p3 is on the board, deploy dir in on the build machine.. | 12:04 |
| *** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV) | 12:04 | |
| override_ | im not trying to write the entire disk image (wic image) this /dev/mblkop3 is just a partition I have on the the board which I can use as a root file system partition | 12:05 |
| override_ | my hope is Verdin-iMX8MM-image.rootfs.ext4 in yocto dir is just an image for the root filesystem.. | 12:06 |
| wCPO | do_write_qemuboot_conf is indeed only called when the the rootfs is modified it seems, not when modifying just the initramfs | 12:09 |
| cocoJoe | override_ ahh okay, I guess you cannot avoid mounting the partition if you want to write to it, but the dd og cat should be able to make a byte wise copy of the rootfs (I think you are right the .ext4 is just the rootfs) | 12:09 |
| override_ | cocoJee: can I somehow uses bamp instead of cat or copy, since bmap is supposedly so much better? | 12:16 |
| cocoJoe | override_ you can try bmaptool copy image.ext4 /dev/partition :-D | 12:25 |
| override_ | cocoJoe: can bmaptool work on partitions directly, or would the partition need to be mounted first? | 12:26 |
| cocoJoe | override_ ahh that is what you mean.. you should write to the device in /dev/mmc/blk0p3, not mount it.. | 12:27 |
| override_ | cocoJoe: im just a little confused becuase i feel like you cant copy to a device cp/cat (you have to mount the device first) but I guess you can bmaptool copy the image onto a device | 12:29 |
| *** jwillikers <jwillikers!~jwilliker@ics141-1.icsincorporated.com> has joined #yocto | 12:30 | |
| override_ | im just a little lost bettween when all mounting is required and if a an image is mounted or copied :/ | 12:30 |
| cocoJoe | override_ you can dd to it and cat should work as well, I dont think cp will work tho | 12:30 |
| override_ | cocoJoe: dd and cat an image onto a disk directly you mean? | 12:31 |
| cocoJoe | yep | 12:31 |
| override_ | cool thanks. | 12:31 |
| cocoJoe | cat image.ext4 /dev/disk/partition | 12:31 |
| override_ | I was definitely doing something long winded before.. | 12:32 |
| cocoJoe | no wait I am not sure about that cat command | 12:32 |
| override_ | youre sure about dd though? | 12:32 |
| cocoJoe | cat image.ext4 > /dev/disk/partition | 12:32 |
| override_ | cool | 12:33 |
| override_ | thanks again | 12:33 |
| cocoJoe | dd bs=4M if=image.ext4 of=/dev/disk/partition conv=fsync oflag=direct status=progress | 12:33 |
| cocoJoe | you might have to play around with the bs | 12:33 |
| override_ | got it, Ill give bmap tool a try too | 12:34 |
| override_ | think we dont have to worry about the bs bs when using bamp | 12:34 |
| override_ | bmap* | 12:34 |
| override_ | what good is setVarFlags("FOO", {"func": True}) for when I can just FOO[func]=True????????? | 12:37 |
| qschulz | override_: you cannot do FOO[func]=True from within a python function | 12:40 |
| override_ | qschulz: ill let that sink in a little.. | 12:41 |
| override_ | wont I have to send the function a reference to FOO when I use setVarFlags too? | 12:42 |
| qschulz | override_: use setVarFlag first, I feel like it's better to do it one flag after the other instead of using a dict | 12:45 |
| qschulz | override_: "the function" ? | 12:45 |
| *** troth <troth!~troth@c-24-8-35-226.hsd1.co.comcast.net> has quit IRC (Quit: Leaving.) | 12:46 | |
| override_ | qschulz: you said I cant call FOO[func] from within a function .. I was trying to figure out why not? call setVarFlags from within a fuction would require passing the function a reference to the object whose flags we're trying to mess around with | 12:48 |
| qschulz | override_: for bitbake python functions, use d | 12:49 |
| qschulz | it's the datastore | 12:49 |
| qschulz | d.getVarFlag to get the value of FOO[func] from within a bitbake python function | 12:49 |
| override_ | and each recipe gets its own datastore Im guessing | 12:50 |
| override_ | seeing some self.d in the manual | 12:50 |
| qschulz | it's a copy of the global datastore I'd guess | 12:53 |
| qschulz | built from the variables contained in configuration files | 12:53 |
| qschulz | that's why you can't pass a variable from one recipe to another | 12:53 |
| *** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Quit: camus) | 12:59 | |
| *** goliath <goliath!~goliath@user/goliath> has joined #yocto | 12:59 | |
| mcon | I am having problems with GitLab pipelines (not strictly a yocto problem, please redirect as needed). After the build step I get all relevant "artifacts", but I didn't find the right spell to make them available to later stages (deploy and test). can someone help? | 13:03 |
| *** Guest81 <Guest81!~Guest81@64.222.164.134> has quit IRC (Quit: Client closed) | 13:05 | |
| *** paulg <paulg!~boodler@104-195-159-20.cpe.teksavvy.com> has joined #yocto | 13:15 | |
| *** xmn <xmn!~xmn@p200300c37f2e9900d0da590799d0287b.dip0.t-ipconnect.de> has quit IRC (Ping timeout: 240 seconds) | 13:17 | |
| *** xmn <xmn!~xmn@p200300c37f2e9900d0da590799d0287b.dip0.t-ipconnect.de> has joined #yocto | 13:18 | |
| rburton | mcon: you need to use the artifacts keyword in build to save them. all artifacts from the build stage will be passed to the test stage, but you can control it with dependencies. https://docs.gitlab.com/ee/ci/yaml/#artifacts | 13:19 |
| rburton | fwiw, we stopped splitting build/test as artifact transfer was a pain | 13:19 |
| mcon | rburton: Thanks, you are always very helpful. Unfortunately I seem to be missing something. Here is my simple .gitlab-ci.yml https://dpaste.org/ib3U and artifacts are indeed produced (I can manually download them from GitLab), but I cannot see them anywhere from later stages. | 13:23 |
| mcon | rburton: I cannot keep build/deploy-test stages together because they will run on different runners (different machines too). | 13:25 |
| kranzo[m] | <mcon> "rburton: Thanks, you are..." <- i think u wanna use the cache | 13:29 |
| kranzo[m] | @mcon for different machines u need shared cache | 13:31 |
| mcon | kranzo[m]: Sorrry I fail to understand what You mean. Can you elaborate, please? | 13:31 |
| kranzo[m] | there is a difference between chache and artifacts on gitlab | 13:31 |
| kranzo[m] | cache | 13:32 |
| mcon | kranzo[m]: I *think* GitLab-CI should do the copying work for me (if I find a way to ask nicely) | 13:32 |
| kranzo[m] | but give me a minute, so that i dont confuse the terms here | 13:32 |
| mcon | kranzo[m]: Thanks. | 13:32 |
| *** camus <camus!~Instantbi@2409:8a1e:9115:d1d0:c8fa:8b7b:7cb5:2f02> has joined #yocto | 13:37 | |
| *** Guest39 <Guest39!~Guest39@64.222.164.134> has joined #yocto | 13:37 | |
| *** sethfoster <sethfoster!~seth@cpe-74-71-192-123.nyc.res.rr.com> has joined #yocto | 13:38 | |
| sethfoster | Hey folks, is this the right place to ask questions about some odd build configurations with setting task dependencies in a yocto build | 13:38 |
| qschulz | sethfoster: ask and you shall discover :) | 13:38 |
| kranzo[m] | mcon you are right, the next stages should download the artifacts, but i remember that there were some unintuitive elements if you use container and multiple runnner, do you compile bare metal or in conatiners? | 13:41 |
| sethfoster | OK! So I'm trying to (hack together) a recipe for building electronjs so I can pass through some configure args to its chromium webcontent renderer. The first problem is that electron uses depot_tools (https://commondatastorage.googleapis.com/chrome-infra-docs/flat/depot_tools/docs/html/depot_tools_tutorial.html) for source control, which doesn't have a fetcher (there's a patchset to land one | 13:41 |
| sethfoster | languishing on bitbake-devel, but not quite what I need). The main tool is called gclient, which is what I'll say from now on. | 13:41 |
| sethfoster | I have a recipe for gclient-native which works great, but it's a fetcher, so I overrode do_fetch in my custom recipe to use it. This therefore requires gclient to be present in the sysroot in do_fetch, which is of course unusual | 13:42 |
| sethfoster | So I set do_fetch[deptask] = "do_populate_sysroot", but that sets _all_ of DEPENDS as a dependency for do_fetch | 13:42 |
| sethfoster | Is there a way to just add do_populate_sysroot for gclient-native as a dependency to electron do_fetch? | 13:42 |
| sethfoster | This is dunfell. | 13:42 |
| sethfoster | Sorry for the essay, figured context would be useful. | 13:43 |
| *** goliath_ <goliath_!~goliath@user/goliath> has joined #yocto | 13:46 | |
| *** goliath <goliath!~goliath@user/goliath> has quit IRC (Ping timeout: 252 seconds) | 13:47 | |
| mcon | kranzo[m]: I'm compiling on bare metal. Also deploy runner is bare metal (currently on the same machine, but that will change soon). As said compilation is completely ok and artifacts *are* uploaded. Problem is I don't see them in later stage :( | 13:49 |
| kranzo[m] | mcon there we go: https://docs.gitlab.com/ee/ci/yaml/index.html#artifactsuntracked | 13:49 |
| kranzo[m] | artifacts | 13:49 |
| kranzo[m] | did you actiuually check if the content is correct in the artifacts? | 13:49 |
| qschulz | sethfoster: I think you need to create a new fetcher for that | 13:50 |
| qschulz | with it's own protocol for detection in src_uri | 13:50 |
| qschulz | e.g. crate:// git:// and the like | 13:50 |
| sethfoster | Yeah that's definitely the correct, maintainable way. I was kind of hoping to have a way to just hack around it for now since the goal is actually to answer the question "is this worth it" | 13:51 |
| sethfoster | I want to see how electron behaves when it's doing drm-direct rendering, but the chromium binaries in their official builds don't support it | 13:52 |
| sethfoster | I guess optimization like limiting the dependency set here doesn't really matter just for evaluation | 13:53 |
| mcon | kranzo[m]: Yes. I can confirm artifacts manually downloaded from Gitlab are actually OK (an archive named "artifcacts" containing all relevant files). | 13:53 |
| mcon | IMHO Problem is actually in the preparation of later stages | 13:54 |
| qschulz | sethfoster: https://github.com/meta-rust/meta-rust/blob/master/lib/crate.py from my IRC logs, discussed for artifactory a bit more than a week ago | 13:54 |
| kranzo[m] | mcon: yeah i understood and i remember i had the problem as well but i think my problem was another one ... | 13:55 |
| qschulz | sethfoster: otherwise look into what's in do_populate_sysroot and try to check if there's a way to bypass DEPENDS for that one | 13:56 |
| qschulz | mmmmmmmmm | 13:56 |
| sethfoster | qschulz: oh that's a lot simpler than I had been assuming. i guess fetchers are basically free to rely on the build host having it setup? | 13:56 |
| sethfoster | having it setup = having the tool used for the fetch setup, sorry | 13:56 |
| qschulz | what about: DEPENDS_task-fetch = "gclient-native" in addition to do_fetch[deptask] = "do_populate_sysroot" ? | 13:56 |
| qschulz | for hacking around | 13:56 |
| qschulz | this overrides DEPENDS for the fetch task to be gclient-native only | 13:57 |
| sethfoster | ooh I think that's exactly what I would want | 13:57 |
| *** goliath_ <goliath_!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV) | 13:58 | |
| sethfoster | Although I think that your linked example actually solves my x/y problem - I had been assuming that the only way to add a fetcher would be to make a local fork of bitbake and try and get it upstreamed, but of course I can just add to BBPATH in the layer | 13:58 |
| wCPO | Is it possible to use addtask with only before? | 13:58 |
| sethfoster | I'll try both. Thank you qschulz! | 13:59 |
| barath | does anyone know whether uninative is enabled by default? the manual says that poky includes it by `require conf/distro/include/yocto-uninative.inc` but grepping through poky, I can't find anything that uses it or a file by that name | 14:06 |
| barath | is the documentation outdated and it's enabled by default in some other way? | 14:06 |
| kranzo[m] | mcon: https://gitlab.com/kranzo/ci-test/ | 14:11 |
| kranzo[m] | have a look at the last to pipelines.. in this way the pipeline failes without the untracked flag | 14:11 |
| qschulz | sethfoster: good luck :) | 14:12 |
| *** sakoman <sakoman!~steve@172.243.4.16> has joined #yocto | 14:13 | |
| qschulz | barath: what's the url of the doc you're reading? | 14:13 |
| qschulz | but yes, uninative should be enabled by default | 14:13 |
| qschulz | it was on thud, the only release I really worked with | 14:13 |
| qschulz | it was enabled with uninative in INHERIT | 14:14 |
| qschulz | I think it was enabled back in krogoth or jethro already (since my previous company disabled it because it broke icecc in those older versions) | 14:14 |
| barath | https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#ref-classes-uninative | 14:15 |
| barath | "In the Poky reference distribution this is enabled by default through meta/conf/distro/include/yocto-uninative.inc. Other distributions that do not derive from poky can also "require conf/distro/include/yocto-uninative.inc" " | 14:15 |
| qschulz | barath: docs.yoctoproject.org is the up-to-date version but the one you're looking at is not too old either (stopped at dunfell) | 14:16 |
| rburton | barath: http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta-poky/conf/distro/poky.conf#n71 | 14:16 |
| barath | oh thanks | 14:17 |
| barath | Im an idiot | 14:17 |
| barath | I used ripgrep in the poky repository and it ignored/didn't search through the submodules, which includes meta-poky | 14:18 |
| barath | oh and I did not know that the mega manual I always look at is actually out of date... thanks for that too! | 14:19 |
| rburton | meta-poky isn't a submodule, it wouldn't know to ignore it | 14:19 |
| kranzo[m] | barath:... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/95d21f478753d28e48abc20668acca380ce37418) | 14:19 |
| qschulz | seems like the docs need an update for that one since yocto-uninative isn't explicitly included anywhere... to what it should be replaced with.. i don't know | 14:20 |
| barath | strange wrt ripgrep ignoring it then | 14:21 |
| barath | possibly due to our poky being a submodule itself, in our yocto dir/project | 14:21 |
| qschulz | didn't find anything in poky git repo | 14:21 |
| kranzo[m] | > <@barath:matrix.org> strange wrt ripgrep ignoring it then | 14:22 |
| kranzo[m] | > possibly due to our poky being a submodule itself, in our yocto dir/project | 14:22 |
| kranzo[m] | by default rg is ignoring everything metioned in any vcs ignore files | 14:22 |
| *** tlwoerner <tlwoerner!~tlwoerner@pppoe-209-91-167-254.vianet.ca> has quit IRC (Remote host closed the connection) | 14:24 | |
| barath | well poky's .gitignore contains !meta-poky, which should negate the earlier meta-* entry... but it seems that !meta-poky does actually work for ripgrep | 14:25 |
| barath | oh well | 14:25 |
| rburton | yeah, atom also failed to parse the gitignore correctly | 14:25 |
| *** Guest86 <Guest86!~Guest86@ppp78-37-187-116.pppoe.avangarddsl.ru> has joined #yocto | 14:25 | |
| barath | *!meta-poky does not actually work for ripgrep | 14:26 |
| *** d0ku <d0ku!~d0ku@178.43.198.70.ipv4.supernova.orange.pl> has quit IRC (Remote host closed the connection) | 14:42 | |
| *** goliath <goliath!~goliath@user/goliath> has joined #yocto | 14:42 | |
| mcon | kranzo[m]: If I understand correctly your example this doesn't really mimic my case. Of course next stage, running exactly in the same place as the previous one will find "leftovers". problem happens when you either run on separate machines or you use "manual" stages to decouple build and deploy (possibly with cleanout in the middle). | 14:44 |
| RP | https://sourceware.org/pipermail/libc-help/2021-August/005985.html | 14:44 |
| RP | khem: if you have any ideas on the above? :/ | 14:45 |
| RP | I'm out of ideas on how to fix this at this point :( | 14:45 |
| kranzo[m] | mcon: it is up uand downloading so should work on different machines | 14:46 |
| rburton | mcon: are you remembering that everything will be in artifacts/ in the test job? | 14:48 |
| kranzo[m] | mcon: could you post the log of your jobs? would help to debug | 14:58 |
| rburton | replacing your scripts with "echo THIS IS A BUILD IMAGE >tmp/deploy/etc" in build and then checking the files exist in test would be a first step to make sure the jobs are doing what you expect | 14:59 |
| mcon | rburton: Sorry I don't understand what you mean. My problem is "Downloading artifacts" step is completely absent from my deploy logs (see: https://dpaste.org/QDoR) | 15:00 |
| rburton | mcon: fwiw our test jobs had needs: job: build-foo in to get the right artifacts in the right job | 15:02 |
| *** Guest86 <Guest86!~Guest86@ppp78-37-187-116.pppoe.avangarddsl.ru> has quit IRC (Quit: Client closed) | 15:04 | |
| barath | does anyone know if there's a quick way to check whether my build/image is using the uninative tar ball? I see it downloaded, but... | 15:19 |
| *** bps <bps!~bps@user/bps> has quit IRC (Ping timeout: 268 seconds) | 15:19 | |
| rburton | NATIVELSBSTRING in the build configuration will say 'universal' instead of eg ubuntu-20.04 | 15:20 |
| prabhakarlad | Hi all, I am wondering why timeout utility is not included as part of coreutils, there is a comment stating "gets a special treatment and is not included in this", can i get around and install timeout utility? | 15:25 |
| *** awafaa <awafaa!sid716@highgate.irccloud.com> has quit IRC (Read error: Connection reset by peer) | 15:26 | |
| *** YogeshSiraswar_ <YogeshSiraswar_!sid500596@highgate.irccloud.com> has quit IRC (Read error: Connection reset by peer) | 15:26 | |
| *** dagmcr <dagmcr!sid323878@highgate.irccloud.com> has quit IRC (Read error: Connection reset by peer) | 15:26 | |
| *** armpit <armpit!sid501830@id-501830.highgate.irccloud.com> has quit IRC (Read error: Connection reset by peer) | 15:26 | |
| *** CosmicPenguin <CosmicPenguin!sid489106@id-489106.highgate.irccloud.com> has quit IRC (Read error: Connection reset by peer) | 15:27 | |
| *** behanw <behanw!uid110099@highgate.irccloud.com> has quit IRC (Read error: Connection reset by peer) | 15:27 | |
| *** NishanthMenon_ <NishanthMenon_!sid138049@highgate.irccloud.com> has quit IRC (Read error: Connection reset by peer) | 15:27 | |
| rburton | prabhakarlad: its part of coreutils... | 15:28 |
| *** lucaceresoli <lucaceresoli!~lucaceres@77.244.183.192> has quit IRC (Quit: Leaving) | 15:29 | |
| prabhakarlad | coreutils is included as part of my image (core-image-minimal), but the timeout utility seems to be missing. | 15:30 |
| *** NishanthMenon_ <NishanthMenon_!sid138049@highgate.irccloud.com> has joined #yocto | 15:31 | |
| *** CosmicPenguin <CosmicPenguin!sid489106@id-489106.highgate.irccloud.com> has joined #yocto | 15:31 | |
| *** behanw <behanw!uid110099@id-110099.highgate.irccloud.com> has joined #yocto | 15:31 | |
| *** dagmcr <dagmcr!sid323878@highgate.irccloud.com> has joined #yocto | 15:31 | |
| *** YogeshSiraswar_ <YogeshSiraswar_!sid500596@id-500596.highgate.irccloud.com> has joined #yocto | 15:32 | |
| *** armpit <armpit!sid501830@id-501830.highgate.irccloud.com> has joined #yocto | 15:32 | |
| *** awafaa <awafaa!sid716@highgate.irccloud.com> has joined #yocto | 15:32 | |
| rburton | here its at /usr/bin/timeout.coreutils, with a symlink | 15:34 |
| rburton | ah, the symlink might be missing? | 15:35 |
| rburton | no, should be there | 15:35 |
| prabhakarlad | ls /usr/bin/timeout.coreutils | 15:35 |
| prabhakarlad | ls: /usr/bin/timeout.coreutils: No such file or directory | 15:35 |
| rburton | are you sure you actually have coreutils installed | 15:36 |
| prabhakarlad | Yes pretty sure doing a bitbake -c cleansstate coreutils and then later bitbake core-image-minimal does actually build coreutils. | 15:41 |
| qschulz | you can have something built but not installed in an image | 15:42 |
| rburton | the easiest way is to just look at the image manifest (next to the image), or the package manager on the target | 15:42 |
| *** xmn <xmn!~xmn@p200300c37f2e9900d0da590799d0287b.dip0.t-ipconnect.de> has quit IRC (Quit: ZZZzzz…) | 15:43 | |
| rburton | JPEW: we might want to consider putting 'extended' pkgdata in a different directory tree, as stuff like oe-pkgdata-util iterates over every file (and aborts when it tries to parse a json.zstd) | 15:44 |
| *** Frozen-compiler <Frozen-compiler!~Frozen-co@95.168.120.19> has quit IRC (Quit: Client closed) | 15:46 | |
| JPEW | rburton: Ah, I didn't realize that | 15:46 |
| rburton | just discovered the hard way :) | 15:46 |
| JPEW | Would `${PKGDATA_DIR}/extended` be OK? | 15:48 |
| rburton | yeah | 15:48 |
| JPEW | K | 15:48 |
| prabhakarlad | right looking at the it just has the below utils: | 15:48 |
| prabhakarlad | cat.coreutils chmod.coreutils cp.coreutils dd.coreutils false.coreutils kill.coreutils ls.coreutils mknod.coreutils pwd.coreutils rmdir.coreutils stat.coreutils sync.coreutils true.coreutils | 15:48 |
| prabhakarlad | chgrp.coreutils chown.coreutils date.coreutils echo.coreutils hostname.coreutils ln.coreutils mkdir.coreutils mv.coreutils rm.coreutils sleep.coreutils stty.coreutils touch.coreutils uname.coreutils | 15:48 |
| prabhakarlad | s/the it/ the image it | 15:49 |
| rburton | what version of yocto? any interesting layers? | 15:49 |
| prabhakarlad | yocto-3.2.1 | 15:50 |
| rburton | AC_CHECK_FUNCS([sigsuspend], | 15:52 |
| rburton | gl_ADD_PROG([optional_bin_progs], [timeout])) | 15:52 |
| rburton | you might not have sigssuspend for some reason? | 15:52 |
| rburton | check the configure log | 15:53 |
| *** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV) | 15:53 | |
| prabhakarlad | rburton: good point let me check the configure log. | 16:05 |
| *** dev1990 <dev1990!~dev@dynamic-78-8-55-226.ssp.dialog.net.pl> has joined #yocto | 16:13 | |
| *** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has quit IRC (Quit: Ex-Chat) | 16:23 | |
| RP | vmeson: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found (required by /media/build1/poky/build/tmp/work/x86_64-linux/rust-native/1.54.0-r0/rustc-1.54.0-src/build/bootstrap/debug/deps/libproc_macro_error_attr-9c7a09885c50c72e.so) | 16:27 |
| RP | vmeson: I think this may struggle in cases where uninative and the host libc version differ | 16:29 |
| vmeson | RP fun! | 16:29 |
| barath | rburton: ty | 16:32 |
| RP | vmeson: glibc 2.34 and pseudo break with uninative and I have no idea how to fix it | 16:32 |
| RP | vmeson: I'm therefore a little frustrated with these kinds of errors atm | 16:33 |
| prabhakarlad | NOTE: coreutils-8.32-r0 do_package: update-alternatives --remove lbracket /usr/bin/lbracket.coreutils removes update-alternatives --remove timeout /usr/bin/timeout.coreutils | 16:34 |
| *** zpfvo <zpfvo!~fvo@i59F44C1B.versanet.de> has quit IRC (Remote host closed the connection) | 16:53 | |
| kranzo[m] | what is the merge cycle for master-next into master in poky? | 17:07 |
| kranzo[m] | or better oe-core | 17:07 |
| kranzo[m] | and how can i request a backport to hardknott? :D | 17:09 |
| smurray | kranzo[m]: that first one's a RP question. For the second, you'd send a request for a backport to the oe-core list after it's gotten into master | 17:10 |
| *** vmeson <vmeson!~rmacleod@198-48-226-187.cpe.pppoe.ca> has quit IRC (Quit: Konversation terminated!) | 17:10 | |
| *** vmeson <vmeson!~rmacleod@198-48-226-187.cpe.pppoe.ca> has joined #yocto | 17:13 | |
| RP | kranzo[m]: which patch are we talking about? Some merge quickly, some need more testing | 17:13 |
| RP | kranzo[m]: speed depends on how many build failures we get in testing too | 17:14 |
| kranzo[m] | my patch from yesterday got merged into master (Allow global override of golang GO_DYNLINK), i was just thinking about the timescales to expect :) | 17:16 |
| kranzo[m] | so am i right, patches get applied to master-next, pipelines run (how often?), if success merge into master? | 17:17 |
| *** nerdboy_p is now known as nerdboy | 17:21 | |
| *** BCMM <BCMM!~BCMM@user/bcmm> has quit IRC (Ping timeout: 268 seconds) | 17:23 | |
| *** florian <florian!~florian@dynamic-093-133-184-098.93.133.pool.telefonica.de> has joined #yocto | 17:37 | |
| *** bps <bps!~bps@80.71.142.18.ipv4.parknet.dk> has joined #yocto | 17:39 | |
| RP | kranzo[m]: that is the correct flow, yes. The tests are batched and run manually and take hours | 17:52 |
| *** bps <bps!~bps@user/bps> has quit IRC (Ping timeout: 248 seconds) | 18:00 | |
| *** tlwoerner <tlwoerner!~tlwoerner@pppoe-209-91-167-254.vianet.ca> has joined #yocto | 18:06 | |
| *** florian <florian!~florian@dynamic-093-133-184-098.93.133.pool.telefonica.de> has quit IRC (Ping timeout: 252 seconds) | 18:07 | |
| *** tp43_ <tp43_!~ndeem@2001:1970:501a:e201:7dd8:7bb5:b166:9697> has joined #yocto | 18:20 | |
| *** tp43_ <tp43_!~ndeem@2001:1970:501a:e201:7dd8:7bb5:b166:9697> has quit IRC (Ping timeout: 250 seconds) | 18:44 | |
| *** bps <bps!~bps@80.71.142.18.ipv4.parknet.dk> has joined #yocto | 18:50 | |
| *** bps <bps!~bps@user/bps> has quit IRC (Ping timeout: 248 seconds) | 18:56 | |
| *** mranostaj <mranostaj!~mranostaj@185.193.126.133> has quit IRC (Remote host closed the connection) | 19:15 | |
| *** mranosta1 is now known as mranostaj | 19:15 | |
| *** bps <bps!~bps@user/bps> has joined #yocto | 19:21 | |
| tlwoerner | fray: Error, the PACKAGE_ARCHS variable (all any noarch ${PACKAGE_EXTRA_ARCHS:tune-mips32r2el-24kc} qemumips) for DEFAULTTUNE (mips32r2el-24kc) does not contain TUNE_PKGARCH (${MIPSPKGSFX_VARIANT:tune-mips32r2el-24kc}-nf) | 19:35 |
| tlwoerner | DEFAULTTUNE = "mips32r2el" works but DEFAULTTUNE = "mips32r2el-24kc" doesn't | 19:35 |
| vmeson | halstead: this email isn't rendering, have you seen that happen before: https://lists.openembedded.org/g/openembedded-core/message/154863?p=,,,20,0,0,0::created,0,CVE-2021-3682,20,1,0,84940037 | 19:38 |
| vmeson | Firefox on Linux of course. Trying Chomium. | 19:38 |
| vmeson | halstead: asme there. | 19:39 |
| vmeson | same even. | 19:39 |
| *** ssajal <ssajal!~ssajal@bras-base-otwaon0150w-grc-06-184-147-146-64.dsl.bell.ca> has joined #yocto | 19:40 | |
| vmeson | should ssajal open a defect halstead ? | 19:40 |
| paulg | are we sure an empty msg wasn't sent? | 19:46 |
| paulg | w3m can display https://lists.openembedded.org/g/openembedded-core/message/154862 but not 154863 | 19:47 |
| vmeson | paulg: yes, that was my first question! ;-) | 19:47 |
| * ssajal gets some rotten tomatoes and eggs | 19:48 | |
| * paulg thinks ssajal would be throwing tomato skins and egg shells based on that empty mail. | 19:48 | |
| *** florian <florian!~florian@dynamic-093-133-184-098.93.133.pool.telefonica.de> has joined #yocto | 20:07 | |
| halstead | vmeson: I'll request the unmodified mbox file and see what's going on. It takes a few hours. | 20:14 |
| *** tp43_ <tp43_!~ndeem@2001:1970:501a:e201:7dd8:7bb5:b166:9697> has joined #yocto | 20:24 | |
| *** Vonter <Vonter!~Vonter@user/vonter> has quit IRC (Ping timeout: 245 seconds) | 20:33 | |
| *** amitk_ <amitk_!~amit@103.208.71.65> has quit IRC (Ping timeout: 250 seconds) | 20:53 | |
| *** xmn <xmn!~xmn@p200300c37f2e990025ee5c6938528ed3.dip0.t-ipconnect.de> has joined #yocto | 20:56 | |
| khem | https://www.openssl.org/blog/blog/2021/06/17/OpenSSL3.0ReleaseCandidate/ | 20:57 |
| khem | So I wonder if it is yet another pain to migrate coming our way hoping to have it in next LTS | 20:58 |
| vmeson | khem: yes, I tried to upgrade to 3.0-alpha-X months ago and there were some problems. I'm trying to arrange for Yi Zhao to have time to work on it for that we're ready to merge early in the next release. | 21:09 |
| *** leon-anavi <leon-anavi!~Leon@78.130.197.211> has quit IRC (Quit: Leaving) | 21:11 | |
| *** abiliomarques <abiliomarques!~abiliomar@44-147-177-143.ftth.glasoperator.nl> has quit IRC (Remote host closed the connection) | 21:20 | |
| *** jwessel` <jwessel`!~jwessel@unknown-105-123.windriver.com> has joined #yocto | 21:22 | |
| *** jwessel` <jwessel`!~jwessel@unknown-105-123.windriver.com> has left #yocto | 21:24 | |
| *** jwessel <jwessel!~jwessel@unknown-105-123.windriver.com> has joined #yocto | 21:27 | |
| *** jwessel <jwessel!~jwessel@unknown-105-123.windriver.com> has quit IRC (Quit: Coyote finally caught me) | 21:28 | |
| *** jwessel <jwessel!~jwessel@unknown-105-123.windriver.com> has joined #yocto | 21:28 | |
| *** Guest39 <Guest39!~Guest39@64.222.164.134> has quit IRC (Quit: Client closed) | 21:32 | |
| *** tgamblin <tgamblin!~tgamblin@2607:fea8:c29d:d7c0::f245> has quit IRC (Ping timeout: 240 seconds) | 21:42 | |
| *** tgamblin <tgamblin!~tgamblin@cpe64777de11593-cm64777de11590.cpe.net.cable.rogers.com> has joined #yocto | 21:42 | |
| *** sethfoster <sethfoster!~seth@cpe-74-71-192-123.nyc.res.rr.com> has quit IRC (Quit: Lost terminal) | 21:48 | |
| *** darknighte <darknighte!sid214177@user/darknighte> has joined #yocto | 21:52 | |
| *** xmn <xmn!~xmn@p200300c37f2e990025ee5c6938528ed3.dip0.t-ipconnect.de> has quit IRC (Quit: ZZZzzz…) | 22:00 | |
| *** dev1990 <dev1990!~dev@dynamic-78-8-55-226.ssp.dialog.net.pl> has quit IRC (Quit: Konversation terminated!) | 22:03 | |
| *** dvorkindmitry <dvorkindmitry!~dvorkindm@5.167.98.73> has joined #yocto | 22:34 | |
| dvorkindmitry | how to enable gcc-plugins for gcc-cross? | 22:34 |
| *** zyga <zyga!~zyga@ip-81-15-135-168.unregistered.net.exatel.pl> has quit IRC (Ping timeout: 250 seconds) | 23:09 | |
| *** florian <florian!~florian@dynamic-093-133-184-098.93.133.pool.telefonica.de> has quit IRC (Ping timeout: 252 seconds) | 23:19 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!