| *** linums <linums!~linums@apn-94-44-253-155.vodafone.hu> has quit IRC | 00:05 | |
| *** linums <linums!~linums@84.198.214.27> has joined #yocto | 00:06 | |
| *** agust1 <agust1!~agust@p5483339b.dip0.t-ipconnect.de> has quit IRC | 00:16 | |
| *** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC | 00:18 | |
| *** ericch <ericch!~ericch@pool-108-34-251-214.prvdri.fios.verizon.net> has quit IRC | 00:18 | |
| *** asteriusio <asteriusio!~derek@104-179-196-18.lightspeed.brhmal.sbcglobal.net> has quit IRC | 00:18 | |
| *** asteriusio <asteriusio!~derek@104-179-196-18.lightspeed.brhmal.sbcglobal.net> has joined #yocto | 00:19 | |
| *** dev1990 <dev1990!~dev@dynamic-78-8-233-105.ssp.dialog.net.pl> has quit IRC | 00:29 | |
| *** asteriusio <asteriusio!~derek@104-179-196-18.lightspeed.brhmal.sbcglobal.net> has quit IRC | 00:36 | |
| *** camus <camus!~Instantbi@58.246.136.202> has joined #yocto | 00:46 | |
| *** kaspter <kaspter!~Instantbi@58.246.136.202> has quit IRC | 00:46 | |
| *** camus is now known as kaspter | 00:46 | |
| *** kpo_ <kpo_!~kpo@bwu34.internetdsl.tpnet.pl> has quit IRC | 00:50 | |
| *** kpo_ <kpo_!~kpo@bwu34.internetdsl.tpnet.pl> has joined #yocto | 00:51 | |
| *** asteriusio <asteriusio!~derek@104-179-196-18.lightspeed.brhmal.sbcglobal.net> has joined #yocto | 00:52 | |
| *** ahadi <ahadi!~ahadi@89.244.126.54> has quit IRC | 00:53 | |
| *** risca <risca!~quassel@212.85.71.156> has quit IRC | 00:54 | |
| *** ahadi <ahadi!~ahadi@89.244.126.54> has joined #yocto | 00:56 | |
| *** erbo <erbo!~erik@linode.unixshell.se> has quit IRC | 00:56 | |
| *** erbo <erbo!~erik@linode.unixshell.se> has joined #yocto | 00:56 | |
| *** risca <risca!~quassel@212.85.71.156> has joined #yocto | 00:56 | |
| *** adelcast <adelcast!~adelcast@cpe-70-123-151-98.austin.res.rr.com> has quit IRC | 01:03 | |
| *** camus <camus!~Instantbi@58.246.136.202> has joined #yocto | 01:26 | |
| *** kaspter <kaspter!~Instantbi@58.246.136.202> has quit IRC | 01:26 | |
| *** camus is now known as kaspter | 01:26 | |
| *** rcrudo <rcrudo!~rcrudo@2001:16b8:c214:e500:6bf:5a7f:3cd8:619e> has quit IRC | 01:26 | |
| *** vineela <vineela!~vtummala@134.134.137.75> has quit IRC | 01:28 | |
| *** vineela <vineela!~vtummala@134.134.137.75> has joined #yocto | 01:29 | |
| *** vineela <vineela!~vtummala@134.134.137.75> has quit IRC | 01:30 | |
| *** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has quit IRC | 01:53 | |
| *** nerdboy <nerdboy!~sarnold@47.143.129.81> has joined #yocto | 02:05 | |
| *** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has joined #yocto | 02:05 | |
| *** willy__ <willy__!~willy@d154-20-165-119.bchsia.telus.net> has quit IRC | 02:08 | |
| *** marka <marka!~marka@198-84-181-245.cpe.teksavvy.com> has quit IRC | 02:09 | |
| *** marka <marka!~marka@198-84-181-245.cpe.teksavvy.com> has joined #yocto | 02:10 | |
| *** eduardas <eduardas!~eduardas@78-61-200-153.static.zebra.lt> has quit IRC | 02:30 | |
| *** rcw <rcw!~rcwoolley@157.52.1.76> has quit IRC | 02:36 | |
| *** oberstet <oberstet!~oberstet@213.170.219.39> has quit IRC | 02:49 | |
| *** linums <linums!~linums@84.198.214.27> has quit IRC | 03:02 | |
| *** linums <linums!~linums@apn-94-44-249-51.vodafone.hu> has joined #yocto | 03:04 | |
| *** ahadi <ahadi!~ahadi@89.244.126.54> has quit IRC | 03:08 | |
| *** ahadi_ <ahadi_!~ahadi@i5E86ACA2.versanet.de> has joined #yocto | 03:08 | |
| *** linums <linums!~linums@apn-94-44-249-51.vodafone.hu> has quit IRC | 03:16 | |
| *** linums <linums!~linums@84.198.214.27> has joined #yocto | 03:16 | |
| *** Klox04809318631 <Klox04809318631!~Klox@c-24-1-131-19.hsd1.il.comcast.net> has quit IRC | 03:55 | |
| *** rcrudo <rcrudo!~rcrudo@2001:16b8:c275:7e00:5b7b:48af:39cf:89c6> has joined #yocto | 04:01 | |
| *** rcrudo <rcrudo!~rcrudo@2001:16b8:c275:7e00:5b7b:48af:39cf:89c6> has quit IRC | 04:10 | |
| *** rcrudo <rcrudo!~rcrudo@2001:16b8:c27d:d00:37e1:5a51:e0d9:efdf> has joined #yocto | 04:12 | |
| *** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has quit IRC | 04:13 | |
| *** Klox04809318631 <Klox04809318631!~Klox@c-24-1-131-19.hsd1.il.comcast.net> has joined #yocto | 04:13 | |
| *** gonkulator <gonkulator!~brandon@75.71.150.20> has quit IRC | 04:15 | |
| *** gonkulator <gonkulator!~brandon@75.71.150.20> has joined #yocto | 04:22 | |
| *** camus <camus!~Instantbi@58.246.136.202> has joined #yocto | 04:25 | |
| *** kaspter <kaspter!~Instantbi@58.246.136.202> has quit IRC | 04:25 | |
| *** camus is now known as kaspter | 04:25 | |
| *** Klox04809318631 <Klox04809318631!~Klox@c-24-1-131-19.hsd1.il.comcast.net> has quit IRC | 04:26 | |
| *** Klox04809318631 <Klox04809318631!~Klox@c-24-1-131-19.hsd1.il.comcast.net> has joined #yocto | 04:27 | |
| *** gonkulator <gonkulator!~brandon@75.71.150.20> has quit IRC | 04:28 | |
| *** gonkulator <gonkulator!~brandon@75.71.150.20> has joined #yocto | 04:39 | |
| *** camus <camus!~Instantbi@58.246.136.202> has joined #yocto | 04:47 | |
| *** kaspter <kaspter!~Instantbi@58.246.136.202> has quit IRC | 04:48 | |
| *** camus is now known as kaspter | 04:48 | |
| *** georgem_home <georgem_home!uid210681@gateway/web/irccloud.com/x-eiioszbxlyzlfqgo> has quit IRC | 04:49 | |
| *** amitk <amitk!~amit@unaffiliated/amitk> has joined #yocto | 05:25 | |
| *** willy__ <willy__!~willy@node-1w7jr9qkgk55bb1txp6190hif.ipv6.telus.net> has joined #yocto | 05:26 | |
| *** matthewzmd <matthewzmd!~user@72.138.138.18> has quit IRC | 05:31 | |
| *** willy_ <willy_!~willy@node-1w7jr9qkgk55bari5g7tswimn.ipv6.telus.net> has joined #yocto | 05:32 | |
| *** willy__ <willy__!~willy@node-1w7jr9qkgk55bb1txp6190hif.ipv6.telus.net> has quit IRC | 05:36 | |
| *** camus <camus!~Instantbi@58.246.136.202> has joined #yocto | 05:36 | |
| *** willy__ <willy__!~willy@node-1w7jr9qkgk55ckuubo3eektbr.ipv6.telus.net> has joined #yocto | 05:37 | |
| *** kaspter <kaspter!~Instantbi@58.246.136.202> has quit IRC | 05:37 | |
| *** camus is now known as kaspter | 05:37 | |
| *** willy_ <willy_!~willy@node-1w7jr9qkgk55bari5g7tswimn.ipv6.telus.net> has quit IRC | 05:41 | |
| *** willy__ <willy__!~willy@node-1w7jr9qkgk55ckuubo3eektbr.ipv6.telus.net> has quit IRC | 05:45 | |
| tlwoerner | on Dec 3 the first running of a new conference targeted at embedded (linux) development will occur: https://liveembedded.virtualconference.com/ | 05:49 |
|---|---|---|
| tlwoerner | my understanding is that the conference is organized by a group of embedded companies including Bootlin (for example) | 05:50 |
| tlwoerner | there are several OE/Yocto talks: https://liveembedded.virtualconference.com/#/agenda | 05:50 |
| tlwoerner | the conference schedule mostly aligns with European timezones | 05:51 |
| *** tomjose <tomjose!~tomjose@129.41.86.5> has quit IRC | 05:57 | |
| *** amitk_ <amitk_!~amit@unaffiliated/amitk> has joined #yocto | 06:05 | |
| *** amitk <amitk!~amit@unaffiliated/amitk> has quit IRC | 06:08 | |
| *** tomjose <tomjose!~tomjose@129.41.86.5> has joined #yocto | 06:16 | |
| *** amitk <amitk!~amit@unaffiliated/amitk> has joined #yocto | 06:19 | |
| *** amitk_ <amitk_!~amit@unaffiliated/amitk> has quit IRC | 06:22 | |
| *** davidinux <davidinux!~davidinux@82.102.21.244> has joined #yocto | 06:23 | |
| *** amitk_ <amitk_!~amit@unaffiliated/amitk> has joined #yocto | 06:24 | |
| *** AndersD <AndersD!~AndersD@h83-209-96-136.cust.a3fiber.se> has joined #yocto | 06:26 | |
| *** amitk <amitk!~amit@unaffiliated/amitk> has quit IRC | 06:27 | |
| *** AndersD_ <AndersD_!~AndersD@h-17-226.A137.corp.bahnhof.se> has joined #yocto | 06:29 | |
| *** AndersD <AndersD!~AndersD@h83-209-96-136.cust.a3fiber.se> has quit IRC | 06:31 | |
| *** B0ned1ger <B0ned1ger!~B0ned1ger@82-135-139-249.static.zebra.lt> has joined #yocto | 06:32 | |
| *** rcoote <rcoote!~rcoote@221-224-024-217.ip-addr.vsenet.de> has joined #yocto | 06:32 | |
| *** amitk <amitk!~amit@unaffiliated/amitk> has joined #yocto | 06:42 | |
| *** beneth <beneth!~beneth@irc.beneth.fr> has joined #yocto | 06:43 | |
| *** amitk_ <amitk_!~amit@unaffiliated/amitk> has quit IRC | 06:45 | |
| *** jobroe <jobroe!~manjaro-u@p579eb746.dip0.t-ipconnect.de> has joined #yocto | 06:46 | |
| *** mihai <mihai!~mihai@unaffiliated/mihai> has joined #yocto | 07:00 | |
| *** rob_w <rob_w!~rob@unaffiliated/rob-w/x-1112029> has joined #yocto | 07:02 | |
| *** tomjose <tomjose!~tomjose@129.41.86.5> has quit IRC | 07:05 | |
| *** pharaon2502 <pharaon2502!~manjaro-u@cpezg-94-253-139-105-cbl.xnet.hr> has joined #yocto | 07:06 | |
| *** geissonator <geissonator!~geissonat@129.41.86.5> has quit IRC | 07:09 | |
| *** agust <agust!~agust@p5483339b.dip0.t-ipconnect.de> has joined #yocto | 07:11 | |
| *** blauskaerm <blauskaerm!~blauskaer@185.204.1.183> has joined #yocto | 07:11 | |
| *** iceaway <iceaway!~pelle@c188-149-179-85.bredband.comhem.se> has joined #yocto | 07:12 | |
| blauskaerm | Is 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 |
| blauskaerm | I 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 |
| mihai | blauskaerm: depending on where `netcat` is needed, where would the small script run | 07:18 |
| iceaway | blauskaerm: Can you add the required package to DEPENDS? | 07:18 |
| blauskaerm | mihai: It runs just after boot in multi-user mode | 07:20 |
| blauskaerm | iceaway: That could be a solution? Is DEPENDS used to give dependacy during build or can it be used for my situation too? | 07:20 |
| blauskaerm | dependency* | 07:20 |
| mihai | blauskaerm: then you can add netcat to RDEPENDS variable, which will require netcat to be installed on the target when your script is also installed | 07:21 |
| *** fatalhalt_ <fatalhalt_!~fatalhalt@c-67-163-60-93.hsd1.il.comcast.net> has quit IRC | 07:21 | |
| blauskaerm | Looks like what I'm looking for! | 07:22 |
| blauskaerm | Thank you very much mihai :) | 07:22 |
| mihai | blauskaerm: np | 07:22 |
| mihai | blauskaerm: the complete variable specification to use is RDEPENDS_${PN} | 07:23 |
| mihai | https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#var-RDEPENDS | 07:23 |
| *** rcrudo <rcrudo!~rcrudo@2001:16b8:c27d:d00:37e1:5a51:e0d9:efdf> has quit IRC | 07:24 | |
| iceaway | I 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 the | 07: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 |
| iceaway | This 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@58.246.136.202> has quit IRC | 07:32 | |
| *** kaspter <kaspter!~Instantbi@58.246.136.202> has joined #yocto | 07:33 | |
| *** tomjose <tomjose!~tomjose@129.41.86.5> has joined #yocto | 07:36 | |
| *** frsc <frsc!~frsc@i6DFA830E.versanet.de> has joined #yocto | 07:44 | |
| *** LetoThe2nd <LetoThe2nd!uid453638@gateway/web/irccloud.com/x-xhomhlmhgeidrpeh> has joined #yocto | 07:49 | |
| *** geissonator <geissonator!~geissonat@129.41.86.5> has joined #yocto | 07:55 | |
| *** wertigon <wertigon!~per@c-6d61225c.021-396-7673741.bbcust.telenor.se> has joined #yocto | 07:56 | |
| wertigon | Hey! Having a weird compile problem I cannot seem to resolve no matter what I do | 07:56 |
| *** Shikadi <Shikadi!~Shikadi@135.30.27.136.in-addr.arpa> has quit IRC | 07:57 | |
| wertigon | WARNING: lz4-native-1_1.9.2-r0 do_fetch: Failed to fetch URL git://github.com/lz4/lz4.git, attempting MIRRORS if available | 07:57 |
| *** gsalazar <gsalazar!955a6fad@gateway/web/cgi-irc/kiwiirc.com/ip.149.90.111.173> has joined #yocto | 07:59 | |
| wertigon | I can get this repo no problem manually | 08:00 |
| *** fl0v0 <fl0v0!~fvo@89.244.122.39> has joined #yocto | 08:00 | |
| mihai | wertigon: what's the compile problem? that's a fetch warning :) | 08:05 |
| mihai | maybe you can pastebin it somewhere | 08:05 |
| wertigon | Ok, it's a fetch warning; it then complains about no other mirrors having the expected commit hash | 08:06 |
| wertigon | And then proceeds to say there is no source at all | 08:06 |
| *** mckoan|away is now known as mckoan | 08:06 | |
| mckoan | good morning | 08:06 |
| mihai | 'morning | 08:07 |
| mihai | wertigon: maybe you're trying to use a commit from another branch, in which case you need to also specify the branch | 08:08 |
| *** kpo_ <kpo_!~kpo@bwu34.internetdsl.tpnet.pl> has quit IRC | 08:08 | |
| *** kpo_ <kpo_!~kpo@bwu34.internetdsl.tpnet.pl> has joined #yocto | 08:08 | |
| wertigon | https://pastebin.com/3erq28vY <-- Full pastebin of error | 08:08 |
| wertigon | Yeah, maybe | 08:08 |
| wertigon | Thing is this worked perfectly before... Hmmmm... | 08:09 |
| wertigon | Could it be that upstream changed name of master branch? | 08:10 |
| *** habing_ <habing_!~habing@2a02:8388:6c0:1200:269c:52c3:be0c:e984> has joined #yocto | 08:10 | |
| wertigon | ... Yes, this actually seems to be the reason! | 08:12 |
| wertigon | https://github.com/lz4/lz4/branches/all | 08:13 |
| wertigon | master branch deleted, dev branch is now default | 08:13 |
| *** rcrudo <rcrudo!~rcrudo@83.135.244.64> has joined #yocto | 08:14 | |
| LetoThe2nd | *lesigh* | 08:15 |
| LetoThe2nd | wertigon: care to report a bug if this is still present on dunfell and/or master? | 08:16 |
| wertigon | I think it is present on dunfell | 08:18 |
| LetoThe2nd | wertigon: can you file a bug then? | 08:18 |
| wertigon | Absolutely, either this was introduced recently or lz4 is not used that often | 08:19 |
| LetoThe2nd | mcfrisk: 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!~dev@dynamic-78-8-233-105.ssp.dialog.net.pl> has joined #yocto | 08:20 | |
| LetoThe2nd | wertigon: 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 |
| wertigon | Yeah, this was broken a couple of days ago | 08:23 |
| wertigon | I did a clean rebuild a couple of days ago because it's what you must do | 08:24 |
| wertigon | Every month or so we do clean rebuilds to catch errors like these, I mean | 08:25 |
| mcfrisk | LetoThe2nd: sure, I could have a chat | 08:26 |
| wertigon | Should the bug be filed under meta-yocto, oe-core or other? | 08:28 |
| *** TuxBlackEdo <TuxBlackEdo!~Default@unaffiliated/tuxblackedo> has quit IRC | 08:29 | |
| *** T_UNIX <T_UNIX!~T_UNIX@HSI-KBW-109-192-195-138.hsi6.kabel-badenwuerttemberg.de> has joined #yocto | 08:29 | |
| *** davidinux <davidinux!~davidinux@82.102.21.244> has quit IRC | 08:33 | |
| *** davidinux <davidinux!~davidinux@109.116.24.241> has joined #yocto | 08:36 | |
| LetoThe2nd | wertigon: oe-core | 08:37 |
| *** leon-anavi <leon-anavi!~Leon@78.130.197.211> has joined #yocto | 08:40 | |
| *** eduardas <eduardas!~eduardas@78-61-200-153.static.zebra.lt> has joined #yocto | 08:51 | |
| *** megabread <megabread!~megabread@2a01:4b00:e031:2600:9d36:e023:61e7:b8cd> has joined #yocto | 08:57 | |
| wertigon | LetoThe2nd: https://bugzilla.yoctoproject.org/show_bug.cgi?id=14135 | 09:02 |
| *** ginj <ginj!~Ginj@84-107-180-76.cable.dynamic.v4.ziggo.nl> has quit IRC | 09:02 | |
| LetoThe2nd | wertigon: great, thank you very much! | 09:03 |
| wertigon | LetoThe2nd: I also included the quick fix for it :) | 09:06 |
| LetoThe2nd | wertigon: for additional brownie points, send a patch to the oe-core ML :) | 09:08 |
| *** geissonator <geissonator!~geissonat@129.41.86.5> has quit IRC | 09:17 | |
| *** tomjose <tomjose!~tomjose@129.41.86.5> has quit IRC | 09:17 | |
| *** w00die <w00die!~w00die@212.91.255.186> has quit IRC | 09:17 | |
| *** w00die <w00die!~w00die@212.91.255.186> has joined #yocto | 09:19 | |
| *** mckoan_ <mckoan_!~marco@unaffiliated/mckoan> has joined #yocto | 09:23 | |
| *** mckoan <mckoan!~marco@unaffiliated/mckoan> has quit IRC | 09:27 | |
| *** mckoan_ <mckoan_!~marco@unaffiliated/mckoan> has quit IRC | 09:30 | |
| *** mckoan <mckoan!~marco@unaffiliated/mckoan> has joined #yocto | 09:31 | |
| *** B0ned1ger <B0ned1ger!~B0ned1ger@82-135-139-249.static.zebra.lt> has quit IRC | 09:32 | |
| *** B0ned1ger2 <B0ned1ger2!~B0ned1ger@82-135-139-249.static.zebra.lt> has joined #yocto | 09:32 | |
| *** otavio <otavio!~otavio@debian/developer/otavio> has quit IRC | 09:32 | |
| *** Dracos-Carazza <Dracos-Carazza!~Dracos-Ca@94.31.98.213> has quit IRC | 09:42 | |
| *** Dracos-Carazza <Dracos-Carazza!~Dracos-Ca@94.31.98.213> has joined #yocto | 09:44 | |
| *** thecomet <thecomet!~thecomet@212-51-148-26.fiber7.init7.net> has joined #yocto | 09:45 | |
| thecomet | So 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 stuck | 09:46 |
| thecomet | What can I do? | 09:46 |
| wertigon | thecomet: Easiest is to just delete tmp-glibc and re-run | 09:47 |
| wertigon | It'll cost you a bit of time | 09:47 |
| thecomet | Will my workspace/sources directory still be in tact or will I have to run devtool modify again? | 09:48 |
| wertigon | No idea if there is a more elegant solution out there :) | 09:48 |
| wertigon | Yes, only delete tmp-glibc in the build folder | 09:48 |
| *** oberstet <oberstet!~oberstet@213.170.219.39> has joined #yocto | 09:49 | |
| wertigon | I think there is a bitbake command in there somewhere, but no idea where, how or when. | 09:49 |
| carlsb3rg | the bitbake server is a python process, isn't it? | 09:49 |
| carlsb3rg | think I recall killing a python process to force a hung bitbake process | 09:50 |
| *** awaisb <awaisb!~quassel@110.93.212.98> has joined #yocto | 09:50 | |
| *** abelal <abelal!~quassel@110.93.212.98> has quit IRC | 09:51 | |
| thecomet | I deleted build/bitbake.lock and that seems to have fixed it | 09:52 |
| thecomet | I should have probably checked for python processes first though, oops | 09:52 |
| RP | kanavin_home: should I stop that f33 reproducible build? | 09:55 |
| kanavin_home | RP: it seems like diffoscope chokes on large items, let me take a look | 10:03 |
| *** Yumasi <Yumasi!~guillaume@2a01cb09b06b29ea391191835a81a7a2.ipv6.abo.wanadoo.fr> has joined #yocto | 10:03 | |
| kanavin_home | RP: 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 fully | 10:04 |
| cengiz_io | hello. what are the possible unwanted side effects of having a very high BBFILE_PRIORITY on your custom layer? | 10:10 |
| cengiz_io | I'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-mylayer | 10:11 |
| cengiz_io | and log.do_unpack picks other layer's bbappend due to my layer priority. | 10:11 |
| qschulz | cengiz_io: highest prio will be applied last provided the paths in SRC_URI are identical | 10:12 |
| cengiz_io | SRC_URI's are identical | 10:13 |
| qschulz | cengiz_io: triple check your paths, quadruple check your FILESEXTRAPATHS_prepend := | 10:13 |
| qschulz | cengiz_io: and check that your bbappend is actually applied (there's a bitbake-layers command for that IIRC) | 10:14 |
| cengiz_io | qschulz I did copy the exact bbappend and files. didn't even rename them. | 10:14 |
| cengiz_io | qschulz it's definitely being added to search path, as I see it in do_unpack logs. | 10:15 |
| qschulz | cengiz_io: shouldn't do_unpack only list the paths it failed to find a file in? | 10:15 |
| cengiz_io | hmm | 10:16 |
| cengiz_io | here's a snippet of it. | 10:16 |
| *** zandrey <zandrey!~zandrey@193.8.40.126> has joined #yocto | 10:18 | |
| cengiz_io | DEBUG: 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_io | if the order is relevant to priority, my layer is skipped | 10:19 |
| cengiz_io | NOTE: Unpacking /yocto/meta-agl/meta-agl-profile-core/recipes-core/psplash/files/psplash-poky-img.h | 10:19 |
| cengiz_io | meta-agl-profile-core has priority of 80, meta-mylayer has 20 | 10:20 |
| *** B0ned1ger2 <B0ned1ger2!~B0ned1ger@82-135-139-249.static.zebra.lt> has quit IRC | 10:22 | |
| *** B0ned1ger <B0ned1ger!~B0ned1ger@82-135-139-249.static.zebra.lt> has joined #yocto | 10:23 | |
| qschulz | cengiz_io: there you go: https://docs.yoctoproject.org/ref-manual/ref-variables.html#term-BBFILE_PRIORITY | 10:24 |
| qschulz | meta-mylayer has lower prio | 10:25 |
| cengiz_io | yeah I've changed it to 80 will see if my PV will let me override it | 10:26 |
| cengiz_io | qschulz equalizing the priority and adding SRCREV = "${AUTOREV}" \n PV = "1.00+git${SRCPV}" did the trick | 10:33 |
| cengiz_io | qschulz with too high priority it wasn't compiling. | 10:34 |
| qschulz | cengiz_io: don't use AUTOREV for production ;) | 10:36 |
| cengiz_io | qschulz don't really care | 10:36 |
| qschulz | cengiz_io: if the order or priority breaks your build, your layer needs to be reworked | 10:36 |
| qschulz | (or AGL's) | 10:36 |
| cengiz_io | qschulz you're probably right but I'm out of willpower and time | 10:39 |
| cengiz_io | btw what's wrong with AUTOREV? I already commit each change to my layer | 10:40 |
| cengiz_io | and what else do you suggest? hardcoded rev? | 10:40 |
| *** kaspter <kaspter!~Instantbi@58.246.136.202> has quit IRC | 10:41 | |
| rcrudo | is there an yocto example to install python packages from the source and without pypi? | 10:41 |
| *** kaspter <kaspter!~Instantbi@58.246.136.202> has joined #yocto | 10:41 | |
| rcrudo | I meant recipe example | 10:43 |
| *** davidinux <davidinux!~davidinux@109.116.24.241> has quit IRC | 10:43 | |
| *** davidinux <davidinux!~davidinux@217.138.197.44> has joined #yocto | 10:45 | |
| *** Dracos-Carazza_ <Dracos-Carazza_!~Dracos-Ca@94.31.98.213> has joined #yocto | 10:46 | |
| cengiz_io | rcrudo did you check openembedded recipe search? | 10:46 |
| cengiz_io | python recipes are very scarce though | 10:47 |
| *** Dracos-Carazza <Dracos-Carazza!~Dracos-Ca@94.31.98.213> has quit IRC | 10:47 | |
| *** geissonator <geissonator!~geissonat@129.41.86.5> has joined #yocto | 10:47 | |
| rcrudo | cengiz_io: yes, they all seems to use pypi | 10:48 |
| qschulz | cengiz_io: the point of a build system is to be able to rebuild an image years after it was originally built | 10:50 |
| qschulz | AUTOREV means that yoiu'll never be able to do that because it'll always fetch the last commit | 10:50 |
| paulbarker | rcrudo: I know bmap-tools isn't published on pypi so you may be able to find a recipe for that | 10:52 |
| cengiz_io | qschulz indeed. but I'm not frozen my build yet. | 10:52 |
| paulbarker | rcrudo: If your python source has a `setup.py` file it's usually pretty simple to make a recipe for it | 10:53 |
| rcrudo | paulbarker: bmap-tools looks like a good example, thanks | 10:55 |
| wyre | what's intended the distribution layer for? https://imgur.com/lqQreTs.png | 10:58 |
| *** Dracos-Carazza_ is now known as Dracos-Carazza | 10:59 | |
| LetoThe2nd | wyre: 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 |
| RP | kanavin_home: ok. I figured it was stuck in diffoscope :/ | 11:02 |
| *** tomjose <tomjose!~tomjose@129.41.86.5> has joined #yocto | 11:04 | |
| *** geissonator <geissonator!~geissonat@129.41.86.5> has quit IRC | 11:05 | |
| cengiz_io | anyone seen this before? ` error: 'POKY_IMG_WIDTH' undeclared (first use in this function); did you mean 'BAR_IMG_WIDTH'?` | 11:09 |
| cengiz_io | for the record, I'vve generated image header with https://git.yoctoproject.org/cgit/cgit.cgi/psplash/plain/make-image-header.sh script | 11:09 |
| cengiz_io | yikes. that script requires a second argument... | 11:11 |
| cengiz_io | nevermind me. | 11:11 |
| *** jonasbits <jonasbits!~quassel@2001:2002:4e48:1aca:908e:1969:c028:2e1d> has joined #yocto | 11:18 | |
| iceaway | I'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!~goliath@clnet-p04-043.ikbnet.co.at> has joined #yocto | 11:28 | |
| kanavin_home | RP: 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 packages | 11:32 |
| kanavin_home | and in any case, it should not run for this long | 11:32 |
| *** BobPungartnik <BobPungartnik!~BobPungar@177.41.198.185> has joined #yocto | 11:33 | |
| LetoThe2nd | iceaway: bitbake -e not being helpful? | 11:34 |
| RP | kanavin_home: that was the one which built the original packages so they would match | 11:34 |
| RP | (maybe?) | 11:34 |
| *** kayterina <kayterina!kayterina-@gateway/shell/matrix.org/x-bvltbzlvqhlrcgpn> has quit IRC | 11:34 | |
| *** clementp[m] <clementp[m]!cperonmatr@gateway/shell/matrix.org/x-clpwxvwotdtekdyy> has quit IRC | 11:34 | |
| *** xicopitz[m] <xicopitz[m]!xicopitzma@gateway/shell/matrix.org/x-htcdmswyfjthtfio> has quit IRC | 11:34 | |
| *** stefan-schmidt[m <stefan-schmidt[m!stefan-sch@gateway/shell/matrix.org/x-lfdqscvhbdwvyncc> has quit IRC | 11:34 | |
| *** yangm <yangm!yanyetanot@gateway/shell/matrix.org/x-gdupmrgdtkxeownx> has quit IRC | 11:34 | |
| *** hmw1 <hmw1!hmwmatrixo@gateway/shell/matrix.org/x-tzibhetykfgdlyhs> has quit IRC | 11:34 | |
| *** henriknj <henriknj!hnjematrix@gateway/shell/matrix.org/x-lmaewottjiweqqla> has quit IRC | 11:34 | |
| *** khem <khem!khemmatrix@gateway/shell/matrix.org/x-tufjrgvtmamaqimg> has quit IRC | 11:34 | |
| *** GonZo2k <GonZo2k!gonzo2000m@gateway/shell/matrix.org/x-jwxdbleqrtppeojn> has quit IRC | 11:34 | |
| *** nrossi <nrossi!nrossimatr@gateway/shell/matrix.org/x-fyyvvymcjuzockob> has quit IRC | 11:34 | |
| *** bachp <bachp!bachpmatri@gateway/shell/matrix.org/x-systgieqdnrabueb> has quit IRC | 11:35 | |
| *** silviof <silviof!silv-iomat@gateway/shell/matrix.org/x-geylapwejvrzuffd> has quit IRC | 11:35 | |
| *** cbrake1 <cbrake1!cbrakematr@gateway/shell/matrix.org/x-lqdbfwgyljhjqdyb> has quit IRC | 11:35 | |
| *** lexano[m] <lexano[m]!lexanomatr@gateway/shell/matrix.org/x-duuerdnbpenwykxu> has quit IRC | 11:35 | |
| *** ahadi_ <ahadi_!~ahadi@i5E86ACA2.versanet.de> has quit IRC | 11:37 | |
| *** tgoodwin[away] <tgoodwin[away]!~textual@pool-100-16-74-100.bltmmd.fios.verizon.net> has quit IRC | 11:37 | |
| *** gsalazar <gsalazar!955a6fad@gateway/web/cgi-irc/kiwiirc.com/ip.149.90.111.173> has quit IRC | 11:39 | |
| *** ahadi <ahadi!~ahadi@i5E86ACA2.versanet.de> has joined #yocto | 11:39 | |
| *** BobPungartnik <BobPungartnik!~BobPungar@177.41.198.185> has quit IRC | 11:40 | |
| *** tgoodwin <tgoodwin!~tgoodwin@pool-100-16-74-100.bltmmd.fios.verizon.net> has joined #yocto | 11:40 | |
| *** xicopitz[m] <xicopitz[m]!xicopitzma@gateway/shell/matrix.org/x-adjgrcsybyyxzhkt> has joined #yocto | 11:42 | |
| kanavin_home | RP: not sure I understand your explanation? the passing selftest was this one https://autobuilder.yoctoproject.org/typhoon/#/builders/80/builds/1580 | 11:45 |
| kanavin_home | one other selftest from a-full failed, and two others got stuck in diffoscope | 11:46 |
| kanavin_home | RP: ah nevermind | 11:47 |
| kanavin_home | I get it now: the passing selftest built packages from scratch and that matched | 11:47 |
| kanavin_home | when one of them comes from sstate, it may be mis-matching | 11:47 |
| kanavin_home | RP: the mystery is I guess why one other selftest failed, and two others got stuck | 11:48 |
| RP | kanavin_home: right, I'd guess it just depends which builders built the objects in sstate | 11:52 |
| kanavin_home | RP: the packages are all saved here for failing and cancelled ones | 11:53 |
| kanavin_home | https://autobuilder.yocto.io/pub/repro-fail/oe-reproducible-20201125-u6roxed2/packages/reproducibleA/tmp/deploy/ipk/core2-64/ | 11:53 |
| kanavin_home | https://autobuilder.yocto.io/pub/repro-fail/oe-reproducible-20201125-dnr1qh6w/packages/reproducibleA/tmp/deploy/ipk/core2-64/ | 11:53 |
| kanavin_home | I'll take a look what is different there, I guess diffoscope cannot handle enormously big items like llvm | 11:53 |
| *** gsalazar <gsalazar!955a6fad@gateway/web/cgi-irc/kiwiirc.com/ip.149.90.111.173> has joined #yocto | 11:53 | |
| *** clementp[m] <clementp[m]!cperonmatr@gateway/shell/matrix.org/x-ynpygwinysofrwxp> has joined #yocto | 11:56 | |
| *** bachp <bachp!bachpmatri@gateway/shell/matrix.org/x-hdcubdujvtkjvzmy> has joined #yocto | 11:56 | |
| *** stefan-schmidt[m <stefan-schmidt[m!stefan-sch@gateway/shell/matrix.org/x-szmvmpsqdsupdqgr> has joined #yocto | 11:56 | |
| *** hmw1 <hmw1!hmwmatrixo@gateway/shell/matrix.org/x-qtvtyhcmupwgfvxg> has joined #yocto | 11:56 | |
| *** nrossi <nrossi!nrossimatr@gateway/shell/matrix.org/x-azrkenjhkuwfgylf> has joined #yocto | 11:56 | |
| *** yangm <yangm!yanyetanot@gateway/shell/matrix.org/x-kyhecpokvqhfplra> has joined #yocto | 11:56 | |
| *** silviof <silviof!silv-iomat@gateway/shell/matrix.org/x-kjufdxmgpdvaagpn> has joined #yocto | 11:56 | |
| *** kayterina <kayterina!kayterina-@gateway/shell/matrix.org/x-wsxxrdjzbfzjnwlz> has joined #yocto | 11:56 | |
| *** GonZo2k <GonZo2k!gonzo2000m@gateway/shell/matrix.org/x-qmamymrbkvhvoalu> has joined #yocto | 11:56 | |
| *** khem <khem!khemmatrix@gateway/shell/matrix.org/x-dnpyqrvjinqlobmq> has joined #yocto | 11:56 | |
| *** henriknj <henriknj!hnjematrix@gateway/shell/matrix.org/x-pkqpyisidbgucrot> has joined #yocto | 11:56 | |
| *** cbrake1 <cbrake1!cbrakematr@gateway/shell/matrix.org/x-jnnhxfsbhyxlplek> has joined #yocto | 11:56 | |
| *** lexano[m] <lexano[m]!lexanomatr@gateway/shell/matrix.org/x-sibmvuozedpsgzxv> has joined #yocto | 11:56 | |
| RP | kanavin_home: right, it seems to have a problem when things get really large :/ | 11:56 |
| *** khem is now known as Guest11662 | 11:56 | |
| *** JaBen <JaBen!~Thunderbi@2a02:8109:86c0:1c58:bd52:f0ef:80f0:e69e> has joined #yocto | 12:00 | |
| *** tgoodwin <tgoodwin!~tgoodwin@pool-100-16-74-100.bltmmd.fios.verizon.net> has quit IRC | 12:04 | |
| *** otavio <otavio!~otavio@191-221-68-106.user3p.brasiltelecom.net.br> has joined #yocto | 12:13 | |
| *** otavio <otavio!~otavio@debian/developer/otavio> has joined #yocto | 12:13 | |
| *** B0ned1ger <B0ned1ger!~B0ned1ger@82-135-139-249.static.zebra.lt> has quit IRC | 12:23 | |
| *** B0ned1ger2 <B0ned1ger2!~B0ned1ger@82-135-139-249.static.zebra.lt> has joined #yocto | 12:23 | |
| *** geissonator <geissonator!~geissonat@129.41.86.5> has joined #yocto | 12: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. If | 12:26 |
| *** linums <linums!~linums@84.198.214.27> has quit IRC | 12:30 | |
| *** linums <linums!~linums@84.198.214.27> has joined #yocto | 12:30 | |
| JaBen | (found it: laking about the BBFILE_PRIORITY setting in the layer config) | 12:33 |
| JaBen | *talking | 12:33 |
| *** mckoan is now known as mckoan|away | 12:39 | |
| iceaway | LetoThe2nd: I was thinking more of in which script the PATH is configured, but maybe I can dig that out of bitbake -e? | 12:47 |
| LetoThe2nd | iceaway: if it is something that is dynamically set, then you can, yes. | 12:48 |
| qschulz | JaBen: I do not include their meta-layer and we do not keep up to date | 12:52 |
| qschulz | IoT industry does not care about upgrade sadly | 12:52 |
| qschulz | but you'd manually monitor changes to source git repos or layer git repos | 12:52 |
| qschulz | BSP component recipes rarely change so much that you can't just change SRCREV manually though | 12: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 layer | 12:55 |
| JaBen | ok, 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 |
| qschulz | JaBen: in which case you want to BBMASK everything you don't need AND make sure it's still ok to build later on | 13:05 |
| qschulz | JaBen: 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 |
| JaBen | ok, 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 |
| qschulz | JaBen: I'd rather spend time on debugging my own recipes based on vendor's BSP components than debugging their layers | 13:10 |
| qschulz | specifically, we add a shit ton of patches on top, so we anyway fork off the vendor;s | 13:11 |
| qschulz | JaBen: priority probably not but LAYERSERIES_COMPAT yeah | 13:11 |
| qschulz | though it's probably not meta-qt5 but the name of the BBCOLLECTIONS (qt5-layer maybe? don't remember) | 13:11 |
| *** gpanders <gpanders!~gpanders@c-98-32-4-57.hsd1.nm.comcast.net> has quit IRC | 13: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 :D | 13:14 |
| *** pbergin <pbergin!~pbergin@h-79-136-99-68.NA.cust.bahnhof.se> has joined #yocto | 13:16 | |
| rcrudo | How can set my yocto image to use python3 as default? I want to fix this: QA Issue: /usr/bin/hexmerge.py contained in package python3-intelhex requires /usr/bin/python | 13: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 |
| qschulz | rcrudo: shebang at the top of you script needs to have python3 in it | 13:20 |
| qschulz | rcrudo: and migrate the script to python3 if it was written for python2 | 13:20 |
| qschulz | JaBen: 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 |
| qschulz | JaBen: and if I had the choice I'd go 100% upstream | 13:22 |
| qschulz | but yeah, you see the maintenance burden | 13:22 |
| *** vineela <vineela!~vtummala@134.134.139.74> has joined #yocto | 13:24 | |
| *** dexterlb <dexterlb!~dexterlb@2a01:9e40:2:2::2> has quit IRC | 13:24 | |
| *** vineela <vineela!~vtummala@134.134.139.74> has quit IRC | 13:26 | |
| *** gpanders <gpanders!~gpanders@c-98-32-4-57.hsd1.nm.comcast.net> has joined #yocto | 13: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 |
| yann | in 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 |
| qschulz | JaBen: then in any other layer.coinf | 13:35 |
| JaBen | ok | 13:36 |
| JaBen | that seems to work :) | 13:37 |
| qschulz | subject to breakage ;) | 13:37 |
| *** pharaon2502 <pharaon2502!~manjaro-u@cpezg-94-253-139-105-cbl.xnet.hr> has quit IRC | 13:38 | |
| *** dexterlb <dexterlb!~dexterlb@2a01:9e40:2:2::2> has joined #yocto | 13:38 | |
| *** pharaon2502 <pharaon2502!~manjaro-u@cpezg-94-253-139-105-cbl.xnet.hr> has joined #yocto | 13: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 upstream | 13:44 |
| qschulz | JaBen: you can always work around priorities by splitting your layers into higher and lower prio compared to upstream layers you depend on | 13:45 |
| JaBen | true, but say you want to put an upstream layer at a higher priority than a second upstream layer | 13:47 |
| *** gpanders <gpanders!~gpanders@c-98-32-4-57.hsd1.nm.comcast.net> has quit IRC | 13:48 | |
| qschulz | JaBen: if they have same prio, the order in which they are included in bblayers.conf is the way to order your layers | 13:48 |
| JaBen | how to shitfix vendor layers 101: overwrite their compatibility setting and bbmask stuff until it builds! :D | 13: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 |
| qschulz | JaBen: IIRC yes | 13:52 |
| qschulz | but not for classes and conf files :p | 13:52 |
| qschulz | (the opposite) | 13:52 |
| JaBen | @qschulz well thats not confusing at all :P | 13:56 |
| qschulz | JaBen: 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 one | 13:57 |
| *** rcw <rcw!~rcwoolley@157.52.1.76> has joined #yocto | 13:58 | |
| *** linums <linums!~linums@84.198.214.27> has quit IRC | 14:03 | |
| *** linums <linums!~linums@apn-94-44-250-231.vodafone.hu> has joined #yocto | 14:05 | |
| *** linums <linums!~linums@apn-94-44-250-231.vodafone.hu> has quit IRC | 14:23 | |
| *** linums <linums!~linums@84.198.214.27> has joined #yocto | 14:24 | |
| rcrudo | qschulz: that is not my script. it's coming from pypi installation | 14:27 |
| *** geheimnis` <geheimnis`!~geheimnis@23.226.237.192> has quit IRC | 14:27 | |
| *** geheimnis` <geheimnis`!~geheimnis@23.226.237.192> has joined #yocto | 14:30 | |
| rcrudo | nvm, fixed with do_install_append | 14:35 |
| qschulz | rcrudo: 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 |
| rcrudo | I used do_install_append with a sed -> sed -i 's|#!/usr/bin/python|#!/usr/bin/python3|g' ${D}/usr/bin/*.py | 14:38 |
| qschulz | rcrudo: is it an exact match? | 14:40 |
| qschulz | because if your package is updated upstream one day, you might replace #!/usr/bin/python3 with #!/usr/bin/python33 | 14:41 |
| *** pbergin <pbergin!~pbergin@h-79-136-99-68.NA.cust.bahnhof.se> has quit IRC | 14:42 | |
| *** anoo1 <anoo1!~anoo1@129.41.86.5> has quit IRC | 14:42 | |
| *** tomjose <tomjose!~tomjose@129.41.86.5> has quit IRC | 14:42 | |
| *** geissonator <geissonator!~geissonat@129.41.86.5> has quit IRC | 14:43 | |
| rcrudo | qschulz: good point! thanks for the code review ;) | 14:44 |
| *** anoo1 <anoo1!~anoo1@129.41.86.5> has joined #yocto | 14:47 | |
| *** matthewcroughan_ <matthewcroughan_!~quassel@static.211.38.12.49.clients.your-server.de> has joined #yocto | 14:47 | |
| matthewcroughan_ | Hey :) | 14:47 |
| matthewcroughan_ | What are .in files in Yocto? | 14:47 |
| LetoThe2nd | oppostite of .out! | 14:48 |
| matthewcroughan_ | Ah, I thought it might have been related to .inc lol | 14:48 |
| LetoThe2nd | well 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 |
| qschulz | I think those are files that are supposed to be handled in Yocto to replace some variables? | 14:54 |
| qschulz | or sometimes by autotools or whatever | 14:54 |
| *** Yumasi <Yumasi!~guillaume@2a01cb09b06b29ea391191835a81a7a2.ipv6.abo.wanadoo.fr> has quit IRC | 14:56 | |
| *** Klox04809318631 <Klox04809318631!~Klox@c-24-1-131-19.hsd1.il.comcast.net> has quit IRC | 14: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 #yocto | 14:58 | |
| LetoThe2nd | huh? | 14:58 |
| LetoThe2nd | well sure autotools have Makefile.in 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 |
| LetoThe2nd | matthewcroughan_: 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. https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#creating-a-patch-for-the-fix | 15:00 |
| LetoThe2nd | (e.g.: you're missing context at the moment) | 15:00 |
| LetoThe2nd | ah. | 15:01 |
| LetoThe2nd | thats no "yocto" context, rather just "some generic whatever file somewhere in the package that has to be patched" | 15:01 |
| LetoThe2nd | or alternatively, "jsut some generic file that is used in some way in the package". | 15:02 |
| LetoThe2nd | but in no meaning it relates to the yocto build process - it is something package-internal. | 15:02 |
| LetoThe2nd | you 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_!~kpo@bwu34.internetdsl.tpnet.pl> has quit IRC | 15:05 | |
| *** kpo_ <kpo_!~kpo@bwu34.internetdsl.tpnet.pl> has joined #yocto | 15:05 | |
| matthewcroughan_ | LetoThe2nd: https://www.yoctoproject.org/docs/1.6/bitbake-user-manual/bitbake-user-manual.html#example-obtaining-bitbake | 15:06 |
| matthewcroughan_ | What would the purpose of MANIFEST.in be here then? | 15:07 |
| matthewcroughan_ | I just see these files around and wonder "Why does it have that extension? | 15:07 |
| LetoThe2nd | i 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!~Klox@c-24-1-131-19.hsd1.il.comcast.net> has joined #yocto | 15:11 | |
| *** linums <linums!~linums@84.198.214.27> has quit IRC | 15:11 | |
| *** linums <linums!~linums@apn-94-44-112-85.vodafone.hu> has joined #yocto | 15:13 | |
| LetoThe2nd | today i learned: https://packaging.python.org/guides/using-manifest-in/ | 15:13 |
| LetoThe2nd | matthewcroughan_: 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 context | 15:17 |
| *** frsc <frsc!~frsc@i6DFA830E.versanet.de> has quit IRC | 15:17 | |
| LetoThe2nd | absolutely and totally not. | 15:17 |
| matthewcroughan_ | what if you had a file like recipes-core/utils/ostree/ostree/ostree-daemon.in ? | 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 |
| qschulz | those are files included in recipes | 15:20 |
| LetoThe2nd | qschulz: note the second "ostree" in the path | 15:21 |
| LetoThe2nd | matthewcroughan_: 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 |
| LetoThe2nd | e.g.: doesn't relate to yocto | 15:22 |
| matthewcroughan_ | Okay, what *is* the recipe and what *is not* the recipe? | 15:23 |
| LetoThe2nd | matthewcroughan_: 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 |
| LetoThe2nd | matthewcroughan_: recipe: .bb | 15:23 |
| LetoThe2nd | matthewcroughan_: 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 |
| qschulz | LetoThe2nd: I saw it, hence my remark ;) (recipes-*/*/*.bb is the default so one too many subdir :) ) | 15:26 |
| LetoThe2nd | qschulz: which in turn means that it is in the default FILES searching path. | 15:27 |
| qschulz | matthewcroughan_: a .in file is nothing to yocto, it makes sense only for a software built by Yocto | 15:27 |
| qschulz | it's something you add to the sources of whatever you want to build | 15:27 |
| LetoThe2nd | matthewcroughan_: 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. https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#creating-a-patch-for-the-fix | 15:28 |
| * LetoThe2nd facepalms and is silent now. | 15:28 | |
| matthewcroughan_ | neard.service.in | 15:28 |
| matthewcroughan_ | what purpose does .in serve? Is it literally just convention? or does it serve a literal purpose? | 15:28 |
| zeddii | it's an automake concept. nothing to do with yocto. | 15:29 |
| zeddii | just 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 |
| qschulz | matthewcroughan_: hehehe no. .patch files will be applied to the source in order of their declaration in SRC_URI | 15:35 |
| matthewcroughan_ | okay, so bitbake *does* care about more than just .bb and .bbappend files? | 15:35 |
| qschulz | same for .diff | 15:35 |
| matthewcroughan_ | Is there a list of file extensions that are special to bitbake? :D | 15:36 |
| qschulz | matthewcroughan_: they're actually not special to bitbake, they're special to recipes built by bitbake | 15:36 |
| qschulz | .patch, .diff are applied by default | 15:36 |
| qschulz | some tarball extensions are automatically unpacked too | 15:36 |
| matthewcroughan_ | Is this behavior somewhere in the bitbake manual then? What should I search for? | 15:37 |
| qschulz | matthewcroughan_: if you want to understand everything that bitbake does, you're in for a long journey | 15:37 |
| qschulz | I haven't read thebitbake manuals even once | 15:37 |
| qschulz | though i should | 15:37 |
| qschulz | i've read the Yocto manuals though | 15:37 |
| qschulz | just start working on something simple and build your knowledge from there | 15:38 |
| matthewcroughan_ | That always works. Though I'm really not sure where the starting point is. | 15:38 |
| *** davidinux <davidinux!~davidinux@217.138.197.44> has quit IRC | 15:41 | |
| matthewcroughan_ | qschulz: What determines if a function is executed in a bitbake file? | 15:42 |
| *** lfa <lfa!~lfa@62-178-244-151.cable.dynamic.surfer.at> has joined #yocto | 15:42 | |
| matthewcroughan_ | By being defined, is it always ran? | 15:42 |
| *** anoo1 <anoo1!~anoo1@129.41.86.5> has quit IRC | 15: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@129.41.86.5> has joined #yocto | 15:46 | |
| matthewcroughan_ | Additionally, is there an importance to the `do_` in `do_thing` or is this again just naming convention? | 15:47 |
| qschulz | matthewcroughan_: tasks should start with do_, that's a convention | 15:48 |
| matthewcroughan_ | right, but it doesn't have any literal effect like vars do? | 15:48 |
| qschulz | you can have "normal" python or shell functions which aren't tasks too | 15: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 |
| qschulz | tasks aren't run (except the anonymous one) except asked | 15:48 |
| qschulz | "asked" can be by the user or through recipe or task dependencies | 15:49 |
| *** eduardas <eduardas!~eduardas@78-61-200-153.static.zebra.lt> has quit IRC | 15:53 | |
| stkw0 | is example.com down? bitbake is telling me I don't have internet connection but I have. It seems it connects to example.com and if it doesn't respond it exits | 15:56 |
| *** AndersD_ <AndersD_!~AndersD@h-17-226.A137.corp.bahnhof.se> has quit IRC | 16:02 | |
| JaBen | has 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 exists | 16:04 |
| LetoThe2nd | stkw0: https://downforeveryoneorjustme.com/example.com | 16:04 |
| stkw0 | LetoThe2nd: thanks, something is wrong with my computer, it doesn't resolve that domain specifically :( | 16:08 |
| JaBen | This is the file in question btw: https://github.com/analogdevicesinc/lnxdsp-adi-meta/blob/develop/yocto-1.0.1/meta-adi-adsp-sc5xx/recipes-kernel/linux/linux-adi_4.19.bb | 16:10 |
| JaBen | @stkw0 assuming unix-like, try setting a different dns server in /etc/resolv.conf for testing purposes ( e.g. 1.1.1.1) and see if the issue still persists. | 16:12 |
| stkw0 | JaBen: I did it, same problem. I also tried to use the phone and connect to example.com and chrome gives a DNS_PROBE_FINISHED_NXDOMAIN, I guess the ISP is doing something | 16:13 |
| JaBen | @stkw0: you could try running `dig example.com` and see which server is answering the request | 16:15 |
| stkw0 | using dnscrypt-proxy ""fix"" the issue | 16:16 |
| *** gnac <gnac!~gnac@or-71-0-52-80.sta.embarqhsd.net> has quit IRC | 16:16 | |
| stkw0 | JaBen: yeah, that is what I was trying, using dig with different dns servers, but none worked | 16:17 |
| JaBen | gotta love ISPs | 16:17 |
| *** tomjose <tomjose!~tomjose@129.41.86.5> has joined #yocto | 16:18 | |
| *** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has joined #yocto | 16:22 | |
| *** B0ned1ger2 <B0ned1ger2!~B0ned1ger@82-135-139-249.static.zebra.lt> has quit IRC | 16:23 | |
| *** B0ned1ger <B0ned1ger!~B0ned1ger@82-135-139-249.static.zebra.lt> has joined #yocto | 16:23 | |
| *** wertigon <wertigon!~per@c-6d61225c.021-396-7673741.bbcust.telenor.se> has quit IRC | 16:23 | |
| *** Yumasi <Yumasi!~guillaume@2a01:e0a:5cb:4430:5572:c108:3697:b06d> has quit IRC | 16:31 | |
| *** pharaon2502 <pharaon2502!~manjaro-u@cpezg-94-253-139-105-cbl.xnet.hr> has quit IRC | 16:31 | |
| *** amitk <amitk!~amit@unaffiliated/amitk> has quit IRC | 16:32 | |
| qschulz | JaBen: 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 |
| qschulz | JaBen: when does the error happen (which task?) | 16:48 |
| qschulz | JaBen: always blame the vendor before upstream :) | 16:49 |
| *** zandrey <zandrey!~zandrey@193.8.40.126> has quit IRC | 16: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: https://github.com/analogdevicesinc/lnxdsp-adi-meta/blob/develop/yocto-1.0.1/meta-adi-adsp-sc5xx/recipes-kernel/linux/linux-adi_4.19.bb | 16:51 |
| JaBen | the task failing is "do_kernel_metadata" | 16:54 |
| *** fl0v0 <fl0v0!~fvo@89.244.122.39> has quit IRC | 16:55 | |
| JaBen | @qschulz: complete log is here: https://paste.it-works-jbo.de/?ba6a4fc7f76e59b3#3LaUkCJTyreu5QX49PgtzAomCWBnTcXuw9GKezSUydF1 | 16:57 |
| qschulz | JaBen: first one in the list has a full path, not the others | 17:02 |
| qschulz | JaBen: just being curious, but what about adding all config fragments by hand (and not use features/ only) | 17:04 |
| *** w00die <w00die!~w00die@212.91.255.186> has quit IRC | 17:05 | |
| *** w00die <w00die!~w00die@212.91.255.186> has joined #yocto | 17:06 | |
| *** geissonator <geissonator!~geissonat@129.41.86.5> has joined #yocto | 17: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" worked | 17:09 |
| JaBen | @qschulz so I assume the parser at some point tries to interpret "feature/cfg/nfs.cfg" as a filename | 17:09 |
| JaBen | I see there has been a lot of change to do_kernel_metadata since thud | 17:11 |
| yann | I'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 |
| yann | looks like SRCPV is only set if the URI scheme matches a hardcoded list :( | 17:13 |
| yann | any reason needsrcrev is not defined by the fetcher ? | 17:14 |
| *** kaspter <kaspter!~Instantbi@58.246.136.202> has quit IRC | 17:20 | |
| *** kaspter <kaspter!~Instantbi@58.246.136.202> has joined #yocto | 17:20 | |
| *** thecomet <thecomet!~thecomet@212-51-148-26.fiber7.init7.net> has quit IRC | 17:25 | |
| *** habing_ <habing_!~habing@2a02:8388:6c0:1200:269c:52c3:be0c:e984> has quit IRC | 17:30 | |
| *** rcrudo <rcrudo!~rcrudo@83.135.244.64> has quit IRC | 17:31 | |
| qschulz | JaBen: I'm clueless sorry | 17:33 |
| qschulz | might want to send a mail or open a bug on bugzilla | 17:33 |
| *** kpo_ <kpo_!~kpo@bwu34.internetdsl.tpnet.pl> has quit IRC | 17:34 | |
| qschulz | (try to reproduce on linux-yocto from gatesgarth though before) | 17:34 |
| *** kpo_ <kpo_!~kpo@bwu34.internetdsl.tpnet.pl> has joined #yocto | 17:34 | |
| *** mckoan|away is now known as mckoan | 17: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 image | 17:45 |
| mckoan | how can I use recipetool setvar recipename.bb "-option" ? Looks like the dash gives an error | 17:45 |
| mckoan | and setvar recipename.bb -option doesn't work | 17:46 |
| *** mckoan is now known as mckoan|away | 17:52 | |
| *** linums <linums!~linums@apn-94-44-112-85.vodafone.hu> has quit IRC | 17:55 | |
| *** linums <linums!~linums@apn-94-44-112-85.vodafone.hu> has joined #yocto | 17:57 | |
| JaBen | @qschulz: ok, so the issue actually comes from these lines: https://github.com/analogdevicesinc/lnxdsp-adi-meta/blob/ad2203c11723b07727589a8eebe33f3129cc236a/meta-adi-adsp-sc5xx/recipes-kernel/linux/linux-adi_4.19.bb#L21-L24. So the error message is definitely misleading... | 18:00 |
| *** rob_w <rob_w!~rob@unaffiliated/rob-w/x-1112029> has quit IRC | 18:01 | |
| *** ssajal <ssajal!~ssajal@bras-base-otwaon1146w-grc-08-142-114-156-131.dsl.bell.ca> has quit IRC | 18:06 | |
| *** ssajal <ssajal!~ssajal@bras-base-otwaon1146w-grc-08-142-114-156-131.dsl.bell.ca> has joined #yocto | 18:08 | |
| *** rcoote <rcoote!~rcoote@221-224-024-217.ip-addr.vsenet.de> has quit IRC | 18:18 | |
| *** anoo1 <anoo1!~anoo1@129.41.86.5> has quit IRC | 18:18 | |
| *** geissonator <geissonator!~geissonat@129.41.86.5> has quit IRC | 18:19 | |
| *** tomjose <tomjose!~tomjose@129.41.86.5> has quit IRC | 18:20 | |
| *** anoo1 <anoo1!~anoo1@129.41.86.5> has joined #yocto | 18:21 | |
| *** mihai <mihai!~mihai@unaffiliated/mihai> has quit IRC | 18:22 | |
| *** gsalazar <gsalazar!955a6fad@gateway/web/cgi-irc/kiwiirc.com/ip.149.90.111.173> has quit IRC | 18: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 |
| neverpanic | No, stuff from SRC_URI has always been placed in WORKDIR, unless you manually specified a different destination | 18:36 |
| *** megabread <megabread!~megabread@2a01:4b00:e031:2600:9d36:e023:61e7:b8cd> has quit IRC | 18:39 | |
| *** linums <linums!~linums@apn-94-44-112-85.vodafone.hu> has quit IRC | 18:40 | |
| *** linums <linums!~linums@84.198.214.27> has joined #yocto | 18:42 | |
| *** linums <linums!~linums@84.198.214.27> has quit IRC | 18:46 | |
| *** jobroe <jobroe!~manjaro-u@p579eb746.dip0.t-ipconnect.de> has quit IRC | 18:49 | |
| *** linums <linums!~linums@84.198.214.27> has joined #yocto | 18:49 | |
| *** LetoThe2nd <LetoThe2nd!uid453638@gateway/web/irccloud.com/x-xhomhlmhgeidrpeh> has quit IRC | 18:50 | |
| rburton | JaBen: 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 tarball | 18:52 |
| *** camus <camus!~Instantbi@58.246.136.202> has joined #yocto | 18:59 | |
| *** kaspter <kaspter!~Instantbi@58.246.136.202> has quit IRC | 19:00 | |
| *** camus is now known as kaspter | 19:00 | |
| *** JaBen <JaBen!~Thunderbi@2a02:8109:86c0:1c58:bd52:f0ef:80f0:e69e> has quit IRC | 19:02 | |
| *** armpit <armpit!~armpit@2601:202:4180:a5c0:d0c2:4ffa:1fd8:ee96> has joined #yocto | 19:05 | |
| *** Saur <Saur!pkj@nat/axis/x-mkyufnjfzystsaac> has quit IRC | 19:22 | |
| *** mbulut <mbulut!~nameclash@ip1f110f5b.dynamic.kabel-deutschland.de> has joined #yocto | 19:23 | |
| *** lsandov1 <lsandov1!c8448bdf@200.68.139.223> has joined #yocto | 19:28 | |
| *** lsandov1 <lsandov1!c8448bdf@200.68.139.223> has left #yocto | 19:29 | |
| *** lsandov1 <lsandov1!c8448bdf@200.68.139.223> has joined #yocto | 19:29 | |
| *** tlwoerner <tlwoerner!~Trevor@unaffiliated/tlwoerner> has quit IRC | 19:49 | |
| *** Saur <Saur!pkj@nat/axis/x-khlpywkqyoqkzrzj> has joined #yocto | 20:04 | |
| *** tomjose <tomjose!~tomjose@129.41.86.5> has joined #yocto | 20:07 | |
| *** fatalhalt <fatalhalt!~fatalhalt@2601:244:4d01:52df:225:90ff:feda:2428> has joined #yocto | 20:08 | |
| *** geissonator <geissonator!~geissonat@129.41.86.5> has joined #yocto | 20:09 | |
| *** blauskaerm <blauskaerm!~blauskaer@185.204.1.183> has quit IRC | 20:09 | |
| *** camus <camus!~Instantbi@58.246.136.202> has joined #yocto | 20:14 | |
| *** kaspter <kaspter!~Instantbi@58.246.136.202> has quit IRC | 20:14 | |
| *** camus is now known as kaspter | 20:14 | |
| *** lfa_ <lfa_!~lfa@62-178-244-151.cable.dynamic.surfer.at> has joined #yocto | 20:15 | |
| *** lfa <lfa!~lfa@62-178-244-151.cable.dynamic.surfer.at> has quit IRC | 20:17 | |
| *** davidinux1 <davidinux1!~davidinux@37.120.201.244> has joined #yocto | 20:18 | |
| *** davidinux1 <davidinux1!~davidinux@37.120.201.244> has quit IRC | 20:24 | |
| *** davidinux1 <davidinux1!~davidinux@109.116.24.241> has joined #yocto | 20:26 | |
| *** davidinux1 <davidinux1!~davidinux@109.116.24.241> has quit IRC | 20:30 | |
| *** asteriusio <asteriusio!~derek@104-179-196-18.lightspeed.brhmal.sbcglobal.net> has quit IRC | 20:33 | |
| *** Shikadi <Shikadi!~Shikadi@135.30.27.136.in-addr.arpa> has joined #yocto | 20:34 | |
| *** linums <linums!~linums@84.198.214.27> has quit IRC | 20:42 | |
| *** linums <linums!~linums@apn-94-44-121-133.vodafone.hu> has joined #yocto | 20:43 | |
| *** gpanders <gpanders!~gpanders@c-98-32-4-57.hsd1.nm.comcast.net> has joined #yocto | 20:46 | |
| *** linums <linums!~linums@apn-94-44-121-133.vodafone.hu> has quit IRC | 20:47 | |
| *** linums <linums!~linums@84.198.214.27> has joined #yocto | 20:47 | |
| *** kpo_ <kpo_!~kpo@bwu34.internetdsl.tpnet.pl> has quit IRC | 20:52 | |
| *** kpo_ <kpo_!~kpo@bwu34.internetdsl.tpnet.pl> has joined #yocto | 20:53 | |
| *** asteriusio <asteriusio!~derek@104-179-196-18.lightspeed.brhmal.sbcglobal.net> has joined #yocto | 20:59 | |
| *** linums <linums!~linums@84.198.214.27> has quit IRC | 20:59 | |
| *** linums <linums!~linums@apn-94-44-121-133.vodafone.hu> has joined #yocto | 21:00 | |
| *** linums <linums!~linums@apn-94-44-121-133.vodafone.hu> has quit IRC | 21:09 | |
| *** linums <linums!~linums@84.198.214.27> has joined #yocto | 21:09 | |
| *** emrius <emrius!~emrius@dslb-088-064-250-061.088.064.pools.vodafone-ip.de> has joined #yocto | 21:10 | |
| emrius | Hey everyone, one of my recipes inherits setuptools3 to build a python package. I would like to pass something to it's setup.py. Best would be an environment variable. How can I set a variable so that it can be accessed by the setup.py? | 21:12 |
| *** linums <linums!~linums@84.198.214.27> has quit IRC | 21:25 | |
| *** linums <linums!~linums@84.198.214.27> has joined #yocto | 21:27 | |
| *** mbulut <mbulut!~nameclash@ip1f110f5b.dynamic.kabel-deutschland.de> has quit IRC | 21:44 | |
| *** beneth <beneth!~beneth@irc.beneth.fr> has left #yocto | 22:10 | |
| *** emrius <emrius!~emrius@dslb-088-064-250-061.088.064.pools.vodafone-ip.de> has quit IRC | 22:10 | |
| *** tlwoerner <tlwoerner!~Trevor@unaffiliated/tlwoerner> has joined #yocto | 22:13 | |
| *** B0ned1ger <B0ned1ger!~B0ned1ger@82-135-139-249.static.zebra.lt> has quit IRC | 22:23 | |
| *** B0ned1ger2 <B0ned1ger2!~B0ned1ger@82-135-139-249.static.zebra.lt> has joined #yocto | 22:23 | |
| *** juvenal <juvenal!juvenal@premium.znc.bg> has quit IRC | 22:23 | |
| *** leon-anavi <leon-anavi!~Leon@78.130.197.211> has quit IRC | 22:25 | |
| *** rabbit9911 <rabbit9911!~mprokos@ec2-52-25-23-41.us-west-2.compute.amazonaws.com> has quit IRC | 22:28 | |
| *** juvenal <juvenal!juvenal@premium.znc.bg> has joined #yocto | 22:30 | |
| *** mrc3 <mrc3!~mrc3@linaro/mrc3> has quit IRC | 22:42 | |
| *** kaspter <kaspter!~Instantbi@58.246.136.202> has quit IRC | 22:45 | |
| *** kaspter <kaspter!~Instantbi@58.246.136.202> has joined #yocto | 22:45 | |
| *** T_UNIX <T_UNIX!~T_UNIX@HSI-KBW-109-192-195-138.hsi6.kabel-badenwuerttemberg.de> has quit IRC | 22:49 | |
| *** lfa_ <lfa_!~lfa@62-178-244-151.cable.dynamic.surfer.at> has quit IRC | 22:54 | |
| *** B0ned1ger2 <B0ned1ger2!~B0ned1ger@82-135-139-249.static.zebra.lt> has quit IRC | 22:54 | |
| *** mrc3 <mrc3!~mrc3@linaro/mrc3> has joined #yocto | 22:55 | |
| *** linums <linums!~linums@84.198.214.27> has quit IRC | 23:17 | |
| *** linums <linums!~linums@apn-94-44-121-85.vodafone.hu> has joined #yocto | 23:17 | |
| *** linums <linums!~linums@apn-94-44-121-85.vodafone.hu> has quit IRC | 23:24 | |
| *** linums <linums!~linums@84.198.214.27> has joined #yocto | 23:25 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!
