[yocto] [PATCH] meta-yocto-bsp: Disable the glamor acceleration for the beaglebone
In the commit ec6d61cbddc3 ("mesa: enable native and nativesdk
variants"), the gallium is enabled for the mesa. Since we use the
modesetting driver for the Xorg on the beagleboard and the glamor
acceleration method is enabled by the modesetting driver, the gallium
DRI driver will be used after this commit. But the gallium DRI driver
only support 32bpp and we choose to use 16bpp on beaglebone in commit
e7434c17b4b3 ("meta-yocto-bsp: workaround the X malfunction on
beaglebone"), the mismatch between them causes the malfunction of the
Xorg. I have hacked the kernel to enable the 32bpp for the beagllebone,
but it has the following issues:
1. The color is abnormal.
2. The Xorg hang occasionally.
3. The performance of using glamor acceleration based on gallium is
pretty bad.
So I choose to disable the glamor on this board.
Signed-off-by: Kevin Hao
---
.../xorg-xserver/xserver-xf86-config/beaglebone-yocto/xorg.conf | 1 +
1 file changed, 1 insertion(+)
diff --git
a/meta-yocto-bsp/recipes-graphics/xorg-xserver/xserver-xf86-config/beaglebone-yocto/xorg.conf
b/meta-yocto-bsp/recipes-graphics/xorg-xserver/xserver-xf86-config/beaglebone-yocto/xorg.conf
index 2f40dae15710..5da15888d44b 100644
---
a/meta-yocto-bsp/recipes-graphics/xorg-xserver/xserver-xf86-config/beaglebone-yocto/xorg.conf
+++
b/meta-yocto-bsp/recipes-graphics/xorg-xserver/xserver-xf86-config/beaglebone-yocto/xorg.conf
@@ -5,6 +5,7 @@ EndSection
Section "Device"
Identifier "Builtin Default fbdev Device 0"
Driver "modesetting"
+Option "AccelMethod" "none"
EndSection
Section "Screen"
--
2.14.4
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [linux-yocto] [kernel-cache][RFC 0/3] qemuarm|qemuarm64: graphics support
On Thu, Feb 28, 2019 at 5:09 PM Bruce Ashfield wrote: > > On Wed, Feb 27, 2019 at 10:58 PM Jon Mason wrote: > > > > This series reverts the reversion of qemuarm match for qemuarma15, and > > adds graphics support for both qemuarm and qemuarm64. > > > > I'm sending this out as an RFC as there are some issues with the > > implementation, and this should probably only be included if the > > forthcoming patches for meta/conf/machine/qemuarm64.conf and > > meta/conf/machine/qemuarm.conf are acceptable. > > The series looks fine to me (at least patch 1 and 3). To allow us > flexibility in the > future, I'll leave qemuarm out of the qemuarma15 machine .scc file .. > and instead > can do a patch that adds: > > KMACHINE_qemuarm ?= "qemuarma15" > > to linux-yocto_* in the master branch. > > That will have the same end result, if you build qemuarm, the tools will go > look > for the qemuarma15 match and will find your new definitions for the > kernel build. > > That way, I can backport future config changes to older release branches and > they won't change how the old qemuarm works. > > When we get to the fall release, I can drop the KMACHINE mapping, and make > the change to the kernel meta data directly. Fantastic! Thanks for doing this. Thanks, Jon > > I'll do up a queue with that in it shortly. > > Cheers, > > Bruce > > > > > Thanks, > > Jon > > > > > > Jon Mason (3): > > qemuarma15: Undo the revert of qemuarm match > > qemuarma15: Add graphics support > > qemuarm64: Add graphics support > > > > bsp/qemuarm64/qemuarm64-gfx.cfg | 7 +++ > > bsp/qemuarm64/qemuarm64.scc | 1 + > > bsp/qemuarma15/qemuarma15-gfx.cfg| 7 +++ > > bsp/qemuarma15/qemuarma15-preempt-rt.scc | 1 + > > bsp/qemuarma15/qemuarma15-standard.scc | 1 + > > bsp/qemuarma15/qemuarma15-tiny.scc | 1 + > > bsp/qemuarma15/qemuarma15.cfg| 3 +++ > > bsp/qemuarma15/qemuarma15.scc| 1 + > > 8 files changed, 22 insertions(+) > > create mode 100644 bsp/qemuarm64/qemuarm64-gfx.cfg > > create mode 100644 bsp/qemuarma15/qemuarma15-gfx.cfg > > > > -- > > 2.17.2 > > > > -- > > ___ > > linux-yocto mailing list > > linux-yocto@yoctoproject.org > > https://lists.yoctoproject.org/listinfo/linux-yocto > > > > -- > - 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][RFC 0/3] qemuarm|qemuarm64: graphics support
On Wed, Feb 27, 2019 at 10:58 PM Jon Mason wrote: > > This series reverts the reversion of qemuarm match for qemuarma15, and > adds graphics support for both qemuarm and qemuarm64. > > I'm sending this out as an RFC as there are some issues with the > implementation, and this should probably only be included if the > forthcoming patches for meta/conf/machine/qemuarm64.conf and > meta/conf/machine/qemuarm.conf are acceptable. The series looks fine to me (at least patch 1 and 3). To allow us flexibility in the future, I'll leave qemuarm out of the qemuarma15 machine .scc file .. and instead can do a patch that adds: KMACHINE_qemuarm ?= "qemuarma15" to linux-yocto_* in the master branch. That will have the same end result, if you build qemuarm, the tools will go look for the qemuarma15 match and will find your new definitions for the kernel build. That way, I can backport future config changes to older release branches and they won't change how the old qemuarm works. When we get to the fall release, I can drop the KMACHINE mapping, and make the change to the kernel meta data directly. I'll do up a queue with that in it shortly. Cheers, Bruce > > Thanks, > Jon > > > Jon Mason (3): > qemuarma15: Undo the revert of qemuarm match > qemuarma15: Add graphics support > qemuarm64: Add graphics support > > bsp/qemuarm64/qemuarm64-gfx.cfg | 7 +++ > bsp/qemuarm64/qemuarm64.scc | 1 + > bsp/qemuarma15/qemuarma15-gfx.cfg| 7 +++ > bsp/qemuarma15/qemuarma15-preempt-rt.scc | 1 + > bsp/qemuarma15/qemuarma15-standard.scc | 1 + > bsp/qemuarma15/qemuarma15-tiny.scc | 1 + > bsp/qemuarma15/qemuarma15.cfg| 3 +++ > bsp/qemuarma15/qemuarma15.scc| 1 + > 8 files changed, 22 insertions(+) > create mode 100644 bsp/qemuarm64/qemuarm64-gfx.cfg > create mode 100644 bsp/qemuarma15/qemuarma15-gfx.cfg > > -- > 2.17.2 > > -- > ___ > linux-yocto mailing list > linux-yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/linux-yocto -- - 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] Proper way to set locale and keymap
Hi all, After some experiments on Poky thud I have found this method to set my fr_CH.utf8 local and fr_CH-latin keymap in my distribution with systemd and without busybox: Add this two lines to the local configuration or distribution configuration file: GLIBC_GENERATE_LOCALES = "fr_CH.UTF-8" IMAGE_LINGUAS = "fr-ch" After boot add this file to set local in the shell environment variable: cat < /etc/profile.d/locale.sh if [ -r /etc/locale.conf ]; then export \$(cat /etc/locale.conf) fi EOF Finally set the locale and keymap either with the localctl command: localectl set-locale fr_CH.utf8 localectl set-keymap fr_CH-latin1 Or by directly creating this two files: echo "LANG=fr_CH.utf8" > /etc/locale.conf echo "KEYMAP=fr_CH-latin1" > /etc/vconsole.conf The result is workable but a lot of [Alt Gr] + key characters are missing. Please comment on this method and if a recipe already exist to do that. Best regards. Jean-Christian de Rivaz -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] ROS support on yocto project
Hi, >It does work. BTW, afaik there is no yocto 3.9.0, 2.6.1 is last stable if I am >not mistaken. I think Oscar is referring to the BSP version. 3.9.0 was a recent release. Regards Steve From: yocto-boun...@yoctoproject.org On Behalf Of Matthias Schoepfer Sent: 28 February 2019 17:26 To: yocto@yoctoproject.org Subject: Re: [yocto] ROS support on yocto project Hi! Yes, there is, there is a meta-ros. For your convenience: https://discourse.ros.org/t/new-version-of-meta-ros-for-kinetic-distribution/2833 https://github.com/bmwcarit/meta-ros It does work. BTW, afaik there is no yocto 3.9.0, 2.6.1 is last stable if I am not mistaken. Regards, Matthias On 2/21/19 9:26 AM, Carlos Pozos Ochoa wrote: I recently acquire a Renesas R Car M3 board which runs on an embedded linux image build by means of the Yocto project. We are currently using YOCTO 3.9.0. We are looking forward to implement ROS kinetic libraries on this embedded linux. Does the yocto project supports this libraries? In the case it does, is there any special process to install and run them? Or is it work as a normal linux distribution? -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Removing busybox
On Wed, Feb 27, 2019 at 05:42:03PM +, Burton, Ross wrote: > On Wed, 27 Feb 2019 at 17:27, Mark Hatle wrote: > > You can also blacklist busybox to ensure that it never builds, and thus > > can't > > show up in your target image. > > > > PNBLACKLIST[busybox] = "Don't build this" > > Sounds like someone should write a new selftest that does the required > configuration changes as per Tom's mail, blacklists busybox, and then > tries a core-image-sato build. This would double as a check that we > don't break it in the future, and a documented example of how to do it Can you point me at a test that just does a 'bitbake -g' or similar check-don't-build type test and I'll go off and add this to my series that adds packagegroup-core-base-utils? Thanks! -- Tom signature.asc Description: PGP signature -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] ROS support on yocto project
Hi Carlos, When you say ROS do you mean the Robotic OS? BMW Car IT have a yocto layer, with MIT license, for cross compiling it here: https://github.com/bmwcarit/meta-ros I'm not familiar with it but it seems to be actively maintained and as you are using an R-Car M3 board I assume your project has an automotive flavour so the layer might be a good fit. The readme has details of their community. If you get somewhere please consider posting some notes about using it on R-Car somewhere. If there is no where obvious there are general notes about using R-Car in oss on elinux.org. I would be interested to hear how you get on. I work in the oss Genivi Automotive alliance (www.genivi.org) Regards Steve From: yocto-boun...@yoctoproject.org On Behalf Of Carlos Pozos Ochoa Sent: 21 February 2019 08:26 To: yocto@yoctoproject.org Subject: [yocto] ROS support on yocto project I recently acquire a Renesas R Car M3 board which runs on an embedded linux image build by means of the Yocto project. We are currently using YOCTO 3.9.0. We are looking forward to implement ROS kinetic libraries on this embedded linux. Does the yocto project supports this libraries? In the case it does, is there any special process to install and run them? Or is it work as a normal linux distribution? -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Cannot use LICENSE_CREATE_PACKAGE = "1" with mDNS package
I'm using the latest version from git branch of yocto thud.
If I add to INSTALL the package "mdns" and also I want to create all files
for licenses adding LICENSE_CREATE_PACKAGE = "1" the build of the final
image fails with this error:
Error myimage-1.0-r0 do_rootfs: Postinstall scriptlets of ['mdns'] have
failed. If the intention is to defer them to first boot,
then please place them into pkg_postinst_ontarget_${PN} ().
Deferring to first boot via 'exit 1' is no longer supported.
Without LICENSE_CREATE_PACKAGE = "1" everything is ok because I can build
both with and without licenses but not if LICENSE_CREATE_PACKAGE is
enabled.
Do you have any suggestions? Log doesn't say nothing really useful to me.
It seems a generic error. Am I missing something?
Thanks.
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] ROS support on yocto project
On Thu, Feb 28, 2019 at 9:26 AM Matthias Schoepfer < matthias.schoep...@googlemail.com> wrote: > Hi! > > > Yes, there is, there is a meta-ros. > > > For your convenience: > > > > https://discourse.ros.org/t/new-version-of-meta-ros-for-kinetic-distribution/2833 > > https://github.com/bmwcarit/meta-ros > > > It does work. BTW, afaik there is no yocto 3.9.0, 2.6.1 is last stable if > I am not mistaken. > yes - see https://wiki.yoctoproject.org/wiki/Releases > Regards, > > > >Matthias > > > On 2/21/19 9:26 AM, Carlos Pozos Ochoa wrote: > > I recently acquire a Renesas R Car M3 board which runs on an embedded > linux image build by means of the Yocto project. We are currently using > YOCTO 3.9.0. We are looking forward to implement ROS kinetic libraries on > this embedded linux. Does the yocto project supports this libraries? In the > case it does, is there any special process to install and run them? Or is > it work as a normal linux distribution? > > > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] ROS support on yocto project
Hi! Yes, there is, there is a meta-ros. For your convenience: https://discourse.ros.org/t/new-version-of-meta-ros-for-kinetic-distribution/2833 https://github.com/bmwcarit/meta-ros It does work. BTW, afaik there is no yocto 3.9.0, 2.6.1 is last stable if I am not mistaken. Regards, Matthias On 2/21/19 9:26 AM, Carlos Pozos Ochoa wrote: I recently acquire a Renesas R Car M3 board which runs on an embedded linux image build by means of the Yocto project. We are currently using YOCTO 3.9.0. We are looking forward to implement ROS kinetic libraries on this embedded linux. Does the yocto project supports this libraries? In the case it does, is there any special process to install and run them? Or is it work as a normal linux distribution? -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-security][PATCH V2] xmlsec1: add PACKAGECONFIG disable-des
On Thu, Feb 28, 2019 at 01:46:25PM +0800, changqing...@windriver.com wrote: > From: Changqing Li > > Signed-off-by: Changqing Li Reviewed-by: Tom Rini -- Tom signature.asc Description: PGP signature -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Enabling BLE on RPI 3B+ using meta-rasperrypi recipe
Hi,
I am using meta-raspberrypi
https://github.com/agherzan/meta-raspberrypi recipe to build an image
for RPI 3B+ . I want to enable bluetooth on the device.
My local.conf looks something like this
CONF_VERSION = "1"
ENABLE_UART = "1"
ENABLE_RPI3_SERIAL_CONSOLE = "1"
SERIAL_CONSOLES = "115200;ttyAMA0"
MACHINE = "raspberrypi3-64"
CORE_OS = " \
bluez5 \
openssh openssh-keygen openssh-sftp-server \
tzdata \
"
WIFI_SUPPORT = " \
crda \
iw \
wpa-supplicant \
"
DEV_SDK_INSTALL = " \
python3 \
pi-bluetooth \
python3-modules \
python3-pip \
python3-pygobject \
python3-dbus \
dbus-glib \
gobject-introspection \
"
DEV_EXTRAS = " \
ntp \
ntp-tickadj \
"
EXTRA_TOOLS_INSTALL = " \
bzip2 \
ethtool \
i2c-tools \
iperf3 \
iproute2 \
iptables \
less \
netcat \
procps \
sysfsutils \
tcpdump \
unzip \
util-linux \
zip \
dbus \
"
PREFERRED_VERSION_linux-raspberrypi = "4.%"
DISTRO_FEATURES_remove = "x11 wayland"
DISTRO_FEATURES_append = " bluez5 bluetooth wifi systemd"
IMAGE_INSTALL_append = " \
${CORE_OS} \
${DEV_SDK_INSTALL} \
${DEV_EXTRAS} \
${EXTRA_TOOLS_INSTALL} \
${WIFI_SUPPORT} \
"
VIRTUAL-RUNTIME_init_manager = "systemd"
PACKAGE_EXCLUDE_append = " packagegroup-core-ssh-dropbear"
I am not able to attach the device to the HCI interface.
bluetoothctl -- devices return "No default controller available"
I am very new to both Yocto and RPI distro. Any help in pointing to
the right firmware or init scripts to fix this is appreciated. Thanks.
--
Regards ,
Utsav
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Error in do_rootfs while builing on sumo with cmake the library called "libfmt" 4.1.0 (on rocko it was ok)
I had a similar problem where the rapidjson recipe was not working only on sumo.
The problem was that the default ${PN} package was empty so it would
not be generated, but do_rootfs would try to include it.
It helped to add a bbappend with the following line:
FILES_${PN} = " ${includedir}/ "
in your case you could possibly add ${libdir}/ as well,
This will create the rapidjson package and dnf will be happy.
I do not know if it is the right way to do that but it solves the
problem for me.
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] ROS support on yocto project
I recently acquire a Renesas R Car M3 board which runs on an embedded linux image build by means of the Yocto project. We are currently using YOCTO 3.9.0. We are looking forward to implement ROS kinetic libraries on this embedded linux. Does the yocto project supports this libraries? In the case it does, is there any special process to install and run them? Or is it work as a normal linux distribution? -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] ROS support on yocto project
Hi, I recently acquire a Renesas R Car M3 board which runs on an embedded linux image build by means of the Yocto project. We are currently using YOCTO 3.9.0. We are looking forward to implement ROS kinetic libraries on this embedded linux. Does the yocto project supports this libraries? In the case it does, is there any special process to install and run them? Or is it work as a normal linux distribution? Best Regards -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Removing busybox
Le 28.02.19 à 06:19, Adrian Bunk a écrit : > On Wed, Feb 27, 2019 at 11:59:42PM +, Burton, Ross wrote: >> ... >> Also swap vim for something in core obviously. > It is not obvious how to do that. > > What other vi implementation is in core? > Is there even any good non-busybox non-GUI editor in core? > Replacing busybox vi with ed would be a bad fit for the > stated usecases. > > There has to be some vi implementation installed, > and the "desktop command" implementation is vim. I have see numbers of users trying nano before falling back to vim or vi. The nano editor is standard on Debian and Ubuntu making a lot of users expecting it more intuitive interface. Jean-Christian -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Removing busybox
On Thu, 2019-02-28 at 09:37 -0500, Tom Rini wrote: > On Thu, Feb 28, 2019 at 02:27:37PM +, Richard Purdie wrote: > > On Thu, 2019-02-28 at 12:05 +, Burton, Ross wrote: > > > I thought we had some other editor in core, but can't see > > > one. Worse > > > case we still use busybox for its vi... :) > > > > This could be an argument for pulling a small number of things into > > OE- > > Core too... > > Moving the vim recipe (which doesn't have further depends) over and > then > putting VIRTUAL-RUNTIME_vim and ?= "vim-tiny" in this packagegroup > should be flexible enough, yes? Yes. Cheers, Richard -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Removing busybox
On Thu, Feb 28, 2019 at 02:27:37PM +, Richard Purdie wrote: > On Thu, 2019-02-28 at 12:05 +, Burton, Ross wrote: > > On Thu, 28 Feb 2019 at 05:20, Adrian Bunk wrote: > > > > That's a good start. For a oe-core packagegroup > > > > > > I do not think a core-only packagegroup makes sense when the goal > > > is to > > > completely replace busybox (and not just most apps while keeping a > > > few > > > busybox apps installed). > > > > But a "close enough" packagegroup in core would be a good starting > > point. > > > > > > I'd suggest dropping > > > > dnsmasq bridgeutils bindutils to keep it lean. > > > > > > The stated usecases are not "lean" but "replace all busybox > > > commands > > > with the full versions". > > > > > > For that you need bind-utils (in oe-core) for DNS lookup. > > > > Good point well made. > > > > Also swap vim for something in core obviously. > > > > > > It is not obvious how to do that. > > > > > > What other vi implementation is in core? > > > Is there even any good non-busybox non-GUI editor in core? > > > Replacing busybox vi with ed would be a bad fit for the > > > stated usecases. > > > > > > There has to be some vi implementation installed, > > > and the "desktop command" implementation is vim. > > > > I thought we had some other editor in core, but can't see one. Worse > > case we still use busybox for its vi... :) > > This could be an argument for pulling a small number of things into OE- > Core too... Moving the vim recipe (which doesn't have further depends) over and then putting VIRTUAL-RUNTIME_vim and ?= "vim-tiny" in this packagegroup should be flexible enough, yes? -- Tom signature.asc Description: PGP signature -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Removing busybox
On Thu, 2019-02-28 at 12:05 +, Burton, Ross wrote: > On Thu, 28 Feb 2019 at 05:20, Adrian Bunk wrote: > > > That's a good start. For a oe-core packagegroup > > > > I do not think a core-only packagegroup makes sense when the goal > > is to > > completely replace busybox (and not just most apps while keeping a > > few > > busybox apps installed). > > But a "close enough" packagegroup in core would be a good starting > point. > > > > I'd suggest dropping > > > dnsmasq bridgeutils bindutils to keep it lean. > > > > The stated usecases are not "lean" but "replace all busybox > > commands > > with the full versions". > > > > For that you need bind-utils (in oe-core) for DNS lookup. > > Good point well made. > > > Also swap vim for something in core obviously. > > > > It is not obvious how to do that. > > > > What other vi implementation is in core? > > Is there even any good non-busybox non-GUI editor in core? > > Replacing busybox vi with ed would be a bad fit for the > > stated usecases. > > > > There has to be some vi implementation installed, > > and the "desktop command" implementation is vim. > > I thought we had some other editor in core, but can't see one. Worse > case we still use busybox for its vi... :) This could be an argument for pulling a small number of things into OE- Core too... Cheers, Richard -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH meta-selinux] Backport patches from upstream to fix build with musl
From: Luca Boccassi
Audit 2.8.4 fails to build with musl. The fixes have been committed
to the upstream master branch and can be backported.
Building with glibc is unaffected.
Signed-off-by: Luca Boccassi
---
...dupa-as-suggested-in-pull-request-25.patch | 47 ++
...tue-functions-for-strndupa-rawmemchr.patch | 134 ++
recipes-security/audit/audit_2.8.4.bb | 2 +
3 files changed, 183 insertions(+)
create mode 100644
recipes-security/audit/audit/0001-Remove-strdupa-as-suggested-in-pull-request-25.patch
create mode 100644
recipes-security/audit/audit/0002-Add-substitue-functions-for-strndupa-rawmemchr.patch
diff --git
a/recipes-security/audit/audit/0001-Remove-strdupa-as-suggested-in-pull-request-25.patch
b/recipes-security/audit/audit/0001-Remove-strdupa-as-suggested-in-pull-request-25.patch
new file mode 100644
index 000..38029aa
--- /dev/null
+++
b/recipes-security/audit/audit/0001-Remove-strdupa-as-suggested-in-pull-request-25.patch
@@ -0,0 +1,47 @@
+From a1782b58b687b74249dc8b2411a3f646b821ebd6 Mon Sep 17 00:00:00 2001
+From: Steve Grubb
+Date: Thu, 4 Oct 2018 08:45:47 -0400
+Subject: [PATCH] Remove strdupa as suggested in pull request #25
+
+---
+ src/auditd.c | 11 ++-
+ 1 file changed, 6 insertions(+), 5 deletions(-)
+
+Origin:
https://github.com/linux-audit/audit-userspace/commit/a1782b58b687b74249dc8b2411a3f646b821ebd6
+Applied-Upstream: yes
+
+diff --git a/src/auditd.c b/src/auditd.c
+index b0952db..c826ec0 100644
+--- a/src/auditd.c
b/src/auditd.c
+@@ -209,21 +209,22 @@ static void cont_handler(struct ev_loop *loop, struct
ev_signal *sig,
+
+ static int extract_type(const char *str)
+ {
+- const char *tptr, *ptr2, *ptr = str;
++ const char *ptr2, *ptr = str;
+ if (*str == 'n') {
+ ptr = strchr(str+1, ' ');
+ if (ptr == NULL)
+ return -1; // Malformed - bomb out
+ ptr++;
+ }
++
+ // ptr should be at 't'
+ ptr2 = strchr(ptr, ' ');
+- // get type=xxx in a buffer
+- tptr = strndupa(ptr, ptr2 - ptr);
++
+ // find =
+- str = strchr(tptr, '=');
+- if (str == NULL)
++ str = strchr(ptr, '=');
++ if (str == NULL || str >= ptr2)
+ return -1; // Malformed - bomb out
++
+ // name is 1 past
+ str++;
+ return audit_name_to_msg_type(str);
+--
+2.20.1
+
diff --git
a/recipes-security/audit/audit/0002-Add-substitue-functions-for-strndupa-rawmemchr.patch
b/recipes-security/audit/audit/0002-Add-substitue-functions-for-strndupa-rawmemchr.patch
new file mode 100644
index 000..c948aa3
--- /dev/null
+++
b/recipes-security/audit/audit/0002-Add-substitue-functions-for-strndupa-rawmemchr.patch
@@ -0,0 +1,134 @@
+From 5346b6af0ca67a2965ca5846ae150f3021a2aa17 Mon Sep 17 00:00:00 2001
+From: Steve Grubb
+Date: Tue, 26 Feb 2019 18:33:33 -0500
+Subject: [PATCH] Add substitue functions for strndupa & rawmemchr
+
+---
+Origin:
https://github.com/linux-audit/audit-userspace/commit/d579a08bb1cde71f939c13ac6b2261052ae9f77e
+Applied-Upstream: yes
+
+ auparse/auparse.c | 12 +++-
+ auparse/interpret.c | 9 -
+ configure.ac| 14 +-
+ src/ausearch-lol.c | 12 +++-
+ 4 files changed, 43 insertions(+), 4 deletions(-)
+
+diff --git a/auparse/auparse.c b/auparse/auparse.c
+index f84712e..3764046 100644
+--- a/auparse/auparse.c
b/auparse/auparse.c
+@@ -1,5 +1,5 @@
+ /* auparse.c --
+- * Copyright 2006-08,2012-17 Red Hat Inc., Durham, North Carolina.
++ * Copyright 2006-08,2012-19 Red Hat Inc., Durham, North Carolina.
+ * All Rights Reserved.
+ *
+ * This library is free software; you can redistribute it and/or
+@@ -1100,6 +1100,16 @@ static int str2event(char *s, au_event_t *e)
+ return 0;
+ }
+
++#ifndef HAVE_STRNDUPA
++static inline char *strndupa(const char *old, size_t n)
++{
++ size_t len = strnlen(old, n);
++ char *tmp = alloca(len + 1);
++ tmp[len] = 0;
++ return memcpy(tmp, old, len);
++}
++#endif
++
+ /* Returns 0 on success and 1 on error */
+ static int extract_timestamp(const char *b, au_event_t *e)
+ {
+diff --git a/auparse/interpret.c b/auparse/interpret.c
+index 1846f9d..8540bd1 100644
+--- a/auparse/interpret.c
b/auparse/interpret.c
+@@ -853,6 +853,13 @@ err_out:
+ return print_escaped(id->val);
+ }
+
++// rawmemchr is faster. Let's use it if we have it.
++#ifdef HAVE_RAWMEMCHR
++#define STRCHR rawmemchr
++#else
++#define STRCHR strchr
++#endif
++
+ static const char *print_proctitle(const char *val)
+ {
+ char *out = (char *)print_escaped(val);
+@@ -863,7 +870,7 @@ static const char *print_proctitle(const char *val)
+ // Proctitle has arguments separated by NUL bytes
+ // We need to write over the NUL bytes with a space
+ // so that we can see the arguments
+- while ((ptr = rawmemchr(ptr, '\0'))) {
++ while ((ptr =
Re: [linux-yocto] [PATCH 1/3] features: Add the drm-bochs feature
On Wed, Feb 27, 2019 at 4:44 PM Alistair Francis wrote: > > On Wed, Feb 27, 2019 at 6:20 AM Bruce Ashfield > wrote: > > > > On Wed, Feb 27, 2019 at 9:18 AM Bruce Ashfield > > wrote: > > > > > > Hi Allistair, > > > > > > Which kernel versions were you using for these ? I was thinking 4.19 > > > and master, and have put them there. Let me know if you'd like to see > > > them on other versinos as well. > > > > > > > I take that back, they didn't apply cleanly to 4.19, so they are only > > on master. > > > > Let me know if you do want them on other versions. > > Hey Bruce, > > Thanks for that, I only wanted them applied to master. > > In general I assume the patches will only be applied to master unless > I specify otherwise. Let me know if you would like me to be more clear > about what branches I would like the patches applied to. Nope. That's fine with me. I just wanted to be sure in this instance. As long as i know that you are typically specifying versions when required, I'll run with just master for any patches. Bruce > > Alistair > > > > > Bruce > > > > > Bruce > > > > > > > > > On Mon, Feb 25, 2019 at 4:42 PM Alistair Francis > > > wrote: > > > > > > > > Signed-off-by: Alistair Francis > > > > --- > > > > features/drm-bochs/drm-bochs.cfg | 44 > > > > features/drm-bochs/drm-bochs.scc | 1 + > > > > 2 files changed, 45 insertions(+) > > > > create mode 100644 features/drm-bochs/drm-bochs.cfg > > > > create mode 100644 features/drm-bochs/drm-bochs.scc > > > > > > > > diff --git a/features/drm-bochs/drm-bochs.cfg > > > > b/features/drm-bochs/drm-bochs.cfg > > > > new file mode 100644 > > > > index ..4ff07bb3 > > > > --- /dev/null > > > > +++ b/features/drm-bochs/drm-bochs.cfg > > > > @@ -0,0 +1,44 @@ > > > > +CONFIG_DMA_SHARED_BUFFER=y > > > > +CONFIG_MOUSE_PS2_SYNAPTICS_SMBUS=y > > > > +CONFIG_MOUSE_PS2_SMBUS=y > > > > +CONFIG_VT_HW_CONSOLE_BINDING=y > > > > + > > > > +CONFIG_I2C=y > > > > +CONFIG_I2C_BOARDINFO=y > > > > +CONFIG_I2C_COMPAT=y > > > > +CONFIG_I2C_HELPER_AUTO=y > > > > +CONFIG_I2C_ALGOBIT=y > > > > + > > > > +CONFIG_DRM=y > > > > +CONFIG_DRM_KMS_HELPER=y > > > > +CONFIG_DRM_KMS_FB_HELPER=y > > > > +CONFIG_DRM_FBDEV_EMULATION=y > > > > +CONFIG_DRM_FBDEV_OVERALLOC=100 > > > > +CONFIG_DRM_TTM=y > > > > +CONFIG_DRM_BOCHS=y > > > > +CONFIG_DRM_PANEL=y > > > > + > > > > +CONFIG_DRM_BRIDGE=y > > > > +CONFIG_DRM_PANEL_BRIDGE=y > > > > +CONFIG_DRM_PANEL_ORIENTATION_QUIRKS=y > > > > +CONFIG_FB_CMDLINE=y > > > > +CONFIG_FB_NOTIFY=y > > > > +CONFIG_FB=y > > > > +CONFIG_FB_CFB_FILLRECT=y > > > > +CONFIG_FB_CFB_COPYAREA=y > > > > +CONFIG_FB_CFB_IMAGEBLIT=y > > > > +CONFIG_FB_SYS_FILLRECT=y > > > > +CONFIG_FB_SYS_COPYAREA=y > > > > +CONFIG_FB_SYS_IMAGEBLIT=y > > > > +CONFIG_FB_SYS_FOPS=y > > > > +CONFIG_FB_DEFERRED_IO=y > > > > + > > > > +CONFIG_FB_SIMPLE=y > > > > +CONFIG_HDMI=y > > > > +CONFIG_FRAMEBUFFER_CONSOLE=y > > > > +CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y > > > > + > > > > +CONFIG_SYNC_FILE=y > > > > +CONFIG_FONT_SUPPORT=y > > > > +CONFIG_FONT_8x8=y > > > > +CONFIG_FONT_8x16=y > > > > diff --git a/features/drm-bochs/drm-bochs.scc > > > > b/features/drm-bochs/drm-bochs.scc > > > > new file mode 100644 > > > > index ..6cc01ab0 > > > > --- /dev/null > > > > +++ b/features/drm-bochs/drm-bochs.scc > > > > @@ -0,0 +1 @@ > > > > +kconf hardware drm-bochs.cfg > > > > \ No newline at end of file > > > > -- > > > > 2.20.1 > > > > > > > > -- > > > > ___ > > > > linux-yocto mailing list > > > > linux-yocto@yoctoproject.org > > > > https://lists.yoctoproject.org/listinfo/linux-yocto > > > > > > > > > > > > -- > > > - Thou shalt not follow the NULL pointer, for chaos and madness await > > > thee at its end > > > - "Use the force Harry" - Gandalf, Star Trek II > > > > > > > > -- > > - Thou shalt not follow the NULL pointer, for chaos and madness await > > thee at its end > > - "Use the force Harry" - Gandalf, Star Trek II -- - 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: [yocto] Removing busybox
On Thu, 28 Feb 2019 at 05:20, Adrian Bunk wrote: > > That's a good start. For a oe-core packagegroup > > I do not think a core-only packagegroup makes sense when the goal is to > completely replace busybox (and not just most apps while keeping a few > busybox apps installed). But a "close enough" packagegroup in core would be a good starting point. > > I'd suggest dropping > > dnsmasq bridgeutils bindutils to keep it lean. > > The stated usecases are not "lean" but "replace all busybox commands > with the full versions". > > For that you need bind-utils (in oe-core) for DNS lookup. Good point well made. > > Also swap vim for something in core obviously. > > It is not obvious how to do that. > > What other vi implementation is in core? > Is there even any good non-busybox non-GUI editor in core? > Replacing busybox vi with ed would be a bad fit for the > stated usecases. > > There has to be some vi implementation installed, > and the "desktop command" implementation is vim. I thought we had some other editor in core, but can't see one. Worse case we still use busybox for its vi... :) Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
