**** BEGIN LOGGING AT Mon Mar 01 02:59:57 2010 Mar 01 07:25:06 morning Mar 01 07:30:13 03Martin Jansa  07org.openembedded.dev * r09a79a497f 10openembedded.git/recipes/opkg/ (opkg.inc update-alternatives-merge.inc): (log message trimmed) Mar 01 07:30:13 opkg: don't run merger in case when /usr/lib/ipkg is link Mar 01 07:30:13 * if there is link /usr/lib/ipkg -> /usr/lib/opkg, then merger will Mar 01 07:30:13 create backups of "both" alternatives directories, but they will be Mar 01 07:30:13 both the same /usr/lib/opkg/alternatives, then it will try to merge Mar 01 07:30:14 with output that every file is the same, sofar no real harm. Mar 01 07:30:15 * Problem is after successfull merge, when it removes Mar 01 08:04:50 good morning Mar 01 08:08:40 Spyzer, re your cooker problem; This http://paste.debian.net/61924/ should avoid that python errors from bitbake Mar 01 08:16:32 kergoth, sent you that above hunk with some more detail for your consideration. Basically, Spyzer somehow ended up with a BBPATH that points to no .bb and got the backtrace mentioned in the mail. The patch would bail gracefully instead of trying to continue. Mar 01 08:22:23 morning Mar 01 08:45:42 morning Mar 01 08:47:44 anyone, i have trouble getting ipkg running on my target, it does not find basic modules (like tempfile), possible i made something wrong, is there some tutorial ? Mar 01 08:48:57 isn't it opkg nowadays? Mar 01 08:49:23 oh... so thats my fail Mar 01 08:50:05 all the tutorials i worked through where pointing at ipkg... i had no clue, sorry Mar 01 08:50:26 i'm not sure. my morning coffee didn't kick fully in yet Mar 01 08:50:56 i just tried typing opkg into the target console, and i greeted me without errors Mar 01 08:51:14 :) thanks Mar 01 08:52:14 oic, then hack away! Mar 01 09:22:06 morning Mar 01 09:22:14 morning Mar 01 09:22:34 o cześć soltys Mar 01 09:23:18 ;) Mar 01 09:23:19 hi hrw Mar 01 09:23:39 eFfeM: what about moving task-nas-server-openmoko to separate recipe? this way openmoko distros can built it if need? Mar 01 09:24:00 nas on om ?:) Mar 01 09:25:23 hrw: openmoko it self doesn't build imags anymore Mar 01 09:25:45 and shr doesn't use this recipe Mar 01 09:26:34 soltys: what about freerunner in space? Mar 01 09:27:35 hrw: dunno Mar 01 09:29:44 soltys: read http://www.datenfreihafen.org/~stefan/weblog/archives/2010/02/index.html then Mar 01 09:30:08 ok Mar 01 09:32:11 hrw: interesting Mar 01 09:41:37 Hey, what recipe is responsible for en_US.UTF-8 ? Mar 01 09:41:51 glibc Mar 01 09:43:31 and the created package should be /eglibc-binary-localedata-en-us_2.10...version... ? Mar 01 09:46:30 ? Mar 01 09:59:51 03Koen Kooi  07org.openembedded.dev * r5a3429c62d 10openembedded.git/recipes/mozilla/firefox_3.6.bb: firefox 3.6: bump PR for package.bbclass strip problem Mar 01 09:59:52 03Koen Kooi  07org.openembedded.dev * r39e7c169d8 10openembedded.git/recipes/qt4/ (4 files in 2 dirs): qt4: bump PR for package.bbclass strip problem Mar 01 10:30:17 I have FILES_${PN}-util = "${bindir}/js" in my recipe, still I get: the following files were installed but not shipped in any package: /usr/bin/js, what am I missing? Mar 01 10:31:12 Jin^eLD: PACKAGES += ${PN}-util ? Mar 01 10:31:50 ah crap! thank you Mar 01 10:32:09 :) Mar 01 10:50:48 03Graeme Gregory  07org.openembedded.dev * r5f52f56fd8 10openembedded.git/recipes/udev/attr_2.4.44.bb: attr_2.4.44.bb : uclibc needs a -lintl to compile Mar 01 10:59:11 /away Mar 01 11:01:19 03Martin Jansa  07org.openembedded.dev * r7dccaf76a7 10openembedded.git/conf/distro/include/sane-srcrevs.inc: elementary-theme-gry: bump SRCREV Mar 01 11:01:56 hi Jin^eLD Mar 01 11:02:06 hi Mar 01 12:35:21 zecke: this time again, something simialr :) I have PACKAGES += ${PN}-tests and I have FILES_${PN}-tests = "${datadir}/dss/dsstests" but somehow the dsstests file still ends up in the main package? what am I missing this time? :) Mar 01 12:35:52 Jin^eLD: PACKAGES =+ "${PN}-tests" Mar 01 12:36:15 oops.. so with the other recipe it worked just by accident Mar 01 12:36:34 thanks Mar 01 12:41:14 pb_: that did not help though... NOTE: Not creating empty archive for dss-tests-0.7.7-r9.5 Mar 01 12:42:08 is the order important, i.e. who gets listed first? Mar 01 12:42:40 or should I list FILES_${PN} manually myself? Mar 01 12:48:02 yep, seems that was it Mar 01 12:48:39 no Mar 01 12:49:15 no? hmm well after I specified FILES_${PN} in addition to the other custom packages, things went where they were supposed to Mar 01 12:49:30 what's the "correct" way of solving this? Mar 01 12:50:15 prepend to PACKAGES not append Mar 01 12:50:25 as bitbake goes in order Mar 01 12:50:39 and FILES_${PN} should not be overwritten Mar 01 12:50:56 ok.. thanks, let me try.. I did suspect that but somehow went the FILES_ way Mar 01 12:55:51 ok, I have two patches which can break people or not. autoconf + automake pokyified Mar 01 12:56:16 builds should work anyway so I will push Mar 01 12:56:28 03Marcin Juszkiewicz  07org.openembedded.dev * rb6faf3681a 10openembedded.git/recipes/automake/ (5 files): Mar 01 12:56:28 autoconf: merged Poky changes (BBEXTENDCLASS + new staging) Mar 01 12:56:28 Signed-off-by: Marcin Juszkiewicz Mar 01 12:56:37 03Marcin Juszkiewicz  07org.openembedded.dev * r15ab483e62 10openembedded.git/recipes/autoconf/ (6 files): Mar 01 12:56:37 autoconf: merged Poky changes (BBEXTENDCLASS + new staging) Mar 01 12:56:37 Signed-off-by: Marcin Juszkiewicz Mar 01 13:01:52 hrw, was in meetings all morning, wrt openmoko: & nas: seemed a weird combination anyway Mar 01 13:02:01 ok Mar 01 13:02:48 actually it is a task which is a collection of tasks and apparently more or less orphaned too Mar 01 13:03:12 but this is also a case that a specific machine has a specific need Mar 01 13:03:48 the real solution is probably to fix dfu-util (and make it use usb iso usb-compat Mar 01 13:06:42 rigth Mar 01 13:06:58 hrw: thanks, prepending worked just fine Mar 01 13:07:13 pb_: we are using gnu-config from 2005 - any idea why we did not updated? Mar 01 13:10:08 hrw: I guess simply because the old one was working adequately well. The rate of change in gnu-config is pretty slow and, unless you need support for a new cpu or something, there is generally not much to be gained by upgrading it. Mar 01 13:10:42 ok Mar 01 13:14:43 wow. one of gnu-config patches was manually updated by me nearly 5 years ago... time flies Mar 01 13:16:23 so I met OE ~6 years ago Mar 01 13:16:41 18th March 2004 was first OEML contribution Mar 01 13:45:25 blindvt`: BBPATH isn't what points to .bb files, BBFILES is. Thanks for the patch, though, we definitely want to avoid that backtrace. appreciate your taking the time to find the cause Mar 01 13:52:34 ok, time for gnu-config push Mar 01 13:53:03 03Marcin Juszkiewicz  07org.openembedded.dev * rd0d9ad50a4 10openembedded.git/recipes/gnu-config/ (gnu-config-native_20050701.bb gnu-config_20050701.bb): Mar 01 13:53:03 gnu-config: merge Poky improvements (BBCLASSEXTEND, new staging) Mar 01 13:53:03 Signed-off-by: Marcin Juszkiewicz Mar 01 13:53:14 03Marcin Juszkiewicz  07org.openembedded.dev * r5463fa1e85 10openembedded.git/recipes/gnu-config/gnu-config/uclibc.patch: Mar 01 13:53:14 gnu-config: remove not used uclibc.patch Mar 01 13:53:14 Signed-off-by: Marcin Juszkiewicz Mar 01 14:03:02 kergoth, BBFILES point to .bb, yes. Either of BBPATH="" or BBFILES=/nothing_in_there and variations thereof would trip this, so perhaps BBFILES should also be printed (I thought the common mistake would be an improperly set BBPATH but that's of course not always true) Mar 01 14:03:26 * kergoth nods, fair enough Mar 01 14:06:36 Jin^eLD: yes, the order is important: that is why you need to use =+ not += Mar 01 14:09:38 ooh, I did not notice that subtle difference, was using _prepend then, thanks once more Mar 01 14:27:07 03Koen Kooi  07org.openembedded.dev * r5a9223eab9 10openembedded.git/recipes/e17/exalt_svn.bb: exalt: convert to new style staging Mar 01 14:27:07 03Koen Kooi  07org.openembedded.dev * rb154373858 10openembedded.git/recipes/e17/e-wm_svn.bb: e-wm: convert to new style staging Mar 01 14:54:05 another 2 recipes less to parse Mar 01 14:55:25 bonus will be move people to file-native 5.04 Mar 01 14:58:42 03Graeme Gregory  07org.openembedded.dev * rdb935da155 10openembedded.git/conf/distro/include/angstrom-2008-preferred-versions.inc: Mar 01 14:58:42 angstrom-2008-preferred-versions.inc : downgrade udev for uclibc Mar 01 14:58:42 udev 141 is known good on uclibc, I know there are patches to hack up Mar 01 14:58:42 151 to work. But for now I would prefer to have a known good stable we Mar 01 14:58:42 can upgrade. Mar 01 14:58:49 03Graeme Gregory  07org.openembedded.dev * r3b35dfffa8 10openembedded.git/conf/distro/angstrom-2008.1.conf: Mar 01 14:58:49 angstrom-2008.1.conf : increment angstrom uclibc usage to the latest point rel. Mar 01 14:58:49 There were problems compiling later gnome/polkit/conkit stuff that this Mar 01 14:58:49 release fixes. To not deviate too far from glibc builds we need to Mar 01 14:58:50 update. Mar 01 15:01:05 re Mar 01 15:01:28 hrw: heh, file 5.04 combined with the other update means no-ones builds are stripped :-) Mar 01 15:02:25 dammit Mar 01 15:02:39 I think I screwed up something :D Mar 01 15:03:07 ok, will set default to 4.21 then Mar 01 15:03:21 I tried creating a recipe for linux-2.6.33 with a defconfig for the sbc6020, but do_stage seems to fail Mar 01 15:03:24 XorA: yep, magic gone 'no magic' ;-) Mar 01 15:04:02 XorA: target or host binaries are not stripped? Mar 01 15:04:33 hrw: target Mar 01 15:04:41 hrw: see the thread on mailing list Mar 01 15:04:49 hrw: 150M firefox libs :-D Mar 01 15:05:13 ok, need to build for target first Mar 01 15:05:45 Romke: try to clean that recipe before building Mar 01 15:06:08 16:05 hrw@home:devel$ build/micro/tmp/staging/x86_64-linux/bin/file Mar 01 15:06:08 file: File 5.4 supports only version 7 magic files. `/home/hrw/devel/build/micro/tmp/staging/x86_64-linux/share/misc/magic.mgc' is version 4 Mar 01 15:06:11 fun Mar 01 15:06:28 ~curse file upstream for 5.4 == 5.04 Mar 01 15:06:29 May the fleas of a thousand camels infest your most sensitive regions, file upstream for 5.4 == 5.04 ! Mar 01 15:07:18 ok, file native fails to deliver magic.mgc Mar 01 15:07:36 hrw: its moved to usr/share/misc/magic.mgc Mar 01 15:07:53 XorA: and it is there - 8 bytes Mar 01 15:08:00 ooops Mar 01 15:08:02 will fix file 5.04 Mar 01 15:08:17 should be about 1.7M Mar 01 15:08:19 JaMa: it fails again Mar 01 15:08:31 XorA: I know - it was such one with 4.21 Mar 01 15:08:40 Romke: aren't you using stable branch? Mar 01 15:08:47 yes, I am Mar 01 15:08:57 http://tinderbox.openembedded.org/builds/62439/ Mar 01 15:08:59 Romke: then read ML and kernel.bbclass log from oe.dev Mar 01 15:09:16 ML? Mar 01 15:09:31 Romke: openembedded-devel@ Mar 01 15:09:31 hm.. anyone here building oe for beagleboard ? trying to build xserver-xorg fails because HAL is not available Mar 01 15:09:35 Romke: and then extract needed changes from .dev, test them in stable/2009 and post them for inclusion Mar 01 15:09:59 mkay Mar 01 15:10:07 gilligan_: which xserver version? Mar 01 15:10:24 JaMa, xserver-xorg_1.7.4.bb Mar 01 15:10:37 gilligan_: I was the last one changing xserver wrt HAL.. so maybe I've broken something :/ Mar 01 15:10:54 gilligan_: do you have error log? Mar 01 15:11:01 hehe Mar 01 15:11:12 gugus: is the problem that hal wasn't built before xserver? Mar 01 15:11:13 I guess I found my answer in the mailinglist indeed Mar 01 15:11:17 gilligan_: ^ Mar 01 15:11:37 JaMa, yeah i suppose it's a screwed up dependency thing Mar 01 15:12:16 JaMa, not much interesting stuff to log really ... "configure: error: HAL hotplug API requested, but HAL is not installed" Mar 01 15:12:26 JaMa, building hal manually now and then trying again Mar 01 15:13:01 gilligan_: show me please bitbake -e xserver-xorg Mar 01 15:13:37 gilligan_: this DISTRO_XORG_CONFIG_MANAGER ?= "hal" and RDEPENDS = "${DISTRO_XORG_CONFIG_MANAGER}", should make hal available Mar 01 15:14:07 hang on Mar 01 15:14:08 but I should probably add ${DISTRO_XORG_CONFIG_MANAGER} also to DEPENDS Mar 01 15:14:32 eh..yeah Mar 01 15:14:40 it's not a runtime dependency only Mar 01 15:15:24 but doesn't bitbake always build RDEPENDS before package too? Mar 01 15:16:13 rdepends? not have to Mar 01 15:16:22 at least it's the case I usually see while building, but maybe with more bb threads it's not the rule Mar 01 15:16:33 DEPENDS needs to be staged before. RDEPENDS do not have to Mar 01 15:16:39 hrw: thanks, I'll add it to DEPENDS Mar 01 15:16:47 in that case there would be little use in using rdepends and depends Mar 01 15:17:13 hence please add hal to xorg DEPENDS Mar 01 15:17:31 if xorg links to hal then it is depends Mar 01 15:17:59 XorA: rebuilt from clean file-native 5.04 and magic.mgc has 1.7MB Mar 01 15:18:20 hrw, dunno if it does.. all i know is configure fails right now because hal is missing Mar 01 15:18:28 log? Mar 01 15:20:11 where does bitbake save logs ? lost the relevant output from scrollback after bitbake -e xserver-xorg ... Mar 01 15:20:48 ~hail JaMa Mar 01 15:20:50 * ibot bows down to JaMa and chants, "I'M NOT WORTHY!!" Mar 01 15:20:50 oh..it was independent for each package iirc Mar 01 15:20:56 it works Mar 01 15:21:28 I could use the pointer after a day of work Mar 01 15:26:56 hrw, http://pastebin.com/3q4JsSGs Mar 01 15:27:23 hrw, log of failed xserver-xorg configure Mar 01 15:27:37 1thx Mar 01 15:27:46 hrw: there is small problem with moving DISTRO_XORG_CONFIG_MANAGER to DEPENDS in case you want just libudev :/ Mar 01 15:28:20 --enable-config-hal was given so HAL was checked Mar 01 15:28:22 hrw: for RDEPENDS libudev was enough, but to DEPENDS I have to put udev right? Mar 01 15:28:24 hrw, after that I ran 'bitbake hal' and tried 'bitbake x11-image' again and xserver-xorg builds fine (or well.. still running) Mar 01 15:29:05 JaMa: right Mar 01 15:29:21 JaMa: it dl() libudev not links to it? Mar 01 15:29:27 hrw: but then I'll get whole udev as runtime dependency? Mar 01 15:29:34 hrw, well is --enable-config-hal intended or not ? I assume angstrom uses hal Mar 01 15:30:10 JaMa: no Mar 01 15:30:32 gilligan_: I am not X11 mastah Mar 01 15:30:50 hrw: I have to check if it links to it (because I have both hal/libudev disabled in my builds) Mar 01 15:31:06 Gah. How do I persuade OE to build a compiler with EABI support? Mar 01 15:31:18 hrw, too bad.. me neither ;-D Mar 01 15:31:44 dammit Mar 01 15:32:17 the AT91 PATA driver is included in the kernel, but doesn't seem to be working :/ Mar 01 15:32:38 broonie: DISTRO=angstrom-2008.1 Mar 01 15:33:40 XorA: That's what I'm using. Turns out it's installed a compiler into cross after only initial which confused me. Mar 01 15:33:40 hmm, anyone seen this problem with building uboot from oe dev http://pastebin.mozilla.org/705525 Mar 01 15:36:34 | configure: error: cannot compute suffix of object files: cannot compile Mar 01 15:36:35 | See `config.log' for more details. Mar 01 15:36:35 | make[1]: *** [configure-target-libgcc] Error 1 Mar 01 15:36:35 | make[1]: Leaving directory `/home/hrw/devel/build/micro/tmp/work/armv5te-oe-linux-gnueabi/gcc-cross-initial-4.4.2-r2.1/gcc-4.4.2/build.x86_64-linux.arm-oe-linux-gnueabi' Mar 01 15:36:38 arhg Mar 01 15:37:50 what is this git read-tree 1 failed with signal 128, output: fatal: Not a valid object name 1 ? did something change in the uboot trunk or what is it? Mar 01 15:38:58 SRCREV not set, likely, afaik Mar 01 15:39:02 * kergoth yawns Mar 01 15:39:23 let me pull again, maybe I am not at the latest oe.dev rev... Mar 01 15:43:13 lets restart Mar 01 15:44:46 pointers appreciated as to how I make sure that includes are found for an recipe correctly. currently I get "glib.h: No such file or directory" - I built that by hand and also added it to DEPENDS just in case Mar 01 15:45:07 this is fennec_hg.bb jftr Mar 01 15:47:43 meh, the issue might be different it is looking for build//angstrom-dev/staging/i686-linux/usr/bin/libIDL-config-2 which is actually in build/angstrom-dev/staging/i686-linux/usr/bin/armv7a-angstrom-linux-gnueabi/libIDL-config-2 Mar 01 15:50:58 why would bitbake get that wrong? Mar 01 15:52:26 dm8tbr: it has nothing to do with bitbake. Mar 01 15:53:13 zecke: ok, where do I have to look then? at the fennec recipe, the libidl recipe? Mar 01 15:53:23 dm8tbr: How did you determine "looking" for? strace? Mar 01 15:53:41 bye Mar 01 15:53:53 zecke: it's in the output for a failed bitbake -b fennec Mar 01 15:54:44 before it wouldn't even go past the configure, but then I built the libraries configure was missing using bitbake Mar 01 15:55:02 dm8tbr: check classes/mozilla.bbclass Mar 01 15:55:25 dm8tbr: from a quick glance, it appears that we use pkg-config to ask for the path of libIDL-config-2 Mar 01 15:55:51 * XorA wonders if avr32 kernel developers have a special toolchain Mar 01 15:57:38 zecke: excuse my ignorance but I'm rather unfamiliar with the whole oe/bitbake structure. how would I go and troubleshoot that? Mar 01 15:57:58 and all that because I wanted a working fennec build... Mar 01 15:58:31 jftr the fennec package I got from the regular feed looked rather broken Mar 01 15:59:33 03Martin Jansa  07org.openembedded.dev * r175f25a8e3 10openembedded.git/recipes/linux/ (3 files in 2 dirs): Mar 01 15:59:33 linux-openmoko-2.6.32: simplified JBT6k74 driver as WSOD fix Mar 01 15:59:33 Signed-off-by: Martin Jansa Mar 01 15:59:35 03Martin Jansa  07org.openembedded.dev * r517816ac3c 10openembedded.git/recipes/shr/ (initscripts-shr/mountdevsubfs.sh initscripts-shr_0.0.1.bb): Mar 01 15:59:35 initscripts-shr: create /dev/pts, /dev/shm if they doesn't exist (devtmpfs doesn't create them for us and ssh login fails later due to missing PTYs) Mar 01 15:59:35 Signed-off-by: Martin Jansa Mar 01 15:59:36 03Martin Jansa  07org.openembedded.dev * r899adeeaab 10openembedded.git/recipes/tasks/task-shr-minimal.bb: Mar 01 15:59:36 task-shr-minimal: we need MACHINE_ARCH, because task-base and MACHINE_TASK_PROVIDER are machine specific Mar 01 15:59:36 Signed-off-by: Martin Jansa Mar 01 15:59:37 03Martin Jansa  07org.openembedded.dev * r98278bf81f 10openembedded.git/recipes/xorg-xserver/xorg-xserver-common.inc: Mar 01 15:59:37 xorg-xserver-common: move DISTRO_XORG_CONFIG_MANAGER from RDEPENDS to DEPENDS, because configure checks hal availability. Thanks to gilligan for reporting. Mar 01 15:59:38 Signed-off-by: Martin Jansa Mar 01 15:59:38 03Martin Jansa  07org.openembedded.dev * r0d6078ea08 10openembedded.git/recipes/ (dri/libdrm_git.bb mesa/mesa-dri_git.bb): Mar 01 15:59:54 mesa-dri, libdrm: use distro override to force same PV for om-gta01 and om-gta02 Mar 01 15:59:54 Signed-off-by: Martin Jansa Mar 01 16:00:05 does anyone know if qemu-arm will be of any use for trying beagleboard images ? Mar 01 16:00:40 dm8tbr: fennec_hg.bb is doing a "inherit mozilla", which means the textual content of "classes/mozilla.bbclass" is copied into the recipe. Mar 01 16:00:59 at least qemu-arm lists cortex-a8 as cpu model.. can't be all bad ;) Mar 01 16:01:56 nuhu, expect me back with more questions during the weekend. I'll try to wrap my head around that then Mar 01 16:02:21 dm8tbr: eeek. okay. Troubleshooting. Figure out who is coming up with the "bad" path. The first stop should be config.log of the fennec build Mar 01 16:02:38 I won't put up with an horribly slow firefox3 if I could have a better performing firefox mobile... Mar 01 16:03:19 roger that. lot's of grep ahead :) Mar 01 16:05:30 dm8tbr: yeah, the config.log is quite easy. I would try to figure out if it is a) something we pass with a --option to ./configure or b) firefox figures it out by itself Mar 01 16:05:51 ok Mar 01 17:06:13 Dammit, this compiler still doesn't claim to do EABI. Mar 01 17:11:44 Hi all, Mar 01 17:12:47 I experience a strange problem when trying to use my QT4 application in angstrom (both QT4 and GCC are the standard versions from angstrom) : I cannot run my app, and I have the error message : /lib/libgcc_s.so.1: version 'GCC_4.1.0' not found (required by /usr/lib/libQtScriptE.so.4) Mar 01 17:13:36 (despite I compiled everything in a "single shot", with GCC 4.3.3) Mar 01 17:13:55 does anyone know where it could come from ? (is it a bug ?) Mar 01 17:35:56 03Antonio Ospite  07org.openembedded.dev * r04fa0decdc 10openembedded.git/recipes/meta/meta-toolchain.bb: Mar 01 17:35:56 meta-toolchain: Show the host system in toolchain archive name Mar 01 17:35:56 Signed-off-by: Antonio Ospite Mar 01 17:35:56 Signed-off-by: Tom Rini Mar 01 17:48:35 hey khem? Mar 01 18:11:55 * kergoth grumbles Mar 01 18:12:23 somehow my rootfs got populated by unstripped libraries... how did that happen? Mar 01 18:13:46 It's a bug, I'll push a fix in a moment Mar 01 18:14:06 oh ok, cool Mar 01 18:14:15 I'll be here to test it then Mar 01 18:16:48 03Chris Larson  07org.openembedded.dev * r9ce55ea62b 10openembedded.git/classes/package.bbclass: Mar 01 18:16:48 Revert "package.bbclass: when running 'file', be explicit about the path to the magic" Mar 01 18:16:48 Drop this for now, as apparently the magic file location varies with 'file' Mar 01 18:16:48 version. I'll just patch file to find it relative to the binary location Mar 01 18:16:48 instead. Mar 01 18:16:49 This reverts commit 1b5e7041ae3b26b7e59c76bd2f2fd72e35492940. Mar 01 18:16:55 Jin^eLD: that should do it. Mar 01 18:17:02 thanks Mar 01 18:17:07 np Mar 01 18:45:09 03Martin Jansa  07org.openembedded.dev * red51f18cde 10openembedded.git/recipes/xinput-calibrator/ (4 files): Mar 01 18:45:09 xinput-calibrator: add version 0.6.0 and also git version from misclick branch Mar 01 18:45:09 Signed-off-by: Martin Jansa Mar 01 18:53:10 kergoth, seen me s/!=None// hunks? Mar 01 18:56:04 file. btw.. version specific patches. From a short glance, i did not manage to find precedence for how would i express for foo-47.11 apply bar-0.8.15-if-foo-47.11.patch ? Mar 01 18:56:08 didn't, sounds good though Mar 01 18:57:11 kergoth, perhaps i forgot to send it out? mompls.. Mar 01 19:00:17 kergoth, oh, and i'm contemplating a \"parser.add_option( "-C", "--kconfig", help = "emit kconfig",\" inspired by your (rightful) complaint^Wnote to the libtool list, fyi Mar 01 19:05:17 kergoth, story was like: find ./ -name "*.py" -exec sed -i -e "s/\!=[[:space:]]*None:/:/g" {} +; && git commit -s -a -m '*: trim != None:' && yes | git send-email --to $kergoth HEAD^..HEAD Mar 01 19:06:57 kergoth, but i'm apparently unable to find the box that i used to generate it :( Anyway. PLease push if you feel like (it works fine for me for my oe setup, if that counts as testing) Mar 01 19:08:03 kergoth, and yes, you're really in my .profile.local by now ;) Mar 01 19:08:47 kergoth, although you seem to (still?) have a box where your GIT_ points to MV, so perhaps check them.. :) Mar 01 19:09:44 * kergoth isn't at MV, and doesn't have access to anything of MV. Mar 01 19:10:21 Hey, I need to understand why I should set vm.mmap_min_addr to 0.. Can anyone respond me ? Mar 01 19:10:59 i really hate computers. Mar 01 19:11:51 kergoth: Apparently the feeling's mutual :) Mar 01 19:11:57 indeed Mar 01 19:12:39 :) Mar 01 19:13:31 ;P Mar 01 19:18:32 kergoth, be assured that i share your feelings in this respect. Thing is, if no-one fixes them they won't get any better. Think LFS, threads or NLS. Plain PITA, but if they cry for crap like that?.. Mar 01 19:31:34 kergoth: any plans to restore df32920678d15c86897b50b752b937210a01edea commit? Mar 01 19:32:34 vadmeste: qemu <0.12 (so any OE one) require that to get binary locale generation working Mar 01 19:33:12 kergoth: thats about using md5/sha256 from Python instead of calling commands Mar 01 19:34:11 hrw uh why was it switched? Mar 01 19:34:19 hrw, md5 is already in there, no? and sha256sum is just a matter of seeing if the hasher supports it else fallback to a bb internal sha256 impl in C that gets linked in Mar 01 19:35:22 blindvt: 80 md5pipe = os.popen('PATH=%s md5sum %s' % (bb.data.getVar('PATH', data, True), localpath)) Mar 01 19:35:31 hm Mar 01 19:35:33 blindvt: we call commands like before Mar 01 19:35:41 qgit dont find this revision Mar 01 19:36:55 commit df32920678d15c86897b50b752b937210a01edea Mar 01 19:36:55 Author: Ross Burton Mar 01 19:36:55 Date: Fri Jan 15 08:30:33 2010 +0000 Mar 01 19:37:02 was reverted in: Mar 01 19:37:07 hrw, wasn't there some try:\nimport md5 block int here that was supposed to handle that? Dunno offhand Mar 01 19:37:09 commit 22ee98e2fc4d58de61184332e41b9a44c949ed17 Mar 01 19:37:09 Author: Chris Larson Mar 01 19:37:09 Date: Thu Feb 25 13:11:28 2010 -0700 Mar 01 19:37:16 hm oh Mar 01 19:37:22 didnt update Mar 01 19:37:24 since then Mar 01 19:37:25 *g* Mar 01 19:37:48 hrw, or s/md5/hashlib/ or however it's called Mar 01 19:38:12 blindvt: I know, I had hands in that code in Poky time Mar 01 19:41:49 hrw, http://bugs.python.org/msg45775 so this should now be available about everywhere i guess Mar 01 19:45:08 hello Mar 01 19:45:13 i am new to oe Mar 01 19:45:14 hrw, let's just move the pipe fallback to lib/bb/oh_dear/sha256.freakin-python-issue935454.py and import that (deriving hashlib) as 256sum-er Mar 01 19:45:40 jo zecke Mar 01 19:45:43 reithi_: we all did Mar 01 19:45:53 hrw *g* Mar 01 19:46:06 I like to build a qte image Mar 01 19:46:17 sure Mar 01 19:46:19 do it Mar 01 19:46:21 i wouldn't want to Mar 01 19:46:21 is opie the place to start ? Mar 01 19:46:26 no Mar 01 19:46:31 * hrw was new 6 years ago and that was not fun Mar 01 19:46:32 opie is based on qt2 Mar 01 19:47:02 hrw, i'm new #here now and it is. Everthing's jazz :) Mar 01 19:47:11 so is there a receipe using qte 453 Mar 01 19:47:24 we are at 4.6 too Mar 01 19:47:53 great Mar 01 19:48:10 if you want Mar 01 19:48:13 with gles support Mar 01 19:48:21 so how to build a rootfs image ? Mar 01 19:48:34 look under recipes/qt4 Mar 01 19:48:47 hm? Mar 01 19:49:05 ok I will do Mar 01 19:49:13 an image likes to contains a rootfs Mar 01 19:49:13 thx so far Mar 01 19:49:27 so building a rootfs-image is missleading Mar 01 19:49:50 ok Mar 01 19:50:11 I build an console image so far Mar 01 19:50:31 now i need qte with fb support Mar 01 19:51:19 look at recipes/images Mar 01 19:51:28 how to make your custom image Mar 01 19:51:36 or make console-image Mar 01 19:51:42 and install qte packages afterward Mar 01 19:51:45 via opkg Mar 01 19:52:16 thats what i did so far ;-) Mar 01 19:53:28 but I thougth there may be something existing so far Mar 01 19:55:19 however I'll have a look and try to make a custom one Mar 01 19:55:47 thx woglinde Mar 01 20:27:13 hmm. Mar 01 20:28:36 jo kergoth Mar 01 20:33:15 bye Mar 01 20:33:50 nite hrw Mar 01 20:41:31 03Frans Meulenbroeks  07org.openembedded.dev * r23009a6ecf 10openembedded.git/recipes/u-boot/ (3 files in 2 dirs): (log message trimmed) Mar 01 20:41:31 u-boot: removed environment patches Mar 01 20:41:31 removed 0006-cmd_itest.c-also-support-environment-variables-as-a.patch Mar 01 20:41:31 this one was rejected upstream as the functionality was already in hush Mar 01 20:41:31 reworked 0007-cmd_setexpr-allow-memory-addresses-and-env-vars-in-e.patch Mar 01 20:41:32 the setenv part was rejected upstream as the functionality was already in hush Mar 01 20:41:33 took that part out of the patch. Mar 01 20:41:34 03Frans Meulenbroeks  07org.openembedded.dev * rf0da6033e6 10openembedded.git/recipes/tasks/task-nas-server.bb: (log message trimmed) Mar 01 20:41:34 task-nas-server removed the openmoko part Mar 01 20:41:34 removed the openmoko part from the nas server task Mar 01 20:41:35 this part only drags in dfu-util which does not build under most distro's Mar 01 20:41:35 openmoko users are very unlikely to run a NAS on their device, and even Mar 01 20:41:36 if they want to and need dfu-util, they can easily install afterwards Mar 01 20:41:36 (and dfu-util is not even nas related, so it does not really belong in this task) Mar 01 20:41:37 03Frans Meulenbroeks  07org.openembedded.dev * r9c022f7728 10openembedded.git/ (2 files in 2 dirs): Mar 01 20:41:37 linux/linux-davinci/hawkboard added netfilter modules to defconfig Mar 01 20:42:23 added netfilter modules to hawkboard defconfig Mar 01 20:42:23 these are needed in order to build nas-server-image Mar 01 20:42:23 Signed-off-by: Frans Meulenbroeks Mar 01 20:44:52 Oh my Mar 01 20:45:02 qemu gcc 3.x checks are insane... Mar 01 20:45:15 Is 3.2.x and 3.3.x supposed to work on the old magic 0.9.x versions? Mar 01 20:45:30 It's listed in the gcc check fn, but still saying "Only some 3.4.x's will work" Mar 01 20:48:06 re Mar 01 20:49:41 hey florian Mar 01 20:49:52 hi florian Mar 01 20:55:29 as brought up by graham on the ML: why do we keep svn-updates.dpatch in the gcc 4.3.[1-4] dirs ? Mar 01 20:56:08 saw the 4.4 versions are gone Mar 01 20:56:48 Probably because someone didn't notice they weren't used anymore, and then just left them there Mar 01 20:57:06 It should become svn-updates-4.whatever-uses-it.dpatch, in the files/ dir Mar 01 20:57:10 And nuke all of the extra copies Mar 01 20:57:29 (Of course then someone will ask about dropping all of the various very old versions, say pre 4.2.4 at least) Mar 01 21:01:39 hrw|gone: Do you recall why you added gcc-3.3.x / 3.2.x to the qemu gcc logic? Mar 01 21:01:58 hrw|gone: Well, 3.2.x.. Mar 01 21:04:42 Tartarus: actually they are not used at all Mar 01 21:04:59 I assume, but could be wrong, that at some point it was used Mar 01 21:05:08 But if it's never ever been used, hey, that's an even easier fix :) Mar 01 21:05:17 frans@linux-suse:~/oe/openembedded/recipes/gcc> grep svn-updates * Mar 01 21:05:17 frans@linux-suse:~/oe/openembedded/recipes/gcc> Mar 01 21:05:29 Yeah, but does that catch the rename? Mar 01 21:05:38 (packages/ to recipes/) Mar 01 21:05:49 git grep it, with some magic flags Mar 01 21:06:24 Tartarus: don't understand, if there is no recipe in recipes/gcc using it, then it is pointless to keep it around isn't it ? Mar 01 21:06:47 Right. But it's good to know (for the comments) when it should have been deleted Mar 01 21:06:51 btw as several people reacted on graham's email I expected that someone already fixed it Mar 01 21:07:23 will try some git magic :-) Mar 01 21:09:47 seems they are just copied over Mar 01 21:13:17 hmm, better leave it as is, i think i've but enough karma on the line last few weeks, better not risk getting the whole community over me if something still accidently breaks, will drop an email though guess gcc patches should go to the review procedure anyway Mar 01 21:14:38 eFfeM, best become an expert on gcc first :) Mar 01 21:17:05 Crofton :-) Mar 01 21:24:29 * We currently have two bytes left at this point until we Mar 01 21:24:29 * crash into the system call handler... Mar 01 21:24:46 yes it does let us know, let us know that the avr32 kernel dudes are smoking something :-( Mar 01 21:34:17 hi ant Mar 01 21:34:27 * XorA is actually stunned Mar 01 21:34:41 xora why? Mar 01 21:34:58 woglinde: I dont think anyone is compiling avr32 Mar 01 21:35:06 they are just randomely checking in patches Mar 01 21:35:14 or there is some magic secret version of binutils Mar 01 21:35:26 xora some people tried the over the last weeks Mar 01 21:35:39 woglinde: I dont mean in OE, I mean kernel developers Mar 01 21:36:00 hm oh Mar 01 21:36:10 I think avr32 is dead for them Mar 01 21:36:16 as its for atmel Mar 01 21:36:31 I just cant beleive this patch, and it comes from atmel Mar 01 21:36:39 oh wau the n810 survied 3 weeks with out power Mar 01 21:36:56 hehe aks ulf Mar 01 21:36:59 ups ask Mar 01 21:38:19 hello woglinde Mar 01 21:38:22 hi XorA Mar 01 21:38:39 * XorA should have stayed as a windows kernel developer :_D Mar 01 21:39:20 windows kernel developer? Mar 01 21:39:25 are you serious? :P Mar 01 21:39:54 i would like to kill somebody at embest by the way Mar 01 21:40:03 xora hm you would have missed a lot of fun Mar 01 21:40:21 i follow their manual, and the CF card still doesn't work Mar 01 21:40:35 romke hm? Mar 01 21:40:55 yeah Mar 01 21:41:05 i've got an SBC6020 at the office Mar 01 21:41:10 why shouldn't a cf card not work? Mar 01 21:41:27 with an at91sam9g20 cpu Mar 01 21:41:52 but only one ethernet interface works Mar 01 21:41:57 the cf card doesn't work Mar 01 21:42:10 only three out out 7 USART's work Mar 01 21:42:24 usb seems to work Mar 01 21:43:26 i've got 2.6.33 kernel, with all the driver options they state in their manual enabled Mar 01 21:43:30 but it still doesn't work Mar 01 21:43:43 hm Mar 01 21:43:50 which makes me want to kill the bloody chinese who wrote the manual :P Mar 01 21:43:58 for x86 hardware I would say check the bios Mar 01 21:44:07 yeah Mar 01 21:44:09 otherwis maybee hardware is broken Mar 01 21:44:17 the stock kernel works Mar 01 21:44:37 recognices the CF card 'nd stuff Mar 01 21:44:52 but i can't even extract the sources provided on the cd Mar 01 21:45:10 lol? Mar 01 21:45:21 vanilla kernel works out of the box? Mar 01 21:45:24 no Mar 01 21:45:28 not vanilla kernel Mar 01 21:45:31 the kernel they proviced Mar 01 21:45:35 provided* Mar 01 21:45:37 ah yeah Mar 01 21:45:53 but they didn't provide the patches they used Mar 01 21:45:58 uh Mar 01 21:46:04 thats not good Mar 01 21:46:06 if any Mar 01 21:46:19 woglinde: hey! Mar 01 21:46:29 jo zecke Mar 01 21:46:36 which would mean that i would have to run diff over their source and the vanilla source Mar 01 21:49:00 work, work, hack, hack Mar 01 21:49:15 well, i'll live Mar 01 21:49:27 being the intern ftw Mar 01 21:50:03 i have virtually no time restrictions :+ Mar 01 21:51:09 Tartarus: hello looking for me still ? :) Mar 01 21:51:12 hi all Mar 01 21:52:13 hello Mar 01 21:53:43 yeah Mar 01 21:53:54 hi khem Mar 01 21:53:55 khem: You didn't really reply to my suggestions for eglibc packaging :) Mar 01 21:54:29 Do you want any/all of that? And if so, are you planning to do the glibc-packaging.bbclass -> eglibc-packaging.inc easy stuff? Mar 01 21:54:40 (ie resync the -dev packages, add libmemwhatever) Mar 01 21:56:22 grr, stupid "build within a path that has a symlink" bug Mar 01 21:56:32 * kergoth forgot about that one :) Mar 01 21:56:35 heh Mar 01 21:57:27 kergoth: btw, what exactly causes that bug? Mar 01 21:57:52 I think some of the autotools scripts have issues with that Mar 01 21:58:00 iirc its the difference between $PWD and the specified path. i think it was autoconf that compares the two to check somethingorother Mar 01 21:58:01 so it is not really an OE specific issues Mar 01 21:58:04 * kergoth nods Mar 01 21:59:03 right Mar 01 21:59:43 someday should look into how much work itd be to fix.. thats one of those long standing little quirks Mar 01 21:59:45 heh Mar 01 22:00:59 now I remember this - GNUmakefile: Too many levels of symbolic links Mar 01 22:01:48 khem: Ah, dead disks suck. Mar 01 22:01:57 khem, I'll see what I can do for some patches and maybe even testing ;) Mar 01 22:02:43 Tartarus: you mentioned you have pstage outside of temp in your setup... Mar 01 22:03:04 correct Mar 01 22:03:18 Tartarus: but not deploy. does the build from pstage work if you nuke tmp dir? Mar 01 22:03:32 it does, yes Mar 01 22:03:44 don't you need real ipks also? Mar 01 22:03:56 pstage packages include the binary packages for the target. Mar 01 22:04:14 Yeah Mar 01 22:04:24 Tartarus: re. eglibc I said that its going to diverge even more Mar 01 22:04:32 My hell-build is doing every package step for a "full" build from just the caches of previous deps Mar 01 22:04:44 * kergoth has thought about just capturing the do_install into the pstage package and let packaging go from that, to keep packaging changes from invalidating pstage packages, though Mar 01 22:04:51 and so having common include or something for glibc might not be fruitful in long run Mar 01 22:04:55 khem: Right, so no generic'ing of glibc's bbclass. But there's stuff they need Mar 01 22:04:59 Er Mar 01 22:05:04 Stuff in there eglibc needs Mar 01 22:05:31 Tartarus: may be having a generic class for libc would be better including eglibc/glibc/uclibc Mar 01 22:05:45 because eglibc's build will tend more towards uclibc Mar 01 22:05:53 khem: Perhaps, yes. It really depends on what common stuff there really is.. Mar 01 22:06:16 Tartarus: packaging for eglibc and glibc will remain same to a certain extent Mar 01 22:06:23 khem: But my questions are (a) are you going to fix/resync -dev and add libmemwhateverthat is or should I and (b) what do you think about adding *libc-pic packages? Mar 01 22:06:42 yeah sync is good Mar 01 22:06:45 go ahead Mar 01 22:06:48 k Mar 01 22:06:58 we should take the goodies Mar 01 22:07:00 for free Mar 01 22:07:01 Doing an initial set of builds now Mar 01 22:07:08 Will resync, rebuild and post some stuff tomorrow Mar 01 22:07:16 Tartarus: sounds gr8 Mar 01 22:07:44 sakoman - tried your R11 "Gnome image"; still have the same problem Mar 01 22:08:31 robtow: sorry to hear that :-( Mar 01 22:09:04 sakoman - using brand new "Fire" module, on a new Tobi - isn't that your setup? Mar 01 22:09:31 yes Mar 01 22:09:32 Also got a friend's Canon Rebel XT - so I think I have duplicated your setup pretty closely Mar 01 22:09:41 remind me what your issue is? Mar 01 22:10:17 Getting error from gPhoto2 when trying to take pix or list files via USB from either a Canon G10 or a Rebel. Mar 01 22:10:35 Tried both the latest Gumstix image, and your Gnome R11. Mar 01 22:11:33 "usb 1-1: BOGUS urb flags, 1 --> 0" appears on the console, three times. Mar 01 22:11:54 robtow: I'll have to try again sometime this week, perhaps there has been bit rot since the last time I used it Mar 01 22:11:58 Hmm. Mar 01 22:12:48 sakoman - has it been a while since you did I'm not sure I *ever* did anything from the command line! Mar 01 22:13:35 Ah. Hmm! Mar 01 22:13:51 I mostly just tried the GUI features and things seemed to work Mar 01 22:13:57 nods> Mar 01 22:14:43 on a deadline for a client, so no time to test today Mar 01 22:15:06 sakoman: you are keeping gnome uptodate? could you take a look at the gnome-screensaver package? there was a small security incident and I think our version is unpatched. Mar 01 22:15:22 I understand :-) I'll struggle ahead as I can. One question, though - from the GUI did you only do list and download, or did you also do capture? Mar 01 22:15:49 robtow: just list and download, not capture Mar 01 22:16:18 robtow, when I get bored (hahahaha) I have a small nikon I would like to try with ghoto Mar 01 22:16:20 zecke: we should form a security team Mar 01 22:16:26 zecke: as I have time I update things Mar 01 22:16:29 zecke: I would be part of it Mar 01 22:16:43 but haven't looked at screensaver recently Mar 01 22:17:00 Thanks, sakoman (altho' even list is not working from gPhoto2). Mar 01 22:17:14 yay, my plane has landed Mar 01 22:17:21 sakoman - which gui program did you use for list & download? Mar 01 22:17:24 khem: we should, would you have regular time for such an activity? My work life is coming in peeks making such things harder. Mar 01 22:17:35 Crofton - which model Nikon? Mar 01 22:18:03 robtow, not sure, it was a compact cam, and the lcd viewfinder is broken Mar 01 22:18:09 zecke: I wud devote some time per week. Mar 01 22:18:15 used AA batteries Mar 01 22:18:33 khem, zecke forming a team to try and keep up with security would be a good thing Mar 01 22:18:46 Crofton - it probably only works with list & xfer, not capture; most of the point and shoot cameras are like that - the G10 is unusual in that regard. Mar 01 22:18:49 robtow, it will be a while before I can look at it though Mar 01 22:19:14 I can say from having done it before, security stuff is time consuming as hell :( Mar 01 22:19:15 Mar 01 22:19:23 Depending on how proactive you want to be Mar 01 22:19:26 zecke: job + 2 kids keeps me busy and job does use OE so its all in my own time Mar 01 22:19:38 ie I had to make a script to dump the CVE db and do a diff, daily Mar 01 22:19:40 I *have* to get gPhoto2 to work with the gumstix. Sigh. I had it working with the Beagleboard. Mar 01 22:19:43 it would still be a start getting some contact poepl together Mar 01 22:19:47 And then give me the info on what changed Mar 01 22:19:51 Tartarus: eh I remember your MV days ;) Mar 01 22:20:03 khem: cool, then we should do it. My primary goal would be to get the nr. of known issues down to zero. Mar 01 22:20:19 khem: should we aim to get on the distro security lists too? Mar 01 22:20:19 I tried both USB paorts on the Gumstix; got a mini-A to mini-B cable today. Mar 01 22:20:25 zecke: right. I will scan thru your list and see what we can do Mar 01 22:20:47 zecke: that wud be good idea Mar 01 22:20:51 ok, I need to get ready to go hopefully we board soon Mar 01 22:20:52 robtow: I think I was using gthumb Mar 01 22:21:05 khem, zecke, are you guys thinking of fixing all of the old applicable versions or don't know yet? Mar 01 22:21:16 That was one of the time consuming parts Mar 01 22:21:26 sakoman - I'll give that a try... Mar 01 22:21:36 Tartarus: probably we should only fix active recipes first Mar 01 22:21:49 which means the recipes used in current distro's Mar 01 22:21:51 Tartarus: no, most likely latest. Either by bumping the version or finding a patch. Mar 01 22:21:58 and go from there Mar 01 22:22:01 That will help a little bit Mar 01 22:22:14 Tartarus: how did you map CVE entry to package name of your distro? Mar 01 22:22:29 zecke: Couldn't automate that part Mar 01 22:22:41 heh yeah its a manual think Mar 01 22:22:43 There wasn't at the time any standard format for that kind of info in the CVE Mar 01 22:22:59 So one of my morning tasks was to check the emails I had generated Mar 01 22:23:03 Tartarus: what was your primary source to detect the issues Mar 01 22:23:09 one could probably cheat and use the HOMEPAGE field. Mar 01 22:23:14 khem, to find new CVEs? Mar 01 22:23:18 Tartarus: yes Mar 01 22:23:21 zecke: In the CVE or the recipes? Mar 01 22:23:24 sec.. Mar 01 22:23:42 lemme see if I have this around still Mar 01 22:23:44 I hope I do Mar 01 22:24:10 Bingo'ish Mar 01 22:24:14 http://cve.mitre.org Mar 01 22:24:21 There's a link there, somewhere, to a daily dump of the db Mar 01 22:24:23 zecke: we could add CVE number to patch Mar 01 22:24:38 zecke: then we could deduce from the SRC_URI and files:// Mar 01 22:24:39 I cron'd, diff,ed old to new and then did a for loop to dump each new CVE into an email Mar 01 22:24:45 Then procmail'd that to a folder Mar 01 22:25:04 khem: right now my sources would be RSS for FreeBSD, Gentoo, Debian. For FreeBSD I have a script. For most of the packages I have 1:1 mapping, for others I have a map (e.g. pcre2 -> libpcre) Mar 01 22:25:08 khem: good idea. Mar 01 22:25:44 khem: so far I have only opted to make big upgrade. but applying the patch is a more conversative approach. Mar 01 22:25:45 That'll catch when we've got stuff in common Mar 01 22:25:46 * khem doesnt use RSS so much Mar 01 22:25:49 Which might be good enough to start with Mar 01 22:26:07 Get us out of the real bad place and decide if we want more work still Mar 01 22:26:31 * khem pokes at akregator Mar 01 22:26:38 sakoman - gThumb sees the Canon Rebel, but throughs an error. Mar 01 22:27:00 Aw, looks like I might not have been smart enough to archive that particular script Mar 01 22:27:13 "An error ocurred in the io-library ('Unspecified error'): No error description available. Mar 01 22:27:17 Tartarus: one issue is with the CVE. I could reserve a number now, and disclose in a year. Would the CVE still show up at the time of the diclosure? Mar 01 22:27:34 zecke: The DB is only disclosed stuff Mar 01 22:27:42 Sometimes with a minor (unintentional) lag Mar 01 22:27:58 So yes, from time to time I'd see stuff show up that was an otherwise "old" looking number Mar 01 22:28:34 And, iirc, I did things this way since the various summary pages they did have didn't catch that stuff well, or at least it was a pain to read (no rss feed of it, at least at the time) Mar 01 22:28:58 So I went from reload the daily updates page, open all links, to generate my own daily diffs in an email Mar 01 22:29:30 Time for a lunch break. Mar 01 22:30:30 So, unrelated, anyone think the firefox deps are good enough now that bitbake firefox, on an empty TMPDIR will work? Mar 01 22:30:45 I think I've got the "right" parallel make stuff done for it and need to test :) Mar 01 22:31:24 hmm. Mar 01 22:31:27 Tartarus: yeah bitbake it may be you will figure out missing dependencies too as a bonus Mar 01 22:32:46 khem: heh Mar 01 22:32:53 Only so many cpu cycles per hour :) Mar 01 22:34:13 https://cassandra.cerias.purdue.edu/CVE_changes/ that is nice Mar 01 22:36:09 Yeah, that's the site I got tired of :) Mar 01 22:36:52 it might be easier to stand on the shoulders of debian, gentoo and FreeBSD. They filter relevant software Mar 01 22:36:58 If I had it to do over, I'd see if I could get ahold of someone and add some rss feeds Mar 01 22:37:10 zecke: I'd strongly recommend that as a first pass Mar 01 22:37:27 nice Mar 01 22:37:30 And maybe try prodding the commerical folks to make sure they're pushing any relevant security stuff up too Mar 01 22:37:48 That might help cover older backports at least Mar 01 22:38:58 the most difficult part in my script is version comparison... i thought bitbake's stuff would help me but it does not. Mar 01 22:40:26 Again, depends on how through you need to be on being up to date / fixed. Mar 01 22:40:50 The min version broken stuff depends on who had time to check what, in some cases Mar 01 22:41:14 So at some point you need to just check your version, to be really sure Mar 01 22:42:38 khem: nice that we agree on the first target. We should keep a log too? For stuff where we apply a patch we put the cve name in the filename. What about stuff like my wireshark upgrade from yesterday. It is fixing several CVEs but I didn't mention that in the commit message. Mar 01 22:43:06 yeah having it in commit message will help too Mar 01 22:43:17 so adding CVE number in commit message and recipes Mar 01 22:43:26 and probably keep a doc on wiki Mar 01 22:43:55 khem: doc in wiki? sorted by date? like a changelog? Mar 01 22:45:28 Keep in mind the version X comes out, then CVE Y is announced later Mar 01 22:45:38 Any info you have at the time is good, of course Mar 01 22:45:54 But if we want some form of real definitive info, a google doc or wiki table or something Mar 01 22:46:01 how do you decide which versions of a recipe get a backported fix? Mar 01 22:46:29 there are going to be cases where it is relevant for many versions that are in use in the tree Mar 01 22:46:31 grg: At the moment, the thought is most recent and distros can fix older if needed Mar 01 22:46:43 ok. that makes sense Mar 01 22:46:51 Since from experience the backport to 10 versions thing is time consuming :( Mar 01 22:46:56 grg: or is the question upgrade vs. patch? Mar 01 22:47:16 zecke, yes. Both are going to happen, i suspect. Mar 01 22:48:00 grg: yeah, specially right now. E.g. vim 7.0 has a sec issue with ftp in one plugin. In this case updating vim 7.2 just makes more sense Mar 01 22:48:17 zecke: I think and upgrade should be preferred to patch prolly Mar 01 22:48:30 vim has ftp support? wtf? Mar 01 22:48:43 vim has to compete with emacs Mar 01 22:48:46 grg: a plugin Mar 01 22:48:47 ha! Mar 01 22:49:00 vim has plugins? ;) Mar 01 22:49:08 yeah :) Mar 01 22:49:53 for me, vim has been feature complete since v5 Mar 01 22:50:41 heh Mar 01 22:50:50 grg: hi. I foun dout that updating libopkg to 522 broke opie-packagemanager. I have no idea of both packages. Question: did opkg have some major header split lately? Mar 01 22:51:27 I think that for public OE, esp the dev branch, the end choice is going to be update to latest and just patch when there is no latest yet or we're really behind and update would be hard Mar 01 22:51:40 The stable branches will need their own security work Mar 01 22:51:42 ant__, yeah. I cleaned up a bunch of headers in r504 Mar 01 22:52:01 ah, ok, thx for confirming Mar 01 22:52:18 btw it's the single package failing atm Mar 01 22:52:18 ant__, opkg frontends will not be compatible with both 0.1.7 and 0.1.8 Mar 01 22:52:45 ant__, and if i have the time, the interface will change again. Mar 01 22:52:58 ant__: did you solve your klibc issue ? Mar 01 22:53:02 grg: Iìll have to ask bluelightning to bump opie packagemanager Mar 01 22:53:08 ant__: sorry I did not have much time for past couple of weeks Mar 01 22:53:09 khem: well, some of Mar 01 22:53:11 it build now Mar 01 22:53:19 ant__: ok nice Mar 01 22:53:28 khem: the biggest issues are probably: OpenSSL and gnutls... both have issues Mar 01 22:53:35 the fact is klibc still eeds linux headers to compile Mar 01 22:53:35 zecke: agree Mar 01 22:53:47 headers_install is used only on the deploy side Mar 01 22:53:48 ant__: yes infact it needs a raw linux tree Mar 01 22:53:50 not staged one Mar 01 22:53:53 but Mar 01 22:53:58 khem: i will have to sleep now. Mar 01 22:54:03 hpa promised he'd work on this Mar 01 22:54:09 zecke: gn Mar 01 22:54:19 khem: if you feel like, you could send an announcement mail with the ideas we have? if not I can draft such an email during the day Mar 01 22:54:47 zecke: ok if you dont see an email when you wake up then you know you have to do it :) Mar 01 22:54:48 khem: http://www.zytor.com/pipermail/klibc/2010-February/002483.html Mar 01 22:55:17 sakoman - I'm going to try your Gnome R8 version. Mar 01 22:57:21 ant__: yeah in parts problem wrt klibc in OE is that we dont put same source tree for kernel in staging and klibc build uses it Mar 01 22:57:26 khem: well, was first msg in the thread Mar 01 22:57:35 khem: exactly Mar 01 22:58:18 ant__: one solution we could use is that we could build linux-libc-headers and stage them which can then be symlinked during klibc build and we dont have to do install_headers step in klibc build Mar 01 22:58:40 somewhere hpa said the libc headers are not enough :/ Mar 01 22:58:40 is there anything else it needs from kernel source tree ? Mar 01 22:58:54 oh well Mar 01 22:59:09 ah..no..here Mar 01 22:59:10 http://gentoo-portage.com/AJAX/Ebuild/95599/View Mar 01 22:59:12 I wonder why we muck with staged kernel tree Mar 01 22:59:33 probably some packages need the headers in old place Mar 01 23:00:49 * khem needs to eat Mar 01 23:01:28 khem: possibly best is wait for 1.5.16 Mar 01 23:01:54 and see if then klibc builds against headers_install headers Mar 01 23:02:28 guten appetit! Mar 01 23:03:09 RP__: ping? Mar 01 23:04:34 zecke: pong? Mar 01 23:05:05 RP__: sorry, to ask.. For a package with upstream version 2.0.36rc1, I'm going to pick 2.0.35+2.0.36rc1 as PV? Mar 01 23:05:29 zecke: Sounds good since we don't support ~ (yet) Mar 01 23:06:06 RP: wrt those strings, remember the vercmp in bitbake Mar 01 23:06:14 cannot cope Mar 01 23:06:17 * kergoth fights with BBCLASSEXTEND+amend.inc.. setting bbclassextend via an anonymous python function makes things very confused :) Mar 01 23:06:33 kergoth: I saw your patch for that and worried Mar 01 23:06:42 ant__: We need to fix that Mar 01 23:06:47 it confuses the whole based vs d logic Mar 01 23:06:52 * kergoth is working on it.. Mar 01 23:07:29 kergoth: I never really intended code to be able to do that Mar 01 23:07:40 hehe Mar 01 23:07:46 amend.inc is twisted, i know, but incredibly useful Mar 01 23:08:09 I'm thinking about giving bitbake a better mechanism to inject files to be parsed like that, instead of having to do it itself, and resulting in multiple finalise()s Mar 01 23:08:16 maybe just an env var listing extra files to pull in Mar 01 23:08:17 thoughts? Mar 01 23:08:56 You have to have multiple finalises though? Mar 01 23:09:20 well, if you want anonymous python functions in the amend.inc to function, anyway Mar 01 23:09:31 * kergoth ponders Mar 01 23:09:37 kergoth: I don't think I understand what ammend.inc does ;-) Mar 01 23:09:48 It's like 3 lines of code :) Mar 01 23:10:10 It searches FILESPATH for an amend.inc file. If it finds it, it parses it into the datastore with bb.parse.handle() Mar 01 23:10:14 that's all there is to it Mar 01 23:10:34 makes it easy to maintain recipe alterations out of band, in another overlay, or local to the build dir, or whatever Mar 01 23:10:44 eases the pain of oe syncs Mar 01 23:11:22 mkdir -p build/files/nano; echo 'BBCLASSEXTEND = "native"' >> build/files/nano/amend.inc; bitbake nano-native Mar 01 23:11:25 heh. Mar 01 23:12:01 kergoth: I'd actually been thinking of something similar recently - being able to do "require ${EXTRACONFFILES}" in the distro config Mar 01 23:13:12 The pathological EXTRACONFFILES = "" would be interesting though Mar 01 23:13:18 heh Mar 01 23:13:24 and require would need to be able to take a list Mar 01 23:13:56 kergoth: My main worry is the searching of FILESPATH rather than BBPATH Mar 01 23:14:04 Do we do that for includes anyway? Mar 01 23:14:11 in .bb files? Mar 01 23:14:13 no? Mar 01 23:14:20 that just prepends ${FILE_DIRNAME} to bbpath temporarily Mar 01 23:14:40 using filespath, i can have version or revision specific amend.incs easily, also Mar 01 23:15:04 kergoth: Right, that makes sense and I understand the attraction Mar 01 23:15:33 kergoth: It doesn't let you split the files into a separate tree though, right? Mar 01 23:15:40 not sure what you mean by that Mar 01 23:16:15 kergoth: So have a plain OE checkout in some directory and a set of ammend.inc files in another Mar 01 23:16:28 that works fine, if you manipualt eFILESPATHBASE Mar 01 23:16:28 w Mar 01 23:16:28 hi Mar 01 23:16:43 * kergoth rearchitected filespath this way for a reason :) Mar 01 23:16:53 blah, this computer is possessed at times, i swear Mar 01 23:16:53 kergoth: but you don't do that atm? Mar 01 23:17:00 not sure what you mean Mar 01 23:17:28 It's just that it doesn't play nice with another set of funny automagic stuff :) Mar 01 23:17:31 Can you have multiple FILESPATHBASE ? Mar 01 23:17:45 RP__: you set FILESPATHBASE to a bunch of things Mar 01 23:17:49 FILESPATHBASE is a colon separated list Mar 01 23:17:57 kergoth: right Mar 01 23:17:59 just as FILESPATHPKG and OVERRIDES are Mar 01 23:17:59 F Mar 01 23:17:59 I Mar 01 23:17:59 LE Mar 01 23:18:03 FILESPATH is constructed from all of them Mar 01 23:18:04 makes lots of sense Mar 01 23:18:19 * RP__ needs to get this into Poky Mar 01 23:18:37 * RP__ suspects it kills parsing time though? Mar 01 23:18:48 amend.inc hurts a little Mar 01 23:18:59 have to reparse the specific dirs you have one for Mar 01 23:19:05 dangit, where's that link someone put on the mailing list that set FILESPATHBASE based on BBPATH/COLLECTIONS Mar 01 23:19:11 * RP__ did a lot of work to remove FILESPATH from all parsing paths a while aho Mar 01 23:19:37 well, for every recipe that has one, it does an extra bb.parse.handle() for it Mar 01 23:19:54 kergoth: Its finding whether it has one thats the hit Mar 01 23:20:22 file for file in amendfiles if os.path.exists() Mar 01 23:20:28 is slow :( Mar 01 23:21:24 it also checks each of those paths when checking the status of the cache Mar 01 23:21:33 since it adds them all to __depends, to ensure that creating one invalidates the cache for the recipe Mar 01 23:21:34 :\ Mar 01 23:21:42 kergoth: ouch Mar 01 23:21:51 kergoth: I can guess why... Mar 01 23:21:53 worth the cost, though, for many, due to the improvement on the maintenance. Mar 01 23:22:06 I'd love to find a better way to manage it, but how.. Mar 01 23:24:16 kergoth: You include all ammend.inc files? Mar 01 23:24:27 currently only the first, but i think moving to all is a better bet Mar 01 23:24:27 o Mar 01 23:24:28 the Mar 01 23:24:28 r Mar 01 23:24:36 otherwise the user "overriding" an amend.inc will lose distro changes, or whatever Mar 01 23:24:42 which is unlikely what they expect Mar 01 23:24:45 heh Mar 01 23:24:47 kergoth: hmm, right Mar 01 23:24:56 there goes that optimisation ;-) Mar 01 23:25:08 * kergoth left it as is for consistency with the rest of OE for now, but changing it is on his oe issues list Mar 01 23:26:02 kergoth: For speed, being clever with the path building code may help Mar 01 23:26:22 03Holger Hans Peter Freyther  07org.openembedded.dev * r8f81a0fcff 10openembedded.git/ (3 files in 3 dirs): vorbis-tools: Upgrade to 1.2.0 Mar 01 23:26:23 03Holger Hans Peter Freyther  07org.openembedded.dev * r32b8772ca7 10openembedded.git/ (conf/checksums.ini recipes/gd/gd_2.0.33.bb): Mar 01 23:26:23 gd: Upgrade from 2.0.33 to 2.0.36RC1 Mar 01 23:26:23 * Move the checksums into the recipe Mar 01 23:26:23 * Pick 2.0.35+2.0.36rc1 as the name to remain easily upgradable Mar 01 23:26:24 * This should resolve: Mar 01 23:26:24 http://portaudit.FreeBSD.org/6e099997-25d8-11dc-878b-000c29c5647f.html Mar 01 23:26:25 http://portaudit.FreeBSD.org/4e8344a3-ca52-11de-8ee8-00215c6a37bb.html Mar 01 23:26:25 03Holger Hans Peter Freyther  07org.openembedded.dev * ra68d07365b 10openembedded.git/ (4 files in 3 dirs): (log message trimmed) Mar 01 23:26:26 wireshark: Upgrade from 1.0.5 to 1.2.6 Mar 01 23:26:26 Update the ieee80215.patch. The original commit message is so weak Mar 01 23:26:27 it is not saying why the wpan_nofcs variant is to be used. I'm Mar 01 23:26:27 respecting the original patch author here but it would be better Mar 01 23:26:28 to have nice commit messages. My feeling tells me that we should Mar 01 23:26:28 drop this patch as there is no indication why this patch is a good Mar 01 23:26:32 kergoth: For example if foo/ doesn't exist there is no point in checking for foo/A foo/B and foo/C Mar 01 23:27:12 hmm, thats a possibility Mar 01 23:27:33 kergoth: I'm sure I did that with the overrides in FILESPATH thing Mar 01 23:27:51 kergoth: but back then, FILESPATH wasn't a parsing issue Mar 01 23:28:09 kergoth: so if X didn't exist we could just drop it entirely Mar 01 23:28:24 the evaluation of FILESPATH already excludes the dirs that don't exist, so amend.inc will never see them Mar 01 23:28:32 iirc, anyway. Mar 01 23:28:49 Local test: bitbake -p w/ amend.bbclass inherited = 2m26s Mar 01 23:28:54 bitbake -p w/o amend.bbclass inherited = 2m20s Mar 01 23:28:55 kergoth: I think I did that... Mar 01 23:28:57 i think I'll live. Mar 01 23:29:07 kergoth: but that will break your cache ;-) Mar 01 23:29:13 hm? Mar 01 23:29:24 oh.. hmm. Mar 01 23:29:28 Add an amend.inc in an override dir? Mar 01 23:30:12 Its not as slow as I thought as you're not using the full list of paths I expected ;-) Mar 01 23:30:17 yeah, that case is probably broken at the moment. Mar 01 23:30:49 6s for total parse time is hardly worth complaining about given the convenience added, but lets see how bad it gets once the filespath includes them all... :) Mar 01 23:31:45 kergoth: You're talking a 5% speed loss... Mar 01 23:32:13 kergoth: we've done a lot for a lot less than that before :/ Mar 01 23:33:09 We'd take it faster if we can get it :) Mar 01 23:33:16 well, clearly some people think its worth it, given the number of people and companies already using it Mar 01 23:33:19 How many collections was that too? Mar 01 23:33:22 but yeah, by all means, improve it if we can Mar 01 23:34:22 kergoth: I'm not saying its a bad improvement, just highlighting why it causes a slow down so we can mitigate it if possivle Mar 01 23:34:49 * RP__ spent a lot of time looking into stuff like this a while ago :/ Mar 01 23:37:23 Well, if we had a version specific override, an amend.inc per recipe per collection would be likely be sufficient, so it could be done via bbpath/collections/bblayers. Mar 01 23:41:06 kergoth: I'll give it some thought. I'm wondering if some kind of central mechanism for this kind of thing might not work better... Mar 01 23:41:23 Oh yeah, once again, anyone Mar 01 23:41:42 Given that LIBC={eglibc,glibc,uclibc} why do we have minimal and minimal-uclibc? Mar 01 23:41:55 Well, like I said earlier, its definitely something that would do better by moving at least part of it into bitbake. The question is how. Mar 01 23:42:01 * Tartarus kicks his uclibc minimal build off before doing libc packaging stuff Mar 01 23:42:04 hmm Mar 01 23:42:06 kergoth: How about a global find of any ammend.inc files feeding into some magic somewhere Mar 01 23:42:18 kergoth: with a custom caching system... Mar 01 23:42:44 hmm. Mar 01 23:43:08 That should be faster than 6s Mar 01 23:44:49 I hate to hardcode the amend.inc thing into bitbake, but putting that find anywhere in the metadata would lead to cache nightmares Mar 01 23:44:50 meh Mar 01 23:45:14 lol fetchmail 6.3.8 is not fetchable :( Mar 01 23:45:57 kergoth: I'm thinking of a BBAMEND = "amend.inc" BBAMENDPATH="basepath1:basepath2" Mar 01 23:46:05 kergoth: or something Mar 01 23:46:57 kergoth: Just thinking out loud... Mar 01 23:46:57 that'd work. similar to what i was thinking earlier, just with the traversal moved into bitbake too to avoid the performance problems.. its a good idea, though how it associates the amend.incs to the recipes could be an interesting question Mar 01 23:47:00 * kergoth nods Mar 01 23:47:09 hmm. Mar 01 23:47:20 kergoth: Its like what I did with BBCLASSEXTEND Mar 01 23:47:37 Its generic but had to be in bitbake to make sense Mar 01 23:48:16 kergoth: I will leave you to ponder :) Mar 01 23:48:23 'night all! Mar 01 23:48:43 meh, i can't fix amend.inc+BBCLASSEXTEND without requiring the creation of the extra createCopy() that used to be done only for non-null bbclassextend Mar 01 23:48:46 hrmph Mar 01 23:48:48 night Mar 01 23:52:35 hi , did someone know any raw data reading from other usb device ? i just need to read some data from keyboard from usb layer that will be controlled by beagleboard ? someone know ? Mar 02 00:25:28 khem: Testing an eglibc sync up now Mar 02 00:55:52 hehe, i kicked off a -c fetchall -k world Mar 02 00:55:57 15,616 tasks Mar 02 01:11:12 oh my Mar 02 01:11:23 a number of threads I hope :) Mar 02 01:13:38 indeed. Mar 02 01:13:48 of course, it took like half an hour to generate the runqueue.. Mar 02 01:25:40 Hmmmm. bitbake nano... "OSError: [Errno 12] Cannot allocate memory" Mar 02 01:26:02 glibc_2.9.bb was unhappy. Mar 02 01:26:42 heh, ouch Mar 02 01:26:44 more swap? :) Mar 02 01:26:56 I guess maybe so. Mar 02 01:27:19 A bit painful, as I'm running Ubuntu under a VMware virtual machine. Mar 02 01:27:43 Chainging the partitions involves running gparted as a virtual machine, mounting the file system. Mar 02 01:28:10 Mar 02 01:28:21 kergoth - how's the new job? Mar 02 01:28:53 pretty good, still getting up to speed and all, not yet involved in the planning phases, so mostly churning out code, but its oe code, so that'll do Mar 02 01:29:07 how are things going with your work nowadays? Mar 02 01:29:41 I'm mildly frenic, trying to get a stable gPhoto2 running on omap. Mar 02 01:30:06 Trying the Gumstix the last several days. Getting USB io errors with the '33 kernel. Mar 02 01:30:29 ah :\ Mar 02 01:30:41 sakoman and koen have been helpful; but it's not working well. Mar 02 01:31:01 Had a version working sorta kinda almost on the Beagle, with Koen's "demo" image. Mar 02 01:31:17 But later kernels appear to problematic, with PTP io over USB Mar 02 01:39:19 khem: OK, eglibc changes make sense to me, added in a -pic package too Mar 02 01:39:28 Testing an update to glibc to add -pic to run past RP Mar 02 01:39:39 Then maybe i'll remember to kick a firefox build :) **** ENDING LOGGING AT Tue Mar 02 02:59:58 2010