**** BEGIN LOGGING AT Fri Sep 09 02:59:58 2016 Sep 09 06:47:13 hi. need a hint. i have a custom recipe that installs a firmware. a file with the same name is included in the linux-firmware recipe. Sep 09 06:47:51 now whenever i change from including my recipe to the linux-firmware i get a very dramatic error message indicating that there is a conflict: two files installed at same path Sep 09 06:48:28 why does the yocto not understand that i've removed my custom recipe so there is no longer a conflict? Sep 09 06:48:31 my recipe: https://gist.github.com/anonymous/187c3d5df05754738bdc6a22fe67ab13 Sep 09 06:51:19 running cleansstate on both recipes fixes the issue. but i would still like to know why that happens... Sep 09 07:00:51 ionte_: no doubt the old file was still installed in a sysroot. you should probably set RCONFLICTS_${PN}, RREPLACES_${PN} and maybe RPROVIDES_${PN} to "linux-firmware-wl18xx" or whatever the corresponding package is Sep 09 07:02:32 jku: are files not automatically uninstalled when removed? so if i add like 20 packages while testing things, and then remove them from the image recipe, they will still be deployed until i do a complete clean? Sep 09 07:02:50 RCONFLICTS seems right, thanks! Sep 09 07:03:03 ionte_: they may be in sysroots yes Sep 09 07:03:30 oops. ok. good to know. Sep 09 07:04:05 there's a script "wipe-sysroot" for those cases where you want to be sure you don't have anything extra there (like testing that your recipe has all dependencies listed) Sep 09 07:42:05 is there any good writeup on package management in yocto? pros and cons of rpm vs opkg etc? Sep 09 07:43:30 ionte_: are you space restricted? Sep 09 07:43:49 ionte_: i'm not sure it makes much of a difference in the real world... Sep 09 07:44:37 package manager smart for rpm drops in with 40MB (dependencies and it's cache) Sep 09 07:45:01 opkg is one megabyte or something like this. Sep 09 07:46:44 fragfutter: ok. i'm actually not that interested in package management. we will do most firmware updates by flashing a complete new image. but every now and then, mostly during development, it would be convenient to be able to install a package without having to reflash the whole thing Sep 09 07:47:03 sounds like opkg is the best choice for me...? Sep 09 07:48:21 ionte_: do you have experience with rpm or opkg? extracting content of an uninstalled package and stuff like this? then go with the one you know. Sep 09 07:50:55 ionte_: even without package management rpm uses more space. So if the system is tight use opkg. I prefer rpm as it is a well known format outside of the embedded world and colleagues can look into rpms, i can use my stock rpm package feed server, etc. Sep 09 07:52:48 yeah, i'd go with whatever your team knows best... that's a pretty important criteria in your case Sep 09 07:59:28 davis: there's your problem: /home/davis/setup-scripts/build/tmp-glibc/work/corei7-64-oe-linux/pcmx/1.0.0+gitAUTOINC+d3_d3v16_pcmx-r0/build/bin/abllib_metrics_header_generator Sep 09 07:59:30 ok! thanks for your input! i know my way around rpm, but i think i'll test both... Sep 09 07:59:45 davis: it tries to run the generator built for the target, you need to change your cmake so it runs the one built for your host Sep 09 08:03:38 ohboy, ohboy! first image booting up and runs our custom applications with all dependencies. Sep 09 08:03:46 ionte_: I was going to add that if you don't know any packaging system, opkg is probably the easiest to quickly learn (opkg -h tells you more or less what you have to know) Sep 09 08:15:56 ionte_: my default image using rpm including smart package manager: 102MB, after running smart update (creates caches), 144MB, Sep 09 08:16:12 ionte_: still rpm, without smart package manager 74MB Sep 09 08:16:40 (booted image size) Sep 09 08:19:37 is it possible to add something to the start of PATH in bitbake? Sep 09 08:25:34 Phlogistique: Yes, I've seen a patch on a mailing list that does it Sep 09 08:25:57 Phlogistique: http://lists.openembedded.org/pipermail/openembedded-core/2015-February/101489.html Sep 09 09:22:10 another question. i'm writing a recipe for a source that i have no control of. the source directory includes a Makefile that can't be used. i've created a do_install that handles the installation. how can i stop bitbake from using the Makefile? i have created empty do_configure and do_compile, but it feels like a hack Sep 09 09:22:42 thats the exact fix Sep 09 09:23:00 default do_compile is to run make, if you don't want that then replace do_compile Sep 09 09:25:09 ok. my problem is that i have two very similar recipes, one for a project with a Makefile and one without. for some reason bitbake fails to create opkg package for the one with the Makefile (there's no error message except a return code), but not the other, is there something more i need to override? Sep 09 09:25:40 impossible to say without seeing the recipe and logs Sep 09 09:25:56 if you're installing by hand then the packaging not working is your problem Sep 09 09:27:17 well, the strange thing is when building without package-management enabled it works... Sep 09 09:28:06 the failing recipe: https://gist.github.com/d278a1dd13090896b7f2017f980a133f Sep 09 09:28:56 package management is purely image-time so won't impact your recipe Sep 09 09:30:00 rburton: building the image without package-management in EXTRA_IMAGE_FEATURES works Sep 09 09:30:18 you could use their makefile btw Sep 09 09:30:53 oe_runmake install DEST_DIR=${D} BASE_LIB_DIR=/lib Sep 09 09:31:11 oh and set MACHINE_NAME Sep 09 09:31:43 ionte_: you can set do_configure[noexec] = 1 in your recipe Sep 09 09:32:15 hi everyone Sep 09 09:32:31 is it possible to disable postinst scripts for a package? Sep 09 09:32:42 ionte_: run oe-pkgdata-util list-pkg-files wilink8-bt Sep 09 09:32:57 aurele: don't write any? Sep 09 09:33:02 net-snmp post-inst blocks my boot and I really don't need what he would do Sep 09 09:33:23 a bbappend may be able to unset it, but it depends on what is writing the postinst Sep 09 09:33:29 rburton, if only I had written this... but it isn't mine... Sep 09 09:34:03 I think it is not the receipe itself... Sep 09 09:34:18 aurele: you can bbappend to a recipe Sep 09 09:34:55 rburton, maybe it is linked to INITSCRIPT_PARAMS_${PN} Sep 09 09:35:11 boucman_work: just that line, "do_configure[noexec] = 1"? it failed with a parse error Sep 09 09:35:35 ionte_: quotes around 1 Sep 09 09:35:51 right, my bad Sep 09 09:36:06 right. thanks. Sep 09 09:36:10 rburton, the install script just enables the startup script or service for snmpd depending on the init program Sep 09 09:38:12 oh. i found my error. there was a warning while building my recipe cause i had not added the installed files to FILES_${PN}. it was just a warning, so i did not see it until i did a cleansstate. fixed it, and now package generation works. Sep 09 09:38:43 oh yeah files is wrong Sep 09 09:38:54 just set FILES_${PN} = "/lib/firmware" :) Sep 09 09:40:41 ionte_: the latest version of the reference manual has more information on the default behavior of tasks btw: http://www.yoctoproject.org/docs/2.2/ref-manual/ref-manual.html#ref-tasks-compile Sep 09 09:41:33 Ulfalize: thanks! Sep 09 09:49:56 in a recipe, is there a conditional if variable is set, then also set this variable? Sep 09 09:51:23 if FOO; then EXTRA_OEMAKE += 'something ${FOO}'; fi Sep 09 09:52:28 fragfutter: can be done with bb.utils.contains() and inline python or anonymous python functions Sep 09 09:52:58 see https://www.yoctoproject.org/docs/2.2/bitbake-user-manual/bitbake-user-manual.html#inline-python-variable-expansion and https://www.yoctoproject.org/docs/2.2/bitbake-user-manual/bitbake-user-manual.html#anonymous-python-functions Sep 09 09:53:44 might make sense to make FOO empty if the condition isn't met via an override too. depends on what you're trying to do. Sep 09 09:54:27 i have a class, id defines FOO as empty, but recipes using the class can set FOO. if FOO is set i need to append a bunch of flags and the value of FOO to EXTRA_OEMAKE. Sep 09 09:55:18 ok, an anonymous python function or inline python might make sense then Sep 09 10:00:46 like this? s://gist.github.com/fragfutter/b88346f31219eeabd31998fdfedab065 Sep 09 10:02:34 fragfutter: yeah, that should work. you want to pass True as the second argument to getVar() though. otherwise, references to other variables in the value of MAKE_CONF won't get expanded. Sep 09 10:02:56 i'm working on latest krogoth branch and I have a problem with post install script of net-snmp-server, I cant find wich line set such a script Sep 09 10:03:20 TypeError: getVar() takes at least 3 arguments (2 given) Sep 09 10:03:29 ah stupid me Sep 09 10:03:35 check that you're not overquoting stuff too. the single quotes around MAKE_CONF look weird Sep 09 10:04:01 fragfutter: EXTRA_OEMAKE += "${@'MAKE_CONF=%s/%s' % (d.getVar('COMMON_MAKE_PATH', True), d.getVar('MAKE_CONF', True)) if d.getVar('MAKE_CONF', True)}" Sep 09 10:04:02 that stuff won't get passed through a shell, so nothing will remove those Sep 09 10:04:52 does the same thing without using an anonymous python function; you might want to wrap the python code in a function, though Sep 09 10:06:41 needs an else '' there too in the inline version Sep 09 10:06:49 how can i remove updatercd_postinst from startup postinstall scripts? Sep 09 10:07:31 neverpanic: understood, but for me unreadable in two weeks :) Sep 09 10:09:45 Ulfalize: quotes are required, $(COMMON_MAKE_PATH) is not expanded by bitbake and passed excatly like this to make. Sep 09 10:09:54 and it works. Sep 09 10:10:00 thanks all around Sep 09 10:11:22 fragfutter: $(COMMON_MAKE_PATH) won't get expanded though, because only ${} stuff is. you're passing the literal string 'MAKE_CONF=$(COMMON_MAKE_PATH)...', which probably isn't what you want. Sep 09 10:11:38 does anyone knows why a package would install a postinstall script and how to remove it? Sep 09 10:11:51 e.g., when make looks at that argument, it will see a quote character at the beginning Sep 09 10:11:58 there's no shell to remove that quote Sep 09 10:12:11 the postinstall function is given by systemd and update-rc.d bbclasses Sep 09 10:12:43 those post-install scripts are needed at package install but not at startup... Sep 09 10:12:57 hmz, actually... that might work Sep 09 10:13:08 and I have the problem only with net-snmp Sep 09 10:14:16 yeah, never mind. it will actually get passed through the shell. Sep 09 10:14:22 Ulfalize: at some point it is expanded. Sep 09 10:14:32 yeah, ignore me. i'm just being confused. :) Sep 09 10:15:06 if it wasn't expanded, there'd be no way to pass multiple arguments either. ${EXTRA_OEMAKE} appears within e.g. the shell function oe_runmake_call, and after it's expanded, the shell will take care of the quoting. Sep 09 10:15:21 Ulfalize: checking run.do_compile, the command, that one fails make -j8 ... MAKE_CONF=$(COMMON_MAKE_PATH)/Make.cmw "$@" Sep 09 10:16:04 the quotes shouldn't be necessary though. bitbake won't do anything with $(COMMON_MAKE_PATH). Sep 09 10:16:18 and there are no spaces in the argument Sep 09 10:16:47 but it's not a huge deal :P Sep 09 10:17:11 but run.do_compile is a large shellscript, so it will substitute $() (same as ``) Sep 09 10:17:44 and i need it to get passed to make, so make will expand the variable Sep 09 10:18:03 hmm, you might be right Sep 09 10:18:14 quoting hell and variable expansion Sep 09 10:19:34 i wonder what bitbake's shell does with $(). in the sense of command substitution, that's a bashishm. maybe it's still supported though... Sep 09 10:19:44 you're right though. safest to quote it. Sep 09 10:19:48 how to configure yocto to use gstreamer1.0_git.bb instead of gstreamer1.0_1.8.3.bb Sep 09 10:20:27 PREFERRED_VERSION_gstreamer1.0 = "git%" doesn't work ? Sep 09 10:21:11 does it work without the % ? Sep 09 10:21:44 I'm trying that right now Sep 09 10:22:19 you need to put the real version, so look in the recipe to see what it sets PV to Sep 09 10:23:10 sims like the pattern is 1.8.2+gitAUTOINC+3de8a4f728 so 1.8.2+git% should work Sep 09 10:24:15 yes Sep 09 10:25:40 yep is working thanks boucman_work & rburton Sep 09 10:39:32 fragfutter: sure, unreadable, but you could make it EXTRA_OEMAKE += "${@generate_make_conf(d)}" followed by def generate_make_conf(d): ... that does what you need Sep 09 10:39:35 much more readable Sep 09 10:47:27 good morning Sep 09 10:48:16 rburton: neverpanic I finally figured out the inherit and BBCLASSEXTEND problem. I see what you folks were telling me now. Sep 09 10:48:34 ive got one recipe which builds host first and then target. Sep 09 10:49:07 i appreciate your help. Give me your address and I will send you a post card. I am a happy lad. Sep 09 10:58:33 has anyone using meta-oe's xorg scripts looked at the patches from jussi to remove it? Sep 09 12:29:59 is there a (clean) way to append/prepend to def-style python functions? def foo_append() doesn't seem to work. Sep 09 12:30:10 no immediate need. just got curious. Sep 09 12:36:40 seems yocto on fedora isn't the most tested route Sep 09 12:36:53 * zeenix installs debian in Boxes Sep 09 12:42:20 zeenix: absolutely tested and supported Sep 09 12:42:44 zeenix: caveat: if you're using krogoth on f24 then you'll need to use the git branch as gcc6 is too new Sep 09 12:44:13 (f24 won the race to be the first mainstream distro to ship gcc6 and released about a week before we did) Sep 09 12:44:57 * joshuagl runs YP/OE builds on Fedora every day Sep 09 12:45:22 and so does the autobuilder Sep 09 12:45:57 that's true, I just sent a patch to update SANITY_TESTED_DISTROS for f24 Sep 09 12:46:53 yeah well remembered Sep 09 12:47:38 rburton, oh? Sep 09 12:48:03 rburton, the main issue i had was with qemu's configure failing on pulseaudio libs Sep 09 12:48:22 with krogoth? Sep 09 12:48:51 i tried seeing if removing the check in configure helps but then i end up with link issues Sep 09 12:49:15 rburton, no, actually it's a old branch we use that's been known to work for our target Sep 09 12:49:27 right Sep 09 12:49:40 so krogoth should work? Sep 09 12:49:50 so cherry-pick the fixes for qemu that we're backported to the last three or so stable release branches Sep 09 12:51:57 unfortunately if you're building old branches you probably need to build on older distros Sep 09 12:52:20 maybe buildtools for that release would help Sep 09 12:55:53 buildtools likely won't help the qemu farce Sep 09 12:57:01 zeenix: unless your branch is very old then oe-core's branches will have the commits you want to cherry-pick to work on a modern host. note that debian and ubuntu break the same way now. Sep 09 12:58:11 rburton, hmm.. it builds fine for my colleagues who are all using debian :( Sep 09 12:58:43 yeah, older distros :-) Sep 09 12:58:59 * joshuagl stops trolling Sep 09 13:01:02 debian8 will break if you have enough host libraries installed Sep 09 13:01:49 i think they all use testing Sep 09 13:05:51 well i suggest testing with something like master or the latest krogoth release, if qemu builds fine then you know you need to backport the qemu fixes. Sep 09 13:07:20 i actually made progress with cherry-picking already Sep 09 13:08:41 tell me what version your branch is based on and i can point you to the commits - there's a few needed that are non-obvious Sep 09 13:10:14 40376446904ae3529be41737fed9a0b650ed167d Sep 09 13:11:11 zeenix: thats jethro, right? Sep 09 13:11:40 xorg-lib: allow native building without x11 DISTRO_FEATURES Sep 09 13:11:46 base: check for existing prefix when expanding names in PACKAGECONFIG Sep 09 13:11:57 libsdl: expand PACKAGECONFIG and enable native builds Sep 09 13:13:29 and then remove libsdl-native from ASSUME_PROVIDED in your local.conf Sep 09 13:21:22 hello Sep 09 13:21:46 i've got a strange failure while building an extended sdk for beaglebone Sep 09 13:22:26 ImportError: No module named oe.recipeutils Sep 09 13:23:11 the import statement is from file: poky/scripts/lib/devtool/upgrade.py Sep 09 13:23:32 if i remove that statement then it builds successfully Sep 09 13:24:17 any idea what the problem could be ? Sep 09 13:45:03 rburton, ah those messages were for me? Sep 09 13:46:02 rburton, i cherry-picked all patches from master that applies to qemu-native but i still see that pa missing error :( Sep 09 13:46:55 zeenix: yes those messages were for you Sep 09 14:05:39 rburton, i'm being pulled into the bar now Sep 09 14:05:46 rburton, thanks for your help! Sep 09 14:59:51 if i want do_configure to call a defined python function, what would be the syntax? Sep 09 15:20:03 RP: https://github.com/openembedded/bitbake/compare/master...kergoth:shallow-external?expand=1 -- i think this might be easier to review. the code which makes a repo shallow is a standalone script, with details in its description about how it works, renamed a couple methods for clarity, added a couple docstrings, and added a few comments. also split out a couple independent fixups into their own commits Sep 09 15:20:05 afk Sep 09 15:21:27 kergoth: I really really should have got this into M3 :/ Sep 09 15:21:54 heh, there was an awful lot going on, broken builds, patch backlogs, i get it. not ideal, but it happens Sep 09 15:42:09 hello, I'm getting this weird build error from the cmake_3.6.1.bb recipe: tmp/sysroots/x86_64-linux/usr/lib/libcrypto.so.1.0.0: version `OPENSSL_1.0.0' not found (required by bin/cmake) Sep 09 15:44:33 I'm not sure where to go looking for the root cause so any help would be appreciated Sep 09 16:11:40 hi all, I'm working with Yocto Krogoth and running into an issue with the Toaster GUI, I hope nobody minds me reporting it here. Anyway, I have created a "custom image" which used to work great, and I can still build this particular image (>90 times build without any issues). But when I want to modify this image now, I'm running into a "operationalerror - database is locked" error. Also when navigating to "custom images" in the interfac Sep 09 16:11:54 I have a log file from django over here >> http://dpaste.com/0C9EDD3 Sep 09 16:13:01 maybe I'm better off migrating my custom image in toaster to a dedicated image recipe, but maybe anyone has seen this before and has an idea how to resolve this. Thanks in advance anyhow! Sep 09 16:14:28 everything else in toaster seems to be working without any issues Sep 09 16:15:41 zebaz: i'm a toaster noob, so don't shoot me if i break something toaster-specific, but a general tip is to try removing tmp/ inside your build directory Sep 09 16:16:52 also check if you have any runaway processes that didn't terminate properly and might be holding locks Sep 09 16:19:02 tmp/ holds the ${WORKDIR}s for recipes, staging sysroots, etc. usually removing it isn't a big deal w.r.t. build time, because it can get repopulated from the sstate cache Sep 09 16:19:53 it also has some sqlite3 databases that keep track of file permissions for fakeroot. see http://www.yoctoproject.org/docs/2.2/ref-manual/ref-manual.html#fakeroot-and-pseudo. Sep 09 16:20:14 probably not related to those though, but could be worth a try at least Sep 09 16:21:22 thanks a bunch Ulfalizer, I will try removing the tmp dir in my build-toaster directory, and pray I won't break anything ;) Sep 09 16:21:38 could just move it too if you're worried :P Sep 09 16:24:20 that was my plan ;) Sep 09 16:24:52 love toaster though, moved from console to hob and now toaster and my life is sooo much easier Sep 09 16:24:57 let's see if I can revive it Sep 09 16:26:05 any idea though where custom images are stored by toaster? I was afraid I would destroy my custom image setup by deleting tmp folders; anyhow Ill make a backup anyway, can't go wrong with that Sep 09 16:26:08 thanks for the pointers! Sep 09 16:27:00 normally build output would be in tmp/deploy Sep 09 16:28:08 it always irks me that build output is in a directory called tmp. feels wrong for some reason. :P Sep 09 16:28:12 ah yeah, I explained incorrectly, I meant the location of the "custom image recipe" which are derived from other recipe files Sep 09 16:28:22 * Ulfalizer would've preferred work/ Sep 09 16:28:36 no idea there Sep 09 16:30:48 maybe I'll just run my searchmonkey through the files and see if I can find it Sep 09 16:31:31 Ulfalizer: tmp/ is just a variable, change it :) Sep 09 16:31:56 and yeah, tmp folder for build output was a little bit counter-intuitive for me as well when I got started with yocto; but I can live with it Sep 09 16:32:06 Ulfalizer: a substantial part of tmpdir's content really is temporary. it's too bad sstate assumes everything is relative to tmpdir, you can't move stuff out Sep 09 16:32:06 rburton: i'm not that passionate about it :) Sep 09 16:34:05 makes me think of /tmp, which automatically makes me think "unimportant stuff not worth looking at", so mostly that :P Sep 09 16:35:17 i kind of regret the convention to call topdir build, as build would have been a decent name for tmpdir Sep 09 16:36:31 yeah, "build" seems nice Sep 09 16:38:27 Hmm, if we set TMPDIR = "${TOPDIR}" and rearranged some things relative to it, sstate would probably still work. shifting the contents of tmpdir up a level, then move a few things in there to organize it and not clutter up the root so much.. Sep 09 16:50:13 only thing in tmpdir I care about (typically) is logs and the 'deploy'.. Sep 09 16:50:23 everything else is stuff most people shouldn't care about Sep 09 16:50:34 (and as any 'tmp' is destroyable, because it can be recovered via teh sstate-cache Sep 09 16:55:17 indeed, true Sep 09 16:55:34 I've often considered moving logs and deploy, but leaving everything else under 'tmp' Sep 09 16:55:59 what we ended up doing in WR 8 and prior was a seperate class that linked the items in tmp/deploy to a location outside of tmp.. Sep 09 16:56:18 that way if someone DID 'rm' tmp, the link broke and it was obvious it had been 'cleaned up'.. preventing errant copies from sitting around Sep 09 16:56:19 https://mail.python.org/pipermail/python-dev/2016-September/146327.html Sep 09 16:57:18 huh Sep 09 17:16:03 just fyi, regarding my previous issue with my database being locked with my custom image in Toaster; I just did another rebuild and suddenly database was magically unlocked again, no need for nuking my tmp folder luckily; will probably export my custom image as bb file from toaster to be safe in the future, as toaster saves custom images in database, not in bb files, from what I saw in the django source Sep 09 17:40:05 anyone around understand bitbake enough.. I'm tring to figure out where the 'include' and 'require' directives are processed.. I see that they eventually appear to go through an 'eval' and then eventually the 'handler' functions.. but I can't see to find where they are initially parsed Sep 09 17:41:25 regex in lib/bb/parse/parse_py/ConfHandler.py produces ast nodes from lib/bb/parse/ast.py which are then evaluated Sep 09 17:42:56 ahh I wasn't looking deep enough in the dir structure! Sep 09 17:44:43 trying to figure out how BLANK = "" inherit ${BLANK} works, but include ${BLANK} does not Sep 09 17:45:30 handle() in lib/bb/parse/__init__.py is the entry point, you can walk it down from there if you're curious Sep 09 17:45:52 speaking of, we need some better parsing api functions. i.e. parse specified string and return ast nodes Sep 09 17:47:17 looks like the parsing functions are the same for inherit, include and require.. next step.. ast.handleInherit and ast.handleInclude Sep 09 17:48:01 indeed Sep 09 17:48:38 def handleInherit(statements, filename, lineno, m): Sep 09 17:48:38 classes = m.group(1) Sep 09 17:48:38 statements.append(InheritNode(filename, lineno, classes)) Sep 09 17:48:42 def handleInclude(statements, filename, lineno, m, force): Sep 09 17:48:43 statements.append(IncludeNode(filename, lineno, m.group(1), force)) Sep 09 17:48:51 isn't that basically the same thing? Sep 09 17:49:15 yes, so the differentiation will be in the eval() of IncludeNode and InheritNode Sep 09 17:49:22 most likely, anyway Sep 09 17:49:27 ahh my eyes missed that nuance Sep 09 17:58:40 ok.. I give up for now.. I don't understand the code path.. and frustration won't make it go any faster.. :/ Sep 09 17:58:57 what I'm trying to do for reference is: Sep 09 17:59:13 BLANK = "" inherit ${BLANK} (appears to work) Sep 09 17:59:23 while 'include ${BLANK}' reports an error: Sep 09 17:59:34 /: not a BitBake file Sep 09 17:59:44 that error comes from parse/__init__.py, 'handle' function.. Sep 09 18:00:11 so the 'fn' was expanded to include the path of the calling item, but since it was blank, nothing appended and the handler function failed to find an include handler.... Sep 09 18:00:44 https://autobuilder.yoctoproject.org/main/ is ready for new work. Sep 09 18:02:18 fray: are you investigating this for something in particular? Sep 09 18:02:23 or just curious? Sep 09 18:02:28 yes.. I need an optional include file Sep 09 18:02:33 (the name can change) Sep 09 18:02:47 so I have implemented today is: Sep 09 18:02:52 'include' is already optional. 'require' is the non-optional include. Sep 09 18:03:38 WRTEMPLATE_INC ?= '${@['conf/template.conf', ''][d.getVar('WRTEMPLATE_ENABLE', True) == '1']}" Sep 09 18:03:41 but yeah, in case you need the variable it might not be that simple Sep 09 18:03:42 include ${WRTEMPLATE_INC} Sep 09 18:03:56 so it can set to 'whatever' as one method of override.. Sep 09 18:04:06 or the default value, but disabled in that WRTEMPLATE_ENABLE is not set to '1' Sep 09 18:04:14 but that doesn't work since include is not allowed Sep 09 18:04:17 (it works in inherit) Sep 09 18:04:27 I can change the 'blank' to 'notdefined.inc' and it works fine Sep 09 18:04:40 ....until someone comes along and implemented a 'notdefined.inc' :/ Sep 09 18:04:46 as a hack, you could use 'thisfilewontexist' instead of '' Sep 09 18:04:58 not sure about the original problem though Sep 09 18:05:09 has to end in .inc, .bbclass or .conf ;) but yes.. that works.. but I think it should be fixed.. Sep 09 18:05:10 yeah Sep 09 18:05:23 inherit was fixed a long time ago to permit 'blank', but it doesn't appear include or require permits it.. Sep 09 18:05:34 I'd rather change it to 'require'.. so if it's define it's mandatory Sep 09 18:06:44 I can see the symptom, I can figure out where the error is coming from -- but I'm lost in the parsing and why inherit appears to work and include/require does not.. some how inherit must be implicitly looking for a blank and skipping it Sep 09 18:06:51 while include/require doesn't do that Sep 09 18:08:29 i'd throw some prints at it. see what ends up in the AST node, and if it's any different from the inherit case. Sep 09 18:08:49 if it's the same, then try to trace further along where the nodes are processed Sep 09 18:09:27 If I get back to it I will.. I'm out of time to do that today Sep 09 18:10:09 the doc maintainer is a nice guy in case you discover/add something and want to add some documentation for it btw :) Sep 09 18:10:18 ha Sep 09 18:10:30 i'm not talking about me btw :P Sep 09 18:10:42 Anyone knows or any ARM boards like i.MX 6Quad SABRE Lite that has two CAN busses on board? I am looking for my research project Sep 09 18:10:48 i file doc bugs though Sep 09 18:12:06 at this point it's unclear if it's a bug.. enhancement request for sure.. but maybe not a bug.. Sep 09 18:12:15 was hoping ti would be obvious and I could just supply a change -- no luck Sep 09 18:28:50 fray: think i traced it out. there's some really questionable variable naming going on that makes things confusing. :S Sep 09 18:29:41 for includes, you end in 'def include()' in lib/bb/parse/parse_py/ConfHandler.py. 'fn' is the FileName. :P Sep 09 18:29:53 not 'function' Sep 09 18:30:32 yes.. and fn ends up with / Sep 09 18:30:52 for inherits, you end up in inherit() in lib/bb/parse/parse_py/BBHandler.py Sep 09 18:31:00 another not-function-fn :P Sep 09 18:31:03 correct Sep 09 18:31:19 so check what happens for the poorly-named fns there Sep 09 18:31:19 fn to me int hat context means filename.. so 'fn' isn't confusing to me.. ;) Sep 09 18:31:35 the handling, on the surface at least, looks the same Sep 09 18:31:39 it's extremely confusing to me, so please don't do that :/ Sep 09 18:31:44 if you ever feel like it :P Sep 09 18:31:55 even 'f' is infinitely better Sep 09 18:37:27 fray: i'm guessing what happens is that 'files' ends up empty in 'for file in files:' inherit(), while in include(), you always reach the bb.parse_handle(fn, data, True). Sep 09 18:37:54 *in inherit() Sep 09 18:38:53 'include' always takes a single argument as well. would just have to check if it's empty i think. Sep 09 18:39:28 maybe it makes more sense syntactically for 'inherit' to accept zero arguments though, since it already takes an arbitrary number of arguments Sep 09 18:39:46 dunno about pragmatically Sep 09 18:50:54 sorry about that naming rant. it's my trigger. :P Sep 09 18:56:36 inherit supports 0..n Sep 09 18:56:41 I would love to see include/require do the same Sep 09 18:56:52 (and I think that is a low impact update... I think) Sep 09 19:00:17 but I suspect you are right.. the 'files' processing is what permits this.. Sep 09 19:00:35 what's in the included file btw? would it hurt if it was included more than once? that can happen e.g. if both a bb file and a bbclass file used by it include the same file. Sep 09 19:00:56 I don't think there is a problem including stuff more then once... Sep 09 19:01:06 might be useful to filter, but it shouldn't be a problem Sep 09 19:01:08 if it could be included more than once, you could use that as an excuse to turn it into a bbclass. there's special processing for those so that they're only ever processed once. Sep 09 19:01:23 ok Sep 09 19:04:28 it looks like something needs to come after 'inherit' though. you get a parse error if you put it on a line by itself. Sep 09 19:05:39 it can only take zero arguments if that something is a variable that expands to nothing Sep 09 19:06:01 or ${}-thingy in general Sep 09 19:21:23 hmm, since bitbake is on python 3 now, should probably make use of some keyword-only arguments Sep 10 00:09:58 Hey, we finally "finished" the laserharp. Thanks everyone who helped! Part 1: < https://www.youtube.com/watch?v=seCaFMf5aRI > Part 2 < https://www.youtube.com/watch?v=2sJR8vJw9VY > **** ENDING LOGGING AT Sat Sep 10 02:59:58 2016