**** BEGIN LOGGING AT Thu May 14 02:59:58 2015 May 14 04:56:35 Hi Iam newbe to Yocto May 14 04:57:16 iam using yocto for Phytech AM355x board May 14 04:57:59 while building ianm getting following error May 14 04:58:17 DEBUG: Executing python function sstate_task_prefunc DEBUG: Python function sstate_task_prefunc finished DEBUG: Executing python function do_populate_sysroot DEBUG: Executing shell function sysroot_stage_all tar: --same-order option cannot be used with -c Try 'tar --help' or 'tar --usage' for more information. tar: This does not look like a tar archive tar: Exiting with failure status due to previous errors WARNING: exit code 2 fr May 14 04:58:33 any body please help me May 14 05:06:30 sadashiv_: Are you using a non-supported distro? (do you get the warning message when you try to run bitbake commands)? cause it looks like you have an incompatible version of tar May 14 05:10:21 what is nonBuild Configuration: BB_VERSION = "1.20.0" BUILD_SYS = "x86_64-linux" NATIVELSBSTRING = "Ubuntu-14.04" TARGET_SYS = "arm-poky-linux-gnueabi" MACHINE = "phyBOARD-WEGA-AM335x" DISTRO = "poky" DISTRO_VERSION = "1.5" TUNE_FEATURES = "armv7a vfp neon" TARGET_FPU = "vfp-neon" meta meta-yocto meta-yocto-bsp meta-hob = ": these are my settings May 14 05:15:00 sadashiv_: Ok that is a supported distro for newer versions of Yocto. Not sure if it works correctly with older versions of yocto (1.5 in your case) May 14 05:24:40 can anybody please explain how to debug to find the exact root cause May 14 07:06:19 Does a machine file and the files that it requires(.inc) need to be in the same layer?? I have a machine file in one layer and I need to include a .inc file from some other layer without code duplication May 14 07:10:30 does this apply to my situation: http://www.openembedded.org/wiki/Layers_FAQ#Can_I_overlay.2Fappend_an_inc_file_from_another_layer_in_my_layer.3F May 14 07:46:26 good morning May 14 08:01:03 Hi, I want to add iptables at my compile RFS + kernel, how can I add this features at my kernel? May 14 08:02:38 Is there any manual? May 14 08:04:57 Rigth now I'm using poky-dizzy-12.0.1 May 14 08:17:56 hmm, this is interesting: http://lists.openembedded.org/pipermail/openembedded-devel/2014-July/097213.html May 14 08:20:05 so why do I need this with daisy, but not dylan? May 14 08:35:35 bluelightning: hu May 14 08:35:38 hi, I mean :) May 14 08:35:52 morning all May 14 08:35:58 morning lpapp May 14 08:36:07 https://github.com/Angstrom-distribution/meta-angstrom/tree/master/recipes-tweaks/openssh -> is this some flexible way of defining the version Yocto uses so that it does not break on update? May 14 08:36:18 I am referring to % in the file name of the recipe append. May 14 08:37:16 lpapp: '%' in recipe names is a wild card. And yep its mainly for flexible version appends May 14 08:37:35 morning bluelightning May 14 08:38:10 ok, thanks :) May 14 08:38:17 hi nrossi May 14 08:38:42 hmm, perhaps I should change all my appends to this syntax May 14 08:38:46 is there any drawback of it? May 14 08:38:51 depends May 14 08:38:55 perhaps in case of multiple recipe versions? May 14 08:39:17 what would pick it up then? bitbake would complain that it is ambiguous? May 14 08:39:18 if you appends rely on the actual content of a versioned recipe then do not wildcard May 14 08:39:27 or would it pick up some dedicated version by default? May 14 08:39:55 lpapp: wildcards mix with version specific ones too May 14 08:40:48 lpapp: as in it will apply all appends that match the pattern May 14 08:41:02 well, I am still unsure why it all worked with dylan and not daisy. May 14 08:41:13 I would like to find the reason even though I know what is suggested in that thread. May 14 08:41:27 is it upstream openssh that changed? May 14 08:41:56 nrossi: right, so that would not cause any issues then if I set my preferred version. May 14 08:42:58 lpapp: what exactly is the issue you are seeing? May 14 08:43:18 http://lists.openembedded.org/pipermail/openembedded-devel/2014-July/097190.html May 14 08:43:36 "Just trying to found what's missing for PAM to work so ssh will stop May 14 08:43:36 exiting with Broken pipe? Quick fix to solve ssh broken pipe is to May 14 08:43:37 change in /etc/ssh/sshd_config "UsePAM yes" to "UsePAM no"." May 14 08:43:54 ssh did work before the daisy update May 14 08:43:59 but I see that the openssh version changed. May 14 08:44:08 so that could be a place to look at for finding the issue May 14 08:44:23 but since I do not know Yocto enough, that could also be a place. May 14 08:44:46 and of course our own stuff, too, but I am not sure that I have all the information so that I can localize it just yet. May 14 08:45:06 I can sure fix the issue like khem raj did, but I would also like to understand what I fix and why exactly and why it stopped working. May 14 08:47:17 lpapp: Sorry i don't know too much about the PAM stuff. Although I do remember that there were some changes around PAM stuff that went into daisy, where you could enable/disable PAM via distro features or some such May 14 08:48:56 interesting May 14 08:49:17 this is the exact error message by the way: packet_write_wait: Connection to 192.168.0.1: Broken pipe May 14 08:49:44 when I issue "ssh root@192.168.0.1" May 14 08:50:13 also, I am not sure if this "fix" compromises security. May 14 09:00:26 is it ok to reply to that old thread asking this? May 14 09:01:04 hmm, I was not on that list for the time ... May 14 09:03:08 lpapp: yes, nothing wrong with that May 14 09:04:08 hmm, I thought kmail had an option to edit the in-reply-to field, but maybe not May 14 09:14:54 in general, it is not good if pam has to be disabled for software intentionally using pam. May 14 09:15:03 so I hope that it is just an openssh specific issue. May 14 09:30:53 seems openssh_%.bbappend does not work for me May 14 09:31:09 still the unappended content is generated. May 14 09:34:30 I have this: ../meta-foo/recipes-connectivity/openssh/openssh/sshd_config May 14 09:34:56 and I have this: FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:" in ../meta-foo/recipes-connectivity/openssh/openssh_%.bbappend May 14 09:34:59 is this ok? May 14 09:35:52 fwiw, I also have: ../meta-foo/recipes-connectivity/openssh/openssh-foo_1.0.bb with we install company specific keys. May 14 09:36:27 do I need to do a complete image rebuild from scratch or placing openssh_%.bbappend with ../meta-foo/recipes-connectivity/openssh/openssh/sshd_config in there should be enough to regenerate the image with the new sshd_config? May 14 09:42:30 lpapp: does bitbake-layers show-appends list it? May 14 09:44:31 unfortunately no. May 14 09:44:48 good idea to check with that. I was not aware of that tool! May 14 09:45:43 hmm, so for some reason that bbappend isn't being picked up May 14 09:46:45 things to check: 1) is the layer enabled (I'm guessing it is), 2) BBFILES value in conf/layer.conf for the layer has a pattern that includes *.bbappend May 14 09:47:21 openssh_6.5p1.bbappend gets picked up May 14 09:47:37 just remind me, this is daisy right? May 14 09:47:40 yes May 14 09:48:20 wildcard bbappends are definitely supported there May 14 09:48:26 BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \ ${LAYERDIR}/recipes-*/*/*.bbappend" May 14 09:49:15 argh... the fix to make them show up in bitbake-layers never made daisy May 14 09:49:27 guess we should backport that May 14 09:49:44 is that just about tooling or the proper operation, too? May 14 09:50:05 tooling May 14 09:50:07 in all probability it's being parsed then, just the contents needs fixing May 14 09:50:45 hmm. May 14 09:52:48 although, I can't see how it could go wrong May 14 09:53:06 me neither, I will not use % for now then unless it is easy to fix. May 14 09:53:16 the file is already in SRC_URI, so FILESEXTRAPATHS_prepend as you've done and putting the file in the directory as you've done should be enough May 14 09:54:02 one thing - openssh-foo is just the company-specific stuff, it isn't a replacement for openssh - right? May 14 09:54:36 I doubt the % naming is related, that operates at a completely different level to variable values May 14 09:56:07 that is correct, it is not a replacement. May 14 09:56:16 I am not sure why the two could not be merged. May 14 09:56:30 company specific keys installed via .bbappend, but that is not for today. May 14 09:56:47 I could back that file up and remove it for a quick test whether this can cause any issues. May 14 10:01:37 actually I do not even need to back it as git checkout will get it back if I remove :) May 14 10:49:38 bluelightning: I cannot figure out. I think I will just do a fresh clean build. May 14 10:49:49 Most of the time I waste more time with fixing things than just rebuilding it :) May 14 10:50:57 have you verified that renaming the bbappend without % fixes it? May 14 10:51:29 yes and no May 14 10:51:34 first it seemed to work May 14 10:51:36 either you have or you haven't May 14 10:51:38 then I changed it back to % May 14 10:51:45 removed the other recipe May 14 10:51:49 and then that did not help May 14 10:51:59 I renamed % back to the version, and that no longer worked either May 14 10:52:06 it is kind of mysterious for me what is going on May 14 10:52:07 ok, so it has nothing to do with it May 14 10:52:17 I do not know for sure May 14 10:52:35 doing a complete fresh build is a total waste of time May 14 10:52:50 well, I have already spent more on it than rebuilding :) May 14 10:52:52 at minimum, -c cleansstate openssh will wipe out anything relating to openssh May 14 10:52:58 also, even openssh_6.5p1.bbappend no longer works now May 14 10:53:01 I do not know what is going on May 14 10:53:19 I even tried bitbake -c cleanall openssh;bitbake openssh May 14 10:54:32 this is like any other problem in computing, you follow the steps that the system will take until you find where things are going wrong May 14 10:56:06 lpapp: this is like any other problem in computing, you follow the steps that the system will take until you find where things are going wrong May 14 10:57:10 e.g. you can do an unpack and see which file is there May 14 10:57:15 in the workdir May 14 10:57:20 have you done that? May 14 11:36:04 bluelightning: unpack what? May 14 11:56:28 I am using dizzy 1.7.2 and I am facing a new problem, modprobe: no gzip/bzip2/xz magic May 14 11:56:38 do you have any clue? May 14 11:57:55 why the system suddenly started asking me for a compressed module? May 14 12:02:10 image is core-image-minimal May 14 12:05:22 mckoan: upgrade to latest dizzy revision May 14 12:05:28 busybox is broken in older May 14 12:10:24 JaMa: thx, probably I was aligend to a bad commit May 14 12:11:55 Hi, I'm running a Qt fullscreen application on EGLFS and as soone as I touch the screen I'm seeing the console in the background appearing and disappearing (flashing). How can I fix this ? May 14 12:22:16 JaMa: I cant do git pull at the moment, as quick workaround I added kmod to my image and I solved it as well May 14 12:23:07 erakis: did you test with a minimal Qt app (not full screen)? May 14 12:29:19 just for reference, the problem with insmod was solved by commit 29812e61736a95f1de64b3e9ebbb9c646ebd28dd May 14 12:33:49 mckoan : You mean by (-platform minimal) ? I did tried but it do not support GLES context, also I'm not having any x11 environment on fb. It seem to be the console in the background that is intercepting keys or touch event and printing chars. May 14 12:38:24 bluelightning: I am all kinds of lost ... May 14 12:38:27 even rebuild did not help May 14 12:38:40 and the tool that you showed me lists openssh as a valid append May 14 12:39:34 mckoan : I think I found a workaround. "echo 0 > /sys/class/vtconsole/vtcon1/bind & myQtApplication -platform eglfs & echo 0 > /sys/class/vtconsole/vtcon1/bind". But is my console will be reativated after my myQtApplication quit ? May 14 12:51:28 lpapp: bitbake -c unpack openssh May 14 12:52:03 lpapp: you don't have multiple bbappends for openssh by any chance? May 14 12:52:33 nope May 14 12:52:37 and also, the tool only shows one May 14 12:52:56 what to do after unpack? May 14 12:53:10 check if sshd_config is in the workdir? May 14 12:57:05 yep May 14 12:57:09 bluelightning: this looks correct, /home/lpapp/Projects/Yocto-daisy-32/poky-dylan-9.0.1/build/tmp/work/armv5te-foo-linux-gnueabi/openssh/6.5p1-r0/sshd_config May 14 12:57:50 lpapp: ok, maybe bitbake -c package openssh and look under packages-split/ May 14 13:01:40 bluelightning: it is wrong there. May 14 13:01:47 aha May 14 13:02:12 maybe the wrong thing is happening at do_install? May 14 13:02:32 you can cleansstate and try bitbake -c install openssh and look under image/ May 14 13:02:36 I am referring to this file: /home/lpapp/Projects/Yocto-daisy-32/poky-dylan-9.0.1/build/tmp/work/armv5te-foo-linux-gnueabi/openssh/6.5p1-r0/packages-split/openssh-sshd/etc/ssh/sshd_config May 14 13:05:52 right, but that would presumably be what got installed, so that's the next thing to check May 14 13:05:53 bluelightning: wrong one in there May 14 13:06:24 I am referring to this: /home/lpapp/Projects/Yocto-daisy-32/poky-dylan-9.0.1/build/tmp/work/armv5te-foo-linux-gnueabi/openssh/6.5p1-r0/image/etc/ssh/sshd_config May 14 13:07:25 ok, so it would be worth looking at do_install via bitbake -e openssh - is there any other install/cp/etc. command referencing sshd_config? May 14 13:11:35 bluelightning: https://paste.kde.org/pgreognea May 14 13:12:14 oh, so there's a sed command changing the very setting we are talking about May 14 13:12:57 it seems so, yes, where does that come from? May 14 13:13:27 ah, the openssh recipe May 14 13:13:57 DISTRO_FEATURES can be set per recipe? May 14 13:14:06 if not, I do not know how to solve this use case. May 14 13:14:24 normally you shouldn't, but in this case you probably can May 14 13:14:46 turning this option off is a hack anyway May 14 13:15:17 yeah, and I still do not know whether it is openssh specific or pam is broken in general May 14 13:15:33 we do want to use pam in our software, so if it is the latter, pam has tobe fixed, and not disabled May 14 13:19:51 my approach would be to look upstream for a fix... if not somewhere in there release notes then maybe in their repository May 14 13:21:11 but according to this, I cannot possibly imagine how khem raj's layer ever worked May 14 13:21:43 of course, I could always sed it back in my .bbappend? May 14 13:22:23 provided that the .bbappend's rules execute later than the corresponding .bb? May 14 13:23:51 you could, and yes they will May 14 13:24:07 but I still do not get how khem raj's layer could work May 14 13:24:30 which layer is that, sorry? May 14 13:24:37 meta-angstrom May 14 13:25:03 https://github.com/Angstrom-distribution/meta-angstrom/blob/master/recipes-tweaks/openssh/openssh_%25.bbappend May 14 13:25:16 hmm, he completely turns password authentication off May 14 13:25:26 that is not really a solution either :) May 14 13:26:52 or I miss something basic... May 14 13:32:51 bluelightning: I wonder how it is handled in master May 14 13:33:57 bluelightning: https://github.com/maximeh/buildroot/blob/master/package/openssh/openssh-01-fix-pam-uclibc-pthreads-clash.patch ? May 14 13:34:06 probably not. May 14 13:34:23 no, doesn't look like it May 14 14:46:50 morning May 14 14:57:48 bluelightning: are you still around? What would you suggest for adding a line in inittab? Again, copy? May 14 14:57:52 like with fstab May 14 14:58:17 lpapp: well, you could edit it in a do_install_append as an alternative... May 14 14:58:42 bluelightning: Yocto seems to put S1:12345:respawn:/sbin/getty 38400 ttyS1 in, but actually, I would like to remove 1 and 5 from there and use a custom line for those runlevels May 14 14:59:25 and I assume Yocto puts that in basedon the serial console variable as meta/recipes-core/sysvinit/sysvinit-inittab/inittab does not seem to contain that line, so it is likely post-processed. Is that correct? May 14 14:59:52 bluelightning: I would like to append a line like this, foo:5:respawn:/sbin/foo.sh May 14 15:00:02 can that be done through SERIAL_CONOLES or via other means? May 14 15:00:10 SERIAL_CONSOLES* May 14 15:01:00 most likely you'll have to alter it in a bbappend. SERIAL_CONSOLES only covers the tty and speed, not runlevels May 14 15:01:02 * kergoth yawns May 14 15:02:11 probably a sed+echo then May 14 15:05:21 unless I copy the whole file and change it on the way May 14 15:05:21 but even then, I wonder if SERIAL_CONCOLES could break it. May 14 15:05:21 SERIAL_CONSOLES* May 14 15:05:21 by e.g. appending the modified line again May 14 15:05:56 worst case you could presumably just empty SERIAL_CONSOLES and append your own lines entirely May 14 15:08:45 so this would be the content of my .bbappend? https://paste.kde.org/p4qgkxvdb May 14 15:10:17 sed -i reads and writes from a single file. either use -i on ${D}${sysconfdir}/inittab, or don't use -i and specify both paths to read from one and write to the other May 14 15:10:32 other than that, seems reasonable May 14 15:12:33 ah, ok, so the openssh recipe is wrong in meta/ too May 14 15:12:41 cause I looked weird at it and then trusted ^_^ May 14 15:13:21 or am I missing something with that? May 14 15:15:09 i'm guessing the -i *works*, in that it does the substitutions in place in both files, it's just pointless to do that :) May 14 15:15:22 is it enough to do the second? May 14 15:15:23 the -i with both files passed, tha tis May 14 15:15:26 i.e. the download directory? May 14 15:16:08 afaik -i on the existing file in ${D}${sysconfdir} is best, given the task it's running in. do_install shouldn't be modifying WORKDIR or S content, only D May 14 15:16:38 erakis: I didn't mean -platform minimal, I meant to try an app non running in fullscreen in order to discriminate the cause May 14 15:17:27 Hello, I need a little help on adding/building a freescale layer. May 14 15:17:46 kergoth: heh, one fatal mistake is > instead of >> May 14 15:17:59 jc_: ask May 14 15:18:00 heh, indeed, didn't spot that May 14 15:18:03 My build stops on the error: (Function failed: Fetcher failure for URL: 'git://github.com/Freescale/linux-fsl.git;branch=patches-4.0'. Unable to fetch URL from any source.) May 14 15:18:25 I have seen the github page at "https://github.com/Freescale/linux-fslc/tree/patches-4.0". May 14 15:18:45 Do i have to change the mirrors for this git? (linux-fslc-4.0+gitAUTOINC+19ebefd40a-r0)? May 14 15:19:41 I am still new to OpenEmbedded and Yocto, so this is all a learning experience for me. May 14 15:20:22 My build pulled a lot of info before this, so it is not a network problem. May 14 15:20:23 `find ./ -name inittab` fives no result run in my build directory... May 14 15:20:27 why is that? May 14 15:20:29 bitbake myimagename May 14 15:20:40 and then I expected to be available for introspection somewhere before flashing. May 14 15:27:08 jc_: please try git pull git://github.com/Freescale/linux-fsl.git May 14 15:27:25 jc_: sorry I mean "git clone" May 14 15:27:36 if it starts you can ctrl-c it May 14 15:27:58 * mckoan is on 3G network very unstable, sorry May 14 15:30:33 mckoan: fatal: remote error: Repository not found. May 14 15:35:01 mckoan: if I HTTPS instead (git clone https://github.com/Freescale/linux-fsl.git), it responds with: Username for 'https://github.com': Password for 'https://github.com': ... May 14 15:35:21 mckoan: That should only be needed if i 'push', right? May 14 15:36:02 sounds like it's a private repository, if it's shown as not existing over git:// May 14 15:36:10 in which case no, its needed for more than just pushing May 14 15:43:41 kergoth: The layer is hosted at (git://git.yoctoproject.org/meta-fsl-arm). would it still use a private repository? May 14 15:44:17 one would certainly hope not, but that's what the behavior sounds like from what you've described May 14 15:44:21 * kergoth shrugs May 14 15:44:38 mmm May 14 15:47:50 does anyone have any idea why I cannot find inittab in my build directory? Also, my board does not boot up properly after my changes :) May 14 16:38:58 is it just me, or does nativesdk-* workdir get cleaned even w/o rm_work being used? May 14 16:43:08 I've not observed that behaviour... it would be a bug if that's what's happening May 14 17:12:31 bluelightning: another question - should nativesdk packages be reused between machines in multimachine build? May 14 17:15:11 denix: I'm not positive, but it's possible that with dizzy+ if they are the same arch then yes May 14 17:16:55 bluelightning: well, they do share the workdir and deploydir, which is keyed off SDKMACHINE May 14 17:17:58 so in the general nativesdk case, yes they should be reused when SDKMACHINE stays the same May 14 17:18:22 I might be missing a subtle detail though May 14 17:19:27 so, when the second machine hasn't been built yet (no sstate?), it triggers all those nativesdk packages to be rebuilt again May 14 17:20:45 on the face of it that doesn't sound right May 14 17:21:18 bitbake-diffsigs ought to narrow down for sure why there's no reuse May 14 17:22:09 bluelightning: that's not the main problem though... once sstate gets populated for all machines, it gets reused, but for some reason all the sources from corresponding workdir are gone... May 14 17:22:45 hang on... when something is restored from sstate, you don't get sources, that's expected May 14 17:22:49 or is that not what you meant? May 14 17:23:31 and sometimes the PR goes backwards for the first machine, as PRService bumped it for the second... I sure need to run diffsigs to see why it wants to rebuild and bump PR May 14 17:24:05 as of workdir empty - but there was no rm_work, why the sources aren't there in the first place? May 14 17:28:02 PR goes backwards ?? May 14 17:29:21 denix: if e.g. populate_sysroot comes from ssstate, then the tasks leading up to it (fetch, unpack, patch, configure, compile, etc) aren't run, they're short-circuited May 14 17:29:32 so its entirely expected that workdir might be empty, or close to it, when something comes from sstate May 14 17:30:02 if you run devshell, it'll explicitly depend on those early tasks, and then they'll be run from scratch at that time May 14 17:31:31 bluelightning: ok, so populate_sysroot from dependent packages (eglibc, libgcc) trigger the rebuild of nativesdk - I'll investigate further May 14 17:32:10 kergoth: right, but those packages were built from sources sometime back and there were no rm_work, so where did they go since then? May 14 17:32:56 oh, in this tmpdir? May 14 17:33:08 denix: does WORKDIR perhaps change without the signature changing? May 14 17:33:20 kergoth: it now fails for me, since dependency has changed and it wants to rebuild, but it skips unpack and goes directly to configure, but the sources are missing May 14 17:35:06 bluelightning: WORKDIR seems to be the same... May 14 17:35:14 that shouldn't even be possible. *if* something wipes content from a task, whatever it is should also remove the associated stamps. but nothing should be removing that to begin with May 14 17:37:09 denix: which version of the build system is this with? May 14 17:43:25 kergoth, bluelightning: huh, I've been making some fixes lately, like reordering "inherit packagegroup nativesdk" w/o cleaning the build. wonder if that affected my nativesdk tmpdirs and I should just do a clean build... May 14 17:44:05 hmm, not sure, it might have changed signatures May 14 17:46:06 WOWO May 14 17:46:08 http://free-electrons.com/doc/training/yocto/yocto-labs.pdf May 14 17:46:17 googled for dialout yocto and this documentation has just come up May 14 17:46:23 the wow thing is that it is from today :) May 14 17:46:36 how much chance you have got to find a documentation published on that day ... :) May 14 17:46:43 heh, nice May 14 17:46:55 the Free Electrons folks are awesome May 14 17:47:00 or is it always recalculating the date? I would not think so. May 14 17:47:09 well, anyway, I have got a problem with ttyS1 May 14 17:47:18 bluelightning: is there an easy way to see upfront why bitbake would want to rebuild a package? or is it only after the fact by comparing signatures? May 14 17:47:19 or any other tty for that matter May 14 17:47:37 they have this permission setup: crw------- 1 root root May 14 17:47:42 I see two problems with this: May 14 17:47:46 lpapp: free electrons already had yocto labs - are you sure this is new? May 14 17:47:47 denix: there is bitbake -S printdiff May 14 17:47:48 1) no dialout or similar group May 14 17:47:54 2) no permission for the group May 14 17:48:07 now this was working with dylan; I do not know what happened to them with daisy. May 14 17:48:28 denix: I can tell you tomorrow :) May 14 17:48:39 perhaps they regenerate the pdf on request from latex source or so May 14 17:48:45 would be a bit strange, but then who knows. May 14 17:48:53 bluelightning: great! thanks, I'll give that a try May 14 17:50:00 lpapp: they may have updated something today. but it still references dora, so no, it's not brand new :) May 14 17:50:11 :-) May 14 17:50:16 bluelightning: got a clue about that permission issue? May 14 17:50:36 our services are running as "foo". That user is added to the dialout group. May 14 17:51:42 lpapp: I'm not sure what the actual issue is from your description May 14 17:51:49 is dialout not in /etc/group? May 14 17:51:56 okay, so I am trying to communicate over /dev/ttyS1, for instance May 14 17:52:10 the service using that device is not run with root privileges. May 14 17:52:16 it is run as user "foo". May 14 17:52:28 user "foo" is added to the dialout group, but apparently the permissions disregard that. May 14 17:52:37 I would expect permissions like these for that file: May 14 17:53:00 crw-rw---- 1 root uucp May 14 17:53:13 this is from my desktop, but some distributions tend to use dialout, etc, so the group is a bit flexible. May 14 17:53:32 we used to run our service with user added to dialout though when we were using dylan. May 14 17:53:49 but somehow the permissions are crw------- 1 root root with daisy. May 14 17:53:52 this is not about the user at all though... this is about the perms on the device node May 14 17:53:57 yes May 14 17:54:02 the perms on items in /dev are controlled via udev scripts May 14 17:54:23 see meta/recipes-core/udev/udev/permissions.rules May 14 17:54:53 at least, I'm assuming that is input for what ends up on the target, without digging further May 14 17:55:38 bluelightning: hmm, that reminds that we have got PREFERRED_VERSION_udev ?= "141" in our distribution config. May 14 17:55:46 could that cause the regression with daisy? May 14 17:56:28 is that the version that is actually being built? May 14 17:56:43 I have no idea, but it worked with dylan :-) May 14 17:56:43 it's possible, I couldn't say for sure May 14 17:56:51 well, the recipe is 182 May 14 17:57:34 so was it with dylan May 14 17:57:45 I do not even understand why we had that preferred version May 14 17:57:50 that setting would only work if (a) you were providing a 141 recipe and (b) there was no other setting of PREFERRED_VERSION_udev May 14 17:57:55 it is likely a void statement this way? May 14 17:58:25 if there is no 141 recipe it won't be achieving anything except producing a warning May 14 17:58:43 I think there must have been in denzil times, or so May 14 17:58:46 I will remove that line May 14 17:59:00 still, I would like to get /dev/ttyS1 accessible by a dedicated group :) May 14 17:59:05 do not want to run my services as root. May 14 17:59:51 bluelightning: that aforementioned file has, KERNEL=="tty[0-9]*", GROUP="root" May 14 18:00:11 in addition, it does not have a pattern for ttyS[0-9]* May 14 18:00:40 is it good like this? May 14 18:01:20 I am not 100% sure May 14 18:02:38 I'm no expert on udev rules I'm afraid May 14 18:02:58 I've also got to head home May 14 18:02:59 bbl May 14 18:03:13 me too :) May 14 18:03:16 thanks and see you May 14 18:09:41 ah, bluelightning has already left... May 14 18:11:02 kergoth: so, my nativesdk packages get rebuilt, because gcc-crosssdk gets rebuilt between different machines and its populate_sysroot triggers the rest. is that the correct behavior? May 14 18:30:09 Hi guys. It seems to be an discordance in between the LICENSE of socat and the file in comon licenses. The license in the package is stated as LICENSE = "GPL-2.0+-with-OpenSSL-exception" while the filename in common-licenses GPL-2.0-with-OpenSSL-exception . May 14 18:30:24 common* May 14 18:31:03 Is this a known issue? Or something that was missed? May 14 18:32:36 GPL-2.0-with-OpenSSL-Exception is a license identifier according to SPDX, the other is not May 14 18:33:19 Especially since the OpenSSL exception is usually only regarded as required with GPL-2.0, I'd say this should actually be GPL-3.0+ | GPL-2.0-with-OpenSSL-Exception, or only the latter May 14 18:33:31 But I'm in no position to change it May 14 18:34:09 neverpanic: i still don't understand how that "+" got there. May 14 18:34:17 It used to be the syntax for & ? May 14 18:34:23 anyone is in a position to change it, just submit a patch :) May 14 18:34:29 it means "any later" May 14 18:34:36 so it was probably put there on purpose May 14 18:35:48 Yeah - that's what i suspected May 14 19:06:37 Yo! Anyone awake? May 14 19:09:00 no May 14 19:09:11 Just booted my raspberry pi with a newly build yocto image and I can see it got an IP from my access point, but I cannot log in using ssh. nmap tells me it's not listning to any ports. How to enable sshd (dropbear or openssh)? May 14 19:11:35 kergoth: neverpanic I'm still confused. It seems like the warning i'm getting is at rootfs generation: May 14 19:11:45 WARNING: log_check: There is a warn message in the logfile WARNING: log_check: Matched keyword: [WARNING:] WARNING: log_check: WARNING: The license listed GPL-2.0+-with-OpenSSL-exception was not in the licenses collected for socat May 14 19:12:10 all that means is there's no generic license file for that license May 14 19:12:39 as i remeber checking for generic licenses was done at paackage time May 14 19:12:49 package build* May 14 19:13:08 image construction gathers up the generic license files to facilitate their inclusion in the image when appropriate May 14 19:13:10 see image.bbclass for details May 14 19:13:15 or license.bbclass, one of them May 14 19:13:30 previously those messages were still shown, but they were hidden in the do_rootfs log May 14 19:13:36 that was fixed recently, so they're now user-visible May 14 19:14:15 in fido i get those warnings May 14 19:14:39 kergoth: i created a file called GPL-2.0+-with-OpenSSL-exception in the common-licenses and i still get this warning May 14 19:14:53 in common-licenses where? May 14 19:15:07 meta/files/common-licenses May 14 19:15:09 if you're using a licenses dir in a layer other than oe-core, you have to adjust the search paths so it can be found there May 14 19:15:14 if you're modifying oe-core, dont' May 14 19:15:17 :) May 14 19:15:20 i know May 14 19:15:40 both options don't fix this warning May 14 19:15:57 most likely the do_popualte_lic task of the recipe is what grabs it, and then do_rootfs uses that May 14 19:16:08 but bitbake's knowledge of do_populate_lic might not be smart enough to pick up the creation of the file on disk May 14 19:16:25 try doing a -ccleansstate on the recipe and rebuilding it, or bitbake -C populate_lic socat May 14 19:16:30 then rebuild the image May 14 19:16:41 that's just a guess, of course, but worth testing May 14 19:16:42 i did May 14 19:16:47 no luck May 14 19:17:22 can you give it a try? May 14 19:17:27 just add socat in a image May 14 19:27:27 kergoth: i either miss something stupid or this is indeed broken May 14 19:31:26 agherzan: fyi, pretty sure that license is wrong. from some quick looking at the source code, nothing in the source tree says anything about being 2.0 or later, only 2.0. May 14 19:31:40 so might be best to just adjust the license of hte recipe May 14 19:31:49 unless i'm missing something, but not seeing anything May 14 19:32:53 kergoth: the problem persists at linux-firmware too: May 14 19:33:05 WARNING: log_check: There is a warn message in the logfile WARNING: log_check: Matched keyword: [WARNING:] WARNING: log_check: WARNING: The license listed Firmware-atheros_firmware was not in the licenses collected for linux-firmware WARNING: log_check: There is a warn message in the logfile WARNING: log_check: Matched keyword: [WARNING:] WARNING: log_check: WARNING: The license listed Firmware-ralink was not in the licenses collected May 14 19:33:32 linux-firmware license issues have been resolved recently, i saw patches hit the list May 14 19:33:37 check master May 14 19:33:42 so there must be something else May 14 19:34:56 kergoth: licenses weren't merged in master May 14 19:35:03 just checked May 14 19:35:37 wait May 14 19:35:39 it was a license.bbclass change, not added licenses. May 14 19:35:42 they have no generic license May 14 19:35:49 [OE-core] [PATCH v2 3/3] linux-firmware: add NO_GENERIC_LICENSE for all licenses May 14 19:36:03 NO_GENERIC_LICENSE[Firmware-atheros_firmware] = "LICENCE.atheros_firmware" May 14 19:36:08 yup May 14 19:36:15 thanks that makes sense May 14 19:36:17 thanks make May 14 19:36:19 mate* May 14 19:36:40 np **** ENDING LOGGING AT Fri May 15 02:59:58 2015