**** BEGIN LOGGING AT Fri Apr 11 02:59:58 2014 Apr 11 03:33:59 regorianer: you may not have CAPS letters in recipe names Apr 11 03:34:07 err versions Apr 11 03:34:12 kergoth: what ICE Apr 11 03:34:33 I dont use RHEL so care less but still am interested Apr 11 03:36:03 the odd thing is, re-doing the build after it fails, will succeed. must be something unreliable in the build process, or something? Apr 11 03:56:57 noooo, don't rebuild everything from scratch *again*! Apr 11 03:57:02 * kergoth kicks sstate in the junk Apr 11 04:11:09 hi Apr 11 04:11:36 Can someone point me to the docs for yocto in regards to pulling source for a package from git? Apr 11 04:11:52 I'd like to have a recipe that checks out the latest commit from the git repo and build from that source Apr 11 04:12:10 kergoth: did you update srcs ? Apr 11 04:12:32 diffuse: look into other recipes e.g. uclibc Apr 11 04:12:41 see the SRC_URI Apr 11 04:13:57 and also read http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#var-SRC_URI Apr 11 04:17:46 khem: ok, that helps a bit but the build complains about srcrev being set, is that required? Apr 11 04:20:39 typo... Apr 11 04:20:47 khem: thanks, that did solve my issue Apr 11 08:38:07 Is there a way / bitbake command to get the list of packages available in a particular image ? Apr 11 08:43:57 YoctoAutoBuilder: Is there a way / bitbake command to get the list of packages available in a particular image ? Apr 11 08:44:01 good morning Apr 11 09:07:05 morning all Apr 11 10:32:25 morning. Apr 11 10:49:14 hi. i have a workflow question. Apr 11 10:50:57 i want to compile a very simple application, just for testing purposes (spidev_test.c). do i have to create a recipe etc, or can i just compile this by hand somehow? Apr 11 10:54:58 allright, "bitbake -c devshell" was what i was looking for Apr 11 11:18:27 <_valle_> Hi! Has anyone modified psplash? Apr 11 11:18:43 _valle_: changed logo Apr 11 11:19:05 <_valle_> What is the maximum size of the logo? Apr 11 11:19:36 <_valle_> Could you have an image that takes full resolution of the display? Apr 11 11:21:35 _valle_: I think you can. Apr 11 11:21:59 _valle_: probably you need to put it in RLE format using make-image-header.sh Apr 11 11:22:20 http://git.yoctoproject.org/cgit.cgi/poky/plain/meta-yocto/recipes-core/psplash/files/psplash-poky-img.h Apr 11 11:22:39 ionte: If using devshell, be aware of "PSEUDO_UNLOAD=1" - it drove me nuts for ages trying to find it! Apr 11 11:25:34 <_valle_> diego_r: Yes I did, but it seems that it cannot be fullscreen Apr 11 11:25:56 <_valle_> diego_r: Because my logo is placed above the progress bar :( Apr 11 11:26:10 _valle_: I can't help you further then, never tried to go fullscreen Apr 11 11:26:48 <_valle_> diego_r: Okay, thanks anyway Apr 11 11:38:07 hi everybody Apr 11 11:38:27 I get this error: Apr 11 11:38:38 preferred version 9.1.6 of mesa not available (for item virtual/egl) Apr 11 11:38:56 because I had modified with a mesa.bbappend Apr 11 11:39:12 PROVIDES = "virtual/libgl virtual/libgles1 virtual/mesa" Apr 11 11:39:42 I had removed egl and libgles2 from mesa PROVIDES because I have another package providing those Apr 11 11:40:02 don't do that Apr 11 11:40:05 any idea on how to get around this? Apr 11 11:40:37 rburton, well, how should I proceed? that other package only provides egl and gles2 Apr 11 11:40:38 just set the PREFERRED_PROVIDER for virtual/egl to your other package Apr 11 11:40:45 I did Apr 11 11:40:58 and the other library parts it provides? Apr 11 11:41:01 and then it says that multiple providers for virtual/egl exist Apr 11 11:41:17 yes. your PREFERRED_PROVIDER was incorrectly specified then. Apr 11 11:41:42 I just did: PROVIDES = "virtual/libgles2 virtual/egl" Apr 11 11:41:50 for the other package Apr 11 11:41:59 as it only provides gles2 and egl Apr 11 11:42:29 http://git.yoctoproject.org/cgit/cgit.cgi/meta-intel/tree/conf/machine/include/meta-intel-emgd.inc shows how to tell bitbake that you want to use one recipe for libgl, and another for egl/gles Apr 11 11:42:32 and in my machine I have: Apr 11 11:42:38 PREFERRED_PROVIDER_virtual/libegl and PREFERRED_PROVIDER_virtual/libgles2 Apr 11 11:42:50 it's virtual/egl Apr 11 11:43:26 darn, I missed that Apr 11 11:43:36 thanks for the tip Apr 11 11:44:53 would be nice to fix the inconsistent naming but thats more inconcenience than just having the current names Apr 11 11:46:56 indeed Apr 11 12:12:08 pev: what's that for? (PSEUDO_UNLOAD) Apr 11 12:12:52 pev: i had no problems compiling, but there was an error message when running sudo though (something similar to "pseudo unload"...) Apr 11 13:09:42 I was following the openssl discussion on the mailing list, about PRINC... so, it means when uing poky with "live" feeds one really has to use a PRSERV, because poky does not guarantee proper recipe revision bumps? Apr 11 13:10:48 Jin^eLD: yes Apr 11 13:11:02 uuh.. I did not know that, good to know Apr 11 13:11:43 how does it behave with multimachine builds? Apr 11 13:30:55 ionte: devshell runs as 'root' in a fakeroot environment by default, so lots of things you think might work, dont. (In my case I was trying to use quilt as a patch manager to make patch maintenance easier) - if you run "PSEUDO_UNLOAD=1 bash" in your devshell first it takes you out and sorts a few things. Apr 11 13:31:26 if that isn't documented, it should be Apr 11 13:31:47 Jin^eLD: if you want to use a feed then you have to run a pr server Apr 11 13:32:10 rburton: my question is if that also works fine for multimacine configurations? Apr 11 13:32:49 I am building feeds for two different machines, but same distro Apr 11 13:34:33 Jin^eLD: it's tested regularly with that use case, so it should yes Apr 11 13:36:13 thx, I guess I will have to rebuild my feed now, yesterday I already had the feeling that not all of the packages got updated... Apr 11 13:47:54 Jin^eLD: multi-machine builds are OK, problem is with multi-builder builds populating the same feed Apr 11 13:48:14 Jin^eLD: then you need to use shared PR server and there is no access control for bumping the values there Apr 11 13:48:32 I think I am fine in that regard, luckily we use only one builder Apr 11 13:49:07 but one more question, I did not fully understand that from the docs... do I need to reset all my existing PRs to zero? or can they stay at whatever value they have now until the next PV bump? Apr 11 13:52:57 they should stay until you bump PV Apr 11 13:53:06 otherwise overall version will go backwards Apr 11 13:54:30 ok, so the PR server just incrrements existing PRs, got that Apr 11 13:54:31 thanks Apr 11 14:28:56 one more question regarding PR server... so let's say I have a recipe with SRC_URI="file://somescript" and I then change the contents of "somescript" - will it bump the PR automatically? or do I still need to bump manually for changes that are done outside the .bb recipe? Apr 11 14:29:43 it should bump it automatically Apr 11 14:31:26 thx Apr 11 15:02:32 kergoth: are you around by chance? Apr 11 17:12:03 damnit bitbake Apr 11 17:13:05 RP: so, any idea how 'd' could be undefined in ${@}? we add it to that context pretty early.. Apr 11 17:13:16 RP: i know i've seen it once before, when i was programmatically generating vardeps Apr 11 17:13:19 but this time, not so much Apr 11 17:13:20 RP: https://gist.githubusercontent.com/kergoth/10485100/raw/91924061f569258fd8123d46f293c59172b09e36/gistfile1.txt Apr 11 17:14:36 kergoth: it's probably not helpful for the error, but surely something like that would be better implemented in a proper python function and then called from there? Apr 11 17:15:23 d would still have to be passed into that function, and presumably it'd still get a nameerror trying to pass it to it Apr 11 17:15:26 though its worth a shot Apr 11 17:15:36 worst case i can just anonymous python func it Apr 11 17:15:53 but there still seems to be some sort of bitbake bug lurking Apr 11 17:16:17 it does seem like a bug yes Apr 11 17:16:53 I think we have situations where exceptions in the wrong place during parsing can trigger odd failures like this one Apr 11 17:17:01 also, that stupid thing where it acts like it coudln't find the terminating ' when you use things like '${FILES_${PN}}' has been biting us for years Apr 11 17:17:06 need to fix that at some point Apr 11 17:17:25 kergoth: I can't think offhand why that would break :/ Apr 11 17:18:43 trying to fix the external toolchain recipe to use explicit file lists, so it stops picking up additional libs that are sometimes shipped with the toolchain.. at hte moment, our latest has liburcu and lttng crap i'd rather not have leaking into the libc6 packages ;) Apr 11 17:19:24 and there it is, EOL while scanning string literal Apr 11 17:19:28 i really hate that one Apr 11 17:33:13 Do FILES_* support wildcards at all? Apr 11 17:33:34 It seems like being able to give names like libc.* might simplify life. Apr 11 17:35:45 not only do they support wildcards, nearly every files var already uses them Apr 11 17:35:48 see bitbake.conf Apr 11 17:35:57 :) Apr 11 17:35:58 ... I probably knew that, then. <-- it has been a long week Apr 11 19:02:49 kergoth: I think if CSL would use OE to generate their SDKs all problems will be solved :) Apr 11 19:03:15 heh :) Apr 11 23:42:32 hello Apr 11 23:44:44 if I set BB_GENERATE_MIRROR_TARBALLS to 1 after downloading and building everything, is there a way to make bitbake go back and generate the tarballs? Apr 12 02:13:39 Hi everyone, i have yocto running in DE2i-150 board from terasic, and I need to install an camera through usb. Does anyone knows how to do it at yocto Apr 12 02:13:40 ? **** ENDING LOGGING AT Sat Apr 12 02:59:59 2014