| *** ecdhe_ <ecdhe_!~ecdhe@mms-rf-support.com> has joined #yocto | 00:18 | |
| *** ecdhe <ecdhe!~ecdhe@mms-rf-support.com> has quit IRC (Ping timeout: 256 seconds) | 00:21 | |
| *** zeddii <zeddii!~zeddii@cpe04d4c4975b80-cmf4c11490699b.cpe.net.cable.rogers.com> has quit IRC (Ping timeout: 268 seconds) | 00:29 | |
| *** shoragan[m] <shoragan[m]!~shoraganm@2001:470:69fc:105::39> has joined #yocto | 00:29 | |
| *** kayterina[m] <kayterina[m]!~kayterina@2001:470:69fc:105::960> has joined #yocto | 00:31 | |
| *** zeddii <zeddii!~zeddii@cpe04d4c4975b80-cmf4c11490699b.cpe.net.cable.rogers.com> has joined #yocto | 00:32 | |
| *** cody <cody!~cody@user/cody> has joined #yocto | 00:41 | |
| *** zeddii <zeddii!~zeddii@cpe04d4c4975b80-cmf4c11490699b.cpe.net.cable.rogers.com> has quit IRC (Ping timeout: 268 seconds) | 00:50 | |
| *** SamuelDolt[m] <SamuelDolt[m]!~samdoltma@2001:470:69fc:105::4898> has joined #yocto | 01:05 | |
| *** jwillikers <jwillikers!~jwilliker@ics141-1.icsincorporated.com> has joined #yocto | 01:11 | |
| *** jwillikers <jwillikers!~jwilliker@ics141-1.icsincorporated.com> has quit IRC (Remote host closed the connection) | 01:11 | |
| *** hmw[m] <hmw[m]!~hmwmatrix@2001:470:69fc:105::3c7c> has joined #yocto | 01:13 | |
| *** shoragan|m <shoragan|m!~shoragans@2001:470:69fc:105::c9f> has joined #yocto | 01:21 | |
| *** rostam98[m] <rostam98[m]!~rostam98m@2001:470:69fc:105::ca0e> has joined #yocto | 01:21 | |
| *** Spectrejan[m] <Spectrejan[m]!~spectreja@2001:470:69fc:105::1609> has joined #yocto | 01:23 | |
| *** berton[m] <berton[m]!~fabiobert@2001:470:69fc:105::ce36> has joined #yocto | 01:28 | |
| *** Emantor[m] <Emantor[m]!~emantorm]@2001:470:69fc:105::8eb> has joined #yocto | 01:33 | |
| *** moto_timo[m] <moto_timo[m]!~mototimom@2001:470:69fc:105::c94> has joined #yocto | 01:34 | |
| *** jonesv[m] <jonesv[m]!~jonesvmat@2001:470:69fc:105::4616> has joined #yocto | 01:34 | |
| *** meck[m] <meck[m]!~meckmeckd@2001:470:69fc:105::3a51> has joined #yocto | 01:37 | |
| *** ejoerns[m] <ejoerns[m]!~ejoernsma@2001:470:69fc:105::252> has joined #yocto | 01:44 | |
| *** PascalBach[m] <PascalBach[m]!~bachpmatr@2001:470:69fc:105::1d3b> has joined #yocto | 01:45 | |
| *** barath <barath!~barath@2001:470:69fc:105::21a> has joined #yocto | 01:46 | |
| *** tokamak[m] <tokamak[m]!~tokamakma@2001:470:69fc:105::c4df> has joined #yocto | 01:48 | |
| *** jwillikers[m] <jwillikers[m]!~jwilliker@2001:470:69fc:105::626a> has joined #yocto | 01:53 | |
| *** t_unix[m] <t_unix[m]!~tunixmatr@2001:470:69fc:105::9ea> has joined #yocto | 01:56 | |
| *** Pierre-jeanTexie <Pierre-jeanTexie!~pjtexierm@2001:470:69fc:105::f2f> has joined #yocto | 02:00 | |
| *** hpsy <hpsy!~hpsy@45.86.203.252> has joined #yocto | 02:02 | |
| *** m1kr0[m] <m1kr0[m]!~m1kr0matr@2001:470:69fc:105::c827> has joined #yocto | 02:06 | |
| *** jordemort <jordemort!~jordemort@2001:470:69fc:105::2d9> has joined #yocto | 02:10 | |
| *** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Ping timeout: 268 seconds) | 02:13 | |
| *** camus <camus!~Instantbi@58.246.136.202> has joined #yocto | 02:13 | |
| *** Alban[m] <Alban[m]!~albeugaen@2001:470:69fc:105::34b4> has joined #yocto | 02:21 | |
| *** dwagenk <dwagenk!~dwagenk@2001:470:69fc:105::103d> has joined #yocto | 02:24 | |
| *** khem <khem!~khemmatri@2001:470:69fc:105::b81> has joined #yocto | 02:31 | |
| *** behanw[m] <behanw[m]!~behanwmat@2001:470:69fc:105::c96> has joined #yocto | 02:37 | |
| *** nicolas[m]12 <nicolas[m]12!~nicolasma@2001:470:69fc:105::b5f4> has joined #yocto | 02:37 | |
| *** amitk <amitk!~amit@103.208.71.30> has joined #yocto | 02:40 | |
| *** lexano[m] <lexano[m]!~lexanomat@2001:470:69fc:105::3110> has joined #yocto | 02:41 | |
| *** tp43_ <tp43_!~ndeem@2001:1970:501a:e201:e021:97c4:bc6c:f59a> has quit IRC (Ping timeout: 272 seconds) | 02:42 | |
| *** ndec[m] <ndec[m]!~ndecmatri@2001:470:69fc:105::9c0> has joined #yocto | 02:45 | |
| *** michaelo[m] <michaelo[m]!~michael-o@2001:470:69fc:105::be7c> has joined #yocto | 02:50 | |
| *** halstead[m] <halstead[m]!~halsteadm@2001:470:69fc:105::d0ef> has joined #yocto | 02:51 | |
| *** Saur[m] <Saur[m]!~saur2000m@2001:470:69fc:105::dce> has joined #yocto | 02:52 | |
| *** falk0n[m] <falk0n[m]!~falk0nmat@2001:470:69fc:105::ce60> has joined #yocto | 02:53 | |
| *** michaelo[m]1 <michaelo[m]1!~michaelom@2001:470:69fc:105::d101> has joined #yocto | 02:54 | |
| *** peterp <peterp!~peterp@2607:f2c0:e154:2bf::776> has joined #yocto | 03:15 | |
| peterp | Hi, I'm trying to compile a custom bootloader provided by our vendor and it requires that it has a dtsi file available from the kernel recipe. How do I go about sharing this file while I'm building the bootloader? I added a DEPENDS on the kernel, but now I'm stuck and can't seem to find the answer in the docs and googling... | 03:19 |
|---|---|---|
| *** camus1 <camus1!~Instantbi@58.246.136.202> has joined #yocto | 03:30 | |
| *** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Ping timeout: 268 seconds) | 03:31 | |
| *** camus1 is now known as camus | 03:31 | |
| *** zeddii <zeddii!~zeddii@cpe04d4c4975b80-cmf4c11490699b.cpe.net.cable.rogers.com> has joined #yocto | 03:37 | |
| *** wing0 <wing0!~wing0@2804:431:c7ed:41c:20ad:47f:325f:7c35> has quit IRC (Quit: WeeChat 3.1) | 04:40 | |
| *** roussinm <roussinm!~mroussin@bras-base-qubcpq1306w-grc-21-184-145-222-193.dsl.bell.ca> has quit IRC (Quit: WeeChat 3.3-dev) | 05:27 | |
| *** paulg <paulg!~boodler@104-195-159-20.cpe.teksavvy.com> has quit IRC (Ping timeout: 248 seconds) | 06:01 | |
| *** rob_w <rob_w!~bob@host-82-135-31-73.customer.m-online.net> has joined #yocto | 06:04 | |
| *** vmeson <vmeson!~rmacleod@198-48-226-187.cpe.pppoe.ca> has quit IRC (Ping timeout: 268 seconds) | 06:04 | |
| *** kranzo <kranzo!~kranzo@a81-14-214-202.net-htp.de> has joined #yocto | 06:35 | |
| *** 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 | |
| *** dtometzki <dtometzki!~dtometzki@fedora/dtometzki> has joined #yocto | 06:49 | |
| *** goliath <goliath!~goliath@user/goliath> has joined #yocto | 06:51 | |
| *** bps <bps!~bps@user/bps> has quit IRC (Read error: Connection reset by peer) | 06:59 | |
| *** bps <bps!~bps@80.71.142.18.ipv4.parknet.dk> has joined #yocto | 06:59 | |
| *** LetoThe2nd <LetoThe2nd!uid453638@id-453638.highgate.irccloud.com> has joined #yocto | 07:06 | |
| LetoThe2nd | yo dudX | 07:06 |
| *** dmoseley <dmoseley!~dmoseley@24.96.56.90> has quit IRC (Read error: Connection reset by peer) | 07:12 | |
| *** dmoseley <dmoseley!~dmoseley@24.96.56.90> has joined #yocto | 07:16 | |
| cocoJoe | good morning | 07:17 |
| qschulz | peterp: One way would be to deploy the dtsi of the kernel and take the dtsi from the deploydir in u-boot and add it in the configure task or similar, and add a dependency on virtual/kernel:do_deploy for said task from u-boot | 07:53 |
| qschulz | but i'm not entirely sure it makes sense, device trees used in U-Boot and the kernel are often different. Similar but different | 07:54 |
| qschulz | the drivers don't always expect the same properties for example | 07:54 |
| qschulz | so the other way could be to just duplicate the dtsi from the kernel and add it to the u-boot recipe directly | 07:54 |
| *** leon-anavi <leon-anavi!~Leon@78.130.197.211> has joined #yocto | 08:34 | |
| *** d0ku <d0ku!~d0ku@178.43.198.70.ipv4.supernova.orange.pl> has joined #yocto | 09:04 | |
| *** leon-anavi <leon-anavi!~Leon@78.130.197.211> has quit IRC (Quit: Leaving) | 09:06 | |
| *** kranzo <kranzo!~kranzo@a81-14-214-202.net-htp.de> has quit IRC (Ping timeout: 246 seconds) | 09:07 | |
| *** peterp <peterp!~peterp@2607:f2c0:e154:2bf::776> has quit IRC (Quit: Client closed) | 09:30 | |
| *** cocoJoe <cocoJoe!~Guest48@xb9b5dc3e.cust.hiper.dk> has quit IRC (Ping timeout: 246 seconds) | 09:31 | |
| *** argonautx <argonautx!~argonautx@i5E8672F4.versanet.de> has joined #yocto | 09:34 | |
| *** wCPO <wCPO!~wCPO@mail.klausen.dk> has joined #yocto | 09:45 | |
| wCPO | Is initramfs-live-boot meant to be used without the "initramfs-framework"? AFAIU the initramfs-framework /init mounts the rootfs and switch_root to it. We are using the live/iso FSTYPE so the rootfs is read-only and initramfs-live-boot can't do its thing as the rootfs is read-only | 09:54 |
| *** mihai <mihai!~mihai@user/mihai> has quit IRC (Remote host closed the connection) | 10:04 | |
| RP | moto-timo: looks like a good fix, thanks | 10:10 |
| qschulz | moto-timo: now I need to keep up with the ML to fix those in the various documentations too :) cc michaelo | 10:11 |
| qschulz | might have missed a few since I was not subscribed to the oe-core ML | 10:11 |
| RP | rburton: we have a buildtools issue now? :/ | 10:11 |
| *** florian <florian!~florian@dynamic-078-049-026-088.78.49.pool.telefonica.de> has joined #yocto | 10:14 | |
| *** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV) | 10:19 | |
| rburton | RP: the glibc one i moaned about, or another one? | 10:32 |
| *** rob_w <rob_w!~bob@host-82-135-31-73.customer.m-online.net> has quit IRC (Quit: Leaving) | 10:39 | |
| *** florian <florian!~florian@dynamic-078-049-026-088.78.49.pool.telefonica.de> has quit IRC (Ping timeout: 248 seconds) | 10:57 | |
| *** jwillikers <jwillikers!~jwilliker@ics141-1.icsincorporated.com> has joined #yocto | 11:10 | |
| *** goliath <goliath!~goliath@user/goliath> has joined #yocto | 11:23 | |
| *** camus1 <camus1!~Instantbi@58.246.136.202> has joined #yocto | 11:27 | |
| *** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Read error: Connection reset by peer) | 11:28 | |
| *** camus1 is now known as camus | 11:28 | |
| RP | rburton: glibc one | 12:34 |
| rburton | chasing it down as we speak | 12:34 |
| rburton | its annoyingly slow to bisect :) | 12:34 |
| wCPO | Is read-only-rootfs unsupported when systemd is used exclusively? The script seems to be part of initscripts which is used only by sysvinit, right? | 12:45 |
| LetoThe2nd | wCPO: nope, it certainly works. | 12:46 |
| wCPO | LetoThe2nd: I will continue debugging then. We are building a iso (which means the rootfs is read-only) and the rootfs is mounted early as / read-only, so initramfs-live-boot isn't working as it can't create new directories for the overlayfs it seems | 12:50 |
| *** tp43_ <tp43_!~ndeem@2001:1970:501a:e201:e021:97c4:bc6c:f59a> has joined #yocto | 13:04 | |
| LetoThe2nd | wCPO: i have no experience with ISOs, sorry. | 13:04 |
| *** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV) | 13:09 | |
| *** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Quit: camus) | 13:16 | |
| JPEW | Are circualar RDEPENDS allowed? I added a task with do_foobar[rdeptask] = "do_foobar" and it fails on some recipes with a circular dep error | 13:20 |
| RP | JPEW: no, they're not | 13:21 |
| JPEW | Ok, so what I did with do_foobar is allowed and I should fix the recipes? | 13:21 |
| JPEW | Kinda makes me want to add a dummy task that does the rdeptask as a check to make sure no one adds more since there doesn't currently appear to be a check | 13:22 |
| RP | JPEW: hmm, I think that is allowed | 13:31 |
| RP | JPEW: I think the code knows to remove self references | 13:31 |
| JPEW | RP: This trivial class errors out: | 13:35 |
| JPEW | https://www.irccloud.com/pastebin/0s0b1ZFS/ | 13:35 |
| RP | JPEW: it is possible since there is meta/recipes-devtools/xmlto/xmlto_0.0.28.bb:do_populate_sysroot[rdeptask] = "do_populate_sysroot" | 13:39 |
| *** argonautx <argonautx!~argonautx@i5E8672F4.versanet.de> has quit IRC (Quit: Leaving) | 13:39 | |
| RP | JPEW: I suspect if you add in general dependencies there are problems :/ | 13:39 |
| RP | JPEW: usually you're looking for recrdeptask and not rdeptask | 13:40 |
| *** ptsneves <ptsneves!~ptsneves@77-92-34-4.cable-modem.tkk.net.pl> has joined #yocto | 13:49 | |
| ptsneves | Hey all. Does anybody know why $(( )) expressions which are POSIX compliant fail in dunfell? Am I missing something? | 13:50 |
| ptsneves | when i mean fail, i mean the parsing fails | 13:50 |
| qschulz | ptsneves: are you appending/prepending to an already existing task? | 13:51 |
| ptsneves | yes | 13:52 |
| ptsneves | i am intrigued with that question. Do you think it makes a difference? | 13:52 |
| qschulz | are you sure you're appending to a shell task? | 13:53 |
| qschulz | we have support for python tasks | 13:53 |
| qschulz | and some are | 13:53 |
| JPEW | RP: I'm trying to capture the RDEPENDS graph for SBoM SPDX generation. What I would like to do is encode the runtime dependencies in the SPDX document, but for that to work, all the SPDX documents for the runtime dependencies need to be fully generated first. It seems like rdeptask is the correct thing to use there? | 13:53 |
| ptsneves | qschulz yes i am. I am putting the $(( in a task which has other shell stuff. The same happens for $(( inside functions executed by bb.build.exec_func | 13:56 |
| ptsneves | funny thing is that there are plenty of expr calls in yocto layers and no $((. At first i thought that $(( was a bashism but it is not. | 13:56 |
| ptsneves | regardless i would not expect the $(( to make the parser fail | 13:57 |
| qschulz | ptsneves: bitbake probably is looking for strings starting with $ and tries to replace it if it has a variable matrching the name | 13:57 |
| JPEW | ptsneves: I *think* bitbake has it's own shell parser that probably doesn't understand $(()) | 13:57 |
| *** tp43_ <tp43_!~ndeem@2001:1970:501a:e201:e021:97c4:bc6c:f59a> has quit IRC (Ping timeout: 245 seconds) | 13:57 | |
| qschulz | there's variable substitution done during parsing I'm absolutely sure of it | 13:58 |
| *** sakoman <sakoman!~steve@172.243.4.16> has joined #yocto | 13:58 | |
| RP | JPEW: Do you mean the package runtime dependencies or the RDEPENDS of the recipe? | 13:58 |
| RP | JPEW: RDEPENDS are usually incomplete until after do_package and the fact some things are only in DEPENDS | 13:59 |
| JPEW | RP: The latter, which I can get. The hard part is I don't want to parse *every* pkgdata file to figure out the mappings, so I was trying to use rdeptask/RDEPENDS/BB_TASKDATA to only parse the ones the recipe actually cares about (this is perhaps the wrong track) | 13:59 |
| RP | JPEW: I think you're nearly on the right track :) | 14:00 |
| JPEW | RP: Also, you need the runtime dependencies to have run their SPDX generation before the current recipe, which I *think* means rdeptask? | 14:01 |
| ptsneves | JPEW qschulz i know that the parser does a bit more than just substitution but it should not fail in places where no substitution happens. I can reproduce the failure with echo $((1 +2 )) | 14:01 |
| RP | JPEW: the do_package_write_* code already has to do this for different reasons so you want to emulate something like that I'd guess | 14:01 |
| RP | JPEW: do_package_write_ipk[rdeptask] = "${DEBIANRDEP}" - I'd have a look at that code, see if the PACKAGES = "" anon python helps | 14:03 |
| JPEW | RP: Thanks | 14:03 |
| *** vd <vd!~vd@bras-base-mtrlpq2848w-grc-41-70-53-240-121.dsl.bell.ca> has quit IRC (Quit: Client closed) | 14:07 | |
| RP | JPEW: in general I'd think you could get away with going after packagedata. The hard part is that you'd therefore want the SPDX doc gen after packagedata for some reasons and before packagedata for others :( | 14:08 |
| JPEW | RP: Ya, that was the conclusion I was coming to | 14:08 |
| JPEW | Rp: Hence my do_create_spdx[rdeptask] = "do_create_spdx", which doesn't work | 14:09 |
| fray | JPEW I'm just catching up, but I worked on planning something that sounds similar.. | 14:09 |
| fray | We had broken the problem into three phases.. First phase, source code download -- along w/ SPDX to Source code mappings.. (either downloaded or generated) | 14:10 |
| fray | We'd the patch the sources and configure them.. and repeat the process.. any files that changed would have to be scanned or loaded.. and new files generated tagged as generated configurations | 14:10 |
| fray | and then a pass AFTER the compilation, where the binaries were interogated to see what the _dwarf_ debug said they all came from, then attached to the source mapping of this (and other) dependencies.. | 14:11 |
| fray | that way we could find and capture staticly linked, as well as functions embedded in headers. | 14:11 |
| JPEW | fray: Ya, you can break it up for thes source scanning, which I'm not dealing with. I'm just worried about creating the SPDX documents. At the end of the day, you need each SPDX document to be created in (runtime) depenency order because each document encodes the SHA1 of the thing it references, which means it must be a DAG | 14:11 |
| fray | the end result was a set of XML files that together game a full picture of original source -> patches/configured source -> binary | 14:11 |
| *** vd <vd!~vd@bras-base-mtrlpq2848w-grc-41-70-53-240-121.dsl.bell.ca> has joined #yocto | 14:13 | |
| fray | (the reason the planned patches/configured was there, most time patches were not somethign that people had scanned.. so it would highlight places that may need manual attention.. adn the configured/generated is stuff that got referenced by the binary..) | 14:13 |
| RP | JPEW: I think we'd need to understand exactly what kind of circular reference that is causing :/ | 14:14 |
| RP | JPEW: this stuff can get tricky. I suspect I'm not in the best of states to think clearly about it either :( | 14:14 |
| fray | I never implemented what I designed, but we didn't see any circular references in it, but it did expand the sysroot information required | 14:14 |
| JPEW | RP: Yep. I can compile a list of the ones I find quick | 14:16 |
| *** vmeson <vmeson!~rmacleod@198-48-226-187.cpe.pppoe.ca> has joined #yocto | 14:20 | |
| JPEW | RP: Hmm, ok. So there are a few circular deps that might be considered bugs (weston <=> weston-conf for example.... oops), but a lot are the ptest packages... going to have to have a thing about it | 14:25 |
| JPEW | s/thing/think/ | 14:26 |
| *** paulg <paulg!~boodler@104-195-159-20.cpe.teksavvy.com> has joined #yocto | 14:26 | |
| fray | I think I didn't run into that stuff when I did my planning, cause we didn't care out package dependencies. We cared about sources, and embedded binary source dependencies. The image would just say anything installed on it, got linked back to the SPDX files.. (including configuration files, etc.) | 14:29 |
| fray | so packages were limited to 'I provide the follow.... When I was compiled, I needed the following..." the image was the only thing that would have done "I use the following..." | 14:30 |
| JPEW | fray: Ya, I'm leveraging the recipe metadata a lot more | 14:30 |
| RP | JPEW: I think the runtime deps can end up circular, just because the inter-package deps are much more granular than the recipe level :/ | 14:31 |
| JPEW | RP: Right | 14:31 |
| wCPO | How would I disable the pcbios machine feature for the genericx86-64 machine? I tried MACHINE_FEATURES_remove = "pcbios" in local.conf but syslinux is still added to the iso | 14:31 |
| fray | not sure I mentioned, but our expectation was also to create a ${PN}-spdx package (like the -lic package) | 14:31 |
| JPEW | fray: You should look at what I have in http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=jpew/sbom | 14:41 |
| JPEW | (If you care) | 14:41 |
| *** cocoJoe <cocoJoe!~cocoJoe@185.5.164.212> has joined #yocto | 14:43 | |
| *** cocoJoe <cocoJoe!~cocoJoe@185.5.164.212> has quit IRC (Client Quit) | 14:44 | |
| *** cocoJoe <cocoJoe!~cocoJoe@185.5.164.212> has joined #yocto | 14:44 | |
| fray | are you doing any debug symbol processing? | 14:44 |
| JPEW | fray: Yes | 14:44 |
| JPEW | fray: Look in add_package_sources_from_debug() | 14:45 |
| fray | how are you generatin the list? | 14:46 |
| JPEW | fray: http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=jpew/sbom&id=14d92b68b4249ed1612a0524ac5365f8c8942e93 | 14:46 |
| JPEW | fray: package.bbclass already had the list, I just made it dump it out somewhere | 14:47 |
| *** tre <tre!~tre@ip5f58aa1a.dynamic.kabel-deutschland.de> has joined #yocto | 14:47 | |
| fray | Is that list complete? I thought it only referred to items from within the existing sources | 14:47 |
| JPEW | fray: Seems complete to me | 14:48 |
| fray | Does it include all of the headers from external items, like glibc? | 14:48 |
| JPEW | fray: tes | 14:48 |
| JPEW | yes | 14:48 |
| *** d0ku <d0ku!~d0ku@178.43.198.70.ipv4.supernova.orange.pl> has quit IRC (Quit: Client closed) | 14:48 | |
| fray | ok, I thought that stuff had been filtered.. Also the other check is, compile something against a static .a (with debug symbols) do the references hold? | 14:49 |
| fray | those were teh three cases we identified. 'normal' shared build. build w/ functions (and other bits) embedded in headers.. and 'hidden' static libraries from external providers being linked in.. (assumed to include debug) | 14:49 |
| JPEW | Not sure about the .a. I think it will as long as the .a has debug info | 14:50 |
| *** tre <tre!~tre@ip5f58aa1a.dynamic.kabel-deutschland.de> has quit IRC (Quit: Leaving) | 14:50 | |
| JPEW | fray: Example output: https://drive.google.com/file/d/1-VjLNIGtesx_0aE9gwF1i_OnL66Se2WK/view?usp=sharing (obviously, still WIP) | 14:50 |
| fray | the issue w/ the .a when I was planning this was.. pkgA provides a static.a (with debug symbols).. pkgB requires pkgA, but doesn't require pkgA's build dependencies. | 14:50 |
| fray | so when linked and debugs processed, the referenced files wouldn't be directly avaialble. We could reference them, but wouldn't know the checksums, unless we processed the pkgA spdx file and read them ourselves | 14:51 |
| fray | (I'm assuming the .a was processed in pkgA, and an SPDX was generated that referenced the orgiinal upstream sources) | 14:51 |
| JPEW | fray: The eaiser path would be to add a STATIC_LINK relationship | 14:53 |
| JPEW | fray: Well, "easier" from a SPDX standpoint. Knowing a static link has occured is hard :) | 14:54 |
| fray | knowing it was a static link is hard, but knowing we have references to things we can't find (when prcessing debug) should make it more obvious it's a depdnency coming from a dependency.. | 14:56 |
| fray | there is no way (that I know of) that a dependency could come in that isn't a dependency of a parent. So at worst case, you could always say "I depend on XYZ, but can't find it" triggering a second program to scan the SPDX of my 1st order dependencies and finding/filling in the pieces.. | 14:56 |
| fray | but the key, we can't directly scan the dependency (rm_work and all), but we can read our dependencies SPDX and transfer data | 14:57 |
| JPEW | Ya, we can mark the files with a GENERATED_FROM NOASSERTION | 15:00 |
| JPEW | Meaning, we know it was generated from somewhere, but we have no idea what that is :) | 15:00 |
| fray | but I like your solution of using the debugsrc output. I had overlooked that and was creatign a dwarf scanner.. | 15:00 |
| fray | (when I ran out of time) | 15:00 |
| fray | ya, should still list the files you don't know about, then another tool can post-process to find hte matches.. | 15:01 |
| fray | (listing the build time dependencies can help with that match) | 15:02 |
| JPEW | Ya, I have all those; I split each generated package into it's own SPDX document, and then there is also a document for the recipe itself, so you can trace back the package -> recipe -> build dependencies (DEPENDS) | 15:06 |
| JPEW | fray: Ok, I have to doing a GENERATED_FROM NOASSERTION any any unknown debug sources now | 15:07 |
| alimon | In bitbake which is the step/flow to load a dynamic-layers files, I have a bug in OE/bitbake master for android-tools recipe that has the same version but one of them is in a dynamic-layer in meta-clang/dynamic-layers/selinux and the other one in meta-oe, so I select to use the meta-oe via preferred_version and ends in | 15:11 |
| alimon | ERROR: Multiple versions of android-tools-conf-configfs are due to be built (/home/builds/oe-rpb-master/build-410c-2/conf/../../layers/meta-openembedded/meta-oe/recipes-devtools/android-tools/android-tools-conf-configfs_1.0.bb | 15:11 |
| alimon | /home/builds/oe-rpb-master/build-410c-2/conf/../../layers/meta-clang/dynamic-layers/selinux/android-tools/android-tools-conf-configfs_1.0.bb). Only one version of a given PN should be built in any given build. You likely need to set PREFERRED_VERSION_android-tools-conf-configfs to select the correct version or don't depend on multiple versions. | 15:11 |
| alimon | also I noticed that dynamic-layers are not load frist I changed the version to 10 where is provided by meta-clang and got a warning about not begin available | 15:11 |
| *** goliath <goliath!~goliath@user/goliath> has joined #yocto | 15:15 | |
| *** camus <camus!~Instantbi@2409:8a1e:9115:d1d0:8d8e:69cf:78f9:c939> has joined #yocto | 15:19 | |
| alimon | RP: rburton any idea ^ | 15:21 |
| alimon | khem: just figure out you are the maintainer of meta-clang, any reason to have android-tools in the dynamic-layers in meta-clang instead of meta-oe?, this unhidden the bug above, that is good | 15:36 |
| *** LetoThe2nd <LetoThe2nd!uid453638@id-453638.highgate.irccloud.com> has quit IRC (Quit: Connection closed for inactivity) | 15:38 | |
| *** cocoJoe <cocoJoe!~cocoJoe@185.5.164.212> has quit IRC (Quit: Quit) | 15:38 | |
| RP | alimon: that usually means the recipes aren't identical and one provides something the other doesn;t | 15:44 |
| RP | alimon: also, layer priorities may override PREFERRED_VERSION :/ | 15:44 |
| alimon | RP: yep, it differs with new and old syntax for appends | 15:45 |
| alimon | RP: i will try to see if works, but still is a bug for me, for example if i select a preffered version of android-tools to 10 that is in meta-clang/dynamic-layers at frist bitbake parse displays warning about not being available | 15:46 |
| alimon | then there is other issue about not being able to select the preferred version because two recipes are in the file_set inside bitbake | 15:46 |
| *** camus <camus!~Instantbi@2409:8a1e:9115:d1d0:8d8e:69cf:78f9:c939> has quit IRC (Ping timeout: 272 seconds) | 16:02 | |
| RP | alimon: the trouble is I doubt you can change behaviour like that without breaking other things, at least if I understand the issue correctly | 16:07 |
| RP | alimon: if the provides are different, it will break regardless of how much you set that stuff | 16:07 |
| alimon | RP: yeah, i think the best solution is move the android-tools new recipe inside meta-oe | 16:09 |
| *** leon-anavi <leon-anavi!~Leon@vin.openfest.org> has joined #yocto | 16:25 | |
| *** bps <bps!~bps@user/bps> has quit IRC (Ping timeout: 248 seconds) | 16:34 | |
| *** ptsneves <ptsneves!~ptsneves@77-92-34-4.cable-modem.tkk.net.pl> has quit IRC (Quit: Connection closed) | 16:39 | |
| *** leon-anavi <leon-anavi!~Leon@vin.openfest.org> has quit IRC (Quit: Leaving) | 16:39 | |
| fray | ya | 16:48 |
| fray | 'er.. wrong channel | 16:48 |
| *** tp43_ <tp43_!~ndeem@2001:1970:501a:e201:e021:97c4:bc6c:f59a> has joined #yocto | 17:00 | |
| *** LetoThe2nd <LetoThe2nd!uid453638@id-453638.highgate.irccloud.com> has joined #yocto | 18:44 | |
| *** dev1990 <dev1990!~dev@dynamic-78-8-55-226.ssp.dialog.net.pl> has joined #yocto | 18:44 | |
| LetoThe2nd | khem: howdy! Can you recommend a riscv board that (mostly) world ootb with meta-riscv? | 18:45 |
| *** fitzsim <fitzsim!~user@69-165-165-189.dsl.teksavvy.com> has quit IRC (Ping timeout: 252 seconds) | 18:48 | |
| *** jwillikers <jwillikers!~jwilliker@ics141-1.icsincorporated.com> has quit IRC (Remote host closed the connection) | 18:49 | |
| *** roussinm <roussinm!~mroussin@bras-base-qubcpq1306w-grc-21-184-145-222-193.dsl.bell.ca> has joined #yocto | 18:52 | |
| *** jwillikers <jwillikers!~jwilliker@ics141-1.icsincorporated.com> has joined #yocto | 19:31 | |
| *** Chep <Chep!~chep@88.168.197.200> has quit IRC (Ping timeout: 245 seconds) | 19:50 | |
| *** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has quit IRC (Quit: Client closed) | 19:52 | |
| *** aleblanc_ <aleblanc_!~aleblanc@192-222-183-114.qc.cable.ebox.net> has quit IRC (Ping timeout: 245 seconds) | 20:07 | |
| *** Vonter <Vonter!~Vonter@user/vonter> has quit IRC (Ping timeout: 248 seconds) | 20:34 | |
| manuel_ | In githubs shitty user interface, how can I get the commit history? An actual list of commits? https://github.com/openembedded/meta-openembedded/graphs/commit-activity is clearly not the answer | 20:34 |
| *** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has joined #yocto | 20:36 | |
| smurray | manuel_: it's definitely not as clear as it could be, you click on the number of commits: https://github.com/openembedded/meta-openembedded/commits/master | 20:36 |
| *** amitk <amitk!~amit@103.208.71.30> has quit IRC (Ping timeout: 248 seconds) | 20:38 | |
| manuel_ | smurray: That's not a link on my system, i.e. it's not clickable | 20:39 |
| smurray | manuel_: sorry, I meant from the main repo page, i.e. "20,546 commits" on https://github.com/openembedded/meta-openembedded | 20:40 |
| manuel_ | smurray: Ah, I see. Got it now. Thanks :) | 20:41 |
| *** mrdmitry <mrdmitry!~dmitry@24.127.93.253> has quit IRC (Quit: WeeChat 2.8) | 20:57 | |
| manuel_ | What exactly means distro-less? | 20:57 |
| abelloni | with DISTRO not defined | 21:04 |
| manuel_ | yeah but what does that give me? Or rather, what does it not give me? Why do I define a distro in the first place? Seems to work without just as well | 21:04 |
| marex | abelloni: DISTRO="nodistro" , no ? | 21:05 |
| fray | "nodistro" is just a set of defaults.. | 21:06 |
| marex | manuel_: the stuff defined in yourdistro.conf is not defined ... is what it gets you | 21:06 |
| JPEW | manuel_: it can be useful if you want a lot of different things to behave with a similar (centralized) policy | 21:06 |
| JPEW | e.g. different machines | 21:06 |
| marex | JPEW: that ... is not entirely clear ? | 21:07 |
| marex | JPEW: I mean, that does not really explain what nodistro is about | 21:08 |
| marex | JPEW: if you want centralized policy, dont you define your own distro in distro layer ? | 21:08 |
| JPEW | marex: Ya, nodistro means "I'm not going to do that" (I think, I don't use nodistro TBH) | 21:09 |
| * tlwoerner uses nothing but nodistro | 21:09 | |
| * marex uses many custom distros | 21:09 | |
| tlwoerner | what's all this PUH-KEY stuffy about? | 21:09 |
| manuel_ | Gonna look into this nodistro thing another time. | 21:10 |
| manuel_ | Am currently facing another problem | 21:10 |
| manuel_ | I updated my layers to the newest dunfell ones. My yocto project is building for Raspberrypi 4. After updating the layers, the build breaks with a syntax error here: https://github.com/openembedded/meta-openembedded/blob/master/meta-oe/conf/layer.conf#L104 | 21:11 |
| marex | tlwoerner: there is actually one other thing which I was pondering about /wrt poky -- whether it is a good idea to include poky.conf in customdistro.conf to get the "sane defaults" like some distros do, or whether it is better to copy the whole poky.conf over and filter out what is useless | 21:11 |
| manuel_ | DEFAULT_TEST_SUITES:pn-meta-oe-ptest-image = " ${PTESTTESTSUITE}" | 21:11 |
| marex | I cant decide which way is better to go about it | 21:11 |
| manuel_ | NON_MULTILIB_RECIPES:append = " crash" <---- the colon here looks strange | 21:12 |
| manuel_ | marex: I think this whole poky thing is more confusing than in helps. At least to me, as a beginner. | 21:12 |
| marex | manuel_: it is a reference distro for starters ... | 21:13 |
| marex | better than having nodistro as a starting point , heh | 21:13 |
| tlwoerner | poky is the sample distro that's used for testing | 21:13 |
| abelloni | marex: if you include poky.conf and suddenly this switches from X11 to wayland or sysv to systemd, you can have some surprises | 21:17 |
| tlwoerner | s/if/when | 21:17 |
| marex | abelloni: well ... yes ... that's solved if you duplicate large part of poky.conf into your own customdistro.conf | 21:18 |
| marex | abelloni: on the other hand, some of the defaults defined in poky.conf might be updated (like equivhash) and that would be beneficial to your customdistro.conf | 21:19 |
| tp43_ | I am getting access denied or repo not exported for various branches of /meta-respberrypi | 21:20 |
| marex | tp43_: where ? | 21:20 |
| marex | locally ? permissions issue ? | 21:20 |
| tp43_ | Nevermind, my fault. I had a type. the i at the end with missing. | 21:22 |
| tp43_ | marex thx for reply | 21:22 |
| *** florian <florian!~florian@p54b4f74d.dip0.t-ipconnect.de> has joined #yocto | 21:25 | |
| *** sakoman <sakoman!~steve@172.243.4.16> has quit IRC (Read error: Connection reset by peer) | 21:33 | |
| *** sakoman <sakoman!~steve@172.243.4.16> has joined #yocto | 21:35 | |
| *** dvorkindmitry <dvorkindmitry!~dvorkindm@5.167.98.73> has joined #yocto | 21:40 | |
| dvorkindmitry | how can I enable myscript@eth1.service in .bb file? | 21:41 |
| tp43_ | I added the meta-raspberrypi to my bblayer.conf and set MACHINE to raspberrypi4-64.conf. But now how do I bitbake ___? bitbake core-image-minimal didn't work | 21:55 |
| tp43_ | when I run bitbake-layers I get error "no response from server" | 21:59 |
| *** LetoThe2nd <LetoThe2nd!uid453638@id-453638.highgate.irccloud.com> has quit IRC (Quit: Connection closed for inactivity) | 22:13 | |
| tp43_ | Aha, got it. $bitbake rpi-basic-image, or rpi-hwup-image or rpi-test-image | 22:16 |
| *** florian <florian!~florian@p54b4f74d.dip0.t-ipconnect.de> has quit IRC (Ping timeout: 268 seconds) | 22:23 | |
| *** jwillikers <jwillikers!~jwilliker@ics141-1.icsincorporated.com> has quit IRC (Quit: jwillikers) | 22:24 | |
| *** jwillikers <jwillikers!~jwilliker@ics141-1.icsincorporated.com> has joined #yocto | 22:25 | |
| tp43_ | no that might not be right | 22:28 |
| tp43_ | My bitbake isn't working after adding raspberrypi, so I reverted, deleted the pi line in bblayers.conf and changed back the machine in local.conf. And it wont build the simple core-image-minimal emulated one either now. I deleted the bitbake.lock too, that didn't help. | 22:37 |
| *** aleblanc_ <aleblanc_!~aleblanc@192-222-183-114.qc.cable.ebox.net> has joined #yocto | 22:38 | |
| tp43_ | Your version of local.conf was generated from an older/newer version | 22:38 |
| *** aleblanc_ <aleblanc_!~aleblanc@192-222-183-114.qc.cable.ebox.net> has quit IRC (Remote host closed the connection) | 22:39 | |
| *** aleblanc_ <aleblanc_!~aleblanc@192-222-183-114.qc.cable.ebox.net> has joined #yocto | 22:39 | |
| tp43_ | ok, I copy that file over it mentioned in meta-poky/conf/local.conf.sample to build/conf/local.conf and it is building again ok. | 22:41 |
| *** aleblanc_ <aleblanc_!~aleblanc@192-222-183-114.qc.cable.ebox.net> has quit IRC (Ping timeout: 258 seconds) | 22:45 | |
| *** dvorkindmitry <dvorkindmitry!~dvorkindm@5.167.98.73> has quit IRC (Quit: KVIrc 5.0.0 Aria http://www.kvirc.net/) | 22:50 | |
| tp43_ | What do I put for machine for the meta-raspberrypi? | 22:51 |
| *** jwillikers <jwillikers!~jwilliker@ics141-1.icsincorporated.com> has quit IRC (Remote host closed the connection) | 22:53 | |
| *** alicef_ <alicef_!~none@gentoo/developer/alicef> has joined #yocto | 23:20 | |
| *** Fanfwe <Fanfwe!~fanfwe@im.goudal.net> has quit IRC (Quit: ZNC 1.8.2+deb2+b1 - https://znc.in) | 23:20 | |
| *** alicef <alicef!~none@gentoo/developer/alicef> has quit IRC (Remote host closed the connection) | 23:20 | |
| *** Fanfwe <Fanfwe!~fanfwe@im.goudal.net> has joined #yocto | 23:21 | |
| tp43_ | anyone used sierrawireless? | 23:47 |
| *** tangofoxtrot <tangofoxtrot!~tangofoxt@user/tangofoxtrot> has quit IRC (Remote host closed the connection) | 23:57 | |
| *** tangofoxtrot <tangofoxtrot!~tangofoxt@user/tangofoxtrot> has joined #yocto | 23:59 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!