**** BEGIN LOGGING AT Tue Jul 01 03:00:01 2014 Jul 01 06:24:58 for multiple patches, can I squash them together into *one* patch.gz file? then during do_patch() stage, extricate them all, apply one by one. Jul 01 06:27:39 why would you? Jul 01 06:27:55 that's a maintenance nightmare when updating the recipe Jul 01 06:38:08 koen: ok, fine.. I thought compressed tarball could save disk space, network bandwidth Jul 01 06:49:10 just put the patches in the metadata repo Jul 01 06:49:19 git will compress them Jul 01 07:09:54 good morning Jul 01 07:24:44 good moning Jul 01 07:52:50 Question: I have the following line in my fooimage.bb ---> IMAGE_BUILDNR="${@file('${WORKDIR}/../buildnr').read().strip()}" Jul 01 07:53:22 the problem is that when you try to build that fooimage for the first time ${WORKDIR} does not exist... and the recipy fails... it's a chicken egg problem Jul 01 07:54:05 where can teamcity drop a file (that contains the build#) that my image recipy can pick up Jul 01 07:59:55 ${OEROOT} Jul 01 08:24:27 pompomJuice: is this file under source control? Jul 01 08:25:10 no it is dumped by teamcity Jul 01 08:25:17 every time the build kicks off Jul 01 08:25:20 I found a way Jul 01 08:25:22 ok. you can use auto.conf maybe? Jul 01 08:25:30 it's loaded by bitbake.conf Jul 01 08:25:30 explain Jul 01 08:25:39 like local.conf Jul 01 08:25:44 and all variables inside auto conf is available for my recipies? Jul 01 08:25:49 e.g. /conf/auto.conf Jul 01 08:25:51 yep. Jul 01 08:25:56 ok awesome Jul 01 08:26:01 that is what I actually wanted to do Jul 01 08:26:14 my solution works but it is at the wrong places Jul 01 08:26:55 and from the manual: "auto.conf: This file is not hand-created. Rather, the file is usually created and written to by an autobuilder" Jul 01 08:27:59 also, keep in mind it's loaded *before* local.conf. so local.conf can override variables you set in auto.conf Jul 01 08:30:44 aah Jul 01 08:30:45 I see Jul 01 08:30:46 Thanks man Jul 01 08:30:53 This is what I have been trying to do Jul 01 08:31:03 and since it is not a new problem I was sure I was doing it wrong Jul 01 09:48:02 hmm, is FEED_DEPLOYDIR_BASE_URI still used ? Jul 01 09:48:16 (hello there) Jul 01 10:46:36 postgresql is failing to build Jul 01 11:02:16 do I really need poky to run toaster? Jul 01 11:08:27 Crofton|work: if you don't run poky every bug you file for it will be WONTFIX :( Jul 01 11:08:40 Crofton|work: I have a few disgruntled angstrom users due to that :/ Jul 01 11:08:49 I file bugs and they do not say WONTFIX Jul 01 11:09:01 mine say NEEDINFO Jul 01 11:09:05 can you point me at specific bugs? Jul 01 11:09:33 and fwiw toaster started Jul 01 11:09:48 now to see if it will tell me why someone is building postgres Jul 01 11:11:45 I'd expect to see you added as a cc: though Jul 01 11:12:29 I stay away from yocto bugzilla Jul 01 11:12:58 comment #3 will always be "can you repeat everything because we didn't read the report" and mark it NEEDINFO Jul 01 11:13:16 I did fairly well with my wic fail Jul 01 11:13:49 I need to go read the last remark, but it seems like someone pointed out why it gave me a traceback Jul 01 11:18:54 gm Jul 01 11:19:03 gm Jul 01 11:26:22 weird Jul 01 11:26:51 I am trying to use toaster to see who wants postgresql, but the page shows no reverse build dependencies Jul 01 11:27:54 hmm, what are reverse build dependencies? Jul 01 11:38:15 Crofton|work: "users" ? Jul 01 11:39:07 I think, I suspect my problem is starting toasters on a dirty tmp or soemthing Jul 01 11:39:25 Or provider? if A depends on B, B provides for A. Jul 01 11:39:45 If I extend the kernel with a custom driver and this driver has userspace-exposed "uapi" includes, how do those propogate into sysroot? Jul 01 11:40:17 manually? Jul 01 11:41:59 likewise you mean like i2c-dev.h? Jul 01 11:42:13 I suppose I should figure out how to fix postgres Jul 01 11:42:27 crofton sure you will do it Jul 01 11:42:36 woglinde: yes Jul 01 11:42:58 woglinde: Is i2c-dev.h from linux-libc-headers? Jul 01 11:43:02 haha Jul 01 11:43:06 yes Jul 01 11:43:19 but that will not compile your i2c userspace programs Jul 01 11:43:34 you will need the i2c-dev.h from lm-sensors Jul 01 11:43:37 project Jul 01 11:43:44 you could look at debian Jul 01 11:43:49 how they solved it Jul 01 11:43:58 with some alternatives stuff Jul 01 11:44:31 Let me ask differently. The kernel 3.7+ has the uapi/ folder, which supposedly installs when you run make headers_install in the kernel stuff. Jul 01 11:44:49 interesting, I didn't know that Jul 01 11:45:41 So basically, when I add a new driver with a custom IOCTL, I need to make linux-libc-headers use the actual kernel headers. However, this would make the C library machine-dependent (see the big fat warning RP added to linux-libc-headers) Jul 01 11:47:18 likewise: it's happening right now with ubiblock Jul 01 11:47:29 the ioctl is in headers > 3.15 Jul 01 11:47:54 it's an uapi one, ubi-user.h Jul 01 11:48:07 I have a new problem now... since I tag my IMAGE_BASENAME with my build nr the files seem to hang around forever since the previous behaviour was to overwrite the image... Jul 01 11:48:37 likewise: the 'trick' is, mtd-utils do ship own copy of the ehader Jul 01 11:49:01 will be out of sync sooner or later obviously, already happened Jul 01 11:49:11 so it's just a band-aid waiting for new kernel Jul 01 11:49:14 ant_work: the 'danger' to me seems, what if the IOCTL is not supported by the running kernel (-EINVALID?) Jul 01 11:49:31 well, normally the prog doesn't compile... Jul 01 11:49:54 in fact, I've seen different behaviors, depending on the libc Jul 01 11:50:36 as it is, mtd-utils in oe-core should not compile...the ioctl is missing Jul 01 11:51:03 the trick is passing the directory as -I.... so it finds the custom header Jul 01 11:51:32 klcc/klibc cannot be tricked so easily ;) I'm building with 3.15 headers Jul 01 11:52:29 ant_work: I am aware of the trick of including from /usr/src/kernel/, but that should be used only by out-of-kernel modules, not user-space AFAIK. Jul 01 11:52:57 not from there but from linux-libc-headers Jul 01 11:53:36 (see the reicpe, it's a make headers_install) Jul 01 11:53:58 hmm, linux-libc-headers has its own version Jul 01 11:54:17 likewise: in that way it's not machine-specific Jul 01 11:54:35 ant_work: some APIs break because of that (cf linux-dvb) Jul 01 11:54:52 and we're still not supposed to -I from /usr/src/kernel/include according to kernel doc Jul 01 11:55:10 right, I'm not suggesting that Jul 01 11:55:13 :) Jul 01 11:55:41 (I actually ran into this problem as well recently) Jul 01 11:56:08 ant_work: using linux-libc-headers makes the libc machine specific. In fact that's the actual warning now prepending in linux-libc-headers.inc Jul 01 11:57:25 maybe I misunderstand you. See, we build klibc against linux-libc-headers and not against kernel to avoid th emachine-specific issue Jul 01 11:57:38 stock linux-libc-headers Jul 01 11:59:06 ant_work: understood Jul 01 11:59:19 ant_work: now I add a custom driver to my kernel, with a new IOCTL. Jul 01 11:59:40 ant_work: In fact, shitloads of them... Jul 01 11:59:49 (escuse le mot) Jul 01 12:00:09 I am also interested in a solution to this issue :) Jul 01 12:00:48 it seems like something has changed wrt to libxml2 and/or its detection Jul 01 12:01:40 Now, there is nothing libc specific about an IOCTL, it's just that linux-libc-headers are the only kernel uapi headers that are exposed to userspace. The actual kernel UAPI does not end up in userspace... Jul 01 12:02:10 right Jul 01 12:02:43 likewise, we should bug zediii in #yocto Jul 01 12:02:48 I want to prevent copying my UAPI headers somewhere else. Jul 01 12:02:52 he is in my TZ so he might wake up soon Jul 01 12:03:05 your question remains valid: what if the kernel doesn't have that ioctl and userspace *somehow* has? Jul 01 12:03:34 this should not happen by design ofc Jul 01 12:03:36 ant_work: yes, but that's not my main concern (although valid) Jul 01 12:05:13 likewise, I'm assuming this is for the soc fpga type of systems? Jul 01 12:05:19 likewise: one idea could be to do like klibc, you copy the linux-libc-headers part of interest under another subdir and refer to that one (you can extend/customize it) Jul 01 12:05:23 where you have drivers for user defined hardware :) Jul 01 12:08:27 Crofton|work: FPGA type of systems, not SoC per se. Jul 01 12:08:38 Crofton|work: but could relate to any h/w Jul 01 12:10:41 postgrsql has the bincofngi problem Jul 01 12:11:59 ant_work: do you have a pointer to the klibc approach? Jul 01 12:12:43 maybe this: http://cgit.openembedded.org/meta-openembedded/tree/meta-initramfs/recipes-devtools/klibc/klibc-2.0.3/klibc-linux-libc-dev.patch Jul 01 12:12:52 ant_work: I may decide to extend my kernel recipe to perform the header_install, then populate sysroot include/linux with the uapi headers, but this will be dirty... Jul 01 12:13:05 one recipe must install th eextra stuff Jul 01 12:13:17 just build klibc and see how it stages headers Jul 01 12:14:31 here i.e. I've added ../../../include/mtd Jul 01 12:14:52 exactly because the package-headers are out of sync with OE Jul 01 12:21:04 likewise: seems messy indeed Jul 01 12:22:07 actually I dont know where we should have the kernel headers installed ... we wouldnt want to override libc-headers for everyone/every package I guess Jul 01 12:22:19 and yet we want something kinda reusable Jul 01 12:30:23 ant_work: v Jul 01 12:30:33 bencoh: See the "[yocto] Exporting kernel header from patch" discussion in April. Jul 01 12:31:18 (hmm, why is that on yocto and not on OE-core ?) Jul 01 12:31:31 If you do need to export something to the sysroot, that isn't already in the libc-headers, and you can't use the STAGING_KERNEL_DIR, then you should be installing it to another directory structure like: /usr-alt/include/linux/* and have your applications look there. Jul 01 12:31:49 bencoh: it probably is, this is a discussion, not the implementation. Jul 01 12:31:59 oh 'kay :) Jul 01 12:32:26 Bruce Ashfield seems working on this: "I have an open enhancement that I'm doing for yocto 1.7 which automates the alternate header file structure, but doing it explicitly in your recipes will work for now." Jul 01 12:33:39 hmm, nice, if that's done properly and ends up in oe-core :) Jul 01 12:33:58 I need pro advice again... I added a build nr to my image name which has caused the images to consume diskspace as previously it just overwrote the same name every time. Jul 01 12:34:29 There are some sort of symlink business going on but it is not doing what I would like it to do which is ln -s image.ext4 image.basename.ext4 Jul 01 12:34:42 basename contains a rolling counter Jul 01 12:34:47 but the symlinks wont take up much space Jul 01 12:35:14 likewise: it look sto me you have the two options: 1) play with kernel unanitized headers -> machine-specific or 2) copy somewhere the headers Jul 01 12:35:33 or symlink it as we do with klibc Jul 01 12:37:33 likewise: option #3 push all upstream -> no extra-headers :p Jul 01 12:37:40 ant_work: Jul 01 12:37:41 PACKAGES += " kernel-extra-headers" Jul 01 12:37:43 FILES_kernel-extra-headers = "/usr-alt/linux/*' Jul 01 12:38:27 yes, something like that or under usr Jul 01 13:23:01 is the monthly OE meeting on for today (in roughly 2.5 hrs)? Jul 01 13:31:25 * Crofton|work summons the TSC Jul 01 13:35:18 tlwoerner, I've tried emailing them Jul 01 13:35:39 I'd be surprised if any of them are working though Jul 01 13:36:05 anyway, aren't you on holiday also today? Jul 01 13:44:59 anyone know where I can find a chronyd developer on IRC? Jul 01 14:17:09 Crofton|work: technically yes, but since i don't have much in the way of plan for today... :-) Jul 01 14:17:57 Crofton|work: why wouldn't the others be working? is it a holiday in the UK and/or the US too? i thought the US holiday would be in 3 days? Jul 01 14:18:21 people tend to take the week off Jul 01 14:28:42 ya, I have a lot of coworkers who have the week off.. (both Canada and US) Jul 01 15:43:10 so... do we think this month's meeting might be a wash? Jul 01 15:47:24 I am going to be available to take comments/questions and discuss topics.. Jul 01 15:47:44 but unfortunately many of the other TSC members (and community members in general) appear to be on vacation this week.. Jul 01 15:47:55 I know the meeting today "snuck" up on me.. I was thinking it was next Tuesday Jul 01 16:03:24 looks like the meeting started 3 minutes ago (?) Jul 01 16:04:30 tlwoerner that accounts for all the chatter Jul 01 16:06:00 Sorry.. I had to step away from my desk.. Jul 01 16:06:17 let me repeat what I said earlier for those who might have joined us for the OE-TSC meeting.. Jul 01 16:06:23 I am going to be available to take comments/questions and discuss topics.. Jul 01 16:06:27 but unfortunately many of the other TSC members (and community members in general) appear to be on vacation this week.. Jul 01 16:06:31 I know the meeting today "snuck" up on me.. I was thinking it was next Tuesday Jul 01 16:06:51 so if anyone would like to discuss anything the floor is open and I'll be around... Jul 01 16:07:37 I will mention one status item. The first milestone of development within the Yocto Project community (which of course affects oe-core as well) has completed, and the second milestone has begun Jul 01 16:07:47 ah... summertime :-) Jul 01 16:07:56 tlwoerner: ya pretty much.. Jul 01 16:10:21 fray: https://wiki.yoctoproject.org/wiki/Yocto_1.7_Schedule Jul 01 16:11:42 yup.. that is the correct link.. M1 development completed last week, stabilization is in progress.. M2 planning/development began yesterday Jul 01 16:12:08 In reality that shouldn't affect OpenEmbedded users "much", other then to show the flow of patches and bug fixes from the Yocto Project engineers.. Jul 01 17:02:07 koen, I'm confused by your comment on the postgresql patch Jul 01 17:02:34 which one? Jul 01 17:02:42 th epgac_option thing is how they extract the include flags and libs from the output of xml2-config Jul 01 17:03:53 it's a filter function Jul 01 17:04:12 it looks like a stupid and misguided filter function, but it's one nonetheless Jul 01 17:04:28 so if you drop it, make a note in the commit message Jul 01 17:04:43 like "cflags only has safe values" Jul 01 17:05:35 notice how it will drop -lfoo on the floor Jul 01 19:29:16 what bitbake version is recommended with daisy? Jul 01 19:34:45 cbrake, 1.22 Jul 01 19:34:47 cbrake, https://wiki.yoctoproject.org/wiki/Releases Jul 01 20:01:31 * fray finally finishes testing the RPM 5 uprev and sends patches.... **** ENDING LOGGING AT Wed Jul 02 03:00:00 2014