**** BEGIN LOGGING AT Mon Oct 17 02:59:57 2011 Oct 17 06:46:14 good morning Oct 17 08:08:07 morning all Oct 17 08:10:22 morning all Oct 17 08:11:26 hi RP__ Oct 17 09:43:04 RP__: I have some doubts about a couple of default preferred providers: PREFERRED_PROVIDER_virtual/libx11 and PREFERRED_PROVIDER_virtual/libgl Oct 17 09:43:30 JaMa|Off: ^^ Oct 17 09:43:51 it seems libx11-trim is still 'special' https://lists.yoctoproject.org/pipermail/poky/2011-July/006800.html Oct 17 09:46:14 and about gl, last I've read is 'use mesa-dri with xserver-xorg and mesa-xlib whit xserver-xorg-lite' Oct 17 11:08:38 ant_work: So what are you proposing/asking? Oct 17 11:12:26 I'm asking what is the foreseen approach for 'defaults' then how to circumvent it if it doesn't fit well for meta-handheld Oct 17 11:16:16 specifically, is there any gain using the -trim and/or -lite versions? Oct 17 11:21:42 in fact, using 'defaults' (xserver-xorg, mesa-dri, libx11-trim) I'm not too far http://paste.debian.net/137190/ Oct 17 11:29:13 ant_work: trim is smaller that full libx11 and with -lite you don't get Xgl Oct 17 11:32:34 I really don't know what the best trade-off would be for e.g. Zaurus and Ipaq's, missing a dedicated dri Oct 17 11:33:01 now that core-image-sato boots I'll do some tests Oct 17 12:30:52 ant_work: The dri swrast backend will work but it will be slow Oct 17 12:30:56 ant_work: probably not much use Oct 17 12:35:50 so maybe Xlib will be faster than dri+swrast Oct 17 12:36:17 well, s/faster/less slow/ Oct 17 12:37:45 ant_work: https://gitorious.org/shr/meta-handheld/commit/d3793e1c2e7b28ce798a6ca1c253bfca05a462b7 Oct 17 12:38:00 ant_work: but I haven't tried to benchmark it.. Oct 17 12:39:16 does calibration work w/out xcb? Oct 17 12:39:51 there was some problem iirc Oct 17 12:43:31 imho it does, but I have libx11 with xcb for quite some time Oct 17 12:45:14 ant_work: I think we fixed those calibration issues in oe-core a while ago Oct 17 12:49:29 RP__: for evdev? Oct 17 12:50:04 JaMa|Off: The xcb issues causing problems with xcalibrate Oct 17 12:52:25 RP__: I think we have some kernel-related calibration issues also; that's outside the scope of oe-core though Oct 17 12:52:46 bluelightning: hmm, right :/ Oct 17 13:05:00 JaMa|Off: what's PREFERRED_PROVIDER_virtual/xserver-xf86 for? Oct 17 13:08:28 ant_work: it was used ie in xorg-driver/ but now it's deprecated and I'm setting virtual/xserver only Oct 17 13:08:42 ok, thx Oct 17 13:09:35 JaMa|Off: last thing for you..have you noticed the kernel modules no-autoload? Oct 17 13:10:14 is there any distro-magic glue I'm missing building with defaults? Oct 17 13:11:28 ant_work: do you have syslog-ng? it breaks update-modules Oct 17 13:11:48 or recheck you have right -/_ in modules_autoload_kernel-module.. Oct 17 13:12:07 I have whatever is default Oct 17 13:12:11 it needs to be exactly the same as module filename -/_ Oct 17 13:12:22 default where? Oct 17 13:12:30 in oe-core + meta-oe Oct 17 13:13:06 I see e.g. rtc is not loaded Oct 17 13:13:39 rtc is imho not autoloadded by default Oct 17 13:14:24 ant_work: read comment in http://git.shr-project.org/git/?p=meta-smartphone.git;a=blobdiff;f=meta-openmoko/conf/machine/om-gta02.conf;h=ddf4221519b8cf67ee6874fff6adc385ae7973bc;hp=0a16f5ea7b86c572818f75fba9ad0ca90ef34dcc;hb=c920280084606e60935ea0c71aa3bad649a90eec;hpb=6e5877d48ae5e910498f5fda10aa14349c55cb17 and recheck syslog-ng Oct 17 13:15:02 and for syslog-ng you can use http://git.openembedded.org/meta-openembedded-contrib/commit/?h=jansa/test&id=86a260a0399df34db6a97cc5adfc77423ec66693 to fix it Oct 17 13:19:29 the rtc are listed here: http://cgit.openembedded.org/meta-openembedded/tree/meta-oe/classes/kernel.bbclass Oct 17 13:20:38 and you're right, there is only sa1100-rtc remaining Oct 17 13:24:08 all should be managed by udev as default Oct 17 13:51:21 RP__: I've noticed the initramfs images usually do export IMAGE_BASENAME. Well, it seems working ok w/out exporting it. What's the reason for it? Oct 17 13:53:00 ant_work: I'm not using udev on spitz.. so module_autoload is still usefull for people like me Oct 17 13:53:20 JaMa|Off: I'll check the underscores ;) Oct 17 13:53:24 ant_work: but you need rtc_pxa Oct 17 13:53:35 long ago was in the autoload list Oct 17 13:53:55 both sa1100 and pxa rtc's Oct 17 13:54:23 in oe-classic it was working just fine Oct 17 13:55:08 ant_work: both with dash.. Oct 17 13:55:08 /lib/modules/3.1.0-rc8/kernel/drivers/rtc/rtc-sa1100.ko Oct 17 13:55:08 /lib/modules/3.1.0-rc8/kernel/drivers/rtc/rtc-pxa.ko Oct 17 13:55:25 ok ;) Oct 17 13:56:56 ant_work: and you have to add it to MACHINE_EXTRA_RDEPENDS and bump PR in task- to get it installed in image by default Oct 17 13:57:21 the list in zaurus.conf need double checks Oct 17 14:28:24 ant_work: probably historical for bbimage when we used to use that script Oct 17 14:29:54 ok, initramfs-kexecboot-image is very well tested and doesn't export that. thx for confirming Oct 17 14:50:54 bluelightning: hi, some time for plasma active? Oct 17 14:51:26 mdfe_: I haven't yet, but I have asked for a git repo to be created Oct 17 14:52:40 bluelightning: please let me know when we have a repo :) Oct 17 14:53:39 bluelightning: I'm trying to package some dependenies of plasma active in an own layer at the moment Oct 17 14:54:11 mdfe_: ah ok, how far did you get? Oct 17 14:54:47 bluelightning: sadly not far, but by now I have the time to come in Oct 17 14:55:55 bluelightning: I'm packaging the 'raptor2' package at the moment, but the tarball fetching does not work Oct 17 14:56:16 mdfe_: could you pastebin the recipe? maybe I can help with that Oct 17 14:56:41 bluelightning: that would be greate, mom Oct 17 14:58:31 bluelightning: http://pastebin.com/yjtBwqGx Oct 17 14:59:32 bluelightning: line 20 was just a try... Oct 17 15:01:54 mdfe_: ah yes, you don't need to do that Oct 17 15:02:38 also you can drop the PRIORITY = and PV = lines Oct 17 15:02:50 they aren't doing any harm but also aren't serving any purpose FYI Oct 17 15:03:37 ok Oct 17 15:05:12 mdfe_: looks pretty much OK otherwise, I'm not sure why it wouldn't fetch Oct 17 15:05:29 But I do not understand why bitbake try to validate an lincense file without previous fetching Oct 17 15:05:35 mdfe_: presumably the md5sum/sha256sum are definitly correct? Oct 17 15:05:35 http://pastebin.com/GDEiSfe4 Oct 17 15:06:15 bluelightning: I checked it twice, but I cannot find the tarball inside download directory Oct 17 15:08:08 mdfe_: well, checking LIC_FILES_CHKSUM at configure is normal Oct 17 15:08:45 bluelightning: Ok, but I think the source tarball is still missing Oct 17 15:08:56 mdfe_: could you try removing the do_fetch line then "bitbake -c clean raptor2" then "bitbake raptor2" ? Oct 17 15:10:11 bluelightning: awesome :) Oct 17 15:10:35 mdfe_: that worked? Oct 17 15:10:46 bluelightning: greate thanks for the hint with 'bitbake -c clean raptor2' Oct 17 15:10:55 bluelightning: yep :) Oct 17 15:11:31 ah right... I suspect that do_fetch line actually resulted in overriding the fetch task to do nothing, which would explain why nothing got fetched :) Oct 17 15:13:22 mdfe_: some other comments: Oct 17 15:13:32 1) you should prepend to PACKAGES Oct 17 15:13:46 i.e. PACKAGES =+ "${PN}-utils" Oct 17 15:14:14 rather than overriding the whole thing (also you have ${PN} twice which it will complain about I believe) Oct 17 15:14:53 also line 44 in that pastebin needs to start with FILES_${PN}, not just ${PN} Oct 17 15:16:00 bluelightning: I will overhaul this recipe Oct 17 15:16:42 bluelightning: maybe you can take a second look when I have finished? Oct 17 15:16:50 mdfe_: sure thing Oct 17 15:17:04 mdfe_: also, I think you'll find the .so and .h files in ${PN}-dev should be included in that package already Oct 17 15:18:01 mdfe_: I think also the line 44 I refered to earlier may in fact be unnecessary as well Oct 17 16:59:10 bluelightning: http://pastebin.com/ZXmLEbTm but some QA scripts are still screaming about packaging Oct 17 17:01:38 bluelightning: I prefer to package raptor2 but sadly the 'configure' breaks on error Oct 17 17:02:11 bluelightning: http://pastebin.com/yjtBwqGx with raptor2 related files and output Oct 17 17:03:20 bluelightning: sorry outdated paste, this one ist raptor2 http://pastebin.com/k5NMrRnK Oct 17 17:06:16 mdfe_: I would revise your packaging as follows: http://pastebin.com/h4TUMZ8C Oct 17 17:06:38 (I now understand what you were attempting to do, my advice on prepending for PACKAGES was incorrect) Oct 17 17:08:12 mdfe_: as for the raptor2 error, it doesn't make sense :( Oct 17 17:09:47 bluelightning: just removing the '+' in PACKAGES line? Oct 17 17:10:04 mdfe_: and tidying up the FILES_ lines Oct 17 17:10:12 there are redundant items in there Oct 17 17:11:32 mdfe_: FYI you can find the default values for these variables in meta/conf/bitbake.conf if you haven't seen it already Oct 17 17:12:16 bluelightning: thanks, I'm taking a look Oct 17 17:20:39 bluelightning: thanks for your help, the first steps with an new build system are not easy Oct 17 17:21:46 mdfe_: no problem... I hope we can find a solution to the raptor2 issue Oct 17 17:22:34 mdfe_: it's worth having a look at the actual configure check being done Oct 17 17:24:13 bluelightning: I will investigate some time in raptor2 from home office, maybe there is an patch available Oct 17 17:27:20 bluelightning: Is the 'autotools' entry at 'inherit' mandatory? Oct 17 17:27:54 mdfe_: only if the application uses autotools to build Oct 17 17:28:19 mdfe_: FYI "inherit" is a directive to inherit from a bbclass (found in meta/classes/) Oct 17 17:28:33 autotools.bbclass is one class we have Oct 17 17:29:00 bluelightning: Does bitbake needs every time autoreconf? Oct 17 17:29:15 in case of configure Oct 17 17:29:53 mdfe_: I know in autotools.bbclass it does do an autoreconf, I believe there are good reasons for doing that Oct 17 17:30:17 bluelightning: because it is a plain unpatched configure Oct 17 17:30:24 bluelightning: ok Oct 17 17:30:51 mdfe_: you might be able to get away with not using autotools.bbclass in that case, I'm not sure Oct 17 17:31:55 bluelightning: I will try it tomorrow, its late going home now Oct 17 17:32:24 mdfe_: ok, I'll be around tomorrow if you need anything else Oct 17 17:32:39 bluelightning: thanks! :) Oct 17 18:06:28 dvhart: not sure if you saw my (very late) email reply but still see the beagleboard ghosting Oct 17 18:06:53 also, do you know the status of pandaboard support? I see some branches related to it but no build instructions Oct 17 18:08:49 jefferai, hi, sorry I haven't responded Oct 17 18:09:06 I'm running around like a headless chicken preparing for a couple presentations :) Oct 17 18:09:20 Unfortunately about the Rev C, we'll have to address that in 1.2 Oct 17 18:09:32 dvhart: no, no problem Oct 17 18:09:37 As for the pandaboard, I believe zeddii will be able to answer that one Oct 17 18:09:43 jefferai, and thanks for testing! Oct 17 18:09:50 just making sure it didn't get lost up in your email, since the thread was so long ago Oct 17 18:10:17 sure Oct 17 18:16:41 right, understood - thanks :) Oct 17 18:47:30 dvhart: This username reduction business - are you ok to try an experiment to see if I can make this work? Oct 17 18:47:45 RP__, sure Oct 17 18:47:52 RP__, if it's a big deal it can wait too Oct 17 18:48:12 dvhart: Having to host our repos on somebody elses server isn't something I'm happy about Oct 17 18:48:21 :) Oct 17 18:53:29 RP__, just let me know if you want me to try something Oct 17 18:56:00 dvhart: Can you see if you can still push please Oct 17 18:56:52 $ ssh git@git.yoctoproject.org Oct 17 18:56:52 Permission denied (publickey). Oct 17 18:57:13 that's an adequate test I take it? Oct 17 18:57:49 as that used to report my read/write perms across all the repositories Oct 17 18:59:20 dvhart: yes Oct 17 18:59:48 dvhart: My big worry is the system becomming unmaintainable if we can't identify users easily :/ Oct 17 19:00:22 meaning you would prefer to use the longer name? Oct 17 19:00:56 from the announcement I thought the shorter was expected, if the longer is the policy, I can work with that. Oct 17 19:01:04 it's just pretty non-standard Oct 17 19:01:17 but you really only type it once when you add the remote - makes for a weird URL though Oct 17 19:02:40 dvhart: ok, try again now? Oct 17 19:03:08 dvhart: We have to track the users internally by this name within gitolite and we can't associate more information with users easily Oct 17 19:03:16 perms report looks right Oct 17 19:03:20 dvhart: I agree its too long and looks ugly Oct 17 19:03:58 wonder how kernel.org decided to go about it Oct 17 19:04:03 they should have the same problem now Oct 17 19:04:28 perhaps an opty to share infrastructure... Oct 17 19:04:45 dvhart: They have full shell user accounts Oct 17 19:04:57 well.... I don't Oct 17 19:05:02 which is a different set of problems Oct 17 19:05:12 dvhart: your account is a full shell account even if you can't ssh in Oct 17 19:05:19 ok Oct 17 19:05:25 * RP__ talked to warthog about this Oct 17 19:06:57 I thought my gitolite commands used a different userid, which is why I thought I didn't have a real account. I didn't hear otherwise, just assumed. Oct 17 19:08:38 * dvhart needs a better means of timing qemu boot time Oct 17 19:08:51 my human latency is not at the 30% of total boot time range :/ Oct 17 19:08:57 s/not/now/ Oct 17 19:15:07 dvhart: kernel.org doesn't use gitolite (or didn't) Oct 17 19:15:15 it does now Oct 17 19:15:32 dvhart: can't say I'm surprised :/ Oct 17 19:15:38 and we access it using gitolite@ra.kernel.org Oct 17 19:15:56 that's why I suggested they faced a similar problem Oct 17 19:16:45 dvhart: This might get some issues with gitolite fixed ;-) Oct 17 19:17:15 yeah, those kernel guys, always the squeaky wheels ;) Oct 17 20:44:59 would I expect bitbale -c clean linux-... and bitbake linux-... to rebuild the kernel? Oct 17 20:45:33 Crofton|work: -c cleansstate Oct 17 20:45:55 ah Oct 17 20:46:25 this wouild explain things being seriously annoying today Oct 17 21:26:45 sgw: Unable to fetch URL ftp://ftp.isc.org/isc/bind9/9.8.1/bind-9.8.1.tar.gz from any source Oct 17 21:38:52 khem: it should be on the autobuilder.yoctoproject.org for sure (I just checked), looks like that bind9 directory is missing more than 9.8.1, it's missing the 9.7* directories also. Oct 17 21:39:46 khem so something is going on at isc.org, I would suggest pinging them somehow. Oct 17 21:57:12 dvhart: RP__: FWIW, I'm one of the architects of KDE's Gitolite installation, which is one of the most complex out there, and has driven a lot of Gitolite development Oct 17 21:57:28 I offered to two different kernel.org guys that came sniffing around to help them out with their deployment Oct 17 21:57:31 never heard back though Oct 17 21:57:41 my understanding is they didn't talk to the Gitolite author (sitram) either Oct 17 21:58:10 so if their installation isn't optimal, I'm not surprised Oct 17 21:58:58 that said, I know that people at e.g. Oracle and Red Hat and so had their hands dipped in there, so maybe too much was done by committee instead of talking to people with experience Oct 17 22:02:44 jefferai: Just to be clear, I know nothing of k.org's gitolite setup, only yoctos Oct 17 22:03:52 ah, sorry -- I think I missed the difference above, kernel.org URL posted once and yoctoproject URL posted once Oct 17 22:04:02 RP__: what issues are you having that you hope will get fixed? Oct 17 22:07:35 jefferai: Looking at the situation, I think my problems are at the cgit level now :/ Oct 17 22:07:45 Just need to update the gitolite install Oct 17 22:08:11 (to get the better description/owner control) Oct 17 22:11:34 RP__: better? I'm not aware of recent changes Oct 17 22:51:40 bah, new disk stats bits break on some machines, and the code doesn't even bother to check Oct 17 22:53:44 * kergoth_ blows it away in a later layer, since its inherited by base.bbclass, not one of the inherit variables (why exactly is there no way to disable the build performance testing?) Oct 18 00:13:51 woo-hoo! Oct 18 00:13:59 * zenlinux_laptop dances his new release jig Oct 18 00:20:24 * pidge dances her way home and to a cold beer. **** ENDING LOGGING AT Tue Oct 18 02:59:57 2011