*** nrossi <nrossi!nrossimatr@gateway/shell/matrix.org/x-jatmjaeghdtmpizr> has joined #yocto | 02:38 | |
*** Bunio_FH <Bunio_FH!~bunio@clj-165.netdrive.pl> has quit IRC | 02:49 | |
* armpit arrrg... zeddii forgot to update kernel-cache version for 4.14.. should be .154 now | 02:52 | |
*** bcran <bcran!~bcran@muon.bluestop.org> has joined #yocto | 02:57 | |
*** mrc3 <mrc3!~mrc3@linaro/mrc3> has joined #yocto | 03:36 | |
*** nslu2-log <nslu2-log!~nslu2-log@milla.nas-admin.org> has joined #yocto | 04:43 | |
*** armpit <armpit!~armpit@2601:202:4180:a5c0:49d0:4aef:f5f:565e> has quit IRC | 05:40 | |
*** armpit <armpit!~armpit@2601:202:4180:a5c0:1527:dedf:f05:266c> has joined #yocto | 05:53 | |
*** pohly <pohly!~pohly@p54BD5C64.dip0.t-ipconnect.de> has joined #yocto | 06:19 | |
*** fatalhalt <fatalhalt!~fatalhalt@2601:244:4d01:52df:225:90ff:feda:2428> has quit IRC | 06:22 | |
*** fatalhalt <fatalhalt!~fatalhalt@2601:244:4d01:52df:225:90ff:feda:2428> has joined #yocto | 06:33 | |
*** AndersD <AndersD!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has joined #yocto | 06:44 | |
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has joined #yocto | 07:01 | |
*** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has joined #yocto | 07:03 | |
*** guerinoni <guerinoni!~guerinoni@internet.micro-systems.it> has joined #yocto | 07:05 | |
*** rburton <rburton!~rburton@35.106.2.81.in-addr.arpa> has joined #yocto | 07:06 | |
*** ThomasD13 <ThomasD13!~ThomasD13@DSL01.212.114.255.148.ip-pool.NEFkom.net> has joined #yocto | 07:07 | |
*** agust <agust!~agust@p5483338F.dip0.t-ipconnect.de> has joined #yocto | 07:28 | |
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has quit IRC | 07:33 | |
*** alessioigor <alessioigor!8c69cfe3@out-207-227.elettra.trieste.it> has joined #yocto | 07:35 | |
*** yann|work <yann|work!~yann@91-170-159-152.subs.proxad.net> has quit IRC | 07:55 | |
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has joined #yocto | 07:57 | |
*** lfa <lfa!~lfa@217.19.35.51> has joined #yocto | 08:02 | |
*** locutus_ <locutus_!~LocutusOf@ubuntu/member/locutusofborg> has joined #yocto | 08:05 | |
*** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has quit IRC | 08:07 | |
*** lucaceresoli <lucaceresoli!~lucaceres@45.11.168.109.cust.ip.kpnqwest.it> has joined #yocto | 08:10 | |
*** diego_r <diego_r!~diego@217-133-17-98.static.clienti.tiscali.it> has joined #yocto | 08:22 | |
*** hpsy <hpsy!~hpsy@217.66.60.5> has joined #yocto | 08:36 | |
*** TobSnyder <TobSnyder!~schneider@ip5f5aa32f.dynamic.kabel-deutschland.de> has joined #yocto | 08:43 | |
*** yann|work <yann|work!~yann@85.118.38.73> has joined #yocto | 08:58 | |
*** leon-anavi <leon-anavi!~Leon@78.130.245.67> has joined #yocto | 09:05 | |
*** goliath <goliath!~goliath@82.150.214.1> has joined #yocto | 09:12 | |
*** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has joined #yocto | 09:13 | |
*** Bunio_FH <Bunio_FH!~bunio@81-18-201-214.static.chello.pl> has joined #yocto | 09:17 | |
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto | 09:31 | |
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC | 09:35 | |
*** florian_kc is now known as florian | 09:41 | |
RP | khem: FWIW the binutils upgrade looks fine on the AB | 09:48 |
---|---|---|
*** sashko <sashko!~sashko@83.218.80.243> has joined #yocto | 09:51 | |
sashko | hi! is there a way to remove inherit from a recipe with bbappend? | 09:51 |
yocti | New news from stackoverflow: How to exclude opencv compilation from Yocto image? <https://stackoverflow.com/questions/59245952/how-to-exclude-opencv-compilation-from-yocto-image> | 09:51 |
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has quit IRC | 09:52 | |
LetoThe2nd | sashko: no, i dont' think so. | 09:54 |
RP | sashko: not really, no | 10:01 |
sashko | thanks! | 10:01 |
RP | khem: binutils looks fine | 10:10 |
*** hpsy <hpsy!~hpsy@217.66.60.5> has quit IRC | 10:14 | |
*** hpsy <hpsy!~hpsy@217.66.60.5> has joined #yocto | 10:14 | |
*** silviof <silviof!silv-iomat@gateway/shell/matrix.org/x-gwflfyxktyivjeax> has quit IRC | 10:16 | |
*** nrossi <nrossi!nrossimatr@gateway/shell/matrix.org/x-jatmjaeghdtmpizr> has quit IRC | 10:16 | |
*** bachp <bachp!bachpmatri@gateway/shell/matrix.org/x-yfkjezgtdhnedjug> has quit IRC | 10:16 | |
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has quit IRC | 10:19 | |
*** mihai <mihai!~mihai@unaffiliated/mihai> has joined #yocto | 10:24 | |
rburton | PY2 IS NOT LONGER A HOST REQUIREMENT THIS IS NOT A DRILL PY2 IS NO LONGER A HOST REQUIREMENT | 10:31 |
rburton | if it wasnt 10am i'd crack open a gin to celebrate | 10:31 |
LetoThe2nd | rburton: so, why not? | 10:32 |
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto | 10:32 | |
RP | rburton: haha :) | 10:36 |
RP | Its nice to reach this point | 10:36 |
LetoThe2nd | drinking at 10am? | 10:39 |
LetoThe2nd | hell yeah! | 10:39 |
*** JaMa <JaMa!~martin@109.238.218.228> has joined #yocto | 10:55 | |
LetoThe2nd | is there some variable that is unique to a bitbake run? | 10:59 |
RP | LetoThe2nd: DATETIME ? | 10:59 |
LetoThe2nd | RP: will cause headaches probably, as it triggers the non-deterministic warnings | 11:00 |
RP | LetoThe2nd: so you just vardeps exclude it? | 11:00 |
LetoThe2nd | but then it will lift the recipe out of being run i only DATETIME has changed, right? | 11:02 |
qschulz | yup | 11:06 |
rburton | LetoThe2nd: what do you want to do with this unique variable | 11:08 |
LetoThe2nd | rburton: we're still trying to tackle a problem with inter-multiconfig dependencies that are caused by specific image types. | 11:09 |
LetoThe2nd | but we're really, really close to just stick in a nostamp on the fetching task in the depending multiconfig recipe by now, so much human time has already been burnt that the additional cycles start to appear cheaper. | 11:11 |
*** nrossi <nrossi!nrossimatr@gateway/shell/matrix.org/x-lgzmahlwjdzyjftc> has joined #yocto | 11:14 | |
*** silviof <silviof!silv-iomat@gateway/shell/matrix.org/x-aewxyybrfqnlptda> has joined #yocto | 11:14 | |
*** bachp <bachp!bachpmatri@gateway/shell/matrix.org/x-asshazipkjnvfdhr> has joined #yocto | 11:14 | |
rburton | RP: doing a build spin of next here before giving it my +1 :) | 11:17 |
RP | rburton: fair enough | 11:20 |
*** rubdos <rubdos!~rubdos@2a02:578:859d:700:8b44:5716:382d:a7da> has quit IRC | 11:20 | |
yocti | New news from stackoverflow: How to get the ARM tool chain with poky? <https://stackoverflow.com/questions/59048325/how-to-get-the-arm-tool-chain-with-poky> || Having Angstrom build and Poky build in one repository <https://stackoverflow.com/questions/59247336/having-angstrom-build-and-poky-build-in-one-repository> | 11:22 |
kanavin__ | RP: thanks, I probably was far too optimistic about the big upgrade patchset. Certainly should be approached piece by piece. | 11:32 |
RP | kanavin__: I'd pushed out all the problem pieces I could spot and -next is now building ok. I'll probably take -next as it stands and build M1 with that, then we can work through the problematic pieces in M2 | 11:33 |
*** berton <berton!~berton@189.103.49.163> has joined #yocto | 11:42 | |
*** berton <berton!~berton@189.103.49.163> has quit IRC | 11:47 | |
*** berton <berton!~berton@189.103.49.163> has joined #yocto | 11:50 | |
rburton | RP: next looks good | 11:54 |
RP | rburton: cool. I shall merge. Does this mean we're ready for M1? | 11:55 |
RP | rburton: there are other patches around but I think we draw the line here? | 11:55 |
rburton | just rebasing mut to see what else i had hanging around | 11:56 |
rburton | oh theres a cve fix which might be super useful | 11:56 |
RP | rburton: which one? | 11:56 |
rburton | the cve-check one | 11:56 |
RP | rburton: master updated fwiw | 11:57 |
RP | rburton: ah, the version one | 11:57 |
rburton | right | 11:57 |
rburton | just testing now | 11:57 |
RP | rburton: ok, let me know. Tempted to then roll M1 | 11:57 |
rburton | upstream-status fix on the list ;) | 11:59 |
RP | rburton: ah, will merge | 12:00 |
rburton | cve check fix appears to be fine | 12:05 |
RP | rburton: instantly have another 10 patches in -next, including live removal | 12:05 |
RP | rburton: M2 though I think | 12:05 |
rburton | yes | 12:05 |
rburton | i need to double check all the other bits about live removal | 12:05 |
RP | rburton: I will trigger M1 then, thanks | 12:06 |
*** distrozapper <distrozapper!~distrozap@p200300E60F02D000BD019004C2114902.dip0.t-ipconnect.de> has joined #yocto | 12:09 | |
*** distrozapper <distrozapper!~distrozap@p200300E60F02D000BD019004C2114902.dip0.t-ipconnect.de> has quit IRC | 12:14 | |
rburton | RP: fire in the hole! | 12:20 |
Ad0 | maybe a dumb question, but can't qemuarm machine config have a UBOOT_MACHINE ? | 12:28 |
LetoThe2nd | Ad0: you could probably make it use one, but its uncommen. | 12:30 |
Ad0 | ok | 12:30 |
LetoThe2nd | Ad0: for most people it like, "u-boot get out of my way as quickly as possible". and as qemu can directly boot into a kernel, theres no reason even to get *into* your way first. | 12:31 |
Ad0 | I see | 12:32 |
kanavin__ | RP: I am not sure I understand the errors here, particularly the at-spi2 stuff seems to be building a previous version rather than the one I sent an update for? http://errors.yoctoproject.org/Errors/Latest/?filter=2cfc5dd223815df65d2001a6a9c352eadf936f94&type=commit&limit=150&page=1 | 12:35 |
RP | kanavin__: It could well be I got lost in the patches with that. I dropped them simply as I was hitting failures and couldn't quite see what was wrong | 12:35 |
kanavin__ | RP: right, or maybe you dropped at-spi2-atk, but not at-spi2-core or atk, and that caused a mismatch | 12:36 |
RP | kanavin__: right, its possible. I had to do something to try and partition the problems so I was pretty ruthless with failures. Rsend them in the next batch and we can test in isolation with the right patchset | 12:37 |
kanavin__ | RP: yep, generally centos 7 seems to be getting in the way of updates more and more lately :-/ | 12:39 |
RP | kanavin__: right, we are working on centos8 but that has different problems michael is working on | 12:39 |
*** berton_ <berton_!~berton@189.103.49.163> has joined #yocto | 12:40 | |
*** berton <berton!~berton@189.103.49.163> has quit IRC | 12:43 | |
yocti | New news from stackoverflow: Yocto / OE : recipe with CMake install a shared library .so <https://stackoverflow.com/questions/59091938/yocto-oe-recipe-with-cmake-install-a-shared-library-so> | 12:52 |
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has quit IRC | 13:14 | |
*** tgamblin <tgamblin!~tgamblin@128.224.252.2> has joined #yocto | 13:17 | |
*** guerinoni <guerinoni!~guerinoni@internet.micro-systems.it> has quit IRC | 13:34 | |
*** bluca <bluca!~bluca@88.98.246.218> has joined #yocto | 13:50 | |
ThomasD13 | Are here some linux memory specialists? :) Regarding physical and logical addresses (ioremap vs phys_to_virt) | 14:03 |
*** AndersD <AndersD!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has quit IRC | 14:06 | |
LetoThe2nd | ThomasD13: you have a considerably higher chance of getting an answer if you ask about your *actual* problem | 14:10 |
* zeddii sees armpit’s question / comment from last night .. I pushed the kernel-cache update this morning. | 14:11 | |
ThomasD13 | Thats the way to go: I'm on a AARCH64 device. I allocate via "request_mem_region" 256 MB starting from physical address 0x4000 0000. After mapping this memory via "ioremap_nocache" into kernel virtual address space, I have noticed a difference when I use "phys_to_virt" function. | 14:16 |
*** iceaway <iceaway!~pelle@37.233.78.69> has joined #yocto | 14:16 | |
iceaway | I am trying to include mono in my image, so I have cloned the meta-mono layer and checkout out the branch for my Yocto version (sumo). When I try to include Yocto I get the following error: nothing provides mono-gac needed by mono-5.12.0.226-r0.aarch64 | 14:17 |
ThomasD13 | I'm little bit confused about this. I thought the purpose of phys_to_virt should be to translate physical addresses to virtual ones. | 14:18 |
ThomasD13 | But the address I got from phys_to_virt seems to be wrong in my case. | 14:18 |
iceaway | But the mono-gac package SHOULD be provided by the mono-package itself. If I do bitbake mono-gac I get: mono RPROVIDES mono-gac | 14:18 |
qschulz | iceaway: there's a difference between provides and rprovides. provides is used to resolve DEPENDS and is at least the name of the recipe (can be something else if there's a PROVIDES set in the recipe). rprovides is for packages so either to resolve RDEPENDS or IMAGE_INSTALL, RRECOMMENDS, etc... | 14:23 |
iceaway | qschulz: ahhh did not see the little 'r' there. | 14:25 |
iceaway | If I do "bitbake -e mono" and look for DEPENDS, it does not DEPEND on mono-gac but it RDEPENDS on it. Not sure if that makes me any the wiser though on how to resolve this. | 14:31 |
qschulz | I don't remember how the error message is crafted, but might be that a dependency if mono is missing mono-gac | 14:33 |
qschulz | if/of/ | 14:34 |
iceaway | So If I only include mono in my image (which depends on mono-gac), would not bitbake automatically pick up and build/include the mono-gac dependency? | 14:38 |
qschulz | it does not depend on mono-gac, it rdepends on it is what you said | 14:39 |
qschulz | but yes, however it should be an issue at build time, what the error message you sent is saying | 14:39 |
*** bernardoaraujo <bernardoaraujo!uid179602@gateway/web/irccloud.com/x-vumbctcbyunqnwme> has joined #yocto | 14:42 | |
*** fl0v0 <fl0v0!~fvo@i5E869742.versanet.de> has joined #yocto | 14:46 | |
*** junland <junland!~junland@142.93.201.46> has quit IRC | 14:47 | |
qschulz | iceaway: can you paste somewhere the whole error log? | 14:48 |
*** junland <junland!~junland@142.93.201.46> has joined #yocto | 14:48 | |
iceaway | qschulz: sure! give me a minute. | 14:50 |
*** locutus_ <locutus_!~LocutusOf@ubuntu/member/locutusofborg> has quit IRC | 14:52 | |
fl0v0 | Hi, can somebody explain to me how the do_merge_delta_config task in the linux recipe (imx) is supposed to work? I get the merged defconfig in the WORKDIR but it doesnt seem to be used. Do i need a extra task to copy it somewhere? (The recipe: https://pastebin.com/rYfLSAbz) | 14:52 |
*** AndersD <AndersD!~AndersD@h83-209-191-235.cust.a3fiber.se> has joined #yocto | 14:53 | |
*** LocutusOfBorg <LocutusOfBorg!~LocutusOf@ubuntu/member/locutusofborg> has joined #yocto | 14:59 | |
iceaway | qschulz: https://pastebin.com/dMNjTPVV | 15:00 |
*** AndersD <AndersD!~AndersD@h83-209-191-235.cust.a3fiber.se> has quit IRC | 15:07 | |
fl0v0 | just found out, that the correct merged config is in './build/config.old'. But the '.config' contains the unmerged config. Any ideas? | 15:09 |
qschulz | iceaway: the recipe looks correct though. PACKAGECONFIG ??= "gac" and PACKAGECONFIG[gac] = ",,mono-gac" with mono-gac being a package with files defined in FILES_${PN}-gac | 15:12 |
qschulz | fl0v0: what's run after merge_delta_config? (i'm looking for preconfigure task especially) | 15:16 |
iceaway | qschulz: Yeah I think it looks reasota | 15:18 |
iceaway | reasonable too. | 15:18 |
fl0v0 | qschulz: do_preconfigure is run after merge_delta_config | 15:19 |
*** roussinm <roussinm!~mroussin@ipagstaticip-d73c7528-4de5-0861-800b-03d8b15e3869.sdsl.bell.ca> has joined #yocto | 15:20 | |
fl0v0 | do_merge_delta_config (30346): log.do_merge_delta_config.30346 | 15:20 |
fl0v0 | do_copy_custom_device_tree_files (30345): log.do_copy_custom_device_tree_files.30345 | 15:20 |
fl0v0 | do_preconfigure (30774): log.do_preconfigure.30774 | 15:20 |
fl0v0 | this is an excerpt from log.task_order | 15:20 |
qschulz | fl0v0: I meant what's inside that task. If you can point a git repo with the file with that task it'd be good help I think | 15:22 |
RP | rburton: hashequiv build breakage on rc1. After it all worked :/ | 15:23 |
rburton | damnit | 15:23 |
fl0v0 | qschulz: there seems not much to be happening in that task :/ thats the whole log: | 15:25 |
fl0v0 | DEBUG: Executing shell function do_preconfigure | 15:25 |
fl0v0 | DEBUG: Shell function do_preconfigure finished | 15:25 |
fl0v0 | i try to find it. it must be inherited by recipes-kernel/linux/linux-imx.inc | 15:27 |
fl0v0 | This file is here https://git.yoctoproject.org/cgit/cgit.cgi/meta-freescale/tree/recipes-kernel/linux?h=thud | 15:29 |
fl0v0 | what on the other hand includes the poky kernel.bbclass | 15:30 |
JPEW | RP: Have a link? | 15:32 |
RP | https://autobuilder.yoctoproject.org/typhoon/#/builders/97/builds/673 https://autobuilder.yoctoproject.org/typhoon/#/builders/47/builds/1344 | 15:33 |
RP | JPEW: ^^^ | 15:33 |
JPEW | rburton: I think the last piece for reproducible core-image-sato and core-image-full-cmdline is your pod2man changes | 15:33 |
fl0v0 | qschulz: found it https://git.yoctoproject.org/cgit/cgit.cgi/meta-freescale/tree/classes/fsl-kernel-localversion.bbclass?h=thud | 15:33 |
RP | JPEW: probably https://autobuilder.yoctoproject.org/typhoon/#/builders/69/builds/1335 too | 15:33 |
RP | JPEW: and https://autobuilder.yoctoproject.org/typhoon/#/builders/69/builds/1335 is something different | 15:34 |
JPEW | RP: Looks like the sstate object that it's looking for isn't actually in the sstate cache? | 15:40 |
JPEW | a31ad8d78bc45b8575eac43b477679ce2c4c211a39a72503b71fa251db700edb | 15:40 |
RP | JPEW: right, question is why it selected that object in the first place :/ | 15:41 |
RP | JPEW: I was looking at the OE-Core one | 15:41 |
JPEW | RP: Did you add in the code to check for the existence of sstate objects before accepting a unihash from the server? | 15:42 |
RP | NOTE: Task /home/pokybuild/yocto-worker/qemuarm-oecore/build/meta/recipes-devtools/gdb/gdb-cross_8.3.1.bb:do_populate_sysroot unihash changed to 06d1a23427579c4e46c34048c11b1d78ac57c1da43f67810efd37450f8e9c43f | 15:42 |
RP | That eSDK can't find that | 15:42 |
rburton | JPEW: woot woot | 15:42 |
rburton | JPEW: will finish and post | 15:42 |
RP | JPEW: we have no choice but to accept unihashes from the server :( | 15:43 |
*** ericch <ericch!~ericch@50-205-235-218-static.hfc.comcastbusiness.net> has joined #yocto | 15:43 | |
RP | JPEW: question is how a unihash can exist but not be in sstate :/ | 15:43 |
JPEW | RP: OK. I thought we had done some validation on them, but I think I misremember | 15:43 |
RP | JPEW: you may be thinking of how we report equiv if sstate exists? | 15:44 |
JPEW | RP: Yes, thats probably it. | 15:44 |
armpit | zeddii, thanks | 15:44 |
RP | JPEW: I wonder if there was cleanup of the sstate cache we raced with :/ | 15:45 |
JPEW | RP: Possibly. How often does that happen? | 15:45 |
RP | JPEW: we age out things not accessed for 30 days | 15:45 |
JPEW | RP: So, I suppose the hash equiv database doesn't get cleaned out at the same time? | 15:50 |
JPEW | Because there really isn't anyway to do so (currently) | 15:50 |
RP | JPEW: correct. I'm not 100% sure this what has happened here either, it would seem unlikely active sstate artefacts would be removed :/ | 15:53 |
*** rcrudo <rcrudo!~rcrudo@i5387F440.versanet.de> has quit IRC | 15:54 | |
*** ThomasD13 <ThomasD13!~ThomasD13@DSL01.212.114.255.148.ip-pool.NEFkom.net> has quit IRC | 15:55 | |
*** LocutusOfBorg <LocutusOfBorg!~LocutusOf@ubuntu/member/locutusofborg> has quit IRC | 15:57 | |
*** rcrudo <rcrudo!~rcrudo@i5387F440.versanet.de> has joined #yocto | 15:57 | |
*** goliath <goliath!~goliath@82.150.214.1> has quit IRC | 15:57 | |
fl0v0 | qschulz: reordering the tasks seems to have helped. compiling now. Thank you for the pointer | 15:58 |
qschulz | fl0v0: how did you re-order? | 15:58 |
fl0v0 | addtask merge_delta_config before do_configure after do_patch do_preconfigure | 15:58 |
qschulz | fl0v0: Quite confused by what they're doing here. Please test without sstate-cache as well to check that your modifications aren't benefitting from a side-effect ;) | 16:02 |
fl0v0 | i just turned on optimization for size. if the binary is smaller after compiling, it should be working :) | 16:04 |
*** tlwoerner <tlwoerner!~Trevor@unaffiliated/tlwoerner> has quit IRC | 16:07 | |
*** tlwoerner <tlwoerner!~Trevor@unaffiliated/tlwoerner> has joined #yocto | 16:08 | |
fl0v0 | qschulz: yep it worked :) | 16:08 |
*** TobSnyder <TobSnyder!~schneider@ip5f5aa32f.dynamic.kabel-deutschland.de> has quit IRC | 16:11 | |
qschulz | fl0v0: worth sending a patch to meta-freescale I think. At least to let them know it does not work as expected and that what you did fixed it. They may even come up with a better solution | 16:17 |
*** hpsy <hpsy!~hpsy@217.66.60.5> has quit IRC | 16:18 | |
JPEW | tlwoerner: I sent some patches for meta-rockchip, did you happen to see them? | 16:18 |
fl0v0 | qschulz: i think its an error of variscite, not freescale. But have to check the other freescale recipes to make sure | 16:19 |
tlwoerner | JPEW: that's awesome! thanks! no i haven't seen them yet, i'm deep in "the coding cave" ;-) | 16:20 |
tlwoerner | JPEW: panfrost! w00t! | 16:22 |
tlwoerner | the holidays have come early | 16:22 |
JPEW | tlwoerner: Ya, it works reasonably well, and it's getting better all the time. | 16:22 |
* tlwoerner has a get-together planned with main panfrost developer for january :-) | 16:24 | |
tlwoerner | i'm glad to see it's (obviously) part of mesa now, last time i looked, it was still outside | 16:24 |
tlwoerner | i'm hoping to get away from all that gpt stuff and move to wic sometime too... | 16:26 |
RP | JPEW: I checked and that sstate artefact isn't there. I'm wondering if we could make hashequiv self healing | 16:26 |
JPEW | tlwoerner: Ya. FWIW, you don't *have* to do GPT. Just writting the bits to the right offset is sufficent | 16:26 |
RP | JPEW: i.e. when something is reported back, check sstate, if it exists, great. If not, send a delete request to hashequiv | 16:26 |
JPEW | RP: Yes, thats what I was thinkng | 16:26 |
*** ericch <ericch!~ericch@50-205-235-218-static.hfc.comcastbusiness.net> has quit IRC | 16:27 | |
*** ericch <ericch!~ericch@50-205-235-218-static.hfc.comcastbusiness.net> has joined #yocto | 16:27 | |
JPEW | RP: Deleting might be more complicated... can we make the sstate artifact with the correct name? | 16:27 |
*** ericch <ericch!~ericch@50-205-235-218-static.hfc.comcastbusiness.net> has joined #yocto | 16:27 | |
RP | JPEW: hmm, maybe | 16:27 |
JPEW | e.g. rename, or perhaps even re-run the sstate packaging task | 16:27 |
RP | JPEW: probably not in all cases | 16:28 |
RP | JPEW: for an initial change yes but not for one as things ripple out | 16:28 |
tlwoerner | ... then i need better handling for kernel configs/defconfig | 16:28 |
JPEW | tlwoerner: Ya, that would nice. Thankfully, the panfrost kernel driver is on by default for aarch64 and armv6 defconfigs :) | 16:29 |
JPEW | s/armv6/armv7/ | 16:29 |
JPEW | RP: Delete would be OK, but it might have consequences because you would have to remove all matching unihashes | 16:30 |
RP | JPEW: could you change it to a different hash? | 16:30 |
JPEW | RP: Ya, I just was thinking that. Rename them all to the taskhash of the task that just ran | 16:30 |
tlwoerner | JPEW: armv6? | 16:31 |
JPEW | tlwoerner: armv7 | 16:31 |
*** Sandrita <Sandrita!d0586e2e@gateway/web/cgi-irc/kiwiirc.com/ip.208.88.110.46> has joined #yocto | 16:31 | |
tlwoerner | ah, sorry didn't see the ed line | 16:31 |
tlwoerner | :-) | 16:31 |
RP | JPEW: what if we don't have a task which just ran though? :/ | 16:33 |
*** lquirion <lquirion!~luq@modemcable114.129-37-24.static.videotron.ca> has joined #yocto | 16:34 | |
roussinm | By default TARGET_FPU is empty on AArch64, any reason for it? | 16:36 |
tlwoerner | roussinm: isn't FPU non-optional on AArch64? | 16:39 |
tlwoerner | (so it's probably on by default and can't changed?) | 16:40 |
roussinm | tlwoerner: you mean the compiler knows which FPU to use? | 16:42 |
RP | JPEW: wondering if I can somehow rescue the current build... | 16:42 |
*** goliath <goliath!~goliath@212-186-42-13.cable.dynamic.surfer.at> has joined #yocto | 16:43 | |
RP | JPEW: perhaps I just wipe the hashequiv DB :/ | 16:43 |
*** adelcast <adelcast!~adelcast@130.164.62.197> has quit IRC | 16:43 | |
*** yann|work <yann|work!~yann@85.118.38.73> has quit IRC | 16:45 | |
*** andycooper <andycooper!uid246432@gateway/web/irccloud.com/x-rfhwgjyxnpewodtr> has quit IRC | 16:55 | |
roussinm | I have an image with NO_RECOMMENDATIONS ?= "1", but I would like to have the recommendations when I build the sdk ( bitbake my_image -c populate_sdk ). | 16:57 |
roussinm | Right now we have added the NO_RECOMMENDATIONS to the extrawhitelists and exported in the cmdline, but it feels like a hack. | 16:58 |
*** adelcast <adelcast!~adelcast@130.164.62.221> has joined #yocto | 17:02 | |
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC | 17:05 | |
*** nmoos <nmoos!~moosnat@unaffiliated/moosnat> has joined #yocto | 17:08 | |
JPEW | RP: If we did the check at the time a unihash was reported as changed from the server that should be sufficent | 17:15 |
JPEW | (because that is always in the context of a task) | 17:15 |
JPEW | RP: In fact, I think if report_unihash() did a d.setVar('BB_UNIHASH', new_unihash), it might just work as expected | 17:18 |
JPEW | sstate would make the object with the new unihash name, or do nothing because it already exists | 17:19 |
*** fl0v0 <fl0v0!~fvo@i5E869742.versanet.de> has quit IRC | 17:20 | |
RP | JPEW: I guess we could try a rebuild with that | 17:26 |
rburton | JPEW: fwiw i'm still seeing a number of buildpath warnings | 17:29 |
rburton | i've turned on buildpaths, which is a hint of something that will break reproducbile | 17:29 |
rburton | eg WARNING: libdnf-0.28.1-r0 do_package_qa: QA Issue: File /usr/lib/libdnf.so.2 in package libdnf contains reference to TMPDIR [buildpaths] | 17:29 |
*** rubdos <rubdos!~rubdos@2a02:578:859d:700:8b44:5716:382d:a7da> has joined #yocto | 17:29 | |
RP | JPEW: I'm just going to try it, risky but I don't have a better idea right now | 17:31 |
*** diego_r <diego_r!~diego@217-133-17-98.static.clienti.tiscali.it> has quit IRC | 17:32 | |
*** Bunio_FH <Bunio_FH!~bunio@81-18-201-214.static.chello.pl> has quit IRC | 17:42 | |
roussinm | tlwoerner: just found a message from the mailing list saying that if it's empty, TARGET_FPU, that means default is hard for that architecture. | 17:44 |
tlwoerner | roussinm: nice! (which is what i assumed and was trying to say above) | 17:46 |
JPEW | rburton: Huh. I'll have to turn that on. I wonder why the test passes in that case... | 17:47 |
roussinm | tlwoerner: just annoying that I had to search through the mailling list. Looking at the megamanual documentation, maybe it's something worth adding? | 17:48 |
*** vineela <vineela!vtummala@nat/intel/x-vrgqahzapjmcvuok> has joined #yocto | 17:48 | |
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has joined #yocto | 17:53 | |
*** jklare <jklare!~jklare@157.97.76.18> has quit IRC | 17:58 | |
*** micka <micka!~micka@reverse-75.fdn.fr> has joined #yocto | 17:59 | |
*** jklare <jklare!~jklare@157.97.76.18> has joined #yocto | 18:01 | |
tlwoerner | roussinm: the tuning files, surprisingly, change often enough. keeping the doc in sync with the tuning files would be a lot of work, and risk a lot of confusion if ever they didn't agree. maybe a more general doc update explaining how machine configs point to tune files and how to read a tune file in general would be better? | 18:36 |
roussinm | tlwoerner: it's surprising indeed. In that case, I would agree on a more general approach, yes. | 18:38 |
*** yann|work <yann|work!~yann@91-170-159-152.subs.proxad.net> has joined #yocto | 18:46 | |
*** lfa <lfa!~lfa@217.19.35.51> has quit IRC | 18:56 | |
milloni | hm silly question, is the sdk supposed to be MACHINE-specific? | 19:00 |
milloni | would "/opt/${DISTRO}/${SDK_VERSION}" make a good alternative for SDKPATH? | 19:01 |
milloni | sorry, that's the current value in poky | 19:02 |
milloni | would ""/opt/${DISTRO}/${SDK_VERSION}-${MACHINE}" make a good alternative for SDKPATH? | 19:02 |
milloni | or perhaps even redefining SDK_VERSION as something like: | 19:04 |
milloni | SDK_VERSION = "${@d.getVar('DISTRO_VERSION').replace('snapshot-${DATE}', 'snapshot')}-${MACHINE}" | 19:04 |
*** mischief <mischief!~mischief@wopr.sciops.net> has joined #yocto | 19:10 | |
mischief | is there a way to generate a package dependency graph? | 19:10 |
JPEW | mischief: bitbake -g | 19:14 |
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto | 19:15 | |
mischief | JPEW: i'm aware of the option but i don't care about the tasks. most of the edges in here are useless. i want to see what gets written into the package dependencies, not task dependencies | 19:16 |
milloni | in older versions, bitbake would generate several graphs - one of them was a graph of dependencies between recipes | 19:19 |
milloni | there was also a graph of dependencies between packages | 19:19 |
milloni | i dont know why they're gone now, these two were certainly more useful than the graph of tasks :/ | 19:20 |
JPEW | huh, ya. I guess it doesn't do that anymore. | 19:20 |
milloni | i know i could probably extract a graph of recipes from the graph of tasks but it seems too difficult to figure out how to do that and then automate | 19:20 |
mischief | right.. i wasn't really looking to write a bespoke graph algorithm on monday morning. | 19:21 |
milloni | mischief: find the commit that removed the option to create a graph of recipes and revert it? | 19:22 |
milloni | i'd be interested to know why that option was removed though | 19:22 |
yocti | New news from stackoverflow: BitBake add tmux package to image <https://stackoverflow.com/questions/59255189/bitbake-add-tmux-package-to-image> | 19:23 |
mischief | https://github.com/openembedded/bitbake/commit/4c484cc01e3eee7ab2ab0359fd680b4dbd31dc30 | 19:24 |
milloni | hm okay | 19:24 |
JPEW | mischief: That's not the one you are looking for | 19:25 |
JPEW | mischief: You want the package-depends.dot file | 19:25 |
mischief | no such file is generated. | 19:25 |
JPEW | msichief: Correct, but it used to be generated | 19:26 |
JPEW | mischief: Find the commit that removed package-depends.dot, not the one that removed recipe-depends.dot | 19:27 |
mischief | https://github.com/openembedded/bitbake/commit/d3e182bc18ff2894f1efc8aad3d508dd432c996e | 19:30 |
mischief | doubt a revert would work but i guess i can try to patch it in | 19:31 |
JPEW | mischief: Hmm, it does look like something was lost there when the package-depends.dot was removed. It doesn't look like the newer file outputs the runtime dependencies | 19:38 |
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto | 19:43 | |
mischief | haha, even the file output by this is 1.6MB, making dot slow to a crawl still | 19:44 |
JPEW | mischief: I've never actually bother graphing it, I just read through the text & grep for what I'm looking for | 19:45 |
milloni | same for me, i found that graphical representation is much more difficult to interpret, due to its size | 19:54 |
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has quit IRC | 19:56 | |
*** goliath <goliath!~goliath@212-186-42-13.cable.dynamic.surfer.at> has quit IRC | 20:23 | |
*** andycooper <andycooper!uid246432@gateway/web/irccloud.com/x-duziqgdxhwcqomae> has joined #yocto | 20:25 | |
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has joined #yocto | 20:38 | |
*** JaMa <JaMa!~martin@109.238.218.228> has quit IRC | 20:43 | |
roussinm | Why do I have to be at BUILDDIR to be able to invoke bitbake? | 20:59 |
rburton | in latest bitbake, you don't | 21:06 |
rburton | \o/ | 21:07 |
rburton | good reason to upgrade? | 21:07 |
roussinm | We just upgraded to Zeus. | 21:09 |
roussinm | Is it after? | 21:09 |
rburton | no | 21:09 |
rburton | sumo onwards, in fact | 21:09 |
rburton | that is with the oe-core/poky oe-buildenv-internal script, so if you've a custom distro that doesn't use that script then it needs fixing | 21:10 |
roussinm | Oh man... I just saw... some senior at work hacked something, which prevents it.... | 21:10 |
rburton | oe-core 82eeb934997c9eaa6443079dfb649a89872a222c was the fix there | 21:10 |
roussinm | We do have the script | 21:11 |
roussinm | In a local.conf we do `require ${PWD}/../local.conf` | 21:11 |
roussinm | That can't work unless you have at BUILDDIR | 21:11 |
roussinm | are* | 21:12 |
rburton | thats horrible ;) | 21:13 |
rburton | use BBPATH? | 21:13 |
rburton | should be $(BUILDDIR) and is exported | 21:13 |
roussinm | why a subshell? | 21:13 |
rburton | habit, ignore that | 21:13 |
rburton | BBPATH=$BUILDDIR | 21:14 |
rburton | export BBPATH | 21:14 |
rburton | says the script | 21:14 |
*** berton_ <berton_!~berton@189.103.49.163> has quit IRC | 21:14 | |
roussinm | Hmm it fails because it tried to concatenate all the paths from the BBLAYERS paths. When using ${BBPATH} | 21:27 |
roussinm | Oh I see, all the layers appends to the BBPATH variable. | 21:29 |
*** yann|work <yann|work!~yann@91-170-159-152.subs.proxad.net> has quit IRC | 21:30 | |
armpit | zeddii, I got a kernel oops on Arm for 4.18.45 on thud on the AB.. I need to triage it local and will open a bug if need be | 21:35 |
*** tgamblin <tgamblin!~tgamblin@128.224.252.2> has quit IRC | 21:36 | |
*** LocutusOfBorg <LocutusOfBorg!~LocutusOf@ubuntu/member/locutusofborg> has joined #yocto | 21:43 | |
*** yann <yann!~yann@91-170-159-152.subs.proxad.net> has joined #yocto | 21:44 | |
*** pohly <pohly!~pohly@p54BD5C64.dip0.t-ipconnect.de> has quit IRC | 21:46 | |
roussinm | rburton: so in theory if we do `require ../company-local.conf` | 21:51 |
roussinm | It should be "cleanish" ? | 21:51 |
rburton | company-local.conf sounds a lot like it should be site.conf in your own layer | 21:51 |
rburton | any file called conf/site.conf in a layer is included automatically | 21:52 |
rburton | site-wide settings that are not distro-specific | 21:52 |
rburton | everything else should be in your distro | 21:52 |
rburton | then your local.conf can be templated using your layer | 21:52 |
roussinm | So you are saying that, for example, DL_DIR should be inside a layer? | 21:52 |
rburton | if its a company-wide setting then sure. sstate_mirrors is a good example if you have a central server. | 21:53 |
roussinm | We use that company-local.conf for compagny wide settings. | 21:53 |
rburton | i'd look at moving that to site.conf then | 21:54 |
roussinm | but that configuration file has to be the same for all machines. | 21:54 |
rburton | right, has to be generic settings | 21:55 |
roussinm | Oh, but we have different directories for each machines `/builds/yocto/machine1..5`. When we source the environment we source for a specific machine. If we use site.conf it would be duplicate inside each machine? | 22:00 |
roussinm | Maybe we shouldn't have a seperate directories for each machine? | 22:01 |
*** dv_ <dv_!~dv@62-178-50-190.cable.dynamic.surfer.at> has quit IRC | 22:04 | |
*** LocutusOfBorg <LocutusOfBorg!~LocutusOf@ubuntu/member/locutusofborg> has quit IRC | 22:12 | |
*** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has joined #yocto | 22:12 | |
*** dv_ <dv_!~dv@62-178-50-190.cable.dynamic.surfer.at> has joined #yocto | 22:22 | |
*** tgamblin <tgamblin!~tgamblin@CPE64777de11593-CM64777de11590.cpe.net.cable.rogers.com> has joined #yocto | 22:36 | |
*** agust <agust!~agust@p5483338F.dip0.t-ipconnect.de> has quit IRC | 23:04 | |
tlwoerner | JPEW: still around? | 23:24 |
*** sstabellini <sstabellini!sstabellin@gateway/shell/xshellz/x-vrxobbleezmitueb> has quit IRC | 23:25 | |
RP | JPEW: Still erroring: https://autobuilder.yoctoproject.org/typhoon/#/builders/42/builds/1330 :( | 23:36 |
RP | JPEW: I guess I'll need to check the patch actually did what we hoped/wanted it to :/ | 23:38 |
yocti | New news from stackoverflow: Add OP-TEE to Yocto <https://stackoverflow.com/questions/59258192/add-op-tee-to-yocto> | 23:54 |
Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!