Re: [yocto] Intel Galleio Board SSH Minimal Poky Image
On 16.04.2019 17:36, nick wrote: Greetings, Hello, What is the minimal image from the poky yocto recipes that has ssh enabled by default or is it just better to enable it in the core minimal image on system startup. I would go with the core-image-minimal or the core-image-full-cmdline (depending on the requirements) and enable the ssh-server via IMAGE_FEATURES: https://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#ref-features-image Typically, at the start of development, by adding the following line in build/conf/local.conf: IMAGE_FEATURES_append = " ssh-server-openssh" Thanks, Nick -- Maciej Pijanowski Embedded Systems Engineer https://3mdeb.com | @3mdeb_com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Intel Galleio Board SSH Minimal Poky Image
Hi Nick, On 16/04/2019 16:36, nick wrote: > Greetings, > > What is the minimal image from the poky yocto recipes that has ssh enabled by > default or is it just better to enable it in the core minimal image on system > startup. core-image-minimal plus dropbear (ssh daemon) comes to 16 MB when installed (BeagleBone Black). This is just the rootfs. Add another 6 to 10 MB for bootloader and kernel. > > Thanks, > > Nick > Cheers, Chris -- Chris Simmonds, trainer and consultant at 2net http://www.2net.co.uk Author of "Mastering Embedded Linux Programming" -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Intel Galleio Board SSH Minimal Poky Image
Greetings, What is the minimal image from the poky yocto recipes that has ssh enabled by default or is it just better to enable it in the core minimal image on system startup. Thanks, Nick -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [linux-yocto] [linux-yocto v4.14] arm/Makefile: Fix systemtap
Thanks Kevin, This is now merged: b219eb2a436e..48a345e3b61e v4.14/standard/arm-versatile-926ejs -> v4.14/standard/arm-versatile-926ejs f596fd1d802b..5252513a39b4 v4.14/standard/base -> v4.14/standard/base 6fb7bd59037a..c67809688bd2 v4.14/standard/beaglebone -> v4.14/standard/beaglebone 873e1c6f41f1..d8fb40cd0e99 v4.14/standard/edgerouter -> v4.14/standard/edgerouter a7112232cd38..258ee8228e0a v4.14/standard/fsl-mpc8315e-rdb -> v4.14/standard/fsl-mpc8315e-rdb a3626e91a9d1..9ed70333fac9 v4.14/standard/intel -> v4.14/standard/intel f755b9ed57cb..5f4bd2042396 v4.14/standard/mti-malta32 -> v4.14/standard/mti-malta32 6a090aa71e6c..5c1de80e91e5 v4.14/standard/mti-malta64 -> v4.14/standard/mti-malta64 c7220ecfe9ba..d86ed237d7cf v4.14/standard/preempt-rt/base -> v4.14/standard/preempt-rt/base 879cc62ecb5e..ee960be9307e v4.14/standard/preempt-rt/intel -> v4.14/standard/preempt-rt/intel b71379749760..a8169837aaf2 v4.14/standard/qemuarm64 -> v4.14/standard/qemuarm64 5022a07d7bdb..2c7af1ccbae2 v4.14/standard/qemuppc -> v4.14/standard/qemuppc 29ed04baa16b..aa7571ecc313 v4.14/standard/tiny/base -> v4.14/standard/tiny/base 1371fce2aedb..fb22c2913bb0 v4.14/standard/tiny/common-pc -> v4.14/standard/tiny/common-pc 868e38925dce..508a14e6f02b v4.14/standard/tiny/intel -> v4.14/standard/tiny/intel 8492e08afbe7..0163da6ef132 v4.18/standard/arm-versatile-926ejs -> v4.18/standard/arm-versatile-926ejs dce546f5a33b..b24d9d2146d4 v4.18/standard/base -> v4.18/standard/base dce546f5a33b..b24d9d2146d4 v4.18/standard/beaglebone -> v4.18/standard/beaglebone dce546f5a33b..b24d9d2146d4 v4.18/standard/edgerouter -> v4.18/standard/edgerouter 32e53bb51eef..0802dc980cbc v4.18/standard/fsl-mpc8315e-rdb -> v4.18/standard/fsl-mpc8315e-rdb dce546f5a33b..b24d9d2146d4 v4.18/standard/intel -> v4.18/standard/intel 45ab7de40ef2..fd55b7eb9074 v4.18/standard/intel-socfpga -> v4.18/standard/intel-socfpga dce546f5a33b..b24d9d2146d4 v4.18/standard/intel-x86 -> v4.18/standard/intel-x86 ecec6866c67a..c755c4907708 v4.18/standard/mti-malta32 -> v4.18/standard/mti-malta32 9de1e96b7587..a5b2107abcdb v4.18/standard/mti-malta64 -> v4.18/standard/mti-malta64 82e47952e138..c92f5f6097c7 v4.18/standard/preempt-rt/base -> v4.18/standard/preempt-rt/base 8d5b34b7c091..e171fe1b498c v4.18/standard/preempt-rt/intel -> v4.18/standard/preempt-rt/intel b96ed399bd53..9a24c2c31a7b v4.18/standard/preempt-rt/intel-x86 -> v4.18/standard/preempt-rt/intel-x86 dce546f5a33b..b24d9d2146d4 v4.18/standard/qemuarm64 -> v4.18/standard/qemuarm64 dce546f5a33b..b24d9d2146d4 v4.18/standard/qemuppc -> v4.18/standard/qemuppc 6163aadae99c..adc7d47598fd v4.18/standard/tiny/arm-versatile-926ejs -> v4.18/standard/tiny/arm-versatile-926ejs dce546f5a33b..b24d9d2146d4 v4.18/standard/tiny/base -> v4.18/standard/tiny/base dce546f5a33b..b24d9d2146d4 v4.18/standard/tiny/common-pc -> v4.18/standard/tiny/common-pc dce546f5a33b..b24d9d2146d4 v4.18/standard/tiny/intel -> v4.18/standard/tiny/intel Bruce On Mon, Apr 15, 2019 at 4:10 AM Kevin Hao wrote: > > From: Richard Purdie > > Currently systemtap fails to operate correctly on armv7 systems such as > beaglebone and > soon, qemuarm. > > root@qemuarm:/usr/src/kernel# env -uARCH -uKBUILD_EXTMOD -uCROSS_COMPILE > -uKBUILD_IMAGE -uKCONFIG_CONFIG -uINSTALL_PATH -uLD_LIBRARY_PATH > PATH=/usr/bin:/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin > make -C /lib/modules/4.19.19-yocto-standard/build M=/tmp/staptcNU6M modules > CONFIG_DEBUG_INFO= CONFIG_STACK_VALIDATION= ARCH=arm stap_4321_src.i > --no-print-directory -j2 V=1 > test -e include/generated/autoconf.h -a -e include/config/auto.conf || ( > \ > echo >&2; \ > echo >&2 " ERROR: Kernel configuration is invalid."; \ > echo >&2 " include/generated/autoconf.h or include/config/auto.conf > are missing.";\ > echo >&2 " Run 'make oldconfig && make prepare' on kernel src to fix > it."; \ > echo >&2 ; \ > /bin/false) > mkdir -p /tmp/staptcNU6M/.tmp_versions ; rm -f /tmp/staptcNU6M/.tmp_versions/* > make -f ./scripts/Makefile.build obj=/tmp/staptcNU6M > (cat /dev/null; echo kernel//tmp/staptcNU6M/stap_4321.ko;) > > /tmp/staptcNU6M/modules.order > gcc -Wp,-MD,/tmp/staptcNU6M/.stap_4321_src.o.d -nostdinc -isystem > /usr/lib/gcc/arm-poky-linux-gnueabi/8.3.0/include -I./arch/arm/include > -I./arch/arm/include/generated -I./include -I./arch/arm/include/uapi > -I./arch/arm/include/generated/uapi -I./include/uapi > -I./include/generated/uapi -include ./include/linux/kconfig.h -include > ./include/linux/compiler_types.h -D__KERNEL__ -mlittle-endian -Wall -Wundef > -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common > -fshort-wchar -Werror-implicit-function-declaration
Re: [linux-yocto] v4.18.x - stable updates comprising v4.18.35
On Sun, Apr 14, 2019 at 9:36 AM Paul Gortmaker wrote: > > Bruce, Yocto kernel folks: > > Here is the next 4.18.x stable update "extension" primarily created > for the Yocto project, continuing from the previous v4.18.34 release. > > There are just over 185 commits here, based on commits chosen from > what was used in the recent 4.19.33 stable release. > > Fortunately there is no one stand out feature with a bunch of fixes > applied - they seem fairly uniformly spread out once again. > > I've put this 4.18.x queue through the usual testing; build testing > on x86-64/32, ARM-64/32, PPC and MIPS, plus some static analysis > and finally some sanity runtime tests on x86-64. > > I did the signed tag just as per the previously released versions. > Please find a signed v4.18.35 tag using this key: > > http://pgp.mit.edu/pks/lookup?op=vindex=0xEBCE84042C07D1D6 > > in the repo in the kernel.org directory here: > > > https://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux-4.18.y.git/?h=linux-4.18.y > git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux-4.18.y.git > > for merge to standard/base in linux-yocto-4.18 and then out from there > into the other base and BSP branches. > Looks fine to me. This is now merged. Bruce > For those who are interested, the evolution of the commits is here: > > https://git.kernel.org/cgit/linux/kernel/git/paulg/longterm-queue-4.18.git/ > > This repo isn't needed for anything; it just exists for transparency and > so people can see the evolution of the raw commits that were originally > selected to create this 4.18.x release. > > Paul. -- - Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end - "Use the force Harry" - Gandalf, Star Trek II -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] [kernel-cache][master][PATCH 0/3] support for Intel virtual RAID
No problem, I've now cherry picked them to 5.0. Bruce On Tue, Apr 16, 2019 at 2:03 AM Liwei Song wrote: > > Hi Bruce, > > > Could you also help apply these three patches to yocto-kernel-cache yocto-5.0 > branch. > I missed this branch. > > Thanks, > Liwei. > > > On 03/21/2019 11:41 AM, Liwei Song wrote: > > Hi Bruce, > > > > These three patches used to built-in nvme driver and efivarfs driver to > > kernel > > to make boot from Intel Virtual disk work. > > Also enable CONFIG_VMD kernel configuration > > > > Aim at master branch. > > > > Thanks, > > Liwei. > > > > Liwei Song (3): > > intel-x86: built-in nvme driver to support boot from nvme disk > > cfg/efi.cfg: built-in CONFIG_EFIVAR_FS to support Intel VROC > > intel-x86: add Intel VMD support > > > > bsp/intel-x86/intel-x86-64.scc | 1 + > > bsp/intel-x86/intel-x86.cfg | 2 +- > > cfg/efi.cfg | 2 +- > > features/intel-vmd/intel-vmd.cfg | 1 + > > features/intel-vmd/intel-vmd.scc | 4 > > 5 files changed, 8 insertions(+), 2 deletions(-) > > create mode 100644 features/intel-vmd/intel-vmd.cfg > > create mode 100644 features/intel-vmd/intel-vmd.scc > > -- - Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end - "Use the force Harry" - Gandalf, Star Trek II -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] [PATCH 4.19-rt] Revert "mm: handle lru_add_drain_all for UP properly"
On Mon, Apr 15, 2019 at 12:02 PM Paul Gortmaker
wrote:
>
> This reverts commit e6e9d6e290028b0a6b83b563fad9fafa7f1d515e.
>
> It was a 4.19.31 backport of commit 6ea183d60c46 ("mm: handle
> lru_add_drain_all for UP properly"). In summary, what that did
> was to fix a possible harmless WARN_ON on non-SMP, introduced at
> commit 4d43d395fed1 ("workqueue: Try to catch flush_work() without
> INIT_WORK().") by adding non-SMP variants of lru functions.
>
> The combination of that, with the -rt commit 473f14a9f234 ("mm:
> perform lru_add_drain_all() remotely") at the merge of the two
> results in the following build failure:
>
> mm/swap.c:736:2: error: #endif without #if
>
> since the -rt change wants RT specific lru and the stable backport
> wants non-SMP specific lru, and a chunk of the backport with
> an #ifdef CONFIG_SMP is missing.
>
> However, before we add a four way cluster of ifdeffery to handle all
> cases, we note 4d43d395fed1 was added to the v5.1 release, and it
> was not (currently) backported to any 4.19.x stable release - so it is
> unclear to me why this commit was ever backported to 4.19.31 at all.
>
> Further, we note this change was to mm/swap.c -- and by definition,
> any preempt-rt deployment that uses swap for anything other than a
> failure contingency mitigation is broken by design.
>
> Given all that, I decided that the best path forward was to revert
> the two of the three chunks of the backport that remain in the -rt
> branch, and return us to the pre-4.19.31 merge behaviour for -rt.
>
Paul, this is now merged. There's been a lot of churn in these
functions, so thanks for the help fixing it up!
Bruce
> Signed-off-by: Paul Gortmaker
>
> diff --git a/mm/swap.c b/mm/swap.c
> index 7e0bcaf450a5..9217027671c8 100644
> --- a/mm/swap.c
> +++ b/mm/swap.c
> @@ -325,6 +325,11 @@ static inline void activate_page_drain(int cpu)
> {
> }
>
> +static bool need_activate_page_drain(int cpu)
> +{
> + return false;
> +}
> +
> void activate_page(struct page *page)
> {
> struct zone *zone = page_zone(page);
> @@ -728,12 +733,6 @@ void lru_add_drain_all(void)
>
> mutex_unlock();
> }
> -#else
> -void lru_add_drain_all(void)
> -{
> - lru_add_drain();
> -}
> -#endif
>
> /**
> * release_pages - batched put_page()
> --
> 2.7.4
>
--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II
--
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto
[yocto] [OE-core] Yocto Project Status WW15'19
Current Dev Position: YP 2.7 M4 (2.7 rc2 is in QA) Next Deadline: YP 2.7 Release Target April 26, 2019 SWAT Team Rotation: SWAT lead is currently: Chen SWAT team rotation: Chen -> Armin on Apr. 19, 2019SWAT team rotation: Armin -> Anuj on Apr. 26, 2019 https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team Next Team Meetings: YP 2.8 Planning meeting Tuesday April 16nd at 8am PDT ( https://zoom.us/j/990892712) Bug Triage meeting Thursday April 18th at 7:30am PDT (https://zoom.us/j/454367603) Key Status/Updates: Stephen is unavailable at the moment, please refer any queries to RichardYP 2.6.2 was rebuilt as rc4 to include the boost upgrade revert and is due to be released today. The YP 2.6.2 rc3/4 report is summarized at https://lists.yoctoproject.org/pipermail/yocto/2019-April/044827.html and the results are at https://autobuilder.yocto.io/pub/releases/yocto -2.6.2.rc4/testresults/.YP 2.5.3 is currently going through the QA process.We’re sad to announce that we will be removing eclipse plugin builds from the autobuilder and will not be including the plugin in any future project releases. This is due to a lack of anyone able to help work on the plugin development, bug fixing or release.The key fixes mentioned in last week’s status have been merged into 2.7.A key bug in pseudo was identified which may be the root cause of the long standing glibc-locale uid “host contamination” issue. Many thanks to Peter and Otavio for the help in debugging that. A separate fix should also ensure pseudo works with newer distro coreutils and glibc versions.YP 2.7 rc2 (warrior) was built successfully and is currently going through the QA process after 2.5.3 is done.The ptest results in 2.7 are much more stable than ever before with results being consistent from build to build. At the start of 2.8 we can make some further improvements so we take advantage of this and build upon it to reduce regressions in the system.In an effort to keep the patch queue under control, patches are merging to master.The list of issues from last week of worrying things we lack resources to improve upon remains:Intermittent autobuilder failures (fork running out of resources - which resources?, oe-selftest intermittent issues, gpg signing resource problems, occasional PR server failure and more)Build-appliance testing issues (show up on each QA report across multiple releases)40% valgrind ptest failuresKnown bitbake memory resident bugsOther ptest failuresThe 2.8 planning discussions are starting and there is a google doc summarising the discussions so far: https://docs.google.com/document/d/1CNEKA4d0eT6-e0hnS2pwi7xdZ5_t6smpZO2HbaJGXbU/If people are planning to work on specific things in 2.8 please let us know so we can incorporate this into our plans. If you’re interested in working on anything in the document, please also let us know or talk with us in one of the planning meetings. Planned Releases for YP 2.7: YP 2.7 M4 Cutoff was Apr. 1, 2019YP 2.7 M4 Release Target is Apr. 26, 2019 Planned upcoming dot releases: YP 2.5.3 (Sumo) is in QA. Tracking Metrics: WDD 2523 (last week 2471) ( https://wiki.yoctoproject.org/charts/combo.html)Poky Patch Metrics Total patches found: 1553 (last week 1553)Patches in the Pending State: 654 (42%) [last week 655 (42%)] Key Status Links for YP: https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.7_Status https://wiki.yoctoproject.org/wiki/Yocto_2.7_Schedule https://wiki.yoctoproject.org/wiki/Yocto_2.7_Features The Status reports are now stored on the wiki at: https://wiki.yoctoproject.org/wiki/Weekly_Status [If anyone has suggestions for other information you’d like to see on this weekly status update, let us know!] -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Yocto (poky) thud build problems with xen-image-minimal
Greetings, I have just transitioned to a clean upgrade to 'thud' (poky) and I'm having problems executing a test build of "xen-image minimal". My bblayers.conf file contains the following layers ... BBLAYERS ?= " \ /home/kbassford/repo/poky/meta \ /home/kbassford/repo/poky/meta-poky \ /home/kbassford/repo/poky/meta-yocto-bsp \ /home/kbassford/repo/poky/meta-openembedded/meta-oe \ /home/kbassford/repo/poky/meta-openembedded/meta-filesystems \ /home/kbassford/repo/poky/meta-openembedded/meta-python \ /home/kbassford/repo/poky/meta-openembedded/meta-networking \ /home/kbassford/repo/poky/meta-openembedded/meta-perl \ /home/kbassford/repo/poky/meta-intel \ /home/kbassford/repo/poky/meta-selinux \ /home/kbassford/repo/poky/meta-virtualization \ /home/kbassford/repo/poky/meta-security \ " My local.conf is appended with the following ... # Customizations DISTRO_FEATURES_append = " xen virtualization " IMAGE_INSTALL_append += " bridge-utils wireshark" IMAGE_EXTRA_INSTALL ?= " strace" CORE_IMAGE_EXTRA_INSTALL ?= " strace" PACKAGECONFIG_append_pn-recipename = " dhcp dhcpcd" IMAGE_ROOTFS_SIZE = "381600" BB_ENV_WHITELIST = " IMAGE_ROOTFS_EXTRA_SPACE" # for Dom0 BOOTIMG_EXTRA_SPACE = '825312' BOOTIMG_VOLUME_ID = 'dom0sd' The first failure I encountered was this ... glibc-locale-2.28: glibc-locale: Files/directories were installed but not shipped in any package: /usr/lib/gconv/EBCDIC-DK-NO-A.so /usr/lib/gconv/IBM1097.so /usr/lib/gconv/IBM874.so /usr/lib/gconv/ISO8859-14.so /usr/lib/gconv/IBM865.so /usr/lib/gconv/IBM1157.so /usr/lib/gconv/MAC-CENTRALEUROPE.so /usr/lib/gconv/IBM274.so /usr/lib/gconv/EUC-JP.so /usr/lib/gconv/IBM1025.so ... This has been documented on and off through several releases, usually solved by using "DISTRO_FEATURES_append =" in place of "DISTRO_FEATURES +=" in the local.conf file. Despite my local.conf containing "DISTRO_FEATURES_append = " the compile fails. Compiling glibc-locale by itself succeeds (bitbake glibc-locale -c cleanall && bitbake glibc-locale) The second failure I encountered was ... util/zbin.c:7:18: fatal error: lzma.h: No such file or directory #include ^ compilation terminated. Compiling xz-native by itself succeeds, but compiling ipxe by itself fails with the same error. Could someone from the community tell me what I'm overlooking? Are there bugs in the aforementioned recipes? Apologies for the length, I wanted to include all the details up front. Thanks in advance. Sincerely, Ken Bassford Apertus Solutions -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Failed to execute GCC
On Tuesday, April 16, 2019 3:10 AM JH wrote: > I am building an image on Ubuntu 18.04 host, I got following error: > unable to execute 'x86_64-linux-gnu-gcc': No such file or directory | error: > command 'x86_64-linux-gnu-gcc' failed with exit status 1 > I can see the x86_64-linux-gnu-gcc is available, but why it failed to find it? > $ which x86_64-linux-gnu-gcc > /usr/bin/x86_64-linux-gnu-gcc Could you provide more details, please? Which Yocto version do you use? Could you present some more context or logs? What does following command does? file /usr/bin/x86_64-linux-gnu-gcc Best regards, Lukasz Zemla *** The information in this email is confidential and intended solely for the individual or entity to whom it is addressed. If you have received this email in error please notify the sender by return e-mail, delete this email, and refrain from any disclosure or action based on the information. *** -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-selinux][PULL] refpolicy: update to 2.20190201 and git HEAD policies (2019-04-10 10:57:14 -0400)
Hi all, Update on this, I've just now completed this merge (with Yi's corrected SRC_URI for the RELEASE_2.20190201 tag) and I'm going to start pulling in the additional meta-selinux patches that have been sent to the mailing list. I'll prep a queue of those updates soon and send out another pull mail to the list in order to keep everyone reasonably informed of what's in and what's not. Once that happens, if you have a patch that's still pending but not in my pull list, please let me know with a follow up to the list. Thanks, -J. [[yocto] [meta-selinux][PULL] refpolicy: update to 2.20190201 and git HEAD policies (2019-04-10 10:57:14 -0400)] On 19.04.10 (Wed 11:53) Joe MacDonald wrote: > This is a huge, long-overdue update the refpolicy. I apologise for it > blocking the other outstanding meta-selinux patches, but I've been > trying to limit the scope of changes while this happens. Now that this > is cleared off the slate, I'll be gathering up the other meta-selinux > patches from the list. I'll send out a follow-up on those as they're > merged and another when I think I'm done, so if I've missed your patch, > that'll be the time to ping me about it. > > As for this, here's what I've done. > > - manually reviewed all patches that had been present in > repolicy-* for both the old stable (2.20170204) and git > versions > > - forked the SELinuxPolicy/refpolicy repo and applied all > still-relevant patches to the RELEASE_2.20190201 branch > > - restructured the patches so that all patches that should > reasonably apply to all variants (mcs, mls, minimum, standard > and targeted) were in a common branch and only the ones that > are specific to each variant would be in their own recipe > > - restructure the patches so that systemd and sysvinit patches > were not applied to the same tree > > - created a parallel set of branches for each of these against > current git HEAD > > The results of this can be examined here: > > https://github.com/joeythesaint/refpolicy > > Then each of these were exported and put in the appropriate SRC_URIs so > the branch structure is more-or-less preserved. > > My goals with this approach were the following: > > - make it easier to keep refpolicy up to date, particularly for > anyone wanting to use the git variants > > - make it easier to determine how your preferred version of > refpolicy on Yocto differs from upstream refpolicy > > - limit the above differences to the minimum to achieve the goal > of a functional Yocto system > > - eventually move us away from release tarballs entirely > > That last point is why I'm preserving the refpolicy fork above. I'd > like to keep going with this and so future refpolicy patches will first > be put in that repo then exported and applied to the SRC_URIs. If you > have such a patch and want to send me a PR against the branch you think > it belongs on from github directly, that'd be awesome, but the old > method of patches to the mailing list will work fine too, just know that > this is the way I'm going to try to manage this for the foreseeable > future. Ultimately, if this proves to work well, I would like to move > the refpolicy fork off github and house it on git.yoctoproject.org > beside meta-selinux, but the workflow needs to be properly validated > first. > > One additional point, I intend to take another pass at revising this > stuff, ideally moving the huge number of common patches out as well. > There's still some that aren't necessary for base yocto but are for > additional layers. That's fine for us to have, but I'd like to get > those moved to optional layer directories so we're making the best use > of that functionality we can. If you have suggestions on which pieces > already present are good candidates, let me know. Similarly, if you've > got additional policy patches you want to see included, feel free to > send them along, we can easily move them to optional locations inside > meta-selinux. > > Finally, please everyone test this and provide feedback on anything that > doesn't work or looks strange. This is easily the biggest change we've > had in meta-selinux in years and I expect there's still some wrinkles to > be ironed out. And I really appreciate everyone's patience while we got > to this point and hope it's not too much more pain before we put a > ribbon on this and call it done. > > I'll give this until at least the weekend before merging it to master, > pending comments or an overwhelming "please just do it" from the > community. > > Thanks. > > --- > > The following changes since commit a6a3cadb1ef3203a123d8f5f9df27832f55b2ce3: > > Backport patches from upstream to fix build with musl (2019-03-25 09:43:53 > +0100) > > are available in the Git repository at: > > git://git.yoctoproject.org/meta-selinux yocto/master-next > > for
[yocto] [meta-selinux][PULL] consolidated meta-selinux updates
Hi all,
This is the promised update to meta-selinux, incorporating all of the
current pending patches I'm aware of on the list. As before, I'll give
everyone a couple of days to check this out and raise any questions or
concerns before merging it. Please take a look and let me know if
you've got a pending change that isn't here. There were a couple that
didn't get merged, but I think the only ones I dropped were due to being
no longer applicable (for example Yi's updates to refpolicy to the 2018
release).
The following changes since commit d6686698444616b9857a15bb514400f8a629e7ed:
refpolicy: update to 2.20190201 and git HEAD policies (2019-04-12 15:28:38
-0400)
are available in the Git repository at:
git://git.yoctoproject.org/meta-selinux yocto/master-next
for you to fetch changes up to e0105eed2b2461bf08b7aaf71db12dfae6ca51e3:
audit: change to use ${WORKDIR} instead ${S}/../ (2019-04-15 09:02:21 -0400)
Chen Qi (1):
audit: change to use ${WORKDIR} instead ${S}/../
Kai Kang (2):
layer.conf: update to warrior release name series
setools: fix build failure with gcc 7
Luca Boccassi (1):
packagegroup-selinux-minimal: add selinux-init
Sinan Kaya (1):
libpcre: do no create links when compiling for windows
Yi Zhao (4):
core-image-selinux.bb: remove trailing whitespace
openssh: update sshd_config
selinux-image.bbclass: using append instead of += for
IMAGE_PREPROCESS_COMMAND
selinux: remove git version
classes/selinux-image.bbclass | 2 +-
conf/layer.conf| 2 +-
recipes-connectivity/openssh/files/sshd_config | 53 +++--
recipes-security/audit/audit_2.8.4.bb | 2 +-
recipes-security/images/core-image-selinux.bb | 2 +-
.../packagegroups/packagegroup-selinux-minimal.bb | 1 +
recipes-security/selinux/checkpolicy_git.bb| 6 --
recipes-security/selinux/libselinux_git.bb | 14
recipes-security/selinux/libsemanage_git.bb| 17
recipes-security/selinux/libsepol_git.bb | 8 --
recipes-security/selinux/policycoreutils_git.bb| 6 --
recipes-security/selinux/selinux_git.inc | 11 ---
...ailure-with-GCC-7-due-to-possible-truncat.patch | 90 ++
recipes-support/libpcre/libpcre_selinux.inc| 20 +++--
14 files changed, 118 insertions(+), 116 deletions(-)
delete mode 100644 recipes-security/selinux/checkpolicy_git.bb
delete mode 100644 recipes-security/selinux/libselinux_git.bb
delete mode 100644 recipes-security/selinux/libsemanage_git.bb
delete mode 100644 recipes-security/selinux/libsepol_git.bb
delete mode 100644 recipes-security/selinux/policycoreutils_git.bb
delete mode 100644 recipes-security/selinux/selinux_git.inc
--
-Joe MacDonald.
:wq
signature.asc
Description: PGP signature
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Screenshot tool
Hi Evan, We don't currently have a 4.9 kernel running for our project since we're working mainly with mobile devices which are stuck on 3.4 and 3.18 kernels for now, however we do have small screenshot utility which we have as a plugin to our compositor which we have been using since early Qt5 releases and we're currently on Qt 5.11/5.12. Might be worth to give a go at your end: https://github.com/webOS-ports/luna-next/blob/f5fc4c8af0d0c6f74f57d3963eb570966bc8fa55/plugins/compositor/screenshooter.cpp And the header file at: https://github.com/webOS-ports/luna-next/blob/f5fc4c8af0d0c6f74f57d3963eb570966bc8fa55/plugins/compositor/screenshooter.h Hope this helps. Best regards, Herman On 2019-04-16 09:15, Evan O'Loughlin wrote: Hi, I’m currently using yocto to build a custom OS based on Linux 4.9 for our hardware: Build Configuration: BB_VERSION= "1.32.0" BUILD_SYS = "x86_64-linux" NATIVELSBSTRING = "Ubuntu-16.04" TARGET_SYS= "arm-linux-gnueabi" MACHINE = "CUSTOM_MACHINE_NAME" DISTRO= "arago" DISTRO_VERSION= "2017.12" TUNE_FEATURES = "arm armv7a vfp thumb neon callconvention-hard" TARGET_FPU= "hard" meta-processor-sdk = "HEAD:92db4d8023d88ab59fab2953e7447ec0bd5a6db1" meta-ros = "HEAD:e2566402ab108a19634354a934788109422cf409" meta-arago-distro meta-arago-extras = "HEAD:5b2a44b0c4d989133bc13d59398fd10375d351bb" meta-browser = "HEAD:26d50665e2f7223c5f4ad7481a8d2431e7cb55fb" meta-openamp = "HEAD:8a214032bfb7e8124bc1485c70c69f7d60abb819" meta-qt5 = "HEAD:2c9f0e4eb0e9097f6f872ec1e1d81768a8ab5f1b" meta-networking meta-ruby meta-python meta-oe meta-gnome meta-multimedia = "HEAD:b40116cf457b88a2db14b86fda9627fb34d56ae6" meta-ti = "HEAD:3dc08477529b31ce887bb22a08201a843ded48f0" meta-linaro-toolchain meta-optee= "HEAD:d73e794c7e7ebb1cc5bf495a52a72b26fb118250" meta = "HEAD:39fd8c129e2bff7f2f1649b7f6e036ccc50fd5d8" meta-custom = "" meta-printing = "morty:72811bc3755d1a943fa2a2e79601781b44a77420" We run a Qt5 application using EGLFS but can no longer capture screenshots. In a previous yocto build based on Linux 3.x we were able to use a screenshot tool which effectively just read /dev/fb0 to a file. I believe this was a change to how the underlying drivers interact with the GPU/Screen - I've started reading up on KMS/DRM. Does anyone know is there a utility/tool which I could use to capture the Qt5 application as its drawn on screen? Regards, Evan -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Screenshot tool
Hi, I’m currently using yocto to build a custom OS based on Linux 4.9 for our hardware: Build Configuration: BB_VERSION= "1.32.0" BUILD_SYS = "x86_64-linux" NATIVELSBSTRING = "Ubuntu-16.04" TARGET_SYS= "arm-linux-gnueabi" MACHINE = "CUSTOM_MACHINE_NAME" DISTRO= "arago" DISTRO_VERSION= "2017.12" TUNE_FEATURES = "arm armv7a vfp thumb neon callconvention-hard" TARGET_FPU= "hard" meta-processor-sdk = "HEAD:92db4d8023d88ab59fab2953e7447ec0bd5a6db1" meta-ros = "HEAD:e2566402ab108a19634354a934788109422cf409" meta-arago-distro meta-arago-extras = "HEAD:5b2a44b0c4d989133bc13d59398fd10375d351bb" meta-browser = "HEAD:26d50665e2f7223c5f4ad7481a8d2431e7cb55fb" meta-openamp = "HEAD:8a214032bfb7e8124bc1485c70c69f7d60abb819" meta-qt5 = "HEAD:2c9f0e4eb0e9097f6f872ec1e1d81768a8ab5f1b" meta-networking meta-ruby meta-python meta-oe meta-gnome meta-multimedia = "HEAD:b40116cf457b88a2db14b86fda9627fb34d56ae6" meta-ti = "HEAD:3dc08477529b31ce887bb22a08201a843ded48f0" meta-linaro-toolchain meta-optee= "HEAD:d73e794c7e7ebb1cc5bf495a52a72b26fb118250" meta = "HEAD:39fd8c129e2bff7f2f1649b7f6e036ccc50fd5d8" meta-custom = "" meta-printing = "morty:72811bc3755d1a943fa2a2e79601781b44a77420" We run a Qt5 application using EGLFS but can no longer capture screenshots. In a previous yocto build based on Linux 3.x we were able to use a screenshot tool which effectively just read /dev/fb0 to a file. I believe this was a change to how the underlying drivers interact with the GPU/Screen - I've started reading up on KMS/DRM. Does anyone know is there a utility/tool which I could use to capture the Qt5 application as its drawn on screen? Regards, Evan -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [linux-yocto] [kernel-cache][master][PATCH 0/3] support for Intel virtual RAID
Hi Bruce, Could you also help apply these three patches to yocto-kernel-cache yocto-5.0 branch. I missed this branch. Thanks, Liwei. On 03/21/2019 11:41 AM, Liwei Song wrote: > Hi Bruce, > > These three patches used to built-in nvme driver and efivarfs driver to kernel > to make boot from Intel Virtual disk work. > Also enable CONFIG_VMD kernel configuration > > Aim at master branch. > > Thanks, > Liwei. > > Liwei Song (3): > intel-x86: built-in nvme driver to support boot from nvme disk > cfg/efi.cfg: built-in CONFIG_EFIVAR_FS to support Intel VROC > intel-x86: add Intel VMD support > > bsp/intel-x86/intel-x86-64.scc | 1 + > bsp/intel-x86/intel-x86.cfg | 2 +- > cfg/efi.cfg | 2 +- > features/intel-vmd/intel-vmd.cfg | 1 + > features/intel-vmd/intel-vmd.scc | 4 > 5 files changed, 8 insertions(+), 2 deletions(-) > create mode 100644 features/intel-vmd/intel-vmd.cfg > create mode 100644 features/intel-vmd/intel-vmd.scc > -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
