*** 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 #yocto | 00: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 #yocto | 00: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 #yocto | 01: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 #yocto | 02: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 #yocto | 02:58 | |
*** amitk <amitk!~amit@103.208.71.23> has joined #yocto | 03: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 #yocto | 05: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 #yocto | 05:15 | |
*** gioyik <gioyik!~gioyik@gateway/tor-sasl/gioyik> has joined #yocto | 05:21 | |
ThomasD13 | Good morning | 05:21 |
---|---|---|
*** rfuentess <rfuentess!~rfuentess@2a01:598:b028:f0de:ccd2:b5cc:b9fd:a9c> has joined #yocto | 05: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 #yocto | 05: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 #yocto | 05:39 | |
barath | morn | 05:41 |
*** pgowda <pgowda!uid516182@id-516182.ilkley.irccloud.com> has joined #yocto | 05:50 | |
yates | question 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 |
yates | s/is there/are there/ | 05:54 |
*** Belsirk <Belsirk!~rfuentess@2.160.74.247> has joined #yocto | 06: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 dudX | 06:14 |
*** leon-anavi <leon-anavi!~Leon@78.130.197.211> has joined #yocto | 06:16 | |
ThomasD13 | Is 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/kernel | 06:17 |
ThomasD13 | I get the same bitbake error message, when I just use fantasy machine names, which does not exist | 06:18 |
*** fbre <fbre!~fbre@145.253.222.69> has joined #yocto | 06: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 default | 06:20 |
ThomasD13 | thanks a lot josef, I'll check that. | 06:21 |
*** frieder <frieder!~frieder@i59F4B7B0.versanet.de> has joined #yocto | 06:23 | |
ThomasD13 | If 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 #yocto | 06: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 #yocto | 06:55 | |
*** mckoan|away is now known as mckoan | 06:55 | |
mckoan | good morning JosefHolzmayr[m], everyone | 06:56 |
ThomasD13 | morning :) | 06:56 |
ThomasD13 | JosefHolzmayr[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.makefile | 06:59 |
ThomasD13 | j7-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 log | 07: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 |
ThomasD13 | JosefHolzmayr[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 #yocto | 07:14 | |
ThomasD13 | Yes 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 out | 07:14 |
ThomasD13 | Currently, I try to add some debug-output in bbclasses to find out when is something executed to make my guesses :) | 07:15 |
kroon | Hi. 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 #yocto | 07:23 | |
*** rfuentess <rfuentess!~rfuentess@tmo-097-180.customers.d1-online.com> has joined #yocto | 07:32 | |
kroon | I want to make my custom x86 machine conf work for all OE-Core versions. For now I have these two lines: | 07:41 |
kroon | arch_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 | |
kroon | require conf/machine/include/${arch_subdir}/tune-i686.inc | 07:41 |
kroon | Can 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 |
kroon | im already using python | 07: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 |
kroon | JosefHolzmayr[m], thanks, youre right, checking bitbake version should make it possible | 07:48 |
kroon | JosefHolzmayr[m], actually not the override thing, but they moved core .inc files between releases, which broke my machine .conf | 07: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 #yocto | 07:56 | |
*** gioyik <gioyik!~gioyik@gateway/tor-sasl/gioyik> has joined #yocto | 08: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 #yocto | 08:04 | |
*** gioyik <gioyik!~gioyik@gateway/tor-sasl/gioyik> has quit IRC (Ping timeout: 276 seconds) | 08:07 | |
qschulz | ThomasD13: probably doing some weird stuff with _j7-evm overrides somewhere | 08:09 |
qschulz | ThomasD13: try to add MACHINEOVERRIDES =. "j7-evm:" at the top of your machine conf file before any include | 08:10 |
qschulz | also 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 |
ThomasD13 | qschulz, thank you - I'll check that | 08:14 |
ThomasD13 | qschulz, 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 |
qschulz | includes to requires, every file in your machine config file yes | 08:25 |
qschulz | otherwise, they might be using ${MACHINE} directly in some of their logic instead of using overrides and then you're more or less screwed | 08:25 |
ThomasD13 | qschulz, 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.rb | 08:33 |
ThomasD13 | In 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 |
ThomasD13 | SOC_FAMILY ??= "" | 08:34 |
ThomasD13 | MACHINEOVERRIDES =. "${@['', '${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 |
ThomasD13 | But this seems just to add more at MACHINEOVERRIDES, so I think its not the issue | 08:36 |
qschulz | ThomasD13: /me shrugs ask TI for support | 08:37 |
ThomasD13 | Yes 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 #yocto | 08:40 | |
ThomasD13 | But 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.sql | 08:42 |
ThomasD13 | Better 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 #yocto | 08:47 | |
*** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has joined #yocto | 08: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 #yocto | 08: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 #yocto | 09:00 | |
*** Belsirk <Belsirk!~rfuentess@2a01:598:88b8:1eac:ccd2:b5cc:b9fd:a9c> has quit IRC (Ping timeout: 264 seconds) | 09:03 | |
barath | I'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 #yocto | 09:24 | |
*** eduardas <eduardas!~eduardas@93.93.57.5> has joined #yocto | 10:02 | |
ThomasD13 | Is it possible to debug/print env variables when bitbake parses include files? | 10:02 |
*** retoatwork <retoatwork!~retoatwor@85.195.220.82> has joined #yocto | 10: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|away | 10: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 #yocto | 10:29 | |
*** dtometzki <dtometzki!~dtometzki@fedora/dtometzki> has joined #yocto | 10:56 | |
*** pgowda <pgowda!uid516182@id-516182.ilkley.irccloud.com> has joined #yocto | 10:58 | |
*** landgraf <landgraf!~landgraf@2a03:b0c0:2:d0::fa3:c001> has joined #yocto | 11:29 | |
*** lucaceresoli <lucaceresoli!~ceresoli@tech.aim-sportline.com> has joined #yocto | 11:30 | |
lucaceresoli | hi, 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 recipe | 11:33 |
lucaceresoli | in .bb I have: | 11:33 |
lucaceresoli | FILES_${PN}-dev += "${datadir}/foobar" | 11:33 |
lucaceresoli | and in do_install_append(): | 11:33 |
lucaceresoli | install -d ${D}${datadir}/ | 11:33 |
lucaceresoli | echo "FUBAR" >${D}${datadir}/foobar | 11:33 |
lucaceresoli | when building I get: | 11:33 |
lucaceresoli | do_package: QA Issue: linux-aim: Files/directories were installed but not shipped in any package: | 11:34 |
lucaceresoli | /usr | 11:34 |
lucaceresoli | /usr/share | 11:34 |
lucaceresoli | /usr/share/foobar | 11:34 |
lucaceresoli | :-? | 11:34 |
rburton | do bitbake my-linux -e and see if FILES is set to what you expect | 11:35 |
qschulz | rburton: should be ${KERNEL_PACKAGE_NAME}-dev and not ${PN}-dev I think | 11:36 |
qschulz | lucaceresoli: ^ | 11:36 |
qschulz | c.f. https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/kernel.bbclass#n630 | 11:36 |
rburton | yeah | 11:36 |
lucaceresoli | rburton: looks OK: FILES_my-linux-dev="/usr/include /lib/lib*.so ... /usr/share/foobar" | 11:36 |
rburton | what qschulz said is right | 11:36 |
lucaceresoli | qschulz: I guess you are right... | 11:37 |
rburton | kernel.bbclass changes PACKAGES, so the names you need to use in FILES are different | 11:37 |
lucaceresoli | OK, you are right. But this does not solve my _real_ problem: | 11:37 |
lucaceresoli | my-linux also inherits a bbclass with common code that other packages use too | 11:38 |
lucaceresoli | and the additional file I'm trying to add to -dev should be common | 11:39 |
lucaceresoli | so 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 | |
rburton | the kernel recipe will need a custom FILES | 11:40 |
qschulz | lucaceresoli: you can add the FILES_${KERNEL_PACKAGE_NAME}-dev in the bbclass file in the worst case | 11:40 |
qschulz | as you just saw, if it's not part of the PACKAGES variable, it's a noop | 11:40 |
lucaceresoli | seems to work, I have put two lines in my.bbclass and it does the trick: | 11:41 |
lucaceresoli | FILES_${PN}-dev += "${datadir}//foobar" | 11:41 |
lucaceresoli | FILES_${KERNEL_PACKAGE_NAME}-dev += "${datadir}/foobar" | 11:41 |
*** camus1 <camus1!~Instantbi@58.246.136.202> has joined #yocto | 11:43 | |
*** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Ping timeout: 260 seconds) | 11:43 | |
*** camus1 is now known as camus | 11:43 | |
lucaceresoli | qschulz, rburton: it seems like my goal is not yet reached :-\ | 11:49 |
lucaceresoli | now my-linux produces the wanted file in the -dev package, which is called kernel-dev | 11:49 |
lucaceresoli | this foobar file contains version info (git describe) produced from some important packages that are build as externalsrc | 11:50 |
lucaceresoli | my final goal is to have all these version info files available in the image recipe, to cat them into a version info file | 11:51 |
rburton | so why are you putting them in the -dev package? | 11:51 |
rburton | put that data in a separate package so you don't pull in the entire dev package tree | 11:52 |
lucaceresoli | however in the image recipe if I add DEPEND += "my-linux" then the file does not appear in the image recipe-sysroot | 11:52 |
rburton | because $datadir doesn't go into the sysroot | 11:52 |
qschulz | lucaceresoli: 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 |
rburton | why not just embed the versions in the PV, and then just use the existing manifest | 11:53 |
qschulz | or that :p | 11:53 |
lucaceresoli | rburton: 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 hour | 11:54 |
rburton | or what qschulz said is better than putting files into packages and trying to extract them again from the sysroot | 11:54 |
rburton | if you put the srcrev in the PV, then the version will have the sha in | 11:54 |
lucaceresoli | OK, 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 |
rburton | the sysroot is for build time | 11:55 |
rburton | if you built an image entirely from sstate, there would be no sysroot to speak of | 11:56 |
lucaceresoli | good point! | 11:56 |
lucaceresoli | rburton: 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 |
rburton | yes | 11:58 |
rburton | then you won't be dropping those files over your image | 11:58 |
rburton | but if its entirely for build time, don't even do that | 11:58 |
qschulz | lucaceresoli: you can have subdirectories in the deploydir so it's not *that* messy | 11:59 |
lucaceresoli | uhm, OK, seems like the deploy dir idea is the best then | 11:59 |
lucaceresoli | qschulz: yup, I already have a bunch of subdirs... :-P | 11:59 |
lucaceresoli | qschulz, 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 | |
ThomasD13 | I'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 -e | 12: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 #yocto | 12:12 | |
Sinaasappel | Hey all | 12:12 |
ThomasD13 | Just 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 process | 12:13 |
ThomasD13 | The difference between these two, is that at line 9 DEF_TOOLCHAIN_PATH is not set anymore | 12:14 |
ThomasD13 | Is 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 #yocto | 12:20 | |
yates | question 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 #yocto | 12:23 | |
agherzan | Is 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 |
agherzan | Josef Holzmayr (TheYoctoJester): I see them in the web frame though which is strange. | 12:27 |
agherzan | Maybe 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 | |
ThomasD13 | ahhhhh god... I think its the ***** multiconfig. The first config does work, at second config DEF_TOOLCHAIN_PATH is somehow not defined. | 12:28 |
ThomasD13 | This also explains the line numbers... | 12:29 |
JosefHolzmayr[m] | Andrei: probably its the yocto events one. | 12:29 |
agherzan | Found it Josef Holzmayr (TheYoctoJester) | 12:31 |
agherzan | It is Yocto Project Meetings - https://calendar.google.com/calendar/ical/theyoctoproject%40gmail.com/public/basic.ics | 12:31 |
JosefHolzmayr[m] | ah interesting. | 12:31 |
ThomasD13 | LOL! I've got it *facepalm | 12:32 |
lucaceresoli | rburton, 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 |
lucaceresoli | I think I'm going to the ${PN}-myversioninfo idea + handle the kernel as a special case ;.(... | 12:43 |
qschulz | lucaceresoli: do_deploy_append() | 12:49 |
qschulz | I don't know if do_task_append() works fine when there's no task to begin with | 12:51 |
qschulz | I know it works with variables but don't know for tasks | 12:51 |
lucaceresoli | I don't think so. Let me try | 12:52 |
qschulz | if it does not, you can always check from a python anonymous function if a deploy task exists and then append to it | 12:52 |
lucaceresoli | qschulz: it doesn't work, I'd need anonymous python | 12:58 |
lucaceresoli | but before going down that way: will the deploydir take into account the dependency for rebuild? | 12:59 |
qschulz | not sure to understand the question | 12:59 |
lucaceresoli | I 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 |
ThomasD13 | To 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 |
ThomasD13 | And of course I had not a multiconfig file which was named j7-mycopy-k3r5.conf | 13:07 |
fbre | Hey guys, do you know what to add by IMAGE_INSTALL_append += "....." to get the tool "sfdisk"? | 13:08 |
qschulz | lucaceresoli: 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 deploydir | 13:09 |
*** pidge <pidge!~pidge@194.110.145.166> has joined #yocto | 13:10 | |
qschulz | fbre: util-linux recipe should provide it | 13:12 |
fbre | (y) thanx | 13:12 |
qschulz | if the package containing sfdisk is util-linux is a different topic | 13:12 |
qschulz | you can check once you've compiled util-linux with oe-pkgdata-util find-path '*sfdisk*' | 13:12 |
rburton | lucaceresoli: you can do a do_deploy[postfunc] to inject your own function as part of the deploy function | 13:14 |
qschulz | rburton: what happens if there's no do_deploy task to add postfunc to? | 13:15 |
rburton | do_deploy?= ""? | 13:15 |
qschulz | because tasks aren't much more than special variables? | 13:16 |
rburton | right | 13:16 |
lucaceresoli | rburton: does this magic really work? without any 'addtask'??? | 13:16 |
rburton | yeah you need the addtask | 13:17 |
rburton | but iirc that doesn't explode if it already exists | 13:17 |
qschulz | lucaceresoli: you can addtask multiple times, it shouldn't harm | 13:17 |
lucaceresoli | ooh, and the befores and the afters will be the union of the befores and afters mentioned in the various addtasks? | 13:17 |
qschulz | worst case scenario, if deltask of an inexisting task does not fail the parsing, you could deltask followed by addtask :p | 13:18 |
qschulz | so many shitty ideas to implement :D | 13:18 |
rburton | or you could make your own task that deploys on its own | 13:20 |
qschulz | indeed, reimplementing most if not all of deploy.bbclass | 13:21 |
qschulz | so that the sstate-cache is correctly configured and used | 13:21 |
lucaceresoli | I don't want to reimplement yocto to copy a one-line file :-) | 13:22 |
qschulz | lucaceresoli: the deploy task is very small :) | 13:22 |
qschulz | s/task/class/ | 13:22 |
lucaceresoli | yes, 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 #yocto | 13:24 | |
lucaceresoli | ouch, using 'do_deploy ?= ""' + do_deploy_append() + 'addtask do_deploy after do_unpack before do_build' gives 'do_deploy: command not found' | 13:24 |
lucaceresoli | I'm getting crazy | 13:24 |
RP | lucaceresoli: use ":" as the ?= as it is trying to execute "" | 13:26 |
rburton | you should be able to drop that assignment | 13:29 |
rburton | and i'd use a postfunc not a append, and you can't be sure what language the deploy is written in | 13: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 | |
rburton | resisting ... jokes ... | 13:32 |
JosefHolzmayr[m] | lame jokes are the best jokes! | 13:34 |
opello | saw 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 |
tlwoerner | the 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 #yocto | 13:37 | |
rburton | tlwoerner: why are you building target code against native headers | 13:38 |
rburton | oh sorry can't read | 13:39 |
rburton | change the include to <pkg/foo.h>? | 13:39 |
rburton | that's evil but would work ;) | 13:39 |
rburton | i think you want to call include_directories, somehow | 13:40 |
qschulz | or 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 #yocto | 13:42 | |
SandwichCakeExpe | Houdy | 13:42 |
SandwichCakeExpe | Anyone ever done a password based prompt for a recipe? | 13:43 |
SandwichCakeExpe | Say I wanna fetch a tarball from a site needn a password | 13:43 |
SandwichCakeExpe | Can I pause bitbake execution and prompt for a pass? | 13:44 |
rburton | no, because bitbake wants to be able to execute without interaction | 13:45 |
rburton | but wget will read .netrc for you | 13:45 |
SandwichCakeExpe | Thanks rburton | 13:46 |
SandwichCakeExpe | I guess my next best thing is to pass the password on bitbake invocation. Somethin like this: https://stackoverflow.com/a/58344016/1214214 | 13:47 |
rburton | use .netrc | 13:48 |
RP | SandwichCakeExpe: use .netrc | 13:48 |
SandwichCakeExpe | Thanks guys, gotta check what that is | 13:49 |
JosefHolzmayr[m] | jonmason: i hereby officially blame you for just having set up a gitlab runner! | 13:50 |
rburton | hahaha | 13:50 |
*** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has joined #yocto | 13:51 | |
rburton | ah the shame of a broken build mail to the universe | 13:51 |
JosefHolzmayr[m] | theres actually nice things ahead (hopefully) | 13:52 |
lucaceresoli | rburton: 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 |
lucaceresoli | as if the ?: syntax does not add a function, only a variable (?) | 13:53 |
rburton | did you try not having that line at all | 13:53 |
lucaceresoli | BTW bitbake mypackage -e | grep -A1 ^do_deploy gives | 13:54 |
lucaceresoli | do_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 #yocto | 13:54 | |
RP | lucaceresoli: did you look at the run.do_deploy.22093 at what the definition looks like? | 13:54 |
jonmason | JosefHolzmayr[m]: what did I do now? | 13:55 |
JosefHolzmayr[m] | jonmason: https://youtu.be/3EqYkhAaiN0 | 13:57 |
RP | sgw: 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 |
jonmason | JosefHolzmayr[m]: yes, it works. I have 3 running now: meta-arm, meta-zephyr, and poky | 13:58 |
JosefHolzmayr[m] | jonmason: i know that it works, just finding my way around things. | 13:59 |
lucaceresoli | RP: 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 #yocto | 14: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 #yocto | 14:01 | |
jonmason | JosefHolzmayr[m]: let me know if you need help, once you get over the initial pain of setup its not bad | 14:01 |
JosefHolzmayr[m] | jonmason: thx | 14:01 |
RP | lucaceresoli: try adding do_deploy[func] = "1" too. I think its is a syntax thing | 14: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 #yocto | 14:07 | |
*** mario-go` <mario-go`!~user@static.172.139.76.144.clients.your-server.de> has joined #yocto | 14:11 | |
*** dkl_ <dkl_!~dkl@prometheus.umask.eu> has joined #yocto | 14: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 #yocto | 14: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 | |
lucaceresoli | RP: it works!! Thanks | 14:18 |
*** gioyik <gioyik!~gioyik@gateway/tor-sasl/gioyik> has quit IRC (Ping timeout: 276 seconds) | 14:18 | |
lucaceresoli | so 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 |
lucaceresoli | s/fund/find/ | 14:19 |
RP | lucaceresoli: its a kind of internal detail. It is what is set when you define a variable as a function rather than a simple string | 14:20 |
RP | do_deploy () { \n : \n } | 14:21 |
yates | there are no less than 10 recipes under the meta/recipes-devtools/gcc folder: http://paste.debian.net/1212687/ | 14:22 |
yates | is 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 testing | 14:22 | |
yates | i am trying to implement a patch and am finding myself in ambiguous-recipe hell | 14:23 |
RP | systemd-logind.service: Unexpected error repsonse from GetNameOwner(): Connection terminated | 14:23 |
*** gioyik <gioyik!~gioyik@gateway/tor-sasl/gioyik> has joined #yocto | 14:23 | |
yates | khem: do you have any input on this? | 14:23 |
RP | systemd-hostnamed.service: Deactivated successfully | 14:23 |
yates | i 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/Makefile | 14:26 |
yates | which recipe do i bbappend to patch that Makefile? | 14:26 |
yates | (which is a Makefile.in in the preconfigure) | 14:26 |
yates | i have tried creating libgcc and gcc .bbappends - none work | 14:28 |
yates | (and, i think gcc-cross) | 14:28 |
*** rfuentess__ is now known as rfuentess | 14:28 | |
yates | at 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 bbappend | 14:30 |
rburton | yates: gcc-source is where the source comes from | 14:33 |
yates | rburton: is gcc-source the recipe that puts the stuff in tmp/work-shared? | 14:34 |
rburton | ah, libgcc has its own source. its definitely the libgcc recipe | 14:34 |
rburton | well libgcc.bb includes gcc-version.inc which sets SRC_URI | 14: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 #yocto | 14:36 | |
*** eduardas <eduardas!~eduardas@93.93.57.5> has quit IRC (Quit: Konversation terminated!) | 14:37 | |
yates | rburton: 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 |
RP | yates: ultimately those gcc bits come from gcc-course | 14:38 |
RP | gcc source | 14:38 |
yates | wait, no i 'm confused | 14:38 |
yates | so 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 |
yates | RP: so does gcc-source get the fiels into build/tmp/work-shared/gcc-10.3.0-r0? | 14:40 |
yates | s/get/fetch | 14:41 |
RP | yates: yes | 14:41 |
yates | cool | 14:41 |
yates | thank you | 14: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 #yocto | 14:44 | |
*** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV) | 14:45 | |
tlwoerner | rburton: 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 #yocto | 14: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 #yocto | 15:04 | |
*** gioyik <gioyik!~gioyik@gateway/tor-sasl/gioyik> has joined #yocto | 15: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 #yocto | 15: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 #yocto | 15:40 | |
*** Belsirk <Belsirk!~rfuentess@2a01:598:b028:f0de:e478:f610:8037:f5a4> has joined #yocto | 15:40 | |
*** rfuentess <rfuentess!~rfuentess@tmo-097-180.customers.d1-online.com> has quit IRC (Ping timeout: 264 seconds) | 15:43 | |
tlwoerner | zeddii: can you recommend a MACHINE to follow as an example for a BSP layer's kernel config? | 15:55 |
RP | I 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 break | 15:55 |
lucaceresoli | RP, rburton, qschulz: thanks for your time today! | 15:56 |
tlwoerner | zeddii: 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 nothing | 15:56 |
yates | RP: that worked. | 15:56 |
yates | +1 | 15: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 #yocto | 16:03 | |
*** whuang0389 <whuang0389!~whuang038@cpeac202ebbe763-cmac202ebbe760.cpe.net.fido.ca> has joined #yocto | 16:05 | |
*** goliath <goliath!~goliath@user/goliath> has joined #yocto | 16: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 #yocto | 16:19 | |
vd | Is it OK to use the deploy class to copy files outside of DEPLOYDIR (and thus DEPLOY_DIR_IMAGE)? | 16:19 |
rburton | it wouldn't be conventional | 16:19 |
vd | It'd like to write a class to copy final files (not all deployed files) to a locally mounted file server share | 16:19 |
rburton | write a new class | 16: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 |
vd | rburton you answered my question before I asked it :)) | 16:22 |
vd | rburton is the do_build task mantatory for a recipe or can I deltask it? | 16:24 |
rburton | its not mandatory, but without it you can't 'bitbake recipe' without specifiying the task name | 16:25 |
rburton | as the default task is 'build' | 16:25 |
vd | ok | 16:25 |
vd | "build" is commonly the final task I assume. Where should my task go? anywhere "before do_build" I suppose? | 16:25 |
rburton | yes | 16:25 |
rburton | addtask shipit after deploy before build | 16:26 |
rburton | obviously not *anywhere* before do build as otherwise it can run before you've actually deployed anything | 16:26 |
vd | rburton it this case I would do do_shipit[depends] = "my interesting recipes", so it'd be fine | 16:27 |
*** zpfvo <zpfvo!~fvo@88.130.216.3> has quit IRC (Remote host closed the connection) | 16:28 | |
rburton | a more idiomatic approach would be to inherit shipit in the recipes which are interesting | 16:28 |
*** rfuentess__ <rfuentess__!~rfuentess@2.160.74.247> has joined #yocto | 16:31 | |
vd | rburton 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 smarter | 16: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 #yocto | 16:59 | |
*** frieder <frieder!~frieder@i59F4B7B0.versanet.de> has quit IRC (Remote host closed the connection) | 17:02 | |
*** mario-go` is now known as mario-goulart | 17:11 | |
*** florian <florian!~florian@dynamic-002-243-148-019.2.243.pool.telefonica.de> has joined #yocto | 17: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 #yocto | 17:27 | |
*** jessequinn <jessequinn!~jessequin@2804:30c:92b:df00:c181:f92e:73c8:3f5f> has joined #yocto | 17:30 | |
*** Tokamak <Tokamak!~Tokamak@172.58.190.196> has joined #yocto | 17:30 | |
jessequinn | Hi, 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 #yocto | 17: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 #yocto | 18: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 #yocto | 18:19 | |
JPEW | RP: I suspect that removing that is pulling something out of the systemd initialization graph, making it stop the services | 18:19 |
JPEW | RP: Running `systemd-analyze dot > graph.dot` before disabling the service might show why it thinks that | 18:20 |
*** Belsirk <Belsirk!~rfuentess@2a01:598:b028:f0de:e478:f610:8037:f5a4> has joined #yocto | 18:25 | |
*** marex <marex!~marex@195.140.252.251> has joined #yocto | 18: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 #yocto | 18:38 | |
*** Xagen <Xagen!~Xagen@99-135-179-142.lightspeed.austtx.sbcglobal.net> has quit IRC (Quit: Textual IRC Client: www.textualapp.com) | 18:39 | |
fray | looks like git.qemu.org is down, which is breaking some of my buids.. Ugh | 18:40 |
*** Belsirk <Belsirk!~rfuentess@2a01:598:b028:f0de:e478:f610:8037:f5a4> has quit IRC (Ping timeout: 264 seconds) | 18:41 | |
fray | Is there a generic way (MIRRORS/PREMIRRORS) to redirect git://git.qemu.org/git/... to git://gitlab.com/qemu-project/... | 18:41 |
fray | if I specify the '...' part it seems to work, but I thought we could wild card some of it | 18:42 |
*** pgowda <pgowda!uid516182@id-516182.ilkley.irccloud.com> has joined #yocto | 18: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 #yocto | 18:48 | |
*** gioyik <gioyik!~gioyik@gateway/tor-sasl/gioyik> has quit IRC (Ping timeout: 276 seconds) | 18:56 | |
fray | git://git.qemu.org/git/.* git://gitlab.com/qemu-project/BASENAME \n \ | 18:56 |
fray | gitsm://gitqemu.org/git/.* gitsm://gitlab.com/qemu-project/BASENAME \n \ | 18:56 |
fray | as a premirror fixes the problem for me.. | 18:56 |
*** gioyik <gioyik!~gioyik@gateway/tor-sasl/gioyik> has joined #yocto | 19: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 #yocto | 19:26 | |
*** kanavin_ <kanavin_!~Alexander@82.119.0.16> has joined #yocto | 19: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 #yocto | 19:32 | |
RP | JPEW: why would it be intermittent though? | 19:33 |
JPEW | RP: 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 | |
whuang0389 | ah 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 #yocto | 19:50 | |
*** jwillikers <jwillikers!~jwilliker@ics141-1.icsincorporated.com> has quit IRC (Quit: jwillikers) | 19:54 | |
*** jwillikers <jwillikers!~jwilliker@ics141-1.icsincorporated.com> has joined #yocto | 19:55 | |
*** jwillikers <jwillikers!~jwilliker@ics141-1.icsincorporated.com> has quit IRC (Quit: jwillikers) | 19:59 | |
*** gioyik <gioyik!~gioyik@gateway/tor-sasl/gioyik> has joined #yocto | 19:59 | |
*** jwillikers <jwillikers!~jwilliker@ics141-1.icsincorporated.com> has joined #yocto | 20: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 #yocto | 20:15 | |
*** rfuentess <rfuentess!~rfuentess@tmo-097-180.customers.d1-online.com> has quit IRC (Quit: Leaving) | 20:18 | |
RP | JPEW: 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 | |
JPEW | Is it quick enough it could be racing with systemd tearing everything down? | 20:35 |
*** jwillikers <jwillikers!~jwilliker@ics141-1.icsincorporated.com> has joined #yocto | 20:35 | |
JPEW | (seconds perhaps) | 20:35 |
*** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV) | 20:36 | |
RP | JPEW: the tests take some time but I guess something could happen occasionally | 20:37 |
*** pgowda <pgowda!uid516182@id-516182.ilkley.irccloud.com> has quit IRC (Quit: Connection closed for inactivity) | 20:46 | |
vd | I'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 #yocto | 21:02 | |
smurray | vd: that doesn't seem like a sensible ordering to me? I'd expect do_deploy to be after do_build | 21: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 #yocto | 21:06 | |
vd | smurray: 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 |
smurray | vd: though looking in the metadata, I guess I'm mistaken | 21:11 |
smurray | vd: yeah, I see that in base.bbclass | 21:11 |
*** LocutusOfBorg <LocutusOfBorg!~locutusof@93-50-192-18.ip153.fastwebnet.it> has joined #yocto | 21: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 #yocto | 21:20 | |
vd | smurray what am I missing? | 21:21 |
smurray | vd: I'm not sure. Is this a new recipe, or a bbappend to e.g. a kernel recipe? | 21:22 |
smurray | vd: if it's the former, perhaps look at deploy.bbclass, it gets inherited by other things that seem to use do_deploy | 21:23 |
vd | smurray: it's a core-image recipe | 21:24 |
vd | core-image inherits deploy, right? | 21:24 |
vd | or does it.. "Task do_deploy does not exist for target <image>" :-S | 21:27 |
vd | but an image copies stuff in DEPLOY_DIR_IMAGE, I don't get it :/ | 21:27 |
*** gioyik <gioyik!~gioyik@gateway/tor-sasl/gioyik> has joined #yocto | 21:32 | |
*** bunk <bunk!~bunk@debian/bunk> has quit IRC (Quit: leaving) | 21:33 | |
*** bunk <bunk!~bunk@debian/bunk> has joined #yocto | 21:33 | |
vd | well I'm confused, the image class doesn't inherit deploy... Is there a reason why? | 21:36 |
smurray | vd: that's a question for someone like RP or rburton with a bit more knowledge in that area | 21:40 |
smurray | vd: for images do_image_complete does the copying to tmp/deploy/images/..., the deploy task isn't used | 21:47 |
smurray | vd: so you could try using that to order your task | 21:48 |
JPEW | kanavin_: The combination of autotools and rust is... odd :) | 21:49 |
kanavin_ | JPEW, the combination of autotools and rust is a grey hair generator | 21:49 |
kanavin_ | I hope we won't see more of those | 21:50 |
RP | vd: the core-image class does not use the deploy code, it has it's own logic | 21:59 |
vd | RP: why though? | 22:00 |
RP | vd: because the way images deploy is quite different and complex compared to the usual do_deploy tasks and justifies it's own custom code | 22:01 |
RP | vd: both happen to write to the "deploy" directory but that is about all the have in common | 22:01 |
RP | vd: for example images aren't written into sstate, do_deploy tasks are | 22:02 |
vd | ok I see | 22:08 |
*** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has joined #yocto | 22:08 | |
vd | RP: 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 |
RP | vd: you mean copying files that are in DEPLOY_DIR_IMAGE to somewhere else? | 22:09 |
vd | RP: yes | 22:10 |
RP | vd: I would do that as a follow on task to do_deploy, yes | 22:10 |
RP | or to do_image_complete | 22:10 |
vd | ok 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 |
RP | vd: a generic class with added a postfunc to do_image_complete, do_deploy and do_deploy_setscene might work | 22:12 |
*** FredO2 <FredO2!~willy562@bras-base-crnypq0201w-grc-08-216-209-60-169.dsl.bell.ca> has joined #yocto | 22:12 | |
RP | vd: or just addtask after them. I think the postfunc might cause sig changes | 22:13 |
vd | should 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 |
RP | vd: it depends how you want to trigger this and if the checksums matter | 22: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 | |
vd | RP: 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 |
RP | vd: if you were sharing public sstate and wanted it to work without the class, yes | 22:17 |
RP | if not, that does make it easier | 22:17 |
*** rcw <rcw!~rcwoolley@45.72.203.103> has quit IRC (Quit: Leaving) | 22:19 | |
vd | I'm sharing SSTATE_CACHE between builds, but the output directory for final artifacts is fresh every builds | 22:20 |
RP | vd: using sstate just for these builds is fine | 22:20 |
vd | RP: so a generic class which does: addtask do_myarchive after do_deploy; addtask do_myarchive after do_image_complete; without condition? | 22:23 |
RP | vd: those tasks won't trigger, it isn't this simple :( | 22:23 |
RP | vd: which is where I come back to postfuncs | 22:23 |
RP | vd: 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 #yocto | 22:28 | |
*** LocutusOfBorg <LocutusOfBorg!~locutusof@93-50-192-18.ip153.fastwebnet.it> has quit IRC (Ping timeout: 264 seconds) | 22:33 | |
vd | The 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 |
vd | RP: sorry if I misunderstood your suggestions, it's still a bit unclear to me | 22:44 |
*** vd <vd!~vd@bras-base-mtrlpq2848w-grc-41-70-53-240-121.dsl.bell.ca> has quit IRC (Quit: Client closed) | 22:48 | |
RP | vd: 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 |
RP | vd: that could be at the end of the build in an event handler or something | 22:49 |
RP | vd: 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 #yocto | 22: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 #yocto | 23: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 #yocto | 23:33 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!