**** BEGIN LOGGING AT Thu Aug 29 02:59:58 2013 Aug 29 03:32:47 hi, why are there native packages? Aug 29 03:39:53 lpapp_: your up late, the -native packages are to ensure a consistent and reproducible build environment and not rely on the host's tools which may be either older or newer. Aug 29 03:42:41 sgw_: why would I? Aug 29 03:42:56 it is already 5 pm here soon. Aug 29 03:43:03 am* Aug 29 03:43:15 lpapp_: then your up early! Aug 29 03:43:31 sgw_: why? This is the best time for meditating. :) Aug 29 03:43:41 rather than the tiring evenings. Aug 29 03:44:03 I guess it is just the matter of when one goes to sleep. :) Aug 29 03:44:14 You have an interesting viewpoint if you are meditating on IRC ;-) Aug 29 03:44:26 no, I am already done with that. Aug 29 03:45:10 sgw_: there is for instance qtbase-native, but I am not yet sure why. Aug 29 03:45:22 sgw_: qt5 is meant to be buildable easily for host, or target. Aug 29 03:45:30 but I see this situation for other packages, too. Aug 29 03:46:41 lpapp_: is qtbase part of qt5? There might be some tool that is needed to help build qt5, so these are built first and then qt5 will use that tool Aug 29 03:49:04 sgw_: yes, there is a bootstrap, but how is that related? Aug 29 03:50:39 (it is not a qt5 specific problem btw) Aug 29 03:56:02 JaMa: any of the qt5 changes meant to be upstreamed? Aug 29 04:06:00 Hi yocto. I added linux-firmware in my image file. It compiled fine. But i m getting the licence problem of rtlwifi. My log at http://pastebin.com/8LyWxq8y Aug 29 05:28:15 lpapp_: you mean .patch files in meta-qt5? Aug 29 05:28:23 some has Upstream-Status.. Aug 29 05:45:17 JaMa: yes, those Aug 29 05:45:23 JaMa: like external host dir Aug 29 05:45:28 bin Aug 29 05:47:09 JaMa: I was trying the update to 5.1.1 but patches are failing Aug 29 05:47:22 JaMa: and I was thinking of asking the upstreamability... Aug 29 05:47:30 even qtbase has many patches. Aug 29 05:51:35 JaMa: I removed 2 integrated, and there are few inappropriate, and the rest is pending... Aug 29 08:02:27 lpapp_: you can see qtbase repo in meta-qt5 org on github, that's what I'm using to rebase patches for new releases Aug 29 08:03:25 lpapp_: I've discussed external-dir-host with ossi on IRC, but in the end I'm not so happy about how it works, so I haven't submitted it upstream in the end Aug 29 08:11:15 morning all Aug 29 08:14:16 JaMa: well, there are a few inappropriate things in there. Aug 29 08:14:23 like the oe-g++ mkspcs. Aug 29 08:14:25 mkspecs* Aug 29 08:18:47 Hi, How can I change the PYTHON executable in a recipe in order to use python-native ? Aug 29 08:45:51 gaby: inherit the python-native class Aug 29 08:46:30 that should have been pythonnative Aug 29 08:53:27 JaMa: what did ossi suggest instead of the external host dir? Aug 29 09:06:19 lpapp: there isn't any replacement for that Aug 29 09:06:43 JaMa: what is the problem with bootstrapping Aug 29 09:06:51 ? Aug 29 09:07:19 JaMa: as far as I read that, it seems to grab tools from a prebuilt external location Aug 29 09:07:29 true Aug 29 09:07:42 so, what is the problem with boostrapping, rather than doing so? Aug 29 09:07:54 ah I see where you're going Aug 29 09:08:06 the goal with OE is to build native tools just once Aug 29 09:08:18 and then reuse the same tools for different target builds Aug 29 09:08:47 JaMa: yeah, so why not have a native package? Aug 29 09:08:51 which are building the tools? Aug 29 09:08:57 and that native package is bootstrapped. Aug 29 09:09:07 lpapp: that's what qtbase-native is Aug 29 09:09:58 JaMa: yeah, so what is the purpose of that change? Aug 29 09:10:08 you can use the native tools if they are in the path. Aug 29 09:10:31 no it will try to bootstrap them again Aug 29 09:11:11 external-host-bin is switch to disable bootstraping and forcing build to use binaries from qtbase-native Aug 29 09:11:56 this looks like a configure flag Aug 29 09:12:05 it is configure flag Aug 29 09:14:54 JaMa: I am not sure I understand this use case. Aug 29 09:15:06 JaMa: if qtbase changes, it might be that the tools changed, and they need to be rebuilt. Aug 29 09:15:13 and they are only rebuilt during the qtbase rebuild. Aug 29 09:17:25 perhaps it external stuff cannot be found, it makes sense to bootstrap even then though, yeah. Aug 29 09:18:45 ? Aug 29 09:20:04 JaMa: if native tools cannot be found in the path, it might make sense to rebuilt them. Aug 29 09:20:19 if they, then perhaps not, although the installed might be outdated. Aug 29 09:20:30 can* Aug 29 09:30:59 lpapp: that's why recipes using them have qtbase-native in DEPENDS Aug 29 09:31:32 the only problem I see is that tools might be outdated. Aug 29 09:31:40 and IMO it should be rebuilt when qtbase is rebuilt Aug 29 09:31:47 in which case, the change has not much addition Aug 29 09:31:54 why should be, if there is newer qtbase-native it will be upgraded before qtbase is built Aug 29 09:34:07 lpapp: as long as qtbase-native signature is valid, then aren't outdated Aug 29 09:34:22 lpapp: and qtbase-native can be reused from sstate-cache Aug 29 09:34:43 so this addition is needed (I don't know how to explain it better for you to see it) Aug 29 09:36:59 well, the source has to be checksum'd and compared Aug 29 09:37:20 if it is not what is installed, it has to be rebuilt... so in that case, the one time build is kinda moot. Aug 29 09:37:37 if it is the same, it does not have to rebuild. Aug 29 09:54:06 rburton: ping Aug 29 09:57:23 JaMa: he's away I think Aug 29 09:57:31 JaMa: anything I can help with? Aug 29 09:57:48 it was about libmatchbox, but I'll handle it different Aug 29 09:58:54 bluelightning: you can help me with something else.. I have 20 patches for oe-core and 80 for meta-oe for deterministic dependencies, I'm still testing them so I haven't sent them for review yet Aug 29 09:59:06 but when is the last option to get them in 1.5? Aug 29 09:59:09 JaMa: wow, ok... Aug 29 10:00:15 JaMa: well, I can't guarantee they will get in but if they're bugfixes and not too impactful then they should be OK; we'd better have them soon though Aug 29 10:00:35 bluelightning: this is the libmatchbox change I wanted to ask rburton about (if he wants to fix missing include instead) http://git.openembedded.org/openembedded-core-contrib/commit/?h=jansa/deps&id=e6abe1f4e6a41cf4ac4070971b6ec1757d79b9ab Aug 29 10:00:45 IMO it would be really great to have most dependency issues nailed down for 1.5 Aug 29 10:01:59 I know only about handful yet unresolved deps after this patchset but verification builds get always broken by some other change, so I haven't got complete world for some time.. Aug 29 10:01:59 JaMa: that fix looks reasonable to me; I'd say fixing the png-disabled case can be handled later, but rburton may have other ideas being the maintainer Aug 29 10:02:23 yes that why I was asking him Aug 29 10:02:27 right Aug 29 10:08:25 bluelightning: btw were you interested in qcanobserver? or do I remember it incorrectly? Aug 29 10:11:38 JaMa: not personally... I don't yet have a device here with a CAN bus to test, although I do have a minnowboard on order; but still nothing CAN-equipped to connect to it other than my car which I don't really want to tinker with at that level ;) Aug 29 10:12:37 oki, it's broken for long time, so I'm looking for someone who was using it or plans to use it Aug 29 10:14:03 I wonder if anyone in the minnowboard community might be interested if they're playing around with CAN Aug 29 10:14:22 I can ask in #minnowboard later Aug 29 10:16:24 it's broken since some qt4 upgrade IIRC, so I'm not sure if it needs someone with CAN knowledge - except for motivation to fix it of course :) Aug 29 10:17:15 hmm last build error looks like just missing include.. I'll probably fix it in next round Aug 29 10:22:14 ah there is also problem with sourceforge layout change for svn repos Aug 29 10:38:49 hi experts, i have a little problem: my build always fails at xserver-xorg, do_package_wirte_rpm due to a change in $PV. i tried to 'bitbake -c clean xserver-xorg' and rebuild but it doesnt help. i noticed that the explicit funtion to fail is read_subpackage_metadata. since xserver-xorg does have subpackages (a few -extension packets) i guess i would have to rebuild them because they were build with another PV Aug 29 10:39:24 JaMa: right, we discussed that last week I think; someone really needs to go and submit a sourceforge infrastructure bug report to get them to put in working redirects for the old layout Aug 29 10:39:30 JaMa: is that something you'd be prepared to do? Aug 29 10:39:36 but i do not know how, because bitbake says 'nothing provides xserver-xorg-extension-*' with * being any of the extensions provided by xserver-xorg. Aug 29 10:40:13 bluelightning: not now as I would like to finish those dependencies in time Aug 29 10:47:11 JaMa: right, fair enough Aug 29 11:05:24 anyone any ideas? Aug 29 11:05:30 please :) Aug 29 11:09:02 ndec: given we discussed it earlier in #oe would you be able to submit a sourceforge infrastructure bug report to get working redirects added for the old svn layout? Aug 29 11:11:09 dRp3pP3r: xserver-xorg is the recipe that produces those packages, but they are packages and thus you can't specify them as names on the bitbake command line Aug 29 11:11:34 dRp3pP3r: it sounds more like a bug to me Aug 29 11:12:03 bluelightning: thats my problem. deleting all files under work/ didn't help too... Aug 29 11:15:09 so, what do i do? Aug 29 11:15:14 dRp3pP3r_: you should never delete tmp/work/ on its own, that's probably trashed your TMPDIR Aug 29 11:15:54 seemed like the only way to get rid of the subpackages with the wrong PV, but the error stays... Aug 29 11:15:59 (although just deleting tmp/work/...../recipe/version wouldn't be a problem if you subsequently cleaned) Aug 29 11:16:10 that's what i did.... Aug 29 11:16:17 ok, no worries on that front then Aug 29 11:16:35 but you should never get tracebacks or obscure errors like that, if you are it's a bug Aug 29 11:16:54 brb Aug 29 11:17:44 the exact one is: ERROR: Recipe xserver-xorg is trying to change PV from '1.14.0' to '1.11.4'. This will cause do_package_write_* failures since the incorrect data will be used and they will be unable to find the right workdir. Aug 29 11:18:27 ah right Aug 29 11:18:57 have you tried bitbake -c cleansstate xserver-xorg ? Aug 29 11:19:28 not yet, mom Aug 29 11:19:52 I have to step out for a sec but that should get around the problem Aug 29 11:19:58 k thx Aug 29 11:37:10 bluelightning: for the record: didn't work. read_subpackage_metadata again. Aug 29 11:37:58 dRp3pP3r_: read https://bugzilla.yoctoproject.org/show_bug.cgi?id=4102 especially last comment with "find" command Aug 29 11:37:59 Bug 4102: normal, Medium+, 1.5 M2, richard.purdie, RESOLVED FIXED, Incremental builds do not work well when renaming recipes or changing architecture. Aug 29 11:47:12 JaMa: thanks, worked (the find command) Aug 29 11:47:44 i suppose the mentioned patch 2/2 is implemnted in 1.5M2? Aug 29 11:49:10 yes Aug 29 11:49:26 right. thanks again. :) Aug 29 11:50:35 i'm off... hava a nice day u all :) Aug 29 12:02:28 Heya. If I make a bbappend that contains a file named exactly like the one in the original recipe, with the intend to use the file I provide instead of the original one, will the original file be "overwritten" in D and used by do_install()? (The do install in the main recipe - I don't want one if I don't need it in my bbappend). Aug 29 12:02:50 If not, I assume I can just do a do_install_append and install on top of the old one. Aug 29 12:04:52 And on another note, this line here: PRINC := "${@int(PRINC) + 1}" This increments package revision by one, right? Aug 29 12:06:34 Morning everyone... to those involved with my problem... here are the results of the core-minimal sdk build. Aug 29 12:06:39 http://pastebin.com/3PAncwWk Aug 29 12:06:47 Stygia: what you mean by "bbappend that contains a file named exactly like the one" ? Aug 29 12:07:05 Stygia: are you talking about some file referenced from SRC_URI? Aug 29 12:07:40 JaMa, Yes exactly. The original recipe has a hosts file in SRC_URI, and I want to ensure that the file from my bbappend is used instead. Aug 29 12:07:46 JaMa, Sorry if I was unclear. Aug 29 12:09:32 Could I assume that, if I do a bbappend with a SRC_URI +=, that the file from my bbappend is what'll be used in the statement something like "install hosts ${D}/etc" ? Aug 29 12:11:18 Stygia: you don't need to modify the SRC_URI Aug 29 12:11:38 just provide the file and do the usual preppend on the path Aug 29 12:11:43 tf, Oh? I just do FILESEXTRAPATH_prepend and add it in? Aug 29 12:11:47 tf, Ah exactly. Cool. :) Aug 29 12:12:10 tf, Presumably I'd still need to increment the package revision, though, right? Aug 29 12:12:29 yes, I think so Aug 29 12:13:56 tf, Alright, cool. Seems simple enough. Aug 29 12:17:20 Stygia: yes, but it uses your file in WORKDIR, then it's back on base recipe what it will do with it (to install it in $D or something else) Aug 29 12:18:38 JaMa, Exactly, that's what I want. :) Aug 29 12:19:16 JaMa, This is netbase, and we need to use our own hosts file to workaround a crazy bug we couldn't track down... so that's exactly what I want. Just to do the normal things with my file instead of the original. Aug 29 12:19:43 WARNING: Host distribution "Debian-GNU-Linux-7" has not been validated with this version of the build system; you may possibly experience unexpected failures. It is recommended that you use a tested distribution. Aug 29 12:19:53 debian stable is unsupported? How come? Aug 29 12:20:10 Stygia: understood, it just wasn't clear from that question what do you expect Aug 29 12:20:56 JaMa, Alright, sorry. Aug 29 12:21:09 JaMa, But that is exactly what I expected, so all good. Aug 29 12:21:45 update: http://pastebin.com/8cUQCHnn works from Makefile. Environment probably needs tweaked. Aug 29 12:22:50 cfo215, weird, not dyn linker failure? Aug 29 12:23:26 Crofton|work, I thought you were going rafting today? Aug 29 12:23:47 I am just trying to get cuaght up b4 loading the car Aug 29 12:24:59 Crofton|work, I'm jealous! Anyhow. the pastebin has everything I did and the results. I can pastebin my env if that will help. Aug 29 12:27:35 I am annoyed the otehr problem went away Aug 29 12:27:40 soemthing really funny is up Aug 29 12:28:11 I need to stop caring long enough to get out the door Aug 29 12:29:49 Crofton|work, I feel you. I just want to compile my Qt app for ARM. So frustrated at this point. Aug 29 12:30:04 yep Aug 29 12:30:10 we want this to work Aug 29 12:30:34 is it "easy" for you install Fedora? Aug 29 12:30:52 I understand. I want it to work to. It will surely be better in the long run. Beats having to do everything from scratch. Aug 29 12:31:04 also, did you get anywhere with the touchscreen? Aug 29 12:32:24 Nowhere on the touchscreen yet. -qws doesn't play with it. I thought Qt was compiled with touchscreen support built in. Aug 29 12:33:14 dunno Aug 29 12:33:33 Crofton|work, can i "upgrade" my Ubuntu to fedora? Or do I need to rebuild my system? Aug 29 12:33:41 is your app "big" you can compile on the bone Aug 29 12:33:43 rebuild Aug 29 12:33:54 I was hoping you had an extra box around Aug 29 12:34:09 That's what I thought. I'll ask the IT peeps here if they have anything. Aug 29 12:34:17 What version of Fedora? Aug 29 12:34:24 F19 is what I used Aug 29 12:34:28 use Aug 29 12:34:36 anyone knows why Debian stable is not supported anymore? Aug 29 12:35:02 I can compile it on the bone. I tried opkg qt4, and qt4-embedded but it couldn't find those. I'll search the *.ipks for the correct name. Aug 29 12:35:49 I just "happen" to have that version on DVD sitting on my desk... Aug 29 12:36:12 Do you use 32bit or 64bit? Aug 29 12:38:45 64 Aug 29 12:39:50 thnks Aug 29 12:40:34 I believe this is the correct file: packagegroup-qte-toolchain-target_1.0-r7.0_all.ipk Aug 29 12:40:41 to install on the BBB that is. Aug 29 12:40:57 try it :) Aug 29 12:41:15 working on it... ;) Aug 29 12:42:42 can someone try endorsing me for OpenEmbedded and "Yocto Project" on linkedin Aug 29 12:42:51 yes, I know the endorsement stuff is bs Aug 29 12:43:41 also, I would to get the number of times I have been endorsed for trolling up :) Aug 29 12:44:46 * RP likes his Cat Herding skiil Aug 29 12:46:06 Crofton|work, if I get a machine for Fedora, I should be able to just move my files over, or am I going to have to start from scratch again? Aug 29 12:46:56 you can move the downloads ;) Aug 29 12:47:16 that works... Aug 29 12:47:22 after the time for changing distro a run of bitbake isn't so bad... Aug 29 12:47:33 Crofton|work: I can't see Yocto Project and OpenEmbedded on there :/ Aug 29 12:49:41 I thought they are "interchangeable" for the most part. Aug 29 12:49:58 Crofton|work: I've noticed Fedora* and Ubuntu* distros seem suffering now and then. Trust me (and JaMa): with Gentoo we never had any issue apart one obscure binutils thing years ago Aug 29 12:50:02 cfo215: in the way some people use the term Yocto Project, certainly Aug 29 12:50:15 I use Fedora, so problems get fixed :) Aug 29 12:50:47 cfo215: strictly speaking the Yocto Project is an umbrella project and one (major) sub-project under that umbrella is to enhance BitBake and OE-Core Aug 29 12:51:15 cfo215: so strictly speaking the build system is OpenEmbedded Aug 29 12:51:23 +1 Aug 29 12:51:28 Crofton|work: it may sound strange but I'd suggest Gentoo to newcomers Aug 29 12:51:45 I suggest what I use :) Aug 29 12:51:59 ah, golden rule... Aug 29 12:52:42 for least pain on a headless build server I use CentOS ;) Aug 29 12:53:02 there has been some fun with python there but buildtools solves that Aug 29 12:54:18 for master that is, dylan needs no additional help Aug 29 12:54:26 dylan and earlier Aug 29 12:54:41 the idea is that the buildtools-tarball should solve the various distro related problems we were seeing Aug 29 12:54:47 indeed Aug 29 12:55:41 he he.. it was already foreseen: OE builds OE Aug 29 12:56:25 well, an OE "SDK" (since buildtools-tarball is effectively an SDK) supports the build of OE ;) Aug 29 12:56:37 RP: by the way, is the issue of /usr still popular? Aug 29 12:56:40 but of course OE will build under an OE-built OS as well :) Aug 29 12:57:49 ant_work: most of the userbase still use it Aug 29 12:58:20 ant_work: the buildappliance is an OE image which can then run OE Aug 29 12:59:37 RP: wrt /usr -> / I'm hearing opinions like "let those distros sink into oblivion" Aug 29 13:00:40 ant_work: I think it makes sense to maintain configurability with the project so I'd certainly not support that Aug 29 13:02:36 RP: I was planning to build a small image with meta-micro but I'm still exitating Aug 29 13:03:24 *hesitating fwiw Aug 29 13:03:51 3: linux-yocto-3.4.59+gitAUTOINC+f36797c2df_cdd7a54692-r4.5 do_install (pid 29353) -> why is it getting stuck in here? Aug 29 13:08:10 RP, I endiorsed you for OpenEmbedded and tried "Yocto Project" in "'s Aug 29 13:35:07 Crofton|work, hopefully I won't run out of space on the BBB. Also, I rather do my development on my PC not the target. Kind of defeats the purpose. Aug 29 13:36:24 bluelightning, thanks for the clarification. Aug 29 13:39:01 sure, but you need something that works, having multiple paths to success is always a good idea Aug 29 13:44:23 what is the best practice to handle SOURCE_MIRROR_URL ?= "file://source_mirror/sources/" for in repository state and downloads stuff? Aug 29 13:44:38 file://${TOPDIR}/build/ etc or something else? Aug 29 13:58:49 JaMa: so what did you not like about the external host bin change Aug 29 14:02:07 bluelightning: is there a download dir variable that can be used in local.conf? Aug 29 14:02:22 lpapp: DL_DIR? Aug 29 14:03:51 bluelightning: is that accessible for local.conf? Aug 29 14:11:46 lpapp: absolutely Aug 29 14:15:09 lpapp: that I had to modify also other qt5 modules in order to support it (and similar changes are needed for cmake support) Aug 29 14:17:35 JaMa: well, cmake is just following qmake. Aug 29 14:18:18 yes, that is bad if other modules require it because it should be a one-shot action in qtbase. Aug 29 14:18:23 Crofton|work: it didn't show up :/ Aug 29 14:18:38 th eOE one did? Aug 29 14:18:40 bluelightning: ok, thanks so I need to use that for this? https://wiki.yoctoproject.org/wiki/How_do_I#Q:_How_do_I_create_my_own_source_download_mirror_.3F Aug 29 14:18:48 we need to work on our linkedin gaming Aug 29 14:18:54 i.e. is it enough? INHERIT += "own-mirrors" Aug 29 14:18:54 BB_GENERATE_MIRROR_TARBALLS = "1" Aug 29 14:19:18 or, I also need, SOURCE_MIRROR_URL ?= "file://${DL_DIR}"? Aug 29 14:19:20 lpapp: see https://github.com/meta-qt5/meta-qt5/commit/7c3a1a208df46fcf094b957cdd35f06729c53eda Aug 29 14:20:17 lpapp: https://github.com/meta-qt5/meta-qt5/blob/master/recipes-qt/qt5/qtjsbackend-5.1.0/0002-v8.pro-respect-external-host-bindir-when-set.patch Aug 29 14:20:40 luckily, v8 is history soon. Aug 29 14:20:48 so is qtjsbackend Aug 29 14:21:47 I must admit that I don't follow qt5 so closely to know that, but still it's something which doesn't work with simple -external-host-dir out-of-the-box Aug 29 14:22:06 why not Aug 29 14:25:12 hmm, I need to add uthash in my layer for now. Aug 29 14:25:23 which recipes-foo subsystem should I choose for that? Aug 29 14:25:35 the project ships 4 header files, that is all ... it is only for development. Aug 29 14:25:47 but "devtools" sounds wrong for this as this is not a tool. Aug 29 14:26:10 bluelightning: ^ Aug 29 14:26:36 maybe recipes-extended Aug 29 14:26:41 * bluelightning doesn't know what uthash is Aug 29 14:26:53 C preprocessor implementations of a hash table and a linked lis Aug 29 14:26:56 t Aug 29 14:27:17 recipes-support or recipes-devtools I would think Aug 29 14:27:28 it is not a tool Aug 29 14:27:29 but ultimately it's your layer and the system doesn't care what directory it's in... Aug 29 14:27:31 it is 4 header files. Aug 29 14:27:43 well, I plan to propose it back later tonight to some layer Aug 29 14:28:07 ok, I am fine with recipes-support Aug 29 14:33:00 bluelightning: right, so what is the best way not to run any confiure, make whatsoever? Aug 29 14:33:06 just install the four headers in the tarball downloaded? Aug 29 14:33:13 do I even need to mention the installationo f them explicitly? Aug 29 14:33:18 installation of them* Aug 29 14:33:26 depends if it supports "make install" Aug 29 14:33:34 well actually Aug 29 14:33:48 if it's not autotooled you need to write your own do_install Aug 29 14:34:11 bluelightning: ls src Aug 29 14:34:11 utarray.h uthash.h utlist.h utstring.h Aug 29 14:34:17 that is all Aug 29 14:34:22 no makefiles, no configure, whatsoever. Aug 29 14:34:40 tests folder is full of c test sources. Aug 29 14:34:45 but I do not need that one. Aug 29 14:34:52 there is a makefile in there. Aug 29 14:35:00 right, then you'll need to install them in your own do_install with install -m 0644 ... Aug 29 14:35:20 right, thanks. Aug 29 14:40:47 bluelightning: this, right? install -m 0644 ${S}/src/*.h ${D}${includedir} Aug 29 14:41:11 lpapp: looks OK Aug 29 14:41:35 thanks.. also, there is a one-command syntax for this repetitive pattern: bitbake foo -c clean && bitbake foo Aug 29 14:45:46 bluelightning: install: target `/home/lpapp/Projects/Yocto/poky-dylan-9.0.1/build/tmp/work/armv5te-linux-gnueabi/uthash/1.9.7-r1/image/usr/include' is not a directory Aug 29 14:46:09 I need to create that explicitly? Aug 29 14:52:50 yeah, apparently.. Aug 29 14:53:19 or is there a nicer way? Aug 29 14:53:52 other than: install -m 755 ${D}${includedir} Aug 29 14:53:52 install -m 0644 ${S}/src/*.h ${D}${includedir} Aug 29 14:54:43 install -dm755 ${D}${includedir}* Aug 29 15:13:44 hmm, I just realized stuff is not stripped by default Aug 29 15:13:53 is there a yocto catch up setting for that to strip everything possible? Aug 29 15:15:10 it does strip binaries as part of packaging Aug 29 15:15:23 symbols are split out to the -dbg packages and then stripped from the binaries Aug 29 15:17:59 ah, as part of the packaging, thanks. Aug 29 15:44:04 bluelightning: so I should not check anything in, inside the downloads folder which starts with "git2"? Aug 29 15:45:26 personally I wouldn't put downloads into a VCS but if you feel you must, the answer is yes exclude those Aug 29 15:51:29 bluelightning: thanks Aug 29 15:59:43 The last 10 minutes really make me wish I'd either unsubbed from oe-devel@ or taken the time to set up mail sieve.... :P But good on Martin Jansa, whoever that is. Aug 29 16:00:10 Stygia: /whois JaMa Aug 29 16:00:30 If you've no idea what I'm on about, check your email. Aug 29 16:01:40 definitely sounds like you need to setup some filtering Aug 29 16:01:47 * lpapp feels the time to unsubscribe from oe-devel. :p Aug 29 16:02:06 * kergoth didn't even notice Aug 29 16:02:29 I think the other one was worse with 180 Aug 29 16:03:11 Stygia: you shouldn't read your e-mail on android phone or where do you read it Aug 29 16:03:33 Stygia: 1000 e-mails per hours and mutt isn't even shown in htop :) Aug 29 16:04:25 is there a pattern deletion option on the gmail webinterface? Aug 29 16:04:29 hehe Aug 29 16:04:30 when someone sends so many changes? Aug 29 16:04:46 JaMa, Hah it's not that it's performance-heavy, it's that I've neglected to actually implement the filter, so I got a shitton of mails all at once. Aug 29 16:05:10 JaMa, And it's not an issue really, I just didn't see 30+ emails at once coming anytime soon. :P Aug 29 16:05:24 i use gmail, but i filter so patches are auto-archived, and use a separate patch review saved search, so only non-patch-review discussions hit the inbox Aug 29 16:05:32 get used to it :) Aug 29 16:06:17 so, turns out i have no immodules in gtk+3 because whoever added gtk+3 didn't pull forward a required patch from gtk+2 Aug 29 16:06:20 * JaMa is using filters on gmail to split the flow into 30+ labels with auto-archive, then isync to get them in local maildir and mutt to read them from local storage Aug 29 16:06:23 * kergoth rolls eyes and submits patch Aug 29 16:07:56 most annoying part on this setup is that in order to delete some e-mail from "All mail" folder I have to locally move it to trash and push it with isync back to gmail Aug 29 16:09:24 i have fond memories of procmail+mutt Aug 29 16:09:26 good times Aug 29 16:10:06 Anyone else playing around with using buildtools-tarball to build on old distros? Aug 29 16:10:10 should I cross post yocto and oe-dev for general question? Aug 29 16:10:16 I mean, CCing lists Aug 29 16:10:44 JaMa: I still have these, http://paste.kde.org/~lpapp/pcaaade13/ Aug 29 16:11:04 even with BB_GENERATE_MIRROR_TARBALLS = "1" Aug 29 16:11:19 really depends on what the discussion is about Aug 29 16:11:22 * eren uses mutt + offlineimap. didn't even notice the performance problem :) Aug 29 16:11:34 lpapp: that's what you want isn't it? Aug 29 16:11:46 kergoth: it's about an image creation process for a new BSP layer Aug 29 16:11:48 JaMa: I want to avoid git in favor of tarballs. Aug 29 16:12:12 lpapp: fetcher will unpack tarballs into git2/ folder Aug 29 16:12:36 lpapp: tarballs are only for transfer between your mirror and builder Aug 29 16:13:02 JaMa: I wanna check in stuff in downloads and sstate Aug 29 16:13:07 and I do not wanna have git in there, only tarballs. Aug 29 16:15:00 unfortunately, BB_GENERATE_MIRROR_TARBALLS = "1" do not seem to help with this. Aug 29 16:15:45 yes it only generates mirror tarballs :) Aug 29 16:16:13 so, I was then right on the mailing list, it is N/A for my case. Aug 29 16:16:21 nobody asked for BB_GENERATE_ONLY_MIRROR_TARBALLS_WITHOUT_THE_POSSIBILITY_TO_UNPACK_THEM Aug 29 16:17:20 not sure what that is supposed to mean. Aug 29 16:18:26 bitbake needs to unpack them in order to checkout some revison to WORKDIR Aug 29 16:18:49 if you don't want to see unpacked tarballs then you cannot build anything Aug 29 16:19:29 I do not wanna see .git Aug 29 16:19:33 I wanna see tarballs. Aug 29 16:19:48 but fwiw, putting that variable in generates the same downloads folder as without Aug 29 16:19:51 I cannot see the difference. Aug 29 16:19:56 rsync has nice option to exclude .done, svn/, git2/ in order to sync downloads directory to some PREMIRROR server Aug 29 16:20:25 we do not wanna have a mirror server Aug 29 16:20:32 downloads is pretty convenient for everyone involved. Aug 29 16:20:50 also, we do not have time for a lot of extra work. Aug 29 16:22:24 I probably don't understand your use-case, because for me it works fine and rsync call isn't a lot of extra work Aug 29 16:23:07 you need to host the mirror etc ... Aug 29 16:23:13 you need to configure server, etc etc Aug 29 16:23:19 heh, turning off email computer really help me get out of here :) Aug 29 16:23:20 it is a lot of additional work for no apparent gain. Aug 29 16:23:32 at least for me.. Aug 29 16:23:43 lpapp: and your plan is to share downloads directory on floppy disks or what? Aug 29 16:23:47 git add ./downloads && git push -> would be simpler Aug 29 16:23:53 JaMa: ? Aug 29 16:23:58 no, check the mailing list Aug 29 16:24:02 I described that 1-2 weeks ago Aug 29 16:24:11 Hi guys I want to do something unusual, don't shoot Aug 29 16:24:19 and what prevents you from git add && git push? just add unwanted directories into .gitignore Aug 29 16:24:32 JaMa: that it does not work. Aug 29 16:24:33 I want to place tarball with sources of my app inside a Yocto layer Aug 29 16:24:37 JaMa: it is trying to fetch stuff from git. Aug 29 16:24:44 JaMa: which fails due to upstream unreliability. Aug 29 16:24:52 so CI continuously fails. Aug 29 16:24:57 is it as easy as pointing SRC_URI to "./my-tarball.tgz" ? Aug 29 16:24:58 which stops the integration. Aug 29 16:25:05 lpapp: are you using tag= in SRC_URI? Aug 29 16:25:10 Krz: yes Aug 29 16:25:17 Krz: file://my-tarball.tgz Aug 29 16:25:25 lpapp: has anybody done that before? is that really bad? Aug 29 16:25:25 lpapp: that's the only place where it runs git ls-remote upstream-site Aug 29 16:25:36 Krz: no, I do the same for our own softwares. Aug 29 16:25:56 Krz: in our bsp/distro layer. Aug 29 16:25:56 lpapp: ok, that's grand, thanks Aug 29 16:26:10 of course, it would be nicer to have download url for the release etc, but meh Aug 29 16:26:22 and how is "git2/" removal going to help with 18:25:58 < lpapp> JaMa: which fails due to upstream unreliability. Aug 29 16:26:57 JaMa: these are poky packages. I use whatever Yocto uses. Aug 29 16:27:28 JaMa: I have the same downloads folder generated w/ and w/o BB_GENERATE_MIRROR_TARBALLS Aug 29 16:27:54 are you 100% sure that you had BB_GENERATE_MIRROR_TARBALLS disabled? Aug 29 16:28:28 well you can have the tarballs there if they were downloaded from some MIRROR Aug 29 16:29:07 JaMa: there are a few packages fetching stuff from git, even for the Yocto releases. Aug 29 16:29:07 BB_GENERATE_MIRROR_TARBALLS only ensures that tarballs are generated on your machine everytime do_fetch finds new source Aug 29 16:29:29 JaMa: which means the Yocto releases will not work for people with CI etc due to upstream repo unreliabilities. Aug 29 16:30:04 of course, you can solve it with an external mirror, etc, but I think it would be simpler for many, including us, if those tarballs are generated in downloads by an option when building the repository. Aug 29 16:30:19 and then downloads are checked in, and when it is checked out by someone it just works, including the CI Aug 29 16:30:42 have you ever seen http://autobuilder.yoctoproject.org/pub/sources/ ? Aug 29 16:31:24 yes that's what BB_GENERATE_MIRROR_TARBALLS does Aug 29 16:31:27 JaMa: no, but we cannot trust that either. Aug 29 16:31:46 we would like to solve it ourselves rather than putting our business on someone's potential unreliability. Aug 29 16:32:06 ok, so where are the mirror tarballs generated? Aug 29 16:32:11 downloads is the same as without that variable. Aug 29 16:32:21 git tarballs in your downloads directory are probably downloaded from here (like http://autobuilder.yoctoproject.org/pub/sources/git2_git.denx.de.u-boot.git.tar.gz) Aug 29 16:32:24 grep -rn BB_GENERATE_MIRROR_TARBALLS ./conf/local.conf Aug 29 16:32:24 19:BB_GENERATE_MIRROR_TARBALLS = "1" Aug 29 16:32:38 use bitbake -e Aug 29 16:32:55 I have that u-boot tarball even without BB_GENERATE_MIRROR_TARBALLS Aug 29 16:33:51 I'm not surprised so much http://downloads.yoctoproject.org/mirror/sources/ is in default MIRRORS Aug 29 16:34:46 so BB_GENERATE_MIRROR_TARBALLS=1 is the default? Aug 29 16:35:11 or something else by default doing its/similar job? Aug 29 16:35:27 18:29:42 < JaMa> well you can have the tarballs there if they were downloaded from some MIRROR Aug 29 16:35:57 * lpapp has done a git rm -r downloads/git2 Aug 29 16:36:24 but if the tarballs are downloaded from mirrors Aug 29 16:36:32 why is bitbake trying to use the git version when the tarballs are there? Aug 29 16:36:42 git has some preference over the tarballs when both present? Aug 29 16:37:22 have you read the bug report about versioned snapshots? Aug 29 16:37:41 I skimmed through, so not in details, no. Aug 29 16:37:45 18:19:40 < JaMa> bitbake needs to unpack them in order to checkout some revison to WORKDIR Aug 29 16:38:40 it downloads tarball with compressed git checkout just to skip git clone from unreliable and possibly slower upstream site Aug 29 16:38:43 I would not like to have SRCVER check. Aug 29 16:38:49 as I do not wanna use VCS at all. Aug 29 16:39:00 IOW, I wanna have tarballs without .git inside. Aug 29 16:39:12 that's what that bug is about Aug 29 16:39:29 I am fine without version tracking. Aug 29 16:39:34 as it is not critical here. Aug 29 16:39:42 one version is fine without an explicit version number Aug 29 16:39:58 we do not get more than one from poky, and when do it is a major upgrade, so everything would be rewritten. Aug 29 16:40:25 let us see if "git rm -r ./downloads/git2 && git commit ./downloads/git2" fixes the CI Aug 29 16:41:28 pushed Aug 29 16:51:56 JaMa: now, I read through in details. It is what I thought it is. Aug 29 16:52:18 JaMa: basically sane mirror creation, and gpl compliance help. Aug 29 16:52:30 but if you need only one version, this is not necessary. Aug 29 16:56:28 Anyone have any experience with Sato on Beaglebone Black? Aug 29 16:57:41 last time I tried it I came up with the display "mirrored" on the lcd cape7. e.g. if you were to look at it in a mirror then it would look correct. Aug 29 16:57:48 Hmm, could be interesting to set up autocreation of DISTRO_FEATURE_ for each distro feature, to make dependency on distro features less brittle. instead of depending on the full value, we'd just depend on the existance or nonexistance of the particular features we care about, so random distro feautre changes woudln't affect you, making the checksums less brittle Aug 29 16:57:56 RP, bluelightning_: thoughts on something like that? Aug 29 17:01:22 I created additional layer Aug 29 17:01:27 kergoth: hmm, its an interesting idea Aug 29 17:01:33 kergoth: yes, intriguing Aug 29 17:01:40 the image file is copyrightable? Aug 29 17:01:42 specified in mylayer/conf/layer.conf BBFILE_COLLECTIONS += "abc" Aug 29 17:01:45 kergoth: my other though was to teach the python parser about base_contains() Aug 29 17:02:04 and now my build fails saying ERROR: BBFILE_PATTERN_abc not defined Aug 29 17:02:08 RP: or, have a different in-language construct to replace it Aug 29 17:02:41 bluelightning: yes, although I have thought about ans struggled to come up with that Aug 29 17:02:45 Krz: have you defined that? Aug 29 17:03:12 cfo215: I didn't get my original bb to start X at all, so you're already further Aug 29 17:03:43 teaching the parser to be smart about base_contains could be rather ugly.. currently we only really support dependency on other variables, not dependency on a segment of another variable :) might need internal temporary vars Aug 29 17:03:47 hmmmm Aug 29 17:03:54 kergoth: did you see the cookerdata patches? I was wondering about droping the direct usage of bitbake.conf and requiring a bblayers.conf file Aug 29 17:03:54 i made what i thought was a trivial change to a recipe, and a whole lot of dependencies appear to have been pulled in. can anybody help me with getting a dependency graph to work out what happened? Aug 29 17:04:17 kergoth: we left it in whilst we experimented with bblayers but I think that is making sense and here to stay now Aug 29 17:04:42 i'm trying to use the output of bitbake -g, but i've never used graphviz before, and it's making *very* wide, short graphs that are basically illegible Aug 29 17:04:47 bluelightning, bb or bbb? Aug 29 17:05:04 kergoth: I think that was the issue I ran into last time I tried to look at such a thing, yes :/ Aug 29 17:05:16 I use a beaglebone black (bbb) Aug 29 17:05:25 cfo215: bb (original) in my case Aug 29 17:05:26 bluelightning: ok I did now, I had a look at other layers. They use this funny variables like BBFILE_PATTERN_ etc. Aug 29 17:05:29 bluelightning: thanks Aug 29 17:05:31 err... trying to use... Aug 29 17:06:52 is there an option for bitbake to query the available images in the layers rather than looking for them manually? Aug 29 17:09:40 lpapp: bitbake-layers show-recipes "*image*" Aug 29 17:10:00 of course that's just a query by name Aug 29 17:10:08 yes... Aug 29 17:11:09 BCMM: have you tried -g -u depexp ? Aug 29 17:11:44 tf: thanks, just discovered that using google. man page doesn't really mention what it's for Aug 29 17:12:01 bluelightning: got a clue? http://paste.kde.org/~lpapp/pa77846a6/ Aug 29 17:12:03 tf: "reverse depends" is the thing that causes the selected package to be installed right? Aug 29 17:12:07 bluelightning: trying to use my first image... Aug 29 17:13:01 lpapp: looks like you've upgraded from denzil to dylan; tasks were renamed to packagegroups Aug 29 17:13:08 lpapp: it's in the migration notes in the manual Aug 29 17:13:16 it seems as if meta-toolchain-qte is not building Qt with -qt-gfx-transformed option turned on.. I'm getting "transformed: driver not found" on my BBB. Who handles/supports open-embedded core recipes? Aug 29 17:13:18 bluelightning: this is my image file, http://paste.kde.org/~lpapp/p4755a9a2/ Aug 29 17:14:17 https://www.yoctoproject.org/docs/current/poky-ref-manual/poky-ref-manual.html#migration -> ok. Aug 29 17:14:30 BCMM: yes Aug 29 17:14:58 tf: why are their packages that have only themselves as a reverse dep? Aug 29 17:14:59 cfo215: the Qt4 recipes are maintained by me, as it happens Aug 29 17:15:06 cfo215: that is odd Aug 29 17:15:15 bluelightning, afaik, it's supposed to be included by default during the bitbake. Aug 29 17:15:16 BCMM: no idea Aug 29 17:15:43 BCMM: perhaps a bug the depexp app Aug 29 17:16:22 or maybe some cached information is broken Aug 29 17:16:42 BCMM: no, I don't think so, it's always been like that in the list Aug 29 17:16:47 are there specific steps i should take if i "git pull" layers i'm using between builds? Aug 29 17:17:13 BCMM: it really depends on the nature of the changes that come in Aug 29 17:17:41 cfo215: that's what I would have thought too Aug 29 17:18:16 BCMM: mostly you should be able to just run a build again Aug 29 17:18:20 bluelightning: so my image is supposed to build what image-core-minimal builds? Aug 29 17:18:45 but sometimes it is necessary to wipe out the tmp dir Aug 29 17:20:36 tf: heh, it looks like i might have called my bbappend file ".bb" instead of ".bbappend"... that's probably where the deps came from, somehow Aug 29 17:21:21 BCMM: if it's accounting for runtime dependencies, that can easily explain a self referene. any given recipe emits multiple binary packages, and they depend on one another Aug 29 17:21:26 reference Aug 29 17:21:54 kergoth: you mean the stuff that only rdepends from itself? Aug 29 17:22:04 I dont understand the question Aug 29 17:22:15 again, a recipe's binary packages depend on one another. e.g. -dev usually depends on the main package Aug 29 17:22:28 lpapp: see 4.1.2.4. Task Recipes Aug 29 17:22:29 that doesnt' mean thats all they depend on, many runtime dependencies are generated at build time Aug 29 17:22:46 lpapp: if it helps you can always look at the dylan version of core-image-minimal Aug 29 17:23:50 bluelightning: refman? Aug 29 17:24:02 lpapp: yes Aug 29 17:24:04 bluelightning: ah, you mean, the porting. That is fixed already. Aug 29 17:24:15 bluelightning: I am just asking in general as I inherited that image file. Aug 29 17:24:29 and what I basically need is core-image-minimal + a couple of custom softwares. Aug 29 17:24:36 so I would like to extend core-image-minimal Aug 29 17:25:10 lpapp: I always recommend copy and modify for image recipes Aug 29 17:25:10 bluelightning: the image built successfully, but I am not sure what it was supposed to build, at least not exactly anyway. Aug 29 17:36:59 am i right in saying that, if I have a .bb recipe with the same filename in two different layers, the one that comes later in bblayers.conf is used and the other one ignored totally? Aug 29 17:37:28 nope Aug 29 17:37:37 order in bblayers.conf affects .conf/.bbclass priority Aug 29 17:37:44 recipe priority is controlled byt eh priorities defiend in the layer.conf files Aug 29 17:38:10 kergoth: ah, thanks Aug 29 17:38:44 kergoth: how to bbappends work? can a .bbappend effect the interpretation of a .bb from a higher-priority layer? Aug 29 17:39:19 bbappends are appended to the recipe Aug 29 17:39:22 not unlike concatenating the files Aug 29 17:39:35 and they are applied in layer priority order Aug 29 17:45:55 are higher or lower numbers high priority? Aug 29 17:46:12 BCMM: higher Aug 29 18:21:32 kergoth: can you direct me to some sort of documentation about setting priorities? i'm clearly done something wrong, but can't work out how Aug 29 18:21:55 i know my recipe can be found, because if i move the other layer's recipe, mine gets used Aug 29 18:22:04 but if i leave the other layer's one in place, it does not Aug 29 18:32:31 Hi folks, I'm building an image for mips and it's using the o32 ABI, but I need the n32 ABI. Where's the knob to change that? Aug 29 18:33:38 JaMa: do you know if Joe still actively maintains meta-networking? Aug 29 18:33:48 (or if it is better to fork) Aug 29 18:34:19 yes, he is actively maintaining it Aug 29 18:35:08 then I do not understand why he has replied to my change. Aug 29 18:35:19 I guess TUNE_FEATURES = "mips64-32" Aug 29 18:37:00 or DEFAULTTUNE Aug 29 18:37:42 jama: heh, i was about to send the same change for the xbmc recipe (libmad dep). nice work :) Aug 29 18:39:09 lpapp: possibly on vacation, I think he will be back after the US Long weekend (next week sometime) Aug 29 18:39:46 zibri: it still fails, but at least a bit later in do_compile (like it always did) xbmc/utils/MathUtils.h:101:28: error: impossible constraint in 'asm' Aug 29 18:40:03 hum, i got different failures. Aug 29 18:40:31 this one is repeated in every "State of bitbake world" update... Aug 29 18:40:39 optional deps (swig, java) causing fatal errors. and some other stuff Aug 29 18:41:07 sgw_: right, I was looking for some vacation message on the mailing list... Aug 29 18:41:31 not sure if adding swig-native dep is the correct solution, even more hesitant about adding java deps :/ Aug 29 18:41:52 and even if i do, it fails somewhere else anyways :) Aug 29 18:49:26 I really hate it when people post patch series without [PATCH] or equivalent Aug 29 19:00:51 Anyone know if the beaglebone black linux 3.8.13 kernel can have the RT-linux patches applied? Aug 29 19:12:18 Is it as simple as setting LINUX_KERNEL_TYPE to pre-emtive-rt in the kernel recipe file ..? Aug 29 19:12:59 if you are using linux-yocto, it's the linux-yocto-rt recipe. Aug 29 19:13:34 (which sets that variable). if you have extra board patches, that I don't have in that tree, you can add them via a layer. Aug 29 19:25:09 zeddii: I am using the linux-mainline source Aug 29 19:25:23 then you need to apply everything yourself. Aug 29 19:25:41 how do i go about that? Aug 29 19:25:48 but if you are on 3.8.x, then linux-yocto-3.8 has everything you need already. Aug 29 19:26:17 I am on 3.8, are you saying it has the kernel patched allreaty for RT Aug 29 19:27:01 the linux-yocto kernel has branches for different features standard/preempt-rt/base has it already applied. Aug 29 19:27:22 My kernel is linux-mainline-3.8.13 Aug 29 19:28:27 in that case, you need to grab the patches, and add them to the SRC_URI, just like any recipe does. Aug 29 19:29:03 So I have to grab the patches from linux-yocto-3.8 and apply then to linux-mainline-3.8.13 in my layer? Aug 29 19:32:17 zeddii: Is that correct? Aug 29 19:32:50 you could, but I'd have to ask why :) Aug 29 19:32:55 since they are already applied. Aug 29 19:33:09 or you can to go the upstream project and grab the -rt patch and apply it that way. Aug 29 19:33:09 What do you mean? Why I want real-time? Aug 29 19:33:35 no, I mean why yank patches out of a 3.8 linux-yocto recipe and apply them to another 3.8 kernel tree. Aug 29 19:33:48 you can of course do whatever you need to do, but there may be a faster way to do it. Aug 29 19:33:57 Cause I don't know where to find the upstream patches? Aug 29 19:36:03 zeddii: I thought you said the patches were allready applied to linux-yocto-3.8.x not linuc-mainline-3.8.x?? Confused Aug 29 19:37:07 yep. Aug 29 19:37:29 i.e. I'm not sure where you are getting your linux-mainline-3.8.x, I assume it is a recipe you created ? Aug 29 19:37:51 yep what? Aug 29 19:37:53 all of the patches I apply to linux-yocto can either be dumped from the tree, or found in git://git.yoctoproject.org/kernel-cache Aug 29 19:38:03 s/kernel-cache/yocto-kernel-cache/ Aug 29 19:38:27 I did say that the patches were on linux-yocto-3.8, branch standard/preempt-rt/base Aug 29 19:38:43 No, linux-mainline is in the BBB receipe ... I am building images from meta-pansenti layer Aug 29 19:39:20 ok. so you can always go an try to extract my patches, or hit the linux-rt wiki (google will find it with that), and you'll find the upstream patches. Aug 29 19:40:18 what do you mean "your patches" did you create the linux-yocto ones? Aug 29 19:45:58 brm. yes, I've merged all of the core support for the linux-yocto* trees. Aug 29 19:46:19 create is too strong a work, integrated is more accurate :) Aug 29 19:46:31 I've been porting and using preempt-rt since 2.6.12 though :) Aug 29 19:46:45 cool .. :) Aug 29 19:47:15 So still strugling to find the patches for linux-mainline Aug 29 19:47:32 sec. let me post a gitweb link Aug 29 19:48:36 warning, this will be a large patch: http://git.yoctoproject.org/cgit/cgit.cgi/yocto-kernel-cache/tree/features/rt/preempt-rt-integrate-patch-3.8.4-rt2.patch?h=yocto-3.8 Aug 29 19:48:47 Is this the correct place? https://www.kernel.org/pub/linux/kernel/projects/rt/3.8/ Aug 29 19:48:52 yep. Aug 29 19:49:03 I have all my upstream sources in the commit logs Aug 29 19:49:05 Merging patch-3.8.4-rt2 from: https://www.kernel.org/pub/linux/kernel/projects/rt/3.8/ Aug 29 19:49:09 (is what was in my log) Aug 29 19:50:00 Ok, so I have a look at one of your merges, then do a similar thing on linux-mainline ... Aug 29 19:53:53 Got to go thanks ..:) Aug 29 20:47:23 zeddii: around? Aug 29 20:54:11 ant_home, for a few more mins. yep. did I break something ? ;) Aug 29 20:55:44 sent mail about qemumips vs. 3.10 headers Aug 29 20:56:51 oh interesting. I can patch linux-libc-headers again to fix it up. Aug 29 20:57:02 folks, I'm trying to build a minimal image for mips32 with DEFAULTTUNE = "mips64-n32", and I get a failure while trying to build busybox. mips64-poky-linux-gnu32-ld: applets/applets.o: file class ELFCLASS32 incompatible with ELFCLASS64 Aug 29 20:57:42 any idea what I may have done wrong? Aug 29 21:09:55 does mips64-ciscovs-linux-gnun32-ld need the -mabi=n32 parameter that gcc uses? Aug 29 21:13:09 Need some advice in applying a real-time patch to linux-mainline-3.8.13-r23a kernel Aug 29 21:13:53 path upstream is called 3.8.13-rt15.patch and doesn't path cleanly .. Aug 29 21:14:05 5 files error ourt Aug 29 21:14:08 mips64-poky-linux-gnun32-ld: Attempt to do relocatable link with elf32-ntradbigmips input and elf64-tradbigmips output Aug 29 21:22:35 anyone? Aug 29 21:23:32 I think no one is home Aug 29 21:45:50 I think you are right Aug 29 22:01:14 brm: all files or just some files referred to in the patch? Aug 29 22:12:02 bluelightning: just some files in the patch .. 5 of them Aug 29 22:13:50 It doesn't patch correttly in Yocto, it does work if I patch the kernel outside yocto Aug 29 22:14:43 I am using the linux-mainline kernel heavily patched in meta-beagleboard and trying to apply a RT patch Aug 29 22:16:23 kernel version is linux-mainline-3.8.13.23a Aug 29 22:22:18 I think the meta-beagleboard patches are conflicting with the RT patches for the base kernel Aug 29 22:22:25 how do I fix this? Aug 29 22:37:51 brm: I don't know I'm afraid Aug 29 22:38:27 brm: the fact that some files don't match up suggests that either there is a conflict or the patch you're trying to apply wasn't meant for the version of the kernel you're applying it to Aug 29 22:38:32 looks like I will have to merge the patch sets somehow Aug 29 22:38:42 right Aug 29 22:39:07 The beaglebone patches are definetely conflicting with the RT patch set .. Aug 29 22:39:10 probably easiest to do that externally in a separate git tree, at least that's the way I would do it Aug 29 22:39:58 frankly it would be easiest if everyone just got their stuff upstream Aug 29 22:41:25 I agree .. Aug 29 22:41:59 There is something like 150 beaglebone patches to the kernel!! Aug 29 22:42:53 make that 650 patches Aug 29 22:44:16 hmm, that is quite a lot Aug 29 23:09:33 Jefro: going to troll my talk? :) Aug 29 23:50:09 Hmm, we need to improve the ruby handling to be on per with perl/python Aug 29 23:50:47 I would not mind that at all. I get along with Ruby. Aug 29 23:51:22 I never got around to learning it.. seems like once you know either ruby or python, the need to learn the other drops down, since they tend to overlap in where they're useful Aug 29 23:51:32 though ruby does have better support for DSLs Aug 29 23:54:15 I mostly just like it better. Easier for me to read/write. **** ENDING LOGGING AT Fri Aug 30 02:59:58 2013