Monday, 2019-04-08

* armpit great warrior -next has patches that are not in master00:13
*** la_croix <la_croix!> has quit IRC00:51
*** la_croix <la_croix!> has joined #yocto00:55
*** la_croix <la_croix!> has quit IRC01:01
*** la_croix <la_croix!> has joined #yocto01:04
*** la_croix <la_croix!> has quit IRC01:30
*** la_croix <la_croix!> has joined #yocto01:31
*** demonimin_ <demonimin_!~demonimin@unaffiliated/demonimin> has joined #yocto01:40
*** demonimin <demonimin!~demonimin@unaffiliated/demonimin> has quit IRC01:40
*** demonimin_ <demonimin_!~demonimin@unaffiliated/demonimin> has quit IRC01:48
*** demonimin <demonimin!~demonimin@unaffiliated/demonimin> has joined #yocto02:05
*** learningc <learningc!> has joined #yocto02:15
*** learningc <learningc!> has quit IRC02:38
*** learningc <learningc!> has joined #yocto02:39
*** learningc <learningc!> has joined #yocto02:41
*** fatalhalt <fatalhalt!> has quit IRC02:59
OutBackDingoermmm whys my thud image installing both python2 and python3 ???03:08
*** sjolley_ <sjolley_!> has quit IRC03:14
*** comptroller <comptroller!> has quit IRC03:36
*** justanotherboy <justanotherboy!~justanoth@> has quit IRC04:09
*** lexano <lexano!> has quit IRC04:21
*** lexano <lexano!> has joined #yocto04:25
*** armpit <armpit!~armpit@> has quit IRC04:25
*** armpit <armpit!~armpit@> has joined #yocto05:32
*** AndersD <AndersD!~AndersD@> has joined #yocto05:59
lukmaThe image.bbclas defines do_fetch[noexec] = '1'06:01
lukmaIs there a way to re-enable fetch in my recipe (so SRC_URI = "file://foo") copies foo to ${WORKDIR} ?06:02
lukmaOr 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!> has joined #yocto06:12
lukmaor better base_do_unpack() ?06:13
*** sk_tandt <sk_tandt!> has joined #yocto06:22
*** frsc <frsc!~frsc@2003:a:e7a:6200:246c:2a8b:f45a:a33d> has joined #yocto06:22
*** jmiehe <jmiehe!> has joined #yocto06:43
*** cvasilak <cvasilak!~cvasilak@2a02:587:8117:600:2482:3aec:ef75:9af7> has joined #yocto06:48
*** Bunio_FH <Bunio_FH!> has joined #yocto06:54
*** mckoan|away is now known as mckoan06:56
mckoangood morning06:56
*** varjag <varjag!> has joined #yocto06:57
*** fl0v0 <fl0v0!~fvo@> has joined #yocto06:58
*** jeanba <jeanba!~jbl@> has joined #yocto07:03
*** jeanba <jeanba!~jbl@> has left #yocto07:03
LetoThe2ndmckoan: depends on your definition07:10
*** tprrt <tprrt!~tprrt@> has joined #yocto07:11
*** lusus <lusus!~lusus@> has joined #yocto07:12
*** sk_tandt <sk_tandt!> has quit IRC07:15
*** MarcWe <MarcWe!hmwmatrixo@gateway/shell/> has joined #yocto07:17
yannRP: 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
yannI'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 fit07:21
*** yacar_ <yacar_!~yacar@> has joined #yocto07:28
*** acrap <acrap!> has joined #yocto07:28
acrapHi, folks!07:29
mckoanLetoThe2nd: c'mon be positive :-D07:29
*** Striking7 <Striking7!> has quit IRC07:30
acrapI 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
acrapI think it would be great to create separate recipes for those subprojects07:31
acrapbut the problem is - I need an access to their sources from the main one07:31
*** yann <yann!> has quit IRC07:32
acrapSo, those recipes I want to copy should only do the following job: fetch, patch, populate their sources somewhere07:33
*** Striking7 <Striking7!> has joined #yocto07:34
acrapSure I can do it manually, but I am just wondering if there is a standard way (or just less dull)07:34
*** TobSnyder <TobSnyder!> has joined #yocto07:35
acrapseems like I've already found the solution07:39
acrappatchdir - Specifies the directory in which the patch should be applied. The default is ${S}.07:39
acrapIt's a lot easier than I thought07:39
armpitLetoThe2nd, needs some heavy metal07:41
armpitmckoan, just scream it at LetoThe2nd07:43
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto07:55
LetoThe2ndarmpit: ++07:57
LetoThe2ndmckoan: actually, i sent some potential customer your way last week07:57
*** yacar_ <yacar_!~yacar@> has quit IRC07:58
*** jku <jku!> has joined #yocto08:00
*** yann <yann!~yann@> has joined #yocto08:13
*** RP <RP!> has joined #yocto08:15
yannhi RP - did not notice you were away08:18
*** kaspter <kaspter!~Instantbi@> has quit IRC08:18
yannRP: 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
yannI'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 fit08:19
*** kaspter <kaspter!~Instantbi@> has joined #yocto08:19
RPyann: You have a piece which needs immediate expansion (THISDIR) and a piece which does not (PV)08:20
RPyann: try something like MYAPPENDDIR := "${THISDIR}" then FILESEXTRAPATH_append = "${MYAPPENDDIR}/${PV}"08:21
RPthe spacing and so on needs tweaking there08:21
yannhm, not far from one of my attempts, but I had missed the immediate-expansion part08:22
*** voyo <voyo!> has quit IRC08:22
*** lfa <lfa!~lfa@> has joined #yocto08:24
*** yacar_ <yacar_!~yacar@> has joined #yocto08:24
yannRP: that does the job well enough, thanks much!08:27
armpitRP, i have some sumo-nmut failures that I wont be able to look at until I get home on thursday08:28
armpitthud-nmut looks good and is out for review. I send a pull request tomorrow?08:29
* armpit what day is today??08:30
RParmpit: Monday08:31
RParmpit: I saw the thud email, patches looked good thanks08:32
*** cvasilak <cvasilak!~cvasilak@2a02:587:8117:600:2482:3aec:ef75:9af7> has quit IRC08:33
*** cvasilak <cvasilak!~cvasilak@2a02:587:8117:600:2482:3aec:ef75:9af7> has joined #yocto08:34
* armpit going to be 34C here today.. 08:34
*** jku <jku!> has quit IRC08:38
RParmpit: couldn't stand that :)08:38
armpiti can last an hour of that then I melt08:40
lukmaMaybe somebody had similar issue08:40
lukmato use / copy SRC_URI's file:// to WORKDIR when one uses inherit image.bbclass ?08:41
RPlukma: As I mentioned, it should be enough to delete the noexec flag using delVarFlag08:41
lukmaThe python () { d.delVarFlag("do_fetch", "noexec") } is not enough08:41
RPlukma: something odd is going on if that isn't enoug08:41
lukmaI need to create separate task and put there:08:42
lukmasrc_uri = (d.getVar('SRC_URI') or "").split()08:42
lukmafetcher = bb.fetch2.Fetch(src_uri, d)08:42
RPlukma: $ bitbake core-image-sato -e | grep python.do_fetch -C 508:43
RPshows python do_fetch () {'base_do_fetch', d) }08:43
RPwhich implies the function still exists08:44
lukmarecipes-core/images/', lineno: 16, function: do_get_foo08:44
lukma     0012:# image.bbclass disabled calls do_fetch[noexec] = 1,08:44
lukma     0013:# which disables fetcher - so no files are provided via08:44
lukma     0014:# SRC_URI08: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_foo08:44
lukmaException: NameError: name 'base_do_fetch' is not defined08:44
*** T_UNIX <T_UNIX!uid218288@gateway/web/> has joined #yocto08:45
lukmaWith the -e flag08:45
lukmapython do_fetch () {08:45
lukma'base_do_fetch', d)08:45
lukmaIt is also there ...08:46
RPyou can't call it like that. Please use pastebin for things which are multiple lines08:47
lukmaNow it shall be more concise08:51
RPlukma:'base_do_fetch', d) is not the same as base_do_fetch()08:52
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto08:52
RPlukma: and I still don't see why you would need to add a new task08:52
lukmaRP: I've double checked - I only do have python do_fetch () {'base_do_fetch', d) }08:56
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC08:57
RPlukma: can you share the code you're trying which sets SRC_URI and deletes the noexec fetch/unpack var flag?08:57
RPlukma: and clearly say what happens or doesn't happen. Its very hard for me to guess what you're doing or what the problem is08:58
*** falk0n_ <falk0n_!> has quit IRC09:01
*** falk0n <falk0n!> has joined #yocto09:03
RPlukma: well, that won't even parse. You want the "." between d and delVarFlag09:04
RPlukma: you also want a second line under it which is the same but change fetch for unpack09:04
*** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto09:05
lukmaRP: With the dot - correct it is in the recipe09:05
RPlukma: what about the second line?09:09
RPlukma: you need both, ie. python () { d.delVarFlag("do_fetch", "noexec") d.delVarFlag("do_unpack", "noexec") }09:10
*** la_croix <la_croix!> has quit IRC09:11
*** la_croix <la_croix!> has joined #yocto09:14
lukmaRP: It seems like the do_fetch / do_unpack functions are missing09:15
*** alcroito <alcroito!> has joined #yocto09:15
lukmaor not inherited properly09:15
*** alcroito <alcroito!> has left #yocto09:15
RPlukma: they're clearly not missing as the -e output shows them. The question is why they're not executing09:16
RPlukma: try "-e | grep do_fetch", it will have more output but perhaps more clues. I'm interested in the tasks output09:16
lukmaThe question is about core-image, but image.bbclass superseeds it09:17
RPlukma: right, same issue, the noexec09:17
lukmaRP: So with -e the python base_do_fetch () { is visible and correct09:24
sveinseWhat 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 process09:25
sveinseMy ultimate goal is to be able to run the yocto image from a VM (in Azure cloud)09:26
RPsveinse: compare the commandlines?09:31
RPlukma: that wasn't what I asked. I'm interested in the long line started #     "{'tasks':09:32
RPlukma: I suspect you have some other layer/class involved which is doing something like a deltask do_fetch09:32
RPlukma: but I simply can't tell09:32
sveinseRP: 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 boot09:34
sveinseI plan on getting it from 'runqemu' to standalone qemu to VirtualBox to HyperV to Cloud.09:38
*** marble_visions <marble_visions!~user@> has quit IRC09:38
JaMasveinse: my guess is the rnd initialization09:39
*** yacar_ <yacar_!~yacar@> has quit IRC09:40
JaMasveinse: at least it was for me when using old script for running qemu builds and vbox09:40
*** marble_visions <marble_visions!~user@> has joined #yocto09:40
RPlukma: right, so it is running do_fetch but not finding the file?09:41
JaMasveinse: 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 there09:42
RPlukma: is the file <dir>/recipes-core/images/image-foo/foo.its ?09:42
sveinseJaMa: 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
JaMausing uvesafb?09:44
lukmaRP: Yes, the file is there09:44
sveinseJaMa: Don't know. Just using out of box config from rocko, so I probably need to configure it09:45
RPlukma: ok, so what does the unpack log say?09:46
RPlukma: I wonder if do_roots[cleandirs] is cleaning up the file before you can see it09:47
sveinseJaMa: 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 them09:47
RPlukma: try bitbake image-foo -c unpack -f09:47
lukmaRP: Hmm....09:50
lukmaIt is placed in WORKDIR now .....09:50
lukmaRP: Let me double check it with sstate cache removed09:50
RPlukma: I suspect the rootfs code is cleaning it up before it starts09:51
lukmaRP: I suppose that the task do_rootfs () is necessary to use IMAGE_CMD ...09:52
RPlukma: addtask do_stashfile before do_rootfs after do_unpack ?09:54
RPlukma: put the file somewhere safe?09:54
sveinseWhere 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
lukmaRP: It shall be safe in WORKDIR? (as I just use it with IMAGE_CMD_foo mkimage09:56
*** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC09:56
RPlukma: probably09:56
lukmaRP: Ok, it seems like the problem was with no re-enabling both d.delVarFlag("do_fetch", "noexec") d.delVarFlag("do_unpack", "noexec"09:58
lukmaRP: As fetch just "downloads" the stuff and "unpack" places it in ${S} or ${WORKDIR}09:59
lukmaRP: Thanks for explanation and help :)10:01
lukmaRP: BIG thanks - sounds better :)10:01
*** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto10:02
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto10:08
yoctiNew news from stackoverflow: Yocto Image Recipe and SRC_URI <>10:09
*** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC10:11
kanavinRP: yes, thanks for pushing the hang issue further10:12
*** AndersD <AndersD!~AndersD@> has quit IRC10:13
RPkanavin: 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 hang10:14
RPkanavin: my local builds are a mess so rebuilding atm10:15
RPkanavin: Your work triggered me to run the bisect whilst watching TV :)10:15
kanavinRP: right, I did not check if the rest of the tests are okay10:15
kanavinbisecting poky is time-consuming10:16
*** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto10:16
RPkanavin: 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
kanavinRP: I also wonder if 5 minutes timeout set by ptest-runner is genuinely too small, even with perfect buffering10:17
kanavinsome of python3 tests take 2 and half minutes to complete, too close to comfort imo10:18
RPkanavin: I think it should be fine, most tests have some output if they sit for that long10:18
RPkanavin: hmm :/10:18
kanavinsince ross's output reduction patch10:18
*** rburton <rburton!> has joined #yocto10:18
sveinseIt 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 AFAICS10:19
kanavinRP: the timeout is easy to adjust via command line from though, if needed10:19
sveinse(copy paste type in the former, no ".vmdk" in it)10:20
RPkanavin: what worries me is some kind of breakage which then has each ptest hang for 15 mins :/10:20
RPkanavin: a 5 minute timeout is bad enough to lock builds up10:20
*** comptroller <comptroller!> has joined #yocto10:20
kanavinRP: 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 seconds10:21
RPkanavin: agreed, that would be better10:21
*** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC10:28
*** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto10:33
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has quit IRC10:42
*** yacar_ <yacar_!~yacar@> has joined #yocto10:55
*** comptroller <comptroller!> has quit IRC10:58
*** demonimin <demonimin!~demonimin@unaffiliated/demonimin> has quit IRC11:00
*** comptroller <comptroller!> has joined #yocto11:16
RPkanavin: I think you may be right, I think it is timing out on the AB as you say11:16
RPkanavin: its also not getting pass/fail processing correctly11:16
*** thaytan <thaytan!> has quit IRC11:20
RPrburton: any idea why run-ptest for python3 wouldn't parse any of the results? :/11:29
* RP is wondering about escaping11:29
RPah, busybox sed verses non-busybox?11:30
RPkanavin: any idea how difficult a per recipe timeout would be? :/11:31
*** armpit <armpit!~armpit@> has quit IRC11:37
yoctiNew news from stackoverflow: How to run a shell script while compiling a recipe in Yocto <>11:39
RPzeddii: 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
zeddiiright. 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
zeddiiI can do those -tiny build tests today as well, if we want to at least give it a go.11:44
RPzeddii: we build and boot it iirc11:44
zeddiiI can do that much.11:44
RPzeddii: not much other than that and I would kind of prefer to get to two kernels to test/release rather than three11:44
* zeddii denied another trip this week, so I’m around.11:44
zeddiileave 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
RPzeddii: I'm also trying to get ptest beaten into some sort of shape for release11:45
RPzeddii: thanks11:45
zeddiino replies on -netdev to your query that I saw.11:45
* RP is going to mistype unbuffered in a commit message soon...11:46
RPzeddii: no :(11:46
RPzeddii: did I ask the right things and have the right info? I don't now the networking people really...11:46
*** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC11:48
*** thaytan <thaytan!> has joined #yocto11:51
zeddiithe 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
RPzeddii: thanks :)11:52
*** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto11:55
*** klemen <klemen!~textual@> has joined #yocto12:04
RPrburton: I think is bust for python312:07
*** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC12:11
RPspecifically the sed filtering or the lack of -v addition of -W for py312:12
*** berton <berton!~berton@> has quit IRC12:17
*** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto12:17
*** berton <berton!~berton@> has joined #yocto12:18
*** berton <berton!~berton@> has quit IRC12:21
*** berton <berton!~berton@> has joined #yocto12:26
*** berton <berton!~berton@> has quit IRC12:29
*** cvasilak <cvasilak!~cvasilak@2a02:587:8117:600:2482:3aec:ef75:9af7> has quit IRC12:33
*** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC12:38
*** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto12:44
*** vladzouth <vladzouth!500c5411@gateway/web/freenode/ip.> has quit IRC12:44
rburtonRP: what happens?12:46
rburtoni wonder if the -W means it splits to stderr/stdout and the sed messed up the order12:47
rburtonmaybe we should 2>&1 before the sed?12:47
rburton*or* try again to write a results subclass that writes messages we're after12:47
rburtonwas wondering if we should unify on something more common like TAP output12:47
*** LocutusOfBorg <LocutusOfBorg!LocutusOfB@ubuntu/member/locutusofborg> has quit IRC13:00
yannI'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 there13:00
*** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC13:01
yannmy understanding problem is probably linked to not seeing where the autotools_do_install call itself comes from13:01
rburtonyann: do_install_append_arm6413:02
rburtonorder matters13:02
rburtonkanavin: did you touch openssl ptest?13:02
rburtonWARNING: core-image-minimal-1.0-r0 do_image_qa: /usr/lib/openssl/ptest/util/ is a broken link13:02
yannrburton: d'oh, thx - looks like I can't again wrap my head around this order13:06
rburtonappend and remove go before other overrides13:07
*** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto13:07
yannI keep imagining func_append_foo overloads func_append, like VAR_foo overloads VAR13:10
yannshadows, rather13:10
*** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC13:12
kanavinrburton, I didnt13:12
kanavinnot lately at least13:12
kanavinRP, Im thinking about it, first thing is where would we actually specify a custom timeout that ptest-runner can read13:13
kanavinprobably a ptest-timeout file next to ptest-run, with a single number in it13:13
kanavinthen it shouldnt be very hard to read that from C and re-assign the timeout variable, jsut before running the test13:14
*** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto13:16
*** la_croix <la_croix!> has quit IRC13:17
*** la_croix <la_croix!> has joined #yocto13:18
*** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC13:30
*** jij <jij!jonashg@nat/axis/x-rkcqywhmqqmnddqp> has quit IRC13:35
*** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto13:37
*** jeanba <jeanba!~jbl@> has joined #yocto13:49
*** jij <jij!jonashg@nat/axis/x-kxmdwqowkmrfhsbc> has joined #yocto13:51
*** jeanba <jeanba!~jbl@> has left #yocto13:54
*** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC13:56
*** stephano <stephano!~stephano@> has joined #yocto13:59
*** kanavin_ <kanavin_!~kanavin@> has joined #yocto14:01
*** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto14:01
*** kanavin_ <kanavin_!~kanavin@> has quit IRC14:01
*** prabhakarlad <prabhakarlad!~prabhakar@> has joined #yocto14:02
*** Striking7 <Striking7!> has quit IRC14:04
*** Striking7 <Striking7!> has joined #yocto14:05
*** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC14:06
*** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto14:10
*** Bunio_FH <Bunio_FH!> has quit IRC14:15
*** voyo <voyo!> has joined #yocto14:21
*** demonimin <demonimin!~demonimin@unaffiliated/demonimin> has joined #yocto14:21
rburtonRP: 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 patch14:21
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC14:24
OutBackDingorburton: is there a hardware list for new gear ?14:27
rburtonliterally no idea what you mean14:28
OutBackDingorburton: meaning ffor vendors with yocto capable hardware14:28
LetoThe2ndOutBackDingo: like a list to advertise your products, or what?14:28
OutBackDingoLetoThe2nd: right14:29
OutBackDingoor at least get word out14:29
LetoThe2ndOutBackDingo: 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. :-P14:30
LetoThe2ndOutBackDingo: until that happens, only thing is to become yocto project compliant as far as i know14:31
OutBackDingowell we have thud running on some new pi clone SOM boards14:31
rburtonhaving the layer being yp compliant means it goes on a list on the web site14:31
LetoThe2ndOutBackDingo: everybody has something running on something.14:31
LetoThe2ndsee :)14:31
OutBackDingoi know... mama alwats told me i was nothing special :)14:32
*** demonimin <demonimin!~demonimin@unaffiliated/demonimin> has quit IRC14:32
LetoThe2ndits the other way round. we are all special!14:32
LetoThe2ndno, seriously. do the compliancy dance, its the best value for money you can probably get.14:33
*** demonimin <demonimin!~demonimin@unaffiliated/demonimin> has joined #yocto14:33
*** Pharaoh_Atem <Pharaoh_Atem!~neal@fedora/ngompa> has joined #yocto14:33
*** demonimin <demonimin!~demonimin@unaffiliated/demonimin> has quit IRC14:39
*** armpit <armpit!~armpit@> has joined #yocto14:42
*** fbre <fbre!91fdde45@gateway/web/freenode/ip.> has joined #yocto14:55
fbreHi, 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
LetoThe2ndfbre: 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
LetoThe2ndjust like generating an spl for some boards15:01
fbreLetoThe2nd: What does the abbreviation "spl" mean?15:03
*** blueness <blueness!~blueness@gentoo/developer/blueness> has quit IRC15:07
varjagsecondary program loader15:07
*** otavio <otavio!~otavio@debian/developer/otavio> has quit IRC15:08
*** blueness <blueness!~blueness@gentoo/developer/blueness> has joined #yocto15:08
*** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC15:08
fbreah OK15:08
*** armpit <armpit!~armpit@> has quit IRC15:09
fbreI thought secondary poot loader :)15:09
*** acrap <acrap!> has quit IRC15:10
*** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto15:13
*** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC15:17
zeddiiRP: 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!> has joined #yocto15:19
*** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto15:24
sveinseI'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_!> has joined #yocto15:27
sveinseDrop using runqemu and make my own where I control the qemu options?15:27
*** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC15:29
sveinseDoes Yocto have any generic x64 intel MACHINE, or is qemux64 precisely that?15:30
*** fbre <fbre!91fdde45@gateway/web/freenode/ip.> has quit IRC15:30
kergothgenericx86, perhaps?15:31
kergoththough that might not be x64, thinking about it15:31
* kergoth needs more coffee15:31
rburtonsveinse: genericx86-64 is that, but the meta-intel intel-corei7-64 is better15:33
rburtonespecially if you're actually targetting intel15:33
sveinserburton: yeah, I'm going to run the image in a containerized/VM environment, so something modern is best :)15:34
rburtonmeta-intel is what you want then15:34
*** frsc <frsc!~frsc@2003:a:e7a:6200:246c:2a8b:f45a:a33d> has quit IRC15:35
sveinserburton: thanks, I'll try that. Hopefully I have better luck with other hypervisors then15:35
zeddiiwell, technically linux-yocto is ahead of meta-intel ;)15:35
rburtonpah ;)15:36
rburtonsveinse: qemu* assumes its running in qemu15:36
sveinserburton: yup, figured as much. Actually it works fine in VirtualBox. But not in Hyper-V, due to not having IDE storage in kernel15:37
*** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto15:37
rburtonyeah its pretty tuned for what qemu offers for HW15:37
*** Simgate <Simgate!540e05c8@gateway/web/freenode/ip.> has joined #yocto15:37
sveinseAlthou not quite straight forward in all combinations of IMAGE_FSTYPES in qemu either, as it varies in how it configures the storage device apparently15:38
*** Simgate <Simgate!540e05c8@gateway/web/freenode/ip.> has quit IRC15:38
*** learningc <learningc!~learningc@> has joined #yocto15:42
*** LocutusOfBorg <LocutusOfBorg!LocutusOfB@ubuntu/member/locutusofborg> has joined #yocto15:53
voyoRP: thanks for tip,  I put MULTILIBS="" in local.conf and it make it15:53
*** LocutusOfBorg <LocutusOfBorg!LocutusOfB@ubuntu/member/locutusofborg> has joined #yocto15:55
voyohowever 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@> has quit IRC15:57
*** rcw <rcw!~rcw@> has joined #yocto15:58
voyolooks 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.5408816:02
voyoanyone have idea what it is about ?16:02
sveinsevoyo: what is process 54088 ?16:05
voyosveinse: no such process16:06
voyo(anymore , I suppose)16:06
*** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC16:08
*** fl0v0 <fl0v0!~fvo@> has quit IRC16:09
yoctiNew news from stackoverflow: Odroid XU4 with Yocto and GUI (gtk+3 error wayland-egl not found) <>16:10
*** lusus <lusus!~lusus@> has quit IRC16:11
*** yann <yann!~yann@> has quit IRC16:13
*** jmiehe <jmiehe!> has quit IRC16:18
*** varjag <varjag!> has quit IRC16:21
*** yacar_ <yacar_!~yacar@> has quit IRC16:25
*** mckoan is now known as mckoan|away16:27
sveinseWhen using MACHINE=intel-corei7-64 my image does not parse. It throws a "ERROR: Task do_bootimg in */ depends on non-existent task do_image_ext4 in */", 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
sveinseThat is, I'm not using neither do_bootimg or do_image_ext4 in my image recipe16:36
rburtondoes your image set an image type?16:37
sveinserburton: 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 target16:40
sveinse*meta-intel :D16:40
*** sjolley_ <sjolley_!> has quit IRC16:42
*** stephano <stephano!~stephano@> has quit IRC16:56
RPrburton: right now python3 shows no test success, no fail and no skipped16:57
RPrburton: i.e. zero counts everywhere16:57
zeddiiRP: do you recall if qemuarm (qemuarma15) for 5.0 booted in nographic mode ?17:08
zeddiiI’m testing tiny and seeing a hang. i just started a poky build, but it’ll take a while17:08
*** moto-timo <moto-timo!ttorling@fsf/member/moto-timo> has joined #yocto17:14
*** tprrt <tprrt!~tprrt@> has quit IRC17:32
*** justinsg <justinsg!sid296040@gateway/web/> has quit IRC18:20
*** dagmcr <dagmcr!sid323878@gateway/web/> has quit IRC18:20
*** tardyp <tardyp!sid45259@gateway/web/> has quit IRC18:20
*** sjolley_ <sjolley_!~sjolley_@2600:100f:b118:9190:90a5:c83c:756a:294b> has joined #yocto18:20
*** ndec <ndec!sid219321@linaro/ndec> has quit IRC18:20
*** Tartarus <Tartarus!sid72705@gateway/web/> has quit IRC18:20
*** justinsg <justinsg!sid296040@gateway/web/> has joined #yocto18:20
*** hugo___ <hugo___!sid6079@gateway/web/> has quit IRC18:20
*** paulbarker <paulbarker!sid269702@gateway/web/> has quit IRC18:20
*** ndec <ndec!sid219321@linaro/ndec> has joined #yocto18:20
*** mirzak <mirzak!sid303002@gateway/web/> has quit IRC18:20
*** paulbarker <paulbarker!sid269702@gateway/web/> has joined #yocto18:20
*** dagmcr <dagmcr!sid323878@gateway/web/> has joined #yocto18:20
*** hugo___ <hugo___!sid6079@gateway/web/> has joined #yocto18:21
*** tardyp <tardyp!sid45259@gateway/web/> has joined #yocto18:21
*** Tartarus <Tartarus!sid72705@gateway/web/> has joined #yocto18:21
*** sjolley_ <sjolley_!~sjolley_@2600:100f:b118:9190:90a5:c83c:756a:294b> has quit IRC18:24
*** sjolley_ <sjolley_!~sjolley_@2600:100f:b118:9190:90a5:c83c:756a:294b> has joined #yocto18:37
sveinseHas 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
*** sjolley_ <sjolley_!~sjolley_@2600:100f:b118:9190:90a5:c83c:756a:294b> has quit IRC18:41
*** T_UNIX <T_UNIX!uid218288@gateway/web/> has quit IRC18:42
sveinseCrofton: cool, thanks18:42
*** kaspter <kaspter!~Instantbi@> has quit IRC18:44
*** kaspter <kaspter!~Instantbi@> has joined #yocto18:45
rburtonsveinse: there's a container image type that rips out kernels and stuff as a generic starter18:48
rburtonsveinse: integration per-service is more specific, patches welcome.  also try meta-virtualisation?18:49
Croftonbottom, OpenEmbedded, it isn't just for embedded anymore :)18:50
sveinserburton: 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
sveinseAt 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 promising18:53
CroftonYes, people already do this18:54
sveinseI'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 :D18:54
sveinseNot sure yet clear if I need a VM or a container, so I'm testing both approaches18:55
sveinseNot 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
sveinseSo everything everywhere is cloud and containers these days18:59
*** ebolton <ebolton!~ebolton@> has joined #yocto19:07
eboltonis 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 value19:09
*** JaMa <JaMa!> has quit IRC19:17
sveinseI'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@> has quit IRC19:28
voyoguys, 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
RPzeddii: I don't think I've tested that, only in graphic mode19:40
RPzeddii: FWIW these are the tiny tests we run, I think its only qemux86:
*** tgraydon <tgraydon!~textual@> has joined #yocto19:45
rburtonsveinse: grub-efi is the bootloader19:46
rburtonor, systemd-boot19: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
RPzeddii: sounds good! I'd like to sort qemuarm for tiny and can add testing for that but that can be 2.819:49
RPzeddii: is non-tiny nographic also having issues?19:49
zeddiinope. it worked.19:49
sveinserburton: interestingly, manifest lists neither (-- this is on rocko)19:50
zeddiipoky -> qemuarm -> 5.0 -> nographic was fine.19:50
RPzeddii: I wonder if its related to that edid stuff19:50
zeddiieither 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
RPzeddii: thanks. Things are starting to come together for 2.7 rc1 :)19:51
RPapart from the string of AB build failures :/19:51
sveinseI'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" target19:51
rburtonsveinse: 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 image19:52
sveinserburton: ah, right, makes kinda sense. Thanks.19:52
RPrburton: is there a downside if I swap py3 back to -v instead of -W for run-ptest?19:53
*** yann <yann!> has joined #yocto19:56
sveinseIn 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
voyosveinse:  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 IRC20:02
sveinsevoyo: thanks20:03
*** rcw <rcw!~rcw@> has quit IRC20:03
voyonp. however I havwe no idea how it is implemented within OE, and how to provide certs to check signature of your binary.20:06
sveinsevoyo: 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
voyovery simple booting option only then...20:08
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto20:08
sveinsevoyo: yet, browsning through meta-intel, it doesn't seem to support non-gpt and uefi without manual tweaking20:09
sveinseUnderstandable. Gpt and uefi has been with us for a while. Only ancient hardware doesn't support it20:10
sveinseSo its Azure Cloud which is the surprise here20:11
*** otavio <otavio!~otavio@debian/developer/otavio> has joined #yocto20:11
voyowell. 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
voyoby assumption you are working under very limited and controlled environment, so why to worry for uefi and makes life even more miserable ;)20:17
sveinsevoyo: Well, I don't really want it. At least not for the VM part. But it seems integrated into the image20:18
*** la_croix <la_croix!> has quit IRC20:19
RPseebs: around?20:19
voyoyou 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
RPseebs: I have some data on our mysterious owner corruption...20:20
RPseebs: I don't understand it though!20:20
sveinsevoyo: correct. I pull in meta-intel, set MACHINE="intel-corei7-64" and then I get uefi when I build wic based image20:24
voyosveinse: what if you choose other MACHINE , maybe something like generic_x64 make a difference ?20:25
voyobtw, 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
sveinsevoyo: hmm on rocko it sais: "MACHINE=generic_x64 is invalid."20:28
seebsRP: semi-around, what's up?20:29
rburtonsveinse: can't you just throw a ext4 at the cloud provider thingy?20:29
RPseebs: otavio has a reproducer for our weird pseudo owner corruption and some logs20:30
RPseebs: I was hoping you could glance at them and see if its anything obvious to you20:30
RPseebs: A cutdown version:
RPseebs: basically that file should be owned by 0 but becomes owned by 100020:31
RPseebs: the "symlink mismatch" being the thing which seems to be a smoking gun20:31
voyosveinse:  genericx86-6420:31
sveinserburton: no, not when running a full VM. Even the wic is a intermediate format, as it must be converted to the appropriate hypervisor format20:32
RPseebs: I can give a link to the full logs and bitbake output but I think that is perhaps the most obvious filtered version20:32
RPseebs: 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!> has joined #yocto20:33
RPseebs: even then the later 1000 owner which suddenly appears makes no sense20:35
seebsthis is interesting.20:36
sveinseWhat is the difference from using genericx86-64 vs intel-corei7-64? Is is only cpu options and uefi/gpt booting?20:36
seebsthere'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
RPseebs: This was a filtered log, not sure if that got stripped out20:37
*** sjolley_ <sjolley_!~sjolley_@> has joined #yocto20:38
voyosveinse:  did you saw this? -
sveinsevoyo: yeah sure. Can't build a bootable image without wic.20:50
seebsit shouldn't have, i think, since the path should have matched. i think.20:54
seebsand the unfiltered log seems not to have them either, which is weird.20:54
seebsoh, i see. those lines are under PDBGF_DB, but only PDBGF_FILE is in use.20:54
seebsand they probably shouldn't be restricted like that, but i'm honestly not sure.20:55
rburtonsveinse: .wic is just a disk image format, its not a special format.  vmdk etc is just optimised for vm use.21:05
rburtonsveinse: compiler tune and kernel (generic vs intel)21:05
sveinserburton: yes, thanks. I know what wic is21:06
sveinserburton: is it correct that uefi and gpt cannot be turned off with an option in meta-intel?21:06
rburtonits the wic image that is controling that iirc21:09
rburtonwhich is controllable just set WKS_FILE21:10
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto21:20
*** WillMiles <WillMiles!> has quit IRC21:21
*** stephano <stephano!stephano@nat/intel/x-hlucxjwwcbkiqzwg> has joined #yocto21:26
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC21: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 scratch21:39
*** armpit <armpit!~armpit@> has joined #yocto21:50
*** sjolley_ <sjolley_!~sjolley_@> has quit IRC22:03
*** agust <agust!> has quit IRC22:16
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto22:21
*** armpit <armpit!~armpit@> has quit IRC23:06
yoctiNew news from stackoverflow: Why is my kernel configuration option not set in resulting defconfig after running bitbake -c savedefconfig virtual/kernel? <>23:11
*** justanotherboy <justanotherboy!~justanoth@> has joined #yocto23:12
*** khem <khem!~khem@unaffiliated/khem> has quit IRC23:13
*** khem <khem!~khem@unaffiliated/khem> has joined #yocto23:14
*** rburton <rburton!> has quit IRC23:32

Generated by 2.11.0 by Marius Gedminas - find it at!