| 01:51.22 | *** join/#oe tprrt (~tprrt@upc31-1-78-208-110-13.fbx.proxad.net) |
| 03:02.37 | *** join/#oe hrw (~hrw@redhat/hrw) |
| 03:38.08 | *** join/#oe hrw (~hrw@redhat/hrw) |
| 04:21.06 | *** join/#oe bluelightning (~paul@pdpc/supporter/professional/bluelightning) |
| 05:06.39 | *** join/#oe rob_w (~bob@unaffiliated/rob-w/x-1112029) |
| 05:14.51 | *** join/#oe AndersD (~AndersD@h-98-128-162-82.NA.cust.bahnhof.se) |
| 06:18.22 | *** join/#oe frsc (~frsc@2003:a:e7a:6200:246c:2a8b:f45a:a33d) |
| 06:22.41 | *** join/#oe khem (~khem@unaffiliated/khem) |
| 06:24.32 | *** join/#oe yegorich (~yegorich@mail.visionsystems.de) |
| 06:26.49 | *** join/#oe Bunio_FH (~bunio@81-18-201-214.static.chello.pl) |
| 06:28.00 | *** join/#oe florian_kc (~florian_k@Maemo/community/contributor/florian) |
| 06:31.12 | *** join/#oe ao2 (~ao2@87.19.81.128) |
| 06:44.40 | *** join/#oe tprrt (~tprrt@217.114.201.133) |
| 07:21.59 | *** join/#oe leon-anavi (~Leon@78.130.245.19) |
| 08:06.29 | *** join/#oe tnovotny (~tnovotny@176-74-132-138.netdatacomm.cz) |
| 08:18.24 | *** join/#oe florian_kc (~florian_k@Maemo/community/contributor/florian) |
| 08:20.10 | *** join/#oe AndersD (~AndersD@h-98-128-162-82.NA.cust.bahnhof.se) |
| 09:15.53 | *** join/#oe JaMa (~martin@ip-217-030-068-212.aim-net.cz) |
| 09:33.43 | *** join/#oe nslu2-log (~nslu2-log@23.141.224.193) |
| 10:23.19 | *** join/#oe bluca (~bluca@88.98.246.218) |
| 10:25.30 | *** part/#oe bluca (~bluca@88.98.246.218) |
| 11:02.22 | *** join/#oe comptroller (~comptroll@47-213-222-253.paolcmtc01.res.dyn.suddenlink.net) |
| 11:08.00 | *** join/#oe florian (~florian_k@Maemo/community/contributor/florian) |
| 11:32.02 | *** join/#oe berton (~berton@181.220.86.53) |
| 11:35.11 | *** join/#oe dv_ (~dv@62-178-50-190.cable.dynamic.surfer.at) |
| 12:01.49 | *** join/#oe radsquirrel (~bradleyb@mail.fuzziesquirrel.com) |
| 13:22.05 | *** join/#oe andre_d (~user@77.107.218.170) |
| 13:49.56 | *** join/#oe AndersD (~AndersD@h83-209-191-235.cust.a3fiber.se) |
| 13:51.42 | *** join/#oe AndersD_ (~AndersD@h-98-128-162-82.NA.cust.bahnhof.se) |
| 14:00.44 | *** join/#oe tanuk_ (~quassel@91-152-158-222.elisa-laajakaista.fi) |
| 14:01.15 | *** join/#oe pespin__ (~Sharwin_F@espeweb.net) |
| 14:12.09 | *** join/#oe jaeckel (~jaeckel@unaffiliated/jaeckel) |
| 14:14.12 | *** join/#oe vquicksilver (~nobody@gentoo/contributor/vquicksilver) |
| 14:25.35 | *** join/#oe bluelightning (~paul@pdpc/supporter/professional/bluelightning) |
| 14:27.41 | *** join/#oe vmeson (~rmacleod@24-52-238-240.cable.teksavvy.com) |
| 14:32.06 | *** join/#oe mrc3 (mrc3@linaro/mrc3) |
| 15:29.03 | *** join/#oe florian_kc (~florian_k@Maemo/community/contributor/florian) |
| 15:50.48 | mnemoc | hi, I have a variable that is calculated from `git describe` across BBPATH, the build directory and the (repo) manifest used to populate the workspace |
| 15:51.18 | mnemoc | this variable is assigned as PV to some packages, including packagegroups and images |
| 15:51.53 | mnemoc | unfortunatelly, if anything changes on the workspace during the build, the signatures check goes bunkers |
| 15:52.12 | mnemoc | s/bunkers/bonkers/ |
| 15:53.23 | mnemoc | the variable in question is set on a bbclass via "${@....}" |
| 15:54.30 | mnemoc | the most frustrating part is that is no way to recover from this basehash-changed state... not even `-c cleansstate` lets me carry on |
| 15:55.42 | mnemoc | any suggestion on how to annotate this variable so it makes bitbake just build the new PV? or not recalculate the variable during the build? |
| 15:56.33 | *** join/#oe Bunio_FH (~bunio@clj-165.netdrive.pl) |
| 16:05.40 | khem | mnemoc: you need two passes here |
| 16:05.55 | khem | so have tooling to calculate it first and feed it into yocto metadata |
| 16:08.08 | mnemoc | as environment when calling bitbake you mean? |
| 16:09.44 | mnemoc | or there is a mechnamism without yocto for this pre-build pass? |
| 16:09.50 | mnemoc | within* |
| 16:11.45 | khem | the latter .. |
| 16:13.07 | *** join/#oe Bunio_FH (~bunio@clj-165.netdrive.pl) |
| 16:13.25 | mnemoc | khem: any suggestion on what to look at as example (or documentation?) |
| 16:17.06 | khem | fundamentally once you invoke bitbake then the metadata should be static until end of build |
| 16:17.24 | khem | so any setups you need to do need to happen before or after |
| 16:17.29 | khem | for best results |
| 16:17.35 | khem | I dont have any open example |
| 16:18.17 | khem | I assume you know best the logic your workspace is trying to execute so you probably can comeup with the separation logic |
| 16:21.16 | mnemoc | khem: yes, the actual implementation is obviusly on me. i was wondering how to inject the variable into the metadata in a way that doesn't recalculate "accidentally" |
| 16:22.25 | mnemoc | with my limited understanding of bitbake I can only think on wrapping `bitbake` and pass the value as an external literal |
| 16:22.38 | mnemoc | but I got the impression there is a proper method |
| 16:29.23 | mnemoc | and doing it externally I won't have BBPATH so I would need to understand bblayers |
| 16:29.26 | mnemoc | :( |
| 16:30.10 | khem | you can generate say global conf/site.conf file |
| 16:30.16 | khem | externally |
| 16:35.24 | mnemoc | how evil would be to generate a $TMPDIR/foo-${DATETIME) file from the distro conf and use it as cache? conf/site.conf surely sounds better than messing with the env, but I would make assumtions about the /user's/ build directory |
| 16:38.11 | paulbarker | mnemoc: I always handle this sort of variable by wrapping bitbake, exporting it in the env and adding the variable to BB_ENV_EXTRAWHITE |
| 16:38.30 | paulbarker | That way it doesn't get changed after bitbake has been invoked |
| 16:40.02 | mnemoc | paulbarker: thanks, i'll bite that bullet |
| 16:43.58 | mnemoc | i really really wanted to find a hook somewhere safe but under bitbake's control |
| 16:45.09 | paulbarker | mnemoc: You may be able to do this by some magic but it's probably much simpler to just wrap bitbake |
| 16:45.52 | mnemoc | very true. I've been three days fighting this thing already |
| 16:49.33 | paulbarker | Setting PV dynamically is essentially a huge hassle as the working directory for the build is based on that value |
| 16:50.15 | paulbarker | If you really want to go down the 'magic' route you should look into how ${AUTOREV} updates PV safely |
| 16:50.54 | mnemoc | paulbarker: great pointer! |
| 16:52.34 | paulbarker | Actually, the trick may be that it updates PKGV instead of PV so the workdir path doesn't change |
| 16:56.03 | JaMa | meta-oe/classes/gitpkgv.bbclass might help with that |
| 17:05.09 | *** join/#oe Crofton (~Crofton@c-73-152-143-112.hsd1.va.comcast.net) |
| 17:08.30 | mnemoc | thanks a lot |
| 17:40.43 | mnemoc | using PKGV instead of PV on the packagegroups didn't fix the /non determinism/ of the signature :( |
| 17:47.42 | *** join/#oe ensc|w (~ensc@fedora/ensc) |
| 18:09.02 | *** join/#oe dqx_ (~dqx@unaffiliated/dqx) |
| 18:21.27 | *** join/#oe bluelightning (paul@pdpc/supporter/professional/bluelightning) |
| 18:22.39 | *** join/#oe florian_kc (~florian_k@Maemo/community/contributor/florian) |
| 18:24.32 | *** join/#oe Crofton (~balister@2601:5c0:c100:b84:c22d:c40:ab44:9e37) |
| 18:39.55 | *** join/#oe fischerm (~mfischer@207.114.172.147) |
| 18:51.48 | *** join/#oe armpit (~armpit@45.19.219.178) |
| 19:14.18 | *** join/#oe tnovotny (~tnovotny@176-74-132-138.netdatacomm.cz) |
| 20:30.15 | *** join/#oe ao2 (~ao2@87.19.81.128) |
| 20:42.06 | *** join/#oe troulouliou_div2 (~troulouli@unaffiliated/troulouliou-div2/x-0271439) |
| 21:35.14 | *** join/#oe troulouliou_div2 (~troulouli@unaffiliated/troulouliou-div2/x-0271439) |
| 21:38.40 | *** join/#oe troulouliou_div2 (~troulouli@unaffiliated/troulouliou-div2/x-0271439) |
| 22:53.36 | *** join/#oe armpit (~armpit@2601:202:4180:c33:a1cd:b182:87c0:f84e) |
| 23:03.32 | *** join/#oe JaMa (~martin@ip-217-030-068-212.aim-net.cz) |