dl9pf changed the topic of #yocto to: Welcome to the Yocto Project | Learn more: http://www.yoctoproject.org | Join the community: http://www.yoctoproject.org/community | Channel logs available at https://www.yoctoproject.org/irc/ and https://libera.irclog.whitequark.org/yocto/ | Having difficulty on the list, or with someone on the list? Contact YP community mgr Nicolas Dechesne (ndec)
arlen_ has quit [Ping timeout: 252 seconds]
arlen has joined #yocto
goliath has quit [Quit: SIGSEGV]
bluearc has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
bluearc has joined #yocto
gioyik has quit [Ping timeout: 276 seconds]
gioyik has joined #yocto
gioyik has quit [Ping timeout: 276 seconds]
Ad0 has quit [Ping timeout: 260 seconds]
Ad0 has joined #yocto
sakoman has quit [Quit: Leaving.]
gioyik has joined #yocto
amitk has joined #yocto
roussinm has quit [Quit: WeeChat 3.3-dev]
Vonter has quit [Ping timeout: 246 seconds]
gioyik has quit [Ping timeout: 276 seconds]
arlen_ has joined #yocto
arlen has quit [Ping timeout: 252 seconds]
ThomasD13 has joined #yocto
gioyik has joined #yocto
<ThomasD13> Good morning
rfuentess has joined #yocto
gioyik has quit [Ping timeout: 276 seconds]
rfuentess has quit [Remote host closed the connection]
rfuentess has joined #yocto
rfuentess has quit [Remote host closed the connection]
rfuentess has joined #yocto
<barath> morn
pgowda has joined #yocto
<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?
<yates> s/is there/are there/
Belsirk has joined #yocto
rfuentess has quit [Remote host closed the connection]
<JosefHolzmayr[m]> yo dudX
leon-anavi has joined #yocto
<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
<ThomasD13> I get the same bitbake error message, when I just use fantasy machine names, which does not exist
fbre has joined #yocto
<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
<ThomasD13> thanks a lot josef, I'll check that.
frieder has joined #yocto
<ThomasD13> If I checked correctly ( https://hastebin.com/ledigasaku.typescript ) this is not the case? Do you might have a second guess?
goliath has joined #yocto
<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.
zpfvo has joined #yocto
mckoan|away is now known as mckoan
<mckoan> good morning JosefHolzmayr[m], everyone
<ThomasD13> morning :)
<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
<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
<JosefHolzmayr[m]> ThomasD13: this is not the machine file borking, but the external toolchain.
<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.
<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.
<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?
<JosefHolzmayr[m]> ThomasD13: anything is possible, its only software. go and find out.
<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.
kroon has joined #yocto
<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
<ThomasD13> Currently, I try to add some debug-output in bbclasses to find out when is something executed to make my guesses :)
<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 ?
<JosefHolzmayr[m]> kroon: can you try to rephrase/elaborate? or explain what you *actually* want to archieve?
Belsirk has quit [Ping timeout: 252 seconds]
tnovotny has joined #yocto
rfuentess has joined #yocto
<kroon> I want to make my custom x86 machine conf work for all OE-Core versions. For now I have these two lines:
<kroon> arch_subdir = "${@['x86', ''][d.getVar('LAYERSERIES_CORENAMES') in ['dunfell', 'hardknott']]}"
ant__ has quit [Quit: Leaving]
<kroon> require conf/machine/include/${arch_subdir}/tune-i686.inc
<kroon> Can I instead say "version is greater or equal to 'honister'" ?
<JosefHolzmayr[m]> not without some python, i would guess. but happy to be corrected.
<kroon> im already using python
<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.
<JosefHolzmayr[m]> (presuming that the main reason for all of this is the override syntax change)
<kroon> JosefHolzmayr[m], thanks, youre right, checking bitbake version should make it possible
<kroon> JosefHolzmayr[m], actually not the override thing, but they moved core .inc files between releases, which broke my machine .conf
<JosefHolzmayr[m]> ah ok.
<JosefHolzmayr[m]> anyways, as the releases are tied to specific bitbake versions, it should do the trick.
wwilly has joined #yocto
gioyik has joined #yocto
ecdhe has quit [Read error: Connection reset by peer]
ecdhe has joined #yocto
gioyik has quit [Ping timeout: 276 seconds]
<qschulz> ThomasD13: probably doing some weird stuff with _j7-evm overrides somewhere
<qschulz> ThomasD13: try to add MACHINEOVERRIDES =. "j7-evm:" at the top of your machine conf file before any include
<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)
<qschulz> (`include` is "optional", `require` is not)
<ThomasD13> qschulz, thank you - I'll check that
<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?
<qschulz> includes to requires, every file in your machine config file yes
<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
<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
<ThomasD13> In the last inc file (soc-family.inc) there is something interesting:
<ThomasD13> # Add SOC_FAMILY to machine overrides so we get access to e.g. 'omap3' and 'ti335x'
<ThomasD13> SOC_FAMILY ??= ""
<ThomasD13> MACHINEOVERRIDES =. "${@['', '${SOC_FAMILY}:']['${SOC_FAMILY}' != '']}"
<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".
<ThomasD13> But this seems just to add more at MACHINEOVERRIDES, so I think its not the issue
<qschulz> ThomasD13: /me shrugs ask TI for support
<ThomasD13> Yes I've already done that - still waiting :)
kroon has quit [Quit: Leaving]
goliath has quit [Quit: SIGSEGV]
Xagen has quit [Remote host closed the connection]
Xagen has joined #yocto
<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
<ThomasD13> Better than nothing, So Ill go further to check the license_handler process. Maybe I'm find something :)
camus has quit [Ping timeout: 264 seconds]
camus has joined #yocto
florian has joined #yocto
pgowda has quit [Quit: Connection closed for inactivity]
Belsirk has joined #yocto
rfuentess has quit [Ping timeout: 252 seconds]
rfuentess__ has joined #yocto
Belsirk has quit [Ping timeout: 264 seconds]
<barath> I'm testing out building with icecc and it just failed on systemd. do I really need to blacklist that one?
goliath has joined #yocto
eduardas has joined #yocto
<ThomasD13> Is it possible to debug/print env variables when bitbake parses include files?
retoatwork has joined #yocto
dtometzki has quit [Quit: ZNC 1.8.2 - https://znc.in]
mckoan is now known as mckoan|away
retoatwork has quit [Ping timeout: 252 seconds]
retoatwork has joined #yocto
dtometzki has joined #yocto
pgowda has joined #yocto
landgraf has joined #yocto
lucaceresoli has joined #yocto
<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
<lucaceresoli> in .bb I have:
<lucaceresoli> FILES_${PN}-dev += "${datadir}/foobar"
<lucaceresoli> and in do_install_append():
<lucaceresoli> install -d ${D}${datadir}/
<lucaceresoli> echo "FUBAR" >${D}${datadir}/foobar
<lucaceresoli> when building I get:
<lucaceresoli> do_package: QA Issue: linux-aim: Files/directories were installed but not shipped in any package:
<lucaceresoli> /usr
<lucaceresoli> /usr/share
<lucaceresoli> /usr/share/foobar
<lucaceresoli> :-?
<rburton> do bitbake my-linux -e and see if FILES is set to what you expect
<qschulz> rburton: should be ${KERNEL_PACKAGE_NAME}-dev and not ${PN}-dev I think
<qschulz> lucaceresoli: ^
<rburton> yeah
<lucaceresoli> rburton: looks OK: FILES_my-linux-dev="/usr/include /lib/lib*.so ... /usr/share/foobar"
<rburton> what qschulz said is right
<lucaceresoli> qschulz: I guess you are right...
<rburton> kernel.bbclass changes PACKAGES, so the names you need to use in FILES are different
<lucaceresoli> OK, you are right. But this does not solve my _real_ problem:
<lucaceresoli> my-linux also inherits a bbclass with common code that other packages use too
<lucaceresoli> and the additional file I'm trying to add to -dev should be common
<lucaceresoli> so the original code giving me this problem was in my.bbclass. Can I still fix my problem?
wwilly has quit [Quit: Leaving]
<rburton> the kernel recipe will need a custom FILES
<qschulz> lucaceresoli: you can add the FILES_${KERNEL_PACKAGE_NAME}-dev in the bbclass file in the worst case
<qschulz> as you just saw, if it's not part of the PACKAGES variable, it's a noop
<lucaceresoli> seems to work, I have put two lines in my.bbclass and it does the trick:
<lucaceresoli> FILES_${PN}-dev += "${datadir}//foobar"
<lucaceresoli> FILES_${KERNEL_PACKAGE_NAME}-dev += "${datadir}/foobar"
camus1 has joined #yocto
camus has quit [Ping timeout: 260 seconds]
camus1 is now known as camus
<lucaceresoli> qschulz, rburton: it seems like my goal is not yet reached :-\
<lucaceresoli> now my-linux produces the wanted file in the -dev package, which is called kernel-dev
<lucaceresoli> this foobar file contains version info (git describe) produced from some important packages that are build as externalsrc
<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
<rburton> so why are you putting them in the -dev package?
<rburton> put that data in a separate package so you don't pull in the entire dev package tree
<lucaceresoli> however in the image recipe if I add DEPEND += "my-linux" then the file does not appear in the image recipe-sysroot
<rburton> because $datadir doesn't go into the sysroot
<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?
<rburton> why not just embed the versions in the PV, and then just use the existing manifest
<qschulz> or that :p
<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
<rburton> or what qschulz said is better than putting files into packages and trying to extract them again from the sysroot
<rburton> if you put the srcrev in the PV, then the version will have the sha in
<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.
<rburton> the sysroot is for build time
<rburton> if you built an image entirely from sstate, there would be no sysroot to speak of
<lucaceresoli> good point!
<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)?
<rburton> yes
<rburton> then you won't be dropping those files over your image
<rburton> but if its entirely for build time, don't even do that
<qschulz> lucaceresoli: you can have subdirectories in the deploydir so it's not *that* messy
<lucaceresoli> uhm, OK, seems like the deploy dir idea is the best then
<lucaceresoli> qschulz: yup, I already have a bunch of subdirs... :-P
<lucaceresoli> qschulz, rburton: thanks, I'll give the deploy dir a try!
camus has quit [Quit: camus]
<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
xmn has quit [Ping timeout: 252 seconds]
Sinaasappel has joined #yocto
<Sinaasappel> Hey all
<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
<ThomasD13> The difference between these two, is that at line 9 DEF_TOOLCHAIN_PATH is not set anymore
<ThomasD13> Is there any chance to find out, who/what is responsible for resetting an env variable without using bitbake -e option?
arlen_ has quit [Ping timeout: 252 seconds]
arlen has joined #yocto
<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?
jmiehe has joined #yocto
<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.
<JosefHolzmayr[m]> Andrei: wrong is not exactly a good word - its just not maintained anymore as far as i know.
<agherzan> Josef Holzmayr (TheYoctoJester): I see them in the web frame though which is strange.
<agherzan> Maybe just the link is wrong?
<JosefHolzmayr[m]> Andrei: I seem them too, but the only things there are the automatic, recurring events.
Sinaasappel has quit [Quit: Client closed]
<ThomasD13> ahhhhh god... I think its the ***** multiconfig. The first config does work, at second config DEF_TOOLCHAIN_PATH is somehow not defined.
<ThomasD13> This also explains the line numbers...
<JosefHolzmayr[m]> Andrei: probably its the yocto events one.
<agherzan> Found it Josef Holzmayr (TheYoctoJester)
<JosefHolzmayr[m]> ah interesting.
<ThomasD13> LOL! I've got it *facepalm
<lucaceresoli> rburton, qschulz: gaah, the deploy dir idea is a no-go as well :-(
<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...
<lucaceresoli> I think I'm going to the ${PN}-myversioninfo idea + handle the kernel as a special case ;.(...
<qschulz> lucaceresoli: do_deploy_append()
<qschulz> I don't know if do_task_append() works fine when there's no task to begin with
<qschulz> I know it works with variables but don't know for tasks
<lucaceresoli> I don't think so. Let me try
<qschulz> if it does not, you can always check from a python anonymous function if a deploy task exists and then append to it
<lucaceresoli> qschulz: it doesn't work, I'd need anonymous python
<lucaceresoli> but before going down that way: will the deploydir take into account the dependency for rebuild?
<qschulz> not sure to understand the question
<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?
<lucaceresoli> (if using a ${PN}-myversion package this would obviously work)
<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" "
<ThomasD13> And of course I had not a multiconfig file which was named j7-mycopy-k3r5.conf
<fbre> Hey guys, do you know what to add by IMAGE_INSTALL_append += "....." to get the tool "sfdisk"?
<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
pidge has joined #yocto
<qschulz> fbre: util-linux recipe should provide it
<fbre> (y) thanx
<qschulz> if the package containing sfdisk is util-linux is a different topic
<qschulz> you can check once you've compiled util-linux with oe-pkgdata-util find-path '*sfdisk*'
<rburton> lucaceresoli: you can do a do_deploy[postfunc] to inject your own function as part of the deploy function
<qschulz> rburton: what happens if there's no do_deploy task to add postfunc to?
<rburton> do_deploy?= ""?
<qschulz> because tasks aren't much more than special variables?
<rburton> right
<lucaceresoli> rburton: does this magic really work? without any 'addtask'???
<rburton> yeah you need the addtask
<rburton> but iirc that doesn't explode if it already exists
<qschulz> lucaceresoli: you can addtask multiple times, it shouldn't harm
<lucaceresoli> ooh, and the befores and the afters will be the union of the befores and afters mentioned in the various addtasks?
<qschulz> worst case scenario, if deltask of an inexisting task does not fail the parsing, you could deltask followed by addtask :p
<qschulz> so many shitty ideas to implement :D
<rburton> or you could make your own task that deploys on its own
<qschulz> indeed, reimplementing most if not all of deploy.bbclass
<qschulz> so that the sstate-cache is correctly configured and used
<lucaceresoli> I don't want to reimplement yocto to copy a one-line file :-)
<qschulz> lucaceresoli: the deploy task is very small :)
<qschulz> s/task/class/
<lucaceresoli> yes, it is small, 12 lines. But I don't understand a good 50% of them :(
jwillikers has joined #yocto
<lucaceresoli> ouch, using 'do_deploy ?= ""' + do_deploy_append() + 'addtask do_deploy after do_unpack before do_build' gives 'do_deploy: command not found'
<lucaceresoli> I'm getting crazy
<RP> lucaceresoli: use ":" as the ?= as it is trying to execute ""
<rburton> you should be able to drop that assignment
<rburton> and i'd use a postfunc not a append, and you can't be sure what language the deploy is written in
<rburton> (yes, typically sh, but don't make me write one in python just to break your class)
<JosefHolzmayr[m]> rburton: hum is there anybody taking up maintenance of ukdev too?
* JosefHolzmayr[m] badum-tsh!
<rburton> resisting ... jokes ...
<JosefHolzmayr[m]> lame jokes are the best jokes!
<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?
<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?
gioyik has joined #yocto
<rburton> tlwoerner: why are you building target code against native headers
<rburton> oh sorry can't read
<rburton> change the include to <pkg/foo.h>?
<rburton> that's evil but would work ;)
<rburton> i think you want to call include_directories, somehow
<qschulz> or add -I=${RECIPE_SYSROOT_NATIVE}${includedir}/pkg to TARGET_CFLAGS/TARGET_CXXFLAGS I guess?
<qschulz> (without the = after -I sorry)
SandwichCakeExpe has joined #yocto
<SandwichCakeExpe> Houdy
<SandwichCakeExpe> Anyone ever done a password based prompt for a recipe?
<SandwichCakeExpe> Say I wanna fetch a tarball from a site needn a password
<SandwichCakeExpe> Can I pause bitbake execution and prompt for a pass?
<rburton> no, because bitbake wants to be able to execute without interaction
<rburton> but wget will read .netrc for you
<SandwichCakeExpe> Thanks rburton
<SandwichCakeExpe> I guess my next best thing is to pass the password on bitbake invocation. Somethin like this: https://stackoverflow.com/a/58344016/1214214
<rburton> use .netrc
<RP> SandwichCakeExpe: use .netrc
<SandwichCakeExpe> Thanks guys, gotta check what that is
<JosefHolzmayr[m]> jonmason: i hereby officially blame you for just having set up a gitlab runner!
<rburton> hahaha
sakoman has joined #yocto
<rburton> ah the shame of a broken build mail to the universe
<JosefHolzmayr[m]> theres actually nice things ahead (hopefully)
<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'
<lucaceresoli> as if the ?: syntax does not add a function, only a variable (?)
<rburton> did you try not having that line at all
<lucaceresoli> BTW bitbake mypackage -e | grep -A1 ^do_deploy gives
<lucaceresoli> do_deploy=":"
<lucaceresoli> #
<lucaceresoli> (tried "{:}" too)
roussinm has joined #yocto
<RP> lucaceresoli: did you look at the run.do_deploy.22093 at what the definition looks like?
<jonmason> JosefHolzmayr[m]: what did I do now?
<JosefHolzmayr[m]> jonmason: https://youtu.be/3EqYkhAaiN0
<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 :/
<jonmason> JosefHolzmayr[m]: yes, it works. I have 3 running now: meta-arm, meta-zephyr, and poky
<JosefHolzmayr[m]> jonmason: i know that it works, just finding my way around things.
<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.
wwilly has joined #yocto
Xagen has quit [Remote host closed the connection]
Xagen has joined #yocto
<jonmason> JosefHolzmayr[m]: let me know if you need help, once you get over the initial pain of setup its not bad
<JosefHolzmayr[m]> jonmason: thx
<RP> lucaceresoli: try adding do_deploy[func] = "1" too. I think its is a syntax thing
otavio_ has quit [Remote host closed the connection]
ThomasD13 has quit [Ping timeout: 264 seconds]
otavio has joined #yocto
mario-go` has joined #yocto
dkl_ has joined #yocto
mario-goulart has quit [Ping timeout: 252 seconds]
matthewcroughan_ has joined #yocto
dkl has quit [Ping timeout: 252 seconds]
SandwichCakeExpe has quit [Quit: Client closed]
<lucaceresoli> RP: it works!! Thanks
gioyik has quit [Ping timeout: 276 seconds]
<lucaceresoli> so what is the [func] varflag? A flag telling bitbake that 'do_deploy' is a function as opposed to a variable?
<lucaceresoli> (didn't fund it in the docs)
<lucaceresoli> s/fund/find/
<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
<RP> do_deploy () { \n : \n }
<yates> there are no less than 10 recipes under the meta/recipes-devtools/gcc folder: http://paste.debian.net/1212687/
<yates> is there some document or description somewhere that hangs together what all these are afor?
* RP wonders what would cause systemd to get update and pull over the network in an image during testing
<yates> i am trying to implement a patch and am finding myself in ambiguous-recipe hell
<RP> systemd-logind.service: Unexpected error repsonse from GetNameOwner(): Connection terminated
gioyik has joined #yocto
<yates> khem: do you have any input on this?
<RP> systemd-hostnamed.service: Deactivated successfully
<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
<yates> which recipe do i bbappend to patch that Makefile?
<yates> (which is a Makefile.in in the preconfigure)
<yates> i have tried creating libgcc and gcc .bbappends - none work
<yates> (and, i think gcc-cross)
rfuentess__ is now known as rfuentess
<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
<rburton> yates: gcc-source is where the source comes from
<yates> rburton: is gcc-source the recipe that puts the stuff in tmp/work-shared?
<rburton> ah, libgcc has its own source. its definitely the libgcc recipe
<rburton> well libgcc.bb includes gcc-version.inc which sets SRC_URI
tnovotny has quit [Quit: Leaving]
tnovotny has joined #yocto
eduardas has quit [Quit: Konversation terminated!]
<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?
<RP> yates: ultimately those gcc bits come from gcc-course
<RP> gcc source
<yates> wait, no i 'm confused
<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?
<yates> RP: so does gcc-source get the fiels into build/tmp/work-shared/gcc-10.3.0-r0?
<yates> s/get/fetch
<RP> yates: yes
<yates> cool
<yates> thank you
lexano has quit [Ping timeout: 252 seconds]
lexano has joined #yocto
goliath has quit [Quit: SIGSEGV]
<tlwoerner> rburton: qschulz: thanks!
jwillikers has quit [Quit: jwillikers]
jwillikers has joined #yocto
gioyik has quit [Ping timeout: 276 seconds]
Wouter0100 has quit [Read error: Connection reset by peer]
Wouter0100 has joined #yocto
gioyik has joined #yocto
gioyik has quit [Ping timeout: 276 seconds]
pgowda has quit [Quit: Connection closed for inactivity]
gioyik has joined #yocto
gioyik has quit [Ping timeout: 276 seconds]
fbre has quit [Quit: fbre]
dev1990 has joined #yocto
Belsirk has joined #yocto
rfuentess has quit [Ping timeout: 264 seconds]
<tlwoerner> zeddii: can you recommend a MACHINE to follow as an example for a BSP layer's kernel config?
<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
<lucaceresoli> RP, rburton, qschulz: thanks for your time today!
<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
<yates> RP: that worked.
<yates> +1
<tlwoerner> (instead of starting with a random defconfig and tweaking from there)
Saur[m] has quit [Quit: You have been kicked for being idle]
gioyik has joined #yocto
whuang0389 has joined #yocto
goliath has joined #yocto
gioyik has quit [Ping timeout: 276 seconds]
gioyik has joined #yocto
<vd> Is it OK to use the deploy class to copy files outside of DEPLOYDIR (and thus DEPLOY_DIR_IMAGE)?
<rburton> it wouldn't be conventional
<vd> It'd like to write a class to copy final files (not all deployed files) to a locally mounted file server share
<rburton> write a new class
florian has quit [Quit: Ex-Chat]
tnovotny has quit [Quit: Leaving]
<rburton> (with a new task)
<vd> rburton you answered my question before I asked it :))
<vd> rburton is the do_build task mantatory for a recipe or can I deltask it?
<rburton> its not mandatory, but without it you can't 'bitbake recipe' without specifiying the task name
<rburton> as the default task is 'build'
<vd> ok
<vd> "build" is commonly the final task I assume. Where should my task go? anywhere "before do_build" I suppose?
<rburton> yes
<rburton> addtask shipit after deploy before build
<rburton> obviously not *anywhere* before do build as otherwise it can run before you've actually deployed anything
<vd> rburton it this case I would do do_shipit[depends] = "my interesting recipes", so it'd be fine
zpfvo has quit [Remote host closed the connection]
<rburton> a more idiomatic approach would be to inherit shipit in the recipes which are interesting
rfuentess__ has joined #yocto
<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
Belsirk has quit [Ping timeout: 246 seconds]
jwillikers has quit [Quit: jwillikers]
jmiehe has quit [Quit: jmiehe]
jwillikers has joined #yocto
frieder has quit [Remote host closed the connection]
mario-go` is now known as mario-goulart
florian has joined #yocto
mario-goulart has joined #yocto
mario-goulart has quit [Changing host]
sakoman has quit [Ping timeout: 252 seconds]
pidge has quit [Quit: Client closed]
Tokamak has quit [Read error: Connection reset by peer]
sakoman has joined #yocto
jessequinn has joined #yocto
Tokamak has joined #yocto
<jessequinn> Hi, quick question, how do I go about enabling iptables physdev on poky?
gioyik has quit [Ping timeout: 276 seconds]
gioyik has joined #yocto
wwilly has quit [Quit: Leaving]
Tokamak has quit [Read error: Connection reset by peer]
prabhakarlad has quit [Quit: Client closed]
Tokamak has joined #yocto
gioyik has quit [Ping timeout: 276 seconds]
gioyik has joined #yocto
<JPEW> RP: I suspect that removing that is pulling something out of the systemd initialization graph, making it stop the services
<JPEW> RP: Running `systemd-analyze dot > graph.dot` before disabling the service might show why it thinks that
Belsirk has joined #yocto
marex has joined #yocto
rfuentess__ has quit [Ping timeout: 252 seconds]
rfuentess__ has joined #yocto
Xagen has quit [Quit: Textual IRC Client: www.textualapp.com]
<fray> looks like git.qemu.org is down, which is breaking some of my buids.. Ugh
Belsirk has quit [Ping timeout: 264 seconds]
<fray> Is there a generic way (MIRRORS/PREMIRRORS) to redirect git://git.qemu.org/git/... to git://gitlab.com/qemu-project/...
<fray> if I specify the '...' part it seems to work, but I thought we could wild card some of it
pgowda has joined #yocto
LocutusOfBorg has quit [Ping timeout: 265 seconds]
ant__ has joined #yocto
gioyik has quit [Ping timeout: 276 seconds]
<fray> git://git.qemu.org/git/.* git://gitlab.com/qemu-project/BASENAME \n \
<fray> gitsm://gitqemu.org/git/.* gitsm://gitlab.com/qemu-project/BASENAME \n \
<fray> as a premirror fixes the problem for me..
gioyik has joined #yocto
gioyik has quit [Ping timeout: 276 seconds]
gioyik has joined #yocto
kanavin_ has joined #yocto
kanavin has quit [Ping timeout: 252 seconds]
gioyik has quit [Ping timeout: 276 seconds]
prabhakarlad has joined #yocto
<RP> JPEW: why would it be intermittent though?
<JPEW> RP: Ah, that makes no sense (unless it some race)
rfuentess__ has quit [Ping timeout: 252 seconds]
<whuang0389> ah noob linux question. does indentation matter in /etc/network/interfaces file?
rfuentess has joined #yocto
jwillikers has quit [Quit: jwillikers]
jwillikers has joined #yocto
jwillikers has quit [Quit: jwillikers]
gioyik has joined #yocto
jwillikers has joined #yocto
Tokamak has quit [Read error: Connection reset by peer]
Tokamak has joined #yocto
rfuentess has quit [Quit: Leaving]
<RP> JPEW: right, it seems to be some kind of race :/
jwillikers has quit [Quit: jwillikers]
<JPEW> Is it quick enough it could be racing with systemd tearing everything down?
jwillikers has joined #yocto
<JPEW> (seconds perhaps)
goliath has quit [Quit: SIGSEGV]
<RP> JPEW: the tests take some time but I guess something could happen occasionally
pgowda has quit [Quit: Connection closed for inactivity]
<vd> I'm adding: addtask mytask after do_deploy before do_build, but it isn't run unless I call it explicitly. Idea?
Vonter has joined #yocto
<smurray> vd: that doesn't seem like a sensible ordering to me? I'd expect do_deploy to be after do_build
gioyik has quit [Ping timeout: 276 seconds]
stkw0 has quit [Ping timeout: 240 seconds]
stkw0 has joined #yocto
<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""
<smurray> vd: though looking in the metadata, I guess I'm mistaken
<smurray> vd: yeah, I see that in base.bbclass
LocutusOfBorg has joined #yocto
whuang0389 has quit [Quit: Client closed]
LocutusOfBorg has quit [Ping timeout: 265 seconds]
BobPungartnik has joined #yocto
<vd> smurray what am I missing?
<smurray> vd: I'm not sure. Is this a new recipe, or a bbappend to e.g. a kernel recipe?
<smurray> vd: if it's the former, perhaps look at deploy.bbclass, it gets inherited by other things that seem to use do_deploy
<vd> smurray: it's a core-image recipe
<vd> core-image inherits deploy, right?
<vd> or does it.. "Task do_deploy does not exist for target <image>" :-S
<vd> but an image copies stuff in DEPLOY_DIR_IMAGE, I don't get it :/
gioyik has joined #yocto
bunk has quit [Quit: leaving]
bunk has joined #yocto
<vd> well I'm confused, the image class doesn't inherit deploy... Is there a reason why?
<smurray> vd: that's a question for someone like RP or rburton with a bit more knowledge in that area
<smurray> vd: for images do_image_complete does the copying to tmp/deploy/images/..., the deploy task isn't used
<smurray> vd: so you could try using that to order your task
<JPEW> kanavin_: The combination of autotools and rust is... odd :)
<kanavin_> JPEW, the combination of autotools and rust is a grey hair generator
<kanavin_> I hope we won't see more of those
<RP> vd: the core-image class does not use the deploy code, it has it's own logic
<vd> RP: why though?
<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
<RP> vd: both happen to write to the "deploy" directory but that is about all the have in common
<RP> vd: for example images aren't written into sstate, do_deploy tasks are
<vd> ok I see
xmn has joined #yocto
<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?
<RP> vd: you mean copying files that are in DEPLOY_DIR_IMAGE to somewhere else?
<vd> RP: yes
<RP> vd: I would do that as a follow on task to do_deploy, yes
<RP> or to do_image_complete
<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?
<RP> vd: a generic class with added a postfunc to do_image_complete, do_deploy and do_deploy_setscene might work
FredO2 has joined #yocto
<RP> vd: or just addtask after them. I think the postfunc might cause sig changes
<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 } ?
<RP> vd: it depends how you want to trigger this and if the checksums matter
FredO has quit [Ping timeout: 252 seconds]
<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/
<vd> ?*
<RP> vd: if you were sharing public sstate and wanted it to work without the class, yes
<RP> if not, that does make it easier
rcw has quit [Quit: Leaving]
<vd> I'm sharing SSTATE_CACHE between builds, but the output directory for final artifacts is fresh every builds
<RP> vd: using sstate just for these builds is fine
<vd> RP: so a generic class which does: addtask do_myarchive after do_deploy; addtask do_myarchive after do_image_complete; without condition?
<RP> vd: those tasks won't trigger, it isn't this simple :(
<RP> vd: which is where I come back to postfuncs
<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)
* vd is confused \o/
LocutusOfBorg has joined #yocto
LocutusOfBorg has quit [Ping timeout: 264 seconds]
<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?
<vd> RP: sorry if I misunderstood your suggestions, it's still a bit unclear to me
vd has quit [Quit: Client closed]
<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?
<RP> vd: that could be at the end of the build in an event handler or something
<RP> vd: or just copy the deploy dir entirely?
vd has joined #yocto
leon-anavi has quit [Quit: Leaving]
amitk has quit [Ping timeout: 246 seconds]
florian has quit [Ping timeout: 264 seconds]
LocutusOfBorg has joined #yocto
LocutusOfBorg has quit [Ping timeout: 265 seconds]
BobPungartnik has quit [Read error: Connection reset by peer]
BobPungartnik has joined #yocto