| 01:21.14 | armpit | kergoth, does bitbake lib/bb/__init__.py need its version match that of bin/bitbake ? |
| 01:23.19 | armpit | notes 1.42.0 does not and does not know if that will be a problem |
| 02:23.57 | *** join/#oe keith (keith@kodi/staff/keith) |
| 02:54.24 | kergoth | i.. have no idea |
| 04:06.19 | keith | https://www.irccloud.com/pastebin/Bf8SkMtM/ |
| 04:06.29 | keith | er, sorry. |
| 04:06.36 | keith | https://www.irccloud.com/pastebin/9iJkzJn1/ |
| 04:06.36 | keith | Anyone used meta-python lately in OE? |
| 04:40.44 | *** join/#oe bluelightning_ (~paul@pdpc/supporter/professional/bluelightning) |
| 05:03.33 | *** join/#oe armpit (~armpit@2601:202:4180:c33:3979:dabc:ad30:adf) |
| 05:10.13 | *** join/#oe AndersD (~AndersD@194-237-220-218.customer.telia.com) |
| 05:15.59 | *** join/#oe AndersD (~AndersD@194-237-220-218.customer.telia.com) |
| 05:39.10 | *** join/#oe AndersD (~AndersD@194.237.220.218) |
| 06:11.16 | *** join/#oe tprrt (~tprrt@217.114.201.133) |
| 06:35.34 | *** join/#oe ao2 (~ao2@host246-206-dynamic.27-79-r.retail.telecomitalia.it) |
| 07:05.56 | *** join/#oe dagmcr (sid323878@gateway/web/irccloud.com/x-dlwghcddeabszlee) |
| 07:06.25 | *** join/#oe fl0v0 (~fvo@88.130.216.123) |
| 07:10.56 | *** join/#oe Bunio_FH (~bunio@81-18-201-214.static.chello.pl) |
| 07:14.11 | *** join/#oe lusus (~lusus@62.91.23.180) |
| 07:20.06 | *** join/#oe florian (~florian_k@Maemo/community/contributor/florian) |
| 07:26.24 | *** join/#oe kroon (~jkroon@213.185.29.22) |
| 07:29.43 | *** join/#oe JaMa (~martin@ip-217-030-068-212.aim-net.cz) |
| 07:31.36 | *** join/#oe andre_d (~user@77.107.218.170) |
| 07:33.56 | kroon | Is anyone using grub2 ? I can't find any place in oe-core's image generation code where grub-* tools are called.. |
| 07:36.04 | *** join/#oe BlastuR (~magnus@unaffiliated/blastur) |
| 07:38.19 | *** join/#oe hrw (~hrw@redhat/hrw) |
| 07:48.46 | *** join/#oe hrw (~hrw@redhat/hrw) |
| 07:50.57 | *** join/#oe leon-anavi (~Leon@78.130.245.106) |
| 07:53.42 | *** join/#oe hrw (~hrw@redhat/hrw) |
| 07:56.32 | *** join/#oe tnovotny (~tnovotny@176-74-132-138.netdatacomm.cz) |
| 07:56.51 | *** join/#oe rob_w (~bob@unaffiliated/rob-w/x-1112029) |
| 08:16.26 | *** join/#oe florian (~florian_k@Maemo/community/contributor/florian) |
| 08:25.13 | *** join/#oe hrw (~hrw@redhat/hrw) |
| 09:16.31 | *** join/#oe troulouliou_div2 (~troulouli@unaffiliated/troulouliou-div2/x-0271439) |
| 09:20.17 | *** join/#oe awe00 (~awe00@unaffiliated/awe00) |
| 09:44.41 | *** join/#oe bluelightning (~paul@pdpc/supporter/professional/bluelightning) |
| 09:49.00 | *** join/#oe sk_tandt (~sk_tandt@net-5-88-141-17.cust.vodafonedsl.it) |
| 10:57.33 | *** join/#oe awe00 (~awe00@unaffiliated/awe00) |
| 11:07.53 | *** join/#oe bluelightning (~paul@pdpc/supporter/professional/bluelightning) |
| 11:08.41 | *** join/#oe awe00 (~awe00@unaffiliated/awe00) |
| 11:31.52 | *** join/#oe awe00 (~awe00@unaffiliated/awe00) |
| 11:50.37 | *** join/#oe awe00 (~awe00@unaffiliated/awe00) |
| 12:01.11 | *** join/#oe comptroller (~comptroll@47-213-222-253.paolcmtc01.res.dyn.suddenlink.net) |
| 13:13.13 | ensc|w | is it possible that layer submission at http://layers.openembedded.org is broken? When I enter a gitlab url, a wrong webinterface type ("(custom)") is selected, uris are incorrect and can can not be changed |
| 13:22.44 | ensc|w | why are dots (.) prohibited in layer names there? |
| 13:28.39 | *** join/#oe berton (~berton@177.194.197.186) |
| 13:30.35 | *** join/#oe tprrt (~tprrt@217.114.201.133) |
| 13:34.42 | *** join/#oe awe00 (~awe00@unaffiliated/awe00) |
| 13:42.31 | *** join/#oe berton (~berton@177.194.197.186) |
| 13:43.51 | *** join/#oe awe00 (~awe00@unaffiliated/awe00) |
| 13:49.04 | *** join/#oe vmeson (~rmacleod@24-52-238-240.cable.teksavvy.com) |
| 13:49.20 | kroon | I have a do_deploy() that uses files from SRC_URI. Those files seem to get wiped by rm_work inbetween rebuilds I think. Is there a way I should mark those files, so that they get re-populated by setscene tasks, or something like that ? |
| 14:19.06 | *** join/#oe laplante (0422c024@gateway/web/freenode/ip.4.34.192.36) |
| 14:20.00 | laplante | hopefully easy question - I'm writing a tool using tinfoil and I want to make sure BB_SRCREV_POLICY is set to 'cache'. Does anyone know a programmatic way of doing this? |
| 14:23.57 | *** join/#oe awe00 (~awe00@unaffiliated/awe00) |
| 14:24.59 | laplante | nvm, looks like I can create a temporary post.conf with "BB_SRCREV_POLICY = 'cache'", then create a TinfoilConfigParameters with postfile=["post.conf"] which I pass to tinfoil.prepare() |
| 14:43.34 | *** join/#oe tsjsieb (~quassel@2a06:5b80:1::2be3:ec4) |
| 15:14.35 | *** join/#oe awe00 (~awe00@unaffiliated/awe00) |
| 15:38.09 | *** join/#oe awe00 (~awe00@unaffiliated/awe00) |
| 15:43.23 | *** join/#oe armpit (~armpit@2601:202:4180:c33:8494:4fff:a33b:98ac) |
| 15:47.48 | kergoth | laplante: just parse the config, setVar() the value the way you want it, then parse whatever recipes you need after that |
| 15:47.56 | kergoth | but yes, that'd work too |
| 15:48.41 | *** join/#oe awe00 (~awe00@unaffiliated/awe00) |
| 15:55.24 | *** join/#oe vmeson (~rmacleod@24-52-238-240.cable.teksavvy.com) |
| 16:00.07 | laplante | kergoth: OK, thanks for the tip. |
| 16:53.18 | laplante | kergoth: if I wanted to do it your way, on which object do I call setVar? the Tinfoil itself? |
| 16:58.33 | laplante | kergoth: nvm again, looks like tinfoil.config_data.setVar. Sorry for spam. |
| 17:01.34 | kergoth | yep, on the config metadata |
| 17:01.37 | kergoth | np |
| 17:11.51 | laplante | kergoth: loving this API :) really powerful |
| 17:22.23 | *** join/#oe aduskett (~aduskett@68-188-149-81.dhcp.aldl.mi.charter.com) |
| 17:33.13 | laplante | kergoth: actually, I think it's not possible to do what I want with BB_SRCREV_POLICY without resorting to a temporary file like I initially described. Tinfoil.prepare(config_only=True) ends up calling bb.fetch.fetcher_init, and since BB_SRCREV_POLICY isn't set yet it defaults to clear. So by the time I try to set BB_SRCREV_POLICY to cache, it's too late - the cache is gone. |
| 17:37.09 | *** join/#oe dustinm` (~dustinm@68.ip-149-56-14.net) |
| 17:42.39 | kergoth | ah, that's interesting |
| 17:59.04 | *** join/#oe kroon (~jkroon@37-247-29-68.customers.ownit.se) |
| 18:21.48 | laplante | kergoth: would you be interested in a patch that added a new flag to bitbake (and transitively BitBakeConfigParameters and TinfoilConfigParameters), "--cache-srcrevs", which ensures BB_SRCREV_POLICY = "cache" is set from the get-go? |
| 18:42.58 | kergoth | hmm, possibly? I'd suggest emailing the bitbake-devel list iwth a RFC |
| 18:47.32 | laplante | kergoth: OK, will think about it. Thanks |
| 18:49.54 | kergoth | obviously doesn't harm anything, just wondering how common the use case will be |
| 18:54.57 | laplante | laplante: personally, I use it in a continuous integration environment where I am building images for multiple target machines. I want to ensure common components between the machines are built from the same upstream revisions (we use AUTOREV a lot), and so BB_SRCREV_POLICY is how I ensure that. In the future, when multiconfig because more mature, I'll use that instead. |
| 18:55.27 | laplante | oops didn't mean to use my own nick |
| 19:00.32 | kergoth | ah, that makes sense. lock it down for the duration of the CI job. |
| 19:00.44 | kergoth | i could see it being accepted with that use case in mind specifically |
| 19:01.56 | laplante | kergoth: sweet, now I just hope I can find time to work on the patch and RFC :) |
| 19:07.09 | kergoth | we use SRCREV_POLICY at metnor for product releases. mentor embedded linux installers include sources, set cache, and include a autorevs.conf emitted by buildhistory-collect-srcrevs to fix BB_NO_NETWORK operation for AUTOREV recipes |
| 19:13.12 | *** join/#oe awe00 (~awe00@unaffiliated/awe00) |
| 19:18.56 | laplante | kergoth: gotcha - that's very similar to what we're doing. Up until today actually, we were essentially using a homemade autorevs.conf generator (which I wrote at a time I didn't understand buildhistory). It became too ugly and broken, so I am in the process right now of moving us over to buildhistory-collect-srcrevs. |
| 19:19.34 | kergoth | we tried to tell the devs to just stop using AUTOREVS, but yeah.. not going to happen :) |
| 19:20.50 | laplante | Unfortunately (or fortunately, which is IMO my stance) we use AUTOREV everywhere for our internal recipes. devtool is basically our entire development workflow. I also parameterize every SRC_URI with a "BRANCH" variable, to make it easy to not only override SRCREV but also the branch from local.conf or whatever. |
| 19:21.30 | laplante | I have tweaks to devtool I'd like to upstream that respect the BRANCH automatically (instead of having to pass -b every time) |
| 19:22.07 | laplante | Additonally I'm working on extending buildhistory-collect-srcrevs (via the external Python script I'm working as we type) that exports the BRANCH variable alongside SRCREVs. |
| 19:24.41 | *** join/#oe bluelightning (~paul@pdpc/supporter/professional/bluelightning) |
| 19:25.30 | *** join/#oe khem (~khem@unaffiliated/khem) |
| 19:39.12 | kergoth | sounds useful given how picky the fetcher is about srcrev being in a specified branch |
| 19:40.27 | laplante | glad you think so; I look forward to upstreaming it :) |
| 19:41.40 | *** join/#oe florian (~florian_k@Maemo/community/contributor/florian) |
| 20:18.18 | *** join/#oe ao2 (~ao2@host246-206-dynamic.27-79-r.retail.telecomitalia.it) |
| 20:33.58 | *** join/#oe bluelightning (~paul@pdpc/supporter/professional/bluelightning) |
| 21:25.43 | *** join/#oe tprrt (~tprrt@upc31-1-78-208-110-13.fbx.proxad.net) |
| 21:29.44 | *** join/#oe bluelightning (~paul@pdpc/supporter/professional/bluelightning) |
| 22:28.03 | *** join/#oe georgem_home (uid210681@gateway/web/irccloud.com/x-ccyfacywrtkvhrjr) |
| 22:33.27 | *** join/#oe dqx_ (~dqx@unaffiliated/dqx) |
| 22:56.45 | *** join/#oe dqx_ (~dqx@unaffiliated/dqx) |
| 23:39.09 | *** join/#oe JaMa (~martin@ip-217-030-068-212.aim-net.cz) |