Monday, 2019-02-25

*** AccelShark <AccelShark!~ace@> has joined #yocto00:14
*** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC00:17
black_13what is the settings for the local.conf to allow me to use the qemu arm test00:19
khemcopy it into local.conf00:24
khemand make changes as needed00:24
*** gtristan <gtristan!~tristanva@> has joined #yocto00:26
khemdid you follow the readme ?00:27
khem. ./ && bitbake yoe-simple-image then execute runqemu nographic00:28
nerdboykhem: thud doesn't fail on either bison or cross-localedef00:33
nerdboy* for me on unsupported gentoo build host00:33
nerdboyi probably don't update frequently enough but i'm pretty much always on ~hardened or ~musl-hardened profile00:35
khemnerdboy: yeah thud is recent enough00:36
khemusually glibc (uninative) is an issue for rolling distros00:36
nerdboyyeah i don't remember the shim being installed until (relatively) recently00:37
nerdboybranch-wise recently...00:37
*** vmesons <vmesons!> has joined #yocto00:55
*** vmeson <vmeson!> has quit IRC00:56
*** nighty- <nighty-!> has joined #yocto00:58
*** vmesons is now known as vmeson01:04
*** gtristan <gtristan!~tristanva@> has quit IRC01:06
*** chandana73 <chandana73!~ckalluri@> has joined #yocto01:15
*** ferlzc <ferlzc!~ferlzc@> has quit IRC01:36
black_13khem: i had to step away and make dinner02:08
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has quit IRC02:52
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has joined #yocto03:07
black_13how do you use ipk or get bitbake to generate ipk packages03:11
*** AccelShark <AccelShark!~ace@> has quit IRC03:47
*** BuddyButterfly <BuddyButterfly!> has joined #yocto03:47
*** BuddyButterfly1 <BuddyButterfly1!> has quit IRC03:49
khemblack_13: if you use yoe then ipk is default backend04:52
khemso you can do bitbake foo04:52
khemyoe_setup_feed_server <ip of target device>04:53
khemthis will start a feed server on your build machine04:53
khemnow you can go to your target machine and do opkg update && opkg install foo04:54
khemprovided you have n/w setup on your target04:54
*** sno <sno!> has quit IRC05:12
*** comptroller <comptroller!> has quit IRC05:18
*** warthog9 <warthog9!> has joined #yocto05:49
*** jobroe <jobroe!~manjaro-u@> has joined #yocto05:59
*** AndersD <AndersD!~AndersD@> has joined #yocto06:11
*** AndersD <AndersD!~AndersD@> has quit IRC06:15
*** pbb <pbb!> has joined #yocto06:16
*** AndersD <AndersD!~AndersD@> has joined #yocto06:16
*** ctlnwr <ctlnwr!~catalin@> has quit IRC06:20
*** ctlnwr_ <ctlnwr_!~catalin@> has quit IRC06:20
*** lucaceresoli <lucaceresoli!> has quit IRC06:44
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has joined #yocto06:44
*** lucaceresoli <lucaceresoli!> has joined #yocto06:49
*** agust <agust!> has joined #yocto06:55
*** ctlnwr <ctlnwr!~catalin@> has joined #yocto06:58
*** ctlnwr_ <ctlnwr_!~catalin@> has joined #yocto06:58
*** paulg <paulg!> has quit IRC07:06
*** frsc <frsc!~frsc@2003:a:e7a:6200:246c:2a8b:f45a:a33d> has joined #yocto07:07
*** tprrt <tprrt!~tprrt@> has joined #yocto07:13
*** paulg <paulg!> has joined #yocto07:23
*** rubdos <rubdos!~rubdos@2a02:578:859d:701:a846:9858:21a:9451> has joined #yocto07:43
*** rubdos_ <rubdos_!> has quit IRC07:44
*** mckoan|away is now known as mckoan07:46
*** sk_tandt <sk_tandt!> has joined #yocto08:00
*** jobroe <jobroe!~manjaro-u@> has quit IRC08:01
*** chandana73 <chandana73!~ckalluri@> has quit IRC08:02
*** jobroe <jobroe!~manjaro-u@> has joined #yocto08:03
*** yacar_ <yacar_!> has joined #yocto08:04
*** fl0v0 <fl0v0!> has joined #yocto08:09
*** jij <jij!jonashg@nat/axis/x-qkkiixzjrocdpbrh> has joined #yocto08:16
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto08:27
*** TobSnyder <TobSnyder!> has joined #yocto08:29
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC08:32
*** demonimin <demonimin!~demonimin@unaffiliated/demonimin> has joined #yocto08:35
*** gtristan <gtristan!~tristanva@> has joined #yocto08:42
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has quit IRC08:45
*** retoatwork <retoatwork!~reto@> has quit IRC08:49
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has quit IRC08:49
RPJaMa: From what I remember do_install had to have the get_auto_pr else the PR values would be incorrect09:01
JaMaPKGR, right? but do_install doesn't seem to use them anywhere (other than WORKDIR where it's not expanded anyway)09:02
RPJaMa: yes, its the use of PKGR09:02
RPJaMa: I suspect back then it may have done but changed over time?09:03
JaMaI'll try to remove it to see if something breaks now09:03
RPJaMa: definitely worth looking at, it does seem an odd thing to do now...09:04
*** comptroller <comptroller!> has joined #yocto09:04
JaMaI've also replaced PKGR with PR to work around this (PKGR can be used in the symlink later)09:05
RPJaMa: you're effectively just reverting that commit then09:06
JaMaonly partially and with do_deploy_links task after do_deploy it can result in the same artifact names09:08
RPJaMa: but the artefact name itself would have the unexpanded PR?09:08
JaMathe goal is to have reusable do_deploy sstate, which is then hard linked with any filenames you want (which might mean expanded PKGR)09:09
RPJaMa: you are right, the use of TASKHASH in get_auto_pr means it has to be called consistently09:09
JaMae.g. with DATETIME currently included in artifact names, you either have to re-execute do_deploy every single build (which means rebuild for builds with rm_work) or you have "old" datetime in deploy directory artifacts09:10
JaMait's more annoying if you do "releases" by setting the version suffix e.g. from jenkins job -> again either you need to rebuild kernel or you might get different release number for kernel artifact in some builds (those where kernel checksums didn't change since previous release)09:11
RPJaMa: my main worry with this is that we then break "stacking" artefacts09:12
RPJaMa: the old OE behaviour was to generate a new image each run, the symlinks were then added to you could easily find "latest"09:12
JaMain webOS we work around this by extra task (do_deploy_fixup) but it's quite error prone to do from "outside" in our layer, because every do_deploy needs to be wrapped with do_deploy_fixup and then the task dependencies which might depend on other recipe do_deploy need to be adjusted as well09:12
RPJaMa: with sstate we started letting it clean up previous output but left it so you could easily disable that09:13
JaMathis use case is still supported09:13
*** sk_tandt_ <sk_tandt_!> has joined #yocto09:13
JaMathat's why the links are hardlinks (so whatever the version says you'll get) and the latest is the one without version09:14
RPJaMa: hmm, right09:14
JaMamaybe it could be simiplified even more and use just KERNEL_VERSION variable in do_deploy (as the latest one) like do_install does, but that will prevent people from renaming the "latest" one in deploy09:15
RPJaMa: I agree we need to do something to improve things09:15
JaMaI have something which works in most cases, once I test it on more combinations, I'll share it in the bugzilla to better show how it looks now and how it will look like in deploy dir09:16
*** sk_tandt <sk_tandt!> has quit IRC09:17
RPJaMa: sounds good. I think explaining the change and the reasons behind it will be impoartant09:17
JaMahaving the extra variables introduced in thud already helps with "external" sollution, but hopefully with good explanation people will agree to get it all in oe-core09:18
RPJaMa: yes09:19
* RP notes its technically 2.7 feature freeze today. We're nowhere near ready :(09:21
*** florian_kc is now known as florian09:22
*** YokoOkto <YokoOkto!91fdde45@gateway/web/freenode/ip.> has joined #yocto09:22
*** Saur <Saur!pkj@nat/axis/x-zmajdjsemlvbjkmq> has joined #yocto09:24
YokoOktohello, I applied the preempt_rt patch and still see peaks of 15ms although normally it runs with 300┬Ás. Do you also have such experience, and what is the best tool to analyze where that is reasoned?09:25
LetoThe2ndYokoOkto: probably better to ask the linux rt channel over at OFTC09:27
YokoOktohmm ok thank you09:28
*** Saur <Saur!pkj@nat/axis/x-zmajdjsemlvbjkmq> has quit IRC09:28
*** Saur <Saur!pkj@nat/axis/x-dbkaxfgucdnjycdm> has joined #yocto09:30
*** Saur <Saur!pkj@nat/axis/x-dbkaxfgucdnjycdm> has quit IRC09:32
*** Saur <Saur!pkj@nat/axis/x-gdtnljjpmbhvewit> has joined #yocto09:34
*** dv_ <dv_!~dv@> has quit IRC09:38
RPkanavin: around?09:43
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto09:45
*** lucaceresoli <lucaceresoli!> has quit IRC09:46
* RP sends email09:47
*** dv_ <dv_!> has joined #yocto09:52
*** T_UNIX <T_UNIX!uid218288@gateway/web/> has joined #yocto09:55
*** alinucs <alinucs!> has quit IRC10:02
*** YokoOkto <YokoOkto!91fdde45@gateway/web/freenode/ip.> has quit IRC10:03
*** alinucs <alinucs!> has joined #yocto10:04
*** alinucs <alinucs!> has quit IRC10:09
*** alinucs <alinucs!> has joined #yocto10:09
*** gsalazar <gsalazar!> has quit IRC10:14
*** rburton <rburton!> has joined #yocto10:15
*** alinucs <alinucs!> has quit IRC10:20
*** alinucs <alinucs!> has joined #yocto10:21
*** sk_tandt_ <sk_tandt_!> has quit IRC10:30
*** sk_tandt <sk_tandt!> has joined #yocto10:42
*** lucaceresoli <lucaceresoli!> has joined #yocto10:42
*** nslu2-log <nslu2-log!~nslu2-log@> has quit IRC10:48
*** alinucs <alinucs!> has quit IRC10:50
*** hugo___ <hugo___!sid6079@gateway/web/> has joined #yocto10:52
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto10:53
hugo___Hi everyone! I added `SDK_EXTRA_TOOLS = " nativesdk-cmake     " ` as described here:,Eclipse,_and_SDKS to get a CMake toolchain for my SDK. However, the CMake Toolchain would only work if I source the SDK environment before hand. Is there a "configuration/buildstep/install" step that would allow the SDK to export a Cmake toolchain with the paths needed to cross compile10:54
hugo___without sourcing?  thanks in advnace10:54
*** sk_tandt <sk_tandt!> has quit IRC10:55
kanavinRP: yep10:59
*** nslu2-log <nslu2-log!~nslu2-log@> has joined #yocto10:59
*** sk_tandt <sk_tandt!> has joined #yocto10:59
*** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto11:00
*** daniel-k <daniel-k!~daniel@> has joined #yocto11:01
RPkanavin: I've taken some bits of virtgl in so the patchset should reduce a bit more :)11:02
kanavinRP: thanks :) I did notice that debian 8 also fails the selftest with an unhelpful error message11:03
RPkanavin: right, two issues. the unhelpful message and the fact it fails :(11:04
RPprobably should have a bug for the former11:04
kanavinRP: I suspect the actual testimage log might tell a bit more11:04
kanavinlog file11:04
kanavinoh, massive update to master, finally!11:04
RPkanavin: this batch took quite a bit of sorting out11:05
*** sk_tandt_ <sk_tandt_!> has joined #yocto11:06
*** alinucs <alinucs!> has joined #yocto11:06
RPwe now have a working resulttool, buildhistory and auto updating repositories of all the data, hopefully11:08
*** sk_tandt <sk_tandt!> has quit IRC11:09
rburtonhugo___: you need to source to use the sdk11:10
*** alinucs <alinucs!> has quit IRC11:13
*** alinucs <alinucs!> has joined #yocto11:13
*** sk_tandt_ <sk_tandt_!> has quit IRC11:21
jofrhugo___: And that's a feature, not a bug.  ;-)11:27
*** sno <sno!~sno@2a01:598:9904:28c3:c31:9ed0:a77f:f2ad> has joined #yocto11:28
*** gsalazar <gsalazar!> has joined #yocto11:30
hugo___rburton: jofr : Ok, need is a strong word ;P11:31
*** berton <berton!~berton@> has joined #yocto11:33
rburtonhugo___: bits of the sdk use environment variables exported by the setup script, so need is the correct word11:42
*** sk_tandt <sk_tandt!> has joined #yocto11:42
RPhugo___: it does not work without it. I'm sure you could wrap every binary in the SDK to set the right envvars to avoid sourcing but you'd still have to modify PATH to find said binaries and to do that you'd probably still have to source something11:47
*** sgw <sgw!~sgw@> has quit IRC11:53
*** AndersD_ <AndersD_!~AndersD@> has joined #yocto11:58
*** AndersD <AndersD!~AndersD@> has quit IRC12:00
*** sno <sno!~sno@2a01:598:9904:28c3:c31:9ed0:a77f:f2ad> has quit IRC12:04
*** ferlzc <ferlzc!~ferlzc@> has joined #yocto12:14
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has quit IRC12:16
kanavinRP: I'll send a patch that removes the _remove in qemu recipe in a moment12:17
yacar_Hey guys, I have still no review on my patch sent on the mailing list, shall I change something ? See mailing list thread : "Fixing devtool issue with kernel bbhappen do_patch recipe"12:27
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC12:29
*** alinucs <alinucs!> has quit IRC12:33
RPkanavin: thanks12:36
kanavinRP: removing _remove is actually tricky, can you give me a suggestion? I'd like to ensure that gtk+ is not in the final value, but it seems impossible to override what is set in local.conf, other than through use of _remove12:36
kanavinyacar_, that should be looked at by Paul Eggleton12:37
LetoThe2ndkanavin: already poked him couple of days back, probably he forgot again :/12:37
*** agnem <agnem!> has quit IRC12:41
yacar_kanavin : do you have Paul's email address ?12:42
LetoThe2ndyacar_: its easy to find on the ML, and he's here as bluelightning. but just offline, due to timezone12:43
RPkanavin: hmm, that is harder than I was initially thinking12:53
kanavinRP: we can drop the qemu related bits from local.conf altogether, and enable gtk+ directly from the recipe12:53
RPkanavin: this is something users may want to configure12:54
RPkanavin: perhaps remove is the right thing :/12:54
RPkanavin: it would only become a problem if someone works on enabling gtk on mingw/darwin12:54
kanavinbut then they would adjust the recipe as a part of that12:55
kanavinto not do the remove12:55
* RP just reran a-full and its nearly completed in less than 1 hour 50 minutes with hot sstate12:55
RPremaining bits are ptest, mips, mips64 and qemuarm12:56
RPthat is a pretty amazing build time12:56
kanavinRP: yeah, I was going to ask if we really need to run those very long mips target tests, or make them shorter somehow12:58
RPkanavin: we already did cut a few out12:58
RPkanavin: actually, I'm not sure you do need to change PACKAGECONFIG for mingw from local.conf12:59
RPkanavin: if the user configures gtk+ into a mingw build that is their own fault12:59
kanavinRP: but it's set for all nativesdk variants from local.conf12:59
kanavinand uncommented by default, which will break things on mingw13:00
black_13ERROR: ParseError in configuration INHERITs: Could not inherit file classes/package_rpmpackage_ipk.bbclass13:00
black_13what is this error from13:00
RPkanavin: hmm, I was thinking mingw has its own namespace but you're right13:00
RPblack_13: misset PACKAGE_CLASSES variable (missing space)13:01
kanavinRP: you can give it special treatment via PACKAGECONFIG_mingw32_class-nativesdk though, but it would further bloat local.conf, and really shouldn't belong there13:01
RPkanavin: right, that is a level of ugliness the user doesn't need13:02
black_13this is my local.conf :
black_13PACKAGE_CLASSES ?= " package_rpm"13:08
*** gtristan <gtristan!~tristanva@> has quit IRC13:09
RPblack_13: I strongly suspend something is appending to that without a space13:09
*** gtristan <gtristan!~tristanva@> has joined #yocto13:12
black_13how do you instruct bitbake to use on the ipk package format and install the package manager13:15
black_13what bothers me is i had this working13:15
RPblack_13: the problem is those last two lines. Why not just set PACKAGE_CLASSES = "package_ipk" ?13:21
RPblack_13: PACKAGE_CLASSES_append = " package_ipk" (with a space) would have worked13:22
black_13i will check13:23
black_13ok its bitbaking lets see what happens13:24
black_13still buiding PACKAGE_CLASSES_append = "package_ipk" PACKAGE_CLASSES_remove = "package_rpm"13:29
black_13sorry it is still build the rpm package manager13:29
LetoThe2ndblack_13: whats wrong with setting PACKAGE_CLASSES ?= "package_ipk"13:32
LetoThe2ndor even more directly PACKAGE_CLASSES = "package_ipk"13:32
black_13i did that i believe13:32
LetoThe2ndprobably not, then13:33
LetoThe2ndbitbake -e $WHATEVER | less, and then search for PACKAGE_CLASSES13:34
*** dev1990 <dev1990!> has quit IRC13:35
*** lexa_` <lexa_`!~user@> has joined #yocto13:37
LetoThe2ndblack_13: then chances are that something that you do need rpm for other reasons13:39
black_13it use rpm for other reason but will also have ipk packages available13:40
LetoThe2ndis that a statement or a question?13:41
*** gtristan <gtristan!~tristanva@> has quit IRC13:43
black_13a statement13:52
Piratyyocto being really late to the p3 party yes?13:52
black_13you are saying that though it may build the rpm package management system it will have ipkg files available for use13:52
LetoThe2ndblack_13: no, thats not what i am saying.13:53
PiratyLOL it needs both py2 and py313:53
LetoThe2ndblack_13: i am saying that when you have package_ipk as the package_class, then this is what it will use to build the image and to provide packages.13:54
LetoThe2ndblack_13: there can be packages that require the rpm tooling for other reasons, but that doesn't affect the image building and packaging process then.13:55
lexa_`Hi, I have a problem with Yocto, I'm not sure how to approach. I want to build a13:55
lexa_`few Yocto images, which are 99% identical, except for the couple of packages.13:55
lexa_`Usually, I want to install one or two extra packages.13:55
lexa_`I want to save some space on multiple rootfs images. Is there some way to produce one 'base' image and them install rpm package in the image on the host?13:55
black_13LetoThe2nd: your correct i see multiple ipk files present in ./build/tmp/deploy/ipk/all13:56
LetoThe2ndlexa_`: you can have a base image recipe, and 99 other recipes that jsut include it and extend it by one or two packages.13:57
lexa_`LetoThe2nd: But I don't want to build multiple images in Yocto. Maybe it is possible to install packages into pre-build rootfs?13:59
LetoThe2ndlexa_`: i don't get the point13:59
lexa_`LetoThe2nd: save some diskspace by having one big image + packages which could be installed when needed.14:00
LetoThe2ndlexa_`: you want yocto to create a base image, and then run a whatever-something that takes this image, and makes it into 99 other images that only differ by a handful of packages.14:00
LetoThe2ndlexa_`: i mean, you explicitly wrote "install rpm package in the image on the host"14:01
LetoThe2ndso there's no diskspace saving in any case.14:01
LetoThe2ndor did you actually mean to create a base image + a package feed, and then install the add-ons in the TARGET?14:01
lexa_`Usually, I don't want to have all images at the same moment, so I could have one base image and one base image with an extra package installed.14:02
lexa_`LetoThe2nd: I wouldn't like to install packages on the host, because it implies RW rootfs.14:03
*** gtristan <gtristan!~tristanva@> has joined #yocto14:03
LetoThe2ndlexa_`: so what would be the difference to bitbake'ing the base-image and the special image?14:04
LetoThe2ndlexa_`: so then this was a freudian error now, you meant "I wouldn't like to install packages on the target, because it implies RW rootfs."14:04
LetoThe2ndok, that makes perfect sense14:04
*** Pharaoh_Atem <Pharaoh_Atem!~neal@fedora/ngompa> has quit IRC14:06
lexa_`LetoThe2nd: The difference between base-image and a special image is that special image has a few packages extra.14:07
LetoThe2ndlexa_`: i understood that.14:07
lexa_`LetoThe2nd: So, what was the question 'so what would be the difference to bitbake'ing the base-image and the special image?'14:08
LetoThe2ndlexa_`: but i don't see what "diskspace savings" you expect. if you bitbake special-image which depends on base-image, then bitbake will literally build only what those two images need, and assemble them14:08
LetoThe2ndthe more they share, the better.14:08
*** black_13 <black_13!d106cd8b@gateway/web/freenode/ip.> has quit IRC14:08
*** Pharaoh_Atem <Pharaoh_Atem!~neal@fedora/ngompa> has joined #yocto14:09
JaMaanyone seeing illegal instructions from llvm when used with mesa on qemux86?14:10
JaMakanavin: for me qemu-native doesn't work with gtk+, but works with sdl2, so it might be useful for people to configure14:11
lexa_`LetoThe2nd: Oh, forgot to explain that. I didn't meant to save space in Yocto. I want to save space on the resulting images, because I have to share them over the Internt.14:11
LetoThe2ndlexa_`: sorry, but you're not making sense.14:12
LetoThe2ndlexa_`: if you have an image that you want to contain a defined set of things, where is the space saving opportunity?14:13
*** Bunio_FH <Bunio_FH!~bunio@2a01:4b00:874a:fd00:6809:184d:862f:1e01> has joined #yocto14:15
JaMakanavin: any link to upstream where it shows that sdl is deprecated in favor of gtk+?14:16
lexa_`LetoThe2nd: Compare: 5 images each 1Gb vs 1 image 1Gb + 5 packages of negligible size.14:18
lexa_`and I have to share these images over the network.14:18
lexa_`So, I'm not saving a diskspace, but a network throughput.14:19
LetoThe2ndlexa_`: ok. now i think i see the missing part. you mean, that you are kind of "development host 1". you produce the base image and feed and share it. "development host 2" receives things, and then creates the images. right?14:19
LetoThe2ndit would have been very helpful to mention that there are multiple "hosts". you did always only name "host"14:21
kanavinJaMa, I tried everything I could to make qemu work with sdl2, it would either refuse to start, crash on driver initialization or show a blank window when starting smth graphical14:21
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto14:21
lexa_`LetoThe2nd: sorry, I forgot to mention that fact.14:21
kanavinif you have a branch somewhere which works for you, with precise instructions, I could give it a try14:21
kanavinJaMa, sdl is deprecated in favor of gtk+ in poky distro14:22
LetoThe2ndlexa_`: in that case, i don't know of any fitting solution. you can of course provide a base image plus a package feed, but the re-packaging of the image is something you'd probably have to script yourself.14:22
JaMakanavin: "qemu: build target variant with gtk+, and nativesdk variant without sdl" this commit isn't poky specific and still it says sdl is deprecated14:27
lexa_`LetoThe2nd: I guest I'll to script image re-packaging.14:27
kanavinJaMa, which version of qemu is that?14:30
JaMathe prebuilt one is 2.7.014:30
JaMaI was using to build it with OE14:30
JaMabut my version of mesa-native was also depending on drm-native, so I wasn't using that much from host as your version14:31
kanavinyes, that was a trade-off in time needed to build all the drivers14:32
JaMaand my version still had some issues, like mesa loading the drm driver from the path in libdrm WORKDIR which of course didn't work after rm_work removed libdrm WORKDIR14:32
JaManow I've built your version with both sdl and gtk+ support so I should be able to test both just by changing -display parameter14:33
kanavinyep, if you can make sdl work, that'd be great14:33
JaMavirgl enabled qemu in gentoo has the same issue (sdl works and gtk+ doesn't)14:33
kanavinfedora and opensuse have the opposite problem14:34
kanavinubuntu doesn't have virgl enabled at all14:34
JaMabut there might be some new issue in either xubuntu (as guest) or newer qemu, because now with default display xubuntu fails to start graphics, it works only with passthrough gpu or qxl display (slowly)14:34
JaMaI have ubuntu packages rebuilt with sdl and virgl, but I haven't tried them with gtk display14:35
JaMaas in
JaMaah I didn't use GTK because "With GTK UI there are few more issues, the14:37
JaMaresolution isn't set correctly and the cursor isn't rendered inside QEmu14:37
*** Bunio_FH <Bunio_FH!~bunio@2a01:4b00:874a:fd00:6809:184d:862f:1e01> has quit IRC14:48
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has quit IRC14:55
*** jobroe <jobroe!~manjaro-u@> has quit IRC14:59
*** AndersD_ <AndersD_!~AndersD@> has quit IRC15:01
varjagi'm setting up my own distro, but when i bake virtual/kernel, it seems to ignore my preferred_provider15:03
varjaghow does one go about diagnosing that?15:04
LetoThe2ndvarjag: bitbake -e15:04
varjagi tried getting the dependencies graph for recipes, but it doesn't help15:04
LetoThe2ndvarjag: chances are that COMPATIBLE_MACHINE or such is off15:04
varjagthanks, it looks like my definition is getting overriden15:14
*** TobSnyder1 <TobSnyder1!> has joined #yocto15:14
*** TobSnyder <TobSnyder!> has quit IRC15:16
yoctiNew news from stackoverflow: Qt - Module "QtQuick.Controls" is not installed <>15:17
ernstpwhen is ${B} cleaned?15:19
ernstpif I do some file processing in there, should my recipe task start with a bunch of rm first, to not have stale files from the previous run?15:19
jofrThey stay there between runs, yes. In some cases you may need to remove stuff.15:25
*** mckoan is now known as mckoan|away15:26
jofrernstp: FWIW: I have a recipe that, among other things, creates a zip archive. When I originally created that recipe, I do recall that zip added my files into the old archive if they had a new name. So now I start by removing it so I don't have to do a -c cleanall before building that recipe.15:28
kergothdepends on the task being rerun15:28
*** rcw <rcw!~rcw@> has joined #yocto15:34
ernstpkergoth: if I trigger compile to rerun15:45
ernstpshould I always start with rm -rf ${B}* ?15:45
ernstprm -rf ${B}/*15:45
ernstpso what's the idea? :-)15:45
jofrOnly the build artifact that would be added to incrementally.15:46
*** varjag <varjag!> has quit IRC15:46
ernstpI discovered it because I had an intermediate file where I did >> instead of >15:47
jofrLet's say you have something that does an "echo sumfink >> somefile" in your recipe. If you run that build over and over again, your "sumefile" will contain lots of "sumfink"s.15:47
daniel-kHi! I'm trying to build an eSDK with SDK_INCLUDE_PKGDATA="1" and it keeps failing during populate_sdk_ext with "No such file or directory: '[...]/build/tmp/work/raspberrypi3-poky-linux-gnueabi/core-image-base/1.0-r0/recipe-sysroot/world-pkgdata/'" Any ideas?15:48
jofrSo in this simple example you have two options. Either have the first echo do an overwrite ">" or have a build-step that first does a: rm -f somefile and then does you append-stuff. You don't want to erase everything to get rid of a single file.15:49
ernstpjofr: when do you want to keep old stuff around in ${B}?!15:50
jofrWhen you build something more often than once in your lifetime.  ;-)15:50
ernstpa assume a cmake recipe that triggers do_compile nukes the build directory?15:50
jofrOnly if the upstream has changed and it needs to fetch again15:51
ernstpwell there's the ccache, and when I work on something I compile it myself. I didn't expect yocto to do dirty buidls15:51
ernstpI mean sstate15:52
ernstpok, fetch deletes B?15:53
*** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC15:56
jofrI believe it does. If I'm wrong, I hope someone will correct me on that?  :p15:56
jofrI've only used ${B} once and that was for a temporary workaround that I'm not even using anymore.15:58
*** lquirion <lquirion!> has joined #yocto16:01
*** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto16:01
ernstpI guess this ties in with "B: By default, this directory is the same as the S directory"16:02
ernstpcmake has rm -rf ${B} mkdir -p ${B} in do_configure16:03
*** TobSnyder1 <TobSnyder1!> has quit IRC16:04
jofrYes. But doesn't it only do a configure when it needs to fetch new sources?16:05
ernstpyeah I guess it's quite rare to only trigger do compile, perhaps mostly happens when developing a recipe itself16:06
*** lpapp <lpapp!~lpapp@kde/lpapp> has joined #yocto16:07
lpapphi, is this the syntax of fetching from a local repo on the machine? SRC_URI = "file:///home/lpapp/foo;protocol=file;nocheckout=1;branch=topic \16:07
*** stephano <stephano!~stephano@> has joined #yocto16:08
RPlpapp: for git, no16:09
RPlpapp: SRC_URI = "git:///home/xxxx;protocol=file"16:09
lpappoh ok, tried that, too, thanks16:09
kergothfile:// won't call out to git, it'll copy the file over16:10
lpapphmm, that may be good enough as well16:10
ernstpyou might think that git over ssh is ssh://path but it's git://path;protocol=ssh etc16:10
lpappwith git:/// -> unable to find revision16:10
lpappWARNING: Failed to fetch URL git:///home/lpapp/foo;protocol=file, attempting MIRRORS if available16:11
lpappERROR: Fetcher failure: Unable to find revision b9e8d459764b211392089f4ea04ce003229ae0b9 in branch master even from upstream16:11
ernstplpapp/foo/.git ?16:12
jofrlpapp: Try adding: SRCREV = "${AUTOREV}" and PV = "1.0+git${SRCPV}" (you may want a different PV though)16:13
jofrIf you want to use the latest head, that is.16:14
lpappno, it is not auto, sorry16:19
lpappit is not the latest, etc16:19
lpappso why is it failing to fetch given that git show b9e8d459764b211392089f4ea04ce003229ae0b9 is just fine in that local repo when I cd in?16:20
lpappif I specify the branch, it is "better"16:21
*** tprrt <tprrt!~tprrt@> has quit IRC16:30
*** tprrt <tprrt!~tprrt@> has joined #yocto16:32
*** dmoseley <dmoseley!~dmoseley@> has joined #yocto16:38
*** nighty- <nighty-!> has quit IRC16:41
*** mort <mort!~mort96@snow/mort96> has joined #yocto16:42
*** JaMa <JaMa!~martin@> has quit IRC16:43
ernstpso COPY_LIC_DIRS puts all the licenses that are part of the image on the target rootfs, but is there a method to get a bundle outside the target?16:46
ernstptmp/deploy/license/ just has licenses for everything compiled for some reason16:47
rburtonfor a good reason: everything that gets built puts the license in deploy16:48
rburtonjust like everythingt hat gets built put packages into deploy16:48
rburtonyou can use the image manifest to get the package names, so you know what bits of the license folder to pick16:49
*** yacar_ <yacar_!> has quit IRC16:49
ernstprburton: I mean everything compiled regardless of what triggered it :-)16:51
ernstpso it includes hosttools etc16:51
ernstpI'm thinking about stealing /usr/share/common-licenses from the target rootfs but that feels a bit backwards :-)16:52
*** frsc <frsc!~frsc@2003:a:e7a:6200:246c:2a8b:f45a:a33d> has quit IRC16:54
rburtonernstp: just copy what you need from deploy/licenses16:57
rburtonRP: alsa patch from tanu on the list if you didn't spot it16:57
*** dev1990 <dev1990!> has joined #yocto17:02
ernstprburton: i have to implement package to recipe mapping then, don't I have? feels like a lot of work duplication17:05
*** tprrt <tprrt!~tprrt@> has quit IRC17:05
rburtonernstp: oe-pkgdata-util can do that17:06
rburtoni even extended it recently to take a list for pretty much this purpose17:06
rburtoni'm assuming that license.bbclass can't generate a license manifest for you per-image17:07
rburtonmaybe it can17:07
*** sno <sno!> has joined #yocto17:07
rburtonalso ripping it out of the rootfs isn't that nasty tbh :)17:08
rburtonensure you have the rootfs as a tar.gz and then you can just tar them out17:08
rburtondo you actually what the license text, or just the names?17:09
ernstpmy idea was to do it in a postprocess hook and nuke them from the image17:09
ernstpI want the text17:09
rburtonif you don't want them in the image, don't put them in the image...17:09
ernstpyeah but that was the available method to get them collected per image :-)17:10
*** fl0v0 <fl0v0!> has quit IRC17:10
rburtonso i'd turn off license_image, then take the image manifest, turn each package into a recipe, and grab the files from deploy/licenses/[recipe]17:11
rburton$ oe-pkgdata-util lookup-pkg -r pkg [pkg ...]17:11
ernstplicense.bbclass has quite a lot of code...17:11
rburtonor was it lookup-recipe17:12
rburtonyeah license.bbclass is arguably over-engineered17:12
rburtonvisitor classes and what not17:12
rburtonno glory in rewriting something that works though ...17:12
ernstpcat tmp/deploy/images/machine/my-image-machine.manifest | awk '{ print $1 }' | xargs oe-pkgdata-util lookup-recipe | sort | uniq | xargs -i ls 'tmp/deploy/licenses/{}' -d17:14
ernstpls returns without any errors so that looks good17:14
rburtonthe long term fix would be to enhance imagelicence.bbclass so its behaviour is configurable: you want per-image license texts outside the image which is can almost but not quite do.17:15
ernstpthe usecase is: no UI on device, licenses go on homepage/companion app, which I think is quite common17:17
rburtonadd some toggles to the class17:17
ernstpLICENSE_CREATE_IMAGE_ARCHIVE or something17:18
rburtoni could see it writing a directory of the licenses under deploy/images/[image name]/17:19
RPrburton: I had, thanks17:19
RPkanavin: playing with virtgl locally, its not easy to use compared to sdl :(17:19
kanavinRP: how come?17:19
ernstprburton: right, then you can archive it however you like17:20
*** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC17:20
RPkanavin: I use X over ssh for example which no longer works :/17:20
RPkanavin: I also just tried egl-headless here and it seems broken :(17:20
kanavinRP: does the oe-selftest pass for it?17:21
ernstpI wonder if I have waited long enough to ping you about again... ;-)17:22
yoctiBug 12107: normal, Medium, 2.7, JPEWhacker, NEW , useradd-staticids: groupadd: GID already exists17:22
RPkanavin: its skipped, I'll retry with better permissions17:22
kanavinRP: you need /dev/dri/render* with appropriate permissions17:23
kanavinlexander@alexander-box:~/development/mbient-virgl/build-qemu-spark$ ls -l /dev/dri/17:23
kanavintotal 017:23
kanavindrwxr-xr-x  2 root root        80 Feb 21 19:18 by-path17:23
kanavincrw-rw----+ 1 root video 226,   0 Feb 21 19:18 card017:23
kanavincrw-rw----+ 1 root video 226, 128 Feb 21 19:18 renderD12817:23
RPkanavin: actually, X fails to start in my image with a GLSL compile failure :(17:23
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC17:24
RPkanavin: (with runqemu gl)17:24
kanavinRP: for me core-image-sato starts without problems, it adjusts to use Glamor X server automatically when it sees 'hardware' gl17:25
kanavinfor weston, you need to 'fix' the config file to use dri instead of fbdev17:25
RPkanavin: this was core-image-sato ;(17:25
*** WillMiles <WillMiles!> has joined #yocto17:27
*** sk_tandt <sk_tandt!> has quit IRC17:27
*** sgw <sgw!~sgw@> has joined #yocto17:31
*** berton <berton!~berton@> has quit IRC17:33
RPkanavin: the headless selftest passes but running it with runqemu just "hangs"17:41
RPkanavin: running the qemu command on the console I see errors to do with bad dri driver paths by the looks of it17:42
kanavinRP: you don't get anything when you connect to qemu with vnc?17:42
*** nerdboy <nerdboy!~sarnold@> has joined #yocto17:44
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has joined #yocto17:44
RPkanavin: there is no vnc to connect to, qemu dies afaict17:45
RPkanavin: I'm probably doing something wrong17:45
kanavinbut egl-headless only makes sense if you also enable vnc, if you actually want to see the output17:46
RPkanavin: right, it doesn't pass in that option though so I need to do that17:46
kanavinyes :)17:47
kanavinrunqemu kvm egl-headless publicvnc17:47
RPkanavin: its confusing as runqemu just appears to hang, bad error handling?17:47
kanavinit starts, but renders its output into nothing. if it has an ssh server, you can log into it.17:48
*** gtristan <gtristan!~tristanva@> has quit IRC17:48
kanavinpublicvnc option lets you see the output17:48
RPkanavin: here, if I run the qemu command from the console that runqemu claims to be running, I just get errors17:49
RPgbm: failed to open any driver (search paths /media/build1/poky/build/tmp/work/x86_64-linux/mesa-native/2_18.3.4-r0/recipe-sysroot-native/usr/lib/dri)17:49
RPkanavin: what is worrying me more is that a) the headless test passes and b) I'm not seeing errors from runqemu17:50
kanavinRP: runqemu does special magic to use the host dri drivers:17:50
kanavindripath = subprocess.check_output("PATH=/bin:/usr/bin:$PATH pkg-config --variable=dridriverdir dri", shell=True)17:50
kanavinos.environ['LIBGL_DRIVERS_PATH'] = dripath.decode('utf-8').strip()17:51
kanavinso I think it works as it should17:51
rburtonassuming host has libdrm-dev?17:52
kanavinrburton, yes17:52
RPkanavin: earlier it warned me about missing dri.pc, the reality was pkg-config wasn't installed :/17:52
RPkanavin: right, so my expectation of being able to copy and paste the command is now invalid17:53
*** lexa_` <lexa_`!~user@> has quit IRC18:16
*** andycooper <andycooper!uid246432@gateway/web/> has quit IRC18:21
*** gtristan <gtristan!~tristanva@> has joined #yocto18:30
*** armpit <armpit!~armpit@2601:202:4180:c33:70ef:357b:adf:5cc4> has quit IRC18:33
kanavinRP: fwiw, just tried core-image-sato here, plain gl works fine, egl-headless also works fine via vncviewer.18:44
*** armpit <armpit!~armpit@2601:202:4180:c33:5d2e:f64b:3649:ebdb> has joined #yocto18:45
*** T_UNIX <T_UNIX!uid218288@gateway/web/> has quit IRC19:10
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto19:11
*** lexano <lexano!> has quit IRC19:34
*** lexano <lexano!> has joined #yocto19:34
*** daniel-k <daniel-k!~daniel@> has quit IRC19:40
hugo___rburton: RP Sorry for late reply. I currently support multiple toolchains for multiple platforms in the embedded space. I currently update them when theres a bump in the Poky SDK, which sometimes means a change in specific compiler flags. Most of the time, its not really an issue, as the sdk stays consistent. The reason I do this is to let the developers use the same editor but switch toolchain and reconfigure Cmake.  We do not19:52
hugo___NEED to source for this to work. It would be great if yocto could export the toolchain in the setup step, as it now know the path of the sdk on the host.19:52
hugo___This is something I could do as a custom build step when we generate the sdk, just wondering before hand so I don't do unnecessary work :) Anyone have a pointer to the code where the current Cmake toolchain is compiled?19:54
*** ljp <ljp!~quassel@2001:8003:e043:6900:ba27:ebff:febb:59b> has joined #yocto20:01
*** lpotter <lpotter!~quassel@2001:8003:e043:6900:ba27:ebff:febb:59b> has quit IRC20:01
*** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto20:05
*** andycooper <andycooper!uid246432@gateway/web/> has joined #yocto20:07
*** dfaught <dfaught!~dfaught@> has joined #yocto20:57
*** rcw <rcw!~rcw@> has quit IRC21:01
*** lazyape <lazyape!> has quit IRC21:04
*** lazyape <lazyape!> has joined #yocto21:04
*** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC21:51
RPkanavin: I'm just not getting a good vibe about this being usable as it stands. I can't quite put a finger on why, just lots of odd things happening and things which don't quite work. Thinking we might mark this as experimental for 1.721:52
*** lazyape <lazyape!> has quit IRC21:56
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has quit IRC21:56
*** lazyape <lazyape!> has joined #yocto21:57
*** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto22:05
*** Crofton <Crofton!> has quit IRC22:08
*** Crofton <Crofton!~balister@2601:5c0:c100:b84:c22d:c40:ab44:9e37> has joined #yocto22:09
*** Klox <Klox!> has quit IRC22:09
*** mario-goulart <mario-goulart!> has quit IRC22:10
*** Klox <Klox!> has joined #yocto22:10
*** derRichard <derRichard!> has quit IRC22:10
*** mario-go` <mario-go`!> has joined #yocto22:10
*** derRichard <derRichard!> has joined #yocto22:10
*** lukma <lukma!> has quit IRC22:11
JPEWernstp: Sorry I missed your question on YOCTO #12107. I haven't had a chance to look at it yet :(22:11
*** lukma <lukma!> has joined #yocto22:12
*** mario-go` <mario-go`!> has quit IRC22:12
*** WillMiles <WillMiles!> has quit IRC22:12
*** mario-goulart <mario-goulart!> has joined #yocto22:13
*** ferlzc <ferlzc!~ferlzc@> has quit IRC22:16
*** ferlzc <ferlzc!~ferlzc@> has joined #yocto22:17
*** [Sno] <[Sno]!> has joined #yocto22:17
*** sno <sno!> has quit IRC22:20
*** [Sno] <[Sno]!> has joined #yocto22:21
*** gtristan <gtristan!~tristanva@> has quit IRC23:08
*** black_13 <black_13!927305a2@gateway/web/freenode/ip.> has joined #yocto23:16
*** nerdboy <nerdboy!~sarnold@> has joined #yocto23:16
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has joined #yocto23:16
black_13is tere something that is even smaller than core-image-minimal23:19
*** emg <emg!~emg@> has joined #yocto23:21
emgcan I enable two systemd services from one bb file? I added a second one to SYSTEMD_SERVICE_${PN} but that didn't seem to enable it23:22
*** ljp is now known as llornkcor23:30
*** llornkcor <llornkcor!~quassel@2001:8003:e043:6900:ba27:ebff:febb:59b> has left #yocto23:30
*** agust <agust!> has quit IRC23:35
khemyou can23:38
khemwhat does service look like ? is it there in image23:38
*** ferlzc <ferlzc!~ferlzc@> has quit IRC23:44
*** black_13 <black_13!927305a2@gateway/web/freenode/ip.> has quit IRC23:50
*** JaMa <JaMa!> has joined #yocto23:56

Generated by 2.11.0 by Marius Gedminas - find it at!