*** rob_w__ <rob_w__!~bob@ppp-93-104-61-39.dynamic.mnet-online.de> has joined #yocto | 00:15 | |
*** splatch <splatch!~root@18.ip-217-182-76.eu> has quit IRC (Quit: Lost terminal) | 00:18 | |
*** rob_w_ <rob_w_!~bob@ppp-93-104-38-126.dynamic.mnet-online.de> has quit IRC (Ping timeout: 255 seconds) | 00:19 | |
*** nh00 <nh00!~nh00@208.84.155.39> has quit IRC (Quit: Client closed) | 00:26 | |
*** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Ping timeout: 258 seconds) | 00:29 | |
*** camus1 <camus1!~Instantbi@58.246.136.202> has joined #yocto | 00:30 | |
*** camus1 is now known as camus | 00:32 | |
*** nh00 <nh00!~nh00@208.84.155.39> has joined #yocto | 00:39 | |
*** nh00 <nh00!~nh00@208.84.155.39> has quit IRC (Client Quit) | 00:39 | |
*** camus1 <camus1!~Instantbi@58.246.136.202> has joined #yocto | 00:42 | |
*** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Ping timeout: 258 seconds) | 00:43 | |
*** camus1 is now known as camus | 00:43 | |
*** BuZZ-T <BuZZ-T!~basti@IP-185189140137.dynamic.medianet-world.de> has joined #yocto | 00:54 | |
*** camus1 <camus1!~Instantbi@58.246.136.202> has joined #yocto | 01:02 | |
*** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Read error: Connection reset by peer) | 01:03 | |
*** camus1 is now known as camus | 01:03 | |
*** hpsy1 <hpsy1!~hpsy@85.203.15.17> has joined #yocto | 01:25 | |
*** camus1 <camus1!~Instantbi@58.246.136.202> has joined #yocto | 01:26 | |
*** hpsy <hpsy!~hpsy@85.203.15.12> has quit IRC (Ping timeout: 240 seconds) | 01:27 | |
*** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Ping timeout: 252 seconds) | 01:28 | |
*** camus1 is now known as camus | 01:28 | |
*** leo_sandoval <leo_sandoval!~leo_sando@200.68.166.51> has quit IRC (Quit: Client closed) | 01:41 | |
*** camus1 <camus1!~Instantbi@58.246.136.202> has joined #yocto | 01:59 | |
*** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Ping timeout: 252 seconds) | 02:01 | |
*** camus1 is now known as camus | 02:01 | |
*** hpsy <hpsy!~hpsy@85.203.15.12> has joined #yocto | 02:02 | |
*** hpsy1 <hpsy1!~hpsy@85.203.15.17> has quit IRC (Ping timeout: 246 seconds) | 02:03 | |
*** patrick-r <patrick-r!~patrick-r@cpc142184-mcam2-2-0-cust140.18-3.cable.virginm.net> has joined #yocto | 02:23 | |
*** camus1 <camus1!~Instantbi@58.246.136.202> has joined #yocto | 02:31 | |
*** Tokamak <Tokamak!~Tokamak@107.117.203.211> has quit IRC (Ping timeout: 256 seconds) | 02:31 | |
*** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Ping timeout: 255 seconds) | 02:32 | |
*** camus1 is now known as camus | 02:32 | |
*** camus1 <camus1!~Instantbi@58.246.136.202> has joined #yocto | 02:58 | |
*** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Ping timeout: 255 seconds) | 02:59 | |
*** camus1 is now known as camus | 02:59 | |
*** amitk <amitk!~amit@103.208.69.178> has joined #yocto | 03:07 | |
*** jwillikers <jwillikers!~jwilliker@ics141-1.icsincorporated.com> has quit IRC (Remote host closed the connection) | 03:11 | |
*** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV) | 03:12 | |
*** roussinm <roussinm!~mroussin@bras-base-qubcpq1306w-grc-17-70-53-150-78.dsl.bell.ca> has quit IRC (Ping timeout: 272 seconds) | 03:30 | |
*** patrick-r <patrick-r!~patrick-r@cpc142184-mcam2-2-0-cust140.18-3.cable.virginm.net> has quit IRC (Quit: Client closed) | 04:28 | |
*** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Ping timeout: 272 seconds) | 05:02 | |
*** rob_w__ <rob_w__!~bob@ppp-93-104-61-39.dynamic.mnet-online.de> has quit IRC (Remote host closed the connection) | 05:19 | |
*** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has quit IRC (Quit: Client closed) | 05:37 | |
*** gioyik <gioyik!~gioyik@gateway/tor-sasl/gioyik> has quit IRC (Quit: WeeChat 3.1) | 05:50 | |
*** camus <camus!~Instantbi@58.246.136.202> has joined #yocto | 05:51 | |
*** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Quit: camus) | 05:58 | |
*** camus <camus!~Instantbi@58.246.136.202> has joined #yocto | 05:59 | |
*** rob_w <rob_w!~bob@host-82-135-31-73.customer.m-online.net> has joined #yocto | 06:18 | |
*** Schlumpf <Schlumpf!~Schlumpf@62.157.232.200> has joined #yocto | 06:22 | |
*** rob_w <rob_w!~bob@host-82-135-31-73.customer.m-online.net> has quit IRC (Ping timeout: 255 seconds) | 06:26 | |
*** rob_w <rob_w!~bob@host-82-135-31-73.customer.m-online.net> has joined #yocto | 06:26 | |
*** mckoan|away is now known as mckoan | 06:38 | |
dwagenk | Good morning! Has anyone taken note of https://lists.yoctoproject.org/g/yocto/topic/83622035#53936 ? I seem to be running into the same problem. At least the symptom xyz-src package is empty when xyz is worked on via devtool. | 06:38 |
---|---|---|
dwagenk | I'm using dunfell version. | 06:39 |
*** zyga <zyga!~zyga@31.0.173.147> has joined #yocto | 06:41 | |
*** rob_w <rob_w!~bob@host-82-135-31-73.customer.m-online.net> has quit IRC (Ping timeout: 272 seconds) | 06:55 | |
*** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Ping timeout: 272 seconds) | 06:58 | |
*** LetoThe2nd <LetoThe2nd!uid453638@id-453638.highgate.irccloud.com> has joined #yocto | 07:00 | |
*** florian_kc <florian_kc!~florian@78.48.73.53> has joined #yocto | 07:06 | |
LetoThe2nd | yo dudX | 07:07 |
*** rob_w <rob_w!~bob@host-82-135-31-73.customer.m-online.net> has joined #yocto | 07:08 | |
mckoan | LetoThe2nd: hey! | 07:09 |
*** camus <camus!~Instantbi@180.168.140.162> has joined #yocto | 07:10 | |
*** florian_kc <florian_kc!~florian@78.48.73.53> has quit IRC (Ping timeout: 255 seconds) | 07:11 | |
*** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has joined #yocto | 07:13 | |
*** splatch <splatch!~root@18.ip-217-182-76.eu> has joined #yocto | 07:16 | |
*** crawler <crawler!~crawler@user/crawler> has joined #yocto | 07:17 | |
splatch | hey, here I am back with same trouble as before, a failed intel-microcode update during the build. I have no clue why this happens, but it did work before with warrior (I haven't made any changes in this part, except rising meta-intel layer version). I keep getting exit code '2'. | 07:19 |
splatch | Writing selected microcodes to: /build/tmp/work/corei7-64-intel-common-connectorio-linux/intel-microcode/20210608-r0/microcode_20210608.bin | 07:19 |
splatch | /build/tmp/work/corei7-64-intel-common-connectorio-linux/intel-microcode/20210608-r0/microcode_20210608.bin: error while flushing file data: Input/output error | 07:19 |
*** rob_w <rob_w!~bob@host-82-135-31-73.customer.m-online.net> has quit IRC (Ping timeout: 258 seconds) | 07:20 | |
splatch | is my hard drive corrupted ? | 07:20 |
*** rob_w <rob_w!~bob@host-82-135-31-73.customer.m-online.net> has joined #yocto | 07:32 | |
*** manuel1985 <manuel1985!~manuel198@2a02:1748:dd5c:f290:21ee:3e44:58ef:e6d0> has joined #yocto | 07:34 | |
*** frieder <frieder!~frieder@i6DFA814D.versanet.de> has joined #yocto | 07:38 | |
*** leon-anavi <leon-anavi!~Leon@78.130.197.211> has joined #yocto | 07:40 | |
*** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has joined #yocto | 07:41 | |
*** ilunev <ilunev!~koolkhel@80.72.17.178> has joined #yocto | 07:41 | |
*** ilunev <ilunev!~koolkhel@80.72.17.178> has quit IRC (Client Quit) | 07:44 | |
splatch | filesystem check done, doing clean build once again | 07:46 |
rburton | Looks like the disk is failing, check smart status | 07:50 |
splatch | could be, I have nvme+f2fs setup from 2016 which proven to be very fast but also a bit fragile on power drops. Anyhow fsck reported no errors and I see no issues with microcode. Now I am back to host contamination on a fresh build. I have feeling this is going to be a long day. | 07:53 |
splatch | > Currently 2 running tasks (3656 of 3685) 99% | 08:13 |
*** rob_w <rob_w!~bob@host-82-135-31-73.customer.m-online.net> has quit IRC (Ping timeout: 246 seconds) | 08:14 | |
splatch | The host contamination was in fact taking place cause my recipe used cp -r, manual did answer it: https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#ref-tasks-install, leaving it here so IRS archives for future generations will contain this note in one more place! :) | 08:14 |
*** rob_w <rob_w!~bob@host-82-135-31-73.customer.m-online.net> has joined #yocto | 08:26 | |
*** rob_w <rob_w!~bob@host-82-135-31-73.customer.m-online.net> has quit IRC (Ping timeout: 272 seconds) | 08:39 | |
rburton | yeah, don't use cp, use install. | 08:52 |
*** rob_w <rob_w!~bob@host-82-135-31-73.customer.m-online.net> has joined #yocto | 08:52 | |
timbert[m] | Hey! Is there a way to use project version from CMake inside a bitbake recipe (without writing a parser for CMakeLists.txt 😉 )? | 08:54 |
LetoThe2nd | timbert[m]: use what for? | 08:55 |
timbert[m] | <LetoThe2nd "timbert: use what for?"> I want to use the project version from CMake as PV variable | 08:56 |
LetoThe2nd | timbert[m]: in that case, no. | 08:56 |
LetoThe2nd | timbert[m]: how would bitbake obtain it without fetching source? | 08:57 |
timbert[m] | <LetoThe2nd "timbert: how would bitbake obtai"> You are right, it can not get the version without the sources. But maybe there is a way of lazy evaluation to set PV after fetching the sources. | 08:58 |
LetoThe2nd | timbert[m]: nope. | 08:59 |
timbert[m] | <LetoThe2nd "timbert: nope."> I was able to set PV from a plain text file located at the source code, but I found no way to do this with cmake.bbclass | 09:02 |
qschulz | timbert[m]: how? | 09:03 |
LetoThe2nd | timbert[m]: you can happily set the pv inside the recipe to whatever you want, but once it relies on the source being present its an outright bug. no way discussing that away. | 09:04 |
LetoThe2nd | timbert[m]: and even worse, if it includes actually executing code you are effectively breaking reproducibility. so you might have a hack that works for your one usecase, ok. but this is not the general design of things, and it is explicitly unsupported. | 09:05 |
rburton | so you *can* set PKGV during the build but you need to set PV before the build, so you don't really gain anything | 09:06 |
LetoThe2nd | qschulz: i guess by having the source not fetches seperately but shipped next to the recipe, or something similar. | 09:06 |
LetoThe2nd | e.g. source+metadata conglomeration | 09:06 |
rburton | in that world, setting PKGV would make sense | 09:07 |
timbert[m] | <LetoThe2nd "qschulz: i guess by having the s"> Excatly. I have layers and source code as submodules. | 09:07 |
timbert[m] | > <@LetoThe2nd:libera.chat> qschulz: i guess by having the source not fetches seperately but shipped next to the recipe, or something similar. | 09:07 |
timbert[m] | * Exactly. I have layers and source code as submodules. | 09:07 |
LetoThe2nd | *shrug* | 09:07 |
rburton | you still need to parse the cmakefile though | 09:07 |
rburton | unless cmake can tell you what the version is | 09:07 |
LetoThe2nd | in which case you would have a hidden dependency on cmake during parse time. | 09:08 |
rburton | no, you can set PKGV later | 09:08 |
rburton | in a do_package prefunc | 09:08 |
LetoThe2nd | rburton: but how does this relate to PV? how could i do a PREFERRED_VERSION if the version is not even known until the packaging is finished? | 09:09 |
rburton | you still need a PV for the recipe | 09:09 |
rburton | but that can be 1.0 | 09:09 |
rburton | during the build PKGV can be set to the real version | 09:09 |
rburton | PREFERRED_VERSION will only look at PV, that's the compromise | 09:10 |
LetoThe2nd | so PKGV is actually only put into the package for the stream? no idea why i would want that. | 09:10 |
*** vmeson <vmeson!~rmacleod@198-48-226-187.cpe.pppoe.ca> has quit IRC (Ping timeout: 240 seconds) | 09:10 | |
rburton | yeah | 09:10 |
rburton | i doubt its actually used much, but you might want to mangle versions | 09:10 |
*** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has quit IRC (Ping timeout: 246 seconds) | 09:11 | |
rburton | nothing in core at least explicitly uses it, it all relies on the default (which is obviously PV) | 09:11 |
LetoThe2nd | i can see it being useful for some forms of distribution management where you feed package repositories, but certainly not for orchestrating an image build. | 09:11 |
rburton | so in meta-oe there's a gitpkgv.bbclass which lets you have ugly PV but rewrite PKGV to include tag names | 09:12 |
rburton | but i *think* the bulk of that logic is in core now anyway? | 09:13 |
LetoThe2nd | rburton: good luck with that (thinking) | 09:14 |
*** vmeson <vmeson!~rmacleod@198-48-226-187.cpe.pppoe.ca> has joined #yocto | 09:17 | |
*** hpsy <hpsy!~hpsy@85.203.15.12> has quit IRC (Quit: Leaving.) | 09:18 | |
*** Falital <Falital!~Falital@ip-178-203-146-237.hsi10.unitymediagroup.de> has joined #yocto | 09:19 | |
qschulz | rburton: and would Yocto use that PKGV for version-specific RDEPENDS? | 09:19 |
qschulz | rburton: RDEPENDS_${PN} = "package (operator version)" is what I'm talking about | 09:20 |
BuZZ-T | is anyone here using eclipse for development in the "pre Eclipse Yocto Plugin" era? | 09:25 |
BuZZ-T | eh.. i mean in the "post Eclipse Yocto Plugin" era :) | 09:27 |
*** camus1 <camus1!~Instantbi@222.65.17.208> has joined #yocto | 09:36 | |
*** camus <camus!~Instantbi@180.168.140.162> has quit IRC (Ping timeout: 255 seconds) | 09:38 | |
*** camus <camus!~Instantbi@58.246.136.202> has joined #yocto | 09:38 | |
*** rob_w <rob_w!~bob@host-82-135-31-73.customer.m-online.net> has quit IRC (Ping timeout: 272 seconds) | 09:39 | |
*** camus1 <camus1!~Instantbi@222.65.17.208> has quit IRC (Ping timeout: 252 seconds) | 09:40 | |
*** bizulk <bizulk!~bizulk@68.64.140.88.rev.sfr.net> has joined #yocto | 09:48 | |
bizulk | Hello. I have an issue building for raspberry pi 1 (host x86_64 ubuntu 20) : task poky/meta/recipes-devtools/gcc/gcc-cross_11.1.bb:do_compile | 09:49 |
bizulk | I have a lot of undefined reference like this one : build-rpi/tmp/hosttools/ld: lto-lang.c:(.text+0x3279): undefined reference to `builtin_info' | 09:50 |
*** rob_w <rob_w!~bob@host-82-135-31-73.customer.m-online.net> has joined #yocto | 09:52 | |
*** BuZZ-T <BuZZ-T!~basti@IP-185189140137.dynamic.medianet-world.de> has quit IRC (Quit: BuZZ-T has left the building...) | 09:52 | |
*** BuZZ-T <BuZZ-T!~basti@IP-185189140137.dynamic.medianet-world.de> has joined #yocto | 09:52 | |
*** Schlumpf <Schlumpf!~Schlumpf@62.157.232.200> has quit IRC (Quit: Client closed) | 09:53 | |
bizulk | I am using master branch | 09:55 |
*** bizulk72 <bizulk72!~bizulk@68.64.140.88.rev.sfr.net> has joined #yocto | 10:07 | |
*** bizulk <bizulk!~bizulk@68.64.140.88.rev.sfr.net> has quit IRC (Ping timeout: 246 seconds) | 10:08 | |
*** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has quit IRC (Quit: ZZZzzz…) | 10:09 | |
bizulk72 | there is a tip that I would like to test : "build glibc without static PIE support", but how can I do that | 10:16 |
*** crawler <crawler!~crawler@user/crawler> has quit IRC (Remote host closed the connection) | 10:16 | |
*** lukma <lukma!~lukma@85-222-111-42.dynamic.chello.pl> has joined #yocto | 10:21 | |
splatch | BuZZ-T: I don't do any C stuff, so I am set with regular text editor. If you need debuging capabilities I believe you have all necessary tools in Eclipse CDT. I am not sure what yocto plugin used to do as information available online is fairly limited. | 10:26 |
lukma | Dear All, I do have the question regarding 'uninative'. As fair as I see, by default (in the poky.conf) require conf/distro/include/yocto-uninative.inc is inherited. Moreover, I do know that for eSDK this uninative is used to build its "host" tools. I do have a question then - is this libc version used also for "normal" built of -native packages for using bitbake ? | 10:29 |
lukma | In the link: http://downloads.yoctoproject.org/releases/uninative/3.1/ the ARM (32 bit) is missing, but this is built by eSDK, so no issues | 10:32 |
rburton | ah, yeah, no 32-bit arm uninative tarball. | 10:33 |
rburton | i'd say 1) please file a bug and 2) you can turn off uninative | 10:33 |
rburton | the primary use of uninative is so that a set of different distributions can reuse the same native sstate. | 10:33 |
lukma | rburton: But I want to use uninative | 10:34 |
lukma | the goal is to have singled "native" set of sstate built packages | 10:34 |
rburton | then definitely (1), and make your own tarball that you use for now | 10:34 |
*** sayo9394 <sayo9394!~sim@182-239-133-199.tpgi.com.au> has joined #yocto | 10:35 | |
lukma | rburton: I'm just not 100% sure if uninative is used by default | 10:35 |
rburton | poky uses uninative, yes | 10:35 |
lukma | for example when I want to build core-image-minimal for beaglebone reference board | 10:35 |
rburton | uninative is *native*, target isn't relevant | 10:35 |
lukma | will it used the uninative libc, which in turn will produce the same set of -native tools | 10:36 |
rburton | yes | 10:36 |
lukma | which then I could reuse on the same setup deployed on e.g. Fedora build host ? | 10:36 |
rburton | if you use uninative, the native sstate can be shared between different build host distributions | 10:37 |
rburton | that's the purpose of it | 10:37 |
lukma | rburton: And by default uninative is enabled in poky distro ? | 10:37 |
rburton | yes | 10:37 |
lukma | rburton: Thanks for the clarification :-) | 10:37 |
bizulk72 | here is the pastbin, it does seem there is a link missing : https://pastebin.com/25yXqdAH | 10:37 |
rburton | it was created to share sstate on the autobuilder | 10:37 |
lukma | That was uncrear for me ... | 10:38 |
*** crawler <crawler!~crawler@user/crawler> has joined #yocto | 10:38 | |
rburton | the first thing you said was that poky uses uninative ;) | 10:38 |
rburton | are you actually doing a build on a 32-bit arm host? | 10:38 |
lukma | rburton: It is a bit more tricky .... | 10:39 |
lukma | I do have poky, which runs on debian 10 | 10:39 |
lukma | and this poky uses meta-virtualization layer | 10:39 |
lukma | to build the OCI container | 10:39 |
rburton | but none of that is relevant to your point of 'there is no 32-bit arm uninative' | 10:39 |
rburton | which is why I think you're confused | 10:40 |
rburton | or, hopefully, were confused | 10:40 |
lukma | so I guess that this container uses libc, which was built with uninative poky libc | 10:40 |
lukma | and this container would also need to have eSDK set of tools installed in it | 10:40 |
lukma | and the eSDK would be for ARM 32 bit targets | 10:41 |
lukma | So I would like to have everything built starting from single sources of libc | 10:41 |
lukma | the uninative libc -> (can be prebuilt for ARM 32 bit and x86_64) | 10:42 |
RP | lukma: are you ever trying to run builds (i.e. ibitbake) on a 32 bit arm system? If not, you don't need a 32 bit arm uninative | 10:42 |
lukma | so in that way (hopefully) I would have OCI container agnostic from the Host OS on which it is going to be run :-) | 10:42 |
rburton | but the eSDK grabs uninative if its being used, does it not? | 10:43 |
rburton | lukma: the only reason esdk uses uninative is so that sstate is sharable. honestly, you can probably just turn it off | 10:44 |
lukma | RP: rburton: From the code, yes, eSDK installs the uninative container on the host on which is it installed | 10:44 |
RP | eSDK can only run on the platform it was built on | 10:44 |
lukma | RP: That is the problem - I need to wrap eSDK into OCI container, so it would be Host OS agnostic | 10:45 |
rburton | Pretty sure you're confusing things again. Just turn off uninative :) | 10:45 |
RP | lukma: what do you mean by host agnostic? What is different about the hosts? | 10:46 |
RP | There is a bug with eSDK and pseudo-native atm :( | 10:46 |
lukma | RP: I build the eSDK on Debian, but then somebody else loves Fedora and would like to install eSDK on it | 10:46 |
rburton | (I do think that uninative should be something we enable on the autobuilder but not in poky out of the box) | 10:46 |
RP | https://bugzilla.yoctoproject.org/show_bug.cgi?id=14428 | 10:47 |
lukma | Now it is not possible | 10:47 |
lukma | but with eSDK wrapped to OCI container :-) | 10:47 |
lukma | he/she just runs it from there | 10:47 |
RP | lukma: right, the above open bug? | 10:47 |
lukma | RP: Yes, this is the bug | 10:47 |
RP | lukma: if you run your build of the eSDK in the container environment, the eSDK should then work in that container environment even with the above bug | 10:48 |
RP | or help us fix the above bug... | 10:48 |
lukma | RP: I also thought about the workaround: Create OCI container with Poky for x86_64 | 10:49 |
lukma | then in the bitbake recipe run this container with bindings to the yocto build directories | 10:50 |
lukma | execute the bitbake populate_sdk_ext | 10:50 |
lukma | (so it would use the sysroot + -native stuff from the OCI container) | 10:51 |
lukma | and then install it with the installer | 10:51 |
lukma | the questions are as follows: | 10:51 |
lukma | 1. Will bitbake allow/correctly handle running container it ist task (like "build" task) ? | 10:51 |
lukma | 2. Have anybody tried to use --bind container option with bitbake? | 10:52 |
RP | lukma: bitbake will run in a container fine. Just don't try and run bits of the build in the container and bits outside | 10:52 |
RP | and I do think certain bind mount options will cause problems due to the way bitbake uses the filesystem. Exactly what issues those are I don't know, mostly related to copy-on-write | 10:53 |
rburton | fwiw, the crops container guide explicitly says to bind your build directory into the container | 10:54 |
lukma | RP: Do you have any idea how and if it would be possible to add OCI container (as a "skin") to yocto/OE build ? | 10:54 |
rburton | lukma: http://git.yoctoproject.org/cgit/cgit.cgi/meta-virtualization/tree/classes/image-oci.bbclass? | 10:54 |
rburton | or do you mean build-inside-a-container | 10:55 |
rburton | look at crops for prior art | 10:55 |
rburton | or kas, which has a kas-docker script | 10:55 |
lukma | rburton: Yes, I'm using the http://git.yoctoproject.org/cgit/cgit.cgi/meta-virtualization/tree/classes/image-oci.bbclass to create the OCI container | 10:56 |
lukma | IMHO I would also need to "wrap" in some way bitbake populate_sdk_ext into the OCI container (bo build it into it and install) | 10:57 |
lukma | that would solve this problem | 10:57 |
RP | lukma: it would be way easier just to fix pseudo ;-) | 10:58 |
lukma | and as a result I would have the OCI container with eSDK built inside it and it installed. | 10:58 |
lukma | RP: Maybe you are right :-) I will look into the bug report ... | 10:58 |
lukma | but I need a backup plan | 10:58 |
rburton | lukma: core-image-base, also make it depend on the populate_sdk_ext task, then in a rootfs-post-process install the eSDK into it | 10:59 |
rburton | easy | 10:59 |
*** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Ping timeout: 258 seconds) | 10:59 | |
lukma | RP: But this bug has "High major" Importance.... | 10:59 |
*** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has joined #yocto | 11:00 | |
RP | lukma: right, we're aware this is a major problem and I'm going to need to try and fix it | 11:02 |
RP | lukma: it was reasigned to me yesterday as there is nobody else to work on it (or any other esdk bug) | 11:02 |
lukma | RP: So you are the "one" :) | 11:03 |
qschulz | rburton: and now I'm quite confused. What's the difference between pyrex and kas-container then :D ? | 11:03 |
rburton | qschulz: well kas-container comes with kas built in :) | 11:03 |
RP | lukma: I'm more than a little frustrated and saddened we have nobody working on the esdk :( | 11:04 |
lukma | RP: From my perspective - eSDK is the first tool, which is seen by developer | 11:04 |
lukma | externa or internal | 11:04 |
RP | lukma: well, yes. Hence my feelings on the subject. How do we encourage people to help though? | 11:05 |
paulg | bribes? | 11:05 |
RP | paulg: wish I had the capability :) | 11:07 |
qschulz | rburton: that I figured, but I'm not using kas yet, thus I'm more interested in what makes them different outside of kas :p | 11:09 |
rburton | can the LF stump up £100 to anyone who sends a merged patch that fixes it :) | 11:09 |
rburton | qschulz: i imagine, pyrex/kas/crops containers are all 99% identical (just the build deps), it's the little bit of glue that makes them different | 11:09 |
*** jwillikers <jwillikers!~jwilliker@2604:2800:2:a403:fe91:ac3e:5153:1290> has joined #yocto | 11:13 | |
RP | ndec: could we have bug bounties? :) | 11:25 |
RP | rburton: would be YP itself rather than the LF, no idea if we could so that | 11:25 |
rburton | the return of bug bounties could be fun | 11:26 |
*** zyga <zyga!~zyga@31.0.173.147> has quit IRC (Ping timeout: 240 seconds) | 11:26 | |
*** bizulk72 <bizulk72!~bizulk@68.64.140.88.rev.sfr.net> has quit IRC (Quit: Client closed) | 11:38 | |
mihai | http://www.quickmeme.com/img/ac/acc34ea8aaa78d7d8df53cf2d51f46f522498f8f3c1b93aeb076408e0b764236.jpg | 11:42 |
*** zyga <zyga!~zyga@31.0.173.147> has joined #yocto | 11:48 | |
BuZZ-T | splatch: the yocto plugin provided a convient way to create autotools, cmake and make file projects from eclipse. It has setup the correct PATH a.s.o. to build/deploy and debug the binaries generated in eclipse. Thats what it has done. | 11:51 |
BuZZ-T | splatch: But I made a few steps in the right direction, i'm able to setup the automake projects using the eSDK way.. when eclipse started from a "sourced" sdk environment, then the build and debug with is working with a few tweaks. | 11:52 |
BuZZ-T | its not what our devs were used to too, but at least i know that eclipse is generally usable. | 11:53 |
RP | rburton: did you work out why parted was intermittent? | 11:58 |
*** goliath <goliath!~goliath@user/goliath> has joined #yocto | 12:07 | |
*** rob_w <rob_w!~bob@host-82-135-31-73.customer.m-online.net> has quit IRC (Ping timeout: 255 seconds) | 12:08 | |
rburton | RP: no, didn't look. need a better way to mine the ptest logs | 12:18 |
*** rob_w <rob_w!~bob@host-82-135-31-73.customer.m-online.net> has joined #yocto | 12:21 | |
paulg | zeddii, if you are bored, you can probably nuke v5.10/standard/base-aufsv2 and v5.10/standard/base-noaufs ; we don't need them polluting the branch namespace, or reminders of that LTP/cgroup horror. | 12:24 |
yates | if i set BBFILES = "${TOPDIR}/*", does that mean .bbappend files of any base name will be incorporated from any level directory, recursively, under ${TOPDIR}? | 12:25 |
rburton | no | 12:25 |
yates | what is the syntax to specify that? | 12:25 |
yates | oh wait | 12:25 |
yates | i should be using ${LAYERDIR} | 12:26 |
rburton | the idiom is BBFILES += "${LAYERDIR}/recipes-*/*/*.bb ${LAYERDIR}/recipes-*/*/*.bbappend" | 12:26 |
* paulg needs to revisit the topic of nuking other old branch polluting cruft. | 12:26 | |
*** otavio <otavio!~otavio@200-203-25-205.user3p.brasiltelecom.net.br> has joined #yocto | 12:28 | |
yates | is BBFILES further constrained by BBFILE_PATTERN_{layer-name} in the layer's layer.conf file if it is present? | 12:30 |
yates | i guess i really don't see the use in the BBFILE_PATTERN variable. the layer's BBFILS are already specified by BBFILES | 12:32 |
yates | s/BBFILS/BBFILES/ | 12:33 |
rburton | no, pattern is the reverse lookup and idiom is just BBFILE_PATTERN_layername = "^${LAYERDIR}/" | 12:34 |
yates | there aren't just arbitray questions. i have a layer.conf file with both BBFILES and BBFILE_PATTERN_blah (as well as BBFILE_COLLECITONS and BBFILE_PRIORITY_blah) | 12:34 |
yates | arbitrary | 12:34 |
rburton | good | 12:34 |
rburton | you need all of those | 12:34 |
yates | ok, so what is their perpose/meaning? | 12:35 |
yates | sheesh. can't type today (or spell) | 12:35 |
rburton | BBFILES is "this is the glob to find files to parse" | 12:35 |
rburton | so the idiom is BBFILES += "${LAYERDIR}/recipes-*/*/*.bb" | 12:35 |
rburton | erm, and *.bbappend | 12:35 |
yates | right | 12:35 |
yates | what about BBFILE_PATTERN_blah? | 12:36 |
rburton | BBPATTERN is the reverse for finding the layer of an arbitrary file, because this stuff grew organically | 12:36 |
rburton | the idiom is eg BBFILE_PATTERN_core = "^${LAYERDIR}/" | 12:36 |
yates | ok well here is my layer's layer.conf: http://paste.ubuntu.com/p/s4cpy2mYrQ/ | 12:37 |
rburton | so i'd say you should have just used bitbake-layers instead of guessing what the variables were for | 12:37 |
rburton | bitbake-layers new-layer will create a new layer with the idiomatic values in the file | 12:38 |
rburton | BBFILES is recipes and appends, not classes | 12:38 |
yates | it appears a .bbappend in <yocto>/meta-csky/recipes-core/glibc/glibc-locale_2.32.bbappend is not being loaded | 12:39 |
rburton | use bitbake-layers to verify if its being parsed and just not doing what you expect, or not being parsed at all | 12:40 |
yates | ok let me read up on that utility | 12:40 |
*** rob_w <rob_w!~bob@host-82-135-31-73.customer.m-online.net> has quit IRC (Remote host closed the connection) | 12:45 | |
*** troth <troth!~troth@c-24-8-35-226.hsd1.co.comcast.net> has joined #yocto | 12:48 | |
Emantor | The mega-manual doesn't get any more updates, right? Is there another convenient one-page searchable option? | 13:09 |
rburton | the search button on https://docs.yoctoproject.org? | 13:13 |
Emantor | Search Button works, but I liked the "open mega-manual, Ctrl-F, next until relevant section" more since it didn't include page loads. | 13:14 |
rburton | i wonder if sphinx has a generate-one-huge-page button | 13:16 |
rburton | yes, -b singlehtml | 13:19 |
rburton | you could do that locally on the docs? | 13:19 |
JPEW | rburton, Emantor: It's published even: https://docs.yoctoproject.org/singleindex.html | 13:19 |
rburton | ah cool :) | 13:20 |
JPEW | Also selectable from the drop down menu at the top of the page :) | 13:20 |
rburton | oh yes! | 13:20 |
rburton | i looked but couldn't see it :) | 13:20 |
Emantor | Wonderful! | 13:20 |
qschulz | we decided to remove it from the left nav panel about a month ago I think | 13:20 |
qschulz | It used to be there too | 13:20 |
rburton | does anyone know tcl here? | 13:22 |
yates | rburton: you might try #emacs - there are a lot of eclectic and old-fart programmers there | 13:25 |
*** thekappe <thekappe!~user@198.90.66.177> has quit IRC (Ping timeout: 252 seconds) | 13:27 | |
rburton | i'm on #tcl which you'd think would be good | 13:27 |
*** thekappe <thekappe!~user@198.90.66.177> has joined #yocto | 13:28 | |
*** mckoan <mckoan!~marco@host-79-3-92-72.business.telecomitalia.it> has quit IRC (Ping timeout: 252 seconds) | 13:29 | |
*** mckoan <mckoan!~marco@host-79-3-92-72.business.telecomitalia.it> has joined #yocto | 13:29 | |
*** frieder <frieder!~frieder@i6DFA814D.versanet.de> has quit IRC (Remote host closed the connection) | 13:39 | |
*** kroon <kroon!~kroon@37-247-29-68.customers.ownit.se> has joined #yocto | 13:45 | |
kroon | Hi. Anyone know the easiest way to download a yocto image to a Toradex Colibri imx7d emmc ? | 13:45 |
*** camus <camus!~Instantbi@58.246.136.202> has joined #yocto | 13:46 | |
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has joined #yocto | 13:52 | |
OutBackDingo | kroon: is there not docs for yocto on toradex site ? | 13:55 |
*** sakoman <sakoman!~steve@172.243.4.16> has joined #yocto | 13:56 | |
timbert[m] | <kroon "Hi. Anyone know the easiest way "> Have you found this page: https://developer.toradex.com/knowledge-base/flashing-embedded-linux-to-imx7-modules ? | 14:01 |
kroon | OutBackDingo, lots of docs, hard to tell what is the easiest method | 14:01 |
OutBackDingo | kroon: so its a self-built yocto image ? | 14:02 |
kroon | for instance, does mfgtool (uuu?) work with imx7d, or that tool deprecated ? | 14:03 |
OutBackDingo | kroon: that or the easyinstaller should work, last i knew... at least when i worked for toradex | 14:06 |
mckoan | kroon: unfortunately I totally agree, it's overcomplicated | 14:07 |
mckoan | I usually use the Toradex "Easy Installer" to setup a prisine board | 14:08 |
qschulz | kroon: I used uuu with an imx8mm at my previous job, so far from being deprecated ;) | 14:08 |
OutBackDingo | mckoan: yep, i would also agree, even though they say its easy | 14:08 |
mckoan | kroon: https://developer.toradex.com/software/toradex-easy-installer | 14:09 |
mckoan | Toradex Easy Installer (2.0b6 | 2020-11-02 | 29.37 MB) | 14:09 |
mckoan | https://docs.toradex.com/103869-colibri-imx6_toradexeasyinstaller_beta.zi p | 14:09 |
mckoan | Uncompress it and call recovery-linux.sh | 14:09 |
*** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Ping timeout: 272 seconds) | 14:10 | |
*** camus <camus!~Instantbi@58.246.136.202> has joined #yocto | 14:10 | |
*** sakoman <sakoman!~steve@172.243.4.16> has quit IRC (Ping timeout: 272 seconds) | 14:13 | |
*** tnovotny <tnovotny!~tnovotny@ip4-83-240-26-162.cust.nbox.cz> has joined #yocto | 14:14 | |
*** mckoan is now known as mckoan|away | 14:14 | |
*** sakoman <sakoman!~steve@172.243.4.16> has joined #yocto | 14:20 | |
*** t_unix[m] <t_unix[m]!~tunixmatr@2001:470:69fc:105::9ea> has joined #yocto | 14:20 | |
*** gjohnson <gjohnson!~gjohnson@63.227.75.96> has joined #yocto | 14:27 | |
*** sakoman <sakoman!~steve@172.243.4.16> has quit IRC (Ping timeout: 255 seconds) | 14:29 | |
*** LetoThe2nd <LetoThe2nd!uid453638@id-453638.highgate.irccloud.com> has quit IRC (Quit: Connection closed for inactivity) | 14:30 | |
*** dvorkindmitry <dvorkindmitry!~dvorkindm@5.167.98.73> has joined #yocto | 14:36 | |
dvorkindmitry | If I generate sdk with -c populate_sdk ... command, and then re-run it on another day, I got error "No such file or directory:... /locale". Because SDK links are reffering to old dir. How can I avoid this problem in dunfell? | 14:37 |
*** Guest4 <Guest4!~Guest4@host-80-21-103-84.business.telecomitalia.it> has joined #yocto | 14:39 | |
*** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has joined #yocto | 14:43 | |
*** gjohnson <gjohnson!~gjohnson@63.227.75.96> has quit IRC (Remote host closed the connection) | 14:44 | |
*** leo_sandoval <leo_sandoval!~leo_sando@200.68.166.51> has joined #yocto | 14:45 | |
*** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Remote host closed the connection) | 14:45 | |
*** camus <camus!~Instantbi@58.246.136.202> has joined #yocto | 14:45 | |
*** gjohnson <gjohnson!~gjohnson@63.227.75.96> has joined #yocto | 14:47 | |
RP | dvorkindmitry: is there some date reference in the path? Seems a little strange :/ | 14:47 |
dvorkindmitry | RP, there are! i my Distro.conf: SDK_VERSION = "${@d.getVar('DISTRO_VERSION')}" | 14:48 |
*** gjohnson <gjohnson!~gjohnson@63.227.75.96> has quit IRC (Remote host closed the connection) | 14:48 | |
dvorkindmitry | and DISTRO_VERSION = "3.1.2-${DATE} | 14:52 |
dvorkindmitry | RP, sorry. forgot to show you DISTRO_VERSION="3.1.2-${DATE} | 14:53 |
RP | dvorkindmitry: I suspect the best way forward is to find out why the rebuild doesn't work smoothly. Which task is failing? this is for the populate_sdk task right? | 14:55 |
*** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has quit IRC (Quit: Leaving.) | 15:00 | |
*** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has joined #yocto | 15:02 | |
*** Neur0mante <Neur0mante!~Neur0mant@193.207.204.0> has joined #yocto | 15:09 | |
*** Neur0mante <Neur0mante!~Neur0mant@193.207.204.0> has quit IRC (Client Quit) | 15:09 | |
*** Neur0mante <Neur0mante!~Neur0mant@193.207.204.0> has joined #yocto | 15:09 | |
*** Guest4 <Guest4!~Guest4@host-80-21-103-84.business.telecomitalia.it> has quit IRC (Quit: Client closed) | 15:09 | |
*** tnovotny <tnovotny!~tnovotny@ip4-83-240-26-162.cust.nbox.cz> has quit IRC (Quit: Leaving) | 15:11 | |
dvorkindmitry | RP, right. I always get this problem rebuilding SDK on next day, case some of SDK directories are named with <DATE> and I need date in final file, but don't know how to regenerate date reference: https://pastebin.com/ZqCtdP2A | 15:13 |
*** zyga-mbp <zyga-mbp!~zyga@31.0.173.147> has joined #yocto | 15:15 | |
RP | dvorkindmitry: since the sdk task is re-running, the next question to ask is where the date is being encoded that causes the problem such that a new run doesn't account for the new date | 15:16 |
*** leon-anavi <leon-anavi!~Leon@78.130.197.211> has quit IRC (Quit: Leaving) | 15:45 | |
*** camus1 <camus1!~Instantbi@58.246.136.202> has joined #yocto | 15:46 | |
*** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Ping timeout: 246 seconds) | 15:47 | |
*** camus1 is now known as camus | 15:47 | |
*** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has quit IRC (Quit: Ex-Chat) | 15:47 | |
*** camus1 <camus1!~Instantbi@58.246.136.202> has joined #yocto | 16:02 | |
*** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Ping timeout: 252 seconds) | 16:02 | |
*** camus1 is now known as camus | 16:02 | |
*** zyga-mbp <zyga-mbp!~zyga@31.0.173.147> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…) | 16:22 | |
kroon | mckoan|away, OutBackDingo, yes I've used Toradex Easy Installer, but I think its overly cumbersome.. unless I can skip the gui somehow and send the image over the SDP/USB link | 16:26 |
kroon | thats why "uuu" looked interesting, but as I understand it I have to send first a specialzed u-boot with support, then the image I want to write | 16:27 |
*** Neur0mante <Neur0mante!~Neur0mant@193.207.204.0> has quit IRC (Read error: Connection reset by peer) | 16:27 | |
kroon | and I don't know where to get that specialized u-boot from | 16:28 |
kroon | and I can't find a recipe for building uuu-native or mfgtools-native | 16:30 |
rburton | question: do we want to support <500MB ext4 file systems which can't handle y2038 bugs | 16:31 |
rburton | currently, file systems smaller than 500mb don't get big enough inodes for 64-bit times | 16:31 |
rburton | very tempted to patch that down to 100mb or something ... | 16:32 |
*** florian_kc <florian_kc!~florian@dynamic-078-048-073-053.78.48.pool.telefonica.de> has joined #yocto | 16:34 | |
*** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has joined #yocto | 16:38 | |
kroon | rburton, maybe not set inode size to 128 for "small"/"floppy"/"hurd" in e2fsprogs ? thats what I did as a workaround | 16:38 |
rburton | yeah | 16:39 |
rburton | was considering changing the cutoff for small to 100mb or something | 16:39 |
rburton | but i just discovered that in wic we force all filesystems to be 'default', not small | 16:39 |
rburton | so maybe just duplicate that in the bare file system creation? | 16:39 |
*** nerdboy <nerdboy!~nerdboy@gentoo/developer/nerdboy> has quit IRC (Remote host closed the connection) | 16:48 | |
jordemort | kroon: the u-boot you need for uuu is not actually that specialized, it just needs fastboot support compiled in | 17:01 |
jordemort | i just use the u-boot.imx in tmp/deploy/images/${MACHINE} and i'm fine | 17:01 |
kroon | jordemort, hmm ok, I tried that: "uuu -b emmc_all u-boot.imx image.wic" with no success | 17:02 |
jordemort | kroon: it took me a while to figure out but here's the uuu script i use to flash my device (which happens to also be an imx7d) https://gist.github.com/jordemort/584840fa042d410ede7dc18f232bc873 | 17:03 |
jordemort | so i save that as "script.uuu" and then run "uuu script.uuu" | 17:03 |
kroon | jordemort, ok and you use yocto to build the mfgtools kernel and initramfs ? | 17:05 |
jordemort | kroon: yep! | 17:05 |
kroon | I can't build "fsl-image-mfgtool-initramfs" with MACHINE="colibri-imx7-emmc" | 17:07 |
kroon | I get "u-boot-imx-mfgtool PROVIDES u-boot-mfgtool but was skipped: incompatible with machine colibri-imx7-emmc (not in COMPATIBLE_MACHINE)" | 17:07 |
kroon | And "u-boot-fslc-mfgtool PROVIDES u-boot-mfgtool but was skipped: You cannot use UBOOT_MACHINE and UBOOT_CONFIG at the same time." | 17:07 |
jordemort | hm not sure, i'm an imx7sabresd | 17:08 |
jordemort | er imx7dsabresd | 17:09 |
kroon | yeah im guessing toradex MACHINE's only cares about toradex easy installer support :-/ | 17:09 |
jordemort | yeah i'm not using those layers, just meta-freescale | 17:10 |
*** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Ping timeout: 265 seconds) | 17:26 | |
*** camus <camus!~Instantbi@58.246.136.202> has joined #yocto | 17:26 | |
*** vmeson <vmeson!~rmacleod@198-48-226-187.cpe.pppoe.ca> has quit IRC (Ping timeout: 255 seconds) | 17:34 | |
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has quit IRC (Quit: jmiehe) | 17:36 | |
*** vmeson <vmeson!~rmacleod@198-48-226-187.cpe.pppoe.ca> has joined #yocto | 17:37 | |
perdmann_ | does, for example, {@urllib.parse.quote} automatically import urllib? | 17:41 |
*** dtometzki <dtometzki!~dtometzki@fedora/dtometzki> has quit IRC (Ping timeout: 265 seconds) | 17:45 | |
jordemort | can anyone help me understand the difference between itbImage and fitImage? itbImage also seems to be FIT | 17:47 |
*** JaMa <JaMa!~martin@ip-109-238-218-228.aim-net.cz> has quit IRC (Quit: off) | 17:54 | |
*** nerdboy <nerdboy!~nerdboy@47.143.129.24> has joined #yocto | 17:56 | |
*** camus1 <camus1!~Instantbi@58.246.136.202> has joined #yocto | 17:56 | |
*** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Ping timeout: 246 seconds) | 17:57 | |
*** camus1 is now known as camus | 17:57 | |
RP | perdmann_: sadly not | 18:01 |
perdmann_ | RP: so how do i know which modules are available and which not? | 18:03 |
*** florian_kc <florian_kc!~florian@dynamic-078-048-073-053.78.48.pool.telefonica.de> has quit IRC (Ping timeout: 252 seconds) | 18:10 | |
RP | perdmann_: basically os, sys and bb I suspect | 18:18 |
RP | and oe | 18:18 |
*** florian_kc <florian_kc!~florian@78.48.73.53> has joined #yocto | 18:26 | |
perdmann_ | RP: ok .... | 18:39 |
*** Falital <Falital!~Falital@ip-178-203-146-237.hsi10.unitymediagroup.de> has quit IRC (Quit: Connection closed) | 18:55 | |
*** v2d <v2d!~v2d@bras-base-mtrlpq2848w-grc-37-174-89-250-70.dsl.bell.ca> has joined #yocto | 18:56 | |
v2d | hi there -- I get an "do_rootfs: The postinstall intercept hook 'update_udev_hwdb' failed" error related to qemu-native when building from my CI. Seems to be related to RedHat derivated distros. Is it a known issue by any chance? | 18:57 |
*** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Ping timeout: 265 seconds) | 19:42 | |
*** camus <camus!~Instantbi@58.246.136.202> has joined #yocto | 19:42 | |
*** zyga-mbp <zyga-mbp!~zyga@31.0.173.147> has joined #yocto | 20:34 | |
*** Vonter <Vonter!~Vonter@user/vonter> has quit IRC (Ping timeout: 272 seconds) | 20:34 | |
*** zyga-mbp <zyga-mbp!~zyga@31.0.173.147> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…) | 20:41 | |
*** kroon <kroon!~kroon@37-247-29-68.customers.ownit.se> has quit IRC (Quit: Leaving) | 20:51 | |
*** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has quit IRC (Quit: Client closed) | 21:16 | |
*** florian_kc <florian_kc!~florian@78.48.73.53> has quit IRC (Ping timeout: 252 seconds) | 21:16 | |
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has joined #yocto | 21:22 | |
*** camus1 <camus1!~Instantbi@58.246.136.202> has joined #yocto | 21:37 | |
*** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Remote host closed the connection) | 21:37 | |
*** camus1 is now known as camus | 21:37 | |
*** amitk <amitk!~amit@103.208.69.178> has quit IRC (Ping timeout: 272 seconds) | 21:39 | |
*** florian_kc <florian_kc!~florian@dynamic-078-048-073-053.78.48.pool.telefonica.de> has joined #yocto | 21:50 | |
dvorkindmitry | RP, are you there? sorry for the delay in answer | 23:03 |
*** florian_kc <florian_kc!~florian@dynamic-078-048-073-053.78.48.pool.telefonica.de> has quit IRC (Ping timeout: 255 seconds) | 23:10 | |
*** BuZZ-T <BuZZ-T!~basti@IP-185189140137.dynamic.medianet-world.de> has quit IRC (Ping timeout: 272 seconds) | 23:27 | |
*** camus1 <camus1!~Instantbi@58.246.136.202> has joined #yocto | 23:36 | |
*** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Read error: Connection reset by peer) | 23:38 | |
*** camus1 is now known as camus | 23:38 | |
dvorkindmitry | https://pastebin.com/ZqCtdP2A | 23:46 |
dvorkindmitry | I have SDK_VERSION = "${@d.getVar('3.1.3-${DATE}')}", so when I build SDK on the next day, some directories of the SDK are not cleared amd refer to previous day (by name). How to clear SDK build and reassemble it again? | 23:48 |
dvorkindmitry | there is no "cleanall/cleansstate" action inside "populate_sdk" action :) | 23:49 |
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has quit IRC (Quit: jmiehe) | 23:53 | |
*** jwillikers <jwillikers!~jwilliker@2604:2800:2:a403:fe91:ac3e:5153:1290> has quit IRC (Remote host closed the connection) | 23:54 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!