**** BEGIN LOGGING AT Sat Mar 08 10:59:56 2008 Mar 08 11:10:52 hey ant|work Mar 08 11:11:02 zecke: hey Mar 08 11:11:28 zecke: can you please help me using mtn2git.py ? :) Mar 08 11:13:04 zecke: on IRC logs, I could find something like 'mtn2git -d ~/theDB.mtn | git-fast-import --date-format=rfc2822" Mar 08 11:13:32 and it seems to work (.git directory is filled) Mar 08 11:13:32 cyrilRomain: isn't there a readme? Mar 08 11:13:49 cyrilRomain: at least there is mtn2git --help and man git-fast-import :) Mar 08 11:14:28 yes I looked at 'mtn2git --help' Mar 08 11:15:15 the problem is then 'git log' or 'git status' doesn't return things Mar 08 11:15:48 cyrilRomain: after the import? Mar 08 11:15:56 yes Mar 08 11:16:14 cyrilRomain: git-branch -a says what? Mar 08 11:17:54 zecke pasted "mtn2git driver" at http://paste.lisp.org/display/57020 Mar 08 11:18:14 that is the script I run when someone asks me to update the mirror Mar 08 11:18:47 zecke: it list the branches :) I was too stupid not to run that command, so what I was missing is just a 'git checkout' :) Mar 08 11:18:51 zecke: thanks :) Mar 08 11:19:07 cyrilRomain: what did you convert? the whole of OE? Mar 08 11:19:41 zecke: no, just another mtn database in which I have some OE related stuff Mar 08 11:20:12 zecke: it worked like a charm ! Thanks for this wonderfull script :) Mar 08 11:20:57 Hi! I just recently started to get the message "Error, TMPDIR has changed ABI (0 to 1) and you need to either rebuild, revert or adjust it at your own risk." Mar 08 11:20:57 zecke: so do you now use git only when working on OE ? Mar 08 11:21:11 Does this mean I have to flush my whole tmp directory? Mar 08 11:21:41 treitmayr: yes, or don't use current org.openembedded.dev Mar 08 11:22:09 treitmayr: we have enabled sysroot on gcc, which required a change to our tmp/staging directory Mar 08 11:22:12 zecke: thanks, just wanted to make sure I am doing the right thing Mar 08 11:22:30 zecke: I read about it but was not sure if its already in effect Mar 08 11:22:39 thanks! Mar 08 11:22:44 treitmayr: :) Mar 08 11:29:15 can someone confirm this commit has been pushed? --> [20080308 03:24:26] thesing ^C07org.oe.dev * rbe3d3cb0... / (7 files in 3 dirs): klibc, klibc-utils-static: add losetup and modprobe to klibc-utils Mar 08 11:29:36 I don't see it using viewmtn Mar 08 11:32:40 neither here http://www.openembedded.org:1081/branch/changes/org.openembedded.dev?q=viewmtn/branch/changes/org.openembedded.dev Mar 08 11:32:50 nor here http://lists.linuxtogo.org/pipermail/openembedded-commits/2008-March/thread.html Mar 08 11:33:02 both are out of sync? Mar 08 11:38:56 03pfalcon 07org.oe.dev * r0ddcb5d9... 10/ (3 files in 2 dirs): Mar 08 11:38:56 linux-handhelds-2.6: Fix some initramfs support issues. Mar 08 11:38:56 * Be sure to clean up any possible old initramfs. Mar 08 11:38:56 * Fix bashism. Mar 08 11:44:28 whats the deal with avr32 .. i read the mails but i cant get it Mar 08 11:45:04 * * OE Bug 3980 has been created by  Mar 08 11:45:06 * * makedevs-1.0.0-r5-do_compile Mar 08 11:45:08 * * http://bugs.openembedded.net/show_bug.cgi?id=3980 Mar 08 11:52:40 morning everybody Mar 08 11:53:29 RP: my girlfriend said the only thing missing in the poky image for spitz is a sudoku game ;) Mar 08 11:55:41 RP: linux-rp_2.6.24 fails in do patch because of htcuni.patch. Do you want to fix this by upgrading the patch, or should I disable the patch and commit? Mar 08 11:57:30 morning thesing Mar 08 12:00:27 03mickeyl * r1028 10bitbake/ (ChangeLog lib/bb/cooker.py): cooker: fix traceback when using -b and -f together Mar 08 12:01:12 03mickeyl 07bitbake-1.8 * r1029 10/ (ChangeLog lib/bb/cooker.py): 1.8.x/cooker: backport -f and -b fix from trunk Mar 08 12:03:48 XorA: hey, did you progress on Qtopia/X11 packaging yesterday? Mar 08 12:14:33 03mickeyl 07org.oe.dev * rdf77e731... 10/ (3 files in 2 dirs): cmake-native 2.4.8 write proper do_stage Mar 08 12:18:31 03mickeyl 07org.oe.dev * rdf77e731... 10/ (3 files in 2 dirs): cmake-native 2.4.8 write proper do_stage Mar 08 12:19:07 03mickeyl 07org.oe.dev * r75880ed5... 10/ (5 files in 2 dirs): wireless-tools: remove .29 prereleases, add .29 release, refactor .inc file Mar 08 12:19:10 zecke: qpe runs, but fonts dont work Mar 08 12:19:14 03mickeyl 07org.oe.dev * racc74e7e... 10/ (1 packages/python/python-gsmd_svn.bb): python-gsmd svn fix SRC_URI Mar 08 12:19:20 03mickeyl 07org.oe.dev * r42eff260... 10/ (1 packages/python/python-pyiw_0.3.3.bb): python-pyiw 0.3.3 fix unpacking Mar 08 12:19:23 03mickeyl 07org.oe.dev * ra165e975... 10/ (1 packages/tasks/task-python-everything.bb): task-python-everything: catch up with renaming Mar 08 12:19:42 zecke: I now have to fix an OE issue we have avoided for years Mar 08 12:19:50 XorA|gone: installed the desktop files? xmodmap's added? font don't work in which way? Mar 08 12:20:12 zecke: the bar qpe puts at the bottom, all [] where text should be Mar 08 12:21:46 zecke: but on monday I need to fixup an xsession file and make it selectable Mar 08 12:22:02 XorA|gone: no text drawn? wrong glyphs? wrong size? don't get what [] means? is that empty text, is that the glyph's drawn? Mar 08 12:22:05 zecke: and probably whach illume crash horribly and find out reasons that does Mar 08 12:22:22 zecke: thats a square which is drawn instead of character Mar 08 12:22:49 XorA|gone: ah okay, wrong glyphs then Mar 08 12:23:09 normally caused by UTF conversion issues Mar 08 13:10:39 03thesing 07org.oe.dev * r2c5004d7... 10/ (1 packages/linux/gumstix-linux.inc packages/linux/linux.inc): Mar 08 13:10:39 linux.inc, gumstix-kernel.inc: remove sizecheck stuff Mar 08 13:10:39 The do_sizecheck function is in kernel.bbclass for some time now. Mar 08 13:12:17 thesing: We really need to fix the patch Mar 08 13:14:04 RP: I about to put do_deploy into kernel.bbclass and update the kernel recipes to use or override it. Should I RFC this patch on ML? Mar 08 13:15:22 thesing: Yes, people need to know about that kind of change Mar 08 13:19:07 RP: ok. I have the initramfs stuff nearly ready but its doesn't work for all kernel because do_deploy is put at different places by different kernel recipes. I would add it after do_install before do_build. (After I look at all kernel recipes if thats ok) Mar 08 13:19:17 * thesing -> lunch. Mar 08 13:20:26 RP: apparently you did not test building the other major toolkit with the sysroot changes :) Mar 08 13:22:35 zecke: ah :/. Give me a problem case and I'll take a look ;-) Mar 08 13:23:01 RP: it might be too ugly to look at, I will try to find time... Mar 08 13:23:25 RP: but I think qmake needs to be aware of sysroot Mar 08 13:23:30 *time* *where is the time* Mar 08 13:24:27 zecke: Is there a specific package failure example I can look at? Mar 08 13:24:43 thesing: How's this going to work with initfs images which need kernel modules? Mar 08 13:24:47 RP: bitbake qsvn should fail, at least I'm testing it now :) Mar 08 13:25:29 RP: but sysroot can make some of the qmake/qt stuff better... Mar 08 13:27:06 zecke: I don't know qmake at all unforunately so I can't really comment on that. I'm not sure why sysroot would break it though :/ Mar 08 13:27:35 Unless it has some hardcoded layout assumptions? Mar 08 13:27:40 RP: :) Mar 08 13:27:58 * zecke mumbles someone from germany, currently in in taipei, added sed :) Mar 08 13:28:47 zecke: ;-) Mar 08 13:31:51 and I'm sick of mtn :) Mar 08 13:32:08 zecke: ready for git? Mar 08 13:32:53 I fully agree with the sysroot stuff, I think it should have been done in a branch and say. I think it is done, I will merge it in a week, check your favorite recipe or fix it afterwards. and if major issues would be found post pone merging a week :) Mar 08 13:33:01 yeah, definately ready for git Mar 08 13:33:54 zecke: A branch would have perhaps been better, yes. Live and learn I guess... Mar 08 13:34:17 zecke: I think if you propose switching not many people will object Mar 08 13:34:40 RP: I know why we don't do this with mtn, but it is disgusting to deploy bad engineering because your SCM system is broken :) Mar 08 13:35:02 hmm I'm either just tired ATM or a bit frustrated.. dunno why :) Mar 08 13:36:01 zecke: Due to the ABI change, I doubt many people would have tested a branch anyway Mar 08 13:36:49 zecke: I did promise to try and timely fix reported issues, you've reported this one so I have a promise to keep now ;-) Mar 08 13:38:12 RP: if it breaks, it is my issue though... Mar 08 13:38:40 RP: probably true on the ABI change, but then people can not complain Mar 08 13:39:18 zecke: It would have had that adavantage Mar 08 13:39:45 RP: and I would probably start builds for the stuff I care :) Mar 08 13:40:11 zecke: Yes, I think you're one of the few who would :) Mar 08 13:42:56 RP: I use your suggestion from ML the kernel build process will be: configure, compile, install, stage, package (modules only), buildin_initramfs, sizecheck, deploy, package_kernel Mar 08 13:43:51 RP if INITRAMFS_IMAGE is not set buildin_initramfs does nothing, all other task behave as they do now except splitted packaging. Mar 08 13:44:27 thesing: I'm not sure I ever suggested split packaging like that Mar 08 13:45:04 RP: no you suggested a second packaging. But this does package the modules twice. Mar 08 13:46:18 RP: This may not be the best solution but its without recursive bitbake and generic for all kernels. Mar 08 13:46:43 thesing: I think I said the only way to sanely make this work was for two different kernel packages, one generating the initfs modules and then the second the kernel Mar 08 13:46:50 RP: but the initramfs has to be build with the same libc (or use klibc which is a special case) Mar 08 13:47:07 thesing: I think you will hit issues with the approach ;/ Mar 08 13:48:20 RP: What issues? Mar 08 13:49:05 thesing: image generation depends on do_package_write. How are you going to make image A depend on do_package_writeA and image B depend on do_package_writeB ? Mar 08 13:51:01 Simpler is to create a linux-initramfs-kernel.bb which provides virtual/kernel and depends on virtual/kernel-initramfsless. This .bb generates the initramfs kernel package from the original one Mar 08 13:51:31 Machines would select this approach by declaring their preferred kernel providers accordingly Mar 08 13:51:39 RP:Thesing: don't you think the whole initramfs thing should be treated separately (a.k.a. new.bb) like other bootloader / firmware stuff? Mar 08 13:52:00 But distros could not decide if they want initramfs or not. Mar 08 13:52:46 at least for the kexec, replacin broken bootloaders, I'd say install once and forget about Mar 08 13:53:38 ant: this discussion is more about the backend ;) Mar 08 13:54:28 yea, but you do need an uclibc pass anyway... Mar 08 13:54:45 which complicated the matter Mar 08 13:55:07 ant: no uclibc is not needed eventually (because the initramfs only uses klibc) Mar 08 13:55:30 I'm confident you'll win ! Mar 08 13:55:49 against klibc ;-) Mar 08 13:57:26 RP: how about having a kernel-modules-bb and reusing its workdir for the kernel-bb? Mar 08 13:59:29 thesing: The kernel-modules-bb can just depend on some task in the original kernel that builds the initramfs. The key point is that that task can now run outside the normal task dependencies and the second .bb file can package it Mar 08 14:01:45 RP: do you mean s/initramfs/modules/? Mar 08 14:02:59 thesing: Yes and no. The kernel-initfs-bb can just depend on some task to build the initramfs in the original kernel that builds the modules Mar 08 14:03:13 is that clearer? Mar 08 14:04:55 hi all Mar 08 14:05:03 hi florian Mar 08 14:06:25 RP: yes but I think the other way is better: split the have kernel-modules that depends on virtual/kernel:do_install an packages the kernel modules. The initramfs can use the modules for do_rootfs and buildin_initramfs can build the initramfsed kernel which is packaged normally. Mar 08 14:08:28 thesing: I don't think it will work. How will you solve the do_package_write issue I mentioned above? Mar 08 14:10:56 RP: kernel has only the normal package_write and images can depend on that. if the image include modules it depends on kernel-modules:do_package_write which depends on kernel:do_install. Mar 08 14:12:26 thesing: but the point of creating this initramfs package is so you can include it in some rootfs image? Mar 08 14:13:27 RP: no the initramfs package generate an image that can included in a kernel. This kernel can be included by some (not initramfs) image. Mar 08 14:14:13 thesing: Will generating this (not initramfs) image be a separate bitbake command? Mar 08 14:15:23 zecke: Does apt-util build for you? Mar 08 14:15:29 apr-util Mar 08 14:17:01 RP: not necessarily. Mar 08 14:17:33 thesing: I'm presuming we want "bitbake gpe-image" to continue to work. Assuming you have some initramfs-image target in the build chain, that will have a dependency on virtual/kernel:do_write_package and gpe-image will also have a dependency on virtual/kernel:do_write_package Mar 08 14:18:13 This is a circular depends loop which is what I want to avoid Mar 08 14:19:00 RP: no the initramfs will have a dependency on kernel-modules:do_package_write as it only include kernel modules and no kernel. Mar 08 14:19:43 thesing: "kernel-modules" is a seperate .bb file? Mar 08 14:20:20 RP: yes. Mar 08 14:20:30 thesing: So every kernel needs a separate .bb file? Mar 08 14:22:00 RP: I think we can share this by doing some magic with virtual/kernel. Mar 08 14:22:57 thesing: So we only have one .bb file? Mar 08 14:23:22 RP: yes I think so. Mar 08 14:23:31 thesing: It won't work like that Mar 08 14:24:04 I don't see how you can do "magic with virtual/kernel" without two .bb file as I previously mentioned Mar 08 14:24:27 * RP -> lunch Mar 08 14:27:12 RP: I didn't really think about this detail. As a first step one would have a kernel-modules.bb file for every kernel-recipe but they would be identical. I was thinking that one can manipulate stamps depending on virtual/kernel or something like that. Mar 08 14:27:49 thesing: would kernel.bb and kernel-modules.bb operate on the same workdir? Mar 08 14:28:11 pH5: yes Mar 08 14:38:02 RP: it did the last time :( Mar 08 14:41:05 * * OE Bug 3981 has been created by  Mar 08 14:41:07 * * klibc-1.5-r6-do_compile Mar 08 14:41:09 * * http://bugs.openembedded.net/show_bug.cgi?id=3981 Mar 08 15:11:04 * * OE Bug 3982 has been created by  Mar 08 15:11:06 * * linux-handhelds-2.6-2.6.21-hh20-r16-do_compile Mar 08 15:11:08 * * http://bugs.openembedded.net/show_bug.cgi?id=3982 Mar 08 15:21:05 * * OE Bug 1208 has been RESOLVED (FIXED) by Mar 08 15:21:06 * * New bbclass - initramfs Mar 08 15:21:08 * * http://bugs.openembedded.org/show_bug.cgi?id=1208 Mar 08 15:41:04 * * OE Bug 1262 has been RESOLVED (FIXED) by Mar 08 15:41:06 * * Bitbake complains about LEAD_SONAME building ncurses-5.4-r8 Mar 08 15:41:08 * * http://bugs.openembedded.org/show_bug.cgi?id=1262 Mar 08 15:42:05 * * OE Bug 1382 has been RESOLVED (FIXED) by Mar 08 15:42:07 * * qmake does not exist in oe Mar 08 15:42:08 * * http://bugs.openembedded.org/show_bug.cgi?id=1382 Mar 08 15:45:05 * * OE Bug 1575 has been RESOLVED (INVALID) by Mar 08 15:45:07 * * ACE 5.5 bb file Mar 08 15:45:09 * * http://bugs.openembedded.org/show_bug.cgi?id=1575 Mar 08 15:54:03 Greetings and Salutations Mar 08 15:54:12 hi mwester Mar 08 15:58:10 03mickeyl 07org.oe.dev * rc76638bd... 10/ (4 files in 2 dirs): ncurses 5.4 revamp packaging. closes #1262 Mar 08 15:58:15 03mickeyl 07org.oe.dev * rfeafcb12... 10/ (14 files in 2 dirs): gstreamer update: base 0.10.17, good 0.10.7, bad 0.10.6, ugly 0.10.7 Mar 08 15:58:28 ~lart koen Mar 08 15:58:28 * ibot takes large quantities of Krispy Kream donuts and stuffs them one after another down koen's throat until koen puts on 150lbs Mar 08 15:59:07 florian what happened? Mar 08 15:59:35 woglinde: looks like the x11 gpe image does not have a screenshot tool Mar 08 16:00:03 hi mwester Mar 08 16:00:33 I should do more kernel hacking Mar 08 16:00:51 thesing: This was why I preferred the idea of a single extra .bb file for the initramfs rather than one per kernel recipe Mar 08 16:00:51 * florian has a basically working Mainstone now Mar 08 16:20:10 RP: how do I get workdir, PV etc. from virtual/kernel in initramfs-kernel.bb then? Mar 08 16:21:07 thesing: You don't, you just depend on a task in the other .bb Mar 08 16:21:21 That task puts something into staging Mar 08 16:26:07 why don't we just build the kernel as usual then and have a kernel+initramfs.bb that depends on virtual/kernel:do_compile_and_stage_initramfs_kernel tasks and then packages that? Mar 08 16:28:44 pH5: People want "gpe-image" to include building the initramfs image and that include that into a kernel Mar 08 16:29:41 initramfs-kernel would need to package a file from deploydir then. Mar 08 16:30:02 thesing: or staging Mar 08 16:30:42 is this ok? this seems a little bit dirty to me. Mar 08 16:31:02 thesing: I think its the only option available Mar 08 16:31:49 ant there is no python-foo got get workdir etc of virtual/kernel? Mar 08 16:32:13 thesing: Touching another workdir from a recipe is a bug. It will break rm_work Mar 08 16:33:04 RP: we preserve workdir for linux-rp anyways for wlan-ng. Mar 08 16:33:27 thesing: Yes, but that is a nasty hack Mar 08 16:33:36 thesing: I don't really agree with that Mar 08 16:34:09 nastier than staging the kernel to package in another .bb, certainly Mar 08 16:34:40 * mwester wonders if the concept of inheriting a work-dir makes any sense -- would permit a way to express a dependency on another recipe's working data... Mar 08 16:34:42 RP: rm_work only deletes ${S}, does it? Mar 08 16:35:05 thesing: I think so Mar 08 16:36:31 another usecase: currently klibc and klibc-utils-static both build klibc but install and package different files. It would be better if klibc:install would install the files for klibc-utils-static to ${Dstatic}. klibc-utils-static could depend on klibc:do_install and package the files from ${Dstatic} Mar 08 16:38:38 thesing: Two recipes adds some code but not a lot... Mar 08 16:38:53 Shared work directories are not what we currently support Mar 08 16:39:14 If anyone wants to start supporting them we need a really good reason for it Mar 08 16:40:14 it doesn't make packaging files from staging or somewhere else necessary. Mar 08 16:41:51 What would be the problem with that? It may break if we change rm_work do remove WORKDIR but rm_work could watch out for this. We could rule that only packages can share Workdir if one depends on the other. Mar 08 16:42:41 thesing: It makes the system more complex and changes the expected behaviours Mar 08 16:43:00 thesing: Its not something we can do without careful consideration Mar 08 16:43:14 The design is that shared data goes into staging Mar 08 16:43:30 What's wrong with that design? Mar 08 16:44:25 ok how to make sure that package A finds the data package B puts there? And can A delete the data after it used it? Mar 08 16:44:48 A DEPENDS on B or has some other dependency Mar 08 16:45:00 and no, it cannot delete the data, why would it want to do that? Mar 08 16:45:57 because its not needed after A run. (ok except you rebuild A) Mar 08 16:46:26 thesing: Do we delete libs from staging after something links against them? Mar 08 16:46:43 you're right. Mar 08 16:47:04 ok. where to put the data in staging dir? Mar 08 16:47:24 That is a good question :) Mar 08 16:47:51 Somewhere in STAGING_KERNEL_DIR? Mar 08 16:48:17 and in the case of klibc? and potential other packages? Mar 08 16:48:45 I really think shared workdirs would be cleaner. Mar 08 16:49:28 RP: btw. who is "team bitbake" besides you? Mar 08 16:52:50 thesing: We deal with it on a case by case basis. shared workdirs are not currently supported. They'd complicate a lot of different things and if you wanted to change that you'd need to propose it with good reasons Mar 08 16:52:59 thesing: zecke and mickeyl I guess Mar 08 17:08:09 hi mr_nice Mar 08 17:09:26 woglinde: hi Mar 08 17:09:43 woglinde: hi Mar 08 17:26:58 03pfalcon 07org.oe.dev * r6d9b16cd... 10/ (3 files in 2 dirs): linux-handhelds-2.6: Use rm -f for stale initramfs cleanup. Mar 08 17:28:38 RP: do if shared workdirs where supported how would I get the workdir of another package? Mar 08 17:35:11 thesing: You would have to devise a way to work that out Mar 08 17:35:58 thesing: This raises all kinds of questions though Mar 08 17:36:50 RP: would it be necessary to extend bitbake for that or is some python enough? Mar 08 17:38:27 thesing: Well, it means recipe A needs to peek into recipe B's variable space Mar 08 17:39:11 whilst bitbake stores some data on each recipe, WORKDIR isn't amongst it Mar 08 17:40:16 thesing: Also for things like "virtual/kernel" you'll have trouble working out which recipe is providing it without help from bitbake Mar 08 17:40:48 thesing: so yes, you'll need to extend bitbake Mar 08 17:40:57 thesing: and I'm not keen on the idea tbh Mar 08 17:41:06 RP: ok. there shared workdirs die ;) Mar 08 17:41:28 and the workdir may no longer be there anyway :-) Mar 08 17:41:35 This is why we have staging, so packages can share data Mar 08 17:42:17 thesing: I'm not trying to be negative about these things but it really is a massive change in behaviour Mar 08 17:42:28 and would cause a lot of issues Mar 08 17:43:58 RP: so now to the "put stuff to staging" thing. If A puts Stuff to STAGINGDIR/A-$PV-$PR how does B know what PV an PR of A are? Or would it be enough for A to put stuff to STAGINGDIR/$PN ? But then there might be issues if people want different versions to coexist. Mar 08 17:44:54 thesing: You wouldn't use PV/PR. different versions coexisting in staging is a bad idea Mar 08 17:45:58 If you recipe can't work out what PV/PR would be its usually a sign you shouldn't be using them Mar 08 17:46:02 * RP -> back later Mar 08 17:46:24 before I get really annoyed with apr-util and libtool ;-) Mar 08 17:53:18 is MACHINE_TASK_PROVIDER still being used for "new" designs or is it a leftover from the task-base switchover? Mar 08 18:00:41 03pfalcon 07org.oe.dev * rd63274ea... 10/ (1 packages/initrdscripts/initramfs-module-bootmenu_1.0.bb): initramfs-module-bootmenu: Use klibc-linked fstype util, tested to work as expected. Mar 08 18:00:45 03pfalcon 07org.oe.dev * r046a7c86... 10/ (3 files in 3 dirs): klibc-utils-fstype-static 1.1.1: Remove hacky recipe now that there's klibc-utils-static. Mar 08 18:12:02 03mickeyl 07org.oe.dev * r1d903fb7... 10/ (5 files in 4 dirs): add libgee, a collection library providing GObject-based interfaces and classes for commonly used data structures. Mar 08 18:23:33 03pfalcon 07org.oe.dev * r1764f957... 10/ (3 files in 3 dirs): initramfs-module-bootmenu: Show only block devices with FSes supported for boot. Mar 08 18:25:16 hi Mar 08 18:26:21 hi Mar 08 18:27:18 hi schurig Mar 08 18:34:57 03pfalcon 07org.oe.dev * r06ce69bd... 10/ (3 files in 3 dirs): Mar 08 18:34:57 initramfs-module-bootmenu: If rootdelay= param was not passed, assume 2s delay still. Mar 08 18:34:57 * So people who don't bother to set correct rootdelay still have good chance Mar 08 18:34:57 for there SD/CF cards detected. Mar 08 18:34:57 * To disable the feature, explicit rootdelay=0 should be passed on kernel Mar 08 18:34:58 command line. Mar 08 19:45:05 * * OE Bug 3983 has been created by  Mar 08 19:45:07 * * mono-1.2.6-r1-do_compile Mar 08 19:45:09 * * http://bugs.openembedded.net/show_bug.cgi?id=3983 Mar 08 19:59:18 afternoon-ish Mar 08 19:59:34 so, how does PACKAGES_DYNAMIC pull in kernel module packages into the rootfs? Mar 08 19:59:50 I am getting all these nice ipk's but none of them are pulled in by default. Mar 08 20:01:08 I see that kernel.bbclass pulled in kernel-module-* via PACKAGES_DYNAMIC but I don't really see where/how that gets used. Mar 08 20:04:36 What is the recommended distro to use in OE for the N800? I see there is mamona distro, I tried using it and then doing an image build of maemo-image but it seems the maemo-image is very broken.. I don't mind fixing it but the question is is it worth fixing :-) Mar 08 20:05:18 03mickeyl 07org.oe.dev * ra7d0911c... 10/ (4 files in 2 dirs): gnutls (all) fix pkgconfig file at the proper location Mar 08 20:07:22 svolpe: hmm... we have a maemo image? that would be the one to fix imho Mar 08 20:11:48 flo_lap, yes but is is wierd as a lot of the packages depend on several packages that directly depend on a package called gtk+-2.6.4-1.osso7, that is the actual name not gtk+_2.6.4.1-1.oss7. That is really wierd to have the version as part of the name and not after a underscore _. and that package has been removed so several hildon packages are now broken. Mar 08 20:12:05 * * OE Bug 3072 has been RESOLVED (FIXED) by Mar 08 20:12:07 * * A Mastermind-style game *.bb file Mar 08 20:12:09 * * http://bugs.openembedded.org/show_bug.cgi?id=3072 Mar 08 20:12:17 flo_lap, I guess I will post a message to the email list and if no one is really using those packages I will redo them so they work :-) Mar 08 20:13:37 flo_lap, example: check out packages/maemo/hildon-home_0.8.20-2.bb Mar 08 20:13:38 <_Krieger_> please, make it possible to download oe-usermanual in html format in a tarball at once. PLEASE. Mar 08 20:14:08 moin Mar 08 20:14:53 svolpe: i'll check Mar 08 20:15:00 zecke: hi Mar 08 20:18:00 *bac* Mar 08 20:18:27 *back* Mar 08 20:20:45 svolpe: ah yes, that's really old and someone removed that special gtk package Mar 08 20:22:08 sounds like koen or laibsch cleaning up :/ Mar 08 20:23:23 svolpe: We have a set of maemo packages that is really old... and a part of updated ones in the maemo4 subdir Mar 08 20:28:15 _Krieger_: if you just want a local copy, you could check out the org.openembedded.documentation/ branch Mar 08 20:28:28 * hvontres|AFK should update his Mar 08 20:29:47 * flo_lap kicks his buildserver... the workstaion is way faster Mar 08 20:31:31 flo_lap: you must have long legs :) Mar 08 20:32:07 hvontres|AFK: heh, true... about 2km ;) Mar 08 20:32:16 flo_lap, I guess the maemo-image must be part of the really old stuff. Mar 08 20:32:46 svolpe: yes, i guess i checked that in when the 770 was released Mar 08 20:41:39 flo_lap, Well I guess I will work on getting it working again, I guess I can just fix it and push it as I don't think I have to worry about messing anyone up since it is already really borken :-) Mar 08 20:44:06 svolpe: hehe... ok :) check with the mamona guys, maye they have more bits already Mar 08 20:44:28 night Mar 08 20:44:54 I guess i would play with this pretty soon too Mar 08 20:45:05 * flo_lap has some interesting devices for it Mar 08 20:45:10 zecke: good night Mar 08 20:45:34 flo_lap, I started with mamona but so much was broken with it that I figured I would work in OE instead of mamona. Any idea why the mamona guys branched instead of working out of the mainstream OE? Mar 08 20:45:56 flo_lap, plus I have write privs to oe so I could do more with it. Mar 08 20:46:48 svolpe: no idea, but getting their stuff upstream sounds like a good start Mar 08 20:52:41 http://pandora.bluwiki.com/ Mar 08 20:57:02 no ideas on getting kernel modules to install into the rootfs image? Mar 08 20:58:29 flo_lap, well I have spoken with some of them and they seem like a good group and interested in mainstreaming as much as possible so I will talk to them more and see if I can't do the mainstreaming... Mar 08 21:00:33 flo_lap: btw, looks like g****** is still having a hard time describing GPE to the USPTO: http://tmportal.uspto.gov/external/portal/tow?SRCH=Y&isSubmitted=true&details=&SELECT=US+Serial+No&TEXT=77123546# Mar 08 21:01:32 cdm: all modules or particular ones? Mar 08 21:02:46 svolpe: sounds good Mar 08 21:03:30 hvontres|AFK: yeah, read this some time ago... i'll never understand what is going on in his mind Mar 08 21:03:49 flo_lap: all the modules the kernel builds. Mar 08 21:04:03 so I don't need to worry about exactly which ones are being built. Mar 08 21:04:11 I see all the nice ipk's Mar 08 21:04:20 in the machine specific directory under delpoy/ipk Mar 08 21:04:23 deploy even. Mar 08 21:04:35 but only the kernel gets pulled into the rootfs Mar 08 21:05:03 cdm: there is one meta package - kernel-packages iirc Mar 08 21:06:45 whats the option to automaticly let tmp/work be removed while building ? Mar 08 21:08:12 cdm: then just set MACHINE_EXTRA_RDEPENDS in the macheines conf Mar 08 21:09:35 rob_w: inherit rm_work Mar 08 21:09:54 can i set this in a local.conf ? Mar 08 21:10:15 rob_w: yes Mar 08 21:10:40 flo_lap: is 'INHERIT += "rm_work"' and 'inherit rm_work' the same? Mar 08 21:10:50 so is then possible to set this globaly in local.conf and then be able to add tags to certain bb files to igrnore it again ? Mar 08 21:12:12 rob_w: if you want to ignore rm_work, just add do_rm_work() { Mar 08 21:12:12 } Mar 08 21:12:34 ah right Mar 08 21:12:34 in your .bb file (see linux-rp.inc for an example) Mar 08 21:12:39 got you Mar 08 21:13:36 pH5: hum... iirc "inherit" is the deprecated syntax, but i'm not sure Mar 08 21:22:08 flo_lap: cool, lemme try Mar 08 21:27:04 * * OE Bug 3984 has been created by  Mar 08 21:27:06 * * gpe-mini-browser2-0.0.1+svn20080308-r0-do_configure Mar 08 21:27:09 * * http://bugs.openembedded.net/show_bug.cgi?id=3984 Mar 08 21:30:50 Hi! Mar 08 21:30:51 hello psokolovsky Mar 08 21:31:17 it seems that koen doesn't spend much time on irc either lately... Mar 08 21:31:47 psokolovsky: yes someone mentioned that he decided not to use irc any more Mar 08 21:31:59 heh ;-) Mar 08 21:32:24 hi psokolovsky Mar 08 21:36:04 * * OE Bug 3985 has been created by  Mar 08 21:36:06 * * speech-dispatcher-0.6.5-r7-do_configure Mar 08 21:36:09 * * http://bugs.openembedded.net/show_bug.cgi?id=3985 Mar 08 22:05:55 flo_lap: hmm, two years ago has was edgy on IRC; so that might be a benefit ... Mar 08 22:07:22 schurig_home: heh.. koen's emails seem a lot friendlier lately... Mar 08 22:07:41 * hvontres|AFK wonders if aliens secretly replaced koen with a stunt double... Mar 08 22:08:48 well, i guess there were reasons Mar 08 22:09:46 flo_lap: maybe the real world started catching up... IRC can be a real time-sucker Mar 08 22:11:15 hvontres|home: its all a question of your mind :) Mar 08 22:17:04 http://pandora.bluwiki.com/ Mar 08 22:17:29 anyone knows for how long more -c rebuild will stay broken? Mar 08 22:18:02 I think RP fixed it? Mar 08 22:18:53 Crofton: doesn't work for me with fresh .dev update, and hasn't been working for ~week now Mar 08 22:19:03 update bitbake? Mar 08 22:19:50 Crofton: heh, thanks ;-D Mar 08 22:22:04 * * OE Bug 3986 has been created by  Mar 08 22:22:06 * * linux-handhelds-2.6-2.6.21-hh20-r17-do_compile Mar 08 22:22:08 * * http://bugs.openembedded.net/show_bug.cgi?id=3986 Mar 08 22:28:36 Crofton: that server does not respond Mar 08 22:32:41 heh... looks like hrw|gone had some free time :) http://changelog.complete.org/posts/698-guid.html Mar 08 22:46:20 hvontres|home: too bad that they don't cover monotone airlines there. Main competitor: 3270 airlines ... Mar 08 22:52:29 schurig_home: feel free to add it :) Mar 08 22:53:33 hvontres|home: naaa, I'm not that imaginative ... and not distant enought (being a dedictate mtn disliker). One should write this that is capable of writing it with a a smile and a twinkle Mar 08 22:55:14 hvontres|home: maybe I would have used the Kremlin analogon on monotone. Every action of every pupil is recorded in the database archives. And bureaucrats need ages to synchronize and find things. While doing it, they generate tons of papers. Mar 08 22:56:20 (seeing how many bytes mtn needs to send & receive for a simple "mtn pull" operation compared with hg or git and it's slow sqlite database). Hmm, I should bark about the sign and check-signature orgy of mtn as well ... Mar 08 22:58:37 schurig_home: heh... I guess I am OK with mtn...of course so far I have been limited mostly to mtn pull;mtn up :) Mar 08 22:59:10 schurig_home: and at lest it's not VSS air... they use that at work and it scares me... Mar 08 23:00:17 schurig_home: Of course as a mechanical engineer I am more familiar with Pro/Intralink....RCS for 3D Cad models... that can get fun... but diffs are a pain in the butt Mar 08 23:06:52 flo_lap, http://openpandora.ca/ Mar 08 23:07:36 Crofton: ah cool, that looks good Mar 08 23:07:47 yeah Mar 08 23:08:19 re Mar 08 23:08:24 re thesing Mar 08 23:08:34 thesing: wb Mar 08 23:15:02 03florian 07org.oe.dev * r0a0941ba... 10/ (6 files in 4 dirs): linux-mainstone: Add 2.6.25-rc4 for Mainstone including latest PXA27x love and keypad patch by Eric Miao. Mar 08 23:15:07 03florian 07org.oe.dev * rd06ab8ea... 10/ (1 conf/machine/mainstone.conf): mainstone.conf: Use new kernel Mar 08 23:50:39 * RP kicks the subversion recipe Mar 09 00:01:33 03pfalcon 07org.oe.dev * rfc771feb... 10/ (3 files in 3 dirs): Mar 09 00:01:33 initramfs-uniboot: Add support for early-init plugins. Mar 09 00:01:33 * Extend plugin protocol: plugins matching pattern '0*' are early-init, Mar 09 00:01:33 executed ASAP after boot, before kernel command and block devices are scanned. Mar 09 00:01:33 And thus, they can affect parsing of kernel command line (by overriding $CMDLINE) Mar 09 00:01:34 or detection of block devices (e.g. by loading additional modules). Mar 09 00:01:38 03pfalcon 07org.oe.dev * ra71e40a6... 10/ (3 files in 3 dirs): initramfs-module-bootldr-buster: initramfs module to fight Compaq bootldr stupidity. Mar 09 00:01:43 03pfalcon 07org.oe.dev * r7e48fff2... 10/ (3 files in 3 dirs): Mar 09 00:01:43 initramfs-module-bootldr-buster: Add initial code to workaround bogus system console issue. Mar 09 00:01:45 * The main trouble is the bogus console=ttySA0 passed by bootldr Mar 09 00:01:47 It appears that kernel doesn't have protection against only invalid Mar 09 00:01:49 consoles being passed on the command line, which means that the Mar 09 00:01:51 kernel is deaf and dumb when booted by bootldr. Mar 09 00:01:55 03pfalcon 07org.oe.dev * rc62839bc... 10/ (3 files in 3 dirs): Mar 09 00:01:57 initramfs-uniboot: Add new global var - CONSOLE - and start to use it as output device. Mar 09 00:01:59 * This is to workaround bogus console= passed in by bootldr. Mar 09 00:02:01 03pfalcon 07org.oe.dev * r521a15d5... 10/ (3 files in 2 dirs): Mar 09 00:02:03 linux-handhelds-2.6: Remove broken keep-initramfs.patch. Mar 09 00:02:05 * Doesn't work with the no-initramfs case. Mar 09 00:02:09 * Added explicit touch after cp instead. Mar 09 00:13:32 psokolovsky: ping Mar 09 00:19:05 thesing: pong Mar 09 00:20:20 psokolovsky: I added losetup and modprobe to klibc-utils. It should be easy to convert your initramfs stuff to klibc now. Do you have plans to do this in near future? Mar 09 00:21:42 thesing: nope. my plan is to move linux-hh in stable to it. optimizations are for later time. feel free to hack on that if you like. note also that read -s -n -t is required for interactivity. Mar 09 00:21:55 thesing: otherwise, great work of course - thanks! Mar 09 00:24:00 psokolovsky: ok will do. Mar 09 00:26:04 psokolovsky: is it save to overide RDEPENDS in initramfs-module-bootmenu to remove some initramfs-moduls-foos? i.e. are there dependencies between the modules that are not set? Mar 09 00:27:24 thesing: nope, all RDEPENDS in initramfs-module-* are must (modulo bugs). However, you can freely add/remove stuff in initramfs-bootmenu-image.bb Mar 09 00:28:28 Thats exactly what I wanted to know. Thanks. Mar 09 00:29:25 psokolovsky: It would be cool if we could use some nice looking framebuffer gui for the bootmenu. But I'm dreaming.. Mar 09 00:29:33 thesing: for example, throwing away nfsboot will immediately make entire cpio.gz ~500k Mar 09 00:29:58 Crofton: so where do I get one of those ? :) Mar 09 00:30:43 thesing: I'm functionality man. blinken-lights are "easy", and there's always someone who wants to do that kind of stuff, so I leave that for other people ;-) Mar 09 00:31:23 psokolovsky: me too. Mar 09 00:31:27 ;-) Mar 09 00:31:56 hvontres|home: hvontres|home didn't you want do a nicer bootmenu? ;) Mar 09 00:32:52 thesing: oh, btw - did you ever try to override console= via kexec? like, original kernel boots with one set of consoles, while kexec'ed with other? Mar 09 00:33:38 thesing: well, I'm cool with ncurses myself... actually I have a ncurses frontend for altboot..but I think thins initramfs thing looks much better :) Mar 09 00:34:13 psokolovsky: no. but it takes nearly no time to try. Mar 09 00:35:42 thesing: such stuff doesn't work too well for me at all ;-(. I'm going to make final tests and post to LAKML about it... Mar 09 00:37:25 * thesing wonders if libraries can be compiled against klibc. Mar 09 00:39:54 psokolovsky: works fine here: I started with console on serial and tty1, kexeced a kernel with console=tty1 and did not get kernel messages on serial. Mar 09 00:40:14 Hi, is anyone able to help me determine why a package is being built? Mar 09 00:40:14 psokolovsky: should I test other scenarios? Mar 09 00:40:15 thesing: ok, thanks for test Mar 09 00:40:59 thesing: well, wouldn't waste your time now, let me finish mine cases and post to LAKML if needed, then I'd appreciate your review Mar 09 00:41:16 ok. Mar 09 00:41:49 Kinnison: 'bitbake -g' should help along with grep on packages Mar 09 00:42:45 thesing: I get very confused while trying to read that kind of output Mar 09 00:43:59 thesing: I'd ask on #poky but I doubt they're around at this time of night :-( Mar 09 00:44:19 it seems a task depends on it Mar 09 00:44:23 well, RDEPENDS on it Mar 09 00:44:32 and this is odd because I don't want that task anyway Mar 09 00:44:37 and I'm not supposed to be including it Mar 09 00:44:43 are all tasks built automatically or something? Mar 09 00:45:11 see http://en.wikipedia.org/wiki/DOT_language for syntax of bitbake -g output Mar 09 00:45:37 it doesn't appear that the -g output shows what depends on something Mar 09 00:45:39 :-( Mar 09 00:45:44 only what the something depends on Mar 09 00:45:51 I.E. bitbake -g foopackage Mar 09 00:45:56 won't show me what depends on foopackage Mar 09 00:46:01 Or am I missing something? Mar 09 00:46:40 no but if you want to know why something is in an image you can do bitbake -g image and find it out. Mar 09 00:47:05 afaict from that output, nothing is depending on the task which depends on the package I want to omit Mar 09 00:47:14 and nothing else depends on that package Mar 09 00:47:20 yet bitbake is insisting on building it Mar 09 00:47:45 there is a class in oe that generated nice pngs that show why something ended up in images. Mar 09 00:48:13 For now, I've deleted the lines from the task I'm not using Mar 09 00:48:24 it's a hack, but I have to have built images by tomorrow morning for a demo :-( Mar 09 00:48:26 if it only builds it you shouldn't care. There are much things that are only needed at build time and won't end up in images. Mar 09 00:48:51 I care because it can't be built Mar 09 00:48:55 so bitbake stops Mar 09 00:50:06 The image I'm building is for a machine where the bitbake can't build a suitable kernel because I'm still writing the kernel patches, but this package *depends* on having a kernel which it can build against Mar 09 00:50:11 hence the annoyance :_( Mar 09 00:50:51 good night Mar 09 00:53:57 Oh crap, now the linux-dummy package is failing to build Mar 09 00:54:16 flo_lap: night Mar 09 00:55:30 if this hack works for you use it until you can ask somebody in #poky ;) Mar 09 00:55:42 aye Mar 09 00:55:53 urgh, I hate trying to get these things working Mar 09 00:56:52 NOTE: package linux-dummy-1.0-r0: task do_package_write_ipk: started Mar 09 00:56:52 *** Error: CONTROL/control is missing field Source Mar 09 00:56:58 any idea how to shut that up? Mar 09 00:59:31 If not, don't worry, I'll hack around it by allowing it to build a kernel which I can discard later Mar 09 00:59:34 * Kinnison sighs Mar 09 01:13:51 psokolovsky: btw. I have nearly a new generic initramfs-kernel solution ready. It can't build initramfs-images with different libc, but with klibc this will not be necessary. Mar 09 01:14:32 psokolovsky: I will rfc it next week. Mar 09 01:14:54 thesing: cool Mar 09 01:15:05 thesing: thanks for your help Mar 09 01:15:11 thesing: It's finally building a rootfs Mar 09 01:15:14 * Kinnison can go to bed at last Mar 09 01:15:24 thesing: and for now, it seem that kexec-static built against klibc doesn't support command line Mar 09 01:17:15 psokolovsky: strange. I have an idea what the issue could be. I will look into this asap. Mar 09 01:18:00 thanks! Mar 09 01:19:09 psokolovsky: but it works with normal kexec? Mar 09 01:19:36 thesing: yes Mar 09 01:20:40 thesing: moee exactly, it works with kexec-static from stable, which is built against uclibc Mar 09 01:39:53 psokolovsky: I tested kexec-static on my collie and command line support works fine. Mar 09 01:40:40 thesing: from .dev? Mar 09 01:41:07 psokolovsky: I did "./kexec --command-line="" -l zImage; kexec -e" and got a "no root device found" panic as expected. Mar 09 01:41:18 psokolovsky: yes. Mar 09 01:41:41 thesing: ;-) Mar 09 01:42:03 thesing: when command line passing doesn't work, it's equivalent of --command-line="" Mar 09 01:42:16 psokolovsky: Maybe its an eabi issue. Mar 09 01:42:57 psokolovsky: I also tried readding my serial console and it worked too. Mar 09 01:50:20 * thesing -> bed. Mar 09 01:50:23 night all. Mar 09 01:57:36 zecke: I think I've fixed qsvn Mar 09 02:06:29 03rpurdie 07org.oe.dev * ra4f53c2d... 10/ (1 packages/libtool/libtool-cross_1.5.10.bb): libtool-cross: Make sure patches changes are applied to the staged libtool Mar 09 02:06:34 03rpurdie 07org.oe.dev * r103af779... 10/ (5 files in 3 dirs): apr: Add 1.2.12 verison, stage all needed files, sed staged build scripts to remove workdir paths, run full autoreconf and patch to resolve reconf issues Mar 09 02:06:39 03rpurdie 07org.oe.dev * re2bd5c16... 10/ (5 files in 3 dirs): apr-util: Add 1.2.12 version, run full autoreconf and match apr changes Mar 09 02:06:43 03rpurdie 07org.oe.dev * r89d5e8d1... 10/ (1 packages/subversion/subversion_1.4.5.bb): subversion-1.4.5: Run full autoreconf Mar 09 02:06:48 03rpurdie 07org.oe.dev * r7115d904... 10/ (4 files in 2 dirs): qt4: Make sure staged .la and .prl files do not contain target system paths Mar 09 02:06:53 03rpurdie 07org.oe.dev * r9ea3802f... 10/ (1 site/arm-linux): site/arm-linux: Add /dev/zero test result for apr Mar 09 02:18:09 03rpurdie 07org.oe.dev * rcb33e6ea... 10/ (11 files in 2 dirs): libtool: Add .inc file (from poky) **** ENDING LOGGING AT Tue Mar 18 21:11:42 2008