**** BEGIN LOGGING AT Wed Nov 25 03:00:55 2015 Nov 25 09:10:32 Hello everyone. I have a question concerning the postgresql service. I modified the "postgresql.service" (found in meta-oe) in my layer. Once the target launched, the command "systemctl start postgresql" succeeds. Unfortunately, I don't understand why the service isn't started at startup. Nov 25 09:11:18 The "postgresql.service" file contains '[Unit] ... After=network.target ...' Nov 25 09:18:03 olivier__: 'systemctl enable ' if you are using a persistant rootfs that should make it work on startup Nov 25 09:18:47 olivier__: There is a variable to add it as an autoenable from within the yocto rootfs build Nov 25 09:23:41 nrossi: Thanks. Indeed the 'systemctl enable postgresl' make it autoenabled. Nov 25 09:24:02 nrossi, olivier__: the default for SYSTEMD_AUTO_ENABLE is "enable" so services should get started automatically by default... Nov 25 09:24:31 nrossi: but I'm trying to configure it directly from the yocto configuration. Nov 25 09:25:03 jku: That's strange, because before the 'systemctl enable', the service wasn't started. Nov 25 09:25:28 jku: Now, I rebooted and the 'systemctl status' shows me the service is enabled. Nov 25 09:26:02 olivier__: the recipe sets that Nov 25 09:26:10 SYSTEMD_AUTO_ENABLE_${PN} = "disable" Nov 25 09:26:30 remove that line and it'll work out of the box Nov 25 09:28:30 jku: Ok; so how should I do it? Copy the 'postgresql.inc' file inside my layer and modify it? Nov 25 09:28:41 jku: Or should I do a patch? Nov 25 09:29:32 jku: Or simply add 'SYSTEMD_AUTO_ENABLE_${PN} = "enabled"' inside my recipe? Nov 25 09:31:03 olivier__: you can override the value from your distro.conf, or with local.conf. Something like "SYSTEMD_AUTO_ENABLE_postgresql = "enable"" Nov 25 09:31:19 _pn-postgresql it'll need to be Nov 25 09:31:21 oops that probably needs to be "pn-postgresql" Nov 25 09:31:22 or, use a bbappend Nov 25 09:31:39 too quick, hes like lightning! :P Nov 25 09:32:15 :D Nov 25 09:32:16 yeah, here I am trying to write an anser with my ~4 finger typing ... Nov 25 09:32:26 I prefer two fingers myself Nov 25 09:32:39 never did learn to properly touch type Nov 25 09:32:44 bluelightning: or is it just the nice warm southern hemisphere climate? :) Nov 25 09:32:51 nrossi: could be :) Nov 25 09:36:36 olivier__: the least fragile long term solution might be bbappending postgresql_%.bb (and setting the variable value to "enable") -- or convincing the maintainer that "enable" is a sensible default Nov 25 09:40:57 jku: nrossi: bluelightning: Thanks to all. I'll try the bbappend method. I'll keep you posted. Nov 25 09:43:59 One last thing: my postgresql_9.%.bbappend contains: Nov 25 09:44:02 FILESEXTRAPATHS_prepend := "${THISDIR}/files:" Nov 25 09:44:12 when adding 'SYSTEMD_AUTO_ENABLE_${PN} = "enabled"' Nov 25 09:44:29 the bitbake postgresql doesn't recompile the package Nov 25 09:44:46 What am I forgetting? Nov 25 10:01:54 jku: Any idea? Nov 25 10:43:42 bluelightning: Hey. Do you have any idea why the bitbake postgresql doesn't recompile the package after I added 'SYSTEMD_AUTO_ENABLE_${PN} = "enabled"' to the bbappend file? Nov 25 11:32:51 olivier__: it should be "enable" (without d), and recompile might not be necessary -- some tasks should definitely get re-executed though Nov 25 11:51:33 jku: I changed it to "enable". Unfortunately, no new task is performed. Nov 25 11:52:00 jku: If I add 'foobar' to my bbappend file, a Parse error is raised. So this file is parse. Nov 25 11:52:03 (parsed) Nov 25 12:20:11 olivier__: I would guess there is no variable dependency forcing a rebuild Nov 25 13:27:43 hello: I'm trying to use this assignment in bbappend file: PR_NUM := "${echo ${PR} | sed -e 's/^[^1-9]\+//g'}" but it gives me an error: expression was ${@int(PR_NUM) + 1} which triggered exception ValueError: invalid literal for int() with base 10: "${echo r1 | sed -e 's/^[^1-9]\\+//g'}" Nov 25 13:27:53 any idea what could be wrong? Nov 25 13:30:19 marek_: ${} is not a subshell Nov 25 13:43:36 neverpanic: should I use () instead? Nov 25 13:43:46 probably. Nov 25 13:46:21 are you trying to execute shell in bitbake expression? Nov 25 13:47:00 JaMa: yes I would need to increment PR which contains also literals and numbers Nov 25 13:47:31 Hello; I'm having trouble understanding why my "install -d -m 755 ${D}${bindir}/my_folder" followed by "install -m 0755 server ${D}${bindir}/my_folder/file1" and then "FILES_${PN} += "${D}${bindir}/my_folder/file1"doesn't create the folder neither the file on the target; The strange thing is that when I change every '${bindir}' by '${libdir}', it works... Nov 25 13:47:49 marek_: find how old PRINC implementation worked and copy it Nov 25 13:48:13 marek_: a4d530bcf55f03258078c10a123e2717444e1060 in oe-core Nov 25 13:52:49 JaMa: thx Nov 25 15:11:29 JaMa: one more question I put PRINC functionality to custom bbclass like: http://pastebin.com/zCbVaBM9 when call from bbappend it fails when call: PR = "${@increase_pr(2)}" Nov 25 15:12:19 JaMa: it's evaluated as : u-boot/2015.07-${increase_pr(2)}/temp/log.do_unpack.4013 Nov 25 16:55:54 hello Nov 25 16:56:33 i have a question related to udev rules...i want to know which all udev scripts create nodes inside /dev folder Nov 25 16:56:34 ? Nov 25 16:56:47 can anybody please help me in this? Nov 25 17:01:03 hi Nov 25 18:14:34 hi. i have a situation where part of the product can only be compiled by dedicated people. Nov 25 18:14:43 the result of that compilation is a set of libraries. Nov 25 18:15:16 is there a recommended way to handle this kind of workflow: one party builds a set of libraries, another party uses those libraries Nov 25 18:15:19 ? Nov 25 18:18:34 sa2ajj: you are probably best off having those dedicated people provide you a tarball of the libs that you integrate into yocto Nov 25 18:19:14 the question is: what kind of tarball they should provide? Nov 25 18:19:31 is there a particular tree structure? (for headers, libs themselves) Nov 25 18:20:15 how to amend a recipe for an app that uses those so it'd be unpacked at the right time in the right place? Nov 25 18:21:39 yocto should support any tarsal type Nov 25 18:22:14 * sa2ajj hmms Nov 25 18:22:28 let's say i have a library called libA Nov 25 18:22:39 you would just need a .bbappend file for the recipe you want to modify and iinclude a SRCURI += with the url or path to the tarball Nov 25 18:22:52 my app APP's recipe would say "I depend on libA" Nov 25 18:23:14 and bitbake would build and install everything that is necessary for APP to get built Nov 25 18:23:29 how would i achieve the same thing with a tarball? Nov 25 18:23:45 I would just add it to your APP recipe Nov 25 18:24:17 and include the tarball in your SRCURI statement(s) Nov 25 18:25:30 in all honesty i just started using yocto. do you think you could point me to some specific examples? Nov 25 18:25:56 (actually for both: the part where the tarball is built and where the tarball is used) Nov 25 18:26:29 http://www.yoctoproject.org/docs/1.8/dev-manual/dev-manual.html#new-recipe-fetching-code Nov 25 18:27:02 since you can't have yocto build the libs for you, you just need to integrate the tarsal download into your recipe Nov 25 18:28:51 the link seems to be for the 2nd part Nov 25 18:29:09 what about the 1st part? where i produce the tarball? Nov 25 18:29:17 (and, btw, thank you for the link!) Nov 25 18:30:03 I thought you said you can only have certain people build the libs Nov 25 18:30:25 yes, and i'd need to provide those certain people with instructions :/ Nov 25 18:30:29 as far as I know there is no method to ave yocto tell someone they have to build it Nov 25 18:31:09 lemme try to describe the situation in a few more details Nov 25 18:31:28 1st. i have a layer that describes cross-compiler etc. Nov 25 18:31:53 2nd. i'd like to have a layer that have recipes for producing library tarballs. Nov 25 18:31:54 have them compile the libs as expected and then just add them to tarball that is either integrated into your yocto layer or available for download from a url Nov 25 18:32:22 3rd. i'd like to have a layer that allows to build an app that depends on libraries in that tarball Nov 25 18:32:38 2nd is handled by a handful of people Nov 25 18:32:51 3rd is used by a big bunch of people Nov 25 18:33:08 because of your specific case for number 2, you'd probably not want to do that in yocto Nov 25 18:33:18 why not? Nov 25 18:33:35 (the compiler is defined by 1st layer) Nov 25 18:33:57 it is primarily intended to make distribution images Nov 25 18:34:00 (s/by 1st/by the 1st) Nov 25 18:34:21 images _and packages_, no? Nov 25 18:34:57 those packages are used in the images, sure Nov 25 18:35:16 but are not used for setting up the environment? Nov 25 18:35:30 unless you have a shared build system, the other folks that are building won't get those packages Nov 25 18:36:18 my initial thinking was: the devs for 2nd layer build packages and make them available, the devs for 3rd layer somehow make use of those packages Nov 25 18:36:27 right Nov 25 18:37:06 Yocto expects to be able to build everything it needs. Nov 25 18:37:19 * sa2ajj nods Nov 25 18:37:27 not that certain people can only build certain things, and have those things somehow available to other people Nov 25 18:38:12 sa2ajj: make the "build" recipe for the restricted libs "fetch and unpack a tarball from a restricted location" instead? Nov 25 18:38:27 also, hello. working late today? :) Nov 25 18:38:38 not working :) Nov 25 18:38:53 trying to clarify a couple of details :D Nov 25 18:39:06 so basically for yocto to inlcude those special libs for everyone that needs to build an image, I would recommend producing a tarball of those libs that is compiled and make available out of yocto that you can use in a yocto recipe Nov 25 18:44:15 BB_SRCREV_POLICY = "cache" will that ensure that it doesnt update the SRCREV of the recipes using SRCREV = "${AUTOREV}" Nov 25 18:44:28 or are there any unknowns Nov 25 18:48:54 deviosity: i am still not exactly clear on a) how to produce those tarballs using yocto and a particular layer that defines target architecture and compiler Nov 25 18:49:11 b) how to make use of that tarball :/ Nov 25 18:50:37 b) requires unpacking into a particular tree (include, lib) as i feel it'd be "bad" to unpack them into the source tree... Nov 25 18:51:23 a) probably would be something similar to creating a package (.ipkg?) without meta-information.. Nov 25 18:51:46 sa2ajj: something like - the privileged group have a "normal" recipe that grabs the source and builds, producing a tarball or whatever that they can drop into a known location. Nov 25 18:52:09 then everyone else has a "fake" recipe which grabs that tarball, and instead of building, just unpacks and installs it. Nov 25 18:52:21 if I understand the requirements Nov 25 18:52:38 i think you do Nov 25 18:52:54 at least, the above scenarious seem to make sense Nov 25 18:53:42 now the question is: are there existing examples of such an approach? :) Nov 25 18:53:53 that I do not know. Nov 25 18:54:09 so i could "hack together" a PoC and see if it works... Nov 25 18:54:20 but it's probably worth looking at the docs on how to override various stages like the build stage. Nov 25 18:54:35 sa2ajj: as I mentioned I wouldn't compile those tarballs with yocto, compile it how you normally would and have those tarballs either integrated into your yocto layer or available via some download location. Nov 25 18:55:05 deviosity: how we normally build things _is_ yocto :) Nov 25 18:55:08 deviosity: i do not seem to be able to -- the cross compiler definition comes from a yocto layer :/ Nov 25 18:56:04 "normally" we get a cross-compiler w/ required libs Nov 25 18:56:34 since our current situation is "no sdk for you, sorry", we do not get those cross-compilers Nov 25 18:57:05 they are only produced as a part of a yocto build Nov 25 18:57:29 you might want to revisit your policy, I suppose it would be possible to have this workflow in yocto, but it would be forging new ground. Nov 25 18:57:33 they = cross-compilers Nov 25 18:58:23 how to put it, it's not a policy, it's how the things _can_ be done now :/ Nov 25 19:00:50 unfortunately your scenario is beyond my familiarity with yocto. although it should be possible with a custom do_install to create a tarball from your custom libs once they are compiled. Nov 25 19:00:59 the only "policy" element is that only a very specific group of people can access the sources for those libraries Nov 25 19:01:28 sa2ajj: throw a task onto the pile for us if you like to produce an example pair of recipes. Nov 25 19:01:56 we have a story, i'm not sure that martin is very excited about it though :) Nov 25 19:02:50 heh Nov 25 19:02:50 i'll try to "formalise" it tomorrow though Nov 25 19:03:07 basically the concept is to create a build artifact that is uploaded in a location that is available to use in the yocto layers the other developers can use Nov 25 19:03:21 yup :) Nov 25 19:04:40 fledermaus: basically, he wants everything to be built from sources (keeping in mind particular components and i agree with that) Nov 25 19:05:12 however there's one set of components that require a special treatment :) Nov 25 19:05:31 and those are not in martin's focus Nov 25 19:08:11 so as part of the restricted libs build, you'll want to have a custom do_install that creates a tarball from those compiled libs, once that build is complete, you'll want to upload that tarball to a secure url, that you can integrate into the other yocto layer that other folks can use to compile their images. Nov 25 19:08:57 yes, this sounds to be inline with my goals Nov 25 19:09:53 while it might be possible to script out the upload into yocto, it will be specific to your infrastructure and workflow. Nov 25 19:10:20 Just keep in mind to version that tarsal, as yocto will want md5sum to verify its integrity. Nov 25 19:12:54 in a way, we do not need to version it, we just need to make sure a correct {md5,sha1,etc}sum is available. Nov 25 19:14:16 b Nov 25 19:14:19 correct, and that the md5sum doesn't change. Nov 25 19:15:10 * paulg curses xchat for being so twitchy about focus Nov 25 19:16:41 deviosity: thank you for looking into it Nov 25 19:16:56 fledermaus: we'll continue tomorrow :) Nov 25 19:17:01 Happy to help. I wish you good luck Nov 25 19:25:04 oob Nov 25 20:51:25 So I happened to have a buildtools in $PATH, and "git rebase" doesn't work because "git am" isn't apparently built. Nov 25 20:51:37 I am wondering whether we should just build a full-featured git instead of stripping it down a lot. Nov 25 20:51:44 ... note, this may be an oldish build tools tarball. Nov 25 20:57:58 erm, yeah, pretty sure we fixed that Nov 25 20:58:06 the current one (YP 2.0) should haev that fixed.. Nov 25 20:58:11 it was changed as part of the extensible SDK Nov 25 20:58:39 oe-core 5b051d65e797624cca3a81fc6f5c924925f3493e Nov 25 20:58:46 Date: Fri Dec 5 18:09:28 2014 +0000 Nov 25 20:59:02 at least, that's the latest fix you need **** ENDING LOGGING AT Thu Nov 26 03:00:38 2015