**** BEGIN LOGGING AT Wed Mar 03 02:59:58 2010 Mar 03 05:35:20 * kergoth sighs Mar 03 06:45:19 good morning Mar 03 06:46:27 mckoan|nurnberg: gm Mar 03 06:46:48 mckoan|nurnberg: are you at SuSE in Nurnberg ? Mar 03 07:18:41 man.. i love oe and all, but some days really make me want to completely revamp parts Mar 03 07:18:43 :\ Mar 03 08:56:29 03Koen Kooi  07org.openembedded.dev * r90a13cad56 10openembedded.git/recipes/apex/apex-env_1.5.14.bb: apex-env 1.5.14: turn of QA checks, adding LDFLAGS is too hard for this Mar 03 10:02:09 Hi Guys, I'm getting this (http://pastebin.ca/1820928) failure when I try to build, any ideas? Mar 03 10:13:34 morning Mar 03 10:14:19 03Marcin Juszkiewicz  07org.openembedded.dev * r4789ed2ce0 10openembedded.git/recipes/file/file.inc: Mar 03 10:14:20 file: package also magic files - spotted by Koen Mar 03 10:14:20 Signed-off-by: Marcin Juszkiewicz Mar 03 10:14:55 hrw, morning Mar 03 10:20:05 Hey, I know that it's not specific OE question but I have an embedded device which came with a ready kernel and rootfs image... when I compile a new kernel (even with bitbake virtual/kernel), all things work fine (shell, xorg, etc.. which are included in the ready rootfs), just my compiled HelloWorld doesn't work... Notice that the same HelloWorld works under the kernel that came with the embedded device... Apparently the problem is with crosstool which com Mar 03 10:20:05 pile for a specific kernel... any idea ? Mar 03 10:20:38 vadmeste: and you are talking about nhk15? Mar 03 10:20:53 yes Mar 03 10:21:30 and you got it with Poky preinstalled? Mar 03 10:21:38 yes Mar 03 10:22:30 show me "arm-linux-objdump helloworld" output via pastebin Mar 03 10:22:37 okey Mar 03 10:22:39 ^_^ Mar 03 10:24:04 vadmeste: "arm-linux-gnueabi-objdump -x helloworld |grep EABI" will be enough (use your objdump) Mar 03 10:24:20 okey Mar 03 10:26:37 actually, there are no output Mar 03 10:30:18 |grep 'private flags' then Mar 03 10:30:50 private flags = 2: [APCS-32] [FPA float format] [has entry point] Mar 03 10:30:53 and for future: do not mix toolchains. 'bitbake meta-toolchain' will give you standalone OE toolchain for you out-of-OE compiles Mar 03 10:31:04 private flags = 5000002: [Version5 EABI] [has entry point] Mar 03 10:31:08 see difference? Mar 03 10:31:23 your toolchain will not give you binaries for nhk15 system Mar 03 10:32:22 but how it comes it works under the ready kernel built by STEricc ? Mar 03 10:32:32 I mean my helloworld Mar 03 10:32:42 and I didn't mix toolchains Mar 03 10:32:50 euu sorry Mar 03 10:38:17 because Poky kernel has oabi support enabled Mar 03 10:38:20 OE do not enable it Mar 03 10:38:41 okey Mar 03 10:38:56 I just compiled my HelloWord with OE cross compiler and it worked Mar 03 10:40:34 good Mar 03 10:55:33 03Michael 'Mickey' Lauer  07org.openembedded.dev * reb7df07737 10openembedded.git/recipes/pulseaudio/ (pulseaudio_0.9.19.bb pulseaudio_0.9.21.bb): pulseaudio: demote 0.9.19 and 0.9.21 for motorola ezx series and openmoko devices Mar 03 11:03:39 die, busybox, die Mar 03 11:03:46 die busybox, die Mar 03 11:05:05 heh Mar 03 11:16:06 morning all Mar 03 11:16:39 morning PR Mar 03 11:16:45 hi RP as well Mar 03 11:57:45 still need to find few components Mar 03 12:38:00 hi OE asks me to install md5sumqemu. Is that a typo ("md5sum qemu")? Maybe a missing space in sanity.bbclass? Mar 03 12:38:50 03Mike Westerhof  07org.openembedded.dev * rb002cfb5d2 10openembedded.git/conf/distro/include/preferred-slugos-versions.inc: Mar 03 12:38:50 SlugOS: preferred-slugos-versions.inc: bump up libtool to latest version Mar 03 12:38:50 (Required by, at least, wireshark) Mar 03 12:39:51 typo Mar 03 12:40:56 ok, found it, sending a fix. Mar 03 13:08:58 morning all Mar 03 13:13:19 hi otavio & thank you for your supportive email :-) Mar 03 13:25:50 i am using OE stable with avr32. I am trying to port a new kernel and am having a small issue. I am getting an error at the do_staging step but there is no data in the logfile. I am not really sure where to begin to solve this problem Mar 03 13:26:23 03Martin Jansa  07org.openembedded.dev * rc852af3dc4 10openembedded.git/recipes/pango/ (pango-native-1.22.0/no-tests.patch pango-native_1.22.0.bb): (log message trimmed) Mar 03 13:26:23 pango-native: remove 1.22.0 as it's already provided by pango_1.22.0.bb thanks to BBCLASSEXTEND from .inc file, resulting package seems the same Mar 03 13:26:23 * list of included files is the almost the same (native from Mar 03 13:26:23 pango_1.22.0.bb doesn't have tests (as removed with no-tests.patch Mar 03 13:26:24 from pango.inc). Mar 03 13:26:24 * PR changed from r0 to r2 Mar 03 13:26:25 Signed-off-by: Martin Jansa Mar 03 13:26:27 03Martin Jansa  07org.openembedded.dev * r4f499f5ed9 10openembedded.git/recipes/efl1/efreet_svn.bb: (log message trimmed) Mar 03 13:26:27 efreet: include efreet_desktop_cache_create in main package, because it's needed for e-wm start Mar 03 13:26:27 * Without it will fail with: Mar 03 13:26:27 ESTART: 0.34227 [0.00036] - efreet Mar 03 13:26:27 sh: /usr/bin/efreet_desktop_cache_create: not found Mar 03 13:26:28 <<<< Enlightenment Error >>>> Mar 03 13:26:28 Enlightenment cannot initialize the FDO desktop system. Mar 03 13:26:29 03Martin Jansa  07org.openembedded.dev * r3cd9ddbfa1 10openembedded.git/recipes/libxml/ (4 files): Mar 03 13:26:30 libxml2: migrate -native to BBCLASSEXTEND Mar 03 13:26:42 NOTE: Running task 629 of 637 (ID: 9, /home/martin/avr32/oe/openembedded.modified/linux/linux_2.6.33.bb, do_populate_staging) Mar 03 13:26:42 NOTE: Running task 630 of 637 (ID: 18, /home/martin/avr32/oe/openembedded.modified/linux/linux_2.6.33.bb, do_devicetree_image) Mar 03 13:26:42 ERROR: function do_stage failed Mar 03 13:26:42 ERROR: log data follows (/home/martin/avr32/oe/tmp/work/atngw100-angstrom-linux-uclibc/linux-2.6.33-r55/temp/log.do_stage.13036) Mar 03 13:26:44 NOTE: Task failed: /home/martin/avr32/oe/tmp/work/atngw100-angstrom-linux-uclibc/linux-2.6.33-r55/temp/log.do_stage.13036 Mar 03 13:26:47 ERROR: TaskFailed event exception, aborting Mar 03 13:26:49 ERROR: Build of /home/martin/avr32/oe/openembedded.modified/linux/linux_2.6.33.bb do_populate_staging failed Mar 03 13:26:49 03Martin Jansa  07org.openembedded.dev * r8e37605e4f 10openembedded.git/recipes/libxml/libxml2_2.7.6.bb: Mar 03 13:26:49 libxml2: new version 2.7.6 Mar 03 13:26:49 Signed-off-by: Martin Jansa Mar 03 13:26:51 NOTE: Running task 631 of 637 (ID: 14, /home/martin/avr32/oe/openembedded.modified/linux/linux_2.6.33.bb, do_package) Mar 03 13:26:58 sh: avr32-angstrom-linux-uclibc-depmod-: command not found Mar 03 13:26:58 ERROR: Task 9 (/home/martin/avr32/oe/openembedded.modified/linux/linux_2.6.33.bb, do_populate_staging) failed Mar 03 13:27:32 it correctly applies the defconfig file, I am applying no patches, and the kernel is correctly built. I tested it and it boots. Mar 03 13:28:24 martinmeba: ~pastebin Mar 03 13:28:31 ok, should I alter coreutils etc packages to follow placement of binaries by busybox or change busybox? Mar 03 13:28:39 doesn;'t that work? Mar 03 13:28:41 ~pastebin Mar 03 13:28:43 [~pastebin] A "pastebin" is a web-based service where you can paste anything over 3 lines without flooding the channel. Here are links to a few : http://www.pastebin.com , http://pastebin.ca , http://channels.debian.net/paste , http://paste.lisp.org , http://www.rafb.net/paste Mar 03 13:29:06 ah better, tought it would also work if not at the start of the line Mar 03 13:29:16 ~lart ibot Mar 03 13:29:17 * ibot takes a rusty axe and swings it violently, taking effem's head off Mar 03 13:29:37 hm, ibot seems ill-tempered today Mar 03 13:29:51 03Koen Kooi  07org.openembedded.dev * rea8857e112 10openembedded.git/recipes/gperf/ (gperf-native_3.0.3.bb gperf_3.0.3.bb): gperf-native: convert to new style staging and BBCLASSEXTEND Mar 03 13:30:01 thanks, eFfeM - my kernel packages correctly now. I will use that instead Mar 03 13:31:06 hrw wrt midnight commander, never used it, does it compare opk's out of the box Mar 03 13:31:31 eFfeM: usually need one change in config to treat ipk as debs not as tarballs Mar 03 13:31:37 (really dislike manually run ar, then tar then some tree cmp) Mar 03 13:31:51 eFfeM: dpkg-deb -c file.ipk ;) Mar 03 13:31:54 ah ok, will give it a try Mar 03 13:32:23 hrw not sure my opensuse box at home has dpkg-deb Mar 03 13:33:05 eFfeM: bitbake dpkg-native ;d Mar 03 13:33:46 anyway, so do_stage fails. I feel like I am doing everything vanilla. I am trying to be as un-cute as possible. Here is the output:http://pastebin.com/WhfyrZa5 Mar 03 13:36:36 hrw, i think i'll give MC a try Mar 03 13:47:07 martinmeba: i suggest to look at /home/martin/avr32/oe/tmp/work/atngw100-angstrom-linux-uclibc/linux-2.6.33-r55/temp/log.do_stage.13036 Mar 03 13:47:39 eFfeM: I did. It is empty. That is why I am stumped. Mar 03 13:47:47 ah ok Mar 03 13:48:25 the answer is on the next line in the log: sh: avr32-angstrom-linux-uclibc-depmod-: command not found Mar 03 13:50:40 eFfeM: I don't understand that error. How could it build another kernel - say 2.6.24, but not this one? Wouldn't they both need the same command? Mar 03 13:52:53 the - after depmod is odd, not sure where it comes from but I suggest to compare the run.do_stage files of a working and non working version Mar 03 13:53:23 eFfeM: thanks for the help. I will give it a try. best regards Mar 03 13:56:12 the working version calls avr32-angstrom-linux-uclibc-depmod-2.6 while the non-working version calls avr32-angstrom-linux-uclibc-depmod- - interesting Mar 03 13:58:48 so there is an issue with your cross chain and somewhere the kernel major version is not postfixed, no idea who does that as I have no uclibc or avr experience Mar 03 13:59:14 http://hrw.pastebin.com/4dvw262X - busybox hack Mar 03 13:59:29 what do you mean "not postfixed"? Mar 03 14:00:20 martinmeba: how the hell did you get linux 2.6.33 to compile for the atngw100? Mar 03 14:00:51 XorA: it was not too bad. Atmel finally pushed all of their patches upstream as of 2.6.30 Mar 03 14:01:04 XorA: why he could not? Mar 03 14:01:08 martinmeba: 2.6.30 onwards are all broken for me Mar 03 14:01:17 I just randomly picked 2.6.33 - I should have picked 2.6.32 so I could use the dev recipe Mar 03 14:01:31 i have been building it out of the tree with the oe stable toolchain Mar 03 14:01:32 due to rcall being made call and the assembler overflowing the assigned space Mar 03 14:01:42 I was trying to put it into the stable tree Mar 03 14:01:51 i also got the newest samba to work Mar 03 14:02:00 i was hoping to clean everything up and submit the patches Mar 03 14:02:10 * XorA cries Mar 03 14:02:44 hrw: you can get it to build too? Mar 03 14:03:00 I do not have avr32 toolchain now Mar 03 14:03:05 I have it running on my atngw100 right now Mar 03 14:03:16 * XorA cries some more Mar 03 14:03:32 mine atngw100 is in soltys's hands Mar 03 14:03:44 martinmeba: any oopses on mount? Mar 03 14:03:55 no Mar 03 14:04:02 i will paste the boot output and send you a link Mar 03 14:04:13 * XorA wonders what the difference is then Mar 03 14:04:43 it really does not compile here, and when I revert the patch that stops compile it doesnt run stable Mar 03 14:05:04 martinmeba: you wouldnt be on a 32bit host would you? Mar 03 14:05:10 yes Mar 03 14:05:18 * XorA swears Mar 03 14:05:45 guess its time to learn kvm then Mar 03 14:07:10 martinmeba: I have been working on this for 2 days now :-( Mar 03 14:09:03 and sorry - it is 2.6.32, not 33 - I went up a version somewhere... Mar 03 14:09:04 http://pastebin.com/BTDqWtZ9 Mar 03 14:09:25 * XorA has 2.6.33 booted Mar 03 14:09:33 yes Mar 03 14:09:38 but there are some serious problems with mounting Mar 03 14:09:43 i can't find the log with that one Mar 03 14:09:51 and it doesnt compile without me reverting a patch Mar 03 14:09:59 no kernel since 2.6.29 compiles for me Mar 03 14:10:17 * XorA is suspecting atmel toolchain has 64bit issues if yours works fine Mar 03 14:10:32 XorA: I would think so as well Mar 03 14:10:45 I understand that there are several nagging gcc issues with the avr32 arch Mar 03 14:12:14 well it seems atmel stopped with support as its never updated anymore Mar 03 14:12:47 yeah - it is such a bummer. I just noticed that they marked the part as not suitable for future product development on their website Mar 03 14:14:24 * XorA wonders on the quickest way to get 32bit bost Mar 03 14:14:26 host Mar 03 14:19:24 hello: I'm trying to put opencv in my toolchain, the package is added to the RDEPENDS and built, but then the meta-toolchain fails at populating the sdk Mar 03 14:19:35 satisfy_dependencies_for: Cannot satisfy the following dependencies for task-mobots-toolchain-target: Mar 03 14:19:35 * opencv * opencv (= 2.0.0+svnr2219-r0.5) * Mar 03 14:20:06 XorA: Virtualbox Mar 03 14:20:42 hrw: Im just checking if I can actually free up enough disk space for 2 OE installs :-) Mar 03 14:21:03 I guess that's because the openCV recipe does not produce an opencv.ipk Mar 03 14:23:34 XorA: 20GB is enough for VM Mar 03 14:23:45 how can I tell in my sdk recipe that the opencv recipe must be used for build and then the libcv*.ipk must be installed ? Mar 03 14:23:53 hrw: yeah I know, just really tight on disk space at the moment Mar 03 14:24:32 it must be possible to use local dir in vm Mar 03 14:25:19 XorA: yeah - use virtual box and map in your oe dir Mar 03 14:26:07 die busybox, die! Mar 03 14:26:44 I wonder what's difference between virtualbox and kvm Mar 03 14:26:55 I mean in performance Mar 03 14:27:28 should be little if both are using the virt extensions Mar 03 14:27:34 no idea - i don't know my way around kvm very well - i mainly use virtualbox because of windoze at work Mar 03 14:28:24 speaking of which, I am off to firewalled-work. thanks for the help, everyone. Mar 03 14:28:27 on my machine VM uses one core only Mar 03 14:31:56 hm, I've seen some option to assign both cores to kvm/qemu Mar 03 14:33:39 03Koen Kooi  07org.openembedded.dev * rf88f6869a9 10openembedded.git/recipes/xorg-lib/pixman_git.bb: pixman git: update to 0.17.8 + flags branch to test upcoming 0.18.x RCs Mar 03 14:38:39 ~tell martinmeba about pastebin Mar 03 14:39:01 (just showing the ibot feature, since someone was wondering about directed answers) Mar 03 14:40:56 only 40 symlinks to busybox in final image Mar 03 14:46:01 hrw: heh, you working on a "full versions of the utils" image? Mar 03 14:47:22 kergoth: yes Mar 03 14:47:37 nice, I'm sure lots of folks would find such a thing useful :) Mar 03 14:47:43 kergoth: and looks like my next build will be busybox free so will have to boot it finally Mar 03 14:48:14 kergoth: 6 years ago I was first which booted OE image on device. now I do that without busybox... Mar 03 14:48:33 s/booted/booted working/ Mar 03 14:49:09 meh Mar 03 14:49:26 I still don't have CF crap working on my sbc6020 :( Mar 03 14:53:15 wow.. busybox-free.. that could be interesting, I'm sure there are still things we don't have the full versions of, or at least don't fully support both versions (i.e. initscripts, update-alternatives usage) Mar 03 14:54:53 I know that so far content of image looks stranve Mar 03 14:55:24 as I had to add dpkg to get start-stop-daemon Mar 03 14:55:57 huh Mar 03 14:56:06 strange indeed. Mar 03 14:56:30 * kergoth is debugging a really, really strange pstage problem :\ Mar 03 14:57:30 I'm also finding myself wanting a post-build analysis tool, but I think bitbake would have to emit more information Mar 03 14:57:51 it would be lovely if you could point at a tmp dir and say.. what built, what failed, what used pstage packages, what built from scratch, what images were produced, ... Mar 03 15:00:16 hello, what are the first steps if a task fail? Mar 03 15:00:28 are there log files around? Mar 03 15:00:34 i do have: ERROR: '/home/hanibal/oe/openembedded/recipes/gdb/gdb-cross-sdk_6.8.bb' failed Mar 03 15:00:36 it gives you the path to the log when the task fails Mar 03 15:00:44 look up a couple lines from that Mar 03 15:02:41 ah, right, thank you, kergoth Mar 03 15:02:50 heh Mar 03 15:06:03 * hrw -> out Mar 03 15:33:52 03Martin Jansa  07org.openembedded.dev * r8a7dc51327 10openembedded.git/recipes/ (3 files in 2 dirs): Mar 03 15:33:52 shr: use numeric-alt keyboard in illume* config and default-numeric only in feed Mar 03 15:33:52 Signed-off-by: Martin Jansa Mar 03 15:41:36 JaMa? Mar 03 15:42:09 pong Mar 03 15:42:22 Hi, Tom Rini here :) Mar 03 15:42:32 qemu/qemu-arm? :) Mar 03 15:42:36 Yeap Mar 03 15:42:39 See my reply? Mar 03 15:42:54 no.. mmt Mar 03 15:43:27 now.. yes Mar 03 15:43:40 k Mar 03 15:43:42 So, ideas? Mar 03 15:44:11 Tartarus: I'm not complaining about qemu usage (as I was also thinking about qemu-mips or what ever is used for other targets ... so qemu is probably better check then qemu-arm ie in case building for mips) Mar 03 15:44:38 Right. But is there some 'always there' qemu binary we can check for? Mar 03 15:44:48 maybe OR would be best to check qemu||qemu-arm||qemu-mips Mar 03 15:45:05 and then expect that whoever used ASSUME_PROVIDED was aware of what he needs Mar 03 15:45:11 too fragile.. Mar 03 15:45:22 * kergoth poners Mar 03 15:45:22 And it'd have to be hard-coded Mar 03 15:45:24 * kergoth ponders, too Mar 03 15:45:30 0.10.x does qemu-ppc not -powerpc Mar 03 15:45:31 in gentoo is no 'alwasy there' I would say :) Mar 03 15:45:50 JaMa, qemu-img maybe? Mar 03 15:46:10 Tartarus: cannot you use the same logic which choose qemu-arm in *libc in this sanity check? Mar 03 15:46:47 Tartarus: but yes I have qemu-img too Mar 03 15:46:52 hmm Mar 03 15:46:59 We could copy/paste that logic Mar 03 15:47:03 or maybe pull out Mar 03 15:47:29 Tartarus: and I always had "qemu" too, but with that minimalistic chroot I'm using now.. I built "minimal" qemu for my needs and missing qemu binary is side-effect of minimalism :) Mar 03 15:47:41 Yeah Mar 03 15:48:07 I almost want to make a qemu.bbclass for the gcc stuff, and now this target arch fun Mar 03 15:48:14 So I'll go post something in a min Mar 03 15:48:40 I'm looking forward for 0.12* version.. because it doesn't need minimal mmap == 0 Mar 03 15:49:16 and with 2.6.33 on buildhost it's even possible to test if mmap == 0 (and error is now silenced in sanity check now) Mar 03 15:50:05 and that's the reason why I started to use ASSUME_PROVIDED qemu-native again.. Mar 03 15:53:52 btw: did someone noticed /usr/lib/ipkg -> /usr/lib/opkg link? I was checking what is responsible for creating it and didn't found it/commit Mar 03 15:56:45 and this is in opkg-ipkg-compat: ln -sf /var/lib/ipkg ${D}/var/lib/ipkg, does it makes sense to you? Mar 03 16:00:20 Hmm Mar 03 16:00:31 What's a board in oe.dev today that binary locale stuff happens for? Mar 03 16:00:40 sane-toolchain.inc turns it off on arm v7/v6 Mar 03 16:00:55 (and if minimal doesn't work as a distro for it, distro too pls) Mar 03 16:01:45 Tartarus: AFAIK usually enabled from local.conf ( I use it that way for angstrom and SHR is using it too) Mar 03 16:02:14 So it might just work anyhow on v7? ok Mar 03 16:02:17 Tartarus: and IIRC it was also written in local.conf.sample Mar 03 16:02:40 Yeah, I have it of Mar 03 16:02:40 Tartarus: never tried on v7/v6 ( I have only v5 and v4) Mar 03 16:02:41 f Mar 03 16:02:45 Never works for me Mar 03 16:02:47 heh Mar 03 16:02:51 What machine do you build for? Mar 03 16:02:58 om-gta02, spitz Mar 03 16:03:02 k Mar 03 16:03:04 i'll try spitz Mar 03 16:03:21 and what doesn't work for you on it? Mar 03 16:03:36 binary locale generation Mar 03 16:03:40 always blows up Mar 03 16:03:43 no packages created or it's not created properly? Mar 03 16:03:48 But then again, I usually care about armv6 or armv7 Mar 03 16:03:59 or mips Mar 03 16:04:06 or not arm pre v6, basically :) Mar 03 16:04:23 :) Mar 03 16:08:02 ok, bitbake -e confirms that locale stuff would be generated Mar 03 16:08:06 bitbake'ing virtual/libc Mar 03 16:08:22 (no assume provided stuff, but this change does change glibc-package.bbclass a bit) Mar 03 16:09:02 Tartarus: I guess you have 0 in minimal mmap Mar 03 16:09:16 yeah Mar 03 16:10:47 NOTE: :too many values to unpack while evaluating: Mar 03 16:10:47 ${@base_version_less_or_equal("KERNEL_VERSION", "2.6.17", "", "apm-wifi-suspendfix", d)} .. wtf Mar 03 16:12:15 hmm I've seen something like this too Mar 03 16:12:37 but then it disappeared so I cannot check it properly Mar 03 16:12:55 weird Mar 03 16:12:57 kergoth: there was problem in kernel_version.bbclass for detecting KERNEL_VERSION from sources Mar 03 16:13:10 kergoth: I've fixed it for 33-rc* versions Mar 03 16:13:20 ah Mar 03 16:13:24 kergoth: but maybe it's somehow broken again Mar 03 16:13:42 probably just using an odd machine, just doing test builds with 'x86' :) Mar 03 16:13:49 kergoth: but for some strange reason it worked in my test (disappeared) before pushing 2.6.33 Mar 03 16:14:49 apm-wifi-suspendifx... it was for cf/pcmcia ones? Mar 03 16:15:56 hrw: it was for ones such as prism3 that lost their firmware when they powered down on suspend Mar 03 16:16:51 old times Mar 03 16:18:57 03Martin Jansa  07org.openembedded.dev * re6e884c834 10openembedded.git/conf/distro/include/sane-srcrevs.inc: Mar 03 16:18:57 shr-launcher: fix SRCREV Mar 03 16:18:57 * no idea what's revision from 732af689fae49fb80e184f2a31c6bdba3f210f11 Mar 03 16:18:57 but for svn recipe it's clearly wrong, 103 is latest Mar 03 16:18:57 Signed-off-by: Martin Jansa Mar 03 16:19:11 * kergoth ponders Mar 03 16:19:37 * kergoth starts writing up a proposal for a pstage revamp Mar 03 16:21:40 kergoth: in what cases is pstage usefull? I mean I'm doing rebuild from scratch usually for DISTRO_PR bump, moved tmp or to force that newer gcc is used for all recipes already built, can I use pstage in any of this cases? Mar 03 16:22:27 the first two. cases where the binaries are still usable. at least, once you work out the relocation kinks, which has been worked on by a number of people Mar 03 16:22:40 but its useful even when you aren't rebuilding from scratch fromt eh packages Mar 03 16:23:06 because a do_clean can just uninstall the package from staging, avoids problems with multiple versions of something in there at once too, i believe Mar 03 16:23:22 (to a certain extent, anyway) Mar 03 16:23:40 kergoth: thanks for clarification Mar 03 16:28:56 JaMa: pstage is useful if you want to check does your recipes have all deps Mar 03 16:29:19 you remove all from tmp except pstage and do build Mar 03 16:29:46 heh, indeed, one rogue dep leaks in and it links against something it doesn't depend on.. boom. excellent point, didn't think about that as a feature ;) Mar 03 16:30:22 kergoth: I rather used it for finding missing ones Mar 03 16:30:44 http://marcin.juszkiewicz.com.pl/2008/07/01/packaged-staging-and-what-it-gives/ Mar 03 16:31:02 * Tartarus scrolls up Mar 03 16:31:20 nice post, maybe i'll just link to that.. I was going to write up what is it / how it works / why it should be default in the beginning of my proposal Mar 03 16:32:00 kergoth: Make sure you reply to my email just now with your proposal linked ;) Mar 03 16:32:08 will do Mar 03 16:32:20 it may take me a bit, I don't write enough.. Mar 03 16:32:27 * kergoth is so rusty at things > one paragraph Mar 03 16:32:29 hehe Mar 03 16:32:32 hrw: tmp/* except pstage? so also rootfs/stamps/!cache!? Mar 03 16:32:37 twitter and IM have ruined me! Mar 03 16:32:47 JaMa: Yeah Mar 03 16:32:56 I've got pstage outside of tmpdir Mar 03 16:33:04 denix iirc deploy outside of tmpdir Mar 03 16:33:06 * kergoth hugs WriteRoom Mar 03 16:33:13 Both are/should be valid cases Mar 03 16:33:22 Tartarus: so be carefull about cache when we switch to SRCPV :) Mar 03 16:33:40 And in ours at least, the hard part comes from also having tmpdir change name each time I did my big iterative test Mar 03 16:33:55 (relocation is just annoying due to annoying upstream programs, really... ;)) Mar 03 16:34:29 hrw: I've read that blog entry and it's good, but I didn't think of using it for deps check, thanks Mar 03 16:34:35 hmm. Mar 03 16:35:12 I wonder if anyone in other distros (and autopackage-type folks) would be interested in getting together to start an effort to properly make upstream apps relocatable in ways that upstream would consider accepting Mar 03 16:35:19 hrw: only catches critical deps, not implicit ok if it's not there ones tho :( Mar 03 16:36:06 hrw: and all other rebuild from scratch reasons look to me that I usually want to really rebuild it as DISTRO_PR is usually bumped for good reason and moved tmp I usually resolve with mount --bind in old location Mar 03 16:36:15 hrw: but that deps check is nice Mar 03 16:36:33 I plan to test a private staging implementation on top of what I propose we do about pstage, eventually Mar 03 16:37:12 kergoth: I suspect there would be people interested in that effort Mar 03 16:37:18 * kergoth still thinks private staging areas with caching is a good route to make builds more deterministic Mar 03 16:37:28 ok, time to upgrade bug to busybox-free system Mar 03 16:37:40 kergoth: during FOSDEM send-patches.org was mentioned as a gathering point Mar 03 16:38:10 * kergoth looks Mar 03 16:38:16 hrw: why? Mar 03 16:38:24 incandescant: and then that guy with 'forget crosscompiling, we have 8core 23GHz arm cpus now' came ;( Mar 03 16:38:35 JaMa: experiment Mar 03 16:38:36 hrw: I hate busybox.. so I'm just interested for reasons why I should remove it too Mar 03 16:38:54 hrw: yeah, that was a real downer :-( Mar 03 16:39:33 JaMa: omap3 has power, bug* has 2GB microsd for rootfs so why not Mar 03 16:39:49 hrw: Andy Green by any chance? Mar 03 16:40:07 I can see wanting to do all native development when doing active development on a kernel or app or something, but for distro level builds, i prefer cross, personally Mar 03 16:40:14 broonie: yes ;( Mar 03 16:40:17 it's the same Andy Green, who worked for openmoko? Mar 03 16:40:20 yes Mar 03 16:40:44 He wrote Qi there and now thinks we should all be booting from SD cards and running Fedora. Mar 03 16:40:52 * kergoth twitches Mar 03 16:41:25 broonie: yeah, I know about Qi and seen something about Fedora, that's why I was wondering if it's really the same guy :) Mar 03 16:41:32 I mean, I think Debian ARM is a great thing for certain applications but I can't see things like phones even finding space for the SD card. Mar 03 16:41:37 heh Mar 03 16:41:54 and how to put Debian on 64MB flash Mar 03 16:42:00 JaMa: When he was at OM ge got really pissed off with using OE since he seemed to run into lots of hassle buuilding it nobody else seems to. Mar 03 16:42:49 broonie: well with his "8core 23GHz" I would also think about building natively ;) Mar 03 16:42:54 So it's not just me that finds people that break OE in otherwise impossible ways? :) Mar 03 16:43:32 * JaMa still hopes that 23GHz is typo and it's 2,3GHz :) Mar 03 16:44:02 JaMa: that "8core 23GHz" was my addon Mar 03 16:44:18 I'd like a 23Gz embedded processor... as long as it doesn't radiate a thousand watts! Mar 03 16:44:24 Tartarus: Is it really people finding impossible ways or taking simple instructions and interpretting them as something else? Mar 03 16:45:21 hrw: good one :) Mar 03 16:45:45 army of bugs sounds good too :) Mar 03 16:47:08 anyway I am waiting for armv7a 12" laptop with 1GB ram Mar 03 16:47:22 hi, I always lag behind mails and often read them in a burst, so I shurely missed angstrom migration to /etc/shadows Mar 03 16:47:47 what can I do to migrate a machine to /etc/shadow without reinstalling Mar 03 16:49:10 sulogin doesn't work(no password entry for root),passwd says that /etc/shadow is not present so it uses /etc/passwd Mar 03 16:49:47 hrw, hi,waiting means that it's not out already or that it's curently shiping and has not arrived yet Mar 03 16:50:26 I bet it's the fist thing Mar 03 16:51:40 I did not saw any of such ones on a market yet Mar 03 16:51:50 ok Mar 03 16:51:59 touchbook has 512M but...it's very fragile Mar 03 16:52:00 ReaperOfSouls: I suspect both, though a fair bit of the latter remains our fault, due to weak documentation, lack of discoverability, etc :) Mar 03 16:52:10 I still don't think you wnat to compile natively on an arm7a, 1Ghz or not Mar 03 16:52:23 there are mips laptops with 1GB ram but they consume a lot Mar 03 16:53:43 ReaperOfSouls: Well, did you ever have tlbmiss break things? :) Mar 03 16:53:58 netwalker also has 512M but it's small Mar 03 16:54:07 (the laptop size is small) Mar 03 16:54:17 CosmicPenguin - I set up native compile on the Beagleboard; did gPhoto2, libgphoto, and Imagemagick with success. Mar 03 16:54:35 so,any clue for /etc/passwd->/etc/shadow migration? Mar 03 16:54:48 It just feels wrong Mar 03 16:55:01 its never that you couldn't, it that you shouldn't.. :) Mar 03 16:55:13 You could natively compile on a Geode too, but you would be foolish to do so Mar 03 16:55:43 GNUtoo: and it is 8.9" not 12" Mar 03 16:56:00 ok Mar 03 16:56:26 Tartarus: not i years for obvious reasons..:) Mar 03 16:59:30 :) Mar 03 17:04:23 * hrw off Mar 03 17:08:07 Hmm Mar 03 17:08:14 I wonder if binary locale stuff works w/ eglibc right now Mar 03 17:08:19 * Tartarus undoes all his stuff and tries again Mar 03 17:16:15 I'll bitbake shadow as soon as I've made some space on my build system Mar 03 17:19:13 RP, Tartarus, CosmicPenguin, ReaperOfSouls, whomever else: would appreciate a glance at the proposal I just threw out :) Mar 03 17:19:21 (no rush, just a pointer) Mar 03 17:20:23 gPhoto2 version 2.4.8 has been for a while; the gphoto2 recipes appear to still be topped at 2.4.7. Mar 03 17:23:29 03Koen Kooi  07org.openembedded.dev * r8538297f89 10openembedded.git/recipes/libxslt/ (3 files): libxslt 1.1.22: convert to new style staging and BBCLASSEXTEND=native Mar 03 17:23:39 03Koen Kooi  07org.openembedded.dev * r2e518a1a8f 10openembedded.git/recipes/libxml/libxml2.inc: libxml2: readd binconfig inherit that went missing Mar 03 17:23:51 What's the preferred community route to get 2.4.8 in? Mar 03 17:23:54 robtow: time to make a recipe for the new version then (or rather, cp it) Mar 03 17:24:18 once the recipe works, mail a patch to the list Mar 03 17:24:29 kergoth - roger. wilco. Mar 03 17:24:46 I want to get that into the Gumstix builds. Mar 03 17:25:17 I natively compiled 2.4.8 for Beagleboard; time to do it the "right" way. Mar 03 17:25:21 Thanks Mar 03 17:25:38 version bumps tend to go in pretty fast, afaik, unless there's obvious breakage.. though "pretty fast" is relative Mar 03 17:25:44 np Mar 03 17:26:33 crap, this works before my change Mar 03 17:26:35 Hate that :) Mar 03 17:28:14 * Tartarus hopes he spots why Mar 03 17:44:15 kergoth: I've put some ideas back ;-) Mar 03 17:59:37 RP: install *is* special, though. There's no benefit to caching intermediate output when you can get the end result instead. Mar 03 18:00:23 RP: heh, I have this thing I was playing with, it put all of WORKDIR under a git repository, and tagged each task, so you can look through the log and see exactly what happened Mar 03 18:00:32 could use something like that for this. Mar 03 18:01:32 and you seem to be ignoring the fact that I said deploy can come from the archive. either the recipe can do it in a subsequent task or an image can grab it itself Mar 03 18:02:12 and of course, in my proposal, pkgdata is a nonissue, since it doesn't cache packaging. you're right that in your more generic proposal that it would be a concern Mar 03 18:03:09 * kergoth ponders Mar 03 18:04:14 kergoth: I don't see why I should run all the packaging tasks again rather than have cached versions of the packages Mar 03 18:04:32 kergoth: do_install is no more or less special than do_package_write_ipk Mar 03 18:04:38 of course it is Mar 03 18:04:51 but this comes back to the separation of responsibilities that you always argue against Mar 03 18:05:04 kergoth: do_install output is of course shared by several further steps Mar 03 18:05:15 but it is no more or less special Mar 03 18:05:34 I strongly disagree. Mar 03 18:05:46 kergoth: to build an image you seriously think having to build a load of .ipk files first is useful? Mar 03 18:06:18 Well, I also intend to allow the image to only generate the ipks you want for the image. Mar 03 18:06:32 kergoth: obviously but even so... Mar 03 18:06:46 sorry, I need to go :( Mar 03 18:07:11 install is special because it's the final output of the upstream buildsystem. *Everything* else comes from that, and everything before it is intermediate output which is of limited used Mar 03 18:07:13 s/d$// Mar 03 18:10:47 not so bad - busybox-less system booted into X11 but complained a lot during boot Mar 03 18:13:27 some question: does busybox's init support shadow? Mar 03 18:13:42 because /sbin/init.sysvinit seem to work a lot better Mar 03 18:13:53 GNUtoo: busybox init is very simple Mar 03 18:15:50 ok Mar 03 18:21:54 busybox init isn't usable really outside of special purposes Mar 03 18:21:56 imho Mar 03 18:23:16 XorA: still think i'm going at this backwards? Mar 03 18:23:55 XorA: Also, ping about my firefox patches Mar 03 18:24:04 shit Mar 03 18:24:20 someone remember how to set mac address of ethernet card from kernel cmdline? Mar 03 18:24:21 Tartarus: firefox I dont really care enough, Ive hurt my brain enough debugging it over the years :-( Mar 03 18:24:43 03Koen Kooi  07org.openembedded.dev * rb9601a21e7 10openembedded.git/recipes/gnome-mplayer/gecko-mediaplayer_0.9.8.bb: gecko-mediaplayer: bump PR so postinst picks up firefox 3.6 Mar 03 18:24:45 XorA: heh, k Mar 03 18:24:46 Tartarus: your assuming anyone even cares about a new stable, this is a problem as very few do Mar 03 18:25:02 XorA: Yes, I am assuming there's going to be another one done "soon" Mar 03 18:25:06 * hrw|gone wants new stable Mar 03 18:25:08 But I forget where I read that Mar 03 18:25:23 Tartarus: then you need to gather support and do it yourself most likely Mar 03 18:25:36 heh.. Mar 03 18:25:38 Tartarus: otherwise your beard will reach ankles :-) Mar 03 18:26:09 XorA: My concern really, wrt these changes is that outside folks or even big inside folks like angstrom might not like to deal with the breakage Mar 03 18:26:18 But we'll see I guess Mar 03 18:26:23 Angstrom is actually almost ready for one, but cant give definite deadline when we find those last few bugs Mar 03 18:26:41 * Tartarus needs to figure out if he'll have time to do one of these himself, or just give one to kergoth and maybe something else to some other internal folks Mar 03 18:27:00 Angstrom is resilient :-) Mar 03 18:27:12 We can't keep avoiding breakages forever, we'll never make progress :) Mar 03 18:27:20 on with the breakage! *cheers* Mar 03 18:28:10 just do what we always did, tag before Mar 03 18:29:14 RP: okay, replied to your comments, please let me know what you think, I'd really like to get started on this as soon as I can either get Mentor to pay me for it, or find the time on a weekend :) Mar 03 18:29:23 heh Mar 03 18:29:33 Figure out that pstaging issue I gave you :) Mar 03 18:29:49 XorA: s/tag/branch? :) Mar 03 18:29:57 kergoth: I'm due to head to the US in 11 hours so the timing isn't going to work too well Mar 03 18:30:14 np, not like I need a response today or anything :) Mar 03 18:30:20 Tartarus: tag, someone later can always do a branch from that tag point Mar 03 18:30:32 I might just start playing around with the task tracking and stuff on my own again, it was fun to experiment with Mar 03 18:30:44 (in the meantime) Mar 03 18:31:01 Tartarus: the pre-breakage tag is traditional and seperate from make a new stable Mar 03 18:31:07 RP: where to in the US, out of curiosity? Mar 03 18:31:16 kergoth: Portland - Intel stuff Mar 03 18:31:20 ahh cool Mar 03 18:31:28 * kergoth should meet his coworkers at mentor someday Mar 03 18:32:32 kergoth: I think we mainly just disagree about the do_install thing although your reply hasn't made it here yet Mar 03 18:32:44 kergoth: heh... common problem. it took nearly year for me to meet all OH guys at OH times Mar 03 18:32:49 kergoth: I only have say 10 mins here but I can talk a little further if you want Mar 03 18:33:09 RP: http://news.gmane.org/find-root.php?message_id=%3cb6ebd0a51003031028q1b948bb4y2e40d734252f0fb6%40mail.gmail.com%3e Mar 03 18:33:35 The bottom two paragraphs I try to summarize the disagreement and give thoughts on how to proceed Mar 03 18:33:42 erm, one paragraph Mar 03 18:33:53 * kergoth really needs to spend some time practicing his writing Mar 03 18:34:46 JaMa: still in? Mar 03 18:36:00 yup Mar 03 18:37:11 kergoth: I can't write a response to that in the time available Mar 03 18:37:37 np Mar 03 18:38:15 Well, I'm certain we can work out the details Mar 03 18:38:35 I wish we had more folks to participate in this sort of discussion, it seems like stuff like this always comes down to a few of us :) Mar 03 18:38:46 kergoth: I know this is pushing slightly to an extreme but to me this reads as "we should drop to a model where there is one task", then we know the inputs and the outputs. Mar 03 18:38:57 ok, bye for sure now Mar 03 18:39:26 kergoth: like your previous proposal to merge patch/configure/compile tasks Mar 03 18:40:11 I think the tasks should remain, just the caching should treat unpack through install as being the recipe's primary responsibility. Mar 03 18:41:00 kergoth: Its a responsibility but it ignores package splitting and assumes all knowledge is part of "make install" Mar 03 18:41:18 and deploy and any other "output" which we might generate Mar 03 18:41:27 No, it doesn't. Mar 03 18:41:32 those other things can all go based on do_install's output Mar 03 18:41:48 kergoth: some of them are not based on it Mar 03 18:41:58 what part of "can" do you not grasp? Mar 03 18:41:59 kergoth: QA stuff probes config.log Mar 03 18:42:13 config.log is not part of do_install Mar 03 18:42:30 That's a pre-install task Mar 03 18:42:33 nor should it be, nor should the config.log check be a part of the packaging, it can be done as a post-configure check Mar 03 18:42:33 Or would need to be Mar 03 18:42:35 exacxtly Mar 03 18:42:37 blah, exactly Mar 03 18:43:04 make install sometimes doesn't install the zImage but is used by do_deploy Mar 03 18:44:56 It should Mar 03 18:44:57 RIght, so fix that. Mar 03 18:45:09 kernel is totally busted for pstaging right now Mar 03 18:45:20 And if we redo things, we should make stuff work from packages for the kernel Mar 03 18:45:21 and uboot Mar 03 18:45:32 and any other similar case Mar 03 18:46:30 fuck, gmail is archiving new mails on this thread even though its not muted :( Mar 03 18:46:54 I'm not making my point clearly and have way too much on to try and do so Mar 03 18:47:18 I'll reply to the email when I get a chance Mar 03 18:47:58 * XorA is off Mar 03 18:48:36 Perhaps a silly question. Is there any reason not to just add the install directory to the current pkged-staging bits? it will double the size cost, but should hit both issues. Mar 03 18:49:52 Adding the install directory is something that would be easy to do and effective Mar 03 18:50:22 People already fail to get their head around pstaging, hacking more crap onto the end of it isn't going to clean things up Mar 03 18:50:57 it also doesn't solve the headaches surrounding stagefile and the inability to have full control over the layout of the tmpdir paths Mar 03 18:51:05 kergoth: I've said before I hate the thing Mar 03 18:51:12 If I could have done it differently I would have done Mar 03 18:52:01 many reasons for it including the need to make it optional, the need to build on what we already had, finding corner cases the code didn't orginally cover Mar 03 18:52:10 I think you may be taking this too personally. I think your work was a great move for the project, and added a much needed feature at a good time, I'm not trying to bash the thing, but its clearly grown to be a mess Mar 03 18:52:16 right, thats what I figured Mar 03 18:52:40 Hmm Mar 03 18:52:44 I don't disagree with that but I'm also not sure a rewrite from scatch is going to help that much Mar 03 18:52:50 Roman K in here? Mar 03 18:53:06 We can't get adoption of the new staging now, let alone a totally new implementation Mar 03 18:53:38 RP: New style staging is coming along Mar 03 18:53:44 yes, with a per recipe change like that, of course its going to take time Mar 03 18:53:53 And part of how kergoth wants the new impl to be, how i read, it's not opt-in Mar 03 18:53:58 you can't get out :) Mar 03 18:54:04 Tartarus: I know Mar 03 18:54:41 Tartarus: is the new implementation going to need per recipe changes? If not, that'll be a good thing. Building off whats taken years to pull off :) Mar 03 18:54:44 I know you want to retain massive flexibility, stay with the task concept, whatever, but caching per task is just going to confuse people more than they already are Mar 03 18:55:08 I don't expect many recipe changes would be necessary. The few using deploy, probably Mar 03 18:55:09 kergoth: I said optionally per task Mar 03 18:55:25 kergoth: I don't see it being needed for any task that doesn't generate output Mar 03 18:55:45 kergoth: so it would only cover install/package/package_write_*/deploy Mar 03 18:55:59 kergoth: and stuff like packagehistory Mar 03 18:56:02 right, and as I said in the email, I think we can build that as a subsequent task Mar 03 18:56:32 I just don't see the need for those things to depend upon the tasks prior to install Mar 03 18:57:20 * kergoth thinks about what would be involved for the granular caching Mar 03 18:59:14 kergoth: I don't think I said they needed to depend on tasks prior to install? Mar 03 18:59:25 depending on what you mean by depend Mar 03 18:59:29 well, you were just arguing that do_deploy tasks require files from compile Mar 03 18:59:43 I'd call that a "dependency", but maybe you have a different definition Mar 03 19:01:50 kergoth: so you're saying any task after do_install must only use the output from do_install? Mar 03 19:02:48 If we go with that I proposed, yes. I proposed that that was the main output of the recipe, and that all subsequent tasks went from that. It's not that different from how it is today in the new staging world. Mar 03 19:03:15 It dovetails nicely, really Mar 03 19:03:26 Everything would be new staging :) Mar 03 19:03:47 yeah, just moves deploy, etc into the same model Mar 03 19:03:51 <[denix]> Tartarus, kergoth: I also had couple old blog posts on DEPLOY_DIR outside of TMPDIR and pstage... :) http://blog.denix.org/2008/09/getting-dangerous-with-packaged-staging.html http://blog.denix.org/2008/09/getting-even-more-dangerous-with-pstage.html Mar 03 19:07:14 kergoth: What really grates is that prebuilds will call opkg to build packages a ton of times to build packages before being able to build an image Mar 03 19:07:37 kergoth: That is my key problem, I think that any prebuild mechanism should have facility to cache it Mar 03 19:07:49 03Tom Rini  07org.openembedded.dev * r679a2367ac 10openembedded.git/ (18 files in 6 dirs): (log message trimmed) Mar 03 19:07:49 firefox: Perform a number of cleanups and fix consistency issues. Mar 03 19:07:49 - parallel builds need to happen via MOZ_MAKE_FLAGS and it gripes if still Mar 03 19:07:49 passed -jN, so keep the old value before we clear it. Mar 03 19:07:49 - Move the HOST_LIBIDL stuff into configure, otherwise bad things happen when Mar 03 19:07:50 you don't have pkg-config on the build host. Mar 03 19:07:51 - Prior to 3.6, wireless-tools can be, or not be built already and the Necko Mar 03 19:08:09 but I have to go, I'm already late :/ Mar 03 19:08:17 RP: Some form of caching some outputs would be good Mar 03 19:08:18 too much to do, too little time :( Mar 03 19:08:23 Well, the problem I see with that is changes to the packaging/FILES will result in not being able to use the package. Mar 03 19:08:39 unless we do task level granular caching for those tasks, but i think we can add that to what i suggest Mar 03 19:09:00 hehe, okay, later, we can work out the details when you have thet ime Mar 03 19:09:04 kergoth: I don't think its any more work to do something generic Mar 03 19:09:08 from the start Mar 03 19:09:25 right, must leave, really Mar 03 19:09:46 Get out of this country, dammn you :) Mar 03 19:10:58 IMO, that makes it substantially more complex. Mar 03 19:13:21 both in implementation and in user interaction. you lose the simple elegance of a single archive for the recipe, if you don't want the user to have to fetch things they don't need Mar 03 19:14:51 * kergoth ponders Mar 03 19:14:59 kergoth: or build things the user doesn't need Mar 03 19:15:13 kergoth: the do_write_package_ipk just has the .ipk files in Mar 03 19:15:35 the staging package for do_... Mar 03 19:15:42 yes, I know. What i meant was, either all the task output is in one archive (i.e. git repo) in which case they have to fetch the world, or its a pile of little packages, which is a mess Mar 03 19:15:43 * RP -> gone Mar 03 19:16:33 hmm. Mar 03 19:18:46 * kergoth doesn't see a clean way to do it the way RP wants without hacking bitbake Mar 03 19:19:09 03Tom Rini  07org.openembedded.dev * r8b0202e6e3 10openembedded.git/conf/distro/include/ (glibc-external.inc glibc-internal.inc glibc.inc): Mar 03 19:19:09 glibc*.inc: Bump OLDEST_KERNEL to 2.6.16 Mar 03 19:19:09 Per glibc's ChangeLog, 2.6.16 is the minimum required by at least glibc 2.9 Mar 03 19:19:09 Prior to this, it was a murky 2.6.14 + patches to 2.6.16 (when it was all Mar 03 19:19:09 upstream). Mar 03 19:27:13 hmmm. Mar 03 19:27:19 Note, I hit that trying to test w/ glibc my qemu testing fixup Mar 03 19:27:20 So.. Mar 03 19:27:35 Good news, I've got locales being made for spitz for glibc Mar 03 19:27:42 Once this is finally done i'll kick for eglibc Mar 03 19:27:44 nice Mar 03 19:28:19 Still not touching the armv6 and newer stuff :) Mar 03 19:28:31 But bug I introduced being cleaned up more so :) Mar 03 19:29:39 hmm.. with what RP proposes, the layout of WORKDIR will end up encoded into the packages, also, since there's no other path to capture that makes sense.. whereas with going based on install, it captures from the root of ${D}.. it would also have to move DEPLOY_DIR into WORKDIR to capture the package creation process Mar 03 19:30:35 I don't think there's any way to use event handlers to automatically try to fetch a cached version for every task, unless the stamps are rechecked after running the handlers but before running the task.. hmm Mar 03 19:32:02 Do think more on it :) It would indeed be good to cache any outputs that we can cache Mar 03 19:33:15 course, the upside to that method would be, you could do_devshell on something that came from cached binaries, at least if we change the stamp behavior so that dep tasks aren't rebuilt when a dependent task is built. so do_package would be complete, but not do_fetch, do_unpack, do_patch... of course, to grab the cached version of the *latest* task available rather than the *first* would be the trick, would have to hack bitbake for that Mar 03 19:33:37 I'm still leaning towards going with my approach as a first step and implementing the rest as a secondary task, but still give it more thought Mar 03 19:35:00 k Mar 03 19:36:15 I see the second task as being an enhancement, I still think its best to think of a recipe's responsibility as getting you the installed files, and everything else before is intermediate, and everything else after can optionally be moved outside of the recipe itself if we choose to Mar 03 19:36:46 just seems less confusing that way. What does everyone else think? Mar 03 19:37:52 There is a point at which we stop making stuff and start managing stuff Mar 03 19:38:10 If we cache right at that first point, we'll save some time Mar 03 19:38:27 If we can then cache what makes sense out of that second point, we save more time still Mar 03 19:38:39 But maybe you have more than one cache file? Mar 03 19:39:00 Yeah, that's sort of how I'm thinking of it, too. The whole concept of bbclasses was to get us to the install point, I think.. it's all about dealing with upstream's content. Once we've got past that, we can do with it what we will Mar 03 19:39:08 ie with current pstaging, you can go from nothing to an image, in a reasonable timeframe Mar 03 19:39:09 that's good Mar 03 19:39:22 RP is wanting per-task cache files, capture the output of each task, store it, and be able to restore it on an as needed basis Mar 03 19:39:31 which sounds nice, but is likely to be a pain in the ass to implement Mar 03 19:39:46 capturing the task output (*if* you limit to WORKDIR) is easy, using it isn't Mar 03 19:39:52 Well, it sounds like it would be slower to run Mar 03 19:40:02 impl is easy, for the default cases Mar 03 19:40:19 run something like stage-manager over the dirs that the task says it cares about Mar 03 19:40:26 do the task, re-run Mar 03 19:40:28 cache changes Mar 03 19:40:31 repeat every time Mar 03 19:40:33 If we don't cache the packages, it definitely would go slightly slower than current, but I still think we can postpone the packaging to make that as-needed as well, which would limit the damage Mar 03 19:40:39 That just gives us stat() hell Mar 03 19:41:02 kergoth: I'd like to be proven wrong, but I think slightly is a big under statement Mar 03 19:41:05 I don't htink its viable to have multiple basedirs, trying to restore them into where they need to be would be a pain.. better to just make all the task output relative to WORKDIR Mar 03 19:41:31 well, its still substantially faster than the default case today, which is no pstage at all :) Mar 03 19:41:49 That is true Mar 03 19:42:01 It's just that we do spend a lot of time in the stuff that's after build Mar 03 19:42:23 Wish I had time (and some IT person time too) to get some real detailed logging out of a build or two Mar 03 19:42:45 Can really see the libc bottleneck on a from scratch build :( Mar 03 19:43:17 I can probably implement postponed packaging in a weekend, too. Building the 3 or so packages you really need from libc for an image shouldn't be much Mar 03 19:43:24 * kergoth shrugs Mar 03 19:44:48 huh, Digi International has a cortex-a8 dev board? interesting, i still think of them as serial, though i guess that acquisition of the embedded network folks must have shifted things after I left Mar 03 19:46:13 OK, glibc building done, kicking off eglibc now Mar 03 19:46:20 Then a quick test of my assume provided changes Mar 03 19:46:39 eFfeM, hi, are you at work or are you disponible Mar 03 19:47:24 And, curse my adding comment when I work: Mar 03 19:47:30 6 files changed, 40 insertions(+), 32 deletions(-) Mar 03 19:49:45 http://pastebin.com/EGPei9rU Mar 03 19:51:54 I do wonder tho, why angstrom/kaelios don't just bump OLDEST_KERNEL Mar 03 19:52:38 (They play a funny game in glibc-package.bbclass, which means that eglibc may just fail for them) Mar 03 19:55:15 ACTION thinks.. if you pulled all cached task output in setscene for all tasks that exist, you could really screw things up.. not all tasks should be tracked.. you'd need a blacklist or something.. and even then, i see problems where some task output could be cherry picked into place if you used git, but others would fail to applyw ithout earlier task output, whereas some could apply fine without earlier task output.. (i.e. do_compile touches f Mar 03 19:55:15 * kergoth do_configure touched, but do_install is safe) Mar 03 19:56:32 GNUtoo: i'm home, i'm europe based so 9pm here Mar 03 19:56:48 eFfeM1, ok we've got some huge breakage on eee701 Mar 03 19:56:56 eFfeM, I'll push a new xorg.conf Mar 03 19:57:02 should I do it now? Mar 03 19:57:06 but i have to leave in a 5-10 minutes to help my neighbour who has b-day, need to help getting rid of the ear Mar 03 19:57:10 ok Mar 03 19:57:10 GNUtoo: fine with me Mar 03 19:57:26 i can't test now though (and might need a rebuild anyway) Mar 03 19:57:31 also there is some breakage at boot with shadow+init Mar 03 19:57:34 actually quite busy this week) Mar 03 19:57:34 ij] Mar 03 19:57:43 s/ij]/ok/ Mar 03 19:58:39 what is b-day btw? Mar 03 19:58:53 kergoth: RP: saw the proposal to stage inbetween steps too, but don't really see the benefit Mar 03 19:58:56 GNUtoo: birthday Mar 03 19:58:59 ah ok Mar 03 19:59:10 thought that was a known abbreviation Mar 03 19:59:23 maybe it is and I was not aware of it Mar 03 19:59:23 like cy and np etc Mar 03 19:59:28 ok Mar 03 19:59:33 no problem, Mar 03 20:00:18 * eFfeM1 suddenly thinks he also needs to do taxwork this month >:o Mar 03 20:03:50 gone, have a nice evening all! Mar 03 20:09:28 can I bump PR of xserver-xorg-conf_0.1.bb ? the effect I want is a bump for eee701's config...but it's easier and more manageable to bump the general pr Mar 03 20:12:12 Hmm Mar 03 20:12:27 Out of curiousity isn't this what MACHINE_PR was supposed to help with? Mar 03 20:12:30 Or was that something else? Mar 03 20:17:53 I don't know MACHINE_PR Mar 03 20:18:11 in the recipe there is only PR Mar 03 20:19:38 Yeah Mar 03 20:19:57 koen added MACHINE_PR or so, for the omap3 stuff that needs bumping whenever some other machine stuff needs bumping Mar 03 20:20:28 Which in theory, iirc, allows for a per machine rebuild on recipes, rather than bump once for 10 machines since 1 needs it Mar 03 20:21:12 ok Mar 03 20:21:24 but if each person add his MACHINE_PR ? Mar 03 20:22:50 what's the difference between MACHINE_PR and PR_eee701 ? if the package is MACHINE_ARCH Mar 03 20:23:01 I'm not personally sure if it's the best way to solve problems and don't quite know how it's supposed to be used Mar 03 20:23:09 Sorry Mar 03 20:23:14 ok thanks a lot anyway Mar 03 20:46:29 mmm http://lwn.net/Articles/370711/ "but more commonly if you saw the flickering on your laptop panel due to LVDS downclocking" Mar 03 20:46:43 maybe we should bump kernel version for eee701 Mar 03 20:49:50 woop, eglibc is making locales now Mar 03 20:49:58 almost time to make sure the assume provided logic actually works Mar 03 21:03:52 * Tartarus recalls he can test that change w/ his glibc tmpdir and does Mar 03 21:07:20 03Tom Rini  07org.openembedded.dev * r27de16184d 10openembedded.git/ (6 files in 3 dirs): Mar 03 21:07:20 qemu: Move gcc version check, qemu-TARGET logic into qemu.bbclass Mar 03 21:07:20 Move the logic to determine what qemu-TARGET to run into qemu.bbclass so Mar 03 21:07:20 we can check for the right binary in sanity.bbclass. This code was Mar 03 21:07:20 duplicated by glibc-package and eglibc-package anyhow and with the new fn Mar 03 21:07:20 we can clean up the usage in these classes a bit. Now that we have a class Mar 03 21:07:21 for qemu stuff, and the gcc check is just for qemu, move it there. Mar 03 22:13:25 Where can I find a description of all config variables? eg. an example for TARGET_FPU is 'soft' - I'd like hard/vfp.. Mar 03 22:15:03 Some grepping reveals hard. First question still stands ;) Mar 03 22:19:07 Well, if it's not on the main wiki, which iirc links to a copy of the generated docs Mar 03 22:21:24 Can't find a reference there either Mar 03 22:24:12 * Tartarus pokes Mar 03 22:26:24 So, in a bbclass, VARIABLE[doc] = "What it does" is supposed to, i'd swear, end up someplace Mar 03 22:26:25 Tartarus: Huh? Mar 03 22:27:36 bbdoc. Mar 03 22:27:45 will generate docs based on it, using documentation.conf, iirc. Mar 03 22:28:23 Yeah, that's what I was thinking of Mar 03 22:28:30 That variable in question isn't documented Mar 03 22:28:33 But others are Mar 03 22:30:01 I managed to grep it from my documentation.conf Mar 03 22:31:58 Ah, der :) Mar 03 23:02:39 denix, I've created a bug in the opkg tracker for your BAD_RECOMMENDATIONS related issue. If you have further information, or a small test case, please add to it here: http://code.google.com/p/opkg/issues/detail?id=46 Mar 03 23:03:18 grg: thanks! Mar 03 23:03:53 grg: I was testing and modifying your original patch, but so far can't make it work... need more time, I guess ;) Mar 03 23:04:49 denix, also see opkg_conf_write_status_files() in libopkg/opkg_conf.c Mar 03 23:05:05 it doesn't write out status info for pkg->state_want == SW_DEINSTALL Mar 03 23:05:12 which is probably a bug Mar 03 23:06:29 ah, good, I'll check that as well, thanks Mar 04 02:38:34 hey all **** ENDING LOGGING AT Thu Mar 04 02:59:58 2010