**** BEGIN LOGGING AT Wed Apr 22 02:59:58 2015 Apr 22 03:07:27 hi..how do I kill X in Yocto? Apr 22 03:07:36 is there a service that I can stop or something? Apr 22 03:25:26 chankit, have you checked for an init script? Apr 22 05:27:23 redengin: sorry can't follow you..I just want to kill and start X in a more canonical way Apr 22 05:27:41 redengin: not sure what init script u r referring to Apr 22 05:28:24 chankit, if X started upon boot, there is a script in /etc/init.d that made it happen Apr 22 05:28:43 that same script should be able to be called with a "stop" option to kill X Apr 22 05:29:10 or you can grep the process list and kill the xserver Apr 22 05:33:14 redengin: I'm afraid there's no such script that controls X Apr 22 05:33:22 redengin: never mind then...thanks a lot Apr 22 05:35:23 which image are you building? Apr 22 08:06:12 morning all Apr 22 08:09:01 morning Apr 22 08:18:39 hi marquiz Apr 22 08:47:01 morning all Apr 22 08:50:46 when using my own kernel (vanilla plus own patches) rules and my own defconfig i have issues with the QA rules (i.o.w. certain k. params are discarded as they are in the defconfig and the defconfig provided is changed). What's wrong with it? TIA Apr 22 09:07:53 sm0ketst: is this a linux-yocto flavor you are building? Apr 22 09:43:37 hi, i need to extract some archives within a bitbake task, but as the archive is a rootfs containing dev/* i need to untar with sudo. but that is not working, bitbake not showing password prompt. so any idea? Apr 22 09:46:13 ericbutters: http://docs.openembedded.ru/fakeroot.html Apr 22 09:46:17 is there anyway to make yocto use svn folder instead of a copy to build in? Apr 22 09:47:22 ericbutters: i don't know if i've linked the best source, but basically you don't do stuff as root ("with sudo"); you do it with fakeroot, which makes it look like dev nodes and so on exist when they don't really Apr 22 09:47:48 (i assume the reason you want to untar with sudo is so that tar can create dev nodes?) Apr 22 09:48:13 mrsan__: sounds like you're looking for EXTERNAL_SRC (at the cost of reproductibility, be aware of that.) Apr 22 09:49:07 ericbutters: also google says i am out of date and people use this instead now https://www.yoctoproject.org/tools-resources/projects/pseudo Apr 22 09:50:25 BCMM: thanks.. and yes, also yocto replaced fakeroot with pseudo: https://www.yoctoproject.org/tools-resources/projects/pseudo Apr 22 09:51:35 hmm i'm curious about the history of fakeroot now... was it originally created for debian packaging? Apr 22 09:59:04 BCMM: ericbutters: note that we already have pseudo, so you wouldn't need to use fakeroot Apr 22 09:59:58 hi all Apr 22 10:00:00 LetoThe2nd: do u know any better way to set SVN version if the cmake file requires it Apr 22 10:00:03 respape: hi Apr 22 10:00:14 anybody has experince with intel nuc n2820 ? Apr 22 10:00:19 BCMM: ericbutters: well, what I mean is you wouldn't need to add fakeroot itself, it may be that you'd need to mark the do_unpack task with the "fakeroot" flag though (which means run it under pseudo) Apr 22 10:00:50 any meta repo available ? Apr 22 10:01:10 ( like rappberypi meta ) Apr 22 10:01:17 ( like raspberypi meta ) Apr 22 10:02:10 respape: I would suggest meta-intel with MACHINE = "intel-corei7-64" Apr 22 10:02:19 ok Apr 22 10:02:21 thx Apr 22 10:02:31 bluelightning: so the fakeroot flag makes psuedo happen now, meaning the migration from actual fakeroot is transparent to most recipes? Apr 22 10:03:20 BCMM: yes, more succinctly the fakeroot flag means "I need fakeroot functionality" which is implemented by running the task under pseudo Apr 22 10:03:46 bluelighning: that was the info i needed, prepend fakeroot for the tasks Apr 22 10:04:26 bluelightning: ^ Apr 22 10:04:47 is yocto default build system for debian? or other distros? Apr 22 10:04:52 i think i saw somewhere mentioning debian on yocto Apr 22 10:05:45 ericbutters: not so much prepend as d.setVarFlag() (you can do this from an anonymous python function) Apr 22 10:06:37 miandonmenmian: no; debian has its own build infrastructure, but I believe there was a project presented to build debian using our system at ELC Apr 22 10:07:02 miandonmenmian: no, debian has it's own automated building system Apr 22 10:07:53 (i.e. a proper debian package is not just an archive of binaries some developer built; it should come with a source package that can automatically recreate the binary package. some somewhat conceptually similar to a BB recipe) Apr 22 10:11:26 JaMa: ping Apr 22 10:12:03 would be be easy to build debian with yocto ? where can i find more information about ELC ? Apr 22 10:12:11 sujith_h: pong Apr 22 10:12:17 JaMa: Wouldn't it be better to change qtquick1 recipe name to qtquick? Apr 22 10:12:35 JaMa: Unless there is any reason for making it qtquick1 Apr 22 10:14:35 miandonmenmian: http://events.linuxfoundation.org/sites/events/files/slides/ELC2015-YOSHI-PokyDebian_0.pdf Apr 22 10:14:59 miandonmenmian: I haven't tried it myself and don't necessarily endorse it... Apr 22 10:16:32 mostly out of curiosity, yocto's learning curve ( for a newbie like me ) is a bit rough. but I'm actually liking this quite a lot, so far, very impressed Apr 22 10:17:14 did some openwrt before and is quite different Apr 22 10:21:36 right, it's something we hear a lot; we do try to improve things where we can, so if you can think of anything that we could do to make the system easier to use then please let us know Apr 22 10:22:59 sujith_h: ask upstream http://code.qt.io/cgit/qt/qtquick1.git/ Apr 22 10:29:35 JaMa: aah ok :) Apr 22 10:29:56 ant_work: sorry for the delay. not it is not. im using the vanilla kernel. I defined an .inc and git.kernel.org + SRCREV to point the version i want Apr 22 10:31:30 so no KMETA used. Also using my own defconfig Apr 22 10:59:31 i want to archive some (maybe) unusual approach with yocto: i just want to use yocto/bitbake to extract a pre-build yocto rootfs out of an archive, then apply some recipies which also extract some binaries out of archives, and then copy the binaries over the pre-build rootfs. finally let bitbake create the rootfs out of this. Apr 22 10:59:49 is this possible? what will be the best way to do this? Apr 22 11:00:15 which tasks should be used, which tasks should be added/overwritten? Apr 22 11:04:32 ericbutters: that's not something we support out of the box; in theory it would be possible, but you'd need to do a bunch of work to implement it Apr 22 11:18:34 bluelightning: excellent article. when and where was the ELC? Apr 22 11:19:53 oh, San Jose.. Apr 22 11:22:39 LetoThe2nd: is there any other way to do it? Apr 22 11:22:52 mrsan__: huh, what? Apr 22 11:23:04 svn issue Apr 22 11:23:04 11:48 < LetoThe2nd> mrsan__: sounds like you're looking for EXTERNAL_SRC (at the cost of reproductibility, be aware of that.) Apr 22 11:24:13 mrsan__: i don't know the backgounrd of your question, so i really can't comment more. you said you want to build from some directory that is *not* what OE fetched. the mechanism for that is called EXTERNAL_SRC - and it obviously breaks the reproductibility of the build Apr 22 11:24:46 ok Apr 22 11:24:48 mrsan__: if you ask more specifically, maybe some other pointers can be found (not necessarily by me, i'm no expert either.) Apr 22 11:24:54 :) Apr 22 11:26:50 im using SRC_URI = "svn://svn.code.sf.net/p/domoticz/code;module=trunk;rev=${PV}" , but in the working directory it makes export it seems of svn, and looses svn information. is there anyway to make it checkout instead, so the recipies CMake file doesnt need to be patched and the svn version can remain in the working directory? Apr 22 11:27:49 currently the cmake fetches this information and builds it in to binary Apr 22 11:27:55 now that actually sounds more like actually only out-of-tree building is broken for that thing. Apr 22 11:28:20 e.g. make your recipe build in-tree. Apr 22 11:29:02 LetoThe2nd: and how do i do that (im a n00b :() Apr 22 11:30:09 any links i can read about it i would be happy:) Apr 22 11:30:34 mrsan__: i have no clue for cmake, for autotools its inherit autotools versus inherit autotools-brokensep. maybe the difference there can also be applied to cmake Apr 22 11:30:37 mrsan__: see http://www.yoctoproject.org/docs/1.7.1/ref-manual/ref-manual.html#ref-classes-autotools Apr 22 11:35:41 LetoThe2nd: Ty il read it :) Apr 22 11:36:59 bluelightning: yes, that is what i was thinking. could you please provide some basic ideas how to start with this? and how is the workflow? Apr 22 11:37:32 mrsan__: good luck Apr 22 11:46:18 is variables like PV parsed down to compiling shell so it can be picked up by f.ex. CMake? Apr 22 11:46:26 parsed pushed Apr 22 11:53:22 Hi.. Apr 22 11:54:25 since there are number of kernel configuration files e.g. under arch/x86/xyz_defconfig ... is there any way to specify in recipe file to use specific 'xyz_defconfig' when building kernel? Apr 22 14:12:15 otavio: I can build out the meta-fsl fido stuff now for release on the AB if you want. Apr 22 14:12:35 pidge: meta-fsl-arm you meant Apr 22 14:12:36 yes Apr 22 14:13:32 otavio: where does meta-fsl-ppc stand (I keep forgetting who needs pinging on that). Apr 22 14:15:17 otavio, ok, arm is kicked off. Apr 22 14:19:01 pidge: ping Luo Apr 22 14:19:26 pidge: to be honest I am not following them so I am not aware how well tested fido was with it Apr 22 15:09:37 Hi all, quick question -- what's the easiest way to figure out which recipe is causing a dependency to be built? Apr 22 15:10:21 bitbake -g -u depexp works fairly well. -g gives you the info in the form of graphviz .dot files, but -u depexp gives you an x11 browser for the data. not perfect, but better than nothing Apr 22 15:10:45 my 'bb' tool provides a 'whatdepends' subcommand, but unfortunately it only works for build deps at this time, not runtime, which makes it very limited in usefulness Apr 22 15:12:01 kergoth: thanks, I'll take a look! Apr 22 15:14:13 np Apr 22 15:40:50 Has anyone seen ncurses libraries with incorrect ownership? That is, owned by the build user, not root Apr 22 15:43:34 kergoth: IIRC there was some discussion recently about file ownership issues, don't think it was specific to ncurses though Apr 22 15:43:59 I know there are some other cases, e.g. files written by qemu end up with wrong ownership, hence the recent fontcache fix, but this one i've not seen before, quite odd Apr 22 15:44:05 hmm Apr 22 15:44:13 * kergoth reads the current ncurses recipe Apr 22 15:44:20 suppose i could check the pseudo logsd Apr 22 15:44:22 s/d$// Apr 22 15:45:11 are these files that would have had debug symbols stripped out? Apr 22 15:45:20 I guess yes Apr 22 15:46:20 maybe this would be related? http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=1e34e71e0f6752ec33eb4b30ce72f249b80e9a5d Apr 22 15:46:29 I don't think I've seen that. For a while most of the recent bits have been recipe issues. Apr 22 15:47:53 ah, i don't hvae that commit, guess its time to update our upstream layers (we do it explicitly, usually on a weekly basis, to reduce churn) Apr 22 15:48:02 thanks for the tip, bluelightning, will see if that takes care of it Apr 22 15:50:47 kergoth: that was the middle of three patches that affect that area (the last of which was just sent today) Apr 22 15:53:17 the first was http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=8bab098c36e2a10107b368dc94448c536a536e40 Apr 22 15:53:49 I think it was the first that introduced the issue in question, so if you don't have that one yet then you may not be seeing the same problem Apr 22 15:55:33 ah, we do have that one. that could explain it, then Apr 22 15:55:46 thanks Apr 22 16:14:49 hi, how can I force yocto to regenerate the image once I removed that manually from ./tmp/deploy/images/foo? Apr 22 16:15:00 bitbake -f myimage did not seem to work out. Apr 22 16:16:27 -f operates against a specific task. without specifying -c, the task being forced is likely the default task, which is 'build' Apr 22 16:16:32 since build is a no-op, that doesn't do what you expect Apr 22 16:16:36 you can do -f -c rootfs Apr 22 16:16:41 or you can -c clean it and re-run the bitbake Apr 22 16:16:50 ok, thanks. Apr 22 16:16:52 np Apr 22 16:18:09 alternatively, bitbake -C rootfs foo will "taint" do_rootfs, and then build up to the default task. the difference would be if the recipe had any tasks after the one being tainted. e.g. -C fetch foo will rebuild the entire recipe, since forcing fetch to rerrun will make all its later tasks rerun Apr 22 17:45:36 Now playing with a prototype enhanced Local fetcher that can support PREMIRRORS, has improved wildcard support, copies symlinks without resolving them, and simplifies/improves the destination/subdir handling, with an eye toward using it for sysroot extraction for meta-sourcery like the way fray described the other day Apr 22 17:46:40 hmm, think i'll have to give up on ideal support for wildcards in the relative subdirectory path, though, as determining the correct destination will be tough when coupled with both premirrors and filespath.. (e.g. file://.${libdir}/gcc/*/*/foo.*) Apr 22 17:54:31 * kergoth ponders Apr 22 18:08:18 if a recipe has a PACKAGES =+ "p1 p2" Apr 22 18:08:43 when I build the recipe, does both the p1 and p2 will be compiled and copie ton the fs of my image ? Apr 22 18:09:04 or I need to specifically include p1 and p2 Apr 22 19:24:27 oh, i didn't realize we had open bugs on these behaviors, and tests in the selftest, excellent. Apr 22 19:24:36 hmm, a couple cases are likely missing from it, should add them Apr 22 19:24:49 doesn't test behavior with multiple entries in FILESPATH, either Apr 22 19:25:29 hmm Apr 22 19:38:58 * kergoth writes a little python script to first inject a replacement fetcher instance, then run the unit tests on that Apr 22 19:48:12 gahh, the unexpected/unanticipated full rebuild is the worst Apr 22 19:48:23 at least if i just did a layer update or something, it's not unexpected Apr 22 19:48:41 but when you're just going to test a build of some recipe and for some unknown reason it'll now take an hour, it really irks Apr 22 19:49:07 and can't always use -S printdiff due to sstate mirror involvement.. Apr 22 19:51:53 hmm, having trouble with the multilib support in meta-sourcery, because the PREFERRED_PROVIDERs aren't set for the multilib variants of the external toolchain recipes. wonder how best to resolve that Apr 22 21:23:05 Yocto Project 1.8 is officially released. https://lists.yoctoproject.org/pipermail/yocto-announce/2015-April/000062.html Apr 22 21:23:13 * halstead cheers! Apr 22 21:41:06 too many names for the smae thing Apr 22 22:08:39 huzzah Apr 22 22:31:56 halstead: you got a sec to setup the webhook? Apr 22 22:32:04 darknighte, Yep! Apr 22 22:34:56 hmm, ./var/lib/opkg/lists/oe-all and the ncurses libs are still having build user ownership, even with the previously discussed commit applied Apr 22 22:35:00 * kergoth checks for pending bits on the list Apr 22 22:46:34 hat off to all developers for the 1.8 release! **** ENDING LOGGING AT Thu Apr 23 02:59:58 2015