Thursday, 2020-11-26

*** linums <linums!> has quit IRC00:05
*** linums <linums!~linums@> has joined #yocto00:06
*** agust1 <agust1!> has quit IRC00:16
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC00:18
*** ericch <ericch!> has quit IRC00:18
*** asteriusio <asteriusio!> has quit IRC00:18
*** asteriusio <asteriusio!> has joined #yocto00:19
*** dev1990 <dev1990!> has quit IRC00:29
*** asteriusio <asteriusio!> has quit IRC00:36
*** camus <camus!~Instantbi@> has joined #yocto00:46
*** kaspter <kaspter!~Instantbi@> has quit IRC00:46
*** camus is now known as kaspter00:46
*** kpo_ <kpo_!> has quit IRC00:50
*** kpo_ <kpo_!> has joined #yocto00:51
*** asteriusio <asteriusio!> has joined #yocto00:52
*** ahadi <ahadi!~ahadi@> has quit IRC00:53
*** risca <risca!~quassel@> has quit IRC00:54
*** ahadi <ahadi!~ahadi@> has joined #yocto00:56
*** erbo <erbo!> has quit IRC00:56
*** erbo <erbo!> has joined #yocto00:56
*** risca <risca!~quassel@> has joined #yocto00:56
*** adelcast <adelcast!> has quit IRC01:03
*** camus <camus!~Instantbi@> has joined #yocto01:26
*** kaspter <kaspter!~Instantbi@> has quit IRC01:26
*** camus is now known as kaspter01:26
*** rcrudo <rcrudo!~rcrudo@2001:16b8:c214:e500:6bf:5a7f:3cd8:619e> has quit IRC01:26
*** vineela <vineela!~vtummala@> has quit IRC01:28
*** vineela <vineela!~vtummala@> has joined #yocto01:29
*** vineela <vineela!~vtummala@> has quit IRC01:30
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has quit IRC01:53
*** nerdboy <nerdboy!~sarnold@> has joined #yocto02:05
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has joined #yocto02:05
*** willy__ <willy__!> has quit IRC02:08
*** marka <marka!> has quit IRC02:09
*** marka <marka!> has joined #yocto02:10
*** eduardas <eduardas!> has quit IRC02:30
*** rcw <rcw!~rcwoolley@> has quit IRC02:36
*** oberstet <oberstet!~oberstet@> has quit IRC02:49
*** linums <linums!~linums@> has quit IRC03:02
*** linums <linums!> has joined #yocto03:04
*** ahadi <ahadi!~ahadi@> has quit IRC03:08
*** ahadi_ <ahadi_!> has joined #yocto03:08
*** linums <linums!> has quit IRC03:16
*** linums <linums!~linums@> has joined #yocto03:16
*** Klox04809318631 <Klox04809318631!> has quit IRC03:55
*** rcrudo <rcrudo!~rcrudo@2001:16b8:c275:7e00:5b7b:48af:39cf:89c6> has joined #yocto04:01
*** rcrudo <rcrudo!~rcrudo@2001:16b8:c275:7e00:5b7b:48af:39cf:89c6> has quit IRC04:10
*** rcrudo <rcrudo!~rcrudo@2001:16b8:c27d:d00:37e1:5a51:e0d9:efdf> has joined #yocto04:12
*** sakoman <sakoman!> has quit IRC04:13
*** Klox04809318631 <Klox04809318631!> has joined #yocto04:13
*** gonkulator <gonkulator!~brandon@> has quit IRC04:15
*** gonkulator <gonkulator!~brandon@> has joined #yocto04:22
*** camus <camus!~Instantbi@> has joined #yocto04:25
*** kaspter <kaspter!~Instantbi@> has quit IRC04:25
*** camus is now known as kaspter04:25
*** Klox04809318631 <Klox04809318631!> has quit IRC04:26
*** Klox04809318631 <Klox04809318631!> has joined #yocto04:27
*** gonkulator <gonkulator!~brandon@> has quit IRC04:28
*** gonkulator <gonkulator!~brandon@> has joined #yocto04:39
*** camus <camus!~Instantbi@> has joined #yocto04:47
*** kaspter <kaspter!~Instantbi@> has quit IRC04:48
*** camus is now known as kaspter04:48
*** georgem_home <georgem_home!uid210681@gateway/web/> has quit IRC04:49
*** amitk <amitk!~amit@unaffiliated/amitk> has joined #yocto05:25
*** willy__ <willy__!> has joined #yocto05:26
*** matthewzmd <matthewzmd!~user@> has quit IRC05:31
*** willy_ <willy_!> has joined #yocto05:32
*** willy__ <willy__!> has quit IRC05:36
*** camus <camus!~Instantbi@> has joined #yocto05:36
*** willy__ <willy__!> has joined #yocto05:37
*** kaspter <kaspter!~Instantbi@> has quit IRC05:37
*** camus is now known as kaspter05:37
*** willy_ <willy_!> has quit IRC05:41
*** willy__ <willy__!> has quit IRC05:45
tlwoerneron Dec 3 the first running of a new conference targeted at embedded (linux) development will occur:
tlwoernermy understanding is that the conference is organized by a group of embedded companies including Bootlin (for example)05:50
tlwoernerthere are several OE/Yocto talks:
tlwoernerthe conference schedule mostly aligns with European timezones05:51
*** tomjose <tomjose!~tomjose@> has quit IRC05:57
*** amitk_ <amitk_!~amit@unaffiliated/amitk> has joined #yocto06:05
*** amitk <amitk!~amit@unaffiliated/amitk> has quit IRC06:08
*** tomjose <tomjose!~tomjose@> has joined #yocto06:16
*** amitk <amitk!~amit@unaffiliated/amitk> has joined #yocto06:19
*** amitk_ <amitk_!~amit@unaffiliated/amitk> has quit IRC06:22
*** davidinux <davidinux!~davidinux@> has joined #yocto06:23
*** amitk_ <amitk_!~amit@unaffiliated/amitk> has joined #yocto06:24
*** AndersD <AndersD!> has joined #yocto06:26
*** amitk <amitk!~amit@unaffiliated/amitk> has quit IRC06:27
*** AndersD_ <AndersD_!> has joined #yocto06:29
*** AndersD <AndersD!> has quit IRC06:31
*** B0ned1ger <B0ned1ger!> has joined #yocto06:32
*** rcoote <rcoote!> has joined #yocto06:32
*** amitk <amitk!~amit@unaffiliated/amitk> has joined #yocto06:42
*** beneth <beneth!> has joined #yocto06:43
*** amitk_ <amitk_!~amit@unaffiliated/amitk> has quit IRC06:45
*** jobroe <jobroe!> has joined #yocto06:46
*** mihai <mihai!~mihai@unaffiliated/mihai> has joined #yocto07:00
*** rob_w <rob_w!~rob@unaffiliated/rob-w/x-1112029> has joined #yocto07:02
*** tomjose <tomjose!~tomjose@> has quit IRC07:05
*** pharaon2502 <pharaon2502!> has joined #yocto07:06
*** geissonator <geissonator!~geissonat@> has quit IRC07:09
*** agust <agust!> has joined #yocto07:11
*** blauskaerm <blauskaerm!~blauskaer@> has joined #yocto07:11
*** iceaway <iceaway!> has joined #yocto07:12
blauskaermIs it possible to make a "install dependency" on a recepie? Such as, in order to install the recepie, another must also be installed?07:13
blauskaermI have a recepie that adds a small script and it uses netcat. Can I add something to that recepie so that I get an error during build if I dont add netcat too?07:14
mihaiblauskaerm: depending on where `netcat` is needed, where would the small script run07:18
iceawayblauskaerm: Can you add the required package to DEPENDS?07:18
blauskaermmihai: It runs just after boot in multi-user mode07:20
blauskaermiceaway: That could be a solution? Is DEPENDS used to give dependacy during build or can it be used for my situation too?07:20
mihaiblauskaerm: then you can add netcat to RDEPENDS variable, which will require netcat to be installed on the target when your script is also installed07:21
*** fatalhalt_ <fatalhalt_!> has quit IRC07:21
blauskaermLooks like what I'm looking for!07:22
blauskaermThank you very much mihai :)07:22
mihaiblauskaerm: np07:22
mihaiblauskaerm: the complete variable specification to use is RDEPENDS_${PN}07:23
*** rcrudo <rcrudo!~rcrudo@2001:16b8:c27d:d00:37e1:5a51:e0d9:efdf> has quit IRC07:24
iceawayI asked here a few days ago when I was having great difficulties installing lib32-libgdiplus in my image, but libgdiplus was fine. I have been digging into the details, and the issue seems to be that lib32-libgdiplus has a postinstall script that tries to use "lib32-qemuwrapper", but the PATH variable in the environment where the postinstall script runs does not include the  "lib32-recipe-sysroot" only the07:24
iceaway"recipe-sysroot". If I make a hack and change the path in the "update_gio_module_cache" script before running qemuwrapper to include the lib32-recipe-sysroot it works fine. Any idea why, or how I can change it, so that the postinstall script also searches the lib32-recipe-sysroot path?07:25
iceawayThis seems to run in the context of the image recipe, so the recipe-sysroot is for the image recipe, not the package recipe. (it's actually not libgdiplus that is the issue, it is libglib-2.0 which is a dependency).07:26
*** kaspter <kaspter!~Instantbi@> has quit IRC07:32
*** kaspter <kaspter!~Instantbi@> has joined #yocto07:33
*** tomjose <tomjose!~tomjose@> has joined #yocto07:36
*** frsc <frsc!> has joined #yocto07:44
*** LetoThe2nd <LetoThe2nd!uid453638@gateway/web/> has joined #yocto07:49
*** geissonator <geissonator!~geissonat@> has joined #yocto07:55
*** wertigon <wertigon!> has joined #yocto07:56
wertigonHey! Having a weird compile problem I cannot seem to resolve no matter what I do07:56
*** Shikadi <Shikadi!> has quit IRC07:57
wertigonWARNING: lz4-native-1_1.9.2-r0 do_fetch: Failed to fetch URL git://, attempting MIRRORS if available07:57
*** gsalazar <gsalazar!955a6fad@gateway/web/cgi-irc/> has joined #yocto07:59
wertigonI can get this repo no problem manually08:00
*** fl0v0 <fl0v0!~fvo@> has joined #yocto08:00
mihaiwertigon: what's the compile problem? that's a fetch warning :)08:05
mihaimaybe you can pastebin it somewhere08:05
wertigonOk, it's a fetch warning; it then complains about no other mirrors having the expected commit hash08:06
wertigonAnd then proceeds to say there is no source at all08:06
*** mckoan|away is now known as mckoan08:06
mckoangood morning08:06
mihaiwertigon: maybe you're trying to use a commit from another branch, in which case you need to also specify the branch08:08
*** kpo_ <kpo_!> has quit IRC08:08
*** kpo_ <kpo_!> has joined #yocto08:08
wertigon <-- Full pastebin of error08:08
wertigonYeah, maybe08:08
wertigonThing is this worked perfectly before... Hmmmm...08:09
wertigonCould it be that upstream changed name of master branch?08:10
*** habing_ <habing_!~habing@2a02:8388:6c0:1200:269c:52c3:be0c:e984> has joined #yocto08:10
wertigon... Yes, this actually seems to be the reason!08:12
wertigonmaster branch deleted, dev branch is now default08:13
*** rcrudo <rcrudo!~rcrudo@> has joined #yocto08:14
LetoThe2ndwertigon: care to report a bug if this is still present on dunfell and/or master?08:16
wertigonI think it is present on dunfell08:18
LetoThe2ndwertigon: can you file a bug then?08:18
wertigonAbsolutely, either this was introduced recently or lz4 is not used that often08:19
LetoThe2ndmcfrisk: howdy! do you maybe have a couple of minutes in private to discuss some BSP crazyness that came to my mind?08:20
*** dev1990 <dev1990!> has joined #yocto08:20
LetoThe2ndwertigon: its much more likely that they renamed the branch a couple of days ago, and nobody caught it because we're all working with hot download caches. i can confirm that on monday dunfell still built fine. (though i'm not sure if my build included lz4)08:21
wertigonYeah, this was broken a couple of days ago08:23
wertigonI did a clean rebuild a couple of days ago because it's what you must do08:24
wertigonEvery month or so we do clean rebuilds to catch errors like these, I mean08:25
mcfriskLetoThe2nd: sure, I could have a chat08:26
wertigonShould the bug be filed under meta-yocto, oe-core or other?08:28
*** TuxBlackEdo <TuxBlackEdo!~Default@unaffiliated/tuxblackedo> has quit IRC08:29
*** T_UNIX <T_UNIX!> has joined #yocto08:29
*** davidinux <davidinux!~davidinux@> has quit IRC08:33
*** davidinux <davidinux!~davidinux@> has joined #yocto08:36
LetoThe2ndwertigon: oe-core08:37
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto08:40
*** eduardas <eduardas!> has joined #yocto08:51
*** megabread <megabread!~megabread@2a01:4b00:e031:2600:9d36:e023:61e7:b8cd> has joined #yocto08:57
*** ginj <ginj!> has quit IRC09:02
LetoThe2ndwertigon: great, thank you very much!09:03
wertigonLetoThe2nd: I also included the quick fix for it :)09:06
LetoThe2ndwertigon: for additional brownie points, send a patch to the oe-core ML :)09:08
*** geissonator <geissonator!~geissonat@> has quit IRC09:17
*** tomjose <tomjose!~tomjose@> has quit IRC09:17
*** w00die <w00die!~w00die@> has quit IRC09:17
*** w00die <w00die!~w00die@> has joined #yocto09:19
*** mckoan_ <mckoan_!~marco@unaffiliated/mckoan> has joined #yocto09:23
*** mckoan <mckoan!~marco@unaffiliated/mckoan> has quit IRC09:27
*** mckoan_ <mckoan_!~marco@unaffiliated/mckoan> has quit IRC09:30
*** mckoan <mckoan!~marco@unaffiliated/mckoan> has joined #yocto09:31
*** B0ned1ger <B0ned1ger!> has quit IRC09:32
*** B0ned1ger2 <B0ned1ger2!> has joined #yocto09:32
*** otavio <otavio!~otavio@debian/developer/otavio> has quit IRC09:32
*** Dracos-Carazza <Dracos-Carazza!~Dracos-Ca@> has quit IRC09:42
*** Dracos-Carazza <Dracos-Carazza!~Dracos-Ca@> has joined #yocto09:44
*** thecomet <thecomet!> has joined #yocto09:45
thecometSo this is a stupid problem, but I pressed CTRL+C immediately after "bitbake target" (twice) and now I can't run bitbake anymore at all. It just gets stuck09:46
thecometWhat can I do?09:46
wertigonthecomet: Easiest is to just delete tmp-glibc and re-run09:47
wertigonIt'll cost you a bit of time09:47
thecometWill my workspace/sources directory still be in tact or will I have to run devtool modify again?09:48
wertigonNo idea if there is a more elegant solution out there :)09:48
wertigonYes, only delete tmp-glibc in the build folder09:48
*** oberstet <oberstet!~oberstet@> has joined #yocto09:49
wertigonI think there is a bitbake command in there somewhere, but no idea where, how or when.09:49
carlsb3rgthe bitbake server is a python process, isn't it?09:49
carlsb3rgthink I recall killing a python process to force a hung bitbake process09:50
*** awaisb <awaisb!~quassel@> has joined #yocto09:50
*** abelal <abelal!~quassel@> has quit IRC09:51
thecometI deleted build/bitbake.lock and that seems to have fixed it09:52
thecometI should have probably checked for python processes first though, oops09:52
RPkanavin_home: should I stop that f33 reproducible build?09:55
kanavin_homeRP: it seems like diffoscope chokes on large items, let me take a look10:03
*** Yumasi <Yumasi!> has joined #yocto10:03
kanavin_homeRP: yes you can stop. I think any failing packages are already saved so I can look at it - seems like llvm wasn't quite fixed fully10:04
cengiz_iohello. what are the possible unwanted side effects of having a very high BBFILE_PRIORITY on your custom layer?10:10
cengiz_ioI'm trying to replace a psplash image from oe, that has already been bbappend'ded by another layer, and what I really want is my image to be used from meta-mylayer10:11
cengiz_ioand log.do_unpack picks other layer's bbappend due to my layer priority.10:11
qschulzcengiz_io: highest prio will be applied last provided the paths in SRC_URI are identical10:12
cengiz_ioSRC_URI's are identical10:13
qschulzcengiz_io: triple check your paths, quadruple check your FILESEXTRAPATHS_prepend :=10:13
qschulzcengiz_io: and check that your bbappend is actually applied (there's a bitbake-layers command for that IIRC)10:14
cengiz_ioqschulz I did copy the exact bbappend and files. didn't even rename them.10:14
cengiz_ioqschulz it's definitely being added to search path, as I see it in do_unpack logs.10:15
qschulzcengiz_io: shouldn't do_unpack only list the paths it failed to find a file in?10:15
cengiz_iohere's a snippet of it.10:16
*** zandrey <zandrey!~zandrey@> has joined #yocto10:18
cengiz_ioDEBUG: Searching for psplash-poky-img.h in paths: | <path> <path> <path> ... <my layer's path that includes psplash-poky.img.h> ... <path> <path> <meta-agl-profile-core layer's path that has the same file>10:18
cengiz_ioif the order is relevant to priority, my layer is skipped10:19
cengiz_ioNOTE: Unpacking /yocto/meta-agl/meta-agl-profile-core/recipes-core/psplash/files/psplash-poky-img.h10:19
cengiz_iometa-agl-profile-core has priority of 80, meta-mylayer has 2010:20
*** B0ned1ger2 <B0ned1ger2!> has quit IRC10:22
*** B0ned1ger <B0ned1ger!> has joined #yocto10:23
qschulzcengiz_io: there you go:
qschulzmeta-mylayer has lower prio10:25
cengiz_ioyeah I've changed it to 80 will see if my PV will let me override it10:26
cengiz_ioqschulz equalizing the priority and adding SRCREV = "${AUTOREV}" \n PV = "1.00+git${SRCPV}" did the trick10:33
cengiz_ioqschulz with too high priority it wasn't compiling.10:34
qschulzcengiz_io: don't use AUTOREV for production ;)10:36
cengiz_ioqschulz don't really care10:36
qschulzcengiz_io: if the order or priority breaks your build, your layer needs to be reworked10:36
qschulz(or AGL's)10:36
cengiz_ioqschulz you're probably right but I'm out of willpower and time10:39
cengiz_iobtw what's wrong with AUTOREV? I already commit each change to my layer10:40
cengiz_ioand what else do you suggest? hardcoded rev?10:40
*** kaspter <kaspter!~Instantbi@> has quit IRC10:41
rcrudois there an yocto example to install python packages from the source and without pypi?10:41
*** kaspter <kaspter!~Instantbi@> has joined #yocto10:41
rcrudoI meant recipe example10:43
*** davidinux <davidinux!~davidinux@> has quit IRC10:43
*** davidinux <davidinux!~davidinux@> has joined #yocto10:45
*** Dracos-Carazza_ <Dracos-Carazza_!~Dracos-Ca@> has joined #yocto10:46
cengiz_iorcrudo did you check openembedded recipe search?10:46
cengiz_iopython recipes are very scarce though10:47
*** Dracos-Carazza <Dracos-Carazza!~Dracos-Ca@> has quit IRC10:47
*** geissonator <geissonator!~geissonat@> has joined #yocto10:47
rcrudocengiz_io: yes, they all seems to use pypi10:48
qschulzcengiz_io: the point of a build system is to be able to rebuild an image years after it was originally built10:50
qschulzAUTOREV means that yoiu'll never be able to do that because it'll always fetch the last commit10:50
paulbarkerrcrudo: I know bmap-tools isn't published on pypi so you may be able to find a recipe for that10:52
cengiz_ioqschulz indeed. but I'm not frozen my build yet.10:52
paulbarkerrcrudo: If your python source has a `` file it's usually pretty simple to make a recipe for it10:53
rcrudopaulbarker: bmap-tools looks like a good example, thanks10:55
wyrewhat's intended the distribution layer for?
*** Dracos-Carazza_ is now known as Dracos-Carazza10:59
LetoThe2ndwyre: in a nutshell, the DISTRO layer defines the ABI/API of the resulting distribution, and therefore the facilities that "higher" applications can use.11:00
RPkanavin_home: ok. I figured it was stuck in diffoscope :/11:02
*** tomjose <tomjose!~tomjose@> has joined #yocto11:04
*** geissonator <geissonator!~geissonat@> has quit IRC11:05
cengiz_ioanyone seen this before? ` error: 'POKY_IMG_WIDTH' undeclared (first use in this function); did you mean 'BAR_IMG_WIDTH'?`11:09
cengiz_iofor the record, I'vve generated image header with script11:09
cengiz_ioyikes. that script requires a second argument...11:11
cengiz_ionevermind me.11:11
*** jonasbits <jonasbits!~quassel@2001:2002:4e48:1aca:908e:1969:c028:2e1d> has joined #yocto11:18
iceawayI'm trying to find where in bitbake the PATH variable is set up when doing various recipe tasks (do_rootfs in particular). Any suggestions?11:27
*** goliath <goliath!> has joined #yocto11:28
kanavin_homeRP: I do wonder if diffoscope somehow has a bug, because one of the selftests passed fine through the diffoscope step, with the same set of non-reproducible packages11:32
kanavin_homeand in any case, it should not run for this long11:32
*** BobPungartnik <BobPungartnik!~BobPungar@> has joined #yocto11:33
LetoThe2ndiceaway: bitbake -e not being helpful?11:34
RPkanavin_home: that was the one which built the original packages so they would match11:34
*** kayterina <kayterina!kayterina-@gateway/shell/> has quit IRC11:34
*** clementp[m] <clementp[m]!cperonmatr@gateway/shell/> has quit IRC11:34
*** xicopitz[m] <xicopitz[m]!xicopitzma@gateway/shell/> has quit IRC11:34
*** stefan-schmidt[m <stefan-schmidt[m!stefan-sch@gateway/shell/> has quit IRC11:34
*** yangm <yangm!yanyetanot@gateway/shell/> has quit IRC11:34
*** hmw1 <hmw1!hmwmatrixo@gateway/shell/> has quit IRC11:34
*** henriknj <henriknj!hnjematrix@gateway/shell/> has quit IRC11:34
*** khem <khem!khemmatrix@gateway/shell/> has quit IRC11:34
*** GonZo2k <GonZo2k!gonzo2000m@gateway/shell/> has quit IRC11:34
*** nrossi <nrossi!nrossimatr@gateway/shell/> has quit IRC11:34
*** bachp <bachp!bachpmatri@gateway/shell/> has quit IRC11:35
*** silviof <silviof!silv-iomat@gateway/shell/> has quit IRC11:35
*** cbrake1 <cbrake1!cbrakematr@gateway/shell/> has quit IRC11:35
*** lexano[m] <lexano[m]!lexanomatr@gateway/shell/> has quit IRC11:35
*** ahadi_ <ahadi_!> has quit IRC11:37
*** tgoodwin[away] <tgoodwin[away]!> has quit IRC11:37
*** gsalazar <gsalazar!955a6fad@gateway/web/cgi-irc/> has quit IRC11:39
*** ahadi <ahadi!> has joined #yocto11:39
*** BobPungartnik <BobPungartnik!~BobPungar@> has quit IRC11:40
*** tgoodwin <tgoodwin!> has joined #yocto11:40
*** xicopitz[m] <xicopitz[m]!xicopitzma@gateway/shell/> has joined #yocto11:42
kanavin_homeRP: not sure I understand your explanation? the passing selftest was this one
kanavin_homeone other selftest from a-full failed, and two others got stuck in diffoscope11:46
kanavin_homeRP: ah nevermind11:47
kanavin_homeI get it now: the passing selftest built packages from scratch and that matched11:47
kanavin_homewhen one of them comes from sstate, it may be mis-matching11:47
kanavin_homeRP: the mystery is I guess why one other selftest failed, and two others got stuck11:48
RPkanavin_home: right, I'd guess it just depends which builders built the objects in sstate11:52
kanavin_homeRP: the packages are all saved here for failing and cancelled ones11:53
kanavin_homeI'll take a look what is different there, I guess diffoscope cannot handle enormously big items like llvm11:53
*** gsalazar <gsalazar!955a6fad@gateway/web/cgi-irc/> has joined #yocto11:53
*** clementp[m] <clementp[m]!cperonmatr@gateway/shell/> has joined #yocto11:56
*** bachp <bachp!bachpmatri@gateway/shell/> has joined #yocto11:56
*** stefan-schmidt[m <stefan-schmidt[m!stefan-sch@gateway/shell/> has joined #yocto11:56
*** hmw1 <hmw1!hmwmatrixo@gateway/shell/> has joined #yocto11:56
*** nrossi <nrossi!nrossimatr@gateway/shell/> has joined #yocto11:56
*** yangm <yangm!yanyetanot@gateway/shell/> has joined #yocto11:56
*** silviof <silviof!silv-iomat@gateway/shell/> has joined #yocto11:56
*** kayterina <kayterina!kayterina-@gateway/shell/> has joined #yocto11:56
*** GonZo2k <GonZo2k!gonzo2000m@gateway/shell/> has joined #yocto11:56
*** khem <khem!khemmatrix@gateway/shell/> has joined #yocto11:56
*** henriknj <henriknj!hnjematrix@gateway/shell/> has joined #yocto11:56
*** cbrake1 <cbrake1!cbrakematr@gateway/shell/> has joined #yocto11:56
*** lexano[m] <lexano[m]!lexanomatr@gateway/shell/> has joined #yocto11:56
RPkanavin_home: right, it seems to have a problem when things get really large :/11:56
*** khem is now known as Guest1166211:56
*** JaBen <JaBen!~Thunderbi@2a02:8109:86c0:1c58:bd52:f0ef:80f0:e69e> has joined #yocto12:00
*** tgoodwin <tgoodwin!> has quit IRC12:04
*** otavio <otavio!> has joined #yocto12:13
*** otavio <otavio!~otavio@debian/developer/otavio> has joined #yocto12:13
*** B0ned1ger <B0ned1ger!> has quit IRC12:23
*** B0ned1ger2 <B0ned1ger2!> has joined #yocto12:23
*** geissonator <geissonator!~geissonat@> has joined #yocto12:25
JaBen@qschulz: yesterday you suggested to me, that I should just cherry-pick the most necessary stuff from ADI like kernel, u-boot etc. I would like to hear how you make sure that these components keep up to date with the vendor "upstream". Do you still include their meta-layer and work with layer preferences (if I recall correctly there was some option of this sorts) or do you just hard copy the recipes from their layer to your own. If12:26
*** linums <linums!~linums@> has quit IRC12:30
*** linums <linums!~linums@> has joined #yocto12:30
JaBen(found it: laking about the BBFILE_PRIORITY setting in the layer config)12:33
*** mckoan is now known as mckoan|away12:39
iceawayLetoThe2nd: I was  thinking more of in which script the PATH is configured, but maybe I can dig that out of bitbake -e?12:47
LetoThe2ndiceaway: if it is something that is dynamically set, then you can, yes.12:48
qschulzJaBen: I do not include their meta-layer and we do not keep up to date12:52
qschulzIoT industry does not care about  upgrade sadly12:52
qschulzbut you'd manually monitor changes to source git repos or layer git repos12:52
qschulzBSP component recipes rarely change so much that you can't just change SRCREV manually though12:54
JaBen@qschulz: hm ok... wouldn't it be easier to use their meta-layer and just add your own layer on top with a higher priority? this way you could still automatically pull updates from the few recipes you use from their layer12:55
JaBenok, I just noticed this wouldn't work too well for 2. reasons. 1: the BBFILE_PRIORITY is set within the layer itself  and 2: the layer compatibility still would stop us from using their layer with dunfell. unless this can be overwritten within the local.conf?13:03
qschulzJaBen: in which case you want to BBMASK everything you don't need AND make sure it's still ok to build later on13:05
qschulzJaBen: it can be overwritten in local or layer.conf (even one that isn't the layer's, but that's uuhhh.. not guaranteed, it's not intended, it works but nothing tells us it won't be modified later)13:06
qschulz(we use the layer.conf method for meta-qt5 IIRC ;) )13:06
JaBenok, so assuming this doesn't get modified, taking meta-qt5 as an example I could try setting BBFILE_PRIORITY_meta-qt5 = X and LAYERSERIES_COMPAT_meta-qt5 or is it minus the "meta-"?13:10
qschulzJaBen: I'd rather spend time on debugging my own recipes based on vendor's BSP components than debugging their layers13:10
qschulzspecifically, we add a shit ton of patches on top, so we anyway fork off the vendor;s13:11
qschulzJaBen: priority probably not but LAYERSERIES_COMPAT yeah13:11
qschulzthough it's probably not meta-qt5 but the name of the BBCOLLECTIONS (qt5-layer maybe? don't remember)13:11
*** gpanders <gpanders!> has quit IRC13:14
JaBen@qschulz: I get where you are coming from with "not wanting debugging their layer", however I am hoping to be able to automatically build two versions using KAS: using the latest known-working refspec and bleeding-edge. so I naively assumed, that debugging their changes might be less of a pain if we just test their changes fast enough :D13:14
*** pbergin <pbergin!> has joined #yocto13:16
rcrudoHow can set my yocto image to use python3 as default? I want to fix this: QA Issue: /usr/bin/ contained in package python3-intelhex requires /usr/bin/python13:17
JaBen@qschulz I'm just a bit scarred by our status quo, where we have some 5 year old forks of OSS projects within our firmware, which are a maintainability nightmare as my colleagues also added their own stuff on top... so really painful to keep up to date :/13:19
qschulzrcrudo: shebang at the top of you script needs to have python3 in it13:20
qschulzrcrudo: and migrate the script to python3 if it was written for python213:20
qschulzJaBen: I might be biased as I really don't trust vendors (well technically, we're vendors too and our layers aren't that much better, but it's only our fault :p)13:21
qschulzJaBen: and if I had the choice I'd go 100% upstream13:22
qschulzbut yeah, you see the maintenance burden13:22
*** vineela <vineela!~vtummala@> has joined #yocto13:24
*** dexterlb <dexterlb!~dexterlb@2a01:9e40:2:2::2> has quit IRC13:24
*** vineela <vineela!~vtummala@> has quit IRC13:26
*** gpanders <gpanders!> has joined #yocto13:32
JaBen@qschulz: Ok, so the ADI layer defines `LAYERSERIES_COMPAT_adsp-sc5xx = "thud"` and I tried setting `LAYERSERIES_COMPAT_adsp-sc5xx_append = " dunfell"` in local.conf without any luck. :/13:32
yannin bitbake/lib/bb/fetch2/ most logging is done through bb.fetch2.logger, but there is a handful of bb.note calls - how harmless is that ?13:33
qschulzJaBen: then in any other layer.coinf13:35
JaBenthat seems to work :)13:37
qschulzsubject to breakage ;)13:37
*** pharaon2502 <pharaon2502!> has quit IRC13:38
*** dexterlb <dexterlb!~dexterlb@2a01:9e40:2:2::2> has joined #yocto13:38
*** pharaon2502 <pharaon2502!> has joined #yocto13:39
JaBen@qschulz: lets hope not :D I mean being able to set the layer priority from outside the layer in question sounds like something you would want to be able to do. especially when relying a lot on upstream13:44
qschulzJaBen: you can always work around priorities by splitting your layers into higher and lower prio compared to upstream layers you depend on13:45
JaBentrue, but say you want to put an upstream layer at a higher priority than a second upstream layer13:47
*** gpanders <gpanders!> has quit IRC13:48
qschulzJaBen: if they have same prio, the order in which they are included in bblayers.conf is the way to order your layers13:48
JaBenhow to shitfix vendor layers 101: overwrite their compatibility setting and bbmask stuff until it builds! :D13:49
JaBen@qschulz: assuming they have the same prio... but good to know that the order makes a difference. So the last one to add is is highest prio?13:50
qschulzJaBen: IIRC yes13:52
qschulzbut not for classes and conf files :p13:52
qschulz(the opposite)13:52
JaBen@qschulz well thats not confusing at all :P13:56
qschulzJaBen: classes and conf files are parsed in order of BBPATH, which by default is appended to by each layer and the priority does not matter for that one13:57
*** rcw <rcw!~rcwoolley@> has joined #yocto13:58
*** linums <linums!~linums@> has quit IRC14:03
*** linums <linums!> has joined #yocto14:05
*** linums <linums!> has quit IRC14:23
*** linums <linums!~linums@> has joined #yocto14:24
rcrudoqschulz: that is not my script. it's coming from pypi installation14:27
*** geheimnis` <geheimnis`!~geheimnis@> has quit IRC14:27
*** geheimnis` <geheimnis`!~geheimnis@> has joined #yocto14:30
rcrudonvm, fixed with do_install_append14:35
qschulzrcrudo: care to tell us what you did? (IRC messages are archived and publicly available so if anyone has the issue,m they may fall on this archive :) )14:37
rcrudoI used do_install_append with a sed -> sed -i 's|#!/usr/bin/python|#!/usr/bin/python3|g' ${D}/usr/bin/*.py14:38
qschulzrcrudo: is it an exact match?14:40
qschulzbecause if your package is updated upstream one day, you might replace #!/usr/bin/python3 with #!/usr/bin/python3314:41
*** pbergin <pbergin!> has quit IRC14:42
*** anoo1 <anoo1!~anoo1@> has quit IRC14:42
*** tomjose <tomjose!~tomjose@> has quit IRC14:42
*** geissonator <geissonator!~geissonat@> has quit IRC14:43
rcrudoqschulz: good point! thanks for the code review ;)14:44
*** anoo1 <anoo1!~anoo1@> has joined #yocto14:47
*** matthewcroughan_ <matthewcroughan_!> has joined #yocto14:47
matthewcroughan_Hey :)14:47
matthewcroughan_What are .in files in Yocto?14:47
LetoThe2ndoppostite of .out!14:48
matthewcroughan_Ah, I thought it might have been related to .inc lol14:48
LetoThe2ndwell that would be .inc files :) nah seriously, if it was a typo and you mean .inc, then its actually nothing with deeper meaning other than it being a file that is included somewhere. if it wasn't a typo, no idea. never seen any .in files.14:50
qschulzI think those are files that are supposed to be handled in Yocto to replace some variables?14:54
qschulzor sometimes by autotools or whatever14:54
*** Yumasi <Yumasi!> has quit IRC14:56
*** Klox04809318631 <Klox04809318631!> has quit IRC14:57
matthewcroughan_You guys are great, didn't expect a quick response, or 270~ users to be here lol.14:57
*** Yumasi <Yumasi!~guillaume@2a01:e0a:5cb:4430:5572:c108:3697:b06d> has joined #yocto14:58
LetoThe2ndwell sure autotools have somewhere in their processing stage for example, but where do they surface in yocto context? (serious question, never witnessed that)14:59
matthewcroughan_So, I still don't really know what a .in file is, I can't really find it in the docs explained.15:00
LetoThe2ndmatthewcroughan_: it would be useful if you just would show the file, respectively path where it can be found.15:00
matthewcroughan_The first mention of .in is here in the megamanual.
LetoThe2nd(e.g.: you're missing context at the moment)15:00
LetoThe2ndthats no "yocto" context, rather just "some generic whatever file somewhere in the package that has to be patched"15:01
LetoThe2ndor alternatively, "jsut some generic file that is used in some way in the package".15:02
LetoThe2ndbut in no meaning it relates to the yocto build process - it is something package-internal.15:02
LetoThe2ndyou can have a file "fooboobar.xyzzy" that comes with your recipe and is being packaged. bitbake itself doesn't care what it is, it just carries out what the recipe defines to be done with it.15:04
*** kpo_ <kpo_!> has quit IRC15:05
*** kpo_ <kpo_!> has joined #yocto15:05
matthewcroughan_What would the purpose of be here then?15:07
matthewcroughan_I just see these files around and wonder "Why does it have that extension?15:07
LetoThe2ndi have to admit, i see that question and wonder why would anybody on earth even think of that. :) but seriously, i have no idea. it is definitively a bitbake source internal. if you absolutely and totally must know, then get in touch with one of its maintainers. but i can assure you that you will have a long and happy yocto career without ever seeing that file again.15:10
*** Klox04809318631 <Klox04809318631!> has joined #yocto15:11
*** linums <linums!~linums@> has quit IRC15:11
*** linums <linums!> has joined #yocto15:13
LetoThe2ndtoday i learned:
LetoThe2ndmatthewcroughan_: here you go ^^^^ just like i said. bitbake source internal.15:14
LetoThe2nd(please note that this in no way correlates to the example in the manual that you mentioned.)15:14
matthewcroughan_oh okay so this has nothing to do with recipes then in that context15:17
*** frsc <frsc!> has quit IRC15:17
LetoThe2ndabsolutely and totally not.15:17
matthewcroughan_what if you had a file like recipes-core/utils/ostree/ostree/ ?15:18
matthewcroughan_do you need context for this sort of thing? Do extensions mean anything to bitbake if they're not .bb or .bbappend?15:19
qschulzthose are files included in recipes15:20
LetoThe2ndqschulz: note the second "ostree" in the path15:21
LetoThe2ndmatthewcroughan_: this is an example of the case you mentioned in the manual. this is a file that is in some way ingested by the recipe. look at its SRC_URI, it is probably there. and then look at the recipe what it is being used for.15:22
LetoThe2nde.g.: doesn't relate to yocto15:22
matthewcroughan_Okay, what *is* the recipe and what *is not* the recipe?15:23
LetoThe2ndmatthewcroughan_: and it really helps if you refer to things that we can also see. this seems to be nothing that we can inspect.15:23
LetoThe2ndmatthewcroughan_: recipe: .bb15:23
LetoThe2ndmatthewcroughan_: if inside the recipe things are "included" or "required", then they effectively also become part of it. everything else is *not* the recipe.15:25
matthewcroughan_So, if a file without .in is present, it is not in the recipe?15:26
matthewcroughan_By not putting .in on the end of a file, you are excluding it?15:26
qschulzLetoThe2nd: I saw it, hence my remark ;) (recipes-*/*/*.bb is the default so one too many subdir :) )15:26
LetoThe2ndqschulz: which in turn means that it is in the default FILES searching path.15:27
qschulzmatthewcroughan_: a .in file is nothing to yocto, it makes sense only for a software built by Yocto15:27
qschulzit's something you add to the sources of whatever you want to build15:27
LetoThe2ndmatthewcroughan_: i have no idea how i shall word it in any other way than i already it. this file is something that the author of the recipe added/needs for something the recipe does. we know nothing of it, yocto knows nothing of it.15:28
matthewcroughan_Well the exact case I'm trying to understand seems to be here.
* LetoThe2nd facepalms and is silent now.15:28
matthewcroughan_what purpose does .in serve? Is it literally just convention? or does it serve a literal purpose?15:28
zeddiiit's an automake concept. nothing to do with yocto.15:29
zeddiijust like "Makefile" means nothing to oe/yocto.15:29
matthewcroughan_zeddii: Awesome.15:34
matthewcroughan_So similarly, .patch means nothing? It just hints at the contents and purpose of the file?15:35
qschulzmatthewcroughan_: hehehe no. .patch files will be applied to the source in order of their declaration in SRC_URI15:35
matthewcroughan_okay, so bitbake *does* care about more than just .bb and .bbappend files?15:35
qschulzsame for .diff15:35
matthewcroughan_Is there a list of file extensions that are special to bitbake? :D15:36
qschulzmatthewcroughan_: they're actually not special to bitbake, they're special to recipes built by bitbake15:36
qschulz.patch, .diff are applied by default15:36
qschulzsome tarball extensions are automatically unpacked too15:36
matthewcroughan_Is this behavior somewhere in the bitbake manual then? What should I search for?15:37
qschulzmatthewcroughan_: if you want to understand everything that bitbake does, you're in for a long journey15:37
qschulzI haven't read thebitbake manuals even once15:37
qschulzthough i should15:37
qschulzi've read the Yocto manuals though15:37
qschulzjust start working on something simple and build your knowledge from there15:38
matthewcroughan_That always works. Though I'm really not sure where the starting point is.15:38
*** davidinux <davidinux!~davidinux@> has quit IRC15:41
matthewcroughan_qschulz: What determines if a function is executed in a bitbake file?15:42
*** lfa <lfa!> has joined #yocto15:42
matthewcroughan_By being defined, is it always ran?15:42
*** anoo1 <anoo1!~anoo1@> has quit IRC15:43
matthewcroughan_do_something() do_something_else(), how do I conditionally *not* run the latter function? Or have I misunderstood bitbake?15:43
*** anoo1 <anoo1!~anoo1@> has joined #yocto15:46
matthewcroughan_Additionally, is there an importance to the `do_` in `do_thing` or is this again just naming convention?15:47
qschulzmatthewcroughan_: tasks should start with do_, that's a convention15:48
matthewcroughan_right, but it doesn't have any literal effect like vars do?15:48
qschulzyou can have "normal" python or shell functions which aren't tasks too15:48
matthewcroughan_SOMEVAR_append has a real usage, and it does stuff, but do_ doesn't magically do anything on your behalf right?15:48
qschulztasks aren't run (except the anonymous one) except asked15:48
qschulz"asked" can be by the user or through recipe or task dependencies15:49
*** eduardas <eduardas!> has quit IRC15:53
stkw0is down? bitbake is telling me I don't have internet connection but I have. It seems it connects to and if it doesn't respond it exits15:56
*** AndersD_ <AndersD_!> has quit IRC16:02
JaBenhas there been a change on how to SRC_URI a folder since thud? Trying to set SRC_URI += "file://feature/" throws an "ERROR. input file "feature/cfg/nfs.cfg" does not exist", although path /mnt/lnxdsp-adi-meta/meta-adi-adsp-sc5xx/recipes-kernel/linux/linux-adi/ is searched and /mnt/lnxdsp-adi-meta/meta-adi-adsp-sc5xx/recipes-kernel/linux/linux-adi/feature/cfg/nfs.cfg exists16:04
stkw0LetoThe2nd: thanks, something is wrong with my computer, it doesn't resolve that domain specifically :(16:08
JaBenThis is the file in question btw:
JaBen@stkw0 assuming unix-like, try setting a different dns server in /etc/resolv.conf for testing purposes ( e.g. and see if the issue still persists.16:12
stkw0JaBen: I did it, same problem. I also tried to use the phone and connect to and chrome gives a DNS_PROBE_FINISHED_NXDOMAIN, I guess the ISP is doing something16:13
JaBen@stkw0: you could try running `dig` and see which server is answering the request16:15
stkw0using dnscrypt-proxy ""fix"" the issue16:16
*** gnac <gnac!> has quit IRC16:16
stkw0JaBen: yeah, that is what I was trying, using dig with different dns servers, but none worked16:17
JaBengotta love ISPs16:17
*** tomjose <tomjose!~tomjose@> has joined #yocto16:18
*** sakoman <sakoman!> has joined #yocto16:22
*** B0ned1ger2 <B0ned1ger2!> has quit IRC16:23
*** B0ned1ger <B0ned1ger!> has joined #yocto16:23
*** wertigon <wertigon!> has quit IRC16:23
*** Yumasi <Yumasi!~guillaume@2a01:e0a:5cb:4430:5572:c108:3697:b06d> has quit IRC16:31
*** pharaon2502 <pharaon2502!> has quit IRC16:31
*** amitk <amitk!~amit@unaffiliated/amitk> has quit IRC16:32
qschulzJaBen: i'm surprised file://feature/ would throw such a specific error (a file namely)16:32
JaBen@qschulz: interestingly enough, the folder (and files) are actually added to build/tmp/work/adsp_sc573_ezkit-poky-linux-gnueabi/linux-adi/4.19-r0/feature/. So this appears to be a bug within yocto or bitbake?16:36
qschulzJaBen: when does the error happen (which task?)16:48
qschulzJaBen: always blame the vendor before upstream :)16:49
*** zandrey <zandrey!~zandrey@> has quit IRC16:49
JaBen@qschulz: I'd agree, but I don't see how this could be a vendor issue. I'm running `bitbake linux-adi` which this recipe:
JaBenthe task failing is "do_kernel_metadata"16:54
*** fl0v0 <fl0v0!~fvo@> has quit IRC16:55
JaBen@qschulz: complete log is here:
qschulzJaBen: first one in the list has a full path, not the others17:02
qschulzJaBen: just being curious, but what about adding all config fragments by hand (and not use features/ only)17:04
*** w00die <w00die!~w00die@> has quit IRC17:05
*** w00die <w00die!~w00die@> has joined #yocto17:06
*** geissonator <geissonator!~geissonat@> has joined #yocto17:07
JaBen@qschulz: so I tried setting SRC_URI += "file://feature/cfg/nfs.cfg", same issue. Only adding FILESEXTRAPATHS_prepend := ${THISDIR}/${BPN}/feature/cfg/:" and SRC_URI to "file://nfs.cfg" worked17:09
JaBen@qschulz so I assume the parser at some point tries to interpret "feature/cfg/nfs.cfg" as a filename17:09
JaBenI see there has been a lot of change to do_kernel_metadata since thud17:11
yannI'm trying to integrate our yarn fetcher by monkey-patching (like meta-rust) to avoid touching the poky repo, and stumbled on a strange issue: when doing that, SRCPV stops being defined (that YarnFetcher is still derived from gitsm)17:12
yannlooks like SRCPV is only set if the URI scheme matches a hardcoded list :(17:13
yannany reason needsrcrev is not defined by the fetcher ?17:14
*** kaspter <kaspter!~Instantbi@> has quit IRC17:20
*** kaspter <kaspter!~Instantbi@> has joined #yocto17:20
*** thecomet <thecomet!> has quit IRC17:25
*** habing_ <habing_!~habing@2a02:8388:6c0:1200:269c:52c3:be0c:e984> has quit IRC17:30
*** rcrudo <rcrudo!~rcrudo@> has quit IRC17:31
qschulzJaBen: I'm clueless sorry17:33
qschulzmight want to send a mail or open a bug on bugzilla17:33
*** kpo_ <kpo_!> has quit IRC17:34
qschulz(try to reproduce on linux-yocto from gatesgarth though before)17:34
*** kpo_ <kpo_!> has joined #yocto17:34
*** mckoan|away is now known as mckoan17:44
JaBen@qschulz: I am afraid you were right and it seems to be a vendor issue. no idea how, though... I'm not able to reproduce on a basic poky image17:45
mckoanhow can I use recipetool setvar "-option" ? Looks like the dash gives an error17:45
mckoanand setvar -option  doesn't work17:46
*** mckoan is now known as mckoan|away17:52
*** linums <linums!> has quit IRC17:55
*** linums <linums!> has joined #yocto17:57
JaBen@qschulz: ok, so the issue actually comes from these lines: So the error message is definitely misleading...18:00
*** rob_w <rob_w!~rob@unaffiliated/rob-w/x-1112029> has quit IRC18:01
*** ssajal <ssajal!> has quit IRC18:06
*** ssajal <ssajal!> has joined #yocto18:08
*** rcoote <rcoote!> has quit IRC18:18
*** anoo1 <anoo1!~anoo1@> has quit IRC18:18
*** geissonator <geissonator!~geissonat@> has quit IRC18:19
*** tomjose <tomjose!~tomjose@> has quit IRC18:20
*** anoo1 <anoo1!~anoo1@> has joined #yocto18:21
*** mihai <mihai!~mihai@unaffiliated/mihai> has quit IRC18:22
*** gsalazar <gsalazar!955a6fad@gateway/web/cgi-irc/> has quit IRC18:33
JaBen@qschulz: eeeehhh... stupid question: shouldn't the files be added to the ${S} (${WORKDIR}/git) directory? because in my case they end up in ${WORKDIR}18:35
neverpanicNo, stuff from SRC_URI has always been placed in WORKDIR, unless you manually specified a different destination18:36
*** megabread <megabread!~megabread@2a01:4b00:e031:2600:9d36:e023:61e7:b8cd> has quit IRC18:39
*** linums <linums!> has quit IRC18:40
*** linums <linums!~linums@> has joined #yocto18:42
*** linums <linums!~linums@> has quit IRC18:46
*** jobroe <jobroe!> has quit IRC18:49
*** linums <linums!~linums@> has joined #yocto18:49
*** LetoThe2nd <LetoThe2nd!uid453638@gateway/web/> has quit IRC18:50
rburtonJaBen: idiom is that SRC_URI files are put in WORKDIR, and then anything that is an archive unpacked. S is WORKDIR/BPN-PV, so if your SRC_URI is a typical tarball, S points into the unpacked tarball18:52
*** camus <camus!~Instantbi@> has joined #yocto18:59
*** kaspter <kaspter!~Instantbi@> has quit IRC19:00
*** camus is now known as kaspter19:00
*** JaBen <JaBen!~Thunderbi@2a02:8109:86c0:1c58:bd52:f0ef:80f0:e69e> has quit IRC19:02
*** armpit <armpit!~armpit@2601:202:4180:a5c0:d0c2:4ffa:1fd8:ee96> has joined #yocto19:05
*** Saur <Saur!pkj@nat/axis/x-mkyufnjfzystsaac> has quit IRC19:22
*** mbulut <mbulut!> has joined #yocto19:23
*** lsandov1 <lsandov1!c8448bdf@> has joined #yocto19:28
*** lsandov1 <lsandov1!c8448bdf@> has left #yocto19:29
*** lsandov1 <lsandov1!c8448bdf@> has joined #yocto19:29
*** tlwoerner <tlwoerner!~Trevor@unaffiliated/tlwoerner> has quit IRC19:49
*** Saur <Saur!pkj@nat/axis/x-khlpywkqyoqkzrzj> has joined #yocto20:04
*** tomjose <tomjose!~tomjose@> has joined #yocto20:07
*** fatalhalt <fatalhalt!~fatalhalt@2601:244:4d01:52df:225:90ff:feda:2428> has joined #yocto20:08
*** geissonator <geissonator!~geissonat@> has joined #yocto20:09
*** blauskaerm <blauskaerm!~blauskaer@> has quit IRC20:09
*** camus <camus!~Instantbi@> has joined #yocto20:14
*** kaspter <kaspter!~Instantbi@> has quit IRC20:14
*** camus is now known as kaspter20:14
*** lfa_ <lfa_!> has joined #yocto20:15
*** lfa <lfa!> has quit IRC20:17
*** davidinux1 <davidinux1!~davidinux@> has joined #yocto20:18
*** davidinux1 <davidinux1!~davidinux@> has quit IRC20:24
*** davidinux1 <davidinux1!~davidinux@> has joined #yocto20:26
*** davidinux1 <davidinux1!~davidinux@> has quit IRC20:30
*** asteriusio <asteriusio!> has quit IRC20:33
*** Shikadi <Shikadi!> has joined #yocto20:34
*** linums <linums!~linums@> has quit IRC20:42
*** linums <linums!> has joined #yocto20:43
*** gpanders <gpanders!> has joined #yocto20:46
*** linums <linums!> has quit IRC20:47
*** linums <linums!~linums@> has joined #yocto20:47
*** kpo_ <kpo_!> has quit IRC20:52
*** kpo_ <kpo_!> has joined #yocto20:53
*** asteriusio <asteriusio!> has joined #yocto20:59
*** linums <linums!~linums@> has quit IRC20:59
*** linums <linums!> has joined #yocto21:00
*** linums <linums!> has quit IRC21:09
*** linums <linums!~linums@> has joined #yocto21:09
*** emrius <emrius!> has joined #yocto21:10
emriusHey everyone, one of my recipes inherits setuptools3 to build a python package. I would like to pass something to it's Best would be an environment variable. How can I set a variable so that it can be accessed by the
*** linums <linums!~linums@> has quit IRC21:25
*** linums <linums!~linums@> has joined #yocto21:27
*** mbulut <mbulut!> has quit IRC21:44
*** beneth <beneth!> has left #yocto22:10
*** emrius <emrius!> has quit IRC22:10
*** tlwoerner <tlwoerner!~Trevor@unaffiliated/tlwoerner> has joined #yocto22:13
*** B0ned1ger <B0ned1ger!> has quit IRC22:23
*** B0ned1ger2 <B0ned1ger2!> has joined #yocto22:23
*** juvenal <juvenal!> has quit IRC22:23
*** leon-anavi <leon-anavi!~Leon@> has quit IRC22:25
*** rabbit9911 <rabbit9911!> has quit IRC22:28
*** juvenal <juvenal!> has joined #yocto22:30
*** mrc3 <mrc3!~mrc3@linaro/mrc3> has quit IRC22:42
*** kaspter <kaspter!~Instantbi@> has quit IRC22:45
*** kaspter <kaspter!~Instantbi@> has joined #yocto22:45
*** T_UNIX <T_UNIX!> has quit IRC22:49
*** lfa_ <lfa_!> has quit IRC22:54
*** B0ned1ger2 <B0ned1ger2!> has quit IRC22:54
*** mrc3 <mrc3!~mrc3@linaro/mrc3> has joined #yocto22:55
*** linums <linums!~linums@> has quit IRC23:17
*** linums <linums!> has joined #yocto23:17
*** linums <linums!> has quit IRC23:24
*** linums <linums!~linums@> has joined #yocto23:25

Generated by 2.17.2 by Marius Gedminas - find it at!