That's great news!
Glad to help. It's frustrating some times, but I hope that also someone
else may come with a better solution.
Regarding secureboot, I guess that if you use the same keys, then there
shouldn't be any issue. But I haven't use it, so I can't tell from
experience.
Regards,
it is possible to use the beagleboneblack with the 8250 serial
driver or with the deprecated omap serial driver.
Unfortunately serial console get different names (ttyS0 with
8250 driver and ttyO0 with omap driver)
So set SERIAL_CONSOLES to
SERIAL_CONSOLES ?= "115200;ttyS0 115200;ttyO0"
On 2018/11/13 04:17, Bruce Ashfield wrote:
> On 2018-11-12 4:49 a.m., He Zhe wrote:
>>
>>
>> On 2018/11/6 00:05, Bruce Ashfield wrote:
>>> On 11/2/18 4:42 AM, He Zhe wrote:
When merging tag 'v4.18.10' into v4.18/standard/base, 05a9931 "of: fix
phandle
cache creation for DTs with
Since 'CONFIG_NR_CPUS=256' was moved to intel-x86-64.cfg, seeing
commit [11917e28727], we would better explicitly set CONFIG_NR_CPUS
to 64 in intel-x86-32.cfg for a future re-org of the fragments.
And the '64' is also the default value for intel-x86-32.
Signed-off-by: Hongzhi.Song
---
Sometimes the problem is that parts of the underscored function name are seen
as overrides, so you should try using "mysetcapfunction" instead as a name.
Also, there's a semicolon missing:
ROOTFS_POSTPROCESS_COMMAND += "my_setcap_function;"
On 12-11-18 14:09, Markus W wrote:
> Thanks Uwe!
>
>
On 2018-11-12 4:49 a.m., He Zhe wrote:
On 2018/11/6 00:05, Bruce Ashfield wrote:
On 11/2/18 4:42 AM, He Zhe wrote:
When merging tag 'v4.18.10' into v4.18/standard/base, 05a9931 "of: fix phandle
cache creation for DTs with no phandles" from v4.18.10 introduces an undefined
label "out" and
On Mon, 12 Nov 2018 at 16:20, akuster808 wrote:
> Maybe shoot for before the Dec Holidays instead of a fixed period after
> 2.6 releases, a nice way to end the year : )
*Before* the holidays, I don't plan on taking a laptop with me and RP
works enough outside of Mon/Fri 9-5 as it is! :)
Ross
--
All,
The triage team meets weekly and does its best to handle the bugs reported into
the bugzilla. The number of people attending that meeting has fallen, as have
the number of people available to help fix bugs. One of the things we hear
users report is they don't know how to help. We (the
On 11/12/18 8:12 AM, Burton, Ross wrote:
> On Sat, 10 Nov 2018 at 16:26, wrote:
>> My personal view is that whilst there are a number of issues present in
>> rc1, we should release it, collect up fixes on the thud branch (aleady
>> happening) and plan on a 2.6.1 as soon as it looks like we have
On Sat, 10 Nov 2018 at 16:26, wrote:
> My personal view is that whilst there are a number of issues present in
> rc1, we should release it, collect up fixes on the thud branch (aleady
> happening) and plan on a 2.6.1 as soon as it looks like we have enough
> critical mass behind those as opposed
good catch, thanks for the fix!
merged
On 11/11/18 8:19 AM, Niko Mauno wrote:
> Commit fcb2633921eb9bb711aa264247aebcfdd4ae which added Debian-style
> support for link relocation tries to relocate symbolic link on host OS,
> resulting in following-like error when two alternative packages
On Mon, 12 Nov 2018 at 14:33, Alan Martinovic wrote:
> > The standard do_install (which calls make install) copies the file
> > from the source tree to the staging directory.
>
> What's the reason for not seeing that in `bitbake -e systemd`?
It is there:
do_install() {
meson_do_install
> The standard do_install (which calls make install) copies the file
> from the source tree to the staging directory.
What's the reason for not seeing that in `bitbake -e systemd`?
Be Well,
Alan
On Mon, Nov 12, 2018 at 1:30 PM Burton, Ross wrote:
>
> The standard do_install (which calls make
Thanks Uwe!
I tried the global approach by adding the following to my local.conf file:
ROOTFS_POSTPROCESS_COMMAND += "my_setcap_function"
my_setcap_function() {
setcap cap_net_raw+eip ${IMAGE_ROOTFS}/usr/bin/node
}
But got the following warning:
WARNING: core-image-full-cmdline-1.0-r0
The standard do_install (which calls make install) copies the file
from the source tree to the staging directory.
Ross
On Mon, 12 Nov 2018 at 11:52, Alan Martinovic wrote:
>
> Hi,
> I'm trying to understand how a conf file finds its way from source to
> the rootfs.
>
> The example is use is
Hi,
I'm trying to understand how a conf file finds its way from source to
the rootfs.
The example is use is `journald.conf` from systemd.
The file originates from systemd source:
work/cortexa7hf-neon-vfpv4-senic-linux-gnueabi/systemd/1_234-r0/git/src/journal/journald.conf
In the environment
On 2018/11/6 00:05, Bruce Ashfield wrote:
> On 11/2/18 4:42 AM, He Zhe wrote:
>> When merging tag 'v4.18.10' into v4.18/standard/base, 05a9931 "of: fix
>> phandle
>> cache creation for DTs with no phandles" from v4.18.10 introduces an
>> undefined
>> label "out" and causes the follow
On Mon, Nov 12, 2018 at 10:35 AM Outback Dingo wrote:
>
> On Mon, Nov 12, 2018 at 3:22 PM Belisko Marek wrote:
> >
> > Hi,
> >
> > I'm having recipe for custom python3 application whcih need to install
> > ~20 python dependencies. I've create requirements.txt and using pip on
> > PC I can
On Mon, Nov 12, 2018 at 3:22 PM Belisko Marek wrote:
>
> Hi,
>
> I'm having recipe for custom python3 application whcih need to install
> ~20 python dependencies. I've create requirements.txt and using pip on
> PC I can install necessary python packages. When try to use
> pip3-native (as DEPENDS)
I Searched this question on google, stackoverflow but I did not find.
I am using DISTRO=poky MACHINE=intel-corei7-64 IMAGE=core-image-x11 sceme.
The machine which I want to install image, doesn’t allow bootx64 but it
works when I install x32 efi.
I checked this (I copied first bootia32.efi and
Hi,
I'm having recipe for custom python3 application whcih need to install
~20 python dependencies. I've create requirements.txt and using pip on
PC I can install necessary python packages. When try to use
pip3-native (as DEPENDS) and call pip3 I get some errors:
pkg_resources.VersionConflict:
21 matches
Mail list logo
