**** BEGIN LOGGING AT Wed Jun 29 02:59:58 2016 Jun 29 06:13:12 pohly, hi... so I'm taking back what I understand from how yocto builds things to the team and suggesting alternative approaches based on that; it could very well be that I am wrong so just trying to verify some things Jun 29 06:14:02 One fellow mentioned that I should be able to accomplish this with bin_package recipes as such: https://paste.fedoraproject.org/386178/46718063/ ... but I think this is naive Jun 29 06:14:53 (i.e. accomplish rooting the whole build against an existing set of rpms using yocto and build the rest of the middleware/apps against this root also using yocto) Jun 29 06:16:47 My understanding is that the bitbake classes are tightly coupled with the recipes used to build/install the build tooling, and at best you might end up with a staged sysroot based on a set of rpms, but then have the yocto built versions of build tooling Jun 29 06:17:51 and at some point, this will bleed into the build either by way of indirect dependencies, or just by way of not using the same build tooling to build the upper levels Jun 29 06:19:07 gtristan: I agree, this sounds like a giant hack. It might work or it might not. Jun 29 06:19:38 sorry work calling, thanks pohly Jun 29 07:47:24 good morning Jun 29 07:49:06 well, we'll see what russell thinks about it Jun 29 07:49:14 raah Jun 29 07:49:24 wrong windows :) Jun 29 07:54:04 windows? yocto here! :D Jun 29 08:30:10 Can I tell yocto to ignore a recipe if a certain layer it depends on is not available? Jun 29 08:34:01 you can structure a layer so that parts of it are ignored, yes Jun 29 08:35:15 frsc: i think meta-fsl has a good example of how its done Jun 29 08:35:36 it has a bbappend for some web-browsers that are loaded only if meta-browser is available Jun 29 08:39:24 boucman_work: I can see the "browser-layer" directory in meta-fsl-arm. But how is it linked to meta-browser? Is it just the dir name? Jun 29 08:40:11 *-layer depends on meta-* ? Jun 29 08:41:13 frsc: yes, see meta-fsl-arm/conf/layer.conf Jun 29 08:41:17 at the very bottom Jun 29 08:42:07 boucman_work: aha, ok. Now I see how it works. Jun 29 08:42:23 Thanks rburton and boucman_work! Jun 29 08:44:39 not exactly directory-name based, it uses the collection name Jun 29 09:05:45 how can i build a meta- for a new board? i use the 'yocto-bsp' script to build a meta-* layer and write a u-boot.bb file in recipes-bsp, but that seems not work. Jun 29 09:07:24 define "seems not work" Jun 29 09:07:29 did you switch your machine in local.conf? Jun 29 09:09:23 yes, i dit. and i add the meta-* to the bblayers.conf file also Jun 29 09:09:37 ls Jun 29 10:13:56 Hello, possibly stupid question. What is the best approach to make a post-installation script to run on first boot? I use systemd and consider writing a simple service that disables itself, like in the opkg-configure.service Jun 29 10:18:17 write a service that has a precondition of a file existing or not-existing and have the service create or remove said file? Jun 29 10:20:11 yes, that's another option, not sure if it's better or not. I think I'm bikeshedding this issue anyway Jun 29 10:21:14 I wouldn't worry about it too much. Jun 29 10:22:02 mathieu2: give the package that ships the service a post inst that refuses to run at rootfs time and then does its job and deletes itself Jun 29 10:24:33 mathieu2: see pkg_postinst in the yocto mega manual, it explains how to do that Jun 29 11:34:13 thanks, I think it's the easiest path Jun 29 13:33:41 Hi, I'm having problem compilling QtWebEngine (using meta-qt5), I get the following error: Jun 29 13:33:57 ui_delegates_manager.cpp: In member function 'void QtWebEngineCore::UIDelegatesManager::showColorDialog(QSharedPointer)': Jun 29 13:33:59 ui_delegates_manager.cpp:346:34: error: invalid use of incomplete type 'class QColor' Jun 29 13:34:01 if (controller->initialColor().isValid()) Jun 29 13:34:33 "incomplete type 'class QColor'" - am I missing some library? Jun 29 13:35:09 > guessing this is the right place to ask Jun 29 13:39:52 it seems that the QColor is not included in delegates_manager.cpp Jun 29 13:40:28 I suggest you to run bitbake -c devshell and change the code by hand Jun 29 13:40:35 and find out what is missing Jun 29 13:41:58 Okay, thanks I'll try Jun 29 15:20:35 armpit: around? Jun 29 15:21:13 armpit: the last krogoth-next build looked pretty good, really need to sort out review/merge of that? Jun 29 15:55:49 RP, yes Jun 29 15:57:12 RP, parts have been reviewed Jun 29 15:57:28 I am having trouble locating this: does anyone know how I would remove a PNBLACKLIST from something with a BBAPPENDS? Jun 29 15:57:37 as they where part of other pull requests Jun 29 15:59:45 from "musl: Create symlinks for stub libraries" commit is the newer stuff Jun 29 16:01:49 armpit: and everything was in master already? Jun 29 16:03:16 WarheadsSE: I don't think you can do it with a bbappend, it's .conf level Jun 29 16:03:28 yes Jun 29 16:05:34 * armpit needs to my modify work flow Jun 29 16:06:11 fredcadete: https://github.com/OSSystems/meta-browser/blob/master/recipes-mozilla/firefox/firefox_38.7.1esr.bb#L122 is where my source problem is. Jun 29 16:07:16 WarheadsSE: oh, I did not know you could do that in a .bb Jun 29 16:07:59 I hadn't before either. Jun 29 16:15:13 WarheadsSE: the question would then be if you can remove a flag from a variable Jun 29 16:15:28 I don't know if it's possible Jun 29 16:41:49 freanux: it doesn't seem it is possible Jun 29 16:42:38 I have tried PNBLACKLIST_remove (didn't expect it to work), and an anonymous python function that called d.delVarFlag('PNBLACKLIST','firefox'). neither worked. Jun 29 16:42:55 PNBLACKLIST[firefox] = "" Jun 29 16:43:21 horribly, that might work, not that it _should_. Jun 29 16:44:01 (logically, it doesn't make that much sense, but) .. looking at the blacklist.bbclass, I can't say for sure if it will. Jun 29 16:44:36 I'll let it compile before I go punching it in the face again. (manually edited the recipe for now) Jun 29 17:00:12 zeddii: Are you there? Jun 29 17:01:26 RP: the musl bits are acked by khem as well Jun 29 17:04:43 zeddii: we are trying to boot a qemu a9 machine without much luck; the board is stuck and prints nothing. Are you using it with the 4.4 kernel? Jun 29 17:04:43 otavio: yes, looking at krogoth now Jun 29 17:05:47 RP: if there is any issue please let us know; I am using it here so I can test Jun 29 17:11:21 otavio: prepping FF esr 38.8.0, despite the blacklist of FF for gcc-6 Jun 29 17:33:03 fray: .. Yeah, horribly, that does seem to work. Jun 29 17:34:50 that is the design.. if the reason is 'blank' then it's not blacklisted Jun 29 17:39:03 otavio, sorry. distracted a bit today. I haven't booted it in a bit. let me find all the old conrfigs. Jun 29 17:39:42 zeddii: I figured; it requires the dtb file and runqemu does not have support for it Jun 29 17:40:00 zeddii: I mapped it for qemuarma9 kmachine Jun 29 17:40:27 WarheadsSE: no worries; did you try to upgrade it for a next esr? Jun 29 17:41:12 That's what I am doing, but I don't have an active master tree in my build farm at the moment Jun 29 17:41:14 zeddii: are you using the runqemu utility? Jun 29 17:41:29 WarheadsSE: I can ask berton to give it a go Jun 29 17:41:40 otavio: DIT won't be moving to the ESR 45's until September Jun 29 17:41:54 at the time, there were patches for it but largely it was launched via some other wind river scripts. Jun 29 17:43:17 zeddii: it is clear that qemuarm config and qemuarma9 configs are not that close; the later does not support virtio, for example Jun 29 17:44:18 WarheadsSE: you can coordinate with berton for test Jun 29 17:44:38 K, I will pop the PR up on github shortly Jun 29 17:47:35 Up Jun 29 17:51:11 WarheadsSE: DIT? Jun 29 17:53:54 otavio: my apologies, Devon IT Jun 29 17:54:16 WarheadsSE: Wouldn't be better to do the change now? Jun 29 17:55:50 otavio: I can't move from 38.x ESR to 45.x ESR at the moment due to release requirements and stability on the API that i don't have time to check between now and friday Jun 29 18:01:12 WarheadsSE: ok; so after we merge this would you mind work on an upgrade for next week or so? Jun 29 18:01:32 I can work on that in ~ 2 weeks, yeah Jun 29 18:01:36 WarheadsSE: ok Jun 29 18:02:18 zeddii: the qemuarmv6 and qemuarmv7 runqemu options seem to be unused at all Jun 29 18:33:14 I'm trying to build a kernel for a board using linux-yocto, and I'd like to use a newer patchset than the default 4.4.3 in krogoth. In my layer I set SRCREV_machine_{machine} = "hash-for-4.4.13" and LINUX_VERSION_machine_{machine} = "4.4.13". The SRCREV override works, but the LINUX_VERSION one doesn't. When building it still says 4.4.3. Jun 29 18:33:34 if I set LINUX_VERSION = "4.4.13" in my .bbappend, it works as expected Jun 29 19:15:28 g Jun 29 19:15:53 h Jun 29 19:30:13 i Jun 29 19:46:55 Hello Everyone Jun 29 19:47:30 in my core-image-minimal , the system boots up into a bash command prompt to enter the username Jun 29 19:47:43 how can i set a default username and password Jun 29 19:48:07 other than root onto the system Jun 29 19:48:19 that has root privileges and deactivate root Jun 29 19:48:34 should i create .bb file for that in one of my layers Jun 29 19:48:47 and in do_install script , should i write some bash script in there Jun 29 19:49:02 or which method override , should i write the commands , and , which commands ! Jun 29 19:54:38 snouto: see http://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#ref-classes-extrausers Jun 29 19:56:25 ntl: thanks , one more question , how can i make the prompt once successfully user logs in , a specific executable to run Jun 29 19:56:36 instead of going directly to the home bash prompt Jun 29 19:59:08 .bashrc ? Jun 29 19:59:47 you want to set the account's shell or modify the prompt? Jun 29 20:00:09 Once , the user logs in successfully the user should be prompted with a specific program prompt Jun 29 20:00:13 instead of Jun 29 20:00:16 ~# Jun 29 20:00:18 to be Jun 29 20:00:30 ~SomeProgram> Jun 29 20:00:48 then he can write help like Jun 29 20:00:55 ~SomeProgram>help Jun 29 20:01:07 then display help parameters for the specific program prompt Jun 29 20:02:04 just make the user's login script (.bash_profile) run that program Jun 29 20:26:48 Hi. what are these -native recipes which are being built? Jun 29 20:27:29 Guest11734: they provide tools to run on the build host that will be used as part of the build process for other recipes Jun 29 20:28:50 If I write recipe abc.bb with BBCLASSEXTEND = "native". Will it be shown as abc-native during build? Jun 29 20:29:17 @bluelightning Jun 29 20:35:38 Guest11734: yes, an abc-native variant will be created by doing that Jun 29 20:35:55 the stranger thing with the LINUX_VERSION issue I was talking about before is that if I set LINUX_VERSION = "4.4.13" in my linux-yocto_%.bbappend file, then bitbake stops loading linux-yocto_4.4.bb and instead loads linux-yocto_4.1.bb Jun 29 20:36:22 bluelightning Thanks :) Jun 29 20:36:49 if I remove that line from the .bbappend file, then it loads linux-yocto_4.4.bb as before Jun 29 20:37:38 m2: that's probably because PV gets set to include the value of LINUX_VERSION, and somewhere you will have a PREFERRED_VERSION_linux-yocto = "..." where 4.4.13 doesn't match that Jun 29 20:37:58 m2: so you need to also change PREFERRED_VERSION_linux-yocto in your configuration Jun 29 20:51:48 hmm... ok. Jun 29 20:52:06 the bit I don't get is why setting LINUX_VERSION changes the version of the recipe that gets used... Jun 29 20:52:37 I have PREFERRED_VERSION_linux-yocto = "4.4%" Jun 29 20:53:23 and the only instance of something different that I can find is: Jun 29 20:53:25 meta-poky/conf/distro/poky-lsb.conf:PREFERRED_VERSION_linux-yocto_linuxstdbase ?= "4.1%" Jun 29 21:06:32 when I do set the LINUX_VERSION variables and run bitbake -e linux-yocto, I see PV="4.4.13+gitAUTOINC+a4f88c3fad_bc64c81245", which is almost what I expected ... Jun 29 21:07:06 m2: I think you will find that your PREFFERRED_VERSION setting is not used... bitbake -e | less will tell you for sure Jun 29 21:07:20 but I also can see that it silently switches from loading linux-yocto_4.4.bb to linux-yocto_4.1.bb Jun 29 21:07:54 it's not silent, it's just that that line will be being parsed after yours so it overwrites the value Jun 29 21:08:11 m2: by changing LINUX_VERSION, since that is included in PV that's what feeds into the preferred version selection Jun 29 21:08:17 and the output of bitbake -s still says :4.4.3+gitAUTOINC+bcc6509084_bc64c81245-r0 and nothing else ... Jun 29 21:09:11 so are you using DISTRO = "poky-lsb" ? Jun 29 21:09:50 I still get PREFERRED_VERSION_linux-yocto="4.4%" in the output of -e Jun 29 21:11:07 and DISTRO is set to the expected value, not "poky-lsb" Jun 29 21:12:46 can you please pastebin the full history of PREFERRED_VERSION_linux-yocto ? Jun 29 21:17:15 http://pastebin.com/NiHFeEWL Jun 29 21:20:56 hmm, it is indeed 4.4% Jun 29 21:21:00 this makes no sense at all Jun 29 21:21:13 :-) at least I'm not going nuts Jun 29 21:21:34 bitbake -DDD may shed some light on the behaviour but it'll produce quite a lot of output to wade through Jun 29 21:21:56 ah, thanks for the tip, I didn't think of that ... let's see... Jun 29 21:29:24 this is just bizarre... Jun 29 21:29:26 DEBUG: selecting DIRECTORY/yocto/poky/meta/recipes-kernel/linux/linux-yocto_4.1.bb as PREFERRED_VERSION 4.4% of package linux-yocto (for item linux-yocto) Jun 29 21:35:50 How do I build from scratch with out removing build directory? Jun 29 21:36:06 Guest11734: why exactly do you want to do that? Jun 29 21:36:15 m2: anything related around that? Jun 29 21:36:54 bluelightning: still looking Jun 29 21:37:20 Want test if my recipe is working if I build from scratch Jun 29 21:42:38 Guest11734: you'd just build the recipe itself from scratch I would think - bitbake -c clean recipename then bitbake recipename Jun 29 21:42:45 er Jun 29 21:42:54 I meant bitbake -c cleansstate recipename then bitbake recipename Jun 29 21:43:19 cleanstate will also clean all the dependencies too? Jun 29 21:45:59 bluelightning: What is the difference between clean, cleanall and cleanstate? (sry for too many questions) Jun 29 21:46:37 Guest11734: no, all of these only deal with the individual recipe... but why would cleaning the dependencies be of value for testing just this one recipe? Jun 29 21:49:08 so FYI certain tasks within a recipe (such as do_populate_sysroot, do_package, do_package_write_rpm) have their output saved so that if nothing has changed next time they are needed and the files aren't still present, the output is restored verbatim - this is known as "shared state" or "sstate" Jun 29 21:49:25 clean just removes the work files for a recipe, leaving shared state Jun 29 21:49:37 hmm... when selecting the provider, it loops over all the cached packages... and as it happens, for linux-yocto_4.1.bb the pv value is 4.4.13 (what I set using LINUX_VERSION, because PV in the recipe is set to "${LINUX_VERSION}...") Jun 29 21:49:58 (well, clean removes all files created by building the recipe aside from shared state) Jun 29 21:50:09 cleansstate does that plus removes the sstate for the recipe Jun 29 21:50:23 so me setting LINUX_VERSION in the .bbappend causes the PV for linux-yocto_4.1.bb to be set to 4.4.13... Jun 29 21:50:26 Ok. I have a recipe which uses libgit2. But libgit2 isn't built properly with openssl support. Now I added openssl dependency to libgit2 and build is working. Want to verify if build from scratch is working ensuring the dependecies are built properly in order Jun 29 21:50:31 cleanall also removes the fetched source for the recipe, which neither clean nor cleansstate will do Jun 29 21:51:24 I can fix that by changing linux-yocto_%.bbappend to linux-yocto_4.4.bbappend Jun 29 21:51:42 m2: ah... that would explain it Jun 29 21:51:53 which kind of makes sense, becasue the SRCREV value I want to use only makes sense if I'm using 4.4 Jun 29 21:51:59 m2: your bbappend is applied to all versions not just the 4.4 recipe Jun 29 21:52:13 that's quite an ugly trap actually Jun 29 21:53:54 Guest11734: well, you could bitbake -c cleansstate libgit2 and then bitbake -c clean the dependencies explicitly; there is also a "wipe-sysroot" script although personally I haven't used it Jun 29 21:55:19 bluelightning: Is there a command to get dependency chain? Jun 29 22:00:08 Guest11734: bitbake -g will produce some graphs Jun 29 22:00:44 bluelightning: Ok. Thanks alot :) Jun 29 22:08:49 anybody get a segfault building ruby-native? Jun 29 22:09:15 generating encdb.h Jun 29 22:09:16 | make: *** [uncommon.mk:581: .rbconfig.time] Segmentation fault Jun 29 22:22:27 bluelightning: thanks for the nudge in the right direction! it's working now Jun 29 22:22:39 m2: np Jun 30 01:26:29 hello, how can i build a *ddimg file? i didn't find this kind of file in -/tmp/deploy/images/* Jun 30 01:52:01 tomorrow: set IMAGE_FSTYPES += "live" in your configuration **** ENDING LOGGING AT Thu Jun 30 02:59:58 2016