**** BEGIN LOGGING AT Tue Dec 16 02:59:58 2014 Dec 16 09:39:50 morning all Dec 16 10:11:33 hey bluelightning Dec 16 10:11:59 hi mago_ Dec 16 10:12:35 whats up in intel-land? :) Dec 16 10:15:11 mago_: not too much, although there's plenty of things to do as usual :) Dec 16 10:16:03 does there exist some mechanism to prevent absolute filenames in .pc files? e.g. target 'fontconfig.pc' contains a -I/usr/include/freetype2 which results in -I//usr/include/freetype2 when running 'pkgconfig --cflags fontconfig' Dec 16 10:16:46 libkmod.pc contains such paths in -L which might create broken rpaths Dec 16 10:22:21 yes, pkgconfig supports variables like 'includedir' Dec 16 10:22:42 and OE should sanitize them when using pkgconfig.bbclass Dec 16 10:22:45 (iirc) Dec 16 10:25:18 pkgconfig.bbclass contains only a single line... (a DEPENDS) Dec 16 10:30:05 hmmm Dec 16 10:30:12 maybe it's in a different class now Dec 16 10:34:00 ant_work: hi Dec 16 10:34:12 hello Dec 16 10:34:27 ant_work: I've updated my linux repo on github, see v3.18-anarsoul-wip branch Dec 16 10:34:40 for h1940 you need everything except pxa stuff Dec 16 10:35:47 ok, thx, noted Dec 16 10:35:58 anarsoul|2: hey Dec 16 10:36:03 hi bluelightning Dec 16 10:36:04 waiting for yocto-3.18 Dec 16 10:37:01 btw Bruce promised a 'vanilla' branch for next release, better to ping him Dec 16 10:38:52 _ao2: don't you have some ezx patches as well? Dec 16 10:39:28 <_ao2> ant_work, not really Dec 16 10:39:59 I see Dec 16 10:40:38 heh, bluelightning is braking but I'd obsolete many kernels and recipes in meta-hh Dec 16 10:41:25 ant_work: I think we can probably go ahead and do that now for those machines that have never worked Dec 16 10:41:50 does bitbake still skip /obsolete and /non-working ? Dec 16 10:42:38 ant_work: well, my branch should work for rx1950 as well, I can test it tonight Dec 16 10:43:04 ant_work: it will (by virtue of BBFILES), but it's probably best to just leave them in a branch I'd say Dec 16 10:43:05 so at least one more machine can be moved from linux-handhelds Dec 16 10:43:13 anarsoul|2: great, thanks! Dec 16 10:43:37 lumag: ^ pls send one more invitation Dec 16 10:46:39 btw, as far as I know DT support was added for s3c24xx, so it's possible to build unified kernel (well, some minor patches are needed, e.g. for LCD power control) for all s3c24xx-based PDAs Dec 16 10:47:00 however, I didn't try it yet Dec 16 10:51:04 anarsoul|2, ant_work I need a github id then. Dec 16 10:51:21 bluelightning, from you too. Dec 16 10:52:11 mine is "anarsoul" (obvious :)) Dec 16 10:54:03 ant_work, or did you mean the asana invitation? Dec 16 10:56:38 LinuxPDA Dec 16 10:57:35 ant_work, done Dec 16 11:03:14 uh, I'm not good at github markdown... Dec 16 11:04:09 anarsoul|2, you can use html as well. Just name the file .html instead of .md Dec 16 11:04:26 .md is nearly like a wiki Dec 16 11:06:59 In front of the file comes a section with metadata (key: value lines between two three-dash-lines). They are used e.g. to generate the beautiful tables. Dec 16 11:09:50 ok, I've added h1940 Dec 16 11:11:18 anarsoul|2, why cpufreq is n/a ? Dec 16 11:12:35 lumag: well, it was never implemented in WinMobile, and in linux it's quite tricky to implement it, because LCD power (not backlight) is somehow depends on PWM Dec 16 11:13:18 and as far as I know it was broken recently during transition to new clk framework Dec 16 11:13:22 can you put that to comments (status-cpufreq-comment: .. Dec 16 11:13:31 ok Dec 16 11:14:51 <_ao2> ant_work, if you remove ezx stuff that's OK, just ping me so I can save them locally Dec 16 11:19:36 ant_work, what is the issue with ezx in meta-hh? Never tested? Dec 16 11:21:18 hm, looks like I broke it :( Dec 16 11:23:02 lumag: any idea what's wrong? Dec 16 11:24:24 ah, I guess metadata needs html-style links, not md Dec 16 11:25:22 anarsoul|2, yes. Dec 16 11:25:40 The error is very cryptic though. Dec 16 11:25:53 Spend few minutes trying to understand what is wrong. Dec 16 11:27:25 I guess git push --force is not acceptable way, so I'll just make 2 fixup commits? Dec 16 11:27:53 anarsoul|2, as you'd like . Dec 16 11:29:28 after that I'll change NA to N/A globally - the later makes more sense. Dec 16 11:30:40 lumag: done Dec 16 11:31:52 stupid question Dec 16 11:32:17 we are trying to set a static IP address in /etc/network/interfaces, but find it still wipes resolv.conf at boot Dec 16 11:32:22 HELP! Dec 16 11:32:30 yeah, customer on irc :) Dec 16 11:34:26 Crofton|work, maybe that's due to systemd-networkd? Dec 16 11:34:30 (wild guess) Dec 16 11:34:38 should be systemd free Dec 16 11:35:37 Crofton|work: connman? dnsmasq? file symlinked into /var/volatile? Dec 16 11:35:48 vpn client software ? Dec 16 11:35:55 core-image based Dec 16 11:45:42 byw, does anyone really use distcc? Dec 16 11:46:49 Crofton|work, I use icecc Dec 16 11:47:15 distcc shows up as part of the dev packagegroup I think, so hard to remove Dec 16 11:49:24 Crofton|work: it's not that hard to remove Dec 16 11:49:33 it's only added for qemu machines Dec 16 11:49:52 * Crofton|work is running on not enough coffee and customer questions to early Dec 16 11:50:02 weird, why does it end up in my image Dec 16 11:50:53 not sure, but the only way I know it ever gets into the image is via POKYQEMUDEPS, and that's only ever added to DISTRO_EXTRA_RDEPENDS for qemu machines Dec 16 11:51:14 well, that's by default anyway Dec 16 11:51:40 hmm, packagegroup-core-sdk does contain it as well Dec 16 11:51:56 yeah, that is the one that gets me Dec 16 11:52:06 we should discuss this Dec 16 11:52:23 I want to be able to build stuff, but distcc is overkill for most cases Dec 16 11:52:25 perhaps, but a lot of those packagegroups aren't going to be perfect for everyone Dec 16 11:52:54 it could be that distcc support isn't really commonly needed these days though Dec 16 11:53:31 that is my thought Dec 16 11:53:48 basically, I will end up rewriting it Dec 16 11:58:31 bluelightning, btw, the stand emails should go out today. If you do not see it let me know and I can prod the fosdem guys Dec 16 11:58:44 Crofton|work: ok Dec 16 11:59:03 ideally we would make the OE-Core packagegroups useful for the common case, but it's not entirely unexpected that people will want to modify them; package selection basically comes down to distro policy Dec 16 12:14:32 volatile.cache appears to be the root of all evil Dec 16 12:28:22 the desire of the image to reset resolv.conf is very very strong Dec 16 12:32:25 does it have connman? Dec 16 12:32:49 and is the nameserver info it uses wrong? Dec 16 12:33:03 because resetting resolv.conf is usually a good thing Dec 16 12:33:12 especially if you have >1 interface Dec 16 12:33:42 in other words: is the customer upset that it's being reset or is the customer upset that something uses the wrong nameserver? Dec 16 12:46:35 koen, they want to use static ip Dec 16 12:46:40 with fixed dns Dec 16 12:47:01 connman not installed Dec 16 12:47:34 and resolv.conf is not a symlink? Dec 16 12:47:42 it si a symlink Dec 16 12:47:47 and keeps getting recreated Dec 16 12:47:56 and the file in /var/run gets wiped Dec 16 12:51:11 wtf happends if you have a directoy called /etc/resolv.conf? Dec 16 12:52:53 no name resolution Dec 16 12:53:06 (well, depends on /etc/nsswitch.conf) Dec 16 12:53:48 sometimes you speak in tongues Dec 16 12:54:31 I am kind of guessing I need the resolvconf binary Dec 16 13:14:14 FYI: https://events.ccc.de/congress/2014/Fahrplan/events/6240.html Dec 16 13:21:55 Crofton|work: to get static ip on my devices, i just created a init-ifupdown.bbappend that overrides "interfaces" file, seems to work fine Dec 16 13:22:20 (although, when i come to think of it, i did not set any DNS) Dec 16 13:22:51 :) Dec 16 13:23:01 yeah, the trick is resolv.conf I think Dec 16 13:25:16 I would think just using the bbappend to replace interfaces would be best Dec 16 13:37:06 i'm compiling for 2 different machines, one Cortex A8-based machine and another Cortex A9-based. Both are using armv7 instruction set. How come they do not share tmp-eglibc/work/armv7a-vfp-neon... directory? instead the cortex a8 compiles its non-machine dependent packages into tmp-eglibc/work/cortexa8t2hf-vfp-neon .. Is this a bug in one of the layers, or is it because some TUNE_FEATURE that makese the armv7 Dec 16 13:37:07 binaries incompatible with eachother? Dec 16 13:52:33 JaMa: How to include in my machine qtquick demos? Do i have to add to IMAGE_INSTALL quick1-demos ? Dec 16 13:53:21 Because i've added to qtbase PACKAGECONFIG += examples Dec 16 13:53:30 Bu i only have qtbase examples and widgets. Dec 16 13:53:46 Ps. Also added qtbase-examples to IMAGE_INSTALL. Dec 16 13:56:59 My mistake. I want QML examples like on this side https://qt-project.org/doc/qt-4.7/qdeclarativeexamples.html Dec 16 13:57:06 Not qtquick. Dec 16 14:02:11 so apparently setting up static ip + static resolv.conf is a pain in the adss with stuff based off core-image-minimal Dec 16 14:02:16 why is this so hard Dec 16 14:04:51 Crofton|work: by all means, file a bug... Dec 16 14:05:17 trying to check if I screwed something up Dec 16 14:05:49 I'm also not certain what the correct behavior is Dec 16 14:06:28 google suggests adding this to /etc/network/interaaces Dec 16 14:06:31 dns-nameservers 192.168.1.16 Dec 16 14:08:59 Ok, answer was : qtdeclarative-examples. :) Dec 16 14:18:04 mago_: you need to select the same DEFAULTTUNE for both of them Dec 16 14:19:16 Crofton|work: can't you just install a /etc/resolv.conf manually? Dec 16 14:19:26 nope, it gets wiped out Dec 16 14:23:05 who reads /etc/network/interfaces and des the work? Dec 16 14:24:41 i think it's read by "ifup" Crofton|work Dec 16 14:24:50 which is annoyingly a binary Dec 16 14:24:58 when you do "ifup -a", it'll bring up all "auto" interfaces Dec 16 14:25:53 Crofton|work: i think maybe the way to go here is to figure out why your /etc/resolv.conf gets wiped? Dec 16 14:26:03 that happens at boot Dec 16 14:26:09 in volatile.cache Dec 16 14:26:17 the question is how do you rebuild it Dec 16 14:32:40 well, isn't /etc/resolv.conf linked with /var/run/resolv.conf by /etc/init.d/populate-volatile.sh ? so you probably need to provide a different /etc/default/volatiles/00_core (if you want to prevent that linkage). I think "initscripts" package provides that file Dec 16 14:33:52 this fiel is missing Dec 16 14:33:53 so a .bbappend for initscripts that replaces "volatiles" files might do the trick to prevent the system from wiping your manually installed resolv.conf Dec 16 14:33:55 /lib/resolvconf/list-records Dec 16 14:34:13 mago_, we need to work out why this is so hard on a default mage Dec 16 14:34:32 i think it's hard because no one cares about static IPs anymore ;-) Dec 16 14:34:36 yep Dec 16 14:34:57 you use link-local addresses/dhcp/zeroconf Dec 16 14:35:14 the resolvconf script is supposed to solve this, but it seems like the list-records is missing Dec 16 14:35:25 alright, that's a good clue Dec 16 14:35:40 yep Dec 16 14:35:48 now to see where it is supposed to come from Dec 16 15:19:30 mago_, volatile.cache beats resolv.conf with a large club Dec 16 15:20:27 dang it Dec 16 15:22:42 hopefully someone more involved will answer your oe-core mail Dec 16 15:24:17 yep Dec 16 15:25:32 the image is a bit of a hodge podge atm, but I can't imagine that stuff changes much Dec 16 15:37:10 I think I should set dns-gateway in the interfaces file, and that should get propagated into resolv.conf Dec 16 16:14:17 hodge podge Dec 16 16:14:24 never heard that word before :) Dec 16 16:55:04 whats a recommended release strategy for OE layers? it seems like most layers do branches for each Yocto release, and i guess this makes it easy for users: just use daisy-branch of all your layers and "it should work" (tm). But that doesn't guarentee that backports to a daisy branch will break a layer, so do projects also keep tags on these branches? Dec 16 16:57:58 example: for each of your layers, you tag the tested commit with "daisy-releaseX" let products lock onto those tags. If you bring in updates to the daisy branch, you will again tag with "daisy-releaseX+1" on all layers, even if only one of the layers has changed. This would ensure that users always use the correct combination of layer revisions Dec 16 17:02:19 mago_: there shouldn't ever be backwards-compatiblity breaking changes in a stable branch, so it shouldn't be necessary to go to that level Dec 16 17:02:56 well, just recently alsa-utils broke when i merged upstream daisy onto my local daisy Dec 16 17:03:13 so it does happen, and i'd like to be ready for that. Products should never be on a floating branch Dec 16 17:03:55 i needed to apply this patch to get daisy to build: http://patchwork.openembedded.org/patch/80727/ Dec 16 17:05:06 mago_: specify tested revision in your setup scripts and update even release branches only after internal testing Dec 16 17:06:55 but if product doesn't lock to a specific commit on each daisy branch, how can you re-produce an old build? Dec 16 17:16:10 mago_: I guess what I am suggesting is that if those things happen then that's the problem we should address Dec 16 17:16:34 mago_: by all means record the specific revision you successfully built with, that's not quite what you were suggesting though Dec 16 17:17:26 bluelightning: well, i need to be able to reproduce older builds. So somehow I need to record specific revision, and then tags are probably more readable than hardcoding my setupscript to a specific sha-id? Dec 16 17:19:01 mago_: it depends if you are prepared to keep to only upstream releases or not (or you store your own copy of the repo with your own tags in it) Dec 16 17:20:00 we are sticking to upstream releases, but we keep own copies of the repos in-house (in case the upstream repo goes away in the future) Dec 16 17:24:35 bluelightning: how do you ensure you can build old releases at Intel? Dec 16 17:26:16 mago_: well, at least on the Yocto Project team we record the revisions built in our autobuilder reports, these values can be fed back into the build later on if needed Dec 16 17:28:51 ok Dec 16 18:03:35 mago_: setup scripts which lock the revision are git repository, so if I want to re-produce older build I'll checkout older revision of setup scripts repo Dec 16 18:03:53 and we tag the setup scripts repo Dec 16 18:04:04 with build/product names as needed Dec 16 18:54:57 sgw_, I'm goin gto try building an image from oe-core and duping against master Dec 16 18:55:43 do you have an expected course for this? Dec 16 18:57:24 https://github.com/MentorEmbedded/meta-sourcery/pull/56 - seem reasonably sane? not happy with it being one commit, but i gave up on even trying to break it up for the reasons mentioned in the req Dec 16 19:17:16 Crofton|work: hi, sorry not completely following your question, I understand your going to try and reproduce the resolv.conf issue with master? I would hope that it works if you include the resolvconf package. Dec 16 19:21:25 it didn't on the dodgy image I ahhve Dec 16 19:21:33 looks liek parts are not getting packaged Dec 16 19:21:47 need to check resolvconf build history after this finished Dec 16 19:22:15 basically, I want something sane to file a bug for :) Dec 16 19:22:29 or figure out needed backports Dec 16 19:25:41 do you expect adding a dns-nameservers line to an iface in the interfaces file to set a static entry in resolv.conf? Dec 16 19:28:40 Crofton|work: depends on your network manager Dec 16 19:28:51 there isn't one Dec 16 19:30:45 so how does the ip address get set? Dec 16 19:30:59 if there isn't a network manager all your interfaces will stay down Dec 16 19:31:05 unless you use the kernel cmdline **** ENDING LOGGING AT Wed Dec 17 02:59:59 2014