Tuesday, 2021-09-21

*** arlen_ <arlen_!~arlen@50-32-89-83.adr01.dlls.pa.frontiernet.net> has quit IRC (Ping timeout: 252 seconds)00:15
*** arlen <arlen!~arlen@50-32-89-83.adr01.dlls.pa.frontiernet.net> has joined #yocto00:15
*** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV)00:23
*** bluearc <bluearc!~quassel@137.78.79.57> has quit IRC (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.)00:41
*** bluearc <bluearc!~quassel@137.78.79.57> has joined #yocto00:43
*** gioyik <gioyik!~gioyik@gateway/tor-sasl/gioyik> has quit IRC (Ping timeout: 276 seconds)00:57
*** gioyik <gioyik!~gioyik@gateway/tor-sasl/gioyik> has joined #yocto01:23
*** gioyik <gioyik!~gioyik@gateway/tor-sasl/gioyik> has quit IRC (Ping timeout: 276 seconds)01:30
*** Ad0 <Ad0!~Ad0@93.124.245.194> has quit IRC (Ping timeout: 260 seconds)02:03
*** Ad0 <Ad0!~Ad0@93.124.245.194> has joined #yocto02:08
*** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has quit IRC (Quit: Leaving.)02:45
*** gioyik <gioyik!~gioyik@gateway/tor-sasl/gioyik> has joined #yocto02:58
*** amitk <amitk!~amit@103.208.71.23> has joined #yocto03:00
*** roussinm <roussinm!~mroussin@bras-base-qubcpq1306w-grc-07-184-145-217-104.dsl.bell.ca> has quit IRC (Quit: WeeChat 3.3-dev)03:14
*** Vonter <Vonter!~Vonter@user/vonter> has quit IRC (Ping timeout: 246 seconds)03:29
*** gioyik <gioyik!~gioyik@gateway/tor-sasl/gioyik> has quit IRC (Ping timeout: 276 seconds)04:30
*** arlen_ <arlen_!~arlen@50-32-89-83.adr01.dlls.pa.frontiernet.net> has joined #yocto05:00
*** arlen <arlen!~arlen@50-32-89-83.adr01.dlls.pa.frontiernet.net> has quit IRC (Ping timeout: 252 seconds)05:00
*** ThomasD13 <ThomasD13!~thomasd13@DSL01.212.114.255.148.ip-pool.NEFkom.net> has joined #yocto05:15
*** gioyik <gioyik!~gioyik@gateway/tor-sasl/gioyik> has joined #yocto05:21
ThomasD13Good morning05:21
*** rfuentess <rfuentess!~rfuentess@2a01:598:b028:f0de:ccd2:b5cc:b9fd:a9c> has joined #yocto05:29
*** gioyik <gioyik!~gioyik@gateway/tor-sasl/gioyik> has quit IRC (Ping timeout: 276 seconds)05:31
*** rfuentess <rfuentess!~rfuentess@2a01:598:b028:f0de:ccd2:b5cc:b9fd:a9c> has quit IRC (Remote host closed the connection)05:34
*** rfuentess <rfuentess!~rfuentess@2a01:598:b028:f0de:ccd2:b5cc:b9fd:a9c> has joined #yocto05:35
*** rfuentess <rfuentess!~rfuentess@2a01:598:b028:f0de:ccd2:b5cc:b9fd:a9c> has quit IRC (Remote host closed the connection)05:38
*** rfuentess <rfuentess!~rfuentess@2a01:598:b028:f0de:ccd2:b5cc:b9fd:a9c> has joined #yocto05:39
barathmorn05:41
*** pgowda <pgowda!uid516182@id-516182.ilkley.irccloud.com> has joined #yocto05:50
yatesquestion on patch context: when you create a patch and use it in a .bbappend, it normally patches stuff in the tmp/work/.../build folder, right? what about recipes which pull stuff into a work-shared folder? is there some special paths that must be used in the patch file in that case?05:54
yatess/is there/are there/05:54
*** Belsirk <Belsirk!~rfuentess@2.160.74.247> has joined #yocto06:00
*** rfuentess <rfuentess!~rfuentess@2a01:598:b028:f0de:ccd2:b5cc:b9fd:a9c> has quit IRC (Remote host closed the connection)06:01
JosefHolzmayr[m]yo dudX06:14
*** leon-anavi <leon-anavi!~Leon@78.130.197.211> has joined #yocto06:16
ThomasD13Is there any reason that following does not work? Copy and rename a functional machine configuration (for example j7-evm.conf to test.conf) and try to build something with MACHINE=test bitbake virtual/kernel06:17
ThomasD13I get the same bitbake error message, when I just use fantasy machine names, which does not exist06:18
*** fbre <fbre!~fbre@145.253.222.69> has joined #yocto06:18
JosefHolzmayr[m]ThomasD13: if i had to guess, then i'd say that the machine file you copied internally sets the machine name to something specific instead of relying on the filename default06:20
ThomasD13thanks a lot josef, I'll check that.06:21
*** frieder <frieder!~frieder@i59F4B7B0.versanet.de> has joined #yocto06:23
ThomasD13If I checked correctly ( https://hastebin.com/ledigasaku.typescript ) this is not the case? Do you might have a second guess?06:27
*** goliath <goliath!~goliath@user/goliath> has joined #yocto06:49
JosefHolzmayr[m]ThomasD13: just lloked up the machine config myself, that actually looks good. "test" is maybe not exactly a good name, maybe start with "my-j7" or something like that. then then next thing would be to make sure the machine file is located at a path thats properly searched.06:51
*** zpfvo <zpfvo!~fvo@88.130.216.3> has joined #yocto06:55
*** mckoan|away is now known as mckoan06:55
mckoangood morning JosefHolzmayr[m], everyone06:56
ThomasD13morning :)06:56
ThomasD13JosefHolzmayr[m], sorry for disturbing again: I think I have the correct path and use another name: https://hastebin.com/eyovehizic.apache       And here on the other console the result after adding j7-fantastic machine config: https://hastebin.com/nozukohaje.makefile06:59
ThomasD13j7-evm works. I literally copied that, which does not work. When I check the output of bitbake -e virtual/kernel of working j7-evm machine, there is no explicit set of "MACHINE=j7-evm" in the log07:01
JosefHolzmayr[m]ThomasD13: this is not the machine file borking, but the external toolchain.07:01
JosefHolzmayr[m]ThomasD13: i guess there is magic hidden in there that sets it up/enables/configures for specific machines , but thats beyond the topics that I am willing to look into at the moment, sorry.07:02
JosefHolzmayr[m]my personal advice would be to strip the layer stack, it looks quite bloated - and i doubt that you actually need all that stuff.07:03
ThomasD13JosefHolzmayr[m], thank you I understand that. Just one question: I think their distribution "arago" (meta-arago/meta-arago-distro/conf/distro/arago.conf) setup the correct toolchain. Is it possible that arago.conf is NOT used for j7-fantastic?07:04
JosefHolzmayr[m]ThomasD13: anything is possible, its only software. go and find out.07:05
JosefHolzmayr[m]your last paste indicates that the arago distro config is being pulled in for the build. what it actually does or doesn't do, no idea.07:07
*** kroon <kroon!~kroon@37-247-29-68.customers.ownit.se> has joined #yocto07:14
ThomasD13Yes thats the key here I think. I am able to debug when I have a logfile from bitbake -e. Since I see the history of which config/inc files are picked up in order (And what does overwrite/set a env variable). But all the stuff before this point is still "black hole" for me. I try to figure this out07:14
ThomasD13Currently, I try to add some debug-output in bbclasses to find out when is something executed to make my guesses :)07:15
kroonHi. Is there a way in bitbake/python to differentiate between whether or not the current OE-Core version is past/before a certain other version ?07:16
JosefHolzmayr[m]kroon: can you try to rephrase/elaborate? or explain what you *actually* want to archieve?07:21
*** Belsirk <Belsirk!~rfuentess@2.160.74.247> has quit IRC (Ping timeout: 252 seconds)07:21
*** tnovotny <tnovotny!~tnovotny@ip4-83-240-26-162.cust.nbox.cz> has joined #yocto07:23
*** rfuentess <rfuentess!~rfuentess@tmo-097-180.customers.d1-online.com> has joined #yocto07:32
kroonI want to make my custom x86 machine conf work for all OE-Core versions. For now I have these two lines:07:41
kroonarch_subdir = "${@['x86', ''][d.getVar('LAYERSERIES_CORENAMES') in ['dunfell', 'hardknott']]}"07:41
*** ant__ <ant__!~ant@host-79-24-62-179.retail.telecomitalia.it> has quit IRC (Quit: Leaving)07:41
kroonrequire conf/machine/include/${arch_subdir}/tune-i686.inc07:41
kroonCan I instead say "version is greater or equal to 'honister'" ?07:42
JosefHolzmayr[m]not without some python, i would guess. but happy to be corrected.07:43
kroonim already using python07:44
JosefHolzmayr[m]ah its the gte thing that you mean. in that case, the release codename is actually just a symptom, but not the core topic - its the bitbake version. and that one should be numeric, so possible to do comparison arithmetic on.07:46
JosefHolzmayr[m](presuming that the main reason for all of this is the override syntax change)07:48
kroonJosefHolzmayr[m], thanks, youre right, checking bitbake version should make it possible07:48
kroonJosefHolzmayr[m], actually not the override thing, but they moved core .inc files between releases, which broke my machine .conf07:48
JosefHolzmayr[m]ah ok.07:49
JosefHolzmayr[m]anyways, as the releases are tied to specific bitbake versions, it should do the trick.07:49
*** wwilly <wwilly!~wwilly@217.140.106.13> has joined #yocto07:56
*** gioyik <gioyik!~gioyik@gateway/tor-sasl/gioyik> has joined #yocto08:02
*** ecdhe <ecdhe!~ecdhe@user/ecdhe> has quit IRC (Read error: Connection reset by peer)08:04
*** ecdhe <ecdhe!~ecdhe@mms-rf-support.com> has joined #yocto08:04
*** gioyik <gioyik!~gioyik@gateway/tor-sasl/gioyik> has quit IRC (Ping timeout: 276 seconds)08:07
qschulzThomasD13: probably doing some weird stuff with _j7-evm overrides somewhere08:09
qschulzThomasD13: try to add MACHINEOVERRIDES =. "j7-evm:" at the top of your machine conf file before any include08:10
qschulzalso make sure that your includes are actually requires so that it's obvious if a file is not included (it'll fail the parsing)08:13
qschulz(`include` is "optional", `require` is not)08:13
ThomasD13qschulz, thank you - I'll check that08:14
ThomasD13qschulz, adding MACHINEOVERRIDES as you suggested didn't change anything. Which requires should I change to includes? Every file which is referenced by machine config?08:24
qschulzincludes to requires, every file in your machine config file yes08:25
qschulzotherwise, they might be using ${MACHINE} directly in some of their logic instead of using overrides and then you're more or less screwed08:25
ThomasD13qschulz, I went up all the referenced files from that j7-fantastic.conf which is a copy of j7-evm.conf. Everything is required. I doubled check the "chain" with the log of the working machine configuration "j7-evm": https://hastebin.com/guqavapuja.rb08:33
ThomasD13In the last inc file (soc-family.inc) there is something interesting:08:34
ThomasD13# Add SOC_FAMILY to machine overrides so we get access to e.g. 'omap3' and 'ti335x'08:34
ThomasD13SOC_FAMILY ??= ""08:34
ThomasD13MACHINEOVERRIDES =. "${@['', '${SOC_FAMILY}:']['${SOC_FAMILY}' != '']}"08:34
JosefHolzmayr[m]qschulz: in the mentorship session, one question was on external toolchains. my answer was: "its possible, but don't do it. it will cause you pain".08:35
ThomasD13But this seems just to add more at MACHINEOVERRIDES, so I think its not the issue08:36
qschulzThomasD13: /me shrugs ask TI for support08:37
ThomasD13Yes I've already done that - still waiting :)08:38
*** kroon <kroon!~kroon@37-247-29-68.customers.ownit.se> has quit IRC (Quit: Leaving)08:39
*** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV)08:39
*** Xagen <Xagen!~Xagen@99-135-179-142.lightspeed.austtx.sbcglobal.net> has quit IRC (Remote host closed the connection)08:40
*** Xagen <Xagen!~Xagen@99-135-179-142.lightspeed.austtx.sbcglobal.net> has joined #yocto08:40
ThomasD13But I think I've gone one step further: I added some debug prints in "meta-arm-toolchain/conf/distro/include/external-arm-toolchain-versions.inc", and now I get after the bitbake command a kind of a stacktrace: https://hastebin.com/ozitixujon.sql08:42
ThomasD13Better than nothing, So Ill go further to check the license_handler process. Maybe I'm find something :)08:43
*** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Ping timeout: 264 seconds)08:46
*** camus <camus!~Instantbi@58.246.136.202> has joined #yocto08:47
*** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has joined #yocto08:52
*** pgowda <pgowda!uid516182@id-516182.ilkley.irccloud.com> has quit IRC (Quit: Connection closed for inactivity)08:56
*** Belsirk <Belsirk!~rfuentess@2a01:598:88b8:1eac:ccd2:b5cc:b9fd:a9c> has joined #yocto08:57
*** rfuentess <rfuentess!~rfuentess@tmo-097-180.customers.d1-online.com> has quit IRC (Ping timeout: 252 seconds)08:57
*** rfuentess__ <rfuentess__!~rfuentess@tmo-097-180.customers.d1-online.com> has joined #yocto09:00
*** Belsirk <Belsirk!~rfuentess@2a01:598:88b8:1eac:ccd2:b5cc:b9fd:a9c> has quit IRC (Ping timeout: 264 seconds)09:03
barathI'm testing out building with icecc and it just failed on systemd. do I really need to blacklist that one?09:07
*** goliath <goliath!~goliath@user/goliath> has joined #yocto09:24
*** eduardas <eduardas!~eduardas@93.93.57.5> has joined #yocto10:02
ThomasD13Is it possible to debug/print env variables when bitbake parses include files?10:02
*** retoatwork <retoatwork!~retoatwor@85.195.220.82> has joined #yocto10:12
*** dtometzki <dtometzki!~dtometzki@fedora/dtometzki> has quit IRC (Quit: ZNC 1.8.2 - https://znc.in)10:19
*** mckoan is now known as mckoan|away10:26
*** retoatwork <retoatwork!~retoatwor@85.195.220.82> has quit IRC (Ping timeout: 252 seconds)10:28
*** retoatwork <retoatwork!~retoatwor@85.195.220.82> has joined #yocto10:29
*** dtometzki <dtometzki!~dtometzki@fedora/dtometzki> has joined #yocto10:56
*** pgowda <pgowda!uid516182@id-516182.ilkley.irccloud.com> has joined #yocto10:58
*** landgraf <landgraf!~landgraf@2a03:b0c0:2:d0::fa3:c001> has joined #yocto11:29
*** lucaceresoli <lucaceresoli!~ceresoli@tech.aim-sportline.com> has joined #yocto11:30
lucaceresolihi, I have a recipe that inherits 'kernel', let's call it my-linux.bb, where FILES_${PN}-dev does not seem to work as it does in any other recipe11:33
lucaceresoliin .bb I have:11:33
lucaceresoliFILES_${PN}-dev += "${datadir}/foobar"11:33
lucaceresoliand in do_install_append():11:33
lucaceresoliinstall -d ${D}${datadir}/11:33
lucaceresoliecho "FUBAR" >${D}${datadir}/foobar11:33
lucaceresoliwhen building I get:11:33
lucaceresolido_package: QA Issue: linux-aim: Files/directories were installed but not shipped in any package:11:34
lucaceresoli  /usr11:34
lucaceresoli  /usr/share11:34
lucaceresoli  /usr/share/foobar11:34
lucaceresoli:-?11:34
rburtondo bitbake my-linux -e and see if FILES is set to what you expect11:35
qschulzrburton: should be ${KERNEL_PACKAGE_NAME}-dev and not ${PN}-dev I think11:36
qschulzlucaceresoli: ^11:36
qschulzc.f. https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/kernel.bbclass#n63011:36
rburtonyeah11:36
lucaceresolirburton: looks OK:   FILES_my-linux-dev="/usr/include /lib/lib*.so ... /usr/share/foobar"11:36
rburtonwhat qschulz said is right11:36
lucaceresoliqschulz: I guess you are right...11:37
rburtonkernel.bbclass changes PACKAGES, so the names you need to use in FILES are different11:37
lucaceresoliOK, you are right. But this does not solve my _real_ problem:11:37
lucaceresolimy-linux also inherits a bbclass with common code that other packages use too11:38
lucaceresoliand the additional file I'm trying to add to -dev should be common11:39
lucaceresoliso the original code giving me this problem was in my.bbclass. Can I still fix my problem?11:39
*** wwilly <wwilly!~wwilly@217.140.106.13> has quit IRC (Quit: Leaving)11:40
rburtonthe kernel recipe will need a custom FILES11:40
qschulzlucaceresoli: you can add the FILES_${KERNEL_PACKAGE_NAME}-dev in the bbclass file in the worst case11:40
qschulzas you just saw, if it's not part of the PACKAGES variable, it's a noop11:40
lucaceresoliseems to work, I have put two lines in my.bbclass and it does the trick:11:41
lucaceresoliFILES_${PN}-dev += "${datadir}//foobar"11:41
lucaceresoliFILES_${KERNEL_PACKAGE_NAME}-dev += "${datadir}/foobar"11:41
*** camus1 <camus1!~Instantbi@58.246.136.202> has joined #yocto11:43
*** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Ping timeout: 260 seconds)11:43
*** camus1 is now known as camus11:43
lucaceresoliqschulz, rburton: it seems like my goal is not yet reached :-\11:49
lucaceresolinow my-linux produces the wanted file in the -dev package, which is called kernel-dev11:49
lucaceresolithis foobar file contains version info (git describe) produced from some important packages that are build as externalsrc11:50
lucaceresolimy final goal is to have all these version info files available in the image recipe, to cat them into a version info file11:51
rburtonso why are you putting them in the -dev package?11:51
rburtonput that data in a separate package so you don't pull in the entire dev package tree11:52
lucaceresolihowever in the image recipe if I add DEPEND += "my-linux" then the file does not appear in the image recipe-sysroot11:52
rburtonbecause $datadir doesn't go into the sysroot11:52
qschulzlucaceresoli: deploy files into the DEPLOYDIR for each recipe with their own version, from the image recipe, collect all of those and do something with it. I think all deploy functions are run before the image recipe tasks are started?11:52
rburtonwhy not just embed the versions in the PV, and then just use the existing manifest11:53
qschulzor that :p11:53
lucaceresolirburton: not sure the PV idea would work for me; would I get a new build dir for every new PV? we have internal packages that change version (= new commits) very often, up to many times per hour11:54
rburtonor what qschulz said is better than putting files into packages and trying to extract them again from the sysroot11:54
rburtonif you put the srcrev in the PV, then the version will have the sha in11:54
lucaceresoliOK, I initially didn't use the deploy dir as I try to not pollute it with all sort of temp files... it just looks dirty, no strong reason for that.11:55
rburtonthe sysroot is for build time11:55
rburtonif you built an image entirely from sstate, there would be no sysroot to speak of11:56
lucaceresoligood point!11:56
lucaceresolirburton: earlier you suggested "put that data in a separate package so you don't pull in the entire dev package tree": do you mean to add it to, say, FILES_${PN}-versioninfo (and add ${PN}-versioninfo to PACKAGES)?11:58
rburtonyes11:58
rburtonthen you won't be dropping those files over your image11:58
rburtonbut if its entirely for build time, don't even do that11:58
qschulzlucaceresoli: you can have subdirectories in the deploydir so it's not *that* messy11:59
lucaceresoliuhm, OK, seems like the deploy dir idea is the best then11:59
lucaceresoliqschulz: yup, I already have a bunch of subdirs... :-P11:59
lucaceresoliqschulz, rburton: thanks, I'll give the deploy dir a try!12:00
*** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Quit: camus)12:03
ThomasD13I've deployed some backtraces in the python functions of toolchain-arm*.inc files and know exactly WHEN the error happens. The error is that DEF_TOOLCHAIN_PATH is not set/defined anymore. But how do I find out what causes this? I cannot use bitbake -e12:09
*** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has quit IRC (Ping timeout: 252 seconds)12:11
*** Sinaasappel <Sinaasappel!~Sinaasapp@2a02-a45a-88f0-1-460d-fbb9-1fae-8bb3.fixed6.kpn.net> has joined #yocto12:12
SinaasappelHey all12:12
ThomasD13Just to give some context: https://hastebin.com/lahilisalo.kotlin     This is the parent function (external_arm_toolchain_license_handler). The error occurs within the function call "eat_get_gcc_version(ld)". Bitbake executes first line 10, which runs fine, then line 9 which aborts the process12:13
ThomasD13The difference between these two, is that at line 9 DEF_TOOLCHAIN_PATH is not set anymore12:14
ThomasD13Is there any chance to find out, who/what is responsible for resetting an env variable without using bitbake -e option?12:17
*** arlen_ <arlen_!~arlen@50-32-89-83.adr01.dlls.pa.frontiernet.net> has quit IRC (Ping timeout: 252 seconds)12:20
*** arlen <arlen!~arlen@50-32-89-83.adr01.dlls.pa.frontiernet.net> has joined #yocto12:20
yatesquestion on patch context: when you create a patch and use it in a .bbappend, it normally patches stuff in the tmp/work/.../build folder, right? what about recipes which pull stuff into a work-shared folder? is there some special paths that must be used in the patch file in that case?12:22
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has joined #yocto12:23
agherzanIs there something wrong with the ics calendar @ https://wiki.yoctoproject.org/wiki/YoctoCalendar? Trying to subscribe to "Yocto Project Development Schedule (1.2 and beyond)" but I get no events.12:24
JosefHolzmayr[m]Andrei: wrong is not exactly a good word - its just not maintained anymore as far as i know.12:26
agherzanJosef Holzmayr (TheYoctoJester): I see them in the web frame though which is strange.12:27
agherzanMaybe just the link is wrong?12:28
JosefHolzmayr[m]Andrei: I seem them too, but the only things there are the automatic, recurring events.12:28
*** Sinaasappel <Sinaasappel!~Sinaasapp@2a02-a45a-88f0-1-460d-fbb9-1fae-8bb3.fixed6.kpn.net> has quit IRC (Quit: Client closed)12:28
ThomasD13ahhhhh god... I think its the ***** multiconfig. The first config does work, at second config DEF_TOOLCHAIN_PATH is somehow not defined.12:28
ThomasD13This also explains the line numbers...12:29
JosefHolzmayr[m]Andrei: probably its the yocto events one.12:29
agherzanFound it Josef Holzmayr (TheYoctoJester)12:31
agherzanIt is Yocto Project Meetings - https://calendar.google.com/calendar/ical/theyoctoproject%40gmail.com/public/basic.ics12:31
JosefHolzmayr[m]ah interesting.12:31
ThomasD13LOL! I've got it *facepalm12:32
lucaceresolirburton, qschulz: gaah, the deploy dir idea is a no-go as well :-(12:41
lucaceresoli[at least] one of the involved packages is my-u-boot.bb, which includes u-boot.inc, which inherits deploy. Now I have two do_deploy()s, and one of them overrides the other...12:42
lucaceresoliI think I'm going to the ${PN}-myversioninfo idea + handle the kernel as a special case ;.(...12:43
qschulzlucaceresoli: do_deploy_append()12:49
qschulzI don't know if do_task_append() works fine when there's no task to begin with12:51
qschulzI know it works with variables but don't know for tasks12:51
lucaceresoliI don't think so. Let me try12:52
qschulzif it does not, you can always check from a python anonymous function if a deploy task exists and then append to it12:52
lucaceresoliqschulz: it doesn't work, I'd need anonymous python12:58
lucaceresolibut before going down that way: will the deploydir take into account the dependency for rebuild?12:59
qschulznot sure to understand the question12:59
lucaceresoliI mean: I do a commit to a package, it gets rebuilt and its version file is regenerated in deploydir. Will the image recipe rebuild to get the new version file, or will it consider itself up-to-date?13:00
lucaceresoli(if using a ${PN}-myversion package this would obviously work)13:00
ThomasD13To sum up, this was the issue: I copied and renamed j7-evm.config. Some include file of j7-evm.config enabled multiconfig (BBMULTICONFIG += "k3r5"). The multiconfig file k3r5.conf changes machine name via "MACHINE_append = "-k3r5" "13:06
ThomasD13And of course I had not a multiconfig file which was named j7-mycopy-k3r5.conf13:07
fbreHey guys, do you know what to add by IMAGE_INSTALL_append += "....." to get the tool "sfdisk"?13:08
qschulzlucaceresoli: your package will be rebuilt because there's a new commit, the deploy task will be called again and since your package changed and it's part of the image already, the image will get the up-to-date version from deploydir13:09
*** pidge <pidge!~pidge@194.110.145.166> has joined #yocto13:10
qschulzfbre: util-linux recipe should provide it13:12
fbre(y)  thanx13:12
qschulzif the package containing sfdisk is util-linux is a different topic13:12
qschulzyou can check once you've compiled util-linux with oe-pkgdata-util find-path '*sfdisk*'13:12
rburtonlucaceresoli: you can do a do_deploy[postfunc] to inject your own function as part of the deploy function13:14
qschulzrburton: what happens if there's no do_deploy task to add postfunc to?13:15
rburtondo_deploy?= ""?13:15
qschulzbecause tasks aren't much more than special variables?13:16
rburtonright13:16
lucaceresolirburton: does this magic really work? without any 'addtask'???13:16
rburtonyeah you need the addtask13:17
rburtonbut iirc that doesn't explode if it already exists13:17
qschulzlucaceresoli: you can addtask multiple times, it shouldn't harm13:17
lucaceresoliooh, and the befores and the afters will be the union of the befores and afters mentioned in the various addtasks?13:17
qschulzworst case scenario, if deltask of an inexisting task does not fail the parsing, you could deltask followed by addtask :p13:18
qschulzso many shitty ideas to implement :D13:18
rburtonor you could make your own task that deploys on its own13:20
qschulzindeed, reimplementing most if not all of deploy.bbclass13:21
qschulzso that the sstate-cache is correctly configured and used13:21
lucaceresoliI don't want to reimplement yocto to copy a one-line file :-)13:22
qschulzlucaceresoli: the deploy task is very small :)13:22
qschulzs/task/class/13:22
lucaceresoliyes, it is small, 12 lines. But I don't understand a good 50% of them :(13:23
*** jwillikers <jwillikers!~jwilliker@ics141-1.icsincorporated.com> has joined #yocto13:24
lucaceresoliouch, using 'do_deploy ?= ""' + do_deploy_append() + 'addtask do_deploy after do_unpack before do_build' gives 'do_deploy: command not found'13:24
lucaceresoliI'm getting crazy13:24
RPlucaceresoli: use ":" as the ?= as it is trying to execute ""13:26
rburtonyou should be able to drop that assignment13:29
rburtonand i'd use a postfunc not a append, and you can't be sure what language the deploy is written in13:29
rburton(yes, typically sh, but don't make me write one in python just to break your class)13:30
JosefHolzmayr[m]rburton: hum is there anybody taking up maintenance of ukdev too?13:32
* JosefHolzmayr[m] badum-tsh!13:32
rburtonresisting ... jokes ...13:32
JosefHolzmayr[m]lame jokes are the best jokes!13:34
opellosaw a strange problem where run.do_install was not generatd with all the necessary helpers (qmake5_base_do_install was missing along with the functions it called) and this was fixed by manually removing bb_codeparser.dat, is that a thing that people might expect to get into a "bad" state and need manual correction?13:36
tlwoernerthe header files from pkg are in sysroot-native/usr/include/pkg not in sysroot-native/usr/include, with a cmake project how do i add sysroot-native/usr/include/pkg to my build?13:36
*** gioyik <gioyik!~gioyik@gateway/tor-sasl/gioyik> has joined #yocto13:37
rburtontlwoerner: why are you building target code against native headers13:38
rburtonoh sorry can't read13:39
rburtonchange the include to <pkg/foo.h>?13:39
rburtonthat's evil but would work ;)13:39
rburtoni think you want to call include_directories, somehow13:40
qschulzor add -I=${RECIPE_SYSROOT_NATIVE}${includedir}/pkg to TARGET_CFLAGS/TARGET_CXXFLAGS I guess?13:40
qschulz(without the = after -I sorry)13:40
*** SandwichCakeExpe <SandwichCakeExpe!~SandwichC@2a02-a45a-88f0-1-460d-fbb9-1fae-8bb3.fixed6.kpn.net> has joined #yocto13:42
SandwichCakeExpeHoudy13:42
SandwichCakeExpeAnyone ever done a password based prompt for a recipe?13:43
SandwichCakeExpeSay I wanna fetch a tarball from a site needn a password13:43
SandwichCakeExpeCan I pause bitbake execution and prompt for a pass?13:44
rburtonno, because bitbake wants to be able to execute without interaction13:45
rburtonbut wget will read .netrc for you13:45
SandwichCakeExpeThanks rburton13:46
SandwichCakeExpeI guess my next best thing is to pass the password on bitbake invocation. Somethin like this: https://stackoverflow.com/a/58344016/121421413:47
rburtonuse .netrc13:48
RPSandwichCakeExpe: use .netrc13:48
SandwichCakeExpeThanks guys, gotta check what that is13:49
JosefHolzmayr[m]jonmason: i hereby officially blame you for just having set up a gitlab runner!13:50
rburtonhahaha13:50
*** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has joined #yocto13:51
rburtonah the shame of a broken build mail to the universe13:51
JosefHolzmayr[m]theres actually nice things ahead (hopefully)13:52
lucaceresolirburton: tried 'do_deploy ?= ":"' but for those of my recipes that don't inherit deploy on their own I keep getting '.../run.do_deploy.22093: line 104: do_deploy: command not found'13:53
lucaceresolias if the ?: syntax does not add a function, only a variable (?)13:53
rburtondid you try not having that line at all13:53
lucaceresoliBTW bitbake mypackage -e | grep -A1 ^do_deploy gives13:54
lucaceresolido_deploy=":"13:54
lucaceresoli#13:54
lucaceresoli(tried "{:}" too)13:54
*** roussinm <roussinm!~mroussin@bras-base-qubcpq1306w-grc-07-184-145-217-104.dsl.bell.ca> has joined #yocto13:54
RPlucaceresoli: did you look at the run.do_deploy.22093 at what the definition looks like?13:54
jonmasonJosefHolzmayr[m]: what did I do now?13:55
JosefHolzmayr[m]jonmason: https://youtu.be/3EqYkhAaiN013:57
RPsgw: When I look at the build output for https://autobuilder.yoctoproject.org/typhoon/#/builders/101/builds/2891/steps/13/logs/stdio I see 55 qmp dumps at 500MB each. This isn't good :/13:58
jonmasonJosefHolzmayr[m]: yes, it works.  I have 3 running now: meta-arm, meta-zephyr, and poky13:58
JosefHolzmayr[m]jonmason: i know that it works, just finding my way around things.13:59
lucaceresoliRP: there is no 'do_deploy' function at all in .../temp/run.do_deploy. The "do_deploy" string appears only in the line where it is supposed to be called: line 104, the one erroring out.14:00
*** wwilly <wwilly!~wwilly@fw-tnat-cam2.arm.com> has joined #yocto14:00
*** Xagen <Xagen!~Xagen@99-135-179-142.lightspeed.austtx.sbcglobal.net> has quit IRC (Remote host closed the connection)14:00
*** Xagen <Xagen!~Xagen@99-135-179-142.lightspeed.austtx.sbcglobal.net> has joined #yocto14:01
jonmasonJosefHolzmayr[m]: let me know if you need help, once you get over the initial pain of setup its not bad14:01
JosefHolzmayr[m]jonmason: thx14:01
RPlucaceresoli: try adding do_deploy[func] = "1" too. I think its is a syntax thing14:01
*** otavio_ <otavio_!~otavio@201-34-65-230.user3p.brasiltelecom.net.br> has quit IRC (Remote host closed the connection)14:04
*** ThomasD13 <ThomasD13!~thomasd13@DSL01.212.114.255.148.ip-pool.NEFkom.net> has quit IRC (Ping timeout: 264 seconds)14:04
*** otavio <otavio!~otavio@201-34-65-230.user3p.brasiltelecom.net.br> has joined #yocto14:07
*** mario-go` <mario-go`!~user@static.172.139.76.144.clients.your-server.de> has joined #yocto14:11
*** dkl_ <dkl_!~dkl@prometheus.umask.eu> has joined #yocto14:12
*** mario-goulart <mario-goulart!~user@chicken/developer/mario-goulart> has quit IRC (Ping timeout: 252 seconds)14:12
*** matthewcroughan_ <matthewcroughan_!~quassel@static.211.38.12.49.clients.your-server.de> has joined #yocto14:13
*** dkl <dkl!~dkl@prometheus.umask.eu> has quit IRC (Ping timeout: 252 seconds)14:13
*** SandwichCakeExpe <SandwichCakeExpe!~SandwichC@2a02-a45a-88f0-1-460d-fbb9-1fae-8bb3.fixed6.kpn.net> has quit IRC (Quit: Client closed)14:14
lucaceresoliRP: it works!! Thanks14:18
*** gioyik <gioyik!~gioyik@gateway/tor-sasl/gioyik> has quit IRC (Ping timeout: 276 seconds)14:18
lucaceresoliso what is the [func] varflag? A flag telling bitbake that 'do_deploy' is a function as opposed to a variable?14:18
lucaceresoli(didn't fund it in the docs)14:19
lucaceresolis/fund/find/14:19
RPlucaceresoli: its a kind of internal detail. It is what is set when you define a variable as a function rather than a simple string14:20
RPdo_deploy () { \n : \n }14:21
yatesthere are no less than 10 recipes under the meta/recipes-devtools/gcc folder: http://paste.debian.net/1212687/14:22
yatesis there some document or description somewhere that hangs together what all these are afor?14:22
* RP wonders what would cause systemd to get update and pull over the network in an image during testing14:22
yatesi am trying to implement a patch and am finding myself in ambiguous-recipe hell14:23
RPsystemd-logind.service: Unexpected error repsonse from GetNameOwner(): Connection terminated14:23
*** gioyik <gioyik!~gioyik@gateway/tor-sasl/gioyik> has joined #yocto14:23
yateskhem: do you have any input on this?14:23
RPsystemd-hostnamed.service: Deactivated successfully14:23
yatesi have tracked my problem to a build problem in build/tmp/work/csky-poky-linux/libgcc/10.3.0-r0/gcc-10.3.0/build.csky-poky-linux.csky-poky-linux/libgcc/Makefile14:26
yateswhich recipe do i bbappend to patch that Makefile?14:26
yates(which is a Makefile.in in the preconfigure)14:26
yatesi have tried creating libgcc and gcc .bbappends - none work14:28
yates(and, i think gcc-cross)14:28
*** rfuentess__ is now known as rfuentess14:28
yatesat this point i'm just guessing, and i'm tired of guessing. i need to undertand the structure of this mess so i can intelligently create the bbappend14:30
rburtonyates: gcc-source is where the source comes from14:33
yatesrburton: is gcc-source the recipe that puts the stuff in tmp/work-shared?14:34
rburtonah, libgcc has its own source.  its definitely the libgcc recipe14:34
rburtonwell libgcc.bb includes gcc-version.inc which sets SRC_URI14:34
*** tnovotny <tnovotny!~tnovotny@ip4-83-240-26-162.cust.nbox.cz> has quit IRC (Quit: Leaving)14:36
*** tnovotny <tnovotny!~tnovotny@ip4-83-240-26-162.cust.nbox.cz> has joined #yocto14:36
*** eduardas <eduardas!~eduardas@93.93.57.5> has quit IRC (Quit: Konversation terminated!)14:37
yatesrburton: i've nailed the compile line in the Makefile above to be compiling build/tmp/work-shared/gcc-10.3.0-r0/gcc-10.3.0/libgcc/config/csky/crti.S, so is libgcc_10.3.bb responsible for putting the source there in work-shared, or is it somethign else?14:38
RPyates: ultimately those gcc bits come from gcc-course14:38
RPgcc source14:38
yateswait, no i 'm confused14:38
yatesso is the gcc stuff fetched ONCE into build/tmp/work-shared/gcc-10.3.0-r0, and then other related recipes copy out of there?14:40
yatesRP: so does gcc-source get the fiels into build/tmp/work-shared/gcc-10.3.0-r0?14:40
yatess/get/fetch14:41
RPyates: yes14:41
yatescool14:41
yatesthank you14:41
*** lexano <lexano!~lexano@cpe00e06722f0e4-cm98524a70e35e.cpe.net.cable.rogers.com> has quit IRC (Ping timeout: 252 seconds)14:41
*** lexano <lexano!~lexano@cpe00e06722f0e4-cm98524a70e35e.cpe.net.cable.rogers.com> has joined #yocto14:44
*** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV)14:45
tlwoernerrburton: qschulz: thanks!14:47
*** jwillikers <jwillikers!~jwilliker@ics141-1.icsincorporated.com> has quit IRC (Quit: jwillikers)14:48
*** jwillikers <jwillikers!~jwilliker@ics141-1.icsincorporated.com> has joined #yocto14:49
*** gioyik <gioyik!~gioyik@gateway/tor-sasl/gioyik> has quit IRC (Ping timeout: 276 seconds)14:50
*** Wouter0100 <Wouter0100!~Wouter010@entry.nbg.netvos.nl> has quit IRC (Read error: Connection reset by peer)15:04
*** Wouter0100 <Wouter0100!~Wouter010@entry.nbg.netvos.nl> has joined #yocto15:04
*** gioyik <gioyik!~gioyik@gateway/tor-sasl/gioyik> has joined #yocto15:08
*** gioyik <gioyik!~gioyik@gateway/tor-sasl/gioyik> has quit IRC (Ping timeout: 276 seconds)15:15
*** pgowda <pgowda!uid516182@id-516182.ilkley.irccloud.com> has quit IRC (Quit: Connection closed for inactivity)15:16
*** gioyik <gioyik!~gioyik@gateway/tor-sasl/gioyik> has joined #yocto15:23
*** gioyik <gioyik!~gioyik@gateway/tor-sasl/gioyik> has quit IRC (Ping timeout: 276 seconds)15:28
*** fbre <fbre!~fbre@145.253.222.69> has quit IRC (Quit: fbre)15:38
*** dev1990 <dev1990!~dev@78.10.71.240> has joined #yocto15:40
*** Belsirk <Belsirk!~rfuentess@2a01:598:b028:f0de:e478:f610:8037:f5a4> has joined #yocto15:40
*** rfuentess <rfuentess!~rfuentess@tmo-097-180.customers.d1-online.com> has quit IRC (Ping timeout: 264 seconds)15:43
tlwoernerzeddii: can you recommend a MACHINE to follow as an example for a BSP layer's kernel config?15:55
RPI meant to ask on the call - do we have any systemd experts who can make sense of why: https://bugzilla.yoctoproject.org/show_bug.cgi?id=14556 might break15:55
lucaceresoliRP, rburton, qschulz: thanks for your time today!15:56
tlwoernerzeddii: i'm thinking of putting BSP-specific things in my BSP layer, then starting each MACHINE out with an empty config which gets built up from nothing15:56
yatesRP: that worked.15:56
yates+115:57
tlwoerner(instead of starting with a random defconfig and tweaking from there)15:57
*** Saur[m] <Saur[m]!~saur2000m@2001:470:69fc:105::dce> has quit IRC (Quit: You have been kicked for being idle)16:00
*** gioyik <gioyik!~gioyik@gateway/tor-sasl/gioyik> has joined #yocto16:03
*** whuang0389 <whuang0389!~whuang038@cpeac202ebbe763-cmac202ebbe760.cpe.net.fido.ca> has joined #yocto16:05
*** goliath <goliath!~goliath@user/goliath> has joined #yocto16:08
*** gioyik <gioyik!~gioyik@gateway/tor-sasl/gioyik> has quit IRC (Ping timeout: 276 seconds)16:14
*** gioyik <gioyik!~gioyik@gateway/tor-sasl/gioyik> has joined #yocto16:19
vdIs it OK to use the deploy class to copy files outside of DEPLOYDIR (and thus DEPLOY_DIR_IMAGE)?16:19
rburtonit wouldn't be conventional16:19
vdIt'd like to write a class to copy final files (not all deployed files) to a locally mounted file server share16:19
rburtonwrite a new class16:21
*** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has quit IRC (Quit: Ex-Chat)16:21
*** tnovotny <tnovotny!~tnovotny@ip4-83-240-26-162.cust.nbox.cz> has quit IRC (Quit: Leaving)16:21
rburton(with a new task)16:21
vdrburton you answered my question before I asked it :))16:22
vdrburton is the do_build task mantatory for a recipe or can I deltask it?16:24
rburtonits not mandatory, but without it you can't 'bitbake recipe' without specifiying the task name16:25
rburtonas the default task is 'build'16:25
vdok16:25
vd"build" is commonly the final task I assume. Where should my task go? anywhere "before do_build" I suppose?16:25
rburtonyes16:25
rburtonaddtask shipit after deploy before build16:26
rburtonobviously not *anywhere* before do build as otherwise it can run before you've actually deployed anything16:26
vdrburton it this case I would do do_shipit[depends] = "my interesting recipes", so it'd be fine16:27
*** zpfvo <zpfvo!~fvo@88.130.216.3> has quit IRC (Remote host closed the connection)16:28
rburtona more idiomatic approach would be to inherit shipit in the recipes which are interesting16:28
*** rfuentess__ <rfuentess__!~rfuentess@2.160.74.247> has joined #yocto16:31
vdrburton currently I was using a dumb recipe to bundle together all recipes I want instead of specifying all of them, for all multiconfig variants. But the class might be smarter16:31
*** Belsirk <Belsirk!~rfuentess@2a01:598:b028:f0de:e478:f610:8037:f5a4> has quit IRC (Ping timeout: 246 seconds)16:34
*** jwillikers <jwillikers!~jwilliker@ics141-1.icsincorporated.com> has quit IRC (Quit: jwillikers)16:58
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has quit IRC (Quit: jmiehe)16:59
*** jwillikers <jwillikers!~jwilliker@ics141-1.icsincorporated.com> has joined #yocto16:59
*** frieder <frieder!~frieder@i59F4B7B0.versanet.de> has quit IRC (Remote host closed the connection)17:02
*** mario-go` is now known as mario-goulart17:11
*** florian <florian!~florian@dynamic-002-243-148-019.2.243.pool.telefonica.de> has joined #yocto17:11
*** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has quit IRC (Ping timeout: 252 seconds)17:12
*** pidge <pidge!~pidge@194.110.145.166> has quit IRC (Quit: Client closed)17:21
*** Tokamak <Tokamak!~Tokamak@172.58.190.196> has quit IRC (Read error: Connection reset by peer)17:24
*** sakoman <sakoman!~steve@172.243.4.16> has joined #yocto17:27
*** jessequinn <jessequinn!~jessequin@2804:30c:92b:df00:c181:f92e:73c8:3f5f> has joined #yocto17:30
*** Tokamak <Tokamak!~Tokamak@172.58.190.196> has joined #yocto17:30
jessequinnHi, quick question, how do I go about enabling iptables physdev on poky?17:34
*** gioyik <gioyik!~gioyik@gateway/tor-sasl/gioyik> has quit IRC (Ping timeout: 276 seconds)17:36
*** gioyik <gioyik!~gioyik@gateway/tor-sasl/gioyik> has joined #yocto17:41
*** wwilly <wwilly!~wwilly@fw-tnat-cam2.arm.com> has quit IRC (Quit: Leaving)17:43
*** Tokamak <Tokamak!~Tokamak@172.58.190.196> has quit IRC (Read error: Connection reset by peer)17:55
*** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has quit IRC (Quit: Client closed)18:00
*** Tokamak <Tokamak!~Tokamak@172.58.190.196> has joined #yocto18:00
*** gioyik <gioyik!~gioyik@gateway/tor-sasl/gioyik> has quit IRC (Ping timeout: 276 seconds)18:16
*** gioyik <gioyik!~gioyik@gateway/tor-sasl/gioyik> has joined #yocto18:19
JPEWRP: I suspect that removing that is pulling something out of the systemd initialization graph, making it stop the services18:19
JPEWRP: Running `systemd-analyze dot > graph.dot` before disabling the service might show why it thinks that18:20
*** Belsirk <Belsirk!~rfuentess@2a01:598:b028:f0de:e478:f610:8037:f5a4> has joined #yocto18:25
*** marex <marex!~marex@195.140.252.251> has joined #yocto18:27
*** rfuentess__ <rfuentess__!~rfuentess@2.160.74.247> has quit IRC (Ping timeout: 252 seconds)18:28
*** rfuentess__ <rfuentess__!~rfuentess@2.160.74.247> has joined #yocto18:38
*** Xagen <Xagen!~Xagen@99-135-179-142.lightspeed.austtx.sbcglobal.net> has quit IRC (Quit: Textual IRC Client: www.textualapp.com)18:39
fraylooks like git.qemu.org is down, which is breaking some of my buids.. Ugh18:40
*** Belsirk <Belsirk!~rfuentess@2a01:598:b028:f0de:e478:f610:8037:f5a4> has quit IRC (Ping timeout: 264 seconds)18:41
frayIs there a generic way (MIRRORS/PREMIRRORS) to redirect git://git.qemu.org/git/... to git://gitlab.com/qemu-project/...18:41
frayif I specify the '...' part it seems to work, but I thought we could wild card some of it18:42
*** pgowda <pgowda!uid516182@id-516182.ilkley.irccloud.com> has joined #yocto18:42
*** LocutusOfBorg <LocutusOfBorg!~locutusof@93-50-192-18.ip153.fastwebnet.it> has quit IRC (Ping timeout: 265 seconds)18:44
*** ant__ <ant__!~ant@host-79-24-62-179.retail.telecomitalia.it> has joined #yocto18:48
*** gioyik <gioyik!~gioyik@gateway/tor-sasl/gioyik> has quit IRC (Ping timeout: 276 seconds)18:56
fraygit://git.qemu.org/git/.* git://gitlab.com/qemu-project/BASENAME \n \18:56
fraygitsm://gitqemu.org/git/.* gitsm://gitlab.com/qemu-project/BASENAME \n \18:56
frayas a premirror fixes the problem for me..18:56
*** gioyik <gioyik!~gioyik@gateway/tor-sasl/gioyik> has joined #yocto19:03
*** gioyik <gioyik!~gioyik@gateway/tor-sasl/gioyik> has quit IRC (Ping timeout: 276 seconds)19:09
*** gioyik <gioyik!~gioyik@gateway/tor-sasl/gioyik> has joined #yocto19:26
*** kanavin_ <kanavin_!~Alexander@82.119.0.16> has joined #yocto19:27
*** kanavin <kanavin!~Alexander@2a02:2454:29b:3b00:d35d:e3cf:58b5:748b> has quit IRC (Ping timeout: 252 seconds)19:29
*** gioyik <gioyik!~gioyik@gateway/tor-sasl/gioyik> has quit IRC (Ping timeout: 276 seconds)19:32
*** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has joined #yocto19:32
RPJPEW: why would it be intermittent though?19:33
JPEWRP: Ah, that makes no sense (unless it some race)19:33
*** rfuentess__ <rfuentess__!~rfuentess@2.160.74.247> has quit IRC (Ping timeout: 252 seconds)19:40
whuang0389ah noob linux question. does indentation matter in /etc/network/interfaces file?19:48
*** rfuentess <rfuentess!~rfuentess@tmo-097-180.customers.d1-online.com> has joined #yocto19:50
*** jwillikers <jwillikers!~jwilliker@ics141-1.icsincorporated.com> has quit IRC (Quit: jwillikers)19:54
*** jwillikers <jwillikers!~jwilliker@ics141-1.icsincorporated.com> has joined #yocto19:55
*** jwillikers <jwillikers!~jwilliker@ics141-1.icsincorporated.com> has quit IRC (Quit: jwillikers)19:59
*** gioyik <gioyik!~gioyik@gateway/tor-sasl/gioyik> has joined #yocto19:59
*** jwillikers <jwillikers!~jwilliker@ics141-1.icsincorporated.com> has joined #yocto20:00
*** Tokamak <Tokamak!~Tokamak@172.58.190.196> has quit IRC (Read error: Connection reset by peer)20:08
*** Tokamak <Tokamak!~Tokamak@172.58.190.196> has joined #yocto20:15
*** rfuentess <rfuentess!~rfuentess@tmo-097-180.customers.d1-online.com> has quit IRC (Quit: Leaving)20:18
RPJPEW: right, it seems to be some kind of race :/20:34
*** jwillikers <jwillikers!~jwilliker@ics141-1.icsincorporated.com> has quit IRC (Quit: jwillikers)20:34
JPEWIs it quick enough it could be racing with systemd tearing everything down?20:35
*** jwillikers <jwillikers!~jwilliker@ics141-1.icsincorporated.com> has joined #yocto20:35
JPEW(seconds perhaps)20:35
*** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV)20:36
RPJPEW: the tests take some time but I guess something could happen occasionally20:37
*** pgowda <pgowda!uid516182@id-516182.ilkley.irccloud.com> has quit IRC (Quit: Connection closed for inactivity)20:46
vdI'm adding: addtask mytask after do_deploy before do_build, but it isn't run unless I call it explicitly. Idea?21:02
*** Vonter <Vonter!~Vonter@user/vonter> has joined #yocto21:02
smurrayvd: that doesn't seem like a sensible ordering to me? I'd expect do_deploy to be after do_build21:03
*** gioyik <gioyik!~gioyik@gateway/tor-sasl/gioyik> has quit IRC (Ping timeout: 276 seconds)21:05
*** stkw0 <stkw0!~quassel@ns3046126.ip-91-121-8.eu> has quit IRC (Ping timeout: 240 seconds)21:06
*** stkw0 <stkw0!~quassel@ns3046126.ip-91-121-8.eu> has joined #yocto21:06
vdsmurray: but the doc says this about do_deploy: "You do not need to add before do_build to the addtask command (though it is harmless), because the base class contains the following: do_build[recrdeptask] += "do_deploy""21:10
smurrayvd: though looking in the metadata, I guess I'm mistaken21:11
smurrayvd: yeah, I see that in base.bbclass21:11
*** LocutusOfBorg <LocutusOfBorg!~locutusof@93-50-192-18.ip153.fastwebnet.it> has joined #yocto21:11
*** whuang0389 <whuang0389!~whuang038@cpeac202ebbe763-cmac202ebbe760.cpe.net.fido.ca> has quit IRC (Quit: Client closed)21:12
*** LocutusOfBorg <LocutusOfBorg!~locutusof@93-50-192-18.ip153.fastwebnet.it> has quit IRC (Ping timeout: 265 seconds)21:16
*** BobPungartnik <BobPungartnik!~Pung@187.113.151.66> has joined #yocto21:20
vdsmurray what am I missing?21:21
smurrayvd: I'm not sure.  Is this a new recipe, or a bbappend to e.g. a kernel recipe?21:22
smurrayvd: if it's the former, perhaps look at deploy.bbclass, it gets inherited by other things that seem to use do_deploy21:23
vdsmurray: it's a core-image recipe21:24
vdcore-image inherits deploy, right?21:24
vdor does it.. "Task do_deploy does not exist for target <image>" :-S21:27
vdbut an image copies stuff in DEPLOY_DIR_IMAGE, I don't get it :/21:27
*** gioyik <gioyik!~gioyik@gateway/tor-sasl/gioyik> has joined #yocto21:32
*** bunk <bunk!~bunk@debian/bunk> has quit IRC (Quit: leaving)21:33
*** bunk <bunk!~bunk@debian/bunk> has joined #yocto21:33
vdwell I'm confused, the image class doesn't inherit deploy... Is there a reason why?21:36
smurrayvd: that's a question for someone like RP or rburton with a bit more knowledge in that area21:40
smurrayvd: for images do_image_complete does the copying to tmp/deploy/images/..., the deploy task isn't used21:47
smurrayvd: so you could try using that to order your task21:48
JPEWkanavin_: The combination of autotools and rust is... odd :)21:49
kanavin_JPEW, the combination of autotools and rust is a grey hair generator21:49
kanavin_I hope we won't see more of those21:50
RPvd: the core-image class does not use the deploy code, it has it's own logic21:59
vdRP: why though?22:00
RPvd: because the way images deploy is quite different and complex compared to the usual do_deploy tasks and justifies it's own custom code22:01
RPvd: both happen to write to the "deploy" directory but that is about all the have in common22:01
RPvd: for example images aren't written into sstate, do_deploy tasks are22:02
vdok I see22:08
*** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has joined #yocto22:08
vdRP: we agree that copying files outside of DEPLOY_DIR_IMAGE (for archiving) requires its own class and cannot use the deploy class, right?22:09
RPvd: you mean copying files that are in DEPLOY_DIR_IMAGE to somewhere else?22:09
vdRP: yes22:10
RPvd: I would do that as a follow on task to do_deploy, yes22:10
RPor to do_image_complete22:10
vdok thank you. Is there a way to make a class generic enough to inherit it in recipes using the deploy class or image recipes?22:11
RPvd: a generic class with added a postfunc to do_image_complete, do_deploy and do_deploy_setscene might work22:12
*** FredO2 <FredO2!~willy562@bras-base-crnypq0201w-grc-08-216-209-60-169.dsl.bell.ca> has joined #yocto22:12
RPvd: or just addtask after them. I think the postfunc might cause sig changes22:13
vdshould I write class code that does something like: if (has task "do_deploy") { addtask do_myarchive after do_deploy } else { addtask do_myarchive after do_image_complete } ?22:13
RPvd: it depends how you want to trigger this and if the checksums matter22:13
*** FredO <FredO!~willy562@bras-base-crnypq0201w-grc-06-76-69-222-77.dsl.bell.ca> has quit IRC (Ping timeout: 252 seconds)22:14
vdRP: I'm not sure about that. I just need to copy some final artifacts in a shared directory. Do checksums matter in this scenario/22:16
vd?*22:16
RPvd: if you were sharing public sstate and wanted it to work without the class, yes22:17
RPif not, that does make it easier22:17
*** rcw <rcw!~rcwoolley@45.72.203.103> has quit IRC (Quit: Leaving)22:19
vdI'm sharing SSTATE_CACHE between builds, but the output directory for final artifacts is fresh every builds22:20
RPvd: using sstate just for these builds is fine22:20
vdRP: so a generic class which does: addtask do_myarchive after do_deploy; addtask do_myarchive after do_image_complete; without condition?22:23
RPvd: those tasks won't trigger, it isn't this simple :(22:23
RPvd: which is where I come back to postfuncs22:23
RPvd: buildhistory is an example of a class that hooks in but tries to stop the hashes changing FWIW if that is important to you (and I suspect it isn't)22:24
* vd is confused \o/22:27
*** LocutusOfBorg <LocutusOfBorg!~locutusof@93-50-192-18.ip153.fastwebnet.it> has joined #yocto22:28
*** LocutusOfBorg <LocutusOfBorg!~locutusof@93-50-192-18.ip153.fastwebnet.it> has quit IRC (Ping timeout: 264 seconds)22:33
vdThe thing is, it has to come from the recipes themself because only them know IMAGE_NAME and I don't want to guess them. So how can I share this code? postfuncs or a bbclass?22:43
vdRP: sorry if I misunderstood your suggestions, it's still a bit unclear to me22:44
*** vd <vd!~vd@bras-base-mtrlpq2848w-grc-41-70-53-240-121.dsl.bell.ca> has quit IRC (Quit: Client closed)22:48
RPvd: well, stepping back and thinking about this a different way, you could look through tmp/sstate-control/* and look for the do_deploy and do_image_complete manifests, then just copy the referenced files?22:48
RPvd: that could be at the end of the build in an event handler or something22:49
RPvd: or just copy the deploy dir entirely?22:50
*** vd <vd!~vd@bras-base-mtrlpq2848w-grc-41-70-53-240-121.dsl.bell.ca> has joined #yocto22:52
*** leon-anavi <leon-anavi!~Leon@78.130.197.211> has quit IRC (Quit: Leaving)23:00
*** amitk <amitk!~amit@103.208.71.23> has quit IRC (Ping timeout: 246 seconds)23:06
*** florian <florian!~florian@dynamic-002-243-148-019.2.243.pool.telefonica.de> has quit IRC (Ping timeout: 264 seconds)23:17
*** LocutusOfBorg <LocutusOfBorg!~locutusof@93-50-192-18.ip153.fastwebnet.it> has joined #yocto23:25
*** LocutusOfBorg <LocutusOfBorg!~locutusof@93-50-192-18.ip153.fastwebnet.it> has quit IRC (Ping timeout: 265 seconds)23:30
*** BobPungartnik <BobPungartnik!~Pung@187.113.151.66> has quit IRC (Read error: Connection reset by peer)23:33
*** BobPungartnik <BobPungartnik!~Pung@187.113.151.66> has joined #yocto23:33

Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!