**** BEGIN LOGGING AT Sat Oct 09 02:59:57 2010 Oct 09 04:23:11 khem: huh, would think so Oct 09 04:25:06 any of you guys know any workarounds to make a quickcam pro 9000 work with the beagleboard Oct 09 04:25:07 ? Oct 09 06:19:02 hi Oct 09 06:19:09 hi in my /etc/inittab scpirt there is this line Oct 09 06:19:15 S:2345:respawn:/sbin/getty 115200 ttyS2 Oct 09 06:19:22 if i change it to ttyS1 will it be displayed in the normal RS 232 instad of USB Oct 09 06:19:23 ?? Oct 09 06:20:02 I guess that depends on what ttyS1 is on your device Oct 09 06:21:22 i want to see the console boot on my regular RS 232 instad of usb Oct 09 06:21:27 is it possible Oct 09 06:22:01 i have a rs232 serial rf Tx and Rx device Oct 09 06:22:15 if your 'regular RS 232' is ttyS1 (this does not affect kernel messages) Oct 09 06:22:21 i want to trasmit the cosole boot over rf Oct 09 06:22:46 i am using gumstix Oct 09 06:22:47 I have no idea what hardware you have, how can I know... Oct 09 06:23:12 well look at the documentation, which UART is connected to what Oct 09 06:23:17 i have two paired rf device Oct 09 06:23:38 and if you want to have the kernel boot messages then you need to recompile the kernel Oct 09 06:23:46 or change the kernel command line Oct 09 06:23:51 now i can communicate them by connecting to my hyperterminal Oct 09 06:24:56 what if i connect my rx tx pin of gumstix via a max 232 to PC rs 232 port Oct 09 06:25:01 will it work?? Oct 09 06:25:42 I'd expect so. consult your datasheet to be sure which logic levels are used Oct 09 06:25:56 you may need an 1,8V or 3,3V level converter Oct 09 06:26:10 ya i have oredered that one Oct 09 06:27:19 but my doubt is if i edit my /etc/inittab to 19200 baud rate and connect the gumstix RX1 ,TX1 pin via max 232 to my pentium pc Oct 09 06:27:41 will i be able to see the console boot via RS 232 Oct 09 06:27:44 ? Oct 09 06:28:24 are you talking about the kernel messages or a login prompt? Oct 09 06:28:45 login prompt Oct 09 06:29:02 then don't say boot console, that sounds like kernel messages! Oct 09 06:30:12 you can put a getty on whatever port you want. I'm not familiar with your hardware, so just read the fine documentation to make sure you are doing it right. Oct 09 06:30:34 what should i say Oct 09 06:30:38 for that ? Oct 09 07:00:25 gm Oct 09 07:03:56 gm Oct 09 07:36:27 03Frans Meulenbroeks  07org.openembedded.dev * rb87c02aeb9 10openembedded.git/recipes/perl/libxml-sax-perl_0.96.bb: Oct 09 07:36:27 perl/libxml-sax-perl_0.96.bb: updated LICENSE Oct 09 07:36:27 Signed-off-by: Frans Meulenbroeks Oct 09 07:36:32 03Frans Meulenbroeks  07org.openembedded.dev * r9f08969044 10openembedded.git/recipes/mythtv/gmyth-upnp_0.7.0.bb: Oct 09 07:36:32 mythtv/gmyth-upnp_0.7.0.bb: removed superfluous quote in LICENSE Oct 09 07:36:32 Signed-off-by: Frans Meulenbroeks Oct 09 07:36:42 03Frans Meulenbroeks  07org.openembedded.dev * r4a88b81c58 10openembedded.git/recipes/mythtv/gmyth_0.7.1.bb: Oct 09 07:36:42 mythtv/gmyth_0.7.1.bb: removed superfluous quote in LICENSE Oct 09 07:36:42 Signed-off-by: Frans Meulenbroeks Oct 09 07:36:48 03Frans Meulenbroeks  07org.openembedded.dev * r72fb6426ac 10openembedded.git/recipes/perl/libxml-namespacesupport-perl_1.11.bb: Oct 09 07:36:48 perl/libxml-namespacesupport-perl_1.11.bb: update LICENSE Oct 09 07:36:48 Signed-off-by: Frans Meulenbroeks Oct 09 07:36:49 03Frans Meulenbroeks  07org.openembedded.dev * rcf1fa2e787 10openembedded.git/recipes/perl/libxml-libxml-perl_1.70.bb: Oct 09 07:36:49 perl/libxml-libxml-perl_1.70.bb: update LICENSE Oct 09 07:36:49 Signed-off-by: Frans Meulenbroeks Oct 09 07:44:14 03Martin Jansa  07master * rf1b5be6850 10openembedded.git/recipes/mupdf/ (3 files in 2 dirs): Oct 09 07:44:14 Revert "mupdf_0.6.bb: remove recipe." Oct 09 07:44:14 * mupdf_git doesn't build here Oct 09 07:44:14 * only grg have successfull build on http://tinderbox.openembedded.org/packages/mupdf/ Oct 09 07:44:14 This reverts commit 71d25fe210fc31a342114e5a229f89be304632be. Oct 09 07:44:14 Signed-off-by: Martin Jansa Oct 09 07:44:15 03Martin Jansa  07master * r65b22b06f1 10openembedded.git/recipes/openmoko-3rdparty/mokojeweled_git.bb: mokojeweled: bump SRCREV Oct 09 07:44:16 03Martin Jansa  07master * re8990a5faa 10openembedded.git/conf/distro/include/preferred-shr-versions.inc: Oct 09 07:44:16 shr: prefer mupdf 0.6 Oct 09 07:44:17 Signed-off-by: Martin Jansa Oct 09 08:20:05 hello Oct 09 08:26:27 03Martin Jansa  07master * rf581ee319b 10openembedded.git/recipes/xorg-lib/libx11.inc: Oct 09 08:26:27 libx11: disable fop Oct 09 08:26:27 * it's probably trying to use fop from buildhost Oct 09 08:52:47 03Koen Kooi  07org.openembedded.dev * r55845cdac6 10openembedded.git/recipes/util-linux-ng/util-linux-ng.inc: Oct 09 08:52:47 util-linux-ng: fix DEPENDS Oct 09 08:52:47 * it picks up pam from staging if it's built, so add it to DEPENDS with DISTRO_FEATURES guard Oct 09 08:52:47 * remove bogus IMAGE_FEATURE check since u-l-ng is supposed to be used in images with or without udev Oct 09 08:52:47 Recipes are not allowed to make compile decisions based on the image that's going to get built, since that breaks package management severely. Oct 09 08:52:47 More to the point: What happens when you do 'bitbake util-linux-ng' and later do 'bitbake foo-image' where foo-image sets a different IMAGE_DEV_MANAGER? Oct 09 08:52:48 Signed-off-by: Koen Kooi Oct 09 11:30:05 03Frans Meulenbroeks  07org.openembedded.dev * r12df30097f 10openembedded.git/recipes/pulseaudio/pulseaudio.inc: Oct 09 11:30:05 pulseaudio.inc: add DEPENDS on tcp-wrappers Oct 09 11:30:05 Pulseaudio by default uses tcpwrap if it is there Oct 09 11:30:05 (unless told in configure not do do so) Oct 09 11:30:05 This made things nondeterministic Oct 09 11:30:05 made the dependency explicit (alternate option was add --disable-tcpwrap to EXTRA_OECONF) Oct 09 11:30:06 Signed-off-by: Frans Meulenbroeks Oct 09 12:09:08 hrms Oct 09 12:09:18 patentissue on libgsm http://www.quut.com/gsm/ Oct 09 12:40:28 Hello --- I have a really old device (a Psion netBook, not Pro) which nobody's got around to porting 2.6 to. The filesystem for it is based on the now defunct OpenZaurus project, from circa 2005. Does anyone know if any ipkg feeds exist form armv4 that support 2.4 kernels? Oct 09 12:41:07 dg11 ask florian Oct 09 12:41:15 he hast a netbook too Oct 09 12:41:23 hm or was it a pro Oct 09 12:41:33 I know there's a 2.6 port to Pro. Oct 09 12:44:04 If I were willing to build OE myself, could I get 2.4 support? Note that I don't need to build the kernel itself, just the userland. Oct 09 12:45:27 sorry Oct 09 12:45:43 dont know if we have a kernel in Oct 09 12:46:14 Fair enough. Oct 09 12:46:30 some newer features like udev istn available for 2.4 Oct 09 12:46:59 hm and you cannt build glibc without kernel headers Oct 09 12:47:01 hm hm Oct 09 12:49:42 supper now Oct 09 12:49:53 Lunch for me. Enjoy. Oct 09 12:50:29 You might have better luck seeing if you can find a similar situation in optware -- perhaps there's a toolchain there already that will work, or perhaps you can find the original toolchain? Oct 09 12:50:54 Optware's non-OE, right? Oct 09 12:51:03 Right. Oct 09 12:51:56 But some of the devices that support optware are built by OE - NSLU2 unslung, slugOS, etc. are examples. Oct 09 12:52:27 In particular, unslung uses a 2.4 kernel (although it's an ARM5 device Oct 09 12:52:29 ) Oct 09 12:52:58 I *think* Unslung is big-endian. I used to have a NSLU2, but always run Debian on it, so I can't be sure. Oct 09 12:53:34 Unslung is BE as well. Oct 09 12:53:52 Can you download the original toolchain that supports your 2.4 rootfs? Oct 09 12:54:17 No, it vanished when OpenZaurus packed it in. Oct 09 12:54:26 My current rootfs was packaged up in 2005. Oct 09 12:55:42 Makes things really hard that way. Oct 09 12:56:11 Yes... Oct 09 12:56:26 Grar, nslu2-linux.org doesn't mention *kernel versions* anywhere. Oct 09 12:57:41 libc version matching is probably more important, unless you get an alternate libc with optware (which is possible too) Oct 09 12:58:57 Okay, unslung is 2.4 but is BE, SlugOS, Angstrom, Debian, OpenWRT for the NSLU2 are all 2.6. Oct 09 12:59:28 Well, they probably wouldn't work anyway, since they assume ARM5 -- isn't your device ARM4? Oct 09 12:59:51 The rootfs is using glibc 2.3.3. I discovered the 2.4/2.6 problem when I installed 2.9 and nothing would load. Oct 09 12:59:55 armv4l. Oct 09 13:00:33 Hmmm... sounds like you might need to create your own custom world. Lots of work. Oct 09 13:01:11 And probably not too much different from porting a 2.6 kernel (kernels are a lot easier than libc and all that stuff!) Oct 09 13:02:33 I *have* found an OE machine description for a 2.4 device. Okay, it's mipsel, but it's encouraging... Oct 09 13:06:57 Well, I've hacked together a config file for SA1100 and kernel24. I suppose now I have to crank it and see what happens. Oct 09 13:29:06 Arrgh! How do I force bitbake to redownload packages? Removing the source packages just causes 'The localpath does not exist' errors. Oct 09 13:32:21 bitbake -c clean package Oct 09 13:36:06 I made the mistake of ^Cing a build, and it got itself into a state... seems to be working now, though. Oct 09 13:47:36 crtl+c a build is not a mistake Oct 09 13:49:37 aaanyone know of workarounds to get a quickam pro 9000 to work with OE/beagle? Oct 09 13:50:06 usb? Oct 09 13:51:03 yeah Oct 09 13:51:19 apparently my revision and the revision before of this camera have issues with UVC Oct 09 13:51:20 same as under linux Oct 09 13:51:35 on other boards Oct 09 13:51:45 like they are still UVC cameras, but some pieces dont work Oct 09 13:52:02 try update the kernel Oct 09 13:52:14 at .32 right now Oct 09 13:52:19 or try update just the uvc part Oct 09 13:52:22 yes Oct 09 13:52:34 .32-psp is only kernel with dsp and sgx support Oct 09 13:53:08 there's a seperate kernel for dsp and sgz? Oct 09 13:53:11 sgx* Oct 09 13:53:20 *sigh* Oct 09 13:53:33 the standard kernel in oe is .32-psp Oct 09 13:53:41 for beagle Oct 09 13:56:42 you maybee can try this http://wiki.meego.com/ARM/Meego_on_Beagleboard_from_scratch Oct 09 13:56:49 for the kernel Oct 09 13:56:58 and loosing dsp support Oct 09 14:23:30 If I change a target flag in my machine.conf --- TARGET_CC_ARCH, actually --- is BitBake intelligent enough to rebuild everything that needs rebuilding? Oct 09 14:37:35 Tis not a matter of intelligence; bitbake is not designed to solve that problem. Oct 09 14:37:46 So no, you'll have to rebuild everything yourself. Oct 09 14:38:09 dg11: We have armv4 working with EABI + 2.6 kernel, but not with 2.4 Oct 09 14:38:39 hi mwester Oct 09 14:45:00 03Frans Meulenbroeks  07org.openembedded.dev * r51d673fe16 10openembedded.git/recipes/mythtv/mythtv_0.23+fixes.bb: Oct 09 14:45:00 mythtv_0.23+fixes.bb: add pulseaudio to DEPENDS Oct 09 14:45:00 Signed-off-by: Frans Meulenbroeks Oct 09 14:45:43 Hi Oct 09 14:46:09 Since /etc/update-fonts-common.d is usually empty, what does update-fonts actually do? Oct 09 14:49:07 khem feel free to add my ack to the libtool patches Oct 09 14:49:20 Sorry, my bad Oct 09 14:51:37 #belated Okay, so once I change the build options, how do I tell BitBake to delete *all* intermediate data and start again from scratch? -c clean appears to clean only one package. Oct 09 14:51:52 eFfeM: ok thx Oct 09 14:51:53 (I've just discovered that my device isn't even EABI, it's APCS-32 with FPA floats. Whee! Oct 09 14:52:00 ) Oct 09 14:52:07 dg11: rm your TMPDIR Oct 09 14:52:26 dg11: if its based on armv4 then its supported Oct 09 14:52:38 like StrongARM Oct 09 14:52:48 Yes, it's a SA1100. Oct 09 14:52:56 should work Oct 09 14:54:09 I'm a little worried that the glibc it's building will assume EABI for system calls. Is there a 'better' way to specify the ABI than just setting -mabi=apcs-gnu in the build flags? Oct 09 14:56:58 (efFem: ta, works fine.) Oct 09 14:58:01 well, I dont know how good OABI is in OE now Oct 09 14:58:10 can you use newer kernel ? Oct 09 14:58:57 Alas no. Oct 09 15:00:26 hmm, ok it should work with OABI though Oct 09 15:03:48 just make sure that you choose TARGET_OS to be "linux" and not "linux-gnueabi" Oct 09 15:04:54 Hmm. I'm not defining TARGET_OS at all. I copied my machine.conf off mtx-1. Oct 09 15:05:22 I do have kernel24 in MACHINE_FEATURES and a kernel version of 2.4.27. I haven't spotted it downloading that kernel, though. Oct 09 15:05:35 k Oct 09 15:05:41 which DISTRO are you using Oct 09 15:06:23 * dg11 searches for DISTRO. Oct 09 15:06:34 Ah. angstrom-2008.1. Oct 09 15:06:42 ok Oct 09 15:07:14 That's in a local.conf somewhere else entirely and was set by the angstrom setup scripts. Oct 09 15:07:36 Ah. Now it's unpacking the 2.6.31 headers, and it doesn't look like a native package. Oct 09 15:08:54 hmmm yeah you need to pin some versions in your local.conf Oct 09 15:08:59 to match your kernel Oct 09 15:09:17 Not in the machine conf file? Oct 09 15:11:31 * dg11 finds the angstrom-2008-preferred-versions.inc file. Oct 09 15:16:51 you can do customization in local.conf Oct 09 15:17:18 local.conf is read last, right? Oct 09 15:17:34 yes Oct 09 15:17:51 Are the distro files read before the machine .conf file? Oct 09 15:18:41 you can add -DDD to bitbake invocation this along with other messages will print when bitbake read which conf Oct 09 15:18:48 Ah, brilliant. Oct 09 15:19:05 Shame that rereading all the .bb files takes such an age, though... Oct 09 15:20:04 well, have you compiled a project with 8200 files Oct 09 15:20:13 how long does C compiler take ? Oct 09 15:20:54 Actually, yes. I had to write my own build tool to make it compile in a reasonable time... Oct 09 15:21:27 that said bb is not optimal we alway work on improving speed Oct 09 15:21:35 I'm not knocking bb, but it's a good thing I have a book handy! Oct 09 15:21:56 feel motivated to see if there are ways to improve it Oct 09 15:22:30 hoi khem Oct 09 15:22:54 woglinde: hello wie gehts Oct 09 15:26:29 hallo wie gehts Oct 09 15:26:38 gotta go now Oct 09 16:45:48 yo, watch out, patch train coming (letter o) Oct 09 16:46:37 03Frans Meulenbroeks  07org.openembedded.dev * rf2dfbcac98 10openembedded.git/recipes/openmoko-projects/exposure/setup-r62.diff: Oct 09 16:46:37 openmoko-projects : moved unused files to obsolete dir Oct 09 16:46:37 Signed-off-by: Frans Meulenbroeks Oct 09 16:46:37 03Frans Meulenbroeks  07org.openembedded.dev * r713c49ed1c 10openembedded.git/recipes/omnewrotate/files/xsession.script.patch: Oct 09 16:46:38 omnewrotate : moved unused files to obsolete dir Oct 09 16:46:38 Signed-off-by: Frans Meulenbroeks Oct 09 16:46:39 03Frans Meulenbroeks  07org.openembedded.dev * ra7de1354ec 10openembedded.git/recipes/openmoko2/ (2 files in 2 dirs): Oct 09 16:46:39 openmoko2 : moved unused files to obsolete dir Oct 09 16:46:40 Signed-off-by: Frans Meulenbroeks Oct 09 16:46:41 03Frans Meulenbroeks  07org.openembedded.dev * r01a8bb73c0 10openembedded.git/recipes/opencv/opencv/debian/ (3 files): Oct 09 16:46:42 opencv : moved unused files to obsolete dir Oct 09 16:46:42 Signed-off-by: Frans Meulenbroeks Oct 09 16:46:43 03Frans Meulenbroeks  07org.openembedded.dev * r3453dd03b1 10openembedded.git/recipes/omniorb/files/ (arm_double.patch dynskel.patch): Oct 09 16:46:43 omniorb : moved unused files to obsolete dir Oct 09 16:46:44 Signed-off-by: Frans Meulenbroeks Oct 09 16:46:44 03Frans Meulenbroeks  07org.openembedded.dev * r0bf5053f52 10openembedded.git/recipes/opie-freetype/opie-freetype/modern-freetype-includes.patch: Oct 09 16:47:02 opie-sysinfo : moved unused files to obsolete dir Oct 09 16:47:02 Signed-off-by: Frans Meulenbroeks Oct 09 16:47:02 (3 lines omitted) Oct 09 17:02:38 re Oct 09 17:03:41 hi woglinde Oct 09 17:03:47 hi hrw Oct 09 17:04:23 effem policy was when not pinned I can remove the older recipes? Oct 09 17:05:56 yes, if minor version or major version & older than 2 yrs Oct 09 17:06:48 unless it is quite obious that there are out-of-tree users or if it is still well-maintained Oct 09 17:07:00 * eFfeM would not even think about removing e.g. a gcc version Oct 09 17:07:09 as these are well taken care of Oct 09 17:07:45 woglinde: and don't do 100 or so in a weekend, that upsets people Oct 09 17:09:12 woglinde, if you are familiar with a set of recipes and its user base you can do what you need to Oct 09 17:09:46 re Oct 09 17:09:50 okay Oct 09 17:18:00 damn Oct 09 17:18:06 gpe uses older libgsm Oct 09 17:20:43 woglinde: that is a typical problem, i also saw that sometimes a distro which seems to be orphaned pins a recipe Oct 09 17:21:39 older gpe versions Oct 09 17:21:40 hm Oct 09 17:22:29 I am updating libxine Oct 09 17:22:39 next will be directfb and disko Oct 09 17:24:07 woglinde: the gpe situation in my opinion is evern wose, the pinning is only in the 2.6 and 2.7 versions but no distro is including preferred-gpe-versions-2.6.inc or 2.7 Oct 09 17:24:47 proposed to remove this and a few others as they were not used, but got a NAK without any motivation :-( Oct 09 17:25:22 hm whi nacked it? Oct 09 17:25:24 florian? Oct 09 17:25:30 nope, koen Oct 09 17:26:25 http://thread.gmane.org/gmane.comp.handhelds.openembedded/35427/focus=35946 Oct 09 17:27:05 btw also proposed to remove the unused conf/distro/include/maemo-preferred.inc Oct 09 17:27:26 maemo-preffrerd ist not used? Oct 09 17:27:29 hm hm Oct 09 17:27:45 i *guess* the reason is the mythical out-of-tree user who does not contribute but only consumes :-( Oct 09 17:27:53 no Oct 09 17:27:57 not really Oct 09 17:28:07 we used maemo-compat to compile java stuff Oct 09 17:28:44 well, grep -r maemo-preferred.inc conf does not give any users Oct 09 17:42:35 woglinde: btw to avoid possible confusion, my remark on the mythical user was referring to the gpe inc's Oct 09 17:43:33 03Frans Meulenbroeks  07org.openembedded.dev * rd153e7d9a2 10openembedded.git/recipes/perl/ (134 files): (log message trimmed) Oct 09 17:43:33 perl: updated LICENSE; GPL -> GPLv1 Oct 09 17:43:33 perl has as license the choice between Artistic or GPLv1. Oct 09 17:43:33 see http://dev.perl.org/licenses/ Oct 09 17:43:33 so changed LICENSE = "Artistic|GPL" to LICENSE = "Artistic|GPLv1" Oct 09 17:43:33 This also applies to CPAN recipes. Typically they specify that the Oct 09 17:43:34 code is licensed under the same terms as perl so figured that the Oct 09 17:44:05 hm why gcc-cross depends on update-rc.d Oct 09 17:45:16 strange, maybe khem knows Oct 09 17:47:46 03Frans Meulenbroeks  07org.openembedded.dev * r82fa426cee 10openembedded.git/recipes/perl/ (2 files): Oct 09 17:47:46 liblog-dispatch-perl: merged native and non-native recipes Oct 09 17:47:46 as there is no functional change, no PR bump is needed Oct 09 17:47:46 Signed-off-by: Frans Meulenbroeks Oct 09 17:57:00 03Frans Meulenbroeks  07org.openembedded.dev * r25fd42efab 10openembedded.git/recipes/perl/libxml-parser-perl_2.34.bb: Oct 09 17:57:00 libxml-parser-perl_2.34.bb: removed old version Oct 09 17:57:00 Signed-off-by: Frans Meulenbroeks Oct 09 17:57:11 03Frans Meulenbroeks  07org.openembedded.dev * r9f533610cb 10openembedded.git/recipes/perl/libxml-parser-perl_2.36.bb: Oct 09 17:57:11 libxml-parser-perl_2.36.bb: LICENSE is similar to perl so also GPLv1 Oct 09 17:57:11 Signed-off-by: Frans Meulenbroeks Oct 09 17:57:36 hm testing branch seems to fail on libgee Oct 09 17:57:44 whatever that is Oct 09 18:01:34 03Frans Meulenbroeks  07org.openembedded.dev * r9a8dc85087 10openembedded.git/recipes/perl/libclass-methodmaker-perl_2.15.bb: Oct 09 18:01:34 libclass-methodmaker-perl_2.15.bb: removed GPL from LICENSE Oct 09 18:01:34 LICENSE said unknown|GPL (which seems very odd) Oct 09 18:01:34 could not find any evidence in the package or on CPAN about the license Oct 09 18:01:34 so removed the |GPL part as that is probably not right Oct 09 18:01:34 Signed-off-by: Frans Meulenbroeks Oct 09 18:15:52 eFfeM, hi Oct 09 18:16:36 JaMa|Off, hi Oct 09 18:16:50 JaMa is still off Oct 09 18:17:10 and I had more important to tell him this morning than thanks him for wesnoth along with eFfeM Oct 09 18:24:30 03Klaus Kurzmann  07org.openembedded.dev * r3885e7a0e8 10openembedded.git/recipes/freesmartphone/cornucopia.inc: Oct 09 18:24:31 cornucopia.inc: bump rev Oct 09 18:24:31 Signed-off-by: Klaus Kurzmann Oct 09 18:49:55 GNUtoo|laptop: my pleasure Oct 09 18:50:15 actually watching a movie (commercial break now) Oct 09 18:50:39 eFfeM, ok, next time tell me I did something wrong btw Oct 09 18:50:51 (it doesn't mather if it's after the commit) Oct 09 18:51:04 and why it was wrong Oct 09 18:52:22 well the only thing was that RDEPENDS or so should be RDEPENDS_${PN} Oct 09 18:52:29 no biggie Oct 09 18:53:29 hm Oct 09 18:53:32 libudev again Oct 09 18:54:05 | libudev/libudev-queue.c:185:1: internal compiler error: in cond_exec_process_insns, at ifcvt.c:273 Oct 09 18:54:20 qemuarm Oct 09 18:54:23 glibc Oct 09 18:54:27 gcc-4.5 Oct 09 18:55:23 hi Oct 09 18:55:41 wtf is this Oct 09 18:56:03 ... Oct 09 18:56:24 hi kergoth Oct 09 18:56:29 hey Oct 09 18:57:39 03Frans Meulenbroeks  07org.openembedded.dev * rff1da6be42 10openembedded.git/recipes/perl/libdevice-serialport-perl_1.04.bb: Oct 09 18:57:39 libdevice-serialport-perl_1.04.bb: license = artistic according to .spec file in src dir Oct 09 18:57:39 Signed-off-by: Frans Meulenbroeks Oct 09 19:14:04 yo Oct 09 19:16:46 hi all Oct 09 19:25:08 eFfeM, ah ok I thought I did an error, was it an error or just cosmetics? Oct 09 19:27:30 GNUtoo|laptop: ping Oct 09 19:27:39 JaMa, hi Oct 09 19:27:49 it was just to talk about my wesnoth error Oct 09 19:27:56 that you silently corrected Oct 09 19:28:01 it's nice that you corrected it Oct 09 19:28:25 I? imho eFfeM did Oct 09 19:28:30 but as I did an error, it would be nice that I learn about it, in order not to do it in the future Oct 09 19:28:31 ok Oct 09 19:28:41 the commit had both names Oct 09 19:28:42 no? Oct 09 19:29:12 acked-by you Oct 09 19:29:21 and signed off by eFfeM Oct 09 19:29:26 so I wonder Oct 09 19:29:33 I've just acked it.. because it's the same type of error I was fixing couple months ago Oct 09 19:29:41 ok Oct 09 19:29:51 why is RCONFLICTS bad? Oct 09 19:29:58 but credits and thanks go to eFfeM for this Oct 09 19:29:59 why is RCONFLICTS_${PN} preferred Oct 09 19:30:04 ok Oct 09 19:30:20 GNUtoo|laptop: should I look for that e-mail I sent couple months ago? :) Oct 09 19:30:39 what mail? Oct 09 19:30:43 I can look too Oct 09 19:31:02 mostly because ie RCONFLICTS_wesnoth-dev doesn't really RCONFLICT Oct 09 19:31:09 ah ok Oct 09 19:31:16 usually you care only about RCONFLICTS_wesnoth Oct 09 19:31:20 ok Oct 09 19:31:23 understood Oct 09 19:31:24 not all packages from PACKAGES, clear? Oct 09 19:31:25 thanks a lot Oct 09 19:31:26 ok Oct 09 20:03:20 03Frans Meulenbroeks  07org.openembedded.dev * ra8766995a3 10openembedded.git/recipes/perl/liblinux-dvb-perl_1.0.bb: Oct 09 20:03:20 liblinux-dvb-perl_1.0.bb: update LICENSE according to file COPYING Oct 09 20:03:20 Signed-off-by: Frans Meulenbroeks Oct 09 20:03:30 03Frans Meulenbroeks  07org.openembedded.dev * rdd8703ecfa 10openembedded.git/recipes/perl/libsocket6-perl_0.23.bb: Oct 09 20:03:30 libsocket6-perl_0.23.bb: changed license to unkwown, no evidence that it is bsd (or something else) Oct 09 20:03:30 Signed-off-by: Frans Meulenbroeks Oct 09 20:03:31 03Frans Meulenbroeks  07org.openembedded.dev * r3be04dd901 10openembedded.git/recipes/perl/libwww-mechanize-perl_1.60.bb: Oct 09 20:03:31 libwww-mechanize-perl_1.60.bb: changed license from perl to Artistic|GPLv1 as used everywhere else Oct 09 20:03:31 Signed-off-by: Frans Meulenbroeks Oct 09 20:03:34 03Frans Meulenbroeks  07org.openembedded.dev * r3114e9d1c6 10openembedded.git/recipes/perl/libio-stringy-perl_2.110.bb: Oct 09 20:03:34 libio-stringy-perl_2.110.bb: update LICENSE according to file COPYING Oct 09 20:03:34 Signed-off-by: Frans Meulenbroeks Oct 09 20:03:36 03Frans Meulenbroeks  07org.openembedded.dev * r43dedf5248 10openembedded.git/recipes/perl/libxml-simple-perl_2.18.bb: Oct 09 20:03:37 libxml-simple-perl_2.18.bb: similar license as perl so added GPLv1 Oct 09 20:03:37 Signed-off-by: Frans Meulenbroeks Oct 09 20:13:31 Oh, dear. My attempt to build an OABI kernel 2.4 OE package is failing when configuring glibc-initial-2.9-r37.3 with: Oct 09 20:13:33 configure: error: working compiler support for visibility attribute is required Oct 09 21:02:44 mickeyl: testing build is broken in libgee-native: http://tinderbox.openembedded.net/public/logs/task/8568667.txt Oct 09 22:32:30 cya tomorrow Oct 10 00:19:28 hey Oct 10 00:57:15 * kergoth thinks about ditching the separate tasks for the various package_*.bbclasses, and just use something like PACKAGEFUNCS to run them all, or even just use PACKAGEFUNCS, thereby avoiding the need to emission of and reading back in of pkgdata Oct 10 00:57:29 s/need to/need for/ Oct 10 01:29:32 hey Oct 10 02:24:55 hey JDuke127 **** ENDING LOGGING AT Sun Oct 10 02:59:57 2010