**** BEGIN LOGGING AT Mon Feb 08 02:59:57 2010 Feb 08 03:04:35 Kyoron: still here? Feb 08 03:06:50 Kyoron: I might be able to give you a hand if you ping me while we're bother around Feb 08 03:07:06 Kyoron: er, both... freudian slip eh? ;-) Feb 08 03:07:42 cool Feb 08 03:08:04 Still had no success Feb 08 03:08:47 (tyhis is in the process of building the helloworld tutorial, Im guessing it's building the crosscompiler or something related) Feb 08 03:14:08 Kyoron: So the "-native" there does indeed mean its the process of setting up cross-compilation Feb 08 03:14:19 Kyoron: You're on x86, right? Feb 08 03:14:51 a pentium 4, so I suppose so Feb 08 03:15:28 Kyoron: Has it already built pkgconfig-native? (you can check in /home/mavstar/oe/tmp/work/i686-linux/pkgconfig-native-0.24-r7.1 or something like that) Feb 08 03:15:41 hang on Feb 08 03:16:28 there's no such directory in there Feb 08 03:16:53 would that be the problem? Feb 08 03:16:57 Kyoron: Is there any pkgconfig-* directory there? Feb 08 03:17:09 Kyoron: Well PKG_CHECK_MODULES is a macro defined by pkgconfig Feb 08 03:17:20 I see Feb 08 03:17:22 Kyoron: So you need a native pkgconfig built before you can build glib Feb 08 03:17:25 no pkg* Feb 08 03:17:57 Kyoron: Just so you're learning how I'm thinking about hese problems.... I'm looking at org.openembedded.org/recipes/pkgconfig/pkgconfig-native* next Feb 08 03:18:13 Kyoron: Checking how/if that recipes requests pkgconfig to be built first Feb 08 03:18:47 Kyoron: er, make that glib-native Feb 08 03:19:07 hm I didn't think in thet direction before Feb 08 03:19:23 since I assume oe would automagically take care of dependencies :/ Feb 08 03:20:50 Kyoron: Sometimes a package's dependency chain isn't complete Feb 08 03:21:05 Kyoron: It worked in other contexts because SO MANY packages request pkg-config Feb 08 03:21:13 Kyoron: This might not be the problem Feb 08 03:21:17 ah, I see Feb 08 03:21:36 Kyoron: But I am noticing glib-2.0-native_2.22.1.bb doesn't directly DEPEND on pkgconfig-native Feb 08 03:21:43 Kyoron: So lets run an experiment on your computer Feb 08 03:21:49 sure Feb 08 03:22:10 Kyoron: edit glib-2.0-native_2.22.1.bb Feb 08 03:23:03 Kyoron: Change DEPENDS = "gettext-native gtk-doc-native" to DEPENDS = "gettext-native gtk-doc-native pkgconfig-native" Feb 08 03:23:03 add pkgconfig-native to the dependencies or something like that? Feb 08 03:23:07 yup Feb 08 03:23:20 Then go back to your build dir, and run the bitbake command again Feb 08 03:24:10 let's see now Feb 08 03:26:19 bleh, edited the wrong file Feb 08 03:33:31 ....geh, no deal Feb 08 03:33:45 it doesn't seem to even try compiling pkgconfig Feb 08 03:35:26 I might try compiling the gumstix bootloader since I had successfully built that one once Feb 08 03:35:33 (before the hard drive dies) Feb 08 03:35:49 thoughts? Feb 08 03:42:22 ....and the first thing in the bootloader compilation process is compiling pkgconfig. Doh. Feb 08 03:54:30 Thanks for your help sethn! Feb 08 03:56:17 Kyoron: did it work? Feb 08 03:56:26 Kyoron: Sorry, went to buy an SD card before everything closed Feb 08 03:56:34 lol no worries Feb 08 03:56:51 the edit the file method didnt so I tried compiling x-load Feb 08 03:57:10 that installed pkgconfig Feb 08 03:57:22 which results in glib behaving again Feb 08 03:57:51 (something else breaks, but I dont really worry about it atm) Feb 08 03:58:18 Kyoron: weird, I'm surprised the file didn't cut it, but at least you're on your way Feb 08 03:58:43 I'll just compile one of the standard packages and then mess with helloworld again Feb 08 03:58:47 Kyoron: You can also just do "bitbake pkgconfig-native" if you run into something like this again and don't want to try tweaking the files Feb 08 03:58:49 * sethn nods Feb 08 03:59:00 cool Feb 08 03:59:21 so bitbake automagically detects if something is already compiled? Feb 08 03:59:29 that's awesome Feb 08 06:04:02 morning everyone Feb 08 08:31:04 good morning! Feb 08 08:33:49 morning Feb 08 08:50:51 hi all Feb 08 08:54:12 morning Feb 08 08:56:33 good morning Feb 08 09:10:00 03Steffen Sledz  07org.openembedded.dev * r958e674180 10openembedded.git/recipes/subversion/subversion_1.6.5.bb: Feb 08 09:10:00 subversion-1.6.5: missing dependency to sqlite3 added Feb 08 09:10:00 Signed-off-by: Steffen Sledz Feb 08 09:11:07 03Koen Kooi  07org.openembedded.dev * rdac96029c4 10openembedded.git/recipes/mtd/ (4 files): Feb 08 09:11:07 mtd-utils(-native): add v1.3.1 Feb 08 09:11:07 * also convert mtd-utils(-native) to new-style staging Feb 08 09:11:07 * old-style ubifs commands have been removed in v1.3.1 Feb 08 09:11:08 03Graeme Gregory  07org.openembedded.dev * r4e6d406d43 10openembedded.git/: Merge branch 'org.openembedded.dev' of git+ssh://git.openembedded.org/openembedded into org.openembedded.dev Feb 08 09:25:57 hi Feb 08 09:26:35 hi woglinde Feb 08 09:28:04 hi marco was your trip home well? Feb 08 09:30:41 woglinde: fine thx and you ? Feb 08 09:37:42 yeah nice flight back to cold berlin Feb 08 09:37:46 I hate the snow Feb 08 09:37:54 last to long Feb 08 09:40:15 he mickeyl :) Feb 08 09:58:48 hi, meta-toolchain fails to build for me http://tinderbox.openembedded.net/packages/467410/ Feb 08 10:00:54 ao2 hm strange error Feb 08 10:01:47 yep, the build was done after wiping out tmp/, FYI Feb 08 10:02:19 with "was done" I mean, _launched_, not completed successfully, sorry Feb 08 10:02:30 tmp or oetmp? Feb 08 10:03:03 woglinde, OE tmp. Feb 08 10:05:50 hm sorry Feb 08 10:11:29 03Klaus Kurzmann  07org.openembedded.dev * r344932973d 10openembedded.git/conf/distro/include/sane-srcrevs.inc: Feb 08 10:11:29 sane-srcrevs.inc: bump rev for pyphonelog Feb 08 10:11:29 to a revision which should build again Feb 08 10:11:29 Signed-off-by: Klaus Kurzmann Feb 08 10:18:02 (backreading) morning mickey|office Feb 08 10:18:45 mickey|office: how was fosdem, was in your first talk yesterday, but had to move to another talk and didn't manage to catch you later :-( sorry about that Feb 08 10:20:30 hi effem Feb 08 10:21:37 hi woglinde, all Feb 08 10:22:11 * eFfeM is already for quite a while in-da-house: (07:03:50 AM) eFfeM: morning everyone Feb 08 10:22:13 (ouch) Feb 08 10:22:55 btw enjoyed fosdem, made a few pics of our table will try to upload them somewhere tonight Feb 08 10:23:22 if anyone else has piccies please drop them somewhere too Feb 08 10:31:29 hi eFfeM Feb 08 10:32:00 hi ant Feb 08 10:32:32 eFfeM: hi, no problem, 2nd talk was well received, the demo (interactively calling into the middleware via dbus) got them sold ;) Feb 08 10:33:33 Tartarus: your patch seems have fixed the " install: cannot stat `arch/arm/boot/zImage': No such file or directory" issue. Thx Feb 08 10:34:03 eFfeM: I can finally report progresses wrt packaged-staging Feb 08 10:34:32 mickeyl how was the workshop? Feb 08 10:34:50 eFfeM: at least the 3 images are built and even the fourth one (the initramfs) does not error out anymore Feb 08 10:34:59 hi cbrake Feb 08 10:36:20 mickey|office: good morning Feb 08 10:36:27 he pb Feb 08 10:37:06 hi woglinde Feb 08 10:37:09 good morning pb_ Feb 08 10:37:23 hi booxter Feb 08 10:37:34 eFfeM: still this "...has no architecture specified, defaulting to i686-linux" for some packages, though. Scary... Feb 08 10:39:33 03Robert Schuster  07org.openembedded.dev * r0feaefef7b 10openembedded.git/recipes/swt/ (6 files): Feb 08 10:39:33 swt-gtk.inc: Properly give OE's LDFLAGS to makefile. Feb 08 10:39:33 swt3.3-gtk: Increased PR. Feb 08 10:39:33 swt3.3-gtk-hildon: Dito. Feb 08 10:39:33 swt3.4-gtk: Dito. Feb 08 10:39:33 swt3.4-gtk-hildon: Dito. Feb 08 10:41:04 eFfeM: and new findings too! At least 3 (native) packages are found but are 'invalid' so these get rebuilt. They are gettext, glib-2.0_2.24 and libxml-parser-perl. Feb 08 10:42:16 morning all Feb 08 10:42:51 ant_work: nice, did you have to make additional changes? Feb 08 10:43:12 no, but I didn't yet test the sanity of images Feb 08 10:43:33 this no arch specified is indeed odd, I checked the package and the control file does have an Architecture: line. Feb 08 10:43:57 yes, and this is like in the file suffix...686 Feb 08 10:44:06 At one point i did some instrumentation of opkg-native (that is the one spitting out the message) but then I could not reproduce it any more Feb 08 10:44:29 no idea if 686 is ok the file name also contains the actual arg Feb 08 10:44:44 hi rp Feb 08 10:45:05 ant_work: eg ./angstromglibc/staging-strace-armv7a-angstrom-linux-gnueabi_4.5.14-r9_i686-linux.ipk Feb 08 10:45:27 guess the staging package is to be unpaced on 686 and is for armv7a Feb 08 10:45:32 yes, this is definetely armv7a Feb 08 10:45:35 staging packages contain .ipk's Feb 08 10:45:54 whose control file should specify the arch Feb 08 10:46:03 so it would make sense to say the arch is i686 in the staging ipk and armv7a in the contained ipk Feb 08 10:46:10 both have their own control file Feb 08 10:46:20 I can't believe opkg distinguoshes the buildhost? Why? It could be a web feed Feb 08 10:46:44 I mean for packages built to run on target Feb 08 10:47:21 but hey, I avoided as possible to dig inside ipkg/opkg meanders Feb 08 10:47:54 I ended up building my own images with preinstalled packages :D Feb 08 10:48:32 ~ping rp Feb 08 10:48:42 pong rp Feb 08 10:48:54 eFfeM: anyway there is some discrepancy between the packages in /ipk and those in /pstage Feb 08 10:49:32 really I'm not the opkg man....I'm too biased (portage/emerge) Feb 08 10:50:10 ant_work: time permitting I can dig into it but I first need to make sure I get the problem again Feb 08 10:50:24 if you have a recipe for that, please let me know Feb 08 10:52:10 for now, if you have time, just rebuild from stage console-image Feb 08 10:53:28 check the log and see what about gettext glib-2.0_2.24 and libxml-parser-perl Feb 08 10:53:56 ..or just parse ./classes and grep for ' but invalid' Feb 08 11:00:39 hi rp Feb 08 11:07:49 ant_work: will try Feb 08 11:10:14 ok, thx, I'll do more tests this evening Feb 08 11:12:11 ant_work: wrt the invalid packages, you get that message if the package is out of date if I understand the class code properly Feb 08 11:12:56 at least glib is changed recently, packaged staging is conservative and in doubt it will not recover from pstage but instead regenerate Feb 08 11:18:38 eFfeM: I rebuilt the images after git pull... Feb 08 11:18:51 only then I rebuilt from pstage Feb 08 11:19:10 I saw glib-2.0 was rebuilding (XorA commit) Feb 08 11:19:19 so should have been fresh Feb 08 11:19:43 ok will check Feb 08 11:31:43 * XorA denies it Feb 08 11:33:12 morning all Feb 08 11:33:34 ah re rp Feb 08 11:33:43 rp we have a question about new staging Feb 08 11:33:51 woglinde: go for it Feb 08 11:35:11 rp hm with swt we have jar's and native libraries Feb 08 11:35:27 and we want to install the native-libraries in the packages only Feb 08 11:35:34 not in stagging Feb 08 11:35:41 how is this achieved Feb 08 11:36:03 woglinde: why? Feb 08 11:36:05 why do you not want to install them in staging? Feb 08 11:36:08 without legacy staging of courese Feb 08 11:36:17 woglinde: can you also define native? Feb 08 11:36:18 the consume space Feb 08 11:36:25 they Feb 08 11:36:26 hms Feb 08 11:36:34 my english gets worsers and worser Feb 08 11:36:56 yeah easiest options is to install them Feb 08 11:36:56 is it enough space to be a real issue? Feb 08 11:37:00 but maybe there are cases Feb 08 11:37:12 unless they are really vast it is hard to imagine that the space will be significant compared to the rest of the build tree. Feb 08 11:37:59 woglinde: I assume in this case "native" really means "target" since native.bbclass doesn't generate packages Feb 08 11:38:00 I really don't think it is a good idea to introduce artificial differences between staging and the shipped packages. Feb 08 11:38:23 rp hm not native Feb 08 11:38:44 in this sense Feb 08 11:38:44 I agree with pb_ in general, however there is a way to make them different Feb 08 11:38:59 native in java sense Feb 08 11:39:02 Have a look in the tree for "preprocess" functions Feb 08 11:39:11 RP: heh, funnily enough I have just been experimenting with having native.bbclass generate packages. Feb 08 11:39:17 but its okay we will install them Feb 08 11:39:28 These can make the install and staging contents different Feb 08 11:39:39 swt natvie libs are only used at runtime Feb 08 11:39:43 we do already have them differ as we don't stage man pages for example Feb 08 11:39:59 pb_: Dare I ask why or don't I want to know? ;-) Feb 08 11:40:09 sorry for confusion Feb 08 11:40:21 RP: basically because I want to start populating staging from the actual packages rather than generating it in parallel. Feb 08 11:40:25 pb_: Dependency loops would be your main enemy I'd guess Feb 08 11:40:36 and, obviously, in order to do that for native packages you need to have packages created in the first place :-) Feb 08 11:41:06 pb_: We do generate staging from packages? Feb 08 11:41:43 pb_: We cheat for package management and use an old version of opkg written in python ;-) Feb 08 11:42:13 (stagemanager-native) Feb 08 11:44:48 RP: yeah, I don't particularly like the way it is done at the moment (with dedicated "staging packages") though. Feb 08 11:47:01 pb_: I know. If you want multiple package backends its kind of inevitable though Feb 08 11:48:05 RP: on that topic, can you remind me whether there is a good reason for having the "cross" directory separate from the rest of staging? Feb 08 11:48:37 pb_: You'd suggest the native sysroot I guess? Feb 08 11:48:38 it seems to remove a lot of complicated (and bogus-seeming) stuff in cross.bbclass and the associated recipes if we can just allow the toolchain to go into staging along with everything else. Feb 08 11:48:42 RP: right, exactly Feb 08 11:49:04 I ran a build like that yesterday and it seemed to work fine, but presumably there was some reason for creating cross/ in the first place. Feb 08 11:49:41 pb_: I think the problem is largely historic but the layout of the cross stuff is a bit different Feb 08 11:49:58 yeah, it is a bit different, but it doesn't seem to be different for any useful purpose. Feb 08 11:50:16 pb_: With other gcc and other tools it was useful Feb 08 11:50:28 pb_: Now, I can see a case for merging them Feb 08 11:50:36 okay Feb 08 11:50:46 hoi zecke Feb 08 11:50:47 pb_: I've slowly been moving that way ;-) Feb 08 11:50:48 I will see if I can separate my patchset for that from the rest of the changes that I have in my tree. Feb 08 11:50:55 woglinde: hey, how was your first fosdem? Feb 08 11:51:00 iirc, the changes to eliminate cross/ are fairly straightforward Feb 08 11:51:18 pb_: The situation is tons better than it was in the the gcc and binutils recipes are cleaner Feb 08 11:51:18 zecke okay Feb 08 11:51:23 RP: right Feb 08 11:51:27 was like the earlier linuxdays Feb 08 11:51:28 and actually use the cross code Feb 08 11:51:43 RP: though, I discovered yesterday that there is still a certain amount of craziness in binutils, heh Feb 08 11:51:57 pb_: Check poky, its still ahead in changes :( Feb 08 11:52:25 pb_: There is also a work in progress tree in OE somewhere from me which has some poky toolchain stuff I was planning to push Feb 08 11:52:34 Sadly the tree will be bitrotten now :/ Feb 08 11:52:44 hm hm we have a touchbook now Feb 08 11:53:15 pb_: http://git.openembedded.org/cgit.cgi/openembedded/log/?h=rpurdie/work-in-progress Feb 08 11:54:13 pb_: Some small binutils bits in there along with gcc Feb 08 11:56:00 pb_: One further question for you - what to do with the STAGING_BINDIR_CROSS ? Feb 08 11:56:18 pb_: Should that be in the native sysroot or the target one? Feb 08 11:57:08 eFfeM: ping Feb 08 12:00:50 zecke: pong Feb 08 12:01:54 eFfeM: thanks for the reply to "tejas" Feb 08 12:02:24 ant_work: did a rebuild from pstage over lunch and I indeed have the three invalid packages; will dive into it tonight Feb 08 12:03:33 zecke: np, actually recently got a little bit fed up by people sending emails without proper description and without explanation, or with obvious solutions Feb 08 12:03:58 like for tejas where it was obviously a network issue (and if you can't see that probably oe is not for you Feb 08 12:04:14 not that i do not want to help people, but there are limits Feb 08 12:06:58 eFfeM: yeah. I'm getting upset by these corporations... They should not filter what gets into their network, but what is leaving it. Feb 08 12:07:29 zecke: actually had the idea he was a student Feb 08 12:07:51 picus.in seems to be a company Feb 08 12:08:51 obviously for indian's there.. language is not a problem... they are just incredible lazy. Feb 08 12:08:59 yeah just googled it: http://www.picus.in/ Feb 08 12:09:19 they specialise in dsp sw :-) read the guys' totem messages Feb 08 12:09:42 eFfeM: so someone is paying them $$$ to get OE running on a platform. Maybe even outsourced from Europe because India is cheaper Feb 08 12:09:56 btw see a lot of those email messages on beagleboard and hawkboard ML: Feb 08 12:10:01 hey, I have a problem help me Feb 08 12:10:04 now Feb 08 12:10:41 eFfeM: by helping, you are killing jobs your own job. I'm at a stage where I help friends and FOSS Feb 08 12:10:43 zecke: could well be, and from his email I doubt if he has a clue what he's doing Feb 08 12:11:11 zecke: agree Feb 08 12:11:35 I wonder if I should create a Django app... Companies Hall of Shame.. Feb 08 12:12:09 actually i have no problem giving some help to someone who is doing his homework and needs some guidance, but I assume that people try first Feb 08 12:12:27 * eFfeM got quite some advice from Koen when I started with oe several years ago Feb 08 12:13:03 zecke, hall of shame :-) guess they will also end up in the GPL hall of shame as they do not understand that part either Feb 08 12:13:52 * eFfeM has a lot of experience with Indians, for better and for worse (there are definitely very good and clever guys there too; and for some reason the bad ones didn't really last long in my projects) Feb 08 12:15:49 ant_work: the fresh build from staging does not give architecture warnings (beagleboard console-image) Feb 08 12:16:03 if you have an idea on how t recreate them drop a msg Feb 08 12:16:21 otherwise will look into it tonight, need to do other thigns now so afk for next hour or so Feb 08 12:16:22 eFfeM: try to rebuild from pstage, from the same rootfs created by first rebuild Feb 08 12:16:26 eFfeM: yeah. I know some incredible indian engineers... It is not avoidable. If you create a "Software Industry" you will have to have people that are not good... Feb 08 12:16:49 ant_work: did that Feb 08 12:17:14 oh, on second run I saw the infamous lines... Feb 08 12:17:22 zecke: true and informatics is considered to be a good paying career so it attracts lots of untalented people Feb 08 12:17:26 ant_work: define second run Feb 08 12:17:49 first rebuild from pstage, remove tmp (keep pstage), rebuild Feb 08 12:18:11 will try later, really gone now Feb 08 12:18:19 the 3 invalid were still there Feb 08 12:18:36 but now, though the warnings, image is created Feb 08 12:18:44 that's a big progres :) Feb 08 12:19:31 eFfeM: What I have learned in India. Being unfriendly can be helpful to be left alone. FOSS Communities were too helpful to deal with non thinking crowd, we need to get rid of the "free thinking support"... Feb 08 12:20:40 eFfeM: the stopper was the " install: cannot stat `arch/arm/boot/zImage'. This has been finally fixed (by Tartarus). Feb 08 12:24:30 RP: thanks, I'll take a look Feb 08 12:27:08 RP: as for STAGING_BINDIR_CROSS, I'm not entirely clear on what exactly that variable is used for. There don't seem to be many references to it apart from binconfig. Feb 08 12:29:30 zecke: fully agree Feb 08 12:29:58 ant_work: the cannot stat is because do_deploy is executed for kernel which should not be the case Feb 08 12:30:06 could be a timestamp issue Feb 08 12:30:16 eFfeM: it has disappeared now Feb 08 12:30:22 haven't seen tartarus patch Feb 08 12:30:32 btw the recipe had empty do_stage and do_istall Feb 08 12:30:45 so it wasn't recipe fault apparently Feb 08 12:32:22 it was: kernel.bbclass: Fix pstaging do_deploy. Feb 08 12:33:05 http://cgit.openembedded.org/cgit.cgi/openembedded/commit/?id=8dc84badb1d772f5953492c4022c1f644c4fe278 Feb 08 12:33:59 ant_work: ah ok didn't see that one Feb 08 12:41:37 ant_work: managed to reproduce the problem; rm tmp; bitbake console-image; bitbake -cclean virtual/kernel;bitbake virtual/kernel Feb 08 12:41:49 will see if I can find something Feb 08 12:52:15 good morning Feb 08 12:53:08 florian robert worried Feb 08 12:53:48 hey dudes, now your all back anyone going to write a report on FOSDEM Feb 08 12:54:26 time Feb 08 12:55:37 yes e should have something like this Feb 08 13:01:34 hm we should update qemu-natvie Feb 08 13:03:50 heh picus.in are hiring :-D Feb 08 13:04:27 yeah, they evidently need someone :) Feb 08 13:04:49 pb_: well done. incredible how relaxed you can deal with that. were you forced to ever work in tech support? Feb 08 13:16:14 morning Feb 08 13:16:40 hi hrw Feb 08 13:17:00 florian, hrw, wb, had a good trip back? Feb 08 13:17:55 XorA: I don't think they can afford either of us Feb 08 13:18:02 eFfeM: was fine Feb 08 13:20:12 The phrase "please guide me" is over used Feb 08 13:24:30 crofton I will pay for guide me Feb 08 13:24:35 that would be good Feb 08 13:24:44 hi btw. Feb 08 13:26:07 hi Feb 08 13:26:08 yeah Feb 08 13:26:52 I wish someone would guide me to fix my gobject-introspection recipe :-D Feb 08 13:28:06 heh Feb 08 13:34:23 guide me Crofton I demand! Feb 08 13:35:29 picus is pussy in czech :p Feb 08 13:36:05 ynezz: now that made me laugh Feb 08 13:36:30 ynezz *g* Feb 08 13:47:22 eFfeM: yep... Feb 08 13:47:57 florian hm query? Feb 08 13:58:23 pb_: Its used to place binaries generated by target packages which are safe to run on the build (native) system Feb 08 13:58:40 pb_: binconfig scripts are one example, there are others Feb 08 13:59:18 pb_: It presents an interesting dilemma for the staging packages as in thery target packages should be 32/64 bit agnostic for example Feb 08 13:59:30 s/thery/theory/ Feb 08 13:59:54 and STAGING_BINDIR_CROSS "binaries" can currently be actual binaries Feb 08 14:00:30 RP: ah, right, I see. so yeah, I would say that those belong in the native sysroot. If they are intended to run on the build host but they are in some way specific to the target system, then they should go in staging/BUILD_SYS/TARGET_SYS/ or some such. Feb 08 14:00:39 the latter is what binutils naturally does with things like the target "as" Feb 08 14:00:53 er, cross "as" that is Feb 08 14:02:35 pb_: Currently we put them in BUILD_SYS/TARGET_SYS/ in the native sysroot as you mention Feb 08 14:02:55 pb_: The problem is the package is then build system specific Feb 08 14:03:17 and touches two different sysroots :/ Feb 08 14:03:30 yeah, I see what you mean. Feb 08 14:03:44 how many packages are there that actually have this issue? It is tempting to say that we should just try to eliminate them. Feb 08 14:04:10 pb_: 50 in my usual builds of 600 recipes maybe? Feb 08 14:04:15 Just a guess mind... Feb 08 14:04:23 and of those 50, do you know how many are actual binaries rather than binconfig scripts? Feb 08 14:04:38 we only have a small number of actual binaries I think Feb 08 14:04:38 I guess I should run a build and find out for myself. Feb 08 14:05:03 Most are scripts, thankfully Feb 08 14:05:35 Ripping out some of the configure scripts would actually be nice Feb 08 14:05:40 er, binconfig scripts Feb 08 14:05:52 That was a Freudian slip :) Feb 08 14:05:53 for the ones that are really binaries, I suppose the "right" answer would be to make a separate foo-utils-native package to build those binaries. Feb 08 14:06:07 pb_: Probably, yes Feb 08 14:06:20 if it's only a small number of packages then that might not be too awful to arrange. Feb 08 14:06:40 for the binconfig bits, those are a bit less toxic to start with but in theory most/all of them could be replaced with a suitable pkg-config arrangement. Feb 08 14:06:52 maybe even in an automated way, I suppose Feb 08 14:07:02 pb_: Most of the binconfig providers also have .pc files now and we'd just have to make sure all the users were happy with .pc files Feb 08 14:07:28 luckilly PKG_CHECK_MODULES is real easy to add to configure.in Feb 08 14:07:43 XorA: right. and much less error prone Feb 08 14:08:15 * RP has tested the latest pkgconfig from git and made sure the next release will support sysroots correctly Feb 08 14:08:16 RP: right, that sounds like it should be easy enough. and, if that proves intractable, I think one could write a little stub script which translates "foo-config --libs" into "pkg-config --libs foo" easily enough. Feb 08 14:08:41 pb_: Its even something we could push at upstream Feb 08 14:08:53 yeah Feb 08 14:09:04 * pb_ -> meeting Feb 08 14:09:05 bbl Feb 08 14:13:16 ehm..sorry for the strange question: is it possible to run qemu on an arm machine and emulate x86, isn't? Feb 08 14:13:37 yes Feb 08 14:14:30 http://marcin.juszkiewicz.com.pl/2010/02/08/fosdem-x/ Feb 08 14:16:06 XorA: would you imagine testing the boot of some x86 BIOS images on arm? Feb 08 14:16:33 ant_work: qemu uses bochs bios Feb 08 14:16:54 hrw: nice post Feb 08 14:17:22 kergoth: thx Feb 08 14:17:53 thanks hrw Feb 08 14:17:59 minix 3 looks like it could be fun to play with, just for fun Feb 08 14:18:09 i don't know that i'd actually use it for anything, but.. Feb 08 14:18:44 pushed few languages fixes Feb 08 14:19:10 kergoth: hehe, is this not a bit late? Feb 08 14:19:27 kergoth: I am thinking about fetching usb version just to check it on my machine. will probably nearly not work but worth check Feb 08 14:19:46 i grabbed the iso, figured I'd see if it boots in vmware fusion Feb 08 14:20:07 actually, should poke around its kernel, probably easier to grasp in its entirety than the Linux one Feb 08 14:20:08 heh Feb 08 14:28:38 hrw: thx. Do you think one could test own bios images? Feb 08 14:29:48 rather not Feb 08 14:31:55 hrw: you shouldn't be worried about me knowing you better as you know me :) Feb 08 14:35:51 toi: ;D Feb 08 14:36:45 You can not really know me because I'm not an OE developer. Feb 08 14:37:30 But I follow OE already from the days of oemae/oebuild, so thats why I always (try to) make the joke Feb 08 14:38:08 Real life and other projects keep me away from doing embedded stuff, but one day... Feb 08 14:38:17 mkey Feb 08 14:38:26 So no worries :) Feb 08 14:38:46 But I will buy you a beer next year to make up! Feb 08 14:49:02 03Thomas Zimmermann  07org.openembedded.dev * rb165d5c23e 10openembedded.git/recipes/evopedia/evopedia_git.bb: Feb 08 14:49:02 evopedia: new recipe Feb 08 14:49:02 * evopedia is an offline wikipedia viewer Feb 08 14:49:02 Signed-off-by: Klaus Kurzmann Feb 08 14:49:23 hmm, oe-bakery looks interesting Feb 08 15:00:39 * Laibsch sends a friendly Hello to toi Feb 08 15:01:11 Hi Laibsch :) Feb 08 15:01:51 Possibly we have met, but I can't put a face on the name atm, too much people in so little time... Feb 08 15:02:24 Brain is still much in recovery mode for now. Feb 08 15:08:06 the amount of alcohols consumed at FOSDEM normally effects memories Feb 08 15:09:53 XorA: Only had 1 beer during the whole event, so that's not the problem, lack of sleep is... Feb 08 15:10:41 And manning the info desk for almost 2 whole days drains a lot of energy. But is totally worth every second of it :) Feb 08 15:11:37 But the beer event was indeed again enormous, seems there where about 1100 people (countesd by the security). Feb 08 15:11:50 heh Feb 08 15:12:13 * XorA prefers the other Delirium bar Feb 08 15:12:23 good name Feb 08 15:12:54 toi: wallet Feb 08 15:13:19 wallet? Feb 08 15:14:23 no alchool either(I prefer to see things cleanly,and it sometimes gives me headaches) but lack of sleep didn't help Feb 08 15:15:09 there is pictures of me recovering from rum last year :-D Feb 08 15:15:13 lol Feb 08 15:19:25 http://www.flickr.com/photos/32615155@N00/3260848665/ Feb 08 15:20:39 lol Feb 08 15:21:05 lol indeed. Feb 08 15:21:24 Don't worry, you're not the only one :) Feb 08 15:22:14 People arrive friday to not miss the saturday morning, but are to late anyway because of the beer event :) Feb 08 15:22:28 But it's more fun for sure. Feb 08 15:22:33 lol ok Feb 08 15:25:00 I was physically on time Feb 08 15:36:43 :D Feb 08 16:02:12 GNUtoo: :-D Feb 08 16:20:38 g.m. Feb 08 16:21:13 thx to FOSDEM ! Feb 08 16:22:55 hi recalcati Feb 08 16:23:33 hi florian. I'm back to real world Feb 08 16:24:18 * florian too... trying to play with a new toy and making customers happy at the same time Feb 08 16:24:48 ** right, I'm trying to do impossible things Feb 08 16:27:53 recalcati: hi, was your trip home well? Feb 08 16:28:21 recalcati, impossible things? such as cross-compile openoffice? Feb 08 16:28:33 gnutoo hm Feb 08 16:28:36 lol Feb 08 16:28:40 touchbook has openoffice 3.0 Feb 08 16:28:45 yes I know Feb 08 16:28:52 I also know how they built it Feb 08 16:28:55 somehow compiled with gentoo Feb 08 16:28:59 qemu...+ chroot Feb 08 16:28:59 hm oh? Feb 08 16:29:02 lol Feb 08 16:29:39 1 week of compilation Feb 08 16:29:44 lol Feb 08 16:30:02 I bet if I do it this way...maybe I'll have to compile for one month because of slow build computer Feb 08 16:31:03 woglinde, anyway I decided against buying touchbook because some people(tuxbrain) told me that it was not solid/good quality product Feb 08 16:32:24 RP: fwiw, I pushed the bits that I have been playing with to http://git.openembedded.org/cgit.cgi/openembedded/log/?h=pb/toolchain-desuck Feb 08 16:32:34 but I think I still want openoffice under my eeepc701 Feb 08 16:32:34 gnutoo hm yes partly Feb 08 16:32:43 gnutoo we have one here now Feb 08 16:32:51 ok Feb 08 16:33:17 and it seem easy to accidentaly break? like when beeing in a travel bag and traveling? Feb 08 16:33:40 * pb_ meeting again now Feb 08 16:33:45 but I bet I'll find another arm netbook that permit to run angstrom Feb 08 16:34:14 mckoan: very well. two leffe blonde at airport!!! Feb 08 16:34:34 GNUtoo: as doing what I'm doing ... clear? Feb 08 16:35:07 mmm Feb 08 16:35:17 and also create a new develop in OE without knowing enough it Feb 08 16:36:37 ooh, toolchain-desuck, that sounds nice Feb 08 16:36:38 but doing something else in the same time Feb 08 16:38:00 ok Feb 08 16:41:29 recalcati: me too LOL Feb 08 16:42:17 recalcati: the smoothest flight I've ever done :-D Feb 08 16:45:03 03Klaus Kurzmann  07org.openembedded.dev * re69880e5c9 10openembedded.git/conf/distro/include/sane-srcrevs-fso.inc: Feb 08 16:45:03 sane-srcrevs-fso.inc: bump rev of libframeworkd-glib Feb 08 16:45:03 Signed-off-by: Klaus Kurzmann Feb 08 16:59:43 I slept perfectly ... and then I saw malpensa, the foggiest airport in the world Feb 08 17:08:33 have a nice rest of the day Feb 08 17:17:29 jo khem Feb 08 17:17:57 pb_: Interesting. That actually packages the toolchain bits ok? Feb 08 17:19:49 wtf.. screen -r doesn't work to join the screen session spawned by devshell under cygwin Feb 08 17:19:52 does nothing Feb 08 17:19:53 weird. Feb 08 17:22:12 hi woglinde Feb 08 17:30:25 woglinde, hi Feb 08 17:30:35 hi blinder Feb 08 17:39:19 * hrw -> off Feb 08 18:01:33 doesn't bitbake have a facility to error out on non-applied patches? say foo-0.8.15/barf.patch isn't applied but in the tree, barf? I'd guess that this could (potentially, didn't try) cut off 10% of the whole repo, no? Feb 08 18:02:34 s/repo/oe repo/ Feb 08 18:20:38 blindvt: uh, bitbake doesn't magically know about patches that aren't listed in SRC_URI Feb 08 18:21:22 blindvt: and sometimes overrides apply patches selectively from a dir too Feb 08 18:21:37 blindvt: I know you want to get rid of unused patches :) Feb 08 18:22:11 * khem is using ssl connection to freenode now Feb 08 18:22:34 khem: ssl? how? Feb 08 18:23:23 zecke: port 7000 Feb 08 18:23:29 they mentioned it in the blog posts about the new ircd Feb 08 18:23:37 * kergoth is connected that way now too Feb 08 18:26:47 yes or port 7070 Feb 08 18:27:18 anybody who uses irssi I can help :) Feb 08 18:27:55 kergoth, i was thinking about a post-parser. Parse .bb and barf on anything not in SRC_URI Feb 08 18:28:04 but that doesn't make any sense. Feb 08 18:28:08 FILESPATH includes any number of locations Feb 08 18:28:13 some of which apply to multiple recipes Feb 08 18:28:28 you'd have to parse every recipe, gather a list of every patch everything refers to, then gather a list of every patch in the reposiitory and compare the two Feb 08 18:28:28 kergoth, and some of which are never applied Feb 08 18:28:36 possible, yes, but its not a per recipe thing Feb 08 18:28:41 yes, no shit Feb 08 18:28:42 indeed Feb 08 18:28:44 blindvt: its as complex as gcc's unused variable warning trust me Feb 08 18:29:25 you're right, I'm sure it is worthwhile, just not entirely trivial Feb 08 18:29:49 khem, i've written a use-counter for gcc decls, and it wasn't _that_ hard ;) Feb 08 18:29:54 also, there are patches which aren't named .diff/.patch, you'd likely have to see if 'file' can identify them Feb 08 18:30:49 blindvt: decl is different unused/unintialized variables is different 10 out of 100 times gcc is wrongly warning about somethinhg Feb 08 18:30:53 kergoth, i understand, sure. I just think that there is some cruft accumulated over time, and it really hurts anybody, not only, let's say modem-users Feb 08 18:31:03 khem, see set but not used PR Feb 08 18:31:06 it doesn't hurt anyone. Feb 08 18:31:14 a clone will still pull down that data Feb 08 18:31:21 due to the history in the git repository Feb 08 18:31:26 the only difference will be local space in the checkout Feb 08 18:31:26 yeah true Feb 08 18:31:29 trivial Feb 08 18:31:52 kergoth, it hurts folks who are bandwidth limited (and yes, only clone but particularly hard on that one) Feb 08 18:31:58 no Feb 08 18:31:59 RP: mostly, yeah. the toolchain bits seem to come out with the wrong PACKAGE_ARCH, for reasons I haven't yet fully determined, and I haven't exactly tested the packages in great detail, but they seem to be basically correct. Feb 08 18:32:04 you can't reduce the amount of shit a clone pulls Feb 08 18:32:11 rp Feb 08 18:32:14 removing it from the head branch doesn't remove the objects from the repository Feb 08 18:32:19 so it DOES NOT benefit modem users Feb 08 18:32:24 it has zero effect Feb 08 18:32:26 RP: the resulting sysroot tree does seem to work for compiling things against, at least. Feb 08 18:32:58 pb__: it is about do_install and do_stage integration ? Feb 08 18:33:16 RP: oh, I know there is one outstanding issue with things like libgcc1, which don't currently get packaged correctly with those changes. per what I wrote on the mailing list the other day, I think the right way to deal with that is to have a separate recipe which builds (just) the gcc runtime for the target. Feb 08 18:33:42 kergoth, for initial cloners it does make a difference if you clone like 659M or 10% less, but ok. Non-issue for well-connected core Feb 08 18:33:46 what? Feb 08 18:33:52 it will always be the same Feb 08 18:34:01 kergoth, --depth=1 Feb 08 18:34:19 thats a tiny, tiny portion of the userbase Feb 08 18:34:24 again, trivial Feb 08 18:34:30 blindvt: you get everything with a clone even once there now deleted files Feb 08 18:34:31 okok Feb 08 18:34:41 he's talking about shallow clones Feb 08 18:34:47 i don't think I've ever talked to anyone that's done one Feb 08 18:34:49 i certainly haven't Feb 08 18:35:00 oh --depth=` Feb 08 18:35:08 hmmm interesting Feb 08 18:36:22 khem, kergoth, i back out on the bandwidth and disk-footprint. Not relevant ATM Feb 08 18:36:25 like i said before, I'm sure its worthwhile, but i don't think we should overstate the benefits, either. bandwidth and disk are both cheap, and it only reduces the bandwidth for shallow cloners. Feb 08 18:38:16 let's see if RP or somebody else applies any of the two trivial or two "but, but.." patches to bb |) Feb 08 18:39:50 * kergoth fights cygwin some more Feb 08 18:41:03 kergoth, my sympathy ;) Feb 08 18:41:12 I'm clearly a glutton for punishment Feb 08 18:46:24 kergoth, in contrast. you're keeping the bridge alive which is as cumbersome as worthwhile. fore! Feb 08 18:46:49 heh. well, there's a definite need for windows support of some kind, so what the hell Feb 08 18:48:20 indeed, i suppose there is :) Feb 08 18:51:37 in a bbclass file is there a way to enable bb.debug for that function only ? Feb 08 18:52:20 When stable will be branched? Feb 08 18:52:35 otavio ask the TSC Feb 08 18:52:41 or change the bb.debug into something that will echo Feb 08 18:54:30 nevermind went for -D will weed out the junk Feb 08 18:57:12 khem: yeah Feb 08 19:02:04 khem, as you may have read, busybox restructure downloads yesterday. Would you (eventually) accept xz handling, updated busybox paths, md5sum, sha256 sums and toggle to .bz2 for busybox? Feb 08 19:02:23 khem, via ML, that is Feb 08 19:02:47 restructured even Feb 08 19:09:48 so tschau Feb 08 19:10:59 hrw|gone: i have tab completion for mdbus2 ! Feb 08 19:11:03 hrw|gone: you will love it Feb 08 19:11:19 took me the whole train ride from BRU to FRA Feb 08 19:13:53 btw.. ASSUME_PROVIDED.. is there a facility (that i manage to miss, apparently) that goes like "which foo || type -p foo || foo-native" with, perhaps, a minimum required version? Feb 08 19:14:21 no such facility exists. you'd also have to differentiate between the patched and unpatched natives Feb 08 19:14:25 would be nice, though Feb 08 19:15:25 i find myself in dependency loops concerned about git/{busybox,coreutils}/libtool/{xz,bunzip,...decompressors} and other heck like that which i didn't expect from something like oe 8) Feb 08 19:16:22 kergoth, mhm. i see Feb 08 19:20:44 kergoth, boils down to configure-like checks i fear. But get_assumed(package=None, version=None) would be a good start, imho Feb 08 19:21:54 that's why we avoided it from the beginning, didn't want to take on the whole 'running tests' thing the way autoconf does from a scope standpoint.. but it'd be nice Feb 08 19:23:13 * blindvt nods kergoth Feb 08 19:23:24 kergoth: yeah, you could imagine a script (perhaps even an autoconf-generated script) which would test your build host and output a suitable .conf file containing a bunch of ASSUME_PROVIDED lines. Feb 08 19:23:38 might be a neat project for someone Feb 08 19:24:04 * pb__ waits patiently for his 19:00 appointment to show up Feb 08 19:24:06 at least a rudimentary checker for versions (i.e. no runtime-tests) would be of tremendous help for me Feb 08 19:25:59 mickeyl: git url please Feb 08 19:29:49 bitbake mickeydbus2 Feb 08 19:29:51 ;) Feb 08 19:30:00 http://git.freesmartphone.org/?p=cornucopia.git;a=tree;f=tools/mdbus2;h=75294ec89c55a112f598eae18edfe3669230847f;hb=507a51ea045d0fd2ee717e501a19ac624798e951 Feb 08 19:30:28 Is it safe to switch to different git branch while building another one? Feb 08 19:30:28 some things still missing, but you can already enjoy Feb 08 19:30:38 mickeyl: th Feb 08 19:30:39 x Feb 08 19:31:54 ynezz: no Feb 08 19:32:19 ynezz, i wouldn't do it unless you're really sure that you don't change stuff under self Feb 08 19:32:35 recipes are parsed so what can happen? Feb 08 19:32:52 I mean, I'm building org.openembedded.dev Feb 08 19:32:57 * hrw|gone -> off Feb 08 19:33:00 ynezz, patches, new versions, classes changes. Put short.. alot Feb 08 19:33:04 git branch fix org.oe.dev Feb 08 19:33:08 git checkout fix Feb 08 19:33:27 vim something.bb; git commit... Feb 08 19:33:47 this should be safe, right? Feb 08 19:35:43 blindvt: ok, I understand what you mean Feb 08 19:51:25 RP__, all noticed another issue with packaged staging (ok ant_work did, but I am analysing it) Feb 08 19:52:21 Anyone around that's used the external-toolchain stuff? Feb 08 19:52:31 when restoring packages that have BBCLASSEXTEND="native" in the recipe, packaged staging complaind, with -D -D it says: Feb 08 19:52:55 DEBUG: Checking /home/frans/oe/tmp_angstrom/stamps/i686-linux/gettext-native-0.17-r5.do_fetch Feb 08 19:52:55 DEBUG: Result None Feb 08 19:52:55 NOTE: Staging package found but invalid for /home/frans/oe/openembedded/recipes/gettext/gettext_0.17.bb Feb 08 19:52:55 Done. Feb 08 19:53:30 anyone an idea? Feb 08 19:53:37 Kinda.. Feb 08 19:53:49 Tartarus: shoot :-) Feb 08 19:53:55 Well, thinking how to phrase it Feb 08 19:54:05 That error msg means that some stamp file was found, but not deemed OK Feb 08 19:54:33 That said, I'd swear it works here Feb 08 19:54:42 But I can't quickly check, got a buncha other builds going Feb 08 19:54:50 the NOTE line gives the name of the recipe but we are restoring a -native package Feb 08 19:55:08 Yeah Feb 08 19:55:14 print is for recipe used, not PN Feb 08 19:55:15 for "classic" native packages (without BBCLASSEXTEND) it works fine Feb 08 19:55:35 Does it work fine the second time? Feb 08 19:55:42 will try Feb 08 19:55:42 Or every time, does it decide to rebuild Feb 08 19:55:53 I'd imagine that changing to that, yes, you need to make a new cache Feb 08 19:55:57 Since that changes a few things around Feb 08 19:56:09 eFfeM1, compiling for eeepc701? Feb 08 19:56:17 GNUtoo: no this is for beagle Feb 08 19:56:20 ok Feb 08 19:56:26 ah indeed Feb 08 19:56:43 i686-linux not i686-angstrom-something Feb 08 19:58:34 Tartarus: trying to build a 2nd time, expect it to go ok as it has now rebuild the package and it is in the work/i686-linux dir Feb 08 20:00:20 yeah, then try a new just caches test Feb 08 20:00:22 Should be OK Feb 08 20:00:40 * Tartarus wonders if external-toolchain* really expects the user to modify PATH outside of OE... Feb 08 20:03:25 this is very odd. the cvs fetcher errors out saying gzip doesn't exist, from the tar.gz process run by bb.fetch.. yet a tar -czf worksf ine outside of bitbake, and even works fine in a devshell Feb 08 20:03:28 * kergoth scratches head Feb 08 20:03:33 time to compare environments, i guess Feb 08 20:03:48 kergoth: ubuntu? Feb 08 20:04:00 what do you mean with a new just caches? do you expect it to go ok now (after i rebuild a 2nd time ?) Feb 08 20:04:01 naw, still screwing around with cygwin. weird behavior, though Feb 08 20:04:05 Ah, hmm Feb 08 20:04:18 Er, yeah, not found, not the pipe thing Feb 08 20:04:37 eFfeM1, yes, I expect that now a valid cache would be found Feb 08 20:05:05 kergoth, have you used the external-toolchain stuff denix pushed? :) Feb 08 20:05:28 not yet, i need to sit down and spend more quality time with external-toolchain in general, haven't messed with it much Feb 08 20:05:34 k Feb 08 20:05:38 * kergoth adds to his todo for this week Feb 08 20:05:45 heh Feb 08 20:05:59 Seems to be pretty OK, just doesn't automatically add to PATH Feb 08 20:25:42 Ah good, PATH_prepend := adds it in like I want Feb 08 20:25:46 Tartarus: It can add to PATH, I'm sure at least something in poky does Feb 08 20:26:13 Tartarus: you shouldn't need := Feb 08 20:29:18 hmm, checking Feb 08 20:30:42 re Feb 08 20:31:57 Tartarus: I think there is already a PATH_prepend in bitbake.conf so you may want .= or something similar. I can't remember whether mutiple _prepends stack or not :/ Feb 08 20:32:03 also worked Feb 08 20:32:11 yeah, it's stacking Feb 08 20:32:14 Tartarus: cool :) Feb 08 20:32:17 .= is what i was thinking i wanted, heh Feb 08 20:37:13 re Feb 08 20:47:01 anyone know why 2.6.31/32 is not preferred for overo/beagle? Feb 08 20:47:53 no one has made one for Angstrom that supports the dsp/sgx demos? Feb 08 20:48:24 crofton hm? Feb 08 20:48:48 ti breaks wit the next hardware the dsp api again Feb 08 20:48:55 not sure Feb 08 20:49:11 I suspect because the one we have works :) Feb 08 20:50:10 thats fair... Feb 08 20:50:22 crofton I was at the dsp talk at fosdem Feb 08 20:50:29 how was that? Feb 08 20:50:32 that was the only new think I got out of it Feb 08 20:50:44 any idea if anyone taped it? Feb 08 20:50:55 there were some cameras Feb 08 20:51:15 but he mostly talked about programming with dsp-bridge Feb 08 20:51:33 yeah Feb 08 20:51:59 I am personal likes dsp-link more Feb 08 20:52:14 but didnt programm something yet Feb 08 20:52:30 yeah Feb 08 20:52:35 I am in the smae boat Feb 08 20:52:56 but dsp-link will not hit main kernel tree Feb 08 20:53:21 this problem needs fixiing Feb 08 20:53:31 lol Feb 08 20:53:46 that problem is a minefield like poulsbo driver Feb 08 20:54:02 yeah Feb 08 20:54:15 I wish I was smart enough to figure it out Feb 08 21:00:35 hmmm Feb 08 21:00:51 kergoth yes? Feb 08 21:01:17 Crofton but the guy who held the talk, made *sigh* his own oe-overlay again Feb 08 21:03:38 this gzip execution failure under cygwin is fucking weird. doesn't happen at a shell, even if i filter the same env vars out. hmm Feb 08 21:04:19 what? Feb 08 21:04:39 hm has cygwin now the new auth mechanism? Feb 08 21:04:48 which handles kerberos/AD right? Feb 08 21:05:12 :p Feb 08 21:07:35 woglinde, indeed(for problem with ploubseau and dsp-things) Feb 08 21:08:15 woglinde, do you have any infos on the license of dsp-link and the other that was not bridge on the dsp side? Feb 08 21:08:33 Tartarus:when gettext-native gets rebuild and I remove the tmp dir again and then bitbake console-image again, the "invalid" error remains Feb 08 21:14:28 kergoth: very weird. same tar? Feb 08 21:14:57 there's no tar or gzip in tmp at all Feb 08 21:15:08 works fine in devshell Feb 08 21:15:10 * kergoth scratches head Feb 08 21:15:11 NOTE: Update cvs://anonymous@cvs.sv.gnu.org/cvsroot/config;module=config;method=pserver;date=20050701 Feb 08 21:15:12 tar (child): gzip: Cannot exec: No such file or directory Feb 08 21:15:12 tar (child): Error is not recoverable: exiting now Feb 08 21:15:12 NOTE: Task failed: Fetch failed: config Feb 08 21:15:35 maybe its not gzip itself its not finding Feb 08 21:15:36 hm. cygwin, so no strace. bummer. Feb 08 21:15:44 guess it could be the directory its in went away, or something Feb 08 21:15:53 but i dont see why itd only happen under cygwin Feb 08 21:16:19 pb??? Feb 08 21:16:23 cygwin has strace Feb 08 21:16:26 I used it Feb 08 21:16:47 I think that message is diagnostic of not being able to find gzip. sounds like tar has a screwed-up $PATH or something. Feb 08 21:16:52 woglinde: oh, does it? very good Feb 08 21:16:57 in that case, kergoth just needs to use it :-) Feb 08 21:17:03 it's just an os.system() call from bitbake's python Feb 08 21:17:10 no mangling of any env vars other than the usual filtering Feb 08 21:17:14 heh, i'll try that Feb 08 21:17:36 course, in this case, there's no reason it couldn't just use tarfile.TarFile & friends, but.. :) Feb 08 21:18:13 heh Feb 08 21:18:14 true Feb 08 21:19:47 hrm, still can't figure out where my toolchain packages are getting this bogus PACKAGE_ARCH from Feb 08 21:19:49 * pb__ stabs oe Feb 08 21:20:13 Packaged contents of gcc-cross-arm-oe-linux-uclibceabi into /home/pb/oe/build-qemuarm/tmp/deploy/ipk/armv5te/gcc-cross-arm-oe-linux-uclibceabi_4.4.2-r2.1_armv5te.ipk Feb 08 21:20:14 heh Feb 08 21:20:43 hm whats wrong? Feb 08 21:20:46 with this? Feb 08 21:49:28 woglinde: it should be _x86-64.ipk Feb 08 21:49:54 since it is a cross compiler, not a target-native compiler Feb 08 21:50:52 oh right Feb 08 21:51:20 bedtime here, back tomorrow, stay well! Feb 08 21:51:26 nite effem Feb 08 21:55:04 oh eFfeM quit... Feb 08 21:55:26 this is the best msg of the serie ;) Feb 08 21:55:29 * pkg_hash_add_from_file: Package staging-opkg-native-i686-linux version 0.1.6+svnr519-r19 has no valid architecture, ignoring. Feb 08 21:55:58 opkg = ko pkg Feb 08 22:00:12 yeah, opkg is teh suck Feb 08 22:00:43 I was a bit disappointed that nobody in the FOSDEM distro showdown session mentioned a better package manager as something that different projects could cooperate on :-} Feb 08 22:01:30 pb__: yay for toolchain-desuck Feb 08 22:04:15 Tartarus: heh, yeah, it is surprising how much bogus stuff is lurking in those recipes. Feb 08 22:04:50 Tartarus: I might have a go at doing the $ORIGIN thing for gcc-cross as well. I take your point about it being slightly annoying to calculate the right relative paths for things like cc1, but it doesn't seem like that should be completely intractable. Feb 08 22:07:00 People have been doing $ORIGIN stuff? Is that on the OE list? Feb 08 22:08:08 RP__: I don't think anybody has actually been doing it, but Tartarus and I had a brief discussion (indeed on the list) about using that to make gcc more relocatable for hosts that don't ship libmpfr Feb 08 22:08:52 pb__: Its something I've been thinking about too... Feb 08 22:09:05 if I understand the issue correctly, you can't currently move the sysroot containing gcc on a non-libmpgr-equipped host, because then gcc stops being able to find its local copy of that library. Feb 08 22:09:31 but, it seems like a suitably constructed "--rpath $ORIGIN/../../.." kind of thing would fix that. Feb 08 22:10:30 pb__: Right. It would be lovely if we could get the compiler/linker to work that out for us... Feb 08 22:11:09 pb__: Lemme point you at the patch for gcc Feb 08 22:11:24 gcc/binutils suck due to the multiple reruns on configure Feb 08 22:11:40 RP__: yeah, that is an interesting idea. of course, the immediate problem with that is that the compiler doesn't know where you are going to install the binary, but I guess it could be given that information. Feb 08 22:11:51 gcc-cross needs a few ..'s then staging/${host_arch}/... added Feb 08 22:11:55 which is ugly, but fixes it Feb 08 22:12:41 Tartarus: you mean due to the cygnus configure arrangement with multiple subsidiary configures? Feb 08 22:12:52 afaik, they only run each configure script once each, though I could be wrong about that Feb 08 22:13:18 pb__: I think we could teach it some kind of sane assumptions... Feb 08 22:13:59 pb__: Er, yes? sec... Feb 08 22:16:22 pb__: I dont have any gcc-cross in my deploy dir Feb 08 22:16:33 RP__: true, though in most of the cases where the sane assumptions would hold, I think "$ORIGIN/../lib" would probably be good enough Feb 08 22:17:08 i.e. you could do that statically without needing any help from gcc :-} Feb 08 22:17:08 khem: what branch are you on, .dev? Feb 08 22:17:12 yes Feb 08 22:17:24 yeah, this is only on the toolchain-desuck branch at the moment Feb 08 22:17:38 ah Feb 08 22:17:40 oh Feb 08 22:17:43 can't find the patch url yet Feb 08 22:17:57 pb__: what is all planned on that branch Feb 08 22:18:33 khem: ideally, what I want to achieve is making the toolchain bits all properly packageable, with no custom do_stage() methods. Feb 08 22:18:37 OK, maybe I made it a patch Feb 08 22:18:38 based on Feb 08 22:18:43 http://sourceware.org/ml/binutils/2009-05/msg00252.html Feb 08 22:19:20 LDFLAGS="${LDFLAGS//\$ORIGIN/\\\\\$$\\\$$\\\\\$$\\\$\$ORIGIN}" Feb 08 22:19:21 hah Feb 08 22:19:34 http://pastebin.com/m22698880 Feb 08 22:19:51 That is what I had to do, to get gcc to use $ORIGIN in the end Feb 08 22:19:59 ~curse whoever made $ORIGIN use a $ Feb 08 22:20:01 May you be reincarnated as a Windows XP administrator, whoever made $ORIGIN use a $ ! Feb 08 22:20:10 Tartarus: cool, thanks Feb 08 22:20:17 as-is works on binutils Feb 08 22:20:26 but that's missing the magic bit for getting libmpfr from staging Feb 08 22:20:42 * Tartarus needs to poke folks about committing more frequently Feb 08 22:21:57 I wonder if say CS just forces static link vs libmpfr & co or what Feb 08 22:22:05 haven't bothered to ldd Feb 08 22:22:43 yeah, that'd be another option of course Feb 08 22:23:04 * RP__ would like something we could roll over all the native packages Feb 08 22:23:07 Tartarus: put libmpc libgmp and libmpfr under gcc src tree during build Feb 08 22:23:09 thats it Feb 08 22:23:26 RP__: All of the native packages is easy Feb 08 22:23:35 it's just gcc/binutils that get that shit Feb 08 22:23:52 khen, pb__, maybe we want to look at that then.. Feb 08 22:24:12 I do it for non OE builds here Feb 08 22:24:19 it works well and is less of a headache Feb 08 22:25:18 Tartarus: due to the extra directory level? This assumes everything ends up in usr/bin and needs libs from usr/lib? Feb 08 22:25:29 http://pastebin.com/m6167f3e4 Feb 08 22:25:52 catches everything else, except perl, and needs a python 2.6.x with a patch i think that is in .4 but not .2 Feb 08 22:26:02 RP__: yes, there is an assumption about layout in these too Feb 08 22:26:43 Could just kinda fake it and always do ../lib, ../../lib and ../../../lib Feb 08 22:26:49 (and lib64 too?) Feb 08 22:26:58 Tartarus: hmm. This all seems rather evil :/ Feb 08 22:27:06 RP__, yes, a little bit Feb 08 22:27:10 actually same problem can happen if you dont have zlib installed on the targeted host where the toolchain is relocated to Feb 08 22:27:14 Tartarus: for the gcc/binutils that might be a sane solution... Feb 08 22:27:17 that said, staging/host-arch/lib is always empty, yes? Feb 08 22:27:40 Tartarus: Poky's sdk ships glibc and the dynamic loader now Feb 08 22:27:50 RP__: gcc/binutils just get stuck being needing an evil patch :( Feb 08 22:28:01 everything else is sane enough to obey global flags Feb 08 22:28:05 RP__: That's, er, interesting Feb 08 22:28:13 Why that over just LSB linking? Feb 08 22:29:02 Tartarus: I wanted to solve the incompatibilities once and for all... Feb 08 22:30:49 Did you go the LSB route and still get bit? Feb 08 22:30:54 That seems a tad excessive... Feb 08 22:31:16 Tartarus: It just turned out to be very simple to implement Feb 08 22:31:49 Tartarus: and meant you can do candian builds properly (32 and 64 bit sdks from the same build machine) Feb 08 22:32:01 yeah, that probably is an easier solution than trying to lean on LSB. not very pretty, but I can see it being attractive. Feb 08 22:32:05 Since you're shipping all the libs, I guess it doesn't matter mind :) Feb 08 22:32:23 RP__: is that all relocatable too? Feb 08 22:32:25 of course, it's a bit of a disaster for non-linux build hosts, but then LSB doesn't help you there either so you are still no worse off. Feb 08 22:32:52 Tartarus: No, but if OE has changes to make things reclocatable, this will be too if I merge them Feb 08 22:34:22 RP__: It's pretty close right now Feb 08 22:34:27 it seems building toolchain statically is the better solution Feb 08 22:34:41 *-cross-sdk just needs to use $ORIGIN and binutils/gcc need that extra hell Feb 08 22:34:51 or rebuild differently so the mpfr thing is a non-issue Feb 08 22:34:58 khem: This wasn't just for the toolchain, it was for other tools too Feb 08 22:35:46 We could package host tools Feb 08 22:36:06 RP: I don't think there is any good way to make your sysroot relocatable if you have a custom dynamic linker. Unless you wrap all your binaries in shell scripts of course. Feb 08 22:36:43 presumably, right now all your binaries have a hardwired PT_INTERP pointing to somewhere inside your sysroot. Feb 08 22:37:05 PT_INTERP should be appended to --sysroot= Feb 08 22:37:11 by ld Feb 08 22:37:15 pb__: That is indeed a potential problem Feb 08 22:37:29 pb__: It doesn't support $ORIGIN ? Feb 08 22:37:42 RP: no, ld.so is the thing that processes $ORIGIN :-) Feb 08 22:37:59 PT_INTERP itself is processed by the kernel, and I don't think it understands $ORIGIN at all. Feb 08 22:38:21 of course, you could hack it so that it did, but then your sdk would need to ship a custom kernel and I suspect that might be a bridge too far Feb 08 22:38:24 pb__: Thats what I was asking... Feb 08 22:38:40 pb__: A custom kernel is not on the agenda Feb 08 22:39:46 afaik, PT_INTERP can only be a simple absolute path. I don't think the gABI admits anything beyond that, and I am pretty sure the kernel just calls open() directly on the string it finds there. Feb 08 22:40:43 pb__: That sounds sane (unfortunately). Feb 08 22:40:50 doing the wrapper script thing would not be impossible, though, and I suspect that is probably your best option in this situation. Feb 08 22:40:59 * RP__ wonders about a relative path Feb 08 22:42:18 hmm ORIGIN is interesting Feb 08 22:43:02 RP: I have a feeling that, if you put a relative path there, the kernel will just interpret it relative to the cwd of the exec()ing process rather than the location of the binary. Feb 08 22:53:12 pb__: Looking at the kernel code, I think you're right Feb 08 22:57:45 pb__: are you also going to move cross into the host staging area ? Feb 08 22:58:25 khem: yes Feb 08 22:58:37 in fact, that is already (mostly) done Feb 08 22:58:42 pb__: cool Feb 08 22:58:53 if you build from the branch, you should find there is no cross/ subdir anymore Feb 08 22:58:57 I should look at the branch Feb 08 23:01:40 pb__: I guess http://git.openembedded.org/cgit.cgi/openembedded/commit/?h=pb/toolchain-desuck&id=ebe7729f6d056b4de17342e5010f1cfe27f90546 is the reason for the bogus PACKAGE_ARCH Feb 08 23:03:12 no, actually, it's unrelated to that. it turns out that tune-arm926ejs.inc (for example) forces BASE_PACKAGE_ARCH to "armv5te", overriding the default of ${HOST_ARCH} Feb 08 23:03:47 so, that sucks, but it is fairly easy to work around it by just forcing {BASE_}PACKAGE_ARCH back to the right value in cross.bbclass Feb 08 23:05:11 I still don't entirely understand what that deleted code in cross.bbclass was trying to accomplish, but I am fairly sure that we are better off without it. Feb 08 23:06:16 I dont either but I think it was trying to use PACKAGE_ARCH = HOST_ARCH for cross packages and save original PACKAGE_ARCH Feb 08 23:08:12 mm I think it evaluates the current value of the variable with := and reassigns it Feb 08 23:08:28 right there Feb 08 23:08:49 its saving the original value and then forcing that value to remain Feb 08 23:09:13 We needed the value of HOST_ARCH before the class messed around with it. Feb 08 23:09:16 I guess the value is influenced by other parameters so it evaluates it as it goes Feb 08 23:09:30 I suspect I was even responsible for some of that :/ Feb 08 23:09:34 and saves it Feb 08 23:09:56 right RP:) Feb 08 23:10:32 Originally it was just PACKAGE_ARCH, then we had BASE_PACKAGE_ARCH to worry about too Feb 08 23:10:39 yeah Feb 08 23:10:59 pb__: that commit really is than the one which changes it for you Feb 08 23:12:20 This was all stuff for mutlimachine. Changing PN looks like a nicer way to do it Feb 08 23:12:54 I'm not sure I'd bother with the horrible PROVIDES though Feb 08 23:14:08 pb__: That form of package name will also probably upset the BPN code which does things line PN.endswith("-cross") Feb 08 23:16:08 khem: no, I think you have it backwards. if that OLD_BASE_PACKAGE_ARCH thing was left in place, it would also cause me to get the wrong value. Feb 08 23:16:22 removing it is necessary, but not sufficient due to the tune-xx thing. Feb 08 23:16:46 RP__: ah, yeah, right. I will have a look at that in the morning and see what I can do about it. Feb 08 23:17:17 RP__: the most annoying thing about changing PN for the toolchain bits is that it breaks all the PREFERRED_PROVIDER rules in the .conf files. But I can't think of any good way to avoid that really. Feb 08 23:17:28 urg, off to home improvement store for supplies to work on plumbing, suspeted clogged pipe Feb 08 23:17:32 and store for beer Feb 08 23:18:24 horrible PROVIDES is just there for some measure of backwards compatibility. I suspect it is probably not necessary. Feb 08 23:18:44 pb__: Yes, I was wondering about that and I see what you mean about compatibility now. Hmm :/ Feb 08 23:19:04 pb__: It would be nice to take a step back and solve some of this properly Feb 08 23:19:29 rather than continually trying to retain compatibility and digging a deeper hole Feb 08 23:19:41 which is what I see packaged-staging as :/ Feb 08 23:20:17 yeah, I think I am on the point of throwing packaged-staging away and writing a new replacement for it from scratch. Feb 08 23:20:31 it doesn't really seem to solve my problems in a way that I want to have them solved :-} Feb 08 23:21:00 pb__: I hate the thing :( Feb 08 23:21:19 Its just what circumstances dictated was necessary Feb 08 23:21:44 pb__: but we also disagree on the package reuse thing :/ Feb 08 23:22:17 when i was experimenting with private staging, i combined the packaged-staging functionality with the sysroot/staging bits in base.bbclass, moved it all into a staging.bbclass, and pulled that in from base. probably a decent way to go for a replacement for the regular thing too Feb 08 23:22:21 heh Feb 08 23:23:02 aside: cygwin just keeps biting me in the ass with new and fun issues.. did you know that a 'install.exe' will fail to run due to lacking permissions unless its run via uac / administrator, just because it has "install" in the name? Feb 08 23:23:04 kergoth: It was always intended to merge it into base or similar... Feb 08 23:23:16 kergoth: scary :/ Feb 08 23:23:28 very.. gotta love silly heuristics based on executable name Feb 08 23:23:29 * kergoth pukes Feb 08 23:23:35 kergoth: hah, cute Feb 08 23:23:40 the cygwin /usr/bin/install.exe has a /usr/bin/install.exe.manifest that says "i really don't want administrator, thanks" Feb 08 23:23:59 think i'll patch coreutils-native to automatically provide it when targeting cygwin.. Feb 08 23:24:01 * kergoth shakes head Feb 08 23:25:34 *g* Feb 08 23:25:47 RP__: incidentally, it occurs to me that if you are going to end up wrapping your binaries anyway to solve the PT_INTERP thing, you can also handle the library path in the wrapper and not need to bother with $ORIGIN at all. might even be a better way of solving the problem, since you can do it as a single post-process step once all the binary paths are fixed. Feb 08 23:26:09 no need to guess at compile time where the binaries and libs are going to land relative to each other. Feb 08 23:26:42 and, no monster $$$$$$$$$$$$\\\\\\\$$$$$$$$$$$$$$$$$$$$$$$$$$$ style stuff in the makefile, which has got to be a win Feb 08 23:27:36 pb__: I must admit that monster expression makes me feel ill Feb 08 23:29:48 yeah, I can't help wondering whether the next autoconf release will require you to add an extra backslash somewhere Feb 08 23:30:00 (or an extra ten backslashes, of course) Feb 08 23:30:46 pb__: or introduce a new character representing ten backslashes which needs to be specified in triplicate for correct expansion Feb 08 23:30:50 hi bluelightning Feb 08 23:30:56 heh, right, or that Feb 08 23:31:40 * pb__ bedtime now Feb 08 23:31:41 night all Feb 08 23:32:09 'night pb__ Feb 08 23:32:17 nite pb Feb 08 23:32:32 * RP__ -> Zzzz too Feb 09 00:48:13 hmmmm Feb 09 00:48:22 Should I rfc, or just do, removing the locale stuff from task-sdk-bare? Feb 09 00:54:17 I want to make a recipe/package that essentially dumps a tarball of files in a specific place (in particular, it populates htdocs) Feb 09 00:54:32 Is there a good "file dump" recipe in the tree I could copy? Feb 09 01:02:24 My default is just going to be a manual do_install() stage, which seems sane but maybe not optimal Feb 09 01:18:08 /quit zaoo Feb 09 02:13:26 Tartarus: rfc is better I would say Feb 09 02:13:59 sethn: use do_install Feb 09 02:14:29 khem: thanks, its working fine, I just wanted to learn if there was a better way! Feb 09 02:16:23 sethn: do you see some performance problem ? Feb 09 02:16:44 khem: no works great Feb 09 02:17:01 khem: just trying to learn as much as I can about writing maintainable bitbake recipes Feb 09 02:17:24 * sethn goes back to fighting apache2 into compiling :) Feb 09 02:17:43 sethn: from maintainablilty POV you should use bitbake provided methods as much as possible and classes Feb 09 02:18:02 khem: yeah, I was curious if there was a method/class that automated this Feb 09 02:18:43 khem: I could have imagined there was a class that would let me give it a tarball, and a place to install the files, and it would worry about the rest Feb 09 02:18:57 but a do_install() method isn't all that different Feb 09 02:19:30 exactly, bitbake provides for common tasks Feb 09 02:20:06 sometimes people append or prepend to tasks to achieve something additional Feb 09 02:20:19 sometimes even overrided the complete do_install Feb 09 02:20:36 but if you do so then it needs more maintenance obviously Feb 09 02:20:41 * sethn nods Feb 09 02:25:53 * khem (SIGFOOG) Feb 09 02:27:10 SIG_ERR Feb 09 02:27:40 * khem SIGFOOD Feb 09 02:32:35 khem: What's the difference between DEPENDS and RDEPENDS ? Feb 09 02:32:45 SIGFOGGY Feb 09 02:33:04 DEPENDS adds buildtime dependency Feb 09 02:33:44 RDEPENDS adds runtime dependency which means when you will install the resulting ipk it will require the package added to RDEPENDS Feb 09 02:34:52 khem: makes sense, thanks Feb 09 02:35:06 sethn: there is bitbake manual too http://docs.openembedded.org/usermanual/usermanual.html **** ENDING LOGGING AT Tue Feb 09 02:59:56 2010