**** BEGIN LOGGING AT Wed Nov 18 03:00:03 2009 Nov 18 07:14:17 good morning Nov 18 07:14:28 is it possible to tell bitbake NOT to delete the files after it creates the ipk? Nov 18 07:32:26 morning Nov 18 07:38:05 tzanger: the stuff in tmp/work? getting started I followed a tutorial that inherited rm_work in local.conf. if you comment out that it won't delete tmp/work. Nov 18 07:43:59 hmm okay, I'll look into that, thank you Nov 18 08:29:34 I had to modify usb-gadget to make it work for me. With MODULE_OPTIONS="file=/dev/mmcblk0p4 removable=1", usb-gadget fails because it does: modprobe g_file_storage "file=/dev/mmcblk0p4 removable=1". Should "$MODULE_OPTIONS" be changed to $MODULE_OPTIONS in the setup_usb() function in recipes/usb-gadget-mode/files/usb-gadget? Nov 18 08:30:18 that's the fix I did, and I just wondered if it's a fix that needs to be committed upstream Nov 18 08:37:21 tasslehoff: chances are that it would be good upstream. Nov 18 09:01:30 03Martin Jansa  07org.openembedded.dev * ra3779a461c 10openembedded.git/conf/checksums.ini: checksums.ini: add entries for SHR recipes Nov 18 09:01:30 03Martin Jansa  07org.openembedded.dev * r7412e6f91e 10openembedded.git/recipes/aceofpenguins/ (3 files in 2 dirs): aceofpenguins: new recipe from SHR Nov 18 09:01:31 03Martin Jansa  07org.openembedded.dev * rbb0afba8d2 10openembedded.git/recipes/calc/ (calc_0.0.2.bb calc_git.bb): calc: new recipe for elementary based calculator from SHR Nov 18 09:01:32 03Martin Jansa  07org.openembedded.dev * rdb1b0c2061 10openembedded.git/recipes/linux/ (4 files in 2 dirs): linux-openmoko-2.6.31: new recipe for 2.6.31 kernel from SHR Nov 18 09:01:34 03Martin Jansa  07org.openembedded.dev * rc102a9632d 10openembedded.git/recipes/orrery/ (orrery/Makefile.am.patch orrery/datadir.patch orrery_2.4.bb): orrery: new recipe from SHR Nov 18 09:01:37 03Martin Jansa  07org.openembedded.dev * r6310a961f2 10openembedded.git/recipes/openmoko-3rdparty/pisi_0.4.7.bb: pisi: new recipe from SHR Nov 18 09:01:40 03Martin Jansa  07org.openembedded.dev * r861528cf2f 10openembedded.git/recipes/linux/ (3 files in 2 dirs): linux-openmoko-shr: new recipe for 2.6.29-rc3 kernel Nov 18 09:01:45 03Martin Jansa  07org.openembedded.dev * rd977d3744d 10openembedded.git/recipes/linux/ (10 files in 2 dirs): linux-openmoko-shr-drm: new recipe for 2.6.29-rc3 kernel with DRM/KMS support Nov 18 09:01:50 03Martin Jansa  07org.openembedded.dev * rcf57a54696 10openembedded.git/recipes/openmoko-3rdparty/advancedcaching_git.bb: advancedcaching: new recipe from SHR Nov 18 09:01:53 03Martin Jansa  07org.openembedded.dev * rff2fd35c87 10openembedded.git/recipes/images/ (11 files in 9 dirs): shr-image, shr-lite-image: for building SHR distribution Nov 18 09:01:56 03Martin Jansa  07org.openembedded.dev * rbb8849eb44 10openembedded.git/recipes/cellhunter/cellhunter_0.5.0.bb: cellhunter: new recipe from SHR Nov 18 09:01:59 03Martin Jansa  07org.openembedded.dev * r86b44306e4 10openembedded.git/recipes/callrec/callrec_svn.bb: callrec: new recipe from SHR Nov 18 09:02:04 03Martin Jansa  07org.openembedded.dev * r217f3840ff 10openembedded.git/recipes/e17/e-tasks_svn.bb: e-tasks: new recipe from SHR Nov 18 09:02:11 03Martin Jansa  07org.openembedded.dev * rccd7a2aa41 10openembedded.git/recipes/e17/eve_svn.bb: eve: new recipe from SHR Nov 18 09:02:15 03Martin Jansa  07org.openembedded.dev * rd7f99e8b69 10openembedded.git/recipes/openmoko-3rdparty/om-neon_svn.bb: om-neon: new recipe from SHR Nov 18 09:02:17 03Martin Jansa  07org.openembedded.dev * r4438e09396 10openembedded.git/recipes/tasks/ (task-shr-feed.bb task-shr-minimal.bb task-shr.bb): task-shr: new task for SHR distribution Nov 18 09:02:21 03Martin Jansa  07org.openembedded.dev * rb953f04d8a 10openembedded.git/recipes/webkit/webkit-efl_git.bb: webkit-efl: new recipe from SHR Nov 18 09:02:25 03Martin Jansa  07org.openembedded.dev * r8b1a8c8b63 10openembedded.git/recipes/openmoocow/ (openmoocow/openmoocow.desktop openmoocow_git.bb): openmoocow: new recipe from SHR Nov 18 09:02:32 03Martin Jansa  07org.openembedded.dev * r23decb4d14 10openembedded.git/recipes/python/pyring_1.1.10.bb: pyring: new recipe from SHR Nov 18 09:02:35 03Martin Jansa  07org.openembedded.dev * re347d30bd1 10openembedded.git/recipes/python/pydes_1.3.1.bb: pydes: new recipe from SHR Nov 18 09:02:40 03Martin Jansa  07org.openembedded.dev * r53449d0731 10openembedded.git/recipes/python/python-dateutil_1.4.1.bb: python-dateutil: new recipe from SHR Nov 18 09:02:43 03Martin Jansa  07org.openembedded.dev * r43d06b2c0e 10openembedded.git/recipes/python/ (python-epydoc-native_3.0.1.bb python-epydoc_3.0.1.bb): python-epydoc: new recipe from SHR Nov 18 09:02:46 03Martin Jansa  07org.openembedded.dev * r94a6dcd953 10openembedded.git/recipes/python/python-blipapi_0.02.04.bb: python-blipapi: new recipe from SHR Nov 18 09:02:53 03Martin Jansa  07org.openembedded.dev * r6e7ed0aca2 10openembedded.git/recipes/python/python-pybluez_0.16.bb: python-pybluez: add version 0.16 from SHR Nov 18 09:02:56 03Martin Jansa  07org.openembedded.dev * ra9bd031a4b 10openembedded.git/recipes/python/ (python-ldap/setup.cfg.patch python-ldap_2.3.9.bb): python-ldap: new recipe from SHR Nov 18 09:03:01 03Martin Jansa  07org.openembedded.dev * r93288ed203 10openembedded.git/recipes/python/python-webdav_0.1.2.bb: python-webdav: new recipe from SHR Nov 18 09:03:04 03Martin Jansa  07org.openembedded.dev * r83db763387 10openembedded.git/recipes/python/python-wifi_0.3.1.bb: python-wifi: new recipe from SHR Nov 18 09:03:09 03Martin Jansa  07org.openembedded.dev * r27f9b46ed6 10openembedded.git/recipes/qwo/qwo_0.5.bb: qwo: add version 0.5 from SHR Nov 18 09:03:16 03Martin Jansa  07org.openembedded.dev * r305be9e66f 10openembedded.git/recipes/sms-sentry/sms-sentry.bb: sms-sentry: new recipe from SHR Nov 18 09:03:19 03Martin Jansa  07org.openembedded.dev * r2550b95344 10openembedded.git/recipes/e17/elmdentica_svn.bb: elmdentica: new recipe from SHR Nov 18 09:03:24 03Martin Jansa  07org.openembedded.dev * r3bc8e9e009 10openembedded.git/recipes/blueman/blueman_1.10.bb: blueman: new recipe from SHR Nov 18 09:03:29 03Martin Jansa  07org.openembedded.dev * r920f17d20a 10openembedded.git/recipes/blipomoko/blipomoko_git.bb: blipmoko: new recipe from SHR Nov 18 09:03:32 03Martin Jansa  07org.openembedded.dev * ree94b0ada2 10openembedded.git/recipes/tangogps/tangogps_0.9.9.bb: tangogps: add version 0.9.9 from SHR Nov 18 09:03:35 03Martin Jansa  07org.openembedded.dev * r5953dfd42f 10openembedded.git/recipes/python/python-vobject_0.8.1c.bb: python-vobject: new recipe from SHR Nov 18 09:03:40 03Martin Jansa  07org.openembedded.dev * r8df97109ca 10openembedded.git/recipes/dictator/dictator_0.2.bb: dictator: new recipe from SHR Nov 18 09:03:43 03Martin Jansa  07org.openembedded.dev * r575a75adb7 10openembedded.git/recipes/ebrainy/ebrainy_svn.bb: ebrainy: new recipe from SHR Nov 18 09:03:46 03Martin Jansa  07org.openembedded.dev * r8058014490 10openembedded.git/recipes/enotes/enotes_svn.bb: enotes: new recipe from SHR Nov 18 09:03:51 03Martin Jansa  07org.openembedded.dev * rc24888cefd 10openembedded.git/recipes/bt-gps/bt-gps.bb: bt-gps: new recipe from SHR Nov 18 09:03:54 03Martin Jansa  07org.openembedded.dev * ra24c1e6132 10openembedded.git/recipes/erminig/erminig_3.0.3.bb: erminig: new recipe from SHR Nov 18 09:03:57 (19 lines omitted) Nov 18 09:12:03 03Sebastian Spaeth  07org.openembedded.dev * re4e52ba358 10openembedded.git/conf/distro/include/sane-srcrevs.inc: Nov 18 09:12:03 e-wm-config-illume-shr: update sane src rev Nov 18 09:12:03 Signed-off-by: Sebastian Spaeth Nov 18 09:17:56 03Koen Kooi  07org.openembedded.dev * r19a9dfbb29 10openembedded.git/recipes/powervr-drivers/ (4 files in 2 dirs): libgles-omap, omap3-sgx-modules: add SDK 3.01.00.02/1.4.14.2514 release Nov 18 09:19:28 DJW|Home: ok. something I should do to make it happen? Nov 18 09:20:29 tasslehoff: patch to oe-devel? That would be the best way to start the process, it's what I do for patches. Nov 18 09:21:49 hmm, what do people tend to use in OE for web servering with a little CGI? Nov 18 09:22:57 tzanger: let us know ;-), not sure, been ages since I setup a webserver on an embedded device and I used Apache2 and it was fine. Nov 18 09:24:15 :-) I rolled my own on an old m68knommu system, but on a gumstix overo it seems pointless Nov 18 09:24:19 jo Nov 18 09:24:24 ~seen jama Nov 18 09:24:26 jama was last seen on IRC in channel #openmoko-cdevel, 7m 17s ago, saying: 'spaetz: someone will prepare "merging script" imho.. so I haven't done it manually'. Nov 18 09:26:25 03Graeme Gregory  07org.openembedded.dev * r4b51794977 10openembedded.git/: Merge branch 'org.openembedded.dev' of git+ssh://git@git.openembedded.org/openembedded into org.openembedded.dev Nov 18 09:26:25 03Graeme Gregory  07org.openembedded.dev * r15387c72d5 10openembedded.git/: Merge branch 'org.openembedded.dev' of git+ssh://git@git.openembedded.org/openembedded into org.openembedded.dev Nov 18 09:26:26 03Graeme Gregory  07org.openembedded.dev * r7f3d2b172a 10openembedded.git/ (conf/checksums.ini recipes/libsdl/libsdl-mixer_1.2.11.bb): libsdl-mixer_1.2.11.bb : update the latest version Nov 18 09:27:05 hm new sdl-mixer version Nov 18 09:28:26 ping jama Nov 18 09:28:43 woglinde: yo Nov 18 09:30:32 Is there really a reason why distro/minimal.conf needs to have DISTRO_EXTRA_RRECOMMENDS += "avahi-daemon avahi-autoipd" Nov 18 09:31:01 Can I use a local git repo as SRC_URI ? SRC_URI = "git://app/opt/sources/MAEMO/qt is not correct because goes to http://www.angstrom-distribution.org/unstable/sources/git_app.opt.sources.MAEMO.qt.tar.gz Nov 18 09:31:18 jama hm whats wrong with the e-core patch? Nov 18 09:31:50 recalcati maybee you have to specifiy the protocol Nov 18 09:32:48 woglinde: not sure why.. but it cannot find iconv lib here.. Nov 18 09:33:02 hm Nov 18 09:33:09 jama glibc? Nov 18 09:33:22 eglibc Nov 18 09:33:22 woglinde: I was going to bed.. so haven't checked it much.. Nov 18 09:33:43 I did, but I think I have to set some env var.... fetch http://www.angstrom-distribution.org/unstable/sources/git_app.opt.sources.MAEMO.qt.tar.gz Nov 18 09:33:48 woglinde: do you have libiconv installed? Nov 18 09:33:56 jama yes Nov 18 09:34:00 NOTE: Angstrom DOES NOT support libiconv because the glibc builtin iconv replacement is used Nov 18 09:34:03 thats what uclibc needs Nov 18 09:34:14 yes I know this Nov 18 09:34:39 but my changes dont touch the original detection stuff Nov 18 09:34:47 maybee there is something wrong in it Nov 18 09:34:49 will test it Nov 18 09:35:22 find . -name libiconv\* in my tmpdir.. mmt Nov 18 09:35:24 the libiconv is wrong anyway Nov 18 09:35:30 morning all Nov 18 09:35:32 args +detection Nov 18 09:35:34 hi rp Nov 18 09:35:39 gettext has it build in Nov 18 09:35:40 woglinde: and returns nothing.. Nov 18 09:36:06 hm okay Nov 18 09:36:58 woglinde: +libecore_txt_la_LIBADD = @iconv_libs@ $(LTLIBICONV) \ Nov 18 09:37:16 yeah Nov 18 09:37:19 woglinde: not sure if @iconv_libs@ has -liconv or new $(LTLIBICONV} added it.. Nov 18 09:37:41 woglinde: if you need me to test something.. ping me.. Nov 18 09:37:44 $(LTLIBICONV) ist the detection from gettext Nov 18 09:37:44 RP: moin Nov 18 09:37:56 and that shouldnt bee empty Nov 18 09:38:41 but also shouldn't containg -liconv if I don't have libiconv*, no? Nov 18 09:38:55 maybee we should remove the fucking detection code completey Nov 18 09:39:01 and releay on gettext stuff Nov 18 09:39:21 good morning Nov 18 09:39:27 jama could you test remove @iconv_libs@ Nov 18 09:39:30 and try again Nov 18 09:39:36 in configure.ac too Nov 18 09:39:38 woglinde: ok Nov 18 09:40:55 I guess we will not have a arch which has the fancy other libiconv stuff Nov 18 09:43:15 * DJWillis has come to the conclusion that Voodoo is more successful than trying to get a good generic Linux-PAM config setup. Nov 18 09:52:16 03Sebastian Spaeth  07org.openembedded.dev * r4592f35f2e 10openembedded.git/conf/distro/include/sane-srcrevs.inc: Nov 18 09:52:16 frameworkd-config-shr: bump sane rev Nov 18 09:52:16 Signed-off-by: Sebastian Spaeth Nov 18 09:59:18 I'd like to get, instead of SRC_URI = "ftp://ftp.trolltech.com/qt/source/qt-embedded-linux-opensource-src-${PV}.tar.bz2 , my git cloned dir on my pc. SRC_URI = "idon'tunderstand..." Nov 18 10:01:24 maybe file:// can get a dir . I'd prefer git protocol used locally Nov 18 10:01:25 recalcati_ zecke may help you probably Nov 18 10:01:31 zecke: ping Nov 18 10:02:23 JaMa: what has seriously gone wrong with SRCPV???? Nov 18 10:02:54 xord koen complains Nov 18 10:02:59 read the oe-dev list Nov 18 10:03:03 /home/dp/openembedded/build-oe/tmp/work/armv7a-angstrom-linux-gnueabi/webkit-gtk-1.1.16+svnr50081-r50081-r0/temp/log.do_configure.3881 Nov 18 10:03:18 woglinde: nothing to do with koens complains Nov 18 10:03:35 svnrSRCREV-rSRCREV thats just wropng Nov 18 10:03:47 XorD: its from oe.dev? Nov 18 10:04:11 JaMa: yes Nov 18 10:04:23 hmm, I think I know why Nov 18 10:04:37 multiple svn source in the same recipe Nov 18 10:04:38 arse Nov 18 10:04:42 I never thought of that Nov 18 10:04:59 Is there really a reason why distro/minimal.conf needs to have DISTRO_EXTRA_RRECOMMENDS += "avahi-daemon avahi-autoipd" Nov 18 10:05:10 especially as BAD_RECOMMENDATIONS doesn't seem to work Nov 18 10:05:16 XorD: seen that in matchbox2 recipe.. where it failed .. and was fixed later.. Nov 18 10:05:18 it's still pulled in Nov 18 10:05:34 due to staging changes? Nov 18 10:06:16 RP: can you check rootfs_ipk.bbclass please? Nov 18 10:06:33 JaMa: what was the fix? Nov 18 10:06:45 XorD: SRCREV_FORMAT setting Nov 18 10:06:53 and check whether the BAD_RECOMMENDATIONS handling looks right to you? Nov 18 10:07:01 XorD: http://cgit.openembedded.net/cgit.cgi/openembedded/commit/?h=martin_jansa/srcpv&id=b93e7e22233e78b04ac6208be9f6de05260ae490 Nov 18 10:07:23 XorD: but strange that goes wrong like this in webkit :/ Nov 18 10:07:40 webkit has loads of svn sources :-) Nov 18 10:07:50 spaetz: check it for what? Nov 18 10:08:10 JaMa: bit SRCREV_FORMAT is correct Nov 18 10:08:15 XorD: how it looked like before? Nov 18 10:08:20 XorD: I mean PV? Nov 18 10:08:21 JaMa: oddness, why do I have two different build dirs Nov 18 10:08:49 webkit-gtk-1.1.16+svnr50081-r0/ webkit-gtk-1.1.16+svnr50081-r50081-r0/ Nov 18 10:09:07 JaMa: I think actually SRCPV has unbroken it :-) Nov 18 10:09:15 but later is right wrt SRCREV_FORMAT, isn't it? ;) Nov 18 10:09:47 RP, minimal.conf RRECOMMENDS avahi-daemon which supposedly can be overridden by putting it in BAD_RECOMMENDATIONS. But this does not work Nov 18 10:10:03 So, I am wondering whether STATUS=${IMAGE_ROOTFS}${libdir}/opkg/status Nov 18 10:10:04 JaMa: yeah, its right Nov 18 10:10:17 will right the BAD_RECOMMENDATIONS stuff to the right place Nov 18 10:10:24 XorD: so you aren't complaining about SRCPV change, are you? :P Nov 18 10:10:28 s/right/write/ Nov 18 10:10:58 JaMa: sorry, I got confused with the two direcotries Nov 18 10:11:14 JaMa: initial look it looked like some stuff was accessing old, some new Nov 18 10:12:24 JaMa: but I guess at sometime recently SRCREV_FORMAT was broken Nov 18 10:13:47 plus I really don't think that task-distro-base in minimal.conf should be recommending avahi, but that is unrelated :) Nov 18 10:17:30 mmh, the location seems right to me: STATUS=[...]/tmp/rootfs/shr-image/usr/lib/opkg/status Nov 18 10:19:55 no, it seems the previous way of dealing with BAD_RECOMMENDS is just not working anymore... Nov 18 10:21:33 spaetz: the path looks right but something else could be wrong Nov 18 10:22:48 03Phil Blundell  07org.openembedded.dev * r5a8ab31788 10openembedded.git/recipes/usb-gadget-mode/ (files/usb-gadget usb-gadget-mode.bb): remove extraneous quoting around MODULE_OPTIONS; patch from Tasslehoff Kjappfot Nov 18 10:25:41 03Phil Blundell  07org.openembedded.dev * ra7affee8d4 10openembedded.git/classes/kernel.bbclass: Nov 18 10:25:41 move menuconfig task from "after do_patch" to "after do_configure"; Nov 18 10:25:41 patch from Przemyslaw Wesolek Nov 18 10:27:04 spaetz: have you changed your opkg version recently? :-} Nov 18 10:27:40 just sent a mail to oe-devel Nov 18 10:27:53 and my opkg version is rather new Nov 18 10:28:10 might be worth trying with an older opkg Nov 18 10:28:37 I guess it is probably unfair to automatically assume that opkg is responsible for all the world's ills, but nonetheless it is tempting. Nov 18 10:28:46 not sure which of the ten opkg versions is actually used for populating the rootfs though. I guess: opkg-collateral 0:1.0-r1 Nov 18 10:28:46 :-) Nov 18 10:28:54 no, opkg-collateral is just some config files Nov 18 10:28:58 opkg-native is the one you want Nov 18 10:29:17 opkg-native 0:0.1.6+svnr240-r17 Nov 18 10:29:21 that would be this one then. Nov 18 10:29:24 right Nov 18 10:29:29 let me try an older version Nov 18 10:29:36 03Roger Monk  07org.openembedded.dev * rcd12a381b1 10openembedded.git/ (4 files in 4 dirs): Nov 18 10:29:36 linux-davinci git: Update to latest OMAPL kernel Nov 18 10:29:36 - 2.6.32rc6 (PSP 3.20.00.07) Nov 18 10:29:36 - Updated commit id's for DA830_OMAPL37/DA850_OMAPL138 and switch to 'master' Nov 18 10:29:36 - Updated defconfigs (machine defconfig + swap + mmc + fbconsole) Nov 18 10:29:37 - Bump MACHINE_KERNEL_PR (in davinci.inc) Nov 18 10:29:41 03Roger Monk  07org.openembedded.dev * r09022c90f1 10openembedded.git/recipes/u-boot/u-boot_git.bb: u-boot git: Updated to omap-l machines to latest revisions corresponding to 2009.08 (PSP 3.20.00.07) Nov 18 10:31:45 svn r240 does look rather old to me already though .... :) Nov 18 10:31:54 03Koen Kooi  07org.openembedded.dev * rd6c55524b1 10openembedded.git/recipes/efl1/ (4 files in 2 dirs): Nov 18 10:31:54 Revert "ecore: fix building for uClibc" Nov 18 10:31:54 This commits breaks non-uclibc builds since it will add an unconditional -liconv Nov 18 10:31:54 This reverts commit 406cd0fee12ad99ba6d6f7d55f743cc4c6697955. Nov 18 10:32:00 well, Nov 02 Nov 18 10:32:06 not so old Nov 18 10:32:14 I'm trying to subrscribe to oe mailing list epenembedded-devel . I'm not able to do it. Any help is appreciated. thx Nov 18 10:32:33 recalcati_: goto lists.linixtogo.org Nov 18 10:32:39 lists.linuxtogo.org Nov 18 10:33:02 recalcati_: it's "openembedded-devel", not "epenembedded-devel" Nov 18 10:36:49 pb_: yes, yes, sorry Nov 18 10:38:27 I try to resend the e-mail, but I hope someone can confirm it Nov 18 10:39:24 so, what exactly goes wrong when you try to subscribe? Nov 18 10:40:04 03Marc Olzheim  07org.openembedded.dev * r8aa4ca945d 10openembedded.git/recipes/curl/files/ (2 files): curl: apply patch for CVE-2009-2417 Nov 18 10:41:17 03Martin.Jansa  07org.openembedded.dev * re326b03394 10openembedded.git/conf/distro/include/sane-srcrevs-fso.inc: Nov 18 10:41:17 sane-srcrevs-fso: update freesmartphone revs Nov 18 10:41:17 Signed-off-by: Martin Jansa Nov 18 10:41:18 03Martin.Jansa  07org.openembedded.dev * r2263b51333 10openembedded.git/conf/distro/ (include/preferred-shr-versions.inc shr.conf): Nov 18 10:41:18 shr: update config from SHR Nov 18 10:41:21 Signed-off-by: Martin Jansa Nov 18 10:41:23 03Martin.Jansa  07org.openembedded.dev * rf205d8a024 10openembedded.git/conf/machine/ (om-gta01.conf om-gta02.conf): Nov 18 10:41:26 om-gta0(1|2): update config from SHR Nov 18 10:41:28 Signed-off-by: Martin Jansa Nov 18 10:41:30 03Martin Jansa  07org.openembedded.dev * r943dd0f655 10openembedded.git/: Merge branch 'org.openembedded.dev' of git.openembedded.org:openembedded into org.openembedded.dev Nov 18 10:41:33 03Martin Jansa  07org.openembedded.dev * r8ef4ce21c6 10openembedded.git/: Merge branch 'org.openembedded.dev' of git.openembedded.org:openembedded into org.openembedded.dev Nov 18 10:41:36 03Martin Jansa  07org.openembedded.dev * r27c58b2727 10openembedded.git/conf/distro/include/sane-srcrevs.inc: sane-srcrevs: update libgee, paroli, pyphonelog, xf86-video-glamo, libmokoui2, fltk2 revs Nov 18 10:42:54 03Marc Olzheim  07org.openembedded.dev * rdf515a378b 10openembedded.git/recipes/curl/ (4 files): curl: apply patch for CVE-2009-2417 Nov 18 10:43:46 pb_: Your mail to 'Openembedded-devel' with the subject \n subscribe \n Is being held until the list moderator can review it for approval. Nov 18 10:44:08 RP: how would you feel about adding a git hook to prevent pushing useless merge commits? we seem to have that in the glibc git tree and I think it is quite a good idea. Nov 18 10:44:12 now I hope it will be approved.... Nov 18 10:44:19 recalcati_: I think you sent your mail to the wrong place. Nov 18 10:45:09 the easiest way to subscribe is to use the mailman web page. Nov 18 10:45:23 if you want to subscribe by email then I think you need to write to openembedded-devel-request or some such address, not to openembedded-devel itself. Nov 18 10:49:39 What's a useless merge commit? Nov 18 10:55:23 pb_: How do you detect a useless merge? Nov 18 10:55:30 03Marc Olzheim  07org.openembedded.dev * r6ee684a2c6 10openembedded.git/recipes/curl/curl_7.19.7.bb: curl: add 7.19.7 Nov 18 10:56:15 RP: there's some eleet thing that apparently the people in #git know :-} Nov 18 10:56:21 RP: just a minute, I will find a link to the thing we use in glibc Nov 18 10:56:36 http://www.mail-archive.com/bug-gnulib@gnu.org/msg11689.html Nov 18 10:56:37 I think that's the one Nov 18 10:57:18 Ah, that doesn't prevent useless merge commits - it prevents merges entirely. Nov 18 10:58:54 broonie: exactly :/ Nov 18 10:59:36 Anyone here who tried a recent opkg lately? I noticed they are ~100 checkins ahead of what we use in oe. Nov 18 11:00:21 pb_: that'll only work if nobody is ever supposed to develop on branches. Nov 18 11:03:32 ah, yes, that is not quite as clever as I thought it was. Nov 18 11:04:10 I guess it would be possible to enhance it to spot when you are merging master back into itself, though, which would probably remove most of the noise. Nov 18 11:09:51 perl-native should really be perl-cross Nov 18 11:10:14 RP: in what way? surely perl isn't a cross tool, it doesn't generate any code. Nov 18 11:11:03 pb_: It generates config.sh files specific to the target you're compiling for Nov 18 11:11:47 pb_: It could be argued that it shouldn't but as it stands its a perl-cross :/ Nov 18 11:12:00 RP: is that intentional? that sounds more like a bug than a feature to me :-} Nov 18 11:12:24 but yeah, I agree, if it is doing that then it is not really native. Nov 18 11:14:03 pb_: Its just a total mess. There is sed stuff in here for staging problems that no longer exist and all kinds of things :/ Nov 18 11:14:40 pb_: noy the web subscribe works, but it seems that I am already subscribed Nov 18 11:21:12 RP: yeah, I think it is fair to say that the state of perl in oe is all bad. Nov 18 11:39:32 At least perl appears to have DESTDIR support now Nov 18 11:39:34 can I only do -c compile ? without fetch Nov 18 11:39:42 Why aren't we using it though? :/ Nov 18 11:45:00 at a guess, either because perl didn't use to support that, or because the staging layout at the time perl-native was first added wasn't conducive to its use. Nov 18 11:45:11 that perl-native stuff is so old now, though, that I suspect the truth is going to be lost in the mists of time. Nov 18 11:45:44 pb_: Does perl work for DISTRO=minimal? Nov 18 11:46:13 pb_: I think I will try and fix 5.8.8. Anything other I'm going to propose gets dropped Nov 18 11:46:22 dunno, I don't use minimal much at the moment. iirc, it does not work for micro but I am not 100% sure about that either. Nov 18 11:46:40 (I also don't have any perl-using packages in the set that I build regularly so I don't get to try it often.) Nov 18 11:47:19 I'll try a build of perl for micro now and see what happens. I don't have a minimal build tree handy so that's less convenient to do right now. Nov 18 11:47:23 Hi .. I'm kind of new to OE and Linux - I've made a package (for i686-generic with Ångström) DEPEND'ing on the qt4-x11-free_4.5.0 recipe, but can't find out how to start the Xorg server - I get "(EE) Failed to load module "dri" (module does not exist, 0)" - "(EE) Failed to load module "vga" (module does not exist, 0)" - "(EE) No drivers available."... Does anyone know what's wrong and how to fix this? Nov 18 11:47:48 RP: yeah, fair enough, I don't think there is any good reason to keep anything older. Nov 18 11:48:22 out of interest, why do you have this sudden surge of interest in perl? Nov 18 11:48:36 pb_: I think I meant micro - with the missing /usr Nov 18 11:48:52 pb_: My guess will be that it at best ignores your lack of /usr Nov 18 11:49:01 pb_: The staging conversions Nov 18 11:49:04 yeah, micro is the one without /usr Nov 18 11:49:06 Hasse__: kdrive, I remember is about Xorg Nov 18 11:49:13 I think you are probably right that it will not work Nov 18 11:49:13 pb_: and perl is probably the most broken recipe in poky now Nov 18 11:49:48 yeah, probably Nov 18 11:50:06 I wonder if anybody is even really using perl for anything. Do you have many packages in poky that depend on it? Nov 18 11:50:21 presumably you must have some, otherwise it wouldn't be there, but I can't think of many common things that are perl-based. Nov 18 11:52:03 pb_: libxml-parser-perl which is needed by gettext/intltool mainly Nov 18 11:52:09 recalcati_: Hi :) - what do you mean by kdrive? Nov 18 11:52:27 search it, it is a driver inside X Nov 18 11:52:27 recalcati_: I'll be at lunch the next 15 min ... Nov 18 11:52:41 recalcati_: oki, I will thx! Nov 18 11:52:48 I'm not an expert of it... Nov 18 11:53:34 * XorD tends to use perl a lot Nov 18 11:53:44 RP: ah, right. I wonder whether it would be a better use of time to just fiddle those two packages to use something else for their xml processing and then throw perl away. Nov 18 11:53:53 it does seem faintly silly to build an entire language just for that. Nov 18 11:56:12 Hasse__: you need to install xf86-video- where is the name of the driver you want to use Nov 18 11:56:21 pb_: Can we throw perl out of OE though? Nov 18 11:56:23 Hasse__: fbdev pretty much always works Nov 18 11:56:33 pb_: If not, who will fix the staging problems? Nov 18 11:57:12 I wonder if we can build perl under qemu Nov 18 11:57:26 removing the need for perl-native Nov 18 11:57:43 but I guess that fails on non qemu platforms Nov 18 11:58:20 RP: well, my standard response to that kind of thing is that the people who want to use perl get to fix the staging problems for it. Nov 18 11:58:53 pb_: Lets see how far I get - if I can make libxml-parser-perl work, I'll probably leave it there Nov 18 11:59:26 * XorD would hate to have to learn python just becuase I cant work out how to fix perl :-) Nov 18 11:59:30 RP: righto, fair enough Nov 18 11:59:40 oh wait, we have a volunteer to fix perl! Nov 18 11:59:48 XorD: congratulations on your appointment as perl maintainer! Nov 18 12:00:01 pb_: I think the last few crazy fixes were me anyway Nov 18 12:00:08 re Nov 18 12:00:19 woglinde: wb Nov 18 12:00:25 XorD: well done! Nov 18 12:00:34 I do remeber scratching my head on some errno crap :-) Nov 18 12:01:46 perl is a total PITA cross compiled Nov 18 12:02:13 wonder if perl 6 will be any better Nov 18 12:02:19 XorD: Why the nickname change? Nov 18 12:02:38 RP: different machine, Fedora 12 is currently installing on the other one Nov 18 12:03:37 although I see my irc proxy seems to have died anyway :-) Nov 18 12:05:00 XorD: fair enough :) Nov 18 12:05:15 someone registered XorB and XorC :-D Nov 18 12:21:42 XorD: How about XorZ? oreven better XorY? :) Nov 18 12:26:41 Can I ask is something is a good idea? I want to post-process the sudoers file to enable the wheel group and I was thinking of something along the lines of http://pastebin.com/d2cbd0ae (crude 2min attempt) in a sudo-enable-wheel-group.bb to live next to the sudo recipe. Is there a better way assuming I don't want to munge the sudo recipe? Nov 18 12:27:18 RP: to keep with the theme they have to be real registers :-) Nov 18 12:28:24 XorD: but if you say something really clever it will be known as an XorZism. Nov 18 12:28:41 XorD: I'm sure we can find a processor with them somewhere ;-) Nov 18 12:30:06 DJWillis, you could use a machine specific sudoers file Nov 18 12:30:59 ah the days when a CPU bug allowed a whole new familly of machine to be built Nov 18 12:31:01 DJWillis: something along those lines, yes, though you should probably add a bit more logic to your postinst to make it more robust (e.g. not adding a wheel entry if one already exists) Nov 18 12:31:31 and/or put the sudoers file back the way it was if your package is uninstalled Nov 18 12:32:44 use LDAP and your sudo file is easier to edit :-) Nov 18 12:35:49 pb_: of course ;-) it was more 'is the concept sound'. Nov 18 12:36:37 yeah, I think the basic concept is fine Nov 18 12:36:46 Crofton|work: I did consider a machine file but I am not sure that is the right way to go, the choice to use wheel is not really something at the machine level (i.e. I want this machine secure today, and more open tomorrow, oh look, it's hard coded). Nov 18 12:37:44 yeah, I just wanted to through that out in case you hadn't thought of it Nov 18 12:37:52 XorD: Use LDAP ;-), only just managed to beat PAM into something that actually works in OE for what I want ;-) Nov 18 12:38:27 * Crofton|work restarts his beagle bloat image (:)) after the iconv fail Nov 18 12:38:32 Crofton|work: noted :). That reminds me that I really should push up the new sudo version I did anyway. Nov 18 12:38:35 RP: doh, perl build failed, no space left on device Nov 18 12:39:34 DJWillis: you enabled pam for login? Nov 18 12:39:45 XorD: Shadow yep Nov 18 12:40:35 XorD: and sudo ;-) - may have been ott Nov 18 12:40:51 DJWillis: oooooh, Angstrom would be interested in that :-) Nov 18 12:40:54 hi mickey|sofa Nov 18 12:41:04 good morning pb_ Nov 18 12:41:08 DJWillis: would make dbus work right as well Nov 18 12:42:59 03Sebastian Spaeth  07org.openembedded.dev * re2ff712602 10openembedded.git/conf/distro/include/sane-srcrevs-fso.inc: Nov 18 12:42:59 libfsobasics: bump sane rev (fixes log file creation) Nov 18 12:42:59 Signed-off-by: Sebastian Spaeth Nov 18 12:55:25 pb_: doh! :) Nov 18 13:07:55 03Phil Blundell  07org.openembedded.dev * rb252feed97 10openembedded.git/recipes/curl/ (curl-common.inc curl_7.19.7.bb): curl: add checksums for 7.19.7 Nov 18 13:08:31 facebook thinks lrg needs a profile picture ... Nov 18 13:09:50 Crofton|work: heh, its on my todo list Nov 18 13:10:15 the new nagging from facebook is amusing Nov 18 13:13:50 * lrg has to check now Nov 18 13:44:15 Crofton: So it nags your friends rather than you personally? Nov 18 13:44:45 no, it just has a listing of people I should bother Nov 18 13:44:55 mostly people who haven't been on in a while i think Nov 18 13:46:32 I'm compiling qt 4.6 : how to force the compilation of qt4-tools-native.inc ? Nov 18 13:50:21 XorD: there is some in my op oe.dev clone but it's all still a WIP. Will be nice when it all works. Nov 18 14:09:05 XorD: thx a lot - I'm looking into :) Nov 18 14:09:19 recalcati_: oki, thx .) Nov 18 14:12:54 Hasse_: ok Nov 18 14:40:06 morning Nov 18 14:40:16 hi kergoth Nov 18 14:47:01 g'day kergoth Nov 18 14:50:48 rday seems to be cursed Nov 18 14:51:05 seems so Nov 18 14:51:14 he does seem to have remarkably bad luck, yeah Nov 18 14:51:35 normally, I can dupe his issues, but guile-native is working for me now Nov 18 14:52:08 I should update something to f12 and see if that breaks things Nov 18 14:52:23 but I need to call a guy first, and that may "refocus me" Nov 18 14:53:35 Crofton|work: Watch out, the switch to dracut causes the upgrade to fail with the default /boot Nov 18 14:53:51 dracut makes the initrds much bigger so they fill the partition Nov 18 14:53:54 hmm, maybe I'll wait then :) Nov 18 15:03:04 hmm Nov 18 15:06:11 i am trying to build x11-image for zoom2 using openembedded. I did basic build and it worked fine. Now i am trying to add some packages to it and trying to rebuil the new image. I added name of packages to x11-image.bb file in receipes/image and restarted the build process using bitbake x11-image commang. But I am getting some sort of parsing error. http://pastebin.com/m3e66ca8d Nov 18 15:07:44 I believe that the proper way to make images is having a bb file in the form of -image.bb and have it depend on task-.bb Nov 18 15:08:09 the xfce-image.bb is a good guide Nov 18 15:12:10 amitshah08: parsing error = typo in the vaste majority of cases Nov 18 15:26:21 abt_work: thanks ... it was a kind of typo error but not exactly a typo ..... actually i tried adding a package named mozilla and it was causing problems .. i dont know why Nov 18 15:26:53 XorD, I too am interested in keeping Perl in OE. :) There are a number of users in the SlugOS community, and while I think they may be able to pull a binary from the optware feeds, I'd prefer we have the option to offer Perl from the OE-built feeds. Nov 18 15:27:29 mwester: I want to add imapsync sometime as well, want to run it on my sheeva to backup my email Nov 18 15:27:32 Alas, the perl recipes frighten me; I tried to add a module some time ago and couldn't figure it out. Nov 18 15:29:14 * mwester has just finished downloading F12 (x64), and will re-isntall his build machine soon... Nov 18 15:29:22 re-install, even. Nov 18 15:44:48 morning Nov 18 15:46:42 hmm Nov 18 15:52:17 kergoth: not thinking again, are you? Nov 18 15:52:30 yeah, i should know better :) Nov 18 15:52:49 dangerous ;) Nov 18 15:53:01 greetings chouimat Nov 18 15:53:32 those forms are driving me nuts Nov 18 16:08:19 damnit, i wish i'd stop losing things on my drive Nov 18 16:08:38 * kergoth has no idea what he did with the prototype git based tree tracking for tasks Nov 18 16:08:51 * kergoth keeps doing this Nov 18 16:09:15 er, I'm up to 126 oe/mvl6 projects Nov 18 16:09:24 * kergoth makes one per bug# :) Nov 18 16:22:08 otavio: thanks for the feedback; i have replied again. Nov 18 16:37:04 anyone looked at leveraging BBCLASSEXTEND to do multilib builds, 32bit & 64bit variant builds of recipes for 64 bit machines? Nov 18 16:37:09 * kergoth might have to look into that Nov 18 17:24:58 kergoth: not looked at but should be able to handle it Nov 18 17:25:12 * kergoth nods, figured Nov 18 17:44:56 likewise: good and thx Nov 18 17:53:27 morning Nov 18 17:57:38 greetings Nov 18 18:00:11 Hello Nov 18 18:02:24 Has anyone tried to create an openoffice recipe (perhaps use qemu-arm-static to chroot into an ARMEL rootfs and compile inside)? Nov 18 18:02:39 * kergoth shudders at the thought Nov 18 18:06:47 I don't know of anybody who has done that. I did work on a project a few years ago where we tried to make a .bb file for openoffice but I think we ended up just using the debian binaries instead. Nov 18 18:07:11 gregoiregentil: Koen tried over year ago Nov 18 18:07:19 and failed. Nov 18 18:07:33 crosscompiling oo sounds like fun. not... Nov 18 18:08:20 bah Nov 18 18:08:25 the emdebian repos are a mess Nov 18 18:09:07 trying to get just a regular armel cross toolchain... 4.4 doesn't work, 4.3 is missing at least one package (libc-bin-armel-cross)... OE's very heavy but at least it seems to be complete Nov 18 18:10:35 s/^the //; s/repos are/is/ Nov 18 18:10:36 ;) Nov 18 18:10:55 heh Nov 18 18:23:14 03Leon Woestenberg  07org.openembedded.dev * rd9a2c93817 10openembedded.git/recipes/linux/linux-kirkwood/cpuidle-reenable-interrupts.patch: Nov 18 18:23:14 linux-kirkwood: Add patch that re-enables interrupt from idle. Nov 18 18:23:14 Signed-off-by: Leon Woestenberg Nov 18 18:23:16 03Leon Woestenberg  07org.openembedded.dev * r88e8ac888f 10openembedded.git/recipes/linux/linux-kirkwood_2.6.31.bb: Nov 18 18:23:18 linux-kirkwood: Add patch that re-enables interrupts from idle. Nov 18 18:23:20 Signed-off-by: Leon Woestenberg Nov 18 18:23:22 03Leon Woestenberg  07org.openembedded.dev * rae7a832d3b 10openembedded.git/conf/bitbake.conf: squashfs-lzma-tools: Upstream LZMA support requires -comp argument. Nov 18 18:23:25 03Leon Woestenberg  07org.openembedded.dev * ra089057b76 10openembedded.git/MAINTAINERS: Nov 18 18:23:28 MAINTAINERS: Update recipes, machines that I look at now and then. Nov 18 18:23:30 Signed-off-by: Leon Woestenberg Nov 18 18:23:32 03Leon Woestenberg  07org.openembedded.dev * rd0728eceb6 10openembedded.git/conf/bitbake.conf: (log message trimmed) Nov 18 18:23:35 squashfs-lzma-tools: Revert, re-applied later in unified commit. Nov 18 18:23:37 This reverts commit 78ec619c698b227e0d0f310f49c4a932ce9f0db6. Nov 18 18:23:39 Upstream squashfs-tools has now-official support for LZMA but Nov 18 18:23:45 requires different arguments. This commit added the new Nov 18 18:23:47 argument, but I later decided to unify this commit with the Nov 18 18:23:49 actual recipes -- so that in case of problems, it can be traced Nov 18 18:23:51 03Leon Woestenberg  07org.openembedded.dev * r96fa2bacf6 10openembedded.git/recipes/linux/ (9 files in 2 dirs): (log message trimmed) Nov 18 18:23:54 linux-{,kirkwood-}2.6.31: Add upstream squashfs-4.0 LZMA patches. Nov 18 18:23:58 Squashfs 4.0 has official LZMA in the works. Nov 18 18:24:01 "Re: [Squashfs-devel] squashfs 4.0 lzma support" Nov 18 18:24:02 According to the author "No, I don't anticipate the format Nov 18 18:24:04 changing. As far as LZMA is concerned, the format is dictated Nov 18 18:24:06 by the LZMA code in the kernel". Nov 18 18:24:08 03Leon Woestenberg  07org.openembedded.dev * r1481ac48dd 10openembedded.git/ (4 files in 3 dirs): (log message trimmed) Nov 18 18:24:15 squashfs-4.0: update squashfs-tools to include upstream LZMA inclusion. Nov 18 18:24:17 In OpenEmbedded we used squashfs 4.0 with external patch for LZMA Nov 18 18:24:19 compression support. In the meantime, squashfs has mainlined LZMA Nov 18 18:24:23 support in its CVS version. Nov 18 18:24:23 This patches switches to the upstream squashfs-tools and modifies Nov 18 18:24:25 bitbake.conf to match the slightly different arguments to mksquashfs. Nov 18 18:24:58 sorry, will be less noisy next time Nov 18 18:26:12 likewise: I'd be glad if you had given time for me to reply before pushing it Nov 18 18:26:58 likewise: and your policy of "this is how upstream has done it" is wrong IMO. I did used external lzma source in my previous recipe so it was not that hard to just keeping using it Nov 18 18:27:36 otavio: sorry, I then misunderstood your "likewise: good and thx" remark Nov 18 18:27:36 likewise: and from upstream POV it looks right to expect it this way; from a distro POV it is wrong Nov 18 18:28:22 OK, I want to link two files in a do_install function Nov 18 18:28:24 kergoth: :-) Nov 18 18:28:32 otavio: I can revert the squashfs-tools commit right away. Nov 18 18:28:33 Is it OK to "cd"? Nov 18 18:28:58 If I just do a "ln -s ${D}${base_libdir}/firmware/helper_gspi.bin ${D}${base_libdir}/firmware/gspi8686_hlp.bin" it obviously doesn't work. Nov 18 18:29:15 so don't Nov 18 18:29:22 I need to cd in ${D}${base_libdir}/firmware/ and ln from there Nov 18 18:29:28 no, you don't Nov 18 18:29:36 ln -s helper_gspi.bin ${D}${base_libdir}/firmware/gspi8686_hlp.bin Nov 18 18:29:49 the first argument is where the link points, it doesn't have to exist relative to the currnet directory Nov 18 18:29:55 likewise: I'd prefer if you fix it now Nov 18 18:29:59 oh I forgot to ask you last night, kergoth... is there a flag to tell bitbake to NOT get rid of the staging files? I am just trying to copy what's built (a signle executable) over to the board without going thorugh the ipkg stuff Nov 18 18:30:07 Hmmm Nov 18 18:30:28 likewise: I replied it in ml Nov 18 18:30:47 Thanks kergoth, I am retarded. Nov 18 18:30:48 :) Nov 18 18:31:28 nah, just have to remember that you can always create relative links, and that relative path is relative to the location of the link you're creating Nov 18 18:31:30 np Nov 18 18:31:43 Heh, thanks anyways. Nov 18 18:31:46 ;) Nov 18 18:32:11 not a problem, happy to help Nov 18 18:32:24 tzanger: not sure what you mean by getting rid of staging files. Nov 18 18:33:24 i really need to do a better job of keeping track of the various proof of concepts i throw together Nov 18 18:33:49 * kergoth works on pulling bits from various bitbake git repositories on his box into one Nov 18 18:35:18 kergoth: oh :-) I'm looking forward for a branch of it :P Nov 18 18:35:20 kergoth: heh Nov 18 18:35:34 heh Nov 18 18:35:40 tzanger: bitbake doesn't ever remove the staging files during a build (except in certain special cases having to do with packaged staging). if you mean the files in tmp/work, you just need to avoid inheriting rm_work in order for those to not be removed. Nov 18 18:36:35 pb_: ahh okay. will read up on inheritance Nov 18 18:36:36 * pb_ go home now Nov 18 18:37:00 otavio: i have a lot of random things that aren't necessarily worth keeping.. just to try out and determine if its worthwhile, you know.. not pushing all that to upstream branches necessarily :) maybe i should throw a bitbake repo of my own onto github Nov 18 18:37:06 * kergoth yawns Nov 18 18:37:48 kergoth: at same time some might be worth working for upstream pushing? :p Nov 18 18:38:10 some, certainly. lots of half complete stuff too Nov 18 18:38:10 h Nov 18 18:38:10 eh Nov 18 18:38:35 kergoth: heh Nov 18 18:38:40 kergoth: normal :-) Nov 18 18:38:44 indeed Nov 18 18:39:47 otavio: I'll peek at it for a bit. However, the lzma 4.65 recipe doesn't build (do_patch) for me, so I'll have to look at that first. Nov 18 18:39:52 http://cgit.openembedded.net/cgit.cgi/bitbake/commit/?h=kergoth/checksnippets for example is likely to never go in, but that kind of thing might be worth investigating to keep better control over what people do, to reduce side effects Nov 18 18:40:56 likewise: it does here Nov 18 18:40:59 likewise: humm Nov 18 18:44:55 it would really be nice if / would let us push non-fast-forwards and delete branches.. did anything ever come of the discussion to use per user repositories or a contrib repository? Nov 18 18:48:49 otavio: I see now. It depends on a host tool: dos2unix, that isn't installed (nor instructed by OpenEmbedded): xargs: dos2unix: No such file or directory Nov 18 18:49:14 likewise: oh :-( Nov 18 18:49:22 likewise: crap Nov 18 18:50:14 otavio: maybe we can use xargs together with sed, instead of dos2unix Nov 18 18:51:19 otavio: or better "tr" from the core-utils package: tr -d \\r < win.txt > unix.txt # if you can't find dos2unix Nov 18 18:56:34 likewise: yes; it should work Nov 18 19:01:12 anyone know what defines the macro PKG_CONFIG_LIBDIR? Nov 18 19:03:20 RP: ping Nov 18 19:04:37 RP: something new about that bitbake patch? Would be nice to have it in some bitbake release in sanity check.. as srcpv branch is getting old/conflicts really fast :/ Nov 18 19:09:58 03Leon Woestenberg  07org.openembedded.dev * r2ffe3fac16 10openembedded.git/recipes/lzma/lzma.inc: Nov 18 19:09:58 lzma.inc: Remove dependency on dos2unix host command, using sed. Nov 18 19:09:58 Signed-off-by: Leon Woestenberg Nov 18 19:10:49 Crofton|work: what uses it? Nov 18 19:11:44 newer omniorb Nov 18 19:12:10 just wondering if anyone knew anything before I dig Nov 18 19:12:10 trying to build then Nov 18 19:13:16 this is a new recipe I am working on Nov 18 19:13:30 the old recipe has issues with newer gcc :) Nov 18 19:13:42 re Nov 18 19:13:46 ok Nov 18 19:13:52 Crofton|work: try s/LIBDIR/PATH Nov 18 19:14:17 Crofton|work: 4.0.7 omniorb-native do not like (e)glibc 2.10+ Nov 18 19:14:24 ah Nov 18 19:14:26 yeha Nov 18 19:14:33 thats simple to fix Nov 18 19:14:48 yeah, but the version is ancient :) Nov 18 19:14:50 s/getline/getlineSOMETHINGADDEDTONOTBEJUSTgetline/g Nov 18 19:14:55 heh Nov 18 19:15:38 hrw: thanks for the buildbot config in oe Nov 18 19:16:07 florian: no problem Nov 18 19:16:10 otavio: did you ever build lzma for the target? Nov 18 19:16:18 florian: it has some changes from other devs too iirc Nov 18 19:16:22 otavio: I get a x86 executable even when building for arm Nov 18 19:17:37 likewise: I use amd64 to build to i486 Nov 18 19:18:02 otavio: ah, so maybe you didn't find that bug Nov 18 19:19:18 otavio: try to see if you get amd64 executable out of it when you build for i486 Nov 18 19:19:41 hrw: its a pretty good start.. the buildbot configuration is well... not really oobvious :) Nov 18 19:21:27 florian: I plan to close access to my buildbot soon Nov 18 19:22:25 likewise, at OEDEM we talked about changing the stats page to show good/bad builds for a collection of machine/distros Nov 18 19:22:31 built by specific builders Nov 18 19:25:24 hrw: I have some hope for a public autobuilder :) Nov 18 19:26:26 hrw: If not I maybe try ro arrange somethign like this at kc... low bandwith but a (comparably slow) blade for this task would be cheap. Nov 18 19:26:46 Crofton|work: good, it would be nice if we differentiate between "from scratch builds" and non-from-scratch builds. Also, we need to know if the checkout is clean. Nov 18 19:27:25 yeah, that is why we would filter results from certain people Nov 18 19:27:45 for this, I would say build from scratch Nov 18 19:28:11 florian: would be nice to have official one Nov 18 19:28:25 Crofton|work: so from scratch could be done once a week or dily Nov 18 19:28:25 Crofton|work: daily I meant Nov 18 19:28:38 depends on the person doing the build Nov 18 19:28:50 likewise: good points Nov 18 19:29:05 hrw: indeed Nov 18 19:32:44 mickey|bbl, http://tinderbox.openembedded.net/public/logs/task/3676613.txt Nov 18 19:34:15 bye all Nov 18 19:38:14 bye hrw Nov 18 19:38:55 Can I pursuade bitbake in creating the run.do_* script but halt before execution (so that I can inspect the script and the state of ${S} at that point) ? Nov 18 19:40:30 likewise: can't you "echo ${S} > my-file" from the task you want to monitor? Nov 18 19:40:39 I don't think so. but, of course, you can add a prepend to the script to just make it exit without doing anything. Nov 18 19:41:53 mario-goulart: I meant the state of ${S}/*, not the variable itself :-) Nov 18 19:42:19 pb__: duh. very clever and simple, tnx. Nov 18 19:44:19 likewise: use do__prepend { exit 1 } Nov 18 19:44:28 likewise: so you see it failing and check it Nov 18 19:57:54 apropos the build report thing, we seem to have both a tinder-client.bbclass and an oestats-client.bbclass. I detect the hand of zecke in the former but apart from that it is not obvious to me which is the one to use. Nov 18 20:00:53 pb__: I suppose thats Tinderbox vs. oestats. In this context its mostly the domain the official oestats ui lives is misleading. Nov 18 20:01:13 yeah :) Nov 18 20:01:36 oestats is the right one, correct? Nov 18 20:01:45 okay, so tinderclient.bbclass genuinely does want to talk to tinderbox? Nov 18 20:02:01 and oestats-client.bbclass talks to oestats, which is what runs on tinderbox.openembedded.net? Nov 18 20:02:05 I hope so :-} Nov 18 20:02:14 pb__: right Nov 18 20:02:41 righto Nov 18 20:02:46 I wonder who had the crazy idea to install it with this subdomain. Nov 18 20:02:49 and what's the difference between the two, is oestats better? Nov 18 20:03:05 yeah, that does seem like the worst possible choice of subdomain :-} Nov 18 20:04:48 pb__: I haven't seen Tinderbox for ages, but oestats looks good and it took me < 10 minutes to set up. Nov 18 20:05:01 indeed Nov 18 20:05:12 righto Nov 18 20:05:21 I haven't used tinderbox for about a decade and a half either Nov 18 20:05:30 let me see if I can find out what the current state of the art is with that Nov 18 20:05:54 oestats does look nice but I am not sure it is quite what we want in this application Nov 18 20:07:04 combining the features of oestats and buildbot would be nice Nov 18 20:07:26 pb__, since we are reporting stuff to oestats, my thinking is that it can filter for certain image/distro combos and log them Nov 18 20:07:31 * florian currently works on the build servers at kc Nov 18 20:10:58 hmm Nov 18 20:11:33 grr Nov 18 20:11:39 anyone have a bdi2000 config file for arm7? Nov 18 20:11:51 bdisetup doesn't like mine because it's lacking a [MODE] section, but I have no idea what to put in that section Nov 18 20:11:54 seems like tinderbox has indeed gotten "more spiffy" (to quote its webpage) since I used it last Nov 18 20:13:32 so, that might be worth a go. if I have some spare time tomorrow I might try setting it up and see what happens. Nov 18 20:14:00 "spare time" sounds promising :) Nov 18 20:14:09 heh. well, that is a fairly large "if". Nov 18 20:14:52 I'll have a play with oestats some more, but based on a quick perusal of the tinderbox.oe.net thing it looks like the tinderbox ui is rather closer to what we want in this instance. Nov 18 20:15:08 or, at least, closer to what I think would be useful; I guess other folks might have other preferences. Nov 18 20:17:03 * kergoth finds the parallels between oe/bitbake and CI / enterprise level build tools / buildbot / etc interesting. both tend to obey dependencies among the various things being built, both tend to "do things" with the artifacts produced.. just the latter tend to have the automation pieces and fancy interfaces and scheduler and all Nov 18 20:17:24 hi Nov 18 20:17:38 is it possible to check for an external app? Nov 18 20:17:39 kergoth: yeah, indeed Nov 18 20:18:04 playya__: doubtless. can you be any more specific? Nov 18 20:18:09 i need inkscape on the host Nov 18 20:18:23 to convert some pictures Nov 18 20:18:48 i can't find a native recipe for it Nov 18 20:18:53 pb__, I haven't looked at the real tinderbox in ages Nov 18 20:18:55 I'm not entirely sure if anything should be done with that information, but it's definitely interesting. it makes me wonder if maybe our scope should change, split up into 1) bits that know how to build a thing for an arbitrary target, and 2) the higher level bits that build the whole and make use of the output of 1) Nov 18 20:19:45 playya__: what about installing it with your host distro package management system? Nov 18 20:20:05 that's not the problem Nov 18 20:20:43 playya__: i think perhaps your use of the term 'native' is not what we expect? native recipes are built for the build machine, not the target Nov 18 20:20:54 if i send you a patch for navit which bails out because an app on the host isn't installed, i could never ask for commit rights ;) Nov 18 20:21:11 ahh Nov 18 20:22:03 if a recipe exists for the target, you can generally also make it build for native/cross/sdk by manipulating BBEXTENDCLASSES Nov 18 20:23:10 inkscape has a lot of depencies which are not available as naitves: DEPENDS = "libgc intltool-native gtk+ gtkmm glibmm libart-lgpl libxslt librsvg libxml2 libsigc++-1.2 popt" Nov 18 20:23:40 would have to add those as natives too, then, or modify the thing to not use inkscape to do its conversions Nov 18 20:23:44 kergoth: yeah, you mentioned that kind of separation the other day I think. it isn't completely obvious to me what that split would buy you: you still (in general) want to be able to deal with dependencies between build artifacts at the "do stuff" stage, so it probably wouldn't make sense to have a completely separate tool for that. Nov 18 20:24:12 kergoth, DEPENDS = "libgc intltool-native gtk+ gtkmm glibmm libart-lgpl libxslt librsvg libxml2 libsigc++-1.2 popt" Nov 18 20:24:15 yeah, that's a good point Nov 18 20:25:05 there is probably some stuff you could do to formalise that separation somewhat in oe, but I think this would mostly be a window-dressing exercise in the .bb files (and maybe a couple of classes) rather than a core architecture change Nov 18 20:25:56 fair enough, will have to think about how things can be cleaned up in that way Nov 18 20:28:14 pb_, is this what you looked at? Nov 18 20:28:17 https://developer.mozilla.org/En/Tinderbox Nov 18 20:33:02 http://www.johnkeiser.com/mozilla/tbox3.html was the page with the "spiffy" remark Nov 18 20:34:04 http://tinderbox.freedesktop.org/ Nov 18 20:34:10 Chris Ball runs that - I've always liked it Nov 18 20:34:44 hrm Nov 18 20:35:48 pb__: i just don't think recipes are the ideal way of taking the artifacts from other recipes and doing things with them. an image recipe isn't an ideal interface. i think you'd be better off having something else do it, perhaps leveraging the bitbake python module to get to the output and its dependencies Nov 18 20:37:25 kergoth: yeah, I agree that the interface sucks. but, it seems to me that this is more a problem of presentation than infrastructure: given sufficient supporting classes it seems like it ought to be possible to represent the artifact handling in (something that can be transformed into) a .bb file. Nov 18 20:38:25 http://tinderbox.mozilla.org/showbuilds.cgi?tree=SeaMonkey is a reasonable example of the "classic" tinderbox ui Nov 18 20:39:04 for some reason the "guilty" column seems to be completely empty there, I guess I made a poor choice of tree Nov 18 20:39:33 maybe what i dislike most about the current setup is the fact that recipes put things outside of WORKDIR. conceptually, I'd rather see the other piece take the output of the other recipes from them, rather than them deploying things around Nov 18 20:40:09 yeah, that would be an improvement Nov 18 20:40:58 i think we're misusing the recipe itself for anything that might need to traverse the dependency graph. Nov 18 20:41:24 consider: if rootfs_ipk pulled the exact packages it should be using, instead of whatever the latest recipe installed into tmp/deploy/ipk, image creation would be more deterministic Nov 18 20:42:34 yes, that is a big pain point for me at the moment in fact. Nov 18 20:43:38 but, still, I don't think it is a problem with the fact that the rootfs is a recipe, it's just due to a combination of (a) bitbake suckage, in not being able to specify the version of the package that you want in DEPENDS; and (b) oe suckage, in that (as you say) there is no way to reliably get at the output of a particular package build. Nov 18 20:44:28 and, in my case, also (c) bitbake suckage again, in that you need to have a separate .bb file for every version of every package that you want to build, rather than being able to leave things like PV relatively unbound in the recipe and having it match multiple versions. Nov 18 20:44:36 and of course, an image recipe can't really be poking around at other recipe's stuff, since the API bitbake provides to recipes doesn't allow it sanely. a separate python script could leverage the python package to do so, though, which is why i was thinking in that direction.. but perhaps we can provide a better mechanism to a recipe to access the output of recipe builds instead Nov 18 20:44:43 * kergoth nods Nov 18 20:44:53 that does suck Nov 18 20:45:26 so, suckage all round, but it isn't obvious to me that dispensing with recipes for images will really solve any of that. Nov 18 20:45:57 though, when i was playing with the private staging areas, i ran headlong into that same dilemma .. accessing the output of your dependencies builds .. so i guess addressing that in a generic way would be good, and get us a good portion of the way there Nov 18 20:49:07 you know what would be cool Nov 18 20:49:45 if an image creation / project build UI could construct in memory a representation of the image they want to reproduce, a semantic model of sorts of a nonexistant recipe, and tell it to build it Nov 18 20:52:06 thats a harder math problem then it sounds Nov 18 20:52:18 I've seen people try to do that with kconfig and fail at it Nov 18 20:57:34 i think we should really sit down and do some big refactoring inside of bitbake Nov 18 20:58:28 a start would be to look at the points of interaction between the modules Nov 18 20:59:51 I'd love for the parsing process to produce something other than a datastore. the rest of bitbake doesn't need to care how we happen to be storing things internally, or how the user interacts with it via its file format.. Nov 18 21:00:01 heh Nov 18 21:00:28 * kergoth adds to his list for another proof of concept Nov 18 21:03:00 should give some thought to the API we provide to recipes, too, rather than them just blindly using the python module to manipulate an injected 'd' variable Nov 18 21:03:06 heh Nov 18 21:03:12 Nov 18 21:05:25 * kergoth tries to remember what he was working on an hour ago.. damn meetings throwing off trains of thought Nov 18 21:12:57 hmm Nov 18 21:13:12 is it expected that ipkg does not exist in the openembedded build for overo earth? Nov 18 21:13:33 at first I thought it was just the flash image being odd (I didn't replace it from what gumstix ships) Nov 18 21:13:36 yes Nov 18 21:13:46 but now I am running what I built myself in oe and it's still not there Nov 18 21:13:49 it should be opkg now Nov 18 21:13:53 ahh yes opkg is there Nov 18 21:15:44 so opkg works how ipkg does? what's the differnce between them? Nov 18 21:16:30 * mwester bites his tongue Nov 18 21:20:46 heh Nov 18 21:21:01 tzanger: accept a simple "yes" :) Nov 18 21:21:21 florian: :-) Nov 18 21:21:43 tzanger: and forget the term "ipkg" Nov 18 21:21:49 :-) Nov 18 21:22:35 fair enough Nov 18 21:23:48 hmm, I see opkg list will give me a list of everything available, and search will let me find a package with a given filename... is there anything similar to apt-cache search? Nov 18 21:23:54 right now I"m grepping the output of opkg Nov 18 21:24:41 also is there a way to get the version of vim running on oe to stop making assumptions about screen size on serial tty? Nov 18 21:24:45 iirc opkg list can take additional pattern Nov 18 21:24:58 I can execute 'reset' to restore it after but maybe I'm missing some magical parameter Nov 18 21:27:46 yeah the search is searching the filename Nov 18 21:42:06 How do I get the git fetcher to update what branches are in the git repo? Nov 18 21:46:22 rschuster1, are you going to fill out the application for a fosdem stand/ Nov 18 22:01:50 hm, seems like the svn fetcher is a bit broken when DL_DIR is on nfs Nov 18 22:02:08 lots of "file changed as we read it" errors Nov 18 22:03:03 strange... I have all DL_DIR at kc on nfs for quite some time. Nov 18 22:03:13 saves a lot of bandwith :) Nov 18 22:03:28 yeah, I usually have my DL_DIR on nfs too Nov 18 22:03:38 all my machines are configured that way except my laptop :-} Nov 18 22:04:08 same here... Nov 18 22:08:25 we need to update the git fetcher docs to include the branch option ... Nov 18 22:09:08 branch/tag/etc aren't different from the fetchers perspective, they're all just checking out a ref.. Nov 18 22:09:35 well, fetching a branch did not work until I changed from tag to branch Nov 18 22:09:46 although, I had pushed the branch after the first fetch Nov 18 22:10:01 then fetched the branch without changing the rev Nov 18 22:10:10 I suspect that confused the fetcher ??? Nov 18 22:10:21 huh, weird, don't know :\ Nov 18 22:14:58 wtf is wrong with virtual/libiconv Nov 18 22:15:46 libiconv would be wrong for sure... hmmmm Nov 18 22:16:59 koen reverted the e-core stuff mainly because virtual/libiconv Nov 18 22:17:28 but I will test it now Nov 18 22:18:09 if the recipe had a virtual/libiconv dependency i don not see the problem here. Nov 18 22:18:24 Since 406cd0fee12ad99ba6d6f7d55f743cc4c6697955 broke all Nov 18 22:18:24 glibc-internal-iconv builds and I'm too lazy/stupid to fix it properly Nov 18 22:18:25 for uclibc I reverted this commit. Nov 18 22:26:37 jo raster Nov 18 22:30:35 he jama Nov 18 22:31:03 woglinde: boo boo! Nov 18 22:41:26 woglinde, it broke builds Nov 18 22:42:04 crofton it only brooke e-core builds Nov 18 22:42:18 well, it broke beagle-demo-image :) Nov 18 22:42:44 which people are building Nov 18 22:48:11 Crofton|work: oh yes I forgot - you need it for crosscompiling Qt! ;) Nov 18 22:48:29 woglinde, if you check something in, I can start another demo image build Nov 18 22:48:49 crofton have to wait for my glibc build Nov 18 22:48:54 ok Nov 18 22:49:05 urg, I am not in a position to build Nov 18 22:49:06 hmmm Nov 18 22:49:17 but now I fix it the really way Nov 18 22:49:27 wonder why it breaks on glibc Nov 18 22:49:29 anyway Nov 18 22:50:22 hm have to look how ${LTLIBICONV} is on glibc Nov 18 23:26:23 haha lol Nov 18 23:26:34 ecore needs glib dep anyqway Nov 18 23:30:22 eh? Nov 18 23:30:25 as of when? Nov 18 23:30:29 needs? or is optional? Nov 18 23:30:37 :) Nov 18 23:31:18 glib.h not found Nov 18 23:31:25 in oe configuration Nov 18 23:36:29 pb__: ping? Nov 18 23:36:39 anyway Nov 18 23:37:38 what is heavier - ioctl(fd, BLKGETSIZE, ... ) on mtdblock or lseek(fd, 0, SEEK_END) on mtd? :) Nov 18 23:39:58 or MEMGETINFO ( u_long size; /* Size of the device in bytes */ ) Nov 18 23:40:16 on mtd Nov 19 00:13:24 so now its fixed Nov 19 00:13:33 crappy iconv Nov 19 01:17:12 hmm, isn't there supposed to be an /etc/timezone to tell the system what its timezone is? Nov 19 01:22:05 not necessarily. Nov 19 01:22:24 /etc/localtime, but some distros won't install that by default. Nov 19 01:27:44 so now ecore fixes can go in Nov 19 01:28:29 03Henning Heinold  07org.openembedded.dev * r9bd7891192 10openembedded.git/recipes/efl1/ (4 files in 2 dirs): Nov 19 01:28:29 ecore: fix building for uClibc Nov 19 01:28:29 * dep on gettext-native, becaus it provides iconv.m4 with AM_ICONV Nov 19 01:28:29 * we don't have any estoric libc, so relay on AM_ICONV macro Nov 19 01:28:30 * bump PR Nov 19 01:28:32 * this time tested for glibc builds too Nov 19 01:33:51 mwester: yeah, needed the tzdata package **** ENDING LOGGING AT Thu Nov 19 02:59:56 2009