| * armpit great warrior -next has patches that are not in master | 00:13 | |
| *** la_croix <la_croix!~la_croix@cpc97624-walt24-2-0-cust98.13-2.cable.virginm.net> has quit IRC | 00:51 | |
| *** la_croix <la_croix!~la_croix@cpc97624-walt24-2-0-cust98.13-2.cable.virginm.net> has joined #yocto | 00:55 | |
| *** la_croix <la_croix!~la_croix@cpc97624-walt24-2-0-cust98.13-2.cable.virginm.net> has quit IRC | 01:01 | |
| *** la_croix <la_croix!~la_croix@cpc97624-walt24-2-0-cust98.13-2.cable.virginm.net> has joined #yocto | 01:04 | |
| *** la_croix <la_croix!~la_croix@cpc97624-walt24-2-0-cust98.13-2.cable.virginm.net> has quit IRC | 01:30 | |
| *** la_croix <la_croix!~la_croix@cpc97624-walt24-2-0-cust98.13-2.cable.virginm.net> has joined #yocto | 01:31 | |
| *** demonimin_ <demonimin_!~demonimin@unaffiliated/demonimin> has joined #yocto | 01:40 | |
| *** demonimin <demonimin!~demonimin@unaffiliated/demonimin> has quit IRC | 01:40 | |
| *** demonimin_ <demonimin_!~demonimin@unaffiliated/demonimin> has quit IRC | 01:48 | |
| *** demonimin <demonimin!~demonimin@unaffiliated/demonimin> has joined #yocto | 02:05 | |
| *** learningc <learningc!~learningc@mti-37-145.tm.net.my> has joined #yocto | 02:15 | |
| *** learningc <learningc!~learningc@mti-37-145.tm.net.my> has quit IRC | 02:38 | |
| *** learningc <learningc!~learningc@mti-37-145.tm.net.my> has joined #yocto | 02:39 | |
| *** learningc <learningc!~learningc@mti-37-145.tm.net.my> has joined #yocto | 02:41 | |
| *** fatalhalt <fatalhalt!~fatalhalt@c-67-163-60-93.hsd1.il.comcast.net> has quit IRC | 02:59 | |
| OutBackDingo | ermmm whys my thud image installing both python2 and python3 ??? | 03:08 |
|---|---|---|
| *** sjolley_ <sjolley_!~sjolley_@c-71-59-136-149.hsd1.or.comcast.net> has quit IRC | 03:14 | |
| *** comptroller <comptroller!~comptroll@47-213-222-253.paolcmtc01.res.dyn.suddenlink.net> has quit IRC | 03:36 | |
| *** justanotherboy <justanotherboy!~justanoth@136.49.196.186> has quit IRC | 04:09 | |
| *** lexano <lexano!~lexano@CPEa021b7ac59c9-CMf0f249028110.cpe.net.cable.rogers.com> has quit IRC | 04:21 | |
| *** lexano <lexano!~lexano@CPEa021b7ac59c9-CMf0f249028110.cpe.net.cable.rogers.com> has joined #yocto | 04:25 | |
| *** armpit <armpit!~armpit@116.212.180.67> has quit IRC | 04:25 | |
| *** armpit <armpit!~armpit@182.72.92.62> has joined #yocto | 05:32 | |
| *** AndersD <AndersD!~AndersD@145.253.186.116> has joined #yocto | 05:59 | |
| lukma | The image.bbclas defines do_fetch[noexec] = '1' | 06:01 |
| lukma | Is there a way to re-enable fetch in my recipe (so SRC_URI = "file://foo") copies foo to ${WORKDIR} ? | 06:02 |
| lukma | Or do I need to re-invent fetch for my recipe? | 06:02 |
| lukma | (I.e. reuse base_do_fetch() in python my_fetch () { base_do_fetch() } ) ? | 06:04 |
| *** agust <agust!~agust@p508B6C31.dip0.t-ipconnect.de> has joined #yocto | 06:12 | |
| lukma | or better base_do_unpack() ? | 06:13 |
| *** sk_tandt <sk_tandt!~sk_tandt@net-5-88-141-17.cust.vodafonedsl.it> has joined #yocto | 06:22 | |
| *** frsc <frsc!~frsc@2003:a:e7a:6200:246c:2a8b:f45a:a33d> has joined #yocto | 06:22 | |
| *** jmiehe <jmiehe!~Thunderbi@p578c106e.dip0.t-ipconnect.de> has joined #yocto | 06:43 | |
| *** cvasilak <cvasilak!~cvasilak@2a02:587:8117:600:2482:3aec:ef75:9af7> has joined #yocto | 06:48 | |
| *** Bunio_FH <Bunio_FH!~bunio@81-18-201-214.static.chello.pl> has joined #yocto | 06:54 | |
| *** mckoan|away is now known as mckoan | 06:56 | |
| mckoan | good morning | 06:56 |
| *** varjag <varjag!~user@122.62-97-226.bkkb.no> has joined #yocto | 06:57 | |
| *** fl0v0 <fl0v0!~fvo@89.244.126.68> has joined #yocto | 06:58 | |
| *** jeanba <jeanba!~jbl@77.243.63.34> has joined #yocto | 07:03 | |
| *** jeanba <jeanba!~jbl@77.243.63.34> has left #yocto | 07:03 | |
| LetoThe2nd | mckoan: depends on your definition | 07:10 |
| *** tprrt <tprrt!~tprrt@217.114.201.133> has joined #yocto | 07:11 | |
| *** lusus <lusus!~lusus@62.91.23.180> has joined #yocto | 07:12 | |
| *** sk_tandt <sk_tandt!~sk_tandt@net-5-88-141-17.cust.vodafonedsl.it> has quit IRC | 07:15 | |
| *** MarcWe <MarcWe!hmwmatrixo@gateway/shell/matrix.org/x-bosiwezfjuljdhgo> has joined #yocto | 07:17 | |
| yann | RP: I already use a "files" directory, and was hoping to use a single layer for multiple poky releases (here we have patches to connman, which have to be changed to apply to new versions) | 07:20 |
| yann | I'm also looking for an idiom where I get an early failure if I forget to adjust one change for a new poky release. The %.bbappend catch-all combined with a necessary per-version patch dir just sounded like a perfect fit | 07:21 |
| *** yacar_ <yacar_!~yacar@80.215.66.56> has joined #yocto | 07:28 | |
| *** acrap <acrap!~Thunderbi@host-85-237-33-147.dsl.sura.ru> has joined #yocto | 07:28 | |
| acrap | Hi, folks! | 07:29 |
| mckoan | LetoThe2nd: c'mon be positive :-D | 07:29 |
| *** Striking7 <Striking7!~jon@96-94-100-129-static.hfc.comcastbusiness.net> has quit IRC | 07:30 | |
| acrap | I am searching for a standard way to solve my problem. I have one tricky recipe from BSP layer that uses multiple repositories. So, I can patch only main one with Yocto's standard way. | 07:30 |
| acrap | I think it would be great to create separate recipes for those subprojects | 07:31 |
| acrap | but the problem is - I need an access to their sources from the main one | 07:31 |
| *** yann <yann!~yann@lfbn-1-3372-5.w90-127.abo.wanadoo.fr> has quit IRC | 07:32 | |
| acrap | So, those recipes I want to copy should only do the following job: fetch, patch, populate their sources somewhere | 07:33 |
| *** Striking7 <Striking7!~jon@96-94-100-129-static.hfc.comcastbusiness.net> has joined #yocto | 07:34 | |
| acrap | Sure I can do it manually, but I am just wondering if there is a standard way (or just less dull) | 07:34 |
| *** TobSnyder <TobSnyder!~schneider@ip5f5aa32f.dynamic.kabel-deutschland.de> has joined #yocto | 07:35 | |
| acrap | seems like I've already found the solution | 07:39 |
| acrap | patchdir - Specifies the directory in which the patch should be applied. The default is ${S}. | 07:39 |
| acrap | It's a lot easier than I thought | 07:39 |
| armpit | LetoThe2nd, needs some heavy metal | 07:41 |
| armpit | mckoan, just scream it at LetoThe2nd | 07:43 |
| *** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto | 07:55 | |
| LetoThe2nd | armpit: ++ | 07:57 |
| LetoThe2nd | mckoan: actually, i sent some potential customer your way last week | 07:57 |
| *** yacar_ <yacar_!~yacar@80.215.66.56> has quit IRC | 07:58 | |
| *** jku <jku!~jku@dyx9b8yyyyyyyyyyyyyby-3.rev.dnainternet.fi> has joined #yocto | 08:00 | |
| *** yann <yann!~yann@85.118.38.73> has joined #yocto | 08:13 | |
| *** RP <RP!~RP@5751f4a1.skybroadband.com> has joined #yocto | 08:15 | |
| yann | hi RP - did not notice you were away | 08:18 |
| *** kaspter <kaspter!~Instantbi@125.118.63.231> has quit IRC | 08:18 | |
| yann | RP: I already use a "files" directory, and was hoping to use a single layer for multiple poky releases (here we have patches to connman, which have to be changed to apply to new versions) | 08:18 |
| yann | I'm also looking for an idiom where I get an early failure if I forget to adjust one change for a new poky release. The %.bbappend catch-all combined with a necessary per-version patch dir just sounded like a perfect fit | 08:19 |
| *** kaspter <kaspter!~Instantbi@125.118.63.231> has joined #yocto | 08:19 | |
| RP | yann: You have a piece which needs immediate expansion (THISDIR) and a piece which does not (PV) | 08:20 |
| RP | yann: try something like MYAPPENDDIR := "${THISDIR}" then FILESEXTRAPATH_append = "${MYAPPENDDIR}/${PV}" | 08:21 |
| RP | the spacing and so on needs tweaking there | 08:21 |
| yann | hm, not far from one of my attempts, but I had missed the immediate-expansion part | 08:22 |
| *** voyo <voyo!~wsawasci@89-74-72-36.dynamic.chello.pl> has quit IRC | 08:22 | |
| *** lfa <lfa!~lfa@217.19.35.51> has joined #yocto | 08:24 | |
| *** yacar_ <yacar_!~yacar@80.215.66.56> has joined #yocto | 08:24 | |
| yann | RP: that does the job well enough, thanks much! | 08:27 |
| armpit | RP, i have some sumo-nmut failures that I wont be able to look at until I get home on thursday | 08:28 |
| armpit | thud-nmut looks good and is out for review. I send a pull request tomorrow? | 08:29 |
| * armpit what day is today?? | 08:30 | |
| RP | armpit: Monday | 08:31 |
| RP | armpit: I saw the thud email, patches looked good thanks | 08:32 |
| *** cvasilak <cvasilak!~cvasilak@2a02:587:8117:600:2482:3aec:ef75:9af7> has quit IRC | 08:33 | |
| *** cvasilak <cvasilak!~cvasilak@2a02:587:8117:600:2482:3aec:ef75:9af7> has joined #yocto | 08:34 | |
| * armpit going to be 34C here today.. | 08:34 | |
| *** jku <jku!~jku@dyx9b8yyyyyyyyyyyyyby-3.rev.dnainternet.fi> has quit IRC | 08:38 | |
| RP | armpit: couldn't stand that :) | 08:38 |
| armpit | i can last an hour of that then I melt | 08:40 |
| lukma | Maybe somebody had similar issue | 08:40 |
| lukma | to use / copy SRC_URI's file:// to WORKDIR when one uses inherit image.bbclass ? | 08:41 |
| RP | lukma: As I mentioned, it should be enough to delete the noexec flag using delVarFlag | 08:41 |
| lukma | The python () { d.delVarFlag("do_fetch", "noexec") } is not enough | 08:41 |
| RP | lukma: something odd is going on if that isn't enoug | 08:41 |
| lukma | I need to create separate task and put there: | 08:42 |
| lukma | src_uri = (d.getVar('SRC_URI') or "").split() | 08:42 |
| lukma | fetcher = bb.fetch2.Fetch(src_uri, d) | 08:42 |
| lukma | fetcher.unpack(d.getVar('WORKDIR')) | 08:42 |
| RP | lukma: $ bitbake core-image-sato -e | grep python.do_fetch -C 5 | 08:43 |
| RP | shows python do_fetch () { bb.build.exec_func('base_do_fetch', d) } | 08:43 |
| RP | which implies the function still exists | 08:44 |
| lukma | recipes-core/images/foorec.bb', lineno: 16, function: do_get_foo | 08:44 |
| lukma | 0012:# image.bbclass disabled calls do_fetch[noexec] = 1, | 08:44 |
| lukma | 0013:# which disables fetcher - so no files are provided via | 08:44 |
| lukma | 0014:# SRC_URI | 08:44 |
| lukma | 0015:python do_get_foo () { | 08:44 |
| lukma | *** 0016: base_do_fetch() | 08:44 |
| lukma | 0017: base_do_unpack() | 08:44 |
| lukma | 0018:} | 08:44 |
| lukma | 0019: | 08:44 |
| lukma | 0020:addtask do_get_foo before do_image_foo | 08:44 |
| lukma | Exception: NameError: name 'base_do_fetch' is not defined | 08:44 |
| *** T_UNIX <T_UNIX!uid218288@gateway/web/irccloud.com/x-fcmresbzfipbpbfl> has joined #yocto | 08:45 | |
| lukma | With the -e flag | 08:45 |
| lukma | python do_fetch () { | 08:45 |
| lukma | bb.build.exec_func('base_do_fetch', d) | 08:45 |
| lukma | } | 08:45 |
| lukma | It is also there ... | 08:46 |
| RP | you can't call it like that. Please use pastebin for things which are multiple lines | 08:47 |
| lukma | RP: https://pastebin.com/VasgFWRZ | 08:50 |
| lukma | Now it shall be more concise | 08:51 |
| RP | lukma: bb.build.exec_func('base_do_fetch', d) is not the same as base_do_fetch() | 08:52 |
| *** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto | 08:52 | |
| RP | lukma: and I still don't see why you would need to add a new task | 08:52 |
| lukma | RP: I've double checked - I only do have python do_fetch () { bb.build.exec_func('base_do_fetch', d) } | 08:56 |
| *** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC | 08:57 | |
| RP | lukma: can you share the code you're trying which sets SRC_URI and deletes the noexec fetch/unpack var flag? | 08:57 |
| RP | lukma: and clearly say what happens or doesn't happen. Its very hard for me to guess what you're doing or what the problem is | 08:58 |
| *** falk0n_ <falk0n_!~falk0n@a81-84-60-132.cpe.netcabo.pt> has quit IRC | 09:01 | |
| lukma | RP:https://pastebin.com/0G6Rjnuh | 09:02 |
| *** falk0n <falk0n!~falk0n@a81-84-60-132.cpe.netcabo.pt> has joined #yocto | 09:03 | |
| RP | lukma: well, that won't even parse. You want the "." between d and delVarFlag | 09:04 |
| RP | lukma: you also want a second line under it which is the same but change fetch for unpack | 09:04 |
| *** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto | 09:05 | |
| lukma | RP: With the dot - correct it is in the recipe | 09:05 |
| RP | lukma: what about the second line? | 09:09 |
| RP | lukma: you need both, ie. python () { d.delVarFlag("do_fetch", "noexec") d.delVarFlag("do_unpack", "noexec") } | 09:10 |
| *** la_croix <la_croix!~la_croix@cpc97624-walt24-2-0-cust98.13-2.cable.virginm.net> has quit IRC | 09:11 | |
| *** la_croix <la_croix!~la_croix@cpc97624-walt24-2-0-cust98.13-2.cable.virginm.net> has joined #yocto | 09:14 | |
| lukma | RP: https://pastebin.com/B9tcyNBB | 09:14 |
| lukma | RP: It seems like the do_fetch / do_unpack functions are missing | 09:15 |
| *** alcroito <alcroito!~alcroito@placinta.eu> has joined #yocto | 09:15 | |
| lukma | or not inherited properly | 09:15 |
| *** alcroito <alcroito!~alcroito@placinta.eu> has left #yocto | 09:15 | |
| RP | lukma: they're clearly not missing as the -e output shows them. The question is why they're not executing | 09:16 |
| RP | lukma: try "-e | grep do_fetch", it will have more output but perhaps more clues. I'm interested in the tasks output | 09:16 |
| lukma | RP: https://stackoverflow.com/questions/51952495/yocto-image-recipe-and-src-uri | 09:16 |
| lukma | The question is about core-image, but image.bbclass superseeds it | 09:17 |
| RP | lukma: right, same issue, the noexec | 09:17 |
| lukma | RP: So with -e the python base_do_fetch () { is visible and correct | 09:24 |
| sveinse | What is the difference from running a qemu image with runqemu vs running a wic.wmdk image with qemu manually? The former works fine, but the latter hangs midway in the kernel boot process | 09:25 |
| sveinse | My ultimate goal is to be able to run the yocto image from a VM (in Azure cloud) | 09:26 |
| RP | sveinse: compare the commandlines? | 09:31 |
| RP | lukma: that wasn't what I asked. I'm interested in the long line started # "{'tasks': | 09:32 |
| RP | lukma: I suspect you have some other layer/class involved which is doing something like a deltask do_fetch | 09:32 |
| RP | lukma: but I simply can't tell | 09:32 |
| lukma | RP: https://pastebin.com/iLGwShxv | 09:33 |
| sveinse | RP: Yep. Not completely comparable thou. One is using the .ext4 image and "injecting" kernel and parameters from the qemu command line, while the other is self-contained with a syslinux boot | 09:34 |
| sveinse | I plan on getting it from 'runqemu' to standalone qemu to VirtualBox to HyperV to Cloud. | 09:38 |
| *** marble_visions <marble_visions!~user@68.183.79.8> has quit IRC | 09:38 | |
| JaMa | sveinse: my guess is the rnd initialization | 09:39 |
| *** yacar_ <yacar_!~yacar@80.215.66.56> has quit IRC | 09:40 | |
| JaMa | sveinse: at least it was for me when using old script for running qemu builds and vbox | 09:40 |
| *** marble_visions <marble_visions!~user@68.183.79.8> has joined #yocto | 09:40 | |
| RP | lukma: right, so it is running do_fetch but not finding the file? | 09:41 |
| JaMa | sveinse: and with VirtualBox 6 there is also issue with serial port, syslinux gets stuck, you either need to disable syslinux menu or redirect serial from vbox e.g. to pipe and confirm the menu selection there | 09:42 |
| RP | lukma: is the file <dir>/recipes-core/images/image-foo/foo.its ? | 09:42 |
| sveinse | JaMa: syslinux seems to pass fine, yet it complains both in qemu (using wmdk) and vb about undefined video mode and halts there for 30 secs, but it doesn't get stuck. | 09:43 |
| JaMa | using uvesafb? | 09:44 |
| lukma | RP: Yes, the file is there | 09:44 |
| sveinse | JaMa: Don't know. Just using out of box config from rocko, so I probably need to configure it | 09:45 |
| RP | lukma: ok, so what does the unpack log say? | 09:46 |
| RP | lukma: I wonder if do_roots[cleandirs] is cleaning up the file before you can see it | 09:47 |
| sveinse | JaMa: further, one of the last messages I see in the console is "random: crng init done", but I get often 2-3 other lines after that. On vb its "hid-generic: input: USB HID v1.10 Mouse" on qemu its "e1000: enp0s3: renamed from eth0", so I'm guessing I'm not seeing the real lockup cause in either of them | 09:47 |
| RP | lukma: try bitbake image-foo -c unpack -f | 09:47 |
| lukma | RP: Hmm.... | 09:50 |
| lukma | It is placed in WORKDIR now ..... | 09:50 |
| lukma | RP: Let me double check it with sstate cache removed | 09:50 |
| RP | lukma: I suspect the rootfs code is cleaning it up before it starts | 09:51 |
| lukma | RP: I suppose that the task do_rootfs () is necessary to use IMAGE_CMD ... | 09:52 |
| RP | lukma: addtask do_stashfile before do_rootfs after do_unpack ? | 09:54 |
| RP | lukma: put the file somewhere safe? | 09:54 |
| sveinse | Where and how I control the boot parameters and kernel options in a wic.wmdk image? | 09:55 |
| sveinse | (or any other image that embeds the bootloader and kernel options) | 09:56 |
| lukma | RP: It shall be safe in WORKDIR? (as I just use it with IMAGE_CMD_foo mkimage | 09:56 |
| *** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC | 09:56 | |
| RP | lukma: probably | 09:56 |
| lukma | RP: Ok, it seems like the problem was with no re-enabling both d.delVarFlag("do_fetch", "noexec") d.delVarFlag("do_unpack", "noexec" | 09:58 |
| lukma | RP: As fetch just "downloads" the stuff and "unpack" places it in ${S} or ${WORKDIR} | 09:59 |
| RP | correct | 10:01 |
| lukma | RP: Thanks for explanation and help :) | 10:01 |
| lukma | RP: BIG thanks - sounds better :) | 10:01 |
| *** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto | 10:02 | |
| *** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto | 10:08 | |
| yocti | New news from stackoverflow: Yocto Image Recipe and SRC_URI <https://stackoverflow.com/questions/51952495/yocto-image-recipe-and-src-uri> | 10:09 |
| *** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC | 10:11 | |
| kanavin | RP: yes, thanks for pushing the hang issue further | 10:12 |
| *** AndersD <AndersD!~AndersD@145.253.186.116> has quit IRC | 10:13 | |
| RP | kanavin: No problem. I tried to patch out the hanging test but it still showed timeouts on the autobuilder last night so I think there may be further tests that hang | 10:14 |
| RP | kanavin: my local builds are a mess so rebuilding atm | 10:15 |
| RP | kanavin: Your work triggered me to run the bisect whilst watching TV :) | 10:15 |
| kanavin | RP: right, I did not check if the rest of the tests are okay | 10:15 |
| kanavin | bisecting poky is time-consuming | 10:16 |
| *** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto | 10:16 | |
| RP | kanavin: I naively thought I could just disable that one. Regardless the ptest results from the last build are way healthier, the util-linux fixes help too for example (assuming we can fix the other build issue) | 10:16 |
| kanavin | RP: I also wonder if 5 minutes timeout set by ptest-runner is genuinely too small, even with perfect buffering | 10:17 |
| kanavin | some of python3 tests take 2 and half minutes to complete, too close to comfort imo | 10:18 |
| RP | kanavin: I think it should be fine, most tests have some output if they sit for that long | 10:18 |
| RP | kanavin: hmm :/ | 10:18 |
| kanavin | since ross's output reduction patch | 10:18 |
| *** rburton <rburton!~rburton@35.106.2.81.in-addr.arpa> has joined #yocto | 10:18 | |
| sveinse | It seems to be linked how the HDD is enabled in qemu "-drive if=none,id=hd,file=myimage.wic.vmdk,format=raw -device virtio-scsi-pci,id=scsi -device scsi-hd,drive=hd" works, while simply using "-drive file=myimage.wic,format=raw" fails to boot. That is, it seems to boot the kernel properly but fails to jump to userspace boot AFAICS | 10:19 |
| kanavin | RP: the timeout is easy to adjust via command line from ptest.py though, if needed | 10:19 |
| sveinse | (copy paste type in the former, no ".vmdk" in it) | 10:20 |
| RP | kanavin: what worries me is some kind of breakage which then has each ptest hang for 15 mins :/ | 10:20 |
| RP | kanavin: a 5 minute timeout is bad enough to lock builds up | 10:20 |
| *** comptroller <comptroller!~comptroll@47-213-222-253.paolcmtc01.res.dyn.suddenlink.net> has joined #yocto | 10:20 | |
| kanavin | RP: right, a per-test ability to override the timeout would be good to have. Most tests can have it set to something really minimal like 30 seconds | 10:21 |
| RP | kanavin: agreed, that would be better | 10:21 |
| *** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC | 10:28 | |
| *** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto | 10:33 | |
| *** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has quit IRC | 10:42 | |
| *** yacar_ <yacar_!~yacar@80.215.66.56> has joined #yocto | 10:55 | |
| *** comptroller <comptroller!~comptroll@47-213-222-253.paolcmtc01.res.dyn.suddenlink.net> has quit IRC | 10:58 | |
| *** demonimin <demonimin!~demonimin@unaffiliated/demonimin> has quit IRC | 11:00 | |
| *** comptroller <comptroller!~comptroll@47-213-222-253.paolcmtc01.res.dyn.suddenlink.net> has joined #yocto | 11:16 | |
| RP | kanavin: I think you may be right, I think it is timing out on the AB as you say | 11:16 |
| RP | kanavin: its also not getting pass/fail processing correctly | 11:16 |
| *** thaytan <thaytan!~thaytan@121-200-23-18.79c817.syd.nbn.aussiebb.net> has quit IRC | 11:20 | |
| RP | rburton: any idea why run-ptest for python3 wouldn't parse any of the results? :/ | 11:29 |
| * RP is wondering about escaping | 11:29 | |
| RP | ah, busybox sed verses non-busybox? | 11:30 |
| RP | kanavin: any idea how difficult a per recipe timeout would be? :/ | 11:31 |
| *** armpit <armpit!~armpit@182.72.92.62> has quit IRC | 11:37 | |
| yocti | New news from stackoverflow: How to run a shell script while compiling a recipe in Yocto <https://stackoverflow.com/questions/55572567/how-to-run-a-shell-script-while-compiling-a-recipe-in-yocto> | 11:39 |
| RP | zeddii: I'm trying to figure out the pieces we have left for this release before we can build rc1. qemumips shutdown is one, would we want to sort the tiny kernel and drop 4.18 too? | 11:40 |
| zeddii | right. I have the config change to merge for mips (I’ll do that this morning here). We could do the -tiny bump, I can do some builds and qemu boot tests, but I’m not aware of what sort of other testing is commonly done with tiny (I’m betting not all that much). | 11:44 |
| zeddii | I can do those -tiny build tests today as well, if we want to at least give it a go. | 11:44 |
| RP | zeddii: we build and boot it iirc | 11:44 |
| zeddii | I can do that much. | 11:44 |
| RP | zeddii: not much other than that and I would kind of prefer to get to two kernels to test/release rather than three | 11:44 |
| * zeddii denied another trip this week, so I’m around. | 11:44 | |
| zeddii | agreed. | 11:45 |
| zeddii | leave it with me today, and I’ll get you a patch for your morning tomorrow (or at least an email describing what broke). | 11:45 |
| RP | zeddii: I'm also trying to get ptest beaten into some sort of shape for release | 11:45 |
| RP | zeddii: thanks | 11:45 |
| zeddii | no replies on -netdev to your query that I saw. | 11:45 |
| * RP is going to mistype unbuffered in a commit message soon... | 11:46 | |
| RP | zeddii: no :( | 11:46 |
| RP | zeddii: did I ask the right things and have the right info? I don't now the networking people really... | 11:46 |
| RP | know | 11:46 |
| *** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC | 11:48 | |
| *** thaytan <thaytan!~thaytan@121-200-23-18.79c817.syd.nbn.aussiebb.net> has joined #yocto | 11:51 | |
| zeddii | the question looked fine to me. I don’t know many of the core devs either in that space. I’ll see if I can wrangle up a known name to jiggle them to looking at it. | 11:51 |
| RP | zeddii: thanks :) | 11:52 |
| *** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto | 11:55 | |
| *** klemen <klemen!~textual@193.189.172.170> has joined #yocto | 12:04 | |
| RP | rburton: I think http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=9dec37ceef6c1db79e33484cf983629c6601f802 is bust for python3 | 12:07 |
| *** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC | 12:11 | |
| RP | specifically the sed filtering or the lack of -v addition of -W for py3 | 12:12 |
| *** berton <berton!~berton@177.194.204.148> has quit IRC | 12:17 | |
| *** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto | 12:17 | |
| *** berton <berton!~berton@177.194.204.148> has joined #yocto | 12:18 | |
| *** berton <berton!~berton@177.194.204.148> has quit IRC | 12:21 | |
| *** berton <berton!~berton@177.194.204.148> has joined #yocto | 12:26 | |
| *** berton <berton!~berton@177.194.204.148> has quit IRC | 12:29 | |
| *** cvasilak <cvasilak!~cvasilak@2a02:587:8117:600:2482:3aec:ef75:9af7> has quit IRC | 12:33 | |
| *** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC | 12:38 | |
| *** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto | 12:44 | |
| *** vladzouth <vladzouth!500c5411@gateway/web/freenode/ip.80.12.84.17> has quit IRC | 12:44 | |
| rburton | RP: what happens? | 12:46 |
| rburton | hm | 12:46 |
| rburton | i wonder if the -W means it splits to stderr/stdout and the sed messed up the order | 12:47 |
| rburton | maybe we should 2>&1 before the sed? | 12:47 |
| rburton | *or* try again to write a results subclass that writes messages we're after | 12:47 |
| rburton | was wondering if we should unify on something more common like TAP output | 12:47 |
| *** LocutusOfBorg <LocutusOfBorg!LocutusOfB@ubuntu/member/locutusofborg> has quit IRC | 13:00 | |
| yann | I'm getting troubled understanding some interactions (in morty): I have a base autotools-based recipe (pulseaudio) makeing use of do_install_append(). In a .bbappend I can add more using do_install_append() myself, but if additionally I add, say, do_install_arm64_append(), the autotools_do_install call does not make it into the final script, only those 3 _append snippets make it there | 13:00 |
| *** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC | 13:01 | |
| yann | my understanding problem is probably linked to not seeing where the autotools_do_install call itself comes from | 13:01 |
| rburton | yann: do_install_append_arm64 | 13:02 |
| rburton | order matters | 13:02 |
| rburton | kanavin: did you touch openssl ptest? | 13:02 |
| rburton | WARNING: core-image-minimal-1.0-r0 do_image_qa: /usr/lib/openssl/ptest/util/opensslwrap.sh is a broken link | 13:02 |
| yann | rburton: d'oh, thx - looks like I can't again wrap my head around this order | 13:06 |
| rburton | append and remove go before other overrides | 13:07 |
| *** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto | 13:07 | |
| yann | I keep imagining func_append_foo overloads func_append, like VAR_foo overloads VAR | 13:10 |
| yann | shadows, rather | 13:10 |
| *** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC | 13:12 | |
| kanavin | rburton, I didnt | 13:12 |
| kanavin | not lately at least | 13:12 |
| kanavin | RP, Im thinking about it, first thing is where would we actually specify a custom timeout that ptest-runner can read | 13:13 |
| kanavin | probably a ptest-timeout file next to ptest-run, with a single number in it | 13:13 |
| kanavin | then it shouldnt be very hard to read that from C and re-assign the timeout variable, jsut before running the test | 13:14 |
| *** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto | 13:16 | |
| *** la_croix <la_croix!~la_croix@cpc97624-walt24-2-0-cust98.13-2.cable.virginm.net> has quit IRC | 13:17 | |
| *** la_croix <la_croix!~la_croix@cpc97624-walt24-2-0-cust98.13-2.cable.virginm.net> has joined #yocto | 13:18 | |
| *** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC | 13:30 | |
| *** jij <jij!jonashg@nat/axis/x-rkcqywhmqqmnddqp> has quit IRC | 13:35 | |
| *** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto | 13:37 | |
| *** jeanba <jeanba!~jbl@77.243.63.34> has joined #yocto | 13:49 | |
| *** jij <jij!jonashg@nat/axis/x-kxmdwqowkmrfhsbc> has joined #yocto | 13:51 | |
| *** jeanba <jeanba!~jbl@77.243.63.34> has left #yocto | 13:54 | |
| *** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC | 13:56 | |
| *** stephano <stephano!~stephano@134.134.139.76> has joined #yocto | 13:59 | |
| *** kanavin_ <kanavin_!~kanavin@141.113.67.170> has joined #yocto | 14:01 | |
| *** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto | 14:01 | |
| *** kanavin_ <kanavin_!~kanavin@141.113.67.170> has quit IRC | 14:01 | |
| *** prabhakarlad <prabhakarlad!~prabhakar@194.75.40.178> has joined #yocto | 14:02 | |
| *** Striking7 <Striking7!~jon@96-94-100-129-static.hfc.comcastbusiness.net> has quit IRC | 14:04 | |
| *** Striking7 <Striking7!~jon@96-94-100-129-static.hfc.comcastbusiness.net> has joined #yocto | 14:05 | |
| *** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC | 14:06 | |
| *** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto | 14:10 | |
| *** Bunio_FH <Bunio_FH!~bunio@81-18-201-214.static.chello.pl> has quit IRC | 14:15 | |
| *** voyo <voyo!~wsawasci@89-74-72-36.dynamic.chello.pl> has joined #yocto | 14:21 | |
| *** demonimin <demonimin!~demonimin@unaffiliated/demonimin> has joined #yocto | 14:21 | |
| rburton | RP: if you haven't yet merged the py ptest thing, just ading @unittest.skip("broken on newer kernels") would be a neater and more pythonic patch | 14:21 |
| *** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC | 14:24 | |
| OutBackDingo | rburton: is there a hardware list for new gear ? | 14:27 |
| rburton | literally no idea what you mean | 14:28 |
| OutBackDingo | rburton: meaning ffor vendors with yocto capable hardware | 14:28 |
| LetoThe2nd | OutBackDingo: like a list to advertise your products, or what? | 14:28 |
| OutBackDingo | yeah | 14:29 |
| OutBackDingo | LetoThe2nd: right | 14:29 |
| OutBackDingo | or at least get word out | 14:29 |
| LetoThe2nd | OutBackDingo: send $$$ to the yocto project, become platinum sponsor, and then convice all the other platinum sponsors that its a good idea to use the project as advertising. :-P | 14:30 |
| LetoThe2nd | OutBackDingo: until that happens, only thing is to become yocto project compliant as far as i know | 14:31 |
| OutBackDingo | hahahhaha | 14:31 |
| OutBackDingo | well we have thud running on some new pi clone SOM boards | 14:31 |
| rburton | having the layer being yp compliant means it goes on a list on the web site | 14:31 |
| LetoThe2nd | OutBackDingo: everybody has something running on something. | 14:31 |
| OutBackDingo | true | 14:31 |
| LetoThe2nd | see :) | 14:31 |
| OutBackDingo | i know... mama alwats told me i was nothing special :) | 14:32 |
| *** demonimin <demonimin!~demonimin@unaffiliated/demonimin> has quit IRC | 14:32 | |
| LetoThe2nd | its the other way round. we are all special! | 14:32 |
| LetoThe2nd | no, seriously. do the compliancy dance, its the best value for money you can probably get. | 14:33 |
| *** demonimin <demonimin!~demonimin@unaffiliated/demonimin> has joined #yocto | 14:33 | |
| *** Pharaoh_Atem <Pharaoh_Atem!~neal@fedora/ngompa> has joined #yocto | 14:33 | |
| *** demonimin <demonimin!~demonimin@unaffiliated/demonimin> has quit IRC | 14:39 | |
| *** armpit <armpit!~armpit@116.212.180.67> has joined #yocto | 14:42 | |
| *** fbre <fbre!91fdde45@gateway/web/freenode/ip.145.253.222.69> has joined #yocto | 14:55 | |
| fbre | Hi, booting from QuadSPI flash of an i.MX8 eval board requires to build a bootable image which I must flash at address 0x0 of the flash. Such image consists of certain parameters as header and the actual program which is u-boot. How does yocto support to build such image? I've just seen u-boot is bitbaked, but it's not that bootable image. | 15:00 |
| LetoThe2nd | fbre: if the u-boot build process can support such an image, then you'll probably have to adjust it for your specific hardware. | 15:00 |
| LetoThe2nd | just like generating an spl for some boards | 15:01 |
| fbre | LetoThe2nd: What does the abbreviation "spl" mean? | 15:03 |
| *** blueness <blueness!~blueness@gentoo/developer/blueness> has quit IRC | 15:07 | |
| varjag | secondary program loader | 15:07 |
| *** otavio <otavio!~otavio@debian/developer/otavio> has quit IRC | 15:08 | |
| *** blueness <blueness!~blueness@gentoo/developer/blueness> has joined #yocto | 15:08 | |
| *** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC | 15:08 | |
| fbre | ah OK | 15:08 |
| *** armpit <armpit!~armpit@116.212.180.67> has quit IRC | 15:09 | |
| fbre | I thought secondary poot loader :) | 15:09 |
| *** acrap <acrap!~Thunderbi@host-85-237-33-147.dsl.sura.ru> has quit IRC | 15:10 | |
| *** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto | 15:13 | |
| *** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC | 15:17 | |
| zeddii | RP: I just poked around a bit, but didn’t see the poky-tiny test build configuration. I’m building core-image-minimal with my distro set to poky-tiny, but wanted to build the same image types as the AB. | 15:19 |
| *** WillMiles <WillMiles!~Will@static-209-87-231-80.storm.ca> has joined #yocto | 15:19 | |
| *** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto | 15:24 | |
| sveinse | I'm seeing some variance inbetween builds when using runqemu, where it works one time and not in the next build. The out-of-box kernel of qemux64 is depending that the system drive is a scsi device. And I see that sometimes runqemu sets up the proper scsi virtio, other times it does not (and it fails to start). Any ideas on how to approach that inconsistency? | 15:26 |
| *** sjolley_ <sjolley_!~sjolley_@c-71-59-136-149.hsd1.or.comcast.net> has joined #yocto | 15:27 | |
| sveinse | Drop using runqemu and make my own where I control the qemu options? | 15:27 |
| *** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC | 15:29 | |
| sveinse | Does Yocto have any generic x64 intel MACHINE, or is qemux64 precisely that? | 15:30 |
| *** fbre <fbre!91fdde45@gateway/web/freenode/ip.145.253.222.69> has quit IRC | 15:30 | |
| kergoth | genericx86, perhaps? | 15:31 |
| kergoth | though that might not be x64, thinking about it | 15:31 |
| * kergoth needs more coffee | 15:31 | |
| rburton | sveinse: genericx86-64 is that, but the meta-intel intel-corei7-64 is better | 15:33 |
| rburton | especially if you're actually targetting intel | 15:33 |
| sveinse | rburton: yeah, I'm going to run the image in a containerized/VM environment, so something modern is best :) | 15:34 |
| rburton | meta-intel is what you want then | 15:34 |
| *** frsc <frsc!~frsc@2003:a:e7a:6200:246c:2a8b:f45a:a33d> has quit IRC | 15:35 | |
| sveinse | rburton: thanks, I'll try that. Hopefully I have better luck with other hypervisors then | 15:35 |
| zeddii | well, technically linux-yocto is ahead of meta-intel ;) | 15:35 |
| rburton | pah ;) | 15:36 |
| rburton | sveinse: qemu* assumes its running in qemu | 15:36 |
| sveinse | rburton: yup, figured as much. Actually it works fine in VirtualBox. But not in Hyper-V, due to not having IDE storage in kernel | 15:37 |
| *** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto | 15:37 | |
| rburton | yeah its pretty tuned for what qemu offers for HW | 15:37 |
| *** Simgate <Simgate!540e05c8@gateway/web/freenode/ip.84.14.5.200> has joined #yocto | 15:37 | |
| sveinse | Althou not quite straight forward in all combinations of IMAGE_FSTYPES in qemu either, as it varies in how it configures the storage device apparently | 15:38 |
| *** Simgate <Simgate!540e05c8@gateway/web/freenode/ip.84.14.5.200> has quit IRC | 15:38 | |
| *** learningc <learningc!~learningc@121.122.105.31> has joined #yocto | 15:42 | |
| *** LocutusOfBorg <LocutusOfBorg!LocutusOfB@ubuntu/member/locutusofborg> has joined #yocto | 15:53 | |
| voyo | RP: thanks for tip, I put MULTILIBS="" in local.conf and it make it | 15:53 |
| *** LocutusOfBorg <LocutusOfBorg!LocutusOfB@ubuntu/member/locutusofborg> has joined #yocto | 15:55 | |
| voyo | however I have other problem, looks like building of my receipe stuck on "do_package_qa" stuck , it is quite simple receipe but it is running almost 1h... how to check what it is doing ? | 15:55 |
| *** klemen <klemen!~textual@193.189.172.170> has quit IRC | 15:57 | |
| *** rcw <rcw!~rcw@128.224.252.2> has joined #yocto | 15:58 | |
| voyo | looks like it is waiting for some input on /home/voyo/IOX/opencgx-x86-generic-64-4.14-2.4/iox/tmp/work/core2-64-poky-linux/iox-cisco/1.0-r0/packages-split/iox-cisco/package/temp/fifo.54088 | 16:02 |
| voyo | anyone have idea what it is about ? | 16:02 |
| sveinse | voyo: what is process 54088 ? | 16:05 |
| voyo | sveinse: no such process | 16:06 |
| voyo | (anymore , I suppose) | 16:06 |
| *** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC | 16:08 | |
| *** fl0v0 <fl0v0!~fvo@89.244.126.68> has quit IRC | 16:09 | |
| yocti | New news from stackoverflow: Odroid XU4 with Yocto and GUI (gtk+3 error wayland-egl not found) <https://stackoverflow.com/questions/55577521/odroid-xu4-with-yocto-and-gui-gtk3-error-wayland-egl-not-found> | 16:10 |
| *** lusus <lusus!~lusus@62.91.23.180> has quit IRC | 16:11 | |
| *** yann <yann!~yann@85.118.38.73> has quit IRC | 16:13 | |
| *** jmiehe <jmiehe!~Thunderbi@p578c106e.dip0.t-ipconnect.de> has quit IRC | 16:18 | |
| *** varjag <varjag!~user@122.62-97-226.bkkb.no> has quit IRC | 16:21 | |
| *** yacar_ <yacar_!~yacar@80.215.66.56> has quit IRC | 16:25 | |
| *** mckoan is now known as mckoan|away | 16:27 | |
| sveinse | When using MACHINE=intel-corei7-64 my image does not parse. It throws a "ERROR: Task do_bootimg in */my-image.bb depends on non-existent task do_image_ext4 in */my-image.bb", yet building core-image-minimal works. I've grepped the sources and I am not finding any clues to why. Any ideas guys? | 16:33 |
| sveinse | That is, I'm not using neither do_bootimg or do_image_ext4 in my image recipe | 16:36 |
| rburton | does your image set an image type? | 16:37 |
| sveinse | rburton: ah. yes IMAGE_FSTYPES="wic.vmdk tar.xz". When I added ext4 to the list, then it proceeds. Apparently metal-intel requres must have ext4 as a target | 16:40 |
| sveinse | *meta-intel :D | 16:40 |
| *** sjolley_ <sjolley_!~sjolley_@c-71-59-136-149.hsd1.or.comcast.net> has quit IRC | 16:42 | |
| *** stephano <stephano!~stephano@134.134.139.76> has quit IRC | 16:56 | |
| RP | rburton: right now python3 shows no test success, no fail and no skipped | 16:57 |
| RP | rburton: i.e. zero counts everywhere | 16:57 |
| rburton | urgh | 16:57 |
| zeddii | RP: do you recall if qemuarm (qemuarma15) for 5.0 booted in nographic mode ? | 17:08 |
| zeddii | I’m testing tiny and seeing a hang. i just started a poky build, but it’ll take a while | 17:08 |
| *** moto-timo <moto-timo!ttorling@fsf/member/moto-timo> has joined #yocto | 17:14 | |
| *** tprrt <tprrt!~tprrt@217.114.201.133> has quit IRC | 17:32 | |
| *** justinsg <justinsg!sid296040@gateway/web/irccloud.com/x-wnffbehhuypebtjh> has quit IRC | 18:20 | |
| *** dagmcr <dagmcr!sid323878@gateway/web/irccloud.com/x-oksymsvsvayxljmj> has quit IRC | 18:20 | |
| *** tardyp <tardyp!sid45259@gateway/web/irccloud.com/x-nvvlqxsnyzqevjft> has quit IRC | 18:20 | |
| *** sjolley_ <sjolley_!~sjolley_@2600:100f:b118:9190:90a5:c83c:756a:294b> has joined #yocto | 18:20 | |
| *** ndec <ndec!sid219321@linaro/ndec> has quit IRC | 18:20 | |
| *** Tartarus <Tartarus!sid72705@gateway/web/irccloud.com/x-fkvwweoctjpkpugz> has quit IRC | 18:20 | |
| *** justinsg <justinsg!sid296040@gateway/web/irccloud.com/x-tkjujenvnjabopbk> has joined #yocto | 18:20 | |
| *** hugo___ <hugo___!sid6079@gateway/web/irccloud.com/x-mhcediptjylznlar> has quit IRC | 18:20 | |
| *** paulbarker <paulbarker!sid269702@gateway/web/irccloud.com/x-syawsftkvcszxrhx> has quit IRC | 18:20 | |
| *** ndec <ndec!sid219321@linaro/ndec> has joined #yocto | 18:20 | |
| *** mirzak <mirzak!sid303002@gateway/web/irccloud.com/x-ffxokgjlxikhsefr> has quit IRC | 18:20 | |
| *** paulbarker <paulbarker!sid269702@gateway/web/irccloud.com/x-kbfsvnynhyjnaubu> has joined #yocto | 18:20 | |
| *** dagmcr <dagmcr!sid323878@gateway/web/irccloud.com/x-xjrcxxrdqhsvjmbq> has joined #yocto | 18:20 | |
| *** hugo___ <hugo___!sid6079@gateway/web/irccloud.com/x-wndobnzbcqmxnxoz> has joined #yocto | 18:21 | |
| *** tardyp <tardyp!sid45259@gateway/web/irccloud.com/x-jvfileosofzaqbgg> has joined #yocto | 18:21 | |
| *** Tartarus <Tartarus!sid72705@gateway/web/irccloud.com/x-nszlycqswpbjirfy> has joined #yocto | 18:21 | |
| *** sjolley_ <sjolley_!~sjolley_@2600:100f:b118:9190:90a5:c83c:756a:294b> has quit IRC | 18:24 | |
| *** sjolley_ <sjolley_!~sjolley_@2600:100f:b118:9190:90a5:c83c:756a:294b> has joined #yocto | 18:37 | |
| sveinse | Has there been any efforts in Yocto/OE towards building images for containerized deployment, e.g. docker? I believe the images would be somewhat different. E.g. no need for any kernel or systemed, yet some low-level system things must be deployed, such as libc. | 18:38 |
| Crofton | Yes | 18:40 |
| Crofton | https://www.youtube.com/watch?v=OSyLoHYxGLQ&feature=youtu.be | 18:41 |
| Crofton | https://elinux.org/images/6/62/Building-Container-Images-with-OpenEmbedded-and-the-Yocto-Project-Scott-Murray-Konsulko-Group-1.pdf | 18:41 |
| *** sjolley_ <sjolley_!~sjolley_@2600:100f:b118:9190:90a5:c83c:756a:294b> has quit IRC | 18:41 | |
| *** T_UNIX <T_UNIX!uid218288@gateway/web/irccloud.com/x-fcmresbzfipbpbfl> has quit IRC | 18:42 | |
| sveinse | Crofton: cool, thanks | 18:42 |
| *** kaspter <kaspter!~Instantbi@125.118.63.231> has quit IRC | 18:44 | |
| *** kaspter <kaspter!~Instantbi@125.118.63.231> has joined #yocto | 18:45 | |
| rburton | sveinse: there's a container image type that rips out kernels and stuff as a generic starter | 18:48 |
| rburton | sveinse: integration per-service is more specific, patches welcome. also try meta-virtualisation? | 18:49 |
| Crofton | bottom, OpenEmbedded, it isn't just for embedded anymore :) | 18:50 |
| sveinse | rburton: Yes. We have two setups, one where we are running docker server on embedded hardware, so meta-virtualization is used there. The other, which I'm experimenting with, is to build and run images for this purpose. | 18:51 |
| sveinse | At the same time, we want to be able to deploy the same SW into cloud computing. Since we have the ecosystem up and running with OE, it would be absolutely best if images could be build to cloud as well. Saves us from needing to make a build system for it. And OE seems very promising | 18:53 |
| Crofton | Yes, people already do this | 18:54 |
| sveinse | I'm building the image for intel-corei7-64 now to see if that is good generic platform for that. Takes a while on my sluggish machine :D | 18:54 |
| sveinse | Not sure yet clear if I need a VM or a container, so I'm testing both approaches | 18:55 |
| sveinse | Not related to this specific task, but management has asked me to assess if building our OE images is feasable using cloud services as opposed to purchase and maintain local metal. Then I will be placing yocto inside a docker container. | 18:58 |
| sveinse | So everything everywhere is cloud and containers these days | 18:59 |
| *** ebolton <ebolton!~ebolton@208.77.58.11> has joined #yocto | 19:07 | |
| ebolton | is there an easy way to set the "-native" and "-nativesdk" variations of variables to the "base" version in a python function, I'm trying to use a single assignment that calls a function to set all three without copy-pasting the assignments...the env dump shows the override, but uses the default value | 19:09 |
| *** JaMa <JaMa!~martin@ip-217-030-068-212.aim-net.cz> has quit IRC | 19:17 | |
| sveinse | I'm having the same problems booting any .wic or .wic.vmdk images with runqemu, even under the intel-corei7-64 machine. It does work using the ext4 image. I am able to start the .wic.vmdk image in virtualbox only if I enable EFI. Yet I cannot see any secureboot or efi packages in the manifest. | 19:25 |
| *** learningc <learningc!~learningc@121.122.105.31> has quit IRC | 19:28 | |
| voyo | guys, I need to have a very simple receipe, for my own simple &small image, with only static files (nothing to build/compile) and maybe untar some archives inside rootfs. what receipe to use as best example ? is there any doc with description ? | 19:32 |
| RP | zeddii: I don't think I've tested that, only in graphic mode | 19:40 |
| RP | zeddii: FWIW these are the tiny tests we run, I think its only qemux86: https://autobuilder.yoctoproject.org/typhoon/#/builders/15/builds/711 | 19:40 |
| *** tgraydon <tgraydon!~textual@134.134.139.76> has joined #yocto | 19:45 | |
| rburton | sveinse: grub-efi is the bootloader | 19:46 |
| rburton | or, systemd-boot | 19:46 |
| zeddii | RP: ok, cool. I can confirm that qemux86 works. qemuarm has an issue. I'll poke at arm a bit, but prepare a patch regardless. | 19:47 |
| RP | zeddii: sounds good! I'd like to sort qemuarm for tiny and can add testing for that but that can be 2.8 | 19:49 |
| RP | zeddii: is non-tiny nographic also having issues? | 19:49 |
| zeddii | nope. it worked. | 19:49 |
| sveinse | rburton: interestingly, manifest lists neither (-- this is on rocko) | 19:50 |
| zeddii | poky -> qemuarm -> 5.0 -> nographic was fine. | 19:50 |
| RP | zeddii: I wonder if its related to that edid stuff | 19:50 |
| zeddii | either that or a kernel config. I'll try a couple of things and see if I can find a smoking gun. but will definitely send a patch later tonight, so you'll have it in your morning. | 19:50 |
| RP | zeddii: thanks. Things are starting to come together for 2.7 rc1 :) | 19:51 |
| RP | apart from the string of AB build failures :/ | 19:51 |
| sveinse | I'm more hampereded by not being able to build a kernel less image with IMAGE_FSTYPES="container" and that bitbake faults at parsing since there is no "ext4" target | 19:51 |
| rburton | sveinse: welcome to a quirk: image manifest doesn't found stuff that isn't in a image, and the boot partition with a wic isn't an image | 19:52 |
| sveinse | rburton: ah, right, makes kinda sense. Thanks. | 19:52 |
| RP | rburton: is there a downside if I swap py3 back to -v instead of -W for run-ptest? | 19:53 |
| *** yann <yann!~yann@lfbn-1-3372-5.w90-127.abo.wanadoo.fr> has joined #yocto | 19:56 | |
| sveinse | In meta-intel/documentation/secureboot/README it states that IMAGE_FEATURES += " secureboot" should be used for that. Sorry if this is a stupid question but is secureboot something else than UEFI? Because my image requires EFI set in the hypervisor apparently, but I have not configured secureboot. | 19:58 |
| voyo | sveinse: secureboot is kind of "sub function" of UEFI, you can have UEFI but not enable secureboot. secureboot itself will allow you to boot only signed binary. | 20:01 |
| *** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC | 20:02 | |
| sveinse | voyo: thanks | 20:03 |
| *** rcw <rcw!~rcw@128.224.252.2> has quit IRC | 20:03 | |
| voyo | np. however I havwe no idea how it is implemented within OE, and how to provide certs to check signature of your binary. | 20:06 |
| sveinse | voyo: no worries. My concern is more that it seems my VM (Azure) provider does not support for gpt or uefi or SCSI (need IDE) :( | 20:07 |
| voyo | very simple booting option only then... | 20:08 |
| *** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto | 20:08 | |
| sveinse | voyo: yet, browsning through meta-intel, it doesn't seem to support non-gpt and uefi without manual tweaking | 20:09 |
| sveinse | Understandable. Gpt and uefi has been with us for a while. Only ancient hardware doesn't support it | 20:10 |
| sveinse | So its Azure Cloud which is the surprise here | 20:11 |
| *** otavio <otavio!~otavio@debian/developer/otavio> has joined #yocto | 20:11 | |
| voyo | well. for simple images, virtualization stuff, etc. - personally - I wouldnt need and rather not want to have such complex things like uefi , its just overkill if you simply need to boot small image. For embeded devices you will have to use uboot or similar stuff anyway... | 20:16 |
| voyo | by assumption you are working under very limited and controlled environment, so why to worry for uefi and makes life even more miserable ;) | 20:17 |
| sveinse | voyo: Well, I don't really want it. At least not for the VM part. But it seems integrated into the image | 20:18 |
| *** la_croix <la_croix!~la_croix@cpc97624-walt24-2-0-cust98.13-2.cable.virginm.net> has quit IRC | 20:19 | |
| RP | seebs: around? | 20:19 |
| voyo | you mean UEFI is built in your image, even you dont asked for it ? I see.. Im just starting with OE/yocto, have only small experience with images build by somebody else, using quite old version, with just old grub on board. | 20:20 |
| RP | seebs: I have some data on our mysterious owner corruption... | 20:20 |
| RP | seebs: I don't understand it though! | 20:20 |
| sveinse | voyo: correct. I pull in meta-intel, set MACHINE="intel-corei7-64" and then I get uefi when I build wic based image | 20:24 |
| voyo | sveinse: what if you choose other MACHINE , maybe something like generic_x64 make a difference ? | 20:25 |
| voyo | btw, I need to have a very simple receipe, for my own simple &small image, with only static files (nothing to build/compile) and maybe untar some archives inside rootfs. what receipe to use as best example ? is there any doc with description ? | 20:26 |
| sveinse | voyo: hmm on rocko it sais: "MACHINE=generic_x64 is invalid." | 20:28 |
| seebs | RP: semi-around, what's up? | 20:29 |
| rburton | sveinse: can't you just throw a ext4 at the cloud provider thingy? | 20:29 |
| RP | seebs: otavio has a reproducer for our weird pseudo owner corruption and some logs | 20:30 |
| RP | seebs: I was hoping you could glance at them and see if its anything obvious to you | 20:30 |
| RP | seebs: A cutdown version: https://paste.debian.net/1076734/ | 20:30 |
| RP | seebs: basically that file should be owned by 0 but becomes owned by 1000 | 20:31 |
| RP | seebs: the "symlink mismatch" being the thing which seems to be a smoking gun | 20:31 |
| voyo | sveinse: genericx86-64 | 20:31 |
| sveinse | rburton: no, not when running a full VM. Even the wic is a intermediate format, as it must be converted to the appropriate hypervisor format | 20:32 |
| RP | seebs: I can give a link to the full logs and bitbake output but I think that is perhaps the most obvious filtered version | 20:32 |
| RP | seebs: I guess its saying the inode number in the database and the inode number on disk are different hence the "inode mismatch" | 20:33 |
| *** la_croix <la_croix!~la_croix@cpc97624-walt24-2-0-cust98.13-2.cable.virginm.net> has joined #yocto | 20:33 | |
| RP | seebs: even then the later 1000 owner which suddenly appears makes no sense | 20:35 |
| seebs | huh | 20:35 |
| seebs | this is interesting. | 20:36 |
| sveinse | What is the difference from using genericx86-64 vs intel-corei7-64? Is is only cpu options and uefi/gpt booting? | 20:36 |
| seebs | there's no "linking [...] for" messages. but every call to pdb_link_file should be preceeded by one, I think? | 20:36 |
| seebs | pseudo_debug(PDBGF_DB, "linking %s for %s\n", | 20:37 |
| seebs | msg->pathlen ? msg->path : "no path", | 20:37 |
| seebs | pseudo_op_name(msg->op)); | 20:37 |
| seebs | pdb_link_file(msg); | 20:37 |
| RP | seebs: This was a filtered log, not sure if that got stripped out | 20:37 |
| *** sjolley_ <sjolley_!~sjolley_@65.158.186.241> has joined #yocto | 20:38 | |
| voyo | sveinse: did you saw this? - https://wiki.yoctoproject.org/wiki/How_do_I#Q:_How_do_I_build_a_wic_image.3F | 20:49 |
| sveinse | voyo: yeah sure. Can't build a bootable image without wic. | 20:50 |
| seebs | it shouldn't have, i think, since the path should have matched. i think. | 20:54 |
| seebs | and the unfiltered log seems not to have them either, which is weird. | 20:54 |
| seebs | oh, i see. those lines are under PDBGF_DB, but only PDBGF_FILE is in use. | 20:54 |
| seebs | and they probably shouldn't be restricted like that, but i'm honestly not sure. | 20:55 |
| rburton | sveinse: .wic is just a disk image format, its not a special format. vmdk etc is just optimised for vm use. | 21:05 |
| rburton | sveinse: compiler tune and kernel (generic vs intel) | 21:05 |
| sveinse | rburton: yes, thanks. I know what wic is | 21:06 |
| sveinse | rburton: is it correct that uefi and gpt cannot be turned off with an option in meta-intel? | 21:06 |
| rburton | its the wic image that is controling that iirc | 21:09 |
| rburton | which is controllable just set WKS_FILE | 21:10 |
| *** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto | 21:20 | |
| *** WillMiles <WillMiles!~Will@static-209-87-231-80.storm.ca> has quit IRC | 21:21 | |
| *** stephano <stephano!stephano@nat/intel/x-hlucxjwwcbkiqzwg> has joined #yocto | 21:26 | |
| *** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC | 21:28 | |
| * sveinse is starting to feel like a bitcoin miner with the amount of heat generated from compiling for 3 new machines, each 10k OE tasks from scratch | 21:39 | |
| *** armpit <armpit!~armpit@116.212.180.67> has joined #yocto | 21:50 | |
| *** sjolley_ <sjolley_!~sjolley_@65.158.186.241> has quit IRC | 22:03 | |
| *** agust <agust!~agust@p508B6C31.dip0.t-ipconnect.de> has quit IRC | 22:16 | |
| *** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto | 22:21 | |
| *** armpit <armpit!~armpit@116.212.180.67> has quit IRC | 23:06 | |
| yocti | New news from stackoverflow: Why is my kernel configuration option not set in resulting defconfig after running bitbake -c savedefconfig virtual/kernel? <https://stackoverflow.com/questions/55582908/why-is-my-kernel-configuration-option-not-set-in-resulting-defconfig-after-runni> | 23:11 |
| *** justanotherboy <justanotherboy!~justanoth@136.49.196.186> has joined #yocto | 23:12 | |
| *** khem <khem!~khem@unaffiliated/khem> has quit IRC | 23:13 | |
| *** khem <khem!~khem@unaffiliated/khem> has joined #yocto | 23:14 | |
| *** rburton <rburton!~rburton@35.106.2.81.in-addr.arpa> has quit IRC | 23:32 | |
Generated by irclog2html.py 2.11.0 by Marius Gedminas - find it at mg.pov.lt!