Thursday, 2021-04-15

*** Ad0 <Ad0!~Ad0@> has quit IRC00:41
*** Ad0 <Ad0!~Ad0@> has joined #yocto00:48
khemRP: kergoth  The gcc11 reproducibility issue is due to use of git SHA1 id in S, It would not happen for proper releases, however I think the check to replace debug-maps can be fixed00:59
khemand made mode robust, I Will send a patch01:00
*** dplascen <dplascen!~Daniela_P@2806:103e:18:28ac:6910:47ab:74b7:f1df> has joined #yocto01:04
*** kpo_ <kpo_!> has quit IRC01:39
*** kpo_ <kpo_!> has joined #yocto01:40
*** yizhao <yizhao!~zhaoyi@> has joined #yocto01:40
*** kaspter <kaspter!~Instantbi@> has joined #yocto01:53
*** kaspter <kaspter!~Instantbi@> has joined #yocto01:54
*** linums <linums!> has quit IRC01:55
*** otavio_ <otavio_!> has quit IRC01:56
*** chrysh <chrysh!> has quit IRC01:56
*** chrysh <chrysh!> has joined #yocto01:56
*** malinus <malinus!~malinus@unaffiliated/malinus> has quit IRC01:56
*** iokill <iokill!> has quit IRC01:57
*** linums <linums!> has joined #yocto01:57
*** otavio_ <otavio_!> has joined #yocto01:58
*** iokill <iokill!> has joined #yocto01:59
*** nvmd <nvmd!~nvmd@> has quit IRC02:03
*** malinus <malinus!~malinus@> has joined #yocto02:03
*** malinus is now known as Guest1262002:04
kergothkhem: ah, interesting02:37
*** dplascen <dplascen!~Daniela_P@2806:103e:18:28ac:6910:47ab:74b7:f1df> has left #yocto02:38
*** itseris <itseris!> has quit IRC02:42
*** itseris <itseris!> has joined #yocto02:43
*** sakoman <sakoman!~steve@> has quit IRC02:52
*** vquicksilver <vquicksilver!~nobody@gentoo/contributor/vquicksilver> has quit IRC02:53
*** ahadi <ahadi!> has quit IRC02:59
*** ahadi <ahadi!> has joined #yocto03:05
*** georgem_home <georgem_home!uid210681@gateway/web/> has quit IRC03:28
*** kaspter <kaspter!~Instantbi@> has quit IRC03:38
*** kaspter <kaspter!~Instantbi@> has joined #yocto03:38
*** vquicksilver <vquicksilver!~nobody@gentoo/contributor/vquicksilver> has joined #yocto03:39
*** Wouter0100 <Wouter0100!> has quit IRC03:47
*** yizhao <yizhao!~zhaoyi@> has quit IRC03:48
*** Wouter0100 <Wouter0100!> has joined #yocto03:50
*** yizhao <yizhao!~zhaoyi@> has joined #yocto03:52
*** yizhao <yizhao!~zhaoyi@> has quit IRC04:07
*** yizhao <yizhao!~zhaoyi@> has joined #yocto04:07
*** yizhao <yizhao!~zhaoyi@> has quit IRC04:34
*** yizhao <yizhao!~zhaoyi@> has joined #yocto04:37
*** yizhao <yizhao!~zhaoyi@> has quit IRC04:57
*** yizhao <yizhao!~zhaoyi@> has joined #yocto04:59
*** kiwi_29 <kiwi_29!> has joined #yocto05:02
*** yizhao <yizhao!~zhaoyi@> has quit IRC05:05
*** yizhao <yizhao!~zhaoyi@> has joined #yocto05:07
*** kiwi_29 <kiwi_29!> has quit IRC05:07
*** kaspter <kaspter!~Instantbi@> has quit IRC05:14
*** kaspter <kaspter!~Instantbi@> has joined #yocto05:16
*** vineela <vineela!vtummala@nat/intel/x-gucvgqkjewmnlwcj> has quit IRC05:19
*** creich <creich!> has joined #yocto05:25
*** jobroe <jobroe!> has joined #yocto05:27
*** yizhao <yizhao!~zhaoyi@> has quit IRC05:27
*** AndersD <AndersD!> has joined #yocto05:29
*** yizhao <yizhao!~zhaoyi@> has joined #yocto05:29
*** AndersD_ <AndersD_!> has joined #yocto05:32
*** linums <linums!> has quit IRC05:34
*** AndersD <AndersD!> has quit IRC05:35
*** linums <linums!> has joined #yocto05:35
*** Guest12620 <Guest12620!~malinus@> has quit IRC05:37
*** Guest12620 <Guest12620!~malinus@unaffiliated/malinus> has joined #yocto05:37
*** Guest12620 is now known as malinus05:38
*** LetoThe2nd <LetoThe2nd!uid453638@gateway/web/> has joined #yocto05:39
*** agust <agust!> has joined #yocto05:58
*** sbach <sbach!~sbachmatr@> has quit IRC06:04
LetoThe2ndyo dudX06:14
*** cdgarren <cdgarren!> has quit IRC06:19
*** oberstet <oberstet!~oberstet@> has joined #yocto06:38
*** rcoote <rcoote!~rcoote@2a02:908:692:81c0:5431:696e:2c99:3f4a> has joined #yocto06:39
*** frsc <frsc!> has joined #yocto06:45
*** fl0v0 <fl0v0!> has joined #yocto06:55
*** pankaj347 <pankaj347!9d2daadf@> has joined #yocto06:56
*** Jonek <Jonek!> has joined #yocto07:06
*** tnovotny <tnovotny!> has joined #yocto07:11
*** plntyk <plntyk!> has joined #yocto07:17
*** dreyna <dreyna!> has quit IRC07:22
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto07:22
*** prabhakarlad <prabhakarlad!> has joined #yocto07:24
*** zyga <zyga!~zyga@unaffiliated/zyga> has joined #yocto07:27
*** kpo_ <kpo_!> has quit IRC07:31
creichhi there, shouldn't it be sufficient to use INSTALL_IMAGE_remove += "package-name" to test dropping out one package of an image build?07:44
creichif i do that, i end up getting errors from the image build that tries to copy config files regarding that 'removed' package07:44
creichanything else needed to remove a package from an image?07:45
creichor do i have to run a complete clean build07:45
*** dev1990 <dev1990!> has joined #yocto07:49
*** sahilgg <sahilgg!b6ed879b@> has joined #yocto07:50
sahilgghow to get into uboot menu? i want to use tftp for booting image08:01
LetoThe2ndsahilgg: usually by pressing some key on the serial console. if not, then read the documentation of the board.08:03
qschulzcreich: first, it'd be IMAGE_INSTALL_remove and not INSTALL_IMAGE. Second, this applies only to "top-level" recipes, the ones that are **explicitly** included in the image via IMAGE_INSTALL variable08:12
qschulz"top-level" package* sorry08:13
creichqschulz: yeah, sry for the typo.. i did IMAGE_INSTALL_remove in my local.conf. and yes, i removed on that explicitly got added using IMAGE_INSTALL08:15
creichbut i theory that should work, right? if not, i'd expect something else is wrong with the configuration08:16
qschulzif it is not a "top-level" package, you need to modify the recipes that are adding said package as a dependency, it can be either in RDEPENDS, DEPENDS or RRECOMMENDS. One easy way is to add said package to PACKAGE_EXCLUDE in your loca.lconf and see what fails to "build"08:16
qschulzif you don't want any package of a given recipe, the easiest way is just to remove the recipe and see what fails to build08:16
*** ericbutters <ericbutters!5b3d7226@gateway/web/cgi-irc/> has joined #yocto08:16
qschulzif it is a "top-level" package but is also in RDEPENDS/RRECOMMENDS/DEPENDS of another recipe/package then you need to modify those too08:17
qschulzthose = the recipes that have RDEPENDS/RRECOMMENDS/DEPENDS on the package/recipe you don't want08:17
creichmakes sense. I'll check for dependencies08:17
creichthx for the hint :)08:18
*** leon-anavi <leon-anavi!~Leon@> has quit IRC08:18
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto08:18
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto08:18
*** leon-anavi <leon-anavi!~Leon@> has quit IRC08:21
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto08:21
*** goliath <goliath!> has joined #yocto08:27
*** falk0n[m] <falk0n[m]!falk0nmatr@gateway/shell/> has quit IRC09:00
*** phoenix <phoenix!d53dd19e@> has joined #yocto09:04
*** phoenix is now known as Guest982009:04
Guest9820Can you attach a machine specific task to ROOTFS_POSTPROCESS_COMMAND? ROOTFS_POSTPROCESS_COMMAND_mymachine overwrites the default variable.09:07
ScorpiHi, when the state cache is used, I only get log files for the setscene task. How can I see the log of the last build? I think it would be nice to have the build log as part of the sstate-cache, and a "cached_log" directory as part of the build when the cache is used09:07
LetoThe2ndGuest9820: ROOTFS_POSTPROCESS_COMMAND_append_mymachine ? (qschulz to the rescue)09:09
mcfriskhi, how to default shared library providers? looks like some odd package stole some python shared libraries in my build and QA check "QA Issue: python3-rpm rdepends on bla but isn't a build DEPENDS" fails. Which log or database would have the shared lib providers?09:09
qschulzGuest9820:  LetoThe2nd: can confirm, that is the way to do it, don't forget the leading space09:11
qschulzScorpi: I'm not sure you can, because the tasks are obviously not re-run so Yocto would need to store logs in the sstate-cache and it's already pretty big :p09:12
qschulzmcfrisk: oe-pkgdata-util find-path '**' will return the package providing this lib if it's been built, otherwise happy hunting :)09:12
Scorpiqschulz: I think space wouldn be a big issue as logfiles usually compress well09:12
Scorpiqschulz: speaking of which, is there a tool to manage the state cache, e.g. find old and unused cache items?09:13
mcfriskqschulz: found it, by looking at the offending bla package, it shipped a private which now suddenly overrides the real shared lib from popt. it's in a funny non-default path but bitbake doesn't seem to care since it's not marked is private lib09:16
qschulzScorpi: bitbake-dumpsig and bitbake-diffsigs09:18
qschulzScorpi: ah sorry, didn't read til the end. Mmmm I think there might be a script somewhere in poky but I usually use `find -atime +30 -delete`09:19
qschulzat least a few of us here do it09:19
Scorpiokay, thanks09:19
qschulz(some even have this in a cronjob)09:19
derRichardi have a bbappend for linux-firmware where i do PACKAGES =+ " ${PN}-foo" with FILES_${PN}-foo, but all of my new firmware files are part of linux-firmware and no linux-firmware-foo package is created. is the linux-firmware recipe somehow special?09:24
derRichardit looks like as if PACKAGES is ignored09:25
derRichardbut when i run bitbake -e linux-firmware > vars.txt. i see linux-firmware-foo in the PACKAGES variable09:26
qschulzderRichard: the order is wrong :)09:27
qschulzah no, my bad09:27
mcfriskhmm, why does shared lib RDEPENDS magic look into all binaries offered by recipes, not just the ones in the default shared library paths?
Guest9820@qschulz @LetoThe2nd Thanks!09:28
qschulzderRichard: what's inside the PACKAGES variable?09:28
derRichardqschulz: one moment, i can share the bb file09:29
derRichardjust need to censor the vendor name^^09:29
qschulzderRichard: just go for cat vars.txt | grep ^PACKAGES=09:30
derRichardbeside of tons of other linux-firmware packages, i see in PACKAGES also linux-firmware-xxx09:32
*** sahilgg76 <sahilgg76!b6ed879b@> has joined #yocto09:32
derRichardall looks good to me except, that FILES_${PN}-xxx seems to have no effect and fw.bin goes into linux-firmware instead of linux-firmware-xxx09:33
*** Guest9820 <Guest9820!d53dd19e@> has quit IRC09:33
qschulzderRichard: you did NOT do PACKAGES =+ " ${PN}-foo" but PACKAGES_append09:33
qschulzwhich is completely different09:33
derRichardyes, i just changed it09:33
qschulzso indeed, the order is wrong09:33
derRichardwhich order?09:34
qschulzPACKAGES =+ prepends directly, PACKAGES_append appends later after everything is done (but before _remove is evaluated)09:34
qschulzderRichard: in PACKAGES09:34
qschulzfiles are put on the first package whose FILES_${PN} matches their path09:35
qschulzthe "first package" being determined from the PACKAGES variable, from leftmost to rightmost09:35
derRichardhm, i had that already. when printing the PACKAGES variable i see linux-firmware-xxx being first09:36
derRichardlet me try again without hackery09:36
qschulzyou are **appending** to PACKAGES, therefore linux-firmware package (which probably has a glob pattern to match everything that hasn't been added in previous packages) will take your file and there'll be nothing left to match in your linux-firmware-xxx09:36
derRichardyes, i understand that _append is wrong09:37
derRichardbut with PACKAGES =+ i see the same problem09:37
derRichardi'm rebuilding now woth =+ just to be sure09:37
derRichardmaybe some other .bbappend messes with linux-firmware's PACKAGES variable? hmmm09:38
*** snikulov <snikulov!~snikulov@> has joined #yocto09:39
derRichardjust printed the PACKAGES variable, linux-firmware-xxx is first and linux-firmware is last. sounds about right to me09:40
*** roussinm1 <roussinm1!> has joined #yocto09:42
derRichardin vars.txt i see also: FILES_linux-firmware-xxx="        /lib/firmware/xxx/fw.bin "09:42
derRichardmakes sense too09:42
*** kpo <kpo!> has quit IRC09:45
qschulzderRichard: at that point, you'll have to dig into the original linux-firmware recipe and what's done exactly, maybe there's some automate process of some sort, I don't know09:45
*** kpo <kpo!> has joined #yocto09:45
*** roussinm <roussinm!> has quit IRC09:46
qschulzalso... you don't need to make a bbappend for this firmware, especially since you add your own firmware by hand09:46
derRichardqschulz: thanks, i can do that myself. just wanted to make sure i'm on the right track09:46
qschulzjust create your own recipe from scratch just for this firmware09:46
qschulzderRichard: BTW, most of the time, instead of PACKAGES =+, PACKAGE_BEFORE_PN += works fine and is a bit more easy to read and less error prone (IMO)09:46
derRichardso, this is the wrong approach?
derRichardnow you can guess on what bsp i am ;)09:47
qschulzderRichard: yes, this seems like a wrong approach to me09:48
* derRichard takes a note09:48
sahilggwhile using pip install xxx i am getting ssl error so i added trusted list it got install. but while using python request too i am getting requests.exceptions.SSLError .. i added verify=False to do its work. any way to avoid these errors from base?09:49
qschulzderRichard: smh09:49
qschulzderRichard: why don't you take directly?09:50
*** linums <linums!> has quit IRC09:54
derRichardqschulz: i showed you the first file google found09:54
*** linums <linums!> has joined #yocto09:54
derRichardi take my copy of meta-imx form the internal git...09:54
*** pankaj347 <pankaj347!9d2daadf@> has quit IRC09:57
qschulzderRichard: aaaah, then just create your own recipe then :)09:59
derRichardbut can i still use MACHINE_FIRMWARE then in my machine?10:00
*** geheimnis` <geheimnis`!~geheimnis@> has quit IRC10:03
qschulzderRichard: can you point me to where this is defined/used, I don't think it is in vanilla poky/oe-core?10:03
derRichardjesus chist, i hate vendor stuff so much...10:04
derRichardlet me see after lunch :-)10:04
derRichardconf/machine/include/ += "${MACHINE_FIRMWARE}"10:07
derRichardin meta-freescale10:07
derRichardis not that bad10:07
derRichardnow i realize also that any recipe can do it, i thought MACHINE_FIRMWARE is special. m(10:08
derRichardqschulz: thanks a lot for pushing me into the right direction!10:08
*** linums <linums!> has quit IRC10:09
*** snikulov <snikulov!~snikulov@> has quit IRC10:10
*** geheimnis` <geheimnis`!~geheimnis@> has joined #yocto10:10
*** linums <linums!> has joined #yocto10:10
qschulzderRichard: my pleasure, happy hacking :)10:13
*** dreyna <dreyna!~dreyna@2601:646:4201:e280:d901:f7e5:fabb:39ac> has joined #yocto10:19
*** dreyna <dreyna!~dreyna@2601:646:4201:e280:d901:f7e5:fabb:39ac> has quit IRC10:23
*** vmeson <vmeson!> has quit IRC10:44
*** vmeson <vmeson!> has joined #yocto10:45
*** sahilgg <sahilgg!b6ed879b@> has quit IRC10:49
*** sahilgg76 <sahilgg76!b6ed879b@> has quit IRC10:51
*** Jonek <Jonek!> has quit IRC10:52
*** SinthuRaja <SinthuRaja!31cfcfec@> has joined #yocto10:53
derRichardqschulz: i gave the bbappend appraoch another try because i wanted to see why i didn't work. after a bitbake -c cleanall linux-firmware all worked like charm o_O10:56
qschulzderRichard: that is... concerning :)11:03
*** la_croix <la_croix!> has joined #yocto11:04
derRichardqschulz: well, isn't the first time that cleanall did wonders when hitting yocto issues11:05
rburtondon't use cleanall11:09
rburtonit takes forever as it has to purge sstate too11:10
rburton-Cunpack would most likely have forced a rebuild11:10
*** fl0v0 <fl0v0!> has quit IRC11:14
*** fl0v0 <fl0v0!> has joined #yocto11:14
*** linums <linums!> has quit IRC11:33
*** linums <linums!> has joined #yocto11:33
*** vygu2 <vygu2!9eff70c2@gateway/web/cgi-irc/> has joined #yocto11:34
vygu2Hello, I would like to know how to bbappend the do_install_append_class-nativesdk() in the bison recipe with a bbappend file? I would like to add PATH variable in the create_wrapper11:37
*** jobroe <jobroe!> has quit IRC12:03
*** jobroe <jobroe!> has joined #yocto12:04
qschulzvygu2: do_install_append_class-nativesdk_append() ?12:14
qschulzwell not even12:14
qschulzdo_install_append_class-nativesdk would work fine too if I'm not mistaken12:14
*** Jonek <Jonek!> has joined #yocto12:17
vygu2I would like to add PATH=\$PATH:${bindir} to create_wrapper to find m4 files12:21
*** Jonek <Jonek!> has quit IRC12:22
*** Jonek <Jonek!> has joined #yocto12:32
*** prabhakarlad <prabhakarlad!> has quit IRC12:32
*** manuel1985 <manuel1985!~manuel198@2a02:1748:dd5c:f290:d1f0:3d22:af09:7ac5> has joined #yocto12:42
*** cdgarren <cdgarren!> has joined #yocto12:54
*** eFfeM1 <eFfeM1!b9b86d22@> has joined #yocto12:59
eFfeM1Hi, I was wondering if I can nest bitbake variables, e.g. something like:13:06
eFfeM1${PN}_REV ?= "${AUTOREV}"13:06
eFfeM1and then when checking out I would use rev=${${PN}_REV}13:06
eFfeM1Idea is to allow per package redefinition of revision13:06
*** vygu2 <vygu2!9eff70c2@gateway/web/cgi-irc/> has quit IRC13:06
qschulzeFfeM1: that means you want to modify ${PN}_REV somewhere right?13:18
qschulzso that it is not the default AUTOREV13:18
eFfeM1qschulz what I want do do is AUTOREV, but I want to have the possibility to override the hash for a release build;13:19
eFfeM1so while developing I'd like to use AUTOREV and while making the release I want to specify the hash so later on I can reproduce the release build13:20
*** vineela <vineela!~vtummala@> has joined #yocto13:23
*** Sona <Sona!> has joined #yocto13:27
*** RobertBerger <RobertBerger!> has quit IRC13:30
*** RobertBerger <RobertBerger!> has joined #yocto13:32
*** zyga-mbp <zyga-mbp!~zyga@unaffiliated/zyga> has joined #yocto13:33
*** zyga <zyga!~zyga@unaffiliated/zyga> has quit IRC13:34
*** zyga <zyga!~zyga@unaffiliated/zyga> has joined #yocto13:37
*** zyga-mbp <zyga-mbp!~zyga@unaffiliated/zyga> has quit IRC13:39
eFfeM1ok, found out the hard way that it has to be13:41
eFfeM1SRCREV = "${AUTOREV}"13:41
eFfeM1I cannot even call it SRC_REV and append a rev=${SRC_REV} to my git URI13:41
qschulzeFfeM1: you also need PV to use SRCPV IIRC, the docs explain that anyway13:42
eFfeM1yeah I have added this to my recipe13:43
eFfeM1PV = "1.0+git${SRCPV}"13:43
*** prabhakarlad <prabhakarlad!> has joined #yocto13:43
eFfeM1and with SRCREV that works but with SRC_REV and rev=${SRC_REV} it does not work13:43
qschulzeFfeM1: just have a conf file somewhere where you define SRCREV_pn-recipea = "${AUTOREV}" PV_pn-recipea = "1.0+git${SRCPV}"13:44
qschulz**include** (and NOT require) this file13:44
qschulzthen for your releases, delete the file13:44
qschulzand voila13:44
qschulzand you define all your recipe's SRCREV and PV in there13:46
qschulz(yes, you need pn- in front, it is not a typo)13:46
eFfeM1qschulz, ah ok, do you have two conf files (a different one for release with hashes in it) ?13:46
qschulzeFfeM1: no, I suggest you update the recipe so that it points to the correct revision13:47
qschulzeFfeM1: and we don't use AUTOREV at all, we use externalsrc for development and/or devtool13:47
eFfeM1qschulz understood the rev part, I assume you do use SRCREV ?= in the recipe then13:48
qschulzeFfeM1: that's exactly what I was thinking about13:48
*** Jonek <Jonek!> has quit IRC13:48
qschulzyou probably need SRCREV ?= indeed13:48
eFfeM1I'm unaware of externalsrc and have never used devtool13:48
qschulzThere has been at least one talk about CI/CD with Yocto at a Yocto project Summit13:49
qschulzso you might want to check it out :)13:50
eFfeM1qschulz will do, I've been away from yocto/oe for several years, so I'm not really up to speed with the latest things13:51
*** dmoseley <dmoseley!~dmoseley@> has quit IRC13:52
*** thekappe <thekappe!c65a42b1@> has joined #yocto13:53
thekappehello guys ! I'm using a distro with systemd13:54
*** RobertBerger <RobertBerger!> has quit IRC13:54
*** SinthuRaja <SinthuRaja!31cfcfec@> has quit IRC13:56
thekappeI want to put some configuration file /opt/lib/systemd/network13:56
thekappeinstead of /lib/systemd/network13:56
thekappei've tried putting symbolink links but it doesn't work.. any suggestion ?13:56
chrysh11:47 < derRichard> now you can guess on what bsp i am ;)13:57
chrysh11:48 < qschulz> derRichard: yes, this seems like a wrong approach to me13:57
chrysh11:48  * derRichard takes a note13:57
*** vineela <vineela!~vtummala@> has quit IRC13:57
derRichardchrysh: hm?13:58
LetoThe2ndhm, hm13:59
*** dmoseley <dmoseley!~dmoseley@> has joined #yocto14:00
*** sakoman <sakoman!~steve@> has joined #yocto14:01
*** RobertBerger <RobertBerger!> has joined #yocto14:01
LetoThe2ndoh, and by the way:
chryshderRichard: oops, layer 8 error.14:03
chryshbut also, some imx* board I guess14:03
derRichardyeah, i work a lot for imx6 and 8 systems14:04
LetoThe2ndmany do that these days.14:05
chryshwhy not 7? xD14:05
* LetoThe2nd curses RP for making him read up on Honister Pass / Wikipedia now *during* worky hours.14:06
RobertBergerHey imx6 people ;)14:07
RPLetoThe2nd: heh. Keeps things interesting :)14:07
chryshNobody on imx7? what a pitty14:08
RobertBergerDid you try tiptop on a recent kernel with imx6 - arm32?14:08
qschulzchrysh: imx7 was much less popular than imx6 and 814:08
qschulzchrysh: we do have a product based on imx7d though, any specific question?14:08
LetoThe2ndRP: i keep on learning so many completely useless things. now i know where in the uk the most rain fell, and that it was on my birthday 6yrs ago. now what use can i put that knowledge to?14:09
qschulzLetoThe2nd: you were the sunshine of that day but as all things need to be balanced, it poured rain in the UK14:10
*** georgem_home <georgem_home!uid210681@gateway/web/> has joined #yocto14:10
chryshqschulz: no, I am just making jokes because we had a lot of trouble with imx7 in my previous company14:10
LetoThe2ndqschulz: that must be the most hilarous and cheesy compliment i've ever received over IRC. great job!14:11
* qschulz blushes14:11
LetoThe2ndqschulz: hi5 - lo5 - fistbump14:12
yatesis there a better description of the tmp/work directory structure than this?
RPyates: doesn't the ref manual go into details?14:12
qschulzchrysh: we don't use upstream kernel though, very outdated NXP kernel. But outside of a very nasty bug in the code handling suspend to RAM, I think it was mostly fine? Though to be fair, I didn't work a lot on that product14:13
sgw1Morning Folks14:13
sgw1I am looking for some help with cmake, which in the past I avoided!  Don't judge the fact that install is trying to do some compilation, but I think that's part of the problem.14:13
sgw1Ceph tries to build some python binding C code during the install phase and it's not finding the core libraries and crt related objects.14:13
sgw1It seems to be searching in the recipe-sysroot-native area instead of the recipe-sysroot directory, the top level toolchain.cmake does have the correct sysroot pointing to recipe-sysroot14:13
yatesRP: i'll take a look14:13
LetoThe2ndyates: i would probably say that this document is even more misleading that helping... you know, "blinky"14:13
RPyates: blinky is very very old now!14:14
qschulzSome people have nostalgy, what can I say14:14
RPI liked the pacman era, that was pre yocto14:14
yatesi liked Missile Command, myself..14:16
yates(yes folks, I really did play the original MC game at the arcades...)14:16
*** RobertBerger <RobertBerger!> has quit IRC14:17
yateslim_{<curdate> - <birthdate>\approach\infty} = old guy14:18
*** marc1 <marc1!> has joined #yocto14:18
*** eFfeM1 <eFfeM1!b9b86d22@> has quit IRC14:20
*** kaspter <kaspter!~Instantbi@> has quit IRC14:26
vdlto ship a systemd foo.mount unit and enable it by default, should I bbappend systemd-conf or should I write a new package?14:26
*** kaspter <kaspter!~Instantbi@> has joined #yocto14:27
*** Spooster <Spooster!> has joined #yocto14:27
qschulzvdl: new package recipe14:28
*** escalion <escalion!> has joined #yocto14:29
*** Wouter0100 <Wouter0100!> has quit IRC14:30
*** Wouter0100 <Wouter0100!> has joined #yocto14:31
escalionHey all. I was wondering if anyone could point me in the right direction - I am adding psplash to my IMAGE_INSTALL_append but psplash-start complains that /usr/bin/psplash doesn't exist. Neither does psplash-default but these are in fact compiled in the tmp directory. Using core-image-minimal on dunfell14:31
*** prabhakarlad <prabhakarlad!> has quit IRC14:31
*** RobertBerger <RobertBerger!> has joined #yocto14:33
*** prabhakarlad <prabhakarlad!> has joined #yocto14:36
vdlqschulz: thanks14:38
*** WillMiles <WillMiles!~Will@> has joined #yocto14:39
qschulzescalion: oe-pkgdata-util find-path '/usr/bin/psplash'14:42
qschulzthen add the package that provides this binary to your image via IMAGE_INSTALL14:42
qschulzif there's none, happy hunting :)14:42
* LetoThe2nd so totally misreads that nickname as"escalation" each and every time.14:42
yatesLetoThe2nd: sign of old age14:43
yatesdid you play Missile Command too?14:43
*** jobroe <jobroe!> has quit IRC14:44
*** leon-anavi <leon-anavi!~Leon@> has quit IRC14:47
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto14:47
*** WillMiles <WillMiles!~Will@> has quit IRC14:47
escalionqschulz: awesome, thanks for the pointer. I'll try it as soon as chromium has finished rebuilding!14:49
*** AndersD_ <AndersD_!> has quit IRC14:49
escalionLetoThe2nd: In voice enabled games plenty make the same mistake!14:51
qschulzmmm now that think about it, psplash-start should explicit the runtime dependency (RDEPENDS_${PN}-start I assume) on the package which provides /usr/bin/psplash14:52
qschulzescalion: ^14:52
*** kaspter <kaspter!~Instantbi@> has quit IRC14:53
escalionqschulz, psplash-start is a service file installed by psplash_git. The strange thing is that there is a line that clearly deletes /usr/bin/psplash "rm -f ${D}${bindir}/psplash" this is in in poky/meta/recipes-core14:54
*** thekappe <thekappe!c65a42b1@> has quit IRC14:57
*** mihai <mihai!~mihai@unaffiliated/mihai> has joined #yocto14:57
*** frsc <frsc!> has quit IRC14:57
*** thekappe <thekappe!c65a42b1@> has joined #yocto15:04
qschulzescalion: binaries are created per SPLASH_IMAGES and their package names are listed in SPLASH_INSTALL if I am not mistaken15:04
vdlqschulz: these .mount units are the systemd equivalent of what wic could do for you (editing the fstab with boot and data partitions). Would you consider these units a recipes-core package or preferably a recipes-bsp?15:06
qschulzvdl: potato potato :)15:07
qschulzhonestly, the name of the directory does not matter much ;)15:07
vdlqschulz: I know, it's just that it gives me a better insight on how to organize the code, I'm not sure it these basic mount points are part of the bsp or part of an image15:10
*** frsc <frsc!> has joined #yocto15:10
* vdl creates an recipes-qschulz directory15:10
ecdheI have a 10 year old SOM based on the TI-AM33xx... they still have an old ubuntu 10.04 vm with a toolchain that builds linux 2.6!!!  I thought about converting it to yocto15:12
ecdhethat is, until I saw how old the kernel is15:12
vdlecdhe: I hope you're using a container at least to build everything15:13
qschulzecdhe: am33xx have excellent upstream support15:13
ecdheI have the kernel config they recommended, but I'm not sure how much of that stuff would still be applicable15:13
qschulz(kernel and u-boot for sure)15:13
qschulzecdhe: assume none ;)15:13
qschulzyou'll need to create a device tree for your SoM+carrier board though15:14
vdlqschulz: I switched to barebox for am335x, works like a charm15:14
qschulzbut once done, upstream kernel + upstream yocto + upstream bootloader15:14
qschulzthe dream15:14
ecdheWould it be better to jump from 2.6 straight to 5.10, or should I do incremental upgrades?15:14
qschulzvdl: that works too, I don't use that often, U-Boot has cannibalized the industry market15:14
qschulzecdhe: straight, the jumps anyway are going to be painful if there's some hacks or very specific features added by the vendor15:15
vdlecdhe: I'd keep a build system clean with both buildable at any time, the 2.6 kernel and a vanilla upstream kernel, try to boot the upstream kernel, fixup everything until it does what the 2.6 did15:16
vdlqschulz: not really, U-boot just became the reference bootloader mainly for arm, but it's awful. Thing is there was nothing better until barebox slowly started adding proper support for more and more platforms.15:17
vdlswitching to barebox is honestly one of the very first steps I consider when working on a board. I can't stand u-boot scripting and their code..15:18
qschulzvdl: the point is, the market share of barebox cannot be compared to U-Boot's15:19
qschulzbut one of my former colleague was an avid supporter of barebox :)15:19
RobertBergervdl, qschulz: It's just a boot loader. That's like vim vs. emacs ;)15:19
qschulzRobertBerger: now imagine the immense majority of people are using emacs. And a vendor provides vim only, would they be happy :) ?15:20
RobertBerger@qschulz: I know a couple of such vendors ;)15:21
qschulzRobertBerger: the british "a couple" or the american :p ?15:22
escalionqschulz: good spot. I'll add a SPLASH_IMAGES variable to my local.conf and test it out15:22
RobertBerger@qschulz: and tend to replace it with the other solution ;)15:22
qschulzescalion: good luck!15:22
escalionUp next my rngd cpu hog investigation >.>15:23
*** sbach <sbach!~sbachmatr@> has joined #yocto15:23
escalionNot looking forward to this *searches racking for a JTAG adaptor"15:24
*** dmoseley <dmoseley!~dmoseley@> has quit IRC15:25
vdlyeah have fun scripting "just a boot loader", you'll quickly appreciate the work done on barebox15:26
escalionvdl: If only bootloaders could be as simple as they are on microcontrollers :D15:38
vdlescalion: sure. Sometimes I'm not sure to get the point of the second stage bootloaders, but well15:39
escalionvdl: It's because of early initialisation memory limits. Basically you have to enable access to that memory, so you need a smaller bootloader to enable the memory and jump to it. Basically15:40
vdlescalion: I guess it's cleaner to separate this step into a separate binary, but in most cases that can simply be part of the main bootloader, right?15:41
escalionvdl: Depends on the size of the bootloader I guess. You can genuinely boot an x86 system in a ~20 lines of assembly, in this case you don't need a second stage.15:43
*** armpit <armpit!~armpit@2601:202:4180:a5c0:2d0c:893d:5593:863c> has quit IRC15:43
escalionI'm all for separation of concerns when writing software, but sometimes people get a little carried away and end up making things more complicated than they were before15:44
*** armpit <armpit!~armpit@2601:202:4180:a5c0:c6a:9ade:28ad:18c> has joined #yocto15:45
escalionI'll look over barebox later. I've stuck with u-boot because it's easy to get going (unlike when I first started using it), but open to change if it has genuine advantages15:47
escalionOther thing to remember is often there is a 'hidden' stage which is built into the ROM of the CPU by the vendor15:48
escalionSo you sometimes end up with 3 stages of bootloader15:49
alejandrohssgw1: if the toolchain.cmake file has the correct sysroot, I'm wondering if do_install overrides something15:53
vdlescalion: barebox was "u-boot v2" to start with. It started as u-boot with a cleaner integration of upstream drivers and dts, and a more unix-y env (you have files, scripts and a really shell).15:53
ecdheso if I already have uboot working from a vendor why would I switch to barebox?15:55
sgw1alejandrohs: great suggestion.  I tried running the cmake command in a devshell and the "all" target worked (used by compile) but the install target still failed.  So maybe it's cmake itself15:56
*** dmoseley <dmoseley!~dmoseley@> has joined #yocto15:57
qschulzvdl: the bootrom loads a very small bootloader into SRAM whose goal is to initialize DRAM and then load the full-featured bootloader. This wouldn't be an issue if the SRAM was big enough. The thing is, SRAM is darn expensive and more or less useless once you've booted into Linux, so the smaller the better.15:57
qschulzI'm sure I'm missing details, but that's the big overview of the boot process15:58
escalion^ this15:58
*** escalion <escalion!> has quit IRC16:02
vdlif only everyone agreed on the smaller the better :>16:03
vdlqschulz: but yes, you're totally right16:03
*** linums <linums!> has quit IRC16:03
vdlecdhe: if you have a working vendor bootloader and you don't need customization at the bootloader level, don't change. You *might* want to change if you need to customize it, like advanced scripting, recovery or boot logic, etc.16:05
qschulzvdl: I'm curious now, what kind of usecase you have to require advanced scripting?16:09
*** dreyna_ <dreyna_!> has joined #yocto16:10
yatesqschulz/vdl: i believe the "very small bootloader" is called the SPL (Secondary Program Loader) in some systems. from there it loads u-boot. this is the way our freescale/nxp imx6 processor board from varscite worked, for example.16:11
*** prabhakarlad <prabhakarlad!> has quit IRC16:13
*** frsc <frsc!> has quit IRC16:19
yatesnow i'm wondering: is u-boot discarded (overwritten) when linux boots?16:19
*** dmoseley <dmoseley!~dmoseley@> has quit IRC16:20
khemRP: you missed,,,20,0,0,0::Created,,khem,20,2,0,82107633 and,,,20,0,0,0::Created,,khem,20,2,0,82058865 onto master-next16:22
qschulzyates: yes SPL is its name16:24
qschulzsometimes you have a TPL too, don't remember why but eh16:24
qschulzyates: U-Boot loads at some place in DRAM, then U-Boot loads the kernel/dtb/initramfs whatever, at some other places in DRAM (where the user tells it to put the files; meaning you could break U-Boot at runtime if you're not careful)16:26
qschulz(this btw was used for an attack with huge images because U-Boot used to wrap the DRAM, so once you reach the max address, it was starting from the min address which is usually where U-Boot is, or something along those lines)16:27
*** vineela <vineela!~vtummala@> has joined #yocto16:27
qschulzOnce the kernel is load in DRAM, you jump to it and where U-Boot was can be safely used for anything else16:27
yatesqschulz: interesting16:29
yatesqschulz: you sound like you have experience in writing bootloaders.16:30
RPkhem: I'm not sure we need the go url change? I missed the systemd bit, yes16:31
*** dmoseley <dmoseley!~dmoseley@> has joined #yocto16:32
khemRP:  I think using https is better isnt it regardless ?16:39
khemwe can also do it as a followup maybe16:39
khemRP: I sent a followup16:44
khemjust changing SRC_URI16:44
RPkhem: ok, thanks16:48
*** fl0v0 <fl0v0!> has quit IRC17:09
*** thekappe <thekappe!c65a42b1@> has quit IRC17:17
*** prabhakarlad <prabhakarlad!> has joined #yocto17:18
*** nvmd <nvmd!~nvmd@> has joined #yocto17:21
*** oberstet <oberstet!~oberstet@> has quit IRC17:23
*** dmoseley <dmoseley!~dmoseley@> has quit IRC17:25
*** dmoseley <dmoseley!~dmoseley@> has joined #yocto17:35
*** EddyEdgy <EddyEdgy!uid193337@gateway/web/> has joined #yocto17:42
*** tnovotny <tnovotny!> has quit IRC17:43
*** cdgarren <cdgarren!> has quit IRC17:43
*** vineela <vineela!~vtummala@> has quit IRC17:46
*** mihai <mihai!~mihai@unaffiliated/mihai> has quit IRC17:53
*** kpo_ <kpo_!> has joined #yocto17:55
*** kiwi_29 <kiwi_29!> has joined #yocto17:56
*** pharaon2502 <pharaon2502!> has joined #yocto17:57
*** vineela <vineela!~vtummala@> has joined #yocto17:58
*** pharaon2502 <pharaon2502!> has quit IRC17:59
*** kiwi_29 <kiwi_29!> has quit IRC18:01
*** rcoote <rcoote!~rcoote@2a02:908:692:81c0:5431:696e:2c99:3f4a> has quit IRC18:07
*** LetoThe2nd <LetoThe2nd!uid453638@gateway/web/> has quit IRC18:12
*** EddyEdgy <EddyEdgy!uid193337@gateway/web/> has quit IRC18:30
mischiefis there a way to get in yocto?18:34
mischiefi'm trying to see if there's a simple way to get useful backtraces without full debug packages..18:34
*** ericbutters <ericbutters!5b3d7226@gateway/web/cgi-irc/> has quit IRC18:42
*** prabhakarlad <prabhakarlad!> has quit IRC18:43
khemmischief: breakpad is an option18:45
mischiefincluding a client library in every program is a nonstarter18:50
mischiefalso we don't (currently) save debug packages for built images. that is why having the minimum useful info already in the image would be good.18:56
frayas for the debug, if you do save this stuff from your build artifacts, it doesn't get deployed (for proprietary use this is protective and) it keeps space smaller as well in the deployed filesystems..18:59
frayyou can always debug (cross) WITHOUT the debug symbols on the target.. (threads need to have the thread library on the target, but that is I think the only limitation)19:00
frayIf you don't mind debug on the target, then there are ways to limit the debug info, but I'm not sure anyone has made it generic (within the scope of YP) yet19:00
mischiefno, we can't debug on target at all19:04
*** Sona <Sona!> has quit IRC19:04
mischiefwhats ideal for us is automatic backtraces in logs (which we can read) and i believe implementing minidebuginfo (the link i posted above) would get us that without full symbols installed19:05
mischiefwe dont even have room for full symbols installed :/19:05
RPmischief: I'd say that implementing that wouldn't be too hard19:07
mischiefRP: i'm a bit of a noob on yocto internals, but fwict it would require overriding a ton of functionality in package.bbclass19:09
RPmischief: well, yes, but definitely doable.19:12
*** prabhakarlad <prabhakarlad!> has joined #yocto19:15
fullstopthis isn't exactly a yocto question, but the image built with it has inconsistent USB bus numbering, and I'm wondering how to make it more consistent.19:30
mischiefdont rely on enumeration order?19:32
fullstopIt has both ehci and ohci controllers, and sometimes ehci is bus 1 and sometimes it is bus 2.19:32
fullstopI mean, I hear what you're saying, mischief, but this feels like /dev/ttyS0 changing to /dev/ttyS1 on a reboot.  I'm okay with not relying on _enumeration_ order, but the order of the bus designations seems like it should be constant.  On a normal laptop it is tied to PCI bus numbering, and they are consistent.19:39
fullstopI wonder if /dev/modules-load.d/* happens before udev/systemd loads other modules...19:47
mischief/dev/modules-load.d/ ?20:01
mischiefsystemd (systemd-modules-load.service) is precisely what reads modules-load.d20:01
mischiefyou could maybe control order by handling module probe order yourself, but really, i would avoid trying to rely on the order20:02
*** kiwi_29 <kiwi_29!> has joined #yocto20:08
fullstopsorry, /etc/modules-load.d/20:23
fullstopit's been a long day20:23
fullstopIt just feels like such a superfluous thing, the arbitrary order.  I can use udev to handle device mapping, say, so that a rs232<->USB device plugged into port 1 maps to /dev/ttyWhatever1, but I can't write rules to do this based on bus and port number.20:26
fullstopbecause the bus number changes on me.20:26
fullstopSo do I write two sets of udev rules?  Calculate which bus is which and rewrite the rules?20:26
*** smooge <smooge!~smooge@centos/qa/smooge> has left #yocto20:32
*** leon-anavi <leon-anavi!~Leon@> has quit IRC20:48
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto20:48
*** zyga <zyga!~zyga@unaffiliated/zyga> has quit IRC21:10
*** dmoseley <dmoseley!~dmoseley@> has quit IRC21:20
*** kiwi_29 <kiwi_29!> has quit IRC21:26
*** kiwi_29 <kiwi_29!> has joined #yocto21:28
*** itseris <itseris!> has quit IRC21:38
*** itseris <itseris!> has joined #yocto21:39
*** kiwi_29 <kiwi_29!> has quit IRC21:40
*** dmoseley <dmoseley!~dmoseley@> has joined #yocto21:41
*** goliath <goliath!> has quit IRC22:00
*** pbb <pbb!> has quit IRC22:09
*** pbb <pbb!> has joined #yocto22:10
*** kiwi_29 <kiwi_29!> has joined #yocto22:11
*** kiwi_29 <kiwi_29!> has joined #yocto22:17
*** agust <agust!> has quit IRC22:18
*** kiwi_29 <kiwi_29!> has quit IRC22:22
khemfullstop: I think systemd had done some work in making the device names consistent22:49
*** fury <fury!uid193779@gateway/web/> has joined #yocto22:57
fullstopkhem: I created a modules-load.d conf file and load the ohci driver first, which seems to keep things consistent.23:06
khemanother approach would be perhaps to write a udev rule which would name it when its detected23:07
khemthen order wont matter23:07
*** leon-anavi <leon-anavi!~Leon@> has quit IRC23:08
fullstopkhem: what do you mean by "it" ?23:11
fullstopIf I have a udev rule which maps a usb serial device on bus 1 port 1 to something, bus 1 must remain bus 1.  I don't think that you can give a bus a name.23:12
khemright yeah23:23

Generated by 2.17.2 by Marius Gedminas - find it at!