**** BEGIN LOGGING AT Thu Sep 05 02:59:59 2013 Sep 05 06:49:36 good morning Sep 05 06:51:20 morning mckoan and #oe Sep 05 07:43:30 hi. i am looping into IMAGE_FEATURES, and how it works. I woud like to create my own custom IMAGE_FEATURES, after looking at the code, it sounds it should work (i haven't tried yet), since image.bbclass would simply take PACKAGE_GROUPS_. but it's not something documented, so i'd like to check first if it's supported/ok to do that. Sep 05 07:44:24 i guess, that means that i need to make my own 'image class' too, to be inherited from all my images. Sep 05 08:15:09 morning all Sep 05 08:15:27 morning Sep 05 08:18:44 hi bluelightning, hi JaMa, hi all Sep 05 10:00:36 Just built a new sysvinit based image with dropbear, but for some reason update-rc.d was not run. Anyone familiar with this? From what it looks in the recipe update-rc.d should be run automatically. Sep 05 10:04:48 hno: sounds like postinstalls might not have been run Sep 05 10:05:15 hno: which package management backend are you using (PACKAGE_CLASSES)? Sep 05 10:05:45 Stygia: I'm afraid those last two patches for libdevice-gsm-perl need to be squashed together Sep 05 10:06:43 bluelightning, Ah. Any good way to do that? Maybe I should just not contribute anything until I know git better. Sep 05 10:06:52 "Better" as in at all.. Sep 05 10:07:16 Stygia: git rebase -i is the easiest way Sep 05 10:07:39 Stygia: if you like, you could send me a branch with everything in it and I can review / squash everything Sep 05 10:07:43 bluelightning, Haven't set any. How do I tell? Sep 05 10:08:14 hno: do you have deploy/ipk, deploy/deb or deploy/rpm under your tmp directory? Sep 05 10:08:16 bluelightning, I think I'll just wait and read up on git this weekend. Sep 05 10:08:26 bluelightning, Besides, I need to review my recipes for core modules... Sep 05 10:08:36 bluelightning, I'm a bit confused about that aspect. I grep'd most of them in the core perl recipes. Sep 05 10:08:48 But there are no perl-module-X variants of them. Is it just implicit they're compiled in, or what? Sep 05 10:09:08 bluelightning, I have deploy/eglibc/ipk Sep 05 10:09:14 hi Sep 05 10:09:42 guys: simple Qt4-x11 app in OE I need. suggestions? qt-helloworld with one button is enough;) Sep 05 10:09:44 hno: you don't by any chance have opkg installed in your image without package-management in IMAGE_FEATURES? Sep 05 10:10:06 hno: I ask because there is a bug that prevents postinstalls from running in that case at the moment Sep 05 10:10:31 there seems to be opkg installed. Sep 05 10:10:46 bluelightning, Some of them are only mentioned in RDEPENDS... As in, perl-module-time-hires depends on some things, but doesn't seem to actually be defined anywhere. Sep 05 10:10:53 stygia: and i would urge you to send the patches as a series of patches, it makes it easier to track/comment on them as a whole Sep 05 10:11:24 Stygia: I'm not completely familiar with the ins and outs of our perl packaging; you may be able to find the answers by looking in packages-split under the workdir for perl though Sep 05 10:11:38 zibri, Yea I wrote that down actually. I'll just wait until next week to commit things, though, and read up on git properly. Sep 05 10:11:47 stygia: sounds good :) Sep 05 10:12:05 zibri, Heh it's not as simple as it seems at first glance... Sep 05 10:12:21 you become used to it after a while :) Sep 05 10:12:49 bluelightning, and no IMAGE_FEATURES set at all. Sep 05 10:13:02 stygia: btw, the Time::HiRes module is core ;) Sep 05 10:13:17 zibri, Yup I know. Sep 05 10:13:27 zibri, I did send a patch to my patch removing it once I noticed I'd left it in... Sep 05 10:13:40 oh, i misread. i thought you added the dep, not removed Sep 05 10:13:41 sorry Sep 05 10:13:45 hno: ok, that's probably the cause then; if you want packaging on the target device, turn that on; otherwise for the moment as a workaround you'll need to change things so that opkg isn't being installed Sep 05 10:14:27 I don't really want packaging in this image, it's an initramfs so kind of pointless. Sep 05 10:14:34 hrw: well we have three qt example applications, otherwise there are the demos provided with qt itself but I don't think the latter are packaged individually Sep 05 10:14:56 hno: ok, then I guess opkg is superfluous as well Sep 05 10:14:58 bluelightning: thx Sep 05 10:15:00 have not asked for opkg to be installed, but guess it's a dependency of something. Sep 05 10:15:19 bluelightning: qt-demos exist ;) Sep 05 10:16:05 Heh... if I could travel back in time a few months with what I know about packaging and OE now I could save myself at least 80% of the time I've spend on these projects. Sep 05 10:16:14 how can I tell why a package got included? Sep 05 10:16:17 Stygia: ;:)) Sep 05 10:16:32 hno: the ultimate way is to enable buildhistory: http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#maintaining-build-output-quality Sep 05 10:17:14 hno: see "Using Build History to Gather Image Information Only" for just the bit that you're looking for Sep 05 10:19:35 bluelightning, have lots of files there so guess it's enabled somehow. Sep 05 10:20:03 hno: could be, in which case just have a look at the depends.dot file under the buildhistory dir for the image Sep 05 10:21:38 busybox -> opkg; dropbear -> opkg; initscripts -> opkg; .... Sep 05 10:21:46 seems kind of hard to get rid of. Sep 05 10:22:22 but no idea why those needs opkg. Seems strange. Sep 05 10:22:59 sysvinit & tinylogin also. Sep 05 10:25:17 bluelightning, any idea why busybox or sysvinit would depend on opkg? Sep 05 10:25:47 er.. no, that is strange Sep 05 10:26:06 hno: are you building dylan/some other branch or master? Sep 05 10:32:58 hmm... seems to be angstrom-v2013.06-yocto1.4.. maybe should try with a clean openembedded tree. Sep 05 10:35:10 can not find any opkg references in those packages. Sep 05 10:40:48 well, I guess that is dylan if it's 1.4 Sep 05 10:40:57 yes, seems so. Sep 05 10:41:05 with some changes. Sep 05 10:41:23 but can't see why there is an opkg dependency. Sep 05 11:15:09 bluelightning, getting a pure dylan env up and running seems a bit problematic.. getting stuck with parsing errors on meta-ti layer. Killed a number of .bb recipes I don't really need and got it running. Sep 05 11:40:58 morning all Sep 05 11:50:28 gm Sep 05 11:57:34 hno: yes, meta-ti could make things a little easier in that regard Sep 05 12:00:58 bluelightning, how do I work around the opkg problem? IMAGE_FEATURES += "package-management" Sep 05 12:01:47 hno: that's one workaround but it's going to put things in your image that you don't want Sep 05 12:01:57 I'm really interested to know why this is happening Sep 05 12:02:41 bluelightning, should there be any spaces within the quotes? Or fine without? Sep 05 12:03:14 hno: fine without Sep 05 12:04:41 any idea what to look at for finding why opkg gets pulled in as a dependency for busybox? Sep 05 12:27:42 bluelightning, workaround do not seem to help. Still get no rc*.d links for dropbear and other packages using update-rc.d. Sep 05 12:27:59 sigh Sep 05 12:29:03 hno: any clues in log.do_rootfs? Sep 05 12:29:03 plain dylan build running but takes a while Sep 05 12:29:52 hno: there is one concern, I've just realised you're using angstrom; FWIW angstrom has been systemd-only for some time now and I'm not sure how well sysvinit support will work with that distro configuration Sep 05 12:30:27 unless the policy over there has changed that is Sep 05 12:31:03 bluelightning, yes there is quite obvious hits. It's configuring for systemd and not sysvinit. Sep 05 12:31:34 I'd say that'll be where the problem lies then Sep 05 12:31:38 yes Sep 05 12:32:47 FWIW, OE-Core does support both sysvinit and systemd (even both at the same time if you want some images using one and other images using the other); but distros on top of OE-Core are another matter Sep 05 12:34:10 good. So hopefully the dylan build should look better. Don't really need a distro as such. This thing will only run a single console application (plus dropbear for ssh access). Sep 05 12:36:22 hmm.. now bitbake is crashing... AttributeError: 'NoneType' object has no attribute 'rfind' Sep 05 12:39:25 File "/build/openembedded/oe-core/bitbake/lib/bb/runqueue.py", line 1372, in RunQueueExecuteTasks.execute(): Sep 05 12:39:25 if not self.rq.fakeworker: Sep 05 12:39:25 > self.rq.start_fakeworker(self) Sep 05 12:45:01 bitbake stopped due to low disk space, and then this started (after clearing up many GB diskspace elsewhere) Sep 05 12:53:47 not my bitbake day today obviously. Sep 05 12:55:12 hno: the earlier error sounds like bitbake master used with dylan; you should use the bitbake 1.18 branch instead Sep 05 12:57:40 Ok. trying again... Sep 05 13:26:20 how do you detect screen resolution while X is starting? Sep 05 13:27:00 I intend for different resolutions (not only one screen) Sep 05 13:27:54 so, I guess I need some way to find screen resolution and write xorg.conf. Or does xorg handle this? Sep 05 13:30:49 xorg generally do not need an xorg.conf if it can identify the screens. Sep 05 13:37:20 eren: which platform? Sep 05 13:40:50 hrw: x86 Sep 05 13:41:11 actually it is an AMD board with i586 instruction set Sep 05 13:41:28 eren: geode lx? Sep 05 13:42:00 hrw: yep Sep 05 13:42:20 eren: from what I remember from alix.1c it handles EDID just fine Sep 05 13:43:22 eren: so just boot it into x11 and it should use proper res Sep 05 13:43:22 well, I need to package geode module first Sep 05 13:43:22 last time I tried it was really unresponsive Sep 05 13:43:26 I thought that using without GUI is more appropriate Sep 05 13:44:33 eren: do not expect too much from few years old cpu Sep 05 13:45:40 yeah, it runs on 500MHz Sep 05 13:46:08 at least I want to be able to run Xastir (APRS tracker software) Sep 05 14:22:30 Hello everybody. I wonder if a bbappend can overwrite the SRC_URI & S variables of the correspondant bb file ? Sep 05 14:23:48 vadmeste: hi, yep absolutely Sep 05 14:33:33 bluelightning: thanks.. ops, it seems that it is not possible to check a subdirectory of a git repository.. :/ Sep 05 14:34:06 checkout* Sep 05 14:34:14 vadmeste: actually there is an option for that Sep 05 14:34:25 vadmeste: ;subpath=path/within/repo Sep 05 14:38:38 bluelightning: thanks.. and do you think that bitbake will download only the subdir ? because downloading all takes too much time for me Sep 05 14:39:12 it's not possible to clone just a subdir of a git repository, with or without bitbake Sep 05 14:39:20 vadmeste: unfortunately it can't do that, because git doesn't really support that Sep 05 14:39:43 vadmeste: however, if you have multiple recipes using subpath= there should be collective saving in fetch time Sep 05 14:40:03 (multiple recipes using the same repo/revision with different subpath= values) Sep 05 14:48:45 this question may sounf a bit off topic, but anyway does anybody know a solution for the year 2038 problem with our 32bit linux embedded systems? http://en.wikipedia.org/wiki/Year_2038_problem Sep 05 14:49:48 mckoan: there's a load of discussion here: https://lwn.net/Articles/563285/ Sep 05 14:50:35 bluelightning: uh, looks a quite recent article, thanks a lot! Sep 05 15:02:45 * hno suddently felt old... "Many LWN readers have been in the field long enough to remember the year-2000 problem".. that was only some years ago. Sep 05 15:11:35 hno: BTW I also used 5"1/4 floppy disks and MS-DOS :-D Sep 05 15:14:57 * JaMa remembers important upgrade from win 3.10 to 3.11 :) Sep 05 15:17:16 JaMa: LOL Sep 05 15:17:34 * zibri remembers important upgrade from linux 3.10 to 3.11 :) Sep 05 15:18:58 mckoan: when I went to use DOS on my x86 box I used OpenDOS from Caldera Sep 05 15:19:07 zibri: upgrading kernel was easier, just one command instead of 16 commands and switching 8 floppy disks in drive :) Sep 05 15:19:15 JaMa: I booted windows 1.01 during studies Sep 05 15:22:43 :) Sep 05 15:26:13 * denix wonders why don't people read README? re: hno Sep 05 15:31:20 denix: I've said it before, but I think those extra steps shouldn't really be needed Sep 05 15:32:06 bluelightning: not until everyone learns to read! :) jk Sep 05 15:38:03 * XorA remembers upgrade from zx81-zx82 :-D Sep 05 15:49:05 XorA: zx82? Sep 05 15:49:45 hrw: code name for the spectrum before it was actually released Sep 05 15:50:01 XorA: aka zx81 colour I see Sep 05 15:51:01 these days of course I have full series zx80->Sam Coupe Sep 05 15:51:26 XorA: including non-uk clones? Sep 05 15:51:28 :D Sep 05 15:52:20 hrw: none of those, they seem to be silly money even compared to zx80 Sep 05 15:52:32 ;)) Sep 05 15:53:02 XorA: I remember one demoparty when iirc yerzmey was running all zx demos from zx evo Sep 05 15:53:06 there is a modern remanufacture of the Pentagon though Sep 05 15:54:42 hrw: you have met the man himself? Sep 05 15:54:52 * XorA hero worships Sep 05 15:55:00 XorA: yerzmey? few times Sep 05 15:55:41 XorA: visit Poland in next next weekend - we have nice demoscene party Sep 05 15:55:58 hrw: next time you are in the uk take him back some zx81s I hear he is running short Sep 05 15:56:12 hrw: next weekend I need to prep for plumbers :-( Sep 05 15:56:39 XorA: use courier service - will be faster D" Sep 05 15:57:07 hrw: I think the issue is the postage costs to Poland are much greater than the value of the machines Sep 05 15:58:01 even sending just the PCB to Germany from here was expensive Sep 05 16:00:32 XorA: for 5kg 60x40x20cm box by ups I got ~20GBP price Sep 05 16:00:41 XorA: from Poland to Scotland Sep 05 16:00:54 hrw: and machines are only worth 5-10GBP Sep 05 16:02:22 XorA: cheap retro Sep 05 16:03:16 hrw: there were an aweful lot of them produced Sep 05 16:03:41 hrw: so no matter how many ebay sellers claim they are R@RE there is always hundreds listed :-D Sep 05 16:03:49 ;) Sep 05 16:11:56 hi. is it 'safe' to build several images in the same env for the same machine, successively? i expect in $DEPLOY there will be 1 kernel + N rootFS. Sep 05 16:12:10 yes Sep 05 16:12:13 in other words, can an 'image' impact the kernel/modules build? Sep 05 16:12:36 and no Sep 05 16:12:48 all IMAGE_FEATURES never impact kernel/module? Sep 05 16:13:11 ndec: if they do, that's a bug Sep 05 16:13:26 ndec: no non-image recipe should pay attention to IMAGE_FEATURES Sep 05 16:13:31 ok. as you saw, i needed to hear it 3 times ;-) Sep 05 16:14:26 this morning i asked another question, which wasn't answered. so let me try again. Can i create create my 'own' IMAGE_FEATURES? iirc, i just need to create PACKAGE_GROUP_myown and that should be it, right? Sep 05 16:14:43 yes, that should be enough Sep 05 16:14:49 ok. Sep 05 16:36:11 denix, which README did I forget reading? Sep 05 16:38:00 oe-core did not tell that dylan needs a specific bitbake version Sep 05 16:38:48 meta-ti said to exclude some recipipes if meta-openembedded was not used, but I have that layer and it was not those recipes that failed. Sep 05 16:39:29 hno: each layer comes with its own README - there may be some details about the layer specifics... Sep 05 16:40:45 hno: then which recipes failed in your case? Sep 05 16:42:07 the images recipes. bitbake complained about missing license, and then syntax error. Sep 05 16:44:19 but might have been before I switched to a older bitbake version. Don't remember which error came first. Sep 05 16:49:02 any tips on how you use PATCHRESOLVE? Sep 05 16:49:40 * JaMa is using noop Sep 05 16:49:54 * bluelightning too Sep 05 16:50:00 better for running non-interactive builds Sep 05 16:50:58 yeah, I need to debug a failure and the logfile is useless Sep 05 16:51:00 noop for nightlies, of course Sep 05 16:54:10 if a patch fails and I can't puzzle it out, how can I use PACTHRESOLVE to help? Sep 05 16:55:05 moin Sep 05 16:55:14 Crofton: if you set PATCHRESOLVE to "" and the application of the patch fails, you end up with a "devshell"-like environment in which you can poke around Sep 05 16:56:07 you should also be able to try it manually in workdir Sep 05 16:56:17 (if i'm remembering that correctly) Sep 05 16:56:22 and look at the do_patch script in temp i suppose... Sep 05 16:56:43 lets see what happens with ="" Sep 05 16:56:44 tlwoerner: sounds correct, although i haven't actually tried it Sep 05 16:57:39 this is what is weird Sep 05 16:57:41 hmm Sep 05 16:57:47 if the paths in the patch are relative to workdir it should work Sep 05 16:57:48 mayb eI need to to this in local.conf Sep 05 16:58:00 oh yes, conf/local.conf Sep 05 16:58:08 you can also set the patch level on SRC_URI i think Sep 05 16:59:07 that said, i have a few classic recipes with a manual do_patch because i was too lazy to remake the patch myself... Sep 05 16:59:30 denix, tried again and the meta-ti images recipes in dylan branch all fail to parse even with bitbake 1.18. error message: http://ur1.ca/fe2dl Sep 05 16:59:42 probably ought to change the PATCHRESOLVE line in local.conf to ?= .... Sep 05 17:05:48 hno: this is the part convered in meta-ti's README I think Sep 05 17:05:58 er covered Sep 05 17:06:32 could be better worded then. Sep 05 17:07:18 hmm, I can't get it to kick into devsheell Sep 05 17:07:23 "When not depending on meta-openembedded and not using systemd,", I have meta.openembedded. Sep 05 17:07:25 do I need to set something else? Sep 05 17:08:09 hno: yes the wording is out-of-date Sep 05 17:08:59 Crofton|work: OE_TERMINAL? although that will normally auto-select whatever terminal is available assuming it's been left at the default value of "auto" Sep 05 17:09:04 Found the culpit I think.. they all end up in "include recipes-images/angstrom/systemd-image.bb" Sep 05 17:09:11 hno: indeed Sep 05 17:09:21 strangely the error message says nothing about it.. Sep 05 17:09:56 Crofton|work: devshell runs after do_patch, so you can work with the final sources. so you cant manually run a devshell task to fix a non-applying patch without removing the patch from SRC_URI first Sep 05 17:10:17 Crofton|work: setting PATCHRESOLVE=user to will get it to automaitcally spawn a devshell specifically to resolve the failed patch application Sep 05 17:10:26 hno: "include" doesn't error when the file is not found, that's by design; "require" is the equivalent that does Sep 05 17:10:50 ok. Sep 05 17:11:10 * kergoth fights bitbake (and mostly loses) Sep 05 17:11:13 kergoth: ah okay "user" sorry Crofton :-S Sep 05 17:11:37 hno: I'd suggest just BBMASKing out those recipes as mentioned in the README Sep 05 17:13:20 yes. Sep 05 17:16:56 arg Sep 05 17:17:03 it refues to go into a devdeall Sep 05 17:17:57 insufficient information to diagnose. refuses? Sep 05 17:18:06 :) Sep 05 17:18:20 Crofton: could you wait another week or two before making such comments? (http://www.talklikeapirate.com/) ;-) Sep 05 17:18:53 http://pastebin.com/aGDJ386T Sep 05 17:19:06 PATCHRESOLVE = "user" Sep 05 17:20:50 it doesn't look like that recipe is using standard patch application mechanisms Sep 05 17:21:06 its using git, so either its using the 'git' patch applier from oe.patch, or it's rolling its own do_patch Sep 05 17:21:15 tough to say without examining the recipe Sep 05 17:21:37 I can believe that Sep 05 17:21:41 aside: that message about using devshell is completely wrong, afaik, wonder where that's coming from Sep 05 17:23:08 https://github.com/Xilinx/meta-xilinx Sep 05 17:23:25 I can't see if messing with do_patch Sep 05 17:24:01 or do I blame linux-yocto Sep 05 17:24:30 linux-yocto recipe, i have no clue on how to proceed Sep 05 17:24:44 [INFO] validating against known patches (zynq-default-standard-meta) Sep 05 17:24:46 yeah reading back up the food chain Sep 05 17:25:27 damn it, zediii is only in #yocto Sep 05 18:40:51 arg, it look slike if I give the kernel recipe a rev past the end of master, it silently choses HEAD os master as the rev to check out Sep 05 18:41:16 any ideas how to tell bitbake the SRC_REV in a bbappnd file is on a branch? Sep 05 18:56:02 Crofton|work: bitbake checks out exactly what SRCREV is set to, if its a commit, it doesn't care waht branch that belongs to, but linux-yocto does its own thing, rather than letting bitbake check it out.. Sep 05 18:56:29 yeah, I think I see that Sep 05 18:56:43 next time I see zedii, I am goin gto make him buy me beer Sep 05 18:57:02 hehe Sep 05 18:59:23 KBRANCH=.... Sep 05 18:59:34 the not erroring on the original checkout is really annoying Sep 05 19:32:04 Quick (frustrated) question: does OE "ever" work right away? I've been following guides online, trying everything I can find, but something ALWAYS fails. :/ Sep 05 19:32:19 Right now I'm following this: http://www.angstrom-distribution.org/building-angstrom Sep 05 19:32:33 But every machine combo I try fails in some different way. Sep 05 19:34:47 i would recommend you stick to 'poky' when you get started. it's the simplest IMHO to learn, and get some basic underdstanding. Sep 05 19:35:33 Cool, I will take that advice. :) Sep 05 19:35:33 the quick start guide should just works. http://www.yoctoproject.org/docs/current/yocto-project-qs/yocto-project-qs.html Sep 05 19:36:03 there is nothing wrong with angstrom, of course! it's just that there is more documentation for poky. Sep 05 19:38:24 Well, I'm not sure how/why this failing. Angstrom/rpi fails on eglibc something, and Angstrom/beagleboard fails on linaro-image-lamp. **** ENDING LOGGING AT Fri Sep 06 02:59:59 2013