**** BEGIN LOGGING AT Thu Jun 29 03:00:02 2017 Jun 29 07:26:27 hello guys. I need a hint.. I've a yocto project structured as prj/poky /prj/layers prj/applications. now I have a custom recipe that must fetch the soruces folders and subfolders in prj/applications/app1 Jun 29 07:27:18 I've trie to add SRC_URI = "file:///home/myuser/prj/applications/app1/* " Jun 29 07:27:45 but doesn't seem correct.. How can I do that ? Jun 29 07:29:24 good morning Jun 29 07:30:07 eppak: no, you have to keep your sources locally into the recipe directory Jun 29 07:31:11 thank you mckoan ! Jun 29 07:31:59 so there is no way to have the custom applications sources outside the layers dir ? Jun 29 07:32:24 for the development time you can use EXTERNAL_SRC to archieve a similar effect, but usually the bast practise is to have the application in a seperate VCS repository that the recipe can then fetch. Jun 29 07:32:41 eppak: in this case you need to use http or git fetch Jun 29 07:32:44 http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#new-recipe-writing-a-new-recipe Jun 29 07:33:14 as now I have "gitted" my "yocto-project" Jun 29 07:33:56 every application folder under the prj/applications is a git repo itself Jun 29 07:34:22 eppak: packing the sources into the layer itself (or tightly coupling them) is a bad practise. well if every application is a proper git repo anyways, then just have the recipe fetch it. Jun 29 07:34:24 so I fetch the soruces using the git protocol within the recipe Jun 29 07:35:37 by the way since the applications folder is local, when I pull the main yocto project on gitlab Jun 29 07:36:12 I see that the folders under the prj/application folder is not browasable Jun 29 07:36:39 it seems not to add the git repos related to the applications sources Jun 29 07:38:48 eppak: no, every application folder under the prj/applications as a git repo itself is not what is expected Jun 29 07:39:14 eppak: have a look at other recipes as reference Jun 29 07:39:35 as long as prj itself is not under version control, its no problem Jun 29 07:40:11 the key point is that bitbake does not use the src in your manually tinkered application folder, but its own fetched state. Jun 29 07:41:35 mckoan as far I have understood I have three options.. have a tar.gz, have a git repos or put the sources in the recipes folder.. Correct ? Jun 29 07:41:53 LeoThe2nd the problem is that prj itself is versioned with git Jun 29 07:42:38 eppak: then you might want to read up on git submodules, but you're most likely to run into problems. Jun 29 07:43:06 I know and I think it too Jun 29 07:43:47 so I was thinking to remove versioning of the applications Jun 29 07:44:08 most people avoid such giant repositories by properly splitting up things, and then use some script or setup solution to recreate the build setup as needed. Jun 29 07:44:11 but then I can't fetch them Jun 29 07:44:21 like repo, for example Jun 29 07:45:22 as a workaround you can EXTERNAL_SRC, as i already said. but it will break the internal reproductibility of your builds, and probably slow down them too as everything get rebult all the time then. Jun 29 07:45:58 what do you mean for repo ? Jun 29 07:46:18 I'm interested in finding the best way to structure the project Jun 29 07:46:57 eppak: https://source.android.com/source/using-repo Jun 29 07:47:30 its a common option these days. you can find an example usecase in the fsl stuff Jun 29 07:49:37 ty LeoThe2nd. I'll give it a try Jun 29 07:50:53 here's how they do it: http://freescale.github.io/#download Jun 29 07:53:44 basically I have to create different git repositories Jun 29 07:54:01 and using repo to have them collected ? Jun 29 07:54:11 thats the common way of using it, yes. Jun 29 07:57:36 Ok.. it seems quite an option Jun 29 08:00:33 but if the applications begins to be many.. probably would be better to version only the applications folder instead of each one of its subfolder Jun 29 08:02:00 in such a case, I will be facing the same problem.. Jun 29 08:05:05 i don't see the point. basically everything you get from upstream is "one repository per application". Jun 29 08:17:50 LeoThe2nd I'm not quite an expert both and git and yocto Jun 29 08:18:51 as now I have more or less 10 applications under the applications folder and to have them bitbaked I have setup one local git repo for each application Jun 29 08:19:11 ok, so what? Jun 29 08:19:50 i don't see any problem. 10 application -> 10 git repos for them, and a layer that containes the recipes for it, 11th repo Jun 29 08:20:55 see, for bitbaking you do not need to checkout the 10 app repos. you only get the layer repo, rest all happens internally. Jun 29 08:22:58 i don't really want to upload 20 repos on gitlab Jun 29 08:23:25 it would be better to upload only the applications folder as one repo Jun 29 08:23:41 "i don't want to." Jun 29 08:23:43 why? Jun 29 08:24:46 glueing everything into on means that everytime you need to modify one thing, you need to download everything. plus, the commit history become totally meaningless for the applications Jun 29 08:24:56 not a good idea. Jun 29 08:24:57 correct Jun 29 08:27:44 but what about if the projects beacame to be more and with different applications Jun 29 08:27:46 I would have to face dozen of repos Jun 29 08:28:12 Is this acceptable ? I really don't now as I am pretty a newbie Jun 29 08:28:42 no the exact opposite. imagine you have application A, B, C, D, E. project 1 needs A, B, C - project 2 needs C, D, E Jun 29 08:29:28 eppak_: really bad idea. You can try with git submodules, nevertheless it remain a bad idea. Jun 29 08:29:47 if everything is glued up, each project needs to pull in 2 applications it doesn't need at all. and would even need to rebuild even if the needed application is unchanged. but there's no way of telling with one global commit history. Jun 29 08:29:50 in that case I agree with you Leto Jun 29 08:30:23 its really https://en.wikipedia.org/wiki/Divide_and_rule Jun 29 08:30:51 ty guys ! I've really appreciated Jun 29 08:31:06 one task should be handled by one application, one application goes into one repository. easy as that. Jun 29 10:19:28 hi guys. I'd like to add the build date to the PV of my image. Just adding ${DATETIME} worked i fido but now yields errors (hash mismatch) after updating to pyro. Is it possible some other way? Jun 29 10:58:27 hmm, the DATETIME variable is still documented as "The date and time on which the current build started". Yet I'm getting a new value every time the recipe is parsed/accessed. Is this a bug? Jun 29 11:06:26 mansandersson: it stays constant for any given execution of bitbake Jun 29 11:08:20 RP: that's what I thought too but adding it to my PV gives me all sorts of errors, among them hash mismatch for each task in my image recipe. Jun 29 11:08:50 mansandersson: in fido I suspect you might get an odd behaviour like errors if the date you parse on was different to the one you built on Jun 29 11:09:02 mansandersson: we found there were issues so we made the system more verbose about the errors Jun 29 11:09:29 mansandersson: DATETIME is still placed into generated image output files in master Jun 29 11:10:06 mansandersson: using it as PV is potentially trickier, I've not tried that Jun 29 11:10:12 RP: I guess it's this message you've added: When reparsing myimage.bb.do_image_qa, the basehash value changed from to . The metadata is not deterministic and this needs to be fixed. Jun 29 11:10:24 mansandersson: right Jun 29 11:10:37 RP: yeah, I've might have had errors in fido too but not known about them. Jun 29 11:11:18 mansandersson: its basically saying that the metadata it just parsed didn't match what was in the cache (which in this case it clearly doesn't match since DATETIME changed and PV changed) Jun 29 11:11:31 RP: the actual problem I'm trying to solve is that I have an AUTOREV packag in my image and I want each build of the image have a different version to indicate that there can be differences Jun 29 11:12:26 RP: I can override the image name and add DATETIME there but then the version written to my rootfs isn't the same as the one in the file name Jun 29 11:12:56 mansandersson: You might be able to do something like PV[vardepsexclude] = "DATETIME" Jun 29 11:13:11 I do worry about that just masking problems though :/ Jun 29 11:13:29 mansandersson: the other option is to force your recipe to reparse every time Jun 29 11:14:20 I think BB_DONT_CACHE = "1" in the recipe Jun 29 11:14:56 RP: okay. I'll try the BB_DONT_CACHE option and see where that gets me. Jun 29 11:15:03 big thanks! Jun 29 12:09:45 the latest versions of yocto use systemd, no? Jun 29 12:11:03 AFAIK they can, but they offer you a choice. Jun 29 12:11:06 depends on your distro config Jun 29 12:18:32 RP: just for info, BB_DONT_CACHE didn't work. I still get the same errors. Jun 29 12:19:44 mansandersson: :(. Not sure I understand why that didn't help without debugging it :( Jun 29 12:20:53 RP: I understand. I'll have to keep experimenting and see if I can find a workaround that's good enough. Thanks anyway Jun 29 12:31:30 does sbd. know what could cause 'No package X available.' after adding a cmake-package to CORE_IMAGE_EXTRA_INSTALL_append? it builds fine using bitbake X Jun 29 12:33:09 misspelled? recipe name instead of package name? Jun 29 12:34:51 ant_work: It's definitely not misspelled. how are recipe and package names defined? just via the names of the directories? I store it in meta-MYLAYER/recipes-NAME/X/X_1.0.bb Jun 29 12:38:44 RP: a workaround that seems to be working is this: I add a new variable to my image recipe IMAGE_PV="${PV}-${DATETIME}" which I add to my IMAGE_NAME and also prints to /etc/version in a POSTPROCESS_ROOTFS_COMMAND. I basically separates the bitbake build version and the perceived version by the user. Jun 29 12:40:04 mansandersson: that makes sense Jun 29 12:51:47 yoctoguest, I'm looking for th eentry in the Yocto manual, one mom :) Jun 29 12:52:05 basically you install the artifacts of a recipe Jun 29 12:52:19 whose names can vary Jun 29 12:54:42 ant_work: my recipes compiles using cmake, but only *.a files are being generated, no .so's or binaries. may that be a problem? Jun 29 12:55:29 it all depends on packaging Jun 29 12:55:58 well I don't do any packaging. I leave that to the cmake script Jun 29 13:03:26 I should check if cmake.bbclass does change this but normally .a files are packaged as staticdev Jun 29 13:04:37 check in WORKDIR and see the names of the packages Jun 29 13:04:43 and the split Jun 29 13:04:48 I think that the main package class is not created because there are no binaries Jun 29 13:04:54 after adding ALLOW_EMPTY_${PN} = "1" it compiled Jun 29 13:05:18 th eproblem is that staticdev depends on dev which depends on the main package Jun 29 13:05:32 for whatever reason Jun 29 13:06:04 it's hard for me without crystal ball ;) Jun 29 13:06:41 check that the recipes do inherit cmake Jun 29 13:06:48 they do Jun 29 13:06:49 as first Jun 29 13:06:51 ok Jun 29 13:07:24 then if you don't see custom do_install I'd say there should be no surprises Jun 29 13:07:44 somewhere FILES = or PACKAGES = is declared ? Jun 29 13:08:31 https://pastebin.com/HPBFy4H0 Jun 29 13:08:35 no it's not Jun 29 13:12:41 to me it looks like the build system creates X X-dev and X-dev recipes depending on the files being installed Jun 29 13:13:10 see, there is a (much more complicate) similar case Jun 29 13:13:11 fded4cf6a8c Jun 29 13:13:13 and for some magical reason X-staticdev depens on X-dev and dev depends on X Jun 29 13:13:31 opencv: fix packaging and install Jun 29 13:13:46 from which repo is thatg commit id? Jun 29 13:13:52 meta-oe Jun 29 13:14:12 https://tinyurl.com/y97lhrlp Jun 29 13:16:19 try to find an easier example of another cmake recipe :) Jun 29 13:18:51 well they just overwrite the file lists Jun 29 13:19:01 it's questionable if that's better Jun 29 13:19:15 yoctoguest: you should be able to set RDEPENDS_${PN}-staticdev = "" in the recipe Jun 29 13:20:20 is that the normal way to do things? because it sounds kinda weird to list every single file produced by cmake Jun 29 13:20:38 instead of letting bitbake do that Jun 29 13:28:06 yoctoguest, check out simpler ex. like meta-oe/recipes-graphics/openjpeg/openjpeg_2.1.1.bb Jun 29 13:33:41 "FILES_${PN}-dev += "${libdir}/cmake/*.cmake"" that certainly looks interesting. so the build system knows how to handle these files and doesn't just place them in the install dir? Jun 29 13:34:01 yoctoguest sounds like you need to read the bit of the manual about how install/package works Jun 29 13:36:40 rburton: I did(and still am) but it doesn't say anything about this Jun 29 13:37:17 tbh i can't understand what you're asking, what's the problem? Jun 29 13:38:25 well right now it's kinda solved/workedaround using two different possible solutions(thx btw), but the core problem was that there seem to be some weird dependencies between X, X-dev and X-staticdev Jun 29 13:38:42 and the FILES-line I just posted looks interesting/undocumented Jun 29 13:39:14 the files line is documented by virtue of being in cmake.bbclass Jun 29 13:39:27 it just puts the cmake library files into the right package Jun 29 13:39:58 the PN-dev -> PN etc depends are declared in bitbake.conf. typically, a -dev package is useless without the main package Jun 29 13:40:11 line 278 Jun 29 13:40:13 ie no point having libfoo.h if you don't have libfoo.so.1 to link against Jun 29 13:40:41 staticdev -> dev as staticdev will just contain .a. no headers, as they're in -dev Jun 29 13:40:59 *if* you have a package which is only a static library then feel free to redefine the defaults Jun 29 13:42:08 rburton. makes sense, but I fail to see any code/comments related to the FILES-line in cmake.bbclass Jun 29 13:43:01 yoctoguest: its bordering on self-explanatory. a comment would be "add $libdir/cmake/*.cmake to PN-dev" as they're for development purposes. Jun 29 13:44:04 the file cmake.bbclass doesn't contain the string "*.cmake" Jun 29 13:46:34 hm, so 1) i thoguht you were quoting from cmake.bbclass, and 2) i thought the class did that :) Jun 29 13:47:21 grep says it really should Jun 29 13:47:31 yoctoguest, grep for 'inherit cmake' and see, I think this is almost standard for libs Jun 29 13:47:39 rburton, ah :) Jun 29 13:47:51 so that FILES is just to put a development-time file in the development package Jun 29 13:47:51 * ant_work cannot grep atm Jun 29 13:54:56 well I'm actually using poky, so there may be a few differences Jun 29 13:57:28 poky is a demo distro, and a git repository combining bitbake+oe-core+meta-yocto. that class isn't poky-specific Jun 29 13:57:30 * kergoth yawns Jun 29 14:08:01 rburton: there ? Jun 29 14:09:50 RP: rburton: glibc trunk is getting frozen for upcoming 2.26 release today, and I have been testing builds locally, I can propose that for OE-Core and then do a small bump along the way until august when the final 2.26 release Jun 29 14:10:25 Here's a random thing, paged bitbake -e output with syntax highlighting: `bitbake -e | /usr/share/vim/*/macros/less.sh - -c 'set ft=bitbake fdl=99'` Jun 29 14:11:06 hmmm Jun 29 14:11:10 khem: that would seem to fit with our release schedule... Jun 29 14:11:17 RP: OK Jun 29 14:11:39 kergoth: interesting. I wonder how that works with the pagination patch I just saw... Jun 29 14:11:40 then I will send a pu for glibc 2.26 tomorrow after freeze Jun 29 14:12:09 I also wish that we could highlight the compiler errors in logs Jun 29 14:12:11 khem: do we need to be careful with the version? 2.26~rc or something? Jun 29 14:12:17 RP: should be fine, afaik that patch should avoid its own paging when stdout isn't a tty, to run it this way, or presumably it'd obey PAGER so you could let it do it that way.. Jun 29 14:12:22 though i haven't read the patch thoroughly Jun 29 14:12:33 kergoth: I've mixed feelings on that patch Jun 29 14:12:57 RP: I think it should be ok to call it 2.25.90 may be Jun 29 14:13:29 RP: although I am waiting on the PIE rework to go in first Jun 29 14:13:34 yeah.. generally I'm in favor of auto-paged command output, but bitbake is a little different than most, given the multiple purposes of the different arguments, and knotty is rather more interactive than commands that usually page.. but at the same time, there's a clear value add Jun 29 14:13:43 since all my testing is happenin on top of that Jun 29 14:13:52 khem: I think we're strill struggling to get that to build cleanly on the ABs Jun 29 14:14:12 I am trying to reproduce but if you have pointers Jun 29 14:14:25 kergoth: right, its not clear cut. I do know who'll end up getting the bug reports though :( Jun 29 14:14:27 on AB to take a look at errors it will help me Jun 29 14:14:39 I have not managed to reproduce it locally Jun 29 14:14:43 khem: rburton has been handling it, not me Jun 29 14:15:25 he mentioned that bitbake -ctestimage core-image-sato-sdk fails Jun 29 14:15:43 but I have tried it on qemux86_64 and qemux86 Jun 29 14:15:54 it passed Jun 29 14:20:19 kergoth : Is it you that played with boot2qt? Jun 29 14:24:15 ChrysD_: it was kanavin (who seems not to be here atm) Jun 29 14:24:25 bluelightning : oh yeah Jun 29 14:24:39 bluelightning : I'm trying to understand what exactly it is... Jun 29 14:28:46 how can I pass runqemu arguments when doing bitbake -ctestimage ? Jun 29 14:28:56 I want to pass kvm option Jun 29 14:57:32 RP: here are latest run this morning http://sprunge.us/ENAM Jun 29 14:58:09 this is on qemux86 Jun 29 15:19:00 ChrysD_: irc disonnected, did you get more understanding of boot2qt? Jun 29 15:19:10 ChrysD_: yes it was kanavin, but he's on holiday now Jun 29 15:21:31 rburton: I pasted my results here http://sprunge.us/ENAM while you were disconnected Jun 29 15:25:48 i think the irc client is really dumb and doesnt' stop deep sleep Jun 29 15:27:59 khem: i'll pull your branch and try again now Jun 29 15:33:43 rburton: I am proposing glibc 2.26 as well later tonight which might be the difference Jun 29 15:34:11 yeah Jun 29 15:36:33 rburton: try once Jun 29 15:36:45 otherwise I will prepare another pull for glibc 2.26 Jun 29 15:37:09 although that will require the other pull for kraj/pu I sent last night Jun 29 15:47:37 khem: did you push? the hardening branch mail says 10 patches but branch says 9 Jun 29 15:48:06 ah the iptables patch is in master-next Jun 29 16:11:28 hello guys.. anybody know how to debug a: segmentation fault (core dumped) on yocto ? Jun 29 16:12:26 I've the same sources compiled natively on the same architecture with the same libraries and it runs like acharm Jun 29 16:12:59 but with its default distribution Jun 29 16:15:08 RP, bluelightning, rburton: Any thoughts on including something like https://gist.github.com/kergoth/cbc491a9d1f0d5489dab1e02d5adcd19#file-unpack_templates-bbclass in oe-core? It's a file templating mechanism, any .bbin file in SRC_URI gets processed by expanding bitbake variables in the file and writing the result to a new file in WORKDIR. For any file:// files, it parses it at parse time to add extra vardeps based on the vars it references Jun 29 16:15:36 extremely simple, but could be of use Jun 29 16:16:17 kergoth: can you give an example of where you'd use this? Jun 29 16:16:39 that gist actually includes the example :) Jun 29 16:17:05 sw-description needs to include the image filename for swupdate, so the new image type uses a template for it Jun 29 16:17:14 https://gist.github.com/kergoth/cbc491a9d1f0d5489dab1e02d5adcd19#file-image_types_swu-bbclass-L79 Jun 29 16:17:51 ah, reading comprehension fail, sorry Jun 29 16:18:03 hmmmmm Jun 29 16:18:06 it disables the unpack-time processing in favor of a prefunc on do_image_ext3 or the like, though Jun 29 16:18:26 not sure how useful it'd be for other recipes, since it hasn't been available for use Jun 29 16:18:30 would solve the mess of sedding paths in do_install Jun 29 16:19:08 but consider how common it is to replace ${datadir} and crap. i wouldn't want to blindly run it on arbitrary upstream files, due to the bitbake variable reference syntax being the same as shell, but for config files and startup scripts we supply, it could be useful Jun 29 16:19:37 could always change the template syntax to align with autoconf or something instead, but i think having some form of templating mechanism out of the box would be a good thing Jun 29 16:20:22 rburton: indeed Jun 29 16:21:48 figured i'd run it by you guys to see if it's completely crazy before i open an issue in bugzilla Jun 29 16:22:11 or a mailing list thread to bikeshed syntax, or both Jun 29 16:22:13 :) Jun 29 16:22:41 don't see anything using process_templates() in the sample, was that added for completeness? Jun 29 16:23:32 i actually quite like it Jun 29 16:23:53 yeah, it was a thought when i prototyping, and didn't end up using it for anything Jun 29 16:24:12 but i was thinking a variable could add those, to make it even more generic, so both a .bbin in SRC_URI would be processed along with anything extra Jun 29 16:24:25 could supply e.g. random files in S and then use the processed version in do_install Jun 29 16:24:28 * kergoth shrugs Jun 29 16:29:45 i wonder how much work it'd be to add bitbake file format highlighting to an existing highlighting project, i.e. pygments Jun 29 16:30:10 kergoth: not hard surely Jun 29 16:30:19 the atom formatting isn't bad Jun 29 16:30:30 yeah, that's what i was thinking. could actually highlight bitbake -e out of the box :) Jun 29 16:30:50 shame nobody published a many-major-modes thing for emacs so it knows to switch to python mode in python blocks and shell model in shell blocks Jun 29 16:31:38 hmm, yeah, i'm glad vim handles the different highlighting in the blocks, but it'd be nice to have smarter indenting and folding within them too Jun 29 16:33:39 emacs's mmm can do that but its a mare to setup Jun 29 16:34:53 Hmm, it'd be interesting to add a vim completion plugin and shell completion for the bitbake command that actually communicates to a running bitbake memres server to see what's available :) Jun 29 16:34:58 Jun 29 16:35:00 is there an easy way to determine why bitbake chose a certain version of a package? Jun 29 16:35:46 it's currently ignoring a more update-to-date version in favour of an older one. grep didn't return any preferred version related stuff Jun 29 16:36:39 T_UNIX: other possibilities: one of them might be skipped, i.e. due to COMPATIBLE_HOST or COMPATIBLE_MACHINE or whatnot, or one might define DEFAULT_PREFERENCE, or even more likely, layer priorities are a factor Jun 29 16:36:56 an older version in a highier priority layer will be used in preference to a higher version in a lower priority layer, by default Jun 29 16:37:17 no good way to ask bitbake why, but -v or -ddd might show messages about it Jun 29 16:37:22 kergoth: okay. will have a look Jun 29 16:37:24 er, -DDD Jun 29 16:38:42 i just got bit by that the other day in meta-mentor, i accidentally had an old recipe in meta-mentor-staging, which resulted in it being used by default when we didn't want it to be, since that layer is high priority to ensure our bugfixes are applied. moved it to our support layer where we add our extra recipes instead, which is quite low in priority Jun 29 16:38:54 my mistake, of course, just didn' tspot it righ taway Jun 29 16:54:10 kergoth: weird thing is: I grepped for that specific version without any results :-/ Jun 29 16:55:30 rburton: yes, the branch is rebased on latest master it say 9 because 1 patch got merged in master Jun 29 16:55:35 the pull was sent before Jun 29 16:59:44 kergoth: just cloned your vim-bitbake project, sorry the for the noob question...but how can I install it? :) Jun 29 17:00:16 that depends Jun 29 17:01:04 you can copy it all to .vim, or you can use pathogen, or you can use one of the many vim plugin/bundle managers Jun 29 17:01:47 can google for vim plugin management to see some of the options Jun 29 17:01:58 assuming you arent' using something already, of course Jun 29 17:02:44 kergoth: thank you. I use vim everyday but never used a single plugin..maybe I should Jun 29 17:04:29 anyway for now I think I'll go for the copy to .vim Jun 29 18:26:37 Hello - is there a way to customize the filesystem layout on the .hddimg file for a live image? Jun 29 18:27:32 I'd like to leave it as FAT, but put all the files into the /EFI/BOOT folder. Jun 29 19:45:52 hello! when i try to run oe-selftest, i get this error: 2017-06-29 12:41:16,633 - oe-selftest - ERROR - Please unset SANITY_TESTED_DISTROS in order to run oe-selftest Jun 29 19:46:05 it just told you what to do Jun 29 19:46:07 idk how or where i would unset SANITY_TESTED_DISTROS Jun 29 19:46:24 conf/local.conf, as you'd set nearly any other local build variable? Jun 29 19:46:34 ah, thanks Jun 29 19:47:44 so, it's not set in conf/local.conf Jun 29 19:47:54 correct, your distro sets it Jun 29 19:48:21 so your options are using a different distro, or overriding it in local.conf, with or without an override. if the distro is setting it without ?=, then setting it without an override won't do the job, but try that first. Jun 29 19:52:09 kergoth, thanks for your help. setting `SANITY_TESTED_DISTROS = ""` did the trick Jun 29 19:52:13 np Jun 29 20:30:31 Dear All, Jun 29 20:30:31 Maybe somebody knows how to tackle this issue: Jun 29 20:30:31 https://patchwork.freedesktop.org/patch/157889/ Jun 29 20:33:20 tackle what issue? Jun 29 20:33:24 that's a patch, not a bug Jun 29 20:34:44 IMHO it is a problem Jun 29 20:35:07 because this patch was rejected by Mesa and Weston community Jun 29 20:35:36 and OE builds this packages if on Host PC you have /usr/bin/wayland-scanner installed Jun 29 20:35:41 if not - then build breaks Jun 29 20:35:54 no matter if you have wayland-native installed or not Jun 29 20:36:15 ah, right Jun 29 20:36:20 can you file a bug please, because our patches should fix that Jun 29 20:36:31 that thread is about upstreaming a fix so we don't have to patch Jun 29 20:36:36 but we already patch Jun 29 20:38:56 rbutton: I'm affraid that my parsing stopped on "fill a bug report" Jun 29 20:39:09 do we have a patch/workaround for that or not? Jun 29 20:40:25 you just said the build breaks. if that's the case with current master, then open a bug Jun 29 20:40:41 kregoth: Ok. Jun 29 20:54:06 khem: your series is doing "qemux86-64 klogd: Cannot find map file." again, see the yocto.io autobuilder Jun 29 21:54:08 Has anyone out there successfully built oe/poky using Windows Subsystem for Linux? I got the build to start, but I had to build in /mnt/e since I didn't have enough space in my C drive, so I ran afoul of filenames with ":" in them. Jun 29 22:24:03 hmm, qtdeclarative-plugins no longer exists, but the packagegroups still refer to it Jun 29 22:24:06 * kergoth scratches head Jun 29 22:24:30 * kergoth checks for local changes that might do it Jun 29 23:14:02 hmm, slightly annoying that there's no way to locally alter the default IMAGE_FSTYPES for a given machine in local.conf. unless it uses ?=, as if you use an override, it hoses any images that explicitly set IMAGE_FSTYPES, since it overrides those Jun 30 01:25:57 hi folks, is the ROS operating system still supported by yocto? Jun 30 01:27:29 * kergoth has no idea what that even is Jun 30 01:28:29 Robot Operating System Jun 30 01:30:28 https://en.wikipedia.org/wiki/Robot_Operating_System Jun 30 01:31:10 evidently kergoth doesn't support it :) Jun 30 02:52:31 wic seriously doesn't let you switch bootloaders for a pcbios-style image? Jun 30 02:52:40 it hardcodes stuff in so many places, it's mind-boggling **** ENDING LOGGING AT Fri Jun 30 03:00:03 2017