**** BEGIN LOGGING AT Fri Mar 15 02:59:58 2013 Mar 15 03:21:19 i just realized .... passwd --root /path/to/other/root --pass `/path/to/password_generator` would not reveal the password in ps Mar 15 05:10:34 hi Mar 15 05:10:37 automatic de-ANSI-fication support has been removed Mar 15 05:10:59 configuaration error Mar 15 07:07:20 when we build any module ,cloned source will be stored in downloads folder (in archieve format)...when i build the same module again after some days, will it fetch the latest source ?? Mar 15 07:17:11 boost1: for sources from SCMs like git, subversion it depends on your SRCREV Mar 15 07:17:20 boost1: e.g. if you use a fixed SRCREV it will use that one Mar 15 09:28:07 @zecke...Thanks for ur info Mar 15 11:48:39 hi, what is the best way to modify the deafult PACKAGECONFIG for a recepi that have it defined as PACKAGECONFIG ??= "...." add it in a .bbappend file or something else? Mar 15 12:07:34 neg: yes a bbappend Mar 15 12:07:45 thanks Mar 15 12:45:31 I wonder how widely people are using systemd in their distros. I have a problem, described here https://lists.yoctoproject.org/pipermail/yocto/2013-March/014783.html I have managed to debug this so far that NameOwnerChanged dbus messages from various daemon startups like connman, ofono, avahi are not received by systemd so these daemons are promply killed by systemd. Any idea what is going wrong here? Mar 15 14:05:05 should i submit the base-shadow patch that modifies passwd to allow command-line parameter password in yocto or in meta-oe? Mar 15 14:05:35 s:/base-shadow/shadow-native/ Mar 15 14:06:18 I'd say submit to oe-core, personally, I think there's clear value. but if anyone disagrees, they'll reply to your email as such. so i'd say start there, and go from there Mar 15 14:06:22 * kergoth yawns and goes to get breakfast Mar 15 14:08:40 okay, in the case do you think it would be a good idea to include a modification of image.bbclass such that do_rootfs will use this utility if the variable "ROOT_PASSWD" is not empty? probably right around the same location where ROOTFS_POSTPROCESS_COMMAND is run? Mar 15 14:10:04 i'd make the modfication actually add it to ROOTFS_POSTPROCESS_COMMAND directly, rather than modifying do_rootfs, but yes, that sort of thing would be nice. most likely as a separate commit, however Mar 15 14:15:21 well yesterday i ran into some problems when writing the script for rootfs_postprocess_command, maybe you have a suggestion to get around it. specifically, i couldn't seem to escape double-quotes when adding the 'if [ "${ROOT_PASSWD}x" != "x" ] ...' to ROOTFS_POSTPROCESS_COMMAND; this led to ExpansionError during the recipe parse portion of the build Mar 15 14:16:29 even if not doing this conditionally, being able to quote the ${ROOT_PASSWD} variable itself in the 'passwd' command is important in case it contains spaces Mar 15 14:16:38 first, i'd suggest creating a shell function which can be added to ROOTFS_POSTPROCESS_COMMAND the way all the other shell functions can be Mar 15 14:16:57 then, use python to conditionally add it to ROOTFS_POSTPROCESS_COMMAND based on ROOT_PASSWD, rather than unconditionally appending an if statement Mar 15 14:17:09 pretty sure there's already an example of this in image.bbclass Mar 15 14:17:18 okay, i'll take a look Mar 15 14:18:00 ya.. I'd agree, if it's an issue (spaces and whatnot).. it's much easier to add a function.. Mar 15 14:18:26 you can create a custom class and use inherit to add it to the name space.. then just call it via the ROOTFS_POSTPROCESS_COMMAND_append = " my_passwd_func ; " Mar 15 14:19:04 (new file, myclass.bbclass): Mar 15 14:19:08 my_passwd_func() { Mar 15 14:19:31 if [ -n "${ROOT_PASSWORD}" ]; then Mar 15 14:19:46 true, good point re separate class Mar 15 14:19:56 echo "${ROOT_PASSWORD}" | passwd -D ${IMAGE_ROOTFS} --stdin root Mar 15 14:19:59 fi Mar 15 14:20:00 } Mar 15 14:20:10 (I'm sure I typoed something in there.. but that's about all that is needed) Mar 15 14:20:35 myclass.bbclass should be put into the 'classes' directory of your custom layer.. and then your custom layer be added to the bblayers.conf file.... Mar 15 14:20:52 I'm using yocto (master) and I have a weird behaviour with core-image-sato, the system boots, but after "Freeing init memory: 144K" there are no messages and the daemons in /etc/rc5.d/ are not executed (no psplash no xinit). Am I missing anything? Mar 15 14:20:53 >.> i went with passwd -R ${IMAGE_ROOTFS} --pass $ROOT_PASSWORD instead Mar 15 14:21:24 after a while the prompt appears: Poky 8.0 (Yocto Project 1.3 Reference Distro) 1.3+snapshot-20130315 ttyS0 Mar 15 14:22:04 if I launch the daemons manually they are working S09xserver-nodm Mar 15 14:22:38 fray, kergoth i was thinking it would simplify giving others access to using the variable ${ROOT_PASSWD} if this code was patched into image.bbclass directly Mar 15 14:23:27 make it work externally first.. Mar 15 14:23:38 waynr, I believe the --pass requires the prehashed password Mar 15 14:24:47 actually the modification i made to the passwd utility takes the plaintext password on the command line and converts it as if it had been given at the new password prompt Mar 15 14:24:59 ahh ok.. Mar 15 14:25:13 I just noticed it doesn't look like our passwd has the --stdin feature... hmm.. Mar 15 14:25:16 wonder if that is Red Hat specific Mar 15 14:25:54 yeah i couldn't find the --stdin feature on any of the debian or ubuntu machines that i use Mar 15 14:26:35 and it was simpler to grab it as an optional argument than to correctly interpret stdin Mar 15 14:27:53 and I have confirmed that my image builds correctly just by using ROOTFS_POSTPROCESS_COMMAND_append in my image recipe Mar 15 14:28:33 i guess i still need to verify it works correctly when booting Mar 15 14:36:23 hi all! is there a way to specify a jar file in the SRC_URI variable, so that it will not be uncompressed under the ${S} direcotry in the fetch phase? maybe simply deleting the file extension? Thanks! Mar 15 14:37:24 soldoKyn: try this, file://whatever.jar;unpack=0 Mar 15 14:37:48 here is some documentation on it: http://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#var-SRC_URI Mar 15 14:42:45 waynr: thanks a lot! Mar 15 14:46:30 waynr: I never heard about the 'mega manual' is it more updated than YP reference manual? www.yoctoproject.org/docs/current/poky-ref-manual/poky-ref-manual.html Mar 15 14:49:24 mckoan: well they are both in docs/current so I think they are both current Mar 15 14:50:22 it looks like they contain much of the same content, except the mega manual does not seem to have a nifty table of contents Mar 15 14:50:43 sometimes when i am looking for documentation in end up on the mega manual, other times i end up on the poky reference manual Mar 15 14:56:24 waynr: ;-) Mar 15 15:08:07 too bad oe.utils.contains does not use regex against the contents of the the split string :( Mar 15 15:31:29 okay if i add a function to both classes/utils.bbclass and lib/oe/utils.py is there something special I need to do to get the build system to recognize this change? for example i created a regex version of "base_contains" called "base_contains_regex" that uses oe.utils.contains_regex which uses python's re.match function to check for a given regular expression in the contents of the given variable Mar 15 15:34:12 but this leads to "Error during finalize of ..." for all the parsed image recipes, which might be due to a typo or something but more likely due to my lack of understanding of how all this works Mar 15 15:35:30 also, i understand something like this might be overkill but it certainly is helping me understand a little better bitbake/oe/yocto work together Mar 15 18:47:42 hmm, why didn't I push my tmux Terminal for oe.terminal yet Mar 15 21:24:14 kergoth: what is oe.terminal used for? Mar 15 21:24:35 devshell and the user patch resolver Mar 15 21:24:41 it has screen today, but not tmux Mar 15 21:25:18 thumbs up for tmux, i use it everywhere :D Mar 15 21:25:24 * kergoth too Mar 15 21:25:54 k, will find some time to polish and push one of these days Mar 16 01:05:02 anyone open for a position in CA for yocto/oe, linux, etc... pvt me **** ENDING LOGGING AT Sat Mar 16 02:59:58 2013