**** BEGIN LOGGING AT Tue Feb 20 03:00:03 2018
Feb 20 06:28:37 <yocti> New news from stackoverflow: Yocto - Try to use Realtime Kernel Version <https://stackoverflow.com/questions/47185572/yocto-try-to-use-realtime-kernel-version>
Feb 20 07:28:47 <yocti> New news from stackoverflow: Difference between SRC_URI and FILESEXTRAPATHS_prepend in bitbake <https://stackoverflow.com/questions/46342810/difference-between-src-uri-and-filesextrapaths-prepend-in-bitbake>
Feb 20 07:32:40 <Domin1k> Hi Folks, I have a problem with building a system with read-only-rootfs. I'm using Yocto-Dizzy after adding "read-only-rootfs" to "EXTRA_IMAGE_FEATURES" in "conf/local.conf" i faith the problem that some packages could't be configured as read-only-rootfs.
Feb 20 07:32:53 <Domin1k> The first Error is: "ERROR: The following packages could not be configured offline and rootfs is read-only: ['libomxil', 'gdk-pixbuf-loader-jpeg', 'gdk-pixbuf-loader-xpm', 'gdk-pixbuf-loader-gif', 'pango-module-basic-fc', 'gdk-pixbuf-loader-png']"
Feb 20 07:34:21 <Domin1k> How can add the capability for read-only-rootfs-configuration for these Packages? And How do i find out where these Packages belonge to?
Feb 20 07:36:36 <Domin1k> I'm using the old dizzy-release because i need the Layer: "meta-amd" which hasn't got support for rocko.
Feb 20 09:33:42 <acrap> Hi folks! Is there an opportunity to disable recipe from oe-core?
Feb 20 09:59:20 <yocti> New news from stackoverflow: Compile rygel for yocto with plugins <https://stackoverflow.com/questions/35704821/compile-rygel-for-yocto-with-plugins>
Feb 20 10:29:21 <yocti> New news from stackoverflow: Bitbake meta-toolchain-qt5: UnicodeDecodeError <https://stackoverflow.com/questions/48820227/bitbake-meta-toolchain-qt5-unicodedecodeerror>
Feb 20 10:55:41 <eduardas_m> rburton: hello, I have hit an issue when kernel headers are not included in the SDK I get with populate_sdk, even though my images build fine. How do I even start trying to resolve this issue?
Feb 20 10:56:13 <eduardas_m> so when using the SDK I now get errors like fatal error: linux/errno.h: No such file or directory
Feb 20 10:56:33 <eduardas_m> I am using Rocko
Feb 20 11:35:59 <maxin> acrap: BBMASK ?
Feb 20 11:37:20 <acrap> maxin: what BBMASK?
Feb 20 11:38:35 <maxin> acrap: http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#var-BBMASK
Feb 20 11:39:40 <acrap> maxin: wow! Thanks!
Feb 20 11:40:39 <maxin> acrap: or may be PNBLACKLIST: http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#var-PNBLACKLIST  - depending on your requirement
Feb 20 11:50:47 <acrap> maxin: it works (BBMASK). But it disable not only what i need. I need to disable only non-native version of my packet.
Feb 20 11:53:41 <acrap> maxin: by the way, thank you :)
Feb 20 11:54:00 <maxin> acrap: in that case, you need PNBLACKLIST..
Feb 20 11:55:15 <acrap> maxin: i need to specify name of layer. Am i right?
Feb 20 11:55:48 <maxin> acrap: eg: INHERIT += "blacklist" PNBLACKLIST[nativesdk-libidn] = "reason" will just disable nativesdk-libidn
Feb 20 11:58:32 <acrap> maxin: thank you! It helps me.
Feb 20 12:04:43 <acrap> maxin: oh, i got message that my image requires it (RDEPENDS), but it isn't. I even tried add RDEPENDS_imagename_remove += "packagename" (local.conf). but it doesn't help. I got chain "Missing or unbuildable dependency chain was: ['imagename', 'packagename]"
Feb 20 12:06:35 <maxin> acrap: ah, find the dependency and see if you can remove it..
Feb 20 12:07:54 <acrap> maxin: how can i do that? Why can't i see it in dependency chain? I tried to grep all the layers, but can't see any dependencies :(
Feb 20 12:10:36 <maxin> acrap: try : bitbake -g <recipe> && less task-depends.dot
Feb 20 12:19:49 <acrap> maxin: that's not help. I see one of my packet dependency in task-depends.dot, but i cant figure out why it is there. It's not mentioned in *.bb or *.inc files.
Feb 20 12:37:02 <maxin> acrap: hmm.. I am not so sure about easy ways to find reverse dependencies
Feb 20 12:39:16 <acrap> maxin: you help me enough. Now i know more useful tricks! May be i should stop trying to remove this package. It's not so important.
Feb 20 12:40:22 <maxin> acrap: good to hear.all the best ..
Feb 20 12:40:51 <acrap> maxin: thank you :)
Feb 20 12:58:02 <eduardas_m> In my target sysroot shipped with the SDK I am missing such headers as /usr/include/linux/limits.h or /usr/include/linux/errno.h Does anyone have any idea why that might happen?
Feb 20 13:38:34 <seppe> Hey, what happened to `devtool update recipe`? It doesn't seem to exist anymore in the devtool of rocko :s
Feb 20 13:42:56 <mckoan> seppe: devtool update-recipe
Feb 20 13:50:55 <seppe> mckoan: that doesn't seem to do the same as update recipe...
Feb 20 13:51:08 <seppe> I'm trying to follow https://wiki.yoctoproject.org/wiki/TipsAndTricks/Patching_the_source_for_a_recipe
Feb 20 13:51:38 <seppe> I think `devtool finish` might be what I want though
Feb 20 13:52:31 <seppe> which is creating a patch for the vendored linux sources
Feb 20 13:56:02 <seppe> hhm, nvm, looks like update-recipe is definetly what I want
Feb 20 13:56:27 <seppe> Do I need to commit my changes in my workspace for it to work?
Feb 20 14:02:54 <RP> zeddii, armpit: Think I understand the 4.12 arm64 failure
Feb 20 14:03:16 <zeddii> oh ? that's good, since I just did a boot this morning and was going to start bisecting.
Feb 20 14:03:28 <RP> zeddii: we need http://git.yoctoproject.org/cgit.cgi/linux-yocto/patch/?id=629a359bdb0e0652a8227b4ff3125431995fec6e
Feb 20 14:04:07 <RP> zeddii: literally just confirmed it works with that applied
Feb 20 14:04:32 <zeddii> ahah. I can do a test very quickly here, and get it merged. I can then let PaulG know that he needs it in his queue for his next -stable.
Feb 20 14:04:57 <zeddii> RP: I also just tried that oe-selftest for the mod-scripts, and will look at that if this is fixed.
Feb 20 14:05:19 <zeddii> but the one-liner fix you wondered about didn't seem to change it, so I need to ponder it more.
Feb 20 14:08:33 <otavio> RP: rburton: I did the upgrade of mesa including the latest regression fix and sent all patches together in a v2. Total of 6 patches
Feb 20 14:11:02 <zeddii> qemuarm64 login: root
Feb 20 14:11:02 <zeddii> root@qemuarm64:~# uname -a
Feb 20 14:11:02 <zeddii> Linux qemuarm64 4.12.20-yocto-standard #2 SMP PREEMPT Tue Feb 20 09:07:07 EST 2018 aarch64 GNU/Linux
Feb 20 14:11:16 <zeddii> RP: confirmed here as well. will merge that and send the updated revs in the next few mins.
Feb 20 14:46:22 <hastake> hello
Feb 20 14:46:27 <RP> zeddii: thanks!
Feb 20 14:48:27 <hastake> i have a small issue with python code in a recipe, if i write SRC_URI = "{@d.getVar('foo').bar()}", should it works?
Feb 20 14:48:33 <hastake> work*
Feb 20 14:49:03 <cornel> hello
Feb 20 14:49:11 <hastake> i have an error saying "The URL: '{@d.getVar...' is invalid and cannot be interpreted"
Feb 20 14:50:02 <cornel> if you have to write a ~1500 lines script for automating yocto builds, what would you use? rust, ruby, python, bash, or something else? i have currently a bash version but is a complete mess and iwant to rewrite it
Feb 20 14:50:18 <hastake> where is the error in what i do?
Feb 20 14:50:21 <LetoThe2nd> hastake: the expansion is "${...}", "{...}" afaik
Feb 20 14:50:26 <LetoThe2nd> erm.
Feb 20 14:50:39 <LetoThe2nd> hastake: the expansion is "${...}", not "{...}" afaik. e.g. you need the '$'
Feb 20 14:51:26 <LetoThe2nd> cornel: reconsider life choces, because a ~1500 line single script is ... meh
Feb 20 14:51:32 <cornel> :)
Feb 20 14:51:59 <cornel> you're right but is part of the job :)
Feb 20 14:52:13 <cornel> however, splitting it in three would be the next generation
Feb 20 14:52:19 <hastake> LetoThe2nd: i am idiot, thanks
Feb 20 14:52:24 <LetoThe2nd> cornel: generally i'd always say: see whats already around and reuse, not reinvent.
Feb 20 14:52:30 <cornel> but i was pondering if i should move away from bash
Feb 20 14:52:40 <LetoThe2nd> cornel: e.g. use repo, or kis as infrastructure
Feb 20 14:52:51 <LetoThe2nd> cornel: or rip something out of the yocto autobuilder.
Feb 20 14:52:52 <cornel> kis?
Feb 20 14:53:09 <cornel> i have no idea what kis or autobuilder are
Feb 20 14:53:30 <cornel> searching ...
Feb 20 14:53:51 <LetoThe2nd> the autobuilder is part of the yocto project, so should be easy to find.
Feb 20 14:54:15 <cornel> found autobuilder
Feb 20 14:54:21 <cornel> not found kis
Feb 20 14:55:25 <LetoThe2nd> my bad, its called kas. see: https://github.com/siemens/meta-iot2000
Feb 20 14:55:30 <LetoThe2nd> that uses it.
Feb 20 14:56:43 <cornel> interesting
Feb 20 14:56:50 <cornel> thank you very much LetoThe2nd
Feb 20 15:05:40 <RP> cornel: http://git.yoctoproject.org/cgit.cgi/yocto-autobuilder-helper might be interesting depending on what you're doing. Its python based
Feb 20 15:07:26 <cornel> thank you RP
Feb 20 15:18:07 <armpit> RP, zeddii thanks
Feb 20 15:21:30 <kergoth> Huh, I just realized meta-external-toolchain probably breaks for armeb
Feb 20 15:21:54 <kergoth> armeb is the only big-endian tune that doesn't pass -meb/-mb/-mbig-endian in TUNE_CCARGS, it assumes the TUNE_ARCH changed the toolchain's default
Feb 20 15:21:58 <kergoth> true for internal, not so much for external
Feb 20 15:22:14 <kergoth> maybe i'll submit a patch to oe-core to pass it explicitly like all the others do
Feb 20 15:26:01 <RP> kergoth: might be an idea...
Feb 20 15:26:08 <RP> armpit: I triggered 2.4.2 rc2
Feb 20 15:26:26 <armpit> RP, thanks
Feb 20 15:26:30 * zeddii goes back to loooking at sametume_samsigs
Feb 20 15:27:15 * armpit works on pull request
Feb 20 15:31:44 <ejoerns> clsulliv, did you resolve your CONFIG_UNWINDER_ORC libelf dependency issue? I just came across the the same when trying to build a module oot and my attempts to fix it do not seem to be fruitful :/
Feb 20 15:37:54 <zeddii> ejoerns. are you carrying something like this in your kernel recipe ? DEPENDS += "${@bb.utils.contains('ARCH', 'x86', 'elfutils-native', '', d)}"
Feb 20 15:38:36 <ejoerns> zeddii, jep. and kernel works fine. but compiling out-of-tree modules not
Feb 20 15:38:54 <zeddii> yah. there's a patch for that floating around, IIRC correctly.
Feb 20 15:39:15 <zeddii> I've completely torn apart the kernel-devsrc package. so it handles it now, but that's not ready to submit quite yet.
Feb 20 15:41:12 <zeddii> [OE-core] [PATCH] kernel: add objtool to shared workdir
Feb 20 15:43:17 <ejoerns> zeddii, for this I sent [OE-core] [PATCH] module-base: use modules_prepare build target in do_make_scripts()
Feb 20 15:43:43 <zeddii> make_scripts is completely different now.
Feb 20 15:43:46 <zeddii> with the patch under test.
Feb 20 15:44:23 <zeddii> RP: there the oe-self test passed, I'll send a new patch.
Feb 20 15:46:32 <ejoerns> zeddii, mh, mine is 2 weeks older but was ignored... Well, don't you think calling modules_prepare is the more general solution?
Feb 20 15:46:38 <zeddii> nope
Feb 20 15:47:11 <zeddii> the patch to take all the scripts crap out of the kernel bbclass has been ongoing for 6 months
Feb 20 15:47:15 <zeddii> so that pre-dates everything ;)
Feb 20 15:47:43 <zeddii> but we actually do want the scripts in some scenarios, it wasn't being used due to not knowing about modules_prepare.
Feb 20 15:49:50 <ejoerns> my patch actually is for module-base.bbclass not kernel.bbclass
Feb 20 15:50:14 <zeddii> same differece
Feb 20 15:50:24 * zeddii shrugs
Feb 20 15:50:46 <zeddii> we are getting it all out of that build process it races and has been junk for a long time.
Feb 20 15:51:12 <zeddii> that + devsrc are changing once I the sig gens changse are sorted + we can cross build the scripts, etc.
Feb 20 15:56:53 <ejoerns> zeddii, mh, ok. But I'm still unsure how to fix my issue now :D maybe I'll give the crude objtool workaround a try ;)
Feb 20 15:57:52 <RP> zeddii: thanks, what was it out of interest?
Feb 20 15:58:17 <zeddii> RP: it was the line you suggested for the fix, or did you mean 'what was the error I saw initially' ?
Feb 20 15:58:29 <lukma> Just to ask
Feb 20 15:58:51 <lukma> I do need to override linux-yocto-4.12 to linux-yocto-dev
Feb 20 15:58:58 <zeddii> my error was due to dangling bbappends ;) so I cleanedup my layers.
Feb 20 15:59:03 <RP> zeddii: I just saw the email, I was wondering what the fix was. Glad I was able to guess :)
Feb 20 15:59:06 <lukma> I'm using MACHINE=qemuarm
Feb 20 15:59:21 <lukma> the only way to override PREFERRED_PROVIDER_virtual/kernel = "linux-yocto-dev"
Feb 20 15:59:25 <zeddii> RP: yah. I'm pretty dense when it comes to that stuff, so I ran with your suggesetion.
Feb 20 15:59:29 <zeddii> lukma, yep.
Feb 20 15:59:45 <lukma> is to put it into build_dir/conf/local.conf
Feb 20 16:00:03 <lukma> Can it be done in other way?
Feb 20 16:00:12 <zeddii> it can be in any conf file, i.e. a layer you are including, etc
Feb 20 16:00:17 <lukma> Like override some parts of quemu.inc ?
Feb 20 16:01:15 <lukma> zeddii: I rather thought about adding meta-XXX/conf/machine/qemuarm.conf
Feb 20 16:01:34 <lukma> and override it there - which is a more portable solution IMHO
Feb 20 16:02:10 <lukma> But it seems like it doesn't overwrite stuff in poky/meta/conf/machine
Feb 20 16:02:46 <RP> zeddii: those kind of bugs are a pain to debug which is why we have those tests to spot them!
Feb 20 16:03:23 <zeddii> indeed. doing a final build test now, and will send v3 shortly.  then back to kernel-devsrc and integrating it with the scripts-cross build test.
Feb 20 16:03:39 <zeddii> task swap death
Feb 20 16:03:50 * zeddii notes RP knows task swap death better than me ;)
Feb 20 16:04:01 <RP> zeddii: I know the feeling, believe me! :)
Feb 20 16:04:20 * RP ponders toolchains, bugs, stable releases or misc next
Feb 20 16:07:54 <lukma> Ok, so there is no "easy" way to adjust PREFERRED_PROVIDER_virtual/kernel for MACHINE=qemuarm ?
Feb 20 16:09:09 <lukma> By easy - I mean portable
Feb 20 16:09:36 <lukma> to avoid copying local.conf to the deployment directory/setup?
Feb 20 16:09:50 <LetoThe2nd> lukma: the portable way is to define your own machine that sets up things the way you want them.
Feb 20 16:10:00 <kergoth> local.conf, site.conf, or add a custom machine that's based on or includes qemuarm
Feb 20 16:10:24 <LetoThe2nd> for reasons unknown people always try to avoid own images, own machines, own distros and prefer beating things into shape.
Feb 20 16:11:35 <lukma> LetoThe2nd: :)
Feb 20 16:11:42 <lukma> People are lazy
Feb 20 16:11:42 <kergoth> i think people think it's harder or more imposing than it is
Feb 20 16:11:54 <LetoThe2nd> kergoth: yeah
Feb 20 16:12:00 <kergoth> i suspect it seems intimidating to new users, even though it's trivial
Feb 20 16:12:17 <lukma> If I do have qemuarm machine written by OE|yocto core team
Feb 20 16:12:33 <lukma> then why should I re-invent the wheel?
Feb 20 16:12:50 <RP> kergoth: ironic given the problem we had with oe-classic...
Feb 20 16:12:58 <kergoth> FYI, you can create a new machine that includes/requires the existing qemuarm machine, if you don't want to bother copying it for some reason..
Feb 20 16:13:03 <LetoThe2nd> lukma: then what is complicated about having a myquemarm.conf that just pulls in the prewritten stuff and just overriding it?
Feb 20 16:13:03 <kergoth> just need to tweak MACHINEOVERRIDES to include both
Feb 20 16:13:17 <kergoth> RP: heh, indeed
Feb 20 16:13:41 <lukma> good point
Feb 20 16:13:55 <ejoerns> zeddii, :( build server says no and my recipe still cries for libelf-dev...
Feb 20 16:14:20 <lukma> kergoth: I will do that this way
Feb 20 16:16:05 <zeddii> I'll have to test the use case against my re-worked packages. I'm back to them now that qemuarm64 is booting. I was getting that error, but haven't seen it for a while now.
Feb 20 16:19:14 <ejoerns> zeddii, also seems to be polluted by the host env as it works on my local machine but not on my CI server
Feb 20 17:00:36 <yocti> New news from stackoverflow: Skip printk calls <https://stackoverflow.com/questions/48890102/skip-printk-calls>
Feb 20 17:08:11 <zeddii> RP: my gmail copy of oe-core is messing with me. If you don't see both of my patches in the make-mod-scripts (v3), can you shout/yell at me ?
Feb 20 17:08:36 <zeddii> I only see 2/2, but I think it has threaded 1/2 away, and it may have appeared on the list.
Feb 20 17:26:50 <rburton> zeddii: yeah 1/2 was there, it's in mut now at least
Feb 20 17:27:09 <zeddii> ok. I *detest* the threading that gmail does with patches.
Feb 20 17:27:35 <zeddii> but yet, I need the list somewhere that I can check from home without VPN :D
Feb 20 17:28:41 <rburton> zeddii: you reminded me to ask twitter for mailer suggestions for exactly that reason
Feb 20 17:52:21 <ejoerns> zeddii, fyi I guess the fuckup is mainly caused by the kernel Makefile using $(HOSTCC) for the libelf-test during module builds. Thus (in contrast to kernel builds) for modules it uses the build machine's toolchain for checking (in kernel class we do set HOSTCC to ${BUILDCC} explicitly)
Feb 20 18:20:25 <alex___> anyone around? have a bit of a dilemma
Feb 20 18:43:00 <JPEWhacker> alex___: I'm here FWIW
Feb 20 18:57:12 <alex___> so I have a recipe named activist.bb that I want to rename to activist-acceptance.bb, activist-staging.bb, and activist-production.bb, depending on environment. the challenge is, I want the resulting debian package to install into a directory named activist regardless of environment specified, but it's getting that value from the PN variable which is set by the recipe name which includes the environment
Feb 20 19:06:13 <JPEWhacker> You don't have any control of ${PN} getting passed as part of the installation directory?
Feb 20 19:06:59 <alex___> Within the recipe it says:
Feb 20 19:07:00 <alex___> pkg_postinst_${PN}() {
Feb 20 19:07:22 <alex___> If I change PN would it update appropriately?
Feb 20 19:08:26 <alex___> meaning if I set it to pkg_postinst_activist would the install folder be named activist?
Feb 20 19:08:48 <alex___> or does that just specify which application the pkg_postinst applies to?
Feb 20 19:09:28 <JPEWhacker> I don't think that pkg_postinst affect the installation directory
Feb 20 19:09:37 <JPEWhacker> usually....
Feb 20 19:11:26 <JPEWhacker> But you might want to clarify "installation directory"
Feb 20 19:15:06 <alex___> the directory where the application is installed
Feb 20 19:15:21 <alex___> it's always /usr/pkgs/PN regardless of application
Feb 20 19:15:29 <JPEWhacker> Usually thats set by do_install()
Feb 20 19:16:13 <alex___> ooh yeah!
Feb 20 19:16:27 <alex___> so I have this block in a class file that's inherited by each individual sub-recipe
Feb 20 19:16:34 <alex___> `bundler_do_install() { 	install -d ${D}${prefix}/pkgs/ 	install -d ${D}${prefix}/pkgs/${PN} 	rsync -rtv ${S}/ ${D}${prefix}/pkgs/${PN} }`
Feb 20 19:17:20 <alex___> so it's precisely there where ${PN} needs to be ${PN} minus the environment, right?
Feb 20 19:17:44 <JPEWhacker> Right
Feb 20 19:17:52 <alex___> so maybe I could declare a variable such PN_NEW that grabs PN then removes the environment tag from the end of it
Feb 20 19:18:02 <alex___> then update the install block to use PN_NEW instead of PN
Feb 20 19:18:06 <alex___> does that make sense?
Feb 20 19:19:24 <alex___> thank you so much JPE! Our systems guy left and I inherited this code base. I'm a junior devops guy with only 1 year of experience so still have so much to learn.
Feb 20 19:21:00 <JPEWhacker> Ya, I think thing might work: PN_INSTALL_DIR = "${@d.getVar('PN').split('-')[0]}"
Feb 20 19:21:03 <JPEWhacker> np
Feb 20 19:21:35 <alex___> That's just beautiful thank you sir! I miss Python. It's all Ruby here.
Feb 20 19:23:11 <JPEWhacker> ... Did you reverse that? bitbake uses python
Feb 20 19:23:30 <alex___> By "here" I meant my company heh
Feb 20 19:23:56 <alex___> I started in Python, fell in love with it, then was forced to switch to Ruby; now I'm starting to get Stockholm Syndrome
Feb 20 19:24:01 <JPEWhacker> Oh, right. Got it ;)
Feb 20 19:24:09 <alex___> I barely even remember my real parents anymore
Feb 20 20:05:25 <didil> hi
Feb 20 20:07:13 <didil> glib doesn't compile in poky "rocko"
Feb 20 20:07:17 <didil> https://paste.ofcode.org/MBqSyKZ8mirQSBvbFRPXvc
Feb 20 21:06:15 <didil> glibc*
Feb 20 21:06:48 <didil> this branch is broken
Feb 20 21:27:25 <alex____> JPEWhacker so sometimes the application names include the - character
Feb 20 21:28:09 <alex____> so I think I need to write it like this:
Feb 20 21:28:10 <alex____> INSTALL_FOLDER = '-'.join(PN.split('-')[0:-1])
Feb 20 21:28:46 <alex____> Is there a more technically correct way to do that? Getting a little bit of a code smell vibe.
Feb 20 21:32:01 <fray> you can replace the '-' with say '_' or another character if this makes more sense..
Feb 20 21:46:34 <alex____> Can I reference PN freely in a class file or do I need to do something like bb.data.getVar('PN',d,1)?
Feb 20 21:49:02 <JPEWhacker> Not sure I understand the question
Feb 20 21:49:27 <JPEWhacker> Is bundler_do_install() in a class file?
Feb 20 21:49:39 <alex____> yes
Feb 20 21:50:15 <JPEWhacker> Ya, you can reference PN in a class file. You would use bb.data.getVar('PN') in Python code, and ${PN} elsewhere
Feb 20 21:50:28 <JPEWhacker> Are you willing to change the bbclass file?
Feb 20 21:50:46 <alex____> Definitely
Feb 20 21:51:19 <alex____> INSTALL_FOLDER = '-'.join(bb.data.getVar('PN').split('-')[0:-1])
Feb 20 21:51:32 <JPEWhacker> You might consider doing it a little "dumber" then. In the bbclass do something like: INSTALL_FOLDER ?= "${PN}", then override it in each recipe
Feb 20 21:52:07 <JPEWhacker> e.g. INSTALL_FOLDER = "activist"
Feb 20 21:52:11 <alex____> I get a parse error from the above line
Feb 20 21:52:39 <JPEWhacker> Ya, you need the "this is python code" delimiters, ${@ }
Feb 20 21:52:50 <alex____> Ah gotchya I'm such a newb heh
Feb 20 21:52:58 <alex____> so I was planning to add a regex if clause
Feb 20 21:53:01 <JPEWhacker> e.g. INSTALL_FOLDER = "${@'-'.join(bb.data.getVar('PN').split('-')[0:-1])}"
Feb 20 21:54:13 <JPEWhacker> That works. You still might want to define that weakly so it can be overriden easily on per-recipe basis, e.g. INSTALL_FOLDER ?= "...."
Feb 20 21:54:47 <alex____> that's a good idea thank you
Feb 20 22:05:58 <alex____> so when i construct the whole if clause that should be encapsulated in ${@ } as well, right??
Feb 20 22:11:56 <alex____> hmm i'll try to set it up as a python function
Feb 20 22:12:40 <JPEWhacker> Ya, I would write a function
Feb 20 22:18:28 <alex____> will the function be automatically invoked or do I need to invoke it?
Feb 20 22:18:51 <alex____> or do i do something like "python do_install_prepend"
Feb 20 22:23:04 <alex____> python do_install_prepend () { 	PN = bb.data.getVar('PN') 	environments = ['acceptance', 'staging', 'production']   if any(n in PN for n in environments): 		INSTALL_FOLDER = '-'.join(bb.data.getVar('PN').split('-')[0:-1]) 	else:  		INSTALL_FOLDER = PN }
Feb 20 22:25:15 <alex____> I'm just going to make it "dumb" and put it in the recipes
Feb 20 22:26:39 <alex____> oh hm that's not going to work because the do_install is in the class not the recipes...
Feb 20 22:35:48 <JPEWhacker> alex___: I think some time reading the manual would be in order, but you can start with this: https://paste.ofcode.org/FRi5kSW2HySxtKCeRiQbua
Feb 20 22:43:50 <alex____> amen thanks JPE
Feb 20 22:54:35 <alex____> holy crapoly
Feb 20 22:54:38 <alex____> i think it worked...
Feb 20 22:57:25 <alex____> nope jumped the gun : )
Feb 20 23:00:11 <alex____> woot fixed the issue -- just had to make a small adjustment in the actual recipe file!
Feb 20 23:00:38 <alex____> JPEWhacker: here's the code in case you're curious: https://paste.ofcode.org/qvG5kRtsbwCwMf7XXBNdm9
Feb 20 23:00:44 <alex____> I owe you a beer man
Feb 20 23:02:42 <JPEWhacker> Lol, no problem. It looks really good, I would only make one change: the "d" argument to the function is the bb data store, so instead of bb.data.getVar('PN', d, 1), you can simply do d.getVar('PN')
Feb 20 23:04:34 <rburton> didil: glibc in rocko branch builds fine here
Feb 20 23:06:22 <didil> rburton: not on my computer
Feb 20 23:06:43 <didil> Ubuntu 17.10
Feb 20 23:07:01 <rburton> didil: that's interesting, but it works on the entire autobuilder.  so you've an interesting quirk.  have you tried with a different MACHINE? do you have anything apart from just oe-core?
Feb 20 23:08:19 <didil> not yet :/, I use meta-freescale and meta-openembedded and meta-qt5
Feb 20 23:08:49 <didil> added to poky
Feb 20 23:10:29 <rburton> didil: i'd rip those layers out, set machine=qemuarm, and try building glibc
Feb 20 23:10:40 <rburton> if it works then you know its not oe-core at fault
Feb 20 23:10:56 <rburton> if it doesn't then file a bug
Feb 20 23:11:07 <didil> i'm compiling the pyro branch
Feb 20 23:11:19 <didil> it passes the glibc compilation task
Feb 20 23:11:39 <didil> ok i'll do it
Feb 20 23:13:06 <didil> thanks :)
Feb 20 23:48:56 <hastake> i need to instantiate the images that i build (eg add some unique id and certificates inside). any idea the simpler way to do that? any alternative?
Feb 20 23:49:42 <hastake> (i tried to find documentation about that, but unfortunalty no luck. any ptr?)
**** ENDING LOGGING AT Wed Feb 21 03:00:02 2018