**** BEGIN LOGGING AT Mon Mar 08 02:59:57 2010 Mar 08 06:12:23 03Holger Hans Peter Freyther  07org.openembedded.dev * red68667b91 10openembedded.git/ (7 files in 4 dirs): Mar 08 06:12:23 netatalk: Upgrade from 2.0.3 to 2.0.5 Mar 08 06:12:23 Addresses CVE-2008-5718. Mar 08 06:12:23 netatalk-2.0.3-db43.patch: Done differently. Mar 08 06:12:23 netatalk-2.0.3-xfs.patch: Drop as the config switch was not used Mar 08 06:12:24 netatalk-2.0.3-setXid.patch: Was not used. Mar 08 06:33:48 03Holger Hans Peter Freyther  07org.openembedded.dev * r4fb5a96bb2 10openembedded.git/recipes/net-snmp/ (net-snmp-5.4.2.1/CVE-2008-6123.patch net-snmp_5.4.2.1.bb): Mar 08 06:33:48 net-snmp-5.4.2.1: Addresses CVE-2008-6123. Mar 08 06:33:48 See http://bugs.gentoo.org/show_bug.cgi?id=250429 for more details. Mar 08 07:36:43 good morning Mar 08 07:39:54 hi Mar 08 07:58:10 03Frans Meulenbroeks  07org.openembedded.dev * r7004e43af6 10openembedded.git/recipes/lttng/lttng-control_0.12.bb: Mar 08 07:58:10 lttng-control: upgraded to 0.79 Mar 08 07:58:10 Signed-off-by: Frans Meulenbroeks Mar 08 08:01:23 03Martin Jansa  07org.openembedded.dev * r8eb15be652 10openembedded.git/recipes/tasks/task-shr-feed.bb: Mar 08 08:01:23 task-shr-feed: add evopedia Mar 08 08:01:23 Signed-off-by: Martin Jansa Mar 08 08:01:34 03Martin Jansa  07org.openembedded.dev * ra2193c4e95 10openembedded.git/recipes/freesmartphone/fsodatad_git.bb: Mar 08 08:01:34 fsodatad: move mobile-broadband-provider-info to RDEPENDS Mar 08 08:01:34 Signed-off-by: Martin Jansa Mar 08 08:09:03 is there an easy way to harvest all url's from all recipes with all the metadata (like PV) expanded ? Mar 08 08:09:31 eFfeM: what do you want to do? Mar 08 08:10:32 eventually check if all url's point to still-existing (http, ftp and maybe cvs/svn/git locations) Mar 08 08:10:45 the original one, not the angstrom mirror or so Mar 08 08:11:08 I've bumped into two last few days that didn't even exist any more Mar 08 08:11:36 one being the lttng one changed above (guess that was from a 2006 version that was gone a loooong time ago) Mar 08 08:13:36 and apparently also some of the gnu mirrors don't work any more Mar 08 08:16:46 OK Mar 08 08:16:58 that should be much less of an issue now since OE mirrors all sources Mar 08 08:17:23 hrw (or was it zecke) has written an URL checker script Mar 08 08:17:27 check contrib/ Mar 08 08:18:06 will do, actually the lttng thing was apparently not cached and I also had problems with findutils Mar 08 08:20:17 hi, I have a problem with gnu-config...do_patch fails with quilt usage message; what should be the problem? Mar 08 08:21:26 eFfeM: run contrib/source-checker/oe-source-mirror-build.py Mar 08 08:21:35 eFfeM: there are a few sources that were already vanished when I tried to mirror them Mar 08 08:21:45 hrw provided a few, I also had a few Mar 08 08:22:16 at this point in time I'm not putting any further effort into the old sources Mar 08 08:22:18 * hrw|gone will be back in ~2h Mar 08 08:22:24 bye Mar 08 08:22:26 guess if the sources were vanished, there should be a better/newer versions Mar 08 08:22:54 Laibsch: basically in my branch I'll eihter update or nuke them Mar 08 08:23:03 hrw|gone: cya later & thanks for the link Mar 08 08:23:56 some sources have completely disappeared Mar 08 08:24:16 then imho it is questionable to keep the recipe around Mar 08 08:24:26 with some effort they may of course be hunted down Mar 08 08:24:38 I did quite a bit of that effort Mar 08 08:25:17 I also did remove one or two recipes Mar 08 08:25:23 but as you know, that's very risky Mar 08 08:25:37 that's why i do it in my own branch Mar 08 08:26:19 I know Mar 08 08:26:25 good luck Mar 08 08:26:48 a few months ago I would have gladly joined your effort Mar 08 08:26:57 ty, didn't get to pushing it yesterday, actually 4 recipes did not yet build properly for console-image Mar 08 08:27:08 and maybe some users of them ofc Mar 08 08:27:26 still wondering why console-image would require things like gnome and x11 and so on Mar 08 08:27:36 "bitbake -g" Mar 08 08:27:58 i know Mar 08 08:29:31 Hello, I have a question about Compulab CM-X300...will be supported by OE? I noticed there is CM-X270 support...anyone have tried to use it with CM-X300? Mar 08 08:44:02 03Koen Kooi  07org.openembedded.dev * raf23fbe727 10openembedded.git/recipes/pidgin/pidgin_2.6.6.bb: pidgin: add 2.6.6 Mar 08 08:44:29 henomis: hi Mar 08 08:44:40 mckoan: hi Mar 08 08:47:14 actually the reason console-image drags in all those X stuff is because bluez4 depends on gst-plugins-base which drags in things like pango, gstreamer, gnome-vfs, cdparanoia etc etc Mar 08 08:47:29 henomis: looks like CM-X300 is not currently supported Mar 08 08:48:12 henomis: and of cource the CM-X270 kernel won't suit Mar 08 08:50:16 actually we have 10 recipes for bluez4 so maybe there is one without gst-plugins :-) Mar 08 08:52:03 mckoan: sure, the kernel is not the same...but using a CM-X300 kernel with all the remaining applications builded for CM-X270 target...it should works. Or not? Mar 08 08:52:29 hrw|gone: i'm not a python wiz but it seems the scripts in source-checker just compare the dl dir with checksums.ini Mar 08 08:52:44 i would like to fetch the original src Mar 08 08:59:44 henomis: you need only the proper kernel, userspace doesn't change Mar 08 09:01:04 mckoan: ok, tnx :) Mar 08 09:01:18 henomis: you're welcome :-D Mar 08 09:19:36 hrw|gone: ping me when you're back, I'm curious why you forced *.h installed to include/SDL in http://git.openembedded.org/cgit.cgi/openembedded/commit/?id=cdba23dc285142750361fa95360e8c67d8351c9e, newer SRCREVs are installing it include/smpeg, so if it's ok to let it there (with conversion to new staging) Mar 08 09:21:02 hi, I have a problem with gnu-config...do_patch fails with quilt usage message; any suggestion of what can I do to solve the problem? Mar 08 09:51:02 03Gregoire Gentil  07org.openembedded.dev * rc7fcc36b36 10openembedded.git/recipes/mplayer/ (files/yuv.S mplayer_svn.bb): Mar 08 09:51:02 mplayer: Upgrade yuv assembly conversion in vo_omapfb Mar 08 09:51:02 Signed-off-by: Koen Kooi Mar 08 09:52:57 hi, will there be a merge of the linux-kernel-base class into stable 2009? to support > 2.6.33 kernels in old stable? or is there a new stable/2010 branch to be created? Mar 08 09:58:46 JaMa|Wrk: feel free Mar 08 09:59:38 nik0n_: extract needed patches from .dev, adapt them for stable, send for review Mar 08 10:00:06 hrw|gone: maybe it will make this not needed anymore :) sdlperl/sdl-perl_1.20.3.bb: sed -i -e 's:#include :#include :g' SDL_perl.xs Mar 08 10:00:18 maybe Mar 08 10:00:21 bb in few Mar 08 10:01:16 good morning Mar 08 10:05:57 hi all Mar 08 10:06:19 How to enable PowerVr SGx on beagle angstrom demo image Mar 08 10:06:20 ?? Mar 08 10:07:45 morning Mar 08 10:09:49 eFfeM: ah... that script just checks DL_DIR and export list of good files... Mar 08 10:10:25 eFfeM: if you want to fetch check all then "bitbake -cfetchall world" can be used or extract links from checksums.ini Mar 08 10:20:15 hrw, will try that Mar 08 10:36:24 hrw tried it but world says there are unbuildable targets :-( 9ERROR: Required build target 'sugar-fructose' has no buildable providers. Mar 08 10:36:24 ) Mar 08 10:36:43 bitbake -k? Mar 08 10:39:21 03Koen Kooi  07org.openembedded.dev * r8c37bbf914 10openembedded.git/recipes/gstreamer/ (2 files in 2 dirs): gst-plugin-gles: update to current git Mar 08 10:55:10 03Leon Woestenberg  07org.openembedded.dev * rdc7f0c8bb2 10openembedded.git/recipes/squashfs-tools/ (squashfs-tools-4.0/Makefile.patch squashfs-tools_4.0.bb): Mar 08 10:55:10 squashfs-tools-4.0: Use LDFLAGS in Makefile. Mar 08 10:55:10 LDFLAGS was not used. Fixed that. Mar 08 10:55:10 The staged zlib was not picked up on a system that hadn't zlib-dev Mar 08 10:55:10 installed natively. Mar 08 10:55:11 Signed-off-by: Leon Woestenberg Mar 08 11:20:00 hi Mar 08 11:51:43 03Koen Kooi  07org.openembedded.dev * r4b674c46ac 10openembedded.git/recipes/gstreamer/ (gst-plugin-bc/gst-debug.diff gst-plugin-bc_git.bb): gst-plugin-bc: add git version Mar 08 11:51:43 03Koen Kooi  07org.openembedded.dev * r5663153404 10openembedded.git/recipes/gstreamer/ (gst-plugins-package.inc gst-plugins.inc): gst-plugins: seperate packaging from configuring .inc Mar 08 11:51:44 03Koen Kooi  07org.openembedded.dev * r5a21221562 10openembedded.git/recipes/gstreamer/gst-plugin-gles_git.bb: gst-plugin-gles: use proper gst-plugin packaging Mar 08 11:53:10 kergoth_, ping.. I get parse errors (with bb master, in case that matters) for e.g.: SRC_URI = "git://some.thing.tld/foo ${@['', '${FILE_FOO}'][bb.data.getVar('USE_NLS', d, 1) == 'yes']} " Mar 08 11:53:44 specifically: NOTE: :EOL while scanning string literal (, line 1) while evaluating: Mar 08 11:54:29 [snip];branch=master;protocol=git ${@['', '${FILE_FOO}'][bb.data.getVar('USE_NLS', d, 1) == 'yes']} file://foo.config [snip] Mar 08 11:55:01 kergoth_, am i doing something wrong or is that a buglet? Mar 08 12:02:33 eFfeM: any plans when to publish your branch with cleanups? Mar 08 12:02:59 hrw, i hope to be able to push it tonight Mar 08 12:03:06 * eFfeM keeps fingers crossed Mar 08 12:03:26 great Mar 08 12:04:01 the criterion for pushing is that it builds console-image and that that image runs the basic stuff on my board Mar 08 12:04:03 I have few changesets for gnutls 2.8+ build breaks. but they break everyone with 2.4.2 used Mar 08 12:05:40 basically yesterday evening I ended up having 4 non-building recipes (and maybe a few that depend on it) fontconfig dbus-glib and 2 which I forgot Mar 08 12:06:19 ~love Debian for gnutls patches Mar 08 12:06:20 If you love Debian for gnutls patches so much, why don't you marry it? (oooooh) Mar 08 12:06:24 ;D Mar 08 12:06:30 ibot: I am already taken Mar 08 12:06:31 it is my pleasure to meet you, already taken Mar 08 12:07:01 had to revert a few BBCLASSEXTEND="native" though where the obvious patches did not work Mar 08 12:07:19 i've reserved most of the evening for it Mar 08 12:07:55 it is only a first step though, lots of work needed as there is lots of crud around Mar 08 12:08:05 i feel i only touched the surface Mar 08 12:09:19 xorg-server-1.5.3 is support touch screen? Mar 08 12:09:34 if you use drivers for it then yes Mar 08 12:09:57 hej Mar 08 12:10:09 anyone seen strange linking errors recently ? Mar 08 12:10:40 just did a git pull, and rebuild a (private) recipe; undefined symbol: _ZNSs4_Rep20_S_empty_rep_storageE is the result ... Mar 08 12:19:37 Downloading http://www.angstrom-distribution.org/feeds/unstable/ipk/glibc/armv7a/debug/libpixman-1-dbg_0.17.8-r0.5_armv7a.ipk. Mar 08 12:19:38 wget: server returned error: HTTP/1.1 404 Not Found Mar 08 12:19:38 Collected errors: Mar 08 12:19:38 * opkg_download: Failed to download http://www.angstrom-distribution.org/feeds/unstable/ipk/glibc/armv7a/debug/libpixman-1-dbg_0.17.8-r0.5_armv7a.ipk, wget returned 1. Mar 08 12:19:38 * opkg_install_pkg: Failed to download libpixman-1-dbg. Perhaps you need to run 'opkg update'? Mar 08 12:19:49 Am getting this error while trying to build clutter Mar 08 12:20:09 did opkg update manytimes but still getting the same Mar 08 12:20:13 how to resolve this Mar 08 12:28:48 hmmm... it is sad that no one else bothers to remove remote code exploits. :( Mar 08 12:29:08 80x25 framebuffer on 24" lcd is too hardcore Mar 08 12:29:24 yes it is Mar 08 12:29:28 zecke: ? Mar 08 12:29:38 zecke: exploits are fun! Mar 08 12:29:40 :) Mar 08 12:29:58 hrw: I posted a list of affected packages and no one really bothers fixing it Mar 08 12:30:13 raster: well, new ones yes. Being exploitable by a three year old zlib bug is not funny. Mar 08 12:30:21 (i think our zlib is fine though) Mar 08 12:30:40 zecke: I got used to that Mar 08 12:30:55 hrw: used to what? Mar 08 12:31:15 having my mails ignored on OEML Mar 08 12:32:33 But it is not that hard. If you feel responsible for GNOME, you update gnome-screensaver. Mar 08 12:32:59 I know, but people are lazy Mar 08 12:33:25 yeah, maybe then we should support emdebian, instead of having a swiss cheese distro construction set Mar 08 12:33:33 I just fixed bunch of recipes which failed on new gnutls but pushing changes will break everyone who did not upgraded Mar 08 12:33:46 "Hey, you can create a distro with OE, but it will be owned fasta than Windows 95" Mar 08 12:34:03 kergoth_, drats, i forgot to declare FILE_FOO. Still, the EOL parse errors on an attempt to expand an undeclared variable is a bit misleading imho. Mar 08 12:35:21 03Holger Hans Peter Freyther  07org.openembedded.dev * rc28fa72a4c 10openembedded.git/ (4 files in 2 dirs): Mar 08 12:35:21 samba: Upgrade stable releases from 3.2.8 to latest 3.2.x release Mar 08 12:35:21 This is addressing: CVE-2009-1886, CVE-2009-1888, CVE-2009-2813 Mar 08 12:35:21 CVE-2009-2948 and CVE-2009-2906. Mar 08 12:35:26 03Holger Hans Peter Freyther  07org.openembedded.dev * rb0a786a159 10openembedded.git/recipes/samba/ (samba-ads-3.3.0/wbstatic.patch samba-ads_3.3.0.bb): Mar 08 12:35:26 samba-ads: Upgrade from 3.3.0 to 3.3.9 to benefit from various fixes Mar 08 12:35:26 There were certain but bugs that were fixed between 3.3.0 Mar 08 12:35:26 and 3.3.8, it makes sense to upgrade to this version. Mar 08 12:36:28 hrw: latest example is neon, luckily it is so old people will need to use their time machine to find the exploits Mar 08 12:36:50 neon... subversion used it - right? Mar 08 12:37:02 yes, and someothers Mar 08 12:43:58 hi, how to enable touch option in "xorg-server-1.5.3" Mar 08 12:44:19 our apr has two issues too Mar 08 12:46:12 zecke: gnome-screensaver is on my TODO, but gnome is a whole pile of pain Mar 08 12:46:39 XorA: the good thing is, it should be only a minor release Mar 08 13:10:18 wow I never even knew samba-essential existed :-) Mar 08 13:11:08 iirc it was minimal samba install Mar 08 13:12:50 and a sane smb.conf to get started Mar 08 13:13:00 * XorA has always just used the samba recipe Mar 08 13:45:56 samba-essential is intended for very small mem devices, i.e. the NSLU2 -- works wonderfully. :) Mar 08 13:46:23 mwester: i agree, I was hoping to find a DEPENDS on samba-essential in a task or image, but I didn't. Mar 08 13:48:06 mwester: I'm not denying the usefulnes of that app, I just think that 15 potential remotely exploitables issues in that smbd is bad. (and it is less than 15 as some bugs were in nmbd too.. which maybe isn't part of samba essential). :) Mar 08 13:53:58 hm we could add something like at the end of local.conf.sample to the exploitable recipes? 'Do not use this package until you want a remote hole' Mar 08 13:55:34 mwester: We could just patch base.bbclss. "You are building a Mickey Mouse Distribution with known remote exploits. Enjoy your trip to the Wonderland" :) Mar 08 13:56:10 lets call this Goofy or Donald Duck, otherwise people will think i'm crazy Mar 08 13:56:29 mwester: sorry. didn't mean to tab complete you Mar 08 14:00:05 03Holger Hans Peter Freyther  07org.openembedded.dev * rfc4226e83f 10openembedded.git/ (8 files in 3 dirs): Mar 08 14:00:05 git: Upgrade from 1.6.0.4 to 1.7.0.2 Mar 08 14:00:05 The git-daemon+(x)inetd has a known denial of service problem. Upgrade Mar 08 14:00:05 to a newer git version just in case. Remove two bogus autoconf patches Mar 08 14:00:05 that can be done by passing in autoconf varaibles. Switch to local Mar 08 14:00:05 checksums instead of checksums.ini Mar 08 14:00:18 http://www.vuxml.org/freebsd/index.html <- this is a very nice, one can pick a random version and fix it. We are likely shipping a bad version Mar 08 14:07:54 zecke: nice url Mar 08 14:09:30 siji: guess you need to run opkg update or angstrom need to update its pacakge index, the version in the feed is http://www.angstrom-distribution.org/feeds/unstable/ipk/glibc/armv7a/debug/libpixman-1-dbg_0.17.8-r6+gitr7a15fa25ddb88ebb4ac00772854271f102f06e81.5_armv7a.ipk Mar 08 14:10:06 could be that package index is out of date, in which case you need to bother koen i guess Mar 08 14:10:20 oh ok Mar 08 14:10:23 package-index is rebuilt every 8 hours or so Mar 08 14:10:39 so wht u will suggest Mar 08 14:10:53 what was original problem, I missed it Mar 08 14:10:56 shld i update the package index Mar 08 14:11:05 siji: do "opkg install http://www.angstrom-distribution.org/feeds/unstable/ipk/glibc/armv7a/debug/libpixman-1-dbg_0.17.8-r6+gitr7a15fa25ddb88ebb4ac00772854271f102f06e81.5_armv7a.ipk" Mar 08 14:11:12 Downloading http://www.angstrom-distribution.org/feeds/unstable/ipk/glibc/armv7a/debug/libpixman-1-dbg_0.17.8-r0.5_armv7a.ipk. Mar 08 14:11:18 siji: it will fetch and install Mar 08 14:11:25 wget: server returned error: HTTP/1.1 404 Not Found Mar 08 14:11:46 ok Mar 08 14:12:50 btw how to update the package index of angstrom? Mar 08 14:15:59 ssh login to angstrom account on server, cd to feed dir, run tool to update pakcage index. simple Mar 08 14:16:19 which is all dont by script so its unlikely its wrong Mar 08 14:16:23 done Mar 08 14:16:36 ok Mar 08 14:16:54 but still I dont see what the original issue was Mar 08 14:17:03 oh srry Mar 08 14:17:11 wil paste again Mar 08 14:17:13 * XorA is the one with Angstrom feed access :-) Mar 08 14:17:47 03Koen Kooi  07org.openembedded.dev * rd2fc55223a 10openembedded.git/recipes/gstreamer/gst-plugin-bc/gst-debug.diff: gst-plugin-bc: update patch to the version thats going upstream Mar 08 14:18:10 Downloading http://www.angstrom-distribution.org/feeds/unstable/ipk/glibc/armv7a/debug/libpixman-1-dbg_0.17.8-r0.5_armv7a.ipk. Mar 08 14:18:10 wget: server returned error: HTTP/1.1 404 Not Found Mar 08 14:18:10 Collected errors: Mar 08 14:18:10 * opkg_download: Failed to download http://www.angstrom-distribution.org/feeds/unstable/ipk/glibc/armv7a/debug/libpixman-1-dbg_0.17.8-r0.5_armv7a.ipk, wget returned 1. Mar 08 14:18:11 * opkg_install_pkg: Failed to download libpixman-1-dbg. Perhaps you need to run 'opkg update'? Mar 08 14:19:01 Now same error for libexpat Mar 08 14:20:04 looks like you need to run opkg update Mar 08 14:20:20 i did it manytimes Mar 08 14:20:25 but still getting the same error Mar 08 14:22:06 arse Angstrom feed is actually wrong :-( Mar 08 14:23:15 srry? Mar 08 14:23:52 Packages points to a different version than is in feed, maybe koen just did an upload and upadate-packages is still running Mar 08 14:24:08 siji: as a workaround you can browse http://www.angstrom-distribution.org/feeds/unstable/ipk/glibc/armv7a/debug/ then find the latest version and install that one, but it is a pain in the ass if you have multiple pacakges Mar 08 14:24:25 I was doing that Mar 08 14:24:41 but u are right hve to install lot of packages ;( Mar 08 14:26:22 Anyway I will try after some hrs Mar 08 14:26:32 let's try my luck Mar 08 14:26:59 bye for now Mar 08 14:27:07 Thanks alot for the support Mar 08 14:31:14 hrw: had bitbake -cfetchall -k world running for a few hours, python was still running at 100% Mar 08 14:44:30 crap ;( Mar 08 14:44:48 eFfeM: for recipe in recipes/*/*bb;do bitbake -cfetch -b $recipe;done Mar 08 14:46:40 * kergoth_ successfully did a bitbake -k -c fetchall world this weekend, though it took 30+ minutes to generate the runqueue alone Mar 08 14:48:11 heh Mar 08 14:55:49 hrw didn't think of that Mar 08 14:56:10 kergoth_: i think it was already a few hrs generating the runqueue Mar 08 14:56:13 hmm, BPN of gcc-cross-initial is gcc-cross, not gcc Mar 08 14:56:33 hrw the for works like a charm Mar 08 14:57:07 eFfeM: simplicity always wins? Mar 08 14:57:58 yeah Mar 08 14:58:33 9 changesets ahead of origin... Mar 08 14:59:46 kergoth_: but it still fetches only latest/preferred versions for world pacakges, doesn't it? Mar 08 14:59:47 will cleanup e2fsprogs + util-linux-ng tomorrow Mar 08 15:00:16 JaMa|Wrk: yeah, hrw's method is definitely superior in more ways than one, if you want to populate for a mirror Mar 08 15:00:17 JaMa|Wrk: if you really want to fetch everything then you need to process every recipe for each MACHINE/DISTRO combo Mar 08 15:00:26 and hrw's method fails for BBCLASSEXTENDS :) Mar 08 15:00:47 heh, well, we need to add a way to specify that for -b anyway Mar 08 15:01:18 yeah I agree, I miss -b everytime I need to debug some recipe with BBCLASSEXTEND Mar 08 15:02:00 libc_uclibc override is true for any abi - right? Mar 08 15:03:05 eFfeM: hrw Angstrom feed is now fixed so if that guy comes back it should work Mar 08 15:03:15 koen kindly found the issue Mar 08 15:03:20 bye Mar 08 15:06:52 XorA: if i see him i'll tell him, but i'll be heading home in 45 mins (but will be on tonight) Mar 08 15:20:19 how can i specify a branchname with a / for git? just writing the / there results in a phrase error Mar 08 15:20:52 what do you mean? Mar 08 15:21:03 :) Mar 08 15:21:14 branches can have slashes in them fine. i wouldn't suggest putting a *leading* slash, because it wouldn't make any sense, but otherwise.. Mar 08 15:21:16 I hase this SRC_URI: SRC_URI = "git://github.com/heinervdm/bluez.git;protocol=http;branch=felix/fso " Mar 08 15:21:24 ah Mar 08 15:21:29 what's the error you're getting? Mar 08 15:21:58 http://shr.pastebin.com/Lus2e1QS Mar 08 15:23:17 oh Mar 08 15:23:25 the error is somewhere else Mar 08 15:23:44 kergoth_: solved, thx :) Mar 08 15:24:02 heheh, np Mar 08 15:24:02 Heinervdm: no SRCREV defined? Mar 08 15:24:24 JaMa|Wrk: no, an additional \ at the end of SRC_URI Mar 08 15:35:22 hello: has someone experienced an illegal instruction when using -qws with qt4-embedded 4.6.2 ? Mar 08 16:05:42 Longfield: This sounds like Qt is compiled for a wrong architecture. Mar 08 16:24:37 03Martin Jansa  07org.openembedded.dev * r038f68a6b7 10openembedded.git/ (8 files in 2 dirs): Mar 08 16:24:37 shr: move etk-themes to obsolete, remove etk-theme-neo from RSUGGESTS Mar 08 16:24:37 Signed-off-by: Martin Jansa Mar 08 16:24:38 03Martin Jansa  07org.openembedded.dev * rd4d8d8ce57 10openembedded.git/recipes/freesmartphone/fsodatad_git.bb: fsodatad: missing PR bump Mar 08 16:24:39 03Martin Jansa  07org.openembedded.dev * r82380e0d0f 10openembedded.git/ (9 files in 2 dirs): Mar 08 16:24:39 shr: move some obsolete SHR apps to obsolete directory Mar 08 16:24:39 * with SRCREV moved from sane-srcrevs.inc to recipes Mar 08 16:24:39 Signed-off-by: Martin Jansa Mar 08 16:29:46 hi laibsch Mar 08 16:49:15 hi, I'd like to have xmms2 in oe, but it uses waf, should I override do_configure do_compile and do_install ? Mar 08 17:00:14 it seems that midori uses waf but in a different way Mar 08 17:06:46 mmm the waf command seem so close to configure Mar 08 17:06:57 * GNUtoo is tempted to do a hack Mar 08 17:10:08 03Otavio Salvador  07org.openembedded.dev * r96270fd7d3 10openembedded.git/recipes/hal/consolekit_0.3.0.bb: Mar 08 17:10:08 consolekit: add pam-plugin-ck-connector package Mar 08 17:10:08 Signed-off-by: Otavio Salvador Mar 08 17:10:09 03Otavio Salvador  07org.openembedded.dev * r7c6fbaac31 10openembedded.git/recipes/hal/consolekit_0.3.0.bb: Mar 08 17:10:09 consolekit: pam-plugin-ck-connector rdepends on consolekit Mar 08 17:10:09 Signed-off-by: Otavio Salvador Mar 08 17:45:19 woa, there is an OE channel, nice :-) Mar 08 17:45:52 jayson: were here already a while Mar 08 17:45:59 waiting for you since a year or 5 Mar 08 17:46:06 eFfeM1: lol Mar 08 17:46:10 welcome ! Mar 08 17:46:28 well, playing with using OE on the nslu2, and on a sheevaplug, figured I would see if there's a channel around as well Mar 08 17:47:24 guys, i tried to change unzip to use BBCLASSEXTEND="native" thought it would be no biggie as native does not seem to do somethign special, yet the build fails with http://tinderbox.openembedded.net/builds/63715/ Mar 08 17:47:30 anyone an idea how to fix this Mar 08 17:47:32 only 1 question so far..how much diskspace is needed to git OE/bitbake and do a compile? wondering if this 80GB external drive is going to be enough (google: required disk space for open embedded, doesn't help) Mar 08 17:47:55 jayson: nslu2, that's quite old, you could have come 5 years ago :-) Mar 08 17:48:21 03Koen Kooi  07org.openembedded.dev * re518bd5129 10openembedded.git/recipes/powervr-drivers/ (libgles-omap3/rc.pvr libgles-omap3_3.01.00.02.bb): libgles-omap3: autoload bufferclass_ti driver at boot Mar 08 17:48:21 if this 80 GB is empty i don't think you'll run into space problems Mar 08 17:48:26 depends also what you want to build Mar 08 17:48:31 03Koen Kooi  07org.openembedded.dev * re5dcf0d4e4 10openembedded.git/recipes/gtk-webcore/midori_0.2.4.bb: midori: add 0.2.4 Mar 08 17:48:52 i have an 80 gb /home and build lots of things Mar 08 17:49:01 eFfeM1: I know ;-) I just have one laying around in an old box @ home..figured I would slap up a generic image on it..just going to use it to rsync backups Mar 08 17:49:26 I'm coming from the buildroot world, so this is alittle new to me Mar 08 17:57:34 jayson: I have 8GB in use on my build box Mar 08 17:57:52 that includes the ubuntu install Mar 08 17:58:12 and a few linux source tarballs and trees Mar 08 17:59:47 Romke: awesome, thanks for you input. I'm firing up a debian install as we speak Mar 08 18:02:49 yeah, i built angstrom in that box Mar 08 18:02:59 so it also includes downloads of all things Mar 08 18:13:28 my downloads dir alone is 10 G so 8G seems to be quite small Mar 08 18:13:39 zecke: have you seen any packaging probs since you bumped git-native? Noticed it's failing in pop_staging for me http://tinderbox.openembedded.org/packages/511088/ but I am off out so can't look right now. Mar 08 18:18:20 kergoth_, let me ping you on the s/!= None// bitbake cosmetic patchlet (same for /is not None/ btw..) Mar 08 18:18:31 gah, thanks, was busy this weekend Mar 08 18:23:57 kergoth_, find ./ -name "*.py" -exec sed -i -e "s/[[:space:]]*\!=[[:space:]]*None:/:/g" -e "s/[[:space:]]*is not None//g" {} + Mar 08 18:24:27 kergoth_, seems to work fine for me. Many thanks in advance && cheers Mar 08 18:48:23 any BBCLASSEXTEND wiz around? I seem to have a problem converting unzip Mar 08 18:52:16 blindvt: applying that blindly results in a failed build, will have to do more research to find the spots where it truly does check for None (vs, say, empty list or empty string, which also evaluate as false, iirc) Mar 08 19:00:45 what is the meaning of NATIVE_INSTALL_WORKS ? Mar 08 19:08:36 eFfeM1: afaik its just a way to force non-legacy staging, but specifically in mind is native recipes, becuase currently native.bbclass provides a do_stage, so would normally result in legacy Mar 08 19:17:14 hi mickeyl Mar 08 19:17:31 * pb__ stabs pxelinux Mar 08 19:17:45 evening pb__ , how are things? Mar 08 19:17:57 spent half the day trying to figure out why my kernel won't boot, only to discover that if you name it with a ".bin" extension then it gets treated differently. doh. Mar 08 19:18:05 ugh Mar 08 19:18:24 mickeyl: pretty good. still waiting for the lawyers to do their thing with our house purchase, which is frustrating. Mar 08 19:18:46 office move all going ahead though, the builders finished knocking down the walls today. Mar 08 19:19:27 will you lose some productivity during the move or is it going to be fairly streamlined? Mar 08 19:19:33 [office, taht is] Mar 08 19:19:49 I think we'll probably have about a day of downtime. Mar 08 19:20:27 split across two calendar days: we'll lose a monday afternoon while everybody puts their stuff in crates, and a tuesday morning while we unpack and set up at the new building. Mar 08 19:20:40 should hopefully be back up and running (mostly) on tuesday afternoon Mar 08 19:21:17 although, as of today, we still don't actually have any telecoms in the new office which is not ideal Mar 08 19:22:00 right Mar 08 19:22:07 but loosing a day or two is fairly well Mar 08 19:22:32 when university moved to a new place there was a couple of months "downtime" ;) Mar 08 19:22:37 heh Mar 08 19:26:15 gm Mar 08 19:30:20 eh, what crazy stuff is going on with INC_PR in binutils_2.20.bb? Mar 08 19:34:42 re Mar 08 19:35:28 khem, can you please check if you trip bugs.uclibc.org/1033 (gcc.gnu.org/PR32219 and the ld bug mentioned in there) on arm too (anything !i386 and !bfin where the former's broken and the latter obviously ok)? hidden weak handling in PIC/PIE thing. Just curious.. Mar 08 19:36:52 hi likewise Mar 08 19:37:16 kergoth_: ah thanks, I would expect BBCLASSEXTEND itself to take care of those things Mar 08 19:37:26 but guess it will solve my problem Mar 08 19:41:09 eFfeM1: not sure what you mean. new style vs old style staging is independent of BBCLASSEXTEND vs separate recipes. Mar 08 19:41:50 ah ok, yeah mixing things up, sry Mar 08 19:42:19 np, its confusing, lots of stuff going on :) Mar 08 19:42:58 well i have a problem with unzip, i'm trying to get it to use BBCLASSEXTEND, the recipe for native is very small and does nothing spectactular but still a version of unzip with BBCLASSEXTEND="native" gives linker errors http://tinderbox.openembedded.net/builds/63808/ Mar 08 19:43:03 could use expert advise here Mar 08 19:49:17 is there a difference in handling between inherit native folled by require unzip_${PV}.bb and BBCLASSEXTEND="native" in the nonnative recipe ? Mar 08 19:49:47 well, remember that inherit and require are *immediate* operations Mar 08 19:50:04 if the inherit is before the require, then the unzip recipe can override the bits in the native class, rather than vice versa Mar 08 19:50:31 whereas bbclassextend=native is like adding inherit native to the end of the recipe Mar 08 19:50:35 ah ok, didn't know what, guess BBCLASSEXTEND puts native after it Mar 08 19:50:36 its after the regular parse Mar 08 19:50:37 right Mar 08 19:50:43 ah ok Mar 08 19:50:50 understood Mar 08 19:50:50 so check the recipe and native.bbclass, see whose overriding what :) Mar 08 19:51:30 guess it is this: export LD = "${CC} ${LDFLAGS}" Mar 08 19:51:37 in the nonnative recipe Mar 08 19:53:08 might want to do something like EXTRA_OEMAKE += "'LD=${CC} ${LDFLAGS}'" instead, perhaps? Mar 08 19:53:21 * kergoth_ shrugs Mar 08 19:53:39 the recipe is fairly simple: http://cgit.openembedded.org/cgit.cgi/openembedded/tree/recipes/unzip/unzip_552.bb Mar 08 19:53:57 kergoth_: will try that, some variables are still mystery to me Mar 08 19:54:41 well, you can link with ld directly, but its not usually the best way to do, and our ldflags is intended to be passed to gcc as the linker rather than ld (gcc calls ld under the hood) Mar 08 19:55:08 I guess that LD change was their way of forcing the matter to ensure that it obeyed our LDFLAGS,a nd hence got the gnuhash, etc Mar 08 19:56:30 Unless there is a highly compelling reason to link with LD, its almost always wrong to do so. gcc is smarter then the average developer. ;) Mar 08 19:56:39 s/LD/ld/ Mar 08 19:57:27 yeah Mar 08 19:57:28 kergoth_: guess you are right the recipe is from before the pacakges -> recipes rename and after that someone added the LDFLAGS as GNU_HASH fix Mar 08 19:57:45 In a good way too, unlike libtool. Mar 08 19:58:50 kergoth_: with the EXTRA_OEMAKE it builds, ReaperOfSouls will try without the flag at all Mar 08 19:58:52 heh, that's what i was just thinking. rule of thumb: trust gcc, distrust libtool, distrust hand-written makefiles Mar 08 19:59:24 eFfeM1: eh, no, he didn't say to remove it. he said you should link with gcc instead of ld, which is what that export LD / EXTRA_OEMAKE does Mar 08 19:59:46 * eFfeM1 also dislikes everything that starts with auto* as it generally generates uncomprehensible makefiles Mar 08 19:59:54 kergoth_: ah ok, didn't understand Mar 08 20:00:02 auto* is consistent from OE's perspective. we know how to handle it Mar 08 20:00:08 eFfeM1: Yeah sorry my LD was supposed to be ld the utility not the env varible. Mar 08 20:00:23 no Mar 08 20:00:23 with a custom makefile based system, its comprehensible, but you *have to* read it to make a recipe for it, as you don't know what to expect Mar 08 20:00:25 np Mar 08 20:00:34 * kergoth_ goes back to fighting bitbake Mar 08 20:00:36 lots of interesting linker errors w/o it. Mar 08 20:03:05 i think i can convert some more recipes now Mar 08 20:03:12 kergoth_: what's happening with your packaged staging revamp at the moment? Mar 08 20:03:27 but first fix a cups cross compile badness Mar 08 20:14:37 03Phil Blundell  07org.openembedded.dev * r2d66520cb9 10openembedded.git/recipes/binutils/ (10 files in 2 dirs): binutils: add 2.20.1 Mar 08 20:15:30 pb__: Hey, if I went an added FILESPATHPKG .= gcc-$PV and nuked some duplicate files in your branch, would that be OK? Mar 08 20:15:35 pb__: Or want me to email you first? Mar 08 20:15:41 Tartarus: yeah, that'd be awesome, just go ahead Mar 08 20:16:12 k Mar 08 20:25:46 Although honestly, they're unrelated I think, heh Mar 08 20:28:30 03Martin Jansa  07org.openembedded.dev * rd0697d0c8a 10openembedded.git/ (3 files in 2 dirs): Mar 08 20:28:30 fso: bump SRCREV for libgsm0710, fso-abyss, frameworkd (redesigned opimd database) Mar 08 20:28:30 Signed-off-by: Martin Jansa Mar 08 20:32:28 pb__: I almost think we need a files-${GCC MAJOR}.${GCC MINOR} set of dirs Mar 08 20:33:13 I started poking the gcc 4.3.x duplicates a bit Mar 08 20:33:20 And setting aside all of those unused patches Mar 08 20:33:40 files/ is gonna get quite croweded even with say debian-4.3.x and fedora-4.3.x Mar 08 20:36:02 There's only a small number of identical over large ranges of gcc files Mar 08 20:38:43 03Koen Kooi  07org.openembedded.dev * rc7fea4b156 10openembedded.git/recipes/tasks/angstrom-task-gnome.bb: angstrom-task-gnome: add pam ck connector Mar 08 20:41:42 how can i set PREFERRED_VERSION_gcc* = "4.4.3" at once? Or do i have to explicitly spell out gcc gcc-cross gcc-cross-initial gcc-cross-intermediate gcc-cross-sdk ? Mar 08 20:42:34 03Martin Jansa  07org.openembedded.dev * r509dbd7d97 10openembedded.git/recipes/freesmartphone/frameworkd_git.bb: frameworkd: missing quot in postinst :/ Mar 08 20:42:35 03Martin Jansa  07org.openembedded.dev * r8c12755bcf 10openembedded.git/recipes/tasks/task-shr.bb: Mar 08 20:42:35 task-shr: replace default browser midori with ventura Mar 08 20:42:35 Signed-off-by: Martin Jansa Mar 08 20:43:27 blindvt: the latter Mar 08 20:43:36 ugh Mar 08 20:43:45 mickeyl, thanks nonetheless Mar 08 20:43:47 although depending on what you want to build, you probably don't need all Mar 08 20:43:53 and some distros make it more simple Mar 08 20:43:59 e.g. in minimal you just need to set it once Mar 08 20:45:06 ahem. is it just me or does anyone else thing that's a bit awkward? Mar 08 20:45:34 think even Mar 08 20:47:28 i think that's just you Mar 08 20:48:02 don't assume that you always want to build the same gcc version Mar 08 20:48:27 you might want to build another one for the sdk than the one for cross Mar 08 20:49:19 Er Mar 08 20:49:27 If you use sane-toolchain.inc Mar 08 20:49:34 There's PREFERRED_VERSION_GCC or so Mar 08 20:49:35 i mean it would be pretty broken to use initial=3.4.6 and rest=whatever but might be needed for if you were about to bootstrap a current distro on a libc.4 box but of course legitimate. But isn't the normal use-case that you should be able to do a shortcut and just say binutils=0.8.15 gcc=47.11 and just use those for cross- and target compilers Mar 08 20:49:38 which will set all of the sub ones out Mar 08 20:49:52 (angstrom has a similar mechanism) Mar 08 20:50:18 And distros not using sane-toolchain.inc really run the risk of other stuff being busted if they aren't careful (ie missing libc-LIBC overrides) Mar 08 20:51:02 mickeyl, not always, but as a convenient shortcut i as a user would find it handy, fwiw Mar 08 20:51:48 blindvt: true, that's why i added sane-toolchain.inc some months ago Mar 08 20:51:49 There's a knob for binutils version too :) Mar 08 20:52:33 heh Mar 08 20:52:41 Tartarus, i'll look at that sanity, thanks for the hint (i'm playing with micro since it sounds like the thing that i'd vaguely would want to end up with) Mar 08 20:53:54 micro uses sane-toolchain, iirc :) Mar 08 20:53:59 * Tartarus looks at mickeyl Mar 08 20:54:35 mickeyl, nod, i'll have a look. Well thanks a bunch for adding it in advance :) Mar 08 20:55:27 :) Mar 08 20:55:41 mickeyl, could very well be that just the dummy local.conf in there lacks a hint (and thus /me a clue) and all is jazz Mar 08 20:55:54 well Mar 08 20:56:02 dummy is really rather a build configuration Mar 08 20:56:10 toolchain selection is usually a distro type configuration Mar 08 20:56:22 s/dummy/local/ Mar 08 20:59:15 mickeyl, could be. /me as a dummy user just look at conf.sample and base off that. Since the sample just talks about e.g. qte stuff and doesn't list a sample catch-all pattern, it's a(nother) hurdle fyi Mar 08 21:01:42 mickeyl: Personally, I'm with blindvt on this one. We should have LIBC, PREF GCC/BINUTILS versions stuff in local.conf.sample, commented out Mar 08 21:01:56 and nuke the micro-uclibc / minimal-uclibc distros Mar 08 21:03:12 we can't nuke those distros until we have regained sane default settings Mar 08 21:03:44 oh, and it would be pretty cool if there was some ready to use x86_64 machine or a documented way (that even _i_ could find easily) to pick random standard qemu targets, like an i486-mmu-fpu, armel-nofpu-mmu, mipsel-softfp-nommu, bfin-elf2flt, ppc405-softfp-mmu, coldfire-nommu, m68k-softfp-nommu, arm-926t-mmu etc. Just a suggestion, bit i will need them for testing anyway Mar 08 21:04:25 Tartarus: yeah, I think it would make sense to have both gcc-MAJOR and gcc-MAJOR.MINOR in FILESPATHPKG. Mar 08 21:04:53 Tartarus, well, all i'm personally interrested in is micro-uclibc, better wipe the glibc ones for we have uClibc or eglibc/you-name-it for the rest ;P Mar 08 21:05:20 blindvt: You misunderstand, I think Mar 08 21:05:33 DISTRO=micro-uclibc == LIBC=uclibc DISTRO=micro Mar 08 21:05:35 Tartarus: apropos LIBC, I disagree that this should be a user-twiddleable knob. I think that is a mistake. Mar 08 21:05:44 Tartarus, oh, you mean let user decide on LIBC-flavour, right? Sorry then Mar 08 21:06:14 I do happen to think that, in the specific case of micro, we should probably just support uClibc and ditch the eglibc variant (and minimal would probably make the opposite choice, though mickey can speak to that) Mar 08 21:06:16 pb__: Difference between end-user users and distro-developer users I guess Mar 08 21:06:48 pb__: sounds good to me Mar 08 21:06:51 'tho even then, some end'ish users need one or the other Mar 08 21:06:53 too many variants Mar 08 21:06:56 less variants = good Mar 08 21:07:01 But, if you allow end users to select between two different and binary-incompatible C libraries then you have, effectively, created two different DISROs since they are not interoperable anymore. Mar 08 21:07:03 the older i get the more i appreciate Mar 08 21:07:06 fewer choices Mar 08 21:07:40 pb__: An issue for feed based distros and somewhat an issue for sanity checking Mar 08 21:07:53 (or at least making sure LIBC is in the right paths Mar 08 21:08:17 Tartarus, IDontCare if the user can choose lib variant and whatnot. I want to pick toolchain with one line (PREFERRED_HECK_EVERYTHING_{GCC,BINUTILS} = tip or last release or the single one version the user gives) Mar 08 21:08:47 blindvt: A valid use case for some, I agree. I've been there :) Mar 08 21:09:12 You can for the most part do that know, it's just not a tweak listed in local.conf.sample Mar 08 21:09:31 Tartarus: it's more than that: if you give the user the choice, you are implicitly promising them that either choice will work. from the point of view of micro, I don't especially want to put any effort into testing or fixing builds with glibc, since I think this is a waste of time: by definition, micro is supposed to be a small footprint DISTRO, and you just won't get that with glibc. likewise, I suspect that mickey would consider time spent Mar 08 21:09:31 fixing minimal for uclibc (e.g. quirky NLS and what have you) to be time wasted. Mar 08 21:09:53 but yes, the problem is most acute for feed-based distros. Mar 08 21:10:03 and i (and keep expanding them) want DISTRO_FEATURES to decide upon ipv4, ipv6, NLS, LFS, WCHAR, {RPC, NFS}, and if NLS then PICK_me_LANGs etc. Mar 08 21:10:27 blindvt: Yes, that would be nice too :) Mar 08 21:10:55 blindvt: I'm not sure I agree about NFS; I can't think of many/any situations where that needs to be a compile time choice. And I don't necessarily agree about LANGs either, but everything else in your list sounds good. Mar 08 21:11:00 pb__: True enough, but there shouldn't be distro specific bugs to either I think Mar 08 21:11:14 same for SSP and THREAD. You folks hardcode ssp to no but we'll fix that Mar 08 21:11:22 pb__: If there's a well supported uclibc distro and a well supported *glibc distro, both should work in either case Mar 08 21:11:28 but yeah, I see what you mean too Mar 08 21:11:40 Tartarus: right, but not necessarily with the same (versions of) packages. Mar 08 21:11:43 pb__: Re NFS, it's not so much a compile knob but an image creation knob Mar 08 21:12:10 Tartarus: you're right that clearly there will be a permutation that works for uclibc, and a permutation that works for glibc, but I am not sure that they will always be the same. Mar 08 21:12:16 pb__, NFS implies RPC and thus an RPC PREFERRED_PROVIDER (depending on libc ability) Mar 08 21:13:01 pb__: I'm also in the camp that there shouldn't be that many permutations of versions, in .dev anyhow.. But anyow, it is an ideal vs real world issue Mar 08 21:13:09 ideally, it should just work Mar 08 21:13:17 I know from experiance myself even that it doesn't quite Mar 08 21:13:26 And keep pushing fixes when I find problems :) Mar 08 21:14:36 hm get a cross compile badness in gnome-vfs (subdir neon), anyone any clue how to fix this? Mar 08 21:14:49 the top level makefile already includes /usr/include Mar 08 21:18:18 pb__, and i'm simply not willing (since i straight out don't have the resources nor inclination) to support pregenerated locales. So the UCLIBC_LOCALE_FILE is gone and will never ever return, i simply cannot prebuild each abi/endianess/bitness variant, even if oe and qemu would work out of the box for my needs. If you want fo_BA.utf8 locale, install it on your glibc buildhost and tell me that we have to generate data for it. If you want the minimum, then install Mar 08 21:18:18 some en_FOO.* locales and pick MINIMAL_LOCALE. No way out, so you/we _have_ to give educated folks a chance to select if they want None, MINIMAL, ALL_BUILDHOST-INSTALLED Mar 08 21:20:47 pb__, likewise for rpc. uClibc does have an rpc impl but we definitely will only provide it for setups that desperately don't want to upgrade to an actively maintained impl. Ours works and is pretty ok, but there are superior impls that we will migrate to (externally) in the next years for sure Mar 08 21:21:49 blindvt: I'm not sure I understand what you're saying about the locales. Mar 08 21:22:12 pb__, see UCLIBC_LOCALE_URI in there Mar 08 21:22:22 blindvt: for rpc, I think I do understand what you are saying but I am still not clear that this means it ought to be a DISTRO_FEATURE. That sounds more like it is just a distro choice of how to configure uClibc. Mar 08 21:24:49 blindvt: so, are you saying that uclibc now leans on the locales available on the build host in order to generate its own locale files? Mar 08 21:25:33 I've never really used i18n under uclibc so I am not very familiar with the way it works. Mar 08 21:27:25 pb__, it's bit- and endian dependant. The ancient version that you (and several others) use simply don't work for all (see helptext of 0.9.30.2 or master). We can easily generate the desired locale data out of the build-host (i.e. all that are installed on the buildhost, i.e. up to the user which locales she wants to support) or a minimal list: see MINIMAL in http://git.uclibc.org/uClibc/tree/extra/locale/Makefile.in and the block below http://git.uclibc.org/uCli Mar 08 21:27:25 bc/tree/extra/Configs/Config.in#n1352 Mar 08 21:28:16 blindvt: I'm not quite sure what your references to "you" mean, there. as far as I know, I have never personally used that file for anything. Mar 08 21:28:37 pb__, landley promised to provide pregenerated locale data about 2 years ago with nada outcome. I'm not going to provide them, so if noone does, you can have at most those that you have on your buildhost. That simple Mar 08 21:29:03 okay, fair enough. in that case, that isn't a DISTRO_FEATURE, it is a build host feature. Mar 08 21:29:58 and, practically speaking, since most distros don't control what is installed on the corresponding build hosts, that probably means that uclibc-based distros are going to have to build with NLS effectively disabled. That probably isn't all that big a deal since I suspect most folks are doing basically that already. Mar 08 21:30:18 pb__, there are people out there that want to support several dozend of locales in their images. These people simply have to install the locales they want on their build-host and (somehow) tell oe to UCLIBC_BUILD_ALL_LOCALE Mar 08 21:32:05 Which of course is very host specific :( Mar 08 21:32:16 Problem for feed distros, less so others Mar 08 21:33:07 pb__, sane folks will have locale off anyway, so it's basically a non-issue for oe. Still there should be a documented knob that you have installed de, us, fr but want oe to only support us, fr for example (thus i was assuming the LANGS="us fr" were a distro-specific thing) Mar 08 21:33:07 blindvt: right, yeah, I understand now. but, as I say, this is now beyond the scope of DISTRO configuration and into user-specific configuration hackery. Mar 08 21:34:02 I'm not convinced that adding a specific configuration knob to suppress locales that are installed on the host is a worthwhile thing. I wouldn't be massively opposed to it, but absent any real user demand I am not keen to rush off and do it either. Mar 08 21:35:23 pb__, rpc can just be virtualized, i guess. NLS is currently hardcoded in an inappropriate place. ssp is inappropriately hardcoded to no. ipv4 vs. ipv6 vs. just socket is not expressed at all, AFAICS Mar 08 21:37:12 pb__, fiddling much with nls is most likely not worth the hazzle for a start, agree Mar 08 21:37:17 yeah, I would be happy to see NLS, ipv4 and ipv6 added to DISTRO_FEATURES if they are not there already. I am not sure I know what ssp is. Mar 08 21:39:39 03Martin Jansa  07org.openembedded.dev * r68ed1f674f 10openembedded.git/conf/distro/include/sane-srcrevs-fso.inc: frameworkd: bump SRCREV a bit more Mar 08 21:42:25 stack smashing protector Mar 08 21:42:27 ~ssp Mar 08 21:42:28 well, ssp is a shared resource with other machines as are the GPIO lines, so separating them out makes integration clearer, the big single file is easiest for initial development tho' Mar 08 21:43:12 well that too Mar 08 21:43:17 heh Mar 08 21:43:41 ibot, ssp is also a stack smashing protector Mar 08 21:43:42 pb__: okay Mar 08 21:45:05 pb__, might i humbly ask you about an opinion wrt http://patchwork.openembedded.org/patch/1625/ ? Mar 08 21:46:09 ah, yes. that looks fine to me. Mar 08 21:46:23 pb__, the 'SRC_URI[{sha256,md5}sum] = 0xdeef' shortcut? Mar 08 21:46:27 yeah Mar 08 21:46:36 nobody seems to have objected so I guess I will go ahead and check it in Mar 08 21:51:16 woglinde, didn't you have a USE_NLS cleanup thing somewhere? thought so.. Mar 08 21:53:08 wrt USE_NLS please remember libc-uclibc override :) Mar 08 21:54:06 not that i'd have write-access yet, but is there some public branch that gets periodically blamed by a buildbot where mob could feed their changes for verification? Mar 08 21:54:28 Tartarus, be assured that that will be about the only thing that i'll actually test ;) Mar 08 21:55:03 blindvt: Heh, I mean vs the linux-uclibc test Mar 08 21:55:20 There's now an OE override that's on for all uclibc stuff, via conf/distro/include/uclibc.inc Mar 08 21:56:08 yeah, I'm sort of in two minds about that. I kind of feel that people should be checking TARGET_OS rather than using a new override. Mar 08 21:56:19 by now i've accumulated some good (as they tested fine for me) and other bumps and virtualizations that i'd love to have tested.. anything like that? Mar 08 21:56:42 pb__: But then you git bit by the 3 TARGET_OSes you need to check Mar 08 21:56:51 hence the lets add in one override that's set right Mar 08 21:57:13 I suppose we could try and always add the override, based on TARGET_OS in bitbake.conf or something... Mar 08 21:57:38 pb__, what's an override? something i should rather do than http://paste.debian.net/63256/ ? Mar 08 21:57:39 But the "oh we fixed uclibc but didn't try gnuspe+uclibc or not-arm+uclibc" bugs suck Mar 08 21:57:48 yeah, that might be better. I would be happy enough with the extra override if the two things are tightly coupled together. Mar 08 21:58:19 you're right that the "forgot uclibceabi" case does suck, but of course this is exactly the same issue that upstream configure.in scripts are going to have. Mar 08 21:58:28 pb__: I'm still not convinced that a distro without {eglibc,glibc,uclibc}.inc being pulled in is valid, or at least not something that needs to be taking special care, on the distro maintainers side Mar 08 22:00:11 03Bernhard Reutner-Fischer  07org.openembedded.dev * rf83598d515 10openembedded.git/ (2 files in 2 dirs): base.bbclass: provide shortcut syntax for first anonymous entry in SRC_URI Mar 08 22:01:16 Tartarus, imho any such distro should default to glibc. If you don't ask/demand you get the thing that everybody seems to pick. But then debian testing seems to have gone eglibc by now.. -- including assorted gettext breakage that will impose unto oe ;) Mar 08 22:02:11 what do i need to do to publicize my branch ? Mar 08 22:02:23 Tartarus: well, yeah, maybe. it isn't as if uclibc.inc contains any very high technology: apart from the OVERRIDES thing in question it consists of two weak assignments, one piece of avr32 bogosity, and three preferred providers for uclibc itself. Mar 08 22:02:44 eFfeM1: that's up to your own ingenuity. google adwords? local newspaper? Mar 08 22:03:15 * blindvt goes to ask google what an override in oe is & Mar 08 22:03:25 pb, an oe branch; i've made a local branch which is good enough to make public and want to push it Mar 08 22:04:02 eFfeM: there are no special rules for that. if you want to push it, and it has a sensible name, you can go ahead and do so. Mar 08 22:04:06 pb__: Right. All of the libc.inc's are intended to weak assign the virtuals to the libc and add libc-FOO override Mar 08 22:04:16 eFfeM: if you want to merge it into .dev, the normal rules would apply Mar 08 22:04:41 pb_ it tells me that it does not appear to be a repository, guess it needs to be created remotely Mar 08 22:05:22 eFfeM: I think you are using the wrong syntax. Mar 08 22:05:34 git push branchname Mar 08 22:05:34 eFfeM1: git push origin my-local-branch:me/sensible-branch-name Mar 08 22:05:43 on the same note, how would i (be allowed to) have a private branch in the oe repo? *FAQ ? Mar 08 22:05:48 Tartarus: thanks Mar 08 22:05:51 Will create me/sensible-branch-name upstream Mar 08 22:06:49 blindvt: if you have write access to the oe repo, it is as easy as using the git command that tartarus just mentioned. if you don't have write access, ask the admins to give you that access and then see above :-} Mar 08 22:06:53 eFfeM1: there is even short page in wiki about WIP branches.. Mar 08 22:07:22 Tartarus, i don't have any .ssh key stored on any oe box ATM, i.e. no write access. Should i go somewhere else, provide my own repo somewhere for the curious? Mar 08 22:07:23 eFfeM1: http://wiki.openembedded.net/index.php/GitPhraseBook#Create_your_own_short_lived_feature_branch Mar 08 22:08:03 blindvt: that would be fine too. I think kergoth keeps his special bits on github or some such place. Mar 08 22:09:16 ok i think i get it, jama thanks for the link pb_, Tartarus, JaMa thanks for the info Mar 08 22:10:27 pb__, k. then i'll try github for the osuosl folks are usually not really delighted if i store repos worth several 100 MB on their boxes Mar 08 22:12:46 does anybody knows what the space limit on the gitorious? On github it's 300MB Mar 08 22:12:58 hmm, get message about merging remote changes Mar 08 22:16:01 03Florian Boor  07org.openembedded.dev * r4d3121cbcc 10openembedded.git/recipes/linux/linux_2.6.32.bb: Mar 08 22:16:01 linux: Do not put the simone kernel image into package. Mar 08 22:16:01 The default bootloader configuration expects the kernel in a separate partition. We save quite some precious flash removing the kernel from the filesystem. Mar 08 22:16:49 this is what I get: http://www.pastebin.ca/1829171 Mar 08 22:21:23 I think you misunderstood Tartarus's suggestion. What is your local branch actually called, and what do you want to call it in the upstream repo? Mar 08 22:21:30 can't I just update my branch and merge later ? Mar 08 22:22:07 the local branch is called sanity, remotely i'd like to call it either sanity or if people prefer so eFfeM/sanity Mar 08 22:23:19 oh f***, thougth the my-local-branch was part of the command Mar 08 22:23:22 so, git push origin sanity:effem/sanity Mar 08 22:23:45 03Chris Larson  07org.openembedded.dev * rc77f216ab2 10openembedded.git/classes/package_ipk.bbclass: Mar 08 22:23:45 package_ipk: ensure pkgdest/root dirs exist before the lockfile/chdir Mar 08 22:23:45 Signed-off-by: Chris Larson Mar 08 22:23:53 should i use the effem prefix if I also want others to work on this branch Mar 08 22:24:10 aim is to clean up some things and have a testing branch for that Mar 08 22:25:08 yes, probably. Mar 08 22:25:25 if you wanted to lose the effem prefix then I think you would need to think of a more descriptive name than "sanity" Mar 08 22:26:00 ok, will add effem to it, we can rename if needed Mar 08 22:26:14 thanks alot, push is on its way Mar 08 22:27:01 shared/ Mar 08 22:27:24 right, but "shared/sanity" is a hopelessly vague name Mar 08 22:27:30 That's what someone mentioned after i pushed things to pb/toolchain-desuck :) Mar 08 22:27:36 Yeah, that's also true Mar 08 22:27:57 i've just pushed under eFfeM/sanity Mar 08 22:28:04 bedtime now, cya all later & hve fun Mar 08 22:30:01 good evening, i'm having troubles while compiling a kernel because the task menuconfig depends on gnome-terminal.. you dont happen to know how to change it into xchat or ncurses? (i cant find the task in the bb file...) Mar 08 22:30:18 xchat? that'd be an eleet choice for a terminal Mar 08 22:30:25 :-D Mar 08 22:30:28 xterm, sry Mar 08 22:30:34 I think ${TERMCMD} is what you want Mar 08 22:30:58 i should set it in the bb file then? shouldnt it be there somewhere already? Mar 08 22:31:12 ah, no, ${TERMCMDRUN} Mar 08 22:31:15 you can set it in local.conf Mar 08 22:31:27 TERMCMDRUN = '${XTERM_TERMCMD} -e $SHELLCMDS' Mar 08 22:31:32 something like that Mar 08 22:31:43 ah, great! i was looking in /openembedded/recipes/linux/linux-rp_2.6.26.bb Mar 08 22:31:48 * kergoth_ thinks its rather weird and annoying that we need to set two variables for that :) Mar 08 22:31:53 wrong place then. i'll try setting it in local.conf Mar 08 22:32:32 kergoth_: yeah, it is both of those things. Mar 08 22:32:41 03Chris Larson  07org.openembedded.dev * r4eb51d8d2c 10openembedded.git/recipes/linux-libc-headers/ (12 files): Mar 08 22:32:41 linux-libc-headers: kill unneeded do_stage functions Mar 08 22:32:41 Signed-off-by: Chris Larson Mar 08 22:52:31 pb__: TERMCMDRUN = '${XTERM_TERMCMD} -e $SHELLCMDS' Mar 08 22:52:31 TERMCMD = '${XTERM_TERMCMD} -e $SHELLCMDS' Mar 08 22:52:38 this solved it, thank you ! Mar 08 23:17:55 qsp: there is an XTERM_TERMCMDRUN, fyi. TERMCMD = "${XTERM_TERMCMD}" TERMCMDRUN = "${XTERM_TERMCMDRUN} will do Mar 08 23:19:02 mm. thanks. i-ll remove redundant var then. Mar 08 23:19:49 mm, it remains 2 vars.. what changes is the argument. ok :-) Mar 09 00:26:47 how do I list which glibc locales I want built? Mar 09 00:30:05 jacques: GLIBC_GENERATE_LOCALES = "en_GB.UTF-8" Mar 09 00:30:15 something like this in local.conf Mar 09 00:30:39 florian: thanks! **** ENDING LOGGING AT Tue Mar 09 02:59:58 2010