**** BEGIN LOGGING AT Sun Feb 04 02:59:58 2007 Feb 04 03:50:23 03mwester 07org.oe.dev * r66e0605f... 10/ (1 packages/linux/ixp4xx-kernel/2.6.19/defconfig): Kernel: af_packet now built into the kernel Feb 04 08:24:19 good morning Feb 04 08:24:33 hey Bernardo|away Feb 04 08:24:36 good morning all Feb 04 08:25:01 hi koen Feb 04 08:25:21 morning all Feb 04 08:26:27 anyone still using the oz354x branch? I'm stuck now building libxine-fb (bug #1795) Feb 04 08:26:35 hey rwhitby Feb 04 08:27:47 03koen 07org.oe.dev * rf6eb0ab7... 10/ (21 files in 3 dirs): gtk+: add 2.10.9, a bugfix release Feb 04 08:27:50 03koen 07org.oe.dev * rf3a8dc0c... 10/ (1 packages/dates/dates_0.3.bb packages/dates/dates_0.3.1.bb): dates: update to 0.3.1, a bugfix release Feb 04 08:31:05 morning Feb 04 08:31:56 03rwhitby 07org.oe.dev * rdf745605... 10/ (1 packages/linux/ixp4xx-kernel/2.6.20/defconfig): ixp4xx-kernel: af_packet now built into the kernel Feb 04 08:32:03 03ifaistos 07org.oe.dev * ra39305a5... 10/ (1 conf/machine/dht-walnut.conf): dht-walnut.conf: Modify to use task-base Feb 04 08:32:37 koen : Did you find time to fix the problem with my commit yesterday ? Feb 04 08:33:20 no Feb 04 08:33:24 and I doubt I'll find time Feb 04 08:34:34 is there something i can do ? remoke the commit ? Feb 04 08:41:37 koen: the cron package fails in do_install on angstrom/ixp4xx due to install -s in cron's Makefile trying to call strip and strip not recognising the binary format (I presume it's calling the host strip instead of the cross strip). Any pointers on where I should look to work out how to fix it? Feb 04 08:42:17 remove the '-s', OE does its own stripping Feb 04 08:42:31 if the package strips itself, the -dbg packages don't work anymore Feb 04 08:45:16 ok, so this is a general problem with the cron package then - cause the '-s' would be there for all distros. Feb 04 08:45:25 yes Feb 04 08:45:33 I'll do a patch later tonight - have to put the kids to bed now. Thanks koen. Feb 04 08:45:57 heh - there is already a patch that modifies those lines, so it'll be easy to fix :-) Feb 04 08:46:26 (/cron-3.0pl1/nonrootinstall.patch Feb 04 08:46:26 ) Feb 04 08:50:03 fixed and pushing. Feb 04 08:55:04 morning all Feb 04 08:55:34 RP: hi ! Feb 04 09:06:22 hey RP Feb 04 09:08:28 03koen 07org.oe.dev * r6ffad588... 10/ (6 files in 3 dirs): Feb 04 09:08:28 esound: add proper esound, move away the gpe fork Feb 04 09:08:28 * thanks to the GPE folks not following the versioning policy PV is going backwards Feb 04 09:08:38 03rwhitby 07org.oe.dev * r77fc766a... 10/ (3 files in 3 dirs): cron: change the existing nonrootinstall patch so that it also removes the -s flag from the install commands Feb 04 09:08:38 03rwhitby 07org.oe.dev * r6f6ac342... 10/ (1 packages/meta/slugos-packages.bb): slugos-packages: re-enable cron Feb 04 09:39:34 03koen 07org.oe.dev * rbffe1534... 10/ (3 files in 2 dirs): abiword: update to 2.5.1 Feb 04 10:00:15 koen, RP: what was the final consensus on how to remove the /boot/zImage file from distros/machines which load the kernel from flash and don't have an extra 1MB to spare in the rootfs? Feb 04 10:01:17 rwhitby: I know how the Zaurus does it, I'm not sure there is a consenus but the Zaurus will continue to do that until a better way presents itself... Feb 04 10:02:07 RP: can you point me to the .bb file where it is done? Feb 04 10:02:56 rwhitby: linux-rp.inc: FILES_kernel-image = "", ALLOW_EMPTY = "1" Feb 04 10:04:03 RP: what was the downside of removing it from the image after the rootfs had been built, but keeping it in the kernel-image package? Feb 04 10:04:30 rwhitby: ipkg update could install it Feb 04 10:05:03 ah right. you guys don't pivot to large storage as a matter of course. Feb 04 10:05:33 No, and we don't want large useless confusing files on the root filesystem Feb 04 10:05:38 :-) Feb 04 10:08:25 RP: I'm going to create an empty kernel-image, but also create a kernel-image-ixp4xx which includes the file (but is not used in building the rootfs). Then the use can choose to install the specific kernel image package on external storage if they want it, but it won't get brought in automatically. Feb 04 10:10:10 rwhitby: :-/. I'll give handling this properly some thought as I'd like to have one way which helps everyone ideally... Feb 04 10:10:27 so I should hold off then? Feb 04 10:10:55 (I'm happy to do so, for up to a week) Feb 04 10:11:11 rwhitby: Yes, please, just leave it a couple of days and I'll think about this Feb 04 10:11:20 ok Feb 04 10:16:31 rwhitby: My current thinking is to put the kernel binary into a separate package and usually have kernel-image RDEPEND on the binary but allow that dependency to be overridden on certain machines Feb 04 10:17:12 Or maybe keep the binary in kernel-image-version but create kernel-version which the modules depend on Feb 04 10:17:46 either of those solutions would work for me. Feb 04 10:18:14 I will also take the oppertunity to package vmlinux :) Feb 04 10:20:45 ok, so kernel_ is already created, so it should just be a case of having the modules depend on that rather than kernel-image and making kernel_'s dependency on kernel-image optional Feb 04 10:26:33 Would anyone object if I nuked PARALLEL_INSTALL_MODULES? Feb 04 10:27:21 afaik all its users are happy with their own fork Feb 04 10:30:45 koen: generic.conf and openzaurus.conf are using it in OE.dev :-/ Feb 04 10:31:09 generic doesn't need it Feb 04 10:31:30 and I think I can say openzaurus shouldn't have that... Feb 04 10:35:07 03rpurdie 07org.oe.dev * r64a99c44... 10/ (4 files in 3 dirs): openzaurus/generic.conf: Remove PARALLEL_INSTALL_MODULES, neither need it Feb 04 10:36:48 03koen 07org.oe.dev * rbb6c1f59... 10/ (1 conf/distro/angstrom-2007.1.conf): angstrom: prefer gtk 2.10.9 Feb 04 10:37:18 Another random thought, would it be better to have kernel modules with PN = kernel-module-myname-${KERNEL_VERSION} and PV=${PR} ? Feb 04 10:38:25 only if it (R)PROVIDES kernel-module-myname Feb 04 10:39:36 That's easy enought to arrange. I'm just wondering if we ever would want to allow multiple kernels to be installed... Feb 04 10:40:11 PARALLEL_INSTALL_MODULES is bust as it only works for 2.4/2,6 and has other issues so I still want to see that die Feb 04 10:41:34 hrm Feb 04 10:41:41 pulseaudio needs some love Feb 04 10:41:58 and a initscript, a volatile entry, a proper postinst... Feb 04 10:43:59 RP: Regarding the problem i told you yesterday.... ipkg gets build Feb 04 10:44:05 hey zecke Feb 04 10:44:21 RP: any news on Ximageon in the past 2 weeks? Feb 04 10:44:54 when copiling for arm for example; if i don't add anything special in the build command will bitbake automatically use ./configure --target=arm ? Feb 04 10:46:07 Eblis: if configured right, it will pass the right options Feb 04 10:47:04 in local.conf i have machine = "ep93xx" and distro = "generic" Feb 04 10:47:11 the target line is commented Feb 04 10:47:14 RP : -> http://pastebin.ca/339874 Feb 04 10:47:20 do i need to specify something in the project .bb file as well ? Feb 04 10:47:30 Eblis: do you just wonder or do you see an error? Feb 04 10:47:35 i just want to do a ./configure --target=arm, nothing special Feb 04 10:47:43 i see an error, but it's for install Feb 04 10:48:23 Ifaistos: does dht-walnut have an EXTRA_PACKAGE_ARCH for ppc405? Feb 04 10:48:35 Eblis: If you have an autotools based app to compile, inherit autotools and then check http://www.openembedded.org/repo/org.openembedded.dev/classes/autotools.bbclass Feb 04 10:49:03 Eblis: it is passing the various --build,host,target automatically Feb 04 10:49:31 koen : Don't think so Feb 04 10:49:43 Ifaistos: that's the problem Feb 04 10:53:38 it's probably me doing something very stupid but i don't know what :) http://miranda.pastebin.ca/339877 Feb 04 10:54:25 if i go an look at the temp\work folder mono was copied to the i686 folder, not the arm4v one Feb 04 10:54:33 *arm4t Feb 04 10:54:47 Eblis: prefer 'require' over include' Feb 04 10:55:12 Eblis: "no rule to make"... means either mono has no install target at all Feb 04 10:55:26 Eblis: or make is executed from the wrong directory? Feb 04 10:55:48 it has an install target ... so it must be the other one Feb 04 10:55:49 Eblis: e.g. change into the 'S' dir and you will see a temp/ directory with scripts and logs Feb 04 10:56:13 Eblis: check the bottom of the run.do_install script Feb 04 10:56:31 Eblis: e.g. source one of the scripts that worked (do_configure) and then try typing make install? Feb 04 10:58:17 when i go look in tmp\work mono is inside the i686-linux folder instead of armv4t-linux one. if i'm builing for arm shouldn't mono be copied to the armv4t folder ? Feb 04 10:58:41 Eblis: right, but for you mono-native is failing Feb 04 10:58:51 mono_1.2.2.bb Feb 04 10:58:55 and a little further: Feb 04 10:59:05 SRC_URI = "http://go-mono.com/sources/mono/mono-1.2.2.1.tar.gz" Feb 04 10:59:11 1.2.2 != 1.2.2.1 Feb 04 10:59:47 i need to specify the exact version ? i thought i could leave the build number out Feb 04 11:00:01 Eblis: 'S' is the dir where the software/src is in Feb 04 11:00:06 koen : i am trying it out. btw efika declares ppc and ppc603e. dht declares powerpc and ppc405 Feb 04 11:00:12 Eblis: and for filesystems 1.2.2 != 1.2.2.1 Feb 04 11:00:13 koen : it works. thanks ! Feb 04 11:00:24 SRC_URI = "http://go-mono.com/sources/mono/mono-${PV}.tar.gz" Feb 04 11:00:49 koen: aha, thanks Feb 04 11:01:41 and I suspect mono won't work with generic/ep93xx, since it generates vfp insns instead of fpa isns Feb 04 11:01:52 but lets get it to build first Feb 04 11:02:10 i can build mono with --target=arm by hand Feb 04 11:03:59 Eblis: sure, but you are in the right 'S' when doing it by hand... Feb 04 11:04:37 i tried it now, after changing the name of the file to include .1 and it got to do_configure ... now i'm waiting to see what happens :) Feb 04 11:04:42 thanks Feb 04 11:08:23 it's still unpacking mono in the i686 directory, is that ok ? NOTE: Unpacking /home/loki/work/openembedded/sources/mono-1.2.2.1.tar.gz to /home/loki/work/openembedded/build/tmp/work/i686-linux/mono-native-1.2.2.1-r0/ Feb 04 11:08:54 [12:30] zecke: Eblis: right, but for you mono-native is failing Feb 04 11:09:12 mono *native* is failing, not mono Feb 04 11:09:17 s/failing/unpacking/ Feb 04 11:09:40 aha Feb 04 11:20:07 Ifaistos: For some reason it can't find the ipk. Perhaps you don't have the architectures set up correctly? Feb 04 11:20:14 hi zecke Feb 04 11:20:34 zecke: I have a bitbake question/problem :} Feb 04 11:20:48 koen: I've not seen anything on Ximageon Feb 04 11:20:56 RP: yes that was the problem. it was missing ppc405 from the machine file Feb 04 11:22:21 RP: hehe, and I have about zero time :) Feb 04 11:22:47 zecke: I know :/ Feb 04 11:22:51 the deadline is approaching fast Feb 04 11:23:21 RP: maybe just shoot, but then I can't give it much thought anyway :} Feb 04 11:23:23 *sorry* Feb 04 11:23:50 zecke: Basically, my plans for event.py have hit a problem - we can't marshall the dataDict and all the events include it. Sending it for each event over xmlrpc would be a bad idea anyway... Feb 04 11:24:23 RP: send it once and cache it? Feb 04 11:24:30 koen: it is different Feb 04 11:24:42 RP: apply the Proxy pattern Feb 04 11:25:00 zecke: proxy pattern? Feb 04 11:25:08 RP: or have something like remote handlers, which declare what keys they want to look at Feb 04 11:25:28 RP: fire the event without any keys/only some keys, and fetch on demand if the remote needs more Feb 04 11:25:33 At the moment, I'm ripping the dict out for remote handler... Feb 04 11:25:52 Its something we're going to have to give more thought to though... Feb 04 11:26:05 zecke: Anyhow, it can wait :) Feb 04 11:26:22 RP: The handlers register themselves, they should declare which keys they want (for the remote case) Feb 04 11:26:42 RP: then when dispatchin/xmlrpc'ing we can just send the extracted/expanded strings Feb 04 11:27:09 RP: we should check if we use update_data somewhere in the handler and then consider defining OVERRIDES as well Feb 04 11:27:58 zecke: It kind of depende where we see tinderbox going in the future too. It might be better off as a pseduo UI rather than a class Feb 04 11:28:41 RP: in worst case we can do something like this Feb 04 11:28:56 A remote handler compiles a bit of python code that extracts a DATA dict Feb 04 11:29:14 on regsitration this code is send to the server and on each event this code is executed Feb 04 11:29:30 this code will be used to extract the necessary information which then will be send? Feb 04 11:30:32 zecke: Or maybe we just stipulate that the events should contain all the neccessary information... Feb 04 11:30:57 (if neccessary, extracting it from a passed dictonary internally) Feb 04 11:31:36 RP: I doubt we can know what to extract Feb 04 11:31:58 hmm :/ Feb 04 11:32:13 I presume tinderbox is the main user of this? Feb 04 11:33:27 atm yes Feb 04 11:37:34 The big advantage of making tinderclient a UI would be it could retain state. That might then mean we don't need as much data being passed around Feb 04 11:37:56 right, it should get a ui Feb 04 11:38:53 zecke: I'll work on this with my hack in place for now and perhaps I'll have something to demo my ideas by the time you have some free time and we can then discuss the correct direction to take :} Feb 04 14:32:58 morning Feb 04 14:43:56 re Feb 04 14:49:05 guys, any idea why I am getting "NOTE: preferred version 2.5 of glibc not available" when I am trying to build my distro? Feb 04 14:49:19 the glibc_2.5.bb file is there and I can even build it manually with bitbake -b Feb 04 14:49:34 you can ignore that message most of the times Feb 04 14:49:44 koen: well, it takes a different version Feb 04 14:49:46 and I need 2.5 Feb 04 14:49:54 I added patches from cross-lfs for mips Feb 04 14:50:41 but with the message above it automatically starts building glibc-2.3.5+cvs20051107 allthough I did not specify it anywhere Feb 04 14:50:55 any idea what is happening? Feb 04 14:52:41 I tried setting PREFERRED_VERSION_glibc, glibc-intermediate, glibc-initial to "2.5" but it did not help Feb 04 14:55:27 Jin^eLD: Perhaps bitbake with verbose debug (-DDD) will give some clues as to why its choosing that? Feb 04 14:55:46 oh, 3 'D's, I only figured two :) thanks, let me try Feb 04 14:56:34 how many -Ds can you place ? Feb 04 14:56:41 is 3 the maximum level of debug info ? Feb 04 14:57:44 Its just a number inside bitbake so you can have as many as you like. Higher than 3 usually needs code alterations to use the debug Feb 04 15:02:20 hmm I still don't get it... the glibc_2.5.bb file is being parsed OK, then after printing the OE Build Configuration it says this: Feb 04 15:02:21 DEBUG: providers for glibc-2.3.5+cvs20051107 are: ['glibc'] Feb 04 15:02:57 and goes off parsing that... I must have missed something, I really dont get it Feb 04 15:03:18 Jin^eLD: Which bitbake version is this? 1.6.x? Feb 04 15:03:36 1.6.3 Feb 04 15:04:19 so its basically like that: Feb 04 15:04:20 DEBUG: providers for glibc-2.3.5+cvs20051107 are: ['glibc'] Feb 04 15:04:20 DEBUG: update_data() Feb 04 15:04:20 NOTE: preferred version 2.5 of glibc not available Feb 04 15:04:26 and then it goes off building the 2.3.5 version Feb 04 15:04:42 and I do not see any hints in the log Feb 04 15:05:14 If it says "NOTE: preferred version 2.5 of glibc not available" there should be some hints around there as to why it thought that Feb 04 15:05:34 but I foget how the 1.6.x codebase works :/ Feb 04 15:06:19 well I do not see any hints.. Feb 04 15:06:49 I spent a couple of hours yesterday night trying to figure this one out Feb 04 15:06:55 Jin^eLD: Can you share the full log somewhere? Feb 04 15:06:59 sure Feb 04 15:08:00 one moment Feb 04 15:10:38 http://www.deadlock.dhs.org/jin/glibc-25-log.txt Feb 04 15:11:04 I think I might have found something though.. last log I did was when cleaning, there it just said not available and thats it, this one is for building task base Feb 04 15:11:53 DEBUG: selecting org.openembedded.dev/packages/glibc/glibc- Feb 04 15:11:55 intermediate_2.5.bb as PREFERRED_VERSION 2.5 of package Feb 04 15:12:03 glibc-intermediate Feb 04 15:12:08 and then it says Feb 04 15:12:19 that it is selecting glibc_2.3.5+cvs20051107.bb to satisfy virtual/mipsel-linux-libc-for-gcc Feb 04 15:12:20 hmm Feb 04 15:12:25 who sets that dependency? Feb 04 15:13:02 Jin^eLD: This all comes down to NPTL and whether you need an intermediate gcc or not... Feb 04 15:13:13 sorry, an intermediate glibc Feb 04 15:13:24 aha.. so.. do I? :) lets assume I build with nptl Feb 04 15:13:36 yes, you would for nptl Feb 04 15:14:04 but something makes bitbake think glibc 2.5 can't work for mipsel so it chooses 2.3.5 Feb 04 15:14:41 its all down to which glibc packages provide virtual/mipsel-linux-libc-for-gcc Feb 04 15:14:59 aha.. ok.. that is starting to make more sense now Feb 04 15:15:42 is there a way to figure out which package provides that? Feb 04 15:16:12 the 2.5.bb has something about it Feb 04 15:16:47 Jin^eLD: bitbake -b glibc-2.5.bb -e | grep PROVIDES might help Feb 04 15:17:19 I think I found it.. Feb 04 15:17:25 its indeed nptl related Feb 04 15:18:41 can you take a look please: http://www.deadlock.dhs.org/jin/glibc-provides.txt Feb 04 15:19:03 that is looking for nptl in GLIBC_ADDONS, right? Feb 04 15:19:20 yes Feb 04 15:19:27 the .bb file has GLIBC_ADDONS ?= "ports,nptl,libidn" and I am not overriding it anywhere Feb 04 15:19:59 so either someone along the way is setting GLIBC_ADDONS so the ?= does not get triggered, or I don't know.. Feb 04 15:20:30 Did you check the variable with bitbake -e? Feb 04 15:21:09 uhm.. no, I poked around with -i in the shell but was not quite successful Feb 04 15:21:37 03koen 07org.oe.dev * re1bf125b... 10/ (18 files in 3 dirs): glib: add 2.12.9 and remove unused versions Feb 04 15:21:43 03ifaistos 07org.oe.dev * r7a70501f... 10/ (1 conf/machine/dht-walnut.conf): dht-walnut.conf: Add ppc405 are package arch Feb 04 15:21:49 I'd make 100% sure you know what the problem is - check the actual values of PROVIDES and GLIBC_ADDONS Feb 04 15:21:50 03ifaistos 07org.oe.dev * r68b3ed44... 10/ (1 packages/uboot/u-boot-1.1.4/u-boot-dht-walnut-df2.patch): Add missing uboot patch for dht-walnut Feb 04 15:21:56 03koen 07org.oe.dev * ra7590ede... 10/ (1 conf/machine/dht-walnut.conf): dht-walnut: use PACKAGE_EXTRA_ARCHS instead of overwriting PACKAGE_ARCHS Feb 04 15:22:02 03koen 07org.oe.dev * r9fc82b6e... 10/ (1 conf/distro/angstrom-2007.1.conf): angstrom: add mipsel support Feb 04 15:22:30 so its enough to simply do bitbake -e and grep for the var? I was fiddling with -i yesterday because I thought that the .bb needs to get parsed first Feb 04 15:22:42 just doing a bitbake -e | grep GLIBC_ADDONS does not return anything Feb 04 15:22:53 You need -b with -e for it to make sense, as I hinted above Feb 04 15:23:07 oh crap I must have missed the -b part, sorry Feb 04 15:25:33 uhm.. bitbake -b glibc_2.5.bb but when adding -e it says file not found Feb 04 15:25:38 what am I doing wrong? Feb 04 15:25:53 aem.. just -b works but with -b and -e it says file not found Feb 04 15:28:26 would peek glibc-2.5 GLIBC_ADDONS in the shell do the same thing? Feb 04 15:28:38 if yes it returns correct values Feb 04 15:29:07 hmm, but getvar returns None :) Feb 04 15:29:11 * Jin^eLD is quite confused :> Feb 04 15:37:13 hmm, setting the addons in the distro config file using "=" or in the glibc_2.5.bb file does not seem to help Feb 04 15:38:51 hmm someone is saying that an additional runtime dependency to virtual/mipsel-linux-libc-for-gcc is glibc 2.3.5 Feb 04 15:38:58 I guess I have to track down this Feb 04 15:39:03 03koen 07org.oe.dev * r79a8fbec... 10/ (4 files in 3 dirs): pulseaudio: create pulse user and create /var/run/pulse via volatiles Feb 04 15:42:36 is it possible to hand https auth credentials to the svn fetcher? Feb 04 15:43:00 mickey|tv: it should work if they're specified as part of the SRC_URI Feb 04 15:43:01 mickey|tv: 'yes | ' Feb 04 15:43:14 in case it has bad certs as well Feb 04 15:43:27 RP: how exactly? Feb 04 15:43:33 i tried user:pass@svn.... Feb 04 15:43:37 but that wasn't honored Feb 04 15:43:37 mickey|tv: which bitbake? Feb 04 15:43:43 1.6.2 Feb 04 15:43:52 koen: is there a "proper" way to add/remove users in OE yet? Feb 04 15:44:00 mickey|tv: I think there are patches in the bugtracker for 1.6. It should work in trunk Feb 04 15:44:14 NAiL: the most proper one is in the quagga recipe Feb 04 15:44:16 NAiL: no. I have been encouraging folks to add a useradd.bbclass Feb 04 15:44:20 but nothing happend yet Feb 04 15:44:35 RP: ok, i'll have a look, thanks Feb 04 15:44:38 mickey|tv: I was supposed to. But the python stuff is beyond me :-P Feb 04 15:44:40 * RP would like to see a class too... Feb 04 15:44:45 koen: ok, I'll look at that. Feb 04 15:44:51 NAiL: it doesn't need to be python Feb 04 15:44:56 you can add shell tasks as well Feb 04 15:45:18 if were all python I wouldn't be a OE developer :) Feb 04 15:45:28 s/if/if it/ Feb 04 15:45:30 hehe Feb 04 15:45:45 I didn't know much python before bitbake.. Feb 04 15:46:24 * RP appears to be refactoring runQueue again :-/ Feb 04 15:46:25 mickey|tv: http://www.flickr.com/photos/koenkooi/379165991/ <- find the hint :) Feb 04 15:46:32 hehe Feb 04 15:46:38 seen that in #openmoko Feb 04 15:46:39 Not actually changing the code, just rearranging it... Feb 04 15:46:40 nice tags Feb 04 15:46:48 mickey|tv, I think hrw|gone added svn username support to dev bitbake? Feb 04 15:46:54 did he? Feb 04 15:46:58 mickey|tv: move your mouse over the picture Feb 04 15:47:05 pretty certain Feb 04 15:47:16 I had some recipes that depended on it, and they annoyed him :) Feb 04 15:47:18 koen: yeah. didn't knew that flickr can indicate hotspots Feb 04 15:47:33 * mickey|tv grabs trunk svn fetcher Feb 04 15:47:52 I refactored the fetchers in trunk and we got user/passwd support for svn nearly for free Feb 04 15:48:09 1.6 is a lot different as it hasn't had the refactor Feb 04 15:49:41 mickey|tv, http://bugs.openembedded.org/show_bug.cgi?id=1781 Feb 04 15:49:58 oh cool Feb 04 15:49:58 thanks Feb 04 15:50:23 hmm Feb 04 15:51:01 did we have a 1.6.x release since that went in? Feb 04 15:51:11 Has it gone in? Feb 04 15:51:20 I don't know about that Feb 04 15:51:29 Patch pushed also into bitbake 1.6 branch. Tested on svn:// anonymous and Feb 04 15:51:29 https:// with user/pass provided in SRC_URI. Feb 04 15:51:32 according to herw Feb 04 15:51:33 hrw, even Feb 04 15:51:57 might be a chance for a subrelease Feb 04 15:52:05 I though it was waiting on testing and then was to go in Feb 04 15:52:12 We could use a new release... Feb 04 15:52:22 * mickey|tv points to zecke Feb 04 15:52:32 zecke is probably too busy Feb 04 15:53:14 I'd check with hrw where we're at with it, I think there were a couple of other bugs outstanding then we'd roll one... Feb 04 15:53:14 * zecke hides Feb 04 15:53:39 mickey|tv: Is there a nice way to retrive the last 100 lines of a log file in python? Feb 04 15:53:53 RP: in a fast way? Feb 04 15:53:59 zecke: yes Feb 04 15:54:06 i don't know any offhand Feb 04 15:54:10 file.readall()[-100:] but I wonder how fast that is Feb 04 15:54:11 That is one of the outstanding issues, I don't like an os.system call... Feb 04 15:54:22 (and it will break my UI plans) Feb 04 15:54:35 There are some bugs open with my comments in... Feb 04 15:54:43 #97 iirc Feb 04 15:55:55 to be honest, i'd be ok with it being a rough estimate Feb 04 15:56:04 e.g. you just seek to 100*80 Feb 04 15:56:06 or so Feb 04 15:56:15 (from the end of the log) Feb 04 15:56:25 i don't think we can afford doing readall Feb 04 15:57:07 mickey|tv: Even with a seek to end say minus 500kb then running readall? Feb 04 15:58:09 I am planning to thow this to the UIs to deal with anyway - they'll just get a pointer to the logfile filename... Feb 04 15:58:24 mickey|tv: I wouldn't have thought readall() would be that slow. Presumably python will mmap() big files when you do that, and the chances are the log will be in the page cache anyway, so it's basically just a question of searching for the line endings. Unless your log file is very very big that doesn't sound like it ought to be a massive deal. Feb 04 15:59:04 pb_: question is how it convers the string :) Feb 04 15:59:09 well, or if your computer is very slow, but in that case you are probably SOL with bitbake in the first place Feb 04 15:59:15 pb_: even if it mmaps, it might do a strcpy :} Feb 04 15:59:31 (preferably memcpy or strncpy) Feb 04 16:00:18 I guess it would have to memcpy the output, but you can memcpy at something approaching a gigabyte a second on commodity hardware nowadays. Feb 04 16:01:51 pb_: I suspect python will do the following: fstat, malloc, memcpy into internal string :) Feb 04 16:02:23 RP: but readlines should be reasonable fast, and if it implements the iter interface/protocol mickeyl might have a comment about how good that is... Feb 04 16:02:34 anyway back to Windows Mobile :} Feb 04 16:03:57 readlines implements the iter interface but it can't tell you in advance how many lines there are which is the problem. You could read into a circular buffer but that seems a little like overkill... Feb 04 16:13:45 Zero_Chaos: pong? Feb 04 16:14:28 Zero_Chaos: did you add it tot he broken locales in the glibc bb? Feb 04 16:14:31 03koen 07org.oe.dev * r9854932e... 10/ (1 packages/pulseaudio/pulseaudio_0.9.5.bb): pulseaudio: fix do_install Feb 04 16:28:15 koen: DEBUG: Removing failed build target gpe-conf Feb 04 16:28:18 ERROR: No buildable providers available for required build target gpe-conf Feb 04 16:28:36 koen: could this be due to some pulseaudio upgrade? Feb 04 16:28:45 it shouldn't be Feb 04 16:28:53 I did replace esound-gpe with proper esound Feb 04 16:29:29 * koen bitbake gpe-conf Feb 04 16:31:23 koen: bitbake esound fails here, I'll remove my cache to be sure. Feb 04 16:35:31 NOTE: package gpe-conf-0.2.3: completed Feb 04 16:36:56 koen: maybe you have already built pulseaudio? the problem might be PREFERRED_VERSION_esound = "pulseaudio" but pulseaudio doesn't PROVIDE esound. Feb 04 16:37:25 03koen 07org.oe.dev * r10bce4f0... 10/ (1 packages/esound/esound_0.2.36.bb): esound: actually add it Feb 04 16:40:42 ah :) thanks Feb 04 17:05:58 i'd like to specify a custom parameter to the ./configure call. how could i do that easily ? Feb 04 17:06:27 EXTRA_OECONF = "--with-my-param" Feb 04 17:06:44 aha, thanks Feb 04 17:18:55 later :) Feb 04 18:49:10 hi all, some here will be on FOSDEM and present at OE booth/stand ??? Feb 04 19:05:27 koen: how about splitting out the libraries from eds-dbus like this: http://en.pastebin.ca/340416 Feb 04 19:06:01 pH5: that looks a lot like what I'm typing in vi now :) Feb 04 19:06:39 koen: then it can't be all wrong :) Feb 04 19:06:44 :) Feb 04 19:06:50 feel free to commit that Feb 04 19:10:03 ok Feb 04 19:12:24 03pH5 07org.oe.dev * r86d8dfc8... 10/ (1 packages/eds/eds-dbus_svn.bb): eds-dbus: split out libraries in separate packages Feb 04 19:14:30 pH5: could you bump PR as well? Feb 04 19:15:05 koen: yeah, that might turn out to be a good idea Feb 04 19:19:40 03pH5 07org.oe.dev * r371347ae... 10/ (1 packages/eds/eds-dbus_svn.bb): eds-dbus: bump PR Feb 04 19:23:18 somebody please look at bug 1846 Feb 04 19:27:44 03koen 07org.oe.dev * r355cafb7... 10/ (1 packages/eds/eds-dbus_svn.bb): eds-dbus: really bump PR :) Feb 04 21:41:04 03rwhitby 07org.oe.dev * ra4f1af86... 10/ (1 packages/linphone/linphone_1.6.0.bb): linphone: removed default_preference=-1 from the 1.6.0 console-only version Feb 04 21:41:08 03rwhitby 07org.oe.dev * reba77e76... 10/ (4 files in 2 dirs): ixp4xx-kernel: Updated to 2.6.20 Feb 04 21:41:12 03rwhitby 07org.oe.dev * rd7d5cb09... 10/ (1 conf/distro/include/slugos.inc): slugos.inc: Update to 2.6.20 Feb 04 22:12:28 please somebody look at bug 1846 it is update to Palm Zire 72 support Feb 05 02:02:56 JustinP: I added it to broken_locales however that will not solve this issue because that is used during install and for some reason my issue is during packing, before install **** ENDING LOGGING AT Mon Feb 05 02:59:57 2007