IRC log for #oe on 20080308

00:30.05cdbot2* * OE Bug 3965 has been created by yan(AT)seiner.com
00:30.07cdbot2* * Slow resume with libertas wifi
00:30.09cdbot2* * http://bugs.openembedded.net/show_bug.cgi?id=3965
00:33.22*** join/#oe Marex (n=marex@gwfm10-3-250.802.cz)
00:41.53*** join/#oe wrobbie (n=rob@cm38.kappa85.maxonline.com.sg)
00:49.41*** join/#oe mithro (n=tim@ppp246-117.static.internode.on.net)
00:54.04cdbot2* * OE Bug 3966 has been created by <OE-Autobuilder>
00:54.06cdbot2* * openmoko-browser2-0.0.1+svnr3646-r2-do_compile
00:54.08cdbot2* * http://bugs.openembedded.net/show_bug.cgi?id=3966
01:20.19*** join/#oe punkass (n=user@unaffiliated/punkass)
01:24.36*** join/#oe wick728 (n=zsirc@63.135.128.119)
01:29.48*** join/#oe nnn0 (n=nnn0@unaffiliated/nnn0)
01:29.51*** part/#oe nnn0 (n=nnn0@unaffiliated/nnn0)
01:31.02*** join/#oe Marex (n=marex@gwfm10-3-250.802.cz)
01:31.54*** join/#oe bluelightning (n=blueligh@222-154-186-210.jetstream.xtra.co.nz)
01:33.11*** join/#oe benlau (n=benlau@221.125.8.105)
01:51.22thesing_night all
02:24.26CIA-3803thesing 07org.oe.dev * rbe3d3cb0... 10/ (7 files in 3 dirs): klibc, klibc-utils-static: add losetup and modprobe to klibc-utils
03:06.19*** join/#oe mzb (n=ubernut@ppp108-88.static.internode.on.net)
03:14.48*** join/#oe pb_ (n=pb@castle.reciva.com)
03:43.24*** join/#oe AvengerMoJo (n=alex@219.142.242.162)
04:07.05cdbot2* * OE Bug 3967 has been created by <OE-Autobuilder>
04:07.06cdbot2* * kismet-2007-10-R1-r5-do_patch
04:07.09cdbot2* * http://bugs.openembedded.net/show_bug.cgi?id=3967
04:15.04cdbot2* * OE Bug 3968 has been created by <OE-Autobuilder>
04:15.06cdbot2* * orbit2-2.14.0-r2-do_compile
04:15.08cdbot2* * http://bugs.openembedded.net/show_bug.cgi?id=3968
04:38.12*** join/#oe jkilb_ (n=jkilb@p5B20ABA0.dip0.t-ipconnect.de)
04:40.36*** join/#oe davygravy (n=davygrav@h75-100-80-221.75-100.unk.tds.net)
04:47.31*** join/#oe yansa (n=yans@host-89-230-211-114.lublin.mm.pl)
05:18.44*** join/#oe loudawg (n=loudawg@cpe-76-176-76-233.san.res.rr.com)
05:19.55loudawghi all, I'm trying to build for the first time and am running into some issues.  First it failed looking for "defconfig" for the kernel, but I'm pretty sure I did the right thing by copying the one for my device to the parent directory where it was looking for it.  Maybe I should've symlinked it but oh well.  So I have one more problem now:
05:20.55loudawg| /home/loudawg/openembedded/bitbake/tmp/deploy/uclibc/images/aximx50v/initramfs-bootmenu-image-aximx50v.cpio.gz does not exist, you may need to bitbake it separately
05:21.21loudawgI noticed that there's a glibc directory, but not uclibc.  Do I need to set something to have it build a uclibc based system instead?
05:22.47*** join/#oe zecke (n=ich@118-166-68-156.dynamic.hinet.net)
05:27.22*** join/#oe JustinP (n=papercra@c-98-207-74-83.hsd1.ca.comcast.net)
05:40.48*** join/#oe jbs (n=Bernardo@89-180-30-19.net.novis.pt)
05:52.49*** join/#oe marek` (i=jdegges@s77-92.resnet.ucla.edu)
05:54.14*** join/#oe hvontres|home (n=hvontres@adsl-75-15-87-17.dsl.sndg02.sbcglobal.net)
06:17.13*** join/#oe wicknix (n=wicked@63.135.132.204)
06:26.05cdbot2* * OE Bug 3969 has been created by <hvontres>
06:26.07cdbot2* * opie image uses MACHINE_TASK_PROVIDER which defaults to task-base
06:26.09cdbot2* * http://bugs.openembedded.net/show_bug.cgi?id=3969
06:26.26*** join/#oe bluelightning (n=blueligh@222-154-185-1.jetstream.xtra.co.nz)
06:36.37*** join/#oe Khem_ (n=khem@adsl-71-146-14-189.dsl.pltn13.sbcglobal.net)
06:45.33*** join/#oe khem (n=KhemWork@nat/montavista/x-918496715ecf93f0)
06:47.45*** join/#oe KhemWork (n=KhemWork@nat/montavista/x-9cbdf2cf34dcd37d)
06:49.34*** join/#oe Khem (n=khem@adsl-71-146-14-189.dsl.pltn13.sbcglobal.net)
07:09.05cdbot2* * OE Bug 3970 has been created by <OE-Autobuilder>
07:09.07cdbot2* * vim-7.0-r1-do_configure
07:09.09cdbot2* * http://bugs.openembedded.net/show_bug.cgi?id=3970
07:11.02*** join/#oe wrobbie (n=rob@cm38.kappa85.maxonline.com.sg)
07:12.04cdbot2* * OE Bug 3971 has been created by <OE-Autobuilder>
07:12.07cdbot2* * mc-4.6.1-r2-do_configure
07:12.09cdbot2* * http://bugs.openembedded.net/show_bug.cgi?id=3971
07:13.05cdbot2* * OE Bug 3972 has been created by <OE-Autobuilder>
07:13.07cdbot2* * screen-4.0.2-r2-do_configure
07:13.09cdbot2* * http://bugs.openembedded.net/show_bug.cgi?id=3972
07:19.30*** join/#oe polyonymous_ (n=hacker@pD953AC6E.dip0.t-ipconnect.de)
07:28.47*** join/#oe daurnimator (i=daurn@unaffiliated/daurnimator)
07:35.14*** join/#oe russf (n=russf@host86-156-111-23.range86-156.btcentralplus.com)
07:59.04cdbot2* * OE Bug 3973 has been created by <OE-Autobuilder>
07:59.06cdbot2* * mono-1.2.6-r1-do_configure
07:59.08cdbot2* * http://bugs.openembedded.net/show_bug.cgi?id=3973
08:01.13*** join/#oe |miska| (i=miska@atrey.karlin.mff.cuni.cz)
08:08.28*** join/#oe kristoffer (n=kristoff@62.209.186.97)
08:26.39*** join/#oe jekhor (n=jek@mm-166-254-57-86.leased.line.mgts.by)
08:32.03cdbot2* * OE Bug 3974 has been created by <OE-Autobuilder>
08:32.05cdbot2* * mysql-4.1.18-r3-do_configure
08:32.07cdbot2* * http://bugs.openembedded.net/show_bug.cgi?id=3974
08:47.53*** join/#oe Terminar (i=rues@rdgw1.rother-data.com)
08:48.17*** join/#oe Khem_ (n=khem@adsl-71-146-14-189.dsl.pltn13.sbcglobal.net)
08:51.13*** join/#oe ssvb (n=user@87.252.225.64)
08:53.14*** join/#oe gremlin[it] (n=gremlin@ppp-230-43.25-151.libero.it)
08:54.04cdbot2* * OE Bug 3975 has been created by <OE-Autobuilder>
08:54.06cdbot2* * qt4-x11-free-4.3.3-r7-do_configure
08:54.09cdbot2* * http://bugs.openembedded.net/show_bug.cgi?id=3975
08:59.05cdbot2* * OE Bug 3976 has been created by <OE-Autobuilder>
08:59.07cdbot2* * libcroco-0.6.1-r2-do_compile
08:59.09cdbot2* * http://bugs.openembedded.net/show_bug.cgi?id=3976
08:59.17cdbot2* * OE Bug 3977 has been created by <OE-Autobuilder>
08:59.19cdbot2* * osb-jscore-0.5.2+svnr117-r1-do_compile
08:59.21cdbot2* * http://bugs.openembedded.net/show_bug.cgi?id=3977
09:13.04cdbot2* * OE Bug 3978 has been created by <OE-Autobuilder>
09:13.06cdbot2* * libidl-0.8.6-r3-do_compile
09:13.08cdbot2* * http://bugs.openembedded.net/show_bug.cgi?id=3978
09:29.13*** join/#oe jekhor (n=jek@mm-166-254-57-86.leased.line.mgts.by)
09:33.04cdbot2* * OE Bug 3979 has been created by <OE-Autobuilder>
09:33.06cdbot2* * linux-handhelds-2.6-2.6.21-hh20-r15-do_compile
09:33.08cdbot2* * http://bugs.openembedded.net/show_bug.cgi?id=3979
09:36.10*** join/#oe zap (n=zap@28.169.249.ozerki.net)
09:37.11*** join/#oe benlau (n=benlau@221.125.8.105)
09:37.46*** join/#oe rd_ (n=dr@vnsecurity.net)
09:42.47*** join/#oe rob_w (n=bob@M873b.m.pppool.de)
09:57.01*** join/#oe johnx (n=john@softbank221106232002.bbtec.net)
10:24.33*** join/#oe cyrilRomain (n=cyrilRom@AToulouse-157-1-14-39.w86-201.abo.wanadoo.fr)
10:24.40cyrilRomaingm
10:24.51*** join/#oe Khem (n=khem@adsl-71-146-14-189.dsl.pltn13.sbcglobal.net)
10:29.00*** join/#oe Sleep-Walker (n=Sleep@195.22.44.103.adsl.nextra.cz)
10:33.37CIA-3803koen 07org.oe.dev * re0ff8944... 10/ (1 conf/distro/angstrom-2008.1.conf): angstrom 2008: ask for initramfs file, not its symlinke
10:34.15CIA-3803koen 07org.oe.dev * r507c64fd... 10/ (3 files in 3 dirs): linux-handhelds 2.6.21-hh20: add patch to stop the kernel from blowing away our initramfs archive
10:39.00*** join/#oe pH5 (n=ph5@p5485F235.dip.t-dialin.net)
10:39.01*** join/#oe ant|work (n=ant|work@host214-85-static.34-85-b.business.telecomitalia.it)
10:39.23ant|workg'morning
10:40.31ant|workcyrilRomain: hey
10:45.08CIA-3803koen 07org.oe.dev * rea4c245b... 10/ (9 files in 3 dirs): bluez: update to latest releases
10:45.38*** join/#oe Marex (n=marex@gwfm10-3-250.802.cz)
10:52.10johnxis there a known issue with ipkg on oabi platforms?
10:59.53*** join/#oe yansa (n=yans@host-89-230-211-114.lublin.mm.pl)
11:01.36*** join/#oe treitmayr (n=thomas@85-127-84-15.dynamic.xdsl-line.inode.at)
11:02.59*** join/#oe mrdata (i=unknown@dslb-088-074-144-172.pools.arcor-ip.net)
11:09.49*** join/#oe zecke (n=ich@118-166-68-156.dynamic.hinet.net)
11:10.52cyrilRomainhey ant|work
11:11.01cyrilRomainzecke: hey
11:11.28cyrilRomainzecke: can you please help me using mtn2git.py ? :)
11:13.04cyrilRomainzecke: on IRC logs, I could find something like 'mtn2git -d ~/theDB.mtn | git-fast-import --date-format=rfc2822"
11:13.32cyrilRomainand it seems to work (.git directory is filled)
11:13.32zeckecyrilRomain: isn't there a readme?
11:13.48zeckecyrilRomain: at least there is mtn2git --help and man git-fast-import :)
11:14.28cyrilRomainyes I looked at 'mtn2git --help'
11:15.14*** join/#oe pH5 (n=ph5@p5485F235.dip.t-dialin.net)
11:15.15cyrilRomainthe problem is then 'git log' or 'git status' doesn't return things
11:15.48zeckecyrilRomain: after the import?
11:15.56cyrilRomainyes
11:16.14zeckecyrilRomain: git-branch -a says what?
11:17.54lisppaste7zecke pasted "mtn2git driver" at http://paste.lisp.org/display/57020
11:18.14zeckethat is the script I run when someone asks me to update the mirror
11:18.47cyrilRomainzecke: it list the branches :) I was too stupid not to run that command, so what I was missing is just a 'git checkout' :)
11:18.50cyrilRomainzecke: thanks :)
11:19.07zeckecyrilRomain: what did you convert? the whole of OE?
11:19.40cyrilRomainzecke: no, just another mtn database in which I have some OE related stuff
11:20.12cyrilRomainzecke: it worked like a charm ! Thanks for this wonderfull script :)
11:20.56treitmayrHi! 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."
11:20.57cyrilRomainzecke: so do you now use git only when working on OE ?
11:21.10treitmayrDoes this mean I have to flush my whole tmp directory?
11:21.41zecketreitmayr: yes, or don't use current org.openembedded.dev
11:22.09zecketreitmayr: we have enabled sysroot on gcc, which required a change to our tmp/staging directory
11:22.12treitmayrzecke: thanks, just wanted to make sure I am doing the right thing
11:22.30treitmayrzecke: I read about it but was not sure if its already in effect
11:22.39treitmayrthanks!
11:22.44zecketreitmayr: :)
11:28.28*** join/#oe |miska| (i=miska@atrey.karlin.mff.cuni.cz)
11:29.15ant|workcan someone confirm this commit has been pushed? --> [20080308 03:24:26] <CIA-38>   thesing ^C07org.oe.dev * rbe3d3cb0... / (7 files in 3 dirs): klibc, klibc-utils-static: add losetup and modprobe to klibc-utils
11:29.36ant|workI don't see it using viewmtn
11:30.03*** join/#oe Laibsch (n=Laibsch@ip-62-143-227-114.1411N-CUD12K-01.ish.de)
11:32.40ant|workneither here http://www.openembedded.org:1081/branch/changes/org.openembedded.dev?q=viewmtn/branch/changes/org.openembedded.dev
11:32.50ant|worknor here http://lists.linuxtogo.org/pipermail/openembedded-commits/2008-March/thread.html
11:33.02ant|workboth are out of sync?
11:38.56CIA-3803pfalcon 07org.oe.dev * r0ddcb5d9... 10/ (3 files in 2 dirs):
11:38.56CIA-38linux-handhelds-2.6: Fix some initramfs support issues.
11:38.56CIA-38* Be sure to clean up any possible old initramfs.
11:38.56CIA-38* Fix bashism.
11:44.28rob_wwhats the deal with avr32 .. i read the mails but i cant get it
11:45.04cdbot2* * OE Bug 3980 has been created by <OE-Autobuilder>
11:45.06cdbot2* * makedevs-1.0.0-r5-do_compile
11:45.08cdbot2* * http://bugs.openembedded.net/show_bug.cgi?id=3980
11:46.41*** join/#oe benlau (n=benlau@221.125.8.105)
11:52.25*** join/#oe thesing (n=tkunze@BAEcfd4.bae.pppool.de)
11:52.40thesingmorning everybody
11:53.28thesingRP: my girlfriend said the only thing missing in the poky image for spitz is a sudoku game ;)
11:55.41thesingRP: 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?
11:57.29mrdatamorning thesing
12:00.27CIA-3803mickeyl * r1028 10bitbake/ (ChangeLog lib/bb/cooker.py): cooker: fix traceback when using -b and -f together
12:01.12CIA-3803mickeyl 07bitbake-1.8 * r1029 10/ (ChangeLog lib/bb/cooker.py): 1.8.x/cooker: backport -f and -b fix from trunk
12:02.39*** join/#oe XorA (n=XorA@www.xora.org.uk)
12:03.48zeckeXorA: hey, did you progress on Qtopia/X11 packaging yesterday?
12:14.33CIA-3803mickeyl 07org.oe.dev * rdf77e731... 10/ (3 files in 2 dirs): cmake-native 2.4.8 write proper do_stage
12:18.31CIA-3803mickeyl 07org.oe.dev * rdf77e731... 10/ (3 files in 2 dirs): cmake-native 2.4.8 write proper do_stage
12:19.06CIA-3803mickeyl 07org.oe.dev * r75880ed5... 10/ (5 files in 2 dirs): wireless-tools: remove .29 prereleases, add .29 release, refactor .inc file
12:19.10XorA|gonezecke: qpe runs, but fonts dont work
12:19.14CIA-3803mickeyl 07org.oe.dev * racc74e7e... 10/ (1 packages/python/python-gsmd_svn.bb): python-gsmd svn fix SRC_URI
12:19.20CIA-3803mickeyl 07org.oe.dev * r42eff260... 10/ (1 packages/python/python-pyiw_0.3.3.bb): python-pyiw 0.3.3 fix unpacking
12:19.23CIA-3803mickeyl 07org.oe.dev * ra165e975... 10/ (1 packages/tasks/task-python-everything.bb): task-python-everything: catch up with renaming
12:19.42XorA|gonezecke: I now have to fix an OE issue we have avoided for years
12:19.50zeckeXorA|gone: installed the desktop files? xmodmap's added? font don't work in which way?
12:20.11XorA|gonezecke: the bar qpe puts at the bottom, all [] where text should be
12:21.46XorA|gonezecke: but on monday I need to fixup an xsession file and make it selectable
12:22.02zeckeXorA|gone: no text drawn? wrong glyphs? wrong size? don't get what [] means? is that empty text, is that the glyph's drawn?
12:22.05XorA|gonezecke: and probably whach illume crash horribly and find out reasons that does
12:22.21XorA|gonezecke: thats a square which is drawn instead of character
12:22.49zeckeXorA|gone: ah okay, wrong glyphs then
12:23.09XorA|gonenormally caused by UTF conversion issues
12:31.45*** join/#oe pvanhoof (n=pvanhoof@d54C0EE14.access.telenet.be)
12:32.44*** join/#oe Sup3rkiddo (n=sudharsh@unaffiliated/sudharsh)
13:02.14*** join/#oe stefan_schmidt (n=stefan@sirius.lasnet.de)
13:09.39*** join/#oe timtimred (n=On3@82-34-50-106.cable.ubr02.chel.blueyonder.co.uk)
13:10.39CIA-3803thesing 07org.oe.dev * r2c5004d7... 10/ (1 packages/linux/gumstix-linux.inc packages/linux/linux.inc):
13:10.39CIA-38linux.inc, gumstix-kernel.inc: remove sizecheck stuff
13:10.39CIA-38The do_sizecheck function is in kernel.bbclass for some time now.
13:12.17RPthesing: We really need to fix the patch
13:14.04thesingRP: 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?
13:15.22RPthesing: Yes, people need to know about that kind of change
13:18.07*** join/#oe lrg (n=liam@lrg2.demon.co.uk)
13:19.07thesingRP: 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)
13:20.26zeckeRP: apparently you did not test building the other major toolkit with the sysroot changes :)
13:22.35RPzecke: ah :/. Give me a problem case and I'll take a look ;-)
13:23.01zeckeRP: it might be too ugly to look at, I will try to find time...
13:23.24zeckeRP: but I think qmake needs to be aware of sysroot
13:23.30zecke*time* *where is the time*
13:24.27RPzecke: Is there  a specific package failure example I can look at?
13:24.43RPthesing: How's this going to work with initfs images which need kernel modules?
13:24.47zeckeRP: bitbake qsvn should fail, at least I'm testing it now :)
13:25.29zeckeRP: but sysroot can make some of the qmake/qt stuff better...
13:27.06RPzecke: 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 :/
13:27.35RPUnless it has some hardcoded layout assumptions?
13:27.40zeckeRP: :)
13:27.48*** join/#oe kristoffer (n=kristoff@62.209.186.97)
13:28.47RPzecke: ;-)
13:29.23*** join/#oe Timelord (n=TL@16.8c.d12c.cidr.airmail.net)
13:30.16*** join/#oe russf (n=russf@host86-156-111-23.range86-156.btcentralplus.com)
13:31.51zeckeand I'm sick of mtn :)
13:32.08RPzecke: ready for git?
13:32.53zeckeI 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 :)
13:33.01zeckeyeah, definately ready for git
13:33.54RPzecke: A branch would have perhaps been better, yes. Live and learn I guess...
13:34.17RPzecke: I think if you propose switching not many people will object
13:34.40zeckeRP: I know why we don't do this with mtn, but it is disgusting to deploy bad engineering because your SCM system is broken :)
13:35.02zeckehmm I'm either just tired ATM or a bit frustrated.. dunno why :)
13:36.00RPzecke: Due to the ABI change, I doubt many people would have tested a branch anyway
13:36.49RPzecke: I did promise to try and timely fix reported issues, you've reported this one so I have a promise to keep now ;-)
13:38.12zeckeRP: if it breaks, it is my issue though...
13:38.40zeckeRP: probably true on the ABI change, but then people can not complain
13:39.01*** join/#oe treitmay1 (n=thomas@85-127-87-103.dynamic.xdsl-line.inode.at)
13:39.18RPzecke: It would have had that adavantage
13:39.45zeckeRP: and I would probably start builds for the stuff I care :)
13:40.10RPzecke: Yes, I think you're one of the few who would :)
13:41.11*** part/#oe treitmay1 (n=thomas@85-127-87-103.dynamic.xdsl-line.inode.at)
13:41.13*** join/#oe treitmay1 (n=thomas@85-127-87-103.dynamic.xdsl-line.inode.at)
13:41.56*** part/#oe treitmay1 (n=thomas@85-127-87-103.dynamic.xdsl-line.inode.at)
13:42.56thesingRP: 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
13:43.51thesingRP if INITRAMFS_IMAGE is not set buildin_initramfs does nothing, all other task behave as they do now except splitted packaging.
13:44.27RPthesing: I'm not sure I ever suggested split packaging like that
13:45.04thesingRP: no you suggested a second packaging. But this does package the modules twice.
13:45.49*** join/#oe gerwinin (n=holograp@ip5457b30e.direct-adsl.nl)
13:46.18thesingRP: This may not be the best solution but its without recursive bitbake and generic for all kernels.
13:46.43RPthesing: 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
13:46.50thesingRP: but the initramfs has to be build with the same libc (or use klibc which is a special case)
13:47.07RPthesing: I think you will hit issues with the approach ;/
13:48.20thesingRP: What issues?
13:49.05RPthesing: 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 ?
13:50.13*** join/#oe ant (n=ant@host112-251-dynamic.9-87-r.retail.telecomitalia.it)
13:50.22*** join/#oe treitmayr (n=thomas@85-127-87-103.dynamic.xdsl-line.inode.at)
13:51.01RPSimpler 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
13:51.31RPMachines would select this approach by declaring their preferred kernel providers accordingly
13:51.39antRP:Thesing: don't you think the whole initramfs thing should be treated separately (a.k.a. new.bb) like other bootloader / firmware stuff?
13:52.00thesingBut distros could not decide if they want initramfs or not.
13:52.26*** join/#oe florian (n=fuchs@217.146.132.69)
13:52.46antat least for the kexec, replacin broken bootloaders, I'd say install once and forget about
13:53.13*** join/#oe dcordes (n=snoopdog@unaffiliated/dcordes)
13:53.38thesingant: this discussion is more about the backend ;)
13:54.28antyea, but you do need an uclibc pass anyway...
13:54.45antwhich complicated the matter
13:55.07thesingant: no uclibc is not needed eventually (because the initramfs only uses klibc)
13:55.30antI'm confident you'll win !
13:55.49antagainst klibc ;-)
13:57.26thesingRP: how about having a kernel-modules-bb and reusing its workdir for the kernel-bb?
13:59.29RPthesing: 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
14:01.45thesingRP: do you mean s/initramfs/modules/?
14:02.59RPthesing: 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
14:03.13RPis that clearer?
14:04.55florianhi all
14:05.02RPhi florian
14:06.25thesingRP: 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.
14:08.28RPthesing: I don't think it will work. How will you solve the do_package_write issue I mentioned above?
14:10.56thesingRP: 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.
14:12.26RPthesing: but the point of creating this initramfs package is so you can include it in some rootfs image?
14:12.28*** join/#oe flo_lap (n=fuchs@217.146.132.69)
14:13.27thesingRP: no the initramfs package generate an image that can included in a kernel. This kernel can be included by some (not initramfs) image.
14:14.13RPthesing: Will generating this (not initramfs) image be a separate bitbake command?
14:15.23RPzecke: Does apt-util build for you?
14:15.29RPapr-util
14:17.01thesingRP: not necessarily.
14:17.33RPthesing: 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
14:17.43*** join/#oe gremlin[it] (n=gremlin@ppp-79-111.25-151.libero.it)
14:18.13RPThis is a circular depends loop which is what I want to avoid
14:18.59thesingRP: no the initramfs will have a dependency on kernel-modules:do_package_write as it only include kernel modules and no kernel.
14:19.43RPthesing: "kernel-modules" is a seperate .bb file?
14:20.20thesingRP: yes.
14:20.30RPthesing: So every kernel needs a separate .bb file?
14:22.00thesingRP: I think we can share this by doing some magic with virtual/kernel.
14:22.57RPthesing: So we only have one .bb file?
14:23.22thesingRP: yes I think so.
14:23.31RPthesing: It won't work like that
14:24.04RPI don't see how you can do "magic with virtual/kernel" without two .bb file as I previously mentioned
14:26.23*** join/#oe rschuster (n=rob@e178097195.adsl.alicedsl.de)
14:27.12thesingRP: 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.
14:27.49pH5thesing: would kernel.bb and kernel-modules.bb operate on the same workdir?
14:28.11thesingpH5: yes
14:35.48*** join/#oe |miska| (i=miska@atrey.karlin.mff.cuni.cz)
14:38.02zeckeRP: it did the last time :(
14:41.04cdbot2* * OE Bug 3981 has been created by <OE-Autobuilder>
14:41.07cdbot2* * klibc-1.5-r6-do_compile
14:41.08cdbot2* * http://bugs.openembedded.net/show_bug.cgi?id=3981
15:05.30*** join/#oe aloisiojr (n=aloisio@189.70.87.155)
15:11.04cdbot2* * OE Bug 3982 has been created by <OE-Autobuilder>
15:11.06cdbot2* * linux-handhelds-2.6-2.6.21-hh20-r16-do_compile
15:11.08cdbot2* * http://bugs.openembedded.net/show_bug.cgi?id=3982
15:12.09*** join/#oe CSMan (n=csman@bas6-montrealak-1128592555.dsl.bell.ca)
15:18.09*** join/#oe woglinde (i=woglinde@e178094169.adsl.alicedsl.de)
15:21.05cdbot2* * OE Bug 1208 has been RESOLVED (FIXED) by <mickeyl>
15:21.06cdbot2* * New bbclass - initramfs
15:21.08cdbot2* * http://bugs.openembedded.org/show_bug.cgi?id=1208
15:27.48*** join/#oe TheCan (n=thecan@dslb-088-067-143-082.pools.arcor-ip.net)
15:32.17*** join/#oe osas (n=nnnnnnnn@nslu2-linux/osas)
15:41.04cdbot2* * OE Bug 1262 has been RESOLVED (FIXED) by <mickeyl>
15:41.06cdbot2* * Bitbake complains about LEAD_SONAME building ncurses-5.4-r8
15:41.08cdbot2* * http://bugs.openembedded.org/show_bug.cgi?id=1262
15:42.05cdbot2* * OE Bug 1382 has been RESOLVED (FIXED) by <mickeyl>
15:42.07cdbot2* * qmake does not exist in oe
15:42.08cdbot2* * http://bugs.openembedded.org/show_bug.cgi?id=1382
15:45.05cdbot2* * OE Bug 1575 has been RESOLVED (INVALID) by <mickeyl>
15:45.07cdbot2* * ACE 5.5 bb file
15:45.09cdbot2* * http://bugs.openembedded.org/show_bug.cgi?id=1575
15:54.03mwesterGreetings and Salutations
15:54.11florianhi mwester
15:58.10CIA-3803mickeyl 07org.oe.dev * rc76638bd... 10/ (4 files in 2 dirs): ncurses 5.4 revamp packaging. closes #1262
15:58.15CIA-3803mickeyl 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
15:58.28florian~lart koen
15:58.28ibottakes large quantities of Krispy Kream donuts and stuffs them one after another down koen's throat until koen puts on 150lbs
15:59.07woglindeflorian what happened?
15:59.35*** join/#oe loudawg (n=loudawg@cpe-76-176-76-233.san.res.rr.com)
15:59.35florianwoglinde: looks like the x11 gpe image does not have a screenshot tool
16:00.03RPhi mwester
16:00.33florianI should do more kernel hacking
16:00.51RPthesing: This was why I preferred the idea of a single extra .bb file for the initramfs rather than one per kernel recipe
16:20.10thesingRP: how do I get workdir, PV etc. from virtual/kernel in initramfs-kernel.bb then?
16:21.07RPthesing: You don't, you just depend on a task in the other .bb
16:21.21RPThat task puts something into staging
16:24.27*** join/#oe yansa (n=yans@host-89-230-211-114.lublin.mm.pl)
16:26.07pH5why 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?
16:28.08*** join/#oe jekhor (n=jek@mm-166-254-57-86.leased.line.mgts.by)
16:28.44RPpH5: People want "gpe-image" to include building the initramfs image and that include that into a kernel
16:29.41thesinginitramfs-kernel would need to package a file from deploydir then.
16:30.02RPthesing: or staging
16:30.42thesingis this ok? this seems a little bit dirty to me.
16:31.02RPthesing: I think its the only option available
16:31.49thesingant there is no python-foo got get workdir etc  of virtual/kernel?
16:32.13RPthesing: Touching another workdir from a recipe is a bug. It will break rm_work
16:33.04thesingRP: we preserve workdir for linux-rp anyways for wlan-ng.
16:33.27RPthesing: Yes, but that is a nasty hack
16:33.36RPthesing: I don't really agree with that
16:34.09RPnastier than staging the kernel to package in another .bb, certainly
16:34.42thesingRP: rm_work only deletes ${S}, does it?
16:35.05RPthesing: I think so
16:36.31thesinganother 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}
16:38.30*** join/#oe rschuster (n=rob@e178097195.adsl.alicedsl.de)
16:38.38RPthesing: Two recipes adds some code but not a lot...
16:38.52*** join/#oe vivijim (n=vivijim@189.70.87.155)
16:38.53RPShared work directories are not what we currently support
16:39.14RPIf anyone wants to start supporting them we need a really good reason for it
16:40.14thesingit doesn't make packaging files from staging or somewhere else necessary.
16:41.36*** part/#oe vivijim (n=vivijim@189.70.87.155)
16:41.51thesingWhat 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.
16:42.41RPthesing: It makes the system more complex and changes the expected behaviours
16:43.00RPthesing: Its not something we can do without careful consideration
16:43.14RPThe design is that shared data goes into staging
16:43.30RPWhat's wrong with that design?
16:44.25thesingok how to make sure that package A finds the data package B puts there? And can A delete the data after it used it?
16:44.47RPA DEPENDS on B or has some other dependency
16:45.00RPand no, it cannot delete the data, why would it want to do that?
16:45.57thesingbecause its not needed after A run. (ok except you rebuild A)
16:46.26RPthesing: Do we delete libs from staging after something links against them?
16:46.43thesingyou're right.
16:47.04thesingok. where to put the data in staging dir?
16:47.23RPThat is a good question :)
16:47.51RPSomewhere in STAGING_KERNEL_DIR?
16:48.17thesingand in the case of klibc?  and potential other packages?
16:48.45thesingI really think shared workdirs would be cleaner.
16:49.01*** join/#oe Sup3rkiddo (n=sudharsh@unaffiliated/sudharsh)
16:49.28thesingRP: btw. who is "team bitbake" besides you?
16:52.50RPthesing: 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
16:52.59RPthesing: zecke and mickeyl I guess
16:58.09*** join/#oe TheCan (n=thecan@dslb-088-067-143-082.pools.arcor-ip.net)
17:07.16*** join/#oe mr_nice (n=mr_nice@91-65-161-14-dynip.superkabel.de)
17:08.09woglindehi mr_nice
17:09.25mr_nicewoglinde: hi
17:09.43mrdatawoglinde: hi
17:11.44*** join/#oe helgeD (n=deller@mnhm-590f55d0.pool.einsundeins.de)
17:21.48*** join/#oe Sleep_Walker (n=Sleep@195.22.44.103.adsl.nextra.cz)
17:25.20*** join/#oe aloisiojr (n=aloisio@200.184.118.132)
17:26.58CIA-3803pfalcon 07org.oe.dev * r6d9b16cd... 10/ (3 files in 2 dirs): linux-handhelds-2.6: Use rm -f for stale initramfs cleanup.
17:27.13*** join/#oe wicknix (n=wicked@63.135.132.204)
17:27.54*** join/#oe vivijim (n=vivijim@189.70.87.155)
17:28.38thesingRP: do if shared workdirs where supported how would I get the workdir of another package?
17:32.38*** join/#oe hvontres|home (n=hvontres@adsl-75-15-87-17.dsl.sndg02.sbcglobal.net)
17:35.11RPthesing: You would have to devise a way to work that out
17:35.58RPthesing: This raises all kinds of questions though
17:36.49thesingRP: would it be necessary to extend bitbake for that or is some python enough?
17:38.27RPthesing: Well, it means recipe A needs to peek into recipe B's variable space
17:39.11RPwhilst bitbake stores some data on each recipe, WORKDIR isn't amongst it
17:40.16RPthesing: Also for things like "virtual/kernel" you'll have trouble working out which recipe is providing it without help from bitbake
17:40.48RPthesing: so yes, you'll need to extend bitbake
17:40.56RPthesing: and I'm not keen on the idea tbh
17:41.06thesingRP: ok. there shared workdirs die ;)
17:41.28XorA|goneand the workdir may no longer be there anyway :-)
17:41.35RPThis is why we have staging, so packages can share data
17:42.16*** join/#oe jdav_gone (n=james@d75-157-13-250.bchsia.telus.net)
17:42.17RPthesing: I'm not trying to be negative about these things but it really is a massive change in behaviour
17:42.28RPand would cause a lot of issues
17:43.57thesingRP: 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.
17:44.54RPthesing: You wouldn't use PV/PR. different versions coexisting in staging is a bad idea
17:45.58RPIf you recipe can't work out what PV/PR would be its usually a sign you shouldn't be using them
17:46.24RPbefore I get really annoyed with apr-util and libtool ;-)
17:51.28*** join/#oe hvontres1home (n=hvontres@adsl-75-15-87-17.dsl.sndg02.sbcglobal.net)
17:53.18hvontres1homeis MACHINE_TASK_PROVIDER still being used for "new" designs or is it a leftover from the task-base switchover?
18:00.41CIA-3803pfalcon 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.
18:00.45CIA-3803pfalcon 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.
18:02.14*** join/#oe gremlin[it] (n=gremlin@217.201.212.246)
18:12.02CIA-3803mickeyl 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.
18:18.07*** join/#oe schurig_home (n=schurig@frnk-590eae6b.pool.einsundeins.de)
18:19.41*** join/#oe vivijim (n=vivijim@200.184.118.132)
18:23.33CIA-3803pfalcon 07org.oe.dev * r1764f957... 10/ (3 files in 3 dirs): initramfs-module-bootmenu: Show only block devices with FSes supported for boot.
18:24.24*** join/#oe astro76 (n=jtaji@unaffiliated/astro76)
18:25.16vivijimhi
18:26.20schurig_homehi
18:27.18woglindehi schurig
18:34.57CIA-3803pfalcon 07org.oe.dev * r06ce69bd... 10/ (3 files in 3 dirs):
18:34.57CIA-38initramfs-module-bootmenu: If rootdelay= param was not passed, assume 2s delay still.
18:34.57CIA-38* So people who don't bother to set correct rootdelay still have good chance
18:34.57CIA-38for there SD/CF cards detected.
18:34.57CIA-38* To disable the feature, explicit rootdelay=0 should be passed on kernel
18:34.58CIA-38command line.
19:00.18*** join/#oe gints____ (n=gints@62.84.15.211)
19:11.59*** join/#oe Sleep_Walker (n=Sleep@r9bg204.net.upc.cz)
19:18.15*** join/#oe dcordes_ (n=snoopdog@unaffiliated/dcordes)
19:18.52*** join/#oe jekhor (n=jek@mm-166-254-57-86.leased.line.mgts.by)
19:35.05*** join/#oe pleemans (n=peter@d51A5E76A.access.telenet.be)
19:38.50*** join/#oe flo_lap (n=fuchs@f054162098.adsl.alicedsl.de)
19:45.04cdbot2* * OE Bug 3983 has been created by <OE-Autobuilder>
19:45.06cdbot2* * mono-1.2.6-r1-do_compile
19:45.09cdbot2* * http://bugs.openembedded.net/show_bug.cgi?id=3983
19:54.54*** join/#oe jekhor (n=jek@mm-166-254-57-86.leased.line.mgts.by)
19:56.11*** join/#oe chouimat|work (n=mchouina@r2351064.cidc.net)
19:59.12*** join/#oe cdm (n=cdm@pool-71-121-2-9.snfcca.dsl-w.verizon.net)
19:59.16*** join/#oe svolpe (n=Gerrath@unaffiliated/gerrath)
19:59.18cdmafternoon-ish
19:59.34cdmso, how does PACKAGES_DYNAMIC pull in kernel module packages into the rootfs?
19:59.50cdmI am getting all these nice ipk's but none of them are pulled in by default.
20:01.08cdmI see that kernel.bbclass pulled in kernel-module-* via PACKAGES_DYNAMIC but I don't really see where/how that gets used.
20:02.30*** join/#oe zecke (n=ich@118-166-68-156.dynamic.hinet.net)
20:03.20*** join/#oe aloisiojr (n=aloisio@189.70.87.155)
20:04.36svolpeWhat 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 :-)
20:05.18CIA-3803mickeyl 07org.oe.dev * ra7d0911c... 10/ (4 files in 2 dirs): gnutls (all) fix pkgconfig file at the proper location
20:07.22flo_lapsvolpe: hmm... we have a maemo image? that would be the one to fix imho
20:11.48svolpeflo_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.
20:12.05cdbot2* * OE Bug 3072 has been RESOLVED (FIXED) by <mickeyl>
20:12.07cdbot2* * A Mastermind-style game *.bb file
20:12.09cdbot2* * http://bugs.openembedded.org/show_bug.cgi?id=3072
20:12.17svolpeflo_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 :-)
20:12.39*** join/#oe _Krieger_ (n=warsword@ip233.15.airbites.od.ua)
20:13.37svolpeflo_lap, example: check out packages/maemo/hildon-home_0.8.20-2.bb
20:13.37_Krieger_please, make it possible to download oe-usermanual in html format in a tarball at once. PLEASE.
20:14.08zeckemoin
20:14.53flo_lapsvolpe: i'll check
20:15.00flo_lapzecke: hi
20:16.05*** join/#oe bluelightning (n=blueligh@219-89-44-58.dialup.xtra.co.nz)
20:18.00zecke*bac*
20:18.27zecke*back*
20:20.45flo_lapsvolpe: ah yes, that's really old and someone removed that special gtk package
20:22.08flo_lapsounds like koen or laibsch cleaning up :/
20:23.23flo_lapsvolpe: We have a set of maemo packages that is really old... and a part of updated ones in the maemo4 subdir
20:28.15hvontres|AFK_Krieger_: if you just want a local copy, you could check out the org.openembedded.documentation/ branch
20:31.31hvontres|AFKflo_lap: you must have long legs :)
20:32.07flo_laphvontres|AFK: heh, true... about 2km ;)
20:32.16svolpeflo_lap, I guess the maemo-image must be part of the really old stuff.
20:32.46flo_lapsvolpe: yes, i guess i checked that in when the 770 was released
20:41.39svolpeflo_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 :-)
20:44.06flo_lapsvolpe: hehe... ok :) check with the mamona guys, maye they have more bits already
20:44.28zeckenight
20:44.32*** join/#oe frank7d (n=afs@p549F2AD7.dip0.t-ipconnect.de)
20:44.54flo_lapI guess i would play with this pretty soon too
20:45.10flo_lapzecke: good night
20:45.34svolpeflo_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?
20:45.56svolpeflo_lap, plus I have write privs to oe so I could do more with it.
20:46.48flo_lapsvolpe: no idea, but getting their stuff upstream sounds like a good start
20:52.41Croftonhttp://pandora.bluwiki.com/
20:56.35*** join/#oe rob_w (n=bob@M873b.m.pppool.de)
20:57.02cdmno ideas on getting kernel modules to install into the rootfs image?
20:57.17*** join/#oe lrg (n=liam@lrg2.demon.co.uk)
20:58.29svolpeflo_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...
21:00.33hvontres|AFKflo_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#
21:01.32flo_lapcdm: all modules or particular ones?
21:02.45flo_lapsvolpe: sounds good
21:05.05*** join/#oe ibot (i=ibot@pdpc/supporter/active/TimRiker/bot/apt)
21:05.05*** topic/#oe is OpenEmbedded Developer Lounge | Web: http://www.openembedded.org | Bugtracker: http://bugs.openembedded.org | Repository: monotone.openembedded.org | This is not a distro support channel
21:06.45rob_wwhats the option to automaticly let tmp/work be removed while building ?
21:08.11flo_lapcdm: then just set MACHINE_EXTRA_RDEPENDS in the macheines conf
21:09.35flo_laprob_w: inherit rm_work
21:09.54rob_wcan i set this in a local.conf ?
21:10.15flo_laprob_w: yes
21:10.40pH5flo_lap: is 'INHERIT += "rm_work"' and 'inherit rm_work' the same?
21:10.50rob_wso 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 ?
21:12.12hvontres|AFKrob_w: if you want to ignore rm_work, just add do_rm_work() {
21:12.12hvontres|AFK}
21:12.34rob_wah right
21:12.34hvontres|AFKin your .bb file (see linux-rp.inc for an example)
21:12.39rob_wgot you
21:13.35flo_lappH5: hum... iirc "inherit" is the deprecated syntax, but i'm not sure
21:21.43*** join/#oe Bernardo (n=Bernardo@sourcemage/Bernardo)
21:22.08cdmflo_lap: cool, lemme try
21:26.46*** join/#oe Laibsch (n=Laibsch@ip-62-143-227-114.1411N-CUD12K-01.ish.de)
21:27.04cdbot2* * OE Bug 3984 has been created by <OE-Autobuilder>
21:27.06cdbot2* * gpe-mini-browser2-0.0.1+svn20080308-r0-do_configure
21:27.08cdbot2* * http://bugs.openembedded.net/show_bug.cgi?id=3984
21:30.38*** join/#oe psokolovsky (n=psokolov@78.164.227.166)
21:30.50psokolovskyHi!
21:30.51flo_laphello psokolovsky
21:31.17psokolovskyit seems that koen doesn't spend much time on irc either lately...
21:31.46flo_lappsokolovsky: yes someone mentioned that he decided not to use irc any more
21:31.59psokolovskyheh ;-)
21:32.24woglindehi psokolovsky
21:36.04cdbot2* * OE Bug 3985 has been created by <OE-Autobuilder>
21:36.06cdbot2* * speech-dispatcher-0.6.5-r7-do_configure
21:36.08cdbot2* * http://bugs.openembedded.net/show_bug.cgi?id=3985
21:37.07*** join/#oe davygravy_ (n=davygrav@h75-100-81-154.75-100.unk.tds.net)
21:37.53*** join/#oe scruggs (n=chris@72-161-98-68.dyn.centurytel.net)
21:46.30*** part/#oe rschuster (n=rob@e178097195.adsl.alicedsl.de)
21:46.54*** join/#oe hillct (n=H@cpe-024-211-242-232.nc.res.rr.com)
21:58.07*** join/#oe memeruiz (n=memeruiz@f051110192.adsl.alicedsl.de)
22:05.55schurig_homeflo_lap: hmm, two years ago has was edgy on IRC; so that might be a benefit ...
22:07.22hvontres|AFKschurig_home: heh.. koen's emails seem a lot friendlier lately...
22:08.48flo_lapwell, i guess there were reasons
22:09.46hvontres|AFKflo_lap: maybe the real world started catching up... IRC can be a real time-sucker
22:11.15flo_laphvontres|home: its all a question of your mind :)
22:17.04Croftonhttp://pandora.bluwiki.com/
22:17.29psokolovskyanyone knows for how long more -c rebuild will stay broken?
22:18.01CroftonI think RP fixed it?
22:18.53psokolovskyCrofton: doesn't work for me with fresh .dev update, and hasn't been working for ~week now
22:19.03*** join/#oe ssvb (n=user@87.252.225.64)
22:19.03Croftonupdate bitbake?
22:19.50psokolovskyCrofton: heh, thanks ;-D
22:22.04cdbot2* * OE Bug 3986 has been created by <OE-Autobuilder>
22:22.06cdbot2* * linux-handhelds-2.6-2.6.21-hh20-r17-do_compile
22:22.08cdbot2* * http://bugs.openembedded.net/show_bug.cgi?id=3986
22:28.36flo_lapCrofton: that server does not respond
22:32.41hvontres|homeheh... looks like hrw|gone had some free time :) http://changelog.complete.org/posts/698-guid.html
22:46.20schurig_homehvontres|home: too bad that they don't cover monotone airlines there. Main competitor: 3270 airlines ...
22:52.29hvontres|homeschurig_home: feel free to add it :)
22:53.33schurig_homehvontres|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
22:55.14schurig_homehvontres|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.
22:56.20schurig_home(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 ...
22:58.36hvontres|homeschurig_home: heh... I guess I am OK with mtn...of course so far I have been limited mostly to mtn pull;mtn up :)
22:59.10hvontres|homeschurig_home: and at lest it's not VSS air... they use that at work and it scares me...
23:00.17hvontres|homeschurig_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
23:06.52Croftonflo_lap, http://openpandora.ca/
23:07.36flo_lapCrofton: ah cool, that looks good
23:07.47Croftonyeah
23:08.04*** join/#oe thesing (n=tkunze@BAEcfd4.bae.pppool.de)
23:08.19thesingre
23:08.24woglindere thesing
23:08.34flo_lapthesing: wb
23:11.45*** join/#oe hufnus (n=slonsiki@69-12-177-67.dsl.static.sonic.net)
23:12.54*** part/#oe hufnus (n=slonsiki@69-12-177-67.dsl.static.sonic.net)
23:13.23*** join/#oe hufnus (n=slonsiki@69-12-177-67.dsl.static.sonic.net)
23:15.02CIA-3803florian 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.
23:15.07CIA-3803florian 07org.oe.dev * rd06ab8ea... 10/ (1 conf/machine/mainstone.conf): mainstone.conf: Use new kernel
23:15.59*** part/#oe hufnus (n=slonsiki@69-12-177-67.dsl.static.sonic.net)
23:36.31*** join/#oe jbs (n=Bernardo@89-180-51-142.net.novis.pt)

Generated by irclog2html.pl Modified by Tim Riker to work with infobot.