**** BEGIN LOGGING AT Wed Sep 04 02:59:58 2013 Sep 04 05:41:26 what is the codename for the next poky version? Sep 04 05:59:49 pidge: ping Sep 04 06:10:41 AlexG: little late here :) Sep 04 06:13:12 mranostay: ok Sep 04 06:13:26 :) Sep 04 06:23:55 hi behanw_ ! Sep 04 06:29:15 AlexG: had a question? Sep 04 06:37:03 AlexG: just ask Sep 04 07:02:49 http://www.kitkat.com/#/home <-- apparently, they have a sense of humor Sep 04 07:27:12 seebs: is it yocto compatible? ;) Sep 04 07:28:03 seebs: sweet Sep 04 07:55:23 good morning Sep 04 08:09:05 lpapp: "dora" Sep 04 08:09:18 rburton: thanks. Sep 04 08:09:53 it was announced in the tech call minutes last tuesday, sent to yocto@ Sep 04 08:10:05 those minutes are always worth a read Sep 04 08:10:19 morning all Sep 04 08:10:43 bluelightning: hi Sep 04 08:11:16 it is a(n unwrittne) rule to always start with 'd'? Sep 04 08:11:22 unwritten* Sep 04 08:12:16 no Sep 04 08:12:24 that's just the pattern of the current naming scheme Sep 04 08:12:40 so yes. :) Sep 04 08:13:43 lpapp: https://wiki.yoctoproject.org/wiki/Releases Sep 04 08:14:03 points if you can identify the naming schemes Sep 04 08:14:50 well, now with so many names it gets easier to google for them Sep 04 08:15:12 i suspect the final addition makes it a lot easier to google Sep 04 08:15:27 previously you had to have a hunch and guide google with other keywords Sep 04 08:15:47 ? Sep 04 08:16:11 by the way, that is lacking the dora cells at the top. Sep 04 08:16:21 Code name and poky version. Sep 04 08:16:59 so it was Sep 04 08:17:19 :-) Sep 04 08:17:42 unwritten rule: if you identify the current scheme, don't announce it publically. Sep 04 08:17:58 <_alex_kag_> hello! can anybody say about mfw_isink? (imx6) fakesink take a lot of processor time, is it possiple to get frame from isink? Sep 04 08:18:20 is there a channel for opkg questions? Sep 04 08:18:25 or we can reach the maintainer only via email? Sep 04 08:34:23 morning all Sep 04 08:35:03 hi eren Sep 04 08:38:20 porky would be a good name canditate for a build bot Sep 04 08:38:26 :P Sep 04 08:39:22 heh Sep 04 08:40:12 guys at axis named it so, which was interesting. I don't know if it was a typo or not Sep 04 08:47:44 eren: it wasn't :) Sep 04 08:48:32 a manager accidentaly said "porky" in a meeting, and the name stuck for our migration project :) Sep 04 08:48:47 eren: sorry about the mails btw Sep 04 08:48:49 hey, don't ruin a good story with facts! B) Sep 04 08:49:09 zibri: i like that story Sep 04 08:50:22 zibri: ah, don't worry, mails are not problem :) Sep 04 08:50:53 zibri: if it is not confidential, what are you using currently for building images? Sep 04 09:02:04 eren: hum, i didn't write our image bbclass, but it's ported from our old system. not exactly sure what you want to know :) Sep 04 09:03:58 zibri: ah, someone just wrote it then Sep 04 09:04:05 yes Sep 04 09:04:28 I always wonder why embdded system companies do not usually think of switching to OE Sep 04 09:04:56 here we have a company producing software for routers, they sell quite well but their image is, pardon me, crap Sep 04 09:05:08 i have to reboot the machine once in a week Sep 04 09:05:58 I learned that they are using some hackery for building images for their boards. I asked why they are not switching to more elegant solutions, they said "it works" Sep 04 09:06:45 heh Sep 04 09:19:25 hi all ! Sep 04 09:19:37 I come to you because I would like to build a poky image I've already build before, this image contains wayland and X11 but I would like to re-build it without X11, does someone know how is that possible ? Sep 04 09:19:55 thank you Sep 04 09:21:13 elbc_: remove x11 from your DISTRO_FEATURES Sep 04 09:21:29 then you'll be free of any traces of X11 Sep 04 09:22:04 (with x11 distro feature enabled dbus will depend on libx11, which is why you can still get pieces of X on a wayland image) Sep 04 09:22:07 I'm a beginner with yocto but actually i didn't found any trace of X11 in my conf file Sep 04 09:22:21 thank you for your ansmwer by the way Sep 04 09:23:20 eren: well, there's definitely some ramp-up time... it's after that that people see the value of the system Sep 04 09:24:06 bluelightning: yeah, learning curve is a bit high but after that it's ok Sep 04 09:24:12 at least, it is maintainable Sep 04 09:25:47 when the image is built, libX11 is present because I think some features need it. As I said there is no trace of "X11" in my DISTRO_FEATURES, but maybe there is a command to disable or not allow libX11 Sep 04 09:25:49 ... Sep 04 09:26:30 elbc_: your distro features must have x11, as otherwise libx11 will refuse to build Sep 04 09:26:36 elbc_: (the default has x11) Sep 04 09:27:51 ok I'll take a look again. thank you ! Sep 04 09:29:39 if you're using poky from git master, you can use the lovely new _remove operator to edit DISTRO_FEATURES Sep 04 09:29:49 otherwise you'll need to set it Sep 04 09:30:37 if i don't like one line of a recipe's do_install(), for example, is the correct course of action to replace the entire do_install() in my bbappend? Sep 04 09:31:01 BCMM: yes Sep 04 09:31:06 thanks Sep 04 09:32:00 can i ask some advice about submitted changes upstream? i've made a few modifications to the mpd recipe which might be of general interest Sep 04 09:32:07 ok I'll try to use it ! thanks a lot for your help Sep 04 09:32:29 BCMM: each layer has a readme with any rules, like where to send the patches. Sep 04 09:33:09 rburton: for meta-multimedia, it's a mailing list, it's just that somebody posted a patch that does some of the same things as what i did at pretty much exactly the same time, but his has a bug Sep 04 09:33:57 and i'm rather unsure of the etiquette - should i post a patch to be applied after his patch, or a working version of his patch, or what? Sep 04 09:34:16 BCMM: if that broken patch hasn't been applied, reply on the list and send a revised version Sep 04 09:34:24 an, in general, are people interested in patches that optionally remove features? Sep 04 09:34:25 rburton: thanks Sep 04 09:34:48 BCMM: optionally trimming stuff out is fine, best practise is to use PACKAGECONFIG if it works for that package Sep 04 09:35:00 rburton: that's what i've done, thanks Sep 04 09:35:12 just wanted to make sure i wasn't totally misunderstanding stuff before posting Sep 04 09:35:28 now i just have to work out how to make git generate patches for me, cause that's the rules for that layer... Sep 04 09:35:48 (for some reason, pulseaudio was compulsory in mpd) Sep 04 09:35:56 if you configure git's email sending, you can use git send-email Sep 04 09:35:57 and dbus in wpa_supplicant Sep 04 09:36:26 rburton: i've also never modified somebody else's git repo before Sep 04 09:36:41 i've used a local one, and pulled other ones (obviously) Sep 04 09:37:06 do i just edit the recipe in the layer, and then git-send-email works out what i've done? Sep 04 09:37:18 it sends the commits as patches Sep 04 09:37:46 so you review your branch and ensure that you've logical changes with clear commit messages Sep 04 09:37:56 i.e. no "add foo", "fix typo", "argh another typo" commits Sep 04 09:38:33 ah right, so i make a git branch, commit changes to it, then have git generate the patches from that? Sep 04 09:38:40 yes Sep 04 09:39:06 thanks, i'll go and read git docs and make a brance Sep 04 09:39:08 branch Sep 04 09:39:19 BCMM: that documentation would help: http://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded Sep 04 09:39:23 my personal workflow is a "feature" branch per logical set of changes, then i daily rebase all my branches and get to see what's been merged and what is outstanding Sep 04 09:39:45 rburton: what do you mean by "rebase" in this context? Sep 04 09:39:49 eren: thanks! Sep 04 09:39:59 ah, rebasing, I haven't done that either Sep 04 09:40:02 BCMM: git-rebase Sep 04 09:40:15 I usually create a branch for changes, generate patches from that branch Sep 04 09:40:19 then I remove that branch Sep 04 09:40:29 if the patches have been applied, of course Sep 04 09:41:11 eren: my "mergeotron" script does a git fetch, rebase's all branches against origin/master, and tells me if any branches are now the same as master (i.e. have been merged), so my other script can prune them from local and remote repos Sep 04 09:41:20 so... rebase is for if your branch could basically be considered a relatively small set of patches to the master, and rebase basically applies said patches to the latest master? Sep 04 09:41:28 BCMM: basically Sep 04 09:42:09 if you google for git workflow you'll find plenty of example workflows Sep 04 09:42:53 so in terms of actually making my images, i could have a branch of meta-multimedia in my bblayers.conf, and make changes i want to send upstream to that branch, and changes that only make sense for my project in bbappends in a seperate layer? Sep 04 09:44:41 BCMM: that's pretty sensible for the long-term Sep 04 09:45:24 rburton: well, it's a pretty small project. thus far, i upstreamable changes for wpa_supplicant and mpd Sep 04 09:45:35 but i want to do things "cleanly" where i can Sep 04 09:46:16 BCMM: good, make it easier for everyone :) Sep 04 10:07:42 rburton: reading again what you have written, to be sure to understand, are you saying there is no way to disable libx11 (I want to build an image using wayland/weston) Sep 04 10:07:46 ? Sep 04 10:07:48 thanks again Sep 04 10:08:09 elbc_: removing x11 from your DISTRO_FEATURES will mean you have absolutely zero X in your builds Sep 04 10:08:28 yes that'ts what I want Sep 04 10:08:32 elbc_: and if anything doesn't respect that choice and tries to build something, libx11 checks the DISTRO_FEATURES and will refuse to build Sep 04 10:09:46 rburton: ok, so there is no way to build an image entirely based on wayland ? Sep 04 10:10:10 sure there is, just remove x11 from distro features Sep 04 10:10:27 i'm saying that the system will do exactly what you want Sep 04 10:10:39 remove x11 from distro features and you'll have no x11 in your distro Sep 04 10:11:03 rburton: ok thank you very much for your patience and your help Sep 04 10:11:53 DISTRO_FEATURES_remove = "x11 x11-common xorg-xserver" ? Sep 04 10:12:16 elbc_: are you using poky from git master? Sep 04 10:12:27 yes Sep 04 10:12:32 cool, in that case close Sep 04 10:12:36 DISTRO_FEATURES != packages Sep 04 10:12:38 so just "x11" Sep 04 10:13:02 ok ! thanks ! Sep 04 10:33:26 where can i find a list of vars for paths? i mean, like ${bindir} Sep 04 10:36:05 BCMM: best reference for those is meta/conf/bitbake.conf, where their default values are defined Sep 04 10:36:10 bluelightning: thanks Sep 04 11:05:35 Hi guys, in machine/my.conf originally used: SERIAL_CONSOLE = "" SERIAL_CONSOLES = "115200;ttyS0 115200;ttyS1" Sep 04 11:05:46 now switching to only one COM port Sep 04 11:06:11 is the logic as simple as assigning it to SERIAL_CONSOLE and leaving SERIAL_CONSOLES = "" ? Sep 04 11:19:21 Krz: for dylan, yes; note that the two variables use different syntaxes though Sep 04 11:19:55 so I'm gonna do exactly: SERIAL_CONSOLE = "115200 ttyS1" SERIAL_CONSOLES = "" Sep 04 11:19:57 for dylan Sep 04 11:20:29 Krz: right, that would be correct assuming ttyS1 is the device you wish to enable Sep 04 11:20:50 bluelightning: thanks very much! Sep 04 11:38:45 bluelightning, it sounds like cf0... made a working sdk after installing F19 Sep 04 11:38:59 we may have some problem with Ubuntu something Sep 04 12:12:06 rburton: hello again ! I've tried this : DISTRO_FEATURES != "x11" and I had the following error : ParseError: ParseError at /yocto/poky/thinkpad/conf/local.conf:251: unparsed line: 'DISTRO_FEATURES != "x11"' Sep 04 12:12:25 do you know why ? Sep 04 12:12:40 oh , i meant that the DISTRO_FEATURES line isn;t a set of packages Sep 04 12:12:54 so DISTRO_FEATURES_remove = "x11" Sep 04 12:13:09 ok thanks I will try this Sep 04 12:14:59 rburton: beginner question : if it builds correctly, how can I check easily that this line has worked ? Sep 04 12:15:31 elbc_: the work directory for the image will let you browse the rootfs that's been created, and see a list of files Sep 04 12:16:08 ok thanks I'll check this list ! Sep 04 12:24:57 Crofton|work: FWIW I run ubuntu here, though I haven't made a habit of using the Qt toolchain on this machine Sep 04 12:25:07 Crofton|work: but noted, thanks Sep 04 12:25:22 do you use any sdk's? Sep 04 12:31:45 Crofton|work: I use buildtools-tarball every day on my build machine which is basically an SDK; I've installed the meta-toolchain SDKs a number of times recently to check basic functionality Sep 04 12:32:23 I''l try and get some details about the issue Sep 04 12:32:41 I'm an ubuntu avoider so not much help :) Sep 04 12:52:23 I need to add one entry to inittab. I think there is some magic API to do that in Yocto way, anybody aware? Sep 04 12:55:03 Krz: I don't think there's any magic for that, I think you'd just bbappend sysvinit-inittab (see meta/recipes-core/sysvinit/sysvinit-inittab_2.88dsf.bb) Sep 04 12:55:39 bluelightning: was looking at this recipe right now. Yeah, it seems I have to do bbappend for that. Does do_install_append in my bbappend sound good? Sep 04 12:55:52 Krz: that would work yes Sep 04 12:56:07 bluelightning: nice, cheers Sep 04 13:35:28 mranostay, How's it going? Sep 04 13:45:55 what's the codename for 1.5 release? Sep 04 13:46:01 Krz: dora Sep 04 13:46:21 wow, that sounds non-english Sep 04 13:53:14 Krz: well, technically "dylan" is a welsh name so that's also non-English ;) Sep 04 13:53:30 s/welsh/Welsh/ Sep 04 14:10:29 I've a question about the package_rpm. There is a recipe I am using that is a pre-compiled program with a few libraries. The rpm for the pre-compiled program mentions that it provides all of the libraries it contains. I want to avoid that. Is there a way to prevent this, such that the rpm will only provide the package name, and not any of the libraries it contains? Sep 04 14:15:52 quatre: adjust the recipe to not include them? Sep 04 14:16:00 via a .bbappend Sep 04 14:16:57 Garibaldi|work: the depends are added when building the rpm itself Sep 04 14:17:09 quatre: not sure how you can avoid those... Sep 04 14:17:55 rburton: I thought that's what he wanted ... to have an external depend rather than the rpm including the lib Sep 04 14:20:03 Here is the concrete example: I am using a recipe to bring in the oracle java jre. It has several libraries already compiled, including a jpeg library. I move the program and its libraries out of the standard path to avoid conflicts. There are two images being built, one that pulls in the jre, and one that pulls in libjpeg from another recipe. Sep 04 14:20:47 The way it works now, both images happen to pull in the jre. the first pulls it in because it provides the jre. the second pulls it in because it find that it provides libjpeg, but does not see the other rpm file first Sep 04 14:21:28 I would like the jre rpm to only provide the name of the jre recipe, so that it is not unintentionally pulled in to the other image Sep 04 14:21:40 rburton: Hi again, I think X11 has been removed correctly, my question is : is there a way to have no trace of libx11 (because it is still present) if I want some packages like pulseaudio and gtk3 ? Sep 04 14:22:16 I tried setting 'EXCLUDE_FROM_SHLIBS = "1"', as in gcc-package-sdk.inc, but it did not do as I expected Sep 04 14:22:17 quatre: in that case you'll be pleased to know that (iirc) there's a patch on the list to not generate those deps if the libs are not in the default search paths Sep 04 14:22:43 elbc_: gtk3 and pulse will compile fine without x11 Sep 04 14:23:04 that is great news. Do you happen to know where I can find that patch so I may try it out? Sep 04 14:23:59 win 2 Sep 04 14:24:02 rburton: ok, so if after build I see traces of libx11 , i can affirm it is not a problem, can you confirm ? thanks Sep 04 14:24:03 gah Sep 04 14:24:04 quatre: http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=rpurdie/wip76&id=589a2d0d0768ab399b7bf919480815e0df650303 might be relevant Sep 04 14:24:41 elbc_: if you've correctly removed the x11 distro feature you won't see any libx11. as i've said, libx11 checks for the x11 distro feature and will only build if x11 is enabled. Sep 04 14:26:06 rburton: ok, I'll check, I've just put the DISTRO_FEATURES_remove = "x11". thanks again Sep 04 14:33:15 JaMa: Did you update your shlibs patches from the ones you posted? Sep 04 14:33:26 JaMa: I'm seeing a few small bugs in the ones I took from the list :/ Sep 04 14:46:38 is the eglibc error : ERROR: Function failed: do_compile (log file is located at /yocto/poky/thinkpad/tmp/work/x86_64-poky-linux/eglibc/2.18-r0/temp/log.do_compile.3428 a known issue ? Sep 04 14:47:52 probably not Sep 04 14:47:56 pastebin the log please Sep 04 14:51:41 here is the end of the log : Sep 04 14:51:45 ln -s ld.so /home/elebideau/yocto/poky/thinkpad/tmp/work/x86_64-poky-linux/eglibc/2.18-r0/build-x86_64-poky-linux/elf/ld-linux-x86-64.so.2 /home/elebideau/yocto/poky/thinkpad/tmp/sysroots/x86_64-linux/usr/libexec/x86_64-poky-linux.gcc-cross-initial/gcc/x86_64-poky-linux/4.8.1/ld:/home/elebideau/yocto/poky/thinkpad/tmp/work/x86_64-poky-linux/eglibc/2.18-r0/build-x86_64-poky-linux/shlib.lds:128: syntax error collect2: error: ld returned 1 e Sep 04 14:52:07 it didn't work Sep 04 14:52:13 pastebin the full log please :) Sep 04 15:06:05 rburton: try to do a pastebin on pastebin.com but have some problems, trying to do as fast as i can Sep 04 15:13:39 Hello all, is there a way to create a native package based on the output of a target build? This question is in reference to building qt. I want to build qt for my arm target but I would like to then add the generated qmake to my host sysroot. Sep 04 15:13:51 rburton: log is too long cannot create a pastebin Sep 04 15:15:54 rburton: is there an other way to send you the log ? Sep 04 15:17:13 try a different pastebin, i'd say. there are plenty fo pastebin sites, i can't imagine they all have the same limitations Sep 04 15:17:21 gist.github.com, pastebin.ca, others Sep 04 15:17:34 kergoth: thanks I'll try Sep 04 15:17:45 alternatively, if you have dropbox, share it that way, that's always an easy way to share a fiel Sep 04 15:17:52 or mediafire or rapidshare or.. Sep 04 15:17:56 always lots of options for such things Sep 04 15:31:42 rburton: I'll try to build all packages excepts eglibc and i'll post you the log of the build of eglibc after that if it is ok for you. thanks for your time Sep 04 15:32:52 elbc_: eglibc is pretty important... Sep 04 15:35:59 rburton: still at a bit of a loss. I tried the patch, but the rpm will still list the offending libraries as being provided. I also see that by setting 'EXCLUDE_FROM_SHLIBS = "1"' in a recipe the entire step that the patch tries to help with can be skipped. Even doing that, when I query the generated rpm file: Sep 04 15:36:03 $ rpm -qp $rpm_file_here --provides | grep libjpeg Sep 04 15:36:07 libjpeg.so Sep 04 15:36:10 libjpeg.so(SUNWprivate_1.1) Sep 04 15:36:55 so, the package_do_shlibs step is not the one causing the issue in my case. Sep 04 15:44:24 rburton: yes I know but that was for have just the log (short) I need Sep 04 15:47:00 rburton: here is the log ! http://pastebin.com/pB5dCfnV Sep 04 15:47:07 Hm, it seems that including 'SKIP_FILEDEPS = "1"' into the recipe instead appears to work. Sep 04 15:48:04 elbc_: that's... odd. silly question but the disk isn't full? Sep 04 15:48:16 rburton: not at all Sep 04 15:49:38 quatre: This is an rpm feature enabled at the rpm level Sep 04 15:50:09 quatre: you probably need to move the files you don't want to a different directory or something Sep 04 15:50:21 quatre: or split the package into two Sep 04 15:51:02 rburton: I've to go thanks a lot for your help again, maybe see you tomorrow Sep 04 15:51:20 all the files in the jre package I believe I need. The files in the jre package are installed to a location that is non-standard to avoid other programs from accidently loading with the jre's libraries. Sep 04 15:51:41 the issue is that I am using one workspace to build two images Sep 04 16:10:13 RP: I'll compare them with my local copy a bit later and let you know, current version is HEAD~4 here https://github.com/shr-distribution/oe-core/commits/jansa/test Sep 04 16:10:27 now off to get some food Sep 04 16:14:20 there is a gdb recipe in poky Sep 04 16:14:27 but I didn't find gdb-server Sep 04 16:14:39 how do I build gdb-server? Sep 04 16:18:37 gdb-server usually comes out of the gdb recipe Sep 04 16:19:11 the 'gdbserver' package (produced from the gdb recipe) is what you likely want Sep 04 16:23:14 so it's been a while since i last checked Sep 04 16:23:23 er.. shit wrong channel Sep 04 16:23:24 carry on. Sep 04 16:24:21 ERROR: Nothing PROVIDES 'gdbserver' Sep 04 16:24:33 im using poky dylan 9.0.1 Sep 04 16:24:47 he just told you the recipe is gdb, not gdbserver Sep 04 16:25:29 sorry, my bad Sep 04 16:25:38 so I just build gdb and will have server and client, right? Sep 04 16:27:38 you build gdb, and tell your image recipe to install the 'gdbserver' package Sep 04 16:27:58 fray: thanks! Sep 04 16:55:58 JaMa: ok, I have some fixes then Sep 04 17:00:28 JaMa: http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/wip76&id=fe9e70f5ff23cd4e77949a4f47cc3de2401b4a22 specifically Sep 04 17:01:12 JaMa: I'm now worrying this will cause autogenerated shlibs dependencies for be removed from things though. We probably need to have some kind of RPATH handling to make this all work properly :/ Sep 04 17:01:29 * RP is out of time right now but will try and write up a full repsonse/summary Sep 04 17:06:56 looks good, my version in jansa/test branch has one more change: Sep 04 17:06:57 - def read_shlib_providers: Sep 04 17:06:57 + def read_shlib_providers(): Sep 04 18:14:41 So, I've got this one nagging loose end with the pseudo bug pabigot found, which is: How did this ever appear to work? Sep 04 18:15:18 I hate when that happens :( Sep 04 18:15:35 Answer: Back in October of 2011, fray renamed the undocumented/internal PSEUDO_RELOADED hack to PSEUDO_UNLOAD. Sep 04 18:15:57 In passing, he added a helpful check in the pseudo client: if PSEUDO_UNLOAD is in the environment, pseudo *also* disables itself. Sep 04 18:16:31 So in any case where you tried to do something like "PSEUDO_UNLOAD=1 ", the command would run as though it didn't have pseudo in its environment, even if it was actually loaded. Sep 04 18:16:50 Of course, that doesn't entirely resolve the mystery. Sep 04 18:17:12 Because I still don't know why, on the machines not exhibiting this behavior, we don't get any diagnostics about being unable to load libpseudo.so. Sep 04 18:19:11 Ah. Hah. Sep 04 18:19:14 bash/dash Sep 04 18:19:33 pseudo dash -c "PSEUDO_UNLOAD=1 id" => trips t Sep 04 18:19:36 the test I had for this Sep 04 18:19:44 pseudo bash -c "PSEUDO_UNLOAD=1 id" => does not Sep 04 18:20:21 all of the testing done at the time used /usr/bin/env Sep 04 18:20:44 And the reason we rarely-if-ever saw it inside WR is that our old build system did not have enough hooks to protect individual apps from bashisms, so we have a habit of changing /bin/sh to point to bash on systems that have to build the old product. Sep 04 18:21:58 And if you had a program which cleaned up its environment, then called something else, and you ran it with PSEUDO_UNLOAD=1 but without the bug fix and you were using dash, it could end up with LD_PRELOAD set and LD_LIBRARY_PATH not set, or something similar. Sep 04 18:22:45 Oh, like, say, if it tried to change LD_LIBRARY_PATH. I bet I could now make something that triggers this, but in any event, I am now content to assert that this really IS the fundamental problem, and that there are real reasons for it to appear only sporadically. Sep 04 18:23:58 so is pabigot's fix the correct one then? Sep 04 18:24:06 (for the confused) Sep 04 18:24:33 Well, "the" correct one might be a bit strong, but I stand by my "this looks good, let's use that until I have time to spend staring at this and thinking more about edge cases". Sep 04 18:24:43 ok, fair enough Sep 04 18:26:50 seebs: i mysteriously got the problem again today and confirm that his patch fixed it Sep 04 18:27:12 rburton, what's /bin/sh on your machine? Sep 04 18:27:28 bash Sep 04 18:28:19 Huh. Well, then I'm still a little confused. But I think I'm willing to accept that. Sep 04 18:28:41 same here :) Sep 04 18:29:46 FWIW, a quick check for the behavior: Sep 04 18:29:57 pseudo bash -c "PSEUDO_UNLOAD=1 env" | grep LD_PRE Sep 04 18:30:16 And then you can try with other shells, and observe the behavior changing. Sep 04 18:41:26 Thinking more about this, I note a fundamental flaw in pseudo's environment setup, which is that the UNLOAD behavior just tries to remove LD_PRELOAD. So I think I am going to change this so that, if UNLOAD is set, we don't do the environment setup, we just remove LD_PRELOAD. As-is, pseudo will clutter an environment with various PSEUDO_FOO values even if it's being unloaded. Sep 04 19:37:33 hi all. My external kernel module includes local .h files. How to tell Yocto to find these files Sep 04 19:37:45 I tried EXTRA_CFLAGS=-I$(PWD), does not work Sep 04 19:45:38 how about CFLAGS_append = foo Sep 04 20:09:32 JaMa: still around? Wanted to ask you about bug #4795 Sep 04 20:09:33 Bug https://bugzilla.yoctoproject.org/show_bug.cgi?id=4795 normal, Medium, 1.5, saul.wold, NEEDINFO , PSEUDO_LOCALSTATEDIR _sometimes_ points to WORKDIR with wrong TARGET_OS Sep 04 20:10:27 Hi Guys, Anyone know how to do Yocto app development on Windoze? Sep 04 20:13:18 sgw_: yes, I've seen NEEDINFO in the morning but haven't had time to reproduce it and add more details Sep 04 20:13:39 sgw_: fwiw it's not fatal in any way (at least I don't think so) so it's OK to move it to 1.6 Sep 04 20:18:25 JaMa: got it was one of those, that I had hanging around and thought I would look at it. I am guessing it's oe-core not poky based and maybe qemuarm for the machine? Sep 04 20:32:34 Is there a way to have an image recipe DEPEND on another image build? A client would like to include the tarball of a small recovery image in the main image build. Sep 04 20:33:26 Doing the obvious approach, adding a DEPENDS in the image recipe, doesn't trigger a build of the recovery image Sep 04 20:34:37 sakoman: i have done something similar. Sep 04 20:34:44 sakoman: I think that's doable, since we do it form initramfs I think Sep 04 20:35:38 i have 2 images. 1 being 'included' in the other one. Sep 04 20:35:53 to make a chroot in my case, but it's similar. Sep 04 20:36:36 sakoman: you might need to create a depends on the image:do_rootfs, take a look at imiage-live.bbclass and INITRD_IMAGE Sep 04 20:36:37 sakoman: in the 'top level' image, i do this: Sep 04 20:36:37 do_rootfs[depends] += "my-other-image:do_rootfs" Sep 04 20:37:01 ndec got it also Sep 04 20:37:09 yep ;-) Sep 04 20:37:31 then in your top level image, you can assume that your other image is in ${DEPLOY_DIR_IMAGE}/ Sep 04 20:52:46 ndec: thanks, I'll try that Sep 04 20:54:48 sgw_: yes different DISTRO and I've seen it with multiple different MACHINEs Sep 04 20:59:16 jama, ok I am building an oe-core/qemuarm, I know you said the reproduce was hard, you do know that the pseudo directory is added back in again to deal with setscene Sep 04 21:04:22 yes, but than I've built the same target twice once completely from sstate-cache and once from scratch and the names of pseudo dirs weren't consistenly all incorrect or correct Sep 04 21:05:07 heh, bitbake still has a bug where it doesn't re-create the mirror tarballs when the repositories are updated Sep 04 21:05:11 hrmph Sep 04 21:09:07 ugh, i don't think BB_SRCREV_POLICY = "cache" is working properly anymore Sep 04 21:09:33 * kergoth digs Sep 04 21:42:16 sgw_: how that u-boot seems ok on beagle; I sent a upgrade patch for it Sep 04 21:42:32 sgw_: *now that ... Sep 04 21:46:54 bluelightning: sent an e-mail with a possible backport for dylan Sep 04 21:51:29 otavio: yes, I saw that thanks. Sep 04 21:52:30 tomz2: thoughts on moving lttng to git recipes instead of tarballs? (re otavio email from this morning) Sep 04 21:53:53 sgw_: sounds like a good idea to me Sep 04 21:54:55 tomz2: of course it means going through the whole potential renaming issue again, maybe.. Sep 04 22:00:48 How do I add extra files so that they get populated in the sysroot? Sep 04 22:02:27 gjohnson: install them within your recipe's do_install into the appropriate path under ${D} and they will be staged into the sysroot automatically Sep 04 22:03:54 kergoth: ouch; if you fix the cache policy please cc me in the patch so I can test it Sep 04 22:07:05 i don't quite understand the README_-_DO_NOT_DELETE_FILES_IN_THIS_DIRECTORY in my /tmp/deploy/images dir - do i have to do something special in order to remove old images? Sep 04 22:07:16 it seems to collect an extra image for every build i run Sep 04 22:07:51 BCMM: the kernel file, in case you remove it and kernel does not change, it won't be re-deployed. Sep 04 22:08:03 BCMM: same for bootloaders Sep 04 22:08:26 BCMM: if you know that you are doing you can remove images, problem has been people will remove the kernel or other files and then can not rebuild, what otavio said ;-) Sep 04 22:08:29 BCMM: so you must to be careful Sep 04 22:08:50 but you can always recover by -c clean'ing the appropriate recipe? Sep 04 22:08:51 sgw_: ;-) Sep 04 22:09:13 BCMM: well, but it takes time and in case you use package feeds it is not wanted Sep 04 22:09:29 BCMM: you can -b deploy -f Sep 04 22:09:29 i don;t know aht "package feeds" means... Sep 04 22:09:46 BCMM: I think it'll do the trick Sep 04 22:10:00 BCMM: look at Yocto docs about package feeds Sep 04 22:10:06 otavio: not sure exactly what's going on, but i do know we're having trouble shipping with SRCREV=AUTOREV, which was a problem we'd already worked around in the past by pre-supplying the BB_URI_HEADREVS map.. will come up with more detail and open a bug if necessary tomorrow Sep 04 22:10:06 * sgw_ the YoctoAutoBuilder is going to make a lot of noise shortly, bad build on my part! Sep 04 22:10:10 heh Sep 04 22:10:39 sgw_: you bad! Sep 04 22:10:54 sgw_: please if possible add my u-boot in mut for testing as well Sep 04 22:11:06 sgw_: did you see the distro_features_check additions? Sep 04 22:12:42 * otavio went off; bbl Sep 04 22:45:10 Suppose I was running a perl script on qemuppc and it complained because it couldn't find the module File::Basename in its search paths. File::Basename has been part of Perl core since 5.14.2. What should be my cpurse of action? Sep 04 22:45:35 It seems to be able to find File::Spec. Sep 04 22:52:55 How can I find out what yocto Perl module actually supplies this module? Sep 04 22:56:01 The answer is, you can noodle around in the Perl workdir looking for that file name. Sep 04 22:56:42 right Sep 04 22:56:45 mulhern: perl-module-file-basename I guess Sep 04 22:57:21 Yup…it's the correct one. Sep 04 22:57:42 But here's another question. Sep 04 22:59:19 Is the reason that File::Spec is on qemuppc even though it's not in RDEPENDS of my package pure luck? Because there's another module perl-module-file-spec that seems to contain File::Spec but it's not in my RDEPENDS. Sep 04 23:00:22 I agree that the naming is helpfully consistent. But I also believe that there are some uber- yocto perl modules that contain more than one actual Perl module. Sep 04 23:01:18 mulhern: right; I'm not sure what the logic has been in how those were grouped **** ENDING LOGGING AT Thu Sep 05 02:59:59 2013