**** BEGIN LOGGING AT Fri Aug 12 02:59:58 2016 Aug 12 08:47:37 is anyone aware to taskhash mismatch issues with the krogoth sdk? I've had it in meta-raspberrypi but that has been fixed upstream Aug 12 08:57:38 for reference http://git.yoctoproject.org/cgit/cgit.cgi/meta-raspberrypi/commit/?id=6564e126aea0ac42a129595c79218ba69f8095eb Aug 12 09:06:37 Hi Aug 12 09:06:42 nothing is standing out in poky, unless [vardepsexclude] = "DATETIME" needs adding to one of the sdk classes? Aug 12 09:11:58 I'm trying to make a package which would be a dependency of an other package only for few machines. So I added it in DEPEND in a package and set COMPATIBLE_MACHINE. However if I run bitbake with a machine which is not in COMPATIBLE_MACHINE, I end up with " incompatible with >machine " Aug 12 09:12:50 Is there a solution to skip the package if not compatible ? Aug 12 09:16:18 DEPENDS_append_$machine Aug 12 09:27:27 Thanks CTpollard Aug 12 09:34:40 fcs why does the smart package manager update the cache *prior* to removing a package? Aug 12 10:43:40 Hi I'm trying to call some custom python script in a recipe what's the best way of doing it? And how to provide the script? Aug 12 10:51:40 jubr: what do you ment with 'add'? Aug 12 10:57:39 MDNNeo: what does this script? The installation? The Compilation? Aug 12 10:58:17 MDNNeo: or should the recipe only exectue the python script? Aug 12 11:07:17 pretty custom usecase I want to "produce" various users (or basically) create the /etc/passwd file by various conditions on the target rootfs ... so I just thought of calling a funtion doing this in do_rootfs_append() in the image file Aug 12 11:07:23 HyP3r: ^ Aug 12 11:08:24 MDNNeo: there's already support for setting users/passwords Aug 12 11:08:47 HyP3r: calling a function since I want to use the script as well outside the bitbake environment Aug 12 11:09:39 CTtpollard: I know the thing is I want to use the script as well "outside" of the bitbake environment Aug 12 11:10:03 MDNNeo: take a look at EXTRA_USERS_PARAMS Aug 12 11:14:39 so basically I planned to provide it as noarch package in the native environment and then use it in the recipe ... I'm just not sure if this works? Aug 12 11:24:35 What use is setting LIBTOOL=${STAGING_BINDIR_CROSS}/${HOST_SYS}-libtool? Shouldn't every autoconf-based project get its local copy of libtool updated by autoconf.bbclass while autoreconf'ing? Aug 12 11:36:48 MDNNeo: there is a bbclass where you can inherit to create users Aug 12 11:37:16 http://www.yoctoproject.org/docs/1.8/ref-manual/ref-manual.html#ref-classes-useradd Aug 12 11:41:28 HyP3r: I know ... my prob is I want to use the script as such as well ... maybe a bigger background ... for each binary in our target rootfs in a special folder I want to create a user ... this I achieve with a python script. I know I could do this in plain recipe/bbclass as well but I want to use the script for example as well on the target itself Aug 12 12:25:13 any meta-intel minnowboard users around? Aug 12 12:28:36 HyP3r: [18:39] HyP3r: set SRCREV to ${AUTOREV} and add ${SRCPV} to PV Aug 12 12:29:05 I think you misread the last part, he means PV_append = "${SRCPV}" Aug 12 12:29:27 which will trigger a rebuild when it changes, since it is checked every time Aug 12 12:30:45 then I was a bit cryptic in referring to "add", I was prepping for a release and didn't have much time :) Aug 12 13:00:25 does yocto assume to use the native compiler depending on the recipe name? Aug 12 13:02:57 No, native.bbclass does that Aug 12 13:03:05 T_UNIX_: I'm not sure I understaand your question, but the answer is probably yes Aug 12 13:03:13 hmm Aug 12 13:03:16 So if you have a foo-native that doesn't inherit native, you're doing things wrong. Aug 12 13:03:28 boucman_work: I mean like qtbase vs. qtbase-native Aug 12 13:03:36 ok Aug 12 13:04:16 T_UNIX_: neverpanic is right, it's the inherit that does that, not the name, my bad. Aug 12 13:04:20 neverpanic: boucman_work thanks :) Aug 12 13:04:55 native is meant to refer to BUILD, right? Aug 12 13:05:05 yes Aug 12 13:05:12 thanks Aug 12 13:09:11 CTtpollard: I'm using the minnow board Aug 12 13:17:11 what's the best way for do src_uri_append for all but one target? Aug 12 13:19:21 just using if =! $machine? Aug 12 13:22:58 CTtpollard: maybe _append + _remove_$machine could work? Not sure about that one though... Aug 12 13:24:41 I'll give it a test Aug 12 13:32:45 CTtpollard: alternative, something like: ${@base_conditional('SITEINFO_ENDIANESS', 'le', '-DL_ENDIAN', '-DB_ENDIAN', d)} Aug 12 14:11:16 is anyone actually using qt4 embedded? Aug 12 14:42:11 if webkit compiles faster in 4 I might revert ;) Aug 12 14:42:31 hello Aug 12 14:43:51 is there a way to query bitbake to see the list of dependencies for a particular target? Aug 12 14:44:20 davis: https://bugzilla.yoctoproject.org/show_bug.cgi?id=10131 ;P Aug 12 14:44:21 Bug 10131: normal, Undecided, ---, srifenbark, NEW , Suggested rewriting of '2.3.5. Dependency Graphs' Aug 12 14:44:22 davis: bitbake -g (to have a dozen .dot files generated) Aug 12 14:44:34 bitbake -g -u depex to start a gui Aug 12 14:45:11 if I am doing $ bitbake foo, would that be $bitbake -g -u foo? Aug 12 14:45:34 no, bitbake -g -u depex foo Aug 12 14:45:35 nah, need the depex too Aug 12 14:46:00 many thanks Aug 12 14:46:38 it looks like i need depexp, odd it also has google and some others. this is cool. many thanks Aug 12 14:47:05 omg, this is cool. very many thanks. Aug 12 14:47:57 * Ulfalizer wonders if he should move the depexp stuff to the top in his bug Aug 12 14:48:00 davis: Careful, don't want you to have a coronary now ;) Aug 12 14:48:09 oh dude i might Aug 12 14:48:13 maybe it's more immediately useful to more people than the graph stuff Aug 12 14:48:22 hehe Aug 12 14:49:01 Ulfalizer: nice, took me some time to figure that .dot are more readable than depexp :) Aug 12 14:49:21 though I agree with your comment, figuring out what dot file is what would be usefull Aug 12 14:49:35 (and when you run -g on an image, you get other files iiuc) Aug 12 14:49:52 ahh that is goggle, not google. i was like this will be interesting if its google. Aug 12 14:49:54 hmm, alright Aug 12 14:50:50 and np. i've never gotten anything out of looking at graphs themselves. :/ Aug 12 14:51:04 you'd need to prune them heavily somehow Aug 12 14:51:36 this goggle, popped a dialog, did a few messages and then nothing. are we supposed to query it using a web browser or someing? Aug 12 14:51:58 they are usefull to show a customer that that kind of work isn't as trivial as they think :P Aug 12 14:52:06 there's some graphviz thingy for removing A->C dependencies if A->B and B->C already exist, but even that didn't help much Aug 12 14:52:46 boucman_work: could print one of those graphs out and put up whenever a customer visits Aug 12 14:53:12 Ulfalizer: I think the only way to make those graphs readable would be to depth prune... i.e limit it to a certain level of dependencies, or "show me the dep path from package x to package y" Aug 12 14:53:33 (which would translate into the more usefull why is package y included in my image x) Aug 12 14:53:46 Ulfalizer: hehe Aug 12 14:53:57 should be fairly simple to write a tool to parse the dot and show the route between two nodes Aug 12 14:53:59 yeah, something like that Aug 12 14:54:19 oh we have that already Aug 12 14:54:25 scripts/contrib/graph-tool Aug 12 14:54:26 we do ? Aug 12 14:54:37 i didn't know about it until recently, and haven't actually tried it yet Aug 12 14:54:43 find-paths Aug 12 14:54:50 (one of the weakness of yocto is the number of cool stuff in scripts/ that are undocumented) Aug 12 14:55:11 bitbake-layers and its capacity to automatically fetch stuff from the layer-index is one of them... Aug 12 14:55:22 especially some o the stuff in contrib that is just "i hacked a thing" Aug 12 14:55:28 * Ulfalizer has a pending bug for some oe-pkgdata-util documentation Aug 12 14:55:33 * boucman_work add that to his yocto cheatsheet Aug 12 14:55:57 https://bugzilla.yoctoproject.org/show_bug.cgi?id=10066 Aug 12 14:55:59 Bug 10066: enhancement, Medium, 2.2 M4, srifenbark, NEW , Suggested new section on listing package contents Aug 12 14:56:47 i like this documentation on ncurses interface of that command. Aug 12 14:56:56 bitbake -u ncurses text-window based interfaceI couldn't figure out how to control or exit this interface Aug 12 14:57:04 that is my exact problem. Aug 12 14:57:13 i had no idea we had a curses ui Aug 12 14:58:26 when i did that depexp it showed there were differnt modes, i was just testing them. i can't exit the ncurses one. lol Aug 12 14:58:27 and its not been touched apart from to stop it breaking with api changes since 2010 at least Aug 12 14:59:35 * jubr also recently found the ncurses interface -- can it do more that look interesting? Aug 12 15:01:19 how do we open the .dot files? Aug 12 15:02:24 with a dot viewer Aug 12 15:02:28 or emacs if you're hardcore Aug 12 15:03:23 with emacs Aug 12 15:03:30 xdot Aug 12 15:03:30 or a dot viewer if you're hardcore Aug 12 15:03:32 :P Aug 12 15:04:51 lol, this is insane Aug 12 15:04:56 davis: dot -Tpng foo.dot -o foo.png is another option Aug 12 15:05:29 if you have a six foot wide screen :) Aug 12 15:05:53 Ulfalizer: i would highly recommand svg rather than png, it's way more practicall when zooming Aug 12 15:06:23 yeah, i agree. just wanted to give a quick alternative. Aug 12 15:06:33 both will give that blob feeling ;) Aug 12 15:07:30 davis: note that .dot files use a plain text format. they're pretty readable even. Aug 12 15:08:05 or at least more readable than the graphs themselves in this case... Aug 12 15:10:49 so i see part of my problem as a result of this depexp output Aug 12 15:11:31 i have two image receipes. the first has dependency on a recipe i added (amongst others) that is good. Aug 12 15:11:59 the second image which is supposed to depend on the first does not have it as a dependency. it lists itself instead. Aug 12 15:12:48 hmm. odd. in the second image .bb, it has IMAGE_DEPENDS ="the first image" Aug 12 15:13:05 but the dependency explorer does not show that. Aug 12 15:18:45 davis: IMAGE_DEPENDS is an internal variable used by image_types.bbclass afaics, and not supposed to be used like that Aug 12 15:18:58 "image depending on image" does not means that the second will include all packages from the first Aug 12 15:19:20 it means that the second is suppposed to somehow "include" the first (think : initrd) Aug 12 15:20:24 davis: either write common stuff into a image-common.inc, or (a little hackish) actuallually include image-a.bb from inside image-b.bb Aug 12 15:20:52 i'm working with a setup which mods subsquent layers to each other. Aug 12 15:21:26 so the existing system has a well working imgA, imgA++, imgA+++, etc. Aug 12 15:21:58 i tried to pick one of the intermediate layers and start a new chain of mods. Aug 12 16:06:19 made graph-tool work \0/ Aug 12 16:06:28 "why does core-image-sato-base include glib-2.0" Aug 12 16:06:40 produces lots of output obviously, but shows stuff like: Aug 12 16:06:40 core-image-sato-base -> gstreamer-vaapi-1.0 -> gstreamer1.0-plugins-bad -> gstreamer1.0-plugins-base -> gstreamer1.0-plugins-base-meta -> pango -> harfbuzz -> glib-2.0 Aug 12 16:09:14 rburton: how do we use graph-tool? Aug 12 16:09:28 bitbake -g to get the graph data Aug 12 16:09:36 and apply the patch i have on my disk Aug 12 16:10:35 excellent many thanks Aug 12 16:12:04 rburton: nice Aug 12 16:12:28 bb whatdepends -r might be of use too, though with a different interface to the data Aug 12 16:12:35 will have to poke at graph-tool, never knew about that Aug 12 16:12:43 me neither Aug 12 16:12:50 shame it takes forever to load the graph data Aug 12 16:12:58 likely better ways of doing what it does tbh Aug 12 16:13:27 whatdepends handles runtime too now, should have the same info. really do need to look into integrating equivalent functionality into bitbake proper at some point Aug 12 16:13:29 hmm Aug 12 16:13:54 does whatdepends work transiently up the dependency graph? Aug 12 16:14:16 graphtool is great for the "why is in my image" usecase Aug 12 16:17:03 ah, yes. whatdepends is more 'why did this get pulled into my build'. similar, but not identical. it should work equivalently for this particular case. Aug 12 16:17:05 * kergoth ponders Aug 12 16:19:12 arse for/else doesn't do what i thought in python Aug 12 16:21:07 heh, yeah. fits some usages, but not all Aug 12 16:21:24 i couldn't remember exactly what it did was forgot it was for "did i break" not "did i run" Aug 12 16:23:29 davis: patch sent :) Aug 12 16:24:13 to the git repot? Aug 12 16:24:21 to the list Aug 12 16:24:33 ahh, cool. Aug 12 16:26:12 fwiw, i'm working with another developer on his yocto/oe setup. he's not arounnd today sadly, but ive compared diffs of what i modded to his on this image append. Aug 12 16:28:26 python3 ../scripts/contrib/graph-tool find-paths package-depends.dot core-image-sato-base connman Aug 12 16:28:26 core-image-sato-base -> packagegroup-core-x11-sato-base -> connman-gnome -> connman Aug 12 16:28:36 \o/ Aug 12 16:29:11 he's using IMAGE_DEPENDS to have one final image be modified to other images. The ones prior to this one use require's keyword. Aug 12 16:30:25 im guessing his intention was that the necessary packages are built ealier using the requires and this one simply makes a new type of image with the intention that the image_depends ensuring the earlier recipes are built. Aug 12 16:31:05 Howdy, I've used buildroot but am new to yocto. Question, is there a way I can check which website(s) will be used to download all the yocto packages during bitbake? Aug 12 16:31:07 it does not look liek that it working though. is there a proper keyword which is used in the situation? ie. not IMAGE_DEPENDS Aug 12 16:31:40 For example, some buildroot packages would go to random websites if a primary mirror failed, and for security purposes I'd like to make sure I track the download location for the yocto build. Aug 12 16:36:25 AgentElrond: SRC_URI in each recipe is the canonical URL that will be used Aug 12 16:36:44 PREMIRRORS and MIRRORS list the places which will be searched if that URL fails Aug 12 16:37:06 rburton: Thanks! I'm guessing those will be different for each individual recipe, potentially Aug 12 16:37:29 SRC_URI will be different for every recipe, yes Aug 12 16:37:33 What I'm hoping is that most packages will come from a common site, and only a few will redirect to NotAVirus.ru Aug 12 16:37:34 the mirrors are global Aug 12 16:37:43 no, we download from canonical upstream Aug 12 16:37:53 so gcc from gnu.org, etc Aug 12 16:38:01 Ah, excellent Aug 12 16:38:06 (generally) Aug 12 16:38:18 some upstreams are dead so point at the yocto mirror, or snapshot.debian.org Aug 12 16:38:23 I do apologize if that was answered somewhere already. May attempts at searching had failed Aug 12 16:44:28 rburton: https://gist.github.com/kergoth/fcc8fe980b1c26981e033f16a6073fcd - did give the same results for that. need to think about how to improve it further, though. I really want to dump info about the type of dependency at each point along the graph, somehow. i.e. this was a task rdeptask + RDEPENDS_foo, this was a deptask + DEPENDS.. Aug 12 16:44:39 * kergoth adds a todo Aug 12 16:45:19 insufficient caffeine to think about that just now Aug 12 16:45:27 kergoth: i bet that took less time than graphtool! Aug 12 16:45:56 possible, the main delay was the bitbake recipe parsing Aug 12 16:46:43 there are a couple weaknesses to it, still. since the scope is by recipe, not task, sdk bits show up in the list whether you want to know about them or not Aug 12 16:48:46 * kergoth digs through upstream submission queue Aug 12 16:50:02 Is it possible to decline the Crown Bay EULAs and skip their downloads when running bitbake? (I haven't gotten the process started yet) Aug 12 16:50:10 I don't need them at all Aug 12 16:50:32 ahh, i'm seeing my problem. my stuff is in wrong architecture sysrootfs Aug 12 17:17:06 AgentElrond: remove them from your image? Aug 12 17:17:22 kergoth: asking why core-image-sato contains connman takes me 10 minutes Aug 12 17:19:37 It just seemed odd those particular elements had different EULAs Aug 12 17:19:47 Worst case, maybe I can change some files to remove them from recipes Aug 12 17:21:42 its been a while since i looked at that bsp, what bits is it trying to ask you for a eula for? Aug 12 17:25:52 rburton: The very first thing bitbake tries to do is grab https://eula-downloads.yoctoproject.org/index.php Aug 12 17:26:09 It may be a red herring. I'm still setting things up. Aug 12 17:27:00 what release are you using? Aug 12 17:27:12 the common x86 BSPs are generally better if they're available Aug 12 17:27:44 oh its likely grabbing the EMGD drivers Aug 12 17:27:48 hi! i've stumbled upon a problem when using systemd-udevd... it does not allow interfaces names as eth*, etc... my question is: can I use systemd and let eudev manage devices? Aug 12 17:28:12 AgentElrond: if you don't need graphics then there's a crownbay-noemdg machine. if you do want graphics (well, GL) then you need to agree to get the binary drivers. Aug 12 17:28:23 "does not allow"? it's just udev, write a rule to rename them. Aug 12 17:28:55 BiteFingerHand: changing systemd to use old device names is a simple option even if i can't remember what it is Aug 12 17:29:00 rburton: Thanks. I'm not building for an Intel machine at all which is why I'm confused. It's a Yocto Poky setup for OpenBMC. I'll look furhter. Aug 12 17:29:07 *further Aug 12 17:29:17 AgentElrond: yeah something is pulling in the bsp Aug 12 17:29:31 at least, as far as I know Aug 12 17:36:18 thanks rburton. But no matter what I do I can't rename eth0 to eth1, for example Aug 12 17:36:40 https://cgit.freedesktop.org/systemd/systemd/commit/src/udev?id=97595710b77aa162ca5e20da57d0a1ed7355eaad Aug 12 17:36:52 the code that allowes this was removed long time ago Aug 12 17:37:02 allowed* Aug 12 20:04:05 I'm building a readonly image with squashfs and overlayfs based on systemd. I'm mounting /etc in overlayfs but the /etc/machine-id must be tmpfs. Someone has an advice ? Aug 12 21:10:10 caiortp: machine-id is persistent file Aug 12 21:10:23 how did you conclude it should be in tmpfs Aug 12 21:10:46 Jan 01 01:28:36 colibri-imx6 systemd-machine-id-commit[225]: /etc/machine-id is not on a temporary file system. Aug 12 21:15:13 by the way, this service is important? Aug 12 21:15:37 There's some problem if I disable this? Aug 12 21:22:23 so its transient machine-id which needs it Aug 12 21:22:33 may be you can use VOLATILE_BINDS Aug 12 21:24:45 VOLATILE_BINDS_append_hybrid = "/tmp/machine-id /etc/machine-id\n" Aug 12 21:24:54 is what I use Aug 12 21:24:59 in local.conf Aug 12 21:25:20 VOLATILE_BINDS_append = "/tmp/machine-id /etc/machine-id\n" Aug 12 21:25:24 actually Aug 12 22:46:22 Hi all. I'm currently learning CMake. I've realized that if you include cmake in your SDK, the toolchain file sets --sysroot via C_FLAGS ( http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-devtools/cmake/cmake/OEToolchainConfig.cmake?h=jethro#n2 ) rather than using https://cmake.org/cmake/help/v3.6/variable/CMAKE_SYSROOT.html Aug 12 22:46:31 Is there a specific reason for this? Aug 12 23:55:06 Anyone? **** ENDING LOGGING AT Sat Aug 13 02:59:59 2016