Tuesday, 2023-08-22

*** warthog9 <warthog9!warthog9@proxy.monkeyblade.net> has quit IRC (Remote host closed the connection)00:31
*** Wouter0100670440 <Wouter0100670440!~Wouter010@entry.nbg.netvos.nl> has quit IRC (Quit: The Lounge - https://thelounge.chat)00:31
*** Wouter0100670440 <Wouter0100670440!~Wouter010@entry.nbg.netvos.nl> has joined #yocto00:31
*** warthog9 <warthog9!warthog9@proxy.monkeyblade.net> has joined #yocto00:34
mischiefMarian46: maybe pass rdinit=/bin/...00:37
mischiefor just install your own symlink for init somewhere in the image recipe00:37
*** otavio <otavio!~otavio@201-35-186-235.user3p.brasiltelecom.net.br> has joined #yocto00:42
khemMarian46: start with https://docs.yoctoproject.org/dev-manual/building.html?highlight=initramfs#building-an-initial-ram-filesystem-initramfs-image01:03
*** Ablu <Ablu!~Ablu@user/Ablu> has quit IRC (Ping timeout: 245 seconds)01:06
*** jclsn <jclsn!~jclsn@2a04:4540:6524:7200:2ce:39ff:fecf:efcd> has quit IRC (Ping timeout: 260 seconds)01:08
*** Ablu <Ablu!~Ablu@user/Ablu> has joined #yocto01:10
khembelgianguy: you might look into uefi support and its good for arm64 look into meta-arm, however, yocto does not provide infra for signing keys etc. its left to the distros01:12
khembelgianguy: I would suggest to look into debian secure boot process01:12
*** Marian46 <Marian46!~Marian@c-73-219-138-101.hsd1.nh.comcast.net> has quit IRC (Quit: Client closed)01:18
*** Marian88 <Marian88!~Marian@c-73-219-138-101.hsd1.nh.comcast.net> has joined #yocto01:18
Marian88Finally I managed to boot a initramfs using: INITRAMFS_SCRIPTS = " initramfs-boot ". The only problem that I still have is the root password. I'm using -EXTRA_IMAGE_FEATURES ?= "debug-tweaks", but the initramfs image seems to not have this option enabled01:21
Marian88genericx86-64 login: root01:21
Marian88Login incorrect01:21
Marian88genericx86-64 login: root01:21
Marian88Login incorrect01:21
Marian88genericx86-64 login:01:21
Marian88any idea01:21
*** Marian88 <Marian88!~Marian@c-73-219-138-101.hsd1.nh.comcast.net> has quit IRC (Quit: Client closed)01:25
*** Marian55 <Marian55!~Marian@c-73-219-138-101.hsd1.nh.comcast.net> has joined #yocto01:29
khemMarian55:  Perhaps add  IMAGE_FEATURES:append = " empty-root-password" in local.conf01:37
*** starblue <starblue!~juergen@dslb-088-078-099-052.088.078.pools.vodafone-ip.de> has quit IRC (Ping timeout: 245 seconds)01:42
*** starblue <starblue!~juergen@dslb-088-078-109-047.088.078.pools.vodafone-ip.de> has joined #yocto01:44
*** xmn <xmn!~xmn@2600:4040:9390:8c00:e11a:3faa:e378:93d1> has quit IRC (Quit: ZZZzzz…)01:45
*** Marian55 <Marian55!~Marian@c-73-219-138-101.hsd1.nh.comcast.net> has quit IRC (Quit: Client closed)01:50
*** belgianguy <belgianguy!~belgiangu@ptr-651fbf6nccqxxk5pil6.18120a2.ip6.access.telenet.be> has quit IRC (Ping timeout: 245 seconds)01:50
*** xmn <xmn!~xmn@2600:4040:9390:8c00:5125:e59:9dab:e455> has joined #yocto01:51
*** Marian89 <Marian89!~Marian@c-73-219-138-101.hsd1.nh.comcast.net> has joined #yocto01:59
Marian89I managed to fix it via "+IMAGE_FEATURES:append = "${EXTRA_IMAGE_FEATURES}""01:59
Marian89in the -initramfs.bb image01:59
*** LocutusOfBorg <LocutusOfBorg!~locutusof@> has quit IRC (Read error: Connection reset by peer)02:14
*** LocutusOfBorg <LocutusOfBorg!~locutusof@> has joined #yocto02:16
*** jclsn <jclsn!~jclsn@2a04:4540:6524:1400:2ce:39ff:fecf:efcd> has joined #yocto02:32
*** xmn <xmn!~xmn@2600:4040:9390:8c00:5125:e59:9dab:e455> has quit IRC (Ping timeout: 248 seconds)03:17
*** xmn <xmn!~xmn@2600:4040:9390:8c00:68b3:cbd9:125:9481> has joined #yocto03:21
*** otavio <otavio!~otavio@201-35-186-235.user3p.brasiltelecom.net.br> has quit IRC (Ping timeout: 244 seconds)04:45
*** rob_w <rob_w!~bob@host-82-135-31-73.customer.m-online.net> has joined #yocto06:03
*** Xhivo <Xhivo!~Xhivo@> has joined #yocto06:13
*** goliath <goliath!~goliath@user/goliath> has joined #yocto06:15
*** valdemaras <valdemaras!~valdemara@> has joined #yocto06:17
*** rfuentess <rfuentess!~rfuentess@lfbn-lyo-1-1294-101.w86-207.abo.wanadoo.fr> has joined #yocto06:32
*** warthog9 <warthog9!warthog9@proxy.monkeyblade.net> has quit IRC (Quit: Leaving)06:39
*** Wouter0100670440 <Wouter0100670440!~Wouter010@entry.nbg.netvos.nl> has quit IRC (Ping timeout: 256 seconds)06:40
*** xmn <xmn!~xmn@2600:4040:9390:8c00:68b3:cbd9:125:9481> has quit IRC (Quit: ZZZzzz…)06:43
*** mckoan|away is now known as mckoan06:47
mckoangood morning06:47
*** frieder <frieder!~frieder@> has joined #yocto06:52
*** pgowda_ <pgowda_!uid516182@2a03:5180:f:3::7:e056> has joined #yocto06:52
*** valdemaras <valdemaras!~valdemara@> has quit IRC (Quit: valdemaras)06:54
*** warthog9 <warthog9!warthog9@proxy.monkeyblade.net> has joined #yocto06:54
*** Schlumpf <Schlumpf!~Schlumpf@> has joined #yocto06:58
*** xmn <xmn!~xmn@2600:4040:9390:8c00:68b3:cbd9:125:9481> has joined #yocto07:02
*** AKN <AKN!~AKN@> has joined #yocto07:21
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto07:56
*** olani- <olani-!~olani@wlan-gw.se.axis.com> has quit IRC (Ping timeout: 246 seconds)07:56
*** paulg <paulg!~paulg@198-84-237-91.cpe.teksavvy.com> has joined #yocto07:59
*** valdemaras <valdemaras!~valdemara@> has joined #yocto08:18
*** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has joined #yocto08:20
*** florian_kc <florian_kc!~florian@> has joined #yocto08:34
kanaviny2038 facepalm of the day08:47
kanavin_dbus_get_real_time (long *tv_sec,08:47
kanavin                     long *tv_usec)08:47
kanavinused throughout dbus, obviously08:47
RPkanavin: it isn't something you'd think about :/08:48
kanavinRP: not quite; the implementation does08:49
kanavin  struct timeval t;08:49
kanavin  gettimeofday (&t, NULL);08:49
kanavin  if (tv_sec)08:49
kanavin    *tv_sec = t.tv_sec;08:49
kanavin  if (tv_usec)08:49
kanavin    *tv_usec = t.tv_usec;08:49
kanavinat which point it would be prudent to look up data types in timeval08:50
kanavin(tv_sec would be time_t)08:50
RPkanavin: ah right :/08:52
*** Guest50 <Guest50!~Guest62@host-80-41-74-129.as13285.net> has joined #yocto08:56
Guest50Isd there any way to lilst valid target architectures for a recipe which builds in a different subdirectory of tmp/work on a different computer ?08:57
Guest50basically a recipe build on the correct subdirectory of /tmp/work on my station and finds what it needs there, but on a different computer it builds in another subdirectory and does not find one projects it needs to build come of its libraries08:58
Guest50to build ONE of its libraries*08:59
Guest50and decides to ignore this during its do_configure09:00
Guest50not sure how to change the recipe to "force" it into the right build/tmp/work/ subdirectory09:00
Guest50never needed to on my station09:01
*** Xhivo <Xhivo!~Xhivo@> has quit IRC (Ping timeout: 246 seconds)09:06
ptsnevesGuest50: I do not think it is a good idea to depend on the tmp/work directory. If you need outputs from the recipe you should deploy it somewhere09:08
Guest50but how comes the recipe builds in a different subdirectory on a different machine?09:09
*** xmn <xmn!~xmn@2600:4040:9390:8c00:68b3:cbd9:125:9481> has quit IRC (Quit: ZZZzzz…)09:11
kanavinRP: what I don't understand is why c compiler is happy with that. Surely assigning long long to long or long to int should be at least a warning?09:13
RPkanavin: I'd have thought the compiler would show a warning09:13
RPprobably depends on the compiler options?09:14
kanavinRP: I just wrote a trivial program to check and there's not warning, not with Wall09:14
kanavinis there some Wreally-super-duper-all maybe?09:14
*** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has joined #yocto09:16
Guest50RP: -Wall -Wextra ... Some diagnostics for non-ISO practices are controlled by specific warning options other than -Wpedantic, but are also made errors by -pedantic-errors09:26
Guest50RP: https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html09:27
kanavinGuest50, all, extra, pedantic. Adding all three still doesn't make a warning.09:27
Guest50RP:  version of gcc are you using?09:28
kanavinI guess the question is for me? 12.2.009:28
Guest50try issuing a sizeof() of the respective integers,09:28
kanavin4 for int, 8 for long long09:30
kanavinno warning09:30
kanavin#include <stdio.h>09:32
kanavinint main(){09:32
kanavinint a;09:32
kanavinlong long b = -3000000000;09:32
kanavina = b;09:32
kanavinprintf("%d %ld\n",a, sizeof(a));09:32
kanavinprintf("%lld %ld\n",b, sizeof(b));09:32
RPkanavin: this is more khem's area than mine to tbh, I just work out how to build the compilers...09:32
kanavinRP: I think it's more or less clear gcc won't help, and maybe there's some awful reason why :-(09:34
kanavinsuch as 'programmers should know what they're doing, and it's their fault if they mess up'09:34
RPkanavin: I fear that may be the case09:35
*** MrFrank <MrFrank!~MrFrank@mx1.fracta.dev> has quit IRC (Ping timeout: 246 seconds)09:36
sudipkanavin: you can use -Wconversion09:39
sudipI used that with your code and:09:39
sudiptest.c:7:5: warning: conversion from ‘long long int’ to ‘int’ may change value [-Wconversion]09:39
kanavinsudip, right! why is it not in all or extra or pedantic?09:40
*** MrFrank <MrFrank!~MrFrank@mx1.fracta.dev> has joined #yocto09:42
* sudip has no idea why09:42
ptsnevesDoes anybody know why in get_taskhahs@siggen.py, the iteration of self.file_checksum_values[tid] is unsorted? I had 2 signatures which are identical except the file list is in a slightly different order leading to a different taskhsh09:42
rburtonptsneves: sounds like a bug to me09:45
*** wyre_ <wyre_!~wyre@user/wyre> has joined #yocto09:45
*** wyre <wyre!~wyre@user/wyre> has quit IRC (Read error: Connection reset by peer)09:45
ptsnevesrburton: ok. Will try to sort the list and see if the hashes come out correctly09:45
RPptsneves: definitely a bug09:54
Guest50still looking for an answer to previously posted question(s)10:03
Guest50still need to understand so I can rectify the problem10:04
*** olani- <olani-!~olani@wlan-gw.se.axis.com> has joined #yocto10:05
ptsnevesGuest50: Try bitbake-getvar -r <recipe> WORKDIR on both machines and see where the values come from10:05
Guest50ptsneves: Thank you, will try that as soon as the respective builds finish10:06
*** starblue <starblue!~juergen@dslb-088-078-109-047.088.078.pools.vodafone-ip.de> has quit IRC (Ping timeout: 250 seconds)10:06
*** Wouter0100670440 <Wouter0100670440!~Wouter010@entry.nbg.netvos.nl> has joined #yocto10:07
*** wyre_ <wyre_!~wyre@user/wyre> has quit IRC (Quit: ZNC 1.8.2 - https://znc.in)10:08
*** starblue <starblue!~juergen@dslb-088-078-109-047.088.078.pools.vodafone-ip.de> has joined #yocto10:08
*** wyre <wyre!~wyre@user/wyre> has joined #yocto10:09
*** MrFrank <MrFrank!~MrFrank@mx1.fracta.dev> has quit IRC (Read error: Connection reset by peer)10:10
*** Schlumpf <Schlumpf!~Schlumpf@> has quit IRC (Quit: Client closed)10:11
*** Schlumpf <Schlumpf!~Schlumpf@> has joined #yocto10:11
ptsnevesRP: Ironically the dump_sigfile function sorts a_data['file_checksum_values']. I only spotted this because i opened the signatures directly with zstdcat10:13
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has quit IRC (Ping timeout: 246 seconds)10:13
*** Guest50 <Guest50!~Guest62@host-80-41-74-129.as13285.net> has quit IRC (Quit: Client closed)10:14
*** Schlumpf48 <Schlumpf48!~Schlumpf@> has joined #yocto10:15
*** Schlumpf <Schlumpf!~Schlumpf@> has quit IRC (Ping timeout: 246 seconds)10:19
*** MrFrank <MrFrank!~MrFrank@mx1.fracta.dev> has joined #yocto10:22
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has joined #yocto10:24
*** camus <camus!~Instantbi@> has quit IRC (Ping timeout: 246 seconds)10:26
*** camus <camus!~Instantbi@> has joined #yocto10:28
mcfriskHow are poky oe-selftests executed on autobuilder(s)? I'd like to know what's in their conf/local.conf, auto.conf and site.conf10:42
mcfriskkanavin: what does test_testimage_virgl_headless need from the build host? some GPU HW or just vgem kernel module?10:44
mcfriskon my x86_64 build machine with "Integrated Matrox G200eW3 Graphics Controller", starting qemu with GPU support is always failing and thus test_testimage_virgl_headless too. loading vgem kernel module doesn't help. What do the upstream build/test servers have?10:55
*** Estrella <Estrella!~quassel@075-081-060-240.res.spectrum.com> has quit IRC (Ping timeout: 256 seconds)11:02
RPptsneves: yes, well spotted!11:07
RPptsneves: I'd be happy to fix that issue11:08
RPmcfrisk: you can see it in the logs?11:08
RPmcfrisk: https://autobuilder.yoctoproject.org/typhoon/#/builders/127/builds/1948/steps/14/logs/stdio11:08
RPfrom https://autobuilder.yoctoproject.org/typhoon/#/builders/127/builds/1948 step 14, "OE Selftest: Write config"11:09
RPthat one is an arm worker but you get the idea11:09
RPmcfrisk: I think that test is excluded on some distros and has some host requirements11:09
kanavinmcfrisk, loading vgem should help, that's what yocto ci does11:12
kanavinspcifically vgem should create /dev/dri/renderD* entries, if the gpu driver does not11:12
mcfriskkanavin: I loaded the vgem module but starting qemu still fails with "qemu-system-x86_64: egl: render node init failed"11:13
kanavinare permissions correct?11:13
mcfriskI saw that /dev/dri/renderD128 is created, ah I don't render group rights, will add and try again. thanks!11:14
kanavinmcfrisk, qemu error message isn't helpful, I think I tried to make runqemu print something more useful in that case, not sure11:15
RPmcfrisk: making some nicer errors messages around that would be nice if we could11:15
ad__hi, any simple way to change glibc version ?11:15
kanavinad__, update to the yocto version that has the needed version11:15
mcfriskyea, I'm trying to improve the error messages and host dependency detection11:16
ad__kanavin:  agh, would like to test 2.28 in place of 2.33 hadrdknott11:16
kanavinad__, everything else is tested with 2.33, so you're likely to run into difficulties and unpredictable amount of time trying to resolve them11:16
kanavinwhy 2.28?11:17
RPad__: you can copy in recipes and try it but no guarantees as we never tested that11:17
ad__well, i am trying to compare to an older buldroot stuff that was more performant, using 2.2811:19
ad__not sure glibc is the culprit, just investigating11:20
kanavinad__, it's perhaps easier to take a version of yocto that has 2.2811:20
ad__kanavin: ok thanks, so not so simple11:20
kanavinswitching major pieces like glibc, or gcc while leaving everything else as it was is asking for cryptic failures11:21
ptsnevesRP: I fixed the issue like this(https://pastebin.com/tP10qcVJ) but I would like to create a reproducer for a test. I do not see anything similar. I think these check sum lists are coming from the data cache but I do not see where in the cache code the file list is retrieved. Ideally I would like to create 2 sets of bitbake recipe metadata whose cache objects only differ in the order of the files to checksum. Then from make an expect that they have the same11:21
ptsnevestask hash11:21
*** valdemaras <valdemaras!~valdemara@> has quit IRC (Quit: valdemaras)11:22
RPptsneves: sadly these issues are tricky, the ordering comes from python's dict ordering being random11:25
RPptsneves: the data is put into a dict and effectively randomised there11:25
RPad__: try swapping in some other recipes, see what happens would be my advice. I don't know how bad the issues would be11:26
ptsnevesRP: can you point me in the code where this is happening, so I at least learn something?11:26
RPptsneves: https://git.yoctoproject.org/poky/tree/bitbake/lib/bb/siggen.py#n200 is where it is defined as a dict. https://git.yoctoproject.org/poky/tree/bitbake/lib/bb/siggen.py#n338 is where it is assigned into that dict. At that point it is going to be unordered11:28
RPptsneves: or do you mean where dataCaches[mc].file_checksums[mcfn] comes from ?11:29
RPptsneves: are those full path filenames? If so that sorting won't be deterministic11:30
*** valdemaras <valdemaras!~valdemara@> has joined #yocto11:30
ptsnevesWhere dataCaches[mc].file_checksums[mcfn] comes from. I see it comes from the cooker but what populates it?11:30
ptsnevesRP: In my case no. The signature files are relative paths and after my patch they are correctly ordered11:31
RPptsneves: add_cacheData in cache.py11:31
ptsnevesRP: Thanks!11:31
mcfriskkanavin: loaded vgem module and added user to "render" group and now test_testimage_virgl_headless passes, thanks11:33
RPptsneves: I don't think you can't assume those paths are relative11:34
RPptsneves: see the comment in checksum.py:get_checksums about "/./" being injected into the path. You need to sort on the piece after that marker if present11:35
RPptsneves: or perhaps just sort on the checksums11:36
ptsnevesRP: Ah! clever! Indeed we do not really need any sorting of the paths. We just need the sort for the reproducibility11:36
RPptsneves: right11:37
ptsnevesOhhh that would be not enough after all. The list will be ambiguous if sorted by checksum if there are more than one file with the same checksum.11:40
ptsnevesThe list's order i mean11:40
ptsnevesI actually have such signature on hand11:41
RPptsneves: right, then you'll have to use the paths :/11:41
*** xmn <xmn!~xmn@pool-71-105-152-109.nycmny.fios.verizon.net> has joined #yocto11:43
*** olani_ <olani_!~olani@> has quit IRC (Remote host closed the connection)11:47
ptsnevesRP: Regarding the "/./" being injected. I do not think it matters for task hash purposes. As we talked, the ordering is just a means to have a unique representation for a list of (file,checksum) tuples. Which order irrelevant as long as it is unique.11:49
RPptsneves: someone might lay out the files differently between layers or something though11:50
RPptsneves: i.e. there are slightly unusual things someone might do that could affect this :(11:50
RPI really don't want to introduce such a different bug11:50
RPptsneves: imagine a recipe in a layer that references a file in oe-core and two people lay the layers out differently in different paths11:51
*** olani_ <olani_!~olani@> has joined #yocto11:52
ptsnevesRP: Such case would not affect the hash. If we sort only in the calc_taskhash function like in my proposal https://pastebin.com/tP10qcVJ i think we will not touch anything else. Do you agree?11:53
RPptsneves: no, I don't agree11:53
ptsnevesNevermind the "/./" is inside the sorted loop. I dont really have a good idea on how to fix this then. I will try to understand better what the /./ does11:56
RPptsneves: what you probably need to do is write a specific sort function which splits the string on "/./" and returns the second bit as the sort key11:57
RPptsneves: it is there to stop us including user local build paths in the task checksums11:58
RPotherwise everyone would have to build in the same path for sstate to match11:59
ptsnevesok. Will have a go at it after lunch. Otherwise I will just open a bug so people are aware of the issue.11:59
RPptsneves: you're close, we just need to make sure we cover the corner cases11:59
ptsnevesOk. By the way is this line https://git.yoctoproject.org/poky/tree/bitbake/lib/bb/siggen.py#n1100 incorrect as well?12:00
RPptsneves: that is probably ok as it is a list, written here: https://git.yoctoproject.org/poky/tree/bitbake/lib/bb/siggen.py#n42912:02
RPso we probably need to fix that bit12:02
RPonce it is a list, the order is determinstic12:02
*** pgowda_ <pgowda_!uid516182@2a03:5180:f:3::7:e056> has quit IRC (Quit: Connection closed for inactivity)12:41
*** Xagen <Xagen!~Xagen@99-135-179-142.lightspeed.austtx.sbcglobal.net> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…)12:49
*** rob_w <rob_w!~bob@host-82-135-31-73.customer.m-online.net> has quit IRC (Remote host closed the connection)13:00
*** kscherer <kscherer!~kscherer@bras-base-otwaon1146w-grc-26-174-95-44-81.dsl.bell.ca> has joined #yocto13:29
*** Xagen <Xagen!~Xagen@rrcs-98-6-114-13.sw.biz.rr.com> has joined #yocto13:48
*** Estrella <Estrella!~quassel@075-081-060-240.res.spectrum.com> has joined #yocto13:56
*** dmoseley_ <dmoseley_!~dmoseley@d4-50-9-187.evv.wideopenwest.com> has joined #yocto14:05
*** dmoseley <dmoseley!~dmoseley@d4-50-9-187.evv.wideopenwest.com> has quit IRC (Ping timeout: 256 seconds)14:09
*** Wouter0100670440 <Wouter0100670440!~Wouter010@entry.nbg.netvos.nl> has quit IRC (Quit: The Lounge - https://thelounge.chat)14:16
*** Wouter0100670440 <Wouter0100670440!~Wouter010@entry.nbg.netvos.nl> has joined #yocto14:17
*** Xagen <Xagen!~Xagen@rrcs-98-6-114-13.sw.biz.rr.com> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…)14:23
*** Xagen <Xagen!~Xagen@rrcs-98-6-114-13.sw.biz.rr.com> has joined #yocto14:24
*** otavio <otavio!~otavio@189-11-189-69.user3p.brasiltelecom.net.br> has joined #yocto14:25
*** dmoseley_ <dmoseley_!~dmoseley@d4-50-9-187.evv.wideopenwest.com> has quit IRC (Quit: ZNC 1.8.2 - https://znc.in)14:38
ptsnevesRP: https://pastebin.com/HU5gxLcy does this key method work to handle the "/./" case?14:39
*** dmoseley <dmoseley!~dmoseley@d4-50-9-187.evv.wideopenwest.com> has joined #yocto14:40
*** belsirk <belsirk!~rfuentess@> has joined #yocto14:40
*** rfuentess <rfuentess!~rfuentess@lfbn-lyo-1-1294-101.w86-207.abo.wanadoo.fr> has quit IRC (Ping timeout: 245 seconds)14:42
*** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV)14:42
*** valdemaras <valdemaras!~valdemara@> has quit IRC (Quit: valdemaras)14:44
*** valdemaras <valdemaras!~valdemara@> has joined #yocto14:45
*** dgriego <dgriego!~dgriego@user/dgriego> has quit IRC (Ping timeout: 246 seconds)14:50
RPptsneves: yes, that looks like what we need14:50
ptsnevesok will submit to the to the mailing list after kids go to sleep :) I do not have the current computer configured for the mailing list14:52
*** dgriego <dgriego!~dgriego@user/dgriego> has joined #yocto14:53
*** belsirk is now known as rfuentess15:07
*** Schlumpf48 <Schlumpf48!~Schlumpf@> has quit IRC (Quit: Client closed)15:07
tlwoerneraha, there *are* 2 JPEWs!15:12
JPEWtlwoerner: When did that happen.... *looks around suspiciously*15:15
*** amitk <amitk!~amit@> has joined #yocto15:21
*** AKN <AKN!~AKN@> has quit IRC (Read error: Connection reset by peer)15:31
*** rfuentess <rfuentess!~rfuentess@> has quit IRC (Remote host closed the connection)15:34
*** leon-anavi <leon-anavi!~Leon@> has quit IRC (Quit: Leaving)15:38
*** valdemaras <valdemaras!~valdemara@> has quit IRC (Quit: valdemaras)15:40
*** goliath <goliath!~goliath@user/goliath> has joined #yocto15:42
yates_worki have a humble question on the yocto reference manual.15:42
*** vladest <vladest!~Thunderbi@> has quit IRC (Ping timeout: 248 seconds)15:43
yates_workin that manual i see major headings like "Classes," "Tasks," "Images," etc., but I do not see a corresponding "Recipes." Where are are the various aspects of recipes defined? for example how recipe files are to be named, the required syntactic components (e.g., LICENSE), etc?15:44
JPEWyates_work: Well.... we are actually working on getting that into the manual15:45
yates_workJPEW: Ah! Ok, cool, thanks.15:45
yates_worki am creating a new custom recipe for an app and the question i'm having is this: should i append the version number after the recipe base file name or not? e.g., if my application is called "myapp", is it ok to just name it "myapp.bb" or should i name it "myapp_1.0.bb"?15:51
rburtonif you don't put it in the filename then you get the default of 1.0 unless you set PV manually15:55
rburtonlooking at oe-core will show you that most recipes put the version in the filename unless they're something that doesn't really have a version15:57
rburtonlike, images don't have intrinsic versions15:57
yates_workrburton: i see. thanks for answering such a basic question!15:59
*** Dr_Who <Dr_Who!~tgall@> has joined #yocto16:04
*** ptsneves <ptsneves!~Thunderbi@> has quit IRC (Ping timeout: 244 seconds)16:10
zwelchMy do_patch task for my kernel recipe wants to run after do_kernel_metadata, but one of the patches adds the defconfig defined in KBUILD_DEFCONFIG.  How can I break this cycle?  (FWIW, adding `addtask do_patch before do_kernel_metadata` results in a circular dependency.)16:15
zwelchI suspect one solution is "move the defconfig from the patch to the layer", but the patch is being automatically extracted from a vendor's BSP package and I'd rather avoid complicating that process.16:17
Sauryates_work: Also know that you can only use versioned bbappends if the recipe actually has a version in the recipe name. I.e., for a foobar_1.%.bbappend to work, the foobar recipe has to be called something like foobar_1.2.3.bb. It does not work to have versioned bbappends for recipes that set PV in the recipe.16:20
dvergatalRP: I'm sorry I couldn't get on the meeting I was busy ATM16:32
*** mckoan is now known as mckoan|away16:35
*** florian_kc <florian_kc!~florian@> has quit IRC (Ping timeout: 248 seconds)16:37
*** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has quit IRC (Quit: Ex-Chat)16:37
*** ptsneves <ptsneves!~Thunderbi@031011128011.dynamic-3-poz-k-0-2-0.vectranet.pl> has joined #yocto16:41
*** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has quit IRC (Quit: Client closed)16:56
*** vladest <vladest!~Thunderbi@mob-194-230-160-62.cgn.sunrise.net> has joined #yocto16:57
khemRP: kanavin the example is convertion between two integer types and compiler does an implicit conversion if no explicit cast is specified. Now if implicit conversion is happening and target type is smaller like in this case then there is risk of overflow and behaviour is upto compiler to define with gcc and clang the behaviour is to discard upper 32bits. thats why there is no warning by default but you can use -Wconversion to enable16:58
khemcompiler to warn about implicit conversions of this kind16:58
RPdvergatal: no problem16:59
*** vladest <vladest!~Thunderbi@mob-194-230-160-62.cgn.sunrise.net> has quit IRC (Ping timeout: 246 seconds)17:14
*** tgamblin <tgamblin!~tgamblin@2001:1970:5b1f:ab00:71eb:b8e9:8589:9ca5> has quit IRC (Quit: Leaving)17:14
*** tgamblin <tgamblin!~tgamblin@2001:1970:5b1f:ab00:71eb:b8e9:8589:9ca5> has joined #yocto17:14
yates_workSaur: good point, thanks.17:19
kanavinkhem, yes, the point is something else: this behaviour leads to subtle bugs, and compiler could do a better job of warning about it17:37
*** lexano <lexano!~lexano@> has joined #yocto17:37
kanavinkhem, i.e. see dbus's implementation of getting time here. There's no help from gcc indicating that this will discard data when long is 32 bit: https://gitlab.freedesktop.org/dbus/dbus/-/blob/master/dbus/dbus-sysdeps-unix.c#L340817:40
kanavinI have a patch, but I'd rather not have to spend time chasing such issues https://git.yoctoproject.org/poky-contrib/tree/meta/recipes-core/dbus/dbus/0001-time-use-time_t-for-seconds-instead-of-long.patch?h=akanavin/y2038&id=7f47c217:42
kanavinnot your fault obviously :)17:43
*** prabhakarlad <prabhakarlad!~prabhakar@> has joined #yocto17:45
khemcompiler takes a general approach as long as code generation is correct. It does offers knobs if programmer wants to be strict or not, integer promotion and conversions are language features. Its good to know them especially in C which is not strictly typed language17:48
khemone can certainly argue to make -Wconversion to be part of -Wextra upstream17:49
*** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV)17:52
kanavinkhem, I wonder if you will take a harder stance on this when your power supply goes out in Jan 19 2038 :)17:54
kanavinthe more I look at C, the more I'm in favour of bondage and discipline languages17:55
kanavinsuch as rust17:55
*** belgianguy <belgianguy!~belgiangu@ptr-651fbf6qt3idf6rrcwk.18120a2.ip6.access.telenet.be> has joined #yocto17:58
*** valdemaras <valdemaras!~valdemara@> has joined #yocto18:01
belgianguykhem, thanks, yeah I've been reading a lot about Debian, they seem to have only recently fixed a bug with Secure Boot and ARM64, but then whilst digging I read about GPLv3 not being compatible with Secure Boot, which is a hornets nest of its own, ... So far I've only seen deby from meta-debian as a Debian-like distro, but I don't know how similar it is to "real" Debian18:03
*** frieder <frieder!~frieder@> has quit IRC (Remote host closed the connection)18:04
*** flom84 <flom84!~flom84@user/flom84> has joined #yocto18:11
*** flom84 <flom84!~flom84@user/flom84> has quit IRC (Remote host closed the connection)18:11
*** starblue <starblue!~juergen@dslb-088-078-109-047.088.078.pools.vodafone-ip.de> has quit IRC (Quit: WeeChat 3.8)18:13
*** flom84 <flom84!~flom84@user/flom84> has joined #yocto18:17
*** starblue <starblue!~juergen@dslb-088-078-109-047.088.078.pools.vodafone-ip.de> has joined #yocto18:19
khemkanavin: I think if I were to start with a clean state - C/C++ will not be at top of consideration for sure18:21
kanavinkhem, I've been fixing stuff like this for the past three weeks or so, so my patience with C is a bit thin :) https://git.yoctoproject.org/poky-contrib/log/?h=akanavin/y203818:22
khemY2038 issue is independent of language though18:23
*** valdemaras <valdemaras!~valdemara@> has quit IRC (Read error: Connection reset by peer)18:23
khemI understand18:23
kanavinI beg to differ. It's very much C-specific.18:23
khemsystem C library ( particularly glibc in this case ) agreed. But its a implementation issue rather than language18:27
khembelgianguy: yeah, although I would suggest to not mix debian and yocto/OE unless you know what you are getting into, it has a potential of painting yourself into wall18:29
kanavinkhem, it's also a language issue. C is both ambiguous about how many bits are in long, and won't warn you when 64 bit time_t is assigned to 32 bit long.18:30
belgianguykhem, hmm, the layered approach really interested me about Yocto/OE and that there was some industrial inflow, from "pure" Debian I've only seen a buster version that supposedly works with a custom 4.14 kernel18:30
khemright, you can get inspiration from that on how secure boot is implemented and get it done on yocto18:31
belgianguykhem, I've seen some Bootlin Youtube videos regarding Secure Boot and it seems a very complex topic, signing every step, and it's not well documented for embedded systems (and depend a lot on vendor, too)18:33
khembelgianguy: yes it is you need all the signing infra vetted18:35
khemkanavin: time_t is not defined by C or C++ std so technically c/c++ compiler can not do much about it. its another define/typedef impl18:36
*** amitk <amitk!~amit@> has quit IRC (Remote host closed the connection)18:44
*** ptsneves <ptsneves!~Thunderbi@031011128011.dynamic-3-poz-k-0-2-0.vectranet.pl> has quit IRC (Quit: ptsneves)19:08
*** ptsneves <ptsneves!~Thunderbi@031011128011.dynamic-3-poz-k-0-2-0.vectranet.pl> has joined #yocto19:09
kanavinkhem, C could mandate strict checks in type conversions, and deprecate long... in theory :)19:30
kanavindeclaring that c programmers should know what they're doing is insane, because practice shows they do not19:31
kanavinshort/long/long long while we're at it19:33
kanavinall this ambiguous crap19:33
kanavinint too!19:33
*** ptsneves <ptsneves!~Thunderbi@031011128011.dynamic-3-poz-k-0-2-0.vectranet.pl> has quit IRC (Ping timeout: 260 seconds)19:34
*** florian_kc <florian_kc!~florian@dynamic-093-133-038-113.93.133.pool.telefonica.de> has joined #yocto19:36
* kanavin finally gets all 32 bit ptests to pass y2038 grrrr19:37
* kanavin should write 'Why C is not my favorite programming language' one of these days19:38
tgamblinkanavin: I'd read it19:48
kanavinthe title is homage to https://www.cs.virginia.edu/~evans/cs655/readings/bwk-on-pascal.html19:49
kanavin(much of what he said in 1981 doesn't apply to modern pascal)19:49
*** dgriego <dgriego!~dgriego@user/dgriego> has quit IRC (Ping timeout: 244 seconds)19:53
*** ptsneves <ptsneves!~Thunderbi@031011128011.dynamic-3-poz-k-0-2-0.vectranet.pl> has joined #yocto19:55
*** dgriego <dgriego!~dgriego@user/dgriego> has joined #yocto19:57
*** dgriego <dgriego!~dgriego@user/dgriego> has quit IRC (Ping timeout: 246 seconds)20:02
*** davidinux <davidinux!~davidinux@> has quit IRC (Ping timeout: 248 seconds)20:03
*** davidinux <davidinux!~davidinux@> has joined #yocto20:06
*** dgriego <dgriego!~dgriego@user/dgriego> has joined #yocto20:07
*** vladest <vladest!~Thunderbi@> has joined #yocto20:13
*** Haxxa <Haxxa!~Haxxa@202-65-68-206.ip4.superloop.au> has quit IRC (Quit: Haxxa flies away.)20:15
dario`hi, i built nativesdk-rust from master, and i think the target definition json files are missing; i think something like https://pbot.rmdir.de/-rwZHClgYadlGTBsVcBk5g might help (that's from some mickledore+X branch, but rust_1.69.bb looks mostly like rust_1.70.bb in master there)20:20
*** Haxxa <Haxxa!~Haxxa@202-65-68-206.ip4.superloop.au> has joined #yocto20:20
dario`is anyone around who can confirm whether that's at all possible or whether i'm just looking at it the wrong way or something?20:20
kanavindario`, you should probably find out how target json gets made and installed in rust-native, and why it isn't happening in nativesdk-rust20:25
kanavinrust toolchain is intricate, and it's unlikely anyone remembers all the details unless they happen to be working on it this very moment20:25
RPdario`: a test case showing how things fails and what this fixes would also help FWIW. I would send the patch, I can imagine how there could be an issue like this20:27
RPdario`: although thinking about it, the target definition would vary per target so it wouldn't be right coming from a nativesdk recipe20:27
RPthe nativesdk recipe isn't meant to be target specific20:27
dario`hm, but isn't nativesdk-gcc also specific for whatever target you're building for?20:29
RPdario`: gcc-cross-canadian is the target gcc in an sdk and is architecture specific20:30
dario`but yes, how i noticed was rustc from the sdk complaining that it couldn't find target spec for x86_64-poky-linux, and even `rustc --print target-list` did that, and providing some target spec fixed that issue, maybe that's not the right point though, not sure20:31
RPdario`: I don't doubt it might be missing, I'm just saying that providing it through nativesdk-rust isn't right20:31
RPdario`: we do have sdk tests for rust so this does work with master (see meta/lib/oeqa/sdk/cases/rust.py)20:32
dario`hm, and rust-cross-canadian does install them, maybe i just don't want nativesdk-rust for my use-case then..20:33
dario`what's nativesdk-rust used for anyway then, if building packages reasonably requires rust-cross-canadian?20:35
dario`(just answer rtfm if that's appropriate)20:35
*** flom84 <flom84!~flom84@user/flom84> has quit IRC (Ping timeout: 256 seconds)20:36
*** ptsneves <ptsneves!~Thunderbi@031011128011.dynamic-3-poz-k-0-2-0.vectranet.pl> has quit IRC (Ping timeout: 252 seconds)20:37
kanavindario`, I suspect it is not used for anything in particular20:40
kanavinnativesdk-cargo depends on it, but I'm not sure if that's a leftover from old time20:40
RPdario`: that QA test points at rust-cross-canadian having the json files. Those depend on nativesdk-rust as the compiler which is target independent20:41
dario`is there a one-sentence summary of "nativesdk" like in https://www.mail-archive.com/yocto@yoctoproject.org/msg22483.html?20:42
RPdario`: I think what you want is SDK_TOOLCHAIN_LANGS += "rust"20:42
dario`ah, i'll take a look at that, thanks :)20:43
RPdario`: "nativesdk" build once per sdk, run on sdk, output code for sdk20:43
RPit happens rust can output for target with the json addition20:43
RPkanavin: it is the main compiler, definitely needed. It works a bit differently to gcc20:44
smurrayRP: I have a couple of recent mickledore change backports and a fix for riscv for my kirkstone Rust mixin layer, do I just push those in?20:45
RPsmurray: I think so, you're the maintainer! :)20:45
smurrayRP: heh20:45
kanavinsmurray, you can post to yocto@ list too20:46
kanavinfor mixin layers it's ok to post/push simultaneously20:46
RPsmurray: usually for my own changes I have to post them and get feedback before I merge20:46
smurraykanavin: yeah, I'll post them there as well20:46
smurrayRP: right20:46
RPhow long "before" is varies depending on how risky the change is and how much breakage it might fix20:46
smurrayI actually have a new issue I need to figure out, there's a crate dependency of the major Rust thing we build for AGL atm that doesn't build for risc-v due to it (ring crate) being a wrapper around a bunch of crypto asm20:48
dario`building SDK with SDK_TOOLCHAIN_LANGS += "rust" now, thanks so much RP and kanavin :-)20:49
*** Wouter0100670440 <Wouter0100670440!~Wouter010@entry.nbg.netvos.nl> has quit IRC (Quit: The Lounge - https://thelounge.chat)21:01
*** Wouter0100670440 <Wouter0100670440!~Wouter010@entry.nbg.netvos.nl> has joined #yocto21:02
yates_workif i build something with a MACHINE ?= "genericx86-64" under a standard ubuntu desktop distribution, which that actually get installed to the system? (e.g., /usr/local/bin)?21:05
yates_workslightly different question: if i build something with a MACHINE ?= "genericx86-64" under a standard ubuntu desktop distribution, can i run it natively on that system?21:06
*** amitk_ <amitk_!~amit@> has quit IRC (Ping timeout: 256 seconds)21:08
yates_works/which that/will that/21:08
*** amitk <amitk!~amit@> has joined #yocto21:09
kanavinyates_work, in general, no. If you want to run things on ubuntu, build them using ubuntu tooling.21:11
kanavinyates_work, however, building something in it's -native variant will work21:13
kanavinbut that's independent of what MACHINE is set to21:13
*** dgriego_ <dgriego_!~dgriego@user/dgriego> has joined #yocto21:30
*** florian_kc <florian_kc!~florian@dynamic-093-133-038-113.93.133.pool.telefonica.de> has quit IRC (Ping timeout: 244 seconds)21:31
*** dgriego <dgriego!~dgriego@user/dgriego> has quit IRC (Ping timeout: 248 seconds)21:32
*** Xagen <Xagen!~Xagen@rrcs-98-6-114-13.sw.biz.rr.com> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…)21:57
khemkanavin: there is lot of legacy code in C that has to be carried forward. Clang is doing some aggressive steps in this area e.g. trying to default to newer C std and this leads to fundamental breakages like autoconf probing tests failing to compile and worse in some cases the test logic depended on these old c89 behaviors21:57
*** mpb27 <mpb27!~mpb27@2604:3d08:1c7f:cc50:ac33:eab1:2021:ab99> has joined #yocto22:23
*** mpb28 <mpb28!~mpb28@2604:3d08:1c7f:cc50:ac33:eab1:2021:ab99> has joined #yocto22:23
*** dmoseley_ <dmoseley_!~dmoseley@> has joined #yocto22:24
*** dmoseley <dmoseley!~dmoseley@d4-50-9-187.evv.wideopenwest.com> has quit IRC (Ping timeout: 252 seconds)22:25

Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!