Friday, 2021-03-12

*** jdrol <jdrol!> has quit IRC00:06
*** goliath <goliath!> has quit IRC00:33
*** kiwi_29 <kiwi_29!> has joined #yocto00:33
*** NiksDev <NiksDev!~NiksDev@> has quit IRC00:37
*** kiwi_29 <kiwi_29!> has quit IRC00:38
mouser_I feel like I am chasing a failure of the compile-host-path WARN_QA check.00:58
mouser_I can get a very clear build failure if I delete an include file on my host, which should not happen. I see the same include file in the build sysroot.00:59
mouser_do_compile log, recipe, and Makefile ->
*** dreyna <dreyna!> has joined #yocto01:02
*** bobo <bobo!> has quit IRC01:12
*** bobo <bobo!> has joined #yocto01:41
Spoostertrying to run xinit as non-root on an rpi4... found the ROOTLESS_X config, added pam, built an image, and things seemed well. X won't start ofc, and after sorting some permission issues with the /dev/tty* it's trying to attach to, it looks like the xuser is getting pretty far along in the init... but it's failing when loading libfb01:45
SpoosterWithout having to dive into libfb internals... my guess is that it could be a permissions issue, creating a framebuffer in memory, and the xuser doesn't have permissions... no idea how to track that down currently01:47
SpoosterIt's worth mentioning that X runs as root just fine... so I'm near certain it's a permission issue01:49
khemRP:  thanks, yeah I was wondering, I guess it disappeared before my attention :)01:49
khemSpooster: yes see in logs it says [  1120.040] (EE) modeset(0): drmSetMaster failed: Permission denied01:58
khemso perhaps you have to let xuser be able to access drm device perhaps01:58
khemjust do ls -l /dev/dri/card*01:59
khemand see what permissions do they have01:59
SpoosterI don't have any /dev/drm* hiding anywhere... but I did check the /dev/dri entries, and unfortunately, those seem to line up with what I'd expect01:59
Spooster /dev/dri/card0 and card1 are in the video group, and xuser is as well... permissions are 66002:00
khemhmm then it should work02:01
Spoosterthere IS a /dev/dri/renderD128 ... which is curiously in the render group...02:01
khemfor tests change the perms to 777 and see if it helps02:01
Spoosterwill do... gonna also tinker with this renderD128...02:02
Spooster:( no dice02:05
khemtry sudo chgrp video /dev/dri/renderD12802:05
khemand see if that helps02:05
SpoosterOh, I just added xuser to the render group instead02:05
Spoosterbut sure02:05
khemI think they should be in same grp02:05
khemyeah that will work too02:05
khemI think you can perhaps control this via udev rules02:06
Spoosterfor sure... I'm already going to need to go there to fix /dev/ttyN group access from 640 to 66002:06
khemlook for *.rules files in /usr and /etc02:06
khemyou already might have a rules file that you can edit02:06
SpoosterI did scour /etc... we don't have much in /usr for udev right now on this image02:07
Spoosterbut that's a step 2...02:07
khemare you using systemd ?02:07
Spoostereven after adding the user to the group, or 777'ing the renderD128 device... it's still throwing that Permission Denied02:08
SpoosterI'll get around to the udev stuff once I figure out what I need to hit with a hammer... just want to know what to try02:09
Spoosterthe only thing left in there is /dev/dri/by-path ... no idea what these are honestly02:09
khemwhats the perms now ?02:09
khemon reboot these perms will be lost02:10
Spooster(what's etiquette for console output in the 5-10 line range? pastebin still?)02:10
khemmore than 4 lines perhaps pastebin it02:11
SpoosterYeah, I'm aware that I'll need to get this all down into udev rules... I've already added some for `/dev/ttyS0`02:12
khemok this looks fine to me02:12
Spoostersystemd is still hammering away every 15 seconds or so trying to run xinit... and it's still getting to the same point. modeset(0): drmSetMaster failed: Permission denied02:13
Spoosterfor what it's worth... I do see the screen seem to draw output from a different console for like... 1/2 a second02:14
Spoosterit looks like colorized dmesg output... maybe 8 lines or so02:14
Spoosterthat might imply that it's not a video device related permissions error... if it's actually getting to the point where SOMETHING is on screen02:14
khemis there anything in /home/xuser/.local/share/xorg/Xorg.0.log02:15
SpoosterI pasted that already, but I'll get a fresh copy02:15
Spooster(For more information, please reread this message)02:16
*** camus <camus!~Instantbi@> has joined #yocto02:17
*** kaspter <kaspter!~Instantbi@> has quit IRC02:18
*** camus is now known as kaspter02:18
khemI wonder if its racing with video driver02:20
Spoosterwould root be able to xinit if that was the case?02:20
Spoosterbecause it definitely can...02:20
khemhmmm not sure root is special in many ways02:21
khemwhat happens if you move /usr/lib/xorg/modules/ out of way02:21
SpoosterI'm tempted to walk through all remaining devices and 777 them for this boot02:21
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has joined #yocto02:21
khemwhats the version of systemd you are using02:22
SpoosterNot going to lie, I'm super green here... Are you suggesting I just straight up mv /usr/lib/xorg/modules/ to some other location for now?02:22
Spoostersystemd 244 (244.5+)02:23
khemyes mv it02:25
khemjust for tests02:25
Spoosterafter nabbing
khematomics in modesetting can be troublesome see
khemyeah move it back02:27
Spoosterseems like this is the only driver available for now...02:27
*** paulg <paulg!> has quit IRC02:27
khemdo you have xorg.conf02:28
Spoosterthere are some rules in /usr/share/X11/xorg.conf.d/02:28
Spoosteri'll dump em now02:28
Spoosterthey're both pretty small02:29
khemwhat does cat /sys/kernel/debug/dri/0/clients say02:29
*** tgoodwin <tgoodwin!> has joined #yocto02:29
Spoosterthat's empty... likely because nothing's running02:30
khemeven after moving fb driver back ?02:31
Spooster10-quirks.conf  40-libinput.conf
Spoosteryeah... I was actually there from another forum post from earlier... because x is just straight up dying, I wasn't surprised to see that there weren't any entries02:32
Spoostersurprisingly... there really isn't a top level xorg.conf anywhere02:32
Spooster /etc/X11/xorg.conf is just an empty file with a comment saying to put stuff in xorg.conf.d/02:33
khemtry to put needs_root_rights=yes in /etc/X11/Xwrapper.config and see if this helps02:34
Spoosterthat file doesn't currently exist, but it can't hurt to make it, and see what sparks fly02:35
*** sakoman <sakoman!> has quit IRC02:39
khemthose files worked in old times not sure if they still work with new X but try it02:41
SpoosterI did give it a go, no dice :(02:42
*** caiortp <caiortp!> has quit IRC02:42
khemyou might find this useful
SpoosterI get a pretty indecipherable message when I try to 'loginctl user-status'    Could not get properties: Unknown object '/org/freedesktop/login1/user/self'02:46
Spoosterone could presume that elogind is not properly configured, function, or present02:48
SpoosterMight investigate the line systemd-logind: failed to get session: PID 1542 does not belong to any known session02:58
Spoostersounds like a thing for tomorrow Spooster... maybe they'll figure it out02:58
*** tgoodwin <tgoodwin!> has quit IRC03:02
*** paulg <paulg!> has joined #yocto03:03
*** ByteLawd <ByteLawd!extor@unaffiliated/extor> has joined #yocto03:03
*** bobo <bobo!> has quit IRC03:05
*** kiwi_29 <kiwi_29!> has joined #yocto03:16
*** kiwi_29 <kiwi_29!> has quit IRC03:21
*** ByteLawd <ByteLawd!extor@unaffiliated/extor> has quit IRC03:25
*** ByteLawd <ByteLawd!extor@unaffiliated/extor> has joined #yocto03:25
zeddiialephan: the fix for the configuration warning is pushed to the 5.10 kernel meta data. i tested on master and a hacked-up dunfell.03:29
*** ByteLawd <ByteLawd!extor@unaffiliated/extor> has quit IRC03:34
*** ByteLawd <ByteLawd!extor@unaffiliated/extor> has joined #yocto03:35
*** ByteLawd <ByteLawd!extor@unaffiliated/extor> has joined #yocto03:36
*** ByteLawd <ByteLawd!extor@unaffiliated/extor> has quit IRC03:41
*** ByteLawd <ByteLawd!extor@unaffiliated/extor> has joined #yocto03:43
*** ahadi <ahadi!~ahadi@> has quit IRC04:00
*** ahadi <ahadi!~ahadi@> has joined #yocto04:01
*** Kyubi_ <Kyubi_!~Kyubi@2601:647:4080:f10:a8a0:3849:29ba:e8a3> has joined #yocto04:04
*** Kyubi <Kyubi!~Kyubi@> has quit IRC04:04
*** amitk <amitk!~amit@unaffiliated/amitk> has joined #yocto04:27
*** kaspter <kaspter!~Instantbi@> has quit IRC04:55
*** kaspter <kaspter!~Instantbi@> has joined #yocto04:56
*** bobo <bobo!> has joined #yocto04:58
khemzeddii:  qemuppc64 defconfig needs some fixing seeing these warnings
khemthis is 5.10 kernel05:04
*** jobroe <jobroe!> has joined #yocto05:49
*** Kyubi_ <Kyubi_!~Kyubi@2601:647:4080:f10:a8a0:3849:29ba:e8a3> has quit IRC05:55
*** alessioigor <alessioigor!> has joined #yocto05:59
*** alessioigor <alessioigor!> has quit IRC06:00
*** Kyubi <Kyubi!~Kyubi@> has joined #yocto06:04
*** JosephAntony <JosephAntony!a5e10863@> has joined #yocto06:09
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has quit IRC06:24
*** beneth <beneth!> has joined #yocto06:29
*** Tralla <Tralla!> has joined #yocto06:30
*** B0ned1ger <B0ned1ger!> has joined #yocto06:31
*** Tralla <Tralla!> has quit IRC06:32
*** Wouter0100 <Wouter0100!> has quit IRC06:33
*** Wouter0100 <Wouter0100!> has joined #yocto06:34
*** AndersD <AndersD!> has joined #yocto06:35
*** AndersD_ <AndersD_!> has joined #yocto06:37
*** zyga <zyga!~zyga@unaffiliated/zyga> has joined #yocto06:39
*** AndersD <AndersD!> has quit IRC06:40
*** Tralla <Tralla!> has joined #yocto06:42
*** bobo <bobo!> has quit IRC06:43
*** Tralla <Tralla!> has quit IRC06:46
*** Tralla <Tralla!> has joined #yocto06:47
*** Tralla <Tralla!> has joined #yocto06:56
*** Tralla <Tralla!> has quit IRC06:57
*** bobo <bobo!> has joined #yocto07:01
*** seebs <seebs!~seebs@> has quit IRC07:01
*** Spooster <Spooster!> has quit IRC07:02
*** agust <agust!> has joined #yocto07:03
*** kpo <kpo!> has quit IRC07:03
*** Spooster <Spooster!> has joined #yocto07:03
*** kpo <kpo!> has joined #yocto07:03
*** rcoote <rcoote!> has joined #yocto07:04
*** paulg <paulg!> has quit IRC07:05
*** Spooster <Spooster!> has quit IRC07:08
*** tralla <tralla!> has joined #yocto07:09
*** seebs <seebs!~seebs@> has joined #yocto07:11
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has joined #yocto07:12
trallaI want to use the MACHINE_FEATURES to be able to change the behavior for some features (enable/disable) between different builds. But for some reasons I cannot get get it to work when setting MACHINE_FEATURES += " myfeature" in local.conf. When debugging, I can see that the MACHINE_FEATURES list will not include myfeature. Assuming this is expected07:15
trallabehavior, can I append MACHINE_FEATURES dynamically between different builds in some other way?07:15
*** dreyna <dreyna!> has quit IRC07:24
*** JPEW <JPEW!~JPEW@2605:a601:ac3d:c100:e3e8:d9:3a56:e27d> has quit IRC07:25
*** JPEW <JPEW!~JPEW@2605:a601:ac3d:c100:e3e8:d9:3a56:e27d> has joined #yocto07:26
*** ENPJ <ENPJ!~ENPJ@2001:a61:3a33:7901:a9f0:885a:b6b3:4a54> has joined #yocto07:28
*** bobo <bobo!> has quit IRC07:30
*** bobo <bobo!> has joined #yocto07:32
*** mckoan|away is now known as mckoan07:50
mckoangood morning07:50
*** mcburger <mcburger!> has joined #yocto07:52
*** B0ned1ger2 <B0ned1ger2!> has joined #yocto07:53
mcburgerhow can I include a specific driver for hardware in yocto?07:53
*** B0ned1ger <B0ned1ger!> has quit IRC07:55
mckoantralla: MACHINE_FEATURES is expected to be used in a machine configuration file, not local.conf07:55
*** camus <camus!~Instantbi@> has joined #yocto07:55
mckoanmcburger: specific driver? please elaborate07:56
mcburgerfor example I have a sensor that communicates over spi, numbered m238.c and I want to include that driver07:56
mcburgerjust an example07:57
*** kaspter <kaspter!~Instantbi@> has quit IRC07:57
*** camus is now known as kaspter07:57
*** Yumasi <Yumasi!> has joined #yocto08:00
*** jkridner|pd <jkridner|pd!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto08:02
*** LetoThe2nd <LetoThe2nd!uid453638@gateway/web/> has joined #yocto08:03
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC08:04
*** bobo <bobo!> has quit IRC08:07
trallamckoan yeah, that makes sense, just that I thought I managed to use it from local.conf in the past. DISTRO_FEATURES seems to work better.. Any drawbacks of using DISTRO_FEATURES to dynamically change behavior between builds using the same sstate?08:08
*** w00die <w00die!~w00die@> has quit IRC08:12
*** w00die <w00die!~w00die@> has joined #yocto08:14
mckoanfor example08:17
mckoaneven I'd avoid eSDK though08:19
mcburgermckoan Got the procedure, thank you!08:23
*** zyga <zyga!~zyga@unaffiliated/zyga> has quit IRC08:26
*** Blackbetty <Blackbetty!> has joined #yocto08:27
*** zyga <zyga!~zyga@unaffiliated/zyga> has joined #yocto08:28
*** mcburger <mcburger!> has quit IRC08:28
*** yocti <yocti!> has joined #yocto08:57
*** jobroe <jobroe!> has joined #yocto08:58
*** Spectrejan[m] <Spectrejan[m]!spectrejan@gateway/shell/> has quit IRC09:00
*** samvlewis <samvlewis!~samvlewis@> has quit IRC09:01
*** samvlewis <samvlewis!~samvlewis@> has joined #yocto09:01
*** zeddii <zeddii!> has quit IRC09:04
*** jdrol <jdrol!> has joined #yocto09:06
*** zeddii <zeddii!> has joined #yocto09:08
*** kiwi_29 <kiwi_29!> has joined #yocto09:17
*** flash27 <flash27!> has joined #yocto09:20
*** RobertBerger <RobertBerger!> has joined #yocto09:20
*** kiwi_29 <kiwi_29!> has quit IRC09:22
*** fflash27 <fflash27!> has joined #yocto09:46
*** flash27 <flash27!> has quit IRC09:48
*** fflash27 <fflash27!> has quit IRC09:50
*** flash27 <flash27!> has joined #yocto09:53
*** camus <camus!~Instantbi@> has joined #yocto10:08
*** pkar <pkar!> has joined #yocto10:08
*** kaspter <kaspter!~Instantbi@> has quit IRC10:08
*** camus is now known as kaspter10:08
*** pkar <pkar!> has quit IRC10:11
*** flash27 <flash27!> has left #yocto10:15
*** pkar <pkar!> has joined #yocto10:16
*** pkar <pkar!> has quit IRC10:21
*** camus <camus!~Instantbi@> has joined #yocto10:28
*** kaspter <kaspter!~Instantbi@> has quit IRC10:29
*** camus is now known as kaspter10:29
*** c3st3l <c3st3l!> has joined #yocto10:29
*** Saur|Home <Saur|Home!> has quit IRC10:40
*** c3st3l <c3st3l!> has quit IRC10:48
*** c3st3l <c3st3l!> has joined #yocto10:49
*** c3st3l <c3st3l!> has quit IRC10:50
*** goliath <goliath!> has joined #yocto10:51
*** B0ned1ger <B0ned1ger!> has joined #yocto10:51
*** B0ned1ger2 <B0ned1ger2!> has quit IRC10:55
*** B0ned1ger <B0ned1ger!> has quit IRC10:56
*** kpo_ <kpo_!> has quit IRC11:00
*** kpo_ <kpo_!> has joined #yocto11:00
*** B0ned1ger <B0ned1ger!> has joined #yocto11:10
alephan<zeddii "Andrei: the fix for the configur"> Thanks!11:24
*** bobo <bobo!> has joined #yocto11:30
*** tralla <tralla!> has quit IRC11:36
*** Bunio_FH <Bunio_FH!> has quit IRC11:44
LetoThe2nddoes this ring a bell, anybody?11:47
LetoThe2nd(blocking io error / wakeup fd)11:47
*** manuel1985 <manuel1985!~manuel198@2a02:1748:dd5c:f290:c5b2:fdff:b718:9edf> has joined #yocto11:56
*** Bunio_FH <Bunio_FH!> has joined #yocto12:00
jdrolis there a way to create a recipe skeleton  with SUMMARY do_install() LICENCE etc with a commannd like recipetool ?12:06
*** B0ned1ger2 <B0ned1ger2!> has joined #yocto12:06
*** Johnmacgregor <Johnmacgregor!> has joined #yocto12:07
*** kaspter <kaspter!~Instantbi@> has quit IRC12:08
*** camus <camus!~Instantbi@> has joined #yocto12:08
*** B0ned1ger <B0ned1ger!> has quit IRC12:08
qschulzjdrol: devtool add <url> ?12:10
*** camus is now known as kaspter12:10
jdrolqschulz, thanks .. I don't understand is the odc I read devtool are from eSDK but without eSDK I have it installed12:11
LetoThe2ndjdrol: maybe
LetoThe2ndhas been passed to me, i'm not exactly convinced of it, but it has use cases.12:12
jdrolLetoThe2nd, yes it is nice ... but it is not exists with command lines ?12:16
LetoThe2ndjdrol: obviously not.12:17
JohnmacgregorHi, I"m a member of the ELISA Linux Foundation project and am trying to build an ELISA demo system that is based on an agl platform.  For reasaons that i don't want to discuss, I'm using an OpenSuse Tumbleweed machine with glibc 2.33.  The pseudo build craps out with failed compiles because _STAT_VER has not been defined.  After a bit of12:17
Johnmacgregorinvestigation, I've found out that io/sys/stat.h has eliminated references to _STAT_VER in 2.33 (it was in 2.32).  The pseudo source code is littered with references to _STAT_VER, and according to the overview in the documentation in the overview, this is intentional. Note that OpenSuse Tumbleweed may be a bit obscure, but Ubuntu 21.04 is12:17
Johnmacgregorscheduled to upgrade to glibc 2.33. Questions: a) Is there an bug  tracking system where I can register this and b) any suggestions for work-arounds (I've already thought about using a virtual machine or chroot OS...) thc12:17
LetoThe2ndJohnmacgregor: theres a bugzilla, yes.12:18
Johnmacgregoruh, where12:18
*** paulg <paulg!> has joined #yocto12:19
qschulzJohnmacgregor: bugzilla.yoctoproject.org12:19
LetoThe2ndJohnmacgregor: as i would have to open google now and type "yocto project bugzilla", then pass the result to you, i'm convinced that you are totally competent to do it yourself :)=12:19
qschulzJohnmacgregor: otherwise you could use containers12:19
LetoThe2ndqschulz: hrhr12:19
qschulz is one example12:19
LetoThe2ndyeah, build in container is a standard approach these days.12:19
JohnmacgregorBTW diff 2.32 2.33
dl9pfJohnmacgregor:  container as proposed or a buildtools tarball from yocto can help. the 2.33 changes need to be worked into pseudo and YP (master and also dunfell)12:32
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has quit IRC12:33
*** Blackbetty <Blackbetty!> has quit IRC12:35
*** bobo <bobo!> has quit IRC12:38
Johnmacgregor>  i'm convinced that you are totally competent to do it yourself :)= ... Rumours of my competence have been greatly exaggerated, but I did find that a bug has been issued (and closed) in bugzilla. (14229).  Didn't find any helpful description or work-arounds, however.  OK, I'll try using the container or the buildtools tarball and try to rely12:46
Johnmacgregoron my ELISA / agl colleagues for further assistance.  Thx.12:46
qschulzJohnmacgregor: sometimes the Bugzilla number is in commit log so that might help you figure out what was needed12:49
LetoThe2ndRP ttps://
LetoThe2ndRP/rburton: (i guess this is related to my stuck build)12:52
RPLetoThe2nd: not seen that before...12:54
*** Blackbetty <Blackbetty!> has joined #yocto12:54
LetoThe2ndits docker-in-lxc and i guess its some combination issue.12:54
LetoThe2ndmaybe also JPEW as our containerized build guru :)12:56
SaurRP: Is there any problems with the patch I sent a month ago (pinged a week ago) to the openembedded-core list adding nativesdk-glibc-dbg to the uninative tarball? I have not seen it in master-next, and I have nor received any comments.13:20
*** ENPJ <ENPJ!~ENPJ@2001:a61:3a33:7901:a9f0:885a:b6b3:4a54> has quit IRC13:20
*** JosephAntony <JosephAntony!a5e10863@> has quit IRC13:35
RPSaur: I understand why you're asking for it, I don't really like it and I don't know what to do13:35
*** jobroe <jobroe!> has quit IRC13:37
*** kaspter <kaspter!~Instantbi@> has quit IRC13:37
*** kaspter <kaspter!~Instantbi@> has joined #yocto13:38
qschulzndec: RP: I'm not sure if we want to manually document the bb.utils functions in the docs??? How do we make sure we keep them in sync with the actual code?13:46
ndeci wondered about that..13:47
qschulzndec: RP: can't we just extract the Python documentation for those functions and have everything automatic?13:47
ndecwith sphinx we should be able to move docs closer to the code..13:47
ndecthe problem is that the doc is not in the main repo..13:47
RPqschulz: generally we'd consider those utils to be "API" so documenting them is probably reasonable but the "how" TBD13:48
qschulzRP: oh no, I'm convinced they should be documented. It's just that for me they should absolutely be documented where they are implemented. Which is usually (always?) the case right now13:49
qschulzbut since they are documented there, why not get their documentation from the python docstring directly and use this so we're always up to date13:50
RPqschulz: question of someone making that all work nicely I guess13:55
*** JosephAntony <JosephAntony!a5e10863@> has joined #yocto13:58
*** sakoman <sakoman!> has joined #yocto13:59
*** Spooster <Spooster!> has joined #yocto14:00
SaurRP: Well, it is necessary to be able to use uninative and be able to debug/memcheck native applications. And it is just a few % size increase, so to me it should not be controversial.14:01
*** ENPJ <ENPJ!~ENPJ@2001:a61:3a33:7901:a9f0:885a:b6b3:4a54> has joined #yocto14:07
RPSaur: how many times have I heard "just a few % increase" with that tarball. It used to be about 5MB :(14:10
*** mous16[m] <mous16[m]!mous16matr@gateway/shell/> has joined #yocto14:15
mous16[m]'Morning everybody14:15
SaurRP: Well, I obviously cannot say how many times you have heard that. ;) But what I do know is that it is not possible to use it and still use valgrind on native applications as valgrind requires that some of the glibc symbols are available to even start the application.14:17
mous16[m]I'm bit confused: i'm a happy user of a SDK that uses GCC for crosscompilation. I woud like to have available also Clang (just to have a second opinion on my code), so i added to my sdk nativesdk-clang, but the resulting clang executable produce x86_64 executables. Am I missing the right package?14:22
JPEWLetoThe2nd: I've never seen that before that I can recall... I suspect that means that the thread handling the signal is blocked/starved and can't handle the queue in a timely manner14:23
RPSaur: If I accept the patch, we'll get people moaning about the size, people will complain there is no way to configure it, we'll need to create split binaries and a mechanism to turn on/off debug symbols and so on. I appreciate your problem. I just also know where the path leads14:25
RPSaur: I can't win :(14:25
qschulzRP: ndec: I should have commented on the ML, will do14:30
SaurRP: I honestly have a hard time seeing that a 200 kB increase to a 5 MB tar ball would cause a huge raucous, but I may be naive. Instead the focus should be on possibilities it opens up that were previously blocked.14:33
SaurIt's not as anyone has complained about the suggested patch on the ML.14:34
*** ssajal <ssajal!> has joined #yocto14:41
RPSaur: it would be an interesting experiment to propose some really bad patches and see if they do get review feedback14:44
SaurRP: True, it is easy to ignore patches on the list if they are not directly related to what you do yourself, so maybe the lack of comments cannot be taken as acceptance of a patch. On the other hand, it is all we have.14:47
SaurAnd I did state in the patch mail that the size increases by 4% (200 kB), so it was not like I tried to hide the fact.14:48
RPSaur: I'm not claiming it was hidden14:48
SaurI know.14:48
SaurBut I meant that if anyone cares about the size of the tarball, the facts were out in the open.14:49
RPSaur: Well, I can't really reject it so I'll just have to merge it14:50
SaurRP: Well, I guess the worst that can happen is that someone actually complains about it, and then brings arguments as to why it was a Bad Idea(tm) to do this.14:51
RPSaur: well, there is work this change triggers as we'll need a new uninative release (which doesn't currently have automated testing), and it will end up backported to all the stable branches as we need to keep uninative in sync14:53
RPSaur: so I'm not sure that is the worst14:53
RPSaur: not your problem though, becomes mine and the stable maintainers14:53
SaurRP: Sure, not much I can do to help you there, I'm afraid.14:54
RPSaur: I think I have wider concerns that a growing number of people are just relying on me to get a lot of things right and I'm not sure I'm going to, I'm stretched too thin14:56
JPEWSaur: Is it only glibc-dbg in the SDK because that's the only meaningful library in uninative? (e.g. why wouldn't you want the debug symbols for everything in uninative?)15:03
SaurJPEW: I'm not following you?15:04
JPEWSaur: nativesdk-glibc-dbg seems specific; are the rest of the -dbg packages for things in uninative unnecessary?15:07
SaurJPEW: Well, my goal was to make it possible to run valgrind on native applications, and valgrind requires that some of the debug symbols from glibc exist to even start.15:09
JPEWSaur: Right. I guess I'm wondering if its possible to publish a separate -dbg tarball (like we can do with a rootfs) for uninative that includes all the debug symbols for it15:10
JPEWfair warning: I don't even know if that's possible or practical15:11
JPEWSaur: Then you could get everything, not just glibc symbols15:11
SaurJPEW: Me neither. I just know there is a lot of magic going on behind the uninative support.15:12
*** JosephAntony <JosephAntony!a5e10863@> has quit IRC15:12
RPJPEW: definitely possible, would be a bit of work to pull together15:15
*** Bunio_FH <Bunio_FH!> has quit IRC15:17
*** Yumasi <Yumasi!> has quit IRC15:30
*** AndersD_ <AndersD_!> has quit IRC15:45
*** jdrol <jdrol!> has quit IRC15:47
paulgah, mailing list roulette, how I love thee.   Where does this poky .gitignore update go?
JPEWpaulg: I think15:56
*** ByteLawd <ByteLawd!extor@unaffiliated/extor> has quit IRC15:59
*** ByteLawd <ByteLawd!extor@unaffiliated/extor> has joined #yocto15:59
*** ENPJ <ENPJ!~ENPJ@2001:a61:3a33:7901:a9f0:885a:b6b3:4a54> has quit IRC16:02
*** w00die <w00die!~w00die@> has quit IRC16:03
paulgbitbake does have its own .gitignore as an independent repo outside of poky, so I was leaning towards making the change there, and letting RP do the path munging as part of a pseudo cherry pick...16:04
*** w00die <w00die!~w00die@> has joined #yocto16:05
*** Kyubi <Kyubi!~Kyubi@> has quit IRC16:05
JPEWpaulg: I frequently find it unfortunate that .gitignore doesn't let you include other files16:06
RPpaulg: should go to the bitbake list16:06
JPEWpaulg: Although.... I think bitbake could have it's own .gitignore and it would be respected16:06
*** B0ned1ger2 <B0ned1ger2!> has quit IRC16:10
SaurJPEW: Well, you can have a .gitignore file in any directory in a repository, so the .gitignore from bitbake could just as well have been left there when merging it into the poky repository.16:11
Saur(Which is basically what you said in your last sentence...)16:13
*** Kyubi <Kyubi!~Kyubi@> has joined #yocto16:14
*** sakoman <sakoman!> has quit IRC16:15
paulgbitbake/doc/.gitignore  managed to find its way from bitbake into poky  (69ed72025ad poky / 84ccba0f4a BB)16:15
*** sakoman <sakoman!~steve@> has joined #yocto16:16
paulganyway - sent.
*** orzen <orzen!~orz@> has joined #yocto16:17
*** mckoan <mckoan!~marco@unaffiliated/mckoan> has quit IRC16:18
*** mckoan <mckoan!~marco@unaffiliated/mckoan> has joined #yocto16:19
*** ENPJ <ENPJ!~ENPJ@2001:a61:3a33:7901:a9f0:885a:b6b3:4a54> has joined #yocto16:19
orzenHi, does anyone here use go.bbclass and know if it is up-to-date? I am having troubles with getting it to work.16:21
*** bobo <bobo!> has joined #yocto16:22
*** ByteLawd <ByteLawd!extor@unaffiliated/extor> has quit IRC16:28
*** ByteLawd <ByteLawd!extor@unaffiliated/extor> has joined #yocto16:29
*** LetoThe2nd <LetoThe2nd!uid453638@gateway/web/> has quit IRC16:29
*** Renga <Renga!a5e16832@> has joined #yocto16:31
RengaHi team16:31
Rengahave questions in adding user/group through yocto recipe file16:32
*** Johnmacgregor <Johnmacgregor!> has quit IRC16:33
*** Johnmacgregor <Johnmacgregor!> has joined #yocto16:33
*** rcoote <rcoote!> has quit IRC16:35
*** Renga <Renga!a5e16832@> has left #yocto16:38
*** Renga <Renga!a5e16832@> has joined #yocto16:44
Spoosterre: Running rootless X on a raspberry pi 4. I was able to narrow down the issue, drmSetMaster runs an ioctl that requires root, so either xinit needs root here, or some other mechanism needs to call drmSetMaster on our behalf... and it looks like systemd-logind has a mechanism to be able to intercede in such a manner.16:49
Spoosterbut the logs indicate an issue when a non-root user runs xinit... and the systemd-logind integration isn't healthy16:50
JPEWSpooster: I run wayland, not X, but still rootless... when I was doing it I had to have systemd allocate a TTY for compositor service16:52
JPEWSpooster: Which was broken when not use polkit with systemd, and we had to subsequently patch16:53
JPEWLook at meta-graphics/wayland/weston-init/weston.service16:54
RPpaulg: merged, thanks16:54
*** Renga <Renga!a5e16832@> has quit IRC16:56
*** aleblanc <aleblanc!> has quit IRC17:04
SpoosterWhat I'm hearing, is that I should consider switching to wayland17:04
SpoosterJPEW: Do you run Wayland in x?   DISTRO_FEATURES_append = " wayland x11"17:07
Spoosteror just Wayland proper somehow?17:08
JPEWSpooster: just wayland17:08
JPEWWe run weston in the fullscreen shell, and they our "special sauce" application runs as a fullscreen client17:09
paulgRP,   \o/17:09
JPEWSpooster: Our application can also run in the normal weston desktop for development, but we don't do that in production :)17:09
SpoosterI mean... our app is mostly chromium --kiosk... with some python behind the scenes so that sounds sufficient for what we're after as well17:10
JPEWSpooster: Ya, I'd give it a try. Last I looked, chromium wayland support was spotty, but that was a few years ago. It may be better17:10
JPEWSpooster: Ya we actually run WebKit as a wayland client of our "special sauce" application (our app is both a client of weston, and a compositor for it's own clients.... wayland is awesome!)17:11
SpoosterJust trying to parse "How to do a Wayland instead of an X" in our kas.yml... it's been a fun two weeks moving to Yocto over pi-gen17:12
Spoostereverything is a bit... "nuanced" we'll say17:12
*** dreyna <dreyna!> has joined #yocto17:12
JPEWSpooster: DISTRO_FEATURES += "wayland" IMAGE_INSTALL += "weston-init" is a start17:13
JPEWI think that should "just work" on at least gatesgarth.... but YMMV as always17:14
Spoosterdunfell >~>17:15
JPEWSpooster: It *might* work there (we use dunfell, but I backport stuff regularly)17:16
* Spooster queues Startrek's opening17:16
JPEWSpooster: More data needed.... which Star Trek? TOS? TNG? DS-9? Animated series? Voyager? Lower Decks?17:17
SpoosterWas thinking TOS...17:18
*** bobo <bobo!> has quit IRC17:18
SpoosterI'm unfortunately not much of a trekkie... just know enough to know that I'm in some sort of unexplored final frontier17:18
*** rcoote <rcoote!~rcoote@2a02:908:692:81c0:2ce5:c2e3:4d74:fef4> has joined #yocto17:28
*** ByteLawd <ByteLawd!extor@unaffiliated/extor> has quit IRC17:28
*** ByteLawd <ByteLawd!extor@unaffiliated/extor> has joined #yocto17:29
*** ByteLawd <ByteLawd!extor@unaffiliated/extor> has quit IRC17:31
*** ByteLawd <ByteLawd!extor@unaffiliated/extor> has joined #yocto17:32
Spoosterwe have the poke/meta layer available, which provides recipes-graphics... but bitbake can't seem to find any recipes that provide weston-init17:41
Spoosterope... just flopped names of things... wayland-init doesn't exist... weston-init does... /ignore17:42
*** pharaon2502 <pharaon2502!> has joined #yocto17:43
*** Spooster <Spooster!> has quit IRC17:44
*** Spooster <Spooster!> has joined #yocto17:44
*** rcoote <rcoote!~rcoote@2a02:908:692:81c0:2ce5:c2e3:4d74:fef4> has quit IRC17:47
*** Blackbetty <Blackbetty!> has quit IRC17:55
*** Wouter0100 <Wouter0100!> has quit IRC18:01
*** mckoan is now known as mckoan|away18:02
*** zyga <zyga!~zyga@unaffiliated/zyga> has quit IRC18:05
*** rZZZr <rZZZr!> has quit IRC18:06
*** gsalazar <gsalazar!> has joined #yocto18:07
*** B0ned1ger <B0ned1ger!> has joined #yocto18:12
*** Wouter0100 <Wouter0100!> has joined #yocto18:14
*** pbb <pbb!> has quit IRC18:14
*** pbb <pbb!> has joined #yocto18:15
*** B0ned1ger <B0ned1ger!> has quit IRC18:17
*** King_InuYasha <King_InuYasha!~King_InuY@fedora/ngompa> has joined #yocto18:19
*** King_InuYasha is now known as Conan_Kudo18:20
*** Conan_Kudo is now known as King_InuYasha18:20
*** zyga <zyga!~zyga@unaffiliated/zyga> has joined #yocto18:26
*** Spooster <Spooster!> has quit IRC18:27
*** zyga <zyga!~zyga@unaffiliated/zyga> has quit IRC18:28
*** kaspter <kaspter!~Instantbi@> has quit IRC18:36
*** kaspter <kaspter!~Instantbi@> has joined #yocto18:36
*** Guest87534 is now known as mischief18:46
*** RzR <RzR!> has joined #yocto18:48
*** RzR <RzR!~rzr@unaffiliated/rzr> has joined #yocto18:48
*** kyanres__ <kyanres__!> has quit IRC18:53
*** amitk <amitk!~amit@unaffiliated/amitk> has quit IRC18:56
*** Kyubi <Kyubi!~Kyubi@> has quit IRC18:58
*** zyga <zyga!~zyga@unaffiliated/zyga> has joined #yocto19:21
*** aidanh <aidanh!~aidanh@unaffiliated/aidanh> has quit IRC19:24
*** aidanh <aidanh!~aidanh@unaffiliated/aidanh> has joined #yocto19:26
*** fatalhalt <fatalhalt!~fatalhalt@2601:244:4d01:52df:225:90ff:feda:2428> has joined #yocto19:29
*** opello_ is now known as opello19:36
yatesis meta-darwin ( a layer to create the "toolchain" for the darwin processor family?19:47
yatesit's description is given as an "SDK". is SDK == toolchain (at least in this case)?19:48
fraydarwin is the name of the Open Source components of MacOS X.19:49
JPEWyates: I beleive it's supposed to make an SDK that can run on MacOS X, but I'm pretty sure it's unmaintained and defunct19:50
*** Spooster <Spooster!> has joined #yocto19:52
yateswhat's the difference between the terms "SDK" and "toolchain"?19:52
yatesok, thanks fray/JPEW19:52
fraySoftware Development Kit.  things that run an on OS to produce software to target 'something'19:52
fraytoolchain, binutils, gcc, gdb, and maybe libc19:52
frayAn SDK usually includes a toolchain, but a toolchain may not have everything required to build working osftware19:53
yatesok that is making more sense19:53
*** Bunio_FH <Bunio_FH!> has joined #yocto19:53
yateswould an SDK provide a native toolchain? e.g., in the case of darwin, it's native, right?19:54
frayand SDK can include one or more toolchains.  So a darwin SDK MIGHT include a native toolchain for Darwin, but would likely include a toolchain and other software used to build 'stuff' on a darwin OS host machine..19:55
yatesi guess where i'm going with this is, where do the toolchain definitions belong? in a layer entitled the SDK? or in a BSP layer? or some other way?19:56
frayMost toolchain definitions are in the core, since they are fundamental to the system.  Overriding the core, belongs in a layer..  sometimes BSP, sometimes are specific, sometimes something else..19:56
frayat Xilinx, we have a meta-xilinx (repository) with a meta-microblaze layer that provides the microblaze compiler support19:57
fraybefore meta-microblaze existed, it was part of the layer meta-xilinx-bsps19:57
yatesfray: what do you mean by "the core"?20:03
yateseverything in the meta layer?20:03
*** NunoMartins[m] <NunoMartins[m]!falk0nmatr@gateway/shell/> has joined #yocto20:09
*** falk0n <falk0n!> has joined #yocto20:12
yatesstupid question?20:13
*** NunoMartins[m] is now known as falk0n[m]20:14
yatesis "toolchain" largely equivalent to binutils?20:15
*** feddischson <feddischson!> has joined #yocto20:22
yatesbtw, these aren't willy-nilly. i'm defining such terms in my kb-yocto (yocto knowledge-base) document for my own sanity and future reference.20:24
kergothDo we have a patch info/metadata gathering tool in oe-core yet? Thinking show filename, modified files, plus the patch metadata, subject, sign offs, etc20:34
yatescould someone please define what "the core" means?20:46
kergoththat doesn't mean anything without context20:50
*** feddischson <feddischson!> has quit IRC20:53
*** zyga <zyga!~zyga@unaffiliated/zyga> has quit IRC21:01
*** zyga <zyga!~zyga@unaffiliated/zyga> has joined #yocto21:01
yateskergoth: re: fray's statement at 14:56 (EST)21:07
JPEWyates: I think that's referring to OE core21:10
*** bobo <bobo!> has joined #yocto21:10
*** jkridner|pd <jkridner|pd!~jkridner@pdpc/supporter/active/jkridner> has quit IRC21:18
*** sbach <sbach!~sbachmatr@> has quit IRC21:18
*** sbach <sbach!~sbachmatr@> has joined #yocto21:18
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto21:19
yatesJPEW: ok - thank you.21:19
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC21:24
*** aleblanc <aleblanc!> has joined #yocto21:36
*** gsalazar <gsalazar!> has quit IRC21:39
mouser_Given an upstream Makefile with CC=gcc in it, is there any guidance on the "right way" to override CC? Using EXTRA_OEMAKE += 'CC=${CC}' breaks make because of the arguments.21:52
mouser_I can patch the Makefile, but was hoping it could be solved more simply in the recipe itself.21:53
*** agust <agust!> has quit IRC21:59
JPEWmouser_: What arguments?21:59
kergothmouser_: just quote it. EXTRA_OEMAKE += 'CC="${CC}"' for example22:04
*** paulg <paulg!> has quit IRC22:06
mouser_kergoth: Thanks, that solved it.22:15
mouser_JPEW: In my case, the extra arguments (beyond the compiler) were: -m64 -march=core2 -mtune=core2 -msse3 -mfpmath=sse --sysroot=/redacted/yocto/tmp-glibc/work/core2-64-redacted-linux/redacted-recipe/1.1.1-r0/recipe-sysroot22:16
mouser_The disconcerting thing about this is that doing a "CC=gcc" in a Makefile does not (appear to) trip any of the insane.bbclass validators.22:17
mouser_So you end up using the host's /usr/include, etc instead of the build sysroot.22:19
*** aleblanc <aleblanc!> has quit IRC22:37
fraythe compiler you used doesn't have include poisoning22:37
frayohh sorry read that wrong.. CC=gcc -- ya not a lot that can be done if you are targeting same as the host22:37
fraythis is part of the reason why any time I build stuff, I always target an architecture tht doesn't match my builder for verification of the packaging22:38
mouser_True. If I was targeting som eother architecture, it would have broken earlier.22:38
mouser_I feel like CC=gcc may be an anti-pattern for Makefiles, but I am sure there are good reasons why I am wrong.22:39
fraymost of the time we end up with Makefiles that have CC = gcc, but the makfile is called with make CC=mygcc22:40
frayso you can't just search the Makefiles, as they can be (and usually are) overridden on the command line22:40
mouser_Fair. Overriding is easy. It was not obvious to me when I was packaging something upstream. I know better now of course...22:40
mouser_Is it worth a new type of insane.bbclass check of the compiler if BUILD_CC is not being used? Or does that get us into a tarpit?22:41
fraylikely into a tarpit.  There are resaons why build_cc isn't used occasionally.. i..e building a smaller host helper app22:42
fraysearching logs or output and warning is certainly an option -- but I'd suggest the warning would be off by default or if on, needs an easy way to disavble22:42
*** leon-anavi <leon-anavi!~Leon@> has quit IRC22:42
mouser_I am bumping us up from thud to gatesgarth (or hardknott depending on a number of other factors) here in a few weeks, so I may drop that idea into the backlog and play around with it. If it works, I can see about submitting a patch.22:45
fraysounds good..22:46
*** beneth <beneth!> has left #yocto23:04
*** beneth <beneth!> has joined #yocto23:08
jonesv[m]I am patching the dts used by u-boot, but it has no effect, at the point where I suspect u-boot may not be using it after all. Would somebody have insights on how I could figure that out? I tried a clean build (removed build/tmp and cache-sstate and rebuilt the image) and it did not have any effect23:08
*** manuel1985 <manuel1985!~manuel198@2a02:1748:dd5c:f290:c5b2:fdff:b718:9edf> has quit IRC23:09
yatesis there a manufacturer database for yocto? i need to check if my layer name is in-use: meta-apex-semi-usa23:22
*** ENPJ <ENPJ!~ENPJ@2001:a61:3a33:7901:a9f0:885a:b6b3:4a54> has quit IRC23:26
*** paulg <paulg!> has joined #yocto23:29
*** JaBen <JaBen!~Thunderbi@2a02:8109:86c0:1c58:bd52:f0ef:80f0:e69e> has joined #yocto23:34
*** kaspter <kaspter!~Instantbi@> has quit IRC23:55
*** kaspter <kaspter!~Instantbi@> has joined #yocto23:56

Generated by 2.17.2 by Marius Gedminas - find it at!