**** BEGIN LOGGING AT Thu Mar 05 02:59:59 2015 Mar 05 07:50:29 good morning Mar 05 10:18:40 heh world builds are doomed.. since last week qtwebengine, chromium, webkit-efl and qt-creator build in tandem to eat all my tmpfs and get killed by OOM k.. will have to lower bitbake threads even more.. Mar 05 10:18:58 hehe Mar 05 10:40:44 woglinde: have you ever had issues with meta-java such as this: WARNING: /home/mago/dev/slp/slp-build/tmp-glibc/sstate-control/manifest-greyhound-cacao-initial.populate_sysroot not found Mar 05 10:43:12 mago_ hm no Mar 05 10:43:15 is this master? Mar 05 10:43:41 there are some patches in master fot sstate and now our concept with initial will not work Mar 05 10:43:48 woglinde: yeah, master Mar 05 10:43:59 is my wild guess Mar 05 10:44:14 maybe we have to flag the -initial packages somehow Mar 05 10:44:23 so sstate will not look at them Mar 05 10:44:42 but I have no time to look into it Mar 05 10:45:02 woglinde: what patches are you referring to? are they already applied, or do you mean there's a fix somewhere out for review? Mar 05 11:26:02 hmm, what is the "standard" way to prevent autoreconf from running? Mar 05 11:34:23 do_configure() { Mar 05 11:34:28 # don't run autoreconf Mar 05 11:34:31 oe_runconf Mar 05 11:34:32 } Mar 05 11:35:21 simplier than I thought, thanks :) I grepped around and found some a bit weird exampls like setting --src=. so thought I'd ask ;) Mar 05 11:38:13 works, thanks again Mar 05 11:48:20 hi Mar 05 11:48:53 is it somehow possible to mark a recipe so that bitbake *always* rebuilds it? that is, bitbake never does a no-op with it? Mar 05 11:49:19 perhaps a way to make bitbake believe it is constantly being changed/invalidated/whatever Mar 05 11:51:01 mago_ there are no fixes to review Mar 05 11:51:59 dv__: I do not know if it is a correct or "suggested" way but this kind of works for me https://gitorious.digitalstrom.org/dss-oe/dss-oe/blobs/master/yocto/dS/meta-digitalstrom-testing/recipes-core/images/digitalstrom-image-version_0.2.bb Mar 05 11:52:16 dv__: you probably want only the nostamp part while keeping the execs Mar 05 11:53:14 the underlying issue is that a recipe for a component of ours is autogenerating the package version based on the current git revision Mar 05 11:53:46 and if we move back in the git history, and rebuild the recipe, OE still picks the newer one from the cache Mar 05 11:54:53 here's the part that does this: http://pastie.org/private/8dvr3fwxhrymrzlyvvveg Mar 05 11:54:57 so perhaps we are doing something wrong Mar 05 11:56:08 are you using gitpkgv and AUTOREV? Mar 05 11:56:58 ah, you don't, you set PV yourself Mar 05 11:57:30 this worked fine up to and including danny Mar 05 11:57:35 after danny, not so much Mar 05 11:57:54 (and yes, I know the PR is there ... we have to remove it as some point, we know :) ) Mar 05 11:58:27 if you look at the names that gitpkgv produces, it always has a gitrXX where XX is always incremented no matter what the revision is Mar 05 11:58:50 so probably forget what I posted earlier (it was a different use case) Mar 05 11:59:08 well, also, we are building from tree Mar 05 11:59:23 so, the recipe does _not_ fetch from a git repo. the recipe is in the same tree as the sources. Mar 05 12:00:23 dv__: to be honest I am a bit confused about what you are trying to do Mar 05 12:00:57 we want to rebuild from the local sources when the git revision changes Mar 05 12:01:21 not just when the revision moves forward, but also when it moves backward, for example because I checked out an earlier commit Mar 05 12:01:26 but without fetching from git? Mar 05 12:01:38 there is no fetching, because the recipe and the sources are in the same local tree Mar 05 12:01:57 ok, I'll ask differently: what is your SRC_URI? Mar 05 12:01:58 see the source line: S = "${FILE_DIRNAME}/../../../.." Mar 05 12:02:09 and we have no SRC_URI Mar 05 12:02:19 I do not see S = in your paste Mar 05 12:02:25 yeah, it wasnt included, sorry Mar 05 12:03:17 updated paste: http://pastie.org/private/sup6wuzhkue9xzu3hqcq Mar 05 12:03:51 I get the impression that it is quite uncommon in OE to not have to fetch the sources first, and build directly from the same tree where the .bb file is located Mar 05 12:04:08 woglinde: why would sstate look for the -initial packages? i don't fully understand why this warning is emitted in the first place Mar 05 12:04:17 dv__: I see such a setup for the very first time Mar 05 12:04:33 well, lets look at it from another angle Mar 05 12:04:53 mago_ the problem is we need the initial packages to build the native build packages Mar 05 12:05:01 you have such a tree (both the C++ sources and OE/yocto scripts in the same tree). you want OE to build from the local sources, that is, no fetching. Mar 05 12:05:05 how would you do it? Mar 05 12:05:08 and I am not sure if I can help you, my OE knowledge is limited to the more or less standard scenarious, maybe someone else has an idea Mar 05 12:05:21 but when using the sstate we do wont need the initial packages Mar 05 12:05:38 thats my wild guessing Mar 05 12:05:49 woglinde: okay, so this is only an issue once the initial packages have been built once? Mar 05 12:05:52 dv__: why would you do it like that? isn't it a mess to have two different things in one tree? wouldn't you want to keep the OE part in a separate repo and track the recipe fixes there and have your sources in an own repo? Mar 05 12:06:08 mago yes I think so Mar 05 12:06:52 but anyway, I think what you are trying to do requires some settings that I won't be able to tell, I'm more an OE user, I don't have too much in depth knowledge of the behind the scenes Mar 05 12:07:44 ah, der 8777 wird es sein Mar 05 12:07:44 woglinde: i thought the sstate cache was transparent ontop of the bitbake dependency system, that it would simply use the sstate when available, otherwise fall back on building the package from source; so if the sstate cache is already populated with -native stuff, why would it even look for -initial stuff? Mar 05 12:07:47 oops wrong window Mar 05 12:11:03 What is the correct way to add kernel modules to your image/ Mar 05 12:11:22 Would it be like any other package, just specify in your image.bb? Mar 05 12:13:15 And where do you specify that they should be Mar 05 12:13:22 modprobed... Mar 05 12:14:09 pompomJuice taskgroup or machine file Mar 05 12:14:42 Aah thanks. Mar 05 12:14:53 Let me investigate that inside the docs. Mar 05 12:15:21 hm I think it is not in the docs Mar 05 12:15:27 but thats the way how I did it Mar 05 12:15:44 and the task-group of course goes to the image Mar 05 12:17:13 I found a piece in the kernel development doc that explains what you said Mar 05 12:17:48 oh okay ,) Mar 05 12:17:52 but Mar 05 12:18:03 it does not say how or if it will be loaded Mar 05 12:18:18 uhm? Mar 05 12:18:23 via udev? Mar 05 12:19:05 hm modprob.e or similiar Mar 05 12:19:08 ok so if I have my dts file updated and match the "compatible" with the driver module name it should work right? Mar 05 12:19:10 ubuntu has /etc/modules-load.d/cups-filters.conf too Mar 05 12:19:28 pompomJuice hopefully yes Mar 05 12:19:31 lets see Mar 05 12:21:01 We have a version 2 of our product now and it runs on a imx6 freescale SOC. Mar 05 12:21:22 That means I can run yocto 1.7 and have all these device tree goodies do work for me. Mar 05 12:22:00 no more noob kernel 2.6.37 issues Mar 05 12:22:56 uh hurray Mar 05 12:22:59 2.6 Mar 05 12:24:19 Yea those noobs at systemd went and tightly coupled their software with the kernel. Causes all kinds of buggerups Mar 05 12:24:28 So annoyed by that Mar 05 12:24:33 what were they thinking Mar 05 12:25:30 hm you can only use the features of systemd you want Mar 05 12:25:46 we ran it without journald Mar 05 12:25:49 for instance Mar 05 12:25:53 interesting Mar 05 12:26:00 I was not aware you could chop and change Mar 05 12:26:16 All I know is that from 205 onwards you need kernel v3.x Mar 05 12:26:39 maybe I can disable that part and upgrade our older model to yocto 1.7 Mar 05 12:26:54 I will investigate Mar 05 12:27:33 pompomJuice yes because of cgroups Mar 05 12:27:41 and cgroups is a nice Mar 05 12:27:48 thing Mar 05 12:28:55 in fact, the problem lies actually at TI for not maintaining their kernels. I will never ever reccomend or use TI products again if I can help it Mar 05 12:30:32 hm hm Mar 05 12:30:33 depends Mar 05 12:30:38 For example. Their IDE, code composed studio, is so dumb it cannot even understand it's own projects made with earlier versions. Basics people... basics. Mar 05 12:31:05 code composed studio is eclipse by the way Mar 05 12:31:18 Dont get me started on eclipse Mar 05 12:31:27 which leads to dont get me started on java Mar 05 12:31:34 I blame it all on java Mar 05 12:32:16 This version that version... good god man how were they planning on being machine independent if they cant even be version independent from the same vendor. It's silly. Mar 05 12:33:00 hm you have desktop java, sever java and embedded java Mar 05 12:34:37 Every piece of software written in java is tightly coupled to the exact version of java it was developed against... don't try and be smart and mix oracle java with openjdk with icetea with this and that... now I have to sudo update alternatives every time I want to use a java app.... java is the stupetest thing ever invented Mar 05 12:36:13 hm Mar 05 12:36:19 I do not have such problems Mar 05 12:36:34 but yes there are some diffrents btw 1.6 1.7 and 8 Mar 05 12:37:17 for example... I have bitbake that compiles recipies that contain java... those only work on oracle java 1.6.... but wait... eclipse requires java 1.7.... so now every time I want to build I must switch versions. Mar 05 12:37:31 ???? Mar 05 12:37:44 no you can start eclipse whith ever jdk you wants Mar 05 12:37:45 the meta-java layer does not work with 1.7+ Mar 05 12:37:58 The latest eclipse told me it needed 1.7 Mar 05 12:38:00 pompomJuice send patches for newer openjdk version Mar 05 12:38:10 the 1.7 is old Mar 05 12:38:21 and I have to time to test and update it Mar 05 12:39:16 Aah wait, I got confused... it was not meta-java giving me problems... but the android we build for our device... it requires 1.6. Install oracle java 1.7 and you get one million compile errors Mar 05 12:39:33 They make no effort to be backwards compatible Mar 05 12:39:50 they are probably lauging their asses off every time they make a release Mar 05 12:40:04 "Those silly developers! Now they shal recode everything" Mar 05 12:40:13 "mohahaha" Mar 05 12:40:25 ;-) Mar 05 12:40:28 I hate java Mar 05 12:41:32 pompomJuice uhm android is another diffrent field Mar 05 12:48:36 what's the correct way to get around the multimachine build warning for allarch packages, like kernel firmware, use SSTATE_DUPWHITELIST? Mar 05 12:49:03 I could make it machine specific but its really the same content for all... Mar 05 13:07:40 seems to do the trick Mar 05 13:20:34 in eaerlier days there used to be a package_mapping_rename_hook in package.bbclass Mar 05 13:20:46 is there a similar mechanism for today? Mar 05 13:21:04 I see there is some hook that could be passed via function parameters but I am not quite sure how this should be done Mar 05 13:21:42 hmm, although I am wrong, in package_ipk.bbclass there is still a mapping_rename Mar 05 13:21:52 I wonder why my hook was not triggered hmm Mar 05 13:23:16 ah, it's just mapping_rename_hook now ;) never mind Mar 05 14:12:08 shouldn't I see a bb.note() in python mapping_rename_hook_append () with -DDD ? Mar 05 14:12:20 I can see with -e that my code is added to the hook Mar 05 14:12:40 but I do not see any printouts and I am not sure if it is ever being run.. Mar 05 14:27:32 hmm, mapping_rename_hook is not being called at all? Mar 05 14:35:45 I added a bb.error to my rename hook and still nothing is happening Mar 05 14:56:01 I really don't get it... /poky/meta/classes/package_ipk.bbclass -> added log output right before mapping_rename_hook(localdata) call, added log output inside my python mapping_rename_hook_append(), checked with bitbake -e that everything is there Mar 05 14:56:16 however, when I then run bitbake I See the printout before the hook Mar 05 14:56:22 but nothing from inside the hook function Mar 05 14:56:33 what am I missing?? I'm puzzled Mar 05 15:15:01 could someone please have a look and explain to me how this is possible at all? https://pastebin.mozilla.org/8824456 This is from the bitbake -e run, my rename hook append code is there, but the printouts that were appended are not printed! and those that I hacked in directly into package.bbclass are printed Mar 05 15:15:14 it's almost like its running the hook first and appending later or something, otherwise I can not explain this Mar 05 15:16:00 otherwise it's really not possible when two printouts that are following each other behave in a way that the first one is printed and the second one is not... Mar 05 15:16:02 is this a bug? Mar 05 15:16:14 something wrong with _append code? Mar 05 15:16:37 you can't _append to a def'd python function Mar 05 15:16:52 or rather, it will append to the metadata's copy of it, but not the python function stored in the python execution context Mar 05 15:17:04 oh... Mar 05 15:17:17 I had that hack back from the days when switching from OE-classic to OE-core Mar 05 15:17:32 kergoth: so how can I hook myself in there? Mar 05 15:17:39 what's the correct way to achieve that these days? Mar 05 15:19:39 there are multiple ways to inject yourself at various points in the packaging process. it depends on what exactly you're trying to accomplish and why Mar 05 15:20:00 I need to add rreplaces/rconflicts rules for a live update from eglibc to glibc Mar 05 15:20:36 since glibc spits out numerous of glibc-whatever packages that seemed the way to do it, it's the way you guys suggested to me 5 years ago when I was working on a live pudate from oe classic to OE core, it worked fine back then Mar 05 15:21:02 yeah, you can't expect things that were hacks back then to work now :P Mar 05 15:21:10 of course not :) Mar 05 15:21:26 I assume there are better ways to do things like that now Mar 05 15:21:31 so I'm all ears Mar 05 15:22:16 well, debian renaming happens in package_name_hook, which is in PACKAGEFUNCS, from some quick reading Mar 05 15:22:45 either you could append to the package_name_hook, or inject your own function in the appropriate place in PACKAGEFUNCS Mar 05 15:23:06 let me try to append and see what happens... Mar 05 15:23:31 that's if you want to override the debian renaming, of course. if you want to run beforre it does, it's even easier, just prepend to PACKAGEFUNCS Mar 05 15:23:47 package.bbclass provides a number of different hooks into various points in the packaging process Mar 05 15:26:10 so basically I would do a PACKAGEFUNCS += or whatever order I like and that would be it in case of a new function? Mar 05 15:27:23 the variable is a list of functions to be executed at that point in the packaging process Mar 05 15:27:32 you don't want to += or your change will occur after writing pkgdata Mar 05 15:27:40 but basically yes Mar 05 15:27:43 oh right, ok I think I get the idea now Mar 05 15:27:49 thank you! Mar 05 15:28:43 np Mar 05 15:43:02 kergoth: pkgname = bb.data.getVar('PKG', d) Mar 05 15:43:06 is null Mar 05 15:43:16 is PKG set only in special context? Mar 05 15:43:51 afaik yes, it's only set when needed Mar 05 15:44:05 that said, you need to iterate over the packages in PACKAGES and get PKG_ Mar 05 15:44:10 PKG is a per-package variable Mar 05 15:45:10 aha, thats why debian.bbclass is doing it like that Mar 05 16:03:15 kergoth: I am still confused... I loop through d.getVar('PACKAGES', True) and want to bb.data.setVar('RREPLACES', somestring, d) Mar 05 16:03:34 but of course I want to replce a specific package with its own specific replacement Mar 05 16:03:48 I guess the old mapping hook was running in the context of one package, now its all global Mar 05 16:04:25 are the actual packges referenced by PKG_ i.e. newpkg = d.getVar('PKG_' + pkg) Mar 05 16:04:26 ? Mar 05 16:04:30 trying to make sense of the debian.bbclass Mar 05 16:05:28 i'll get back tou you, hard to type holding a baby in one arm:) Mar 05 16:05:56 np :) thanks Mar 05 16:06:01 I'll continue digging in the meantime Mar 05 16:12:26 actually I think I am starting to understand how debian.bbclass does it, testing now... Mar 05 16:16:26 or maybe I don't, doh Mar 05 16:20:52 Jin^eLD: for pkg in d.getVar('PACKAGES', True).split(): pkgname = d.getVar('PKG_' + pkg) or pkg; if 'glibc' in pkgname: ... Mar 05 16:22:11 that's close to what I had, let me correct my code Mar 05 16:22:56 naturally you'll then d.setVar('PKG_' + pkg, newpkgname) or whatever Mar 05 16:23:24 I was trying: Mar 05 16:23:24 bb.data.setVar('RREPLACES_' + newpkg, replace, d) Mar 05 16:23:27 but that did not work out Mar 05 16:23:32 but my problem was earlier Mar 05 16:23:41 actually that code did not get triggered yet because I messedup above Mar 05 16:24:00 running it now with your changes applied Mar 05 16:24:49 you'll want d.appendVar('RREPLACES_' + pkg, ' ' + replace), ideally. then it won't blow away any existing value Mar 05 16:25:03 oh ok Mar 05 16:25:11 note tha the rereplaces variable name ahs to be pkg, that's what the packaging code will look for, not the post-renamed value Mar 05 16:25:49 I do not rename the package name at all, I just add RREPLACES/RCONFCLICHTS Mar 05 16:26:26 ah, right Mar 05 16:27:04 cool! it worked now Mar 05 16:27:19 I had this part wrong: newpkg = d.getVar('PKG_' + pkg) or pkg and your line did the trick Mar 05 16:27:38 the 'or pkg' is needed to handle the case where PKG_ isn't set Mar 05 16:27:49 * kergoth gets breakfast Mar 05 16:28:18 thanks a lot once more! Mar 05 16:28:24 np Mar 05 16:31:16 trying to fix your upgrade path, i assume? Mar 05 16:31:21 yes, exactly Mar 05 16:31:28 switching from poky 1.5.3 to 1.7.1 in a live update Mar 05 16:31:44 good luck :) Mar 05 16:31:48 thanks ;) Mar 05 16:32:35 well, I managed to do it from OE-classic -> OE-core ;) so 1.5.3->1.7.1 should be managable :) Mar 05 16:33:49 impressive Mar 05 16:34:05 alternatively: masochistic ;) Mar 05 16:34:13 both, really Mar 05 16:34:35 hehe, well, it was a live product so it had to be done Mar 05 16:34:43 and it did work in the end Mar 05 16:34:49 * kergoth nods Mar 05 16:35:12 * JaMa assumes smaller image and users not installing extra apps from feed, right? Mar 05 16:35:35 JaMa: image was not that small actually but the users only get a fixed set of packages Mar 05 16:35:48 because upgrading generic image + whole feed is very close to impossible with oe-core, which breaks upgrade paths in so many cases Mar 05 16:35:51 so at least I had a controlled environment Mar 05 16:36:14 also I did it in two steps, they had to press uprade twice Mar 05 16:36:44 i.e. everyone had to upgrade to some defined maintained end-state of OE-classic which had all the preparations for the "big" upgrade, this end step also installed new feed URLs Mar 05 16:37:04 and then they pressed upgrade the 2nd time and now they were fetching it from the new OE core feed URLs Mar 05 16:37:12 that way it was doable Mar 05 16:37:16 sounds good :) Mar 05 16:38:17 have you verified that the end state in oe-core is exactly the same (or at least very close) to what you get from fresh install (if there is possibility to do fresh install on that product)? Mar 05 16:38:36 I'm interested if you've found many left-over artifacts left by the upgrade Mar 05 16:38:56 end state of OE classic you mean? Mar 05 16:39:05 even the conffiles could be real pain for average enduser on such big upgrades Mar 05 16:39:17 no the final end state is more interesting :) Mar 05 16:39:18 I had rules in place in task images to force removal of certain things that became obsolete Mar 05 16:39:42 and was it done with opkg or other manager? Mar 05 16:39:44 and the user is not supposed to mess with the conf files manually Mar 05 16:39:47 it was done with opkg Mar 05 16:40:23 mostly the user can configure network/hostname and that's about all he/she needs Mar 05 16:40:35 interesting.. last such big upgrade with opkg ended with libc6 removed from image, before new one was installed :) Mar 05 16:40:46 lol Mar 05 16:40:48 :) Mar 05 16:40:56 I think opkg had a bug in that regard Mar 05 16:41:00 I remember something like that Mar 05 16:41:04 but it got fixed I believe Mar 05 16:41:21 it worked for us in the end Mar 05 16:43:05 all the stuff is online btw in a gitorious repo if you really want to relive my masochistic experience ;) Mar 05 16:43:55 Ihttps://code.google.com/p/opkg/issues/detail?id=71 Mar 05 16:44:20 gitorious? so not for very long :) Mar 05 16:44:39 well, --force-reinstall may indeed be a call for trouble Mar 05 16:44:47 I had a case where I just could not reinstall busybox :) Mar 05 16:44:52 and ended up reflashing my baord Mar 05 16:44:55 board Mar 05 16:44:59 but it worked for an upgrade Mar 05 16:45:09 good work Mar 05 16:45:10 i.e. if you had a newer version it was OK, it got replaced Mar 05 16:46:18 yup Paul did a lot of good improvements Mar 05 16:46:26 pitty he doesn't have time to work on it more now Mar 05 16:47:10 before that Graham was the maintainer? Mar 05 16:47:47 btw that's our repo with classic and core angstrom, and now we switched from angstrom to poky although no live update path is available for that :) Mar 05 16:47:49 https://gitorious.digitalstrom.org/dss-oe/dss-oe Mar 05 16:48:30 we did try to submit some patches to opkg, I think one or two got in but it ended nowehere in the end, I did not check back for a long time and only now saw that Paul took over Mar 05 16:48:36 so I guess we'll try to resubmit Mar 05 16:49:14 Paul recently steped-down because of lack of time Mar 05 16:49:32 so the chances for merge are now low Mar 05 16:50:02 damn, we missed our window again :) Mar 05 23:20:00 is the opkg message Breaking cicular dependency on xxx something I should worry about? or rather information that some problem was actually resolved? Mar 06 02:07:47 ERROR: Multiple .bb files are due to be built which each provide jpeg (/home/balister/src/oe-core/meta-oe/meta-oe/recipes-core/jpeg/libjpeg-turbo_8d+1.4.0.bb /home/balister/src/oe-core/oe-core/meta/recipes-core/jpeg/jpeg_8d.bb). Mar 06 02:07:52 any comments on that? **** ENDING LOGGING AT Fri Mar 06 02:59:58 2015