**** BEGIN LOGGING AT Thu Nov 03 02:59:59 2011 Nov 03 09:01:48 is the git repo down or did the url change somehow? Nov 03 09:10:00 hi Nov 03 09:11:37 how can i force bitbake to build a native package in oe-core ( f.eks autoconf-native ) ? Nov 03 09:12:58 pwgen: i'd try bitbake autoconf-native Nov 03 09:14:18 ok, mz problem seems a little bit deeper. i want to build core-image-sato for efika, this will build gcc 4.5, and this requires autoconf 2.64 .. Nov 03 09:14:33 oh, so it's just all the oe.net repos that ceased to work, the oe.org one does work.. Nov 03 09:15:07 i have now a recipe for autoconf 2.64 but how can i now clean autoconf 2.68 and build autoconf 2.64 ? Nov 03 09:15:44 .. as native package . i could autoconf 2.64 as arm target .. Nov 03 09:15:57 .. as native package . i could build autoconf 2.64 as arm target .. Nov 03 09:16:43 is there a special bitbake target , like -c cleansstate for building a -native package ? Nov 03 09:18:02 pwgen: i guess that you would have to for i in PREFERRED_VERSION_autoconf{,-native} ; do echo $i = \"2.64\";done >> conf/local.conf Nov 03 09:19:56 hi, all! Nov 03 09:20:12 it seems that iproute2 build is broken Nov 03 09:21:13 http://pastebin.com/Mzzmd28i Nov 03 09:22:30 What is xtables thing anyway? Nov 03 09:25:08 ah, see, so I need to revert de034bf830bec1b64260ac8516dd584163716ef4 in openembedded-core to fix it locally Nov 03 09:54:15 mornin Nov 03 09:58:40 mhm....-core/scripts/bitbake: line 73: /pseudodone: Permission denied Nov 03 09:59:45 i don't like that new thing. Where are the days when i could just use bitbake :P Nov 03 10:03:05 blindvt`: I think your paths are messed up... Nov 03 10:14:21 is there a current equivalent or replacement to PREFERRED_BINUTILS="git" / PREFERRED_UCLIBC_VERSION / PREFERRED_GCC_VERSION ? Nov 03 10:14:36 (in oe-core) Nov 03 10:16:12 blindvt`: yes there is see default-tcmode.inc for variable names Nov 03 10:16:29 or tcmode-default.inc Nov 03 10:17:13 JaMa|Wrk: excellent. Thanks! Nov 03 10:18:07 is my git write-access i had for oe supposed to still work for oe-core? Nov 03 10:18:28 you mean oe-core-contrib right? ;) Nov 03 10:18:34 JaMa|Wrk: I lost track..I've seen some xuser related patches. Unfortunately xserver from meta-oe still shuts down immediately after start Nov 03 10:18:58 yes you're lost there is no xserver in meta-oe Nov 03 10:19:26 ;) X server Nov 03 10:19:30 JaMa|Wrk: oe-core-contrib? I mean openembedded-core AFAICS Nov 03 10:21:24 JaMa|Wrk: I meant the xserver-nodm-init: Use useradd to add the xuser for rootless X Nov 03 10:21:29 blindvt`: oe-core is pull based Nov 03 10:21:59 i see. So please sed -i -e s/PREFERRED_VERSIONS/PREFERRED_VERSION/ meta/classes/base.bbclass && git commit -s -m 'base.bbclass: Commentary typo fix' meta/classes/base.bbclass Nov 03 10:22:00 blindvt`: and oe-core-contrib is usefull to push feature branches and then send pull requests Nov 03 10:22:05 TIA ;) Nov 03 10:23:29 ant_work: we're not using xuser in meta-oe yet Nov 03 10:25:00 JaMa|Wrk: ok, i've seen sgw is working about rootless X Nov 03 10:25:41 hmm, and? Nov 03 10:26:11 xserver-nodm-init from meta-oe works fine Nov 03 10:26:57 no, it pulls xserver-common which is not clean Nov 03 10:28:19 what you mean by clean? Nov 03 10:28:53 first, there are lot of extraneus machine settings Nov 03 10:29:27 second, X shuts down after start Nov 03 10:29:37 we've already talked about dropping xserver-common and replacing it with x11-common Nov 03 10:29:49 yes, I thought the issue was rootless x Nov 03 10:30:00 that's why I'm asking Nov 03 10:30:11 and second here it works if it shuts down after start, then you have to provide more info Nov 03 10:30:44 and now you can replace xserver-nodm-init with elsa and xserver-common x11-common by defining right VIRTUAL_RUNTIME values Nov 03 10:30:49 btw x11-common ignores xinput-calibrator Nov 03 10:31:03 do you think I don't know that? ;) Nov 03 10:31:07 :p Nov 03 10:31:34 see, once done with udev merge I'd like to attack this X stuff ;) Nov 03 10:32:35 we are really near to have properly booting images built on the top of oe-core Nov 03 10:58:36 good morning Nov 03 13:13:49 I have a package that fails on do_install, but when i manually run 'run.do_install*' it works. How can I tell OE that I already installed it and needs to skip that action? Nov 03 13:31:19 jordz: I would suggest the correct approach would be to fix it so that do_install works, rather than hacking around it... Nov 03 13:38:00 I see that some .bbappend recipes use a PRINC setting, although the parent recipe does not have an include, is PRINC something that will be treated in a special way, similar to how it was done when .inc files were defining their INC_PR and the main recipe was doing something like PR = "r1.${INC_PR}" ? Nov 03 13:41:29 bluelightning: i can't find the problem, it calls a make install which with bitbake it complains about an unknown directoy, but manually it doesn't Nov 03 13:43:09 jordz: which version of OE are you building? Nov 03 13:44:18 and how can a .bbappend "uninherit" a class? Nov 03 13:46:39 bluelightning: im using angstrom, it pulled the new oe-core Nov 03 13:47:45 jordz: right, it could be an issue with parallel make install; try setting PARALLEL_MAKEINST = "" in the recipe Nov 03 13:48:35 Jin^eLD: PRINC just adds the value to the numerical value of PR, so if PRINC = "1" then PR = "r1" becomes "r2" after the append Nov 03 13:48:48 oh ok, I get it Nov 03 13:48:50 thanks Nov 03 13:48:54 Jin^eLD: you can't "uninherit"; what are you attempting to do? Nov 03 13:49:05 I am attempting to remove update-rc.d from the inherit list Nov 03 13:49:29 hmm.. Nov 03 13:49:48 Jin^eLD: perhaps in that specific case it would be enough to just clear the INITSCRIPT* variables? Nov 03 13:49:57 within the bbappend Nov 03 13:50:04 I could try that... Nov 03 13:50:43 bluelightning: thanks ill try that Nov 03 13:50:54 bluelightning: thanks for the hints Nov 03 13:52:21 no worries Nov 03 13:59:28 bluelightning: that didn't work Nov 03 14:01:07 bluelightning: if the main recipe already has a do_install_append, how can I append my stuff to it? or do I need to duplicate? Nov 03 14:01:20 i just faked the do_install for now Nov 03 14:01:48 Jin^eLD: you can have as many _appends as you like, either for variables or functions; they just get appended in the order they appear Nov 03 14:02:00 ah, ok Nov 03 14:03:49 On "Angstrom v2011.11-core - Kernel 3.1.0-rc4+" my root user is not allowed to create a pthread with SCHED_RR. Why oh why? Could this be because the given application is compiled wih an old SDK from my OE classic days? Nov 03 14:05:52 anyone built an sdk lately? I get: ERROR: Nothing PROVIDES 'base-passwd-nativesdk' (but virtual:nativesdk:/home/tassle/Source/openembedded/sources/openembedded-core/meta/recipes-core/dbus/dbus_1.4.12.bb DEPENDS on or otherwise requires it) Nov 03 14:08:44 tasslehoff: iirc someone reported that on ML too Nov 03 14:09:51 Jin^eLD: _append and _prepend aren't part of the variable name, they're operations, like .= and =., except that they occur in a more lazy fashion Nov 03 14:12:18 JaMa|Wrk: ok. I'll see if I can dig up the thread. Nov 03 14:12:20 kergoth: I see, thanks.. Nov 03 14:12:35 still working on migration of my oe classic setup to OE core Nov 03 14:13:05 Jin^eLD: the systemd-stuff I struggled with almost solved itself after I did "rm -rf build/*" and rebuilt. Nov 03 14:13:09 fyi Nov 03 14:13:20 tasslehoff: ah, cool, that's nice to know Nov 03 14:13:34 so no hard battle expected there then Nov 03 14:15:07 JaMa|Wrk: found it at http://bugzilla.pokylinux.org/show_bug.cgi?id=1702 Nov 03 14:16:40 Jin^eLD: systemd still throws some errors at me on first boot after upgrade, but networking/dropbear runs, and on later boots there's no complaints. Nov 03 14:17:40 tasslehoff: hmm, I guess I'd have to look into that Nov 03 14:18:03 I'll have to do ensure I can do a working live update from the old rootfs that is already out in the field to the newer one Nov 03 14:18:19 I have to ensure that is :) too much "do"'s ;) Nov 03 14:52:58 Afternoon, Is there a nice, supported, clean way to get at the generic_LICENSE that gets copied into the build dir (well recipe-pr/license-destdir/recipe-name) for a recipe to use it in the LIC_FILES_CHKSUM? Nov 03 15:20:36 what exactly is this? BBCLASSEXTEND = "native" Nov 03 15:20:43 is there a "new way" how to generate native packages? Nov 03 15:20:50 yes Nov 03 15:20:57 is it described anywhere? Nov 03 15:21:17 have you read the yocto / poky documentation? Nov 03 15:21:50 partially, I read a couple of things in the yoctoproject wiki Nov 03 15:21:56 that is the right place to search for further clues? Nov 03 15:22:01 that's not what i'm referring to Nov 03 15:22:18 then I guess I did not Nov 03 15:23:10 are you referring to http://www.yoctoproject.org/documentation? Nov 03 15:23:14 yep Nov 03 15:23:24 ok I'll have a look, thx Nov 03 15:24:18 it's not 100%, but it does cover a fair bit of recent stuff Nov 03 15:24:30 bbclassextend basically generates variants of a recipe by inheriting that class Nov 03 15:25:00 it's a space separated list of classes Nov 03 15:25:03 so if I want a native recipe of xyz.bb I just make sure it has this bbclassextend line? and it will spit out the regular recipes + the native ones? Nov 03 15:25:07 yep Nov 03 15:25:14 cool Nov 03 15:25:46 it is also the mechanism that we use to create multilib variants, etc. Nov 03 15:25:56 be aware, sometimes the dependencies differ Nov 03 15:26:02 what are multilib variants? Nov 03 15:26:13 i386 & x86_64 running on the saame system.. Nov 03 15:26:44 you would need libc for both.. and other components (such as an SQL DB engine) you'd likely was 64-bit. while smaller userspace tooling you might want 32-bit to save space Nov 03 15:27:10 multilibs are used on a lot of large embedded systems, in my experience, primarly networking and back-end data processing Nov 03 15:28:32 hmm, I guess I never came across it Nov 03 15:28:54 if you've ever run an x86_64 desktop, you've seen multilibs in use Nov 03 15:28:56 :) Nov 03 15:29:52 multilibs are more prevelant on MIPS64 and PPC64 systems.. as the 64-bit ABI "wastes" a lot of space for most applications -- but is essential for things like large data stores Nov 03 15:30:19 it's used on IA32 systems, but most users ignore it's presence these days.. as x86_64 only systems are very common.. Nov 03 15:31:05 kergoth: I guess I was just not aware Nov 03 15:31:08 (I expect this will change with the recent work on the new "x32" ABI for IA32/X86_64 platforms... it's a 32-bit ABI that uses the advantages of the x86_64 instruction set. Result is smaller, faster code.. that would leave x86_64 (64-bit) as only needed in the large datastore case again. Nov 03 15:34:08 I was not following the recent developments there, but thanks for the explanation, I have an idea about what it is now Nov 03 15:34:21 I'm able to build a micro image for qemux86 not problem. But for qemuarm I get "ERROR: QA Issue: libcidn rdepends on eglibc-dev" Nov 03 15:37:35 martinambrose: I can't say for sure but I think to remember that no regular package is allowed to tepend on the -dev pacakge? so something is for sure wrong Nov 03 15:38:54 member:identifier:jin%5Eeld: thanks. not sure why the dependency is different for qemux86. Nov 03 15:39:12 Hi, all! Nov 03 15:39:22 slapin: privet! Nov 03 15:39:47 is there bitbake foo -c distclean target in oe-core? to remove checked-out sources Nov 03 15:40:01 martinambrose ya.. definitely an error.. most of the time these errors are related to sonames or incorrect library/links.. Nov 03 15:40:07 the error might be in eglibc on ARM Nov 03 15:41:41 fray: it's related to using the micro distro. building a qemu core-image-minimal works which is also uses eglibc. Nov 03 15:42:24 But ya, the error is reasonable.. -dev usage on the target is bad.. it'll blow up the filesystem size quickly Nov 03 15:42:37 (unless of course someone wants -dev.. but that needs to be a manual choice) Nov 03 15:43:27 agree. I'm just not savvy enough to know where to pinpoint the difference between the two machines. Nov 03 15:44:14 I'd suggest that error be expanded to capture which file caused the dependency --or-- if it came from the recipe itself Nov 03 15:50:12 Does current bitbake master work as expected? I'm seeing unwarranted dependencies being added, like this one: http://paste.debian.net/142359/ Nov 03 15:51:07 something is requiring util-linux-native Nov 03 15:51:14 all of the deps below are specific to util-linux-native Nov 03 15:56:53 martinambrose: the eglibc packaging is broken. I think I have a patch for that somewhere. Nov 03 15:57:53 fray: the sorted providers state that the second alternative is not needed and we indeed add the correct (first) alternative but then happily go on to add the second, redundant, alternative, too Nov 03 15:59:54 looks like libcidn is just in the wrong place in PACKAGES. Nov 03 16:01:36 oh cool. Nov 03 16:01:46 hmm...about packaging, smthg seems wrong with kernel packaging in oe-core. I don't see the /boot/$KERNEL_IMAGETYPE symlink. I inspected the ipks and kernel-xx.ipk is empty. Kernel-base is not built. How did it work back in oe-classic? Nov 03 16:26:18 pb_: thanks for the tip. I changed the order in eglibc-package.inc to libcidn${PKGSUFFIX} ${PN}-dev and it builds/runs. Nov 03 16:26:42 Guess I'll attribute the successful builds with the original order to race conditions. Nov 03 16:27:04 ok, very good **** BEGIN LOGGING AT Thu Nov 03 21:40:18 2011 Nov 03 22:33:14 re Nov 03 22:34:57 florian, can you get into the wiki and git? Nov 03 22:34:59 cgit? Nov 03 22:37:10 ka6sox-away: not yet... no reply from wiki or git so far. Nov 03 22:37:39 okay let me check on opal...thanks Nov 03 22:40:33 i am trying to call "resize" from within a script run in place of init (init=myscript.sh) and it says "resize: can't open terminal /dev/tty" Nov 03 22:41:02 florian, now? Nov 03 22:41:11 gungfuwayne oe context? Nov 03 22:42:08 ka6sox-away: works Nov 03 22:42:44 florian, for next year's budget...1 word....RAM....lots of it. Nov 03 22:43:10 * JaMa|Wrk pushed to oe-core-contrib again, thanks ka6sox-away~ Nov 03 22:43:11 I get a warning about a changed key, but from this machine I haven't accessed it for ages. Nov 03 22:43:12 ! Nov 03 22:43:25 ka6sox-away: okay, i'll keep it in mind :) Nov 03 22:43:51 JaMa|Wrk, np...sorry that was a bit of a slog. Nov 03 22:44:12 first spontaneous (unexplained as of yet) shutdown in months. Nov 03 22:44:45 so we took the opportunity to get some other things fixed and upgrade the server RAM. Nov 03 22:45:27 no problem here.. I've pushed it mostly to test it for you :) Nov 03 22:45:38 perfect...quite helpufl. Nov 03 22:45:41 helpful. Nov 03 22:46:04 feels good... Nov 03 22:47:41 woglinde_, yes i am using an OE filesystem Nov 03 22:48:32 huh we have filesystem now? lets push it to mainline kernel :) Nov 03 22:53:14 did i say something ignorant? Nov 03 22:54:18 gungfuwayne only something which dont make much sense Nov 03 22:54:25 03Richard Purdie  07master * r8df3f86bbc 10bitbake.git/ (bin/bitbake lib/bb/__init__.py): Release 1.14.0 Nov 03 22:54:27 you should fix your /dev/tty problem Nov 03 22:54:28 03Richard Purdie  07master * r9c097704b4 10bitbake.git/ (bin/bitbake lib/bb/__init__.py): Nov 03 22:54:28 Increment version post release Nov 03 22:54:28 Signed-off-by: Richard Purdie Nov 03 22:58:17 well here is a different string of characters strung together, maybe they will make more sense: i am using oe recipes to generate a filesystem using bitbake Nov 03 23:01:21 when i run "tty" from a shell spawned by the previously-mentioned init= script, it responds with "/dev/console"; when i boot with /sbin/init.sysvinit, log in, then run "tty" i see "/dev/ttyS0" which is indeed the terminal with which I am communicated with the device Nov 03 23:02:27 i guess this probably isn't the right place to ask, but no one in the debian channel responded possible because i am actually fairly ignorant about how to use the terminology to describe what i am doing **** ENDING LOGGING AT Fri Nov 04 02:59:57 2011