Friday, 2021-08-13

*** ecdhe_ <ecdhe_!> has joined #yocto00:18
*** ecdhe <ecdhe!> has quit IRC (Ping timeout: 256 seconds)00:21
*** zeddii <zeddii!> has quit IRC (Ping timeout: 268 seconds)00:29
*** shoragan[m] <shoragan[m]!~shoraganm@2001:470:69fc:105::39> has joined #yocto00:29
*** kayterina[m] <kayterina[m]!~kayterina@2001:470:69fc:105::960> has joined #yocto00:31
*** zeddii <zeddii!> has joined #yocto00:32
*** cody <cody!~cody@user/cody> has joined #yocto00:41
*** zeddii <zeddii!> has quit IRC (Ping timeout: 268 seconds)00:50
*** SamuelDolt[m] <SamuelDolt[m]!~samdoltma@2001:470:69fc:105::4898> has joined #yocto01:05
*** jwillikers <jwillikers!> has joined #yocto01:11
*** jwillikers <jwillikers!> has quit IRC (Remote host closed the connection)01:11
*** hmw[m] <hmw[m]!~hmwmatrix@2001:470:69fc:105::3c7c> has joined #yocto01:13
*** shoragan|m <shoragan|m!~shoragans@2001:470:69fc:105::c9f> has joined #yocto01:21
*** rostam98[m] <rostam98[m]!~rostam98m@2001:470:69fc:105::ca0e> has joined #yocto01:21
*** Spectrejan[m] <Spectrejan[m]!~spectreja@2001:470:69fc:105::1609> has joined #yocto01:23
*** berton[m] <berton[m]!~fabiobert@2001:470:69fc:105::ce36> has joined #yocto01:28
*** Emantor[m] <Emantor[m]!~emantorm]@2001:470:69fc:105::8eb> has joined #yocto01:33
*** moto_timo[m] <moto_timo[m]!~mototimom@2001:470:69fc:105::c94> has joined #yocto01:34
*** jonesv[m] <jonesv[m]!~jonesvmat@2001:470:69fc:105::4616> has joined #yocto01:34
*** meck[m] <meck[m]!~meckmeckd@2001:470:69fc:105::3a51> has joined #yocto01:37
*** ejoerns[m] <ejoerns[m]!~ejoernsma@2001:470:69fc:105::252> has joined #yocto01:44
*** PascalBach[m] <PascalBach[m]!~bachpmatr@2001:470:69fc:105::1d3b> has joined #yocto01:45
*** barath <barath!~barath@2001:470:69fc:105::21a> has joined #yocto01:46
*** tokamak[m] <tokamak[m]!~tokamakma@2001:470:69fc:105::c4df> has joined #yocto01:48
*** jwillikers[m] <jwillikers[m]!~jwilliker@2001:470:69fc:105::626a> has joined #yocto01:53
*** t_unix[m] <t_unix[m]!~tunixmatr@2001:470:69fc:105::9ea> has joined #yocto01:56
*** Pierre-jeanTexie <Pierre-jeanTexie!~pjtexierm@2001:470:69fc:105::f2f> has joined #yocto02:00
*** hpsy <hpsy!~hpsy@> has joined #yocto02:02
*** m1kr0[m] <m1kr0[m]!~m1kr0matr@2001:470:69fc:105::c827> has joined #yocto02:06
*** jordemort <jordemort!~jordemort@2001:470:69fc:105::2d9> has joined #yocto02:10
*** camus <camus!~Instantbi@> has quit IRC (Ping timeout: 268 seconds)02:13
*** camus <camus!~Instantbi@> has joined #yocto02:13
*** Alban[m] <Alban[m]!~albeugaen@2001:470:69fc:105::34b4> has joined #yocto02:21
*** dwagenk <dwagenk!~dwagenk@2001:470:69fc:105::103d> has joined #yocto02:24
*** khem <khem!~khemmatri@2001:470:69fc:105::b81> has joined #yocto02:31
*** behanw[m] <behanw[m]!~behanwmat@2001:470:69fc:105::c96> has joined #yocto02:37
*** nicolas[m]12 <nicolas[m]12!~nicolasma@2001:470:69fc:105::b5f4> has joined #yocto02:37
*** amitk <amitk!~amit@> has joined #yocto02:40
*** lexano[m] <lexano[m]!~lexanomat@2001:470:69fc:105::3110> has joined #yocto02: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 #yocto02:45
*** michaelo[m] <michaelo[m]!~michael-o@2001:470:69fc:105::be7c> has joined #yocto02:50
*** halstead[m] <halstead[m]!~halsteadm@2001:470:69fc:105::d0ef> has joined #yocto02:51
*** Saur[m] <Saur[m]!~saur2000m@2001:470:69fc:105::dce> has joined #yocto02:52
*** falk0n[m] <falk0n[m]!~falk0nmat@2001:470:69fc:105::ce60> has joined #yocto02:53
*** michaelo[m]1 <michaelo[m]1!~michaelom@2001:470:69fc:105::d101> has joined #yocto02:54
*** peterp <peterp!~peterp@2607:f2c0:e154:2bf::776> has joined #yocto03:15
peterpHi, 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@> has joined #yocto03:30
*** camus <camus!~Instantbi@> has quit IRC (Ping timeout: 268 seconds)03:31
*** camus1 is now known as camus03:31
*** zeddii <zeddii!> has joined #yocto03:37
*** wing0 <wing0!~wing0@2804:431:c7ed:41c:20ad:47f:325f:7c35> has quit IRC (Quit: WeeChat 3.1)04:40
*** roussinm <roussinm!> has quit IRC (Quit: WeeChat 3.3-dev)05:27
*** paulg <paulg!> has quit IRC (Ping timeout: 248 seconds)06:01
*** rob_w <rob_w!> has joined #yocto06:04
*** vmeson <vmeson!> has quit IRC (Ping timeout: 268 seconds)06:04
*** kranzo <kranzo!> has joined #yocto06:35
*** sbach <sbach!~sbach@user/sbach> has quit IRC (Read error: Connection reset by peer)06:40
*** sbach <sbach!~sbach@user/sbach> has joined #yocto06:40
*** dtometzki <dtometzki!~dtometzki@fedora/dtometzki> has joined #yocto06:49
*** goliath <goliath!~goliath@user/goliath> has joined #yocto06:51
*** bps <bps!~bps@user/bps> has quit IRC (Read error: Connection reset by peer)06:59
*** bps <bps!> has joined #yocto06:59
*** LetoThe2nd <LetoThe2nd!> has joined #yocto07:06
LetoThe2ndyo dudX07:06
*** dmoseley <dmoseley!~dmoseley@> has quit IRC (Read error: Connection reset by peer)07:12
*** dmoseley <dmoseley!~dmoseley@> has joined #yocto07:16
cocoJoegood morning07:17
qschulzpeterp: 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-boot07:53
qschulzbut i'm not entirely sure it makes sense, device trees used in U-Boot and the kernel are often different. Similar but different07:54
qschulzthe drivers don't always expect the same properties for example07:54
qschulzso the other way could be to just duplicate the dtsi from the kernel and add it to the u-boot recipe directly07:54
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto08:34
*** d0ku <d0ku!> has joined #yocto09:04
*** leon-anavi <leon-anavi!~Leon@> has quit IRC (Quit: Leaving)09:06
*** kranzo <kranzo!> 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!> has quit IRC (Ping timeout: 246 seconds)09:31
*** argonautx <argonautx!> has joined #yocto09:34
*** wCPO <wCPO!> has joined #yocto09:45
wCPOIs 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-only09:54
*** mihai <mihai!~mihai@user/mihai> has quit IRC (Remote host closed the connection)10:04
RPmoto-timo: looks like a good fix, thanks10:10
qschulzmoto-timo: now I need to keep up with the ML to fix those in the various documentations too :) cc michaelo10:11
qschulzmight have missed a few since I was not subscribed to the oe-core ML10:11
RPrburton: we have a buildtools issue now? :/10:11
*** florian <florian!> has joined #yocto10:14
*** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV)10:19
rburtonRP: the glibc one i moaned about, or another one?10:32
*** rob_w <rob_w!> has quit IRC (Quit: Leaving)10:39
*** florian <florian!> has quit IRC (Ping timeout: 248 seconds)10:57
*** jwillikers <jwillikers!> has joined #yocto11:10
*** goliath <goliath!~goliath@user/goliath> has joined #yocto11:23
*** camus1 <camus1!~Instantbi@> has joined #yocto11:27
*** camus <camus!~Instantbi@> has quit IRC (Read error: Connection reset by peer)11:28
*** camus1 is now known as camus11:28
RPrburton: glibc one12:34
rburtonchasing it down as we speak12:34
rburtonits annoyingly slow to bisect :)12:34
wCPOIs 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
LetoThe2ndwCPO: nope, it certainly works.12:46
wCPOLetoThe2nd: 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 seems12:50
*** tp43_ <tp43_!~ndeem@2001:1970:501a:e201:e021:97c4:bc6c:f59a> has joined #yocto13:04
LetoThe2ndwCPO: i have no experience with ISOs, sorry.13:04
*** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV)13:09
*** camus <camus!~Instantbi@> has quit IRC (Quit: camus)13:16
JPEWAre circualar RDEPENDS allowed? I added a task with do_foobar[rdeptask] = "do_foobar" and it fails on some recipes with a circular dep error13:20
RPJPEW: no, they're not13:21
JPEWOk, so what I did with do_foobar is allowed and I should fix the recipes?13:21
JPEWKinda 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 check13:22
RPJPEW: hmm, I think that is allowed13:31
RPJPEW: I think the code knows to remove self references13:31
JPEWRP: This trivial class errors out:13:35
RPJPEW: it is possible since there is meta/recipes-devtools/xmlto/[rdeptask] = "do_populate_sysroot"13:39
*** argonautx <argonautx!> has quit IRC (Quit: Leaving)13:39
RPJPEW: I suspect if you add in general dependencies there are problems :/13:39
RPJPEW: usually you're looking for recrdeptask and not rdeptask13:40
*** ptsneves <ptsneves!> has joined #yocto13:49
ptsnevesHey all. Does anybody know why $(( )) expressions which are POSIX compliant fail in dunfell? Am I missing something?13:50
ptsneveswhen i mean fail, i mean the parsing fails13:50
qschulzptsneves: are you appending/prepending to an already existing task?13:51
ptsnevesi am intrigued with that question. Do you think it makes a difference?13:52
qschulzare you sure you're appending to a shell task?13:53
qschulzwe have support for python tasks13:53
qschulzand some are13:53
JPEWRP: 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
ptsnevesqschulz yes i am. I am putting the $(( in a task which has other shell stuff. The same happens for $(( inside functions executed by
ptsnevesfunny 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
ptsnevesregardless i would not expect the $(( to make the parser fail13:57
qschulzptsneves: bitbake probably is looking for strings starting with $ and tries to replace it if it has a variable matrching the name13:57
JPEWptsneves: 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
qschulzthere's variable substitution done during parsing I'm absolutely sure of it13:58
*** sakoman <sakoman!~steve@> has joined #yocto13:58
RPJPEW: Do you mean the package runtime dependencies or the RDEPENDS of the recipe?13:58
RPJPEW: RDEPENDS are usually incomplete until after do_package and the fact some things are only in DEPENDS13:59
JPEWRP: 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
RPJPEW: I think you're nearly on the right track :)14:00
JPEWRP: Also, you need the runtime dependencies to have run their SPDX generation before the current recipe, which I *think* means rdeptask?14:01
ptsnevesJPEW 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
RPJPEW: the do_package_write_* code already has to do this for different reasons so you want to emulate something like that I'd guess14:01
RPJPEW: do_package_write_ipk[rdeptask] = "${DEBIANRDEP}" - I'd have a look at that code, see if the PACKAGES = "" anon python helps14:03
JPEWRP: Thanks14:03
*** vd <vd!> has quit IRC (Quit: Client closed)14:07
RPJPEW: 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
JPEWRP: Ya, that was the conclusion I was coming to14:08
JPEWRp: Hence my do_create_spdx[rdeptask] = "do_create_spdx", which doesn't work14:09
frayJPEW I'm just catching up, but I worked on planning something that sounds similar..14:09
frayWe 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
frayWe'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 configurations14:10
frayand 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
fraythat way we could find and capture staticly linked, as well as functions embedded in headers.14:11
JPEWfray: 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 DAG14:11
fraythe end result was a set of XML files that together game a full picture of original source -> patches/configured source -> binary14:11
*** vd <vd!> has joined #yocto14: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
RPJPEW: I think we'd need to understand exactly what kind of circular reference that is causing :/14:14
RPJPEW: this stuff can get tricky. I suspect I'm not in the best of states to think clearly about it either :(14:14
frayI never implemented what I designed, but we didn't see any circular references in it, but it did expand the sysroot information required14:14
JPEWRP: Yep. I can compile a list of the ones I find quick14:16
*** vmeson <vmeson!> has joined #yocto14:20
JPEWRP: 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 it14:25
*** paulg <paulg!> has joined #yocto14:26
frayI 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
frayso 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
JPEWfray: Ya, I'm leveraging the recipe metadata a lot more14:30
RPJPEW: 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
JPEWRP: Right14:31
wCPOHow 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 iso14:31
fraynot sure I mentioned, but our expectation was also to create a ${PN}-spdx package (like the -lic package)14:31
JPEWfray: You should look at what I have in
JPEW(If you care)14:41
*** cocoJoe <cocoJoe!~cocoJoe@> has joined #yocto14:43
*** cocoJoe <cocoJoe!~cocoJoe@> has quit IRC (Client Quit)14:44
*** cocoJoe <cocoJoe!~cocoJoe@> has joined #yocto14:44
frayare you doing any debug symbol processing?14:44
JPEWfray: Yes14:44
JPEWfray: Look in add_package_sources_from_debug()14:45
frayhow are you generatin the list?14:46
JPEWfray: package.bbclass already had the list, I just made it dump it out somewhere14:47
*** tre <tre!> has joined #yocto14:47
frayIs that list complete?  I thought it only referred to items from within the existing sources14:47
JPEWfray: Seems complete to me14:48
frayDoes it include all of the headers from external items, like glibc?14:48
JPEWfray: tes14:48
*** d0ku <d0ku!> has quit IRC (Quit: Client closed)14:48
frayok, 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
fraythose 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
JPEWNot sure about the .a. I think it will as long as the .a has debug info14:50
*** tre <tre!> has quit IRC (Quit: Leaving)14:50
JPEWfray: Example output: (obviously, still WIP)14:50
fraythe 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
frayso 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 ourselves14:51
fray(I'm assuming the .a was processed in pkgA, and an SPDX was generated that referenced the orgiinal upstream sources)14:51
JPEWfray: The eaiser path would be to add a STATIC_LINK relationship14:53
JPEWfray: Well, "easier" from a SPDX standpoint. Knowing a static link has occured is hard :)14:54
frayknowing 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
fraythere 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
fraybut the key, we can't directly scan the dependency (rm_work and all), but we can read our dependencies SPDX and transfer data14:57
JPEWYa, we can mark the files with a GENERATED_FROM NOASSERTION15:00
JPEWMeaning, we know it was generated from somewhere, but we have no idea what that is :)15:00
fraybut 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
frayya, 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
JPEWYa, 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
JPEWfray: Ok, I have to doing a GENERATED_FROM NOASSERTION any any unknown debug sources now15:07
alimonIn 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 in15:11
alimonERROR: 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.bb15:11
alimon/home/builds/oe-rpb-master/build-410c-2/conf/../../layers/meta-clang/dynamic-layers/selinux/android-tools/ 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
alimonalso 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 available15:11
*** goliath <goliath!~goliath@user/goliath> has joined #yocto15:15
*** camus <camus!~Instantbi@2409:8a1e:9115:d1d0:8d8e:69cf:78f9:c939> has joined #yocto15:19
alimonRP: rburton any idea ^15:21
alimonkhem: 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 good15:36
*** LetoThe2nd <LetoThe2nd!> has quit IRC (Quit: Connection closed for inactivity)15:38
*** cocoJoe <cocoJoe!~cocoJoe@> has quit IRC (Quit: Quit)15:38
RPalimon: that usually means the recipes aren't identical and one provides something the other doesn;t15:44
RPalimon: also, layer priorities may override PREFERRED_VERSION :/15:44
alimonRP: yep, it differs with new and old syntax for appends15:45
alimonRP: 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 available15:46
alimonthen there is other issue about not being able to select the preferred version because two recipes are in the file_set inside bitbake15:46
*** camus <camus!~Instantbi@2409:8a1e:9115:d1d0:8d8e:69cf:78f9:c939> has quit IRC (Ping timeout: 272 seconds)16:02
RPalimon: the trouble is I doubt you can change behaviour like that without breaking other things, at least if I understand the issue correctly16:07
RPalimon: if the provides are different, it will break regardless of how much you set that stuff16:07
alimonRP: yeah, i think the best solution is move the android-tools new recipe inside meta-oe16:09
*** leon-anavi <leon-anavi!> has joined #yocto16:25
*** bps <bps!~bps@user/bps> has quit IRC (Ping timeout: 248 seconds)16:34
*** ptsneves <ptsneves!> has quit IRC (Quit: Connection closed)16:39
*** leon-anavi <leon-anavi!> has quit IRC (Quit: Leaving)16:39
fray'er.. wrong channel16:48
*** tp43_ <tp43_!~ndeem@2001:1970:501a:e201:e021:97c4:bc6c:f59a> has joined #yocto17:00
*** LetoThe2nd <LetoThe2nd!> has joined #yocto18:44
*** dev1990 <dev1990!> has joined #yocto18:44
LetoThe2ndkhem: howdy! Can you recommend a riscv board that (mostly) world ootb with meta-riscv?18:45
*** fitzsim <fitzsim!> has quit IRC (Ping timeout: 252 seconds)18:48
*** jwillikers <jwillikers!> has quit IRC (Remote host closed the connection)18:49
*** roussinm <roussinm!> has joined #yocto18:52
*** jwillikers <jwillikers!> has joined #yocto19:31
*** Chep <Chep!~chep@> has quit IRC (Ping timeout: 245 seconds)19:50
*** prabhakarlad <prabhakarlad!> has quit IRC (Quit: Client closed)19:52
*** aleblanc_ <aleblanc_!> 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? is clearly not the answer20:34
*** prabhakarlad <prabhakarlad!> has joined #yocto20:36
smurraymanuel_: it's definitely not as clear as it could be, you click on the number of commits:
*** amitk <amitk!~amit@> has quit IRC (Ping timeout: 248 seconds)20:38
manuel_smurray: That's not a link on my system, i.e. it's not clickable20:39
smurraymanuel_: sorry, I meant from the main repo page, i.e. "20,546 commits" on
manuel_smurray: Ah, I see. Got it now. Thanks :)20:41
*** mrdmitry <mrdmitry!~dmitry@> has quit IRC (Quit: WeeChat 2.8)20:57
manuel_What exactly means distro-less?20:57
abelloniwith DISTRO not defined21: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 well21:04
marexabelloni: DISTRO="nodistro" , no ?21:05
fray"nodistro" is just a set of defaults..21:06
marexmanuel_: the stuff defined in yourdistro.conf is not defined ... is what it gets you21:06
JPEWmanuel_: it can be useful if you want a lot of different things to behave with a similar (centralized) policy21:06
JPEWe.g. different machines21:06
marexJPEW: that ... is not entirely clear ?21:07
marexJPEW: I mean, that does not really explain what nodistro is about21:08
marexJPEW: if you want centralized policy, dont you define your own distro in distro layer ?21:08
JPEWmarex: Ya, nodistro means "I'm not going to do that" (I think, I don't use nodistro TBH)21:09
* tlwoerner uses nothing but nodistro21:09
* marex uses many custom distros21:09
tlwoernerwhat'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 problem21: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:
marextlwoerner: 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 useless21:11
manuel_DEFAULT_TEST_SUITES:pn-meta-oe-ptest-image = " ${PTESTTESTSUITE}"21:11
marexI cant decide which way is better to go about it21:11
manuel_NON_MULTILIB_RECIPES:append = " crash"   <---- the colon here looks strange21:12
manuel_marex: I think this whole poky thing is more confusing than in helps. At least to me, as a beginner.21:12
marexmanuel_: it is a reference distro for starters ...21:13
marexbetter than having nodistro as a starting point , heh21:13
tlwoernerpoky is the sample distro that's used for testing21:13
abellonimarex: if you include poky.conf and suddenly this switches from X11 to wayland or sysv to systemd, you can have some surprises21:17
marexabelloni: well ... yes ... that's solved if you duplicate large part of poky.conf into your own customdistro.conf21:18
marexabelloni: 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.conf21:19
tp43_I am getting access denied or repo not exported for various branches of /meta-respberrypi21:20
marextp43_: where ?21:20
marexlocally ? 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 reply21:22
*** florian <florian!> has joined #yocto21:25
*** sakoman <sakoman!~steve@> has quit IRC (Read error: Connection reset by peer)21:33
*** sakoman <sakoman!~steve@> has joined #yocto21:35
*** dvorkindmitry <dvorkindmitry!~dvorkindm@> has joined #yocto21:40
dvorkindmitryhow 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 work21:55
tp43_when I run bitbake-layers I get error "no response from server"21:59
*** LetoThe2nd <LetoThe2nd!> 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-image22:16
*** florian <florian!> has quit IRC (Ping timeout: 268 seconds)22:23
*** jwillikers <jwillikers!> has quit IRC (Quit: jwillikers)22:24
*** jwillikers <jwillikers!> has joined #yocto22:25
tp43_no that might not be right22: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_!> has joined #yocto22:38
tp43_Your version of local.conf was generated from an older/newer version22:38
*** aleblanc_ <aleblanc_!> has quit IRC (Remote host closed the connection)22:39
*** aleblanc_ <aleblanc_!> has joined #yocto22: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_!> has quit IRC (Ping timeout: 258 seconds)22:45
*** dvorkindmitry <dvorkindmitry!~dvorkindm@> has quit IRC (Quit: KVIrc 5.0.0 Aria
tp43_What do I put for machine for the meta-raspberrypi?22:51
*** jwillikers <jwillikers!> has quit IRC (Remote host closed the connection)22:53
*** alicef_ <alicef_!~none@gentoo/developer/alicef> has joined #yocto23:20
*** Fanfwe <Fanfwe!> has quit IRC (Quit: ZNC 1.8.2+deb2+b1 -
*** alicef <alicef!~none@gentoo/developer/alicef> has quit IRC (Remote host closed the connection)23:20
*** Fanfwe <Fanfwe!> has joined #yocto23: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 #yocto23:59

Generated by 2.17.2 by Marius Gedminas - find it at!