**** BEGIN LOGGING AT Wed Nov 16 02:59:57 2011 Nov 16 09:00:22 morning all Nov 16 11:30:08 RP__: hi, you're right about PACKAGECONFIG_virtclass-nativesdk in libsdl, but now it's passing --enable-video-opengl even for nativesdk case and after such change it wont do it Nov 16 11:30:46 RP__: I'm not saying that passing --enable-video-opengl without proper DEPENDS is correct now Nov 16 11:33:12 JaMa|Wrk: Hmm, its seeing the override too late or something? :/ Nov 16 12:10:27 RP__: no, currently there is ${@base_contains('DISTRO_FEATURES', 'opengl', '--enable-video-opengl', '--disable-video-opengl', d)} in EXTRA_OECONF for nativesdk too Nov 16 12:10:44 RP__: after PACKAGECONFIG_virtclass-nativesdk it will pass --disable-video-opengl Nov 16 12:12:11 I have follow up patch http://git.openembedded.org/openembedded-core-contrib/commit/?h=jansa/pull&id=53cfa7b8a85e18c93e8e734eefc7b19d4c07722c once this is decided what's correct behavior Nov 16 13:44:24 hm, where is the code that's pulling in qemu-config if MACHINE is qemux86? I think it has to be meta/conf/machine/qemux86.conf, but I'm not seeing it Nov 16 13:49:39 walters: meta-yocto/conf/distro/poky.conf Nov 16 13:49:48 search for POKYQEMUDEPS Nov 16 13:50:40 i saw that but it looked too weird so i skipped it =/ Nov 16 13:50:58 so that is saying only add qemu-config if there is no GPLv3 code in the image? Nov 16 13:53:21 walters: yes, it's because qemu-config requires oprofileui-server and that wants to build something that's gplv3 Nov 16 13:53:38 I have a fix for that but it's currently held up on some other issues Nov 16 13:53:47 ah ok Nov 16 13:55:18 hm, but it's not possible to actually link (in the GPL sense) to oprofileui-server, so INCOMPATIBLE_LICENSES is really more LICENSES_TO_BAN right? Nov 16 13:55:57 walters: it's a way of saying "I don't want GPLv3 stuff in my image" Nov 16 13:56:03 right Nov 16 13:56:04 ok Nov 16 13:56:17 but it actually extends to "I don't want anything GPLv3 built, that's not on the whitelist" Nov 16 13:57:49 bluelightning, how about this patch? http://pastebin.mozilla.org/1384043 Nov 16 13:58:27 walters: possibly, I'd rather fix the problem so we don't need that notice though :) Nov 16 13:58:43 I don't imagine it will be long before the proper fix is ready Nov 16 13:58:56 ok Nov 16 14:02:54 so my higher level goal was to still target qemu, but keep my image close to what i want to ship, i.e. without all the debugging stuff that qemu-config pulls in Nov 16 14:03:51 looks like I could just empty out POKYQEMUDEPS later, but maybe it's better to make a machine target like atom-pc.conf ? Nov 16 14:09:14 or hm, more likely i should make a distro file Nov 16 14:13:47 I'm intending to clean up qemu-config a little, rename it (since the stuff in it could be just as useful on a real device) and maybe make it an IMAGE_FEATURE you can turn off easily Nov 16 14:14:42 task-target-debugging? Nov 16 14:28:24 walters: I was thinking something like that yeah Nov 16 14:54:00 * RP__ hates libtool Nov 16 14:54:28 * RP__ wishes it wouldn't link things twice during the build, once would be more than sufficient Nov 16 15:02:37 hm ... why do you have two channels here (#yocto and #poky) ? Nov 16 15:17:10 errordeveloper: yocto is the overall project and has several components of which poky is just one Nov 16 15:22:59 any objections to moving /etc/rpm-postinsts to /var? Nov 16 15:23:08 /etc is a read-only bind mount in my OS Nov 16 15:31:15 walters: you should ping fray but probably not Nov 16 15:31:35 RP__, any alternative suggestions? Nov 16 15:31:55 walters: I'm ok with it but mark (fray) maintains the rpm stuff Nov 16 15:32:03 fray, ^ Nov 16 15:33:56 walters: he might not be awake quite yet Nov 16 15:36:50 var seems like a better place, that's where most metadata of that sort lives for package managers, no? Nov 16 15:37:22 kergoth_: I'm not disagreeing... Nov 16 15:38:21 * kergoth_ nods Nov 16 15:38:56 it'd really be nice to have some sort of declarative way to support breaking up images and easier support of RO vs RW partitions and the like Nov 16 15:38:58 somehow Nov 16 15:41:05 * RP__ contemplates some nasty hacks to libtool to avoid the link and relink differences which are effectively pointless when cross compiling Nov 16 15:41:51 what ever happened with dolt? Nov 16 15:42:28 walters: libtool got some speedups to the point where the outright speed difference was small Nov 16 15:42:32 i liked there idea of "okay you have linux/glibc, let me write out the trivial bits; oh you're running AIX, here's ten thousand lines of shitty shell script" Nov 16 15:43:17 the relink at install stuff for libtool, was that just for things like rpath for the install dest? Nov 16 15:43:25 kergoth_: yes Nov 16 15:43:34 walters: sadly dolt only replaces the compile portion at this point Nov 16 15:43:36 not the link Nov 16 15:43:40 kergoth_, ah Nov 16 15:43:40 would be nice though Nov 16 15:44:01 wouldn't be that hard either Nov 16 15:45:54 kergoth_: what annoyed me was pulseaudio's install task taking 2m47. Take the relinking out and its more like 17s Nov 16 15:46:29 turn pseudo off and it was something like 1m37 :( Nov 16 15:46:34 youch Nov 16 15:46:39 that's ridiculous Nov 16 15:50:36 it has to be doing more then relinking if it's taking over a minute Nov 16 15:50:47 either that or it has an insane amount of symbols to be resolved Nov 16 15:51:46 If anyone has a build handy, a "time bitbake pulseaudio -c install -f" would be interesting for comparision Nov 16 15:51:46 BTW in a single instance, how big is the pseudo DB getting? that's a rough reading of files accessed.. Nov 16 15:52:41 fray: It's around the 1.9MB mark for pulseaudio Nov 16 15:52:52 it's referencing a -lot- of files then Nov 16 15:53:59 BTW I really wonder if do_install should rm the pseudo DB before it starts (in a non pseudo task of course) Nov 16 15:54:17 I'm going to see about finding a way to balance the performance of the delete avoidance with the overall size required when we don't delete.. Nov 16 15:55:22 fray:FWIW I'd forced the install task several times on that db Nov 16 15:55:29 I was seeing consistent times though Nov 16 15:56:48 ok.. I know when the db gets into the > 20 MB range (or mroe) it can become an issue Nov 16 15:57:12 real 3m42.067s Nov 16 15:57:12 user 1m20.872s Nov 16 15:57:12 sys 1m40.437s Nov 16 15:57:20 mips.. 8/8 parallel build Nov 16 15:57:31 so its not just me... Nov 16 15:58:03 my DB is 2.1 MB Nov 16 15:58:07 I'm running 24/24 Nov 16 15:58:08 (that I assume is after a second run) Nov 16 15:59:23 approx 1470 files -- including the debug stuff Nov 16 15:59:26 what is best practice for setting PV when you are pulling from two commits past a named release from a git repo? Nov 16 15:59:36 9723 w/o debug Nov 16 15:59:43 PV = "0.9+gitr${SRCREV}" ? Nov 16 15:59:50 this is a much bigger package then I though.. Nov 16 15:59:53 dvhart: yes Nov 16 15:59:54 'er.. that was 973 Nov 16 16:00:02 RP__, thanks Nov 16 16:01:07 * fray runs again, but this time w/o an existing pseudo DB Nov 16 16:01:24 (might give me a more accurate result as far as file counts go) Nov 16 16:06:36 real 3m31.649s Nov 16 16:06:36 user 1m20.582s Nov 16 16:06:36 sys 1m39.585s Nov 16 16:15:54 is there a reason we're not using devtmpfs? Nov 16 16:16:21 * walters is eyeing /etc/init.d/udev-cache Nov 16 16:17:13 dvhart: s/SRCREV/SRCPV/ Nov 16 16:17:28 poky seems fairly conservative with early userspace, i guess that's understandable since what's there mostly does the job of booting your app, but Nov 16 16:17:52 walters, I'm using devtmpfs in meta-tiny Nov 16 16:17:52 walters: I'm using devtmpfs :) Nov 16 16:18:03 eliminating the server spawning cut approx 15 seconds off the "real" time.. Nov 16 16:18:06 walters, and we're looking to incorporate meta-tiny into poky proper Nov 16 16:18:23 ok right, clearly one can use it, just curious why it's not the default Nov 16 16:18:24 so that is the likely message passing and DB overhead Nov 16 16:18:32 dvhart, ok Nov 16 16:29:33 fray: thats an interesting result... Nov 16 16:29:58 walters: I think people have been experimenting and the time is approaching to change the deafaults in the core Nov 16 16:30:21 fray: Can I ask some rpm questions, hopefully quick ones? Nov 16 16:30:43 sure Nov 16 16:32:00 fray: Occasionally I see rpm temp file errors Nov 16 16:32:11 ya.. we need to instrument those.. Nov 16 16:32:14 fray: Its when multiple processes are writing rpm packages Nov 16 16:32:18 the problem is right now we get an error and nothing telling us what is wrong Nov 16 16:32:26 Ahh, ok, that is info I didn't have before Nov 16 16:32:29 fray: Looking at the code I can make a guess Nov 16 16:32:44 rpm temp files are of the name rpm-tmp.<.....> Nov 16 16:32:55 uses mkstemp for the naming.. so it sounds like there is likely a race then Nov 16 16:32:55 fray: I think its using lockfiles in /var/tmp and occasionally timing means we conflict Nov 16 16:33:01 yup Nov 16 16:33:06 ok, this suddenly make a LOT more sense Nov 16 16:33:22 fray: Its using spec->rootURL as the path case. I'm guessing that is "/" for us? Nov 16 16:33:24 we could move the tmp directory to the work directory... Nov 16 16:33:30 ya, it would be "/" Nov 16 16:33:47 right, this was my thought, can we simply point _tmppath to workdir? Nov 16 16:33:48 it should be using the _tmpdir value.. which isn't actually /var/tmp -- but our internal designation of such Nov 16 16:34:00 ya.. it "should" be that easy Nov 16 16:34:08 Do we set _tmppath anywhere? Nov 16 16:34:09 let me verify it's tmppath Nov 16 16:34:17 ya, it's in the rpm_rootfs update stuff Nov 16 16:34:22 fray: rpmTempFile in signature.c Nov 16 16:34:35 fray: but not package_rpm.bbclass for the package generation? Nov 16 16:34:48 -D "_var ${localstatedir}" \ Nov 16 16:34:58 that is what you want to add.. I think.. let me verify Nov 16 16:35:29 fray: I don't have a reproducible test case but it can't hurt to change this Nov 16 16:36:13 nope.. setting _var in this case is wrong Nov 16 16:36:28 ya.. set -D "_tmppath ...." is the right answer Nov 16 16:36:29 bluelightning, ping Nov 16 16:36:39 hi dvhart Nov 16 16:36:52 hey, so I'm finishing up the efilinux recipes Nov 16 16:37:05 add that around like 951 (or so) to package_rpm.bbclass Nov 16 16:37:07 I'm turning do_install into a nop Nov 16 16:37:09 dvhart: ah yes I meant to ask you about what exactly was going wrong with that... Nov 16 16:37:30 bluelightning, do I need to leave an empty stub in the recipe, or is there a way to just skip the install step? Nov 16 16:37:35 cmd = cmd + " --define '_tmppath " + workdir +"'" Nov 16 16:37:43 dvhart: I think you can just make it an empty stub Nov 16 16:37:56 gm all Nov 16 16:38:00 ok, there isn't some standard means of skipping steps? Nov 16 16:38:03 gm zeddii Nov 16 16:38:04 fray: I'll give this a go, thansk for confirming Nov 16 16:38:07 np Nov 16 16:38:12 I'm glad you finally figured it out.. Nov 16 16:38:13 hi zeddii Nov 16 16:38:24 dvhart: I have seen a number of recipes that put a single indented colon in the function but to be honest I'm not sure what that does if it is still needed Nov 16 16:38:25 whenever I see it I'm stumped.. but the race on the shared tmp directory makes a lot of sense now Nov 16 16:38:29 kergoth_: ^ ? Nov 16 16:38:42 or RP__ Nov 16 16:39:20 bluelightning, there were several problems with the recipes and the sources themselves. They were compiling using the host compiler for a start. Both efilinux and gnuefi needed a handful of fixes to cross compile. Nov 16 16:39:25 bluelightning: its shell for "nothing" Nov 16 16:39:47 dvhart: so yes, you can overwrite a task with something empty Nov 16 16:39:55 RP__: right, but is that different from an empty function? Nov 16 16:40:16 bluelightning: a truly empty function can get lost/cause syntax errors Nov 16 16:40:25 RP__, so that is what I'm doing now, I was just wondering if there was way to just skip install rather than overridding it to nothing. Nov 16 16:40:41 dvhart: there is also do_fooo[noexec] = 1 Nov 16 16:40:58 do_install[noexec] = 1 Nov 16 16:41:05 dvhart: that tells bitbake not to even bother trying to run it Nov 16 16:41:11 dvhart: yes Nov 16 16:41:27 that seems a better option to me Nov 16 16:41:51 thanks RP__ Nov 16 16:42:01 bluelightning, efilinux is building and booting now Nov 16 16:42:10 and the changes to efilinux have been merged upstream Nov 16 16:42:10 dvhart: ok, excellent Nov 16 16:42:23 the gnuefi guys are unresponsive unfortunately Nov 16 16:42:29 so I'm carrying patches for that Nov 16 16:42:29 I have to admit I was not in a position to actually test it Nov 16 16:42:53 bluelightning, understood. It can be done with qemu, but you need an efi bios for it (which I don't have yet either) Nov 16 16:43:25 oh, the gnuefi build CFLAGS were borked too Nov 16 16:43:31 they were removing -fpic Nov 16 16:43:50 which caused some whacky errors in how the final binaries were assembled Nov 16 16:44:18 hmm, sounds like I made a bit of a hash of those recipes :/ Nov 16 16:44:33 bluelightning, that one you couldn't have detected easily Nov 16 16:44:54 everything built and had the proper arch/file type, etc Nov 16 16:44:58 it just didn't run Nov 16 16:45:12 was rather nasty Nov 16 16:45:43 and having the framework in place sped things along nicely - so I still appreciate the help! Nov 16 16:47:05 explain to me why I'm getting spam for cleaning services in Swindon?! Nov 16 16:49:57 dvhart: ok, well I'm glad to hear at least that it works now :) Nov 16 16:50:22 fray: wow, even I don't get those Nov 16 16:50:38 fray: although they'd be about as much use to me as they would be to you :) Nov 16 16:50:47 ;) Nov 16 16:51:10 bluelightning: you probably do get a fair bit more swindon "spam" in general though ;-) Nov 16 16:52:20 RP__: probably :) Nov 16 17:13:20 RP__, using do_install[noexec]=1 results in a do_rootfs failure: Nov 16 17:13:22 | Configuring run-postinsts. Nov 16 17:13:23 | Collected errors: Nov 16 17:13:23 | * satisfy_dependencies_for: Cannot satisfy the following dependencies for task-core-ie: Nov 16 17:13:23 | * efilinux * Nov 16 17:13:23 | * opkg_install_cmd: Cannot install package task-core-ie. Nov 16 17:13:40 I suppose the way I'm specifying the dependecy is incompatible? Nov 16 17:14:08 MACHINE_ESSENTIAL_EXTRA_RDEPENDS = "efilinux" Nov 16 17:23:38 dvhart, I think DEPENDS are actually dependencies on the do_install step. That would explain it. Nov 16 17:23:56 I just tried RRECOMMENDS with the same result Nov 16 17:23:57 Try just setting the do_install function to "" and see if that works Nov 16 17:24:11 zenlinux, I tried using an empty do_install, that also fails Nov 16 17:24:21 it needs to install /boot and FILES_PN=/boot Nov 16 17:24:32 hmm, I wonder how many other recipes have an empty do_install Nov 16 17:26:45 I take back what I just said - that's not really relevant to what's happening here. Nov 16 17:26:55 It is a runtime dependency issue Nov 16 17:27:32 what's the name of the efilinux recipe? Nov 16 17:27:36 e.g, the filename Nov 16 17:28:16 and also what's the name of the package it's generating Nov 16 17:28:18 eflinux_0.9.bb Nov 16 17:28:34 I don't know if does generate one - I don't need it to Nov 16 17:28:40 it doesn't install anything to the rootfs Nov 16 17:28:51 I just need the efilinux.efi binary in the deployment dir Nov 16 17:28:52 so why does task-core-ie depend on it? Nov 16 17:28:56 ^ Nov 16 17:29:01 any ideas why I see this failure in meta-oe? Nov 16 17:29:04 http://pastebin.com/xycRPh2T Nov 16 17:29:47 zenlinux, I'm looking at how we deal with syslinux and bootimg - looks like you can make dependencies on recipe tasks rather than package names.... Nov 16 17:30:00 dvhart, if you're specifying a dependency on efilinux within task-core-ie, that's a runtime dependency, meaning that the package manager will try to install a package named efilinux Nov 16 17:30:27 ok Nov 16 17:30:39 so I need a new mechanism to say "build efilinux and deploy it" Nov 16 17:30:45 there has to be some other kind of trickery to use to simply have the task depend on the copying of that boot file - RP__ would be the one with a clue on that Nov 16 17:31:05 zenlinux, bootimg.bbclass seems to something along those lines for syslinux Nov 16 17:31:21 dvhart, I think that's the example to follow then Nov 16 17:35:33 RP__: does that tmpfile patch fix the BUILDSPEC rpm issue? Nov 16 17:35:42 msm: I think it might Nov 16 17:36:15 Ok, I'll pull it in and see if I see the issue again Nov 16 17:36:25 I saw it again yesterday on our build machine Nov 16 17:36:59 dvhart: Can we take a step back and work out what you're trying to do? Nov 16 17:37:10 dvhart: Are you trying to install files into the rootfs or not? Nov 16 17:37:23 (as that is what RDEPENDS and RRECEOMMENDS are for) Nov 16 17:37:41 no, I'm not Nov 16 17:37:51 when I build for an EFI machine I want to build efilinux.efi Nov 16 17:37:57 and put it in the deploy dir Nov 16 17:38:07 O Nov 16 17:38:20 dvhart: so do EXTRA_IMAGEDEPENDS += " I'm not sure if that should be a machine dependency or an image dependency... or an image type.... Nov 16 17:38:30 dvhart: and look at "inherit deploy" Nov 16 17:38:55 dvhart: see how beagleboard does this with u-boot Nov 16 17:38:59 interesting Nov 16 17:39:43 thanks, once I sort this out, I'll review the docs... I think this concept could be better explained. Nov 16 17:39:49 but maybe I missed it Nov 16 17:39:53 dvhart: quite likely Nov 16 17:40:11 that will be my todo for getting the answer from you ;) Nov 16 17:40:34 dvhart: I wish more people did that :) Nov 16 17:41:00 msm: I just saw it earlier but couldn't reproduce. It did prompt me to look at the code and attempt the fix though Nov 16 17:54:30 RP__: btw: why do we ASSUME_PROVIDED subversion-native now when we have subversion-native? Nov 16 17:55:09 JaMa|Wrk: I "fixed" the entry to enable adding the recipe with less risk Nov 16 17:55:39 ok.. Nov 16 17:56:10 I'll remove it in my branch Nov 16 17:56:45 JaMa|Wrk: I'm still undecided whether changing the defaults re: subversion make sense, obviously its becoming easier to change the defaults Nov 16 17:59:03 you mean default version? Nov 16 17:59:37 because with subversion-native in ASSUME_PROVIDED we cannot assume if host has 1.6 or 1.7 Nov 16 18:34:40 RP -- ahh I see you found a solution to the relink mess Nov 16 18:57:07 anyone have any idea what might cause do_populate_sysroot_setscene to fail with exit code 1 on a native recipe? Nov 16 19:11:36 incandescant: check the logs... I've noticed dbus and shadow-sysroot failing lately Nov 16 19:12:34 bluelightning: I'm wrangling bernard, I've found the relevant commits to cherry-pick Nov 16 19:12:36 bluelightning: but thanks Nov 16 20:23:30 https://github.com/kergoth/oe-core/compare/vardeps seem relatively sane? Nov 16 20:24:13 kergoth_: what is this for? Nov 16 20:24:47 adding more explicit var deps? Nov 16 20:25:36 I'm not sure the gen_package_filedep_var is right.. Nov 16 20:26:05 well, they use those variables Nov 16 20:26:07 I could be reading it wrong.. not sure Nov 16 20:26:14 as far as i can see, anyway Nov 16 20:26:20 msm: yeah Nov 16 20:27:00 # FILERPROVIDESFLIST_pkg - list of all files w/ deps Nov 16 20:27:00 # FILERPROVIDES_filepath_pkg - per file dep Nov 16 20:27:00 # Nov 16 20:27:00 # FILERDEPENDSFLIST_pkg - list of all files w/ deps Nov 16 20:27:00 # FILERDEPENDS_filepath_pkg - per file dep Nov 16 20:27:13 the first is a list of files that have deps, the second is the actual deps Nov 16 20:27:19 I know Nov 16 20:27:36 their contents are irrelevent, this is just indicating that those variables are used Nov 16 20:27:41 ok, then I don't understand what gen_package_filedep_var is supposed to return Nov 16 20:27:49 Ahh, ok.. THAT makes a lot more sense.. Nov 16 20:27:52 it returns the variable names which the tasks reference Nov 16 20:27:57 vardeps are explicit variable dependencies Nov 16 20:28:11 as the python ast analysis code can't determine what is used when names are constructed programmatically Nov 16 20:28:29 ok, ya I understand now.. that makes a lot more sense.. Nov 16 20:28:56 wait.. I don't think it's returning the right values still.. Nov 16 20:29:04 the first FILER*FLIST_ is right Nov 16 20:29:17 the second should be FILER*__ Nov 16 20:29:27 it seems to only be returning FILER*_ Nov 16 20:29:29 oh, missing _ Nov 16 20:29:36 ah Nov 16 20:29:53 + ret.append('FILERDEPENDSFLIST' + p) Nov 16 20:29:54 is wrong too, missing trailing _ Nov 16 20:29:54 + '_' + p should do it Nov 16 20:29:58 k Nov 16 20:30:11 thanks Nov 16 20:30:34 np Nov 16 20:33:24 fixed. will send to the list. appreciate the feedback Nov 16 20:33:45 now that the dep checking code can silence its warnings when vardeps is defined, figured I'd start going through some of them Nov 16 21:25:51 RP__: I notice bitbake doesn't bother cleaning up bitbake.lock half the time. I'd really prefer it to clean up after itself Nov 16 21:27:15 kergoth_: Nov 16 21:27:30 kergoth_: i have a specific string in a variable that is causing problems with sstate-cache Nov 16 21:27:45 its a long variable, and it's actually getting the PARALLEL_MAKE flags passed in Nov 16 21:28:05 which is causing sstate-cache to be invalid for everything Nov 16 21:28:09 and every dependent task Nov 16 21:28:10 interesting Nov 16 21:29:02 i see a blob string after what is ovbiously the do_install step Nov 16 21:29:13 but i can't figure out exactly whats included this blob Nov 16 21:30:18 its this in eglibc.inc Nov 16 21:30:24 EGLIBCPARALLELISM := "PARALLELMFLAGS="${PARALLEL_MAKE}"" Nov 16 21:30:24 EXTRA_OEMAKE += ${EGLIBCPARALLELISM} Nov 16 21:30:24 PARALLEL_MAKE = "" Nov 16 21:32:01 i think just changing that Nov 16 21:32:07 EGLIBCPARALLELISM := "PA to EGLIBCPARALLELISM = "PA Nov 16 21:32:10 can fix the issue Nov 16 21:34:15 kergoth_: Since the do_package_* functions depend on do_package, can we rely on the do_package checksum? Nov 16 21:35:53 kergoth_: The other vardep problem I've been seeing is that we have no way to force the code to do something specific Nov 16 21:36:21 kergoth_: e.g. I want to write something to tell it to just look at the end expanded value of baselib, I don't care how it was constructed, just whether its the same or not Nov 16 22:00:31 msm: you should be able to use vardepsexclude to avoid PARALLEL_MAKE affecting the signature Nov 16 22:03:51 bluelightning: im not sure it's that simple Nov 16 22:03:56 its getting included in another string somehow Nov 16 22:06:42 RP__: heh, I ended up cheating and making an anonfunc that expanded particular vars and shoving them back into the metadata, when i was using the signature code with pstage Nov 16 22:07:36 kergoth_: I'm not very happy with the vardeps stuff atm in general :( Nov 16 22:08:51 msm: is there some diffsigs output on eglibc I could look at somewhere with that in? Nov 16 22:09:15 Me neither, but clearly we need to do something. We're missing dependencies right now Nov 16 22:09:48 kergoth_: oh, agreed, I don't mean that Nov 16 22:10:12 kergoth_: I have another couple of bugs I'm trying to fix which I think I'm going to have to add something to bitbake for Nov 16 22:10:41 kergoth_: I just saying I don't like the fact I'm going to have to do that and would like to find something better medium term Nov 16 22:10:46 * kergoth_ nods Nov 16 22:11:35 kergoth_: At least by applying some bandaids we might figure out the total set of problems and know we've found all the issues so that any improvements can account for them all Nov 16 22:11:53 kergoth_: I'm also pondering oe-core's bitbake version dependency Nov 16 22:12:13 I'd ideally like to use appendVar and friends but that means increasing the version dependency again :/ Nov 16 22:14:39 kergoth_: any thoughts on do_package_* functions depending on do_package and the do_package checksum? Nov 16 22:15:27 would anyone object util-linux-agetty providing u-a for /sbin/getty and making tinylogin also providing u-a? Nov 16 22:32:14 not offhand. I guess it depends on how much we want to rely on the indirect in general. In this particular case it's clearly safe, but in the long term we probably want bitbake to know what things use directly as well as indirectly Nov 16 22:36:13 RP__: I've got a simple fix I believe Nov 16 22:36:27 RP__: I'll send an email soon with a few sstate-cache "possible" fixes Nov 16 22:36:29 with more details Nov 16 22:36:34 msm: sounds good Nov 16 22:36:47 msm: I've not forgotten the open bugs on this subject btw Nov 16 22:37:47 RP__: i think i've almost figured all my sstate issues Nov 16 22:38:01 not sure if my fixes are remotely acceptable though Nov 16 22:38:25 msm: its that baselib one that is frustrating me atm Nov 16 22:38:43 msm: I know what I want the code to do but we don't have a way to do it atm Nov 16 22:40:25 well the baselib one should work after you have it at least Nov 16 22:40:37 it doubles in size, but at least it worsk Nov 16 22:41:22 RP__: new race of today is libtool-native. | /usr/bin/autoreconf-2.68: unrecognized option `--exclude=libtoolize' Nov 16 22:41:38 disappeared on second run Nov 16 22:42:11 ant____: :/ Nov 16 22:54:48 fray: that libtool patch is worth a 12% speedup on my fast build machine... Nov 16 23:09:23 wow.. nice Nov 16 23:10:00 i always hated the libtool relink.. turns out to be worse then i thought Nov 16 23:57:17 fray: v1 appears to have some issues but I have a v2 brewing Nov 16 23:57:40 were things relying on it? Nov 16 23:58:15 no, I had to patch libtool-native as libtool-cross is totally broken and we use mostly -native everywhere Nov 16 23:58:23 we need the -native version to have the relink stage Nov 16 23:58:39 so we need to fix libtool-cross to work properly Nov 16 23:58:41 ha, I didn't even realize we had a "libtool-native" and "libtool-cross". In WR Linux we only have one Nov 16 23:59:08 fray: we have a libtool-native/nativesdk/cross and target version Nov 16 23:59:30 * RP__ repeats he hates libtool Nov 17 00:00:30 we all need the t-shirt -- I hate libtool Nov 17 00:00:45 as I've ranted in the past.. it's 2011 -- why the hell do we still have libtool?! Nov 17 00:01:15 I don't know of a single "modern" UNIX that can't automatically link shared libraries and/or static libraries without going through the mess that is libtool Nov 17 00:01:18 I think at one point we had one of the libtool recipes just for jpeg. needed a generated libtool script since it didn't provide a configure.ac to regen with the correct m4 macro Nov 17 00:01:20 heh Nov 17 00:02:37 kergoth_: I think that was what libtool-cross was originally for (it and apm) Nov 17 00:02:38 (I can understand in 1994 that libtool was still needed because of "old" systems.. but yeesh..) Nov 17 00:02:48 RP__: yeah, I think so Nov 17 00:03:00 i doubt it's even really n eeded anymore Nov 17 00:03:03 but *shrug* Nov 17 00:03:22 kergoth_: apm still needs it Nov 17 00:03:28 (and ltdl -- what a PoS.. cause dlopen is "too hard"...) :P Nov 17 00:03:30 kergoth_: I've tried that recently Nov 17 00:04:46 Hmm, you'd think apm could be replaced with some other way of getting the power management events Nov 17 00:05:01 kergoth_: you'd hope so really Nov 17 00:05:18 considering on some platforms there's no apm bios anyway, its just the kernel interface being used fro the suspend/resume, or something Nov 17 00:05:19 afaik anyway Nov 17 00:05:20 problem is apm is used on non intel architectures to emulate a "standard" power management interface cause nobody can actually agree on one.. :P Nov 17 00:05:25 * kergoth_ nods Nov 17 00:05:28 that's annoying Nov 17 00:05:34 kergoth_: most platforms are adding apm bios emulation :/ Nov 17 00:06:01 * RP__ saw powerpc sharing the arm emulation code not long ago Nov 17 00:06:47 I think the cat wants me to stop working.. he keeps moving my hands and trying to step on the keyboard.. :P Nov 17 00:08:40 * dvhart thinks he has a basic plan forming for EFI support Nov 17 00:08:50 lots of points to consider Nov 17 00:08:56 dvhart, replace it with BLDK or something smaller? ;) Nov 17 00:09:08 (did I say that outloud?) Nov 17 00:09:40 fray, actually I'm referring to how we will boot on EFI platforms in Yocto Nov 17 00:10:08 ya I figured as much.. I'm just not much of an EFI fan (in embedded.. I like EFI on desktops).. Nov 17 00:10:35 well, it's strikes me as a step forward for X86 Nov 17 00:10:48 and allows for much simpler OS loaders and faster boot times Nov 17 00:11:44 fray you mentioned interest in GRUB for the additional device and filesystem support Nov 17 00:12:01 fray, with EFI, I think that advantage is slightly diminished, but still present Nov 17 00:12:39 an EFI firmware is able to provide basic file services to the loader, either from the fat32 system partition or from a flash part with firmware volumes and no filesystem Nov 17 00:12:40 dvhart, that is why folks use grub on "larger" systems.. but frankly i don't like grub much.. Nov 17 00:12:47 the real advantage though is the FS support.. Nov 17 00:13:20 fat32 is ok.. but if someone would implement basic ext2 and LVM support in EFI.. that would eliminate any advantage of grub Nov 17 00:13:26 I'm leaning towards relying on the syslinux family for all the x86 live images, but maintaining grub2 in oe-core for those that want to do whacky things Nov 17 00:13:39 it's really the lvm support that folks wanted from grub in mye xperience.. the ext2/3 was a nice side benefit Nov 17 00:13:54 for embedded as well? Nov 17 00:14:02 we still need grub 1 though.. cause of grub2's GPLv3.. :( Nov 17 00:14:21 the embedded systems that use lvm are the larger ones.. i.e. carrier grade systems that do large billing and routing Nov 17 00:14:33 they're still embedded, but they are approaching dedicated server in some ways.. Nov 17 00:14:52 well that's a non issue for efi Nov 17 00:15:02 since grub1 doesn't support it :) Nov 17 00:15:10 ...and because htye have billing data, lvm is needed for the filesystems so they can have replication and size support and such.. Nov 17 00:15:14 I thought grub1 had lvm support Nov 17 00:15:35 dunno, but it doesn't have efi support Nov 17 00:15:55 ya.. it requires te BIOS emulation (I hate BIOS more then I hate EFI) ;) Nov 17 00:16:02 heh Nov 17 00:16:22 if EFI could just load an ELF image directly -- and someone would implement the fs support.. we wouldn't even need a secondary loader Nov 17 00:16:49 actually, we can do that with a bzImage now Nov 17 00:16:51 Open Firmware on the Macs could do some of that -- but due to a bug in the ELF loader, Linux was too big to directly boot Nov 17 00:17:08 ahh, I didn't know EFI could directly launch a bzImage.. can it also specify command line options? Nov 17 00:17:24 the bzImage needs to have Matt Fleming's EFI_STUB patches Nov 17 00:17:31 but I tested yesterday and it works Nov 17 00:17:35 cool Nov 17 00:17:40 it can pass the arguments from nvram Nov 17 00:17:54 thats a lice improvement.. and may be able to make BLDK even better.. Nov 17 00:17:55 there are runtime services for those, setvar, etc Nov 17 00:18:08 what I want to do is put the kernel into flash and boot it from flash... :| Nov 17 00:18:16 yup, also doable Nov 17 00:18:20 using firmware volumes Nov 17 00:18:43 can you get the bzImage small enough to fit into flash w/ the EFI? Nov 17 00:18:54 that seemed to be the largest issue last time I looked into i Nov 17 00:19:41 depends on your kernel for sure Nov 17 00:19:57 but I have an 850k bzImage here that I'm testing Nov 17 00:19:58 so, yes Nov 17 00:20:02 nice Nov 17 00:22:21 fray, so the interesting bit is how do we support this on the live images Nov 17 00:22:37 I was considering a MACHINE_FEATURES+="efi" Nov 17 00:22:44 live images -- syslinux is what I would do.. Nov 17 00:22:53 syslinux doesn't support efi Nov 17 00:23:04 I have efilinux working, but it has no UI Nov 17 00:23:10 that isn't coming until much later Nov 17 00:23:15 so for now, I think I'm stuck with grub2 Nov 17 00:23:16 is that a big deal (no UI)? Nov 17 00:23:30 fray, live images should have the option to install or boot right? Nov 17 00:23:46 we could just boot and have an install.sh command that can be run Nov 17 00:23:57 that's what everyone does with Fedora et all anyway nowadays Nov 17 00:24:12 eventually install is a nice goal -- but we don't have installer AFAIK.. Nov 17 00:24:23 we do Nov 17 00:24:38 what is the installer? Nov 17 00:24:41 this was leading me down the use grub2 for now path - unfortunately the GPLv3 issues means we could have no way to build an EFI bootable images for GPLv2 only builds Nov 17 00:24:56 dvhart I think that is acceptable -- as long as it's documented Nov 17 00:24:58 fray, yeah, we do now Nov 17 00:25:17 what program is the installer based on? and does it use package feeds, or just copy the live image down or? Nov 17 00:25:19 fray, which bit? using install.sh or not having a bootable gplv2 image? Nov 17 00:25:27 installer Nov 17 00:25:35 fray, I believe it copies the rootfs Nov 17 00:25:46 it's bare bones to say the least Nov 17 00:25:56 it's a simple script Samuel knocked up years ago Nov 17 00:25:59 ahh, ok.. so not an "installer" the way people are used to it on a desktop side.. but simply something that makes a system w/ a storage media functional Nov 17 00:26:13 affirmative Nov 17 00:26:33 ya.. I'd really like to get beyond that and use the package feed to create a live image & install media Nov 17 00:26:44 but that is a -long- term goal for me.. nothing we need to do "today" Nov 17 00:26:45 sure Nov 17 00:27:02 but I'm trying not to let "efi support" explode into more work than I can hope to accomplish :) Nov 17 00:27:26 ya.. for EFI "live boot".. IMHO GPLv3 is fine.. if someone wants something different they'll have to over come the limitation Nov 17 00:27:46 for "IA32 booting" we need a non GPLv3 solution -- but it doesn't have to be "live boot" IMHO Nov 17 00:27:55 i.e. it can be manual steps someone has to do Nov 17 00:28:39 then we can remove grub2 from the process once we have a syslinux family alternative Nov 17 00:28:49 that is reasonable to me.. Nov 17 00:29:01 so a remaining question is do we have separate live images, one for legacy and one for efi Nov 17 00:29:05 (I'm not a direct stake holder here though.. so definitely get a second opionion... but it's reasonable tome) Nov 17 00:29:05 or do we just build both Nov 17 00:29:24 at WR we have a single live image and require the BIOS booting facilities.. Nov 17 00:29:25 I'm leaning towards both by default as some boards actually have both depending on the firmware installed Nov 17 00:29:35 since you are intel, I'm not sure that is reasonable for you Nov 17 00:29:37 I have boards that won't have that Nov 17 00:29:46 especially the fastboot ones Nov 17 00:29:51 so I need a pure efi solution Nov 17 00:30:01 but fortunately, that can cohabitate with the legacy syslinux boot Nov 17 00:30:09 ya.. fastboot IMHO is "special".. so the BSP should say which bootloader to use and do whatever is necessary.. Nov 17 00:30:38 I see two scenerios.. you have a generic live media.. this generic media needs to be BIOS bootable -- since that is the majority of commodity machines.. (included EFI) Nov 17 00:31:04 the second is BSP specific boots.. the BSP owner should be able to set the proper machine flags to indicate EFI, BIOS, (or...) and the right output is generated Nov 17 00:31:11 generic media doesn't make a lot of sense to me since every image we build is for a particular BSP Nov 17 00:31:27 In the end this means you have to support both.. but it's up to the BSP to select one or the other Nov 17 00:31:45 does the MACHINE_FEATURES seem like the right mechanism? Nov 17 00:31:54 Not in Yocto -- but there is a general concensus -- due to Fedora, SuSe, etc that there is a "generic IA32 capable BSP" Nov 17 00:32:08 the bootloader is typically specified via EXTRA_IMAGEDEPENDS Nov 17 00:32:10 about that closest we have to that is qemux86(_64) Nov 17 00:33:06 or atom-pc Nov 17 00:33:27 well -- the other factor of this is that IA is somewhat unique in that bootloaders are needed in the constructed "images".. Nov 17 00:33:42 other systems generally have other ways to do booting (which usually require manual intervention) Nov 17 00:33:43 only sometimes Nov 17 00:33:58 I am doing manual intervention for the EFI systems I'm using now Nov 17 00:34:07 but yes, that's generally true Nov 17 00:34:19 and the live images, afaik, are x86 only Nov 17 00:34:27 ya.. Nov 17 00:34:28 ia32 I should say I guess Nov 17 00:34:50 ;) Nov 17 00:35:27 so I'm thinking I will need to modify bootimg.bbclass to be able to make a LEGACY or an EFI or BOTH image Nov 17 00:35:42 and those options can be specified via the MACHINE_FEATURES variable? Nov 17 00:35:54 so each BSP defines what the live image will look like? Nov 17 00:36:03 does that make sense? Nov 17 00:36:08 yes that makes sense to me] Nov 17 00:36:19 they will still have to specify the bootloader though Nov 17 00:36:28 or... hrm Nov 17 00:36:30 perhaps not Nov 17 00:36:30 (this is a comment, not asking you to implement this..) ;) Nov 17 00:36:43 do we have a way to build a live image with initrds? this is a use case that was a pain for us Nov 17 00:36:56 fray, yes Nov 17 00:37:11 we ended up implementing a build within a build.. the internal build built the initrd "image".. the outter build built the live image Nov 17 00:37:31 iirc we have initrd support now Nov 17 00:37:44 will know more after I get started hashing this out Nov 17 00:37:57 but can you build a live image that requires an initrd... (I expect bitbake can do this because it has better support for multiple target images) Nov 17 00:38:22 I'd have to look to get any more precise - otherwise I'd just be guessing Nov 17 00:38:59 like I said.. it's a somewhat unique use-case.. (something we should do --in the future--) Nov 17 00:39:11 point is.. don't preclude this in your implementation.. ;) Nov 17 00:39:19 ('er.. intentionally preclude it) ;) Nov 17 00:39:44 right Nov 17 00:40:02 ok, I'm going to write up an EFI Support Design / Roadmap and send it out for review Nov 17 00:40:51 sounds good Nov 17 00:42:28 hrm.. oe-core or yocto list.... hrm Nov 17 00:42:51 oe-core if it's base changes Nov 17 00:44:36 it's a little of both - and a lot less base changes than originally planned (I won't be trying to axe grub) Nov 17 00:44:52 so most changes are for meta-intel - but the basic infrastructure is oe-core I guess Nov 17 00:44:54 ok, oe-core it is **** ENDING LOGGING AT Thu Nov 17 02:59:57 2011