**** BEGIN LOGGING AT Fri Mar 31 03:00:03 2017 Mar 31 03:01:05 khem: i'd try inline python inside the postfuncs. if that doesn't work, could use anonymous python or an event handler to conditionally appendVarFlag Mar 31 03:01:31 not sure if the actual content of the postfuncs flags end up in the signatures, or only the actual pre/postfuncs Mar 31 03:01:39 event handler / anonfunc might be better to be safe on that.. Mar 31 03:01:41 * kergoth shrugs Mar 31 03:23:50 kergoth: I was trying to build OE using voidlinux which is a must based distro Mar 31 03:24:01 nice Mar 31 03:24:06 the base system was only taking 54M Mar 31 03:24:08 of ram Mar 31 03:24:24 but then I ran into this issue Mar 31 03:24:46 I wonder if we can just make this check pan libcs Mar 31 03:24:50 i was thinking about trying a build in alpine :) Mar 31 03:25:03 void is more desktopy Mar 31 03:25:23 you have XFCE, cinnamon options Mar 31 03:25:23 * kergoth nods Mar 31 03:25:25 nice Mar 31 03:25:28 will have to try it Mar 31 03:25:54 or you can also build xfce image for musl/OE and use that Mar 31 03:26:05 I have been using that with virtualbox Mar 31 03:26:12 works good Mar 31 04:29:20 RP: I haven’t carried an external patch to linux-yocto in a long time. so that could be triggering an error. I’ll apply that here and see if I can see the problem. Mar 31 09:46:36 hello guys Mar 31 09:47:49 could somebody help me with scons build system in yocto? Here is the output: http://ix.io/ps5 Mar 31 10:08:45 and here is the recipe: http://ix.io/ps7 Mar 31 10:29:37 Ox4: check config.log, maybe it tells you why the check fails Mar 31 10:31:40 So, just trying to be sneaky and understand how wic is doing things, I was able to follow this more or less: http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/scripts/lib/wic/plugins/source/bootimg-pcbios.py and end up with a single image that boots a kernel and drops into a shell Mar 31 10:31:54 with some simple 5 to 10 lines of shell Mar 31 10:33:02 but that's not really enough, from what I understand that part of wic is just creating a boot partition with syslinux/kernel/initrd in vfat, while probably mke2fs is used for the rootfs Mar 31 10:33:44 So my question is, how does wic assemble multiple filesystem images into a single partitioned image ? Mar 31 10:33:57 iiuc that must be what it's doing Mar 31 10:34:58 ed2: ^ Mar 31 10:35:00 Hello there, I am trying to build an image on a centos 7 host, but when I try to run source oe-init-build-env it says bitbake requires python3 Mar 31 10:35:06 jku: here it the config.log output: http://ix.io/ps8 Mar 31 10:35:44 gtristan: yes, it does. That's its main purpose I believe. Mar 31 10:36:15 When I setup python3 as default python interpreter it says openembedded requires python2 as default Mar 31 10:37:01 gtristan: it does it by copying partition images into the final image. Mar 31 10:37:02 ed2, any idea how, is there some tool wic uses to frob multiple filesystem images together without going through the loopback ? Mar 31 10:37:43 * gtristan looks into http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/scripts/lib/wic/partition.py Mar 31 10:39:02 gtristan: why would it need loopback? It prepares partition images and after they're ready it copies them into final image. Mar 31 10:39:08 ilkmc2r: setting python3 as default makes no sense: 'python' should be python2, 'python3' should be python3. OE uses py3 but some software we build still needs python to be python2 Mar 31 10:40:14 gtristan: general approach is to prepare filesystems by converting them from rootfs directory. You've mentioned it yourself yesterday. Mar 31 10:41:08 ed2, yeah, creating the filesys from a rootfs directory (i.e. mkfs.ext4 -d ${root}) I got that part :) Mar 31 10:41:28 it's the "and after they're ready it copies them into final image." that I dont quite grok Mar 31 10:42:24 ed2, I presume this does not mean, just append these filesystem images into a whole and hope for the best :) Mar 31 10:42:35 gtristan: it prepares final image with parted and copies partitions with sparse_copy to preserve sparseness. Previously it did it with dd. Mar 31 10:42:43 Ox4: if the error seems correct (so "-m64" is wrong), look in the projects scons build files. Figure out where -m64 comes from... Mar 31 10:44:09 rburton: now my python is python 2.7.5 python3 is python3.5.1 but still says openembedded requires python to be python v2 >=2.7.3 Mar 31 10:44:53 ed2, ah ok, I think I have the relevant stuff here: http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/scripts/lib/wic/plugins/imager/direct.py#n285 Mar 31 10:45:23 gtristan: assembling happens in PartitionedImage.assemble method. Mar 31 10:45:43 gtristan: yes, the code is in direct.py Mar 31 10:46:07 thanks :) Mar 31 10:46:40 ilkmc2r: can you prove that by pastebining python —version; python3 --version Mar 31 10:46:59 ilkmc2r: maybe you've other pythons around and bitbake is using a different one Mar 31 11:28:47 rburton: still a zoo of openssl failures :( Mar 31 11:29:01 Hello, I have updated my system and I run in a problem with QT 5.6 : I got the error : fatal error: QtGui/QAction: No such file or directory ! Do I have to add some new DEPENDS ? Mar 31 11:55:23 alimon: rpm4 notwithstanding, the RRS still hasn't been updated in weeks - e.g. this recipe is long gone http://recipes.yoctoproject.org/rrs/recipedetail/820/ Mar 31 11:55:38 alimon: can you fix that please, and try to make sure you get notified when things break Mar 31 12:28:26 jku: thank you very much I will try to investigate the problem Mar 31 12:28:46 is there a way to have in a recipe the setting for externalsrc and some SRC_URI but selecting on accourding to a environment variable ... or something comparable Mar 31 12:41:53 mdnneo: you can have multiple recipe versions (that might share a .inc for most of the recipe) and use PREFERRED_VERSION_ in your configuration to select which you want Mar 31 12:42:15 http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#var-PREFERRED_VERSION Mar 31 12:57:33 jku: ... trying to do more something like pseudo coded here https://pastebin.com/MhFkPL2M Mar 31 13:00:42 mdnneo: so is there a reason my suggestion does not work? Mar 31 13:04:23 jku: ok then I maybe misunderstood PREFERED_VERSION but I want to avoid providing two recipes ... anyway ... need to have a closer look then Mar 31 13:16:23 RP: python3/upstream-random-fixes.patch is impossible to understand or rebase :( Mar 31 13:16:56 RP: I have to update python3 to 3.5.3 in the openssl 1.1 branch (because prior versions don't support openssl 1.1), and I just dropped the patch for now Mar 31 13:17:58 kanavin: did that patch make it into 3.5.3? Mar 31 13:18:28 rburton: I couldn't even figure out that Mar 31 13:18:35 the patch is way too hairy Mar 31 13:19:56 god now you have me cloning python ;) Mar 31 13:20:25 we should really update to 3.6.0 anyway, but I'm not doing that ;) Mar 31 13:20:31 or 3.6.1 or what is the latest Mar 31 13:20:55 yeah a 3.6 upgrade can wait Mar 31 13:21:46 https://github.com/python/cpython/commit/035ba5da3e53e45c712b39fe1f6fb743e697c032 is the relevant 3.5 patch Mar 31 13:22:43 don't have a clone yet to see what tags that made it into Mar 31 13:25:08 rburton: the github page lists them at the top: 3.6.1, but not anything in 3.5 Mar 31 13:25:18 rburton: the upstream patch is pretty awful too Mar 31 13:25:50 rburton: no idea why the commit message talks about 3.5 Mar 31 13:29:07 kanavin: can we at least confirm that we're past the revision mentioned in the commit? Mar 31 13:29:55 kanavin: I think I did something horrible to generate that patch :/ Mar 31 13:30:34 RP: let me see if I can apply the upstream patch from the 3.5 branch though, might just work? (it arrived just after 3.5.3 and so isn't in any release yet) Mar 31 13:30:57 gaaah, how do I convince github webpage to give me the raw diff :/ Mar 31 13:32:05 .patch on the url iirc Mar 31 13:32:17 looks like they removed that feauture? don't really want to clone the repo just to cherry pick one commit Mar 31 13:32:31 i definitely did it last week Mar 31 13:32:37 kanavin: yes, that would work Mar 31 13:32:39 yeah https://github.com/python/cpython/commit/035ba5da3e53e45c712b39fe1f6fb743e697c032.patch Mar 31 13:33:05 kanavin: at the time I didn't want to have to start upgrading python to fix that issue (was close to release iirc) Mar 31 13:33:17 kanavin: we do need that fix if its not in 3.5.3 Mar 31 13:36:30 RP: yay it worked :) Mar 31 13:36:47 rburton: ^ Mar 31 13:36:51 kanavin: yay! Mar 31 13:37:12 cool Mar 31 13:39:18 RP: not sure if you've seen the comment, but there's still a zoo of failures with openssl 1.1, so I have things to do it seems :) Mar 31 13:39:42 mips support is broken, arm support is broken, ppc support is broken.... Mar 31 13:41:45 kanavin: I didn't but I'm not entirely surprised :( Mar 31 13:42:21 RP: yeah, I stated my plans in the commit I sent to the oe-core list today, I guess you're ok with it? Mar 31 13:42:59 kanavin: yes, fine with it, its in -next testing Mar 31 13:45:53 RP: I considered doing it the other way (1.0 stays as 'openssl', 1.1 is introduced as 'openssl11'), but I don't want it that way - no one will do anything to port to 1.1, until 1.0 is removed, and then there'll be lots of moaning. Mar 31 13:45:59 I'd like to gently push people here :) Mar 31 13:46:17 and it's trivial to remain on 1.0 Mar 31 13:46:24 if someone needs it Mar 31 13:52:33 kanavin: right, I agree fwiw Mar 31 14:50:23 Can wic can be used to generate an image that has to be written using mfgtools? (imx6) Mar 31 15:28:13 What do I have to write in a recipe if I want to use sources from the same repo as the meta layer, and not download a separate source repo? Mar 31 15:29:22 I hope I don't have to list every file with SRC_URI, as there are thousands of files Mar 31 15:38:00 iirc you can just put the directory in SRC_URI Mar 31 15:49:37 rburton: it seems it is, but it all ends up in recipe/${PV}-${PR}/. Apparently ${S) does not control the destination dir from the SRC_URI copy. Do you know which? Mar 31 15:51:10 correct, S is used to tell the system where do_configure/do_compile/do_install will run, it doesn't control extraction/unpack at all Mar 31 15:51:25 stuff is copied into WORKDIR/ Mar 31 15:52:55 hmm, WORKDIR/ gets gets very cluttered Mar 31 15:53:05 put it in a directory then :) Mar 31 15:53:12 maybe even call it PN-PV Mar 31 15:53:16 rburton: yeah, how? Mar 31 15:53:49 sveinse: https://www.yoctoproject.org/docs/2.2/bitbake-user-manual/bitbake-user-manual.html#bb-the-unpack Mar 31 15:57:34 argh why is cross-compiling to python so hard Mar 31 15:57:48 rburton: Thanks. Apparently I need a file://somedir;subdir=src foreach file: entry I use Mar 31 15:58:35 i'd hope that you could just do file://the/base/path;subdir=src? Mar 31 15:58:54 rburton: yeah, I think I have to Mar 31 16:05:34 How do I specify the root of my layer? SRC_URI = "file://../;subdir=src" caused cooker to fry :P -- and it does not feel right Mar 31 16:06:56 if you can put the sources alongside the recipe you're sorted Mar 31 16:07:38 *maybe* LAYERDIR? Mar 31 16:09:04 I wonder if I can override the unpack step and create symlink instead Mar 31 16:09:51 Wait, thinking loud, I can probably just modify S to point to the sources. The build process does not clobber the sources anyways Mar 31 16:10:06 that *might* work Mar 31 16:11:24 What is the process involved when it tries to determine rebuild for sources', e.g. the taskhash system? Because this would interfer with it wouldn't it? Mar 31 16:13:30 yes, because it wouldn't know if the files in S changed, as it assumes that they're in SRC_URI Mar 31 16:13:42 i guess you could put the path in SRC_URI then override do_unpack to do nothing Mar 31 16:13:48 or just stop trying to break the system ;) Mar 31 16:13:51 LAYERDIR won't be of much use in that context, it's only set during bblayers/laye.rconf parsing Mar 31 16:14:21 right Mar 31 16:14:46 right wasn't sure Mar 31 16:15:04 at mentor, we use https://github.com/MentorEmbedded/meta-mentor/blob/master/meta-mel/classes/layerdirs.bbclass + https://github.com/MentorEmbedded/meta-mentor/blob/master/meta-mel/conf/distro/include/mel.conf#L333-L339 for exactly that Mar 31 16:15:52 there might be a better way, but gets the job done Mar 31 16:18:06 What I'm trying to accomplish is that we have a large (hg) repo for a large Qt application (that supports a number of platforms, not just Yocto), and there is a wish to have the recipe together with the codebase. There has already been loss of synchronization between the meta layer and the code repo Mar 31 16:19:02 So I'm *trying* to avoid breaking the system, but acknowledge that this is not precisely the yocto-way... Mar 31 16:20:20 i've done builds of that sort before, though not recently Mar 31 16:20:55 kergoth: i like layerdirs Mar 31 16:21:37 should think about proposing a bitbake patch to save it instead, probably Mar 31 16:21:40 but it works Mar 31 16:22:21 yeah, would be handy if LAYERDIRS_[name] were available after parse for this Mar 31 16:22:25 iirc we used it to pull downloads from the layer for the recipe in question, but we ended up just making it pull any download from a downloads dir in any layer, instead, otherwise you can't supply additional downloads with a bbappend in an update layer Mar 31 16:22:51 still useful to be able to get the layer for the recipe for other reasons, though :) Mar 31 16:23:50 where in bb can I find the logic for unpack and how the taskhash for the sources are determined? Mar 31 16:24:16 unpack is easy, lib/bb/fetch2/__init__.py, unpack() method Mar 31 16:24:20 iirc its just whats in SRC_URI Mar 31 16:24:54 of course that's the default unpack method, the fetch method can customize this, i.e. git.py does a git clone to unpack Mar 31 16:25:09 so best to examine first the fetch method your'e using, then the base class Mar 31 16:25:35 for SCM based fetchers, does it rely on the git ID to determine rebuild/taskhash, or does it hashsum all files? Mar 31 16:25:46 the revision ID Mar 31 16:26:34 right. then it's this I need to plug into the recipe somehow Mar 31 16:26:55 need to read some code I think to understand it Mar 31 16:30:40 btw, mercurial/hg support is not working properly (we're using krogoth). It does not fetch properly when using sstate cache. So if the rev field is updated in a recipe, bitbake never fetches an update from the upstream source Mar 31 16:30:52 hm, forgotten how to get the SHA of the current checkout from sh Mar 31 16:31:11 Is this known? Otherwise, I should probably prepare a bugreport for it Mar 31 16:31:21 sounds like its worth a bug for sure Mar 31 16:32:02 yeah, ok, I will do that Mar 31 16:44:14 someone seeing this error http://sprunge.us/HiAW Mar 31 16:44:27 after todays updates Mar 31 16:50:46 khem: you need new bitbake Mar 31 16:50:52 there should have been a version check Mar 31 16:51:16 i wonder if the version check happened after the layer init… Mar 31 16:51:37 one thing poky is good for: keeping oe/bitbake requirements in sync :) Mar 31 16:51:41 * rburton -> dinner Mar 31 16:51:45 good weekend all Mar 31 16:53:35 rburton: I have all uptodate Mar 31 16:53:38 oe-core and master both Mar 31 16:53:47 for bitbake as well Mar 31 16:54:13 it should tell me whats wrong then I can fix Mar 31 16:56:18 ah automation gone wrong blame repo Mar 31 16:56:32 for whatever reason it did not fast forward bitbake Mar 31 16:56:49 it thought I have local changes that need manual attention Mar 31 16:56:58 I should trash this piece of junk Mar 31 16:57:35 i hate that behavior of repo. also the automatic rebasing of local commits really makes the shit hit the fan when my 'local commits' is a merge of 1k+ commits from another branch :P Mar 31 16:58:41 you say fan for me its hit the windmill Mar 31 17:25:08 anyone done runit for init system ? Mar 31 17:25:16 it seem pretty good fit Mar 31 17:25:38 systemd has become a hog for system Mar 31 17:25:59 you cant justify 20M of systems on a 64M rootfs Mar 31 17:26:30 and its BSD licensed cool Mar 31 17:39:46 god archiver is crap Mar 31 17:40:58 re-runs do_unpack/do_patch/etc after overriding WORKDIR, but do_unpack also wipes the STAGING_KERNEL_BUILDDIR and STAGING_KERNEL_DIR, neither of which are relative to WORKDIR, so the changes aren't properly isolated to archiver, causing races with the real tasks and other problems for recipes depending on the kernel sources and kernel build files, which were inadvertently wiped Mar 31 17:44:15 Guys how can I specify a SRC for a local repository? I mean, having the sources in my home directory. Mar 31 17:51:30 Nothing, have found it. Thanks anyways Mar 31 17:52:55 file:// or externalsrc. the latter is the better option Mar 31 17:53:04 or git:// + ;protocol=file if it's a local git repo, etc Mar 31 17:53:26 kergoth, is it possible to disable LICENSE checkings? Mar 31 17:54:05 not directly, no. worst case you could set LICENSE = CLOSED, which hacks past it for closed source proprietary stuff, but it's a temporary hack at best Mar 31 17:54:30 ok perfect thank you very much! Mar 31 18:31:52 kergoth: we used to use externalsrc for building the code which we talked about an hour ago, but it seems to trigger rebuild every time. I wonder if its possible to inject some scm ID check into the recipe, making taskhash generation correct Mar 31 18:40:42 aha, externalsrc only supports git for hashing, no other scm Mar 31 19:05:25 sveinse: now there is devtool Mar 31 19:05:56 I think externalsrc was a stop-gap for developers Mar 31 19:06:47 its better to not use it for system production/release builds Mar 31 19:10:24 khem: yes. this is production code thou Mar 31 19:12:29 The challenge is that this layer is also the main application code. Or, more precise, I want to add the recipe/layer into the main application repository. Mar 31 19:14:02 which is not in line with the yocto model with separate metas from sources Mar 31 19:39:17 If bitbake -c cleanall does not completely clean the sstatecache, how can I remove a recipe from it? I just ran bitbake -c cleanall e2fsprogs, but rerunning bitbake -v e2fsprogs seems to be using setstate despite the cleanall. What should I do? Mar 31 19:42:19 cleanall = clean + remove downloads Mar 31 19:42:23 cleansstate = clean + remove sstate Mar 31 19:42:31 you want cleansstate, not cleanall Mar 31 19:44:17 kergoth: ok, then this email from Paul Eggleton is wrong (or outdated then): "You may be thinking of "bitbake -c Mar 31 19:44:21 cleanall recipename" which cleans the working directory, sstate packages and Mar 31 19:44:22 downloaded files for the specified recipe (but not all recipes)." Mar 31 19:44:31 https://www.mail-archive.com/yocto@yoctoproject.org/msg12962.html Mar 31 19:45:39 I thought it was clean -- cleansstate = clean + remove sstate, cleanall = cleansstate + remove download Mar 31 19:46:26 don't do cleanall on gigabyte repos.... Mar 31 19:46:32 lol Mar 31 19:47:49 ah, indeed, i stand corrected: addtask cleanall after do_cleansstate Mar 31 19:50:14 and I do too. It does work. My culprit was a overlooked SSTATE_MIRRORS entry which fetched the entry from the central build server. -c cleanall has no dominion there :P Mar 31 20:02:48 sveinse: -C fetch is helpful when sstate mirrors are involved. forces it to build it from scratch regardless Mar 31 20:03:39 kergoth: ah, thaks Mar 31 20:07:59 Setting S="${THISDIR}/.." actually worked for building the top-level Qt application. qmake does not touch the sources and builds separately, so it is safe too. Mar 31 20:08:44 So the only thing remaining is to find a way to plug the repo/layer scm hash ID into the recipe for the taskhash/sstate cache to be correct and rebuild when it should Mar 31 20:37:02 What is the difference from "python some_python_function () {" and "def get_depends(d):" in a recipe? E.g. in externalsrc.bbclass I see both in use Mar 31 21:55:37 If I want to shell out to run a command once (and only once) and return its output into a BB variable, how and where do I do this? Mar 31 23:03:56 sveinse: only once is pretty much impossible. the metadata is re-parsed multiple times. even if you use := to force immediate expansion, it'll still be run every time a task starts Mar 31 23:04:05 sveinse: but bb.process.run() is likely the easiest Mar 31 23:04:21 if you're just looking to get a git revision, use git:// and put SRVPV in PV and call it a day **** ENDING LOGGING AT Sat Apr 01 03:00:02 2017