**** BEGIN LOGGING AT Tue Jun 16 02:59:59 2015 Jun 16 06:44:04 <_4urele_> Hi everyone! Jun 16 06:47:05 <_4urele_> does someone knows where I should put the "SYSTEMD_DEFAULT_TARGET"? in my image receipe, in my distro, or in any other receipe? Jun 16 06:48:08 _4urele_: image recipe Jun 16 06:48:37 <_4urele_> erbo, thx Jun 16 07:37:24 how can I install a symlink in a yocto recipe? I tried install -m but I got file not found error while the link is definitely there Jun 16 07:37:50 so I think the install command takes the link it points to, hence the error Jun 16 07:39:57 <_4urele_> parrot, usually I do it manually but maybe there is a better way... Jun 16 07:41:30 <_4urele_> parrot, (by manually i mean ln -sf inside the recipe ;) ) Jun 16 07:45:30 _4urele_: -f means force right? not sure how that will solve the problem though. I too prefer the manual way but since I'm making the image for someone else so I would prefer them to do less job. Jun 16 07:47:47 <_4urele_> parrot, if I understand well the symlink target can change? Jun 16 07:49:11 <_4urele_> parrot, maybe the only way is a dirty "cp" as it is for a symlink you shouldn't have to change privileges? but maybe there is a clean way that I don't know ;) Jun 16 07:52:53 _4urele_: I tried cp but same error :-( Jun 16 07:55:31 <_4urele_> parrot, a bare cp will take the symlink destination but did you tried "cp --preserve=links" Jun 16 07:56:21 <_4urele_> parrot, test on a shell first ;) i never tried... Jun 16 07:56:52 <_4urele_> maybe it could preserve the link to the good file and not the link path... Jun 16 08:00:28 <_4urele_> parrot, on my computer "cp -a " and "--preserve" did not work as expected Jun 16 08:00:46 parrot: Using ln directly seems to be the way. Try grep "ln -" -r poky/meta for examples Jun 16 08:02:10 <_4urele_> erbo, I think He maybe don't know the link destination but he knows it is a symlink Jun 16 08:03:35 <_4urele_> parrot, if you want to create the link again you can also read the path destination with "readlink" Jun 16 08:03:42 I actually know the destination but it's relative Jun 16 08:04:26 <_4urele_> so why don't you use "ln" ? Jun 16 08:06:10 <_4urele_> parrot, this is one of my own : ln -s ../castel-prepare.target ${D}${systemd_unitdir}/system/multi-user.target.wants/castel-prepare.target Jun 16 08:10:57 morning all Jun 16 08:28:54 morning Jun 16 08:29:18 * nerdboy eyeballing pillow Jun 16 08:33:18 (UMT) Jun 16 09:26:54 bluelightning: just for your information, I added a profile in /etc/profile.d and it did not what I wanted (I wanted to set PATH system-wide not only when I log in). So, thanks for the help, I'm going to ask on #busybox why their shell doesn't read /etc/environment Jun 16 10:03:20 Hi all Jun 16 10:16:14 i'm having issues booting a celeron-m / i586 unit when init-live.sh is called; it stops at "Waiting for removable media". It boots fine with Qemu so I saw the Qemu image starts fine 'md' but fails in the real target with "md: linear personality registered for level -1". Jun 16 10:31:26 I have a recipe which inherits from cmake and update-rc.d. /usr/bin is shipped, but /usr/lib isn't. I tried to add FILES_${PN} += "${libdir}" but it didn't work (whereas FILES_${PN} += "/opt/toto" works) Jun 16 10:31:38 I installed some libs in "${D}${libdir}/" Jun 16 10:31:55 How do I ship the libs? Jun 16 10:32:06 gourve_l: are these libraries using standard library versioning? Jun 16 10:32:48 hmm. No Jun 16 10:33:10 it's just my_lib.so Jun 16 10:35:25 so the default package splitting for libraries assumes you are using standard library versioning (assuming what you are installing is a library rather than a plugin or optional module) Jun 16 10:37:08 if you really want to avoid using library versioning you will need to set FILES_${PN} to include /usr/lib/yourlib.so and set FILES_${PN}-dev so that it _does not_ include all .so files (because the default, again based on the assumption you're using versioning, is that .so files are development symlinks rather than actual libs and thus should go into the development package) Jun 16 10:38:11 oh. OK. So if I use toto.so.1.0.0 and toto.so -> toto.so.1.0.0 instead of just toto.so, it should work? Jun 16 10:38:39 s/use/install Jun 16 10:38:42 yes, but hopefully whatever build system your lib is using supports that easily, it shouldn't be something you have to hand-code ;) Jun 16 10:39:02 ok :) Thanks for the answer! Jun 16 10:39:09 np Jun 16 12:45:41 Hi. is it possible to override do_patch in bbclass with shell function and call base realization from it? Jun 16 12:46:56 it seems file://*.patch stop working if I override do_patch. at least in 1.6 Jun 16 12:46:57 no, do_patch is python Jun 16 12:47:02 what do you want to actually do? Jun 16 12:47:30 I need to do some seds Jun 16 12:47:49 its fairly common to use do_configure_prepend() or do_compile_prepend() for something like that Jun 16 12:47:59 or, add a new task between patch and configure Jun 16 12:48:13 (or just do the seds in a patch…) Jun 16 12:51:13 for now I use next hack in my recipe http://pix.academ.org/img/2015/06/16/c53d1fab29c028e7625f44434fccfc89.png where umfticc is my bbclass which does additional pathing and call patch_do_patch from patch.bbclass Jun 16 12:51:26 all of these looks to complex. Jun 16 12:51:43 too* Jun 16 12:53:14 regarding do_configure_prepend. I don't like it too. since I expect my sources to be fully ready for compilation after patching. Jun 16 12:53:35 ok. thanks for your help Jun 16 12:54:09 s/after pathing/after do_patch/ Jun 16 12:54:59 then just add a new task between patch and configure to do the seds Jun 16 12:56:57 I'd prefer if it were implemented like in Gentoo Linux. Jun 16 12:59:24 zeddii, can you point me at the patches that make older kernels boot when built with newer gcc? I think they were in a linux-yocto at some point Jun 16 12:59:51 * Crofton|work goes to ride before the furnace turns on outside .... Jun 16 14:23:28 hey guys Jun 16 14:24:15 could somebody help me with this issue -> http://dpaste.com/0Z5RX7X.txt ? Jun 16 14:25:51 looks like it failed to get the glibc version from the external toolchain you pointed to Jun 16 14:26:08 perhaps you are pointing to an external toolchain that meta-sourcery simply does not support ? Jun 16 14:27:19 bluelightning: actually I don't change the default toolchain in the local.conf file Jun 16 14:28:01 hmm... maybe meta-sourcery isn't designed to be included if not being used? Jun 16 14:28:04 I honestly don't know Jun 16 14:42:07 hm Jun 16 14:42:11 anyone else? Jun 16 16:31:31 * darknighte just realized that the ELCE submission deadline is tomorrow Jun 16 16:32:30 * darknighte has been considering doing an update/intermediate version of the YP talk from 2012 Jun 16 17:32:14 sgw_ and or RP around? I have thoughts pertaining to bootloaders, and if people are around IRC is probably faster than email. Jun 16 17:33:03 ... I say right before realizing I have to go AFK for a minute or ten. Jun 16 17:33:38 gives 'em enough time to run away. :) Jun 16 17:47:33 rburton: saw the patch and log? Jun 16 18:03:27 Back now, though. Hah! Jun 16 18:04:26 seebs: are you working on bootloaders revamp? Jun 16 18:06:39 Sort of! Jun 16 18:06:52 We have a thing internally which provides a Generic Bootloader Manager. Jun 16 18:07:10 The idea is that the kernel can have a postinst script that looks roughly like "bootloader-mgr register /path/to/kernel; bootloader-mgr select $version" Jun 16 18:07:27 and then a separate package does the actual whatever-is-needed to make the new kernel be what gets loaded. Jun 16 18:07:52 So we don't have to write all the fancy logic once per bootloader, all we need is the tiny little script for each bootloader that does the magic. Jun 16 18:08:06 And something like PREFERRED_PROVIDER_bootloader-imp = "bootloader-imp-grub-efi". Jun 16 18:13:05 seebs: here now Jun 16 18:13:16 *runs away* Jun 16 18:13:38 Anyway, we currently have all this magic in a layer called, imaginatively enough, meta-bootloader. Jun 16 18:14:03 But that name is wrong (there are no bootloaders in the layer), but I'd find a longer name like meta-bootloader-manager to be sort of unwieldy. Jun 16 18:14:04 very imaginative! Jun 16 18:14:31 but not intuitive then! Jun 16 18:15:54 Yeah. Jun 16 18:16:23 Right now we only have about one and a half of the implementations written, so more are needed, but I *think* the interface is reasonably-flexible. Jun 16 18:16:40 And we'd like to contribute this, whether as a layer or as some other kind of feature. Jun 16 18:16:56 So it's generic for the case of 1 right now (rounding of course) Jun 16 18:16:58 The key really is the interface has everything needed for on-target kernel upgrades.. Jun 16 18:17:01 (packages or otherwise) Jun 16 18:17:03 Although the implementation isn't there, the idea is to make something that is a suitable replacement for the kernel-grub bbclass. Jun 16 18:17:37 It's been thought-checked for a couple of other likely bootloaders, but I don't have enough hardware/time to actually go do all the typing. Jun 16 18:17:39 I've thought that the implementation is 'bsp' specific in some ways.. with generic implementations available (along side bootloaders) where possible Jun 16 18:17:45 But I'm pretty sure that what they need to do is possible with it. Jun 16 18:20:29 rburton: you hit that oserror with your bitbake builds, was that using an external toolchain, or internal? Jun 16 18:34:17 seebs: fray: this is in fact interesting Jun 16 18:34:50 however I am wondering how much it adds when comparing to the distro-agnostic script which has been involving in u-boot Jun 16 18:34:50 so next step is for seebs to publish the code somewhere..... Jun 16 18:35:03 I think there was an open bug that related to this topic, but I haven't gotten to comparing notes with people yet, because that would be far too much like planning ahead. Jun 16 18:35:10 and been being adopted by some distros Jun 16 18:35:15 I think that's solving the opposite problem. Jun 16 18:35:27 That's solving "we want to install u-boot kernels without knowing what distro we're on". Jun 16 18:35:35 I want to solve "we want to install yocto kernels without knowing what bootloader we're using". Jun 16 18:35:56 you got a point Jun 16 18:36:06 So the likely answer is that you'd use both on yocto targets with u-boot, and bootloader-imp-uboot would basically just call their distro-agnostic script for the magic it needs. Jun 16 18:36:08 did you wrote the plugin for u-boot as well? Jun 16 18:36:33 Not yet. And that's a good thing apparently because I don't think I knew about their distro-agnostic script, so I would likely have wasted effort. :) Jun 16 18:37:05 the distro-agnostic one uses syslinux format Jun 16 18:37:31 most eval and community boards are moving to this Jun 16 18:37:50 even though I didn't make it work on yocto yet Jun 16 18:37:55 the imp-uboot could simply generate the syslinux format, and make the call to the script Jun 16 18:38:35 that is the hope with this work.. we can do whatever the backend needs to work properly.. since we have generic "YP" inputs.. and the script can also do validation and -fail- if something isn't right.. i.e. the wrong format kernel Jun 16 18:38:59 scripts can be inserted into YP / OE kernel package automatically or run manually by the user if they don;t want packages Jun 16 18:39:27 and it really is supposed to be bootloader agnostic.. we simply shouldn't care what that board uses.. u-boot, grub, grub-efi, gummiboot, some random binary loader, etc.. Jun 16 18:40:12 fray: agreed Jun 16 18:40:26 seebs: fray: when this code will be made avail? Jun 16 18:40:39 as soon as seebs has a name and place to post it Jun 16 18:43:01 fray: agnostic bootloader interface - abooti :P Jun 16 18:44:03 * fray looks over at seebs.. Jun 16 18:45:14 I think this should all be done using a layer for now Jun 16 18:45:28 so we can do the necessary cooking, cleanup, integration and testing Jun 16 18:45:35 once this is complete, it can go to oe-core Jun 16 18:46:27 if there is any chance of this going into the fall release, I'd love to see it there.. but it was implemented in a layer specifically because we knew that it requires some oversight and such Jun 16 18:48:07 I can help in u-boot integration Jun 16 18:51:47 kergoth: internal Jun 16 18:52:23 my guess is that it will be a day or so, simply to get the project setup on git.yoctoproject.org (or another suitable location) Jun 16 18:53:54 hmm, interesting Jun 16 18:57:33 meta-meta-bootloader Jun 16 18:57:39 fray: to be honest, this kind of work I think would be nice to have in github or similar Jun 16 18:57:54 makes easier for forking, pull request, issue report and like Jun 16 18:58:17 seebs: I hate this double meta Jun 16 18:58:18 kkk Jun 16 18:58:20 meta-boot-loader-loader-boot-fo-bootloader Jun 16 18:58:30 Hmm. This is not getting better. Jun 16 18:58:53 meta-abstract-bootloader-interface-class-and-sample-implementation Jun 16 19:00:04 * paulg_ fines fray $2 Jun 16 19:00:19 meta-bootloader-wrapper-scripts-with-a-nice-clean-name-that-is-easy-to-type-and-remember Jun 16 19:00:22 * fray notes that is only one argument Jun 16 19:00:45 Reminds me of one of my first proposed names: TARGET_NO_REALLY_THIS_TIME_WE_MEAN_IT_FUNDAMENTAL_CFLAGS Jun 16 19:00:48 meta-abi (abrstract bootloader interface) that won't be confusing Jun 16 19:01:32 meta-oh-look-a-three-headed-monkey Jun 16 19:01:55 ... So basically I've been thinking about this name thing for a bit and not making much progress. Jun 16 19:02:36 meta-kernel-bootloader-interface (kbi)! Jun 16 19:03:40 seebs, there ya go.. zedd is the kernel guy, so what he says goes.. :) Jun 16 19:04:03 meta-pebkac Jun 16 19:04:42 meta-grand-unified-bootloader, or meta-gub for short. Jun 16 19:04:52 ha Jun 16 19:05:06 calling it 'gub' would be great.. Jun 16 19:05:34 "hey did you know you had a typo with 'grub'?" Jun 16 19:07:08 gubi - grand unified bootloader interface ;) Jun 16 19:21:01 rburton: it's the execution of pseudo — it's trying to run a fakeroot task without pseudo in the sysroot, somehow — at least, that's the behavior i'm seeing Jun 16 19:21:24 guessing we need an appropriate exception handler when executing bitbake-worker to at least give a nicer error for this.. Jun 16 19:21:25 hmm Jun 16 19:40:53 kergoth: aah, interesting Jun 16 20:33:05 hello i am having massive amounts of trouble getting bitbake to work on my computer Jun 16 20:33:19 i have followed steps online but nothing gets bitbake working Jun 16 20:33:35 my terminal still says bitbake command not found Jun 16 20:33:44 kergoth: I can't help think of the new sstate code somehow removing pseudo... Jun 16 20:33:53 can some one here help me set up bitbake? Jun 16 20:34:10 kergoth: even if it didn't something should presumably rebuild it before it got there... Jun 16 20:34:45 RP: that was my first thought, too. but then i noticed that i had a task flagged as fakeroot, but without virtual/fakeroot-native:do_populate_sysroot in its depends flag, so testing fixing that first Jun 16 20:34:52 then will bisect and see Jun 16 20:35:32 kergoth: the missing depends could do it... Jun 16 20:37:17 kergoth: the noupdatedata branch is pretty much working in any of my tests now btw. Not sure if you're had a chance to look at it? Jun 16 20:37:33 only just got back from a 2 week vacation, playing catch-up Jun 16 20:37:52 quit Jun 16 20:38:48 kergoth: fair enough. It does have some pretty significant behaviour changes although nothing that seems to affect the majority of our metadata Jun 16 23:19:46 Hi guys, how to I enable multicore compilation in my Yocto local.conf? Jun 16 23:20:21 The Quickstart says I should set BB_NUMBER_THREADS, PARALLEL_MAKE, and BB_NUMBER_PARSE_THREADS Jun 16 23:20:43 However these strings don't exist in conf/local.conf ?? Jun 16 23:22:41 The reference manual says "By default, the OpenEmbedded build system automatically sets this variable to be equal to the number of cores the build system uses." Jun 16 23:22:53 (PARALLEL_MAKE) Jun 16 23:23:02 you only need to set them if you don't want hte defaults.. Jun 16 23:23:05 So how do I know how many cores the build system uses? Jun 16 23:23:10 The defaul is to use as many cores as your build system has Jun 16 23:23:22 Oh that's different, thanks. Jun 16 23:26:33 fray, does it do sth sane with BB_NUMBER_THREADS too? I've never tried to rely on the defaults before... Jun 16 23:26:39 yes Jun 16 23:26:56 BB_NUMBER_PARSE_THREADS is based on BB_NUMBER_THREADS (but can be manually set) Jun 16 23:27:36 oh well, i'm guessing it it won't be as agressive as I am, in trying to preemptively unravel inter pkg dependencies ASAP. Jun 16 23:28:11 nothing worse than having a big machine 99% idle as you wait on some pkg that everyone depends on Jun 16 23:28:36 default is: Jun 16 23:28:40 BB_NUMBER_THREADS ?= "${@oe.utils.cpu_count()}" Jun 16 23:28:42 someday I'll get around to looking at that fancy dependency graph feature again. Jun 16 23:28:43 PARALLEL_MAKE ?= "-j ${@oe.utils.cpu_count()}" Jun 16 23:29:35 oe-utils.cpu_count more or less does: Jun 16 23:29:36 [mhatle@msp-dhcp23 conf]$ getconf _NPROCESSORS_ONLN Jun 16 23:29:36 48 Jun 16 23:32:24 * paulg_ fines whoever didn't type out ONLINE in full $2. Jun 16 23:33:32 aha, figures. tinfoil hat glibc kooks. Jun 16 23:43:35 Thanks guys. Bitbake underway on all cores :-) Jun 16 23:44:50 Uh oh ncurses failed to build Jun 16 23:44:54 | from ../ncurses/lib_gen.c:19: Jun 16 23:44:55 | _18469.c:835:15: error: expected ')' before 'int' Jun 16 23:44:57 | ../include/curses.h:1594:56: note: in definition of macro 'mouse_trafo' Jun 16 23:44:59 | #define mouse_trafo(y,x,to_screen) wmouse_trafo(stdscr,y,x,to_screen) Jun 16 23:45:01 | ^ Jun 16 23:59:40 Hmm binutils fails too Jun 16 23:59:59 | Makefile:1182: recipe for target 'tc-i386.o' failed Jun 17 00:02:24 Maybe it's my build host's toolchain? gcc (GCC) 5.1.0 Jun 17 00:16:11 Maybe I don't need to build x86_64-linux/ncurses-native anyway? Jun 17 00:23:36 Maybe I need libtermcap.so? Jun 17 02:02:47 It seems these problems exist only on the fido branch - switching to master solves all Jun 17 02:28:03 how do I make yocto include debug packages? what should I add to local.conf? Jun 17 02:32:30 how about EXTRA_IMAGE_FEATURES=dbg-pkgs Jun 17 02:36:08 zuz: thanks for the pointer...I have a test package that whose name is FILES_${PN}-test. So I wonder how can I get that particular package gets included in the final image build as well Jun 17 02:36:47 I wonder if appending "test-pkgs" would work Jun 17 02:55:02 no it doesn't work... **** ENDING LOGGING AT Wed Jun 17 02:59:59 2015