**** BEGIN LOGGING AT Fri Aug 23 02:59:59 2013 Aug 23 07:30:11 For some recipes, I get the error 'Recipe file does not have license file information (LIC_FILES_CHKSUM)'. Is there a way to fix this (certainly for recipes that only contain my own code and that don't have a license file)? Aug 23 07:31:03 hm? Aug 23 07:31:09 add a license file Aug 23 07:31:20 and than add the md5sum Aug 23 07:31:24 in the recipe Aug 23 07:31:41 TimSmith: depends; if you're not planning on publishing the recipe or the source then you can set LICENSE = "CLOSED" which will disable the check Aug 23 07:31:54 TimSmith: otherwise, you'll need to do what woglinde says Aug 23 07:33:29 gm bluelightning Aug 23 07:33:36 morning woglinde Aug 23 07:33:41 morning all Aug 23 07:34:54 Ok, thanks! Aug 23 08:52:40 good morning, i have finally managed it to cross-compile octave for armv7hf, now i'm facing another problem, i need to define a PREFERRED_PROVIDER for libfftw, so opkg can resolve the dependencies corretly for octave, but where should i put the definition of PREFERRED_PROVIDER ? Aug 23 08:58:29 local.conf Aug 23 08:58:49 otherwise it is upon the distribution to set it Aug 23 09:04:27 woglinde: in build/conf/local.conf ? Aug 23 09:04:57 because i already have PREFERRED_PROVIDER_libfftw3 = "ttfw" in it Aug 23 09:19:01 thesignal porblem solved Aug 23 09:19:56 woglinde: no, i found out i had a typo in my local.conf, but still no luck Aug 23 09:21:41 hm? Aug 23 09:21:59 than run bitbake -e or bitbake -DDD to find out Aug 23 10:04:55 lhi all Aug 23 10:05:54 lhi pb_ :) Aug 23 10:06:35 bluelightning: lgood morning Aug 23 10:21:31 hi pb Aug 23 10:22:49 pb_: hello Aug 23 10:23:03 pb_: I could get RP fix the symlink generation ;) Aug 23 10:23:38 pb_: now I still have major conceptual issues with klibc, though ;) Aug 23 10:24:52 fundamentally it is still machine-specific if the symlinks substitution points to sysroot/machine :/ Aug 23 10:28:06 now I have to understand if I'm allowed to get the headers from STAGING_DIR_HOST instead of KLIBCKERNELSRC=${STAGING_DIR_TARGET}${exec_prefix} Aug 23 10:28:52 the variable is misnamed out of context: it points to installed linux-libc-headers-dev Aug 23 10:33:55 ant_work: very good! Aug 23 10:34:39 on the machine-specific thing, yes, this is true, and this might be another reason that copying the headers rather than linking them would be a better plan. Aug 23 10:36:35 ${STAGING_DIR_HOST} and ${STAGING_DIR_TARGET} will be the same (for non-native anyway) so I don't think using the former variable will help much. Aug 23 10:37:14 pb_: All that needs to happen is to make the symlink relative Aug 23 10:41:32 RP: ah, yes, right. Aug 23 10:44:36 ericben: eny eta on dylan-next next merge? no rush, I just need some date to plan layer upgrade (if I should bump oe-core revision now and meta-oe later or wait a bit more and bump both together) Aug 23 10:48:10 * bluelightning is working on removing busybox bbappend btw, I think I now understand the issue completely Aug 23 10:49:33 pb_: the other issue is that the absolute symlink makes it into the klibc-dev package. Making it relative solves that too Aug 23 10:49:52 We should probably have a sanity check for that kind of insanity Aug 23 10:50:00 yes, good plan Aug 23 10:50:03 bluelightning: what was the issue? Aug 23 10:50:25 this is the weird bit of syslogd policy, right? Aug 23 10:51:11 pb_: I hadn't quite appreciated that the /etc/default/busybox-syslog file that the meta-oe bbappend was providing was also enabling the shared memory buffer logging not just setting the buffer size Aug 23 10:51:25 pb_: since that's apparently what -C does Aug 23 10:52:06 with sysvinit the default arguments are "-C" so we need to do the same for systemd as well Aug 23 10:52:42 I'll be adding -C though, not -C64 as the meta-oe bbappend does; people are free to override this in their distro layers Aug 23 10:57:59 RP: pb_: thx, i'll retry with a relative symlink Aug 23 11:00:57 there is this related thread going on btw; http://www.zytor.com/pipermail/klibc/2013-August/003438.html Aug 23 11:12:54 JaMa: btw, we have now removed any need for libx11-native in OE-Core. I'm aware that meta-qt3 does have a dependency. Do you know offhand how many other parts of the system depend on that? Aug 23 11:24:38 not offhand, but I'll try bitbake -g world on jenkins builder when it's finished with current build (20h+ eta) Aug 23 11:33:59 JaMa: FYI, OE-Core / meta-oe patches sent for busybox bbappend Aug 23 11:34:11 i have a linux-yocto bbappend which sets KERNEL_FEATURES_append = " features/aufs/aufs-enable.scc" - however, as soon as I do that, it appears that the build ignores several other kernel fragments (added using SRC_URI += ...) that are specified in various bbappend. If i remove the KERNEL_FEATURES_append, everything builds properly. I add it back and the kernel builds/packages fine, but I seemingly lose other config fragments which chok Aug 23 11:34:11 es when it goes to build the rootfs and realizes it is missing module dependencies. Any ideas? Aug 23 12:18:21 bluelightning: thanks a lot Aug 23 12:27:17 bluelightning: maybe worth mentioning that it lost "64" option, but otherwise fine with me Aug 23 12:27:55 ah you did mention it in .bbappend removal (i was reading oe-core addition) Aug 23 12:28:38 just out of curiosity do you know offhand what was default size? Aug 23 12:30:48 JaMa: 16 is the value we have in our defconfigs at the moment Aug 23 12:35:24 hi JaMa, for dylan-next I can merge it now if you want Aug 23 12:36:51 I also had a look at xserver-nodm-init... at first it looked straightforward but then I noticed x11-common vs. xserver-common :/ Aug 23 12:37:41 he he Aug 23 12:40:20 one of them must suffice Aug 23 12:41:16 xserver-common has a bunch of machine-specific stuff in it, that doesn't seem right Aug 23 12:42:50 and x11-common has formfactor since the begenning Aug 23 12:43:49 so it would be possible to clean out the mess of duplicate vars for screen/display Aug 23 12:50:26 bluelightning: whole purpose of upstream xserver-common is to contain machine-specific stuff Aug 23 12:50:58 still waiting for all the patches to be merged upstream so that it doesn't look wrong in meta-oe Aug 23 12:51:11 JaMa: indeed, having to patch a recipe in meta-oe for every machine isn't really right Aug 23 12:51:34 why aren't those patches added in bsp layers? Aug 23 12:52:01 are you saying you wouldn't accept a formfactor-based alternative if it had the same functionality? Aug 23 12:52:39 bluelightning: because all were sent to upstream couple months ago and they aren't really MACHINE specific, they should be applied for all MACHINEs Aug 23 12:53:14 bluelightning: I would if it has the same functionality Aug 23 12:53:24 well, they are in that you end up with a bunch of script code that's irrelevant for the machine you're running on Aug 23 12:53:34 it doesn't break things for other machines, I'll grant you Aug 23 12:53:46 bluelightning: until now it was missing: xinput-calibrator integration, nocursor flag, and IIRC something else Aug 23 12:54:33 bluelightning: it's one big script which was meant to support all machines (think of it as TUNE_PKGARCH package) Aug 23 12:55:08 hmm Aug 23 12:55:12 I'll see what I can come up with Aug 23 12:55:39 florian: it would really help if you merge xserver-common patches I've sent you 12 Apr 2012 :) ^^ Aug 23 12:56:17 why is the OBS preferable to one script per machine? It does seem like a rather fragile and unscalable way of solving the problem. Aug 23 12:57:25 JaMa: uh indeed... do me a favour and kick me more frequently then one time every half of a year ;) maybe during this weekend Aug 23 12:58:15 pb_: I'm convinved formfactor is a better approach myself Aug 23 12:58:23 convinced, that is Aug 23 12:58:39 assuming it can be made to do all the same things Aug 23 12:59:38 yes, agreed, that sounds like a better solution (for the things that it supports, anyway) Aug 23 13:01:15 I guess formfactor itself will always be a little bit of a pinch point for machines which need something more than it supports on any given day, but it still seems better than having to maintain a single überscript for all machines. Aug 23 13:03:32 pb_: bluelightning: I agree with you that form-factor is better aproach Aug 23 13:04:43 pb_: bluelightning: xserver-nodm-init and xserver-common were added to meta-oe to keep the functionality provided by oe-classic at that time (like many other xorg related recipes) Aug 23 13:05:13 JaMa: understood Aug 23 13:05:41 bluelightning: try to merge the # provide machine-specific /etc/rotation for psplash we have in formfactor.bappend in meta-hh Aug 23 13:06:40 ant_work: ok, I'll keep that in mind as well Aug 23 13:28:48 JaMa: perhaps I've missed something, but in http://pastebin.com/qtGcBg9z ; how come it apparently execs xtscal again at the end? Aug 23 13:32:07 bluelightning: you're right doesn't look correct, but I wasn't using xtscal for long time (since xinput-calibrator was added in oe-classic) Aug 23 13:35:48 JaMa: right, ok Aug 23 14:12:00 hmm, this is quite a rabbit hole Aug 23 14:12:45 florian: you've asked for it, I'll be pinging you whole weekend if I have to :) Aug 23 14:23:37 JaMa: patch is ready, it's in oe-devel Aug 23 14:23:54 eren: thanks Aug 23 14:34:46 JaMa: do you clean the build directory everytime you do minimum build? Aug 23 14:35:17 I try to reproduce the error on your logfile first before patching the recipe Aug 23 14:35:54 at some point, due to packages that were built, the dependency could be satisfied automatically Aug 23 14:40:14 and yeah, libcap dependency was satisified somehow previously and omgps was built successfully :) Aug 23 14:42:00 I'm wondering if there is a way to remove everything except cross-toolchain, instead of removing build directory and compiling cross-toolchain for every package Aug 23 14:47:09 eren: yes, there is the test-dependencies.sh script which does that for me Aug 23 14:47:46 eren: you can keep sstate-cache between builds, so cross-toolchain will be just unpacked from sstate Aug 23 14:51:52 JaMa: hm, so you are proposing compiling cross toolchain, copyting sstate-cache to somewhere, remove build directory and copy back? Aug 23 14:53:03 I would appreciate your workflow on this issue :) Aug 23 14:55:55 check the script, you don't need to copy anything, just remove tmp-eglibc between the builds and use -c cleansstate if you need to force rebuilding some component (instead of reusing it from sstate) Aug 23 16:33:30 ok, this is too big a job for 1.5, I guess we'll have to live with the split for the moment :/ Aug 23 16:34:14 maybe I can at least eliminate some of the differences in xserver-nodm-init itself though Aug 23 16:46:13 morning Aug 23 16:48:09 hi chouimat Aug 23 17:47:21 ericben: take your time to run usually build test for dylan-next, I'm quite confident with changes I've sent, but no need to rush it in, next week is good enough for me Aug 23 22:14:03 did anyone book hilton for elce? Aug 23 22:44:26 denix: me Aug 24 02:11:06 Hilton? Aug 24 02:11:11 I need to book **** ENDING LOGGING AT Sat Aug 24 02:59:58 2013