Re: bitbake controlling memory use
Richard Purdie
On Sun, 2021-04-18 at 00:17 +0200, Gmane Admin wrote:
Hi,It would need to be: PARALLEL_MAKE_pn-nodejs = "-j 1" So I watched it run for a while. It compiles with g++ and as at aboutIf that works, the override above should also work. You do need the "pn-" prefix to the recipe name though. Cheers, Richard
|
|
Re: bitbake controlling memory use
Gmane Admin
Hi,
Op 14-04-2021 om 06:59 schreef Richard Purdie: On Tue, 2021-04-13 at 21:14 -0400, Randy MacLeod wrote:I tried PARALLEL_MAKE_nodejs = "-j 1" from local.conf but that didn't work.On 2021-04-11 12:19 p.m., Alexander Kanavin wrote:make already has -l option for limiting new instances if load average isDuring today's Yocto technical call (1), So I watched it run for a while. It compiles with g++ and as at about 0.5GB per thread, which is OK. In the end it does ld taking 4GB and it tries to do 4 in parallel. And then swapping becomes so heavy the desktop becomes unresponsive. Like I mentioned before ssh from another machine allows me to STOP one of them, allowing the remaining to complete. And then CONT the last one. I worked around it now, by creating a bbappend for nodejs with only PARALLEL_MAKE = "-j 2" In the longer run, changes to how bitbake schedules work may be needed.http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/wipqueue4&id=d66a327fb6189db5de8bc489859235dcba306237
|
|
Re: [PATCH yocto-autobuilder-helper 1/4] config.json: add "collect-data" template
On 2021-04-15 4:48 p.m., Randy MacLeod wrote:
On 2021-04-15 1:55 p.m., Randy MacLeod wrote:Thanks for fixing the fall-out due to assumptions in other tests.On 2021-04-15 11:55 a.m., Richard Purdie wrote:Richard,On Thu, 2021-04-15 at 11:31 -0400, Sakib Sajal wrote:We were using it for testing on the YP AB and thought it would beOn 2021-04-15 9:52 a.m., Richard Purdie wrote:[Please note: This e-mail is from an EXTERNAL e-mail address] Is the system back to normal and operational now? What was the impact of running the heartbeat and the dd test every 10 seconds on the system build performance? Should we increase the interval to 30, 60, ore more seconds? I spent some time looking at the first bit of data along with Sakib and Saul from time to time. General conclusions: 1. It seems like ALL triggers involve oe-selftest being active. 2. xz might be a problem but we're not sure yet. 3. We need more data and tools and time to think about it. To Do: 1. increase top cmdline length from 512 to 16K 2. sometimes we see: Command '['oe-time-dd-test.sh', '100']' timed out after 10.0 seconds That should not happen so we should understand why and either increase the time between runs or fix the tooling. This seems to happen under load so it's hiding the interesting data that we are looking for! 3. tail the cooker console in addition to top. Present that before top. It would be nice to have a top equivalent for bitbake. We did collect some triggered host data last night as seen in: https://autobuilder.yocto.io/pub/non-release/ https://autobuilder.yocto.io/pub/non-release/20210415-16/ Only one a-full build was run. There were 10 log files produced. There were 21 times that the dd time exceeded the 5 second limit out of a total of 21581 (or so!) invocations and those triggers we captured by 10 log files: testresults/beaglebone-alt/2021-04-16--00-19/host_stats_0_top.txt testresults/qa-extras2/2021-04-15--22-43/host_stats_2_top.txt testresults/qa-extras2/2021-04-15--22-43/host_stats_4_top.txt testresults/qa-extras2/2021-04-15--22-43/host_stats_6_top.txt testresults/qa-extras2/2021-04-15--22-43/host_stats_8_top.txt testresults/qemuarm/2021-04-16--00-02/host_stats_0_top.txt testresults/qemuarm/2021-04-16--00-02/host_stats_1_top.txt testresults/qemumips-alt/2021-04-15--23-36/host_stats_1_top.txt testresults/qemumips64/2021-04-16--02-46/host_stats_0_top.txt testresults/qemux86-world/2021-04-16--00-00/host_stats_0_top.txt We knew that our naming convention needed work in that the files are generically named and differ only by the directory datastamp and, where the logs contain 'top' output or not the _top suffix. We'd like to help whoever is looking at the data understand what the context of the build was. That's not clear to Sakib and I given that we are YP AB newbies still. Do you have any suggestions about what the directory structure or file naming convention should be? The other thing need to do is correlate these higher latency times with the intermittent problems we've encountered. We can do that manually I support via the SWAT team but ideally there would be an automated process. More quick analysis... The number of times that top ran per log file: $ grep "^top - " `fd _top autobuilder.yocto.io/` | cut -d":" -f1 | uniq -c | \ sed -e 's|autobuilder.yocto.io/pub/non-release/20210415-16/||' 2 testresults/beaglebone-alt/2021-04-16--00-19/host_stats_0_top.txt 3 testresults/qa-extras2/2021-04-15--22-43/host_stats_2_top.txt 1 testresults/qa-extras2/2021-04-15--22-43/host_stats_4_top.txt 2 testresults/qa-extras2/2021-04-15--22-43/host_stats_6_top.txt 1 testresults/qa-extras2/2021-04-15--22-43/host_stats_8_top.txt 5 testresults/qemuarm/2021-04-16--00-02/host_stats_0_top.txt 2 testresults/qemuarm/2021-04-16--00-02/host_stats_1_top.txt 1 testresults/qemumips-alt/2021-04-15--23-36/host_stats_1_top.txt 2 testresults/qemumips64/2021-04-16--02-46/host_stats_0_top.txt 2 testresults/qemux86-world/2021-04-16--00-00/host_stats_0_top.txt some of these are duplicates in that the different steps _2,4,6,8 above A little shell hacking can produce one file per top output with ample access to stackoverflow! COUNTER=1 for i in `fd _top`; do for j in `grep "^top - " $i | cut -c 7-15`; do sed -n "/top - ${j}/,/Event Time:/p" $i >> host-stats-$j--$COUNTER.log; ((COUNTER++)); done; done This works because the first line of time is similar to: top - 15:40:53 up 2 days, 22:17, 1 user, load average: 0.36, 0.58, 0.85 so cutting out chars 7-15 gives a fairly uniq timestamp string for the filename and adding the counter makes it unique. Now we have 21 log files: $ ls host-stats-2* | wc -l 21 How big are these files, ie how many process/kernel threads were running when top ran? $ wc -l host-stats-2* | sort -n 757 host-stats-22:12:32--17.log 778 host-stats-22:18:21--8.log 784 host-stats-21:59:42--5.log 785 host-stats-21:59:42--12.log 792 host-stats-22:18:01--7.log 800 host-stats-22:18:21--14.log 811 host-stats-22:07:40--13.log 812 host-stats-22:07:59--6.log 821 host-stats-21:56:21--3.log 850 host-stats-21:59:33--11.log 856 host-stats-21:59:33--4.log 869 host-stats-22:29:49--16.log 884 host-stats-22:29:14--9.log 886 host-stats-22:29:36--15.log 981 host-stats-21:55:40--10.log 985 host-stats-22:47:27--2.log 987 host-stats-22:47:27--21.log 1124 host-stats-22:37:33--1.log 1193 host-stats-22:37:26--20.log 1304 host-stats-23:19:14--19.log 1321 host-stats-23:18:57--18.log 19380 total I noticed that several but not all log files were running xz with args like: xz -a --memlimit=50% --threads=56 $ for i in `ls host-stats-2*`; do echo -n $i ": "; grep "xz " $i | wc -l; done host-stats-21:55:40--10.log : 28 host-stats-21:56:21--3.log : 4 host-stats-21:59:33--11.log : 1 host-stats-21:59:33--4.log : 1 host-stats-21:59:42--12.log : 1 host-stats-21:59:42--5.log : 1 host-stats-22:07:40--13.log : 2 host-stats-22:07:59--6.log : 2 host-stats-22:12:32--17.log : 0 host-stats-22:18:01--7.log : 6 host-stats-22:18:21--14.log : 3 host-stats-22:18:21--8.log : 3 host-stats-22:29:14--9.log : 1 host-stats-22:29:36--15.log : 0 host-stats-22:29:49--16.log : 0 host-stats-22:37:26--20.log : 56 host-stats-22:37:33--1.log : 16 host-stats-22:47:27--21.log : 0 host-stats-22:47:27--2.log : 0 host-stats-23:18:57--18.log : 0 host-stats-23:19:14--19.log : 18 In this case, I don't think it's a problem but if we had several packages running xz like that at once with a limit of 50% of memory each, that could be a problem. Has anyone looked at the time impact of say reducing the number of threads to 32 and the memory limit to 15% ? All of the top output logs seems to be running oe-selftest: $ for i in host-stats-2*; do grep -H -c "DISPLAY.*oe-selftest " $i ; done host-stats-21:55:40--10.log:1 host-stats-21:56:21--3.log:1 host-stats-21:59:33--11.log:1 host-stats-21:59:33--4.log:1 host-stats-21:59:42--12.log:1 host-stats-21:59:42--5.log:1 host-stats-22:07:40--13.log:1 host-stats-22:07:59--6.log:1 host-stats-22:12:32--17.log:1 host-stats-22:18:01--7.log:1 host-stats-22:18:21--14.log:1 host-stats-22:18:21--8.log:1 host-stats-22:29:14--9.log:1 host-stats-22:29:36--15.log:1 host-stats-22:29:49--16.log:1 host-stats-22:37:26--20.log:1 host-stats-22:37:33--1.log:1 host-stats-22:47:27--21.log:1 host-stats-22:47:27--2.log:1 host-stats-23:18:57--18.log:2 host-stats-23:19:14--19.log:2 $ for i in host-stats-2*; do grep -H -c "DISPLAY.*oe-selftest " $i ; done | wc -l 21 Yikes, that seems like more than just random chance. The logs do not seem to be duplicates in that there isn't a single cluster of identical or similar timestamps although some are close and are likely from the same file. That said they certainly don't seem to be spread out uniformly over time and that's what we all expect in that the system response time is okay for much of the time and is poor for quite a while every now and then. $ for i in host-stats-2*; do echo -n $i ": "; head -1 $i | cut -c -15; done host-stats-21:55:40--10.log : top - 21:55:40 host-stats-21:56:21--3.log : top - 21:56:21 host-stats-21:59:33--11.log : top - 21:59:33 host-stats-21:59:33--4.log : top - 21:59:33 host-stats-21:59:42--12.log : top - 21:59:42 host-stats-21:59:42--5.log : top - 21:59:42 host-stats-22:07:40--13.log : top - 22:07:40 host-stats-22:07:59--6.log : top - 22:07:59 host-stats-22:12:32--17.log : top - 22:12:32 host-stats-22:18:01--7.log : top - 22:18:01 host-stats-22:18:21--14.log : top - 22:18:21 host-stats-22:18:21--8.log : top - 22:18:21 host-stats-22:29:14--9.log : top - 22:29:14 host-stats-22:29:36--15.log : top - 22:29:36 host-stats-22:29:49--16.log : top - 22:29:49 host-stats-22:37:26--20.log : top - 22:37:26 host-stats-22:37:33--1.log : top - 22:37:33 host-stats-22:47:27--21.log : top - 22:47:27 host-stats-22:47:27--2.log : top - 22:47:27 host-stats-23:18:57--18.log : top - 23:18:57 host-stats-23:19:14--19.log : top - 23:19:14 All for now. ../Randy -- # Randy MacLeod # Wind River Linux
|
|
#yocto #bitbake #gatesgarth #qca9377
#qca9377
#yocto
#bitbake
#gatesgarth
jovanalukovic0@...
Hi,
I am trying to include qca9377 module in my image (yocto-gatesgarth). I am using command bitbake imx-image-full, and i added two lines in my local.conf file: MACHINE_FEATURES += " qca9377" IMAGE_INSTALL_append += " kernel-module-qca9377", but i get constantly the same mistake: ERROR: kernel-module-qca9377-3.1-r0 do_compile: oe_runmake failed ERROR: kernel-module-qca9377-3.1-r0 do_compile: Execution of '/home/jovana/Projects/imx-yocto-bsp-gates/build-xwayland/tmp/work/imx7ulpevk-poky-linux-gnueabi/kernel-module-qca9377/3.1-r0/temp/run.do_compile.25256' failed with exit code 1: make -C /home/jovana/Projects/imx-yocto-bsp-gates/build-xwayland/tmp/work-shared/imx7ulpevk/kernel-source M=/home/jovana/Projects/imx-yocto-bsp-gates/build-xwayland/tmp/work/imx7ulpevk-poky-linux-gnueabi/kernel-module-qca9377/3.1-r0/git modules WLAN_ROOT=/home/jovana/Projects/imx-yocto-bsp-gates/build-xwayland/tmp/work/imx7ulpevk-poky-linux-gnueabi/kernel-module-qca9377/3.1-r0/git MODNAME?=wlan CONFIG_QCA_WIFI_ISOC=0 CONFIG_QCA_WIFI_2_0=1 CONFIG_QCA_CLD_WLAN=m WLAN_OPEN_SOURCE=1 make[1]: Entering directory '/home/jovana/Projects/imx-yocto-bsp-gates/build-xwayland/tmp/work-shared/imx7ulpevk/kernel-source' make[2]: Entering directory '/home/jovana/Projects/imx-yocto-bsp-gates/build-xwayland/tmp/work-shared/imx7ulpevk/kernel-build-artifacts' and this is just a part of whole group of mistakes. There are a lot of mistakes, for examples: cc1: some warnings being treated as errors | /home/jovana/Projects/imx-yocto-bsp-gates/build-xwayland/tmp/work-shared/imx7ulpevk/kernel-source/scripts/Makefile.build:279: recipe for target '/home/jovana/Projects/imx-yocto-bsp-gates/build-xwayland/tmp/work/imx7ulpevk-poky-linux-gnueabi/kernel-module-qca9377/3.1-r0/git/CORE/HDD/src/wlan_hdd_oemdata.o' failed | make[3]: *** [/home/jovana/Projects/imx-yocto-bsp-gates/build-xwayland/tmp/work/imx7ulpevk-poky-linux-gnueabi/kernel-module-qca9377/3.1-r0/git/CORE/HDD/src/wlan_hdd_oemdata.o] Error 1 | /home/jovana/Projects/imx-yocto-bsp-gates/build-xwayland/tmp/work-shared/imx7ulpevk/kernel-source/scripts/Makefile.build:279: recipe for target '/home/jovana/Projects/imx-yocto-bsp-gates/build-xwayland/tmp/work/imx7ulpevk-poky-linux-gnueabi/kernel-module-qca9377/3.1-r0/git/CORE/HDD/src/wlan_hdd_early_suspend.o' failed. Do you have eny ideas what can i do? Do i miss something for my compiling? Best regards and thanks a lot!
|
|
#bitbake Can't use 'bitbake -g <image-name> -u taskdep
#bitbake
keydi <krzysztof.dudziak@...>
Hi,
Myself had to ask web search engine for usage of Task Dependency Explorer taskexp as I didn't succeed on search in Yocto materials. Hence, the way I try to use taskexp might be not right. In the fashion as I try to start Task Dependency Explorer it does not work. Invocation completes with error in __init__.py -> require_version figures out lack of Gtk namespace. Which is build-area Gtk is missed? Image, distribution, yet another? Which way of fixing should I aim to resolve error? File "/mnt/..../meta/poky/bitbake/lib/bb/ui/taskexp.py", line 22, in <module>
gi.require_version('Gtk', '3.0')
File "/usr/lib/python3/dist-packages/gi/__init__.py", line 130, in require_version
raise ValueError('Namespace %s not available' % namespace)
ValueError: Namespace Gtk not available
Best Regards keydi
|
|
Re: [PATCH yocto-autobuilder-helper 2/4] config.json: collect data by default
Richard Purdie
On Fri, 2021-04-16 at 09:28 +0100, Richard Purdie via lists.yoctoproject.org wrote:
On Tue, 2021-04-13 at 13:02 -0400, sakib.sajal@windriver.com wrote:There is also another issue as BB_HEARTBEAT_EVENT defaults to 1, the change to 10add the variables required to collect data to "defaults"I merged 2-4 of this series, unfortunately this resulted in a few issues overnight: changes the default timings for buildstats and other pieces of code. In particular I suspect this is breaking: https://autobuilder.yoctoproject.org/typhoon/#/builders/80/builds/1993 and again in: https://autobuilder.yoctoproject.org/typhoon/#/builders/79/builds/2014 in the disk monitoring selftest... Cheers, Richard
|
|
Re: [PATCH yocto-autobuilder-helper 2/4] config.json: collect data by default
Richard Purdie
On Tue, 2021-04-13 at 13:02 -0400, sakib.sajal@windriver.com wrote:
add the variables required to collect data to "defaults"I merged 2-4 of this series, unfortunately this resulted in a few issues overnight: https://autobuilder.yoctoproject.org/typhoon/#/builders/85/builds/1393 which is due to the non-executable script which there is a patch for, it just wasn't in master due to the release. I've fixed that by merging the patches. The bigger issue is the performance metrics which this broke: https://autobuilder.yoctoproject.org/typhoon/#/builders/91/builds/4427 https://autobuilder.yoctoproject.org/typhoon/#/builders/92/builds/4453 We're going to need to disable these events on the performance metrics targets... Cheers, Richard
|
|
Re: Building image from Root
Mike Looijmans
You can use both by changing the directory for downloads and sstate-cache. Put these in your local.conf:
toggle quoted messageShow quoted text
SSTATE_DIR = "/opt/sstate-cache" DL_DIR = "/opt/downloads" (You change "/opt" to some other location. Make sure you have write access to those directories) Move the contents of the build/sstate-cache and downloads to the new directories. You really should consider adding extra storage. It's the easiest way out. OpenEmbedded/Yocto is insensitive to disk speed, so if you have some old rotating disk in the attic, put that in your PC. Met vriendelijke groet / kind regards, Mike Looijmans System Expert TOPIC Embedded Products B.V. Materiaalweg 4, 5681 RJ Best The Netherlands T: +31 (0) 499 33 69 69 E: mike.looijmans@topicproducts.com W: www.topic.nl Please consider the environment before printing this e-mail
On 15-04-2021 17:34, Murugesh M via lists.yoctoproject.org wrote:
Hi --
Mike Looijmans
|
|
Re: Building image from Root
try adding
toggle quoted messageShow quoted text
INHERIT += "rm_work" to local.conf and see if that helps
On Thu, Apr 15, 2021 at 11:11 PM Murugesh M <murugesh.pappu@gmail.com> wrote:
|
|
Re: Building image from Root
Murugesh M
I had proceeded the Build image process with Home directory and got stuck with low disk space.
Now, the build image process is stopped almost near to last stage. Please provide me any suggestion to come out of this problem.
|
|
Re: [PATCH yocto-autobuilder-helper 1/4] config.json: add "collect-data" template
On 2021-04-15 1:55 p.m., Randy MacLeod wrote:
On 2021-04-15 11:55 a.m., Richard Purdie wrote:Richard,On Thu, 2021-04-15 at 11:31 -0400, Sakib Sajal wrote:We were using it for testing on the YP AB and thought it would beOn 2021-04-15 9:52 a.m., Richard Purdie wrote:[Please note: This e-mail is from an EXTERNAL e-mail address] I think that the web server for: https://autobuilder.yocto.io/pub/non-release/ runs every 30 seconds via cron so if you are happy with this crude dd trigger once things have soaked in master-next and we want to gather some data overnight, could you merge to master? I ran a simpler test with fewer io stressors from: $ stress -hdd N and have attached a graph with up to 3000! stressors that we looked at this morning and another with up to 35 stressors. It's a crude indicators but once we get beyond 18-20 io stressors on the system I tested (48 cores, 128 GB RAM, 12 TB magnetic disk) dd time become erratic. Running qemu from tmpfs has clearly helped. Let's gather some data and decide if we want to spend more time learning how to monitor the system to tune how we are using it. ../Randy ../RandyI had a quick look at the code and sadly, it doesn't appear I implementedThe template is not used anywhere, yet, the initial patchset enables the -- # Randy MacLeod # Wind River Linux
|
|
Re: [PATCH yocto-autobuilder-helper 1/4] config.json: add "collect-data" template
On 2021-04-15 11:55 a.m., Richard Purdie wrote:
On Thu, 2021-04-15 at 11:31 -0400, Sakib Sajal wrote:We were using it for testing on the YP AB and thought it would beOn 2021-04-15 9:52 a.m., Richard Purdie wrote:[Please note: This e-mail is from an EXTERNAL e-mail address] useful if at some point the monitoring was dropped from the default config. I think we can just add it later if needed. ../Randy I had a quick look at the code and sadly, it doesn't appear I implementedThe template is not used anywhere, yet, the initial patchset enables the -- # Randy MacLeod # Wind River Linux
|
|
Re: [PATCH yocto-autobuilder-helper 1/4] config.json: add "collect-data" template
Richard Purdie
On Thu, 2021-04-15 at 11:31 -0400, Sakib Sajal wrote:
On 2021-04-15 9:52 a.m., Richard Purdie wrote:I had a quick look at the code and sadly, it doesn't appear I implemented[Please note: This e-mail is from an EXTERNAL e-mail address]The template is not used anywhere, yet, the initial patchset enables the nesting so this wouldn't be that useful as things stand. Cheers, Richard
|
|
Building image from Root
Murugesh M
Hi I am new to Yocto project and have little experience in Linux. In my computer, Root folder is having free space of 65 GB and Home is having 45 GB free space. Shall I get the poky in root folder and do the complete Yocto build image process from Root directory itself? Please suggest. Thanks.
|
|
Re: [PATCH yocto-autobuilder-helper 1/4] config.json: add "collect-data" template
Richard Purdie
On Tue, 2021-04-13 at 13:02 -0400, sakib.sajal@windriver.com wrote:
collect-data template can run arbitrary commands/scriptsIs the template used anywhere? I can't remember if we support nesting templates in which case this is useful, or not? Cheers, Richard
|
|
what to include in a "hardware bringup image"?
Robert P. J. Day
for a current project (and subsequent projects), i want to define a
hardware bringup image; that is, a really basic image chock-full of low-level utilities for debugging initial board bringup. this means precious little unnecessary userspace crud that has no value in that context. (at the moment, the target is aarch64 but, naturally, the ideal image would be maximally applicable no matter the target.) i'm thinking of recipes that allow probing/configuration of memory and busses and that sort of thing. off the top of my head: * pciutils * usbutils * libgpiod * phytool (or other MDIO probe/debug tools) * devmem2 * spidev-test/spitools * i2c-tools the list can go on and on, and i just ran across this which i had never seen before: http://cgit.openembedded.org/meta-openembedded/tree/meta-oe/recipes-support/c-periphery/c-periphery_2.3.1.bb?h=master suggestions? i suspect numerous folks on this list have already done something like this. rday
|
|
Re: [meta-selinux][PATCH] openssh: don't overwrite sshd_config unconditionally
Purushottam choudhary
Hi,
Could you please let me know if there is any update on this change? Thanks & Regards,
Purushottam
From: Purushottam Choudhary <purushottam.choudhary@...>
Sent: Tuesday, March 16, 2021 3:03 PM To: yocto@... <yocto@...> Cc: Nisha Parrakat <Nisha.Parrakat@...> Subject: [yocto][meta-selinux][PATCH] openssh: don't overwrite sshd_config unconditionally The current implementation was overwriting the sshd_config and sshd
assuming PAM is needed by default. openssh should use the default sshd_config packaged with the component if no distro specific needs are present and not overwrite the full sshd_config file. 1. If PAM is enabled as a distro then enable the UsePAM option in sshd_config. 2. Moved the file sshd to pam directory so that when pam is enabled, then replace the default from poky by installing the same. Signed-off-by: Purushottam Choudhary <purushottam.choudhary@...> --- recipes-connectivity/openssh/files/{ => pam}/sshd | 0 recipes-connectivity/openssh/files/sshd_config | 118 ---------------------- recipes-connectivity/openssh/openssh_%.bbappend | 14 +++ 3 files changed, 14 insertions(+), 118 deletions(-) rename recipes-connectivity/openssh/files/{ => pam}/sshd (100%) delete mode 100644 recipes-connectivity/openssh/files/sshd_config diff --git a/recipes-connectivity/openssh/files/sshd b/recipes-connectivity/openssh/files/pam/sshd similarity index 100% rename from recipes-connectivity/openssh/files/sshd rename to recipes-connectivity/openssh/files/pam/sshd diff --git a/recipes-connectivity/openssh/files/sshd_config b/recipes-connectivity/openssh/files/sshd_config deleted file mode 100644 index 1c33ad0..0000000 --- a/recipes-connectivity/openssh/files/sshd_config +++ /dev/null @@ -1,118 +0,0 @@ -# $OpenBSD: sshd_config,v 1.102 2018/02/16 02:32:40 djm Exp $ - -# This is the sshd server system-wide configuration file. See -# sshd_config(5) for more information. - -# This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin - -# The strategy used for options in the default sshd_config shipped with -# OpenSSH is to specify options with their default value where -# possible, but leave them commented. Uncommented options override the -# default value. - -#Port 22 -#AddressFamily any -#ListenAddress 0.0.0.0 -#ListenAddress :: - -#HostKey /etc/ssh/ssh_host_rsa_key -#HostKey /etc/ssh/ssh_host_ecdsa_key -#HostKey /etc/ssh/ssh_host_ed25519_key - -# Ciphers and keying -#RekeyLimit default none - -# Logging -#SyslogFacility AUTH -#LogLevel INFO - -# Authentication: - -#LoginGraceTime 2m -#PermitRootLogin prohibit-password -#StrictModes yes -#MaxAuthTries 6 -#MaxSessions 10 - -#PubkeyAuthentication yes - -# The default is to check both .ssh/authorized_keys and .ssh/authorized_keys2 -# but this is overridden so installations will only check .ssh/authorized_keys -#AuthorizedKeysFile .ssh/authorized_keys - -#AuthorizedPrincipalsFile none - -#AuthorizedKeysCommand none -#AuthorizedKeysCommandUser nobody - -# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts -#HostbasedAuthentication no -# Change to yes if you don't trust ~/.ssh/known_hosts for -# HostbasedAuthentication -#IgnoreUserKnownHosts no -# Don't read the user's ~/.rhosts and ~/.shosts files -#IgnoreRhosts yes - -# To disable tunneled clear text passwords, change to no here! -#PasswordAuthentication yes -#PermitEmptyPasswords no - -# Change to yes to enable challenge-response passwords (beware issues with -# some PAM modules and threads) -ChallengeResponseAuthentication no - -# Kerberos options -#KerberosAuthentication no -#KerberosOrLocalPasswd yes -#KerberosTicketCleanup yes -#KerberosGetAFSToken no - -# GSSAPI options -#GSSAPIAuthentication no -#GSSAPICleanupCredentials yes - -# Set this to 'yes' to enable PAM authentication, account processing, -# and session processing. If this is enabled, PAM authentication will -# be allowed through the ChallengeResponseAuthentication and -# PasswordAuthentication. Depending on your PAM configuration, -# PAM authentication via ChallengeResponseAuthentication may bypass -# the setting of "PermitRootLogin without-password". -# If you just want the PAM account and session checks to run without -# PAM authentication, then enable this but set PasswordAuthentication -# and ChallengeResponseAuthentication to 'no'. -UsePAM yes - -#AllowAgentForwarding yes -#AllowTcpForwarding yes -#GatewayPorts no -#X11Forwarding no -#X11DisplayOffset 10 -#X11UseLocalhost yes -#PermitTTY yes -#PrintMotd yes -#PrintLastLog yes -#TCPKeepAlive yes -#UseLogin no -#PermitUserEnvironment no -Compression no -ClientAliveInterval 15 -ClientAliveCountMax 4 -#UseDNS no -#PidFile /var/run/sshd.pid -#MaxStartups 10:30:100 -#PermitTunnel no -#ChrootDirectory none -#VersionAddendum none - -# no default banner path -#Banner none - -# override default of no subsystems -Subsystem sftp /usr/libexec/sftp-server - -# Example of overriding settings on a per-user basis -#Match User anoncvs -# X11Forwarding no -# AllowTcpForwarding no -# PermitTTY no -# ForceCommand cvs server diff --git a/recipes-connectivity/openssh/openssh_%.bbappend b/recipes-connectivity/openssh/openssh_%.bbappend index 7719d3b..b541c3e 100644 --- a/recipes-connectivity/openssh/openssh_%.bbappend +++ b/recipes-connectivity/openssh/openssh_%.bbappend @@ -1 +1,15 @@ require ${@bb.utils.contains('DISTRO_FEATURES', 'selinux', '${BPN}_selinux.inc', '', d)} + +# if pam feature is enabled in the distro then take sshd from the pam directory. +FILESEXTRAPATHS_prepend := "${@bb.utils.contains('DISTRO_FEATURES', 'pam', '${THISDIR}/files/pam:', ' ', d)}" + +do_install_append(){ + + if [ "${@bb.utils.filter('DISTRO_FEATURES', 'pam', d)}" ]; then + # Make sure UsePAM entry is in the sshd_config file. + # If entry not present then append it. + grep -q 'UsePAM' "${D}/etc/ssh/sshd_config" && \ + sed -i 's/.*UsePAM.*/UsePAM yes/' "${D}/etc/ssh/sshd_config" || \ + echo 'UsePAM yes' >> "${D}/etc/ssh/sshd_config" + fi +} -- 2.7.4
|
|
[meta-intel-fpga] [PATCH] layer.conf: add layer compatibility to hardknott
Meng Li
From: Meng Li <Meng.Li@windriver.com>
Signed-off-by: Meng Li <Meng.Li@windriver.com> --- conf/layer.conf | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/conf/layer.conf b/conf/layer.conf index 756e7f4..4b45db9 100644 --- a/conf/layer.conf +++ b/conf/layer.conf @@ -9,6 +9,6 @@ BBFILE_PATTERN_meta-intel-fpga := "^${LAYERDIR}/" # Increase the layer priority BBFILE_PRIORITY_meta-intel-fpga = "6" -LAYERSERIES_COMPAT_meta-intel-fpga = "dunfell gatesgarth" +LAYERSERIES_COMPAT_meta-intel-fpga = "dunfell gatesgarth hardknott" BBDEBUG = "yes" -- 2.17.1
|
|
Re: #golang: go fetches dependencies in compile phase
Hi,
My comments are inline. On 12/04/2021 14:47, Juergen Landwehr wrote: Hi Robert,... if everybody does what they are supposed to - which is not the case. Dependencies and their version is stored in "go.mod". To ensure reproducable builds, hashes for each dependency and version are stored in "go.sum". Both files are in git and together with a local golang proxy, this should ensure reproducable builds, right?This does not sound too bad. This would also mean, that if the outside repo dies you can still build and that you know what's on your proxy. To ensure that licences are valid and did not change over time, we developed a little tool, that goes through all dependencies and creates the following output, which we insert into our recipe:Here you 1) Totally lost which License comes from which module and I hope 2 times MIT is just a typo. Of course if you are really serious about licensing you should use a tool like fossology, upload all your sources there and inspect them. You will be surprised. There are a couple of tools out there which scan your sources and some which claim to do stuff with golang as well. 2) Do you check if the licenses are compatible? MIT and Apache are compatible: some googling: "Both the Apache License and the MIT license are permissive, so incorporating MIT licensed code into your Apache licensed project is certainly allowed. Just be sure to attribute the original author for the parts your incorporated and include a copy of the MIT License terms, as required by the license." Apache and BSD should also be OK: some googling: "In both of them you must: Include copyright But in Apache, unlike BSD you must: Include License State Changes Include Notice " LIC_FILES_CHKSUM = " \really all? You search through every single file of a go module and it's dependencies? Or just the license text, if there is one? It might pollute the recipe a bit, but luckily we do not have thousands of dependencies like some npm projects. So I think it is still manageable. And is it much less work, than defining a recipe for each dependency.Regards, Robert
|
|
Re: Cannot execute nodejs
Alessandro Tagliapietra
I was able to solve it by forcing recompiling nodejs with `bitbake -f -c compile nodejs` Not sure what happened there -- Alessandro Tagliapietra
On Wed, Apr 14, 2021 at 11:51 AM Alessandro Tagliapietra <tagliapietra.alessandro@...> wrote: Hi everyone,
|
|