**** BEGIN LOGGING AT Sat Apr 27 02:59:58 2013 Apr 27 07:30:51 morning all Apr 27 08:20:24 hi bluelightning Apr 27 08:20:33 hi pb_ Apr 27 08:20:37 hi all Apr 27 11:25:47 bluelightning, do you have any thoughts on tune setting in machine files versus local.conf? Apr 27 11:26:39 Crofton|work: setting up available tunes is a machine config setting; the default tune is a distro setting Apr 27 11:26:56 Crofton|work: (based upon the recent discussion) Apr 27 11:27:13 this is annoying for people doing distroless builds :) Apr 27 11:27:41 well, you can't really do distroless builds and expect to set distro policy... Apr 27 11:27:57 I'm guessing it is hard to set in a machine file and overrride from a distro file? Apr 27 11:28:08 not sure, I've never tried Apr 27 11:28:31 you _can_ set most distro policy settings from local.conf, but for reproducibility it's advisable not to set too much there Apr 27 11:28:55 I susppose I should experiment one day Apr 27 11:43:24 I don't suppose there's any great harm in machine config files setting DEFAULTTUNE ??=. If the distro config sets it then it's going to win, and if the distro config doesn't then getting the machine default doesn't seem worse than any other option. Apr 27 11:44:19 But, in general, I agree with Paul: if you want to apply a distro policy then building distro-less is a bad place to start. Apr 27 11:44:21 pb_, thanks Apr 27 11:44:46 sure, I just want bsps to work, without depending on settings in local.conf Apr 27 11:45:05 but I don't want bsp's annoying the crap out of distro people eitehr Apr 27 11:48:34 btw: would anyone object if we make tune-cortexa9 to include tune-cortexa8 instead of arch-armv7a.inc? Apr 27 11:50:01 the reason to do it is that distros with cortexa[89] devices who want to build shared feed (cortexa8 as commod denominator) need to modify machine config in BSP layer which includes only tune-cortexa9 Apr 27 11:50:29 can't they just include tune-cortexa8 directly? Apr 27 11:50:44 BSP? Apr 27 11:50:58 distro Apr 27 11:51:28 including cortexa8 doesn't seem all that unreasonable in itself, but where do you stop? what about distros that want to build for cortexa9 and, I dunno, strongarm or something? Apr 27 11:51:47 that won't work if they also have some MACHINE which isn't cortexa[89], e.g. qemux86 Apr 27 11:52:16 because of the different TARGET_ARCH, you mean? Apr 27 11:52:32 and there are bad side effect when something is included twice.. Apr 27 11:53:03 https://github.com/shr-distribution/meta-smartphone/blob/shr/meta-samsung/conf/machine/tuna.conf Apr 27 11:53:47 including tune-cortexa8.inc from BSP and then tune-cortexa9.inc doesn't work, because double inclusion of arch-armv7a.inc makes sstate checksums different again Apr 27 11:54:17 that's why I need to include tune-cortexa8.inc and then just parts of tune-cortexa9.inc Apr 27 11:54:19 yeah, the double inclusion thing probably wants a more general fix, in bitbake I guess. we already guard against double inheriting of classes, and this doesn't seem conceptually different to that. Apr 27 11:57:46 that would be nice Apr 27 11:58:22 * JaMa wondering how many times something is included/required for 2nd+ time and replaces some assignment Apr 27 11:59:30 * JaMa seen some distro configs which were including stuff like tcmode after it was included by default-setup.inc and that was duplicating all *FLAGS in environment.. Apr 27 11:59:52 yeah, or adds a double copy of its bits to some variable it's appending to. I can't actually think of any .inc files offhand that you'd actively want to include multiple times, though no doubt there is one somewhere. Apr 27 12:00:03 right Apr 27 12:00:44 well, patches welcome no doubt. or you could file a bug in the yocto bugzilla and see what the h4x0rs think of the idea. Apr 27 12:01:58 it probably wouldn't be all that hard to do, invent a new "include_once" keyword and have bitbake just maintain a list of the files it's already included. Apr 27 12:09:25 added as #4425 Apr 27 12:12:19 very good Apr 27 12:19:55 * pb_ heads to the plumbing merchant Apr 27 12:19:59 later Apr 27 12:25:25 JaMa: you could probably determine that using the history output now produced by bitbake -e Apr 27 12:26:28 yes you can find it if you know what you're looking for and new bitbake -e is very handy for that Apr 27 12:27:45 it would probably not be hard to write a tool that makes use of that data to warn when that situation occurs Apr 27 12:29:04 isn't it easier to warn when bitbake parser is trying to include something already included? Apr 27 12:30:04 and also showing which file+line was trying to include something would be really nice Apr 27 12:31:02 detection of such places is 1st part, but sometimes it's not easy to fix it (like with that cortexa8+cortexa9 include) Apr 27 12:49:39 well, if we enabled history always it would noticably impact performance Apr 27 12:50:06 detecting including the same file twice might be worthwhile however Apr 27 13:32:06 Im trying to find "best practise" for doing development on this application, that uses a root image generated by OE Apr 27 13:33:12 The application handled in a git repository. I have a bitbake recipe that uses the git repo as source, with SRCREV = "${AUTOREV}" Apr 27 13:33:35 bluelightning: what do you think about changing default BUILDHISTORY_DIR from TMPDIR to "${TOPDIR}/buildhistory" ? Apr 27 13:34:00 bluelightning: it's annoying that people with existing checkouts need to move it first (in order to save history) Apr 27 13:34:25 bluelightning: but like PERSISTENT_DIR I find it more persistent then tmpdir-eglibc.. Apr 27 13:46:55 But still, bitbaking the application seems to use the cached sstate data, building doesnt "git pull" new changes. I need to clear the sstate cache manually each time Apr 27 13:52:58 So, using "PV = "1.1+gitr${SRCPV}"" in the recipe might do the trick.. Apr 27 13:57:38 hi all Apr 27 14:11:03 have anyone seen PNBLACKLIST not working for some recipes and working fine for other? it's really weird Apr 27 14:17:38 hmm deleting cache helps Apr 27 14:39:17 hmm trying to port a tricky recipe into a distro layer here, would appreciate some help Apr 27 14:39:48 the recipe in question is xorg-headers-native.bb: http://git.openembedded.org/openembedded/tree/recipes/xorg-lib/xorg-headers-native.bb?h=2011.03-maintenance Apr 27 14:40:38 the problem is that SRC_URI just points to a bunch of header files in a local directory: http://git.openembedded.org/openembedded/tree/recipes/xorg-lib/xorg-headers-native/X11?h=2011.03-maintenance Apr 27 14:40:51 is this recipe still needed? Apr 27 14:41:55 JaMa: yes, in my distro layer Apr 27 14:42:34 ok I thought that libx11-native etc made it deprecated Apr 27 14:44:11 JaMa: ha, don't know about that, the jlime distro I'm porting to oe-core seems to need it Apr 27 14:46:35 anyway, bitbake is complaining about the way SRC_URI is used (error mesage is "ERROR: Fetcher failure: Unable to find file file://xorg-headers-native/X11 anywhere" -> http://paste.debian.net/623/) Apr 27 14:47:13 so I changed SRC_URI to FILES_${PN} instead: http://paste.debian.net/622/ Apr 27 14:47:23 apelete: that's probably because there is only BP/BPN in default FILESPATH Apr 27 14:47:50 JaMa: how should I fix it then ? Apr 27 14:48:07 that change doesn't make much sense Apr 27 14:48:28 add PN to FILESPATH or move files to be in xorg-haders/X11 Apr 27 14:48:58 but I still believe that it's wrong to add that recipe back Apr 27 14:51:31 JaMa: ok. I'll consider updating to libx11 if I manage to get it to work. I'm trying to rebuild the distro on oe-core as close as possible to what has been done in oe-classic in the first place Apr 27 14:52:19 if I start updating packages right now, I fear I won't be able to pinpoint why something is broken if that happens Apr 27 14:53:24 JaMa: thanks for helping :) Apr 27 14:53:44 hmm I would advise to start with as close to oe-core as possible and add only distro-specific bits really needed Apr 27 14:53:57 most issues are usually from trying to do stuff old-way Apr 27 14:57:16 JaMa: so you suggest I should start by (re)building a BSP and only then add distro-specific bits ? Apr 27 14:58:18 yes Apr 27 14:58:48 when you get console-image booting on your devices with new BSP then you know that BSP is good Apr 27 14:59:22 then add distro bits needed to build packages from old distro images and see what apps are working etc.. Apr 27 15:00:29 I am going to flip DNS from dotster to amazon now Apr 27 15:00:39 No one should notice anything Apr 27 15:00:53 if something goes south, send me an email :) Apr 27 15:01:05 JaMa: ah, you're the second person to give me that advice. that's interesting... Apr 27 15:01:06 I double checked the important numbers Apr 27 15:02:38 I mean, I didn't consider it because it sounds harder in the first place, but given the sheer number of packages that I'm now trying to fix, I'm beginning to reconsider my approach Apr 27 15:06:35 JaMa: I guess I wouldn't be opposed to changing the default BUILDHISTORY_DIR Apr 27 15:08:50 apelete: well you will get *a lot* of changes just from switching from oe-classic to oe-core, so even when trying to stay close to what you had in oe-classic you will get too many changes at once Apr 27 15:09:25 apelete: so it will be hard to find out what broke something (newer gcc, eglibc, different flags, different versions) Apr 27 15:09:48 apelete: if you start from existing tested images and configs you can at least test it step by step Apr 27 15:10:01 bluelightning: ok, I'll send patch for it Apr 27 15:17:39 JaMa: what you say sounds logical and makes sense Apr 27 15:19:52 I'll backtrack and try to build a working BSP then Apr 27 15:21:38 it's hard to admit because I've been working on porting the distro for a month now, but it's probably the best way to go, as you said Apr 27 15:23:13 JaMa: thanks for the advice, let's see how it goes Apr 27 15:28:32 In a recipe, is it possible to get the in-use kernel major and minor version numbers ? Apr 27 15:33:22 jkroon: e.g. module-base.bbclass exports KERNEL_VERSION Apr 27 15:34:09 then you can use split like KERNEL_PRIORITY in kernel.bbclass to parse it Apr 27 15:50:33 JaMa, do I need to export variables in the recipe, in order to make them available inside the do_install () functions etc ? Apr 27 15:51:05 hmm, are recipes really sort of bash-scripts ? Apr 27 16:36:41 bits of them are shell scripts, but the recipe itself isn't really. Apr 27 16:38:21 ok Apr 27 16:38:52 jkroon: you don't need to export them to use them in do_install() (bitbake will expand them there) Apr 27 16:39:09 jkroon: you need to export them only if you want them exported in shell environment Apr 27 16:39:23 jkroon: e.g. for configure script to read them from environment Apr 27 16:39:34 JaMa, aha, makes sense Apr 27 16:40:55 i rebuild packages on my laptop. instead of writing a new image to the sd-card of my rpi, it would be nice if I could update the installed packages on my rpi via TCP/IP or something Apr 27 16:41:07 Is there a common procedure for doing that, described somewhere ? Apr 27 16:43:34 The idea that comes to mind is having 'rpm' installed on the target, and using an ftp server on my laptop or something like that Apr 27 16:47:06 yeah, you can certainly do that. I would have thought it should be described in the yocto wiki somewhere. Apr 27 16:54:22 why not just use an ipk feed on the laptop? Apr 27 17:00:02 nerdboy, doh, looks like common way is to use an apache server on the host Apr 27 17:00:59 would be nice if could just ftp over some rpms, and the target would automatically refresh the installed rpm. not as fancy with all the dependency handling, but it would suffice for me since im only updating the application Apr 27 17:11:04 * nerdboy needs to get out more Apr 27 17:11:17 out of the oe-classic world... Apr 27 17:14:48 hmm, according to the yocto release notes it can do multiple package formats Apr 27 17:15:02 maybe i'll try deb packages next time... Apr 27 17:17:28 i think wormo was right... we need to move our project off of arago and use yocto instead Apr 27 17:46:39 n Apr 27 17:57:39 * nerdboy bites the bullet and clones yocto to make a pi image Apr 28 01:18:24 My application ships with a couple of .so-files in /usr/lib. Can I force them to go into the application package, and not in the dev package ? **** ENDING LOGGING AT Sun Apr 28 02:59:58 2013