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
<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.
<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']]}"
<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'
<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?
<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>
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)
<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
<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 (?)
<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
<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?
<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
<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]