Friday, 2017-07-21

*** garbados <garbados!~garbados@2601:1c2:303:6b0:cd4c:c80:d4b5:e0a4> has quit IRC00:04
*** dv_ <dv_!~quassel@> has quit IRC00:14
*** dv_ <dv_!> has joined #yocto00:14
*** yann <yann!> has quit IRC00:18
*** nighty- <nighty-!> has quit IRC00:21
*** garbados <garbados!~garbados@2601:1c2:303:6b0:cd4c:c80:d4b5:e0a4> has joined #yocto00:22
*** garbados <garbados!~garbados@2601:1c2:303:6b0:cd4c:c80:d4b5:e0a4> has quit IRC00:30
*** scottrif <scottrif!~scottrif@> has left #yocto00:40
*** dvhart <dvhart!> has quit IRC00:50
*** dvhart <dvhart!> has joined #yocto00:50
*** nighty- <nighty-!> has joined #yocto00:54
*** dvhart <dvhart!> has quit IRC01:00
*** fitzsim <fitzsim!> has joined #yocto01:09
*** garbados <garbados!> has joined #yocto01:27
*** flihp <flihp!~flihp@> has joined #yocto01:36
*** rick_0 <rick_0!~Thunderbi@2001:8003:804a:b500:883e:bb28:3681:5772> has joined #yocto02:01
*** bully4u <bully4u!~Adium@> has quit IRC02:01
*** Guma <Guma!> has quit IRC02:25
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has joined #yocto02:50
*** rick_0 <rick_0!~Thunderbi@2001:8003:804a:b500:883e:bb28:3681:5772> has quit IRC03:07
*** rick_0 <rick_0!~Thunderbi@2001:8003:804a:b500:28d8:c070:9b4c:24d8> has joined #yocto03:13
*** sjolley <sjolley!sjolley@nat/intel/x-kuosbhssudotzzan> has quit IRC03:20
*** georgem_home <georgem_home!uid210681@gateway/web/> has quit IRC03:24
*** sjolley <sjolley!~sjolley@> has joined #yocto03:29
*** dreyna <dreyna!> has quit IRC03:43
*** jmcruzal <jmcruzal!~jmcruzal@> has quit IRC04:01
*** pohly <pohly!> has joined #yocto04:22
*** agust <agust!> has joined #yocto04:37
*** teroshan <teroshan!> has quit IRC05:20
*** bluelightning <bluelightning!> has joined #yocto05:31
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto05:31
*** LocutusOfBorg <LocutusOfBorg!~Gianfranc@ubuntu/member/locutusofborg> has quit IRC06:08
*** LocutusOfBorg <LocutusOfBorg!~Gianfranc@> has joined #yocto06:15
*** LocutusOfBorg <LocutusOfBorg!~Gianfranc@ubuntu/member/locutusofborg> has joined #yocto06:15
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has joined #yocto06:23
*** caiortp <caiortp!~caiortp@> has quit IRC06:31
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC06:33
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto06:34
*** eduardas_m <eduardas_m!~eduardas@> has joined #yocto06:35
*** Bunio_FH <Bunio_FH!> has joined #yocto06:41
pohlyRP: do runqemu and oe-selftest support multiconfig? What I mean is, can they be told to boot images or run tests in some other config than the default one?06:44
pohlySame for "bitbake -e".06:44
*** zero_note <zero_note!~zero@> has joined #yocto06:45
*** LocutusOfBorg <LocutusOfBorg!~Gianfranc@ubuntu/member/locutusofborg> has quit IRC06:54
*** T_UNIX <T_UNIX!uid218288@gateway/web/> has joined #yocto06:55
*** ojdo <ojdo!~ojdo@unaffiliated/ojdo> has quit IRC06:56
*** hamis <hamis!~irfan@> has joined #yocto06:59
*** garbados <garbados!> has quit IRC07:00
*** ant_work <ant_work!> has joined #yocto07:01
*** ojdo <ojdo!~ojdo@unaffiliated/ojdo> has joined #yocto07:03
*** ed2 <ed2!Adium@nat/intel/x-ztzlfnlyqtawgdub> has joined #yocto07:10
pohlyRP: is changing DISTRO_FEATURES allowed in a multiconfig? Apparently not (at least not out-of-the-box), because recipes of different multiconfigs end up sharing the same WORKDIR.07:11
*** rajm <rajm!~robertmar@> has joined #yocto07:11
*** Bunio_FH <Bunio_FH!> has quit IRC07:11
*** Bunio_FH <Bunio_FH!> has joined #yocto07:12
pohlySwitching between machines avoids that because only machine-specific recipes vary between builds, and they already have different paths.07:12
*** jku <jku!> has joined #yocto07:12
*** csanchezdll <csanchezdll!> has joined #yocto07:17
*** mckoan|away is now known as mckoan07:21
*** Kakounet <Kakounet!> has joined #yocto07:23
pohlyRP: does it really make sense that -native tools are built in "x86_64-linux" where "linux" is from "TARGET_OS"? Are these tools really specific to the target OS?07:23
RPpohly: Isn't that from BUILD_OS?07:24
pohlyRP: hmm, not according to "bitbake -e intltools-native", unless I misread something. Let me double-check.07:24
*** diego__ <diego__!> has joined #yocto07:26
RPpohly: runqemu and oe-selftest have no knowledge of multiconfig. I'd have thought runqemu would be fine if you point it at the right deploy artefacts. oe-selftest would be hard for multiconfig07:26
pohlyI'm asking because in my multiconfig variants I could set TARGET_VENDOR or TARGET_OS differently than in the main config to avoid the path clash. TARGET_OS would be a bit more natural, but only if it isn't used for the native tools.07:26
RPpohly: You could just set a different TMPDIR?07:27
pohlyYes, but then native tools aren't shared either.07:27
*** Kakounet <Kakounet!> has quit IRC07:27
pohly# pre-expansion value:07:27
RPpohly: hmm. If they are prepopulated in sstate you'd likely be fine but yes, in a from scratch scenario they would get duplicated07:28
pohlyThat's for intltools-native.07:28
pohlySo no, it's not using BUILD_OS.07:28
RPpohly: It is since native.bbclass sets TARGET_OS = BUILD_OS07:29
RPpohly: I think TARGET_VENDOR may be the correct thing here btw07:30
RPpohly: since vendor is a custom field where as os is keyed off by various things07:30
RPand yes, TARGET_VENDOR and BUILD_VENDOR are different things07:30
*** pohly1 <pohly1!> has joined #yocto07:33
*** pohly <pohly!> has quit IRC07:33
*** Bunio_FH <Bunio_FH!> has quit IRC07:34
*** Bunio_FH <Bunio_FH!> has joined #yocto07:34
*** richardD <richardD!> has joined #yocto07:38
*** mdnneo <mdnneo!~umaucher@> has joined #yocto07:38
*** LocutusOfBorg <LocutusOfBorg!~Gianfranc@ubuntu/member/locutusofborg> has joined #yocto07:39
*** t0mmy <t0mmy!~tprrt@> has joined #yocto07:41
*** gizero_ <gizero_!> has quit IRC07:44
*** pohly <pohly!> has joined #yocto07:46
*** joshuagl <joshuagl!~joshuagl@> has joined #yocto07:48
*** pohly1 <pohly1!> has quit IRC07:48
pohlyRP: changing "TARGET_OS" away from  "linux" doesn't work, I end up with "Unable to determine bit size for architecture 'x86_64' - Please add your architecture to siteinfo.bbclass" errors.07:50
pohlyIt's a bit confusing that the message only mentions HOST_ARCH and not HOST_OS. I suspect it is HOST_OS which changes to something that isn't known.07:53
*** richardD <richardD!> has quit IRC07:55
*** Radela <Radela!> has quit IRC07:56
pohlyYes, HOST_OS = linux-x11 = TARGET_OS in my conf/multiconfig/x11.conf.07:57
RPpohly: right, siteinfo reads HOST_OS which is set from TARGET_OS in many cases07:57
RPpohly: as I said, changing TARGET_OS is a bad idea07:57
RPpohly: you want TARGET_VENDOR07:57
pohlyDid you say that? ;-} Sorry, I did not quite get the message. But I see now why it is a bad idea.07:58
RPpohly: I perhaps didn't put it quite strongly enough :)07:58
pohlyNothing beats first hand experience - seeing the errors is much better than someone saying "don't do that" ;-}07:59
RPpohly: indeed :)07:59
pohlyChanging TARGET_VENDOR helped a bit, but I'm still getting file conflicts elsewere, for example for tmp-glibc/deploy/ipk/corei7-64/wpa-supplicant-cli_2.6-r0_corei7-64.ipk.08:01
pohlyI'll keep trying...08:01
*** rick_0 <rick_0!~Thunderbi@2001:8003:804a:b500:28d8:c070:9b4c:24d8> has quit IRC08:01
RPpohly: right, you might need a DEPLOY_DIR tweak too08:02
RPpohly: you're trying something I don't think anyone has tried before08:02
*** florian <florian!~fuchs@Maemo/community/contributor/florian> has joined #yocto08:02
pohlyRP: you know me - boldly going where no (sane) man has gone before ;-}08:02
RPpohly: you're also assuming DISTRO_FEATURES don't leak into native recipes08:03
pohlyI do.08:03
*** Radela <Radela!> has joined #yocto08:03
*** Bunio_FH <Bunio_FH!> has quit IRC08:03
RPpohly: whilst most distro features shouldn't and the contains() mechanism should prevent leakage of non relevant values, I do wonder if we can assume that08:03
*** Bunio_FH <Bunio_FH!> has joined #yocto08:03
RPpohly: as a headsup for refkit, we just merged the bitbake server rework changes. These are significant changes.08:05
*** Kakounet <Kakounet!> has joined #yocto08:06
pohlyThey don't leak for x11 and wayland, which is what I am trying to build in parallel here. Or perhaps more precisely, x11 is always enabled (due to DISTRO_FEATURES_NATIVE) and wayland gets filtered out.08:09
pohlyThinking about this some more, I wonder whether I can actually achieve my goal. My hope was that by using multiconfig, I can get a more efficient build compared to invoking bitbake three times in the same build directory with different distro features.08:11
pohlyBut the "more efficient" part is a bit questionable.08:11
RPpohly: Its an interesting experiment, I'm cheering you on08:13
pohlyFor example, if there is a target recipe "" which doesn't depend on either x11 or wayland, and it needs to be rebuilt for some reason. When invoking bitbake three times, it will get built the first time and then be left unchanged.08:13
pohlyWhen all three variants are active in a build (foo, multiconfig:x11:foo, multiconfig:wayland:foo), then I fear that they will all get built in parallel, producing the exact same sstate. That's less efficient.08:15
pohlyRP: is my expectation right? I haven't actually tried it.08:15
RPpohly: until fairly recently changing DISTRO_FEATURES on an existing tmpdir was dangerous and not supported ;-)08:15
RPpohly: your suspicion is correct unfortunately08:16
RPpohly: there is an open bug to optimise that but we're no where near ready for that yet08:16
pohlyBug number?08:16
yoctiBug 10682: enhancement, Medium, Future, richard.purdie, NEW , multiconfig sstate optimisations08:17
*** Bunio_FH <Bunio_FH!> has quit IRC08:17
*** Bunio_FH <Bunio_FH!> has joined #yocto08:18
RPpohly: there is overlap between solving that and distributed builds08:18
joshuaglRP: FYI I enabled sstate for oe-selftest on the prod (yp.o) cluster last night, a master build has several failures in oe-selftest08:19
*** Kakounet <Kakounet!> has quit IRC08:20
pohlyI can probably avoid this particular inefficiency by building each target separately. But then the question becomes whether it is still more efficient than the traditional approach.08:20
*** luc4 <luc4!> has joined #yocto08:21
RPjoshuagl: one failure in wic?08:21
joshuagllooks like it's just one test that fails, wic.Wic.test_fs_types - Testcase 1849: FAILED08:22
RPjoshuagl: that doesn't look sstate related to me08:22
RPed2: ^^^08:22
joshuaglRP: neat, was slowly reaching the same conclusion. Thanks for looking08:22
RPtransaction.h:42: btrfs_start_transaction: BUG_ON `fs_info->running_transaction` triggered, value 1552096008:23
ed2joshuagl: RP: I'll have a look.08:23
RPed2: looks like it may be a btrfs tools bug08:23
joshuaglRP: sstate also enabled for new ( cluster now08:25
joshuaglthanks ed208:25
RPjoshuagl: thanks08:27
pohlyRP: about this "changing DISTRO_FEATURES in existing tmp not supported" - was that documented or just part of the "if you run into problems, remove tmp and try again" fallback? I wasn't aware of this limitation.08:29
pohlyWhat removed it?08:29
RPpohly: We added code which makes it work in the majority of cases now08:30
RPpohly: too many users got confused and saw breakage with it not working08:31
*** JaMa <JaMa!~martin@> has joined #yocto08:31
RPpohly: rss should have been the final piece of that puzzle08:31
*** MarcWe <MarcWe!> has joined #yocto08:32
joshuaglRP: rburton: going to make some quick changes to the AB's this morning, please give me a few08:33
pohlyRP: when I do "bitbake multiconfig:x11:refkit-image-common", I end up with three messages about "Build completion summary", with identical content.08:36
pohlyIs that a report about the entire build config?08:36
pohlyI inherit buildstats-summary.bbclass.08:37
*** toscalix_ <toscalix_!~toscalix@> has joined #yocto08:37
pohlyI suspect it's related to your recent event trigger changes.08:37
ed2RP: regarding patchelf & gold issue(#11785). Does this patch looks ok to you?
RPpohly: We intentionally fire BuildCompleted events for each multiconfig08:37
RPpohly: if we don't there are much worse things happen08:38
RPpohly: I'm fine with adding a "MulticonfigBuildCompleted" event too08:38
ed2RP: here is a diff of readelf output after and before the patch:
*** mihai <mihai!~mihai@unaffiliated/mihai> has joined #yocto08:38
RPed2: at a quick glance, yes08:39
RPed2: does that actually change behaviour at all though?08:40
pohlyRP: I think such a MulticonfigBuildCompleted event is needed for buildstats-summary.bbclass.08:40
RPed2: same link?08:40
pohlyDo you want a bugzilla entry for it?08:40
ed2RP: yes, it does.08:40
ed2RP: oops, sorry. this is the right one:
RPpohly: hmm. I can probably write the patch just as fast08:41
pohlyOkay ;-}08:41
ed2RP: without this patchelf produces broken executable. ldd reports (not a dynamic executable) and ld-linux segfaults when loading it.08:42
*** YoctoAutoBuilder <YoctoAutoBuilder!> has quit IRC08:44
ed2RP: you can see much more info in the bug #1178508:44
yoctiBug major, Medium+, 2.4 M3, eduard.bartosh, IN PROGRESS IMPLEMENTATION , On Debian 9 m4 segfaults making impossible to build autoconf-native due to the uninative feature08:44
*** YoctoAutoBuilder <YoctoAutoBuilder!> has joined #yocto08:45
*** YoctoAutoBuilder <YoctoAutoBuilder!> has quit IRC08:47
RPed2: are you sure the patch above is the one you're testing?08:48
*** Bunio_FH <Bunio_FH!> has quit IRC08:48
RPed2: It doesn't seem to match the one in the bug but its hard to tell with diffs of diffs08:48
*** Bunio_FH <Bunio_FH!> has joined #yocto08:48
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has quit IRC08:48
*** toscalix_ is now known as toscalix08:48
*** YoctoAutoBuilder <YoctoAutoBuilder!> has joined #yocto08:49
ed2RP: it's mostly the same. The idea is to put startPage = startOffset; inside the 'startOffset > startPage' condition. It was outside, causing startPage to be changed for all executables.08:50
joshuaglRP: rburton: done on the AB's, feel free to schedule builds08:51
RPed2: of course, I see now08:51
RPed2: I think that does make sense08:52
RPjoshuagl: thanks!08:52
ed2RP: great. I'll send it for review then.08:52
ed2RP: thank you08:52
RPed2: might be worth adding this patch to the github site, they did take my last patch too!08:52
RPed2: well spotted finding that :)08:53
ed2RP: yep, will send it upstream too.08:53
ed2RP: thanks. this kind of things are easily overlooked. Took me some time to find it out :)08:54
ed2joshuagl: is wic test failure still relevant. My build is still going, so I didn't check it out yet.08:55
ed2joshuagl: ?08:55
joshuagled2: still relevant, yes08:56
RPed2: reproducing it may be hard :(09:01
*** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has quit IRC09:03
ed2RP: true. we're lucky it's 100% reproducible on our m4 executable linked with gold09:04
*** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has joined #yocto09:06
*** ChrysD <ChrysD!d9804861@gateway/web/freenode/ip.> has quit IRC09:06
*** ChrysD <ChrysD!d9804861@gateway/web/freenode/ip.> has joined #yocto09:09
ed2RP: btw, did we try to test build performance for ld vs gold? according to what people say gold is much faster.09:12
pohlyRP: looks like changing TARGET_VENDOR is also a dead-end. It is passed to configure as --target=x86_64-refkit-x11-linux and thus changes sstate signatures even in recipes which do not depend on the distro feature.09:13
pohlyI'm coming to the conclusion that different TMPDIR is the only viable approach. It also gets rid of conflicts in the deploy package feeds.09:17
*** richard <richard!> has joined #yocto09:19
*** richard is now known as Guest2046609:20
pohlyRP: but then what about BUILDSTATS_BASE, as used by buildstats-summary.bbclass? Does that need to use a TMPDIR that is the same for all multiconfigs? Currently it doesn't.09:20
ed2joshuagl: RP: I can't reproduce wic.Wic.test_fs_types on my machine. Used the same poky commit & machine.09:23
*** seezer <seezer!quassel@quassel/developer/seezer> has quit IRC09:24
*** seezer <seezer!quassel@quassel/developer/seezer> has joined #yocto09:25
*** toscalix <toscalix!~toscalix@> has quit IRC09:26
*** toscalix <toscalix!~toscalix@> has joined #yocto09:27
*** Guest20466 is now known as vdehors_arc09:27
*** deva <deva!~deva@> has joined #yocto09:31
*** deva <deva!~deva@> has quit IRC09:31
RPed2: hmm, I had a feeling that one might be tricky/rare :/09:33
RPpohly: good question :/09:33
RPpohly: this is why I ended up with separate events09:34
*** luc4 <luc4!> has quit IRC09:34
pohlyRP: I think buildstats are per-build, and thus need to be independent of the TMPDIR used by each individual multiconfig.09:35
pohlybuildstats.bbclass hard-codes BUILDSTATS_BASE, so it cannot even be configured easily in a local.conf where BBMULTICONF is set. I'm now using BUILDSTATS_BASE_forcevariable = "${TOPDIR}/tmp/buildstats".09:37
RPpohly: that does sound like the correct implementation09:45
*** nighty- <nighty-!> has quit IRC09:46
pohlyRP: however, there's a namespacing issue: the directories in ${BUILDSTATS_BASE} do not include the BB_CURRENT_MC prefix, so different variants overwrite each other's files.09:58
pohlyBut I still think a single BUILDSTATS_BASE is the right solution. For example, the system monitor .log files only get written in the main build configuration.10:00
RPpohly: hmm, I'm torn on this to be honest...10:06
pohlyIf it is per multiconfig, then pybootchartgui becomes less useful because it only shows a subset of what really went on.10:08
pohlyI'm not familiar enough with buildstats-diff to determine which approach would be better.10:09
RPpohly: you can run pybootchartgui on a set of directories iirc10:10
pohlyRP: then we have the name clash in the UI.10:12
RPpohly: hmm, true10:13
RPpohly: I did write
pohlySpeaking of pybootchartgui, it's complaining here with "empty state: ... does not contain a valid bootchart" even for the single directory case.10:14
pohlyPerhaps it doesn't like short builds with only setscene tasks? Not sure.10:14
RPpohly: could be. sstate works better now than when it was originally written :)10:14
pohlyRP: about that patch: the terminology is getting confusing. The comment "Event fired once per multiconfig build completion" for MultiConfigBuildCompleted to me sounds more like "fired once for each of the multiconfigs", i.e. more than once per "bitbake" invocation.10:17
pohlyBut it's the other way around, BuildCompleted fires more than once and MultiConfigBuildCompleted exactly once.10:17
pohlyWe probably need a term for the building of a particular variant.10:18
pohlyThen we can define "multiconfig build" = "a build where BBMULTICONFIG is set, ends when all variants are built -> MultiConfigBuildCompleted".10:19
RP better ?10:20
pohlyYes, that's better.10:21
*** sgw_ <sgw_!~sgw_@> has quit IRC10:22
MarcWeHi, how can run bitbake to show echo's from do_install functions in bb files10:22
AxtonHi. I'm new to yocto and learning while I try to build a image for my CHIP Pro board. I have followed the guide from the Link, and I now have a login prompt from my CHIP pro. If I type root in the login prompt it gives "Login incorrect". I have looked at the rootfs tar file and can see a passwd file in the etc folder, but there is no shadow file? My question: is there some way of telling yocto NOT to include10:22
Axtona shadow file?10:22
pohlyHowever, """Event when builds have completed (one event per multiconfig)""" for BuildCompleted is not quite correct in the current implementation. An event handler that registers for BuildCompleted will be invoked twice in a normal build, once for bb.event.BuildCompleted and once for MultiConfigBuildCompleted.10:23
rburtonMarcWe: use bbwarn instead of echo10:23
MarcWea oke10:23
RPMarcWe: you should be able to see them in the WORKDIR/temp/log.do_install file10:23
RPpohly: hmm, I guess I need to split that base class :(10:24
pohlyRP: to avoid that, we probably need a "class BuildCompletedBase" with the current BuildCompleted code and two leaf classes.10:24
RPpohly: yes, how ugly :(10:24
RPpohly: well spotted though thanks10:27
*** nighty- <nighty-!> has joined #yocto10:29
*** sgw_ <sgw_!sgw_@nat/intel/x-kiieswnblwuysbfr> has joined #yocto10:37
*** Kakounet <Kakounet!> has joined #yocto10:41
*** Bunio_FH <Bunio_FH!> has quit IRC10:48
*** Bunio_FH <Bunio_FH!> has joined #yocto10:48
*** toscalix <toscalix!~toscalix@> has quit IRC10:57
ed2rburton: this patch seems to be forgotten:
ed2rburton: I don't see it in any of pre-branches (checked master-next, ross/mut, ross/mut2)11:03
ed2rburton: and unlucky /boot patchset too: (this fixes M2 Medium+ bug)11:07
rburtonthanks ed2, sorry about that11:07
ed2rburton: no prob, just wanted to point out11:08
rburtonRP: did you see ed2 sent a patchelf patch?11:08
RPrburton: we talked about it earlier, looks good to me11:09
RPed2: Isn't the status there submitted?11:10
*** Bunio_FH <Bunio_FH!> has quit IRC11:17
*** Marex <Marex!~Marex@> has quit IRC11:26
*** Marex <Marex!~Marex@> has joined #yocto11:28
*** Bunio_FH <Bunio_FH!> has joined #yocto11:32
*** luc4 <luc4!> has joined #yocto11:34
*** groleo <groleo!> has joined #yocto11:35
*** groleo <groleo!> has joined #yocto11:35
RPrburton: I tracked that mesa failure to the vulkan distro change. I've therefore added mut to -next minus that and will see how that build goes11:39
*** mappy <mappy!b9691ff9@gateway/web/freenode/ip.> has joined #yocto11:47
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has quit IRC11:59
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has joined #yocto12:01
ed2RP: sent v2. thanks for pointing it out.12:11
rburtonRP: +112:15
*** Christoph <Christoph!52716395@gateway/web/freenode/ip.> has joined #yocto12:19
rburtoned2: "runqemu: rework of exception handling" is already in master.  merged the rootfs changes to mut now.12:20
kanavinrburton: gstreamer is moving to meson too, so I'm not at all interested in sending them our pending patches, which are all fixing stuff in autotools. Fair enough? :)12:20
rburtonyeah :)12:20
rburtonkanavin: now you're back...12:20
rburtonwant to play "how to make meson build gtk-doc"12:21
rburtonmeson has built in support for "i need this command to run a target binary", so in theory if we set that and then tell meson to use that when it invokes stuff it builds, it should just work and all be upstreamable12:21
rburton(or g-i but i suspect gtkdoc is the easier case to start with)12:22
*** Bunio_FH <Bunio_FH!> has quit IRC12:22
*** Bunio_FH <Bunio_FH!> has joined #yocto12:22
kanavinrburton: I have never used meson before (but I bloody should)12:22
rburtonjust seeing if all my patches to the class/recipe in meta-oe have landed now12:22
rburtontheres a ross/meson in poky-contrib which has some relevant work in too12:23
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has quit IRC12:23
kanavinrburton: just reading the meson's developer post called "why autotools is not my favorite build system". He has a finnish name btw, Jussi Pakkanen.12:23
rburtonyeah, i'm pretty sure i've worked near him in the past.  then again about 80% of finnish engineers worked at nokia...12:24
kanavinrburton: the remaining 20% worked for nokia subcontractors12:24
rburtonhis linkedin doesn't have any nokia contractors in :O12:25
*** toscalix <toscalix!> has joined #yocto12:26
*** toscalix_ <toscalix_!~toscalix@> has joined #yocto12:28
*** Christoph <Christoph!52716395@gateway/web/freenode/ip.> has quit IRC12:29
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has joined #yocto12:30
*** toscalix <toscalix!> has quit IRC12:30
*** Bunio_FH <Bunio_FH!> has quit IRC12:31
*** Bunio_FH <Bunio_FH!> has joined #yocto12:31
*** marka <marka!~masselst@> has joined #yocto12:33
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has quit IRC12:34
*** sgw_ <sgw_!sgw_@nat/intel/x-kiieswnblwuysbfr> has quit IRC12:38
TafThornekergoth: I got the Python script I wanted to use to execute.  Then I found out it was not updated for Pi3 so I am working with the author to get the GitHub code tested and updated with a pull request someone else made that seems to have Pi3 support.  Then he can push it to pypi and I can make a further recipie update to get the new version.12:43
TafThornekergoth: Then I can get the image build, on my Pi and I'll finally be able to turn and LED on and off via the GPIO.  Simples.  Thank you for your help yesterday.  I'll commit an updated recipie file  that fixed the missing python dependencies soon.12:44
*** groleo <groleo!> has quit IRC12:47
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has joined #yocto12:49
rburtoned2: props for the patchelf debugging12:55
kanavinrburton: I'll spend some time playing with meson next week. Right now my daily rhythm is seriously crooked :-/12:55
kanavin(which is something of a lifetime struggle :(12:55
rburtonkanavin: sure, no problem.  the irc channel is friendly and i've a few more patches building up for meta-oe12:56
*** groleo <groleo!> has joined #yocto12:56
*** groleo1 <groleo1!> has joined #yocto13:00
*** groleo <groleo!> has quit IRC13:01
*** toscalix_ <toscalix_!~toscalix@> has quit IRC13:02
*** Bunio_FH <Bunio_FH!> has quit IRC13:04
*** arkver <arkver!~arkver@> has joined #yocto13:05
*** aln <aln!bcaa4943@gateway/web/freenode/ip.> has joined #yocto13:05
kanavinrburton: I better stop trying to do mentally intense work, and tidy up the apartment instead :D13:06
*** aln <aln!bcaa4943@gateway/web/freenode/ip.> has quit IRC13:06
*** Bunio_FH <Bunio_FH!> has joined #yocto13:06
*** Shurelous <Shurelous!~igor@> has joined #yocto13:06
ed2rburton: thanks. it was interesting challenge13:07
rburtoned2: made it seem easy :)13:08
*** Tartarus <Tartarus!sid72705@gateway/web/> has joined #yocto13:08
* Tartarus hopes over here13:08
Tartaruspohly: ping when you're around again13:09
pohlyTartarus: hi. I'm around briefly - was about to run an errand.13:09
Tartaruspohly: k.  So, as I was saying on the ML, I'm not convinced we need to push vmdk stuff in a different direction13:10
TartarusI was telling RP over in #oe that we do use vmdk/etc as distinct types13:10
Tartarusie in AGL we build the various target images as vmdk and pass them to qemu/vmware/virtualbox13:10
*** Bunio_FH <Bunio_FH!> has quit IRC13:10
*** Bunio_FH <Bunio_FH!> has joined #yocto13:11
ed2Tartarus: pohly: +1 for making vmdk a conversion type.13:11
pohlyTartarus: so did we with Ostro. But we didn't want to be limited to images created with the image-vm.bbclass, and therefore introduced the conversion command.13:12
*** Chocobo <Chocobo!~Chocobo@pdpc/supporter/student/chocobo> has joined #yocto13:12
* RP moves his conversation here13:12
pohlyIt's simply more flexible that way. The conversion is always the same, just the base raw image isn't.13:13
RPI can see this from both sides. The current approach is rather hardcoded and less flexible and I can see why it could be difficult to use13:13
TartarusYeah, I can see how being able to use vmdk as a conversion too is useful13:13
*** jpew <jpew!cc4da337@gateway/web/freenode/ip.> has joined #yocto13:13
pohlyTartarus: also note that you don't need to keep the intermediate raw image if you don't want - the current code already throws it away if its not listed separately in IMAGE_FSTYPES.13:13
Tartaruspohly: The current code does not throw away hdddirects13:14
ChocoboHi all.  I am relatively new to Yocto (moving from buildroot).  I have a layer (meta-xilinx) that generates a devicetree file with a horrendous name.  Is it possible to create another layer that I apply that renames it something more manageable?13:14
Tartarus(ok, unless something changed somewhat recently, I did this initially vs morty, I'm bad, just testing it a bit now vs master)13:14
pohlyTartarus: what I meant is that if you ask for foo.vmdk, the "foo" image will be deleted once foo.vmdk is produced.13:14
Tartaruspohly: Er, again, unless things changed for pyro/master, we have the foo.ext4 and foo.hdddirects around13:15
Tartarusbut some of the intermediate bits do get nuked13:15
pohlyTartarus: I think we are talking about different things. What I have in mind is the solution where image-vm.bbclass is responsible for creating a .hddirect image, and nothing else.13:17
pohlyThen a conversion commands produces .hddirect.vmdk.13:17
pohlyWhen a user selects IMAGE_FSTYPES = hddirect.vmdk, that's all that will be in the image deploy directory.13:17
Tartaruspohly: Right.  I don't think that's quite the right direction13:18
TartarusIt's not obvious that users want "" to get something for $VM to use13:18
Tartarusvmdk is a distinct known type13:18
TartarusHow we implement that under the hood, yes, we need to allow for converting anything, easily, to vmdk/etc13:18
Tartaruswic.vmdk/wic.qcow2/etc should happen, I agree13:19
pohlyTartarus: so you are arguing that IMAGE_FSTYPES = vmdk is a thing (= hddirect converted to vmdk format), and that has to be kept. Right?13:19
Tartaruspohly: Yes13:19
Tartarusvmdk/qcow2 are well known types13:19
JaMaRP: does this look like something related to those bitbake changes? it's build I haven't run for a while and today it fails with:13:20
JaMaERROR: Failed to spawn fakeroot worker to run /OE/build/owpb/webos-ports/meta-qt5/recipes-qt/qt5/ [Errno 2] No such file or directory: '/OE/build/owpb/webos-ports/tmp-glibc/sysroots-components/x86_64/pseudo-native/usr/bin/pseudo'13:20
pohlyI get your point. I'm just not sure how important it is to preserve that. To me it seems more like an accident how these types were implemented initially.13:21
Tartaruspohly: I disagree it being an accident13:21
Tartarusvmdk is an image type13:21
TartarusJust like ext4 is an image type13:21
TartarusThese are known quantities outside of the OE world13:21
pohlyWhen was vmdk introduced?13:22
JaMaRP: also shouldn't bitbake-cookerdaemon.log be in tmp-glibc/log? or it cannot be inside tmp-glibc?13:22
Tartarushmm, wikipedia doesn't say13:22
pohlyI mean, in OE-core.13:22
JaMapohly: I think very long time ago13:22
Tartarus90% sure it predates oe-core13:23
RPJaMa: good question. I just inherited the memres logging so its actually always been there for memres. Our logging needs a huge overhaul13:23
TartarusI know image-vm talks about 200413:23
TartarusBut that might have been iso stuff13:23
Tartaruswith the later VM conversions added on top late13:23
JaMaRP: I'm just asking because I was reading the cooker logs in tmp-glibc/log/cooker/13:23
pohlyMy problem with a user from outside OE coming and asking for "a vmdk image" is that it's completely underspecified.13:23
pohlyWhat should be inside the image?13:23
Tartaruspohly: I again disagree13:24
TartarusA user coming from outside of OE and asking for a vmdk image of core-image-sato knows exactly what they're asking for13:24
ed2Tartarus:  <image>.hdddirect.vmdk looks more informative than <image>.vmdk to me.13:24
Tartarusthey're expecting a vmdk file they can throw at vmware/etc that will boot up and have core-image-sato running13:24
pohlyDo they want an image that can install itself?13:24
pohlyBecause that's what they are getting.13:25
TartarusWhat do you mean install itself?13:25
pohlyIncluding all the extra baggage that comes with that.13:25
TartarusThey're getting a disk image that can be used with a virtual machine13:25
pohlyTartarus: hddimg includes an enhanced initramfs that can partition disks and copy the rootfs to the new disk.13:25
Tartarused2: It's informative in that it's exposing OE internals, yes13:25
pohlyTartarus: they get more than that.13:25
pohlyIf they don't care, fine.13:25
Tartaruspohly: hddimg != hdddirect13:25
TartarusThat's another one of the internal things that we should sort out, we have too many ways to say "make a raw disk image"13:26
ed2Tartarus: it's exposing type of the image. This is what pohly is also pointing out to, I believe.13:26
ed2Tartarus: hdddirect.vmdk can be quite different to wic.vmdk13:26
ed2Tartarus: which some users may prefer, btw.13:27
Tartarused2: I agree that wic.vmdk should be a thing that's allowed to happen13:27
TartarusBut I still think that we need to allow for users to just say "I want an image I can throw at my virtual machine" and that internals like "hdddirect" or "hddimg" are not going to lead to a better experience in that regard13:28
pohlyTartarus: it's quite possible that I have confused the live image with hdddirect. I've hardly ever used either of them.13:28
ed2Tartarus: My point is that <image type>.vmdk is more flexible and more informative than .vmdk as it gives user a choice of image.13:28
ed2Tartarus: current .vmdk hides underlying type and forces it.13:29
pohlyTartarus: anyway, I don't mind keeping "vmdk/vdi/qcow2" around as distinct types. I'm just worried that it'll make the code more complicated - but that remains to be seen.13:30
Tartaruspohly: I'm attempting to see if we can add a conversion trivially atm13:30
Tartarused2: Yes, I agree it does force a certain base type of "disk" onto the user13:30
pohlyI also don't think that hdddirect is necessarily the best starting point for such a type. It's mostly legacy code that has been superseeded by wic.13:31
pohlyBut I need to go now...13:31
* Tartarus fixes thinko, gets to the point of seeing if we can easily have vmdk and wic.vmdk13:33
TartarusGood news is it's not failing early and obvious13:34
Tartarusbad news I need a few min to build all of the new deps that wic.vmdk is adding in13:34
TartarusDoes wic default to something that supports BIOS rather than EFI?13:34
Tartarusor at least both?13:34
ed2Tartarus: it depends on which .wks config is used.13:35
ed2Tartarus: it supports both13:35
ed2Tartarus: even both at the same time sometimes13:35
Tartarused2: My first hope for an outright "vmdk now is just doing wic.vmdk, really" would be function-for-functionl replacement13:36
ed2Tartarus: it doesn't support initfs directly though, so if you need to load some disk modules it'd not be trivial to do.13:36
*** groleo1 <groleo1!> has quit IRC13:36
Tartarusie if qemux86-64 is going to spit out a wic.vmdk that still just works on qemu/vmware/virtual box, just as well as it would have before and the user doesn't care, then I don't care :)13:36
TartarusOtherwise I'd like to go with vmdk does what it does today, and wic.vmdk is now a real thing that exists too13:37
Tartarusbut is not a direct replacement of13:37
ed2Tartarus: I thought hddimg.vmdk is a direct replacement, no?13:38
ed2Tartarus: wic is a different beast.13:38
Tartarused2: s/hddimg/hdddirect/ would be13:38
TartarusBut gets back to exposing pointless details to the end user13:38
TartarusNobody knows what hdddirect is13:38
ed2Tartarus: no it's not :)13:38
TartarusFine, I'm arguing it's a pointless detail :)13:38
ed2Tartarus: it's a valuable detail from my point of view.13:39
ed2Tartarus: especially when other underlying types support vmdk conversion13:39
ed2Tartarus: the fact that they don't exist yet doesn't make the solution worse13:39
ed2Tartarus: and as a programmer I'd love to see one .bbclass removed and replaced by couple of lines introducing vmdk conversion13:41
ed2Tartarus: however, I udnerstand that it would not be easy to achieve. probably …13:42
Tartarused2: Well, lets start with this.  What do I need to do, to get core-image-minimal.wic for qemux86-64 to be functionally equivalent to core-image-minimal.vmdk, today?13:42
TartarusOn just oe-core13:42
Tartarus(which is why I started this over in #oe ;))13:42
ed2Tartarus: I don't know which functionality is provided by vmdk. What kind of image is it?13:44
Tartarused2: It's an at least PCBIOS bootable disk image, with syslinux13:45
ed2Tartarus: how is it different from hddimg?13:45
TartarusLets see13:46
Tartarused2: It looks like hddimg forces us to shove something into FAT?13:47
ed2Tartarus: I'd start from hddirect.vmdk. It should be easier to make it workin.13:47
Tartarused2: hdddirect will have an arbitrary ext4 (default) second partition and fat first partition13:47
*** csanchezdll <csanchezdll!> has left #yocto13:47
*** lamego <lamego!~jose@> has joined #yocto13:49
ed2Tartarus: so, if you add conversion types vmdk, gcow and vdi would you be able to build working hddirect.[vmdk, gcow, vdi] image without using image-vm.bbclass ?13:50
Tartarused2: No, because image-vm.bbclass is where we have the logic for hdddirect13:50
ed2Tartarus: ah, ok. If you move that logic to image_types_hdddirect.bbclass and add 3 conversion types would it be cleaner solution than current one?13:52
Tartarused2: Take a look at the patches I posted please13:52
*** ChrysD <ChrysD!d9804861@gateway/web/freenode/ip.> has quit IRC13:52
TartarusAnd then yes, a follow up could be a rename of image-vm to image_types_vm13:52
ed2Tartarus: I did. This is not what I'm talking about.13:54
ed2Tartarus: I'm talking about getting rid of main image types vmdk, gcow, vdi and replacing them with conversion types.13:55
ed2Tartarus: and this is not what your patchset does.13:56
*** groleo <groleo!> has joined #yocto13:56
ed2If that is in place the next step would be to look at wic13:57
Tartarused2: What my patch does is 90% of that however13:57
*** ant_work <ant_work!> has quit IRC13:57
TartarusSince the hard part isn't making vmdk being a conversion type13:57
Tartarusit's about making it still easy on end users to get what the expect13:57
ed2And if we're lucky we can get dir of hddirect image type. However, I'm not expecting it to be easy. At least for now.13:58
Tartarused2: So, lets cycle back to my question13:58
TartarusIf I build core-image-minimal.wic13:58
TartarusFor qemux86-6413:58
TartarusAm I going to get something that'll just run, easily, on qemu/vmware/virtualbox?13:58
ed2yes for qemu13:59
ed2didn't try to run it on vmware/virtualbox13:59
ed2runqemu script supports wic out of the box.13:59
TartarusNot runqemu so much as users with qemu ;)13:59
TartarusBut, yes, OK, documentation13:59
ed2runqemu is just a wrapper around qemu I believe14:01
TartarusYeah, it buries various bits of logic14:01
TartarusBut if wic is spitting out a functional disk image, it should just be seen as a raw disk14:02
ed2yes, qemu runs it as a raw disk14:03
TartarusOK, seeing what vmware/vbox do with core-image-minimal.wic14:04
TartarusAnd then I'll move forward from that :)14:04
*** ash_charles <ash_charles!~acharles@2607:fad8:4:6:c8a6:17d:5ad6:1157> has joined #yocto14:04
*** stefan <stefan!> has joined #yocto14:06
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has joined #yocto14:07
*** Trinners <Trinners!> has joined #yocto14:15
*** toscalix <toscalix!> has joined #yocto14:17
*** groleo <groleo!> has quit IRC14:20
ed2Tartarus: one more thing that I found confusing is that hdddirect seems to be not related to vm. please, correct me if I'm wrong here.14:22
Tartarused2: No, it would make more sense as .raw rather than .hdddirect14:22
TartarusAs it was initially for raw disk images / ISOs14:22
TartarusAnd VM got bolted on ages and ages ago14:22
Tartarused2: FWIW, maybe we can just go with .wic.vmdk14:23
ed2Tartarus: exactly. That's why it's underlying image type unlike vmdk, qcov and vdi14:23
TartarusI still want to see if we can hide the "wic" part to normal users in some ways14:23
TartarusMy tester is reminding me that he wouldn't have any clue what wic means, were it not for some other JIRA issues he's been reading over of late14:24
ed2Tartarus: we shouldn't hide it :) It gives user opportunity to tweak it using different .wks entries: have more partitions, support EFI, use different filesystems etc.14:25
Tartarused2: IMAGE_FSTYPES += "wic.vmdk.xz" is not user friendly14:25
TartarusWhat is wic?14:26
ed2Tartarus: why not? Pretty clear explains what's inside.14:26
TartarusTo OE people, sure14:26
*** Chocobo <Chocobo!~Chocobo@pdpc/supporter/student/chocobo> has quit IRC14:27
ed2Tartarus: for oe users as well. for external users you can rename it if you want.14:27
ed2Tartarus: directdisk or hdddisk are not very self-explanatory too, btw.14:28
*** jmcruzal <jmcruzal!~jmcruzal@> has joined #yocto14:28
Tartarusraw would be14:28
ed2Tartarus: vmdk is just an image format. it doesn't tell anything about the structure or content of the image.14:29
Tartarused2: I fear we're just going to go round and round on that part14:30
Tartarus"core-image-minimal.vmdk" tells the user what they expect to know, "core-image-minimal.wic.vmdk" tells the user more or less the same thing14:30
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has quit IRC14:30
Tartarusexcept some people will know what wic means and some will not14:30
ed2Tartarus: yes, agree. I think we've got each other points, jus don't agree. That's ok.14:30
TartarusFor the moment I'm going to see why I have wic.vmdk spitting out14:30
Tartarusbut nto wic.vmdk.xz14:30
ed2Tartarus: raw doesn't tell much about image structure(partitions, filesystems), btw.14:32
*** mappy <mappy!b9691ff9@gateway/web/freenode/ip.> has quit IRC14:32
Tartarused2: No, but it says it's a raw image :)14:32
*** scottrif <scottrif!> has joined #yocto14:32
Tartarusraw disk image, people know that it's a raw disk image to poke at using usual tools14:33
TartarusWe are allowed normally to stack conversion/compression types, yes?14:33
ed2Tartarus: yep, and pretty much can be called raw image. It doesn't matter if it's partitioned or not, has efi or syslinux, ext4 or btrfs partitions.14:33
ed2Tartarus: yes, it's allowed to chain conversion types.14:34
ed2Tartarus: raw doesn't tell user if the image contains installer either.14:35
Tartarused2: No, image name should be telling the user if it's something that installs14:35
TartarusSince that's extremely image context dependent14:35
ed2Tartarus: it should, but it doesn't. core-mage-minimal only tells you about rootfs content.14:36
TartarusOr maybe let me try a different path14:37
*** Bunio_FH <Bunio_FH!> has quit IRC14:37
TartarusWhy would images be able to "install" unless someone was very explicit about that being a use case they had?14:37
TartarusI'd be quite unhappy if suddenly my images could "install"14:37
Tartaruswhen that's not anything I want them to be anywhere near as that's nonsense14:37
*** Kakounet <Kakounet!> has quit IRC14:39
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC14:39
Tartarused2: No, I'm not seeing arbitrary stacking14:41
* Tartarus pokes stuff harder to see whats up14:42
ed2Tartarus: sorry, I don't follow. arbitrary stacking of what?14:43
Tartarused2: Compression / conversion14:43
Tartarusie I can't do ext3.gz.bz214:43
TartarusNor wic.vmdk.xz14:43
ed2Tartarus: looks like a bug to me.14:44
*** mdnneo <mdnneo!~umaucher@> has quit IRC14:44
ed2Tartarus: I remember pohly implemented it some time ago.14:46
Tartaruspohly: back yet?14:46
ed2Tartarus: just tried to build wic.gz.xz and it built only wic. Looks like it either didn't build compressed types or removed them.14:47
TartarusYeah, I don't think it's building them even :(14:47
TartarusWhen did this work last roughly?14:48
*** Radela_ <Radela_!> has joined #yocto14:50
*** Bunio_FH <Bunio_FH!> has joined #yocto14:51
ed2hard to say. I only saw it implemented. Didn't test it.14:51
*** Radela <Radela!> has quit IRC14:52
*** Bunio_FH <Bunio_FH!> has quit IRC14:53
*** toscalix <toscalix!> has quit IRC14:53
*** prabhakarlad <prabhakarlad!~prabhakar@> has left #yocto14:53
TartarusOK, fun times :)14:55
* Tartarus prepares to kick things around14:55
Tartarused2, was it in 2017 or 2016? :)14:55
*** MarcWe <MarcWe!> has quit IRC14:55
*** zeenix <zeenix!> has joined #yocto14:56
*** hamis_lt_u <hamis_lt_u!~irfan@> has joined #yocto14:58
ed2Tartarus: commit ba57ba1942546045907a7e1831515ad2da420ab215:01
ed2Author: Patrick Ohly <>15:01
ed2Date:   Mon Mar 7 15:51:14 2016 +010015:01
ed2    image.bbclass: support chaining compression (aka conversion) commands15:01
pohlyed2, Tartarus: it definitely used to work. But I've not been involved in further changes to the code, so I can't say anything about the current state of affairs.15:02
TartarusUg, ok15:03
Tartaruswhat bitbake version do I even need for that15:03
TartarusDouble ugh, lemme grab a yocto..15:03
ed2pohly: some tests would ensure it works, I believe :)15:03
ed2Tartarus: you don't need to grab a Yocto just for that.15:04
Tartarused2: Yeah, found oe core rev15:04
pohlyed2: I've learned about oe-selftest only later... but yeah, some tests would be needed.15:04
ed2Tartarus: git log |grep "support chaining compression"15:04
pohlyI've heard rumors of a QA team adding tests after developers have implemented features...15:04
pohly... but I guess it's better to not rely  on that.15:05
TartarusOK, found an old bitbake version15:05
ed2Tartarus: just file a bug. You don't need this right now. wic.vmdk would work if you define vmdk conversion.15:06
Tartarusconfirming it did work then, then let the bisect begin15:07
Tartarused2: I need compressed vmdk upstream15:07
Tartarused2: Do you have any hints on where to poke things to have wic change from passing root=/dev/sda2 to passing root=PARTUUID=${@generated_disk_signature()} or there-abouts ?15:08
TartarusThat's that other thing to make these images easily passable between VMs15:08
Tartarused2: ... OK, and then to make that be the default used for a board?15:11
*** toscalix <toscalix!> has joined #yocto15:12
ed2Tartarus: it depens on the board/machine.15:12
Tartarused2: Well, the default seems to be sda215:12
TartarusBased on what's coming up as waiting for ..., when testing these wic images in VMs15:12
TartarusI see15:13
ed2Tartarus: it's specified in wks. here is an example:
Tartarused2: Is there a reason we're not defaulting to PARTUUID for these canned things?15:13
Tartarusscripts/lib/wic/canned-wks/directdisk-bootloader-config.cfg and scripts/lib/wic/canned-wks/qemux86-directdisk.wks15:13
Tartarusshouldn't default to sda15:13
ed2well 1st thing is legacy. 2nd - I prefer to have wic configs in layers as there you can be more specific with its content.15:15
ed23rd - directdisk is not efi image. it uses mbr and partuuids for mbr are a bit unusual.15:15
Tartarused2: Legacy what?15:16
TartarusEverything as PARTUUID15:16
TartarusMBR ones are just not awesome ones15:16
TartarusBut they're valid15:16
Tartarusmeta/classes/image-vm.bbclass even makes better-than-normal ones for MBR15:17
ed2Tartarus: wic also supports them. I was just afraid of adding them to canned wks as they're widely used.15:18
Tartarused2: PARTUUID is part of the kernel, has been for forever15:18
ed2someone asked me about this here couple of months ago.15:19
kergothuuid does sound a like a hell of a lot better default15:19
TartarusThat's why we use them by default in U-Boot whenever we can15:19
TartarusCan't rely on kernel ordering15:19
ed2and promised to send a patch :)15:19
Tartaruscan't rely on sdX vs hdX15:19
pohlyrefkit-image-common-intel-corei7-64-20170721150939.wic.xz was just created fine for me.15:19
Tartarused2: So where would I need to start kicking things to move those to use --use-uuid by default?15:19
Tartaruspohly: Yes, but that's not stacking15:19
Tartaruspohly: wic.gz.xz will fail15:20
ed2pohly: wic.xz is using one conversion type15:20
pohlyOkay, just one level. Right, you wanted more.15:20
Tartaruspohly: We got there since it's "trivial" to get wic.vmdk going15:20
Tartaruswith vmdk as conversion typ15:20
kergothi kind of hate IMAGE_CMD and all of that, the use of bitbake variables is a bit silly, we should have just used shell functions that accept arguments15:20
kergoth</random complaint>15:20
ed2Tartarus: if you think this change is harmless - just send a patch. if you want to be careful you can start from discussing it on architecture mailing list and then send a patch.15:21
Tartarused2: Patch to what?  root=/dev/sda2 is in a bunch of places15:22
TartarusDo I just need to drop those?15:22
TartarusIt's jsut automatic insertion?15:22
ed2it's automatic as far as I remember. just use —use-uuid for root15:23
ed2for root partition15:23
pohlyIndeed, wic.xz.sha1sum no longer works.15:23
pohlyed2: are you going to file a bug?15:24
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has quit IRC15:25
ed2pohly: I proposed Tartarus to do that :)15:25
ed2Tartarus: can you?15:25
TartarusI'm attempting a bisect atm15:25
*** zeenix <zeenix!> has quit IRC15:26
ed2Tartarus: —ondisk=sda should be removed as well. it's not mandatory, but less confusing.15:27
*** lemagoup <lemagoup!~lemagoup@> has quit IRC15:28
ed2Tartarus: did you try if wic.vmdk is functional under vmware?15:29
Tartarused2: Yes, wic.vmdk functioned, aside from root= 'issues'15:29
Tartarusas in, need to make sure to pass the right bits so it shows up as scsi15:29
ed2Tartarus: that's what I expected. you'd need initfs for ide drivers or include them into kernel.15:30
*** eduardas_m <eduardas_m!~eduardas@> has quit IRC15:30
ed2Tartarus: how does it work with current .vmdk images? does they work for all disk drive types?15:30
Tartarused2: Kernel should be as functional as ever15:30
Tartarused2: They 'just work', once the PARTUUID bit is passed in15:30
Tartarusmy coworker with the setup is helping his MIL atm15:31
ed2Tartarus: hm, intersting. Someone told me that only scsi disk drive is supported. I didn't try it myself though.15:32
Tartarused2: Yes, I think that's part of the fun15:32
*** clown_ <clown_!c2cc2109@gateway/web/freenode/ip.> has joined #yocto15:37
*** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has quit IRC15:38
*** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has joined #yocto15:38
*** Radela_ <Radela_!> has quit IRC15:42
*** rajm <rajm!~robertmar@> has quit IRC15:45
*** mckoan is now known as mckoan|away15:49
*** Radela <Radela!> has joined #yocto15:49
*** mihai <mihai!~mihai@unaffiliated/mihai> has quit IRC15:51
*** hbruce <hbruce!~hbruce@> has quit IRC15:53
*** toscalix <toscalix!> has quit IRC15:56
*** ed2 <ed2!Adium@nat/intel/x-ztzlfnlyqtawgdub> has quit IRC15:56
halsteadStarting maintenance on main AB.15:59
*** florian <florian!~fuchs@Maemo/community/contributor/florian> has quit IRC16:00
*** WillMiles <WillMiles!> has joined #yocto16:05
*** joshuagl <joshuagl!~joshuagl@> has quit IRC16:05
*** stefan <stefan!> has quit IRC16:06
*** ash_charles <ash_charles!~acharles@2607:fad8:4:6:c8a6:17d:5ad6:1157> has quit IRC16:09
*** stefan <stefan!> has joined #yocto16:09
*** lucaceresoli <lucaceresoli!> has quit IRC16:10
*** toscalix <toscalix!> has joined #yocto16:11
*** scottrif <scottrif!> has quit IRC16:11
*** ash_charles <ash_charles!~acharles@2607:fad8:4:6:c8a6:17d:5ad6:1157> has joined #yocto16:12
*** ash_charles <ash_charles!~acharles@2607:fad8:4:6:c8a6:17d:5ad6:1157> has quit IRC16:18
*** YoctoAutoBuilder <YoctoAutoBuilder!> has quit IRC16:20
*** YoctoAutoBuilder <YoctoAutoBuilder!> has joined #yocto16:20
*** stefan <stefan!> has joined #yocto16:20
halsteadMain AB ready for use.16:21
*** MWelchUK <MWelchUK!> has quit IRC16:24
clown_Can't see why in meta-qt5 layer qtchooser is not native ant thus doesn't populate sysroot with /usr/bin/*. Anyone, what I'm missing?16:24
TartarusWow, been broken for a long time it looks like :(16:30
* Tartarus continues the bisect16:30
Tartarusclown_: per recipe sysroot unfun and you're missing DEPENDS ?16:31
*** toscalix <toscalix!> has quit IRC16:31
* Tartarus gets on with zucchini bread making, idly wonders where the (ex)Mentor folks are that would appreciate bread talk16:32
*** zeenix <zeenix!> has joined #yocto16:36
clown_Tartarus: I have DEPENDS on qtchooser. But qchooser:do_populate_sysroot don't care about /usr/bin at all. Do you think it's a bug, or I'm wearing a shoe on my head?16:38
Tartarusclown_: DEPENDS += qtchoser-native ?16:40
*** ash_charles <ash_charles!~acharles@2607:fad8:4:6:252f:67b3:f11c:3d56> has joined #yocto16:40
clown_Tartarus: ...and a complimentary qtchooser-native.bbappend, I recon?16:43
Tartaruserrr16:43 should BBCLASSEXTENDS native or whatever the right syntax is16:44
TartarusAnd if some qt5 class doesn't already say you DEPENDS on qtchooser-native16:44
TartarusYour recipe should16:44
TartarusI don't do qt enough to know if that's a common tool or not, sorry16:44
clown_Tartarus: yes, that was the original issue. qtchooser does not BBCLASSEXTEND native. Ignore any garbage I said after that16:46
Tartarusah, kk :)16:46
*** hamis <hamis!~irfan@> has quit IRC16:51
*** hamis_lt_u <hamis_lt_u!~irfan@> has quit IRC16:51
*** aehs29 <aehs29!~aehernan@> has quit IRC16:52
*** Bunio_FH <Bunio_FH!> has joined #yocto17:01
*** dreyna <dreyna!> has joined #yocto17:06
*** clown_ <clown_!c2cc2109@gateway/web/freenode/ip.> has quit IRC17:09
*** aehs29 <aehs29!~aehernan@> has joined #yocto17:20
*** vmeson <vmeson!> has quit IRC17:23
*** stefan <stefan!> has quit IRC17:25
*** zeenix <zeenix!> has quit IRC17:27
*** T_UNIX <T_UNIX!uid218288@gateway/web/> has quit IRC17:29
*** scottrif <scottrif!~scottrif@> has joined #yocto17:31
*** t0mmy <t0mmy!~tprrt@> has quit IRC17:37
*** LocutusOfBorg <LocutusOfBorg!~Gianfranc@ubuntu/member/locutusofborg> has quit IRC17:44
*** martinkelly <martinkelly!> has joined #yocto17:52
*** pohly <pohly!> has quit IRC17:58
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has joined #yocto17:59
*** luc4 <luc4!> has quit IRC18:27
*** vmeson <vmeson!> has joined #yocto18:27
*** zero_note <zero_note!~zero@> has quit IRC18:34
*** garbados <garbados!~garbados@2601:1c2:303:6b0:3892:9803:436a:4ac3> has joined #yocto18:35
*** sjolley <sjolley!~sjolley@> has quit IRC18:36
*** ash_charles <ash_charles!~acharles@2607:fad8:4:6:252f:67b3:f11c:3d56> has quit IRC18:38
*** bully4u <bully4u!~Adium@> has joined #yocto18:43
*** jwessel <jwessel!~jwessel@> has joined #yocto18:46
*** sjolley <sjolley!~sjolley@> has joined #yocto18:47
*** denix <denix!> has joined #yocto18:52
*** LocutusOfBorg <LocutusOfBorg!~Gianfranc@> has joined #yocto19:00
*** LocutusOfBorg <LocutusOfBorg!~Gianfranc@ubuntu/member/locutusofborg> has joined #yocto19:00
*** JaMa <JaMa!~martin@> has quit IRC19:04
*** ash_charles <ash_charles!~acharles@2607:fad8:4:6:c8a6:17d:5ad6:1157> has joined #yocto19:05
garbadoshello! i'm having issues with 'testimage'. i've added 'INHERIT += testimage' to conf/local.conf, among other test-related options, and run `bitbake core-image-sato-sdk -c testimage -v` which yields an error that asks `Have you built the image with INHERIT+="testimage" in the conf/local.conf?`19:06
garbadossince 'INHERIT += testimage' is indeed in conf/local.conf, i don't know how to interpret or act on the error message19:06
*** LocutusOfBorg <LocutusOfBorg!~Gianfranc@ubuntu/member/locutusofborg> has quit IRC19:09
*** ash_charles <ash_charles!~acharles@2607:fad8:4:6:c8a6:17d:5ad6:1157> has quit IRC19:14
clsullivgarbados: make sure core-image-sato-sdk has been built already, so no -c testimage19:16
clsullivgarbados: with 'INHERIT += testimage'  still in local.conf19:16
garbadosclsulliv, thanks, i'll try that :)19:17
*** jwessel <jwessel!~jwessel@> has left #yocto19:25
*** ash_charles <ash_charles!~acharles@2607:fad8:4:6:252f:67b3:f11c:3d56> has joined #yocto19:27
TartarusDown to 7 steps to go19:29
*** bluelightning <bluelightning!> has joined #yocto19:54
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto19:54
*** aehs29 <aehs29!~aehernan@> has quit IRC19:55
*** lexano_ <lexano_!> has joined #yocto19:57
*** WillMiles <WillMiles!> has quit IRC19:57
*** lexano <lexano!~lexano@> has quit IRC20:00
garbadosclsulliv, hey, that got me to a different error! thanks for your help getting out of one jam :)20:19
garbadosgetting these errors now: `core-image-sato-sdk-1.0-r0 do_testimage: Couldn't get ip from qemu command line and runqemu output!`20:20 AB ready for use.20:21
Tartarus3 steps to go20:21
Tartarusand it's now basically a cleansstate, check, repeat loop, woo20:21
halsteadgarbados, Your VM doesn't have nested KVM enabled. Let me know if you need that for accelerated sanity testing.20:22
garbadoshalstead, KVM? all i'm trying to do is `bitbake core-image-sato-sdk -c testimage -v`20:23
halsteadgarbados, I don't think it should be an issue unless you are working on sanity tests but I wanted to mention it since I saw you here talking about qemu.20:24
garbadosi'm not quite sure if i'm working on sanity tests. just trying to follow through on steps in yocto guides regarding testing images20:27
Tartaruscommit 46bc438374de74af76d288520c6252c9b784076720:27
TartarusAuthor: Zhenhua Luo <>20:27
TartarusDate:   Mon Jun 13 19:47:34 2016 +080020:27
Tartarus    image.bbclass: do exact match for rootfs type20:27
TartarusNow to think about those changes a bit :)20:27
*** Radela <Radela!> has quit IRC20:30
*** marka <marka!~masselst@> has quit IRC20:32
clsullivgarbados: this is a shot in the dark since I've only done testing on real hardware, but you might need to set the TEST_TARGET_IP variable to your host's IP address20:33
clsullivcould be completely wrong here20:33
*** aehs29 <aehs29!~aehernan@> has joined #yocto20:33
clsulliverr, TEST_SERVER_IP20:33
clsullivtarget is used for the hardware target IIRC20:34
garbadosclsulliv, thanks, i'll try that20:35
TartarusAlso, ugh, need to stop making the uboot image stuff second class citizen20:38
*** stefan <stefan!> has joined #yocto20:50
*** luc4 <luc4!> has joined #yocto21:09
*** ant_home <ant_home!> has joined #yocto21:09
*** tgoodwin <tgoodwin!> has quit IRC21:14
*** scottrif <scottrif!~scottrif@> has left #yocto21:22
*** groleo <groleo!~groleo@> has joined #yocto21:28
*** lamego <lamego!~jose@> has quit IRC21:32
*** stefan <stefan!> has quit IRC21:33
*** groleo <groleo!~groleo@> has quit IRC21:33
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has joined #yocto21:36
*** shauno <shauno!~soneil@pdpc/supporter/professional/shauno> has quit IRC21:37
*** alimon <alimon!~alimon@> has quit IRC21:41
*** ash_charles <ash_charles!~acharles@2607:fad8:4:6:252f:67b3:f11c:3d56> has quit IRC21:51
*** georgem_home <georgem_home!uid210681@gateway/web/> has joined #yocto22:00
*** Shurelous <Shurelous!~igor@> has quit IRC22:05
*** jpew <jpew!cc4da337@gateway/web/freenode/ip.> has quit IRC22:39
*** rburton <rburton!> has quit IRC22:45
*** nathani_ <nathani_!> has quit IRC22:46
*** nathani_ <nathani_!> has joined #yocto22:49
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC22:55
*** sjolley <sjolley!~sjolley@> has quit IRC23:04
*** agust <agust!> has quit IRC23:06
*** ant_home <ant_home!> has quit IRC23:10
*** Trinners <Trinners!> has quit IRC23:24
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has quit IRC23:59

Generated by 2.11.0 by Marius Gedminas - find it at!