**** BEGIN LOGGING AT Wed Dec 07 02:59:57 2011 Dec 07 05:05:01 * wmat fixes oe wiki new user registration, hopefully Dec 07 06:29:48 readelf -d arm-angstrom-linux-gnueabi-gcc: http://pastebin.com/hMRGwtpH Dec 07 06:31:01 does the RPATH there explain why I have to extract my SDK to /usr/local? Dec 07 06:37:26 and: good morning Dec 07 07:02:51 tasslehoff: I've never used SDKs, but I've seen quite patches for SDK relocation support on the list year or so ago Dec 07 07:03:20 tasslehoff: I think, that you can change the rpath with chrpath easily Dec 07 07:04:32 the question is if it's enough :p Dec 07 07:04:45 ynezz: ah. it's a start at least :) Dec 07 07:04:55 khem: ^ Dec 07 07:05:36 and it might be better to ask on the list Dec 07 07:11:06 ynezz: yeah. I'll post a question. Dec 07 07:46:32 good morning Dec 07 07:56:08 gm Dec 07 08:31:40 hi likewise, mckoan, all Dec 07 08:32:08 rstarting pidgin, biab Dec 07 09:08:34 mornin Dec 07 09:53:03 Jin^eLD: (and everyone else): good morning Dec 07 09:53:28 hey likewise :) Dec 07 09:54:04 good morning Dec 07 09:54:05 morning : ) Dec 07 10:06:17 morning all Dec 07 10:06:51 hi bluelightning Dec 07 10:10:30 bluelightning: good morning Dec 07 10:12:28 JaMa: good morning Martin, could you share your thoughts on this one for a sec, thanks? http://lists.linuxtogo.org/pipermail/openembedded-core/2011-December/013897.html Dec 07 10:21:27 likewise: fine with me :) Dec 07 10:24:23 JaMa: thanks. Is the package name "kexec" and "kdump" ok, or should it be "kexec-tools-kexec" and "kexec-tools-kdump"? I am ok with the first, I just wondered how we approach the namespace in general. Dec 07 10:25:57 easier if original names are kept (updating only oe-core stuff depending on kexec-tools) IMHO Dec 07 10:26:19 also users will probably try to opkg install kexec not kexec-tools-kexec Dec 07 10:26:56 JaMa: I agree, it is a different issue and no other package provides it (in contrast with "busybox-" package names). Dec 07 10:27:21 JaMa: I'll test some more and post a patch. Thanks. Dec 07 10:27:31 yw Dec 07 10:53:11 hi all Dec 07 10:58:36 hi pb_ Dec 07 11:25:06 hi pb_ Dec 07 12:46:00 Hi there, is there a mechanism to only download the source packages? Dec 07 12:46:48 sometimes my builds are failung due to outdated SRC_URI descriptions or incomplete mirrors (kernel.org) Dec 07 12:47:30 so, it would be nice to have bitbake to fetch things to the downloads dir first Dec 07 12:50:52 hm, maybe I can restict it to the do_fetch task Dec 07 12:51:48 bitbake -c fetch_all I think Dec 07 12:52:17 so bitbake -c fetch_all blah-image Dec 07 12:52:32 * XorA is working from foggy memory though Dec 07 12:54:50 hi i am comiling a angstrom-gnome-image but it gives me fail at that point http://pastebin.com/V8NLcgNY Dec 07 12:55:01 XorA: thanks! as from the listtasks output it looks like -c fetchall is the one Dec 07 12:56:23 erwt: corrupt download from the looks of it Dec 07 12:56:39 how to solve Dec 07 12:56:53 remove from your downloads dir and try again Dec 07 12:57:03 I guess you only got partial file Dec 07 12:57:19 or its just duff on the original source Dec 07 12:57:26 or your network is flaky Dec 07 12:57:32 sometimes the transparent proxies are doing nasty things with gz files Dec 07 12:57:36 fine i will try Dec 07 12:57:44 I'd check what: file /home/rahul/OEBASE/sources/libcdaudio-0.99.12p2.tar.gz Dec 07 12:57:47 gives Dec 07 12:58:30 kenws: yeah Ive seen corporate ones replace random chunks of binary files with html Dec 07 12:59:06 : ) Dec 07 13:00:27 hm, shouldn't the fetch task recognize files that have been manually placed into the downloads dir? Dec 07 13:03:27 md5sum file.tar.gz >file.tar.gz.md5 Dec 07 13:05:15 XorA: in case the md5sum hint was for me, I already checked it and it matches to what the receipt states Dec 07 13:06:27 maybe there's a missing "stamp" or something that tells the build system that it still needs to fetch that file Dec 07 13:08:51 kenws: check again what I wrote the stamp is the md5sum Dec 07 13:08:53 or was Dec 07 13:08:58 unless fetch2 changed all that] Dec 07 13:10:04 XorA: are you saying that the build system recognizes the file.tar.gz.md5 in the downloads directory? Dec 07 13:10:49 it certainly used to signal successful download Dec 07 13:11:36 but there are no other .md5 in that directory Dec 07 13:11:50 and it already downloaded plenty of them Dec 07 13:12:01 hm, I don't get it : ) Dec 07 13:12:22 kenws: hi, isn't there a archive.tar.gz.done file in the download directory ? Dec 07 13:12:45 aah, the .done files Dec 07 13:12:51 kenws: yes this one Dec 07 13:12:55 that seems the "stamp" Dec 07 13:12:56 cool Dec 07 13:13:00 ericben: thanks! Dec 07 13:13:06 XorA: and thank you too! : ) Dec 07 13:13:53 * XorA is obviously years out of date and retires Dec 07 13:14:33 from what I see, before the stamp was the checksum file now it's the .done file Dec 07 13:16:23 hmpf, I just did a `touch /path/to/download/file.tar.gz.done` to create the empty -done file but bitbake still tries to download it Dec 07 13:16:34 so you can not wget -R one of the source mirrors and then add the .done files :-D Dec 07 13:17:27 kenws: download the file, md5sum $file > $file.md5 Dec 07 13:17:32 then it will not get downloaded Dec 07 13:17:46 that can't be right... when I do builds with a preserved downloads directory it does not re-fetch every file Dec 07 13:18:21 * Jin^eLD thinks that .md5 files do the trick Dec 07 13:18:35 Jin^eLD: i'll try Dec 07 13:19:12 bluelightning: yeah, there are a plenty of files already in the downloads dir that don't get re-fetched Dec 07 13:19:21 I don't think the md5 files are used with fetch2 Dec 07 13:20:22 at least the downloads dir of my oe-core build has only sources and .done files Dec 07 13:21:07 hmm, no idea why it worked for me then Dec 07 13:21:53 creating the .md5 doesn't seem to have any impact for me (on oe-core) Dec 07 13:23:32 weird.. I had the problem that I could not fetch some fies, so I just copied them to the downlaods dir from another machine, generated the md5 and they did not get refetched; although I have to admit I did not try it without the md5 thing Dec 07 13:23:46 I kind of remembered md5 was doing its job in oe classic (but maybe I was wrong there too?) Dec 07 13:24:19 Jin^eLD: yeah,maybe that mechanism has changed recently Dec 07 13:24:58 to be honest I have no idea, I just started with oe Dec 07 13:25:30 well, copying the tarball to the dl dir worked for me in OE core (md5 was not necessary as we just found out..) Dec 07 13:26:16 kenws: which recipe do you have this problem with ? Dec 07 13:26:38 meta/recipes-graphics/libxsettings-client/libxsettings-client_0.10.bb Dec 07 13:26:43 but I think it was my bad Dec 07 13:27:25 I've got more than one build dir that uses the same downloads dir, but it looks like I've messed up my local.conf in one case Dec 07 13:27:53 so that the build was pulling things from build/downloads rather than my shared downloads dir Dec 07 13:27:57 * kenws ducks Dec 07 13:28:04 ah, that explains it :) Dec 07 13:28:10 :) Dec 07 13:33:42 setting DL_DIR to the correct value works flawlessly. I don't even have to create the .done file as the build system seems to recognize the existant file and moves on from there Dec 07 13:33:48 sweet! : ) Dec 07 13:35:25 I have to admit I'd like to know what the .done file actually does Dec 07 13:36:19 bluelightning: I suspect it's kind of a stamp we have the bitbake sources, so all we need to do is to look at the fetch task : ) Dec 07 13:36:40 s/stamp we/stamp. we/ Dec 07 13:36:48 donestamp is file stamp indicating the whole fetching is done Dec 07 13:36:49 this function update the stamp after verifying the checksum Dec 07 13:36:54 this is the comment in bitbake Dec 07 13:37:02 there we go : ) Dec 07 13:37:05 thanks ericben! Dec 07 13:38:01 kenws: yeah just checked, it looks to be informational, nothing in fetch2 actually checks to see if it exists (apart from the code that updates it) Dec 07 13:38:47 I'm guessing it is currently intended to help find stale files in your downloads dir Dec 07 13:39:07 Isn't the sstate-cache used for stamps and those things that tells the buildsystem which tasks are done? Dec 07 13:39:22 no, there's a stamps dir for that Dec 07 13:39:30 ah, ok - sounds reasonable Dec 07 13:40:08 but in the absence of that stamp for sstate candidate tasks it will check the sstate cache for an sstate package with the appropriate checksum Dec 07 13:43:16 one thing that does annoy me with fetch2 is that interrupted fetches seem to be able to foul things up to the extent that manual intervention is required (-c cleanall) Dec 07 13:46:36 Is there a way to specify some sort of a "fall back" mirror? Dec 07 13:46:53 a good candidate would be: http://downloads.yoctoproject.org/releases/yocto/yocto-1.1/sources/ Dec 07 13:48:58 kenws: yep, POSTMIRRORS is the mechanism for that Dec 07 13:50:17 kenws: although in poky we use PREMIRRORS so we're trying our mirror first Dec 07 13:55:57 kenws: it helps to have DL_DIR pointing to outside of build directory Dec 07 13:56:20 and for *.md5 (oe classic) simple touch was enough Dec 07 13:57:19 bluelightning: thanks, I'll add it to my local.conf. Dec 07 13:58:38 kenws: FYI there's a special syntax for that variable Dec 07 13:58:56 although I think just putting one URI in it does work Dec 07 13:59:16 hrw: yep, the DL_DIR is pointing outside my build dir. Since I have a couple of build dirs I also need to maintain a couple of local.conf files. And in one of the configs I had the stock DL_DIR : ) Dec 07 14:00:38 bluelightning: does the POST/PREMIRRORS work with things like the http://downloads.yoctoproject.org/releases/yocto/yocto-1.1/sources/ ? Dec 07 14:00:45 kenws: you can set such things in build/conf/site.conf and copy it between build dirs (or even symlink) Dec 07 14:01:28 I haven't tried it but I could imagine that the mirror need to reflect the structure (directories) Dec 07 14:01:53 hrw: ok, I'll keep that in mind. thanks! Dec 07 14:03:13 kenws: the structure doesn't need to be replicated; my only question is will a single URI work or do you have to set it on a per-protocol basis Dec 07 14:03:56 I see... Dec 07 14:04:47 kenws: the structure doesn't need to be replicated; my only question is will a single URI work or do you have to set it on a per-protocol basis Dec 07 14:04:52 ah sorry Dec 07 14:05:57 kenws: I think you do have to; however you may want to INHERIT += "own-mirrors" and then set SOURCE_MIRROR_URL to that Dec 07 14:08:51 has amyone has the mdz5 no for ca-certificates_20090814+nmu2 Dec 07 14:09:04 plz i am sick of changing them Dec 07 14:23:36 bluelightning: yes, there doesn't seem to be support for POSTMIRRORS within fetch2, I only saw PREMIRRORS and MIRRORS Dec 07 14:24:13 kenws: that might be because I meant MIRRORS and my memory failed me ;) Dec 07 14:24:16 hi ericben Dec 07 14:24:19 hi otavio Dec 07 14:24:22 I've that: Dec 07 14:24:24 WARNING: File '/usr/bin/qt4/examples/sql/drilldown/drilldown' from qt4-x11-free was already stripped, this will prevent future debugging! Dec 07 14:24:37 when building QT Dec 07 14:24:45 GNUtoo: I have a fix for that here Dec 07 14:24:56 ok Dec 07 14:25:04 probably should post it today Dec 07 14:25:10 ok thanks Dec 07 14:27:05 mrmoku: time to cleanup few older images.. http://paste.pocoo.org/show/517537/ Dec 07 14:43:03 JaMa: heh, yeah Dec 07 14:44:38 mrmoku: dropped them all (for armv7 machines.. lets see how 004 works.. :/) Dec 07 14:45:04 mrmoku: and reopened http://bugzilla.pokylinux.org/show_bug.cgi?id=1711 Dec 07 15:38:38 gm galak Dec 07 15:38:59 likewise: hi Dec 07 15:42:35 ao2: you used the openembedded-devel address for an or-core patch. We separated these for oe-core patches going to openembedded-core@lists.openembedded.org Dec 07 15:42:49 ao2: just in case you wonder when no review is coming in Dec 07 15:44:07 stefan_schmidt, thanks, I've been away for a while. Do you know if openembedded-core@lists.openembedded.org requires subscription? Dec 07 15:44:27 ao2: afaik it does, moderated I would think Dec 07 15:44:41 ok, thanks Dec 07 15:44:45 ao2: np Dec 07 15:46:52 I am playing with oe-core, layers and mr (multi repository), I'll share the oe-ezx setup when it's done. The idea is to bring in the all the pieces by just requiring one text file ".mrconfig" Dec 07 15:47:54 ao2: we have different approaches for the layering right now. The angstrom setup-scripts are using a script called layerman Dec 07 15:48:16 yes, oe-core@ is member-posting only. I think all the oe.org lists are set that way. Dec 07 15:48:23 and there are also some scripts from yocto and I think otavio is using them as well. Don't remember the name right now Dec 07 15:48:36 pb_: thanks Dec 07 15:49:14 ao2: I'm undecided on the best approach here but I think we need better tooling to allow easier handling of all the different layers. Dec 07 15:49:51 Especially when we start to have releases where branches need to match other release branches. Future though Dec 07 15:50:42 I am liking mr so far but I haven't explored all its functions, neither I am able to compare it to alternatives right now. Dec 07 15:50:57 stefan_schmidt: combo-layer is the one ke and I worked on Dec 07 15:51:12 bluelightning: right, now I remember :) Dec 07 15:51:53 my idea is to use a generic tool, let's see how that comes out Dec 07 15:53:37 interesting, this is the first I've heard about mr Dec 07 16:34:32 oh drat Dec 07 16:34:34 * pb_ stabs rm_work Dec 07 16:35:11 just spent the last three hours trying to make webkit build and, of course, the moment it succeeded oe went and deleted all the source code that I just modified Dec 07 16:37:02 pb_: ouch. Dec 07 16:37:28 doh :( Dec 07 16:37:38 pb_: at these times, I would love to have a filesystem that does snapshots. (so that empty space is used for history rollback). Dec 07 16:38:36 yeah Dec 07 16:38:41 I think I am going to turn rm_work off again. Dec 07 16:39:14 we have a local hack called "rm_old_work" which deletes all versions other than the latest from the workdir, which seems to be good enough to stop the disk usage growing completely without bounds. Dec 07 16:39:43 pb_: nice, could you share "rm_old_work" Dec 07 16:39:47 ? Dec 07 16:40:04 yeah, let me dig it out Dec 07 16:41:03 with rm_work as it's working now with sstate I would really like to be able to use at least rm_old_work Dec 07 16:42:14 I checked it into the meta-micro tree. http://git.openembedded.org/meta-micro/tree/classes/rm_old_work.bbclass Dec 07 16:42:24 thanks Dec 07 16:45:53 pb_: or override rm_work task in hacked recipe? Dec 07 16:46:23 well, yeah, but that relies on remembering to actually do it each time Dec 07 16:46:41 which is exactly where I went wrong on this occasion Dec 07 17:00:25 neat Dec 07 17:00:35 I wish we did housecleaning on more of our stuff for old versions Dec 07 17:00:45 would be nice for downloads, etc Dec 07 17:00:54 yeah Dec 07 17:01:30 the trouble is a lot of that is hard to remove deterministically Dec 07 17:01:48 yep Dec 07 17:01:48 though a workaround such as pb_'s should be OK most of the time Dec 07 17:01:49 it is a bit sad (although understandable) that your oe tree gradually gets bigger and bigger until it consumes all available disk space Dec 07 17:09:33 pb_: heh webkit, yes that was one who inspired me to use gold Dec 07 17:10:04 pb_: its the ld that took like 45 minutes alone Dec 07 17:10:11 in my case Dec 07 17:10:29 oddly, I don't see that problem here Dec 07 17:10:40 I'm not using gold since I don't think it supports mips yet Dec 07 17:10:56 pb_: yes it does not support mips Dec 07 17:11:01 and I haven't noticed any pathological link times with ld.bfd Dec 07 17:11:03 so far arm/x86/amd64 Dec 07 17:11:44 hmm webkit-gtk it was in my case and I could see ld using up all of my memory and thrashing Dec 07 17:12:34 khem: similar times with webkit-* linking here Dec 07 17:12:53 JaMa: can you try it with gold ? Dec 07 17:12:55 * JaMa adding extra swap just to link webkit-* without oom Dec 07 17:13:12 not right now Dec 07 17:14:08 ah, if it was slow due to out of memory then that might explain why I'm not seeing the problem Dec 07 17:14:22 I do have 20G of RAM and 40G of swap on this machine which might be enough to avoid the oom situation Dec 07 17:14:27 JaMa: just add DISTRO_FEATURES += "ld-is-gold" to enable it and then rebuild from scratch whenever you want to try it out Dec 07 17:14:54 will try when I'll update webkit-efl to newer rev.. Dec 07 17:14:57 pb_: hrmm definitely but then why three hours Dec 07 17:15:18 three hours for me to build webkit, you mean? Dec 07 17:15:25 was it just webkit or everything upto webkit Dec 07 17:15:44 most of that wasn't actual build time, it was me figuring out what changes were needed to make it compile Dec 07 17:16:05 pb_: ok Dec 07 17:16:23 I'm not sure how long it would have taken from clean, probably 15 mins at a guess Dec 07 17:16:27 I found that not using rm_work is better for dev work Dec 07 17:16:35 but it does eat up lot of space Dec 07 17:17:06 once I get the sources reinstated I can try timing a build. certainly minutes not hours though. Dec 07 17:18:28 pb_: yeah if you have 20G of ram I dont see any issues Dec 07 17:18:38 I have 2G of ram on that box Dec 07 17:19:01 right, I can imagine that would be no good Dec 07 17:20:19 pb_: but gold helped me there Dec 07 17:20:57 pb_: what mips chip are you targetting at ? Dec 07 17:22:40 a proprietary one. Dec 07 17:22:53 ok cool Dec 07 17:22:59 are you using N32 Dec 07 17:23:07 ABI Dec 07 17:23:37 no, we're on 32 bit. o32 Dec 07 17:23:51 hmm ok Dec 07 17:24:17 all mips above mips1 can support N32 though Dec 07 17:24:36 at work we still support mips1 so I am out of luck Dec 07 17:24:44 but they do want performance Dec 07 17:26:38 ah, I thought n32 required mips64. Dec 07 17:27:15 only 64bit registers Dec 07 17:27:18 which they do have Dec 07 17:27:37 mips32 doesn't have 64 bit registers, only 32 bit Dec 07 17:38:59 pb_: yes mips32 is 32bit regs IIRC its reincarnation of mips2 Dec 07 17:39:19 so no n64, right? Dec 07 17:39:23 er, no n32 Dec 07 17:46:42 pb_: yep Dec 07 18:16:16 quick recipe question... SRC file:// urls, if I have a dozen files, can I use wildcards or do they have to be explicitly mentioned? Dec 07 18:29:09 hi i am new embedded system developer and I need help on buidling my own embedded linux distro. I am not sure if i should put this question here... bt please guide me on same.. You will be helping future of the linux embedded developer Dec 07 18:29:41 there is plenty of documentation, go read it Dec 07 18:29:50 we aren't going to hold your hand, I'm afraid Dec 07 18:29:58 thank you Dec 07 18:30:04 for your reply ... Dec 07 18:31:25 yes i know you are not going to hold my hand .. but pointer is what i need .. though thanks Dec 07 18:34:56 thanks i found manual on OE.. and it seems perfect for my answer... and thank you for pointing and sorry if my question was silly ....... Dec 07 18:39:33 hm, I have file:// URIs in my SRC_URI, and my do_install() does "install -m 0644 ${WORKDIR}/stuff_from_file:// ${D}/etc/some/path/here"... install complains that the source dir is empty and thus fails. Is there some secret sauce involved in copying the files listed with file:// in the SRC_URI to WORKDIR? Dec 07 18:39:49 I'm looking at some of the other recipes that do similar things but it seems to be automatic Dec 07 18:40:10 dhanraj: I'd suggest reading the documentation at the yocto project Dec 07 18:40:20 dhanraj: most of it also applies to oe proper, and its superior Dec 07 18:42:30 it looks like the files mentioned in SRC_URI end up in ${WORKDIR} automatically. is there something I'm missing? Dec 07 18:45:43 this might have to do with my having SRC_URI including wildcards I guess Dec 07 18:47:30 it is automatic. and I have no clue how wildcards are handled right now Dec 07 18:47:41 we need some automated testing for the fetch/unpack/patch process Dec 07 18:51:33 yeah the documentation is pretty weak for local fetchers atm Dec 07 18:51:34 http://bitbake.berlios.de/manual/ch03s02.html Dec 07 18:51:58 the bitbake manual hasn't been touched in years Dec 07 18:52:10 the fetcher has been replaced since then Dec 07 18:52:16 and unpacking moved into bitbake Dec 07 18:54:14 hm Dec 07 18:58:41 :( Dec 07 19:02:07 hm, even specifying the files individually it's not populating WORKDIR Dec 07 19:19:56 Are they patches? Dec 07 19:25:31 re Dec 07 19:31:51 ah, it seems like 90% of my problems were not -c clean'ing before re-running the recipe Dec 07 19:56:52 help ! im confused, which OE branch to use for collie ? Dec 07 19:58:11 tzanger: heh, that'd do it Dec 07 19:58:18 ralfw: depends on whether you're using oe-core or classic oe Dec 07 19:58:46 kergoth`: dont confuse me more Dec 07 19:58:57 well, that doesn't change the facts Dec 07 20:03:13 fine ill try 2011.03-maintenance, master just doesnt work on collie Dec 07 20:07:05 fix it Dec 07 20:32:41 we should start a buy back program for the older devices Dec 07 20:42:47 this makes even less sense Dec 07 20:42:55 a recipe uses an http:// SRC_URI, no problem Dec 07 20:42:57 it builds fine Dec 07 20:43:12 I add a couple patch files (0000-firstpatch-to-use.patch and 0001-secondpatch-to-use.patch) Dec 07 20:43:25 OE seems to be tryign to apply the patches before it downloads the source Dec 07 20:43:34 I've definitely -c clean'd this time Dec 07 20:44:31 is there a problem with the SRC_URI's being processed in a sorted order? Dec 07 20:50:50 khem: evening (here at least). I posted the readelf output to the ML Dec 07 20:51:53 tzanger o.O Dec 07 20:52:18 I think http first Dec 07 20:56:08 Crofton|work, what do you mean exactly? what about batteries? Dec 07 21:02:14 woglinde: my reaction too. I'm looking through it Dec 07 21:10:54 GNUtoo, buy up all the older machines we used to support :) Dec 07 21:11:14 some people want to give theses machines for free Dec 07 21:11:26 like mickeyl for instance Dec 07 21:11:53 but the problem is that he doesn't know if they still work or not Dec 07 21:11:59 zauruses and ezx Dec 07 21:13:06 the problem is find new maintainers I guess Dec 07 21:13:14 tzanger: no, SRC_URI is alwyas processed in the order it's defined Dec 07 21:13:21 GNUtoo, yes Dec 07 21:13:39 but may be easier on us just to buy up all the outstanding hardware :) Dec 07 21:13:49 yes but to give to whom? Dec 07 21:13:59 how to find new maintainers? Dec 07 21:16:07 * Jay7 have lot of Z's but short in time.. Dec 07 21:16:13 no, get tehm out of circulation Dec 07 21:16:24 so people do not have problems, get frustrated and give up Dec 07 21:16:45 it would be great to spend 2-3 month on dedicated work on Z's support in OE-core/meta-hh Dec 07 21:16:53 but.. real life is so real Dec 07 21:19:55 hehe Dec 07 21:20:22 yes Dec 07 21:20:36 even more.. dedicated work to bring meta-oe to state of oe-classic Dec 07 21:20:48 i.e. working and usable gpe and opie :) Dec 07 21:23:14 heh Dec 07 21:23:15 yeah Dec 07 21:23:52 hm.. may be someone should try to get CELF founding this year to do this Dec 07 21:24:11 s/founding/funding/ Dec 07 21:25:28 has it been decided when oe-classic goes read-only? been a while since I was told "in a short while" :) Dec 07 21:26:12 tasslehoff: no real date afaik Dec 07 21:26:33 TSC should decide Dec 07 21:28:08 as long as noone asks me to comment... ;) Dec 07 21:28:29 Jay7: ok. Dec 07 21:28:44 hey. which script mounts /media/mmcblk0p2 in angstrom? Dec 07 21:29:00 there doesn't seem to be any entry in /etc/fstab for these Dec 07 21:29:05 mount.sh from udev? Dec 07 21:30:01 will there be more releases from classic? Dec 07 21:30:13 wouldn't that conflict with /dev/root mounting the same SD card partition rw as well? Dec 07 21:30:15 tasslehoff no Dec 07 21:30:22 no releases Dec 07 21:30:27 didnt you read the ml? Dec 07 21:30:34 msm: Hello Matthew, Leon 'likewise' here, nice to see you on #oe. Do you know if there are Freescale ppl also upstreaming i.MX SoC into oe-core? Dec 07 21:31:02 woglinde: something about it recently? Dec 07 21:31:04 or is it a bind mount? Dec 07 21:34:47 * tasslehoff calls it a day. good night. Dec 07 21:34:51 what is the oe-core way of modifying kernels in work/ ? I used to throw away some stamps file and run the deploy task, but this seems no longer supported. Dec 07 21:34:54 tasslehoff: nite Dec 07 21:35:23 tasslehoff, thanks for the hint Dec 07 21:35:51 likewise: i'm just on the ppc side Dec 07 21:35:58 likewise: not sure what the arm side has decided Dec 07 21:36:16 msm: I used to be ppc-only until last week :) Dec 07 21:37:12 msm: ppc is now moving away from ltib to yocto? Dec 07 21:38:41 likewise: yes Dec 07 21:38:53 likewise: some people have done fsl arm stuff Dec 07 21:38:58 for OE/yocto Dec 07 21:57:37 msm, hi yes Dec 07 22:00:08 one last question for the day (I hope) Dec 07 22:00:26 I've got a recipe that creates but also -default-config. Dec 07 22:00:59 I have a task that includes that recipe but also an alternate config recipe Dec 07 22:01:31 the recipes get built just fine, but if I look at the final image I can see that -default-config got included and the alternate config did not, although the alternate is spelled out in the RDEPENDS list Dec 07 22:03:15 both the config packages only have CONFFILES defined in them, so one should override the other, should they not? Dec 07 22:04:28 tzanger, basically you've got package that include the not-default config? Dec 07 22:04:58 and the ${PN}-default-config has the default config right? Dec 07 22:05:08 I have a package with the binaries, a package with the default config (all files are CONFFILES) and a recipe that creates a package with an alterante config (again all files CONFFILES) Dec 07 22:05:09 and you want the default config right? Dec 07 22:05:22 GNUtoo: yes ${PN}-default-config has the default config Dec 07 22:05:23 so you have 3 packages Dec 07 22:05:38 yes three altogether, but two "control" the same files (the conf files) Dec 07 22:05:44 ok Dec 07 22:05:55 the -defualt-config has the default config files from the package, and the -custom-config has the customized config Dec 07 22:06:05 ok Dec 07 22:06:16 tzanger: so both ought to provide ${PN}-virtual-config Dec 07 22:06:25 tzanger: or whatever Dec 07 22:06:32 yes indeed you should do something to handle the conflict Dec 07 22:06:34 hmm, ok, let me see if I can figure out how to encode that Dec 07 22:06:40 and verify if it worked in do_rootfs Dec 07 22:06:55 another option would include RCONFLICTS Dec 07 22:07:42 will ipk automatically do the right thing if I try to ipk install a package that conflicts with an installed one, or does it error out and let me rmeove it manually? Dec 07 22:08:02 it errors Dec 07 22:08:10 opkg errors on that Dec 07 22:08:18 you have 2 options then Dec 07 22:08:25 remove the old package and install the new one Dec 07 22:08:30 or --force-overwrite Dec 07 22:08:33 right, ok Dec 07 22:08:40 I think the virtual config is the better way to do it Dec 07 22:08:42 ah conflicts Dec 07 22:08:44 tzanger: your image most probably needs to set preferred provider for it Dec 07 22:08:46 sorry I didn't read well Dec 07 22:08:48 it errors Dec 07 22:08:59 and you have to uninstall the other package Dec 07 22:09:05 otavio: ok Dec 07 22:09:22 I'm not sure if you can get away with --force-overwrite Dec 07 22:09:27 tzanger: or install it before the package, so the depends will be satisfied Dec 07 22:09:27 I'll have to check Dec 07 22:11:53 hm, if the recipe is creating ${PN}, ${PN}-default-config etc can you say that one package that the recipe creates provides ${PN}-virtual-config, or does the defult config have to be broken out into its own recipe? Dec 07 22:13:15 tzanger: you need a package that provides it but this cannot be PN otherwise you'll end up without PN installed. Dec 07 22:13:40 right Dec 07 22:14:01 but what I'm saying is that one recipe creates two packages. how does one specify only ONE of those packages provides the virtual package? Dec 07 22:14:34 the recipe creates ${PN} ${PN}-default-config (as well as the ${PN}-debug and whatever else is automatic) Dec 07 22:14:57 how does one say ${PN}-defualt-config provides ${PN}-virtual-config Dec 07 22:15:47 it looks like there's just a single PROVIDES variable to be used in the recipe, but that would affect ${PN} as well... I think Dec 07 22:15:51 RPROVIDES_${PN}-default-config = "${PN}-config" Dec 07 22:15:56 oh Dec 07 22:16:01 there's a facepalm moment Dec 07 22:16:10 yeah; that's life Dec 07 22:16:13 heh Dec 07 22:18:07 thanks :-) Dec 07 22:21:03 np Dec 07 22:21:36 Wow, this is strange. The libproxy-0.4.7/libmodman/CMakeLists.txt generates a CMakeFiles/modman.dir/link.txt where the ar (arm-none-linux-gnueabi-ar) command is empty when using a binary cross toolchain. All the other generated link.txt of libproxy seems to be ok Dec 07 22:22:43 I've tweaked the meta/classes/cmake.bbclass to set the CMAKE_AR plus friends and the generated toolchain.cmake is looking good. **** BEGIN LOGGING AT Wed Dec 07 23:52:25 2011 Dec 08 00:28:46 khem: around? Dec 08 00:29:08 or, ka6sox? Dec 08 00:32:10 Tartarus, yes Dec 08 00:32:53 Hey, fyi I'll be at SCALE Dec 08 00:33:05 kewl! so will I Dec 08 00:33:12 Was going to ask you about when it usually starts/ends but I found last years schedule, and flights are limited for same day anyhow, heh Dec 08 00:33:34 ya, not always easy Dec 08 00:33:38 I saw, working on my speakers bio real quick atm Dec 08 00:33:46 I need to as well. Dec 08 00:33:46 Doing jkrinder's talk since he can't make it, heh Dec 08 00:33:56 oh, got it. Dec 08 00:37:13 bbt Dec 08 00:43:35 Tartarus: yes Dec 08 00:44:11 ah Scale Dec 08 00:44:22 ka6sox: do we have booth there this time ? Dec 08 00:48:25 khem, do you want one? Dec 08 00:48:32 if so let me know now...and I will get it Dec 08 00:50:05 ka6sox: hmm not sure of commitments yet Dec 08 00:50:56 okay so how many others can you interest in helping? Dec 08 00:58:36 ka6sox: oh i meant not booths at scale but others Dec 08 00:58:43 I might not be able to make it to scale Dec 08 01:00:18 okay, you let me know what you want to do (or other) please. **** ENDING LOGGING AT Thu Dec 08 02:59:57 2011